[nvo3] Mirja Kühlewind's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind 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:
----------------------------------------------------------------------

Thanks for the really well written document that addresses all transport
related question well (and thanks to David for the early TSV review!). I only
have one minor process point that need to be addressed before publication:

Inline with RFC6335 the Assignee and Contact of the port entry should also be
updated to IESG <[e-mail]> and IETF Chair <[e-mail]> respectively.


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

1) One small comment/question on the editorial note in sec 4.4.1:
"It was discussed during TSVART early review if the level of
   requirement for maintaining tunnel MTU at the ingress has to be "MAY"
   or "SHOULD".  The discussion concluded that it was appropriate to
   leave this as "MAY", considering the high level of state to be
   maintained.
I would have preferred a SHOULD and I'm not sure I understand what state your
are talking about...?

2) And one more small question on sec 4.4.1. in general:
Is the assumption that all tunnel packets have the same options (and therefore
same Geneve header length) at a certain ingress, or should the announced MTU
always consider the maximum length that a certain ingress could produce. Would
be good to clarify this in the document!

3) Section 6:
"When crossing an untrusted link, such as the public Internet, IPsec
   [RFC4301] may be used to provide authentication and/or encryption of
   the IP packets formed as part of Geneve encapsulation."
Should this maybe be a normative SHOULD and not a lower case "may"?

3) And one random thought on the protocol design (given we all love to design
protocols :-) ): Was it considered to require to have critical options first in
order to speed up processing?