Re-,
Great! FWIW, https://datatracker.ietf.org/doc/draft-boucla-opsawg-ipfix-fixes/06/ includes now the note proposed below. Cheers, Med De : thomas.g...@swisscom.com <thomas.g...@swisscom.com> Envoyé : vendredi 5 mai 2023 12:00 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; benoit.cla...@huawei.com; opsawg@ietf.org Cc : juans...@cisco.com; rjo...@cisco.com Objet : RE: draft-boucla-opsawg-ipfix-fixes-04 Dear Med and Benoit, Excellent. Thank you very much for addressing this so quickly. The proposed changes make perfectly sense and addresses my concerns. Indeed I was miss leaded by the IANA IPFIX registry indicating unisgned8 where RFC7270 defined unisgned32 for the IE89 forwardingStatus. Therefore reduced-size encoding makes perfectly sense now. Best wishes Thomas From: mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com> > Sent: Friday, May 5, 2023 11:48 AM To: Benoit Claise <benoit.cla...@huawei.com <mailto:benoit.cla...@huawei.com> >; Graf Thomas, INI-NET-VNC-HCS <thomas.g...@swisscom.com <mailto:thomas.g...@swisscom.com> >; opsawg@ietf.org <mailto:opsawg@ietf.org> Cc: juans...@cisco.com <mailto:juans...@cisco.com> ; rjo...@cisco.com <mailto:rjo...@cisco.com> Subject: RE: draft-boucla-opsawg-ipfix-fixes-04 Hi Benoît, To make it clear and avoid any issues (which I smell coming) with the IE-doctors at review time, I would make it very clear in the next version of the draft: [IANA Note: this unsigned8 to unsigned32 is actually a bug, as https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 clearly mentions that the Abstract Data Type must be unsigned32] I went with the following: NEW: The current entry in [IANA-IPFIX] deviates from what is provided in [RFC7270]. In particular, the registered Abstract Data Type is unsigned8, while it must be unsigned32. The following update fixes that issue. The description is also updated to clarify the use of the reduced-size encoding as per Section 6.2 of [RFC7011]. Cheers, Med De : Benoit Claise <benoit.cla...@huawei.com <mailto:benoit.cla...@huawei.com> > Envoyé : vendredi 5 mai 2023 11:04 À : thomas.g...@swisscom.com <mailto:thomas.g...@swisscom.com> ; opsawg@ietf.org <mailto:opsawg@ietf.org> ; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com <mailto:mohamed.boucad...@orange.com> > Cc : juans...@cisco.com <mailto:juans...@cisco.com> ; rjo...@cisco.com <mailto:rjo...@cisco.com> ; me <benoit.cla...@huawei.com <mailto:benoit.cla...@huawei.com> > Objet : Re: draft-boucla-opsawg-ipfix-fixes-04 Dear Thomas, Thanks for spotting this. See inline. On 5/3/2023 4:07 PM, thomas.g...@swisscom.com <mailto:thomas.g...@swisscom.com> wrote: Dear OPSAWG, Med and Benoit Regarding section 6.2, forwardingStatus (https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes -04#section-6.2). Section 4.12 of RFC 7270 (https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes that reduced-size encoding according to Section 6.2 of RFC 7011 (https://www.rfc-editor.org/rfc/rfc7011#section-6.2) can be applied. Further Section 4.12 of RFC 7270 describes that "The basic encoding is 8 bits. The future extensions could add one or three bytes". The IANA IPFIX registry (https://www.iana.org/assignments/ipfix/ipfix.xhtml) reads unisgned8 for IE89 forwardingStatus. Recently we came across a vendor implementation which implemented IE89 forwardingStatus with unsigned32 instead of unsigned8 already. This raised the following questions which I like to clarify here: 1. Does "The future extensions could add one or three bytes" means that data type can be changed from unsigned8 to unsigned32 today already or is a new RFC document needed to update the IPFIX entity? Actually, this is clearly a bug in the IFPIX IANA registry. https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 mentions unsigned32 and it's not the case in the IPFIX IANA registry 2. 3. Does " reduced-size encoding" also applies for increasing the field size? No. That's the reason why unsigned32 must be in the IPFIX IANA registry 4. If yes, I find the wording rather misleading. 5. If IE89 forwardingStatus can be implemented in unsigned8, unsigned16 and unsigned32, shouldn't it be reflected in the IPFIX registry accordingly? Depending on the answers we might take the opportunity with draft-boucla-opsawg-ipfix-fixes to update the IE89 forwardingStatus description. As I mentions, this is a bug. We can take the opportunity to include it in draft-boucla-opsawg-ipfix-fixes-05 Med did it, and this is perfect. Thanks. To make it clear and avoid any issues (which I smell coming) with the IE-doctors at review time, I would make it very clear in the next version of the draft: [IANA Note: this unsigned8 to unsigned32 is actually a bug, as https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12 clearly mentions that the Abstract Data Type must be unsigned32] Thanks to Thomas for the investigaiton and Med for the speedy reaction. Regards, Benoit Best wishes Thomas ______________________________________________________________________ ___________________________________________________ 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
