►
Description
Evolvability, Deployability, & Maintainability (EDM) Program Meeting, 2022-02-01
A
A
I
think
we
have
several
kind
of
new
faces
here,
probably
from
our
working
group
chairs
list
outreach.
So
thank
you
for
coming
along
all
right.
First,
just
some
updates.
We
published
the
use
it
or
lose
it
draft.
So
that's
now,
rfc
9170,
so
good
job.
Everyone
for
helping
us
review
that
and
get
that
over
the
finish
line.
A
So
we
can
understand
what
the
feedback
was
in
general
and
then
talk
about
some
of
the
next
steps
for
implementation
status,
as
well
as
code
tracking,
some
of
the
stuff
that
charles
eckel
had
brought
up
and
was
also
discussed
on
the
list,
and
then,
after
that,
we
also
want
to
get
back
to
an
item
that
we've
discussed
previously
and
now
that
we've
published
user
lose
it.
A
We
want
to
see
you
know:
do
we
want
to
do
something
with
martin
thompson's
draft
the
ib
protocol
maintenance,
which
is
expired,
but
is
an
adopted
ieb
document
and
seems
like
it
would
be
in
scope
for
this
program.
A
All
right
as
there
any
objections.
Let's
get
started
all
right,
so
we
sent
out
a
survey
on
implementation
status
based
on
our
last
meeting,
to
try
to
understand
kind
of
the
scope
of
things
that
different
working
groups
were
tracking
and
what
they're
interested
in
tracking
to
help
with
protocol
deployment
and
I'm
not
understanding
kind
of
the
health
of
protocol
deployments.
A
This
is
an
example
of
what
went
out.
I'm
sure
a
lot
of
you
on
this
call
took
that
or
took
a
look
at
that
survey.
So
thank
you
for
filling
that
out
for
the
responses
we
got.
38
working
groups
responding
overall,
which
is,
I
think,
pretty
good
and
well
go
through
now,
is
just
a
summary
of
the
results
in
kind
of
graph
forms.
We
can
understand
in
general
what
people
are
saying
and
then
we
can
discuss
what
we
think
kind
of
the
conclusions
are
what
we
should
do
about
it.
A
A
higher
percentage,
eighty-two
percent
we're
interested
in
having
the
implementation
status
of
the
protocols
be
more
discoverable,
and
presumably
that's
for
people
reading
the
specs
or
for
people
working
in
the
working
group.
So
they
can
understand
how
implementations
are
coming
along
and
also
a
very
high
percentage.
87
we're
interested
in
looking
at
how
you
could
track
implementation
status
after
rfcs
are
published,
and
that
also
would
potentially
include
after
working
group
said,
have
closed
or
have
finished
their
work.
A
A
Would
use
working
group
presentations
to
keep
updated
on
status,
61
track
something
in
a
github,
repo
somewhere
and
then
30
percent
were
other
and
then
looking
at
the
other.
Some
of
that
was
just
mailing
list.
One
group
mentioned
the
european
advanced
networking
test
center
people
mentioned
the
implementation
status
section
on
internet
drafts,
shepard
write-ups.
That
would
be
added
before
going
up
to
the
isg
and
then
bakeathons.
A
And
then,
as
far
as
tracking
implementation
status,
42
percent
of
the
groups
said
that
they
use
the
internet
draft
section
on
implementation
status
in
some
form.
Relatively
few
11
use
the
ietf
track.
Wiki
same
percent
use
a
github
wiki
16
are
using
hackathon
wiki
13
using
github
pages,
so
there's
a
big
diversity
of
little
things
here
there
that
doesn't
seem
to
be
any
consistent
trend
and
we
didn't
include
a
nun
option
so
pretty
much
everything
else.
55
was
people
saying
other,
but
writing
in
none
with
one
person.
A
Also
writing
in
that
they
use
google
sheets.
So
that
is
the
output
of
that
survey.
I
guess
let's
pause
here
before
we
go
into
kind
of
other
topics,
for
what
we
do
with
this
I
see
myria
was
saying
bakeathon.
I
think
a
bakeathon
was
just
how
someone
termed
they
were
doing
for
interop
code
testing,
I'm
not
sure
exactly
what
it
refers
to
all
right,
paul,
raise
your
hand
and
people
you
can
feel
free
to
just
chime
in
too.
I
think
we're
a
small.
I
will.
B
Chime
and
not
hand,
I
was
since
I'm
no
longer
blue
dotted.
I
was
I
didn't
see
the
survey
was
there
any
question
or
any
suggestion
of
would
peop
would
work
working
group
chairs
who
were
answering
the
survey
like
to
see
the
implementation
status
across
the
ietf
collected
somewhere
and
if
so,
what
were
their
answers?.
A
We
did
not
have
a
question
on
that
specifically,
although
I
think
that
kind
of,
if
anything,
falls
into
the
you
know,
is
there
a
more
discoverable
way
to
see
implementation
status
like?
Is
there
a
way
on
diff
track
to
see
like
how
are
things
being
implemented?
And
maybe
that
is
a
thing.
That's
visible
more
across
the.
B
Itf,
I
think
that
would
be
useful
right
and-
and
my
question
comes
because
I
know
some
working
groups
there.
You
know
once
you're
in
the
working
group
you
hear
about
the
st
the
implementation
status
tracker,
but
if
you're
outside
the
working
group,
you
wouldn't
have
any
idea,
because
it's
a
working
group
function
and
it's
something
that
you
would
only
find
out
if
you
were
on
the
mailing
list.
As
a
very
concrete
example
of
this
in
the
dns
world,
we
have
at
times
started
and
and
not
started
conformance.
B
C
B
A
To
to
what
degree
do
you
think,
because
yeah
we
could
always
have
some
cross
idf
or
iep
statement
on
hey
these
things
are
happening,
but
I
think
you
know
part
of
the
thought
and
what
we
were
talking
about
last
time
was,
you
know?
Maybe
it's
is
it
in
data
tracker
as
an
associated
metadata?
A
Is
it
associated
metadata
with
a
draft
or
an
rfc
of
like
here's,
the
way
to
just
link
over
to
the
page
where
you
track
this,
and
that
way
it's
a
blank
that
people
can
understand
can
be
filled
in
and
even
if
you're
looking
at
a
working
group
or
a
document
you're
not
familiar
with
you
can
see.
This
is
how
these
people
track
this,
or
this
is
how
they
do
conformance
testing.
B
I
don't
know
if
that
was
aimed
at
me
specifically.
I
would
love
to
hear
from
other
people
to
in
my
mind,
if
this
questionnaire
mostly
went
to
work
in
group
chairs,
then
we're
mostly
talking
about
working
groups
or
individual
drafts
within
working
groups
being
tracked,
and
so
it
would
be
something
that
would
maybe
come
from
the
isg.
It
might
be
just
an
annual
blog
post.
A
D
Chime
in,
if
you
don't
mind
to
me
this
is
quite
cool,
but
I
think
we
need
to
read
to
target
some
very
specific
protocol
there.
For
instance,
if
we
want
to
track
the
implementation
of
raci
200
a
ipv6,
we
will
end
up
with
a
way
to
long
list.
It's
useless,
so
we
may
want
to
track
very
specific
newcomers
or
whatever
I
don't
know,
and
performance
testing
is
a
vastly
different
world.
I
will
not
touch
it
with
a
poll,
but
yeah,
that's
fair!
D
That's
something
needs
to
be
done.
That's
for
sure.
E
A
C
Paul
one
additional
issue
is
also
that
there's
a
good
reason
that
we've
removed
the
implementation
status
section
before
publication,
because
otherwise
it
becomes
like
an
advertisement
clause
right.
F
So
you
know
one
thing
I
wanted
to
bring
up
is
I
I
think
they're
sort
of
two
different
targets
for
this.
The
one
that
we're
talking
about
maybe
a
little
bit
more
is
the
during
the
development
of
a
protocol
tracking.
What's
going
on
having
that
feedback
into
this
fact,
as
it's
actively
being
developed
by
the
working
group,
that's
that's
really
important
to
do
and-
and
I
you
know
I'd
like
to
see
us-
improve
mechanisms
for
doing
that
and
are
kind
of
get
a
bit
more
consistent
in
how
we
do
that.
C
F
Really
important
to
be
able
to
track
after
the
fact
and
to
continue
to
have
that
information
after
an
rfc
is
published
and
really
for
people
who
are
not
in
the
working
group
for
just
people
who
want
to
implement
it
so
that
they
can
see
here.
You
know
here's
some
code
that
is
related
to
what's
been
going
on
with
this
this
rfc.
F
Test
tool
that
helps
me
work
with
it.
Maybe
it's
a
plug-in,
for
you
know
something
I
can
use
to
sniff
the
traffic
on
the
wire
and
debug
it
better.
F
G
So,
what's
the
life
cycle
of
the
kind
of
thing
that
you
were
talking
about
just
then,
so
I
I
can
see
having
this
collection
of
resources
easy
to
find
being
useful
early
in
the
development
of
a
of
a
document
and
of
a
protocol.
But,
as
some
folks
have
pointed
out
in
the
chat,
the
lists
of
resources
like
that
tend
to
either
become
popularity
contests
or
or
deadline
graveyards
within
a
few
years.
G
So
understanding
you
know,
martin
asked
in
the
in
the
chat
who
is
the
tracking
for
so
one
of
the
audiences
that
that
you
were
pointing
out.
Charles
is
implementers
that
are
early
on
the
implementation
curve
and
I'd
like
to
refine
that
as
to
when
the
implementation,
when,
when
the
world's
implementation
curve
is
at
the
beginning
or
if
it's
something
that
you
think
should
live
on
into,
you
know
the
future
decades
to
help
new
implementers
of
old
protocols.
F
Yeah,
I
was
thinking
more,
the
latter
that
it
should
it
should
live
on
and
there
wouldn't
be
as
many
updates
to
it.
At
that
point
and
sure
some
information
might
get
a
bit
stale
if
no
one's
actively
maintaining
that
page,
but
the
thought
being
that
it
at
least
provides
a
jumping
off
point
to
get
to
say
various
an
example.
F
It
takes
you
to
a
github
repo,
and
once
you
go
to
that
github
repo,
you
may
find
that
that
the
code
that
it
was
pointing
you
to
is
no
longer
really
actively
being
maintained,
or
perhaps
you
find
that
it
is
so.
I
still
think
having
that
link
is,
is
useful
and
does
more
benefit
than
harm
having
it
there.
So
when
it's
earlier
on
in
the
cycle,
this
information
would
be
fresher
and
probably
the
people
working
on
the
working
group
chairs
many
people
would
be
looking
at
it
and
keeping
it
as
up-to-date
as
possible.
H
To
be
honest,
charles.
A
H
Done
a
better
job
than
I
did,
you
know
the
availability
of
on
the
wire
track.
You
know
plugins
and
debugging
tools
and
things
to
test
against.
You
know
if
you're
writing,
client,
you
want
a
server
to
test
with,
maybe
with
some
test
accounts,
or
at
least
you
know,
person
to
contact
to
talk.
You
know
to
get
one
this
sort
of
thing
and
I
still
yeah.
C
B
Having
run
a
conf,
a
sort
of
well-known
conformance
test
suite
for
a
while
when
the
vpn
consortium
was
active,
I
can
absolutely
speak
to
the
fact
that
it
is
an
advertising
mechanism
and
that's
a
good
thing
that
is,
after
you
have
the
three
biggest
players
who
obviously
are
supposed
to
conform
or
interoperate,
with
each
other
having
having
something
that
gets
smaller
companies
wanting
to
be
involved
and
finding
conformance
issues,
or
at
least
having
them
know.
If
you
want
to
be
on
this
chart,
you're
going
to
get
red
marks
unless
you
do.
G
So
tommy,
I
heard
in
your
early
discussion
a
question
about
whether
or
not
there
needed
to
be
any
normalization
of
how
different
groups
capture
this
information
or
at
least
capture
pointers
to
this
information
right.
G
So
you
know
we,
the
tools.
We've
got
available
right
now.
You
can
put
arbitrary
links
from
a
documents
page
or
from
a
group's
page
using
the
additional
resources
capabilities
for
the
data
tracker
to
point
to
whatever
content
you
have.
Our
story
on
wikis
is
weak
right
now,
we've
still
got
wiki
js,
that's
coming
available.
That
working
groups
could
put
things
on
wikis
and
there
are
lots
of
groups
that
are
putting
things
on
github.
G
I
know
that
in
the
past
there
was
conversations
about
actually
having
a
a
very
purposed
tool
that
looked
more
like
a
marketplace.
That
was
this.
The.
G
The
code
something
yes,
I
had
the
exact
same
stumble
as
I
got
code
and
didn't
didn't
get
further,
but,
yes,
you
know,
do
we
do
we
need
something
code
match
yeah?
Do
we
need
something
that
is
that
purposed
or
do
we
just
need?
Are
people?
G
Would
we
do
better
if
we
than
we
are
from
zero?
If
we
just
started
working
with
consistently
getting
pointers
from
pages
in
the
data
tracker
or
pointers
from
inside
the
document
to
the
larger
collection
of
things
that
are
out
there.
A
Right-
and
I
think
you
know,
based
on
the
discussion
that
we
saw
on
the
chairs
list-
saying
oh
yeah-
I
could
match
this
thing
and
trying
to
build
this
whole
app
and
trying
to
import.
It
was
like
it,
you
know
it
fizzled
out.
I
don't
think
that's
a
successful
direction
to
go
in
and
we
did
capture
the
program
github
issue
around
this
and
the
discussion
there
was
also
you
know,
saying
it's
probably
yeah
more
important
to
have
a
standard
pointer
that
people
can
know.
A
Yeah
and
I
think
the
stuff
in
the
chat
is
kind
of
going
along
that
direction.
Andrew
I
saw
you
had
a
question
around
this
topic
of
having
a
different
tracking
options.
I
I
suppose
tell
me,
I
was
just
thought
it
was
worth
asking
the
question
because
I
know
there's
a
predisposition
within
the
ihf
that
you
know
why
have
one
tool
when
20
are
available.
So
I
thought
I
would
just
gently
ask
the
question
whether
there
will
be
any
merit
in
in
suggesting
at
least
a
reduced
set,
whether
that
will
give
a
any
advantage
but
slightly
tongue
issue.
I
guess
in
a
way,
but
sometimes
choice
isn't
always
helpful.
I
A
Yep,
okay,
so
I
I
think
the
concrete
thing
here
seems
to
be
like
yeah.
Let's
have
you
know
some
url
that
we
can
point
to
so
concretely,
you
know
robert,
you
were
mentioning,
you
know
we
can
do
additional
resources
in
the
data
tracker
page.
A
G
Thinking
you
could
use
the
exist
any
of
the
existing
tabs.
Now
you
know
there's
there
there's
our
are
generic
tags
for
additional
information.
You
know
website
kind
of
tags,
but
if
you
wanted,
if
you
wanted
a
specific
tag
for
implementation,
tracking,
adding
that
tag
would
not
be
a
difficult
thing
to
do.
Okay,.
A
Does
that
only
show
up
on
the
data
tracker
page,
because
I
think
there's
also
been
discussion
of
you
know
in
some
of
the
rendered.
G
A
A
G
You
know
what
are
the
pressures
right?
The
rsc
editor
is
wrapping
the
rendered
html
with
at
least
javascript
that
adds
additional
addressing
and
we
could
provide
a
view
that
did
the
same
thing.
E
Yes,
thank
you.
I
was
wondering
if
it
it
would
make
sense
to
have
a
tab
actually
in
the
working
group
data
tracker
page,
we
have
about
documents,
meetings,
history,
this
stuff
and
what?
If
we
have
an
additional
tab
that
says
implementation,
and
then
you
can
somehow
put
whatever
you
want
there
either
you
go.
You
link
to
something
else.
E
The
working
group
is
using
or
you
you,
you
just
have
a
template
that
allows
you
to
put
information
that
is
needed
that
not
only
the
chairs
can
update,
maybe
also
the
various
contributors
that
would
help
and
in
in
in
keeping
it
up
to
date.
Up
to
some
point,
at
least
until
the
working
group
is
is
closed.
I
would
say
now.
The
question
would
be
what
kind
of
format
that
that
page
should
have
but
yeah,
but
we
can
also
think
something
along
these
lines.
E
Yeah,
I
agree
that
we
need
a
normalized
form.
It's
just
that
a
benefit
that
can
can
be
done
later.
I'm
not
saying
this
is
the
starting
point,
but
if
there
is
a
tool
directly
in
the
data
tracker,
maybe
it
will
be
used
not
only
by
the
the
38
shares
that
answer
to
the
survey
that
are
interested
in
it,
but
maybe
slowly
slowly.
E
A
A
Regarding
people
other
than
chairs
being
able
to
do
things,
you
know,
obviously
I
think
only
the
chairs
would
be
able
to
edit
the
additional
resource
links
on
a
working
group
page,
but
at
least
for
an
individual
draft
authors
should
be
able
to
change
that
for
their
own
documents,
and
I
guess
what's
what's
the
status
if
it's
an
adopted
working
group
document,
can
the
chairs
are
the
chairs,
the
only
ones
who
can
modify
that
that's
correct
yeah,
but
I
think
that's
appropriate
at
this
point,
so
that
seems
like
a
good
boundary.
F
To
have
well,
one
question
I
had
is
how
much
of
the
the
information
we'd
want
to
track
would
be
per
working
group
versus
per
per
draft
or
per
rfc,
because
it
seems
like
we
have
cases
of
both,
and
I
heard
some
people
talk
about
having
something
on
the
working
group
page,
but
in
some
cases
I
imagine
different
drafts
could
have
very
different
sets
of
implementation
resources
associated
with
them,
and
certainly
once
they
become
rfc
right.
It'd
be
separate.
A
If
you
have
a
working
group
approach
that
does
everything
then
put
out
your
working
group
level
probably
also
copy
that
onto
the
individual
documents
that
you
have
adopted
that
are
relevant
if
they
are
separate
for
a
document
have
a
separate
link
per
document,
and
maybe
the
working
group
has
like
their
top
level
wiki
that
links
you
to
all
the
document,
implementation,
statuses
or
tests.
They're
doing
it
seems,
like
you
know,
it's
just
having
the
tag
would
be
useful
for
all
of
those
different
cases.
A
D
And
the
other
point
is:
when
do
we
remove
this
information
right
to
come
back
to
the
vpn
consortium
from
paul
15
or
20
years
ago?
I
guess
the
information
has
disappeared
right.
It's
not
more,
very
useful.
A
Everything
can
be
solved
by
the
way
right.
You
to
some
degree
may
be
a
feature.
Not
a
bug
at
this
point
to
you
know
not
have
links
actively
maintained
for
published
documents
or
closed
working
groups.
Since
that's
a
sticky
area
of
like
we
know
it's
going
to
get
stale,
I
guess
to
be
good
to
confirm
robert.
So
when
you
have
metadata
tags
on
a
working
group
and
the
working
group
closes,
I
assume
those
just
stay.
G
They
continue
to
exist.
Permissions
tend
to
fall
back
to
the
isg
and
the
secretariat
if
they
were
iatf
working
groups
and
if
their
research
groups,
the
irsg
and
the
secretariat,
that
that
kind
of
fall
back
up
leadership
chains,
yep.
A
Well,
that
makes
sense
yep.
I
think
this
is
kind
of
the
appropriate
thing
to
do
for
now.
So
I
guess
what
I
would
propose
coming
out
of
this
is
we
can
bike
shed
names
for
a
tag,
talk
about,
maybe
some
candidate
groups
that
are
doing
this
type
of
stuff?
A
That
want
to
add
it
in
add
that
in
you
know,
potentially
charles
also,
you
know,
along
with
hackathon
work,
as
you
have
people
to
participate
in,
that
make
that
known
as
an
option
kind
of
on
board
people
to
that
and
see
how
that
can
become
useful
for
people.
B
I'd
like
to
toss
one
small
suggestion
in
with
what
you
just
said,
tommy,
which
is
that
the
iesg
itself
can
also
create
these
specifically
in
the
dns
world.
Dns
op
has
become
a
default
working
group,
but
lots
of
dnse
things
for
which
this
kind
of
implementation
things
would
be
appropriate,
are
not
part
of
dns
op
at
all.
So
but
but
some
aed
could
say,
oh
look.
Here's
here
is
a
group
of
people
who
are
itf
regulars
who
seem
to
be
doing
this.
Yes,
this
should
exist
as
well.
A
B
Well,
but
to
be
more
specific,
no
one
is
actually
looking
at
rfc
1034
1035,
which
are
dns
sure,
but
a
conformance
you
know,
or
an
implementation,
especially
on
types
that
are
no
longer
used.
This
comes
up,
sometimes
individuals
do
it
and
it
would
just
be
nice
if
an
ad
can
say
look.
Some
individuals
over
here
are
keeping
this
useful
list.
A
All
right,
I
think
you
know
looking
at
the
slides
that
I
had
after
this.
We
already
had
some
issues
for
the
program
covering
this,
but
I
think
we
talked
through
pretty
much
everything.
I
think
we
have
a
pretty
good
next
step,
the
one
other
bit.
A
Let
me
share
the
slides
again
here
was
originally
before
we
got
into
the
implementation
status.
Half
of
it.
We
did
have
charles
your
draft
on
finding
code,
and
I
I
just
noted
you
know
we
did
have
the
working
group
discussion.
The
working
group
chairs
list
discussion
around
kind
of
the
previous
failed
attempt
of
this
code
match
thing
charles.
What
are
you
thinking
around
the
kind
of
like
the
code
aspect,
which
is
a
little
bit
different
than
just
interop
and
implementation
status?
F
Yeah,
I
guess
in
my
draft
I
was
thinking
of
things
like
I
mentioned.
You
know,
tools
other
things
that
would
just
help
someone
who
is
implementing,
maintaining
debugging
doing
anything
to
do
with
with
that
really
a
protocol
that
the
itf
would
standardize.
So
it
would
be.
I
was
thinking
I
would
you
know,
abuse
this
tag,
if
that's,
if
it's
an
abuse
but
I'd
use
it
for
it'd
use
the
same
tag
to
for
like
really
any
code
that
is
useful
and
related
to
the
the
draft
or
rfc.
A
I
think
that
makes
sense
it's
making
like
a
bunch
of
tags
or
something
like
that
right,
like
essentially
have
you
know,
we'll
need
to
bike
shed
name
and
brainstorm
that,
but
if
the
core
of
this
is
you
know,
this
is
your
implementation
info.
You
know
that
can
be
just
your
status.
That
can
be
your
conformance
testing
results.
That
can
be
other
guides
like
what
you're
saying
of
hey.
If
you're
writing
this
protocol,
here's
some
useful
resources.
F
Yeah-
and
I
think
it
also
points
to
they'll-
obviously
have
to
be
more
information,
but
at
least
you
you
need
a
jumping.
You
need
something
to
get
you
to
where
the
information
is
and
then
it'd
be
up
to
the
people.
You
know
writing
the
tool
to
make
it
clear.
Well,
this
is
a
tool.
That's
meant
to
help
you
with
this,
and
you
know
we
just
developed
it
yesterday
or
it's
been
used
quite
a
lot
and
found
to
be
completely.
F
A
Okay,
very
good,
I
think
if,
if,
unless
anyone
has
anything
else,
I
want
to
move
on
to
our
second
topic
talking
about
protocol
maintenance
draft.
Well,
just
one
thing
I
was
wondering
is:
is
it
are
we
going
to
try
to.
F
Do
some
sort
of
you
know
implement
something
along
this
or
some
type
of
experiment
for
in
time
for
the
next
ietf
meeting?
I
think
so,
if
there's
like
a
few
working
groups
that
want
to
make
use
of
it,
and
then
we
can
make
sure
that
it's,
you
know
useful
for
a
hackathon
project
related
to
those
working
groups
might
just
be
a
good
way
to
test
it
out
and
see
how
it
goes.
A
A
We
can
talk
about
what
the
tag
should
be,
what
the
name
is
and
then
I
assume
robert.
We
just
talked
to
you
about
getting
that
added
to
the
list,
and
then
we
talked
to
you,
charles
about
telling
people
in
the
hackathon
to
do
it.
You
reach
back
out
to
the
working
group
chairs
list
and
say
hey
if
you
were
interested
in
this
in
the
survey.
A
A
C
A
Okay,
moving
on
the
other
thing
we
wanted
to
bring
up
on
the
maintenance
side
and
getting
more
into
documents.
A
Is
this
document
that
we
have
that's
expired
draft
iab
protocol
maintenance,
the
harmful
consequences
of
the
robustness
principle?
It's
adopted,
as
I
mentioned
before,
it's
expired.
It
only
expired
a
few
weeks
ago,
yes,
martin,
but
it's
yeah
good
good
reason
to
look
at
it
again,
and
this
definitely
is
in
scope
for
a
iab
program
that
has
maintenance
in
the
name.
J
That
working
out
yep
headphones.
So
this
is
probably
one
of
the
more
controversial
things
that
I've
written.
It's
changed
a
lot
since
early
versions.
J
J
I
don't
know
what
we
might
do
here
to
sort
of
balance.
The
two
competing
concerns.
That's
really
what
I'm
looking
for
input
on
here.
A
Yeah
yeah,
I
I
think
that
makes
sense,
yeah
and
so
the
questions
I
had
on
this
for
this
program
was,
you
know,
do
we
agree
or
not?
A
I
think,
as
a
community
as
people
working
the
itf,
that
you
know
something
should
be
said
here,
should
we
take
it
on
this
group
to
try
to
refine
balance
the
document
or
define
the
scope
of
it?
So
people
are
comfortable
with
how
it's
applying
and
I'd
love
to
hear
people
have
suggestions
for
how
it
can
be
changed
or
updated,
or
if
people
do
agree
or
disagree.
G
Martin
was
pushing
that
discussion
in
the
program
about
not
necessarily
publishing
the
draft
or
or
just
trying
to
understand
where
that,
where
the
the
the
concepts
in
the
draft
make
sense
to
apply
versus
other
things
would
would.
G
If
that
discussion
bore
any
fruit
it
would,
it
would
be
a
very,
very
valuable
thing
to
have,
and
a
program
like
this
is
more
likely
to
to
provide
a
good
focus
to
to
bring
that
discussion
to
a
useful
conclusion
than
just
leaving
it
out
for
general
discussion
in
the
community
yeah.
So
I
I
actually
would
like
the
the
program
to
have
some
focused
discussion
around
what
what
the
draft
is
saying
and
and
where
the
philosophy
than
in
it
really
applies.
G
G
Are
implementation
communities
that
have
a
small
number
of
big
players
or
versus
a
a
very
large
number
of
very
small
players,
or
if
we
could
even
gather
that
kind
of
information
to
see
if
the
attitudes
change
depending
on
what
the
ecosystem
for
the
protocols
that
are
being
worked
on,
looks
like.
A
D
That's
good
and
pretty
similar
to
what
roberts
said.
Never
not
the
draft
right,
so
I
agree
somehow
with
the
principle,
but
not
for
all
cases.
Right.
That's
for
sure.
If
you
are
developing
a
browser
on
a
well-known
platform
you
can
update
now,
if
you
are
developing
something
from
an
iot
device
that
stays
there
for
15
years
old.
Obviously
you
cannot
right.
You
need
to
rely
on
their
business.
So
again
I've
enrolled
the
draft
yeah
if
you
are
saying
in
the
atf,
but
is
it
about
providing
consideration
the
pros
and
the
cons?
A
I
mean
not
not
to
put
words
in
martin's
mouth,
but
I
think
the
way
at
least
the
drafting
originally
came
out.
It
seemed
to
be
you
know
you.
We
have
this
institutional
principle
of
the
robustness
principle
that
we're
all
used
to,
and
then
you
know
kind
of
to
challenge
that
there's
a
statement
of
like
you
know
you
just
someone
wants
to
come
and
say
no,
that's
wrong
this.
A
You
know
particularly
for
what
you're
bringing
up
here
like
these
cases
where
you
can
update
and
you
are
maintaining
it
that
doesn't
make
sense
and
it's
actually
harmful
and
probably
where
we
need
to
end
up
through.
Is
you
know
let
let
those
two
things
bump
around
in
the
the
polishing
chamber
for
the
rocks
and
like
see
what
comes
out
the
other
side
of
where?
Where
do
you
draw
that
line,
because
I
think
we
can
easily
point
to
extremes
on
both
sides
where
one
approach
is
fine?
The
other
approach
is
much
more
correct.
J
I
was
going
to
say:
karsten
raised
an
interesting
point
about
the
the
difference
between
the
need
for
for
the
ability
to
update
things
and
the
facts
on
the
ground,
which
is
that
in
in
the
iot
world.
J
It
has
been
the
case
and
probably
will
continue
to
be
the
case
that
a
lot
of
devices
don't
get
updates
and
a
large
component
of
this
is
sort
of
based
on
the
the
understanding
that,
in
order
to
deploy
to
the
internet,
you
should
really
have
an
update
process,
and
you
know
we've
had
a
number
of
working
groups
that
have
explored
the
problem.
J
The
area
that
I
find
a
little
more
interesting
is
those
settings
where
the
the
pace
of
deployment
is
historically
relatively
slow.
It's
not
that
there's
no
active
maintenance
involved
is
that
the
pace
of
deployment
tends
to
to
be
somewhat
more
measured,
and
you
think
about
people
deploying
to
routers
and
things
like
that.
J
They
tend
to
be
very
conservative
in
in
the
way
that
they
do
software
rollouts
because
of
the
size
of
the
impact,
if
a
mistake
occurs.
So
those
are
the
sorts
of
things
that
I'd
like
to
talk
about.
To
some
extent.
I
want
to
sort
of
rule
the
iot
thing
like
in
the
just
completely
out
of
scope
in
a
sense,
because,
if
someone's
unwilling
to
update
their
software,
then
maybe
we
need
to,
we
need
to
talk
about
whether
they
get
to
continue
to
participate.
A
One
question
I
have
out
of
this
and
I
think
it
goes
to
robert's
comment
on
chat
about
what
would
happen
if
people
were
just
strict.
It
seems
to
me
that
one
of
the
reasons
you
would
be
liberal
and
what
you
accept
is
that
you
want
to
deal
with
future
changes
to
the
protocol
that
you
may
not
predict
that
otherwise
could
end
up
breaking
you.
But
when
we
combine
this
with
some
of
the
work
we
were
doing
in
user,
lucid
of
talking
more
concretely
about.
A
Greasing
or
making
sure
that
your
extension
points
are
usable,
I
guess
to
people
who
are
doing
more
iot
work.
If
I
have
an
iot
device,
that's
never
going
to
be
updated.
A
Future
things
that
essentially
say
no
be
be
conservative
when
it
expects,
and
just
understand
that
that
will
never
change
is
that
okay.
J
Yeah
this
does
with
the
user.
Loser
basically
said
it,
you,
you
define
very
clearly
what
the
expectations
are
with
respect
to
extensibility
and
if
you,
if
your
design
space,
says
we're
not
going
to
accept
any
more
features
on
this
protocol,
that's
a
perfectly
acceptable
thing
to
do
in
the
same
way
that
that
html
is
deliberately
tolerant
of
of
user
input
errors,
and
it
is
almost
aggressive,
like
some
people
will
characterize
that
as
almost
aggressively
an
application
of
the
robustness
principle.
J
That
is,
it
is
not,
in
fact,
and
the
and
the
draft
talks
about
this.
It
is,
in
fact,
a
very
precise
specification
now
and
that
that
specification
has
a
purpose
on
the
opposite
end
of
the
scale.
The
iot
device
that
doesn't
expect
to
operate
for
expects
to
operate
for
the
next
15
years
without
software
updates
might
want
a
very
much
more
narrowly
defined
protocol
with
no
extensibility.
J
K
And
I
wanted
to
say
that
I
think
this
draft
is
about
protocol
maintenance
and
not
necessarily
software
updates
right
and
software
maintenance,
and
I
think
there
is
some
very
useful
advice
here
and
in
line
with
what
we
both
just
said.
I
believe
that
we
should
be
more
explicit
but
explicit
about
like
how
our
maintenance
look
like.
How
often
do
we
want
to
revise
versions?
How
static
is
a
protocol?
K
K
We
should
bring
the
message
hours
that
we
we
want
to
be
more
active
and
and
people
should
expect
to
see
more
versions
of
all
kind
of
protocols
and
and
need
to
figure
out
what
to
do
if
a
new
version
comes
up
and
so
on,
and
I
think
this
is
only
partly
related
to
robustness
principle.
A
J
Let
me
try
this
again.
I
think
that
probably
the
the
the
core
realization
that
I
had
walking
through
this
was
that
the
two
go
hand
in
hand,
and
if
you,
if
you
expect
one
to
evolve,
then
then
the
other
has
to
has
to
evolve
with
it.
J
That's
one
of
the
things
that
we
saw
with
tcp,
I
think,
was
that,
because
nothing
was
happening
in
the
in
the
implementation
land,
nothing
would
happen
in
the
specification
land
and
and
it
sort
of
kept
itself
in
a
very
nice
stagnant
state.
For
I
don't
know
what
is
it
30
years
and
so
slow
pace
there
meant
slow
pace
on
both
ends.
That's
okay!
K
B
Probably
try
to
revise
that
so
two
things
one
is
dns
has
had
exactly
the
same
problem.
Tcp
has
and
has
had
the
exact
same
thing
of
we.
Don't
we
have
an
extension
mechanism.
Let's,
let's
do
everything
in
there.
Let's
not
actually
work
on
the
base
protocol,
even
though
we
know
there
are
are
a
couple
of
important
places
where
it
really
could
be
fixed
easily
with
a
new
version
that
people
agree
to,
but
martin
going
to
your
your
last
statement
about-
maybe
it's
not
maybe
you're,
not
reflecting
it
really
well
in
the
current
draft.
B
I
unfortunately
would
agree
with
you
there,
because
I
really
liked
where
the
draft
started
a
few
years
ago
and
now
like
what
I
think,
the
part
that
miria
was
just
speaking
to
of
more
protocol
development
happening,
you
know
or
re
redevelopment
happening
is
important-
is
now
sort
of
lost
all
the
way.
In
section
five,
I
would
love
to
see
that
bubble
up
closer
to
the
top.
J
That's
good
input
I'll
I'll,
take
another
look
at
it
and
with
that,
with
that
feedback
in
mind,
if
anyone
is
able
to
help
me,
that
would
be
great.
A
I
think
over
chad
I
was
trying
to
david
and
I
think
david
was
willing
to
help
out.
L
A
All
right,
I'm
conscious
of
the
time
we
have
three
minutes
left
until
the
hour
and
I
have
a
http
meeting
coming
up
so
if
anyone's
coming
over,
there
feel
free
to
join
us
there
yeah.
So
I
think
we'll
wrap
up
here
unless
anyone
has
any
burning
comments.
Thank
you
so
much
for
joining.
I
think
we
made
some
good
progress
and
we
will
chat
more
on
the
list
and
robert
will
get
back
to
you
with
the
tag
sometime
soon.