Andy, The example we have is a module that we are standardizing that is augmenting another standards organization module (e.g., RFC 7223). We didn’t develop the module but we want to reuse the good work of other bodies as much as possible. So using sub-modules doesn’t seem feasible as the models are already published as a module.
These new modules are indeed standardized so the client and server know the specification and the ‘contract’ and the client interacts with the server knowing how to manage the server with this module name. Indeed we look at backward compatibility within the context of the module when we revise the module for the very reason you suggest. We don’t want to break old clients. I just don’t think that is valid for the first revision of a module. BR, Tim From: Andy Bierman [mailto:[email protected]] Sent: Saturday, August 15, 2015 12:37 PM To: Ladislav Lhotka Cc: Carey, Timothy (Timothy); [email protected] Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis On Sat, Aug 15, 2015 at 10:10 AM, Ladislav Lhotka <[email protected]<mailto:[email protected]>> wrote: > On 15 Aug 2015, at 18:00, Andy Bierman > <[email protected]<mailto:[email protected]>> wrote: > > Hi, > > If you are using mandatory nodes in augment, it is because you expect > that 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. Are you saying that a server isn’t required to implement modules that it advertises? Of course not. The server is allowed to implement the base module without the augmenting module. It is not required to advertise the augmenting module. A system working this way cannot just add a module later that breaks old clients. The RFC can hand-wave around this, but the tech-support team will still get calls if already deployed code stops working. I suggested a solution called YANG packages. If multiple YANG modules are required to be used together, then the current YANG conformance model is broken. There is no text in 6020(bis) supporting this theory. An augmenting module is an integral part of the data model as any other. > > It doesn't really matter that you are writing these illegal YANG modules > all 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 module > implemented on a server. Even if this were useful, the client will certainly > not support modules written after the client code was released. Such a client is unsafe because the modules that the client ignores may imply some important semantics. YANG modules are not perfectly isolated from each other, and a client may break things if it doesn’t understand the interactions. And again, I am not aware of any text in 6020 supporting such cherry-picking clients. There is no text that says if a base module is implemented, then some other modules that augment that module must also be implemented. It is not practical to re-implement a client app every time a new module is added. If you don't like how YANG conformance works then fix it. Just breaking old clients and expecting them to re-code constantly to keep up with every server release is not a solution. > > You should be using submodules (written all at once) if you want > to augment with mandatory nodes. In many use cases this is impossible - e.g. for interface types. There are no augments in the interface types module Lada > > Andy > Andy > > > > On Sat, Aug 15, 2015 at 8:39 AM, Carey, Timothy (Timothy) > <[email protected]<mailto:[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]<mailto:[email protected]>] > Sent: Saturday, August 15, 2015 10:25 AM > To: Carey, Timothy (Timothy) > Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[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
