Hi - I know netmod isn't object-oriented, but I think viewing this through the lens of conformance might be causing us to miss the conflicting requirements that lead the group to this impasse.
RFC 6020 effectively presents us with a way of defining instantiable classes, and augment functions as a rather limited way of defining instantiable subclasses. Usage has given us another requirement: the ability to define (or at least to designate as noninstantiable) abstract superclasses. I don't see how one can both with the current metamodel, such as it is. Randy -----Original Message----- From: Andy Bierman Sent: Aug 15, 2015 9:00 AM To: "Carey, Timothy (Timothy)" Cc: "[email protected]" Subject: Re: [netmod] Constraint on mandatory on nodes as part of augmentation in RFC6020bis Hi, If you are using mandatory nodes in augment, it is because you expectthat 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 modulesall 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 moduleimplemented on a server. Even if this were useful, the client will certainlynot support modules written after the client code was released. You should be using submodules (written all at once) if you wantto 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
