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]> 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]> 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] <[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]> 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] <[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 > > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
