►
From YouTube: SIG Network meeting 20200910
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
All
right,
thank
you,
dan.
So
last
week
we
discussed
the
possibility
of
voting
on
the
governance
dock,
so
I've
gone
through
and
made.
You
know
what
I
anticipate
could
be
a
final
pass
through
for
the
most
part,
it's
just
been
finishing
touches
here.
Some
I
had
some
nice
reviews
from
people
that
I
appreciate
there
wasn't
anything
major
structurally
outside
of
one
section
that
I
added
that
is
about
the.
B
Github
organization
ownership,
so
that
would
be
people
that
are
listed
as
a
owner
role
in
the
github
organization.
This
is
essentially
it's
like
the
administrative
privileges
for
all
of
the
repositories,
so
this
is
the
kind
of
role
that
can
add,
delete,
transfer,
ownership,
etc.
B
So,
essentially,
what
I
wanted
to
do
was
right
now,
it's
dan
and
I
listed
there,
and
I
want
to
make
sure
that
it's
equitable,
that
we
have
representation
from
a
number
of
organizations
as
a
ownership
role,
but
essentially
what
I
wanted
to
do
is
make
sure
that
it's
well
represented
there,
but
I
also
added
some
language
to
essentially
say,
like
you,
can't
make
a
drastic
change
to
this
stuff
without
bringing
it
to
the
meeting.
B
So
essentially,
I
essentially
tried
to
make
it
a
figurehead
type
of
role,
so
you
would
have
some
responsibility
because
you're
the
one
who
would
add
somebody
to
the
list
to
say
you
are
now
an
official
maintainer
right
to
give
you
the
like,
merge
privileges
for
a
repository.
That's
essentially
what
your
role
would
be
here.
You
may
create
repositories,
but
in
the
case
that
we
need
to
delete,
rename
etc.
Mostly
that
would
come
to
the
meeting
first
and
we'd,
decide
that
that
stuff
as
a
group.
B
So
I
think
that
as
far
as
changes
go,
that's
the
the
most
major
item
there
and
also
I
realized
that
I
didn't
have
a
link
to
the
actual
proposal
doc
here.
So
that's
probably
the
most
notable
thing
to
be
aware
of.
Otherwise.
B
I
also
just
wanted
to
clarify
that
there's
kind
of
two
parts
two
parts
here
and
one
of
which
is
voting
on
the
governing
stock
and
then
also
we
separately,
I
think,
would
vote
on
having
the
the
code
of
conduct
document,
but
the
governance
dock
itself.
What
we
would
be
approving
is
two
sections
in
the
proposal,
so
one
of
which
is
the
mission
statement
section
and
then
the
governance
section
so
there's
kind
of
some
extra
stuff
in
this
document.
B
That
would
include
the
like
summary
of
changes,
an
overview
of
what
the
heck
we're
trying
to
do
here
and
then
there's
a
I
like
had
stubbed
in
like
an
amendment
section,
so
maybe
in
the
future
we
would
add
an
amendment
or
whatever.
So
we
wouldn't
accept
that
there's
nothing
in
there
and
then
the
code
of
conduct,
notably
the
code
of
conduct,
does
need
at
least
one
change,
which
is
essentially
there's
an
email
address
in
there.
B
That
says,
if
you
have
a
problem
and
you
need
to
get
in
touch
with
somebody
it's
here,
I
had
stubbed
that
in
with
my
own
personal
information
and
I'm
happy
to
take
that
role
if
people
want,
but
I
do
think
that
it
would
probably
be
wise
to
have
some
type
of
alias
there.
I
also
think
that
I
would
advise
to
not
use
the
the
mailing
list
for
this
for
two
reasons,
one
of
which
is
technically.
B
You
can't
just
send
a
mail
to
it
without
being
a
member
of
the
group
and
two
in
case
it's
something
sensitive,
that
somebody
doesn't
want
in
the
public
eye,
there's
that
so
that's
essentially
where
I'm
at,
and
I
certainly
would
love
to
take
the
pulse
of
the
group
to
see
if
we're
ready
to
vote
on
this
or
if
people
think
that
there
are
outstanding
issues
that
we
need.
Another
cycle
to.
B
C
Yeah
hi
doug.
D
C
How
are
you
so
first,
you
know
thanks
for
for
driving
this
effort
on
behalf
of
the
net
nvidia
team,
I
can
say
that
you
know
we
are
definitely
ready
to
to
make
a
vote.
A
I
did
have
one
question
doug
that
I
added
to
the
document,
and
that
was
under
github
organization
ownership
and
the
second
paragraph
there
reads
to
become
an
owner
of
the
github
organization.
A
member
may
indicate
the
candidacy
to
become
an
owner
by
adding
an
item
to
the
agenda.
A
A
B
And
so
yeah,
I
was
originally
thinking
that
that
I
put
member
there
intentionally
in
case.
We
had
that
particular.
B
Where
say,
let's
say
you
know
trying
to
get
ownership
from
across
a
number
of
organizations
if
somebody
thought
among
their
organization
that
it
might
be
better
to
have
somebody
who
has
a
role
more
like
that,
that's
maybe
a
project
management
type
of
role
or
something
to
offer
that,
although
I
do
think
that
that's
probably
an
edge
case,
I
think
that
it's
likely
that
you
would
probably
be
a
maintainer.
B
I
did
put
in
this
blurb
that
says
when
you
become
a
candidate,
you
should
have
some
kind
of
blurb
to
say
why,
and
my
guess
is
probably
that
blurb
would
read
something
along
the
lines
of.
I
have
a
history
of
contribution
to
to
projects
x,
y
and
z,
and
it
would
be
useful
for
the
maintenance
of
those
and
I
could
contribute
to
the
larger
effort
of
this
ownership.
B
So
maybe
in
another
case,
where
you're
just
a
member,
it
may
read
something
like
I
perform
this
role
in
my
organization,
and
I
can
do
this
in
lieu
of
seven
other
people
doing
it
or
whatever.
If
people
are
okay
with
that,
otherwise
I'm
totally
fine
with
changing
that
to
maintainer.
I
feel
like
that.
Would
be
a
reasonable
graduation
path
here.
A
Yeah,
the
alternative
is
that
you
know,
because
it
would
be
going
up
for
a
vote
from
members.
You
know.
Maybe
that
is
sufficient
and
the
members
can
decide
to
filter
you
know
or
bring
that
up
as
a
consideration
when
voting
on
the
proposal.
A
And
the
other
question
was
you
know
if
you
have
a
a
gathering
where
there
are
no
maintainers
present
a
meeting
where
no
maintainers
are
present
and
you
achieve
quorum?
A
B
Yeah
yeah,
I
I
mean
in
some
ways
it
is
touching
because
it
does
give
you
the
keys,
yeah.
A
Well,
in
any
case,
we
do
have
to
start
from
somewhere.
We
can't
change
the
government's
proposals
or
the
governance
document
later,
so
I
think
I'm
okay
with
keeping
member
right
now.
Okay,
I
didn't
resolve
my
comment
on
the
doc
and
then
I
went
through
and
resolved
other
comments
that
looked
like
they
had
answers
just
so
that
we
have
a
clear
idea
of
what
outstanding
questions.
If
any
there
are.
B
All
right
awesome,
I
realize
that
I
missed
one
from
billy
and
billy.
Just
thank
you
for
your
detailed
read
through
he's
had
some
great
comments,
but
one
of
the
kind
of
tweaks
that
we
were
making
was
related
to
the
verbiage
for
basically
meetings
for
projects
that
happen
outside
of
this
meeting.
We
want
to
allow
people
who
do
contribute
to
these
projects
to
have
meetings,
and
there
was
some
kind
of
crossing
of
the
streams
here
with
maintainer
versus
project
and
billy.
B
There's
an
outstanding
one
here
that
reads:
if
maintainer
meetings
occur
with
regularity
and
billy
suggested
that
we
change
this
to
project,
and
I
agree
and
I'm
going
to
make
that
change
right
now.
So
essentially,
it's
to
say
you
know:
maintainer
is
a
specific
role
under
this
group,
but
contribution
happens
in
a
public
sense
and
and
kind
of
projects
and
contributors
are,
are
their
own
thing
that
isn't
necessarily
a
maintainer.
So
I
think
that
that's
also
a
reasonable
change.
So
thank
you.
Billy.
E
Yeah,
okay,
yeah
that
looks
good
to
me.
That
was
just
my
last
little
just
make
sure
they
could
meet
out.
It
was
okay,
according
to
governance,
for
them
to
meet
outside
of
the
network,
plumbing
working
group
so-
and
I
do
like
that
they
should
report
back
in.
So
I
think
that's
good
too.
So
all
looks
good
to
me.
C
B
Okay,
well,
that
being
said,
if
there
are
no,
if
there's
nobody
who
thinks
that
we
need,
we
have
outstanding
issues,
then
I
guess
we
could
move
forward
with
a
vote.
I
believe
what
we
noted
last
meeting,
I'm
just
checking
this
was
to
say
basically
anyone
who's
been
in
at
least
two
of
these
meetings
before
and
has
contributions
somewhere
in
the
group
previously.
B
So
that
includes
this
one
would
be
available
to
would
be
it's
totally
cool
for
you
to
vote
for
the
lack
of
a
better
term,
and
I
think,
in
the
spirit
of
the
document,
we
probably
should
make
sure
that
our
quorum
is
good
and
that
we
meet
the
criteria.
For
you
know,
representation
from
each
organization.
E
B
Yeah
absolutely
so,
I
think,
let's
take
a
look
here.
This
is
coming
up
with
a
little
bit
of
process
on
the
fly
here.
Let's,
let's
just
run
down
the
participant
list
in
zoom,
ask
for
a
vote.
I
guess.
F
Maybe
maybe
we
should
just
check
if
there's
any
objections,
because
if
there's
no
objection,
it
is
a
little
bit
meaningless
to
kind
of
check
the
validity
of
the
hey
yeah.
It's.
B
Eliminating
the
technique,
absolutely,
I
think
that
that's
a
solid
logic
right
there.
We
have
some
people
that
are
fairly
good
with
logic
in
this
group.
So
that's
pretty
good.
All
right,
I
guess.
Let's
start
with
that,
any
objections
to
the
governance.
B
B
I'm
giving
the
mic
timeout
buffer
here
for.
B
Excellent,
I
hopefully
that
means
it's
holly,
yes
to
accept
it.
B
All
right,
that's
excellent.
I
will
say
that
this
is
one
of
my
favorite
parts
about
this
group
is
that
we
usually
continue
a
discussion
until
we
can
have
a
we
can
have
everyone
voting
the
the
same
way
and
as
far
as
I
can
remember,
that's
always
been
the
way
it's
been
in
this
group,
so
I
just
want
to
say
thank
you
to
everybody
for
that,
and
I
think
it
sets
the
stage
for
what
we
have
going
here.
So
that's
awesome.
Thank
you
very
much.
E
B
No,
no
problem,
you
guys
make
it
you
guys
make
it
very
pleasurable.
So
I
appreciate
that.
B
D
B
It's
on
the
last
page:
okay,
that
helps
yeah.
It
is
page,
nine
and
you'll
see
that
there
is
a
comment
here.
You
may
specifically
contact
doug
smith,
and
this
is,
I
believe,
what
we
need
to.
We
need
to
change
here.
B
I
don't
think
that
this
is
an
emergency
by
any
means
as
well,
so
I
guess,
alternatively,
what
we
can
do
is
I
can
think
about
having
how
to
handle
like
some
kind
of
email,
alias
that
we
can
use,
and
then
we
can
have
volunteers
who
are
part
of
all,
like
you
know,
email
list
that
will
handle
anything
here.
I
I
don't
expect
this
to
be
a
major
problem
in
this
group,
and
we've
never
had
anything
like
this
before.
B
I
just
think
that
it's
a
good,
a
good
idea
to
have
this
stuff
in
place
before
any
possible
problem
arises.
E
So
and
you're
thinking
like
how
many
owners
are,
do
you
think
they're
going
to
be
like
right
now?
There's
two:
are
you
looking
at
like
12?
Are
you
looking
at
like
five
or
six,
I'm
wondering
if
and
you
should
you
could
have
an
alias
and
then
you
just
say
the
alias
goes
to
the
owners
or
something
like
that.
B
Yep,
I
I
think
that
totally
works
too.
I
I
would
expect.
B
I
don't
know
from
my
like
best
guess
is:
maybe
a
half
dozen
would
be
plenty
of
ownership.
I
don't
know
that
it
needs
to
be
more
than
that
and
by
the
same
token,
you
know
if
people
have
interest
in
that,
I'm
not
opposed
to
it
being
seven
or
eight
or
whatever,
but
probably
four
to
six
sounds.
E
Right,
so
if
you,
I
guess,
I
mean
the
whole
point
of
this-
is
if
you
have
some
concern
and
that
you
want
to
race,
but
you
don't
necessarily
want
to
bring
up
to
the
whole
group.
You
want
to
hit
right
to
someone,
but
on
the
flip
side,
if
you've
got
some
alias
email
just
sitting
in
there
and
no
one
knows
where
that
goes,
who's
really
going
to
send
to
it.
E
E
All
right
because
because,
for
example,
if
I
have
a
problem
with
doug
smith
and
then
all
I
see
is
an
alias
and
then
I
go
to
send
these
and
they
just
go
to
doug
smith,
that
doesn't
do
me
any
good.
So
you
you
somehow
know
roughly
I
don't
know
if
in
the
conduct
you
need
to
have
everyone
listed
out
specifically.
So
if
they
changes
over
time,
you
don't
have
to
keep
updating
the
code
of
conduct,
but
either
that
or
if
I
don't
know
if
github
allows
other
roles
dynamically,
that
that
they
could
look
and
see.
E
B
So
billy
did
I
capture
this
right
in
the
agenda,
which
is,
let's
both
have
an
individual
volunteer
as
well
as
an
alias
that
goes
to
all
the
owners.
E
If
you
want
that
volunteer,
you
know
if
that
volunteer
is
as
long
as
we
can
document
that,
like
in
the
community
section,
you
know
like
another
like
conduct,
manager
or
conduct
policeman
or
whatever
you
want
to
call
it,
and
you
just
have
that
name
in
there
that
they,
so
they
know
who
it's
going
to
and
that
way
that
can
change
over
time.
But
you
don't
have
to
go
through
every
repo
and
change
the
code
of
conduct.
B
All
right,
so
I'm
thinking
we
need
a
little
bit
of
time
to
figure
out
the
technicality
for
this.
In
terms
of
the
content
of
the
code
of
conduct,
which
is
boilerplate,
it
comes
from
contributor.covenant.org.
B
Does
anyone
have
a
problem
with
the
with
the
content,
otherwise
excluding
the
email
address.
B
Okay,
cool
well:
that
makes
it
much
easier,
let's,
let's
think
about
how
to
handle
that
email,
alias
I'll,
do
some
thinking
on
it.
There's
got
to
just
be
a
google
way
to
do
this,
because
I
don't
think
that
anyone
wants
to
manage
a
send
mail.
B
Something
like
that
or
if
you
do
want
to
manage
that
have
at
it,
but
I
don't
think
I'll
volunteer
a
volunteer
for
it.
I've
I
think
the
send
mail
o'reilly
book
you
can
probably
use
as
a
boat
anchor.
It's
huge.
B
So,
okay,
let's,
let's
defer
this
the
next
time.
B
I'll
come
back
with
a
proposed
email
address
and
situation
suggestion,
okay,
so
that
was
so.
That's
one
of
the
next
steps
was
the
code
of
conduct
we'll
work
through
that
finishing
that
up
next
time,
but
I
think
the
next
steps
include
we'll
need
to
create
the
stub
documents
for
the
community
repo.
B
We
can
we
can
handle
some
of
them
this
meeting,
maybe
some
of
them
next
meeting,
and
so
as
as
of
right
now,
we've
accepted
the
governance
stock,
but
we
don't
have
any
members.
B
And
so
well,
basically,
the
way
the
governance
document
is
written
is
that
we
will
to
become
a
member.
You
basically
put
your
name
down
and
say
I'd
like
to
become
a
member.
B
If
no
one
disagrees
you're
a
member
you
wind
up
on
our
official
list,
which
will
be
in
the
community
repo
and
then
maintainers
is,
will
just
take
a
minute
longer
for
people
to
do,
and
so
maybe
this
is
appropriate
for
the
next
meeting,
because
essentially
you
put
your
name
down,
you
have
to
be
a
member,
then
you
say
I'd
like
to
be
a
maintainer
of
repositories,
x,
y
and
z,
and
then
same
thing.
B
If
no
one
disagrees,
you're
accepted,
you
become
a
maintainer,
we'll
need
to
do
the
same
thing
with
the
owners
and
then
probably
most
importantly,
is
that
we'll
need
to
accept
and
create
any
new
repositories
that
we're
gonna
have,
and
maybe
secondarily,
we
need
to
have
a
review
of
the
repositories
that
currently.
B
Exist,
so
that's
what
I
see
as
the
next
steps.
Does
anyone
have
any
ideas
on
how
much
we
should
do
this
meeting?
How
much
we
should
wait
for
the
next
one
also,
I
guess
lastly,
but
probably
importantly,
is
we'll
need
to
have
the
governance
doc
in
the
community
as
well.
E
Do
we
to
help
speed?
I
mean
it
sounds
like
there's
a
lot
on
there
for
next
week.
Is
there
or
the
next
meeting?
Is
there
something
we
can
do
like
start
collecting
a
list
of
members
and
maintainers
or
people
that
would
you
know
like
have
a
document
where
people
like
you've
got
multiple
things
going
on
here?
You've
got
the
network
plumbing
working
group
itself,
where
you
want
a
list
of
members
and
then
you
need
a
list
of
maintainers
of
individual
projects
and
do
we
want
to
just
start
a
document?
B
Yeah,
so
currently,
the
way
the
governance
doc
is
written
is
to
say
that
it
winds
up
in
the
agenda.
So
my
guess
is
actually
let's
just
do
this
right.
Now,
I'm
just
going
to
go
ahead
and
put
in
a
24
attendees
and
then.
B
B
Repository
proposals,
so
what
I'll
do
here
is,
I
will
add,
in
this
september,
24th
section
I'll
just
stub
in
an
example
of
being
a
candidate,
so
I'll
make
a
quick
and
then
yeah
we're
also
going
to
need.
E
B
E
C
B
Yes,
yeah
absolutely,
I
guess
the
the
only
shortfall
is
just
that
we'll
need
to
write
down
each
person
and
then
the
list
of
repositories
that
they
want
to
be
a
maintainer
of
and
then
for
the
new
repositories.
B
What
we'll
just
need
is
the
name
of
the
repository
and
then
a
blurb
to
go
along
with
them
to
describe
what
they
are.
I
don't
think
that
it
like,
for
example,
we
have
some
repositories
that
we
would
like
to
have
as
new
repositories
their
existing
projects.
I
think
they're
fairly
well
known.
I
don't
think
that
we
need
to
like
write
like
a
scope
and
spec
document
or
whatever.
B
I
think
we
just
need
a
short
description
if
people
want
to
move
forward
with
that
today,
that's
great,
although
I
think
that
we'll
pro,
what
we
would
probably
need
to
do
is
take
a
like
10
minutes
of
radio
silence
for
people
to
write
up
these,
to
write
these
off,
etc.
C
Generally
speaking,
we
have
you
know
on
the
nvidia
side,
we
have
a
couple
of
ideas.
You
know
both.
You
know
the
existing
repository
that
part
of
this
team
has
been
working
on
and
and
some
other
you
know,
repositories
that
we
want
to
to
drive.
There
is
no
like
we.
I
don't
think
it
makes
sense
to
wait
on
the
line
for
10
minutes.
So
so
I
think
if,
if
you
maybe
you
can
share
the
document,
we
can
add
this
information
offline.
C
Sure,
yes,
so
I'll
take
an
action
again
on
the
nvidia
team
to
to
to
to
work
on
this,
and
then
we
can
play
this
foot.
B
Okay,
cool
and
you
know
what
I
will
do
as
well
is:
I
am
going
to
I'll
send
a
mail
out
to
the
mailing
list
that
gives
people
this
link
and
I'll
have
the
kind
of
examples
in
here
for
me,
I'll
put
myself
up
as
a
candidate
for
member
maintainer,
github
organization
status
and
then
an
example,
a
repository
proposal,
and
then
everyone
can
go
through
and
add
those,
and
then
this
can
just
be
the
first
order
of
business
next
meeting.
C
B
I
don't
mean
for
this
to
take
longer
than
it
has
to.
H
Yeah,
so
are
there
any
limitations
of
how
many
maintainers
we
can
have
per
repository
like
right
now
that
the
government's
model
doesn't
specify
that
so,
basically,
every
member
can
apply
for
to
become
a
maintainer.
B
Yes,
that's
true,
there
is
no
limitation
as
of
the
moment,
and
I
think
that
the
way
that
it's
written
is
to
say
sure
you
can
have
as
many
maintainers
from
a
given
organization.
D
B
B
On
a
project,
but
when
it
comes
to
accepting
a
pull
request,
you
should
have
like
equitable
representation
from
different
companies.
C
C
G
A
All
right
with
about
20
minutes
left
here
doug.
Do
we
have
more
to
discuss
on
this
one?
Should
we
continue
on
with
other
agenda
items
and
punt
any
more
governance,
stuff
till
next
meeting.
B
G
Okay
cool
so
as
the
put
it
in
the
agenda.
So
currently
we
are.
We
have
year,
one
repository
for
mulch
network
policy
and
then
here
this
contains
everything
I
mean
that
the
schema
files
and
the
apis
and
then
there's
some
ip
table
implementation
as
well,
but
also,
of
course,
the
ip
tab
is
not
the
only
one
for
filtering
stuff
right,
so
the
evpf
and
then
the
dpdk
and
the
inftable.
G
Various
filtering
mechanism
is
also
available.
So
the
I'm
the
expecting
that
the
summer
bringing
the
another
implementation,
such
as
the
most
network
policy
pc.
So
so
that's
why
the
I'm
just
wondering
that
the
I'm,
the
I'm
making
a
separate
from
the
schemer
and
then
the
api
and
implementations.
G
So
now
I'm
creating
the
multi-network
policy,
ip
table
repository
and
then
putting
the
iptable
based
implementation
code
and
then
the
now
I'm
proposing
the
pull
request
to
mouse
network
policy
as
the
api
and
the
utilities.
Among
the
various
implementation,
I
mean
the
common
code
for
our
most
network
policy,
so
like
the
so
currently,
I'm
just
thinking
about
the
api
util
and
the
schema
and
the
goal
types
and
then
the
generated
client,
which
is
the
kubernetes
code
generator
stuff.
G
So
if
so,
I'm
I'd
like
to
double
check
with
you
guys
to
go
proceed
to
making
a
separate.
G
So
if
any
objections
or
some
comments
for
that,
please
let
me
know
and
then
in
the
within
the
a
few
hours
from
now
and
then
the
after
that
I
I'm
making
the
update
to
the
most
network
policy
and
then
the
the
most
network
procedure,
cable,
repository.
B
Well,
tomorrow,
just
to
have
my
comment
that
I
think
that
this
was
an
awesome
way
to
move
forward
and
thank
you
for
separating
this
out
into
the
api
and
utilities
so
that
there
can
be
other
implementations
of
this
without
having
to
either
have
it
jammed
into
all
the
code
base
or
for
people
to
have
to
sift
out
ip
tables
if
they
want
to
have
another
implementation.
So
I'm
all
for
it.
I
G
So
the
this,
the
most
network
policy,
the
schema-
has
the
annotations,
which
is
the
which
interface
should
be
the
target
they
are.
The
user
can
specify
the
network
attachment
definition,
name,
okay,
policy,
yes,
so
so
that
this
network
policy
is
only
for
the
network
action
definition.
So,
regarding
the
crosstalwide
network,
interface,
kubernetes
already
have
the
network
policy.
So
so
that's
that's.
The
candidate
cool.
J
That's
it.
I
have
a
question:
does
anybody
plan
on
working
on
the
tc
flower,
implementation
of
the
multi
multi-network
of
network
policy.
D
Yeah,
I
think,
okay,
I
don't
see
anyone
actually
working
on
that
right
now.
I
think
the
main
purpose
we
want
to
use
tc
back-end
implementation
is,
we
want
to
gain
the
hardware
assist
offloading
with
tc
and
I
think
we
need
to
understand
the
hardware
capability
of
how
that
how
they,
after
the
pc
rules
here,
first
with
them,
without
search
that
mode
and
then
we
can
design
how
we
implement
backend
of
tc.
I
think
that's
what
we
have
discussed
in
the
resource
lab
meeting,
maybe.
A
J
Okay,
yes,
so
we
have
given
the
proposal
another
yet
another
spin.
Thank
you
very
much
to
all
of
you
who
added
comments
on
the
proposal.
J
I
think
it's
in
a
relatively
good
shape.
I
also
have
a
proof
of
concept
working.
I
I
have
the
links
in
the
agenda
document.
J
Basically,
the
the
changes
are.
We
have
refactored
a
little
bit
the
document
so
that
there
is
a
big
section
called
best
practices
for
device
information
management.
J
Please
suggest
another
name
if
you
feel
like
it,
I'm
not
very
good
at
naming,
but
this
is
ideally
the
document
that
the
current
spec
will
refer
to
when
when
we
decide
not
to
put
things
in
the
in
the
mpwg
spec,
and
we
want
to
refer
to
this
best
practices
document
well,
this
is
the
proposed
document
whether
we
end
up
putting
it
in
in
a
repository
or
or
in
another
format.
That's
that's
to
be
decided,
but
that
is
a
proposed
final
document
content.
J
What
else
we
have
fixed
a
a
couple
of
errors
and
we
have
unified
the
way
of
sending
the
information
to
the
cni's
to
the
cni
plugins.
J
So
I
think
that
is
a
much
clearer
implementation
and
and
it's
more
flexible
in
essence,
the
multus
or
the
network,
plumbing
working
group
implementation
would
decide
to
generate
a
cni
device
file
and
we'll
send
a
and
we'll
send
the
file
name
in
a
runtime,
config
key,
and
so
the
cni
will
pick
that
up
and
it
it's
up
to
the
cni
to
create
a
device
information
file
there,
and
if
it
does,
then
the
implementation
will
pick
it
up
and
add
it
to
the
network
status
annotation.
J
So
I
think
I
would
like
to
ask
for
a
final
round
of
comments
or
if
we
are
ready
to
vote
on
it,
or
also,
I
can
show
you
real,
quick.
The
result
on
a
live
demo
right
now.
If
you.
J
A
Yeah,
I
put
put
a
few
more
comments
in
the
doc.
It
may
be
that
you
know
they've
already
been
addressed
or
I'm
just
confused
about
the
proposal.
We
can
follow
up
with
those
comments
in
the
google
doc
itself
or
something
like
that
if
you'd
like
given,
we
have
like
nine
minutes
left
but
yeah
just
a
couple
of
comments
and
maybe
some
clarifications.
A
E
E
E
So
dan,
maybe
doug,
do
you
think
we're
close
on
this
or
do
we
still
have
a
ways
to
go?
We
in
the
right
direction.
A
I
personally
think
it's
close
it's
more
at
this
point.
I
think
bike
shedding
about
specific
details,
but
yeah.
I
think
the
the
direction
is
good
and
we've
worked
out
most
of
the
high
level
architecture,
type
stuff
and
reasoning
for
why
things
need
to
be
the
way
they
are
so
yeah.
I
think
we're
pretty
close.
E
So
one
question
that
I
had
and
I'm
fine
with
the
way
it's
laid
out,
but
I
wasn't
sure
like
the
way
it's
laid
out
is
we
have
a
device
field,
that's
defined
in
the
spec
and
then
the
data
fields?
It
just
says
it's
an
object
and
those
kind
of
refer
to
the
best
practices
on
the
subfields.
E
E
If
you
go
to
the
network
plumbing
specification
modifications,
whereas
it
talks
about
5.3.7,
it
says
device.
F
E
So
it
says
there
is
a
optional
key
and
then,
but
it
doesn't
necessarily
specify
all
the
subfields
of
the
device.
It
says
you
know,
look
at
the
best
practices
just
to
say
what
you
know
what
those
subfields
are
and
I'm
fine
with
it.
I
just
don't
know
if
that's
the
preferred
method
or
we
prefer
to
actually
specify
every
field,
because
it
is
a
spec.
A
B
Yeah,
maybe
one
model
to
follow
might
be
like,
for
example,
in
the
cni
spec
there's
like
a
like,
well-known
fields.
So
it's
like,
if
you
expect
that
there's
you
know
whatever
a
handful
of
fields
that
you
know
basically
always
make
sense.
Maybe
we
should
have
those
and
say
the
rest.
You
know.
B
Okay,
otherwise
I
I
and
also
I
like,
reading
through
the
spec
modifications,
I
don't
have
major
problems
in
general
and
I
probably
could
be
convinced
either
way
here
on
these
fields
with
the
arbitrary.
Although
some
guidance
from
inside
this
document
may
be
maybe
good
with
the
like
whole
implementation
picture
in
the
best
practices
dog.
C
B
Yeah,
maybe
maybe
give
some
guidance
to
the
reader
here
without
having
to
give
the
entire
implementation
picture,
which
I
would
anticipate
being
in
the
breath.
Best
practices.
E
B
Yeah,
maybe
yeah.
E
B
E
A
A
So
we
are
almost
out
of
time.
Let's
do
one
more
round
on
that.
I
think
the
model
of
that
we
have
in
the
rest
of
the
doc
with
respect
to
like
conventions
md
and
what
doug
was
talking
about
with
well-known
fields
is
probably
a
good
model
to
use
here
to
start
with.
A
Since
we
already
have
prior
examples
of
that,
does
that
sound?
Okay?
I'm
happy
continuing
conversation
on
my
comments
in
the
google
doc
comments
as
well.