Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-08.txt

[Joel Halpern <[e-mail]>]

I suspect that the correct answer from a design perspective depends upon 
other aspects of the protocol.

It is clearly reasonable for the protocol designers as part of the spec 
to say "malformed messages MUST be ignore", or even "malformed messages 
MUST result in a connection reset" (whatever connection means).  if the 
WG writes that in, then that is the correct response.

Whether the WG should write those rules, or other more permissive rules, 
depends I expect on the consequences of problems.  For example, one 
could also write a rule that says that any duplicate or out of order 
TLVs cause the rest of the TLVs to be ignored". Thus allowing efficient 
parsing but not causing as much disruption.  Whether that is right or 
wrong depends upon the implications of the choices.

I can imagine a whole range of nuances and possibilities.

The more interesting case from a protocol robustness point of view is 
what a receiver should do when everything looks right, but the specific 
type code is not understood.  I would again hope that the spec answers 
that question.  But I would also hope and expect implementors to fall 
back to the robustness principle when and if the spec doesn't say.

Yours,

Joel

On 7/14/2022 8:46 PM, Eric Rescorla wrote:
> I'm finding myself a little unsure on where exactly to locate
> the disagreements here. Perhaps a hypothetical would help.
>
> Suppose we have a protocol that consists of a set of tag-length-values
> fields. A message consists of a length field followed by a list of
> TLVs.  The protocol defines the following requirements for how a
> message is constructed:
>
> 1. A given tag MUST only appear once
> 2. TLVs MUST appear in ascending tag order (this can help
>    detect violations of the previous condition)
>
> Question 1: How should implementations behave upon receiving the
> following messages, absent any other spec guidance?
>
> - Tags: 1, 2, 2  [Violates rule 1]
> - Tags: 1, 3, 2  [Violates rule 2]
>
>
> Question 2: Should we provide specification guidance for how to handle
> these rule violations, and if so, how?
>
> Question 3: Do you think the answers depend on other properties of the
> protocol? If so, what are they?
>
> -Ekr
>
>
>
> On Tue, Jul 12, 2022 at 4:44 PM Brian E Carpenter 
> <[e-mail]> wrote:
>
>     I still find it hard to accept that there is community consensus for
>     this document as it stands. Most of what its says is correct but it
>     still seems to unreasonably claim universal scope.
>
>     Some suggestions:
>
>     Title: The Robustness Principle May Have Harmful Consequences
>
>     Last sentence of Abstract:
>     For some types of protocol that are actively maintained, the
>     robustness principle can, and should, be avoided.
>
>     And a few changes in the main text such as:
>     OLD:
>     Time and experience shows that negative consequences to
>     interoperability accumulate over time if implementations apply the
>     robustness principle.
>
>     NEW:
>     Time and experience shows that negative consequences to
>     interoperability sometimes accumulate over time if implementations
>     apply the robustness principle.
>
>     Even with changes like this, I'm not sure everyone will agree.
>
>     Regards
>         Brian Carpenter
>
>     On 12-Jul-22 10:30, [e-mail] wrote:
>     >
>     > A New Internet-Draft is available from the on-line
>     Internet-Drafts directories.
>     > This draft is a work item of the Internet Architecture Board
>     IETF of the IETF.
>     >
>     >          Title           : The Harmful Consequences of the
>     Robustness Principle
>     >          Authors         : Martin Thomson
>     >                            David Schinazi
>     >    Filename        : draft-iab-protocol-maintenance-08.txt
>     >    Pages           : 15
>     >    Date            : 2022-07-11
>     >
>     > Abstract:
>     >     The robustness principle, often phrased as "be conservative
>     in what
>     >     you send, and liberal in what you accept", has long guided
>     the design
>     >     and implementation of Internet protocols.  The posture this
>     statement
>     >     advocates promotes interoperability in the short term, but can
>     >     negatively affect the protocol ecosystem over time. For a
>     protocol
>     >     that is actively maintained, the robustness principle can, and
>     >     should, be avoided.
>     >
>     >
>     > The IETF datatracker status page for this draft is:
>     > https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/
>     >
>     > There is also an HTML version available at:
>     >
>     https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-08.html
>     >
>     > A diff from the previous version is available at:
>     > https://www.ietf.org/rfcdiff?url2=draft-iab-protocol-maintenance-08
>     >
>     >
>     > Internet-Drafts are also available by rsync at
>     rsync.ietf.org::internet-drafts
>     >
>     >
>     > _______________________________________________
>     > I-D-Announce mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/i-d-announce
>     > Internet-Draft directories: http://www.ietf.org/shadow.html
>     > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>     _______________________________________________
>     Architecture-discuss mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/architecture-discuss
>
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss