Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

From: Randy Presuhn <[email-masked]>
Date: Sat, 15 Aug 2015 10:23:19 -0700 (GMT-07:00)

Hi -

I know netmod isn't object-oriented, but I think viewing
this through the lens of conformance might be causing us
to miss the conflicting requirements that lead the group
to this impasse.

RFC 6020 effectively presents us with a way of defining
instantiable classes, and augment functions as a rather
limited way of defining instantiable subclasses.  Usage
has given us another requirement: the ability to define
(or at least to designate as noninstantiable) abstract
superclasses.

I don't see how one can both with the current metamodel,
such as it is.

Randy
-----Original Message-----

From: Andy Bierman 

Sent: Aug 15, 2015 9:00 AM

To: "Carey, Timothy (Timothy)" 

Cc: "[email-masked]" 

Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

Hi,
If you are using mandatory nodes in augment, it is because you expectthat all clients will know and implement both modules.However YANG has no way to require that.A server is NEVER required to implement the augmenting module.
It doesn't really matter that you are writing these illegal YANG modulesall at once. A server is not required to implement them all at once,or all of them ever.
It is rather naive to think that the client must understand every YANG moduleimplemented on a server.  Even if this were useful, the client will certainlynot support modules written after the client code was released.
You should be using submodules (written all at once) if you wantto augment with mandatory nodes.
Andy

On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) <[email-masked]> wrote:
Lada,

Yes sorry - I just saw that thread after I submitted mine.

BR,

Tim

-----Original Message-----

From: Ladislav Lhotka [mailto:[email-masked]]

Sent: Saturday, August 15, 2015 10:25 AM

To: Carey, Timothy (Timothy)

Cc: [email-masked]

Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis

> On 15 Aug 2015, at 16:50, Carey, Timothy (Timothy) <[email-masked]> wrote:

> Team,

> Section 7.17 The augment statement has verbiage If the target node is

> in another module, then nodes added by the augmentation MUST NOT be

> mandatory nodes (see Section 3.1).

> We are seeing situations where this constraint is invalid – Situations where a standard builds on another standard and makes parts of the new standard mandatory.

> It seems this was an issue in the past where the decision was to get around this statement with a presence container.

> Since 6020bis is in progress – would it be possible to simply remove this phrase and allow mandatory nodes as part of the augmentation so we don’t have to have this artificial workaround?

This is exactly what’s currently being discussed in this thread:

https://mailarchive.ietf.org/arch/search/?email_list=netmod&gbt=1&index=ES2ogm1wabzZVIIBlrRor0fn3rk

Lada

> Thanks,

> Tim

> _______________________________________________

> netmod mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/netmod

--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C

_______________________________________________

netmod mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Sat, 15 Aug 2015 10:55:01 -0700

> I don't see how one can both with the current metamodel,
I have been trying to change the meta-model (with YANG packages).
But that does not fix the problem here -- the notion of what is mandatory
for a given data structure can change over time.  Yet YANG absolutely
does not allow that to happen.  It doesn't matter whether 1 module,
2 modules, or submodules are used.  All mandatory data must be defined
in the first release.

SNMP never had this problem because a client can just ignore new
monitoring data it receives.  A NETCONF client cannot create or
replace configuration data that has unknown mandatory nodes.

In your analogy, there is an assumed super-class, and the mandatory
augments is creating a new sub-class.  The problem is the data
is all mixed together so a client using the old derived class needs
to be insulated from the new derived class (w/ new mandatory nodes).

The problem is specifying the rules for insulating the old client.
One design pattern we have come up with assumes that the
old client does not know about new identityref values, so it
won't try to create or replace an entry using a new identity.

   augment /foo:bar {
      when "/foo:bar[foo:type='example:new-identity']";
      leaf maybe-ok {
          mandatory true;
          type string;
      }
  }

It would be OK with me if this was allowed in YANG.
Leave it to Martin to write the text ;-)

Randy

Andy

> If you are using mandatory nodes in augment, it is because you expectthat
> all clients will know and implement both modules.However YANG has no way to
> require that.A server is NEVER required to implement the augmenting module.
> It doesn't really matter that you are writing these illegal YANG
> modulesall at once. A server is not required to implement them all at
> once,or all of them ever.
> It is rather naive to think that the client must understand every YANG
> moduleimplemented on a server.  Even if this were useful, the client will
> certainlynot support modules written after the client code was released.
> > We are seeing situations where this constraint is invalid – Situations
> where a standard builds on another standard and makes parts of the new
> standard mandatory.
>
> >
>
> > It seems this was an issue in the past where the decision was to get
> around this statement with a presence container.
>
> >
>
> > Since 6020bis is in progress – would it be possible to simply remove
> this phrase and allow mandatory nodes as part of the augmentation so we
> don’t have to have this artificial workaround?
>
>
>