On Mon, Aug 10, 2015 at 10:01 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On 10 Aug 2015, at 18:46, Andy Bierman <a...@yumaworks.com> wrote: > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > > > > On 10 Aug 2015, at 17:32, Andy Bierman <a...@yumaworks.com> wrote: > > > > > > > > > > > > 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. > > > > But that means, for example, that annotations cannot be defined via an > extension statement as in draft-ietf-netmod-yang-metadata. > > > > > > > > Which means these statements should be real instead of extensions. > > If the statements are defining data that is exchanged between > > peers in a standard protocol, then YANG extensions are not > > appropriate. > > I agree, and -03 is my preferred solution, too. > > This would allow "if-feature" to be used so attributes would not have to be mandatory. Andy > > > > > > > > > > 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. > > > > Well, in the past you supported the idea of introducing new XPath > functions through extensions, and it is exactly of this sort. > > > > > > I don't remember the details, but new XPath functions > > should be part of the language, not extensions. > > > > > > I’d also argue that current wording of 6020 allows a server implementing > “ietf-system” and “ietf-netconf-nacm” to ignore the nacm:* extensions and > make e.g. container “authentication” writeable by default in non-recovery > sessions. > > > > > > > > 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. > > > > > > > I didn’t ignore that problem, I just didn’t understand why “ephemeral” > (or any) extension needs to be refined. > > > > > > > > Because it is common for data is defined in a grouping without any > config-stmt > > (or ephemeral-stmt) and then add these in for each uses-stmt. > > OK, I see. > > Lada > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
