Subject: Re: [netmod] I-D Action: draft-ietf-netmod-module-tags-09.txt

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 3 Oct 2019 09:45:59 +0000

Hi Chris,

As discussed offline, you have left out the "masked-tag" container in the "modules-tags-state" module.

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.

Thanks,
Rob

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Christian Hopps
> Sent: 25 September 2019 17:19
> To: [email-masked]
> 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-masked] 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-masked]
> > https://www.ietf.org/mailman/listinfo/netmod
> >

---

From: Christian Hopps <[email-masked]>
Date: Thu, 3 Oct 2019 11:15:40 -0400

[resending to include list cc]

> On Oct 3, 2019, at 5:45 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Chris,
> 

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?

> 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 operationa…

Ok, color me confused. For NMDA, why wouldn't masked-tag show up in operational datastore? Isn't the operational datastore the union of the applied intended config (config true nodes) plus the config false nodes?

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.

Thanks,
Chris.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 3 Oct 2019 15:30:44 +0000

Hi Chris,

> From: Christian Hopps <[email-masked]>
> Sent: 03 October 2019 16:16
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; [email-masked]
> 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.

> 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

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

---

From: Christian Hopps <[email-masked]>
Date: Thu, 3 Oct 2019 11:59:17 -0400

> On Oct 3, 2019, at 11:30 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Chris,
> 

So is this how we're supposed to construct these deprecated state modules, just copy all config true and config false nodes into a new module and mark them all config false? If so fine. I will do that.

Thanks,
Chris.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Oct 2019 09:25:04 -0700

On Thu, Oct 3, 2019 at 8:59 AM Christian Hopps <[email-masked]> wrote:

> > 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 is this how we're supposed to construct these deprecated state modules,
> just copy all config true and config false nodes into a new module and mark
> them all config false? If so fine. I will do that.
>
>

IMO the deprecated state module only needs a config=false version of the
config=true NMDA nodes.
Since config=true validation statements are not allowed to reference
config=false nodes it should
always be possible to remove the config=false nodes from the deprecated
state module.

Otherwise the config=false nodes show up twice for non-NMDA clients
because they can
read the NMDA config=false nodes just fine.  (The NMDA transition strategy
is vague and
using the /yang-library tree to hide objects is too complicated, but that
is not in scope for module-tags.)

Thanks,
> Chris.
Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Oct 2019 15:09:13 -0700

On Thu, Oct 3, 2019 at 8:31 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

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

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

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 4 Oct 2019 08:53:23 +0000

From: Andy Bierman <[email-masked]>
Sent: 03 October 2019 23:09
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-module-tags-09.txt

On Thu, Oct 3, 2019 at 8:31 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chris,

> From: Christian Hopps <[email-masked]<mailto:[email-masked]>>
> To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
> Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > On Oct 3, 2019, at 5:45 AM, Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
> wrote:
> >
> > Hi Chris,
> >

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.

[RW]
I agree.

Keeping things consistent is likely to make life easier for both clients and servers because it means fewer special cases.

Thanks,
Rob

Andy

Sort of yes.

Thanks,
Rob

> >> From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Christian Hopps
> >> To: [email-masked]<mailto:[email-masked]>
> >>> On Sep 25, 2019, at 12:15 PM, [email-masked]<mailto:[email-masked]> wrote:
> >>>
> >>>
> >> tools.ietf.org<http://tools.ietf.org>.
> >>>
> >>> [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod