Subject: Re: [netmod] 6020bis extensions

From: Randy Presuhn <[email-masked]>
Date: Sat, 17 Oct 2015 19:49:06 -0700 (GMT-07:00)

Hi -

> From: Andy Bierman
> Sent: Oct 17, 2015 10:42 AM
...
> Subject: Re: [netmod] 6020bis extensions
...

Andy Proposed:

>    If a YANG parser does not support a particular extension, which
>    appears in a YANG module as an unknown-statement (see Section 14),
>    the entire unknown-statement MAY be ignored by the parser. Note that
>    this only applies to a generic YANG parser. A tool which is required
>    to implement the particular extension MUST NOT ignore such an
>    unknown-statement.

I'd suggest a slightly different wording:

  The processing of extensions depends on whether support for those
  extensions is claimed for a given YANG parser or the tool set in
  which it is embedded.  An unsupported extension, appearing in a
  YANG module as an unknown-statement (see Section 14) MAY be
  ignored in its entirety.  Any supported extension MUST be processed
  in accordance with the specification governing that extension.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 18 Oct 2015 10:10:04 +0200

> On 18 Oct 2015, at 04:49, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 
>> From: Andy Bierman

I like this text.

Do we also want to restrict semantics of extensions? If an extension changes YANG validity or datastore semantics, then a tool or protocol implementation that doesn't support that extension may not be able to correctly interpret instance data, or may outright break down.

In order to be able to support annotations in instance data, it is IMO necessary to define the concept of annotations directly in the YANG spec. A similar approach as for YANG extensions could perhaps be used for annotations:

The processing of annotations depends on whether support for those annotations is claimed for a given protocol or tool set. An unsupported annotation appearing in instance data or protocol messages MAY be ignored. Any supported annotation MUST be processed in accordance with the specification governing that annotation.

Lada

> 
> Randy
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Oct 2015 10:31:58 +0200

>   in accordance with the specification governing that extension.

I am not happy with either of these. It is important for me to state
that the semantics associated with an extension statement apply,
irrespective of the tool being used to implement a module. You can't
simply ignore nacm:default-deny-write just because your tool skipped
over this extension statement. So what about this:

   If a tool does not support a particular extension, which appears in
   a YANG module as an unknown-statement (see Section 14), the entire
   unknown-statement MAY be ignored by the tool. Irrespective of this,
   the semantics associated with an extension MUST be implemented
   whenever an extension statement appears in a YANG module.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Oct 2015 01:50:12 -0700

>    whenever an extension statement appears in a YANG module.

I like Randy's text.  I don't really think any text is needed,
because the differences between "conformance to YANG"
and "conformance to a module written in YANG" are quite clear to me.
There is no way that all tools have to support some vendor extension
that is intended for 1 proprietary tool.

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Oct 2015 10:53:31 +0200

> that is intended for 1 proprietary tool.

I dislike Randy's text since it essentially says you can ignore any
extensions such as nacm:default-deny-write - all you have to claim is
that your tool does not support it.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 18 Oct 2015 14:17:46 +0200 (CEST)

> that your tool does not support it.

I think it *is* ok to ignore this statement for a server that doesn't
implement NACM.  I think Randy's text is fine.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Oct 2015 14:52:29 +0200

> implement NACM.  I think Randy's text is fine.

I disagree with the idea that extensions can be ignored arbitrarily
just because a tool did skip over them. I thought we agreed that
nacm:default-deny-write can't be ignored (if you implement NACM).  I
actually think it is up to the extension to define when and how it
applies. The definition of nacm:default-deny-write actually does say
when it applies.

I could copy the text of the nacm:default-deny-write description
verbatim into the description of every object marked with
nacm:default-deny-write. Using an extension is just a shorthand for
this (with the added bonus that it is machine readable for tools). I
do not think such an extension can be arbitrarily ignored just because
a certain tool skipped over it.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 18 Oct 2015 15:07:22 +0200

> On 18 Oct 2015, at 10:53, Juergen Schoenwaelder <[email-masked]> wrote:
> 

It is the role of RFC 6536 to make sure the extension is supported where necessary. On the other hand, other applications such as translation to DSDL schemas have nothing to do with NACM, so they can ignore the extension.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Oct 2015 15:28:06 +0200

> It is the role of RFC 6536 to make sure the extension is supported where necessary. On the other hand, other applications such as translation to DSDL schemas have nothing to do with NACM, so they c…

I am talking about implementation of data models. You all seem to be
thinking about tools only or some intermediate formats. DSDL likely
ignores descriptions - all fine with me. But an implementation of a
data model I think is not allowed to simply ignore extensions (as it
is not allowed to simply ignore descriptions).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 18 Oct 2015 16:28:17 +0200

> On 18 Oct 2015, at 15:28, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Then you have to define what "implementation of a data model" means. If it is only NETCONF server or client software, then I think it is still the business of RFC 6536 to specify the semantics of that extension and address all interoperability issues.

On the other hand, some extensions may be intended for use outside the NETCONF protocol.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 18 Oct 2015 08:35:27 -0700

> implement NACM.  I think Randy's text is fine.
+1

Here is a concrete example -- the 'secret' leaf in the ietf-system module:
http://www.netconfcentral.org/modules/ietf-system/2014-08-06#shared-secret.564

This is tagged as "nacm:default-deny-all".

Does this mean that if an implementation supports the ietf-system "secret"
leaf,
it MUST also include an implementation of NACM?

If yes, then Juergen is right.
If no, then Randy's text is fine.

But read the definition of "default-deny-all" carefully:
http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#default-deny-all.74

Note the line:

       If present, and the NACM module is enabled (i.e.,
       /nacm/enable-nacm object equals 'true'),

Is the NACM module "enabled" leaf set to true in a server that does
not implement NACM at all?  I would say no.

Note also that the extension does not define any behavior outside
of NACM processing.  It is not intended for every tool.
It is only intended for an implementation of NACM.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 18 Oct 2015 20:54:02 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> nacm:default-deny-write can't be ignored (if you implement NACM).
                                            ^^^^^^^^^^^^^^^^^^^^^

Absolutely!  It seems we agree on the idea, but not the words to
describe this.

> I actually think it is up to the extension to define when and how it

Agreed.

/martin