►
From YouTube: IETF101-BABEL-20180322-1810
Description
BABEL meeting session at IETF101
2018/03/22 1810
https://datatracker.ietf.org/meeting/101/proceedings/
A
C
C
B
D
E
F
A
Welcome
to
Babel,
so
what's
our
agenda
start
with
we're
gonna
start
with
oh
I'm,
Ross
white
I'm,
a
routing
II.
A
It's
Martin
now
right.
G
G
G
G
We're
not
behind
schedule
yet
so
and
anyway,
so
just
quickly
review
status.
We've
got
these
I.
Guess,
there's
a
your
I!
Don't
have
your
draft
on
here?
They'd
have
sixty
one
twenty
six
bits
that
I
didn't
update
this
recently
anyway.
There's
it
was
it?
Neither
working
group
adopted
drafts
to
the
home
that
draft
and
I
guess
it
doesn't
have
any
problem
personal
graphs
on
here,
except
for
they
Ted
lemon
home
that
graft
and,
of
course,
there's
the
original
instead
of
RFC.
So
I
guess
there's
a
seventy
to
ninety
eight
bits,
right
yeah!
G
So
that's
also
maybe
I'll
lift
lists
the
personal
drafts
next
time.
So
we're
kind
of
behind
on
our
milestones
so
not
too
much
to
say
about
that.
Possibly
we
should
revise
the
milestones
to
get
them
back
in
sync,
where
we
think
the
working
group
really
is,
but
if
we
can
do
that
offline
and
stuff
I,
don't
have
any
proposal
for
changing
the
milestones
currently
or
anything.
H
G
G
A
G
A
G
K
K
G
K
Alright
and
I
can
maybe
yes,
amazing,
all
right
awesome,
yes,
hello,
everyone,
my
name
is
Toki
Harlan,
Jorgensen
and
I.
Am
the
author
of
the
bird
implementation
of
Babel
and
I
am
going
to
give
you
a
short
update
on
the
status
of
this
implementation
since
it's
been
a
while,
since
you've
been
forced
to
listen
to
me,
so
a
quick
recap
for
those
who
don't
know
what
the
bat
what
the
bird
running
demon
is.
So
it's
a
from
scratch
implementation
of
a
lot
of
major
routing
protocols.
K
It
already
spoke
BGP,
OSPF,
rip,
PDF
and
Ra,
some
of
which
you
might
notice
a
non-action
routing
protocols,
but
they
were
there
as
well
and
I
added
Babel
support
to
this
a
few
years
ago.
It's
a
very
nice
implementation
in
very
nice
demon,
clean
code,
well-organized,
readable
and
the
demon
itself
is
pretty
scalable
as
there's
no
problems
using
this
boy
for
bgp
routing
table
from
sam'l.
So
this
seemed
like
a
cool
place
to
implement
Babel
and,
of
course,
pet
bird
is
also
developed
by
some
friendly
and
very
meticulous
Czech
people,
which
is
really
nice.
K
K
So
this
is
not
actually
speaking
Babel
of
you,
but
this
carries
the
before
out
over
the
v6
packets,
just
as
Babel
D
does,
and
it
does
that
in
their
way
that
interoperates
with
the
original
Babel
the
implementation
as
well
members
been
a
few
updates
since
then,
as
we've
been
working
with
RFC
6120
6
this,
so
we've
added
SAP,
TLB
passing
and
we
now
I
know
the
mandatory
bit
as
well
and
discard
all
mandatory
such
a
always
that
we
don't
know
which
is
basically
all
of
them.
With
one
exception.
K
But
that
means
that
there
is
now
a
released
version
of
the
variant
daemon
that
speaks
so
specific
routing
from
the
updated
draft.
So
that
is
the
implementation
of
Babel
so
specifically,
which
means
that
it
will
speak
to
the
gate
version
of
Babel
v,
but
sympathy
encoding
has
changed
just
not
interoperate
with
the
legacy
version
so,
unfortunately,
for
people
who
already
run
so
specific
routing
a
flight
base
needed,
but
that
was
going
to
be
the
case
anyway
and,
as
you
can
see,
it's
so
specific
routing
in
itself
is
pretty
easy
to
implement
in
the
core
protocol.
K
It's
less
than
200
lines
of
code,
I'm
cheating
a
little
bit
here,
because
of
course
that
requires
the
kernel
to
know
so
specific
routing
to
know
what
to
do
with
them-
and
this
is
does
not
count
the
bird
core
changes
to
soar
to
support
so
specific
routing
either,
which
is
another
200
lines
of
code
or
so
so
all
in
all.
It's
not
that
much
and
it's
pretty
useful
to
have
so
specific
running.
So
that's
nice,
then
there's
a
few
additional
unreleased
changes
which
have
not
been
accepted
upstream.
K
K
Obviously,
I've
plans
to
experiment
some
more
with
the
unique
are
stuff.
We
also
have
some
plans
to
do
the
security
depending
on
the
next
talk
and
what
we
end
up
deciding
there
tentatively
there's
H
Mac
support
already
in
Burt,
so
I
was
probably
going
to
start
with
that,
but
we'll
see
where
we
end
up
in
the
discussion
and
then
there's
also
the
whole
Wi-Fi
issue
with.
It
would
be
really
neat
to
be
able
to
get
some
parameters
out
of
the
kernel
and
do
something
useful
with
that.
K
Instead
of
just
doing
the
multicast
hack,
where
we
look
for
drop
packets
and,
of
course,
scaling
packet
transmissions,
I
think
it
would
be
really
fun
to
try
to
dump
a
full
BGP
routing
table
into
Babel
and
see
what
happens
and,
of
course,
this
is
not
a
promise
to
implement
features
to
do
any
work
or
anything
whatsoever.
This
is
just
ideas
at
this
point
and
if
anyone
else
wants
to
implement
some
ibid,
please
do.
K
So
just
to
sum
up,
we
have
very
full
LC
6126
Biss
implementation
in
burt
2.0,
it's
interoperable
with
the
deployed
babel
d,
except
for
the
saw
specific,
oh
bugger
I
forgot
to
update
this.
This
should
say
two
point,
zero
point
two
and
not
yet
sorry
about
that
which
does
not
enter
operate
with
Babel
D,
but
it
does
interoperate
with
the
upcoming
battle
D,
which
Julius
will
release
any
time
now,
and
security
and
unicast
work
is
pending.
A
A
K
L
K
L
Okay,
so
I
go
look
at
it
and
then,
obviously,
since
you
ran
out
of
ideas
for
200
lines
patches,
you
shall
implement
beer
right
and
we
actually-
and
we
actually
have
there-
no
completely
native
v6
encoding
on
the
plate.
So
you
can
run
the
whole
beer
in
user
space
without
any
kernel
support
right.
So
it's
like
hope,
hope,
I,
hope,
link
local
to
link
local
and
you
get
the
full
frame
and
you
can
do
whatever
you
want
and
it
was.
K
L
K
L
M
H
That
means
that
you
have,
as
far
as
I
can
tell
you're
fully
compliant
with
six
one
two
six
bits
as
it
currently
stands
and
you
can
implement
the
Babel
profile
for
homeless,
probably
as,
except
perhaps
for
land
quality
estimation.
Do
you
do
it?
Yes,
you
do
on
Wi-Fi
what
I
mean
like
you
do,
etx?
Yes,
okay,.
K
N
N
Okay,
so
good
things
we
have
a
working
implementation.
We
use
the
embed
chalice
for
our
today's
implementations.
So
here
you
can
see
a
screen
capture
a
packet
capture,
I
mean
we
have
neighbor
discovery,
packets,
blue,
then
a
DTLS
handshake,
starting
and
after
the
completion
of
the
handshake,
the
two
that
appears
exchanged
double
protective
data
in
green.
N
This
is
a
further
moment,
the
user
interface.
So
you
have
to
say
that
you
want
to
use
unicast
on
the
interface.
Then
you
want
to
enable
DTLS
on
the
interface
and
you
just
give
to
Bible
and
link
to
your
certificate.
The
private
key
and
I
can
show
you
the
actually
the
the
CA
certificates
and
the
key
the
password
to
the
private
key
okay.
So
the
mole
is
based
on
UDP.
You
can
use
beta
over
unicast
and
multicast
and
Bible
is
a
pure,
pure
pure
chapel
protocol,
which
means
whoops
whoops.
N
It
means
that
the
same
part
is
good
for
sirs
and
for
this
nation
and
by
Dodie,
the
implementation
of
a
reference.
Implementation
of
Babel
uses
a
lot
of
multicast,
but
the
trellis
can
only
protect
unicast,
so
Julius
had
to
rewrite
the
buffering
mechanism
in
Babel
D
from
a
lot
of
multicast
to
unicast.
N
N
Okay,
now
I'm
going
to
talk
about
our
actual
prototype,
so
in
detail.
Let
the
handshake
is
a
symmetric,
but
Babel
is
purely
symmetric
and
we
have
to
break
that
symmetry.
So
we
use
the
classic
technique
of
selecting
the
lowest
link
layer
address
the
peer
with
the
lower
address
and
it
becomes
DD
TLS
handshake
server.
N
Now
when
we
receive
packets,
so
the
bubble
structure
is
pure
appear
to
be
a.
We
don't
like
to
provide
this
with
details,
so
we
choose
to
receive
all
traffic
from
bubble
and
from
the
TLS
on
the
same
circuits,
but
we
have
now
two
different
shades
packets
coming
from
me,
TLS
and
coming
from
data,
and
it
turns
out
that
the
details
library
can
do
that
for
us
most
of
the
time.
So
we
have
to
so.
We
receive
the
packets
from
on
the
same
circuit
and
we
try
to
decrypt
the
packets.
N
So
we
give
the
packet
to
the
to
the
chalice
library
and
if
we
succeed
to
decorate
the
packet
we
target
the
we
take
the
packet
as
secure
and
if
we
fail,
we
tagged
the
packet
as
insecure.
If
the
packet
is
insecure,
we
will
ignore
all
theories
except
hellos
in
IH.
U
so
we
either
other
way
we
bounce
the
packets
as
an
optimization
multicast
is
insecure
by
default,
because
details
cannot
protect
multicast,
and
this
behavior
is
interleaved
with
the
DTLS
handshake,
meaning
that
while
we
are
processing
ad
TLS
handshake,
we
can
still
receive
roll
double
packets.
N
Okay,
but
we
have
to
be
some
disagreement
to
shoot
the
server
part
be
the
same.
A
debugger
part.
Should
the
client
be
the
same
as
a
server
part.
We
need
to
discuss
that
and
we
still
have
some
open
questions
that
so
is
passing
insecure
packets,
winning
a
good
idea,
and
another
question
was
raised
on
the
list:
what,
if
appear,
wibbels
after
successfully
TLS
handshake,
so
it
turns
out
that
the
array,
the
section
in
the
details
about
see,
are
telling
us
what
we
should
do,
but
most
implementations
don't
do
this.
We
could
use
different
parts.
N
We
could
do
a
bit
of
hacking
in
the
client
details,
library.
There
is
room
for
other
internships,
also
on
the
usability
of
by
Dodie.
How
should
we
deploy
keys
and
certificates
and
well
the
invalidate
keys
or
whatever
and
another
question
we
need
the
details
of
ahead
cost
presentation,
especially
when
exchanging
certificates,
so
good
news
bubble
can
be
protected
by
DT
Alistair.
We
have
the
running
implementations
that
protects
data
but
nuts
discovery
and
hopefully
for
be
available
soon.
L
L
Because
DTLS
doesn't
give
you
any
non
C's
or
anything
like
that,
I
assume
right,
so
it
does
so
DTLS
does
already
the
reply
protection.
So
what's
the
reason
about
is
adjacency
formation,
it's
just
because
multicast
and
that
you
don't
know
how
to
encrypt
multicast
I
mean
you
can
put
something
and
encrypt
that
stuff,
even
a
small
piece
of
information
on
this
key,
and
it
will
give
you
you
know.
L
At
least
you
know
that
it's
the
right
guy
sending
because
the
most
common
attack
was
really
like
reply
protection,
especially
on
the
adjacent
sister,
which
most
often
ended
up
just
being
a
denial
of
service
right
because
they
weren't
able
to
like
get
adjacency
fully
up.
But
you
can
actually
muck
things
up
pretty
badly,
simply
reply
attacks,
so
just
practical
experience.
M
David
skin
Ozzie
Apple
to
answer
to
Tony
the
yeah,
so
DTLS
gives
us
replay
protections
amongst
a
bunch
of
other
properties.
But
indeed,
if
we
don't
do
anything
to
protect
the
hellos,
the
attack
on
Babel
is
well,
so
you
can
send
evil
hellos
and
mess
up.
The
sequence
number
counts,
which
will
completely
mess
up
your
like
estimation,
and
you
could
also
replay
them,
which
would
probably
have
the
same
effect
actually,
but
that's
yeah,
that's
it
but
the
chart
so.
O
My
name
is
Dennis
and
I've
been
waiting
for
this
for
about
two
years.
The
DTS
mechanism,
because
Irish
had
adverted
lead
since
2016
and
I've
been
asking
the
same
question:
is
it
possible
to
see
a
document
that
explains
of
things
they
expected
to
work,
for
instance,
like
security
considerations,
the
things
the
bad
things
that
you
see
might
be
happening
and
how
you
see
the
mechanism
is
protection,
they're,
minuses
of
the
routing
protocol
from
those
bad
things
you
say
and
I
didn't
have
the
opportunity
to
see
a
document
that
would
explain
it.
O
It's
nice
work
work
in
progress,
okay,
I'm,
not
saying
they're
doing
a
bad
thing
or
but
what
I'm
saying
there
should
be
a
document
that
explains
what
you
meant
to
achieve,
such
that.
If
what
you're
doing
is
not
what
you
want
it
to
do,
other
people
can
see
it
and
say
that's
what
you're
going
to
do?
That's
what
you
have
actually
done.
So
if
this
can
be
fixed,
then
we
need
to
fix
it.
Otherwise,
we
should
review
the
assessment
of
the
security
threat
and
say
that
no
that's
not
the
model
that
should
be
different.
E
O
L
O
Say
that
this
is
what
I
have
missed.
This
is
what's
done
right
and
in
that
document
it
will
be
nice
to
have
a
section
that
spells
exactly
how
many
bytes
do
you
introduce
as
an
overhead
protocol,
because
there
should
be
some
power
head.
It
would
be
nice
to
know
how
much
it
is
like
5%
50%
of
the
normal
traffic
I
think.
O
G
So
I
always
want
this
is
not
least
like
with
whoa
I
just
wanted
to
say.
That
document
seems
like
a
great
thing
to
have,
and
it
just
mentioning
on
on
unicast
and
multicast
I
mean
there's
a
DTLS
as
I
think.
Where
does
this
handshake
to
generate
the
keys,
so
it
sort
of
inherently
a
peer-to-peer
kind
of
thing.
You
know
the
point
quite
the
point
and
the
you
know
some
of
the
Nash.
You
could
easily
build
something
which
is
multicast
but
has
some
kind
of
group
key
okay,
but
but
it's
easier
and
to
do
that
securely.
G
If
you
want
to
have
a
group
key
of
something
like
that,
if
you
have
some
way
to
distribute
that
key
to
the
group
members,
you
know
it.
So
you
kind
of
want
to
have
a
point-to-point
security
already
set
up,
but
they're
anyway,
where
you
most
need.
The
multicast
is
where
your
first
discovering
people
or
something
like
that.
So
it's
a
little
bit
of
a
chicken
and
egg
kind
of
problem.
H
H
H
H
Finish
I
believe
so
I
will
just
so.
First
I
would
like
to
point
out
that
you
know
there
is
on
one
side
Donna
and
on
the
other
side,
a
multi
bill,
reincorporation
Antonov
finished
first,
and
the
other
point
is
that
we,
it
is
really
very,
very
recent
stuff
and
we
simply
haven't
written
anything
down.
Yet.
Okay,.
H
H
Babel
implementation,
you're
still
doing
Babel,
/,
multicast,
Babel,
/
DTLS
is
this
work,
and
this
thing
makes
you
depend
on
the
complex
library
that
you
don't
understand
because
nobody
understands
DTLS
and
but
on
the
other
hand,
it
means
that
crypto
is
somebody
else's
problem.
So
at
some
point
we're
going
to
have
to
decide
which
we
want
to
have
it
strongly
recommended
in
the
draft
and
I
would
be
in
favor
of
pushing
Babel
H
Mac,
with
their
Babel
/
DTLS
being
the
optional
algorithm.
G
You're
saying
that
it
be
TLS
moves
all
the
security
of
somebody
else,
but
it's
not
clear
to
me
that
it
seems
need
need
need
to
protect
to
provide
some
protection
against
people
screwing
with
hellos
and
I
heard
users
and
stuff
like
that,
and
if
de
las
doesn't
do
that,
then
it's
even
though
it
may
push
the
crypto
off
to
somebody
else.
It
may
not.
The
crypto
provided
by
this
other
party
may
not
be
what
you
need
so
right.
H
So
there
was
one
proposal
for
that,
so
my
impression
was
that
were
not
protecting
against
the
OS
yeah.
Okay,
it
looks
like
was
wrong.
If
we
want
to
be
protecting
against
the
US,
then
DTLS
can
work.
I
believe
thanks
to
the
unicast,
hello
Akash,
and
what
had
recently
done,
but
I
think
David
has
clear
ideas
and
I
do
know.
That
subject
is
that.
L
Tony
Fijian,
so
I
would,
from
practical
standpoint,
I
think
played
with
the
stuff
of
twenty
years
right.
I
would.
Second,
what
you
do
says:
replay
protection,
plus
something
like
shell
on
for
integrity
is
mostly
as
far
as
people
go,
and
if
you
have
something
which
is
simple,
doesn't
precondition
library,
lots
of
overhead.
You
know
computational
overhead.
This
goes
a
long
way
where
the
world
is
going.
L
The
DTLS
will
give
you
the
leg
up
right
I
mean
the
security
guys
are
coming
down
heavy
they're
coming
down
heavy
for
a
good
reason
right,
so
I
think
you'll
end
up
there
anyway,
but
having
DTLS.
That's
the
only
option.
That's
a
fairly
fat
pig
yeah.
You
know
if
you
won't
like
practically
deploy
the
protocol
and
be
successful
with
it.
M
One
thing
I
like
to
have
David's
Ganassi,
Apple
DTRS,
doesn't
just
give
you
encryption
on
top
of
this.
It
does
a
new
key
exchange.
Every
time
you
set
up
a
new
Association,
and
so
that
means
that
you
will
never
have
replay
attacks
messages
that
could
come
on
a
later
date
or
people
sending
traffic
that
we
modified.
It
has
a
much
cleaner
security
boundary
and
if
you
say
that
everything
like
hellos
are
outside
or
hellos
are
and
I
heard,
you're
outside
and
everything
else
is
inside,
you
know
that
everything
else
is
completely
immune
from.
M
Replay
attacks,
whereas
with
the
HVAC
work
dennis
found
a
very
clever
attack
on
it,
which,
because
of
the
way,
it
is
it's
kind
of
harder
to
reason
about
it,
harder
to
make
a
security.
We
might
have
other
attacks,
I'm,
not
a
security
expert,
but
it
might
have
other
problems
as
well.
We
could
also
another
option
is
to
use
a
combination
of
both
where
you
could
establish
DTLS,
use
a
key
exporter
and
use
that
to
H
Mac
the
hellos,
and
that
gives
you
a
very
secure
model
that
that
is
also
immune
from
das
attacks.
K
K
There's
no
threat
model,
thus
I
think
it's
sort
of
a
a
difficult
discussion,
but
to
me
at
least
having
the
option
of
doing
the
simple
thing
would
be
important
and
also
from
an
implementation
point
of
view.
I
would
also
like
to
have
security
available
in
environments
where
I
can't
have
a
details.
Library,
first,
such
as
on
a
tiny
unity.
Linux
router
with
two
megabytes
of
Flash.
L
So
a
more
input
on
that.
So
there
is
really
this
layering
of
you
know
what
security
it
is
comprised
of
right,
so
there
shiz
like
the
simple
integrity.
If
you
want,
then
you
have
to
replay
thing
and
then
you
have
really
the
what
you
call
it,
but
you
can
see
what's
inside.
L
L
Okay,
okay,
literally
so
the
keys
are
hanging
there
for
20
years
and
the
only
reason
is
like
you
know:
you
can't
just
randomly
bring
it
up
adjacencies
and
then
you
know
the
read,
because
it's
a
really
good
error
correction,
it's
error,
correction
and
harder
to
come
to
miss,
configure
and
then
the
replay
attacks
where
they're
getting
more
common
and
the
confusion.
The
confidentiality
is
something
that
has
always
over
had
in
the
price,
your
funky
libraries.
L
You
know
funky
version
of
the
libraries
you
have
to
run
funky
tunnels,
you
need,
if
you
bring
up
IPSec
tunnel
before
you
get,
is
now
the
the
security
Association
it
takes
forever
and
then
Psalms
and
convergence
slows
down
and
practically
speaking,
people
don't
do
that
right
and
then
you
think,
like
oh
yeah,
but
anyway
they
really
have
a
key
infrastructure.
No
one
ever
deployed
dynamic,
key
infrastructure
on
the
routing
protocol
and
I
built
someone
having
paid
for
it,
but
then
once
people
understood
what
is
the
implication
that
you
literally
break
you
network
right?
L
A
A
Is
that
is
that
that's
your
job
is
that
when
I
was
at
Cisco
and
we
were
testing
H
Mac
in
d5
and
we
decided
to
test
performance,
we
did
we
determined
that
turning
on
encryption
on
routing
protocols
is
actually
an
awesome
way
to
open
up
a
new
secure
in
your
network
because
most
modern
processors,
even
if
you
throw
enough
miss
sine
to
garbage
at
them,
it
will
take
down
the
processor
on
the
router.
So
you've
opened
yourself
to
a
denial
of
service
attack.
It
very
low
packet
rates,
much
lower
than
you
might
expect.
I
think.
M
G
M
M
G
Ports,
okay,
it
in
general.
It
is
possible
to
get
two
port
assignments
for
a
protocol,
one
for
insecure
one
for
secure.
That's
one
thing
that
the
port,
I
guess
it's.
The
pool
of
experts
that
are
for
port
assignments
will
will
allow
to
in
that
case,
so
it
should.
If
we
want
to
do
that,
we
should
be
able
to
do
it.
So
yeah
I
needs
more
discussion
on
the
list,
perhaps
but
ya.
M
G
D
G
O
Hello,
I'm,
Dennis
and
I'm
here
mostly
to
remind
about
my
message
in
the
working
group
mailing
list.
I
have
reported
an
individual
internet
draft
that
I
believe
addresses
the
problem
that
I
had
described
a
few
times
of
the
mailing
list
and
on
HF
98
I,
think
session
I
heard
slides
that
explain
the
in
as
much
detail
as
possible
how
the
attack
works,
and
we
had
a
few
threads
now
I
have
abated
there
7298.
O
We
solution
that
I
believe
solves
the
problem
and
because
it's
still
an
individual
idea,
I
would
like
to
propose
it
the
working
group
document
because
as
an
individual
idea,
its
users
and
it
doesn't
serve
the
purpose.
If
the
working
group
is
interested
to
pick
it
up,
I
can
finish
the
document
at
the
moment
in.
Could
it
contains
the
central
parts
of
the
technical
description?
Then
it
needs
some
generic
changes.
I
can
do
them
if
it
becomes
a
document
if
it
doesn't
become
them
well.
O
G
O
Explained
the
attack
in
detail
before
and
if
anybody
wants
to
discuss
I
can
discuss.
I
can
explain
how
the
solution
works,
but
if
you
want
to
talk
about
I
would
expect
people
I
would
reasonably
expect
people
to
read
what
I
have
written,
maybe
together
with
me,
we
can
run
through
the
document
and
then
you
can
have
your
opinion
if
it
actually
solves
the
problem
or
if
it
doesn't,
but
I
think
it
does.
O
Regarding
the
point
that
we
discussed
five
minutes
ago
about
control
and
protection
with
computing
compute,
a
computational
intensive
operations
teaching
the
central
processor
of
the
device
right
in
7298
original.
There
are
provisions
that
address
that
specific
problem.
They
try
to
keep
CPU
load
as
well
as
possible
when
the
attacker
just
feeds
packets
that
pretend
to
they
pretend
to
be
integrity
protected.
That's
it
so
that
there
is
a
mitigation
origin
in
that
document.
For
that
that
problem,
that's.
G
E
Alrighty,
so
it's
been
a
while,
since
we
actually
discussed
this
and
I
know,
y'all
are
really
excited
about
it,
but
anyway,
this
is
just
a
brief
structural
overview
of
what's
in
the
current
draft,
but
Julius
and
I
met
on
Monday
and
then
I
internalized
our
meeting
on
Tuesday,
and
then
we
talked
again
on
Tuesday
and
so
there's
a
lot.
That's
going
to
be
changing,
but
it's
still
mostly
this.
It's
just
not
quite,
but
anyway
that's
what
it
was
now.
E
There
are
changes
coming
in
the
o2
version,
yeah,
there's
a
lot
of
myths
that
are
fixing
I'm,
adding
an
appendix
that's
going
to
have
the
change
lock.
So
you
can
see
what
all
the
changes
are,
but
just
some
kind
of
big
things:
yeah,
that's
not
really
big
yeah.
We
are
a
babble
link,
type
taking
away
or
this
lossy
link
and
so
we'll
be
able
to
expand
the
as
it
as
an
enumeration
as
other
link
types
become
supported
in
implementations,
for
example,
power
line.
Coax.
E
We
still
need
to
work
some
on
the
Babel
security
object
but
in
any
case
I'm
allowing
for
credentials
multiple
credentials
of
one's
own,
in
addition
to
multiple
credentials
of
the
nca
credentials,
and
things
like
that
just
in
the
description.
But
you
know
how
a
how
a
security
mechanism
makes
use
of
these
credential
lists
is
up
to
that
security
technology.
E
Log
just
to
record
any
time
when
you
actually
examine
credentials
and
yeah
there's
some
other
things
we're
going
to
get
rid
of
the
source
table
anyway.
It's
just
a
summary.
I
hope
this
is
readable
and
I
didn't
make
it
too
small.
I'm,
really
sorry,
but
there's
some
open
issues,
I'm
not
going
to
step
through
them.
All
y'all
can
read
through
them
and
tell
me
if
there's
any
that
stand
out
at
you,
but
I'd
be
curious,
I
think
one
of
the
let's
see
at
the
end.
Oh
yeah,
this
was
number
eight.
E
J
E
And-
and
just
so
you
understand,
it
is
structured
that
a
lot
of
the
data
model
parameters
are
listed
as
optional,
and
that
is
because,
if
an
implementation
does
not
support
these,
if
it's
not
something
that
in
how
that
implementation
is
designed,
that's
perfectly
okay.
You
don't
have
to
support
or
implement
the
parameters
either.
Even
if
you
choose
to
implement
the
information
model
via
is
some
data
model,
so
that's
kind
of
what
optional
means.
It
means
well
optional,
I.
E
C
H
The
north
is
chroma-trak,
so
one
thing
that
users
do
want
to
configure
is
filtering
rules
and
the
three
implementation
of
the
three
main
implementations,
the
three
sorry
open-source
implementations
of
babel,
have
very
different
configuration
languages
for
filtering
and
I.
Don't
think
it
is
our
job
here
to
extract
the
common
filtering
language
from
free
range,
routing,
bird
and
my
homebrew
implementation,
okay
and
I.
Don't
know
what
to
do
about
that
and
I
would
say
to
leave
the
filtering
rules
as
an
aback
object.
A
So
I'll
say:
I'm
Russ,
Lincoln,
chair
hat
off
that
it
is
not
your
job
to
bother
with
trying
to
mess
with
the
filtering
rules.
It's
whatever
is
in
the
implementation
that
you're
using
bird
through
and
routing
whatever,
because
the
users
of
those
implementations
are
going
to
expect
them
to
be.
The
way
they
are
for
bgp
OSPF
is,
is
whatever.
E
So
we
had
discussed
that
I
would
just
put
a
proposal
in
and
see
you
know.
If
people
like
it,
we
can
have
it
as
to
how
to
model
really
basic
filtering
and
if
something
does
more
advanced
filtering,
then
really
really
basic
stuff.
Then
it's
just
not
in
the
model
and
it's
not
configurable
via
that
model
and
they
would
have
to
do
custom
model
elements,
but.
E
G
I
guess
I
have
a
question:
would
it
make
any
sense
to
have
sort
of
a
big
block
of
stuff
which
only
something
that
understood
that
implementation
could
parse
but
could
be
obtainable
through
the
whatever
that
you
had
of
reading
out
configuration?
You
know
with
your
management
protocol,
see
that
again
just
have
an
opaque
globo's
filtering
rules,
stuff
that
you
know
you
could
obtain
through
your
whatever
I'm
adding
protocol.
You
were
using
whether
you'd
only
be
able
to
understand
if
you
understood
that
the
implantation
honestly.
G
G
Q
In
filthy,
no
not
to
throw
a
spare
in
the
works,
but
it's
I
read
the
source
specific
extension
a
while
back
and
it's
a
very
short
document,
especially
if
you
leave
of
all
the
boilerplate
and
on
each
page
of
the
remaining
document
were
about
three
or
four
references
to
D.
6126
document
I
was
wondering:
would
it
be
simpler
to
just
merge
the
two
things.
G
M
David
skin
Ozzie,
Apple
I
would
prefer
them
to
stay
separate.
Precisely
because
it's
an
optional
feature-
and
in
that
case,
I
would
kind
of
say
you
implement.
One
RFC
gives
you
the
man
in
Babel
and
then
every
extension
to
Babel
is
its
own
RFC.
That
seems
natural
to
me
and
also
the
timelines
might
not
act
like
exactly
in
terms
of
one.
We
want
to
publish
both
documents.
K
You
don't
always
have
a
forwarding
plane
that
can
handle
so
specific
writing.
So
if
we
added
it
to
the
main
document,
we
would
have
to
make
it
optional
and
I
think
that
could
add
as
much
text
now
than
these
back
references
from
the
extension
does
and
I
think
that
having
duck
the
documents
be
really
short,
is
a
feature.
It's.