Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06
Andy Bierman <andy@yumaworks.com> Thu, 07 March 2019 18:44 UTC
Return-Path: <andy@yumaworks.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 2D4131279A8 for <netmod@ietfa.amsl.com>; Thu, 7 Mar 2019 10:44:33 -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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 MvX5CSHbdUAs for <netmod@ietfa.amsl.com>; Thu, 7 Mar 2019 10:44:30 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6F212795E for <netmod@ietf.org>; Thu, 7 Mar 2019 10:44:30 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id d26so12460676lfa.1 for <netmod@ietf.org>; Thu, 07 Mar 2019 10:44:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tjeO3jAD85NokzAEl7st3AVA2KdpBMgw1uVJe75BKtc=; b=lxC559AvsM4J5WozC2Rn4mSZGGWrOSMjNkggHlyk/Dyk9C5GksnK8SSSa8sLuvkfmZ LpbDJP9tzrLn31jqLA6SEtzOSODNEQWBsYXzf4fJlIWeznvg+uqK87d669t8MpPWyRGE RKhyH+5kcGgmIDizVhOOHDSQ8VepD9C9F4bfi039gymh3tFol4JIJEFoQC55qrLPILq7 Y2L8+xXLQU6BQE3dlbfEu1WVjszmm3U9da2Bx2QF8G2qWkS1Vk2peZo4K/movXkpqXYU lRezy+5gXCy92c8ggbLEUfjOiMG5woxXpqOejcwWLqT6obLxxzPZtk0P39bgklDkc4XI kbxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tjeO3jAD85NokzAEl7st3AVA2KdpBMgw1uVJe75BKtc=; b=Hh2lu8wtKid7M8Pu5EMOU+1O/nWHZjWgHIowxLkcNufmQjUMYcssmwMjd+R3gGg8zM fxPYNyQkq2jPyoA1BOXuVrP+OYT3EspLegp0NgjNqPw9eJItC1IGeyVXfzL9dWswthvw LM7DJTYzhK2f6c2vtaIBPBi9tl+JlIVjmnz9pu95F1t2M/VynEKpX30EEGMRUPf+qS8A kLs1Mf8Q88/AHsXko88v6kRKzfJk1ZT7XzFKaw4sR5JuzXKpdPfi8JeBvcWiuFw6mN1S W5wWg9op9oix7qk8fYq6Y3HQf+HDkMc5+mcMCo6qn/CbVOCpsgPva+rNe+onfYAGRcaH AaMg==
X-Gm-Message-State: APjAAAWtbqSw2ba19dP8jGSLvaH5fuunyyRkW6W405cmv0zoDDuMqEf1 Jc3X+hwZBtJEB14mYBGU3R1qsn1O4wRXlLF5GuUcgg==
X-Google-Smtp-Source: APXvYqw56BB4R2ugy2PrTIHQpxpyeu0VIGbqlxAvizPt4cCJzNUX99scstwb3cLSte7L7R/EFzxHRNCPuCec1fkdZd8=
X-Received: by 2002:ac2:53ab:: with SMTP id j11mr7826612lfh.49.1551984268140; Thu, 07 Mar 2019 10:44:28 -0800 (PST)
MIME-Version: 1.0
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>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 07 Mar 2019 10:44:16 -0800
Message-ID: <CABCOCHRxebOhNOEXe5nAmLdEAK-e3xeeqM1T9C1sDfkXABmugA@mail.gmail.com>
To: William Lupton <wlupton@broadband-forum.org>
Cc: Christian Hopps <chopps@chopps.org>, draft-ietf-netmod-module-tags.all@ietf.org, General Area Review Team <gen-art@ietf.org>, Datatracker on behalf of Elwyn Davies <ietf-secretariat-reply@ietf.org>, IETF discussion list <ietf@ietf.org>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fff3730583857e1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/F90P9zqWMEa9at-SwiE4UqpHgt4>
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 18:44:33 -0000
On Thu, Mar 7, 2019 at 10:37 AM William Lupton <wlupton@broadband-forum.org> wrote: > 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 > looks like a great solution and would be less duplication of registries Andy > > On Thu, 7 Mar 2019 at 18:28, Andy Bierman <andy@yumaworks.com> wrote: > >> >> >> On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps <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> 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 >>> > https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >
- [netmod] Genart last call review of draft-ietf-ne… Datatracker on behalf of Elwyn Davies
- Re: [netmod] [Gen-art] Genart last call review of… Elwyn Davies
- Re: [netmod] Genart last call review of draft-iet… Christian Hopps
- Re: [netmod] [Gen-art] Genart last call review of… Christian Hopps
- Re: [netmod] Genart last call review of draft-iet… Andy Bierman
- Re: [netmod] Genart last call review of draft-iet… William Lupton
- Re: [netmod] Genart last call review of draft-iet… Christian Hopps
- Re: [netmod] Genart last call review of draft-iet… Andy Bierman
- Re: [netmod] Genart last call review of draft-iet… Andy Bierman
- Re: [netmod] Genart last call review of draft-iet… Christian Hopps
- Re: [netmod] Genart last call review of draft-iet… Juergen Schoenwaelder
- Re: [netmod] [Gen-art] Genart last call review of… Elwyn Davies
- Re: [netmod] Genart last call review of draft-iet… Alex Campbell
- Re: [netmod] Genart last call review of draft-iet… Christian Hopps
- Re: [netmod] [Gen-art] Genart last call review of… Christian Hopps
- Re: [netmod] Genart last call review of draft-iet… Benjamin Kaduk
- Re: [netmod] Genart last call review of draft-iet… Christian Hopps
- Re: [netmod] [Gen-art] Genart last call review of… Alissa Cooper