Andy Bierman <[email protected]> writes: > 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.
Sure, but that's the point of the concept that was introduced in RFC 7223: there will be a (large) number of modules for different interface types, all of them augmenting "ietf-interfaces". A server implementor will choose a collection of these modules depending on what interface types the device is expected to support. All these modules then become part of the data model and are advertised by the server. > > 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. That's a different problem. It is true that modules like "ietf-interfaces" or "ietf-routing" are pretty much useless without other modules augmenting it, and I think this has to be clear to every server implementor already now (otherwise our RFCs and I-Ds do a poor job). Packages would formalize this information, which would of course be useful, but it has nothing to do with mandatory nodes in augments: even with packages, it will be possible for a server to support "ietf-interfaces" with, e.g., "ietf-ethernet" in revision 1, and "ietf-ethernet" + "ieee-802.1q" in revision 2. The problem this thread is about is that "ieee-802.1q" might need some parameters to be mandatory, such as the VLAN tag or reference to the "base" physical interface. Without such parameters, the VLAN interface is incomplete and has to be rejected by the server, but the data model cannot express this condition because of the restriction on "augment" contents. > > > > >> >> 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. Backward compatibility is important but it mustn't be an absolute requirement. The client receives complete information about the server's data model. If it doesn't understand parts of it, it may be a problem or not, depending on what actions the client wants to perform. > > > > >> > >> > 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 > There are several examples in RFC 7223 that illustrate how "ietf-interfaces" is supposed to be augmented. Lada > >> >> 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 >> >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
