On Thu, Oct 3, 2019 at 8:31 AM Rob Wilton (rwilton) <[email protected]> wrote:
> Hi Chris, > > > -----Original Message----- > > From: Christian Hopps <[email protected]> > > Sent: 03 October 2019 16:16 > > To: Rob Wilton (rwilton) <[email protected]> > > Cc: Christian Hopps <[email protected]>; [email protected] > > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-module-tags-09.txt > > > > [resending to include list cc] > > > > > On Oct 3, 2019, at 5:45 AM, Rob Wilton (rwilton) <[email protected]> > > wrote: > > > > > > Hi Chris, > > > > > > As discussed offline, you have left out the "masked-tag" container in > > the "modules-tags-state" module. > > > > One might read this as an objection that was discussed offline, but I > > don't think you are objecting, you're just stating what happened, > correct? > > Correct, not objecting, although I might be about to 😉 > > Generally, I think that is what is available in "module-tags-state" should > be directly equivalent to what is available in the operational datastore > for servers that support NMDA. > > So, my previous comments were trying to align these two together. I.e. if > you think that "masked-tag" isn't needed in "module-tags-state" then I > think that there is the equivalent question of whether it should be > reported in <operational>. > > What is unusual in this case, is that you have some configuration that > removes items from another list. > > > > > > > For consistently, I wonder, whether there shouldn't also be a comment > in > > the "masked-tag" leaf-list in the main NMDA compatible module to indicate > > that "masked-tag" isn't reported in the operational state datastore > > because the information is combined into the "tag" leaf-list. > > > > Ok, color me confused. For NMDA, why wouldn't masked-tag show up in > > operational datastore? > > By default it would. > > IMO the non-NMDA state module should have the same structure as the NMDA version. Any configured masked-tag entries that are applied will appear in <operational> and also the non-NMDA version. Please don't start making all kinds of special cases in NMDA. If a configured value has an applied value, it is expected in both <operational> and the non-NMDA module for the <operational> contents. Andy > > > Isn't the operational datastore the union of the > > applied intended config (config true nodes) plus the config false nodes? > > Sort of yes. > > What is in <operational> is the "actual operational state in effect in the > system". For configurable items, this is often, but not necessarily, the > same as "applied intended config". > > > > > > Non-NMDA has no concept of "applied" (operational state of config true > > nodes), that is why masked-tags don't go in the module-tags-state > > container. The user can still read the configured masked-tag value on the > > normal non-deprecated module in the non-NMDA case. > > On balance, I'm not sure this was the right choice. I think that it might > be easier to include "masked-tags" in module-tags-state, and have it just > report the list of tags that have been masked. I.e. exactly the same > meaning as NMDA. > > Thanks, > Rob > > > > > > Thanks, > > Chris. > > > > > > > > Thanks, > > > Rob > > > > > >> -----Original Message----- > > >> From: netmod <[email protected]> On Behalf Of Christian Hopps > > >> Sent: 25 September 2019 17:19 > > >> To: [email protected] > > >> Subject: Re: [netmod] I-D Action: > > >> draft-ietf-netmod-module-tags-09.txt > > >> > > >> This adds the deprecated non-NMDA state module. > > >> > > >> Thanks, > > >> Chris. > > >> > > >>> On Sep 25, 2019, at 12:15 PM, [email protected] wrote: > > >>> > > >>> > > >>> A New Internet-Draft is available from the on-line Internet-Drafts > > >> directories. > > >>> This draft is a work item of the Network Modeling WG of the IETF. > > >>> > > >>> Title : YANG Module Tags > > >>> Authors : Christian Hopps > > >>> Lou Berger > > >>> Dean Bogdanovic > > >>> Filename : draft-ietf-netmod-module-tags-09.txt > > >>> Pages : 18 > > >>> Date : 2019-09-25 > > >>> > > >>> Abstract: > > >>> This document provides for the association of tags with YANG > modules. > > >>> The expectation is for such tags to be used to help classify and > > >>> organize modules. A method for defining, reading and writing a > > >>> modules tags is provided. Tags may be registered and assigned > > >>> during module definition; assigned by implementations; or > > >>> dynamically defined and set by users. This document also provides > > >>> guidance to future model writers; as such, this document updates > > RFC8407. > > >>> > > >>> > > >>> The IETF datatracker status page for this draft is: > > >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/ > > >>> > > >>> There are also htmlized versions available at: > > >>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-09 > > >>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags- > > >>> 09 > > >>> > > >>> A diff from the previous version is available at: > > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-09 > > >>> > > >>> > > >>> Please note that it may take a couple of minutes from the time of > > >>> submission until the htmlized version and diff are available at > > >> tools.ietf.org. > > >>> > > >>> Internet-Drafts are also available by anonymous FTP at: > > >>> ftp://ftp.ietf.org/internet-drafts/ > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> [email protected] > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >>> > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
