►
From YouTube: IETF98-BABEL-20170328-1300
Description
BABEL meeting session at IETF98
2017/03/28 1300
A
B
A
D
D
C
D
D
E
F
Okay,
so
also
remains
to
be
seen,
looks
like
we
have
reason
a
lot
of
time
to
this
session,
some
of
the
time
from
the
shirt.
Well,
it's
less
than
the
time
schedule
for
the
session,
so
bidding
must
be
okay,
the
anybody
wish
to
add
topics
or
a
steed
in
the
round,
or
something
like
that
guess
not
so
just
real
quick
talk
about
the
document
status
and
use
the
status.
So
we
have
a
couple
working
your
documents,
which
are
issue
the
rfcs
by
the
oil
jrc
on
its
way
to
becoming
the
stems
track.
F
E
F
There
are
a
number
of
personal
graphs,
including
the
information
model
when
they're
targeted
becoming
a
label
draft,
and
there
are
the
using
and
ceramic
experimental
art
sees.
So
we
did
adopt
these
milestones
here,
which
we've
gotten
some
initial
adoption
of
drafts,
but
you
need
to
get
a
information
model
graph
to
the
opposite
of
the
risk.
That's
giving
you
that
fairly
soon
and
progressed
these
documents
through
the
process
and
hit
them
toward
being
shattered
fat
Bart's
use
when
appropriate.
F
F
B
F
G
G
The
applicability
statement
for
Babel,
which
is
urgent
and
three
extensions
raft
which
are
out
of
scope
for
this
working
group
as
far
as
I
know,
source
Pacific,
routing
and
that's
something
that
is
urgent
because
home
Nets
relies
on
that
and
unfortunately,
it's
going
to
change
quite
a
bit
in
the
following
weeks
or
months,
I'm
going
to
say
a
few
words:
there
is
rtt
based
routing.
So
that's
a
mature
specification
that
has
been
deployed
in
production
for
a
long
time
and
there
is
no
reason
why
it
should
change
and
it
is
not
urgent.
G
It's
completely
ready
that
needs
to
be
submitted,
but
I've
been
invited
as
long
as
2616.
This
is
not
ready.
It
would
be
a
bad
idea
to
ask
to
put
it
in
final
call,
that's
very
surprising.
That's
very
frustrating,
especially
for
the
student
who
did
the
work
and
there's
diversity.
Beirut.
Think
that's
something
that
I'm
excited
about
that
it's
neither
ready
nor
urgent,
so
I'm
not
going
to
speak
about
it,
I'm
not
really
happy
at
being
the
editor
five
documents.
But
that's
what
happens
when
you
work
with
students,
so
the
students
do
the
work.
G
G
Two
six
bits
is
the
merger
of
two
informational
individual
submission
rfcs,
which
are
six
one,
two
six
and
seven
557,
and
while
we
are
at
it,
we
are
obviously
doing
any
bug
fixes
to
any
known
bugs
that
we
found
in
the
old
RFC's
we're
doing
whatever
clarifications
are
deemed
to
be
needed
and
we
have
decided
so
that
was
Berlin
or
craig.
I
think
it
was
Berlin
where
we
decided
that
we
allow
ourselves
to
make
weekly
compatible
changes.
That's
a
polite
way
of
saying
technically
incompatible
that
it
doesn't
matter.
G
G
So
a
few
words
about
the
old
RFC
6126
was
published
in
2011
after
an
excruciating
review
by
Joe
Halpern,
who
was
extremely
helpful
over
a
period
of
a
good
six
months
and
since
then,
we've
done
for
important
extensions.
We've
had
three,
but
every
time
I
checked
there
is
one
more
so
I
think
it
might
actually
be
four
independent,
reimplement
ations
a
babble,
and
we
have
found
a
few
bugs
and
emissions
in
this
pack,
because
the
implementation
work
was
very
helpful
and
it
still
turns
out
to
be
good
enough
for
independent
implementation.
G
Next,
please,
now,
at
the
time
I
wrote,
6126
I
knew
I
wanted
a
extensible
protocol,
but
I
didn't
know
what
extensions
would
look
like
so
cut.
6126
says:
look
there
space
here
and
if
you
see
anything
in
this
space
you
just
silently
ignore
it,
because
I
don't
know
what
the
data
we
look
like
and
a
few
years
later
after
we
had
implemented,
tested
and
deployed
a
number
of
extensions.
We
decided
to
formalize
what
extensions
look
like
and
that's
what
7557
was
so
at
the
time
the
reviewer
7557,
with
a
little
bit
nervous
saying.
G
Are
you
sure
that
existing
implementations
do
obey
the
letter
in
this
peg?
Do
they
actually
ignore
the
extension
data?
And
the
answer
was
yes,
because
I've
checked,
because
I
knew
from
the
beginning
that
I
was
going
to
dump
extension
data
into
there.
So
to
summarize
7557
it
says
this
is
what
sub
T
LVS
look
like.
G
You
put
them
there
and
it
doesn't
say
the
other
place
that
was
free
in
626
of
the
packet
trailer
after
the
series
of
GL
ES,
and
it
ended
up
not
being
used
by
any
extension,
so
got
7557
says,
is
that
a
future
specification
might
or
might
not
define
what
the
packet
trailer
looks
like
for
now.
Don't
use
it.
The
fact
that
those
are
two
different.
Our
axis
is
due
to
purely
historical
reasons,
and
so
it's
a
natural
thing
to
ask
to
merge
them
next,
please,
okay!
G
G
That
is
not
at
all
so
I've,
been
through
everything
that
looked
babel
related
all
of
my
notes
and
as
far
as
I
know
where
I
have
fixed
all
the
known
bugs
in
6126
the
clarification
that
are
needed,
our
neighbor
acquisition
and
sending
up
requests
and
I'm
going
to
expand
on
that
in
a
while.
The
merger
of
7557
is
in
progress,
I'm
going
to
expand
on
that
in
a
while.
As
to
the
weekly
compatible
changes,
there
are
unicast
hellos
and
with
the
redefinition
of
updates
and
that's
tricky.
G
That
needs
to
be
done
and
I'm
definitely
going
to
big
about
it
in
this.
In
a
second
at
least
okay,
so
neighbor
acquisition,
RFC
6126,
does
not
tell
you
when
you
acquire
a
neighbor.
So
the
way
it
is
written
is
that,
once
you
have
dumped
a
neighbor
in
your
neighbor
data
structure,
you
may
exchange
routing
data
with
them
and
at
no
point
does
it
say
at
which
point
exactly
you
acquire
the
neighbor
and
the
reason
for
that
is
that,
from
the
point
of
view
of
Babel,
it
just
doesn't
matter
it's
a
distance
vector
protocol.
G
The
only
condition
is
if
you
want
to
speak
with
me
at
some
point,
you
will
need
to
acquire
me
as
a
neighbor,
and
there
was
a
very
technical
discussion
on
the
mailing
list
with
four
or
five
participants,
so
I'm,
sorry,
if
any
of
you
felt
excluded,
but
that
the
nature
of
the
things
sometimes
you
need
to
have
and
actually
discuss
details
of
the
data
structures,
and
there
was
a
majority
opinion
which
was
to
leave
it
vague.
We
liked
it
this
way,
all
of
our
implementations.
Do
it
differently.
G
G
So
my
reading
of
this
discussion
and
I
happen
to
belong
to
the
majority
opinion
is
to
leave
it
vague
and
one
thing
that
I'm
considering
and
I
would
like
some
opinions
on.
That
is
to
allow
extensions
to
tighten
the
rules.
On
the
one
hand,
it
would
make
H
max
security
happy.
On
the
other
hand,
I'm
not
really
comfortable
with
the
notion
to
say
look.
This
is
a
basic
procedure.
The
protocol,
oh
by
the
way,
extensions,
can
change
it.
So
I'd
like
to
know
if
there
are
any
other
opinions
that
hopeless
already
expressed
on
the
list.
H
To
slightly
say
differently,
what
you're,
saying
I'm
fine
well
I
think
the
best
solution
here
is
I'm.
Also
part
of
the
majority
opinion
is
to
say
that
if
the
H
mac-based
security
has
a
requirement
to
tighten
something
up,
that
document
should
define
that
I,
don't
think
we
should
allow
them
to
modify
how
things
work,
but
slightly
constraining
more
in
a
way
that
is
compatible.
What
the
original
document
seems,
okay,
as
in
extensions
can
say
by
the
way,
this
fundamental
part
of
the
algorithm,
which
can
be
done
in
a
or
b.
You
need
to
do
this.
H
G
It
doesn't.
That
is
exactly
what
makes
me
uncomfortable,
because
it
means
that
for
some
implementations
it
will
be
more
difficult
than
for
others
to
implement
H
max
security.
Oh
I,
don't
worry
so.
The
point
here
is
that
you
expect
an
extension
to
be
something
that
you
can
add
to
your
implementation.
Whatever
the
implementation
choices
you
made,
if
implementing
an
extension
requires
you
to
redo
your
implementation
from
scratch,
although
you
did
obey
the
original
protocol,
then
I
think
this
is
a
badly
designed
extension
I.
H
G
H
A
I
If
you
want
a
real
security
review
of
anything,
send
it
to
the
security
Directorate
I
mean
the
chair
should
be
able
to
do
that
and
they
would
be
able
to
get
us
some
feedback,
probably
I
mean
I
could
look
at
it
first.
If
we
want
to
look
for
low
hanging
fruit,
but
I
assume
it
was
written
by
somebody
who
knows
80%
about
security,
two
or
more.
J
So
the
outputs
have
to
be
compatible,
but
the
internal
logic
doesn't
have
to
be
I,
don't
know
if
that
type
of
approach
might
help
with
the
gap,
because
I
haven't
looked
at
the
requirement
repeat,
please
sometimes
we
specify
that
an
implementation
has
to
have
an
output
that
looks
like
the
results
of
as
if
the
implementation
had
run
this
finite
state
machine.
It
doesn't
have
to
do
the
machine.
It
just
has
to
be
compatible
with
in
well-defined
ways.
I,
don't
know
if
that
would
help
finesse
here
cuz.
I
have
it
looked
at
the
details.
I'm
not.
G
G
Ok,
so
Babel,
so
I've
tried
to
design
Babel
is
a
rather
robust
protocol
and
by
robust
here
I
mean
that
no
matter
how
bad
an
implementer
you
are
you're
not
going
to
break
much,
because
the
protocol
is
resistant
to
all
sorts
of
implementation
errors,
and
there
is
one
bit
so
I've
tried.
In
many
cases
there
is
a
big
temptation
to
the
tricky
optimizations
in
a
protocol.
I've
tried
to
refrain
as
much
as
possible,
and
you
know
that
I
work
with
students
who
I
was
under
a
lot
of,
and
students
like
to
be
smart.
G
So
you
know
that
I
was
under
a
lot
of
pressure
to
be
too
smart
for
the
good
at
the
protocol
and
I'm
proud
to
say
that
most
of
the
time
I'm
refrained
from
being
smart,
and
there
is
one
bit
that
I
didn't
manage
to
make
as
robust
as
I
want.
There
is
one
bid
that
is
actually
tricky.
It
is
one
to
send
requests
so
for
people
who
are
just
a
quick
common
for
people
who
are
not
familiar
with
the
protocol.
G
It
is
absolutely
terribly
written
and,
to
my
great
surprise,
even
that
is
good
enough
for
independently
implementation,
so
many
kudos
to
the
people
who
did
manage
to
reimplement
babel
correctly,
notwithstanding
my
very
dubious
pros,
this
bit
needs
to
be
rewriting
rewritten
and,
while
I
was
looking
at
it
I
realized
that
at
the
time,
I
didn't
fully
understand
the
issues.
I
was
a
little
bit
too
prescriptive,
so
I'm
going
to
make
it
a
little
bit
more
permissive.
I
have
a
proof
that
it
remains
correct.
G
I,
don't
have
a
proof
that
this
is
actually
the
minimum
requirement,
but
I
have
I'm
pretty
sure
we're
pretty
close
to
the
minimum
requirements.
That
should
be
no
problem
and
I've
described
it
all
in
an
email
to
the
mailings.
Next,
please:
okay,
unicast
hellos,
so
one
of
the
design
criterion
babble
is
that
all
tlds
can
be
sent
over
unicast
or
over
multicast,
whether
you're
sending
them
over
unicast
or
multicast,
is
purely
an
implementation
detail,
and
you
deal
with
it
like
you
want,
with
one
exception,
the
hello
tlv.
G
So
it
is
natural
to
have
that
hellos
be
sent
over
multicast
because
halos
are
used
for
discovery,
but
once
you've
discovered
your
neighbors,
you
might
want
to
send
hellos
over
unicast,
and
you
cannot
do
that.
They
cannot
do
that
first,
because
I
say
so
in
6126.
I
say:
must
not
you
know
in
capital
and
capital
letters,
and
that
means
you
really
must
not,
and
the
other
reason
is
that,
if
you
do,
then
you
might
want
to
send
a
hello
to
one
neighbor
and
not
another.
G
G
Now
there
are
at
least
four
people
and
at
least
three
active
implementers,
so
things
have
evolved.
Since
I
wrote
the
slides
last
time
for
clamoring
for
unicast
hello,
Sam,
something
has
to
be
done.
I
think
it
would
be
a
terrible
wasted
opportunity
if
we
missed
the
if
we
missed
if
we
missed
RFC
6126
this
and
didn't
do.
Unicast
hellos
in
it
and
I
would
really
like
the
people
who
are
interested
to
get
into
a
virtual
room
at
some
point
and
work
out
to
work
a
bill
designed
it
satisfies
all
the
requirements.
G
I
On
so
what
we
did
and
what
I
was
attempting
to
propose
in
the
mail
I
said,
but
maybe
wasn't
clear
enough,
is
that
every
time
we
would
have
sent
to
broadcast
hello
according
to
the
current
implementation
we
serialized.
So
we
sent
to
every
pier
on
that
interface
a
hello
every
time
whether
it
was
because
of
an
interval
whether
it
was
because
it
was
triggered
somehow
any
time
we
were
going
to
send
any
hello,
it
would
have
gone
out
broadcast
under
the
normal
implementation,
and
we
just
sent
it
to
every
pier
on
that
interface.
I
I
Your
point
about
I
hear
yours
was
good.
Was
it
was
a
good
point?
I
think
it
probably
should
be
pasta
to
include
the
I
hear
you
to
the
neighbor.
It
applies
to
and
send
the
hello
to
the
other
neighbors
on
the
same
link.
At
the
same
time,
without
the
I
hear
you,
but
my
proposal
doesn't
actually
say
that,
and
we
probably
should
but
other
than
that,
that's
what
I
was
proposing,
because
that's
what
we
implemented
so
I
know
that
works.
I'd,
be
willing
to
discuss
other
things,
but
I'd
like
to
see
them
work.
L
Donald
sharp
so
when
I
implement
it
remote
neighbors
in
the
ER
grp
actually
made
it
so
that
you
could
send
unicast
hello
just
so
so
that
I
could
get
the
packet
to
whoever
I
wasn't
trying
to
talk
to
do.
You
have
concerns
about
having
neighbors
that
aren't
one
hop
away
more
than
one
hop
away
and
double.
G
A
F
H
J
A
I
Don't
I
mean
my
implementation?
Currently
it's
it's
a
very
specialized
implementation
that
is
actually
for
a
different
use.
It's
actually
for
an
amphib
related
protocol
and
it
runs
over
gssapi.
Every
babble
message
is
a
GSA
API
token
running
over
an
encrypted
TCP
connection,
so
I
know
I,
don't
have
any
multicast
related
anything.
There
are
also
non
multicast
networks.
I
I
mean
if
you
had
peer-to-peer
neighbors
they're,
just
another
interface
right
like
so.
I
can't
come
up
with
one
where
I've
got
a
group
of
unicast
neighbors
on
the
same
interface
and
a
group
of
multicast,
neighbors
I,
don't
know
one
another
interface,
I'm
not
sure
I
don't
know.
I
don't
know,
I'm
not
sure
what
the
scenario
would
be.
H
J
H
It's
true
my
implementation
had
does
its
own
stuff
too,
but
I
can
see
like
at
least
from
what
I've
been
hearing
about
the
current
fable
community.
They
can
run
different
versions
and
everything
should
still
work
and
I
think
getting
something
that
would
support
the
interaction
and
also
not
required
saying
to
anyone
shouldn't
be
too
complicated.
We
would
I
definitely
wish
get
in
a
room
and
bash
it
out.
Room
could
give
our
trouble
should
be,
and
but
like
having
something
as
simple
as
like
in
your
periodic
multicast
hellos
that
are
those
are
used
for
discovery.
H
G
H
D
Brass
Weidman
10,
as
a
matter
of
fact,
many
routing
protocols
do
consider
any
packet
received
from
the
neighbor
as
a
hallo.
Even
if
it's
not
technically
hello,
so
some
protocols,
like
eigrp,
will
actually
send
what
is
effectively
minky
unicast
packet,
because
it
knows
the
other
then
we'll
go.
Oh,
that
was
a
below
I
keep
this
guy
alive,
so
it's
not
even
defined
as
a
whole.
Lot
per
se.
H
G
Necklace,
it's
okay,
so
integration
of
sick
of
65,
57
and
26
126
conceptually
easy
editorially
tricky.
There
have
been
three
attempts,
so
the
first
one
was
very
helpful
by
Toki
and
I'm
very
grateful
to
Toki,
because
you
showed
me
what
doesn't
work
that
if
you
just
took
7557,
did
some
editing
of
the
stuff
and
put
it
at
a
separate
section,
which
seemed
like
a
good
idea
and
it
turned
out
to
not
read
very
well
because
you
end
up
with
a
document
that
says
here.
G
G
Let
it
work
in
my
brain
and
this
time
I
got
something
that
works.
It
does
read
correctly,
except
that
it
feels
a
little
bit
like
you
know,
an
American
series
from
the
1970s
like
Dallas
or
dynasty,
or
something
like
that
where
you
go
and
there's
a
lot
of
drama.
Okay
like
this
is
the
format
of
TL
vs
and
everyone
is
crying
and
having
his
text
and
then
at
the
end
you
say,
oh
by
the
way
you
resolve
the
trauma
by
saying
by
the
way
we
don't
define
any
sub
GL
v's
in
this
document.
G
So
except
for
the
somewhat
imbalance
it
does
appear
to
work
pretty.
Well
and
I
didn't
make
it
in
time
before
the
cutoff
to
send
it
to
you
all
will
do
pretty
sit
next,
please
so
before
I
tell
you
about
the
semi
compatible
changes
that
we
are
planning.
I
need
to
make
a
quick
digression
about
source-specific
routing,
not
going
to
tell
you
what's
or
specific
routing
is,
but
it's
the
best
things
and
somebody
invented
next-hop
routing.
It
is
the
most
exciting
extension
that
we've
done
in
Babel.
G
It
is
with
the
work
of
matoub
G,
my
grad
student,
and
that
is
something
that
I'm
very,
very
excited
about.
It
works
beautifully
well
in
Babel,
it
is
a
production-ready
implementation.
There
are
a
few
people
who
are
deploying
it
in
real
networks,
and
the
package
format
is
an
absolute
mess.
We
define
three
new
TLDs
and
trust
me.
Those
tvs
are
not
pretty
at
all.
They
have
way
too
many
fields.
They
resemble
nothing
like
the
other
TL
DS
in
Babel
implementing.
It
is
impossible
to
decode
them
on
site.
G
They
are
even
after
working
on
that
for
months
and
that's
really
not
a
pretty
sight
next,
please,
and
so
we
would
like
to
change
the
packet
format,
and
one
thing
would
be
to
add
a
mandatory
bit
to
sub
deities.
Okay,
so
have
the
source.
Traffics
information
for
specific
routing
appear
is
a
subtlety
of
the
normal
update,
tlv
but
marked
with
a
mandatory
bit,
so
that,
if
you
don't
understand
this
sub
T
lvu
drop
the
whole
tlv
and
that
doesn't
make
me
comfortable
doesn't
fit
well
into
Babel.
G
The
other
solution
is
to
use
the
AE
mechanisms,
which
is
already
in
battle
next,
please.
So
every
update
and
request
in
Babel
carries
a
one
octet
field
known
as
the
address
and
codec,
so
think
of
it
as
being
the
address
family.
It's
a
field
that
tells
you
this
is
ipv4
ipv6
or
I
tvpad.
However,
it's
I
don't
call
it
an
address
family
because
it
carries
some
more
information.
You
can
say
things
like
this
is
a
compressed
ipv6
link
local
address
without
the
fe
80,
prefix
and
stuff
like
that.
G
So
what
that
means
is
that
you
no
longer
have
three
new
TLDs.
You
have
zero
new
TLDs,
just
a
new
Eddie
e
value,
but
you
need
changes
to
the
bay
specification
because
updates
have
two
rigid,
a
format
right
now
for
to
be
able
to
carry
sore
specific
updates,
and
you
need
to
define
very
precisely
how
address
compression
I
don't
want
get
into
the
details,
works
with
unknown
AES.
G
So
we've
got.
There's
three
of
us
having
this
discussion
back
in
Paris
and
that
doesn't
prevent
us
from
having
almost
three
different
opinions,
which
is
pretty
good
and
we've
already
managed
to
have
for
opinions.
Well,
there
were
three
of
us
one
opinion
which
is
the
current
favorite
and
the
due
to
mature
booty.
So
he's
convinced
me
is
to
make
the
payload
of
updates
a
pack.
So
an
update
just
says
there
is
some
data
after
the
header.
G
If
you
don't
understand
the
ID
just
skip
the
whole
tlv
and
no
structure
at
all,
so
the
problem
with
that
is
that
you
have
to
parse
every
single
AE
separately.
The
other
problem
with
that
is
that
you
cannot
parse
the
sub
T
lbs
of
tlv
that
you
understand,
but
you
don't
understand
the
AE.
The
nice
side
is
that
it's
very
flexible.
The
other
opinion
which
was
originally
mine
is
to
make
it
as
precise
as
possible
to
encode
both
sore
specific
updates
and
normal
updates.
G
And
then
we
recently,
the
team
was
joined
by
an
AC
student
Wendell
in
schwann
and
Gwendolen
has
been
there
for
two
weeks,
but
that
doesn't
prevent
her
from
already
disagreeing
from
us,
which
is
a
very
good
sign
and
she's
saying
just
stop
with
the
skull.
Ae
mess
just
use
a
mandatory
bit.
Ok
Gwendoline
has
be
cheeky
experience
from
the
previous
internship,
and
so
since
we're
disagreeing,
that
probably
means
that
we
need
more
data.
I
When
I
am
learned
about
this
yesterday,
I
actually
thought
that
the
mandatory
bit
was
right.
Ok,
even
though
you
were
saying
you
thought
the
other
one
was
right,
but
then
I
happened
to
read
over
the
whole
document
since
then,
and
it
occurred
to
me
that
if
you
don't
know
the
AE,
then
I
mean
you're
not
just
going
to
run.
Babel
I
mean
the
point
is
to
run
Babel,
so
you
can
have
information
about
how
to
forward
packets
what
direction
to
forward
packets
in.
I
But
if
you
don't
know
the
AE
for
a
particular
type
of
route,
you're
not
going
to
know
how
to
use
it
to
forward
packets
anyway,
are
you
so
I
think
it's
perfectly
fine
to
make
it
opaque?
And
it's
like
you
know
about
that,
a
you
process
it.
If
you
don't
you
don't,
because
how
are
you
going
to
know
what
to
use
it
for
if
it's
for
an
address
family,
you
don't
understand
I,
don't
so.
G
H
The
main
issue
and
I
dates,
kanazawa
and
I
totally
agree
and
same
like
my
implementation,
doesn't
support
ipv4
and
if
their
update
elect
sub
theories
of
any
kind
of
all
like
fancy
properties
of
this
ipv4
address,
I
like
what
am
I
going
to
do
with
them
like.
Is
there
an
example
of
a
case
where
this
dis
address?
That
does
something,
but
with
extensions
we
only
want
the
extensions
like
I.
Don't
see
that
ever
happening
or
or
did
you
have
an
idea
in
mind
and.
I
H
G
A
M
What
Dave
said
on
the
jabber
is
AE
is
good,
I,
do
kind
of
think
we
end
up
with
more
than
one
new
AE.
Do
we
end
up
with
a
mirror
image
of
the
existing
for
AES
and
by
the
way
Toki
says?
Bird
will
also
drop
the
entire
tlv.
If
it
doesn't
understand
the
AE
dave,
says
AE
for
sake
of
argument
mpls,
what
other
aes
are
possibly
needed,
thanks
Barbara.
H
G
Absolutely
that
requires
some
very
careful
looking
at
compatibility
with
unknown
a
tease,
yeah,
ok,
so
the
Babel
applicability
statement
at
some
point
I
discovered
my
great
horror
that
I
have
to
write
an
applicability
that
an
applicability
statement
was
desired
by
the
IETF
for
babel,
so
it
has
so.
This
applicability
statement
has
a
long
history.
The
first
version
was
one
sentence
longer.
It
said
it's
a
routing
protocol,
its
roots,
and
that
was
considered
as
too
short.
G
So
then
I
wrote
a
document
that
I
called
Babel
doesn't
care,
and
that
was
considered
too
funny
and
then
I
wrote
the
last
version
which
I
called
applicability
statement,
and
that
was
considered
too
sober,
so
I'm
going
to
spend
a
few
minutes
telling
you
about
my
literary
experiences
with
the
applicability
statement.
Next,
please
so
my
first
version
was
one
sentence
longer.
It
said
it's
a
routing
protocol,
for
goodness
sake
its
roots
and
the
friendly
ad
consider
that
it
was
too
short
I
think
she
mentioned
that,
while
technically
correct.
G
This
is
somewhat
do
short,
so
I
wanted
to
make
a
two-sentence
long,
but
well
the
ad
is
friendly.
I
was
afraid
she
might
no
longer
find
it
funny
at
that
point.
So
I
spend
a
whole
Sunday
afternoon.
Reading
applicability
statements
next,
please
so
I
don't
know
if
you've
ever
send
a
whole
afternoon
reading
applicability
statements.
It
has
an
effect
on
your
brain.
It
does
change
you
and
at
that
point
I
sat
down
and
by
2
a.m.
G
I
had
produced
a
document
that
was
called
Babel
doesn't
care,
and
this
document
I
sent,
I
submit
it
straight
away
before
I
could
think
it
over
as
an
internet
draft-
and
you
know
I'm
going
to
do
you
know
like
english
language
books
than
to
heaven.
The
dust
cover
those
made-up
quotations,
so
those
are
not
made
up.
Those
are
authentic,
so
one
of
the
quotations
was
this
is
the
best
IETF
draft
ever
that
was
not
Donald
Trump.
G
It's
a
different
dt
here
and
the
other
comment
by
someone
whose
initials
are
TL
is
reminds
me
of
the
honey
badger.
So
if
you
don't
know
about
the
honey
badger
after
this
meeting
is
over
just
going
over
to
youtube
and
type
like
honey,
badger
and
another
person
who
was
actually
helpful,
sent
me
a
long
email
trying
to
be
polite,
but
you
felt
the
irritation
between
the
lines
and
he
said:
look
it's
not
an
applicability
statement.
You're
just
bragging,
it's
funny,
but
really
you're,
just
bragging
so
I
read
it.
G
I
was
really
quite
frustrated
by
this
comment.
That's
not
a
nice
thing,
because
I'm,
a
very
modest
person
or
like
the
thing
so
and
so
I
read
through
it
and
I,
said:
damn
he's
right.
Next,
please
and
so
I
said:
okay
I'm,
going
to
write
a
very
sober
document
and
I
wrote
an
extremely
sober
document
called
Babel
applicability
statement.
How
sad
and
this
in
this
document,
I
swear
I
didn't
do
any
bragging
at
all.
G
I,
just
soberly
described
existing
deployments
of
Babel
and
this
document
spent
quite
a
few
months
maturing
in
their
ATF
archives
and
then
I
called
Donald
and
said.
Look.
What
do
we
do?
Is
that
and
Donal
did
the
typical,
don't
think
which
consisted
in
sending
in
straight
away.
For
final
call-
and
there
was
a
review
next
please-
and
there
was
an
extremely
helpful
review
by
someone
I
didn't
know.
Alexander
Weinstein
did
a
great
job.
G
So
it's
a
long
review
because
he's
trying
to
be
polite,
but
if
you
remove
all
the
Bedford
keeper
he's
trying
it
not
to
wound
my
feelings,
the
main
three
points
he's
making
is
that
she
needs
an
introduction.
He
needs
a
more
precise
data
about
the
existing
deployments
and
he
wants
to
know
which
extensions
are
being
used.
So
I
strongly
agree
with
points1
entry
here.
This
document
needs
an
introduction,
and
this
document
needs
more
information
about
the
extensions
I.
Don't
necessarily
disagree
with
want
to.
D
A
D
I
think
you're
perfectly
safe,
leaving
that
out
of
this
document
until
a
more
experienced
that
is
more
open
that
can
be
discussed
is
available.
In
writing.
A
completely
separate
document
at
that
time
called
an
experience
with
federal
deployments
document
when
that
time
comes
I,
don't
think
you
need
it
for
this
document,
personal.
F
If
I
could
Donald
up
so
I
believe
this
Terrace
in
this
was
that
there
was
not
really
enough
response
to
birth.
Would
you
call,
and
but
so
I
thought
ish
we
modified
and
do
another
version
of
us
call
based
after
these
changed
dude
who's
watching
this
conical
made.
That
might
remember
that's
what
I
remember
this
dad
is
to
be.
G
G
We
also
plan
for
a
complete
draft
of
the
applicability
statement
in
crag
and
the
main,
and
the
main
stumbling
block
here
is
that
it's
extremely
boring
work,
especially
if
I'm
not
allowed
to
brag,
and
we
will
hopefully
have
a
new
draft
of
SAR
specific
routing
with
the
new
encoding
and
depending
on
how
gwendolyn's
work
does
goes,
we
might
have
a
draft
for
TOS
routing.
So
when
I'm
saying
here
is
that
we
are
aiming
to
do
it
in
I
have
so.
G
There
are,
of
course,
the
official
deadlines
of
the
ITF,
but
there
is
another
deadline
for
me
that
in
September
teaching
starts,
and
that
means
I'm
completely
out
of
circulation
for
any
stuff
except
teaching.
So
for
me
it's
a
vital
thing
to
get
all
of
this
done
before
july.
Thank
you
very
much
for
attention.
F
E
And
now
the
question
comes
the
problem
coming
and
we
know
if
we
want
to
deploy
here,
but
technology
in
small
network
we
must,
we
can
use.
Babo
is
under
a
protocol
voyage,
but
at
the
same
time
we
mustered
wrong
Mr
D
to
transfer
the
overlay
information.
The
information
includes
matic
has
the
search,
the
information
and
group
information,
so
the
receiver
and
the
sender
will
know
who
each
other.
E
So
he
will
exchange
the
information
and
knows
how
to
stand
at
the
pier
package
and
after
F
F
at
exist
hidden
the
network
that
somebody
will
want
only
one
protocol
I.
Don't
need
a
mr,
be
I
only
want
pebble
at
this
network
exists.
I,
don't
I
have
no
idea
about
it.
So
so
this
is
my
idea
about
it.
I
wanted
to
have
discussion
with
our
people
to
to
think
Adam.
Adam
should
be
forward
move
forward
or
doesn't
make
sense.
E
So
the
solution
is
very
simple:
we
only
use
one
protocol
in
network
just
as
people
Bible,
so
we
use
pebble
to
view
the
beer
multicast,
the
forwarding
plane
and
it's
the
same
time
we
use
be
able
to
advertise
both
cast
the
information
included,
the
and
source
information
and
as
a
groupie
information,
Eric
R
means
the
last
hop
return.
It
means
the
new
target
near
the
receiver,
who
wants
to
receive
the
multicast
low
and
average.
E
E
Hr
collects
the
requirements
of
air
hrs
and
the
buttes
mapping,
relationship
between
multicast,
follow
and
the
beer
destination
bit
stream
and
the
the
formatting
is
very
simple,
because
we
only
use
some
curvy
of
the
pebble
critics.
So
we
advertise
the
group
at
address
and
a
sort
of
a
Prius
lineage
and
the
sausages
may
be
0,
because
we,
some
receiver
only
know
I
wanted
to
receive
some
group
and
I
don't
know
the
source.
So
here
we
are
senator
and
sub.
Q
is
only
the
group,
yes,
no
sauce.
Yes,.
E
And
so
this
is
the
multi
Custer
small
Network
and
they're
a
job.
You
know
there
may
be
many
hrs
and
hy
f
how
epic
I
know
who
the
who
is
who,
as
the
air
hrs
so
and
we
use
pebble,
update
message
to
transfer
the
multicast
source
information
and
the
global
information
and
the
the
prefix
must
not
be
summarized
so.
This
information
can
be
transferred
to
every
node
in
the
network
and
the
potentially
sauce
or
fhr
will
know
the
potential
receivers.
E
G
Different
encoding-
and
that
is
what
I
mentioned
when
I
was
speaking
earlier
about.
The
fact
about
updates-
is
that
we
are
now
in
the
process
of
trying
to
find
out
what
is
the
right
way
to
encode
that
this
car
kind
of
information
in
Babel,
so
perhaps
we'll
come
to
the
conclusion
that
we
do
need
mandatory
and
transitive
this,
but
our
current
thinking
right
now
is
that
this
can
be
done
with
a
different
AE
number.
Now,
if
you
look
at
this
slide,
that's
what
you're
writing
here.
You're
saying:
look
I'm
encoding
this
as
a
graphics,
yeah.
I
G
To
aggregate
it
so
actually
it
looks
like
a
perfect,
but
it's
not
really
a
graphics
right,
so
that
would
seem
to
imply
that
saying
UAE
number
that
it
should
not
be
encode
that,
like
this,
the
other
comment,
if
you
can
come
back
to
the
previous
slide,
the
one
with
the
packet
format
so
Babel
is
designed
to
be
implemented
in
tonight's
I.
Think
that's
the
shortest
implementation
and
in
particular
it
does
not
have
a
recursive
parser.
So
it's
not
like
an
is,
is
or
you
can
have
tlds
within
tlds
within
GL
v's
within
tlds.
G
G
Ok,
so
here
you
are
in
your
encoding,
as
I've
said,
I
think
that
there
are
good
reasons
why
this
is
not
the
incumbent
that
we
want,
but
in
your
encoding
you're
introducing
for
the
first
time
in
Babel,
a
sub-sub
TLD.
Now
perhaps
there's
good
reason.
Perhaps
we
do
need
sub
sub
T
alvey's,
ok,
but
my
my
feeling
here
would
be
that
we
should
not
introduce
a
third
level
of
tal
vez
unless
we're
convinced
that
we
really
have
a
good
reason
why
we
eat
them.
I.
G
E
And
I
must
occur
by
Lodge.
This
document
is
not
the
same
as
the
hakama
data
I
presented
a
yin
thora
meeting
in
SAR
meeting
at
the
pier
extension,
and
this
is
what
has
the
information
extension
at
a
carry
the
different
things
in
edge
yeah,
your
extension
as
important,
so
are
we
I
want
to
know?
If
this
is,
we
did.
E
J
Yeah
atlas,
so
we
do
encourage
running
code,
and
in
this
working
group
there
is
general
agreement
that
really
get
some
code
in
place
to
see.
What's
going
on,
as
Julia
says,
it
doesn't
take
a
lot
to
do
some
of
the
implementation
and
they're
open
source
implementations
out
there,
where
you
can
take
what
you
have
for
your
ideas
and
see
how
well
they
play
out
and
see
what
happens
when
you
try
and
do
something.
J
So
while
there
are
many
drafts
in
different
areas
where
in
different
working
groups
where
there
isn't,
there
is
not
such
a
strong
emphasis
on
having
an
implementation.
First
in
this
working
group,
there
is
a
desire
to
have
that
as
a
good
baseline,
because
it's
fairly
straightforward
and
because
it
doesn't
have
the
same
decades,
sorry
of
history,
that
some
of
the
existing
protocols
do
that
make
us
know
how
to
extend
it.
It's.
E
G
A
M
F
M
Anyway,
I
hastily,
through
this
together
in
preparation
for
this
meeting
and
I,
just
feel
so
bad.
I
haven't
put
enough
time
in
it,
but
anyway
next
slide.
This
is
about
the
information
model
that
is
part
of
the
Charter,
and
I
did
make
some
changes
to
the
draft
that
I
submitted
way
back
in
Berlin
and
I
went
back
and
I
dragged
out
Julius
email
where
he
recommended
changes
and
I
tried
to
apply
them
and
I
just
failed,
because
I
actually
missed
some
of
the
stuff
he
said,
but
so
be
it.
M
M
G
I'll
just
mention
that
I've
got
three
students
the
summer
working
on
speaking
to
a
babble
demon
and
extracting
stuff
from
the
babble
demon
and
drawing
pretty
pictures
and
screen,
and
if
you
have
actual
suggestions
of
what
data
they
should
be
producing,
I
mean
producing
some
JSON
or
whatever.
Once
they
are
speaking
to
the
babble
demon
should
be
no
problem,
I'm
sure
they
will
be
willing
to
do
it.
So.
M
G
E
M
M
M
J
F
So
well
I
guess
the
people
feel
I
seems
to
me
too,
probably
after
one
more
Rev
but
the
personal
graph.
We
could
do
a
call
for
adoption.
I
mean
they
were
sort
of
working
on
it
as
it
is
I
mean
I,
don't
know
they
say,
there's
consensus
that
we
should
adopt
it
and
we're
flattered
as
a
working
of
document.
E
F
I
Read
the
previous
version,
I
I'm
sorry
I
didn't
read
this
one,
but
it
sounds
like
it
was
even
improved
from
there
and
I
usually
think
you
can
make
something
working
group
document.
If
you
think
it's
a
really
good
basis
for
the
working
group
to
start
and
I
would
have
said,
the
previous
one
was
good
enough,
so
I'm
all
for
like
making
a
call
to
make
it
a
working
group
item
I.
Think.