On 2011-01-27 16:29, Scott O. Bradner 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)
I tend to be more optimistic. I think that having only one step
ahead to reach final status is *much* less of a psychological
barrier, and the name "Internet Standard" is a *much* more appealing
target than "Draft Standard". Therefore, I believe this change will
be a significant step forward.
> 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.
I strongly agree. This exact sentence should be carried forward.
>
> 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
Whike I agree with Scott, I suggest solving this outside the BCP itself.
It's quite a complex issue.
>
> 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.
Actually the draft does not appear to require interoperability testing
at all:
"* There are a significant number of implementations with
successful operational experience."
Is that intentional? I thought interop was generally regarded as
fundamental. So I think the text needs to be explicit about which
bits of section 4.1.2 of RFC 2026 still apply. Or expand the
sentence by adding ", including interoperation between different
implementations when meaningful."
(It's "when meaningful" because some standards such as MIB modules
don't interoperate as such, see RFC 2438.)
On another point:
"5. Open Question Regarding STD Numbers"
IMHO the easiest solution is still what I suggested some years
ago: retain STD numbers, but assign them at the PS stage. That
removes the confusion about a PS that updates a numbered Standard.
Brian
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf