Re: [netmod] Review comments for module-tags-02

Martin Bjorklund <mbj@tail-f.com> Wed, 17 October 2018 10:23 UTC

Return-Path: <mbj@tail-f.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 8CEAF12F1AB for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 03:23:57 -0700 (PDT)
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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 37wNqpa9aGLn for <netmod@ietfa.amsl.com>; Wed, 17 Oct 2018 03:23:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC512DD85 for <netmod@ietf.org>; Wed, 17 Oct 2018 03:23:54 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id BF6201AE0399; Wed, 17 Oct 2018 12:23:50 +0200 (CEST)
Date: Wed, 17 Oct 2018 12:23:50 +0200 (CEST)
Message-Id: <20181017.122350.1527287254258681037.mbj@tail-f.com>
To: chopps@chopps.org
Cc: rohitrranade@huawei.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <E9770126-7345-4E0F-B03A-08F22D2A867D@chopps.org>
References: <991B70D8B4112A4699D5C00DDBBF878A6BC65175@dggeml510-mbx.china.huawei.com> <E9770126-7345-4E0F-B03A-08F22D2A867D@chopps.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LPn2-SIYb8KOGwYF3NbSQykfuxY>
Subject: Re: [netmod] Review comments for module-tags-02
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: Wed, 17 Oct 2018 10:23:58 -0000

Christian Hopps <chopps@chopps.org> wrote:
> 
> 
> > On Oct 17, 2018, at 12:09 AM, Rohit R Ranade <rohitrranade@huawei.com>
> > wrote:
> > 
> > 1. In the desrciption of leaf-list tag
> >   "
> >   The operational view of this list will contain all
> >              user-configured tags as well as any predefined tags that
> >              have not been masked by the user using the masked-tag leaf
> >              list below.
> >   "
> >   ==> So the predefined tags, should be output as <default> origin in
> >   <operational> ?
> >   If so, I would suggest renaming them to "default" tags.
> 
> default has this in it's definition:
>  
>     "The default origin is only used when the configuration has not been
>      provided by any other source."
> 
> The predefined tags are being added due to the module definition or by
> the vendor implementing the module, and the user would be adding to
> this set (not replacing) when they configure tags (and thus the reason
> for the mask). So I think predefined tags should have "system"
> origin. We can add text to the document to clarify this if others
> agree.

I agree that the origin should be "system" for these tags.

> > 2. For "masked-tag", if the purpose is to only mask "predefined" tags,
> > why not rename
> > as masked-default-tag or masked-predefined-tag ?
> > Also if a tag say tag-1 (not predefined) is added to this list, and
> > tag-1 added to "tag", the tag-1
> > will still be output in <operational>, which may look confusing to the
> > user as the tag-1 will exist
> > in both "tag" and "masked-tag". Changing the "masked-tag" may help in
> > this case.
> 
> What's the compelling reason to make this more complex? Right now, the
> predefined tags are added, the configured tags are added, and then the
> masks are applied. KISS is the goal.

But this is not what the draft says.  The description of masked-tag
says that predefined tags are removed.

Keep it simple, but make sure the description is clear.  So maybe add
your 3 steps above to the draft, and remove the word "predefined" from
the description of masked-tag.


/martin


> > 3.  It is still not clear, what is the use-case where user wants to
> > "mask" a predefined tag..
> 
> The user is the ultimate arbiter over their network is the point. On
> example is a vendor adds a tag indicating the module belongs to a
> certain category of modules which would enable it's use in that users
> network, but for whatever reason the user does not agree.
> 
> > 4. What about already existing modules which donot define the tags,
> > should they be output in the
> >   "module-tags" list ? Or better to use "min-elements" for leaf-list
> >   "tags" ?
> 
> If they have no tags, there's no reason for them to be in the list,
> whether they come before or after the publication of this document (or
> after a device implements it). However, any client software is going
> to need to deal with no module entry, and also with an entry with no
> tags. I think it's better to stay away from adding restrictions that
> don't add real value, but do allow for software to "get it wrong".
> 
> > 5. I also agree with other reviewer's comment that this document must
> > standardize what a module-tag must look like.
> >   Currently it only standardizes a prefix, if the rest of the tag is not
> >   standardized a client has no way to parse
> >   this tag.
> >   Maybe we can say that a tag will contain 3 parts, 1st part is about
> >   organization, 2nd part is about the whether it is service / element,
> >   3rd part
> >   can be a sub-category of part-2.
> 
> There's a lot of prior art here in leaving this open to however people
> want to use the meta-data (see routing admin-tags, media tags, social
> media tags, etc).. The reservation of prefix space allows for future
> definition if that ends up being needed. Users are free to define
> whatever structure they want if any. This discussion in particular was
> carried out over routing admin tags in the IETF and not pre-defining
> structure/meaning was the end result and has worked out well.
> 
> Thanks,
> Chris.
> 
> >  
> > With Regards,
> > Rohit R
> > _______________________________________________
> > 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
>