Hi Joe, The very short introduction to SAFE/UNSAFE is there to help reader digest the difference between EXP and UEXP introduced right after and understand the rationale for having two IPFIX IEs.
Of course, the authoritative reference for implementers is the TSVWG base spec; the exact section citations are provided. I still prefer maintaining that text for now. Thank you. Cheers, Med De : to...@strayalpha.com <to...@strayalpha.com> Envoyé : mardi 16 janvier 2024 18:30 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : int-...@ietf.org; draft-ietf-opsawg-tsvwg-udp-ipfix....@ietf.org; opsawg@ietf.org Objet : Re: [Int-dir] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03 I’d actually like to suggest this doc avoid repeating information in other docs, notably the UDP options spec. In particular: - there is no need to replicate Fig 1 - there is no need to replicate the definitions of SAFE or UNSAFE All these things can be “as defined in X”. That avoids any issues if there are subtle changes to these, notably the definitions. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com<http://www.strayalpha.com/> On Jan 16, 2024, at 12:28 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Joe, Thanks for the follow-up. Please see inline. Cheers, Med De : to...@strayalpha.com<mailto:to...@strayalpha.com> <to...@strayalpha.com<mailto:to...@strayalpha.com>> Envoyé : lundi 15 janvier 2024 17:17 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : int-...@ietf.org<mailto:int-...@ietf.org>; draft-ietf-opsawg-tsvwg-udp-ipfix....@ietf.org<mailto:draft-ietf-opsawg-tsvwg-udp-ipfix....@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> 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, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Joe, Thanks for the review. Please see inline. Cheers, Med -----Message d'origine----- De : Joseph Touch via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Envoyé : samedi 13 janvier 2024 05:03 À : int-...@ietf.org<mailto:int-...@ietf.org> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix....@ietf.org<mailto:draft-ietf-opsawg-tsvwg-udp-ipfix....@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> 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. _______________________________________________ Int-dir mailing list int-...@ietf.org<mailto:int-...@ietf.org> https://www.ietf.org/mailman/listinfo/int-dir ____________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
