►
From YouTube: IETF100-DHC-20171116-1810
Description
DHC meeting session at IETF100
2017/11/16 1810
https://datatracker.ietf.org/meeting/100/proceedings/
A
All
right
good
evening,
this
is
the
DC
working
group.
If
you're
in
the
wrong
room,
you're
welcome
to
stay
if
you're
in
the
right
room,
please
do
stay
as
with
all
ITF
meetings
and
working
group
sessions.
Please
note
the
note:
well,
the
blue
sheets
are
going
around.
Please
make
sure
you
fill
that
out.
If
there's
anybody
willing
to
be
a
jabber
scribe,
we'd
love
to
have
you,
do
it
as
well
as
etherpad.
A
A
And
we
have
kind
of
a
short
agenda
this
evening,
we're
doing
the
administer
of
you,
which
should
take
just
a
few
more
minutes.
Then
we
want
to
talk
about
the
future
of
the
working
group
and
reach
our
Turing
and
then
we'll
have
chakra
anon
the
yang
model
and
then
two
other
sessions
presentations
by
srivasa
srivasa
that
are
on
one
is
already
a
working
group
document.
The
other
is
a
a
individual
submission
at
the
current
time.
I
do
want
to
point
out
that
there
are
our
IP
our
statements
with
those
last
two
documents
and
Elliott.
C
C
A
A
A
Q1
is
the
DHCP
relay
port,
which
will
be
being
reviewed
by
the
IAS
G
later
this
month
on
their
Telesat
and
yeah.
There
is
3315
biz
with
suresh's
working
through
and
hopes
to
move
along
in
a
couple
of
weeks.
I
think
you
said
right,
and
there
are
two
other
working
group
drafts
that
are
currently
active,
and
this
was
written
a
little
before
it.
The
the
yang
model
was
republished,
so
there's
actually
three
and
all
of
those
are
on
the
the
sorry
that
sorry,
there
are
only
two.
It's
the
yang
model
was
already
there
I
misspoke.
A
B
So
I
skipped
the
preface
because
the
Charter
is
slightly
longer,
but
basically
the
preface
is
a
text
that
explains
that
the
HC
is
about
the
HTTP
protocol
and
but
but
the
the
most
important
part
are
the
items
that
are
here
on
the
slide.
So
the
first
item
was
to
develop
specific
extensions
to
the
HP
v6
infrastructure
and
the
Charter
was
very
specific.
So
we
listed
a
number
of
things
that
we
wanted
to
achieve.
I
think
there
was
nine
or
ten
of
them
and,
as
you
can
see,
they
are
now
color
coded
the
green.
B
The
green
one
has
are
done,
the
red
ones
are
either
felt
or
abandoned,
and
so,
in
the
current
form,
the
Charter
is
basically
done,
at
least
according
to
this
point.
So
there
are
other
items,
namely
item
number
three,
its
issue:
updated
versions
of
the
of
the
base
specifications.
This
work
technically,
it's
not
done,
but
it's
almost
done
so
it's
now.
It
is
G,
so
it
it
should
be
done
in
the
next
couple
months.
B
A
B
So
I
see
that
most
people
finished
reading,
so
we
can
move
on
and
this
is
updated
part
of
the
core
of
the
Charter,
so
Bernie
and
I
think
that
the
working
group
should
have
four
objectives.
The
first
one
is
to
issue
updated
version
of
the
DTV
six
by
specification
and
after
its
published,
we
should
wait
some
time
and
once
there
is
a
significant
deployment
base,
we
should
work
on
promoting
this,
this
RFC
to
full
internet
standard.
B
So
this
is
our
first
goal,
then
the
second
one
is
to
develop
documents
that
help
explain
operational
considerations
for
the
wider
community
if
and
as
needed.
So
sometimes
we
write
documents
that
explains
that
explaining
various
aspects
of
how
DSP
should
and
shouldn't
be
used.
So
this
is
something
that
that
we
could
write
and
I
talked
about
trees
to
assist
other
working
groups
and
independent
submissions
in
defining
options
that
follow
the
option,
guidelines
and
to
assure
operational
considerations
are
properly
documented.
B
B
However,
sometimes
there
are
cases
when
some
people
coming
in
and
say
that
hi
there's
not
really
working
group
appropriate
for
this
kind
of
work
and
in
their
case
there
should
be
an
exception
clause
that
we
talk
with
our
ID
and
if
we're
in
agreement
that
it's
okay
to
I
had
to
adopt.
This
work
then
could
be
done
in
THC.
D
The
work
that
we've
been
talking
about-
and
you
know
trying
to
reinvigorate
I,
guess
number
two
is
where
the
least
worst
fit
here
is,
but
it's
not
exactly
a
good
fit
for
that,
because
it
is
an
operational
document.
But
it's
not
it's
not
explaining
an
operational
consideration.
It's
it's
standardizing
your
yang
model
for.
A
A
We
didn't
want
to
you,
know,
numerate
the
things
we're
currently
working
on
so
because
that
can
change
you
know
and
and
when
things
get
finished
we
have
to
you
know
so
and
we
will
fix
the
typo
in
number.
One
there's
advance
the
to
full.
Internet
standard
needs
to
be
fixed.
That
should
be
ejected
okay,
but
you
know
and
we'll
wordsmith
it
I
mean.
You
know
we're
willing
to
take
suggestions
that
people
have.
A
If
you
want
to
add
a
number
five
here,
because
or
we've
number
them,
you
know,
add
something
else
or
whatever,
and
you
know,
obviously
it's
gonna-
we
haven't
shown
this
to
Suresh,
so
he's
gonna
go
through
it
and
the
iesg
may
have
comments
as
well
during
the
whole
retargeting
process.
So
we're
not
ready
to
send
us
in
yet
and
we'll
well,
I
mean
it
it's
been.
A
Most
of
this
text
has
been
available
for
a
while
on
the
wiki
page
that
we
have
for
this
particular
mania.
I
have
100
meeting
but
I'm
not
sure
how
many
people
looked
at
it
and
what
so.
We
will
send
us
out
to
the
mailing
list
and
get
some
discussion
going
and
hopefully
you
know
wordsmith
it
and
things.
D
So
I
mean
I'm
just
reading
the
text
of
four
again
and
that
specifically
says
additional
topics
and
option
work
with
agreement
from
the
responsible
area
director
I
mean
we
know
this
work
is
coming.
Does
this
mean
we
need
to
get
agreement
for
with
the
area
director
or
you
know?
Can
we
say
that
we
already
have
that,
so
it
should
be
it's
not
captured
by
four.
It
should
be
under
one
two,
three
which
so
you
say
your
point
about
the
additional
topics
with
approval
from
the
area
director,
yeah.
E
D
D
D
F
So
a
couple
of
things,
so
the
first
thing
is
like
a
few
years
away
right,
like
so
15
30,
15
bits
just
came
out,
so
I
would
say
like
let's
say
five
years
in
the
future.
We
need
to
revisit
that
right,
like
the
internet
standard
thing
and
for
like
for
itself,
it
really
doesn't
need
to
be
said
right
like
because,
like
you
know,
if
something
is
not
in
the
Charter
like
you
usually
are
each
other
to
do
it
right
so
out,
like
Tolley
break
this
down
into
few
things,
I'll
say
like
the
option
definition
work.
F
Anything
that
needs
to
get
done
needs
to
like
get
area
director
approval
and
be
done
with
it.
So
that's
just
a
milestone
and
just
leave
all
the
other
thing,
the
additional
topics
for
each
other
and
just
leave
it
out
because
that's
standard
right,
like
you
know
anything,
that's
not
on
the
chart.
It
needs
to
have
at
each
other.
So
yeah.
A
F
A
G
Danny
Moses
I
want
to
give
you
some
feedback
on
an
experience
that
I
had
trying
to
write
a
DHCP
option.
I
wrote
an
option
in
the
DMM
working
group
and
I
was
advised
by
Suresh
and
Sri
to
come
and
present
it
here.
I
presented
it
here.
Last
ITF
and
I
got
some
very
good
feedback
and
comments
to
fix
and,
from
my
experience,
it'll
be
very
difficult
to
assume
that
people
can
add
options
to
DHCP
without
coming
and
getting
feedback
from
a
professional
working
group.
G
F
A
There's
no
they're
encouraged
to
come
here,
there's
no
hard
requirement.
Now
there
is
another
gate
that
does
exist,
and
that
is
that,
when
options,
when
I
anti
gets
the
option
requests,
they
actually
send
email
to
Ted,
lemon
Tomic
and
myself
as
expert
reviewers.
Okay,
and
so
you
know
that
that's
the
way
the
registry
is
Oh
is
updated
anyway,
and
so
we
always
will
be.
You
know,
involved
in
sort
of
policing
the
the
options,
and
we
would
certainly
kick
something
back
if
we
felt
that
there
was
a
problem
with
it.
That's
okay!
A
B
Okay
and
I
just
wanted
to
believe
mention
what
are
the
current
items
that
seems
to
be
having
interest
of
the
working
group,
so
obviously
we
need
to
wrap
up
the
bees
work.
There's
the
real,
a
part
that
it's
also
mostly
done.
We
have
young
models,
so
currently
you
see
only
one
of
them
on
our
working
group
page
because
before
it's
expired,
but
this
doesn't
mean
that
it's
that
it's
simply
waiting
for
the
v6
to
continue
and
then
the
plan
is
to
copy
over
almost
we're
back
into
two
before
we
also
have
two
drafts
with
IOT.
B
Both
of
them
are
later
presented.
There's
also
one
topic
that
that
Bernie
and
I
are
currently
working
on.
This
is
a
mechanism
for
Marc
address
assignment
that
is
needed
in
a
couple
of
environments
in
IOT
and
also
in
massive
virtualization
environment.
When
you
have
a
hypervisor
that
sense
responds
many
VMs.
B
Publish
this
this
proposal
on
the
mailing
list,
so
other
people
who
are
not
in
your
own
are
also
able
to
see
think
about
this
and
possibly
post
some
comments,
and
then
we
will
charter
and
with
the
2015
piece,
we'll
just
wait
until
we
feel
that
there
is
a
substantial
adoption,
then
we'll
start
the
procedure
to
promote
it
to
antenna
standard
any
nemi
time.
We
will
continue
our
work.
D
Right
so
the
draft
has
been
fairly
dormant
for
some
time.
I
think
it's
nearly
a
year
since
the
last
update
sound
due
to
well
basically
a
lot
of
the
authors
moving
on
to
other
things
and
other
commitments
from
the
people
who
are
remaining
so
we
published
after
it
got
adopted
as
a
workgroup
item.
We
had
a
couple
of
updates,
fairly
small
ones
in
o2
and
o3,
which
were
you
know
very,
very
slight
changes
to
namings
and
various
leaf
nodes
and
sorting
out
a
few
tiny
bugs.
D
We
made
a
request
about
for
ATF's
ago,
I
think
for
some
young
doctor
review
and
also
some
implementers
reviews
which
we
did
receive
fairly
extensive
and
there's
a
lot
of
good
stuff
in
there.
But
it
was
never
really
acted
on
until
we
kind
of
tried
to
wipe
the
thing
up
again
in
in
version
zero,
for
which
is
the
one
that
got
published
just
before
the
cutoff
data
a
few
weeks
ago.
D
D
So
a
comment
from
Marcin
was
around
the
DUID
construction
and
you
know
going
back
and
his
comments
completely
justified.
It
was
nothing
like
what's
in
33:15,
so
that
got
very
much
reworked
and
I
think
looks
a
lot
better.
Now
it
certainly
matches.
So
you
know
what
what
the
capabilities
are.
You
know
how
they're
defined
in
1933
15
much
better.
D
We
had
some
enable
nodes
in
errors
and
sort
of
on/off
switch
for
various
bits
and
pieces.
That
comment
from
the
yang
doctor
review
was
that
there's
not
really
any
point
in
that,
so
those
have
gone
and
the
this
was
a
comment
from
far
away's
review.
I
think
the
reserved
address
and
prefix
at
the
level
they
sit
in
the
hierarchy
of
the
model.
If
you're,
if
you
looked
at
the
model,
that
would
make
more
sense
you,
but
if
you
haven't
I
strongly
recommend
you
do
yeah.
This
is
one
of
the
running
themes
that
we've
got.
D
You
know
that
we're
seeing
with
this
and
when
I
opened
the
document
up
again
notes
it's
it's
terrifying
in
its
size,
I
mean
we're
trying
to
model.
You
know
the
entirety
of
the
protocol
really
as
it
stands
at
the
moment,
and
this
is
making
for
a
a
very,
very
unwieldy
model.
So
in
one
of
the
review,
comments
was
to
divide
it
into
three
separate
modules
by
the
functional
element
that
they're
configuring
so
relay
server.
Client
that
will
definitely
improve
things.
D
I
think
we
can
go
further,
though,
and
I'll
talk
about
that
in
the
middle
in
a
minute,
yeah
the
description
fields
that
we
have
are
minimalist
to
say
the
least:
it's
not
a
hard
job
to
do.
It
just
takes
a
long
time
to
go
through,
and
you
know,
update
all
of
the
description
fields
in
in
a
way
that
makes
sense
without
them
becoming
too
verbose.
D
We
currently
explicitly
model
every
option
on
it.
The
way
back
are
they're,
probably
nearly
2
years
ago.
We
had
this
about
how
you
go
about
describing
options.
How
do
you
go
about
filling
those
with
the
relevant
content?
That's
going
to
go,
get
distributed
to
clients
in
the
server
model.
A
comment
we
got
back
from
a
review
was:
if
we
were
to
make
the
option
definitions
and
define
those
each
under
the
yang
features
statement,
then
it
would
make
it
quite
easy
for
a
server
implementation
to
be
able
to
indicate
I
support.
D
D
So
one
of
the
things
that,
when
I,
when
I
open
this
up
again
to
look
at
it
I
mean
it
is
horrendous.
Dividing
into
three
chunks,
as
for
the
by
function,
makes
some
sense.
I
think
what
would
also
make
sense
is
to
come
up
with
a
just
separate
out
the
model,
definite
the
option,
definitions
into
a
separate
model
and
then
reference
them,
because
I
think
that
would
lead
to
having
a
much
more
readable
server
model,
client
model
and
relay
model,
and
then
we
just
reference
and
pull
in
the
other
options.
D
I
also
think,
there's
a
lot
that
around
the
maintainability
of
the
structure
that
would
when,
when
you
want
to
add
new
options
for
as
they
get
defined
in
the
future,
then
we
only
have
to
touch
one
part
of
it.
The
main
server
cut
a
portion
doesn't
need
to
be
touched
which
may
make
it
a
little
bit
more
maintainable.
D
The
option
definitions
that
we've
got
ie
did
a
bit
of
a
compare
and
contrast
against
the
original
RFC's
that
they
come
from
and
in
many
cases
they're
way
off.
So
there
needs
to
be
some
some
good
diligence
kind
of
going
through
and
actually
reading.
What's
in
the
original
draft
or
original
RFC's
that
these
options
come
from
and
modeling
them
more
accurately
in
yang
that
leads
onto
the
whether
you've
got
a
single
tune
or
a
multi
option,
we
need
to
put
things
into
lists
some
contain
as
if
they're
Maltese
and
not
within
lists.
D
If
there
are
singleton
options,
we
need
to
look
at
how
other
IETF
models
are,
which
other
existing
IETF
molds
we
have.
It
may
well
be
that
we
need
to
apply
these
functions
to
ingress
interfaces
in
the
server
or
or
whatever
I'm,
not
I'm,
not
sure
at
that
stage,
how
that's
going
to
work
exactly
or
if
it
needs
doing
but
I
think
it's
worth
looking
into.
D
I
think
we
need
some
text
in
there
about
extensibility
because,
as
it
stands
at
the
moment,
you
know
it's
a
constantly
evolving
protocol
and
you
know
if
we
have
something
that
is
goes
out
of
date,
the
minute
that
it's
published.
It
would
be
good
to
write
it.
You
know
make
it
as
easy
as
it
possible
for
new
option
developers
to
be
able
to
say
and
here's
the
yang
to
be
able
to
do
this
so
that
things
can
be
updated
or
they
can
just
write
that
and
extend
it
internally
in
their
own
implementations.
D
D
So
what's
next,
basically,
we
need
some
help,
that's
what
it
comes
down.
So
we
need
people
to
spend
some
time
on.
This
I
think
Tomic
put
something
out
on
the
list
earlier
on
today,
asking
if
anyone
would
step
forward.
I
would
say
at
this
stage
you
know
even
no
knowledge
or
or
minimal
knowledge
of
Yang
may
not
need
to
be
a
barrier.
If
you
are
keen
and
enthusiastic.
C
C
This
is
interesting
work
from
seven
different
from
several
different
dimensions,
first
of
which
is,
of
course,
people
want
to
manage
their
large-scale
DHCP
infrastructure
mechanism
and
that's
what
people
had
in
mind.
I
think
when
they
first
developed
this
out.
I,
don't
know
if
you
were
to
an
original
co-author.
This
were
you
I,.
C
C
Like
you
know,
what's
your
prefix,
would
you
know
what
IP
address
using?
What's
your?
Maybe
what's
your
next
hop
router
and
things
like
that,
depending
on
all
right
before
v6
what-have-you,
and
then
there's
this
other
stuff
that
we
have
a
ton
of
options
for
which
is
nice
to
know
like?
What's
my
printer?
What's
my
NTP
server?
What's
this
that,
in
the
other
write
that
you
don't
necessarily
need
for
that
first
bring
up
to
send
packets,
but
you
might
very
reasonably
want
to
know
that
stuff
we
may
be
in
a
position.
C
You
know,
given
that
we've
done
yen
right
for
all
of
this.
Well,
then
you
can
serialize
it
and
if
you
can
serialize
it
in
something
like
OSI
bore
or
JSON
or
what-have-you.
At
that
point,
you
can
protect
it
over
Oh,
co-op,
ass
or
something
like
that.
We
can
begin
to
think
about
how
we
might
want
to
protect
this
stuff
now.
I,
don't
expect
this
to
be
a
thing
that
happens
in
the
next.
You
know
it's!
It's
not
something
that
people
are
going
to
dump
their
entire
DHCP
infrastructure
next
year.
C
D
C
C
What
we
have
to
start
in
terms
of
thinking
about
this
is
structuring
the
data,
the
the
the
node
definitions,
such
that,
yes,
the
we
want
to
make
sure
that
we
separate
out
the
only
absolute
necessary
things
in
terms
of
options
from
the
other
things
which
may
not
be
necessary
for
the
bring
up,
but
can
it
but
our
reasonably
good
choices
for
initial
protection.
So.
D
C
Things
that
you
know
you
probably
can't
protect,
because
you
don't
you
don't
have
enough
you're,
not
up
enough
to
establish
that
protection,
and
we.
This
is
a
thing
where
we
could
argue
back
and
forth
that
individual
options
right
but
they're,
mostly
the
ones
that
are
mandatory
right
in
terms
of
v4
and-
and
you
know
the
you
know
things
with
the
M
date
set
for
for
v4
v6.
Maybe
right
I'm,
a
hazard,
a
guess
as
to
what
the
you
know
where
that
line
exactly
is
we
don't
have
to
do
that
now?
I
think.
A
Let
me
just
interject
here:
I
think
that
when
I
mean
you're
talking
more
about
the
sort
of
protocol,
core
options
versus
the
other
configuration
options
and
I
think
yeah
I
think
you
know
I
mean
that's
an
interesting
question
that
I
think
we
have
to
look
at
and
even
this
you
know
it
dividing
it
out
for
the
work
that
that
in
had
specified
of
separating
out
the
options.
It's
it's
an
interesting
question
about
you
know.
I
was
thinking
that
we
were
really
just
dividing
out
the
other
configuration
options
and
sort
of
the
core
protocol.
D
D
C
C
I
think
it
is,
then
you
know
in
terms
of
how
you
divide,
whether
is
this
one
document
or
two
documents:
I
I,
do
think
that
is
a
really
good
question
and
I
don't
have
a
really
good
answer,
because
maybe
that
the
document
is
is
I
think
a
bit
of
a
monster
at
this
point
and
I
do
like
that
that
it
they
did
all
this
work.
You
guys
did
all
this
work,
it's
great
stuff,
and
maybe
we
can
get
it
all
done
really
quickly.
I,
don't
know,
I
mean.
D
I
I,
don't
know
I
with
with
yang
models,
and
you
know
this
is
not
the
only
one
I'm
working
on
what
I.
What
I
see.
You
know
that
the
RFC
is
kind
of
you
know
it's
just
a
vessel
for
container
what
people
are
interested
in
is
the
model
itself
and
I
I.
Think
you
know,
there's
not
really
any
there's
not
much
logic
in
having
multiple
RFC's
to
define
this.
It's
that
it's
the
dividing
of
the
modules
and
you
know
those
by
function.
That's
what
people
use
and
you
know
they
need
to
be
self-contained.
F
So,
like
I
understand
what
you're
saying
Elliott
right,
like
you
said
it's
probably
trying
to
boil
the
ocean
thing
a
little
bit,
but
I
don't
mind
if
you
start
thinking
about
this
like
future
stuff,
but
on
the
security
side.
There's
like
a
couple
of
things
there.
So
you
talked
about
like
you
know,
something
like
you
know,
a
score
or
something
like
that.
I
like
you,
know
something
to
secure
it,
but
there's
a
couple
of
pieces
in
the
in
the
DHD
security,
so
one
of
them
is
the
object.
F
So,
like
you
know,
you
get
something,
and
then
you
pull
off
a
bunch
of
things
in
JSON,
so
maybe
like
for
lack
of
a
better
term.
If
I
call
something
like
you
know,
if
the
configuration
things
are
information
elements
we
can
probably
map
them
into
multiple
in
codings
to
send
them
out
right,
like
could
be,
DHCP
could
be
one
of
them
and
then,
like
you
know,
like
seaboard,
would
be
another
one.
So
I
think
it's
good
to
keep
that
in
mind
and
the
yang
stuff
goes
on,
but
yeah.
It's
like
a
longer-term
project.
Yeah.
A
There's
a
question
about
you
know
the
evolution
of
the
model,
cuz
I,
think
the
you
know,
by
putting
the
options
in
a
separate
document
right
that
one
may
evolve
quickly,
but
the
base
client
server,
really
model
kind
of
stays.
The
same
right
I
mean
so
that
that's
an
advantage,
but
there's
also
the
question
about
you
know:
would
future
option
definition
documents,
maybe
just
so
to
say:
here's
the
you
know
additional
part
of
the
yang
model
that
you
need
to
do
it
I
mean
that
may
be
a
way.
A
E
D
D
C
I
was
just
gonna.
Add
this
Elliott
again
that
I
think
that
one
as
we
go
forward
and
we're
thinking
about
the
revision
model.
For
all
of
this,
then
I
think
that's
one
where
we
do
want
I
hate
to
say
this
because
it
drives
me
batty,
but
we
do
want
to
be
very
careful
to
consult
with
the
yang
doctors
yeah
and
just
make
sure
that
we're
that
they
have
a
view
on
this.
Okay,.
I
A
Did
we
get
everybody
all
right,
so
you've
got
you've
got
people
to
help
out
might
be
good
to
have
you
know,
maybe
there's
a
set
up
a
conference
call
or
something
for
trying
to
figure
out
how
does
divvy
up
the
work
and
what
to
do
or
something
I,
don't
know
what
the
next
step
well.
You've
got
the
names
there
do
we
have
contact
details
for
everyone,
that's
on
there
and
no
so
maybe.
B
D
A
H
Hey
my
name
is
Srinivas
from
erikson.
Okay.
This
is
a
draft
to
propose
some
options
required
to
enable
lwm
team
services
on
in
IOT
scenarios,
and
this
draft
is
to
set
some
context.
This
draft
is
presented
in
Prague
IIT
of
nineteen
nine
and
it's
of
course,
after
that
it
is.
It
was
adapted
by
the
working
group
and
there's
some
comments,
I
received
from
working
group
and
there's
some
comments
outside
working
group.
Also.
First,
the
comments
important
comments,
of
course,
keeping
the
editorials
aside.
H
One
comment
from
Francis
about
the
certificates
that
we
can
encode
as
part
of
options.
That's
I
mean
I,
didn't
mention
very
clearly
in
the
previous
questions,
so
I
added
a
section.
Obviously
it's
taken
from
the
RFC
seven
to
nine
six.
The
data
is
taken
from
that
and
that
section
explains
now
how
what
type
of
certificates
can
be
encoded
and
there's
some
comments
from
vernier.
D
H
H
And
in
the
last
meeting
when
I
presented
remotely,
there
was
I
mean
working
group
insisted
that
this
should
be
reviewed
by
some
I/o
TX,
but
also
because
we
here
are
not
experts
in
lwm
diem.
So
that's
why
I
I
was
trying
to
find
people
and
things
to
think
are
G's
research
book
is
the
place
where
I
went
and
the
chair
of
the
Atari
car
man
assigned
to
the
US
for
that.
Aha,
nice
and
Caston
and,
of
course,
I
got
one
generic
comment
from
honest
about
security,
and
this
is
something
okay.
H
His
question
is:
how
do
we
prevent
that?
An
attack
of
such
Sapodilla
server
and
points
is
the
device
to
the
his
rail
WM
Tim
server
and
take
control
of
it.
That's
his
question.
Of
course
the
question
is
valid.
Obviously,
but
this
is
not
the
problem
introduced
by
this
option
alone,
because
that's
what
can
happen
to
any
option
which
we
have
today?
They
it's
like
other.
H
So
this
is
what
I
try
to
explain,
and
these
are
the
things
which
I
saw
as
implementations
in
different
products
today
and
yeah.
In
spite
of
that,
there
is
further
communication
with
Hanus
e
is
probably
looking
for
a
solution
where
device
can
protect
itself.
We
are
trying
to
say
that
you
deploy
your
network
switch,
that
device
is
protected
and
there
is
still
some
coming
some
discussion
going
on
and
yeah.
It's
not
closed.
A
H
Okay,
fine
I
love
added
to
the
working
group,
mail,
Jake,
okay,
see-
and
this
needs
to
be
still
closed.
Okay,
the
next
step,
but
this
is
okay,
as
I
said
working
group
opinion
on
this
particular
comment
and,
of
course,
I
have
to
discuss
further
with
the
expert.
He
did
not
say
no
to
the
document
as
of
now,
but
he
said
he'll
think
about
this
and
get
back
and
eat
some
time.
That's
what
he's
saying
so!
D
A
Of
the
security
issues
that
you
talked
about
are
basically,
where
you
know
the
3315
biz
document,
that's
also
sort
of
what
we
concluded
about
the
security
model
because
of
you
know
using
the
HTTP
six
card
and
things
like
that
that
that
most
networks
already
provide
fairly
decent
security
at
the
lower
levels
and
therefore
you
know
that's
one
of
the
reasons
we've
the
ban
and
the
SE
dhcpv6
work,
stuff
yeah.
So,
okay.
H
Regarding
the
specific
comment
related
to
the
malicious
DHCP
servers,
I
just
need
to
seek
some
information
from
working
group.
Is
there
any
other
solution
other
than
what
I
was
mentioning
which
came
across
in
any
of
the
discussions?
That's
one
point:
I
want
to
bring
out
yeah
if
something
is
known
as
Suresh
said
DHCP,
it's
all
about
trusting
the
DHCP
server
yeah.
So
I
was
trying
to
explain
the
same
to
the
expert,
but
that's
where
there
is
some
lock
yeah.
A
D
A
One
one
thing
and
I
forgot
to
mention
that
too
in
suresh's
pinged,
both
Tomek
and
I
to
update
the
milestones
on
the
documents
that
we
currently
had.
And
so
you
know
one
of
the
things
for,
since
both
you
guys
are
authors
is
to
to
you
know,
think
about
that
and
send
us
some
stuff,
otherwise
Tomac
and
I
will
make
up
some
stuff
for
you.
H
Okay,
yeah:
that's
about
this
draft
yeah,
okay,
yeah,
okay!
This
draft
is
which
is
somewhat
similar
to
what
we
were
talking
already,
but
it's
different
use
case
and
different
protocol.
I
could
not
think
of
it
when
I
was
submitting
the
previous
one,
so
I
thought
it.
I
can
bring
it
to
the
working
group.
So,
okay,
the
context
for
this
draft
again,
it's
use
cases
or
I
were
to
use
cases
and
MQTT
Message
Queuing
telemetry
transport.
H
This
is
a
protocol
which
is
quite
old,
but
it's
regaining
popularity
in
los
five
six
years
again
because
of
I
was
related
scenarios,
so
there
is
need
to
enable
there
is
need
for
a
few
options
to
enable
MQTT
services
on
devices
in
better
way.
That's
what
this
draft
is
going
to
talk
about,
so
just
to
set
the
context
about
mqtt
protocol
just
one
slide.
H
So
this
is
a
protocol
from
oasis
standards
body
and
it
runs
on
TCP,
and
this
is
a
publisher
and
subscriber
Moodle
protocol,
where
one
publisher
or
multiple
publishers
publish
that
data,
and
there
is
some
intermediate
node
called
broker,
who
replicates
it
to
other
people
who
are
interested
or
who
are
subscribed.
So
this
publication
of
data
happens
for
topics.
Topics
can
be
anything
you
can
just
take
it
as
a
string,
for
example,
any
string,
then
history,
okay,
the
topic
looks
like
this:
it's
generally
hierarchical
string
to
understand
it
better
hierarchy.
H
It's
like
the
temperature
of
your
home
ground
floor
living
room.
You
can
just
say
that
in
hierarchical
way,
that's
how
it
looks
like.
So
what
is
a
problem?
Actually
here?
The
problem
is
again
it's
similar
to
what
we
discussed
in
previous
Roth.
Of
course,
the
how
client
can
reach
to
mqtt
broker.
There
is
no
dynamic
way
today.
It's
hard-coded,
it's
it's
manually
configured
and
there
is
a
need
for
dynamically.
Getting
that
URL
of
the
broker.
H
These
topic
there
is
there
are
no
guidelines
to
manage
this
topic
as
of
now.
This
is
also
something
like
if
I
want
to
publish
data
for
a
specific
topic.
The
topic
again
manually
configure
that
they
by
saying
that,
okay,
if
you
want
to
publish
temperature,
use
this
string
as
topic
for
publishing
the
temperature,
this
is
a
manual
configuration
today,
which
is
error-prone,
and
there
is
no
centralized
control
for
this
topic.
Space,
which
is
causing
problems
in
the
network
to
different
clients,
to
different
publishers,
publishing
data
to
same
topic,
which
is
finally
causing
lot
of
problems.
H
So
I
see
need
for
these
options.
Of
course,
I
am
considering
v4
also,
as
I
said
earlier,
it's
not
so
important,
it's
more
for
v6,
but
I'm,
considering
for
me
for
also
as
of
now.
So.
These
are
the
four
thing
of
course:
broker
URI
for
both
v4
and
v6,
and
the
topic
prefix
for
v4
and
v6.
Okay.
This
is
how
the
options
looks
like
as
copied
from
the
truck.
Of
course,
that
first
line
there
is
some
alignment
issue,
I
think
in
the
picture.
H
J
Robber
naggy,
deep
dive,
networking
look,
I
understand
the
popularity
of
it
coming
back
to
me
and
all
that
other
people
get
up
and
speak.
This
certainly
Falls
as
a
not
a
option
itself,
but
it
we
already
have
mechanisms
for
this
with
vendor
define
so.
Okay
to
me,
this
doesn't
tie
up
an
option
number
on
its
own,
but
that's
just
my
thoughts.
I
mean
we
have
mechanisms
to
do
this
today
and.
J
Have
ways
to
do
this
all
right
and
like
I
was
saying
Suresh.
We
we
define
all
these
options
for
things
that
then
get
limited,
use
come
in
and
out
of
fashion,
and
then
we
can't
get
our
option
lists
updated,
would
type
because
one
person
might
still
be
using
it.
So
while
it's
great
today
does
this
warrant
us
having
the
stuck
in
our
list
forever.
As
we
know
we
are
so
to
me,
this
should
use
the
mechanisms
we
have
for
things
that
aren't
quite
full-time
yeah.
A
I
mean
that's
always
a
good
question
is
whether
somebody
like
you
know,
if
you
say
I
think
he
said.
Oasis
is
doing
this
and
you
know
that
standards
organization
may
already
have
an
enterprise
number
ID
number
and
if
they
don't,
they
can
always
get
one,
and
they
could
do
this
all
under
the
vendor
option
space
and
it's
all
within
their
control.
And
so
you
know
that
that's
a
question
that
I
think
it
should
always
be
asked
about
whether
that's
a
better
solution,
and
we
have
that
both
for
B,
4
and
B
6
right.
F
D
F
Makes
sense-
and
that's
one
thing
in
the
second
thing
is
MQTT-
is
not
like
IDF
protocol
right
like
so
that's
also
another
thing
to
consider,
so
it's
going
straight
against
coop
really,
so
that's
just
think
about
it.
Like
I.
Am
it's
not
like
I'm
worried
about,
like
you
know,
option
space
getting
exhausted,
but
the
question
is:
like
you
know
it's.
Is
it
off
use
like
to
standardize
this
and
I'd?
Yes,
that's
really
something
that
you
can
probably
look
at.
Okay,.
H
A
Well
again,
it's
sort
of
like
what
cable
labs
did
you
know?
Cable
labs
has
a
whole
bunch
of
options
that
are
done
through
the
vendor
options
and
it's
cable,
as
as
a
standard
organization
maintains
that
directory.
It's
not
it's
not
to
say
that
you
know
IOT
vendor
X&Y,
which
are
both
doing
this
MQTT.
What
is
yeah,
are
you
know?
We
don't
want
those
vendors
to
do
the
option.
We
want
Oh
a
sis
as
the
standards
organization
that
is
responsible
for
mqtt
to
get
a
vendor
to
use
their
enterprise.
A
Id
vendor
option
space
to
define
these
options,
okay
and
they
they
have
a
whole.
You
know,
then,
before
they
have
256
options,
they
can
do
well,
they
can
do
any
number
because
they
can
define
whatever
one
they
want
for
the
the
actual
data
within
their
enterprise
space,
but
usually
we
would
recommend
they
be
sub
options
and
so
you've
got
256
or
for
v6.
You
have
65,000
and
you
can
manage.
Our
oasis
can
manage
that
themselves.
A
That's
what
CableLabs
did
they
have
an
enterprise
ID
number.
They
manage
a
directory
of
options
for
how
cable
modems
are
supposed
to
and
the
cmts
are
communicating,
and
so
you
know
it's
not
it's
not
cisco,
cmts
or
error.
Cmts,
that's
using
their
private
vendor
space.
It's
actually
the
table.
Labs
standards,
organizations
under
space
right
yeah,
exactly.
F
B
So
also
a
side
comment,
atif
other
organization
like
classes
takes
over
and
this
window
space
and
they
have
issues
which
define
a
few
options.
I
suppose
this
is
not
in
our
proposed
charter,
but
to
provide
review
of
the
proposed
options.
But
if
they
show
up
and
ask
for
a
review
we
we
could
provide
it
so.
A
They
want
to
say
otherwise
thank
you
and
we'll
save.
Maybe
you
know
what
we're
will
be
sending
out
the
agenda
requests
fairly
soon
for
London
and
we'll
see
what
happens.
You
know
it's
possible.
We
may
go
dormant
if
we
have
no
topics
for
permitting,
but
we'll
see
what
happens.
Hopefully,
we'll
have
some
good
progress
on
the
yang
model
to
discuss
and
yeah.
If
you
haven't
signed
a
blue
sheet,
please
do
so.