On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On 10 Aug 2015, at 12:17, Andy Bierman <a...@yumaworks.com> wrote: > > > > Hi, > > > > I am strongly against changing the contract on extensions. > > They MAY be ignored by any YANG tool. Period. > > That means they are far from mandatory. > > They are little more than a keyword and a description clause. > > So do you prefer my proposed solution -02 or -03? > ** Solution Yxx-03 Make extensions optional. This means that extensions won't be allowed to change YANG language, NETCONF protocol, and validity of datastores and protocol messages. This is how we use extensions to tag YANG data models to drive automation tools. Your entire problem statement assumes that the consumer of the extension is a protocol (client and/or server). IMO this is really bad design to use statements for standards that are by definition external to the YANG language, as if they were part of the YANG language. This is just a hack and it usually doesn't work well. For example, when I pointed out that an extension for "ephemeral" could not be modified with a refine-stmt, you just changed the subject and ignored that problem. Andy > > > > There are not even any rules or help determining > > which extensions can appear as children of other > > extensions. That indicates that they are not > > real statements and not really part of YANG at all. > > > > There are some uses of extensions that fit the modular design, > > but not many. The NACM extensions only affect NACM. > > They have no impact whatsoever on any YANG statement. > > Yet even these statements should be real YANG statements. > > There is really no need to force implementation of NACM > > in order to utilize the concept of 'default-deny-all'. > > But full implementation of NACM is required to use these > > extensions. > > > > The descriptions of “default-deny-write” and “default-deny-all” describe > normative server behaviour. It is not even clear from 6020 text whether > server implementations can ignore these extensions or not and still use the > modules where the extensions are present. > > Lada > > > > > Andy > > > > > > On Mon, Aug 10, 2015 at 1:14 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > Hi, > > > > recent discussions show that 6020(bis) text about extensions isn't > > sufficiently clear about the scope and semantics of extensions. IMO this > > needs to be fixed and so I propose to add the following item to YANG 1.1 > > issue list. Comments and additional solutions are welcome. > > > > Lada > > > > ------------------------------------------------------------------------ > > * NEW :Yxx: clarify conformance wrt extensions > > > > ** Description > > > > YANG extensions as defined in RFC 6020 have no limits on scope – > > they can possibly modify YANG language, datastore semantics or even > > the NETCONF protocol. However, from the text in RFC 6020 it is > > unclear whether extensions appearing in YANG modules advertised by > > a server are mandatory to implement: "If a YANG compiler does not > > support a particular extension, which appears in a YANG module as > > an unknown-statement (see Section 12), the entire unknown-statement > > MAY be ignored by the compiler." > > > > ** Solution Yxx-01 > > > > Extensions appearing in the server's model are an integral part of > > the server-client contract. That is, the server MUST implement > > them, and the client SHOULD terminate the session if it doesn't > > implement any of the extensions. > > > > ** Solution Yxx-02 > > > > Develop a mechanism for negotiating extensions. > > > > ** Solution Yxx-03 > > > > Make extensions optional. This means that extensions won't be > > allowed to change YANG language, NETCONF protocol, and validity of > > datastores and protocol messages. > > ------------------------------------------------------------------------ > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
