Carter,
And the place where you and I part company is the emphasis placed on “process” (e.g., “the only relevant IETF process document for the NVO3 WG”) - I’m interested in seeing this WG deliver results ... both the WG charter and requirements documents are tools that can contribute to achieving that goal, but the focus should be on the goal, not the tools used to achieve it, IMHO. Thanks, --David (chair or past chair of 5 IETF WGs) From: Carter Bullard [mailto:[email protected]] Sent: Saturday, February 07, 2015 1:15 PM To: Black, David Cc: [email protected] Subject: Re: [nvo3] Proposed timeline for publishing Requirements Hey David, Its pretty simple … Reading only from the NVO3 charter, which I believe is the only relevant IETF process document for the NVO3 WG, and skipping to the paragraphs that describe how the protocols will be developed.... The NVO3 WG may produce requirements for a network virtualization control plane, and will select, extend, and/or develop one protocol for each of the functional interfaces identified to support the architecture. I interpret that to mean that a requirements document will identify functional interfaces, from which one protocol will be selected, extended and/or developed. I think that document should be an RFC. The NVO3 WG may produce requirements for network virtualization data planes based on encapsulation of virtual network traffic over an IP- based underlay data plane. Such requirements should consider OAM and security. Based on these requirements the WG will select, extend, and/or develop one or more data plane encapsulation format(s). I interpret that to mean that a requirements document will be used to select, extend, and/or develop one or more data plane encapsulation format(s). I think that document should be an RFC. My only point, is that if you do not take whatever requirements documents you have to RFC, then you will not have completed the dependent task defined in the WG charter for developing NVO3 protocols. Yes you have an architecture RFC, great, first step in the charter. Next step is “may produce requirements”. Great, but if you move on to “select, extend and/or develop” you need to have formalized the requirements to the point where you can identify the functional interface. That I believe would be an in the form of an RFC. I hope you can understand my position. It is simply a superficial interpretation of the WG charter, and why I suggest that you should take any requirements documents that the WG would like to use, to RFC. Carter On Feb 7, 2015, at 12:52 PM, Black, David <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
