[OPSAWG]Re: [IANA #1363824] Expert review for draft-ietf-opsawg-tsvwg-udp-ipfix (ipfix)
Suggest removing “first” below; Removing "the 64 most significant bits" is sufficient. — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On May 23, 2024, at 10:51 AM, mohamed.boucad...@orange.com wrote: > > Re-, > > Thanks. Please see one comment inline. > > Cheers, > Med > > > De : Aitken, Paul mailto:pait...@ciena.com>> > Envoyé : jeudi 23 mai 2024 18:31 > À : BOUCADAIR Mohamed INNOV/NET <mailto:mohamed.boucad...@orange.com>>; drafts-expert-review-comm...@iana.org > <mailto:drafts-expert-review-comm...@iana.org>; Joe Touch > mailto:to...@strayalpha.com>> > Cc : ie-doct...@ietf.org <mailto:ie-doct...@ietf.org>; opsawg@ietf.org > <mailto:opsawg@ietf.org> > Objet : Re: [IANA #1363824] Expert review for > draft-ietf-opsawg-tsvwg-udp-ipfix (ipfix) > > > Sigh. > > In sections 7.1 and 7.2, s/192/256/ > > Add this line and change the ADT: > > 4.1. udpSafeOptions > >Name: udpSafeOptions > >ElementID: TBD1 > >Description: Observed safe UDP options in a Flow. The information > is encoded in a set of bit fields. > > Options are mapped to bits according to their option numbers. UDP > option Kind 0 corresponds to the least-significant bit in the > udpSafeOptions IE while Kind 191 corresponds to the most- > significant bit of the IE. > [Med] I guess this one should be updated as well. No? > > The bit is set to 1 if the > corresponding safe UDP option is observed in the Flow. The bit is > set to 0 if the option is not observed in the Flow. > + The first 64 most-significant bits MUST be set to 0. > > The reduced-size encoding per Section 6.2 of [RFC7011] is followed > whenever fewer octets are needed to report observed safe UDP > options. For example, if only option Kinds <= 31 are observed, > then the value of the udpSafeOptions IE can be encoded as > unsigned32, or if only option Kinds <= 63 are observed, then the > value of the udpSafeOptions IE can be encoded as unsigned64. > ... > >Abstract Data Type: unsigned256 > > P. > > > On 23/05/24 16:46, mohamed.boucad...@orange.com > <mailto:mohamed.boucad...@orange.com> wrote: > Re-, > > Please share the OLD/NEW text that you would like to see and will implement > it. Thanks. > > 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 To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Re: [Last-Call] Intdir last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08
Hi, Med, I still have issue with the same two key parts: 1. This doc refers to unsigned192. - That is not a native data type of any known computer. It needs to be defined. - Reduced-size encoding per RFC7011 does not apply, unless you are restricting them to 64, 32, 16, and 8. 2. Neither unsigned64 nor unsigned192 are compatible with octetArray as used in this document, AFAICT - octetArray would be for a sequence of unsigned64s, for example, but not for bytes that might be interpreted in different ways depending on length It would be useful to explain why the safe and unsafe options are split (i.e., to support reduced-size encoding when both are in use). The only approach that I think is compatible with RFC7011 is: - use an octetArray and explain its length and mapping (e.g., of unsigned8 values), representing the values 0…256 as consecutive groups of 8, truncated when the remaining bytes are all zeros OR - define safe as three unsigned64s, each potentially using reduced-size encoding See additional notes below. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On May 13, 2024, at 8:46 AM, mohamed.boucad...@orange.com wrote: > > Hi Joe, > > Thank you for the excellent review. > > The changes to address the review can be seen here: > https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt_2=https://boucadair.github.io/udp-ipfix/Joe-Review/draft-ietf-opsawg-tsvwg-udp-ipfix.txt > > Please see inline for more context. > > Cheers, > Med > >> -Message d'origine- >> De : Joseph Touch via Datatracker >> Envoyé : mercredi 8 mai 2024 06:06 >> À : int-...@ietf.org >> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; last- >> c...@ietf.org; opsawg@ietf.org >> Objet : Intdir last call review of draft-ietf-opsawg-tsvwg-udp- >> ipfix-08 >> >> >> Reviewer: Joseph Touch >> Review result: Ready with Issues >> >> Note that I previously performed an INTAREA early review on Jan >> 12, 2024. >> >> This document sufficiently addresses the issues previously >> raised, with the exception below. It introduces no new concerns. >> >> The sole remaining issue is the use of "unsigned256" as a data >> type. This is necessary to represent the potential bitfield to >> support all 256 possible UDP option Kind values. This document >> cites draft-ietf-opsawg-ipfix-tcpo-v6eh as defining this type (in >> Sec 8.3). That (tcpo-v6eh) document defines the range of this >> type correctly, but then refers back to RFC7011 Sec 6.1.1 to >> define the encoding. Unfortunately, RFC7011 defines encodings for >> unsigned integers only up to 64 bits. >> >> This (udp-ipfix) document cites Section 6.2 of RFC7011 to define >> reduced size encodings of unsigned256, but RFC7011 defines those >> encodings only for 64, 32, and 16 bit unsigned integers. >> Additionally, those reductions apply only when the high-order >> byte(s) are all zero; for UDP options, the partitioning of >> options into SAFE and UNSAFE groups and the assignment of >> experiment codepoints to the highest values in both ranges >> suggests that these reduced size encodings may be of limited >> relevance. > > Med] Good point. As you can see in > https://mailarchive.ietf.org/arch/msg/opsawg/JJAD7ooBNe_gFHRUAiHmK24HBNk/, we > already made changes so that reduced-size encoding can be used even in the > presence of shared options; see specifically this part: I believe you are referring to experimental options, and yes, I see how that is now fixed, with the text noted below. > > == > [Med] These considerations are not specific to this document and fall under > the generic considerations in base spec 7011 (Section 10.3.3). After think > about this, I added a new section called (ops considerations) with the > following content: > > * moved the text about reduced-size encoding to that section > * encourage the use of reduced-size encoding in the presence of EXP/UEXP > (that is the *ExID IEs) takes precedence and thus their flags can be ignored MUST be ignored. > * add a pointer to transport (including MTU) IPFIX cons. > == > > We can go one step further to export SAFE and UNSAFE options in separate IEs. Yes, and it would be useful to add a note explaining why these are separated. > >> >> At least one document needs to define unsigned256 normatively - >> this doc, tcpo-v6eh, or some other. That document needs to >> explain the byte order representation and reduced size encoding. > > [Med] Makes sense. Removed the pointer to 6.1.1 of 7011 and copy/paste the > encoding in the tcp-eh I-D. That does not resolve the use reduced encoding in a way that 7011’s text does not define. >> This (udp-fix) document also uses the octetArray type, but then >> defines it as being interpreted as "16-bit fields" (Sec 4.2, >> 4.3). This should probably refer to unsigned16 values, but it's >> not clear that this is a valid
Re: [OPSAWG] [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 > 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> <mailto:to...@strayalpha.com>> > Envoyé : lundi 15 janvier 2024 17:17 > À : BOUCADAIR Mohamed INNOV/NET <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 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 alt
Re: [OPSAWG] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03
Please see below. — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Jan 15, 2024, at 12:26 AM, mohamed.boucad...@orange.com wrote: > > Hi Joe, > > Thanks for the review. > > Please see inline. > > Cheers, > Med > >> -Message d'origine- >> De : Joseph Touch via Datatracker >> Envoyé : samedi 13 janvier 2024 05:03 >> À : int-...@ietf.org >> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; >> 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”. > >> 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. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Tsv-art] Tsvart early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03
On Jan 2, 2024, at 9:07 AM, Tommy Pauly via Datatracker wrote: > > Reviewer: Tommy Pauly > Review result: Almost Ready > > Thanks for writing a clear and succinct draft. I only found one issue of note, > around the registration of the new udpOptions Information Element. > > Section 4.1: > The data type used for the “udpOptions” entry is just listed as “unsigned”, > and > is described as being either an unsigned32 or an unsigned64. I understood this to be a bitfield of length 256, which MAY be shorter, and only in those shorter cases could it be UINT32 or UINT64, as per RFC7011. But that doesn’t seem consistent with RFC7011 either. AFAICT, this really should be octetArray, which COULD be shortened as needed. > However, when I > look at the registry at https://www.iana.org/assignments/ipfix/ipfix.xhtml, I > don’t see any entries that use this abstract “unsigned” type, and it is not > listed as an option in the element data types I would think it should have been indicated as “octetArray”. > . Is there a reason this shouldn’t > just be registered as an unsigned64? Yes, IMO - because UDP option Kind values higher than 63 are valid and could be used. > My understanding from > https://www.rfc-editor.org/rfc/rfc7011#section-6.2 is that an unsigned64 can > be > automatically encoded as an unsigned32 if the value is small enough, so the > definition can just use unsigned64. As per above, I don’t see how this helps given the field could be up to 265 bits long. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
