Re: Last Call: <draft-housley-implementer-obligations-01.txt> (Expectations of Implementers of IETF Protocols) to Informational RFC

[John C Klensin <[e-mail]>]

--On Monday, May 12, 2014 08:23 +1200 Brian E Carpenter
<[e-mail]> wrote:

>...
>> This document doesn't fill this purpose as it is written as a
>> what-to-do document rather than a document with advice to
>> implementers. If somebody has specific expectations from
>> implementers then that should be reflected in a contract with
>> them.
> 
> That's a straw man. You know very well that (precisely because
> IETF standards are voluntary) there will never be such a
> contract between the IETF and the implementer.

But that is exactly the point, I think.  This document reads
like an attempt to make one because it leads immediately to "you
implemented that IETF spec, therefore you are/were obligated
to..." statements and arguments.

Also, let's be clear about "voluntary".  I hope we never
contemplate this, but suppose the IETF were to break its
protocol specifications into two parts, the requirements
statement, context, and overview and the actual protocol
specification.  And suppose we created a mechanism by which,
while the former was public, freely available, etc., getting to
the latter required a click-through license asking for agreement
to these sorts of expectations.  I'll leave it to the lawyers
(actual and amateur) to figure out something like that might
work and be enforceable, but it would be no worse than a lot of
commercial software licenses, arguably including the GPL.   The
standard would still be "voluntary" in the sense that no one was
required to implement it.  And _that_ is the sense in which
"voluntary standard" has been used, consistently, since I first
started doing standards work in the early 1970s.

Let me rephrase Nikos's comment (probably in a way he didn't
intend).  "If a particular protocol spec has or requires
specific expectations from implementers then those should be
reflected in conformance statements". [1]


>> If on the other hand this is written in purpose to introduce
>> IETF-certified or IETF-approved implementations it must be
>> even more precise than this document. As it is, it doesn't
>> fill any obvious purpose.
> 
> The document is aspirational, not contractual. It seems
> perfectly reasonable to ask implementers (whether a
> profit-making company, an open-source community, or an
> individual) to accept ongoing responsibility for their code.

And yet...

We know that many of the people who find an RFC, e.g., by a web
search looking for specifications in a particular area or by a
reference from elsewhere are extremely unlikely to browse the
RFC collection looking for a document about "Expectations of
implementers...".  The people who are active in the IETF
probably don't need this document.  If they do, and its content
is really necessary, it probably belongs in the Tao, as others
have suggested.

As it is and for an external audience, it is likely to be mostly
useful for whining, e.g., in conversations like:

(i) IETF: You and your implementation didn't live up to our
expectations.
    Implementer: What expectations?
    IETF: Read RFC 9999.
    Implementer: How was I expected to find that?

(ii) IETF: You and your implementation didn't live up to our
expectations.
    Implementer: So?

And perhaps worse (if the document is actually spotted):

(iii) IETF: Why did you create a completely new protocol for
that purpose rather than following our fine, high-quality,
consensus standard?
    Implementer: We, and our lawyers, looked through your
"expectations", decided they constituted an attempt at a
shrink-wrap style license that encumbered the IETF spec and that
we were therefore better going our own route.

Note that the third hurts interoperability.

>...

A few additional observations if it is determined to publish
this anyway (which, as is probably obvious, I do not favor).
Note that several of these overlap with Adrian's comments, with
which I generally agree:

(1) The draft (-02) tells readers that they are expected to
conform to the BCPs but that they may need "to look through the
BCP index to find related
BCPs".   That makes another expectation of implementers that
they be able to perform a treasure hunt for materials we just
admitted require some deduction to find. using tools the
document specifies only by hand waving, and get it right.  Seems
unlikely to me.

(2) This is mostly a nit, but, while appealing to RFC 760 as an
authority is arguably non-normative because the text is quoted,
it is a bad choice of reference for several reasons including:
760 has been obsoleted by other documents, it has a status of
"unknown", and a present-day reference to a document whose title
describes it as a "DoD Standard" may not be wise in the
present-day political climate of which the author, as IAB Chair,
is only too aware.  FWIW, the rule is repeated, although stated
differently, in Section 1.2.2 of RFC 1122 and RFC 1123, both of
which are full Standard Applicability Statements without any of
those three issues.  As SM points out, the discussion in RFC
1122/1123, a discussion that is not present in 760, is very
important and should be identified.   In addition to the article
he indirectly cites, the IETF has had very significant
experience with sender-implementers claiming that they can do
astonishingly non-conforming (and stupid) things on the grounds
that the receiver is obligated to be robust and liberal in
acceptance.

(3) It is very likely that, with 1122/1123 as premier examples
for the technical specifications they interpret, the document
should call out relevant Applicability Statements as well as
BCPs. Indeed, paralleling discussions that I gather have been
going on in the IESG, unless BCPs really represent established
Best Practices for technical specs rather than BCP-author
instincts or preferences, this document should be citing those
Applicability Statements as exist in preference to BCPs.

(4) I note that several reference implementations that have been
very important to the development of the Internet and/or the
specific protocols involved would not have conformed to this set
of "expectations".   I note that several of them were funded by
various agencies specifically as one-shot (or one shot plus a
very restricted period for iterations) deals.  If the IETF's
stated expectation were really that people should not implement
unless they are committed to maintain, we would be discouraging
such implementations and the support for them.  Similar
observations could be made about a lot of other implementations
created in research settings: few, if any, research managers
would be willing to commit to something that carried obligations
for long-term maintenance.   That would, IMO, be a really nasty
side-effect of publishing a document like this.

I'll make some constructive suggestions about how to solve the
presumed problem to which this is addressed in a separate note.

best,
   john


[1] If the language of RFC 2119 prevents writing such
conformance statements then, IMO, 2119 needs to be fixed.