On Sat, Aug 15, 2015 at 10:10 AM, Ladislav Lhotka <[email protected]> wrote:
> > > 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? > 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]> 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
