David, > -----Original Message----- > From: Black, David [mailto:[email protected]] > Sent: Wednesday, September 17, 2014 5:24 PM > To: Yakov Rekhter > Cc: [email protected] > Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues > > > > Ok, this seems fine for stating requirements. When changing the > > > document to Informational, I suggest adding a sentence or two to > > > Section 1 to expand on its title - in essence these keywords are > > > being used to state protocol design requirements, not protocol > > > implementation/behavior requirements. > > > > Would you please propose "a sentence or two" to add to Section 1 ? > > After the existing text: > > This informational document uses these keywords to express requirements > for protocol design in contrast to the more common use of these keywords > in standards track documents to express requirements for protocol > implementation, deployment and/or usage.
Thanks ! I'll add this to the revised draft. Yakov. > > Thanks, > --David > > > -----Original Message----- > > From: Yakov Rekhter [mailto:[email protected]] > > Sent: Wednesday, September 17, 2014 5:12 PM > > To: Black, David > > Cc: [email protected] > > Subject: RE: [nvo3] WG Last Call on draft-ietf-nvo3-vm-mobility-issues > > > > David, > > > > > -----Original Message----- > > > From: Black, David [mailto:[email protected]] > > > Sent: Wednesday, September 17, 2014 4:25 PM > > > To: Yakov Rekhter > > > Cc: [email protected] > > > Subject: RE: [nvo3] WG Last Call on > > > draft-ietf-nvo3-vm-mobility-issues > > > > > > Yaakov, > > > > > > On 2119 keywords. > > > > > > > From 3.1: > > > > > > > > This document assumes that within a given non-trivial L2 > physical > > > > domain traffic from/to VMs that are in that domain, and belong > > > > to > > > the > > > > same L2-based CUG MUST have the same VLAN-ID. > > > > > > > > In the above "MUST" indicates that in the context of this document > > > > the assumption about VLAN-ID can not be violated. > > > > > > Lower case "must" is fine for stating an assumption, and I would > > > suggest doing so. > > > > Ok. > > > > > > > > > From 3.5: > > > > > > > > In other words, the > > > > policies > > > that > > > > control connectivity between a given VM and its peers MUST NOT > > > change > > > > as the VM moves from one L2 physical domain to another. > > > > > > > > .... > > > > > > > > > Moreover, > > > > policies, if any, within the L2 physical domain that contain a > given > > > > VM MUST NOT preclude realization of the policies that control > > > > connectivity between this VM and its peers. > > > > > > > > In the above "MUST" and "MUST NOT" indicates that in the context > > > > of this document any policies within the L2 physical domain can > > > > not interfere with the policies that control connectivity between > > > > and given VM and its peers. > > > > > > Ok, this seems fine for stating requirements. When changing the > > > document to Informational, I suggest adding a sentence or two to > > > Section 1 to expand on its title - in essence these keywords are > > > being used to state protocol design requirements, not protocol > > > implementation/behavior requirements. > > > > Would you please propose "a sentence or two" to add to Section 1 ? > > > > Yakov. > > > > > > > > Thanks, > > > --David > > > > > > > > > > -----Original Message----- > > > > From: Yakov Rekhter [mailto:[email protected]] > > > > Sent: Wednesday, September 17, 2014 9:03 AM > > > > To: Black, David > > > > Cc: Benson Schliesser; [email protected] > > > > Subject: Re: [nvo3] WG Last Call on > > > > draft-ietf-nvo3-vm-mobility-issues > > > > > > > > David, > > > > > > > > > Three quick questions: > > > > > > > > > > (1) Why is this draft intended as standards track? What > > > > > protocol or > > > > standard > > > > > does it specify? > > > > > Both the problem statement and framework drafts are > Informational. > > > > > > > > Good point. The draft should be progressed as Informational. > > > > > > > > > (2) What is the nature of the use of RFC 2119 terms (e.g., > > > > > "MUST") in this document? > > > > > > > > To answer this question let's look at few examples of the use of > > > > RFC2119 terms in the document: > > > > > > > > From 3.1: > > > > > > > > This document assumes that within a given non-trivial L2 > physical > > > > domain traffic from/to VMs that are in that domain, and belong > > > > to > > > the > > > > same L2-based CUG MUST have the same VLAN-ID. > > > > > > > > In the above "MUST" indicates that in the context of this document > > > > the assumption about VLAN-ID can not be violated. > > > > > > > > From 3.5: > > > > > > > > In other words, the > > > > policies > > > that > > > > control connectivity between a given VM and its peers MUST NOT > > > change > > > > as the VM moves from one L2 physical domain to another. > > > > > > > > .... > > > > > > > > > Moreover, > > > > policies, if any, within the L2 physical domain that contain a > given > > > > VM MUST NOT preclude realization of the policies that control > > > > connectivity between this VM and its peers. > > > > > > > > In the above "MUST" and "MUST NOT" indicates that in the context > > > > of this document any policies within the L2 physical domain can > > > > not interfere with the policies that control connectivity between > > > > and given VM and its peers. > > > > > > > > > > > > > > (3) Why are the security considerations "TBD"? Do the authors > > > > > really think that's acceptable? > > > > > > > > The authors hope that once the document is accepted as an NVO3 WG > > > > document, this section will be completed based on the feedback > > > > we'll receive from the NVO3 WG. > > > > > > > > > Also, a 1-week WG LC time period is really short - that will not > > > > > permit me to do a thorough technical review of this draft. > > > > > > > > > > Thanks, > > > > > --David > > > > > > > > > > > -----Original Message----- > > > > > > From: nvo3 [mailto:[email protected]] On Behalf Of Benson > > > > > > Schliesser > > > > > > Sent: Friday, September 12, 2014 5:42 PM > > > > > > To: [email protected] > > > > > > Subject: [nvo3] WG Last Call on > > > > > > draft-ietf-nvo3-vm-mobility-issues > > > > > > > > > > > > Dear NVO3 Contributors - > > > > > > > > > > > > This message is to initiate a Working Group Last Call for > > > > > > Comments on > > > > draft > > > > - > > > > > > ietf-nvo3-vm-mobility-issues. The chairs believe there is > > > > > > consensus to > > > > subm > > > > it > > > > > > this draft to the IESG for publication. Please review it and > > > > > > provide > > > > feedba > > > > ck > > > > > > on the mailing list by 19-Sep-2014. > > > > > > > > > > > > As a reminder, this is not an opportunity to vote. Please do > > > > > > not post > > > > messa > > > > ges > > > > > > that simply indicate support. Rather, substantial comments and > > > > > > feedback is encouraged. > > > > > > > > > > > > For your convenient reference, the latest version of the draft > > > > > > can be > > > > found > > > > at > > > > > > https://tools.ietf.org/html/draft-ietf-nvo3-vm-mobility-issues- > 03. > > > > > > > > > > > > Thanks, > > > > > > -Benson & Matthew > > > > > > > > > > > > _______________________________________________ > > > > > > 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
