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

Andy Bierman <andy@yumaworks.com> Thu, 07 March 2019 18:27 UTC

Return-Path: <andy@yumaworks.com>
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 C3E9912797D for <gen-art@ietfa.amsl.com>; Thu, 7 Mar 2019 10:27:35 -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=unavailable 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 2ZyVpS2IisUG for <gen-art@ietfa.amsl.com>; Thu, 7 Mar 2019 10:27:34 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 D731912798F for <gen-art@ietf.org>; Thu, 7 Mar 2019 10:27:31 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id r123so12421554lff.6 for <gen-art@ietf.org>; Thu, 07 Mar 2019 10:27:31 -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=1jvXkIfIdqtrU2VZIm9YZN7Q91q3yLakpbEbkB0DFhU=; b=sKu+PAEiBwaCvec2AXOjkjMDhrnSmidswNMSd/pA6dKJ2CfB2Dgql/LtOdtNNY/XrE E9Mdqj5W+D2Hs5vvd7ot1WkWS8N4UEqU0nFqgCUwu97h5M2LXlW2Mb5kQMddpBtsr99Y UimOC3CuGaUYK7HScXFdBJYbq7xKUFw1NTiR0Um0uePPWTr0ftiZRAOpCF2Kij8L7tbZ XWG/LLVfARkoZ0qUg777Tye1O5vj8hJIDiN4FVPYMSSyXeunB1EY7iwR64rJZg9NPDf8 kwkgzKsdf8T9mUqmYhMNC4LEHPMEpcYvgBcsiDnbXMAJGJrNermeFOnVffhKyinsrmXS 9psA==
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=1jvXkIfIdqtrU2VZIm9YZN7Q91q3yLakpbEbkB0DFhU=; b=AIXDlQ8+L7HpOzOpQAB+/1SfEjOaRQ0YhRlnlHmrVJb+aJJdoCDOdgIyjZtB1khUfo uEw6NHmTBjNYpTsyf3rDvU56o5GnaQLQ93e0vtH9LF6238k3WBuUq8AyN5SE2i5bpZqq LN2maOk02GfLiXHYu5dSKrffEMmexV71rkpB38BxMXtl8gYdeq3BDunJyDDbBNUzRrh8 Z/HKWgm7wlZA2xXFtpM+mL0TyZkgwGMCzYuiq0ghCmGMSedrYDT7br7TqzbBYOfeyObZ zs23zUeg6CBrZrBNp2vEqyCMlj7UwJOBMem55MfjtIvca+zDtMHetux7NBSR9TeVp5iU xlRQ==
X-Gm-Message-State: APjAAAWsm5eBBRfLdDNIAzxnI/ay+FXeBIhv4dqaR9iqfRHz0jJ8HTRG 8u8zU2ae0kIbooX/dIDNM/La82Mv0c3OjSpyBIur2Q==
X-Google-Smtp-Source: APXvYqyHSG7+y5/lXG7Uk59j67P6hCQN2KedmkKkHWX1fYqhByhTUovvDb8hlRbOD+82ljbDh7SCg/AocJyKuq65cOk=
X-Received: by 2002:ac2:53ab:: with SMTP id j11mr7790844lfh.49.1551983249830; Thu, 07 Mar 2019 10:27:29 -0800 (PST)
MIME-Version: 1.0
References: <155183201188.27630.13798246400958114485@ietfa.amsl.com> <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org>
In-Reply-To: <0BE3CBAC-40EF-4162-82D0-04C638A3B429@chopps.org>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 7 Mar 2019 10:27:18 -0800
Message-ID: <CABCOCHR-AROb3D1tyEgkNiP0keab_Q-K4T+iSPNwD8eg3ASG4A@mail.gmail.com>
To: Christian Hopps <chopps@chopps.org>
Cc: Datatracker on behalf of Elwyn Davies <ietf-secretariat-reply@ietf.org>, General Area Review Team <gen-art@ietf.org>, draft-ietf-netmod-module-tags.all@ietf.org, IETF discussion list <ietf@ietf.org>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004dd0b60583854262"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/qeF9sFJTpd2DV5Ep1XpvWj0GWD8>
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:27:36 -0000

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
>