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

William Lupton <wlupton@broadband-forum.org> Thu, 07 March 2019 18:37 UTC

Return-Path: <wlupton@broadband-forum.org>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FD41277E5 for <gen-art@ietfa.amsl.com>; Thu, 7 Mar 2019 10:37:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level:
X-Spam-Status: No, score=0.599 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, SORTED_RECIPS=2.499, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadband-forum-org.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 wm2gNTRWzi5m for <gen-art@ietfa.amsl.com>; Thu, 7 Mar 2019 10:37:38 -0800 (PST)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0: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 CF815130F13 for <gen-art@ietf.org>; Thu, 7 Mar 2019 10:37:35 -0800 (PST)
Received: by mail-it1-x130.google.com with SMTP id l139so17334482ita.5 for <gen-art@ietf.org>; Thu, 07 Mar 2019 10:37:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadband-forum-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U6x1xC5KpcvLqxF2hruf0TZUQCH7cB4Jqt4RpZWNZCA=; b=rxRZtVpVdZ+Rhnrbk5FWoUN5KJHVHgIcWbhtCE42wIdGqKcRCmwpwGo6VCurcgm1Te /vy0ejX63NvUFk7ydEu/FtD/1Sik/uLMpGLVBulyY8yWum0dKZR0jftK6jcK5ve6sFuV c1Ng+pRpvFQ0b4smqXTI7hKU+dX3/oW3fbbpWKM4kFLKI01isnDGvmGqIOMjjuTeEwEd mJsxrf9uvtZ9dmM/cnxMQHMi9ae5yIv3k7Ufri+Gi0zD6QpGvAAUErYjl9e9waY0EsO6 0MNY/8DcpjIaTrPkneklT94MUH7DJctRw22UjPtZUNGdgrGTotljfUSK27uKX5vhUFNG Cn/w==
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=U6x1xC5KpcvLqxF2hruf0TZUQCH7cB4Jqt4RpZWNZCA=; b=FEq9LSmpzZ0w+7js+5VI962teHwcLD+ep1g3l2/8/Sp5j0sVN5Thyot6k+H+7E003b PyKcWmSUnVdVpaTgjQrhOu0V0/UjWuZcTrSOWt2K0wew7njWeIcvEu7Yq83VJ6ELbutN wovd+SdysasfcEKtunpss0Fid7q0foJDTALIV/Nn47cKIuQFvnygBXORGh2gJ6HK05nx nAaFyFW5CSdAvicJERSswYHP5ELIlRduRxyCZFGt97MAluWy98IvCNY+TZL0DyLIrVJJ zzLixOOlRVGEGr7NP9k1QAhflU75DxOLGPSk97PqaOZVF7YbSPD4cy2jQO1NDyypEjiz Z1nQ==
X-Gm-Message-State: APjAAAWvsTr6xIPQumHfIeKqBR3xNXDpBP0HTavzzbBescJfBJFmGxw6 HvzaXF88hlMIxUdXpomb+yZt6is6LK8pKUHK5Vm8Mw==
X-Google-Smtp-Source: APXvYqy4SXaieXg0mNx60NXADyosl1N+g1dClzoK53Ldbd5JynkgbMhXwdcY6XrwS2rAMEb2G4K0+MOoZ7oGqCaJLXc=
X-Received: by 2002:a24:38c:: with SMTP id e134mr6018636ite.24.1551983854834; Thu, 07 Mar 2019 10:37:34 -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>
In-Reply-To: <CABCOCHR-AROb3D1tyEgkNiP0keab_Q-K4T+iSPNwD8eg3ASG4A@mail.gmail.com>
From: William Lupton <wlupton@broadband-forum.org>
Date: Thu, 7 Mar 2019 18:37:23 +0000
Message-ID: <CAEe_xxiZS8cTVN=FuULJ_2ppdYrjoiHTJPYu0an4Z-oJY7hQsQ@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
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="0000000000005da58805838566c6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/973H-n_FvihJyVuPXNdxxX7r_y4>
Subject: Re: [Gen-art] [netmod] Genart last call review of draft-ietf-netmod-module-tags-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Mar 2019 18:37:45 -0000

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> 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
>