Re: draft-housley-two-maturity-levels

[Gonzalo Camarillo <[e-mail]>]

Hi,

yes, I also agree the first one is the most important point and has not
been addressed so far. If we want a system that works (and is used), it
needs to include incentives to move from one level to the next one. I
have discussed this issue with quite a few people. Some people claim
that those incentives exist in some areas (e.g., public institutions
preferring or requiring full standards in their RFQs) but, at least in
the RAI area, the incentives are not there in the vast majority of cases.

Cheers,

Gonzalo


On 27/01/2011 9:28 AM, John C Klensin wrote:
> +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
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>