Re: [arch-d] Comments on draft-iab-protocol-maintenance

Just throwing my .02 in -

My experience in HTTP and other application protocols leads me to nod my head a lot when reading this draft. 

The biggest problem we see when the robustness principle is relied upon is that implementations make different decisions regarding what is reasonable, resulting not only in interoperability problems, but security issues (e.g., HTTP response splitting).

As the draft alludes to, the robustness principle is attractive when you're trying to make progress in the early stages of a protocol's development; completely covering the corner cases is indeed hard. The problem is that those 'loose' areas become the new definition of interoperability, and they're not well-defined. Cleaning them up after the fact becomes very difficult. 

One factor that the draft doesn't talk about much is the size of the implementation pool, and I think it might be the source of much of the disagreement here. When there are only a few implementations and everyone can get in touch with each other, the robustness principle might be sufficient for that community (although it has the effect of _requiring_ a small pool, thereby insulating against 'outsiders', which is not great - the draft does talk about this some). When the pool is larger -- for example, HTTP, HTML, etc. -- it's completely impractical to downright dangerous.

Regarding formal verification - see also: 
  https://arxiv.org/abs/1810.04755
  https://github.com/RFCNLP

I know that some of the authors as well as other academics are interested in improving RFCs along these lines. If we wanted to start a conversation I'm pretty sure they'd participate.

Cheers,

> On 19 Jul 2022, at 12:18 am, Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hi Martin,
> 
> Thanks for spending the time on this document.
> 
> I am broadly supportive of the approach that is recommending, i.e., when it comes to protocol design, explicit is better than implicit.
> 
> A few comments, which given it is an IAB document and not an IETF document, you are free to do with as you wish ;-)
> 
> 1)  Abstract: "For a protocol that is actively maintained, the robustness principle can, and should, be avoided."
> 
> I can see how some people find this sentence to be contentious and inflammatory.  I think that there is a strong argument to say that various IETF routing protocols are actively maintained, implementations are seemingly built around the robustness protocol, and that arguably they have been successful.  This document almost suggests that they protocols should move away from that to strict checking, but it is unclear that would be a good change to make.  They could do it for new extensions, but it is unclear whether ending up in a hybrid of strictness would ever really make sense.
> 
> 
> 2) For a newly designed protocol, I broadly agree with the suggestion that it is much better to have strict implementations to quickly find and remove bugs in the specifications and implementations.  However, I'm sure that there are cases where the initial specification is weaker, and the initial implementations won't follow the advice in this draft, particularly when there's time/cost pressures to ship something quickly.
> 
> If another implementation comes along, particularly from a smaller vendor, then as has been previously pointed out, there often isn't really any choice but to interoperate with what has already been deployed.  I would suggest that in these scenarios it may be better to have an implementation that defaults to a strict interpretation of the protocol RFC but has one or more configuration options to allow an operator to enable interoperability with existing implementations where needed.
> 
> 
> 3) Having had the pleasure of reading and reviewing many protocol specifications as an AD, I am always surprised that so many protocols, many of which are primarily intended to distribute some state between two or more entities in a semi-efficient way, end up being written as text descriptions of packets, fields, TLVs, behaviour, error handling, etc.  Each of these protocol drafts document these behaviours in entirely different ways, focussing on different aspects to specify, broadly left to the imagination and experience of the authors.  I suspect that many of these specifications are incomplete w.r.t to corner cases and error conditions.
> 
> Probably out of scope for this draft, but I've long thought that having these more formally specified in a data modelling language with formal constraints on the valid data, and a standard set of behaviours for republishing minimal subsets of what has changed, would likely to be a better place to end up, particularly if tooling can then automatically generate efficient code to encode/decode protocol data, efficiently republish minimal changesets, and validate the received data in an efficient way.  RIFT is probably a step in the right direction by making use of Thrift (although I question how stable the Thrift definition/specification really is, and I presume probably doesn't support any validation beyond existence and type checking).
> 
> If some cases, a tight hand-written specification of protocol fields is justified, where every bit saved make sense, but for many other protocols, e.g., where the protocol data is being processed in userland processes rather than in the kernel or NPUs, then formally specifying the data model and constraints, and using a standard encoding (e.g., CBOR) may be a better pragmatic choice.
> 
> Regards,
> Rob
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss

--
Mark Nottingham   https://www.mnot.net/