►
From YouTube: IETF-CORE-20230315-1500
Description
CORE meeting session at IETF
2023/03/15 1500
https://datatracker.ietf.org/meeting//proceedings/
A
B
So,
for
those
those
who
came
in
just
came
in
there
is
a
link
in
the
chat
pointing
to
the
notes
it's
useful
to
have
the
notes
open,
because
there
are
some
links
in
there
to
specific
documents.
You
may
want
to
follow,
and
you
may
also
want
to
download
the
slides,
because
there
are
links
in
those
slides
but
I
hope
they
mostly
are
the
same.
So
maybe
you
can
just
get
by
with
the
notes.
B
B
A
Now
also,
okay,
let's
start
so
welcome
everyone
to
this
interim
meeting
of
the
co-working
group.
I'm
marketing
automatic
chairs
are
having
Jimenez
and
Kirsten
Morman
and,
as
usual,
the
not
well
applies
so
not
well,
it's
not
just
about
IPR
patents
and
so
on.
It's
also
in
the
special
about
our
code
of
conduct.
So
please
be
nice
with
each
other
and
we're
being
recorded
as
usual.
A
The
agenda
for
today
is
about
going
the
current
status
and
open
points
for
two
documents
from
the
core
comp
cluster
umai
and
then
a
number
of
points
covered
by
documents
in
different
working
group
related
to
different
aspects
of
the
young
Encore
ecosystems.
That
Carlson
noted
was
proper
to
bring
up
any
more
topics
you
imagine
to
discuss
today
or
any
agenda
bashing.
B
C
B
Okay,
so
this
is
just
my
introductory
slide
to
remind
everyone
where
the
call
working
group
is
on
this
work.
We
managed
to
publish
a
document
that
describes
how
to
interchange,
young
model
information
using
sibo,
that's
RFC,
9254
and
that's
kind
of
the
basis
for
for
the
work
that
we
will
be
doing
today,
and
we
have
a
number
of
other
drafts
in
various
stages
of
processing
and
and
maybe
the
most
important
at
this
time,
I
will
spend
a
large
part
of
this
meeting.
B
Discussing
look
at
City
location
aspects
is
the
corset
draft
that
describes
a
process
to
actually
get
the
numeric
identifiers
allocated
that
may
make
Yang
sibo
so
efficient,
and
we
will
talk
about
this
document,
but
we
also
will
talk
about
yang
the
young
allocations.
The
city
allocations
for
a
pwan
and
Laura
has
some
some
slides
for
that.
B
B
So
this
has
been
stable
for
a
while,
but
there
has
been
implementer
feedback
and
also
there
is
a
bug
in
the
original
specification.
The
version
11
that
needed
to
be
fixed,
so
we
have
generated
a
slightly
simplified
version,
dash
12
and
we
should
discuss
whether
this
is
done
or
should
be
reverted
or
should
be
made
even
more
simplified.
B
And
finally,
we
should
briefly
talk
about
Yang
Library,
which
is
the
fourth
document
in
the
cluster,
which
probably
has
less
of
a
problem,
but
yeah.
We
need
to
make
sure
it
makes
sense.
Okay,
so,
based
on
that,
the
the
agenda
is
focusing
on
on
City
allocation
and
then
commai,
simplification
or
optimization.
And
then
we
go
into
the
three
areas
called
Yang
Library
Yang
models
relevant
to
core
and
binary
Yang
push
and
I
would
like
to
do
the
silly
location
in
about
half
the
time.
B
B
So
during
the
isg
processing,
we
did
enough
substantive
changes
that
we
thought
it
would
be
a
good
thing
to
do:
a
working
glass
Hall
and
yes,
it
was
a
good
thing
because
we
got
we
got
feedback
in
particular
from
DNA.
That
told
us
well,
there
are
some
bugs
in
there
and
we
have
to
work
on
that
and
yeah.
We
think
that
that
revision,
Dash
20,
is
dealing
with
Rob
Wilton's
disgust,
but
we
are
currently
waiting
on
feedback
from
him.
The
the
thing
we
did
was
adding
status
information
to
Sid
files.
B
Okay.
So
let's
talk
about
the
the
oops
yeah,
the
remaining
problem
that
that
came
up
and
and
the
other
problems
actually
all
stemmed
from
the
fact
that
we
don't
really
have
a
good
tool
to
validate
the
example
content
and
the
Sid
file
specification
against
each
other.
So
we
have
done
some
some
manual
fixes,
but
really
we
would
like
to
have
more
support
from
the
peaking
tool.
B
So
if
anybody
of
you
has
some
some
python
experience,
maybe
you
want
to
think
about
helping
us
getting
a
version
of
P
Yang
that
actually
solves
the
problem
that
we
are
trying
to
solve.
So
the
the
one
thing
that
we
aren't
sure
about
yet
is:
does
the
current
version
of
PNG
actually
generate
a
complete
set
of
synths
and
to
answer
this
question,
of
course
we
first
need
to
understand
what
the
complete
set
should
be.
B
This
is
the
next
slide
and
then
we
probably
should
be
evolving
P
Yang
to
emit
this
complete
set.
Of
course,
we
can
always
do
things
manually,
but
we
will
make
mistakes
more
mistakes,
I
think
when
we
do
this
manually
than
when
we
have
a
tool
doing
that
for
us.
So
so
the
the
first
priority
should
be
on
getting
p
and
to
emit
the
full
set.
B
So
we
we
have
one
for
current
daytime,
but
not
really
one
for
current
date.
Time,
input
and
it's
also
not
quite
clear
that
that
the
the
Set
current
date
time
current
daytime
is
actually
correct,
because
it
might
be
necessary
to
include
the
the
input
element
into
the
the
instance
identifier
here.
So
this
this
is
kind
of
the
first
question
we
we
need
to
understand.
Is
this
a
change
we
need
to
make
and
are
we
attaining
completeness
when
we
have
done
this
change
or
are
we?
B
Are
we
missing
out
on
on
further
examples
of
of
this
problem?
Do
we
have
any
other
schema
nodes
that
aren't
captured
by
pnget
but
need
to
be
in
the
sit
fire
to
be
able
to
use
the
whole
module
of
a
cockroach
so
that
that's
really
the
first
question
we
we
need
to
understand
and
I
would
would
be,
would
appreciate
if
people
would
air
their
their
view
of
this.
D
E
D
B
B
B
F
B
F
So
yeah
I
think,
like
Andy,
suggested
in
another
middle
of
the
in
the
the
same
work
group.
All
all
schema
nodes
should
be
should
be
mapped
because
that's
the
only
way
to
ensure
I
know
future
proofness
of
of
this.
This
RFC,
you
never
know
if
people
will
end
up
deciding
to
to,
for
example,
serialize
a
a
choice
or
case
statement
which
are
both
usually
not
instantiated
in
in
data
instances.
F
D
B
So
then
we
have
an
example
of
a
protocol
that
actually
is
important
enough,
interesting
enough
that
we
do
want
to
run
a
manual
allocation
process,
we're
talking
about
running
over
millibit,
Networks
or
AP
wins,
and
so
it's
worth
putting
some
time
in
there
and
has
prepared
some
slides,
so
I
think
I
will
stop.
Presenting
and
Laura
can
take
over.
G
The
army-
yes,
okay,
perfect,
so
thank
you
Captain,
so
I
will
present
what
it's
a
personal
presentation.
We
don't
have
discussed
that
right
now
at
the
lp1
working
group,
but
so
in
everyone
working
group,
we
we
are
designing.
We
have
designed
a
Chic
mechanism
that
allowed
to
do
compression
and
it's
based
on
rules.
G
G
So
right
now
we
have
a
NFC
that
has
been
published
is
93
9363,
that
represents
the
young
data
model
for
C
Cruise,
and
if
we
we
can
use
pyang
to
convert
it
into
a
seed
file
or
with
identities
and
data.
It
is
encoded
right
now
and
then
we
have
a
guard
of
some
seeds
that
can
be
reserved
for
for
future
evolution.
G
So
one
of
our
very
important
point
that
we
we
have
in
for
shake
is
that
it
has
to
be
flexible
and
we
can
have
different
people
that
develops
new
or
extends
the
basic
young
data
model
and
that's
why.
For
example,
we
don't
use
enum
for
identity,
but
we
use
identity
because
it's
there
is
no
no
conflict
between
them.
So
it
means
that
in
each
model
we
we
create.
We
can
have
a
lot
of
identities.
G
So
the
the
problem
is
when
we
we
want
to
extend
the
basic
young
data
model,
so
we
will
create
somewhere
else,
a
new
seat
file
that
will
use
a
new
another
range
of
SIDS.
And,
of
course,
when
we
will
code
the
data,
then
we
will
have
the
Delta
encoding
and
if
the
Delta
is
too
too
large,
then
instead
of
one
byte,
we
will
use
two
bytes
or
even
three,
three
bytes
or
five
bytes.
G
So
for
this
example,
I
took
a
space
that
looks
for
me
reasonable.
It's
5000,
it
looks
to
be
free
and
I
took
500
seats
for
that,
and
so
the
way
we
proposed
to
do
the
allocation
is
not
to
have
identity,
then
datas
and
identities
than
data,
but
to
have
two
different
blocks
where
one
where
we
will
have
identities
and
one
where
we
have
data
so
identity.
We
don't
care
that
much
because
the
value
is
still
in
the
data
in
as
as
he's
in
in
the
data
in
the
model
in
the
data.
G
So
it's
the
size
is
not
it
doesn't
matter,
but
for
data
it's
important
to
have
as
close
as
possible,
so
the
the
ID
to
to
do
that
is
to
insert
a
gap
of
23
value
between
each
list
said,
and
then
we
fill
these
these
gaps
with
the
list
that
are
the
most
important
for
the
data
model.
So
here
we
we
have
a
an
example
of
that.
So
here
we
have
the
the
cedar
location.
G
So
we
don't
start
at
the
first
value
we
have,
but
we
go
23
value
after
which
means
that
we
can
use
the
minus
to
cut
some
extension
to
to
the
model.
So
here
in
the
scheme
you
have
in
blue
the
leaf
ietf,
shikshik
I,
don't
know
if
you
you
can
eat
with
it
well
and
then
you
have
in
Blue
on
the
left,
columns
the
negative
deltas
and
the
positive
Delta.
G
So
then
we
we
have
in
five
five
thousand
forty
seven,
the
next
list,
so
we
install
a
gap
of
23
but
overlaps,
the
one
from
the
the
blue
one.
So
that's
why
we
have
also
column
in
green
and
we
have
in
570
5070.
We
have
the
same
thing
for
entry.
Where
we
have
a
gap
of
23.,
then
we
fill
with
the
most
important
notes
on
one
funny
things:
we.
We
discover,
for
example,
that
it's
rule
ID
value
and
Rule
ID
length.
That
are
something
that
you
find
in
all
the
rules.
G
If
we
use
the
the
regular
pyong
allocation
since
it's
based
on
alphabetic
order,
so
the
Delta
will
be
higher
than
23,
so
it's
not
optimal.
For
each
rule.
We
are
losing
two
bytes
for
each
rule.
For
for
that
and
after
that,
so
we
have
all
the
the
information
and
on
the
left
right
on
site
colon.
You
have
the
identities
that
start
at
5
300,
which
leave
or
the
value
between
0
and
250
for
data.
G
So
here
are
some
mathematics
of
what
we
have
right
now
in
in
the
pipe
for
young
data
model
for
Chic.
So
we
have
the
basic
One
Source
from
RFC
9363,
so
it's
92
identity
to
feature
and
42
data,
and
if
we
do
so,
what
we
have
proposed
here
is
to
use
30,
300
values
for
this.
For
external
ability
and
identity
start
at
3,
5
030..
We
have
a
draft
on
OEM
which
will
use
10
identity
and
one
data
Access
Control
extra
extra
value.
You
have
them
on
on
the
picture.
G
So
that's
what
we
so
I
think
that
what
we
have
to
discuss
in
vlp
one
working
group
is
how
we
allocate
this
value
and
for
which
Leaf
we
say
we
can
allow
a
very
small
Delta
and
for
all
the
value
that
are
not
so
used
in
the
model.
We
can
use
the
larger
deltas
and
for
the
process
by
itself.
It
doesn't
change
that
much.
It
means
that
in
that
case,
we
will
publish
a
seed
file
with
all
the
leaves
from
The
Young
data
model.
But
here
it
will
be
done
by
manual
allocation,
foreign.
B
Does
not
change
at
all
because
because
it
doesn't
require
you
to
actually
use
pigeon
or
any
other
tools.
The
important
part
is
that
you
can
get
the
range
from
Ayanna
and
then
you
can
fill
in
this
range
by
whatever
is
best
for
for
the
protocol
that
that
you
are
defined
so
I
think
we
are
in
a
pretty
good
shape
on
the
corset
side,
but
yeah.
It's
really
interesting.
What
what
comes
up
when
you
want
to
do
this
properly,
and
my
question
was:
how
do
we
check
this?
G
D
Question
I
hope
it
doesn't
cause
any
side
tracking,
but
this
is
being
done
for
a
specific
protocol
because
it
it
makes
like
VAR
bind
like
retrieval
better,
because
if
you
put
gaps
in
and
there's
siblings
in
in
the
request,
the
the
Delta
you
just
made
the
Delta
larger,
because
now
there's
all
these
gaps
that
wouldn't
have
been
there.
So.
D
D
That
what
I'm
talking
about
is
the
Sid
allocation.
If,
depending
on
what's
getting
returned,
the
the
Delta
to
the
next
table
is
now
greater
than
it
was
going
to
be
before,
because
it
was
only
going
to
be
about
four
SIDS
away,
and
now
it's
24
kids
away
all
right,
so
at
least
unless,
unless
none
of
the
tables
have
keys
or
leaves
so
you
know,
there's
there's
a
trade-off
it.
It
isn't
like
all
out.
You
know
that
works
in
in
all
kinds
of
retrievals
that
keeps
it
down
to
one
bite.
B
D
What's
really
great
about
the
current
encoding,
it's
very
clever
is
because
it
is
alphabetically
sorted
like
that.
It
ends
up
that
all
children
of
of
the
parent
actually
get
allocated
in
that
first
23
and
and
it's
there's
almost
no
Yang
models
that
that
have
23
or
you
know
more
than
23
child
nodes
of
a
parent.
D
You
were
showing
things
with
four
leaves
in
it,
so
the
way
Delta
Sid
Works
once
you
start
the
the
table,
then
the
you're
going
to
be
on
the
child
nodes
and
and
you're
all
the
Deltas
from
then
on
for
that
table
will
be
like
less
than
23.
Almost
you
know
almost
95
99
of
the
time,
but
but
I
don't
want
to
you
know
so
so
for
whatever
I,
don't
I,
don't
think,
there's
any
problem
with
this.
As
Carson
said,
it's
it's
just
manual
allocation
and
the
the
validation
is
hard.
C
B
I
think
that
that's
good
input
in
the
end,
of
course,
we
need
to
construct
the
realistic
example
and
then
simply
measure
which
off
of
the
approaches
of
doing
this,
actually
helps
most
and
I.
Think
what
what
Laura's
doing
here
is
improving
the
the
locality
at
the
the
lower
levels
of
the
tree,
including
future
additions
to
that
tree,
which
we
don't
know
that
you
don't
know
yet
at
the
cost
of
reusing
the
localities
higher
up
in
in
the
tree.
D
B
D
Yeah
I
didn't
bring
this
up
before
because
it
makes
things
more
complicated,
but
for
protocols
that
really
care
between
one
and
two
bytes.
You
really
want
a
range
that's
down
at
the
bottom.
That's
just
for
what
what
I
call
left
hand?
Side,
I,
mean
right
hand,
side,
sorry,
I
got
it
backwards,
so
it's
it's
never
used
as
a
Delta,
so
if
the
actual
value
was
6
million,
that's
what
you'd
put.
D
So
but
that
would
be
more
complicated
having
like
a
range
just
for
identities
and
and
then
you
have
to
allocate
a
range
from
the
identities
and
range
from
the
objects,
so
I
didn't
so
I.
Don't
think
it
should
really
go
there,
but
obviously
the
the
lower
ranges
need
to
be
reserved
for
iots,
where
numbers
are
stay.
Small.
G
G
B
B
B
B
B
That
doesn't
go
into
a
UI
query
that
goes
into
URI
path
and
the
the
1533
is
essentially
Basics
before
encoded,
but
the
basis
64
encoding
is
for
byte
strings,
so
we
defined
a
numeric,
an
integer
base64
encoding
that
is
essentially
based
on
on
six
bit
digits
on
64.0
to
63,
digits
and
1533
turns
out
to
be
X9
in
in
that
encoding.
So
the
whole
path
is
X9,
then
a
question
mark
and
and
of
course,
and
then
the
rest
of
the
key
and
of
course
in
any
cases
you
won't
have
a
key.
B
B
Well,
actually,
it's
more
than
that,
it's
not
just
the
the
string
is
zero,
but
it's
also
the
information
that
this
is
the
text
string.
It
could
be
something
else,
okay,
so
the
the
sibo
encoding
of
the
is
zero
is
five
bytes,
and
then
we
divide
the
five
by
three
and
multiply
by
four
and
and
so
we
get
the
seven
bytes
that
we
actually
have
to
the
right
side
of
the
question
mark.
H
B
B
Okay,
so
that
would
make
this
slide
number
10
kind
of
overtaken
by
events,
because
it
essentially
tells
how
to
further,
simplify
this.
By
by
just
doing
the
same
thing,
you
would
do
for
a
veg
but
just
base
it
64,
encoding
it
in
the
UI
and
otherwise
sending
it
as
a
fetch
payload
for
for
the
fetch,
but
I
think
that
that's
a
pretty
useful
input
that
maybe
we
can
just
get
rid
of
that
complexity
and
streamline
this
good.
B
So
Yang
comes
with
Yang
Library
model,
which
essentially
allows
a
client
to
find
out
what
models
are
available
on
a
server
and
some
specific
properties
of
those,
and
when,
when
we
started
this
work
Michelle,
who
has
defined
many
of
the
things
that
we're
using
today
came
up
with
simplified
Yang
library.
That
is
useful
for
constraint
devices.
B
So
server
a
constrained
server,
which
is
the
the
normal
situation
here,
because
we're
trying
to
manage
the
constraint
devices
because
drain
server
would
use
this
form
of
a
young
library
to
announce
it's
available
models
and
so
on,
and
this
was
done
like
five
or
six
years
ago.
So
it's
probably
a
good
idea
to
check
which
parts
of
the
Yang
ecosystem
actually
have
changed
enough.
That
today,
you
would
use
somewhat
different
Yang
Library
than
the
one
you
would
have
used
five
or
six
years
ago.
B
And
one
question
is:
are
there
any
fundamental
changes
in
which
Yang
libraries
are
used,
but
also
are
there
any
small
updates
like
like
the
the
update
we
had
to
do
to
replace
rest
conf
data
with
SX
structure
and
so
on?
So
that's
really
a
question
to
to
the
Yang
experts
and
to
the
people
who
know
how
that
that
part
of
the
ecosystem
looks
like.
F
B
F
B
Okay,
most
likely,
we
will
do
another
worker
plus
call
on
this
document
as
well,
but
yeah.
It
would
be
good
to
get
some
some
indication
of
whether
we
have
to
do.
We
do
a
lot
and,
of
course
the
limiter
stuff
is
was
one
of
those
major
changes
in
the
ecosystem
that
that
I
was
alluding
to,
and
that
is
already
in
there,
but
I'm
wondering
whether
there's
anything
else
so,
for
instance,
for
notifications,
so
cool.
E
Looking
to
through
the
draft
now
so
apologies
if
I'm
missing
something
skimming
it
so
from
an
implementation
perspective.
What
would
be
very
convenient
for
me
is
if
I
can
fully
implement
this
as
let's
call
it
compile
time
data
on
the
device
and
just
throw
it
from
the
flash
of
my
compiled
binary
back
to
the
client
and
not
have
to
talk
calculate
these
values
in
practice,
meaning
that
all
the
values
here
are
fixed
or
depending
on
compile
time,
information
and
I
think
that's
the
case.
B
B
B
B
B
Obviously
we
need
to
do
these
things
to
to
demonstrate
that
we
are
eating
our
own
dog
food.
Some
of
these
young
models
actually
turn
up
both
in
constrained
and
non-constrained
environments.
So
this
the
the
data
might
actually
come
from
a
random
netconf
implementation
that
throws
this
into
some
some
system.
That
then,
actually
makes
the
constraint
the
access
to
the
constraint
device
to
get
the
rule
data
or
the
the
connection
configuration
configured.
B
So
that
that's
maybe
one
one
thing,
that's
a
little
bit
different
from
other
cases
we
have
had,
but
in
the
end
all
of
these
actually
need
to
work
in
the
constraint
space
and
that's,
of
course,
pretty
much.
What
what
the
whole
Crossing
is
about,
that
not
everything
is
constrained,
but
the
protocols
we
are
doing
also
need
to
work
in
in
a
constraint
environment.
B
So
one
thing
that
that
we
could
try
to
examine
is:
is
there
anything
we
can
learn
from
these
young
models
that
allows
us
to
to
make
call
conf
better
still,
and
we
just
learned
from
it
when
that
that
alternative
Arrangements
of
the
SIDS
may
be
something
that
that
maybe
looked
at
without
even
having
to
change
the
the
standards.
The
specifications-
and
the
other
thing
of
course
is
then,
are
there
any
best
practices
that
we
can
extract
from
this
models?
B
G
Yes
about
the
eight
Docker
score
model,
we
we
use
the
binary
type
for
keys
and
if
you
look
at
something
that
is
done
for
in
in
I2,
NFS
group
is
that
they
use
X,
binary
or
X
string.
Something
the
type
for
a
young
type
that
has
been
defined
to
save
a
string
is
a
hexadecimal
value,
but
if
we
use
it
directly
in
coconut,
we
still
have
the
string
and,
of
course,
you're
not
optimal.
So
I
don't
know.
B
But
at
this
time
we
don't
have
that,
so
we
actually
need
to
make
sure
that
the
models
use,
something
like
binary
young
binary
to
represent
things
that
that
need
to
be
represented:
efficiency,
efficiency,
like
keys
and
and
hashes,
and-
and
things
like
that.
So
if,
if
you
want
to
import
a
model
that
doesn't
do
that
well,
you
have
to
change
it.
I
E
B
B
D
Comment
if
the
suggestion
is
to
tell
model
developers
to
use
the
data
type
binary,
to
make
an
opaque
encoding
of
something
else
that
isn't
going
to
fly
with
gang
doctors,
I
can
tell
you
and
the
operationally
making
the
code.
Work
is
sometimes
difficult
and
when
you
have
no
idea
what
you're
looking
at
and
you
have
to
trust
the
tools
to
tell
you
what
you're
looking
at
it's
it's
harder.
B
Yeah
there
there
is
a
tension
here,
because
yang
right
now
doesn't
allow
you
to
to
build
complex,
binary,
encodings
and-
and
we
have
learned
that
we
sometimes
have
to
do
that,
and,
for
instance,
cddl
has
some
some
support
for
nesting
data
into
binary
Springs,
like
the
the
DOT
sibo
control
operator.
So
we
cannot
do
this
as
easily
and
yang
as
we
can
do
that
in
cddl.
B
So
I
would
expect
that
we
will
use
binary
for
things
that
specifically
are
opaque
by
Nature,
like
like
he's
and
and
hash
values,
and
and
things
like
that,
and
that
we
are
not
trying
to
come
up
with
complex
binary
encodings
that
that
require
additional
code
to
look
at
them.
I
mean
looking
at
a
hash
is
not
really
very
useful
anyway,
so
you
might
as
well
use
binary
looking
at
the
key,
usually
also
isn't
very
useful
in
isolation.
A
D
B
I
think
that
that's
a
good
basic
rule
that
should
be
applied.
It's
just
that
we
don't
have
that
implemented
yet,
so
we
would
have
to
to
change
or
extend
Yang
sibo
to
to
have
better
support
for
that
that
than
we
have
today
and
today
you
can
just
only
Define
your
own
models
that
use
binary
in
some
way.
G
B
B
So
here
is
the
binary
value
and
when
you
get
that,
please
unpack
that
again,
but
we
haven't
used
that
in
Yang
sibo
at
this
point
in
time,
so
we
we
would
have
to
make
an
extension
to
Yang
sibo
to
allow
the
use
of
this
tag
to
to
make
this
particular
optimization.
Then,
of
course
you
want
to
do
the
same
thing
for
Mac
addresses
and
IP
addresses
and
and
date
times
and
a
few
other
pieces
of
data.
So
that's
the
development
project.
I
was
talking
about
okay,.
B
H
So
there
is
the
comparatively
simple
aspect
of
doing
the
encoding
on
the
sibo
side.
There
is
a
much
harder
aspect
of
knowing
when
to
do
that.
Actually
will
the
Yang
models
need
additional
information
to
know
that
say
something
is
not
only
a
string,
but
it's
really
a
string
that
contains
an
IP
address,
and
thus
you
should
use
tag54,
but
none
of
the
other
encodings.
That
could
also
do
this
so
like
some
some
some
application.
B
B
F
G
One
generic
comment
is
I
think
we
have
the
same
problem
with
XML
and
jizen
and
because
in
XML
everything
is
ASCII
in
season
you
have
number
and
as
keys.
So
when
you
do,
you
always
have
a
problem
to
do
a
conversion,
so
it's
so
in
in
siboyo.
You
have
something:
I
had
some
problem,
for
example,
for
checking
some
data
model
when
I
was
putting
onion
in
a
typedef
instead
of
in
a
container,
because
the
tool
were
not
going
that
far
to
say:
oh,
this
is
a
string
and
they
believe.
G
B
B
D
I
found
that
seabor
has
more
Fidelity,
more
information
that
it's
putting
on
The
Wire
than
either
Json
or
XML,
and-
and
it's
like
you
can
do
extra
validation
that
you
can't,
because
you
know
the
Yang
you
know,
and
the
Seaboard
tagging
is
more
specific,
then
yeah
Json.
So
it's
actually
I
think
the
encoding
I
want
to
get
rid
of
XML
in
netcomf
and
just
use
a
seaboor,
but
the
working
group
probably
isn't
ready
for
that.
So
we'll
take
a
while.
D
That's
related
to
tlvs
versus
content
analysis,
any
kind
of
encoding
where
you
have
to
like
scrub
the
content
is,
is
worse
than
seabor.
The
tlv
approach
is
is
much
better.
If
it's
right
as
soon
as
the
tlv
is
wrong,
then
the
whole
message
is
toast
that
since
one
downside,
but
if
it's
right,
it's
it's
much
more
efficient
and
even
more
accurate
than
than
the
other
two.
D
I
I
will
note
that
I
I
suggested
that
we
use
co-app,
as
as
the
transport
for
binary
anger,
push
and,
and
the
netcomf
working
group
is
no.
We
don't
have
to
solve
any
of
those
problems
that
co-op
had
to
worry
about.
We'll
just
do
this,
oh,
really,
okay,
it's
it's
to
call
it
seriously.
Weird
I
thought
it
was
just
just
kind
of
bad.
It's
really
not
not
a
binary
protocol
at
all.
As
you
point
out,
yeah
I
don't
know
that
it's
much
of
a
protocol
at
all
other
than
it's
just
here's.
B
D
I
I
don't
know
that
that
anyone,
but
the
authors
I,
think
there
is
actually
a
some
open
source
implementation
started.
I
only
brought
these
up
because
and
actually
the
the
second
draft
creates
a
little
structure
so
that
actually
gives
us
a
way
to
assign
the
SIDS.
That
was
the
thing
missing
before
is
and-
and
we
were
talking
about
needing
a
some
complex
special
case
solution
in
in
Seaboard,
but
we
don't.
We
just
just
need
that
struct
and
so
so
I
think.
D
D
B
B
D
I,
don't
think
that
that
this
is
in
scope,
but
it's
really
looking
perplexing
to
me
how
all
of
the
published
ietf
modules
will
will
get
Sid
files
if
it's
one
at
a
time,
it's
it's
not
gonna
work
and
it's
you
know
take
years
and
and
No
One's
Gonna
want
to
do
that.
It's
so
I
guess
that's
also
up
to
the
the
netcomf
working
group,
because
core
working
group
has
this.
D
B
D
G
Yes,
just
because
it's
the
end
of
the
session,
but
for
to
talk
to
of
Arc,
we
do
with
Alex
Fernandez
it's
because
now
it's
with
a
Sit
fight,
it's
easy
to
go
from
Jason
to
sibor,
but
in
the
other
direction,
it's
quite
complex,
because
when
you
have
an
INT
in
C
bar,
you
don't
know
if
it's
a
hint
if
it
is
int,
if
it's
enum
or
if
it's
an
identifier,
so
you
need
to
know
the
type.
So
one
way
is
to
go
to
the
young
data
model
to
to
look
at
it.
G
G
And
this
way
you
can
do
the
conversion
in
both
Direction
and,
for
example,
for
Chic
is
very
useful
because
you
have
manipulating
core
conf
and
when
you
you
want
to
validate
your
model,
then
you
can
change
it
to
network
to
rest
conf,
and
then
you
can
use
tools
like
yongsan
to
to
validate
it,
and
we
had
also
another
a
map
with
list
seeds
and
the
keys
that
are
related
to
that
list.
And
this
allows
the
process
automatic
process
or
to
to
pass
a
young
tree
without
knowing
what
you
you
have
inside.
G
F
C
Oh,
yes,
can
you
hear
me?
Yes,
cool,
so
hi
everyone,
just
my
Master's
students
here
in
yeah
Atlantic
with
long
and
yeah
I
was
working
with
Rafa.
Also
on
this
ad
hoc
and
Oscar
project.
I
was
doing
this
calling
called
it
Pi
core
conf
Library,
which
helps
doing
this
conversion
like
really
really
easily
from
either
XML
or
Json
to
core
conf
and
then
back
to
getting
a
python
dictionary
and
just
to
make
the
point
here
that
with
laurent's
Fork
of
pianga
getting
the
types.
B
A
So
we
hope
to
see
you
all
there
online
or
on
site.
We
plan
otherwise
to
resume
with
the
interim
meetings.
Second
half
of
April
and
we
thought
tentatively
of
April
26
and
to
keep
the
same
Cadence
and
time
every
other
Wednesday.
So
we'll
sync,
with
Seaboard
as
usual,
and
confirm
on
the
main
list.
Hopefully
already
during
the
ITF
week.