Hi Benoît, Good point, but I don't think we need an update here. I suggest this change to draft-ietf-opsawg-ipfix-tcpo-v6eh:
OLD: The type "unsigned256" represents a non-negative integer value in the range of '0' to '2^256 - 1'. NEW: The type "unsigned256" represents a non-negative integer value in the range of '0' to '2^256 - 1'. This type MUST be encoded as per {{Section 6.1.1 of !RFC7011}}. Cheers, Med De : Benoit Claise <benoit.cla...@huawei.com> Envoyé : lundi 5 février 2024 17:34 À : opsawg@ietf.org Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Objet : draft-ietf-opsawg-ipfix-tcpo-v6eh updates RFC 7012? 5610? was (Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-09.txt) Dear all, With the introduction of new unsigned256 IPFIX data type (section 8.2), I am wondering whether draft-ietf-opsawg-ipfix-tcpo-v6eh updates RFC 7012? I guess so >From RFC7012: 3.1<https://datatracker.ietf.org/doc/html/rfc7012#section-3.1>. Abstract Data Types This section describes the set of valid abstract data types of the IPFIX information model, independent of encoding. Note that further abstract data types may be specified by future updates to this document. Changes to the associated IPFIX "Information Element Data Types" subregistry [IANA-IPFIX<https://datatracker.ietf.org/doc/html/rfc7012#ref-IANA-IPFIX>] specified in [RFC5610<https://datatracker.ietf.org/doc/html/rfc5610>] require a Standards Action [RFC5226<https://datatracker.ietf.org/doc/html/rfc5226>]. Well actually, the registry (https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types) points to RFC5610 So I guess this document should update both RFC7012 and RF5610. Initially, I was thinking that an update to RFC 7011 would be necessary, to update the following text. OLD: 6.1.1<https://datatracker.ietf.org/doc/html/rfc7011.html#section-6.1.1>. Integral Data Types Integral data types -- unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 -- MUST be encoded using the default canonical format in network byte order. Signed integral data types are represented in two's complement notation. NEW: 6.1.1<https://datatracker.ietf.org/doc/html/rfc7011.html#section-6.1.1>. Integral Data Types Integral data types -- unsigned8, unsigned16, unsigned32, unsigned64, unsigned256 signed8, signed16, signed32, and signed64 -- MUST be encoded using the default canonical format in network byte order. Signed integral data types are represented in two's complement notation. However, I believe this is not really necessary. Regards, Benoit On 1/23/2024 3:24 PM, internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote: Internet-Draft draft-ietf-opsawg-ipfix-tcpo-v6eh-09.txt is now available. It is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title: Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements Authors: Mohamed Boucadair Benoit Claise Name: draft-ietf-opsawg-ipfix-tcpo-v6eh-09.txt Pages: 16 Dates: 2024-01-23 Abstract: This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve some issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-tcpo-v6eh-09.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-09 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg ____________________________________________________________________________________________________________ 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