David, And it is still pretty simple. Want to do something different from what is in the charter, change the charter. But as long as the charter specifies a process, the WG should follow that process.
As a charter member of the Internet Society, I think charters are important. But I do not think that my opinion is more than that of a normally quiet active WG member. Carter > On Feb 7, 2015, at 1:32 PM, Black, David <[email protected]> wrote: > > 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 > <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] <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 > <https://www.ietf.org/mailman/listinfo/nvo3> > > _______________________________________________ > nvo3 mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nvo3 > <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
