Hi, Andy. I'm always glad for the opportunity to learn from others' experience in IETF process. Thanks for your advice.
That being said, there are two things that I should point out. First, Matthew and I do intend to add milestones for each draft that the WG adopts. These drafts are not yet entirely known, but we expect them to fit into the categories outlined by the milestones attached to the proposed charter text. I plan to mark the "category" milestone Done when the specific drafts (milestones TBD) are all finished. This would include any multicast solutions that are adopted. Second, its not clear that the WG will necessarily adopt any of the various individual drafts that people have written. You are correct that we only expect to adopt drafts that fit into the scope outlined by the charter. And just because somebody puts effort into writing a draft does not ensure that it will be adopted. Likewise, adoption does not guarantee publication. In all cases we will progress documents based on whether they add constructively and materially to the WG body of work, and whether there is consensus to do so. Cheers, -Benson On Sep 2, 2014 7:11 AM, "Andrew G. Malis" <[email protected]> wrote: > Benson, > > I've got a bit of experience when it comes to drafting WG charters. :-) > Especially when working on the milestones, it helps to envision the > expectations for the documents that will be produced by the WG, as there > tends to be a direct correspondence between documents and milestones, so > that milestones can be ticked off as documents are published. There are > currently a couple of multicast-related individual drafts intended for the > WG, however In the current draft charter, there are no specific milestones > related to multicast. If there is a reasonable expectation that at least > one of these drafts will be adopted by the WG and be published as a > stand-alone document, then there should probably be a corresponding > milestone in the charter to track that work. > > Thanks, > Andy > > > > On Mon, Sep 1, 2014 at 6:42 PM, Anoop Ghanwani <[email protected]> > wrote: > >> Benson, >> >> Broadcast is usually a special case of multicast, so by including >> multicast, we would have automatically included broadcast (at least that's >> the way I see it). >> >> If, as you suggest, multicast is already within scope because we haven't >> explicitly excluded it, then I'm fine with the charter text. In that >> sense, even the milestones can be broadly interpreted as containing >> solutions for multicast. At the very least we will have this thread to >> point to, should any questions arise at some point in the future with >> regard to scope of the charter. Hopefully, all folks that would approve >> the charter (WG, ADs, IESG, etc.) would be on the same page. >> >> The main reason why I'm bringing this up is that there are existing >> implementations that do not support multicast, so in that sense, offering a >> solution does not automatically mean that the problem is solved for both >> unicast and multicast. Of course, those are not IETF solutions. >> >> Anoop >> >> >> On Mon, Sep 1, 2014 at 12:15 PM, Benson Schliesser <[email protected] >> > wrote: >> >>> Hi, Anoop, Linda, Ramki, and other contributors - >>> >>> First, just to be clear, I should remind you that we aren't voting here. >>> With that in mind, the important thing for you to do is help me resolve the >>> issue that I asked about. >>> >>> So, let me ask the question in a slightly different way. You are >>> proposing that we expand the current text to explicitly identify multicast >>> and unicast traffic. Does that mean that you intend for the WG to exclude >>> broadcast traffic? >>> >>> The current text of the proposed charter is meant to be open to all >>> sorts of common network traffic. It is nonspecific about what those types >>> of traffic may be, to avoid giving anybody the impression that we are >>> limiting the WG work etc. What is the purpose of changing that? >>> >>> Thanks, >>> -Benson >>> On Aug 30, 2014 5:22 PM, "ramki Krishnan" <[email protected]> wrote: >>> >>>> Hi Benson, >>>> >>>> >>>> >>>> [ag] "The NVO3 WG will develop solutions for network virtualization >>>> covering both unicast and multicast traffic handling based on the following >>>> architectural tenets:” >>>> >>>> >>>> >>>> I agree with Linda’s observation and support Anoop’s suggestion for the >>>> modified charter text. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Ramki >>>> >>>> >>>> >>>> *From:* nvo3 [mailto:[email protected]] *On Behalf Of *Benson >>>> Schliesser >>>> *Sent:* Friday, August 29, 2014 7:56 PM >>>> *To:* [email protected] >>>> *Subject:* [nvo3] Multicast issues draft >>>> >>>> >>>> >>>> Hi, Linda and Anoop - >>>> >>>> >>>> >>>> (I’ve changed the message Subject to more accurately describe this >>>> topic.) >>>> >>>> >>>> >>>> On Aug 29, 2014, at 6:06 PM, Anoop Ghanwani <[email protected]> >>>> wrote: >>>> >>>> >>>> >>>> >>>> [Linda] The entire charter didn't even mention application initiated >>>> multicast. It is wrong. NVA can eliminate (or reduce) ARP/ND related >>>> broadcast/multicast, but not application initiated multicast. >>>> >>>> The current proposed MILESTONES have separate deliverables for WG >>>> adoption and FOR IESG review, and very detailed categories being explicitly >>>> spelled out. Therefore, at minimum, should have one line on the protocols >>>> to handle hosts/applications initiated multicast. >>>> >>>> >>>> >>>> [ag] I agree with Linda here. While it sounds like there is agreement >>>> that the problem needs to be addressed by the working group, it would be >>>> useful to at least have an explicit mention of multicast somewhere in the >>>> charter. Perhaps we could change the following line from: >>>> >>>> "The NVO3 WG will develop solutions for network virtualization based on >>>> the >>>> >>>> following architectural tenets:" >>>> >>>> to: >>>> >>>> "The NVO3 WG will develop solutions for network virtualization covering >>>> both unicast and multicast traffic handling based on the >>>> >>>> following architectural tenets:” >>>> >>>> >>>> >>>> I’m not opposed to mentioning multicast in the charter, but t wouldn’t >>>> be my preferred choice. >>>> >>>> >>>> >>>> The way that I think about it, multicast support is an appropriate >>>> topic for the requirements drafts. And it should be discussed in the >>>> architecture draft, as well as any solutions drafts where it might be >>>> applicable. But it would be sub-optimal to load the charter with a >>>> discussion of the various types of traffic that might be found in the >>>> overlay: broadcast, known and unknown unicast, multicast supporting network >>>> protocols (such as address resolution etc), multicast on behalf of >>>> applications (“application specific multicast”), etc. >>>> >>>> >>>> >>>> The current charter text does not exclude work on multicast, which is >>>> good. And I don’t see any reason to explicitly call it out as a unique >>>> topic separate from the architecture, control plane, data plane, and use >>>> cases. If I’m missing something please help me understand. Otherwise I’d >>>> prefer to leave the proposed charter text as-is. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> -Benson >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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
