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.
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. You should be using submodules (written all at once) if you want to 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
