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

[Brian E Carpenter <[e-mail]>]

Hi Adrian,

On 11/05/2014 06:34, Adrian Farrel wrote:
> 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, 

I can certainly see how you could reach that view, but I think you're
looking at it from the viewpoint of somebody who's been around the
IETF for a long time and knows what we do here and why we do it.

I like to think of somebody else: a young programmer working far,
far away, who will probably never attend an IETF meeting or join
an IETF mailing list. For this person, we need to state things that
are obvious to us. For example:

"It is not sufficient to do an initial implementation of the protocol.
 Maintenance is needed to apply changes as the come out in the future,
 especially to fix security issues that are found after the initial
 publication of a protocol specification."

That isn't a trivial statement. It says that a protocol design may have
zero-day vulnerabilities and if you implement it, it's your job to
watch out for future updates and apply them. Is that going to be obvious
to someone starting a garage company in Africa?

I think the document is valuable.

One specific comment: I think it should be mentioned that implementers
should always read the references cited in a specification, especially
but not only the normative references, and apply them as relevant.

I also suggest mentioning implementation of extensions. Faulty extensions
are harmful to interoperability and security. We have a couple of RFCs
about that too (4775 and 6709).

   Brian

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