Re: [IPFIX] [**EXTERNAL**] [Technical Errata Reported] RFC9487 (7728)

["Aitken, Paul" <[e-mail]>]

TLDR: add "Abstract Data Type: unsigned8" to RFC 9487 and update IANA's IPFIX registry.


The draft was changed in AUTH48. Those changes were not expert reviewed. IMHO this is a hole in the process.

The Abstract Data Type cannot be omitted. Other than #501 srhSegmentIPv6LocatorLength, none of the existing IEs in IANA's IPFIX registry omit the Abstract Data Type.

The Data Type Semantics can be omitted, in which case it defaults to "quantity" (RFC 7012, s3.2.1). Some (132) registry entries explicitly say "default" while others (65) leave this column blank. I'm happy to explicitly say "default" here.


Without reply, I went for the path of IFPIX IANA registry consistency, so sourceIPv4PrefixLength as an example.

sourceIPv4PrefixLength has an Abstract Data Type of "unsigned8", but omits the "Data Type Semantics".

The issue with srhSegmentIPv6LocatorLength is the opposite of this.

P.


On 08/01/24 13:59, Benoit Claise wrote:
Paul, Brian,

This email relates to

The following errata report has been submitted for RFC9487,
"Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7728 [rfc-editor.org]<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7728__;!!OSsGDw!Lyv_id3AIUO1Yuhu1aZmSjDK62wtQR0z3DBcmkJ7ULPRsQGC5d2hh4yuFPtuL-XZ6WoLxmXbbwRNgFnfkJ6hnA$>

I haven't seen a reply to this email so far.
So what do you think?

Regards, Benoit


On 12/14/2023 10:56 AM, Benoit Claise wrote:
Dear all,

I looked back at the history of this.

This is the last email: discussion with Paul Aikten about srhSegmentIPv6LocatorLength
    https://mailarchive.ietf.org/arch/msg/opsawg/S7lMHhekA7ty7KjUS5LXwlkq950/# [mailarchive.ietf.org]<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/opsawg/S7lMHhekA7ty7KjUS5LXwlkq950/*__;Iw!!OSsGDw!Lyv_id3AIUO1Yuhu1aZmSjDK62wtQR0z3DBcmkJ7ULPRsQGC5d2hh4yuFPtuL-XZ6WoLxmXbbwRNgFlmDpkiww$>


Question: should srhSegmentIPv6LocatorLength be changed to quantity? I
think so (remember: doc in AUTH48)

Without reply, I went for the path of IFPIX IANA registry consistency, so sourceIPv4PrefixLength as an example.

If we collectively agree to have an errata here, fine.
However, more updates are required to the IPFIX IANA. (https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/ [datatracker.ietf.org]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/__;!!OSsGDw!Lyv_id3AIUO1Yuhu1aZmSjDK62wtQR0z3DBcmkJ7ULPRsQGC5d2hh4yuFPtuL-XZ6WoLxmXbbwRNgFmJzC6kAg$> ?)

Regards, Benoit

On 12/12/2023 12:33 PM, [e-mail]<mailto:[e-mail]> wrote:
Hello All,

That’s interesting to see these diffs between -14 and RFC. I limited my erratum report to the abstract data type for IE 501, see https://www.rfc-editor.org/errata/eid7728 [rfc-editor.org]<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7728__;!!OSsGDw!Lyv_id3AIUO1Yuhu1aZmSjDK62wtQR0z3DBcmkJ7ULPRsQGC5d2hh4yuFPtuL-XZ6WoLxmXbbwRNgFnfkJ6hnA$>.

However, for the differences between -14 and RFC, I don’t have enough expertise to report about it. I hope someone more expert than myself on IETF processes can take care of this.

Best,
-Ahmed



From: "Aitken, Paul" <[e-mail]><mailto:[e-mail]>
Date: Tuesday, 12 December 2023 at 13:04
To: "Brian Trammell (IETF)" <[e-mail]><mailto:[e-mail]>, "Elhassany Ahmed, INI-NET-VNC-HCS" <[e-mail]><mailto:[e-mail]>
Cc: "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, Benoit Claise <[e-mail]><mailto:[e-mail]>, "Graf Thomas, INI-NET-VNC-HCS" <[e-mail]><mailto:[e-mail]>
Subject: Re: [IPFIX] Data type for srhSegmentIPv6LocatorLength in IPFIX Entities registry


Be aware: This is an external email.

RFC 9487 does not reflect what the IPFIX experts reviewed in the last draft (-14), as there are several differences between the "IANA Considerations" sections:

.1 and .10a below need errata. The others need the authors input.


5.1

The title, "IPFIX Information Elements Registry" and the "Table 1: IPFIX Information Elements Registry" descriptions are wrong, as this table is not the whole registry, but only the "New IPFIX IPv6 SRH Information Elements" at stated in -14.


5.1.6 / Description

-14:    The SRH Segment List
RFC:    The SRv6 Segment List


5.1.7 / Description
-14:    to reach the end of the Segment List in the SRH
RFC:    to reach the end of the Segment List from the SRH


5.1.10 / Abstract Data Type

-14:    Abstract Data Type:  unsigned8
RFC:    (missing text)


5.1.10 / Description

-14:    The SRH segment IPv6 locator length
RFC:    The length of the SRH segment IPv6 locator


P.


On 12/12/2023 08:46, Brian Trammell (IETF) wrote:
hi Ahmed,

Yep, this is an erratum.

Not an SR expert but as this is a “significant bit counter” I suspect unsigned8 is the appropriate type here.

Cheers,

Brian

On 12 Dec 2023, at 09:42, <[e-mail]><mailto:[e-mail]> <[e-mail]><mailto:[e-mail]> wrote:

Hello all,

I noticed IE 501 srhSegmentIPv6LocatorLength is recently added to the ipfix registry https://www.iana.org/assignments/ipfix/ipfix.xml [iana.org]<https://urldefense.com/v3/__https://www.iana.org/assignments/ipfix/ipfix.xml__;!!OSsGDw!Lyv_id3AIUO1Yuhu1aZmSjDK62wtQR0z3DBcmkJ7ULPRsQGC5d2hh4yuFPtuL-XZ6WoLxmXbbwRNgFmfnwysew$>without an abstract data type defined (in XML registry <dataType/>). I checked RFC 9487 that added this element to the registry, and it also doesn’t define an abstract data type for IE 501 srhSegmentIPv6LocatorLength.


This sound contradictory to RFC  7012 which states that:

dataType - One of the types listed in Section 3.1 [rfc-editor.org]<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc7012.html*section-3.1__;Iw!!OSsGDw!Lyv_id3AIUO1Yuhu1aZmSjDK62wtQR0z3DBcmkJ7ULPRsQGC5d2hh4yuFPtuL-XZ6WoLxmXbbwRNgFl0DvFXNA$> of this document or

      registered in the IANA "IPFIX Information Element Data Types"

      subregistry.

The implication for not putting a data type in the registry that automated code generators for parsing and handling IPFIX will not work. A user must intervene manually and read the references RFCs to figure out the appropriate data type to be used.

My question to the mailing list: Is my understanding for RFC7012 correct that a data type must be defined as one of IPFIX Information Element Data Types? And if so, I think we need to report an erratum for the RFC9487 and update the registry accordingly.


Best,
-Ahmed
_______________________________________________
IPFIX mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ipfix [ietf.org]<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!Lyv_id3AIUO1Yuhu1aZmSjDK62wtQR0z3DBcmkJ7ULPRsQGC5d2hh4yuFPtuL-XZ6WoLxmXbbwRNgFnkstXxXw$>




_______________________________________________

IPFIX mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ipfix [ietf.org]<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!Lyv_id3AIUO1Yuhu1aZmSjDK62wtQR0z3DBcmkJ7ULPRsQGC5d2hh4yuFPtuL-XZ6WoLxmXbbwRNgFnkstXxXw$>