On Thu, Jul 04, 2019 at 01:38:00AM -0400, Keith Moore 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 I'm not convinced that we were never supposed to ship pre-Draft-Standard RFC implementations. > deployment before there's been interoperability tests. But clearly > we're not getting that done with our current process. And it's a safe bet we never will. > > 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 :( That's not a good argument for not attempting to improve the rate at which we get things done. > > 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. It's the opposite. In order to get to "deploy earlier" (see below), first get more review than you would have had we not had that option. Mind you, a stability attribute needn't be about deployment, but a) a guide to participants about what changes are considered acceptable going forward, b) an indication to implementors that the protocol is mature enough to implement (not necessarily deploy). > 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 Eh?? Can't test until you have IESG approval? Did you really mean that? > 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. I wouldn't mind some such designations, no, but these should probably be Data-Tracker metadata, and probably set by the WG chairs, not the authors. Any designation about stability should probably also be Data-Tracker metadata, and set by the responsible AD and/or an assigned expert reviewer whose responsibility is to ascertain the likelihood that future reviews will require backwards-incompatible changes. I rather like the idea that any such designations should be Data-Tracker metadata that can only be set by appropriate authorities. Nico --
