Melinda, Maybe you should go back further. How about say RFC 985, 1009, 1716, and 1812. Four RFCs devoted solely to trying to get the requirements for routers down. At a time when some of the best work was done.
The original charter for NVO3 states that optional requirements documents could be generated, from which solutions would be implemented. The WG decided to go down the optional route, in order to go after solutions. The original charter stated that these solutions would come from requirements documents. I interpret that to mean that the requirements would be IETF documents, which I interpret to be RFCs. The only issue is, if you can proceed successfully, then proceed. Experience suggests that formal goals help a WG to be successful. Httpbis had simple requirements, catalog security properties and provide improved bindings of semantics to underlying transport, no need for a requirements document there. Not like it needed to change an application protocol much to be successful, and the charter left a lot unspecified to allow for whatever else anybody wanted to throw in. No mention in the charter that the WG would work through requirements documents to reach solutions. If you think NVO3 is an equivalent to Httpbis, then I’m at a disadvantage, as I’m not that good at thinking at that level. Its up to the WG to decide if it can proceed successfully without formal requirements. My opinion is that there are a lot of ‘ time to market ‘ pressures that will compel implementations to be less than adequate, and without good control over the design goals, these implementations will get leverage over the market that the WG is trying to influence. Which would be a shame. Carter > On Feb 6, 2015, at 3:35 PM, Melinda Shore <[email protected]> wrote: > > On 2/6/15 11:15 AM, Carter Bullard wrote: >> Hey Melinda, >> If you’re point is that you have to go back to 1999 to find an IETF protocol >> that >> was successful, then seems that you’re in agreement with my point. > > I'm not. HTTPbis doesn't have a requirements document, either, > nor do a large number of other successful protocols. Arguably > the IETF produced more useful, relevant documents back when > requirements documents and whatnot were not the norm. > > I think that in general requirements documents are helpful to > the process of specification and have some historical value, but > at this point it's very clearly the case that the IETF process > has slowed down to the point that it's gotten nearly impossible > to publish documents in a timely way. It's happened at the same > time that documents that used not to be part of the process - > problem statements, requirements documents, gap analyses, and > so on - have become part of the culture. There's nothing in > any IETF process document that requires them. Allow me to repeat > that: there's nothing in any IETF process document that requires > them. So, to the extent that they're useful, yay, to the extent > that they bog the IETF down in non-specification work, boo. > > 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
