►
From YouTube: IETF102-BABEL-20180717-0930
Description
BABEL meeting session at IETF102
2018/07/17 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
D
C
D
D
Sorry
for
the
vertical
instability
of
the
slides,
so
document
reviews
are
good,
improves,
quality
helps
to
get
documents
to
progress.
So
if
you
would
like
your
document,
reviewed,
probably
good
to
review
other
documents-
and
things
like
that
here
is
the
proposed
agenda,
there's
an
initiative
stuff.
We
do
have
volunteers
for
jabber
and
minutes,
which
is
great.
You
can
anybody's
testing
changes.
We
can
in
bash
the
agenda
of
Italy,
go
over
its
status
and
milestones
and
things
presentations
on
H,
Mac
and
bowel
DTLS.
D
So,
in
our
status
we
had
a
charter
update
a
small
change
done
so
that
our
request,
the
working
group
by
the
IES
you,
which
basically
decouples
requirement,
reduces
a
yang
model
from
getting
the
standards
track
based
protocol
out,
and
so
we
can
do
the
egg
model
late
and
it
doesn't
affect
the
information
model
which
is
moving
along
and
in
pretty
good
shape.
We
have
a
presentation
on
that,
also
and
and
with
that
information
model,
to
make
it
easier
to
produce
the
egg
model.
D
D
So
we
have
four
working
group
drafts
currently
and
some
of
the
number
of
these
have
been
in
stead
of
sitting
and
working
group
last
call
for
a
while
just
really
because
they
didn't
seem
to
be
a
lot
of
response.
I,
there
hasn't
been
any
negative
response
and
there's
been,
has
been
positive
response,
but
not
a
lot.
D
So
particularly
the
applicability
draft
is
pretty
short
and
simple,
so
I'm
wondering
if
we
can
at
least
for
the
flick
ability,
draft
I,
can
ask
if
there's
any
objections
that
it's
declaring,
that
to
have
working
group
consensus
based
on
the
response
on
the
mailing
list.
Is
anybody
here
or
on
the
media?
Co
have
any
objections
to
doing
that
for
the
applicability
draft.
D
B
D
For
the
other
g
will
continue
them
in
their
work.
Move
last
call
status,
people
should
respond
and
comment.
You
know
more
positive
responses
will
be
good
and
it
see
perhaps
even
more
important.
If
there's
our
people
who
are
opposed,
they
should
speak
up
to
and
say
why
they
have
a
problem
with
the
RC
6126
bushcraft,
or
these
were
specific
craft.
B
D
D
The
the
there's
a
home
that
draft
on
the
approval-
yes,
sorry,
clarification
from
Julius
there
was
an
adoption
call.
Not
a
working
group
last
call
for
70
to
90
at
this.
So
you're
right.
Excuse
me
yeah,
it's
a
good
correction.
We
were,
it
was
a
it's
as
it's
not
draft
IETF,
it's
just
of
Cinco
and
it
was
an
adoption
call
which
is
is
different
and
it
failed
to
get
consensus
to
adopt
yeah.
There's
the
it's.
A
people
may
be
interested
in
the
home.
D
Let's
see
this
is
our
current
milestones,
so
if
people
want
to
look
at
this,
these
slides
it
look,
there's
the
rel
ones,
we've
completed
and
the
ones
where
we're
way
behind.
So
probably
the
suggestion
of
our
ad
the
flight
after
this
has
some
suggested
milestones
which
chain
add
one
and
change
dates,
so
I
thought
we
discussed
those
at
the
end
of
the
meeting
after
we've
had
the
various
presentations,
because
that
might
have
when
people
think
we
could
actually
achieve
these
things.
D
D
D
E
I'm
Julia
scrubber
clerk
I'm
sitting
here
in
Paris,
it's
about
70
degrees
centigrade
in
my
office,
and
it
is
early
afternoon
and
I'd
like
to
tell
you
a
few
words
about
the
protocol
that
have
been
done
by
Claude,
Linda,
Ron
and
Veronica
cognac
during
the
left
months,
which
is
which
is
the
security
protocol
using
H
Mac
for
Babel.
Next,
please
so
I'm,
not
the
person
who
has
done
most
of
the
work.
Most
of
the
work
was
done
by
a
lot
of
people,
so
Dennis
F
shankha
started
the
whole
thing.
E
Then
we
work
together
with
Claude,
doe
and
Veronica
cover
J
yeah,
though
it's
following
online
and
Veronica
is
sitting
here
with
me,
and
they
did
an
implementation
of
the
new
protocol,
design
based
on
Dennis's
work,
and
then
there
was
input
from
a
lot
of
people,
so
I'm
afraid
I'm
going
to
forget
people,
but
David's
kid.
Nancy
convinced
us
to
use
a
pseudo
header,
Marcus
Stenberg,
designed
the
index
mechanism
that
I'm
going
to
this
later
tokoha
and
european
center
on
our
land
below
Xavier,
did
a
lot
of
gave
a
lot
of
suggestions.
Next,
please.
E
So
the
plan
now,
if
you
have
two
protocols
for
Babel
security
now,
the
reason
is
that
there
is
a
natural
tension
between
one
hand
having
a
simple
and
reviewable
protocol
and,
on
the
other
hand,
having
useful
features.
So
we
want
to
have,
on
the
one
hand,
it's
simple
reviewable
protocol
and,
on
the
other
hand,
a
protocol
with
all
the
future
unite
works,
so
H
Mac,
which
I'm
going
to
speak
about
in
this
talk,
uses
unchanged
babel.
It
has
no
dependencies
except
for
hashing
and
has
absolutely
minimal
features.
It
has
symmetric
keying,
few
keys
per
interface.
E
E
D
E
This
you're
right
so
H
Mac
only
does
authenticity
well,
DTLS
also
does
privacy
next,
please
so
now,
I'm
going
to
spend
a
few
minutes,
giving
you
the
technical
details
and
trying
to
avoid
getting
too
bogged
down
into
the
detail.
So
if
there
are
any
cryptographers
in
the
room
you're
going
to
cringe-
and
please
accept
my
apologies-
so
you
all
know
what
is
an
H
Mac?
E
Now
each
Mac
does
not
protect
about
against
message
replay.
So
imagine
the
following
scenario:
Bob
sends
an
announcement.
Okay,
he
says:
okay,
I
can
read
Google,
please
go
through
me.
If
you
want
to
send
to
Google
and
signs
it
correctly
with
an
H
Mac
now
a
Alice
receives
the
message
from
B
and
installs
a
route
through
Bob
C.
In
the
meantime,
Chloe
has
captured
the
message
from
B
and
much
later,
when
Alice
has
forgotten
everything
about
the
exchange.
Chloe
realized
the
announced.
Alice
goes
oh
well.
E
Chloe
has
sent
a
properly
signed
message
and
installs
a
route
through
khloe
and
khloe
has
gotten
all
the
traffic
to
google
okay
game
over.
You've
lost.
That's
a
replay
attack
next,
please.
So.
The
first
mitigation
for
this
attack
is
to
use
a
pseudo
header
that
is,
to
protect
the
sender
and
receivers
address
in
addition
to
the
message
contents.
E
So,
instead
of
sending
an
H
Mac
that
just
covers
the
message
you
send
an
H
Mac
that
covers
the
source,
address
the
destination
address
and
the
message:
okay,
so
the
bit
that
you've
added
to
the
hatch
the
connected
to
the
hash,
the
concatenation
of
the
source
and
destination.
That's
what's
called
the
pseudo
header.
So
here
a
replay
attack
is
still
possible,
but
it's
a
little
bit
more
difficult
to
exploit.
So
B
sends
an
announced.
E
Okay,
properly
signed
by
H
Mac,
a
installs,
a
route
through
B
and
if
later
C
wants
to
replay
the
announced
C
has
to
spoof
B's
source
address,
because
the
source
address
is
part
of
signature,
and
so
a
in
that
case
can
only
install
the
route
through
B.
So
here
C
didn't
manage
to
get
all
the
traffic,
but
it's
still
a
replay
attack.
It's
still
a
vulnerability.
Next,
please
so
we
need
some
form
of
replay
protection
and
the
natural
thing
to
in
order
to
protect
against
replay
is
to
have
a
strictly
increase
encounter
within
all
messages.
E
F
E
Replay
it
with
the
packet
counter
being
42,
because
it
was
signed
by
H
Mac
and
it
cannot
modify
the
packet
without
invalidating
the
H
Mac
and
a
will
reject
the
packet,
because
the
packet
counter
is
too
old.
So
this
is
a
perfectly
safe
protocol,
assuming
that
the
sender
uses
strictly
increasing
packet
counters
and
that
the
receiver
keeps
state
about
the
last
packet
packet
number
received
from
every
single
red
neighbor,
essentially
forever.
Please.
E
So
basically,
I'm
lost
and
over
a
number
of
details
that
what
I've
described
above
is
basically
cut,
seven
to
nine
eight
does,
and
it
has
two
issues.
One
is
that
it
requires
that
every
Center
maintain
a
strictly
monotonic
packet
counter,
and
the
second
one
is
that
it's
received
at
every
receiver.
Keep
the
packet
counter
history
of
every
peer.
It
has
ever
encountered
basically
forever.
So
in
seven
to
nine
nine,
there
is
some
language
about
an
AMM
timeout
which
qualifies
the
forever
here,
but
it
does
cause
some
vulnerabilities.
Now
both
are
problematic.
E
Persistent
sender
state
is
something
that
can
be,
but
it
cannot
be
done
portably,
so
persistent
storage,
if
you
keep
your
packets
counter
and
disk,
is
non
portable
depending
on
which
device
your
own,
the
persistent
state
might
be
the
file
system,
it
might
be
some
form
of
non-volatile
Ram
and
it's
also
not
always
reliable.
Sometimes
the
persistent
state
will
be
reset.
E
For
example,
if
you
have
a
disk
crash
and
hardware
clocks,
don't
necessarily
exist
and
all
of
the
routers
that
we
use
and
even
when
they
do
exist,
there
are
sometimes
reset
and
if
you
lose
your
PC,
for
example,
because
you've
rebooted
and
lost
your
disk,
the
failure
mode
is
very
unpleasant.
Your
node
will
be
black
held
up
to
in
the
language
of
1702
72,
nine,
eight
up
to
the
Amen
timeout
timeout
after
the
receiver
state,
well
I.
Think
it's
completely
unrealistic
because
you
need
to
keep
receiver
States
for
all
the
neighbors
you've
ever
met.
E
So
that
means
that
you
have
unbounded
amounts
of
persistent
storage
on
this
side.
However,
the
failure
mode
is
a
little
bit
gentler
after
loss
of
state
or
just
don't
rebel
to
replay,
as
Dennis
showed
us
at
IETF
96.
Next,
please,
okay,
so
we
want
to
avoid
persistent
state.
Persistent
state
is
evil.
We
want
to
use
soft
state
only
and
that's
what
we
do
in
draft,
though
babble
H
neck.
So
we
have
two
additional
mechanisms.
E
E
E
Now,
on
the
sender
side,
well,
the
packet
counter
is
reset
less
often
we
accept
that
it
will
only
be
reset
when
a
node
reboots
and
the
Meccan
on
here
is
somewhat
different.
Every
single
packet
carries
not
only
a
packet
counter,
but
also
an
index,
so
the
index
is
an
arbitrary
string
of
bytes
and
it
indicates
basically
which
copy
of
the
integers
you're
working
with
the
idea
is
that
whenever
you
reset
your
packet
counter,
you
pick
a
new
index
now
when
it
detects
an
index
mismatch.
E
E
Okay,
Oh
implemented
and
specified
by
clarence
ironic,
so
the
draft
it's
a
0
0.
It
needs
a
little
bit
more
work,
especially
when
speaking
about
implementation
consider
patience,
but
it
has
been
shown
to
be
good
enough
for
implementation.
It's
16
pages
long,
including
boilerplate
and
appendices
and
after
16
pages
only
seven
or
normative,
and
we
already
have
two
independent
interoperable
implementations.
The
original
implementation
by
done
by
Clara
and
Veronica,
could
has
been
integrated
in
Babel
D,
but
not
merged
into
the
master
branch.
Yet
it
consists
of
17
793
lines
of
code,
not
counting
hashing.
E
It
requires
fairly
minimal
changes,
the
babel
d
and,
according
to
the
ladies,
it
was
easier
to
implement
an
RFC
seven
to
nine
eight,
which
is
what
they
implemented
earlier
and
that
there
is
a
second
implementation.
I
haven't
looked
at
yet
it's
due
to
dr.
Holland
Jurgen
said
it
has
been
integrated
in
bird
and
again
in
stock
merged.
Yet
it's
a
little
bit
shorter
than
our
implementation.
Just
five
hundred
and
thirty
three
lines
of
code
and
Toki
explained
to
me
all
this
stuff
in
an
email
input.
E
He
said
I
found
the
draft
pleasant
to
read
and
straightforward
to
implement
next,
please,
okay!
So
although
we
already
have
two
implementations
and
have
written
down
the
specification,
we
still
think
there
are
a
number
of
open
questions,
although
good
has
been
a
little
fast
on
the
list.
So,
first
of
all,
we
have
to
decide
what
is
the
size
of
the
nonce
and
index.
We
have
to
decide
whether
we
want
to
use
the
package
trailer
and
we
want
to
pick
between
two
variants
of
the
algorithm,
the
explicit
or
the
implicit
indices.
Algorithm.
E
E
E
So.
The
other
question
is:
where
do
the
H
max
live
and
there
are
two
possibilities
we
can
put
them
beyond
on
the
packet
or
wizened
package.
So
if
we
starting
within
the
NACA,
we
have
a
problem
because
the
public
participates
in
H,
Mac
computation
and
the
nature
cannot
hash
itself
out.
So
it
requires
a
fairly
compliment
than
clearing
the
H
max
he'll
be
hashing
in
the
thirteen
th
market.
So
up
putting
them
in
the
packet
rate
are
simplified
the
elimination,
but
it
makes
the
specification
like
my
block,
but
we
have
to
specify
the
package
data.
E
Very
sexy
variant
of
the
algorithm
due
to
Marcus
Steinberg
could
consist
in
emitting
disease
in
all
packet
except
parenting
class,
so
Stenberg
north.
Then
the
index
is
usually
known
by
the
receiver.
The
only
time
in
which
the
receiver
does
not
know
the
index
is
what
is
Callaghan,
so
the
idea
is
to
omit
the
packet,
the
northern
route,
packets
included
in
Chandler
Plaza,
so
that
shakes
a
lot
a
few.
E
It
complicates
the
implementation
quite
a
bit.
First
of
all,
you
need
to
parse
the
whole
packet
before
you
can
compute
H
Mac.
Second,
the
encoding,
the
various
TLD
ism
is
much
more
complex
and
finally,
it's
a
clever
solution
which
makes
it
more
difficult
to
prove
correct.
That
is
very
much
Elgar
of
the
nobility
of
the
draft.
Please
check
next,
please,
okay,
so
I
think
we
have
a
simple,
easily
implementable
cryptographic.
Authenticity
extension,
formal
specification
is
simple:
the
implementation
is
very
doable
and
we
already
have
two
independent
interoperable
implementations.
I
I
E
I
D
I
D
D
I
All
right
does
it
click
perfect.
It
does
all
right
good
morning,
everyone,
my
name
is
David
Skinner,
Z
and
I'm
going
to
be
presenting
paper
over
to
us.
So
I
like
Jules,
was
saying
the
producers
said
presentation,
I
didn't
do
most
of
the
work
on
this
either.
Most
of
it
was
at
Inara
with
help
from
joyous,
so
I'm
just
sure
to
present,
because,
unfortunately
they
couldn't
be
in
the
room
today,
so
Jos
already
kind
of
discussed
the
motivation
for
this
earlier.
I
We
need
a
way
to
secure
this
and
having
multiple
security
models
for
different
use.
Cases
is
very
valuable.
So
for
cases
where
you
want
simplicity,
baywatch
mac
is
great,
but
if
you
have
deployments
where
your
King
model
is
more
complicated
to
say,
you
want
a
public/private
key
pair
for
each
device,
then
HVAC
doesn't
quite
cut
it
for
anything
complicated
like
that.
We
don't
want
to
be
reinventing
security
in
this
working
group,
so
we
just
leverage
TTLs.
I
So
how
does
it
work?
The
key
there
is
that
it
leverages
Babel
over
unicast,
so
Julius
calls
that
a
change
to
the
protocol.
I,
don't
worry
because
my
implementation
of
Babel
does
everything
over
unicast
in
the
first
place,
but
a
running
Babel
recast
fits
the
standards.
It
is
just
a
requirement
if
you're
doing
DTLS,
because
they're
pairwise
encrypted
keys,
you
can't
multicast
those
packets
and
then
you
send
multicast
in
the
clear.
I
Another
question,
which
is
one
that
Joyce
and
I
disagree
on
and
after
now
hasn't
made
a
very
clear
statement.
Yet
is
the
port
numbers,
so
we
have
two
ways
to
do
this.
One
is
well
everything
on
the
same
port.
So
let's
take
a
step
back
Babel.
Regular
Babel
is
a
peer-to-peer
protocol
where
everything
is
sent
and
on
port
66,
96
and
I
mean
both
the
UDP
source
and
destination.
I
Ports
are
both
set
to
66
96
doing
DTLS,
for
that
is
kind
of
weird,
because
you
could
end
up
having
multiple
DTLS
connections
on
the
same
five
tuple
and
then
it
makes
the
dichos
implementation
a
little
bit
more
complicated
because
it
needs
to
be
able
to
differentiate
those
the
the
subtlety
there
is.
If
you
have
a
connection
established
and
that
node
reboots
you
get
a
new
client
hello,
you
should
renegotiate
with
that,
not
necessarily
drop
it.
I
But
since
the
client,
hello,
is
not
a
Thundercat
in
any
way
that
claim
to
hello
could
be
an
attack
for
someone
else.
So
you
don't
want
to
clear
your
State
on
receiving
inclined
too
low,
so
you
need
to
kind
of
keep
both
states
on
the
same
ports
at
the
same
time,
which
is
doable
but
complicates
the
details.
I
Implementation
and
another
downside
is
some
DTLS
stacks
handle
like
their
underlying
networking
directly,
meaning
they
open
their
UDP
sockets
and
if
you
they
won't,
let
you
more
create
multiple
connections
on
the
same
ports,
because
then
they
don't
know
which
one
to
send
the
packets
on.
So
that's
something.
You
also
need
to
know
on
your
implementation.
The
other
approach
is
to
use
separate
ports.
So
that's
what
each
NCP
over
an
home
net
did,
for
example,
where
you
have
a
regular
port
for
the
unencrypted
traffic.
I
I
The
downside
that
Joey
is
brought
up
is
that
it
can
cause
packet.
We
ordering
in
that
other
multicast
packets
are
still
ordered
and
other
unicast
packets
are
still
ordered,
but
they
can
be
ordered
between
them.
Given
that
things
like
the
sequence
number
for
hellos
is
separate
for
unicast
and
multicast
hellos
I,
don't
particularly
see
that
as
a
problem.
I
G
G
I
Another
point
is:
if
you're
using
the
same
board,
then
you
need
to
when
a
packet
comes
in
figure
out.
If
it's
DTLS
or
not,
it
does
happen
that
the
first
part
of
a
babel
packet
is
42,
because
julius
still
can't
get
over
that
number,
but
and
the
first
bite
of
a
DTRS
packet
is
the
TLS
type
and
42
is
not
currently
assigned
I.
Don't
personally
want
to
go
to
the
chess
working
group
and
ask
them
to
reserve
a
code
for
Babel,
especially
number
42.
K
I
K
To
make
sure
if
you
use
two
ports,
I
will
consider
such
a
possibility
of
that.
You
have
a
pair
of
speakers
using
two
exchanges
on
different
ports
and
then
another
pair
of
speakers
doing
another
exchange
for
another
pair
of
ports,
and
then
somebody
just
crosses
over
and
uses
details
exchanged
between
one
pair
and
substitutes.
The
actual
routing
protocol
exchanged
for
the
other
hello
considered.
If
such
an
attack
is
possible
or.
I
Yes,
the
what
details
do
does
is
that
as
soon
as
you
finished
your
handshake,
you
have
a
ephemeral,
shared
secret
that
you
use
to
encrypt
all
the
traffic.
If
you
grab
one
and
switch
them
there
is
a
filter,
D
correct
in
the
packet
will
be
dropped.
So
that's
one
of
the
security
properties
that
DTLS
provides
okay.
K
I
Moving
on
implementations
of
people
over
DT
LS,
the
first
one
was
made
by
Altoona
in
Babel
T
I
made
an
independent
implementation
as
well.
We
haven't
found
the
time
to
do
interrupt
testing,
yet
I
kind
of
want
us
to
figure
out
the
port
question
first,
but
I
sure
we
won't
have
many
problems,
it's
pretty
straightforward
to
implement.
As
long
as
you
have
a
DTLS
stack.
Obviously,
next
steps
are
we
so
with
this
work
was
already
presented
by
on
at
the
last
ITF.
Since
then
we
have,
or
he
has
and
I've
written
a
draft.
I
All
right
not
quite
yet,
we
would
like
to
ask
working
group
adoption,
I
suspect
that
will
require
more
people
reading
it,
but.
K
Me
again,
I
heard
accelerate
the
draft
when
it
was
eight
pages
long
and
I
thought
it
was
better
not
to
discuss
it
because
well,
it
was
too
short
to
discuss.
But
there
is
a
question
regarding
the
how
approach
that
I
had
raised
on
the
mailing
list
and
it's
a
simple
as
when
a
DTS
implementation
has,
for
instance,
hot
or
200
Reuters
when
a
single
segment
and
they
tried
to
do
details.
L
I
K
Matter
is
I'm
not
discussing
the
use
case
of
an
internet
exchange,
okay,
but
the
use
case
of
a
mesh
network
and
in
a
mesh
network.
Each
node
has
to
be
rota
rota
and
it
is
quite
possible
that
when
mobile
nodes
get
together
that
they
actually
will
see
each
other
and
try
to
establish
a
GTS
association
between
between
each
other
and
that's
how
I
see
it
it's
possible.
K
I
So
I
think
that's
a
good
point
too.
Thanks
for
using
it
Dennis
so
I
think
it
means
that
we
need
to
add
some
applicability
text
to
the
DTLS
document
where,
if
you
have
a
very
high
number
of
nodes
and
a
quadratic
number
of
pairwise
connections
is
just
too
much
state
when
DTRS
is
not
for
you,
I
think,
that's
very
fair
and
making
clarifying
that
can
help.
K
E
F
E
You're
getting
here
so
if
your
deployment
model
is
to
plug
2,000
Reuters
into
a
single
switch,
Babel
is
not
the
right
protocol.
Now,
the
complexity
of
Babel
is
not
count
by
DTLS
in
Babel,
you
have
a
labor
data
structure
for
every
one
of
your
neighbors.
The
number
of
neighbors
does
not
change
with
DTLS.
All
you
get
is
a
slightly
larger
data
structure,
originator
because
you
have
the
pls
rate,
but
the
complexity.
In
contrast,.
J
Oh
ok,
so
this
is
going
to
be
really
really
quick.
Julie
has
told
me
that
I
had
to
present
on
Babel
security
stuff
in
home
net,
and
so
this
is
what
I'm
going
to
be
telling
them.
How
do
you
fine-tune
this.
D
J
Yeah,
maybe
you
should
okay,
so
this
should.
There
should
be
absolutely
no
surprises
to
anybody
on
this
slide,
because
I'm
pretty
sure
you
just
heard
everything
that
is
here
and
yeah
any
surprises,
no
okay.
So
this
is
slide
2,
and
these
are
the
points
that
I
was
told
to
convey
to
home
that
they
expected
to
recommend
one
security
mechanism
for
all
Babel
implementations,
but
independent
of
that
home.
J
That
needs
to
pick
one
that
it
would
thinks,
make
sense
in
the
context
of
the
home
net
use
case,
and
they
also
need
to
you
know
once
these
straps
progress.
If
there's
any
optional
features
that
they
want
to
make
mandatory
things
like
that,
they
need
to
figure
that
out
and
then
the
biggie
is,
of
course,
how
in
the
world,
do
you
distribute
the
stupid,
keys
and
credentials?
I
D
H
J
We
need
to
further
discuss
what
we,
how
to
describe
whether
we
use
the
leftmost
bit
the
most
significant
bit
or
some
variation
on
Indian
Asst,
which
personally
I'm
not
a
fan
of
using
the
term
Indian
n't,
convey
what
I'm
thinking
of
seeing
but
I'm
not
going
to
go
there
right
here
because
I,
don't
think,
that's
an
important
discussion
for
us
to
have
here.
Then
there
was
thing
about
the
unicast
hellos
and
things
and
representing
them
in
the
data
model
and
I.
J
Think
Tokyo
and
Julius
are
absolutely
right,
of
course,
and
so
I'm
just
going
to
do
what
they
tell
me
there
and
then
there's
this
IH.
U
interval
discussion
that
we've
been
having
and
we're
clearly
not
communicating
very
well
on
that
and
so
I'm
going
to
continue
that
one
on
the
list
and,
let's
see
then
comes
this
next
hop
address
and
I'm
going
to
have
to
you
know
once
Toki
gets
off
his
canoe,
better
understand
what
he's
talking
about
there,
and
so
that's
a
pretty
short
list
and
that's
good
and
they're
all
minor.
J
H
J
J
What
about
this
things
at
the
end
and
I've
just
compiled
a
whole
bunch
of
what
about
this
things
that
you
know,
people
may
or
may
not
agree
with
the
decisions
I've
made
and
so
I've
just
sort
of
here
recorded
some
of
the
decisions
I've
made
on
these
and
I'd
like
to
see
if
anybody
has
any
heartburn
over
the
decisions
I've
made
on
any
of
these
because
I'm
thinking
in
my
next
draft
I'm
going
to
just
close
all
these
issues,
nobody
has
anything
to
say
on
them.
J
So,
let's
see
I
think
we
actually
yeah
fix
the
interfaces.
Object,
stuff
and
Julius
haven't
complained
in
a
while,
so
I
think
we're
actually
fine
on
number
one,
and
unless
Julius
complains
I'm
going
to
number
one
to
the
closed
state
and
then
statistics
and
logs
there
had
been
some
initial
discussion
about
statistics
and
logging
and
I
included
a
few
logs,
specifically
a
log
about
attempts
to
use
security
pairing.
J
That
is,
you
know
when
you
see
a
new
device
to
kind
of
do
it
do
a
bit
of
logging
that
you
see
something
new
and
it
says
that
it
it's
okay,
but
you
know
that
way.
If
you
ever
have
any
questions
as
user
and
you're
going
through
the
log
which
we
all
do
all
the
time
and
then
I
think
I've
got
another
log
on
you.
Can
optionally
log
your
hello
messages
and
that's
the
entire
extent
of
logging
and
I'm
not
doing
any
statistics.
J
J
People
may
want
to
look
at
those
logs
to
see
if
what
I've
defined
for
logging
is
good
enough,
but
anyway,
then
comes
the
basic
security
model,
which
is
really
just
about
managing
credentials.
I
in
having
a
log,
I,
really
don't
see
anything
else
to
model
in
the
area
of
security
other
than
maintaining
a
log
and
maintaining
credentials
next
slide.
Please
oh
wait.
We
have
a
taker.
J
J
L
Security
parameters
are
you?
Have
you
looked
at
any
of
T,
not
permanent
and
I
know
that
sorry.
This
is
an
information
model
but
I'm
sure
in
terms
of
trying
to
collect
security
parameters.
Have
you
looked
at
any
of
the
other
so-called
data
models
that
are
that
I
have
defined
security
parameters,
whether
it
is
from
a
certificate
or
a
user?
A
polarity
information
that
you
could
probably
need
as
part
of
Babel
I.
Don't
know
I'm
new
in
that
sense,
so
so.
J
J
J
J
J
A
hello
message
that
was
or
was
not
received
and
he's
got
that
in
16
bits
and
so
I
kind
of
modeled
that
because
I
thought
it
you
know,
if
others
might
choose
to
implement
that,
since
he
does
describe
that
in
his
appendix
that
it
would
be
kind
of
cool
to
at
least
be
able
to
report
it.
Well,
it's
kind
of
a
good
thing
to
be
able
to
report
it
if
you
implement
it.
So
we
do
have
that
and
I
think
the
discussion
on
that
was
that
fine,
it's
optional.
J
Even
though
6126
abyss
says
that
they
don't
have
to
be
integers
and
unless
somebody
insists
otherwise
I,
don't
know
what
the
heck
they
are
so
I'm
leaving
them
as
integers
should
Babel
link
types
have
an
eye
in
a
registry
right
now.
None
is
defined
and
then
will
be
defined
unless
somebody
says
they
need
to
be
defined
and
then
for
the
security
log.
Should
it
also
log
whether
the
credentials
were
considered?
Okay
right
now
it
doesn't
and
I
think
that's.
Okay,
because
if
you
la
go
anyway,
that's
what
I
said.
E
D
K
E
So
I'd,
rather
like
babble,
and
one
of
the
reasons
why
I
think
babble
is
critical,
is
it's
a
great
platform
for
experimenting
with
various
link
quality
estimation?
Algorithms.
So
if
you're
using
OSPF
or
is,
is
which
are
great
routing
protocols,
you
have
to
be
very
careful
about
what
you
do
with
your
metrics
and
what
you
do
with
your
link.
Quality
with
Babel.
You
just
can
go
ahead
and
experiment
with
ending
everything.
E
It
will
still
interoperate
and
still
remain
loop
free,
so
I
would
like
I
believe
that
people
will
want
to
implement
various
experimental
link
types
and
I'm
afraid
that
an
IANA
registry,
for
this
would
be
a
little,
would
prevent
experimentation.
So
I'd
like
to
keep
this
as
a
human
readable
as
a
human,
readable,
freeform
text
field,
rather
than
something
that
is
controlled
by
a
registry.
J
E
D
L
K
I
just
realized
afterwards
what
my
educated
guess
is
based
the
link
types.
They
do
not
take
care
in
protocol
and
quorum,
and
that
makes
difference
when
it
is
on
the
wire
you
need
to
register.
Well,
it
is
not
affect
your
leg
if
it.
If
the
new
type
never
leaves
the
space
of
the
speaker,
then
it
is
unlikely
that
the
register
of
making
a
difference,
I
think
I
had
read
about
it
somewhere,
but
but
most
remember,
but
that's
what
my
guess
is
based
of
that
fact.
It
does
not
appear
on
the
wire.
J
I
There
is
cannot
see
Apple
in
an
interesting
turn
of
events.
I
think
I
agree
with
everything
everyone
has
said
so
far,
which
is
strange
because
at
first
I
was
kind
of
pushing
against
for
I.
Think
Jose
did
a
good
job
of
describing
the
reasons
against,
but
as
long
as
this
is
a
string
that
is
just
used
in
this
model-
and
we
say
anything
that
starts
with
an
underscore
is
for
experimentation.
You
can
go
nuts
there
and
other
ones.
We
have
a
registry,
then
that
sounds
like
a
solution
that
would
work
for
everyone.
J
Which
brings
in
and
I'll
put
it
in
in
this
draft
rather
than
in
any
other,
because
it's
really
referring
to
the
information
model.
Ok,
so
I
think
then
I
just
have
the
one
slide
left
so
I'm
going
to
produce
an
updated
revision
that
deals
with
everything
mentioned
in
these
slides,
including
link
type
I,
intend
to
create
a
TR
181
data
model.
Then
maybe
someone
else
will
create
a
yang
model
if
they're,
really
nice
and
then
after
I've
made
sure
that
I
can
create
a
tier
181
data
model.
I
would
like
to
ask
to
start.
D
D
D
It
gives
a
little
bit
longer
for
submitting
the
base
protocol
draft
because
of
the
possible
interactions
with
Gettys
with
security
and
so
forth,
and
source-specific
is
kind
of
timed
the
same
and
then
the
management
put
further
out,
maybe
further
the
necessary
I,
don't
know
so.
I
have
welcome
discussion
or
comments
here,
post
this
to
the
mailing
list
for
people
to
comment
there.
F
D
I
change
the
dates
for
these
three
I
believe
I
have
to
go
double-check,
but
I
think
that's
what
I
did
so.
These
are
already
exist,
existed
for
the
management
based
protocol
draft
and
applicability,
so
I
changed
the
dates
for
those
and
they're.
The
first
three
and
I
see.
There's
there
are
these
two
and
the
last
one
and
then
I
added
the
source
specific
one.
F
J
D
H
D
D
Actually
I
think
we
kept
on
schedule
pretty
well,
and
so
we
were
given
considerably
more
time
than
we
asked
for,
and
it
looks
like
we
did
go
over
what
I
originally
asked
for,
but
then
again
I
was
being
very
relaxed
at
all
this
time.
So
I
said
any
topic,
anybody
else
wants
to
bring
up.
I
guess
we'll
see
y'all
on
the
mailing
list
and
in
Bangkok
in
November.