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

[Thomas Watteyne <[e-mail]>]

*[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