Subject: Re: I-D Action: draft-thomson-postel-was-wrong-01.txt

From: heasley <[email-masked]>
Date: Tue, 13 Jun 2017 03:38:59 +0000

Mon, Jun 12, 2017 at 06:29:30AM -0700, [email-masked]:
>         Title           : The Harmful Consequences of Postel's Maxim
> https://tools.ietf.org/html/draft-thomson-postel-was-wrong-01

Perhaps instead of requiring two implementations for a protocol draft to
proceed to rfc, it should first or also have a test suite that

        ... fails noisily in response to bad or undefined inputs.

Having a community-developed test suite for any protocol would be a great
asset.

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Jun 2017 05:10:41 -0400

--On Tuesday, June 13, 2017 03:38 +0000 heasley
<[email-masked]> wrote:

> Perhaps instead of requiring two implementations for a
> protocol draft to proceed to rfc, it should first or also have
> a test suite that
> 
> Having a community-developed test suite for any protocol would
> be a great asset.

Actually, a number of standards bodies have found, to their
chagrin, that test suites that are developed and.or certified by
the standards body are a terrible idea.  The problem is that
they become the real standard, substituting "passes the test
suite" for "conformance to the standard" or the IETF's long
tradition of "interoperates successfully in practice".

And we have never had a global requirement for "two
implementations to proceed to rfc".

    john

---

From: heasley <[email-masked]>
Date: Tue, 13 Jun 2017 14:28:21 +0000

> suite" for "conformance to the standard" or the IETF's long

reference?

> tradition of "interoperates successfully in practice".

so, both - test suite and a pair of interoperable implementation.

> implementations to proceed to rfc".

Is that only IDR?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 13 Jun 2017 10:50:15 -0700

>>> Having a community-developed test suite for any protocol would

I am not a great fan of the test suite approach. I saw that used in OSI
protocols back in the days, and there are multiple issues -- including
for example special-casing the test suite in the implementation.

To come back to Martin's draft, I think two points are missing. One
about change, and one about grease. First, the part about change. The
Postel Principle was quite adequate in the 80's and 90's, when the
priority was to interconnect multiple systems and build the Internet.
Writing protocols can be hard, especially on machines with limited
resource. Many systems were gateways, interfacing for example Internet
mail with preexisting mainframe systems, and the protocol
implementations could not hide the quirkiness of the system that they
were interfacing. The principle was a trade-off. It made development and
interoperability easier, by tolerating some amount of non-conformance.
As the draft point out, it also tends to make evolution somewhat harder
-- although that probably cuts both ways, as overly rigid
implementations would also be ossified. Martin's draft advocates a
different trade-off. It would be nice to understand under which
circumstances the different trade-offs make sense.

Then there is grease, or greasing, which is a somewhat recent
development. The idea is to have some implementations forcefully
exercise the extension points in the protocol, which will trigger a
failure if the peer did not properly implement the negotiation of these
extensions, "grease the joints" in a way. That's kind of cool, but it
can only be implemented by important players. If an implementation has
0.5% of the market, it can try greasing all it wants, but the big
players might just as well ignore it, and the virtuous greasers will
find themselves cut off. On the other hand, if a big player does it, the
new implementations had better conform. Which means that greasing is
hard to distinguish from old fashioned "conformity with the big
implementations", which might have some unwanted consequences. Should it
be discussed?

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Tue, 13 Jun 2017 15:03:07 -0700

Hi, all,

...
> https://tools.ietf.org/html/draft-thomson-postel-was-wrong-01
I completely agree with John Klensin that a test suite defines the
protocol standard (warts and all).

However, I disagree with the characterization of the Postel Principle in
this doc, and strongly disagree with one of its key conclusions ("fail
noisily in response to...undefined inputs"). Failing in response to bad
inputs is fine, but "undefined" needs to be treated agnostically.

IMO, the Postel Principle is an admission of that sort of agnosticism -
if you don't know how the other end will react, act conservatively. If
you don't know what the other end intends, react conservatively. Both
are conservative actions - in one sense, you try not to trigger
unexpected behavior (when you send), and in another you try not to
create that unexpected behavior (when you receive).

That's the very definition of how unused bits need to be handled. Send
conservatively (use the known default value), but allow any value upon
receipt.

The principle does not setup the feedback cycle in Sec 2; a bug is a bug
and should be fixed, and accommodating alternate behaviors is the very
definition of "be generous in what you receive". "Being conservative in
what you send" doesn't mean "never send anything new" - it means do so
only deliberately.

-----
Failing noisily is, even when appropriate (e.g., on a known incorrect
input), an invitation for a DOS attack.

That behavior is nearly as bad as interpreting unexpected (but not
prohibited) behavior as an attack. Neither one serves a useful purpose
other than overreaction, which provides increased leverage for a real
DOS attack.

Joe

---

From: Dave Cridland <[email-masked]>
Date: Tue, 13 Jun 2017 23:19:25 +0100

> implementations", which might have some unwanted consequences. Should it

I think the pressure of large deployments on smaller ones works in
both good, and more often bad, ways. Within the XMPP community, we saw
this multiple times. Facebook and Google both deployed XMPP services
over the years, and both were larger than the rest of the community
put together. You've described this case as "important players", but
I'd prefer to simply describe them as large.

Facebook's involvement was restricted to client/server (C2S) links,
and in general worked reasonably well, though various custom
extensions were used that performed similar functions to standardized
ones.

Google's service did not support SRV lookups, and mandated the (at the
time) legacy immediate-mode TLS instead of XMPP's standard Start TLS,
for example. This was by design, apparently for security (though
likely for deployment considerations), but had the effect that client
developers often had to hardcode server discovery for the service.

Google did provide S2S peering, but - paradoxically given the above -
did not operate TLS at all, preventing any other service from
mandating TLS for several years. When Google withdrew support for the
service (about four years ago with the introduction of Hangouts), the
community almost universally switched to mandatory TLS within a few
months.

At the same time, Google's S2S peering made heavy use of multiplexing
(known as piggybacking within XMPP), which was unusual at the time,
and could easily cause problems with servers - these servers were
simply forced to update. One might consider this case "virtuous
greasing".

One can very easily look at DMARC as another example of larger players
versus small - DMARC obviously fails to work in the mailing list case
(amongst others), yet the large deployments simply don't care, since
it solves their problems, and to hell with everyone else.

Perhaps standards simply work best in a balanced community?

---

From: Petr Špaček <[email-masked]>
Date: Wed, 14 Jun 2017 17:41:36 +0200

>> https://tools.ietf.org/html/draft-thomson-postel-was-wrong-01

Before I dive into details, let me state I support this documents in its
current form.

> conservatively (use the known default value), but allow any value upon

This very much depends on the the original specification.

If the spec says "send zeros, ignore on receipt" and marks this clearly
as an extension mechanism then it might be okay as long as the extension
mechanism is well defined.

On the other hand, accepting values/features/requests which are not
specified is asking for trouble, especially in long-term. Look at DNS
protocol, it is a mess.

- CNAME at apex? Some resolvers will accept it, some will not.
- Differing TTLs inside RRset during zone transfer? Some servers will
accept it and some not.
...

To sum it up, decision what is acceptable and what is unacceptable
should be in protocol developer's hands. Implementations should reject
and non-specified messages/things unless protocol explicitly says
otherwise. No more "ignore this for interoperability"!

With my DNS-software-develoepr hat on, I very clearly see value of
The New Design Principle in section 4.

Set it to stone! :-)

> other than overreaction, which provides increased leverage for a real

Sorry but I cannot agree. This very much depens on properies of "hard
fail" messages.

If "error messages" are short enough they will not create significantly
more problems than mere flood of random packets (which can be used for
DoS no matter what we). In fact, short predictible error message is even
better because it gives you ability to filter it somewhere.

Also, passing underspecified messages further in the pipeline is causing
problems on its own. (Imagine cases when proxy passes
malformed/underspecified messages to the backend because it can.)

So again, I really like this document. Thank you!

-- 
Petr Špaček  @  CZ.NIC

---

From: heasley <[email-masked]>
Date: Wed, 14 Jun 2017 19:56:04 +0000

> protocol standard (warts and all).

This may be, even if a pair of implementations were required company,
but is that wholly negative?  The test suite is not stuck in time; it can
evolve to test things that its authors had not anticipated, its own bugs,
or evolution of the protocol itself.  It is also more likely to catch bugs
and protocol design flaws than interoperability testing alone.

At the very least, an open test suite allows everyone to test against a
know baseline, before they test interoperation with other implementations.
For example, a rigid test suite that fails when an reserved field is not
its prescribed value, would be an asset for future development that
allocates the field.

Certainly the mentioned JSON problems would have benefitted from a test
suite and interoperability testing.  Clearly, peer review and
interoperability testing are insufficient.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 Jun 2017 16:20:50 -0400

Test suites are often quite useful.
But I can not imagine holding up an I-D from publication while we work 
out a test suite.

Demonstrably, there are cases where we have had trouble because people 
took divergent paths based on liberality in interpretation.
Equally clearly, the liberal acceptance approach has served us well in 
many cases.

Unclear specifications (unclear RFCs) are a problem.  Even Jon's 
oroginal formulation was not, from what I saw, intended to permit sloppy 
writing.  Or sloppy implementation.

There are indeed contexts where an application calling attention to a 
problem is very useful.  Silently ignoring things that indicate trouble 
is usually a mistake (although not always.)

I would be very unhappy to see us take the lesson from cases where we 
were sloppy to be that we should tell everyone to have their 
implementations break at the slightest error.

Yours,
Joel

---

From: Paul Wouters <[email-masked]>
Date: Wed, 14 Jun 2017 16:50:27 -0400 (EDT)

On Wed, 14 Jun 2017, Joel M. Halpern wrote:

> There are indeed contexts where an application calling attention to a problem 
> is very useful.  Silently ignoring things that indicate trouble is usually a 
> mistake (although not always.)
>
> I would be very unhappy to see us take the lesson from cases where we were 
> sloppy to be that we should tell everyone to have their implementations break 
> at the slightest error.

I fully agree. Postel's advise was and is good guidance. It is not a
dogma, and the reverse should also not become a dogma.

Paul

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2017 14:02:21 -0700

On 6/14/2017 12:56 PM, heasley wrote:
> but is that wholly negative?
Not necessarily, but it does negate the need for a specification.

"A designer with one set of requirements always knows what to follow; a
designer with two is never sure" (a variant of "a person with one watch
always knows what time it is...")

If you have a test suite, that singularly defines the protocol to the
exclusion of the spec, otherwise you don't have a complete suite.

>   The test suite is not stuck in time; it can
Interoperability tests are just a variant of test suites - just that
they are all relative to each other, rather than to a single entity.

However, forcing testing to a single entity will necessarily catch less
issues than cross-testing can.

> its prescribed value, would be an asset for future development that

That then begs the question:
    - what happens if my version passes the test suite but fails
interoperability tests?

> suite and interoperability testing. 

But what happens when they provide conflicting results? At that point,
you need to decide which one wins; if that wins, why do the other?

>  Clearly, peer review and
Nothing is ever sufficient unless it is complete, and complete protocol
tests are not feasible for anything other than toy examples. The state
space blows up.

Joe

---

From: heasley <[email-masked]>
Date: Wed, 14 Jun 2017 22:27:35 +0000

> is usually a mistake (although not always.)

I believe that it is always a mistake; it will either bite now or later,
or its not a real error and while ignoring it, real errors are missed.
It should be addressed, whether in your implementation, the test suite,
the spec or the other implementation.  And, to Joe's point of resolving
the conflicts between the those; that dispute is not for the individual
to resolve.  The standards body should determine what the correct behavior
is.  That loop improves the spec, the suite, and interoperability - for
everyone's benefit.

quality, speed, price; pick two.  if you dont pick quality, you will likely
be disappointed - whether beer, brakes or bgp.  testing is a large
contributor to quality.

> implementations break at the slightest error.

That is the suggestion of the draft; i suggest only that a test suite
should follow this - be devilishly rude - about the slightest error.

---

From: Joe Touch <[email-masked]>
Date: Wed, 14 Jun 2017 15:31:10 -0700

On 6/14/2017 8:41 AM, Petr Špaček wrote:
> should be in protocol developer's hands.
That should be in the specification.

What the specification leaves open, implementations should respect and
honor as allowed.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jun 2017 10:44:55 +1200

On 15/06/2017 08:20, Joel M. Halpern wrote:
...
> implementations break at the slightest error.

Indeed. We need implementations to be as robust as possible. That
means careful thought, both in the specification and in every
implementation, about how to handle malformed incoming messages.
There's no single correct answer, as I am certain Jon would have
agreed. Some types of malformation should simply be ignored,
because the rest of the message is valid. Others should cause the
message to be discarded, or should cause an error response to be
sent back, or should cause the error to be logged or reported to
the user. There is no single correct solution.

Clearly the Postel principle was intended as general guidance.

Looking at the core of the draft:

      Protocol designs and implementations should fail noisily in
      response to bad or undefined inputs.

that seems a very reasonable principle for *prototype* and
*experimental* implementations, and a lousy one for production
code, where the response to malformed messages should be much
more nuanced; and the users will prefer the Postel principle
as a fallback.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Jun 2017 09:34:33 +1000

> - CNAME at apex? Some resolvers will accept it, some will not.

Well this is something that should be checked on the authoritative
server when the zone is loaded / updated.  A resolver can't check
this as DNS is loosely coherent.  Delegations can come or go.  Other
data comes and goes.

> - Differing TTLs inside RRset during zone transfer? Some servers will

And we have rules to truncate to the minimum value.

Named fails hard for a number of zone content issues when running
as the master server for a zone which it deliberately ignores when
running in slave mode as the slave operator can't fix them.  That
said if there was IETF consensus that these should be fatal on slave
zones, so that we aren't left to pick up a bad reputation for failing
to serve the zone, it would be easy to change them.

We are already failing to resolve signed zones when validating where
the authoritative servers returns FORMERR or BADVERS or fail to
respond to queries with a DNS COOKIE EDNS option being present.  In
both cases we fallback to plain DNS queries which are incompatible
with DNSSEC.  There are a number of .GOV zone served by QWEST that
fall into this category.  Yes, we have attempted to inform QWEST
for the last 2+ years that their servers are broken.

See https://ednscomp.isc.org/compliance/gov-full-report.html#eo
for zones.  They are highlighted in orange.

If we ever need to set a EDNS flag or send EDNS version 1 queries
the number of zones that will fail on a validating resoler will
increase mostly because too many firewalls default to "these field
must be zero" and drop the request instead of listening to the EDNS
RFC which say to IGNORE unknown flags and to return BADVERS with
the highest version you do support if you don't support the version.

Firewalls are capable of generating TCP RST so they should be capable
of generating a BADVERS response if they don't want to pass version
!= 0 queries.

Note: It doesn't have to resolvers that detect DNS protocol errors.
You can test for these sorts of errors easily and refuse to delegate
to servers that don't follow the protocol.

Resolvers can't continue to workaround every stupid response
autoritative servers return.  They don't have enough time.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Jun 2017 09:54:08 -0400

--On Thursday, June 15, 2017 10:44 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> I would be very unhappy to see us take the lesson from cases
>> where we  were sloppy to be that we should tell everyone to
>> have their  implementations break at the slightest error.
> 
> Indeed. We need implementations to be as robust as possible.
> That means careful thought, both in the specification and in
> every implementation, about how to handle malformed incoming
> messages. There's no single correct answer, as I am certain
> Jon would have agreed. Some types of malformation should
> simply be ignored, because the rest of the message is valid.
> Others should cause the message to be discarded, or should
> cause an error response to be sent back, or should cause the
> error to be logged or reported to the user. There is no single
> correct solution.
> 
>       Protocol designs and implementations should fail noisily
> in       response to bad or undefined inputs.
> 

+1 and exactly right.

It is also a good principle for independently-developed test
suites.  Indeed, I agree with 

--On Wednesday, June 14, 2017 22:27 +0000 heasley
<[email-masked]> wrote:

>> I would be very unhappy to see us take the lesson from cases
>> where we  were sloppy to be that we should tell everyone to
>> have their  implementations break at the slightest error.
> 
> That is the suggestion of the draft; i suggest only that a
> test suite should follow this - be devilishly rude - about the
> slightest error.

But I don't see that as a contradiction: test suites that are
developed by third parties reading standards, deciding what
should be tested, and being brutally narrow about requirements
may be very useful in developing good implementations.  The type
of reading of standards such developments that encourages can
also, if used as feedback, improve the standards.    The problem
arises when test suite (and/or certifications) are produced or
endorsed by the standards developer.  If they are endorsed in
that way, they become alternate statements of the standards
themselves and Joe's observation:

> "A designer with one set of requirements always knows what to
> follow; a designer with two is never sure" (a variant of "a
> person with one watch always knows what time it is...")
> 
> If you have a test suite, that singularly defines the protocol
> to the exclusion of the spec, otherwise you don't have a
> complete suite.

Applies.  If they are independently developed, they are just
like another implementation: two implementations either
interoperate or they do not; an implementation may conform to
the test suite or not but the standard is the standard and the
authority.  It is possible for the text suite to simply be in
error and for things to conform to the test suite but not the
standard.  It is the two sets of requirements that is the
problem.

The I-D notwithstanding, very little of that has anything to do
with the robustness principle, which, as Brian suggests, is
intended for production implementations and much less so for
experiments, demonstrations, prototypes, reference
implementations, etc.   Certainly the robustness principle has
been misused by sloppy or lazy implementers to claim that they
can produce and send any sort of garbage they like and that
recipients are responsible for figuring out what was intended,
but that was never the intent and (almost) everyone knows that,
including most of the sloppy/ lazy (or arrogant) implementers
who would probably behave that way whether Postel had ever
stated that principle [1]. I suggest that one of the reasons the
Internet has been successful is precisely because of sensible
application of the robustness principle.   Not only do things
mostly work, or at least produce sensible error messages or
warnings rather than blowing up, in the presence of small
deviations or errors, but (in recent years at least in theory)
it avoids out having to spend extra years in standards
development while we analyze every possible error and edge case
and specify what should happen.  Instead, when appropriate, we
get to say, when appropriate, "this is the conforming behavior,
if you don't conform, the standard has nothing to say to you,
but you should not depend on its working".  The robustness
principle is important guidance for those edge cases 

That assumes a higher level of thinking and responsibility on
the part of implementers than may be justified in the current
world, but I suggest that the fix is not to abandon the
robustness principle.  Personally, I'd like to see more
litigation or other sorts of negative reinforcement against
sloppy implementations and implementers that cause damage.
YMMD, but there is lots of evidence that standards that try to
cover and specify every case are not the solution (see below).

Finally, because I don't want to write a lot of separate,
slightly-connected, notes...

--On Tuesday, June 13, 2017 14:28 +0000 heasley
<[email-masked]> wrote:

>> chagrin, that test suites that are developed and.or certified
>> by the standards body are a terrible idea.  The problem is
>> that they become the real standard, substituting "passes the
>> test suite" for "conformance to the standard" or the IETF's
>> long
> 
> reference?

Sorry, but I don't have time to do the research to dig that
material out and some of what I found quickly has "members only"
availability.   I speak from a "been there, done that"
perspective, with a background that includes standards
development and oversight body leadership roles in ASNI SDOs,
ANSI, and ISO.  Most of my first-hand experience on that side of
things involved programming languages (including observing a
certain one named after a famous early woman programmer with a
three-letter first name that came, in practice, to be defined
entirely by the test/conformance suite) and, closer to IETF's
interests, some OSI-related protocols in which the effort to
specify ever case led to specifications and profiles that either
were never finished or that became so cumbersome as to be
unimplementable.  I won't claim that is what killed OSI and let
the Internet succeed instead (I think there is a rather long
list of contributors), but it was one element.

best,
    john

[1] I note that we have had some worked examples of software
vendors who have taken the position that they are so important,
or that their ideas have achieved sufficient perfection, that
their systems don't need to conform to standards and that
everyone else, including the standards bodies, just need to
conform to them and whatever they produce.  That behavior can't
be blamed on Postel either, nor can the consequences if the IETF
decides to go along and adjust the standards.

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Jun 2017 08:05:30 -0700

> On Jun 15, 2017, at 6:54 AM, John C Klensin <[email-masked]> wrote:
> 
> I suggest that one of the reasons the
> principle is important guidance for those edge cases.

+1

Further, testing for all those edge cases becomes itself a performance burden on operational code, amplifying the leverage of a DOS attack based on all that excess validation.

The Postel principle helps make achieving the balance between usefulness and correctness tractable.

Joe

---

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Jun 2017 11:28:08 -0700

Brian,

> On Jun 14, 2017, at 3:44 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I agree.

It also seems to me that having implementations "fail noisily in response to bad or undefined inputs" is a great formula to making implementations very fragile and consequently very easy to attack.  Overall, I think the approach outlined in this draft would not have allowed us to build the current Internet.

Bob

p.s. The file name chosen for this draft appears to be a good example of stepping on the toes of those who came before, instead of standing on their shoulders.  See: http://wiki.c2.com/?ShouldersOfGiants

---

From: Christian Huitema <[email-masked]>
Date: Thu, 15 Jun 2017 11:35:47 -0700

> p.s. The file name chosen for this draft appears to be a good example of stepping on the toes of those who came before, instead of standing on their shoulders.  See: http://wiki.c2.com/?ShouldersOf…

On the other hand, there is something to be said for "being nice
considered harmful".

Martin describes a very real failure mode. Implementations deviate from
the standard, gain market share as the deviations are happily tolerated,
and then prevent standard evolution that would contradict their own
"extensions". Martin gives examples of that happening with JSON.

Or, implementations fail to properly implement the extension mechanism
specified in the standard, and then prevent deployments of perfectly
good options. The slow deployment of early congestion notification comes
to mind.

-- 
Christian Huitema

---

From: Mark Andrews <[email-masked]>
Date: Fri, 16 Jun 2017 11:07:04 +1000

In message <[email-masked]>, Christian Huitema writes:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> > p.s. The file name chosen for this draft appears to be a good example
> > of stepping on the toes of those who came before, instead of standing on
> > their shoulders.  See: http://wiki.c2.com/?ShouldersOfGiants
>

DNS and EDNS fall into this category.  The AD bit in responses can't
be trusted as there are servers that just echo back (formally)
reserved bits.  STD 13 says these bits MUST be zero.

Then there are all the servers that fail to do EDNS version negotiation
correctly.  They talk EDNS but ignore the version field or return
FORMERR rather than the specified BADVERS error code. etc.  About
half the servers we have tested get EDNS version negotiation wrong
in one way or another.

When we tighted the unknown EDNS option behaviour (RFC 6891, RFC
2671 under specified the behaviour) updating the EDNS version field
would have been appropriate but we couldn't do this due to the level
of poor implementation of EDNS version negotiation and idiotic (yes,
name calling is appropriate) default firewall rules from multiple
vendors that dropped any EDNS request with a version field that
wasn't 0.

Mark

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Jun 2017 07:55:28 +0200

On 2017-06-15 20:28, Bob Hinden wrote:
> .. > I agree.

There's a distinction between failing as in "catching fire and 
exploding" (bad) and "signalling an error and not processing a request" 
(what Martin is describing).

> p.s. The file name chosen for this draft appears to be a good example of stepping on the toes of those who came before, instead of standing on their shoulders.  See: http://wiki.c2.com/?ShouldersOf…

It was an excellent way to get attention. I think it's excellent that we 
are having this discussion.

Best regards, Julian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Jun 2017 19:50:47 +1200

> (what Martin is describing).

That isn't obvious to the casual reader. But anyway, if you are under DDOS
attack, signalling an error rather than just releasing the mbuf may be all
the difference between system failure and survival*. I think it's very
dangerous to generalise.

    Brian

*That's why I often delete emails unread & unanswered :-)

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jun 2017 03:03:41 -0700

> "extensions". Martin gives examples of that happening with JSON.
Agreed.

It's very important to separate errors that diverge from specification
details from reasonable "wiggle room" created by specification gaps. The
Postel principle addresses the latter, but was never intended to
accommodate the former.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jun 2017 03:06:56 -0700

On 6/15/2017 10:55 PM, Julian Reschke wrote:
>> of stepping on the toes of those who came before, instead of standing
>> on their shoulders.  See: http://wiki.c2.com/?ShouldersOfGiants
>
> It was an excellent way to get attention.
Not necessarily the attention you seek, though.

> I think it's excellent that we are having this discussion. 
The utility of clarifying misconceptions in this doc is clear,
especially if they're shared by others.

Then again, some of us get paid to teach. ;-)

Joe

---

From: Petr Špaček <[email-masked]>
Date: Sat, 17 Jun 2017 16:18:22 +0200

> What the specification leaves open, implementations should respect and

This is exactly the point where our opinions differ.
My point of view is that specification should clearly define extension
points and implementations should:
a) Use Postel's principle within defined 'extension' points.
b) Treat any deviation from documented protocol (including non-defined
aspects of protocol outside of extension points) as an error.

Nice set of reasons for being strict when receiving messages is
described in the following article:

"A Patch for Postel's Robustness Principle",
Len Sassaman, Meredith L. Patterson, Sergey Bratus,
2012 IEEE S&P Journal,
http://langsec.org/papers/postel-patch.pdf

Also, the whole web http://langsec.org/ is an interesting read.

-- 
Petr Špaček  @  CZ.NIC

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Jun 2017 10:26:41 -0400

> aspects of protocol outside of extension points) as an error.

So abort all your HTML pages from loading? 

b) is an error that should be handled in a Postel way and the RFC should
be updated to address the issue. Then maybe years down the line you can be more strict on the failure.

Also the consequences of being strict can be worse. Should a TLS connection fail if the nonce size for the integrity algorithm is too weak? Will the result be a retry using plaintext offers greater risks? What if the connection is for a public webpage? What if it is for a nuclear control channel?

if things were an easy black and white, we wouldn't have this discussion every couple of years.

Paul

---

From: John Wroclawski <[email-masked]>
Date: Sat, 17 Jun 2017 16:15:25 -0700

> Indeed. We need implementations to be as robust as possible. […]
> 
> more nuanced; 

+1

Put another way -

the goal of a _specification_ is to coordinate the actions of multiple, independent implementors, across different circumstances, environments, depths of knowledge, etc. etc. etc.

The goal of an _implementation_ is to serve its users as best as it can when that coordination is not quite perfect.

These are decidedly not the same thing.

cheers, -john

---

From: Randy Bush <[email-masked]>
Date: Sun, 18 Jun 2017 15:05:02 +0900

> the goal of a _specification_ is to coordinate the actions of
> multiple, independent implementors, across different circumstances,
> environments, depths of knowledge, etc. etc. etc.
> 
> The goal of an _implementation_ is to serve its users as best as it
> can when that coordination is not quite perfect.
> 

the problem with do-gooder software is that

  when it tries and fails, you may or may not know it, but it is a real
  mess.  and usually the do-gooder receiver is blamed.

  when it succeeds, no one says thanks, and the incorrect sender goes on
  to find some other implementation to break.

at a minimum, the do-gooder receiver needs to notify the operator that
things are broken.

randy, with a respectful nod to erik naggum

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 18 Jun 2017 10:05:09 +0200

>   to find some other implementation to break.

and thus completely ignoring the "be conservative what you send" part

	jaap

---

From: Petr Špaček <[email-masked]>
Date: Sun, 18 Jun 2017 10:25:48 +0200

> be updated to address the issue. Then maybe years down the line you can be more strict on the failure.

Please let me clarify that can be reasonably applies only to new
protocols or new extensions of existing protocols. We do not have time
machine and I'm not proposing to break existing deployments...

> Also the consequences of being strict can be worse. Should a TLS connection fail if the nonce size for the integrity algorithm is too weak? Will the result be a retry using plaintext offers greater…

To use your example, it might be better to refuse opening a "nuclear
control channel" if it is giving just false sense of security by using
nonce size 1 byte :-)

Now seriously:
If the protocol and strict approach to its implementation was specified
from the very begining (again, this is applicable to new development) we
could easily refuse to open connection because almost all
implementations would do the same, so incentive to fix it would be
significant.

> if things were an easy black and white, we wouldn't have this discussion every couple of years.
Sure. That is why I'm advocating for getting stricter and stricter from
now on.

I hope it clarifies the point. Also, please refer to langsec article
from the previous point, it has a lot to say about security reasons for
stricter approach.

-- 
Petr Špaček  @  CZ.NIC

---

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Jun 2017 13:55:39 +0300

> machine and I'm not proposing to break existing deployments...

I don't think both Netscape and Microsoft wrote their browsers so that
they accepted very malformed HTML just because Postel said so. They
figured (probably correctly) that users would prefer a browser that
worked with all websites to a browser that worked with many websites. 

In fact being liberal in what you accept is a necessity for
implementations and any guidance we give to break the connection will be
ignored. 

Best we can do is to make both the sending and processing of protocol
messages clearly defined in our specs. So for example we should not say
"The Certificate Data field contains an X.509 certificate", but should
instead say "The Certificate Data field contains a DER-encoded X.509
certificate conforming to RFC 5280. The receiver MUST verify that the
content is valid DER and that all required fields are present."

This won't eliminate market forces, but at least it can reduce the cases
where different implementers interpreted the specification in a
different way.

Yoav

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 Jun 2017 13:48:03 +0200

> worked with all websites to a browser that worked with many websites. 

Indeed, dumping the error messages on the human user would have been nonsensical.

Now assume for a second that HTTP had had a backchannel that would have allowed a browser to send error messages back to the server.  Of course, we don’t know whether browser implementer would have provided meaningful messages, and we don’t know whether server implementers would have collected them in a useful way.  And, of course, we also don’t know whether site authors would have had a look at these collected error messages.

Still, I think that this approach would have resulted in less soupifying of HTML than what actually happened.

What can we learn from this thought experiment?

When designing protocols, we can’t sustain the fiction that implementations will be compliant.
Instead, we have to think about what to do with the non-compliance that we’ll encounter.
And we have to think about ways that information about this can flow to a place where it can be acted upon.
(Or, preferably, where there actually are forces that make it likely that it *will* be acted upon.)

(Other points from the current discussion playing into this are:
— be *definite* in what you accept — I think we are getting better at that;
and
— clearly identify (and envelope!) extension points — still much work needed.
There was also a good discussion in the past that extension points need to be regularly exercised, or there will be problems at the time when they are actually needed.)

Grüße, Carsten

---

From: Joe Touch <[email-masked]>
Date: Sun, 18 Jun 2017 11:01:24 -0700

> and thus completely ignoring the "be conservative what you send" part
No part of the Postel Principle says to ignore explicit errors.

The issue is how to treat something unexpected, and the implications
thereof.

If everything unexpected must be loudly rejected (as this doc claims), then:
a) specs will become unnecessarily detailed
b) implementations will be come unnecessarily detailed
c) receivers will be vulnerable to increased DOS attacks

The Postel Principle just tries to get the sender to avoid doing
something unexpected (because it could result in unexpected receiver
behavior), and to get the receiver to avoid over-reacting. It is, in a
sense, the dampener that enables practical protocol specification and
implementation.

IMO, it's somewhat an extension of Shannon's recognition that
communication is about symbol agreement, not semantics or intent.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 18 Jun 2017 11:09:30 -0700

FWIW:

> aspects of protocol outside of extension points) as an error.
You're asking for 10,000 page specifications and 10MB protocol
implementations that are vulnerable to attack.

> http://langsec.org/papers/postel-patch.pdf
I would encourage them to read Shannon/Weaver as well.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Jun 2017 04:31:40 -0700

On Sat, Jun 17, 2017 at 7:26 AM, Paul Wouters <[email-masked]> wrote:

> Also the consequences of being strict can be worse. Should a TLS
> connection fail if the nonce size for the integrity algorithm is too weak?

Not to get too into the weeds, but this isn't a coherent question: In TLS
1.1 and TLS 1.2 [0]
the size of the nonce is associated with the cipher suite and it's encoded
onto the wire
without framing. If the sender uses the wrong nonce size, you just get
integrity failures.

To take an example that's more realistic: yes, browsers do indeed decide
that certain
algorithms (e.g., RC4 or DHE below a certain keylength) are insecure and
refuse to
connect.

-Ekr

[0] TLS 1.3 uses implicit nonces.

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Jun 2017 06:11:47 -0700

> aspects of protocol outside of extension points) as an error.
This, IMO, is where we differ.

Postel's Principle is more an application of Hanlon's Razor:
*Never attribute to malice that which is adequately explained by stupidity.
*http://quoteinvestigator.com/2016/12/30/not-malice/
(replace "stupidity" with "ignorance" or "accident" and the relationship
is more clear).

IMO, the Postel Principle advises two things:
    - don't over react to ignorance/accident
    - don't do things that make others question your motives

These principles apply both to protocol specification and
implementation. It's excessive to explicitly outlaw something that might
be useful and could occur benignly, UNLESS it creates a dangerous or
specifically incorrect result.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jun 2017 11:01:15 -0400 (EDT)

On Mon, 19 Jun 2017, Eric Rescorla wrote:

>       Also the consequences of being strict can be worse. Should a TLS connection fail if the nonce size for the
>       integrity algorithm is too weak?
> 
> Not to get too into the weeds, but this isn't a coherent question: In TLS 1.1 and TLS 1.2 [0]
> the size of the nonce is associated with the cipher suite and it's encoded onto the wire
> without framing. If the sender uses the wrong nonce size, you just get integrity failures.

Ok you caught me on a last minute IKE -> TLS word-smithing change :)

We did run into this in our IKE implementation when going through FIPS
validation. And it seemed no one care that our values were too small
to do SHA2_512.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Jun 2017 09:05:41 -0700

> validation. And it seemed no one care that our values were too small

Maybe we should take this offline, but I'm not really seeing a connection
between
the size of the hash function you are using as the basis for your MAC and
the
size of the nonces.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Mon, 19 Jun 2017 21:26:48 +0300

I think a better example is what does a TLS client (or IKE initiator/responder) do when it receives a certificate chain (OK, it’s a certificate pile that the receiver is supposed to sort) with 17 certificates?

It’s fair to assume that most normal chains will have a root CA, one or two intermediaries and an EE certificate, so a chain of three because the root does not need to be transmitted. Setting an application limit of 5 or 7 or 10 seems reasonable, because reasonable senders don’t have longer chains. AFAICT the only limit set by RFC 5246 is 16 MB for the entire chain, enough for thousands of certificates. Thousands of certificates is either a bug or a DoS attack, but a shorter chain, like 17 certs is not.

By the Postel principle, the receiver should accept this chain. In practice I might limit it to a lower number, because I assume nobody does that. I think it’s best for the specification to say that “MUST support a chain of at least 7 and MUST NOT send a chain longer than 7”, and of course you’d have to say that profiles may further reduce this number (for IoT).

Yoav

---

From: John C Klensin <[email-masked]>
Date: Mon, 19 Jun 2017 19:31:23 -0400

--On Monday, June 19, 2017 21:26 +0300 Yoav Nir
<[email-masked]> wrote:

>...
> By the Postel principle, the receiver should accept this
> chain. In practice I might limit it to a lower number, because
> I assume nobody does that. I think it's best for the
> specification to say that "MUST support a chain of at least
> 7 and MUST NOT send a chain longer than 7", and of course
> you'd have to say that profiles may further reduce this
> number (for IoT).

It seems to me that your example, and some others, suggest that
if the principle was being stated today, it would be "be
conservative about what you send and liberal about what you
accept, but nothing justifies violations of common sense or
taking actions that would create risks".  If the latter/new part
is really needed, we may be in worse trouble than with questions
about what the principle really means or even whether Jon was
right or wrong.

    john

---

From: Petr Špaček <[email-masked]>
Date: Tue, 20 Jun 2017 07:48:13 +0200

> You're asking for 10,000 page specifications and 10MB protocol

We do not understand each other here. Let me explain what I meant in
different terms:

For purpose of this example, please imagine that protocol description
(and sometimes also implementation) is a finite state automata.

Right now, if a edge in the automata is not defined as result of
protocol under-specification, it is up to implementation to decide what
to do, i.e. implementation has to guess sender's intent.

This "guess" part is where I see problems because various
implementations naturally differ in their "guesses" and this is causing
problems later on.

I argue that default action triggered by "imagined missing edge" in our
hypothetical protocol automata should be "report protocol specific error
to sender".

This could be done by adding ~ two paragraphs to protocol specification.
One defining how error message looks like (this is already present in
e.g. DNS spec as FORMERR) and second explaining that non-defined inputs
should be treated as errors. Implementations always has to have some
code to handle erroneous inputs (ala switch { default: } ) as well.
I cannot see the 10 MB of code here.

> implementations that are vulnerable to attack.

Could you elaborate on that? I still do not see how early error
reporting invites DoS. In fact I believe that is is improving overall
situation because smaller set of accepted inputs makes it easier to
handle corner cases and to avoid crash bugs.

> I would encourage them to read Shannon/Weaver as well.

(copied from Message-ID: <[email-masked]>)
> communication is about symbol agreement, not semantics or intent.

We have tried to be liberal in DNS protocol in last 25 years. It
resulted in humongous mess which in the end forces sender to do multiple
guesses until he finds meaning of particular "symbol" for that
particular "receiver". This necessitates means for caching
"receiver-symbol meaning" which brings its own problems. I'm sure that
Mark Andrews can tell you wild stories about EDNS version negotiation.

In other words, we had 25+ years to try this liberal approach in DNS and
now it is time to learn from that experience.

Thank you for your time, I really appreciate it.
Petr Špaček  @  CZ.NIC

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Jun 2017 08:56:11 +0300

> about what the principle really means or even whether Jon was

Yeah, as the joke goes, common sense isn't.  Even assuming it's
prevalent, if you run a survey at the next TLS meeting what is a
reasonable limit for the length of a chain, you'd get a bunch of
different answers. Mine would be 10 because I have seen a real 7-cert
chain in production, but before that I might have said 4 or 5.

Without specifying it any sender has to be really conservative, maybe
limiting themselves to 3 in case there is some receiver out there that
is making severe assumptions. Without this being specified we end up
with receivers planning for 10 and senders limiting themselves (and
their PKI) to 3. This is not optimal.

I am not sure what the take away is. On the one hand under-specifying
creates interop failures, security issues and much complexity to address
issues and fix interop with old and new implementations. On the other
hand, the most successful protocols had a lot of wiggle room, and I
don't think this is coincidence.

Yoav

---

From: heasley <[email-masked]>
Date: Wed, 21 Jun 2017 19:32:41 +0000

> On the other hand, there is something to be said for "being nice

Amen, the author is not being rude - be polite and leave your tender feelings
outside.

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jun 2017 13:29:49 -0700

On 6/19/2017 10:48 PM, Petr Špaček wrote:
> to do, 
I agree. A complete FSM specification, including specific actions for
all undefined combinations of state and input, is what I suggest might
be 10,000 pages and result in a 10MB implementation.
> i.e. implementation has to guess sender's intent.
The Postel Principle provides guidance here. The implementation isn't
supposed to guess the other side's intent - it's supposed to consider
(in some sense) any possible other side intent and act as safely as
possible. This is why I think it helps to refer to Shannon/Weaver, who
take intent out of the picture.

> implementations naturally differ in their "guesses" and this is causing
The Postel Principle, IMO, is about agnosticism. If there is more than
one way to interpret a received message, then consider that before
reacting, and react safely (conservatively).

> hypothetical protocol automata should be "report protocol specific error
A missing edge in a protocol spec isn't defined as an error unless the
spec says exactly that. So reporting that edge as an error otherwise
would be wrong.

> should be treated as errors.
That would result in a very vulnerable protocol, and a good reason why
protocol specifications do not say this.

The most correct thing a protocol FSM could do when receiving an
undefined input is to DO NOTHING. Logging or user reporting might be
useful when debugging, but there is no part of the TCP API that
specifies that all errors are to be reported to the user.

>  Implementations always has to have some
You're correct that adding a "simple" default to report all undefined
inputs would be easy to code, but then you'd have to consider code to do
the reporting, to throttle the reporting when load gets high, etc.
Things get complicated quickly.

> handle corner cases and to avoid crash bugs.

Turn on error full error logging in any kernel and watch performance
drop. Writing messages is a non-zero cost of cycles, storage, and memory
bandwidth. If you report every unexpected message, you're putting up a
very large attack surface - I just have to send you a series of
unexpected messages repeatedly and your system will grind to a halt.

> particular "receiver". 

IMO, you're overdoing the "liberal in what you receive". Liberal means
that if it's possibly valid, you should accept it as such. It does not
mean that all ambiguous messages need to be handled in the best possible
light.

Let's say that DNS says "all domains are lowercase, dash, and dot", and
you get uppercase. Sure, maybe that means convert to lowercase. It also
means you should not crash if you get some other character that isn't
valid - but it also does not mean that you strip invalid characters and
provide a response anyway. Maybe a trailing CR, LF, NL, etc., but not
much else.

So if that's the point, I do agree - it's possible to overdo the Postel
Principle, but IMO that usually requires deliberate intent to make a
mockery of what is otherwise a generally useful principle.

Joe

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Jun 2017 01:04:00 -0400

Joe,

I think we are in agreement -- we have been so far-- but let me
add a real world example that might help clarify some of  this.

--On Thursday, June 22, 2017 13:29 -0700 Joe Touch
<[email-masked]> wrote:

>...
>> We have tried to be liberal in DNS protocol in last 25 years.
>> It resulted in humongous mess which in the end forces sender
>> to do multiple guesses until he finds meaning of particular
>> "symbol" for that particular "receiver". 

> IMO, you're overdoing the "liberal in what you receive".
> Liberal means that if it's possibly valid, you should accept
> it as such. It does not mean that all ambiguous messages need
> to be handled in the best possible light.

I would have been even more restrictive and said "possibly valid
and generally unambiguous".  Taking SMTP as an example, not just
because because it is one of the classic robustness principle
cases but because there is a long history of reasonable
applications of the principle and an equally long on of
unreasonable applications including situations in which senders
have claimed "be liberal about what you accept" allows them to
send complete nonsense and, if things then don't work, to claim
that is the receiver's fault (see my earlier comments about
common sense).

Prior to the introduction of the extension mechanism in RFC
1651, the spec said that the command that specifies recipients is
   RCPT TO:<forward-path>
Now, putting a space after the colon is a really common error.
The robustness principle is properly applied to just let that
go; there is no possible ambiguity about what was intended.  I
don't recall ever seeing "RCPTTO:", rather than "RCPT TO:", but
accepting it in the name of liberal acceptance would be
similarly reasonable although I'm not sure it would justify
redesigning a command parser just to allow it.

The question of whether the receiver should generate an error
reply if the brackets are omitted or should just assume them was
an argument that went back and forth for years.  It is an odd
case, because they are less easily overlooked in the specs than
someone not reading the BNF (821) or ABNF (2821 and 5321)
carefully enough.   But that is connected to another issue with
the robustness principle that I don't think has been discussed:

For some years, there were a few SMTP implementations around
that assumed that, since the syntax was as above, they could put
things into the command after the forward path and closing
bracket and have them treated as comments.  It got all the
predictable reactions: Some servers (receivers) just didn't
notice anything past the ">" and hence applied liberality in
acceptance accidentally.  Others applied it deliberately on the
assumption that ignoring noise was reasonable.   And still
others generated syntax replies, perhaps on the theory that
additional text might be an extra address or something else they
didn't know how to handle reliably.   Those choices needed to
come to an end with RFC 1651 because we needed to allow text
after the ">" for something specific.   That forced us to invent
a new session-starting verb rather than just dropping extra
syntax at the end, but that was (at least IMO) a relatively
small price to pay for giving receiver implementations (who
would be blamed, fairly or not, if messages didn't go through)
permission to use their judgment about how flexible to be. 

> Let's say that DNS says "all domains are lowercase, dash, and
> dot", and you get uppercase. Sure, maybe that means convert to
> lowercase. It also means you should not crash if you get some
> other character that isn't valid - but it also does not mean
> that you strip invalid characters and provide a response
> anyway. Maybe a trailing CR, LF, NL, etc., but not much else.

Somewhat in parallel with the SMTP case, it also doesn't mean
that, when "lowercase" doesn't automatically mean "lowercase
ASCII letters", that, in the general case, you don't get to
receive "á" or "č" and decide that the accent and caron are
superfluous so you can change them to, or interpret them as, "a"
and "c".    But, again, "be liberal" means to exercise
reasonable judgment about flexibility of interpretation.  It is
a requirement for thinking and understanding, not a requirement
that one be stupid or irresponsible.

> So if that's the point, I do agree - it's possible to overdo
> the Postel Principle, but IMO that usually requires deliberate
> intent to make a mockery of what is otherwise a generally
> useful principle.

Yep.

    john

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 23 Jun 2017 09:25:13 +0000

Joe Touch wrote:
> Liberal means that if it's possibly valid, you should accept it as such.

That necessitates the protocol designer explicitly flagging some things as invalid. Obvious example is a should be signed message lacking a signature. If taking the most liberal view (as above) the protocol needs to say something like "if the signature is missing or invalid, then the message must be rejected". I don't think that's anything new, I've seen it done.

I can see at least the following cases where making intent clear is, in my opinion at least, a good idea:
- Security and other sensitive cases of failure. Need to say explicitly reject.
- Mechanisms designed for extensions. While the Postel principle makes it unnecessary to say so, it really doesn't hurt saying that a message shouldn't be rejected just for this reason.
- Where what you receive is a container of multiple things (messages in a packet, TLVs in a message). Making the assumed dependence/independence clear doesn't hurt (if rejecting/ignoring one, does this impact on the others?).

That's not something that spirals out of control in size, a couple of sentences would cover most cases.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jun 2017 10:33:26 -0700

Hi, John,

On 6/22/2017 10:04 PM, John C Klensin wrote:
> Joe,
>
> I think we are in agreement -- we have been so far-- 
We are.
> but let me

Your example makes a good point - my interpretation of that is "don't
rely on half of the Postel Principle".

> ... there is a long history of reasonable
They need to "be conservative in what you send".

The principle cuts both ways.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jun 2017 10:35:36 -0700

On 6/23/2017 2:25 AM, Dearlove, Christopher (UK) wrote:
> That necessitates the protocol designer explicitly flagging some things as invalid. 
That's quite typical. Many protocols clearly indicate explicit invalid
cases.

> Obvious example is a should be signed message lacking a signature. If taking the most liberal view (as above) the protocol needs to say something like "if the signature is missing or invalid, then the message must be rejected". I don't think that's anything new, I've seen it done.
>
When not specified, "silently ignore" is another option.

Agreed.
> That's not something that spirals out of control in size, a couple of sentences would cover most cases.
Right - the Postel Principle isn't a license to be lazy in either a
protocol spec or implementation.

Joe

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 26 Jun 2017 08:52:27 +0000

Explicitly reject vs silently ignore. I took the latter to be a an instance of the latter, because I meant explicit in terms of the specification, not the implementation. Wording could obviously have been better. I could see rejection being noisy, silent or somewhere in between.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 3300 467500  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: 23 June 2017 18:36
To: Dearlove, Christopher (UK); Petr Špaček; [email-masked]
Subject: Re: I-D Action: draft-thomson-postel-was-wrong-01.txt

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Agreed.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Jun 2017 13:07:50 -0700

On 6/26/2017 1:52 AM, Dearlove, Christopher (UK) wrote:
> Explicitly reject vs silently ignore. I took the latter to be a an instance of the latter
I'm guessing you meant "I took the former as an instance of the latter".
> , because I meant explicit in terms of the specification, not the implementation. Wording could obviously have been better. I could see rejection being noisy, silent or somewhere in between.

I was working off your term "reject" - which is IMO quite different from
"ignore" (more than the difference between "explicitly" and "silently".

Reject usually means some other action is taken, e.g., requiring an
alert to the user, a change in the protocol state, or a response
protocol message.

Joe

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 27 Jun 2017 08:53:43 +0000

OK. I want(ed) a term covering both. I just took a look at a draft standard (not an IETF one, but uses several RFCs, so it's partly from that culture) and it uses the formulation "the message is invalid".

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: 26 June 2017 21:08
To: Dearlove, Christopher (UK); Petr Špaček; [email-masked]
Subject: Re: I-D Action: draft-thomson-postel-was-wrong-01.txt

Joe