Re: [arch-d] Adoption of draft-thomson-use-it-or-lose-it
John C Klensin <john-ietf@jck.com> Tue, 28 May 2019 16:04 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5C120179 for <architecture-discuss@ietfa.amsl.com>; Tue, 28 May 2019 09:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-G0wCW2gxYd for <architecture-discuss@ietfa.amsl.com>; Tue, 28 May 2019 09:04:47 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACAE120155 for <architecture-discuss@ietf.org>; Tue, 28 May 2019 09:04:47 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) 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 <john-ietf@jck.com>
To: Martin Thomson <mt@lowentropy.net>, architecture-discuss@ietf.org
Message-ID: <720A7A1304B044F5791A766D@PSB>
In-Reply-To: <19b3da4b-bc51-4b5d-baec-c2d9c4d5db5d@www.fastmail.com>
References: <19b3da4b-bc51-4b5d-baec-c2d9c4d5db5d@www.fastmail.com>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/5l8fHDJHrthF9VaV7Irri-NPQtQ>
Subject: Re: [arch-d] Adoption of draft-thomson-use-it-or-lose-it
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=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. Nits: * 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. regards, john --On Tuesday, May 28, 2019 19:47 +1000 Martin Thomson <mt@lowentropy.net> 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: > https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-00 > The agenda for the meeting will be posted 48 hours ahead of > the meeting here: https://www.iab.org/wiki/index.php/Agenda > > Feedback about this draft can be sent in response to this mail > on architecture-discuss@ietf.org, or to the IAB directly at > iab@iab.org. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss
- [arch-d] Adoption of draft-thomson-use-it-or-lose… Martin Thomson
- Re: [arch-d] Adoption of draft-thomson-use-it-or-… John C Klensin
- Re: [arch-d] Adoption of draft-thomson-use-it-or-… Joe Touch
- Re: [arch-d] Adoption of draft-thomson-use-it-or-… Bernard Aboba
- Re: [arch-d] Adoption of draft-thomson-use-it-or-… Joe Touch
- Re: [arch-d] Adoption of draft-thomson-use-it-or-… Martin Thomson
- Re: [arch-d] Adoption of draft-thomson-use-it-or-… Brian E Carpenter