Carter,
> 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.
Perhaps you should think more about the types and contents of requirements
documents. Those four router requirements RFCs contain *implementation*
requirements for routers, and analogous implementation requirements are
to be found in almost every IETF protocol specification.
In contrast, the NVO3 requirements documents (and I'm an author of some
of them) are protocol *design* requirements documents; they do not contain
implementation requirements (those go into the protocol specs). There is a
difference, really there is ...
Just for grins, I dug up a design concerns draft of mine (it includes
design requirements) from over a decade ago:
http://tools.ietf.org/html/draft-black-rdma-concerns-00
That draft accomplished its intended purpose of influencing the WG's design
activity; in that case, publication as an RFC was not needed (and in fact
the draft even said so up front).
Thanks,
--David
> -----Original Message-----
> From: nvo3 [mailto:[email protected]] On Behalf Of Carter Bullard
> Sent: Friday, February 06, 2015 4:09 PM
> To: Melinda Shore
> Cc: [email protected]
> Subject: Re: [nvo3] Proposed timeline for publishing Requirements
>
> 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
> >
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
