►
From YouTube: IETF105-NETCONF-20190722-1000
Description
NETCONF meeting session at IETF105
2019/07/22 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
Alright,
so
blue
sheets
have
been
passed
out,
make
sure
that
you
do
put
your
name
down
on
the
blue
sheets
at
the
mic.
Make
sure
you
do
pronounce
your
name
slowly
for
people
we're
trying
to
take
notes
in
ether
pad
which
we'll
come
to
in
a
minute
pulls
all
your
questions
on
at
the
microphone
itself,
so
that
remote
participants
can
listen
to
the
question
we,
the
chairs
at
least,
have
their
own
JavaScript's.
But
if
anyone
else
wants
to
take
lead
on
it
be
happy
to
have
someone
else
be
the
JavaScript.
A
A
A
So,
as
far
as
the
status
of
shattered
items,
the
yang
bush
suite
of
drugs-
that
are
at
least
four
of
them-
they
have
passed
IESE
and
in
the
RFC
editor
key
already.
In
fact,
they,
the
artsy
editor,
has
been
through
most
of
the
changes.
We
expect
it
to
be
an
odd
48
stay
pretty
soon
for
the
final
review
before
they
are
published
as
RFC
in
the
meeting
today,
we
expect
the
client-server
suite
of
drugs
to
be
presented.
A
A
A
A
B
C
So
there
was
a
draft
called
UDP
pub/sub.
Is
that
the
one,
your
friendship
that
was
they
working
group
adopted
draft,
but
we
unadopted
it
last
time
because
the
main
post
focus
was
actually
the
multi-stream
originator?
What
bad
draft
needs
to
do
is
to
be?
We
read
of
you
know,
brought
to
the
workgroups
again,
has
a
notice
draft.
So
if
something
like
you
did
he
notice,
so
someone
can
first,
you
know
really
submit
it
in
that
fashion,
then
it
could
be
accepted
by
the
working
group.
C
E
F
Tiny
mrs.
Hank
ever
joining
Ken's
presentation
later
and
in
that
context,
I
want
to
highlight
that
there
could
also
be
a
co-ed
call
home
because
in
the
context
we
were
present
here
that
so
I
was
like.
There
could
be
multiple
variants
off
to
doing
this
and
I'm
not
sure
if
there
should
be
across
documents
or
in
a
single
document.
C
Okay
hi
good
morning,
so
we're
gonna
be
presenting
the
suite
of
the
client-server
graphs
and,
of
course,
asthma
has
just
said
all.
But
one
has
been
adopted
working
group
item
the
last
one
HP
client-server.
We
did
attempt
to
run
it
the
adoption.
The
same
time
we
did
the
TCP
client-server
adoption.
There
was
some
pushback
from
the
HTTP
bids
chairs,
which
honestly
we
didn't
have
the
energy
at
that
time
to
pursue,
and
you
know,
because
the
focus
actually
when
we
moved
to
the
next
slide.
C
The
focus
is
on
the
first
three
drafts
that
we're
trying
to
get
them
into
working
group
last
call
as
quickly
as
possible.
So
you
know,
after
those
have
actually
achieved
last
call
status,
then
the
focus
will
shift
again
to
try
and
get
the
the
remaining
hierarchy
of
drafts
adopted
and
published.
So
that's
when
you
should
look
to
seeing
the
HTT
client-server
drafted
adopted
and
let
me
just
quickly
see
yes,
okay,
so
this
presentations
focus
is
threefold.
There's
the
crypto
types
draft,
which
will
you
know,
spend
actually
most
of
our
time
on
I.
C
Think
then
there's
the
keystore
draft
and,
lastly,
restaurant
server
draft
but
I.
So
this
presentation
actually
just
touches
on
you
know
if
you
go
back
to
that
previous
list,
it
really
just
touches
on
three
out
of
you
know.
How
many
are
we
looking
at
nine
drafts
and
in
particular
it
doesn't
talk
about
Hank,
the
trust
anchors
draft,
which
I
think
you
we
were
discussing
yesterday.
You
wanted
to
ask
a
question
about
so
maybe
now
would
be
a
good
time
to
ask
your
question
about
the
trust
anchors
draft
and
especially,
how
relates
the
TLS
draft
yeah.
F
F
There
is
core
Kampf
coming
up
formally
known
as
call
me,
and
this
is
using
DTLS
if
it's
secured,
of
course,
and
it
should
be-
and
that
will
be-
and
in
coop
and
on
the
DTS
level,
a
coop
advises
to
use
a
different
securing
basis.
You
secure
co-op,
and
that
is
a
public
rocky,
a
row
public
key
as
a
minimal
CMS
frame
as
it
was
standardized
years
ago,
and
also
we
have
this
concept
of
pairwise
symmetric
keys
that
are
pre
provision
and
both
of
these
are.
F
Suggested
methods
to
secure
co-op
by
the
coop
RFC
and
they
can
be
applied
to
to
two
levels
they
can
be
applied
to
DTLS
and
therefore,
what
extend
into
TLS,
which
is
effectively
also
done
today,
I
mean
a
lot
of
people
use
PS
case,
probably
known
as
pre-shared
keys.
We,
like
the
term
pair
where
pairwise
symmetric
key
and
the
rob
public
key,
of
course,
is
a
little
bit
different
than
the
SSH
key
material.
F
So
my
proposal
here
and
this
mic
is
true
at
these
two
flavors
like
the
raw
Papa
key
and
the
pairwise
symmetric
key
to
the
trust
or
draft
and
canned
I've
already
talking
about
so
we
are
aligned.
But
the
room
has
to
be
fine
with
this,
because
this
extends
a
little
bit
into
TLS
in
the
DTLS.
It
is
mandated
by
a
co-op
end
and
karatsu
on
the
communication
layer,
but
also
on
the
on
the
application,
as
on
the
object,
security
layer.
F
C
Great
thank
you
and
actually
to
add
to
that.
Even
with
the
TLS
straps,
I'm
the
TLS
itself,
we
primarily
think
about
certificates,
but
it
does
support
other
forms
like
PGP
and
and
pre-shared
keys,
and
currently
trust
anchor
draft
does
not
have
any
support
at
all.
For
these
things,
it's
really
in
that
we
ourselves
should
have
caught
before
and
I
would
expect
is
she
would
have
if
we
are
taking
those
drafts
last
call.
So
what
Hank
is
raising
right
now
in
the
context
of
DTLS?
D
Tim
Kerry
no
key
I,
do
have
a
question
on
this
approach,
though,
because
you
know,
there's
gonna
be
many
consumers
of
these
particular
drafts,
hopefully
right
outside
the
context
of
you
know
just
client-server
type
of
stuff.
So
here
we
have
an
example
of
Comey
and
co-op
wanting
to
augment
and
I
use
that
word
I.
Think
appropriately
here
some
of
the
work
that's
happening
in
the
keystore,
you
know
from
a
different
area.
So
is
it?
Is
it
the
approach
or
strategy
to
continually
revising
these
drafts?
D
That
is
the
universal
crypto
or
key
store
types
that
we
wanted
to
deal
with
or
or
do
we
expect
the
other
working
groups
to
use
those
drafts
or
incorporate
them
into
their
into
their
work?
And
so
I'm
just
trying
to
understand
you
know
the
difference,
because
otherwise
we'll
be
revving.
This
thing,
for
you,
know
every
every
every
use
possible
and
that's
right,
quick
gleams,
Nick.
A
So
there
is
a
second
review
of
the
set
of
drafts
sometime
later
today
or
maybe
tomorrow,
and
be
looking
for
proposals
well
from
them
to
tell
us
whether
the
approach
that
we
are
taking
allows
for
extensibility,
if
need
be,
without
necessarily
devising
these
set
of
drafts
continuously.
So
please,
if
the
framework
of
these
drafts
looks
I
could
enough,
then
other
working
groups
can
extend
the
more
models.
F
I'm
the
sing
it
again
and
addressing
the
concern
of
Perpetual
churn.
We
don't
want
that,
so
it's
basically
the
same
scope,
but
I
think
it
was
like
more
like
an
oversight
on
the
on
the
DTS
part.
So
we
are
not
not
moving
outside
TLS
and
ssh
here,
so
the
requirements
are
coming
from
the
same
document,
so
we
actually
have
the
same
skull,
but
we
are
not
completely
in
that
scope,
I
think,
and
and
beyond
that
it
should
be
different
drafts
or
formulas
of
managing
us.
D
Okay,
so
what
I
understand
what
you're
saying
Hank
is:
is
that
the
that
the
base,
what
we
would
consider
to
be
any
base
draft
that
would
come
out
of
net
mod,
will
incorporate
both
SSH
TLS
and
D
TLS
implementations,
and
then
we
kind
of
Miss
the
DTLS,
and
that
we
are
agreeing
as
a
working
group.
That
DTLS
is
a
core
secure
transport
or
for
the
IE
q,
but
for
for
for
the
work
that
we
did
right.
C
Okay,
so
I
don't
know
which
hat
I'm
using
at
the
moment,
but
this
working
group
is
primarily
focused
on
net
coffin
rest
cough
and
they
only
have
association
TLS
as
being
official
transport
bindings,
not
co-op.
Yet
sorry
Hank
and
that's
why
I
mentioned
that,
even
though
TLS
itself
actually
already
has
the
need
to
support
preacher
keys
and
wrong
keys,
it's
in
the
Tila
strap.
So
our
support
of
TLS
for
our
own
purposes
is
already
incomplete,
and
so
that's.
C
D
C
C
C
These
first
three
drafts
that
we're
focusing
on
trying
to
get
the
last
call
crypto
types
which
we're
gonna
spend
quite
some
time
discussing
today
is
so
probably
the
one
that's
going
to
take
the
longest
to
resolve
trust
anchors,
I
thought
was
resolved,
but
per
the
discussion
we
just
had
is
now
meaning
to
be
extended.
Slightly
I
actually
don't
view.
C
This
is
to
be
terribly
complicated
and
will
likely
conclude
before
the
trust
of
the
crypto
types
discussion
concludes
and
then
lastly,
there's
the
keystore,
which
is
also
on
today's
discussion,
but
thankfully
I
think
we're
at
the
end
of
the
tunnel,
and
it
is
going
to
move
forward
quickly.
Okay,
so
back
to
this
slide
again
and
I'll.
Just
move
on
that
I
think
so,
let's
begin
the
first
discussion
about
crypto
types
and
algorithm
identities,
strategy
I'd
like
to
invite
my
co-authors,
Michael
and
Frank.
C
Sorry,
what
will
hang
and
Frank
know
just
just
how
long,
okay,
great
all
right
so
so
first
I
mean
it
set
up
and
then
transfer
okay.
So
the
high-level
decision
that
we're
needing
to
make
right
now
is
whether
or
not
we
stay
the
course
or
simplify.
The
current
approach
with
crypto
types
is
to
unify
all
the
algorithms
produced
by
disconnected
security
area
efforts.
So
there's
lots
of
working
groups
within
the
security
area
and
each
of
them
are
defining
crypto
algorithms
that
are
effectively
the
identical
kinds
of
things,
but
they
give
them
different
names.
C
They
create
different
IANA
registries
having
different
numbers,
Regiment
assigned
numbers
to
them,
which
is
you
know,
convenient
because
you
know
the
each
is
in
their
own
protocol,
but
here
we're
trying
to
define
a
unified
layer,
this
keystore
layer
it
needs
the
store
keys
that
can
be
used
by
any
protocol.
So
we
get
ourselves
into
this
problem
space
where
we're
trying
to
unify
the
set
of
you
know,
algorithms
identities
or
enumerations,
or
whatever
we're
using
that
can
span
the
gamut
of
all
these
different
protocols.
That's
the
fundamental
problem
that
we're
dealing
with
right
now.
C
Solving
this
problem
is
the
right
thing
to
do,
but
it's
difficult
and
as
Mahesh
just
mentioned
a
moment
ago,
last
week
the
chairs
did
request
an
early
sector
review.
We
were
rough,
it
was
assigned
and
we
had
a
call
with
him
last
week
and
then
just
I
heard
over
email
that
the
topic
was
raised
in
the
isg
discussion
on
Sunday
and
now
someone
Michelle
from
Ayane
has
been
asked
to
have
a
meeting
with
her
FET
and
the
author.
Sorry,
the
chairs,
in
order
to
try
to
discuss
what
the
next
step
is
to
do.
C
G
Yes,
this
was
discussed
briefly
at
AG
sandy
meeting,
and
the
outcome
of
that
is
that
there
is
no
outcome
at
this
time
right
and
what
is
needed
is
that
probably
this
working
group
needs
to
think
of
what
what
of
the
possible,
what
of
the
proposed
options?
Either?
We
don't
have
a
registry
but
put
a
half
coded
values
into
into
the
documents,
and
we
spend
that
every
time
I
have
a
unified
registry
which
is
on
an
aside
or
have
something
in
between.
G
C
Right,
okay,
perfect
and
that's
the
set
up
for
the
the
last
line
here.
The
arthur's
wish
to
see
this
approach
play
out
again.
It
is
the
right
thing
to
do,
but
we're
beginning
to
think
about
fallback
strategies.
So
this
discussion
number
one
right
here-
is
to
first
try
to
talk
about.
What
is
the
you
know
how
we
can
the
current
approach,
the
right
thing
to
do
and
how
what
we
can
do
to
make
it
complete
and
insult.
H
Yeah
good
morning,
everyone,
my
name,
is
aqua
from
Maui
cooler
of
this
IKEA
abstract,
quick
to
attack,
Everest
yeah
I
mean
help
in
these
crystals,
my
identifiers,
so
in
this
style,
I
will
give
some
background
on
the
crypto
type.
Crypto
errors,
my
identifiers
yeah.
Initially
we
used
identity
too
and
by
issue
security.
Everything
like
like
the
upper
yeah
in
the
upper
figure
yeah
for
each
security
algorithm.
We
give
a
name,
and
we
give
a
description
that
is
and
so
on.
We
classify
them
into
a
few
categories.
H
For
example,
we
have
a
hash,
algorithm
and
symmetric
encryption,
algorithm
and
asymmetry.
Swaps
also
change,
but
later
actually
some
expert
from
I
to
intercept
the
they
have
some
suggestion
that
maybe
enumerate
type
could
be
better
because
it
is
simple
to
management
and
also
when
new
algorithms
designed,
we
can
simply
add
a
single
value
in
the
irony.
I
any
and
yeah
I've
seen
from
different
group,
can
refer
to
the
alien
in
the
practical
definition.
H
So
after
that,
in
the
recent
draft
we
change
to
the
new
style
in
the
enumerate
format
and
future
crypto
I
will
indeed
our
value
field.
You
have
to
identify
these
areas
yeah,
but
details
can
be
looked
into
that
can
refer
to
the
destructor
10.
So
this
on
my
tangible
contribution
on
these
crypto
algorithm,
yeah,
actually
I
have
some
personal
observations
or
the
Critical
recently
used
the
unity
of
it.
H
The
figure
below
shows
the
algorithm
from
two
groups:
vines,
TOS
wines,
SSH,
so
different
group
and
the
different
apps.
He
has
your
own
style
in
different,
defining
crypto
algorithm,
for
example,
human
for
the
TOS
1.21
3,
that
the
definition
is
different.
So
this
brings
a
lot
of
effort
for
the
app
see
editor
designers
had
to
define,
review,
implement
I
manage
data
I
wish.
So
usually
they
are
going
to
be
using
a
real
system.
So
I
think
there
are
lots
of
additional
maintenance.
Work
has
to
be
done
the
year.
H
Also
so
peace
and
ease
operation
I
have
some
question.
Yes,
we
come
up
with
a
unified
framework,
for
example,
initially
star
or
any
piece
for
crypto
algorithm
identifiers,
so
that
they
can
be
shared
among
different
groups
and
abscess.
For
example,
we
can
classify
the
crypto
algorithms
into
a
few
categories
and
can
assign
unique
number
to
each
of
them,
and
so
other
artists
in
the
future
can
refer
to
this
this
list
and
do
not
need
to
specify
the
house
absolutely
identified
by
themselves.
It's
just
a
simple
reference
yeah.
H
C
So
the
I'm
speaking
of
better
methods-
this
is
what
I
was
saying
or
what
my
discussion
with
Hank.
You
were
talking
about
Cozy
and
how,
when
this
is
the
encryption
of
JSON
documents
right
and
and
when
that
that
draft
became
RFC,
the
it
registered
a
bunch
of
I
Ana
registries,
is
it
they
actually
I
in
a
red
shades,
and
they
they
cover
a
large
number
of
cryptographic.
Algorithms
I
think
your
proposal
was
that
we
might
be
able
to
leverage
that
work.
Yeah.
F
This
is
Hank
again,
it's
it's
a
it's
for
cozy
or
the
variation,
but
Jim
shot
is
the
expert
on
this
registry
and
he
that
all
the
groups
there
are
other
participants
there
in
the
group
did
an
awesome
job.
It's
keep
my
perimeter
zits,
its
curves
is
hashing
its
signatures,
its
crypto,
and
it's
always
in
combination
that
only
the
safe
only
done
with
the
basics,
but
but
the
combination
of
key
strengths,
and
so
it's
very
elaborate
eye
on
our
registry.
F
Already
there
it's
pretty
much
I,
don't
want
to
like
to
say
complete,
but
it's
very,
very
detailed
already.
So
this
could
be
another
wave
maintained
source
for
everything
crypto
ago
I'm,
not
saying
that
is
complete
for
your
scope,
because
it
prunes
some
of
the
very
old
stuff
and,
of
course,
of
the
deprecated
things.
But
it's
the
best
maintained
come
a
Anna
I
know.
Actually
so
maybe
yeah.
I
Frank,
sorry
Howard
our
interests
and
general
question
about
this
kind
of
thing.
Thank
you
that
you
have
mentioned
that
for
the
Cody
for
the
world.
For
this
technology
we
have
a
very
complicated
crypto
algorithm
on
a
page
right.
So
what
is
the
relation
with
this
new
and
the
pager
and
the
with
the
existing
and
a
pager
for
the
TRS
for
IPSec
and
SSH?
And
what
is
your
future
plan
of
how
to
align
with?
And
you
know
this
is
a
very
important-
the
problem.
F
Yes,
I
think
again,
this
is
not
resolved
yet
so
we
have
either
the
option
to
choose
in
the
module
where
to
go
to,
but
this
can
be
very
confusing
and
it
would
require
a
lot
of
implementation
and
complexity.
So
that's
usually
a
bad
idea,
but
but
if
they're
gaps-
and
if
you
see
maybe
an
assessment
of
the
tables-
is
an
order-
your
your
Lea
TLS
based
so
busy
that's
the
way
to
go.
You
cannot
something
wrong.
There
I
think
from
the
yang
of
things
point
of
view.
We
could
just
document
that
and
put
a
futsal.
F
I
And
my
my
personal
comments
is
that
it's
not
the
responsibility
of
the
individual
or
group
chapter
to
mention
or
to
reflect
the
latest
update
of
crude
origin.
I
hope
that
those
I
know
pages
can,
you
know,
can
be
aligned
with
each
other.
They
take
care
of
this
kind
of
thing
and
we
just
reference
to
them.
I
think
that's
the
best
way
for
not
only
for
our
tracks
or
maybe
for
future
on
another
draft
right.
I
know
you
take
care
of
that
moto
2
or
this
kind
of
thing.
So
maybe
thank
you
and.
I
C
Great
well
you're
right,
so
this
is
definitely
a
good
resource
for
us
to
look
at
and
in
terms
of
potentially
using.
You
know,
folding
some
of
those
ideas
into
what
we're
trying
to
achieve.
With
this
approach
and
to
Frank's
very
last
comment
exactly
I
think
that
we
currently
the
crypto
types
draft
defines
one
IETF
module
and
really
we
should
be
thinking
about
breaking
it
up
too
many
Anna
modules.
C
So
you
know
this
is
of
course
assuming
we
stay
the
course
with
this
approach,
but
you
know
twofold:
first,
assigning
to
I
Anna
allows
IANA
to
update
the
modules
outside
the
standard,
RFC
cycle.
I
think
this
is
important
and
probably
what
Frank
was
just
saying,
although
I
there
may
be
some
disagreement
just
extent
that
I
Anna
will
actually
be
updating
the
modules
outside
the,
but
we
need
to
figure
that
out,
but
that
would
be
the
intent
is
to
allow
them
to
be
able
to
make
those
updates.
C
So
as
and
when
any
security
area
group
defines
an
extension,
a
new
protocol,
a
new
addition
to
registry
automatically,
the
yang
module,
would
be
updated
and
published
by
Anna,
not
us.
Secondly,
breaking
it
up
into
many
modules
enables
each
to
have
a
better
focus.
You
know
as
a
so
it's
unclear
to
me
actually
how
important
this
particular
point
might
be,
but
it
does
seem
like
it
would
be
favorable
to
especially
Anna
if
they
were
being
asked
to
maintain
them.
Yes,
question
Wilson.
J
C
The
many
though
it's
the
second
bullet
point
so
again
as
unclear
to
me
how
important
it
may
be,
but
it
to
myself
like
well
like
programmatically.
It
doesn't
matter
but
from
a
maintenance
perspective,
especially
for
asking
Anna
to
do
the
maintenance.
It
could
be
helpful
to
them
that
then
it's
been
broken
up
too
many
modules
and
either
case
it'd
still
be
one
draft
like
so
this
draft
the
crypto
type
draft
would
continue
to
be
the
draft
that
would,
you
know,
create
all
these
month.
J
C
Quantity,
yes,
it'll,
be,
for
instance,
a
module
that
be
for
symmetric,
key
algorithms,
another
module
for
asymmetric
key
algorithms,
another
module
for
hashing
algorithms.
If
it
makes
sense
to
do
this
it
you
know
to
break
up
that
way.
Okay,
all
right!
So
again,
so
we
would
continue
using
this
trap.
Okay,
so
the
fallback
strategy.
This
is
you
know
in
case
we
don't
stay
the
course
and
we
wish
to
simplify
the
and
I
did
post
this
to
the
mailing
list.
There
was
no
response,
but
so
here
we
are
going
to
go
over
it.
C
The
general
idea
is
to
admit
that
TLS
is
the
transport
layer
for
most
protocols.
Right
I
mean
in
reality
like
on
the
network,
and
imagine
us
you
know
outlining
ourselves
to
a
more
TLS
oriented
solution.
A
TLS
protocol
is
heavily
defined
using
asn.1
structures
right.
If
you
look
to
RFC,
5280
you'll
see
nothing
but
a
ascend
one
in
there,
which
is
how
you
then
wind
up
with
things
like
pin,
which
will
not
pin,
but
during
coding
and
burr
and
coding,
you
know
in
particular,
or
even
pin
they're
all
effectively
encodings
of
asn.1
structures.
C
Already
crypto
types
draft
defines
many
a
and
ASN
ones
types,
so
there
are
types
for
in
particular,
CMS
structures,
so
sign
data,
encrypted
data
and
just
plain
seamless,
there's
actually
six
or
seven
CMS
types
that
are
defined
there.
Three
of
them
I
think
are
used
directly
by
these
zero-touch
draft
and,
of
course,
having
them.
You
know
in
the
crypto
types
track,
so
actually
zero
I
should
say:
zero
touch,
copy-pasted,
it's
the
same
tax
dues,
but
to
get
the
zero
touched
out,
the
door
didn't
actually
have
a
normative
reference
to
crypto
types.
It's
just
so.
C
Anyway,
it's
an
same
idea.
It
would
be
valuable
for
the
crypto
types
draft
to
have
those
asn.1
types
to
find
in
it.
So
why
not
add
one
more
a
that
one
type
to
it
in
in
particular,
RC
59-58
defines
what
they
call
one
a
symmetric
key,
it's
a
strange
name,
I
know,
but
the
title
of
that
draft
is
asymmetric
key
packages
and
if
you
look
there
at
the
ASN
dot
one
at
the
bottom
of
the
screen,
you'll
notice
that
it
has
private
key
algorithm,
private,
key
algorithm,
identifier,
right
and
so
already
they've
somehow
solved.
C
The
problem
of
the
roulette-
you
know
all
the
different
identifiers
z'
that
can
be
used
and
how
to
refer
to
them
when
encoding
a
s
and
that
one
dot
structures
so
exactly
notice.
This
private
key
identifier,
if
you
dig
a
little
bit
deeper,
you'll,
see
private
key
identifier
is
an
algorithm
identifier
and
if
you
dig
into
that
you'll
see
that
this
algorithm
is
identified
by
an
object.
C
You
know
an
ID
and
then
you
try
to
figure
out
what
that
is,
and
you
don't
quite
I
think
that
ultimately
maps
to
an
Dianna
registry
I
tried
to
find
it.
I
couldn't
find
it
so
I
kind
of
bottomed
out
at
that
point.
But
you
get
the
idea.
They've
tried
to
solve
they.
They
have
solved
right
because
it's
running
code
we
just
need
to
figure
out
how
it's
being
done
so,
but
then
what
is
an
open,
SSL,
private,
key
and-
and
you
know,
I
kind
of-
is
I.
C
Think
some
of
you
know
I've
written
two
lists
I'm
in
the
process
of
it,
creating
a
restaurant
server
and
it
does
implement
this.
It
does
use
IETF
restaurant
server,
which
means
the
entire
hierarchy
and
down
to
key
store
and
trust
store,
and
all
this
and
I'm
trying
to
write
code-
and
the
simplest
thing
for
me
to
do
is
use
open
SSL.
You
can
see
the
first
command
there.
Ec
pram
I
want
to
generate
a
private
key
and
then
from
that
I
want
to.
You
know,
generate
the
public
key
I'm,
basically
executing
open,
SSL
command
line.
C
You
know
utility
command
line
commands,
so
you
create
these
things
for
it
for
me
and
then,
of
course,
I
create
this
certificate,
signing
request
and
sign
a
certificate,
and
all
that
goes
into
trust
store.
But
what
am
I
doing?
What
am
I
putting
the
key
store
right
so
currently
we
don't
have
a
well-defined
solution
and
I'm
kind
of
just
getting
something
to
work,
and
so
I
hack
it
and
I
just
basically
put
the
basics
before
encoded,
whatever
openness,
sellout
putted
and
that
I've
stuck
into
the
key
sort,
I'm
a
lazy
programmer.
This
is
easy.
C
Everyone
will
probably
be
wanting
to
do
this.
Also,
it's
very
simple,
so
you
know
that's
the
question.
So
what
is
this
thing
that
opener
cell
is
outputting?
Is
it
and
one
asymmetric
key
I?
You
know
I
tried
to
get
a
better
parsing.
You
know,
that's
the
that's!
What
open
SSL
gave
me,
but
I
can't
quite
see
if
that's
an
a.1
asymmetric
key.
C
It
doesn't
print
out
the
oit's
so
that
were
regardless,
whatever
open
SSL
is
using
would
be
convenient
for
us
to
adopt,
even
if
it's
not
the
one
asymmetric
keys,
so
here's
something
or
or
find
a
simple
way
to
convert
between
the
two.
It's
what
we
need
to
do.
Okay,
so
that's
the
end
of
that
discussion,
but
somehow
I
feel
are
there
any
questions?
Did
anybody
have
any
questions
about
this
I
guess
maybe
I've
kind
of
skimmed
over
the
fact
we're?
No
one
raised
her
hand.
What
do
you
mean
we're
only
gonna
support
TLS?
C
What
about
SSH
SSH
is
important.
Right
I
mean
neck.
Has
a
mandatory
transfer.
Somebody
was
gonna.
Ask
that
question
right.
I
can
see
people
not
in
their
heads.
Yes,
SSH
is
important,
I,
don't
okay,
so
I,
don't
know
exactly
what
we
would
do
for
you
know
what
course
would
want
to
support
it,
but
maybe
the
SSH
client
server
draft
well,
we'll
just
have
to
figure
it
out.
I
mean
I'm,
sure
there's
a
way
of
getting
to
it.
It
may
be
so
choice
and
then
inside
the
choice,
it's
it's.
C
What
one
asymmetric
key
is
the
one
option
with
a
choice,
and
the
other
option
is
Joyce
is
something
we
make
up.
It's
very
SSH
oriented
and
support
SSH,
so
we'd
find
a
way
to
to
an
you
know,
carry
forward
ssh
support,
but
primarily
the
intent
would
be
that
we
were
focusing
on.
Tell
us
that
make
sense.
Okay,
that's
the
end
of
discussion,
one
no
more
questions!
Thank
you.
C
The
goal
is
to
enable
manufacturers
to
ship
devices
with
I,
divided
II
certificates
or
any
you
know,
cryptographically
secure,
identifying
certificate,
I
divided
II
is
just
a
particular
one,
but
any
this
implies
that
the
associated
private
keys
are
hidden
because,
if
you're
shipping
a
device
with
a
forever
certificate,
you
need
that
private
key
to
be
forever,
and
you
know
if
it
were
ever
exposed
to
be
not
it'd,
be
disastrous
effectively,
so
store.
You
know,
generating
and
storing.
C
So
that's
one
goal
so
having
this
ability
to
support
devices
ship
for
manufacturing,
with
key
stores
that
have
values
in
the
operational
data
store
that
contain
private
key
and
associated
certificate
for
Ida
bit
easier
tickets.
Secondly,
is
to
enable
devices
to
generate
keys
again.
This
is
a
best
practice.
Generally,
you
don't
want
I
mean
many
people
do
create
private
keys
and
then
upload
them
to
a
device,
but
best
practice
is
you
ask
the
device
create
the
private
key
for
you
and
and
hence
the
private
key
itself?
Never
left
left
the
device.
C
C
So,
even
though
you
want
the
device
engine
right
keys,
sometimes
it
has
to
be
the
case
you
generate
keys
outside,
but
once
you
load
them
onto
the
device
you
want
them
to
be
treated
as
effectively
hidden
protected
so
that
they
can
never
be
discovered
or
figured
out
from
that
point
forward,
and
you
know
some
people
might
claim
you
can
use
NAC
em
for
this,
you
know,
just
you
know,
have
a
habits
that
only
the
root
user.
The
restore
session
user
can
can
access
that
key.
C
But
even
then
it's
not
quite
what's
being
asked
for
here
when
they,
when
people
ask
for
these
forever.
Hidden
keys
for
is
to
support,
standard
backup
and
restore
interactions
so,
to
the
greatest
extent
possible
we
want
keys
that
are
being
created
or
loaded
or
hidden
or
whatever
to
be
part
of
config.
C
C
The
implicit
statement
here
is
that
these
hidden
keys
can't
be
they
need
to
be
in
config,
even
though
they're
hidden,
they
need
to
be
in
config
and
and
the
sort
of
the
punchline
here
is
that
need
to
be
encrypted
so
they're
in
config
but
they're
encrypted.
So
that's
what
we're
getting
to
and
then
v
don't
have
keys
and
running
with
values
only
and
operational.
So
this
is
say
some
people
are
talking
about.
C
If
you
have
a
value,
a
key,
that's
in
operational,
but
you
want
to
use
it
in
configuration,
just
create
a
proxy
in
configuration
that
has
the
name,
for
instance,
I
handled
to
it,
but
the
rest
of
it
is
missing.
This
is
kind
of
problematic
from
the
gangue
module
design
perspective,
because
it
you
know
whether
or
not
that
the
key
values
are
mandatory,
true
versus
and
mandatory
false.
It's
there's
lots
of
great
properties
that
you
get
if
the
values
are
always
mandatory.
True,
okay,
so
several
strategies
have
been
tried.
C
You've
probably
noticed
that
you
know
we
published
the
full
suite
of
clients
who
are
drafts
three
times
since
ITIF
the
last
IDF.
First,
we
tried
having
action
statements
that
created
values
and
operational
which
had
you
know,
benefits
of
generally,
following
the
rule
about
how
actions
you
know,
create
values
or
are
executing
the
context
of
operational
data
store.
But
the
cons
were
that
you
needed
to
copy
the
values
into
running
in
a
way
that
was
really
complicated
and
we
it
never
was
really
nice
user
friendly.
C
Then
we
switched
to
an
approach
where
we
were
trying
to
encode
trips
hash,
like
values
into
the
configuration
this
had
the
benefit
of
all
the
values
for
in
running.
But
the
downside
is
that
then
we
were
encoding
verbs
into
the
values,
so
the
values
themselves
encoded
like
a
verb
requesting
the
device
to
actually
generate
the
key
which
was
considered
unacceptable
and
then.
Lastly,
we
went
with
this
I'm
calling
disconnected
our
PCs,
but
I
only
mean
to
say
that
they
have
no
data
store
effect
like
the
execute
the
RPC.
C
It
returns
an
output
value,
but
it
itself
has
no
effect
on
any
data
stored,
not
operational
and
not
config,
nothing.
Instead,
the
client
that
receives
the
output
needs
to
round-trip
and
return
back
to
the
device.
The
generated
key
to
wherever
it
wanted
that
key
to
be
located
so
Pro
is
that
it
satisfies
all
the
use
cases
it
seems,
and
especially
wouldn't
you
include
the
fact
that
the
output
can
be
encrypted.
That's
the
main
thing,
but
the
con
is
that
round-trip
I
just
mentioned.
C
Nonetheless,
number
three
appears
to
have
traction
and
I
just
want
to
go
into
that
just
a
bit
more.
Just
so
it's
clear
so
in
crypto
types
we
have
grouping.
So
again,
this
is
a
crypto
types,
the
the
previous
draft
we
were
talking
about.
We
have
two
groupings,
symmetric,
key
and
asymmetric,
key
and
notice
that
there's
a
choice,
key
type-
and
it
has
two
two
Leafs
one-
is
just
simply
key
binary
that
B
or
your
ciphertext
I.
Sorry,
your
your
clear
text
key.
C
So
the
actual
key
values
themselves
are
at
raw
and
visible
and
then
there's
another
type,
hidden
key
which
is
of
type
empty,
and
so
it's
just
an
empty
value
and
then
now
in
key
store
draft.
We
have
some
groupings,
so
we
start
with,
on
the
left
hand,
side
key
reference
type
grouping
which
is
you
know
we
have
this
choice
of
two
different
kinds
of
T
type.
Key
types
is
that
are
you
referring?
Are
you
referencing
a
symmetric
key
or
a
nice
symmetric
key?
C
So
the
key
so
what's
happening
is
that
there's
there's
a
value
so
there's
a
binary
string
and
there's
a
leaf.
That's
referring
to
the
other
key
that
it
was
encrypted
by
and
of
course,
we
do
the
same
thing
for
a
symmetric,
key
store
and
then,
lastly,
there's
to
our
pcs
one
for
generating
a
symmetric
and
asymmetric
key
they're
identical,
except
for
you
know
basic
names
in
the
input
you
can
pass
optionally
in
encrypted
with
parameter.
So
you
can
ask
the
device,
yes
generate.
C
A
key
for
me
with
you
know,
said
algorithm
properties,
and
but
when
you
return
it
to
me
encrypt
the
output
value
using
this
other
key,
that's
already
in
the
key
store
and
I'm
referring
to
it,
and
then
you
get
back
an
encrypted
key
from
the
actual
data
model
perspective.
You
can
see
I'll
just
go
through
one
of
these,
but
they're
effectively
the
same
asymmetric
keys,
and
now
you
can
see,
there's
the
the
private
key
and
there's
these
three
types,
the
private
key,
hidden,
private,
key
and
encrypted
private
key
right
and
then
underneath
encrypted
private
key.
C
There's
that
leaf
ref
to
another
value
in
the
key
store
and,
of
course,
the
the
ciphertext
value
of
the
encrypted
key.
So
how
does
this
work
an
example?
So
you
start
you
know
at
the
top.
We
have
TPM
protected
keys,
so
this
would
be
a
key
if
you
look
on
the
left
hand,
side
a
special
key
shipped
with
the
device
used
to
encrypt
the
operators
key.
So
let's
jump
to
the
bottom,
we
have
a
symmetric
key,
which
is
the
operators
encrypted
key.
C
So
this
would
be
a
special
key
used
to
encrypt
all
other
keys
installed
by
the
operators.
Crypto
officer
right,
so
every
operator
might
have
a
secret
symmetric
key
that
only
its
crypto
officer
knows
and
at
any
time
they
want
to
bring
up
a
new
device.
They
encrypt
that
symmetric
key
using
the
device
specifics,
a
symmetric
key,
the
one
sword
in
the
TPM
and
then
lastly,
in
the
middle
there
you
have
a
generic
key
which
could
be
you
know
any
key
that
might
be
used
by
TLS
or
SSH
for
your.
You
know
any
other.
C
That
key
has
then
been
encrypted
by
the
operators
key,
so
this
satisfies
the
goals
that
we
showed
before,
enabling
manufacturers
to
ship
devices
with
it
was
their
certificates.
So
now
we
have
both
of
those
they're
in
operational
of,
but
also
they
could
be
in
factory
default.
There's
another
draft
and
going
through
net
mod
about
a
fact
our
new
factory
default
data
stores,
so
absolutely
they
could
be
in
factory
default
as
well,
and
the
private
key
is
being
reported
with
value
hidden
and
empty
type.
So
this
satisfies
that
goal.
Enable
devices
generate
keys.
C
So
now
we
have
this
RPC
to
generate
the
keys
and
the
client
can
decide
whether
not
the
key
is
encrypted
enabled
clients
to
install
subsequently
hidden
keys.
So
here
the
client
can
set
using,
for
instance,
at
a
config
in
encrypted
key,
but
so
it's
actually
not
hidden
I
mean
the
use
case.
The
goal
is
to
that
they're
hidden,
it's
not
actually
hidden,
it's
better
than
hidden
it's
encrypted,
and
it's
in
configuration
so
still
in
configuration,
which
means
it
can
support,
backup
and
restore
interactions
which
is
number
four,
so
all
keys,
except
for
hidden
keys.
C
The
truly
hidden
keys
that
want
the
ones
that
were
shipped
for
manufacturing
are
in
fact
reported
in
configuration.
So
you
do
get
config
and
you
get
them
and
of
course
the
RMA
procedure
can
migrate
the
operator
wide
key
and
then
all
the
other
keys
that
were
used
in
you
know.
The
99
percent
of
the
configuration
are
then
migrated
to
the
new
device
and
in
five
we
don't
have
keys
and
running
with
values
that
are
only
an
operational.
Is
that
awkward
ATM
that
we
have
currently
all
the
keys
are
mandatory?
C
True
and
then
we
do
have
an
open
issue
related
to
that,
though,
so
we're
reporting
all
key
values
and
factory
default
and
running,
should
the
algorithm
or
public
he
knows
be
suppressed.
So
this
saves
an
open
issue
because
Martin
I,
don't
think,
is
on
the
on
the
online
raised.
This
continues
to
raise.
This
is
a
potential
concern.
So
that's
why
I'm
trying
to
address
it.
I
personally
I
think
that
it's
better
for
those
values
to
be
there,
because
the
pros
are
that
the
yang
model
is
best
stating
that
all
the
fields
are
mandatory.
C
True,
we
tried
the
mandatory
fall
approach,
got
really
complicated
and
I
didn't
see
any
value
to
it.
Furthermore,
there's
no
harm
in
reporting
these
values.
The
public
key
is
public.
It's
okay.
If
people
see
it,
you
can
report
it.
The
cons
is
that
the
values
only
have
to
be
reported
and
operational,
so
it's
unnecessary,
so
I
admit
technically
speaking,
they
don't
have
to
be
reported,
so
we're
having
something
more
than
necessary
and
then
also
con
Martin
points
out.
It
seems
like
special
case
handling.
That's
true,
but
I.
C
Don't
think
this
is
really
an
issue
and
the
reason
why
is
because
I
actually
think
this
is
something
that
needs
to
be
embraced.
So,
firstly,
number
one:
it's
already
the
case
the
server
has
to
handle
has
to
have,
you
know,
quote
special
handling
for
the
hidden
key
type.
So
there
really
is
no
such
thing
as
hidden
key
there's,
actually
a
value,
a
real
value
and
operational.
C
Already,
the
devices
have
to
have
special
handling
to
understand
this
notion
of
a
hidden
key.
So
I,
don't
actually
you
know
in,
for
instance,
when
you're
doing
an
edit
config
and
there's
a
value
of
hidden
key
the
when
the
device
is
actually
trying
to
commit
that
config
we're
not
actually
telling
it
to
delete
the
algorithm
in
public
like
if
for
if,
if
the
algorithm
public
keys
were
missing
and
we're
only
passing
hidden
key
we're
not
actually
telling
it
delete
the
algorithm
public
key
can't
do
that,
it'd
be
illegal.
C
So
already,
there's
special
keys
handling,
that's
going
on
and
so
I
think,
there's
asking
it
to
don't
actually
modify.
So
if
we
were
to
pass
the
algorithm
public
key
and
instead
the
special
case
handling
is
don't
actually
modify
in
case
the
client
tried
to
change
the
values.
You
know,
don't
actually
try
to
change
the
values
that
wouldn't
make
sense.
Instead
throw
an
error.
I
think
it's
it's
just
special
case
handling
of
a
different
kind.
C
So
I
don't
see
that
as
a
bad
thing
and
then
number
two
I
actually
think
it'd
be
better
to
define
an
annotation
of
some
sort
metadata
that
could
be
used
generically
to
identify
nodes
that
are
effectively
read-only.
I.
Think
that
you
know
such
a
annotation
could
be
used
in
many
other
use
cases
outside
of
this
use
case
and
in
particular,
you
think
about
scheme
amounts
where
you
might
have
some
data.
C
That's
that
you
know
it's
it's
in
the
host
system,
but
it's
been
shared
to
a
virtual
system
effectively
that
data
is
read
only
in
the
context
of
the
virtual
system.
So
when
the
the
virtual
system,
you
know,
if
you
do
get
configure
in
the
virtual
system,
you
get
the
value,
but
you
don't
there.
Currently,
it's
not
flagged
in
a
way
that
indicates
that
that
value
is
effectively
read
only
in
the
context
of
the
virtual
system.
C
So
you
know
something
like
a
an
annotation
that
could
flag
this
algorithm
and
and
public
key,
and
you
know
even
hidden
key.
Those
three
values
is
basically
being
read-only
would
be
perfect
for
this
use
case,
though,
we
could
embrace
and
extend
this
idea
to
support
that
as
well.
Opener
she's
continued
RMA
required
a
special
new
step.
I
spoke
to
this
just
a
moment
ago,
but
I
go
in
just
a
level
deeper.
C
Assuming
operators
follow
what
would
be
effectively
become
best
practice,
which
would
be
to
create
this
operator
wide
symmetric,
key,
that's
encrypted
on
each
device
using
the
devices
hidden
key
and
subsequently
used
to
encrypt
all
the
other
keys.
That's
the
best.
What
we
effectively
be
saying
is
new
best
practice.
All
operators
should
try
to
follow
that
approach.
C
If
possible,
then
the
RMA
process
would
change
from
what
you
know
currently
is
today
load
the
config
from
the
old
device
and
then
do
whatever
additional
customizations
are
necessary,
such
as
installing
any
node
lock
licenses,
and
it
actually,
probably
that
might
be
out
of
order.
You
might
actually
have
to
install
a
node
lock
licenses
before
you
try
to
load
the
config
on
some
devices,
so
that
will
change
is
a
little
bit
to
a
new
approach
which
would
be
to
manually
install
the
encrypted
operator
wide
key
on
the
new
device
and
then
edit,
the
config.
C
You
know
from
the
old
device,
so
you
did
a
get
config
from
the
old
device
edit
it
just
a
little
bit
to
delete
the
upgrade
or
wide
key
value
that
was
there
there
in
the
key
store,
just
delete
it
and
then
save
it,
and
then
let
that
be
the
resulting
file
that
you
load
onto
the
new
device.
That's
number
three
loaded
onto
the
new
device
and
then
lastly,
do
these
additional
customizations,
such
as
installing
your
node,
lock,
license
keys.
I!
Think
that's
it
for
this
discussion.
Are
there
any
comments
about
this
again?
J
Robertson
Cisco:
is
it
safe
to
have
a
single
operator
wide
symmetric-key
I
mean?
Is
that
good
security
practice
in
the
sense
of
if
that
key
gets
compromised?
Do
you
then
effectively
compromise
all
the
vices
and,
if
so,
with
these
schemes
to
work,
if
rather
having
a
single
operator
wide
symmetric
key,
they
were
managing
separate
keys
for
each
device.
So
when
you
are
a
it,
you
use
what.
C
The
kids
didn't
find
that
sure
you're
right.
It
could
be
the
case
that
it's
a
per
device
symmetric
key,
not
not
operator
wide
you're
right.
It
could
be
it
just
be
more
maintenance.
Each
operator
had
to
remember
what
was
the
symmetric
key
I
used
before,
but
yeah
it
could
be
done.
So
that's
their
choice,
though
that's
that's
their
choice
and
and
again
I
mentioned
crypto
officer,
and
so
again
we
kind
of
push
it
to
them.
Push
the
problem
to
them.
One
solution
would
be
a
per
device
symmetric
key.
C
Another
solution
would
be
to
design
some
code
that
the
symmetric
key
itself
has
being
stored
inside
a
TPM
of
some
sort,
and
then
they
develop
a
client
that
basically
does
a
handshake.
Transferring
this
symmetric
key
to
the
new
device
in
a
way
that
the
crypto
officer
actually
never
was
in
was
never
revealed
to
them
with
what
that
symmetric.
Key
value
was
so
that's
also
possible.
Okay,.
C
C
The
second
thing
is,
if
maybe
this
is
out
of
order
right,
but
the
second
thing
I'm
thinking
if
you
load
that
configuration
from
the
old
device-
and
it
has
a
new
definition
for
an
operator
white
key
that
would
overwrite
the
value
that
you
just
stored,
so
it
you're
kind
of
like
avoiding
that
overwrite,
so
maybe
just
train
to
order
this
load,
the
old
config
and
then
manually
overwrite
the
old
operator.
What
key?
Oh.
C
C
C
Symmetric
key
is
actually
currently
only
being
used
for
this
purpose
of
encrypting
other
keys,
in
fact
like
in
this
example,
the
data
model
up
until
the
very
last
or
most
recent
version
of
the
draft
did
not
have
this
symmetric
key
section.
There
were
no
symmetric
keys
being
stored
in
the
trust
or
the
reefs
re
in
the
key
store,
the
reason
being
that
it'd
be
foolish
to
have
the
symmetric
key
value
in
the
configuration
where
anybody
could
see
it.
C
All
all
security
properties
would
be
lost,
but
now
that
we
have
the
ability
to
encrypt
the
symmetric
key,
then
it
opens
up
the
possibility
that
the
symmetric
key
can
be
stored
safely.
So
that's
one
and
then
two
we
can
then
use
it
to
encrypt
all
those
other
keys
that
are
being,
for
instance,
used
by
Association,
TLS,
etc.
So
that's
how
it's
really
being
used
currently
but
to
Hanks
previous
comment
about
extending
the
TLS
support
and
Trust
door
to
also
pre-shared
keys
and
rocky's.
C
J
I
didn't
get
I
think
that
your
your
point
took
bottom.
The
cons
is,
it
might
be
better
to
define
annotation
to
mark
this
configurations,
read-only
the
status
read-only,
so
the
factory
default
data
stores,
read-only
by
definition
and
running,
is
controlled
by
the
client.
So
I
didn't
I
didn't
get
that
bit.
What
you
mark
is
read-only.
J
C
Actually
doing
yes,
okay,
so
remember,
factory
default
is
kind
of
like
startup,
where
it
really
is,
it's
a
place
where
you
copy
and-
and
you
initialize
running
right-
it's
the
first
running
effectively.
So
so
it
becomes
running
and
then
you're
doing
a
get
config
on
running
and
that's
when
it
would
be
helpful
for
there
some
people
to
know
that
this
is
actually
a
read-only
value
kind
of
like
we
need
ooh
with
defaults,
you're
being
told
this
is
actually
a
default
value.
J
C
B
J
C
Oh,
this
is
something
it's
already
and
running.
I.
Don't
need
to
create
it
again,
but
to
balázs
is
point
it
be
actually
helpful
if
they
could
be
tagged
as
you
know,
and
made
it
a
little
bit
like
with
words
and
I
tagged.
As
you
know,
this
is
actually
a
value
that
came
from
operational,
or
this
is
actually
a
value.
This
read-only.
B
Exactly
I
don't
care
if
we
called
it
running
we're
not
running
it's
a
value
that
was
discovered
from
somewhere
in
capabilities
cases,
probably
from
the
software
itself,
and
then
I
can.
Put
that
say:
must
your
configuration
must
not?
It
must
use
something
that
the
device
is
capable
of.
Currently,
you
can't
put
a
must
between
operate
or
config
falls
and
coffee.
True,
this
is
the
way
around.
J
Robots
and
so
I,
but
I
wondered
in
that
case
whether
you
want
to
be
getting
that
configuration
you
to
intended.
So
you
intended
you
I,
have
more
freedom
to
be
allowed
to
inject,
like
system
configuration
or
templates
and
things
there
is
more
freedom
there
and
that's
where
you're
doing
the
validation
so
I
still
see
that
the
ideal
for
running
is
it's
just
what
the
operator
provides.
E
C
So,
let's
flush
they're
on
the
list
again,
this
is
an
open
issue,
so
it
needs
to
be
discussed
on
the
list
and
it
I
hope
to
see
you
responding
to
those
yeah,
but
that
chain
of
threats
and
okay.
My
the
chair
is
at
alerting
me
that
this
is
running
over.
But
just
again
we
had
a
ample
time
on
the
schedule
and
the
discussion
is
important.
Nonetheless,
I'll
try
to
wrap
up
this
last
part
quickly.
This
is
the
last
discussion
number
three
regarding
the
rest,
comp
server
structure
strategy.
C
So
why
is
why
are
we
talking
about
this?
Well,
the
motivation
was
to
follow
the
pattern
that
was
set
by
all
the
other
client-server
drafts,
in
particular,
TCP
ssh,
TLS
and
HTTP
models
for
all
of
them.
There
is
a
grouping
that
represents
the
configuration
of
just
a
single
connection,
a
single
TCP
connection,
a
single
SSH
connection
and
how
you
could
configure
that
single
connection.
But
this
pattern
wasn't
followed
in
the
Netcom
from
rest
cough
models.
Instead,
in
uber
application
level
grouping
was
provided.
C
You
know
to
support
both
standard
and
call
home
use
cases
and
for
each
many
endpoints.
So
you
know
it
was
almost
like
an
application
level
model.
It
certainly
wasn't
a
model
that
was
representing
a
single
connection,
so
the
change
was
to
move
from
the
left,
which
is
essentially
one
large
data
model
that
contains
listen
and
call
home
and
inside
each
all
the
endpoints.
To
then,
on
the
right
hand,
side
have
really
two,
the
second
yellow
or
orange
line
down,
have
a
grouping
rest
cough
server
grouping
that
represents
the
per
connection
grouping.
So
just
what?
C
What
is
in
C?
The
only
configuration
here
is
their
certificate
Maps
right.
How
do
you
how?
And
this
is
a
server?
So
how
does
a
server
map
the
incoming
TLS
client
certificate
to
a
rest,
cough
username
and
that
that's
appropriately
ress
cough?
It's
not
a
TLS
thing.
It's
a
rest
call
thing
so
that
that
would
be,
for
instance,
what
can
be
done,
but
then
you
have
the
restaurant
server,
listen
stack!
C
So
if
you
wanted
to
define
the
configuration
for
listening
to
a
a
single
port
for
incoming
restaurant
connections,
here
is
the
configuration
for
doing
that
and
then
there's
an
another
grouping
for
a
call
home
stack.
So
if
you
wanted
to
define
the
configuration
for
listening
sorry
for
initiating
call
home
connections,
that
would
be
the
configuration
stack
for
doing
that
and
then
at
the
bottom.
We
now
have
our
application
stack,
which
is
the
combination
of
it
all.
C
It
has
both
the
list
and
Ana
call
home
sections
and
inside
each
the
multiplicities
of
the
two
stacks
which
is
spoke
of
and
in
the
end,
the
before
and
after.
There
is
no
change,
because
that
the
actual
data
models
are
the
same
just
restructured,
and
now
we
have
teased
out
this
ability
to
have
configuration
models.
For
you
know
the
call
home
stack
the
listen
stack
and
also
for
single
connections.
So
the
question
really
I
have
I
think
this
might
even
be
the
last
slide
is:
do
we
continue
this
approach?
C
Currently,
it's
only
applied
to
restaurant
server.
I
did
that
because,
as
I
mentioned
before,
I'm
implementing
the
restaurant
server
and
I
wanted
this.
So
that's
where
I
started,
but
it
was
I,
think
it's
goodness
and
I
think
we
should
propagate
it
out
to
you
know
not
just
fresco
server
but
also
restaurant
client
and
in
both
net
client
and
server.
Any
comments
about
this.
A
C
Anything
else
yeah,
ok,
so
I
always
feel
guilty.
Answering
this
question
every
ITF
that
comes
up
and,
of
course
the
pressure
is
to
say
you
know
we'll
get
it
into
last
call
in
two
weeks
time
and
then
it
slides.
The
reality
is
as
I
just
mentioned.
Cryptic
types
traps
is
we're
having
sector
review,
it
needs
to
go
to
Anna.
There
needs
to
be
a
discussion
if
we
can
do
the
right
thing
or
if
we
need
to
do
a
fallback
thing.
How
long
will
that
take
to
play
out?
C
I
don't
know,
but
it
is
the
dependency
of
everything
is
everything
depends
on
it
so
and
I
think
it's
the
long
pole
in
the
tent,
then
there's
a
trust
anchors
draft,
which
I
thought
was
done,
but
Hank
just
mentioned
that
there's
a
desire
to
extend
it
to
support,
be
sure,
keys
and
Rockies,
and
we
need
it.
It
was
an
oversight
we
should
have
done
it
we'll
add
it.
C
It's
a
little
bit
more
work,
but
I
think
it'll
take
less
time
than
it
will
take
to
get
the
crypto
types
thing
resolved
and
then
lastly,
keystore,
which
I
just
presented
I,
think
we're
done.
There's
a
couple
points
about
openness
you
wanted
to
which
we
need
to
resolve,
but
they
look
relatively
minor
and
definitely
we
should
resolve
sooner
than
crypto
types.
So
ultimately
it
comes
down
to
how
long
will
it
take
to
get
crypto
types
on
and
I?
Don't
have
an
answer
for
that
I.
A
A
B
New
quarter,
benoit
was
added
lately,
so
the
problem
why
we
started
all
this
is
still
that
unchanged
notifications
about
datastore
changes.
That
is
a
feature,
and
yes,
if
the
note
supports
it,
it
still
doesn't
mean
that
it
will
be
supporting
it
for
every
single
leaf
and
every
little
bit
of
the
datastore.
B
B
The
draft
has
been
updated
since
the
last
IETF.
One
of
the
comments
was
that
different
data
stores,
candidate,
running
operational
might
have
different
capabilities
for
own
change
may
be,
for
example,
unchanged.
Notification
from
intended
is
not
that
interesting,
so
we
need
differ
a
separate
way
to
define
for
data
store
also
in
the
data
model,
unchanged
capability,
unchanged.
Related
capabilities
are
only
needed
if
the
device
ID
or
the
server
actually
supports
the
yank
push
on
change
feature.
If
it's
not
done
shouldn't,
these
should
not
even
be
there.
So
any
feature
was
added
time.
Units
were
unified.
B
B
So
what
kind
of
yang
model
do
we
have
after
these
changes?
One
changes
that
we
have
a
pure
data
store
list
that
defines
which
which
data
nodes
support
or
do
not
support,
unchanged
notifications.
This
has
basically
two
default
values,
one
for
state
and
one
for
config,
and
then
these
capabilities
are
inherited
down
data
and
a
data
tree.
And
if
you
have
a
few
exceptions
like
you
want
to
say
that
yes,
I
support,
no
unchanged
for
all
leaves
but
accept
the
statistics
branch.
Then
you
can
have
these
few
exceptions
documented
in
some
lists.
B
This
is
how
it
looks
like
and
I
think
it's
quite
stable,
except
yesterday
there
was
one
additional
question
raised
that
the
you
see
that
the
unchanged
capabilities
are
defined
for
data
store
and
even
the
inside
they
store
potentially
per
schema
node
or
data
node.
On
the
other
hand,
these
times,
like
update
period
and
dim
dampening
period,
are
defined
on
a
global
level,
and
that
was
the
assumption
for
quite
some
time
now
esteemed
colleague
raised
the
question
that
they
need
a
more
specific
definition
for
this
one
as
well.
B
I
understand
that
sometimes
I'd
say
hardware
might
be
able
to
defer
to
report
I,
don't
know
every
second
one,
other
non-text
Hardware,
only
every
five
seconds
questions
how
detailed
how
complicated
we
want
to
make
it.
My
feeling
is
that,
whether
you
support
unchanged
or
not
yes,
no
capability,
that's
very
important
and
you
don't
get
any
feedback.
K
Binocular
Cisco
so
actually
I
like
very
much
unchanged
flexibility,
because
that's
right
at,
for
example,
we
could
have
unchanged
on
the
entire
data
store.
We
could
have
unchanged
for
a
specific
feature.
We
have
that
not
the
minimum
they
did
period
there.
For
example,
the
question
is
not
how
complex
you
want
to
have
it.
The
question
is
how
reliable
we
want
to
get
this
contract
with
the
box
right.
K
Now,
if
we
take
like
the
the
the
guidelines
that
we
want
to
get
the
contract,
whenever
you
connect
to
a
box,
it's
important
to
understand
the
minimum
of
the
period
for
each
of
the
different
things
you
can
get
right,
because
if
you
want
to
assure
your
box,
it's
like
difficult
to
say.
Okay,
let
me
try
like
10
seconds
your
information.
Okay,
I
could
do
more,
that's
right,
like
8
and
5
and
3.
Until
you
get
like
well
beep,
you
can't
do
it.
K
It
might
be
better
to
get
this
in
the
contract
and
we
connected
a
box
telling
for
this
part
of
the
three
I
could
get
you
every
half
a
second,
but
for
the
other
one
interface
counters
on
their
line
card
on
this
big
box,
I
could
do
30
seconds.
So
if
you
have
to
rely
on
this
to
get
any
assurance
and
it
closed
the
protonation,
we
need
this
flexibility
and
I
get
I
get
it
that
it
might
be
complex,
but
we
might
be
getting
the
same
flexibility
that
we've
got
below
or
at
top
as
well.
I.
B
See
it
as
somewhat
different,
because
these
global
minimums
are
saying
that
the
best
the
box
can
do
in
any
part
of
the
data
model.
Any
datastore
is
I,
don't
know
170
seconds,
and
then
you
try
that
for
interface.
Oh
interface
sends
you
back
that
it's
only
2
seconds
I
can
do,
and
then
you
still
have
that
reliability.
Yes,
it's
a
one
more
round
trip.
K
But
maybe
it's
not
the
right
question
right.
It's
the
best
that
box
can
do
to
get
me
that
information
as
opposed
to
that
one.
This
is,
you
did
a
question
that
we
have
to
answer
right
as
opposed
to
because
you
know,
if
you
implement
this,
you
know,
update
period
will
say
well,
okay,
five
seconds,
why
no
you're
the.
B
K
Let's
do
that
10
whatever
unit,
then
we'll
go
to
some
pumps.
All
you
want
to
use
the
box
and
say
right.
I
want
to
get
like
my
fav
information,
every
house,
whatever
unit,
and
then
you
say,
oh
actually,
no
mr.
customer,
because
it's
like
more
like
five
seconds.
It's
common
sense.
So
you
know
it's
it's
a
question
of
consequence
being
the
right
expectations
or
to
rely
on
the
information.
L
Rashad
Cisco,
just
to
add
to
what
Bruno
was
saying,
I
mean
in
terms
of
implementation.
You
get
collectors
and
sensors
different
hardware,
which
are
out
very
different
collection
capabilities,
and
you
already
have
feels
per
sensor
path.
It's
not
like
you're,
adding
an
extra
list
or
whatever
it's
that
field
could
be.
If
you
add,
if
you
put
the
update
period
per
path,
it
could
be
optional
by
default.
He
inherits
what's
at
the
top,
it's
not
something
you
have
to
add,
but
for
people
who
want
to
support
that,
it's
there
so
I
think
there's
some
significant
benefit.
L
J
B
J
B
This
point
I'm
using
node
selector
from
an
ACM
which
might
be
moved
to
you,
the
yank
types
that
say
it's.
The
format
is
the
inside
anti-fire,
but
you
can
omit
the
keys
with
meaning,
then
it
that
means
that's
every
every
key
value
for
that.
So
if
you
want
to
say
that
all
the
interfaces-
yes,
you
can
do
that
with
a
single
single
item.
J
And
I
agree
and
I
think
that's
probably
right
compromise,
but
it
goes
I.
Think
it's
back
to
what
Ben
are
saying
is
that
ultimately,
this
is
a
contract,
I
think
contracts
of
what's
the
minimum
capabilities,
you're
willing
support,
rather
than
necessary
the
maximum.
So
if
you
say
I
can
support
a
damping
period
of
five
seconds
or
whatever
happens
with
me,
then
you
should
effectively
be
able
to
honor
that
for
everything
it's.
B
A
slightly
different
contract,
the
two
parts
unchanged
means
I,
really
I
promise
to
support
it,
but
these
periods
either
global
or
if
we
put
them
per
datastore,
that
node
or
pair
whatever
its
you
might
still
have
a
CPU
overload,
and
then
it
will
come
back
that
okay,
I
already
have
too
many
subscriptions
going
figured.
So
your
subscription
will
get
on
really
I,
don't
know
twice
that
dampening
periods,
because
I
have
six
more
subscriptions
already
in
my
in
place.
K
But
not
less
so
I
want
to
come
back
to
what
you
said.
If
you
can't
guarantee
the
minimum
of
that
period
well
actually
depends
because
there
are
multiple
ways
that
you
could
do:
telemetry
right,
these
tricks
interval
or,
if
you
wait
until
after
the
connection
the
correction
time,
but
the
point
is
that
we
should
do
the
best
that
we
can
for
a
device
is
healthy
right
if
the
device
is
not
healthy
because
it's
CPU
is
overloaded,
etc.
K
I
mean
yes,
we
arrived
in
the
situation
where
we
should
give
during
those
those
dead
timeout
on
the
fly.
It's
not
it's
not
at
the
point.
The
point
is
that
I
connect
to
a
box
and
say
contract
now,
I
understand
that
you
want
to
do
this
for
two
different
use
case
like
implementation
time
right
and
the
run
time.
I
care
about
the
run
time
at
discovery
right,
I,.
B
Probably
it
will
need
to
be
renamed
in
that
case
still
I
think
that
it's
not
just
healthy
or
not
healthy.
If
you
have
one
subscription,
you
will
get
the
promised
values.
If
you
have
already
hundred
subscriptions
on
the
device
it's
still
healthy,
but
yes,
you
have
hundred
subscriptions
and
the
device
might
know
that
I
can't
give
you
the
lowest
value.
B
I
promised
design
time
and
I
can't
revert
that
I,
just
only
wording
I
can
put
there
is
that
this
is
the
promised
value
in
an
ideal
case,
but
the
device
still
has
the
right
to
say
that
I
can
support
on
the
double
time
exchange.
Thank
you,
okay.
So
that
means
that
unchanged,
capable
notes
list.
You
have
to
be
renamed
to
I,
don't
know
datastore
subscription
cap,
no
specifics
or
something
like
that,
and
all
these
are
the
update
periods,
max
objects
and
minimum
damping
period
will
go
under
that
list.
B
C
C
A
E
E
We
describe
the
two
use
cases
in
our
draft.
Why
is
about
the
the
router
with
multiple
line
cars
and
one
wanna
to
actually
push
data
from
line
cars
to
the
two
other
tractor
and
the
other
is
about
the
IOT?
Is
narrow
and
I?
Would
he
node
can
push
data
to
the
tractor
and
the
border
outer
does
not
assemble
data
as
a
broker,
and
there
was
discussion
since
last.
A
meeting
this
about
the
IOT
is
narrow,
since
this
case
requires
node
management
protocols.
E
In
addition
to
the
push
mechanism,
for
example,
the
node
join
or
the
leaf
no
discovery
and
so
on,
so
this
I'm
open,
so
it
if
it
is
a
really
useful
or
helpful
to
include
this
out
use
case
in
this
draft
I'm
open
to
hear
the
suggestions
in
the
working
group-
and
next
here
is
the
solution
over
vo.
We
do
not
change
actually
and
it
described
the
basic
magazines,
including
the
subscription
decomposition,
the
publication
composition
and
the
subscreen
state
change
in
notifications.
E
Next,
we
propose
to
extend.
We
propose
the
extensions
for
the
publication
composition,
because
the
receiver
need
to
know
the
number
of
component
subscriptions,
so
we
propose
to
add
a
list
of
publisher
ID
for
configured
subscription.
We
add
this
to
the
subscription
started
and
subscription
modified
notifications
and
on
the
dynamic
subscription.
We
add
this
to
the
established
subscription
and
modify
subscription
are
our
PCs
and
we
stopped
here
in
lustre
revision,
because
we
think
this
should
be
this
job.
E
This
draft
should
be
transport
independent,
but
there
was
suggestions
in
the
Middle
East
to
to
consider
the
transport
configurations
for
multiple
line
cars.
So
we
have
the
following
the
following
two
discussions:
next,
the
one
is
about
the
extension
folder
configure
the
subscription,
we
suggest
to
add
a
list
of
channel
configurations
under
the
receiver
configuration-
and
in
this
case
all
the
potential
channels
are
pre-configured
and
the
actual
publication
channel
are
selected
based
on
the
subscription
decomposition
result,
and
here
I
also
give
an
example.
We
borrow
this
from
the
narco
HTTP
notification
draft
and
we
put
this.
E
C
M
E
And
the
other,
the
other
one
is
the
extension
for
dynamic
subscription.
This
seems
more
complicated,
complicated
because
because
there
are
several
transport
options
for
the
the
line
cars.
Firstly,
the
line
cards
can
run
on
server
mode
or
client
mode,
and
the
connection
could
be
dynamically
set
up
or
pre-configured.
So
we
have
two
option:
one
is
to
generalize
the
rest
cough
notif
jeff'd.
E
This
is
the
mode.
Firstly,
the
rank
has
rung
on
the
server
mode
and
the
connections
are
dynamically
set
up.
So
we
need
the
RPC
to
return.
The
resource,
access
information
and
the
receiver
can
get
data
from
the
line
cards
and
the
second
option
is
used
to
consistent
with
the
configure
subscription,
just
like
the
previous
example
and
this
mode.
Actually,
the
line
cards
runs
on
the
client
mode
and
the
connection
is
pre-configured.
So
all
the
channels
are
pre-configured,
just
just
a
push
data
when
the
subscription
requests
accepted.
E
Yeah,
so
next
we
consider
to
improve
the
examples,
but
we
also
have
question
what
kind
of
reuse
employees
expect
it
because
of
we
see.
We
do
not
see
a
similar
example
in
the
the
subscriber.
The
notification
draft
I
think
you.
This
draft
is,
can
be
compared
to
a
standard
one,
but
we
did
not
find
a
similar
examples
and
we
also
accept
other
suggestions
on
issues
we
need
to
consider
in
in
the
following
work
and
questions.
G
D
The
master
guy
and
so
there's
got
to
be
ways
to
be
able
to
do
all
the
discovery
elements
in
there.
So
if
you
tried
to
extend
this
to
anything
outside
of
closed
ecosystem,
I
think
there's
some
considerations
that
that
that
need
to
happen
or
for
the
solution
to
work
correctly
and
all
the
security
that
goes
around
it
right
right
now,
you're
just
constrained
to
a
to
a
locked
box.
If
you
look
the
extended
past
that,
then
you
got
to
worry
about
discovery
and
other
elements,
so
that
would
be
my
concern
with
the
IOT
use
case.
D
Those
other
use
cases
you're
going
to
have
to
address
these
different
issues,
and
so
I.
Don't
think
that
that
was
your
original
intent
with
this
draft
right,
you're
just
trying
to
say
look
I've
got
a
I've
got
a
closed
ecosystem
that
I'm
gonna
put
together
a
master
publisher.
That's
gonna
kind
of
coordinate
that
stuff.
Instead
of
having
different
streams
right,
that's
effectively.
What
this
was
doing
right
and
so
I
would
keep
it
into
the
context
that
was
in.
If
you
do
choose
to
make
it
broader,
then
you're
gonna
have
to
address
these
other
issues.
D
E
C
As
a
contributor,
my
takeaway
from
that
would
be
at
a
minimum.
The
track
needs
to
have
a
section
that
speaks
to
this,
and
at
least
no
identifies
that
that
intention
and
and
then
and
then
there's
question
of
whether
or
not
the
draft
actually
solves
it.
So
one
potential
solution
might
be
for
it
to
define
in
config
policy
operational
state
that
lists
out
the
channels
that
the
device
is
having
available.
That
descriptions
can
be
made
on,
and
that
would
be.
D
You
can
imagine
an
IOT,
you
know
if
you're
looking
at
this
an
IOT
would
be
some
of
the
mechanisms
they
use
for
discovery
may
be
out
of
coop.
You
know
that
type
of
stuff,
so
you
can.
It
can
spin
quickly
if
you
want
to
move
it
out
of
that
closed
ecosystem,
but
even
within
the
closed
ecosystem,
you're
correct
you
might
want
to
give
them
some
guidance
say:
hey
look.
When
you
build
a
line
card,
it
comes
with
what
you
guys
were
talking
about
becomes
a
channel
right.
N
C
So
I
can't
as
a
contributor,
I
guess
I
was
I
think
we
talked
about.
We
discussed
this
on
lists
and
the
with
the
channels.
It
was
unclear
to
me
that
the
channels
was
a
lists
of
channels
or
or
you
know
or
not,
also
there's
you
know
we
don't
have
a
gang
model
that
is
yet
defining
this.
This
node,
this
container
called
a
channel
or
actually
is
a
list
without
your
sirness.
C
Don't
have
a
gang
model
that
defines
a
list
called
channel
where,
where
is
that
gang
model
working?
No
it?
Presumably
it
should
be
in
this
draft
well,
actually
really,
presumably
might
offend
in
the
SUBSCRIBE
notification
shaft,
but
I
think
that
there's
a
you
know
it
I'm
not
really
clear
how
to
extend
this
draft
to
have
that
definition
of
the
list
of
channels
in
it
being
maudlin.
Could.
E
E
G
C
Http
note
of
draft
is
the
first
note
of
draft
that
we
have
that
this
working
group
has
produced
for
a
configured
description
and
the
approach
is
taking,
which
is,
in
fact
was
sort
of
you
know,
suggested
or
we're
almost
mandated
by
these
describe
notifications.
Draft
or
ARF's
are
almost
farsi
was
to
augment
the
receiver
No,
and
so
that's
what
that
track?
Does
it
augmented
the
receiver,
note
yeah
and
then
what
you're
suggesting
is
that
there'd
be
a
channel?
That's
underneath
the
receiver.
E
C
So
how
is
it
it
knows?
Am
I
supposed
to
be
augmenting
the
receiver
note
or
am
I
supposed
to
be
lifting
the
channel?
No,
how
can
it
you
know
so
I
think
we
get
into
this
issue
of
like
in
these
not've.
They
should
that
it's
the
intention,
the
note
of
craft,
it's
kind
of
somewhat
independent
of
the
transport
so
out
of
the
contest.
So
how
would
it
know
if
this
is
a
device
that
has
slang
carts
or
not,
and
what
is
the
appropriate
augmentation?
One
I
think
that's
the
issue
that
we
know
this.
E
This
is
C,
and
this
is
also
an
Augmented
to
the
the
subjective
draft.
So
let
me
see
if
you
own,
if
you
opened,
if
you
wanna,
only
wanna,
enable
the
one
channel
to
the
receiver
is
like
the
sub
no
TV
after
you,
you
just
augments
that
draft
and
added
audio
configurations
on
the
receivers
on
the
receivers,
and
if
you
wanna
enable
the
mark
on
line
cars,
the
multiple
originator
scenario,
then
you
can
augment
the
augment
the
channel
configuration
sounder
to
China
here.
C
E
C
E
C
There
can
be
many
notice
transports
that
are
defined.
The
HTTP
notice
is
just
one
of
many
possible,
its
begin
and
and
I.
Don't
think
we
want
each
of
those
notice
transports
to
themselves
happen
to
be
augmenting
it
and
optionally
implemented
channel.
That's
it.
So
it's
not
the
right
place
to
do.
It
I
think
that
you're,
a
guy,
can
have
a
data
model
that
augments
the
receiver
lists
adding
in
a
channel
list.
Some
devices
will
implement
it.
Others
won't
the
note
of
straps.
C
We
could
actually
have
it
that
they
have
a
dependency
both
to
subscribe
notifications,
as
well
as
to
your
draft
with
two
arguments
and
there's
a
feature
effectively
that
the
server
chooses
whether
or
not
the
note
of
is
a
augmenting
one
of
the
sub.
The
channel
list,
if
it
exists
or
not
I,
think
that's
what
we
could
do,
but
we
can't
just
hard
if
we
move
the
channel
list
into
the
HTML,
oh
crap,
and
it's
only
one
of
many
possible
future
note
of
that.
It's
not
the
right
location
for
it.
B
B
B
E
B
N
G
N
B
N
A
C
Thank
you,
you're,
going
back
to
the
previous
comment
or
discussion.
I
was
just
we're.
Having
let's
take
a
step
back,
why
do
we
want
to
have
it
list
the
channels
at
all?
The
reason?
Why
is
because
some
protocols
require
her
channel
configuration,
for
instance,
and
actually
it's
questionable
right,
but,
for
instance,
in
TCP
you
may
want
to
specify
the
source
IP
address
on
a
per
line
basis.
Also
for
TLS.
You
may
want
to
specify
the
cryptographic
credentials
on
per
line
card
basis,
but
those
are
TCP
and
TLS
specifics.
C
Not
all
notifications
transports
will
necessarily
have
either
or
any
such
considerations.
For
instance,
a
flat
UDP,
let's
say
syslog
or
UDP
has
none
of
these
concerns,
and
so
a
global
configuration
of
sits
log
of
e
to
be,
for
instance,
just
going
to
receive
her.
You
know
augmenting
receiver
and
then
the
could
be
a
global
flag
that
says:
I
want
the
these
line
cards
to
be
able
to
send
syslog
a
read,
P
straight
out
the
data
plane,
and
that's
it
we're
done
it's
just
a
global
flag.
C
G
C
E
A
So
in
the
interest
of
trying
to
move
this
draft
forward,
one
conversation
that
the
chairs
were
having
was
to
figure
out.
Maybe
we
need
to
put
a
design
team
that
might
be
helpful
for
the
for
the
authors
and
if
such
a
design
team
would
informed
if
people
here
would
be
interested
in
and
of
contributing
to
that
design
team
identify
the
problem
may
be
defined.
The
scope
of
the
graph
help
to
move
it
forward.
That
would
be
one
day
a
week
would
suggest
how
you
move
to
that
pole.
C
Yeah
I
mean
to
be
clear:
the
work
group
very
much
wants
to
adopt
the
strap.
We
think
it's
important
work,
I
shouldn't
say
the
watch
group
I
can't
speak
for
group
chairs
I.
Think
we
welcome.
If
I
can't
say
working
group,
we
adopted
you
to
keep
up
sub
three
four,
because
this
was
the
use
case
that
we
were
hoping
that
it
was
going
to
solve,
but
in
the
end
it
turned
out
to
be
a
UDP
transport
which
is
actually
not
so
we
did
actually,
as
a
working
group,
adopted
this
idea.
C
If
we
want
it,
we
need
to
support
this
so
we're
trying
to
get
it
over
the
line
quickly
as
possible
and
we're
just
thinking
that
it
might
be
helpful
to
have
a
design
team.
So
would
anybody
be
willing
or
to
work
with
the
author
on
a
design
team
basis,
your
hand,
yeah
I,
see
some
hints,
so
that's
great
and
you,
everyone
in
the
race
are
here
and
send
a
message
to
the
author,
so
they
can
sync
up
with
rocker.
C
Great,
thank
you
thank
you,
and
we
need
to
move
to
our
last
presentation,
which
is
Mahesh
should
be
providing.
M
I
A
A
A
A
Actually,
in
this
case,
and
the
receiver,
as
we
say
in
the
module,
has
a
list
of
TCP,
TLS
and
HTTP
parameters
that
it
uses
from
the
module
at
the
drafts
that
Kent
has
been
presenting
and
is
working
on.
So
that's
really
the
sum
of
the
entire
draft
and
I
know
there
were
a
couple
of
questions
on
the
mailing
list.
A
A
C
As
a
contributor,
this
graph
actually
supports
both
JSON
and
XML,
and
the
way
it
does
so
is
through
this
describe
notifications
draft
already
inside
that
data
model.
There's
a
leaf
called
encoding,
Eastern
identity
with
Drive
types,
XML
JSON
in
theory,
it
could
be
extended
to
support
binary
and
then
it
you
know
here
just
be
binary
over
HTTP.
So
we
distract
herself.
We
don't
think
you
know
leads
to
itself.
You
know
it's
it.
It's
already,
not
it's
indicating
what
encoding
is
used
being.
Is
it
just
inherits
it
on
the
subscribes?
Other
patients
trapped,
okay,.
A
G
G
I'm
fine
I
can
actually
read
those
two
lines.
If
you
insist
so
again,
serious
question
is
the
working
group
sees
this
as
the
work
that
is
needed
if
the
community
would
eventually
see
this
being
deployed
and
used,
what
can
I
see?
Can
I
see
a
show
of
hands
right,
if
you
so
about
who
has
who
has
read
this
document
all
right
now,
I
think
this
needs
to
be
raised
into
the
mailing
list
about
adoption.
Please
read
the
document
and
please
provide
your
comments
and
feedback
about
that
from
from
those
hands
which
I
ca.
G
L
I
read
the
draft
in
detail
and
it's
well
returned
it
matches
well
with
subscribe.
Notifications
can
all
that.
So
it's
all
good,
but
one
thing
I
was
asking
the
restaurant
question
before.
Is
we
don't
actually
have
an
HTTPS
draft
for
dynamic
subscriptions?
We
have
net
can-can
restaurant
right,
so
is
it
just
configured
or
is
there
something
else
for
dynamic
subscriptions?
Actually,
it's
that's
the
part
I'm
struggling
with
okay.
C
So
first
I'll
thank
you
Ignace
for
running
this
question,
we'll
take
it
to
the
non
list
and
then
back
to
Rashad
question
which
you
raised
before,
but
so
with
a
contributor
hat
on
so
over
the
course
of
several
a
test
we
didn't
race
and
talk
about
this
discussion,
and
certainly
dynamic
descriptions
have
to
be
restaurant.
That
cough
because
you're
coming
in
over
a
restaurant
for
an
economic
connection
to
begin
with
with
configured
descriptions.
Is
it
the
best
choice
like
if
the
device
is
going
to
proactively
initiate
a
connection
to
a
receiver?
C
Would
that
should
that
connection
be
of
reskin,
a
connection
which
all
that
into
it
entails
meaning
it's
a
full
configuration,
operational
stage,
etc,
type
connection?
Do
we
want
all
that
or
we
were
looking
for
something
smaller,
simpler,
remember
this
is
being
implemented
online
cards,
so
it
has
to
be
simple
and-
and
you
know,
and
typically
you
know,
people
talk
about
pushing
notifications.
C
B
C
We
are
three
minutes
ahead
of
time.
That's
great!
Yes,
that's
it!
Thank
you
very
much
for
coming
to
the
session.
Of
course,
it's
lunch
now
after
lunch
will
be
met.
Maude
I
believe
it's
in
this
room
met
mom
session
one
and
then
a
short
break,
followed
by
even
that
mom
session.
Two
in
the
room
next
door
see
you
then.