►
Description
Evolvability, Deployability, & Maintainability (EDM) Program Meeting, 2021-08-04
https://datatracker.ietf.org/group/edm/meetings/
C
D
D
We
may
disagree
on
the
first
point,
but
I
do
agree
on
the
second
point,
and
so
I've
cut
that
down
quite
a
lot
in
the
pull
request
that
I've
got
there.
One
of
the
things
that
sort
of
came
out
of
the
discussion
would
tell
us
about
this.
One
was
that
this
is
probably
just
a
distraction
from
the
from
the
central
theme.
D
E
F
A
D
D
D
C
E
For
me,
it's
quite
central,
because
that's
that's
only
if
you,
if
you
can
protect
the
in
the
variant
parts
of
your
protocol,
which
is
either
by
doing
encryption
or
using
or
whatever.
Actually
it
makes
sense
to
talk
about
inverters.
If
you,
if
you
don't
have
any
encryption,
then
there's
like
you
know,
nothing
can
do
against
justification.
D
It
also
recognizes
that,
most
of
the
time,
the
problems
that
you
encounter
are
the
the
things
you
want
to
talk
to
anyway,
and
that's
really
what
I
wanted
to
to
focus
on,
so
it
the
first
sentence
there
from
the
security
consideration
sex
is
controversy,
can't
might
be
used
now.
I
can
change
that
to
a
can,
or
some
other
word,
if
you
think,
that's
more
appropriate.
E
C
C
D
They
talked
about
invariants
there
and
one
of
their
examples
was
the
iptl
and
what
it
means
you
decrement
the
ttl.
Every
time
you
forward
a
packet
and
that's
something
that
a
lot
of
other
capabilities
in
the
protocol
depend
on
and
if,
if
that
does,
if
that
invariant
is
not
maintained,
it's
no
longer
called
ip
and
that's
kind
of
central
to
the
to
the
whole
thing,
and
that
was
actually
central
to
the
debate
that
was
had
at
the
time
of
5704
in
it
and
mphl
mptls
mpls,
yeah
yeah.
So.
H
E
Right
no,
but
I
mean
the
whole
point
about
so
invariants
are,
are
easy
because
that's
the
part
that
cannot
define
one
exhaustive
fight
or
whatever,
but
to
protect
the
part
that
is
variable.
You
need
something
else
and
that's
like
you
know.
If
you
cannot
encrypt
it,
then
it's
greasing
or
use
it.
If
you
can
encrypt
it,
then
that's
another
way
to
protect
some
of
that.
C
Maybe
maybe
I'm
wondering
if
there's
another
way
to
put
it
that
doesn't
make
cryptography
like
the
key
thing
that
you
should
do,
but
could
we
instead
say
limit
limit
participants
as
a
way
to
improve
this?
Cryptography
is
one
way
to
do
it,
but
another
way
to
achieve
something
that
can
be
extended
is
limiting
participants
by
having
it
be
in.
You
know,
like
only
for
these,
this
particular
protocol
within
your
limited
domain.
H
E
B
D
B
D
D
E
C
C
F
C
C
G
E
C
C
D
E
E
F
F
C
C
I'm
okay
with
this-
I
I
think
there
you
know
just
for
just
for
open
discussion
for
this
group.
I
think
there's
it'll
be
interesting
to
see
how
things
work
out
with
quick
having
grease
from
the
beginning
versus
adding
stuff
later,
but
I
don't
think
there's
going
to
be
anything
we
can
comment
here
in
the
document,
especially
now
how
we
rephrase
things
to
say
you
know
it's
just
falsifying
and
use
yes.
E
And
I
think
from
this
document
has
already
changed
a
little
bit
that
beginning
at
the
beginning,
it
was
very
focused
on
greasing,
and
now
it's
more
focused
on
active
use,
which
I
think
is
the
right
thing
to
do
and
what
we
say
in
the
document
is
that
reasoning
has
proven
to
be
useful
for
the
dls
ttls
case,
where
it
was
added
later
on,
but
everything
else
still
has
to
be
proven.
So
I
think,
like
that
direction
already
changing.
This
is
addressed
to
some
extent.
H
A
I
I
think
there
are
some
lessons
from
the
initial
quick
deployment,
because
we,
like
literally
when
we
added
we
added
greasing
to
we
crashed
one
of
the
implementations
and
that
got
fixed
before
we
it
shipped.
So
that's
that's
an
example.
We
could
mention,
because
that
got
fixed
before
anything
in
production.
C
H
E
H
C
Right,
I
think
that's
a
great
thing
to
do,
and
I
just
capture
and
I'm
typing
in
those
notes
into
the
issue
on
kind
of
our
program
side.
I'm
just
I'm
worried
about
bloat
on
this
one
and
I
think,
there's
there's
a
lot
of
work.
We
can
still
do
talking
about.
You
know
how
do
we
do
the
deployment
of
a
protocol
within
a
group.
C
D
C
D
Yeah,
I
think,
we've
we've
tried
a
couple
of
things
that
work
this
way
and
it's
actually
a
pretty
cool
design
technique,
particularly
once
you
have
crypto
in
in
the
mix-
and
this
is
one
of
those
things
that
we
sort
of
did
in
quick
to
some
extent,
with
the
way
that
we
did
address
validation
for
the
handshake.
There's
no
additional
overhead,
you
just
encrypt
the
packets
and
if
they
don't
decrypt,
then
it
wasn't
legitimate
and
that
just
sort
of
falls
out
by
virtue
of
tying
into
other
things.
But
it's
a
design
technique.
E
D
C
Right,
I
guess
the
way
I
would
first
is:
do
we
think
there's
anything
in
this
section
on
dependency
that
is
lacking,
and
I
I
feel
like
this
ends
up
just
being
an
example
of
one
way
to
achieve
dependency.
But
you
know,
given
that
we
are
moving
more
and
more
of
the
examples
out
of
the
text
and
just
saying:
hey,
here's
just
here's
the
principle.
A
C
E
D
A
C
F
F
C
D
A
D
D
D
E
I
D
D
C
H
C
I
mean-
and
I
do
think
the
time
scale
for
what
it
means
to
evolve
and
deploy
something
new
is
definitely
different
at
different
layers.
Right,
like
your
time
scale
for
doing
a
new
ip
feature
in
routers
is
definitely
very
very
different
than
adding
a
new
header
in
http
or
something
else,
but
I
I
just
don't
know
if
it's
it
really
changes
what
we
say.
E
H
F
D
G
D
D
F
D
E
E
E
It
and,
of
course
the
iab
will
see
that
this
document
is
on
some
agenda
at
some
point,
so
everybody
has
a
chance
to
look
at
it.
My
question
is,
rather,
do
we
want
to
pick
or
do
we
want
to
find
like
one
or
two
more
people
who
actually
ensure
that
they
will
do
another
in-depth
review
of
the
document,
or
are
we
fine
with
with
the
amount
of
people
we
had
so
far.
C
I
think
we've
got
a
number
of
good
eyes
on
it.
Some
people,
particularly
in
this
last
kind
of
call
to
list-
I
I'm
very
happy
with
the
attention
we've
got
on
it
in
the
reviews,
so
I
think
just
kind
of
kicking
it
through
the
normal
process
would
be
okay.
From
my
perspective,
I
don't
know
if
anyone
is
curious.
E
E
C
C
I
don't
know
how:
how
do
you?
What
do
you
think
practically
could
be
done
here?
You
know,
I
think
yeah
you
could
formalize.
Oh
here's
the
way
to
hook
up
your
github
code.
How
do
we
think
that
would
actually
play
out,
though
I
mean
essentially,
how
do
we
replicate
some
of
the
good
stuff
we
see
with
quick
of
saying,
hey?
There
are
a
lot
of
interoperable
implementations
that
are
working
on
this
and
get
that
benefit.
D
D
B
E
This
point
that
so
the
implementation
section
is
supposed
to
be
removed
before
publication
as
rfc,
because
what
you
said
it's
like
they
outdate
very
quickly,
but
on
the
other
hand,
if
you
read
an
rfc,
it
would
be
still
very
useful,
even
just
to
have
a
report
with
outdated
code
like
to
have
like
any
kind
of
pointer.
So
how
do
we
get
that.
F
H
G
H
Sure
any
of
those
implementations
are
still
used
these
days,
and
I
I
I
still
worry
that
we'll
be
pointing
to
code.
That's
just
not
that's
actively
misleading
rather
than
just
not
useful,
and
I
I
also
worry
slightly
that,
if
we're
not
careful,
we'll
we'll
run
into
antitrust
issues
and
that
sort
of
thing,
if
we're
pointing
at
particular
implementations
rather
than
indirecting
it
through
some
third
party,
that
says
you
know,
there's
a
community
maintained
list
over
here.
D
Yeah
quick
ended
up
with
that
that
sort
of
indirection,
and
I
think
it's
worked
out
reasonably
well.
If
you
look
at
the
the
the
wikis
that
are
maintained
on
quick
or
tls
that
it's
just
people
make
their
own
contributions
to
the
thing
and
it
turns
out
to
be
useful,
I
think
that's
all
charles
is
really
asking
for
here
as
well.
It's
just
that
there's
a
little
more
formalism
around
the
the
way
that
it's
set
up
so
that
there's
standard
places
you
can
go
to
look
for
these
things.
E
C
Yeah
one
of
the
interesting
things
you
know,
obviously
charles
comes
from
the
background
of
hackathon
here
and
also
you
know,
martin.
What
you're
pointing
to
is
that
you?
We
have
these
high
energy
moments
where
people
are
engaged
and
that's
when
this
works
well
and
then,
eventually,
you
know
people
ship
out,
and
you
know
they
have
other
priorities
and
not
going
to
keep
updating
these
things.
C
I
wonder
if
you
know
to
some
degree,
would
it
make
sense
to
have
these
pointers
really
be
too
like
snapshots
that
are
like
how
you
have
in
data
tracking
like
here
was
a
meeting
and
then
like
that
was
the
meeting
that
happened
on
this
day
and
it's
kind
of
expired
now
and
like
here
was
this
interop
event,
and
here
are
the
here's,
the
things
that
were
tested
here?
You
can
go
look
at
that
snapshot,
but
it
maybe
it's
not
as
misleading
michael.
You
have
your
hand
up.
J
G
And
I've
been
involved
in
quite
a
few
interop
events
and
hackathons,
and
sometimes
you
really
don't
have
any
idea
and
some
some
events
have
been
covered
by
interesting,
ndas
and
and
although
the
the
in
hindsight,
I
wish
I
had
known
about
what
chatham
house
rules,
because
that's
actually
really
what
you
really
really
want
right
and
but
I'll
say
this.
This
is
a.
I
don't
know
how
to.
G
I
don't
know
how
to
say
this
loud
enough
to
the
right
people,
because
none
of
them
are
in
the
room
right
that,
if
you
think,
if
your
company
thinks
that
you're
going
to
eventually
implement
protocol
foo,
but
only
after
it
becomes
rfc,
then
you're
going
to
miss
all
of
the
interop
events.
That
actually
will
make
you
clueful
enough
to
actually
implement
it
properly.
G
And
I
don't
know
how
to
say
that
loud
enough
to
people,
you
don't
have
to
ship
a
product.
But
you
know
that
was
the
case
for
ike
v2
15
years
ago
right.
The
people
who
were
that
in
that
room
in
toronto
are
the
people
that
have
trop
products
and
the
people
that
weren't
in
that
room
yeah.
They
still
have
like
v1,
right
and-
and
it
can't
be
said
loud
enough-
I
don't
know
how
to
to
do
that.
But
anyway
we
we
we
had
a.
G
So
we
couldn't
do
that,
but
being
able
to
run
that
on
a
ongoing
basis
is
actually
a
really
really
valuable
kind
of
thing
and
the
the
the
having
people
leave
their
systems
up
is
valuable
and
also
that
that
that
thing,
actually,
you
know,
essentially
punches
through
all
their
corporate
firewalls
into
the
lab
right
and
they
can
never
get
things
exposed.
Otherwise,
even
even
they
go
to
amazon
or
whatever,
they
still
can't
think
get
the
right
things
exposed
to
test
things.
Oh.
G
G
C
G
Well,
yeah,
so
so
that's
that's
part
of
it
and
and
the
thing
that
worked
for
us
two
weeks
ago
was
that
we
only
said
we're
going
to
be
together
for
an
hour
at
a
time
at
you
know
the
typical
10
a.m,
eastern,
and
so
that
was
a
minimum
amount
of
of
disruption
to
people's
time
and
we
got
together-
and
we
very
clearly
you
know
pulled
up
screen
shares
to
look
at
log
files
right
during
that
hackathon.
We
didn't
try
to
do
anything
else.
G
That
was
you
know
more
business
or
you
know
whatever
we
didn't,
we
didn't
edit
ids.
We
didn't
do
anything
else.
We
just
we
just
we
just
it
was
just
a
a
standing,
a
meeting
and-
and
that
was
really
valuable,
but
no
one
other
than
me
had
tried
the
vpn
at
that
point.
So
I
hope
we'll
we'll
get
it
working
in
september.
D
Yeah,
I
shared
a
link
to
the
original
wiki
page
that
we
used
for
for
tracking
tls
implementations
and
chris
and
his
wisdom
has
turned
it
into
a
repo
which
is
not
such
a
terrible
thing.
But
it
also
raises
the
bar
to
come
to
contributions,
which
is
an
interesting
question
to
ask,
is:
is
the
wiki
with
its
ease
of
access
and
lowering
the
bar
as
michael
would
would
have
it?
Is
that
the
the
right
way
to
do
things,
or
you
know,
is
the
just
a
little
little
bit
extra
of
getting
it
into
a
repo.
D
D
G
C
C
Yeah-
and
I
think
it's
also
important
to
note
that
you
know
there
are
examples
on
here
that
do
not
have
repos
behind
them
that
are
accessible,
but
it
is
still
tracking
who
has
done
what,
and
I
think
there
is.
You
know,
meta
value
for
a
working
group
and
knowing
who
has
what
implemented
of
what
status.
D
D
C
Yep,
that's
good
all
right,
so
yeah.
I
think
we'll
we'll
set
aside
some
time
at
a
future
call
we'll
schedule
in
september
or
october.
We
can
have
charles
here
and
talk
a
bit
more
about
this
type
of
stuff
and
then
hopefully,
at
that
point
we
will
also
have
gone
further
on
publishing,
use
it
or
lose
it,
and
we
can
talk
about.
I
guess:
do
we
want
to
talk
about
anything
for
protocol
maintenance?
Was
there
anything
that
needs
to
be
done
there
before,
like
a
shifter?
C
I
I
If
we
actually
make
that
an
official
update
to
8200,
then
perhaps
we
can
actually
make
the
space
in
between
the
ip
header
and
the
l4
header
useful
and
like
put
in
the
mtu
option.
It's
just
basically
like
an
mss
rewriting
scratch
space
option.
Maybe
people
could
use
the
connex
option
so
that
it's
not
just
you
know
one
and
a
half
bits
or
whatever
it
is
remaining
in
dscp,
and
I
mean
martin
is
stifling
a
laugh.
I
I
don't
know,
but,
like
you
know,
whatever
it
is,
and
and
maybe
you
know,
allow
them
to
be
to
be
sent
and
in
various
orders,
so
that
there's
some
some
level
of
like
they
aren't
always
in
the
same
format
or
in
the
same
order
thing.
Then
perhaps
we
could
we
could
get
to
a
place
where
well,
you
know
like
like
it
like
quick
did
where
you
know
it
had
it.
E
J
I
Yeah,
so
actually
I
haven't
read
that
in
in
detail,
but
that
that
very
point
did
come
up,
because
the
current
proposal
for
a
hopper
hop
option
treatment
says
that
reuters
should
only
process.
Routers
are
required
to
only
process.
The
first
topic
hop
option
in
the
chain
which
would
sort
of
like
nullify
any
sort
of
future
usefulness.
Unless
we
made
like
one
mega
hop
by
hop
option
that
had
a
bunch
of
other
and
all.
G
I
I
I
C
D
I
One
of
the
other
things
that
that
might
be
required
for
this
to
be
of
interest,
but
it
could
be
sufficiently
interesting
to
make
it
useful-
and
I
think
yeah
two
minutes
is
that
it
might
be
necessary
to
do
a
a
fragmentation,
v2
header,
where
we
actually
have
in
the
fragment
header,
the
l4
header
or
some
some.
You
know,
per
per
transport
layer,
specifiable
chunk
of
of
bytes,
that
that
might
be
useful,
so
yeah,
obviously,
obviously
pretty
wacky
stuff.
F
C
I
G
G
C
Right
yeah-
and
I
I
wonder
if
you
know
one
of
the
principles
here
is
like
quick's
original
breakage.
Wasn't
that
bad
like
it
didn't,
have
to
fall
back
to
tcp
like
what
it
was.
It
was
maybe
above
10,
initially
or
something,
but
it
was
not
the
majority
of
cases,
and
so
maybe
it's
different
to
say
all
right,
I'm
broken
20
of
the
time
but
80
of
time.
C
G
I
going
to
fix
bugs,
and
the
answer
is
well
the
part.
That's
80
right,
exactly
exactly
okay,
so
then
you're
going
to
rip
out
the
20
when
it's
buggy,
whichever
one
that
is
right,
okay,
that's
too
buggy!
Forget
it
the
other
one's
working
and
that's
where
I
think
we
run
into
problems
right
if
it's
you're
right
anyway,.