Re: [arch-d] Adoption of draft-thomson-use-it-or-lose-it

["Martin Thomson" <[e-mail]>]

Apologies for taking so long to reply; illness kept me otherwise occupied.

On Wed, May 29, 2019, at 02:04, John C Klensin wrote:
> While I applaud your, and the IAB's, efforts to try to sort
> these things out and provide guidance, I see some danger of the
> IAB, with this document and others, moving off in the direction
> of grand pronouncements that are disconnected with reality;
> comments that seem to imply that, if only the IAB's statements
> and procedures are followed, all will be well.  

I will concede that the advice for active use is firm, but that is derived from examples of where strong dependencies on the extension function correlates very well with a history of good availability of extensibility.  If you have a counter-example, that would be worth hearing about.

The other advice is hedged.  We don't really know if this greasing thing will work, though it was shockingly effective at revealing problems when it was first tried.

If you think that this comes across too strongly, it might help to be more specific.  A pull request to https://github.com/martinthomson/use-it-or-lose-it would be the best way, but I'm happy to discuss text changes as you see fit.

> I think a
> careful look backward would suggest that some protocols whose
> design does not follow the recommendations you are making have
> stood the test of time (IMO, the ultimate criterion for success
> in a protocol is its survival in active use for decades) while
> others that come closer to the criteria you suggest have
> disappeared almost without a trace.  It took us well over a
> decade to retrofit an extension mechanism into SMTP and, while
> neither it nor IPv4 reflect the types of mechanisms you seem to
> be suggesting, but seem to still be serving us moderately well
> (or, if they are not, millions of, probably a billion or more,
> Internet users don't seem to be noticing.  Could we do better in
> retrospect?  Almost certainly but only in retrospect and with
> the ability to apply many years of experience.  

It's interesting that you chose to mention IPv4 here, which has been in what you might describe as "extended support" for decades.  IPv4 has very few of what we might regard as extension points, but it might be worth looking at a few examples where it supports extension:

* Version: do you really think that the use of the version field is successful.  Aside from the example in the draft about layer 2 ossification, I doubt that anyone sane would contemplate use of this field.
* Protocol: That QUIC is using UDP here indicates that we've lost this one.  And I agree that this wasn't from lack of use.  SCTP (and to a lesser extent DCCP) are real protocols that use different values for this field, but it would have taken crypto to prevent middleboxes from fixating on this one.
* Options: Not my area, but everything I've found only suggests that these are dead.  RFC 6814 killed most of these.

Now, much of the desire to extend IP has been channeled to IPv6, but I hear that options are similarly endangered there.

> FWIW, one of the reasons those protocols have survived was
> repeated judicious applications of the robustness principle,

I would argue that they have survived more because they are useful, and that they have survived *despite* the repeated use of the robustness principle.  In the case of IPv4, the depth of the hole you can dig by doing that is limited by the very constrained header syntax.

> one could probably design or define protocols to
> avoid needing it but it is not clear to me that one can do that
> type of specification prospectively without so overspecifying
> things as to risk making the resulting protocol unusable, so
> slow to be completely designed and approved that circumstances
> pass it by, or so rigid that implementations feel a need to
> ignore it and make their own solutions.  

I disagree.  Successful interoperation requires that a specification define bounds on behaviour of protocol participants fully.  But that doesn't automatically imply inflexibility, just that the flexibility be carefully prescribed.  That doesn't mean overspecifying the protocol.

As for speed, that's definitely a problem.  The pressure to ship means that the first version is unlikely to properly cover all cases.  Iterating might be the only remedy.  Yes, a full specification first time around is costly, but you can get close and then iterate and improve.  Any given version might be too strict or too lax in different ways, but subsequent versions can rectify that.

> My other, related, concern is that the Internet has a rather
> large population of embedded devices, a population that will
> certainly rise as more and more IoT devices deploy.  The
> developers of such devices probably need to be much more
> cautious than we have often seen when they start burning
> protocols into silicon or even firmware, but those devices are
> likely to leave us a choice between strict backward
> compatibility and either putting the IETF in the position of
> causing many devices to stop working or being ignored.  We also
> need to remember that, especially for smaller and less expensive
> embedded devices and those that are required to be very robust
> (IoT and otherwise), mechanisms for updating raise costs,
> security risks, or both, especially if they do not require
> physical changes or non-network connectivity.   When I compare
> that perspective to this document, it appears to need some
> rather significant work.

It seems like this comment might be directed at a different document.  But I think that this supports the thesis of the draft.

As an aside, I'm of the view that deploying networked devices that can't be updated is flat out irresponsible.  See also RFC 8240 and the work on making updates more secure and manageable (SUIT WG).

That said, even where updates are possible, it might be the case that fixes for protocol problems like extension intolerance aren't a high enough priority that other actors in the system can rely on them being deployed.  But that just supports the thesis of the draft.  Extensibility was not a feature that was considered sufficiently important to ship, so extensibility is not a feature you get to use.  If the devices depended on extensibility working, then it would probably be available to others.

The canonical case here is a device that explodes rather than ignoring an extension that must be ignored if it isn't understood.  We have hit this often enough in TLS for it to be pretty well understood.

> * Procedurally, it seems extremely odd to me  for the IAB to be
> actively considering, and encouraging the community to consider,
> an expired I-D.  

My fault. https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-03 expires soon, and would not have expired prior to the date of our original planned discussion date.  But I failed to send this notice early enough, and then included a link to the -00 by mistake.  I will post an update.

> please do not refer to RFC 5822 as "SMTP".

Again, that's an error on my part.  It's all email to me.  I welcome the correction.