►
From YouTube: IETF114-EDM-20220728-1300
Description
EDM meeting session at IETF114
2022/07/28 1300
https://datatracker.ietf.org/meeting/114/proceedings/
A
All
right,
good
morning,
all
right,
I
think
we
we'll
get
started
here
now.
The
the
chat
already
has
the
edm
music
going.
So
thank
you,
brian
for
providing
that
yeah.
So
welcome
to
the
first
in-person
meeting
of
the
edm
program.
So
today
we're
going
to
talk
about
mainly
one
draft,
but
I
also
wanted
to
give
a
quick
intro
just
to
what
the
program
is
for
the
people
who
haven't
been
on
the
calls
that
we've
had
virtually
those
have
usually
been
relatively
small
and
focused.
A
But
it's
easier
to
have
these
things
when
we
have
an
actual
crowd
to
meet
david,
and
I
are
leading
this
from
the
ib
side.
But
it
is
open
to
participation
and
input
from
the
whole
community,
which
is
how
kind
of
the
the
current
generation
of
iab
technical
programs
are
working
in
general.
So
thank
you
for
being
here
and
contributing.
A
A
It
is
a
technical
program
that
we
have
so
our
goal
is
to
have
good
technical
discussions,
work
on
documents
when
that's
appropriate,
but
also
just
kind
of
figure
out
what
are
the
right
things
that
we
should
be
doing
as
a
community
technically
on
things
and
the
topics
here
yeah.
I
also
cannot
believe
this
has
been
two
years:
yeah,
weird
evolvability,
deployability
and
maintainability.
So
evolvability,
I
think,
is
mainly
around
taking
up
some
of
the
work
that
had
been
done
previously
in
iab
around
preventing
ossification
figuring
out.
How
do
we
maintain
extensibility.
A
A
A
A
Those
are
pretty
flexible
as
it
is,
but
we
formally
defined
like
a
related
implementations
tag,
because
we've
done
a
survey
of
the
chairs
in
general
and
just
tried
to
see
you
know
how
are
people
tracking
these
things
there's
a
big
diversity
but
having
easy
ways
to
if
you
are
coming
to
the
ietf
as
someone
who's
just
I'm
implementing
this
draft
or
this
I'm
working
in
this
group
who
else
is
working
on
this?
Where
do
I
find
the
hackathon
projects
if
we
can
start
formalizing
and
saying
like
hey
if
you're
having
great
hackathon
projects?
A
Let
people
know
where
they
are
such
that
if
they're
reading
your
document,
we
can
tie
those
together,
and
so
that's
just
like
a
first
step,
and
we
want
to
see
with
that.
It's
not
really
an
experiment,
but
like
what
can
we
do
to
use
that
and
see
how
it
goes
in
working
group?
So
I
encourage
people
to
use
it,
and
I
think
it's
a
call
that
we
should
make
that
more
widely
known.
A
C
A
D
Yes
started
using
it
in
two
working
groups,
since
charles
talked
about
it,
the
working
group
chairs
lunch,
one
of
the
groups
that
I
sent
it
to.
They
actually
had
problems
figuring
out
the
fact
that
you
could
actually
have
multiple
entries
there,
which
is
documented
on
there.
So
I
help
them
with
that,
but
the
part
about
how
to
add
the
label
tag
in
parentheses
is
not
documented
or
whatever.
So
we
just
need
to
advertise
that
part
more
because
I
had
problems
with
that,
but
I'm
now
using
it.
It
works
great.
A
B
Yeah
paul
hawking
again,
so
I
propose
this
is
not
just
something
for
working
group
chairs.
I
mean
this
sounds
great.
I
haven't
been
wearing
a
blue
dot
in
the
last
few
years,
so
I
didn't
know
about
it.
If
y'all
once
once
you've
done
like
once,
you
feel
like
the
documentation's
writing
stuff.
If
you
could
send
a
message
to
you
know
ietf
at
saying
this
exists
and
such
like
that
I
think
a
bunch
more
people
will
bug
their
work
and
group
chairs
yes
to
do
it.
Yup.
A
Thank
you
so
yeah
I
mean
thank
you
for
doing
that.
So,
like
I
think,
as
we
get
some
feedback
from
the
chairs
initially,
then
we
can
say
all
right:
here's
how
here's
some
examples
of
how
people
are
using
it.
If
you
want
to
use
it
in
your
working
group,
bug
your
chairs
yeah
great,
all
right
and
then
for
the
remainder
of
the
session
discussion
today.
A
Draft
ib
protocol
maintenance-
and
this
is
something
that
has
evolved.
Martin
was
the
original
author.
David
took
up
co-editing
it
as
a
current
iab
member
and
we've
had
quite
a
bit
of
discussion
on
architecture,
discuss
about
some
of
the
details
here.
So
in
general,
when
we've
discussed
this
on
the
ib.
C
A
Know
it's
something
that
you
know
we
would
like
to
move
forward.
You
know
we
acknowledge
that
is
not
ever
going
to
be
something
that
is
perfect
and
everyone's
going
to
have
complete
consensus
on,
but
we
would
like
to
get
progress
on
it,
and
this
is
a
good
group.
I
think,
to
give
some
feedback
on
what
are
some
of
the
refinements
we
can
make
before
publishing.
E
E
We
we
got
some
pretty
spirited
discussion
on
the
architecture,
discuss
list
fun
times
and
we
decided
oh
well,
let's,
let's
chat
in
person,
things
always
work
out
better
when
we're
face
to
face,
even
if
virtually
so
what
I
was
thinking
is
maybe
starting
with,
like
the
definition
of
the
robustness
principle
that
we
chose
to
use
in
this
document,
because
it
became
clear
that
those
words
didn't
mean
the
exact
same
thing
for
everyone,
and
we
had
to
pick
one.
We
picked
the
one
that
was
like
the
oldest
star
of
c.
E
We
could
find
a
sensible
option.
I
I
can
totally
see
that
there
are
other
interpretations,
but
just
to
set
the
stage
when
the
so
the
the
overall
message
of
the
document
is.
We
had
the
robustness
principle,
which
said
you
know,
follow
the
spec,
but
you're
you're
gonna
find
something
a
condition.
That's
like
not
clear
in
the
spec,
because
it's
not
possible
to
make
a
perfect
spec.
E
Otherwise,
we
wouldn't
have
job
security
and
when
you
do,
how
do
you
react
to
that
and
the
leading
idea
in
the
90s
was
you
are
liberal
in
what
you
get
meaning
you
take
this
erroneous
input
and
you
make
do
you
do
not
error
and
that's
that's
like
in
rc
1958,
the
message
there?
No,
not
58
right.
Oh
yes,
58,
okay,.
A
E
Exactly
this
is
for
cases
when
you
don't
have
the
spec
yeah
yeah.
Let
me
finish
my
quick
intro
and
then
dave.
It's
your
your
first
step
and
then
so.
The
message
in
in
this
document
is
the
world
has
changed
quite
a
bit
since
the
90s
and
what
worked
really
well
then,
and
what
actually
got
the
internet
up
and
running?
Isn't
neces
necessarily
the
best
advice
that
we
can
give
today
and
the
document
goes
into
some
detail
of
what
problems
can
arise.
E
If
you
follow
this
to
the
pretty
to
its
logical
conclusion
and
proposes
alternatives,
specifically
protocol
maintenance,
when
you
have
the
ability
to
evolve
specs
over
time
and
evolve,
implementations
and
their
deployment
of
such
implementations
over
time,
so
the
document
has
come
a
long
way
in
terms
of
overly
focusing
on
the
negative
at
first,
we
still
have
a
ways
to
go.
We
have
a
pr
that
wants
to
improve
this,
but
it's
kind
of
the
idea
is
the
robustness
principle
is
no
longer
the
best
thing
we
have.
We
have
something
else
that
is
protocol
maintenance.
E
D
Okay
and
right
now,
it
comes
across
as
saying
the
robustness
principle
itself
is
bad
and
therefore
all
four
are
bad,
and
hence
the
strong
negative
reactions
about
the
other
three
that
are
good
things.
Okay
and
the
things
you're
pointing
about
are
bad
things.
I
agree
with
right,
but
the
title
and
the
tone
come
across
as
throwing
the
baby
out
with
bath
water,
which,
if
you're
not
an
english
idiom
person.
D
D
D
If
there
are
errors
like
a
bug
or
whatever
that
you
don't
crash,
okay,
that's
one
definition
of
robustness
is
that
you
stay
up
and
running
in
the
presence
of
errors
right,
you
don't
crash
okay,
so
one
definition
of
robustus
principle
is
don't
crash.
When
you
see
unexpected
input.
Okay,
third
one
is
robustness
to
attacks.
Okay,
someone's
actually
trying
to
attack
you
and
intentionally
sending
you
things
that
violate
the
spec.
You
should
be
robust
to
that
too.
D
Okay,
so
that's
also
both
of
the
number
two
and
number
three
I
claim
are
purely
valid
in
the
interpretation
of
what
1958
says,
in
other
words,
in
1958
and
760,
I
see
as
being
almost
opposite
definitions
of
the
roughness
principle
in
terms
of,
if
you
accept
and
try
to
treat
as
valid
errors
versus
if
you
treat
as
invalid
errors
and
then
continue
on
operation
without
detrimental
effects
right
both
of
those
are
interpretations
of
robustness,
principle.
Okay,
I
claim
that
the
invalid
one
is
the
obsoleted
one
in
760
and
the
correct
one.
D
Is
the
1958
not
obsoleted
one?
Okay,
that's
why
my
negative
reaction,
even
though
I
agree
with
the
points
about
760s
interpretation,
the
last
definition
of
the
robustus
prince
would
be
robustness
to
variations
in
maize
and
shoulds
right.
Just
because
you
do
a
particular
variation
of
amazing
shows.
You
still
have
to
be
robust
to
the
other
guy.
According
to
the
spec
right,
the
spec,
a
well-written
spec,
actually
is
written
that
way
to
allow
you
to
interoperate
with
people
that
make
a
different
set
of
choices.
D
You
can
argue
that
that's
also
liberal
and
what
you
accept
in
the
sense
of
a
different
variation
within
this
spec.
All
four
of
those
are
ways
of
interpreting
be
conservative.
What
you
send
in
liberty
and
what
you
accept
only
the
first
one
is
the
harmful
one.
Okay,
so
that's
why
I
have
a
problem
with
the
title
and
the
tone,
even
though
I
agree
with
the
content
about
that.
First
interpretation
being
bad
and
all
the
good
things
that
are
in
there
are
great
stuff
to
have
in
there.
D
So
I
personally
would
rather
frame
the
document
about
you
know
the
correct
application.
The
resonance
principle
define
it.
So
there's
these
four
different
interpretations.
Three
of
them
are
good
and
here's
how
to
apply
them,
and
this
one
is
bad
and
here's
how
to
do
stuff
instead.
So
that's
what
I
would
like
to
see
the
document
become
and
then
I
would
very
much
support
it.
So.
E
D
E
That's
true,
I
personally
don't
see
that
as
necessarily
the
robust
principle.
It
feels
like
common
sense,
but
it's
also
that,
like
it's
been
done
for
so
long
that
you
know,
I
I
assumed
it
as
a
you
know,
one
of
the
laws
of
physics,
but
maybe
yeah
calling
it
the
part
of
the
robustness
principle,
makes
sense
and
then
same
for
reacting
to
attacks
everyone's
in
agreement.
E
Don't
let
attackers
beat
you
on
the
other
on
the
the
point,
and
I
think
that's
the
one
where
maybe
we
we
disagree
on
this
one
is,
if
you
get
faulty
input
and
it's
not
clear
what
the
spec
tells
you
to
do,
your
options
are
to
you
know,
accept
it
and
like
process
it
fully.
I
think
we
can
all
agree.
That's
a
bad
idea,
because
that
was
the
original
one
that
got
obsoleted.
E
Another
option
is
to
discard
it
silently,
and
the
third
option
is
to
error
and
the
idea
and
that's
what
it's
what's
very
clearly
written
in
1958
and
that's
what
this
document
says
is
harmful
and
because,
if
you
discard
it
silently,
you
allow
the
other
party
to
keep
going
and
and
to
never
notice
their
bug.
So
you
end
up
in
a
situation
where
I
think
this
was
a
point
that
stewart
made
and
I
liked
how
he
phrased
it
was,
unlike
other
sdos,
the
itf
doesn't
have
conformance
tests
and
so
kind
of
the
first
implementation
out.
E
F
I
wanted
to
say
the
same
thing,
but
in
just
less
words
than
david
just
said
so
about
crashing.
I
think
crashing
is
not
part
of
the
rashma's
principle.
Nobody
wants
to
crash
that
implementation.
It's
always
an
implantation
bug
right,
so
I
don't
think
that's
ever
on
purpose
and
the
difference
is
really
what
we're
talking
about
is
like
silent
drop
or
not
silent,
drop
right
and
I
think
silent
drop
and
that,
if
that's
the
only
reaction
is
actually
always
wrong.
A
A
I
think
that
is
definitely
helpful,
so
yeah.
I
agree
that
you
have
the
the
number
one
of
just
be
liberal
and
when
you
accept
that
one
you
know
obsoleted
and
not
great.
I
definitely
agree
with
like
the
number
three
and
four
of
you
have
to
be
robust
to
attacks,
and
you
have
to
be
robust
to
the
maze
and
shoulds
the
things
that
let
you
have
variation,
then
I
think
the
part
I
want
to
dig
in
on
is
similar
to
what
david
was
bringing
up
about.
A
If
someone
just
injected
one
kind
of
packet
of
death
to
try
to
make
me
do
bad
things
to
appear,
if
that,
for
some
reason
like
I
can't
authenticate
it,
you
inject
a
uv
packet
to
me
and
now
I
close
down
all
my
quick
connections
like
that
would
be
a
bad
state
to
be
in.
But
if
I
do
have
an
authenticated
channel
to
someone,
so
I
essentially
know
I'm.
I
am
talking
to
someone
on
the
other
side
who,
I
believe
you
know,
is
compliant
with
this
protocol.
A
If
they
start
sending
me
garbage
on
something
that
is
not
an
extension
point
and
like
I
cannot
parse,
it
probably
is
best
for
me
to
close
that
connection
or
have
some
sort
of
error.
And
ideally
the
specification
tells
me
to
do
that,
but
if
there's
some
weird
edge
case
that
it
did
not
explicitly
say,
oh
if
these
bits
aren't
correct
and
you
can't
parse
this
and
the
you're
gonna
have
a
buffer
overflow.
A
If
you
try
to
go
beyond
this,
when
you're
parsing
the
stream,
you
should
probably
close
the
stream,
rather
than
just
like
silently
dropping
packets
forever.
So
that's,
I
think,
maybe
where
some
of
this
document
is
trying
to
get
at,
and
I
don't
know
how
we
name
that
aspect
of
it
such
that
we
say
hey
this
one
little
bit
in
here
is
the
part
that
we
think
needs
more
thought
when
you're
developing
the
protocol
as
well
as
writing
your
implementation
and
trying
to
have
like
a
default
state
for
handling
garbage
input.
G
I'll
see,
if
you
can
see
me
hello
good
morning,
everyone,
so
I
I
was
a
little
bit
struck
by
dave,
thaler's
sort
of
thank
you
very
much,
for
you
know,
starting
off
with
the
sort
of
the
taxonomy
of
different
things
we
can
do
in
the
history
of
this.
We're
we're
talking
about
some
changes
that
were
made
to
the
interpretation,
the
robustness
principle
in
a
three-digit
rfc
that
were
made
in
a
40-rfc
whose
first
digit
is
one
right.
G
G
H
G
Life
cycles
have
changed
and
pointedly.
One
of
the
big
things
that
has
changed
is
that
sort
of
the
development
you
know
early
development
and
deployment
and
maturity,
life
cycles
and
a
lot
of
cases
in
many
deployments
are
going
to
overlap
as
opposed
to
being
distinct
phases
of
the
protocol
life
cycle.
So
when
we
say
you
know
when
I
originally
put
myself
in
the
queue
because
it's
like,
I
think
we
can
all
agree,
someone
said
I
think
we
can
all
agree
that
you
shouldn't
crash.
B
G
Maybe
at
early
in
the
protocol
life
cycle,
if
you're,
basically
doing
early
interrupt,
may
be
the
right
thing
to
do.
If
you
get
into
a
an
error
state
because
the
other
side
has
sent
you
garbage
is
drop.
The
connection
right
like
that
might
actually,
in
that
point
in
the
deployment
or
if
you're,
in
an
environment
where
you
actually
can
do,
can
do
quick
restart.
That
might
be
the
right
thing
to
do
so
so
it
might
make
sense
to
approach.
I
Dave
is
always
great
at
seeing
a
broader
perspective
and
spotting
our
unconscious
assumptions,
and
I
think
this
is
a
great
example
of
that.
That
I
mean
I
love
the
taxonomy
and
I
think
they
should
be
spelled
out
in
the
document,
because
one
of
the
first
lessons
I
learned
on
my
first
job
was:
if
your
code
crashes,
it's
your
fault,
you
don't
point
at
the
packet
trace
and
say:
well.
They
sent
the
wrong
packet.
I've
internalized
this,
but
other
people
reading
the
document
might
not
have
learned
that
lesson.
I
I
If
the
protocol
specifies
a
documented
extension
mechanism,
like
there's
a
tlv
that
goes
here,
you
shouldn't
drop
the
connection
because
there's
a
tlv
there,
that's
not
the
kind
of
conservatism.
We
mean
we're
talking
about
being
stricter
about
pro
about
specification
violations,
we're
not
talking
about
being
strict
in
the
sense
that
I
don't
support
the
optional
stuff
and
I'll
throw
a
tantrum
if
somebody
else
tries
to
use
it
all.
I
I
I
I
Sender
must
not
do
this,
and
if
it
does,
the
receiver
must
abort
the
tcp
connection.
Immediately
now
we
could
have
said
silently
ignore
that
one
message
and
continue
processing
the
subsequent
messages
on
the
connection.
That
would
be
also
been
a
valid
answer
and
I
didn't
particularly
care
which
we
did,
but
I
did
care
that
we
specified
clearly
in
the
document
what
you're
supposed
to
do,
rather
than
leaving
it
ambiguous.
D
Sorry
I
was
typing
because
I
completely
agree
with
you
and
would
love
that
point
to
be
made
in
the
in
the
in
the
in
the
document,
and
I
saw
I
think
antoine
or
whatever
made
a
comment
in
chat
that
gets
to
someone
like
why
I
put
myself
back
in
the
queue.
I
think
one
of
the
good
parts
of
the
draft,
meaning
that
the
main
point
of
the
draft
or
whatever
is
to
is
david's
point
about
sending
errors
rather
than
silently
accepting
things.
I
think
one
of
the
reasons.
D
So
if
you
get
strong
negative
reactions
on
things
then
it's
then
I've
found
that,
in
my
experience,
often
that,
as
somebody
believes
that
it's
being
over
applied
to
a
particular
case
that
they
can
think
of
okay,
so
it
makes
me
question
whether
it
needs
an
often
or
a
conditional
mosque,
or
something
like
that.
So
if
I
see
strong
negative
reactions
on
stuff,
I
say:
okay,
am
I
over
applying
this
somehow,
and
I
do
I
need
to
constrain.
Is
there
some
other
case?
D
You
need
to
call
out-
and
I
think
it's
the
job
of
a
good
ieb
spec,
to
actually
call
out
those
considerations
when
those
tussles
are
those
things
that
occur.
That
says:
well,
it's
there
most
of
the
time,
but
this
other
case-
maybe
it's
not.
You
have
to
admit
that
whatever
so
I
found
usually
when
I've
seen
stronger
reactions,
it's
because
somebody
they
think
that
the
statement
is
being
over
applied.
D
I
think
that
might
be
the
case
here,
because
I
agree
with
the
point
that
david
made
right
that
says:
if
I've
got
a
channel
with
somebody
and
they're
sending
a
malformed
packet
at
me,
then
I
should
abort
the
connection
center
or
whatever,
rather
than
silently
accept
it.
Okay.
I
said
this
stuff,
the
main
point
of
the
document.
I
actually
agree
with
right,
so
don't
get
me
wrong,
but
there's
some
misapplication
of
that.
D
That
says,
if
I
don't
already
have
a
channel
with
somebody,
okay
and
I
have
a
denial
of
denial
of
service
attack,
for
example,
then
in
that
case,
it's
often
better
to
drop
stuff,
rather
than
try
to
send
an
error
which
can
lead
itself
to
a
denial
of
zero's
attack.
Right,
if
I
send
error
messages,
especially
if
it's
an
amplification
with
error
messages
larger
than
the
original
one,
so
think
of
it
as
a
tiny
sin
and
a
large
thing
or
whatever.
D
So
there
are
cases
where
silently
dropping
is
actually
better
than
sending
an
error,
and
it
has
to
do
with
this.
Do
I
already
have
a
channel
with
them?
Okay,
if
so,
it's
better
to
send
an
error
message
clearly
right
at
least
I
can't
think
of
a
counter
example
meaning-
and
that
was
the
example
you
used,
which
I
said:
yeah
plus
1,
plus
100
right,
but
there's
also
cases
that
you
can
misapply
it
to
say.
D
Okay,
you
should
send
an
error
case
in
all
cases
and
therefore
open
yourselves
or
the
world
to
distribute
denial
of
service
attacks.
That
would
be
the
over
application
and
that's
where
I
think
you
get
some
negative
reactions
right,
and
so,
whenever
you
see
negative
reactions,
look
for
okay!
What's
the
corner
case
that
somebody
has
in
mind
and
how
do
I
change
the
statement
to
actually
admit
that?
D
So,
that's
why
I
think
that
there's
actually
a
really
good
thing
that
the
iep
document
could
do
here
if
it
covers
these
various
considerations,
while
retaining
the
main
point
of
the
document
here,
I
just
think
there's
other
things
that
should
be
put
in
there
and
the
title
should
be
changed
to
actually
broaden
the
applicability
of
the
principles
that
are
in
here.
So
thanks.
E
J
Thank
you
tommy
for
giving
up
your
seat,
so
I
don't
disagree
that
better
guidance
is
needed
for
implementers
right.
I
think
everybody
in
the
room
probably
thinks
it's
time
for
a
document
like
this
and
and
to
specification
authors
in
particular
too
right
avoid
holes.
That's
that's
also,
I
think,
fairly
clear
right,
try
and
cover
all
the
cases,
but
this
document's
for
when
that
doesn't
happen,
I
think
the
goal
of
any
modern
document,
though,
should
be
to
inform
the
readers
of
their
complete
set
of
choices
and-
and
this
document's
not
written
that
way.
J
As
I
said
on
the
mailing
list
right,
it
should
be
twice
as
long
because,
right
now
it's
written
to
attack
one
viewpoint
and
it's
written
by
sort
of
one
corner
of
the
market
too.
Right,
as
brian
said
a
second
ago
protocol
life
titles
had
life
cycles
have
changed.
I'm
not
sure,
that's
true
right.
If
you
look
at
cpe
vendors
and
router
vendors
and
switch
vendors
and
stuff,
they
have
struggled
to
get
any
deployed
equipment
to
be
updated
right,
especially
in-home
stuff.
J
It
just
doesn't
happen
so
the
market
space
there
has
a
completely
different
viewpoint
from
http.
You
know
implementers
that
are
changing
their
code
every
nine
months
or
every
three
months.
Excuse
me,
and
the
other
big
thing
is
that
closing
a
connection
on
garbage
may
result
in
some
devices
as
taking
the
entire
network
down.
E
E
J
So
going
back
to
my
original
statement,
the
right
thing
to
do
for
implementers
is
to
have
the
completely
documented
set
of
choices,
no
matter
how
hard
it
is.
I
agree,
as
I
mentioned
in
mail
right,
it
should
be
twice
as
long
in
order
to
inc
to
incorporate
all
these,
because
there
are
times
you
really
want
to
accept
data
and
be
flexible,
and
there
are
times
you
need
to
abort
the
connection.
There
are
times
you
need
to
log
the
error
as
myria
said
right,
but
then
accept
more
after
that.
J
It's
hard
to
write
that
generically.
In
the
first
place
I
mean
even
the
corner
cases
we're
talking
sort
of
about
two
extremes:
what
about
the
middle
grounds
where,
in
the
end,
you
know
you
actually
need
to
give
guidance
to
the
user
on
what
the
different
situations
are,
because
even
in
one
protocol
you
may
want
to
do
one
extreme
thing
in
one
case
and
another
more
flexible
thing
and
another,
depending
on
what
the
ramifications
of
that
decision
are
right.
J
K
So
I'm
going
to
partly
disagree
with
dave,
but
also
agree
with
him.
I
think
this
is
this.
This
is
important
because
you
you
identified
four
things.
I
think
there's
only
really
three
that
we're
talking
about
here,
the
the
maze,
insurance
and
whatnot
the
bounds
of
the
protocol
that
that
entities
interacting
with
that
protocol
are
confined
by
and
the
the
robustness
principle
does,
I
think,
apply
in
those
cases
where
someone
steps
outside
those
bounds.
That's
really
what
we're
talking
about.
K
K
K
The
the
whole
thing
about
silent
drop
and
whatever
else
is,
I
think,
a
little
bit
of
a
distraction
here
to
to
some
extent.
I
think
the
that
the
goal
of
the
document
is
to
say
when
you
end
up
when,
when
you
end
up
in
these
situations,
don't
do
the
one
thing
that
is
specified
in
1958
or
worse,
the
its
predecessors.
K
Something
about
sharp
implements
for
sharp
people,
but
I
I
think
that's
that's,
probably
the
part
that
I
continue
to
struggle
with.
When
I
hear
comments
like
where's,
I
just
can't
I
need
I.
I
need
help
in
identifying
where
where's
is
getting
these
misconceptions,
because
it's
not
what
I'm
trying
to
write
down,
and
I
I
didn't
think
that
it
ever
said
anything
about
the
the
bgp
case.
That's
that's
been
talked
about
right,
so
you
receive
garbage.
K
That's
been
forwarded
on
to
you
from
someone
else
and
somewhere
else
in
the
network,
and
you
have
to
deal
with
the
consequences
of
that
and
you
don't
want
to
bring
the
entire
network
down.
It's
only
one
misbehaving
entity
somewhere
remote
that
that's
causing
this
problem
thing
is
that
has
been
documented
by
that
community
and
it's
well
specified
now,
and
the
behavior
is
fairly
consistent
amongst
well,
at
least
amongst
updated
implementations.
K
In
those
situations
where,
where
people
are
unable
to
to
update
their
devices,
they're
causing
harm
to
themselves
and
and
and
others,
it's
not
a
desirable
situation
to
be
in.
Even
though
I
recognize
that
I
I've
got
a
router
that
hasn't
been
getting
security
updates
myself.
Something
have
to
deal
with.
A
H
So
just
a
few
constant
things
so
broadly,
I
think
this
document's
a
good
document.
I
think
it's
a
good
idea,
it's
heading
in
the
right
direction.
I
think
it's
useful
for
us
to
be
publishing
something
in
this
area.
I
do.
I
do
feel,
though,
trying
to
spin
it
a
bit
more
in
a
positive
way
and
make
it
less
confrontational.
I
think
that
would
help
the
community,
so
I
think
that's
worth
taking
the
feedback.
That's
come
in
and
trying
to
twist
it
slightly,
and
it's
also
clear
to
me.
H
The
good
parts
would
be
helpful
of
having
that
sort
of
thing,
and
certainly
where
there's
confusion
about
our
different
interpretations
of
the
robustness
principle
and
I
think
some
people
think
of
it
as
an
extensibility
extensibility
mechanism,
and
I
don't
think
that's
what
it's
about
at
all.
Then
I
think
actually,
why
don't
we
write
down
what
we
mean
rather
than
just
re-quoting
the
historical
robustness
principle?
Why
don't
we
actually
restate
and
say
these
are
the
things
that
we
think
are
good
and
worth
using.
These
are
the
things
that
we
think
don't
work
so
well.
H
I
agree
on
the
on
sort
of
defining
extension
points
in
protocols
rather
than
just
assuming,
oh,
let's,
let's
just
sort
of
constrain,
what
you're
allowed
to
do
and
anything
outside
that's
just
accepted
and
allowed
so
so
I
think
this
is,
I
think
we
want.
I
would
like
to
see
something
published
in
this
area
from
iob
and
I
think,
having
a
bit
more
balanced
view
would
be
good
and
a
little
bit
less
confrontational
thanks
thanks.
E
E
We
want
there
to
be
a
little
bit
of
a
kind
of
a
catchy
start
to
get
people
to
read
it
because
you
know
most
day
like
ebby
documents,
don't
get
read,
but
we
need
to
soften
it
even
more,
because
absolutely
our
goal
isn't
to
piss
anyone
off
our
goal
is
to
get
people
to
go.
Oh,
there
are
many
better
approaches,
so
totally
agree.
Yeah.
B
All
right
paul,
so
I
want
to
reset
here
because
I'm
really
concerned
with
where
the
beginning
of
the
conversation
went,
which
was
we
should
be
emphasizing
sending
error
responses
more
well.
But
people
have
been
saying
that's
what
we
should
be.
You
know
emphasizing
the
not
dropping
but
sending
back
error,
error
responses,
and
I
I
have
a
concern
because
somebody
who
sent
you
a
message
thought
it
was
reasonable,
a
reasonable
message
to
send.
So
they
aren't
really
expecting
an
error
response.
Even
though
it's
in
the
protocol,
they
probably
could
accept
it.
B
That
is
as
new.
In
the
same
way,
we
have
extensibility
points
usually
for
adding
things
to
the
protocol.
Errors
should
be
extensible
as
well
as
a
way
of
making
it.
You
know,
and
quite
frankly,
I
think
private
use
error
messages
are
a
great
thing.
I
know
this
is
like
I
get
beaten
up
on
this
a
bunch,
but
it
allows
greater
flexibility
for
the
receiver
to
say
I
got
an
error
and
it
doesn't
fit
into
exactly
what
the
protocol
authors
thought.
L
L
L
It's
totally
incorrect.
It's
not
what
postal
has
been
saying
and
as
you've
already
like
been
saying
here,
every
protocol
is
different
and
you
may
not
want
to
put
100
pages
in
your
document,
but
then
you
have
to
tone
it
down
that
this
is
not
applicable
for
for
every
protocol,
and
what
you
really
want
is
that
people
are
rigorous
in
the
specification
writing.
L
L
E
Thank
you
debra,
so,
just
to
clarify
one
thing,
pastel's
name
does
not
appear
in
the
document,
apart
from
in
the
references
section
as
one
as
the
author
on
rfc
760.,
so
we're
we're
not
saying
anything
about.
I
know,
though,
a
very
early
version
of
this
draft
said
postal
was
wrong,
but
we've
toned
it
down,
we've
got
for
and
it's
the
document
is
much
better
now
it
got
that
flashy
thing
that
got
people
to
the
table,
but
yeah,
and
so
I
I
see
what
you're
saying
yeah.
H
M
L
A
M
So
what
the
document
actually
says
to
protocol
designers
is
don't
leave.
Wiggle
room
in
your
protocol
be
clear
about
where
things
should
be
rejected
or
whatever
I'm
not
going
to
go
into
too
much
detail
on
the
like
sending
errors
back.
There
are
a
lot
of
cases
where
we
can't
afford
to
send
errors
back,
but
I
think
the
document
could
do
a
better
job
of
calling
out
what
the
robustness
principle
means
for
each
of
these
two
categories:
the
protocol
designers
and
the
implementers
right-
and
it
should
actually
say
that
implementers.
F
That
makes
my
comment
very
short,
because
I
wanted
to
say
the
same
thing
I
think
like
we
should.
This
is
very
clear
for
protocol
specification.
We
should
do
exactly
what
stuart
also
said
earlier
and
there
should
be
no
wiggle
room
and
that's
the
most
important
message
of
this
document
and
about
deployment
parts.
You
know
if
it's
not
well
specified,
then
there's
a
question
what
you
do
and
I
disagree
with
wes.
F
That's
where
I
joined
the
queue,
because
I
don't
think
I
want
to
want
a
document,
that's
very
long
and
talks
about
all
the
different
options.
I
think
the
message
here
is
also
that,
like
silently
drop,
is
not
always
the
best
option,
so
that's
a
big
message
and
I
actually
think
iab
documents
are
best
when
they
are
short
and
give
like
a
very
clear
short
statement.
So
I'm
I
don't
think
we
should
like
cover
the
whole
space
here.
F
A
A
Another
thing
you
could
just
do
is
try
to
restate
it
to
add
a
bit
more
nuance
to
some
of
these
cases
or
to
just
make
it
more
clear
that
I
think,
if
you
go
that
direction
it
gets
into
the
more
like
now,
you
need
to
talk
about
all
the
different
edge
cases,
and
so
potentially
scoping
it
down
would
just
be
about
saying
here
is
how
you
should
use
the
robustness
principle
in
this
type
of
deployment
and
understand
like
no.
It's
not
as
simple
as
just
being
liberal
thanks.
E
E
The
phrase
I
heard
the
most
today
was,
I
agree
with
you,
yes,
and-
and
that
was
great
because
seriously
we
got
really
useful
feedback
that,
like
sometimes
on
the
list,
I
was
like
having
a
hard
time
understanding
what
people
wanted
us
to
change,
and
now
this
is
like
very
actionable
changes
that
we
can
make
to
this
document,
and
so
in
a
way
because
everyone
has
been
saying
like
this
is
useful:
let's
tweak
it
to
publish
it,
not
like
no,
no
go
away
so
we're
gonna.
Take
that
back.