Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps <[e-mail]>]

Rohit R Ranade <[e-mail]> writes:

> Hi,
>
> Thank you for accepting the comments. Few more comments from my side.
>
> Technical:
> 1. Section 8.1, " could allocate a top level prefix ", I think there is no concept of top-level prefix now. I think this is a remnant of the versions posted earlier where you had examples of multiple prefixes in a tag. Can be removed now I think.

Indeed! I'll remove "top level", as there are no levels.

> 2. Why should the prefix contain ietf: , vendor:, user: ?  I think the second part of the prefix is more important for classification because most of the vendors / sdo already define their own prefixes for their module-name based on RFC7950 guideline in Section 5.1. By adding the prefix, I feel it will reduce the re-usability by other SDO / vendors.

Well the second part of the tag is the tag itself, the prefix is simply there to avoid collision between the module authors in various SDOs, the module implementers, and the module users.

> 3. Consider we have defined a module example-bgp which is similar to ietf-bgp.
> If we need to add tags to example-bgp, then we need to define new "vendor:" prefixes for this even if it uses some IETF protocols ?

"ietf:" tags are allocated with IETF documents which is what the registry policy "IETF Review" indicates.

However, this is an allocation policy not a USE policy. As module designer you get to pick whatever tags you think apply (which is what section 4.1 says).

> I think we need to add more clarity in this document as to when the "ietf:" prefix can be used by a module ? Whether a vendor module can/cannot use standard tags ?
> Consider a module which has some part of vendor and some part of IETF protocol , whether vendor can use "ietf:" tags then ?
> I suggest adding one more example in this document which may indicate/clarify your stand regarding this point.

Again, if you are creating your own module then you can choose whatever tags you want to add to it (section 4.1).

I've changed the headings under section 4 to:

  4.1 "Module Definition Tagging"
  4.2 "Implementation Tagging"
  4.3 "User Tagging"

and split 4.1 into 2 paragraphs (at "If the") to better separate the IETF part away from the anyone part.

> 4. By defining a module tag as an extension, there is no way to validate this extension's argument during YANG compilation (even though a pattern is defined). The existing YANG compiler tools will be forced to do hard-coding for this. Whether there should be a note to Yang Compiler Developers in this document for clarity ?

Well the WG wanted the extension, originally it was just part of a comment in the module definition. I think yang compiler developers (a very small group compared to the other users of this document) can probably figure this out without extra text. :)

> Please not that all these points originated in my mind, by thinking as to how I will use these tags. On the whole, I like the idea and thank you and the co-authors for documenting this.

Thanks!
Chris.

>
> With Regards,
> Rohit R
>
> -----Original Message-----
> From: Christian Hopps [mailto:[e-mail]]
> Sent: 16 February 2019 00:27
> To: Rohit R Ranade <[e-mail]>
> Cc: Christian Hopps <[e-mail]>; Joel Jaeggli <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04
>
>
>
>> On Feb 13, 2019, at 6:04 AM, Rohit R Ranade <[e-mail]> wrote:
>>
>> Editorial Comments:
>> 1.  Section 1, refers to RFC6020 for Yang Module, but since this
>> document uses Yang Version 1.1, I feel it should refer to RFC7950 2.  Section 4.3, " removed with using normal configuration", can use "removed by using normal configuration"
>
> Done
>
>> 3.  Description of statement "leaf-list tag", in the Step 1), " System added tags are added" can be replaced with "tags of 'system' origin are added" as it associates System with "system" origin in a better way.
>
> Adopted with modification. Trying to keep things more readable but still well specified.
>
>            1) System tags (i.e., tags of 'system' origin) are added.
>            2) User configured tags (i.e., tags of 'intended' origin)
>            are added.
>            3) Any tag that is equal to a masked-tag is removed.";
>
>> 4.  Description of statement "leaf-list tag", " The operational view of this list", can be replaced with "The applied configuration of this list", as it uses is a well-known term from RFC 8342.
>
> NEW:
>            The 'operational' state [RFC8342] view of this list is
>            constructed using the following steps:
>
>
>> 5.  Description of statement "leaf-list tag", " User configured tags"
>> can be replaced with "tags of 'intended' origin" as it uses a
>> well-known NMDA term from RFC8342
>
> Adopted with mod, See above.
>
>> Technical:
>> 1. Section 4.2, "These tags may be standard or vendor specific tags".  Does this statement exclude other tags from being added by implementations ? If it does not exclude, I feel this statement can be removed.
>
> Going to leave this, standard tags and vendor tags are tags with a specific prefix.
>
>> 2. In the description of Yang statement "leaf-list tag", is there any reason why System tags should be added first and then User configured tags ? Not clear.
>
> This is just the way it worked out on the mailing list. Doesn't hurt to specify an order.
>
>> 3. Description of statement "leaf-list masked-tag", " This user can remove (mask) tags", I think we need to clarify that it will not "apply" the tags which have been configured as "masked-tags", because they are not "removed" from any configuration datastore.
>> The tags which have been masked will be present in <intended>, but will not be present in <operational>.
>> Suggested description
>> " The list of tags that will not be applied to this module. By adding
>> tags to this list, the user can prevent such tags from being applied.
>> It is not an error to add tags to this list that are not associated
>> with the module."
>
> I'm not sure about making these changes. I think the current text (with the modification below) is pretty clear in what is meant, and delving so deeply into NMDA gets distracting, and could in fact end up being wrong (e.g., I think of tags being associated with a module not applied to them).
>
>  I did make the change to the enumerated list to show what is meant by "System" and "User", and in the spirit of your suggestion, I did change it to be more specific about operational state datastore.
>
>           "The list of tags that should not be associated with this
>            module. The user can remove (mask) tags from the
>            operational state datastore [RFC8342] by adding them to
>            this list. It is not an error to add tags to this list
>            that are not associated with the module, but they have no
>            operational effect.";
>
> Thanks for the review!
>
> Chris.
>
>
>>
>>
>> With Regards,
>> Rohit R
>>
>>
>> -----Original Message-----
>> From: netmod [mailto:[e-mail]] On Behalf Of Joel
>> Jaeggli
>> Sent: 13 February 2019 05:20
>> To: [e-mail]
>> Cc: [e-mail]; Joel Jaeggli <[e-mail]>;
>> [e-mail]; [e-mail]
>> Subject: [netmod] Publication has been requested for
>> draft-ietf-netmod-module-tags-04
>>
>> Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 as Proposed Standard on behalf of the NETMOD working group.
>>
>> Please verify the document's state at
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>