►
From YouTube: IETF113-GROW-20220323-1200
Description
GROW meeting session at IETF113
2022/03/23 1200
https://datatracker.ietf.org/meeting/113/proceedings/
B
B
Let's
go
through
the
administrative
administrative,
that's
a
difficult
word,
administrative
side
of
things.
First
of
all,
this
session
is
covered
by
the
ietf
notewell.
B
This
means
that
we
adhere
to
a
certain
code
of
conduct,
specifically
in
relation
to
civility
different
than
other
meetings.
There
are
no
blue
sheets
to
go
around.
I
dearly
miss
the
tradition,
but
if
you
scan
the
qr
code,
that
was
here
at
the
beginning
of
the
session
or
go
to
the
agenda
on
your
phone,
there's
the
meet
echo
lite
application
and
that's
how
you
check
in
and
also
how
you
cue
yourself
up
for
the
microphone
since
this
is
the
third
day
of
itf.
B
B
B
C
B
E
Good
to
see
you
yes
great
great
and
thank
you
for
awarding
you
know
12
minutes
of
the
agenda,
not
10,
not
15..
That
was
a
greatly
appreciated.
It's
precisely
what
I
was
looking
for,
so
I
have
updates
on
two
drafts,
so
the
tlv
and
the
ebit
tlp
ebit
draft.
So
next
slide.
If
some
somebody
is
running
the
slides.
E
Perfect,
so
I
skipped
the
context
because
every
time
I
present
the
this
draft,
I
give
the
top
context.
So
it's
in
the
previous
slide
for
who
has
lost
the
context
for
this
one.
So
just
a
brief
update
on
what
happened
since
the
last
dra,
the
last
version
of
the
document
so
which
is
last
itf.
E
Essentially
we
formalized
a
little
bit
the
boolean
story.
Coming
from
you
know,
programming
background,
I
was
thinking
that
just
saying
boolean
was
clear
enough,
but
I
received
that
the
feedback
that
we
should
specify
it's
a
one
byte
field
with
you
know
zero
and
one
that
can
be
encoded
in
there.
So
thanks
very
much
to
jeff
and
bang
for
their
feedback
about
that.
E
Following
the
the
rest
of
the
recommendation
here,
they
they
were
all
coming
from
jeff
haas,
and
so
we
should
ask
ayanna
for
two
new
registries,
one
for
the
root
monitoring,
a
message
and
the
other
for
the
peer
down,
and
then
we
added
also
an
error
handling
section
so
in
which
essentially
what
we
say
that
the
tlvs
are
trailing
you
know
are
following
the
bgp
video
and
of
course
you
can
decode
the
tlds
only
if
the
bgp
pdu
is
well
formed.
E
E
E
Maybe
you
are
looking
for
the
root
mirroring
instead
of
the
root
monitoring
and
the
second
thing,
the
secondary
market
that
was
also
coming
from
jeff
was
that,
as
we
know,
you
know
the
message
size
is
limited,
and
then
this
is
already
you
know
a
problem
with
the
bgp
pdu
itself
and
with
bmp
by
itself,
because
there
is
a
decoration
around
the
bgp
pdu
should
it
hit.
You
know
itself
the
maximum
length
and
then,
of
course
this
is
aggravated
with
the
the
use
of
tlts.
E
And
so
this
is
the
status
for
the
version
7
of
the
draft
and
essentially
all
the
feedback
that
was
received
has
been
processed
and
there
is
really
no
more
outstanding
work.
So
this
is
a
message
for
the
chairs
and
also
I
don't
know
if
there
is
any
questions
or
any
any
anything
from
anybody
at
this
point.
B
E
Yes,
this
is
all
coded
on
the
collector
siding
pmsct.
It
is
coded,
it
is
working.
It
was
test.
There
is
at
least
one
vendor
that
I
am
aware
that
has
you
know
such
implementation,
so
yeah.
E
So
this
is
about
the
tlv
ebit.
So
this
is
the
last
present.
The
last
time
I
presented
this
was
at
in
singapore
in
2019
the
last
time
that
we
were.
I
I
was
in
person,
and
I
think
this
is
a
very
useful
draft,
but
you
know
we
received
even
in
the
room.
Some.
You
know
interesting
comments
about
it,
so
I've
I
thought
to
refresh
a
little
bit
give
context
again
and
share
updates.
E
So
next
slide,
please.
So
what
is
the
problem
statement
here?
E
Is
that,
of
course,
you
know,
we
have
tlds
that
we
explained
in
the
other
draft
and
till
these
are
public,
our
ayanna
governed,
and
you
know
we
asked
ayanna
for
registries,
and
then
you
know
every
you
know
id
in
that
registry
will
mean
something
that
is
something
for
those
registries
governed
by
ayana
are,
of
course,
for
you
know,
elements
that
should
be
supported
by
you
know
everybody
or
generally
supported,
of
course,
next
to
that
there
could
be
some
elements
that
are
not
that
are
proprietary,
that
are,
you
know,
not
public.
E
Why
is
that?
There
is
a
wealth
of
reasons
for
that,
so
the
one
of
the
most
common
is
that
it's
a
you
know
a
pre-standard
product
right.
Another
one
is
that
there
is
a
something
that
is
commercially
sensitive,
but
yet
another
point-
and
this
is
something
on
which
I
will
update
the
introduction
of
the
of
the
draft-
is
also
that
there
could
be
elements
that
are
very
low
level,
so
they
cannot
really
be
standardized
right.
E
They
could
be
low
level
or
really
touching
the
internal
of
the
implementation
that
maybe
it
doesn't
generally
exist
or
make
sense
to
make
something.
You
know
ayanna
go
there.
So
this
is
this
specific
point
which
is
very
relevant.
It's
not
yet
mentioned
in
the
draft,
and
I
will
do
in
the
next.
You
know
release
let's
say
and
next
slide,
please
so
as
an
introduction,
just
in
case
not
everybody's
familiar
with
the
pang
pang
is
a
private
enterprise
number
and
it's
a
number
that
is
assigned
by
ayana.
E
So
whoever
can
go
to
a
young
and
say
I
am
an
enterprise
and
a
young
hands
off.
You
know
an
id,
I
I
don't
know
if
it's
whoever
but,
for
example,
even
pmcct
as
a
pen
number
okay.
G
E
The
pen
is
the
key
in
order
to
make
the
enterprise
specific
part
to
work,
and
this
is
all
you
know
nothing
new
under
the
sun.
You
know
who
knows
me.
I
know
I
come
from
a
lot
of
experience
with
ipfix
working
with
ipfix
and
things
like
that,
and
I
just
borrowed
something
that
I
think
it's
very
useful
and
it
totally
works
for
ipfix.
But
you
know
porting
that
to
bmp
next
slide,
please.
E
So
this
is
how
ayanna,
gover
and
the
tlv
is
looking
like.
You
know.
So,
essentially
we
strip
the
first
bit
of
the
type
for
that
e
and
that
becomes
the
e
b
to
the
enterprise
bit,
which
could
be
zero
or
one.
So
in
a
young
gober
in
the
tlv,
the
e
bit
is
zero
and
then
everything
just
stays
as
the
other
draft.
The
tlv
draft
that
I
just
presented,
then
next
slide
please
in
case.
Instead
it
is
an
enterprise
specific
one.
E
E
So
what
is
you
know
the
status
right?
So
there
was,
you
know
some
feedback
that
was
processed
or
actually
all
the
outstanding
feedback
was
processed.
So
an
operational
considerations.
Action
was
added
again
on
on
under
suggestion
of
jeff
jeff
has,
and
essentially
he
was
recommending
that
you
know.
Whoever
is
endorsing
this
scheme.
E
Essentially,
should
you
know,
make
publicly
available
their
privately
defined
registries
and-
and
there
were
a
number
of
editorial
comments
and
things
like
that-
there
are
open
questions
like
what
could
be
the
scope
of
ebit
right.
So
for
so
far
the
scope
is
just
the
tlds,
but
of
course
the
you
know
you
can
make
private
messages.
You
can
make
private
stats
types
and
things
like
that.
I
mean
we
can
be.
E
You
know
more
ambitious
than
this,
but
I
would
say
that
first
of
all-
and
that's
the
next
question
whether
this
is
a
work
that
is
relevant
for
the
working
group
and
whether
you
know
it
would
be
accepted
and
the
last
time
just
for
an
extra
context,
and
with
that
I'm
done.
Let's
say
when
I
asked
this
question:
there
were
a
little
bit
of
mixed
feeling
and
then
I
wanted
to
see
whether
also
with
that
remark
that
I
was
making
before
about
that
ebit
is
also
about.
E
B
H
Ben
madison
work
online,
hi
paulo,
so
I
think
this
is
a
generally
good
idea
and
I
think
that,
given
the
overlap
from
an
implementation
perspective,
that's
likely
to
exist
between
bmp
and
ipfix.
I
think
kind
of
stealing
the
the
mechanism
is
also
a
good
idea.
Question
on,
could
you
go
back
to
the
the
packet
format
slide,
the
the
one
for
the
enterprise
variant,
the
next
one.
E
E
H
Make
sense
that
makes
sense
yes,
so
my
only
my
only
concern
here
is
that
this
ends
up
being
a
way
for
vendors
to
all
implement,
essentially
the
same
thing,
but
with
their
own
special
name
and
syntax,
and
you
know
various
different
ways
in
which
you
have
to
write
the
same
code
100
times
in
order
to
operate
a
multi-vendor
network.
H
I
think
that
I
think,
maybe
a
slightly
stronger
recommendation
about
making
a
registry
available,
possibly
in
some
sort
of
minimally
machine,
readable
format
might
go
some
way
to
help
alleviate
that,
but
I
think
you
know
a
a
fairly
strong
recommendation
that
this
should
not
be
used
other
than
for
you
know
temporarily,
for
things
that
are
likely
even
in
the
distant
future.
To
be
standardized
would
be
helpful
because
we
don't
want.
H
E
Yeah
yeah,
absolutely
absolutely,
and
you
see
this
is
very
along
the
lines
of
the
feedback
that
was
provided
also
in
singapore
in
2019,
and
that
time
who
was
saying
that
was
actually
it
was
job.
It
was
job
right,
our
very
and
true
job
and
the
the
my
answer
back
then,
and
that's
you
know,
the
only
thing
that
I
can
answer
today
is
that
so
first
of
all,
is
that
yeah
we
should
put
in
there
all
the
text
possible
right.
E
We
should
make
this
happen
because
it's
useful
and
put
in
there
all
the
text
possible
in
terms
of
recommendation
and
things
like
that.
The
second
thing
is
that
we
can
look
at
the
story
of
iphix
because,
fortunately,
since
we
are
not
inventing
anything,
we
can
look
at
the
past
and
see
how
that
worked
well
or
not
with
ipfix
and
in
latifix.
We
don't
see
that
happening,
that
they
all
have
the
very
same
thing,
but
not
standardized.
You
see,
there
are
things
that
are
certainly
remaining
permanent
right.
E
So,
for
example,
then
not
the
whole
career
grid,
not
logging,
for
example.
It's
something
it
that
is
staying
into
private
elements
and
things
like
that,
but
that
is
probably
because
there
is
one
vendor
only
implementing
that
or
two
vendors.
Only
you
see
so
I
from
the
story
of
ipfix.
I
feel
to
be
positive
that
this
mechanism
is
not
abused.
E
Of
course,
I
don't
have
the
oracle,
so
I
don't
know
what's
going
to
happen
and
I'm
totally
willing
to
do
our
part
as
itf
and
put
in
there
the
whole
world
that
we
should
be
putting
in
order
to
discourage
to
abuse
this
mechanism.
B
D
So
backing
up
ed's
comments,
I
pasted
a
presentation
that
I
had
given
the
prior
ietf
and
codepoint
management.
The
the
challenge
that
you
usually
end
up
seeing
for
this
stuff
is
that
it's
usually
back
pressure
that
you
get
from
the
registry
availability.
So,
like
the
majority
of
you
know,
bmp's
spaces
were
originally
done
under
very
tight
requirements.
D
The
current
one
is
under
a
specification
required,
which
is
not
quite
as
loose
as
first
come
first
serve,
and
what
we're
looking
for
for
stuff
that
you'd
want
to
put
into
non-enterprise
space
is,
if
this
is
generally
useful,
make
it
as
easy
as
possible
for
people
to
be
able
to
publish
a
specification
and
get
a
code
point
and
just
ship
their
feature,
and
you
know
that
said
part
of
the
back
pressure
that
you
get.
Is
you
know
what,
if
you're,
not
sure
that
it
knows
something?
D
That's
generally
useful,
giving
the
vendors
a
playground
to
be
able
to
do
stuff
is
a
useful
thing.
One
of
the
sort
of
dangers
that's
discussed
in
the
slides
is
that
when
you
do
these
sorts
of
things,
there's
always
the
concern
that
you
know
how
stable
is
the
vendor
going
to
make
something
if
it's
their
magic
number,
maybe
they're
less
concerned
about
stability
than
ietf
might
be,
and
we
see
this
for
incremental
deployment
of
pgp
features
is
the
example
that
we
give
in
the
slides,
so
the
enterprise
number
isn't
bad.
D
There
is
a
motivation
in
the
bmp
community
that
if
it's
generally
useful
feature,
we
should
be
pushing
people
to
push
put
the
stuff
into
public
spaces
and
we're
very
likely
end
up,
seeing
that
they're
could
be
transitional
scenarios
where
stuff
may
show
up
in
an
enterprise
field
and
they
stay
there,
while
also
manifesting
in
the
more
public
versions,
because
long
term,
the
goals
people's
collectors
will
want
to
gather
the
information
from
a
common
set
of
code
points
and
not
have
to
worry
about.
Well,
where
do
I
get?
Did
you
say
as
path?
B
I
So
let
me
redo
it
right.
I
want
to
make
it
short,
but
okay,
let
me
go
to
the
mic
now
so
benoit
class.
So
yes
in
the
history
of
ipfix,
we
had
the
same
concern
initially
and
we
have
not
seen
that
most
of
the
people
were
actually
eager
to
come
and
propose
them
to
ayana,
as
as
in
high
peak
information
elements,
the
only
one
that
were
not
done
in
ayanna.
There
were
particular
reasons
like
it
was.
I
B
The
queue
cleared
up
so
the
two
items-
paulo,
the
ebitd
thing.
You
said
it's
in
working
group
classical
and
the
chairs
need
to
do
work
and
for.
E
E
B
Thank
you,
paulo
next
up.
J
J
So
a
little
bit
of
context.
First,
energy
mp4
is
a
protocol
for
ir
mirroring,
as
many
of
you
may
be
aware,
but
maybe
not
all
the
internet
routing
registry
actually
consists
of
about
a
dozen
sort
of
authoritative
registries.
J
They
have
different
operators
different
purposes,
different
scopes
and
mirroring
exists
for
these
different
registries
to
be
able
to
mirror
data
from
each
other.
It's
a
one-way
process.
So,
for
example,
if
someone
queries
entity
comes
ir
server,
they.
G
J
See
data
that
has
been
mirrored
from
right
and
things
like
that,
and
also
a
number
of
operators
run
their
own
local
mirrors.
They
don't
have
authority,
but
they
run
their
own
mirrors
for
performance
analysis.
Things
like
that
there
are
a
few
common
implementations
for
for
ir
servers.
There's
a
few
versions
of
the
right
database
software
out
there,
which
runs
the
registries
from
rypn
c
and
ethernet
and
apnic.
J
J
So
currently
this
mirroring
is
done
with
nrtm
version
3
and
mostly
ftp
downloads.
This
is
a
very
poorly
specified
protocol.
There's
pdf
somewhere
it's
plain
text
overall
tcp,
so
that's
there's
no
way
to
check
any
kind
of
integrity
or
authenticity,
it
skills
very
poorly.
Essentially,
there's
it's
very
difficult
to
skill
at
all.
J
J
There's
also
the
streaming
of
new
changes
and
the
ftp
downloads
that
you
initialize
with
are
completely
unlinked
basically,
and
you
sort
of
have
to
hope
that
you
got
the
right
tool
matched
up,
because
there
are
many
fascinating
ways
in
which
nrtm
version
3
can
break
quietly
weirdly,
it's
actually
a
major
source
of
support.
I
give
to
users
of
ird
version
4.
J
So
the
new
draft
is
publishing
nrtm
data
publishing
the
ir
mirroring
data
on
a
https
endpoint,
which
creates
all
the
benefits
that
we
have
with
with
publishing
things
on
hbs,
which
is
a
thing
we
know
very
well
to
do.
It
is
inspired
by
irdb,
so
there
are
some
similar
concepts
and
names
in
here.
There
is
a
small
update
notification
file
which
functions
as
a
often
retrieved
index
and
points
to
a
snapshot.
J
J
J
The
end
contains
hashes
of
all
the
referred
files,
so
this
allows
integrity
checking
a
bit
more
on
that
later,
because
there's
still
some
open
ends,
but
the
idea
is
to
offer
integrity
checking
which
we
are
currently
missing
and
finally,
there's
a
random
session
id
which
has
to
match
otherwise
clients,
re-initialize,
and
this
basically
allows
mirror
servers
to
force
clients
to
re-initialize,
which
there's
currently
no
way
for
so
somehow
there
are
gaps
in
history,
clients,
silently
and
without
possibility
of
detection
or
recovery
run
out
of
sync
and
yeah.
It's
it's
bad
next
slide.
Please.
J
So
for
br
servers,
the
process
is
basically
going
to
be.
They
generate
new
session
ids.
I'm
obviously
skipping
over
a
lot
of
details
here,
but
this
is
the
broad
overview
they
generate
a
new
session
id
generator
for
snapshot
which
sometimes
may
be
empty,
not
typically,
a
new
update
notification
file,
publish
that
on
an
endpoint
and
then
you're
running
nrtm
version
4..
J
I
should
note
that
this
is
everything
in
the
protocol
is
per
ir
database,
so
ripen
c
who
publishes,
ripe
and
write
non-auth.
These
are
totally
separate
in
for
nrtm
version.
4.
next
slide.
Please
for
updates
every
minute
where
each
mirror
server
will
generate
a
delta
file.
If
there
are
any
changes,
if
they
were
a
little
late,
if
they
had
downtime,
they
can
catch
up,
but
generally
every
minute.
If
there
were
changes-
and
they
are
all
sequentially
numbered.
So
you
can
always
know
that
you
have
a
consistent,
complete
set
of
delta
files
without
gaps.
J
They
then
generate
and
sign
a
new
update
notification
file
also
periodically
there's
new
snapshot
files
so
that
new
clients
who
show
up
they
need
to
start
with
a
snapshot
file
so
that
shouldn't
be
too
old.
It's
not
necessarily
every
change,
so
we
don't
generate
snapshots
every
minute,
they're
too
large
for
that.
J
There's
also
a
regeneration
of
the
update
notification
file,
even
if
it
hasn't
changed
which
allows
detection
of
still
repositories.
Some
iar
databases
are
incredibly
quiet.
They
have
one
chains
every
few
weeks.
Maybe
so
this
allows
to
attack
like
is
an
ir
server.
Still
publishing
to
this
endpoint
or
or
not,
and
an
important
distinction
to
note
with
compared
to
energy
and
version
3,
is
that
we
don't.
J
J
Mirror
clients
they
retrieve
the
updates
notification
file
and
signature.
They
verify
it.
If
there's
data
there
and
the
session
id
matches,
it's
the
same
version
you're
up
to
date,
you
know,
and
you
don't
have
to
do
anything.
Otherwise,
the
client
tries
to
pull
in
the
deltas
to
get
to
the
latest
version.
If
those
are
not
all
present,
because
probably
the
client
is
has
run
too
far
behind
or
if
the
session
id
has
become
different.
The
client
will
always
reinactivize
from
the
snapshot
automatically
retrieve
that
verify
process.
J
J
I
won't
go
through
all
the
fields
of
the
file
in
detail-
that's
all
in
the
draft,
but
this
the
update
notification
file
which,
as
you
can
see,
essentially
lists
the
current
snapshot
and
the
version
of
that,
along
with
all
deltas,
the
the
ir
database
that
this
is
for
and
a
timestamp
of
publication
to
detect
stillness
next
slide.
Please.
J
The
snapshot
file
itself
is
a
fairly
simple,
contains
also
session
id
version
source
name
so
that
we
know
those
are
consistent
and
essentially
a
list
of
objects.
Nrtm
version
4
intentionally
does
not
go
into
the
actual
syntax
of
ir
objects.
J
Basically,
because
we
don't
have
a
singular
syntax
of
ir
objects,
so
yeah,
that's
why
they
are
they're
presented
as
encoded
strings
next
slide.
Please,
and
so
finally,
the
delta
files
are
are
similar.
They
list
changes,
so
one
delta
file
can
have
at
least
one
possibly
many
different
changes
of
deletions
additions,
modifications
to
objects
next
slide.
J
Of
course,
any
point
of
the
draft
is
open
to
discussion,
but
I
wanted
to
highlight
two
particular
ones.
The
first
is
the
database
configuration
file.
As
I
mentioned,
the
update
notification
file
is
signed
and
it
then
contains
hashes
of
snapshots,
and
the
idea
here
is
that
we
provide
end-to-end
integrity,
checking
so
the
ir
server
that
published
it
all
the
way
to
the
ir
server
that
is
processing.
This
there's
also
hps,
which
offers
transport
security
for
part
of
this,
but
not
all
of
it.
J
The
problem,
of
course,
then
becomes
how
does
a
client
know
which
public
key
to
trust,
and
how
do
we
deal
with
key
rotation,
for
example,
because
people
will
want
to
rotate
their
keys
clients
mirror
clients,
don't
really
sign
up,
there's
not
really
a
single
way
to
effectively
reach
them,
and
so
this
is.
We
have
a
plan
for
this
now
in
the
draft,
but
this
is
definitely
the
most
open
to
discussion
next
slide
please.
J
So
the
current
approach
we've
chosen
is
to
have
an
additional
file.
The
database
configuration
file
which
contains
ir
database
name
like
write,
private,
non-public,
signing
key
of
the
updates
notification
file
and
the
url
where
those
files
should
be
expected,
and
this
file
is
different
from
all
the
others,
in
that
it
must
be
published
on
a
well-known
uri
on
what
I've
called
the
generally
known,
authoritative
domain,
so
other
files
can
be
published
wherever
the
operator
wants
to
this
one
has
to
be
published
on
this
particular
domain.
J
It's
also
low
traffic,
and
the
idea
here
is
that,
if
I
would
say
radb,
then
everyone
who
is
familiar
with
the
ir
system
would
agree
on
the
same
domain,
name
that
we
would
all
trust
to
say.
Where
do
we
retrieve
the
update
notification
file?
Where
do
we
retrieve
nrtm
version
3?
Where
is
the
ftp
server
and
so
to
use
that
as
a
basis
of
trust
and
allow
configuration
from
there?
J
This
is
yeah.
So
this
is
our
approach
so
far
next
slide,
please.
I
only
have
two
more
slides
so
question.
Maybe
at
the
end
another
problem
is
delta
expiration,
because
many
of
our
clients
will
very
closely
follow
all
the
deltas
that
are
being
published.
They
retrieved
snapshots
the
update
notification
file,
frequently
download
any
new
deltas
they're
going
to
download
a
handful
at
a
time,
and
these
are
also
the
ones
that
we
want
to
have
low
latency.
J
So
that's
why
we
make
them
every
minute.
Some
clients,
though,
are
going
to
lag
behind
they're
going
to
be
down
for
a
while
connectivity
issues.
Anything
can
happen,
and
sometimes
they
are
days
weeks,
potentially
even
months
behind
and
they're,
going
to
start
up
and
with
one
minute
one
delta
every
minute.
Potentially
there
are
up
to
1440
deltas
okay,
but
for
many
databases
I
run
some
numbers,
it's
much
less
more
in
the
order
of
hundreds,
but
still
significant.
J
Next
slide.
Please,
and
so
the
initial
idea
was
trim
the
delta,
so
that's
their
size
cumulative
is
less
than
a
snapshot.
So
the
idea
is
downloading.
A
gigabyte
of
deltas
is
better
than
downloading
two
gigabytes
of
snapshot,
because
it's
still
less
data.
However,
ir
data
based
on
some
rough
calculation
is
changing
too
slowly,
and
so
a
client
that
is
running
three
years
behind
on
ripe
would
die
would
still
prefer
deltas
and
would
try
to
download
250
000
of
them,
which
obviously
doesn't
scale
so
optimizing
for
size,
does
not
work
here
next
slide.
J
J
So
the
current
new
plan
is,
we
expire
fast
after
24
hours,
so
anyone
who
is
more
than
24
hours
behind
has
to
reinitialize
from
the
snapshot
upside
is.
This
is
simple.
You
might
still
have
1400
downloads
if
you're
a
day
behind,
although
for
many
databases
it
would
be
less.
J
We
feel
that
it
would
be
a
good
balance
between
allowing
catcher,
preventing
excessive
downloads
and
simplicity.
Also
good
to
remember
is
this
is
all
automatic
in
nrtm
version
3.
This
is
all
manual
like
an
operator
has
to
actively
start
the
the
fresh
redownloading
process.
Another
idea
we
had
is
delta
irrigation,
where
we
aggregate
older
ones
into
larger
blocks
that
are
a
single
download
and
can
be
processed
in
bulk.
J
J
So
the
state
is
the
author
of
the
draft.
Ed
works
on
the
database
team
at
ripe
ncc,
and
I
am
the
author
and
maintainer
of
ird
version,
four.
So
the
authors,
we
are
also
the
people
who
needs
to
work
on
implementation,
so
there's
support
from
there.
The
right
database
working
group.
I've
also
presented
a
broad
strokes
of
this
in
a
off
session,
and
that
was
generally
supported.
So
there's
support
in
other
places,
also
for
at
least
the
general
concept
and
ideas
it
was
posted
on
the
mating
list.
J
B
B
B
So
from
that
perspective
it
felt
appropriate
to
to
bring
it
to
this
working
group
and
the
chairs
will
bring
the
request
to
the
mailing
list
to
guard
interest.
H
Hi
sasha
ben
madison
from
work
online.
Thank
you
for
working
on
this.
It's
really
really
long
overdue.
There
are
some
really
confusing
topics
that
I
have
to
take
new
recruits
through
and
what
to
do
when
an
rtm
version,
three
breaks
is,
I
think,
probably
the
worst
of
it.
So
it's
really
nice
to
see
someone
who's
actively.
Working
on
this
it
looks
I
haven't.
I
I.
H
I
read
a
really
really
early
markdown
version
of
this
that
I
came
across
somewhere,
but
I
haven't
read
the
most
recent
draft,
but
I
think
from
what
you've
described.
It
sounds
like
a
sane
solution
to
the
to
the
problem.
One
thing
that
I
found
slightly
confusing
is
the
the
term
session
id,
because
that
seems
like
it's
used
not
so
much
to
identify
a
session
between
a
server
and
a
particular
client
as
to
identify
the
base
from
which
a
delta
is
taken.
H
So
it's
kind
of
identifying
the
current.
The
current
snapshot,
that's
most
recent,
so
I
think
maybe
a
change
of
terminology.
There
would
make
that
less
confusing
the
I
had
one
suggestion
about
how
to
deal
with
the
trust
anchor
discovery
problem.
That's
a
little
bit
less
hand,
wavy
than
kind
of
hoping
that
everybody
knows
that
rad
b
is
radbeed.net,
which
is
probably
true.
It's
probably
not
a
terrible
assumption,
but
it's
it's,
maybe
not
very
robust.
H
One
of
the
problems
as
an
operator
that
mirrors
irr
data
is
there's
not
really
a
good
list
of
things
that
one
ought
to
be
mirroring
and
there's
not
really
a
good
list
as
a
consumer
of
transit
services,
for
example,
of
where
am
I,
which
databases
can
I
register
my
things
in
and
expect
them
to
be
generally
available
to
anyone
who
I
care
about,
and
that's
maybe
a
that
may
be
a
problem
we
can
solve
at
the
same
time
as
this
by
having
by
having
an
eye
on
a
registry
which
is
fairly
permissive
in
terms
of
its
you
know
its
policies,
but
where
people
can
actually
go
and
register
source
names
and
that
can
then
be
mapped
into
the
dns.
J
Yeah
I
I
do
like
the
ayana
rs3
idea.
I
think
we
had
it
briefly,
but
then
I
was
thinking
like
what,
if
I
email,
ayanna-
and
I
say,
hey,
I'm
I'm
ripe
and
here's
the
new
key
that
should
be
used
for
update
notification
file
and
we're
hosting
it
on
this
domain
now,
which
would
also
then
need
some
kind
of
verification
process,
but
I
think
there
are.
J
So
I
think
the
inner
registry
is
interesting.
Yeah.
D
Hi
this
is
jeff
sasha.
I
have
a
question
last
time
I
worked
on.
This
type
of
technology
was
back
in
1999
for
radb,
so
things
have
obviously
evolved
significantly
past
that
point
and
I'm
not
aware
of
them
at
that
time.
One
of
the
problems
around
the
snapshot
versus
the
incremental
diffs
that
you
get
was
a
dual
tension
between
the
diffs,
basically
encoding.
D
The
transactions
that
have
passed
through
the
server
people
were
interested
in
this
for
historical
and
other
auditing
reasons,
and
the
intention
of
being
able
to
quickly
resynchronize
when
things
you
know
broke
and
fell
out
of
sync.
This
happened,
especially
in
those
days
quite
a
bit,
because
the
software
is
the
reliability
of
the
indices.
J
Well,
traffic
on
the
servers
is
is
probably
not
the
main
concern.
The
the
the
issue
here
is
that
if
we
allow
a
client
to
catch
up
with
delta
files
after
three
years,
it'll
take
forever
like
the
client
will
do
this
automatically
it'll
find
that
all
the
deltas
are
still
there,
but
I
don't
immediately
know
of
stuff
my
head,
how
long
it
would
take,
but
downloading
250
000
separate
files
over
http
is
going
to
take
a
while.
J
D
D
I
completely
agreed
one
of
the
other
pieces
of
the
tension
was
finding
out
what
version
effectively
a
given
server
is
running
for
a
given
database
was
a
non-standardized
item.
Has
that
changed
in
the
interim.
B
D
So
as
an
example,
the
delta
file
gives
you
basically
individual
versions,
so
if
you're
up
to
delta
100,
you
know
that
this
is
as
far
as
you
happen
to
be
in
sync
for
this
database
at
the
time.
I
remember
that
ird
for
redb
did
have
the
ability
to
tell
you
what
version
it
thought
it
was
at
for
itself.
G
J
It
it's
kind
of
it's
a
little
bit
standardized
like
many
things
in
ireland,
but
in
rtm
v4.
That
would
be
the
snapshot
file.
So
the
snapshots
sorry
update
notification
file.
So
whatever
the
update
notification
file
says,
the
latest
version
is
that's
latest
version
that
was
published
there
is
to
catch.
I
suppose
that
what
the
server
is
running
at
right.
This
second
could
be
newer
because
it
might
take
up
to
a
minute
for
a
change
to
be
pushed
out.
C
D
I
I
think
that
is
in
the
lines
of
what
I'm
asking
about.
If
it
was
the
case
that
the
manifest
file
that's
reported
is
provided
a
conventional
consistency
because,
within
a
minute,
you'll
get
the
newest
data.
That's
probably
a
reasonable
thing.
If
a
fully
standardized
mechanism
to
query
the
database
version
number
is
not
present,
that
might
be
a
thing
to
spend
a
little
bit
additional
standardization
time
at
because
it
allows
a
local
cache
mechanism
to
decide.
J
Yeah
yeah
ird
will
also
offer
this,
because
we
have
some
non-standard
queries
right
now
they
become
sort
of
standard
partially
once
they
get
implemented
in
ird
version
4,
because
there's
there's
right,
tb
is
the
only
other
actively
developed
implementation,
but
yeah
there
will
be
also
direct
queries
but
yeah.
The
idea
is
this
update
notification
file.
D
The
detection
of
local
errors
would
be
great.
I
remember
that
at
the
time,
a
significant
problem
during
the
mirroring
process,
using
one
of
your
other
example
slides
if
you
received
an
object
that
could
not
successfully
be
parsed
locally,
because
the
implementations
were
different.
This
led
to
potential
situations
where
objects
were
out
of
sync
yeah.
B
Time,
I
think
jeff
in
ird
version
3
and
nrcm
version
3.
You
refer
to
the
serials
to
corrupt
the
distance
between
local,
locally
cached
data
and
what
the
remote
server
has
and
in
the
nrtm
version
for
notification
file.
That
is
called
the
version.
So
I
pulled
that
slide
up.
You
see
version
three
in
nrtm
version,
three
lingo
would
be
serial
free.
Okay.
Now
everybody
is
confused.
D
B
G
Yeah,
so
I
guess
I'm
a
little
bit
concerned
about
the
one
minute
snapshot
requirement
is
the
reason
why
it
isn't
kind
of
done
on
demand
based
on
when
there's
actually
a
change
you
know
or
for
the
you
know,
for
the
deltas
and
such
because
that
that
seems
like
having
that
always.
J
Misunderstanding
then
snapshots
are
more
rare,
because
they're
very
large
deltas
are
one
minute,
but
only
if
there
were
changes
if
your
ir
database
never
changes.
The
only
thing
you
have
to
do
is
update
this
update
notification
file,
which
is
very
small
just
to
sort
of
clients.
You
know
like
there's
someone
still
publishing
to
this
to
this
endpoint
yeah.
G
Okay
and
then
the
second
concern
I
have
is
about
whether
or
not
ayanna
is
the
right
place
for
there
to
be
a
registry
for
services
that
may
not
exist
in
the
future,
because
I
think
many
of
us
have
seen
irr
databases
come
online
and
go
away
over
time
and
going
and
sticking
it
in
a
registry
seems
a
lot
more
permanent
than
what
actually
exists
in
the
operational
space.
K
K
Retired
backbone
engineer,
I
wanted
to
jump
on
europe's
remark
that
nrtm
never
had
an
official
standardized
standardized
definition.
K
K
Not
not
quite
sure,
not
quite
sure
whether
this
will
actually
be
fixed
before
the
thing
is
forgotten
and
replaced
by
something
else
and
better.
B
B
Sasha,
thank
you
so
much
for
your
presentation
and
information.
I
think
we
are
gonna
move
on
to
the
last
presentation
of
the
grow
session.
F
F
Perfect,
so
can
you
go
into
the
next
slide
please?
So
what
we
are
proposing
in
this
draft
is
basically
a
young
module
for
com
for
managing
bmp
on
routers.
Why
not
well!
The
idea
is
to
have
a
standard
way
of
doing
that.
Bmp
sounds
like
a
simple
protocol,
but
is
it
well
simple
protocol
to
configure
and
manage,
but
is
it
let's
figure
out
ourselves
while
having
these
discussions
the
next
one
please?
F
So
what
the
model
has?
Basically
I
mean:
are
the
items
to
configure
and
monitor
vmp
on
devices
that
is
well
configure
your
stations,
the
connectivity
for
your
stations,
the
bmp
session
parameters,
I
like
to
highlight
two
things
that
probably
are
not
so
common
between
the
models
of
the
vendors.
That
at
least
we
have
read.
F
First,
is
an
action
to
clear
the
to
clear
the
session
with
the
bmp
station.
Well,
that's,
basically
it,
and
the
second
part
is
that
we
are.
We
try
to
be
very
explicit
in
how
we
configure
what
we
call
the
bmp
sources,
and
that
is
we
right
now
have
already
five
remotes
on
bmb,
the
the
latest
three
were
standardized
just
a
few
months
ago.
F
So
you
have
to
be
explicit
on
whether
to
say
you
this
remote
is
enabled
for
the
station,
then
for
others,
families
the
same
so
for
every
address
families
you
don't
take,
there's
no
default.
You
have
to
enable
every
others
family
and
for
the
rib
modes
that
are
actually
not
a
single
rib
but
multiple
ribs
per
pier.
F
Then
we
also
would
like
to
be
explicit.
That
is,
you
can
def,
so
you
you
enable
the
peers
that
you
want
to
send
information
from
or
to
explicitly.
You
can
select
that
individually,
so
by
using
the
by
reusing
the
remote
address
from
the
bgp
module,
also
by
the
type
also
you
can
define
which
peers
you
want
to
to
select
based
on
the
type
of
beer.
Here
we
are
also
reusing
the
the
bgp
peer
type
from
the
bgpa
module.
F
So
you
can
say
please
send
me
the
information
from
all
the
external
peers
for
the
internals
and
so
on,
because
we
also
needed
a
way
of
of
of
especially
saying
we
want
all
peers.
That's
why
we
also
added
an
enum
with
a
with
a
single
value
called
appears
in
the
vgp
mode
and
the
bmp
module
in
this
module
that
you
can
use
to
say.
Okay,
you'll,
send
me
everything
for
every
year.
F
So
we
already
had
a
good
feedback
on
this.
Thank
you
very
much
for
to
team
jeffrey
and
tom.
For
this.
We
already
addressed
some
of
them
some
of
the
issues,
mostly
the
ones
from
tom
that
were
very
low
thinking,
fruits
and
some
of
them
very
clear
mistakes
in
this
version
that
we
already
uploaded
versions.
0.2,
I'm
not
going
to
go
into
the
details
next,
one,
please
yeah.
F
So
we
do
have
some
some
pending
points
that
we
promised
to
tackle.
In
the
next
version,
tim
mentioned
the
vmp
session
options,
initialization
delay,
backup
times.
F
We
will
actually
re,
take
a
look
again
to
all
the
modules
from
the
vendors
that
for
for
configuring
bmp
and
see
what
else
we
might
be
missing
to
try
to
add
them.
Jeffrey
mentioned
the
tcp
module.
That
is
that
is
I
mean
we
can
really
leverage
that
module
to
try
to
another
invent
the
wheel,
how
to
use
it.
F
We're
really
not
sure
that,
for
instance,
we
could
actually
copy
the
four,
the
four
the
four
tuple
connection
from
there:
it's
not
in
a
grouping,
so
maybe
we
can
just
copy
it
or
I
don't
know
or
we'll
see
how
we
can
integrate
it
and
maybe
and
then
we
can
discuss
it
all
together
units
for
stats
where
to
place
the
module
in
the
routing
tree.
This
can
be
important,
so
we
so
if
we,
for
instance,
we
put
in
under
network
instance,
then
we
can.
F
You
know
we
can
use
the
we
can
directly.
We
can
directly
monitor
those
the
network
instance
from
there,
or
we
can
put
the
network
instance
in
a
bmp
source
so
where
to
place
the
model,
the
module.
The
model
is
it's
a
good
question
to
have
and
of
course,
adding
examples
to
I
mean
to
enlighten
these
trade-offs
next
one,
please
john.
F
So
this
is
it
well
grove
works
on
the
vmp
and
we
have
been
working
in
the
last
few
years
about
this.
So
I
think
it
makes
sense
to
have
this
draft
in
the
group,
but
I
also
let
you
guys
discuss
that
besides,
that,
if
you
guys
have
any
other
questions
or
comments,
guys
and
girls.
B
Thank
you.
Jeff
has
you're
up
first.
D
So,
yes,
I
absolutely
think
we
should
adopt
this.
I
agree
that
there's
gonna
be
a
little
bit
of
churn,
as
we
figure
out.
D
D
D
Part
of
the
reason
to
point
you
towards
the
tcp
module
and
potentially
longer
term
discussion
towards
the
itf
key
chain
module
is
you'll,
want
to
figure
out
how
authentication
actually
rolls
into
this.
So
if
you're
running
like
tcp,
ao
or
tls,
or
something
else
similar
for
the
sessions,
you'll
want
to
model
that
not
only
for
configuration
purposes.
But
you
know
what
your
operational
state
is
for
that.
B
C
Yeah,
I
think
this
is
a
useful
work,
really
helpful
for
the
configuration
of
the
bmp.
My
brief
comment
is
that
it
is
better
to
consider
the
alignment
with
the
the
pgp
model,
like
the.
C
C
C
F
G
F
B
All
right,
so
the
to-do
item
for
the
chairs
appears
to
be
to
issue
a
call
for
working
group
adoption.
This
would
be,
I
think,
the
first
time
the
grow
working
group
has
any
involvement
with
yang,
so
there
there
might
be
a
bit
of
a
learning
curve
for
some
of
us,
at
least
for
for
me
myself,
but
together
we
are
strong.
B
John.
Thank
you
so
much
for
this
presentation
and
this
concludes
the
grow
session
at
iatf
113.
I
hope
to
see
all
of
you
at
iatf
114
in
philadelphia
and
a
big
thank
you
to
the
meat
echo
team.
I
have
to
say
this
has
been
the
smoothest
running
hybrid
session.
I
have
been
part
of
so
folks
behind
the
camera.
Thank
you
very
much
well
go
enjoy
your
break
and
see
you
next
time.