Re: [netmod] system DS polluting intended and operational

["maqiufang (A)" <[e-mail]>]

Hi, Jason,
Please see my reply inline.

-----Original Message-----
From: netmod [mailto:[e-mail]] On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: Monday, January 10, 2022 11:14 PM
To: Juergen Schoenwaelder <[e-mail]>
Cc: maqiufang (A) <maqiufang1=[e-mail]>; [e-mail]
Subject: Re: [netmod] system DS polluting intended and operational

Please see inline.

> -----Original Message-----
> From: Jürgen Schönwälder <[e-mail]>
> Sent: Thursday, December 9, 2021 1:19 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> Cc: maqiufang (A) <maqiufang1=[e-mail]>;
> [e-mail]
> Subject: Re: [netmod] system DS polluting intended and operational
> 
> On Thu, Dec 09, 2021 at 05:51:48PM +0000, Sterne, Jason (Nokia - 
> CA/Ottawa)
> wrote:
> > I wonder if having all the system config appear in intended and 
> > operational
> may be annoying. We didn't want to pollute running with 100s/1000s of 
> lines of unreferenced system config. So maybe putting all that in 
> intended & operational is also ugly ?
> >
> 
> The applied config, part of operational, is the config that is 
> actually used by the device. RFC 8342 has the details.

[>>JTS: ] RFC 8342 (rightly) leaves a lot of grey zone around what is considered used/active and what an implementation is allowed to return in <operational>.  But I'm also concerned about polluting intended.
[Qiufang Ma] I never think that all the system configuration will appear in <operational>. E.g., I don’t think inactive-until-referenced( which is defined in https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-00.txt#section-2.3)  system configuration will present in <operational> before it’s referenced.
The presence of system configuration in <operational> only dependents on whether it plays a role in current operational functionality of the device. Going against the definition of <operational> is not the intention.
IMHO there is no such thing as "pollute <operational>/<intended>", if a particular system-defined node is actually in use, it should be present in <operational>, otherwise it is not.
As defined in  NMDA, <intended> holds the configuration that the device attempts to apply. I think we all agree that referenced system configuration should appear in <intended>. 
But unreferenced system configuration(including expansion of system-defined template) is also what is intended to be used by the device and should be subject to validation. Once it is applied successfully, it will appear in <operational>.

> 
> > We should have *some* way that a client can retrieve system
> configuration though.
> >
> > Some potential options (without system flowing 100% of its contents 
> > into
> intended):
> > a) <system> DS that can be read (but doesn't flow into intended or
> operational)
> > b) a "with-system" extension (like "with-defaults"). Returns a merge 
> > of
> running+system (or candidate+system, or intended+system).
> 
> You want to rewrite RFC 8342?

[>>JTS: ] I think we're already discussing potential changes to "system" config in this draft (i.e. having system config flow into intended instead of operational). Maybe we won't do that in the end, but while we're discussing it I wanted to raise other options for consideration to avoid the potential pollution.
[Qiufang Ma] Happy to discuss other options without breaking the definition of <operational>/<intended>.:-)

> 
> > Maybe we'd also want (or maybe want instead) is a way to see
> *referenced* system config (either on its own, or merged with another DS).
> 
> The 'referenced system config' has to be in running since otherwise it 
> can't be referenced.

[>>JTS: ] That's a big part of the debate going on around this draft. I'm leaning the same way as you on this point (for system config), but there doesn't seem to be agreement in the working group. Having the referenced config (at least the list key) explicitly configured by the user in running is a solution I like for this system config problem, but I don't see how we'll handle config templates if running must be valid.  (we should continue that debate on the thread "Must offline-validation of <running> alone be valid?" though).
[Qiufang Ma] On the heavy debate on "MUST offline-validation of <running> alone be valid", the authors are trying to make a compromise to define that all the referenced system configuration MUST be present in <running> and allow the system to auto-populate referenced system configuration into <running> if the client isn’t willing to explicitly configure by themselves.
But I also agree with you that, even we define that the referenced system configuration should be in <running>, the problem may still exist if the validation against the configuration dependents on the template expansion (to populate mandatory fields, satisfy constraints on leafref or when/must statement, etc).
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod