Subject: [coman] constrained management: best practice for "features"

From: Thomas Watteyne <[email-masked]>
Date: Sun, 26 Oct 2014 12:07:33 -0700

*[sending to both 6TiSCH and COMAN MLs]*

While discussion management of 6TiSCH devices, Jonathan brought up an
important question [1] while reviewing draft-ietf-6tisch-6top-interface [2]:

* Are all things in the YANG model required?  For example, must one support
> reading the READ.timesource for minTimeCorrection?
>

I'd like to poll the lists for best practice in (constrained) management
and optional portions of data model:

   1. are "features" [3] the correct mechanism for marking portions on a
   data model optional?
   2. how widely used are features; are they considered good practice?
   3. is GETing the resource /restconf/<module_name>/feature in RESTconf
   the default way for discovering features?
   4. would a HTTP/CoAP status code (e.g. "501 Not Implemented") be a
   viable alternative for feature discovery?
   5. In general, what are the opinions from the 6TiSCH WG about using
   features?

Thanks,
Thomas

[1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02605.html
[2] http://tools.ietf.org/wg/6tisch/draft-ietf-6tisch-6top-interface/
[3] http://tools.ietf.org/html/rfc6020#section-7.18.1
[4] http://tools.ietf.org/html/draft-bierman-netconf-restconf-04

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 26 Oct 2014 20:40:09 +0100

>    1. are "features" [3] the correct mechanism for marking portions on a

Yes

>    2. how widely used are features; are they considered good practice?

$ grep -h -i feature.*\{ ietf-*yang | sort -u  | wc -l
      38

They are apparently not considered bad practice. However, making
single leafs features may be considered bad style. Usually features
are used to mark logical sub-components that may not be always
implemented as optional.

>    the default way for discovering features?

I think the data model in draft-ietf-netconf-restconf-03.txt section 9
is a bit more complex (you seem to be looking at an old
specification).

>    viable alternative for feature discovery?

Unclear. Which request would trigger this?

>    5. In general, what are the opinions from the 6TiSCH WG about using

Can't answer this one.

/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: Thomas Watteyne <[email-masked]>
Date: Sun, 26 Oct 2014 15:08:37 -0700

Juergen,

Great.

> is a bit more complex (you seem to be looking at an old

Yep, I was looking at an old spec...
https://tools.ietf.org/html/draft-ietf-netconf-restconf-03#appendix-D.1.2
does answer what I was looking for, and illustrates
http://tools.ietf.org/html/rfc6020#section-7.18.1 well.

> Unclear. Which request would trigger this?

Assuming some feature is NOT implemented on a server, and a client tries to
access one of the corresponding resources. I was wondering what HTTP status
code would be returned, according to RESTCONF.

Thanks,
Thomas

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Oct 2014 08:00:56 +0100

> code would be returned, according to RESTCONF.

If this is not clear from the spec, the proper place to raise this
question is the NETCONF WG.

/js