+1 on all points, especially the first one. john
--On Wednesday, January 26, 2011 22:29 -0500 "Scott O. Bradner" <s...@harvard.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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
