For an outsider's feedback about John's comments (1), (4), and (5): On 31/May/11 18:23, John C Klensin wrote: > This proposal is problematic in several ways. The first is > obviously the most important, but the others suggest changes > that might be useful whether or not that main provision is > adopted. > > (1) Excessively-high requirements for Proposed Standard and > dropping the three-level model. > > The document asserts, I believe correctly, that one of the > problems with the IETF Standards Process is that the > relatively low bar established for Proposed Standards in > RFC 2026 has evolved into a very high bar and that we > should return to that lower requirement level. Yet it > effectively proposed to solve that problem by reducing the > number of steps in the standards process to two. No > evidence has been offered that whether or not the standards > process is two levels or three has anything to do with > difficulties completing Proposed Standards or getting them > to a satisfactory level of completeness and correctness. > The logic on that subject in the document appears to me to > quite similar to a physician saying "We agree there is a > problem with your hand. We don't know how to treat it > either surgically or medically, but we should do something, > so let's amputate your foot". That really makes no sense > and is probably bad for the patient (only probably... one > really never knows). > > In addition, draft-housley-two-maturity-levels-06 does not > discuss any mechanism for getting from the current > as-practiced requirements for Proposed Standard back to the > requirements of RFC 2026, a schedule for doing so, nor > whether it is necessary to warn readers about the level of > scrutiny applied (it may not be, but there has been little > or no discussion of that subject in the IETF and there is > no such discussion in the document). If this were a > technical specification, unless there were an expectation > that a transition will occur immediately and by magic, that > omission would be a "known defect". > > Suggestion: The level of completeness and quality required > for a Proposed Standard, at least insofar as those > requirements exceed the requirements in RFC 2026, are > entirely in the hands of the IESG, relevant WGs, and the > Last Call process. Whether those requirements can be > reduced to the level required by 2026 has nothing to do > with this document because there is no change to the 2026 > requirements. While those considerations are entirely self-evident, I omit John's suggestions (i), (ii), and (iv) as they address an apparently different problem. In facts, on the requirements for Proposed Standard, the I-D says that "they remain exactly as specified in RFC 2026", which seems to mean that the I-D is not attempting to alter their formal status in any way. I agree that the transition described in Section 5 is somewhat abrupt. It seems to me it would be smoother and more flexible to allow the new two-step ladder to coexist with the current three-step one, at least temporarily. That is to say, use "add to" rather than "replace" or "change" in the RFC Editor notes, and alter the last sentence in section 2 to read Minor revisions and the removal of unused features are expected, but a significant revision may require that the specification accumulate more experience at either Proposed Standard or Draft Standard before progressing. In John's word: > (iii) The above implies that different areas, and > perhaps even different WGs within an area, will end > up with different practical requirements based, at > least in part, on their perception of the risks > implied by a less comprehensive document. I see > that as an advantage and recognition of reality, > not a problem. > (4) Discussion of the STD document series in Section 6. > > It has been pointed out several times, in recent months to > suppress discussion of proposals that might be alternates > to some or all of this one, that there are many issues with > how the IETF develops, approves, documents, and manages > standards that are not addressed in this specification and > that the community cannot reasonable expect to address all > at the same time. The question of what should be done > about the STD numbers is just one entry on this very long > list. Examination of other IETF procedural RFCs indicates > that we rarely, if ever, include a discussion of a single > option that we have decided to _not_ pursue (even if only > in the near term). The only apparent justification for > including Section 6 in this draft is that there was a > specific proposal in an earlier version, a proposal that, > as the draft indicates, did not get community consensus. > The section should be dropped from this document before > publication. If the community wants to have a series > discussion of STD numbers, I suggest that > draft-klensin-std-numbers might be one contribution to that > discussion. +1, different documents for different problems. > (5) Patents > > The specification says (last bullet in Section 2): > > > * If patented or otherwise controlled technology is > > required for implementation, the separate > > implementations must also have resulted from separate > > exercise of the licensing process. > > While this text is copied from 2026, things have changed > and the requirement has been interpreted very loosely, > particularly to leave interpretation of "required" in the > hands of the implementers. > > If it is repeated in a spec that is approved now and that > claims to reset and clarify Draft Standard requirements, it > can easily be read as a requirement that the community has > to somehow evaluate whether claimed controlled technology > is actually "required for implementation". That may be > obvious in some cases; it may be highly controversial and > dependent of validity of patent claims (something that can > normally be resolved only by the courts) in others. The > IETF has been repeatedly advised, both by legal counsel and > by various incarnations of IPR WGs, to avoid straying into > the territory in which it takes a position on whether an > IPR claim is valid. Consider a scenario in which some > company, say ChuckCo, decides that an IETF Internet > Standard for Alice's proposal would put them at a > competitive disadvantage. It is merely necessary for > ChuckCo to file an IPR claim against the technology in > Alice's spec, even a obviously spurious one, assert a > completely irrational and punitive licensing model that > cannot be exercised in a reasonable way, and then sit back > and watch the IETF paralyze itself over this provision as > written. > > Suggestion: I believe that advice of Counsel should be > sought about this language and, if feasible, alternate > language produced that either turns the requirement into an > "if feasible" request or that places the responsibility for > evaluating whether the claims are applicable on the > implementers and not on the IETF or IESG. I suggest that any IPR notices be referenced from RFCs, somewhere among other boilerplate in the front matter. If at all possible, purely defensive patents, for which clearly worded statements grant unencumbered use of the relevant technology, should enjoy a distinguished wording that quickly conveys such condition. No separate exercise of the licensing process seems to be necessary for such cases. On the opposite, I see no reasons for standardizing technologies that are known to require payed licenses, unless (part of) that money goes to the IETF. jm2c _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf