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 > On Jan 16, 2024, at 12:28 AM, 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
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
