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

From: Rohit R Ranade <[email-masked]>
Date: Wed, 17 Oct 2018 04:09:53 +0000

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.

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.

3.  It is still not clear, what is the use-case where user wants to "mask" a predefined tag.

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

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.

With Regards,
Rohit R

---

From: Christian Hopps <[email-masked]>
Date: Wed, 17 Oct 2018 04:37:48 -0400

> On Oct 17, 2018, at 12:09 AM, Rohit R Ranade <[email-masked]> wrote:
> 

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.

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

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

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

>   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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Oct 2018 12:23:50 +0200 (CEST)

Christian Hopps <[email-masked]> wrote:
> 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.

> 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

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

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 17 Oct 2018 11:46:03 +0000

I think we need to define a subtree for non-NMDA clients to get the operational tags.

Reference:  https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
"   2.  Models that require immediate support for "in use" and "system
       created" information SHOULD be structured for NMDA.  A non-NMDA
       version of these models SHOULD also be published, using either an
       existing model or a model created either by hand or with suitable
       tools that support current modeling strategies.  Both the NMDA
       and the non-NMDA modules SHOULD be published in the same
       document, with NMDA modules in the document main body and the
       non-NMDA modules in a non-normative appendix.  The use of the
       non-NMDA model will allow temporary bridging of the time period
       until NMDA implementations are available."  

-----Original Message-----
From: Christian Hopps [mailto:[email-masked]] 
Sent: 17 October 2018 14:08
To: Rohit R Ranade <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [netmod] Review comments for module-tags-02

 

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

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Oct 2018 13:52:00 +0200

> I think we need to define a subtree for non-NMDA clients to get the

It is not much of a change for a _client_ to read a different
datastore hence I do not think this is needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 17 Oct 2018 12:22:39 +0000

If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then we will need this separate subtree to show the system defined tags.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 17 October 2018 17:22
To: Rohit R Ranade <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [netmod] Review comments for module-tags-02

> I think we need to define a subtree for non-NMDA clients to get the 

It is not much of a change for a _client_ to read a different datastore hence I do not think this is needed.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Oct 2018 14:47:41 +0200

Obviously, this is now a slightly different statement. There are NMDA
transition guidelines that have been discussed at length and finally
been integated into

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3

This section 4.23.3 says under case (a):

   Both the NMDA and the non-NMDA modules SHOULD
   be published in the same document, with NMDA modules in the document
   main body and the non-NMDA modules in a non-normative appendix.

In other words, you do not pollute a new NMDA module with non-NMDA
subtrees but instead you create an additional module that goes into an
appendix and is only relevant for transition purposes. I think Rob
created tools to generate such things. Section 4.23.3.1 also provides
some guidelines for creating temporary non NMDA modules.

/js

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 17 Oct 2018 13:13:06 +0000

Either defining a new module in an Appendix or a subtree, I am OK with either and both of us concur that the draft needs the changes.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 17 October 2018 18:18
To: Rohit R Ranade <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [netmod] Review comments for module-tags-02

Obviously, this is now a slightly different statement. There are NMDA transition guidelines that have been discussed at length and finally been integated into

In other words, you do not pollute a new NMDA module with non-NMDA subtrees but instead you create an additional module that goes into an appendix and is only relevant for transition purposes. I think Rob created tools to generate such things. Section 4.23.3.1 also provides some guidelines for creating temporary non NMDA modules.

/js

On Wed, Oct 17, 2018 at 12:22:39PM +0000, Rohit R Ranade wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Oct 2018 16:23:07 +0200

The WG needs to agree whether a -state module in the Appendix is
needed. I just commented on the proposal to add a subtree, which
violates the guidelines.

/js

---

From: Christian Hopps <[email-masked]>
Date: Wed, 17 Oct 2018 10:39:24 -0400

I'll chime in as an operator here, I do not feel there is a need to support non-NMDA implementations with this brand new work that won't be finished let alone start being used for another so many months (at best). There's nothing wrong with simply requiring NMDA for various modules going forward. Indeed I'd like more modules to require NMDA if only to add pressure to get it deployed by vendors.

Thanks,
Chris.

> On Oct 17, 2018, at 10:23 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 17 Oct 2018 19:39:51 +0200

Hi,

Adding  -state modules to all new drafts seems like unnecessary 
overhead. Even mentioning NMDA in a draft that has no logical 
relationship to NMDA also seems like unnecessary overhead.

Not a great set of alternatives. The positive thing is that vendors that 
do not have to worry about existing applications should really have no 
problem responding to the pressure.

Vladimir