Hi all, As indicated in IETF#119, we suggest to tag this issue as closed and proceed with the publication of the current versions of the various I-Ds.
Cheers, Med De : BOUCADAIR Mohamed INNOV/NET Envoyé : vendredi 23 février 2024 15:55 À : 'Aitken, Paul' <pait...@ciena.com>; 'Joe Clarke (jclarke)' <jclarke=40cisco....@dmarc.ietf.org>; 'opsawg@ietf.org' <opsawg@ietf.org> Cc : 'ip...@ietf.org' <ip...@ietf.org> Objet : RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents Hi Paul, Unless I'm mistaken, I didn't see any follow-up to this issue. May I consider this point as closed? Thanks. Cheers, Med De : BOUCADAIR Mohamed INNOV/NET Envoyé : mardi 23 janvier 2024 14:23 À : 'Aitken, Paul' <pait...@ciena.com<mailto:pait...@ciena.com>>; Aitken, Paul <paitken=40ciena....@dmarc.ietf.org<mailto:paitken=40ciena....@dmarc.ietf.org>>; Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>>; opsawg@ietf.org<mailto:opsawg@ietf.org> Cc : t...@ietf.org<mailto:t...@ietf.org>; ts...@ietf.org<mailto:ts...@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>; ip...@ietf.org<mailto:ip...@ietf.org> Objet : Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents Hi Paul, > It is consistent but wrong, as the numeric value of these fields is > meaningless. Bitfields with flags semantics don't have a meaningful > "unsigned" value. You raised this comment for both TCP/UDP specs. As I mentioned in the previous message, all existing IEs of type flags are using an unsigned type. Also, please note that rfc7012#section-3.2.5 says the followings: "flags" is an integral value that represents a set of bit fields. Logical operations are appropriate on such values, but other mathematical operations are not. Flags MUST always be of an unsigned data type. And rfc7012#section-3: Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 are integral data types. As described in Section 3.2, their data type semantics can be further ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ specified, for example, by 'totalCounter', 'deltaCounter', 'identifier', or 'flags'. ^^^^^^^^^^ I quite don't understand why we need to define Bitfields rather than leveraging on the approach followed so far in IPFIX. Cheers, Med De : Aitken, Paul <pait...@ciena.com<mailto:pait...@ciena.com>> Envoyé : lundi 22 janvier 2024 11:49 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; Aitken, Paul <paitken=40ciena....@dmarc.ietf.org<mailto:paitken=40ciena....@dmarc.ietf.org>>; Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>>; opsawg@ietf.org<mailto:opsawg@ietf.org> Cc : t...@ietf.org<mailto:t...@ietf.org>; ts...@ietf.org<mailto:ts...@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>; ip...@ietf.org<mailto:ip...@ietf.org> Objet : Re: Re: [IPFIX] WG LC: IPFIX documents Med, The IE specified in Section 4.1 uses the new abstract data type defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh]. The unsigned256 type? It makes more sense to introduce a bitfield type. [Med] I think the use of unsigned256 is consistent with the current use in IP Flow Information Export (IPFIX) Entities (iana.org) [iana.org]<https://urldefense.com/v3/__https://www.iana.org/assignments/ipfix/ipfix.xhtml__;!!OSsGDw!PbyTGwK6ng1xsDx7EDsqY-zP5SN-siBTe9ltLeN6whqtHew5I4J3MgqA7QOaYGnkTWnF4w1wMldDkBYIpjb9XwrB$> (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs having data semantic of flags. It is consistent but wrong, as the numeric value of these fields is meaningless. Bitfields with flags semantics don't have a meaningful "unsigned" value. ____________________________________________________________________________________________________________ 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
