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

"Martin Thomson" <> Mon, 03 June 2019 04:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22E4F12012C for <>; Sun, 2 Jun 2019 21:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=dkFLHEtp; dkim=pass (2048-bit key) header.b=RsQwNfJ7
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wQyFvAY68Jio for <>; Sun, 2 Jun 2019 21:45:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35D3D120129 for <>; Sun, 2 Jun 2019 21:45:07 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 8065F21FC3; Mon, 3 Jun 2019 00:45:06 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Mon, 03 Jun 2019 00:45:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=99kbFywu3Pq7LHfAr+zxCcg2jQqI1E0 CeaWVG7I7Bjo=; b=dkFLHEtpjL5/kx8djjppAFXmxvF6Um5T4+LQu0JsrpfAs5s OCh8nlLXItiwETVLxeTAN4lN5k0f7fmvJscjTjiDYSiKvXucv4C1MEtjIwsDLTcr MezfOf746QEwYo024Oo4ZnB82oHAbKfevkg1zqP70BhmBom51XWaKHZ/5IO21uVN uqVeZo0wfwDQ1zICwEL6Jo7iE+JnO1EodH0mEMPhn+8sll/EUUVPYP7KKEDIBLFc H0AiA7bqVtk6T1ayfNZXb0lcDCB8HLo9OLLd9sEWSXKNttDdJOvNRWIzkRXJxXcb 2kYWjO0ImaIQABalSMKIv4McfOTRpFePi2O1PpA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=99kbFy wu3Pq7LHfAr+zxCcg2jQqI1E0CeaWVG7I7Bjo=; b=RsQwNfJ7hRYUKD4DdhZYiB 8qhyLq3xwQIjCEACkT6ioye9exEz/0PEijKxwl1tgitGrX1D4R42QjEe/B1EolW2 zrK/GWxkEJ0RanGWoQNdr6PiDMwJ0qW9yAC/Qd075H4LTZ7GGhHZXrp2BjaX8glj fLWWeYqMVH4mh7QiUsjxr6Rz0PdEQ60gj2pX9EyYucb6SJjNStqFapLTJukuFIaV ODhAArmBJJ31F432GrJ3z2FaTvY4W1EUDbI8qDCjvq26GsktPw553dqY1pW1r9Fh ilQwfHSSXpuNEWkPjuXM+eQdX+riKYwuO1x/59MBajAtqm99i3W5Ptfs6OffEcRw ==
X-ME-Sender: <xms:0aX0XH-PIhNqYc1ondpY7_S2p5Hdz0N8OYuTl52Klxfgs77c49Q0iQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefiedgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:0aX0XH8o3D6k5ArqXjT8nPDSr0fndXWd5ALfVOIPTuLm2AOPpMcSMg> <xmx:0aX0XABF3sgz4Gn1ihwCojMcYPWm5sOz87CzpJsy0sZUs5F0V8H1Bg> <xmx:0aX0XHxqoOP6NZ3iQFYQZHiWkh42DwFhSle4uyMTqOnwMqGWVSjQfw> <xmx:0qX0XDJ-lG5qdKVPztOps5xD1ujOGM979LRauyCI0lRzzxOLLflPsA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B3C75E00A1; Mon, 3 Jun 2019 00:45:05 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-555-g49357e1-fmstable-20190528v2
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <720A7A1304B044F5791A766D@PSB>
References: <> <720A7A1304B044F5791A766D@PSB>
Date: Mon, 03 Jun 2019 14:45:05 +1000
From: Martin Thomson <>
To: John C Klensin <>,
Content-Type: text/plain
Archived-At: <>
Subject: Re: [arch-d] Adoption of draft-thomson-use-it-or-lose-it
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Jun 2019 04:45:10 -0000

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 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. 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.