Re: [nvo3] Alissa Cooper's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

["Ganga, Ilango S" <[e-mail]>]

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.



Regards,

Ilango Ganga

Geneve Editor





-----Original Message-----
From: Alissa Cooper via Datatracker <[e-mail]>
Sent: Tuesday, December 3, 2019 11:53 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; Matthew Bocci <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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>