►
From YouTube: IETF106-NETCONF-20191118-1550
Description
NETCONF meeting session at IETF106
2019/11/18 1550
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
B
B
B
B
With
the
status
for
the
list
of
charted
workgroup
items,
we
still
have
the
what
we
call
the
net
compress
count.
Client
suite
of
drafts
that
Kent
is
working
in
Kent
and
a
couple
of
others
are
working
on
the
HTTP
client
server
document
did
go
through
work
group
adoption
and
we
had
a
HTTP
business
and
I
had
a
discussion
this
afternoon
to
try
to
resolve
any
concerns
that
they
had
so
I
think
we
have
come
to
a
resolution
that
they're
okay
with
the
work
proceeding
in
that
con,
so
they
were
group
document.
B
During
that
meeting,
the
yang
push
notification
capabilities
is
pass
working
group
last
call
I
serve
allies,
did
update
the
document
in
data
tracker,
so
I
think
it's
we're
ready
to
go
ahead
with
publication
of
that
document,
and
the
remaining
two
drafts
yang
push
notification
messages
still
work
in
progress.
I
expect
that
there
is
a
presentation
that
will
be
done
I,
hopefully
by
hang,
if
not,
then
by
Erich
remotely.
B
And
finally,
we
have,
of
course,
the
HTTP
notification,
which
is
a
fairly
new
document,
so
here's
the
agenda
we'll
start
with,
of
course,
the
status
and
issues
on
client-server
suite
of
drafts
before
we
move
to
notification,
messages
and
notification,
capabilities,
presentation
and
we'll
round
up
the
charted
list
of
items
with
my
presentation
on
HDTV
based
notification,
transport
for
configured
subscription.
Sorry.
D
Yes,
hey
this
Tim
Carey
with
Nokia
the
udp-based
publication
channel
for
streaming
telemetry.
Do
we
know
what
the
status
of
that
is?
It
used
to
be
an
adopted
draft,
but
I
see
it
fell.
Oh.
B
E
E
E
I
again,
don't
see
them,
but
I'll
just
simply
say
next
slide.
Okay,
great
again,
welcome
well
I'm,
not
there,
but
I'm.
Still
there
today
we're
going
to
be
presenting
the
again
the
client-server
suite
of
drafts,
and
you
can
see
that
they're
now
all
adopted
the
HTTP
client
server
draft
is
in
grey
because
while
it's
adopted,
it's
not
yet
posted
so
well,
actually
I
guess
still
be
talking
about
the
Kay
Watson
draft
that
was
published
before
next
slide.
Please,
oh
by
the
way
and
I
can't
even
see
if
you
have
index
to
the
next
slide.
E
E
E
Next
slide,
please,
okay,
so
in
the
e
crypto
types
draft
there
is
we've
been
discussing
for
quite
some
time
how
to
support
algorithms
or
I
should
say
the
algorithm
note
when,
when
having
public
or
private
keys
or
even
symmetric
keys,
it's
important
for
the
client
to
be
able
to
know
what
is
the
that
algorithm
itself.
That
is
I
see
the
slides
now
from
the
video
zooming
in
to
that's
funny
from
the
from
the
algorithm
without
will
with
algorithms
being
used,
and
we
were
actually
using
the
algorithm
node
before
for
two
purposes.
E
The
first
was
exactly
what
I
just
said:
what
was
the
algorithm
being
used,
but
the
second
was:
how
was
it
being
encoded
and
sometimes
a
particular
key
value
can
be
encoded
in
multiple
different
ways.
The
simplest
explanation
for
that
might
be
if
it's
binary
versus
ASCII,
but
also
there's
other
kinds
of
encoding.
So,
for
instance,
is
it
a
rocky
versus
a
key?
That's
been
embedded
inside
a
content
message,
syntax
or
CMS
structure.
E
So
we
were,
we
again:
we've
been
discussing
how
to
encode
the
algorithm
field
for
some
time
and
and
the
crooks
of
that
discussion
has
been
mostly
with
regards
to,
should
it
be
identity
or
an
enumeration
should
that
be
in
IETF
file
or
an
eye
on
a
file
should
be
one
file
or
multiple
files
and
what
we're
still
having
some
of
that
discussion,
but
also
part
of
that
was
in
the
description
statement.
For
that
algorithm
value
would
be.
How
was
that
value
encoded?
E
E
The
key
format.
Node
is
a
in
a
Dana
B
and
on
the
left
hand
side
you
can
see,
there's
a
base
called
key
format
and
then
there's
three
immediate
descendant
identities
called
public
key
private,
key
and
symmetric
key
by
the
way
they
all
have
format.
After
them,
sorry
actually
public
key
format
and
symmetric
key
format
and
then
underneath
those
there's
also
additional
sub
identities
and
also
they'll.
They
also
have
format
at
the
end
of
Emily
I.
E
Think
I
was
trying
to
make
the
slide
simpler
and
that's
why
I
did
that
you
can
see
at
the
the
last
two
identities
for
private
key
format
are
controlled
by
an
if
feature
statement
and
as
well
as
the
last
two
of
the
symmetric
key
format.
So
here
the
C
feature
format
statement
is
trying
to
this
is
where
there's
a
different
encoding,
but
we're
in
one
aspect
you
could
that
key
could
be
expressed
as
a
role
value
or,
alternatively,
as
a
structure
or
a
value.
That's
been
embedded
inside
of
another
structure.
E
Next
slide,
please
and
then
so:
there's
the
identity
hierarchy.
So
that's
one
aspect
and
I
should
say
that
that
is
inside
the
crypto
types
or
I
hate
to
have
crypto
types,
that
yang
module
and
also
inside
that
same
module
are
three
groupings.
The
two
and
the
left
are
for
a
symmetric
keys
and
one
on
writers
for
symmetric
keys
and,
and
these
groupings
have
been
around
for
some
time,
but
they,
the
part,
that's
in
red,
is
the
important
part
you
can
see
in
the
top
left
the
public
key
grouping
it
now
contains.
E
Well,
first,
it
contains
the
leaf
algorithm
so
that
leaf
algorithm
has
been
there
for
some
time
and
the
part
that's
in
bright,
green
is,
is
sort
of
a
the
what
we'll
be
discussing
in
the
next
the
next
topic.
But
you
know
how
do
we
describe
algorithms
and
and
are
the
identities
her
enumerations
etc,
but
it's
that
value,
but
then
the
second
leaf
is
the
new
one.
So
this
is
a
leaf
that
is
containing
an
identity
ref
to
a
public
key
format.
E
So
there's
that
and
then
and
then
you
can
see
the
other
group
in
the
asymmetric
key
pair
grouping,
it
uses
that
grouping
uses
the
public
key
grouping,
because
every
private
key
also
has
a
public
key,
but
it
distinctly
identifies
its
own
private
key
format.
And
yes,
both
the
public
and
private
key
values
could
be
expressed
differently
most
commonly
they
would
be
done
similarly
right,
but
it
is
possible-
and
you
know,
and
actually
in
some
cases
necessary,
I
suppose
if
you
want
to
encrypt
your
private
key,
but
the
public
key
is
still
a
role
value.
E
So
it's
still
possible
I
mean
it's
necessary
that
they
could
deviate
or
differ
in
their
encoding
strategies.
So
there's
so
that's
how
a
symmetric
Keys
the
groupings
for
h
to
metric
keys
have
been
modified
and
then,
on
the
right
hand,
side
it's
almost
the
same
strategy,
but
just
there's
only
the
symmetric
key
value.
So
here
the
leaf
is
called
key
format
as
opposed
to
public
key
for
Landon
and
private
key
format.
E
I'm
gonna
see
what
I
want
to
say:
no
I,
guess
that
is
it:
oh,
oh,
yeah,
I'm,
sorry,
what
I
wanted
to
say
was
and
I
don't
have
a
slight
it's
not
on
the
slides.
But
if,
after
having
done
this
most
of
the
prior
use
of
the
algorithm
leaf
has
been
replaced
with
this
new
key
format
leak.
E
If
you
were
to
look
at
the
entirety
of
the
remainder
of
the
egg
modules,
you'll
see
that
the
only
remaining
use
of
the
algorithm
leaf,
at
least
from
the
clients
perspective
of
being
able
to
you,
know
like
the
primary
use,
is
in
the
actions,
generate
private
key
and
generate
symmetric
key.
So
you
can
clearly
tell
that
when
a
client
is
trying
to
generate
a
key,
it
would
need
to
be
able
to
use
the
algorithm
to
say
what
kind
of
key
that
is
generate.
E
So
that
is
one
of
the
most
crucial
remaining
uses
of
the
other
legacy,
algorithm
value
and
and
then
and
then
of
course,
it's
also
still
there
for
more
of
a
read-only
view.
I
mean
it
is
still
writable,
but
you
couldn't
write
it
just
arbitrarily,
but
it's
it's
definitely
the
case
that
if,
if
a
person,
if
another
client
were
to
connect
and
wanted
to
look
at
the
key
just
having
the
key
format
by
itself,
it's
not
enough,
they
would
actually
need
that
read-only
value.
E
E
None
locally,
okay
and
I.
Don't
think
I
see
anything
on
me
that
go
either
so
great
all
right,
so
it
so
I
think
it's
it's
working
out
well,
I'll
just
say
that
balázs
K
from
Erickson
has
been
tracking
this
and
and
at
first
he
had
some
mild
concerns,
but
then
I
replied
on
list
about
how
the
advantages
of
it
and
I
think
I
want
to
over,
but
nonetheless
will
continue
this
discussion
on
the
list.
E
Previously
there
were
many
type
that
were
typed
us
inside
ITF,
crypto
types
module
and
now
those
type
deaths
have
been
moved
into
external
I,
Anna
or
I
should
say
external
modules,
three
of
them
and
one
and
there's
two
aspects
to
that
statement.
Well,
the
first
is
that
they're,
each
kind
of
modular
or
or
I
should
each
type
of
algorithm
has
been
moved
into
its
own
module.
So
there's
one
module,
that's
specific
for
symmetric
algorithms
and
otherwise
for
asymmetric
algorithms
and
and
another
one
for
hashing
algorithms.
E
Also
I
shouldn't
mention.
We
we've
reduced
the
total
number
of
algorithm
types,
I
think
before
there
may
have
been
eight
or
nine
different
kinds
of
algorithm
types,
but
we
reduce
them
down
to
just
these
three,
these
three
being
the
ones
that
are
necessary
for
defining
the
Netcom
and
restaurant
server
modules
and
the
remainder
really
not
necessary
for
our
work.
But
it
you
know
in
the
fullness
of
time
important
to
other
working
groups,
oh
sure,
but
not
something
that
we
need
to
take
on
ourselves.
E
That's
why
just
these
three
types
of
algorithms
are
being
focused
on
so
and
then
so
that's
the
first
excellent
aspect
that
we've
broken
up
into
three.
The
other
is
that
we
also
move
them
from
being
IETF
prefix
to
INF,
prefix
and
and
actually
I
have
a
separate
slide.
That
talked
some
that
specific
point.
So,
first
on
that
you
can
see
in
the
lower
left,
each
module
has
a
type
that
so
you
actually
just
moved
the
type
that
from
the
crypto
types
module
to
the
other
module
and
here's
an
example
of
that
type.
Def.
E
You
can
see
that
this
type
def
is
defining
an
enumeration.
So
it's
not
an
identity.
We
may
want
to
have
a
discussion
as
if
it
should
be
an
enumeration
or
identity.
I
actually
think
the
enumerations
are
probably
simpler
to
work
with,
but
it
could
even
be
as
simple
as
a
just
string
all
here.
Only
the
symmetric
algorithm
types
are
being
shown,
but
of
course,
a
symmetric
n'
and
thus
and
hashing
algorithms
follow
legs,
identical
strategy
of
being
a
type
def
containing
enumerations.
B
E
E
Other
Diana
modulus,
and
one
thing
I
noted
about
them,
was
that
it
seemed
that
there's
a
one-to-one
mapping
between
those
modules
and
a
particular
registry
and/or
actually
to
a
particular
RFC,
whether
it's
not
as
a
particular
registry
I
think
is
still
I'm,
not
sure
about
that.
But
but
in
scanning
these
type
ducts.
G
G
So
I
guess
this
is
more
a
net
mode
thing
to
consider,
but
you
asked
how
would
I
Anna
know
when
an
algorithm
should
be
added,
so
my
question
to
this
question
would
be:
how
would
I
on
know
that
an
algorithm
should
be
added
to
the
registry
itself,
because,
as
soon
as
this
is
decided,
then
it
should
be
clear
or
at
least
I
hope
to
IANA
that
the
yanghwa
you
should
be
updated.
Basically,
at
the
same
time,
so
I
really
don't
see
a
big
problem
with
this.
The
only
problem
is
that
may
be
careless.
G
Readers
of
that
RFC
could
take
the
more
you
contained
there
as
the
most
recent
revision
of
the
registry,
which
needn't
be
the
case
because
then
the
module
lives
in
in
under
the
the
IANA
care
may
have
new
revisions,
but
I
don't
know
how
to
solve
this
easily
because
we
have.
We
don't
have
any
any
like
formal
language
for
writing
the
module
templates
as
usage
easier.
So
this
is
really
quite
a
difficult
proposition.
I
think.
E
There
may
be
that
may
be
challenging
and
the
reason
why
is
because
we're
working
with
different
protocols,
in
particular
SSH
and
TLS
and
I
fully
imagine
there
being
registries
that
are
around
the
algorithms
use
for
SSH
and
its
registry
is
being
used
for
algorithms,
that
it
uses
around
TLS,
but
we're
looking
for
something
that's
more
Universal
and
I.
Don't
know
if
that
particular
registry
exists.
That
could
become
our
challenge.
E
H
Rob
Wilton
Cisco,
so
I
definitely
think
this
is
something
that
should
be
handled
by
something
like
an
I
ana
registry.
I.
Think
that's
where
these
need
to
get
to
I.
Think
that
it
that
how
to
update
an
RFC
tab,
these
new
protocols
and
would
be
a
mistake,
I
thought
with
the
IANA
registries,
there's
ones
where
you
could
have
like
experts
that
were
assigned
to
add
values
in
so
it
may
be
that
you
could
assign
the
yang
doctors
or
net
mod
or
something
to
update
that
registry.
H
E
And
just
as
you
were
saying
that
Rob
thank
you,
it
occurred
to
me
that
what
I
was
just
saying
about
how
there's
been
an
association
to
your
specific
registries.
We
could
make
updates
the
ANA
request
could
be
if
those
registries
are
being
updated.
Then
please
allow
them
to
be
a
trickle
down
update
to
this
other
registry
which,
which
is
in
indirect,
it
may
not
be
one-to-one,
but
it
with
the
human
expert.
They
could
do
that
particular
you
know
translation
and
make
it
happen.
That's
a
good
idea.
Yeah.
E
Slide
please
and
so
sort
of
rounding
out
the
discussion
about
algorithms
is
a
you
know,
an
S,
it's
necessary,
so
there's
one
thing
which
is
defining
the
dictionary
of
all
algorithms,
it's
necessary
to
have
a
dictionary
of
of
the
algorithms
for
interoperability,
and
it
could
be
that
each
vendor
came
up
with
around
you
know
the
strengths,
but
that
wouldn't
help
with
interoperability.
So
having
a
universal
dictionary
is
important,
but
there's
another
aspect
which
is
which
subset
of
that
Universal
dictionary
does
a
particular
server
support
and
I.
E
This
discussion
has
been
on
the
list
also
recently,
so
for
those
have
been
following
that
you
know
some
of
this
will
be
a
repeat,
but
nonetheless
I'll
go
over
it.
So
first,
it's
each
module
currently
is
or
I
should
say
each
of
those
three
I
Anna
modules
that
we
just
discussed.
It
is
currently
defining
a
config
false
list
of
algorithms
that
are
supported
by
that
server
and
so
an
example
that
you
can
see
they
they
all
kind
of
follow
the
pattern
of
supported
and
what
kind
of
algorithm
it
is.
Algorithms.
E
E
This
was
late
last
last
week,
where
I
was
saying
that
you
know
a
particular
application
or
server
may
use
different
or
be
able
to
use
different
algorithms
in
different
locations,
and
if
you
think
about
how
that
application
has
been
constructed
with
libraries,
one
part
of
the
vacation
may
use
one
library
and
Sables
support
certain
algorithms,
another
part
of
that
application
to
use
a
different
library
and
southern
algorithms.
So
there's
that
aspect.
E
So
you
know
that
I
think
the
intent
behind
a
global
list
would
be
when
you're
thinking
like
France's,
Fitts
mode,
where
you're
you're
taking
a
you,
know
some.
You
know
there's
the
set
of
algorithms
and
then
oh,
you
turn
on
FIPS
mode.
So
now
it's
a
subset
of
r
and
then
both
those
statements
are
sort
of
there's
a
global
list.
E
E
So
there's
sort
of
the
most
granular
way
of
doing
that
would
be
every
single
location
where
the
leaf,
but
the
algorithm
leaf
has
been
used.
It
could
be.
There
could
be
a
list
there
or
maybe
an
action
statement
that
could
return
a
list,
but
that's
highly
granular
and
and
maybe
ideal,
but
from
a
theoretical
perspective,
but
not
very
practical.
E
From
a
modeling
perspective,
it
seems
like
a
possible
sweet
spot
would
be
to
focus
on
the
algorithms
and
so
have
one
list
in
instead
of
having
the
single
global
list
instead
of
having
or
splitting
it
essentially
into
two
globalists,
one
one
of
those
lists
being
specific
to
SSH
and
the
other
to
TLS
and
so
in,
and
to
be
clear
because
we're
talking
about
three
different
algorithm
types,
there'd
be
340
as
SSH
a.m.
340
less
a
total
of
six
of
these
global
list.
That's
the
current
idea.
Any
thoughts
about
that
I.
I
Why
this
is
Hank
I,
can't
I,
think
I,
somehow
find
myself
in
the
slide.
I
think
is
very
important
to
do
this.
The
since
you
were
highlighting
I'm,
not
an
expert
in
this,
so
probably
this
group
is
and
I
think
one
will
be
selected
or
a
set
of
them.
I
think
this
somehow
swaps
about
who
trusts
store,
because
all
these
algorithms
and
the
big
asymmetric
are
symmetric
or
hashing.
They
will
have
in
the
end,
the
key
material
used
for
these
algorithms
and
I
think.
Nevertheless,
that
is
trust
raw
side.
I
There
are
hints
and
methods
to
find
and
identify
these
keys
and
I
think
this
belongs
also
here,
because
these
have
to
be
defined
like
in
the
same
Bay,
I
assume
with
the
algorithm.
There
comes
an
identification
for
the
pay
dirt
for
the
algorithm
and
I'm.
Probably
that
is
not
a
part
of
the
key
store,
because
that
is
too
late.
If
you
go
to
the
store,
you
already
assume
your
how
to
find
it,
so
there
has
to
be
a
link
between
the
key
identification
or
key
hint
or
identification
hint.
I
E
Alright,
I'm
not
sure
it
seems,
like
maybe
add,
a
second
comment,
but
we
respond
to
the
first
one.
I
think
what
you're
just
discussing
right
now
is
war.
What
I
was
saying
about
the
need
for
having
the
global
dictionary
the
you
know:
what
are
all
the
others?
What
are
all
the
type
tests
for
interoperability
here?
What
we're
talking
about
is
trying
to
identify
the
subset
of
those
algorithms
that
a
particular
server
supports
and,
and
so
I
think
it's
actually,
but
but
that's
a
different,
that's
a
different
discussion
and
to
that
first
one.
E
What
is
the
global
dictionary
of
algorithms
a?
So
if
you
actually
look
a
little
bit
deeper
in
right
here,
we're
talking
about
the
crypto
types
draft,
so
there's
the
universal
set
of
algorithms
at
that
level.
But
then,
if
you
were
to
look
into
the
SSH
and
TLS
specific
drafts,
you'll
see
that
they
have
mapping
tables
and
in
particular
I
mean
the
SSH
and
TLS
protocols.
E
They
they
have
very
specific
algorithms,
enumerations
values,
strings
that
are
sent
over
the
wire,
and
so
there's
these
mapping
tables
that
you
know
for
those
who
are
familiar
with
ssh,
specific
algorithms
or
TLS
specific
algorithms
be
mindful
that
well,
the
algorithm
was
normally
called
foo
in
in
TLS.
It's
actually,
you
know
bar
here
in
the
crypto
type
trap.
So
there's
that
mapping
okay.
H
This
is
a
subset
of
those,
however,
that
work
will
take
a
long
time
so
I
think
what
we're
looking
for
here
is
I
sort
of
stopped.
That
measure,
there's
no
B
in
the
short
term
and
I
think
that
I
either
of
what
you
propose
there
work
either
global
list
or
I.
Think
your
suggestion
of
having
six
lists
that
seems
reasonable
to
me.
I,
look
like
I
wouldn't
go
anything
more
complicated
than
that,
though
I'd
keep
it
I
think
what
you're
proposing
then
makes
sense.
Okay,.
E
Looks
like
the
microphone
line
is
empty,
so
I'll
move
on
to
a
second
question
here:
number
two:
how
are
these
lists
to
be
used
cannot
use
a
leaf
ref
right,
I
mean
they're,
config
files
lists
and
well.
Okay,
not
only
are
they
config
false
list,
but
they're
also
polymorphic
in
the
sense
that
when
you
have
a
the
reference
to
the
to
the
to
the.
E
E
We
could
have
in
the
algorithm
description
statement,
which
would
be
in
crypto
types,
something
like
what's
in
yellow
at
the
bottom
of
the
screen.
It
is
recommended
that
each
protocol
sht
etc
makes
available
a
list
of
the
subsets
of
algorithms
supported.
I
could
maybe
that's
a
different
statement.
So
there's
sorry
that
wasn't
a
clean
site
way.
There's
two
comments
being
made
here,
but
yeah.
So
there's
first
there's
a
you
know:
we
need
a
set
of
strategies.
So
whenever
an
algorithm
or
protocol
is
trying
to
define
you
know
mappings,
we
say
we
should.
E
You
should
create
these
other
lists,
but
once
the
list
exists,
how
are
they
being
used?
I?
Guess
it's
just
simply
the
client
referring
to
the
list.
You
know
opportunistically
optionally.
I
should
even
add
to
try
to
determine
what
it
is.
The
server
supports
before
they
kind
of
configure
the
server
and
worst
case.
If
they
send
a
bad
value
to
the
server
it
will
fail.
You
know
RPC
air,
the
request,
so
maybe
there's
no
need
to
have
a
leave
for
effort
with
this.
B
E
Okay,
so
the
answer
martin's
question
the
oh
well,
there
is
because-
and
we
didn't
actually
actually
can
you-
is
it
possible
to
go
back
to
slide
number
five
just
quickly,
so
on
slide.
Five
you
can
like
well
in
particularly
you
can
see
here
those
if
feature
statements,
the
one
symmetric
key.
The
asymmetric
was
right
in
the
yeah
and
one
asymmetric
key,
the
those
are
CMS
structures
which
are
more
complex
or,
let's
say,
less,
common
commonly
used
than
the
raw
key
values.
E
E
It's
preferred
to
use
those
structures
because
they
do
two
things:
they
actually
internally
embed
the
algorithm
identifier,
which
is
somewhat
redundant,
and
maybe
we
should
gloss
over
that
fact,
because
a
lot
of
structures,
embed
values
that
are
also
I'll.
You
know
redundantly
expressed
outside
the
structure
but,
more
importantly,
it's
necessary
to
you.
Oh,
they
also
support
attributes.
E
So,
for
instance,
a
private
key
can
be
tagged
with
attributes
that
it's
only
to
be
used
for
signing,
or
it's
only
be
used
for
encryption,
or
you
know
these
kinds
of
things
that
what
in
TLS
certificates
might
be
referred
to
as
key
usage.
So
these
one
or
these
that
one
asymmetric
key
structure
has
the
ability
to
capture
the
key
usage
where
the
raw
value
has
no
way
of
doing
that.
So
in
some
applications
it
may
be
important
to
use
the
CMS
structure
over
the
raw
value
just
to
have
that
ability.
E
But
then,
lastly,
it's
actually
necessary
to
use
these
structures
the
the
one
asymmetric,
key
and
and
one
Selectric
key
structures.
If
you
wish
to
encrypt
the
keys,
there's
just
no
other
way
of
or
no
standard
way,
I
should
say
to
encrypt
or
Express
keys
that
have
been
encrypted
other
than
by
using
these
structures.
So
in
all
of
that
response,
what
I'm
trying
to
say
is
I
view?
The
use
of
these
structures
is
sort
of
advanced
you.
You
know
the
the
the
simple
get
it
to
market
as
quickly
as
possible.
E
Application
is
unlikely
to
want
to
support
these
advanced
structures,
hence
the
desire
to
put
them
under
feature
statements
and,
more
specifically,
answering
your
question
you
asked
about.
Should
we
have
config
false
lists?
I,
don't
think
we
need
to
have
config
false
lists
like
the
ones
that
we're
talking
about
here,
because
we
have
a
feature
statements
and
you
know
you
connect
to
the
server
you
go
to
gang
library.
You
ask
the
young
library.
What
features
do
you
support
that
is
in
a
way,
a
config
false
list
of
of
those
features
that
have
been
supported.
E
E
Okay,
right
actually
I
think
Martin
I
had
this
very
conversation
on
the
list
and
in
the
reply
to
that
question,
I
was
thinking
that
the
degree
must
statements
whereby
in
the
SSH
I
guess
this
would
be
the
the
IETF
SSH
server
and
ITF
estate
client
modules,
where
they
are
using
the
asymmetric
and
symmetric
key
structures
that
we
was
on
the
screen,
a
few
slides
back
when
they're
using
those
groupings.
They
would
refine
them
with
a
must
expression.
E
That
would
say
the
SSH
key
must
be
an
ssh
public,
key
and
and
and
and
not
a
cannot
be
a
subject
public
key,
whereas
in
the
TLS
module
it
would
be
saying,
though
it's
my
statement
will
just
be
saying
that
it
must
be
a
subject
public
key
and
not
a
necessary
public
key.
So
I
think
we
could
enable
those
downstream
modules
that
are
using
those
groupings
to
to
cause
to
in
inject
that
discrimination.
E
I
B
H
Yes,
so
Rob
Wilson
said
going
back
to
the
question
on
the
second
question:
I
think
it's
almost
the
same
answer
as
before.
That
I
think
we
solve
this
as
part
of
wider
capabilities,
work,
I,
think
and
so
I
think
what
you're
suggesting
are
just
saying
you
update
the
description
statements,
I
think
that's
fine,
I
think
that's
sufficient
for
this
I
wouldn't
try
and
do
anything
more
sophisticated
here
to
keep
it
simple
now
and
say
this
could
be
solved
in
future.
Hopefully,
if
there's
interest,
okay,
great.
E
E
Okay,
so
what's
currently
published
in
crypto
types,
12
and
trusts
or
seven
is
actually
no
longer
current
in
the
sense
that
the
you
know
the
the
submission
window
closed
and
but
after
it
closed,
there
were
ongoing
discussions
on
list
that
that
kind
of
moved
the
ball
down
the
road
a
little
bit.
So
for
those
that
reviewed
that
the
drafts
that
are
currently
published,
you
know
this
and
work
on
the
list.
This
may
be
new,
but
an
early
review
of
those
particular
modules.
E
So
so
and
remember
what
we're
talking
about
is
for
a
number
of
years,
we've
had
already
the
notion
of
symmetric
keys
and
asymmetric
keys,
and
what
we're
talking
about
here
in
TLS
normally
uses
x.509
certificates,
but
it's
also
possible
to
use
raw
public
keys
and
symmetric
keys.
But
what
is
the
raw
public
key?
Well,
that's,
basically
an
asymmetric
key.
What
is
a
pre-shared
key?
E
Well,
it's
basically
a
symmetric
key,
so
that
was
the
observation
that
was
made
by
the
other
participant
of
balázs,
cake
and,
and
so
the
thinking
was
you
know,
rather
than
defining
new
types
and
groupings
specific
for
Rob
puppies
and
ppreciate
keys,
such
as
those
that
you'll
find
inside
crypto
type
12
and
Trust
or
seven.
Instead,
can
we
not
repurpose
the
existing
groupings
that
we
have?
That
makes
a
lot
of
sense
to
me,
and
so
the
proposal
that
was
on
list
and
on
screen
is
essentially
to
a
in
trust
or
I.
E
Think
it
on
in
the
current
public,
published
document,
you'll
find
there's
a
list
of
raw
public
keys.
There
have
been
better
trusted
and
then
also
the
list
of
the
pre-shared
keys
that
were
trusted
and
so
that
the
lists
appreciate
keys
have
been
removed,
actually
not
specifically
because
it's
an
overlap,
but
because
it's
unnecessary,
if
you
are
having
a
pre
shared
key
I,
mean
it's
a
shared
key.
So
your
that
that
same
symmetric,
key
value,
that's
being
used
both
sort
of
as
your
private
key
and
also
as
as
the
public
key.
E
But
it's
not
saying
private
and
public
doesn't
make
sense
because
is
symmetric,
the
same
key
value
and
it's
a
secret
value
and
you'd
want
that
secret
to
be
stored
in
key
store,
not
in
trust
or
so.
The
observation
being
is
that
that
value
would
be
stored
in
the
key
store
and,
and
you
wouldn't-
we
wouldn't
want
it
to
be
also
stored
in
the
trust
or
the
exact
same
value.
So
so
simply
we
removed
pub
pre-shared,
keys
or
PS
case
from
trustor,
but
but
kind
of
that's
that
itself
is
not
really
following
the
statement.
E
I
was
just
making
above
here
you
see,
there
are
certificates
in
separately,
also
raw
public
keys
I.
We
could
have
a
discussion
if
we
want
to
I
mean
these
are
different
things
right,
so
it
was
certificate.
Is
it
is
a
public
key?
That's
been
signed
by
an
issuer,
so
that's
a
particular
thing.
Raw
public
key
is
well
it's
you
know
it's
not
having
any
of
that
extra
attribution
associated
with
it.
E
Sorry
before
I
go
to
right
hand,
side
going
down
to
the
bottom
of
the
key
store.
There
was
also
in
a
key
store.
Well,
actually
there
wasn't.
When
I
had
worked
with
me
to
update
the
trustor,
we
did
not
actually
update,
also
the
key
store,
but
there
was
some
discussion
about.
Should
we
also
be
able
to
image
key
store,
and
so
that
and
oh
we
would
find
it.
It
would
be
necessary.
First
thought
was
well
previously.
E
We
had
a
symmetric
keys
and
symmetric
keys,
and
so
the
first
naive
was,
let's
add
all
also
to
that
list.
Rob,
cookies
and
PSK,
so
it'd
be
a
total
of
four
things
or
four
descendants
underneath
the
key
store,
but
then
upon
the
observation
that
really
Rob
appliques
are
asymmetric,
keys
and
and
PS
Ches
are
symmetric
keys.
We
collapse
them
and
and
now,
if
they
are
as
sort
of
the
proposals
as
they
are
on
the
screen,
I
think
I'll
pause
right.
There
I
see
Hank
there's
at
the
mic,
yeah.
I
Yeah
again,
this
is
Hank,
so
I
think
there's
a
distinguishing
feature
that
we
are
collapsing
but
is
not
applying
to
both
sides
of
the
coin,
which
is
but
I
try
to
come
to
before
the
key
IDs.
So
pre-shared
keys
have
preferred
an
even
sometimes
very
strong
recommended
way
to
identify
the
pre-shared
keys
because
there
can
be
multiple
of
them
and
that
is
different
to
other
symmetric
keys.
I
So
so
I
agree
with
the
notion
that
apparently
pairwise
symmetric,
keys
or
pre-shared
keys,
whatever
you
want
to
call
them,
are
symmetric
because
in
the
new
interpretation
of
the
acronym,
it
literally
says,
pairwise
shared
a
symmetric
key
sorry,
and
so
that's
true,
but
the
pre
shared
key
identification
and
typically
you'll
go
with
an
ID
into
the
system.
We
don't
have
the
hash
always
or
something
more
concrete,
but
at
the
ID-
and
there
is
recomended
identity
hints
for
PS
case
for
TLS
and
I
think
these
do
not
apply
to
all
symmetric
keys.
I
E
E
You
know
the
lists,
and
so
there
was
a
key
value
and
it's
called
name
and
it's
an
arbitrary
user
specified
name,
that's
how
you
could
distinguish
one
key
from
the
other,
but
you're
actually
referring
to
a
value
that
needs
to
be
communicated
in
the
wire
okay.
So
that's
a
reason
for
needing
to
actually,
you
know
have
a
distinct
thing
there
for
for
those
values.
Can
we
take
that
up
on
the
list?
E
We
see
host
keys
and
raw
public
keys
and
there's
a
question
of
you
know:
should
there
should
these
two
things
be
merged,
possibly
I
mean
a
host
key
is
effectively
an
asymmetric
key
value
and
a
rope
of
caves,
nature,
metric
key
value
and
so
I
mean
there's.
The
encoding
I
mean
I,
understand
that
you
know
when
we
think
about
SSH
house
keys.
We
we
think
about
that
texturized
format
that
you
know
so
that
kind
of
an
encoding
and
but
remember
separately.
We
have
the
key
format.
E
There's
the
algorithm,
there's
a
key
format
that
we
discussed
previously.
So
it
seems
that
maybe
trust
door.
We
could
really
just
have
one
of
these.
Two
things
could
be
merged
and-
and
then
you
know
for
those
that
are
used
for
SSH,
the
key
format
would
say
it's
a
it's
an
SSH
key
and
for
those
that
are
being
used
for
other,
it
would
be
the
other
kind
of
encoding
that
be
specific
for
that
the
key
format
would
be
different.
So
that
was
my
that's
my
question.
Thornton
group,
any
comments
or
thoughts.
E
Okay,
I
think
that
particular
one
probably
requires
a
little
modeling.
You
know
where,
or
you
know
examples
where
we
play
it
out
and
see
how
it
go.
It
seems
it
seems
possible,
it
seems
viable
and
if
there's
an
opportunity
to
simplify
things,
we
should
so
there'll
be
a
something
to
explore
as
we
move
forward
with
this
okay
next
slide,
please
slide
3
slide,
13,
okay.
E
So
what
would
the
impact
of
having
raw
public
keys
and
pairwise
symmetric
or
appreciate
keys,
be
on
to
the
TLS
model
and
and
mind
you
we're
talking
about
the
TLS
model
and
not
the
SSH
model,
because
the
notion
of
using
these
values
are
really
specific,
with
TLS
I'm,
not
I
mean
SSH
with
us
a
sage,
they
do
have
different
kinds
of
keys,
they
talk
about,
I
mean,
will
they
have
public
key
and
then
with
ahem
public
key?
They
also
have,
for
instance,
certificate
based
public
keys
and
PGP
based
public
keys.
E
E
So
there's
this
TLS
client
grouping
and
a
similar
impact
would
be
to
the
TLS
server
grouping
and
in
this
grouping
we
have,
for
instance,
client
identity,
and,
of
course
you
know
if
the
client
is
going
to
identify
itself
using
well,
it's
called
pub
key
or
preacher
key.
But
it's
you
know
if
it's
pub
key,
it's
actually
having
a
private
key.
E
So
that's
what,
if
it's
identifying
himself
using
its
public
key,
then
of
course
the
server
needs
to
be
able
to
authenticate
it
using
a
public
key,
and
so
the
impact
is
going
to
have
is
could
be.
You
know
having
two
impacts.
What
one
you
know
where
the
client
is
trying
to
identify
itself
or
the
server
side
and
by
itself.
Secondly,
where
the
client
is
trying
to
authenticate
servers
or
the
servers
are
trying
to
authenticate
clients.
So
that's
why
we
have
the
impacts
in
two
locations
and
in
both
locations.
E
The
impact
is
kind
of
similar
in
a
sense
that,
where
there's
a
choice
and
and
like
it's,
the
choice
part
is
only
the
identity
but
nonetheless
that
we
enable
there's
a
there's
a
variation
right.
You
can
for
client
see
there's
a
choice
because
you
can
I,
don't
know
I
wanted
about
to
say
you
can
only
identify
yourself
and
you
think
one
strategy
I'm
not
sure
if
that's
totally
true
but
I,
think
it
is
true.
E
So
you
kind
of
pick
one
you
want
identify
yourself
using
a
PSK,
it's
a
you
would
pick
that
choice
and
and
do
it
that
way,
but
when
you're
authenticating
it
that's
actually
becomes
more
of
a
multiplicity.
You
have
a
really-
and
this
is
like
references
to
trust
or,
for
instance,
so
there's
many
kinds
of
certificates
and
many
kinds
of
keys
for
all
public
keys
that
could
be
used
for
authentication
purposes.
So
that's
more.
It
doesn't
need
of
a
choice.
E
It's
more
of
a
union
because
you
know
you
have
a
multiplicity
of
clients
that
are
coming
in
and
one
client
may
be
using
one
choice:
you
versus
another
strategy,
so
it's
not
a
choice
there:
okay!
Well,
anyway,
that
is
the
current
impact
and
I
don't
have
a
question
per
se.
I
just
wanted
to
bring
it
to
the
working
groups
attention
next
or
actually.
If
there
is
a
comment,
I,
don't
think
I
see
anyone
standing
at
the
microphone
so
next
slide.
Please
so.
E
And
there's
only
four
more
slides
or
really
two
more
content
slides
after
this
one,
so
I
think
we'll
be
okay.
Thank
you.
Okay.
So
we
spoke
about
the
impact
to
the
TLS
model.
There's
also
impact
to
the
Netcom
from
restaurant
models.
So
we
spoke.
You
know,
if
was
if
okay,
so
the
clients
can
identify
themselves
using
our
PK
or
PS
k.
We
also
talked
about
the
server
team
to
be
able
to
authenticate
the
clients,
but
in
addition,
the
servers
need
to
be
able
to
extract
a
username.
You
know
what
is
the
net
comp
username?
E
So
once
a
couple
options,
maybe
would
be
one
to
define
PSK,
to
name
and
RPK
to
name
maps
now
and
the.
Why
do
it
now
I
mean?
Is
it
like
to
extent
if
I'm
needed
now
or
to
just
leave
those
definitions
for
some
future
update
and
not
worry
about
it
now
and
I?
Think
that's
probably
a
good
place
to
pause
any
comments.
H
Robert
insist
so
I
mean
I,
don't
know
how
important
this
is
I
if
there's
a
choice
and
it
makes
sense
you
can
defer.
This
I
would
suggest
it's
better
to
try
and
defer
this
and
get
the
drafts
finished.
So
that's
my
preference,
but
if
this
is
required
for
this
to
work,
then
we
need
to
do
it
now,
but
I
don't
know.
E
Yeah,
but
within
our
working
group,
or
you
know,
looking
at
common
restaurant
protocols,
I've
I've
never
heard
anyone
ask
for
this
support.
The
desire
for
wanting
to
add
support
for
PSK
and
our
RPK
I
mean
theoretically
as
possible,
and
it
probably
should
be
supported
within
the
in
the
fullness
of
time.
But
the
immediate
use
would
be
more
and
Hank
was
the
one
that
was
asking
for
this.
E
I
E
That's
right,
so
there
you're
right
theoretically
is
is
there
someone
could
want
to
use
them
and
if
they
want
to
be
as
him
medon't
do
these
mappings,
that
they
just
simply
can't
and
unless
they
create
their
own
mappings
but
I.
Think
that's,
okay,
I
think
the
working
group
we
could
decide
to
just
not
worry
about
that
into
the
problem
arises
completely.
So
we're
aware
that
there
would
be
a
hole
in
the
solution
and
we
with
our
eyes
open,
say
it's:
okay,
Kent.
F
E
Yes,
exactly
so
first,
yes,
it
would
be
an
installation
I
as
we
were
just
saying
and
and
then
secondly,
exactly
we
just
simply
not.
Can
we
leave
him
out?
I
mean,
I
think
what
you're
asking
is.
Can
we
somehow
make
it
be
that
clients
cannot
use
them?
I
I
can't
respond
to
that.
Just
right
now,
I
mean
like
it.
Can
there
be
a
must
expression
or
something
like
that,
but
that
could
be
used
to
restrict
the
syntax.
So
that's
not
possible.
E
I
need
to
look
at
that
just
a
little
bit
more
okay,
so
I
think
I
said
it
earlier.
Can
we
jump
ahead
really
just
go
to
slides
forward,
please
for
client
authentication,
there's
actually
the
repeater,
that's
especially
by
client
authentication.
First,
we're
going
to
talk
about
local
versus
external
and
in
the
currently
published
versions
of
TLS,
Bob
Wills,
there's
a
local
or
external
flag
to
indicate
if
the
client
authentication
should
be
different
inside
or
outside
the
data
model,
specifically
where
where's
Lister
client
a
fine
and
you
know
sort
of
life.
E
E
So
the
only
case
that
remains
between
the
local
case
but
adding
a
feature
statement
to
the
local
case
so
that
it
would
only
you
know
for
those
servers
that
wanted
to
find
clients
locally,
they
could
I,
enabling
that
feature
statement
and
otherwise
it'll,
be
it
be
on
their
own
to
define
where
the
client
authentication
is
going
to
configure
themselves
separately.
So
that's
the
current
strategy.
If
it's
no
object
from
this,
will
any
any
comments
yeah
and
in
this
interest
of
time,
I
think
we'll
just
move
forward.
Please!
E
Yes
again
still
talking
about
client
education,
but
but
now
required
versus
optional
in
the
currently
published
version,
so
the
TLS
they
should
be
dry.
So
this
is
not
with
SSA
Jo,
TLS
and
HTTP.
There's
a
required
versus
optional
flag
to
indicate
if
client
authentication
must
succeed
at
that
protocol
layer
or
not-
and
this
isn't.
E
However,
recent
unless
discussion
is
led
to
the
following,
which
is
essentially
the
removal
of
this
choice
completely,
because
primarily
a
code
that
I've
been
working
on,
isn't
using
the
flag,
rather,
it's
keying
off
of
what
credentials
have
been
configured.
So
you
know
in
the
client
list
that
we
spoke
about
two
slides
prior.
We
in
in
each
client
definition
the
client
may
have
a
password
configure
and
separately.
It
may
have
a
TLS
trust
anchor
configured
if,
if
it
has
a
password
configured,
then
my
code
says
well,
you
must
authenticate
using
HTTP
basic
off.
E
E
Well
I
know
I,
know
Martin's
nodding
his
head
because
he
agreed
on
list
when
we
had
that
discussion.
So
if
there's
no
objections,
then
we'll
it
will,
the
next
update
will
remove.
It.
Just
has
been
discussed
there,
and
so
that
is,
oh
I'm.
Sorry
I
said
differently.
There
is
one
more
two
more
slides
please.
E
This
is
the
last
slide.
There's
a
certificate
name,
fingerprint
mapping
currently
both
in
the
ITF
and
restaurant
server
models.
There's
a
search
name,
grouping
that
map's
the
client
certificates
to
the
user
name.
The
grouping
currently
is
containing
mandatory.
True
for
a
node
called
fingerprint
and-
and
so
the
observation
here
is
that
in
what
I
think
could
be
a
common
case
deployment
scenario,
it
would
be
unnecessary
to
have
to
define
that
fingerprint
all
the
time
that
you
know
a
deployment
would
have
sort
of
a
deployment
wide
strategy.
You
know
they
have
an
issuer.
E
The
issuer
is
signing
all
of
their
certificates,
the
same
way
and
and
the
user
name
is
put
in
the
same
field
for
all
the
certificates,
and
so
the
strategy
for
how
extracting
username
from
a
from
a
certificate
is
universal
and
and
hence
the
need
to
identify
the
fingerprint
of
the
certificate
you
know
and
and
in
order
to
figure
out
the
extraction
strategy
is
the
unnecessary
or
redundant
effectively?
And
so
you
know
the
thinking
is
well.
E
We
like,
let's
remove
this
mandatory
true
because
it's
is
not
required,
always
and
so
in
the
current
model,
when
using
the
grouping,
it
refines
the
mandatory
true
to
a
mandatory,
false
and
so
two
aspects
to
that.
First
off
it
does
not
impact
existing
behavior
so
for
for
those
who
like
to
use
certificate
and
they
want
to
always
specify
fingerprints,
they
still
can
it's
just
giving
them
the
option
to
to
not
specify
it
if
they
don't
need
to
or
want
to
or
I
should
say
have
to,
and
the
second
aspect
is
really
what
Martin
was
saying.
E
Is
that
doing
this
wouldn't
need
to
be
used
with
care,
but
isn't
that
the
case
with
all
things
in
security?
You
know,
if
you,
if
you
the
the
certificate
of
name
mapping,
it's
a
list,
it's
a
user
ordered
list
from
a
yang,
modeling
or
seeing
syntax
perspective.
It's
not
actually
user
by
it
I
should
say
ordered
by
user.
E
H
J
I
G
I
You
thank
you.
Okay,
we
have
old
school
young
notification,
probably
everybody
knows
about
them.
We
now
have
the
three
rfcs
that
are
young
push
and
and
very
big
space
of
new
types
of
notifications
that
can
be
emitted.
Some
of
them
are
originating
from
changes,
data
stores,
some
of
them,
are
originating
from
action,
notification,
statements
and
young
module
definitions.
I
All
of
these
can
produce
light
quite
a
lot
of
yang
telemetry.
There
will
be
flows
of
notifications
and
these
flows
might
be
aggregated
at
some
point
and
even
on
the
mirror.
That
is
the
yang
data
store.
There
might
be
a
quite
of
a
lot
of
original
sources
of
notification,
statements
and
all
instances
in
this
case,
and
these
could
be
already
bundled
at
the
the
source
later
on.
In
this
dream
they
could
be
bundled
by
young
agents
and
immediately
so
there
is
then,
a
specific
need
for
metadata
how
to
do
this,
which
modules
are
involved.
I
What
it
is
about.
These
are,
of
course,
all
informations
that
are
inside
the
tons,
so
to
speak
notification,
instances
in
the
bundle,
but
if
you
just
want
to
have
fast
processing
of
these,
let's
call
it
telemetry
content.
Its
value
SFIL
to
have
some
explicit
metadata
at
the
top
of
the
notification
bundle
so
effectively.
It's
the
no
notifications,
but
with
a
header,
that's
probably
the
bundle
header
with
metadata
in
it,
and
then
this.
So
there
are
some
explicit
changes
in
the
last
iteration
of
this
draft,
especially
we
removed.
K
I
Potential,
the
capability
of
transporting
something
that
is
not
a
yang
notification.
Everybody
was
a
little
bit
like
this
is
net
conf.
Why
are
you
doing
I?
Don't
know
an
RTP
notification
message
here.
This
is
not
the
right
place
for
that
acceptable
and
true
I
think
it
can
be.
It
could
be
augmented
in
again
if
you
want
this
on
a
custom
basis,
and
everything
in
the
drafts
at
the
moment
is
purely
notification.
Based
now.
I
Yes,
an
interesting
question
has
come
over
the
list.
How
do
I
know
that
my
receiver
is
capable
of
doing
that?
So
this
basically
goes
back
to
a
note
of
drafts.
That
would
be
a
place
where
it
is
easy
to
highlight
our
capabilities
lie.
I
think
the
group
has
to
find
use
of
it
in
the
first
place.
I
think
it
has,
because
this
survived
under
version
8
of
the
draft
now
but
I
don't
know
because
I'm,
not
a
young
expert,
that
I'm
not
come
expert.
I
B
So
as
a
contributor
yeah,
so
there
is
interesting
covering
receiving
support
I
take,
but
the
transport
might
decide
what
might
be
used
like
in
our
case,
we
use
options
to
discover
a
receiver
support.
So
the
question,
then,
is
the
format:
how
would
the
receiver
capabilities
be
documented
so
that
when
Greg
do
you
know
all
the
capabilities
that
the
receiver
has
mm-hmm?
So
that's
something?
Surely
the
the
draft
can
take
up
a
chapter.
I
You
can
come
up
with
capability
options
and
how
to
maybe
fine-grain
them-
maybe
not
even
I,
don't
know,
but
we
can
work
on
this
for
our
first
draft
and
then
give
it
to
the
group
and
if
you
can
find
out
of
this,
makes
sense,
I
guess
again,
I'm,
not
the
deep
expert
on
this
term,
so
I.
Thank
you
for
that
comment,
and
it
was
posted.
I
think
it
was
in
here.
I
know
some
of
our
own
contributor
was
posting
to
list
yeah.
I
Well,
if
you're
talking
about
yanked
elementary,
isn't
it
more
useful
if
you
focus
on
the
binary
representation,
therefore
have
all
the
values,
not
in
texts
but
as
a
binary
representation.
What
is
this
inferring
to?
Is
the
Cochran
work
in
the
constrained
environment
space
here?
I,
don't
have
an
answer
to
this
I'm
more
like
an
IOT
guy,
so
I
would
be
very
happy
not
to
waste
space
and
long
were
a
big
volumes
of
telemetry
with
human,
readable
text
and
XML
I
might
not
be
yeah.
I
This
might
be
just
my
point
of
view,
but
I
think
it
is
at
least
worth
considering,
and
we
could
highlight
I
think
the
question
is
on
the
list,
but
we
could
highlight
it
again
and
make
it
more
prominent
when
we
call
for
a
consensus
or
something
how
people
think
about
this
and
our
default
option
is
binary.
I
think,
and
this
has
to
be
bashed
yeah.
H
I
I
Away
and
that's
basically
it
so
last
question
on
the
slide
is
important:
is
there
some
significant
interest
in
doing
this
again?
The
context
is,
there
is
a
large
volume
of
notification
now
that
can
be
created,
and
you
have
to
manage
that
somehow,
which
is
not
highlight
on
the
screen.
As
there
are
cool
sources
week,
footer
are
items
that
are
highlighting,
for
example,
integrity
evidence
which
is
developed
over
in
the
remote
Association
working
group.
I
B
Closure
yeah,
so
just
a
quick
comment
on
and
I
think
we
still
have
the
whole
question
of
receiver
support
or.
L
Okay,
well
India
from
erikson,
hopefully
we're
getting
near
to
finalizing
the
ank
push
notification
capabilities
draft
so
just
a
basic
concept.
The
yank
push
capabilities
has
a
number
of
capabilities
and
it
would
be
good
to
know
what
these
capabilities
are
before
trying
to
get
the
notifications.
The
most
important
original
was
whether
one
change
can
be
supported
for
individual
data
nodes
or
not.
But
then,
since
then,
a
number
of
other
capabilities
were
added
to
the
data
model.
L
L
So
I
can
support
notifications
for
interfaces
generally,
but
not
for
interface,
statistics
or
maybe
I
want
to
be
able
to
support
notifications
for
gigabit
interfaces
because
they
are
new
hardware,
but
not
for
old
old
ones.
So,
if
needed,
then
you
can
specify
the
capabilities
but
per
data
node
and
data,
for
example,
interface.
Instance.
Always
if
you
have
a
more
specific
capability
definition,
so
you
might
have
a
capability
definition
saying
that
so
change
notifications
are
supporters
for
the
whole
node.
L
But
then
you
have
more
specific
definition
that
interface
statistics
on
change
as
a
support
is
not
provided
the
more
specific,
always
overrides
the
less
specific
okay.
So
there
have
been
a
number
of
updates
since
the
last
last
IETF.
We
add
these
two
capabilities
excluded
change
type.
So
for
unchanged
notifications,
we
can
say
that
we
I
only
want
a
notifications
about
the
create
or
modify
or
delete
operations,
and
I
can
say
that
I
only
want
some
of
these
and
this
already
supported
by
yank
push.
L
L
Also,
it
came
up
lately
that
in
some
cases
only
unchanged
notifications
we
might
be
supported
and
periodic
might
not.
If
you
think
about
it,
yep,
for
example.
For
example,
do
we
support
periodic
notifications
about
startup
configuration?
Probably-
and
we
don't
now
want
to
do
that
either
so
period
of
notifications
can
be
supported
or
not,
and
that's
indicated
we
have
a
restructure,
the
yang
module,
so
it
uses
the
node
selector
in
the
same
way
as
knock'em
access
controls,
which
is
basically
that
this
simple
slash
means
the
whole
data
store.
L
So
we
don't
need
a
special
modeling
level
for
this,
for
the
whole
data
store
is
just
indicated
by
the
simple
slash,
also
move
to
the
using
the
term
publisher,
because
it's
not
really
a
server
anymore.
Let's
say
in
case
of
80
HTTP
based
notifications.
In
some
cases,
the
term
server
is
still
there
because,
when
we
say
speak
about
which
data
stores
are
supported,
then
yes,
that
certain
net
cost
a
reskin
server
functionality,
as
requested
by
some
there's
explicitly
indication
that
this
works
both
for
nmda
anon
and
the
nmda
systems.
L
Really,
the
only
little
difference
is
that
if
we
are
speaking
non
nmda,
then
this
draft
considers
the
state
data
to
be
part
of
their
own
running
configuration
just
for
this.
The
purpose
of
these
drafts
is
not
a
general
statement
in
any
way,
and
also
I
updated.
Did
the
draft
to
follow
the
instance
file
format
draft
we
had
workgroup
last
call
and
I
have
up
the
published
update
since
then
sorry
for
it,
their
updates
were
published
yesterday
and
maybe
even
after
midnight
today.
L
One
upcoming
issue
with
these
updates
is
that,
if
instance,
data
format
draft
is
updated.
Then
that
impacts
there
at
least
examples
or
not
at
least
the
examples
in
this
draft,
so
that
will
means
that
whenever
the
instance
data
is
updated,
then
there's
a
need
to
update
this
there's
two
ways
to
handle
this
either.
We
continue
to
update
this.
Whenever
instance,
data
format
is
modified
or
we
kind
of
strip
out
the
metadata
part
from
from
there
examples
just
putting
their
three
dots
and
then
we
don't
need
these
updates.
L
And
yes,
this
is
the
how
the
data
model
looks
like
today.
I
hope,
it's
understandable,
and
so
we
have
the
publisher
level,
and
then
we
have
the
the
data
store.
But
the
data
store
capabilities
really
is
just
one
single
key
for
the
data
store,
and
then
we
have
the
per
node
capabilities,
the
capabilities
on
the
publisher
level
and
the
data
store
and/or
Ferno.
That
level
are
really
the
same
and
I
think
that's
the
end.
Yes,.
H
Rob
Alton
Cisco
just
a
couple
of
comments
for
your
knocking
node
instance,
identifier.
There's
now
that
definitions
sort
of
moved
into
our
six
nine
nine
one
bits,
so
you
could
pick
it
up
from
there.
I,
which
has
the
same
definition.
I
think
is
what
you
require,
but
they
have
dependency
on
that
document.
I,
don't
know
how
long
it's
going
to
take.
H
H
You
can
select
a
wildcard
for
interface
names,
but
we
would
have
cases
won't
be
useful
to
say
I
want
to
do
these
statistics
for
physical
interfaces
differently
from
tunnel
interfaces
or
sub
interfaces,
and
at
the
moment
I
could
have
you'd
have
to
list
every
single
interface
on
the
device
which
would
be
huge
and
dynamically
changing
or
the
the
wild-card
is
it's
too
generic,
so
I'm
not
sure
what
the
best
solution
to
that
is
I
mean.
Maybe
we
could
augment
it
in
with
additional
filters,
but
I'm
not
sure
where
that
breaks
the
logic
of
somebody
reading.
L
Yes,
the
data
tie
for
note
selector
could
have
could
be
taken
from
six
nine
nine
one
base.
It
would
delay
this
work.
I,
don't
know
how
6i9
progresses
I
think
we
will
not
be
reworking
knock'em
either
to
use
that
so
I
would
like
like
to
avoid
that.
But
the
main
reason
is
a
time
and
dependency,
I,
hope,
I,
understand
the
functionality
or
the
it's
the
same
for
more
specific
filtering.
L
L
Also
I
think
there
people
are
having
problems,
reading
expert
filter,
so
that's
an
end
and
yeah
expert
is
very
powerful
and
I'm.
Not
true.
Many
people
will
understand
it,
so
I
see
a
risk
there.
Also,
then
we
get
into
the
problem
of
overlapping
expert
filters
and
how
do
then
we
have
priority
between
them
and
how
to
handle
them,
so
my
preference
would
be
to
maybe
he
put
that
into
abyss
or
if
that's
really
needed.
Okay,.
M
M
J
M
B
B
The
first
one
is
related
to
binary
encoding
I
think
there
was
some
discussion
here
and
an
interest
and
desire
to
see
binary
encoding
supported.
So
assuming
that
the
publisher
does
learn
of
the
receiver
capabilities
and
we'll
talk
about
that
in
issue
number
three:
can
the
media
type
itself
be
used
for
communicating
binary
data?
So
as
an
example,
we
are
currently
saying
we
support
XML
and
JSON
and
the
there's
an
option
to
basically
add
sibour
to
that
media
type
list.
B
Any
comments,
questions,
okay,
I
see
some
thumbs
up
all
right.
The
second
issue
that
we're
tracking
is
for
whether
we
need
to
rename
receivers
to
HTTP
receivers,
and
there
was
a
question
of
course
that
this
should
ideally
have
been
defined
in
86
39.
But
since
each
draft
is
having
to
define
their
receivers,
the
question
was:
do
we
need
to
rename
it
to
be
transport
specific?
B
The
only
question
is,
if
it's
being
declared
within
the
namespace
of
the
model,
do
we
need
to
really
indicate?
For
example,
with
an
HTTP
node
of
that
it
is
a
http
receiver,
I
would
think
it
would
be
obvious
on
the
module
name
and
for
if
there's
any
concern
about
any
conflict.
Of
course,
then
the
each
receiver
is
being
declared
in
their
own
namespace.
B
Okay,
moving
on
to
the
last
issue
for
the
discovery
of
receiver
capabilities-
and
this
is
something
Hank
just
talked
about-
so
from
a
transferred
Pacific-
we
the
options-
I
either
eat
sorry,
either
to
use
options
or
get.
We,
of
course,
would
prefer
options
to
return
the
capabilities
of
the
receiver.
The
only
point
I
think
that
is
left
to
discuss
is
what
the
format
for
advertising
advertisement
of
those
capabilities
is
going
to
look
like
and
that's
something
that,
as
I
suggest,
the
other
draft
could
look
into.
B
So
among
the
list
of
capabilities
that
we're
currently
tracking
is,
of
course,
the
media
type
that
I
just
talked
about,
which
of
course
includes
sea
bore,
and
then
this
second
capability
that
we
are
looking
at
is
bundled
messages,
as
defined
by
the
notification
messages
trapped.
Alright,
any
comments
or
questions.
L
All
right,
you're,
good,
sorry,
bonjah,
Ericsson
I,
would
be
interested
that
they,
if
you
get
these
capabilities,
obviously
or
I
assume
you
don't
want
to
get
the
capabilities
for
every
single
HTTP
notification.
Then
probably
you
need
to
say
something
about
how
long
do
you
think
that
they
are
still
valid
or
caching
them
or.
L
D
L
That
the
second
is
about
security.
I
got
strong
comments
from
some
implementers
that
if
you
move
the
receiver
definition
outside
of
the
subscription
part,
so
the
indirection
to
its
own
own
data
model,
then
configuring
knock'em
will
be
quite
tricky
because
if
someone,
if
you
have
a
subscription-
but
someone
else
is
allowed
to
modify
the
receiver
under
your
subscription
because
it's
a
separate
data
tree
that
can
be
a
risk.
So
at
least
you
need
to
mention
this
in
security
consideration,
okay
and
third,
that
I'm
also
working
on
3gpp
and
3gpp.
B
N
The
question
was:
is
this
going
to
be
the
same
capabilities
as
available
next
week
last
week
or
whatever,
and
the
the
goal
really
would
be
to
have
the
same
kind
of
capability
exposure
as
we
have
for
the
kind
of
capabilities
exchanged
when
net
cough
or
rest
cough
law
again,
and
you
find
the
capabilities
out
for
the
server
so
that
the
idea
behind
that
at
least
that
I
had
for
this,
was
that
we
don't
want
to
have
the
same
life
cycle
of
capabilities.
That's
done
with
other
types
of
transport
establishments.
L
By
in
net
cough,
the
capabilities
are
connected
to
the
session
lifetime.
So
that's
easy,
but
what
do
we
connect
the
capabilities
lifetime
here?
I.
N
O
O
One
is
a
subscribe
notification
it
I
already
be
published,
and
that
is
cannot
allow
the
user
to
subscribe
user
to
subscribe,
multiple
streams
in
a
single
message.
Another
is
a
notification
bundle,
but
is
northern
providers
ability
to
specify
to
explicit
specifies
a
relationship
of
different
and
notification?
Are
you
different
streams?
And
here
a
some
use
case?
There
are
two
years
case
a
one
full
bunk
subscription,
the
other
full
bank.
This
one
full
bunk
establishes
a
subscription.
The
nazzer
is
for
bank
the
latest
subscription.
O
We
can
see
it's
a
user
need
to
send
three
message
to
establish
a
subscription
to
subscribe,
the
module
for
more
the
bar
and
the
model
parts
same
time
if
we
to
dilate
ate
it
all
so
new
to
us
in
the
story
message
to
delay
today's
subscription,
but
if
we
had
can
have
a
capitated
allow
the
user
to
send
only
one
message
to
subscribe:
3
even-
and
we
also
can
allow
the
user
to
use
only
one
message
to
delay
this
mess
strings.
A
similar
idea
is
okay.
O
O
To
provide
a
flag
to
shows
a
explicit
relationship
between
these
different
streams
and
are
also
different,
a
unit
module
which
can
help
the
user
to
punc
subscribes.
It's
a
concern,
Matt
well
I
can
send
only
one
message
for
multiple
streams
and
also
you
allow
the
publisher
to
report
multiple
streams
or
raising
separate
ways.
A
group
ID
here
is
a
module
over
wheel
and
the
way
define
the
group's
list
with
group.
L
O
Maybe
multiple
streams
focus
on
hope
if
we
want
to
collect
the
devices,
some
stated
data
and
this
data
are
cryto,
is
collected
for
the
same
times
and
the
way
can
bound
owes
is
and
defined
as
a
state,
her
newest
group.
So
we
can
only
use
one
group
ID
in
the
subscription
a
separate
subscription,
so
we
can
okay,
it's
a
bundle
subscribes
and
we
also
can
receive
this
state
data
in
only
must
one
message,
so
we
can't
voice
in
case
and
help
to
reduce
the
you
know
the
interaction
between
the
continent
server.
M
B
F
H
Rob
Wilson
Cisco,
just
a
quick
question:
is
you
go
back
I
think
prettiest
slide,
maybe
no
one
more
in
this
case.
Can
you
also
use
a
sub-tree
filter
to
achieve
the
same
effect
so,
rather
than
actually
having
to
have
separate
subscriptions
for
the
different
paths,
food
bar
and
Baz?
Could
you
use
a
sub-tree
filter
that
would
achieve
the
same
things
you
still
end
up
with
one
subscription
and
using
the
sub-tree
filter
to
achieve
the
same
thing
so.
H
M
Actually,
I
think
in
some
cases
before
they,
obviously
you
manage
it
and
maybe
not
a
correlated
in
Chasseur.
So
may
you
may
make
assumption
you
need
to
tag
a
such
kind
of
obstacle.
You
need
to
correlate
with
each
other,
so
use
these
sabbatarian
filter.
May
it
doesn't
work
actually.
So
that's
why
we
introduced
a
new
google
ID
ID
to
help
you
to
correlate
different
object
and
maybe
not
irrelevant
to
each
other
apparently.
But
the
button
in
some
use
cases
in
some
context
is
a
you.
M
H
K
Can
you
come
back
one
slide
this
one?
So
if
I
understand
correctly,
this
is
going
to
be
useful
in
the
after
over
there
were
you
going
to
delete
it's
all
the
members
of
the
group
in
one
go.
This
is
the
main
advantage
right,
yeah
then
I'm
monitoring.
It
was
a
big
enough
problem
to
solve
right
because,
yes,
you
have
multiple
groups
of
young
object
that
you're
streaming
and
then
okay,
maybe
you
have
to
delete
them
one
by
one,
but
actually
it's
because
you
don't
care
any
longer.
O
Is
not
a
need
to
do
everything
in
one
group
it
because
you
want
to
subscribe
the
same
Kratt
eristic,
it's
based
on
your
want
to
do
it's
so
long,
you're.
What
what
you
want
to
salt
or
a
use
case
based
on
your
use
case
it.
If
you
need
to
subscribe
to
send
a
sim
cross-state
sync
rustic
data,
you
can
bundle
it
in
streams.
O
O
N
Questions
were
already
hit
that
I
had
one
other
thing
that
is
not
explicit
in
there
is
you
have
one
filter
as
Rob
was
mentioning,
and
you
could
probably
get
away
with
this
with
one
filter,
but
have
you
thought
about
having
or
what
the
implications
of
having
different
filters
might
be
for
that
for
each
individual
screen?
I.
Think
that
that's
an
interesting
question,
because,
knowing
how
many,
how
many
filters
might
be
interesting
and
whether
the
group
is
actually
applicable
would
be
would
be
something
to
work
through.
B
O
B
Okay
in
it,
so
you
we
are
all
the
time
on
this,
but
I
think
you
should
take
into
consideration
the
comments
that
you
have
received
to
lower.
They
all
seem
to
be
around
the
use
case
that
you
have
up
there,
which
doesn't
seem
to
justify
the
need
to
bulk
manage
a
set
of
subscription.
So
maybe
you
need
to
work
on
the
use
case
a
little
bit
and
come
back
with
a
better
way
to
a
why
this.
O
B
P
P
Actually,
the
notification
capability
has
already
been
defined
in
on
in
that
coffin
allocation,
compatibilities
and
another
critic.
Notification
capabilities
model
allows
the
client
to
discover
young
possibilities,
such
as
maximum
number
of
objects
can
be
sending
updates
or
supported
appearance
of
chaotic
subscription
without
using
notification
communities.
It's
leads
to
an
unexpected
failure
or
additional
message.
Exchange
for
Netcom
clients
and
in
a
state
of
our
subscriptions
of
a
particular
subscriber
to
be
fetched
is
huge
field.
P
Inquiries
of
approach
of
operational
State
on
a
server
can
greatly
reduce
the
amount
of
the
data
to
be
stream
out
to
the
destination,
and
this
is
the
most
important
effect
of
the
notification
capabilities
actually
actually
in
the
existing
yum
post
telemetry
mechanism.
In
the
existing
the
jump
in
the
existing
mechanism,
the
young
post
telemetry
can
provide
a
mechanism
you
subscribe
to
second
sub
to
subscribe,
and
you
select
some
operational
days
stated
data
based
on
the
selection
filter
past.
P
P
In
some
situation,
for
example,
in
the
in
some
situation,
may
be,
the
clients
want
to
change
the
selection
filter
for
the
case,
the
case,
the
service
main
EQ
may
will
be
terminated
and
may
need
to
be
updated,
and
a
few
and
the
human
intervention
may
need
to
be
involved
generally
say
for
the
exist
in
the
existing
mechanism.
His
heart
Fournier
Kafka
lines
to
automatically
select
which
data
objects
of
interests,
for
example,
to
identify
a
set
of
objects
which
have
a
common
which
have
common
characteristics.
P
To
address
this
issue
in
this
document
will
provide
a
tenant
dynamic
way
to
specify
the
selection
filter.
Most
specifically,
we
tagged
characteristics,
data
object
and
an
instructor
client,
all
other
subscribers
or
subscribers
choose
a
selected
operation,
select
the
operation.
We
record
the
self
explanation
in
this
drafts.
P
With
the
self
explenation
information
we
can
fit,
we
can
further
filter
the
queries
of
a
personal
state
or
more
thorough
and
we
can
correlate
the
data
objects
across
the
modules
which
have
the
common
characteristics
and
we
can
reduce
the
large
amount
of
data
to
the
destination
we
argument
out.
We
argument
is
the
notification.
Comparability
is
a
module
to
the
notification,
no
technical
abilities
attributes
and
with
this
experience
we
can
specifies
which
type
of
the
object
is.
Can
it
can
be
pushed
to
choose
the
targeted
recipient.
P
P
Need
to
take
the
note
in
each
device.
Model
T
indicates
the
data
that
has
the
common
characteristics,
for
example,
here
the
the
module
for
it
can
be
like
ietf,
the
can
be
IETF
interface
module
and
no
days
can
be
like
in
discards
package
or
the
note
B
can
be
like
the
aero
package.
We
tag
the
note
a
in
the
WP
performance
metric
and
for
the
second
step
we
automatically
advise
the
tag
from
the
like
roster
to
the
NMS,
to
the
NMS
and
in
the
third
step
we
subscribe
our
interest.
L
Well,
I
enjoy
Erickson
I,
see
this
effort
and
I
heard
about
at
least
one
more
where
we
want
to
define
different
types
of
note,
capabilities
or
data,
those
capabilities
of
the
server
which
I
think
is
generally
a
good
idea,
but
it
somehow
conflicts
with
I
was
instructed
by
this
group
to
keep
my
draft
to
notification
capabilities.
Now
we
are
stretching
the
word
notification
or
in
this
I
don't
know
the
solution.
I
think
the
general
idea
of
providing
such
information
is
good,
but
how
to
handle
it.
K
But
not
less
so
I
could
see
some
use
cases
for
this
while
I
wasn't
a
big
fan
of
the
tags
for
yang
modules.
I
see
some
value
for
attacks
for
data
nodes
and
I
believe
that
if
we
want
to
do
it
right,
we
have
to
exactly
augment
balázs
draft
for
a
notification,
because
that's
the
right
way
to
do
it,
but
then
we
have
to
observe
it
goes
way
beyond
beyond
telemetric
abilities
right,
but
I
think
that
this
is
a
right
way
to
do
it.
Yes,.