Perfect. Thanks Med
B.
On 5/5/2023 11:47 AM, mohamed.boucad...@orange.com wrote:
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>
*Envoyé :* vendredi 5 mai 2023 11:04
*À :* thomas.g...@swisscom.com; opsawg@ietf.org; BOUCADAIR Mohamed
INNOV/NET <mohamed.boucad...@orange.com>
*Cc :* juans...@cisco.com; rjo...@cisco.com; me <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 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.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
