Hi Ilango, > On Dec 5, 2019, at 3:01 AM, Ganga, Ilango S <[email protected]> wrote: > > Hello Alissa, > > Thanks for your review and comments. Please see below for our responses > in-line, enclosed within <Response> </Response>. Let us know if you are > satisfied with the resolution.
These changes look good. I will clear my DISCUSS when the document gets updated. Thanks, Alissa > > Regards, > Ilango Ganga > Geneve Editor > > > <>-----Original Message----- > From: Alissa Cooper via Datatracker <[email protected] > <mailto:[email protected]>> > Sent: Tuesday, December 3, 2019 11:53 AM > To: The IESG <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]>; > Matthew Bocci <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]> > Subject: Alissa Cooper's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS > and COMMENT) > > Alissa Cooper has entered the following ballot position for > draft-ietf-nvo3-geneve-14: Discuss > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Exciting to see this work progressing. > > Section 3.5 (and Section 7): > > "Type (8 bits): Type indicating the format of the data contained in > this option. Options are primarily designed to encourage future > extensibility and innovation and so standardized forms of these > options will be defined in a separate document." > > I'm a little confused about what is expected to happen with the option > classes and types. Are all future option types in the 0x0000..0x00FF range > expected to be specified in a single separate document? If not, that should > be clarified. I also think there needs to be a normative requirement that > such future specifications define all of the types associated with the option > classes. > > IG> <Response> It is not necessary that all option types associated with an > option class to be defined in a single document. Additional option types > could evolve and be defined later in separate documents. We will clarify by > updating the sentence as follows: > “Type (8 bits): Type indicating the format of the data contained in > this option. Options are primarily designed to encourage future > extensibility and innovation and so standardized forms of these > options will be defined in separate documents.” > </Response> > > In the registry defined in Section 7, I think the table needs a column for > the document to reference for each option class definition. That way when > option classes are defined in the 0x0000..0x00FF range, implementers and > operators will be able to find the reference and understand the semantics of > the types. > For the vendor-specific options this can be optional, but still would be nice > to list if such documentation exists. > > IG> <Response> > This was brought up during the IANA review, we request IANA to add additional > column to provide reference(s) and also it would be useful to add Contact > information where applicable. > </Response> > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1: > > s/Current work/Work/ > > IG> <Response> Agreed, we will update text as suggested. > </Response> > > > What is meant by "service based context for interposing advanced middleboxes?" > (I think the verb tense is tripping me up -- are the middleboxes already > there?) > > IG> <Response> We can rephrase the text as follows for clarity: > “There are nearly endless uses for this metadata, > ranging from storing input port identifiers for simple security policies to > sending service based context for advanced middlebox applications.” > </Response> > > > Section 1.2: > > "A transit device MAY be capable of understanding the Geneve packet > format but does not originate or terminate Geneve packets." > > I don't think normative MAY is appropriate here. > > IG> <Response> We will change text to lower case ‘may’ as follows: > “may be capable of understanding the Geneve packet” > </Response> > > > Section 2.1: > > s/the VXLAN spec/the VXLAN spec [RFC7348]/ > > IG> <Response> We will revise text as suggested. > “the VXLAN spec [RFC7348]” > </Response> > > Section 2.2: > > "Transit devices MAY be able to interpret the options" > > Normative MAY is not appropriate here. The normative requirement is captured > in the last sentence of the paragraph. > > IG> <Response> Yes the last sentence provides normative requirements. So we > will use lower case ‘may’ in this sentence. > “may be able to interpret the options” > </Response> > > > Section 4.6: > > "Conversely, when performing LRO, a NIC MAY assume that a > binary comparison of the options (including unknown options) is > sufficient to ensure equality" > > Normative MAY is not appropriate here. > > IG> <Response> The last part of the sentence provides normative text. So we > will use lower case ‘may’ in this sentence. > “a NIC may assume that a binary comparison of the options” > </Response>
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
