►
From YouTube: IETF-NETMOD-20230605-1630
Description
NETMOD meeting session at IETF
2023/06/05 1630
https://datatracker.ietf.org/meeting//proceedings/
A
A
B
B
This
is
a
formal
ietf
meeting.
That
means
our
usual
note.
Well
applies.
Hopefully
everyone
is
familiar
with
it.
I
see,
most
people
here
have
been
around
for
a
little
while
so
or
if
you're
not
familiar
with
it.
Please
take
a
look
at
the
ITF
page
and
look
at
the
note.
Well,
basically,
it
says
everything
we
do
here
becomes
part
of
our
permanent
and
public
record
we're
using
meat
Echo.
If
you're
on
the
on
here,
you
figure
that
out.
Thank
you.
Please
do
help
with
note.
B
B
Material
has
been
posted.
I
just
did
an
update
to
the
bgp,
slides,
I'm,
hoping
that
that
is
the
we'll
be
able
to
share
the
right
person.
We
really
only
have
two
topics:
interesting,
that's
supposed
to
be
five
minutes,
but
I'm
going
to
shortened
to
four
and
I'll
see
if
I
can
do
it
in
three
yeah,
the
intro
is
simply
what
you're
hearing.
C
B
Now
and
the
rest
of
the
time
is
going
to
be
split
between
Jeff
and
Mahesh,
as
they
see
fit
to
go
through
sort
of
a
deep
dive
of
something
we
touched
on
at
the
last
iatf
and
really
didn't
have
enough
time,
which
is
what
led
to
this
meeting.
We
are
recording
this
session.
The
hope
is
is
that
we
have
enough
good
discussion
and
material
that
this
can
be
used
as
a
reference
to
other
game
models
regaining
model
writers
in
the
future
and
with
that
I'm
going
to
try
to
switch
desks.
D
A
So,
while
the
slides
are
being
loaded,
my
name's
Jeff
Haz
and
the
hat
that
I'm
wearing
today
is
you
know,
one
of
the
co-authors,
with
Mahesh
and
the
bgp
Yang
module
and
we're
hoping
to
spend
a
little
bit
of
time
today.
Talking
about
our
experiences
and
working
in
Yang
and
the
ietf
tool
chains
for
developing,
you
know
what
is
a
very,
very
large
note:
module
and
interactions
with
all
the
other
modules
and
the
sort
of
very
long
path
that
we
took
to
get
there
leave
I
actually
can
change.
Slides
I
can
indeed
change
slides.
A
A
You
know
a
given
slide,
because
we
have
slightly
different
frames
of
reference
for
our
experiences,
and
you
know
what
we
sort
of
brought
to
this
process
and
Our
intention
is
to
leave
this
open
for
discussion,
because
you
know
things
that
we've
run
into
may
be
useful
for
other
people
to
discuss
in
terms
of
tools
issue.
Is
this
a
modeling
issue?
Is
this?
A
You
know
figuring
out
how
to
get
bits
of
ietf
to
work
with
each
other,
and
the
point
here
is
to
try
to
share
what
wisdom,
we've
actually
gotten
and
ideally
seek
wisdom.
Others,
and
our
hope,
is
that
long
term,
some
of
these
things
could
distill
down
into
other
things
that
can
help
people
at
ietf.
You
know
advance
and
make
progress
on
their
modules,
whether
they're
very
large
ones
like
we
had
that
work
on
or
very
small
ones,
yeah.
A
So
core
lessons
wise.
You
know
this
is
basically
the
agenda
that
we'll
be
working
through
today,
biggest
thing
that
you
have
to
worry
about
when
you're
working
on
a
module
is
what's
the
content
and
how
are
the
things
organized
you
know,
what's
the
structure
of
it
and
that's
a
hard
enough
task
to
start
with,
if
you
have
people
that
in
the
case
of
protocol
modules
or
similar,
you
know,
if
you
have
somebody,
that's
a
reasonable
protocol
expert.
You
know.
A
Usually
that's
not
a
hard
thing,
although
one
of
the
challenges
we
have
in
ietf
is
that
we
often
do
our
work
incrementally
through
rfcs
that
add
to
things
rather
than
reissuing.
Everything
like
a
one.
Gigantic
module
like
IEEE,
does
as
part
of
their
revisions,
so
the
consequences
trying
to
figure
out.
What
exactly
are
you
covering
and
you
know
which
features
you're
actually
trying
to
cover
whether
you're
trying
to
make
a
module?
That's
covering
everything
or
you're
planning
to
do
pieces
a
bit
of
time.
C
A
Augmentation
modules
as
an
example,
any
part
of
that
conversation
eventually
comes
down
to
modeling
of
things
you
know,
or
these
things
features.
For
example,
when
you
have
a
core
protocol
that
has
a
number
of
things
added
over
the
years.
You
know
how
do
you
handle
your
modeling
in
such
a
way
that
you
can
extend
the
model
and
basically
is
part
of
asking
somebody
to
implement
the
thing
not
effectively
asking
the
support
features
that
they
may
not
actually
have.
A
How
do
you
actually
author
a
module
and
know
that
you
will
not
get
it
right?
The
first
time
that
you
want
to
be
able
to
add
to
it
that
you're
going
to
want
to
deal
with
these
cases
where
you
have
new
protocol
extensions
to
add
in
not
only
you
know,
things
are
completely
brand
new,
but
simply
backfilling.
A
Some
of
the
stuff
you
may
not
have
chosen
to
do
on
day,
one
and
some
of
the
challenges
that
you
have
in
terms
of
maintainability
is
taking
care
of
version,
either
with
extensible
types
that
the
Yang
languages
give
us,
and
you
know
we
found
this
to
be
one
of
our
big
challenges.
I'm
sure
some
of
our
experiences-
we
are
certain
you
know,
since
we
haven't
actually
gotten
through
RFC
stat-
is
that
people
have
opinions
about
how
we've
done
this
and.
A
The
cases
they
may
disagree
with
how
they
gone,
and
hopefully
this
discussion
will
help
us
grow
it
ietf
wise
to
figure
out
how
do
we
solve
some
of
these?
You
know
interesting
challenges,
and
maybe,
if
we
go
on
to
revise
the
Yang
language
at
some
point
for
the
next
version,
you
know
are
these
learnings
that
we
can
take
on
to
maybe
extend
the
language.
A
The
next
travel
we'll
also
hit
through
a
number
of
examples
through
things-
and
you
know
it's
our
experience-
that
not
only
providing
examples
for
discussion
points
for
slides
is
a
useful
way
of
no
transferring
knowledge.
We
found
that
it's
necessary
as
part
of
the
document
authoring
process,
to
provide
examples,
integrate
them
into
these
tool
chains
test
them
out.
These
things
effectively
become
our
unit
tests,
proving
that
we've
actually.
A
Work
correctly-
and
this
would
be
one
of
the
slight
points
that
we
steadily
work
our
way
through
and
the
examples
You
Know
cover
as
an
exam
as
an
example
interworking
between
the
various
models
because
most
of
our
works,
some
of
them
are
very
Standalone
things,
but
the
vast
majority
of
our
protocols
don't
have
completely
independent.
You
know
life
spans
or
fate
sharing
from
each
other.
You
know
so
easy
consequences
are
you're
like
if
you
have
something
that
refers
to
interfaces.
This
will
often
point
off
to
other.
You
know,
standard
modules
and
ietf.
A
Finally,
you
know
one
of
the
things
we're
intending
to
discuss
is
collaboration.
How
do
we
go
about
actually
getting
the
work
done
when
there's
multiple
parties,
you
know
we're
scattered
around
the
planet.
We
have
you
know,
tool
chains
that
we
want
to
have
for
those
levels
of
consistency
with.
We
also
have
a
necessity
of
providing
some
level
of
track
ability
for
our
works,
especially
you
know
for
extremely
large
pieces
of
work
like
a
Yang
module.
A
A
D
A
Okay,
Jason
says
that
you
fix
his
audio
I'll
come
back
later,
I've
switched
my
headset
input,
I
was
noticing,
I
was
getting
ambient,
so
hopefully
I'm
a
little
bit
better
here
at
the
moment,
so
structuring
content
before
you
do
any
large
modeling
exercise.
You
have
to
know
the
things
that
you're
talking
about
you
know
and
unfortunately
for
ietf
we
don't
really
have
a
lot
of
good
introduction
to
modeling.
We
have
a
lot
of
people
that
are
deep
experts
in
various.
You
know
protocols
and
you
know,
as
a
consequence.
A
You
know
people
usually
know
what
are
the
sort
of
nouns
of
the
protocol.
What
are
the
things
that
actually
you're
talking
about
and
your
protocol
operations
when
we're
talking
about
protocols,
you
know
usually
have
some
level
of
verbs
and
relationships
to
each
other.
You
know
these
things,
make
it
significantly
easier
for
somebody.
A
So
the
biggest
piece
of
work
you
have
to
work
on
is
how
do
you
actually
draft
all
the
content?
You
know
the
B2B
Yang
stuff
in
particular,
went
through
a
number
of
iterations,
and
you
know
this
is
one
of
the
minor
points
that
we
did
change,
so
we
sort
of
refined
our
history.
So
a
slight
Point
here
from
ietf
116,
was
that
it
was
originally
are
thinking
that
the
original
bgp
Yang
work
had
started
by
people
who
began
open
config.
A
But
now,
as
we
sort
of
work
through
our
ietf
data
tracker,
history
found
that
it
actually
went
back
several
versions
before
that.
So
you
know
we
see
that
ietf.
Has
you
know
deep
Cycles,
you
know
some
work
actually
started.
Ietf
open,
config
people
got
involved
and
then
eventually
they
went
their
own
separate
way.
You
know
forking
for
their
own
specific
needs
and
OC
has
their
own.
You
know
culture
and
you
know
goals
for
things
that
aren't
necessarily
the
same
as
ietfs.
So
this
leads
to
some
of
the
interesting
comparison
points
later
on
easy
examples.
A
Being
that
you
know
the
goal
for
OC
is,
for
you
know,
modeling.
Basically,
the
generic
device
from
a
configuration
standpoint,
completeness
of
representation
in
the
protocol
Stacks
is
not
a
explicit
goal
for
them.
You
know
a
more
vendor
neutral
background
is
what
they're
looking
for,
whereas
an
ietf
we're
trying
to
provide
modeling
for
the
protocols
themselves.
You
know
we
may
not
have
quite
the
same
level
of
focus
on
configuration,
but
you
know,
certainly
in
terms
of
operational
state
you
care
about
modeling.
A
You
know
the
entirety
of
the
protocols,
maybe
one
step
more
than
they
do
as
a
project.
This
is
neither
good
nor
bad.
Now
they
just
simply
have
you
know,
places
that
the
overlaps
can
impact
specific
challenges
for
bgp,
and
this
is
true
of
a
lot
of
the
protocols
that
have
a
very
long
history.
You
know
pgp
is
a
protocol
of
many
many
extensions
and
it
took
us
a
lot
of
years
just
to
get
all
the
content
in,
and
you
know
if
somebody
says
well
what
is
bgp.
A
You
know
these
days,
you
go
off
and
say
this
is
RFC
4271.
So
is
everything
in
here
that
you
need
not
even
close.
So
one
of
the
challenges
is,
you
know,
based
on
the
fact
that
ITF
does
not
issue.
You
know
basically
update
rfcs
that
have
absolutely
everything.
That's
part
of
the
core
anymore.
We
have
to
figure
out
what
is
the
core
subset
of
modern
bgp
and
the
American
group
didn't
have
strong
opinions
on
these
things.
A
lot
of
people
seem
to
have
a
general
sense
of
things
like
well.
A
Bgp
does
route
reflection,
it
does
confederations.
You
know.
Has
you
know
a
bunch
of
comment,
extensions
like
communities
that
everybody
thinks
they
belong
in
the
the
core
of
the
protocol?
Well,
no,
it's!
These
are
all
extensions,
so
we
have
to
decide
what
to
do.
We
do
some
lines
in
the
sand
and
we
got
some
of
them
right.
We
got
some
of
them
wrong
and
this
consequence
there
is
an
awful
lot
of
feature
creep.
A
What
this
means
is
is
that,
as
a
consequence,
if
you
throw
all
the
contents
into
the
base
model-
and
you
had
to
go
through
iterations
of
you
know,
did
we
do
this
right?
No,
is
it
the
correct
modeling
for
these
things?
Is
the
structure
correct
this?
This
has
to
be
an
iterative
process
and
it
does
involve
not
only
passes
from
people
that
are
protocol
experts,
but
also
modeling
experts,
in
as
we
sort
of
get
through
is
other
pieces
of
the
presentation.
Is
the
usability
of
things
correct.
A
You
know
as
much
as
the
Yang
doctors
are
there
to
help
us
and
a
lot
of
things
about
the
you
know
nature
of
the
language
how
to
model
certain
things.
They
can't
help
us
with
everything.
You
know
they're,
not
experts
in
the
protocols.
They
won't
see
things
that
are
missing
from
the
content.
You
know
perspective
unless
they're
also
experts
in
the
protocol
in
question.
This
becomes
a
challenge
at
review.
Time
and
again,
you
know
just
to
emphasize
the
final
point.
You
know
this
re-examination,
you
know
from
those
three
perspectives
is
really
important.
A
And
you
know
this
is
theoretically
a
very
basic
thing
and
you
know
certainly
for
a
lot
of
people
they're
going
to
be
on
this
interim
that
are
coordinate
mod
participants.
None
of
this
stuff
is
technically
new,
but
these
slides
are
written.
For
you
know
many
of
the
audiences
in
ietf,
and
hopefully
this
is
you
know,
generically
useful.
A
A
You
know,
there's
no
need
to
have
absolutely
everything
present
as
a
mandatory
to
implement
components
inside
of
your
model
and
features,
give
us
a
way
to
add
those
optional
things
in
a
flexible
way.
The
problem
is,
it
complicates
the
model
in
many
perspectives,
makes
it
harder
for
the
server
to
decide
what
to
do
in
some
circumstances
and
clients
have
to
understand
you
know,
through
exchange
of
what
features
are
actually
being
used
by
the
server
to
know
locally
what
is
actually
being
handled
at
the
you
know,
client
end
of
things.
A
It
is
well
there's
some
features
that
if
you
don't
accommodate
for
them
up
front,
you
can't
necessarily
handle
the
modeling
changes
later,
especially
based
on
how
the
revisions
to
gang
modules
are
permitted
to
do,
and
in
particular,
the
biggest
thing
that
this
is
a
gotcha
to
look
out
for
is
for
list
keying.
That
was
an
example.
If
you're
doing
a
list
of
routes,
you're
not
allowed
to
really
change
the
keys,
you
know
that's
something
you
have
to
get
right
very
close
and
very
upfront.
Bgp
has
a
optional
extension
called.
A
Add
paths
that
allows
you
to
have
bgp
advertise
more
than
one
path
between
two
bgp
speakers
and
theoretically
is
an
optional
feature.
You
wouldn't
think,
though
this
doesn't
have
an
implant
impact
on
you
know
the
protocol,
but
since
you
need
to
be
able
to
model
consistently
a
set
of
exchange
droughts,
this
means
that
even
if
the
implementation
doesn't
support
ad
paths,
it's
necessary.
It
includes
the
path
ID.
The
path
index
is
part
of
the
list
keys.
A
A
You
know
thought
about
very
hard
up
front
is
where
most
of
the
extensions
will
get
added
on,
and
you
know
again,
we'll
emphasize
this
in
later
slides
being
able
to
look
back
and
say:
do
I
have
enough
of
a
skeleton
to
add
something
on
that
I
may
want
to
do
later,
even
if
you're
not
doing
it
today,
it
can
save
you
an
awful
lot
of
your
headache
and
some
of
these
things,
maybe
just
simply
strict
augmentations.
This
means
that
you
know
for
me
a
protocol
perspective.
A
You
can
add
things
on
that,
doesn't
have
a
lot
of
complexity
and
you
don't
have
to
worry
about
no
features
in
a
lot
of
these
circumstances.
So
one
of
the
key
learnings
here
is
an
attempt
to
try
to
think
ahead.
Can
we
do
the
work
so
that
it
is,
you
know,
done
primarily
through
augmentation,
without
necessarily
complicating
using
the
Yang
feature
statements
Jason.
You
want
to
try
again.
A
F
Can
okay,
great
yeah
I'm,
just
coming
back
to
the
same
point?
I'd
raised
my
hand
about
before
about
features
and
augmentation
I
know
in
discussions
in
our
versioning
work.
I
just
want
to
reiterate
that
you
know
this
way
of
doing
features
and
augmentation
where
things
are
additive
is
definitely
the
right
way
to
go.
F
We've
seen
in
in
I
think
3gpp
and
some
other
discussions
where
sometimes
standards-based
modules
are
have
other
modules
that
deviate
those
modules.
I,
don't
think,
we've
seen
it
or
at
least
in
our
group,
we
haven't
discussed
examples
in
ietf,
but
I
would
definitely
want
to
avoid
deviations
which
is
kind
of
like
a
subtractive
approach.
F
Similarly,
with
features
I
know,
it's
built
into
Yang
1.1
that
you
couldn't
say
something
like
if
not
feature.
Foo
then
have
some
Leaf
but
I
know
in
our
discussions.
We
we
think
there
may
be
some
problems
and
and
cause
that
could
cause
some
problems
and
be
fairly
non-intuitive.
So,
like
additive
things
like
features
where
it
adds
nodes
augmentations
where
it
adds,
things
seem
to
be
pretty
safe,
but
definitely
recommend
to
avoid
subtractive
type
techniques
like
deviations
or
not
foreign.
A
Where
we've
you
know
seen,
you
know
some
headaches
as
an
example.
Our,
inter
vendor
comparison.
One
of
the
pieces
of
the
work
that
we
try
to
do
is
try
to
construct
what
goes
into
things.
A
lot
of
features
know
that
are
part
of
the
core
protocols
strictly
identifiable
by
the
rfcs,
but
there's
a
lot
of
places.
Also,
where
you
know
vendors
have
added
on
de
facto
features
over
time
and
part
of
the
conversation
has
to
be.
A
You
know
what
do
you
do
about
those
you
know
they
if
they're
so
built
in,
but
don't
have
any
documentation.
It
comes
about
challenging
and
one
of
the
things
that
ends
up
challenging
on
them.
Half
the
time
is.
How
do
you
model
the
configuration?
Since
you
know,
in
a
lot
of
circumstances,
doses
are
not
standardized,
they
end
up
with
no
interesting
quirks
to
them.
You
know
they
pick
an
example
out
of
bgp
the
B2B
route.
A
Reflector
feature
has
a
no
client
reflect
that's
pretty
consistently
implemented
by
most
vendors,
but
in
our
modeling
work
it
turned
out
that
you
know
pretty
much.
No
vendor
had
exactly
the
same
place
where
they
allowed
configuration
for
it,
so
our
choice
ended
up
having
to
be.
We
were
going
to
skip
adding
this
feature
rather
than
make
for
complicated
deviations
out
of
it.
D
Yeah,
actually
I
was
going
to
remind
you
that
maybe
the
route
reflect
option
is
one
example
of
where,
as
Jason
mentioned,
we
want
to
avoid
deviation,
but
there
are
cases
where
we
were
not
able
to
add
the
features
simply
because
of
the
implementation
being
different
across
vendors.
For
that
particular
feature,
the
other
example
I
also
want
to
kind
of
I'll.
D
Probably
get
into
is
with
the
augmentation
is
in
the
schema
Mound
exam
example
in
particular,
but
let's
get
to
that
slide
and
I'll
talk
about
the
issue
that
we
ran
into
with
being
able
to
Simply
augment
and
realize
what
we
wanted
to
realize.
But
let's
wait
for
that
slide
to
talk
about
schema
Mountain,
how
it
affected
us
model.
A
Okay
and
depending
which
side
versions
We
have
uploaded
that,
maybe
when
you
have
to
display
from
your
desktop,
so
maybe
you
have
that
one
available
if
you
have
to
do
that,
so
one
of
the
other
big
buckets
of
things
we
had
to
worry
about-
and
this
was
part
of
our
continuous
re-examination-
was
maintainability-
it's
been
mentioned
multiple
times.
Bgp
gets
a
lot
of
extensions.
Many
of
them
are
completely
optional
versus
each
other.
C
C
Features
I
think
in
future
be
good
to
push
to
try
and
get
the
yam
models
designed
and
developed
in
conjunction
with
the
features
at
the
same
time.
So
if
the
vendors
are
thinking
about
those
management
models
at
the
same
time,
the
event
they're
depending
sorry
designing
the
features,
there's
a
much
greater
chance
that
they
will
be
able
to
reach
some
sort
of
commonality
and
agreement
on
what
those
models
should
look
like,
rather
than
sort
of
trying
to
retrofit
game
models.
A
Right,
that's
an
interesting
set
of
points
several
of
us
on
the
call
here
are
obviously
old
enough
to
remember
the
days
when
mibs
theoretically
were
a
required
piece
of
protocols,
especially
if
you're
trying
to
advance
some
of
the
standards
process.
Yang
is,
thankfully
significantly
better
than
SMI
was
to
do
representation
of
things,
and
it
means
that
doing
it
after
the
fact,
usually
is
one
step.
Less
painful
and
I
agree
with
you
doing
the
work
at
the
same
time
as
you're.
Actually
designing
the
feature
would
be
sort
of
Ideal.
I.
A
Think
the
challenge
we're
going
to
run
into
is
a
little
bit
the
same
challenge.
We
have
for
finding
anybody
who's
willing
to
do
modeling
work
at
all.
You
know
the
skill
set
that
it
takes
to
do.
Modeling
is
overlapping,
but
a
little
bit
different
than
protocol
design
and
trying
to
force
the
two
to
happen.
Maybe
for
the
same
author
set
may
be
an
interesting
challenge.
A
I'm
sure
this
is
a
conversation.
The
isg
should
take
up
at
some
point,
as
part
of
you
know,
long-term
work,
but
you
know
my
sort
of
initial
proposal
would
be.
We
want
to
have
the
coupling.
It's
probably
very
helpful:
I,
don't
recommend
it
being
a
strong
coupling
just
simply
because
no
Feature
work
should
be
able
to
advance.
A
The
industry
is
trying
very
hard
to
be
good
about
not
introducing
non-backward
compatible
things,
as
part
of
you
know,
modeling
work.
If
you
tightly
couple
things
that
thrash
at
the
modeling
into
things
and
the
modules
that
get
exposed
to
the
end
user
base,
you
know
gets
thrashed
as
well,
and
you
know
that
doesn't
really
help
the
industry.
D
The
example
that
actually
I
wanted
to
talk
about
was
the
color
definition
that
you
were
trying
to
add,
for
example,
in
the
model,
but
to
Rob's
point
just
like
we
require
implementations,
I,
one
or
two
implementations
of
anything.
That's
supposed
to
become
become
an
RFC
I
wonder
if
it
would
make
sense
that
manageability
be
a
requirement
at.
At
the
same
time,
the
definition
all
the
RFC
is
being
developed
for
that
particular
feature.
C
A
Okay,
let's
move
on
to
maintainability,
you
know
as
we're
talking
about
how
do
you
actually
structure
things?
That's
a
big
enough
piece
of
work
figuring
out.
How
can
you
actually
add
on
you
know?
The
next
possible
thing
is
itself
an
interesting
challenge,
so
you
know
asking
the
question
now:
does
this
enable
the
future
work
is
a
important
thing,
and
how
do
you
go
about
doing
that
in
the
case
of
you
know,
you're
developing
a
core
module
and
then
potentially
adding
in
everything
else
by
extensions?
A
Well,
your
book
list
is
at
least
pre-built
a
little
bit.
This
gives
you
a
chance
to
say
here
are
the
things
that
we
already
know.
You
want
the
right
later
on
and
you
don't
have
to
do
the
full
modeling
exercise
but
being
able
to
say
well.
Does
this
thing
extend
something
that's
already
in
the
module?
Is
this
thing
completely
off
of
the
side?
These
are
the
sort
of
easy
tests
to
figure
out.
A
You
know
is
this
the
piece
of
work
that
is
enabled
right
now
in
the
current
module
or
am
I
somehow
holding
it
back
somehow
the
the
sort
of
disruptive
blocking
behaviors?
This
is
why
that
we're
really
looking
to
avoid,
because
you
know
you
really
can't
undo
those
in
the
easy
fashion.
Itf
does
give
us
rules
for
basically
replacing
an
entire
module,
but
that
is
incredibly
disruptive
and
you
know
certainly
not
something
we
care
to
do.
A
A
One
of
the
ways
we
try
to
actually
solve
this
on.
Our
part
was
basically
they
do
tests,
and
you
know
the
test
was
you
know?
Can
we
take
something
augment
it?
No,
even
if
it's
a
very
basic
augmentation
we're
not
really
writing
up
the
full
module,
but
you
know
by
doing
enough
of
the
skeletal
extension
on
things
this
lets
us.
You
know
test
that
we
actually
have
done
our
job
correctly.
A
They
the
groupings
in
some
cases,
needed
to
be
reorganized
to
allow
them
to
be.
You
know,
attached
in
different
places,
sometimes
the
groupings
themselves
as
part
of
doing
the
test.
We
realize
that
we're,
since
you
can't
augment
a
grouping
in
the
current
version
of
Yang.
The
consequence
is
every
place.
The
grouping
is
substantiated
if
you
have
to
instantiate
a
augmentation
for
each
one
of
those
things.
That
itself
is
its
own
pain
point
and
now.
Certainly
this
is
one
of
the
known
irritating
quirks
about
yang
right
now
and.
C
A
Know,
perhaps,
is
one
of
the
good
things
that
will
be.
You
know,
part
of
Yang.
Next,
from
B2B
perspective,
we
have
a
number
of
protocol
extensions,
especially
the
VPN,
based
ones,
that
is
managed
by
the
best
working
group,
that's
responsible
for
extending
things,
and
we
had
to
make
sure
that
things
that
best
spotted
the
support
for
like
New,
bgp,
Path
attributes,
new
address
families
for
features
like
multicast
and
ethernet,
based
vpns,
where
those
things
actually
enabled
IDR
that
standardizes
bgp
itself
regularly
comes
out
with
new
extensions.
A
Can
we
actually
make
sure
that
we
can
do
those
sorts
of
things?
And
you
know
interesting
much
harder
questions
in
some
perspectives
is
extending
incrementally
features
that
are
very
flexible,
and
you
know
a
particular
bgp
extended
communities
is
a
headache
that
will
come
back
to
with
some
specific
study,
the
typedef
slides
to
talk
about
how
this
is
actually
really
really
challenging.
You
know
for
something
that's
intended
to
be
both
flexible
and
highly
maintainable.
D
A
If
you
all
have
time
to
go
ahead
and
browse
through
the
GitHub
module
that
the
B2B
work
is
being
done
in
you'll
find
inside
of
there
there's
actually
one
unused
module
that
currently
linked
into
the
internet
draft-
and
you
know
going
through
you
know
quite
a
bit
of
history
in
a
very
short
order
when
the
bgp
Yang
module
is
being
developed,
people
are
trying
to
figure
out
structurally.
How
do
you
take
two
core
pieces
of
bgp?
A
You
know
the
destinations
themselves,
the
prefixes
and
the
sets
of
path,
attributes
that
go
along
with
them
and
model
them
inside
of
the
yang,
and
it's
the
case
of
the
BHP
protocol
that
you
know
you
have
a
bgp
update
that
contains
one
set
of
path,
attributes
which
is
a
couple
of
the
properties
of
the
routes
with
a
large
number
of
prefixes
that
may
be
attached
there.
So
you
have
a
relationship
of
you
know
many
prefixes
to
potentially
one
set
of
unique
Destiny,
a
unique
set
of
path.
A
Unfortunately,
you
know
this
battling
stuff.
You
know
in
terms
of
a
pattern.
Well,
correct,
modeling
is
got
some
interesting.
You
know
protocol
challenges
now
as
an
example
of
some
set
of
path,
attributes
a
is
shared
by
you
know
five
or
six
different.
You
know
routes.
Well,
that's
great!
You
know
you
can
serialize
that
individually
as
long
as
you're
fetching,
you
know
the
individual
sub
trees
for
the
path
attributes
and
then
fetching
the
sub
trees
for
the
routes.
A
As
long
as
you
get
the
entire
thing
as
one
cluster,
you
have
the
data,
it's
made
whole.
The
referential
Integrity
is
correct.
The
trouble
we
have
with
any
of
these
types
of
streaming
mechanisms,
especially
on
change
protocols.
You
know
like
pick
something
outside
of
ietf
gnmi
from
Google
means
that
you're
getting
some
of
this
stuff
streamed.
You
know,
there's
no
guarantees
that
you're
going
to
get
the
things
in
any
specific
order.
E
A
If
you're
doing
something
like
a
CLI,
this
is
even
more
challenging.
You
know,
CLI
is
don't
split
these
things
out.
No,
you
actually
stream
out.
If
you
do
a
show,
B2B
route
on
pretty
much
any
implementation,
it's
going
to
show
the
route
it's
going
to
show
all
the
properties
for
the
route.
It's
not
going
to
refactor
these
things
for
efficiency,
to
try
to
enable
things
like
the
clis
and
potentially
some
types
of
streaming
applications.
Now
we
did
an
exercise,
you
basically
said
well.
Could
we
put
together
a
model
that
is
a
command
space
module?
A
So
if
you
did
equivalent
of
a
show
BHP
route
and
some
platform,
could
it
stream
out
for
this?
You
know
destination
all
the
sets
of
attributes
associated
with
it,
and
it's
part
of
that
exercise.
We
realized
that.
Well,
we
were
most
of
the
way
there
all
the
things
that
were
already
inside
of
the
path
attributes
already
had
most
of
the
right
organization
and
with
a
slight
tweaking
of
the
groupings
we
got.
A
You
know
it's
it's
great,
that
you
can
potentially
enable
multiple
applications,
but
if
you
had
these
things
implemented
out
of
the
box
as
separate
trees,
you'll
just
try
to
pull
all
the
trees
you're
affected,
getting
highly
redundant
data.
You
know
so
this
operational
view,
nicety
versus
no
structure,
is
an
interesting
I.
Think
long-term
conversation,
Rob
I,
see
your
hand
up.
C
Have
a
good
audio,
yes,
so
similar
to
this
all
related
to
this
is
probably
a
sort
of
templating
where
you
might
embed
templates,
either
within
the
model
or
more
generically
for
the
configuration
and
allow
you
to
write
a
very
concise
configuration.
And
then
you
have
the
same
sort
of
question
about.
How
do
you
represent
the
operational
data
for
those
things
where
you
do
that
template
expansion
that
naturally
you
would
do
you
you'd
see
like
the
expanded
operational
data?
C
A
Exactly
and
your
groupings,
unfortunately,
as
we
were
saying
earlier,
you
know
they're
very
nice
in
the
sense
that
they
provide
us.
You
know
some
ability
to
make
reuse
of
things,
but
unfortunately
the
long-term
maintainability.
You
can't
augment
a
grouping.
You
know
that's
where
things
become
interesting,
longer
term
challenges
for
especially
configuration.
A
Move
on
to
the
next
point
and
we'll
actually
pause
from
the
slides
in
a
moment
to
go
out
to
some
GitHub
to
actually
talk
about
this
type.
Versioning
is
actually
one
of
the
interesting
pieces
of
headache
that
we
have
for
certainly
bgp
and
I
suspect.
The
problem
exists
in
different
flavors
for
other
protocols.
Hopefully
is
you
know
the
ITF
is
reviewing
the
modules
they're
looking
at
these
sorts
of
headaches
now,
in
particular
anything
that
needs
to
be
extensible
as
a
type,
ideally
long
term.
A
If
it's
moving
at
a
fast
pace,
you
know
something's
changing,
often
we're
doing
the
work
to
delegate
these
types
to
hyana.
You
know
the
in
the
process,
theoretically
will
allow
us
to
make
changes
without
having
to
go
through
and
issue
a
completely
brand
new
RFC
for
things.
You
know
to
basically
copy
and
paste
the
same
bit
of
data
over
and
over
again
know
exactly
how
well
that
process
will
work
over
the
long
term.
I
think
is
still
to
be
discovered,
but
minimally.
D
Okay,
the
point
I
was
trying
to
also
add
to
it
is
the
currently
exist,
I
believe
no
guidelines
as
to
when
a
particular
set
of
definitions
need
to
can
or
should
be
part
of
a
INR
module
instead
of
an
ITF
module
and
I've.
Had
people
query
me
on
this,
that
particular
question.
So
maybe
this
is
more
to
Rob's
to
say:
maybe
I
did
an
IC
level.
A
Yeah,
in
particular
the
takes
something
outside
of
the
complicated
pieces.
So,
like
you
know,
the
extended
Community
type
work
and
Michael
Richardson
asked
about
good
use
of
identities.
It
will
come
to
that
as
an
example
in
a
moment
for
things
that
are
code
points
in
particular,
you
know
if
there's
a
niceness
to
having
the
things
published
in
a
data
type
that
very
strongly
binds.
You
know
their
type
and
the
code
points
they
represent
together
and
again
gives
us
a
lot
of
different
options
for
just
boring
numbers.
A
Now
we
have
enums,
but
enums
are
not
trivial
to
maintain
on
their
own.
You
know
you
have
to
go
through
a
module
update.
That's
an
example
where
you
know
the
fact
that
when
they
have
the
number-
and
you
want
to
have
the
thing
that
they're
tied
to
strongly
put
together-
that's
a
good
place
to
do
it
and
Diana
maintain
module.
A
A
You
know
you
can
model
them
as
a
base
Identity
or
a
set
of
identities,
no
having
an
appropriate
relationship,
Yang
versioning
rules.
Let
us
actually
extend
identities
without
actually
having
to
worry
about
a
republishing,
the
module,
so
we
get
incremental
maintenance
without
needing
to
you
know
centrally,
publish
them,
but
one
of
your
challenges
is
even
though
you
have
the
ability
to
do
the
extensions.
A
Well,
you
then
have
you
know
a
question
of:
where
does
the
thing
live
now,
if
your
base
module
is
part
of
a
RFC,
and
you
know
you
have
a
base
identity
as
part
of
that,
you
can
certainly
have
your
augmentations
for
other
things
in
a
second
RFC,
but
the
challenge
then
becomes
you
know
if
you
have
that
potential
becomes
a
identity
itself
that
is
being
derived
from,
and
this
is
effectively
a
practice.
We
want
to
avoid
identities
from
identities.
A
You
know
the
consequence
there
is
that
you
start
having
dependency
chains,
one
way
to
sort
of
work
around
some
of
those
interesting
headaches
is
you
know
they
encourage
the
identities,
even
though
they
don't
have
to
be
maintained
in
a
central
place
to
push
them
towards
the
central
place
like
Ayanna,
so
we
can
get
examples
there,
the
BHP
module.
Does
this
as
an
example
for
its
various
types
of
capabilities
and
different
example?
C
A
comment
actually
so
to
answer
mahesh's
question
as
to
when
is
it
good
to
do
an
Ayana
maintained
module?
My
instinct
here
is:
if
you've
got
another
table
already
defined,
of
attributes
or
properties
defined
in
Ayana,
and
you
can
programmatically
sort
of
generate
the
Yang
module
from
that
B
that
either
identities
or
an
enumeration,
or
something
like
that.
Then
I
think
that
those
fit
quite
well
as
some
cyan
maintained,
because
whenever
that
master
table
is
updated,
then
I
can
automatically
generate
an
updated
version
of
the
Yang
module
to
go
with
it.
D
Does
the
cool
Point
need
to
exist
in
INF,
for
it
to
be
in
a
module
and
I
think
rob
you
kind
of
clarified
that
there
are
two
instances,
one
where
a
code
Point
might
exist
and
then-
and
that
would
be
one
very
reason
to
have
an
eye
on
a
module.
The
other
cases
where
it
may
not
be
in
a
code
point
and
the
question
there
is:
is
it
appropriate
or
is
it
okay
to
for
it
to
be
in
an
INR
module
and.
C
I'll
pause
for
the
responses
like
that
one
I
I'm,
not
sure
it's
a
hard
and
fast
rule,
but
having
said
that,
from
what
I
recall
everything
that's
that's
there
today
always
is
a
separate
registry.
I
mean
the
one.
That's
probably
slightly
strange
is
the
eye
of
types
which
I
think
is
added
to
the
to
knife
types
list
that
might
be
and
then
a
mid,
but
it's
generated
from
and
the
Yang
is
perhaps
generation.
That's
saying
this
so
I
think
in
all
the
cases
I
can
think
of.
C
A
A
If
you
have
a
feature,
that's
done
via
identity.
If
somebody
defines
a
internet
draft,
you
know
that
defines
an
extension.
That's
augmenting!
Sorry,
that's
extending
that
identity.
Are
they
squatting
out
of
code
point
or
not?
No,
because
there's
no
magic
number
associated
aside
from
the
stuff
of
the
descriptive
text,
so
one
of
the
things
I
encourage
people
to
think
about
in
terms
of
their
I
added
process
and
know
how
this
actually
interacts
with
Ina
and
the
isg.
A
Is
you
know
what
level
of
enforcement
mechanisms
we
can
get
in
terms
of
trying
to
avoid
code,
Point
squatting,
which
can
cause
all
sorts
of
interesting
headaches,
so
I'm
going
to
hit
touch
upon
B2B,
extended
communities,
because
this
is
probably
our
single
biggest
pain
point
that
we
ran
into
as
part
of
trying
to
figure
out?
How
do
we
clean
up?
A
But
all
the
various
protocol
mechanisms
that
use
about
them
care
very
deeply
about
what
this
stuff
is
pick
easy
examples
of
that
no
route
targets
out
of
vpns
or
a
explicit
type
about
that,
and
they
have
more
than
one
format.
And
you
know
the
choice
for
modeling
was
made
for
use
of
operations
just
like
we
have
inside
of
rclis
people
don't
want
to
put
in
a
8
byte
hexadecimal
number
to
get
stuff
done,
they're
going
to
use
things
that
are
human
friendly.
A
This
means
that,
from
a
Yang
perspective,
two
things
we
need
the
defined
type
for
them
and
we
need
to
define
a
regular
expression
that
allows
them
to
be
matched
against,
and,
unfortunately,
this
means
that
we
have
this
gigantic
growing
set
of
regular
Expressions,
because
this
is
attached
to
a
generic
feature.
The
you
know
extended
community
that
just
happens
to
be
used
in
specific
contexts.
A
E
F
A
F
F
F
A
A
F
A
A
A
We
also
have
things
that
include
features
of
very
popular
in
ITF
right
now,
like
colors,
so
the
color
Community
was
originally
developed
as
part
of
RFC
9012
I'm
not
going
to
flash
that
up
in
the
screen,
but
you
know
poking
to
our
packet
diagram
here,
because
that's
mostly
from
9012,
you
know
we
have.
You
know
again:
it's
eight
bytes
worth
of
data,
here's
a
type,
there's
a
subtype
and
then
the
bottom
four
octets
were
a
color
in
the
original
RFC.
A
You
know
the
prior
to
octets,
where
basically
must
be
zeros
and
no
the
question
becomes
well.
What
happens
if
you
want
to
extend
these
sorts
of
things
and
the
srte
policy
feature
which
is
being
done
in
support
of
you
know.
A
lot
of
more
interesting
segment,
routing
type
use
cases
for
with
bgp
is
a
signaling
plane
decided
that
they
wanted
to
take.
A
You
know
two
bits
of
this
and
actually
make
use
of
them,
so
the
question
becomes:
how
do
you
model
this
sort
of
thing-
and
you
know
part
of
our
process
here
is
this
is
an
example
we
said
well,
we
want
to
add-
and
this
is
inside
of
the
GitHub-
that
we've
been
doing
our
coordination
work.
We
want
to
add
support
for
this
sort
of
thing.
A
If
we
talk
about
where
it
came
from
and
then
the
fact
that
there's
a
modeling
challenge
here
and
you
know
as
an
example,
we
show
the
OC
model
that
they've
done
for
their
stuff,
and
you
know
they
made
an
interesting
choice.
You
know
they
decided
to
model
those
first
two
bits
strictly
is
a
zero
and
one
two
bits
long
and
then
a
colon.
A
So
the
question
is:
what
do
you
do
about
this
sort
of
thing,
especially?
Is
it
changed
now?
If
you
have
a
standard,
9012
implementation
that
doesn't
understand
the
flags
field,
do
you
want
to
model
those
bits
at
all?
You
know
it's
not
actually
relevant.
If
you
do
understand
it,
well,
that's
great.
We
can
display,
you
know
the
two
bits
that
we
do
know
what
to
do
from
this
extension.
Rfc,
that's,
you
know
coming
up
and
we
can
model
it
this
way.
The
question
is:
what
happens
if
we
start
adding
further
bits?
A
A
So
if
we
add
in
you
know
the
next
two
bits
now
do
we
just
simply
continue
adding
in
zeros
and
ones
no
much
like
we
have
for
the
Yang
bit
string
or
you
know
what
happens
if
we
have
a
different
example
where,
instead
of
that,
you
know
somebody
decides
they
want
to
grab
the
bottom
two
bits.
How
do
you
represent
that?
A
Do
you
backfill
all
the
zeros,
so
this
is
an
interesting
set
of
choices
that
we
have
to
deal
with
for
maintainability,
on
top
of
the
fact
that
we
have
to
actually
update
a
type
def
that
is
used
by
everybody,
and
you
know
the
you
know,
example
that
we
came
up
with
you
know
for
ours.
Is
you
know
we're
going
to
add
on
a
field
designator?
You
know
so
this
Co,
you
know
flag.
A
A
This
means
that
regular
Expressions
written
against
this
extended
Community
have
a
chance
of
being
extensible
in
the
future.
This
is
still
not
a
great
pattern.
We'll
have
some
of
the
same
challenges
that
we
have
for
what
happens
when
you,
you
know,
add
things
that
are
present
in
the
protocol,
but
not
actually
signaled.
So
it's
a
example
going
back
to
here.
What
happens
if
somebody
sets
one
of
these
unassigned
bits?
It's
present,
you
can't
configure
it
using
one
of
these
magic
types.
A
You
know
you
can't
now
print
it,
so
the
challenge
becomes.
How
do
you
sort
of
fall
back
your
display
model?
The
answer
that
we
have
for
extended
communities
in
general
is
we
have
the
ability
to
display
raw
communities
that
are
the
raw
hex
format.
Those
are
guaranteed
not
to
change
release
to
release.
A
It
means
we
have
to
some
extent,
no
overlaps
of
you
know
known
human
friendly
communities,
and
you
know
the
ones
that
are
raw
and
the
sort
of
headache
we're
seeing
is
a
pattern
sort
of
repeatedly
as
we're
working
through
the
operational
cases
for
bgp.
How
do
you
deal
with
the
unknowns
and
there's
at
least
one
bit
of
this
discussion
that
we're
having
about
you
know
bit
vectors
that
is
carried
through
into
other
proposals,
so
pause
here
to
see,
if
there's
any
questions
about
this
explicit
example,.
A
A
Just
to
point
out
the
relevant
bits
of
process,
you
know
we're
doing
this
exactly
like
you
do
of
any
other
git
project.
You
know
we
opened
up
issues,
we
have
discussions
about
it.
We
work
through
the
details
of
things
and
you
know
eventually
we'll
get
around
to
crafting
a
pull
request
which
we
have
when
pending
at
the
moment.
We've
decided.
A
This
is
not
a
core
piece
of
the
feature,
and
you
know
this
is
left
as
a
lingering
pull
request,
it's
possible
that
IDR
is
part
of
working
through
the
RFC
process,
we'll
decide
they
want
to
integrate
this.
But
at
some
point
you
know
there
will
have
to
be
the
internet
answer
for
this,
because
it's
a
protocol
extension
that's
defined
so
Lou
I'm,
going
to
switch
back
and
request
you
to
share
the
slides
again
and
pass
back
to
me.
A
So
one
of
our
learnings
here
is
that
switching
back
and
forth
can
be
challenging
Okay,
so
we're
zooming
in
slide.
Seven
type,
versioning,
like
I
said,
is
a
extremely
painful
thing.
When
you're
dealing
with
string
types
that
have
regular
Expressions
used
as
a
validating
elements
on
there,
we
have
some
interesting
challenges
just
for
how
these
things
were
defined.
Originally
part
of
the
routing
working
group
work
was
to
try
to
actually
provide
common
types
for
various
protocols,
including
bgp
and
8294,
gave
us
some
Primitives
for
Route
Target
Route
Origins
route,
distinguishers
Unfortunately.
A
They
probably
made
some
modeling
mistakes
right
there.
You
know
they
they
don't
provide
for
suitable
extensibility.
They
also
don't
make
it
terribly
easy
for
you
to
do
any
updates.
They
they
didn't
delegate
this
Diana.
So
the
consequence
is,
if
you
wanted
to
maintain
something
at
82
94,
there
will
have
to
be
the
entire
Biz,
ideally
that
entire
business,
once
we
actually
start
addressing
the
deficiencies
profound
as
part
of
working
on
the
bgp
modules
and
as
we
continue
working
on
the
VPN
modules
will
be
to
push
this
off
to
Ayanna.
A
The
main
headache
that
we
have
in
terms
of
the
modeling
is
there's
some
ambiguity
in
the
strings
that
they
developed,
especially
the
lack
of
Quant
qualifying
keywords.
Now,
if
you
look
at
mostly
lies
and
do
a
show
of
some
sort,
you
know
you
do
like
a
show.
Bgb
route
and
you'll
see
that
this
has
route
Target,
no
colon,
100
colon
200
as
an
example
that
route
Target
keyword
is
the
thing
that
makes
it
unambiguous
as
to
what
the
thing
is
actually
present
in
the
modeling
that
they
did.
A
That
means
you
have
to
know
the
context
and
as
long
as
the
context
is
completely
unambiguous,
if
this
is
used
solely
as
configuring
targets
for
a
a
VPN,
you
know
verf
as
an
example,
then
that's
sort
of
safe,
but
if
you're
trying
to
display
this
among
a
list
of
all
the
different
types
of
extended
communities
which
route
targets
one
of
well,
it's
no
longer
semantically
clear.
So
that's
the
thing
we'll
decide
about
revisions
as
we
work
on
the
things
in
ietf.
A
A
When
they're
defined
you
know
so
you
can
identify.
Bit
Zero
means
this
bit.
One
means
that
that's
great,
the
problem
is
what
happens
when
you
have
operational
state
for
implementations
that
can
receive
things.
That
might
be
an
older
version.
So
if
the
three
bit
four
bit
five
gets
assigned
later
on,
but
you're
unfortunately
running
an
older
version.
Well,
the
implementation
can
see
it.
The
thing
that
you're
passing
through
your
implementation
may
contain
those
bits.
A
You
may
not
be
able
to
see
it,
but
it
may
be
impacting
something
further
Downstream
in
the
protocol,
so
visibility
is
a
very
important
thing
from
operational
standpoint.
The
bits
construct
doesn't
really
give
us
the
necessary
tool.
So
you
know
the
problem.
We
have
is
sort
two-fold,
there's
no
way
to
sign
default
names
to
these
bits.
You
know
the
consequence
there
is
that
you
know
something:
I
was
getting
sent
on
the
wire.
A
You
can't
show
that
it's
present
that
goes
back
to
our
extended
community
example
for
colors
for
those
unassigned
bits
as
an
example,
and
just
this
messy,
you
can't
change
the
name
of
the
bit
once
it's
been
assigned,
which
means,
if
you
want
to
actually
give
it
a
name,
you're
not
allowed
to
change
it.
No
from
like
unknown
three
to
you
know,
this
is
now
the
color
for
an
example.
A
The
proposal
for
the
unknown
bits
that
I
made
is
one
potential
technique
for
dealing
with
this,
and
this
generated
a
lot
of
interesting
discussion
in
terms
of
whether
these
things
are
Backward,
Compatible
changes
or
not.
I
suggest
that
let's
not
take
a
huge
amount
of
time
in
this
presentation
for
it.
But
let's
please
continue
that
conversation
in
the
deadbat
pause
here
to
see.
If
there's
any
questions.
D
D
D
Now
you
might
choose
to
either
share
them
in
the
draft
or
not,
but
I
would
share
them
simply
because
from
an
implementation
or
somebody
who
is
actually
trying
to
use
those
models
can
then
use
your
examples
to
build
upon
so
I
I
think
our
philosophy
is
that
there
can
never
be
enough
number
of
examples
in
the
draft.
So
more
would
suddenly
be
helpful.
D
Even
within
the
examples
I've
seen,
Snippets
anonymously
complete
configuration
examples
and
that's
better
than
having
no
examples,
but
it
suddenly
helps
if
one
can
see
and
in
that
particular
example
how
you
are
pulling
in
data
for
other
modules
that
you
have
not
necessarily
developed.
So
if
you
look
at
that
the
example
8.5
in
on
draft,
it's
not
just
concentrating
on
example,
as
it
relates
to
the
bgp,
but
also
the
other
modules
that
it's
dependent
on
so
highly
encourage
anyone
who's
writing
models
to
try
to
develop
example,
story,
Jason.
F
Hi
so
mesh
when
you
mentioned
that,
like
I
agree,
the
examples
are
often
very,
very,
very
useful
and
I
found
them
in
developing
Yang.
Models
as
well
is
to
have
some
instance
data
examples
for
myself
to
to
kind
of
validate
my
mind.
Oh
here's
what
it
looks
like
when
you
kind
of
put
it
together,
but
you
mentioned
that
it
would
also
help
detect
when
you
make
some
changes
and
it
breaks.
F
You
know
like
previous
configs,
so
I
I,
assume
by
that
what
you
mean
is
not
just
have
the
examples,
but
you
also
are
validating
them
validating
those
instance.
Data
examples
against
the
models
using
like
Yang
lint
or
something
as
as
you
turn
things
like
to
have
almost
like
an
approval
pipeline
as
you're.
Turning
the
turning
the
module
that.
D
The
repo
in
my
case
is
to
actually
show
exactly
what
you
mentioned,
which
is
using
yanglin
and
an
instance
data
file,
whether
it's
XML
or
Json,
and
run
it
against
your
model.
So
if
you
made
any
changes-
and
you
forgot-
oops
I
I
forgot
to
either
remove
or
change
a
particular
leaf.
Then
that
example
is
able
to
catch
that
and
tell
you
either
you.
A
You
know
the
tcpm
module
that
had
been
coming
out
was
through
their
last
call,
I've
been
through
the
end
doctor's
review
and
we
were
asked
to
go
ahead
and
take
a
look
at
it
because
pgp
is
you
know,
as
a
protocol
uses
TCP,
you
want
to
make
sure
that
we
can
interoper
with
it
for
things
like
tcpao
and
md5,
and
it
was
the
process
of
writing
our
interop
examples
that
we
found
deficiencies
in
the
the
current
dspm
module
at
that
time
and
that
ended
up
halting
their
last
call.
They
got
some
changes
made.
A
D
D
This
is
the
correct
version
of
the
slide,
so
schema
Mount
was
one
other
area.
That
was
that
we
started
to
look
at
fairly
early,
although
one
of
the
issues
that
we
ran
into
was
that
there
were
no
public
tools
available
for
us
to
actually
validate.
So
going
back
to
that
example,
a
scenario,
even
though
we
had
an
example,
we
didn't
have
any
tools
to
validate
it,
but
ever
since
then
I
believe
England
has
added
support
So.
The
plan
is
for
us
to,
of
course,
revalidate
the
scheme.
D
Amount
example
that
we
have
in
the
Trap,
but
why
do
we
need
schema
marble?
Well,
if
you
look
at
the
bgp
model,
it
is
already
augmenting
the
routing
protocol
model
to
add
the
particular
bgp
instance.
Now,
in
that
particular
scenario,
routing
protocols
rarely
of
course,
run
in
isolation.
They
usually
are
realized
inside
of
a
network
instance,
even
if
it's
a
default
Network
instance.
D
F
Hey
it's
just
more
a
time
check,
I
think
we've
got
about
five
or
six
minutes
left
on
the
on
the
on
the
meat.
Echo
I,
don't
know
if
it'll
keep
going
past
that
for
a
few
extra
minutes,
but
we
should
probably
just
make
sure
we
kind
of
hit
on
key
messages
in
the
next
five
minutes
and
then
anything
if,
if
it
lets
us
hang
around
for
another
five
or
ten
after
that,
that's
a
bonus
but
I'm
not
positive.
What
will
happen.
A
And
we
should
be
able
to
easily
finish
this
by
tap
of
hour
and
we'll
try
to
compress.
You
know
the
key
points
down.
You
know
the
next
five
minutes
and
give
up
a
chance
to
actually
show
a
very
you
know
very,
very
brief
demo
of
changes
in
the
ecosystem
he
built
so
again
revisiting
this
point.
Module
into
work
was
a
very
big
deal.
We've
already
reviewed
a
number
of
places
where
this
was
interesting
set
of
challenges
as
an
example.
How
do
we
actually
do
OTC
AO
tcbmd5
ibsec?
A
How
do
we
make
these
things
actually
work
with
bgp?
How
do
we
integrate
with
things
like
policy,
which
was
itself
its
own
growing
thing,
and
you
know
some
of
the
back
and
forth
that
we
had
between
this
module
in
the
IDR
and
the
protein
working
groups.
You
know
policy
module
that
was
under
their
development,
but
had
substantial
need
to
accommodate
bgp.
You
know
that
that
was
one
of
our
sets
of
challenges,
and
you
know
BFD
itself.
It
was
people
who
are
involved
in.
You
know
that
bittyang
work
was
itself
a
headache
in
terms
of
Maintenance.
A
You
know
it
had
to
have
a
small
patch
issued
against
it
very
soon
after
original
publication,
so
verifying
we
can
actually
do
all
these
things
is
critical.
A
lot
of
this
again
is
coming
back
to
try
the
examples
test,
the
integration
we
will
find
bugs
we
did
find
bugs,
and
we
found
bugs
in
like
four
different
of
the
pieces
that
we
tried
to
work
with.
Ipsec
had
already
long
been
published.
They're.
They
don't
have
a
specific
piece
of
work
at
the
moment
open
to
fix
their
problems,
but
this
is
an
example.
A
How
do
you
make
sure
that
you're
making
lots
of
different
point
changes
to
the
documents?
Are
things
correct
at
each
step
of
the
way,
and
these
are
exactly
the
same
problems
that
standard
software
development
has
so
this
project
is
used
GitHub
for
a
very
long
time,
but
Hesh
has
done
a
wonderful
job
of
building
us
an
environment
for
this,
and
GitHub
itself
gave
us
a
lot
of
the
structural
components
we
needed
to
get
the
job
done.
Issues
were
created,
we
track
things,
we
tag
them
once
we
decided
to
work
on
a
given
cluster
of
things.
A
A
The
issues
will
provide
documentation,
perhaps
long
term,
especially
if
we
archive
things
as
to
why
we
made
some
of
the
design
choices
problems
we
didn't
have
enough
eyes
in
the
work-
and
this
is
a
generic
problem
with
modeling
and
ietf
review,
ends
up
happening
effectively
very
late
because
we
published
an
RFC
and
then
some
vendors
trying
to
implement
the
thing.
You
know
we
have
a
lag
between
implementation
and
the
RFC
status
process.
A
Ideally,
we'd
have
something
better
to
do
about
that,
but
based
on
where
the
industry
is
in
terms
of
ITF
Yang
modules,
that's
not
happening
right
now
for
us
trying
to
close
some
of
these
Loops
doing
all
these
testing
components
verifying
we
can
actually
maintain
things.
The
containerized
build
environment
mesh
put
together
for
us
did
a
huge
amount
to
make
sure
that
everybody,
you
know,
and
a
single
git
checkout
with
Docker
has
everything
they
need
to
build
the
modules.
Do
the
validation
build
the
resulting
internet
draft
text?
This
is
all
in
one.
A
A
One
of
the
best
things
we
could
have
done
is
found
a
way
to
do
this
in
less
time,
and
you
know
the
B2B
Yang
work.
If
you
look
at
the
draft
is
probably
the
largest
module
we
have
in
ietf
by
you
know,
at
least
you
know,
3x
consequences
it's
just
going
to
require
a
lot
more
eyeballs
on
there
and
it
required
iteration
and
iterating
over
something
that
large
is
very
difficult.
A
Just
simply
getting
all
the
content
in
itself.
You
know
check
to
rechecked,
you
checked.
Eventually,
you
stop
seeing
things,
you
need
more
eyes,
and
even
if
you
have
eyes
reviewing
things
it's
the
same
problem,
we
do
have
to
get
the
structure
right.
The
first
round
we
found
that
we
actually
had
several
mistakes
in
and
we
found
that
out
late
in
the
process,
conveniently
we're
still
pre-implementation.
So
this
was
not
actually
a
broken
thing,
the
tooling
and
the
maintainability
and,
more
most
importantly,
the
testing.
That's
part
of
the
environment
that
will
be
demonstrated.
A
That
makes
a
huge
difference.
Iesg
in
particular
needs
to
pay
strong
attention
to
what
we
delegate
the
Ayanna,
how
that
actually
goes
into
the
code
boy
management
process-
and
you
know,
but
if
any
type
of
squatting
can
take
effect
when
things
are
defined
through
identities-
and
you
know
emphasizing
very
hard
again,
interwork
has
to
be
tested.
This
is
where
we
will
actually
find
problems
in
ITF.
A
F
D
D
D
D
D
It
has,
and,
as
Jeff
mentioned,
the
set
of
tools
that
we
were
able
to
share
consistently
across
all
the
authors,
because
each
individual
laptop
had
its
own
otherwise
would
have
its
own
tool
set
some
tools
that
were
available
somewhere
different
versions
and
rather
than
debugging
or
working
on
the
model
itself.
We
were
spending
time
trying
to
figure
out
why
the
versions
of
the
draft
were
different.
So
having
a
Docker
containerized
way
to
build
the
draft,
it
was
suddenly
neutralized
any
differences.
D
The
other
part
that
is
not
necessarily
part
of
the
container
environment
was
that-
and
this
is
something
I
learned
through
other
authors
is
keep
the
model
separate
from
the
draft
itself
so
that
the
models
could
be
compiled.
They
could
be
validated
and
tested
before
being
included
in
the
draft,
and
there
are
enough
scripts
around
that
maybe
should
be
shared
that
can
be
used
to
then
include
those
models
into
the
draft.
C
D
A
Well,
I
guess
the
offer
my
closing
remarks.
You
know
this
has
been
a
long
journey.
You
know
we're
still
not
to
the
point
of
no
implementations.
Yet,
although
we
have
rumors
that
some
are
starting
to
make
progress
for
the
bgp
stuff-
and
you
know
the
consequence
of
the
work
that
we've
done
hopefully
has
helped
make
all
the
other
things
that
we're
working
with
a
little
bit
better
as
well.
A
So
hopefully
this
has
been
helpful
and
my
hope
is
that
you
know
this
group
will
take
the
wisdom,
spread
it
around
elsewhere
and
ideally,
let's
write
down
some
of
these
things
as
best
practices
and
disseminate
them.
Whether
it's
internet
drafts
Wiki
entries
Etc,
so
that
the
rest
of
the
people
who
want
to
get
started
in
ITF
Yang
work,
you
know,
have
a
good
place
to
start.
F
Okay
and
thanks
all
and
on
behalf
of
the
chairs
yep
net
mod
thanks
a
lot
guys,
I
know
it's
a
lot
of
it's
a
lot
of
your
time
to
have
arranged
this
and
and
take
the
time
to
present
it.
So
I
think
that
pretty
much
wraps
up
this
interim
someone
else
as
something
else,
they
want
to
add
closing
moments
here.