►
From YouTube: IETF103-GROW-20181105-1120
Description
GROW meeting session at IETF103
2018/11/05 1120
https://datatracker.ietf.org/meeting/103/proceedings/
B
B
B
B
B
All
the
rest
of
that
you
be
down
on
the
slides
and
read
this
on
your
own
at
your
own
leisure.
There
blue
sheets,
going
around
please
be
sure
to
sign
the
blue
sheet
and
pass
it
at
the
person
to
your
left
or
right
where
it
didn't
come
from.
We
have
a
minute
a
cur,
a
jabber
scribe.
We
have
an
agenda.
It
looks
like
this.
B
Oh,
it's
not
quite
all
BMP
this
time,
there's
some
BGP,
but
no
DNS.
So
it's
like
my
other
meeting.
Okay,
so
is
Shriram
around
oh
wait.
We
should
sorry.
Actually
all
of
these
are
going
to
be
talked
about,
except
for
wkc,
behavior
and
a.s
cones
joke.
Do
you
want
to
say
something
about
your
heya
scones.
B
C
Down
a
as
clones
is
Randy
Bush,
IJ
darkus.
Would
anybody
interested
in
actually
trying
to
make
that
into
something
useful
and
sensible
talk
to
some
people
who
know
something
about
security,
sure.
B
Sorry,
the
one
piece
of
sort
of
working
group
business
to
actually
talk
about
today
is
this
grow
registries.
People
should
read
this
and
comment
it
and
we
can
push
it
forward
to
work.
Your
blessed
call
pretty
quickly.
It's
changing
a
bunch
of
the
the
registries
for
BMP
to
be
expert
required
to
kind
of
first-come,
first-serve,
which
I
think
there's
no
reason
not
to
date.
Change
them
to
the
first
come
first
serve
so
at
least
in
my
opinion,
but
I'm
just
one
person.
Please
have
a
read
into
some
comments
on
the
list.
B
D
Considering
that
vendor
implementation
changes
would
not
be
required,
so
we
basically
have
two
parameters
that
are
part
of
the
route
leak,
protection
or
the
RL
p
f--
information.
Those
are
the
down
only
and
the
leak
detected
so
download
lis.
Basically,
the
semantics
is
that
s
is
telling
the
subsequent
a
SS
that
I
am
sending
it
to
a
customer
or
a
lateral
peer,
and
subsequently
the
update
should
not
go
to
a
lateral
peer
or
a
transit
provider.
D
The
L
leak
indication
is
that
it,
the
semantics,
is
that
the
s
and
detected
a
leak,
the
update
came
from
a
customer.
The
the
ISP
doesn't
have
an
alternate
route,
so
it
accepted
that
route
and
propagating
it.
But
it
is
warning
the
subsequent
a
SS
that
I
detected
a
leak
but
I
had
to
propagate
it
because
of
I
would
have
unreachable,
ax,
T,
otherwise,.
D
So
I
will
not
go
into
describing
the
semantics
any
further
than
that.
There
are
a
bunch
of
slides
with
the
scenarios.
Please
feel
free
to
walk
through
them.
We
we
did
present
it
in
the
IDR
interim
meeting
last
week,
so
I'll
skip
through
the
simple
detailed
explanations
and
the
scenarios
of
the
our
LP,
semantics
and
I
would
like
to
jump
because
we
have
elected.
We
would
like
to
allow
more
time
for
the
discussion
and
feedback
on
the
community
choice,
our
type
of
community
etcetera.
So
let
me
just
skip
the
various
things.
D
Detection
rules,
policy
recommendation:
these
are
all
there
in
detail
in
the
draft
as
well
as
in
this
slides,
as
well
as
some
more
slides
at
the
back.
Please
grab
us
in
the
hallway
or
send
us
questions
on
the
list,
we'll
be
happy
to
discuss
the
semantics
with
you.
If
you
have
any
questions
or
suggestions,
but
so
we
are
jumping
right
ahead
to
the
community
use
of
community.
So
here
we
have
three
choices:
regular
community,
large
community
and
extended
community
with
the
regular
community.
D
D
If
you
use
regular
community,
we
have
only
16-bit
payload
limitation,
we'll
have
to
perform
some
tricks,
and
that
can
be
done
and
it
can
be
shown
that,
with
using
three
regular
communities,
we
can
accommodate
the
do
and
the
L
the
2's
and
values.
On
the
other
hand,
if
we
use
a
large
community,
then
we
have
96
bits
readily
available,
of
which
the
first
32
bits
are
global
administrator,
and
then
we
can
put
the
do
and
the
L
as
the
subsequent
three
or
four
Rockets
and
another
four
Rockets.
D
So
all
of
that
is
accommodated
in
one
large
community
next
slide
the
extended
community.
Here
we
have,
we
will
require
two
community
attributes
to
accommodate
the
do
and
the
LA
SN
values
we
can
come.
We
can
accommodate
the
s
and
values
as
they
are
without
any
further
compression
or
encoding.
So
two
community
attributes
that
does
it
next.
This
is
the
slide
where
we
want
to
spend
rest
of
the
time.
Also
so
for
the
rest
of
the
my
remaining
time.
Please
focus
on
these
questions.
D
We
would
love
to
have
you
have
a
discussion
around
these
questions
here.
So
basically
the
questions
are
we.
We
are
making
this
considering
missing,
making
this
transition
from
attribute
to
community
if
you
advised
otherwise,
please.
Let
us
know
your
thoughts
about
that,
and
if
the
community
is
good
to
go
with,
then
the
choice
between
regular
community
versus
large.
What's
this
extended,
we
would
like
to
also
request
your
feedback
on
which
of
these
would
work
best
in
terms
of
the
chart
in
terms
of
a
chance
to
propagate
the
farthest
and
the
next
table.
E
The
large
communities
can
do
it
the
other
way,
the
other
things
are
somewhat
complicated
and
we
don't
like
complicated
and
yes
for
the
large
communities
to
make
sure
that
the
propagation
works
the
right
way.
We
quite
certainly
will
need
a
little
bit
of
documentation,
a
giving
advice
on
how
to
handle
this
in
the
local
come
in
the
local
policy
configurations.
E
D
E
D
G
Okay,
Thank
You
Jacob
Heights
at
Cisco,
I
work
on
XR
io
a
six
hour
and
by
default
does
not
pass
communities.
Is
someone
has
to
configure
to
have
the
communities,
all
arts,
communities
or
extended
communities
to
be
passed?
If
you
know,
if
you're
relying
on
the
leaking
as2
dutifully
pass
along
any
communities
or
attributes,
then
your
relying
on
them.
G
D
So
yeah,
so
we
just
respond
say
seconds,
so
the
leaking
is,
if
it's
not
doing
the
RLP,
hopefully,
hopefully
it's
not
not
yet
RLP,
adapted
or
or
LP.
But,
however,
we
are
hoping
that,
even
though
it's
not
doing
our
LP,
it's
doing
other
things
at
least
right
in
terms
of
passing
a
community
when
it
needs
to
be
passed
through
like
a
transitive
community.
Okay,
thank
you.
A
E
D
H
C
Behind
a
bush,
I
J
darkest
how
many
people
were
at
ie,
PG
and
I.
Probably
I
still
have
to
give
this
anyway.
Sorry,
we
could
have
escaped
okay.
This
is
mainly
I'll.
Try
to
be
quick
community
is
has
been
growing
that
graphs
up
to
the
right.
All
graphs
go
up
to
the
right,
don't
they?
The
communities
are
ill-defined,
it's
not
just
that
large
ones.
There's
no
registry,
the
small
ones.
We
really.
You
know
it's
like
putting
semantics
and
comments
statements.
We
really
don't
know
what
they
mean.
C
We
really
have
no
rules
for
them,
etc.
The
place
we
have
rules
is
BGP
attributes,
not
communities,
okay,
so
the
flavors
we
have
of
communities
are
these
that
the
major
taxa
are
active
and
passive
ones,
but
we
really
don't
know
what
any
of
it
means.
That's
just
the
Wild
West
out
there,
the
propagations
a
problem,
the
it
said
that
you
should
filter
dr.
da
da
people.
Don't
expect
them
to
propagate
very
wildly
I,
for
one
did
not
expect
them
to
propagate
wildly.
I
was
surprised.
C
C
14
percent
seem
small,
but
more
than
50
percent
of
communities
travel
more
than
4
a
SS
10%
travel
6
right.
The
longest
path
we
saw
was
11.
This
is
kind
of
e
CDF,
of
it
you'll
notice,
for
instance,
that
about
half
of
the
communities
travel
for
a
SS,
which
is
the
diameter
of
most
the
mean
diameter
of
the
internet
path
length.
C
C
It
wasn't
destined
here,
but
it
went
here
anyway
to
probably
should
have
filtered
okay,
here's
what
we
see
in
the
distribution
of
measured
communities-
and
this
is
measuring
through
the
usual
broken
glasses
of
Route
views
and
risks,
etc,
whether
as
we
see
these
communities
off
paths-
in
other
words,
this
was
not
debt
marked
as
destined
for
the
AAS
it
was
seen.
This
is
the
most
interesting
that
is
not
$9.99.
For
those
of
you
who
know.
That's
supposed
to
be,
or
by
convention,
that's
the
black
hole
right.
C
C
So
we
decided
to
break
things.
We
method,
we
said
all
experiments
we
first
tested
in
lab.
Then
we
estimated
what
the
impact
would
be,
so
we
could
make
sure
we
weren't
gonna,
break
the
global
Internet
and
then,
with
the
operator,
some
operators
consent.
We
did
some
fun
things
out
there
and
by
the
operators.
Consent
I
mean,
for
instance,
fastly
gave
us
a
prefix
that
we
could
hijack
because
they
weren't
using
at
the
moment,
etc.
They
were
announcing
it,
but
not
using
it.
So
clay
these
are
slow
is
what
it
is.
C
So
what's
a
remote
triggered
black
holes
supposed
to
do
a
s1
is
supposed
to
say
it's
supposed
to
say:
hey
a
s2,
please
traffic,
sync,
this
prefix
and
it's
usually
you
send
it
long
prefix
like
a
32,
so
that
you're
upstream
provider
sinks,
something
that's
being
das,
attacked,
okay
and
there's
all
sorts
of
rules
about
it.
In
fact,
an
attack
e
can
hijack
the
prefix
okay,
here's
an
attacker
hijacks,
the
prefix
announces
it
and
a
s3
syncs
traffic
that
a
s1
really
wanted.
C
No
is
like
this
any
better,
so
this
works
well
multi-hop,
in
other
words,
from
far
away
triggering
it's
possible
for
attributes,
because
the
black
hole
prefix
is
more
specific.
You
usually
say
black
hole
is
32
out
of
my
24,
and
there
was
the
the
first
presentation
at
Nanog
had
a
recipe
for
doing
this
that
had
a
bug
in
it
and,
of
course,
that
bug
propagated
in
documentation,
etc.
They
checked
the
black
hole
community
and
implemented
it
before
checking
whether
the
prefix
was
should
have
been
announced
by
the
person
from
whom
they've
received
it.
C
C
This
one
announces
p1
das
path
grows
the
a
s
path
grows
here.
We've
got
an
ass
path,
went
to
four
here:
we've
got
nay
s
path.
Length
of
five
traffic
goes
as
we
expected:
as2
colludes,
with
a
S
5
and
s
2,
says:
hey
a
s
6,
please
prepend,
and
so
what
happens
is
this
is
now
longer
path?
I
can
push
the
right
button.
So
traffic
starts
this
way.
It
goes
back
past
evil
and
but
this
AAS
can
intercept
the
traffic,
get
the
data
from
it,
etc,
etc.
Spyware.
C
What
does
this
actually
happen?
On
the
Internet,
of
course,
not
here's
where
it
happens:
here's
a
dying
report,
etc.
It's
actually
in
used
attacking
financial
institutions.
Okay,
so
the
ASN
value
is
totally
ambiguous.
Who's,
the
sender
and
receiver,
even
than
the
ones
that
are
documented,
there's
no
defined
semantics
values
can
be
anything
it's
used
for
both
signaling
and
triggering
actions.
There's
no
cryptographic
protection.
Actually
you
don't
know
who,
on
the
path
inserted
the
community
it's
hard
to
apply
filters
or
understand
what
the
heck
is
going
on.
C
Ok,
I
read
it
on
the
internet,
so
it
has
to
be
good
and
true.
They
can
be
modified
and
removed
by
every
a
s
unless
you
want
to
modify
the
well-known
ones,
in
which
case
some
notable
I'm
prouder
implementers
here,
don't
let
you
do
it
very
easily,
no
attribution
again,
no
cryptographic
protections,
but
we
bet
on
it.
Large
communities
help
a
little
some
ideas
don't
propagate
without
knowing
what
you're
doing
on
the
input
drop.
C
Anything
that
is
not
addressed
to
you
or
that
you
don't
have
an
agreement
to
pass
it
on
to
whom
you're
passing
it
and
only
to
whom
you're
passing
it.
So,
if
Joel
gives
me
something,
that's
destined
to
ridiger
do
I,
have
an
agreement
with
both
Joel
and
rüdiger
to
pass
it
to
Ruettiger,
and
only
do
it
in
that
circumstance.
C
I
B
I
So
I
guess
my
question
is:
should
we
align
the
behavior
of
the
1997
communities
and
the
large
bgp
communities
and
the
extended
communities
behaviors?
Should
we
provide
recommendation
to
the
implementers
about
what
those
behaviors
should
be
around
there,
because
by
default
the
large
bgp
communities,
if
they're
not
understood
by
an
implementation
they
will
be
propagated
because
of
the
transitive
nature
of
them?
So
with
that
transitive
nature,
do
we
want
to
make
recommendations
around
stripping
that
so,
for
example,
juniper
has
configuration
options
that
allow
you
to
say
I'd
like
to
strip
this
unknown
attribute?
I
You
know
or
drop
any
routes
with
this
unknown
attribute
upon
receipt
and
that
allows
you
to
arbitrarily
mash
route
based
on.
You
know
a
value
within
the
TLV,
and
perhaps
we
should
give
guidance
to
vendors
around
what
configuration
capabilities
should
be
there
and
what
should
be
there
by
default,
because
most
of
them
do
not
send
communities
by
default,
but
maybe
they
should,
or
maybe
we
should
align
these
behaviors
one
way
or
the
other
good.
E
Yes,
I
think
I
think
some
documentation
about
good
practice
on
how
the
exchange,
what
bgp
information,
assuming
what
responsibilities
of
parties
is
adequate
and
should
be
done
so
for
Randy's
example
about
transiting
stuff
from
Joelle
to
me.
My
view
would
be
that.
Well,
ok,
there
is
bilateral
agreement
randy
between
you
and
me
about
what
we
are
exchanging
and
that
may
include
that
you
pass
on
something
from
Joelle
but
well,
ok,
it's
your
responsibility
is.
E
F
Hello,
Santa
NTT
communications,
choose
lights
on
this
two
drafts,
BMP
low,
Caribe
and
other
about
just
to
update
you
on
what
is
the
status,
so
the
draft
was
presented
in
Chicago
in
March
2017.
Next
IDF
will
be
a
two
years
mark.
It's
a
key
draft.
That
is,
you
know,
adding
vantage
points
to
the
BMP
protocol.
I
think
it's
really
a
key
draft.
You
know
it's
two
key
drafts
that
we
really
all
of
us
operators.
F
Vendors
want
for
a
number
of
use
cases
that
are
described
in
the
back
half
of
slides,
so
you
can
review
them
because
they
were
already
presented.
There
is
a
plenty
of
interest.
There
was
discussion
on
the
mailing
list
and
things
like
that
that
there
was
feedback.
It
was
processed
and
things
like
that.
The
second
version
of
the
draft
only
included,
you
know
refresh
dates
and
a
third
version
of
the
drafts
is,
you
know
we
are
working
it.
It
was
not
possible
to
complete
it
by.
F
You
know
this
meeting,
but
in
line
with
also
the
previous
version
and
the
previous
times
that
I
presented
you
know
to
the
working
group.
We
have
no
structural
issues
with
the
draft.
Nobody
raised
anything
you
know
structural
with
it,
so
we
had
only
to
make
several
clarifications.
Like
also
on
the
mailing
list.
It
appeared
clear
that
sometimes
we
spoke
very
loosely
about
what
should
be
advertised
and
both
you
know
for
the
other
about
and
the
local
rib.
There
was
some
conversation
and
there
as
being
also
convergence
on
that.
F
So
we
are
working
on
those
clarifications
and
there
was
only
one
thing
in
single
change
minor.
So
there
was
in
the
pur
pur
hither
Heather,
there
was
a
filter
flag
and
we
want
now
to
move
that
as
a
TLV
in
the
pyrrha
message
and
with
that
I'm
pretty
much
finished.
I
just
want
to
say
that
I
really
think
that
these
drafts
are
not
rocket
science.
F
They
are
not
really
trying
to
do
anything
magical
it's
two
years,
almost
that
they
are
on
this
working
group
I
think
we
should
really
try
to
wrap
them
up
soon
and
move
on
to
whatever
else
we
want
to
make.
You
know
around
BMP.
Thank
you
and
I
would
like
to
know
your
feedback
comments.
If
there
is
anything
I.
J
K
L
Hello,
everyone-
this
is
Yunnan,
so
I'm
going
to
use
five
minutes
to
quickly
describe
our
draft
that
proposes
bmp4
BGP
route,
lake
detection
and
I'm
not
going
to
discuss
too
much
details
about
solution,
but
more
focused
on
the
motivation
and
application
scenarios.
So
there
have
been
measures
proposed
to
prevent
or
avoid
relics-
and
these
are
ism
or
measures
are
typically
implemented
through
various
import
and
export
policies
and
yeah.
L
L
Here
are
two
and
then
are
two
based
on
this
route
mark
and
its
relationship
with
s
REO
or
s4,
to
decide
if
this
route
is
allowed
to
be
advertised.
So
this
is
a
prevention
method
and
well
we'd
also
like
to
discuss
this
bgp
open
policy
method
which,
to
my
understanding,
standardized
the
prevention
method.
A
little
bit
many
two
points.
L
First,
the
business
relationships
are
exchanged
through
the
BGP
open
messages
so
that
the
two
asses
understand
what
their
relationships
are
and
then
a
second
based
on
this
exchanged
information,
the
they
wrote
they
wrote
brought
mark,
was
carried
by
a
so
called
IOT
C
attribute
through
the
app
you
clear
out
and
then
also
transfer
to
the
egress
right.
Okay
up
just
just
one.
L
Last
word,
and
there
were
proposing
a
message
to
use
BMP
to
upload,
to
sorry
to
report
the
relationship
within
one
ass
so
that
at
the
control
it
understands
if
the
the
road
to
lake
actually
happens
within
its
own,
but
its
own
ass,
without
depending
on
other
sir
party
information
or
ISP,
and
thank
you
maybe
we
can
continue
discussion
offline.
Thank
you.
I
Jared
montz
from
Akamai
we're
actually
using
a
BMP
as
well
right
now
to
validate
our
policy.
You
know
our
routing
policy
decisions
that
we're
making
and
to
validate
when
we're
actually
leaking
our
route
out
locations
where
it's
not
intended.
So
even
you
know,
while
you're
trying
to
capture
I,
think
some
of
the
stuff
that
the
gentleman
behind
me
from
curator
has
has
suggested.
You
know
for
the
relationship
behaviors
to
identify
this
programmatically.
I
There's
cases
where
we
have
address
space
that
we
may
route
internally,
but
that
by
policy
we
may
not
want
to
advertise
out
specific
links
to
specific
guesses,
so,
like
I,
said
we're
currently
using
BMP
to
actually
validate
our
own
routing
behavior,
and
so
that
you
know
stuff
like
this
is
incredibly
valuable.
So
thank
you
for
this.
Thank
you.
L
M
M
M
You
need
so
you
may
have
with
BP,
for
example,
BP
open.
You
may
have
your
policy
automatically
configured
on
your
routers.
With
this
thing,
you
will
have
to
also
separately
specify
all
your
peering
relationships
in
your
beam.
P
agent
I'm,
not
arguing
it.
It
doesn't
make
sense,
but
just
to
highlight
that
it
does
not
simplify
the
work
of
preventing
root,
leaks
or
detecting
root
leaks.
It's.
L
L
A
A
So
the
same
slowness
applies
to
BCPs
as
well,
and
if
we
look
at
the
problem,
space
of
routing
security
I
feel
that
the
life
cycle
of
information
is
faster
than
12
months.
New
data
sources
come
into
existence
the
nature
of
some
date.
Data
sources
can
change,
new
technologies
are
invented
or
methods
and
be
nice
if
we
can
somehow
keep
track
of
these
developments,
but
also
have
a
document,
a
singular
URL
for
newcomers
to
use.
A
A
So
in
this
context,
the
chairs
and
our
operations
ad
and
ITF
chair
will
have
a
meeting
tomorrow
to
figure
out
if
we
can
formulate
a
strategy
and
have
grow,
perhaps
be
a
working
group
that
works
on
the
living
documents
so
with
depth.
I
have
informed
the
group
of
things
we
are
exploring
and
I
would
like
to
open
up
the
floor
for
feedback
a.
K
Sealing
of
Cisco
Systems
I'm
gonna
come
in
on
the
first
one.
Actually
in
the
route.
This
is
the
the
idea
of
a
security
document
is
an
excellent
idea
and
Jeff
Haas
was
asked
to
look
at
BGP
and
I
was
asked
to
look
at
the
IGP
specific.
You
know,
I
actually,
I
would
probably
I
know
I
assess
ice,
but
I
wouldn't
I
haven't
implemented.
It
myself,
like
I,
have
OSPF
and
we
were
consistent
in
our
progress
we
have
made.
We
are
both
not
done
anything
yet,
but
I
think
I.
I
think
this
is
a
great
idea.
K
I
mean
I.
Think
this
really
needs
to
be
done.
If
and
if
you
could
start
the
ball
rolling
on
the
BGP
security.
One
document
that
brings
together
all
the
pieces
like
a
generic
security
considerations
for
a
BGP
that
would
be
excellent.
It
would
also
help
us
during
the
document
cycle
where,
as
you
know,
we
reference
you
know,
people
bring
up
generic
security
problems
and
will
hold
up
documents
based
on
these
four
specific.
You
know
somebody
who's,
just
you
know
just
like
adding
a
single
community.
Somebody
brings
up.
K
You
know
some
valid
security
concern,
but
it's
not
it's.
It's
not
relevant.
Only
to
this
new
community
anyway,
oh
I'll,
give
others
to
the
floor.
N
Her
a
thottie
I
think
this
is
a
great
theater,
I
loved
it
I
wish
more
people
would
go.
Do
living
documents,
things
that
live
in
a
working
group
that
are
used
for
the
working
group
that
can
be
used
for
reference,
etc.
The
question
I
have
for
you
is:
what
more
than
a
draft
do
you
need?
I
mean
why?
Why
do
we
need
a
process
or
extra
things?
Why
isn't
a
draft
that
lives
in
the
draft
repository
that
it's
reviewed
by
the
working
group?
N
N
What
about
expiration
it
lives
forever?
We
live
forever
in
the
repository
right,
your
version,
so
the
optics
of
a
draft
you
just
updated
every
six
months
or
a
brother
or
whatever,
because
I
mean
that's
part
of
the
thing
right,
because
if
the
technology
changes
and
the
features
of
all
you
would
be
updating
it.
Anyways.
A
If
you
look
at
the
optics
of
a
draft,
they
are
different
than
the
optics
of
an
RC
and
RC
carries
a
certain
image,
specifically
the
ones
that
want
to
standards
track
that
certain
review
steps
have
happens,
that
it's
a
ITF
product
or
perhaps
not
in
the
case
of
informational
or
independent
I,
mean
with
the
draft.
Anybody
can
publish
a
trance
and,
and
the
logistics
of
a
draft
are
different.
P
You
know
two
modules
and
a
lot
of
labs
but
I'm
speaking
as
co-author
of
well
a
formally
worked
for
items
to
see,
and
we
were
work
together
with
Oleg
and
others
on
a
document
that
explain
exactly
how
do
AI
right
hands
to
CR
VI
validated
works.
Now
that
is
going
through
loss
all
at
the
moment,
but
I
think
something
like
that.
This
would
fit
better
there,
because
by
definition,
that
thing
is
going
to
be
our
date
at
the
moment
is
published.
So
I
like
this.
Q
Just
ensure
so
T
times,
here's
to
that
back
to
Alworth
comments.
I
would
like
to
be
able
to
normatively
references
document
and
if
I
do
so,
it's
a
draft
I'm
starting,
miss
Rev
forever
and
we've
got
number
of
documents
sitting
there
for
longer
than
a
year.
So
we
need
to
figure
out
how
to
reference
documents
and
let
our
own
documents
to
progress.
Referencing,
the
stuff.
R
Julie
eglee
so
because
there's
a
bunch
of
present
or
former
80s
in
the
line,
I
think
part
of
what
happens
is
we
know
how
to
keep
working
group
documents
alive
forever.
Generally,
that
happens
inadvertently,
but
what
we
don't
actually
have
a
good
way
is
to
say
that
this
working
group
document
currently
is
a
is
the
product
of
working
group
consensus
without
actually
saying
well,
it's
been
last
called,
and
it's
actually
headed
off
to
the
ISDN
for
processing.
R
So
it
could
be
that
the
only
real
requirement
here
is
metadata
that
describe
the
current
state
of
the
document.
That
does
not
yet
exist,
but
that's
really
for
the
current
iesg
to
decide
not
for
me
to
speculate
on.
S
So
Orrin
Kumar
and
we'll
talk
about
this
more
later,
but
the
I've
heard
that
people
both
want
something.
That's
like
an
RFC,
because
that
has
standing
and
wait,
but
also
not
like
an
RFC,
because
then
it
has
to
go
through
stuff
which
gives
it
standing
and
wait
so
kind
of.
Following
on
from
what
Joel
said.
E
There
are
things
that
are
actually
fundamental
and
they
stay
the
same
for
20
years
and
there
are
things
that
are
currently
discussed
and
that
are
moving
and
kind
of
I
have
the
feeling
that
going
for
a
living
document
will
kind
of
tend
to
expose
exactly
what
is
being
discussed
right
now
and
the
fundamental
stable
long-term
things
being
not
that
well
presented
to,
especially
especially
the
newcomers
who
really
should
should
have
the
guidance
for
the
long-term,
stable
stuff.
First.
A
Yeah,
thank
you
for
your
feedback,
so
to
make
sure
the
room
is
in
alignment,
we're
attacking
two
problems.
At
the
same
time,
here
one
is
exploring
ITF
living
documents
as
a
concept
and
the
other
is
the
material
itself
routing
security
explained
to
newcomers.
So
this
is
a
bit
more
challenging
than
your
average
documents,
because
usually
you
only
do
one
of
the
two
at
the
same
time.
A
So
the
next
step
is
our
meeting
tomorrow
and
then
we'll
report
back
to
the
mailing
list
on
what
the
outcome
is
and
regardless
of
whether
ITF
can
facilitate
a
process
specific
for
living
documents.
I
think
we
should
start
with
a
draft
documenting
how
we
think
routing
security
works
in
2018
final
points
about.