Subject: [netmod] 6020bis extensions

From: David Reid <[email-masked]>
Date: Fri, 09 Oct 2015 17:09:30 -0400

section 6.3.1 states:

   If a YANG compiler 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 compiler.

   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
   even in this case the semantics associated with the extension still 
   apply (as if they were part of a description statement).

I assume the repetitive wording is not intentional.

-David Reid

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Oct 2015 10:15:30 +0200 (CEST)

> I assume the repetitive wording is not intentional.

Right; the first paragraph should be removed.  Thanks for spotting
this!

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Oct 2015 11:45:30 +0200

David Reid <[email-masked]> writes:

>    the entire unknown-statement MAY be ignored by the parser.  Note

Implications of this statement are still not clear to me. Let's say some
protocol introduces an extension that is critical for that
protocol. Does the above sentence mean that an implementation of that
protocol MAY ignore the extension if it happens to use a parser that
doesn't support it?

Lada

>    that even in this case the semantics associated with the extension
>    still apply (as if they were part of a description statement).
>
> _______________________________________________
> 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: Tue, 13 Oct 2015 12:19:35 +0200

> >    still apply (as if they were part of a description statement).

Did you read the following sentence:

   [...] Note that

I think it answers your question with a 'no'.

/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: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Oct 2015 12:28:39 +0200 (CEST)

>    apply (as if they were part of a description statement).

But also note that the semantics associated with the extension can
define a protocol negotiation mechanism that triggers the protocol
behavior only when both peers agree it should be triggered.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Oct 2015 12:30:58 +0200

> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Well, if the parser ignores the extension statement, then the application has no way to find out that the extension is present to be able to apply its semantics.

> I think it answers your question with a 'no'.

Specifying behaviour of a YANG parser using 2119 keywords YANG parser doesn't make much sense to me, because it all depends on the purpose of the application that uses the parser.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Oct 2015 12:42:46 +0200

> Well, if the parser ignores the extension statement, then the application has no way to find out that the extension is present to be able to apply its semantics.

Description statements have always to be taken into account.

> Specifying behaviour of a YANG parser using 2119 keywords YANG parser doesn't make much sense to me, because it all depends on the purpose of the application that uses the parser.

I do not get your point. The text says a parser may skip over an
extension it does not know how to process and it says the semantics
still apply as if they were part of a description statement. What
is the problem with this?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Oct 2015 14:40:50 +0200

> On 13 Oct 2015, at 12:42, Juergen Schoenwaelder <[email-masked]> wrote:
> 

This is a different thing. Such a description would be a substatement to the "extension" (built-in) statement that defines the extension. In order to apply the semantics in appropriate places, an application must see where the extension statement is actually *used*. This is only possible if the underlying parser provides this information. 

> is the problem with this?

If a protocol requires an extension to be honoured, then there is no excuse for the parser to ignore it. But the sentence I am objecting to says "MAY ignore" without any qualification.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Oct 2015 09:19:45 -0700

On Tue, Oct 13, 2015 at 5:40 AM, Ladislav Lhotka <[email-masked]> wrote:

>
> > On 13 Oct 2015, at 12:42, Juergen Schoenwaelder <
> [email-masked]> wrote:
> >
> >>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder <
> [email-masked]> wrote:
> >>>
> >> Well, if the parser ignores the extension statement, then the
> application has no way to find out that the extension is present to be able
> to apply its semantics.
> >>
> >
> This is a different thing. Such a description would be a substatement to
> the "extension" (built-in) statement that defines the extension. In order
> to apply the semantics in appropriate places, an application must see where
> the extension statement is actually *used*. This is only possible if the
> underlying parser provides this information.
>
> >
> >> Specifying behaviour of a YANG parser using 2119 keywords YANG parser
> doesn't make much sense to me, because it all depends on the purpose of the
> application that uses the parser.
> >>
> >
> If a protocol requires an extension to be honoured, then there is no
> excuse for the parser to ignore it. But the sentence I am objecting to says
> "MAY ignore" without any qualification.
>
>
I do not want to change YANG wrt/ MAY skip over.
We have been over this many times.

Conformance to YANG for the extension: NONE
This includes syntax and semantics.  It makes no sense at all (Lada is
right)
to say the extension semantics apply.  They only apply if the tool supports
the extension.  Conformance to the extension is a different matter.

A generic YANG tool that is NOT claiming conformance to a particular
external language statement can completely ignore that statement.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Oct 2015 18:42:09 +0200

> On 13 Oct 2015, at 18:19, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> This includes syntax and semantics.  It makes no sense at all (Lada is right)

Right, but this is something very different! The current formulation in 6020bis (a parser MAY ignore) effectively undermines the possibility to specify strict conformance rules wrt a certain extension in other documents.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Oct 2015 09:53:47 -0700

On Tue, Oct 13, 2015 at 9:42 AM, Ladislav Lhotka <[email-masked]> wrote:

> Right, but this is something very different! The current formulation in
> 6020bis (a parser MAY ignore) effectively undermines the possibility to
> specify strict conformance rules wrt a certain extension in other documents.
>
>

Good.

IMO external statements are not part of YANG.

External statements should not be used in a way that requires
interoperability between 2 or more entities.  It should be completely
out of scope wrt/ YANG conformance.

I strongly object to changing this part of YANG.
It is critical that conformance to YANG does not include any
external statement semantics at all.

A server MUST be able to parse all the tokens in a YANG module.
That is all that is required for external statements.  Since YANG extensions
MUST NOT alter the syntax and semantics of real
YANG statements, a tool that only supports the official YANG language
statements can safely ignore all external statements..

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Oct 2015 19:13:38 +0200

> On 13 Oct 2015, at 18:53, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

If YANG conformance means "Is this a valid YANG data model or not?", then I think there is no ambiguity in 6020bis. IMO, the question is whether management protocols or other applications using YANG may define extensions with specific conformance rules, such as "Any implementation of protocol X MUST support extension Y." Other software that doesn't implement protocol X is then free to ignore extension Y, of course.

The YANG spec should IMO say that conformance wrt extensions is out of scope.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Oct 2015 00:34:41 +0200

On Tue, Oct 13, 2015 at 09:19:45AM -0700, Andy Bierman wrote:
>
> Conformance to YANG for the extension: NONE This includes syntax and
> semantics.  It makes no sense at all (Lada is right) to say the
> extension semantics apply.  They only apply if the tool supports the
> extension.  Conformance to the extension is a different matter.

I would hope that a server supporting NACM implements the behaviour of
nacm:default-deny-write when nodes are tagged with this extension.
Sure, a YANG parser is allowed to skip over nacm:default-deny-write
but if nacm:default-deny-write is used for a certain node, I think we
want the server to implement the semantics implied by
nacm:default-deny-write regardless which tool the developer used.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 15 Oct 2015 19:19:14 -0700

> nacm:default-deny-write regardless which tool the developer used.
I do not agree.
The semantics for this YANG extension only apply to NACM.
Of course an implementation of NACM cannot ignore this extension.

The extensions says what to do in NACM if the tag is found.
(As it should).  It does not define any behavior outside of NACM.
No other tool except a NETCONF server implementation
of NACM has any conformance requirement to implement this extension.

/js

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Oct 2015 08:14:32 +0200 (CEST)

> Of course an implementation of NACM cannot ignore this extension.

+1

So the question is if we need to add/change any text in 6020bis?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Oct 2015 09:25:43 +0200

> of NACM has any conformance requirement to implement this extension.

I am confused, perhaps we talk past each other. If a server implements
NACM and some data model X contains

	leaf foo {
	     type string;
	     nacm:default-deny-write;
	}

does this not mean that the nacm:default-deny-write semantics must be
implemented for the foo leaf regardless whether the developer's tool
is able to parse nacm:default-deny-write or skips over it?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Oct 2015 10:43:26 +0200

> So the question is if we need to add/change any text in 6020bis?

IMO, two things:

1. Clarify the text about parser/compiler behaviour - or remove it.

2. State that conformance with respect to extensions is outside the
   scope of YANG spec.

As for #1, I think parser behaviour is totally irrelevant - a parser is
supposed to do what the application or protocol implementation expects
it to do. One could use a parser that ignores everything except module
names, and it can be perfectly OK for a given application.

What we could say is that extensions MUST NOT affect the validity of
datastores, RPC messages and notifications, i.e., when validating an
instance document against a YANG data model, all extensions are
ignored. This is essentially the approach of RELAX NG towards
foreign-namespace annotations. But then the "annotation" extension would
most likely be illegal.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Oct 2015 11:19:00 +0200 (CEST)

> is able to parse nacm:default-deny-write or skips over it?

Sure.  Andy wrote:

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 17 Oct 2015 09:52:58 +0200

>    Of course an implementation of NACM cannot ignore this extension.

Good, so we actually agree. How do we get the wording to say what we
agree on?

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 17 Oct 2015 10:42:08 -0700

> Good, so we actually agree. How do we get the wording to say what we

Here is my attempt...

OLD:

NEW:

   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.

Andy