►
From YouTube: IETF99-I2RS-20170718-1550
Description
I2RS meeting session at IETF99
2017/07/18 1550
https://datatracker.ietf.org/meeting/99/proceedings/
B
D
C
Folks,
what
some
people
have.
C
A
C
C
C
Will
go
with
will
go
with
the
tape,
then.
Okay,
we're
going
to
start
start
is
where
the
where
the
meeting
that's
between
you
and
bear
and
dinner,
so
I'm
gonna
go
through
the
agenda
and
then
Al
and
the
chair
slides.
Unless
you
wanted
to
do
it,
I
can
do
it.
Oh
okay,
so
it's
Alex
you're
up
is
anyone
seen
mark
so
far?
Okay,
he
may
not
make
it.
He
had.
Another
meeting
am
I
too
loud,
though
okay,
so
the
agenda
they've
written
the
note.
Well
again,
please
read
it
enjoy
it.
C
How
many
people
have
never
seen
a
note?
Well,
okay!
Well,
then,
please
read
it
there
online.
The
first
thing
we're
going
to
do
is
we're
going
to
bash
the
agenda
and
we'll
go
through
the
church
to
chair
status
being
as
it's
late,
we
may
run
a
little
later
into
the
chair
status
time,
but
we
have
a
fairly
short
set
of
model
reviews.
The
data
models
were
going
to
go
through
the
topology
drafts
went
to
the
is
Jian
came
back
because
the
revised
data
store
issues
had
not
been
finished.
C
Now
that
met
mod
has
kindly
finished
stuff,
and-
and
given
this
good
advice
and
the
thirties
group
has
worked
alex,
will
give
a
brief
update.
Mock,
went
through
his
data
model
in
info
model
to
see
if
they
were
revised.
Data
stores
we
may
haven't
had
it
checked
on
yang
models.
But
if
he's
not
here,
I
will
give
a
brief
check.
C
Then
we
will
go
through
some
new
models
fabric
data
center
and
see
you
separation
models
and
then
most
of
this
session
was
to
see
if
we
had
interest
in
a
design
team
for
a
family
data
store,
I
will
go
through
a
description
of
that
and
then
I
will
call
for
volunteers.
Then,
at
that
point
we
will
break
out
into
working
on
a
design
team,
because
I
figured
most
people
the
ephemeral
data
stores,
probably
just
so
simple.
C
We
might
be
able
to
finish
it
at
this
time
or
we
might
be
able
to
get
a
good
long
way.
Then
our
next
session
was
set
aside
for
a
data
store
to
get
a
room,
but
they
gave
us
a
large
room,
so
I'll
try.
If
I
get
a
data
center
team.
Now
I'll
go
right
into
the
the
chair,
slides
on
that
because
what's
important
but
I've
lost
the
chair,
slides
okay,.
C
What
we're
doing
is
we're
at
the
end
of
our
two
major
models.
Our
major
models
are
our
network
model
and
our
game
topology
model.
We
think
that
this
is
all
done.
I
think
the
road
data
model
has
to
the
25th
to
make
a
comment,
but
these
are
about
ready
to
go
once.
We've
checked
with
the
aim,
doctors
and
officer
and
routing
der
for
their
cue
A's,
and
these
will
go
carefully.
We
will
I
will
be
asking
at
least
it
my
input
from
the
t's
working
group
and
people
for
an
early
RFC
publication.
C
If
the
ISU
approves
of
the
topology,
so
the
t's
work
can
go
through
and
several
others,
the
read
model
will
probably
go
through
a
normal
speed,
but
there
are
implementations
of
large
size
coming
remember.
These
models
can
go
into
configuration
or
dynamic
data
store;
they
are
simply
models.
They
aren't
designed
to
be
ready
for
dynamic
data
store
and
have
been
implemented
in
it.
I
think
I've
said
everything
on
this
slide.
This
little
thing
is
congratulations
to
the
working
group
for
having
gotten
through
the
big
major
models.
C
C
C
So
looking
for
that
design
team,
if
you're
looking
for
a
quick
term,
that's
what
we're
doing
our
choices
are
again.
Work
on
the
ephemeral
state
work
on
the
new
models
for
specific
deployments
and
wait
for
week
for
more
implementations
at
the
end
of
all
the
models,
I
will
show
the
network
data
store
model
actually,
at
the
end
of
all
the
models,
they'll
take
a
pause
and
ask
for
people.
If
they
have
any
opinion,
then
we'll
go
into
the
revised
data
store
model
and
for
those
people
who
want
to
work
on
it.
C
If
there's
no
one
that
want
to
work
on
it,
that
will
take
us
into
the
go
on
hiatus.
While
we
finish
everything
questions,
this
is
really
a
time
of
choice.
If
the
working
group
says
okay,
we've
done
everything
and
the
information
in
the
revised
data
stores
is
enough
for
corporations
to
develop
their
own.
That's
great.
We've
done
a
good
job
at
setting
everything
up
and
doing
the
pumps
up
and
getting
the
push
and
getting
these
basic
models.
I
C
J
They're
two
drafts,
one
is
the
basic
topology
model.
The
second
is
the
layer.
Three
topology
model
I'm
excited,
so
basically
they
have
been
a
fuel
updates,
and
so
the
topology
model
went
from
the
zero
from
the
12
to
the
14
and
the
layer.
3
topology
model
from
the
8
to
to
the
to
the
10
graphed
and
the
main
update
most
whoops.
J
20
they're
the
most
important
up
it
is
that
we
changed
up
the
model
tool
to
MDM
da
compliance,
and
this
was
Sol's
and
particularly
to
address
the
mix
discovered
underlies
and
configured
over
the
issue
that
we
had
that
we've
struggled
with
for
such
a
long
time.
This
was
basically
the
the
cleanest
resolutions
of
basic
and
glad.
Actually
that
worked
out
this.
Basically,
the
structure
of
the
model
actually
has
remained
the
same.
Actually,
the
change
is
actually
very
minimal.
I
think
we
only
change.
J
All
of
the
description
updates
was
that
the
server
provided
leaf
is
is
gone
then,
and
then,
in
addition,
that
was
actually
was
in
the
in
the
latest
revision
we
did
add,
also
a
state
model
for
non
and
MDA
compliant
implementation.
That
was
a
comment
that
was
made.
I
think
it
would
be
a
good
idea
to
add
that,
so
we
have
this
actually
in
there
in
there
as
well.
We
move.
J
Because
there's
bidding
just
for
the
non
and
named
MDA
compliant
implementations
and
yeah,
so
the
updated
module
models
have
been
reviewed,
but
of
course,
we'll
be
happy
to
to
get
your
review.
I'm,
Kent
and
also
I
wanted
to
mention
also
that
the
security
consideration
have
also
been
updated
and
and
and
reviewed.
Basically,
it
does
explain
basically
the
fact
that
we
rely
on
the
other
line
transport
and
knock
them
to
provide
security.
J
In
addition,
basically,
we
have
added,
basically
explanation
of
various
exploits
that
it
could
do
if
you
were
to
mess
configuration
if
you
did
not
have
that
access
okay,
next
one,
and
so
basically
the
next
steps
are
essentially
the
network.
Topology
draft
is
done.
We
hope
the
tree
topology
draft
is
practically
done.
It
doesn't
require
actually
one
more
revision
with
very
minor
a
place.
There
was
also
another
yang
dr.
think,
Christian
hops
rise.
J
J
C
K
K
C
C
L
Hello,
everyone
now
here
come
to
the
two
models
focusing
on
the
fabric
based
management's
for
this
internet
work.
The
first
one
is
about
the
network.
Topology
and
another
is
the
service
model,
and
these
two
model
have
been
presented
for
several
times
and
so
and
they
give
a
breath
introduce
an
introduction
about
these
two
models.
Next
slide,
please
the
objectives.
L
The
service
model
is
defined
to
represent
the
services
for
the
users
in
order
to
deploy
the
service,
while,
regardless
of
the
details
of
the
network
such
as
the
halogen
technology
and
many
others,
while
the
fabric
pays,
the
topology
model
is
used
to
define
fabrics,
topology
module
to
manage
the
Death
Angel
Network
in
architecture.
We
give
the
usage
of
these
two
models.
L
L
The
fabric
to
purge
model
is
firstly,
proposed
in
ITF
96
in
Berlin,
while
in
ITF
97
we
updated
the
fabric
topology
model
due
to
the
comments
and
and
the
besides.
We
also
propose
to
the
fabric
a
service
model
as
the
servicing
of
s
2
users
to
configure
or
manage
the
user
natural
fabric
topology.
Besides
that,
in
the
fabric
service
model,
we
also
define
an
architecture
in
architecture.
We
explain
how
these
two
models
come
to
cooperate
together
in
order
to
provide
a
service.
L
Besides
that,
we
also
add
new
orders
in
order
to
participate
in
the
work.
My
last
idea
in
Chikako,
we
resolved
the
comments
on
comparing
the
fabric
model
with
the
heat
polity
model.
After
discussion
with
the
heat
policy
authors,
we
both
make
the
consensus
on
the
difference
between
these
two
models.
Besides
that,
we
add
some
descriptions
and
revise
the
models
based
on
the
comments
next
slide,
please
and
after
the
IDF
98,
we
also
make
some
actors
added
on
these
two
models.
L
Firstly,
due
to
the
recommendation
by
the
area
directors,
we're
also
updates
the
models
to
natural
management,
database
architecture,
style
style
and
also
in
appendix
we
provided
a
noun
MD,
a
fabric,
topology
state
module,
in
fact
that
as
people
show
more
interest
in
fabric
modules,
so
we
remove
the
contents
of
the
fabric
capable
device
at
this
model
is
independent
with
our
two
Tomatoes,
the
very
fabric,
our
topology
module
and
the
service
module.
Besides
that,
or
also
make
some
editorial
changes
next
slide
place
after
this.
L
B
C
M
M
Also,
this
work
can
monistic
can't
reduce
the
time
to
market
because
the
the
in
children
and
the
user
can
be
separated
and
the
device
of
them
can
be
extended
separated,
so
it
can
significantly
reduce
time
to
market.
So
last
things
we
can
get
benefit
is
because
some
PNG
network
and
anytime,
maybe
a
large
number
of
user
accessing.
So
if
we
have
a
dynamic
control
plane
to
handle
it
either
will
improve
if
usage
to
the
network.
Okay.
M
So
how
to
achieve
this
see
you
separated
network
in
this
document
will
provide
an
information
module
to
present
interaction,
interface
between
the
control
plane
and
the
user
plane
this.
If
this
world
could
be
standardized,
it
can
help
the
interaction
work
between
interwork
between
different
devices,
for
example,
if
the
controller
and
devices
is
from
winter
a
and
the
user
Briand
devices
are
from
winter
BCD,
and
if
we
have
a
sender
information
modules
that
can
help
them
to
understand
each
other
and
help
them
understand,
I
recognize
what
is
attributes
table
carried.
M
So
this
information
module
basically
have
two
blocks.
The
one
is
introduced,
control
plane
the
interface
it
contributed
information.
Now
there
is
in
introduced
Europeans
in
information,
so
came
to
plan
your
from
the
contributing
is
take
charge
of
generation,
interest
tables
rules
and
it's
an
essential
user
plane
and
its
user
plan.
We
are
mapping
to
some
policy
and
in
performing
corresponding
action.
Another
rules
of
the
user
plane
is
to
report
as
a
traffic
statistic
to
the
user,
to
the
king
to
blame
for
and
next
rise
a.
We
provide
a
example
of
this
information
module.
M
Okay,
we
can
see
in
this
picture-
even
maybe
a
user
name,
the
Bob
he
is
assessing,
and
then
you
can
see
the
figure.
It's
a
user
plain
view,
Barb's
information
and
the
traffic.
A
statistic,
for
example,
available
bandwidth,
choose
a
control,
plane
controlling,
receive
assistive
information
and
then
searched
public
corresponding
service
requirement.
It's
in
generated
Auto
generate
some
service,
some
tables.
So,
for
example,
a
users
information
table
I
chose
each
episode.
M
It's
a
king
user
plane,
okay,
a
set
of
tables
is
a
relative
choose
Bob
and
there's
a
Bob
sauce
in
for
ipv4
information,
and
the
pubs.
Curious
requirement
for
window
here
is
provide
examples,
say:
R
is
6
and
be
per
second
pyaara.
Is
it
and
be
per
second
and
then
to
use
a
contribution
census?
Several
schools
choose
European
European
receives
the
troops
and
mapping
and
mapping
to
corresponding
policies,
and
here
is
some
policy
example
the
user.
M
M
Okay,
this
page
is
a
provider
update
from
last
night
meeting
and
in
the
0-1
version
we
write
into
users,
information,
module
and
user
planes,
information,
module,
characteristic
practice
among
clerical
errors
and
improve
the
readability.
Here
is
a
figure.
2
shows
a
periphery,
introduce
user,
clean,
the
behaviors,
the
user
plan
receives
rules
and
the
map
into
power,
say
map
mapping
persons
and
perform
Cosmin
actions,
and
another
things
we
update
is
a
debt
exception
to
introduce
data
model
of
Co
separate
the
PNG
network.
M
E
M
C
You
Michael
and
again
we're
gonna
cover
some
of
these
adoptions
in
our
general
questions,
so
any
questions
for
Michael
well,
thank
you.
We
will
go
on
to
the
next
step
again
I'm,
going
to
repeat
what
we
started
out
in
the
chair.
Slides
is
our
major
work
item
left
is
to
create
a
femoral
or
a
dynamic
dais,
or
that
was
an
initial
Charter.
Of
course,
with
the
dynamic
data
store,
we
could
create
one.
That's
not
in
our
wonderful
map.
Mod
provides
datastore
version
3
there
is
a
appendix
which
provides
a
great
deal
of
the
information.
C
You
should
see
the
example,
a
federal
state
that
Kent
and
other
his
co-authors
provided
and
there's
a
wonderful
extension.
Now
we
can
go
through
and
continue
to
work
on
that,
but
we
need
a
design
team.
So
right
now
we're
going
to
do
what
we
lovingly
call
the
hum
moment.
I
would
like
to
hear
a
hum
on
people
who
want
to
work
on
this.
Revised
data
stores.
Work
means
be
an
author,
be
a
revisor.
A
C
C
I
C
This
is
an
place
like
our
TWG.
We're
models
can
come
to
find
a
home,
it
doesn't
have
to
be
ephemeral,
it
doesn't
have
to
be
dynamic
and
simply
be
a
platform
wide,
not
a
specific
protocol
and
protocol
independent.
So
in
that
hat
the
fabric
model
fits
so
we'll
ask
that
question
and
for
Michaels
we
have
a
secondary
question.
So
I
will
ask
the
question,
because
that
will
help
the
ad
and
I
and
Russ
and
Aliyah
and
I
to
direct
the
author's
to
their
best
next
step.
C
C
Okay,
so
we
do
here
some
interest,
that's
a
sort
of
well
yeah,
you're,
hearing
it
probably
better
than
I
okay
for
Michael's
draft
and
his
wonderful
co-authors.
That's
the
one
Michael
did
you
present
in
our
DWG
as
well?
Yes,
okay,
what
was
your
feedback
there.
C
C
Other
people
have
suggested
that
it
may
be
aligned
with
other
things,
such
as
a
BBF
because
of
his
application,
and
the
reason
why
it's
here
is
not
necessarily
and
it's
ephemeral
or
dynamic,
although
you
can
see
the
benefit
of
that
for
his
model,
but
because
it's
protocol
independent,
so
I'm
going
to
ask
for
sense
of
the
room
by
the
way
we
will.
We
will
send
these
to
the
list
as
well,
but
as
a
sense
of
the
room
for
the
ad
and
Russ
and
I.
How
many
people
are
interested
in
reviewing
this
model
I
from
heylia?
C
You
here
are
our
answer:
was
that
a
medium
or
was
that
a
high
for
the
note
taker
meeting
that
was
meeting
okay?
So
that's
energized,
quick,
okay,
so
that
gives
the
that
is
the
chairs,
because
of
that
we'll
get
together
and
and
send
the
authors.
What
we're
going
to
do
as
far
as
making
a
working
group
call
unless
you
want
to
yeah
so.
N
I'm
really
happy
to
hear
that
there's
interest
in
additional
work
and
models,
but
one
of
my
questions
is
getting
the
base
pieces
done
and
having
the
energy
and
participation
and
need
in
terms
of
implementations,
for
instance.
To
do
so,
and
so
for
that
I
mean
I
personally
feel
like
there's
a
lot
of
value
in
the
read
models
and
apology
models.
N
One
of
the
questions
is
for
other
pieces
of
work
that
the
working
groups
working
on
like
the
filter
based
rib.
You
know
the
interest
level
in
that
I
have
talked
with
the
chairs
about
looking
at
winding
down
the
working
group.
If
there's
not
enough
energy
and
if
we're
not
having
folks
actually
actively
volunteering
to
do
things
like
Shepherd
and
review
documents.
I
know
that
part
of
the
challenge
in
this
working
group
has
been
that
a
lot
of
the
documents
are
there.
Sorry
I
mean
a
lot
of
the
challenge.
N
N
Some
of
the
ephemeral
data
store
were
in
order
to
do
full,
implement
heat
as
for
these
standards,
compliant
for
what
it
would
be
implementations,
and
so
one
of
the
questions
I
have
is
how
many
people,
of
course,
now
I
can't
hear
the
helmets
well,
either
how
many
people
are
willing
and
interested
to
seriously.
You
know
work
on
things
like
the
data
store,
reviewing
documents
and
and
so
on
in
the
next
six
months,
if
I
can
have
a
hum
for
that,
that
would
be
useful.
N
I
was
actually
asking
in
general
for
the
work,
because,
because
I
think
that
what
I
found
interesting
is
that
was
actually
different
and
less
than
the
people
who
are
interested
in
some
of
the
new
documents.
I'm
lonely
I'm
extremely
concerned
about
the
idea
of
trying
to
adopt
new
documents
in
the
working
group.
If
there's
not
energy
in
the
working
group,
because
there
are
other
places,
if
we
need
to
that,
we
could
put
them
right.
I'd
like
to
see
the
work,
that's
in
the
working
group
get
done,
we've
done
a
lot
of
stuff.
N
When
we
started
this
working
group,
we
thought
wow.
If
we
could
just
get
data
models,
I
mean
just
getting
the
RHIB
data
model
get
some
of
the
stuff
done.
That
would
be
huge
and
a
big
change
for
the
industry
and
I.
Think
we've
seen
a
lot
of
that
happen
already
a
lot
of
the
features
that
we're
looking
for
to
go
into
net
cons
and
rest
cons.
Are
there
it's
awesome?
N
But
the
question
is
you
know
at
what
point
do
we
say
that
was
great,
but
now
we
don't
have
energy
or
at
what
point
do
we
say
this?
Was
great
and
now
we're
really
gung-ho
to
go
focus
on
this
piece
and
that's
what
I
need
you
all
to
be
thinking
about
my
understanding
is
the
ephemeral
data
store
work
to
actually
do
that,
particularly
if
we
have
some
productive
sessions
this
week
is
not
that
high,
but
I.
N
Really
need
to
have
you
know
what
the
question
I'm
facing
is:
do
I
recharter,
or
do
I
close
I
who
are
us
and
when
do
I,
do
it
and
that's
based
on
you
know,
interest
and
energy,
as
is
not
a
I
want
to
I
want
to
close
I
to
are
us.
This
is
a
if
this
is
what
the
status
is.
That's
what
it
is
and
I
need
to
know
that.
O
C
G
Yeah
I'm
economy,
so
the
working
group
from
the
original
architecture
document
fair,
it's
far
away
and
the
original
intent.
What
was
you
know
in
the
in
the
in
the
architecture
and
what
is
being
developed
today
are
two
different
things.
So
from
that
perspective,
me
personally,
I
have
I'm
coming
here
to
see
if
there
is
something
coming
back,
but
so
far
from
my
perspective,
you
know
from
the
original
intent
and
what
we
it
when
the
the
the
working
group
went
to,
our
you
know
ended
up
in
very
you
know
differentiated.
G
N
I'm
very
well
aware
so
I
would
argue,
actually
the
push
notifications,
the
ability
to
do
dynamic
pushes
and
subscriptions
are
one
of
the
pieces
there.
We
have
an
understanding
of
how
to
actually
do
the
priorities
to
handle
multi-headed
control.
That's
there.
We
have
the
dynamic
data,
store,
understood
what
needs
to
happen,
but
not
nailed
down.
Yet
we
have
the
RHIB
model,
which
lets
us
provide
a
programmatic
interface
at
the
right
level.
If
you're
talking
about
speed
issues,
sure
that's
a
concern.
G
C
G
It
is
essentially
not
compliant
with
image
with
the
majority
of
the
documents.
One
other
thing
you
know
which
I
ran
into
it,
that
there
are
some
there
were
some
issues
that
they
had
to
go
different
ways
and
different
paths.
So
some
of
the
things
are
useful,
but
you
know,
majority
of
the
things
are
a
little
bit.
You
know
problematic,
so
I'm
I'm
keeping
an
eye
on
it,
but
I
am
NOT.
You
know
again
doing
active
contributions
because
you
know
it's
a
the
path
has
diverged
it's
off
a.
C
Point
of
clarification,
if
we
had
a
net
mod
exist,
be
net
Kampf,
Andres
Kampf
for
two
initial
pieces,
as
we
announced
in
the
last
couple
things
people
with
an
alternative,
Fiat,
binary,
BAC
bore
or
whatever
you
have
are
still
open.
Are
you
suggesting
something
linked
like
to
see
something
like
that
with
an
yet
another
affirmative.
G
Not
necessarily
to
be
nice,
but
not
necessarily
because
it's
it's
more
about
the
interactions
between
the
app
between
the
applications
between
the
how
I
see
the
address
is
useful
between
the
management,
service
control
and
data
play,
and
some
so,
and
especially
with
the
breaking
up
of
the
data
plan
and
the
control
plane
and
the
control
plane.
Separation.
Sorry
of
the
control
plane
data
plan
that
they
define
the
service
point.
G
Don't
think
it's
that
the
distant
it's
more
about
agreeing
on
you
know
on
the
applications,
for
example,
one
of
them
is,
we
were
having
that
today,
for
example,
is
I
want
to
do
an
LSB
and
from
a
user's
perspective,
is
how
I
want
to
use
the
LSP
or
how
I
want
to
use
the
aqua
and
then
defined
it
here?
How?
How
is
it?
G
How
is
it
being
used
and
what
API
in
an
or
the
what
an
API
to
do
in
order
to
communicate
that
their
desire,
I'd,
wanna
I'm,
purposely
I,
want
to
use
the
word
intent.
So
your
desire
to
be
that
being
in
essentially
through
the
control
point
being
established
and
deployed
under
the
data
play
so
coming
up
with
those
use
cases
and
saying:
okay
here,
I,
might
you
know
here's
my
comment,
el
fip,
here's
my
you
know
common.
C
C
E
C
G
N
You
very
much
that
was
just
a
clarifying
question.
The
question
is
more
use
case,
but
more
the
point.
As
you
say,
you
have
an
implementation
and
what
we've
been
doing
here
is
diverged.
Are
there
other
people
and
I
feel
free
to
raise
hands
or
come
up
to
the
mic
who
are
in
similar
boats?
Is
that
are
there
pieces
that
are
have
been
implemented,
and
it
just
feels
like
this
is
not
has
not
been
going
down
the
right
path?
N
Okay,
so
let
me
pull
that
your
contributions
are
welcome.
The
intent
was
not
to
go
down
the
different
paths
and
if
we
don't
understand
what
the
divergence
is,
it's
hard
to
improve
it
running
code
really
matters.
That
said,
but
then
I
go
back
to
Phil's
point,
which
is
all
right,
raise
your
hand
or
stand
up
if
you're
willing
to
work
on
documents
in
the
last
next
six
months
to
get
different
pieces
done.
N
So
I'm
not
gonna,
try
it
I
mean
if,
if
I
Taurus
were
to
continue
for
a
long
period
of
time,
that
I
would
be
looking
at
doing
things
like
reach
our
Turing
to
add,
in
some
of
the
pieces
that
we
talked
about
in
some
of
the
Netcom
net
mod
recharter,
to
clarify
the
pieces
that
need
to
happen.
But
we've
got
you
know
an
agreement
and
I'm
happy
to
at
least
let
things
run
through
the
next
IETF
and
see
how
things
go,
but
we
really
need
to
actually
have
energy
in
motion.
N
I
know
that
some
of
the
models,
like
the
apology
stuff,
are
things
that
certain
projects
are
depending
on
and
we're
not
really
seeing
folks
coming
and
participating
and
saying
hey.
This
is
what
we
need.
A
lot
of
energy
has
been
put
into
the
working
group
by
you
know.
Sue
is
one
of
the
chairs
and
that's
not
something
that's
fair
to
depend
on
and
it
doesn't
represent.
The
group
right
I
need
you
all
who
raised
your
hand
to
be
active,
reviewers
and
active
drivers.
C
Has
the
input
now
the
next
step
we're
going
to
do
is
for
those
who've
raised
your
hands,
who
want
to
work
on
the
ephemeral
data
store
for
the
model.
People
I
think
the
Lea
and
I
will
get
back
to
you
on
that
I
apologize
for
this
pause
here,
but
we
will
get
back
to
you
within
a
day
or
so
and
if
you're
here
the
rest
of
the
week,
we'll
try
to
meet
with
you
individually.
So
we
really
appreciate
your
hard
work
and
Michael
I.
N
Let
me
just
clarify
clearly
there's
interested
in
both
of
both
of
the
models
and
the
work.
The
question
is
not
should
the
work
proceeded
and
it,
of
course,
I
understood
this.
The
question
is:
should
it
proceed
here
or
would
it
make
more
sense
for
it
to
happen
in
RT
gwg?
Due
to
the
you
know,
if
we're
trying
to
closed,
you
know
work
on
heading
to
finishing
up
the
work
and
I
RS,
then
it
might
make
more
sense
to
do
an
RTG
WGS.
C
That
you
should
see
is
a
positive
thing
for
your
drafts.
There's
there's,
actually
good
interest
in
lily
and
I
are
being
very
careful
to
make
sure
Ellie
and
Russ
and
I
are
very
careful
to
make
sure
your
drafts
are
finding
a
good
place
because
we
are
hearing
interest.
So
you
should
hear
that
as
a
positive.
C
Thank
You
Russ,
okay,
the
next
part
of
this
working
group
is
really
a
working
session.
So
for
those
people
who
raise
your
hand
come
up
to
the
front,
we're
going
to
sit
down
and
talk
about
the
ephemeral
datastore,
the
rest
of
you
are
welcome,
but
this
is
really
this
session
and
we
may
schedule
another
session
on
Thursday
as
a
working
session.
So
if
you
raise
your
hand
and
come
up
toward
the
front,
we'll
just
sit
and
start
working
on
this
ephemeral
datastore,
they.
C
P
C
This
basic
by
the
way
jörgen
just
so
I,
say
thank
you
you're
one
of
the
authors.
Thank
you
very
much
for
the
care.
You
did
your
normal
excellent
work
here,
along
with
Kent.
Thank
you.
You
just
did
a
fabulous
job
with
this
stuff.
Okay,
folks,
in
this
revised
data
store
and
Kent
can
help
us.
This
is
a
basic
model.
You
know
we
could
take
off
example,
ITF
a
femoral
model
and
just
simply
put
weight
first,
let
me
take
a
step
back.
C
I
C
Q
So
the
draft
says
anything
is
written
to
the
dynamic
data
store
is
ephemeral,
it
doesn't
doesn't
the
draft
preclude
you
having
a
data
model
where
you
can
write
entries
in
the
data
model
through
the
dynamic
datastore
and
those
are
ephemeral
and
in
theory
you
could
configure
entries
in
that
same
data
model
through
conventional
data
stores
and
those
would
be
persistent.
Let's.
C
Go
with
the
simple
case,
we're
just
gonna,
say
there
cinnamons
and
stop
I
had
to
raise
the
issue
by
question,
so
we're
only
gonna.
Consider
again,
thank
you
for
the
question.
It
was
excellent
in
email.
It
is
only
a
femoral
okay,
so
this
example
that
they
have,
we
could
say
ITF
a
femoral
is
ephemeral.
Whatever
the
appropriate
thing
is
probably
it
since
it's
ITF
it
should
start.
We
can
go
with
the
namespace.
We
can
give
a
list,
we
can
import
the
data
store,
we
can
import
the
origin.
C
C
C
C
I
G
I
A
I
Second,
to
last
or
second,
to
top
line,
I
think
those
they
config
false,
affirm
all
true,
yes,
so
so
the
that
okay.
So
at
the
time
that
this
was
written,
that's
what
we
thought,
but
then
in
the
interim
we
came
out
the
yang
library,
biz
document,
and
if
you
look
at
that,
there's
basically
a
list
of
modules
which
could
include
standard
configuration
modules
and
also
I
trust,
modulus
e
like
and
then
or
okay,
and
then
there's
a
missile
module
sets
and
then.
I
Lastly,
a
list
of
data
stores,
the
data
source
would
be
things
like
running
candidate
and
then
potentially
ephemeral,
I
traverse
ephemeral.
Each
of
those
data
source,
then
I
have
a
pointer
into
which
module
sets
they're
using
which,
of
course,
then
are
which
models
are
using.
So
what
this
means
is
you
we?
You
can
have
a
module
and
a
server
could
say:
I
only
implement
it
inside
the
ephemeral
data
store
and
no,
it
might
be
very
useful
right
and
then,
of
course,
then
that
means
that
config
true
nodes.
C
I
Q
C
C
R
A
C
Now,
right
now,
the
girl
working
group
is
something
doing
something
very
like
it
in
in
what
wouldn't
call
not
with
all
the
net
lot
stuff,
because
I
can't
do
it,
they
want
to
its
stall
out
and
then
they
want
to
be
able
to
read
it
back
to
make
sure
they
got
there
and
it's
in
their
definition,
that's
dynamic.
It
goes
away.
So
that's
an
example
of
working
you've
doing
it
in
a
less
than
optimum.
R
R
A
A
A
A
Q
A
R
That's
ok
and
I
think
I
think
I'm
the
option
of
having
some
coffee,
true
stuff,
that's
only
applicable
to
iOS
I.
Think!
That's!
Ok!
It's
more
the
question
of
semantically
lots
of
configuration
states,
it's
all
a
bit
woolly
anyway,
but
I
think
the
yang
confit
trees.
What
people
think
was
configuration
of
in
Forsyth,
Sun
isn't,
and
it's
just
trying
to
get
that
balance.
Is.
Is
this
stuff
that
it's
really
just
state?
R
C
We'll
use
BGP
and
we'll
use
the
LSP
example,
the
BJP
an
example
where
you
would
write
over
something
everyone,
who's
done.
That
is
usually
found
a
place
where
it
went
bump
in
the
night
and
caused
a
bad
problem.
Okay
and
then
I
mean
there
are
many
things
like
easy
to
do,
that
that
are
not
configuration
that
people
have
tried
and
every
time
I've
heard
of
that
I've
usually
heard
of
a
a
major
incident
caused
by
it.
So
bad
ideas
just
stop.
C
D
P
C
Q
A
A
C
That's
not
that's
not
our
desire,
yeah.
If
we
said
that
in
the
past
you
sent
us
home
with
that
question
and
we
went
and
did
a
lot
of
discussions
and
decided
nope,
that's
not
a
constraint.
We
have
to
have
to
work
on.
So,
if
you
hurt
me
or
someone
else
say
that
your
questions
really
got
us
to
dig
and
say
nope,
wherever
people
use
our
models,
these
are
models.
Then
they
gotta
define
their
data
stores
and
define
what
they
want.
We've
got
two
basic
models
ribbon
topology.
A
A
E
You're
not
going
to
rewrite
the
Mack
header
from
I
to
RS.
You
might
rewrite
the
next.
You
might
rewrite
the
route
itself
right,
but
the
primary
tree
is
going
to
be
config
true,
but
there
may
be
some
individual
leaf
here
and
there
that
simply
it's
local
state
there's
no
way
for
a
controller
to
know
what
that
local
state
would
look
like
and
there's
no
reason
for
that.
Yeah
there's
no
reason
for
the
loop
ever
if
the
control
over
writes
it
you're,
probably
not
doing
a
good
thing.
C
C
C
Q
So
one
thing
that
came
up
during
the
I
guess
the
routing
working
group
and
I-
think
I
sent
an
email
to
you
on
the
working
list
was:
was
the
assumption
I
think
that
when
we
make
config
true
nodes
in
a
model
that
does
that
necessarily
mean
they're
accessible
through
conventional
data
stores?
So
I
guess
I
responded
to
your
statement
about
that
from
your
slides
and
I
guess.
My
my
thinking
was
that
just
because
you
have
a
data
model
with
config,
true
doesn't
necessarily
mean
it's
accessible
through
conventional
data
stores.
Q
Coming
back
to
what
kent
said,
we
can
say
this
model
is
only
accessible
through
this
data
store.
This
model
is
only
to
supposed
to
this
day
of
store.
We
can
have
models
in
a
router
that
are
testable
through
some
data
stores
and
not
in
others,
so
the
ITRs
model
may
only
be
accessible
through
the
dynamic
data
store.
So.
I
Trying
to
address
that
model
through
a
conventional
data
store
you
get.
So
this
goes
back
the
decision
with
the
idiom,
but
assuming
that
we
go
that
you
know,
I
tress
models
are
with
standard
config.
True,
then,
if
you
really
wanted
it
only
to
be
available
in
a
dynamic
or
ephemeral
datastore,
then
the
RFC
itself
could
say
so
in
text
or
the
yang
module
might
be
able
to
say
so
in
text,
or
we
might
be
able
to
define
a
new
yang
statement
of
some
sort.
That
kind
of
explicitly
states
it
but
I'm,
not
sure.
S
Q
I
Don't
want
to
restrict
it
or
or
imply
that
a
plus
P
right
so
back
to
that
I
mean
I.
Don't
have
read
the
rib
draft
myself,
but
in
the
topology
draft
I
remember
it's
not
intended
to
only
be
in
the
dynamic
discs
or
it
actually
was
intended
to
be
configured
standard
and
because
you
want
your
overlay
is
to
survive
reconfiguration.
I
This
is
why
we
came
up
with
that
whole
thing,
with
the
leaf
Roth
being
required
and
since
false,
so
that
you
know
if
it's
referring
to
something
and
it's
not
the
can't
the
references
and
resolved
inside
configuration,
then
the
system,
if
it's
valid,
convicted,
valid
configuration.
But
then
the
system
can
go
ahead
and
see.
Well,
can
I
resolve
this
leaf
wrapped
inside
operational
state,
and
if
so,
then
the
overlay
becomes
active.
D
R
I
still
think
that
I
think
on
the
same
page,
roughly
that
that
when
you
write
a
model,
you
write
conflict
true
in
there.
That
means
that
you
could
take
this
model
and
use
it
on
collection
of
configuration.
It
may
be
the
author's
intent
to
say
this
doesn't
make
much
sense,
and
you
might
put
a
comment
in
the
model
say
it's
designed
to
use
B
to
be
using
i2s,
but
actually
just
by
it
being
conflict.
True,
that
does
say
that
something
could
take
this
model
if
they
wanted
to
and
try
and
use
it
through
informational
datastore.
C
And
we
find
the
case
what
we've
been
hearing
from
people
is,
for
example,
AC
provided
an
extended
rib.
There
are
t,
WG
and
Elise
said
to
him.
Why
don't
you
look
at
our
to
s?
You
said,
but
that's
a
femoral
only,
and
we
said
no,
that's
a
data
model.
Yes,
you
install
it
in
the
datastore.
You
want
it
to
be
in.
If
you
want
it
to
go
in
the
config,
because
it's
got
some
really
valid
things,
then
you
need
to
make
sure
it
works
in
the
config
that
in
the
yang
doctors
you
might
want
to.
C
R
G
T
We
certainly
do
not
expect
that
all
boxes
will
so
from
our
perspective,
in
terms
of
the
current
work,
we
have
to
treat
it
as,
if
you're
supporting
this
because
you're
supporting
it
here
now
in
principle,
you
could
have
a
box
that
only
supported
it
somewhere
else
only
supported
in
the
conventional,
but
we're
not
trying
to
solve
that.
But
we
would
want
to
have
the
situation
because
we
wrote
it
for
a
femoral.
That
boxes
who
are
supporting
the
model
were
required
to
support
it
for
config.
R
C
S
Q
Question
I
had
based
on
the
new
data
stores
draft,
so
we've
defined
a
new
edit
data
RPC.
So
this
this
the
RHIB
model,
for
example,
has
our
pcs
defined
for
adding
and
removing
things
I.
Don't
think
the
topology
draft
has
that.
So
if
I
go
to
the
the
RHIB
model,
you
could
use
our
pcs
to
add
and
remove
them.
But
I
guess
it's
a
question
for
the
community.
Are
we
also
intend
to
use
edit
data
with
a
target
of
our
ephemeral
or
des
ephemeral
to
write
to
those
data
models
or
just
the
our
pcs?
C
S
Q
C
Q
G
C
Q
Obviously,
you'll
be
able
to
query
this
data
model
from
the
operational
data
store
and
that'll.
Give
you
the
operational
view
of
everything
in
that
data
tree
a
config
true
and
the
config
false
notes
for
the
config.
True
nodes:
are
you
expecting
to
be
able
to
do
an
I
get
data
from
the
or
from
the
DSF
emeral
data
store,
I'm,
not
I'm,
not
sure.
Q
If
there's
a
reason,
I
don't
know
the
protocol
well
enough
to
know
if
what
you
write
to
the
dynamic
data
store,
I
know,
but
what
what
you
writes
the
ephemeral
to
the
ephemeral
data
store?
Is
there
some
reason
I
wouldn't
exactly
get
translated
to
the
operational
or
the
other
things
I
could
overwrite
it
or
something?
Well.
T
I
mean
there
should
be
no
lag
between
the
operational.
The
only
the
only
concern
I
have
is
the
view
that
you
need
to
be
able
to
get
out
all
of
the
pieces
of
data
as
long
as
you
can
get
out
all
of
them,
I
don't
think
it
causes
a
problem
for
us
if
the
reads
need
to
be
aimed
at
the
operational
data
store
instead
of
the
ephemeral
store,
make
the
co2
look
a
little
odd
to
some
people,
but
that's
a
perfectly
reasonable
thing.
T
Q
Q
T
Q
Yeah,
which
means
it'll
be
that
same
copy
very
shortly
in
the
operational
yeah,
then
there's
probably
not
a
strong
need
to
read
from
this
data
store
using
get
data
which
actually
kind
of
means
to
me.
You
have
our
pcs
too
right,
you're,
never
gonna
read
from
it,
I'm,
not
sure.
There's
a
data
store
there
well.
C
C
Q
I
So
I
thought
where
Jason
was
going
with
that
line
of
questioning
was
that
you
know
if
you're
going
to
do
get
data
on
the
DSS
ephemeral
data
store,
then
it'd
be
asymmetric.
If
you
aren't
also
able
to
do
the
Edit
data,
I
mean
there
may
be
our
pcs,
but
it'd
be
a
SPAD
I,
don't
think
you're
going
to
prevent
the
ability
for
edit
data
it's
going
to
be
possible.
The
RPC
is
are
just
an
optimization
and
but
then
I
have
question.
I
If
the
value
of
the
RPC
is
I
mean
it
seems
more
like
an
implementation
detail
that
could
be
optimized,
you
know
a
way,
hopefully
enough,
maybe
not
enough
I'm,
not
the
expert
here
with
your
your
performance
requirements,
but
I
mean
it'd,
be
unfortunate.
If
towards
me
to
define
the
RPC
to
get
that
last
microsecond
of
performance.
A
I
Q
O
Because
I
have
to
do
the
RPC
and
then
go
ahead
and
create
the
thing
in
the
ephemeral
database
I'm,
not
really
optimizing.
You
know
I
actually
have
to
do
more
work
because
now
I
have
to
tell
it
as
I'm,
making
the
operational
database.
Don't
let
that
in
fact
impact
the
demons
who
would
traditionally
look
at
the
ephemeral
database.
So
it's
it's
a
it's.
C
U
So
one
thing
that
you
have
to
be
aware
of:
if
you
write
an
RPC
and
you're
hardwired
it
to
a
specific
data,
store,
it's
hot'
by
it
with
specific
data
store
right
by
doing
that,
you
won't
be
able
to
use
the
same
module
to
implement
it
and
conventional
data
store
whatever,
because
the
RPC
is
hardwired
to
modify
a
specific
dynamic
data
store
right.
So
if
you
look
at
any
data,
it
passes
the
data
store
as
part
of
a
parameter
into
it.
So
you
don't
have
that
mechanism
that.
S
Q
If
we
ever
wanted
the
our
pcs
to
be
used
in
other
data
stores,
I
mean
someone
could
also
augment
them
to
add
a
target
in
theory
group.
If
we
wanted
to
change
it
to
be
able
to
use
another
resource,
but
if
you're,
if
you're
doing
this
stuff
through
conventional
data
stores,
are
probably
not
looking
for
the
high
speed,
optimization
anyways,
why.
R
K
Q
I
I
think
the
recommendation
would
be
to
not
define
the
are
pcs
in
the
base
rib
model,
but
to
allow
those
to
be
defined
in
another
model.
You
know
another
RFC,
actually,
that
you
know
potentially
augments
the
model
yeah
yeah,
so
so
the
traditional
edit
config
or
sorry
edit
data
and
get
data
would
work,
maybe
not
the
highest
performance,
but
for
you
know
it
would
probably
get
you
off
the
ground
and
satisfy
most
these
cases
and
then,
with
experience
from
discovered,
our
proceeds
are
faster.
You
know
we
certainly
could
augment
them
in.
C
Q
C
I
I'm
King
Arthur
urines
comment
where,
if
you,
the
RPC
would
be
locked
down
to
specific
data
store,
presumably-
and
you
know
that's
unfortunate,
because
people
may
want
to
move
around
to
other
data
stores.
So
if
the
base
model
did
not
define
that
our
PCs
and
the
flexibility
to
move
around
would
be
there,
but
then
the
other
you
know,
but
then
the
other
model
module
of
either
but
that's
optional.
To
implement
and
of
course,
we
be
targeted
specifically
to
your.
P
C
I
Maybe
before
we
move
to
your
next
topic,
I
just
wanted
to
sort
of
live,
Joel
was
talking
about
the
priorities
and
one
one
dynamic
or
one
or
thermo
data
store,
I
mean
I.
Think
the
implementation
details
for
how
this
is
going
to
be
done
are
still
in
play
and,
in
my
mind,
or
at
least
the
way
I
was
thinking
about
it.
There
might
truly
be
a
data
store
called
des
ephemeral.
Yes,.
E
T
Tourist
documents
say
you
don't
remember
it,
it
doesn't
come
back
if
you
want
to
store
it
somewhere
for
information,
that's
fine
and
the
device
can
store
anything
it
wants
to
know,
but
the
important
property
is
the
current
property
that
the
application
can
know
about.
Is
this
is
what's
there
if
my
thing
too
gets
overwritten
I
get
an
error
and
I
don't
have
to
worry
about
whether
my
thing
will
reappear
by
magic
at
some
later
point
in
time
it's
gone
so
there's
no.
If,
as
far
as
I
torus
application
to
what
is
in
operation.
K
C
A
C
I
know
the
reason
I
went
to
this
slide
was
actually
that
very
question.
No,
no
Kent!
You
might
want
to
stay
there.
The
you
just
the
the
the
it's
a
fairly
easy
when
I
said
we
had
to
discuss
edit
collision
and
II
did
a
fairly
good
job
of
describing
in
the
Attic
collision,
because
this
is
what
we're
doing
we're
having
edit
collisions
right,
Ren
and
II
called
it
said
on
the
stuff
cause
of
etic
envisions.
The
entity
tag
is
used
to
handle
edit
confusions.
C
The
only
thing
that's
different
with
our
two
S's
requirements
is:
if
you
have
a
collision
and
you
lose,
you
have
to
send
an
event.
It's
it
I,
don't
know
how
to
express
that
in
a
datastore,
but
that's
part
of
the.
What
do
we
do
to
design?
It
is
really
for
rest
comp,
edit
condition
I
figured
if
we
could
get
the
rest
conf
now,
so
this
entity
tag
can
be
broken
up
between
client
ID
and
priority
or
client
reference.
Id
I
mean
Andy.
Did
you
guys
thought
carefully
about
that?
So
that's
why
this
is
here.
C
F
I
Here
is
the
subset
of
the
diagram
ephemeral,
sorry
they'll
provide
safes
or
draft,
and
in
there
it
has
an
error
says:
dynamic
disorders
can
feed
into
operational
and
and
so
then
you
know
you
would.
Might
you
think
that
it
would
just
be
one
dynamic?
They
swear,
I
trust
would
define
but
I'm
proposing
as
an
intimate
I'm.
Not
you
know
as
an
implementation
detail,
you
might
actually
define.
I
Let's
say
you
have
eight
panes
of
glass
so
define
nine
data
stores,
eight
of
them
being
the
specific
one
for
you
painting
class,
one
of
them
being
your
resolution
area
right.
So
so
then
you
would
say
okay,
so
you
know.
However,
you
want
to
do
it.
Use
versa
priorities
they're
actually
interacting
with
these
guys,
but
then
behind
the
scenes.
There's
logic
that
does
the
distillation
and
then
that
gives
us
what's
the
inherent
operational.
F
T
Point
I
was
making
is
I,
don't
care
if
you
store
it
in
nine
different
data
stores
or
four
hundred
different
data
stores,
but
if
a
rights,
the
stuff
and
get
success
and
then
be
rights,
the
stuff
and
get
success
and
there's
a
collision
and
a
gets
told,
your
stuff
is
gone
when
B
goes
and
deletes
his
stuff,
a
stuff,
better,
not
reappear,
don't
reinstall!
Now,
normally,
if
I
see
any
of
those,
it
looks
to
me
like
they're
gonna
intend
to
cause
me
installation.
I
T
C
Q
P
J
I
The
only
reason
I'm
proposing
that
you
might
be
the
writing
to
the
1,
2
or
3
is
because
otherwise
you'd
have
to
introduce
extensions
to
rest
cough
or
you
know.
How
do
you
specify
the
priorities?
There
would
be
some
extension,
but
it
right,
but
if
you
map
priorities
on
today's
tours,
then
you
kind
of
get
it
for
free
with
the
existing
protocols
and
that's
the
reason
why
I'm
suggesting.
C
C
You
know
if
the
clients
different
you
prepare
on
the
priority
bits
if
the
clients
the
same
you
stay,
you
know
if
the
priority
bits
are
the
high
order.
You
can
do
the
comparison
that
that
was
the
discussion
with
Andy
and
in
the
creation
of
the
entity.
Tag
is
if
you're
encoding
that
you
can
encode
it
in
a
way
that
the
priority
it's.
T
Actually,
even
better
than
that,
if
you
but
the
priority
in
the
high
order
bits,
you
just
compare
the
two
things
and
the
entity
tells
the
real
edit.
You
can't
just
serves
as
the
tiebreaker,
because
he
observed
that
if
you
really
just
make
these
unique
and
you
don't
have
a
collision,
you
don't
have
to
worry
about
what.
If
two
things
have
the
same
prayer
effective
priority,
and
so
we
avoid
that,
and
the
point
is
I:
don't
want
to
require
that
people
be
writing
to
their
individual
data
stores,
that
that
would
be
really
a
painful
requirement.
I.
C
I
I
understand
your
proposal
and
this
might
be
workable,
I
think
with
within
the
context
of
the
ephemeral
data
store,
you
may
be
able
to
redefine
the
meaning
of
the
entity
tag,
but
I
just
want
to
share
with
you
that
it's
desirable
that
the
e-tag
value
for
say
running.
If
you
only
if
your
system
only
supports
running
and
it
gets
committed
to
operational,
the
e-tag
value
for
running
an
operational
would
hopefully
be
the
same.
So
a
client
could
very
quickly
look
of
a
single
comparison
of
ETA
comparison.
See
that
actually
you
know
my
system
is
completely.
T
Would
expect
at
least
in
most
cases,
I
want
to
where
there's
not
a
corner
case
that
they
see
tag
that
was
used
on
the
dist
on
a
dynamic
data
store
would
be
the
one
you
would
see
in
the
operational.
The
fact
that
operational
doesn't
worry
about
collision
resolution
doesn't
cause
us
any
problem
with
saying,
but
you
can't
use
that
e
tag.
You
can
still
use
that
e
tag.
R
I
I
R
My
poem
is
actually
different,
I
think
in
some
of
the
I
terrace
drafts,
I've
read
about
how
you
look
at
the
dynamic
configuration
through
dynamic
and
it
compares
to
the
stuff
coming
through,
attended
and
has
some
sort
priority
resolution
between
those
two.
Is
that
still
intended?
So
so
my
question
is
how
how
is
that
going
to
be
handled.
T
Well,
I
can't
tell
how
it
will
be
handled,
but
I
know
what
the
last
time
I
was
working
closely
on
that
question.
You'd
have
a
configured
value,
not
an
ephemeral
value.
That
was
the
effective
priority
of
the
config
store,
and
so
you
have
essentially
a
priority
string.
That
applies
to
that,
and
so
you
then
compare
the
priorities
across
those
two.
T
T
Okay,
because
I'm,
not
a
young
person,
I
cheated
I
said
it
should
look
and
it
doesn't.
It
can
find
the
the
real
data
under
the
covers,
because
if
it's
already
existing
in
dynamic,
then
it
doesn't
have
to
look
at
static.
Because
if
the
new
cling,
the
dynamic
thing,
then
byte
under
dynamic
thing
beat
config.
Then
transitivity
saves
money
by
Lac.
But
if
there's
nothing
in
dynamic,
then
you
have
to
check
that
you're
actually
allowed
to
override
config.
C
B
V
E
Even
you
could
have
a
BGP
route
learn
and
then
you
use
I
to
RS
to
install
a
route
in
the
ribs
that
ever
rides
the
BGP
route
or
you
could
actually
do
it.
The
other
way
around
you
want
to
be
able
to
do
it.
The
other
way
around,
which
is
you
want
to
be
able
to
have
the
BGP
route
override
unless
the
BGP
route
goes
away.
For
some
reason,.
N
Yes,
but
that
examples-
a
rib
example
where
basically
I
tore
us
the
information
compliment,
dynamic
data
store
is
the
equivalent
of
a
protocol.
Routing
protocol,
in
terms
of
it,
has
an
admin,
preference
and
competes
in
the
rib
for
what
gets
installed,
based
on
the
admin
preference
not
based
on
any
right.
That's
a
local
admin,
preference
kind
of
thing.
E
C
E
R
T
W
Q
This
resolution
happens
and
what
data
stores
you
see
the
various
information
so
I
assume
I
assume
that
whatever
is
written
to
the
iOS
protocol,
you're
gonna
see
if
you
do
a
get
data
on
the
on
the
DS
ephemeral,
even
if
in-
and
this
goes
back
to
my
question
earlier,
even
though
that
entry
may
not
make
it
into
operational
because
config
overrode
it
or
okay.
So
then,
going
back
to
that,
we
definitely
need
to
be
able
to
read
the
the
des
ephemeral
because
you
may
get
a
different
value
in
there.
Then
you
read
from
operational.
C
C
Is
it
is
this?
Where
do
we
define
this
different
split?
Is
that
in
the
data
store?
Is
that
in
the
addition
to
restaurant
there's
a
very
simple
answer,
but
I
couldn't
quite
figure
out
where
you'd
say
and
our
normal
standardized
split
between
these
is
this,
or
does
it
need
to
be
flexible
for
customers?
C
C
J
C
Static
give
a
table
that
is
either
statically
configured
or
updated
through
something
like
radius,
because
that's
secure
from
some
server,
but
it's
free
off.
It's
pre
setup,
it's
a
priori,
and
so
you
know
client
ID
the
priority
you
could
simply
have
client
and
priority,
but
in
case
your
client
changes
the
priority
in
the
middle.
That
would
this
is
my
proposal.
C
This
is
Joel
and
I
have
debated
whether
you
just
need
a
client,
the
idea
where
you
need
a
priority,
but
we
need
to
have
that
discussion,
make
a
decision
and
go
on
but
see
if
your
client,
if
you
have
a
client,
ID,
and
it
always
has
the
same
priority,
then
you
just
keep
the
client.
The
question
is:
if
something
dynamically
comes
in
and
changes
it,
what
do
you
do
about
the
decision?
Joel
says:
oh
well,
the
next
time
someone
comes
in,
you
have
a
different
priority:
I'm,
not
as
happy
with
that
I
like
story
well,.
T
The
only
the
part
I
like
actually
being
explicit
about
the
priority
and
the
client
ID,
even
though
I
think
the
priority
is
stable
for
any
given
client,
because
the
prior
that
lets
us
use
some
nice
clean
value
for
client
ID.
That
is
not
necessarily
tied
to
the
assigned
priority
which
changes.
If
I
have
a
client,
it's
got
the
same
ID
all
the
time.
If
the
radius
tells
me
what
priority
it
has
and
the
server
checks
is
he
using
this
priority,
he's
allowed
to
use
if
he
does
something
with
a
priority
he's
not
allowed
to
use?
C
Back
to
the
datastore
definition,
this
is
the
entity
tag,
we're
just
that
the
cleanest
way
seemed
to
be
split,
the
entity,
tag
into
two
fields
and
say
for
our
chests:
it's
going
to
have
these
two
fields
or
anyone's
client,
their
number
integer
fields
or
something
where
would
you
put
that
if
we
have
it
first
of
all,
does
it
sound
reasonable
and,
second
of
all,
where
would
we
define
it?
Is
it
in
restaurant
visit
in
the
datastore.
I
C
I
No,
what
I'm,
trying
to
say,
though,
is
let's
say:
there's
an
e-tag
value.
The
data
has
been
written
by
one
client
and
I
need
to
eat
tag.
Value
is
calculated
using
your
approach
and
then,
let's
say
another,
the
system
reboots.
So
it's
all
this
wiped
clean
and
another
client
comes
in
a
different
priority
and
they
write
the
exact
same
data
in
in
your
approach.
I'd
be
a
different
etag
but
I'm
thinking
that
it's
actually
the
same
state.
It's
the
same
data
therefore
I,
wouldn't
think
that
maybe
I'd
be
the
same.
He
tagged.
So
that's.
T
Not
what
he's
asking
he
says
if
two
different
clients
client
a
wrote
it
at
time.
One,
it's
got
me
tag
claim
they
went
away.
He
died.
Client
B
came
back
and
tried
to
write
it.
The
exact
same
data,
in
fact
either
client
B
has
a
higher
priority
or
he
has
a
lower
priority
if
he
has
a
lower
priority.
Even
though
he's
not
changing
any
of
the
data,
he'll
actually
get
an
error.
T
If
he
has
a
higher
priority,
he
is
replacing
it
with
the
same
content,
but
it
gets
his
e
tag
because
that's
now
actually
conceptually
the
data's
change
it
now
has
this
priority
associated
with
it.
So
I
think
it's
reasonable
to
view
it
as
it's
not
actually
the
same
data,
even
if
all
of
the
fields
look
the
same
so
I
think
it's
a
reasonable
access.
It's
bending
the
etags
but
I
think
it's
a
reasonable
stretch.
I
E
U
U
X
T
Not
just
with
the
merger
between
the
ephemeral
clients,
so
you
have
to
associate
the
priority
with
the
data
in
the
ephemeral
data
store.
Somehow,
and
we
said
we
want
to
associate
the
client
ID
with
the
data
in
the
ephemeral
store
for
traceability.
So
this
is
the
suggestion
that
we
were
given
was
to
use
the
e
tag.
If
you
want
to
give
us
a
different
suggestion,
I
don't
think
anybody
is
hung
up.
A
R
Anton's
on
the
crystal
dating
thing
should
go
in
the
data
stores,
architecture
draft,
because
I
think
this
is
specific
to
ITRs
and
not
dynamic.
Data
stores
in
general
are
down
about.
The
protocol
updates
is
a
different
question,
but
one
thing
on
the
e-tag
that
I'm
still
confused
about
is
that
if
the
each
item
interfere
so
effectively
almost
like
a
hash,
what
current
data
is
then
I
think
you
might
not
have
enough
information.
You
take
your
generating
here,
because
it's
not
going
to
represent
a
hash
of
given
subtree
of
everything.
R
U
L
U
C
R
I
I
A
A
I
Saying
check
into
it,
I
would
say
you
know,
let's
verify
with
HP
RFC
the
definition
of
e
tag,
and
what
does
it
really
mean?
It's
or
you
know,
does
it
have
a
wiggle
room
in
it
just
make
sure
we're
not
violating
it
anyway
and
and
if
we're
not,
then
I
think
you'd
be
okay
to
continue.
It
might
be
difficult
from
implementations
perspective
right
because
a
generic
ruskov
server.
I
C
R
R
T
R
T
Would
actually
like
the
fact
that
oh
you're
going
to
see
the
same
priority
from
the
last
guy
who
won
now
there's
a
little
weirdness.
We
may
not
see
the
highest
priority.
It's
not
going
to
produce
the
right
result
in
any
case,
I,
don't
I
think
we
don't
care
how
it
ripples
up.
That's
because
it's
not
gonna
ripple
up
right,
no
matter
what
we
do.
Rippling
up,
you're
gonna
have
to
check
all
the
subfields.
I
I
I
T
Took
yes,
this
has
to
get
answered,
but
I
think
that
is
not
going
to
break
whether
this
works
for
this
or
not,
because
if
it
ripples
up
it
ripples
up,
so
there
is
a
value
that
is
well
defined,
so
you
know
what
you're
getting,
but
that's
not
the
value.
That's
used
for
the
comparison
to
check
the
things
it
will
know.
It
will
almost
never
tell
somebody
the
right
thing
that
they
want
to
know
about.
Is
this
whole
datastore
still
the
same,
but.
R
Divergent
think
I
just
think
you
back
to
you
saying
where
to
do.
Where
does
this
get
written
to
whatever
the
answer
is
I
say
not
the
data
source
draft,
because
it's
dynamic
actually
everyone's
the
reason
I
think
probably
not
the
rest.
Cough
updates
an
NDA,
because
we
want
out
to
progress
quickly
because
we.