Med, I'm not happy with the unsigned192 type. It's uncommon, specific to the udpSafeOptions IE, and unlikely to be used again for anything else.
Is it possible to use unsigned256, say that topmost bits must be zero, and reduced size encoding MAY be used? Thanks, P. On 22/05/24 20:11, David Dong via RT wrote: > Hi Paul, > > Following up on this document as well. > > Thank you for performing the reviews. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > On Tue May 14 12:48:27 2024, [email protected] wrote: >> Hi Paul, >> >> The new version with all received reviews and comments is available >> at: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-__;!!OSsGDw!P_ycY1FkmBqO94I060aheNn8E63NSE_z4Ch7kSKuTsFNGP209J80BBFfEJVL6LODmAf12QpGRtjzt0I5adRYNMo$ >> [datatracker[.]ietf[.]org] >> ipfix/ >> >> Please see inline. >> >> Cheers, >> Med >> >> De : Aitken, Paul <[email protected]> >> Envoyé : lundi 13 mai 2024 21:53 >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; >> [email protected] >> Cc : [email protected]; opsawg <[email protected]> >> Objet : RE: [Ie-doctors] [IANA #1363824] Expert review for draft-ietf- >> opsawg-tsvwg-udp-ipfix (ipfix) >> >> >> Med, >> >> In the new version: >> >> >> 4.1. The first 64 most-significant bits MUST be set to 0. >> >> This seems to exclude reduced size encoding. >> [Med] These will be seen as leading zeros and will thus be reduced. >> However, I went with a unsigned192 rather than unsiggned256 for this >> IE >> >> >> Also, "while Kind 255 corresponds to the most-significant bit of the >> IE." is nolonger accurate. >> [Med] Yes, changed to “191” >> >> >> >> 4.2 udpUnsfaeOptions >> >> Typo: udpUnsafeOptions >> >> [Med] Fixed. >> >> >> 4.1 and 4.2: >> >> A bit is set to 1 >> >> should be "The bit is set to 1". >> [Med] OK >> >> >> >> 5. Operational Considerations >> >> The note about reduced-size encoding will not be seen in IANA's >> registry. >> [Med] I moved that because this was a comment from Benoît to remove >> the reduced-size encoding from the description. >> >> The note seems contrary to the statement in 4.1 that I quoted above. >> [Med] That statement was removed. >> >> >> Figure 4: >> >> Repeating two points that I made previously: >> >> [Med] Fixed. >> >> The last 0x9858 (next to 0xC3D9) should be 0x9658. Else the figure >> does not correspond with the preceding text. >> >> 9658 and 9858 are unnecessarily similar values. I would urge you to >> choose a different example. >> >> P. >> ____________________________________________________________________________________________________________ >> 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] To unsubscribe send an email to [email protected]
