►
From YouTube: IETF104-DHC-20190327-0900
Description
DHC meeting session at IETF104
2019/03/27 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
A
A
B
A
Hope
you
will
like
it
because
if
not
I
am
the
backup
okay,
so
that's
that
looks
good
and
then
we
have
the
problem,
the
most
important
part
of
this
session
today,
which
will
be
a
discussion
about
future
of
the
working
group.
And
after
that
we
have
a
presentation
about
another
draft.
It's
been
era
and
that's
been
around
for
a
while
about
multi
requirement,
extensions
for
HPV
6.
A
Yeah,
so
we
decided
that
this
is
the
the
most
appropriate
order,
because
we
wouldn't
want
to
have
the
future
of
the
working
group
to
be
the
last,
because
you
know
we
kind
of
estimated.
This
will
take
15
minutes,
but
it
might
take
much
longer
so-
and
this
is
essential
topic
for
for
the
for
the
working
group.
So
we
don't
want
to
rush
it
in
any
way
and.
C
All
right,
so,
can
you
events
so
a
little
background
on
this
because
it
has
been
presented
before
and
we
did
try
to
do
a
working
group?
Glass.
Sorry,
adoption
call,
but
the
background
on
this
work
is
that
there
is
a
cooperation
defined
between
I
Triple,
E,
802
working
groups
and
the
IETF.
And
a
while
ago
the
I
Triple
E
split
up
the
local
MAC
address
space
into
four
quadrants,
and
there
was
a
working
group
within
the
ITF
established
to
work
on
defining
an
allocation
mechanism
for
those
four
quadrants.
C
You
know,
half
the
outer
space
is
managed
by
people
purchasing.
You
know,
typically,
manufacturers
purchasing
a
interface
identifier,
a
no
UI
organizational,
the
unique
identifier
I
think
it's
the
name
of
it.
So
you
know
typically
the
first
three
octets
of
the
MAC
address
and
the
rest
of
the
address
space.
The
second
half
was
sort
of
undefined.
It
was
you
know,
usable
by
anybody,
and
this
is
what
they
split
up
into
four
quadrants,
to
make
it
a
little
bit
more
manageable
as
to
how
the
usage
happened
and
they
wanted.
C
So
Ralph
contacted
me
and
topic
and
I
discussed
it
a
bit
and
we
decided
to
work
on
publishing
a
draft
which,
which
we
did
there's
a
people,
are
more
interested
details
about
what
I,
Triple
E
is
doing,
and
what
they're
looking
for
there's
this
presentation
that
Thaler
did
back
in
at
ITF
96.
That's
a
very
useful
slide
deck
to
look
at.
We
also
talked
I
presented
this
at
the
I
Triple
E
ran
meeting
in
late
May.
C
So
I
Triple
E
is
still
very
interested
in
us
pursuing
this.
They
are
working
on
some
other
allocation,
algorithms,
that
are
protocols
that
are
much
more
sort
of
at
the
link
layer,
but
they
see
that
the
use
case
that
we
were
kind
of
focusing
on,
which
is
more,
the
hypervisor
or
VM
manager
that
might
need
to
assign
lots
of
MAC
addresses
to
you
know
each
of
the
VMS
that
it
produces
was
a
good
model
for
DHCP.
C
It
could
be
used
by
individual
clients
as
well
to
get
MAC
addresses,
but
it
was
primarily
for
devices
like
hypervisors,
so
you
know
the
this
was
I
contacted
one
of
the
key
people.
I
was
working
with
to
around
the
I
Triple
E
work,
and
they
are
still
very
interested
in
us
doing
this
work,
and
so
that's
why
I
am
back
here
trying
to
hopefully
get
people
more
interested
in
it
continue.
C
So
you
know
the
primary
use
case
that
we're
focusing
on
is
the
hypervisor
where
it
needs
to
allocate
a
you
know,
may
have
lots
of
virtual
machines
that
it
produces
over
time
that
it
needs
to
allocate
MAC
addresses
to
you
know
some
may
have
a
very
short
life.
Others
may
have
very
long
life,
and
the
idea
generally
would
be
that
this.
This
hypervisor
will
get
a
block
of
addresses
at
once
filled
them
out
when
it
needed
more.
It
would
go
back
to
using
DHCP
to
get
another
block
of
addresses
again.
C
C
So
you
know
we
do
have
a
description
of
how
that
could
be
done.
You
know
why
dates
of
pv6
it
has
all
the
existing
infrastructure
that
we
need.
You
know
got
a
protocol.
We've
got
the
network
tools,
the
server
already
knows
how
to
manage
and
allocate
resources
the
protocol.
What
is
designed
to
be
easily
extensible
and
and
we're
also
in
the
DC
working
group,
so
next.
C
I
kind
of
covered
all
this,
so
let's
go
to
the
next
slide.
So
the
way
that
we're
we
propose
doing
this
was
to
find
new
new
dhcpv6
options.
One
is
called
the
identity,
Association
for
link
layer
addresses
option,
and
it's
very
similar
to
the
IAEA
and
I
APD
is
used
as
container
for
the
options
to
request
link
layer
addresses
the
ll.
A
CDR
option
is
the
link
layer
address
option
and
that
carries
the
address
and
it's
similar
to
the
ie
address
and
I
a
prefix
option.
C
C
And
we
have
the
t1
and
t2
times
fiddle
for
the
renewal
and
the
rebinding
lifetimes,
so
it's
and
it
carries
the
you
know-
can
carry
additional
options,
which
are
the
ll
addr
options
to
hold
the
individual
address
assignments.
Next
slide
has
kind
of
got
squished,
but
the
link
layer,
addr
option
has
in
it
the
link
layer,
type
the
link
layer
length.
C
You
know
which
in
most
cases
would
just
be
the
ether
values
the
link
layer
address
that
was
either
requested
or
signed,
depending
on
which
way
the
option
is
going
and
the
number
of
the
extra
addresses,
because
the
default
would
be
just
to
give
device
one
address,
but
the
idea
could
be
that
either
device
could
ask
for
a
large
block.
You
know
hundreds
thousands
of
addresses
or
the
server
can
assign
it
some
number
of
addresses
at
once,
and
these
would
be
continuous
addresses
you
know.
So
it's
a
block
of
addresses.
C
We
didn't
do
it
like
prefix
delegation,
where
you
have
to
always
do
stuff
in
powers
of
two,
because
we
we
didn't
think
that
you
know
that
would
be
a
the
best
way
to
do
the
allocation
and
said
you
know.
So
that
device
can
ask
for
a
hundred
or
a
thousand
or
whatever
it
wants,
and
there's
only
a
valid
lifetime
provided
there's
there's
no
preferred
lifetime
because
that's
really
up
to
the
hypervisor
or
who's
ever
using
this
to
figure
out.
You
know
how
do
they
want
to
treat
this?
Because
it's
it's
not
it's!
C
You
know
it's
a
link
layer
address.
It's
not
like
a
you
know,
a
ipv6
address
where
you
might
want
to
use
it
for
a
time
period
and
only
use
it
for,
and
you
know,
use
it
for
new
connections
in
the
preferred
lifetime
and
then
use
it
in
sort
of
only
use
it
in
existing
connections.
When
it's
becomes
deprecated,
you
wouldn't
want
to
do
that
for
link
layer
addresses
it
doesn't
really
make
any
sense.
So
we
remove
the
preferred
lifetime
from
that
message.
C
C
We
did
simplify
things
in
the
sense
that
it
really
doesn't
make
that
much
sense
to
use,
confirm
decline
or
information
requests
messages
related
to
this,
although
you
know
the
information
wasn't
really
come
into
play
here,
but
the
confirming
decline
are
not
really
used,
because
how
do
you
there's
no
way
to
test
for
you?
Is
a
mac
address
already
sort
of
in
use
at
the
MAC
address
layer?
So
he
didn't
think
that
was
necessary.
So.
C
C
If
an
end
client
wanted
to
do
this,
it
could
use
a
temporary
MAC
address
and
again
it's
kind
of
got
squished
off
the
screen
here,
but
you
know
it,
let's
say
clarify
client,
let's
not
use
you
based
on
temporary
Mac.
Yes,
that
was
just
you
know.
We
we
think
that,
because
it's
it's,
you
know
typically
generates
its
DUID
based
on
the
MAC
address.
It's
got
in
this
model.
You
wouldn't
be
able
to
do
that
because
you
don't
have
a
permanent
assignment
for
the
MAC
address
next.
C
C
C
C
E
C
C
I
and
that's
I
think
they
would
have
no
alternative
at
that.
You
know
at
sort
of
the
higher
level
they
are
working
and
I.
Don't
know
you
know.
He
didn't
point
me,
I
kind
of
said
you
know.
Is
there
a
document
that
talks
about
how
you
guys
are
planning
to
do
this
at
the
Mac
layer
or
something?
And
he
didn't
point
me
to
a
document
that
exists
for
that
yet
and
in
the
notes
I
found
about
the
I
Triple
E
meetings.
I
did
not
see
anybody.
You
know
comment
specifically
on
yeah
we're.
C
F
C
G
C
F
G
A
F
C
F
C
Think
yeah
I,
don't
again
I
didn't
find
anything
concrete,
so
I
don't
know
that
there
really
is
anything
else
that
they
have
at
the
present
time,
but
they
did
when
we
talked
to
them
back
in
May
of
last
year.
They
didn't
want
to
do
a
you
know,
a
Mac
layer.
You
know
cuz.
This
runs
over
ipv6
right
and
so
there's
a
lot
of
stuff.
You
need
to
get
going
and
you
need
a
MAC
address
to
talk
so
they're
there
they're
trying
to
work
on
something
that
would
work
at
the
Mac
layer.
H
I'm
Jim
a
sit
there
I
laid
this
document
and
tried
to
respond
to
the
other
phone
call.
I
didn't
see
any
degree
of
program
about
it,
but
the
usage
exchange
intended
usage
seemed
to
be
bit
hypothetical,
so
I
have
not
sure
how
to
respond,
and
that's
why
I
was
basically
silent
and
I
guess
many.
Other
people
probably
did
the
same
thing,
and
if
there
are
really
people
interested
in
it,
probably
they
should
speak
up.
H
E
Sometime,
just
so
just
for
clarity
is
the
use
case
for
a
device.
That's
already
using
a
MAC
address
is
on
the
network
to
request
more
for
VMs
or
tethering,
or
whatever
local
networking
use
case.
It
has
within
its
own
within
itself.
I
guess
it's
that
thing
or
is
it
to
actually
Ella
allow
MAC
addresses
to
be
requested
for
a
node,
that's
starting
up
in
some
way.
Well,.
C
I
mean
there
is,
you
know
there
is
a
way
we
did
document
how
a
individual
device
that
wants
a
MAC
address
that
was
more
longer-term
assigned,
you
know,
could
could
work,
but
we
don't
know
what
it's.
It
is
kind
of
a
contrived
case,
because
we
don't
you
know,
we
don't
really
have
a
good
answer
for
that.
Okay,
but
the
hypervisor
stuff
is
much
easier
because
it's
already
clear.
C
Yeah
and-
and
you
know,
like
the
IOT
use
case
of
having
the
you
know-
the
sensors
sort
of
get
a
long-term
address-
we
don't
know
whether
that
you
know
maybe
Carlos
has
a
little
bit
more
on
that.
So
maybe
we
should
wait
to
sort
of
figure
out
what
we
want
to
do
based
on
his
presentation
as
well.
Okay,
that
makes
sense
so
I
with
that
I
think,
let's
turn
it
over
to
Carlos.
I
I
So
this
is
basically
to
assign
local
addresses
based
on
a
kind
of
vendor
kind
of
thing.
Then
they
have
another
quadrant
that
is
called
a
standard
assign
identifier
space,
which
is
supposed
to
be
managed
by
protocols,
define
it
by
@hv
standard,
and
in
that
case
there
are
44
bits
available
for
assigning
addresses.
Then
there
is
another
quadrant
that
is
called
miserably,
assign
identifiers
in
which
they
don't
specify
how
the
addresses
are
assigned
for
that
particular
corner.
I
So
by
an
administrator
using
whatever
mechanism,
and
then
there
is
another
quadrant
that
is
reserved
for
future
use,
although
can
also
be
used
kind
of
similarly
to
the
previous
quadrant,
their
mistress
will
be
assigned
in
the
fire
quadrant.
So
those
are
the
the
four
different
regions
that
have
been
defined
by
HPV
you
to
see
or
the
local
address
in
space
here
is
basically
how
this
is,
how
they
divided
and
identify
the
different
quadrants.
So
you
can
see
at
the
top
of
the
slide
the
four
first
bits
of
mcalary's.
You
have
the
one
that
we
identify.
I
If
the
MAC
address
is
unicast
or
multicast,
then
you
have
the
bit
that
identifies
this
global
or
local
address
and
then
the
the
following
two
bits
are
used
to
identify
the
actual
quadrant
for
the
Immaculate,
a
space
based
on
the
combination.
You
have
the
four
different
quadrants
that
I
summarized
before,
so
the
motivation
kind
of
prana
statement
of
the
this
document
is
basically
complemented
the
work
that
is
being
done
in
I
Triple
E,
that
is,
defining
the
mechanisms
to
address
to
assign
addresses
in
the
in
the
Sai
quadrant.
I
This
is
what
is
been
done
in
2.1.
Seek
you,
then
the
resource
of
work
here
at
ATF,
as
Bernie
has
presented
and
in
this
document,
but
basically
we
do
is
complement
this
ideal
work,
part
by
refining
mechanisms,
the
low
to
specify
or
to
provide
convey,
preferences
on
what
kind
of
which
kind
of
quadrant
the
addresses
must
be
taken
off
to
assigned
addresses
to
the
client
or
to
Lily
why
this
is
required.
Well,
this
is
what
I
will
try
to
explain
summarized
with
some
use
cases
in
the
following
slides.
I
I
So
we
have
different
scenarios.
Actually,
let
me
see
I
press
twice,
the
back
so
different
scenarios,
depending
on
whether
we
have
we
are
playing
addresses
to
a
terminal
to
a
hypervisor
like
Bernie
defined
before
so,
let's
start
with
the
terminal
kind
of
a
scenario
we
have
Wi-Fi
terminals,
those
interfaces,
those
terminals
have
interfaces
that
come
with
some
kind
of
burn
in
my
calories,
typical
situation
nowadays,
and
in
some
cases
now
there
are
the
requirement
or
the
need
to
assign
local
addresses
to
those
devices
that
will
replace
that
kind
of
temporal
MAC
address.
I
We
have
identified
to
a
scenario,
but
there
may
be
more.
This
is
just
the
this
motivation
just
tried
to
identify
the
need
for
for
this
slab
quadrant
selection,
but
then
maybe
all
the
scenarios
that
required
that
one
is
what
we
call
the
Internet
of
Things
IOT
in
scenario
in
which,
basically,
you
have
devices
that
may
come
with
one
address
that
you
need
to
assign
a
local
address,
because
there
may
be
so
many
of
those
devices
that
you
actually
need
to
to
do
this
kind
of
thing.
I
In
this
scenario
again,
it's
an
example
device
I'm
not
typically
moving,
but
there
may
be
other
scenarios
in
which
they
are
and
based
on
that
we
discuss
in
the
trap
that
the
quantum
that
would
be
more
suitable
for
this
is
they
a
lie
or
the
other
side.
Based
on
this,
for
example,
maybe
there
is
a
need
for
the
IOT
devices
to
use
a
monk
address
based
on
a
kind
of
vendor
company
ID,
this
kind
of
fix
this
one
example.
I
So
that's
why
you
want
to
avoid
this
distraction,
and
in
this
case
the
eye
qualen
probably
is
the
best,
because
it's
the
one
that
allows
to
to
make
use
of
more
space
and
to
distribute
the
handle
of
the
MAC
addresses
and
to
basically
make
easier
to
randomize
the
address
that
you
are
using
for.
For
that,
then
we
have
also
the
hypervisor
or
datacenter
scenario
in
which
we
differentiate
two
different
situations.
I
Basically,
a
hypervisor
is
getting
or
the
question
addresses
to
be
used
for
a
virtual
machine,
but
this
route
or
machine
may
be
a
built
on
machine
that
is
not
expected
to
move
from
the
actual
host
server.
What
is
gonna
be
Stan,
but
there
may
be
situations
in
which
you
may
forecast
over
see
that
that
built
on
machine,
maybe
they
need
to
be
migrated
to
another
OH,
another
data
center
or
another
server.
I
I
Then
this
is
basically
a
summary
of
why
we
need
this
need
or
explain
your
conveying
the
preference
of
the
quadrant
then
how
the
quadrant
selection
will
be
done.
Well.
This
is
not
in
the
scope
of
this
draft,
but
in
the
draft
we
define
it
or
we
provide
some
examples
like
ok,
we
have
the
imaginary.
We
have
the
the
mechanisms
to
to
convey
or
to
include
the
preference
of
the
quadrant,
how
we
will
be
selecting
which
quadrant
what
the
sample
we
take.
I
The
IOT
a
scenario
the
client
or
the
network
of
combine
with
the
client
may
have
or
may
use
different
parameters
to
guess
what
is
a
test
quadrant
so
sample
the
type
of
ilt
deployment.
If
it's
a
small
one,
a
large
one,
if
the
device
is
gonna,
be
moving
or
not
if
the
device
is
manager
and
manage
if
the
device
is
on
battery
or
not
depending
on
this,
there
may
be
different
scenarios.
I
What
in
this
case,
the
need
of
privacy
or
location
tracking
mitigation
or
not
may
be
something
that
you
wanna
need
to
consider
in
order
to
select,
which
is
the
best
address
that
you
wanna
use
and
in
the
case
of
a
datacenter,
the
hypervisor
might
be
interact
with
a
cloud
management
system
like
whatever
you
are
using
OpenStack
or
whatever.
All
the
filter
infrastructure
manager
we
use
more
NFB
terminology
to
know
is
a
function
that
you
want,
as
found,
instantiate
is
suspected
to
be
my
rate
of
moving
or
not
and
based
on
that
select
the
best
preference.
I
So
this
kind
of
the
meet
the
motivation,
then
we
define
in
the
document
some
extensions
to
the
previous
mechanisms
defined
presented
by
Burnley.
We
have
heared
the
example
figure
for
a
client
selecting
a
conveying
the
preference
to
to
get
an
address
from
a
particular
quadrant
in
the
drive.
We
also
define
the
make
the
signaling
when
there
is
a
relay
doing
this
and
basically,
in
order
to
do
this,
we
define
a
new
ia,
a
little
option
for
conveying
the
preference.
I
So
basically,
the
option
allows
to
identify
several
one
of
several
quadrants
and
associated
preference
to
that,
so
the
server
can
get
that
and
based
on
that
assign
the
best
address,
trying
to
meet
the
preferences
conveyed
by
the
cry
nor
by
the
relay-
and
this
is
a
short
summary
of
of
this
document-
it's
an
a
compliment
station
for
the
previous
document
presented
by
Barney.
So
question
is:
is
the
working
group
interested
in
working
on
this
I
guess,
then
the
response
is
very
much
related
to
the
former
question.
C
J
E
C
E
F
C
K
C
K
C
K
So
this
time
last
year
was
the
last
time
we
didn't
update
on
this.
There's
been
a
couple
of
updates
since
then
not
huge
things,
but
there's
been
some
reviews
from
mainly
from
the
chairs
and
from
Francis
we've
opened.
The
issue
tracker
has
proposed
back
then,
and
you
know
it's
a
fair
bit.
That's
been
double
there,
there's
still
15
items
which
are
open.
Some
more
severe
than
others
can
I
make
a
request
at
this
stage.
K
If
you've
got
if
you've
opened
anything
on
the
issue
trackers,
there
have
been
updates
and
attempts
to
resolve
some
of
these
things.
So
could
you
review
those
again
and
just
sort
of
see
whether
the
changes
that
are
proposed?
You
know
meet
your
what
you've
raised.
Do
you
know
if
you've
got
any
other
comments
that
need
to
be
addressed
in
there
as
well?
That
would
be
welcome.
Please
next
slide.
K
Okay,
so
one
of
the
comments
that
came
in
from
I
think
it
was
the
ISC
work
on
on
implementing
this
was
that
we
were
lacking
any
configuration
for
storing
leases
and
managing
that
side
of
things.
Obviously,
this
stuff
is
not
some,
you
know
written
in
any
standards,
documents
anywhere,
but
it's
necessary
for
a
DHCP
server,
so
it
makes
sense
to
have
some
kind
of
generic
functions
or,
or
you
know,
ways
that
we
can
talk
to
common
implementations
in
order
to
get
that
part
of
things
working.
K
K
Right
so
I'll
come
on
to
the
main
problems
with
it
in
a
second,
but
really
where
we
are
at
the
moment
is
that
we've
got
had
a
real
lack
of
activity.
We've
got
about
five
authors
listed
on
there,
I
believe
I
am
the
only
person
who
still
even
got
any
interest
in
doing
this
I
think
most
people
have
moved
on
either
because
they're
their
courses
are
finished
or
you
know,
they've
changed
their
roles
or
whatever
else.
So
this
is
one
of
the
major
problems
with
getting
the
thing
done.
I
already
made
the
comment
about.
K
If
you've,
if
you've
wrote
some
comments
in
the
issue
tracker
on
github,
please
can
you
have
a
look
through
those,
so
I'll
reiterate
that
there's
also,
as
I
mentioned,
the
ISC
key
implementation,
some
real
world
stuff
there
and
we've
been
looking
at
it
from
here
and
within
DT,
and
you
know
it
looks
like
there's
something
very
promising
there.
I
said
this
tutorial
yesterday,
but
it
would
be,
would
be
really
good
if
we
can
try
and
sort
of
fold
in
the
work
that
they've
got
there
take
the
learnings
from
it.
K
Right
so
yeah
that,
as
I
mentioned,
I
mean,
would
the
lack
of
authors
and
and
work
that's
gone,
and
recently
it
feels
like
we're
kind
of
starting
to
languish
a
bit
from
the
milestones
we
were
meant
to
be
ready
for
to
go
with
this
by
the
middle
of
last
year.
I
think
we're
still
a
little
way
away
from
doing
that,
and
one
of
the
things
that
I
noticed
on
this
when
I
was
looking
at
this
earlier
this
year
is
we've
got
a
scope,
that's
just
probably
an
unachievable
as
it
stands
at
the
moment.
K
K
Okay,
so
my
shattering
proposal
to
the
lack
of
authors
is
to
add
new
authors
and
yeah
I
spoke
to
topic
yesterday
and
it
it
seems
that
there
may
be
a
guy
from
Iasi
who's
willing
to
join
us,
which
would
be
obviously
more
than
welcome.
If
there's
anyone
else
in
the
world
who's
got
any
interest
in
this,
then
please
don't
hesitate
to
get
in
touch
and
you
know
get
involved
because
I
think
you
know
if
we
probably
just
need
one
or
two
extra
people.
K
C
K
Okay,
obviously
reduce
the
scope,
so
yeah
we've
got
to
boil
the
ocean
problem,
but
we've
also
got
the
fact
that
as
the
protocol-
okay-
it's
not
it's
not
growing
as
far
as
that
has
been
historically
but
his
filtrate
continued
to
extend
its
you
know
it's
getting
further
and
further
away
from
us,
so
the
proposal
here
is
really.
Can
we
discuss
this
to
a
point
where
we
can
get
something
which
is
useful
to
be
implemented
as
aspect
extensible?
K
You
know
tightening
up
what's
in
there,
adding
this
appendix,
and
yet
we
should
at
that
stage,
be
ready
to
publish.
So
you
know
a
combination
of
this
and
hopefully
the
addition
of
a
another
author
or
two,
then
I
think
we
can
get.
You
know
get
to
a
point
where
we've
got
something
ready
to
publish
fairly
shortly.
K
C
Bernie
volts
working
chair,
hat
offs,
I
kind
of
think
that
you
know
it
might
be
interesting
to
look
at
the
way
the
DNS
ops
group
is
going
about
it
where
they're
sort
of
starting
to
define
stuff
war
long.
You
know
the
what's
in
the
Ayana
registry,
so
they're
starting
to
find
the
you
know
the
resource
records
and
things
like
that,
and
maybe
that's
something
that
you
know.
We
should
think
about.
Here's,
maybe
starting
a
little
bit.
C
You
know
more
about
having
a
standard
way
to
represent
the
options
and
and
other
data
that
is
dhcp
stuff
because
part
of
the
problem
that
it
you
know,
because
we
did
this
same
sort
of
work
many
years
ago
to
try
to
do
an
LDAP
model
and
the
big
problem
is,
is
that
you
know
the
especially
for
the
server
parts
you
know
and
and
potentially
even
clients.
But
you
know,
I
know
the
server
better
kind
of
and
and
the
issue
there
was
that
servers
are
designed
to.
C
You
know,
take
configuration
models
in
in
a
different
manner
than
like
the
ISE.
You
know,
and
Kia
probably
differs
from
the
original
ISC
server
and
stuff.
So
if,
if
you
tried
to
to
produce
one
model,
then
you
kind
of
have
to
to
follow
one
server
architecture
or
configuration
model
which
doesn't
necessary
with
other
servers.
So
one
thought:
maybe
you
know
if
we
sort
of
build
the
common
building
blocks,
that
people
can
put
together
to
produce
specific
models
for
their
serve
our
clients
relays.
That
might
be
more
useful
than
trying
to
say.
C
Oh
here
is
you
know
the
standard
model
to
use
for
everybody.
I
mean
it's
just
an
idea
that
that
we
could,
you
know,
sort
of
start
with
the
fundamental
building
blocks
that
people
could
then
use
in
their
yang
models.
It's
not
as
good
as
if
we
had
a
standardized
getting
model.
But
again,
the
problem
is
that
you
know
the
configuration
models
for
these.
These
things
are
just
different.
I
mean.
K
I
understand
your
pointed
I.
A
while
ago,
we
split
out
the
option,
definitions
into
being
a
standalone
module
that
gets
referenced
by
client
server
relay
wherever
necessary,
I
mean
as
part
of
doing
that
work.
One
of
the
things
became
apparent
is
you
can't
just
goes
right
through
the
Ayana
list
and
make
yang
modules
for
every
single
one
that
what
you
can
do,
but
it's
but
it
you
know
when
it
comes
to
some
of
these
things,
there's
just
kind
of
no
points.
You
know.
K
K
K
K
Concepts,
though,
are
fairly
uniform,
and
you
know
one
of
the
things
I
had
hoped
that
we
would
be
able
to
do
through
the
authoring
process
is
get
the
input
of
more
than
just
one
implementation
to
be
able
to
say.
Well,
if
there
are,
you
know,
where
are
those
differences?
Where
does
this
module
no
longer
function
for
those,
and
is
this
stuff
that
you
know
they're
just
so
different?
K
We
can't
possibly
find
a
commonality
here,
and
it's
not
there's
no
point
in
trying,
or
is
it
possible
to
come
up
with
something
that
works
for
both,
and
you
know
that
would
be
really
useful
input
to
have
us
based
on
another
real
or
one
or
more
real
implementations
in
order
to
kind
of
you
know
find
out.
If
that's
something
that
we
can
do,
yeah.
C
Well,
and
just
to
respond
quickly,
Ju,
you
know,
I,
don't
think
that
we
have
to
model.
You
know,
maybe
I
misspoke,
to
say
all
options.
It's
just
you
know
those
that
are
configured
right
in
in
entities
that
you
need
to
worry
about.
You
know
the
ia
na.
You
know
those
kind
of
things
that
go
over
the
wire
and
are
just
designed
for
the
wire
stuff.
I,
don't
think
we
have
to
I
mean.
K
C
A
little
more
complicated
because
you
know
there
are
things
like
you
know,
even
even
things
like
the
prefix
include
stuff
right.
You
have
to
have
a
model
to
configure
that
for
it
to
be
set.
So,
yes,
you
know
so
I
think
it's
a
it
isn't.
It
is
an
interesting
problem
and
it's
not
as
simple
as
just
sort
of
taking
the
stuff
and
mapping.
C
You
know,
mapping
the
the
text
or
the
die
grams
into
the
yang
equivalent,
because
you
know
you
have
to
really
think
about
what
you're
doing,
because
you
know
you
have
to
convey
the
right
information
so
that
it
can
be
used
properly
so
but
I
mean
yeah
I,
don't
know,
I
mean
that
that's.
This
has
always
been
the
problem
with
these
models.
Right
is
that
there's
different
different
ways
of
slicing
and
dicing
how
they're
they're
sort
of
put
together
and
stuff,
maybe
I,
don't
know
whether
other
people
talk
and
see.
That's.
E
In
so
I
was
just
going
to
maybe
draw
parallels
to
the
way
the
young
models
or
modules
have
been
defined
for
route
reverse
Minh.
So
there
is
a
base
model,
stroke
module
and
there
are
certain
options
that
aren't
included
in
that
the
last
I
looked
a
year
or
two
ago.
There
was
no
way
the
DNS
resolver
option,
wasn't
something
you
could
do
so
I
guess
the
question
I'm
all
for
reducing
the
scope.
I
think
that's
a
pragmatic
way
of
cutting
something
out.
I
guess
the
question
is:
is
it
then
going
to
be
useful?
E
A
Don't
worry,
we're
honesty,
I
see
so
two
comments.
If
you
mentioned
that
there's
a
difference
between
the
Tia
Yankee
kilometer
and
they
wanted
is
described
in
the
draft
currently
I
would
say:
there's
flexibility
on
two
sites,
the
implementation
that
we
did
in
Kia.
This
was
done
on
their
tight
schedule
restrictions.
So
we
did
what
was
the
easiest
for
us,
but
our
model
is
not
fixed
in
song.
A
C
L
Risk
medicine
I,
just
kinda
like
to
reiterate
the
I,
guess
the
idea
to
to
focus
the
scope
of
this
work
into
the
the
common
areas.
Where
is
required
to
get
this
running,
I
think
extending
it
out
and
I
think
Bernie's
point
around
trying
to
capture
all
possible
permutations
and
even
vendor
implementations
is
going
to
be
quite
troublesome
and
from
a
even
from
a
network
elements
modeling
point
of
view.
I
think
I've
personally
resigned
myself
to
that
we're
always
going
to
have
vendor-specific
yang
models.
C
K
But
you
know,
though,
those
are
things
that
they
get
applied
on
top
of
the
standardized
skeleton,
and
you
know
it
that
I
from
what
I'm
seeing
you
know,
what
I
would
like
to
do
is
get
this.
Get
this
skeleton,
and
you
know
that's
that's
what
I'm
I
believe
I
I
think
we
can
do
I
mean
Bernie.
He
did
from
your
perspective.
Do
you
see
anything
in
the
model
as
it
stands
at
the
moment?
That
would
mean
that
that's
not
possible.
F
C
Through
it,
so
I'll
have
to
do
that
again,
but
it
you
know
and
I
think
that
you
know
it's
a
question.
I
mean
I,
guess
the
question
is
is,
and
we
need
some
feedback
right
is.
Are
people
interested
in
working
on
on
this
problem?
Whatever
this,
you
know
this,
this
yang
model,
whatever
it
might
be,
and
are
they
willing
to
you,
know,
step
forward
and
and
help
right
on
it
because
you're
looking
for
more
authors,
could.
K
Would
you
be
able
to
provide
a
review
on
that
basis
just
on
what
we've
got
at
the
moment?
Maybe
not
necessarily
what
we've
the
stage
we
are
at
the
moment,
but
I
mean
if
we
were
to
do,
have
the
discussion
about
what
we
should
include
in
the
scope
and
then
produce
an
update
at
that
stage,
and
would
you
be
willing
to
review
it?
K
I
mean
so
as
a
proposal
on
what
to
do
next.
If
we
can
see
you
know
what
responses
we
get
to
anyone
who
had
wished
to
draw
in
the
author's
list,
once
we
have
that
I
would
suggest
we
produce
a
proposal
about
what
we'll
do
with
the
scoping
and
put
that
on
the
mailing
list
and
and
then
hopefully
have
some
discussion
around
that
and
based
on
the
outcome
of
that,
will
produce
an
update
and
take
it
from
there.
Yeah.
C
K
C
A
C
A
Yeah,
so
I
just
want
you
to
recap:
what's
the
situation
with
the
working
group
right
now
and
then
we'll
move
on
to
describe
what
the
next
steps
could
be.
So
this
is
the
DFC
charter,
so
in
principle,
have
three
goals.
First,
one
is
work
on
informational
documents
providing
operational
and
limitation
advice
about
the
HDTV
six.
So
this
is
something
that's
ongoing,
so
we
have
the
Yak
models.
We
have
the
link
layer
assignment,
there's
also
potential
work
of
the
with
the
Emory.
A
Another
freaking
out.
Chatter
is
that
we
are
supposed
to
assist
other
working
groups
in
defining
DHCP
options.
So,
in
my
opinion,
this
this
is
to
some
degree
in
dysfunctional
that
I
don't
remember.
When
was
the
last
time
we
were
requested
to
to
review
a
draft
there's
some
activity
going
on,
but
it's
very
frequent
and
the
tip
thing
that
the
tasigna
Inchon
in
our
Charter
is
to
issue
an
updated
version
of
HP
v6
spec.
We
did
this
so
that
there's
a
follow
up
that
after
an
appropriate
time,
we
should
work
on
promoting
it
to
full
standard.
A
So
so
this
is
in
progress
next.
So
these
are
the
requirements
to
promote
a
draft
standard
to
full
to
full
standard,
and
we
are
working
on
this.
There
are
couple
technicalities
that
we
need
to
deal
with
the
first
one
is:
there
have
to
be
at
least
two
independent,
interoperable
interoperating
implementations.
A
A
Currently,
they
are
known,
don't
know
unused
features.
We
are
also
working
on
this
and
the
last
one
is
related
to
IPR
and
patents.
There
are
no
patents
report
at
this
time,
so
in
principle
this
looks
reasonably
good.
The
plan
is
that
we'll
wait
around
a
year
after
the
84
15
I
was
published,
so
it
was
published
in
November
2018,
so
around
November
2019
we'll
kick
up
the
procedure
to
promote
this
to
full
standard.
So.
H
My
understanding
battery,
no
one,
if
you
think
and
maybe
not
greatly
increasing
the
complexity
but
I,
think
it
complete,
introduces
some
confusion
about
the
interaction
with
other
cases.
So
if
we
want
to
promote
it
to
internet
standard,
then
probably
we
might
seriously
think
about
duplicating
it
or
making
it
more
clear.
C
C
J
I
think
we
said
that
you
know
they're
not
commonly
used,
but
we
didn't
use
the
word
deprecated
or
historical,
so
it's
still
there
as
something
making
you
I,
don't
think
we
recommended
using
it.
But
my
memory
of
this
is
that
we
left
it
so
gave
words
like
this
isn't
common,
but
it's
still
here
so
doesn't
mean.
J
It
boy
when
we,
when
we've
done
this
for
other
standards
like
when
do
interrupt
testing
there
are
features,
sometimes
don't
get.
Not
everyone
supports
them
right
that
there's
parts
of
the
standards
that
just
not
everyone
decides
to
do.
It's
still
there.
In
some
cases
you
know
I
we've.
In
the
past
we
get
one
or
two
implementations
that
might
implement
the
thing,
and
we
say
we
saw
those
guys
work
together
in
this
case.
There's
a
lot
of
other
IAS
I,
don't
I,
don't
think
this
should
be.
The
thing
that
holds
us
up
would
be.
J
A
A
So
I
just
wanted
to
recap:
what's
been
going
on
with
DHC,
so
this
is
the
oldest
working
group
still
operational,
so
it
was
created
in
the
80s
so
yeah,
so
the
recorded
history
is
close
to
18,000
miles,
but
we
lost
the
history
before
2001
so
like
that
there
was
more
now
compared
this
to
ever
seen,
24:18
that
the
working
groups
are
generally
expected
to
be
short-lived.
So
it's
a
short
lift
if
you
are
a
journalist,
okay.
Otherwise
this
is
like
a
couple.
A
A
So
I
think
we
have
couple
options.
The
first
one
is
once
we
deal
with
the
current
work
we
could
recharge.
But
the
question
is
what
the
what
the
Charter
would
be.
We
could
think
about
something
like
we
have
for
DNA.
We
have
DNS
up,
so
we
could
consider
doing
something
similar
like
creating
a
working
group
about
DHCP
operations.
I,
don't
know,
maybe
it
would
be
more
appropriate
to
do
it
in
in
ops
area
or
maybe
not
do
it
in
ITF
at
all.
A
Maybe
do
it
in
some
other
bodies
like
in
ripe
or
nano,
so
this
is
one
possibility.
The
other
one
is
to
put
the
working
group
in
and
dormant
mode,
so
we
wouldn't
really
meet.
The
the
main
list
would
still
be
active.
I
think
some
people
might
get
confused
with
this,
but
this
is
something
that
we
can
handle
and
the
last
choice
is
to
shut
down
the
working
groups
so
like,
for
example,
happen
to
it.
A
A
Yeah,
so
just
to
reiterate:
we're
not
talking
about
doing
this
now,
but
within
a
year
so
after
after
we
finish
the
current
work
and
also
promote
to
for
standard,
this
also
has
a
different
nice
side
effect
that
will
have
a
deadline
that
people
are
working
on
current
stuff.
They
know
that
they
have
a
year
to
wrap
it
up.
So
so
any
thoughts,
comments,
suggestions,
any
preferences.
E
Right
so
I
think
I
think
what
we
don't
have
here
is
a
list
of
what
is
it
that
we
think
we
might
need
to
do?
What
are
the
requirements
of
a
group
if
it
continued
once
84
1
5
is,
is
I
think
that's
a
very
positive
statement
that
it's
out
there
it's
widely
deployed
in
in
use
and
that's
great,
but
do
you
want
to
do
any
more
protocol
work?
E
C
Will
add
that
you
know
for
right
now
the
and
I
figured
like
exactly
what
the
text
is,
but
you
know
we
do
have
a
expert
review
process
for
both
before
and
b6
options
and
so
actually
working
well,
there's
no.
Today,
there's
no
need
to
go
to
the
working
group
to
get
options.
So
it's
possible
that
you
know
some.
Some
other
working
group
defines
a
draft
that
has
options
in
it.
C
E
C
E
I
think
if
you're
saying,
if
there
are
there
isn't
if
there
is
a
review
function
that
exists
already,
we
don't
need
to
sort
of
vote
things
in
here,
they've
done
elsewhere
and
we
can
take
things
to
int
area.
Then
you
know
I.
Think
studying
is
someone
else,
had
a
deadline
of
a
year
to
sort
things
out
and
then
propose
dormancy
I,
don't
think
you
would
go
straight
from
straight
to
shutdown
but
after
a
dormant
state
and
see
what
happens
right.
C
M
Stephen
Morris
I
see
a
tooth
two
things.
One
is
follow
the
model
of
the
TCP
maintenance
and
minor
extensions
group
which
focuses
on
correcting
bugs
in
the
proto
protocol
and
then
very
modest
extensions
and
the
other
thing
about
shutting
down.
The
group
is
cast
your
minds
back
a
few
years.
When
we
had
to
DNS
groups,
we
had
DNS
extensions
of
DNS
operations
and
DNS
you
extensions.
The
working
group
chose
decided,
that's
it
we're
not
going
to,
they
were
not
gonna,
enhance
DNS
any
more
and
they
shut
it
down.
C
M
C
K
So
there's
a
bit
noisy.
Can
you
hear
me?
Yes,
I
think,
there's
a
there's,
an
interim
state
between
the
two
isn't
there
I
mean
what
we
did
in
in
software
and
actually
we've
been
hanging
on
like
this.
For
some
time
now
is
just
it's
not
accepting
new
work
and
finishing
the
existing
things
that
we
have
and
I
mean
I
think
you
know
the
idea
of
saying
well
taking
18
for
15
STD
track
and
saying
well,
that'll
set
the
timeframe
for
it.
K
You
know
from
what
I
see
in
some
work
groups
you
get
times
where
there's
a
lot
of
stuff
times
where
there's
less
stuff.
Obviously
GHC
is
in
a
lull
at
the
moment,
and
you
know
it
may
well
be
that
this
song
shows
that
it's
Peter
out
or
it
may
just
be
a
little
that
we
don't
know
anything
about
so
saying,
specifically,
anything
more
than
a
statement
of
this
is
how
we're
going
to
proceed,
or
this
is
how
we
expect
us
is.
C
K
C
K
Well,
I
mean
they;
they
you've
always
got
this
problem,
then
of
what
happens
to
any
new
stuff
that
comes
in
because
you
know
saying
that
protocol
is
complete,
finished
and
and
we'll
you
know,
that's
almost
certainly
I'm
not
going
to
happen.
Is
it
there
will
be
new
things
that
will
be
needed.
We
don't
know
what
necessarily
what
those
are
at
the
moment.
So
we
need
a
practical
way
of
being
able
to
handle
those.
K
N
It's
Shane,
Kerr
I,
just
want
to
caution
against
using
a
comparison
with
the
DNS
space
here,
because
in
DNS
there
was
a
long
period
where
new
development
was
basically
suppressed
in
the
ITF
in
order
to
focus
on
DNS
security,
and
once
that
completed
there
was
a
lot
of
interest
in
new
developments
and
new
technologies.
Plus
the
technologies
continue
to
evolve,
not
super
rapidly,
but
but
they
do
continue
to
evolve.
So
I,
don't
know
that
it
that
we
need
to
be
too
worried
that
the
same
thing
is
gonna
happen
in
the
DHCP
space.
C
End
up
changing
based
on
what
happens
between
now
and
then
anyway.
So
it's
just
sort
of
you
know.
We
just
wanted
to
sort
of
open
the
discussion
to
see
what
people
were
thinking
at
this
point
in
time
that
that
we
should
do-
and
you
know
again,
the
main
goal
over
the
next
year
will
be
that
or
even
less
is
to
advance
84
15,
so
anything
that
people
can
do
to
you
know
help
with
that,
which
is
basically
to
confirm
that
you
know
existing
implementations
adhere
to
the
requirements
of
that
document.
O
Hello,
hello,
everyone,
my
name
is
Alena
franching
Ohio
University
today
I'm
going
to
introduce
our
draft
of
the
statement
of
multi
requirement,
extensions
or
dhcpv6
and
I
will
first
introduce
background
and
the
current
extension
practices
and
then
explain
where
we
can
extend
the
HTTP
v6.
And
finally,
we
will
present
give
an
extension
case.
O
O
Tht
be
some
DHCP
servers
in
a
software
provides
interfaces
to
allow
for
user-defined
extensions.
Some
people
may
suggest
that
we
can
modify
open
source
HTTP
servers
to
do
the
job.
However,
it
is
very
difficult
and
we
needed
to
maintain
that
the
code
and
so
when
Neil
and
general
inside
of
how
to
solve
the
extension
problem
better.
O
Currently,
we
have
three
extension
cases.
The
first
one
is
to
extend
options.
This
is
the
most
common
practice
and
the
second
one
is
to
extend
messages,
for
example,
actually
actively
squarey
provides
current
messages
to
allow
administrators
to
extend
the
HTTP
server
and
the
third
one
is
to
to
extend
entity.
For
example,
radius
is
introduced
into
the
estate
to
conduct
authentications.
O
O
Here
we
summarized
a
dhcp
general
model,
which
includes
for
several
paths
the
HTTP
interior,
that
is
the
kinds
relays
and
servers
tht,
take
messages
with
options
and
the
messaging
processing
functions
and
adjust
generation
mechanisms.
Next,
so
we
will
introduce
where
we
can
extend
at
the
edges.
Ipv6
die
that
is
get
sticky
messages,
options
and
message,
processing,
functions
and
adjust
generation
mechanisms.
We
will
introduce
each
point
from
the
stators
problem
and
the
possible
solutions,
let's
say
at
least
eight
messages.
O
Currently
we
can
define
new
messages
and
but
the
effect
messages
are
in
plain
text
that
is,
there
is
a
lack
of
privacy
protection.
Our
messages,
RFC
78
24,
provides
privacy
protection
of
privacy
considerations
for
th
the
key
basics.
While
we
think
one
of
the
most
possible
solutions
that
we
increase
all
the
dhcp
messages.
O
Second
ones
are
the
options.
Currently
we
can
define
your
options
to
convene
or
to
carry
new
parameters.
For
example,
vendors,
specific
information
allow
us
to
define
new
sub
options
to
serve
the
six
of
our
private
purposes,
but
some
parameters
make
him
from
users,
that
is
to
say
this
parameters
uncertain
and
may
change.
We
think.
Well,
there
are
two
kinds
of
possible
solutions.
The
first
one
is
that
clients
are
provided
interfaces
to
obtain
user
parameters.
O
However,
there's
there
are
few
such
interfaces.
The
second
one
is
that
relays
obtain
the
little
parameters
and
first
and
then
Azzam
in
to
DHCP
requests.
However,
this
needs
the
support
of
other
particles.
A
third
line
is
that
is
the
message
processing
functions,
currently
some
servers
providing
the
basis
to
allow
for
user-defined
extensions
and
this
customer
customers
how
servers
handle
and
respond
to
the
DHCP
requests.
However,
not
all
the
SCP
software
containers,
this
extension,
we
think
the
HTTP
server
may
saw
support,
support
the
user-defined.
The
extensions
and.
O
O
O
Here
we
present,
we
give
an
extension
case
which
is
published
in
a
Tripoli
infocomm,
1919
2019,
and
considering
such
a
requirement
that
ipv6
addresses
are
generated
from
user
identifiers
to
for
accountability
and
privacy,
and
we
have
to
do
two
things
to
achieve
such
a
goal.
The
first
one
is
that
clients,
since
their
user
identifiers
to
our
two
servers,
a
second
wise
servers,
generator
addresses
and
assigns
them
to
clients.
O
However,
this
needs
the
help
of
other
protocols,
we're
wondering
if
the
DHCP
is
more
extensible,
so
we
can
do
it
better
with
thanks
for
the
changes
compared
with
Alvaro.
That
way,
thanks
for
Bernie's
valuable
comments
and
we'll
address
well
just
in
a
in
the
Owen
next
place,
where
I'm
not
sure
DHCP
is
injured.
Th-These
working
group
is
interested
in
this
work,
so
any
comments.
Thank
you.
C
And
again,
currently,
this
is
an
individual
submission
and
I
think
it's
on
the
informational
track,
right,
yeah,
yeah,
and
it
basically
just
outlines.
You
know
these
these
different
options
that
people
have-
and
you
know
the
the
hook,
points
and
extension
points
that
some
of
the
servers
provide
that
let
people
perform
or
let
system
administrators
perform
more
complicated
tasks
or
customize
certain
aspects
of
the
processing
for
their
usage.
C
E
P
I'm
Karen
from
Chiba
University,
currently
many
research,
what's
happenin
pong
to
improve
the
genetic
on
bility
and
pricing,
most
of
this
works
are
related
with
IP
address
configuration
and
the
generation
I
think
as
one
of
the
main
protocol
related
with
IP
address
configuration
I
think
made,
it
may
be
useful
to
make
some
extension
to
support
multiple
repairman's
more
easily.
Thank
you.
A
So
tours
here,
so
from
my
perspective,
in
principle,
all
the
information
is
already
there,
but
the
the
biggest
value
of
this
draft
would
be
to
have
it
in
one
single
place,
and
it
would
be
good
a
reference
point
for
people
that
what
to
do
something
uncommon
to
point
them
hi.
This
is
your
static
point,
so
yeah
I'm
in
favor
of
this
draft
of
adopting
it.
If
we
go
the
truth.