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
ietf(_at_)ietf(_dot_)org 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