Re: [Int-dir] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

[[e-mail]]

Hi Joe,

Thanks for the follow-up.

Please see inline.

Cheers,
Med

De : [e-mail] <[e-mail]>
Envoyé : lundi 15 janvier 2024 17:17
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]
Objet : Re: Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

Please see below.

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>


On Jan 15, 2024, at 12:26 AM, [e-mail]<mailto:[e-mail]> wrote:

Hi Joe,

Thanks for the review.

Please see inline.

Cheers,
Med


-----Message d'origine-----
De : Joseph Touch via Datatracker <[e-mail]<mailto:[e-mail]>>
Envoyé : samedi 13 janvier 2024 05:03
À : [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>;
[e-mail]<mailto:[e-mail]>
Objet : Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-
03

Reviewer: Joseph Touch
Review result: Ready with Issues

This review is performed as part of the INTAREA cross-area
review.

There do not appear to be any INTAREA issues in this document.

NOTE: as author of the UDP options on which this document is
based, I have some other concerns noted below, which are the
"issues" indicated in the review result (ready with issues).

There are some misconceptions about UDP options that should be
corrected in this document:

Regarding SAFE options:
-       “Such options can be silently ignored by receivers
without affecting
the meaning of the UDP user data” -       Should be “Such options
can be
silently ignored by legacy receivers because they do not alter
the UDP user data”

Regarding UNSAFE options:
-       “Such options are not safe to ignore”
-       Should be “Such options are not safe tor legacy receivers
to ignore
because they alter the UDP user data”

[Med] Fixed.

It would be useful to use a consistent phrase to describe the "UDP user data" (e.g., as per your Fig 1), i.e., rather than also “UDP data payload”.
[Med] Updated the text to use consistent wording for both safe/unsafe text.


The document should be more clear that UDP options occur per-
packet within a flow and can be introduced at any time in the
flow (unlike TCP).

[Med] Added a new statement to echo this. The export process covers any option that is observed in a flow.



Sec 4.1 needs to indicate use of a field with 256 possible
values; it currently is defined for only 32 or 64 values.


[Med] 32/64 are provided as examples to illustrate the use of reduced encoding. The full 256 range is covered in the spec. Thanks.

“Unsigned” without numeric qualifiers is not an IPFIX data type, per RFC7011 Sec 6.1.1.

Sec 6.2 indicates the specific encoding types where reduced encoding applies, and also uses unsigned only with numeric qualifiers.

[Med] You are right. Updated the text to use a new abstract data type defined in another ongoing opsawg-ipfix spec.

Joe


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