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

Eric Rosen <> Tue, 13 May 2014 16:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C169C1A0124; Tue, 13 May 2014 09:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.152
X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VvEZsI-mycce; Tue, 13 May 2014 09:59:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B3DF71A0107; Tue, 13 May 2014 09:59:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4831; q=dns/txt; s=iport; t=1400000381; x=1401209981; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=vO9O+R/Qu3J0dX/3koZaV3hMTD3opNuOiJOT4Fug+2E=; b=SYhnbYzZz18QmEQW/9yeKvv1mZgbWv60/4UaPU6NUwfQ86+1NHM2i5NR ITTrItsTLbC0bTTW+8mN4uq9i0rszzEPFu7QDWXFVylrZ7tlossw5tApK Q+zbxQIVHjrqQySqJX+DAya7E9iBBhhYrMgk38yAlqnQpcOalUhh49M91 0=;
X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000"; d="scan'208";a="43446778"
Received: from ([]) by with ESMTP; 13 May 2014 16:59:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s4DGxejU006437; Tue, 13 May 2014 16:59:41 GMT
Received: from erosen-lnx (localhost []) by (Postfix) with ESMTP id 76055490; Tue, 13 May 2014 12:59:40 -0400 (EDT)
From: Eric Rosen <>
Subject: Re: Last Call: <draft-housley-implementer-obligations-01.txt> (Expectations of Implementers of IETF Protocols) to Informational RFC
In-reply-to: Your message of Fri, 09 May 2014 12:18:41 -0700. <>
Date: Tue, 13 May 2014 12:59:40 -0400
Message-ID: <21544.1400000380@erosen-lnx>
Cc: IETF-Announce <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 May 2014 16:59:50 -0000

I find this document a bit puzzling.

Obviously, the notion of "expectation" is not meant to be descriptive.  No
one really expects implementors to meet all the "expectations", and often
they do not.  

So the notion of "expectation" must be intended to be prescriptive, roughly
equivalent to "obligation".  However, there does not seem to be any legal
obligation to do all the things the document lists.  And it would be rather
far-fetched to claim that failing to follow a protocol specification is
immoral or unethical.

The document would be less puzzling if it gave up all talk of "expectations"
or obligations and simply said "if you want to maintain interoperability
with other implementations, here are things that would be wise to do".  If
that's all that is really meant.  Even so, it has the feel of the sort of
lecture that parents like to give their teenagers: "if you live in my house
you have to follow my rules".  And it will have the same effect (i.e., no

I also think the document has a few serious mistakes.

For instance:

    "Follow the protocol specification"

Well, that sounds harmless enough, but sometimes the protocol specification
has errors (sometimes of omission), and the errors are known to the
implementors.  Are they supposed to implement the errors?

"Follow the standard" is ITU-T stuff, and leads to conformance testing; "do
what you have to do in order to interoperate" is much more in the IETF

     "IETF standards are voluntary standards.  No one is required to
     implement them.  Implementation is a choice."

Sorry, most implementors are not volunteers, but are being paid to implement
the protocols.  Often there is no real choice involved.

Or by "implementor", does the document mean "whoever is paying to have the
implementation done", rather than "whoever does the implementation"?  In
that case, "the implementor" would often be a company.  And the individuals
doing the implementation will do what is necessary to accomplish the
company's goals, even if this deviates from the advice given in this

   "An implementer should plan to maintain their
   implementation.  It is not sufficient to do an initial implementation
   of the protocol.  One needs to apply changes as they come out."

While this may be generally good advice for any computer programmer, it
obviously does not apply to individual implementors who move on to other
tasks or other companies.  As for whether a company needs to maintain its
implementation in this way in any particular case, well, that depends on
business considerations.  

There are also a few things that are not very clear.

   "The Internet is composed of networks operated by a great variety of
   organizations, with diverse goals and rules.  By following the BCPs,
   implementers, operators, and administrators are able to provide a
   common experience when using the protocol, regardless of their point
   of attachment to the Internet."

What does this even mean, "a common experience"?  And what does that have to
do with BCPs?  And what if a common experience is not desired?  And what if
changes in technology or business conditions make the BCPs less relevant
(assuming they were ever relevant to being with)?

   "Implementers are expected to follow the IANA registry practices
   associated with the protocol, especially in the assignment of new
   values.  By following these practices, other implementations will
   learn about new values and make the appropriate updates to handle
   them properly."

This is a good example of the platitudinous nature of the document.    There
are numerous reasons why IANA practices are not always followed in practice:

- An implementor might not know the proper IANA processes.

- An implementor might know the processes, but think they are too
  cumbersome, when it's much easier just to define a constant in a header

- If the registration policy is "standards action" or any other policy that
  requires IETF or IESG review, codepoint allocation can become enmeshed in
  politics and/or business rivalries.  There are circumstances in which one
  really has no other choice than to follow the rule that "it is better to
  apologize later than to ask permission first".

It's not that useful to say "just follow the process" without saying
anything about the problems that prevent the process from being followed in
many cases.

So overall I'd say that this document is not worth publishing, but if it is
published it should be made clear that it is about "what you have to do to
maximize the chances of interoperability" than it is about "what you have to
agree to before you are allowed to implement".