►
From YouTube: IETF106-DHC-20191118-1000
Description
DHC meeting session at IETF106
2019/11/18 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
C
C
Okay,
so
I
would
like
to
do
it,
but
yeah
also
there's
either
part
it's
helpful
and
if
you
helped
write
the
minutes,
it's
like
collaborative
effort.
So
this
is
the
deep
sea
open.
So
there
are
two
chairs.
This
is
pennyvos
and
I'm.
Talkin
grass
grow
okay.
So
what
we
have
for
the
agenda
today
administrivia
this
is
they
think
I'm
going
to
write
now
after
that,
we're
going
quit
the
problem
statement
of
Muccino
current
extensions
for
HPV
6
after
that
two
presentations
from
Ian.
C
C
And
finally,
we
have
a
discussion
about
advancing
hep-2
to
full
standard,
so
team
will
be
running
the
show
okay.
So,
what's
the
document
status
we
have
several,
the
number
of
drafts
is
decreasing,
which
is
good,
but
still
there
are
some
some
new
appearances,
so
the
first
one
and
visit
yank.
So
this
is
something
that's
on
agenda
today,
maka
sang
it's
still
going
through
the
last
call.
Bernie
and
I
will
talk
about
wrapping
this
up
in
couple
days,
but
there
is
still
time
to
to
share
your
comments.
So
if
you
have
some
time,
please
read
it.
C
It's
it's.
A
short
draft
I
mean
it's
like
twelve
or
fourteen
pages,
so
the
next
one
a
problem
statement
of
Emory.
This
is
only
a
non-agenda,
the
next
draft
bitch-slapped
quadrant.
This
is
something
that's
also
in
the
school.
So
again,
these
show
your
comments.
And
finally,
the
last
relative
drafts
of
this
is
to
individual
the
preface
delegating
really
it's
on
the
agenda
and
I
think
that's
it
regarding
administrivia.
So
let's
go
with.
C
First,
let's
have
a
quick
recap
of
this
document.
We
introduced
them.
Multi
requirement
extensions
for
dhcpv6
in
IETF
98
in
Chicago
for
the
first
term
and
the
ITF
104
in
program
pract.
We
presently
do
this
work
and
the
community
can
see
related,
Deborah
and
Bernie
to
me
and
some
other
people
as
Melanie's
to
keep
valuable
comments
on
this
document
and
we
up-to-date
updating
the
two
versions
to
solve
the
open
issues
before
IETF
106.
C
The
main
changes
society
of
104
includes,
in
figure
1
the
general,
the
general
th,
the
comodo.
We
modify
the
message,
processing
functions
into
message,
overlaying
functions
for
dhcp
relays
and
we
modify
the
your
the
general
model
by
adding
external
entities
and
inputs
I
mean
section
for
point
to
point
for
way
in
the
previous
version
way
say
with
basic
server
strategy
general
to
random
justice.
C
But
in
this
version
the
current
will
say
currently
the
server's
assigning
addresses
prefix
and
there's
some
some
other
configuration
options
to
the
to
Thea,
configure
the
policies
and
we
will
move
the
16th
section.
Four
point:
two
point:
five,
the
extension
principles
and
explain
rates
it's
contained
in
the
introduction,
and
we
talked
about
enforcing
local
policies,
as
use
cases
using
more
generic
languages
in
Section
five.
C
This
is
a
original
DHCP
general
model
and
which
includes
message,
messages,
options
and
the
messaging
processing
functions
and
adjust
generation
mechanisms
and
when
modify
it
in
the
new
old
version-
and
this
is
a
modified
reg
state,
each
a
new
model-
and
we
add
external
inputs
and
videos
in
this
version
and
to
make
it
more
general
and
clearer
and
for
HTTP
for
messaging
extension.
We
can
not
only
define
the
ODST
messages
to
in
which
these
functionalities,
but
also
we
can
extend
the
new
messages
to
enhance
its
security
for
option
extension.
C
We
can
fix
a
few
basics,
allows
defined
me
almost
no
options
to
just
meet
parameters
between
the
HTM.
It
is,
and
also
we
can
define,
define
new
option.
Also,
the
options
can
make
him
may
come
from
may
come
from
external
inputs.
For
example,
I've
seen
74
37
defines
and
defines
the
various
options
to
to
exchange
authorization
and
identification,
information
between
DHCP
relay
and
DHCP
server
on.
D
A
I
think
originally
the
problem
was,
you
know
they
wanted
a
way
to
generate
addresses
with
semantics
in
them,
right
and,
and
maybe
I
want
to
go
back.
Maybe
some
of
that
got
lost
okay,
and
so
it
it's
a
question
of
that.
Do
we
you
know,
do
we
add
that
back
in,
if
it's
not
clear
or
should
we
just
change
the
title
to
make
it
more
of
a
survey
yeah.
C
C
B
B
B
So
what
I
propose
and
what
we
ended
up
doing
was
basically
refocusing
on
just
getting
a
decent
model
that
covers
what's
in
84,
15
the
boil
the
ocean
problem
of
that
we
originally
set
ourselves
and
I
think
what
he
dramatically
underestimated.
What
was
going
to
be
possible
of
trying
to
model
kind
of
the
the
state
of
the
art
of
the
protocol
yeah
the
resulting
work
was
just
was
just
too
huge.
B
Refocusing
on
84
15
has
given
us
something
which
is
much
much
easier
to
work
with
I
think
they're,
much
much
easier
to
read
and
unholy
for
people
to
review
as
well.
We've
also
managed
to
do
this
in
a
way
that
I
don't
think.
We've
ended
up
with
too
much
duplication
of
functionality
and
duplication
in
the
models
as
well.
So
we've
got
quite
a
good
you
reuse
mechanism,
which
I'll
I'll
come
on
so
on
later
slides.
Could
we
go
to
the
next
one?
Please
so.
B
Strangely
enough,
we
kind
of
overlooked
how
this
model
or
the
models
would
interface
and
in
to
work
with
other
existing
gang
models,
and
you
know
particularly
around
IETF
AI
interfaces.
Sorry
I,
don't
know
quite
how
we
managed
to
do
that,
but
there
we
are
so.
We've
restructured
this
to
use
the
existing
interfaces
tree
that
ITF
in
interfaces
provides
us
with,
and
then
we
take
this
and
add
in
the
functionality
that
we
need
on
top
of
the
already
existing
interface
rich,
that
that
provides.
B
What
this
then
means
is
that
for
every
interface
that
you
wish
to
provide
configuration
for
it
kind
of
gives
you
a
structure
in
which
that
can
all
be
built,
and-
and
you
know
it
makes
it
for
a
much
better
into
working
well
with,
what's
already
there
and
I
think
it
lacks
just
a
lot
more
sense
as
well,
and
we'd
also
overlooked
any
data
about
any
state
data
and
timer
data,
which
again
seems
to
be
a
fairly
glaring
omission.
Now
that
I
came
back
and
looked
at
it,
so
that's
fixed
as
well.
B
We
removed
a
lot
of
the
stuff
that
was
done
in
features
in
the
path
of
one
thing
that
we
have
less
left
and
I.
Think
the
only
existing
remaining
feature
actually
is
prefix
delegation
is
obviously
not
every
client.
Has
that
and
we've
also
gone
back
and
and
cleaned
up
a
lot
of
the
notification
stuff.
That's
wasn't
really
working
either
next
slide.
Please.
B
So
a
lot
of
the
things
that
we've
decided
that
were
really
implementation.
Specific
we've
now
just
shifted
out
of
the
sole
model,
because
really
there's
no
realistic
way
that
you
can
try
and
cover
things
that
are
going
to
please
every
implementation
in
there.
So
you
know
the
best
solution.
There
was
just
not
to
try.
B
We
also
think
a
lot
of
the
value
of
of
having
a
common
model
here
is
around
and
where
a
lot
of
your
investment
in
building
network-wide
configurations-
and
you
know
the
time
that
goes
into
that-
is
actually
around
client
configuration
and
orde-lees
configuration
pools.
The
network
objects,
and
you
know
the
other
things
around
that,
and
so
we
kind
of
said,
a
relief
if
that
stuff
can
be
built
and
that
can
be
transferable
between
different
implementations.
Then
that's
that's
a
much
higher
value
than
saying
it.
B
We
wonder
model
is
also
transferable
for
implementation,
specific
functionality
as
well.
So
I
think
we,
you
know,
that's
how
we
decided
to
structure
it,
but
I'll
talk
about
that
a
little
bit
further
in
a
second
yeah.
So
anything
around
things
like
database
backends
interface
configuration,
we
shifted
this
out,
there's
no
exists
in
the
appendix
I'm,
guessing
or
mented
into
a
particular
container,
which
is
provided
for
exactly
this
purpose
as
it's
necessary.
B
Next
slide.
Please,
the
same
thing
thought
process
went
behind
the
client
class
selection
process
as
well.
So
Michael
did
some
digging
into
I
forget
how
many
implementations
it
was,
but
it
was
probably
about
five
or
something
I.
He
looked
into
and
found
that,
whilst
the
way
that
we
classify
incoming
messages
so
that
we
can
give
them
the
right
options,
the
right
select
addresses
from
the
right
port
and
things.
This
is
a
common
problem
that
needs
to
be
solved.
B
There's
a
lot
of
variance
in
how
this
is
configured.
This
is
how
it's
described
and
and
also
kind
of,
the
idea
behind
how
its
structured.
So
once
again,
we
thought
that
the
best
thing
to
do
here
was
just
to
take
that
functionality
out
of
the
main
model
and
provide
a
example
set
of
this,
which
we've
moved
into
an
appendix
and
show
how
this
would
into
work
and
show
how
you
could
you
know,
take
either
the
bond
model
that
we
have
there
or
your
users
basis
for
building
your
own
next
slide.
Please.
B
Another
thing
that
really
was
spiraling
out
of
control
in
the
original
model
that
we
had,
although
the
version
8
model
was
the
modeling
of
DHCP
options,
I
mean
I,
think
we're
up
to
one
hundred
and
thirteen
hundred
and
forty
now
or
something
like
that
with
a
few
omissions
in
there
and
originally
we've
taken
this
this
idea
of
saying.
Well,
we
can
you
know
from
a
modeling
perspective,
the
the
structure
of
a
DHCP
option
makes
it
fairly
trivial,
although
somewhat
labor-intensive,
to
to
model
these
things.
So
we
tried
to
do
this.
B
We
tried
to
model
every
option
that
was
out
there.
We
then
tied
ourselves
in
a
different
knot
of
saying.
Well,
how
do
you
deal
with
variance
of
implementations?
How
do
you
deal
with
the
fact
that
some
options
are
only
relevant
for
clients?
Some
are
relevant
for
relays
that
are
relevant
for
survey,
servers
or
pretty
much
any
permutation
of
of
those
as
well,
and
we
ended
up
with
a
rather
nasty
set
of
features
and
things
that
did
you
know
it.
Just
the
the
more
the
options
went
in
there,
the
the
uglier
the
whole
thing
got.
B
B
We
use
an
identity
mechanism
to
define
what,
whether
it
didn't
with
a
client
or
server
or
relay,
and
we
augment
the
options
based
on
what
that
identity
is,
as,
as
is
relevant,
what
this
also
actually,
if
you
can
move
on
to
the
next
slide,
what
this
also
does
is
provides
us
with
an
easy
way
of
making
it
extensible.
So
the
format
that
we
defined
in
the
84
15
set
of
options.
B
We
also
can
do
for
really
as
many
as
necessary
and
then
the
idea
being
that
a
device
which
implements
those
particular
options
can
would
obviously
implement
the
yang
model.
That
would
support
those
option
to
define
the
configuration
of
those
options,
and
so
those
can
be
loaded
accordingly
and
then
we
get
ourselves
out
of
the
future
mess.
So
again,
we've
gone
down
the
line
of
providing
an
example
of
this.
We
used
our
330
319
because
it's
the
first
numeric
set
of
options
that
don't
exist
in
84,
15
and
they're,
also
nice
and
simple
as
well.
B
So
it
was
a
good
candidate
for
for
an
example.
So
we
provide
this
yang
module
in
there.
We
show
how
that
can
be
augmented
into
place,
there's
also
9
or
10
guidelines
that
are
in
there,
which
which
describe
how
we're
doing
the
naming
conventions,
how
well
a
bunch
of
different
other
things
that
would
hopefully
make
it
pretty
easy
for
people
in
the
future
to
follow
the
same
kind
of
format
and
come
up
with
a
set
of
you
know
a
yang
module
that
will
work
within
this
mechanism
and
would
be
consistent
with
everything
else.
B
B
30
minutes
for
this
seems
a
little
bit
ambitious,
so
yeah.
We
think
we've
now
got
everything's
in
84
15,
which
is
kind
of
reset
herself.
The
scope
to
do
one
thing
that
I
would
be
interested
in
here
is
for
anyone
who
reviews
or
anyone
who's
had
a
look
at
this
is
the
scope
enough
now
I
mean
you
know,
we've
pared
it
down.
So
significantly.
Have
we
gone
too
far,
and
you
know
if
so,
what
are
the
the
essential
things
that
would
to
go
into
here?
To
give
us?
B
B
The
amount
of
work
that's
gone
into.
This
has
been
because
there's
been
so
much
kind
of
restructuring.
Rebuilding
rewriting,
doubtless
gremlins
have
crept
in
in
here
as
ever
the
time
caught
up
with
us,
and
so
we
were
kind
of
rushing
to
get
the
the
thing
out
of
the
door
before
the
final
deadline.
With
that
you
know,
the
big
change
is
in
place,
so
it
needs
really
more
eyes
on
it.
B
From
that
respect
as
well
yeah,
so
I
think
that,
with
this
version
its
it
feel
and
that
you
know
the
way
that
it's
an
is,
is
just
basking
basking
better
than
what
we
had
in
the
past
and,
from
my
perspective,
III
think
that
we
we're
getting
to
the
stage
where
you
know
it's
ready
to
start
so
thinking
about
a
worker
last
call
process,
for
it
obviously
subject
reviews
comments
and
to
get
it
there.
So
that's
everything
I've
got
for
you
on
this
one.
Any
comments.
D
And
thanks
again
and
thanks
for
getting
up
very
early
for
this
suresh
krisshnan,
so
one
thing
I
noticed
like
that
seems
wrong.
Is
the
revision
handling
for
this?
So
this
version
is
really
not
backward
comparable,
although
one
so
I
think
you
need
to
bump
up
the
revisions
on
the
yang
modules
at
the
minimum
in.
B
D
A
Revolts
and
you
foresee
that
there
might
be
a
companion
document
that
does
the
remaining
options
and
or
how
do
you
see
that
sort
of
you
know
I
mean
you
you
mentioned
I
haven't
looked
at
details,
but
you
mentioned
there
were
some
naming
convention
guidelines
and
things
like
that.
But
I'm
just
wondering
you
know
what
you
feel
I
mean
it
may
be.
B
I'm
thinking
about
things
like
come,
what's
the
course
sorry,
it's
very
early
in
the
morning
lease
query
and
stuff
like
that.
Both
of
these
query,
it
things
you
know,
there's
an
option-
that's
defined
there,
but
what
it's
actually
specifying
is
a
bunch
of
other
configurational
stuff
that
the
server
would
need
to
be
able
to
handle,
and
so
just
defining
the
options
necessary.
For
these
query
is
not
a
lot
of
use
to
you.
If
you
don't
have
the
rest
of
the
stuff.
That's
in
there,
however,
I
think
it
would
be
possible
to
totally
you
know.
B
Go
through
the
option
set
and
I
mean
I've
got
lists
that
I've
made
of
where
I've
attempted
to
do
this
down.
You
know
so
yeah
we
could
do
a
companion
document.
That
just
says
here's
all
the
low-hanging
fruit,
but
you
know
when
it
comes
to
see
the
prefix
delegate,
the
least,
query
and
stuff
like
that.
It
would
need
a
much
much
more
detailed
look
at
how
to
do
it.
A
B
B
You
know
with
with
some
of
these
things
it
just
comes
down
to
whether
anyone's
interested
enough
to
actually
be
I
want
to
do
the
work
around
here.
I
think
you're.
Right,
though
you
know,
maybe
something
that
defined
the
7277.
You
know
generic
option
formats
that
would
be
useful
in
previous
versions
of
the
module.
I
think
we've
tackled
that
anyway,
so
you
know
taking
the
thing
and
wrapping
it
inside
the
format
that
we're
now
decide
that
we're
now
using
four
options
would
be
easy
to
do
likewise.
B
A
C
Know
this
don't
do
ask
you,
there's
also
the
question
whether
we
really
need
to
specify
all
the
options.
I
mean
so
on
solver
options,
our
protocol
options
and
they
are
generated
by
the
server
and
they
are
not
explicitly
configured
so
like
you
brought
up
the
lease
query.
So
the
basically
query
there
is
nothing
clearly,
no
option
value
that
you
have
specified
in
the
server
side.
This
is
just
a
configuration
of
you
enable
or
disable
the
feature,
and
this
is
nobody
to
option.
B
B
But
I
mean,
though,
that
as
Bernie
says,
you
know
that
I
think
there's
two
kinds
of
options
here:
the
there's
ones
that
are
just
here's,
a
for
Matt,
here's
a
dataset
and
you
know
you
implement
it
or
you
don't
and
there's
things
that
require
much
more
back
in
configuration
on
there
and
you
know,
I
mean
if
we
can
just
divide
the
things
up
and
then
produce.
You
know
the
relevant
module
to
that.
As
I
say,
I
mean
it's,
it's
labor-intensive,
but
it's
it's!
It's
easy
to
do.
C
A
We
have
one
hand
out
there:
okay,
well,
that's
better
than
nothing,
but
you
know
do
take
a
look
and
send
your
comments
to
the
authors
so
that
they
can
do
these
cleanups
and
get
help
with
that,
and
you
know
we'll
keep
working
away
at
this.
It
is
a.
It
is
a
big
challenge.
It
is
a
big
task.
They
do
this,
it's
not
as
trivial
as
a.
C
B
B
B
Yeah
apologies
for
this
at
the
0
1
went
out,
and
there
were
there
were
one
or
two
things
that
we
said
that
we
would
incorporate
on
there
based
on
an
early
review
comments
that
weren't
telling
there
particularly
the
document
status,
has
now
been
changed
to
informational.
It
was
previously
standards
track.
That
was
a
comment
from
Alexandre
Petrescu
I
think
come
after
zero.
Zero
is
released,
so
apologies
for
the
late
update
on
there.
It
was
just
a
case
of
trying
to
make
sure
that
we
had
the
the
things
in
there
that
we
said
we
didn't
coorporate.
B
Can
you
go
to
the
first
slide?
Please,
okay,
so
a
90
f-104,
McCarroll
Abrahamson
did
a
presentation
in
v6
ops
about
operational
problems
that
we,
as
dr.
telecom,
have
seen
with
deploying
v6
and
one
of
the
things
that
we
mentioned
on.
There
was
the
trouble
that
we've
seen
with
a
prefix
delegation
with
when
you
have
a
separated
relay
function.
So
in
our
particular
case-
and
I
think
this
is
a
reasonably
common
case-
you
have
your
client-
you
have
a
DHCP
relay,
which
is
also
the
first
layer
3
hop
in
the
network.
B
B
Because
the
term
delegating
route
requesting
routes,
our
relay
these
are
all
kind
of
reserved
terms
and
well
understood
to
what
they
they
mean
and
what
they
define.
We've
actually
taken
a
new
term
in
there
to
decide
to
describe
this
device
which
we're
calling
a
delegating
relay
just
to
differentiate
it
from
other
things
out
there
next
slide.
Please.
A
B
A
B
A
B
Here
we
came
up
with
the
term
really
on.
The
basis
is
just
either
working
the
the
permutations
of
relevant
words
here,
and
you
know
to
find
one
that
didn't
already
exist,
although
I
think
it
seems
descriptive
of
what
the
task
is.
You
know
the
function
that's
being
performed.
If
there's
any
suggestions
for
a
better
name,
then
you
know
I'm
happy
to
hear
those.
No.
A
B
You
know:
that's
that's
one
of
the
things
where
we
in
the
setup
for
the
document
that
we
define
is
we're
not
interested
in
that
particular
function,
because,
as
far
as
I'm
aware,
well,
actually
I've
never
really
worked
with
those
devices,
but
I
don't
think
they
have
these
problems
because
you
know
the
a
lot
of
it
arises
from
state
synchronization
and
when
the
functions
are
co-located
in
a
single
device.
That
state
synchronization
is
much
less
of
a
problem.
B
B
F
B
What
the
relay
does
in
that
case
is
it's
also
unpredictable,
so
the
idea
with
this
draft
was
really
just
to
say.
These
are
the
operational
problems
that
we've
encountered
out.
There
enumerate
those
and
provide
a
set
of
requirements
that
should
enable
us
to
solve
those
problems.
You
know
one
of
the
one
of
the
things
that
we've
fallen,
foul
of
is
when
we've
discussed
these
problems
with
with
the
vendors,
the
respective
vendors
we've
got
nothing
to
point
to
say
this
is
how
this
is
how
this
should
be
done.
B
This
is
the
you
know
the
required
behavior
here,
so
that
that
was
really
the
problem
of
trying
to
fix
with
this
draft
next
slide,
please
so
yeah
I
mentioned
about
this
in
the
intro
84
15
and
36
33,
before
that,
both
name-checked,
the
the
architecture
that
I'm
talking
about
here,
but
it's
very,
very
thin
on
talking
about
how
this
is
going
to
be
done.
So
this
this
this
point
here,
that's
been
made
on
the
redistribution
of
protocols
include
the
routing
protocol,
all
or
whatever
else
yeah.
B
That's
absolutely
true,
but
we
actually
declared
this
part
of
the
functionality
to
be
out
of
scope,
because
you
know
there's
many
ways
that
this
can
be
tackled
and
it's
not
really.
What
we're
interested
in
here
is
much
more
the
interface
between
the
client
and
the
relay,
and
also
the
relays
forwarding
and
processing
of
messages
towards
the
server.
B
So
you
know
I
think
there
is
space
for
this
one
and
it's
kind
of
you
know
an
omission
from
184
15
covers
at
the
moment
next
slide,
please
so
the
way
that
we
structured
this
and
in
the
0-2
update,
we
now
have
an
informational
draft,
but
we
took
the
RFC
1784
type
approach.
The
requirements
that
we've
had
in
here
do
use
21
120
119
language,
but
we
have
a
description
in
the
early
on
the
document.
That
kind
of
explains
why
this
is
done.
It's
lifted
straight
from
1784,
and
you
know
my
thinking
was.
B
If
it
was
so,
if
it
worked,
then
then,
hopefully
it
will
work.
Now
we've
divided
the
requirements
into
four
different
categories:
I,
don't
with
in
this
presentation,
actually
go
through
what
each
of
those
requirements
are,
because
please
read
a
draft
for
this,
but
we're
talking
about
things
like
message,
forwarding
and
and
trying
to
make
that
as
stupid
as
we
possibly
can
do
ie.
If
a
relay
gets
a
messy,
a
valid
message,
then
it
should
forward
it
shouldn't.
B
You
know,
try
and
second-guess
that
should
be
done
handling
of
multiple
prefixes,
permitting
these
things
to
happen,
and
also
some
information
about
recent
time
and
maintenance
that
one's
interesting
and
we
kind
of
there's
a
little
bit
of
verb.
I
understand,
although
it
was
kind
of
before
my
involvement
with
the
idea.
I
understand
that
when
prefix
delegation
was
originally
defined,
there
were
some
concerns
raised
about
the
the
idea
that
effectively
what
we're
doing
here
is
snooping
that
we're
looking
into
the
timers
onto
there
and
and
to
some
extent.
You
know.
A
B
I,
don't
want
to
write
a
document
that
says
you
must
snoop
the
traffic,
however,
for
lease
and
time
and
maintenance
I,
don't
think,
there's
anything
else
that
you
can
do,
but
we
use
deliberately
loose
language
around
this
to
say
that
there,
the
relay
must
synchronize
its
timers
must
have
a
way
of
synchronizing.
The
time
is
based
on
the
reply.
Messages
that
are
sent
the
time
is
innocent
reply,
messages
that
are
sent
by
the
server
the
routing
as
I
said,
the
scope
for
this.
B
B
Think
we've
got
something
in
there
as
well
about
about
holding
the
route,
even
if
the
link
goes
down.
So
if
you've
got
a
link
towards
the
client,
you
get
a
link
down
events
then,
essentially,
although
the
route
cannot
be
active
because
the
link
is
down,
it
should
not
be
deleted
because
it's
still
alike,
you
know
once
that
link
gets
we
established.
If
the.
If
the
timers
haven't
expired,
then
it's
still
valid.
So
we've
got
a
requirement
to
know
about
that
service.
B
G
To
moaners
UNH
I
well,
I
have
two
comments.
One
is
I
really
like
this
draft.
We,
you
know
we're
the
hardest
thing
we
have
finding
is
finding
working
real
agents
as
great
as
that's
been
astounding
runner
up.
They
do
all
kinds
of
strange
things
like
you
know,
don't
know
it's
message,
types,
it's
sort
of
an
adventure,
so
I
think
this
will
probably
help
the
community
builder
it
use
for
real
agents.
My
only
other
question
was
the
draft
name
is
obviously
prefix
delegation
and
we
see
the
same
problems
with
ia
na
s
as
well.
G
B
G
Yeah
I
mean
the
ones
I'm
thinking
about.
Are
those
generic
message
ones
right?
It
doesn't
matter
what
options
inside
of
it.
You
know
if
it's
not
14
is
Pacific
of
message.
That's
pretty
bad.
There
was
a.
It
was
all
a
couple
of
them.
I
I,
don't
feel
super
strongly
about
it.
There's
something
to
think
about.
Okay,.
B
H
Eric
line
I
think
section
4.1
requirement
G
one.
A
delegating
router
must
forward
messages
bidirectionally
between
the
client
and
server,
without
changing
the
contents
of
the
message
and
I'm
wondering
how
does
that
comport
with
sixty
sixty
seven
eighty,
eight,
the
line
ID
option
because
I
think
that
gets
inserted
right,
it
doesn't
get
the
the
client
request,
doesn't
get
any
capped
and
sent
to
a
server.
The.
A
A
This
is
very
volts
and
I
think
that
a
lot
of
the
issues
also
existed
in
in
the
fourth
with
just
address
assignment.
You
know,
because
they
were
similar
sort
of
problems
and
stuff
and
I.
Think
there's
also
been
a
lot
of
work
by
the
sabe
working
group
in
sort
of
defining
how
some
of
these
intermediate
devices,
because
they
sabi
stuff,
is
you
know,
on
switches
and
other
forwarding
engines
to
assure
that
they
are
only
you
know
if
they're
monitoring
and
what
devices
are
out
there,
what
they're?
A
In
their
case,
it's
address
assignment
now
previous
application
that
they're
dealing
with.
But
you
know
if
the
device,
the
switch
or
router
is,
is
monitoring
addresses
advice.
Has
they
have
specified
that
fairly
well,
so
I
would
encourage
you,
maybe
to
look
at
that
and
see
what
they
have
to
say
about
some
of
these
issues,
I
mean
having
state
in
multiple
places.
A
B
I
mean
in
preparation
for
writing.
This
I
did
look
into
the
Savi
stuff
and
originally,
when
I
was
kind
of
thinking.
Well,
what?
What
would
the
contents
of
the
draft
be?
You
know
I
thought
well
that
you
know
the
specification
of
the
different
state
machines
in
the
in
the
way
that
Savi
does
was
what
was
going
to
be
necessary
here.
B
However,
I'm
looking
at
that
and
thinking
about
it,
I
I'm,
not
sure
it's
the
right
answer,
the
reason
being
that
you
know
operationally
I
think
we
have
something
that
we
can
treat,
as
has
been
something
like
a
black
box
here.
You
know
we
know
what
we're
putting
in.
We
know
what
we
want
to
get
out.
We
know
what
the
behavior
of
this
thing
should
be
savvy
kind
of
goes
much
further
than
this
and
says
this
is
how
you're
going
to
do
all
of
that
stuff
and
I'm,
not
sure
I
mean
certainly
from
an
operational
perspective.
B
A
B
Not
really
that
interested
in
I've
also
had
a
similar
discussion
about
saying:
have
you
implemented
savvy?
Are
you
willing
to
implement
savvy
and
the
answer?
There
is
pretty
much
a
no
in
a
you
know.
If
it's
not
already
in
existence,
then
it's
seen
as
something
which
is
a
pretty
high
overhead
for
implementation
and-
and
you
know
so
as
I
was
hoping
or
I'm
hoping
with
this
case,
that
we
can
take
this
black
box
approach
and
it's
going
to
be
enough.
A
A
I
think
I
actually
went
looking
at
the
you
know,
docks
of
specifications
quickly
to
see
did
they
ever
spell
out.
You
know
all
of
the
stuff
that
the
cmts
has
to
do
to
to
keep
up
its
state,
and
the
answer
is
I
couldn't
find
it
now.
Maybe
you
know,
maybe,
if
I
look
harder,
I'll
find
it,
but
I
did
not
find
it.
A
They
do
have
a
section
which
kind
of
says
you
know
here
some
general
guidelines,
and
so
you
know
I
probably
should
point
you
to
that
that
I
found
and
it
was
kind
of
interesting,
because
you
know
it
even
hinted
that
you
know
there's
a
lot
of
you
know
in
this
case.
It's
it's
home,
routers
and
stuff
like
that.
A
That
only
will
support
like
one
PD,
and
so
you
know
have
seen
multiple
beauties
and
there
is
a
problem
and
stuff,
and
they
said
you
know
this
is
hopefully
something
that
will
will
be
resolved
in
the
future,
that
these
devices
will
be
more
capable
of
dealing
with
multiple
PD.
So
it's
it's.
You
know,
I
think
that's!
B
Right
sorry,
further
from
the
relays
perspective,
you
mean
from
the
yeah
from
the
delegating
relays.
Perspective
right,
I'll
have
to
I,
mean
I.
Think
this
I
can't
remember.
If
we
say
this
explicitly
or
not,
I
mean
we
certainly
talk
about
things
like
restricting
the
number
of
prefixes.
That
appliance
can
support,
but
I
can't
and
I
think
we
say
that
it
has.
It
supports
multiples.
Actually,
I,
don't
actually
have
the
relative
thing
in
front
of
me,
but
I
can
certainly
check
it.
It's.
A
Just
I
think
it's
just
something:
we
have
to
go
and
check
to
make
sure
that
we
cover
that
case
and
stuff,
because
there's
also
I
mean
there's
another
discussion.
That's
happening
in
v6
ops
about
how
the
CTE
themselves
need
to
behave,
especially
in
terms
of
the
devices
that
are
in
the
home,
or
you
know
in
in
the
end
Network,
and
you
know
making
sure
that
the
router
advertisements
are
properly
handled,
and
things
like
that,
which
is
somewhat
related
to
this,
because
it's
it's.
You
know
how
the
in.
G
B
B
A
B
B
A
C
D
A
B
D
B
D
B
D
B
D
B
B
C
F
B
C
G
Hi
I'm
Tim,
oh
noes,
UNH
I'm,
going
to
talk
a
little
bit
today
about
advancing
on
the
dhcpv6
center
to
an
Internet
standard
or
full
standard.
G
The
DHCP
Charter
has
a
third
I'd
a
minute
that
is
about
issuing
an
update
to
the
DHCP
base
specification
after
so
much
time
to
advance
it
to
an
Internet
standard
and
that's
what
this
is
about.
So
a
couple
things
just
housekeeping
stuff.
This
is
all
from
RFC
60,
410
they're,
really
four
bullet
points
under
there
are
two
independent
interoperable
implementations
in
this
case
right.
That
spec
actually
has
three
different
types
of
right.
G
It's
got
a
server
relay
which
we
just
talked
about
on
a
client,
so
we'd
have
to
find
several
implementations
for
all
of
those,
no
errata
to
the
specification,
no
unused
features
in
the
specification
and
no
IPR
on
any
of
the
things
in
it.
So
currently
84
or
15,
there's
no
rodda's
on
it
yet
and
there's
no,
it
doesn't
update
anything.
It's
not
been
updated
by
anything
at
this
point,
so
it
doesn't
have
any
of
those
and
it
doesn't
have
any
IPR
on
it.
Yet.
G
So
all
those
are
check
boxes
for
all
of
those
features
which
leaves
us
with
a
couple
of
to-do
items,
demonstrate
interoperability
of
to
clients
and
servers
and
I
mess.
This
up
there
should
be
relays
on
there
to
come
comma
relays,
so
we
got
to
find
a
couple
of
different
implementations
which
I'll
talk
about
some
ideas.
We
have
in
a
next
slide
about
that,
and
then
we
need
to
confirm
all
the
features
in
84.
15
are
useful
and
nothing
should
be
removed.
G
We
went
through
some
of
this
when
we
went
from
when
we
merged
33
15
and
36
33.
We
removed
some
with
features
and
there's
a
couple
more.
We
should
probably
talk
about
as
a
group
before
we
move
it
over
so
the
first
to
solve
the
first
problem.
The
UNH
Iowa
would
like
to
host
a
virtual
plug
fests
for
DHCP
people
who
are
interested
in
doing
this.
I
say
virtual.
You
know
the
advantage
of
being
part
of
the
universities.
G
We
have
a
lot
of
students
who
want
to
learn
things,
so
we
were
thinking
about
taking
a
week
in
particular
we're
looking
at
the
week
of
spring
break.
Nothing
says
spring
break
like
dhcpv6.
A
lot
of
our
students
work
the
whole
week
that
week,
so
it
would
be
a
good
week
for
us
to
do
it.
So
we
say
virtual
because
a
lot
of
the
plugfest
we
do.
We
require
people
to
be
on
site.
We
don't
think
this
one
is
going
to
require
people
to
be
there
on
site.
G
Whatever
test
plane,
we
come
up
with
we're
gonna
use
as
the
basis
for
the
v6
ready
one
that'll
come
out
there
currently
is
a
v6
ready
one
for
the
older
specs.
We
have
to
update
it,
so
we
would
use
whatever
we
find
from
this
and
ship
it
off
to
the
ready
logo
committee
as
an
extra
anything.
We
find
that
doesn't
work.
Obviously
we
would
report
back
to
the
DHCP
Group
saying
hey.
We
found
these
features
work.
G
Fine,
these
things
didn't
work
so
well
stuff
like
that
in
particular,
we
would
really
focus
around
the
updates
between
the
old
stuff
and
the
new
stuff,
I
think,
there's
old,
stuff
and
3315
that
might
not
work
but
I,
don't
think
it'll
be
as
interesting
as
the
update
stuff
that
didn't
make
it
through
also
during
the
plugfest
we'll
see
if
there's
any
features
that
no
one
has
implemented
at
all.
We
report
back
any
of
that.
If
we
don't
see
any
support
in
any
of
the
implementations
for
certain
things,
we
report
those
back.
G
This
is
a
more
generic
question
about
that.
So
unused
features
you
know.
Is
there
anything
it's
in
the
spec
that
anyone's
aware
of
that?
You
know,
isn't
used
that
one.
You
know
I
put
IATA
here.
This
comes
up
all
the
time.
I
don't
know.
If
people
find
it
useful,
we
should
remove
it.
Should
we
just
leave
it
in
there.
I
think
now
would
be
the
time
to
discuss
it
again.
People
when
I
talk
about
it.
G
G
Think
they
did
at
one
point
my
last
survey
of
them
I
did
not
see
any,
but
I
will
say
I'm.
You
know,
maybe
there's
bits
you
can
twiddle
to
make
that
happen.
It
doesn't
do
it
by
default
for
sure
I,
don't
I,
don't
know.
If
there's
something
in
the
registry
or
some
configuration
you
can
turn
it
on
that
I
won't
come
to,
but
I
you
know
I.
We
haven't
seen
any
at
the
lab,
but
that
doesn't
mean
they
don't
exist.
I
just
I'm,
just
not
aware
of
any
deployments
that
are
heavily
using
those
yeah.
G
G
We
we'll
post
all
the
stuff
about
the
virtual
bloodfest.
You
know
the
main
thing
we
want
will
have
a
registration
page
for
people
to
be
able
to
register
to,
but
we
really
want
people's
code.
However,
we
can
get
it
whether
it's
on
a
VM
on
a
dock
or
whatever
it
is.
If
you
can
get
us
code
for
your
DHCP
implementation,
that's
doing
80
for
15.
We
have
lots
of
eager
students
who
would
love
to
work
with
that
stuff.
So
well,
I'll
keep
the
DHCP
list
updated
with
the
details
of
it.
G
Here
guy
asked
me
this
I
think
if
I
had
to
guess
I
would
guess
May
they
do
their
major
releases
in
November
in
May.
So
my
guess
is:
we
would
be
aiming
from
a
time
frame.
I
haven't
talked
to
the
other
labs
about
this,
but
I,
don't
think
it'll
be
a
problem
since
we
have
a
background,
it's
not
like
we're
making
something
new.
So
I
think
this
is
just
updating,
yeah,
so
I,
don't
think
this
will
be
a
major
problem.
A
A
D
So
description,
so
I
really
hope
we
don't
have
to
remove
this.
So
it's
like
a
easier
process
that
way.
So
there
is
a
status
change
process
that
we
have
in
place
like
I
kind
of
got
it
down,
pat,
because
I
got
rid
of
ipv5
and
v7,
and
so
on
so
I
know
like
how
to
do
this
process
like,
and
here
it
is
here
so
if
he
gets
on
next,
then
he
has
to
do
that
too.
D
But
I
think
that's
an
easier
process,
then
doing
the
document
through
the
whole
last
call
process
right
because
everything
opens
up.
So
you
cannot
just
say
my
idea
of
last
calling
dis
change
right.
Like
yeah,
the
whole
document
comes
out.
People
are
going
to
come
up
with
things,
so
I
I.
Think
really,
like
you
know,
if,
like
you
know,
some
implementation
implements,
this
I'll
just
keep
it
and
then
go
on
right,
even
if
it's
like
not
widely
used.
D
If
it's
at
least
implemented,
we
have
a
case
to
just
keep
it
on
and
move
on
right
and
I.
Don't
think
it's
like
significantly
different
from
I
na
to
like
have
like
too
much
extra
code
like
just
hanging
around
there,
for
that.
So
I
would
just
say,
like
you
know,
go
for
the
standard
status
change
process
if
possible
and
March
is
like
if
he
write,
because
it
could
be
there
in
my
term
or
the
next
ad
stuff
so
like
we
have
to
figure
out
like
you
know
how
the
reports
come
on.
A
So
that
brings
us
to
the
end
of
the
agenda.
I
think
you
know
just
as
a
quick
summary.
The
problem
statement
draft
we're
gonna
you're
going
to
change
the
title.
I
think
you
want
to
leave
the
name.
You
know
the
document
ID
itself
the
same.
You
know
the
draft
title
or
not
the
title,
the
draft
name
I
guess
isn't
waiting
to
say.
A
A
The
yang
model
we
need
reviewers
as
Ian
requested.
So
anybody
that
can
please
do
so
for
the
dhcpv6
prefix
delegation,
stuff
in
was
going
to
look
at
the
2119
language
stuff
and
maybe
there's
a
few
edits
that
he's
got
to
do
still
and
then
hopefully
we
can
do
a
working
group
call
for
adoption
and
for
the
advancing
84
15
we're
gonna.
A
You
know
look
out
for
the
plugfest
information,
the
virtual
club,
fests
and
hopefully
people
will
submit
the
their
implementation
so
that
we
can
get
sufficient
coverage
in
that
testing.
You
know
they.
They
I
mean
they.
They
really
should
be
84
or
15
implementations,
not
like
33:15
3633
implementations.
So
that's
one
of
the
key
things
that
I
think
we
have
to
make
sure
that
they
adhere
to
that
I.
You
know,
I,
don't
know
if
there's
any
I
mean
that
may
be.
We
want
to
think
about.
A
I
Expect
which
wants
to
cry
firewood
to
should
put
in
its
response?
France
sounds
to
copy
sir
client
address
when
firms
in
front
to
acknowledge
a
packet.
It
seems
a
good
idea
because
they
see
PV
for
specification.
It's
sign
out
about
this
and
it
seems
at
least
some
people
believe
it's.
It
was
a
good
idea.
A
Guess
if
you
want
to
pick
up
the
draft
and
can
try
to
continue
it,
that
would
be
something
to
do.
You
know
we'd
probably
have
to
know.
We'd
have
to
go
through
the
working
group.
Adoption
call
again
and
stuff
like
that,
because
it
is
kind
of
a
long-dead
document.
Now
so
you
know
you
might
you
might
want
if
you
want
to
pick
it
up
and
you
think
it's
useful
and
important
work.
You
take
a
look
at
me.
D
Personally,
don't
mind
like
just
having
the
draft
like
and
try
to,
because
I
got
working
of
last
call
you're
gonna
find
out,
but
it's
up
to
you
like
very
gonna,
find
out
if
their
support
for
it
or
not
right
and
if
it's
something
simple
like
might
be
like
just
filing
an
errata,
might
be
like
a
thing
saying
hey.
This
is
like
some
kind
of
clarification
on
the
original
doc
and
then
we
can
go
from
there
too,
but
either
way
like
I'm.
Okay,
like
I,
don't
want
to
like
put
too
much
process
here.
D
A
And
I
assume
you
also
have
no
issue
with
us
adopting
the
the
prefix
delegating
relay
work.
Okay,
all
right!
Thank
you!
Everybody
and
hopefully
everybody
signed
the
blue
sheets.
If
you
haven't,
please
do
I,
don't
know
where
they
are
right
now,
I
mean
one
is
up
here,
but
I
think
we
just
used
one.
Where
is
the
blue
sheet?
Does
somebody
have
it?
Okay,
there.