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

["Joe Clarke (jclarke)" <[e-mail]>]

Thank you, Thomas and authors/contributors.  We will move this forward to the IESG.

Joe

From: OPSAWG <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Saturday, April 6, 2024 at 03:29
To: jclarke=[e-mail] <jclarke=[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents
Dear Joe and Med,


I updated both shepherd writeup's accordingly and adjusted to: that consensus for introducing a new data type unsigned256 has been achieved.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/shepherdwriteup/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/shepherdwriteup/

I confirm that there is no more blocking points for moving forward to IESG.

Best wishes
Thomas

From: OPSAWG <[e-mail]> On Behalf Of Joe Clarke (jclarke)
Sent: Tuesday, April 2, 2024 5:41 PM
To: [e-mail]; Aitken, Paul <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Be aware: This is an external email.

As a co-chair, I’m willing to call consensus on this as there hasn’t been any other replies on this thread after Med asserted the reasoning for sticking with unsigned256.

I would ask Thomas as shepherd to note this in the write-up, and we can proceed to IESG as I believe all other comments from reviews have now been addressed.

Joe

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 2, 2024 at 11:04
To: Aitken, Paul <[e-mail]<mailto:[e-mail]>>, Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents
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]<mailto:[e-mail]>>; 'Joe Clarke (jclarke)' <jclarke=[e-mail]<mailto:jclarke=[e-mail]>>; '[e-mail]' <[e-mail]<mailto:[e-mail]>>
Cc : '[e-mail]' <[e-mail]<mailto:[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.