►
From YouTube: IETF103-NETCONF-20181105-0900
Description
NETCONF meeting session at IETF103
2018/11/05 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
A
Your
taking
seat
near
the
mic,
so
you
can
watch
the
jabber
room
for
any
comments
or
questions
while
you're
up
here
use
the
box
around
the
mic
and
stay
in
there,
while
you're
speaking,
the
blue
sheets
have
been
handed
out,
I
see
on
this
side,
it's
sitting
on
the
front
row.
So
someone
if
can
pick
that
up
and
pass
it
down
that
aisle.
A
If
you
want
to
quickly
take
a
look
at
it
and
paste
it
into
your
browser,
either
bad
tools
that
idea
that
are
slash,
notes,
/,
ITF,
103,
Netcom
I'll.
Give
you
guys
a
few
seconds.
If
you
want
to
bring
up
the
ether
pad,
we
would
appreciate
you
adding
comments
or
Corrections
into
the
ether
pad.
As
you
see,
people
speaking
will
use
the
minutes
recorded
in
the
user
pad
and,
of
course,
validate
them
with
the
audio
stream
or
any
actions
that
are
taken
in
the
working
group
before
you
proceed
in
full
disclosure.
A
B
C
B
B
We
are,
of
course,
there's
the
closing
the
window,
the
submission
deadline
window,
which
has
just
reopened
and
some
final
dotting
of
the
I's
and
crossing
the
t's
hey
to
occur,
but
for
the
most
part,
they're
moving
out
of
the
working
group
to
Shepherd
right
up
state
and
I
I,
it
will
be
the
designee
designated
Shepherd
unless
someone
else
would
like
to
volunteer
to
be
Shepherd.
The
only
reason
that
you
that
someone
wouldn't
maybe
like
to
do
this
would
be
because
for
myself
it
probably
incur
some
delay.
B
C
This
is
because
the
documents
seem
to
be
mostly
ready,
and
it's
understandable
that
you
have
many
things
on
your
plate,
so
we
might
even
have
some
with
you
who
is
rather
new
to
this
process
and
kind
of
try
to
train
them
into
that.
So,
if
somebody
is
interested
in
that,
please
please
raise
please.
You
put
your
name.
B
B
Okay
and
then
also
there's
a
you
to
keep
up
channel,
also
a
working
group
document,
then
there's
the
yang
push
notification,
capabilities,
draft
and
also
another
draft
notification,
headers
and
bundles
draft.
Both
of
these
are
works
in
progress,
but
neither
are
being
presented
today,
primarily
because
the
authors
are
the
same
authors
working
on
the
yang
push
set
of
drafts
and
they
wanted
to
focus
their
attention
on
those
drafts
rather
than
these
other
working
group
documents.
B
Okay
from
the
agenda
perspective,
first
they'll
be
the
prison
presenting
presentation
of
the
client-server
drafts,
followed
by
the
gang
push
set
of
drafts,
followed
by
the
you
to
be
public,
pub/sub
draft
and
then
a
couple
non-cluttered
drafts
which
would
be
subscription
to
multiple
stream
or
originators
and
the
in
line
action
capability
for
Netcom
and
then
other
area.
Business
I
should
say
that
we
have
plenty
of
time.
B
This
schedule
I
think
with
two
hours
on
the
schedule,
but
from
the
amount
of
time
that
the
authors
were
requesting,
we
may
have
50
minutes
remaining
so
lots
of
time
for
discussion
and
if
anyone
else
wants
to
you
know
to
bring
up
something.
That's
not
on
the
agenda.
There's
plenty
of
time
for
that
as
well.
B
Okay,
hi
Kent,
presenting
the
client-server
graphs
since
I
102
in
Montreal.
All
the
drafts
were
updated
and
submitted
at
a
set
twice
most
of
the
issues
that
we
discuss
in
Montreal
have
now
been
resolved
and
a
few
extra
issues
were
made
as
well.
There
are
two
remaining
issues
from
that.
We
discussed
in
ITF
one
or
two
one
being
wanted
with
that,
which
was
called,
should
algorithm
identities,
be
moved
from
the
IETF,
SSH,
client,
TLS,
common
crypto
type
modules,
sorry
modules
to
the
crypto
type
module
and
the
other
being
add.
B
B
All
right.
So,
first
we'll
just
begin
discussing
the
first
item
you
know,
should
algorithm
identities
be
moved
from
the
SSH
TLS
common
module
to
the
crypto
types
module
for
this
issue.
You
might
recall
we
reached
out
to
sag
in
the
security
group
several
times
requesting
health
cryptology
experts
to
help
us
with
this
particular
item
and
last
time
we
were
fortunate
enough
to
have
some
individuals
from
Huawei
volunteer
to
help
us
with
this.
B
D
D
So
from
my
side,
I
have
updated
as
recharge.
The
the
basic
way
is
the
crypto
type
straps.
It
includes
several
categories
of
the
basic,
oh
cripton,
great
accordance
and
between
used
for
other
applications
for
infinite
comp
country.
We
used,
we
apply
the
physical,
a
Korean
on
the
net
console
based
on
the
SSH
and
the
net
net
convict
or
TRS
okay.
So
this
has
a
street
rafter.
We
are
updated.
We
are
updated,
okay,
so
so,
firstly,
the
crypto
type
traps
like
I
just
mentioned.
We,
we
reference
a
lot
of
existing
and
very
widely
used.
D
Applications
such
as
IPSec
and
a
key
version
2
and
the
T
is
1.2
pantry
and
ssh.
We
do
our
sorrow
story
and
analysis
of
this
draft
and
abstract
of
the
widely
used
crypto
evidence
and
also
very
important.
They
are
also
very
safe,
safe
algorithms,
and
we
try
to
divide
them
into
six
categories.
So
there
you
can
see
Oh.
D
Okay,
you
can
see
the
first
one
is
hush,
Aryan,
okay,
the
second
is
the
symmetric
second
symmetric
encryption
algorithm
and
the
Mac
algorithm
and
the
asymmetric
encryption
algorithm
and
the
signature
and
the
key
keeps
changing
okie
negotiation.
So
our
basic
idea
is
that
we
want
these
categories
to
be
atomic
and
cover
most
also
widely
used
basic
algorithm
and
then
can
combine
together.
Where
is
really
for
not
only
from
that
conf,
we
think
that
in
future
they
can
also
be
used
by
other
applications.
So
so
you
can,
you
can
go.
D
D
D
Identify
a
public
key
pair
and
the
certificate
how
to
define
there.
They
are
ever
even
type
for
the
public
key
pair
and
an
eSATA
Kate.
Usually
it
should
be
a
combination
of
equip
ssin
and
the
signature
right
like
what
we
always
say,
the
I
say:
Michael
didn't
or
the
ECC
so
but
can
read.
You
can
see.
We
already
divided
the
other
algorithm
into
very,
very
atomic,
very
specific
or
categories.
So
so
I
say
it's
not.
D
It
should
be
as
it
should
be,
a
combination
of
the
some
of
the
basic
algorithm.
So
we
are
still
not
not
decided
that
sorry,
we
haven't
decided
how
to
how
to
represent
the
public,
keep
here
algorithm
or
the
certification
arisen.
Of
course,
there
are
two
way:
Rama
is
a
fine
great
way.
We
can
use
our
existing
everything
combined
into
the
present
I
say
or
if
you
see
other
way,
maybe
we
can
just
very
simply
to
the
predator,
so
I
think
this
is
a
problem
we
still
need
to
solve
in
the
future
version.
D
So
if
you
can
help
us,
we
are
working.
Okay
and
after
finish,
you,
the
crypto
types
and
then
we
we
walked
up
based
on
those
crypto
types
and
and
and
those
crypto
types
provided
the
definition
of
the
possible
used
algorithms
by
the
visor
that
comes
over
SSH.
So
so
the
left
of
question
for
us
is
that
we
already
have
got
some
key
from
the
from
the
crypto
types
definition
and
we
also
need
to
define
the
algorithm
we
used
for
the
Netcom
for
over
SSH.
D
So
there
should
be
some
compatibility
relationship
between
the
between
the
Kiwi
we
used
from
the
crypto
types
and
the
definition
we
defined
here
in
the
SH
or
in
the
in
the
in
that
comes
over
SH,
just
so
to
the
Christ
to
clarify
this
relationship.
We
add
some
tables
to
to
justify
what,
if
the
writer
mapping
what
is
yeah,
what
is
a
great
matting?
The
left
isn't
the
draw?
Imagine
okay,
so
you
can
see
that
this
mappings
are
aware
is
a
very
straight
forward.
Actually,
the
left
of
the
left
side
is
crypto
types.
D
We
we
use
the
on
the
key,
and
the
right
side
is
that
we,
what
we
have
defied
in
the
in
the
SH
configuration,
so
they
should
have
be
compatible
so
kind
very
easily,
because
we,
because
you
can
you
can
you
can
see
that
the
s
that
comes
always
says
configuration
configure
every
atomic
algorithms
on
its
configuration.
So
there's
a
one-to-one
mapping
between
the
basic
core
crypto
types
to
the
current
SSH
configuration.
So
this
is
a
very
simple
example.
We
have
for
compatibility
tables.
D
This
is
about
the
Mac
symmetric
encryption
and
the
cheeks
changer
and
the
hash
area
and
signature
okay,
so
they
are
all
the
netting
they
should
be
compatible
with
each
other.
So,
following
the
same
idea
for
the
that
comes
over
here,
is
there
should
appear
this
kind
of
capability
existed
here.
So
we
also
do
the
analysis
on
the
TRS
1.2
and
the
TRS
1.3,
and
also
we
looked
over
all
the
tos
and
a
page,
it's
everything
and
a
page.
D
So
we
know
that
for
TRS
1.2
the
cipher
the
year
here
at
Stifel
feels
it's
a
most
important
part.
It
includes
all
the
all
the
cryptographic
mechanism,
which
is
used
over
TLS
1.2
and
the
fourth
tears
went
off
three.
There
are
three
categories
of
Crick:
grad
pre-classical
acquittance
fault
for
it,
which
is
tra
ciphers
used
here
as
signature
scheme
and
tears
upon
groups.
So,
based
on
this
survey,
we
decide
that.
D
Okay,
we
choose
all
these
three
categories
for
post
the
key
is
1.2
and
1.3,
but
what
is
1.2
only
the
fourth
one
or
which
is
the
ti-84
suits,
can
is
useful
for
constructor
the
competitive
mapping
between
the
key
and
the
key
is
the
configuration
ok
so
also
for
in
a
same
way,
with
the
filer
way.
We
define
the
humidity
a
community
mapping
table
independently
40
eyes
1.2
and
the
tea
is
one
two
three.
D
So
the
reason
why
we
have
so
many
tables
here
is
that,
because
you
know
kinda
ITF
chapter
has
the
limitation
of
the
80
or
82
right,
82
characters
in
one
line.
So
so
because
you
can
see
the
our
our
psychosis
is
too
long
or
too
long
stream.
So
we
we
can
only
divide
the
every
mapping
into
a
table,
so
there
are
five
tables
for
each
category
right
the
for
example.
This
is
the
hash
and
the
and
the
signe
and
the
signature
evidence.
It's
just
a
two
examples.
Also
we
have
the
equation.
E
D
B
Sorry
about
that
good
thing:
we
have
plenty
of
time
on
our
schedule.
Okay,
right,
so
back
to
this
you'll
see
the
back.
Button
works,
it's
no
good,
so
the
question
was:
should
algorithm
identities
be
moved
from
the
ITF
as
safety,
less
common
modules
to
the
crypto
technological?
The
answer
is
no
we're
going
to
leave
them
there.
B
Those
identities
are
going
to
be
defined
both
in
the
SSH
AMT
last
crypto
type
modules,
as
well
as
in
the
crypto
types
module
and
we've
created
these
compatibility
matrix
matrices
that
are
existing
in
the
Association
TLS
modules
to
allow
for
the
mappings
to
be
to
be
performed,
and
currently
those
matrices
are
only
implemented
in
texts.
There's
not
a
yang
module
level
definition
of
these
mappings
we're
actually
undecided
as
to
if
it's
even
possible,
to
create
yang
level
mappings.
How
would
we
do
it?
Maybe
some
very
complex
musts
expressions,
but
it's
unclear.
B
B
B
So
there's
one
reason
for
why
you
may
want
to
do
both
and
similarly
aliveness
checks
at
an
upper
layer
should
not
preclude
the
aliveness
checks
at
lower
layers
and
I.
Think
here,
Tim
Carey
was
mentioning
how
you
made
there
be
like
a
degradation
where
some
of
the
upper
layer
protocol
has
been
corrupted
or
disabled,
but
you
can
come
down
and
at
least
do
TCP
keeper
lives
and
see
whether
or
not
it's
it's
up
at
that
level.
So
the
question
that
we're
stuck
on
currently
is
how
to
configure
the
keep
allows
at
the
various
layers.
B
We
have
not
discussed
this
really
at
all
on
list
since
Montreal,
so
here
we
are
talking
about
it.
Okay,
so
I
have
an
idea,
but
you
may
not
like
it.
That's
my
disclaimer
independent
of
this
discussion
for
a
few
months
now,
I've
been
aware
of
gaps
in
our
current
solution,
specifically
that
we're
missing
the
dependent
or
some
dependent
protocol
layers.
B
I
showed
you
a
picture
of
the
draft
current
draft
relationships,
so
in
the
light
gray
in
the
background
is
that
picture,
though
parts
of
that
picture
are
in
black,
so
the
ssh,
client,
server
and
teals
client
server
or
the
restaurant
client
server
were
were
in
that
other
picture
as
well,
but
new
in
red,
green
and
blue
are
the
proposed
potentially
new
drafts
last
modules
that
we
could
add
to
complete
the
picture
all
right.
So
that's
the
idea.
B
What
are
the
benefits
well
first
factoring
out.
These
dependent
layers
would
provide
a
basis
for
future
protocol
models.
Surely
there
will
be
more
TCP
based
models
that
folks
in
the
IDF
will
want
to
define
so
actually
defining
that
IDF
layer
would
provide
a
placeholder
for
over
them
to
make
that
extension.
B
B
B
F
G
B
G
A
H
So
this
is
Tim,
Kari,
Nokia,
I
will
say,
I
think
you
know
the
approach
that
to
having
keep
a
lives
at
every
layer
and
makes
sense,
because
again,
last
time
we
talked
about
it,
it's
needed
for
that
piece
of
it
to
answer.
You
know
Jason's
question
as
well,
as
is
that
indeed,
this
is
within
the
context
of
the
net
comp
session.
H
You
know
from
the
TCP
that
supports
the
next
comp
session,
but
I
will
say
that,
as
we
were
doing
this
for
for
some
of
the
stuff
within
the
broadband
forum,
work
that
some
of
the
implementations
are
that
when
you
turn
this
on,
you
touch
those
TCP
q4
lives.
It's
actually
for
all
the
sessions
that
there's
some
limitations
and
some
of
the
implementations,
not
that
the
the
approach
still
should
be
the
con.
H
The
context
should
be
the
Netcom
session,
but
sometimes
the
implementation
says
that
the
only
the
only
thing
that
you
can
twiddle
the
bit
that
you
can
twiddle
is
on
me
all
the
all
the
sessions
just
on
some
of
the
implementations,
so
the
refactoring
might
concern
what
the
refactoring
is.
We've
got
modules
coming
up,
I
mean
there's
just
a
ton
of
modules
and
I
just
and
I
get
what
you're
doing
I
just
man
I,
don't
know.
You
know
I'm
saying
it's
just
there's
just
a
lot
of
modules.
H
B
F
F
Is
this
module
generic
enough
and
if
it
is
I
would
say
yes
displayed
it
out,
because
I
might
want
to
support
this
or
that
assistant
level
as
default
settings
for
also,
and
also
just
on
the
net
called
server
sessions,
and
so
that
the
net
con
server
would
use
the
socket
option
to
turn
this
on
for
just
its
sessions
and
I
would
also
like
in
ITF
systems
model.
You
know,
setting
for
the
entire
system,
both.
F
Saying
at
least
spend
10
minutes
on
seeing
is
the
the
way
you
do.
The
TCP
part
is
that
generic
enough,
that
it
would
be
able
to
fit
into
a
native
system
and
if
I,
would
support
an
effort
to
do
that
for
ITF
system
as
well,
because
as
far
as
I
know,
there
is
an
system-wide
settings
and
at
least
some
operating
systems
to
turn
TCP
keep
relies
on
by
default.
Okay,.
B
Okay,
well
look
into
it
so
just
to
speak
a
little
bit
to
what's
been
said,
the
okay.
So
first
off.
Let
me
on
this
slide.
It
said:
net
cough
keeper.
Lives
could
be
defined
at
the
neck
client
server
models
layer.
So
remember,
last
time
we
discussed.
How
would
we
go
about
doing
that?
Keep
lives
for
restaurant
keep
lives,
we
kind
of
concluded
it'd
be
hard
to
do,
I
mean
the
neck
off
our
PC
model
and
the
notifications,
and
especially
when
you
take
into
account
call
home,
actually
figuring
out
how
to
do
that.
B
So
it's
really
TBD
and
I
don't
actually
suggest
this
effort
should
try
to
introduce
Netcom
for
restaurant
level.
Keeper
lives,
it's
just
a
placeholder.
For
if
ever
this
working
group
wanted
to
define
Netcom
press
comma
keeper
lives,
could
such
people
iOS
be
fit
into
the
model
at
that
future
date?
Similarly,
oh
wow
I
don't
put
TBD
there.
There
is
such
thing
as
HTTP.
Keep
it
lives,
but
they're
really
for
HP,
1.0
and
1.1.
They
it
was
by
default.
She
didn't
have
to
configure
it.
B
It
was
just
by
default
and
http2
inherited
that
behavior
as
well,
but
but
also
there's
kind
of
a
misnomer
in
that
HTTP.
When
they
talk
about
keeping
lives,
they
don't
really
mean
keep
a
lives
such
as
like
actively
testing
the
aliveness
of
the
remote
system,
as
they
do
a
hint
that's
being
propagated
to
the
server
to
not
close
the
connection
within
10
seconds.
It's
more
like
keep.
B
Keep
the
underlying
transport
open
so
with
their
religious
that,
with
a
really
balanced,
so
I
think
HDPE
keep
lives
is
also
effectively
a
TBD
not
yet
defined,
and
this
effort
would
not
intend
to
actually
define
how
configuration
for
HP
keep
lives.
Truly,
it's
just
the
TCP
association
TLS,
where
we
would
want
to
configure
this
and
back
to
the
picture.
So
already
we
have
the
keeper
lives
in
the
current
models
that
keeper
lives
are
being
defined
at
the
Netcom
client
server
and
the
restaurant
client
server.
B
So
we
effectively
move
that
configuration
from
the
Netcom
press,
conf
layers
into
the
association
TLS
layers,
as
well
as
into
the
TCP
layer,
TCP
all
right.
So
this
kind
of
goes
to
the
scope
of
the
effort.
We
really
didn't
would
want
to
factor
out
TCP
client
server.
It's
it's
like
primarily.
What
we're
talking
how
we
got
into
this
discussion
is
because
Nokia
observed
that
the
open
SSL
doesn't
implement
today.
Tos
level
keep
lives,
there's
an
RFC,
for
they
don't
implement
it.
Yet
there's
a
discussion
about
that.
B
They
should
implement
it,
but
it's
still
not
implemented
yet,
and
they,
meanwhile,
they
have
to
do
TCP
keep
lives.
So
so
we
really
need
that
TCP
layer
and
configuration
of
TCP
keep
lives.
Do
we
need
to
have
HTTP
client
server
at
all,
and
you
know
similarly,
HTTP
client
server
at
all
I
mean,
as
the
IETF
goes.
We
generally
are
shunning
non
secure
protocols,
so
maybe
we
don't
bother
with
HTTP.
B
Clients
are
going
to
the
comment
made
about
the
expanding
a
number
of
drafts,
so
the
that
green
light
green
drafts,
the
HQ
client/server,
is
one
that
I
think
is
the
least
needed,
and
also
factoring
out
HTTP
from
rest,
cough
technically,
not
needed,
but
you
can
see
how
it
would
probably
be
better
to
factor
it
out.
There
will
be
other
HTTP
based
applications
and
having
it
factored
out
would
be
very
helpful
for
them,
as
opposed
to
us,
bundling
an
insight
at
the
restaurant
player
so
to
to
that
scope
of
the
effort
that
there's
are.
E
B
You
and
then
yeah
and
then
just
last
I
think
to
to
again
to
the
scope
of
the
effort
I
mean
in
thinking
about
okay.
You
know,
I,
don't
really
want
to
take
more
work
on
for
myself
here,
but
in
thinking
about
the
effort.
I
would
suggest
that
we
define
minimal
module
right.
So
if
we
were
to
do
TCP
client-server,
it
would
just
be
the
minimal
IP
address
port
number
and
a
keepalive
configuration
any
other
possible
TCP
level
configurations
could
be.
Ab
is
some
day
in
the
future.
B
I'm
not
really
interested
in
solving
that
further
scope
problem
same
for
HTTP
I,
don't
know
how
many
configuration
parameters
there
might
be
afraid
to
pee
I'm,
not
interested
in
figuring
it
out.
I
just
want
to
you
know,
have
defined
the
little
bit
that
we
need
to
define
to
get
this
factoring
out
and
so
it'd
be
the
minimal
effort.
I.
Think
at
least
that's
the
way
I'd
like
to
approach
this.
Yes,
Michael
Abraham's.
F
I
F
No
for
world
for
not
conf
the
TSP
keep
alive
for
a
net
compensation
zone.
I
would
just
I,
don't
even
need
that
so
I
don't
know
is
someone
else
express
the
need
to
do
this
on
a
per
connection
level.
I
just
wouldn't
want
like
a
default
set
the
on
and
off.
Basically,
that's
what
all
that's
all
of
what
I
need
is.
Someone
else
needs
more
than
okay,
then
we
need
to
do
more,
but
I'm
just
saying
I
would
in
a
lot
of
scenarios.
B
F
F
E
B
And
actually
already
that's
the
strategy
we've
taken
like,
for
instance,
with
the
cessation
TLS,
we're
really
just
focusing
on
the
minimal
necessary
to
configure
the
crypto
stack
so
that
we
can
do
it.
But
if
you
look
at
various
a
cessation,
TLS
implementations,
there's
many
more
configurable
options,
we're
not
touching
any
of
them.
So
more
the
same
in
that
regard.
Yes,.
H
So
tim
carry
nokia
just
to
make
the
comment
from
from
Macau
is
that
you
know
we're
using
it
for
various
applications
right.
So
there's
a
TR
301
within
the
broadband
forum
that
does
call
home
that
uses
TCP
keeper
lives
and
so
there's
a
the
generic
setting
may
or
may
not
work
I,
don't
know
not
sure
it
works
in
that
because
it's
on
a
stream
based
and
we've
got
multiple
endpoints
that
we
have
to
talk
to.
H
B
If
you
know
people
could
collaborate
with
me,
you
know
it's
pretty
much
me
doing
most
of
this
effort,
but
if
I
had
some
co-authors
I'd
truly
believe
this
could
be
done.
You
know
by
104.
We
would
be
talking
about
it
being
done
and
were
there
any
other
things
that
we
forgotten
I
think
probably
be
going
to
last
call
around
that
time
frame
so
we're.
B
If
we
were
to
not
do
this,
then
we
still
have
to
finish
up
the
crypto
types
thing
that
Frank
presented
and
also
we
would
still
have
to
figure
out
how
to
do
keep
lives
and
I
don't
have
an
alternative
proposal.
That's
the
only
proposal
I
have
at
the
moment,
so
we'd
spend
some
wheels
I'm,
trying
to
figure
out
what
the
alternative
proposal
would
be.
We'd
be
looking
into
February
time,
maybe
March
timeframe
anyway.
B
J
K
So
hello,
everybody,
this
is
Alex
Alex
come
so
I'm,
going
to
give
a
quick
update
along
with
Rashad,
actually
on
this
on
the
sub
on
the
speak
of
the
subscription
drafts
and
as
also
earlier
really
actually,
we
don't
have
many
updates
for
this.
This
should
be
fairly.
This
should
be
fairly
short,
but
I
just
take
my
time
sure,
okay,
alright.
So,
basically
again,
there
are
a
whole
lot
of
drafts
that
deal
with
with
subscribe
notification,
yank
push
and
related
things.
K
What
are
we
talking
about
here
are
the
four
drafts
there
from
the
top,
the
ones
that
are
basically
in
working
group.
That's
called
have
to
have
just
passed.
All
the
other
drafts
are
basically
dependent
on
this
work
and
are
yeah
essentially
pending
until
later,
so
so
for
those
drafts
and
some
of
the
updates
here.
So
one
thing
in
key
to
mention:
we
had
a
slight
name
change
for
each
of
the
titles
of
the
drafts.
It
just
make
it
more
clear
that
they
are
all
related
and
related
to
the
same
for
the
same
topic
area.
K
K
Some
minor
knits,
like
renaming
the
subscription
identifier
to
ID,
to
make
it
less
verbose,
and
that's
so
forth,
and
various
of
in
various
in
a
variety
of
minor
editorial
text
journal
and
so
forth,
and
tweaks
and
those
sort
of
things
and
there's
one
upcoming
v.19
that
this
I
think
we
posted
shortly
after
the
obvious
in
all
that
they
and
that
the
site
has
been
real
for
this,
and
basically
there
was
a
thread
in
that
mod.
Concerning
updating
the
description
of
the
x-pyr
yang
object.
Definitions
are
we
do
that,
as
well
as
some
text
tweaks
concerning?
K
Basically,
the
modification
is
eating
of
subscriptions
as
a
requirement
that
they
need
to
come
from
the
subscriber
and
okay.
So
that's
that
and
thank
you
also
actually
for
the
extent
of
discussion
and
reviews
that
we
received
on
the
comment
on
on
this
and
Asha
and
all
of
those
drafts.
So
that
was
very
helpful.
So
thank
you.
K
Second
one
is
the
draft
IETF
net
conf
yang
push
on
this
one
also
saying
same
sorry,
very
group
last
call
is
complete.
It
has
undergone
four
revisions
since
last
time,
we're
now
in
be
20
again,
there
have
been
minor
updates
to
the
to
the
text,
some
clarifications
and
so
forth.
Some
very
mind
very,
very
minor
updates
to
the
yang
module
itself
so
points.
L
So
the
the
changes
to
the
net
cons
notifications
draft
also
were
relatively
minor,
similar
to
some
of
the
ones
Alex
presented
earlier.
You
know
title
change
to
so
that
to
align
with
everybody
else,
the
renaming
of
identifier
to
ID
there's
been
a
few
discussions
about
the
examples
in
the
appendix
e
dot
two
and
a
dot
3,
and
somebody
I
forget
who
it
was
had
asked
for.
You
know
subtree
and
XPath
filter
example.
So
those
are
the
changes
which
went,
Envy,
14
and
then
G
15,
which
is
supposed
to
go
in
very
soon,
is
I.
L
Okay,
rest
content
occasion,
there's
way
more
significant
changes
there
I
think,
because
that
document
didn't
get
as
much
love
as
the
others.
Previously
again,
thanks
to
all
the
comments
we
got
from
from
the
people
on
on
the
alias
the
first
major
change
was
removing
the
configured
subscriptions.
That
was
the
main
topic
of
discussion
OH
in
Montreal,
so
we
got
rid
of
that,
so
it's
dynamic
only
now.
Secondly,
the
the
document
was
very
a
bit
of
restaurant,
a
bit
of
HTTP
1.1
a
bit
of
HTTP
queue.
L
So
there
was
a
fair
amount
of
cleanup
there
to
align
with
restaurant
service
and
events.
For
example,
we
used
to
start
the
subscription
we
used
to
a
post
on
the
URI.
Now
it's
a
get
on
the
URI
to
align
with
our
C
80/40.
We
remove
the
bunch
of
H.
If
you
1.12
specifics,
you
see
way
more
restaurants
in
the
names
in
the
various
names
now
than
HTTP,
similar
to
the
net
conf
draft.
You
know
there
was
filter
examples
added.
There
was
a
discussion
on
the
alias
past
couple
weeks
regarding
stream
XPath
filter.
L
How
to
do
that
can
Jason
fix
a
dot
one
exam
appendix
a
dot.
One
examples
we
aligned
it
at
all
with
NAT
coms
notification,
so
that's
what's
out
there
right
now,
v09
and
vita,
and
what
should
go
in
today,
there's
a
spelling
fix,
but
also
what
was
mentioned
for
the
subscribe
notification
draft.
We
there
was
various
discussions
about
what
does
if
subscriber
or
a
client
mean-
and
there
was
a
proposal
for
restaurant-
to
tie
that
to
a
restaurant
username
so
that
v10
with
that
text
should
go
in
today.
L
We
would
like
I
mean
there's
been
discussions
about
this
many
times
key
before
we
would
like
those
to
go
to
the
IHG
as
soon
as
possible
as
the
process
allows
us
to
and
once
those
are
done,
I
mean
the
first
slide
Alex
presented
or
the
second
one
I
forget
is
a
bunch
of
other
drafts
which
are
dependent
on
those
ones
and
then
progress
on
those
ones.
That's
it.
Thank
you
any
comments.
B
Okay,
I'll
just
make
some
comments:
Thank
You
Rashad,
for
helping
with
the
rest
Kampf
notif
drafted.
It
wasn't
one
of
the
original
three
that
we
had
discussed,
but
adding
it
I
think
was
good
mostly
because
it
actually
helped
us
find
some
other
issues
right
in
the
SUBSCRIBE
notifications
draft,
so
I
had
a
sort
of
a
trickle,
cascading
benefit,
I,
think
beyond
just
sort
of
enabling
us
to
allow
Netcom
from
rest
count
to
move
forward
together,
which
is
a
general
goodness
for
the
working
group.
B
So
thank
you
for
that,
and
and
also
to
the
working
group
as
Shepard
as
soon
as
I
received
these
drafts.
You
know.
One
of
the
question
is
in
parallel
to
beginning
the
write-up
I'll
also
send
out
an
email
to
the
work
group,
just
asking
those
who
had
posted
comments
to
just
review
that
their
actual
you
know
their.
What
they
were
hoping
to
see
was
is
there
and
you
know
to
let
let
me
know
or
they
let
the
Shepherd
know.
If
it's
not
me,
there's
anything
amiss
but
otherwise
great.
Thank
you.
Thank
you
right.
K
So
there's
Alex
of
just
one.
So
what
clarification
so
when
is
it
busy?
So
what
is
the
process
specially
so
meeting?
When
is
it
being
centralized
G?
Is
it
busy
once
the
Shepherd
review
is
completed,
the
Shepherd
write-up
is
there?
Does
it
then
Messi
goat
is
sent
to
the
IC
review?
So
is
a
busy
serialize
like
that
visits
the
process?
Yes
for
the.
B
Most
part,
yes,
the
shepherd
does
the
writer
and
then
and
Shepherd
isn't
necessarily
always
the
chairs,
but
but
then
the
write-up
occurs,
and
then
the
chairs
discuss
whether
or
not
it's
appropriate
to
submit
for
publication,
which
is
equivalent
or
synonymous
to
going
to
the
is
G
so
well,
but
it
almost
happens
at
the
same
time.
So
the
Shepherd
right
up,
the
concluding
of
the
shipwright
up
and
they're
submitting
to
the
publication
or
to
dice
G
happens
at
the
same
time.
Then
what?
But
what
that
really
means?
B
It
goes
the
ad
Ignace
in
this
case
where
it
be
ad
right
up
and
he
needs
to
schedule
or
tell
a
chat
which
he
just
mentioned
a
moment
back.
You
know
it
could
be
a
month
out
it's
every
couple
weeks,
but
you
have
to
get
on
the
calendar,
so
it
gets
on
calendar
and
then
that
occurs.
Then
there
will
be
a
number
of
discuss
items
right.
So
the
various
ihe
members
will
have
comments.
All
of
them
will
ballot
on
your
drafts.
They
will
be
discuss
items
you
need.
B
You
will
need
to
resolve
all
those
discuss
items.
This
isn't
really
normally.
In
the
view
of
the
working
group,
it
happens
off
the
working
group
list,
the
chairs
and
the
shepherds
who
are
involved
in
that
process,
but
that
can
take
as
long
as
it
takes
it
and
I've
seen
it
sometimes
go
quickly,
a
couple
weeks
and
other
times
months,
just
depending
on
how
it
goes
then
that
concludes
it
goes
to
RFC
editor
and
then
there
are
Sierra
will
look
into
other
issues
and
they'll
be
more
back
and
forth.
Sure.
K
M
Hello,
Iowa,
amateur
Angela
Omaha
way
and,
firstly,
there
are
many
feedbacks
from
the
working
group.
What's
the
difference
between
the
Marco
stream
originators
and
the
you'd
be
publication
channel
this
to
draft
here
is
the
relationship.
The
multiple
stream
originators
draft
is
distributed.
Extension
to
the
yunkish
draft
and
the
you
to
be
public
based
the
publication
channel
is
an
transport
for
that
can
be
used
for
both
young
Busha
and
the
multiple
stream
originators,
and
this
presentation
we're
going
to
talk
about
the
unity
based
of
publication
channel.
M
Firstly,
we
would
write.
I
would
like
to
clarify
the
design
goal
we
want
to
produce
a
new
TV
base,
the
transport
for
the
carrier
routers.
There
are
many
advantages
that
compelled
to
UDP
UDP
compelled
to
TCP,
and
here
we
list
the
some.
We
also
want
to
support
multiple
encodings,
including
the
binary,
and
we
also
want
to
enable
options
for
extensibility
and
want
to
facilitates
the
distributed
data
export.
M
We
also
get
requests
from
lustre
meeting
to
compare
with
some
existing
transport.
Here
it
is,
firstly,
the
IP
fix
is
designed
for
the
flow
information
export
is
it
do
not
support,
mark
or
other
encodings
such
as
XML,
zebra
and
GPB,
so
on
and
there's
no
Yankee,
IP
fix
encoding
and
no
mechanism
for
block
message,
fragmentation
and
no
extension
mechanism
and
that
the
other
protocol
is
co-op.
We
I
think
it's
a
it's
an
option
for
IOT
and
it's
designed
for
resource
constrained
device
and
network.
It's
not
for
carry
router
the
message.
Id
is
16-bit.
M
M
We
need
to
consider
the
dynamic
subscription.
Also
here's
the
next
step.
Firstly,
we
need
to
consider
how
to
manage
the
dynamic
subscription
we
may
augment
to
the
established
subscription
RPC
with
the
transport
and
receiver
information.
This.
This
is
not
to
existing
in
current
subscribe,
the
notification
chapter,
and
we
also
need
to
update
the
subscription
model
by
adding
the
dynamic
sub
screen
support
and
adds
the
encoding
attributed
to
the
receiver,
and
we
also
well
aligned
the
document
name
with
other
transport
document.
B
B
Yes,
how
we
might
characterize
this
draft
and
like
with
all
the
other
Notah
for
the
current
note
of
drafts,
they're
really
just
providing
dynamic,
subscription-only
support,
because
we
never
really
got
around
to
thinking
that
we
would
want
to
have
configured
Netcom
for
restaurant
subscriptions,
but
for
for,
but
we
do
want
to
have
configured
udp-based
subscriptions
and
that's
how
this
draft
came
to
be
adopted.
Working
group,
supported
item
and
also
I
think
having
dynamics
descriptions
make
sense
as
well.
B
B
B
Do
you
think
we
do
have
a
name
for
the?
We
need
to
call
it
something,
but
but
it
is
a
UDP
based
protocol.
It
has
a
new
it's
defining
its
own
message,
header
or
etc.
It
can
contain
different
encodings
particular
so
anyway,
it
is
a
new
UDP
based
protocol
with
that
work
describing
being
defined
as
a
notif.
So
then,
finally,
getting
to
my
question
is
defining
a
new
UDP
based
protocol
making
sense
relative
to
making
use
of
an
alternative.
B
Existing
UTP
based
protocol
and
I
know
you
discussed
IP
fix
and
co-op
I
guess
with
IP
fix.
One
of
the
things
he
mentioned
was
that
it
doesn't
support
different
encodings,
but
maybe
that's
okay,
maybe
just
a
single
encoding
would
be
okay
for
co-op.
You
mentioned
that
the
message
ID
was
only
65
thousand
and
I
think
the
concern
there
is
that
IOT
devices
their
rate
of
transmissions
would
be
very
slow,
but
a
high-end
router
could
send
65,000
messages
within
a
single
second,
so
you
would.
B
It
would
lead
to
many
issues
so
so,
but
there
may
be
the.
If
that's
the
only
concern
there
is.
Maybe
there's
an
opportunity
for
this
working
group
to
approach
the
coop
working
group
to
ask
them
if
there
might
be
a
possibility
to
extend
that
message.
Header,
you
know
I
know
I'm
just
exploring
ideas,
other
ways
that
we
might
be
able
to
solve.
The
general
problem
which
the
working
group
wants
to
solve
is
a
udp-based
notification
message
for
subscribe
notifications,
but
how
we
get
there
I
think
I
think
we
should
still
consider
the
solution
space.
N
N
If
you
don't
expect
duplicates
in
that
dimension,
the
association
between
the
requests
also
the
subscription
to
the
stream
is
the
coop
token,
and
that's
eight
bytes
I,
don't
think
that's
the
problem,
so
maybe
message
ID
via
sort
of
misinterpret
idea,
I
think
I
I,
don't
see
that
it
is
a
problem,
but
on
the
other
hand
you
want
to
have
this
inside
system
like
I
heard
like
between
line
cards
or
in
this
is
not
leaving
the
the
data
store
system
component.
I
I
have
the
feeling,
so
maybe
then
having
a
listening
server.
N
This
is
best
Rest
for
co-op.
Server
is
a
little
bit
over
too
much.
Then
you
can
just
establish
a
UDP
stream.
It
depends
on
the
application
if
it
has,
it
goes
through
the
internet.
Probably
co-op
is
a
good
idea
if
it
is
just
for
high
volume
inside
a
system.
You
can
basically
unpack
all
of
the
overhead
tuned
for
Internet
Protocol.
It's
there
now,
not
not
not
being
the
devil's
advocate
at
the
IETF
just
to
say
that
we
don't
need
internet
for
the
courts
here,
but
but
you
can
strip
a
lot
of
that
off.
I.
F
N
B
B
E
B
N
My
last
comment
is
anything,
but
binary
representation
doesn't
make
much
sense
inside
if
you're
talking
about
burdened
by
TCP
state,
I,
think
being
burdened
by
something
else,
as
a
binary
is
even
worse,
so
I
think
it's
rather
obvious
not
to
use
human
readable,
clear
text
formats
like
JSON
or
XML
I
think
it
would
defeat
the
initial
purpose.
I
think
I
have
the
feeling
of
the
concept
of
the
block.
Okay,
I.
O
Here
from
Google
I
find
that
the
whole
section
of
this
draft
to
do
with
any
kind
of
reliable
delivery
and
discussion
of
how
you
should
only
really
deploy
this
over
reliable
networks
is
it's
under
specified.
So
our
operational
experience
of
having
tried
to
put
something
udp-based
streaming
into
production
is
there
are
no
reliable
delivery
channels,
like
you
have
bits
of
your
network,
where
you
can't
possibly
assume
that
all
packets
are
going
to
get
through
or
there's
no
congestion,
because
it's
just
not
like
even
the
amount
of
bandwidth
you
can
buy.
O
There
is
not
sufficient
and
the
the
cost
of
having
to
assume
that
the
channel
is
unreliable.
Is
the
law
of
periodic
replication
of
the
data
on
there
on
the
chat
on
the
channel
so
that
you
can
deal
with
retransmission
or
dealing
with
retransmission
I
would
go
so
far
as
to
say
as
soon
as
you
have
to
deal
with
retransmission
you
might
as
well
use
TCP
anyway
and
TCP,
and
then
because
you
also
get
the
advantages
of
knowing
that
reliably.
When
you
sent
an
event,
it
got
to
the
other
end.
O
My
suspicion
and
operational
experience
of
having
a
few
thousand
devices
that
run
telemetry
at
this
point
across
number
of
vendors
is
that
you
will
just
go
to
TCP
again
as
soon
as
you
have
to
deal
with
these
problems,
which
are
kind
of
the
operational
realities.
So
I.
Don't
really
think
we
should
be
pushing
the
industry
in
a
way
that
doesn't
really
work.
M
O
But
the
the
problem
is
now:
how
do
I
build
any
kind
of
system
that
relies
the
data
being
there?
So
I
can,
if
I'm
trying
to
do
anything
with
interface,
statistics
and
I
know
that
there
might
be
fidelity
loss
because
I've
got
lost.
Packets
I
can't
rely
on
it.
If
there,
you
can't
do
anything
event
based
because
an
interface
goes
down
in
my
network
and
then
you
don't
have
any
way
to
react
to
it.
You
don't
know
that
the
state
is
there.
O
So
the
the
natural
requirement,
then,
is
that
you
end
up
building
a
polling
system
to
make
sure
that
you
have
a
current
enough
view
or
to
Rican
to
reconcile
and
our
scaling
analysis
kind
of
shows
as
soon
as
you
do,
that
you're
going
to
end
up
with
significantly
more
data
than
you
would
via
TCP.
So
this
scalability
argument
kind
of
falls
down,
so
we've
been
pushing
this
entirely
tcp-based
can't.
B
As
a
contributor,
don't
just
jump
in
for
a
second
ooh.
What
is
the
motivation
for
you
udp-based?
Is
it
the
reliability
or
unreal
I?
Don't
think
that
was
it
I
so
much
as
the
desire
to
enable
the
line
cars
to
send
the
UDP
packets
having
the
same
source,
IP
and
port
ordinary,
not
port,
but
at
least
IP
address
as
the
routing
engine.
You
know
that
they
that,
for
the
other
draft
that
we
are
about
to
present
the
multiple
stream
originators,
so
the
desire
for
UDP
is
to
enable
that
distributed
source.
So.
O
We've
looked
to
this
I
think
that
there's
a
there's,
a
model
whereby
you
have
a
distributed
system
that
has
different
components
that
can
each
have
TCP
right,
like
I,
think
you're
going
to
end
up
going
that
way.
If
you
ever
care
about
reliability,
if
you
say
this
is
a
hundred
percent
unreliable,
then
I
think
you
can
kind
of
talk
yourself
into
this
UDP
model.
But
if
you
say
I'm,
one
distribution,
because
it
gives
me
more
scalability
point
to
be
proven
as
to
whether
that's
really
required,
and
then
you
you
can
still
do
TCP.
O
It
was
a
lightweight
TCP
protocol
to
the
to
the
line
cards
and
you're
kind
of
inventing
a
new
protocol
here,
as
you
pointed
out,
so
you've
got
a
bunch
of
room
to
be
able
to
design
it
exactly
how
you
want
the
source,
IP
and
I
would
just
suggest
for
debug
ability,
it's
kind
of
a
challenge.
If
you
have
n
producers
that
are
all
producing
with
the
same
source
IP
it's
kind
of
like
it's.
O
We
have
challenges
around
being
able
to
know
whether
you're,
actually
in
synchronization
with
that
system,
if
you've
got
n
different
producers,
one
line
card
stops
producing
data
and
you
don't
really
know
you've
got
no
metric
to
be
able
to
alert
on
say
of
this
source,
isn't
sending
mutator
anymore,
I.
Think.
B
We're
jumping
into
the
next
draft,
but
I
think
that
draft
is
the
idea
is
that
the
configuration
model
would
allow
you
to
configure
the
UDP
to
the
system,
and
then
the
system
implicitly
distributes
to
line
cards
and
tells
each
of
them.
You
know
it's
implicit,
but
if
you
do
were
to
do,
TCP
you'd
have
to
be
explicit.
The
configuration
model
would
actually
have
to
configure.
We
use
this
IP
address
for
that
line
curtain
for
each
language.
N
Hi
this
is
Hank
again.
If
you
are
expecting
to
have
congestions,
you
will
have
UDP
Datagram
loss,
I
mean
apparently
so
so
that
that's
a
fundamental
decision
you
have
to
make.
Do
you
expect
congestion
with
your
dreams
or
not?
If
you
have
that
expectation
which
I
think
is
likely,
then
you
have
to
deal
with
retransmits
and
then
again
you
should
not
reinvent
a
fundamentally
transmitted
mechanism
for
UDP
for
every
draft
in
the
ITF.
N
There
is
a
good
template
for
that
in
coop.
That
is
a
confirmable
message.
You
can
basically
make
every
message
confirm:
overages,
big,
not
not
recommended
or
every
thousands
message,
and
you
can
then
see
how
many
you
lost
and
in
that
window
can
be
transmitted
messages
that
it's
like
a
little
bit
like
TCP,
but
like
the
performance,
TCP
advancement
and
also,
if
you
are
ending
up
with
TCP
in
the
end
again,
there's
I
call
it
a
reliable
co-op.
It's
the
name
is
co-op
over
TCP
TLS
and
web
sockets,
or
something
very
long,
so
I'm.
N
N
Let's
call
it
data
items
that
are
somehow
and
serious,
and
there
the
problem
of
retransmits
discussed
there,
and
if
you
have
a
problem
that
is
not
solved
in
general
and
you
want
to
solve
it
with
your
draft.
Maybe
we
can
create
a
general
solution
for
UDP
that
other
people
can
also
use
so
that
this
effect
of
recreating
some
new
things
for
UDP
to
make
it
some
more
look
like
TCP
some
our
ends.
N
Finally,
also
that
if
you
decide
to
go
with
co-op,
there
is
the
draft
non-traditional
responses
which
can
do
it,
but
basically
every
exotic
thing
you
need
that
does
not
speak
fire
at
the
moment,
satisfied
with
co-op.
So
if
you
need
something
you
don't
find
and
current
are
cease.
Please
trying
to
thing
to
thing:
research
good
for
once
and
then
to
look
at
the
serious
pattern
and
the
untraditional
response
props,
as.
D
N
B
And
can't,
as
a
contributor,
just
a
quick,
follow
up
on
the
discussion
about
retransmissions
I.
Actually,
when
I
first
saw
the
message
ID
with
the
UDP
I,
never
thought
that
it
would
be
for
the
purpose
of
knowing,
when
or
to
request
for
a
retransmission
or
anything
like
that.
I
only
thought
it
would
be
used
for
won't
number
one
ordering
of
the
packets
received
by
the
receiver,
because
UDP
doesn't
guarantee
order
delivery,
so
at
least
the
receiver
could
do
in
order.
You
know
reorder
at
least
have
order
delivery.
That
was
the
number
one
reason
or
motivation.
B
I
felt
that
was
before
the
message-id
and
number
two
was
for
detecting
gaps.
Now,
when,
when
a
message
was
dropped,
but
not
not
to
request
just
to
know
that
you
lock,
they
miss
one
and
so
I
never
would
I
thinking
that
there
would
be
a
desire
to
try
to
build
reliability
on
top
of
a
UDP
based
protocol.
Here.
O
Prob
again
sorry
I
was
a
long,
walk
and
I
think
that
that's
a
interesting
operational
like
mode
of
mode
of
operation
right.
So,
if
we've
kind
of
said
before,
and
so
with
with
SNMP
I
can
poll
the
device
I
know
I
get
some
stats
back.
Yes,
maybe
there's
some
loss
in
them,
but
I
know
at
what
interval
I'm
polling
in
this
mode.
O
Where
there's
no
reliability,
then,
if
the
device
just
shuts
up,
you
can't
tell
right,
because
you
don't-
you
didn't,
get
a
sequence
number
to
tell,
and
it
becomes
quite
operationally
difficult
to
not
assume
reliability
when
there
isn't,
when
there's,
no,
no
guarantee
that
the
thing
at
the
other
end
is
sending
data.
So
this
is
kind
of
I
mean
we
tried
with
this.
O
We
looked
at
it
as
the
preferred
way
to
start
with,
and
this
along
with
internal
the
collector
deployment
things
about
how
how
you
know
when
it
could
can
reconnect
how
you
deal
with
redundancy
between
collectors
and
those
kind
of
things,
I
think
it
just
makes
more
and
more
challenges
here,
so
that
that's
kind
of
why
I
would
just
I
think
the
draft
could
do
with
some
discussion
of
like
how
you
actually
operate.
The
system
like
this
I
agree.
P
Justin
sure,
just
to
interrupt
comments,
I
work
for
a
company
we
use
streaming
extensively
from
thousands
of
devices,
don't
quite
some
time.
Looking
at
UDP
or
TCP
and
I
also
discussed
with
potential
customers
UDP
us
no,
no,
it
has
to
be
reliable.
Otherwise
you
need
to
build
additional
layer
to
ensure
it
transmissions
reliability.
You
don't
need
this
here.
Q
Q
Q
O
Just
to
add
to
pay,
no,
it's
fine,
I,
think
fundamentally,
yeah
sflow,
IP
fix
have
a
different
nature
anyway,
because
we
know
that
there's
n
flows
on
the
device.
We
know
that
or
n
packets
going
through
the
device,
and
we
know
that
we
only
expect
a
sample
of
them,
therefore
losing
one.
We
can
never
build
a
system
around.
O
Having
get
like
that,
I
don't
know
of
any
system,
that's
built
to
say,
with
s
flow
or
IP,
fixed
I'm,
going
to
do
one
to
one
flow
sampling
and
I'm,
going
to
guarantee
that
I'll
get
every
one
of
them,
whereas
with
telemetry
data,
if
we're
building
systems
that
now
split
the
control
plane
across
the
device
and
off
the
device,
then
we
need
it
to
be
reliable.
Just
like
you
would
need
some
of
this
data
internally
to
the
system
like
links
going
up
and
down
to
be
reliable
for
routing
protocols.
Q
So,
but
no
again,
so
it
depends
what
you
call
telemetry
right.
If
it's
telemetry
I
mean
to
push
high
frequency,
all
information
from
it's
like
IP,
fix
your
sending
flow
records,
even
if
they're
not
flow
whatever
right.
Now,
if
you
condense
everything
in
your
telemetry,
so
it
becomes
an
event
you
can't
miss
it.
K
So
this
is
Alex
yeah,
just
one
of
the
busy
in
response
to
some
of
the
items
here,
clearly
a
different
application
like
that.
Maybe
some
application,
maybe,
but
you
require
reliability,
others
where
you're
saying
you
lose
one
record:
it's
not
a
big
deal
and
another
question
is:
can
you
how
it
is
being
used?
So
if
you
use
this
for
periodic
busy
for
periodic
updates,
you
know
basically
that
you
are
expecting
updates
for
every
period
already
anyway.
So
if
you
have
a
period
missing,
you
would
basically
to
infer
some
of
some
of
those
things
well.
K
I
do
agree,
actually
that
we
need
to
have
the
discussion
busy
of
these
operational
things
in
the
trade-offs
in
this,
but
at
the
same
time,
I
think
I
think
nobody
is
saying
that
this
is
the
be-all
end-all
transport
for
all
particular
use
cases.
This
is
one
use
case
for
certain
scenarios
where
basically,
those
operational
scenarios
that
you
described
yeah
would
be
applicable
so.
O
Rob
again
just
a
response
that
I
think
there's
a
few
challenges
with
those
assumptions
right.
So
as
soon
as
you
say,
oh
I'll
stream,
everything
periodically
you're
going
to
significantly
increase
the
data
that
comes
from
the
device
and
by
hundreds
and
hundreds
of
times
right,
so
actually
the
to
make
this
system
scaleable.
You
probably
want
to
only
send
things
when
they
change.
It
gives
you
a
significant
advantage
for
large
data
sets.
O
It
also
gives
you
a
significant
advantage
for
interfaces
they're
down
on
systems
with
you
know,
radix
of
a
thousand
or
so
which,
which
is
kind
of
common
in
today's
networks.
So,
as
soon
as
you
say,
I'll
send
things
periodically
you're
going
to
end
up
with
these
scalability
concerns,
and
you
probably
are
now
having
to
deal
with
worse
scale
on
the
device
of
your
GP
periodic
than
you
would
be
the
cost
of
doing
TCP
for
reliable.
So,
yes,
I,
don't
entually.
O
The
other
problem
about
periodic
is
that
you
don't
actually
know
what
they
collect
or
what
you
meant
to
receive.
So
if
a
whole
line
card
stops
sending
did
Glen
Kyle
get
removed
from
the
system,
what
did
was
it
meant
to
send?
So
it's
actually
hugely
difficult
without
lots
and
lots
of
other
accounting
to
know
what
you
should
have
been
sent
during
that
period.
So
I
I
see
why
the
the
third
thing
I
shouldn't
say,
is
we're
inventing
a
new
protocol
here
to
send
telemetry
data.
K
Respond
so
regarding
the
unchanged
versus
periodic,
if
we
certainly
on
the
basic
trade-offs,
but
actually
they
subscribe.
The
subscriptions
both
can
support
either
what
I
mean,
depending
on
the
use
case,
a
user
or
they
will
decide
whether
they
want
to
happy
erotic
or
whether
unchanged
is
actually
more
applicable
for
their
particular
application.
If
you
want
to
have
a
continuous
and
telemetry
to
do
some
kind
of
whatever,
whereas
statistics
trendline
analysis,
all
sorts
of
application,
you
might
still
want
to
have
periodic
right.
Not
not
every
use
case
requires
or
change.
K
O
This
is
what
we've
done
and
then
look
at
what
the
proportion
of
it
that
is
event
based
versus
periodic
and
do
some
calculation
as
to
what
the
data
data
volume
is.
So
we
have
this
for
some
jet
friends
the
scaling
analysis
in
the
gr
PC
based
telemetry,
where
we
can
show
you
know
significant
reductions
based
on
this,
but
even
though
that
some
data
is
being
sampled
and
sent
periodically
because
it
needs
to
be
sampled
like
that
from
undying
Hardware
sources,
for
example,.
L
Related
questions
been
a
while,
since
I
looked
at
the
draft
but
I
remember,
there's
previous
message
ID
and
that's
how
the
receiver
knows
that
so
messages
have
been
lost,
but
if
you're
not
receiving
any
messages.
How
do
you
know
that
there's
messages
loss
or
we
going?
Can
we'll
have
to
do
a
UDP?
Keep
a
live
draft
or.
M
M
Q
Burn
worthless,
so
in
IP
fix
we
solve
that
with
SCTP
and
get
a
perfect
solution
where
actually
you
would
have
a
stream
which
is
reliable,
unreliable
or
partially
writable.
So,
depending
what
you're
sending
it
is
monitoring,
it
would
be
unrivaled.
You
miss
a
couple
of
information.
Fine,
no
big
deal.
You
might
be
something
anyway
on
a
router,
partially
reliable.
You
do
your
best
or
reliable
if
it's
event
base.
That's
how
we
solve
that.
Q
However,
a
ctp
didn't
pick
up
and
it's
an
issue
online
Kahn's
right
online
counts
of
routers
I
mean
again,
you
have
an
HTTP
session
directly
from
all
around
counts,
or
actually
it
complex.
You
an
operational
issue
right
and
I.
Think
Rob
mentioned
that.
How
do
you
identify
your
device?
A
router
is
like
one
IP
address
or
it's
a
sum
of
IP
addresses
to
one
per
line
yards.
Q
M
M
B
Just
as
a
contributor,
just
one
more
comment,
I
heard
or
learned
last
night
that
the
I
guess
it's
a
co-op
working
group,
but
there's
a
an
effort.
That's
been
going
on
for
a
couple
years
now
to
do
a
co-op
based
broker,
pub/sub
mechanism-
I,
don't
know
much
about
it,
but
we
should
learn
more
about
it
and
and
see
how
it
might
be
usable
in
this
space
as
well.
Okay,
let's
move
on
to
the
next
presentation:
okay,.
M
M
We
have
some
of
the
use
cases.
The
first
one
is
the
the
router.
The
Camerata
is
narrow
and
we
want
to
push
data
directory
from
the
line.
Cars
and
the
other
use
case
may
be
useful,
is
the
IOT
is
narrow
and
the
tractor
first
dream
subscribe
to
the
border
router
and
the
distributed
the
requester
to
different
route.
He
knows
and
the
Latinos
can
push
data
directly
to
the
tractor.
M
Here
is
solution
overview.
The
publisher
contains
two
rows:
the
master
and
the
agent
and
the
master
have
subscribed
subscription
server
and
the
agent
that
contains
the
component
subscript
is
over.
A
typical
typical
operation
is
like
that.
This,
the
the
subscriber
first
ascend,
the
global
subscription
request
to
the
master
and
the
master
will
decompose
this
request
into
multiple
component
a
subscription
and
send
to
the
components
of
screen
server.
Then
the
different
agent
or
master
have
pushed
data
directly
to
the
tractor.
M
Here
we
to
achieve
this,
there
are
many
interactions
necessary
between
the
master
and
the
agent.
For
example,
the
agent
need
to
have
a
registration
with
the
master
so
that
the
master
is
the
well
of
them
and
and
and
manage
the
lifecycle,
but
in
Manzanero
like
like
who
we
mentioned
in
in
the
career,
outer
the
interaction
between
the
master
and
the
agent
will
be
an
internal
implementation.
So
currently,
in
this
draft,
we
consider
its
out
of
scope,
but
we
listed
there
some
possible
interactions.
M
To
achieve
this
a
reference,
the
implementation
is
like
the
the
master,
may
need
a
data
structure
and
typically
our
resource
allocation
table
to
keep
track
of
the
mapping
between
the
resource
and
the
corresponding
location
of
the
subscription
server
and
another.
Another
key
point
is
the
publication
composition.
M
So
here
we
we
propose
to
use
a
list
of
a
publisher
ID.
We
will
add
this
to
the
to
the
response
of
the
establishes,
subscription
and
modify
the
subscription
and
also
add
this
in
the
subscription
status
and
subscription
modified
notifications,
and
this
part
when
they
need
a
young
model
by
augmented
the
existing
subscription
notification
draft.
M
The
other,
the
other
key
point
is
about
the
subscription
state
change
in
notifications.
We
know,
in
addition
to
sending
events
or
cause
to
the
receiver.
The
master
must
also
send
the
subscription
state
change
notification
and
we
here
we
were
away
asked
for
all
the
subscription
states
change.
In
note,
notifications
must
be
delivered
by
the
master
publication
channel,
which
is
the
session
between
the
master
publication,
publisher
and
the
receiver
there.
B
M
B
So
I
think
that
this
being
at
a
scope
is
dependent
on
the
conclusion
of
some
of
the
operational
requirements
that
we
were
discussing
a
moment
ago,
going
back
to
Rob's
comment
from
before
a
little
more
configuration
complexity
may
be
warranted,
if
were,
for
instance,
needing
to
configure
TCP
instead
of
UDP,
in
which
case
you
would
actually,
it
would
have
to
be
in
scope.
You
because
you'd
have
to
be
configuring.
What
is
the
TCP
interface,
at
least
for
each
line
card
to
use
so
I
think
I.
M
A
M
M
K
Is
Alex
also
hostile
to
add
always
he
respond
to
that.
I
would
not
mix
this
actually.
With
the
earlier
transport
discussion,
the
gold
certainly
busy
for
the
for
the
subscriptions
per
se.
It
has
always
been
to
basically
make
this
busy
make
this
well
make
the
fundamental
mechanism
reliable,
so
that
you
can
avoid
having
to
pull
things
now.
K
Obviously,
with
this
case,
if
you
have
a
new
component
subscription
that
was
added
or
something
that
was
removed,
that
is
be
an
event
that
you
would
needs
to
know
or
that
you
would
want
to
know,
certainly
as
a
collector.
Therefore,
basically
there's
something
that
that
that
needs
to
be
notified.
We've
had
some
this
some
internal
schedule,
whether
it
should
be
subscription
modified
or
whether
there
should
be
another
type
of
notification,
but
either
way
it
is
an
event
and
suppose
it
should
be
foreseen
vide
as
part
of
the
control
channel.
K
B
This
draft
is
not
yet
adopted,
but
the
idea
that
this
draft
was
discussing
was
one
that
was
presented
at
the
time
that
we
adopted
the
previous
strap,
which
was
the
goal
to
support
line
cards,
to
be
able
to
send
messages
themselves
directly
as
opposed
to
trying
to
fold
them
to
the
routing
engine
in
order
to
for
the
routing
engine
to
to
send
them,
because
from
experience
we
know
that
that
the
internal
backplane,
the
fabric,
is
not
having
enough
bandwidth
to
transmit
that
much
data.
It's
just
not
possible.
B
The
line
cards
have
to
be
able
to
send
directly
themselves,
and
in
fact
you
know
things
like
encryption.
Actually,
it's
probably
problematic,
and
so
you
know
go
into
the
operational
requirements
you
know.
Are
we
actually
thinking
that,
for
these
very
high
logging
scenarios
would
the
destination
be
an
internal
receiver,
something
that
on
a
LAN,
you
know
something
that
itself
would
collect
the
logs
in
unencrypted
form,
do
deduplication
and
and
analysis
compression
even
itself
could
convert
it
to
binary
or
the
need
for
binary.
You
don't
really
need
binary
in
the
land.
B
You
need
binary
on
the
WAM.
When
we
talk
to
customers,
you
know
their
their
costs
for
bandwidth
over
LAN
is
expensive.
That's
when
they
care
they
don't
care
about
the
bandwidth
on
the
land.
So
so
you
know
I
think
if
we
get
our
heads
around
what
are
the
operational
requirements?
What
is
the
problem
we're
trying
to
solve?
Maybe
some
of
this
would
become
more
clear.
I
still
strongly
support
the
notion
ability
for
sending
logs
out
the
line
cards
directly.
B
F
I
I've
the
when
use
case
where
I
might
have
a
a
Wi-Fi
access
point
that
basically
doesn't
have
an
IP
address,
so
I'm
speaking
some
kind
of
protocol
to
it
or
I
don't
want
it
to
send
any
thinks
it's
going
through
me,
but
it's
a
different
device
and
I
want
to
like
expose
this
in
yang
so
that
the
wife,
it's
like
I'm,
the
nighttime
room,
I'm,
the
Netcom
server,
but
I'm
configuring,
the
guy
over
there
and
I
still
want
exposed
to
my
NMS
that
these
are
two
different
devices.
Isn't
that
kind
of
the
same
problem?
F
You're,
don't
want
to
like
a
more
generic
approach
and
how
to
expose
this
in
Yang
and
net
conf
and
how
to
handle
this.
Because
isn't
this
the
same
thing
and
like
if
it's
a
lying
it
like
line
card
that
is
like
its
own
computer
sitting
in
the
chassis
or
if
it's
something
else
like
you're
acting
on
behalf
of
that
guy
I
mean
I've,
seen
many
different
scenarios
where
you
need
the
same
concept.
So,
can
we
make
it
more
general
yeah,
I
think.
M
F
F
Yes,
I
know,
but,
but
it's
like
so
this
here,
it's
talking
about
subscription,
so
but
isn't
this
just
configuration
it's
just.
It's
not
me
specifically
I'm
doing
this
for
another
guy
that
he's
like
near
I'm
controlling
him.
So
it's
not
me.
Don't
we
need
like
a
more
generic
approach
that
and
do
we
actually
need
to
talk
about
what
the
configuration
is
instead,
isn't
it
like?
How
do
we
do
this
generically?
F
Isn't
that
what
we
should
be
discussing
like
it's
talking
about
subscriptions
here
and
so
on,
and
how
to
talk
to
that
guy
or
what
to
actually
configure,
but
don't
we
actually
need
just
a
best
comment.
This
is
exposing
this
entire
concept
of
you
know.
Different
devices
managed
through
one
net
culture,
I
have
a
response,
but
I
think
Rob
does
as.
O
I
completely
agree,
so
in
the
GRP
sea
bass
it's
about
telemetry
and
configuration,
we
added
a
generic
way
to
be
able
to
make
a
path,
be
addressable
to
a
certain
target
that
they
entered.
The
managing
entity
deals
with
and
it's
used
for
both
telemetry
and
for
AM
for
configuration,
I
think
having
case-by-case
solutions
is
make
the
point
I,
don't
think
it's
optimal,
I
think
having
a
single
way
that
you
can
say
there
is
this
management
agent
that
is
responsible
for
this
other
domain
is,
is
super
useful
for
many
many
cases?
Ok,.
B
So
up
leveling
the
problem
space,
great,
ok
and
I.
Think
my
closing
thought
is
not
it's
not
really
on
this
draft.
What
kind
of
to
the
other
one
as
well,
it
is,
you
know
currently
just
the
gang
push
and
Friends
drafts
are
almost
out
of
last
call
and
a
Shepherd
right
up.
We
as
working
group
we've
only
yet
to
find
support
for
dynamics
descriptions.
We
do
not
yet
have
any
support
for
configured
descriptions.
B
This
draft
has
honest
path
towards
enabling
support
for
configured
descriptions,
but
I
think
that
there
may
be
other
paths
that
we
could
explore.
That
would
get
us
there
faster
specifically
HTTP
based
push
mechanism
is
something
along
these
lines.
I
don't
know.
Maybe
somebody
would
be
interested
in
putting
together
an
ID
to
propose
another
notice
right.
So
the
nice
thing
about
the
way
that
we've
constructed
the
or
deconstructed
the
the
yang
push
notification
drafts
is
that
we
do
have
all
these
note
of
mechanisms.
B
So
it's
kind
of
a
Swiss
Army
knife,
it's
great
that
we
have
a
UDP
based
mechanism
available.
Certain
deployments
will
use
it
for
their
use
cases.
Others
won't
because
it
doesn't
matter
use
cases.
So
I
think,
though,
which
should
also
consider
other
notifications
that
would
enable
us
to
have
configured
descriptions.
So
that's
sort
of
my
closing
thought
on
this.
M
A
I
think
before
we
get
to
the
point
of
adoption,
I
think
we
probably
need
to
address
the
question
that
Mike
McAlister
trays,
which
is
do
we
need
to
upscale
this
problem
definition
before
we
get
to
the
question
of
adoption?
Maybe
you
should
consider
all
that.
First,
okay,
thanks.
R
Good
morning,
everyone,
my
name,
is
Jim
and
I
could
show
you
attention
to
this
a
new
idea.
Actually,
this
job
has
been
around
for
a
while
we
actually
submitted
in
the
last
night.
A
meeting
I
didn't
get
it
discussed
and
ivory,
but
we
have
some
a
few
discussion
on
the
list
with
Robo
virgin
and
about
this
idea
in
nine
action
capability,
because
here
what
we
like
to
do
is
to
use
this
capability
to
to
provides
a
punk
operation
and
can
walk
aways
together.
R
It's
the
protocol
position,
but
some
of
many
discussion
about
whether
there's
some
Atalaya
medicine
we
can
use
such
as
commission
template,
and
so
we
do
some
Alice's
and,
and
so
before
this
meeting.
Actually
we
prepare
the
draft,
updated
I
missed
the
deadline,
so
we
just
post
our
new
version.
So
sorry
for
the
late.
R
So
for
this
chapter
we
want
to
recap
a
little
bit
provide
several
observation.
The
photo
action
actually
met.
A
couple
actually
doesn't
specify
how
to
handle
this
action.
The
reason
is
because
the
action
get
introduced
in
young
101
after
medical
for
work,
I
window
one
get
a
puppy
and
when
we
introduce
a
young
MTA
and
the
option,
you
know
we
add
the
constrictor
for
this
action.
They
only
can
be
invoked
on
the
original
state
datastore.
So
we
think
is
a
very
limited,
so
we,
you
know,
track
the
early
discussion
on
these
actually
there's
some
statement.
R
You
said
actually
from
the
robber
weapon
and
then
this
kinda
research
can
be
relaxed,
actually
can
be
applied
to
some
other
convention
conversion
latest
also.
We
that
the
motive
like
what
motivated
me
to
rise
this
job,
and
so
we
try
to
investigate
how
this
action
can
be
applied
to
as
a
Korean
datastore
like
wrong
in
datastore
or
start-up
datastore.
R
So
here
is
use
cases
and-
and
we
we
have
some
men
in
this
country
about
this
I-
think
the
simple
cases
we
bring
here
actually
is
suppose
you
configure
the
win
and
hacker
branch
on
the
champion
the
face,
and
you
may
leverage
is
the
conversion
template
if
you
actually
configure
the
chung
interface
with
vein
and
tank
a
value
one
by
one.
Actually,
that
means
that
you
may
you
know
have
a
you
may
need
to
a
lot
of
second
in
traffic.
R
Actually
you
may,
but
we
have
some
other
other
way
you
because
you
you
have
the
completion
template
and
you
can
define
young
data
model
to
to
allow
you
to
configure
the
trunk
interface
ways
pedantic
rng
with
such
congratu.
You
can.
Maybe
you
can
really
reduce
these
sickening
traffic.
'you
only
need
a
one
or
the
message
you
to
carry
these
conversion
data,
but
still
actually
cause
a
larger
packet
size
so
so
go
to
the
face
further.
Actually
you
actually
config
chunk
interface
with
several
VLAN
tag
around
you
labyrinth
a
garage,
not
a
diss
greater.
R
So
in
this
case,
actually
you
may
you
know,
do
a
lot
of
beta
retriever.
You
know
that
cause
a
even
a
lot
of
the
protocol
message
exchange.
So
what
do
we
like
to
do
is
optimize
the
network
net
called
protocol
to
provide
such
a
punk
operation?
You
view
kimochi
the
VIN
and
tag
arranged
several
Bananagrams
into
one.
We
rent
a
grantee.
Actually
you
only
need
the
one
protocol
message
exchange.
R
So
what
do
we
propose
here?
Is
a
u9
actionability
here
these
actually
can
be
applied
to
wear
a
different
protocol
operation
like
edit
config.
I
did't
paid
her
okay
to
date.
Her
and
the
idea
is
to
introduce
the
operation
attribute.
For
example,
under
the
edit
configure.
Surely
we
can
introduce
two
new
operation
attribute
were
called
record.
Emergency
recorded
split,
actually
allow
you
to
to
merge
the
way
number
of
in
an
attacker
range
or
speeds
up
in
an
attacker
ng.
R
If
you
can
allow
such
kind
of
feature,
you
really
actually
improve
the
Nanticoke
for
query
efficiency,
and
you
only
need
actually
one
query
to
get
all
the
information
you
needed
here.
We
gave
the
example
for
this
operation
attribute
recall
the
record
emerge
actually
without
the
u9
action
capability.
Suppose
you
need
to
configure
the
tummy
in
the
face
with
to
win
and
hack
around
you,
and
but
you
really
want
to
merge
them
into
one
when
an
attacker
ranges.
So
so
you,
what
do
you
can
do
with
the
existing
solution
for
them
or
edit
config?
R
Actually,
you,
you
need
to
delete
research
to
win
an
attacker
ranges.
First
and
then
you
created
a
new
bin
and
tag
arranged
with
this
one.
So
in
our
solution,
actually
we,
if
we
with
we,
have
the
win
in
I
action
support.
Actually
we
can,
you
know,
just
the
you
know
introduces
a
week
Mergent
attributed
to
indicate
a
new
server
to
use
the
completion
and
temperature
to
merge
the
the
renji
into
the
into
one
range
in
their
server
side.
So
also
we
want
to
compare
the
difference.
Actually
you
know
for
without
the
in
matching
capability.
R
R
Another
case
actually
is
a
recorder.
We
call
the
recorders
breed.
Actually
you
may
have
when
we
nan
tackle
Reggie,
you
want
to
split
into
three
or
four
and
with
the
existing
protocol
operation
you
we
also
use
at
config.
Actually
you
may
first
I
mean
you
need
to
delete
the
Divina
tank
of
value,
and
then
you
can,
and
now
you
create
a
another
two
or
three
vinegar
ranges.
So
this
actually
is
a
cost.
Actually
you
you
introduce
that
other
ways
in
my
action
capability.
R
Actually,
you
you
only
need
to
actually
indicated
a
server
to
choose
the
VIN
and
tag
arrange.
It
may
not
attack
a
range,
it's
oblivious,
so
these
can
be
happen
on
the
server
side.
So
so
the
advantage
is
you
you
don't
need
to
rely
on
the
kleiner
to
do
the
more
Renji
computation
to
speed
at
the
ranch.
So
this
is
a
basic
idea:
I
like
Joe
your
attention.
Actually,
so
the
summarizes
what
we
proposed
here.
Actually
we
want
to
use
this
in
action
to
embedding
into
the
protocol
operation
to
improve
the
medical
require
in
fishin
see.
R
Actually
we
call
this
a
Bunco
operation
may
be
the
solution.
The
example
we
provide
here
is
very
limited,
but
we
think
the
intention
is
so.
You
know
really
impose
these
kind
of
nano
copy
fishing.
With
these
pump
operation
we
may
introduce
some
propriety.
Actually
you
can.
Actually,
you
know,
do
the
pump
operation
with
with
this
kind
of
group,
so
they
can
really
improve
the
medical
call
for
query
efficiency.
Yeah.
That's
all
yeah
Michael.
F
A
result
so
I,
don't
know
why
I
don't
read
the
draft
if
I
understood
correctly
is
this
only
for
when
the
will
you
change
the
configuration,
but
the
end
result
operational
State
does
not
change.
Is
that
the
only
so
you're
splitting
the
range
into
two
but
the
effective?
You
know
in
effect
configuration
on
the
line
card
or
whatever
it
never
changes.
Is
it
only
for
that
type
of
configuration
or
is
it
also,
or
is
this
also
it
like
you
split
it,
and
then
you
delete
one
and
you
do
that
in
one
operation?
F
Okay,
so
you
had
the
example
one
two
five
and
six
is
six
to
ten.
You
can
merge,
you
can
merge
those
and
into
one
record
yeah.
If
this
changes,
nothing
in
in
real
life,
I
mean
the
line
card.
The
hardware
doesn't
get
reprogrammed
by
that
operation.
You're
changing
the
configuration,
but
the
state
of
the
device
doesn't
change.
Is
it
only
for
that
type
of
operation,
or
is
it
also
for
for
deleting
one
of
the
villains
in
the
middle?
It's
for
both
yeah
I
think
we.
R
Right
now
we
really
support
both.
Actually
the
motivation
we
can
have
the
you
know,
merger
that
is
created
several
tag
around
into
the
one.
Allow
you
to
do
the
better
medical
query
you
know,
but
actually
we
also
support
away.
We
in
some
cases
you
may
need
to
delete
a
some
of
the
value
from
the
VLAN
tag
arranges,
so
we
provide
such
capability
in
some
cases.
Actually,
we,
you
know
we
need
to
support
post
and,
and
then
we
can
actually
can
you
know
optimize
the
actual
to
to
merge
several
rent
into
the
wine
wrench
yeah.
F
R
F
R
Don't
want
you
add
over
here
to
the
client.
Actually,
maybe
you
just
need
a
one
transaction,
but
this
is
actually
transaction.
You
know
you
send
a
request
to
the
server
server.
Actually
we
are
actually
you
know
using
some
existing
contemplator
to
actually
merge
you,
the
the
range
into
the
one.
Actually
all
happened
in
the
server
side.
Actually
you
reduce
overhead
on
the
client
side.
E
Robertson,
cisco,
so
I'm
still
not
convinced
that
this
is
that
this
particular
use
case
is
actually
a
problem.
I'm
not
convinced,
there's
a
scale
issue
in
terms
of
configuration
here.
Even
you
split
out
the
number
of
e
lands
over
and
there
are
hundreds
of
interface
and
then
I
still
think.
The
amount
of
config
is
gonna,
be
a
10k
20k,
something
that
would
be
small
in
terms
of
mister
size
and
I'm
consuming
it.
So
don't
I'm,
not
convinced
by
that
aspect.
E
That's
a
problem
here
to
be
solved
in
terms
of
if
you
want
operations
to
do
more,
advanced
feed,
a
manipulations,
ie
breaking
tags
or
inserting
tags
into
into
particular
strings.
For
example,
then,
yes,
that's,
okay,
but
I.
Think
of
those,
maybe
just
be
our
pcs
potentially
on
a
VLAN
model,
is
how
I
wouldn't
prevent
those.
So
then,
coming
back
to
the
general
inline
actions,
I'm
still
sort
of
conflicted
is
where
this
is
a
good
thing
to
do.
E
I
think
this
more
generally
is
about
transactions
and
saying
I
want
to
give
a
sequence
of
events
to
the
server
as
one
transaction
effort
to
perform
all
of
these
things
and
either
succeed
or
fail.
So
that's
the
the
guys
I'd
look
at
this
problem,
rather
than
just
adding
actions
into
configuration
requests,
but
even
with
that
I
still
question
whether
that's
a
useful
thing
or
not,
I'm
not
I'm,
not
convinced.
This
is
a
problem
to
be
solved
at
this
stage.
R
But
a
you
say
that
you
don't
know
we're
giving.
Actually
we
use
a
edit
configure
the
exam
preview.
You
know
you,
you
really
modify
the
VLAN
tag
around
you
to
the
merger
and
a
split.
Actually
you
may
need,
because
you
may
operate
on
some
list
that
leads
to
the
P
key
index
cannot
be
deleted,
so
you
have
several
disk
rider
Renny
up
to
you,
so
you
need
to
you
know,
delete
several
discs
where
the
rent
arranger
first
and
then
you
create,
then
a
new
range
with
logic,
rent,
rent,
rent
rent.
E
Okay,
so
that's
a
different
problem
potentially
to
solve
and
I
think
again,
I
think
need
to
look
at
the
data
model
that
you're
talking
about
so
the
one
I've
been
through
right,
if
doesn't
have
that
issue,
as
in
the
VLANs
interest
information
on
a
sub
interface,
so
it's
not
actually
something
where
you
have
this
concern.
It's
just
manipulating
that
string
and
the
ability
of
a
client
to
mangle
VLAN
IDs
into
string
is
it's
probably
bored
beyond
trivial.
E
To
do
I
mean
it's
that's
an
easy
thing
to
solve,
so
it
might
be
that
your
data
model
is
different
and
then
hence
there's
a
different
requirement.
Commentary
from
that
so
I'm
happy
to
look
at
what
your
specific
data
model
is
to
see
what
the
changes
was
different
yeah.
We
do
have
such
a
model.
We
can.
A
R
The
case
would
give
actually
maybe
it's
kinda
imitates,
but
we
really
want
to
generalize
this
idea.
The
general
idea.
Actually,
we
can
provide
the
pankration
for
Nanticoke
for
protocols,
you
know
so
you
can
actually
improve
and
then
copy.
If
you
shouldn't
say-
and
here
we
gave
the
Gaddafi,
the
VLAN
tag
arrange
a
value.
The
value
actually
is
interval
type
type.
Maybe
there's
some
other
case
actually
in
an
attacker
value
actually
is
is
a
string
type,
and
you
also
do
this
a
bit
emerges
operation
you
know.
R
So
what
other
use
case
would
you
have
in
some
case
where
you
haven't
bring
bring
up?
Actually,
so
you
may
transpose
some
learn
completion
into
the
into
that
static,
congregation
or
dynamic
accommodation
data
by
the
way
we
sink
yeah.
We
we
only
you
know,
talk
about
the
focus
on
these
cases,
but
we
have
some
other
cases
with
haven't
grown
from.
R
A
B
It
going
to
Mahesh
is
coming
right
here.
If
it's
truly
just
for
ranges,
then
it
seems
like
maybe
we'd
have
to
have
a
data
type,
a
type
def
range,
and
then
this
operation
would
be
available
whenever
that
type
def
was
in
play.
It's
just
unclear
at
the
moment,
I
guess
going
to
my
hashes
last
point:
two
more
examples:
data
analysis.
It's
it's!
R
I
think
in
tension
we
we
provide
such
conservation
Cober.
We
can
generalize
this
cancer.
We
not
only
apply
to
the
input
but
also
can
apply
to
the
existing
medical
operation.
You
know
so
not
a
limit
to
to
the
you
know
the
existing
network
of
further
operation,
so
yeah
I'm
push
you.
Can
we
haven't
investigated
how
these
can
be
applied
to
that
young
boys
ship
either?
That's
that
that's
a
case.
We
think
maybe
first
we
need
to
clever
the
prominent
Space
Coast
and
then
we
can
go
into
a
tip
Oh
about
that
other
other
currency.