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

Hi Paul,

On 1/8/2024 3:50 PM, Aitken, Paul wrote:
> 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.
For this one, I know that you are in discussion with the AD.
>
> 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.
Aha, this is where my mistake comes from!
We discussed the Data Type Semantics and, from my edits, I removed the 
Abstract Data Type.
Sorry for this stupid editorial change ... during AUTH48... hence your 
first remark above (which is valid).

This errata should be accepted for the unsigned8, but what do you 
suggest for "Data Type Semantics"? Remove it or keep default?
See 
https://mailarchive.ietf.org/arch/msg/opsawg/S7lMHhekA7ty7KjUS5LXwlkq950/# 
for some background on it.

Regards, Benoit
>
> 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]
>>
>> 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]
>>>
>>>
>>>     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] ?)
>>>
>>> Regards, Benoit
>>>
>>> On 12/12/2023 12:33 PM, Ahmed.Elhassany@swisscom.com 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].
>>>>
>>>> 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" <paitken@ciena.com>
>>>> *Date: *Tuesday, 12 December 2023 at 13:04
>>>> *To: *"Brian Trammell (IETF)" <ietf@trammell.ch>, "Elhassany Ahmed, 
>>>> INI-NET-VNC-HCS" <Ahmed.Elhassany@swisscom.com>
>>>> *Cc: *"ipfix@ietf.org" <ipfix@ietf.org>, Benoit Claise 
>>>> <benoit.claise@huawei.com>, "Graf Thomas, INI-NET-VNC-HCS" 
>>>> <Thomas.Graf@swisscom.com>
>>>> *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, <Ahmed.Elhassany@swisscom.com>
>>>>         <mailto:Ahmed.Elhassany@swisscom.com>
>>>>         <Ahmed.Elhassany@swisscom.com>
>>>>         <mailto:Ahmed.Elhassany@swisscom.com> wrote:
>>>>
>>>>         Hello all,
>>>>
>>>>         I noticed IE 501 srhSegmentIPv6LocatorLength is recently
>>>>         added to the ipfix
>>>>         registryhttps://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 inSection 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
>>>>         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
>>>>         IPFIX@ietf.org <mailto:IPFIX@ietf.org>
>>>>         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
>>>>
>>>>     IPFIX@ietf.org
>>>>
>>>>     https://www.ietf.org/mailman/listinfo/ipfix [ietf.org]
>>>>
>>>
>>
>