►
From YouTube: IETF100-V6OPS-20171116-0930
Description
V6OPS meeting session at IETF100
2017/11/16 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
The
document
was
right
on
the
edge
of
informational
versus
BCP
and
actually
earlier
versions
of
the
documents
were
mocked
informational
after
chatting
with
a
bunch
of
people,
including
the
author's
suresh
as
the
six-man
ad
and
a
bunch
of
other
iesg
folk.
We
think
that
you
know
just
moving
it
forward,
but
changing
the
track
to
be
informational.
You
know,
because
of
the
new
text,
etc
makes
sense.
Authors
seem
okay
with
that,
I
think
that's
best.
Then
we
can
just
you
know,
get
it
out
the
door.
D
E
C
B
This,
so
speaking,
you
know,
as
somebody
who
wanders
around
on
the
NOC
I,
think
that
that
would
be
something
that
the
NOC
would
be
happy
to
consider
doing,
probably
as
an
experiment,
but
obviously
it
would
need
to
be
something
that's
actually
implemented
and
we
can't
right.
We
need
a
vendor
yeah
implementation.
Yes,
that
needs
to
be
an
implementation
on
gear
that
we
actually
have
or
can
borrow
or
use
or
deploy,
or
something.
B
Well
depends
by
what
you
mean
in
this
room:
the
APS
in
this
room
I
believe
we've
turned
off
the
V
for
one,
so
there
should
be
not
six
four
and
v6.
Only,
however,
just
over
there,
there
is
a
non
RF
opaque
wall
we
had
not.
We
had
not
announced
that
we
were
continuing
the
experiment
of
no
idea
before.
Yes,
that's
what
I
wanted
to
clarify.
Thank
you
and
obviously
you
know.
Please
use
nat64
and
please
file
trouble
tickets
webpage
to
get
stopped
meeting
that
IETF
the
dog
and
also,
please
include
some
some
stats.
G
G
A
B
Yeah,
you
can
see
them
all.
We
have
ApS
here
and
those
are
only
doing
the
v6
ones.
Unfortunately,
there's
a
meeting
in
the
room
next
door
and
that
wall
is
not
RF,
opaque
and
so
those
ones
you're
getting
bleed
through
from
you.
Should
you
know,
please
choose
the
the
six
full
ones,
sorry
at
the
v6
ones,
and
you
should
also
get
to
stronk,
better
signal
strength
with
those
and
better
performance,
etc.
So,.
H
A
H
A
A
K
L
Okay:
okay,
you
can
start
there,
so
this
document
is
called
ipv6
prefix
delegation
for
hosts.
Here
you
got
the
history
of
the
draft.
There's
been
15
versions
of
it,
most
of
them
within
the
last
couple
of
months
because
of
some
intensive
list,
discussion
that
have
clarified
some
points
and
a
pointer
to
the
draft
at
the
bottom.
L
L
The
prefix
to
the
requesting
router
the
requesting
router
then
assigns
addresses
from
the
prefix
to
an
internal
virtual
interface
like
a
loopback
without
invoking
MLD
data
on
the
upstream
interface.
An
example
is
any
host
with
internal
virtual
interface
on
which
addresses
can
be
assigned.
So
so
here
we've
got
multi
addressing
so
you
can
assign,
as
many
addresses
as
you
lie,
to
the
loopback
interface,
but
you
don't
have
to
do
dad
or
mom
Aldi
for
those
addresses
on
the
upstream
interface,
because
that
prefix
has
been
uniquely
delegated
to
the
node
for
its
own
internal
use.
L
So
in
the
example
is
any
host
that
cannot
assign
addresses
to
any
other
interfaces
besides
the
upstream
interface,
and
that
corresponds
to
what's
known
as
the
strong
end
system
or
strong
host
model,
so
ml
D
data
implications.
The
host
does
not
joint
use
ml
d
to
join
the
solicit,
no
multicast
group
and
does
not
perform
that
over
the
upstream
interface
in
any
of
the
three
cases
and
that's
acceptable,
because
prefix
delegation
guarantees
that
no
other
node
receive
the
prefix
dynamic
routing
protocol
implications.
L
The
host
can
be
configured
to
participate
or
not
participate
in
a
routing
protocol
over
the
upstream
interface
then
nodes
that
don't
participate
in
routing
protocols.
They're
gonna
have
to
send
all
outbound
packets
through
the
delegating
router
as
the
default
router,
but
future
redirects
may
inform
the
host
of
a
better
first
hop
than
that
valuating
router.
L
Additional
considers
Nations
ipv6
neighbor
discovery
implications.
The
node
is
going
to
act
as
a
simple
host
to
send
router
solicitation
messages
over
the
upstream
interface
and
but
it's
going
to
have
to
set
the
router
flag
to
true
and
its
neighbor
advertisement
messages,
because
the
thing
has
a
prefix
that
its
routing
is
directing
all
packets
to
that
host
that
matched
the
prefix.
L
For
this
document
observe
both
the
host
and
router
specifications
for
icmpv6
in
terms
of
returning
ICMP
messages,
implications
for
vendors
and
operators,
a
host
that
required
prefix
delegations
act
like
routers
from
the
standpoint
of
prefix
delegation,
but
act
as
host
from
the
standpoint
of
their
local
applications.
But
the
network
from
the
network
at
all
looks
the
same
at
the
network
network,
doesn't
care
that
there's
applications
internal
to
their
hosts
that
are
using
those
addresses.
It
allows
for
unlimited
multi,
addressing
in
the
spirit
of
79,
34
and
multi.
L
Addressing
does
not
cause
them
any
MLD
or
dab
messaging
over
the
upstream
interface,
and
it
opens
new
possibilities.
For
example,
I
live
from
the
unique
ipv6
address
for
each
of
the
hosts
local
applications,
and
the
next
step
I
would
like
to
ask
if
this
could
become
a
v6
ops
working
group.
That
document.
M
Yeah,
this
is
a
terminology
issue.
We
had
this
discussion
in
six-man.
If
you
read
the
definition
than
8,200,
it's
very
clear
on
what
the
definition
of
a
host
of
a
router
router
is,
if
you,
if
you
put
other
links
on
it
and
start
forwarding
packets
to
something
else,
it's
a
router,
so
I
think
you
should
use
that
terminology
here.
I,
don't
have
a
big
opinion
opinion
on
the
merits
of
this,
but
at
least
get
the
terminology
right,
don't
don't
make
new
kinds
of
hosts.
A
M
A
Fred
I'd,
backed
up
to
your
case
too.
You
have
a
number
of
virtual
hosts
embedded
inside
this
thingy
that
the
prophets
was
given
to
and
and
I
think
your
statement
about
this.
Your
statements
correct,
but
it
would
have
been
more
clear
if
you
had
said
that
it
behaves
as
a
router
at
the
upstream
interface,
but
it
behaves
as
a
host
at
a1,
a2,
a3,
yeah
and
a
lot
of
Doc's,
which
I'm
sure
is
what
you
meant
and
in
in
that
those
context
you
would
be
using
the
language
exactly
the
way.
A
E
Mark
is
Google,
there's
an
interesting
edge
case
that
comes
up
when
you
delegate
a
prefix
to
a
host,
and
that's
the
question
of
whether
any
of
the
addresses
are
reserved
like,
for
example,
is
address,
zero,
considered
a
subnet
anycast
address,
or
is
it
usable
as
a
general-purpose
address
like
it
might
be
worth
addressing
that
in
the
document?
That's.
N
So
wrong
to
questions,
but
not
for
you
Fred,
so
the
first
one
is
on
the
value
value
of
this
document.
If
someone
in
the
room
who
is
planning
on
deploying
or
implementing
this
could
say,
if
how
much
you
know
this
document
mattress
versus
if
they
were
able
to
just
implement
it
based
on
RFC
36:33
and
the
other
rq6
RFC's,
especially
what
we
described
around
CPS
as
well,
which
I
were
very
similar.
C
N
C
Know
some
of
the
stuff
he's
already
presented
in
his
slides
are
questions
that
came
up
when
we
did
Pio,
X,
right
and,
and
some
of
the
so
I
do
think.
There's
there's
possibly
some
some
value
here
and
I
also
think
there's
value
in
recognizing
that
nowadays,
a
host
is
just
a
Rooter
that
is
not
currently
forwarding.
I
mean
is
that
is
that
is
that
is
really
the
case.
O
O
Think
this
the
this
artificial
distinction
is
essentially
you
know
it's
just
hampering
us
at
this
point
like
there
really
is
no
point
in
maintaining
that
finish:
the
distinction
between
a
ruder
and
a
host.
Unfortunately,
it's
in
you
know
eighty
two
hundred,
which
is
you
know
full
standard
these
days
and
I,
don't
know
if
there's
any
appetite
to
change
that,
maybe
you
know
we
can
do
something
and
saying:
look
if
you're
doing
a
host
implementation
and
sometimes
your
host
and
sometimes
your
Rooter.
These
are
the
things
that
you
need
to
do
now.
O
This
document
could
be
some
of
it.
Some
of
that
in
the
sense
it
tells
you
kind
of
what
to
do.
What
I
don't
like
about
this
document
is
that
it
tells
you
what
to
do,
but
it
doesn't
say
why
and
so
I
think
we
there
is
value
in
a
document
like
this,
but
most
of
that
value
hasn't
been
written
yet
so
what
what
I
want?
O
We
know
what
to
do
and
your
guidance
says
what
to
do
on
those
links,
but
I
think
we
need
more
of
a
like
more
of
a
guidance
on
why
to
do
things
so
that
when
new
things
appear,
we
actually
know
what
to
do
in
the
future.
So
so
yeah
like
I,
said,
there's
a
lot
of
do
this,
but
not
a
lot
of
why
you
should
do
this
very
good.
Point,
thank
you.
P
L
P
The
second
is,
with
respect
to
the
laptop
model
and
virtual
machines.
I
saw
in
an
earlier
slide
yeah,
so
you
have
example1
example2
looks
like
they
are
distinct,
but
I
I,
miss
I,
may
suggest
separately
that
most
cell
phones
to
smartphones
today
do
have
virtual
machines,
even
though
they
are
rarely
seen,
but
they're
modems,
often
our
mini
VM
virtual
machines
and
whether
they
have
an
IP
address
or
not.
That's
another
question,
but
it's
virtual
machines
on
smartphones
and
finally,
with
respect
to
the
operator
question
that
would
implement
this
or
this
was
raised
earlier.
P
This
is
a
very
relevant
question.
I
think
there
may
be
some
operators
that
would
be
able
to
and
would
be
interested
to
run,
dhcpv6
first
and
then
the
HP
v6
prefix
allocation.
Second,
but
there
are
problems
with
this,
and
the
problems
and
issues
are
not
at
the
operator
are
at
the
hardware
manufacturers
in
particular:
I
could
name
them,
but
router
equipment
manufacturer
model
manufactures.
These
are
some
of
the
key
players
that
allow
or
not
allow
for
DHCP
v6
altogether.
So
that
were
the
comments.
Okay,
thank
you.
D
Take
care.
My
comment
is
on
the
very
last
slide.
I
just
wanted
to
say
more
about
the
eg
that
well
yeah
that
one
thank
you.
Okay,
the
eg,
a
different
and
unique
ipv6
address
for
each
of
the
host
local
applications
is
that
what
I
want
to
comment
on
I
think
this
is
true
and
I
wanted
to
comment
on
that
part
because
there's
actually
at
least
two
different
use
cases
I
can
think
of
for
that,
and
this
is
good
for
one
of
them
and
not
good,
for
the
other.
D
Well,
doesn't
work
for
the
other
one
right,
but
that
doesn't.
But
so
we
go
back
in
time
in
the
six
men
working
group
a
number
of
years
ago,
when
the
privacy
addresses
RFC
or
draft
was
first
being
discussed,
and
this
notion
of
I'd
like
to
have
a
different
ipv6
address
for
each
of
my
host.
Local
applications
actually
came
up
and
was
discussed
at
length
and
the
reason
that
didn't
come
into
the
document
right.
It
was
not
precluded
than
document,
but
it
was
not
put
into.
D
The
document
was
because,
if
you
have
a
whole
bunch
of
IP
addresses
you
get
a
do,
join
a
solicitor
node
multicast
group
for
each
one,
you
blow
the
card
into
promiscuous
mode
and
then
all
your
performance
goes
away.
This
does
not
have
that
problem.
Okay.
What
should
Fred
pointed
out?
Okay,
so
this
solves
that,
because
you're
not
joining
the
Seleucid
multicast
addresses
right.
So
the
example
of
Fred
gave.
Is
you
know
if
it's
on
your
loopback
interface
right,
then
there's
no
interface
that
you're
joining
the
multicast?
D
No
the
multicast
address
on,
and
you
don't
have
the
problems
that
were
talked
about
as
to
why
it
was
not
in
the
privacy
document.
So
that
said,
there
is
at
least
two
use
cases.
I
can
think
of
that.
You
might
say
I'd
like
a
different
IP
v6
address
for
each
application,
one
and
so
that
you
can
use
a
privacy
address.
D
This
doesn't
help
with
that
right,
because
the
purpose
of
privacy
used
to
prevent
correlation,
and
it's
the
prefix
that
you
get
that's
correlated
everything
right,
so
it
doesn't
that
you
wouldn't
actually
use
this
for
privacy
addresses
because
it
doesn't
actually
give
you
privacy.
There
are
other
things
that
you
might
use
that
for
to
say:
I
want
to
define
unique
IP
address
for
each
of
the
host
local
applications.
So,
for
example,
if
you
were
using
CGAs
or
some
use
it
for
cryptographic
security
purposes,
this
would
work
perfectly
fine.
D
Q
Michael
Abrams,
so
first
of
all,
I
think
I
just
want
to
say
that
I
think
this
is
useful.
I
would
like
like
to
see
a
document
that
stitches
multiple
things
together
and
presents
like
ok
here.
Here's
an
end-to-end
solution
that
solves
this
problem.
It
takes
these
and
does
those
mechanisms
together,
I
think
there
is
value
in
this
document,
since
this
is
v6,
ops
and
I've
seen
this
problem
live?
If
you
get
a
delegated
prefix
and
you
do
stuff
to
it
and
you
don't
a
blackhole
route,
the
entire
prefix,
you
might
ping-pong
the
packets.
L
Right,
that's
a
good
point.
I
do
touch
on
the
point
that
the
route
that
the
host
is
supposed
to
send
destination
unreachable,
it's
yeah.
It
gets
its
packets
for
an
address,
that's
not
configured
but
black,
calling
the
prefix
I'm,
not
sure
if
I
see
it
in
the
document,
but
it's
implied
and
it
should
be
in
there
if
it's
not
yeah.
Q
I
think
because
I
I
have
seen
actual
operating
systems
in
volume
that
we
have
that
did
request
prefix
delegation
when
use
to
turn
on
internet
connection,
sharing,
I
guess
if
people
can
figure
out
what
it
was
and
it
didn't
black
hole,
the
entire
prefix.
So
you
got
it
would
request
like
a
flash
56
that
configures
left
64
and
then
it
would
ping
pong
with
the
other
ones
right
right.
So.
O
Fred
I
skimmed
the
graph
but
I
I,
don't
think
I
saw
this
in
there,
but
I'm
not
sure
if
it
is
or
is
it
is
it
if
it
isn't
how
much
of
this
applies
to
ipv6
prefix
per
host
and
and
what
are
the
differences
between
a
delegated
model
and
an
ipv6
prefix
per
host
model,
as
documented
and
the
thing
that's
currently
in
all
48
yeah
I
touched
on
that
one,
the
other
sign
lingo
back
to
that.
So
sorry,.
A
Okay,
so
I've
got
a
couple
of
questions.
If
you
don't
mind
in
I'm
I'm.
Looking
at
your
case,
one
and
I
mean
the
cases
are
all
the
same.
If
we
decide
to
not
distinguish
between
virtual
and
physical
but
okay,
so
I'm,
using
that
one
on
the
upstream
link
or
on
the
upstream
interface.
Where
is
the
address
coming
from
that
is
used
by
this?
This
node?
Is
it
from
the
subnet
that
the
delegating
router
is
using,
or
is
it
from
the
prefix
that
was
delegated
to
the
downstream
router?
It's
the.
L
Prefix
that
delegated
the
downstream
router
so
on
the
upstream
link
that
node
is
going
to
have
a
link
local
address
and
it
used
the
link
local
address
to
do
the
prefix
delegation
exchange
in
the
first
place.
But
once
the
prefix
delegation
comes
that's
the
prefix.
That's
used
internally
by
that
node
by
the
host,
slash
router,
okay,.
A
O
I
mean
if
you
look
at
77084
it
at
the
theater
RFC,
it
allows
for
both
models.
There's
ISPs
that
deploy
unnumbered
northbound
interfaces
would
just
link
local
and
there's
our
SPS
that
use
slack
and
auto
come
on
on
the
upstream
link.
Their
ISP
is
that
only
do
PD
as
sorry
AIA
and
a
on
the
upstream,
so
you'll
see
a
variety
of
models:
okay
in
the
real
world.
I,
don't
know
about
this.
N
O
R
It
says
784
talks
about
the
virtual
interface,
that's
for
internally
routing
stuff,
so
it
won't
actually
show
up
on
the
way,
an
interface.
So
it
has
to
do
it's
something
slightly
different
than
what
I
it's
basically
unnumbered
at
that
point,
so
it's
either
unnumbered
I
na
or
a
slot
based.
They
don't
ever
take
it
out
of
the
prefix.
It
needs
your
address
and
things
coming
up.
The
lamp
I.
N
So
would
later
on,
since
I
was
the
one
who
put
the
restriction
in
place
in
2003
I
forgotten.
Why,
but
no
it
was.
It
is
because
of
nd
right,
there's,
no
expectation
that
the
upstream
reader
can
do
address
resolution
for
addresses
within
the
delegated
prefix.
That
is
deep.
The
sole
reason
why
that's
that
restriction
is
in
in
place,
yeah.
A
Okay,
so
the
route
table
in
the
delegating
router,
as
it's
called
in
this
picture,
the
drought
table
there
uses
the
link
local
address.
So
it's
the
next
hop:
okay,
okay,
okay,
so
before
you
run
away,
I
think
I
heard
two
things
you
would
like
this
to
be
taken
as
a
working
group
draft
Lorenzo
says
that
if
it's
taken
for
a
working
group
draft,
he
wants
to
make
it
an
order
of
magnitude,
more
text
close
and
so
Lorenzo,
and-
and
you
know
anybody
else
can
volunteer
but
I
think
you're
kind
of
volunteering
yourself.
O
I
think
it
practices
like
volunteered
I
would
only
succeed
in
dragging
down
the
document
and
never
getting
it
published
due
to
lack
of
time.
So
I'm
not
gonna,
volunteer
here,
I,
don't
know,
but
but
I
you
know,
I'm
pretty
sure
old
Fred
can
come
up
with
some
rationale
for
the
things
that
he's
written
because
he
did.
You
know
the
things
that
it
says.
Right
now
do
make
sense.
O
So
the
only
thing
is
like
we
have
this
little
blank
slate,
that
we
need
two
coats
of
textin.
No,
no,
no
I!
Think
it's
like
you,
you
you
you've
got
like
it
must
do.
This
should
do
this,
you
do
this
and
then
you
know
you
would
hit
about
the
same
amount
of
text
just
before
that
saying
you
know
here
are
the
reasons
why
or
just
after
that.
Certainly.
N
Bullet
Tyrone
again
so,
for
we
were,
if
we're
going
to
adopt
this
document,
I'd
really
I'd
like
to
have
my
second
question
answered:
are
there
any
operators
who
are
going
to
deploy
this
model
because
I
have
asked
with
my
IT
department
and
they
just
refused
point
blank?
You
know
and
I
asked
them
a
few
times,
because
I
need
this
for
EMS,
for
example,
and
it's
it's,
you
know,
let's
see
if
we
get
some
operational
in
Patera.
N
O
O
O
So
fact
they're,
not
even
like
part
of
the
conversation
here,
you
were
there,
it's
a
product
of
ITF
consensus
just
because
it
has
my
name
on
it,
so
so
I
think
I
would
love
to
have
conversation
with
the
security
people
that
you're
in
your
IT
department
as
to
whether
v6
prefix
per
host
helps
do
what
they
do
right
and
I
would
also
like.
If
somebody
wants
to
implement
PD,
there
is
no
host
support
for
it
right
now.
Right,
but
you
know,
I
could
change.
P
P
Some
of
these
routers
cannot
be
configured
to
accept
requests
on
non-standard
ports.
Some
of
these
routers
use
only
global,
unique
address
in
source
packets
instead
of
link
local
address
of
dhcpv6,
and
it's
really
hard
to
to
make
them
and
it's
expensive
also
because
somebody
said
value,
I
forgot,
but
it's
really
expensive
much.
Money
is
requested
to
make
small
modifications
in
key
parts
of
the
router
manufacturer
software.
So.
A
L
P
Q
Microwave
engine,
so
Windows
Vista
and
later
does
this
it's
I
guess
you
obviously
can
make
Android
do
this.
If
you
want
to
the
will
be
heard
at
the
last
session
about
the
cisco
ITI,
he
said
he
wanted
to
do
tracking
in
the
dhcp
server,
but
he
wanted
to
ini.
He
could
do
PD
instead
and
do
the
same
kind
of
tracking
a
run
I'm
numbered
on
the
one
and
do
the
same
kind
of
tracking
there,
I
don't
know.
Do
you
have
Windows
me?
Q
Q
If
there
are
no
devices
ever
requesting
this
as
they
connect
then
nobody's
going
to
deploy
it
I
had
the
same
question
about
nat64
or
v6
only
but
Wi-Fi
it
and
nobody's
doing
that
they're
all
a
bunch
of
operating
system.
Don't
work
well
with
this
and
up
what's
going
to
do
it,
so
the
question
is:
how
would
we
break
the
catch-22
here
so
I?
Don't
think
that's
I,
don't
think
you
can
answer
that?
Oh
no,
if
you're
going
to
deploy
this
that
really,
at
least
for
true.
C
Eric
Cline
I
mean
this
is
the
sixty-four
share
model
right
here
right.
This
is
deployed
today.
If
you
do
v6
tethering
on
your
Android
phone.
This
is
exactly
what
happens
right.
There's
one
there's
a
couple
of
addresses
pulled
on
for
the
device
and
the
the
rest
of
the
/dt
for
shared,
downstream
I.
Think
and
Ted
Fred.
C
Now
I
have
not
gone
through
the
thesaurus
to
find
a
better
word
than
delegated,
because
it's
kind
of
overloaded
with
PV
and
dhcpv6
stuff,
but
right
put
that
dedicated
sure,
but
it
doesn't
have
the
yeah
anyway,
yeah
I,
don't
know
that
there's
a
better
word,
but
okay,
if
we
could
sort
of
deconflict
the
terms
I
think
I
spell
out
delegated
in
the
terminology.
If
I
don't
how
you
do
it
there
yeah
you
do!
That's
where
you
say
that
DSU
zpg
is
an
example
of
a
delegated
right.
Looks
right
that
was
inside
there's.
C
E
O
Lauren
typically
comment
on
a
you
know.
Comment
on
Alex's
statement
is
my
personal
opinion
that
you
will
never
get
never
ever
ever
ever
ever
get
the
HP
PD
on
your
Wi-Fi
on
your
LTE
modem
until
some
operator
supports
it
on
the
server
side.
You
can
talk
about
it
here
until
we're
all
blue
in
the
face,
but
the
LT
modems
are
built
very
tightly
interoperable
to
interoperate
with
carrier
networks
which
are
highly
managed.
Networks
do
not
typically
have
a
wide
range
of
interoperability
with
non
carrier
devices
right.
O
They
are
mostly
devoted
to
devices
that
are
very
tightly
managed,
very
tightly
controlled
and
obey
very,
very
tight
carrier
requirements.
If
delegating
a
prefix
to
a
USB
key
is
not
a
service
that
an
operator
wants
to
support.
No
modem
vendor
will
actually
implement
that
because
it's
because
the
there's,
a
substantial
impedance
mismatch
with
what
what
the
kernel
knows,
how
to
support
and
how
3gpp
actually
works.
There's
really
a
lot
of
glue
code
in
there
that
basically
pretends
that
you
know
the
PDP
context
looks
like
an
interface.
O
It's
not
right,
and
so
until
somebody
decides
to
make
it
work,
because
some
operator
says
it's
gonna
work
because
they
want
it
to
work,
then
it's
never
gonna
happen
right,
I,
don't
know,
starry
freezing
strong
words
here,
but
we've
been
talking
about
this
for
years
and
it's
gonna
be
many
years
before
it
actually
happens.
Okay,
so,
but
like
talking
about
here,
is
really
not
gonna
make
a
difference.
O
P
So
let
me
be
clear:
there
is
operator
that
is
wishful
to
work
on
this
direction.
Okay,
there
is
that
that
is
not
a
problem.
Both
ends
out
there
operator
is
ready
and
mod,
and
the
node
is
ready
to
do
this.
The
problem
is
either
in
the
modem
or
in
the
hardware
implementer
to
fix
protocol
issues,
but
the
operator
is
ready.
It's
not
a
prefix
length
issue
is
not
a
lack
of
intention
of
lack
of
goo.
We'll
operator
is
ready
to
do
this.
Okay,
okay,.
F
A
S
S
However,
I
I
have
been
running
since
about
when
year
and
a
half
ago,
a
survey
on
how
the
people
is
deploying
ipv6
and
surprisingly
I
discovered
that
31%
of
of
the
of
the
people
who
responded.
The
survey
is
actually
using
this.
There
is
also
and
an
additional
document
since
2012,
which
is
dhcpv6
prefix
delegation,
option
to
support
this.
This
is
the
RFC
6603,
and
the
problem
is
that,
even
if
this
is
supported
by
an
option,
it's
not
described
it.
S
You
know
in
any
document,
so
it's
an
option
for
something
that
it's,
let's
say
somehow
implicitly
address
it,
but
but
not
not
explicitly
documented,
okay,
oops.
Okay.
This
is
some
of
the
stats
of
this
survey
that
I
have
been
running
at
the
moment.
I
got
responses.
This
is
from
one
month
ago.
I
got
responses
from
1513
people
in
different
regions.
There
is
more
responses
from,
for
example,
from
from
Europe
and
Latin
America,
but
also
a
Pinnock
is,
is
also
responding
about
that.
I
have
also
some
pictures
here.
S
There
is
another
picture
that
shows
what
what
prefix
size
they
are
providing
and
and
then,
as
you
can
see,
and
I
just
mentioned
about
oops,
this
is
going
the
other
way
31
percent
of
the
people
is
is
using
this.
This
technology
there
is
something
that
threat
also
commented
to
me
is
that
we
have
RFC
61
64
that
describes
using
in
point-to-point
links
1
to
7,
but
this
document
is
not
precluding
other
options
and
this
document,
actually,
what
is
saying
is
that
routers
must
support
that.
S
But
it's
not
saying
that
this
is
the
only
possible
way
or
even
saying
that
you
should
not
do
something
different
and
in
fact,
with
the
same
survey
I
did
you
can
see
that
62%
of
the
people
that
is
responding
to
the
survey
is
actually
using
his
last
64.
So
there
is
much
more
people
using
as
lasticity
for
that
1
to
7
I.
Think
what
I'm
describing
in
this
document
is
useful
is
something
that
is
actually
being
deployed
more
than
any
other
way
of
doing
point-to-point
links.
S
It's
also
simplifying
addressing
plans
in
the
sense
that,
instead
of
having
two
pools
of
addresses
one
for
the
point-to-point
links
and
one
for
the
customers,
you
have
a
single
pool.
So
it
also
somehow
simplify
the
troubleshooting,
because
when
you
do
a
traceroute,
you
don't
sit
two
different
pools
of
addresses.
You
see
only
the
pool
for
for
the
customer
right
and
in
addition
to
that,
in
terms
of
routing
you
can
aggregate
the
the
prefix
to
the
point-to-point
link.
So
I
have
an
example
here.
S
If
we
have
the
service
provider
prefix
as
2001
DB,
8,
/
32
and,
for
example,
customer
a
is
2001
deviate,
AAA,
8,
:,
:,
/
48,
the
point-to-point
link
will
be
the
first
one
which
is
in
this
case
the
same,
but
as
last
64
and
the
provider
site
can
be,
for
example,
:
:
1
is
less
64
or
:.
:
1
is
less
48
and
then
the
customer
side
will
be
:,
:,
ok,
so
considerations
from
dhcpv6
RFC
363
is
the
perfect
option
for
for
DCP
v6,
which
originally
avoided
it.
S
S
This
is
being
used
for
point-to-point
links
in
both
corporate
and
residential
customers.
The
routers,
of
course,
must
support
the
prefix
exclude
option,
which
is
six
six
zero,
three
and
in
fact,
RFC.
Seventy
eighty
four,
which
is
basic
requirements
for
epiphysis
customer
edge
routers
already,
including
the
support
for
this.
So
if
it's
being
used
is
because
it's
being
supported.
But
again
the
point
is,
is
not
explicitly
documented.
S
Elsewhere,
I
had
a
clarification
from
from
Michael,
which
is
point
to
point
in
non
broadcast,
so
I
added
this
text,
which
is
this
mechanism,
will
not
work
in
broadcast
layer,
two
media
that
relies
on
neighbor
discovery.
Okay,
the
recent
discussion
in
the
list
that
may
be
somehow
related
to
that
to
do
this.
It's
ad
resolution
resolution
to
be
done
only
in
links
which
layer
2
addresses.
So
this
is
something
that
probably
will
will
go
on
in
the
list
and
we
will
see
and
I
think
that's
it.
A
A
Well,
I
think
the
question
is
what
link
it's
used
on
the
the
point-to-point
architecture
thing
that
that
was
mentioned.
That
I
mentioned
was
on
point-to-point
links,
and
this
would
be
on
something
that
looks
amazingly,
like
an
Ethernet
but
connects
to
an
ISP
which
is
different
like
I'm.
Sorry,
oh
so
so
Geordi
asked
me
about
my
comment
about
slash
127
on
on
link
and
the
distinction.
A
There
is
that
the
the
BCP
slash
127
on
the
point-to-point
link
a
place
to
point-to-point
links
where
this
would
be
on
a
something
looks
amazingly
like
an
Ethernet
but
connects
you
to
your
cable,
modem
or
DSL
or
whatever,
being
in
a
broadband
network.
So
so
it
is
actually
a
different
case.
I
guess
what
ends?
Oh
yeah.
O
Just
like
what
does
this
get
you
over
unnumbered,
what
is
it?
What
does
it
give
you
over
the
approach,
that's
written
in
1708
for
right
now,
which
is
that
you
do
you
take
an
IP
address
from
me
from
the
delegated
prefix
and
you
configure
it
on
a
virtual
interface
like
what
do
you
want
to
do
this
instead?
What's
what's
the
point
you.
O
S
O
Says
if
you
don't
have
slack
or
dhcpv6
on
your
earthbound
interface?
Oh,
you
don't
have
okay.
What
does
this
give
you
over
that
model?
The
only
thing
that
I
can
see
that
it
gives
you
is
that
you
can
basically
hang
yourself
by
doing
n,
B
and
and
doing
ping
pong
by
incorrectly
assigning
a
64
to
Al
interface.
That's
basically
always
point-to-point,
like
the
only
thing
that
I
can
see
that
it
would
give.
You
is
basically
allow
you
to
miss,
consider
things,
but
maybe
I'm,
just
not
seeing
it
like.
What
does
this
give
you.
S
Not
1784
is
just
saying
you
can
use
the
AC
router
should
support
the
prefix
exclude
option,
but
it
don't
describes
what
it
actually
means.
So
the
thing
here
is:
we
have
a
document
that
say
you
should
support
prefixes
fruit
option
and
then,
if
you
go
to
the
prefixes
fruit
option,
I
think
you
are
actually
one
of
the
co
out
or
solely
it.
Don't
describes
the
mechanism.
So
it's
actually
assuming
that
this
describe
it
elsewhere,
but
it's.
Q
Not
Michael
Abramson,
so
I
read
the
PDF
document.
That
recommends
two
different
deployment
models.
One
is
a
shared
it's
like
64
with
ia
na
on
the
one.
So
we
have
multiple
you
know:
multiple
customers
were
on
the
one
they
have
one
I
and
I
only
use
unnumbered
as
Lorenzo
said
this.
Basically,
if
we
adopt
this
as
a
best
common
practice,
we're
basically
saying
don't
do
what
VBSS.
O
Q
They
so-
and
this
is
now
a
BCP,
so
I
think
it
should
have
it
then
more
justification
for
its
recommendations.
If
we're
going
down
the
road
and
I
think
it,
we
need
more
analysis,
basically
we're
saying
some
other
large
deployments
in
probe.
You
know,
production
right
now
are
not
doing
this,
and
then
perhaps
we
should
say
why
that
is
wrong.
I'm
not
advocating
these
models,
I
prefer
the
unnumbered
model
myself,
but
the
I
mean
we're.
If
this
is
BCP-
and
it
goes
through
here-
we're
basically
saying
the
BBF
is
recommended
the
wrong
thing.
Well,.
S
Q
So
maybe
the
PCP,
it
must
be
enormous
I-
would
think
it
would
be
great
to
have
a
document
that
goes
through
the
different
models
and
says
pros
and
cons
and
informational,
perhaps
no
metal
but
BC
peeing.
This,
then
I
think
we
need
to
be
pretty
sure
what
we're
doing
and
saying
why
the
other
models
are
bad
and
we're
not
recommending
them.
Informational,
pros
and
cons
document
would
be
perfect
and
lighting.
Although
I
think
that
that's
that's,
not
a
nice
one
and
I
am
happy
to
do
that
way.
Q
O
S
Problem
we
are
trying
to
solve
here
is
this,
is
this
is
something
that
is
being
done?
It's
it's
festival,
it's
useful
and
is
not
described
it
elsewhere,
and
when
people
is
going
to
deploy
ipv6,
they
may
not
realize
that
this
is.
This
is
a
good
way
to
do
that
and
we
need
to
document
that.
Okay,
so
it's
it's
helping
people
hey,
you
can
use
one
two
seven
and
the
people
is
actually
reading
the
the
one
two
seven
as
this
is
the
only
way,
but
it's
not.
Q
So
I
fully
support
that
so
I
I
like
this
this
model
is
it
works
well
as
well,
and
I
mean
that
this
is
so
having.
This
is
having
a
pros
and
cons
document
with
all
the
models,
so
I
do
agree.
The
ITF
doesn't
list
this
model
in
operational
documents.
I
think
it
is
useful
to
bring
this
on
us
any
information
on
analysis
of
all
the
different
models
that
are
in
use
or
could
be
in
use
or,
and
so
on
and
I
mean
at
first
I
know.
O
Q
That's
also
a
way
of
doing
it,
but
so
there
are.
There
are
some
pros
and
cons
about
this,
and
if
an
operator
today
wants
to
do
this,
they
will
most
likely
be
bf
document,
and
it
doesn't
talk
about
this.
This
model
is
as
far
as
I
know,
not
in
there
I'm,
not
I,
don't
attend.
The
BBF
I
just
happen
to
read
this
document
from
another
discussion
like
a
month
ago.
So
I
would
say
this
is
useful.
Informational
analysis
break
so.
S
S
Q
And
cons
because
it
could
be
that
there
are
like
four
or
five
different
ways
of
doing
this
you're
describing
two
of
them
for
someone
else.
It
might
not
disinvite
not
be
the
best
model
because
they
have
some
other
considerations
I,
so
the
listing
all
of
them
might
might
be
good
and
I.
Think
there
were
probably
four
or
five
will.
S
J
Bonica
Juniper,
Networks,
hatless
I,
might
be
repeating
what
you
guys
just
agreed
on.
It
sounds
like
an
interesting
document,
would
be
a
survey
of
all
the
possible
numbering
some
strategies.
You
could
use
the
pros
and
cons
of
each
that'd
be
a
good
thing.
It's
just
a
little
bit
different
from
the
document
we
have
in
front
of
us
today.
F
Lee
Howard
+12
that
I
think
that's
that's
a
better
approach.
Sort
of
in
response
to
Lorenzo
I,
don't
know
that
this
is
clearly
any
better
than
any
other
model
for
numbering
that
link,
but
I
also
don't
see
how
it
harms
anything.
And
since
we
know
that,
there's
a
significant
number
of
deployments
doing
this,
it's
one
of
the
things.
F
Q
O
So
so
there
are
two
ways:
I
think
this
can
go
forward.
First
of
all,
we
do
we
basically
say
here's
what
a
bunch
of
ISPs
are
doing
and
that's
we
publish
that
or
we
say
here's
how
this
model
is
supposed
to
work,
because
that
text
is
not
in
this
draft.
It
really
isn't.
It
says
like
well,
if
you're
doing
PV,
then
you
should
do
this
and
you
should
do
that
and
then
like
at
five
side
effects
would
be
64.
O
It
doesn't
say
if
you
can
figure
on
dress
here's
what
you
need
to
do
from
an
ende
perspective.
It
doesn't
say
any
of
that
and
so
I
you
know.
If
we
want
a
document
a
new
model,
then
we
have
to
define
what
that
model
looks
like
if
you
want
to
do
that.
You
know,
at
least
if
it's,
if
it's
text
that
we
can
say,
look
if
you
want
to
make
this
work
do
this,
then
you
know
maybe
at
least
it's
of
some
use.
O
S
S
A
S
Okay,
so
history
of
this
document
in
in
ATF
98
in
Chicago,
the
working
group
accepted
RFC,
78
piece
and
that
document
included
the
new
transition,
mekinese
Plews,
h,
h,
NCP,
okay,
I
had
I
think
four
or
five
versions
of
of
that
document
before
prac,
but
right
before
practice
was
somehow
pushback
from
from
the
working
group.
It
was
just
a
couple
of
people,
not
not.
Let's
say
that
the
working
group
is
picking
up,
but
we
know
this
is
what
is
happening.
S
Very
very
few
people
actually
is
active
in
the
list,
so
in
bracket
several
choices
and
I
I,
don't
think
there
was
a
clear
consensus,
but
then
we
had
an
informal
talk,
even
one
of
the
co-authors
of
error,
C.
Seventy
seventy
eighty
four
was
in
that
in
that
talk,
and
somehow
we
agreed
to
bring
to
the
list
and
and
I
did
that
to
stop
the
work
on
changing
error,
C.
S
S
Basically,
we
have
the
same
situation
as
as
we
described
it
in
the
previous
two
meetings.
The
act
or
situation
is
people
still
need
I
peel
for
supporting
their
in
the
local
area,
networks.
I,
don't
think
residents,
networks
and
even
enterprise
networks
can
be
like
this
Perriman.
We
are
doing
right
now
here,
so
there
you
still
need
ipv4
support
and
unfortunately
that
will
be
the
case
for
the
next
three
four
five
years.
Maybe
even
more
I
I
wish
it's
just
two
years,
but
it
will
not
be
like
that.
S
So
there
is
no
way
there
is.
Peace
can
deliver
ipv6
only
service
in
the
lands?
It's
fine
for
the
ESPYs
to
have
the
access
links
which
actively
six
only
but
in
the
lands
there
is
still
meat
for
supporting
IP
before
everybody
has
unday
and-
and
you
can
still
buy
today-
ipv4
only
cameras
and
devices
of
all
kinds.
So
we
need
to
support
them.
So
that's
the
reason
for
this
document
making
sure
that
we
have
the
actual
transition
mechanism
being
supported
by
vices
right
now.
S
Error
sees
70,
84
is
only
supporting
six
of
D
and
DS
Lite,
nothing
else,
so
it
don't
makes
too
much
too
much
sense.
I
did
in
the
AP
Nick
in
Taichung
in
September
a
panel
with
C
benders
I
I,
requested
vendors
in
the
lead
in
this
list
and
contacts
which
many
vendors
that
we
had,
but
unfortunately
we
already
succeed
to
have
three
of
them,
so
we
have
dealing,
we
have
NAC
and
we
have
Saxon
and
we
were
commenting
in
that
panel.
S
This
situation,
okay,
I,
have
writen
an
article,
you
have
there
the
link,
and
there
is
also
a
recording
of
the
panel,
so
so
I
I
warned
it
the
panelists
take
care
which
what
you
said
because
it's
being
recorded,
so
everybody
can
see
that
later
it's
one
hour,
video
I,
think
it's
very
interesting
for
everybody.
I
talked
about
some
specific
issues
in
the
home
net
session.
Also,
a
couple
of
days
ago,
I
I
think
it's
it's
very
relevant
as
well
oops.
This
is
going.
S
So
what
is
the?
What
is
the
summary
of
of
the
document?
Well,
basically,
the
document
dating
had
changes
in
the
text
from
what
I
have
presented
in
the
in
the
previous
version.
It
is
just
excluding
the
support
for
H
MC
P,
so
the
document
is
talking
about
supporting
four
six
four
X
lat
map,
a
map
t
like
way
for
over
six
and,
of
course,
the
same
mekinese
that
are
already
in
RFC
seventy,
eighty
four
and
all
the
RFC's
that
are
required
to
support
those
mechanism.
Okay,
so
here
is
a
list.
S
I
am
NOT
going
to
read
that
one
of
the
comments
I
got
from
Fred
and
Ron
is
why,
in
the
document,
I
am
including
the
support
for
6:30
and
and
all
that
stuff.
Well,
I
am
including
that
just
to
make
it
coherent,
which
RFC
seventy
eighty
four,
because
we
decided
not
to
change
that.
So,
if
I
take
down
now
those
mechanism-
and
this
document
is
complementary
to
RFC
seventy
eighty
four-
it's
like
conflicting
thing
right,
I
am
happy
to
change
that
I,
I,
don't
need
and
I
don't
want
to
expand.
S
I
pick
before
I
just
want
to
make
sure
that
the
people
get
sees
that
support
ipv4
in
their
lands.
At
the
moment,
because
they
that's
what
they
need,
but
I
am
not
really
asking
the
working
group
to
keep
supporting
ipv4
at
all,
so
so
I
think
that's
that's
clear.
I
am
not
really
sure
how
it
works
to
have
this
complimentary
document.
If
we
take
that
out.
S
But
but
that's
that's
a
different
question,
this
is
going
so
basically
what
what
I
want
to
make
sure
here
is
that
the
operators
can
get
from
the
market
and
also
end
users
from
the
retail
sees
that
support
this
transition
mechanism
that
we
need
today
and
and
that's
it
but
I
I
heard
from
the
panel
and
if
you
read
the
article
I,
think
it's
very
clear.
If
you
see
the
video
is
that
in
general,
benders
don't
have
problems
supporting
all
these
mekinese.
S
In
fact,
most
of
them
have
they
already,
but
they
don't
deliver
in
the
retile
fewer
okay.
So
it's
the
same
hardware,
but
that
that's
being
provided
only
when
an
operator
ask
for
it.
The
problem
is
that,
of
course,
sometimes
the
customer
want
a
better
router,
for
example,
which
better
wireless
connectivity
or
whatever,
and
they
get.
They
cannot
replace
that
because
it's
not
available
in
the
retail
food
world,
so
that's,
that's.
It
I.
Think
yeah.
Q
S
Q
I
see
this
it's
somewhat
of
an
inventory
of
the
transition
mechanisms
that
we
think
or
or
in
potentially
will
be
in
wide
use,
so
the
for
the
six
or
differences
I
think
it's
okay,
if
it's
in
this
document,
but
it
should
just
say,
look
in
seventy
eighty,
four,
four:
six
Rd
requirements:
just
don't
copy
paste,
don't
really!
Okay,.
Q
Link
it
there
and
the
same
thing
with
the
I,
don't
know
if
16
4
is
in
that
as
well,
but
you
just
point
back
to
70
84
and
don't
you
know
redefined
with
that
yeah
and
the
other
thing
is.
This
is
an
informational
document
with
a
lot
of
must
and
should
sing
capital
letters
and
so
on.
I'm
I,
don't
know
I'm
fine
with
that,
but
is
that
the
way
we
normally
do
things
right?
Q
S
Q
S
Q
T
Barber
stark,
yeah
I
did
actually
very
specifically
argue
for
seventy.
Eighty
four
to
be
informational
and
one
of
the
big
reasons
is:
it's
really
impacted
by
whatever
the
network's
decide,
and
so
it
has
no
ability.
It's
it's
it's
a
response,
as
opposed
to
an
actual
you
know,
standard
or
anything
or
even
best,
common
practice.
It's
just
here's
what
the
access
architectures
are
doing,
and
so
here's
what
you
have
to
do
if
you're
going
to
connect
to
them,
but
one
thing
I
wanted
to
say,
was
what
I
had
hoped.
E
T
S
One
one
of
these
you
know
thing
I,
didn't
mention
before
and
I
think
at
least
one
of
the
panelists
from
the
Phoenix
session
is
here.
I
I
got
the
promise
from
another
one
that
he'll
will
be
in
the
jabber.
If
you
want
to
confirm,
is
they
set?
They
are
not
implementing
those
mechanisms
in
the
retail
fewer,
because
it's
not
a
state
that
in
any
document.
So
that's
the
relevance
of
this
document.
Yep.
Q
Michael
Abramson
again
I,
really
like
seventy
eighty
for
us
when
you're
an
operator,
it's
helpful
with
that
guidance
to
just
be
able
to
say:
okay,
we
want
you
to
implement
all
the
stuff
that
was
in
the
for
this
relevant
mechanisms.
I
think
this.
This
documents
has
value
for
the
same
reasons
for
the
transition
mechanisms.
Q
Is
it
just
easier
for
thing
it
for
operators
to
not
forget
when
they're
doing
requirements
towards
operators
with
that
guidance?
It's
it
really
nice,
oh
yeah,
I
think
it's!
It's
probably
cleaner.
If
you
just
keep
it
as
Barbara
said
and
take
out
the
before
when
access
mechanism
sudden
keep
it
as
it
is
yeah
because
I
still
think
yet
so
I
don't
know
if
I
ever
think.
This
is
about
very
valuable
as
an
inventory
of
transition
mechanism.
O
Code,
actually,
it
has
no
effect
because
when
a
CP
product
manager
decides
what
to
do
they're
going
to
ignore
this
document
so
because,
given
the
choice
of
increasing
their
product
cost
and
the
choice
of
not
increasing
their
product,
cost
they're
gonna
pick
not
increasing
the
product
cost
option,
so
I
I
personally,
don't
see
much
value,
I
think
if
there
were
value
there
it
would
be
around.
You
know
which
one
is
of
these
two
which
of
these
technologies.
Do
you
do
first,
if
both
of
them
are
available,
which
one
do
you
pick?
O
That's
almost
certainly
gonna
be
up
to
the
ISP.
One
thing
that's
valuable
I
think
is
like
which
ones
do
you
choose
you?
How
do
you
determine
what's
there
like?
How
long
do
you
wait
between
you
know
figuring
out?
What's
there
and
what's
not,
do
you
try
70
fifty
first
you
try
what
I'm
DHCP
that
I
think
would
provide
value.
You're
just
saying:
go
implement
this.
You
know,
I,
don't
know
that
anyone's
gonna
do
that
I
mean
like
we
there's
some
I
had
a
hard
battle
to
fight.
O
Just
to
basically
say
to
to
to
some
implementers
look.
784
says
you
must
not
drop
or
500
inbound.
It's
like
and
I
find
it's
a,
but
it
took
a
while
to
convince
them
but
like
getting
them
a
write,
new
code
and
implement
new
stuff,
like
that,
that's
just
beyond
the
pale
I
mean
if
they're
gonna
make
that
choice
based
on
whether
that
code
is
gonna,
provide
benefit
to
their
customers.
I
think
the.
S
What
I
heard
from
from
the
panelists,
and
also
talking
which
other
Burton
vendors
off
list
they
tell
me?
Basically
they
have
implemented
it
and
they
are
providing
it
to
ISPs
2,
RF,
coos,
okay,
so
having
it
in
the
filler
for
retail,
it
done
relink
right,
increase
the
price
I
don't
know.
Maybe
Hans
want
to
confirm
that,
but
it's
something
that
is
done.
Q
Michael
repented
again
so
I've
pointed
people
278
450
times
in
my
life
at
least
just
as
a
when
they
were
like
yeah,
we
don't
know.
What's
out
there,
it
says
what's
available
and
and
then
basically
it's
a
it's
a
bootstrap
I
mean
you
always
need
to
customize
these
things,
but
it
gives
you
a
starting
point
and
I
think
is
the
same
thing
here.
So
this
is
not
for
this
is
not
gonna
agree
with
it.
This
is
not
gonna
change.
Q
What
goes
into
the
retail
software,
but
when
I'm
discussing
or
someone
else
is
discussing
about
someone
Oh.
What
transition
mechanism
should
we
choose?
All
here
is
a
document
that
has
a
laundry
list
of
what's
available.
I
love
those
kind
of
documents,
because
I
can
just
point
it
to
them.
They
can
go,
go
where
you
read
up
and
then
we
can
continue
the
discussion
that
I
think
just
just
for
that
and
nothing
else.
This
is
a
valuable
document.
U
How
to
do
you
think
we
implement
something
doesn't
because
it
is
being
addressed
in
RFC
on
that
we
we
actually
have
our
implementation
way
before
there
was
60
84
and
a
way
before
it
was
like
sixty
two
sixty
two
zero
four,
so
we
are
and
we
we
we
do,
have
those
transition
mechanisms,
just
like
I
mentioned
in
a
unique
44.
However,
we
don't
do
it
in
the
retail
because
we
don't
see
it
is
necessary
to
be
deployed
in
the
retail
models.
So.
A
U
U
However,
we
don't
have
lost
incrementation
being
deployed
in
our
retail
product,
because
we
certainly
don't
know
and
I,
don't
see
how
user
cannot
configure
it
and
how
people
can
correctly
configure
it
before
without
a
help
or
without
us
support
from
their
operators,
and
we
don't
want.
We
certainly
don't
want
you
in
higher
increase
our
the
loading
of
our
service
customer
service
center.
So
we
decided
not
to
put
those
stuff
in
the
retail
routers
and
keep
it
as
it
is
for
today
and
to
be
very
honest:
yes,
today
we
support
six
RD&D,
a
slight.
S
S
Thing
that
maybe
I
need
to
explain
here
is
that
all
them
are
basically
the
same
code.
Okay,
so
if
you
ask
to
an
implementer,
they
will
tell
you-
and
you
can
see
the
source
code,
for
example,
for
open
wrt.
That,
basically,
everything
is
the
same,
is
the
way
you
compute
interfaces,
but
it's
it's.
It's
not
like
implementing.
Let's
say
three
different
things.
It's
implementing
one
thing
that
can
cope
can
be
computed
in
three
different
ways,
so.
V
S
V
F
Lee
Howard
I've
always
been
a
little
bit
uncomfortable
with
using
IETF
documents
as
product
specifications.
We've
done
it
several
times.
I've
contributed,
probably
co-authored
documents
to
do
that
and
still
been
a
little
conflicted
about
it
and
I
feel
like
that's
what
this
is
doing.
That
doesn't
mean
that
I
oppose
it.
It's
just.
It
feels
like
an
odd
space
for
us
to
be
and
ripe
five.
Five
four
is:
it
is
pretty
much
that
that
there's
a
ripe
pot
expect
document
that
has
been
very
useful.
F
On
the
other
hand,
it
may
be
that
one
transition
technology
is
predominant
or
one
or
two
is
predominant
in
a
given
market.
As
that,
a
CPE
vendor
may
only
be
selling
into
a
market
where
they
only
need
to
implement
one
or
two
in
order
for
those
to
be
used
by
that
ISP,
it's
further
complicated
by
the
fact
that
there's
no
benefit
to
the
CPE
vendor
directly
to
supporting
that.
Maybe
they
get
a
sticker
from
an
ISP
that
says
compliant
with
this
is
peace,
specifications
and
requirements.
F
But
in
that
case,
if
they're
trying
to
get
the
sticker,
they
don't
need.
This
document
they've
got
the
ISPs
document
only
if
they're
going
to
try
and
support
transition
mechanisms
in
many
markets
do
they
need
to
support
all
of
them
and
the
trouble
there
is
that
again,
there's
there's
no
I,
don't
think
there's
any
additional
revenue.
The
the
benefit
to
supporting
more
transition
mechanisms
is
that
the
ISP
gets
support
for
their
transition
mechanisms,
but
then
you
get
into
the
the
calculus
of
a
customer.
F
Eventually,
I
would
not
be
surprised
if
ISPs
start
saying
if
we
have
to
spend
more
money
to
give
you
an
ipv4
address,
because
you
don't
support
one
of
these
mechanisms,
then
we're
gonna
charge
you
more
and
then
we
get
into
the
conflict
between
the
ISP
and
the
CPE
vendor,
or
you
know
the
retail
market
in
some
way.
So
that's
sort
of
the
chain
of
logic
that
I
follow
to
get
to
something
has
to
be
supported
and
and
I,
don't
exactly
know
how
to
break
that
deadlock.
I'm,
not
convinced
that
recommending
we
support.
F
F
So
that's
you
know,
and
again
maybe
maybe
part
of
what
we
need
is
a
market
analysis
saying
you
know
just
listing
is
B's
and
transitions
mechanisms
in
use
for
announced,
and
that
would
help
draw
and
that
alone
definitely
not
in
all
right.
I
have
to
ITF
document,
but
that
alone
might
actually
accomplish
the
goal
that
we're
trying
to
do
here.
W
Stephen
from
Rockland
I'm,
realizing
I'm,
really
new
here
so
I,
guess
it's
really
a
new
perspective
or
for
everything,
and
so
for
from
what
I
want
to
say
is
like
I
mean.
There's,
of
course,
there's
a
lot
of
valid
arguments
about
there,
see
vendors
and
also
the
the
ISPs
and
stuff,
but
from
the
perhaps,
on
the
other
hand,
from
the
consumers
perspective,
it
would
be
really
hard
for
them
to
understand
all
of
these
technology.
We
talked
about
configurations
right.
W
So
so,
but
the
question
is
you
perhaps
having
the
right
argument
is
to
wean
a
document
for
that
or
is
that's
the
basically
what
the
the
the
DC
vendors
has
to
do
on
their
own
research?
That's
a
good
question
too,
but
it
would
be
nice
to
have
a
guidance.
I
mean
this
document
seaming
the
information.
Those
are
really
a
standard
that
everyone
has
to
adopt.
So
I
guess
it
could
be
good
compromise
in
some
sense.
Just
thought
like.
S
A
X
A
X
We've
got
lots
of
mechanisms
they're
all
good.
Most
of
them
have
got
DHCP
options
that
will
completely
configure
the
CPA
device.
I,
don't
see
why
we're
come.
What
Hal
cpe
vendor
has
real
problems.
Here
you
send
out
the
options
see
which,
which
ones
get
actually
feel
been
from
the
DHCP
server
and
configure
the
device
Andrew
and
most
of
the
many
many
of
them
you
want
to
reflect
internally
on
the
internal
side
as
well,
but
that's
basically
it
I've
got
a
I've
got
a
cable
modem.
Here
he
writes.
X
J
V
A
luncheon
and
again
I
think
Ellen
what
Martin
said.
We
are
good
toward
having
a
simple
document
versus
you
need
to
have
a
PV
for
support
and
then
start
another
piece
of
work.
Another
body
of
work,
maybe
along
the
line
of
what
Mark
said,
to
try
to
figure
out
how
to
help
you
see
vendors
to
do
it
through
the
mess
that
we
have
created
of
having
way
too
many
mechanism.
Y
In
fire
homes,
but
explain
one
of
the
things
that
I
see
as
an
operator
and
evaluator
of
potential
CDE
devices
for
purchase
is
that
from
vendors
we
try
to
get
a
kind
of
divide,
an
overcharge
approach
from
them.
So
they'll
look
at
this
one
particular
thing
and
say
all
that's
special.
No
one's
ever
asked
for
us
for
that
ever
before.
Therefore,
that's
going
an
expensive
thing,
you
know,
and
from
what
I
see
in
the
industry
overall
and
my
knowledge
of
how
these
things
are
implemented,
I
know
it's
the
same
code
base.
No,
no.
Y
S
The
document
I
have
an
introduction
section
that
explained
the
problem
this.
This
gives
me
back
to
the
suggestion
from
Alan
to
split
it
into
documents.
I
think
actually,
it's
use
is
more
useful
to
have
it
in
a
single
document,
so
then
to
the
action
that
probably
needs
to
be
updated
with
some
of
the
inputs
from
from
here
today,
but
I
see,
there
is
a
very,
very
clear
explanation
already
in
the
document
why
we
need
type
in
for
a
service
and
then
here
are
the
options.
Y
I
mean
the
idea
here
was
really
to
have
some
text
that
recognizes
that
you
know
there's
a
number
of
different
things
here,
we're
not
recommending
mandating
or
anything
any
one
of
these
just
saying
if
you
wish
to
implement
this
particular
function.
These
are
the
requirements
for
that
function.
Okay,.
S
S
Y
S
Y
Y
Mean
to
my
first
point:
I'm,
not
thinking
further
about
that,
whether
it's
worth
saying
in
here
that
the
data
plane
is
is
common
and
you
know
there
is
reusable
code.
I,
don't
I,
don't
know
if
that's
something
that
should
go
in
here,
but
it
might
be
worth
having
here's.
Some
kind
of
indication
of
that
is
also.
A
V
Just
responding
to
what
Jodi
said
and
document
there's
a
lot
of
sholde
in
there
and
I
think
maybe
we
should
remove
them
is
ability
if
you
want
to
go
the
way
you're
suggesting
you
should
point
to
the
other
document
and
says
everything
is
explained,
enforce
documents
and
not
add
additional
requirement
or
additional
Xu
to
what
humans
are
already
saying.
Okay,.
S
Let
me
let
me
explain
that
very
quickly.
What
I
am
doing
again
is
following
the
same
scheme
that
Arif
c70
84
is
doing.
So
what
is
being
done,
then,
for
the
document
see
for
its
transition
mechanism
is,
if
you
want
to
support
this
you
should
you
understand
that
so
I
am
NOT,
saying
you
should
support
everything
like
that.
If
you
want
to
do
map
you,
should
this
so
I
am
NOT,
saying
well.
Q
K
Q
O
Now
the
render
could
be
I.
I
wanted
to
maybe
start
off
with
the
responding
to
something
that
Mark
said.
Most
of
these
things
have
dhcpv6
options.
I
want
to
say
that
I
feel
physically
safe
separated
by
thousands
of
miles
when
I
say
that
for
six
Forex
lat
and
it
doesn't
have
a
DHCP
option,
it
uses
70
50
dns64,
as
the
provisioning
mechanism.
O
I
only
feel
safe,
because
I'm
separated
by
thousands
of
miles
and
saying
that,
but
so
it's
a
bit
of
troubling
if
you
want,
but
what
one
I
did
want
to
get
back
on
what
Mark
said
and
what
iam
said,
which
is
the
mark
is
saying
well,
the
ISP
has
the
opportunity
to
control
all
the
stuff
by
using
DHCP
options
and
Ian
said
we
just
get
charged
five
times
for
the
same
code.
Stop
it
already.
One
thing
I
wanted
to
observe
about:
that
is.
O
If
we
have
a
document
that
says
here,
are
the
rules
of
the
game?
Try
this
first
try
that
first
prefer
this
prefer
that
then
what
you
can
do
is
you
can
avoid
divide
and
conquer
by
implementing
all
of
the
mechanisms,
and
then
you
say:
hey
CPU
vendor.
If
you
implement
at
least
one
of
these
you're,
not
gonna
charge
me
twice,
because
you
already
have
it
and
we
support
it
on
the
network
side.
O
You
can,
if
we
have
a
document
that
says,
do
these
in
this
order
or
do
these
based
on
these
policies,
then
you
can
try
to
like
overcharge
each
other
or
not
overcharge
each
other,
and
you
don't
have
a
stalemate
that
that's
all,
and
so
one
thing
that
might
be
a
valley
here
is
to
say:
look
you
know
if
you
have
this,
do
this
otherwise
do
that
and
provide
a
essentially
a
provisioning
order
or
something
because
if
you
support
map
then
do
map
is
not
useful
texts.
I
agree
with
Ellen
right.
F
Lee
Howard,
especially,
was
something
that
Lorenzo
said
was
a
I
think
a
good
point
that
I
had
come
up
to
ask,
among
other
things,
that
that
I
didn't
understand
the
point
about
not
about
lack
of
clarity
on
how
to
decide
which
mechanism
to
provision,
because
you
get
a
DHCP
option
and
if
you
get
options
telling
you
to
provision
multiple
mechanisms,
then
you
have
a
failure
and
it
doesn't
matter
how
many
you've
implemented
or
not
implemented.
Yet
somebody's
done
it
wrong.
F
If
we
wanted
to
create
a
new
scenario
that
that
said,
step
through
various
ones
that
well,
you
know,
hey
thanks
everybody.
This
is
great
for
my
business,
but
in
particular
you
put
your
right
learns
or
that
dns64
and
forceps
Forex
lat
aren't
exactly
DSP
provisioned
so
that
that's
a
that's
a
different
case.
I
think
there
is
potential
logic
there
where
to
say:
if
you
don't
get
a
provisioning
option
for
one
of
the
other
mechanisms,
hey,
maybe
you
want
to
try
and
you
only
have
v6
availability.
Maybe
you
want
to
try
see
lat.
F
F
It
looked
to
me
I,
tweeted,
a
couple
months
ago
that
in
four
years
80%
of
the
world
will
have
ipv6
that's
getting
pretty
close
and
I'm,
not
I,
don't
want
to
say
the
lifetime
of
an
RFC
is
is
forever
we
can
deprecated
later,
but
that's
just
the
maintenance
that
we
need
to
do
saying
here
are
mechanisms
and
here's
how
you
can
do
this
I.
Do
think
that,
obviously,
for
my
business
I
think
the
transition
mechanisms
are
necessary
for
some
time,
but
I
don't
want
to
say
that
ipv4
is
forever.
A
S
Okay
I
started
working
in
this
document
after
we
have
I
think
it
was
in
Prague
a
discussion
of
using
nat64
as
the
default
IDF
networks.
We
are
doing
right
now
here.
I
was
suggesting
why
not
using
464xlat
in
state,
because
we
know-
and
it
has
been
confirmed
with
this
quick
here-
that
some
applications
still
break
in
the
nat64
network.
S
P
S
What
happens
most
of
the
time
is
that
operators
for
non
cellular
networks
done
know
that
for
64
X
lab
is
also
useful
in
the
in
those
cases.
Right
now
there
is
some
initial
deployment
of
46
for
X
lab
in
non
cellular
networks
and
I
see
the
case
for
documenting
that
and
I.
Think.
A
lot
of
people
is
missing
that
that
possibility,
especially
when
they
have
bought
a
cell
random
cell
remember.
It
makes
a
lot
of
sense
to
have
a
single
transition.
Mekinese.
S
So
this
will
be
the
case.
I
am
just
describing
an
operator
having
bought
a
cellular
and
non
cellular
networks,
and
the
point
here
is
to
describe
and
I
believe,
is
a
B
city
that
we
can
do
that.
Okay,
again
is
st.
questioners
and
in
the
previous
document
the
first
one
I
presented
today.
I
am
not
sure
if
the
BCP
status
is
the
way,
but
I
really
believe
that
is
probably
the
best,
especially
considering
that
464
X
lat
today
is
not
a
standard
compared
to
the
other
transition
mekinese.
S
So
this
is
a
way
to
to
tackle
dot
but
situations
describing
the
actual
deployment
and
also
making
for
six
for
X
less
somehow
at
the
same
level
as
the
rest
of
the
transition
mechanism
to
deploy
for
6
for
X
lat,
you
need
to
follow
about
10
documents,
so
I
think
documenting
in
a
single
document.
It
will
be
also
very
useful
for
people
that
that
really
want
to
go
to
that.
Instead
of
trying
to
find
all
the
documents
related
to
that
they
have
a
single
place
to
read
all
what
they
need
to
do.
S
Ok,
what
I
am
doing
in
the
document
is
looking
at
DNS
SEC
considerations,
so
there
are
different
ways
to
deploy
for
6
for
X
lat
to
avoid
breaking
DNS,
SEC
I
described
also
how
to
deploy
for
6
for
X
lat
and
the
pros
and
cons
which
and
without
dns64-
and
there
are
other
sections
in
the
document.
The
document
is
a
lot
about
dns64
because
it's
part
of
the
problem.
Ok,
if
you
you
want
to
deploy
for
64x
lab.
S
This
is
not
typically
a
problem
in
cellular
networks,
because,
typically
it's
not
being
used
DNS
SEC
on
the
on
the
smartphones,
but
we
are
forgetting
that
the
smartphones
can
be
used
as
with
stuttering,
so
other
devices
behind
can
be
used
can
can
use
the
NSX,
so
I
think
it's
also
useful
for
those
for
those
kinds
of
networks,
not
just
for
non
cellular
networks.
So
the
document
is
not
targeted
to
silver
or
non
cellular
is
targeted
to
any
four
six
four
X
lab
deployment
and
I
think
that's
it
basically.
O
I
think
the
Apple
engineers
are
in
the
room,
but
they
will
tell
me
that
they,
they
will
probably
tell
you
they'll,
never
implement
four
six,
four
X
lat
and
the
truth
is
you
don't
even
need?
This
is
not
even
about
four
six
four
X
that
what
you're
saying
is
you
can
do
I
think
what
you're
saying
is
you
can
do
nat64
dns64
on
a
non
cellular
network.
That's
certainly
a
useful
thing
to
say
we
support
it.
For
example,
Android
supports
it.
O
I
think
there's
value
in
stating
certain
things
about
that,
for
example,
that
you
know
what
do
you
do
about
neighbor
discovery
of
the
address
that
you
need.
I
disagree
for
one
with
the
assertion
that
you
need
a
dedicated
64
for
the
classic
for
the
Clapp
prefix.
We
don't
implement
it.
I,
don't
think
it's
necessary,
there's
already
two
nets
in
the
path:
I,
don't
care
if
you
had
a
third
one,
so
I
the.
On
the
other
hand,
the
DNS
SEC
issues
are
things
that
we
do
need
to
document.
O
We
need
to
slog
through
those
and
we
we
need
to
say
you
know:
you'll-
have
to
come
to
peace
with
Mark
Andrews,
and
you
know
on
how
to
figure
out
how
to
do
this
safely
in
terms
of
DNS
SEC.
It's
true
that
you
could,
if
you
have
a
cloud
implementation,
that's
line
right,
which
we
don't
have
at
least
not
in
stock
Android.
You
could
send
all
the
traffic
through
for
six
for
Excel
and
some
operators
do
want
to
do
this.
O
It's
not
clear
to
me
what
you
can
do
on
an
Apple
style
approach
where
you
never
use
clap
and
you
always
rely
on.
Basically
the
six
only
amps.
So
if
you
know
if
I
were
to
summarize
that
I
would
like
not
make
this
about
four
six.
Four
excellent
I
would
make
this
a
document
about
how
to
empower
do
how
to
provide
service
on
a
nat64,
dns64
network.
Think
really
from
a
host
perspective.
I
think
forget
about
4,
6,
4,
X,
4,
6,
4,
X
9
is
one
way
you
can
do
this.
O
S
O
You
know
Mark
was
saying
on
the
list.
I
think
he
said.
Look
you
know.
All
you
need
to
do
is
to
stub
out
ipv4
only
darpur
and
and
basically
that's
the
only
I
think
what
he
said.
Is
that
that's
the
only
name.
Do
you
need
to
do
dns64
for
and
that's
fine
right,
I
mean
I
you.
You
can
do
that
right
that
that
solves
that
problem,
yeah
areas.
X
N
Unfortunately,
you
haven't
even
implemented
stateless
Jesus
Christ
and
a
stateful
nat64
in
a
network
that
is
464xlat
and
sure
you
can
use
that
Nazis
for
for
other
purposes,
and
you
can
let
die
p6
only
applications
use
that
Nazis
for
to
reach
the
legacy
before
internet.
That
doesn't
mean
that
that's
part
of
four
six
four
X
lack,
so
the
dns64
discussion
is
about
Nazis
for
it's
exactly
the
same
discussion
we're
having
here
on
the
ITF
network
and
you
should
not
muddle
them
together
for
six
for
X.
N
That
is
just
a
v4
tunnel
with
zero
wanker,
like
we
have
fifteen
other
mechanisms
doing
that
those
do
not
have
DNS
problems.
That's
six!
Four!
Do
you
really
have
DNS
problems
and
I
agree
with
mark
which
just
hold
them
I
sort
of
thought?
The
discussion
we
had
on
the
list
sort
of
peeth
around
saying:
well,
you
shouldn't
have
dns64,
you
should
let
the
host
synthesize
addresses
itself.
Then
you
have
no
dependency
in
which
DNS
recursive
resolver
you
need
to
use.
I
can
use
you
know.
N
K
X
S
O
Not
that's
not
true.
Nat64
is
the
most
successful
transition
that
can
well
the
combination
of
but
usage
usage
of
nat64
dns64
is
split
between
implementations
to
do
4,
6
or
X
lot
and
implementations
to
tell
the
apps
you
can
have
a
before
dress
ever
okay.
So
what
I
think
we
need
to
do
it
well
and
to
answer
your
question?
Work
I,
think
why
are
we
doing
dns64,
not
64,
I?
Think,
let
me
let
me
see
if
I
can
prove
identify
something
of
value
here.
O
So
what
we
can
say
is
there
is
a
solution
with
widespread
host
support
in
whichever
way
that
allows
host
to
work
on
an
at
6-4,
dns64
Network.
Now
the
thing
that
we
need
to
figure
out
from
there
is:
how
do
we
do
this
without
breaking
the
MSM
and
I
think
that's
an
important
discussion
and
then
we
need
to
get
away
from
4
6,
4
X
lat
as
being
in
this
document.
So
what
I
would
suggest
is
make
this
document
about
how
to
do
Nats
ik
for
dns64,
without
breaking
the
NSX
on
hosts
and
I.
G
Learning
curve
I
just
like
to
comment
on
whether
or
not
successful,
because
there
is
a
use
case
we
in
some
cases
you
do
not
want
to
do
not
want
to
have
ipv4
address
on
an
end
host.
All
other
transmission
technologies
still
like
dolls.
That
light
and
other
stuff
still
requires
you
to
have
ipv4
address
on
a
host,
and
then
you
can
have
some
part
of
your
infrastructure
in
v6.
G
Only
so
I
think
not
6:4
is
the
current
is
only
a
way,
can
help
e6
only
host
on
the
network
without
changing
everything
on
the
force
and
require
they
doing
some
tricky
stuff
and
from
my
experience
most
things
just
work
on
not
64
years.
There
is
like
some
percentage
of
broken
sinky,
like
did
not
second
meet
Idris
Lorenz.
We
need
to
figure
out
how
to
do
that
and
measurement
I
did
two
years
ago
showed
that
signed
names
without
quad
area
court
was
one
point,
seven
percent.
G
So
it's
not
like
a
huge
number
right
and
I
probably
need
to
do
it
again
and
see
if
it's
decreasing
or
increasing,
because
it
will
be
because
again
we
trying
to
solve
problem
for
the
people
who,
for
some
reason,
like
DNS
yet
but
do
not
want
to
do
v6
and
again
ICS.
My
action
ID
money
to
chat
with
numbers
again
yeah.
But
it's
not
such
a
like
huge
issue
and
I
am
strongly
against
putting
too
much
pressure
on
a
host
which.
G
X
X
We
should
we
at
the
moment.
We've
created
a
situation
where
you
can't
deploy
DNS
SEC
unless
you've
already
also
deploying
ipv4,
and
that
I
am
applying
ipv6,
and
that
really
is
something
we
shouldn't
have
come
to
and
as
for
the
as
for
the
percentages,
ask
Google
about
when
what
numbers
they
needed
for.
A
AA
Tranform
share
of
telecom
two
comments
about
the
scope
of
this
document.
Well,
firstly,
is
about
the
scenario
it's
in
that
axelay
tonight.
Technology
is
likely
to
be
used
in
broad
if
fixed
at
network
region
short
term.
It
is
possible
to
be
widely
used
in
mobile
network,
so
my
suggestion
was
it
was.
It
was
narrow
scope
with
document.
Many
folks
are
mobile,
cellular
network.
AA
The
second
one
is
that
right
now,
the
as
far
as
we
know
that
more
a
network
many
serve
not
only
that's
innate,
supported
and
I
enjoyed
the
system,
but
also
supported
some,
as
a
study
has
iPhone
that
device,
so
some
of
them
supported
axon
eight.
Some
may
not
support
axon,
eight.
So
from
the
perspective
of
our
operators,
we,
maybe
it
is
too
narrow
to
define
how
to
deploy
at
Slate.
You
know
like
work.
AA
H
S
AA
Maybe
it
is
possible
to
deploy
only
cellular
networks,
but
because
the
broadband
fix
that
work
with
a
variety
of
a
customer
different
tabs
Cosmo,
yes,
so
reduce
that
maybe
the
mainstream
you
shot
her
with
not
only
home
that
house
for
the
users
will
mixed
up.
We
also
need
to
serve
and
twice
Cosmo,
so
ipv4,
maybe
maybe.
S
I,
don't
agree
with
that,
because
what
I
am
doing
with
customers,
especially
in
Latin
American
Central
America,
is
actually
they
don't
have
addresses
and
they
really
need
to
deploy
ipv6
only
access
networks
to
broadband
customers-
and
this
is
the
way
they
are
doing.
I
have
right
now
three
trials
with
10,000
customers
among
these
three
trials,
using
for
six
Forex
lat,
okay,.
A
S
A
S
Question
I
will
last
not
just
for
this
document,
for
all
them.
I
will
continue
working
in
on
all
the
documents
from
today
and
and
from
today's
ago,
I
will
like
to
have
some
Co
outdoors
in
some
of
the
documents.
So
it's
not
just
my
point
of
view,
but
but
also
so,
if
somebody
is
interested
in
cooperating
in
the
documents,
please
contact
me
as.
A
Thank
you,
so
one
of
your
documents
earlier
today,
I've
actually
already
posted
the
list.
Saying
do
we
want
to
adopt
this
and
how
do
we
want
to
proceed
that
one
for
sure
this
document
so
bring
bring
us
back
something
the
others
I'm
not
so
sure,
let's
see,
but
but
in
any
event
that
exhausts
our
agenda
just
only
threw
out
a
Oh
beat
somebody
wanted
hold
forth
and
rant
for
oil,
if
not
I'm,
going
to
adjourn
the
meeting.
So
yes,
thank
you.