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 <[email protected]>
Envoyé : lundi 5 février 2024 17:34
À : [email protected]
Cc : BOUCADAIR Mohamed INNOV/NET <[email protected]>
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, [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
