[IPFIX] [Technical Errata Reported] RFC9487 (7728) (was: Re: Data type for srhSegmentIPv6LocatorLength in IPFIX Entities registry)

[Benoit Claise <[e-mail]>]

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

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/#
>
>
>     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/ ?)
>
> Regards, Benoit
>
> On 12/12/2023 12:33 PM, [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.
>>
>> 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]>
>> *Date: *Tuesday, 12 December 2023 at 13:04
>> *To: *"Brian Trammell (IETF)" <[e-mail]>, "Elhassany Ahmed, 
>> INI-NET-VNC-HCS" <[e-mail]>
>> *Cc: *"[e-mail]" <[e-mail]>, Benoit Claise 
>> <[e-mail]>, "Graf Thomas, INI-NET-VNC-HCS" 
>> <[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
>>         registryhttps://www.iana.org/assignments/ipfix/ipfix.xml
>>         <https://www.iana.org/assignments/ipfix/ipfix.xml>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 inSection 3.1  <https://www.rfc-editor.org/rfc/rfc7012.html#section-3.1>  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
>>         ofIPFIX 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
>>         <https://www.ietf.org/mailman/listinfo/ipfix>
>>
>>
>>
>>     _______________________________________________
>>
>>     IPFIX mailing list
>>
>>     [e-mail]
>>
>>     https://www.ietf.org/mailman/listinfo/ipfix
>>
>