►
Description
Evolvability, Deployability, & Maintainability (EDM) Program Meeting, 2020-09-01
A
A
Here
we
have
the
question
kind
of
like
what
extension
mechanisms
are
successful.
How
do
we
do
that?
I
believe
martin
thompson
you're
on
the
call.
One
of
the
questions
I
had
is
you
know
there's
this
document
that
was
started
by,
as
you
were
working
on
as
part
of
the
iab
on
kind
of
the
analyzing
this.
How
do
we
do
protocol
extension
mechanisms
and
there's
a
set
of
recommendations
here
in
design
principles,
and
I
think
this
is
a
really
good
set
to
start
with
and
in
general.
A
I
think
this
document
is
a
really
useful
thing,
so
I'd
love
to
hear
from
you
kind
of
what
we
think
we
can
do
with
this
document.
What
are
the
things
that
maybe
we
could
add
to
it
or
anything-
that's
changed
in
the
year
since
this
has
been
updated.
B
Not
a
lot
the
well
in
terms
of
the
document,
at
least
the
the
list
that
I
have
there
is
complete,
as
I
was
aware
of
at
the
time,
but
since
then
I've
thought
more
about
the
the
involvement
of
extra
parties
in
in
protocols
and
that
the
effect
that
has
on
ossification
I've
written
something
else
on
that
subject.
That
might
be
interesting
as
well.
B
A
Yep
yep,
that
makes
sense,
so
I
guess,
would
you
be
amenable
to
kind
of
us
adopting
just
to
kind
of
get
it
discussed
and
moving
forward
within
this
list
instead
of
people.
B
A
One
of
the
things
I
know
it's
just
like
in
here
for
active
use.
You
know
we
talk
about
that.
What
is
not
discussed
and
I'm
not
sure
if
it's
appropriate
for
this
document
or
something
else,
is
how
do
we
kind
of?
How
do
we
actually
make
active
use
happen
in
the
way
that
we
design
our
extension
mechanisms,
because
I've
seen
you
know
different
ways
of
how
you
set
up
your
iana
considerations
for
your
particular
code.
Points
that
make
it
hard
to
do
active
use
or
make
it
easy
to
do
active
use.
B
And
one
of
the
things
I've
seen-
and
this
may
be
just
my
own
perceptions-
is
that
there's
there's
a
lot
of
protocols
out
there
that
have
mechanisms
that
people
care
about
and
they
care
about
them
for
a
variety
of
different
reasons,
but
they
they
they
care
about
that
mechanism
and
that's
the
mechanism
that
continues
to
work
under
a
variety
of
constraints
and
conditions,
and
so
one
of
the
intuitions
that
was
part
of
adam
langley's
original
greasing
document
was
very
few
extension
points,
and
that's
not
something
that
I
think
people
have
really
taken
to
heart.
B
If
you,
if
you
look
at
the
way
that
you
can
extend
different
protocols,
there's
often
every
single
possible
option
under
the
sun
is
is
presented,
and
that
means
that
then
you
have
five
or
six
different
iona
registries,
with
different
trade-offs
with
different
mechanisms.
You
choose
this
one.
If
you
want
to
do
this
and
you
choose
this
one,
if
you
want
to
do
that
and
that
hasn't,
I
don't
think
worked
out
that
well.
A
A
Yeah,
I've
noticed
much
the
same
thing
that
you
know.
We
have
lots
of
extension
points.
Sometimes
I
think
people
add
them
because,
especially
like
let's
say
you
have
like
a
flags
field
and
some
fixed-length
thing
you
don't
want
to
take
up
the
whole
thing.
You
don't
need
to
take
up
the
whole
thing
for
your
initial
version,
and
so
you
have
points
that
you
don't
even
know
how
you're
going
to
use
and
they're
hard
to
extend,
but
other
times
it
just
seems
like
over
over
design,
and
we
have
too
many
degrees
of
freedom
and.
A
D
Well,
so
how
do
you
like
the
the
I
see
section,
four,
two
and
four
three
here
is
like
how
you
simulate
active
use.
How
do
you
create
an
invariant
without
actively
using
it
right
like
so?
An
invariant
is
essentially
a
specification
level
contract
with
future
developers
of
implementations
of
the
protocol,
or
you
know,
implementations
of
part
of
the
protocol
in
the
in
the
sense
of
intermediaries
or
so
and
like
one
of
the
one
of
the
things
I
really
like
about
this
document.
Is
you
know
it's
active
is
0.4.1
right?
D
It's
if
you,
if
you
want
to
have
an
extension
mechanism
that
works,
you
should
have
an
extension
mechanism
that
works.
It's
almost
a
tourism,
but
it's
one
that,
like
at
least
in
in
sort
of
earlier
protocol
design
has
been.
You
know
a
matter
of
faith
that
you
create
an
extension
point
and
then,
as
an
extension
point
and
and
really
the
rest
of
the
points
here
are
about.
D
B
I
tend
to
think
of
the
cryptography
one
as
as
narrowing
who
you're
exposed
to
more
than
the
the
sort
of
randomization
stuff
that
we're
talking
about
about
the
contexts.
But.
A
A
So
I
guess
to
the
larger
group
kind
of
in
in
this
context,
I'd
ask
if
anyone
else
kind
of
has
examples
that
they'd
like
to
bring
up
of
kind
of
within
their
working
groups
within
the
protocols
that
they've
worked
on,
what
extension
mechanisms
do
you
have
that
work
like
and
does
that?
Does
it
seem
to
ring?
True
with
you
know
it
is
the
active
use
that
works
well,
what
are
the
properties
of
how
you
actually
deal
with
those
extension
points
and
what
are
examples
of
things
that.
D
C
D
F
A
F
So
even
though
the
extension
fields
are
sometimes
used
now
we're
deploying
something
that
actually
is
going
to
really
use
them
at
scale
and
we're
finding
all
sorts
of
network
problems.
This
is
just
terrible
it.
It's
really
really
awful,
and
on
top
of
that,
we
kept
the
format
of
the
header
the
same
for
three
versions.
F
So
there
are
devices
out
there
that
will
send
a
packet
with
a
single
set
bit
and
expect
an
ntp
response
and
as
far
as
we
can
tell
they're
perfectly
happy
to
not
understand
any
of
it
and
just
grab
the
grab
parts
of
the
response,
so
we'll
come
up
with
version
five.
This
is
going
to
be
a
real
challenge
to
get
it
ready
to
properly
negotiate
versions,
etc.
A
So,
thank
you
for
joining.
That
is
very
that's
a
uplifting
story
for
the
morning.
G
A
How
do
you
see
it
kind
of
fitting
into
like
what?
How
would
you
describe
its
downfall
succinctly.
F
I
I
so
I
wasn't.
I
wasn't
there
for
the
for
the
creation
of
it
and
documentation.
My
understanding
is
that
they
haven't
implemented
a
widely
deployed
implementation,
but
the
protocol
used
that
extension
hadn't
been
wasn't
very
widely
deployed
for
a
very
good
reason
and
then,
when
it
came
time
to
actually
start
using
it,
all
sorts
of
issues
started
popping
up.
A
F
No,
it's
gonna
work
somewhat.
Just
very
problematic,
very
temperamental
depends
on
your
isp
and
hopefully
yeah.
I
Yeah,
so
you
were
asking
about
failures
and
obviously
tls
has
these
extensions
and
they've
had
mixed
success
in
terms
of
actually
working
in
practice?
Sometimes
new
extensions
do
work.
Sometimes
they
don't,
and
sometimes
they
fail
miserably
for
a
variety
of
reasons,
like
esni's
recent
debacle
being
blocked
maliciously
by
china.
I
don't
know
if
you
would
classify
that
as
an
extension,
like
a
failure
of
the
extensibility
mechanism
to
not
like
hide
itself
from
that
particular
adversary
or
not.
I
So
I
I
guess
it
sounds
clear
to
me
when
you,
when
you're,
asking
about
failures
or
successes.
Rather
what
is
the
like?
The
threat
model
that
we're
concerned
with?
Is
it
just
like
this
dumb
anti-ossifying
middle
box
that
could
potentially
be
buggy
or
is
it
something
more
malicious?
That's
actively
trying
to
you
know
prevent
the
use
of
certain
extensions
or
just
a
general
extension
mechanism.
A
I
think
that's
a
good
distinction
to
bring
up
and
maybe
something
that
we
would
want
to.
A
You
know
document
at
least
that
that
gets
to
the
point
of
you
know:
do
you
what
do
you
put
behind
that
cryptography
barrier
to
reduce
the
number
of
people?
Who
can
do
this?
Because,
even
if
you
have
active
use,
but
people
don't
like
what
you're
using
they
can
that's
not
really
an
ossification?
That's
an
attack.
I
Yeah
but
the
end
result
is
effectively
the
same
right
like
you
just
failed
to
use
this
new
extension
so
yeah,
I
don't
know
if
making
that
distinction
is
useful
or
not,
it
might
be
in
terms
of
like
guiding,
which
extension
mechanism
to
use
so.
B
Telis
is
kind
of
unique
in
the
sense
that
it
provides
the
encryption.
It
doesn't
necessarily
encrypt
itself,
and
so
it
has
this
sort
of
bootstrapping
problem
that
the
encrypted
client
allows
is
the
perfect
example
of
right.
You
don't
have
a
prior
session,
so
therefore
you
don't
have
crypto
keys,
and
so
you
end
up
in
this
in
this
situation,
where
you
have
to
be
exposed
to
all
of
these
these
third
parties,
would
you
say
that.
B
I
B
A
A
D
So
the
the
tls
point
is
interesting
because
and-
and
I
I
think,
I'm
going
to
be
annoying
transport
guy
and
say
we
need
to
treat
security
special
here,
because
one
there's
the
physics
problem
right
like
so,
no
matter
how
we,
how
we
wave
our
hands
around
the
problem
of
you,
can't
have
cryptographic
context
before
you've
shared
cryptographic
context
right
like
so
that's
just
that's
a
hard
physical
problem.
D
Okay,
unless
we,
you
know,
won't
get
into
that
the
other
issue
with
tls
that
I
think
it
popped
up
when
chris
pointed
out
the
the
s
interception
is
that
there's
different
models
of
non-functioning
of
an
extension
mechanism
that
we
need
to
talk
about
right,
like
so
the
sni
non-functioning
of
that
extension
mechanism
fundamentally
changes
the
security
properties
of
the
channel,
and
that
now
you
know
who
one
of
the
endpoints
is
that
you
weren't
supposed
to
know.
D
Whereas
you
know
non-functioning
of
you
know,
sort
of
I'll
say
pre-hipster
protocol
extension
mechanisms
was
okay.
If
I
speak
this
extension
mechanism
and
you
speak
or
if
I
speak
this
extension-
you
speak
it,
then
we
will
negotiate
it
and
we'll
will
upgrade
there's
something
fundamental
hiding
in
the
fact
that,
in
certain
cases,
upgrade
is
sort
of
this
optional
nice
to
have,
and
in
other
cases
it
fundamentally
changes
the
the
properties
of
the
channel
in
an
unacceptable
way
right
like
so
that
the
the
use
of
the
words
upgrade
and
downgrade.
D
When
you
talk
about
downgrade
and
then
the
word
attack
usually
comes
after
that
in
the
dls
context,
I'm
wondering
if
there's
something
in
the
physics
of
these
protocols
that
makes
it
necessary
to
treat
these
cases
separately
right
like
so.
We
can
talk
about
you
know.
Sni
is
an
extension
mechanism
or
we
could
talk
about.
Sac
is
an
extension
mechanism.
D
Are
they
like,
we
think
of
them,
as
extension
mechanisms,
because
it's
different
bits
on
the
wire?
But
is
there
something
fundamental
about
the
semantics
of
these
things?
It
means
that
we
could
actually
use
different
terminology
for
the
two
different
things,
and
this
is
not
me
saying.
Oh,
the
security
thing
is
hard
and
I'd
rather
not
think
about
it.
It's
the
the
fact
that
in
some
cases,
the
the
like
the
consequences
of
the
failure
of
an
extension
mechanism
can
be
widely
different.
E
D
Leaking
is
your
interest
in
a
website
that
affiliates
you
with
an
illegal
political
group,
for
example,
it
might
be
better
just
to
say
you
know
what
this
you
know.
Failure
is
the
better
option
and
that's
different
than
in
a
lot
of
cases.
When
we
talk
about
sort
of
like
the
interference
and
extension
mechanism
right.
D
A
Yeah
I
mean
I
can
imagine
other
I'm
wondering
if
those
properties
are
just
kind
of
based
on
the
layer
that
we're
talking
about
that.
Like
okay,
transport
ossifying
is
different
from
security
officifying
and
if
you
have
your,
you
know,
http
semantics,
ossifying
or
like.
If,
if
your
extension's
failing
to
work
there,
then
you
aren't
able
to
do
this.
Particular
application
function
and
your
website's
not
going
to
work
in
this
right
way,
and
it's
going
to
look
like
garbage.
A
J
Colin,
hey
so
just
following
on
for
other
properties
other
than
security
or
privacy,
where
we
would
want
to
fail
if
we
can't
negotiate
the
extension
rather
than
continue
non-extended
yeah,
I
mean
that
seems
to
be
the
key
distinction
brian's
pulling
it.
A
A
To
to
use
this
particular
extension
mechanism
that
allowed
me
to
do
you
know,
let's
say
you
know
we're
adding
you
know
we
have
ways
of
doing
within
h3.
We
can
do
unreliable
stuff
because
we're
doing
some
gaming
extension.
I
don't
know,
I
guess
we
could
always
design
fallbacks
that
try
to
use
other
things.
Yeah.
J
D
D
You
obviously
want
the
extension
test
application
to
fail
when
the
extension
fails,
but
I
am
resistant
to
this
idea
only
because
I
am
very
aware
of
our
sort
of
tribal
history
of
saying
security
is
special,
especially
in
the
transport
area,
and
I
really
want
to
resist
saying
that,
but
it
might
just
be
that
security
is
special.
A
Yeah
well-
and
I'm
wondering
also
like
there
is
a
there's-
a
temporal
aspect
to
all
of
this-
in
that
my
my
set
of
things
that
I'm
willing
to
downgrade
gracefully
like
every
graceful
downgrade,
because
the
extension
doesn't
work
has
to
have
explicit
engineering
work
from
someone
designing.
What
is
the
downgrade
too,
and
I
have
to
do
potentially
a
lot
more
work
to
simulate
what
I
was
going
to
do
or
compensate
for
it.
A
I
don't
know
if
that's
often
documented
or
made
explicit
that
you
know
when
we
have
these
extension
mechanisms.
A
B
Martin
yeah,
so
watson
made
a
comment
in
chat
that
I
I
thought
was
interesting.
I
I
think
it's
a
it's
a
security
point
that
he's
making,
but
it
made
me
think
that
about
one
of
the
principles
in
the
draft
that
I
wrote,
which
is,
if
you
can't
trust
the
other
side
to
implement
a
particular
feature
properly,
sometimes
it's
not
worth
continuing.
So
if,
if
it's
clear
that
they
have
not
correctly
implemented
header
parsing
in
http,
I'm
not
going
to
send
them
requests
with
headers
in
them,
because
that
probably
won't
work.
B
So
I'm
going
to
close
the
connection
down
and
part
of
the
reason
you
do
that
to
to
watson's
point
is
so
that
you
know
when
something
has
failed
and
you
escalate,
rather
than
than
just
sort
of
try
to
muddle
by
and
and
follow
along
with
the
I
guess,
the
robustness
principle
I
will.
I
will
attempt
to
attempt
to
interpret
intent
and
try.
My
best
doesn't
always
get
you
reliable
results.
So
that's
that's
a
that's
a
reason
why
you
might
not
want
to
want
to
do
that.
Yeah
carsten
says
fail
fast
yeah.
A
So
I
think
this
is
useful
stuff,
any
other
points
people
want
to
make
here
any
other
examples
that
people
want
to
bring
up.
That
would
be
enlightening
for
us.
A
Without
that,
I
think
we
can
move
on
and
yeah
we'll
look
at
the
notes
from
this
and
discuss
on
the
list
about
what
we
want
to
do
with
this
document,
and
maybe
what
are
the
things
that
we
could
add
or
tweak
in
it
and
we'll
ask
people
to
kind
of
review
it
more
holistically
as
well.
A
Was
kind
of
you
know
what
are
the
mechanisms
that
we
have
within
working
groups
to
track
our
interoperate
deployment
if
we're
doing
experiments
and
new
extensions?
How
do
we
know
and
coordinate
that
we're
doing
these,
and
this
is
something
that
had
been
discussed
a
fair
bit
on
the
working
group
chairs
list,
and
that
was
a
nice
big
thread.
So
I
imagine
people
have
opinions
there.
A
So
here
you
know,
I
know
we
have
examples
within
quick
and
with
within
tls
and
other
areas
about
you
know
how
are
we
doing
stuff
on
github
or
different
groups,
use
wikis
and
stuff,
but
I'd
like
to
hear
from
this
group
kind
of
what
are
the
models
that
they've
done
for
tracking
implementations
and
interops
and
deployments,
and
what
of
those
work?
Well,
what
are
the
things
that
would
be
useful
for
your
groups
going
forward.
A
Okay,
okay,
charles.
K
K
So
it
may
not
necessarily
be
code
that
is
implementing
the
protocol,
but
code
that
helps
someone
with
implementing
the
protocol,
like
just
a
library
or
a
test
client
or
a
lot
of
the
types
of
things
that
we
end
up.
Working
on
in
the
ietf
hackathons,
for
example,
and
those
things
may
be
long-lived
they
may
be
short-lived,
but
they
kind
of
help
move
the
protocol
forward.
They
can
help
someone
gain
understanding
of
the
protocol
may
help
someone
with
implementing
the
protocol
or
adding
support
for
it
into
their
their
their
client
their
server
whatever
it
may
be.
K
I
think
those
things
are
not
straightforward
for
people
to
find
in
general,
of
course,
people
working
in
the
hackathon
can
find
them,
but
you
know
if
they're,
hopefully,
there's
links
to
them
on
the
wiki,
but
we
don't
have
a
consistent
way
of
tying
them
back
to
the
the
work
that
the
working
group
is
doing
or
even
the
making
it.
If
you
have
the
rfc
like
how
are
you
ever
going
to
realize,
there's
this
code
associated
with
it,
so
that
was
my
interest
and
it's,
I
think
it
helps
deployability
and
deployment.
A
No,
I
I
mean
we
can
probably
open
up
another
issue
here
for
that,
but.
A
On
the
topic
that
we
are
looking
at
because,
ultimately,
like
I,
I
think
I'm
only
interested
in
tracking
deployments
and
interops
to
the
extent
that
it
helps
improve
the
deployability
so
within
the
hackathon
work,
because
I
think
that's
you
know
one
of
the
best
concrete
sources
of
implementation
work
that
we
have,
and
you
know
that's
where,
of
course,
some
of
this
interrupt
testing
goes
on.
A
K
Well,
it's
usually
in
the
the
hackathon
wiki
the
hackathon
for
that,
but
the
wiki
for
that
specific
hackathon,
like
we
had
one
for
igf-108,
we'll
have
one
for
ihf-109.
K
If
you
go
back
and
look
at
those
you'll
find
links
to
you
know
directly
to
say,
github
repos
sometimes
they're
a
link
to
another
wiki,
and
then
that
wiki
has
the
links
to
the
github
repo
or
wherever
the
code
may
be.
K
So
you
can
usually
find
the
code
that
people
were
working
on
for
all
the
projects.
At
the
other
place
you
find
it
is
in
the
presentations
that
they
did,
which
are
also
uploaded
to
actually
not
in
this
case,
not
to
the
wiki
but
to
another
github
repository
that
we
have.
So
if
you
know
where
to
look,
you
can
probably
find
this
for
basically
almost
all
the
projects.
K
But
what
happens
after
the
hackathon
are
those
links
still
useful?
Do
people
know
to
go
back
and
look
for
them?
It's
yeah,
because
it's
in
multiple
different
places
and
done
in
different
ways.
We
don't
have
like
a
set
recommendation
for
how
to
do
it.
I'd
say
in
some
cases
people
will
add.
They'll
put
the
code
in
the
in
a
github
repo
that
is
perhaps
even
on
the
the
wiki
page.
K
Sorry
in
the
data
tracker
for
the
working
group
and
that's
arguably
a
good
way
to
go,
but
that's
not
done
universally
either,
and
so
you
know
as
an
additional
url
you
can
get
to
from
the
data
tracker
yeah.
But
perhaps
that's
a
good
thing
to
do
so.
My
thought
was
just
to
get
people
to
discuss
this
and
agree
on.
You
know,
perhaps
a
small
set
of
ways
that
we
think
these
are
the
recommended
or
best
ways
to
do
it
and
to
try
to
get
those
to
be
used
consistently.
A
Yep
colin.
J
Thinking
back
to
when
we
did
this
for
the
rtp
spec,
when
we
went
from,
I
guess
from
marissa
1889
to
35.50,
and
I
mean
I,
I
guess
things
have
changed
quite
a
lot
in
the
far
too
many
years
since
then,
but
we
we
had
an
internet
draft
where
we
pulled
out
all
of
the
the
essential
interrupt
points
and
went
through
and
listed.
J
You
know
actually
wrote
down
a
list
of
implementations
for
each
one
and
whether
we'd
found
interworking,
implementations
or
not,
and
I
mean
that
was
never
intended
to
be
published,
but
going
back,
I
can
see
if
I
look
in
the
proceedings
from
about
80,
f,
50
or
thereabouts.
The
draft
and
the
slides
where
this
was
discussed
in
the
working
group
are
all
still
there.
So
we
we
we
at
least
have
a
record
of
how
the
interrupt
discussion
worked.
J
A
C
Say
this
out
loud
so
so.
B
One
of
the
things
that
I've
observed
about
this
is
that
the
protocols
that
seem
to
to
work
the
best
are
the
ones
that
have
a
community
developer
around
them.
And
so
you
have
a
group
of
people
who
are
all
working
on
implementations
and
working
on
the
specs
and
they
communicate
with
each
other,
and
I
haven't
found
that
in
those
communities,
there's
been
any
problem
with
awareness
of
what
people
have
where
they're
up
to
any
of
those
sorts
of
things.
B
There's
a
couple
of
things
like
what
roman
pointed
out
in
the
chat
in
terms
of
reporting
about
the
the
status
of
implementation
when
you're
working
on
something
new,
but
that's
just
to
kind
of
naturally
falls
out
of
all
of
this.
A
A
A
I
I'm
not
sure
that
we
should
kind
of
have
the
barrier
to
entry
such
that.
If
you
want
to
have
that
level
of
clarity
and
communication
that
you
need
to
go
figure
out
how
to
do
that
or
if
we
we
should
have
a
template
for
that
or
a
way
to
make
that
easier
to
bootstrap.
G
Yeah,
I
guess
I
was
what
what
you
just
said,
which
is
it's
not
clear
to
me
that
we
need
the
interop
reports
and
the
implementation
reports
to
be
all
in
the
same
format.
But
I
think
what
might
be
nice
from
the
discoverability
perspective.
If
the
data
tracker
had
a
standardized
way
to
point
to
the
unstandardized
report,
so
you
could
go
to
work
group
and
it
could
point
to
whatever
we
think
we
wanted
to
point
to
which
doesn't
have
to
be
standardized.
But
there's
a
repeatable
and
a
consistent
way
to
find
whatever
is
written
up.
E
I
only
want
to
very
slightly
disagree
with
martin
so
where
we
have
developer
communities
that
works
well
and
people
know
where
to
find
things
and
can
talk
to
each
other,
but
they're
also
always
people
who
are
not
part
of
this
community
who
want
to
join
the
community.
You
develop
a
new
implementation,
and
especially
in
for
a
quick,
for
example.
A
There
yeah
yeah-
and
I
I
think
part
of
this
is
overall
and
there's
there's
a
background
desire
to.
You
know,
make
sure
that
we
don't
have
too
many
silos
of
communities
that
we
don't
have
our
ietf
protocol,
documentation
being
completely
separate
from
people
who
are
actually
doing
open,
source
implementations
or
have
you
know,
different
groups
are
not
talking
to
each
other.
So
yes,
for
the
cases
in
which
it
already
is
working
and
we
have
implementer
communities
that
are
very
involved
in
itf
and
they
have
their
own
place
to
do
their
work,
that's
great.
A
J
J
One
of
the
things
which
we
make
very
difficult
for
groups
is
to
add
resources
on
the
itf
sites.
Yeah
I
mean
yeah,
I
mean
I
guess
we
have
a
wiki,
but
it's
pretty
clunky
and
it's
it's
not
very
easy
to
find.
A
Like
one
one
thing
I
was
thinking
about
for
data
tracker
is
like
the
model
that
we've
had
more
recently
for
like
how
people
can
propose
slides
or
things
like
that
is
a
lot
better,
also
than
cases
where
it
just
relies
on
chairs
to
go
and
upload
and
update
content.
So
I
think
we
would
also
want
you
know
anyone
if
we
were
hosting
information
or
links
to
implementation
status.
Being
able
to
have
those
implementers
be
able
to
propose
content
into.
There
would
be
useful
brian.
D
Sorry,
looking
for
the
mute
button,
so
another
thing
that
I've
seen
in
quick,
I
haven't
seen
in
other
other
working
groups.
I
expect
that
they
that
exist
in
a
few
other
places,
though,
is
actually
publicly
available
endpoints.
D
So
implementers
will
keep
a
publicly
available
endpoint
for
testing
up,
and
this
makes
sense
in
sort
of
the
quick
world
where
everything
is
happening
very
quickly,
and
you
know
they
already
had
it
yeah
sorry
and
they
already
had
a
sort
of
a
cadence
of
virtual
interops
even
before
we
all
got
off
of
airplanes
and
you
have
the
time
zone
problem.
So
obviously
you
want
to
keep
you
want
to
keep
the
the
endpoints
up.
D
D
For
their
own
use
and
having
a
way
to
collect
or
make
those
make
those
more
publicly
available,
because
there
you
don't
have
the
problem
of
a
wiki
that
rots,
I
mean
you
might
have
a
problem
of.
You
know
your
publicly
available
testing.
Endpoint
is
you
know,
seven
revs
behind
the
thing
that
you're
actually
shipping,
but
if
you're
actually
using
it
for
online
testing
anyway,
then,
hopefully,
the
fact
that
you
know
it's
the
code
would
would
keep
it
from
rotting
as
much.
A
Also,
you
kind
of
mentioned
the
virtual
interop
schedule
and
how
that
you
know
happens
on
a
cadence
right.
That's
something
that
you
know
also
seems
like
it
would
fit
well
like
we
have
meeting
schedules
visible
on
data
track
and
other
things.
If
we
had
kind
of
more
support
for
saying
like
yeah,
these
are
our
interrupt
times
or
calendars
for
doing
other
things.
A
Other
thoughts
that
people
have
maybe
any
oh
robin.
L
Hello,
yes,
okay,
so
in
fact
the
in
our
words
is
the
routine
area,
so
you
know
that's
the
for
our
srv6.
We
have
a
draft
to
record
the
implementation
status
and
also
the
incredibility
status.
I
think
that's
a
possible
way,
but
we
know
that
some,
sometimes
when
the
when
the
rc
is
published
or
the
working
group
is
closed,
maybe
not
there's
another
way
to
update
this
draft
or
the
rc.
A
No,
that
makes
sense,
and
that's
one
of
the
things
that
was
discussed
on
the
list.
So
essentially,
I
think
there
are
a
couple
different
parts
to
what
you
said
right
so
like
one
like
within
routing,
there's
already
a
practice
of
documenting
in
a
draft
like
here's,
the
implementations
section.
A
And
then
you
can
kind
of
keep
updating
that
even
after
the
rfc
is
published
and
then
you're
saying
even
kind
of
decorate
like
tools
would
let
you
get
back
to
it
or
whatever
other
view
of
the
rfc
right.
C
D
A
Thank
you
yeah.
So
what
what
are
people's
thoughts
and
reactions
to
that?
There
are
a
lot
of
different
opinions
on
if
we
should
how
we
should
formalize
that.
A
F
Yeah,
so
I
think
I'm
not
sure
what
the
question
is
about
tracking
interop
and
deployment
if
it's.
These
are
the
servers
that
are
running
these
draft
versions
that
you
can
test
your
implementation
and
figure
out
where
the
draft
clear
during
the
operation,
that's
different
from
curating
a
list
of
of
implementations
later,
and
so
I
think
some
of
the
concerns
people
are
raising
about
the
stability
and
how
do
you
find
it
etc?
F
A
F
So
I
think,
with
I
only
really
know
ntp
recently.
What's
going
to
happen,
is
there's
going
to
be
new
versions
released
with
nts
and
they'll
prominently?
Have
it
in
their
release,
notes
and
people
will
look
there
and
see
what
the
package
does
and
see
what
the
what
the
features
are,
whereas
a
lot
of
the
implementations
we're
making
are
not
full
featured
they're
just
there
to
show
protocol
works
and
hammer
out
bugs
in
the
spec.
C
E
Miriam
yeah,
I
think
the
the
the
thing
that
we
need
to
concentrate
first
on
is
how
to
find
this
information,
rather
than
trying
to
standardize
this
information
a
certain
way.
E
If
we,
if
we
can
make
it
more
easier
to
find
then
maybe
a
kind
of
pseudo
standard
or
whatever
rights,
because
people
get
used
to
seeing
it
in
a
certain
way.
But
as
long
as
people
don't
know
that
this
information
exists,
it's
everybody
just
comes
up
with
their
own.
K
I
think
to
to
that
point.
One
of
the
things
I
wanted
to
try
was
at
least
for
the
next
hackathon.
Let's
just
try
this
and
let's
see
for
all
the
projects.
If
we
can
get
links
back,
you
know
that
make
it
easy
for
you
to
tell
you
know
what
working
group
that
project's
related
to
and
how
to
get
access
to
the
code.
So
whether
you
are
on
the
hackathon,
wiki
or
you're
in
the
data
tracker,
you
know
you're
able
to
find
out
from
the
data
tracker
that
there's
this
code.
K
K
I
don't
think
all
readmes
are
updated
as
they
should
be
over
time,
especially
as
code
you
know,
get
sort
of
abandoned
or
degrades
or
whatever,
but
but
to
me
that
would
be
the
place
to
say,
like
hey
we're
not
actively
using
our
radiators
anymore,
you
know,
and
then
so,
even
if
someone
did
find
an
old
link
at
least
hopefully
the
readme
would
set
them
straight
as
to
whether
or
not
this
is
code
they're
really
interested
in.
A
Yeah,
that's
an
interesting
point
in
general
about
using
kind
of
using
the
fact
that
we
already
have
the
hackathon
infrastructure
and
that
going
on
as
the
concrete
way
to
try
try
some
of
these
tools
out.
A
A
I
think
some
of
the
actions
that
we
have
coming
out
of
this
are
one
to
take
a
look
at
what
we've
discussed
here
for
kind
of
the
extension
mechanisms
and
review
on
the
list,
martin's
document
and
see
what
we
want
to
add
or
send
to
that
and
how
we
can
adopt
that
and
progress
that
that's
one
and
then
on
the
other
side,
I
think
we
do
have
a
concrete
thing
which
we
can
look
at.
Maybe
how
can
we
integrate
some
tools
with?
A
Kind
of
experiment
with
having
more
formal
documentation
for
our
interop
and
deployments.
So
thank
you
all
and
we'll
try
to
get
the
recording
posted
somewhere
sometime
and
we'll.
Let
the
list
know
that.