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

["Adrian Farrel" <[e-mail]>]

While I appreciate the effort the author put in to resolve previous
discussions, I do not support the publication of this document.

The thrust of my previous comments were to say "It is all platitude, 
but probably harmless" and "at whom is this document aimed". This 
review is in a little more detail. I still find the whole document to
be one big platitude that does not need to be published, but I have also
found a number of things that I think need to be fixed.

---

This document significantly conflates advice to implementers wishing to
ensure interoperability, best practice for people claiming to have
implemented (i.e., claiming conformance to) a specification, and 
constraints to the freedom for implementers of IETF specifications.

As the text notes, IETF specifications (please don't call them standards
unless that is what you really mean) are not mandatory to implement. So
the text really must not tell people what they must or must not do. For
example, the Abstract says "By choosing to implement..." This is
nonsense! I can choose to do what I like. If I choose to implement stuff
and tweak it and make it better, that is entirely my choice. 
Maybe you could have said "By claiming to have implemented..." But even
that is marginal. We are not the Internet Police and we have no 
influence in the world of advertising or marketing. Nor do we run 
conformance labs. This attempt at constraining implementations is bogus
and needs to be removed from the document.

As far as interoperability is concerned, it is great to give concrete
advice. When the Introduction says
   This document provides advice to implementers of IETF protocols to
   improve interoperability of their implementations.
it would be wonderful if the document lived up to the claim. But this
claim seems to be at odds with the document Title and Abstract and all
I find in the document is effectively "If you want two implementations
to interoperate, they need to implement the same thing." Well, if that
comes as a surprise to anyone perhaps they are in the wrong business.

So what is the document actually trying to do and say, and to whom?

---

The document also contains a lot of passive voice that hides the
motivation for the text. For example, the Abstract says "...one is
expected..." Expected by whom? Why? Perhaps you can attribute the 
expectation to make this meaningful.

---

Introduction
"IETF protocols foster interoperability."
I don't believe this is true. A protocol cannot of itself achieve this.
Possibly the clear specification of a consensus-based protocol can do
that. Possibly.

---

Introduction
   Yet, IETF standards are
   voluntary standards.  No one is required to implement them.
   Implementation is a choice.  By making this choice, an implementer is
   expected to:

      (1) Follow the protocol specification;

Please clarify "IETF standards" since you almost certainly don't mean 
what you have written.

But note that this text is circular. Implementation of a specification 
is, by definition, following the specification. So this text doesn't
say anything! It is the *claim* of implementation that has an 
expectation attached to it. What I do in the darkness of my own room is
not a matter for anyone's expectations.

---

Introduction

   When implementers meet these expectations, protocols interoperate as
   intended by the IETF.

This is a mixed message. Are you trying to set out the expectations on
people who implement (or claim implementation), or are you giving advice
on how to achieve interoperability?

---

Section 2

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

While the example given is highly desirable, it does not go as far as 
"needs to". An implementation is a snapshot, a moment in specification
history, and is correctly described as such. There is no moral or other
binding on the implementer to make a change, just as there was no 
requirement that the implementer select a particular specification to
implement.

When I implement a protocol as specified in an RFC I am not making a 
commitment to update my implementation to fix bugs in the specification
or to add features.

Furthermore, not all protocol extensions are desirable in all 
environments. There is no requirement for an implementer to add a widget
as there is no requirement for an implementer to implement version 2 of
a protocol or to pick up fixes to version 1.

---

Section 3

I am not comfortable with this attempt to define the purpose and meaning
of BCPs over and above RFC 2026. The statements in this section might 
reflect how BCPs have been used in the past, but this text is too strong
in the way it looks to the future. It might be appropriate to put this 
into the past tense...

   Best Current Practices (BCPs) about IETF protocols (not the BCPs that
   define IETF processes and procedures) have often been used to 
   document IETF consensus about operational or implementation practices
   pertaining to IETF protocols.

By *your* definition of BCP, why is this document not a BCP?

---

Section 3

   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.

Do you mean "provide" or "obtain". If "provide" then provide to whom?

---

Section 3

   Sometimes BCPs are referenced in the protocol specification.  Often
   the implementer needs to look through the BCP index to find related
   BCPs.

The implication here might be that by checking the list of BCPs an
implementer will find all of the relevant advice and guidance outside the
specification itself. This is not true. There are plenty of 
Informational RFCs describing ways to build and deploy protocols. And 
there is this (under-used) thing called an Applicability Statement
[RFC 2026 - section 3.2].

Adrian