Hey Melinda, Most of the NVO3 requirements documents will expire before June, all will have expired before Sept. If they are documents of good quality and usefulness, then the RFC process will not be onerous, and you will have a few design goals that won’t expire into oblivion. If the documents suck, then they aren't helpful to people that think of themselves as designers, or implementors, or just people for that matter, and need to be fixed. Unless of course, the requirements documents disagree with the direction that a few vendors want to go in, then we definitely don’t want to publish those, better to let them expire, and start again.
I suggest that without formalization of the requirements, you aren’t going to get a protocol that meets many of them, or a process that serves more than a few companies. We’ve got many examples of poor protocols in the IETF, possibly the result of a nimble IETF. Carter > On Feb 6, 2015, at 2:10 PM, Melinda Shore <[email protected]> wrote: > > On 2/6/15 8:25 AM, Carter Bullard wrote: >> Benson, >> I apologize if I’m way off base here, but it seems to me that the first task >> that >> the working group took on is unfinished. The IETF doesn’t normally charter >> WGs >> to generate I-D’s, normally the task is to generate RFCs. And of course >> the probability of the WG generating an RFC on its second charter, is >> probably >> equal to the WGs ability to generate RFC’s on its first. > > I don't think this is quite fair and I don't think it's particularly > accurate. RFCs are expensive to publish, in terms of the level of > effort required from a large number of people, ranging from working > group participants to the IESG to the RFC editor. Furthermore, since > resource are badly constrained, doing one thing means taking resources > away from another. Right now, the IETF is quite bogged down and it's > taking years to get useful specifications through the process and > into publication. Because of this it is not at all clear to me that > taking resources away from publishing protocol specs to publish more > requirements/problem statement/etc. documents is a very good tradeoff. > > Requirements documents are primarily *useful* to people who develop > protocols, etc. They aren't that useful to implementers (I don't > think I've ever gone back and looked at a requirements document while > implementing a protocol - I look at the specifications). I think > it's very clearly in the interest of pretty much everybody but > the requirements document editors (because of their interest in > getting an RFC published with their names on it) to be a bit > more flexible so that we can have a somewhat more nimble IETF. > > Melinda > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
