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

[Thomas Watteyne <[e-mail]>]

Juergen,

Great.

>    3. is GETing the resource /restconf/<module_name>/feature in RESTconf
> >    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).


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.

>    4. would a HTTP/CoAP status code (e.g. "501 Not Implemented") be a
> >    viable alternative for feature discovery?
> 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

On Sun, Oct 26, 2014 at 12:40 PM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Sun, Oct 26, 2014 at 12:07:33PM -0700, Thomas Watteyne wrote:
> > *[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?
>
> 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.
>
> >    3. is GETing the resource /restconf/<module_name>/feature in RESTconf
> >    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).
>
> >    4. would a HTTP/CoAP status code (e.g. "501 Not Implemented") be a
> >    viable alternative for feature discovery?
>
> Unclear. Which request would trigger this?
>
> >    5. In general, what are the opinions from the 6TiSCH WG about using
> >    features?
>
> Can't answer this one.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>