Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[Keith Moore <[e-mail]>]

That's just what seemed right to me - don't encourage people outside the 
working group (which is the point of such notices after all) to invest 
time/effort in implementing the protocol until there's been some 
cross-area review to verify that the community is okay with the shape of 
the proposed protocol and the direction.   It might be that the label 
"ready for test implementation" should be slightly different, e.g. 
"ready for outside implementation".   Or maybe that the nature of 
"outside review" should be clarified.

(also don't let that choice kill the idea - this was something off the 
top of my head, and I'd expect there to be discussion with lots of folks 
about the proper order of things before trying this out with a group or 
two)

Keith

On 7/4/19 9:24 AM, Ted Lemon wrote:
> Keith, why would you put “ready for test implementation” /after/ 
> “ready for outside review?”  We /want/ test implementations. These are 
> a great way of finding bugs in the spec. Arguably, there is no point 
> in spending IETF cycles on “outside review” until someone has 
> validated that what is written down is at least implementable by 
> someone who’s been following the work.
>
> Sent from my iPhone
>
> On Jul 4, 2019, at 1:38 AM, Keith Moore <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> On 7/4/19 1:23 AM, Nico Williams wrote:
>>
>>>
>>> In the security area just about all major Internet protocols are at
>>> Proposed Standard.  PKIX?  Proposed Standard.  Kerberos?  Ditto.  TLS?
>>> Yup.  SSHv2?  Indeed.  IKEv2?  No, IKEv2 and CMS are among the
>>> exceptions, though what good IKEv2 might do anyone w/o ESP, or CMS w/o
>>> PKIX, I don't know.
>> Yah, I know.  It's hard to get the energy required to move up from PS.
>>> Whatever the intention originally might have been, it's certainly long
>>> not been the case that one should not deploy protocols that are at
>>> Proposed Standard.
>> Not sure I agree with that :)  I still think it's unwise to promote 
>> deployment before there's been interoperability tests.   But clearly 
>> we're not getting that done with our current process.
>>> And it's very difficult to stop vendors from shipping pre-RFC protocols.
>>> We don't have a protocol police, and we move too slowly.  If we don't
>>> adapt, other SDOs will do more of our work.
>> yup, it's a race to the bottom :(
>>> A big selling point of the
>>> IETF is its review processes -- the adults in the room to keep authors
>>> from doing dreadful things.  But we need to speed up the cycle somewhat,
>>> and one way to do it might be to have a way to indicate expected
>>> stability in I-Ds, and probably only in WG work items only, and at some
>>> cost (e.g., early directorate reviews?).  I don't quite know -- maybe
>>> after reflection we might conclude we shouldn't do this, but we should
>>> certainly discuss it, and be able to discuss it.
>>
>> So the way we get more review is to encourage deployment even earlier 
>> in the draft cycle?  Seems like an odd way to do it.
>>
>> But maybe something like this:  What if WGs labeled drafts with 
>> "preliminary" (not ready for implementation), "ready for outside 
>> review" (after WG thinks the overall shape of the proposal is good, 
>> inviting explicit review/feedback from IETF in general and others), 
>> "ready for test implementation" (after favorable review and IESG 
>> approval), "WG last call candidate" (after favorable implementation 
>> and interop tests), and finally "IETF last call candidate"?   
>> Probably not in the doc name itself, but in the tracker, and in the 
>> document text when appropriate.
>>
>> Keith
>>
>>