Subject: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Oct 2015 17:37:36 +0000

This is a notice to start a NETMOD WG last call for the document:

Defining and Using Metadata with YANG
http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02

Please indicate your support by Thursday October 22, 2015 at 9PM EDT.
We are not only interested in receiving defect reports, we are equally
interested in statements of the form:

  * I have reviewed draft-ietf-netmod-yang-metadata-02 and I found no issues
  * I have implemented the data model in draft-ietf-netmod-yang-metadata-02
  * I am implementing the data model in draft-ietf-netmod-yang-metadata-02
  * I am considering to implement the data model in draft-ietf-netmod-yang-metadata-02

Of course, these are merely suggestions, folks can provide comments in any
form that suits them.

This is the second Last Call for this document, the first call being last June.

Kent  // as co-chair

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Oct 2015 13:01:00 +0200

> interested in statements of the form:

I am concerned about this text:

   Annotations modify the schema of datastores and/or management
   protocol messages, and may also change their semantics.  Therefore,
   due care has to be exercised when introducing annotations in
   network management systems in order to avoid interoperability
   problems and software failures.

I think we should actually very clearly discourage annotations that
modify the schema of datastores and/or management protocol messages
instead of assuming all annotations are free to do so.

/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: Tue, 13 Oct 2015 15:09:34 +0200

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

Annotations modify the schemas by definition because otherwise XML attributes, and objects in JSON encoding whose names start with "@", are not allowed.

Lada

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

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

---

From: Robert Varga <[email-masked]>
Date: Tue, 13 Oct 2015 17:26:19 +0200

> http://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-02

I have read the document, and coming in without the previous 
discussions, md:annotation instances feel like aspects (from 
aspect-oriented programming) being attached to pre-defined models to 
address a cross-cutting concern. Unfortunately it seems it lacks an 
equivalent of pointcut specification, e.g. a machine-readable definition 
where/when a particular annotation is valid.

This makes annotations disconnected from the YANG metamodel, which is 
not desirable for systems strictly based on the metamodel, as each 
instance of an annotation will require hand-written code.

My question is whether it would make sense to define some sort of 
(optional) pointcut specification to be carried within the md:annotation 
statement (such as an explicit list of data nodes, or a 'when' statement 
or similar)?

That would allow us to bind some/most md:annotation instances 
automagically to the metamodel, reducing the need to hand-code their 
semantics.

Thanks,
Robert

---

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

Hi Robert,

> On 13 Oct 2015, at 17:26, Robert Varga <[email-masked]> wrote:
> 
> I have read the document, and coming in without the previous discussions, md:annotation instances feel like aspects (from aspect-oriented programming) being attached to pre-defined models to address a cross-cutting concern. Unfortunately it seems it lacks an equivalent of pointcut specification, e.g. a machine-readable definition where/when a particular annotation is valid.
> 
> This makes annotations disconnected from the YANG metamodel, which is not desirable for systems strictly based on the metamodel, as each instance of an annotation will require hand-written code.
> 
> My question is whether it would make sense to define some sort of (optional) pointcut specification to be carried within the md:annotation statement (such as an explicit list of data nodes, or a 'when' statement or similar)?

The easiest way would be to define "annotation" as a first-class data node. However:

- YANG was deliberately designed to avoid using XML attributes in the same way as XML schema languages,

- IMO this can't be done through an extension.

With must or when it would be difficult to determine the context node.

Lada

> 
> That would allow us to bind some/most md:annotation instances automagically to the metamodel, reducing the need to hand-code their semantics.
> 
> Thanks,
> Robert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Oct 2015 21:23:37 +0200

> Annotations modify the schemas by definition because otherwise XML attributes, and objects in JSON encoding whose names start with "@", are not allowed.

For me, the schema of a datastore is the YANG data model. I do not
want annotations that change the YANG data model of a datastore.
Perhaps you mean something different but then the text allows multiple
interpretations and hence it is problematic.

Annotations should add metadata but I think metadata must not change
the semantics of the data model itself. I am also concerned if
metadata changes the semantics of protocol messages. I am not
interested in standards-track mechanisms that at the end increase the
chances of interoperability problems and software failures.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Oct 2015 16:01:13 +0200

> interpretations and hence it is problematic.

It depends on the definition of "schema". In any case, annotations add
some extra information that possibly might be persistent. FWIW, a RELAX
NG schema generated for datastore + annotation is different from the one
that's for datastore only.

> metadata changes the semantics of protocol messages. I am not

Some annotations that are of this sort, such as "inactive", have already
been discussed. The text you cited tries to explain possible pitfalls of
such annotations, but my understanding of the consensus so far has been
that it is not desirable to limit annotations to "benign" ones.

I guess the considerations are similar to extensions in general:
certain annotations may be a mandatory part of a protocol but is has
to be said in the protocol spec. This is essentially what was done for
NETCONF, and a special extension was used for defining the annotations
(XML attributes).

Lada

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Oct 2015 19:12:03 +0000

Interesting observation about point cut, Robert.

For the case of the "inactive" attribute that has been discussed in the past, as well as the "last-modified" attribute discussed in the draft, the intent would be to allow it everywhere, so the need for point cut isn't there.

Can you think of some metadata examples that would apply to only a subset of the nodes?

I recall a related conversation from before where we concluded that we want attributes to only ever be used as metadata (never data), which is why they are defined in a global way.  I fear that the point cut approach might bring some of that concern back...

Thanks,
Kent

From: Robert Varga <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 13, 2015 at 11:26 AM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-yang-metadata-02 (until 2015-10-22)

Thanks,
Robert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Oct 2015 09:03:30 +0200

> that's for datastore only.

Then this usage of "schema" needs to be clarified. The text in
question does not say it is specific to RELAX NG schema. It can be
read as "annotations modify the YANG data models and/or
NETCONF/RESTCONF protocol messages". I do not want to legalize
annotations that turn data model properties upside down.

> that it is not desirable to limit annotations to "benign" ones.

I am fine with the bullets, my concern is about the paragraph above
it. For me, there are different classes of annotations

- easy annotations that only add metadata (like the 'last-modified'
  example) and which are harmless (since they can be simply ignored)

- risky annotations that impact the interpretation of data (such as an
  'inactive' annotation) and which require that systems agree that
  they understand the semantics of the annotations before they can be
  used safely

- evil annotations that are trying to overwrite essential data model
  properties (e.g. a 'key' annotation that redefines the key property
  of a list or a 'type' annotation that overwrites the type of leafs
  or a 'config' annotation that redefines the config true/false
  property on the fly)

Yes, the boundary between these classes is fuzzy. I am concerned that
a statement like

   Annotations modify the schema of datastores and/or management
   protocol messages, and may also change their semantics.

paves the way to encourage not only risky but also evil annotations.
People might point to this statement and say that evil annotations
are just fine.

> NETCONF, and a special extension was used for defining the annotations

NETCONF is a special case since NETCONF was designed before we had
YANG and the WG retrofitted a YANG data model to describe it.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Oct 2015 09:52:00 +0200

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

Annotations may not turn data model properties upside down but in any case they add stuff that the peer may not be prepared to handle. If the NETCONF client doesn't expect XML attributes in the data part of a <get-config> reply, then it might break if the server uses them. That's what I meant by "schema changes" and this problem is relevant for all uses of annotations, regardless of their semantics.

> Yes, the boundary between these classes is fuzzy. I am concerned that

Yes, and the boundary may also depend on the presence of external information such as protocol specification.

>   protocol messages, and may also change their semantics.

The "schema" part addresses syntactic changes in protocol messages, which are inevitable, and the second part is about risky annotations. I agree evil annotations should be banned but I am not sure we can find a satisfactory formulation. Do you have any suggestion?

> YANG and the WG retrofitted a YANG data model to describe it.

My point here is that XML attributes defined through "get-filter-element-attribute" extension are absolutely safe in the NETCONF context because they are also addressed in the protocol spec. On the other hand, attributes with similar semantics defined through a YANG extension (without being supported in RFC 6241) would most likely be evil.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 18 Oct 2015 11:00:47 +0200

On Thu, Oct 15, 2015 at 09:52:00AM +0200, Ladislav Lhotka wrote:

[...]
 
> The "schema" part addresses syntactic changes in protocol messages,
> which are inevitable, and the second part is about risky
> annotations. I agree evil annotations should be banned but I am not
> sure we can find a satisfactory formulation. Do you have any
> suggestion?

Perhaps the simples solution is to remove the first sentence in order
to avoid having 'schema' understood in different ways. (I personally
believe an annotation MUST NOT change data model semantics but lets
try to find a compromise.) So my proposal is to replace the entire
paragraph with:

   Due care has to be exercised when introducing annotations in network
   management systems in order to avoid interoperability problems and
   software failures.  The following aspects should be taken into
   account:

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Oct 2015 10:22:08 +0200

>    software failures.  The following aspects should be taken into

I am fine with this. In a parallel thread I proposed to extend YANG spec
with a general permission for instance data and protocol messages to
include annotations (in any encoding). This would help to make sure that
compliant parsers won't choke on XML attributes or JSON objects whose
names start with "@".

Would this be acceptable?

Lada