This document can be seen as NVO3 encapsulation design team report and compares 3 typical 
 data plane encapsulation formats including GENEVE, GUE, VXLAN-GPE and 
 explores technical problem and limitation and provides guidance and recommendation
 for common encapsulation design. It also lays foundation for future extension to Geneve 
 encapsulation defined in RFC8926.
   
 I believe it is well written and ready for publication, here are a few comments
 to v-(10) I would like author to consider:
 
Major issues: 
 No

 Minor issues:
 1. Section 5.3 said 
   "The B bit indicates the packet is an ingress replicated
   Broadcase, Unknown Unicast, or Multicast packet.  The O bit indicates
   an OAM packet.
   Issues with VXLAN-GPE [nvo3_vxlan_gpe] are as follows:"
      
   [Qin]: s/Broadcase/Broadcast
 2. Section 5.3 said:
   "
      *  Security, e.g., of the VNI, has not been addressed by GPE.
   "
   [Qin]: I am wondering how this statement is related to section 6.2.2? Do we need add rationale here to 
   explain why security of VNI can be be addressed? e.g.,
   can we use UDP checksum to protect the payload including VNI carried in VXLAN-GPE header?
   or UDP checksum is always set to zero?
   or can we extend VXLAN-GPE to carry HMAC-like Message Authentication Code
   (MAC)?
   
 3. Section 5.3 said:
   "
      Although a shim header could be used for security and other
      extensions, this has not been defined yet and its implications on
      offloading in NICs are not understood.
   "
   [Qin]: Can we add rationale why offloading in NIC is not understood, is this becos
	GPE is not extensible?
 4.Section 6.2.2 said:
   "
   This is desirable since we still have the UDP header for ECMP, the
   NVO3 header is in plain text so it can be read by network elements,
   and different security or other payload transforms can be supported
   "
   [Qin]: 
   I can understand DTLS and IPSEC are two different security schemes.
   How do we understand transforms in the "payload transforms"?
   
 5. Section 6.3 said:
   "
   It is hard to predict which options will be implemented in which
   piece of hardware and when.  That depends on whether the hardware
   will be in the form of a NIC providing increasing offload
   capabilities to software NVEs, or a switch chip being used as an NVE
   gateway towards non-NVO3 parts of the network, or even a transit
   device that participates in the NVO3 dataplane, e.g., for OAM
   purposes.
   "
   [Qin] The second sentence seems too long, I think the key messages can be 
   rephrased as three factors decides which options is implemented in which hardware?
   How about making the following change：
   "
   It is hard to predict which options will be implemented in which
   piece of hardware and when. That depends on:
   o whether the hardware will be in the form of a NIC providing increasing offload
     capabilities to software NVEs;
   o or a switch chip being used as an NVE gateway towards non-NVO3 parts of the network, 
   o or even a transit device that participates in the NVO3 dataplane, e.g., for OAM
     purposes.
	 "
 6.Section 6.4 said:
   "
   The recommended minimum total svailable header length is 64 bytes.
   "
   [Qin]s/svailable/available
 
7.Section 6.6.  TLV versus Bit Fields
   [Qin]: If we have already decided to choose geneve as common encapsulation
   and geneve chooses to use TLV for extension. Why should we discuss comparison
   between TLV and Bit Fields.
   Should common encapsulation consideration only focus on TLV?
 
8. Section 6.7.  Control Plane Considerations
   [Qin] The 2nd paragraph of section 6.6 also discuss using control plane to control 
   the order of the TLVs, which seems overlapping with section 6.7?
   Is this intentional?
 
9. Section 6.9
   If we need a larger VNI, an extension can
   be used to support that.
   [Qin]: In which case where we need a larger VNI？ Can we provide a use case
   to demonstrate the limitation of 24 bit VNI.
 
10.Section 7 said:
   "The DT studied whether VNI should be in the base header or in an
    extension header and whether it should be a 24-bit or 32-bit
    field."1.  
   [Qin] Similarly, Not clear when we will use 32 bit field?

11.Section 7 said:
   "
   By using Geneve options it is
   possible to get in band parameters like switch id, ingress port,
   egress port, internal delay, and queue in telemetry defined
   extension TLV from switches. 
   "
   [Qin] What is queue in telemetry defined extension TLV? Can not parse.
   Are you saying "queue in telemetry" defined in extension TLV?

12. Section 7 said:
   "
   9.  The DT has addressed the usage models while considering the
       requirements and implementations in general including software
       and hardware.

   "   
   [Qin] Are usage models related to Useful Extensions Use Cases defined in Section 6.2?
   If Yes, please add referenced section. 

13. With recommendation given in section 7, Do you think RFC8926 Geneve Document needs 
 to be revised as RFC8926bis document, or you expect for each extension for OAM, performance 
 measurement, security, a separate document is needed to extend RFC8926 to support each extension?