►
From YouTube: IETF104-NETMOD-20190325-1000
Description
NETMOD meeting session at IETF104
2019/03/25 1000
https://datatracker.ietf.org/meeting/104/proceedings/
B
B
Initially,
the
plan
was
to
have
me
talk
for
five
minutes
on
requirements
which,
after
103,
we
thought
with
some
rewording
that
I'll
go
over.
We
thought
that
they
were
as
sufficient.
Some
recent
discussion
has
come
up
on
the
mailing
list
and
therefore
we
want
to
drill
down
a
little
bit
here.
So
if
there
is
time
after
my
session
Rob
and
mala
and
Rashad
will
come
up
and
talk
about,
what's
up
there.
B
A
C
B
Changes
since
revision,
one
we
modified
requirement
the
Textron
requirement,
one
for
to
pull
out
the
word
software
release.
There
was
some
contention
last
meeting
that
software
release
implied
to
vendor
specific
things,
and
it
was
worried
that
we
would
just
layer
on
more
and
more
versions
based
on
a
vendor
release
cycle.
We
also
changed
the
requirement
of
3.2,
so
it
didn't
suggest
a
solution
but
merely
talked
about
what
we
needed
to
do
in
terms
of
a
requirement.
We
pulled
out
requirement
for
4
and
we
added
an
acknowledgment
for
inspiration
from
the
open
config
group.
B
B
The
solution
must
allow
for
backwards-compatible
enhancements
and
bug
fixes,
as
well
as
non
backwards,
compatible
bug
fixes
in
non
latest
release
modules
we'll
get
into
branching
in
a
minute
when
I
asked
the
various
questions,
but
this
was
sort
of
trying
to
address
the
need
for
some
level
of
branching,
where
we
do
not
where
we
do
want
to
make
changes
to
the
non
current
or
non
head
version
of
a
module.
Next
slide,
please
loop.
B
So
this
is
the
modified
requirement.
3.2
again,
we
did
not
want
to
suggest
a
solution.
This
is
just
the
requirements
draft,
so
the
new
text.
The
solution
must
provide
a
mechanism
to
support
clients
that
expect
an
older
version
of
a
given
module
when
the
current
version
has
had
non
backwards,
compatible
changes,
that's
the
new
3.2
next
slide.
Please
4.4
went
away.
You
can
see
what
the
old
text
was.
There
is
no
new
text
next
slide,
so
the
draft
has
been
adopted.
We
got
an
email
over
the
weekend,
a
belief
from
Lulu
lure
Kent.
B
The
draft
has
been
adopted,
but
there
were
questions
raised
during
the
adoption
call
and
we
want
to
address
them.
Ultimately,
what
we
want
to
do
is
make
some
decisions.
This
is
not
the
final
state
of
this
document
it
has
been
adopted,
but
it
can
still
now
be
ratified
and
worked
on
by
the
working
group.
So
next
slide.
Please
rod
presented
this
slide
in
1
103,
the
last
meeting
relative
to
the
solution.
What
I
want
to
say
here
is
we've
heard
a
lot
of
feedback
from
both
ends
of
this
spectrum.
B
The
requirements
are
supposed
to
kind
of
meet
in
the
middle.
What
the
the
design
team
has
thought
is
the
best
possible
compromise
to
solve
things
that
are
we
already
perceive
are
problems
or
that
are
already
happening,
and
that
we
want
to
make
sure
that
it's
not
the
wild
wild
west
vendors
from
one
have
a
tendency
to
go
crazy.
B
Sometimes
if
we
can
ratify
some
requirements
here
as
well
as
some
guiding
principles,
we
can
hopefully
curtail
any
and
everything
is
allowed
or
vendors
are
just
going
to
do
their
own
thing
isms,
so
we're
trying
to
meet
in
the
middle
come
up
with
a
set
of
requirements
that
people
can
agree,
or
at
least
live
with
next
slide.
Please.
So
the
open
questions,
the
questions
that
were
raised
and
we
really
need
to
come
to
some
level
of
consensus
or
agreements.
B
D
B
We
are
the
question
here
is
more
around.
Is
this
too
rigid
are
we
do
we
need
to?
We
think
at
least
for
deprecated
and
obsolete
changes
are
required.
Is
this
not
doing
us
a
service
in
terms
of
being
able
to
either
release
the
yang
modules
we
need
to
at
at
a
timely
manner,
or
are
we
do
or
are
we
enforcing
things
that
just
aren't
being
followed,
and
thus
there
are
different
solutions
coming
out
of
the
module
author
space
so.
D
E
Ilario
vodka,
I
think
actually
this
is
a
wrong
question
for
me.
The
right
question
would
be
to
ask
whether
section
11
has
to
be
in
in
the
definition
of
ganga
language.
Of
course,
I
understand
that
organizations
like
ITF
may
have
some
policies
regarding
to
update
rules
for
modules.
But
in
my
rule
this
section
shouldn't
we
shouldn't
be
in
the
definition
of
of
yang,
and
so
we
won't
have
these
problems
on
the
level
of
VM
of
code.
B
B
Obviously
they
would
be
in
a
different
draft,
but
they
I
think
there
should
be
something
myself
personally
that
stands
alongside
that
kind
of
reins
in
some
of
this
to
not
make
it
seem,
may
be
so
daunting
or
or
at
least
give
some
bounds
into
into
how
this
is
interpreted
anyway.
Next
slide
our
position.
A
On
before
you
go
there
a
comment.
Well,
an
alternate
question
is
just
whether
the
RFC
is
sufficient
versus
section
11,
because
I
think,
if
you're
saying
just
section
limiting
it
to
section
11
you're,
actually
presupposing
a
particular
solution,
if
you
say
can
we
say
it
can
be
changed
that
the
base
RFC
that
allows
a
wider
scope
of
solution.
B
A
B
So
this
is
if
this
feels
rough,
it's
because,
yes,
we
met
again,
look
like
later
late-ish
last
night
to
kind
of
put
this
together,
but
I
think,
and
hopefully
the
next
slide,
which
shows
our
positions.
Here
we
talked
about
some
of
the
things
that
from
the
purpose
of
revision
or
modifying
modules,
and
it's
already
come
up
a
little
in
the
neck
comp
working
group
today.
This
is
our
position.
B
To
some
extent,
we
didn't
have
all
the
bullets,
but
we
feel
that
it
is
not
sufficient
because,
for
example,
obsolete
introduces
non
backwards,
compatibility
x'
already
there
is
no
way
to
with
import
by
revision.
There
is
it's
too
rigid,
there's
no
way
to
say:
I
need
to
import
this
revision
of
a
yang
module
and
later-
and
you
could
say
well
because
not
there
are
no.
No,
there
should
not
be
any
back
non
backwards,
compatible
changes.
Well,
what?
If
you
need
a
new
leaf
from
or
a
new
grouping
from
a
future
revision
of
the
module?
B
How
do
you
know
that
you're,
starting
at
that
point
and
later
so,
there's
there's
a
limitation
there,
we're
capitulating,
that
vendors
are
already
making
non
backwards,
compatible
changes
and
there's
no
signaling
to
the
user
to
their
consumers
that
these
changes
are
in
there.
So
the
onus
becomes
again
on
the
client
to
be
able
to
figure
and
distinguish
what
is
change
with
respect
to
their
use
cases,
and
today
an
implementer
could
if
they
wanted
say
you
know
what
you're
not
gonna.
Let
me
make
these
non
backwards.
B
Compatible
changes,
so
I'll
create
a
new
module
with
a
new
name
and
I'll.
Just
won't
support
the
old
one
in
the
next
client
and
then
they're
still
going
to
be
shuffling
they're
still
going
to
be
paying
put
on
to
the
end
user.
In
order
to
adapt
to
that,
so
we
feel
that
there's
that,
ultimately,
what
we're
saying
is
there
is
a
problem
to
be
solved
here.
What
that
solution
is
what
the
solution
to
the
problem
is
is
up
for
some
debate,
but
there
are.
B
D
D
B
I
wouldn't
say
allowed
I
allowed,
maybe,
but
should
they
be
supported?
Yes,
I
stand
through
the
email.
This
morning,
I
saw
Andy's,
email
and,
and
ultimately
one
of
our
goals
has
been
in
the
design
team
is
to
make
it
to
signal
to
the
consumer.
The
end
user
that
non
backwards
compatible
changes
exist.
So
I
I
would
tend
to
agree
with
what
Andy
was
saying
there.
D
G
H
A
cylinder,
Cisco,
Systems
I
have
been
involved
in
all
the
discussion,
so
I
apologize
if
I
missed
something,
but
what
would
really
be
useful
would
be
how
these
were
handled
from
a
workflow
standpoint,
both
of
us
from
the
client
and
the
server
like.
How
do
you
deprecated
one
node
and
support
it
and
then
move
to
something
different?
Just
like
you
know,
you
know,
what's
what's
day
zero
day
two
day,
three
and
the
different
phases
that
would
be
invaluable
and
get
everybody
do
and
to
get
everybody
to
agree
on
it.
So.
B
About
that,
some
of
the
proposed
solution
that
that
will
maybe,
if
we
have
time
be
presented
next,
goes
into
some
of
that.
In
fact,
we
have
sections
in
there
about
a
believer.
Schad
was
one
of
the
major
contributors
there.
What
should
a
module
author
do
as
part
of
the
transition
if
they
need
to
introduce
these
non
backwards,
compatible
changes
so
time
allowed?
We
will
get
to
discussing
some
of
that
from
a
requirement
standpoint.
I
like
martin,
the
kind
of
the
question
revision
and
yes,
we
want
to.
B
We
realize
these
things
in
fact,
next
slide,
please
Lou
I
think
we
have
some
positional
elements
here.
They
are
not
necessarily
desired,
but
sometimes
you
have
to
do
them.
You
have
to
make
them
because
they
make
the
most
logical
sense.
For
example,
fixing
a
bug
in
a
node
makes
more
sense
to
change
it
than
to
deprecated
and
and
then
obsolete,
and
then
create
a
new
node.
How
do
we
signal
that
to
the
user
to
to
handy
and
then
Martin's
point
at
the
microphone?
B
How
do
we
signal
that,
so
that
there
is
an
expectation
that
this
could
have
a
breaking
or
an
impact
on
on
tooling,
so
it
becomes.
The
transitional
period
is
less
painful
to
that
user
from
a
requirements
standpoint.
Ultimately,
therefore,
we
feel
that
yes
non
backwards.
Compatible
changes
should
be
allowed,
should
be
supported,
and
there
needs
to
be
that
that
mechanism
to
signal
that.
A
I'm
struggling
with
a
comment
that
I
still
feel
like
the
phrasing
here
is
presupposing
a
solution
in
that
I
think
we
can
all
agree
that
we
need
better
support
for
non
backward,
compatible
changes,
whether
it
requires
what
we
do
with
the
the
path
or
the
specific
node
references.
The
expats
I
think
that
could
be
part
of
the
solution
discussion
and
we
don't
have
to
include
that
in
the
phrasing
of
the
requirements.
A
If
it's
not
on
the
slide,
it's
in
it
was
in
what
you
said
ok
earlier,
and
it
goes
also
a
little
bit
too
I
think
some
of
the
point
that
Martin
was
raising
about
it
was
the
term
required
allowed
I
think
we
all
agree
that
we
need
to
do
something
here.
I
think
it's
in
the
solution
space.
We
have
some
radical
disagree:
okay,.
B
So
let
me
ask
it
this
way,
then,
to
your
comment:
is
there
anything
in
the
current
text
of
the
requirements
draft
that
you
well
it's
been
adopted,
so
I
realize
that
text
will
change
as
we
as
we
shape.
This.
Is
there
anything
immediately
in
that
text
that
you
object
to
that
that
we
could
quickly
or
or
in
the
near
term,
change
I
went.
A
Through
it
actually
last
night
with
exactly
that,
thought
and
didn't
have
a
good,
a
good
answer.
There
was
some
minor
things
like
what
Rob
brought
up
about
comments
about.
Is
it
really
bad
for
the
client
or
was
it,
but
those
are
that's
not
really
significant.
I
do
think
we
should
think
about
if
there's
a
way
we
can
improve
it
and
and
really
that
I
think
will
directly
address
Martin's
objection
that
he
had
during
the
adoption,
Paul
or
I
hope
we
can
figure
out
how
to
fix
the
language
to
do
that.
Okay,.
A
Was
part
of
why
we
we
talked
about
whether
we
should
adopt
it
or
not,
and
we
eventually
decided
yes,
because
we
can
change
it,
okay
and
what
we
think
is
really
important
to
do
that.
So
we
have
to
it's
a
struggle,
but
we
have
to
figure
out
how
to
get
the
language
right
there,
oh
great
okay,
and
to
Andy's
point
about
you
know
how
important
is
that
Harmons
document.
Personally,
this
is
not
a
personal
statement,
not
a
chair
statement.
A
I,
don't
really
care
if
it's
publishes
an
RFC
I
think
it's
very
important
that
we
have
a
working
good
document
that
establishes
consensus
on
or
defines
the
consensus
of
what
it
is.
We're
trying
to
solve.
So
I
think
that's
really
important
to
help
us
get
to
a
solution,
whether
it
the
requirements
that
comes
in
RFC
pairs
and.
B
D
So
Martin
you're
claiming-
and
if
that
is
what
is
going
to
happen
with
this
document-
that
it's
not
going
to
be
published
as
Salar
see
then
I
think
that
should
be
stated
because
otherwise
we'll
be
reduce
as
if
it
was
going
to
be
an
RC
right.
We
don't.
We
don't
have
to
spend
time
reviewing
language
stuff,
for
example,
or
things
like
that,
if
it's
just
for
like
an
temporary
document,
I
just
not
going
to
be
published.
A
I
think
we
from
a
chair
standpoint,
we
haven't
established
that
we're
gonna
defer
to
the
working
group
on
that.
So
if
the
working
group
wants
the
publisher
there's
an
RFC,
that's
fine!
If
there,
if
we
end
up
with
the
solution
and
then
say:
okay
now
it
doesn't
matter
that
I
think
that's
fine.
Also
so.
I
Yeah
I
think
as
a
chair,
I
posted
to
the
DT
mailing
list
on
this
very
point
and
I've
made
exactly
lose
point.
That
is
it
important
to
have
a
document
that
establishes
working
group
consensus
and
even
taking
it
to
last
call
whether
or
not
we
published
it
would
be
sort
of
the
open-ended
question
that
and
I
personally
wasn't
concerned.
You
know
which
way
it
went
but
I
believe
there
were
some
feedback
from
the
DTU
members.
This
is
saying
that
you
know
put
that
much
work
into
it,
that
we
should
publish
it.
I
It
doesn't
hurt
the
publication
process
itself
is
cheap.
If,
if
the
publication
process
is
the
thing
that's
in
the
way,
then
that's
a
process
issue.
You
know
we
shouldn't
allow
that
to
complicate
things
so
I
think
I
actually
understood
it
at
least
that
the
DTD
wanted
to
publish
it.
You
know
to
have
it
as
an
informational
RFC.
We.
B
J
Rob
Wilson
Cisco,
so
I
think
that
one
of
the
things
I've
discussed
with
Martin
earlier
today
was
making
like
the
background
section
in
this
document.
I
think
he
was
describing
that
some
of
those
that
description
wasn't
necessarily
ideal
and
could
be
rephrased
and
worked
on.
The
question
is
whether
that's
a
useful
use
of
time.
If
the
only
thing
we
care
about
this
document
is
actually
the
list
of
definitive
requirements,
then
do
got
to
spend
time
discussing
the
background
text
who's
not
going
to
progress
further
or
would
be
better
to
say.
J
A
We
have
a
solution,
I
think
whether
I'm
not
saying
the
decision
of
whether
anyone's
proposing
killing
the
document
right
now,
the
question
is:
is
once
we
have
it
capture
what
the
requirements
are.
We
have
agreement
down
the
line,
we'll
build
solutions
based
on
that,
once
we
have
that,
do
we
actually
publish
this
in
RFC
or
not
and
I
think
that's
an
open
question
right.
I
But
to
Rob's
point
the
question
was
to
what
effort
you
know
to
what
I
simply
put
the
effort
into
you
know,
making
sure
every
part
of
this
document
is
complete.
Now
I
personally
would
like
to
get
a
sense
from
the
room,
if
you
don't
mind
so,
for
those
sorry,
Kristian
hops
can
I
make
a
suggestion,
I
think
Martin
and
Rob
both
saying:
let's
not
work
on
language
issues,
if
we're
not
going
to
publish
it.
So
why
don't?
A
I
Well,
I
think
right,
so
that
was
one
of
the
opinions
so
Chris
you
get
to
not
raise
your
hand.
So
for
those
who
would
like
to
see
this
document
published
as
an
RFC,
can
you
please
this
is
the
requirements
document
for
those
who
would
like
to
see
there
are
the
requirements
document
published
as
an
RFC?
Please
raise
your
hand
just.
I
A
few
for
those
who
would
like
to
not
see
it
published
as
obviously
you
do
not
want
to
have
this
published
as
an
RFC.
Please
raise
your
hand
equal
number,
just
a
few,
so
we're
going
to
defer
oh
I'm,
sorry,
how
many
people
we
should
defer
that
decision
and
almost
double
the
number
is
there
say,
that's
a
few
all
right
thanks!
Okay,.
A
B
Right
last
question
also
probably
going
to
be
question.
One
next
slide:
please
yep
is
branching
required
and
if
so,
how
much
branching
is
needed
and
for
clarity,
because
again
we
wrote
these
last
night.
Branching
means,
if
I
need
to
make
a
change
to
the
non
latest
version
of
the
module.
So
things
are
going
on.
I've
made
some
changes,
there's
only
one
instance
ever
of
that
module
and
then
all
of
a
sudden
I
realized
that
the
latest
revision
is
something
and
I
have
to
go
back
and
change
the
other,
a
change,
an
older
revision
of
it.
B
I
Hutt's
again
I
I've
been
trying
to
hold
off
on
those
questions
the
end,
but
I
think
somebody
else
might
have
mentioned
this
in
lists.
I,
don't
think
I
would
have
it
quite
as
many
objections
to
all
of
this
that's
going
on.
If
you
just
said
it
was
for
vendor
models
like
it
wouldn't
be
used
in
standardization.
You.
I
If
it
was
if
the
branching
and
all
of
these
different
requirements
were
narrowed
in
scope
to
only
vendor-
in
other
words,
not
IETF
publish
models
modules,
you
know
because
I
don't
see
any
need
for
branching
in
in
standards
and
as
a
matter
of
fact
it
would
be.
A
horrible
outcome
to
have
branches
of
is,
is
module
right,
I
mean
it's
just.
This
is
so
much
complexity,
that's
absolutely
not
needed.
The
process
of
standardizing
modules
should
get
us
good
enough
things,
so
we
just
need
to
augment
them.
We
just
don't
need
this
at
all.
I
Now
you
wanted
to
be
able
to
track
your
vendor
models
on
release
trains,
and
you
have
all
these
other
requirements.
I
just
don't
want
to
see
that
move
into
the
standardization
process
right.
So
you
know
I
think
that
maybe
if,
if
there
were
two
trains
for
the
requirements,
right,
one
for
vendors
non-standardized
and
one
for
Center
is
because
for
standardization
all
we
need
is
a
way
to
import
by
revision
and
I.
Think
the
problem
solved.
So.
B
B
Maybe
it
is
that
the
standards
body,
or
at
least
the
IETF,
chooses
not
to
do
changes
to
older
revisions.
That
said,
we
have
heard
from
one
working
group
chair
in
routing
area
that
there
is
a
desire
to
do
this,
not
necessarily
make
backward
non
backwards,
compatible
changes
to
a
previous
revision
of
a
module,
but
to
branch
or
create
two
parallel
tracks
of
a
single
I.
Don't
know
if
it's
still
valid,
but
this
was
heard
on
the
design
team
a
few
months
ago.
B
E
Vodka,
I
guess
I
agree
with
what
Chris
said
just
and
I
think
it
comes
down
to
my
point
about
having
section
11
in
in
in
in
the
yang
the
definition
of
yang,
because
in
fact,
I
underst
I
agree
that
in
the
IDF
we
needn't
any
branching,
probably
whereas
there
are
communities
that
apparently
need
it
right.
But
at
this
point
we
shouldn't
be
discussing
whether
having
some
branches
violates
the
young
specification
of
something
like
that.
We
just
have
to
accept
that
there
will
be
cases
where
some
client
won't
be
able
to
speak
to
some
some
server.
E
But
I
think
this
is
okay.
We
can
have
niches,
they
just
work
and
we
already
have
them
open.
Config
is
such
a
niche
and
they
can
do
it
whatever
they
want.
So
I
think
that
it
would
be
better
if
we
have
some
some
or
if
there
are
some
standards
underlying
or
all
this,
even
though
there
may
be
some
some
niche
is
having
different
tooling,
for
example,
and.
B
And
from
a
requirements,
standpoint
I
think
it
makes
sense,
then
to
say
that
yes,
branching
should
be
supported
and-
and
we
can
talk
about
what,
where
we
constrain
that
and
then
separately
decide
what
is
perhaps
from
a
solution
standpoint.
What
are
the
right
recommendations
for
different
bodies?
If
you
will.
J
Robots
in
Cisco,
so
you're
going
back
to
Chris's
points
point
about
branching
within
like
standard
models.
I
still
think
it's
possible
that
I
84
standardized
and
yo
module
that
has
bugs
in
it.
It
may
be
that
that's
the
latest
revision
in
and
get
fixed.
That's
fine!
There's,
no
issues,
no
practice
required.
It's
also
possible
that
that
might
happen
to
a
model.
This
older
that
suddenly
starts
using
some
parts.
It's
not
been
well
implemented
and
finds
out
those
mistakes
in
that
and
they
actually
want
it
to
be
fixed
in
that
order.
I
So
so
I'm
staying
away
from
trying
to
get
too
deep
in
here
is
branching.
Is
a
branching
solution
considered
changing
the
module
name?
Because
that's
what
I
would
say
you
do
there?
If
you
come
up
with
a
new
BGP
module
and
it's
a
major
revision,
you
just
change
it
to
PGP
module
to
write
and
then
I
mean
well.
Why
do
I
need
branching
it
unless
that's
ranching.
A
Chris
I'll
point
out
that
that
is
presupposing
a
solution,
and
that's
that's
right.
So
the
problem
here
is
is
how
to
phrase
the
questions
without
getting
into
the
solution.
Space
I
think
I
tried
to
here
I
think
allowed,
would
help
okay
and
probably
every
place
you
have.
This
is
Martin's
point.
Okay,
every
place
you
have
required
say
allowed
okay,.
B
J
Going
back
to
Chris
I
still
think
in
that
scenario,
if
it's
an
old
module
that
says
BGP
for
example,
and
there's
some
bit,
it
was
broken
and
you
said
actually
I've
seen
that
bit
to
be
fixed
in
that
order
and
that
order
revision.
You
produce
a
new
module.
Just
if
that
fix
you
got
to
not
produce
just
a
new
module
version
for
that
BGP
module,
but
everything
else
or
comments.
It
also
has
to
have
a
new
revision
to
be
able
to
hook
together.
J
The
Mike
so
Chris
was
asking
can
give
a
concrete
example
in
terms
of
what
is
published
now
in
an
old
module,
no
L
to
SM
when
that
was
published,
had
lots
of
mistakes
in,
but
it
wasn't,
it
wasn't
developed,
so
they
just
fixed
it.
They
they
bypassed
the
rules
and
published
a
new
revision
that
was
number
was
compatible.
J
That's
okay,
because
you
still
do
linear
development,
but
if
the
case
that
actually
some
people
have
implemented
parts
of
that,
then
it
becomes
much
harder
to
do
and
that's
the
point
where
you
may
actually
want
branching,
even
in
IETF,
I
I'm,
not
I'm,
not
saying
it's
a
good
thing,
I'm
not
saying
a
be
used
a
lot,
but
there
might
be
point
instances.
Even
then.
The
variety,
if
is
a
pragmatic
thing
to
do
you
just
want
to
fix
that
much
in
a
small
way,.
I
But
I
don't
understand
what
okay,
so
so
I've
got
a
module
and
it's
got
a
bug
and
then
I
need
to
fix
the
bug.
So
I
produce
a
new
module
right,
but
you're
saying
I
should
produce
a
new
branch
and
I
should
fix
the
old
branch.
You
know
why
don't
I
just
fix
the
module
and
publish
the
new
fix,
and
if
we
have
import
by
revision
you
could
maybe
narrow
it
down
and
get
the
old
version
of
you.
J
So
the
case
I'm
concerned
about
is,
if
there's
already
a
published
provision,
there's
already
an
updated
revision.
So
it's
not
the
latest
one.
You
want
to
fix
it's
an
older
revision.
So
yes,
you
but
I
do
want
to
fix
both,
but
it's
the
older
one
that
I
actually
care
about.
That's
the
one
that
we
might
be
shipping
that
someone
wants,
with
a
fix
it
I
can't
ensign
own
fix,
like
I,
think.
D
Some
Mortimer
Club
common
to
this
discussion,
anyways
and
I,
think
we
have
the
same
comment
about
non
backwards:
compatible
changes.
If
we
talk
about
on
this
without
changing
the
identification
of
the
node,
that
is
not
changing
the
module
name,
node,
name
or
path,
anything
in
that
so
branching
and
non
backwards,
compatible
changes
or
for
existing
or
without
changing
the
node
identification,
because
otherwise
it's
trivial,
as
you
said,
you
can
just
create
a
new
module
right.
We
don't
have
discuss
anything.
D
A
B
D
B
So
that's
the
get
this
right.
That
is,
the
I
think
requirement
one
for
we
did
not
put
in
the
explicit
word
branching,
but
we
intended
to
what
we
said
is
a
change
to
a
non
latest
or
non
current
or
non
head
version
of
a
module
would
maybe
imply.
Maybe
that's
an
area
of
language.
We
could
be
more
explicit
in
Tim,
so.
L
Item
carry
no
kid
just
to
just
let
you
know,
I
mean
we
in
in
the
BB
F.
We've
been
doing
modeling
for
about
fifteen
years
now,
and
we
do
have
this
method
in
place
and
we
have
used
this
method.
It
happens
probably
about
every
two
years
or
so,
and
it's
on
simplified
backward-compatible
changes
things
that
you
change
may
be
a
range
you
know
like
to
get
a
portray,
long
or
or
datatype
might
be
wrong
that
you
can
do,
but
we
have
various.
L
We
have
very
restrictive
requirements
as
to
what
is
allowed
to
be
done
in
that
in
that
fix
right,
and
it
has
to
be.
The
critical
piece
was
that
it
had
to
be
backwards
compatible.
So
you
can
only
like
increase,
arrange
or
the
types
have
to
be
consistent
between
the
two,
because
we
know
that
those
things
are
in
the
fields,
so
you
can
expand,
but
you
can't
contract
the
meaning,
and
so
there
were
some
rules
that
we
put
around
it.
So
we
were
very
concerned
about
it
to
make
sure
the
things
were
back.
B
Last
slide
just
to
cap
on
this,
so
so
we
think
that
some
we
should
allow
some
level
of
branching
but
I
think
maybe
Tim
brought
up
the
point
of
bound
thing
and
he
wasn't
necessarily
talking
about
branching
there
but
bound
what
can
be
changed
in
the
non
latest
version
of
a
module.
We
had
this
discussion
on
the
design
team
a
lot.
B
What
is
a
bug-fix
should
only
bugfixes
be
allowed
in
those
non
latest
revisions
of
the
module,
and
we
couldn't
agree
on
what
should
be
allowed
because
different
authors
are
going
to
want
to
do
different
things,
but
in
terms
of
branching,
we've
heard
from
both
sides
and
one
side
is
no
branching.
Everything
should
be
linear
and
then
the
other
side
is
sky's
the
limit.
B
It
can
be
more
like
get
as
an
example
or
a
revision
control
system,
and
we
think
that
there's
probably
a
balance
there,
but
that
goes
more
to
the
solution
side
of
things
which
may
be
no,
we
won't,
but
in
within
the
propose
the
design
teams
proposed
solution.
We
talked
about
how
we
would
address
branching
regardless.
We
feel
that,
however,
we
do
it
with
recommendations
for
IETF
versus
non
ITF.
We
feel
that
branching
as
a
as
a
concept
should
be
allowed
in
the
solution
and
therefore
should
be
a
requirement,
and
maybe
to
Martin's
point.
B
I
Was
going
to
present
Joe
Thanks,
so
question
I?
We
feel
bad
about
having
run
out
of
time
and
of
course
we
did
have
to
address
the
requirements
issue
and
but
still
there's
a
lot
of
discussion
to
be
had
around
the
other
slides
that
were
not
presented.
The
chair
would
like
to
ask
if
people
are
planning
to
be
here
on
Friday,
we
could
potentially
uncounseled
Friday's
meeting
and
and
allow
people
to
continue
having
some
of
discussions,
while
you're
here
together
so
for
I,
just
get
a
sense
from
the
room.
B
M
A
About
that,
that's
what
we
were
gonna
go
is
there?
What
is
a
right
now,
an
informal
design,
team
meeting
and
a
question
for
the
design
team?
Are
you
comfortable
publishing
that
to
the
list
and
have
inviting
anyone
who
wants
to
come
discuss
as
have
an
informal
meeting
and
just
take
advantage
of
the
time
here
and
see
if
you
can
have
more
discussion,
other
requirements?
A
A
I
I
want
to
say,
there's
a
planned
gang
next
get-together
meeting.
Perhaps
that's
what
Charles
saw
it
says
it's
a
different
topic,
but
there
are
there's
other
time
within
the
experiment,
hours
available
and
potentially
even
tomorrow.
You
know
this
work,
we're
not
meeting
okay
but
actually,
but
going
to
the
point
about
Friday.
If
balázs
is
the
only
design
team
member
that
is
going
to
be
present
on
Friday
I,
actually,
don't
think
it's
going
to
make
sense
to
try
to
do
a
meeting
on
Friday.
J
Rob
Walton,
so
we
have
a
design
gang
version,
design
team
meeting
scheduled
for
Tuesday
afternoon,
the
last
slot
about
4:00
p.m.
to
6:30
and
we've
got
a
room
booked
for
that,
so
which
I
think
I
might
be
wrong,
holds
60
people
so
I.
That
might
be
a
good
opportunity
for
people
who
are
interested
to
have
that
more
open
form
and
I.
Think
that
makes
sense
to
have
everyone
here,
because
we
meet
a
regular
basis
over
WebEx.
Anyway,
that's.
G
A
Basically,
an
invite
say
this
is
when
we're
getting
together
and
please
then
report
back
to
the
working
group
on
email,
and
we
can
try
to
resolve
this
as
much
as
possible
on
email.
Given
the
time
constraints,
I
think
we're
gonna
have
to
end
up
with
a
interim
if
we
don't
end
up
with
some
easy
solution
on
email,
yep.
B
A
A
Thank
you
all
for
accommodating
the
the
tight
schedule,
and
hopefully
we
can
resolve
this
before
the
next
IETF,
whether
it
be
on
list
or
through
it
use
of
interims.
Thank
you
so
we're
meeting
again
later
in
this
afternoon
session,
one
in
Congress
Hall,
one
in
Congress
hall,
one
so
thank
you
and
we
do
actually
have
to
vacate
the
room
because
there's
another
group
coming
in
in
about
ten
minutes
and.