Hi Daniel, Sriram, Thomas, Vyasraj, and Cristian,

Thank you for the effort put into this document. 

I reviewed this document in the past (https://mailarchive.ietf.org/arch/msg/opsawg/MBFQhNQHqhtoTKTH5XeZHbXwFTA/), so I have only minor points:

# Consider adding a brief text to remind that the header includes a mandatory header and optional fields and extension headers. This would help digest some of the IEs you define.

# Guidance on template usage

CURRENT:
   When 3GPP specifications state that a field shall not
   be interpreted, the Exporting Process SHOULD use a Template that
   omits the corresponding IE per Section 8 of [RFC7011]:

I think this discussion fits better under the operational considerations section. I would move this text there.

Also, I don’t think the normative language is really needed.

# The content of Section 3 highly duplicates what is in the IANA section. The normative behavior is what is provided under the description of the IANA section, IMO. I would cleanup the text for consistency.

# Duplicate normative behavior

CURRENT:
   Reserved bits
   in exported gtpuQFI and gtpuPduType values MUST be set to zero by the
   Exporting Process and MUST be ignored by the Collecting Process.

Vs.

gtpuQFI
      The two most significant bits are reserved, MUST
      be exported as zero, and MUST be ignored on receipt.

and

gtpuPduType

      The four most significant
      bits are reserved, MUST be exported as zero, and MUST be ignored
      on receipt.

## Please keep the normative language in one place. Having it under the IE is better.

## s/ gtpuQFI and gtpuPduType values/ gtpuQFI and gtpuPduType IEs

# This is about registering IEs, not allocating them

OLD: Table 2 lists the GTP-U IEs to be allocation 

NEW: Table 2 lists the GTP-U IEs to be registered


OLD: GTP-U IEs to be allocated

NEW: GTP-U IEs to be registered

# Derived

CURRENT:
      This IE is
      derived from the observed packet header and does not export the
      GTP-U Length field defined in Section 5.1 of [TS.29281].

“derived” is a bit ambiguous. I think “computed” is better here.

# S-flag & set clarification

OLD: gtpuFlags.  When the S flag is not set, this IE is not meaningful.

NEW: gtpuFlags.  When the S flag of the gtpuFlags IE is set to 0, this IE is not meaningful.

# How the presence is determined?  

CURRENT:
      The presence of this extension header is
      interpreted based on the extension header flag value from
      gtpuFlags.  When the PDU Session Container extension header is not
      present, this IE is not meaningful.  

Can we please be explicit this is based on E bit?

# reserved bits are already covered in the description

OLD:
   Additional Information:  Refer to Section 5.5.3.3 of the 3GPP
      specification [TS.38415] and Section 5.7.1.1 of the 3GPP
      specification [TS.23501].  The reserved bits in the exported octet
      are set to zero.

NEW:
   Additional Information:  Refer to Section 5.5.3.3 of the 3GPP
      specification [TS.38415] and Section 5.7.1.1 of the 3GPP
      specification [TS.23501].  

# nit: Examples?

CURRENT:
                MSB -   0     1    2    3    4    5    6    7   - LSB
                      +----+----+----+----+----+----+----+----+
                      |     Reserved      |  4 bit PDU Type   |
                      +----+----+----+----+----+----+----+----+


      Examples:

There is only one example listed there. Please s/Examples/Example

Cheers,
Med