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, [email protected] 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 <[email protected]> >> Envoyé : mardi 2 janvier 2024 18:08 >> À : [email protected] >> Cc : [email protected]; >> [email protected] >> 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. > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
