On Wed, Oct 14, 2015 at 04:01:13PM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes:
> 
> > On Tue, Oct 13, 2015 at 03:09:34PM +0200, Ladislav Lhotka wrote:
> >> 
> >> > On 13 Oct 2015, at 13:01, Juergen Schoenwaelder 
> >> > <j.schoenwael...@jacobs-university.de> wrote:
> >> > 
> >> > On Wed, Oct 07, 2015 at 05:37:36PM +0000, Kent Watsen wrote:
> >> >> 
> >> >> 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 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.
> >> 
> >> 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.
> 
> 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.

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.

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

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

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

-- 
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/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to