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

Bernard Aboba <bernard.aboba@gmail.com> Tue, 28 May 2019 17:25 UTC

Return-Path: <bernard.aboba@gmail.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 8C2FE12022E for <architecture-discuss@ietfa.amsl.com>; Tue, 28 May 2019 10:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 OPJrd9tCI2Gk for <architecture-discuss@ietfa.amsl.com>; Tue, 28 May 2019 10:25:14 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87942120198 for <architecture-discuss@ietf.org>; Tue, 28 May 2019 10:25:13 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id q62so18489739ljq.7 for <architecture-discuss@ietf.org>; Tue, 28 May 2019 10:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SVjWDcl6o8eh2ZjRL/ts2Wvne7CT1ebFc1W24JW4+7g=; b=pdrfMYSwaDXipSA3pWk/yuUf0SdLqXSvzf/CPEAU+b2f9UU2tB3QQW01jn3/8LaaGm U0MmstRkhMlJD1Y1w1N00c036bqbFQ2jC7Q2k8poB8btYXDWyykXIYbG+4TZhbLdcqOD VpbdGodGsPMQekTp/WMwy3ZcBD6gewy4PJ4w0BYgzheWdX7jb1oXX007DBlC/pg4JHhr iVmQnP9xiOR00mqBPMV2XLHUozfF1XTOeG1qPrWYMIHuXhxghIuIjMAGdLISG5i6UiAb VXdzAeY2HQlGdxeHIZaz7jeu/gTLK/0yIOV7jPOZ1+pwbVKO+b6ZKyRUZAGRp0kk9jLq nJbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SVjWDcl6o8eh2ZjRL/ts2Wvne7CT1ebFc1W24JW4+7g=; b=r7tSfOUaW6RTwROq3nNdw4tOozpIrSvnubjEffIjKWD4E3lNNbrJWsuZrFHfpbW3t1 Taqzw6eW82cFVzfD92JEAz5XBK+iSOJsBbxSkA28IulJhHT77WxIzzpQ0qARy1w8jNv3 uBfDKMPXGxgeVvjH1GF3QSbiasnMrTAiLt3+OT9GY1P44HafhRpbLagTRBBkv2/yeQ+v l8ttixOpXWiQ9AAwYNabHq74c8UJZcNH6f4n64Pbdcckf0cjAMwAbGymgHYfrJd16wAU DmywD4DTBfoDDUcQD/8uAl76ROd7CSVRBAgjHb89HgLOpMbRavi+GLIwrDugj04Rz6Ab F+Ig==
X-Gm-Message-State: APjAAAV96/Crhd2RS4MmKCdr3eD9FGbg3cl7yKlRGJ08YNVgXwepvk8a zdutH+TvHYSu4Z3dBw7rXzZ037KCW/7oZzJfgRg=
X-Google-Smtp-Source: APXvYqyyvCtPfAggOZSGTTuY8n3at2isX5Ty0cOT5ebwVDKn5skgZPNrHdkbHpuQleWewI3i+SEK9xU6dQaF0GEWkco=
X-Received: by 2002:a2e:8909:: with SMTP id d9mr17428820lji.93.1559064311373; Tue, 28 May 2019 10:25:11 -0700 (PDT)
MIME-Version: 1.0
References: <19b3da4b-bc51-4b5d-baec-c2d9c4d5db5d@www.fastmail.com> <720A7A1304B044F5791A766D@PSB>
In-Reply-To: <720A7A1304B044F5791A766D@PSB>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 28 May 2019 10:24:58 -0700
Message-ID: <CAOW+2duz_9=me5CdG2HQLtSL-BBygoCb0Hdo+MP3S8GuUyp1Ew@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Martin Thomson <mt@lowentropy.net>, architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007621fc0589f5f249"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/dlJQVyPD-g8oVuEj7Qafm7wa5qo>
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 17:25:16 -0000

John said:

" moving off in the direction of grand pronouncements that are disconnected
with reality;"

[BA] The document makes the point that mechanisms that are rarely used also
tend to be poorly tested.  Also, that poorly tested extension mechanisms,
once widely deployed, can fail and become obstacles to protocol evolution.

TLS is cited as an example.  So this is more than a theoretical problem.

"Bugs are bugs. Design flaws are design flaws. Too much effort is spent
ignorant of the difference"

[BA] The point made in the document is that even a flawless extensibility
design, if it is rarely used in practice, will tend to accumulate
(undetected) bugs. The argument is similar to one made about emergency
communications - that mechanisms that are only used in emergencies are more
likely to fail.  So I wouldn't say that the document is ignorant of the
difference - but rather is making an observation about the connection
between the two.




Also, that poorly tested mechanisms, once widely deployed, can become
obstacles to extensibility.



On Tue, May 28, 2019 at 9:05 AM John C Klensin <john-ietf@jck.com> wrote:

> 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
>
>
>
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>