[sending to both 6TiSCH and COMAN MLs]

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

* Are all things in the YANG m= odel required?=C2=A0 For example, must one support reading the READ.timesou= rce for minTimeCorrection?

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

are "features&= quot; [3] the correct mechanism for marking portions on a data model option= al?
how widely used are features; are they considered good prac= tice?
is GETing the resource /restconf/<module_name>/feature in RESTconf the default wa= y for discovering features?
would a HTTP/CoAP status code=C2=A0= (e.g. "501 Not Implemented") be a viable alternative for feature = discovery?
In general, what are the opinions from the 6TiSCH WG abo= ut using features?

Thanks,

Tho= mas=C2=A0

[1]=C2=A0http://www= .ietf.org/mail-archive/web/6tisch/current/msg02605.html

[2]= =C2=A0http://tools.ietf.org/wg/6tisch/draft-ietf-6tisc= h-6top-interface/

[3]=C2=A0http://tools.ietf.org/html/rf= c6020#section-7.18.1

[4]=C2=A0http://tools.ie= tf.org/html/draft-bierman-netconf-restconf-04

--089e016283dc8d5baa05065821b2-- From nobody Sun Oct 26 12:40:16 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3F21A1A65; Sun, 26 Oct 2014 12:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOfLqigaAjzr; Sun, 26 Oct 2014 12:40:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70C541A1A5B; Sun, 26 Oct 2014 12:40:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 425CF8EE; Sun, 26 Oct 2014 20:40:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kel5bjiQk68T; Sun, 26 Oct 2014 20:39:45 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 26 Oct 2014 20:40:12 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7469E20037; Sun, 26 Oct 2014 20:40:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3F7WCptEVfna; Sun, 26 Oct 2014 20:40:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 654CD20035; Sun, 26 Oct 2014 20:40:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 721D42F1229A; Sun, 26 Oct 2014 20:40:10 +0100 (CET) Date: Sun, 26 Oct 2014 20:40:09 +0100 From: Juergen Schoenwaelder To: Thomas Watteyne Message-ID: <20141026194009.GA6308@elstar.local> Mail-Followup-To: Thomas Watteyne , "6tisch@ietf.org" <6tisch@ietf.org>, "coman@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/coman/E7jZ6iSrS_JGUNYv_bHEJYtcU44 Cc: "coman@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [coman] constrained management: best practice for "features" X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 19:40:16 -0000 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//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: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Oct 26 15:09:03 2014 Return-Path: X-Original-To: coman@ietfa.amsl.com Delivered-To: coman@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A82D1A1A2F; Sun, 26 Oct 2014 15:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3gBS5NHG4Zz; Sun, 26 Oct 2014 15:08:58 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEF41A1A17; Sun, 26 Oct 2014 15:08:58 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so4213374pab.28 for ; Sun, 26 Oct 2014 15:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=O5mZL69x+YltUiwbO2EhgFSlhMEg5GqWiWWv8GI91uw=; b=JOoeeHCKx8SapXwO6p+0cLO9y+kV5vpflYkgFx5tjmwlZ5zX9APxWZ7WaiBZikkmFD uN1iMcWntaxExZYVcndDPHEbjV4bjvjW4Ite6Pfx66E5RE2PgSgLqAaI3kpBExWZoa9S XFWDxLN9hbHnVqhecwOvJ/wruylyTjlmzlihLVZuNXhAaS2bwMTNv0rUAXIr+uQaxh8t Z03qGJ70ftnd3N+hM6mxD09COcE4ViQkEpcha5fGFMguaDlb6C+nXOTI4pCZ6OC7iKFu ooj7xUJph9yLeGIN5dcND/H7UEElq9pjpKBtrfpXx9ed/YG7hUe4/TDFe+ccVStH+2xw wSig== X-Received: by 10.68.139.161 with SMTP id qz1mr20317136pbb.24.1414361338001; Sun, 26 Oct 2014 15:08:58 -0700 (PDT) MIME-Version: 1.0 Sender: twatteyne@gmail.com Received: by 10.66.250.169 with HTTP; Sun, 26 Oct 2014 15:08:37 -0700 (PDT) In-Reply-To: <20141026194009.GA6308@elstar.local> References: <20141026194009.GA6308@elstar.local> From: Thomas Watteyne Date: Sun, 26 Oct 2014 15:08:37 -0700 X-Google-Sender-Auth: BzPm6iPVEfbxAJ6-u1O6CU0BDRc Message-ID: To: Juergen Schoenwaelder , Thomas Watteyne , "6tisch@ietf.org" <6tisch@ietf.org>, "coman@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3f7f822c18805065aa99c Archived-At: http://mailarchive.ietf.org/arch/msg/coman/4Y3Ef4UpHJTVIUvRC6iymD0u78w Subject: Re: [coman] constrained management: best practice for "features" X-BeenThere: coman@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Management of Constrained Networks and Devices List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 22:09:00 -0000 --001a11c3f7f822c18805065aa99c Content-Type: text/plain; charset=UTF-8 Juergen, Great. > 3. is GETing the resource /restconf//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 < j.schoenwaelder@jacobs-university.de> 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//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: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c3f7f822c18805065aa99c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Juergen,

Great.

&= gt;=C2=A0 =C2=A0 3. is GETing the resource /restconf/<module_name>/feature in= RESTconf
>=C2=A0 =C2=A0 the default way for discovering feature= s?
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...=C2=A0https://tools.ietf.org/html/draft-ietf-netconf-restconf-03#appe= ndix-D.1.2 does answer what I was looking for, and illustrates=C2=A0http://tools.iet= f.org/html/rfc6020#section-7.18.1 well.

>=C2=A0 =C2=A0 4. would a HTTP/CoA= P status code (e.g. "501 Not Implemented") be a
>=C2= =A0 =C2=A0 viable alternative for feature discovery?
Unclear. Which request= would trigger this?

Assuming some f= eature 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