►
From YouTube: IETF99-DOTS-20170720-1550
Description
DOTS meeting session at IETF99
2017/07/20 1550
https://datatracker.ietf.org/meeting/99/proceedings/
A
Good
afternoon,
everyone
wait
hot
afternoon
everyone.
This
is
dots.
Hopefully
that's
what
you're
here,
for
my
name
is
Roman
Danilo
and
I'm.
Here
with
my
co-chair
Tobias
gunroom
and
we'd
like
to
get
started
so
getting
handed
out
right
now.
Is
the
blue
sheets.
You've
likely
seen
this
a
number
of
times,
since
this
is
Thursday
of
the
week,
but
the
noel
has
been
updated
thanks.
We
already
have
jabber
scribe
and
a
note-taker
and
again
the
blue
sheets
are
going
around.
A
We
have
a
fairly
fairly
full
agenda,
but
we
have
a
buffer,
a
buffer
in
all
the
areas
to
have
the
conversations
to
include
the
drafts
and
the
hackathon
experience.
We
have
an
agenda
split
between
the
use
cases,
requirements
and
architecture
and
then
a
collection
of
various
protocol
drafts
before
moving
forward.
Would
anyone
like
to
bash
this
agenda?
A
A
Today
we
had
a
virtual
interim
meeting
that
check
tweeted
us
halfway
halfway
between
Chicago
and
now
in
June,
which
laid
out
which
laid
out
where
we
need
you
to
head,
and
then
there
were
two
individual
design
team
meetings
on
Tuesday
and
Wednesday
to
talk
about
specific
draft
areas.
Specifically,
the
informational
documents
was
on
Tuesday
and
then
on
Wednesday.
There
was
discussion
about
protocols
and
I
believe
that
the
various
presentations
will
will
cover
some
of
those
specifics
related
to
that
I
just
wanted
to
highlight
where
we
stand
in
terms
of
kind
of
scheduling.
B
C
Okay,
hi
everyone,
I'm
Roland
Evans
with
urban
networks,
and
so
we
just
got
0
7
out
about
5
5
hours
ago.
If
you
remember
at
the
interim
meeting
a
little
while
back,
we
talked
about
0
6,
0
6.
We
revamped
a
lot
of
the
use
cases
we
actually
added
nine
new
use
cases
and,
unfortunately,
due
to
emerge
our
on
my
part.
We
lost
some
of
the
some
of
the
revisions
that
had
taken
place
between
4
&
5,
so
first
of
all,
on
0
7
fixes
those
inadvertent
revisions
and
think
so
hamid
for
pointing
that
out.
C
C
So
now
we're
trying
to
track
0-8
si
welc
candidate
when
we
revamp
the
use
cases
we
put
in
a
lot
of
good
operational
contacts,
but
not
enough
dots
contacts
if
you've
been
with
us
for
a
while.
You
take
a
look
at
like
0
0
in
0
1.
We
were
very,
very
dodged
heavy
in
terms
of
talking
about
the
messaging
flow
between
dots
clients
and
dot
server.
C
It
was
a
little
bit
too
much
without
enough
context,
and
so
we've
added
some
good
use
cases
in
there,
but
we've
gotten
some
good
feedback
from
some
of
the
the
contributors
for
the
document
that
we've
gone
to
light
on
the
actual
dots
interaction.
So
we
need
to
add
those
a
little
bit
more
dots
flavor
to
the
actual
use
cases,
show
some
grammatical
and
terminological
things
that
we
need
to
take
care
of
we'd
work
on
some
of
the,
so
the
orchestration
section
is
good
stuff,
but
again
just
some
of
the
phraseology
and
things
of
that
nature.
C
We
need
at
least
one
additional
intradomain
use
case
talking
about
suppression
of
east-west
attacks
within
a
transit
provider,
and
of
course,
if
folks
have
additional
ideas
for
other
use
cases
that
you
believe
belong
either
in
the
in
the
inter
or
intra
domain
sections.
Please
feel
free
to
share
those
on
the
list
and
then
based
on
the
sense
of
the
working
group.
With
regards
to
the
home
net
use
case,
then
we'll
need
to
make
some
edits
based
on
that
in
the
presentation.
C
One
I
have
a
question
a
couple
of
years
ago:
Andrew
Mortensen.
Actually
let
off
a
discussion
about
the
home
net
use
case
on
the
list.
You
know
we've
had
a
couple
of
people
reply,
but
I,
don't
really
think
we've
received
enough
input
from
the
working
group
on
that
particular
use
case.
So
we'd
really
be
grateful
if
people
could
read
that
on
the
list.
D
Technically
I
believe
we
have
5
to
5
5
5
to
10
minutes
for
discussion.
If
you
have
questions
about
use
case
graph,
the
co-chairs
appreciate
that
the
latest
revision
was
very
very
recently
so
you're
not
demanding
that
you
have
read
it
overnight.
If
you
have
feel
free
to
speak
out,
if
you
have
comments,
please
feel
free
to
say
so
now,
specifically
also
if
you
want
to
reiterate
your
feedback
about
the
whole
net
use
case
yeah.
So
the
floor
is
yours
for
questions.
E
C
Because
it's
not
sufficiently
different
from
several
aspects
of
several
the
other
use
cases
that
are
already
in
there
reading
the
write-up
of
it
there's
nothing.
That
seems
to
be
very
unique
about
it
and
it's
very
rather
verbose
for
being
non
unique.
Ok,
so
it's
not
the
scenario
that
you
feel
does
not
apply.
It's
just
the
way
it's
written
right
yeah!
Is
that
correct?
E
F
Hi
there
are
chunk
of
region,
come
from
curate
of
ellipse,
with
a
few
suggestions.
First
of
the
three
to
name
it
first
of
them.
Speaking
about
the
use
case
with
Mississippi
requesting
assistance
from
other
emesis
peas,
I
believe
it's
important
to
review
the
work.
That's
done
by
another
work
group,
especially
CD
and
I,
because,
though
videos
MSSP
and
the
content
delivery
network
are
pretty
much
should
be
designed
not
in
the
same
way,
though,
some
of
you
that
use
cases
may
play
here.
F
C
F
I
believe
that,
due
to
this,
this
use
case
may
contradict
with
the
working
group
chapter
in
a
place
where
it
says
that
the
working
group
will
focus
on
signaling
and
coordination
mechanisms
directly
related
to
denial
of
such
attack,
detection
classification,
traceback
and
mitigation
because
of
this
I'm
now
coining
a
term,
but
this
I'll
say
abuse
signaling
might
be
I
think
in
itself,
which
will
require
maybe
another
working
group
for
that
those
you're
coming.
Yes,
okay,
you.
C
C
F
Just
a
technical
one,
the
big
because
there's
some
inconvenience
cause
by
there's
a
github
page
for
use,
cases
which
doesn't
get
any
up,
doesn't
get
any
update.
Currently,
the
version
which
is
on
data
tracker
is
seven
from
July
20th
and
the
version
which
is
on
github
is
five
from
May,
the
4th,
which
also
rises
a
question
of
what
it
all
has
to
do
with
Star
Wars
with
the
poor's
sir,
that's
a
silly
joke.
Yeah
yeah.
C
Our
well
noted
on
getting
the
getting
github
updated
to
your
first
comment.
If
you
can
give
us
some
pointers
on
the
list,
specifically
the
SDNS
D&I
stuff,
you
like
us
to
take
a
look
at.
That
would
be
very,
very
helpful
with
regards
the
outbound
DDoS
issue.
This
is
a
completely
distinct
from
other
types
of
bad
traffic
emanating
from
broadband
access
network,
in
that
it
negatively
affects
the
availability
of
the
broadband
operator
in
can
have
an
extremely
high
impact,
we've
seen
outages
with
literally
millions
of
users.
C
Hundreds
of
thousands
is
very
common
that
are
the
result
of
outbound
DDoS
attacks
that
are
launched
from
a
lot
of
different
devices,
computers
and
so
forth.
That
are
that
are
part
of
botnets
on
broadband
access
networks
on
broadband
operators
on
spend
a
lot
of
time
dealing
with
this
and
suppressor
pressing
outbound
DDoS
attacks
in
a
number
of
different
ways
to
help
preserve
the
availability
of
their
network
for
their
subscribers
and
pretty
much
right
now,
I
mean
there's.
C
There
are
there's
kind
of
a
constellation
of
tools
that
are
used
by
different
broadband
access
providers
and
it's
a
little
bit
kind
of
bespoke.
You
know
for
each
one
they
have
different
mechanisms,
and
so
the
idea
here
was
to
illustrate
the
fact
that
number
one
dots
could
in
fact
be
used
to
signal
for
the
mitigation
action
of
suppressing
the
outbound
udaas
attacks
that
there
be
a
standards-based
mechanism
to
do
this.
So
all
of
the
different
broadband
access
operators
don't
have
to
roll
their
own.
B
C
F
The
trend-
okay,
I,
see
a
point.
It
I
need
to
mention
that
the
content
that
we
observe
is
the
maintainer
or
owners
or
users
of
wood
nets.
They
attempt
more
to
hide
their
activity
from
the
network
which
networks
which
originate
the
traffic
because
it
ultimately
causes
the
elimination
of
some
parts
of
botnets.
Their
aim
of
designer
of
a
botnet
is
actually
to
hide
its
activity
from
their
from
the
okay,
let's
say,
personal
computer,
on
which
it's
either
sites,
because
other
way
the
user
will
get
aware.
F
C
It's
yeah
so
again,
I'm
just
speaking
as
an
individual
here
opera
involved,
the
operational
community
that
doesn't
match
what
we
see
at
all.
We
see
the
fact
that
the
bad
guys
who
are
using
botnets
to
launch
DDoS
attacks
have
so
many
different
nodes
that
they
don't
care
if
many
of
them
end
up
being
remediated
because
they
have
so
many
extra
spare
ones.
It
is
easy
to
compromise
new
ones,
also
in
terms
of
hiding
DDoS
traffic.
That's
not
really
easy
to
do.
Very
specifically.
C
The
spoof
traffic
then
comes
into
the
broadband
access
provider
network
and
it
hits
these
devices
that
are
misconfigured
with
things
like
Open
DNS
relays,
for
example
or
SSDP,
and
that
they
stimulate
those
nodes
to
then
send
you
know
the
relatively
high
volume
traffic
out.
So
in
that
regard,
the
initiators
of
the
traffic
are
certainly
I
guess
you
could
say
that
they're
heading
in
a
way,
because
it's
difficult
to
trace
them
back
in
many
cases,
but
the
outbound
DDoS
traffic
that
is
stimulated,
that
is
sourced
from
the
broadband
access
network,
is
not
hidden
in
any
way.
C
A
G
A
G
G
G
The
is
G
is
tending
to
encourage
just
to
let
a
draft
drefs
never
disappear
now,
even
once
they
expire
so
like
link
them
off
of
a
wiki
or
something
like
that
and
not
go
through
the
full
publication
process.
I
leave
that
up
to
the
working
groups
I
work
with
and
if
there's
a
strong
desire
to
publish
I
will
work
with
you
to
do
that,
but
I
wanted
to.
Let
you
know
of
this
preference
before
you
get
to
iesg
review
and
learn
about
it.
Okay,.
G
G
D
In
light
of
that,
it
was
there,
and
these
milestones
were
agreed
and
with
the
intention
to
publish
so
at
this
point,
I
would
say:
I
understand
that,
there's
a
preference
not
to
do
it
anymore,
but
also
I,
would
say
there
is
an
agreement
that
it
there
was
a
previous
agreement
to
do
it.
So
that's
the
procedural
answer.
The
practical
answer
is
I
strongly
believe
that
the
use
case
is
document
and
at
the
very
minimum.
D
Also,
the
architectural
document
are
very,
very
valuable
for
future
readers
to
understand
this
and
I
believe
even
the
requirements
document
will
be
helpful.
A
number
of
these
dots
cases
are
non-trivial
and
the
use
cases
really
helps
to
inform
what
you
do
with
that.
So
I
do
believe
they
are
quite
valuable
as
informational
documents.
That's
my
personal
opinion.
D
G
G
D
G
C
Okay,
so
on
in
terms
of
you
know,
publication
versus
non
publication.
You
know
I
personally
individually,
don't
care
one
way
or
the
other.
We've
already
received
positive
feedback
from
the
folks
working
on
architectural
requirements
that
the
use
cases
revisions
have
been
useful
to
them.
The
only
other
thing
I
would
say
is
that
you
know
DDoS
is
kind
of
an
arcane.
You
know
subject
compared
to
the
rest
of
security
is
its
new
to
a
lot
of
folks
and
as
we
move
towards
you
know
getting
things
in
you
know
into
the
standards
track.
C
We
want
to
encourage
folks
to
number
one
implement
dots
and
number
two
make
use
of
it
that
some
form
of
guidance
and
context.
You
know
from
the
use
cases
we
think
may
be
useful
for
the
implementers
and
the
some
some
of
the
actual
potential
users
as
well,
whether
or
not
that
means
that
they
should
be
published
separately,
whether
it
means
I
should
be
folded
into
another
document.
I,
don't
I,
don't
have
an
answer
to
that,
but
it's
important
I
think
that
the
use
cases
are
preserved
in
a
published
document
that
can
be
cited.
G
So
Kathleen
Moriarty
again
to
your
point
about
the
summary
and
how
things
tie
together.
What
has
been
received
very
positively
is
overview
documents
and
they
would
come
at
the
end
of
a
working
group
lifecycle
and
it
might
pull
together
a
lot
of
the
information.
That's
in
those
other
types
of
documents,
but
it
would
also
show
the
connection
between
the
various
drafts
in
the
working
group
and
any
other
drafts
or
rfcs
from
other
working
groups.
G
I
E
Slamming
andreas
yeah,
I
mean
I
still
support
all
three
documents.
I
think
we
had
a
little
bit
of
discussion
around
that
actually
in
the
design
team
meeting
this
past
week.
My
read
of
that
was
that
the
general
sentiment
was
that
people
were
still
in
favor
of
these
documents
as
well.
So
you
know
if
anyone
wants
to
speak
up
differently,
you
know
by
all
means
and.
D
J
K
K
L
Moskowitz
speaking
for
Annie,
Mortensen
and
chill
ready
and
I
would
say
that
Annie
did
the
lion's
share
of
all
the
work
on
here,
but
fortunately
for
Andy.
He
is
at
home
where
he
belongs
with
his
wife.
Just
had
a
child,
so
I
am
thus
tasked
with
really
going
through
Andy
slides
that
that
he
worked
on
and
we'll
go
through
here
on
the
where
we
stand
with
the
dots
requirements.
Draft
the
changes
since
oh
five,
we
had
good
work
group
feedback
following
the
last
IETF
at
a
github
issues
for
all
work
feedback.
L
So
we
have
been
tracking
that
on
the
workgroup
and
is
again
be
done,
a
wonderful
job
of
saying
to
then
keeping
keeping
that
going
address
all
the
new
issues
in
all
six
set
up
for
that
ten
issues
were
closed.
Since
the
interim,
we
have
one
remaining
issue
well
done
quite
well
on
this
draft
and
completing
items
that
people
have
brought
up
what
we
have
for
those
these
are
some
of
the
ones.
L
We've
closed,
add
authorization
requirements,
clarify
replay
protection
requirements
and
again
you
can
go
and
you
can
see
what
these
issues
were
and
what
we
said.
So
if
that
is
there
clearly
in
the
github,
client
must
set
mitigation.
Lifetime
client
may
incorporate
server
feedback
and
servers
must
support
black
whitelist
management.
So
those
are
examples
of
some
of
the
of
the
ten
issues.
There
are
five
of
the
ten
that
we
addressed
in
this
this
round.
L
We'll
review
it
one
last
time
before
we
do
indeed
post
it
so
and
that's
the
point.
We
have
not
received
any
new
issues
for
some
time.
We
really
believe
that,
in
terms
of
the
requirements
document,
we
are
at
closure.
This
one
issue,
which
is
standing,
which
I
just
mentioned
this
one
issue
we
will
put
into
the
next
version
of
the
draft,
so
you
can
work,
read
the
wording
on
that.
You
can
check
out
the
wording,
we've
done
on
these
issues
and
then
the
Tulsa
ten
issues
and
how
we
handled
it.
L
But
we
really
believe
that
we
are
with
the
0-7.
We
will
be
done
and
ready
for
workgroup
last
call.
So
that
completes
my
slide
presentation.
This
is
the
github,
our
location,
where
you
can
see
all
this
and
we're
welcome
you
to
to
go
and
check
it
and
at
that,
unless
Andy
or
Tara
want
to
pipe
in
from
online
I'm
open
for
comments
and
questions.
F
F
F
F
F
Next,
the
dots
client
is
once
again
in
some
cases
it's
believed
to
be
some
kind
of
security
appliance.
Well,
yesterday,
the
TLS
group
figured
out
that
most
endpoints,
like
middle
boxes,
like
what's
gonna,
be
a
dots
client
I'm
not
built
for
full-scale
packet
capture,
which
actually
is
so
while
the
upstream
transit
operator
running
is
a
dot.
Server
is
by
definition,
capable
of
doing
this.
F
I'm,
not
even
speaking
about
the
perceived
quality
and
I
mean
quality
of
aware
of
this
middle
box,
some
of
them
at
least,
but
the
issue
is
that
the
debtor
actually
could
know
about
the
attack
lots
more
about
that
kind
of
attack
of
the
the
scope
of
the
mitigation,
and
it's
not
that
feasible
to
leave
all
the
decision-making
towards
the
client.
There
are
also
issues
with
congestion
in
this
case
and
all
lastly,
they.
F
This
is
inconsistent
with
the
characteristic
requirement
on
the
page,
five,
the
bottom
of
it,
which
tells
us
that
the
purpose
of
the
whole
document
excuse
me
is
to
design
an
advisory
protocol.
Yet
we
here
see
that
let
me
code
that
in
case
when
this
client
requests
to
stop
the
mitigation,
the
server
should
stop
it
in,
like
three
hundreds
of
seconds,
imagine
a
scenario
where
we
have
a
king
of
dots,
client
service.
F
So
he
just
cannot
stop
the
mitigation
here
in
this
case,
because
it
will
essentially
bring
the
whole
service
down.
I
think
that
here
we
should
once
again
examine
what
the
dots
server
must
treat
when
the
dots
or
must
treat
the
mitigation
is
terminated
and
when
it
should
do
it,
but
it's
possible
not
to
do
that.
L
And
yes,
let's
Andrew
answer
this,
because
when
he
wrote
that
much
that
text
and
I
will
say
that
this
is
an
advisory
message
before
I
drove
over
to
Andrew
and
though
the
client
says
I
see
this
attack.
As
you
said
in
many
sessions
many
time
the
server
says
you
see
this
attack,
the
tack
is
really
something
else.
We
recognize
that
that
that
many
times
with
this
is
what
the
client
sees
as
attack
may
really
not
be.
M
Okay,
well
to
the
week
that
the
can
everybody
hear
me.
First
of
all
make
sure
we
care
you
Andrew
great,
so
to
the
point
that
the
the
server
must
see
the
mitigation
I.
Believe
there,
the
text
in
there
as
well.
That
says
the
server
may
is
no
longer.
The
server
can
continue
to
do.
It
can
continue
mitigation,
but
the
clients
it
is
no
longer
responsible
for
that
mitigation.
M
M
F
L
A
Should
have
all
the
discussion
on
the
man
list
we're
using
github
to
track
that
we
have
an
issue
whose
resolution
won't
have
it
and
on
the
mail
list.
So
please
absolutely
bring
the
issue
to
the
man
list
and
then
the
author's
editors
will
make
sure
that
it's
dropped
in
and
tracted
github
for
us.
Yet.
M
One
other
things,
so
you
were
as
saying
that
you
feel
the
text
is
implying
that
the
dots
client
must
be
some
sort
of
detection
device
and
that
it
must
the
detection
will
be
the
trigger
for
everything.
That's
that's
not
necessarily
the
case
and
I
believe
the
architecture
document
does
have
a
scenario
where
there's
a
manually
initiated
mitigation
where
an
operator
uses
uses
dots
as
the
vehicle
manually,
regardless
of
the
presence
of
any
attack
and
regardless
of
any
detected
attack.
Correct.
D
F
B
C
For
that
good
thing,
thank
you
very,
very
brief.
Clarification
on
dot
says
is
not
tied
to
any
particular
form
of
detection.
Classification
traced
back
or
many
into
to
any
particular
mitigation
model
or
technology
is
deliberately
independent
of
those
things.
Secondly,
there
are
use
cases
which
denote
other
types
of
things,
besides
security,
specific
devices
making
dots
requests.
C
And
thirdly,
we
did
have
a
use
case
in
0,
0
and
0
1
I
believe,
which
was
an
example
of
mitigation
service
writer
not
being
able
to
heal
on
mitigation
because
of
our
capacity
issues,
and
so
I
believe
this
comment
we
should
think
about
bringing
that
use
case
back
in
to
show
a
failed
mitigation
is
illustrative
of
this
type
of
issue.
Thank
you.
J
D
D
D
M
I'm
I'm
a
slow
ghost
yeah,
so
the
there's
the
1
outstanding
issue,
as
bob
highlighted
in
the
presentation
I
do
have
some
text
on
that.
I
won't
be
sharing
that
with
the
other
co-editors
and
then
I
expect
that
go
immediately
to
seven,
so
I
I
would
anticipate
actually
early
next
week,
assuming
that
aligns
with
the
other
co-editor
schedules,
but
it
should
happen
very
quickly.
N
So
for
the
architecture
draft.
We
had
two
revisions
since
the
last
IETF
we've
incorporated
all
the
working
group
feedback
issue
tracking
eyes
on
github.
There
are
currently
no
issues.
Issues
feel
free,
we're
awaiting
additional
multihoming
discussion
that
was
spawned
from
the
discussions.
We
had
last
time
that
med
and
Tara
have
put
a
draft
together
form
from
which
I
think
med
is
presenting
shortly.
N
The
changes
since
the
oh
three
was
to
emphasize
reduced
client
control
in
recursive
signaling
caveats,
so
that
was
the
client
control
over
network
path
of
mitigate
traffic
may
be
reduced,
defined
dot
sessions.
We
had
previously
kind
of
like
being
having
lots
of
discussions
around
the
word
sessions,
so
we
tried
to
clarify
that
a
bit
better
and
went
from
signal
sessions
to
dot
sessions,
which
is
somewhat
so.
We
try
to
just
define
it
as
an
established
bilateral
exchange
of
data
between
dots,
client-server
so
similar
to
sip,
don't
miss
something.
C
Diamonds,
Arbor
networks,
I
think
a
lot
of
people
in
the
working
group
know
that
we've
been
working
on
use
cases
and
the
requirements
kind
of
you
know
in
parallel
with
one
another
and
informing
you
know
one
another
bilaterally
so
to
speak,
and
we
do
have
one
more
Rev
of
use.
Cases
is
going
to
come
out.
We
have
one,
maybe
two
now
additionally
use
cases
and
then
there's
the
whole
net
issue.
C
A
About
multihoming
and
for
context
setting
is
we
got
together
at
the
interim.
We
had
mentioned
that
there
were
some
things
that
we
needed
to
talk
about
related
to
the
architecture
and
one
of
those
was
related
to
multi-homing
and
coming
out
of
that
interim
Chiru
man
actually
said
they
would
write
something
up
to
the
mailing
list
to
get
the
conversation
started,
but
the
origin
of
this
draft
is
actually
one
better.
They
actually
made
a
draft
about
some
of
their
thinking.
So
thank
you
for,
for
forgetting
the
conversation
started
in
this
formal
way.
P
So
the
the
background
for
having
this
rough
writing
and
presented
in
this
in
this
in
this
meeting
so
and
just
a
recall
of
the
minnow
people
that
we
have
to
have
when
we
wrote
this.
This
is
the
first
ones
to
completely
the
dots
architectural
document
with
not
how
many
specific
specific
aspects,
because
currently
there
are
some
text
which
is
in
the
architectural
document
which
is
in
the
building,
which
is
not
sufficient.
P
P
P
So
that's
why
there
is
a
need
to
to
have
some
guidance
somewhere
in
the
architectural
document
or
in
a
separate
document
to
guide
the
DOS
client
and
the
disc
gateways
on
the
way
you
will
place
the
request
and
the
maintain
the
association
with
upstream
the
servers,
so
how
which
methodology
we
have
adopted
for
this
when
we
read
it.
So
we
started
from
the
the
effort
that
that
is
documented
by
Roland,
so
that
we
just
extracted
the
viable
use
cases
from
there,
and
we
wanted
this
use
cases
with
specificity
of
the
of
the
mr.
P
So
basically,
this
is
just
a
summary
of
some
example.
At
least
the
main
trends
of
the
use
cases
that
we
can
cover
when
we
are
we're
dealing
with
multihoming
I
am
not
listening
in
this
one.
The
other
use
cases
in
which
you
have
your
mitigation
provider.
It's
not
your
own
transit
provider,
and
this
is
a
cloud
hosted
by
in
a
cloud.
Basically,
you
have
three
three
three
flavors
there,
which
are
three
of
them.
P
You
are
likely
to
encounter
in
an
enterprise
context
and
one
and
the
the
fourth
one
which
is
likely
in
the
world
that
context
in
which
you
have
SCP
SCP,
which
is
connected
to
multiple
and
multiple
domains:
first,
typically,
a
fixed
X
line
and
the
other
one
with
a
mobile
element
and
the
E
and
the
D
traders.
This
is
typically
the
entreprise
network
in
which
you
have
a
multi
hond.
You
may
have
multiple
absent
providers.
P
If
you
want
to
play
with
your
top
team
as
your
Cecily's
and
in
industry
flavors,
you
have
francis
the
typical
one
usual
is
in
one
single
router,
or
one
single
CP
router
to
integrity
on
absent
provider
or
if
you
have
the
using
dedicated
routers
to
interconnect
to
upstream
sales
provider.
So
once
we
have
identified
this
may
flavor
of
having
multi-home
at
the
human,
we
will
start
to
see
now
if
we
enable
the
das
service
somewhere.
So
again,
there
will
be
a
variety
of
of
of
scenarios
there.
P
You
may
have
all
your
ups
observers
preferences
that
support
the
dude
server,
but
you
may
also
have
only
a
subset
of
this
providers
who
offer
to
do
the
server,
but
whatever
the
scenario
that
would
be
experienced
there,
there
is
a
constraint
that
is
that
some
of
the
dist
servers
that
will
be
available
in
this
absent
providers
may
not
be
reachable
through
an
arbitrary
path.
They
will
be
reachable
only
from
the
router
connected
to
the
absent
provider
who
is
offering
to
you
the
the
dead
server.
P
So
this
a
producer
requirement
there
to
associate
the
link
from
where
you
have
learned
your
good
server
and
so
that
before
for
placing
ups,
three
subsequent
requests,
you
have
to
always
select
that,
but
otherwise
you
will
have
failures
to
contact
with
the
server.
Now,
once
we
have
identified
the
scenarios
in
which
you
have
a
placement
of
your
dead
server.
If
we
see
now
at
the
client
side
a
gander,
there
is
a
variety
or
a
variation
of
scenarios
there,
with
or
without
adults
gateway.
You
can
have
a
gateway
somewhere
in
the
DCP
on
the
router.
P
It
may
be
look
at
it
elsewhere.
There
is
no
requirement
in
the
does
in
the
dots
architecture
that
the
dot
functional
element
be
located
in
the
the
tablet
or
or
in
the
indeed
pad.
That
will
experience
the
DDoS
attack.
So
you
you
have
this
kind
of
of
scenarios
there.
This
is
only
again.
This
is
only
showing
examples
there.
You
may
have
an
if
Francis
V
we
we
focus
on
the
first
one
in
in
which
you
have,
for
instance,
a
gateway
which
is
connected
located
in
one
single
router
and
connected
to
two
upstream
providers.
P
The
this
gate
reference
does
get
referenced
as
it.
It
has.
The
responsibility
decide
whether
we
need
to
receive
a
request
from
internal
clients.
It
has
to
decide
to
decide
to
which,
upstream
that
server,
it
has
to
transmit
the
the
request
or
it
has
to
frog
the
request
to
all
the
app
standard
server
which
is
about
in
the
question
on
this
or
yes,.
E
Let
me
address
not
have
two
questions
for
you.
First
one
is
I.
Think
we've
tried
to
take
a
general
design
principle
in
the
group.
For
now
of
saying
we
want
to
address
the
simple
scenarios
for
and
then
we
can
always
extend
later
on
with
more
complicated
functionality.
So
you
know
the
meta
question
is
whether
you
think
multihoming
is
an
absolute
requirement
for
what
we're
doing
is
the
first
step
in
dots
to
address
that
scenario.
E
P
Yeah
the
questions
yeah
for
the
first
one-
yes
I
do
agree.
Personally,
as
we
don't
need
to
overload
the
current
built
architecture
with
the
demented
Holman
I
did
make
current
for
this.
Take
on
this
is
that
is
to
make
it
clearer
than
the
current
dot
architecture
is
mainly
forgetting
for
the
single
haunt
and
to
leave
multihoming
for
something
else,
so
that
the
group
will
have
time
to
focus.
We
tend
to
study
it
further,
so
this
is
for
the
first
question.
Okay
for
the
second
one,
the
the
dots
gateway
is
defined
as
a
back-to-back.
P
This
client
and
the
server
service
is
fine,
the
dots
get
by
anyway,
but
anyway,
that's
another.
How
do
you
glue
your
client
and
your
server
into?
This
is
an
internal
implementation.
We
are
not
specifying
that,
but
how
you
are
placing
your
request.
This
is
just
a
normal,
that's
client
and
the
in
the
other
side
how
the
dot
server
will
receive
and
process
at
the
the
the
request.
This
is
how
we
are
defined
that
yeah.
E
D
There
may
be
no
later
so
I'm,
just
I
won't
just
want
to
make
clear
like
if
you
believe
this
is
essential,
then
say
so,
and
if
this
is
an
essential
requirement,
assuming
there
is
no
later,
that
would
be
good
if
you
could
state
it
if
you
believe
it
needs
to
be
covered.
If,
if
not,
then
that's
fine
for
me
as
well.
Yeah.
P
This
one
yeah
so
just
called
me
to
deliveries
for
that.
We
started
from
the
dirtiest
cases
and
all
what
M
explained
here
is
extracted
from
the
dots
use
cases.
So
for
me,
it
is
something
which
is
the
working
group
have
identified
in
in
this
work,
you've
adopted
document,
and
they
don't
think
that
personally
that
this
language
is
interesting
that
we
to
handle
there
is
something
which
is
specific
to
milky
homi,
which
is
not
unique
to
the
other
solution
that
we
have
so
far,
which
are
just
you.
P
Have
you
a
single
hold,
and
then
you
have
your
apps
improve
that
server.
There
are
something
which
is
specific
to
be
to
be
elaborated,
but
those
details
me
in
balance
did
those
architecture
to
the
now.
That's
why
I
prefer
to
have
it
something
outside
the
dots
architecture.
So
this
is
two
levels
it's
important,
but
we
may
need
to
handle
it
in
a
separate
document.
C
C
E
P
Okay,
so
if
you
come
back
to
us
cases,
we
have
an
at
least
if
you
focus
on
the
client
side,
as
I
mentioned,
you
may
have
seen
ours
in
which
we
have
the
Gateway
and
the
others
in
which
we
we
don't
have
gateways.
I,
do
agree
with
Roland
here
that
there
is
no
implicit
implication
on
the
protocol
itself,
but
there
will
be
implication
on
the
way
the
dots
get
oriented.
Those
claims
will
use
the
dots
to
contact
the
servers.
P
So
typically,
if
we
now,
if
we
forget
the
topology
and
we
just
focus
on
the
dots,
a
suggestion
themself,
we
have
a
variety
of
scenarios.
There
depends
on
the
use
cases.
Typically,
if
we
offer,
as
you
don't
sell,
CP,
that
you
multihomed
in
there's
two
Association,
there's
the
one
from
the
client
that
is
likely
to
be
invaded
in
the
in
the
CPS
self.
P
So
it
depends
on
each
configuration
that
you
have.
You
have
a
set
of
implications
there
and
recommendation
in
the
way
this
dots
clients
will
contacts
their
upstream
providers
and
all
these
recommendations
are
elaborated
in
the
in
the
draft.
To
give
an
example,
if
we
just
resume
on
this
one-
and
if
you
have
your
your,
you
have
our
original
CP-
that's
embedded
those
client,
and
if
it
happens
that
all
your
absent
providers
are
providing
to
you
that
server,
there
are
the
first
implications
there
is
that,
because
we
are
configuring,
names
off
for
the
best
server.
P
P
There's
also
the
establishment
of
the
association
that
must
be
maintained
with
all
the
app
same
as
AB
same
servers,
but
when
it
comes
to
send
a
mitigation
request,
then
the
the
DOS
client
has
to
decide
whether
it
needs
to
contact
the
appropriate
server
for
a
given,
let's
attack,
because
they
attack
maybe
just
received
for
your
from
the
mobile
network
and
not
for
the
fixed
and
it's
trans.
Yes,
for.
P
Perhaps
you
forgot
my
introduction
on
there
I
say
that's
when
you
focus
on
the
resident
CLK
the
time
machine
here
which
assume
that
this
server
is
provided
by
your
upstream
network
providers
and
I
said
that
if
the
the
dot
server
is
not
Frances
hosted
by
a
cloud
service
providers,
we
are
not
in
this
in
this
in
this.
In
this
use
case,
this
recommendations
are
tied.
So
how.
P
C
Diamonds
Arbor
networks,
first
of
all,
one
second,
what
Fleming
said?
Secondly,
I
believe
that
we're
running
a
risk
here
of
imbuing,
too
much
mitigation,
logic
and
context
within
dots.
A
lot
of
this
stuff
is
external
to
dots,
in
my
view
that
it
really
goes
into
the
orchestration
of
systems
and
mitigation
systems,
and
so
yeah
I
want
I
want
to
hear
more.
But
this
this
seems
like
it's
Mickey's
we're
talking
about
some
problems
that
that
aren't
necessarily
problems.
The
DNS
server
recommendation
in
particular,
it
doesn't
make
sense
to
me.
Oh.
C
D
P
So
the
next
part
is
is
that
this
lies
disease,
showing
some
samples
in
which
indicus
is
not
is
not
recommended
for,
in
plus
in
the
ders
requests.
The
first
case
in,
if
you
have
the
provider
independent
addressing
if,
for
instance,
the
declined,
the
Internet
client
is
using
any
cast
to
reach
the
Gateway,
and
that
means
that
the
death
signal
will
be
received
by
the
the
gateway
which
is
according
to
the
shortest
path
within
that
that
Internet
work,
and
that
could
very
well
just
forward
the
request
to
to
the
appszoom
that
server.
P
P
In
the
other
case,
if
you
have
the
provider
assigned,
for
instance,
assigned
the
assigned
schema
in
this
case
again,
if
we
assume
that
you
are
raising
a
unique
as
unique
as
to
within
the
internal
a
internal
network,
your
request
will
be
received,
for
instance,
by
EDI
gateway,
which
is
the
katadyn
r1.
The
r1,
the
Gateway,
which
is
in
r1,
will
forward
the
request
to
the
upstream
server,
but
the
the
attack
wasn't
Tracy,
isn't
isn't
subject
to
due
to
the
IP
address,
which
is
as
assigned
by
NATO
provider
one.
P
But
if
it
is,
it
is
subject
to
the
idea
that
we
design
by
network
brother
to
the
server
which
is
located
in
the
domain
to
should
be
contacted
instead
of
this
one.
But
you
have
a
problem
there,
because
the
request
was
sent
to
the
first
gateway.
So
in
these
two
examples
this
is
just
to
illustrate
in
cases
which
which
are
the
cases
in
which
it
is
not
recommended
to
use.
Anycast
addresses
when
you
are
contacting
your
upstream,
that
server
that
it
happens
to
be
your
dot.
Gateway,
yes,
Roland.
Yes,
you
that
you.
A
C
That's
so
decisions
about
you
know
whether
or
not
to
use
any
cash
addressing
in
the
topological
issues
that
you
describe
in
this
slide.
I
mean
this
is
network
engineering
101.
Do
we
really
need
to
get
to
that
level
of
detail
in
our
recommendations?
If
we
do
that's,
okay,
I
mean
I,
certainly
see
the
need
to
to
you
know
it
could
help
to
put
some
operation
because
we
already
have
some.
You
know
guidance
as
to
some
of
the
things
that
are
external
to
us,
that
the
operators
need
to
do
so.
I
can
see.
C
P
The
most
important
is
to
have
information
somewhere
and
recorded
by
the
working
group,
and
this
is
an
open
question
tool
to
the
welcome
to
decide
how
to
form
it
is
there's
a
list
of
behaviors
and
guidelines
on
the
way
you
does
client
and
gateways
have
to
behave
in
the
metahuman
context.
How
to
document
that
form?
It's
just
a
logistic.
It's
up
to
decide.
I.
C
A
A
Second
of
all,
we
were
talking
about
I
think
a
little
earlier.
Whether
there
are
any
requirements
relative
to
multi-homing,
I
actually
saw
a
definition
for
a
multi
home
client,
but
I
saw
new
requirements
for
it.
So
this
kind
of
helps
kind
of
inform.
What
we
do
here
and
I
also
notice
in
this
document
very
helpfully.
It
talks
about
requirements
and
architecture
and
borders
kind
of
on
implementation,
so
I
also
would
suggest.
Maybe
we
need
to
decompose,
all
of
which
I
think
we
need
to
do
on
the
middle
list
in
the
interest
of
moving
forward.
P
D
A
lot
of
story,
so
the
underlying
reason
for
the
is
geez
advice,
is
to
manage
the
amount
of
documents
that
are
coming.
I
postulate
this
and
you
may
or
may
not
agree,
but
I
think
I
actually
very
much
welcome
that.
You
put
this
in
a
in
the
form
of
a
document.
I
mean
this
is
very
useful
and
it's
good
to
read
it
that
way.
I
do
agree
with
Roman
that
probably
we
need
to
see
like
where
these
do
these
things
roll
into
the
existing
documents,
like
use
cases,
requirements,
architecture.
What's
the
implications.
G
So
Kathleen
Moriarty
ad
I'm,
not
as
concerned
about
you,
know,
number
of
documents
and
watching
this
it
was
more
that
I'm
interested
to
hear
it,
maybe
on
the
mailing
list
or
show
hands
or
something
interest
in
this,
as
opposed
to
the
you
know,
a
very
few
number
of
people
that
stood
up
right
because
that
doesn't
that's!
That's
not
the
working
group.
That's
you
know
a
couple
of
people's
opinions.
That's.
G
A
Multi-Homing
is
important
at
the
interim
meeting.
We
very
clearly
stated
we're
blocking
the
architecture
document
on
resolving
it,
and
we
have
news
cases
that
do
multi-homing.
So
we
need
to
say
something
about
it
or
kind
of
deal
then
bring
to
closure
or
what
the
working
group
needs
to
do
during
multi-homing.
I
don't
think
we
know
what
to
do
and
boy
it's
really
phenomenal.
We
have
a
lot
of
text
that
describes
what
we
could
do
in
the
multi-homing
space.
D
Before
he
starts
I
like
to
say
how
amazing
it
was
that
we
had
a
hackathon
session
for
dots,
go
dots,
I,
believe
waiting
for
good
odds
and
like
it
was
even
like
listed
as
one
of
the
good
achievements
at
the
hackathon
and
I'm
very
happy.
We
have
that
and
I'm
very
much
looking
forward
to
hearing
more
about
the
implementation
from
Konami.
So
that's
really
great
go
for
it.
Yes,
oh
I,.
J
Thank
you
and
I'm
kinda
mean
he's,
come
from
NTT
communications
I'd
like
to
introduce
the
goal:
implementation
of
thoughts.
Okay,
yes,
we
open
the
code,
then
yeah
I
hope.
This
is
a
good
news
too
yeah.
You
are
this
grip.
This
code
is
available
in
github
this
URL
and
yeah.
You
can
search
for
this
code
by
the
hitting
call
dot.
Maybe
and
then
the
license
is
about
2.0,
so
it's
free
to
use
and,
yes,
you
can
deploy
the
code
only
by
a
gogit
command,
so
yeah
you
could
do
it
so.
J
These
ideas
are
lost
weekend
and
with
this
code,
actually
the
most
of
code
was
developed
and
tested
internally
beforehand.
So
what-what
we
developed
in
this
hackathon
is
that
first
we
made
the
code
of
easy
to
be
deployed
in
various
environment.
For
example,
we
made
a
docker
compose
file
for
each
services
and
also
we
refined
the
configuration
part
which
is
rather
complex,
and
second,
we
clarifies
that
documents
read
any
other
comments
in
the
code
and
enriched
especially
for
newcomers
to
this
field.
J
Ok,
then,
at
the
hackathon
we
made
a
demonstration
of
one
user
scenario
which
triggers
a
black
hole
running
from
victim
side.
So
the
demo
scenario
was
constructed
in
the
current
environment,
so
it
can
be
ported
to
your
environment,
a
project
attracted
at
least
four
people,
which
includes
iyx
people
are
ISP
people
during
the
hackathon.
Then
we
explain
what
dot
is
and
showed
the
demo
okay.
This
is
the
second
good
news
we
do
demo
on
pizza
bites
today,
so
I
from
seven
fifteen
to
nineteen
fifteen.
The
end
so
yeah
pravin
visit
us
on
the
site.
J
Okay,
this
is
a
demo
in
one
paper.
The
demo
scenario
is
enabling
DDoS
protection
in
upstream
network
by
totes
protocol,
the
hot
you
can
do.
I
hope
you
can
see
in
this
demo
is
that
adult
quiet
in
victim
sites
and
the
mitigation
request
to
adult
server
of
asymptotes
fingering
channel,
then
adults
ever
received
and
validates
a
request.
Then
start
mitigation
by
kicking
a
blocker
in
this
time
of
the
blocker
is
Gobi
City
server,
which
triggered
the
call
routing
in
a
service
operators
network.
In
fact,
the
dot
client
is
in
some
cloud
service
and
service
providers.
J
Network
is
in
fact,
in
our
lab
network,
but
dot
dot
request
conveyed
over
the
Internet.
So
you
can
see
this
table
in
bits
and
bytes
okay,
I'd
like
to
introduce
three
lessons
learned
from
our
experience.
So
you
know
we
talked
about
these
lessons,
love
lessons
learned
in
the
yesterday's
design
team
meeting
about
a
drug
to
repeat
them
in
order
to
show
you
here,
you
hear
from
you
first
point:
yeah
about
this
description
on
specification
on
mutual
certification
is
needed.
I
think
our
current
draft
is
using
a
DTLS
based
client
certificate
in
Louisville
in
lab.
J
We
tend
to
use
self
signed
certification.
Then
the
question
is
how
he
binds
the
DTS
or
a
TLS
channel
and
customer,
which
is
a
mitigation
Scott,
so
a
CN
or
as
in
Osawatomie
indicators,
should
be
used.
So
it's
not
clearly
documented,
and
the
second
question
is
what
else
for
mutual
authentication.
We
would
like
to
find
some
other
technology
for
mutual
authentication.
Then
a
question
is
again:
how
can
we
bind
the
authenticated
entity
with
customer
education
Scott?
That
is
a
question.
J
Okay,
the
second
point:
I,
we
are
still
searching
for
good
risk
of
library,
as
our
other
alternative
crop
ETS,
which
is
using
signal
channel,
can
be
used
for
data
channel.
So
we
took
these
strategies,
but
we
want
to
implement
it
on
risk
of
if
we
cancel,
if
you
have
opinion
about
this
strategy
over
you,
if
you
know
good
risk
of
library,
please
assure
to
the
working
group.
J
Okay,
so
third
point
is
about
a
heartbeat
mode.
Yeah,
we
think,
as
we're
hot
with
mode
should
be
allowed
between
those
cry
out:
dot
server,
yeah.
As
a
starting
point
of
implementation
in
love,
we
used
zero.
How
treat
mode,
but
also
we
realized
that
there
are
several
use
cases,
as
discussed
in
the
last
I
heated
meeting.
For
example,
our
residential
CPE
use
cases
and
at
Hawk
cry
out
so
yeah
so
must
in
recur
with
or
recommit
ruff
6:03
should
be
relaxed.
This
is
our
proposal.
J
E
B
E
C
F
J
J
M
M
K
D
N
Again,
Nick
Teague,
no
I
just
wanted
to
echo
regard
echo
some
the
discussion
on
the
zero
heartbeat
idea.
It's
not
so
much
that
we
should
I
I,
agree
that
we
should
have
a
must,
implement
the
heartbeat
and
then
have
an
option
to
turn
it
off
for
certain
scenarios
where
it
is
understood,
that's
turning
it
off
poses
a
certain
risk
or
poses
a
certain
change
in
the
way
that
we
we
deal
with
the
logic.
There
are
arguments
for
ad
hoc
communications
which
don't
require
the
constant
to
backwards
and
forward
of
a
heartbeat.
N
C
J
C
F
E
On
the
whole
heartbeat
thing,
I
mean
I,
I
have
enormous
ly
mixed
feelings
about
the
heartbeat
on
one
hand
right.
You
know
scalability
I'm,
very
concerned
about
it
right,
especially
with
some
of
the
use
case
scenarios
we
have.
On
the
other
hand,
we
have
scenarios
to
say
we
have
to
be
able
to
traverse
Nats
I,
don't
know
how
to
reconcile
all
of
that,
but
I
am
concerned.
You
know
about
heartbeat
in
general
in
this
protocol.
I
don't
think
it's
well
under
civil.
The
implications
are
right
now.
J
A
Given
that
feedback
I
think
that
cascades
into
multiple
drafts
that
were
trying
to
get
done
so
this
certainly
speaks
to
the
protocol
drafts
themselves,
but
it
would
appear
that
the
requirements
language
might
need
to
be
tuned
as
well.
So
it
seems
valuable
to
put
a
note
out
as
a
github
issue,
so
we
track
this
either
closure
to
figure
out
what
we've
resolved
or
we
can
further
discussion
as
to
what
to
do
next.
Roland
you're
just.
C
J
Yep
yeah
about
ionic
consideration,
yeah,
we
think
IV
need
assignment
for
the
fraud
for
number
four
six.
Four:
six,
which
represents
dot
dot
for
signal
channel,
which
is
in
spectrum
lost,
motifs
in
dots
of
a
UDP,
is
used
in
our
implementation,
and
we
used
four
six
four
seven
for
datachannel,
but
exactly
we
need
some
assignment
when
yeah
our
protocol
is
standardized,
and
here
here
are
imitation.
Specific
problems
is
written
like
this
first
point
is
traffic
that
color
collection,
the
atrophic
information
should
be
returned
from
dots.
J
Others
are
like
an
incoming
traffic
block
traffic
post
Rocky,
but
we
noticed
that
we
need
additional
software
components
to
collect
those
data
from
new
network
equipment
or
mitigation
boxes,
but
it
is
very
implementation
specific.
So
we
cannot
make
any
assumption
beforehand,
but
it
is
required
so
yeah.
This
is
a
difficult
problem
to
maybe
do
to
implementers.
The
second
point
is
partially
invalid.
Query
quest
well.
Mitigation
requests
can
contain
multiple
scopes,
but
when
the
mitigation
requests,
we
include
varied
scope
and
invalid
Scott.
J
C
Roland
Islands
Arbor
networks
on
traffic
data
collection
in
export
statistics.
My
views
at
there
outside
the
scope
of
this
working
group.
As
you
say,
it's
very
implementation,
specific
there's
a
lot
more
than
PPS
and
VPS
to
be
concerned
about
right,
just
all
the
different
layer,
7
stuff-
and
there
are
mechanisms
like.
C
Other
things
that
can
be
used
to
return
this
information
to
a
requesting
dot's
entity
outside
the
scope
of
dots,
we're
basically
now
turning
ourselves
into
a
network
telemetry
system.
If
we
go
down
this
path,
so
I
would
recommend
that
that
we
think
very
very
carefully
before
we
do
this
again.
My
individual
view
with
regard
to
partially
valid.
C
C
J
J
Okay,
as
a
next
step
yeah,
we
a
recommendation
is
now
Oasis,
so
we'd
like
to
make
it
to
the
adoptee
to
the
various
deployment
scenario,
and
we
keep
going
on
the
implementation
of
working
group
draft
and
make
feedback
to
the
specifications
so
yeah
we
can
collaborate
on
it.
So
you
have
feedback.
Is
we're
very
welcome.
H
J
H
J
So
yeah
those
is
getting
popular.
We
realized
in
the
hackathon,
so
we'd
like
to
do
inter
interoperability
testing
as
enix
Hakkasan
eitf
100
in
the
design
team
meeting.
We
talked
with
implementers
each
other
and
we
saw
that
a
similar
channel
interrupt
would
be
the
first
step,
but
it
is
not
committed
yet,
but
we,
it
loves
to
do
start
yeah.
This
is
the
end
of
my
presentation.
Thank
you
very
much.
D
Who
would
be
interested
because
thank
you
no
ability.
It's
always
nice
to
have
more
than
one.
So
who
is
interested
in
doing
that?
No
commitment
at
this
point
I'm
just
asking
for
interest
any
show
of
hands
any
shyness
yeah
so
that
we
have
one
two
at
the
back
three.
Okay.
Do
you
want
to
state
your
name
and
company
for
the
record,
or
rather
not
just
show
of
hands
so
to
leave
the
bar
of
commitment?
Less
okay,
I
see
you
I
know
you're
fine
any.
So
that's
that's
at
least
three
different
companies.
If
I
counted
this.
D
Okay,
cool,
so
that
that
gives
us
four
plus
entity.
That's
five!
That
would
be
awesome
yeah.
So
then,
please,
if
you
have
any
questions
or
need
any
help
in
preparing
for
that.
Let
the
chairs
know
we
would.
We
will
do
anything
in
our
power
to
support
that.
So
that's
great
okay
and
thank
you
so
much
I'm,
sorry,
the
ID
as
well
so
she's
smiling.
So
this
is
yeah.
So
thank
you
very
much
for
Kaname
for
making
this
first
great
step
forward
and
I'll
be
looking
forward
to
more
in
Singapore
awesome,
yeah.
A
And
one
more
thing:
I
wanted
to
repeat
about
doing
Interop
that
came
up
in
the
design
team
meeting.
If
this
puts
someone
that's
on
the
fence
to
participate,
your
code
does
not
need
to
be
open
source
and
you're,
releasing
no
IPR
by
bringing
your
implementation.
So
if
you
are
kind
of
wondering
do
I
does
that
imply
kind
of
anything
that
I
bring
it
in
terms
of
kind
of
a
note
well
or
anything
else
it
does
not.
A
A
N
We'll
see:
okay,
so
I'm,
here,
challeng
thiru
I'm,
going
to
do
the
dots
in
single
channels
draft
these
were
adopted
last
time
or
shortly
thereafter.
So
we've
had
we've
dropped
a
couple
of
versions
since
the
transitions
of
the
first
transition,
the
double-o
was,
was
the
adoption
and
were
on
o2.
Now,
we've
addressed
all
comments
receive
from
the
working
group
of
both
drafts.
So
far,
going
on
to
the
signal
channel,
specifically
the
mitigation
requests,
we
replaced
the
idea,
the
the
terminology
of
policy
ID
with
mitigation
ID.
N
The
session
configuration
will
also
replace
policy
ID
with
session
ID,
just
to
keep
kind
of
keeps
a
uniformity
in
that
aliases
could
be
created
either
using
the
dots
data
channel
or
direct
configuration,
direct
configuration
being
somebody
typing
something
on
a
command
line
somewhere
or
into
a
you
know,
into
a
GUI
or
whatever
it
whatever.
It
is
previously.
Data
being
kind
of,
like
I,
think
referred
to
as
direct
connection,
so
it
was
just
to
kind
of
give
it
a
bit
more
clarification
than
that.
One,
the
dot
server,
derives
the
dots
client
identity.
N
There
are
some
further
discussions
around
that
we
had
from
con
amazed
implementation
regarding
things
like
identity
and
also
tying
in
the
the
signal
channel
and
the
assets
that
were
being
communicated,
a
single
channel
while
the
prefixes
and
so
on
and
aliases
and
everything
and
tying
those
to
the
customer
at
the
back.
End
of
the
decor
had
been
gone
through
the
day
channel.
So
there
were
some
some
some
some
resupply
Seng
that
needed
happened
there,
which
obviously
would
be
informed
by
what
kind
of
Mae's
been
doing.
N
N
It
just
a
case
of
like
you,
know,
mitigate
me
or
mean
it
could
be
for
always-on
services.
Well,
how
whatever
anybody
wants
to
do.
We
also
did
a
new
parameter
mitigation
request.
The
signal
server
to
initiate
mitigation
after
the
service
eases
receiving
client
signals
so
similar
to
the
discussion
around
the
harpy
before
you
could
also
have
something
like.
Oh
well,
if
the
heartbeats
disappear
or
if
the
signals
disappear,
then
Autoport
or
mitigate
or
whatever,
that
would
be
a
switch.
Some
customers
would
want
that
some
people
won't
people,
wouldn't
would
trust
it.
N
Other
people,
don't
so
some
people
might
just
be
doing
a
maintenance
and
I
wouldn't
have
told
you
further
next
updates
again
in
can,
in
addition
to
whatever
they've
brought
up,
that
we
need
to
address,
or
anybody
else
is
the
mitigation
lifetime
was
negotiated.
We
there's
a
little
bit
of
confusion,
minute
cuz,
the
mitigation
lifetime
is
it's
negotiated
in
the
request
response,
but
there's
also
some
some
negotiation
in
the
signal
channel
session
configuration.
N
So
we
just
need
to
kind
of
like
figure
out
exactly
what
it
is
we
mean
by
that
and
what
we're
doing
with
it
and
whether
we
want
that
to
go
ahead.
It
doesn't
make
sense
to
do
it
in
two
places
and
especially
if
one
takes
precedence
over
the
other
or
anything
like
that
and
I,
don't
you
can
do
it
on
a
on
a
you
know
on
a
session
configuration
basis
person.
N
C
C
N
I
can't
remember
the
discussion
that
it
came
up,
but
it
was
it
was
there
and
obviously
I
think
I
think
it's
it's
it's
worth
making
note
as
well
this.
This
is
our
first
revision
since
we
adopted
this
one,
so
there's
probably
some
baggage
there
and
there's
some
changes
and
everything
else
would
have
occurred
on
a
on
a
rolling
basis
that
we
that
some
things
have
been.
You
know
there
may
be
some
overlap
or
anything
like
that.
So
so
I
wouldn't
put
too
much
okay,
yeah.
C
I
just
want
to
point
out
for
folks.
Something
proposed
to
think
about
is
that
it's
certainly
a
viable
scenario.
We're
in
a
given
dots
client
request
different
mitigations
at
different
times
with
different
values
based
on
the
specifics
of
a
particular
attack.
So
we
want
to
make
sure
that
we
preserve.
You
know
that
kind
of
flexibility
on
the
part
of
what
the
dots
client
wants
to
requires.
Yeah.
N
B
E
B
E
N
N
So
data
channel,
so
we
extended
the
the
the
ACL
yang
model
to
handle
fragments,
in
support
rate,
limiting
action.
There's
an
example
of
it
brief
bit
on
the
filtering
of
fragments.
We
haven't
really
done
a
whole
look
changes
on
the
data
Channel
other
than
other
than
around
this,
so
the
filtering
of
fragments
to
defend
against
DDoS
attacks
use
any
non
non
initial
fragments
you
can
read
on
the
slide,
they're
exactly
what
it
does
is
just
to
add
it.
N
Some
additional
filtering
capabilities
into
the
into
the
filter,
transfer
portion
of
the
data
channel,
and
it
just
brings
it
in
line
with
with
various
mitigation
potential
mitigation
strategies,
and
so
on
that
we
that
exist
and
that's
it.
So
any
any
comments
concerns
again.
This
is
like
first
drop
I.
Think
since
we
adopted
these
so
with
the
still
way
to
go.
N
A
A
C
N
I
mean
we,
we
have
experience
of
it
where
it's
like.
Oh,
we
want
to
there'll,
be
some
demand,
some
some
kind
of
murmurings
on
a
forum
somewhere,
and
so
you
know
it's
it's
there
for
a
couple
of
weeks
or
a
month
or
whatever
until
so
or
campaign,
or
something
like
that.
So
it's
just
to
kind
of
cover
that
you
know
it,
so
they
can
be
handled
via
dots
versus
a
coordinator.
D
A
quick
question
is
couch
here:
let's
read
the
draft
quick
show
of
hands.
If
so,
we
get
a
feeling
about
the
state
of
review.
At
this
point,
I
mean
I,
know
it's
new,
oh
wow,
wow,
that's
much
more
than
I
expected
two
three
more
like
eight
nine
Wow.
Okay,
that's
yeah!
Okay,
that
that's
a
good
set
of
review
for
an
early
hard.
D
D
N
D
C
A
P
Yeah
yeah,
just
a
reminder
of
the
context,
is
that
he
there's
a
need
for
the
best
client
to
know
the
IP
address,
for
the
name
of
the
disturber
to
contact,
and
currently
the
dots
architecture
is
silent
about
that.
He
assumed
that
based
on
magic,
the
does
client
is
configured
with
the
information
for
the
dot
servers
to
be
a
contact.
P
So
there's
a
void
there
and
you
are
trying
to
fit
that
that
that
void
with
this
document
so
may
have
bid
this
day
is
to
go
back
to
Roland
document
and
to
extract
these
cases
and
to
classify
the
cases,
but
I
am
not
using
all
of
them.
I
removed,
one
that
a
it's,
not
my
favorite,
but
to
balance
that
I
removed
the
the
hum.
P
Let
you
skate,
which
is
not
running
so
if
we
just
consider
all
these
use
cases,
we
classified
them
whether
they
require
a
CP
or
not,
and
also
whether
there
is
a
need
or
or
or
whether,
the
the
dots,
the
the
Daniell
of
service
mitigation
service
is
provided
by
the
absent
if
your
provider
or
it
is
provided
by
a
cloud
service
provider.
So
you
have
the
the
device
combination
there.
P
So
if,
if
we
start
to
examine
this
this
list-
and
if
we
we
have
in
mind
how
we
can
answer
to
the
previous
question
area,
we
have
how
to
configure
or
to
provide
to
the
disk
line
the
identity
of
the
does
servers
to
contact
if
we
focus
on
the
first
use
case,
the
first
use
case,
for
instance,
there
is
a
single,
a
single
network
which
is
single
found
for
this
one.
We
can
just
answer
to
him.
Yeah,
it's
easy,
just
use
an
in
u.s.
address
you.
P
You
would
just
hit
your
dad
server,
that's
easy,
but
the
problem
is
that
there
are
other
use
cases
there
that
your
the
the
dots
mitigation
service
is
not
your
upstream
provider.
If
that
means
that,
if
you
are
using
in
the
COS
address,
you
want
never
reach
the
dots
that
server
in
the
meantime,
if
we
we
have
the
other
use
cases
that
require
to
have
an
integrated,
that's
client
for
those,
it
is
just
appropriate
to
avoid
requiring
new
functionalities
to
those
clients
just
to
reuse
and
to
diverge
on
existing
features
on
this
on
its
own.
P
The
on
on
this
on
it
on
this
note,
that
is
the
leveraging
on
existing
tools
to
discover
the
the
dot
server
is
appropriate.
That
that's,
why
we
think
that's
using
the
straightforward
in
a
material
for
that
case
would
be
will
be
recommended,
but
in
the
the
other
calendar
we
see
that
all
of
them,
or
almost
all
the
use
cases
are
using
the
CPE.
P
And
if
you
have
the
network
providers
today,
we
are
provisioning
on
providing
configuration
information
to
to
the
CP
which
it
it
will
attach
the
network,
and
we
are
just
using
DHCP
and
other
tools,
TR,
16:9
and
so
on-
to
provision
the
CP.
So
it
is
just
intuitive
for
us,
as
a
provider
just
to
reuse
these
tools
to
provide
dots
identity
using
this
existing
tool.
That's
why
the
use
of
the
DCP
may
be
appropriate
for
this
case.
P
So
if
we
suck,
if
we
do
a
summary
of
this
Aleph,
we
consider
all
the
use
cases
each
of
them-
you
have
some
specifically
there
and
know
of
the
tools
that
I
mentioned
the
use
of
the
mdns
for
instances
of
Innoko.
The
use
of
DHCP
does
not
does
not
that
not
solve
all
the
problem
for
all
the
use
cases.
So
each
of
these
use
cases
have
some
its
own
unique
requirement.
So
it
is
unlikely
that
one
signal
solution
should
is
to
be
recommended
for
Ford.
For
that.
P
So
that's
why
we
we
we
are
proposing
this
unified
discovery,
discovery
method
in
which
we
are
don't
find
at
least
year
four
steps
to
be
followed
by
the
dots
client.
The
first
one
is
that
simple
that
to
assume
that
this
is
something
which
is
explicitly
configure
to
the
dots
client.
If
you
have
some
day
which
is
configured
just
go,
go
go
with
your
local
configuration.
This
low
configuration
can
be
manual,
can
be
static
or
can
be
written
by
DHCP.
Once
you
have
this
information
with
50,
you
just
proceed
with
with
the
service
resolution.
P
The
service
solution
will
provide
you
with
the
other
information,
for
instance,
to
discover
whether
you
you
have
the
same
IP
address
for
both
the
data
channel
or
the
signal
Channel
or
whether
you
use
TCP
recipients
on
this
kind
of
stuff.
And
if
the
service
will
restore
files,
then
you
can
use
other
tools
which
are
available
locally.
For
instance,
you
can
use
DNS
service
the
discovery
or
mdns
at
the
end
of
the
day.
P
If
all
of
these
steps
fail,
then
you
you
can
use
the
the
unipass
address
as
a
last
resort
and
in
the
document
we
are
not
required
or
recommended
in
the
order
in
which
you
can
proceed
for
the
discovery,
just
an
implementation,
we
decide
to
run
all
of
them
separately
or
just
stop
at,
for
instance,
for
the
first
one
and
doesn't
implement
the
others.
So
this
is
this
is
the
main
contribution
from
this
document
to
say
that
it
is.
P
There
is
no
justification
to
have
to
have
one
single
mechanism
to
discover
or
thicken
the
disk
servers
to
those
clients.
It
is
all
it
is
likely
that
we
will
need
multiple
tools
to
discover
this
information
to
provide
this
client,
and
it
is
good
to
have
for
for
deterministic
behavior
of
those
clients
to
have
a
unified
algorithm
that
will
be
followed
by
this
distance
implemented
implementation,
and
this
is
what
we
are
providing
while
providing
here.
Yes,
Rolla
Roland.
C
Avanzar
Burnett
works.
I
have
a
question.
There's
a
lot
of
discussion
about
anycast
here.
It
seems
that
there's
an
assumption
that
any
caste
is
going
to
be
a
pervasive
addressing
mechanism
for
dot
servers.
What
is
an
assumption
based
upon
oh,
there
seems
to
be
an
assumption
that
any
caste
is
going
to
be
a
pervasive
or
very
common.
P
C
P
C
P
In
the
draft
they
are
separated
into
billets
different,
the
static
one
on
the
other
one
to
dynamic
one
with
the
cheapy
and
so
on.
Yeah
yeah,
so
I
won't
go
into
details.
How
all
these
mechanic,
the
specification
of,
if
your
option
dismiss
regression
or
all
the
other
tools
which
you
can
find
more
details
on
in
the
draft-
and
this
is
my
last
slide
slide
sorry
to
have
some
discussion
on
the
only
draft
and
how
to
proceed
for
the
next
step.
D
J
A
A
P
H
P
Q
Martin,
arson
and
cocl,
so
this
may
be
out
of
ignorance
because
I'm
pretty
new
to
dots,
but
is
there
any
mechanism
foreseen
for
bootstrapping
trust
because
otherwise
like
doing
automatic
discovery
and
then
doing
out-of-band
or
manual,
confirmation
of
trust
seems
a
bit
of
them
well
and
why?
Wouldn't
you
fear.
P
It
yeah
this
is
really
a
very
good
point
and
we
have
that
effect
in
the
Hindi
draft
that
we
for
the
the
cpu's
case,
what
we
are
considered
as
we
are
leveraging
on
existing
the
practice
we
have
result
for
sip
server,
services
and
so
on
is
that
the
the
trust
is
is
manufactured
with
UCP.
So
you
have
this
shipped
when
you
have
the
device
which
is
manufactured
by
the
provider.
P
But
if
you
are
in
other
situation
in
which
you
you
cannot
allow
such
practice,
what
we
discuss
in
the
Security
section
of
the
document
is
that
you
can
use
the
risk
I,
which
is
the
anima,
and
you
must
have
to
to
discover
and
to
establish,
to
establish
the
trust
automatically.
But
to
do
that,
you
need
to
start
from
the
name
of
the
server
and
then
to
run
all
the
authentication
afterwards.
So
we
had
both,
which
is
discussed
in
the
draft,
and
if
you
read
it,
you
find
this
kind
of
details
there.
D
I
Ok,
hello,
everyone,
so
I
will
present
the
last
evolution
of
our
draft,
so
just
to
remind
so
the
change.
So
the
first
initial
idea
was
to
use
hot,
buy
up
option
in
ipv6,
so
basically
to
store
information
and
then
remember
the
information
and
on
path.
So
we
presented
a
different
place,
including
of
course,
those
up
second
six
months.
So
we
understand
that,
even
if
we
restrict
ourselves
to
the
let
say
in
trudeau
menus
case
I
mean
some
issues,
so
it's
not
recommended
actually
with
a
new
version
to
use
it
and
to
have
a
new
proposition.
I
So
our
proposition.
Basically,
no.
We
want
you
to
keep
the
original
ID
of
where
and
when
we
come
with
ipv6,
which
originally
was
12.
Let's
say
a
safeguard
mechanism
where
you
are
not
able
to
reach
from
the
desk
E&Z
that
server
to
a
signal
the
attack.
So
we
want
you
to
keep
this
original
ID,
but
we
so
in
these
versions.
We
want
don't
want
to
necessarily
add
new
to
a
new
protocol
like
we
proposed
before.
I
What
we
need
anyway
in
watch,
is
similar
to
what
ratified,
to
have
something
it's
synchronous,
meaning
that
we
don't
in
this
oxygen
americanism.
So
I
really
want
to
emphasize
that
it's
not
be
used
as
a
first
mechanism
for
signaling.
It
just
a
ways
that,
for
instance,
in
Pachuca
in
case,
for
example,
if
you
use
it
a
bit,
you
don't
realize
that
the
client
is
not
responding
in,
can
retrieve
soft
information.
So
we
want
basically
to
have
this
kind
of
repository
where
so
that
doc,
playin
can
infirm
the
servers
as
a
resident
can
retrieve
information.
I
But
it's
not
confirm
yet
can
push
some
informations
that
if
the
attack
occurs
in
the
client
is
not
able
to
signal
the
attack
afterwards,
the
sûreté
can
still
retrieve
some
information
that
can
get
critters
and
in
finish
and
as
I
say,
it's
independent
of
the
boss
protocol
between
the
client
and
the
repository
that
we
call
now
and
from
the
successor
and
by
the
case.
That's
it
for
me.
I
just
yeah
I
want
to
hear
something
back
and
son
Roland.
C
C
I
C
I'm
still
not
sure,
I
follow
because
again,
if
I
want
to
ensure
that
the
communications
channel
is
available
and
clear,
I
establish
a
completely
parallel
and
AB
in
communications
channel,
write
communications
path
right
for
dots
as
this
being
discussed
today
in
the
architecture
draft.
So
why
would
I
want
to
use
this
specific
mechanism
for
an
additional
auxiliary
signaling
mechanism
in
the
in
band
path?
I,
don't
understand
that.
I
I
mean
in
the
sense
that,
in
the
case
of
the
attack,
the
current
may
not
be
a
bit
even
to
send
again
it's
a
single
information,
but
some
information
is
already
stored
in
the
repositories
at
the
Zurich
and
which
so
maybe
the
client.
Basically,
now
is
the
case
of
the
kind.
It's
completely
isolated.
The
Sarika
still
retrieve
some
information.
D
Yeah
not
now
but
I,
think
I'm
kind
of
so
Toby
has
gone
wrong.
Bob
a
working
group
chair,
hired
off
I'm
also
confused
a
little
bit.
It's
like
I
can
see.
Maybe
I
want
to
upload
information
to
a
server
in
case
I'm
going
death
or
silent.
Yes,
I
can
see
that
I'm
not
quite
clear
on
the,
but
this
student
is
my
own
stupidity
I'm,
not
quite
clear.
What's
the
benefit
of
uploading
it
somewhere
else,
instead
of
uploading
it
to
the
server
and
so
I'm
not
grasping
what
what
you
try
to
solve.
I
Yeah,
so
the
original
am
I
really
so
it
let's
say
Z
Z
original
idea
that
we
have
is
that,
for
instance,
let's
say
I
have
these
informations
that
you
multiply
different
places
that
you
can
still
retrieve
and
I.
Don't
know
if
the
server
in
my
opinion
should
be
only
be,
let's
say
to
say:
reach
are
requested
when
you're
really
need
mitigation,
it's
what
I
understand,
but
so.
B
D
Which
case
I
would
inform
all
the
servers?
Yes,
okay,
if
I
go
silent,
do
this
so
I
don't
see
a
strong
need
to
have
another
repository
of
which
I'm
not
sure
that
the
other
service
will
see
it.
If
something
goes
wrong,
so
I'm
not
I
can
see.
This
is
interesting
when
I'm
I'm
I'm,
not
so
seeing
it
as
a
strong
requirement
personally
again
to
be
asked.
When
I'm
working
group
chair
chair
head
off.
Okay,
all
the.
A
Okay,
thank
you.
So
this
brings
us
to
the
end
of
our
formal,
formal
agenda.
So
just
to
recap,
where
we
stood
based
on
all
the
discussion
going
through
the
architectural
eustachian
requirements
document,
we
were
tentatively
thinking
that
we
would
be
able
to
go
to
work.
Call
what
we
heard
during
the
design
team
meetings
and
through
this
session
is
that
we
need
at
least
one
more
version
across
all
three
of
those
documents
to
to
consider
ourselves
done
so
not
declaring
working
last
call
there's
issues
to
kind
of
work
out,
but
please
bring
issues.
A
If
you
have
them
to
the
mailing
list,
we
got
requirements
from
the
hackathon
that
may
suggest
changes.
Those
things
should
be
come
through
as
well,
and
then
overall,
we
need
to
think
about
based
on
what
Kathleen
was
suggesting,
how
we
might
want
to
be
packaging
kind
of
those
documents.
We've
talked
about
it
before
and
we
can
bring
up
that
topic
again.
Adding.
D
One
note
I
think
the
perception
from
looking
at
the
documents
progress
the
requirements
draft
seemed
to
be
closest
to
working
good
last
call.
So
if
you
have
issues
with
it,
please
post
them
within
the
next
two
to
three
weeks,
because
like
by
that
time,
I
could
imagine
that
we
might
come
close
to.
They
have
closed
everything
other
and
then
we
would
initiate
working
group
called
for
the
requirements
first.
A
My
next
bullet
was,
we
will
absolutely
hold
an
interim
reading.
We've
been
finding
them
to
be
very
successful,
so
we'll
put
something
on
the
calendar
not
half
way
between
now
and
and
Singapore.
If
there's
a
desire
for
design
team
meetings
in
between
that
or
multiple
interim
meetings,
kind
of,
let
the
chairs
know
the
shares
know
we
can
kind
of
figure
it
out,
but
again
somewhere
halfway
between
now
in
Singapore,
which
historically
was
October
early
October
or
late
September
yeah.
D
A
And
the
last
thing
to
point
out
is:
we
saw
five
interested
parties
for
the
hackathon.
We
will
not
name
them.
We're
very
excited
that
there
are
five.
We
would
like
to
plan
kind
of
that.
That
will
start
the
discussion
before
the
interim
meeting
about
what
we
might
do,
because
experience
suggests
that
there's
can
only
time
about
scoping
and
preparing
what
will
be
done
to
make
that
time
most
most
productive.
So
if
you
did
not
voice
yourself
as
one
of
those
five,
please
please
kind
of.
D
Thank
you
very
much
everybody
for
coming
great
great
presentations,
and
so
we
will
see
you
all
in
Singapore.
Thank
you
and
have
a
good
evening.
Bye,
oh
and
last
thing
remember
bits
and
bytes.
There
will
be
a
presentation
of
the
dots
implementation
and
blue
sheets
who
has
who
has
not
signed
blue
sheets.
Yet,
can
you
move
the
blue
sheets
over
to
the
people?
Okay,
please.
Thank
you.
Thank
you.
Everyone.