►
From YouTube: IETF100-DOTS-20171114-1330
Description
DOTS meeting session at IETF100
2017/11/14 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
A
Okay,
okay,
let's
move
forward,
so
we
have
a
usual
usual
order
of
affairs.
Here,
we're
going
to
talk,
use
cases,
requirements,
architecture,
then
we'll
get
into
the
protocol
discussion
and
we're
gonna
have
some
exciting
conversations
related
to
our
hackathon
and
our
Interop
testing
next
slide:
okay,
a
lot
of
activities
since
we
got
together
last
we
did
have
a
virtual
interim
in
Akhter
early
October
and
we've
seen
a
ton
of
discussion
on
the
mailing
list
related
to
implementation.
A
Experience
next
slide
and
I
just
wanted
to
call
attention
to
something
new
in
in
the
world
kind
of
last
week
or
two
we're
trying
to
get
more
content
organized.
We
obviously
use
github
a
lot.
We
have
some
implementations
so
wanted
to
put
that
all
in
one
place.
So
there
is
now
content
on
the
dots
track.
Wiki
in
github
you'll
find
working
copies
of
almost
everything.
That's
cutting
edge
there
and
the
issue
trackers
are
live
there.
A
So
if
you
want
to
point
out
something
related
to
a
particular
draft,
that's
in
there
and
the
different
editor
teams
right
now
are
trying
really
hard
as
we're
trying
to
get
to
working
group
last
call
on
various
documents
to
really
be
transparent
on
what
are
the
outstanding
items
there
then
just,
lastly,
just
to
point
out
again:
we
have
to
live
implementations,
you
can
see
them
referenced
there
and
we
also
have
a
public
test
server.
That's
also
up
and
running
that
you
could,
if
you're
building
an
implementation
used
to
help
you
next
slide.
A
Something
I
want
to
talk
about
later,
as
we
go
through.
The
different
drafts
is
we're
behind
on
some
of
our
milestones
and
we
want.
We
need
to
crisp
up
what
we
want
to
do
about
all
of
that
all
right.
So
with
that,
why
don't
we
get
started?
First
up,
we
have
Roland
Dobbins
who's,
going
to
be
a
remote
and
he's
going
to
be
telling
us
where
we
stand
with
use
cases.
C
E
D
F
A
E
D
A
E
E
I
think
the
the
major
work
is
really
an
attempt
to
address.
Some
heart
beat
concerns
that
were
brought
up
at
the
IETF
99
meeting
in
the
wake
of
some
implementer
feedback.
We've
also
had
the
good
fortune
to
get
a
lot
of
working
group
feedback
in
the
interim
lots
of
coal
requests.
Thank
you
very
much.
Everyone
we've
addressed
a
lot
of
editorial
minor
editorial
issues.
You
know
some
misspellings
and
rewarding
some
clarifications
and
we
do
not
have
any
issues
open
on
the
github
tracker.
E
E
So
the
first
issue
to
come
out
of
discussion
around
the
the
heartbeat
in
the
wake
of
some
of
the
implementer
feedback.
Was
this
idea
of
a
zero
heartbeat
mode
in
which
aDOT's
client
might
be
able
to
just
request
mitigation
without
having
to
stab
you
know
continuing
heartbeats
between
the
the
client
and
the
server.
E
This
would
have
been
just
a
minor
change
to
the
requirement
level
for
an
implementation,
but
in
subsequent
discussion
we
also
uncovered
the
need
to
have
some
heartbeat
rate
flexibility,
especially
during
peacetime.
There
were
some
concerns
raised
about
the
potential
load
that
clients
could
impose
on
a
server
by
overwhelming
it
with
heartbeats,
especially
when
we're
talking
about
having
a
heartbeat
rate
at
around
30
seconds
at
or
below
30
seconds,
so
the
this
revision
of
the
draft
attempts
to
create
space
for
both
of
those
considerations.
E
What
we
have
currently
is
that
the
heart
rate,
heart
beat
rate,
must
maintain
that
bindings
when
mitigation
is
active,
so
there
must
be
a
heartbeat
rate.
That's
at
30
seconds
below
when
a
client
has
requested
mitigation
and
that
the
rate,
the
heartbeat
rate,
is
flexible
during
peacetime.
We
do
know
this.
This
is
something
that
we've
also
gotten
some
feedback
on.
So
we
anticipate
adjusting
this
slightly.
It
would
be
useful
during
this
meeting
to
get
some
discussion
of
that
as
we,
we
press
toward
working
group
last
call
but
I
believe
with
these.
E
E
Great,
thank
you.
It
was
just
a
little
slow
to
update
on
my
end,
alright,
so
there's
also
been
some
honest
discussion
of
NAT
considerations.
It
seems
like
a
lot
of
this
can
be
covered
in
the
architecture
which
I
will
cover
in
the
next
presentation
that
I'm
doing,
but
it's
not
clear
to
me
that
there
are
there's
any
impact
on
the
requirements
as
a
result
of
this
discussion
of
not
considerations,
I,
don't
in
going
back
through
the
archives.
I,
don't
see
anything.
E
That
means
an
obvious
change
to
the
requirement,
but
other
members
of
the
working
group
may
disagree
with
me.
I
believe
Artyom
brought
up
the
possibility
of
black/white
list
conflict
resolution.
My
impulses
is
simply
to
say
that
white
lists
will
supersede
black
in
this
case,
but
again
the
the
working
group
may
disagree,
and
finally,
there
was
a
discussion
raised
by
John,
Chow
and
furthered
by
thiru
on
the
issue
of
order
in
tackles.
It
sounds
like
a
recent
nut.
E
Model
Model
Draft
has
has
added,
ordered
a
cassettes
which
we
would
need
then
to
to
potentially
address
in
the
requirements
themselves,
but
I
believe
this
is.
This
is
all
that
we
have
remaining
the
have
next
slide
other
than
that
we
are
looking
to
go
to
working
group.
Last
call
and
I
hope
that
we
are
we've
been
at
the
verge
of
it
for
a
long
time
and
so
I
hope
we're
actually
seeing
the
end
in
sight
and
I
believe
that
does
cover
it.
I
Andrew
Fleming
and
race
near
could
we
get
the?
What
was
it
two
slides
back
again
with
you
to
open
questions?
Yes,
on
that
discussion,
I
agree,
I,
don't
see
any
impact
on
the
requirements
in
terms
of
the
other
two
items:
black
white
there's
conflict
resolution
and
a
glue
ordering.
Do
we
really
need
to
deal
with
that
in
the
requirements,
or
is
that
something
that
we
can
just
deal
with
in
the
protocol
drafts
themselves?
I'm.
E
I
J
D
D
So
this
is
to
be,
as
with
working
group
chair
head
off
sorry
that
I'm
not
getting
off
of
the
chair
at
the
moment.
I
also
start
and
read.
The
document
I
would
agree
with
that
perception.
Do
we
should
we
ask
how
many
have
read
this
or
okay?
So
then,
could
someone
raise
whether
you
have
seen
the
last
iteration
or
the
one
before
the
last
and
read
it
one
two,
three,
four:
five:
six:
seven
something:
six
six
ish!
D
D
A
D
Yeah
so
then
without
objections,
let's
let's
say
in
two
weeks:
we
initiate
it.
What
do
we
call
so
expect
that
in
yeah
in
two
weeks
time
from
now,
we
will
initiate
working
group
last
call
and
it
will
have
a
duration
of
two
weeks.
So
if
you
want
to
read
it
now,
you
can
read
it
and
then
you
have
plenty
of
time
to
post
your
comments.
Okay,
moving
back
to
the
use
cases,
Roland,
can
you
hear
us?
Did
you
miss
your
audio
working
now.
J
E
E
E
E
The
dots
client
can
operate
entirely
without
using
the
data
Channel,
but
it
can
also
take
advantage
of
the
functionality
that
the
data
channel
offers
to
do
things
like
install
Ackles,
black
and
white
lists
so
on,
but
it's
not
necessary
by
itself,
as
a
component
of
the
these
signaling
may
have
the
next
slide.
Please.
E
So,
as
I
mentioned
in
the
requirements
discussion,
there
was
some
discussion
Matt
on
the
list,
I'm
sorry
I'm,
having
some
echo
in
just
a
moment.
There
was
some
discussion
of
not
on
the
mailing
list,
largely
that
is
going
to
be
focused
on
the
architecture.
So
that's
where
we're
proposing
to
move
it.
One
of
the
issues
that
was
brought
up
is
dots
hi
in
signaling,
from
a
private
IP
space
through
net
to
request
mitigation.
E
We
need
to
discuss
how
the
dot
server
treats
that
and
how
it
both
ends
interact
when
such
a
model
is
being
deployed,
and
then
the
other
thing
that
came
up
as
a
result
of
further
discussion
was
how
to
request
mitigation
for
privately
address
services.
Maybe
using
D,
not
NASA,
not
let's
say,
has
something
a
service,
that's
being
deployed
in,
let's
say
a
private
cloud.
E
Next
slide,
please.
So
the
only
open
issue
right
now
is
the
request
for
in
that
consideration
section.
However,
we
do
have
one
pull
request:
proposing
an
addition
of
an
appendix
covering
multihoming.
We've
had
some
discussions
among
the
document
among
the
draft
team
and
we're
not
sure
that
the
full
appendix
is
something
that
we
need
to
have,
but
potentially
some
minor
additional
work
regarding
multihoming
and
when
we
have
that
we
do
believe
we're
ready
to
press
forward
with
the
working
group.
Last
call.
D
G
I
mean
she's
got
from
NTT
communications
so
regarding
to
not
yeah
if
the
it's
channel-
and
you
know
each
other
is-
is
kind
of
separated,
then
some
of
mobile
applications
or
something
can
do
education
from
those
client
in
mobile
applications.
So
in
that
case,
I
thought
to
be
within
a
private
IP
address
space,
so
I
can
heat
up
on
such
kind
of
the
situation.
Okay,.
L
L
E
I
agree
with
you:
yeah
I,
don't
I,
don't
agree
that
we
needed
an
appendix
covering
multihoming.
This
is
a
this
is
a
proposed
pull
request
from
another
working
group.
Member
and
my
my
sense
is
that
it's
not
appropriate
for
the
document,
but
potentially
some
minor
additional
discussion
of
multihoming,
maybe.
I
I
We
need
to
add
that
I
think
it's
capturing
what
has
been
discussed
on
the
mailing
list
and
I
also
agree
with
the
multihoming
I
think
there
is
treatment
of
that
in
the
architecture,
draft
right
now
and
I
think,
what's
being
proposed
to
being
added
right
now,
I
think
goes
be
up
and
above
and
beyond
what
is
really
necessary
for
the
architecture
document.
So
we
can
look
at
it.
You
know
one
see
if
there's
any
wording,
tweaks
needed,
but
I
think
in
appendix
is
probably
a
little
bit
too
much.
D
D
M
D
We
defer
this
to
later,
if
that's
okay,
so
let
me
come
back
to
one
question
like
who
has
reviewed
the
architecture
draft
in
the
last
or
last
two
previous
to
last
version
wow
that
is
super
low.
That
means
like
three
reviews
and
like
wow,
four
okay,
Oh
I
mean
it's
should
I,
maybe
change
the
question
is
there
even
like?
Should
we
proceed.
A
J
D
E
Know
speaking
only
for
myself,
I
think
the
net
considerations
is
very
quick
work.
We
have
a
lot
of
this
already
captured
on
the
mailing
list
and
then
the
multihoming
discussion
I
think
we
can
probably
discuss
among
the
authors.
We
will
communicate
with
the
author
of
the
pull
request
and,
let's
see
if
we
can
get
something
that's
agreeable
to
everyone,
but
I,
don't
anticipate
just
taking
much
work.
A
A
H
Great,
so
let's
go
ahead
and
advance
to
the
next
slide.
Please,
okay!
So
we
made
some
very
significant
changes
versus
409.
We've
reorganized
the
use
cases,
and
the
idea
here
was
to
make
it
so
that
those
who
are
really
focused
on
implementing
dots.
You
know
coders,
pretty
much
very
quickly
see
what
they
needed
to
see
in
terms
of
the
anticipated
communications
model,
whereas
those
who
were
more
operationally
focused
and
who
actually
cared
more
about
things
that
are
externalities
to
the
dots
protocol
itself.
H
That
are
our
key
or
network
operators
founders,
and
you
can
see
what
they
needed
to
see
without
either
having
to
really
leak.
Read
some
use
cases
that
have
lots
of
different
variations,
but
that
wouldn't
necessarily
be
of
interest
to
to
either
party
we
streamlined
the
dots,
Communications,
modeled
listings
and
change
of
the
verbiage
to
make
it
more
accessible.
We
added
lead
us
to
the
security
considerations,
which
probably
should
have
been
worked.
The
first
we
added
an
internal
main
use
case
back
in
o8,
an
additional
one
that
was
suggested
by
the
working
group.
H
We
need
more
feedback
on
the
home
network
use
case.
We
just
got
some
from
Fleming
and
from
some
other
folks,
that's
good
or
WG
feedback.
On
that
question.
For
the
working
group
do
we
need
a
use
case
which
involves
dots
game,
I'm,
inclined
to
think
that
we
do,
but
we
need
to
hear
from
the
WG
do
we
need
any
additional
intra-organizational
use
cases,
and
if
so,
we
would
love
to
hear.
H
The
specifics
of
the
use
case
is
that
WG
member,
which
is
offense,
think,
should
be
added
and
of
course,
any
additional
feedback
would
be
greatly
appreciated
as
well.
Are
we
essentially
ready
for
working
group
last
call
I,
don't
think
so?
Quite
yet,
we've
just
got
some
additional,
very
good
feedback
on
the
list
that
our
organization
and
refactoring
have.
This
aft
has
been
good
that
we
need
to
go
through
one
more
iteration,
so
I
don't
think
that
we're
quite
ready
yet,
but
we're
close
on
a
a
draft
organizational
perspective
next
slide.
I
Fleming
Andrea
isn't
so
I
agree.
I,
don't
think
this
document
is
quite
ready
for
working
group
last
call.
Yet
we
got
some
comments.
I
think
Roman.
You
made
some
good
observations
as
well.
I
would
encourage,
though
the
group
to
get
this
to
working
group
last
call
pretty
quickly.
I
I
think
you
know
the
should
say
they
return
on
further
investment
right
is
to
managing
at
this
point
and
I
would
like
the
group
to
start
focusing
on
the
protocol
drafts.
D
D
D
H
D
The
use
cases
draw
hands
up:
okay,
okay,
so
it
seems
we
are
hit
again
by
demographics,
that's
just
for
and
it's
for.
Yes,
yes,
these
were
just
the
last
well
well,
but
there
weren't
significant
changes
on
the
last
arrests
who
has
plans
to
review
the
draft
in
version.
Oh
nine,
now
going
forward
in
the
next
two
or
three
weeks,
one:
two:
three:
okay,
there's
a
couple
of
hands:
good,
okay!
So
that's
good
yeah,
I,
think
yeah.
So
so,
let's
wait
for
the
review,
but
also
to
the
author
team.
D
H
A
You,
okay,
so
we're
gonna
have
to
juggle
the
schedule
just
a
little
bit
the
presenter
for
the
multi-home
draft
and
the
signal
data
channel
is
not
available
until
2:15.
So
if
we
could
swap
further
architecture
discussion
with
discussion
about
our
hackathon
report
in
the
interrupts
economic,
would
you
mind
coming
up
and
talking
to
your
slides?
A
So
if
any
of
you've
been
watching
the
mailing
list,
you've
probably
noticed
that
there
is
a
significant
uptick
in
volume
related
to
implementation
reports
and
that
banging
on
this
signal.
Data
draft,
so
I
wanted
to
reiterate
on
behalf
which
you
come
to
Baez,
about
how
fabulous
that
is
so
John.
Thank
you
for
kind
of
coming
with
the
implementation
Konami
and
your
team.
Thank
you
for
hanging
on
your
implementation
as
well
and
driving
that
feedback
to
the
working
group.
It's
really
phenomenal
and
accelerating
our
progress
to
closure.
A
G
G
G
So
what
happen
in
the
hackathon,
so
the
three
active
projects
are
conductive
priori
with
seven
participants
so,
but
it
includes
three
remote
participants
from
Tokyo,
London
and
19
and
they're.
Our
main
project
is,
as
I
see,
integrity,
test
of
the
individual
implementations
and
also
for
people.
Feet
are
added
new
features
and
extensions
to
the
open
source
implementation
and
one
person
tries
to
integrate
it
with
a
detection
system
of
Berea
botnet
X
P.
So
then
we
won
an
award
of
best
open-source
project.
G
So
hot
I'd
like
to
report
about
inter
interrupt
testing,
so
Jon
shallow
from
NCC,
kindly
participated
in
this
hackathon
and
interpreter
testing
remotely
from
other,
even
if
it
was
almost
midnight.
Thank
you,
John
yeah
next,
please.
So
this
is
the
result
of
the
intro
test.
We
tried
to
make
it
green
and
we
managed
to
do
that
by
changing
the
code
during
the
hackathon,
unfortunately,
because
of
lack
of
the
functionality
of
gold
quartz,
which
is
the
opposite
project,
though
it
lacks
the
functionality
of
status,
notify
and
Akashi
update
and
heartbeat.
G
So
we
only
tested
the
rest
of
the
functionality
on
messages
of
the
only
signal
channel
and
in
species
implementation.
We
already
have
all
of
the
functionality
of
these
messages
on
signal
channel,
so
we
tested
Godot
client
against
in
the
series
dot
server
and
also
with
we
tested
in
the
cities,
dot
client
against
co,
dot
server.
G
A
K
G
A
G
So
here's
what
we
proved
it
in
D
it
drops
so
we
now
we
can
start
and
handle
mitigation
from
each
client
of
a
thoughts
to
know
each
other
of
Scott
on
the
TTLs,
by
mutual
request
of
god
third
gate
and
delete,
then
dot
server
of
both
and
can
activate
the
limitation
action
by
the
bottom
service.
So,
as
I
said,
we
tested
both
cry
out
and
functionality,
each
other
plus
in
the
city's
group's
implementation,
can
act
as
adults
gateway.
So
we
proved
that
a
related
mutation
request
can
work
over
multiple
organizations.
G
So,
okay,
the
general
feedback,
2.1
group.
We
had
a
lot
of
implementation
experiences.
For
example,
most
of
the
code
modification
was
related
to
encode
and
decode
of
Shiva
mapping.
So
they
are
here
the
type
of
not
called
Shiva
mapping,
and
there
are
many
implicit
specifications.
We
need
to
figure
out
and
agree
on,
so
we
will
do
feedback
about
the
only
description
of
the
content
of
the
draft
and
also
we
assume
that
approximately
60
percentage
of
the
signature
speak
has
been
proved
to
work,
so
the
rest
will
be
done
at
or
by
the
next
IETF.
G
Okay,
the
feedback
from
my
site
before
the
interruptus
we
prepared
these
things
we
I
under
John,
agreed
on
port
number
and
URI
path.
The
port
number
is
supporting
the
zero
six
version
of
signature.
Doors
on
your
path
is
supporting
the
receiving
dozens
of
the
draft
and
we
fixed
Shiva
mapping,
which
was
pointed
out
by
John,
and
we
updated
at
the
models.
In
order
to
suppose
the
latest
signal
Chara
draft
the
week
updated
codes
during
hackathon,
which
includes
the
meeting
empty
new
entries
in
requests
and
we
fixed
response
body.
G
The
sublet
is
the
most
important
feedback
to
talk
about
Europe
in
order
to
find
the
intended
behavior.
We
need
this
scenario,
which
covers
all
of
the
situation
of
the
request
and
the
response
type
our
Norma
and
error
on
this
behavior.
So
we
thought,
if
she
never
see
the
police
did
our
shared
with
working
group.
So
we
really
welcome
that
and
next
to
slide
include
any
city
groups
feedback
to
those
wacky
rude.
G
Okay,
updated
code
during
hackathon,
Shiro
JSON
mapping
are
fixed
for
new
entries
and
still
removed
new
entries
confusion
and
deleted
new
entries
in
any
response,
and
they
added
support
for
communication
request
with
India's
in
group
food
and
actually
a
dot
client
of
NEC.
She
crushed
our
dot
server
so
that
that
is
problem.
My
implementation
side,
but
in
this
job,
disabled
signal
channel
ask
your
configuration
wicket
and
heartbeat.
So
still,
we
are
intensively
working
on
tasks.
N
G
On
John
is
also
continuing
work,
so,
okay,
he
have,
he
already
have
fixed
some
functional
functionality,
even
after
the
hackathon.
So
the
second
point
was
already
fixed
yesterday.
So
these
questions
from
John
and
I
is
listed
here.
So
first
one
should
new
entry
be
allowed,
should
are
null
the
entry
of
type
object
be
allowed
when
ignition
is
RA
who,
as
I
said,
some
of
the
entries
was
included
in
our
rebates,
so
John
John's
implementation
is
solid
enough
to
accept
such
new
entries.
But
the
question
is:
should
it
be
strict
or
not
about
the
new
entries?
G
G
Okay,
if
the
last
type
is
zero
in
request,
John
set
the
lifetime
of
that
mitigation
request
to
the
default
value
of
the
his
dot
server,
but
it
is
not
explicitly
written
in
the
signature
draft.
So
what
should
happen
when
last
time
he
called
zero
request
is
requested
by
dot
Claire.
It
should
be
described
in
this
draft,
and
the
third
question
is
very
important.
She
was
there
be
support
from
multitude
medication
requests
even
a
single
pill,
so
in
the
e-signature
draft
the
mitigation
request
is
array,
so
it
can
be.
G
The
multiple
mitigation
requests
can
be
is
varied,
but
if
one
of
the
mitigation
Ric
request
in
singer
put
is
corrupted
and
one
is
normal,
so
what
should
be
done
on
these
services?
So
that
is
a
question.
So
what
what
should
be
done
if
the
multiple
mitigation
request
is
in
a
single
pair
but
equation
so
okay,
so
before
moving
to
the
second
part,
we
will
activate
the
questions
and
comments
from
yeah,
rude
I.
A
O
G
Okay,
thank
you
for
question,
told
not
all
of
use
cases
are
covered,
so
it
is
the
first
interoperability
thing,
so
we
just
focusing
on
the
messages
on
the
wire
itself.
So
we
checked
that
we
can
convey
the
information
over
the
signal
child
and
also
we
tested
both
and
can
encode
other
day
because
methods.
Also,
then,
are
we
yeah.
G
G
D
Awesome
actually
like
this
is
really
cool.
I
have
a
question,
so
we
we
test
it
now
like
two
two-and-a-half
implementations
but
I,
remember
from
previous
discussions
that
were
a
number
of
other
parties
who
might
also
consider
implementing
this.
So
are
there
any
people
in
the
room
or
companies
who
would
like
to
join
this
interoperability
test?
Are
there
any
other
implementations
out
there
at
this
moment
that
we
should
test,
or
that
would
like
to
provide
feedback
about
whether
the
specification
was
clear
enough,
because
we
learned
from
the
hackathon
that
there
was
some
improvements
to
be
done?
D
D
D
G
P
Okay,
it's
French
how,
as
goes
down
to
the
I,
just
want
to
say
that
as
economy
has
said
that
in
this
hexam
activity
we
have
several
players
in
this
activity
and
how
he
has
provided
our
implementation.
Our
implementation
is
mainly
based
on
the
current
Dakotas
open-source
project
and
we
added
as
some
tossed
protocol
itself,
features
such
as
a
fickle,
see
up,
update
and
the
stadium,
updated
six
features
and
with
Twitter
internet
Hestia
in
our
company,
but
still
for
some
some.
You
know
some
open
source
policy
in
our
company.
P
We
cannot
bring
code
to
come
here
so
so
that's
why
we
through
our
internal
tester,
and
we
have
some
tests
to
result
in
our
slides,
but
we
I
think
if
anyone
interested
we
can,
we
can
show
anyone
yeah.
So
the
in
addition
to
this
existing
protocol
features.
We
also
want
to
one
thing
that
we
also
are
very
interested
that
weather
toss
protocols
can
be
extended
for
some
renders
pacifica
use,
so
we
we
use.
P
We
use
this
chance
to
to
add
some
more
attributes
to
the
render
specific
attributes
of
the
taught
seminary
messages
and
we
test
two
features.
Why
is
the
recorder?
The
global
IP
reputation
sharing
functions,
so
that
means
that
if
the
test
client
can
analysis,
the
attack
information
and
send
us
this
Center,
the
the
identify
the
attack
source
information
to
the
sower.
So
this
information
can
be
intelligence
share
that
with
the
other
client.
So
we
extended
a
current
because
current
protocol,
we
think
that
is
a
very
minimal
function
set.
So
we
we
try
to.
P
We
try
to
test
a
youthful
if
we
can
be
variable
for
more
functions.
So
that's
one
one
thing,
and
another
thing
is
that
we
think
that
the
us
also
attack
mitigation
is
also
very
important.
So
we
also
use
extending
we
also
test
or
the
another
feature
is
how
to
extending
the
currently
taught
protocols
to
to
the
outbound
or
the
source.
Muscles
attack
mitigation.
I
think
this
this
to
to
extended
a
test
or
past.
P
So
so
maybe
I
think
if
we
finish
you
the
first
third
stage
of
protocol,
we
can
consider
it
to
how,
if
it's
possible,
we
can
do
more
things
based
on
the
current
work.
So
that's
our
main
goal,
but
as
also
the
I
think
the
greatest
achievement
for
what
have
we
that
we
we
have
to
the
physical
protocol
interoperate
it
a
test,
that's
a
greater
and
greater
success
for
this
time.
Yeah!
That's
all!
Ok,.
A
M
Again
for
not
being
able
to
attend
the
decision
from
from
the
beginning,
so
this
is
an
update
of
the
builded
data,
the
signal
channel
and
the
dead
channel.
So
this
will
reflect
the
main,
the
main
changes
and
to
to
show
you
the
mention
that
we
have
done
since
the
last
last
IETF
meetings.
So
next
slide,
please.
M
So,
just
a
reminder
that
there
is
a
github
in
which
we
we
are
maintaining
the
latest
versions
of
the
draft,
so
please
feel
free
to
to
fill
the
request
there
and
to
to
add
any
any
contribution
that
you
would
like
to
see
and
to
write
it
in
the
draft.
The
link
is
provided
in
the
in
this
slide.
Next
slide,
please.
M
This
is
something
that
we
we
have
agreed
I
discussed
last
and
during
the
last
ATF
meeting,
and
after
also,
we
agree
to
to
use
a
distinct
port
number
for
the
dead
signal
channel.
So
we
we
have
a
digital
draft
to
a
2.2,
the
new
request
for
from
a
Jana,
and
also
we
have
a
digital
draft
to
to
to
use
a
will
now
in
your
eyes,
for
four
dots.
So
these
two
updates
are
e
are
now
reflected
in
the
in
the
document.
Next
slide.
Please.
M
M
So
the
value
is
it
to
16
minutes,
and
there
is
no
objection
or
no
other
proposal
to
to
use
a
distinct
value
and
the
the
another
major
modification
which
may
have
some
implication
on
the
privacy
is
the
that
we
all
know
that
aDOT's
gateway
to
insert
the
client
identifier
in
case
that
gateway
is
aggregating,
multiple
clients,
so
that
the
the
dot
server
has
information
about
the
original
clients
that
better
to
be
serviced.
This
information
is
not
systematically
inserted
in
da
Ãndia
request.
There
are
some
situation
in
which
there
is
no
value
to
insert
it.
M
D
I
M
So
the
outcome
to
discussion
is
that
we
clarified
the
tag
that
was
there
in
the
signal
channel,
but
I
have
also
updated
the
requirement
draft
to
a
line
document
so
that
there
is
no
misalignment
between
the
the
protocol
specification
itself
and
the
requirement
that
was
the
origin
of
this
text.
So
now
there
is
this.
M
M
The
rationale
for
this
kind
of
setting
is
documented
in
the
document,
and
we
we
also
encouraged
you
use
of
other
tools
to
discover
the
lifetime
when
there
is
a
presence
of
the
firewall
and
and
and
the
net.
But
we
are
not
recommending
any
any
protocol
for
for
this
kind
of
of
solutions
if
you
want
to
use
a
distinct
value
for
the
the
interval
next
slide.
Please.
M
This
is
this
modification
was
to
reflect.
The
cameras
from
John
is
mainly
to
t
distinguish
between
the
two
phases:
the
first
one.
When
tourism
there
is
no
saturation
in
the
link
and
the
other
one
with
the
RISM
I,
don't
go
in
attack.
So
this
time
we
we
have
these
two
parameters,
the
first
one,
which
is
the
interval
between
st.
India.
They
hurt,
but
per
request
and
the
maximum
number
of
herpe
that
we
can
send
to
that
can
be
exchanged
built
between
the
the
client
and
the
server.
M
It
maintain
a
decision,
even
if
it
does
not
see
any
message
coming
from
the
server,
but
the
server
has
to
if
it
doesn't
see
any
indium
in
the
traffic
or
in
a
message
from
the
dis
client
has
to
decide
that
the
the
client
the
decision
is,
is
closing
after
an
exhaustion,
the
maximum
number
of
hurt
but
sent
to
the
server
next
slide.
Please.
M
An
open
question
that
we
would
like
to
hear
from
the
working
group
is
because
documents
say
that
if
you
receive
multiple
requests
for
the
same
client
and
for
the
same
and
scope
justly
we
we
are,
we
are
deleting
the
lower
the
raucous
with
the
lower
mitigation
mitigation
ad.
We
are
not.
We
are
asking
to
working
with
those
up
if
there's
a
problem
with
this,
with
this
approach
or
or
side
effect
of
this
kind
of
of
decisions,
so
we
would
live
to
two
to
hear
from
you
all
next
slide.
M
Please
yeah,
there's
an
open
question
which
is
currently
which
has
been
raised
by
Abed
jon
is
ready
to
to
manipulate
in
the
the
access
list.
The
first
one
is
to
allow
to
have
multiple
access
lists
for
goods
client
and
the
the
other
one
which
is
ready
to
this.
One
is
how
we
can
order
the
access
list,
projects
client
for
the
second
one.
This
is
something
which
is
currently
not
supported
in
the
base
ECL
draft.
M
So
this
is
something
as
we
can
add
to
to
the
document
and
we
are
still
waiting
from
some
feedback
from
the
working
of
about
the
support
of
the
multiple
issues,
whether
we
can
include
it
directly
into
the
document,
or
we
need
to
discuss
with
the
authors
of
the
debates,
ECL
document.
So
if
there
are
any
feedback
or
comments,
please
feel
free
to
to
share
it
with
us.
A
L
M
Was
a
we
are
using
the
the
recent
one
which
which
was
supposed
to
reflect
the
refresh
situation?
That
means
that's.
The
latest
with
requests
is
supposed
to
to
reflect
the
up
to
date.
Situation
from
the
desk
clients
domain
itself.
That
was
I,
wrote
the
rationale
for
that,
but
we
may.
This
may
have
problems
in
case
there's
multiple
list,
clients
and
each
of
them.
We
have
a
distinct
view
on
the
situation
on
the
on
the
network.
So
that's
why
we
are
raising
the
question
and
we
would
like
to
hear
from
you
and
from
the
others.
F
I
I'm
going
so
one
question
for
clarification,
and
maybe
you
use
the
answer
this,
but
does
this
apply
between
requests
from
different
dots
clients?
Potentially,
this
is
not
just
on
a
per
dots
client
basis.
It's
it's
supported
in
domain,
not
for
that's
client,
business
yeah
that
then
and
I
guess.
I
am
concerned.
Yeah.
M
I
D
H
I
H
D
You
said
like
several
pages
before,
where
you
specify
the
mitigation
lifetime
default
value
to
be
sixty
minutes,
I'm
actually
wondering
do
we
even
need
to
specify
that,
or
should
we
maybe
better,
not
specify
that
in
the
draft,
because,
like
denial
of
service
attack,
scenarios
are
evolving
quite
quickly
and
there
may
be
choices
by
vendors
to
be
made
about
different
mitigation
default
lifetimes.
So
maybe
we
shouldn't
set
one,
especially
also
in
the
context
of
if
you
set
it
to
zero,
then
it
means
default
lifetime.
So
so
like
there
are
questions
like
why.
A
M
Yeah,
okay,
so
yeah
just
transfer
the
last.
The
last
question
about
the
you
recommended
value.
This
is
just
a
recommended
values,
so
implementers
can
use
other
values
if
the
if
it
is
appropriate
and
also
the
do
provider
for
operators
who
are
using
the
dot
servers
and
also
the
error,
correcting
codes,
clients
or
managing
the
dots
clients
can
set
it
to
a
district
value.
We
are
just
recommending
that
value
so
that
we
there
is.
M
There
is
some
some
guidance
for
for
the
implementers
to,
because
if
you
process
you
city
to
a
lower
value,
you
will,
you
may
have
some
other
side
effects
that
the
the
mitigation
request
is
not
maintained
as
long
as
required
to
further
this
kind
and
so
on.
So
this
is
something
that
we
have
asked
to
the
list
and
there
is
no
objective
so
far
for
this
value.
So
if
you
think
that
there
is
there's
a
problem,
please
you
raise
the
question
in
the
malleus
so
that
we
kind
of
discuss
it
with
there.
N
N
D
D
Okay,
so
thank
you,
the
yeah.
This
is
to
be
asked
on
room
huawei,
non
working
group
chair.
Just
one
clarification,
I
didn't
want
to
say
to
remove
like
I
think
the
60
minute
makes
sense,
just
the
like.
If
you
say
this
is
a
recommended,
that's
fine,
declaring
it
as
a
default
value
in
a
specification,
then
that
would
suggest
something
like
you
should
use
that
value
and
that's
where
I
was
concerned,
I'm
fully
with
you
to
say:
we
recommend
this
value
and
that's
okay.
M
Yeah
the
next
slide.
This
is
something
which
is
open
and
is
there
since
the
many
ATF
meetings
I
would
like
to
know
what
to
do
with
the
material
authentication.
Should
we
and
should,
should
we
recommend
and
a
solution
so
that
the
Dutch
client
at
the
Dutch
server
can
mutually
authenticate
themselves?
There
are
various
options
there
that
we
are
listed
in
the
in
the
in
the
in
this
slide
and
also
the
next
one,
and
we
would
like
to
know
what
you
do
with
those
should.
M
We
assume
a
particular
solution
to
be
to
be
specified
or
we
we
can
leave
a
t2
to
the
implementers
so
that
you
can
decide
which
what
is
the
better
option
for
them
to
do
to
achieve
the
material
integration
between
the
dot
server
and
the
dis
client,
knowing
that
there
may
be
some
interpretive
problems,
if
we
leave
it
open,
so
I
won't
go
into
all
the
options
we
have.
We
have
so
far,
so
the
most
important
for
us
is
to
know
what
the
world
working
group
want
us
to
do
with
regard
to
this.
M
That
that's
what
the
question
is.
The
question
is
not
whether
we
want
or
we
don't
want,
the
visualized
indication
is
how
we
will
achieve
the
authentication
materials.
Interrogation
is
a
mass
for
the
protocol,
and
this
is
something
that
is
clearly
called
out
in
the
requirement
document,
and
we
would
like
to
adhere
to
that
to
that
requirement.
This
is
really
important
that
there
is
that's
should
we
should
be
supported
by
those
clients,
and
the
question
is
how
we
will
achieve
that
and
for
us,
and
especially
about
the
the
provisioning
problem
without
the
certificates
and
so
on.
K
M
Know
that
that's
not
that's,
not
the
point
it
this
that
is
trying
to
to
reflect.
The
point
is
that
this
is
one
candidate
that
will
that
that
we
are,
we
are
seeing
there
if
you
want
to
do
something
which
is
automatic
about
the
enrolment
and
so
on
this
kind
of
stuff,
but
if
there
are
other
the
other
alternates
or
other
solutions
to
do
that,
so
please
feel
free
to
share
it
with
us
and
the
that's.
M
That's
one
point
the
other
one
is
whether
we
should
specify
a
mandatory
to
support
option
in
into
the
document,
and
we
are.
We
are
open
to
that
and
we
would
like
to
hear
from
the
working
group.
How
should
we
talk
about
this
in
the
in
the
document?
This
is
this,
is
this
is
our
main
concern
not
and
not
the
the
dissolutions
themselves,
but
how
to
do
that
and
how
to
proceed
with
this
kind
of
in
editorial
aspect,
to
reflect
what
we
at
this
client
at?
M
What
at
the
server
Massey
support
with
regard
to
be
to
the
applications
and
how
the
the
required
security
credential
our
provision
to
reduce
client
and
for
to
the
servers
that
we
can
achieve.
Demeter
authentication,
which
is
imposed
and
required,
and
we
would
like
to
see
it
supported
by
the
protocols.
K
I'll,
look
at
the
text
again
see
if
I
come
some
wording
to
make
it
that
est
is
a
a
recommended
way
and
there
are
others.
You
know
one
others
work
being
done.
An
animal
brueski
might
evolve
as
another
potential
method
for
the
certificates.
There's
a
lot
of
T
V
DS
there,
but
est
can
well
be
called
out
as
a
no
here's,
something
which
works
or
can
be
made
to
work
and
to
be
use
accordingly.
So
let
me
again
look
at
your
text.
There
yeah.
M
K
I
K
Mascots
Fleming
excellent
question,
and
this
is
the
server-side
answer
authoring.
The
server
client
can
choose
which
poison
works
best
for
it,
because
definitely
the
whole
thing
about
raw
public
keys.
There
are
clients
which
can't
do
anything,
but
that
kind
of
a
solution.
So
this
is
server
mom
shut
up.
No
must
do
all
three
clients
select
one.
D
M
M
Yeah,
so
we
have,
we
have
already
a
section
in
the
end,
in
the
protocol
specification
document
that
documents
the
the
current
go.
That's
implementation!
Yes,
so
we
are
following
that
yeah,
but
I
I
need
to
to
read
and
to
refresh
my
mind
about
the
latest
issue
that
was
found
during
the
hackathon,
so
that
we
can
align
the
specification
and
decide
if
there
is
any
fix
that
need
to
be
added
to
the
specification
documents.
Yeah.
D
M
M
This
is
this
is
the
homework
ahead
from
from
Prague
is
due
to
check
how
we
can
cover
the
discussion
about
the
mr.
Hammond
in
the
existing
documents,
so
mainly
to
check
with
order.
There
are
modifications
that
are
required
to
build
the
the
requirement
and
also
the
architecture
document
next
slide.
Please
so
I
started
with
the
the
dots
requirement.
M
So
there
is
a
some
discussion
on
the
mailing
list
and
also
I
have
proposed
text
to
a
to
Andrew
to
for
to
cover
which
to
cover
for
me
what
what
AAC
has
the
main
requirements
there
is
that
the
the
clients
must
be
able
to
comment
in
multiple
sessions
and
to
to
appropriately
select
the
appropriate
server
when
you
have
two
to
two
plus
a
request.
So
this
is
this
requirement.
Text
is
really
brief
at
concise.
We
don't
want
to
go
into
specificity
of
the
mr.
Hartmann
to
not
overload
the
the
dots
requirement
document
itself
so
decide.
M
M
The
next
document
is
the
dots
architecture
for
this
one.
Yes,
there
are
some
discussion
about
the
mr.
Holman,
but
the
discussion
is
really
at
a
high
level,
which
is
which
I
see
as
a
good
points,
and
even
the
documents
mentioned
that
there
are
some
extra
care
and
planning
to
be
done
by
the
dots
clients
in
mr.
Herman
situation.
M
So
the
the
card
disk
text
and
the
current
discussion
that
we
have
in
the
the
individual
document
we
described
meant
a
human,
is
really
something
which
is
zooming
on
this
part,
so
that
to
to
provide
some
guidance
to
implementers
and
to
to
operate
or
how
he
can
operate
the
the
its
clients
in
multihoming
situations.
So
this
are
from
your
complimentary
discussions.
Do
you
count
one
which
is
which
I
see
as
a
sufficient
for
a
an
architectural
document
which
is
already
there
and
do
the
other
one
which
is
in
the
in
the
individual
document?
Next
slide?
M
Please
for
the
dots
signal
and
the
that's
channel
specification
protocols.
This
is
clear:
there
is
no
requirements
on
the
on
the
on
the
protocols
themselves.
There
is
no
modifications
that
we
are
required
to
do
to
the
protocols
themselves,
so
we
are
just
using
the
that's
signal
and
data
channels
as
they
are,
but
it's
the
problem
is
mainly
on
the
behavior
on
the
desk
ages
themselves
and
not
the
protocols
we
are
using
to
establish
the
communication
and
to
place
the
request
by
the
dursa
client
to
a
remote
that
server.
M
M
So
here
we
are
so
there
are
some
modification
that
have
been
proposed
to
the
requirement
document.
There
is
something
which
is
still
missing
to
address
the
practicalities
and
all
the
the
issues
that
are
related
to
a
rational
aspect
of
the
mr.
Harmon.
So
there
are
two
approaches
there.
The
first
one
is
to
go
with
updating
the
architecture,
the
current
architecture
document-
and
there
is
already
a
proposal
to
in
that
in
the
direction
to
add
the
mr.
M
Harmon
discussion,
not
in
the
core
part
of
the
document,
but
but
as
an
appendix,
so
that
we
can
provide
some
operational
guidance
and
the
to
to
implementers
or
the
other
one,
which
is
to
consider
a
subsidy,
the
current
individual
document
as
a
standalone
document,
so
that
you
can
have
one
single
document
in
which
we
we
are
discussing
all
the
specificity
of
the
of
the
mr.
Harmon.
So
I
do
personally
prefer
the
second
plant,
which
is
because
this
is
really
focused
but
I'm
open
to
to
any
direction
from
the
working
group.
We
have
built.
H
We
have
considerable
operational
experience
with
protocols
that
are
similar
to
what
dots
are
going
to
do
and
we
don't
run
into
any
you
know,
glitches
or
gotchas
related
to
multihoming
I
think
the
care
path
that
was
on
slide
3
is
good,
and
it's
something
that
we
should.
You
know
consider
in
yeah
this
paragraph
right
here,
but
this
is
only
all
that
we
need
to
be
said.
We
don't
need
to
get
into
the
all
the
detail.
That's
in
this
particular
proposed
graph
because
it
was
more
or
less
tcp/ip,
101
and
I.
H
I
Fleming
underrated,
please
rejoin
the
queue.
Speaking
as
one
of
the
authors
of
the
architecture,
draft
I
would
say:
I'm
not
in
favor
of
adding
this
as
an
appendix
I
think
we
have
per
the
previous
discussion
on
the
architecture.
Draft
I
think
we
have
sufficient
treatment
of
multihoming
in
the
architecture
draft
itself,
so
yeah
I
would
I
would
not
vote
for
option
one.
There.
D
I
D
A
D
Sorry
one
more
one
more
question:
for
me:
I
mean
we
had
this
discussion.
Indeed
at
ITF
99
and
at
least
at
that
point
in
time,
I
had
the
impression
we
did
not
have
enough
information
for
multihoming,
so
I
just
hear
now.
There's
sufficient
information,
the
architecture
draft,
as
is
so
has
just
been
improved.
Has
this
used
some
of
that
component
or
like
it's
the
statement
like?
Actually,
we
were
wrong
at
99
and
like
it
was
already
good
enough.
D
I
Fleming
Andreasen
again
speaking
as
one
of
the
authors,
at
least
at
the
architecture
draft,
when
we
did
the
intern
review
of
the
architecture
draft,
not
specifically
a
multihoming
in
there,
I
felt
that
the
treatment
that
we
had
in
there
was
sufficient
I
looked
at
the
multihoming
draft
as
well,
I'm,
not
sure
if
it
was
updated
subsequently,
but
but
I
didn't
see
things
that
I
thought
were
necessary
for
the
architecture
draft
itself
at
least
I
names.
A
question
of
I
mean
how
many
of
these
deployment
consideration
documents
do
we
want?
I
Should
we
focus
our
energy
more
on
the
protocols
at
this
point?
Maybe
this
is
something
that
we
defer
a
decision
on,
and
you
know
we
can
see
if
there
are
impacts
on
some
of
the
protocol.
Shafts
I
think
Matt
has
indicated
that
so
far
at
least
he
hasn't
seen
an
impact
on
the
protocol
drafts,
so
I
I
don't
know
how
much
of
a
need
there
is,
but
but
I
would
prefer
to
see
the
group
investing
energy
again
in
the
protocol
drafts.
At
this
point
and.
H
Moving
on
to
Roland
yeah
I
want
a
second,
our
Criminal
Code
and
the
question
about
what
we
were
thinking
at
IETF
nt9.
We
really
have
all
the
iterations
that
we
need
already
this
paragraph
here.
This
last
slide,
3,
suffice
is,
and
I
really
don't
think
that
lead
to
spend
a
lot
of
time
than
original
movie
chord.
D
A
Yeah
one
thing
that
perhaps
my
my
help
kind
of
clarify
things
I
think
we're
talking
we're
tossing
around
different
terms
here,
got
it
so
slide.
Six
speaks
to
how
this
draft
is
going
to
complement
the
dots
architecture,
but
we're
also
talking
about
deployment
considerations.
So
are
those
the
same
thing.
M
E
M
Are
two
distinct
levels
of
the
of
the
same
problem?
That
is
that,
once
you
have
the
protocols
and
what
you
you
have
the
your
agents
there.
There
are
some
another
dimension
in
which
that
which
is
really
key
for
the
operation
of
your
mitigation
problem.
Is
that
how
your
data
client
is
talking
with
the
to
the
appropriate
server?
And
how
do
those
clients
are
sending
the
appropriate
information
to
the
appropriate
servers?
And
all
these
kind
of
information
is
they
are?
They
are
not
currently
specifically
specified
in
the
architecture.
M
For
instance,
if
you
have
just
a
simple
multi
hung
situation:
if
you
are
talking
to
the
wrong
good
server,
your
the
problem
won't
be
solved,
so
there
are
some
and
other
considerations
that
need
to
be
documented
somewhere.
Perhaps
for
some
this
is
obvious,
but
they
don't
take
so
because
there
are
many
problems
and
merely
considerations
there.
That
should
to
be
documented.
Clearly,
I
do
think
that
there
is
something
which
is
missing.
This.
I
H
Yeah
I
disagree:
I
I
just
this
is
such
a
basic
issue
that
I
think
there's
a
lot
of
heat
and
why
around
us
that
that
that
III
don't
understand
why
this
is
considered
to
be
such
a
complex
issue
that
requires
you
know
specific
documentation
beyond
the
paragraph
on
slide.
Three
I
just
don't
understand
it.
I
haven't
heard
the
case
made
specifically
here:
I,
don't
I,
I
read
the
document
and
it
just
doesn't
make
sense
to
me
cuz
I'm,
sorry,
maybe
just
my
failure
to
comprehend.
I
Fleming
Fleming,
there's
no
I
mean
I
agree
with
Matt
that
it
goes
beyond
deployment
consideration
right.
There
is
an
implementation
aspect
to
it
as
well,
but
I
think
that's
it
right,
I
mean
again.
I,
don't
see.
Protocol
impacts
right
here
right
now
and
and
again,
I
would
prefer
that
we
focus
our
energy
on.
D
So
in
Rome,
while
we
were
king
of
jihad
off,
if
it
has
no
impact
on
the
protocol
specification,
then
I
think
we
really
need
to
think
carefully
where
to
put
like
whether
this
is
like
what
what
is
the
impact
of
this
I
have
seen
in
other
working
groups,
discussions
about
deployment
advisory,
something
like
that,
but
then
I
would
question
whether
why
this
is
like.
If
we,
if
you
would
go
down
this
way,
then
the
question
would
be.
H
Roland
Europe
by
Roland
ovens
over
networks,
since
med
is
intending
this
more
I
think
in
the
flavor
of
deployment
guidance
we
would
be.
It
would
be
very
easy
for
us
to
add
this
to
one
of
the
these
considerations
that
he's
thinking
about
in
one
of
the
existing
news
cases
that
has
a
multihomed
type
of
scenario.
We
could
simply
work
with
med
to
get
some
verbiage
from
him
to
stick
into
the
use
cases
drafter.
That
would
help.
D
If
I
may
waha,
why
jump
into
the
queue
I
do
not
think
we
should
add
this
to
the
use
cases.
Draft
I
mean
if
this
is
later
about
advice
for
the
deployment.
I
really
think
we
should
get
the
whose
case
is
draft
through
the
door
and
into
working
group
last
call,
and
if
we
need
to
provide
later
some
guidance
on
deployment,
then
this
shouldn't
be
in
the
use
cases
draft
my
personal
opinion.
M
Actually
there
there
are
two
two
aspects
in
the
meta:
Harmon
specification,
individual
document.
There
are
already
a
discussion
on
the
use
cases
themselves
and
the
discussion
about
the
deployment
considerations.
I
would
personally
agree
with
the
with
Roland
that
there
is
already
one
section
in
the
u.s.
case.
The
working
group
adopted
use
cases
document
which
is
described
in
one
Milty
home
in
the
use
case,
but
this
one
is
yeah.
M
One
option
is
that
we
can
complete
this
dis
section
with
with
with
materials
coming
from
the
the
individual
document
and
to
leave
the
considerations
out
in
out
from
the
US
case.
This
is
this
is
one
option
Roland
and
I
am,
as
far
as
we
are
documenting
the
the
problem
and
as
far
as
we
are
documenting
the,
what
is
the
deployment
that
are
likely
to
happen
as
a
use
case?
It
is
fine
by
me.
D
Okay,
maybe,
as
a
working
group
chair
I,
think
we
don't
have
many
people
who
read
the
draft.
In
fact,
we
have
only
very
few
so
I'm
I,
don't
dare
to
ask
for
anything
consensus
oriented
in
this
direction
at
this
moment.
My
proposal
would
be
to
put
this
back
to
the
mailing
list
to
discuss
there.
If
you
see
a
strong
need
to
also
raise
gaps,
if
you
see
them
in
the
architecture
draft,
so
we
had
the
comment
that
from
the
authors
of
the
architecture
draft
that
actually
they
feel
it's
sufficient.
D
A
A
M
C
A
M
So
the
this
presentation
would
just
summarize
what
had
happened
since
the
last
eight,
if
anything
about
the
the
server
discovery
point
that
we
discussed
in
the
in
the
Prague
meeting
and
also
in
the
ending
maladies.
So
next
slide
please.
So
this
is
just
hear
the
story
about
the
motivation
for
this
document.
Why
we
need
to
have
a
solution
to
to
discover
the
and
to
provision
the
the
dot
servers
to
to
these
clients
currently
build
your
requirement
and
the
protocol
specification
and
also
the
architecture.
M
The
comments
say
that
the
there
are
some
magic
way
that
can
be
manual
or
dynamic
so
that
the
the
dead
servers
are
horizontal
to
this
clients.
So
we
are
just
here
in
this
document
we
are
providing
some
dynamic
means
to
discover
or
the
this
information
so
that
the
there
will
be
communication
between
those
agents
themselves.
Next
slide,
please.
M
So
in
the
during
the
last
ATF
meeting
there
will
there
was
one
command.
I
say
that
we
we
have
much
more
options
there
in
the
document
and
we
would
like
to
shorten
that
that
deftly.
So
what
we
did
is
that
we
read
back
to
to
the
mailing
list
and
we
asked
people
if
the
if
there
are,
if
they
have
opinions,
how
to
shorten
that
list,
and
if
the
there
are
some
options
that
we
can,
we
can
remove
from
the
draft.
M
But
what
happened
is
that
the
the
discussions
confirmed
the
current
day
approach
in
the
draft,
and
that
is
that
when
single-disc
Arabic,
it
is
unlikely
because
of
the
the
heterogeneous
aspect
of
the
various
dots
clients
that
may
be
may
be
solicited.
So
there
is
a
people
ask
in
even
asking
for
more
solutions
to
to
be
a
to
be
a
to
be
at
least
first.
M
There
was
the
discussion
about,
add
Indian,
a
discovery
solution
using
the
Roughriders
Desmond,
which
is
something
which
is
broken,
so
we
just
abandon
to
to
add
it
to
the
list,
and
you
maintain
DD
current
history.
We
have
so
far
in
the
document,
but
there
is
one
key
command
that
was
raised
by
a
brass
which,
which
is
for
me
a
fair
comment.
Are
the
important
to
discuss
by
the
working
group?
Is
that
we
need
to
cover
both
devices
with
numerous
allusions
capabilities
and
devices
that
are
not
that
are
able
to
solicit
an
underlying
name
resolution
library?
M
So
the
outcome
of
the
discussion
we
have
and
the
commands
the
detailed
comments
from
Russia's
that
we
we
have
listed
the
documents
so
that
he
now
a
dude's
client
may
be
provisioned
with
a
list
of
IP
addresses
and
a
list
of
IP
addresses,
together
with
our
reference
into
the
fire
that
can
be
used
for
authentication
purposes
or
it
can
configure
with
with
with
with
a
name
the
name.
When
the
name
is
provisioned
to
this
client,
the
name
will
be
used
for
two
purposes.
M
The
first
one
is
g2
to
resolve
it
into
a
list
of
IP
addresses
that
will
be
used
to
to
reach
the
server
itself,
but
it
will
be
also
used
as
an
authentication
reference
identifier
for
applique
X,
for
instance,
of
the
authentications,
but
when
there
is
a
both/and
name
and
an
IP
addresses,
the
name
will
be
all
only
used
for
authentication
purposes
and
the
IP
addresses
for
reaching
the
the
server
itself.
But
when
there
is
only
an
IP
address
which
which
is
configured
to
to
to
this
client,
we
have.
M
This
open
question
is
with
all
the
certificates
that
are
based
on
the
the
the
sole
IP
address
itself.
So
if
we
go
back
to
our
361
to
2025,
it
told
us
that
there
is,
there
are
very
few
certificates
to
authorities
that
are
issuing
certificates,
both
based
on
IP
address.
So
this
was
the
main
motivation
why
we
discarded
to
include
the
IP
addresses
in
the
first
version
of
the
specification.
But
the
argument
for
for
us
is
that,
if
someone
wants
to
deploy
that
using
the
IP
address
as
a
an
entry
fortification,
it
can
do
so.
M
So
we
don't
need
to.
There
is
no.
He
don't
think
that
there
is
a
valid
arguments
that
we
we
can
forbid
this
kind
of
deployment
option.
So
that's
why
we
added
up
to
212
low
and
this
multiple
option
that
that
is
that
you
can
provision
IP
addresses
you
can
provision
names
and
you
can
provision
our
refers
identifier
to
get
work
with
our
with
a
list
of
IP
addresses
next
slide,
please.
M
So
this
this
is
the
updated
behavior
of
the
of
the
the
discovery
solution
so
that
there
are
so
far
the
four
alternate
solutions
to
to
discover
the
the
servers.
So
you
have
the
the
explicit
configuration
that
can
be
local
or
can
be
automatic
using
DHCP
and
so
on.
We
have
the
service
resolution,
we
have
the
SD
and
we
have
the
unicast
and
the
the
the
context
and
the
as
per
the
outcome.
M
The
discussion
we
had
on
the
manual
I
see
that
at
least
the
dots
client
must
at
least
support
one
of
this
of
the
of
this
of
these
mechanisms,
and
we
we
also
add
this
the
this
world
in
to
say
that
it
should
support
all
all
of
them,
and
we
also
indicated
forum
for
determinism
perspective
that
there
there
will
be
an
order
preference.
So
if
a
dude's
client
is
supporting
many
of
this
of
this
of
this
mechanism,
it
has
to
follow
the
the
professional
order
which
is
which
is
indicated
in
the
document.
M
So
this
is
the
decay
contribution
from
from
from
the
document,
which
is
basically
the
before
mechanism,
as
we
have
we
have
in
the
previous
version,
but
we
just
added
a
further
clarifications
about
the
nature
of
the
information
that
can
be
provisioned
with
this
can
be
an
IP
address,
a
name
or
a
combination
order
of
yes
Tobias
as
we
met
there.
You
can
see
yes.
D
Wonderful,
just
just
a
quick
comment
to
be
asked
on
Rome:
are
we
working?
Ok,
how
head
off?
I
I
roughly
agree
with
the
language
terminology.
I
think
you
should
you
should
use,
should
in
non-capital
terms
not
RC
2119,
because
otherwise
you
would
have
to
explain.
I
think
it
would
be
too
strong
if
you,
if
you
use
it
in
2119
terms,
so
my
recommendation
were
to
do
the
shoot
in
small.
I
Salami
Andreas,
whenever
I
see
four
different
choices
and
the
aim
is
to
have
interoperable
implementations.
Ie
start
scratching.
My
head
I
get
the
fact
that
there
is
at
least
two
different
scenarios
that
we're
trying
to
cover
right,
one
of
which
is
going
through
a
gateway
and
the
other
one
is
going
direct
I,
don't
see
why
we
need
four
different
options.
For
that,
though,.
M
Q
I
Let
me
enjoy
yes,
I
mean
maybe
the
service
discovery.
Authors
aren't
in
a
better
position
to
answer
that
I'm,
not
sure,
because
again
they
are
two
to
two
different
scenarios.
The
thing
that
they're
trying
to
cover
I
think
we
have
to
look
more
closely
at
that.
But
as
a
starting
point
here
probably
then
you
can
say
maybe
not
every
single
scenario
supported
right
in
basic
mandatory
to
implement.
D
M
H
Sorry,
Roland
heavens
Arbor
networks
I
want
to
point
out
a
couple
of
things
that
we
anticipate
that
the
majority
of
dice
implementations
for
quite
some
time
are
going
to
be
basically
point
one
explicit
configuration
done
either
manually
or
via
some
local
automatic
configuration
mechanism,
service
discovery
and
all
this
stuff
is
really
nice,
but
I
think
we're
really
getting
ahead
of
ourselves
and
I
also
want
to
point
out
that
we're
that
anything
it
relies
on
DNS
under
the
asset
pack.
Conditions
is
unwise.
D
M
H
Actually
end
up
at
in
many
cases
where
those
who
wish
to
have
DDoS
mitigation
services
are
not
pre-positioned,
and
so
they
call
screaming
at
or
am
you
know,
on
a
Sunday
saying,
help
help
I
need.
You
know
DDoS
mitigation
services,
and
you
know
you
want
to
be
able
to
use
dots
if
you
can,
and
so
that's
what
I'm
trying
to
say
that
we
we
want
to
make
sure
that
certainly
point
one
subheading,
one
and
two
are
supported.
H
The
service
discovery
stuff
again,
I
just
really
think
we're
getting
ahead
of
ourselves
here
in
and
that
we
want
to
make
sure
that
it's
well
understood
by
implementers
and
by
operators
that
that
reliance
upon
DNS.
You
know
when
attack
indifference,
we're
taking
place
can't
be
taken
for
granted.
That's
all
I'm
trying
to
get
at.
M
I
think
this
is
this
is
a
comment
from
from
from
Roland
I
understand
that
he,
the
the
reliance
on
DNS
may
be
problematic,
but,
as
mentioned
by
Tobias,
the
the
discovery
is
happening
during
this
time
and
not
during
your
attacks.
But
anyway
we
disagree
that
the
discussion
that
I
would
like
to
to
have
together
or
to
continue
so
that
we
can
shorten
the
list,
which
is
really
a
key
for
our
interoperability.
A
H
D
D
I
A
B
D
B
D
A
A
D
We
have
yayyyyy,
we
have
the
first
implementation
with
code
ox,
which
is
really
really
great,
but
what's
bothering
me
is
that
I
don't
see
many
commercial
implementations
and
it's
like
kind
of
like?
Why
is
that
I
don't
fully
get
this
like
by
now,
actually,
like
commercial
implementers
should
have
caught
up
with
the
flow
and
like
at
the
beginning
we
had
at
the
beginning
when
this
working
group
was
founded.
We
had
this
talking
eye.
This
is
really
important.
We
need
to
do
this.
This
is
so
important,
but
then
yeah,
we
I,
don't
see
these
implementations
happening.
D
Q
D
H
Thing
that
I
just
noticed
in
general
is
that
vendors,
often
like
looking
back
until
standards
were
adopted.
They
themselves
invest
the
time
to
do
a
shin
and
obviously
the
implementations
that
have
been
done
so
far
very
helpfully
a
lot
of
useful
information.
That
is
that
we
take
in
as
input
into
the
architecture
in
the
protocols
grass,
and
we
want
to
see
more,
but
I
think
that
that's
one
reason,
internally
speaking,
is
that
vendors
are
often
hesitant
to
to
do
pre
standard
implementations.
I,
don't
know
what
that
is.
It's
just
a
guess.
H
Lot
of
vendors
unfortunately
like
to
hang
back
until
standards
or
are
actually
standardized,
and
so
I
think
that
that's
part
of
the
problem
here
is
that
we're
in
a
situation
where
you
know
we
still
aren't
finished
yet.
We've
gotten
some
great
feedback
from
the
lessons
learned
from
the
implementations,
we've
seen
so
far,
but
I
think
a
lot
of
vendors
just
like
to
kind
of
sit
on
their
hands
and
wait
until
something
has
been
standardized
before
they.
They
they
actually
the
minute,
maybe
I'm
wrong.
It's
just
against
okay,.
H
Q
A
Q
Well,
just
a
RFI.
So
what
pajas
this
point?
There
are
many
other
working
groups
where
they
don't
wait
like
TLS,
for
instance,
they
they've
been
hammering
at
code
and
security
design
problems
for
a
long
time
and
it's
held
up
publication
as
a
result,
but
that's
a
good
thing
because
they're
correcting
problems
found
and
so
that
that
life
cycle
is
so
helpful.
So.
D
Tobias
gone
wrong,
Huawei
non-working
room,
chair
comment,
so
don't
get
me
wrong
at
least
for
for
my
company.
We
intend
to
implement
this
and
you've
seen
that
like
Frank
joined
this
in
the
hanging
on
I
just
feel
like
a
little
bit.
Lonely
like
with
entity
and
NCC
and
then
voila
is
like
I
didn't
expect
us
to
be
among
the
first
adopters
I
rather
expected.
There's
like
all
these
other
vendors
who
are
so
eager
and
that
maybe
we
would
be
slower.
D
So
if
there
may
be
to
your
point
rollin
if
there
is
like,
in
your
mind
a
list
of
vendors
who
are
maybe
not
aware
of
this
or
if
you
have
some
suggestions
like
the
Roman
and
me,
we
can
also
go
to
them.
As
the
chair
and
like
say,
hey,
are
you
aware
of
this?
Are
you
interested?
Can
we
help
you
in
any
way,
because
I'm
just
confused
at
the
moment?
Why
why
it's
not
so
many?
I.
H
Well,
we
have.
We
have
some
good
under
representation
in
the
working
group.
I
can't
answer
for
why
we
aren't
seeing
more
implementations
from
the
vendors
who
are
actually
participating
in
the
working
group
I'm,
not
in
a
position
to
answer
that
question.
I.
Think
a
lot
of
the
main
vendors
who
need
to
know
about
this
of
our
engagement
aware,
there's
always
room
for
more,
but
you
know.
If
we
look
at
the
vendors
that
are
involved,
we
have
a
pretty
pretty
strong
roster,
so
I
don't
know
think
that
awareness
is
necessarily
the
problem.
D
Good,
so
then,
let
me
just
resume
that
one
little
piece
if
you
are
aware
of
people
who
you
think
should
be
interested
in
this-
and
maybe
they
are
not
aware
of
this-
please
feel
free
to
come
to
Roman
myself
anytime.
We
can
like
help
how
we
can
bring
them
in
or
or
like
share
information
and
so
on,
because
I
think
now
we
are
really
getting
into
the
face
where
this
needs
to
be
like
code
on
the
on
the
road
and
with
this
I
hand
back
to
Roman
for
I,
think
some
closing
comments.
Q
A
A
A
I
D
To
you,
maybe
one
comment
as
a
person
comment
from
a
cheer
perspective.
I
could
imagine
us
pull
the
trigger
on
working
group
last
call,
even
if
a
document
is
only
in
let's
say
close
to,
but
not
fully
finished
yet
state,
and
that
may
be
something
for
you
the
ad
to
to
raise
your
hand
and
say
don't
do
that,
but
I
actually
see
us
doing
that.
So
we
can
wrap
this
up
faster,
like
not
wait
for
until
it's
completely
finished
and
I
see
you
nodding
so
I
take
that
okay,
we
pull
B.
D
Q
So
once
you
go
through
working
group
last
call
whoever
shepherding
it
will
assess
the
state
of
debates
and
then,
when
I
do
my
review
after
that,
I
will
look
for
glaring
issues
that
might
get
picked
up
in
the
iesg
to
avoid
than
having
it
picked
up
that
late,
so
yeah.
So
if
you
find
anything
full
addressed
and.