> > 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, --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
