I have a few comments.

Thanks,
Anoop

--

section 3.5
>>>

Packets in which the total length of all
options is not equal to the 'Opt Len' in the base header are
invalid and MUST be silently dropped if received by an endpoint.

>>>
what if none of the options are critical and the implementation is choosing
to remove the options headers without even processing them?  does this
still apply?  if so, it would be good to call it out.

section 4.1
what is the guidance for ttl?  like dscp, there is also a uniform and pipe
model for ttl.

section 4.1.3
may be helpful to add a reference to rfc 8293.

editorial
- endpoint, tunnel endpoint, geneve endpoint are used interchangeably.
also endpoint and end point.  suggest change all to "tunnel endpoint" which
is the only term defined.
- in the definition of ECMP, change:
  while avoiding reordering a single stream. ->
  while avoiding reordering of packets within a flow.
  (stream is not used or defined anywhere else.)
- transit and non-terminating are used interchangeably.  suggest change to
transit which is defined.
- section 3.5.1
  Options or their ordering, ... -> Options, or their ordering, ...
- section 5
  "(VXLAN, NVGRE )" has an extra space
- section 6.1
  DTLs -> DTLS
- section 6.2
  change implementation to specification in the text below.
>>

Implementation of such a mechanism is beyond the scope of this
   document.

>>
- section 6.3

 Authentication mechanism -> authentication mechanism




> *From:* Bocci, Matthew (Nokia - GB) [mailto:[email protected]
> <[email protected]>]
> *Sent:* Tuesday, October 9, 2018 2:08 AM
> *To:* NVO3 <[email protected]>
> *Cc:* [email protected]
> *Subject:* Working Group Last Call and IPR Poll for
> draft-ietf-nvo3-geneve-08.txt
>
>
>
> This email begins a two-week working group last call for
> draft-ietf-nvo3-geneve-08.txt.
>
>
>
> Please review the draft and post any comments to the NVO3 working group
> list. If you have read the latest version of the draft but have no comments
> and believe it is ready for publication as a standards track RFC, please
> also indicate so to the WG email list.
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as an Author or a Contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers from
> all the Authors and Contributors.
>
>
>
> Currently there are two IPR disclosures against this document.
>
>
>
> If you are not listed as an Author or a Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> This poll will run until Friday 26th October.
>
>
>
> Regards
>
>
>
> Matthew and Sam
>
> _______________________________________________
> 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

Reply via email to