Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06

Alex Campbell <Alex.Campbell@Aviatnet.com> Thu, 07 March 2019 23:40 UTC

Return-Path: <Alex.Campbell@Aviatnet.com>
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 88452131017; Thu, 7 Mar 2019 15:40:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdX70M-PXygC; Thu, 7 Mar 2019 15:40:37 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810059.outbound.protection.outlook.com [40.107.81.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E793130FB8; Thu, 7 Mar 2019 15:40:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aPkhIfak5uyjCI4ZI3xaHyd7/5shsS3m0Qo/pV6Hxck=; b=Zw4ycvEgMYc8xI9iTdWZV0FmEkzc4mMy2RFsDjcC3vbUB5Sdd2OJ0XgnEdDZKUXnwEEmuVHHqIz/O0eF3s4Oxro5k/YYyURp35JI2za1qfMzkhwYv0r0rKEgXrQjlxOHn//G4/QSFv6R00NUDRK1hHAEoqk7JwL2ulq9dbmpZ4U=
Received: from CY4PR2201CA0005.namprd22.prod.outlook.com (2603:10b6:910:5f::15) by CY4PR22MB0597.namprd22.prod.outlook.com (2603:10b6:903:e0::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16; Thu, 7 Mar 2019 23:40:35 +0000
Received: from DM3NAM03FT015.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::209) by CY4PR2201CA0005.outlook.office365.com (2603:10b6:910:5f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1686.16 via Frontend Transport; Thu, 7 Mar 2019 23:40:35 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com; client-ip=192.147.115.52; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.52) by DM3NAM03FT015.mail.protection.outlook.com (10.152.82.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Thu, 7 Mar 2019 23:40:33 +0000
From: Alex Campbell <Alex.Campbell@Aviatnet.com>
To: William Lupton <wlupton@broadband-forum.org>, Andy Bierman <andy@yumaworks.com>
CC: Datatracker on behalf of Elwyn Davies <ietf-secretariat-reply@ietf.org>, IETF discussion list <ietf@ietf.org>, NetMod WG <netmod@ietf.org>, General Area Review Team <gen-art@ietf.org>, "draft-ietf-netmod-module-tags.all@ietf.org" <draft-ietf-netmod-module-tags.all@ietf.org>
Thread-Topic: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06
Thread-Index: AQHU1T8nb8i+TYPV90KSfkw71s2JFg==
Date: Thu, 07 Mar 2019 23:40:32 +0000
Message-ID: <1552002032265.43670@Aviatnet.com>
References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org> <CABCOCHR-AROb3D1tyEgkNiP0keab_Q-K4T+iSPNwD8eg3ASG4A@mail.gmail.com>, <CAEe_xxiZS8cTVN=FuULJ_2ppdYrjoiHTJPYu0an4Z-oJY7hQsQ@mail.gmail.com>
In-Reply-To: <CAEe_xxiZS8cTVN=FuULJ_2ppdYrjoiHTJPYu0an4Z-oJY7hQsQ@mail.gmail.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: multipart/alternative; boundary="_000_155200203226543670Aviatnetcom_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(136003)(39850400004)(346002)(396003)(2980300002)(199004)(189003)(51914003)(8676002)(4546004)(30436002)(11346002)(81156014)(126002)(36756003)(6486002)(81166006)(5660300002)(446003)(336012)(956004)(486006)(53416004)(117636001)(476003)(8936002)(54906003)(2616005)(229853002)(7736002)(97736004)(102836004)(7696005)(53546011)(86362001)(71190400001)(106002)(53936002)(54896002)(356004)(236005)(6306002)(14444005)(72206003)(93886005)(69596002)(966005)(76176011)(478600001)(4326008)(6246003)(36736006)(3846002)(6116002)(606006)(186003)(110136005)(106466001)(316002)(97876018)(26005)(118246002)(19627405001)(84326002)(2906002)(25786009)(16586007); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR22MB0597; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:ErrorRetry; A:1; MX:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 01289b02-54bf-4deb-53c4-08d6a3564b33
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4608103)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0597;
X-MS-TrafficTypeDiagnostic: CY4PR22MB0597:
X-MS-Exchange-PUrlCount: 2
X-Microsoft-Exchange-Diagnostics: 1; CY4PR22MB0597; 20:a1dV7CO38/lOTLSk6y6n5vNzsjJ6Ma0GJkSq8/txwYF+R/Gj1kKGZy+EZGw8aggRdmP5aCWmEOPywflqGQdZtQSRB+tLBiCVcBvK15czgUYryL/C9prsV5rsjvJn9dnXFx1d0oW2LEPbVCcistM8ijQFgWy0IPdK8OGoBT7S7ZlJk1XOQOYdBQY7pnVNpZVg9PELasP2cUBLESVIFM2OWpsLtwh0isvUKkDD7jmcGGcMg1dO9VaWIt8KgAiz5JpzLMVXJB6Sdhh/6JUGMtKad45u8emw2BCP5r7aI/vgjophsNxrSUnMFMPctxVKXYaRcwyo5M+TCAUMLB63wXUqd28r2s8DAXkkuzTAmRXhbAZXWloyLIgoDQY1D5K/qR/63loiPic9Afb5UXQqTAH+Gz0hKAy4OEUOO4IPa0VXUoy3+GISxcU8TuILsoqGU7pOwiA92l7sfpS2ffnJUcjle9S8kbydayBBQ0aRV+wry4z8vvJdVRXIPl/zmhno/aNt
X-Microsoft-Antispam-PRVS: <CY4PR22MB05976A39D63B92A3A378F929874C0@CY4PR22MB0597.namprd22.prod.outlook.com>
X-Forefront-PRVS: 096943F07A
X-Microsoft-Exchange-Diagnostics: 1; CY4PR22MB0597; 23:WYzpLg6bnOeWCrUSIhiJw+wVsVMrd0IquPQ5ArEn4z8Pe3UurWbiSQrvR4MZy+bYjYFHPmOcsJeam+I+J0W094QBTTTkCw6JPSk7N5AYgORXjIMk9QmWEd4I9zVXtL1gMQ0s7NPjc7d1lmTMay8DL9H3dKScj8liQ1X7bmdb3arukm5gV0nBzQv6HtmbK+9orlDITnUHzsdLSp2kX288H6M4DtVf8i4WoqbYkDHtl4bxD2lenTRtdnPTgr9vFEnNXOgYIe2QLXf1QDk+oyF55DcjUcsChrFqjORh0SUbESrNwrcMJuFC1E21YPleSyzTkNKGbfeF+YrgOqdSCFuIJ4f7ozrbb072h52P2Uyc1tklt9V+5FBjxwntAlfTrastO0SaxdanGGbhZln/R/2Vzg7pOwCXWqWNAE4y6CADMR9qaKQnzvOxWND63XVHMPstDqX0Qhp/FSAG6Y9CmmTv7k2G8Jk0B1EAe5Y946YufqMZY9akxO0tXuyaLrnQNGZiboc3AbUkwPMPI7fCoTs7YqmACYWhIZtNyZrSVCG61B/KSaA7Z69Hk0nptZz5ZxeAMtz5tksvS4bBFRTIyg7FO8r4bdfCH7sNbvZiIQ2TrBRCXGzHZN7JAxSe+j3LpXz+k32rlyLILB3weyVmXLh4Kq/fFeq2CO3Ho6WYv9gHC3Wuhj4ShCGuWeNHLmwiticonQBL6OgCGhIW0IcfCF1Kib6qMBdrB4qGn8kcOmRGPXGG4Wz9pRKfG9cG9JVcyqpTn2nxZCjSgFJoV9JEUfa+9Zu+N/Ugx74u/2C5iFqz1M4Q5gN+DPOQqbKILsEKdEo0Aky0huRYZoaJKwRTzBkjj00UpPbM9dhk0KHGLvBkMnP8ZotG5sX5Vjp/VbwPMqoGNSRnjVSuc6uOPAFd/rHqfhVX8xzuegGaic7RznMGPoV3cWPUVDIjINvgrRLxbhRypCOOaYzApPjiAG03QuUlS6ljrF+bOYwnr/BFlUhCrTnNAMgXbJxFQcIJe5eXzRiGsAEGS0eJneie7wmqYXKRjsds1IOtcgGyN0fZq4vMsf1fn3m06bFUIjKqaPWI2yYHwjvMAxnvexLa36DCeFLzhw40V05keRenRajHlSQw6ZyWtVGX3CF/0OpDzThQnE4nO1S1OlEjvELNehgYymLTrnqZnUKd4n0ikZx4u/uACYDqqmqapWO4VwCftXNHL0A1+NLRDeU2NtJn3+oAiSOVsjbLjDYVEUgkgItI2etBhp8dvX/gxTfXA/PuIfDVxSUYjyZlY4LPbrkl4pO2g/4jO6FuXmDDpqTbyeq+M4YdQibBq/2rJeL/M1DRRkpwJkiFaR/ShKCr8WaR7W04JTuu165gX56etKh9n3Wb0EVq2wXRU1LIitnvZ++UdMwxsPt0sqA1EUzgW1/FgZmq25CplBaJHAlYRv9l+aw7t07xyypslhd8J7VjFIm1+TW5IQza8uR4U6EcuhAnrUGjobSdrA==
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: fE9ZJap73jktDeJu8zsCaUib6aWitkwUwiVZT3I8mShRbGrgOHpLhl4v6e1diPI4niF+uVe8UgCFPY3Vu/XGERPDy7+1RkddivDDZnDNzachhv25WXT1CPAfkKVq5mr2aEUpMFkcUVy+IP06vNcUcOh65rdv/lsE2+vmiY/ujsrxpFboFrn7T6PHiF2qZGQJFtBufi5qjfUEL3qbTczsxn8D7UIK/1Y8f+vh34DRFwuFK+CEY5E87PDc5OwyQmQ6GyWYnGLxNIzRz/D56h3SM7Otyu1GkUjLe89dKUChGbUdc7uuD5e1vj6Gvbi5v7bDqxRXJHnRV0DfizJPghyoOGxL7ucmFA+g6J6ZTFnuKafvW9OiCST8R1nERMEaCD+skQU5bOdYFgVEj8SdthLovqZDL3uvriYBQvtb+QQSZWg=
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2019 23:40:33.8699 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 01289b02-54bf-4deb-53c4-08d6a3564b33
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52]; Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0597
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xpA4kvfSxH-jI72YPsugqm4YlHc>
Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 07 Mar 2019 23:40:42 -0000

In that case, why not make it so the tags are actually valid URIs, similar to XML namespaces?


________________________________
From: netmod <netmod-bounces@ietf.org> on behalf of William Lupton <wlupton@broadband-forum.org>
Sent: Friday, 8 March 2019 7:37 a.m.
To: Andy Bierman
Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; NetMod WG; General Area Review Team; draft-ietf-netmod-module-tags.all@ietf.org
Subject: Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06

This remark might be out of context (I haven't been following the details) but this reference to prefixes makes me wonder whether there's any way that registered URN namespaces could be regarded as valid prefixes. https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

On Thu, 7 Mar 2019 at 18:28, Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>> wrote:


On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>> wrote:
Thanks for the review! Comments inline.

> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <ietf-secretariat-reply@ietf.org<mailto:ietf-secretariat-reply@ietf.org>> wrote:
>
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
....
> If I read correctly, the YANG definition in s4.2 REQUIRES that all tags have a
> prefix.  For clarity, it would better if this read:
>    All tags MUST begin with a prefix; it is intended that this prefix SHOULD
>   [or maybe 'should'] indicate
>  the ownership or origination of the definition.

The intent was to not put the MUST on users. As the final arbiters of tags, users should be free to do whatever they want and not have implementations or standards superfluously block them from doing so. How about we carry the SHOULD into the typedef in the YANG model as well? That seems reasonable to me, i.e.,

  typedef tag {
    type string {
      length "1..max";
      pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
    }
    description
      "A tag is a type 'string' value that does not include carriage
       return, newline or tab characters. It SHOULD begin with a
       standard prefix.";




I strongly agree that a prefix SHOULD be present, not MUST be present.
I also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix "vendor:"
seems a bit short-sighted)


Andy

> S2, para 1: s/yang type/YANG type/ (I think)
>
> S2.2: s/follwing/following/
>
> S3.1, para 2:
> OLD:
> If the module definition is IETF standards track, the tags MUST also be Section
> 2.1. Thus, new modules can drive the addition of new standard tags to the IANA
> registry, and the IANA registry can serve as a check against duplication.
>
> NEW:
> If the module is defined in an IETF standards track document, the tags MUST use
> the prefix defined in Section 2.1. Thus, definitions of new modules can drive
> the addition of new standard tags to the IANA registry defined in Section 7.2,
> and the IANA registry can serve as a check against duplication.
>
> ENDS
>
> S3.2: s/standard/IETF Standard/
>
> S3.3: It would be useful to introduce the term 'masking' used later in the YANG
> module definition.

How about:

"Tags of any kind can be assigned and removed by the user using normal
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =masked-tag= entry for
a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer to RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod