+1 on all points, especially the first one.
john
--On Wednesday, January 26, 2011 22:29 -0500 "Scott O. Bradner"
<sob(_at_)harvard(_dot_)edu> wrote:
1/ I still do not think this (modified) proposal will have any
real impact on the number of "Proposed Standard" documents
that move to a (in this proposal, "the") higher level since
I do not see how this makes any significant changes to the
underlying reasons that documents have not progressed in
the past - i.e., I see no reason to think that this
proposal would change the world much (would not help, would
not hurt)
2/ I think the proposal must specifically deal with the 2026
IPR licence requirement in section 4.1.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.
The requirement can be dealt with by explicitly discarding
it or by including it. But not mentioning the requirement
does not make the issue go away. This requirement was, in
theory, a way to keep the IETF/IESG out of the business of
evaluating the fairness of licensing terms. I can remember
only one time it came up (in an appeal) so getting rid of
it may be fine - but don't make it look like it was just
forgotten.
3/ I think you also be quite specific as to how to decide that
the conditions for advancement have been met - one of the
big implementation issues with 2026 was knowing how to
decide that a technology was ready to be advanced (did you
need a spreadsheet listing all features and noting with ones
had been multiply implemented (as was done at huge effort
for HTTP 1.1) or is there someting simplier - clear rules
would help avoid this type of issue in the future
4/ as part of #3 - the rules should also specifically deal with
the following pp from 2026
The requirement for at least two independent and
interoperable implementations applies to all of the
options and features of the specification. In cases in
which one or more options or features have not been
demonstrated in at least two interoperable
implementations, the specification may advance to the Draft
Standard level only if those options or features are
removed.
this requirement was included to try to remove cruft from
protocols as they went forward - maybe this is no longer a
desire but, like with the license issue, a specific mention
of what has been decided would mean that people would not
think that things were not just forgotton.
Scott
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf