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

[Martin Thomson <[e-mail]>]

I agree with Joel here.  A lot of this comes down to circumstances.  RFC 7606 shows how BGP does it and there are almost as many different rules as there are TLVs.

But I think the important thing is, as Joel notes again: this needs to be written down so that implementations behave consistently and predictably.  And the spec needs to match what is actually deployed, unlike pre-RFC 7606 BGP where the spec said one thing and basically everyone did something else.

The extensibility piece is pretty well-trodden ground already, but again spec and deployment should agree.

On Fri, Jul 15, 2022, at 11:06, Joel Halpern wrote:
> 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
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss