Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-metadata-05.txt

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Mar 2016 09:44:04 +0100

Hi,

this revision is based on the IETF LC. In particular, Robert Sparks suggested in his Gen-ART LC review to include an explanation as to why we chose a YANG extension rather than a built-in statement. I added a paragraph at the end of Introduction, please have a look, I hope it's a fair account that shouldn't cause any controversy.

Thanks, Lada

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-ietf-netmod-yang-metadata-05.txt
> Date: 10 March 2016 at 09:37:07 GMT+1
> To: "Ladislav Lhotka" <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-netmod-yang-metadata-05.txt
> has been successfully submitted by Ladislav Lhotka and posted to the
> IETF repository.
> 
> Name:		draft-ietf-netmod-yang-metadata
> Revision:	05
> Title:		Defining and Using Metadata with YANG
> Document date:	2016-03-10
> Group:		netmod
> Pages:		20
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-metadata-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-05
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-metadata-05
> 
> Abstract:
>   This document defines a YANG extension statement that allows for
>   defining metadata annotations in YANG modules.  The document also
>   specifies XML and JSON encoding of annotations and other rules for
>   annotating instances of YANG data nodes.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Mar 2016 10:18:11 +0100

> this revision is based on the IETF LC. In particular, Robert Sparks suggested in his Gen-ART LC review to include an explanation as to why we chose a YANG extension rather than a built-in statement…

I think it is a feature to use extensions for new statements that do
not have to be in the core. Modularity is a good thing, the YANG
1.1. specification is already 200 papges. When adding new statements,
we should rather ask the question 'can this not also be done using
extensions'?

/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: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Mar 2016 10:49:33 +0100

> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I am not convinced about that. If we have a host of "standard" extensions (annotation, complex-type and co., mount-point, mount-module, you name them), every module author then may choose a subset of extensions for use in the module, and then the value of YANG as a standard data modelling language would be gone.

This explains the glacial pace of development of schema languages - there is a good reason for it.

The following facts also don't help:

- there is no way for indicating which extensions are supported;

- sec. 11 in 6020bis allows extensions to be added in a new revision of a module (it is not clear though whether this means definitions of extensions, uses of extensions, or both).

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Mar 2016 11:16:19 +0100

> I am not convinced about that. If we have a host of "standard" extensions (annotation, complex-type and co., mount-point, mount-module, you name them), every module author then may choose a subset…

There will be a natural filter; things that are widely used will be
widely supported, things that are not widely supported will not be
widely used. We have the same with protocols and protocol extensions,
some gain more traction than others.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Mar 2016 11:28:13 +0100

> On 10 Mar 2016, at 11:16, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Asymptotically, yes. But the modules developed in the meantime will be a mess.

> some gain more traction than others.

Protocols are very different because they usually have means for signalling/negotiating extensions. A schema, ideally, is a static specification against which instance documents can be validated. With some YANG extensions that are looming around this may not be the case anymore.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Mar 2016 12:19:44 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 
> > On 10 Mar 2016, at 11:16, Juergen Schoenwaelder
> > <[email-masked]> wrote:
> > 
> >>> On 10 Mar 2016, at 10:18, Juergen Schoenwaelder
> >>> <[email-masked]> wrote:
> >>> 
> >>>> this revision is based on the IETF LC. In particular, Robert Sparks
> >>>> suggested in his Gen-ART LC review to include an explanation as to why
> >>>> we chose a YANG extension rather than a built-in statement. I added a
> >>>> paragraph at the end of Introduction, please have a look, I hope it's
> >>>> a fair account that shouldn't cause any controversy.
> >>>> 
> >>> 
> >> I am not convinced about that. If we have a host of "standard"
> >> extensions (annotation, complex-type and co., mount-point,
> >> mount-module, you name them), every module author then may choose a
> >> subset of extensions for use in the module

Sure.  The author will use the subset of core statement + extensions
that is needed.  If the module doesn't need meta-data, it won't be
used regardless of if it's a core statement or an extension.

> >> and then the value of YANG
> >> as a standard data modelling language would be gone.
> >> 
> > 

I disagree.  I agree w/ Juergen that defining extensions when it is
possible is a feature.

/martin

> Protocols are very different because they usually have means for
> signalling/negotiating extensions. A schema, ideally, is a static
> specification against which instance documents can be validated. With
> some YANG extensions that are looming around this may not be the case
> anymore.
> 
> Lada
> 
> > 
> > /js
> > 
> > -- 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 10 Mar 2016 11:34:39 +0000

> I disagree.  I agree w/ Juergen that defining extensions when it is
I actually also agree with Juergen and Martin.

I see that the one of the advantages of using extensions is that it 
allows them to evolve independently and more quickly than the base 
draft.  And I would think that it is easier to deprecate an old 
extension if it was superseded by a better approach.

Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Mar 2016 12:39:10 +0100

> On 10 Mar 2016, at 12:19, Martin Bjorklund <[email-masked]> wrote:
> 

If it is a built-in statement, implementations have no excuse to ignore it. Even with metadata, an implementation that uses DSDL validation but ignores some annotation definitions will find instance documents containing them invalid.

> I disagree.  I agree w/ Juergen that defining extensions when it is

OK, so what about complex-type, that Balazs has just asked about? Do you encourage authors of standard track modules to use it if they feel they need it?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Mar 2016 12:42:40 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> If it is a built-in statement, implementations have no excuse to
> ignore it. Even with metadata, an implementation that uses DSDL
> validation but ignores some annotation definitions will find instance
> documents containing them invalid.
> 
> > 
> OK, so what about complex-type, that Balazs has just asked about? Do
> you encourage authors of standard track modules to use it if they feel
> they need it?

No - but not because it is an extension, but because it is
Experimental.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 10 Mar 2016 13:18:03 +0100

> On 10 Mar 2016, at 12:34, Robert Wilton <[email-masked]> wrote:
> 
> 
> 
> I see that the one of the advantages of using extensions is that it allows them to evolve independently and more quickly than the base draft.  And I would think that it is easier to deprecate an old extension if it was superseded by a better approach.

This would all be fine as long as modules developed with such extensions stay experimental, too.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Mar 2016 08:57:00 -0800

On Thu, Mar 10, 2016 at 4:18 AM, Ladislav Lhotka <[email-masked]> wrote:

> allows them to evolve independently and more quickly than the base draft.
> And I would think that it is easier to deprecate an old extension if it was
> superseded by a better approach.
>

I think standard extensions can be in standard YANG modules.
My problem with extensions is that they become mandatory-to-implement
if the module is advertised.

IMO, YANG 1.1 MUST require that if-feature-stmt can appear within an
external statement.
There is currently no way to create an optional extension.

We have also received customer requests to allow the if-feature-stmt inside
the deviation-stmt, which would be a really useful addition to YANG 1.1.

> > Rob

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Mar 2016 09:33:36 +0100

> On 10 Mar 2016, at 17:57, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

I don't agree - this doesn't happen automatically. There must be some extra mechanism for an extension to become mandatory to implement, e.g. a special protocol, or a negotiated capability in an existing protocol.

For example, if my RESTCONF implementation uses future modules that happen to contain the "mount-point" extension, I don't want structural-mount to become mandatory to implement.

> 
> IMO, YANG 1.1 MUST require that if-feature-stmt can appear within an external statement.

IMO it is way too late to consider such new features for inclusion in YANG 1.1.

Lada