On Sat, Aug 15, 2015 at 4:58 PM, Carey, Timothy (Timothy) < [email protected]> wrote:
> 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. > > > Implementations of RFC 7223 don't know about your new module. It is compatibility with that module that is the issue, not your new module. > BR, > > Tim > > Andy > > > *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]> 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
