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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf