[OPSAWG] AD review of draft-ietf-opsawg-ipfix-fixes

[Mahesh Jethanandani <[e-mail]>]

Hi Authors,

Thank you for working on this document, This is my review of draft-ietf-opsawg-ipfix-fixes-06 draft. They are roughly divided between COMMENT and NIT. The COMMENTs should be resolved before this document is sent for IETF LC for publication as a Draft Standard.

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 1, paragraph 2
>    When OPSAWG was considering [I-D.ietf-opsawg-rfc7125-update] which
>    updates [RFC7125], the WG realized that some other parts of the IANA
>    IP Flow Information Export (IPFIX) registry [IANA-IPFIX] were not up-
>    to-date.  Indeed, since its initial creation in 2007, some IPFIX
>    Information Elements (IEs) are no longer adequately specified (while
>    they were at some point in time in the past).  This document intends
>    to update the IANA registry and bring some consistency among the
>    entries of the registry.


For a specification to "no longer adequately" specify an IE, the underlying specification for IPFIX must have changed. If that is so, can you cite what changed? If not, I would just remove the statement. It is not serving any purpose in this specification.

Section 1, paragraph 1
>    As discussed with IANA during the publication process of [RFC9487],
>    the "Additional Information" entry in [IANA-IPFIX] should contain a
>    link to an existing registry, when applicable, as opposed to having:


What happens to the existing registries? Does Section 6 take care of all of them? Should the link in existing registries not specified in Section 6, also move to Additional Information?

Section 3, paragraph 3

Since Sections 4-7 are really for the IANA Consideration section, why not move them there?

Section 4.1.2, paragraph 0
>     - Description:  This Information Element describes the forwarding
>                     status of the flow and any attached reasons.
>                     IPFIX reduced-size encoding is used as required.


I know that you explain what reduced-size encoding in the other IPFIX documents, but it will be worth repeating it here or refer to that definition from here.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "he"; alternatives might be "they", "them", "their"
 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Uncited references: [RFC_Errata_1739] and [RFC_Errata_1738].

Reference [RFC2482] to RFC2482, which was obsoleted by RFC6082 (this may be on
purpose).

Reference [RFC5102] to RFC5102, which was obsoleted by RFC7012 (this may be on
purpose).

Reference [RFC1631] to RFC1631, which was obsoleted by RFC3022 (this may be on
purpose).

Document references draft-ietf-opsawg-RFC7125-update, but that has been
published as RFC9565.

Reference [I-D.ietf-opsawg-rfc7125-update] to RFC7125, which was obsoleted by
RFC9565 (this may be on purpose).

Reference [RFC7125] to RFC7125, which was obsoleted by RFC9565 (this may be on
purpose).

Reference [RFC4646] to RFC4646, which was obsoleted by RFC5646 (this may be on
purpose).

"Abstract", paragraph 3
> ions and Management Area Working Group Working Group mailing list (opsawg@iet
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
This phrase is duplicated. You should probably use "Working Group" only once.

Section 6.2.2, paragraph 1
> NAT event. This IE identifies the type of a NAT event. Examples of NAT events
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 6.3.1, paragraph 1
> NAT event. This IE identifies the type of a NAT event. Examples of NAT events
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 6.10.1, paragraph 5
> description of the abstract data type of an IPFIX information element. These
>                                  ^^^^^^^^^^
If "type" is a classification term, "an" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 6.10.2, paragraph 5
> description of the abstract data type of an IPFIX information element.These a
>                                  ^^^^^^^^^^
If "type" is a classification term, "an" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 6.20.2, paragraph 1
> nformation Element identifies the type of a NAT Quota Exceeded event. Values
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 6.20.2, paragraph 2
> nformation Element identifies the type of a NAT Quota Exceeded event. Values
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 6.21.1, paragraph 2
>  Information Element identifies a type of a NAT Threshold event. Values for t
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 6.21.2, paragraph 2
>  Information Element identifies a type of a NAT Threshold event. Values for t
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 6.23.1, paragraph 4
>  | | | table below, and section Section 5.1. | | 2 | PmA | Pe
>                         ^^^^^^^^^^^^^^^
Possible typo: you repeated a word.

Section 6.24.2, paragraph 1
> SHOULD have this flag set, and vice-versa.) | +--------+----------+---------
>                                ^^^^^^^^^^
The expression "vice versa" is spelled without hyphens.

Section 7.2.1, paragraph 1
> SHOULD have this flag set, and vice-versa.) | +--------+----------+---------
>                                ^^^^^^^^^^
The expression "vice versa" is spelled without hyphens.


Mahesh Jethanandani
[e-mail]