> On 15 Aug 2015, at 18:00, Andy Bierman <[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? 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. > > 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. Lada > > 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 > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
