►
From YouTube: IETF-DTN-20221005-1700
Description
DTN meeting session at IETF
2022/10/05 1700
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
Excellent,
thank
you
Ed,
so
yeah
good
afternoon.
Everyone
welcome
to
the
dgn
interim
meeting.
I
I
have
an
apology
to
start
with,
as
I
mentioned
in
the
chat,
I
was
on
vacation
last
week
for
two
weeks
and
I
picked
up
kovid
on
the
way
home,
so
I
I'm
a
little
bit
groggy
and
I'm
still
making
strange
coughing
noises
which
is
unpleasant
for
me
and
I
will
attempt
to
mute
my
microphone
before
doing
so.
A
B
So
again,
as
Rick
said,
welcome
to
the
interim
meeting,
we
had
really
two
things
that
we
wanted
to
make
sure
that
we
covered,
and
the
interim
meeting
is
a
little
bit
less
formal
than
the
typical
working
group
meetings.
In
that
we
don't
have.
You
know
PowerPoint
slides,
to
go
through
because
I
think
really.
What
we
want
to
do
is
focus
on
the
ipn
internet
draft
that
Rick
has
put
up.
B
There
were
some
comments
coming
from
the
mailing
list
as
to
ways
in
which
we
wanted
to
update
this,
we
we
did
not
put
out
a
new
version
of
that
and
honestly
putting
a
new
version
out.
You
know
the
day
before
a
few
days
before
the
interim
meeting
probably
doesn't
make
a
lot
of
sense,
so
the
the
plan
was
for
us
to
take
really
the
bulk
of
this
meeting
and
walk
through
that
document.
B
That
document,
in
addition
to
proposing
an
extension
to
ipn,
also
has
a
section
that
tries
to
capture
some
of
the
concerns
that
were
associated
with
not
extending
ipn
based
on
the
mailing
list
and
use
that
in
a
screen
share
to
talk
through
what
we
think
should
and
should
not
be
incorporated.
If
there
is
time
remaining
on
the
agenda,
we
do
have
a
little
bit
of
an
update
to
talk
through
on
network
management,
but
we
can
also
do
that
at
ietf
115.
B
A
Thanks
so
just
for
sort
of
General
administrivia,
so
this
is
an
ITF
meeting,
so
this
is
covered
by
the
ietf
note.
Well,
we
would
normally
show
this
on
the
screen,
but
frankly,
as
Ed
said,
we
haven't
done
any
slides
for
this,
because
we
didn't
seem
that
particularly
useful,
but
you
are
now
formally
warned.
This
is
an
a
standard,
ITF
meeting
and
therefore
covered
under
the
no
well.
Please
go
and
check
the
note
well
on
the
ITF
resources
page.
A
If
you
are
not
familiar
with
it,
if
someone's
feeling
particularly
efficient,
could
they
post
a
link
to
it
in
the
chat?
There
is
a
meeting
note
taking
tool
as
ever
built
into
meet
Echo.
Please
feel
free
to
use
that
if
you
wish
to
make
some
minutes
on
this,
although
the
recording
of
This
will
be
made
and
automatically
and
will
be
available
after
the
event
for
people
to
watch
again
but
as
Ed
said
we're
not
being
particularly
formal
about
this,
but
it
is
an
official
IDF
meeting.
A
What
I'm
sharing
on
the
screen
at
the
moment
is
actually
the
raw
markdown
of
the
draft,
so
I
published
two
versions
co-written
with
Ed.
Simply
it's
not
entirely
my
own
work,
although
I
am
probably
the
primary
typist
I
write
it
in
markdown
because
it's
really
convenient
to
edit,
but
it
also
means
we
can
make
live
changes
now.
A
So
what
we
thought
we'd
do
is
almost
Workshop
this
document,
because,
although
it's
a
personal
draft
at
the
moment,
I
think
it
might
be
a
good
candidate
for
working
group,
adoption
very
happy
to
receive
feedback
and
make
comments
within
my
own
working
copy
at
the
moment,
push
out
another
copy
and
then
we'll
discuss
that
at
ietf115
to
see
whether
the
working
group
does
like
it,
whether
we're
willing
to
adopt
it.
That
sort
of
thing,
so
what's
quite
important
to
remember
here,
is,
although
both
Ed
and
I
are
chairs
of
dtn.
We're
also
authors
of
this.
A
So
when
we're
talking
about
this
document,
we
are
very
much
personal
contributors
to
the
to
the
working
group.
These
are
personal
drafts
and
you
should
ignore
the
fact
that
we
happen
to
chair
the
working
group
at
the
same
time,
and
we
promise
that
this
is
not
a
conflict
of
interest
and
we're
not
abusing
our
position
of
power
to
flag
away
for
our
own
opinions.
A
A
A
So
of
those
who
have
not
read
the
draft
well
now
this
is
an
open
question,
I'm
running
out
of
breath
already
Ed.
Do
you
want
to
give
a
little
summary
for
this,
while
I
mute
myself
and
have
a
cough?
If
that's,
okay,
I,
don't
think
we
need
to
spend
too
long
summarizing
this
and
then
I
I'd
quite
like
to
get
into
some
of
the
the
Q
a.
B
The
observation
was
that,
when
that
individual
node
number
represents
something
that
has
meaning
within
a
locally
administered
domain,
then
the
control
of
that
and
the
allocation
of
those
numbers
is
probably
manageable.
But
if
we
wanted
to
extend
this
to
be
more
of
a
global
uniqueness
than
having
a
sim,
a
single
flat
number
space
for
nodes
may
become
very
difficult
to
manage,
and
so
we
looked
at
other
things
that
that
tried
to
tackle
these
similar
problems.
B
It
would
turn
it
into
something
more
like
like
numberingauthority
dot,
node
number
dot
service
number,
and
then
there
are
a
couple
of
different
flavors
of
that.
So
really
the
the
fundamental
questions
here
are
whether
a
single
flat
node
numbering
namespace
can
work
in
a
global
distribution.
And,
if
not,
then
is
the
idea
of
tagging
organizations
as
a
numbering
Authority
the
the
thing
that
gets
us
a
more
scalable
solution.
B
So
so
that's
really
the
purpose
of
the
primary
purpose
of
this
document
and
then
a
secondary
purpose
is
to
go
back
and
make
very
clear
that
for
bundle
protocol
version
seven,
there
are
Registries
associated
with
the
use
of
ipn
and
the
organizations
for
node
numbering
and
service
numbering.
Whereas
it's
a
little
bit.
People
have
expressed
confusion
to
us
as
to
what
Registries
to
look
at
for
what
purposes.
B
C
C
Is
it
there
any
urgency
to
discuss
this,
and
let
me
elaborate:
is
there
any
impending
event
organization
that
is
working
towards
this?
The
reason
I'm
asking
is
because
this
is
a
very
fundamental
change,
so
one
to
understand
whether
the
approach
here
would
be
for
hey,
let's
make
sure
that
we
analyze
and
reanalyze
these
versus.
No,
we
need
to
move
fast
because
of
X,
Y
or
Z.
Just
trying
to
you
know
understand
a
little
bit
and
the
situation.
B
D
My
comment
is
actually
not
so
much
on
that.
It's
it's
on
the
question
of
whether
a
flat
numbering
space
can
be
used
and
what
I
would
offer
there
is
that
clearly
it
can
be
used
and
I.
Think
the
the
the
the
draft
explains
how
it
you
know,
based
on
node
number
ranges
that
are
assigned
to
to
to
numbering
authorities
is
a
is
a
mechanism
that
is
contemplated
in
the
current.
D
Registries,
the
the
question
really
is
not
whether
it
can
be
used
the
questions,
whether
it's
desirable
and
and
I,
think
the
advantage
of
of
adding
additional
structure
to
the
to
the
node
naming
in
this
scheme
is
compression
you.
It
enables
a
very
small
node
numbers
to
be
used
by
many
different
organizations
without
requiring
that
every
node
number
of
the
16
bits
long
and.
A
Can
I
just
jump
in
to
answer
Alberto's
question
for
a
second,
my
reasoning
for
for
kicking
off
this
document,
and
we
were
talking
about
timeliness
is:
is
there
some
pressing
need
to
get
the
to
look
at
some
of
my
perceived
issues
with
ipn
I
had
started
to
within
the
context
of
of
the
updated
Charter
for
the
working
group?
We're
looking
at
naming
and
addressing
lots
of
people
started
to
discuss
this
I
know
myself.
A
I
looked
at
ipn
I
had
a
lot
of
side
conversations
with
people
who
were
using
ipn
and
through
my
investigation,
I
I
started
to
uncover
that
there
was
some
confusion
about
how
to
use
it
successfully.
There
wasn't
really
a
consistent
document
which
pulled
it
all
together.
So,
although
I
am
unaware
of
any
pressing
industrial
or
big
space
mission,
that
is
is
going
to
require
an
update
that
some
breaking
change
to
occur.
C
Things
out
things
we
got
a
and
ahead
I,
I
appreciated
and
the
reason
you
know
I
was
asking.
The
question
was
also
to
you
know:
I
think
one
thing
that
would
benefit
is
to
you
know,
look
at
the
specific
examples
in
the
upcoming.
You
know
in
their
coming
meetings,
because
I
think
there's
some
I
wouldn't
say
confusion,
but
I
don't
think
there
is
General
agreement
into
you
know
how
much
of
these
authorities
gonna
be
used
for
you
know
forwarding
versus
you
know.
C
A
So,
yes,
you
make
a
very
valid
point
there,
which
I
probably
should
have
called
out
and
Scott.
Yes,
I
can
see
you
in
the
queue
sorry
one.
Second,
this
whole
thing
is
about
interoperable
Behavior,
so
this
is
It's
kind
of
under
the
remit
of
the
ITF,
the
itfs,
about
interoperability
between
cooperating
parties.
If
you
want
to
use
ipn
for
your
own
purposes
within
your
own
closed
system,
and
no
that
don't
need
to
talk
to
anyone
else,
great
knock
yourself
out,
you
don't
need
a
standard
for
that.
A
You
can
go
and
go
and
have
fun
bundle.
Protocol
threshold
7
will
work
beautifully
for
you
use
your
own
naming
when
you
want
to
interoperate.
It
starts
to
become
important,
and
all
the
proposed
changes
I've
made
in
this
document
are
to
make
that
interoperability
easier
to
administrate,
easier
to
manage
and
easier
to
use.
So
so
interoperability
is
the
key
point
and
yeah
I
I
will
make
a
note
to
do
some.
Nice
worked
examples,
although
I
don't
want
to
talk
about
routing.
D
A
So
so
that's
a
very
valid
point.
Again.
It's
got
sorry.
We
had
a
conversation
with
zaheda
rad
about
how
to
update
that
registration,
because
we
we
had
noticed
that
the
Iona
Registries
were
called
slightly
misleading
things.
We'd
had
a
number
of
questions.
The
correct
way
to
update
that
in
I
ITF
world
is
to
publish
a
document,
so
we
kind
of
knew
we
had
to
write
a
document
anyway
and
that
that
was
a
great
way
to
to
drive
us
to
say
well.
A
Actually,
if
we're
writing
this
anyway,
let's
try
and
address
some
of
these
other
points.
It
might
be
the
case
and
I'm
perfectly
open
to
a
suggestion
from
from
the
working
group
to
say
actually
Rick
make
these
two
documents,
one
which
just
addresses
the
Iona
registration
naming
thing
and
bring
in
this
whole
subtle,
allocating
Authority
business
and
these
these
extra
extra
dotted
authorities
as
a
different
draft.
We
can
debate
them
separately.
That
is
an
open
question.
I
I,
it's
just
text
I'm,
not
that
precious
about
it.
A
So,
from
my
perspective,
because
of
the
way
seabor
is
encoded
and
Carson
is
on
the
call-
and
he
will
correct
me
if
I
make
a
single
sepal
error
here,
numbers
less
than
23
can
be
encoded
in
one
octet.
As
soon
as
you
have
integers
greater
than
23.
You
start
to
need
more
octets
quite
quickly,
so
that
that
results
in
a
race
for
low
numbers
and
if
we
use
a
single
numbering
space
and
and
as
it
stands
in
RFC,
9171,
You've
Got
2
to
the
64
bits
to
play
with
with
the
first
come.
A
First
served
access
to
that
numbering
space.
If
you
don't,
if
you're,
not
the
first,
if
you're
not
at
the
head
of
the
queue,
you
have
to
have
overly
long
encodings
in
order
to
interoperate
with
the
lucky
people
who
got
the
shorter
encodings
and
that's
the
main
pressure.
Oh,
it's
one
of
the
main
drivers
I
saw
to
say
well
actually
by
using
a
a
different
way
of
encoding
effectively
as
a
prefix
architect
as
a
prefix
number.
A
E
That,
then
is
this
might
not
be
something
anybody
wants
whatsoever,
but
I'll
go
ahead
and
throw
it
out
there.
Would
it
be
a
possible
option
to
extend
the
usage
of
the
report
to
Eid
to
effectively
also
act
as
your
Authority
identifier,
at
which
point
the
ipn
scheme
stays
exactly
the
way
it
currently
is,
and
then,
if
you
need
to
or
want
to
do
more
of
the
low
number
system
or
whatever,
then
you
could
use
the
report
to
Eid
to
establish
effectively
what
the
authority
is.
E
A
E
I'm,
specifically,
envisioning
is
kind
of
along
the
lines
of
with
a
different
type
of
thing,
that's
being
worked
on
the
IMC
or
interplanetary
multicast
stuff,
with
the
idea
of
having
your
Edge
nodes
or
inter-regional,
routers
or
whatnot
that
you
would
effectively
have
a
named
singular
Edge
router.
That
could
quote
unquote,
be
in
the
reply
to
Eid
space.
A
Are
you
going
to
make
a
very
quick
comment
and
I've
seen?
Ed
has
immediately
jump
to
the
queue
on
this
one
and
I'm
going
to
shut
up
for
a
second
I
know
where
you're
going
with
this
I
think
that
leads
you
in
the
direction
of
bundle
in
bundle.
Encapsulation
I
think
you're
absolutely
fine
to
do
that,
but
that's
where
you're
effectively
tunneling
from
one
addressing
domain
to
another
addressing
domain
and
having
to
end
cap
and
Decap
on
the
way
through
I
think
that
will
work
very
well
so
effectively.
A
What
you're
doing
is
Network
address
translation
rather
than
extending
the
address
space
to
allow
for
a
single,
homogeneous,
interoperable
address
space
I
think
it's
it's
something.
I've
I've
certainly
discussed
with
Scott
and
a
few
other
people.
It's
it's
quite
a
nice
way
of
doing
other
things,
but
it's
Network
address
translation
rather
than
extending
the
address
space
to
allow
everyone
to
do
it
without
that
that
extra
CPU
work
Ed.
Do
you
want
to
jump
in
or
Adam
you've
got
a
comment.
D
Quickly,
you
can
jump
in
front
of
Adam,
but
I
will
try
to
speak
very
quickly,
just
that
that
I
think
having
a
single
naming,
Authority
indication
in
the
bundle
is
probably
not
sufficient,
because
the
source
and
destination
might
have
been
named
by
different
authorities.
So
I
think
each
each
endpoint
ID
is
going
to
need
its
own
Authority
identification.
If
we're
going
to
use
this
mechanism
and
I
don't
know
shut
up,
but.
B
E
B
If
that
is
not
the
design
decision,
then
then
really.
If
that
is
the
design
decision,
then
we
need
a
registry
of
of
authorities,
not
a
registry
of
node
numbers
or
node
number
ranges,
so
so
that
may
that
may
impact
whether
there
are
two
documents
or
one,
the
design
of
one
is
going
to
clearly
impact
the
design
of
the
other.
B
A
So
so
can
I
answer
that
so
I
I
put
a
I
put
a
a
discussion
points
at
the
bottom
of
this
document
to
try
and
capture
the
answers
to
some
of
those
questions
and
I
absolutely
agree
with
the
question.
So
I
I
had
a
draft
which
wasn't
published
called
ipn3
to
sort
of
capture
the
fact
that
oh
we've
got
a
sort
of
a
a
three
Tuple
of
of
address,
and
it's
it's.
You
know
it's
perhaps
different.
A
Fundamentally,
if
you
think
about
the
processing
that
a
receiving
bundle
processing
node
does
when
it
receives
an
ipn,
a
number
either
a
yeah
either
an
ipn3
new
scheme,
identifier
or
an
existing
scheme
identify
with
a
different
arity
for
the
Rarity
different
dimension
for
the
for
the
array
that
makes
up
the
Eid
itself.
The
behavior
is
identical.
It
just
hits
an
error
case,
one
octet
later.
A
So
actually
you
know
and
I
suggest,
reading
this
I,
don't
I,
don't
really
want
to
read
it
through,
but
fundamentally
goes.
Oh
I've
got
an
Eid
either,
don't
recognize
the
scheme
because
it's
ipn3,
because
I
that
didn't
exist
when
when
I
started,
when
I
went
into
service.
So
therefore
I
don't
recognize
it
or
oh,
it's
an
ipn
scheme,
that's
great!
How
many
dimensions
are
there
to
the
to
the
ipn
thing?
Three,
oh
I
wasn't
aware
that
such
a
thing
existed
same
error,
so
I
think
functionally.
There
is
no
difference.
A
E
So
I
would
say
this
is
probably
just
personal
preference
here,
but
from
my
standpoint,
where
I
work
with
the
Marshall
space
flight
center
and
the
ISS,
it
would
be
more
frustrating
to
have
to
try
and
figure
out
how
to
fix
our
systems
to
allow
for
both
options
than
it
would
be.
To
Simply
say
that
this
new
scheme
is
legitimately
just
a
new
scheme.
D
The
the
the
sort
of
issues
that
I
was
focusing
on
in
the
email
that
I
sent
out
yesterday
proposing
that
that
we
can
Institute
this
change
to
the
scheme
and
limit
the
impact
on
existing
implementations.
If
the,
if
the
sizes
of
authority
numbers
sub,
Authority
numbers
and
node
numbers
are
restricted
in
such
a
way
that
you
can
transform
the
a
an
authority
unqualified
Eid
into
a
single
unassigned
long
long
integer
for
internal
use
within
the
within
the
implementation.
D
D
A
B
So
I
I'll
just
jump
in
and
say
two
things.
One
is
that
you
know
Josh
when
we
talk
about
existing
implementations.
The
question
there
is:
are
these
implementations
again
assuming
a
local
administrative
Network
right?
So
one
of
the
things
that
I
see
in
in
this
document,
this
proposed
extension
is
that
a
a
two
Tuple
ipn
address,
a
name
is
still
valid.
You
can
say
ipn
1.1,
and
the
idea
is
that
the
the
the
organization
is
assumed
to
be
locally
administered.
B
So
if,
if
the
idea
is
that
there
is
a
relatively
small
you
know
deployment
of
that,
then
then
there
may
not
be
really
any
changes
required
if
in
that
Network
you're
still
using
essentially
a
local
administrative
domain
for
backwards
compatibility.
However,
if
your
node
is
4
billion-
and
you
want
everyone
in
the
world
to
know
that
4
billion
means
you
that
becomes
perhaps
more
difficult
to
to
manage
and
maintain,
in
which
case
I
am
not
against.
B
You
know
Scott's
proposal
to
say:
are
there
reasonable
thresholds
to
put
on
things
with
an
eye
towards
whether
or
not
that
enables
efficient
Coatings,
I
I,
certainly
see
standards
make
decisions
based
on
what
may
or
may
not
entice
firmware
implementation
or
other
kinds
of
implementation?
So
I
think
that
that's
a
valid
discussion
that
that
should
also
be
had
so
my
two
points.
A
So
I'm
just
going
to
jump
in
just
before
you
Joshua
story.
I
should
I
should
put
my
myself
with
the
queue
here,
I'm
being
a
bad
citizen,
I'm
going
to
say
one
thing:
I,
don't
think
the
status
quo
is
satisfactory,
so
I'm
I'm,
going
to
flag
wave
here
to
say
there
needs
to
be
some
change,
relying
on
allocations
in
the
cbhe
registry,
which
were
for
bundle,
protocol
version,
six
for
bundle,
protocol
version,
seven
implementations,
and
just
assuming
that
that's
that's
not
going
to
work.
A
It's
it's
there's
a
lot
of
supposition
that
that's
the
right
way
to
go
and
it's
it's
not
built
on
any
solid
foundation.
So
some
sort
of
clarity
has
to
occur.
Whether
that
is
a
new
scheme
or
an
update
to
to
IPM,
specifically
I
prefer
the
latter,
but
I.
Think
one
of
those
two
options
has
to
occur.
Doing
nothing.
I,
don't
believe,
is
an
option.
E
What's
going
on
in
my
mind
from
an
operator's
perspective,
I
know,
inevitably
on
the
ISS
we
will
end
up
having
to
combine
usage
of
BP
version
6
with
BP
version
seven
and
there
it's
minimal,
but
there
is
a
certain
amount
of
worry
from
my
perspective
that
using
the
same
ipn
nomenclature
to
Define
two
separate
ways
of
how
it's
supposed
to
look
might
enter
some
slight
confusion
there.
It
wouldn't
necessarily
cause
a
giant
issue,
but
I
can
foresee
that
happening
at
the
very
least
and
again.
A
So
even
if
you're
trying
to
name
things
the
same
using
the
ipn
scheme,
you're
never
going
to
send
a
six
bundle
to
a
seven
device
without
doing
some
sort
of
end
cap,
Decap
or
some
kind
of
bridging
gatewaying
translation.
Something
is
going
to
have
to
happen
and
given
you're
having
to
do
that
anyway.
Doing
name
translation
as
part
of
that
I
see
that
as
a
viable
price
to
pay,
so
I
I
every
time
I've
gone
through
this.
Oh,
isn't
this
going
to
break
back
compatibility
with
bundle
protocol
version?
Six!
It's
that
there
isn't!
E
Any
form
of
compatibility
there
between
the
versions
I'm,
just
saying
simply
from
a
perspective
of
a
operator
on
the
ground
that
barely
knows
what
they're
talking
about
when
they
say
dtn.
If
they
see
a
V6
bundle
and
then
happen
to
see
a
V7
bundle,
and
that
name
is
different.
They
have
no
idea
what
the
heck.
That
means
that
could
lead
to
confusion.
And
again
it's
not
a
very
high
issue.
Necessarily
it's
just
something:
I
wanted
to
throw
out
there
as
a
it
will
most
likely
happen.
D
B
D
D
If
we
did
not
do
it
I
think
you
know
the
the
flat
every
every
every
node
number
is
is
64
bits
that
that
can
work
and
what
it
does
is
it
disadvantages.
People
who've
got
a
low,
a
high
high
range
of
node
numbers.
They
spend
more
bandwidth
and
there's
there's
clearly
an
operational
disadvantage
there
and
I
think
it's
worthwhile
to
try
to
address
that
operational
disadvantage.
I
I
think
it's
it's
not
that
addressing.
A
So
I'm
well
as
a
stunned
silence
and
I
actually
agree
with
with
Scotland
I'm
gonna
raise
one
point
which
appears
to
have
slipped
through
reviews,
so
we've
got
it
quite
caught
up
in
node
numbers
and
naming
authorities
for
the
nodes.
One
piece
that
existed
with
the
bundle
protocol
version,
six
versions
of
ipn,
so
the
cbhd
6020
and
and
7116
and
I
I
God
RFC
numbers
in
those
previous
rfcs.
The
administrative
endpoint
was
always
service
number
zero.
A
A
D
I
would
have
to
document
to
give
you
an
answer
on
that,
but
I
my
dim
recollection
is
the
intent.
Was
that
the
administrative
endpoint
is
always
the
serious
number
is
always
zero.
I
I
think
the
language
in
and
I'd
have
to
go
back
and
look
I.
Think
the
language
in
RC
71
is
that
the
administrative
and
endpoint
a
service
number
it
either
is.
A
D
C
D
A
A
D
A
D
The
intent
was
it.
Let
me
take
a
step
back
and
say
if
I
was
starting
from
a
blank
sheet
of
paper,
I
would
say
that
nodes
are
identified
by
a
node
number,
possibly
an
authority
qualified
node
number
period.
I
would
make
node
numbers
first
class
Concept
in
the
document
and
and
construct
eids
from
them
and
say
that
the
node
number
identifies
the
node
period.
We
have
not
done
that.
D
It
may
be
that,
that's,
like
you
know,
closing
the
Barn
Door
after
the
horse
is
gone
right.
It
may
be
too
late
for
that
I'm
I'm
not
opposed
to
it,
but
I'm
not
sure
it's
doable.
That
is
the
intent.
The
intent
is
the
the
the
the
the
node
identifier,
whether
it's
qualified
or
not,
is
is
is
the
identifier
for
the
no
in
the
ipn
scheme.
It's
not
the
sole
identifier
for
the
node
anyway,
because
the
node
can
be
identified
within
the
dtn
scheme
as
well.
D
Yeah
DTM,
multicast,
I
I,
agree
that
this
would
be
desirable
and
if
it's
something
that
that
that
we
can
do,
you
know
sort
of
logistically
and
you
know
in
terms
of
and
procedurally
then
then
I'm
all
for
it.
I'm
I'm,
just
saying
I'm,
not
certain
that
it
is
and
and
and
I'm,
not
certain
that
it
has
to
be
a
big
problem.
But.
A
So
so
talking
procedurally
I
think
if
we're
going
to
make
a
change
to
ipn,
we
try
and
Tackle
all
these
things
and
don't
have
and
then
close
the
lid
on
ipn
for
at
least
five
years.
I
don't
want
to
come
back
to
this
in
two
years
time
and
say:
oh
there's,
another
update
to
ipn,
because
at
that
point
everybody
from
an
implementer.
You
know
the
NASA
guys
the
Jackson
guys
on
this
call
are
just
going
to
say
no,
we've
lost
all
faith
in
whatever
you're
doing
IDF.
F
So
I'm
kept
quiet
because
I've
had
nothing
to
contribute
on
the
specific
points
under
discussion,
but
I
have
another
point
about
the
draft
as
a
whole.
I'm
not
going
to
pretend,
although
I
have
read
it
with
some
care
several
times
that
I
fully
understand.
The
draft
are
all
the
termifications,
because
my
involvement
in
the
DTI
and
working
group
hasn't
been
sufficiently
deep
for
the
last
several
years,
but
I
have
been
involved
with
the
host
identity
protocol.
I
can
hear
some
of
you
groaning.
F
Authority
and
I
could
take
one
of
his
hierarchical
domain
authorities
and
declare
it
to
be
a
local
sub.
You
know
naming
Authority
and
I
could
use
his
orcid
V2
modified
H,
hit
construction
procedure
to
create
the
hash
and
use
that
64-bit
hash
as
the
64-bit
piece
of
all
this
and
have
full
compatibility
between
this
naming
scheme
and
the
hierarchical
host
identity.
Tag
which
I
will
point
out
is
also
an
identifier.
F
So
I'm
going
to
repeat
my
plea:
the
people
who
are
not
already
familiar
with
host
identity
tags
and
the
recent
extension
this
hierarchical
host
identity
tags,
take
a
look
at
our
drone,
remote
identification
protocol
working
group
documents
and
see-
if
you
agree
with
me
that
indeed
we
would
have
compatibility
here
and
I
think
that
is
stipulated
as
germane
by
virtue
of
the
boss
for
time
variant,
routing,
which
acknowledges
that
we
are
concerned
not
only
with
spacecraft
but
also
with
unmanned
aircraft
systems.
Slash
rant.
A
Thanks
Stuart,
unsurprisingly,
for
those
who
know
me
and
Stuart,
we
have
discussed
some
of
this
and
yeah.
That's
where
some
of
the
ideas
came
out
of
conversations
with
Bob.
So,
yes,
it
is
quite
nice
that
you
can
embed
other
methods
of
allocating
numbers
within
the
prefixing
scheme.
However,
I
think
it
is
quite
important
to
remember
these
are
just
methods
of
allocating
numbers
and
at
the
discretion
of
whichever
Authority
has
the
permission
to
allocate
into
a
certain
area.
A
D
B
B
That
was
my
comment.
I
guess,
with
with
chair
hat
on
I,
have
a
few
questions,
because
we're
getting
to
the
end
of
the
hour
of
it
seems
to
me
that
that
an
extension
of
the
ipin
scheme,
as
the
ipn
scheme
is,
is
something
that
we
are
generally
on
board
with,
and
there
are
some
questions
associated
with
how
that
would
happen.
So
so
I
wanted
to
know
and
really
Rick
what
you
thought,
as
well
of
just
putting
up
a
few
quick
polling
questions
related
to
this
or
really
just
asking.
B
If
people
are
are
concerned,
and
then
the
other
is
to
really
understand
if
there
are
any
final
comments
on
this,
this
concept
of
thresholding
I
I
certainly
understand
the
desire
to
have
an
internal
representation.
That
is,
is
helpful
and
and
restricted
in
some
way
to
64
bits.
But
what
I'm?
What
I'm
going
over
in
my
head
is?
Is
that
an
Ianna
restriction,
or
is
that,
like
a
ccsds
restriction?
B
A
B
That-
and
this
was
an
email
that
Scott
had
proposed,
sent
to
the
mailing
list
to
propose
if
numbering
authorities
are
capped
at
32
bits
and
sub
organization,
IDs
are
capped
at
16,
bits
and
and
node
numbers
are
capped
in
16
bits.
Then
the
combination
of
numbering
Authority,
sub,
ID
and
node
number
would
always
fit
within
64
bits,
so
you
could
pack
them
into,
for
example,
a
64-bit
unsigned
interview,
and
that
has
some
implementation
advantages.
A
Yeah
I
I
can
see.
I
could
see
good
implementation
reasons,
I
think
in
the
in
the
body
of
the
text.
At
the
moment,
I
I
think
under
the
the
authority
numbers
I
think
I've
I
I
suggested
that
any
numbering
authorities
with
a
number
larger
than
2
to
the
power
of
16,
so
65
536,
should
be
private
or
experimental.
A
So
these
would
never
be
registered.
These
wouldn't
be
available
for
registration
kind
of
allowing
people
to
use
them
for
their
own
purposes
and
not
expecting
them
to
be
interoperable
in
any
particular
way.
I
think
had
would
have
the
side
effect
of
delivering
what
Scott
is
asking
for
without
saying
it
must
so
so
enforcing
through
registration,
rather
than
the
new,
forcing
through
rules
in
this
document.
If
that
makes
sense,.
D
So
I
I
I
think
there
is
again
going
back
to
wanting
to
try
to
preserve
the
applicability
of
of
dvn
to
work
that
has
already
been
done
in
NASA
and
and
not
just
ccsds,
but
other
other
entities
that
are
using
the
existing
implementations
for
the
purposes.
Maybe
terrestrial
and
maybe
space
I,
think
I.
Think
it's
desirable
to
avoid
that
and
I
think
it
costs
nothing
because
I
think
it
is.
A
I
I
agree
with
you
speaking
frankly:
I'm
I
was
trying
really
hard
not
to
update
RFC
9171.
With
this
document.
That's
the
most
compelling
reason.
I
had
not
to
start
bringing
in
rules
like
that,
because
I
really
didn't
want
to
change
9171,
because
I
think
the
the
perceived
impact
of
updating,
bundled
protocol
version,
seven
Even
If,
all
we're
doing-
is
correcting
some
of
the
number
ranges
for
ipns
in
a
very
specific
small
section.
I
can
imagine
various
space
agencies
just
throwing
their
hands
in
the
air
and
discussed
at
that.
D
A
A
problem
I
I,
I
I,
take
I,
take
your
point
and
it
may
get
as
far
as
if
this
was
to
be
adopted
and
hit
iesg
and
the
the
IR
the
IDF
RFC
editors.
They
may
turn
around
and
say.
Actually
this
does
do
an
update
and-
and
we
can
work
through
the
politics
of
that
I
I
I'm-
very
wary
about
altering
a
specification
in
order
to
manage
existing
implementations
that
predate
the
update.
I
mean
yes,
there's
always
work
for,
like
compatibility
to
make
sure
you
don't
break
everything,
but.
D
You
know,
that's
that's
the
deal
right.
It
would
break
everything.
This
is
I.
I
think
this
is
somewhat
existential
right,
I
think!
Well,
if
you
require
that
for
interoperability,
all
node
identifiers
have
to
essentially
be
48
bytes
up
to
48
bytes
in
length.
Then
that
I
think
the
I
think
the
problems
are
significant
right.
D
A
D
A
D
D
A
A
I
know:
Scott
put
a
post
onto
the
mailing
list.
I
did
not
respond
to
I'm,
going
to
take
an
action
to
put
a
new
revision
of
this
draft
out.
I'll.
Take
you
on
board
all
the
comments
that
have
been
made
on
the
mailing
list,
while
I
was
on
vacation
and
the
latest
comments
and
I
will
get
that
out
pretty
promptly
and
hopefully
get
more
conversation
on
the
list
at
this
point
and
see
what
people
think
if
somebody
Scott
maybe
wants
to
start
actually.
Scott
has
started
a
thread
about
that.
B
B
A
Otherwise,
thank
you
all
very
much
for
your
patience
and
before
me.
Techo
just
kills
us
because
we're
five
minutes
overdue.
Thank
you
very
much
can
I
say
a
personal
thank
you
to
carsten
for
the
markdown
tool
I'm
using
for
this
cram
down
RFC
tool.
It's
very
very
good.
Those
of
you
who've
never
used
it
before
big
personal
thumbs.
Up
on
on
that
cast,
and
thank
you.
Thank
you
for
my
own
news.
Only
you
could
tell
it's
a
tool.
A
That's
been
written
by
someone
who
has
a
need
to
to
write
rfcs
quickly
in
markdown.
It
works
really
nicely
I've,
never
never
doing
anything
with
any
of
the
other
XML
stuff,
so
I'm
now
waffling
now.
Thank
you.
All
very
much
I
will
see
you
all
in
London
ietf115,
hopefully
in
person,
hopefully
in
person,
if
not
virtually,
and
let's
keep
the
conversation
going
on
the
mailing
list.
Thank
you
all
very
much,
I
sure,
love
you
and
leave
you.