Export of UDP Options Information in IP Flow Information Export (IPFIX)
draft-ietf-opsawg-tsvwg-udp-ipfix-14

This document has a normative reference to draft-ietf-tsvwg-udp-options, because of which this document was held back. Since the other document has cleared the WG and recently been sent forth as a publication request, releasing this document for announcement to sent.

This document references draft-ietf-tsvwg-udp-options, and normatively depends on it. Holding it in the "Approved-announcement to be sent" state, till the other draft clears WGLC. At that point, this draft can be sent to the RFC Editor, where it will encounter a MISREF.

[Ballot comment]
Thanks for discussing my discuss points. As wrote in the email I moved one clarification point to comment here.

> Another discussion - as this specification is based on
> draft-ietf-tsvwg-udp-options, that draft already defines number
> of Kind values
> for SAFE and UNSAFE options then why we are not defining IEs for
> them?
>

>[Med] Not sure to get your point. We do have IEs that can exports kinds for both SAFE and UNSAFE. We used to have these in one single IEn but abandoned that design because it was suboptimal for an encoding compactness perspective.

>I see, then it was not that clear that we are abandoned that desing in favour of encoding effiency. I think it would need  some backgoround and rational on that to clarify the design choice.



I also believe publication of this draft should have been waited to be publised along with or after draft-ietf-tsvwg-udp-options and I strongly suggest that.

I also support Roman's comment that kind of echos why I have my previous comment on waitning on publication.

[Ballot discuss]
Thanks for working on this specification. Thanks to Tommy Pauly for the TSVART review.

I would like to discuss something that might not be completely technical but we should understand that aspect better. The sub-sections of section 4 defines udpXOptions and "reference" itself. My understanding is that it should reference to the draft where UDP options are defined. My understading can be wrong, but this is what is done for tcpOptions in RFC5102. So, I would like to discuss if we are referencing to the correct document or not.

Another discussion - as this specification is based on draft-ietf-tsvwg-udp-options, that draft already defines number of Kind values for SAFE and UNSAFE options then why we are not defining IEs for them?

[Ballot comment]
I also believe publication of this draft should have been waited to be publised along with or after draft-ietf-tsvwg-udp-options and I strongly suggest that.

I also support Roman's comment that kind of echos why I have my previous comment on waitning on publication.

[Ballot comment]
Thank you for writing this document. Also thank you to Jouni Korhonen for the Ops-Dir review (https://datatracker.ietf.org/doc/review-ietf-opsawg-tsvwg-udp-ipfix-10-opsdir-lc-korhonen-2024-05-21/) and the excellent catch in it.

I support Roman's DISCUSS as well.

[Ballot discuss]
** Section 7.1.  This section is under-specified and contains typos relevant to registration. 

-- The "IPFIX Information Elements" registry doesn’t have a “Value” field.  It is “ElementID”

-- The mandatory elements of the "IPFIX Information Elements" registry defined in the registration template of Section 2.1 of RFC7012 are missing – description, datatype, and status.  I appreciate that the first two in this list are found in their respective sections.  However, there is no guidance to IANA to extract those values as such.

-- Per the Reference field value, is a section number permitted?  No other current entry in this registry includes a section number.  The definition of references from RFC7012 doesn’t seem to account for it either --  “reference - Identifies additional specifications that more precisely define this item or provide additional context for its use.”

[Ballot comment]
I agree w/ Eric V on the timing of this publication with respect to the publication of draft-ietf-tsvwg-udp-options.  Since this draft will sit in the editor's queue, why not do them together?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tsvwg-udp-ipfix-12

Thank you for the work put into this document.

Thanks to Joe Touch for his int-dir reviews but also kudos to the authors for reacting to Joe's issue about the SAFE/UNSAFE split and the normative reference to draft-ietf-opsawg-ipfix-tcpo-v6eh. The I-D is now in much better shape.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Thomas Graf for the shepherd's detailed 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

# COMMENTS (non-blocking)

## Link to draft-ietf-tsvwg-udp-options

There is a normative reference to draft-ietf-tsvwg-udp-options, so all is good, but it might have been better to wait for draft-ietf-tsvwg-udp-options rather than having to review this I-D without knowing what will be the published specification of UDP options.

## Section 1

s/widely deployed in *operators* networks/widely deployed in networks/ IPFIX is largely deployed outside of operators (in the sense if (I)SP) ;-)

s/The IE specified in Section 4.1 uses the new abstract data type defined/The IE specified in Section 4.1 uses the new abstract data type *unsigned256* defined/ ?

## Section 3

While is it nice for the reader to have a short description of UDP options, it does not say anything about "Kind" as in `Options indicated by Kind values`... So, the reader must anyway read the UDP options draft. Suggest adding a short description of the Kind.

## SAFE or safe

This document uses both "safe" and "SAFE" for what seems the same concept. Please select one writing everywhere to reduce confusion.

## Use of MUST w/o BCP14

There are a couple of "MUST" and "MUST NOT" in the text without any BCP14 template. This is OK, but the "MUST" is then equivalent to a "must", so suggest either using only lower case "must" or including BCP14 template. The lowercase "must" is anyway normative as it is part of a Proposed Standard but somehow less defined as the BCP14 "MUST".

## Section 4.1

s/The bit is set to 1 if the corresponding safe UDP option is observed in the Flow/The bit is set to 1 if the corresponding safe UDP option is observed *at least once* in the Flow/

s/The bit is set to 0 if the option is *not* observed in the Flow./The bit is set to 0 if the option is *never* observed in the Flow./

Same comment for the unsafe options in section 4.2

What about "UDP option extended format" ? I.e., where the Kind is expressed over 2 octets. Suggest adding some text restricting the use of this I-D to only "normal 1-octet Kind".


## Section 4.3

I am afraid that I do not understand what value to use based ont the Description. Are the only allowed values: 127 and 254 ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-tsvwg-udp-ipfix-12; we had also previously reviewed -08. If any part of this review is inaccurate, please let us know.

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: [I-D.ietf-tsvwg-udp-options]

IANA understands that, upon approval of this document, there is a single action which 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/

five new registrations are to be made as follows:

ElementID: [ TBD-at-Registration ]
Name: udpSafeOptions
Abstract Data Type: unsigned256
Data Type Semantics: flags
Status: current
Description: Observed safe UDP options in a Flow. The information is encoded in a set of bit fields.

Options are mapped to bits according to their option numbers. UDP option Kind 0 corresponds to the least-significant bit in the udpSafeOptions IE while Kind 191 corresponds to the 65th most-significant bit of the IE. The bit is set to 1 if the corresponding safe UDP option is observed in the Flow. The bit is set to 0 if the option is not observed in the Flow. The first 64 most-significant bits MUST be set to 0.

The reduced-size encoding per Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed safe UDP options. For example, if only option Kinds <= 31 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned32, or if only option Kinds <= 63 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned64.

The presence of udpSafeExIDList is an indication that the SAFE Experimental option is observed in a Flow. The presence of udpSafeExIDList takes precedence over setting the corresponding bit in the udpSafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpSafeExIDList IE, the Exporter MUST NOT set to 1 the EXP flag of the udpSafeOptions IE that is reported for the same Flow.
Units:
Range:
Additional Information: See the "UDP Option Kind Numbers" registry at [registry created by [I-D.ietf-tsvwg-udp-options]].
See [I-D.ietf-tsvwg-udp-options] for more details about UDP options.
Reference: [ RFC-to-be; Section 4.1 ]
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: udpUnsafeOptions
Abstract Data Type: unsigned64
Data Type Semantics: flags
Status: current
Description: Observed unsafe UDP options in a Flow. The information is encoded in a set of bit fields.

Options are mapped to bits according to their option numbers. UDP option Kind 192 corresponds to the least-significant bit in the udpUnsafeOptions IE while Kind 255 corresponds to the most-significant bit of the IE. The bit is set to 1 if the corresponding unsafe UDP option is observed in the Flow. The bit is set to 0 if the option is not observed in the Flow.

The reduced-size encoding per Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed unsafe UDP options.

The presence of udpUnsafeExIDList is an indication that the UNSAFE Experimental option is observed in a Flow. The presence of udpUnsafeExIDList takes precedence over setting the corresponding bit in the udpUnsafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpUnsafeExIDList IE, the Exporter MUST NOT set to 1 the UEXP flag of the udpUnsafeOptions IE that is reported for the same Flow.
Units:
Range:
Additional Information: See the "UDP Option Kind Numbers" registry at [registry created by [I-D.ietf-tsvwg-udp-options]].
See [I-D.ietf-tsvwg-udp-options] for more details about UDP options.
Reference: [ RFC-to-be; Section 4.2 ]
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: udpExID
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Status: current
Description: Observed ExID in an Experimental option (EXP, Kind=127) or an UNSAFE Experimental option (UEXP, Kind=254).
Units:
Range:
Additional Information: See the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry at [registry created by [I-D.ietf-tsvwg-udp-options]].

See [I-D.ietf-tsvwg-udp-options] for more details about ExIDs.
Reference: [ RFC-to-be; Section 4.3 ]
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: udpSafeExIDList
Abstract Data Type: basicList
Data Type Semantics: list
Status: current
Description: Observed ExIDs in the Experimental option (EXP, Kind=127).

A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an EXP option.
Units:
Range:
Additional Information: See the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry at [registry created by [I-D.ietf-tsvwg-udp-options]].

See [I-D.ietf-tsvwg-udp-options] for more details about ExIDs.
Reference: [ RFC-to-be; Section 4.4 ]
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: udpUnsafeExIDList
Abstract Data Type: basicList
Data Type Semantics: list
Status: current
Description: Observed ExIDs in the UNSAFE Experimental option (UEXP, Kind=254).

A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an UEXP option.
Units:
Range:
Additional Information: See the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry at [registry created by [I-D.ietf-tsvwg-udp-options]].

See [I-D.ietf-tsvwg-udp-options] for more details about ExIDs.
Reference: [ RFC-to-be; Section 4.5 ]
Date: [ TBD-at-Registration ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request. We also note that the changes in -12 are as a result of expert feedback during the review process for -08.

We understand that this is 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 2024-06-19):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org, mjethanandani@gmail.com, opsawg-chairs@ietf.org, opsawg@ietf.org, thomas.graf@swisscom.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Export of UDP Options 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
UDP Options 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 2024-06-19. 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 specifies new IP Flow Information Export (IPFIX)
  Information Elements for UDP options.

Discussion Venues

  This note is to be removed before publishing as an RFC.

  Discussion of this document takes place on the Operations and
  Management Area Working Group Working Group mailing list
  (opsawg@ietf.org), which is archived at
  https://mailarchive.ietf.org/arch/browse/opsawg/.

  Source for this draft and an issue tracker can be found at
  https://github.com/boucadair/udp-ipfix.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-tsvwg-udp-options: Transport Options for UDP (None - Internet Engineering Task Force (IETF))

* 3. UDP Options at a Glance

    Add "to" :

    e.g., to discover a path MTU or share timestamps



* 4. New UDP IPFIX Information Elements

The URLs in the "note" should be listed in the references. The note should say "to be updated / removed by the RFC editor".



* 4.2. and 4.3. / Description
The information is encoded in a set of 16-bit fields. Each 16-bit
field carries the observed ExID in an EXP option.
I mis-parsed this as if each 16-bit field carries an EXP option: "Each 16-bit field carries the observed ExID / in an EXP option."

It may be clearer as, "Each 16-bit field carries the ExID which was observed in an EXP option."



* 4.2. and 4.3.

No mention is made of whether ordering is important or unimportant.



* 5. Examples

Add "a":

    If a udpOptions IE is exported for this Flow,



* Under Figure 2:
Show quoted text
The last 0x9858 should be 0x9658 to correspond with the following point 2 and Figure 4.

0x9858 and 0x9658 are very similar. Could more distinct values be used?



* Figure 3:
If udpOptions IE is exported for this Flow, then that IE will
have bits in positions 127 (EXP) and 254 (UEXP) set to 1 (Figure 3).

The goal is to set bits 127 and 254, so it's confusing to see what appears to be bits 1 and 128 set:

Intuitively one would expect to see these bits:

However since bit 2^n is set for option n, the problem is really with the misleading bit numbering in the figure.

ie, the example would be clearer without the numbering.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

IANA understands that, upon approval of this document, there is a single action which we must complete.

IANA also understands that the action requested in the IANA Considerations section of this document is dependent upon the approval of and completion of IANA Actions in another document:

[I-D.ietf-tsvwg-udp-options]

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

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

three new IPFIX Informaiton Elements are to be registered as follows:

ElementID: [ TBD-at-Registration ]
Name: udpOptions
Abstract Data Type: unsigned256
Data Type Semantics: flags
Status: current
Description: Observed UDP options in a Flow. The information is encoded in a set of bit fields.

Options are mapped to bits according to their option numbers. UDP option Kind 0 corresponds to the least-significant bit in the udpOptions IE while Kind 255 corresponds to the most-significant bit of the IE. A bit is set to 1 if the corresponding UDP option is observed in the Flow. The bit is set to 0 if the option is not observed in the Flow.

To cover the 0-255 Kind range, up to 256 flags can be set in the value field. The reduced-size encoding specified in Section 6.2 of [RFC7011] is followed whenever fewer octets are needed to report observed UDP options. For example, if only option Kinds <= 32 are observed, then the value can be encoded as unsigned32, or if only option Kinds <= 63 are observed, then the value can be encoded as unsigned64.
Units:
Range:
Additional Information: See the assigned UDP options in the "UDP Option Kind Numbers" registry at [URL_IANA_UDP_OPTIONS].
Reference: [ RFC-to-be; Section 4.1 ]
Revision: [ TBD-at-Registration ]
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: udpSafeExperimentalOptionExID
Abstract Data Type: octetArray
Data Type Semantics: identifier
Status: current
Description: Observed Experiments ID (ExIDs) in the Experimental option (EXP, Kind=127).

The information is encoded in a set of 16-bit fields. Each 16-bit field carries the observed ExID in an EXP option.
Units:
Range:
Additional Information: See the assignments in the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry at [URL_IANA_UDP_ExIDs].
Reference: [ RFC-to-be: Section 4.2 ]
Revision: [ TBD-at-Registration ]
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: udpUnsafeExperimentalOptionExID
Abstract Data Type: octetArray
Data Type Semantics: identifier
Status: current
Description: Observed Experiments ID (ExIDs) in the UNSAFE Experimental option (UEXP, Kind=254).

The information is encoded in a set of 16-bit fields. Each 16-bit field carries the observed ExID in an UEXP option.
Units:
Range:
Additional Information: See the assignments in the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry at [URL_IANA_UDP_ExIDs].

See [I-D.ietf-tsvwg-udp-options] for more details about ExIDs.
Reference: [ RFC-to-be; Section 4.3 ]
Revision: [ TBD-at-Registration ]
Date: [ TBD-at-Registration ]

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 this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action 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

Request for Last Call review by INTDIR Completed: Ready with Issues. Reviewer: Joseph Touch. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2024-05-10):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org, mjethanandani@gmail.com, opsawg-chairs@ietf.org, opsawg@ietf.org, thomas.graf@swisscom.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Export of UDP Options 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
UDP Options 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 2024-05-10. 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 specifies new IP Flow Information Export (IPFIX)
  Information Elements for UDP options.

Discussion Venues

  This note is to be removed before publishing as an RFC.

  Discussion of this document takes place on the Operations and
  Management Area Working Group Working Group mailing list
  (opsawg@ietf.org), which is archived at
  https://mailarchive.ietf.org/arch/browse/opsawg/.

  Source for this draft and an issue tracker can be found at
  https://github.com/boucadair/udp-ipfix.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-tsvwg-udp-options: Transport Options for UDP (None - Internet Engineering Task Force (IETF))

# Document Shepherd Write-Up for Group Documents

*This version is dated 10 February 2024.*

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?

Within the working group, this document was seen as valuable since it defines.
the IPFIX entities of the draft-ietf-tsvwg-udp-options defined UDP options and
is going to be submitted to the IESG at about the same time while aligned with
the newly defined TCP options IPFIX entities described in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-05#section-4.

The authors decided to keep the UDP options IPFIX entities definition separate from
draft-ietf-opsawg-ipfix-tcpo-v6eh due to the draft-ietf-tsvwg-udp-options dependecies.

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

Consesus was achieved without any opposing voice.

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)?

This document defines new IPFIX entities for new UDP options defined in
draft-ietf-tsvwg-udp-options. The working group is not aware of any existing or
planned implementations. IPFIX entity 209 tcpOptions appears to be,
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DAqA/,
merly used to its ambiguity and suggested to deprecate as specified in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-10#section-8.1.
It is expected that the IPFIX entities defined in this document are going to be
implemented.

## 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.

Yes, the document received.

Transport area
https://mailarchive.ietf.org/arch/msg/opsawg/p9WGo52u2pBhjr8kIHjeYPwHECc/
https://mailarchive.ietf.org/arch/msg/opsawg/953SHdHE5-XmlvlneaDqHy2HmeA/

Internet area
https://mailarchive.ietf.org/arch/msg/opsawg/29dxzf6kBHMYrDP9cIjlqcwqPKc/

and IPFIX doctor
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

reviews while Operations area is pending. While the Internet Area review
remarked one minor point to be aligned with draft-ietf-tsvwg-udp-options about
applicability of UDP options in legacy transport receivers which was addressed
by the authors, the Transport Area directorate and the IPFIX doctors challenges
the correctness of the udpOptions data type. Wherever
this should be a new data type unsigned256 or a bitfield type instead of
unsigned according to reduced size encoding defined in
https://www.rfc-editor.org/rfc/rfc7011#section-6.2. The authors therefore
interoduced a new unsigned256 data type in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-08#name-new-ipfix-information-element
and a consensus,
https://mailarchive.ietf.org/arch/msg/opsawg/YbOuevvacJ0hwKRjPGaSaMVXRgk/,
has been achieved.


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.

IPFIX doctor review
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

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]?

N/A

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.

N/A (other than IDNITS)

## 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, it is. I have reviewed the document and had minor comments on wording which
was addressed by the authors.

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?

Transport, Internet area and IPFIX doctors have reviewed. I do not believe detailed
subsequent reviews are required.

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?

Proposed Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13, while waiting for more implementations and operational experience.

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.

A poll was sent to the list. The named authors has replied that there is no IPR.

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.

Yes

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.)

Some minor found and already addressed by authors.

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

No

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

N/A

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?

draft-ietf-tsvwg-udp-options is being prepared to be submitted to IESG.

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]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

The IPFIX entities created by this document references an IANA registry being created
by https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25

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.

N/A to this document but to draft-ietf-tsvwg-udp-options.


[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 10 February 2024.*

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?

Within the working group, this document was seen as valuable since it defines.
the IPFIX entities of the draft-ietf-tsvwg-udp-options defined UDP options and
is going to be submitted to the IESG at about the same time while aligned with
the newly defined TCP options IPFIX entities described in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-05#section-4.

The authors decided to keep the UDP options IPFIX entities definition separate from
draft-ietf-opsawg-ipfix-tcpo-v6eh due to the draft-ietf-tsvwg-udp-options dependecies.

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

Consesus was achieved without any opposing voice.

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)?

This document defines new IPFIX entities for new UDP options defined in
draft-ietf-tsvwg-udp-options. The working group is not aware of any existing or
planned implementations. IPFIX entity 209 tcpOptions appears to be,
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DAqA/,
merly used to its ambiguity and suggested to deprecate as specified in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-10#section-8.1.
It is expected that the IPFIX entities defined in this document are going to be
implemented.

## 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.

Yes, the document received.

Transport area
https://mailarchive.ietf.org/arch/msg/opsawg/p9WGo52u2pBhjr8kIHjeYPwHECc/

Internet area
https://mailarchive.ietf.org/arch/msg/opsawg/29dxzf6kBHMYrDP9cIjlqcwqPKc/

and IPFIX doctor
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

reviews while Operations area is pending. While the Internet Area review
remarked one minor point to be aligned with draft-ietf-tsvwg-udp-options about
applicability of UDP options in legacy transport receivers which was addressed
by the authors, the Transport Area directorate and the IPFIX doctors challenges
the correctness of the udpOptions data type. Wherever
this should be a new data type unsigned256 or a bitfield type instead of
unsigned according to reduced size encoding defined in
https://www.rfc-editor.org/rfc/rfc7011#section-6.2. The authors therefore
interoduced a new unsigned256 data type in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-08#name-new-ipfix-information-element
and a consensus,
https://mailarchive.ietf.org/arch/msg/opsawg/YbOuevvacJ0hwKRjPGaSaMVXRgk/,
has been achieved.


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.

IPFIX doctor review
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

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]?

N/A

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.

N/A (other than IDNITS)

## 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, it is. I have reviewed the document and had minor comments on wording which
was addressed by the authors.

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?

Transport, Internet area and IPFIX doctors have reviewed. I do not believe detailed
subsequent reviews are required.

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?

Proposed Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13, while waiting for more implementations and operational experience.

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.

A poll was sent to the list. The named authors has replied that there is no IPR.

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.

Yes

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.)

Some minor found and already addressed by authors.

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

No

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

N/A

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?

draft-ietf-tsvwg-udp-options is being prepared to be submitted to IESG.

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]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

The IPFIX entities created by this document references an IANA registry being created
by https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25

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.

N/A to this document but to draft-ietf-tsvwg-udp-options.


[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 10 February 2024.*

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?

Within the working group, this document was seen as valuable since it defines.
the IPFIX entities of the draft-ietf-tsvwg-udp-options defined UDP options and
is going to be submitted to the IESG at about the same time while aligned with
the newly defined TCP options IPFIX entities described in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-05#section-4.

The authors decided to keep the UDP options IPFIX entities definition separate from
draft-ietf-opsawg-ipfix-tcpo-v6eh due to the draft-ietf-tsvwg-udp-options dependecies.

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

Consesus was achieved without any opposing voice.

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)?

This document defines new IPFIX entities for new UDP options defined in
draft-ietf-tsvwg-udp-options. The working group is not aware of any existing or
planned implementations. IPFIX entity 209 tcpOptions appears to be,
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DAqA/,
merly used to its ambiguity and suggested to deprecate as specified in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-10#section-8.1.
It is expected that the IPFIX entities defined in this document are going to be
implemented.

## 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.

Yes, the document received.

Transport area
https://mailarchive.ietf.org/arch/msg/opsawg/p9WGo52u2pBhjr8kIHjeYPwHECc/

Internet area
https://mailarchive.ietf.org/arch/msg/opsawg/29dxzf6kBHMYrDP9cIjlqcwqPKc/

and IPFIX doctor
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

reviews while Operations area is pending. While the Internet Area review
remarked one minor point to be aligned with draft-ietf-tsvwg-udp-options about
applicability of UDP options in legacy transport receivers which was addressed
by the authors, the Transport Area directorate and the IPFIX doctors challenges
the correctness of the udpOptions data type. Wherever
this should be a new data type unsigned256 or a bitfield type instead of
unsigned according to reduced size encoding defined in
https://www.rfc-editor.org/rfc/rfc7011#section-6.2. The authors therefore
interoduced a new unsigned256 data type in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-08#name-new-ipfix-information-element
and a consensus,
https://mailarchive.ietf.org/arch/msg/opsawg/YbOuevvacJ0hwKRjPGaSaMVXRgk/,
has been achieved.


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.

IPFIX doctor review
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

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]?

N/A

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.

N/A (other than IDNITS)

## 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, it is. I have reviewed the document and had minor comments on wording which
was addressed by the authors.

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?

Transport, Internet area and IPFIX doctors have reviewed. I do not believe detailed
subsequent reviews are required.

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?

Proposed Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13, while waiting for more implementations and operational experience.

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.

A poll was sent to the list. The named authors has replied that there is no IPR.

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.

Yes

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.)

Some minor found and already addressed by authors.

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

No

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

N/A

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?

draft-ietf-tsvwg-udp-options is being prepared to be submitted to IESG.

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]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

The IPFIX entities created by this document references an IANA registry being created
by https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25

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.

N/A to this document but to draft-ietf-tsvwg-udp-options.


[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 10 February 2024.*

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?

Within the working group, this document was seen as valuable since it defines.
the IPFIX entities of the draft-ietf-tsvwg-udp-options defined UDP options and
is going to be submitted to the IESG at about the same time while aligned with
the newly defined TCP options IPFIX entities described in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-05#section-4.

The authors decided to keep the UDP options IPFIX entities definition separate from
draft-ietf-opsawg-ipfix-tcpo-v6eh due to the draft-ietf-tsvwg-udp-options dependecies.

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

Consesus was achieved without any opposing voice.

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)?

This document defines new IPFIX entities for new UDP options defined in
draft-ietf-tsvwg-udp-options. The working group is not aware of any existing or
planned implementations. IPFIX entity 209 tcpOptions appears to be,
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DAqA/,
merly used to its ambiguity and suggested to deprecate as specified in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-10#section-8.1.
It is expected that the IPFIX entities defined in this document are going to be
implemented.

## 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.

Yes, the document received.

Transport area
https://mailarchive.ietf.org/arch/msg/opsawg/p9WGo52u2pBhjr8kIHjeYPwHECc/

Internet area
https://mailarchive.ietf.org/arch/msg/opsawg/29dxzf6kBHMYrDP9cIjlqcwqPKc/

and IPFIX doctor
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

reviews while Operations area is pending. While the Internet Area review
remarked one minor point to be aligned with draft-ietf-tsvwg-udp-options about
applicability of UDP options in legacy transport receivers which was addressed
by the authors, the Transport Area directorate and the IPFIX doctors challenges
the correctness of the udpOptions data type. Wherever
this should be a new data type unsigned256 or a bitfield type instead of
unsigned according to reduced size encoding defined in
https://www.rfc-editor.org/rfc/rfc7011#section-6.2. The authors therefore
interoduced a new unsigned256 data type in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-08#name-new-ipfix-information-element
and a consensus,
https://mailarchive.ietf.org/arch/msg/opsawg/YbOuevvacJ0hwKRjPGaSaMVXRgk/,
has been achieved.


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.

IPFIX doctor review
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

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]?

N/A

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.

N/A (other than IDNITS)

## 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, it is. I have reviewed the document and had minor comments on wording which
was addressed by the authors.

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?

Transport, Internet area and IPFIX doctors have reviewed. I do not believe detailed
subsequent reviews are required.

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?

Internet Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13

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.

A poll was sent to the list. The named authors has replied that there is no IPR.

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.

Yes

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.)

Some minor found and already addressed by authors.

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

No

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

N/A

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?

draft-ietf-tsvwg-udp-options is being prepared to be submitted to IESG.

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]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

The IPFIX entities created by this document references an IANA registry being created
by https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25

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.

N/A to this document but to draft-ietf-tsvwg-udp-options.


[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 10 February 2024.*

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?

Within the working group, this document was seen as valuable since it defines.
the IPFIX entities of the draft-ietf-tsvwg-udp-options defined UDP options and
is going to be submitted to the IESG at about the same time while aligned with
the newly defined TCP options IPFIX entities described in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-05#section-4.

The authors decided to keep the UDP options IPFIX entities definition separate from
draft-ietf-opsawg-ipfix-tcpo-v6eh due to the draft-ietf-tsvwg-udp-options dependecies.

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

Consesus was achieved without any opposing voice.

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)?

This document defines new IPFIX entities for new UDP options defined in
draft-ietf-tsvwg-udp-options. The working group is not aware of any existing or
planned implementations. IPFIX entity 209 tcpOptions appears to be,
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DAqA/,
merly used to its ambiguity and suggested to deprecate as specified in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-10#section-8.1.
It is expected that the IPFIX entities defined in this document are going to be
implemented.

## 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.

Yes, the document received.

Transport area
https://mailarchive.ietf.org/arch/msg/opsawg/p9WGo52u2pBhjr8kIHjeYPwHECc/

Internet area
https://mailarchive.ietf.org/arch/msg/opsawg/29dxzf6kBHMYrDP9cIjlqcwqPKc/

and IPFIX doctor
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

reviews while Operations area is pending. While the Internet Area review
remarked one minor point to be aligned with draft-ietf-tsvwg-udp-options about
applicability of UDP options in legacy transport receivers which was addressed
by the authors, the Transport Area directorate and the IPFIX doctors challenges
the correctness of the udpOptions data type. Wherever
this should be a new data type unsigned256 or a bitfield type instead of
unsigned according to reduced size encoding defined in
https://www.rfc-editor.org/rfc/rfc7011#section-6.2. The authors therefore
interoduced a new unsigned256 data type in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-08#name-new-ipfix-information-element
and a consensus,
https://mailarchive.ietf.org/arch/msg/opsawg/wqP_V-UAn7-o0SQ4bbUCyeHeHCA/
https://mailarchive.ietf.org/arch/msg/opsawg/Sg1ZbGbvb2lLeh-XM6sjcL_DTOw/,
is pending wherever this is the best choice.


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.

IPFIX doctor review
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

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]?

N/A

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.

N/A (other than IDNITS)

## 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, it is. I have reviewed the document and had minor comments on wording which
was addressed by the authors.

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?

Transport, Internet area and IPFIX doctors have reviewed. I do not believe detailed
subsequent reviews are required.

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?

Internet Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13

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.

A poll was sent to the list. The named authors has replied that there is no IPR.

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.

Yes

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.)

Some minor found and already addressed by authors.

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

No

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

N/A

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?

draft-ietf-tsvwg-udp-options is being prepared to be submitted to IESG.

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]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

The IPFIX entities created by this document references an IANA registry being created
by https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25

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.

N/A to this document but to draft-ietf-tsvwg-udp-options.


[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?

Within the working group, this document was seen as valuable since it defines.
the IPFIX entities of the draft-ietf-tsvwg-udp-options defined UDP options and
is going to be submitted to the IESG at about the same time while aligned with
the newly defined TCP options IPFIX entities described in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-05#section-4.

The authors decided to keep the UDP options IPFIX entities definition separate from
draft-ietf-opsawg-ipfix-tcpo-v6eh due to the draft-ietf-tsvwg-udp-options dependecies.

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

Consesus was achieved without any opposing voice.

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)?

This document defines new IPFIX entities for new UDP options defined in
draft-ietf-tsvwg-udp-options. The working group is not aware of any existing or
planned implementations. IPFIX entity 209 tcpOptions appears to be,
https://mailarchive.ietf.org/arch/msg/opsawg/gaJ9-A6i3Z4grgHT86OUym_DAqA/,
merly used to its ambiguity and suggested to deprecate. It is expected that the
IPFIX entities defined in this document are going to be implemented.

## 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.

Yes, the document received.

Transport area
https://mailarchive.ietf.org/arch/msg/opsawg/p9WGo52u2pBhjr8kIHjeYPwHECc/

Internet area
https://mailarchive.ietf.org/arch/msg/opsawg/29dxzf6kBHMYrDP9cIjlqcwqPKc/

and IPFIX doctor
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

reviews while Operations area is pending. While the Internet Area review
remarked one minor point to be aligned with draft-ietf-tsvwg-udp-options about
applicability of UDP options in legacy transport receivers which was addressed
by the authors, the Transport Area directorate and the IPFIX doctors challenges
the correctness of the udpOptions data type. Wherever
this should be a new data type unsigned256 or a bitfield type instead of
unsigned according to reduced size encoding defined in
https://www.rfc-editor.org/rfc/rfc7011#section-6.2. The authors therefore
interoduced a new unsigned256 data type in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-08#name-new-ipfix-information-element
and a consensus, https://mailarchive.ietf.org/arch/msg/opsawg/wqP_V-UAn7-o0SQ4bbUCyeHeHCA/,
is pending wherever this is the best choice.


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.

IPFIX doctor review
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

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]?

N/A

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.

N/A (other than IDNITS)

## 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, it is. I have reviewed the document and had minor comments on wording which
was addressed by the authors.

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?

Transport, Internet area and IPFIX doctors have reviewed. I do not believe detailed
subsequent reviews are required.

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?

Internet Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13

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.

A poll was sent to the list. The named authors has replied that there is no IPR.

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.

Yes

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.)

Some minor found and already addressed by authors.

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

No

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

N/A

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?

draft-ietf-tsvwg-udp-options is being prepared to be submitted to IESG.

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]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

The IPFIX entities created by this document references an IANA registry being created
by https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25

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.

N/A to this document but to draft-ietf-tsvwg-udp-options.


[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?

Within the working group, this document was seen as valuable since it defines.
the IPFIX entities of the draft-ietf-tsvwg-udp-options defined UDP options and
is going to be submitted to the IESG at about the same time while aligned with
the newly defined TCP options IPFIX entities described in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-05#section-4.

The authors decided to keep the UDP options IPFIX entities definition separate from
draft-ietf-opsawg-ipfix-tcpo-v6eh due to the draft-ietf-tsvwg-udp-options dependecies.

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

Consesus was achieved without any opposing voice.

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)?

This document defines new IPFIX entities for new UDP options defined in
draft-ietf-tsvwg-udp-options. The working group is not aware of any existing or
planned implementations. However IE209 tcpOptions has been adopted widely,
therefore, with the development and deployment of draft-ietf-tsvwg-udp-options it is
expected that the UDP options IPFIX entities defined in this document are going to
be implemented.


## 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.

Yes, the document received.

Transport area
https://mailarchive.ietf.org/arch/msg/opsawg/p9WGo52u2pBhjr8kIHjeYPwHECc/

Internet area
https://mailarchive.ietf.org/arch/msg/opsawg/29dxzf6kBHMYrDP9cIjlqcwqPKc/

and IPFIX doctor
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

reviews while Operations area is pending. While the Internet Area review
remarked one minor point to be aligned with draft-ietf-tsvwg-udp-options about
applicability of UDP options in legacy transport receivers which was addressed
by the authors, the Transport Area directorate and the IPFIX doctors challenges
the correctness of the udpOptions data type. Wherever
this should be a new data type unsigned256 or a bitfield type instead of
unsigned according to reduced size encoding defined in
https://www.rfc-editor.org/rfc/rfc7011#section-6.2. The authors therefore
interoduced a new unsigned256 data type in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-08#name-new-ipfix-information-element
and a consensus is pending wherever this is the best choice.


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.

IPFIX doctor review
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

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]?

N/A

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.

N/A (other than IDNITS)

## 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, it is. I have reviewed the document and had minor comments on wording which
was addressed by the authors.

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?

Transport, Internet area and IPFIX doctors have reviewed. I do not believe detailed
subsequent reviews are required.

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?

Internet Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13

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.

A poll was sent to the list. The named authors has replied that there is no IPR.

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.

Yes

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.)

Some minor found and already addressed by authors.

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

No

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

N/A

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?

draft-ietf-tsvwg-udp-options is being prepared to be submitted to IESG.

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]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

The IPFIX entities created by this document references an IANA registry being created
by https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25

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.

N/A to this document but to draft-ietf-tsvwg-udp-options.


[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?

Within the working group, this document was seen as valuable since it defines.
the IPFIX entities of the draft-ietf-tsvwg-udp-options defined UDP options and
is going to be submitted to the IESG at about the same time while aligned with
the newly defined TCP options IPFIX entities described in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-05#section-4.

The authors decided to keep the UDP options IPFIX entities definition separate from
draft-ietf-opsawg-ipfix-tcpo-v6eh due to the draft-ietf-tsvwg-udp-options dependecies.

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

Consesus was achieved without any opposing voice.

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)?

This document defines new IPFIX entities for new UDP options defined in
draft-ietf-tsvwg-udp-options. The working group is not aware of any existing or
planned implementations. However IE209 tcpOptions has been adopted widely,
therefore, with the development and deployment of draft-ietf-tsvwg-udp-options it is
expected that the UDP options IPFIX entities defined in this document are going to
be implemented.


## 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.

Yes, the document received.

Transport area
https://mailarchive.ietf.org/arch/msg/opsawg/p9WGo52u2pBhjr8kIHjeYPwHECc/

Internet aera
https://mailarchive.ietf.org/arch/msg/opsawg/29dxzf6kBHMYrDP9cIjlqcwqPKc/

and IPFIX doctor
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

reviews while Operations area is pending. While the Internet Area review
remarked one minor point to be aligned with draft-ietf-tsvwg-udp-options about
applicability of UDP options in legacy transport receivers which was addressed
by the authors, the Transport Area directorate and the IPFIX doctors challenges
the correctness of the udpOptions data type. Wherever
this should be a new data type unsigned256 or a bitfield type instead of
unsigned according to reduced size encoding defined in
https://www.rfc-editor.org/rfc/rfc7011#section-6.2. The authors therefore
interoduced a new unsigned256 data type in
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-08#name-new-ipfix-information-element
and a consensus is pending wherever this is the best choice.


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.

IPFIX doctor review
https://mailarchive.ietf.org/arch/msg/opsawg/zuDCHGyj1Pr9MbSo7aE1AJU2bSY/

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]?

N/A

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.

N/A (other than IDNITS)

## 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, it is. I have reviewed the document and had minor comments on wording which
was addressed by the authors.

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?

Transport, Internet area and IPFIX doctors have reviewed. I do not believe detailed
subsequent reviews are required.

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?

Internet Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13

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.

A poll was sent to the list. The named authors has replied that there is no IPR.

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.

Yes

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.)

Some minor found and already addressed by authors.

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

No

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

N/A

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?

draft-ietf-tsvwg-udp-options is being prepared to be submitted to IESG.

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]).

The IPFIX entities created by this document references an IANA registry being created
by https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25

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.

N/A to this document but to draft-ietf-tsvwg-udp-options.


[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/