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

[S Moonesamy <[e-mail]>]

At 12:18 09-05-2014, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'Expectations of Implementers of IETF Protocols'
>   <draft-housley-implementer-obligations-01.txt> as Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[e-mail] mailing lists by 2014-06-06. Exceptionally, comments may be

The document defines three expectations which can be summed up as 
"follow".  I don't think that's a good idea.

The Introduction Section of the draft states that IETF protocols are 
about interoperability and defines what is expected of 
implementers.  In that section:

   "IETF protocols foster interoperability.  This interoperability brings
    great benefits.  IETF protocols are building blocks for many products
    and services, and they enable innovation."

The above comes out as marketing IETF protocols to the world.  The 
implementers I am acquainted would be suspicious if I were to use 
words such as "great benefits" and "enable innovation".

   "Yet, IETF standards are voluntary standards.  No one is required to
    implement them."

Some IETF standards, e.g. TCP, are de facto standards.  When an IETF 
standard is widely used and widely implemented there isn't any 
practical alternative except to follow suit.  Arguing that it is a 
voluntary goes against describing an IETF protocol as the standard.

The real test of a protocol specification is the implementation.  An 
implementer (not speaking for anyone else) decides how to implement 
what is specified in the RFC instead of blindly following what is 
written in it.  I'll note that some IETF protocols are 
over-specified, e.g. they prescribe methods instead of specifying the 
interoperable elements.

Ideally, a BCP would describe best current practice.  In practice, a 
BCP states the beliefs of the proponents as current practice.  The 
expectation for implementers to follow associated BCPs could be seen 
as an imposition.

It is not clear what IANA registry practices has to do with this 
document.  There is a normative reference to RFC 2860.  That RFC is 
an agreement between IETF and ICANN.

Section 2 quote Postel's Law. It has been argued in an IEEE 
publication that several mistakes in Postel's principle lead to the 
opposite of robustness - unmanageble insecurity.  The RFC 1122 
discussion of that principle provides better guidance to the 
implementer.  Unfortunately, there is a tendency to quote the 
sentence instead of the RFC 1122 discussion.

Section 2 of the draft states that "many protocol specifications are 
living documents".  An implementer would expect that a specification 
has reached a level of maturity where it won't be changed 
significantly.  The rationale here is that there is a cost to making 
changes.  There are also other parties involved and the implementer 
does not have any control over them.  On a somewhat related note, the 
IETF has published a specification in 1998.  There are errata for 
that specification.  It seems that the IETF found it sufficient to 
publish a specification and not include technical changes which 
affect the specification.  Reading nine "updates" does not make the 
life of the implementer easier.  In simple terms, the IETF would be 
unable to follow its own advice.

Section 3 mentions that:

   "Often the implementer needs to look through the BCP index to find
    related BCPs."

The secret of Polichinelle is that there is some hand-waving in a BCP 
when nobody knows, or there isn't agreement, about what guidance to 
give.  That leaves the implementer without guidance.

Section 4 is quite lengthy compared to the sections about the first 
two expectations.  The section states that the Internet Assigned 
Numbers Authority is a central authority.  That section might be in 
contradiction with RFC 6220; the latter mentions a Registry Operator 
without stating that the Internet Assigned Numbers Authority will 
always be the central authority.

The following is odd:

   "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."

It looks like implementers are to follow registry practices so that 
other implementations will have to be updated.  It lessens the 
argument for interoperability by choice and makes a strong argument 
for forcing implementations to follow the registry practices.  A 
future effect might be to turn registry assignments into 
controversial discussions with the IETF acting as a gatekeeper.

The implementer is advised to follow the registry practices for 
"top-level DNS names in the rare cases where such values are 
needed".  A search turned up:

http://support.microsoft.com/gp/gp_namespace_master
http://support.apple.com/kb/ts3389
http://www.belkin.com/PYRAMID/AdvancedInfo/F5D7632uk4Aver7000/Interfaces/Interface/English/lan_main_0.stm
https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1295
http://www.enterprisenetworkingplanet.com/netsysm/article.php/991281
http://community.linuxmint.com/tutorial/view/159
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-hostname.html

The advice has not been followed previously.  It is unlikely that it 
will be followed.

It is better to have a technical discussion about the implementation 
details of a specification than to argue that "you must do what the 
RFC says".  Interoperability does not work without mutual 
consent.   An expectation that people will follow does not create a 
sense of collaboration.  The draft mentions that the "expectations 
reflect the fundamental philosophy of the IETF".  As much as it is 
appealing to know better, is that the philosophy that the IETF would 
like to encourage?

Regards,
S. Moonesamy