►
From YouTube: IETF101-DOTS-20180320-1550
Description
DOTS meeting session at IETF101
2018/03/20 1550
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
A
A
Sir
next
slide
so
just
to
make
sure
you've
seen
this
properly
in
other
meetings,
but
the
note
well
applies-
and
this
is
new
text
next
slide.
So
we
have
the
blue
sheets
going
around
Frank
is
taking
our
notes.
Thank
you,
and
do
we
have
a
jabber
scribe?
Who
could
we
have
a
jabber
scribe,
or
would
anyone
volunteer?
A
Okay,
then
I
can
talk
to
you,
so
we
we
pulled
it
pulled
an
agenda
together.
We're
gonna
be
talking
early
on
about
some
of
the
implementation
experience.
What
happened
at
the
hackathon
and
some
individual
vendors
talking
about
implementation
reports,
we'll
talk
protocol
drafts
and
then
we'll
get
to
a
few
of
the
informational
zhh,
and
we
have
enough
time
for
some
open
mic
as
well.
Would
anyone
like
to
bash
this
agenda?
A
Okay
with
that
we'll
proceed
so
next
slide,
please
to
give
an
update
of
what's
happening
with
the
workgroup.
Since
we
last
got
together,
the
drafts
have
seen
updates,
which
is
great.
We
had
a
virtual
interim
meeting
on
February
7th.
We
did
a
working
group
last
call
on
requirements
in
December.
We
closed
it
in
January.
A
number
of
updates
occurred
just
to
make
sure
that
that
everything
that
needs
to
be
in
the
is
in
there
we
will
be
starting
a
short
second
working
group
last
call
on
requirements.
A
A
Also
exciting
news
is
and
we're
gonna
have
a
presentation
on
it.
Is
that
there's
a
new
new
implementation.
That's
emerged
from
our
bure
networks
and
they're
gonna
be
talking
about
that
next
slide.
So
schedule-wise
milestones
have
changed.
We
slipped
on
all
of
them,
so
we
pushed
everything
kind
of
forward.
So
we
are
at
the
London
meeting.
We
are
going
to
issue
the
working
group
last
call
on
the
requirements
document.
That's
going
to
get
us
into
early
April.
We
want
a
host
of
virtual
interim
meeting
at
the
end
of
April.
A
That's
what
you
see
there
and
that'll
be
halfway
between
London
and
Montreal.
Otherwise,
we're
notionally
also
planning
to
get
a
number
of
our
informational,
x'.
Wrapped
up
April
may
be
a
little
ambitious,
probably
in
in
in
April
of
some
kind.
We're
gonna
do
working
group
last
calls
there
and
we
have
a
marker
out
for
the
August
time
frame
for
the
two
protocol
drafts
to
working
for
a
blast
call.
A
E
Yep
I
think
I
mean
she's,
complimented
communication
reduction
I'd
like
to
talk
about
IETF
axonal
report,
which
was
on
last
weekend,
and
that
is
thoughts
interrupt
first
of
all,
I
track
to
adjourn
for
helping
making
this
report
an
x-ray.
Please,
okay,
here
here
is
a
our
action
plan.
We
tested
the
interoperability
between
Indian
implementations
in
order
to
see
the
maturity
of
these
classifications
of
dots
protocol.
Now
we
have
four
implementations:
one
is
entity
dot
from
entity
which
is
always
a
so
now.
It's
called
is
open
to
the
public
and
the
rest.
E
Three
proprietary
implementations
from
three
different
vendors
and
she
she
grips
John
is
from
hunt
over.
They
couldn't
attend
the
hackathon
at
this
time,
but
under
you
from
ABBA
will
do
his
presentation.
After
this
about
the
result
of
the
internal
testing,
the
CRO
raise
implementation,
which
is
based
on
a
fifty
dots.
Then
they
are
adding
their
own
futures
are
the
OSS
right,
please
so?
Ok,
they
hacked
own
plan.
E
E
First,
we
enumerated
the
features
of
dots.
You
know
each
other
at
each
other
then
checked
if
it
is
supported
by
each
implementations.
This
list
may
be
helpful
for
you
for
you,
because
the
drugs
are
getting
a
little
bit
longer,
so
it
makes
easy
to
understand
what
features
are
there
and
whether
they
are
supported
now
or
not?
E
One
achievement
is
that
entity
dot
was
updated
to
support
pfk
mode
of
DTLS
during
the
hackathon,
and
it
was
checked
with
John's
implementation
next
slide.
Please
so
then
we
case
feed
special
configuration,
the
mitigation
request,
operation
and
cut
pink
each
other.
Unfortunately,
we
couldn't
do
the
test
against
Chloe's
implementation,
but
I
hope
they
can
talk
each
other
because
it
is
based
on
a
tiki
dots,
except
that,
as
you
see,
the
test
result
was
all
green.
In
addition,
we
did
get
and
delete
operations
of
Education
request
with
MIT
and
CID
in
you
are
right
path.
E
E
So
here
is
where
we
are,
as
you
know,
dot
protocol
protect
the
internet
from
DDoS
attacks
by
making
this
by
making
DDoS
protection
more
effective
with
programmatic
feature
capabilities,
then
we
confirmed
that
we
can
do
cooperative
DDoS
protection
between
at
least
two
independent
implementations
next
release.
So
this
screen
capture
is
one
of
the
most
impressive
one
of
the
hackathon.
E
We
did
mediation
requests
from
OSS,
not
quiet,
which
is
entity
dots
to
prepare
every
dot,
server
sec
groups,
and
you
may
see
that
the
protection
protection
of
an
IP
address
is
successfully
registered
to
the
server
and
which
is
actually
well
known.
Ddos
protection,
our
players
Lido's
secure,
also
a
we
did:
educational
requests
from
ACC
groups,
dot,
client
to
educators,
thought
server,
and
also
it
worked
there.
E
So
here
shows
what
we
learned
during
the
hackathon,
so
I
assure
you
that
we
can
meet
the
expectation
for
dot
protocol
from
market,
so
it
means
the
draft
signal.
Chara
specification
is
almost
stable
in
the
hackathon.
We
taste
is
based
on
the
latest
specification
and
it
is
proven
to
work.
That
must
be
a
good
news
for
you
and
we
discussed
and
qualified
a
lot
about.
The
current
draft
text
actually
provided
the
feedback
to
the
working
groups
and
also
we
discussed
about
new
new
features
which
could
be
added
to
the
future
thoughts
specifications.
E
E
The
third
one
is
a
PKI
and
esk
mode
on
TTLs,
the
last
one
needs
to
your
ID
and
meid
in
URL
path
regarding
to
the
gate,
wave
functions,
entity,
don't
cry
on
traffic
to
a
sushi
group,
thoughts,
gateway,
relayed
to
entity,
dot,
server
with
city
ID
addition,
then,
the
usage
of
city
ID,
is
now
under
discussion,
because
she
you
see
you
I,
did
not
see
really
shiridi
is
globally
unique.
So,
finally,
this
new
dot
server
can
create
resource
location
only
by
this
GRE.
So
the
purpose
of
introducing
the
CD
ID
of
gateway
is
really
obvious.
E
Attr
this
is
your
group
leader,
intro
test
internally
three
times
before
the
hackathons.
So
in
preparation
for
the
hackathon,
we
agreed
on
the
trying,
the
with
the
latest
spec
73
later
on
updated
models
so
as
to
comply
with
that
also
from
our
identity
added
copying
capability,
and
we
made
many
fixes
of
the
code
on
both
sides.
The
most
of
the
fixes
are
related
to
encoding
and
decoding
of
Shiva
format
and
John
is
now
actively
contributing
to
recode
library.
So
a
live
Corp
function
is
enhanced
and
extended.
E
F
Yeah,
just
in
sort
of
summer
I
just
really
would
like
to
cite
the
work.
That's
done
on
Antigua
dots
in
terms
of
a
base
open
source,
because
on
that,
as
it's
being
developed,
that
will
then
help
other
people
do
implementations
and
all
the
rest
of
our
particular
NCC.
Gruffudd
is
proprietary,
but
that's
fine
because
it
creates
differences,
but
it's
just
the
thanks
of
you
know
the
likes
of
you.
What
the
work
you're
doing
on
that,
because
that
is
just
creating
a
stable
platform
that
we
can
then
base
everything
else
off
on.
G
F
C
Yes,
kono
omoi,
we
working
group
chair
head
off
so
I
think
this
is
awesome.
I'm
super
happy
to
see
these
interoperability
tests
happening
and
now
that
we
have
two
implementations,
that's
great
the
you
you
asked
for
whether
there
are
any
questions.
I
have
a
question
which
is
potentially
more
be
more
later.
The
other
implementers,
given
that
we
have
these
two
interval
T
tests.
Now
so
can
we
expect
for
the
next
hackathon
to
maybe
have
three
or
four
implementations
doing
these
so
that
we
can
fill
this
matrix
completely?
That
would
be
awesome.
I
E
Is
not
supported
and
also
yeah.
There
are
many
functionality.
Lack
of
authority
go
implementation,
of
course,
so
and
also
I
think
we've
got
a
the
most
referenced
limitation
of
crops,
so
I,
so
I
decided
we
should
is
live
crop
because
yeah
yeah,
because
yeah
it
is
supporting
more
function.
I'll
than
other
libraries.
A
I
Right,
so
this
is
a
pretty
brief
implementation
report
on
the
the
work
in
progress.
We've
got
for
an
internal
dot,
server
and
client,
which
I
am
hoping
we'll
be
able
to
see
as
open
source
in
the
relatively
near
future,
but
I
don't
want
to
make
any
promises
yet
anyway,
we'll
move
on
next
slide
all
right.
So
this
is
a
partial
implementation
of
the
vision.
17
of
the
signal
channel
draft
internally,
we
I
have
a
working,
dots,
client
and
server
talking
to
each
other
with
PKI
and
PSP
mutual
authentication.
I
It
is
using
ipv4
and
ipv6,
not
happy
eyeballs
at
this
point
yet
and
I've
been
able
to
do
largely
local
Internet,
interrupts
testing
with
entities
implementation
and
including
over
the
weekend
some
testing,
based
on
the
updated
version
that
came
out
of
the
hackathon,
with
a
little
bit
of
assistance
from
economy.
Next
slide
please.
I
So
there
are
a
number
of
challenges
we've
run
into
partly
in
the
interest
of
diversity.
I
chose
to
use
Python
and
there
are
a
number
of
Python
co-op
frameworks,
but
only
one
appears
to
actually
support
DTLS.
A
lot
of
the
implementations
out
there
make
a
reference
to
you
know
coming
soon
or
you
know,
DTLS
is
not
supported.
A
I/o
co-op
is
using
tiny
detail
s,
but
tiny
DTLS
itself
turns
out
to
be
limited
in
a
number
of
ways.
Next
slide,
there
aren't
really
any
good
Python
DTLS
implementations
that
I
was
able
to
find
tiny.
I
Dtls
has
been
wrapped
in
a
project
called
DTLS
socket,
but
it's
limited
to
PSK
and
the
the
project
maintainers
have
made
it
explicit
that
they
are
not
planning
to
support
PKI.
So
that
restricts
you
right
out
of
the
bat
and
the
it's
only
supporting
CCM
aid
in
the
the
cipher
suites,
which
also
restricts
the
the
particular
choices
you
have
when
you're
trying
to
communicate
between
the
dots
clan
and
server.
So
I
subsequently
have
rapped
embed
TLS
with
syphon
and
I.
I
As
like
kind
of
a
said
about
running
into
limitations,
with
with
a
go,
coop
I've
run
into
some
limitations
with
a
IO
co-op.
For
example,
the
pink
handling
is
unavailable
to
the
application
currently,
which
means
that
we
aren't
able
to
do
the
sort
of
Deadman
switch
that
we've
talked
about
and,
for
example,
the
architecture
draft.
An
on
handling
of
error
responses
causes
an
exception.
I
So
I
was
running
into
this
with
the
the
go
dots
implementation,
where,
if
you
make
a
request
that
causes
an
error
than
you
know,
a
IO
co-op
would
would
back-trace
and
TCP
support
in
a
co-op
is
currently
very
rudimentary.
I
do
have
a
selection
of
patches
that
I'll
be
planning
it
upstream,
in
also
the
hope
of
adding
support
for
the
new
DTLS
module.
I
Configuration
configuration
stuff
is
progress,
I'm
hoping
I'll
have
something
working
on
are
certain
and
I
began
testing.
You
can
see
groups,
public
server
and
hopefully
I'll
be
able
to
coordinate
with
with
John
Moore
I've
run
into
some
problems
actually
at
the
handshake
handshake
stage,
but
hopefully
I'll
be
able
to
overcome
that
pretty
quickly.
Next,
like
that,
covers
it
for
them.
K
Under
Frank
I,
just
to
have
our
comments
comment
on
this,
our
different
kind
of
for
das
demo
and
how
to
interoperate
ur
between
their
encounter
I
think
we
have
several
rounds
of
who
interpreted
test
in
between
different
vendors
and
companies,
but
I
haven't
seen
we
test
our
use.
Cases
such
as,
if
the
network
link
is
under
the
you
know,
under
the
very
bad
situation,
is
a
very
congested
by
the
attack
traffic
and
how
our
protocol
can
really
work.
I
I
strongly
agree
with
you,
I
think
that's
very
important,
especially
watching
the
the
network
traffic
during
the
detail
is
handshake
for
the
PKI
forms
of
authentication.
So
there's
a
lot
of
data
going
back
and
forth
and
I
know.
The
draft
covers
different
ways
to
try
to
reduce
the
amount
of
traffic
going
back
and
forth,
especially
at
the
handshake
stage.
But
doing
some
testing
under
attack
conditions
would
be
very
valuable.
I
think
I
can
see
John
lining
up
there.
F
Yeah
and
you
and
within
lib
co-op,
there's
the
ability
to
be
able
to
set
things
up
as
lossy
and
we've
actually
done
some
stress
testing,
which
fans
and
how
should
we
put
undesirable
features
in
Lib
co-op,
which
have
now
been
fixed
so
yeah.
We
certainly
need
to
be
able
continue
doing
that
kind
of
stress
testing
to
work
things
through
in
terms
of
interoperability.
Yeah
I
saw
you
come
onto
our
sister
Manju
and
there
seems
to
be
some
greed
failure.
I
guess
I
may
be
covering
it
to
my
next
couple
of
slides.
A
J
F
F
Yeah,
so
sorry
about
this.
Basically,
this
is
not
so
much
an
implementation,
but
as
status
of
what
is
available
there
should
one
want
to
do
interrupt
tests
find
out
what's
going
on
there
so
informations
here
in
the
slide
so
and
to
access
a
server,
it's
hosted
server,
DDoS,
secure
net
and
we're
now
listening
on
both
ports,
four
six,
four
six,
which
have
not
yet
been
officially
approved,
as
well
as
the
type
s
56
84
ports.
We
also
have
data
channel
as
well.
F
So
if
you
were
to
come
in
and
play
with
the
data
channel
and
see
what
happens,
there
is
support
for
that
as
well.
The
requirements
on
the
data
Channel
is
that
sni
is
set
within
the
initial
setup
sessions
so
that
we
steer
the
traffic
specifically
having
hit
bought
for
flee
into
the
dots
environment
as
opposed
to
there's
another
environment.
On
that
same
port,
though
terms
of
PK
are
certificates.
We're
currently
set
up
to
use
the
entity,
dots,
client
certificates.
F
You
can
use
one
of
those
we
can
provide
others
if
you
or
lots
of
people
come
in
at
the
same
time,
using
the
same
certificate
which
today
we
allow
in
the
future,
we
probably
won't
you'll
get.
You
know,
someone
said
mitigate
a
and
then
someone
comes
in
a
beam
will
see
a
AIDS
being
mitigated
yeah,
it's
a
bit
a
bit
of
confusion,
but
we
can
provide
other
certificates
sitting
in
there.
Another
requirement
that
we
have
is
that
you
identify
on
the
client.
F
What
is
your
CA
certificate
because
we're
doing
mutual
authentication
by
having
a
common
CA
certificate
between
the
client
and
the
server
terms
of
pre
shaky?
If
you
want
to
play
with
that
as
well
keys,
1,
2,
3,
4,
5,
6,
7,
8
and
the
identifies
identity
for
dots,
we
can
add
in
extra
ones,
but
that's
a
starting
place
of.
What's
in
there,
we
don't
care
whether
you
come
in
with
UDP
or
TCP.
Both
are
fully
supported.
We
actually
have
happy
eyeballs
supported
in
terms
of
our
so
our
client
talking
to
an
external
server.
F
We
have
a
restricted
set
of
ID's
that
can
be
allowed
to
be
mitigated.
So
if
you
try
and
say,
I
want
to
mitigate
an
IP
outside
of
what's
down
there,
you'll
get
back
a
suitable
error
message.
If
you
choose
one
of
those,
those
particular
ones
will
get
done
so
again,
it
allows
you
to
do
and
a
variety
testing
we
actually
have
for
one
of
those
IPs.
F
There
will
be
incrementing
statistics
that
have
reported
back
to
you
if
you
want
to
sort
test
out
your
status
of
what
is
happening
on
the
mitigation,
so
we
have
that
capability
there
terms
of
setting
up
dots
clients.
We
can
talk
to
your
service
somewhere.
All
I
need
to
know
is:
where
is
it
and
what
is
it
listening
on
information
here?
So
I'll
need
a
client
certificate,
maybe
or
if
we're
using
PSK
I
need
that
kind
of
information
to
go
out
and
deal
with
your
probe.
It's
tough.
F
F
So
we
just
join
the
two
together
for
relaying
stuff
to
do,
and
so
that
gives
us
the
abilities
that,
based
on
two
different
client
identifies
you
can
either
come
to
us,
can
be
gateway
through
to
a
server
or
you
can
come
to
us
and
just
talk
directly
as
a
service.
So
you
have
again
have
the
flexibility
of
being
able
to
test
things
out.
F
Current
functionality,
we
are
I,
won't,
say
100%
supporting
the
17,
but
it's
pretty
complete.
There
is
a
couple
of
minor
exceptions
which
are
coming
out
in
the
18
when
we
generate
CEO,
IDs
and
m/m
IDs,
we
actually
put
them
into
the
UI
path,
but
so
that's
when
we
as
a
client
talking
to
you
as
a
server,
but
we
as
a
server
will
accept
it
both
as
a
path
or
a
query.
So
we
support
the
old,
true
17
or
the
potential
18
sitting
in
there.
F
A
A
A
Okay,
I'm,
taking
that
as
a
no
that
there
are
no
other
implementations
here,
represented
that
they
want
to
talk
at
the
working
group.
So
that
closes
the
time
we
have
to
talk
about
the
implementation
work
to
date,
and
so
now,
let's
talk
about
the
protocols
themselves
there
we
could
that
we
spent
the
last
half
hour
and
talking
about
the
implementation
of
so
made
your
up
Oh
tears
up.
Okay,
no
I
made
a
mistake
on
the
agenda
tears
up
so
we're
talking
about
the
data
in
the
signal
draft.
A
L
Thanks
the
next
one
of
these
issues
was
discussed
in
the
mailing
list
and
was
raised
by
John
that
we
had
a
problem
with
multiple
gateways
or
a
single
gateway
between
the
dots,
client
and
thought
server,
where
it
miss
configuration
or
DNS
cache
poisoning
could
cause
infinite
loops
to
handle
that
we
had
introduced
a
new
co-op
option
by
the
name
hop
limit.
It
was
added
as
a
co-op
option
and
not
as
a
parameter
because
to
accommodate
the
various
request
types,
especially
the
gate
requests
which
does
not
have
a
body
so
for
that
we
had
also.
L
We
had
to
also
update
it.
The
ionic
Constitution
section
to
us
in
a
new
code
point
for
the
coop
option
and
also
a
new
header
code
5.06
in
case,
if
the
hop
limit
reaches
0
so
and
it'll
get
be
sent
back
to
the
client
and
the
intermediate
gateways
could
see
that
the
hop
limit
has
reached
zero
and
could
get
infinite
loop.
L
So
we
wanted
to
clarify
and
update
this
graph
to
say
that,
because
dot
signal
configuration
requires
a
negotiation
of
the
configuration
and
message
transmission
parameters,
so
it's
been
updated
to
a
flow
type
to
be
inconsistent
with
the
existing
implementations
yeah.
This
was
one
important
bug
that
was
raised
by
John.
That
currently
rc7
to
phi2
has
a
limitation
that
only
one
token
can
be
bind
per
client
or
destination
pair,
which
pretty
much
restricts.
L
So
to
address
that
Matt
has
already
raised
an
errata
with
the
RFC
7
to
phi2,
to
fix
that,
and
we
also
have
fixed
the
draft
to
use
to
convey
cui
D
the
client
domain
identifier
and
the
medication
IDM
the
URI
path
parameter
rather
than
a
you
are
equity,
so
we
have
any
unique
resources
identified
and
each
resource
would
be
uniquely
identified
by
a
token
and
the
client
simultaneously
getting
get
consolidated.
Responses
for
multiple
medication
requests.
L
Message
this
was
an
overlook
that
when
we
were
going
through,
we
did
not
look
into
the
max
adoption
and
thanks
to
John
we
had
in
config
interval
define
for
configuration,
configuration
negotiation
wire.
The
configure
interval
tells
the
client
went
to
contact
the
server
to
get
the
latest
configuration
from
the
server.
L
But
then
there
is
a
max
adoption
in
coop,
which
pretty
much
says
that
if
max
is
not
defined
or
written,
the
default
value
is
60
and
in
which
case
the
client
has
to
frequently
every
60
seconds
has
to
contact
the
server
for
a
new
configuration
change.
So
we
have
updated
the
draft
that
instead
of
config
interval,
we
would
be
using
the
max
age
that
would
make
the
implementation
pretty
straightforward.
That
would
leverage
the
existing
option
and
then
to
avoid
frequent
neuron
trips
between
the
client
and
server.
The
value
of
zero
is
not
recommended
to
power.
L
32
minus
one
is
for
infinite
lifetime
and
find
a
client
which
is
misbehaving
that
does
not
contact
the
server
after
the
expiry
of
max
age
would
be
considered
a
bad
client
and
would
be
disconnected
by
the
server.
The
exception
to
those
rules
are
wire.
The
client
is
subjected
to
a
DDoS
attack
and
it
cannot
reach
the
server
in
this
case.
The
server
can
make
an
exception
and
ignore
not
receiving
request
refresh
request
from
the
client
and
continue
to
maintain
the
detail.
L
L
It
was
also
conveyed
that
the
configuration
and
message
transmission
parameters
can
either
be
present
in
the
mitigating
config
or
the
ideal
config
containers
and
need
not
be
present
in
both
thanks
to
our
area
director.
We
hope
she
approved
for
six
for
six
as
the
port
for
dots
and
met,
fill
the
form
and
it's
being
sent
by
our
of
chest,
and
we
are
waiting
for
response
from
miner
for
an
permanent
allocation,
so
this
work
is
under
progress
and
the
working
copy.
A
Service,
our
if
I,
can
interrupt
based
on
the
eye
and
our
allocation.
That
is
all
correct,
but
we
want
to
emphasize
it's
the
chairs
that
have
actually
dropped
the
ball.
The
ad
have
cleared
the
approval
we
are
in
contact
with
Ayana.
We
just
have
not
submitted
the
input
to
get
that
early
allocation,
but
we
are
approved
for
that
early
allocations.
There
is
no
IDI
action.
G
L
I
I
Some
of
my
experiences,
interacting
with
the
the
other
implementations,
makes
me
wonder
if
we
need
to
be
a
little
bit
more
explicit
about
what
is
minimally
required
there,
particularly
with
PSK
I,
don't
know
that
we
want
to
be
recommending
the
choices.
For
example,
the
CCM,
a
cipher
suites
that
tiny
DTLS
is,
is
offering
and
then
separately,
although
this
might
be
a
little
bit
of
a
distraction
at
this
point,
so
I'm
interested
to
hear
some
comments.
I
There
was
a
period
where
we
made
some
adjustments
to
the
requirements
draft
based
on
some
feedback
that
we
wanted
to
leave
space
potentially
for
the
use
of
quick
in
future
revisions,
which
has
been
wondering
if
we
want
to
identify
specific
requests
which
are
currently
just
referred
to.
As
you
know,
coop
get
put
and
so
on
as
specific
message
types.
But
beyond
that,
I
don't
have
any
further
comments
on
the
current
work.
L
Yeah
regarding
quick,
we
looked
into
quick
and
quick.
Basically
in
today's
running
is
using
HTTP
on
top
of
that,
and
you
could
also
use
corporate
with
quick
and
coop.
It
would
add.
Large
overhead
and
web
is
pretty
much
using
reliable
transmission
today
for
most
of
its
messages.
So
do
we
really
need
that
and
co-op
is
pretty
much
giving
us
both
the
flexibility
of
being
reliable
or
unreliable?
That's
not
the
way
Vic
is
going
towards,
and
it's
not
designed
for
running
in
a
constrained
anyway.
Wrong
right,
like
like
co-op,
is
being
designed.
L
So
we
can
have
that
discussion.
Yes,
regarding
the
cypher
suits
what
what
I
have
a
specific
section
to
discuss
the
TTLs
profile
and
what
what
mandatory
cypher
suits
the
client
and
server
should
implement.
We
can
go
or
that
and
see
if
any
changes
to
be
done
there,
but
it's
pretty
much
what
the
latest
are
FCC
what's
I
pursue
should
be
supported
and
that's
what
we're
just
following
right.
M
C
Okay,
so
there
seem
to
be
no
further
questions,
so
then
a
question
from
the
chairs,
so
there
have
been.
We
have
heard
several
implementations
and
at
least
feedback
I
saw
and
implementations
was
like.
Oh
actually,
they
were
built
on
17
and
they
were
relatively
consistent,
so
yeah.
Actually
the
question
would
be:
what's
the
opinion
in
the
room?
Is
this
draft
close
to
ready
for
working
group
last
call?
Are
there
some
issues
still
left
that
we
need
more
discussion
based
on
the
implementations?
You
did.
C
A
F
I
think
subject
2-18
rather
than
that
17.
Yes,
we
are
in
a
good,
stable
place,
I'm
of
the
opinion
that
we
need
to
get
this
out
there
and
then
work
on
maybe
additions
later
on.
You
know
otherwise
I'm
just
going
to
get
bogged
down.
If
there's
a
lot
of
other
kind
of
extra
stuff,
so
I
mean
we,
we
something
that
is
pretty
stable
and
seems
to
be
working
and
I.
Think
I
believe
we
should
be
going
forward
with
what
we
have
in
this
first
instance.
C
C
So
to
be
asked
on
Rome
Huawei,
no
working
group
chair
head
on
so
I'm
happy
with
this
I
fully
agree.
Just
one
note,
like
my
experience
in
the
IETF,
is
like
minor
updates
happening
later
many
or
may
not
happen.
So
if
you,
our
expectation,
is
that
you'll
need
to
make
changes,
then
maybe
we
need
to
do
the
tests
now
before
we
go
into
working
last
call,
if
you
say
actually,
this
is
okay
now
and
changes
are
unlikely,
then
yeah
we
go.
O
Bob
Moskowitz
agency
consulting
this
is
just
between
proposed
standard
and
standard.
We
get
the
proposed
standard
out
there.
We've
done
our
best
due
diligence,
we
believe
strongly.
We
got
it
then
after
you
start
getting
some
real
experience,
you
say
oh
crud
and
that's
what
the
business
for
and
then
going
there
to
get
to
final
standard.
So
if
we
group
say
that
we've
done
our
due
diligence
here
now
and
we've
done
some
testing,
we
think
we
got
it.
Then
we
should
go
forward
with
it.
That's
my
feel
on
it.
A
C
A
C
G
So
this
is
a
bit
of
the
the
current
state
of
the
directional
specification,
so
there
will
be
an
a-list
of
issue
that
we
have
discussed
so
far
in
analyst
and
then
the
what
we
think
to
be
the
next
steps
for
this
the
specification
so
just
as
other
mentor.
During
the
last
intern
meeting,
we
discussed
a
list
of
issues
that
we
have
identified
for
a
specification.
Some
of
them
are
not
real
issues,
but
we
do
think
that
it
is
work
for
the
working
group
to
discuss
them
and
to
make
sure
that
we
have.
G
What
we
have
recorded
in
the
specification
is
is
aligned
with
your
expectation
as
a
working
group.
So
there's
I
won't
go
to
to
list
this
list
with
it
because
I
will
individually
and
then
we
we
have
made
an
an
update
of
the
specification
to
be
aligned
with
the
latest
version
of
the
ACL
net
mod
specification,
because
there
are
some
iterations
there
in
the
network
working
group
that
affect
our
our
specification
here.
So
the
current
version
we
have
in
the
jet
are
completely
alignment
with
the
latest
version
of
the
new
network
specification.
G
But
this
one
is
not
published.
Yet
the
first
issue
is
about
the
the
lifetime
handling.
We,
we
agreed
during
the
in
the
purest
version
of
the
editor
channel
that
there
is
a
need
to
have
the
lifetime
associated
with
the
the
the
ideas
that
we
are
associating
with
the
client
and
also
with
the
filtering
rules
that
were
operating.
G
The
rationale
behind
that
is
that
we
want
to
avoid
to
have
still
map
in
indie
in
the
server
and
to
to
end
up
with
a
an
infinite
list
of
interest
there
without
having
any
clue
from
the
server
how
to
clean
up
the
entries.
But
the
the
problem
is
that
if
we
go
with
the
current
friskin's
mode,
is
that
if
you
a
client
suggest
a
lifetime,
a
hinted
left-hand
value,
but
the
server
decides
to
assigned
another
a
distinct
live
value.
G
There
is
no
means
in
the
risk
on
protocol
to
return
the
assigned
value
in
the
protocol
itself,
so
we
had
this
it's
more
about
the
technical
protocol.
So
what
with
this,
what
we
have
suggested,
the
mailing
list
and
what
we
invited
you
to
add
to
to
share
the
comments
and
the
conclusion
that
we
had
from
the
discussion
is
that
we
are
not
indicating
any
more
in
a
lifetime
in
the
request
to
the
server
we
are,
assuming
that
there
is
a
minimum
default
value
which
is
honored
by
the
server
so
the
server.
G
If
we
need
to
accept
a
filtering
entry
or
an
ileus
entry,
it
will.
It
must
maintain
that
in
3d
for
at
least
the
one
week
that
we
have
indicated
as
a
default
value,
so
then
the
clients,
if
they
don't
refresh
beyond
that
lifetime.
So
the
server
is
free
to
clean
up
the
entry
but
the
clients.
If
they
want
to
money
in
the
entry,
they
are
invited
to
send
a
refresh
before
the
expiry
date
and,
of
course,
the
clients,
the
can't
contact
the
server
to
get
depending
lifetime
from
the
server.
G
So
that
didn't
know
what
is
the
current
value
and
then
you
can
refresh
before
the
alias
or
default
means.
Who
is,
is
expired?
I
don't
know
if
there
is
any
objection
from
the
room
here,
because
this
is
exactly
what
we
have
as
a
conclusion
from
the
malleolus.
So
it
is
time
if
there
is
no
further
or
if
there's
no
objection
about
this
conclusion,
this
what
will
be
recorded
in
the
next
version
of
the
de
specification?
Is
there
any
objection
to
this
resolution?
G
Okay,
so
we
go
to
the
to
the
second
issue.
It's
it's
about
the
filter
that
direction
in
the
data
channel
specification.
We
are
assuming
that
the
the
denial
of
service
attack
that
we
are
we
are
covering
is
the
one
which
target
the
decline.
So
the
destination
is
always
the
client.
So
for
us
we
are
assuming.
There
is
no
need
to
specific
to
specify
the
destination,
because
by
default
the
destination
will
be
the
target
the
target
network.
G
But
in
the
the
discussion
among
the
others
there
will
there
is
this
famous
use
case,
which
is
called
the
Cole
home,
and
there
is
the
discussion
whether
there
is
a
need
to
cover
both
this
nation
and
and
the
source
address.
But
the
conclusion
of
the
discussion
we
had
on
the
malice
is
that
the
the
column
is
is
only
a
the
other
scenario
in
the
other
way.
G
Around
is
just
we
are
changing
the
rules
and
there
is,
the
target
will
be,
will
be
the
net
the
network
and
the
source
would
be
the
the
customer,
the
customer
network,
and,
as
far
as
the
dots
channel
specification
is
concerned,
there
is
no
implications
there,
because
the
always
the
the
the
destination
will
be.
The
network
which
is
hosting
the
dots
client
and
not
the
one
which
is
Austin
D,
do
that
server.
G
The
next
issue
and
the
point
that
we
discussed
is
about
the
default
activation.
The
depart
is
whether
we
assume
that
whenever
the
dust
client
sent
a
filtering
request
to
the
server,
do
we
assume
that
the
filtering
entry
will
be
immediately
enforced
by
the
server
or
it
will
be
only
enforced
only
during
the
mitigation
time.
G
So
in
the
indica,
in
the
updated
version
of
the
that
we
are
on,
we
have
on
the
github
we
we
are,
we
defined
what
we
call
the
activation
type
and
it
will
have
which
will
take
two
values,
whether
the
deactivation
will
be
immediate
or
only
do
the
mitigation
time
and
it's
up
to
the
server
to
decide
where
it
has
to
unload
the
request,
as
per
the
Kota
for
a
given
its
client.
And
so
there
is
this.
G
The
other
the
other
issue
is
about
the
scope
of
the
filtering.
If
you
consider
that
you
have
an
adult
domain
in
which
you
have
multiple
deaths
clients,
do
you
assume
that
that
all
the
different
rules
that
are
instance
on
set
but
a
given
client
do
apply
only
for
that,
given
Lots
client
or
it
will
apply
for
the
whole
domain
again?
G
This
would
be
only
specific
for
a
given
a
given
that's
client
and
not
for
all
the
ducks
clients,
because
there
will
be
a
a
potential
conflict
between
the
hints
that
will
be
provided
by
those
clients,
and
it
is
more
safe
that
we
associate
the
filtering
rules
for
with
a
given
dose
client.
So
that's
the
current
that
we
discussed
in
the
Marianist.
I
don't
know
if
there
are
some
problems
there
or
if,
if
we
have
to
change
what
he
the
the
the
this
the
outcome
of
of
this
conclusion,
so
there
is
one
open
questions
there.
Yes,.
P
And
Drazen,
so
III
have
not
followed
the
mailing.
This
discussion
on
this
one
so
bear
with
me
as
I
think
through
this
in
real
time,
I,
don't
recall
to
what
extent
we
said
that
things
were
done
on
a
per
domain
basis
versus
on
a
per
client
basis.
Maybe
this
is
something
that
we
just
need
to
look
at
a
little
bit
more
from
it
Architects
a
point
of
view.
L
G
Alienist
this
this
one
is
about
the
filtering,
the
filtering
fields
and
whether
we
need
to
do
to
list
the
Mon
that
way
to
be
to
be
supported,
fields
to
be
to
be
supported
by
the
protocols.
What
we
have
so
far
that
we
are
just
relying
on
what
we
have
on
in
net
mode
and
specification.
That
means
there
is
a
lot
of
optional
fields
and
fields
there.
G
But
the
problem
is
that
when
you
are
doing
it,
your
privacy,
you
don't
know
if
you
are
asking
your
server
to
do
some
filtering
a
given
field,
but
the
disorders
not
support
that
field.
So
there
will
be
some
issues
there
and
complications
to
an
or
the
Rockets
from
the
dis
client.
So
that's
why
we
end
up
to
to
this
entity
to
have
this
a
subset
of
the
the
filtering
fields
that
must
be
supported
by
inhibits
implementations
and
those
are
the
the
current
proposed
feels
to
be
a
to
be
supported
by
the
servers.
G
If
the
the
does
server
supports
other
actions
or
other
filtering
fields,
the
you
can
indicate
that
in
a
in
a
new
a
capability
container
that
we
introduced,
so
the
clients
can
ask
the
server.
What
are
the
lists
of
the
field?
The
filtering
feel
that
you
are
supporting
and
based
on
that,
the
Dutch
client
may
ask
the
server
to
install
some
filters.
Based
on
this.
On
this
on
the
honest
fields,
there
was
a
disguise,
a
proposal
from
Peru
to
include
detail
as
part
of
a
mall
that
very
field.
G
We
didn't
include
that
there
because
for
me
it's
not
that
I
would
say
drug
is
that's
in
way.
This
is
not
really
a
monetary
monetary
to
be
supported.
I
don't
know
if
you
think
that
this
list
is
long
or
as
short
or
is
I,
don't
know
so
this
kind
of
really
feedback
and
comment
we
need
to
have
from
the
work
group
so
that
we
win
has
the
specification
a
corny.
Yes,
yes,
you
need
a
shirt,
a
microfiber,
the.
N
N
L
P
P
Q
I
was
not
speaking,
I
wasn't
aware
that
I
was
lives.
Sorry
about
that,
can
you
hear
me?
Okay,
yes,
yeah
Roland,
avanzar
Burnett
works.
First
of
all,
I
went
into
second
Nick's
comments.
This
is
very
important.
Secondly,
looking
at
this
list
I
see
ICMP
I
don't
see
icmpv6,
it's
probably
just
an
oversight
needs
to
be
headed
there
and
then.
Finally,
with
regards
to
what
Fleming
just
said,
I
do
believe
that
we
need
to
be
looking
into
layer.
7
constructs
things
like
URIs
and
NS
resource
records,
and
things
like
that.
J
G
Ok,
so
we
move
to
to
the
next
to
the
next
issue
that
we
have
on
the
list
is
about
the
the
multiple
server.
So
this
is
a
comment
from
from
John.
It's
about
the
the
behavior
that
to
be
to
be
to
be
followed
by
this
bad.
That's
a
gateway,
windy,
there's,
a
quest
which
is
forwarded
to
to
upstream
servers,
but
it
happens
that
it
received
a
success
from
one
of
them,
but
a
failure
from
the
others.
What
will
be
the
behavior
of
the
dodds
gateway
with
regards
to
this
client?
G
For
me,
this
is
typically
the
kind
of
discussion
that
we
wanted
to
cover
in
the
multi-home
and
draft,
so
that
the
that's
why
I
suggested
to
John
that
we
don't
need
to
discuss
this
kind
of
consideration
and
the
current
based
specifications,
because
the
current
specification
are
really
I
would
say
targeting
the
single
home
scenarios
and
all
the
multi-home
in
consideration
will
be
left
out
of
scope
and
will
be
considered
in
the
other
document
via
we
have
presented,
or
your
order
here.
I
don't
know
John.
F
So
it's
the
challenge
with
multiple
services
I
like
to
live
in
a
world
where
redundancy
is,
and
so
as
part
of
that
I
like
to
have
my
primary
gateway
and
my
secondary
gateway,
and
is
this
current
spec
doesn't
handle
it
handles
just
a
single
gateway.
I
totally
appreciate
that
multihoming
is
way
beyond
just
primary
and
secondary
of
what's
in
there,
but
it's
certainly
from
my
perspective,
I
like
to
have
at
least
two
gateways
which
are
kind
of
similarly
configured
and
have
one
of
them
been
active
and
I
will
I
will
talk.
F
My
current
implementation
is,
as
far
as
the
signal
channel
is
concerned.
I
have
both
open
and
I
choose
one
of
them
to
send
the
mitigation
request
via,
but
I
can't
do
that
with
well,
not
so
easily.
With
the
data
Channel
is
you
know,
someone
sets
up
an
alias,
do
I,
send
it
to
both
gateways,
who
the
difference
its
we're
into
a
whole
world
of
strangeness.
F
G
C
G
We
have
the
error,
which
is
already
there
for
HDPE,
that
we
can
reuse
and
so
on,
but
so
the
Maricruz
to
you
and
to
for
the
working
group
is
to,
if
you
have
any
suggestion
or
if
you
have
any
favorite
option
that
you
want,
has
to
go
to
to
cover
or
to-220
guided
lovely
text
for
the
editor
channel.
Please
pick
up
and
share
your
thoughts
and
comments
with
us
just
no
matter
what
we
have.
G
E
On
clarification,
question
about
the
number
three
issue:
Mystica,
yes,
we
know
each
other.
It
is
said
that
education,
scott,
should
check
its
confliction
status
we'd.
Why
to
it
so
which,
when
clear
that
education
request,
the
confliction
of
visual
scott
with
white
elite
filter
should
be
done
for
registered
whitelist
or
active.
What
reason
that
is
the
question?
Yeah.
G
G
So
if
the
mitigation
request
assume
that
there
is
an
attack
which
is
ongoing,
that's
me
that
this
will
be
a
conflict
both
of
type
of
the
of
the
filter
and
the
one
which
is
currently
enforcement
network
and
the
one
that
will
be
available
to
as
a
hint
for
the
DAT
server.
So
my
answer
is
that
we
don't
need
to
clarify
in
the
signal
channel
with
our
dia.
We
are
covering
both
because
this
is
implicitly
assumed.
G
E
N
Next
week
so
haven't
really
been
following
much
the
risks
of
being
really
busy
recently
but
the
as
far
as
the.
N
N
N
A
Blue
sheet
on
it
somewhere
in
the
room,
can
the
one
the
person
holding
it,
raise
it
up
or
bring
it
forward?
Please,
and
does
anyone
else
need
to
sign
a
blue
sheet?
If
you
do,
if
you
could
catch
the
one
coming
up,
is
the
blue
sheet
somewhere
back
there?
Okay,
someone,
it
still
hasn't.
Okay,
very
good,
just
want
to
make
sure
we
didn't
lose
it.
Okay!
Next
up
we're
going
to
talk
about
our
informational
drafts.
A
I
We've
got
remote
audio,
we're
good
all
right
thanks.
This
is
just
an
update
on
the
dots
of
architecture
I
published
for
a
sort
of
a
provisional.
Oh
six
revision
this
early
this
morning
and
I.
They
will
probably
be
at
least
one
more
before
we
really
want
to
talk
about
adopting
working
group
last
call
just
as
a
preface,
but
let's,
let's
move
on
to
the
next
slide.
I
All
right,
so
I
will
cover
the
changes
and
then
the
obstacles
to
working
group
last
call
next
slide.
Please,
there
seemed
to
be
consensus
following
the
last
meeting
that
the
working
group
wanted
to
see
in
that
consideration
section
primarily
about
the
the
need
to
prevent
the
dots
client
from
requesting
mitigation
for
private
IP
space,
so
that
it
is
there's
a
new
that's
considering
in
that
consideration
section
in
the
O
six
revision
and
the
next
slide.
Please
we'll
cover
some
of
the
details.
I
So
the
this
new
section,
which,
as
I,
is
in
some
ways
rather
naive
and
need
some
some
reworking
I've
added
three
subsections,
which
involve
direct
provisioning
of
the
external
address
to
the
internal
address
spaces.
There
is
a
very
rudimentary
stun
binding
request
response
section,
which
Cheerios
already
given
some
very
good
feedback
on
about
some
of
the
naivety
that's
been
involved
in
that
particular
section.
I
We
will
probably
need
to
expand
that
rather
considerably
to
cover
ice
and
turn
as
well,
and
then
we've
added
a
section
for
DNS
names
which
would
allow
the
internal
resources
to
provide
a
dots
mitigation
scope.
If
they're,
internally
and
externally
resolvable,
the
dots
client
does
not
need
to
know
the
IP
address
mapping
at
all
next
slide,
so
the
obstacle
to
working
group
last
call
is
really
the
feedback
on
that
considerations.
Tier
has
already
kicked
it
off
on
the
the
working
group
mailing
list
using
his
feedback.
I
I
think
we'll
be
able
to
make
some
rapid
progress
on
this
and
barring
that
work
we
have
no
other
open
issues,
I'm
hoping
to
get
this
wrapped
up
actually
by
the
end
of
this
week,
hopefully,
we'll
have
an
O
7
draft
with
the
additional
changes,
and
then
we
would
I'd
like
to
proceed
to
working
group
last
call
rapidly
after
that
last
slide.
Please.
A
A
I
A
C
So
actually,
in
particular,
one
question
for
me
is:
is
there
any
particular
feedback
on
the
net
considerations
that
we
still
have
as
as
a
note
here,
any
additional
points
or
actually
let
me
rephrase
this:
is
there
anything
else
beyond
the
net
that
we
have
measured?
No,
no,
you
can
stay,
don't
worry
like
you,
don't
need
to
run
away.
G
Just
to
say
that
I
think
we
we
need
to
have
more
time
to
review
the
current
text
before
lunch,
indeed
working
class
contract
lecture,
so
that
to
make
sure
that
the
in
the
net
considerations
is
aligned.
What
we
have
already
provided
in
this
signal
channel,
also
in
the
channel,
because
we
have
already
and
not
consideration
discussions
there-
that's
to
align
tanks
and
then
start
the
developing
of
plastic
on
the
architecture.
Apart
from
that,
I
think
that
the
architecture
of
document
is
almost
stable
and
we
have
the
main
point
to
be
discussed
are
already
covered.
A
A
Yes,
okay,
so
the
last
topic
we
have
is
the
use
case
document,
which
is
an
informational
and
we
in
a
sense
needs
your
help.
The
we've
done
various
kind
of
structural
reform,
adding
of
it.
We've
talked
a
lot
about
the
use
cases
kind
of
themselves
and
we
are
not
making
progress.
So
we
have
a
couple
of
questions
kind
of
structure
here
to
help
us
get
there.
A
So
what
what
you
see
projected
right
now
are
two
hums
that
we
are
going
to
do
and
we
wanted
to
share
the
questions
with
you
ahead
of
time
before
you
see
the
material,
so
there
has
been
some
conversation
related
to
whether
we
need
the
home
net
use
case.
So
after
the
next
presentation
of
use,
cases
is
done.
The
first
thing
the
first
hum
we're
going
to
do
is
ask:
are
there
objections
to
removing
the
use
case,
and
then
the
next
hum
that
we're
going
to
be
doing
is
contingent
on
the
content.
A
You're
gonna
be
seeing
in
the
next
presentation,
which
is
which
sets
of
use
cases
we
want
to
use
in
the
11
whether
it's
going
to
be
the
basis
of
the
use
cases
currently
in
the
draft
or
what
is
about
to
be
presented
and
I,
see
some
puzzle
looks
and
it'll
be
a
little
clearer
after
you
see
the
presentation,
so
I
would
ask
that
that
you
kind
of
listen
to
what's
about
to
get
presented.
We're
gonna
do
two
hums
and
we
need
your
help
as
the
working
group.
A
The
editor
team
needs
actually
your
help
in
deciding,
which
course
of
action
to
take,
and
without
that
we
are
going
to
be
really
unable
to
publish
ticket
of
this
document,
because
the
editor
team
needs
clarity
on
which
way
which
way
to
process
that
document.
So
you
will
see
this
slide
again
and
we
will
hum
kind
of
twice
with
oh
and
we'll
talk
a
little
bit
more
about
that
after
Daniels
got
a
presentation
around
use
cases.
A
M
M
Mostly,
it's
not
a
big
change.
It's
mostly
organizational
it
limits.
It
reduces
the
number
of
use
cases,
so
I'm
stating
three
use
cases
instead
of
multiple
additional
use
cases,
and
it's
also
limit
the
level
of
details
to
the
dot
protocol.
So
there
are
a
lot
of
information,
but
maybe
this
information
at
some
point
I
found
not
so
if
I'm
more
information
out
relevant
relevant
in
the
dots
context.
M
So
the
end
result
is
a
ugly
copy-paste,
but
it
still
provide
what
the
intent
was
really
to
provide
you
and
a
high-level
view
of
what
we
may
we
may
go.
So
there
are
three
use
cases
I
think
that
are
relevant
for
that
document.
The
first
one
is
when
you
have
a
novel,
a
DDoS
mitigation
managed
by
a
service
provider.
That
is,
that
has
nothing
to
do
with
a
customer.
M
So
it's
very
related
close
to
the
use
case,
one,
except
that
you
have
a
binding
between
the
link
and
the
service,
so
it
could
be
useful,
but
it
had
some
small
constraint
and
rather
than
starting
the
use
case
to
from
scratch,
I
just
built
and
focus
on
the
difference
which
the
use
case
and
the
most
motivation.
The
main
motivation
for
use
case
two
is
that
is
it's
a
use
cases,
that's
gonna.
M
That
seems
to
me
quite
relevant
and
that's
going
to
be
widespread
in
future,
and
the
last
use
case
is
use
case
tree
where
dot
is
being
used
as
a
way
to
manage
and
to
orchestrate
different
that
dot
service.
So
if
there
is
a
coordination
and
and
so
on.
So
these
are
the
three
use
case.
I
think
are
really
relevant
to
the
document,
and
it
seems
to
me
that
some
of
the
other
use
cases
described
in
version
10
or
nine,
because
mostly
based
my
work
on
my
comments
were
for
a
version
time.
M
The
other
chains
are
that
I've
removed
HomeNet
use
case.
Well,
this
is
case.
I
was
the
one
introducing
this
use
cases
so
I
feel
less
guilty
to
remove
that
one.
But
it
seems
to
me
that
we
didn't
have
a
real
consensus,
whether
it
was
a
useful
use
case,
and
it
was
also
maybe
a
use
case
that
mislead
the
the
team
into
splitting
to
use
cases
between
internal
use,
cases
and
external
use
cases.
So
inter-domain
and
intradomain
use
cases
which
may
not
be
relevant
to
you
at
that
stage.
M
E
L
M
L
L
Case
right
so,
for
example,
my
company
McAfee
is
providing
home
security,
so
we
have
security
software
running
on
CP
right,
and
this
is
something
that
we
could
do
basically
to
provide
home
security
where
we
can
protect
the
home
network
from
DDoS
attacks
or
the
whole
network.
Launching
DDoS
attacks
right
now.
One
specific
change
in
the
protocol
that
basically
for
a
home
light
used,
is
that
I
can
bring.
You
is
the
call
home
feature
what
the
dots
client
running
on
the
we
need
a
dot
server
on
the
CPU.
L
Basically,
but
you
don't
really
want
to
run
a
server.
So
restaurant
gives
you
a
capability
where
you
initially
act
as
a
client
talk
to
the
ISP
and
then
ISP
degrades
himself
to
act
as
a
client
and
the
server
becomes.
The
client
becomes
own
on
the
CPU
becomes
a
server.
That's
a
call
home
functionality,
basically
for
home
routers
to
be
managed
by
a
cloud
service
provider
or
somebody
sitting
in
that
ISP
to
manage
them.
L
M
Q
There
Roland
Devon
server
networks,
yeah
I,
strongly
disagree
that
it's
a
unique
you
case,
I
believe
that
the
other
use
cases
that
are
in
9,
10
10
was
just
cleaning
up
notes
and
in
grammar
errors,
no
content
changes,
there's
already
another
use
case.
That's
quite
clear
that
talks
about
mitigation
of
outbound
DDoS
attacks,
for
example,
on
a
broadband
access
network
that
use
case
could
be
modified
slightly
to
incorporate
a
little
bit
more
of
what
was
just
discussed
right
now
in
this
meaning.
Q
The
current
home
net
use
case
as
defined,
is
not
very
clear
and,
and
there's
a
lot
of
verbiage
in
the
air.
It's
just
it's
it's,
it's
not
a
clear
use
case
at
all,
and
so
we
already
have
the
outbound
stuff
taken
care
of
and
the
the
phone
home
you
know,
stuff
that
was
just
discussed
could
very
easily
be
added
to
that
other
use
case
to
fulfill
that
particular
name.
Thank
you.
P
C
C
N
Is
related
to
home
that,
but
it's
more
case
of
like
the
simple
use
case
of
this
is
the
fact
that,
like
saying
help
it
make
it
stop,
and
that
is
really
the
only
one
use
case
and
we're
just
trying
to
be
a
bit
new,
and
so
personally,
if
there's
text
that
people
would
like
to
suggest
for
home
net
that
they
would
like.
You
know
that
we
can
just
slap
it
in
there
and
kind
of
put
it
to
the
working
group
and
go
from
there.
N
E
L
C
Sorry,
I
shouldn't
have
touched.
The
mic
I
think
the
question
goes
a
little
bit
to
you
whether
you
would
like
to
propose
some
text
for
the
because,
like
you,
you
seem
that
you
care
about
this
use
case
so
and,
as
Nick
mentioned
like,
if
you
have
something
that
you
want
to
propose
and
put
it
there,
I'm.
C
L
C
Q
A
C
A
C
Q
Yeah,
first
of
all,
I
want
to
think
annual
for
all
the
work
that
he's
done.
I'm
thinking
about
this
and
in
putting
together
this
proposal.
My
view
is
that,
while
guests
people
who
are
familiar
with
the
DDoS
arena,
with
the
concepts
that
are
out
late
and
are
laid
out
in
the
three
proposed
use,
cases
can
easily
derive
many
of
the
other
use
cases.
Q
Many
of
the
people
who
would
benefit
the
most
from
this
document
are
not
familiar
with
DDoS
and
they're,
not
familiar
with
the
operational
world
or
if
they're
operational
people
they're
not
cognizant
of
all
the
different
considerations.
They
don't
understand
necessarily
what
is
outside
the
scope
of
donnas
versus
what's
inside
the
scope
of
dots,
and
that
is
from
from
my
perspective,
is
the
value
of
those
additional
use
cases.
So
my
suggestion
would
be
that
we
don't
condense
it
down
into
three.
Q
My
further
suggestion
is,
if
the
consensus
the
working
group
is
that
we
do
consider
it
down
to
three,
then
my
suggestion
would
be
that
we
actually
use
the
upstream
transit
provider
case
s
use
case
number
one,
because
that's
actually
conceptually
similar,
then
the
overlaid
cases
so
flip.
Those
two
in
the
list
of
three
in
Daniels
presentation,
Thanks.
L
Q
I
Q
R
Q
Rowland
Island
server
networks,
that's
actually
not
a
separate
use
case.
That's
just
a
separate
motive.
Operation
I
do
agree
with
you
that
it
should
be
explicitly
stated
that
there
are
two
different
primary
modes
of
mitigation:
either
number
one
on
demand,
diversion
in
reinjection
or
number
two
permanent
permanent
diversion
in
line
issue.
You
know
whether
it's
specifically
inline
or
logically
line,
as
you
mentioned,
so
that
does
need
to
be
addressed
in
whichever
form
the
group
decides
that
the
document
should
take
thanks
for
bringing
that
up
again.
Okay,.
A
C
So
to
be
Escanaba
away,
working
with
J
head
off
so
before
we
go
into
this
humming.
The
one
thing
that
I
care
is
that
this
gets
done.
Frankly,
like
we
have
been
running
around
this
use
case
trough
for
quite
a
long
time.
The
last
update
didn't
really
make
many
changes.
It's
good
that
we
had
some
chromatic
grammar
editorial
changes,
that's
okay,
but
like
we
were
still
missing
this
use
case
that
was
just
mentioned
and,
like
I,
really
hope
us
to
get
this
through.
C
Actually
I
have
a
slight
preference
for
a
streamlined
option
as
Daniel
proposes
it,
because
I
think
it
will
like
help
the
reader
to
go
through
that,
and
maybe
you
will
not
be
so
easily
lost
in
a
large
number
of
cases
and
especially
like
I'm.
Actually,
this
would
be
a
question
for
me
personally,
not
as
a
chair
to
Daniel,
like
if
you're
committed,
to
make
these
changes.
That
would
also
help
me
to
go
for
yeah.
Okay,
do
it
because
left
or
right
or
both
open?
So
it's
fine,
but
as
long
as
we
get
through
that
door.
A
M
A
Okay,
the
first
question
we
are
going
to
hum
is
framed
around
the
fact
that
we
have
an
editor
team
right
now.
Working
on
this
use
case
document
and
the
two
different
elements
of
that
editor
team
have
said
the
home
that
use
case
should
be
removed.
We
need
working
group
feedback
to
the
editors
about
whether
the
home
that
use
case
should
stay
in
or
out
so
I'm
gonna
frame.
This
frame
this
as
the
text
is
there
hum
please
now
if
there
is
an
objection
to
removing
the
home
net
use
case.
B
C
A
So
that
is
hum
number
one
now.
The
second
hum
were
we're
going
to
do
is
going
to
consider
the
structure
of
the
document
again,
the
editor
teams
have
proposed
two
different
structures
to
what
is
in
the
current
text
and
they
need
your
feedback
to
tell
them
what
to
do
with
that
text
so
option
one.
So
the
first
time
we're
gonna
be
asking
is
about
keeping
the
existing
structure
in
the
text.
That's
10,
but
also
it's
also
9,
and
it's
been
in
the
last
couple
versions.
The
that
structure
has
been
the
same.
A
P
M
C
So
with
the
working
which
I
hear
working
group
chair
head
on,
like
we
also
debated
about
this
and
I
think
in
the
end,
there's
probably
pros
and
cons
on
both
sides
for
the
speed
of
this
I
mean
looking
at
what
we've
seen
for
the
changes
from
Danielle
as
most
of
this
is
organizing.
This
is
probably
not
gonna.
Take
a
lot
of
time
to
do.
A
Okay,
so
to
restate,
there's
going
to
be
two
options
to
hum
on
option:
one
is
going
to
be
keep
the
existing
structure
less.
The
HomeNet
we
just
decided
on
option.
Two
will
be
take
the
use,
the
revised
structure
of
three
primary
use;
cases
that
Daniel
just
just
splashed
up
in
the
presentation.
So,
okay,
if
you
would
like
to
hum
for
option
one,
please
hum.
A
Okay,
so
the
consensus
from
the
ad
listening
is
that
we're
going
with
option
two
on
hum
2,
which
is
we
are
going
to
pursue
a
revised
structure?
That's
simplified
to
the
three
use
cases
that
was
just
in
the
presentation
prior
to
this
slide.
So
Daniel,
you
had
been
saying
that
you
were
late,
laying
out
a
notional
kind
of
timeline,
so
to
repeat
that
you
think
you
can
make
all
of
the
changes
you
had
shown
in
your
slide
to
within
a
month
and
after
we
do
that
we
go
working.
Group
last
call.
A
C
Have
one
comment
as
working
group
chair,
so
we
have
seen,
let's
say
some
delays
with
the
use
case
draft
and
at
this
point
actually,
my
my
face
is
directly
to
you
Danielle.
So
you
made
this
commitment
so
within
a
month,
I
hope
we
can
have
that
draft
and
if
you
need
help,
you
can
get
it
but
like
this,
if
I,
if
I
get
a
commitment
from
five
people,
then
I
it's
not
as
dependable
like
as
that
one
from
one
person
so
go
ahead,
don't
wait
for
others
make
it
happen.
A
C
Okay,
that
leaves
us
with
one
thing:
we
want
to
think
our
graceful
ad
for
all
the
great
services
she
did
for
our
working
group
and
all
the
patience
she
had
with
the
many
slipping
milestones.
I
heard,
I
read
somewhere,
there's
nothing,
no
better
sound
than
the
swooshing
of
milestones
kind
of
swooshing.
By
and
like
I
think
we
had
a
great
great
sound
with
that.
So
thank
you
so
much
Kathleen
for
all
the
help
and
the
guidance
you
offer
to
us
really.