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

[Alissa Cooper via Datatracker <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-nvo3-geneve-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/



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

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1:

s/Current work/Work/

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?)

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.

Section 2.1:

s/the VXLAN spec/the VXLAN spec [RFC7348]/

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.

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.