►
From YouTube: IETF111-6MAN-20210727-1900
Description
6MAN meeting session at IETF111
2021/07/27 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
We
essentially
uploaded
them
to
meet
echo
before
the
session
started
and
we're
going
to
try
to
have
each
speaker
share
the
slides
themselves
and
pick.
You
know,
pick
the
presentation
from
the
list
and
then
the
speaker
can
advance
the
slides
themselves.
If
this
doesn't
work,
we
the
chairs,
can
share
the
slides.
So
when
you
you
know,
you
should
click
on
the
share,
pre-loaded,
slides
and
select
your
presentation
from
the
list
and
we
they
should
all
be
there.
We
believe.
B
Please,
oh
sorry,
that's
me
yeah
yeah!
Unfortunately,
we
can't
share
the
controls.
Norm
is
awaiting
right
up.
We
have
the
longest
adoption
call
in
history.
That's
still
stuck
awaiting
the
spring
outcome.
There
was
for
those
who
participated
in
the
spring
meeting
yesterday,
you're
probably
more
up
to
date
than
than
I
am
we'll
we'll
see
how
what
the
outcome
will
be
of
that
we
have
one
working
group
document,
it's
the
minimum
path
empty
or
by
op
option.
B
A
D
D
A
A
Yeah,
so
I
can
do
this,
so
the
basic
operation
is
that
routers
compare
the
minimum
path,
m2
field,
the
configured
mtu
of
the
outgoing
link,
if
it's
less
you
rewrite
it,
and
that
going
going
from
source
to
destination
should
result
in
the
minimum
path
mtu
being
delivered
to
the
host
hosts
will
originally
fill
in
the
minimum
field.
With
the
mtu
of
the
out.
You
know
the
configured
mt
with
the
their
outgoing
link
for
the
packet
and
you
can
set
the
return.
A
Field
to
the
cash
value
cash
value
of
the
reported
mtu,
essentially
the
last
one
you've
received-
and
you
may
also
request
that
the
destination
host
return,
the
minimum
path
mtu
by
setting
the
r
flag
and
host
receiving
this
save
the
minimum
path
mtu
for
the
flow
and
if
the
r
flag
is
set,
include
the
minimum
path
in
the
next
outgoing
packet
for
the
flow,
and
so
that's
the
basic
operation.
The
draft
goes
into.
I
think,
a
lot
of
detail
about
considerations
for
doing
this
when
to
do
it,
which
packets
to
put
it
in.
A
So
I
think
this
is
it's
gonna
be
a
short
presentation.
We
believe
the
document
is
stable.
The
current
draft
is
was
limited
to
editorial
changes.
We
have
done
some
testing
and
implementation.
Wireshark
is
shipping.
You
know
description
so
code
in
the
production
release
that
will
display
these.
We
haven't.
There
was
an
ian,
a
temporary
code
phone
allocated,
and
so
we
would
like
to
request
working
group
last
call
on
this.
A
E
D
Defined
currently
in
3168
is
standards
track
and
the
new
work
we're
doing.
The
ietf
on
l4s,
which
is
a
second
generation
ecm,
is
going
to
be
experimental
until
it's
been
deployed
and
we
have
deployment
experience
so
I'm,
unfortunately
unable
to
help
on
this.
The
first
version
was
prosperous
standard.
The
second
version
of
ecn
is
put
forward
as
experimental,
so
I
thought
it.
D
E
D
Okay,
alfresco's
experimental,
because
the
original
ecn
appears
to
be
more
of
an
experiment,
and
we
could
talk
at
length
of
this
and
we
think
another
revision
of
the
specs
would
be
good
for
l4s
in
the
transport
area.
So
l4s
is
experimental
and
will
hopefully
become
proposed
standard
in
a
year
or
two.
D
B
F
Whenever
you
start
proposing
modifications
to
what
is
effectively
a
widely
deployed
protocol,
you
have
to
figure
out
that
not
everyone
is
going
to
do
this
overnight
and
the
mechanism
that
you're
describing
here
appears
to
work
effectively.
If
every
single
router
on
the
path
actually
supports
that
option,
but
they
won't
and
not
in
a
million
years,
will
that
happen,
and
so
the
real
question
is:
how
effective
is
this
under
partial
deployment
and
does
the
draft
even
argue
what
mitigations
can
take
place
if
the
information
you
get
back
is
basically
faulty
because
of
partial
deployment
thanks.
A
Well,
the
jeff,
thank
you.
The
the
draft
does
go
actually
discusses
this
and
I
think
it's
our
gory
and
ours
expectation
that
there
will
be
mixed
implementations
of
this
for
a
while,
and
the
draft
argues
that
any
and
for
most
any
information
you
get
is
helpful
to
the
transport.
Do
you
want
to
talk
about
that
more
glory.
D
Are
you
using
the
plp
mtud
version
of
the
spec,
the
plp
mtud
needs
hints
to
know
what
to
probe,
for
this
is
a
really
good
hit
to
probe
for
something
there's
no
way,
you
will
ever
know
what
a
ethernet
switch
or
layer
2
device
is
going
to
do
on
your
path
or
what
mtu
that
might
have.
So
we
can
never
have
really
good
information.
So
the
only
really
good
information
to
prevent
black
holing
is
to
probe.
D
E
The
one
thing
I
would
be
worried
about
in
general-
and
unfortunately
I
don't
have
practical
experience
much
with
ipv6,
but
is
that
you
know
routers,
even
if
they
don't
understand
the
option
by
pure
having
an
extension
header
in
package
that
previously
didn't
have
one
are
punting
these
packets
and
therefore
forwarding
them
slower,
and
that
may
create
undesirable
churn
right.
So
I'm
not
quite
sure
how
to
probe
for
this
effectively
on
the
internet,
because
I
think
you
know
the
big
risk
of
this.
E
Is
it's
so
attractive
that
you
know
people
would
want
to
put
it
over
internet
path
and
so
some
some
thoughts
about
trying
to
do
experiments
figuring
out.
If
there
are
performance
impacts.
I
think
that
can
be
seen
by
a
higher
latency
because
of
hunting
and
so
on.
I
think
that
would
be
really
helpful
to
vet.
You
know,
then,
also
whether
to
make
it
for
that
reason,
experimental
as
opposed
to
standard.
D
Yeah
tallest
the
drafts
suggest
that
you
actually
probe
the
path
occasionally
like
you
would
do
with
other
path.
Mtu
probes.
So
you
wouldn't
add
this
to
every
packet.
You
would
add
it
probably
to
a
sacrificial
packet
that
you
know
might
be
dropped
because
some
people
drop
packets
with
extension,
headers
so,
and
I
would
see
very
few
packets
carrying
this.
If
you
want
to
use
it
to
advantage
just
a
few,
maybe
at
the
start
of
the
flow,
maybe
periodically
as
a
keeper
life.
E
B
Do
you
think
we
have
two
more
presentations
after
this
which
goes
on
that
topic
a
little
bit
and
there
was
also
a
presentation
on?
Was
it
idea,
110
or
109?
You
know
when
this
document
was
presented
with
with
some
experimental
results
as
well,
and
we
have
updated
8200
to
say
that
you
know
you
should
not
punt
for
whatever
that
means
in
a
particular
platform
jen,
do
you
want
to
go
ahead.
G
First
of
all,
how
does
the
host
know
that
it
should
send
as
this
option
for
this
destination,
because
this
is
in
controlled
environment
and
shouldn't
be
using
an
internet
in
general
because
I'm
afraid,
if
host
starts
using
it
for
all
destinations,
it
might
cause
trailers,
especially
as
drafts
are
used
in
in
tcp
scene,
so
that
still
will
be
dropped.
We'll
be
seeing
more
api,
both
failures
as
a
result
right,
I
am
afraid,
because
the
tcp
connection
over
this
pics
wouldn't
be
established
and
it
would
fall
back
for
before.
G
A
Jen,
thank
you.
That's
a
good
comment
and
I
assume
you're
responsible
for
the
seagulls
in
the
background
so
yeah
I
we
had
the
the
first
version
of
the
draft,
I
think,
had
the
notion
of
controlled
environments,
but
I
think
that
does
need
to
get.
I
mean
that
that
would
be
very
good.
Last
call
comment
that
I
think
we
could.
We
could
address.
B
So,
at
least
from
from
my
perspective
as
the
chair
for
this
document,
I
think
I
think
the
next
step
here
would
be
to
last
call
the
document
and,
and
then
he
got
any
of
these
issues,
and-
and
I
mean
you
know,
if
we
choose
to
publish
it,
it
will
you
know
this
is
probably
the
first
hope
I
hope
option
that
has
a
wide
applicability
and
it
will
have
you
know
that
set
of
questions
mark
mark's
coming
with
it.
I
think,
but
I
might
be
you
know
you
know.
B
B
A
A
D
A
No,
I
completely
agree,
so
I
guess
I
can
do
the
introduction
I
mean
so,
as
I
think
is
very
well
known.
Hop
up
options
are
not
working
very
well
on
the
internet.
It's
very
common
for
riders
to
drop
packets
with
hot
pipe
options.
It's
a
probably
a
great
firewall
feature,
and
so
the
conclusion
here
is:
we
need
to
do
something
different.
We
expect
hop.
I
hop
options
to
be
useful
in
the
you
know
in
the
future,
and
anything
we
do
is
not
going
to
magically
change
the
internet
instantly.
A
A
A
This
is
a
I
think,
a
topic
for
debate.
We,
I
think,
gorey-
and
I
are
very
we'll-
be
very
happy
to
change
this
to
something
else.
If
the
working
group
can
agree
on
it
or
something,
but
for
the
in
the
meantime,
we'll
use
these
these
words.
But
it's
you
know,
I
don't
think
that's.
This
is
the
the
key
element
in
this
document,
but
we
just
needed
a
way
of
talking
about
these
ideas
of
you
know:
there's
a
fast
hardware,
usually
hardware
based
processing
path
and
routers,
and
then
there's
one.
A
A
A
Inability
to
process
it
wire,
speed
and
hardware
packets
sent
to
the
slow
path,
would
degrade
router
performance
and
could
be
used
as
a
denial
of
service
attack
package.
You
know
there
was
no
limit
on
the
number
of
hop
high
up
options
or,
as
tom
will
talk
about
later
today,
the
size
of
the
number
of
hop
I
have
options
or
extension,
header
options,
etc,
etc.
A
It
was
a
nice
idea
at
the
beginning
in
8200
this
was
changed.
A
bit
changed
that
you
only
had
to
do
hop,
high
options
if
you
were
configured
to
do
so,
and
this
essentially
documented
the
current
operational
procedure,
but
didn't
improve
the
processing
of
pop-up
options,
and
there
was
some
ambiguity
in
the
text
in
8200.
If
this
was
talking
about
all
options
or
individual
ones,
I
guess
if
you
treat
it
as
all
it's
sort
of
the
same,
but
it
could
have
been
a
little
more
precise.
I
think.
D
D
Probably
a
big
ask
for
people
to
do
all
of
these
all.
At
the
same
time,
they
could
be
used
as
a
dos
attack,
not
that
you'd
ever
want
to
do
this,
but
some
people
might
inject
packets
just
to
create
fun
for
the
routers
make
them
run
slow.
You
put
them
on
the
slow
path.
They
really
do
make
it
into
a
slow
router.
D
D
The
goal
is
to
redefine
and
make
hot
my
hop
options
practical.
So
that
you
can
actually
use
a
hot
hot
option
along
your
path
to
do
something
useful,
the
caveat
being.
We
can't
change
the
whole
internet
by
writing.
One
rfc
be
nice,
but
it
doesn't
work,
so
it
likely
won't
work
for
all
paths.
It
likely
won't
work
for
all
routers,
but
we
believe
that
methods
can
be
defined,
such
as
the
path
mtu
option.
We
talked
about
the
other
methods
as
well.
D
D
Well,
okay,
so
the
most
yeah,
the
most
important
is
the
second
bullet,
and
we
need
terminology-
and
it's
clear
from
doing
this-
that
good
terminology
is
lacking
and
one
of
our
area
directors
helpfully
said
we
did
choose
the
terminology
right,
it's
probably
true,
so
we
need
better
terminology
for
this.
We
will
just
accept
other
offers
of
better
terminology.
A
A
You
know
only
hop
only
fast
path,
processing,
no
nothing
goes
to
the
sole
path
period,
only
one
option
just
fast
path,
but
there
was
some
pushback
or
other
comments.
That
said,
you
know,
having
some
ability
for
for
things
like
router
alert
might
still
be
useful,
so
we
change
so
this
version
of
the
draft
talks
about
you
know
you
process
at
least
one
option
you
may
process
more,
but
the
one
exception
to
fast
pass
processing
is
the
router
alert
which
sends
the
whole
packet
to
the
slow
path.
A
I
J
So
in
some
of
the
discussion
on
the
list,
especially
about
the
second
bullet
that
hop,
I
hop
option
must
be
processed.
There
was
a
lot
of
question
whether
or
not
that's
practical,
because
we
have
a
lot
of
deployed
routers.
That
may
just
ignore
all
the
hop
by
hop
options
which
would
actually
be
conformant
with
rfc.
A
A
So
you
we
have
a
couple
slides
which
we'll
do
really
quickly,
which
is
basically
the
summary
of
the
proposal.
As
you
know,
in
the
current
draft
you
know
it's
that
first
half
pipe
option
must
be
processed
in
the
fast
path.
Additional
popeye
options
may
be
processed
if
configured
with
the
one
exception
being
the
router
alert
nodes.
Creating
packets
with
hotpie
options
should
include
a
single
option.
They
may
include
more
based
on
local
configurations.
Obviously,
you'd
want
to
only
do
that
if
you
had
some
idea
that
the
nodes
along
the
path
might
process
them.
A
And
if
there,
if
there
are
more
than
one
hop
up
option
in
the
option,
header
a
node
may
skip
the
rest
without
actually
looking
at
them,
so
she's,
not
processing
or
verify
them
just
skip
over
the
the
op
option.
Option
header
has
a
length
in
it,
so
you
can
do
this
without
actually
looking
at
what's
inside
and
if
you
can't
process
a
particular
option
in
the
fast
path,
you
must
treat
it
as
an
unrecognized
option.
A
The
other
change
was
in
the
zero
draft.
We
basically
eliminated
all
ability
to
send
an
icmp
parameter
problem.
We
got
a
bunch
of
comments
on
that,
and
so
we
changed
it
to
that.
You
may
send
an
icmp
parameter
problem,
so
the
ability
to
do
that
is
still
there,
but
you're
not
required
to
do
it
as
you
are
in
8200.
M
D
A
So
one
of
the
it'll
show
up
in
the
issue
slides.
We
did
recently
realize
from
looking
thinking
about
the
draft
that,
if
you
have,
if
you
have
pop
up
options,
that
don't
need
to
be
in
ever
every
packet,
this
approach
works.
Well,
if
you
have
an
option
that
is
required
to
be
in
every
packet
in
the
flow,
then
that's
going
to
make
it.
You
know.
If
it's
the
first
option,
then
it
may.
A
L
Deal
with
that
in
the
draft,
then
it
may
not
be
a
show
stopper.
It's
just
a
situation
that
I
expect
to
come
up,
and
so,
if
you
say
well,
if
you,
if
you
think
you
need
to
be
first
for
some
reason,
then
consider
not
being
required
in
every
packet
so
that
other
ones.
You
know
some
language
like
that
that
you
mentioned
great.
L
I
B
E
You
know
the
must
be
processed
how
about
new
first
hop.
I
hop
options
right
things
that
haven't
been
defined
up
to
a
certain
point.
Right
I
mean
changing.
Existing
behavior
is
always
difficult,
but
for
new
ones,
let's
say,
for
example,
that
new
mtu
thingy,
you
know
much
easier.
I
think,
to
get
the
most
accepted.
O
Yeah,
I
mean,
I
guess,
just
sort
of
a
reminder.
I
guess
that
one
of
the
reasons
that
a
lot
of
people
are
not
doing
stuff
like
this
on
the
fast
path
is
because
of
the
complexity
and
cost
of
doing
so,
and
simply
saying
you
know
you
must
be
able
to
handle
one
of
them
without
bounding.
The
complexity
doesn't
really
change
that
equation.
Very
much.
O
You
know.
Maybe
you
don't
have
to
do
five
or
six
or
ten
of
them,
but
you
still
need
to
know
how
to
handle
the
ihop
option
in
the
fast
path.
So
you
have
to
design
and
build
the
capability
into
the
asic.
You
have
to
design
and
build
into
the
hardware.
You
don't
have
to
loop,
the
pack
around
five
or
six
times,
but
you
still
have
to
know
how
to
actually
process
that.
D
A
Yeah
I
mean
8200,
and
this
draft
also
do
talk
about
per
option
configuration
about
whether
they're
supported
and
what
to
do,
if
they're,
not
so,
I
think
options
which
are
options
which
are
complicated
or
long
or
whatever
are
not
going
to
be
widely
supported.
I
think
that's.
The
challenge
for
creating
popular
options
need
to
have
a
compelling
use,
which
is
not
something
we're
addressing
here.
It's
hard
to
do
that,
but
I
think
that's
a
reality.
P
We
said:
okay,
like
we
made
it,
I
should
to
put
it
as
the
first
option,
because
at
some
point,
like
you
know,
we
know
like
people
are
not
going
to
look
past
x,
number
of
options
and
most
likely
the
x
is
going
to
be
one.
So
I
I
I
think,
like
you
have
some
text
for
this
like
to
say,
like
hey:
don't
do
it
on
every
packet
could
be
very
useful
and
the
reference
for
that
is
out
of
c7837.
K
K
K
Plane
was
very
different,
and
what
we
can
do
today
is
quite
different,
so
we
need
to
update
what
we're
doing
taking
it
into
account
the
much
more
powerful
processing
that
we
have
and
the
much
much
bigger
requirements
that
we
have,
and
the
second
thing
is,
if
you
do
have
multiple
hop
by
hop
or
or
end
to
end
things
in
the
in
the
stack
or
after
the
stack,
how
much
of
it
should
be
processed?
How
much
of
it
must
be
processed?
How
much
of
it
you
know,
may
be
processed?
K
If
you
can't
process
it,
do
you
throw
the
packet
away
and
so
on?
I
just
want
to
bring
this
to
this
group,
because
ron
and
I
have
talked
about
hop-
I
hop
options
in
ipv6,
but
I
see
this
parallel
between
them.
So
even
for
the
terminology,
you
know,
do
you
want
to
talk
about
fast
path?
Slow
path,
do
you
want
to
talk
about?
You
know?
How
do
you
want
to
talk
about
capabilities?
K
How
much
should
be
done
or
must
be
done?
How
much
may
be
done
so
there
is,
I
think,
some
commonality,
and
I
think
it's
worthwhile
to
at
least
for
for
the
authors
of
these.
We
have
a
design
team
in
the
mprs
working
group
to
say:
okay,
here's
some
things
that
we
do
have
in
common
here,
something
that
are
very
specific
to
our
particular
way
of
doing
things.
A
B
A
Yeah,
so
this
is
just
finishing
up
what's
in
the
current
draft,
so
the
draft
currently
says
you
know
that
router
alert
the
node
should
verify
that
the
router
alert
contains
a
supported
protocol.
The
router
alert
format
says
what
here's
the
thing
you
should
be
looking
at,
and
so
obviously,
if
you
can't
do
that
in
the
slow
path,
then
don't
send
it
to
the
sole
path,
and
so
only
verified
package
should
be
sent
to
the
slow
pack.
A
I
think
this
helps
a
little
bit
and
obviously,
if
you're
going
to
do
router
alert
processing,
you
must
protect
yourself
from
infrastructure
attacks.
It's
you
know
we're
trying
to
if
we're
going
to
keep
this,
and
so
that's
with
that
I'll.
Unless
there's
a
comment
on
this
I'll
go
to
the
next
slide,
which
sort
of
covers
that
as
well.
B
Q
Do
you
hear
me?
Yes,
yes,
okay,
I
have
a
clarification
question.
I'm
just
trying
to
understand
if
some
particular
vendor
will
implement
six,
for
example,
options
in
fast
path,
but
just
one
option
in
slope:
up,
for
example,
just
a
situation
yeah
and
because
from
from
this
draft
it
will
have
must,
and
one
option
is
not
implemented
as
a
must
doesn't
mean
that
this
vendor
is
not
qualified
as
properly
supporting
abv6.
Q
A
Well,
we
continue
the
notion
that
you
know
each
that
a
router
will
have
a
configuration
table
for
which
options
it
does
in
the
fast
path,
and
obviously
you
can
set
that.
So
you
do
none
and
I
would
think
that
would
be
compliant
with.
With
this
I
mean
the
other
thing
about
this
is
this
is
a
proposal
that
would
be
if
it
goes,
you
know
once
it
gets
through
the
whole
if
it
gets
through
the
whole
process.
A
Q
A
Q
D
D
This
doesn't
change
the
ipv6
core
spec,
it's
something
in
addition
that
that
we
hope
will
make
things,
work
and
we'd
love
to
get
more
feedback
on
the
wording.
Really,
we
thought
a
lot
about
the
busts
and
shuts-
and
if
you,
if
you
start
discussing
with
us,
we'll
we'll
happily
look
again
at
any
of
them,.
B
S
Yeah
thanks,
I
I
sort
of
understand
the
dance
you're
doing
with
router
alert,
especially
because
there
are
protocols
out
there
that
use
it,
but
I
I
wanted
to
make
sure
you
had
read
and
digested
rfc
6398,
which
yeah
I
know
we
there's
only
there's
only
9
000
odd
rfcs
out
there,
and
I
don't
know
why
you
don't
know
them
all
by
heart.
6398
basically
recommends
against
wide
use
of
router
alert
and
in
particular
against
using
it
in
new
protocols.
E
To
to
to
to
jump
onto
what
adrian
said-
and
I
also
read
that
I
know
all
the
9000
rfcs
so
the
yeah.
My
conclusion-
I
repeated
that
on
a
couple
of
mail
threads
for
this
is
that
you
know,
if
you
want
to
do
you
know
better
router
alert
functionality,
even
in
the
spirit
of
router
alert.
I
think
we
should
have
a
new
hop
by
hop.
E
T
T
A
E
You
yeah,
actually
I
mean
in
multicast.
We
had
two
other
protocols
that
we're
using
and
still
you
know,
supposedly
on
on
the
functionality
use,
router
alert
right.
One
is
pgm
which,
basically,
whose
deployment
got
pretty
much
killed
by
exactly
that
router
alert
implementation
issue.
So
that's
why
we
got
very
annoyed
about
the
you
know:
insufficient
specification
of
router
alert
to
you,
know,
mandate,
fast
path
or
so,
and
the
other
one
is
rsvp
right
and
in
rsvp.
E
In
the
meantime,
as
kiriti
was
pointing
out,
we
have
much
better
hardware,
so
you
know
there
are
100,
gigabit
and
faster.
You
know
fast
pass
processing
of
similar
functionality
as
rsvp
to
set
up
flow
state,
so
that
would
obviously
be
exactly
something
good
for
a
new
hop
by
hop
option
to
do
so
yeah.
Maybe
it
will
end
up
being.
You
know
that
we're
obsoleting
all
the
old
users,
because
router
alert
simply
you
know,
got
you
know
badly
specified
badly
implemented
and
we've
got
to
let
go
of
it.
C
A
I
think
you're
free
to
continue.
Thank
you.
A
lot
of
the
next
slides
we've
been
talking
about,
but
so
the
there
is
a
section
in
the
document
about
new
hop
options.
The
you
know.
So
we
had
some
ideas
of
of
this,
but
I
think
in
this
discussion
I
think
this
section
will
get
expanded
because
I
think
there's
more
to
it,
but
you
know
I
guess
the
other
way.
I
would
say
this
is
any
hop.
I
hop
option
that
is
going
to
be
used
or
implemented
widely
has
to
be
compelled.
A
It
has
to
solve
a
compelling
problem
because
otherwise
I
doubt
people
are
going
to
do
it
in
the
fast
path.
So
this
this
will
always
be
a
challenge.
Okay,
next
slide.
So
this
is
a
summary
of
the
issues
that
were
raised
on
the
mailing
list
after
we
published
the
draft.
I
think
many
of
these
we've
addressed
but
feel
free
to
jump
in
you
know,
there's
the
question
of
what
terminology
to
use
in
the
draft.
A
You
know,
I
don't
think
it's
the
an
objection
to
describing
it.
I
think
what
is
the
best
word,
so
we
don't
want
to
get
too
caught
up
on
that,
but
we're
quite
welcome
looking
for
someone
to
tell
us
what's
the
best
thing
to
use.
If
you
can
get
agreement
on
it,
then
one
big
issue,
I
think
that
was
raised
and
caused
there
to
be
a
lot
of
comments,
because
the
document
is
not
completely
clear.
A
K
A
E
J
B
A
A
If
this,
if
what
we're
proposing
is
adopted,
I
think
that's.
We
should
probably
talk
to
v6
ops
about
the
relationship
and
question
about
which
we've
somewhat
talked
about.
Can
existing
deployed
equipment
implement
this
proposal,
probably
not
where
I
think
this
is
really
focused
on
revised
equipment,
updated
equipment
which
does
happen.
It's
not
we're
not
expecting
publishing
an
rfc
is
going
to
change
the
deployed
base
and
then
the
question
thing
we
just
talked
about
that
they've
raised.
You
know
any
hop.
I
hop
option
that
needs
to
be
in
every
packet
in
the
flow.
A
A
A
You
know,
needs
to
work,
even
if
packets,
without
hop
high
options
are
delivered,
so
something
that
you
know
if
you
can't,
if
they're
not
processed,
then
it's
not
going
to
work.
Well,
it's
not
going
to
work
in
today's
world
and
probably
even
the
future
world
you
you
have
to
be.
You
have
to
use
this
to
supplement
what
you're
doing
and
then
there's
a
question
about
overall
limits
on
the
number
and
size
of
extension
headers,
including
hoppe,
hop-
and
I
think
tom
is
going
to
be
talking
about
that
later
today,
okay
and
last
slide.
A
So
thank
you
all
for
feedback
corey
and
I
think
six
men
should
adopt
this
as
a
working
group
document
our
take
is
there
is
interest
in
working
on
this.
You
know
this
is
a
question
for
adoption.
It's
not!
You
know.
We
expect
the
document
to
change
considerably,
perhaps
based
on
working
group
feedback,
but
we
think
we
can
work
through
the
issues
on
the
mailing
list
once
it's
adopted
and
we
sort
of
to
state
the
contrary.
A
B
Up
excellent,
thank
you
bob
and
gory.
It
sounds
like
the
next
step
here
is
to
do
a
call
for
adoption
on
this
document
I'll
put
that
on
the
list
of
action
items
from
this
meeting.
If,
if
no
one
disagrees
very
violently
with
that,
they
can
of
course
do
that
on
the
main
list,
too
excellent
as
well.
Indeed.
B
J
J
The
problem,
I
think,
was
already
articulated,
so
extension
headers
have
not
been
doing
well
and
a
major
reason
for
that
is
kind
of
what
we
were
talking
about
before
processing
tlvs
processing
variable
length.
Headers
is
hard
to
do,
especially
in
hardware
and,
as
bob
mentioned
one
of
the
problems
or
this
problem
was
exacerbated
by
the
fact
that
when
we
defined
extension
headers
in
rsu,
2460
and
8200,
we
really
didn't
put
any
limits
on
them.
J
So
I
agree
with
the
consensus
from
the
last
set
of
authors.
We
need
to
do
something
to
save
extension
headers,
so
the
solution
that
I'm
outlined
today,
we
want
to
specify
some
limits,
practical
limits
that
may
be
applied
to
that
extension.
Headers
and
there's
really
two
goals
to
this
one
is
we
want
to
make
them
practical
so
that
we
can
actually
efficiently
implement
them,
but
on
the
other
hand,
we
don't
want
to
restrict
the
functionality.
J
J
There's
a
rc8
a3
some
icmp
errors
for
drops,
but
I
would
point
out:
rfc
8504
lim
host
requirements
actually
does
mention
some
specific
extension
header
limits
applied
to
host
receiving
so
in
some
sense
we're
expanding
on
that,
and
I
would
also
say
that
the
hapa
hop
options.
Processing
that
we
just
saw
is
probably
a
subset
of
this.
This
draft
more
addresses
the
the
larger
problem
with
hopi
hop
options.
J
J
J
So
they
don't
see
the
transport
layer
and
in
some
cases
they
arbitrarily
drop
the
packet
because
they
have
this
limited
capability.
Another
important
consideration
is
public
internet
versus
limited
domains,
so
kind
of
a
simple
rule.
When
we're
playing
this
our
robustness
principle,
if
we're
sending
to
an
anonymous
destination,
the
public
internet
apply
the
most
restrictive
limits
when
we're
sending
into
a
limited
domain
limits
can
be
relaxed.
J
One
important
thing
about
that
is
a
lot
of
extension,
headers
some
of
the
extension
headers
some
hobby
hub
options.
I
guess
some
destination
options
really
are
intended
only
for
limited
domains,
which
means
having
kind
of
global
limits
should
not
affect
this.
So,
for
instance,
segment
routing
would
almost
certainly
exceed
any
any
limit
that
we
could
say
that
we
want
to
send
into
the
internet
in
terms
of
number
of
bytes
in
an
ip
header
length
chain.
J
So
the
types
of
or
the
application
of
limits
is
important,
so
we
have
one
case
ascending
limits
that
only
the
host
sends
extension
headers
and
then
we
have
to
consider
three
dimensions
of
receivers
and
for
each
of
these
we
can
apply
limits
and
then
an
important
question
is
for
each
of
these
senders
or
receivers.
What
is
the
behavior
when
the
limit
is
exceeded
so
for
host
sending
extension
headers?
J
This
is
just
simply
here's
the
limits
that
the
host
is
allowed
to
send,
so
they
can
send
packets
with
five
bytes
or
some
number
of
bytes
of
extension,
headers
some
number
of
hot
by
hop
options.
Sending
limits
are
are
typical
like
that
and
then
in
the
receiving
case
we
consider
the
host
receiving.
So
again
this
was
kind
of
covered
by
rfc
8504.
I
believe
so.
Host
must
process
all
extension,
headers
and
options
we're
assuming
that
the
behavior
when
a
limit
is
exceeded
that
the
host
applies
would
be
to
drop
the
packet.
J
A
router,
on
the
other
hand,
is
an
intermediate
node,
never
a
destination,
so
really
limits
primarily
apply
to
hot,
by
hop
options.
The
behavior
that
we
expect
there
is
to
ignore
data
beyond
the
limit,
so
this
also
correlates
to
rc8200,
where
routers
can
ignore
all
hotba
help
options.
The
important
distinction
here
is
that
we
don't
want
routers
to
drop
packets
with
hop
options
that
they
don't
understand
or
can't
process.
J
However,
if
there's
a
destination
option
before
the
routing
header
that
exceeds
a
limit
being
applied
by
an
intermediate
destination,
we
would
basically
drop
the
packet.
The
rationale
is
that
a
destination
is
actually
explicitly
addressed
by
the
sender,
so
this
is
the
sender's
intent
that
these
options
be
processed
by
those
explicit
destinations.
J
One
of
the
more
important
ones
is
the
next
slide.
This
is
the
header
chain
limit
that
I
mentioned.
So
the
draft
specifies
this
as
a
host
must
not
send
a
packet
with
the
length
of
the
extension
header
chain
greater
than
104
bytes,
and
this
is
derived
from
the
fact
that
we
expect
that
routers
and
devices
intermediate
nodes
should
at
least
support
128
bytes,
minimal,
parsing
buffer,
which
means
they
should
be
able
to
process
at
least
128
bytes
of
headers.
J
There
is
some
evidence
that
suggests
that
current
commonly
supported,
we
do
have
anecdotal
information.
I
don't
think
anyone's
ever
done
an
actual
measurement
on
the
internet,
but
I
would
also
point
out
less
than
that,
if
we
don't
have
at
least
128
bytes
extension
headers
probably
aren't
viable
at
all.
J
So
this
is
a
kind
of
a
hard
limit
that
we
would
want
to
make
a
requirement
and
again
the
problem
isn't
so
much
that
if
we
we
have
these
large
headers
that
we
can't
process
the
extension
headers
themselves.
The
problem
again
is
large.
Headers
could
push
the
transport
layer
too
deep
in
the
packet
such
that
routers
that
need
that
information
can't
get
to
it.
G
H
J
Can
we
can
we
defer
that?
I
do
have
some
comments
on
that
in
a
couple
of
slides,
thank
you
so
receiving
limits.
These
are
kind
of
similar
to
the
sending
limits
and
again
already
those
are
basically
based
on
rc
8504.
We
just
extended
that
so,
for
instance,
a
number
of
non-padding
destination
up
options
and
hoppy
hop
options
would
default
to
eight
and
then
maximum
lengths
of
headers
maximum
lengths
of
number
of
options
limits
on
the
ipv6
header
chain
length.
J
So
we
have
a
a
limit
here
which
basically
says
that
a
router
can
process
some
number
of
options,
basically
zero
to
the
number
of
options
in
a
packet.
So
in
this
draft
we
say
that
the
requirement
is
that
a
device
can
process
between
zero
up
to
the
number
of
options.
If
they
process
something
less
than
the
number
of
options
but
greater
than
zero,
then
we
expect
it
to
be
the
first
consecutive
n
options
that
they
would
process
so
rc
2460
basically
specifies
that
n
equals
all
the
options.
J
So
we
we
said
that
all
routers
must
process
all
options
all
hop
by
hub
options:
rc
8200
change
that
either
n
can
be
zero
or
a
little
ambiguous.
But
apparently
I
think
it
interprets
that
either
you
can
process
zero
of
them
or
all
of
them
and
then
in
the
last
graph
we
talked
about.
Basically
that
makes
n
greater
than
one.
So
at
least
one
option
would
need
to
be
process.
E
More
like
a
comment,
so
I
I
I
take
it
50
50
right,
so
I
think
the
the
analysis
of
what
is
likely
feasible
in
specific
contexts-
or
so
I
think
is-
is
really
great.
You
know
analysis
and
information
for
people
trying
to
build.
You
know
extension,
headers
and
combinations
of
extension.
Headers
that,
hopefully
could
be
deployed
in
you
know
limited
domains.
E
On
the
other
hand,
putting
any
of
this
analysis
into
recommendations
in
in
the
form
of
must
and
should,
or
so
I'd
be
very
scared
about
doing
that
right
now,
given
how
we
have
such
a
wide
range
of
different
type
of
devices
right
data
center
devices
are
totally
different
than
you
know:
metropolitan
routers,
then
iot,
routers
and
so
on.
Right,
and
you
know,
I
think,
the
the
one
thing
that
is
just
you
know
as
januko
was
saying
you
know.
E
If
we,
if
we
do,
have
a
control
plane,
you
know
that
can
figure
out
what
a
particular
path
can
do
and
orchestrate
this
stuff.
Then
I
think
why
do
we
want
to
have
any
generic
limitations?
And
maybe
you
know
we
should
rather
start
from
having
you
know
better
understanding
of
what
you
know
may
be
possible
and
and
then
you
know
for
the
deployment
say
well,
you
know
your
control
plane
must
you
know
be
able
to
to
tell
you
what
what
can
be
done,
what
you
can
do
there.
J
J
J
Basically,
a
node
can
completely
ignore
them
and
and
still
be
conformant
and
one
other
thing
that's
important,
you
know
to
understand
is
there's
no
such
thing
as
100
percent
support
on
the
internet
for
pretty
much
anything
the
ability
to
pull
and
or
the
ability
to
use
a
mashup
map
of
the
internet
capabilities
or,
if
I
know
I'm
in
a
restricted
domain,
that
is
that's
significant
information
right
and,
and
I
think
that
that
should
be
part
of
it.
I
would
be
a
little
and
so
on
on
the
public
internet.
L
I
have
two
related
questions,
so
I'll
ask
the
first
question
and
then
I'll
have
a
follow-up
based
on
the
answer
this
one.
So
you
talked
about
how
the
primary
problem
we're
trying
to
solve
was
where
routers
and
intermediate
nodes
need
to
deal
with
things
in
the
transport
header,
and
they
need
to
be
able
to
find
that
transfer
here.
My
question,
the
first
question
I
should
say
is:
do
you
consider
ipsec
a
transport
header?
L
In
other
words,
do
you
is
there
any
problem
with
routers
that
try
to
try
to
find
things
past
that
especially
the
first
question
we
take
into
the
encrypted
case?
Is
there
any
known
problems
with
hosts
having
destination
options,
there's
a
large
number
of
them
encrypted
inside
the
end-to-end
esp
session?
And
if
so,
what
are
those
issues
with
hosts?
L
In
other
words,
why
would
you
want
to
say
that
the
spending
node
can't
do
stuff
by
default
when
it's
end-to-end
and
it's
never
going
to
be
seen
by
intermediate
nodes,
because
it's
inside
into
end
ipsec,
for
example?
So
that's
my
first
question,
or
can
you
constrain
this
to
say
we're
only
talking
about
stuff
that
appears
outside
of
you
know
before
an
ipsec
header.
J
L
The
first
piece
is
you're
guaranteed
to
not
be
able
to
find
anything.
Is
there
any
problem
with
putting
a
lot
of
extension
headers
after
that,
because
it's
end-to-end
encrypted
is
the
only
problem
you're
trying
to
solve
for
routers
or
you're
trying
to
solve
any
problem
for
end
hosts
and
if
you're,
trying
to
solve
a
problem
for
in-host,
you
have
any
evidence
that
there
is
a
problem
so.
J
L
My
recommendation
would
be
it
would
be
a
lot
easier
to
discuss
if
you
said
this
is
only
for
stuff
that
appears,
but
before
an
ipsec
header
and
anything
after
that.
That's
up
to
the
end,
and
I
was
probably
because
this
is
you're
trying
it's
not
addressing
the
problem
you're
trying
to
solve
here.
So
that's
my
recommendation
of
my
first
question.
L
J
L
We
should
be
very
judiciously
with
anything
that
would
affect
the
node
requirements.
Rfc,
I
guess
is
my
my
point
there.
My
second
follow-up
question
would
be
especially
if
you're
going
to
ask
v6,
ops
or
whatever
about
routers.
Then
the
same
question
comes
up
when
you're
talking
about
just
a
h
or
esp
null.
In
other
words,
it's
not
encrypted,
but
you
can't
parse
past
it
the
normal
way
and
so
router.
L
It
would
only
affect
routers
if
routers
will
try
to
be
super
intelligent
and
be
able
to
parse
past
ipsec
headers
when
you
don't
actually
have
encryption-
and
there
is
a
transport
header
later
on.
Is
that
a
problem
because
that,
I
think,
is
probably
a
little
bit
of
higher
risk
where
you
might
be
trying
to
address
that
problem,
but
only
those
writers
that
do
that
so.
J
L
J
This
you
know
I-
and
this
is
a
discussion
we've
had
on
v6
ops.
The
implicit
requirement
right
now
from
some
is
that
routers
have
to
be
able
to
parse
into
the
transport
layer,
and
we
point
out
not
all
packets
have
a
transport
layer.
That's
parsable,
I
don't
know
what
that
means
relative
to
this
specification.
J
L
Yeah
yeah,
but
I'm
just
considering
if
there
is
a
case
where
rightfu
stick
is
working
right,
I
think
it
would
be
great
to
not
break
it.
In
other
words,
if
there's
something
that's
working
today
on
the
internet,
don't
tell
a
host
to
change
the
behavior
that
would
break
something
that's
currently
working.
I
get
the
fact
that
the
ipsec
wouldn't
always
work
right,
but
if
you
do
have
a
situation
where
it
is
working
across
some
network
or
some
path
or
whatever
it'd
be
great
to
not
break
things
that
are
currently
current
currently
working.
M
V
So
it
looks
like
the
header
buffer
size
is
a
fundamental
parameter,
just
like
the
mtu,
I'm
wondering
if
there
will
be
some
mechanism
actually
to
query
or
advertise
such
capabilities
to
routers,
so
the
router
or
other
that
the
host
can
decide
or
how
many
headers
they
can
support.
Actually
in
the
package.
That's
just
some
comments.
J
J
So
there
would
be
some
sort
of
mechanism
to
detect
that,
but
the
the
other
point
that
I
would
make
is
the
limits
that
we're
defining
really
should
be
considered
the
baseline,
minimal
limits
and,
like
any
other
sort
of
limits,
manifest
limits
that
we
apply
they
may
be
applicable
today,
but
tomorrow
they
may
not
be.
Hopefully
in
our
case,
the
the
potential
limits
would
only
get
bigger,
not
smaller.
If
they
get
smaller,
then
we
have
a
problem.
H
Download
if
we
do
decide
to
say
something
sensible
about
how
option
processing
should
the
same
document
include
this
some
sensible
recommendations
about
limits-
and,
I
suppose
vice
versa-
is
it
dude?
Does
it
make
sense
to
have
one
document
without
the
other?
Does
it
make
sense
to
have
two
doc?
The
two
documents
together
in
in
one.
J
A
Yeah
we
know
in
the
processing
top
half
processing
document.
We
don't
we
sort
of
mention
they
shouldn't
be
too
big,
but
we
certainly
don't
specify
sizes,
but
the
limiting
it
to
one
or
some
number
probably
reduces
that
as
an
issue
for
hop.
I
hop
options,
but
there
is
some
relationship
between
the
two
drafts.
J
E
I
think
the
question
is
always
what
we're
trying
to
achieve
with
a
particular
document
right,
so
any
any
new
hop.
I
hop
extension
header
that
people
you
know
like
in
functionality
can
always
override
what
any
of
these
generic
documents
are
saying.
But
I
think
that
the
biggest
benefit
of
the
generic
documents
is
trying
to
figure
out.
J
So
I
would
completely
agree
with
that.
I
think
that's
that's.
The
biggest
thing
that's
been
missing
is
some
sort
of
guidance
to
the
hardware
developers,
especially
in
reference
to
to
the
reality
of
deployment,
as
opposed
to
what
the
what
the
specification
says,
which,
as
we
mentioned,
are
so
unlimited.
B
B
So
again,
you
know
this
document.
The
problem
we're
trying
to
solve
with
this
document
is
is
twofold:
it's
it's
one
of
of
process
where
the
working
group
has
spent.
You
know
lots
of
time
on
on
various
configuration
information
options
in
sixth
man,
for
real
advertisements
and
in
the
atp
for
various
dhp
options,
and
what
we're
trying
to
do
here
is
see
if
defining
a
self-describing
option
format
based
on
you,
know,
json
and
cdl
and
zebor,
let's
say
encoded
in
seabor.
B
If
we
can,
then,
to
you,
know
almost
get
away
with
just
having
in
a
ayanna
registry,
defining
the
options
and
also
implementations
could
just
support
the
infrastructure
here.
So
you
could,
you
know,
add
a
new
configuration
option
on
the
router
without
having
to
get
your
vendor
to
change
the
implementation.
There's
also.
B
You
know
it
started
out
as
experimental,
largely
because
of
the
process
issues
to
see
if
it
would
be
beneficial
to
you
know,
bypass
quite
a
lot
or
simplify
lots
of
the
itf
process,
because
we,
you
know
the
idea
for
the
working
group
would
take.
You
know
a
year
or
even
years,
to
define
a
new
option
that
perhaps
you
know
it
was
quite
trivial
to
start
out
with.
So
the
format
again
is
is
just
you
know,
a
tlv
where
the
v
is
a
zebra,
encoded
ctdl
described
object.
B
You
can,
you
know,
look
something
like
this.
The
new
things
we've
done
is
to
add
a
set
of
ranges,
so
these
ranges
are
based
on
how
efficient
c
bar
are
at
encoding.
These
integers,
so
you
know
minus
23
to
23,
is,
I
guess,
a
single
byte
and
then
you
know
the
next
16
bits
are
are
two
well.
I
can't
exactly
remember
how
many
bytes
it
use,
and
then
you
know
when
you
start
different,
ion
actions
for
the
different
ones
as
well,
depending
on
how
you
know
valuable
they
are.
B
You
know
we
would
go
down
from
42
bytes
to
29
bytes
to
send
a
pio
option,
for
example
with
integer
encoding.
So
it's
you
know
quite
a
lot
more
efficient
one
benefit.
Also
using
cbor
is,
of
course,
that
we,
you
know
it's
a
much
more
flexible
encoding
that
allows
you
not
to
include
the
default.
You
know
fields
that
have
default
values,
for
example,
which
in
this
particular
case
made
it
more
efficient
than
you
know
the
rfc
4861
definition.
B
So
that's
the
question.
So
now
we've
been
this
draft.
You
know,
and
apologies
for
that-
it's
mainly
been
me
that
have
been
slow
on
this,
but
this
draft
has
now
been
around
for
for
quite
a
while.
So
I
think
we
have,
you
know,
asked
the
working
group
to
make
a
decision
if
he
wants
to
work
on
it
and
and
take
it
to
publication
or
if
we
should
abandon
it,
any
comments
now
or
otherwise.
We
can
take
that
to
the
mailing
list.
B
G
B
I
I
don't
think
we
at
least
we
haven't
come
up
with
a
you
know,
a
sensible
way
to
deal
with
that.
If
there
is
conflicting
information,
you
know
the
same
thing
applies
with
between
race
and
dhep
too
right
that
if
yeah
we
have,
I
think
we
left
that
up
to
the
implementation
to
deal
with,
but
yeah
contributions
welcome.
I
B
Was
not
meant
to
you,
know,
stop
or
deprecate
or
prohibit
any
other
uses.
It
might
be
that
you
know
that
discussion
would
come
up.
I
think
if,
if
you
were
to
propose
new
configuration
information
options
or
if
it
would
be
better
suited
or
not
to
this
format,
but
I
I
yeah
at
least
my
intention
was
not
to
do
that.
A
L
All
right,
so
I
previously
got
in
the
queue
and
then
dropped
out
because,
oh
you
said
the
same
thing
as
I
was
gonna
say,
which
is
on
the
conflict
question
yeah.
It's
a
configuration
error
the
same
as
if
you
would
have
included
the
same
option
twice
or
if
you
had
a
conflict
between
dhcp
and
rav,
any
other
mechanism
right.
You
already
have
to
have
some
way
of
dealing
with
that
in
the
host
deal
with
it
the
same
way,
it's
just
another
conflict
and
you
already
have
to
have
some
conflict
resolution.
L
L
In
other
words,
somebody
creates
an
ra
option
and
somebody
else
three
years
later
comes
along
and
puts
it
in
dhcp,
or
vice
versa.
Right
we've
seen
both
of
that
right,
and
so,
if
you
say
that
it's
fine
to
create
a
one
and
just
as
a
new
ra
option
and
not
put
it
under
here
right,
then
the
question
is
okay.
Is
that
saying
that
this
thing
would
be
inappropriate
for
dhcp
or
whatever?
L
And
so
you
might
want
some
text
that
says
anybody
that
asks
for
something
other
than
this
should
come
with
an
explanation
of
why
it
does
not
make
sense
in
dhcp
or
whatever,
so
that
it
would
deter
future
presentations
into
this
working
group
or
into
the
dhc
working
group,
as
the
case
may
be,
whichever
so
anyway.
Jesus
talk
about.
I
think
fred's
asked
a
great
question
and
I
would
like
to
see
the
draft
cover
and
answer
to
it,
but
I
think
it
doesn't
need
to
be
mandatory.
As
you
said
always
so,
there
you
go.
H
H
Just
yeah,
no,
no
hats
kind
of
comment,
a
couple
of
things
one.
There
are
some
things
that
I
that
I
think
are
nice
about
this.
Among
other
things,
there's
some
stuff
over
in
mask
that's
doing
ip
provisioning
over
http,
quick
kind
of
things,
and
they
are
potentially
going
to
have
to
reinvent
many
of
the
same
information
control,
plane,
signaling,
stuff
like
addressing
and
routing.
H
I
guess
for
the
moment-
and
that
is
there
are
sometimes
value
in
in
like
not
having
certain
things
standardized
in
the
sense
that
this
will
allow
or
could
allow
networks
to
attempt
to
force
clients
implement
certain
options
where,
if
they
had
not
been
previously
adopted
by
the
ietf,
they
could
reasonably
perhaps
have
been
ignored
this.
This
opens
sort
of
an
avenue
for
that
to
happen.
H
B
Yeah,
no
and-
and
I
think
we're
at
least
we
were
when
we
made
this-
you
know
originally
experimental.
We
were
quite
clear
on
the
you
know.
That
is
this.
You
know
aspect
and
of
you
know,
removing
process.
You
know,
and
you
can
argue
either
way.
If,
if
you
know
the
itf
acting
as
some
sort
of
you
know,
blocker
or
or
police
for
or
or
guardian
of
number
space
is
adds
value
or
not,
but
but
yes
indeed,
this
would
let
that
cat
out
of
the
bag.
W
I
would
like
to
argue
that
this
is
probably
not
a
good
idea
and
that
the
working
group
should
abandon
it
and
the
reason
I
say
that
is
twofold
one.
It's
always
bad
to
have
two
ways
to
do
something:
it's
always
going
to
create
interrupt
problems
so,
at
the
very
least,
take
out
all
of
the
stuff.
That's
already
nras,
don't
don't
have
a
way
of
doing
that
in
this
right?
If
you,
if
you
have
a
way
of
doing
that
in
this,
then
there's
two
ways
to
do
it.
Some
people
are
going
to
implement
it.
W
One
way
some
people
can
implement
the
other
you're
going
to
have
interrupt
problems.
That's
bad.
Second
point,
though,
is
that
it's
actually
really
a
good
thing
that
the
ietf-
and
this
is
this-
is
somewhat
reiterating
what
what
eric
said.
It's
a
slightly
different
reason.
It's
a
good
idea
for
the
ietf
to
review
this
stuff.
W
We
don't
want
to
have
again
multiple
versions
of
essentially
the
same
thing
you
know,
and
and
if
you,
if
you
basically,
if
you
open
it
wide
up,
you're
going
to
wind
up
with
a
train
wreck
you're
going
to
wind
up
with
thousands
of
new
options,
many
of
them
will
do
the
same
thing
as
some
other
option.
Some
of
them
will
be
implemented
by
one
vendor.
Some
will
be
implemented
by
another
you're
not
going
to
have
interop
and
the
whole
point
of
doing
ietf
review
is
to
get
interrupts.
W
So
I
just
really
don't
think
that's
a
good
idea.
I
mean,
I
think
you
know.
Had
things
been
different,
this
would
have
been
a
better
technology
for
doing
what
ras
do.
So,
I'm
not
saying
that
this
is
a
bad
proposal
from
the
technical
defense.
It's
just
that.
I
think
that
it's
going
to
have
some
really
bad
unintended
consequences,
and
so
I
really
would
prefer
to
see
it
not
happen.
B
A
H
W
That
would
certainly
make
me
that
would
certainly
make
me
happier,
but
it's
I'm
still
a
little
concerned.
I
think
the
problem
with
if
you
open
up
the
door.
This
is
responding
to
to
what
willa
was
saying.
If
you
open
up
the
door
at
all,
closing
it
later
is
not
really
going
to
help
much,
because
you
already
have
a
problem.
You
could
have
an
experimental
space,
but
I
don't
know
quite
how
you
do
that.
So
that's
that's
another
way.
W
You
could
consider
doing
that,
but
I
just
you
know,
is
this:
oh,
the
other
point
I
wanted
to
make.
Is
we
really
if,
if
we
can't
get
important
options
through
the
process,
then
maybe
the
problem
is
the
process
not
not
the
spec,
and
so
maybe
we
should
fix
this
the
process
and
not
try
to
fix
the
spec
by
you
know
anyway,
I'll
shut
up.
E
Firm
believer
that
there
is
really
no
reason
why
we
must
stand
on.
You
know
one
encoding
of
a
functionality
fits
all
right,
so
the
problem
that
ted
was
mentioning
before
that
we
may
have
different
encodings
and
subset
of
vendors
supporting
one
and
other
subset
others.
We
already
have
that
a
lot
through
different
features.
Right,
I
mean
look
at
the
srh
header
versus
what
they're
doing
in
the
iot
space,
which
is
very
similar
and
predated
right.
So
I
think
this.
This
is
a
perfect
experiment.
E
A
A
M
U
U
So
a
particular
ethernet
interface
particular
wi-fi.
Whatever
a
web
browser
is
sometimes
the
handiest
tool
for
this,
and
and
in
fact
there
is
a
situation
where
it's
the
only
tool
you've
got
if
you're
trying
to
reconfigure
a
device.
That's
come
back
for
service
where
the
only
way
to
configure
it
is
through
its
web
server
interface
and
the
only
way
to
reach
that
web
server
interface
is
through
a
literal
ip
address.
U
If
it
happens
to
be
a
link
local
address
on
a
specific
interface
of
your
machine,
you
can't
reach
it.
If,
if
we
don't
solve
this
problem-
and
there
is
one
application
and
it's
an
apple
proprietary
application,
but
it's
still
quite
wide
spread.
I
think
where
they
use,
link
local
addresses
over
http
in
a
specific
way
that
actually
requires
them
to
transmit
the.
O
U
Bug
history
on
this
particular
feature
for
for
what
is
now
called
firefox,
I
suspect
it
was
called
something
else.
When
the
bug
started,
you'll
discover
there
are
a
lot
of
people
who
want
this.
It
comes
up
every
couple
of
years
or
something.
So
why
is
this
a
fail?
Why
was
the
rfc
a
fail
because
of
the
percent
sign?
U
U
We
defined
a
mapping
from
that
format
into
url
syntax.
Currently,
no
known
current
browser
is
supported.
Actually
internet
explorer
still
does
support
it,
but
that
hardly
meets
the
definition
of
a
current
browser,
and
the
reason
for
this
is
that
the
browser
community,
which
is
embodied
in
a
mailing
list,
called
what
wg
they
decided
explicitly
not
to
support
this
feature
because
they
don't
like
it.
A
A
U
R
U
That
says,
if
you
write
your
bnf
the
nf
properly,
you
don't
need
that
percent
encoding,
because
you
can
simply
specify
that
that
particular
bit
of
the
uri
is
not
encoded.
Okay,
there's
a
our
proposal
on
the
draft
at
the
moment
is
to
not
change
that,
but
that's
open
for
discussion,
probably
not
today.
U
The
second
big
problem
with
rfc
6874
was
that
it
has
a
rather
strange
requirement,
which
is
to
require
a
host
to
delete
the
zone.
Identifier
from
outgoing
uri.
Now
that's
within
the
http
host
header,
I
actually
dug
into
the
http
rfc
for
once
in
my
life,
discovered
that
this
requirement
actually
violates
the
normal
behavior
of
http.
U
Second,
the
third
problem
is
somewhat
similar.
We
also
have
a
rather
screwy
suggestion
in
the
draw
in
the
rfc
that
parsers
should
support
the
percent
25
encoding
of
the
percent
sign,
but
heuristically
accept
ones
that
don't
include
it,
so
the
famous
percent
f
zero
would
be.
Okay,
if
you
happen
to
have
an
interface.
An
internet
interface
called,
I
think,
percent
ee
is
one
of
the
ones
that
wouldn't
work
that
wouldn't
work
because
percent
ee
would
decode
as
a
uri.
U
U
A
R
R
The
only
the
only
argument
to
escape
it
is
well,
we
escape
everything
else.
So
why
not
escape
this
and
one
downside
is
you
can
type
a
ping
command
and
ping
the
host
and
get
a
reply,
but
you
can't
copy
and
paste
that
address
into
a
web
browser.
It
requires
some
manual
editing
which
is
hard
to
explain
and
as
we've
seen
in
these
slides,
the
escaping
or
not
escaping
or
having
heuristics,
because
it
might
be
escaped
or
might
not
also
comes
with
a
lot
of
pain.
R
R
R
L
So
sure
I'll
jump
in
just
because
you
asked
me
to
comment,
I
don't
remember
the
technical
details
that
I
had
when
we
first
described
it,
because
I
probably
had
some
specific
anecdotes
then
that
I
don't
recall
now
because
it's
been
a
while,
but
there's
a
lot
of
uri
parsers
in
the
world.
There's
lots
of
pieces
of
stuff
to
do
that
in
operating
systems
and
middleware
inside
applications
and
things,
and
so
the
percent.
L
Two
five
is
probably
the
only
thing:
that's
safe,
given
the
wide
deployment
of
uri
parsers
all
over
the
place,
yeah
it
prevents
cut
and
paste,
but
you
can
make
it
work
for
a
specific
implementation,
but
putting
in
a
standard
issue
is
just
going
to
break
applications.
I
think
the
argument
went
something
like
that.
L
L
L
You
know,
applications
that
do
things
middleware,
that
does
things
middle
boxes
that
do
things
with
uris
and
so
on.
So
it's
really
hard
to
make
any
change
with
uris,
given
that
they're
so
prevalent
all
over
the
place
and
of
course
6874
did
make
a
change,
and
what
you've
seen
is
that
it
didn't
work
with
everything.
So.
U
A
E
I'll
put
it
in
there
jaclyn
good,
I
mean
what
would
as
a
user.
Would
I
like
something
consistent
sure.
Would
I
like
something
consistent,
that's
ugly?
No,
so
I
mean
isn't
there
any
way
that
how
we
can
find
another
character
that
doesn't
have
to
be
escaped
instead
of
percent
25,
I
mean
this
is
not
going
to
go
away
anytime
soon,
so,
even
if
it
takes
a
little
bit
longer
to
get
it
proliferated,
I
mean
why
not
do
whatever
is
the
nicest
that
can
be
consistent.
Instead
of
you
know
this
stuff
yeah.
E
U
A
So
we
I'm
gonna,
put
my
chair
hat
back
on
not
as
a
co-author
here.
So
we
are
out
of
time,
might
take
or
only
should
confirm.
I
think,
there's
interest
in
doing
this.
I
think
there's
deadly
some
questions
about
what
the
right
course
is,
but
this
should
certainly
be
socialized
in
other
places
as
brian
suggested,
but
I
think
we
can.
I
don't
I'm
not
so
this
should
continue
on
the
mailing
list,
but
I
do
think,
what's
what
we
have
now
is
clearly
broken,
then
we
should
try
to
fix
it
best.
A
A
B
A
Y
There
we
are
so,
hopefully
you
can
hear
me:
yes
go
ahead
and
be
quick
right
so
very
quickly.
I
go
directly
to
the
most
important
slides
just
to
explain
what
our
draft
is
about.
So
basically
we
are
trying
to
analyze
cases
of
prefix
invalidity
and
try,
of
course,
to
propose
solutions
for
those
cases,
looking
in
particular
to
multi-homing
multi-prefixes
environments
in
the
presentation,
you
will
find
much
more
information.
Y
I
simply
skip
the
slides
for
the
sake
of
saving
time,
so
basically
we
are
trying
to
achieve
is
to
store
the
case
such
as
the
one
represented
in
the
slide
here.
So
basically,
we
have,
for
example,
a
home
or
an
office
network
with
a
couple
of
routers
connected
to
or
even
more
possibly
upstream
providers,
and
suddenly
one
of
the
routers
fails
or
is
a
connect
issue.
Y
So
the
problem
is
how
to
cope
with
the
situation
where
you
have
that
router
still
working
and
presenting
itself
the
default
router
or
the
next
loop
for
a
set
of
prefixes
that
haven't
been
deplocated
because
they
have
not
been
invalidated
because
of
the
situation
represented
here.
So
the
diagram
on
the
right
simply
represents
the
case.
Y
So
what
happens
with,
let's
say
having
one
of
those
prefixes
which
becomes
only
valid,
but
one
of
the
hosts
in
internet
is
not
able
to
understand
that
or
does
not
have
the
means
to
understand
that,
so
it
keeps
on
using
the
same
prefix
to
build
a
source
address.
The
the
draft
is
clearly
much
wider
than
that.
I
simply
show
probably
as
one
of
the
final
slides
this
summary,
which
right
on
left
possible
solutions
to
the
different
issues
that
we
may
find.
Y
Y
That
is
the
main,
let's
say,
content
of
the
draft,
and
I
conclude
with
the
slide
eight
just
to
share
with
you
that
we
would
be
happy
to
receive
a
comments,
contribution,
even
criticisms.
Of
course
we
have
produced
the
draft
zero.
So
it's
quite
new.
We
uploaded
a,
I
guess
a
couple
of
months
ago.
Okay,.
A
X
X
X
This
is
the
format
I
will
skip
it,
and
this
is
the
procedures
it
is
describing
the
draft
and
we
also
skip
it.
Okay,
this
is
updating
the
recent
versions.
We
have
the
new
co-op
search
in
and
we
clarify
this
as
a
option
in
the
hover
hub
header.
We
also
clarify
this.
Video
id
is
only
used
for
to
determine
the
set
of
resources
for
the
packet
processing
and
we
also
added
some
operational
considerations
that
reference,
the
hobby
processing
draft.
X
Okay,
so
in
conclusion,
this
document
proposed
a
new
haba
hub
option
for
the
harbour
package
forwarding
treatment,
so
it
aligns
with
the
design
functionality
of
the
harbor
hub
header.
The
content
of
this
document
has
been
stable,
so
we'd
like
to
confirm
whether
the
documents
belongs
to
six
man
working
group.
If
so
and
we'd
like
to
ask
for
the
adoption
on
this
document.
A
A
So
we
have
completed
about
eight
minutes
over
schedule,
but
I
think
we've
had
a
very
constructive
discussions
on
a
variety
of
topics,
so
I
think
chloe
and
I
would
like
to
thank
you
very
much
and
I
wonder
if
we're
going
to
see
you
in
madrid
or
on
the
computer
again
next
time
so
good.
Thank
you
all
see
you
on
the
mailing.