Re: draft-housley-two-maturity-levels

[John C Klensin <[e-mail]>]

+1 on all points, especially the first one.

   john


--On Wednesday, January 26, 2011 22:29 -0500 "Scott O. Bradner"
<[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf