Re: [Tsv-art] Tsvart early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

[Tommy Pauly <[e-mail]>]

Hi Med,

I understand that fewer bits are needed in practice, and RFC 7011 would allow a field defined as an unsigned64 to be sent as fewer bits on the wire. However, for the IANA registration, I still would expect this field to match the existing fields and not have a unique type just called “unsigned”. 

Tommy

> On Jan 15, 2024, at 12:32 AM, [e-mail] wrote:
> 
> Hi Tommy,
> 
> Thank you for the review.
> 
> The encoding should allow to export the full 256 range, but it is likely that fewer bits will be needed. unsigned32/unsigned64 are provided as examples to illustrate the use of reduced encoding (https://datatracker.ietf.org/doc/html/rfc7011#section-6.2).
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Tommy Pauly via Datatracker <[e-mail]>
>> Envoyé : mardi 2 janvier 2024 18:08
>> À : [e-mail]
>> Cc : [e-mail];
>> [e-mail]
>> Objet : Tsvart early review of draft-ietf-opsawg-tsvwg-udp-ipfix-
>> 03
>> 
>> 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. However, when I look at the registry at
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.iana.org%2Fassignments%2Fipfix%2Fipfix.xhtml&data=05%7C02%7C
>> mohamed.boucadair%40orange.com%7C7a23dc00f97a4cadeee208dc0bb5555f
>> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638398120645105476%
>> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P9pWAnW5VI1SzmRx4
>> Q%2FB2wOa3rsve1uOdsRm%2BMNB4%2B0%3D&reserved=0, 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. Is there a reason
>> this shouldn't just be registered as an unsigned64? My
>> understanding from
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-editor.org%2Frfc%2Frfc7011%23section-
>> 6.2&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7a23dc00f97a4
>> cadeee208dc0bb5555f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
>> 638398120645105476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
>> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
>> a=1FvKZv60OgONy5w%2BygO9sSnBN121J9yveL7Gkv15apI%3D&reserved=0 is
>> that an unsigned64 can be automatically encoded as an unsigned32
>> if the value is small enough, so the definition can just use
>> unsigned64.
>> 
> 
> ____________________________________________________________________________________________________________
> 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.
>