Re: [netmod] WGLC on node-tags-09
Adrian Farrel <adrian@olddog.co.uk> Wed, 28 June 2023 15:25 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896AAC151065 for <netmod@ietfa.amsl.com>; Wed, 28 Jun 2023 08:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk
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 Fxa_EZ_0MCvB for <netmod@ietfa.amsl.com>; Wed, 28 Jun 2023 08:25:39 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6CEC14CF1E for <netmod@ietf.org>; Wed, 28 Jun 2023 08:25:37 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 35SFPL2J014219; Wed, 28 Jun 2023 16:25:21 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6468B4604B; Wed, 28 Jun 2023 16:25:21 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4E9B24604A; Wed, 28 Jun 2023 16:25:21 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS; Wed, 28 Jun 2023 16:25:21 +0100 (BST)
Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 35SFPKU4004407 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Jun 2023 16:25:21 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Qin Wu' <bill.wu@huawei.com>, 'Kent Watsen' <kent+ietf@watsen.net>, netmod@ietf.org
References: <0fdc64cf915a41e3994348e5d647df9d@huawei.com>
In-Reply-To: <0fdc64cf915a41e3994348e5d647df9d@huawei.com>
Date: Wed, 28 Jun 2023 16:25:20 +0100
Organization: Old Dog Consulting
Message-ID: <0aea01d9a9d4$c01060c0$40312240$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQGls3+Wa3j5jdcS2FRMD8Fhq58kALAH8Bzg
X-Originating-IP: 82.69.109.75
X-Thinkmail-Auth: adrian@olddog.co.uk
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding; s= 20221128; bh=THIaqSrkEr+CrlPp2HjnwlDAownYkIDvXGaaPplZpUM=; b=D0/ LjW0azkYMcJ2+Nuo0+FPC0acUnXI/4n+TcavTrhQQ5vveF8vkWQ/23ncqgcRgnAO PTotCMbt41oV4IqGs0B/Gs3A6V2HLO20s0ep6nilY0tR2F/IpgMQTI8tbCiXsUqk BThx8pGRNup9C7waBTf2VPnUMeCxFCmVW/uiECHYIUVJIXePWhK2zx87W/hZ1SEF T0EfdKcndCDvFThXD6P/16kdlA1neFtPpJGglZQOQ2TN9MdB4UUCsUIUrLPKOfEr i6YP13SVdW/bCCyJPp2AHYbUfSECEoBE+gC9+kWtB2aSnx1wNCaH7eEoXK5vk/EM efB1BuKa+PTLrgdlb2g==
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27720.000
X-TM-AS-Result: No--14.443-10.0-31-10
X-imss-scan-details: No--14.443-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27720.000
X-TMASE-Result: 10--14.442900-10.000000
X-TMASE-MatchedRID: IDdx3MBO6EDxIbpQ8BhdbI61Z+HJnvsOTJDl9FKHbrlw7FL+ShG0BGVY YC40jpLGPG/R1GUal1WUcqEAkfOLxgjt4l5TmF6fbb4JyMK+kzApA2ExuipmWixMw0FMkBlZ0Am pRo8p3xNntfXZWMw70vIfyQa9Xve/wTIpOR1711L1A8E3bi1JHGl5nVxdmJvH+OlLgwHNx/H9GB RrZgui1pA8bj4Y6Py03r9ddThq4vNSuJfEWZSQfN35+5/2RxqmMVx/3ZYby7+ZS4w4kqRPPkQBD VDzvZj13Rq1qtW57uP0xVQZRPSbxvn/om5XE6y/sWltH2OCDLh4fCfFRQ30yFK85G40RIzS0+Qb BcjoBeyEju6+OLyeKxP91RdGQH6y08q9KSsUtVdswYo64ufkVUjmbQR0Nyy8B0/bCpixkw3J6KR jxVC/CW8DUcTwCQ5dmgXnZPTMVm3bthYHhtpcktHu43wY4QfHT5ysQDj6eFm+IQ+aeLlhn4Y+d4 I4WCpECvxhrH3JmRRrdJAvX4JirBzIu43df0mM/e+uN180e5dlRzZAkKRGDcboqPA6+88kOSLmt hZG++ZVVx/3S8KTculks+SChsBJRcMdmrUY7NH0hv/rD7WVZMot0tGMsqGnPHMAbjuhwd/aC9i9 iC+FL4uD2my4DFTX0e+Nw44UnKIuRdmDWOweykA0Hz2xXRsnfS0Ip2eEHny+qryzYw2E8AvgpsX ypsAMDMq3z/Y/gtXfd+P6wwCt8xoxTJ4LSy1onAOnU4i/fON2oJRFNxWABv3V0T/64788PuiEP4 DF1qrC9yUviG359dy89tVOrDil
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_SCxT0SHC1iB8V2rdI1AQ9BNSsI>
Subject: Re: [netmod] WGLC on node-tags-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jun 2023 15:25:43 -0000
Thanks Qin, In line... Adrian == Discussion == Section 7. I'm not completely comfortable with the way you use the base identity node-tag-type to capture the variants defined in the IANA registry shown in 9.2. What happens when another document defines a new IETF tag type? Is it necessary to also write a new YANG module that augments this one? Or to respin this document? Those feel to me to be very ugly! The alternatives might be: 1. You simply use the tag as a string (i.e., using the typedef tag) and rely on implementations to know what the tag type means. 2. You change the identity to an Integer, and you include an integer in the IANA registry so that new tags are just new entries. 3. You move the base identity into an IANA-managed YANG module that is updated by IANA automatically in lockstep with the IETF tags registry [Qin Wu] Good comment, Andy also raised similar comment, the motivation of introducing node-tag-type identities is to address Jurgen's comment and try to make the node tag mechanism generic enough and allow future extension, we did provide an example in Appendix A which allow you add additional Auxiliary Data Property in the module extension. one thing I want to clarify is node-tag-type identities did capture the variants defined in the IANA registry, but node-tag-type identities will not be registered together with IETF YANG Data Node Tags. Secondly, we did use tag as a string, we choose to use the same typedef tag used for module tag, now for node tag. We have two ways to address this comment: 1. we completely remove identities from this module, the downside is it doesn't allow any future module extension. 2. we keep some of these identities for second level data node classification, e.g., summary, counter, gauge, unknown, etc but remove packet loss ,jitter ,delay identities from this draft since it seems to duplicate with what has already been defined in IANA registry, in addition, we remove some of IETF yang data node tags including summary, counter, gauge and unknown, which is redundant with identities for second level data node classification. [AF] I support the motivation. I would like the node tag mechanism to be extensible. I didn't notice the purpose of Appendix A (perhaps it could use a little more explanation?). I think your option 1 would only work if we move the identities to a new module (possibly under IANA control - my option 3) Your option 2 looks worthy of consideration, but it is a big change at this stage in the process - I don't want to cause disruption to the WG process as I am not an implementer of this technology. I wonder whether my options 1 and 2 wouldn't be simpler. -- I think that Section 1, in introducing the concept of tags, should spend a sentence describing YANG Module Tags [RFC8819] so that we can see how the YANG tags already exist, and how this work develops the idea. [Qin Wu] I think we have already done this, see relevant text in section 1 as follows: " To that aim, this document defines a YANG module [RFC7950] that augments the YANG Module Tags ([RFC8819]) to provide a list of node entries to add or remove node tags as well as to view the set of node tags associated with specific data nodes or instance of data nodes within YANG modules. " [AF] Hmmm. It's true that you provide the pointer to RFC 8819. I just wondered about a quick description of what it does. But I don't insist on this change. -- Apart from being able to deduce it from Section 4.3, it is not absolutely clear from Section 4 that the colon has special meaning. That is that all prefixes now and in the future are delimited by the colon. (This is important because, absent a colon, there is no way to distinguish an non-colon user prefix from any registered prefix.) This means that: - Future definitions of tag values might not realise that they are supposed to use a colon - you should clarify that all prefixes end with a colon noting that the colon is not a separator but is part of the prefix. This does beg the question about separators in the prefixes and in the tag values - Prefixes that contain colons will cause confusion and so you should probably make it a 'MUST NOT' - Tag values (after the prefix) that contain colons may cause confusion so you should probably make this a RECOMMENDation, although 4.2 suggests the use of colons as further separators. An alternative to all this is that you define the colon as the separator, and change the tag names to not include colons. But 9.1 makes it pretty clear that you expect all registered prefixes to end with a colon. [Qin Wu] That's really a good comment, so Tag = Tag prefix+ Tag Value, Colon is part of Tag prefix if you expect all registered prefix to end with a colon. The question is whether we see colon as separator or portion of the tag prefix. Do we need to make tag prefix is mandatory to have for a tag? [AF] I don't really mind. The closest to what you have is... - Tag prefix is not mandatory - All tag prefixes MUST end with a colon - Colons MUST NOT be used within a prefix - Colons SHOULD NOT be used in a tag value If you want to, you could specify a character to be used as a separator within prefixes and values (such as a period). -- 4.1 9.2 constrains these tags by saying that they must "conform to Net- Unicode as defined in [RFC5198], and shall not need normalization". I think you should state this in this section using BCP 14 language. [Qin Wu] How about the following change: OLD TEXT: " An IETF tag is a node tag that has the prefix "ietf:". All IETF node tags are registered with IANA in the registry defined in Section 9.2. " NEW TEXT: " An IETF Tag is a node tag that has the prefix "ietf:". All IETF Node Tags are registered with IANA in the registry defined in Section 9.2. These IETF Node Tags MUST conform to Net-Unicode as defined in [RFC5198], and SHOULD not need normalization. " [AF] Yes -- 4.2 These tags are defined by the vendor that implements the module, and are not registered with IANA. However, it is RECOMMENDED that the vendor includes extra identification in the tag to avoid collisions, such as using the enterprise or organization name following the "vendor:" prefix (e.g., vendor:entno:vendor-defined-classifier). Surely you have to go further than recommending? How will interop work unless you require 'entno' to be present? But here you have said "enterprise or organization name" and then used a field called 'entno' which looks very much like an Enterprise Number as registered by IANA (RFC2578) which would, IMHO, be a good solution. [Qin Wu] Correct, the motivation is to use additional enterprise name to avoid collision, Do you think I should add reference to RFC2578? [AF] Yes. RFC 9371 might be a good reference, too. -- 4.4 looks reasonable to me, but I think you need to add text to talk about how an implementation is supposed to handle a tag prefix it doesn't know (for example, one that is defined and added to the registry after the code was released). I suspect the intention is that all tags can be processed as opaque strings, and the prefixes are there in order to achieve uniqueness of the strings, but do not need to be processed. Thus all implementations should be able to process all tags regardless of their prefixes. [Qin Wu] Your understanding is correct, maybe add one more sentence at the end to say: " Therefore an implementation SHOULD be able to process all tags regardless of their prefixes. " [AF] Yes -- 5.2 An implementation MAY include additional tags associated with data nodes within a YANG module. These tags SHOULD be IETF ((i.e., registered) ) or vendor tags. It would be good to: - Expand on the "MAY" to say why an implementation might do that [Qin Wu] I think section 5.1 emphasizes adding tag at the module design stage while section 5.2 emphasizes that we can adding additional tag at the implementation stage, e.g., vendor A want to add some vendor specific tag, Vendor B want to add some other IETF tag that allow two vendors interoperable. - Add an alternative to the "SHOULD" and an indication of why an implementation might vary from the "SHOULD". [Qin Wu] How about the following change: NEW TEXT: " An implementation MAY include additional tags associated with data nodes within a YANG module at the implementation time. These tags SHOULD be IETF ((i.e., registered) ) or vendor tags. IETF tags allows better interoperability than vendor tags. " [AF] I'm afraid that this seems to miss my point. How about... " An implementation that wishes to define additional tags to associate With data nodes within a YANG module MAY do so at implementation time. These tags SHOULD be IETF (i.e., registered)), but MAY be vendor tags. IETF tags allows better interoperability than vendor tags. "
- [netmod] WGLC on node-tags-09 Kent Watsen
- Re: [netmod] WGLC on node-tags-09 Andy Bierman
- Re: [netmod] WGLC on node-tags-09 Andy Bierman
- Re: [netmod] WGLC on node-tags-09 Adrian Farrel
- Re: [netmod] WGLC on node-tags-09 Qin Wu
- Re: [netmod] WGLC on node-tags-09 Qin Wu
- Re: [netmod] WGLC on node-tags-09 Qin Wu
- Re: [netmod] WGLC on node-tags-09 Adrian Farrel
- Re: [netmod] WGLC on node-tags-09 Andy Bierman
- Re: [netmod] WGLC on node-tags-09 Qin Wu
- Re: [netmod] WGLC on node-tags-09 Qin Wu
- Re: [netmod] WGLC on node-tags-09 Adrian Farrel
- Re: [netmod] WGLC on node-tags-09 Qin Wu
- Re: [netmod] WGLC on node-tags-09 Lou Berger
- Re: [netmod] WGLC on node-tags-09 Qin Wu
- Re: [netmod] WGLC on node-tags-09 tom petch
- Re: [netmod] WGLC on node-tags-09 Jürgen Schönwälder
- Re: [netmod] WGLC on node-tags-09 tom petch