From benoit.claise@huawei.com Fri Oct 20 06:52:17 2023 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693CDC14CE55; Fri, 20 Oct 2023 06:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.091, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaVHy_aZ0-0m; Fri, 20 Oct 2023 06:52:12 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93622C151077; Fri, 20 Oct 2023 06:52:12 -0700 (PDT) Received: from frapeml500001.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SBmGH2Tc7z6K63D; Fri, 20 Oct 2023 21:51:35 +0800 (CST) Received: from [10.48.214.76] (10.48.214.76) by frapeml500001.china.huawei.com (7.182.85.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Fri, 20 Oct 2023 15:52:06 +0200 Content-Type: multipart/alternative; boundary="------------KLfYAHII9uRf5ZgdzJeN6HI9" Message-ID: <8e6d192b-eb1a-2753-8441-fdc91cadda86@huawei.com> Date: Fri, 20 Oct 2023 15:52:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-GB To: , "Aitken, Paul" CC: "ipfix@ietf.org" , "Eric Vyncke (evyncke)" , "opsawg@ietf.org" References: From: Benoit Claise In-Reply-To: X-Originating-IP: [10.48.214.76] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To frapeml500001.china.huawei.com (7.182.85.94) X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPFIX] Full or Truncated EHs RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2023 13:52:17 -0000 --------------KLfYAHII9uRf5ZgdzJeN6HI9 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Paul, I looked at this one below. On 10/19/2023 11:02 PM, mohamed.boucadair@orange.com wrote: > > > 3.2 Data Type Semantics: > > - this is not an identifier. It seems be a new type consisting of > (type, count) tuples. > > > */[Med] Will double check this one. /* > > > You are right that ipv6ExtensionHeaderCount consists of (type, count) tuples. I tried too look at similar IPFIX IEs in IANA The closest one I could find might be anonymizationFlags, which categorized as "flags" So which "Data Type Semanitcs" should be have? Flags? Then I investigated further..._ _1. https://datatracker.ietf.org/doc/html/rfc7012#section-2.1 dataTypeSemantics - The_integral _types are qualified by additional semantic details. Valid values for the data type semantics are either specified inSection 3.2 of this document or will be specified in a future extension of the information model. 2. Looking at IPFIX IANA, I saw as series of integral IPFIX IEs with "Data Type Semantics" with no value. See sourceIPv4PrefixLength 3. I see a single integral IPFIX IE, "srhSegmentIPv6LocatorLength" (document https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/14/ in AUTH48 right now), with "Data Type Semantics" with "default" value. That seems wrong to me. Interestingly, I don't see this "Default" in https://datatracker.ietf.org/doc/html/rfc7012#section-3.2, as a valid Data Type Semantic. BUT searching around, I found this: https://datatracker.ietf.org/doc/html/rfc5610#section-3.6 +-------+--------------+ | Value | Description | +-------+--------------+ | 0 | default | | 1 | quantity | | 2 | totalCounter | | 3 | deltaCounter | | 4 | identifier | | 5 | flags | +-------+--------------+ Table 2: IE Semantics Values See how "default" is different than "quantity", which is inconsistent with the following text https://datatracker.ietf.org/doc/html/rfc7012#section-3.2.1 3.2.1 . quantity "quantity" is a numeric (integral or floating point) value representing a measured value pertaining to the record. This is distinguished from counters that represent an ongoing measured value whose "odometer" reading is captured as part of a given record._This is the default semantic type of all numeric data types._ Question:  Data Type Semantic => is "default" different than "quantity"? Question: if yes, what's the difference? Question: if not different, errata in RFC5610? Question: should srhSegmentIPv6LocatorLength be changed to quantity? I think so (remember: doc in AUTH48) 4. Then, coming back to ipv6ExtensionHeaderCount , I wonder, is the "Data Type Semantics" optional? https://datatracker.ietf.org/doc/html/rfc7012#section-3 Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 are integral data types. As described inSection 3.2 , their data type semantics_can be further specified_, for example, by 'totalCounter', 'deltaCounter', 'identifier', or 'flags'. "can be" => seems optional to me. However, https://datatracker.ietf.org/doc/html/rfc7012#section-3.2 is not clear about it So proposal for ipv6ExtensionHeaderCount => remove the Data Type Semantic. At least, that would consistent with the current IANA entries. If not, https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-fixes might need a long series of updates (I am not searching for more work :-) ), to add "default" for integral IPFIX IE with no values. Regards, Benoit --------------KLfYAHII9uRf5ZgdzJeN6HI9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Paul,

I looked at this one below.

On 10/19/2023 11:02 PM, mohamed.boucadair@orange.com wrote:


3.2 Data Type Semantics:

- this is not an identifier. It seems be a new type consisting of (type, count) tuples.


[Med] Will double check this one.=



You are right that ipv6ExtensionHeaderCount consists of (type, count) tuples.
I tried too look at similar IPFIX IEs in IANA
The closest one I could find might be anonymizationFlags, which categorized as "flags"
So which "Data Type Semanitcs" should be have? Flags?

Then I investigated further...

1. https://datatracker.ietf.org/do= c/html/rfc7012#section-2.1
   dataTypeS=
emantics - The integral types are qualified by additional
      semantic details.  Valid values for the data type semantics are
      either specified in Section 3.2 of this document or will be
      specified in a future extension of the information model.
2. Looking at IPFIX IANA, I saw as series of integral IPFIX IEs with "Data Type Semantics" with no value.
See sourceIPv4PrefixLength

3. I see a single integral IPFIX IE, "srhSegmentIPv6LocatorLength" (document https://datatracker.ietf.org= /doc/draft-ietf-opsawg-ipfix-srv6-srh/14/ in AUTH48 right now), with "Data Type Semantics" with "default" value.
That seems wrong to me.

Interestingly, I don't see this "Default" in https://datatracker.ietf.org/doc/html/rf= c7012#section-3.2, as a valid Data Type Semantic.
BUT searching around, I found this: https://datatracker.ietf.org/doc/html/rf= c5610#section-3.6
 =
                        +-------+--------------+
                         | Value | Description  |
                         +-------+--------------+
                         | 0     | default      |
                         | 1     | quantity     |
                         | 2     | totalCounter |
                         | 3     | deltaCounter |
                         | 4     | identifier   |
                         | 5     | flags        |
                         +-------+--------------+

                         Table 2: IE Semantics Values
See how "default" is different than "quantity", which is inconsistent with the following text
https://datatracker.ietf.org/doc/html/= rfc7012#section-3.2.1

3.2.1.  quantity

   "quantity" is a numeric (integral or floating point) value
   representing a measured value pertaining to the record.  This is
   distinguished from counters that represent an ongoing measured value
   whose "odometer" reading is captured as part of a given record.  Th=
is
   is the default semantic type of all numeric data types.

Question:=C2=A0 Data Type Semantic =3D> is "default" different tha= n "quantity"?
Question: if yes, what's the difference?
Question: if not different, errata in RFC5610?
Question: should srhSegmentIPv6LocatorLength be changed to quantity? I think so (remember: doc in AUTH48)

4. Then, coming back to ipv6ExtensionHeaderCount , I wonder, is the "Data Type Semantics" optional?
https://datatracker.ietf.org/doc/html/rfc7= 012#section-3

   Abstract =
data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types.
   As described in Sect=
ion 3.2, their data type semantics can be further
   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.
"can be" =3D> seems optional to me.
However,=C2=A0 https://datatracker.ietf.= org/doc/html/rfc7012#section-3.2 is not clear about it

So proposal for ipv6ExtensionHeaderCount =3D> remove the Data Type= Semantic.
At least, that would consistent with the current IANA entries.
If not, https://datatracker.ietf.org/d= oc/html/draft-ietf-opsawg-ipfix-fixes might need a long series of updates (I am not searching for more work :-) ), to add "default" for integral IPFIX IE with no values.
Regards, Benoit

    

    

    

    

  


--------------KLfYAHII9uRf5ZgdzJeN6HI9--