Rohit R Ranade <[email protected]> writes:
Hi, While looking at Section 3.1, it looks like this document does not mandate that all IETF drafts in future MUST have atleast one module-tag. Is this correct ? Or whether it is better that future IETF draft MUST/SHOULD have at least one IETF tag ?
Correct, we aren't mandating tag use.
Consider modules like "ietf-yang-types" and similar which provide common definitions, what will be the tags for such modules ? Editorial: ------------ Section 4.1 "If the module definition is IETF standards track, the tags MUST also be Section 2.1. " ==> s/ MUST also be Section 2.1. / MUST also adhere to Section 2.1./ ?
I corrected this based on the GenART review (the odd text was a tool use error on my part). "... If the module is defined in an IETF standards track document, the tags MUST be IETF Standard Tags (2.1). ..." I've been waiting to publish corrections until after the GenART review is done. Thanks, Chris.
With Regards, Rohit -----Original Message----- From: Rohit R Ranade Sent: 21 February 2019 14:14 To: 'Christian Hopps' <[email protected]> Cc: Joel Jaeggli <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04 Hi, Please find inline. -----Original Message----- From: Christian Hopps [mailto:[email protected]] Sent: 21 February 2019 13:54 To: Rohit R Ranade <[email protected]> Cc: Christian Hopps <[email protected]>; Joel Jaeggli <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04On Feb 20, 2019, at 10:40 PM, Rohit R Ranade <[email protected]> wrote: Hi Christian, 2 points are missing from the IANA registry, "Updates to the IETF XML Registry" and "Updates to the YANG Module Names Registry", you can refer to RFC 8342 section 8 for registering the new module and namespace.Will add, thanks.Also w.r.t "ietf:", whether we can make it "sdo:" and ask ietf modules to start their tags as "sdo:ietf:xxxx" , because all the other SDO will need to register their organization prefixes once with IANA. This will also keep it at the same level where each vendor will also define his tags as "vendor:vendor-name:xxxxx" etc.Since this isn't fixing something that's broken, and in fact is going against what was talked about and agreed to in the WG during the document development time, it's not an appropriate change to consider at this very late stage in the process. [Rohit R Ranade] OK, If the WG has decided then I concede on this point. Thanks, Chris.With Regards, Rohit -----Original Message----- From: Christian Hopps [mailto:[email protected]] Sent: 18 February 2019 14:57 To: Rohit R Ranade <[email protected]> Cc: Christian Hopps <[email protected]>; Joel Jaeggli <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04 Rohit R Ranade <[email protected]> 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:[email protected]] Sent: 16 February 2019 00:27 To: Rohit R Ranade <[email protected]> Cc: Christian Hopps <[email protected]>; Joel Jaeggli <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04On Feb 13, 2019, at 6:04 AM, Rohit R Ranade <[email protected]> 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"Done3. 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 RFC8342Adopted 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:[email protected]] On Behalf Of Joel Jaeggli Sent: 13 February 2019 05:20 To: [email protected] Cc: [email protected]; Joel Jaeggli <[email protected]>; [email protected]; [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
