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

From: "Martin Thomson" <[email-masked]>
Date: Tue, 28 May 2019 19:47:02 +1000

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 [email-masked], or to the IAB directly at [email-masked].

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 May 2019 12:04:38 -0400

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
<[email-masked]> 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 [email-masked], or to the IAB directly at
> [email-masked].
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 May 2019 10:01:12 -0700

+1

> On May 28, 2019, at 9:04 AM, John C Klensin <[email-masked]> wrote:
> 
> these things out and provide guidance

I do not. IMO, the IAB has no privileged perspective other than a soapbox on which to pontificate and repeatedly proves so.

> I see some danger of the
> and procedures are followed, all will be well.

Agreed, e.g.: 

2.0 suggests that new protocol extensions are preferable to fixing bugs. 2.2 implies we accept hijacking and fails to recognize how (and arguably why) HTTPS has already supplanted HTTP.

The rest can be summarized by Berkeley’s question of whether a tree falling in a vacant forest makes a sound*.

Bugs are bugs. Design flaws are design flaws. Too much effort is spent ignorant of the difference, here and throughout the IETF.

That said, this doc should proceed, if only to highlight the value of IAB advice.

Joe

*if we’re going to be philosophical; but preferably, let’s not.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 May 2019 10:24:58 -0700

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.

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 May 2019 11:21:30 -0700

> On May 28, 2019, at 10:24 AM, Bernard Aboba <[email-masked]> wrote:
> 
> "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.

Again, a tree in a vacant forest.

Untested designs are untested. So we should test them.

A massive observation surely worthy of IAB imprimatur.

Joe