Re: [IPFIX] Bitfields vs. Unsigned RE: Re: WG LC: IPFIX documents

[[e-mail]]

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' <[e-mail]>; 'Joe Clarke (jclarke)' <jclarke=[e-mail]>; '[e-mail]' <[e-mail]>
Cc : '[e-mail]' <[e-mail]>
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' <[e-mail]<mailto:[e-mail]>>; Aitken, Paul <paitken=[e-mail]<mailto:paitken=[e-mail]>>; Joe Clarke (jclarke) <jclarke=[e-mail]<mailto:jclarke=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Envoyé : lundi 22 janvier 2024 11:49
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; Aitken, Paul <paitken=[e-mail]<mailto:paitken=[e-mail]>>; Joe Clarke (jclarke) <jclarke=[e-mail]<mailto:jclarke=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.