Export of GTP-U Information in IP Flow Information Export (IPFIX)
draft-ietf-opsawg-ipfix-gtpu-18

[Ballot comment]
Thanks to Tim H for the SECDIR review.

Please consider Tim's comment from the SECIDR review; but converting the SHOULD to MUST might require slightly more text to explain the guidance.

My other comments are otherwise covered by other reviews.

[Ballot comment]
Thanks for this document. I support the DISCUSS from Ketan concerning following items:
1. Section 5.7: gtpuTotalHdrLength is too small
2. Sections 3, 5.5, and 5.6: the E flag does not indicate the presence of a PDU Session Container
3. Sections 3 and 5.8: packet-versus-flow semantics are not defined

[Ballot comment]
Thanks to Tim Hollebeek for their secdir review.

Section 9, para 1:  Perhaps RFC 7011 could be referenced here?  While it is dated in its specific recommendations (for example, RFC 5246 has been obsoleted by RFC 9846), it still has much good information about security in this context.

Section 9, para 2:  Why not MUST (or must)?  When is it appropriate for an app or operator to ignore this advice?  And to be clear, RFC7011 section 11.8 addresses the sensitivity of the information, but protection of that information is deemed to be out of scope, either state that here, or reference a different specification.

Normative References:  None of the 3GPP references have links for where they can be found.  Are they, in fact, freely available?

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

Note: this review is based on my very quick skim through the referenced 3GPP spec
and I might have got this wrong. If so, please correct me.

Comments are inline in the idnits output of v18. Look for the  tag at
the end to ensure you are seeing the full review.

I have a few points that I would like to discuss.

Sections 5.5 and 5.6

423   Description:  6-bit QoS flow identifier field defined in PDU Session
424       Container extension header of GTP-U.  This may be used to
425       determine the QoS flow and QoS profile which are associated with
426       the received packet.  The presence of the PDU Session Container
427       extension header is indicated by the E (Extension Header) bit in
428       the gtpuFlags IE.  When the E bit is set to 0, this IE is not
429       meaningful.  The two most significant bits are reserved, MUST be
430       exported as zero, and MUST be ignored on receipt.

470   Description:  4-bit PDU type field defined in PDU Session Container
471       extension header of GTP-U.  This field indicates the structure of
472       the PDU session user plane frame.  The presence of the PDU Session
473       Container extension header is indicated by the E (Extension
474       Header) bit in the gtpuFlags IE.  When the E bit is set to 0, this
475       IE is not meaningful.  The four most significant bits are
476       reserved, MUST be exported as zero, and MUST be ignored on
477       receipt.

The E flag indicates that the Next Extension Header field is valid; it
does not indicated which extension header is present. GTP-U supports multiple
extension-header types and a chain in which each header identifies the next
header. Therefore, E=1 does not mean that the chain contains a PDU
Session Container, and that container need not be the first extension header
in the chain.

As written, an exporter can treat unrelated extension-header bytes as QFI or
PDU Type. Please revise both IE descriptions to require the Exporting Process
to parse the extension-header chain and locate a PDU Session Container before
exporting either IE. When no PDU Session Container is present, or when the
chain is malformed, truncated, or cannot be safely parsed, the IE should be
omitted. The document should also specify the behavior if multiple PDU
Session Containers are encountered; though I don't know if that is even possible.

Section 5.7

504 5.7.  gtpuTotalHdrLength
506   Name:  gtpuTotalHdrLength
508   ElementID:  TBD1
510   Description:  8-bit field indicating the total length in octets of
511       the observed GTP-U header, including the mandatory 8-octet header
512       and any optional fields and extension headers defined in Sections
513       5.1 and 5.2 of the 3GPP specification [TS.29281].  This IE is
514       computed from the observed packet header and does not export the
515       GTP-U Length field defined in Section 5.1 of [TS.29281].
517   Abstract Data Type:  unsigned8
519   Data Type Semantics:  quantity
521   Additional Information:  Refer to Sections 5.1 and 5.2 of [TS.29281].
523   Reference:  [RFC-to-be]

An IPFIX unsigned8 can represent values only from 0 through 255. GTP-U has a
variable-length header, its extension headers can be chained, and each
Extension Header Length is encoded in four-octet units. A valid GTP-U header
can therefore exceed 255 octets. Please use a data type that is large enough
to cover the headers.

If the intention were to limit to 255, then the specification does not state
what an exporter does when the observed header is longer than 255 octets.
Implementations could truncate, stop at the value at 255, wrap it modulo 256,
omit the IE, or reject the record. These outcomes are not interoperable, and
several report an incorrect length.

Section 5.8

525 5.8.  gtpuHeaderSection
527   Name:  gtpuHeaderSection
529   ElementID:  TBD2
531   Description:  This Information Element carries a series of n octets
532       from the observed GTP-U header, including the mandatory header and
533       any optional fields and extension headers defined in Sections 5.1
534       and 5.2 of the 3GPP specification [TS.29281], as a series of
535       octets in IPFIX.
537   Abstract Data Type:  octetArray
539   Data Type Semantics:  default
541   Additional Information:  Refer to Section 5 of [TS.29281].
543   Reference:  [RFC-to-be]

The phrase "a series of n octets from the observed GTP-U header" does not
indicate whether the value begins at the first GTP-U header octet, whether it
contains the entire header or only a contiguous portion, whether an arbitrary
subsection is permitted, how truncation is detected, whether padding is
allowed, what values of n are valid, or what happens when the captured header
is itself truncated or malformed.

RFC 7012 requires applicable octetArray length constraints to be specified.

Please define one interoperable semantic model. A simple approach is
to require the value to start at the first GTP-U header octet, contain a
contiguous set of bytes, and contain the complete header whenever it is available
and fits. Truncation should either be prohibited or explicitly permitted with
a reliable way for the collector to recognize it. One possible option is to
require gtpuTotalHdrLength whenever gtpuHeaderSection is shorter than the
complete header. The definition should also cover malformed/truncated input
and prohibit bytes beyond the observed GTP-U header.

[Ballot comment]
I also have one comment to offer:

586   The IEs described in this document export GTP user plane information
587   about packet forwarding in a 3GPP network.  In particular, TEIDs,
588   QFIs, PDU types, and GTP-U header sections can enable correlation of
589   traffic with individual PDU sessions and, depending on deployment,
590   with subscriber activity.  Implementations and operators therefore
591   MUST treat this data as sensitive network telemetry data.
593   Applications and operators using the IEs specified in this document
594   SHOULD evaluate the sensitivity of this information in their
595   deployment context, and apply the data-at-rest storage guidance in
596   Section 11.8 of [RFC7011] as appropriate.
598   Operators SHOULD restrict access to these exported IEs, apply
599   retention limits appropriate to sensitive operational telemetry, and
600   SHOULD NOT export gtpuHeaderSection unless required by the
601   operational use case.  An Exporting Process MUST NOT include octets
602   beyond the observed GTP-U header in gtpuHeaderSection.

The section correctly identifies the data as sensitive and covers
storage, access, retention, and minimization. It does not explicitly cover
confidentiality, integrity, and peer authentication while records are
transported from the Exporting Process to the Collecting Process. RFC 7011
addresses these properties and can be referenced for these aspects as well.

Please consider text along the following lines:

  Exporting Processes and Collecting Processes that exchange these
  Information Elements SHOULD use the secure transport mechanisms specified
  in Section 11 of [RFC7011] to provide confidentiality, integrity, and peer
  authentication, particularly when exporting gtpuHeaderSection.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-opsawg-ipfix-gtpu-18
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits, replies would be appreciated even if only for my own education).

Special thanks to Benoît Claise for the shepherd's concise write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.


## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 3 SHOULD

Why not a "MUST" in `When 3GPP specifications state that a field shall not be interpreted, the Exporting Process SHOULD use a Template that omits the corresponding IE` ? Like Med Boucadair, I do not think that BCP14 should be used in the sentence.

Also note https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### Section 5

I find very unusual to have the normative description of several flags *only* inside the IANA section and not in section 3. This only makes the implementers' job more complex. Consider moving the normative text into section 3.

### Section 5.1

In addition to the global DISCUSS on section 5, what is the meaning of `Version(3b)` in the flag description ? I have a guess but a PS-level draft should not leave any room for ambiguities.

The draft is also completely silent on the value & semantic on this 'Version' number.

Finally, what is the expected receiver behaviour when bit 4 (labelled as "0") is set ?

[Ballot comment]

## COMMENTS (non-blocking)

### Abstract
s/This document introduces/This document specifies/ as it is PS.

### Section 3 "meaningless"

What is meant by "meaningless" in `When the S flag of the gtpuFlags IE is set to 0, this IE is not meaningful` ?

Does it mean that this IE is to be ignored or must not be sent ?

Same comment for gtpuQFI and gtpuPduType.

### Section 4

Please add a reference to `gNodeB` as it does not appear in https://rpc-wiki.rfc-editor.org/doku.php?id=abbrev_list

Is `IP tunnel` the same as the GTP mentioned earlier ?

### Sections 5.1 & 5.5

The HTML formatting is really unclear that there are *two* examples as it appears as a single example.

Why not using a Figure caption ?

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
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

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-ipfix-gtpu-14. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions that we must complete.

First, in the IPFIX Information Elements registry in the IP Flow Information Export (IPFIX) Entities registry group located at:

https://www.iana.org/assignments/ipfix/

six information elements are to have their description updated and their references changed to [ RFC-to-be ] as follows:

Name: gtpuFlags
ElementID: 505
Description:
8-bit flags field indicating the version of GTP-U header, protocol type, and presence of extension header, sequence number and N-PDU number defined in Section 5.1 of the 3GPP specification [TS.29281]. The bits are exported as observed.

The basic encoding is 8 bits. The layout of the encoding is as follows:


MSB - 0 1 2 3 4 5 6 7 - LSB
+----+----+----+----+----+----+----+----+
| Version(3b) | PT | 0 | E | S | PN |
+----+----+----+----+----+----+----+----+

Examples:

value : 0x34
binary: 00110100
decode: Version=1, PT=1, spare=0, E=1, S=0, PN=0

value : 0x36
binary: 00110110
decode: Version=1, PT=1, spare=0, E=1, S=1, PN=0

Abstract Data Type: unsigned8
Data Type Semantics: flags
Additional Information: Refer to Section 5.1 of [TS.29281].
Reference: [RFC-to-be]

-

Name: gtpuMsgType
ElementID: 506
Description: 8-bit field which indicates the type of the GTP-U message as mentioned in Section 5.1 of the 3GPP specification [TS.29281].
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Additional Information: Refer to Section 5.1 of the 3GPP specification [TS.29281].
Reference: [RFC-to-be]

-

Name: gtpuTEid
ElementID: 507
Description: 32-bit tunnel endpoint identifier field unambiguously identifies a tunnel endpoint in the receiving GTP-U protocol entity for a given UDP/IP endpoint.
Abstract Data Type: unsigned32
Data Type Semantics: identifier
Additional Information: Refer to Section 5.1 of the 3GPP specification [TS.29281].
Reference: [RFC-to-be]

-

Name: gtpuSequenceNum
ElementID: 508
Description: 16-bit sequence number field defined in the GTP-U. This field is interpreted based on the sequence number flag value from gtpuFlags. When the S flag is not set, this IE is not meaningful.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Additional Information: Refer to Section 5.1 of the 3GPP specification [TS.29281].
Reference: [RFC-to-be]

-

Name: gtpuQFI
ElementID: 509
Description:
6-bit QoS flow identifier field defined in PDU Session Container extension header of GTP-U. This may be used to determine the QoS flow and QoS profile which are associated with the received packet. 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. The two most significant bits are reserved, MUST be exported as zero, and MUST be ignored on receipt.

The basic encoding is 8 bits. The layout of basic encoding is as follows:


MSB - 0 1 2 3 4 5 6 7 - LSB
+----+----+----+----+----+----+----+----+
|Reserved | 6 bit QFI value |
+----+----+----+----+----+----+----+----+

Examples:

value : 0x08
binary: 00001000
decode: 001000 - QFI value

value : 0x3e
binary: 00111110
decode: 111110 - QFI value

Abstract Data Type: unsigned8
Data Type Semantics: identifier
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.
Reference: [RFC-to-be]

-

Name: gtpuPduType
ElementID: 510
Description: 4-bit PDU type field defined in PDU Session Container extension header of GTP-U. This field indicates the structure of the PDU session user plane frame. 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 and is exported as specified in Section 3. The four most significant bits are reserved, MUST be exported as zero, and MUST be ignored on receipt.

The basic encoding is 8 bits. The layout of basic encoding is as follows:


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

Examples:

value : 0x01
binary: 00000001
decode: 0001 - PDU Type value

Abstract Data Type: unsigned8
Data Type Semantics: identifier
Additional Information: Refer to Section 5.5.3 of the 3GPP specification [TS.38415]. The reserved bits in the exported octet are set to zero.
Reference: [RFC-to-be]

As this document requests changes to registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, also in the IPFIX Information Elements registry in the IP Flow Information Export (IPFIX) Entities registry group located at:

https://www.iana.org/assignments/ipfix/

two new Information Elements are to be registered as follows:

Name: gtpuTotalHdrLength
ElementID: [ TBD-at-registration ]
Description: 8-bit field indicating the total length in octets of the observed GTP-U header, including the mandatory 8-octet header and any optional fields and extension headers defined in Sections 5.1 and 5.2 of the 3GPP specification [TS.29281]. 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].
Abstract Data Type: unsigned8
Data Type Semantics: quantity
Additional Information: Refer to Sections 5.1 and 5.2 of [TS.29281].
Reference: [RFC-to-be]

Name: gtpuHeaderSection
ElementID: [ TBD-at-registration ]
Description: This Information Element carries a series of n octets from the observed GTP-U header, including the mandatory header and any optional fields and extension headers defined in Sections 5.1 and 5.2 of the 3GPP specification [TS.29281], as a series of octets in IPFIX.
Abstract Data Type: octetArray
Data Type Semantics: default
Additional Information: Refer to Section 5 of [TS.29281].
Reference: [RFC-to-be]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-06-25):

From: The IESG
To: IETF-Announce
CC: benoit@everything-ops.net, draft-ietf-opsawg-ipfix-gtpu@ietf.org, mjethanandani@gmail.com, opsawg-chairs@ietf.org, opsawg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Export of GTP-U Information in IP Flow Information Export (IPFIX)) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Export of
GTP-U Information in IP Flow Information Export (IPFIX)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-06-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document introduces IP Flow Information Export (IPFIX)
  Information Elements to report information contained in the Generic
  Packet Radio Service Tunneling Protocol(GTP) User Plane header such
  as Tunnel Endpoint Identifier, and data contained in its session
  container extension header.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-gtpu/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Yes, there is consensus on this document, even if it's a little bit difficult to get community feedback on OPSAWG drafts that essentially contain a series of IPFIX information elements.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is one implementation status, as mentioned in the "Implementation Status" section

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The GTP technology comes from 3GPP.
The "Liaison statement between IETF and 3GPP on GTP-U" was sent (and DMM WG feedback was asked in creating this LS).

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The IPFIX doctors were involved in the development of the draft, and the feedback collected.
Note that they pushed back on the IANA IPFIX information elements preallocation, since a draft was being presented, and potential changes could be incorporated.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The RFC5706bis Operational Considerations is present.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track, as most IPFIX Information Elements documents recently.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.
There is an IPR declaration. https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-opsawg-ipfix-gtpu

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

5 authors, all willing.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Just one nit, which I have mentioned to the authors, regarding an unused reference.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Thinking some more about it, RFC7133 might be moved from normative to informative. Up to AD.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

NA

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No issue on that front.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

"IPFIX Information Elements" registry

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Yes, there is consensus on this document, even if it's a little bit difficult to get community feedback on OPSAWG drafts that essentially contain a series of IPFIX information elements.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There is one implementation status, as mentioned in the "Implementation Status" section

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The GTP technology comes from 3GPP.
The "Liaison statement between IETF and 3GPP on GTP-U" was sent (and DMM WG feedback was asked in creating this LS).

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The IPFIX doctors were involved in the development of the draft, and the feedback collected.
Note that they pushed back on the IANA IPFIX information elements preallocation, since a draft was being presented, and potential changes could be incorporated.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The RFC5706bis Operational Considerations is present.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track, as most IPFIX Information Elements documents recently.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.
There is an IPR declaration. https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-opsawg-ipfix-gtpu

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

5 authors, all willing.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Just one nit, which I have mentioned to the authors, regarding an unused reference.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Thinking some more about it, RFC7133 might be moved from normative to informative. Up to AD.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

NA

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No issue on that front.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

"IPFIX Information Elements" registry

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/