Hey Alia, Thanks for responding. I’m not disappointed. I think a requirements RFC for the data plane would improve the result, and possibly save a few meetings worth of time, but you won’t know until you go down one path, and see where you end up at the end.
And I hate to keep harping on what seems so simple to me. But how does a WG proceed with “Based on these requirements the WG will select, extend and/or develop ...” without a description of "these requirements" ??? This is a challenge for the chairs and AD, and if they don’t see an issue then who am I to point it out. Maybe the only real hurdle is if the I-Ds that are going to be used conform to BCP 78 and 79, and 6702, and had some form of Last Call. Carter > On Feb 9, 2015, at 10:21 AM, Alia Atlas <[email protected]> wrote: > > Carter, > > I wrote the charter with the WG chairs. That paragraph says "may" because it > is NOT a > requirement for the WG to produce a protocol requirements draft. It says may > because it > is up to the WG chairs. I would prefer not to see drafts progressing if they > don't need to > live as RFCs and be useful for a long period of time. These types of drafts > can become > either meaningless (out of sync when the protocol spec is written) or simply > unneeded for > future (everything relevant is in the protocol spec). > > I understand that you are disappointed with Benson's call. > > Regards, > Alia > > > > On Sat, Feb 7, 2015 at 1:52 PM, Carter Bullard <[email protected] > <mailto:[email protected]>> wrote: > 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] >> <mailto:[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] <mailto:[email protected]>] >> Sent: Saturday, February 07, 2015 1:15 PM >> To: Black, David >> Cc: [email protected] <mailto:[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> > > _______________________________________________ > 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
