Subject: [netmod] working group adoption of draft-lhotka-netmod-yang-metadata-00

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jan 2015 22:21:20 +0100

Hi,

the chairs like to receive feedback from the WG whether

  draft-lhotka-netmod-yang-metadata-00

should become a working group work item. The abstract says:

   This document defines a YANG extension statement that allows for
   defining metadata annotions in YANG modules.  The document also
   specifies the encoding of annotations and rules for annotating
   instances of YANG data nodes.

In particular, the chairs like to know

  - who believes a mechanism to define metadata annotations
    should be standardized
  - who plans to use the proposed annotation extension statement
  - who is willing to review the document during the WG phase

Lada's IETF 91 slides can be found here:

  http://www.ietf.org/proceedings/91/slides/slides-91-netmod-4.pdf

Please respond by January 23rd the latest.

/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: Tue, 6 Jan 2015 13:40:58 -0800

>   - who is willing to review the document during the WG phase

yes to all 3.
We have implemented the JSON server output (but not input yet).
The extension is not supported yet, but planned.  Currently there
is hard-wired support for "with-defaults" and "owner".

The extension is a good way for the server to tell the client what
attributes it supports and tell the validation tools what attributes to process
automatically instead of generating a parsing error.

> Please respond by January 23rd the latest.

Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 07 Jan 2015 15:56:20 +0100

>   - who plans to use the proposed annotation extension statement

Support for this extension statement is now implemented in the following
two plugins of pyang:

- dsdl: XML instance documents can be validated with DSDL schemas
  including annotations defined through this extension;

- jsonxsl: Annotated XML documents can be translated to JSON.

I also plan to implement translation of annotations in the opposite
direction (JSON->XML) via the jtox plugin.

Lada

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Jan 2015 15:02:27 +0000

>  - who believes a mechanism to define metadata annotations

Not yet.  

First I think we need to clear the way for attributes to be used safely.
We used attributes in <edit-config> and also with-defaults, but in both
cases the client either accepted the contract of the protocol (base:1.1)
or explicitly opted into receiving the attributes (report-all-tagged).
Specifically, what happens to a legacy client if the attribute MUST be
semantically understood (e.g., the enabled/inactive) in order to correctly
process the data?   Even if we don't care about the client, we might want
to assert that the client will always echo back any attributes it receives
on config=true nodes - this might require a base:1.2 for NETCONF, I'm not
sure how to do this for RESTCONF.  Perhaps I'm conflating what and how,
but it seems that we're skipping a step.

>  - who plans to use the proposed annotation extension statement

As proposed, I don't see how it can be used.

Specially, I'd need to see more examples around how to declare where
attributes can be used.  For instance, how to specify that the "default"
and "enabled" parameter can only appear on config=true nodes or a
"last-sampled-timesamp" can show up only on specific config=false nodes?
Or that a "timestamp" or "Etag" attribute MUST be on top-level config node
and MAY be on other config nodes (yes, I know that RESTCONF uses HTTP
headers for this, but a similar mechanic may be desired for NETCONF).

Note that as long as attributes are cross-cutting (applying to all config
nodes generically), then they'll likely only be used for "metadata".  But,
if we introduce the ability for attributes to be used on specific nodes
(top-level node, or specific config=false node), then we open the door to
attributes being used for regular data (not just metadata), which I don't
think we want...

>  - who is willing to review the document during the WG phase

I will, if it is promoted to a WG item.

Thanks,
Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 Jan 2015 09:38:57 +0100

> process the data?   Even if we don't care about the client, we might

You are right but I think we have two separate issues here:

1. Annotations are defined via an extension, and that by definition
   means the client is free to ignore them.

2. The existing sentiment of letting a (legacy) client pick only a
   subset of modules from those advertised by the server means that the
   client in any case cannot be expected to support an annotation that
   is defined in a YANG module.

As for #1, it would help to make "annotation" a built-in statement, and
that was actually one of the questions I asked earlier:

http://www.ietf.org/mail-archive/web/netmod/current/msg11391.html

#2 could probably be addressed as a part of conformance statements.

> but it seems that we're skipping a step.

I am not sure how the client could echo the attributes. In NETCONF, it
would probably suffice that the client indicate support for particular
annotations in its hello message - then the server knows it can use it.

> headers for this, but a similar mechanic may be desired for NETCONF).

Any constraints can be specified in the description that is a part of
annotation's definition.

> attributes being used for regular data (not just metadata), which I don't

Right. If an annotation is only intended for specific nodes, then the
data modeller should consider making it a regular data node.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Jan 2015 11:05:54 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> process the data?

Note that the draft just defines the mechanism to specify the *syntax*
of meta data, not the semantics.  In the specific case of inactive,
lots of works on the semantics is needed, but that needs to happen in
a separate document.  (I think that a client needs to send
"with-inactive" in the get-config/get in order to signal to the server
that it wants to receive the inactive nodes).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 8 Jan 2015 12:43:56 +0100

> On 08 Jan 2015, at 11:05, Martin Bjorklund <[email-masked]> wrote:
> 

Hmm, but what happens if an old client creates data inside a subtree that is tagged as inactive?

For some annotations including this one the semantics will have to be “either you support it, or go away."

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Jan 2015 12:53:36 +0100 (CET)

> that is tagged as inactive?

An old client that doesn't send with-inactive will not receive
inactive data, so it won't know that it is there.

Also, with-inactive is needed in edit-config/copy-config.

> “either you support it, or go away."

Not for this one, but *maybe* for some other ;)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 Jan 2015 13:07:58 +0100

> inactive data, so it won't know that it is there.

Right, so it may think it can create its own (active) data there.

> Also, with-inactive is needed in edit-config/copy-config.

An old client that doesn't know about with-inactive can't put it there.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 10 Jan 2015 10:34:34 -0800

Hi,

This discussion got sidetracked.
Clearly the definition of individual standard attributes like "enabled"
is outside the scope of this document.  For this attribute, the
nodes have to be removed from normal retrieval.  The client
needs to ask to include disabled nodes.

The "annotation" extension is not a good way to define an
entire attribute like "enabled". We just need some way to
bind the attribute local-name to a namespace (represented
by a URI in XML and a module name in JSON).

   attr:attribute-binding "with-defaults" {
      namespace "urn:ietf:params:netconf:capability:with-defaults:1.0";
      attr:module-name "ietf-netconf-with-defaults";
   }

   attr:attribute-binding "operation" {
     namespace "urn:ietf:params:xml:ns:netconf:base:1.0";
     attr:module-name "ietf-netconf";
   }

For attributes without YANG modules, a module name needs to be assigned;

The JSON encoding of "YANG attributes" in sec. 4 also needs to be standardized.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Jan 2015 11:31:54 +0100

> that was actually one of the questions I asked earlier:

I believe we need to work with extensions, we can't revise the YANG
specifications each time an addition is needed.

My understanding is that this particular extension provides the
mechanics to define and encode metadata. It will be up to concrete
metadata definitions to figure out how to make things work such that
ignorant clients and servers will continue to function.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Jan 2015 11:37:33 +0100

> On 21 Jan 2015, at 11:31, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Fine with me.

Lada