On Sat, Aug 15, 2015 at 10:23 AM, Randy Presuhn <
[email protected]> wrote:
> 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.
>
>
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
> -----Original Message-----
>
> From: Andy Bierman
>
> Sent: Aug 15, 2015 9:00 AM
>
> To: "Carey, Timothy (Timothy)"
>
> Cc: "[email protected]"
>
> 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 protected]> wrote:
> Lada,
>
>
>
> Yes sorry - I just saw that thread after I submitted mine.
>
>
>
> BR,
>
> Tim
>
> -----Original Message-----
>
> From: Ladislav Lhotka [mailto:[email protected]]
>
> Sent: Saturday, August 15, 2015 10:25 AM
>
> To: Carey, Timothy (Timothy)
>
> Cc: [email protected]
>
> 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 protected]> 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 protected]
>
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> --
>
> Ladislav Lhotka, CZ.NIC Labs
>
> PGP Key ID: E74E8C0C
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> 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
