Re: [netmod] extensions and conformance

> On 10 Aug 2015, at 17:32, Andy Bierman <andy@yumaworks.com> wrote:
> 
> 
> 
> On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> 
> > On 10 Aug 2015, at 12:17, Andy Bierman <andy@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.

> 
> 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’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.

Lada

> 
> 
>  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 <lhotka@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