While I am neutral on the need for such a document – perhaps Brian or Adrian is correct – I have some concerns about its content. When implementers vary from specification, it falls into two cases: a bug or a feature. I have varied from the spec when I thought it was necessary to protect my customer base or to improve their experience in some other way. I consider it a more nuanced question as to when Postel's Law should be applied, because it is often difficult to distinguish a "technical error" from an attack. It may be better to fast fail in these sorts of circumstances, and I believe working groups have been taking this attitude for some time in their guidance, starting with DRUMS way back when. To address the above concerns, I would suggest that the author provide more nuanced guidance. One must balance being liberal in what one accepts against the likeliehood of an attack or misinterpretation of what the sender is trying to say. Furthermore, for any protocol that involves some sort of store and forward or proxy component, in as much as intermediaries are able to interpret a malformed protocol element, if the end point cannot, one must see that the error gets back to the right place. In addition, I concur with Elwyn about the tone of the document, in that it borders on legalistic. Fundamentally we argue that IETF standards are voluntary, and I agree with Adrian on that point. I have different concerns about the need to maintain implementations. This is a very important concern in the Internet of Many Tiny Little Things that deserves attention. Considerable research has been undertaken as to how long it takes to get zero day exploits fixed in browsers and phones. But the world is changing and browsers and phones are now joined by refrigerators[1] and toilets[2] (to name a few examples). I agree with Russ that this is a problem, and it may even be the IETF's problem (see above about NOT being liberal, for instance), but perhaps this area needs its own document. Finally, it seems to me that much of this (revised) text could be incorporated into the Tao. Eliot [1] http://www.businessinsider.com/hackers-use-a-refridgerator-to-attack-businesses-2014-1 [2] http://www.theverge.com/2013/8/3/4584980/inax-satis-bluetooth-toilet-android-app-vulnerability On 5/10/14, 8:34 PM, 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, 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 > > >