Re: [OPSAWG] AD review of draft-ietf-opsawg-tsvwg-udp-ipfix

[[e-mail]]

Hi Mahesh,

Thank you for the review.

The candidate version can be seen at: Diff: draft-ietf-opsawg-tsvwg-udp-ipfix.txt - draft-ietf-opsawg-tsvwg-udp-ipfix.txt<https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt&url_2=https://boucadair.github.io/udp-ipfix/boucadair-patch-2/draft-ietf-opsawg-tsvwg-udp-ipfix.txt>

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani <[e-mail]>
Envoyé : mardi 16 avril 2024 18:48
À : [e-mail]
Cc : [e-mail]
Objet : AD review of draft-ietf-opsawg-tsvwg-udp-ipfix


Hi Authors,

Thank you for working on this document. And thanks to Tommy Pauly, and Joe Touch for providing their reviews.

Here is my review that is divided between COMMENTs and NITs. I expect the COMMENTs to be resolved before the document is sent for IETF Last Call.

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

Section 1, paragraph 1
>    IP Flow Information Export (IPFIX) [RFC7011] is a protocol that is
>    widely deployed in operators networks for traffic management
>    purposes

Would it be fair to say, that IPFIX is used for traffic monitoring and not directly traffic management?
[Med] It is actually given that it covers many aspects of the so-called FCAPS management function (see for example rfc5472#section-2). I added "({{Section 2 of !RFC6632}}) where it is cited as part of "Core Network Management Protocols"".

Section 2, paragraph 2
>    This document uses the IPFIX-specific terminology (e.g., Flow)
>    defined in Section 2 of [RFC7011].  As in [RFC7011], these IPFIX-
>    specific terms have the first letter of a word capitalized.
>
>    Also, this document uses the terms defined in Section 3 of
>    [I-D.ietf-tsvwg-udp-options].

It would help to identify which terms are being used from each of the documents in this draft.
[Med] cited the main terms.

Also, is the rule that the IPFIX specific terms have the first letter captilized?
[Med] This is a convention for terms such as Flow, Template, etc.

What about udpOptions?
[Med] For IEs, the convention in rfc7012#section-2.3 apply, that is:

   o  Names of Information Elements MUST start with lowercase letters.

   o  Composed names MUST use capital letters for the first letter of
      each component (except for the first one).  All other letters are
      lowercase, even for acronyms.  Exceptions are made for acronyms
      containing a mixture of lowercase and capital letters, such as
      'IPv4' and 'IPv6'.  Examples are "sourceMacAddress" and
      "destinationIPv4Address".

[Med] Added this NEW: "The document adheres to the naming conventions for Information Elements per {{Section 2.3 of !RFC7012}}."

Section 5, paragraph 3
>                    Figure 2: An Example of udpOptions IE

Can the description be expaned to say "An Example of udpOptions with EOL and APC options?

[Med] Sure. Fixed.

Section 5, paragraph 10
>      udpSafeExperimentalOptionExID IE:
>
>      MSB                                                          LSB
>                           1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              0x9858           |             0xE2D4            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      udpUnsafeExperimentalOptionExID IE:
>
>                           1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              0xC3D9           |             0x9658            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>               Figure 3: Example of UDP Experimental option IEs


This example is not clear or confusing. The explanation above talked about SAFE and UNSAFE Experimental options. How is the range of 0-191 for SAFE or the range of 192-255 encoded in these values?
[Med] The shared option in the safe range is (EXP, Kind=127) while it is (UEXP, Kind=254) for the unsafe. When a shared SAFE option is observed, the ExIDs it carries are exported using udpSafeExperimentalOptionExID IE. The same happens for UEXP but with udpUnsafeExperimentalOptionExID IE. The presence of udpSafeExperimentalOptionExID or udpUnsafeExperimentalOptionExID is explicit about whether EXP or UEXP were observed. Both can be observed in the same Flow as exemplified in this Section.


Or if they are not, because they come part of the UDP options, then how about showing what the UDP options field looks like? In other words, can Example 2 and Example 3 be combined to show a more complete example?
[Med] I tweaked the example to also describe how the udpOptions IE looks like. Please let me know if any further change is needed. Thanks.

No reference entries found for these items, which were mentioned in the text:
[URL_IANA_UDP_OPTIONS] and [URL_IANA_UDP_ExIDs].
[Med] ACK. We have a note about that.

Note, the following comment is boilerplate output from the review tool I use. However, it is true that draft-ietf-tsvwg-udp-options currently is in WG LC and does not have the intended RFC status set, and thus the message. Also note that this document will result in MISREF state unless the other document moves forward and gets approved as an RFC.

DOWNREF [I-D.ietf-tsvwg-udp-options] from this Proposed Standard to
draft-ietf-tsvwg-udp-options of unknown standards level. (For IESG discussion.
It seems this DOWNREF was not mentioned in the Last Call and also seems to not
appear in the DOWNREF registry.)

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

Section 5, paragraph 1
>    Given UDP kind allocation in Section 10 of
>    [I-D.ietf-tsvwg-udp-options] and the option mapping defined in
>    Section 4.1 of this document, fewer octets are likely to be used for
>    Flows with mandatory UDP options.

Inconsistent use of the term Kind. Sometimes it is used with a captial K but other times it is used with a small k.
[Med] Changed to « Kind » to be consistent with the upd-options spec.

Document references draft-ietf-tsvwg-udp-options-28, but -32 is the latest
available revision.

Document references draft-ietf-opsawg-ipfix-tcpo-v6eh-08, but -10 is the latest
available revision.

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>





____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.