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

John C Klensin <> Tue, 28 May 2019 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBB5C120179 for <>; Tue, 28 May 2019 09:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H-G0wCW2gxYd for <>; Tue, 28 May 2019 09:04:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ACAE120155 for <>; Tue, 28 May 2019 09:04:47 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1hVeaj-000MoE-BY; Tue, 28 May 2019 12:04:45 -0400
Date: Tue, 28 May 2019 12:04:38 -0400
From: John C Klensin <>
To: Martin Thomson <>,
Message-ID: <720A7A1304B044F5791A766D@PSB>
In-Reply-To: <>
References: <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Tue, 28 May 2019 16:04:50 -0000

Martin and IAB,

I would encourage approaching this area with some care.  

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

FWIW, one of the reasons those protocols have survived was
repeated judicious applications of the robustness principle,
something you appear to want to deprecate, presumably to be
replaced by this document and its relatives.  Again, in
retrospect, 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.  

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.


* Procedurally, it seems extremely odd to me  for the IAB to be
actively considering, and encouraging the community to consider,
an expired I-D.  At the very least, it shows disrespect for
BCP-level procedures about the status of documents.  Or it tells
the community that the IAB considers itself to be exempt from
community consensus about such documents and their relationship
to more permanent and stable publications.

* The most common argument for choosing citation anchors that
use mnemonic terms is to make it easier for the reader to
understand and remember what is going on, something that many of
use actually prefer to using, e.g., "RFCnnnn" as anchors.  But,
in that context, please do not refer to RFC 5822 as "SMTP".  It
(and its predecessors RFC 2822 and 822) are never referred to as
SMTP, a term that belongs fairly exclusively to RFCs 821, 2821,
and 5821 and their extensions and derivatives.  Use of "SMTP" to
refer to Message Format documents is likely to either cause
confusion or to cause that document (and possibly you and/or the
IAB) to be dismissed as ignorant.  Try "MsgFormat",
"EmailMsgFormat" or something else.


--On Tuesday, May 28, 2019 19:47 +1000 Martin Thomson
<> wrote:

> The IAB will discuss adoption of
> draft-thomson-use-it-or-lose-it at its meeting on 2019-06-12.
> The draft can be found here:
> The agenda for the meeting will be posted 48 hours ahead of
> the meeting here:
> Feedback about this draft can be sent in response to this mail
> on, or to the IAB directly at
> _______________________________________________
> Architecture-discuss mailing list