From nobody Fri Aug 1 00:54:19 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0FB1A0255 for ; Wed, 30 Jul 2014 08:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 OJ68hQmnxjgX for ; Wed, 30 Jul 2014 08:19:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 595201A01BD for ; Wed, 30 Jul 2014 08:17:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1C5E218001B; Wed, 30 Jul 2014 08:16:36 -0700 (PDT) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140730151636.1C5E218001B@rfc-editor.org> Date: Wed, 30 Jul 2014 08:16:36 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FLwg7lEeHHm5z-HagI-CWm3EOVo X-Mailman-Approved-At: Fri, 01 Aug 2014 00:54:17 -0700 Cc: rfc-editor@rfc-editor.org, netconf@ietf.org Subject: [Netconf] [Technical Errata Reported] RFC6241 (4066) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:19:05 -0000 The following errata report has been submitted for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4066 -------------------------------------- Type: Technical Reported by: Andy Bierman Section: 7.2 Original Text ------------- If the "operation" attribute is not specified, the configuration is merged into the configuration datastore. Corrected Text -------------- If the "operation" attribute is not specified, then the operation applied to the parent data node of the configuration is used. If no parent data node is available, then the "default-operation" value is used. Notes ----- sentence in para 6 is not correct. The default-operation value is used, not the value "merge". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Sun Aug 3 23:03:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A091B2873 for ; Sun, 3 Aug 2014 23:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 P5MpG5i8khAk for ; Sun, 3 Aug 2014 23:03:45 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DB4D81B2868 for ; Sun, 3 Aug 2014 23:03:44 -0700 (PDT) Received: from localhost (37.250.156.156.bredband.tre.se [37.250.156.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 34E7B12809A3; Mon, 4 Aug 2014 08:02:44 +0200 (CEST) Date: Mon, 04 Aug 2014 08:03:23 +0200 (CEST) Message-Id: <20140804.080323.446662583.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <1406649697.21825.11.camel@ksekera-fedora> <53D7CEC0.4020300@seguesoft.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/OUr6-LLDfzX22QaFh1W5AJQLL3k Cc: netconf@ietf.org Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 06:03:46 -0000 Hi, Andy Bierman wrote: > The text on page 37 needs to be updated somehow (as errata). > I don't think we agree on the text yet, but here is an attempt > > RFC 6241, sec 7.2, para 6: > > OLD: > > If the "operation" attribute is not specified, the > configuration is merged into the configuration datastore. > > > > NEW: > > If the "operation" attribute is not specified, then > the operation applied to the parent data node of the configuration > is used. If no parent data node is available, then the > 'default-operation' value is used. Ok. Minor tweak to match the rest of the text, and re-adding the last part from the original sentence. NEW: If the "operation" attribute is not specified, then the operation applied to the parent data node of the configuration is used. If no parent data node is available, then the value of the parameter is used. If the parameter is not given, the configuration is merged into the configuration datastore. /martin From nobody Thu Aug 7 09:32:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134C81B296E for ; Thu, 7 Aug 2014 09:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 8D2Csc3cWiwq for ; Thu, 7 Aug 2014 09:31:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 94F7B1B2862 for ; Thu, 7 Aug 2014 09:31:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 117AC18047D; Thu, 7 Aug 2014 09:30:27 -0700 (PDT) To: andy@yumaworks.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140807163027.117AC18047D@rfc-editor.org> Date: Thu, 7 Aug 2014 09:30:27 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/d6C4DMetQ7RB6cCGJfYzX0LKrxI Cc: rfc-editor@rfc-editor.org, netconf@ietf.org Subject: [Netconf] [Editorial Errata Reported] RFC6470 (4073) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 16:32:01 -0000 The following errata report has been submitted for RFC6470, "Network Configuration Protocol (NETCONF) Base Notifications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6470&eid=4073 -------------------------------------- Type: Editorial Reported by: Andy Bierman Section: 2.2 Original Text ------------- file="ietf-netconf-notifications@2011-12-09.yang" Corrected Text -------------- file="ietf-netconf-notifications@2012-02-06.yang" Notes ----- Reported to me by Martin Bjorklund Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6470 (draft-ietf-netconf-system-notifications-07) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Base Notifications Publication Date : February 2012 Author(s) : A. Bierman Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Sat Aug 9 11:51:09 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F491A0273 for ; Sat, 9 Aug 2014 11:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 5k9whw7YivKr for ; Sat, 9 Aug 2014 11:49:02 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C601A0243 for ; Sat, 9 Aug 2014 11:49:01 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so416006qcx.10 for ; Sat, 09 Aug 2014 11:49:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+4fft3gVYnBxDxxVSPB83qVdrEU+C5+x6HA9UUYqK/w=; b=ZENADDDTvZVp+3N2JTiM/WiBZ/xO40a6JqkPZ9Kx+tcUJxuY/1+1l1PvIK3DoCi6YO SC0EM5xSZajWTXL77Pg9x6HQsUN1FrQJG7UdnPtmeWBhuWLcuQdkQnZ4VK9diThgQ7gn h+U4/drOjhWsY8iLZasuehB3CG9vg0q1vNR/DoEW9uUgcnKikKEBxdbm/0KrSGcEja5k NkXF7Z6zxWIfi3pGEIUcCd9U0dZ5yLYejlLIJy/2GX6rEra7hXsqR9Mmfy72p48R0wV7 6Ht5rFbliagZlpRdDTS7LYLmqhSAHAwv0wXJtHAdy5TFr/Bf5e6mmMHAZHEOZhhQ8zO5 Xfpw== X-Gm-Message-State: ALoCoQkKl5yczYIsB7qvZWQlJlxePvvTWnu+JueazesxhfP1Od2gl6ZKhOvxMn04gh74LUJ7Jkwk MIME-Version: 1.0 X-Received: by 10.229.191.2 with SMTP id dk2mr48066916qcb.8.1407610141053; Sat, 09 Aug 2014 11:49:01 -0700 (PDT) Received: by 10.140.83.8 with HTTP; Sat, 9 Aug 2014 11:49:00 -0700 (PDT) In-Reply-To: <20140804.080323.446662583.mbj@tail-f.com> References: <1406649697.21825.11.camel@ksekera-fedora> <53D7CEC0.4020300@seguesoft.com> <20140804.080323.446662583.mbj@tail-f.com> Date: Sat, 9 Aug 2014 11:49:00 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1133979e70a8f4050036c6f4 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0Q_GqPxs2C5qt64iK4wwZWsdEKo Cc: Netconf Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 18:49:07 -0000 --001a1133979e70a8f4050036c6f4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 3, 2014 at 11:03 PM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > > The text on page 37 needs to be updated somehow (as errata). > > > > > > I don't think we agree on the text yet, but here is an attempt > > > > RFC 6241, sec 7.2, para 6: > > > > OLD: > > > > If the "operation" attribute is not specified, the > > configuration is merged into the configuration datastore. > > > > > > > > NEW: > > > > If the "operation" attribute is not specified, then > > the operation applied to the parent data node of the > configuration > > is used. If no parent data node is available, then the > > 'default-operation' value is used. > > Ok. Minor tweak to match the rest of the text, and re-adding the last > part from the original sentence. > > I don't mind, but I thought since the YANG default for this leaf is 'merge', the last sentence is somewhat redundant. > NEW: > > If the "operation" attribute is not specified, then > the operation applied to the parent data node of the > configuration > is used. If no parent data node is available, then the > value of the parameter is used. If the > parameter is not given, the > configuration is merged into the configuration datastore. > > > > /martin > Andy --001a1133979e70a8f4050036c6f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Aug 3, 2014 at 11:03 PM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Hi,

Andy Bierman <andy@yumaworks.com> wrote:
> The text on page 37 needs to be updated somehow (as errata).




> I don't think we agree on the text yet, but here is an attempt
>
> RFC 6241, sec 7.2, para 6:
>
> OLD:
>
> =A0 =A0 =A0 =A0 =A0If the "operation" attribute is not speci= fied, the
> =A0 =A0 =A0 =A0 =A0configuration is merged into the configuration data= store.
>
>
>
> NEW:
>
> =A0 =A0 =A0 =A0 =A0If the "operation" attribute is not speci= fied, then
> =A0 =A0 =A0 =A0 =A0the operation applied to the parent data node of th= e configuration
> =A0 =A0 =A0 =A0 =A0is used. If no parent data node is available, then = the
> 'default-operation' value is used.

Ok. =A0Minor tweak to match the rest of the text, and re-adding the last part from the original sentence.



the last sentence is somewhat redundant.



<= /div>
Andy

--001a1133979e70a8f4050036c6f4-- From nobody Sun Aug 10 03:34:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DCC1A06C9 for ; Sun, 10 Aug 2014 03:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 uOJaOb9tjvBf for ; Sun, 10 Aug 2014 03:34:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDFC1A06C5 for ; Sun, 10 Aug 2014 03:33:59 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s7AAXvf7022926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 10 Aug 2014 10:33:58 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s7AAXuoc013115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 10 Aug 2014 12:33:57 +0200 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 10 Aug 2014 12:33:56 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.128]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0195.001; Sun, 10 Aug 2014 12:33:56 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: IETF 90 NETCONF Draft Minutes Thread-Index: AQHPtIaW7ffK/Pf6PUu0Ln+t5Jf+/w== Date: Sun, 10 Aug 2014 10:33:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8194CB6BCDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5110 X-purgate-ID: 151667::1407666838-000005B1-07A937DC/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dsH5UdR793zWMlRvrZyo7QkACkk Subject: [Netconf] IETF 90 NETCONF Draft Minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 10:34:02 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8194CB6BCDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, please find the draft minutes of the IETF 90 NETCONF session at http://www.ietf.org/proceedings/90/minutes/minutes-90-netconf Pls send your comments to the co-chairs by August 18, 2014. Many thanks to the minute takers Dan Romascanu and Lada Lhotka. Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F8194CB6BCDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NETCONF WG,

 

please find the draft minutes of the IE= TF 90 NETCONF session at

http://www.ietf.org/procee= dings/90/minutes/minutes-90-netconf

 <= /p>

Pls send your comments to the co-chairs= by August 18, 2014.=

 <= /p>

Many thanks to the minute takers Dan Ro= mascanu and Lada Lhotka.

 

Regards,

Mehmet

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F8194CB6BCDEMUMBX005nsnin_-- From nobody Sun Aug 10 11:06:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2749C1A0457 for ; Sun, 10 Aug 2014 11:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 NzKr2Hgw4l7i for ; Sun, 10 Aug 2014 11:06:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E28391A0436 for ; Sun, 10 Aug 2014 11:06:55 -0700 (PDT) Received: from localhost (unknown [193.12.35.134]) by mail.tail-f.com (Postfix) with ESMTPSA id 11B201280055; Sun, 10 Aug 2014 20:05:39 +0200 (CEST) Date: Sun, 10 Aug 2014 20:06:53 +0200 (CEST) Message-Id: <20140810.200653.454846317.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140804.080323.446662583.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/tyDZykAN1rNQ4E7acQQ7TY9IoJg Cc: netconf@ietf.org Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 18:06:57 -0000 Andy Bierman wrote: > On Sun, Aug 3, 2014 at 11:03 PM, Martin Bjorklund wrote: > > > Hi, > > > > Andy Bierman wrote: > > > The text on page 37 needs to be updated somehow (as errata). > > > > > > > > > > > I don't think we agree on the text yet, but here is an attempt > > > > > > RFC 6241, sec 7.2, para 6: > > > > > > OLD: > > > > > > If the "operation" attribute is not specified, the > > > configuration is merged into the configuration datastore. > > > > > > > > > > > > NEW: > > > > > > If the "operation" attribute is not specified, then > > > the operation applied to the parent data node of the > > configuration > > > is used. If no parent data node is available, then the > > > 'default-operation' value is used. > > > > Ok. Minor tweak to match the rest of the text, and re-adding the last > > part from the original sentence. > > > > > > I don't mind, but I thought since the YANG default for this leaf is 'merge', > the last sentence is somewhat redundant. Agree it is redundant, but since it it there in the original, I think it is better to keep it. /martin From nobody Thu Aug 14 10:01:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBD41A0903 for ; Thu, 14 Aug 2014 10:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 I3ybUHJAAA1O for ; Thu, 14 Aug 2014 10:01:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0122D1A0916 for ; Thu, 14 Aug 2014 10:01:43 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Thu, 14 Aug 2014 17:01:40 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.227]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.120]) with mapi id 15.00.1005.008; Thu, 14 Aug 2014 17:01:40 +0000 From: Kent Watsen To: NetConf Thread-Topic: RESTCONF modularilty Thread-Index: AQHPt+FqdMjKJfbxJUGUd4a2DR/a/g== Date: Thu, 14 Aug 2014 17:01:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(199003)(189002)(92566001)(229853001)(83322001)(101416001)(36756003)(50986999)(107886001)(2656002)(83072002)(85852003)(99396002)(15202345003)(21056001)(87936001)(95666004)(86362001)(99286002)(66066001)(16236675004)(221733001)(105586002)(54356999)(19580395003)(106356001)(77982001)(107046002)(19617315012)(80022001)(81542001)(79102001)(81342001)(20776003)(4396001)(106116001)(64706001)(46102001)(110136001)(83506001)(74662001)(15975445006)(77096002)(85306004)(92726001)(76482001)(74502001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D01263B17E18Bkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JBxTerHVsfCfq8b9Gm-UuFFgZNM Subject: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 17:01:50 -0000 --_000_D01263B17E18Bkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The RESTCONF authors recently discussed adding support for filtering, sorti= ng, and paging collections (i.e. lists). One comment was that it was compl= ex and better defined in another draft. I agree, but more importantly, RE= STCONF should be fully modular, providing an ability for implementations to= selectively advertise support for various things. This is exactly the a= pproach we used for the NETCONF Light draft (http://tools.ietf.org/html/dra= ft-schoenw-netconf-light-01), but RESTCONF being a new protocol, there is n= o reason to not do it from the get go. This strategy was discussed in Tor= onto, but we felt we should take it to the list before restructuring the do= cument... Recapping the NETCONF Light strategy, the YANG module defined the follow fe= atures: feature get-config { description "This feature indicates that the server supports the protocol operation, albeit without subtree filtering. The server must additionally advertize the \"subtree-filtering\" feature to enable subtree filtering. Alternatively, if the server only wants to support XPath filtering, it may just advertize the :xpath capability."; } feature subtree-filtering { description "This feature indicates that the server supports subtree filtering for the operation. This feature is only meaningful if the "get-config" feature is advertized; if "get-config" is not also advertized, this feature MUST be ignored."; } feature edit-config { description "This feature indicates that the server supports the protocol operation. If the server is unable to support all the attributes (merge, replace, create, delete, remove), then it should advertize the \"copy-config\" feature instead."; } feature copy-config { description "This feature indicates that the server supports the protocol operation."; } feature delete-config { description "This feature indicates that the server supports the protocol operation."; } feature locking { description "This feature indicates that the server supports the and protocol operations."; } feature get { description "This feature indicates that the server supports the protocol operation."; } feature close-session { description "This feature indicates that the server supports the protocol operation. When this feature is not advertized, clients are expected to close the underlying transport directly."; } feature kill-session { description "This feature indicates that the server supports the protocol operation."; } The corollary to RESTCONF might be: Base Support - the ability to GET and PUT on the top-level node using XML only Optional Support: - the ability to do PATCH (this is already optional) - the ability to use JSON encoding - the ability to POST/GET/PUT/DELETE subtrees (PATCH too, is su= pport for it is advertised) - the ability to use "select" with GET operations - the ability to use "filter" with GET on collection resources (i= .e. lists) and event streams - the ability to do pagination with GET on collection resources (= i.e. lists) - the ability to do sorting with GET on collection resources (i.e= . lists) Thoughts? Thanks, Kent --_000_D01263B17E18Bkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <441A0B26BDBD144289DFC0D673DB5199@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

The RESTCONF authors recently discussed adding support for filtering, sorti= ng, and paging collections (i.e. lists).  One comment was that it was = complex and better defined in another draft.   I agree, but more impor= tantly, RESTCONF should be fully modular, providing an ability for implementations to selectively advertise support = for various things.    This is exactly the approach we used for t= he NETCONF Light draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-0= 1), but RESTCONF being a new protocol, there is no reason to not do it from th= e get go.   This strategy was discussed in Toronto, but we felt we sho= uld take it to the list before restructuring the document...

Recapping the NETCONF Light strategy, the YANG module defined the follow fe= atures:

     feature get-conf= ig {
       descripti= on
        "Th= is feature indicates that the server supports the
         &l= t;get-config> protocol operation, albeit without subtree
         fi= ltering.   The server must additionally advertize
         th= e \"subtree-filtering\" feature to enable subtree
         fi= ltering.  Alternatively, if the server only wants
         to= support XPath filtering, it may just advertize
         th= e :xpath capability.";
     }

     feature subtree-= filtering {
       descripti= on
        "Th= is feature indicates that the server supports subtree
         fi= ltering for the <get-config> operation.  This
         fe= ature is only meaningful if the "get-config" feature
     =    is advertized; if "get-config" is not also advertiz= ed,
         th= is feature MUST be ignored.";
     }

     feature edit-con= fig {
       descripti= on
        "Th= is feature indicates that the server supports the
         &l= t;edit-config> protocol operation.  If the server is
         un= able to support all the <edit-config> attributes
         (m= erge, replace, create, delete, remove), then it
         sh= ould advertize the \"copy-config\" feature instead.";=
     }

     feature copy-con= fig {
       descripti= on
        "Th= is feature indicates that the server supports the
         &l= t;copy-config> protocol operation.";
     }

     feature delete-c= onfig {
       descripti= on
        "Th= is feature indicates that the server supports the
         &l= t;delete-config> protocol operation.";
     }

     feature locking = {
       descripti= on
        "Th= is feature indicates that the server supports the
         &l= t;lock> and <unlock> protocol operations.";
     }

     feature get {
       descripti= on
        "Th= is feature indicates that the server supports the
         &l= t;get> protocol operation.";
     }

     feature close-se= ssion {
       descripti= on
        "Th= is feature indicates that the server supports the
         &l= t;close-session> protocol operation.  When this feature
         is= not advertized, clients are expected to close the
         un= derlying transport directly.";
     }

     feature kill-ses= sion {
       descripti= on
        "Th= is feature indicates that the server supports the
     =    <kill-session> protocol operation.";
     }



The corollary to RESTCONF might= be:

    Base Support
          -= the ability to GET and PUT on the top-level node using XML only

    Optional Support:
          - the ability to do PATCH  (th= is is already optional)
          - the ability to use JSON encoding<= /div>
          -= the ability to POST/GET/PUT/DELETE subtrees   (PATCH too, is support = for it is advertised)
          -= the ability to use "select" with GET operations 
          -= the ability to use "filter" with GET on collection resources (i.e. lists) and event streams=
          -= the ability to do pagination with GET on collection resources (i.e. lists)
          -= the ability to do sorting with GET on collection resources (i.e. lists)


Thoughts?

Thanks,
Kent



--_000_D01263B17E18Bkwatsenjunipernet_-- From nobody Wed Aug 20 10:46:35 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139B51A0666; Wed, 20 Aug 2014 10:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 nC0UYII--GIY; Wed, 20 Aug 2014 10:46:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 411181A064F; Wed, 20 Aug 2014 10:46:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820174629.27343.42011.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 10:46:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9GUk4JdBRxztxEleGZ2d1Uw4SmI Cc: netconf@ietf.org Subject: [Netconf] NETCONF WG Bi-Weekly Virtual Interim Meetings beginning September 8, 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 17:46:31 -0000 The NETCONF WG will have a series of bi-weekly virtual interim meetings. The meetings will take place every other Monday from 1900-2100 CEST. The first meeting will be on Monday, September 8, 2014, and the series will end on Monday, November 2, 2014. ------------------------------------------------------- Topic: NETCONF Bi-weekly Meeting Date: Every 2 weeks on Monday, from Monday, September 8, 2014 to Monday, November 3, 2014 Time: 7:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 602 794 Meeting Password: restconf ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=m3376a52e7a0e41672bed8e07d6c65d67 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: restconf 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=me875d958a9d772d851399d42e20ae8d4 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 602 794 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: netconf-chairs@tools.ietf.org To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=m25825e3bf1347d5a34f89769b2cdcd01 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x649602794# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From nobody Thu Aug 21 07:26:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8F51A031A for ; Thu, 21 Aug 2014 07:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 aqwoCmZ_ZTtn for ; Thu, 21 Aug 2014 07:26:23 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F141A02F1 for ; Thu, 21 Aug 2014 07:26:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 511E654057F; Thu, 21 Aug 2014 16:26:19 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t9u887vOUmO; Thu, 21 Aug 2014 16:26:14 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6C06C540010; Thu, 21 Aug 2014 16:26:13 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , NetConf In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 21 Aug 2014 16:26:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ahKsI-euMrMjnPGNApHEZNpZUlI Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:26:25 -0000 Hi, Kent Watsen writes: > The RESTCONF authors recently discussed adding support for filtering, > sorting, and paging collections (i.e. lists). One comment was that it > was complex and better defined in another draft. I agree, but more > importantly, RESTCONF should be fully modular, providing an ability > for implementations to selectively advertise support for various > things. This is exactly the approach we used for the NETCONF Light > draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but > RESTCONF being a new protocol, there is no reason to not do it from > the get go. This strategy was discussed in Toronto, but we felt we > should take it to the list before restructuring the document... I fully agree with this strategy. Support for individual capabilities will be indicated somehow under the "restconf" resource? ... > > The corollary to RESTCONF might be: > > Base Support > - the ability to GET and PUT on the top-level node using XML only > > Optional Support: > - the ability to do PATCH (this is already optional) > - the ability to use JSON encoding I think XML and JSON should be given equal footing, i.e. the server could support either or both. Perhaps the "Accept" header on the client side and 406/415 status codes on the server side could be enough? Lada > - the ability to POST/GET/PUT/DELETE subtrees (PATCH too, is support for it is advertised) > - the ability to use "select" with GET operations > - the ability to use "filter" with GET on collection resources (i.e. lists) and event streams > - the ability to do pagination with GET on collection resources (i.e. lists) > - the ability to do sorting with GET on collection resources (i.e. lists) > > > Thoughts? > > Thanks, > Kent > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 21 08:12:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6691A04A4 for ; Thu, 21 Aug 2014 08:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 P6PxSAoGXN_1 for ; Thu, 21 Aug 2014 08:12:10 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6021A03CA for ; Thu, 21 Aug 2014 08:12:09 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id r5so9320470qcx.16 for ; Thu, 21 Aug 2014 08:12:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i6nNEmP8s1viCgFm898HvwDJZ1LJ6lUUVz+cJytUm38=; b=ZX4zZigPz/BPEv7Ash7Vo8OhXeUbmwZbF+zOhOR8iGejwsWAse+tW5Wj4gX2FKNXzB rqT9Ty7z5bdUJd7RAQbOy+sxzx5KPxa1vb6NLOFhQ8hsmBzodza/fSY7e9H++LaKfoJ7 8Jvu1MrL9PpofpjIGyRPz7YShxuBVXKZXkquSTDgI6zXklrNxwR1oIPazei1uN5wZPJ7 Uo9C+Yzzcg1+QBS8J844GTUTZo1OKbmwvPL2g33aT4S26IKNx5sDn4j/v2lvApuNgrYf Gge65iRAkIn28fczt2qoG3JtHBrawKWHHb1sz76xRAbnnPnxxlH+BwyEqL+ZV6ZXlYST KtKQ== X-Gm-Message-State: ALoCoQmpyFlQciy4ULzc2mlyVhA9Ws+uBRv39Dvq3Recxbb+OF8hDR41GIR45nRRJLSj/mr6B7jb MIME-Version: 1.0 X-Received: by 10.140.28.6 with SMTP id 6mr83610069qgy.90.1408633928956; Thu, 21 Aug 2014 08:12:08 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 21 Aug 2014 08:12:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Aug 2014 08:12:08 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11398076f45aa80501252474 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1-qOBRpWonL8T1hhqjVVfUo1Pz4 Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:12:12 -0000 --001a11398076f45aa80501252474 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 21, 2014 at 7:26 AM, Ladislav Lhotka wrote: > Hi, > > Kent Watsen writes: > > > The RESTCONF authors recently discussed adding support for filtering, > > sorting, and paging collections (i.e. lists). One comment was that it > > was complex and better defined in another draft. I agree, but more > > importantly, RESTCONF should be fully modular, providing an ability > > for implementations to selectively advertise support for various > > things. This is exactly the approach we used for the NETCONF Light > > draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but > > RESTCONF being a new protocol, there is no reason to not do it from > > the get go. This strategy was discussed in Toronto, but we felt we > > should take it to the list before restructuring the document... > > I fully agree with this strategy. Support for individual capabilities > will be indicated somehow under the "restconf" resource? > > I support this strategy as well. We made all 9 groups of RMON optional and let the market decide how to best deploy RMON-MIB. Turned out that "RMON-Lite" was very useful. Option 1: custom lists: container restconf { container modules { ... currently in tree ... } container capabilities { ... new ... format TBD } container query-parameters { new ... format TBD } } Option 2: back to simple list of URIs container restconf { container capabilities { leaf-list capability { same as in ietf-netconf-monitoring } } } Option 3: Require implementation of the ietf-netconf-monitoring 'capability' node /restconf/data/netconf-state/capabilities/capability ** This probably requires a 6022bis to make the monitoring stats support NETCONF and RESTCONF ** 2 & 3 require URI definitions for each query parameter and official protocol capability ... > > > > > The corollary to RESTCONF might be: > > > > Base Support > > - the ability to GET and PUT on the top-level node using XML > only > > > > Optional Support: > > - the ability to do PATCH (this is already optional) > > - the ability to use JSON encoding > > I think XML and JSON should be given equal footing, i.e. the server > could support either or both. Perhaps the "Accept" header on the client > side and 406/415 status codes on the server side could be enough? > This approach doesn't work if each person picks their pet options to be mandatory. Everything is optional, even XML. One might want to support only JSON and not implement XML. I would make read-only vs read-write vs read-create/delete 3 separate capabilities (server MUST support 1 of them) read-only: GET read-write: GET, PUT read-create: GET, POST, PUT, DELETE I think this aligns better with capabilities of constrained devices. > Lada > > > - the ability to POST/GET/PUT/DELETE subtrees (PATCH too, is > support for it is advertised) > > - the ability to use "select" with GET operations > > - the ability to use "filter" with GET on collection resources > (i.e. lists) and event streams > > - the ability to do pagination with GET on collection > resources (i.e. lists) > > - the ability to do sorting with GET on collection resources > (i.e. lists) > > > Some of these are traditionally client-side tasks. They should be optional. HTTP already makes PATCH optional. All query parameters should be optional. > > > > Thoughts? > > > > Thanks, > > Kent > > > Andy --001a11398076f45aa80501252474 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 7:26 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Hi,

Kent Watsen <kwatsen@juniper.net<= /a>> writes:

> The RESTCONF authors recently discussed adding support for filtering,<= br> > sorting, and paging collections (i.e. lists).=A0 One comment was that = it
> was complex and better defined in another draft.=A0 I agree, but more<= br> > importantly, RESTCONF should be fully modular, providing an ability > for implementations to selectively advertise support for various
> things.=A0 This is exactly the approach we used for the NETCONF Light<= br> > draft (http://tools.ietf.org/html/draft-schoenw-netconf-l= ight-01), but
> RESTCONF being a new protocol, there is no reason to not do it from > the get go.=A0 This strategy was discussed in Toronto, but we felt we<= br> > should take it to the list before restructuring the document...

I fully agree with this strategy. Support for individual capabilities
will be indicated somehow under the "restconf" resource?


I support this strategy as well. We ma= de all 9 groups of RMON optional
and let the market decide how to= best deploy RMON-MIB. =A0Turned out
that "RMON-Lite" w= as very useful.

=A0Option 1: =A0custom lists:

= =A0 =A0container restconf {
=A0 =A0 =A0 =A0 container modules { = =A0... currently in tree ... }
=A0 =A0 =A0 =A0 container capabili= ties =A0{ ... new ... format TBD }
=A0 =A0 =A0 =A0 container query-parameters { new ... format TBD }
=A0 =A0}


Option 2: back to si= mple list of URIs

=A0 =A0 =A0container restconf {<= /div>
=A0 =A0 =A0 =A0 container capabilities =A0{
=A0 =A0 =A0 =A0 =A0 =A0 leaf-list capability { same as in ietf-netconf= -monitoring }
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0}
=

Option 3: Require implementation of the ietf-= netconf-monitoring 'capability' node

=A0 =A0 =A0/restconf/data/netconf-state/capabiliti= es/capability
=A0 =A0 =A0** This probably requires a 6022bi= s to make the
=A0 =A0 =A0 =A0 =A0monitoring stats support NETCONF= and RESTCONF


=A0** 2 & 3 require URI definitions = for each query parameter and official protocol capability


...

>
> The corollary to RESTCONF might be:
>
>=A0 =A0 =A0Base Support
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to GET and PUT on the top-level no= de using XML only
>
>=A0 =A0 =A0Optional Support:
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to do PATCH=A0 (this is already op= tional)
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to use JSON encoding

I think XML and JSON should be given equal footing, i.e. the server
could support either or both. Perhaps the "Accept" header on the = client
side and 406/415 status codes on the server side could be enough?

This approach doesn't work if each person pi= cks their pet options to
be mandatory. =A0Everything is optional,= even XML. One might want
to support only JSON and not implement XML.

I= would make read-only vs read-write vs read-create/delete 3 separate
<= div>capabilities (server MUST support 1 of them)

=A0 read-only: GET
=A0 read-write: GET, PUT
=A0 read-cr= eate: GET, POST, PUT, DELETE

I think this aligns b= etter with capabilities of constrained devices.


Lada

>=A0 =A0 =A0 =A0 =A0 =A0- the ability to POST/GET/PUT/DELETE subtrees=A0= =A0(PATCH too, is support for it is advertised)
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to use "select" with GET= operations
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to use "filter" with GET= on collection resources (i.e. lists) and event streams
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to do pagination with GET on colle= ction resources (i.e. lists)
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to do sorting with GET on collecti= on resources (i.e. lists)
>

Some of these are traditionally cl= ient-side tasks. =A0They should be optional.
HTTP already makes P= ATCH optional. All query parameters should be optional.


=A0
>
> Thoughts?
>
> Thanks,
> Kent
>

Andy
=A0
--001a11398076f45aa80501252474-- From nobody Thu Aug 21 08:36:54 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE261A03FE for ; Thu, 21 Aug 2014 08:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.668] 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 HJ0VZAAPl-a0 for ; Thu, 21 Aug 2014 08:36:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084431A03F1 for ; Thu, 21 Aug 2014 08:36:51 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 5005813FB0D; Thu, 21 Aug 2014 17:36:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1408635409; bh=pVRQFz0Cy56HRYVY+dhuwcAWDmyqvH94/RB2E3Mz1og=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=reNnldncHnS44WgZwjfPT8IepMUPAmtKWwYiyNX+HIE//F4x87hLPjP/twN2Orsmd usEu5wEeSoenhYRctXEa7jHdZp3+teGUmrqApwOgUH69BnU+mV816BTULYp1tURbY5 Rb/ncFUSWaKMLfeWrIPGylHAWs7CNP0RN/Fw6Nvg= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 21 Aug 2014 17:36:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_YrpY4a7fW_96MM1QC88nyexdRg Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:36:53 -0000 On 21 Aug 2014, at 17:12, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Aug 21, 2014 at 7:26 AM, Ladislav Lhotka = wrote: > Hi, >=20 > Kent Watsen writes: >=20 > > The RESTCONF authors recently discussed adding support for = filtering, > > sorting, and paging collections (i.e. lists). One comment was that = it > > was complex and better defined in another draft. I agree, but more > > importantly, RESTCONF should be fully modular, providing an ability > > for implementations to selectively advertise support for various > > things. This is exactly the approach we used for the NETCONF Light > > draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), = but > > RESTCONF being a new protocol, there is no reason to not do it from > > the get go. This strategy was discussed in Toronto, but we felt we > > should take it to the list before restructuring the document... >=20 > I fully agree with this strategy. Support for individual capabilities > will be indicated somehow under the "restconf" resource? >=20 >=20 > I support this strategy as well. We made all 9 groups of RMON optional > and let the market decide how to best deploy RMON-MIB. Turned out > that "RMON-Lite" was very useful. >=20 > Option 1: custom lists: >=20 > container restconf { > container modules { ... currently in tree ... } > container capabilities { ... new ... format TBD } > container query-parameters { new ... format TBD } > } >=20 If the set of capabilities is open-ended then I would go for this option = as it is the most flexible. Capability descriptions could then have more = structure than a simple URI. >=20 > Option 2: back to simple list of URIs >=20 > container restconf { > container capabilities { > leaf-list capability { same as in ietf-netconf-monitoring = } > } > } >=20 >=20 > Option 3: Require implementation of the ietf-netconf-monitoring = 'capability' node >=20 > /restconf/data/netconf-state/capabilities/capability > ** This probably requires a 6022bis to make the > monitoring stats support NETCONF and RESTCONF >=20 >=20 > ** 2 & 3 require URI definitions for each query parameter and = official protocol capability >=20 >=20 > ... >=20 > > > > The corollary to RESTCONF might be: > > > > Base Support > > - the ability to GET and PUT on the top-level node using = XML only > > > > Optional Support: > > - the ability to do PATCH (this is already optional) > > - the ability to use JSON encoding >=20 > I think XML and JSON should be given equal footing, i.e. the server > could support either or both. Perhaps the "Accept" header on the = client > side and 406/415 status codes on the server side could be enough? >=20 > This approach doesn't work if each person picks their pet options to > be mandatory. Everything is optional, even XML. One might want > to support only JSON and not implement XML. This is what I am saying. Lada >=20 > I would make read-only vs read-write vs read-create/delete 3 separate > capabilities (server MUST support 1 of them) >=20 > read-only: GET > read-write: GET, PUT > read-create: GET, POST, PUT, DELETE >=20 > I think this aligns better with capabilities of constrained devices. >=20 >=20 >=20 > Lada >=20 > > - the ability to POST/GET/PUT/DELETE subtrees (PATCH = too, is support for it is advertised) > > - the ability to use "select" with GET operations > > - the ability to use "filter" with GET on collection = resources (i.e. lists) and event streams > > - the ability to do pagination with GET on collection = resources (i.e. lists) > > - the ability to do sorting with GET on collection = resources (i.e. lists) > > >=20 > Some of these are traditionally client-side tasks. They should be = optional. > HTTP already makes PATCH optional. All query parameters should be = optional. >=20 >=20 > =20 > > > > Thoughts? > > > > Thanks, > > Kent > > >=20 > Andy > =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 21 09:06:38 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D29A1A03E2 for ; Thu, 21 Aug 2014 09:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 CfTzakZo5PHp for ; Thu, 21 Aug 2014 09:06:32 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582CE1A02E3 for ; Thu, 21 Aug 2014 09:06:32 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id l6so9424560qcy.39 for ; Thu, 21 Aug 2014 09:06:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sMq9EsptSW3P39eB58tq2n4zFPeT4m/u0wPMSA30SEw=; b=dEcgcnu1vmu1+iCbaCSrYfnpZX9/6ue+mx9F49JJGcRz3p/sxy3i8RfrDFW1AxjO/0 6bFAaNFAk3lTINz6bcwDjTDcX55Ggr2vvKyIMC7G4ODNmYlUtmwOv9UjwVGH1X9R/xBI lo2i09H1bni7MTUHeXrH9ectTteaiGfYZDo8+c2z3DpFWEeVFm0fq7lgOuMQ+w+vIaRc TBVH+tNMbymQFqpsGznCY6/lXEtfQXxwr5R39aZnnzjZafAvD16rPZo7DPe8dIm/WMXS xtly9a5S55xKuvcyEDBo4Jx5+XuaIm8LIuzxOP8AmK1wQk8UWikNjsJS7eK/0LG7HlPU efLg== X-Gm-Message-State: ALoCoQkQDt3TWa22u5OU9eva/jpm20WDDUHEd/PtUZJnXFS2Dz9P1bhG3nD+wiTv8AwrGLzyv0Fv MIME-Version: 1.0 X-Received: by 10.229.231.68 with SMTP id jp4mr89527799qcb.4.1408637191467; Thu, 21 Aug 2014 09:06:31 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 21 Aug 2014 09:06:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Aug 2014 09:06:31 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1134497a6a626b050125e734 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Idw8nfL7nRzAYVSUkofT6bJ9k0A Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:06:35 -0000 --001a1134497a6a626b050125e734 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 21, 2014 at 8:36 AM, Ladislav Lhotka wrote: > > On 21 Aug 2014, at 17:12, Andy Bierman wrote: > > > > > > > > > On Thu, Aug 21, 2014 at 7:26 AM, Ladislav Lhotka wrote: > > Hi, > > > > Kent Watsen writes: > > > > > The RESTCONF authors recently discussed adding support for filtering, > > > sorting, and paging collections (i.e. lists). One comment was that it > > > was complex and better defined in another draft. I agree, but more > > > importantly, RESTCONF should be fully modular, providing an ability > > > for implementations to selectively advertise support for various > > > things. This is exactly the approach we used for the NETCONF Light > > > draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but > > > RESTCONF being a new protocol, there is no reason to not do it from > > > the get go. This strategy was discussed in Toronto, but we felt we > > > should take it to the list before restructuring the document... > > > > I fully agree with this strategy. Support for individual capabilities > > will be indicated somehow under the "restconf" resource? > > > > > > I support this strategy as well. We made all 9 groups of RMON optional > > and let the market decide how to best deploy RMON-MIB. Turned out > > that "RMON-Lite" was very useful. > > > > Option 1: custom lists: > > > > container restconf { > > container modules { ... currently in tree ... } > > container capabilities { ... new ... format TBD } > > container query-parameters { new ... format TBD } > > } > > > > If the set of capabilities is open-ended then I would go for this option > as it is the most flexible. Capability descriptions could then have more > structure than a simple URI. > > This is not very flexible because the YANG structure needs to be defined at the start. I think the URI is better because it is flexible. Also much less overhead on-the-wire than a YANG data structure (that would match it in flexibility). Andy > > > Option 2: back to simple list of URIs > > > > container restconf { > > container capabilities { > > leaf-list capability { same as in ietf-netconf-monitoring } > > } > > } > > > > > > Option 3: Require implementation of the ietf-netconf-monitoring > 'capability' node > > > > /restconf/data/netconf-state/capabilities/capability > > ** This probably requires a 6022bis to make the > > monitoring stats support NETCONF and RESTCONF > > > > > > ** 2 & 3 require URI definitions for each query parameter and official > protocol capability > > > > > > ... > > > > > > > > The corollary to RESTCONF might be: > > > > > > Base Support > > > - the ability to GET and PUT on the top-level node using XML > only > > > > > > Optional Support: > > > - the ability to do PATCH (this is already optional) > > > - the ability to use JSON encoding > > > > I think XML and JSON should be given equal footing, i.e. the server > > could support either or both. Perhaps the "Accept" header on the client > > side and 406/415 status codes on the server side could be enough? > > > > This approach doesn't work if each person picks their pet options to > > be mandatory. Everything is optional, even XML. One might want > > to support only JSON and not implement XML. > > This is what I am saying. > > Lada > > > > > I would make read-only vs read-write vs read-create/delete 3 separate > > capabilities (server MUST support 1 of them) > > > > read-only: GET > > read-write: GET, PUT > > read-create: GET, POST, PUT, DELETE > > > > I think this aligns better with capabilities of constrained devices. > > > > > > > > Lada > > > > > - the ability to POST/GET/PUT/DELETE subtrees (PATCH too, > is support for it is advertised) > > > - the ability to use "select" with GET operations > > > - the ability to use "filter" with GET on collection > resources (i.e. lists) and event streams > > > - the ability to do pagination with GET on collection > resources (i.e. lists) > > > - the ability to do sorting with GET on collection resources > (i.e. lists) > > > > > > > Some of these are traditionally client-side tasks. They should be > optional. > > HTTP already makes PATCH optional. All query parameters should be > optional. > > > > > > > > > > > > Thoughts? > > > > > > Thanks, > > > Kent > > > > > > > Andy > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1134497a6a626b050125e734 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 8:36 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 21 Aug 2014, at 17:12, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Thu, Aug 21, 2014 at 7:26 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Hi,
>
> Kent Watsen <kwatsen@juniper= .net> writes:
>
> > The RESTCONF authors recently discussed adding support for filter= ing,
> > sorting, and paging collections (i.e. lists).=A0 One comment was = that it
> > was complex and better defined in another draft.=A0 I agree, but = more
> > importantly, RESTCONF should be fully modular, providing an abili= ty
> > for implementations to selectively advertise support for various<= br> > > things.=A0 This is exactly the approach we used for the NETCONF L= ight
> > draft (http://tools.ietf.org/html/draft-schoenw-netc= onf-light-01), but
> > RESTCONF being a new protocol, there is no reason to not do it fr= om
> > the get go.=A0 This strategy was discussed in Toronto, but we fel= t we
> > should take it to the list before restructuring the document... >
> I fully agree with this strategy. Support for individual capabilities<= br> > will be indicated somehow under the "restconf" resource?
>
>
> I support this strategy as well. We made all 9 groups of RMON optional=
> and let the market decide how to best deploy RMON-MIB.=A0 Turned out > that "RMON-Lite" was very useful.
>
>=A0 Option 1:=A0 custom lists:
>
>=A0 =A0 container restconf {
>=A0 =A0 =A0 =A0 =A0container modules {=A0 ... currently in tree ... } >=A0 =A0 =A0 =A0 =A0container capabilities=A0 { ... new ... format TBD }=
>=A0 =A0 =A0 =A0 =A0container query-parameters { new ... format TBD } >=A0 =A0 }
>

If the set of capabilities is open-ended then I would go for this option as= it is the most flexible. Capability descriptions could then have more stru= cture than a simple URI.



This is not very flexib= le because the YANG structure needs to be defined at the start.
I= think the URI is better because it is flexible. =A0Also much less overhead= on-the-wire than
a YANG data structure (that would match it in flexibility). =A0
<= div>

Andy

>
> Option 2: back to simple list of URIs
>
>=A0 =A0 =A0 container restconf {
>=A0 =A0 =A0 =A0 =A0container capabilities=A0 {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0leaf-list capability { same as in ietf-netco= nf-monitoring }
>=A0 =A0 =A0 =A0 =A0}
>=A0 =A0 =A0 }
>
>
> Option 3: Require implementation of the ietf-netconf-monitoring 'c= apability' node
>
>=A0 =A0 =A0 /restconf/data/netconf-state/capabilities/capability
>=A0 =A0 =A0 ** This probably requires a 6022bis to make the
>=A0 =A0 =A0 =A0 =A0 monitoring stats support NETCONF and RESTCONF
>
>
>=A0 ** 2 & 3 require URI definitions for each query parameter and o= fficial protocol capability
>
>
> ...
>
> >
> > The corollary to RESTCONF might be:
> >
> >=A0 =A0 =A0Base Support
> >=A0 =A0 =A0 =A0 =A0 =A0- the ability to GET and PUT on the top-lev= el node using XML only
> >
> >=A0 =A0 =A0Optional Support:
> >=A0 =A0 =A0 =A0 =A0 =A0- the ability to do PATCH=A0 (this is alrea= dy optional)
> >=A0 =A0 =A0 =A0 =A0 =A0- the ability to use JSON encoding
>
> I think XML and JSON should be given equal footing, i.e. the server > could support either or both. Perhaps the "Accept" header on= the client
> side and 406/415 status codes on the server side could be enough?
>
> This approach doesn't work if each person picks their pet options = to
> be mandatory.=A0 Everything is optional, even XML. One might want
> to support only JSON and not implement XML.

This is what I am saying.

Lada

>
> I would make read-only vs read-write vs read-create/delete 3 separate<= br> > capabilities (server MUST support 1 of them)
>
>=A0 =A0read-only: GET
>=A0 =A0read-write: GET, PUT
>=A0 =A0read-create: GET, POST, PUT, DELETE
>
> I think this aligns better with capabilities of constrained devices. >
>
>
> Lada
>
> >=A0 =A0 =A0 =A0 =A0 =A0- the ability to POST/GET/PUT/DELETE subtre= es=A0 =A0(PATCH too, is support for it is advertised)
> >=A0 =A0 =A0 =A0 =A0 =A0- the ability to use "select" wit= h GET operations
> >=A0 =A0 =A0 =A0 =A0 =A0- the ability to use "filter" wit= h GET on collection resources (i.e. lists) and event streams
> >=A0 =A0 =A0 =A0 =A0 =A0- the ability to do pagination with GET on = collection resources (i.e. lists)
> >=A0 =A0 =A0 =A0 =A0 =A0- the ability to do sorting with GET on col= lection resources (i.e. lists)
> >
>
> Some of these are traditionally client-side tasks.=A0 They should be o= ptional.
> HTTP already makes PATCH optional. All query parameters should be opti= onal.
>
>
>
> >
> > Thoughts?
> >
> > Thanks,
> > Kent
> >
>
> Andy
>

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





--001a1134497a6a626b050125e734-- From nobody Thu Aug 21 10:30:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0600E1A06D0 for ; Thu, 21 Aug 2014 10:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 mRri2Z72VyTZ for ; Thu, 21 Aug 2014 10:30:18 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32F21A0453 for ; Thu, 21 Aug 2014 10:30:17 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so9389228wgh.33 for ; Thu, 21 Aug 2014 10:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=74IyWbGPRqWhaGXOAnoyZ2pdvM1XJQHbHw5Fs60KO50=; b=jHiQP8kYkrSsqCTlzVfrx4cCRmaAJKDmGCZMVH+tiWx2/mAEr+K4HRlEyvWMyCnYtd 7i3xJLw8hoz6TnKfLaf7xyaXnlzotXFgKuFT1YTcg6u5GQik2hD078iLPQt1fmsWOAIT kRFpNp1EVlmpHfuWge8XUwMNrwhBaTnX1FgYnlSCkxY+kM/LUZMjPdV66SNgkRjJmTy6 wlRIpLOKMtrMGygVjfOJUsO4weWS1s3vJT6+DA5fEXMQJw/vg+zNP5fKLkguCH9B8bVE HTJqmxsNdKtaumjTZwmcYV7CRqi09CZEj2ksS+R7stqt9dIJcaRI1FspG4tL/ZSrS8Zz qMsg== MIME-Version: 1.0 X-Received: by 10.180.73.115 with SMTP id k19mr5782333wiv.35.1408642216313; Thu, 21 Aug 2014 10:30:16 -0700 (PDT) Received: by 10.195.13.201 with HTTP; Thu, 21 Aug 2014 10:30:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Aug 2014 19:30:16 +0200 Message-ID: From: Wojciech Dec To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=f46d043749cbeb47b50501271238 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Imyot8_2h3MG_m7Wi_FrJDaPSa4 Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:30:21 -0000 --f46d043749cbeb47b50501271238 Content-Type: text/plain; charset=UTF-8 On 21 August 2014 16:26, Ladislav Lhotka wrote: > Hi, > > Kent Watsen writes: > > > The RESTCONF authors recently discussed adding support for filtering, > > sorting, and paging collections (i.e. lists). One comment was that it > > was complex and better defined in another draft. I agree, but more > > importantly, RESTCONF should be fully modular, providing an ability > > for implementations to selectively advertise support for various > > things. This is exactly the approach we used for the NETCONF Light > > draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but > > RESTCONF being a new protocol, there is no reason to not do it from > > the get go. This strategy was discussed in Toronto, but we felt we > > should take it to the list before restructuring the document... > > I fully agree with this strategy. Support for individual capabilities > will be indicated somehow under the "restconf" resource? > > ... > > > > > The corollary to RESTCONF might be: > > > > Base Support > > - the ability to GET and PUT on the top-level node using XML > only > > > > Optional Support: > > - the ability to do PATCH (this is already optional) > > - the ability to use JSON encoding > > I think XML and JSON should be given equal footing, i.e. the server > could support either or both. Perhaps the "Accept" header on the client > side and 406/415 status codes on the server side could be enough? > +1 re XML and JSON on equal footing. > > Lada > > > - the ability to POST/GET/PUT/DELETE subtrees (PATCH too, is > support for it is advertised) > > - the ability to use "select" with GET operations > > - the ability to use "filter" with GET on collection resources > (i.e. lists) and event streams > > - the ability to do pagination with GET on collection > resources (i.e. lists) > > - the ability to do sorting with GET on collection resources > (i.e. lists) > > > > > > Thoughts? > > > > Thanks, > > Kent > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --f46d043749cbeb47b50501271238 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 21 August 2014 16:26, Ladislav Lhotka <lhotka@nic.cz>= wrote:
Hi,

Kent Watsen <kwatsen@juniper.net<= /a>> writes:

> The RESTCONF authors recently discussed adding support for filtering,<= br> > sorting, and paging collections (i.e. lists).=C2=A0 One comment was th= at it
> was complex and better defined in another draft.=C2=A0 I agree, but mo= re
> importantly, RESTCONF should be fully modular, providing an ability > for implementations to selectively advertise support for various
> things.=C2=A0 This is exactly the approach we used for the NETCONF Lig= ht
> draft (http://tools.ietf.org/html/draft-schoenw-netconf-l= ight-01), but
> RESTCONF being a new protocol, there is no reason to not do it from > the get go.=C2=A0 This strategy was discussed in Toronto, but we felt = we
> should take it to the list before restructuring the document...

I fully agree with this strategy. Support for individual capabilities=
will be indicated somehow under the "restconf" resource?

...

>
> The corollary to RESTCONF might be:
>
>=C2=A0 =C2=A0 =C2=A0Base Support
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- the ability to GET and PUT o= n the top-level node using XML only
>
>=C2=A0 =C2=A0 =C2=A0Optional Support:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- the ability to do PATCH=C2= =A0 (this is already optional)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- the ability to use JSON enco= ding

I think XML and JSON should be given equal footing, i.e. the server could support either or both. Perhaps the "Accept" header on the = client
side and 406/415 status codes on the server side could be enough?

+1 re XML and JSON on equal footing.=C2=A0
<= /div>

Lada

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- the ability to POST/GET/PUT/= DELETE subtrees=C2=A0 =C2=A0(PATCH too, is support for it is advertised) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- the ability to use "sel= ect" with GET operations
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- the ability to use "fil= ter" with GET on collection resources (i.e. lists) and event streams >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- the ability to do pagination= with GET on collection resources (i.e. lists)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- the ability to do sorting wi= th GET on collection resources (i.e. lists)
>
>
> Thoughts?
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--f46d043749cbeb47b50501271238-- From nobody Fri Aug 22 10:38:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FBE1A06C6 for ; Fri, 22 Aug 2014 10:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 X0wrNqLdRX0k for ; Fri, 22 Aug 2014 10:38:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF7C1A069E for ; Fri, 22 Aug 2014 10:38:03 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 22 Aug 2014 17:38:00 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.68]) with mapi id 15.00.1005.008; Fri, 22 Aug 2014 17:38:00 +0000 From: Kent Watsen To: Wojciech Dec , Ladislav Lhotka Thread-Topic: [Netconf] RESTCONF modularilty Thread-Index: AQHPt+FqdMjKJfbxJUGUd4a2DR/a/pvbJ/OAgAAzbgCAAVFuAA== Date: Fri, 22 Aug 2014 17:37:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(377454003)(199003)(189002)(51704005)(24454002)(4396001)(95666004)(81542001)(77982001)(20776003)(85852003)(105586002)(77096002)(107046002)(15975445006)(2656002)(19580395003)(106116001)(90102001)(99286002)(79102001)(101416001)(83506001)(19617315012)(80022001)(66066001)(76482001)(74502001)(50986999)(76176999)(31966008)(64706001)(86362001)(54356999)(81342001)(87936001)(46102001)(92726001)(99396002)(85306004)(83322001)(74662001)(21056001)(92566001)(575784001)(83072002)(16236675004)(15202345003)(106356001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D01CF7607F32Fkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/geTnMzzNtaOyZMDx-xnO5SXT5L0 Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:38:06 -0000 --_000_D01CF7607F32Fkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree XML/JSON should be on equal footing. I like Andy's idea of h= aving them both optional to implement. I can easily imagine cases where an= implementation only want to support a single encoding, perhaps one NETCONF= supports in the future. From: Wojciech Dec > Date: Thursday, August 21, 2014 at 1:30 PM To: Ladislav Lhotka > Cc: Kent Watsen >, NetConf = > Subject: Re: [Netconf] RESTCONF modularilty On 21 August 2014 16:26, Ladislav Lhotka > wrote: Hi, Kent Watsen > writes: > The RESTCONF authors recently discussed adding support for filtering, > sorting, and paging collections (i.e. lists). One comment was that it > was complex and better defined in another draft. I agree, but more > importantly, RESTCONF should be fully modular, providing an ability > for implementations to selectively advertise support for various > things. This is exactly the approach we used for the NETCONF Light > draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but > RESTCONF being a new protocol, there is no reason to not do it from > the get go. This strategy was discussed in Toronto, but we felt we > should take it to the list before restructuring the document... I fully agree with this strategy. Support for individual capabilities will be indicated somehow under the "restconf" resource? ... > > The corollary to RESTCONF might be: > > Base Support > - the ability to GET and PUT on the top-level node using XML on= ly > > Optional Support: > - the ability to do PATCH (this is already optional) > - the ability to use JSON encoding I think XML and JSON should be given equal footing, i.e. the server could support either or both. Perhaps the "Accept" header on the client side and 406/415 status codes on the server side could be enough? +1 re XML and JSON on equal footing. Lada > - the ability to POST/GET/PUT/DELETE subtrees (PATCH too, is = support for it is advertised) > - the ability to use "select" with GET operations > - the ability to use "filter" with GET on collection resources = (i.e. lists) and event streams > - the ability to do pagination with GET on collection resources= (i.e. lists) > - the ability to do sorting with GET on collection resources (i= .e. lists) > > > Thoughts? > > Thanks, > Kent > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_D01CF7607F32Fkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I also agree XML/JSON should be on equal footing.   I like Andy's= idea of having them both optional to implement.  I can easily imagine= cases where an implementation only want to support a single encoding, perh= aps one NETCONF supports in the future.


From: Wojciech Dec <wdec.ietf@gmail.com>
Date: Thursday, August 21, 2014 at = 1:30 PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Kent Watsen <kwatsen@juniper.net>, NetConf <netconf@ietf.org>
Subject: Re: [Netconf] RESTCONF mod= ularilty




On 21 August 2014 16:26, Ladislav Lhotka <lhotka@nic.cz>= ; wrote:
Hi,

Kent Watsen <kwatsen@juniper.net<= /a>> writes:

> The RESTCONF authors recently discussed adding support for filtering,<= br> > sorting, and paging collections (i.e. lists).  One comment was th= at it
> was complex and better defined in another draft.  I agree, but mo= re
> importantly, RESTCONF should be fully modular, providing an ability > for implementations to selectively advertise support for various
> things.  This is exactly the approach we used for the NETCONF Lig= ht
> draft (http://tools.ietf.org/html/draft-schoenw-netconf-l= ight-01), but
> RESTCONF being a new protocol, there is no reason to not do it from > the get go.  This strategy was discussed in Toronto, but we felt = we
> should take it to the list before restructuring the document...

I fully agree with this strategy. Support for individual capabilities
will be indicated somehow under the "restconf" resource?

...

>
> The corollary to RESTCONF might be:
>
>     Base Support
>           - the ability to GET and PUT o= n the top-level node using XML only
>
>     Optional Support:
>           - the ability to do PATCH = ; (this is already optional)
>           - the ability to use JSON enco= ding

I think XML and JSON should be given equal footing, i.e. the server
could support either or both. Perhaps the "Accept" header on the = client
side and 406/415 status codes on the server side could be enough?

+1 re XML and JSON on equal footing. 

Lada

>           - the ability to POST/GET/PUT/= DELETE subtrees   (PATCH too, is support for it is advertised) >           - the ability to use "sel= ect" with GET operations
>           - the ability to use "fil= ter" with GET on collection resources (i.e. lists) and event streams >           - the ability to do pagination= with GET on collection resources (i.e. lists)
>           - the ability to do sorting wi= th GET on collection resources (i.e. lists)
>
>
> Thoughts?
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

 --_000_D01CF7607F32Fkwatsenjunipernet_-- From nobody Fri Aug 22 10:44:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3011A069E for ; Fri, 22 Aug 2014 10:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 NLGYW0F0x8pt for ; Fri, 22 Aug 2014 10:44:17 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9425B1A067F for ; Fri, 22 Aug 2014 10:44:17 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x13so11130736qcv.26 for ; Fri, 22 Aug 2014 10:44:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oQc11Tbccp/Ot+RubD+4qA7eXwRCIunJ0fSeXawKYiQ=; b=kbe5RCofjwu2cu6cbFfUUlqeQeIotfvofFKYjm/FZCw90KfFwNmcMihvBC26yC/ZRK A4UMUqQMQphbD5rmNen0B1RtJ6O5QvlDQHGWl1AvvOznog6gZ+fza/ZHZOUJo4KfOK1g VN9iuoMcSH5OrJq98/1Q45DNReXMsgg0HEw+IP+rZ2ytgRnP9pJYye1CjFROuct/JAuG cNus88SK2CfX+/Da7pV4kShMsOxktKBcZXszMUDRRF9gq0ZDT3cffeil9DRxvWPcAGTM pi1snn0z2nA6ZbvAXZRJdMqq6sRNTB9qV6XzyERJKXEppSHzoVObfEbxHsR6ynAXS+IY qIsw== X-Gm-Message-State: ALoCoQmQ2stIlpDBLbULg9emGWIkyWjG3okCo220EbKpwME1Dxn/x6CYdWRO+uGYsAmuJXcFS8Nm MIME-Version: 1.0 X-Received: by 10.140.98.147 with SMTP id o19mr9474408qge.21.1408729451848; Fri, 22 Aug 2014 10:44:11 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 22 Aug 2014 10:44:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Aug 2014 10:44:11 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a113a923c8ffd1a05013b6212 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/z8x6Zf_JnuFh76P3CbqzVD8zYMU Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:44:20 -0000 --001a113a923c8ffd1a05013b6212 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 22, 2014 at 10:37 AM, Kent Watsen wrote: > > I also agree XML/JSON should be on equal footing. I like Andy's idea > of having them both optional to implement. I can easily imagine cases > where an implementation only want to support a single encoding, perhaps one > NETCONF supports in the future. > > NETCONF is problematic because of backward compatibility. That is why the NETCONF-EX "encoding" capability is part of the message. The first message needs to be XML encoding using base:1.0 message framing. Framing and encoding switch after the message. Andy > From: Wojciech Dec > Date: Thursday, August 21, 2014 at 1:30 PM > To: Ladislav Lhotka > Cc: Kent Watsen , NetConf > Subject: Re: [Netconf] RESTCONF modularilty > > > > > On 21 August 2014 16:26, Ladislav Lhotka wrote: > >> Hi, >> >> Kent Watsen writes: >> >> > The RESTCONF authors recently discussed adding support for filtering, >> > sorting, and paging collections (i.e. lists). One comment was that it >> > was complex and better defined in another draft. I agree, but more >> > importantly, RESTCONF should be fully modular, providing an ability >> > for implementations to selectively advertise support for various >> > things. This is exactly the approach we used for the NETCONF Light >> > draft (http://tools.ietf.org/html/draft-schoenw-netconf-light-01), but >> > RESTCONF being a new protocol, there is no reason to not do it from >> > the get go. This strategy was discussed in Toronto, but we felt we >> > should take it to the list before restructuring the document... >> >> I fully agree with this strategy. Support for individual capabilities >> will be indicated somehow under the "restconf" resource? >> >> ... >> >> > >> > The corollary to RESTCONF might be: >> > >> > Base Support >> > - the ability to GET and PUT on the top-level node using XML >> only >> > >> > Optional Support: >> > - the ability to do PATCH (this is already optional) >> > - the ability to use JSON encoding >> >> I think XML and JSON should be given equal footing, i.e. the server >> could support either or both. Perhaps the "Accept" header on the client >> side and 406/415 status codes on the server side could be enough? >> > > +1 re XML and JSON on equal footing. > >> >> Lada >> >> > - the ability to POST/GET/PUT/DELETE subtrees (PATCH too, >> is support for it is advertised) >> > - the ability to use "select" with GET operations >> > - the ability to use "filter" with GET on collection >> resources (i.e. lists) and event streams >> > - the ability to do pagination with GET on collection >> resources (i.e. lists) >> > - the ability to do sorting with GET on collection resources >> (i.e. lists) >> > >> > >> > Thoughts? >> > >> > Thanks, >> > Kent >> > >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a113a923c8ffd1a05013b6212 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 22, 2014 at 10:37 AM, Kent Watsen <= ;kwatsen@juniper.n= et> wrote:

I also agree XML/JSON should be on equal footing. =A0 I like Andy'= s idea of having them both optional to implement. =A0I can easily imagine c= ases where an implementation only want to support a single encoding, perhap= s one NETCONF supports in the future.


NETCONF is problemati= c because of backward compatibility.
That is why the NETCONF-EX &= quot;encoding" capability is part of the
<hello> messa= ge. =A0The first message needs to be XML encoding
using base:1.0 message framing. Framing and encoding switch after
the <hello> message.


An= dy




From: Wojciech Dec <wdec.ietf@gmail.com> Date: Thursday, August 21, 2014 at = 1:30 PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Kent Watsen <kwatsen@juniper.net>, NetC= onf <netconf@ietf.= org>
Subject: Re: [Netconf] RESTCONF mod= ularilty




On 21 August 2014 16:26, Ladislav Lhotka <lhotka@nic.cz>= ; wrote:
Hi,

Kent Watsen <kw= atsen@juniper.net> writes:

> The RESTCONF authors recently discussed adding support for filtering,<= br> > sorting, and paging collections (i.e. lists).=A0 One comment was that = it
> was complex and better defined in another draft.=A0 I agree, but more<= br> > importantly, RESTCONF should be fully modular, providing an ability > for implementations to selectively advertise support for various
> things.=A0 This is exactly the approach we used for the NETCONF Light<= br> > draft (http://tools.ietf.org/html/draft-schoenw-netconf-l= ight-01), but
> RESTCONF being a new protocol, there is no reason to not do it from > the get go.=A0 This strategy was discussed in Toronto, but we felt we<= br> > should take it to the list before restructuring the document...

I fully agree with this strategy. Support for individual capabilities
will be indicated somehow under the "restconf" resource?

...

>
> The corollary to RESTCONF might be:
>
>=A0 =A0 =A0Base Support
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to GET and PUT on the top-level no= de using XML only
>
>=A0 =A0 =A0Optional Support:
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to do PATCH=A0 (this is already op= tional)
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to use JSON encoding

I think XML and JSON should be given equal footing, i.e. the server
could support either or both. Perhaps the "Accept" header on the = client
side and 406/415 status codes on the server side could be enough?

+1 re XML and JSON on equal footing.=A0

Lada

>=A0 =A0 =A0 =A0 =A0 =A0- the ability to POST/GET/PUT/DELETE subtrees=A0= =A0(PATCH too, is support for it is advertised)
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to use "select" with GET= operations
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to use "filter" with GET= on collection resources (i.e. lists) and event streams
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to do pagination with GET on colle= ction resources (i.e. lists)
>=A0 =A0 =A0 =A0 =A0 =A0- the ability to do sorting with GET on collecti= on resources (i.e. lists)
>
>
> Thoughts?
>
> Thanks,
> Kent
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf

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

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--001a113a923c8ffd1a05013b6212-- From nobody Fri Aug 22 11:20:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE53B1A0455 for ; Fri, 22 Aug 2014 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 lHyPgnzCxhXA for ; Fri, 22 Aug 2014 11:20:32 -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 0648B1A06A6 for ; Fri, 22 Aug 2014 11:20:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 58C00E9C; Fri, 22 Aug 2014 20:20:30 +0200 (CEST) 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 NDydliWStYfm; Fri, 22 Aug 2014 20:20:07 +0200 (CEST) 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; Fri, 22 Aug 2014 20:20:29 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D179A20034; Fri, 22 Aug 2014 20:20:29 +0200 (CEST) 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 ko3RUO2UecBI; Fri, 22 Aug 2014 20:20:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00A2B20033; Fri, 22 Aug 2014 20:20:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 594812E38D5D; Fri, 22 Aug 2014 20:20:28 +0200 (CEST) Date: Fri, 22 Aug 2014 20:20:27 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140822182027.GA27962@elstar.local> Mail-Followup-To: Kent Watsen , Wojciech Dec , Ladislav Lhotka , NetConf 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/netconf/ySbm8r_Yp1DTnZZjOUcECL7DvII Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 18:20:37 -0000 On Fri, Aug 22, 2014 at 05:37:59PM +0000, Kent Watsen wrote: > > I also agree XML/JSON should be on equal footing. I like Andy's idea of having them both optional to implement. I can easily imagine cases where an implementation only want to support a single encoding, perhaps one NETCONF supports in the future. > Two compliant implementations that do not interoperate sounds like a bad idea to me. I think the WG needs to pick one encoding and make it mandatory to implement. /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 Fri Aug 22 11:28:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20A1A0AA3 for ; Fri, 22 Aug 2014 11:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tFyCCB3fNpi1 for ; Fri, 22 Aug 2014 11:28:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75871A096C for ; Fri, 22 Aug 2014 11:28:03 -0700 (PDT) Received: from BLUPR05CA0071.namprd05.prod.outlook.com (10.141.20.41) by DM2PR05MB733.namprd05.prod.outlook.com (10.141.178.18) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Fri, 22 Aug 2014 18:28:02 +0000 Received: from BL2FFO11FD008.protection.gbl (2a01:111:f400:7c09::177) by BLUPR05CA0071.outlook.office365.com (2a01:111:e400:855::41) with Microsoft SMTP Server (TLS) id 15.0.1015.17 via Frontend Transport; Fri, 22 Aug 2014 18:28:02 +0000 Received: from P-EMF01-SAC.jnpr.net (66.129.239.15) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Fri, 22 Aug 2014 18:28:01 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 22 Aug 2014 11:27:19 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s7MIRGn36221; Fri, 22 Aug 2014 11:27:16 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id s7MIR7am049505; Fri, 22 Aug 2014 14:27:07 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201408221827.s7MIR7am049505@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Fri, 22 Aug 2014 14:27:07 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.15; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(199003)(189002)(164054003)(81542001)(74502001)(99396002)(6806004)(1941001)(64706001)(85306004)(53416004)(103666002)(20776003)(77982001)(102836001)(44976005)(97736001)(47776003)(54356999)(83322001)(84676001)(90102001)(21056001)(68736004)(87936001)(74662001)(83072002)(69596002)(80022001)(50466002)(50986999)(31966008)(95666004)(107046002)(110136001)(85852003)(81156004)(105596002)(92566001)(79102001)(92726001)(76482001)(76506005)(81342001)(46102001)(4396001)(86362001)(48376002)(106466001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB733; H:P-EMF01-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 0311124FA9 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=phil@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iGKnrrVddMytSNRMreeS_dCCPDA Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 18:28:05 -0000 Kent Watsen writes: >I also agree XML/JSON should be on equal footing. I like Andy's idea of h= >aving them both optional to implement. I can easily imagine cases where an= > implementation only want to support a single encoding, perhaps one NETCONF= > supports in the future. Making them both optional-to-implement really means that any client that wants interoperability needs both, since it never knows which it will need, and any server that wants interoperability needs both, since it never knows which it will need. "Either" translates into "both" in the real world, making life harder, not easier. Thanks, Phil From nobody Fri Aug 22 11:42:14 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEC81A06D7 for ; Fri, 22 Aug 2014 11:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 eZB2RM2O2s0c for ; Fri, 22 Aug 2014 11:42:10 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535271A01F4 for ; Fri, 22 Aug 2014 11:42:10 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id z107so7364831qgd.9 for ; Fri, 22 Aug 2014 11:42:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wv3GOC1mK/vlNPoQx0yxIr8x8hRHr9TSS5bKztfXIaE=; b=EHKdL6WY9AkmQMS1xmxH705jZr/O3FLeNn58RAK6Q2/zm+Y4MFH3PCh8SosheB0abn t6ndGPKFprvTFOz7pc9Iow0vg8nhB5EpNgeDC6znmP45/rCt6ptTh0ym1lGX3/9tEPRg eKLQ3hASXdyn1Wbcf2F1jlLugVgm+Bkgwoh1Go4OjoUeL/MwCclQY8nwO8IiNKG9XPS0 g8ZrfJk8lqZ7VWIIL1+la0gR0uXL1VdoKowcMO3jvtMrCWwVhS/4BrRICIh9kUmlUqZx eV3q/GV3vJDLKNLGJfGysBIgEEUnsou8RjX2kz61vgjxOftpQHC5mcMxS26n4bH0+pu/ S65A== X-Gm-Message-State: ALoCoQkG1krmIAA9+8GrEmHYcdl4ILG07Ny84oPY5A9hR8PXCv29kOAXj0FNyuiq49K1VsMIBrSv MIME-Version: 1.0 X-Received: by 10.229.212.66 with SMTP id gr2mr10676199qcb.27.1408732929484; Fri, 22 Aug 2014 11:42:09 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 22 Aug 2014 11:42:09 -0700 (PDT) In-Reply-To: <201408221827.s7MIR7am049505@idle.juniper.net> References: <201408221827.s7MIR7am049505@idle.juniper.net> Date: Fri, 22 Aug 2014 11:42:09 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: multipart/alternative; boundary=001a11339b58d880f505013c314f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pAXDXzLkzIK7fp6KU9wHRrVpTyo Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 18:42:11 -0000 --001a11339b58d880f505013c314f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 22, 2014 at 11:27 AM, Phil Shafer wrote: > Kent Watsen writes: > >I also agree XML/JSON should be on equal footing. I like Andy's idea of > h= > >aving them both optional to implement. I can easily imagine cases where > an= > > implementation only want to support a single encoding, perhaps one > NETCONF= > > supports in the future. > > Making them both optional-to-implement really means that any client > that wants interoperability needs both, since it never knows which > it will need, and any server that wants interoperability needs both, > since it never knows which it will need. "Either" translates into > "both" in the real world, making life harder, not easier. > > I agree the client will end up implementing both, but a constrained server might not implement both. "equal footing" means both are mandatory or both are optional. Currently both are mandatory and XML is the default. Making one encoding mandatory would be more efficient for constrained devices, but that assumes we can pick 1. I would pick XML over JSON as mandatory, since it handles attributes and an inline (streaming) implementation is much easier. > Thanks, > Phil > > Andy --001a11339b58d880f505013c314f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 22, 2014 at 11:27 AM, Phil Shafer <= ;phil@juniper.net= > wrote:
Kent Watsen writes:
>I also agree XML/JSON should be on equal footing.=A0 =A0I like Andy'= ;s idea of h=3D
>aving them both optional to implement.=A0 I can easily imagine cases wh= ere an=3D
> implementation only want to support a single encoding, perhaps one NET= CONF=3D
> supports in the future.

Making them both optional-to-implement really means that any client
that wants interoperability needs both, since it never knows which
it will need, and any server that wants interoperability needs both,
since it never knows which it will need.=A0 "Either" translates i= nto
"both" in the real world, making life harder, not easier.



I agree the client will= end up implementing both, but a constrained server might not
imp= lement both. "equal footing" means both are mandatory or both are= optional.
Currently both are mandatory and XML is the default.

Making one encoding mandatory would be more efficient for constrain= ed devices,
but that assumes we can pick 1. =A0I would pick XML o= ver JSON as mandatory,
since it handles attributes and an inline (streaming) implementation i= s much easier.

=A0
Thanks,
=A0Phil



Andy
=A0
--001a11339b58d880f505013c314f-- From nobody Fri Aug 22 13:12:43 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684AA1A0B13 for ; Fri, 22 Aug 2014 13:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9mWifBAUBqcW for ; Fri, 22 Aug 2014 13:12:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66AA1A0ACC for ; Fri, 22 Aug 2014 13:12:38 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB361.namprd05.prod.outlook.com (10.141.51.148) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 22 Aug 2014 20:12:30 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.68]) with mapi id 15.00.1005.008; Fri, 22 Aug 2014 20:12:30 +0000 From: Kent Watsen To: Andy Bierman , Phil Shafer Thread-Topic: [Netconf] RESTCONF modularilty Thread-Index: AQHPt+FqdMjKJfbxJUGUd4a2DR/a/pvbJ/OAgAAzbgCAAVFuAIAAUMmAgAAEM4D//9YuAA== Date: Fri, 22 Aug 2014 20:12:29 +0000 Message-ID: References: <201408221827.s7MIR7am049505@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(189002)(1941001)(74502001)(76176999)(83322001)(54356999)(74662001)(81542001)(50986999)(79102001)(77096002)(31966008)(16236675004)(90102001)(99396002)(106356001)(77982001)(92726001)(101416001)(4396001)(36756003)(87936001)(80022001)(2656002)(66066001)(76482001)(83506001)(105586002)(107046002)(95666004)(99286002)(21056001)(85306004)(83072002)(106116001)(46102001)(81342001)(64706001)(92566001)(20776003)(85852003)(86362001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB361; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D01D1AB47F463kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/uMAPQDlSd7mskBfEX5sDy1hblTg Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:12:41 -0000 --_000_D01D1AB47F463kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I agree the client will end up implementing both, but a constrained serve= r might not > implement both. "equal footing" means both are mandatory or both are opti= onal. > Currently both are mandatory and XML is the default. "both optional" does mean that clients have to support both. The servers = reap the benefit in needing to implement support only one, which is importa= nt for constrained devices. Do we think "both mandatory" is OK for all ser= vers? K. --_000_D01D1AB47F463kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <34FC2381B4A39E4EB0EC0B0AF710C983@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

> I agree the client will end up implementing both, but a constrained se= rver might not
> implement both. "equal footing" means both are mandatory or = both are optional.
> Currently both are mandatory and XML is the default.

"both optional" does mean = that clients have to support both.   The servers reap the benefit in n= eeding to implement support only one, which is important for constrained de= vices.  Do we think "both mandatory" is OK for all servers?  

K.
--_000_D01D1AB47F463kwatsenjunipernet_-- From nobody Fri Aug 22 14:28:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA2A1A6F6D for ; Fri, 22 Aug 2014 14:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 3uD_3jTNhlPH for ; Fri, 22 Aug 2014 14:28:53 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822E51A0ADA for ; Fri, 22 Aug 2014 14:28:53 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id z107so7462990qgd.0 for ; Fri, 22 Aug 2014 14:28:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZyWULJxFw2bX6hjqX8bfc6YJlZpqKAe86NjaqQ45yi4=; b=i7GswQKH0/qAegWi9KcqMyklL8rP8xfOwc/Z1YoR018uCgVhI5BDxNcI3BknlCStxS qAk/TvhtbBW45allmqkjtEc53fr85UZpbwU4OmsmdJGgbXLAD4tPWhAmTw7SEegyykmo IumqQ/O6lvSLUySGdaNykJnKUP5ycng/tUIV2yB4oWS5pFyw2dKtAKk5rWplQkUvKgGc hmokSC43CQKugGSb7fKhNvbk1SAqyvNXzE4YB0O8j4Cqf5Rre9GGz9fTHnaLUtUS216Y J/aXY15wpdimX+GeF+DInkcqkSX4sXrJS1vHRtTLxUilu1SBXNnxNO+qK0PWkos8WqJm sW7A== X-Gm-Message-State: ALoCoQleuGc0ANi8c5uJtWVsSxXPZ2A15B1ssfd+H2dDfsU3UT4f8XPFODtgcIeyCNj43Sq7BzOJ MIME-Version: 1.0 X-Received: by 10.224.112.1 with SMTP id u1mr12052326qap.7.1408742932501; Fri, 22 Aug 2014 14:28:52 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 22 Aug 2014 14:28:52 -0700 (PDT) In-Reply-To: References: <201408221827.s7MIR7am049505@idle.juniper.net> Date: Fri, 22 Aug 2014 14:28:52 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=047d7b673a4e126f2e05013e8692 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6Zov6tJA78Ra1q2KlmxyUOVTQ5w Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:28:55 -0000 --047d7b673a4e126f2e05013e8692 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen wrote: > > > I agree the client will end up implementing both, but a constrained > server might not > > implement both. "equal footing" means both are mandatory or both are > optional. > > Currently both are mandatory and XML is the default. > > "both optional" does mean that clients have to support both. The > servers reap the benefit in needing to implement support only one, which is > important for constrained devices. Do we think "both mandatory" is OK for > all servers? > > What are the alternatives? mandatory for the client to implement both? mandatory for the server to implement at least one? This means the client has to retrieve the server capabilities before sending any requests with a message body? (Or just try 1 format and if it fails, assume the other will work?) Another option: server SHOULD implement both; MAY implement one if resource constrained K. > Andy --047d7b673a4e126f2e05013e8692 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen <= kwatsen@juniper.ne= t> wrote:

> I agree the client will end up implementing both, but a constrained se= rver might not
> implement both. "equal footing" means both are mandatory or = both are optional.
> Currently both are mandatory and XML is the default.

"both optional" does mean = that clients have to support both. =A0 The servers reap the benefit in need= ing to implement support only one, which is important for constrained devic= es. =A0Do we think "both mandatory" is OK for all servers? =A0


What ar= e the alternatives?
mandatory for the client to implement both?
mandatory for the server to implement at least one?
This means the client has to retrieve the server capabilities
bef= ore sending any requests with a message body?
(Or just try 1 form= at and if it fails, assume the other will work?)

Another option:
=A0 =A0server SHOULD implement both; MAY implemen= t one if resource constrained


K.

Andy
--047d7b673a4e126f2e05013e8692-- From nobody Sun Aug 24 14:18:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B6B1A0AEE for ; Sun, 24 Aug 2014 14:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 pNx62o1WaDJp for ; Sun, 24 Aug 2014 14:18:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5671A884A for ; Sun, 24 Aug 2014 14:18:46 -0700 (PDT) Received: from DM2PR05MB461.namprd05.prod.outlook.com (10.141.105.15) by DM2PR05MB365.namprd05.prod.outlook.com (10.141.98.13) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Sun, 24 Aug 2014 21:18:43 +0000 Received: from DM2PR05MB461.namprd05.prod.outlook.com ([169.254.9.97]) by DM2PR05MB461.namprd05.prod.outlook.com ([169.254.9.97]) with mapi id 15.00.1010.016; Sun, 24 Aug 2014 21:18:43 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] RESTCONF modularilty Thread-Index: AQHPt+FqdMjKJfbxJUGUd4a2DR/a/pvbJ/OAgAAzbgCAAVFuAIAAUMmAgAAEM4D//9YuAIAAWGcAgALewgA= Date: Sun, 24 Aug 2014 21:18:43 +0000 Message-ID: References: <201408221827.s7MIR7am049505@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03137AC81E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(189002)(21056001)(87936001)(92726001)(81542001)(92566001)(83072002)(83506001)(36756003)(85852003)(2656002)(95666004)(80022001)(81342001)(50986999)(99286002)(66066001)(16236675004)(107046002)(86362001)(64706001)(20776003)(46102001)(79102001)(77096002)(85306004)(76176999)(76482001)(83322001)(4396001)(54356999)(93886004)(105586002)(106356001)(110136001)(77982001)(106116001)(90102001)(31966008)(101416001)(74662001)(99396002)(74502001)(558084003); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB365; H:DM2PR05MB461.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D01FCE307F515kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/TYf1PIJX0NHaTRW8G-aeLtbODSw Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 21:18:48 -0000 --_000_D01FCE307F515kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Another option: > server SHOULD implement both; MAY implement one if resource constrained +1 - and the server MUST advertise which encoding(s) it supports, at lea= st one. Kent --_000_D01FCE307F515kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <30F14844B307264FB20FBA773ABF4DA3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

> Another option:
>   server SHOULD implement both; MAY implement one if resourc= e constrained

+1    - and the server MUST advertise which encoding(s) = it supports, at least one.

Kent






--_000_D01FCE307F515kwatsenjunipernet_-- From nobody Sun Aug 24 23:51:35 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E3D1A8AA7 for ; Sun, 24 Aug 2014 23:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 JGjRbXF2T-AZ for ; Sun, 24 Aug 2014 23:51:32 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D39A1A6FC4 for ; Sun, 24 Aug 2014 23:51:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6EE9B5407C7; Mon, 25 Aug 2014 08:51:29 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp8BtAE5Ov8d; Mon, 25 Aug 2014 08:51:25 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 54D79540396; Mon, 25 Aug 2014 08:51:24 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , Andy Bierman In-Reply-To: References: <201408221827.s7MIR7am049505@idle.juniper.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 25 Aug 2014 08:51:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/m4eozSMbX6K1m1gLSZttUJZKD8Y Cc: NetConf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 06:51:34 -0000 Kent Watsen writes: >> Another option: >> server SHOULD implement both; MAY implement one if resource constrained > > +1 - and the server MUST advertise which encoding(s) it supports, > at least one. +1, and the client SHOULD implement both. The strategy "everything is optional" leads to a similar situation in other cases, too, for example YANG Patch versus JSON Patch (or perhaps even versus things like XQuery Update). We are potentially addressing a huge range of devices, so finding any common denominator on the server side might be impossible. Lada > > Kent > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 25 11:51:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1261A0295 for ; Mon, 25 Aug 2014 11:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 pTd6xlTzEyIx for ; Mon, 25 Aug 2014 11:50:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6E21A01BA for ; Mon, 25 Aug 2014 11:50:59 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 9D87712809D5; Mon, 25 Aug 2014 20:48:30 +0200 (CEST) Date: Mon, 25 Aug 2014 20:50:54 +0200 (CEST) Message-Id: <20140825.205054.364839469.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4WSLrC-zf1lTTCkQebDbXOVnoJM Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:51:00 -0000 Andy Bierman wrote: > On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen wrote: > > > > > > I agree the client will end up implementing both, but a constrained > > server might not > > > implement both. "equal footing" means both are mandatory or both are > > optional. > > > Currently both are mandatory and XML is the default. > > > > "both optional" does mean that clients have to support both. The > > servers reap the benefit in needing to implement support only one, which is > > important for constrained devices. Do we think "both mandatory" is OK for > > all servers? > > > > > What are the alternatives? > mandatory for the client to implement both? > mandatory for the server to implement at least one? > This means the client has to retrieve the server capabilities > before sending any requests with a message body? > (Or just try 1 format and if it fails, assume the other will work?) > > Another option: > server SHOULD implement both; MAY implement one if resource constrained The goal is still interoperability. So why not simply: server MUST implement XML and SHOULD implement JSON. /martin From nobody Mon Aug 25 12:25:49 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC751A02C1 for ; Mon, 25 Aug 2014 12:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 LLqvkLetb-HR for ; Mon, 25 Aug 2014 12:25:44 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74271A0262 for ; Mon, 25 Aug 2014 12:25:43 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so13521402qga.36 for ; Mon, 25 Aug 2014 12:25:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=20WyS9xCst27NUHTQ/SWUfdU/PV2eOl65jHX53Ne8bw=; b=B8hbux18wPuScnAGeU5MKKPy30MAHu+k3p9mQxcLIEQNY1LeoqQZaktQDXydgMdFgo FuL1vO0nZLMG8/SE+6kzezVB8wntvZS+Eh1UjFi5xa+4n3dgSnZVpKsHraggurN7mdHR bwjeuARW/TGW0ZOfdiqa4dlfLpDkGaJ0VpNlDIwx/nBfqg6th1Pvng11SjBAeoi/hzKf hZ2xeD+/eV1jiw8ebwJvJe/o4MwRDIP5uC8JYd24I3HeOYVTGqTwJVqRNcp6Z9HW+ycc dW2G7RoeAq6y2silcHscL1EbUZaxhmuNf0BmneY1iX2tZWMDc1w1mbo8Ut63YaUFHxMX YzTQ== X-Gm-Message-State: ALoCoQmYmg0CVxUNfAF/8+oYuVuXdrptlkr3IbnRt4bf+lYPDVwoSiWF/SQeNahsS+WcI6P+21sq MIME-Version: 1.0 X-Received: by 10.140.95.101 with SMTP id h92mr36215219qge.35.1408994742906; Mon, 25 Aug 2014 12:25:42 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 25 Aug 2014 12:25:42 -0700 (PDT) In-Reply-To: <20140825.205054.364839469.mbj@tail-f.com> References: <20140825.205054.364839469.mbj@tail-f.com> Date: Mon, 25 Aug 2014 12:25:42 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c15c5025061c05017927ce Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eLaQjAh8-TQwE4m_Mv-_4XjC-RU Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:25:46 -0000 --001a11c15c5025061c05017927ce Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 25, 2014 at 11:50 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen > wrote: > > > > > > > > > I agree the client will end up implementing both, but a constrained > > > server might not > > > > implement both. "equal footing" means both are mandatory or both > are > > > optional. > > > > Currently both are mandatory and XML is the default. > > > > > > "both optional" does mean that clients have to support both. The > > > servers reap the benefit in needing to implement support only one, > which is > > > important for constrained devices. Do we think "both mandatory" is OK > for > > > all servers? > > > > > > > > What are the alternatives? > > mandatory for the client to implement both? > > mandatory for the server to implement at least one? > > This means the client has to retrieve the server capabilities > > before sending any requests with a message body? > > (Or just try 1 format and if it fails, assume the other will work?) > > > > Another option: > > server SHOULD implement both; MAY implement one if resource > constrained > > The goal is still interoperability. So why not simply: > > server MUST implement XML and SHOULD implement JSON. > > > MUST implement XML, SHOULD implement JSON does not put XML and JSON on "equal footing" as Lada requested -- but I could agree to this -- if we have to pick a mandatory-to-implement, I would pick XML over JSON. I agree there is operations impact because the client has to figure out what the server supports before it can send it any data. But supporting multiple formats is heavyweight. We don't seem to have any real justification for using 2 encoding formats. It is quite an implementation burden for the server to provide equivalent functionality in both JSON and XML format. (Consider distributed servers that stream the reply and do not build a static "document" in memory that can be translated on output). The justification seems to be that we do not want to pick between XML and JSON so they are both mandatory. /martin > Andy --001a11c15c5025061c05017927ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Aug 25, 2014 at 11:50 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> >
> >=A0 > I agree the client will end up implementing both, but a c= onstrained
> > server might not
> >=A0 =A0 > implement both. "equal footing" means both = are mandatory or both are
> > optional.
> >=A0 > Currently both are mandatory and XML is the default.
> >
> >=A0 "both optional" does mean that clients have to suppo= rt both.=A0 =A0The
> > servers reap the benefit in needing to implement support only one= , which is
> > important for constrained devices.=A0 Do we think "both mand= atory" is OK for
> > all servers?
> >
> >
> What are the alternatives?
> mandatory for the client to implement both?
> mandatory for the server to implement at least one?
> This means the client has to retrieve the server capabilities
> before sending any requests with a message body?
> (Or just try 1 format and if it fails, assume the other will work?) >
> Another option:
>=A0 =A0 server SHOULD implement both; MAY implement one if resource con= strained

The goal is still interoperability.=A0 So why not simply:

=A0 server MUST implement XML and SHOULD implement JSON.



MUST implement XML, SHOU= LD implement JSON does not put XML and JSON on
"equal footin= g" as Lada requested -- but I could agree to this -- if we have to
pick a mandatory-to-implement, I would pick XML over JSON.
<= br>
I agree there is operations impact because the client has to = figure out what the
server supports before it can send it any dat= a. But supporting multiple formats is heavyweight.

We don't seem to have any real justification for us= ing 2 encoding formats.
It is quite an implementation burden for = the server to provide equivalent functionality
in both JSON and X= ML format. (Consider distributed servers that stream the reply
and do not build a static "document" in memory that can be t= ranslated on output).
The justification seems to be that we do no= t want to pick between XML and JSON so
they are both mandatory.



/martin

Andy<= /div>

--001a11c15c5025061c05017927ce-- From nobody Mon Aug 25 12:50:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBE21A02F9 for ; Mon, 25 Aug 2014 12:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 OfKrHucApSCc for ; Mon, 25 Aug 2014 12:50:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A1B1A02F6 for ; Mon, 25 Aug 2014 12:50:24 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 1EBA9141B96; Mon, 25 Aug 2014 21:50:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1408996222; bh=NwVmjiNhNXKOC+I7vXmL5ZO2YfXN3hyg9slSDoKctBk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vdZLYD/qpK/cAbe/u4+6OX53u1PzdzzK8m8WA4Gm9agVzBEM0CYzReilSOZBlqSIg sJXi9HVK9CarkX9acpwmeAu67mt8RmAbGwUcdgWz9iquSisCHknY9pUsyl4pwPg+2x DBrAEMHVcSMrd/300PxxEc4hWUjDoE1NtGHIUVyo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140825.205054.364839469.mbj@tail-f.com> Date: Mon, 25 Aug 2014 21:50:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> References: <20140825.205054.364839469.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/TRYdbJLLQY78Bq3wcn_-IJnm3Fs Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:50:28 -0000 On 25 Aug 2014, at 20:50, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen = wrote: >>=20 >>>=20 >>>> I agree the client will end up implementing both, but a constrained >>> server might not >>>> implement both. "equal footing" means both are mandatory or both = are >>> optional. >>>> Currently both are mandatory and XML is the default. >>>=20 >>> "both optional" does mean that clients have to support both. The >>> servers reap the benefit in needing to implement support only one, = which is >>> important for constrained devices. Do we think "both mandatory" is = OK for >>> all servers? >>>=20 >>>=20 >> What are the alternatives? >> mandatory for the client to implement both? >> mandatory for the server to implement at least one? >> This means the client has to retrieve the server capabilities >> before sending any requests with a message body? >> (Or just try 1 format and if it fails, assume the other will work?) >>=20 >> Another option: >> server SHOULD implement both; MAY implement one if resource = constrained >=20 > The goal is still interoperability. So why not simply: >=20 > server MUST implement XML and SHOULD implement JSON. It would probably make more sense the other way around as for = constrained devices JSON is generally much easier to deal with than XML. Lada >=20 >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 25 16:34:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C821A0494 for ; Mon, 25 Aug 2014 16:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 eqsd450E3i81 for ; Mon, 25 Aug 2014 16:34:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFC11A040D for ; Mon, 25 Aug 2014 16:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1982; q=dns/txt; s=iport; t=1409009648; x=1410219248; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=nMklqlRbakiYRnOMb78FZPm8jo0uuhIrPLSqrQ5rqKk=; b=FC3D2GjUzrxGqtfMiXW2O7KWAnSaO12zxd8lnBTcqJ/7sxZrKwRvfq2T h0QYd/lyyMMMk7cTLSAriCrDM6ynOPjGDjp7SD6ckl4mDYVnxjTKs337F HtJhanH9jN0qKBeEMePum+eiXkYCMD6mg10EU4fmjZGt2XxXBRLChkn/P Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAIHH+1OtJA2L/2dsb2JhbABZgw1TVwTMTAqGelMBgR4Wd4QEAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTAGDQYCAQGIPg2/QxMEj1MWhDYFiyKRJ4cvjV2DfkyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,400,1406592000"; d="scan'208";a="350159100" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 25 Aug 2014 23:34:08 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7PNY76G007529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 23:34:07 GMT Received: from [10.21.64.225] (10.21.64.225) by xhc-rcd-x04.cisco.com (173.37.183.78) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 Aug 2014 18:34:06 -0500 Message-ID: <53FBC7F1.4080706@cisco.com> Date: Mon, 25 Aug 2014 16:34:09 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> In-Reply-To: <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.21.64.225] Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/BpLEf03bYVvzNxUGDtdJTK_uouI Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 23:34:10 -0000 Hi, I would also support JSON being at least equal footing with XML. Ideally being MTI. thanks, Reinaldo On 8/25/14 12:50 PM, Ladislav Lhotka wrote: > On 25 Aug 2014, at 20:50, Martin Bjorklund wrote: > >> Andy Bierman wrote: >>> On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen wrote: >>> >>>>> I agree the client will end up implementing both, but a constrained >>>> server might not >>>>> implement both. "equal footing" means both are mandatory or both are >>>> optional. >>>>> Currently both are mandatory and XML is the default. >>>> "both optional" does mean that clients have to support both. The >>>> servers reap the benefit in needing to implement support only one, which is >>>> important for constrained devices. Do we think "both mandatory" is OK for >>>> all servers? >>>> >>>> >>> What are the alternatives? >>> mandatory for the client to implement both? >>> mandatory for the server to implement at least one? >>> This means the client has to retrieve the server capabilities >>> before sending any requests with a message body? >>> (Or just try 1 format and if it fails, assume the other will work?) >>> >>> Another option: >>> server SHOULD implement both; MAY implement one if resource constrained >> The goal is still interoperability. So why not simply: >> >> server MUST implement XML and SHOULD implement JSON. > It would probably make more sense the other way around as for constrained devices JSON is generally much easier to deal with than XML. > > Lada > >> >> /martin >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Aug 25 17:33:01 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631401A04BC for ; Mon, 25 Aug 2014 17:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 A86N0rOEaV8S for ; Mon, 25 Aug 2014 17:32:54 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39201A04F6 for ; Mon, 25 Aug 2014 17:32:54 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x13so14566608qcv.26 for ; Mon, 25 Aug 2014 17:32:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ynEXNgBM0Hm7ueb2Bd8T/cl29sqB33U/eySBAN1SpZc=; b=WgKzXFWJiNLW2Bf3iM/Mb//mfLeyhRuw/+mRwBVZEjI/VmQtkYazdm+s7m8lkp9bQh nR358sekUtXo0+Yyxe0RIcH0EcePJiaIdj3jGNve4+CmWNhjwYVoGYvweb6CyOiznKwV +E7ID8mWOJK4M+/R/hHLfwF6xzFkTXz/qmKUa4d3RhRzSk0SyNCwTsmOpRtnOY7S+Fzm 5rt8rfdZNT14qSKNS2rCDVEw76/Uj2rIrsM0+nrY4n0qwue+iEKRMxVW3cMOcWS3tI8q eyvbi0dHmz1Xakkqv8uzS57NLHD2D8lPZ2XOE0II1CraTFw93S32Xyg5t7fpdFTEwmzk nSbg== X-Gm-Message-State: ALoCoQmFH3ikCWcWwV0+KatBZCfN/fexottclADKKQ7Z/QUMJUjL/fzQtuYQSIy+0j1b7ktcZMh3 MIME-Version: 1.0 X-Received: by 10.224.88.137 with SMTP id a9mr42143844qam.88.1409013173751; Mon, 25 Aug 2014 17:32:53 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 25 Aug 2014 17:32:53 -0700 (PDT) In-Reply-To: <53FBC7F1.4080706@cisco.com> References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> Date: Mon, 25 Aug 2014 17:32:53 -0700 Message-ID: From: Andy Bierman To: Reinaldo Penno Content-Type: multipart/alternative; boundary=001a11c2bbc0b4cb0605017d71f4 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/c9U2NQrU6bfNsLT8D-HsbasDKco Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 00:32:57 -0000 --001a11c2bbc0b4cb0605017d71f4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 25, 2014 at 4:34 PM, Reinaldo Penno wrote: > Hi, > > I would also support JSON being at least equal footing with XML. Ideally > being MTI. > > IMO 2 mandatory encoding formats is overkill. RESTCONF is supposed to be lightweight compared to NETCONF, and NETCONF does not require more than 1 encoding format. XML is a mature standard. It supports namespaces and attributes. The YANG-to-JSON standard is still an work-in-progress with no full implementations. I don't see why the server SHOULD or MUST implement multiple formats. Seems like that is moving the complexity from the client to the server. Since there are many more servers (and they may be constrained) this seems like the wrong place to dump complexity for the sake of client flexibility. I think a constrained server should only need 1 encoding format, and I could see how the vendor could choose JSON over XML. But implementation details are usually left out of standards. That is why my first choice is not to pick a mandatory between XML and JSON. thanks, > > Reinaldo > > Andy > On 8/25/14 12:50 PM, Ladislav Lhotka wrote: > >> On 25 Aug 2014, at 20:50, Martin Bjorklund wrote: >> >> Andy Bierman wrote: >>> >>>> On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen >>>> wrote: >>>> >>>> I agree the client will end up implementing both, but a constrained >>>>>> >>>>> server might not >>>>> >>>>>> implement both. "equal footing" means both are mandatory or both are >>>>>> >>>>> optional. >>>>> >>>>>> Currently both are mandatory and XML is the default. >>>>>> >>>>> "both optional" does mean that clients have to support both. The >>>>> servers reap the benefit in needing to implement support only one, >>>>> which is >>>>> important for constrained devices. Do we think "both mandatory" is OK >>>>> for >>>>> all servers? >>>>> >>>>> >>>>> What are the alternatives? >>>> mandatory for the client to implement both? >>>> mandatory for the server to implement at least one? >>>> This means the client has to retrieve the server capabilities >>>> before sending any requests with a message body? >>>> (Or just try 1 format and if it fails, assume the other will work?) >>>> >>>> Another option: >>>> server SHOULD implement both; MAY implement one if resource >>>> constrained >>>> >>> The goal is still interoperability. So why not simply: >>> >>> server MUST implement XML and SHOULD implement JSON. >>> >> It would probably make more sense the other way around as for constrained >> devices JSON is generally much easier to deal with than XML. >> >> Lada >> >> >>> /martin >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c2bbc0b4cb0605017d71f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Aug 25, 2014 at 4:34 PM, Reinaldo Penno &= lt;repenno@cisco.com= > wrote:
Hi,

I would also support JSON being at least equal footing with XML. Ideally be= ing MTI.


IMO 2 mandatory encoding formats is ov= erkill.
RESTCONF is supposed to be lightweight compared to NETCON= F,
and NETCONF does not require more than 1 encoding format.

XML is a mature standard. =A0It supports namespaces and= attributes.
The YANG-to-JSON standard is still an work-in-progre= ss with no
full implementations.

I don&#= 39;t see why the server SHOULD or MUST implement multiple formats.
Seems like that is moving the complexity from the client to the server= .
Since there are many more servers (and they may be constrained)=
this seems like the wrong place to dump complexity for the sake = of client flexibility.

I think a constrained server should only need 1 encodin= g format, and I could
see how the vendor could choose JSON over X= ML. =A0But implementation details
are usually left out of standar= ds. That is why my first choice
is not to pick a mandatory between XML and JSON.

<= div>
thanks,

Reinaldo


Andy


=A0
On 8/25/14 12:50 PM, Ladislav Lhotka wrote:
On 25 Aug 2014, at 20:50, Martin Bjorklund <mbj@tail-f.com> wrote:

Andy Bierman <an= dy@yumaworks.com> wrote:
On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen <kwatsen@juniper.net> wrote:

I agree the client will end up implementing both, but a constrained
server might not
implement both. "equal footing" means both are mandatory or both = are
optional.
Currently both are mandatory and XML is the default.
"both optional" does mean that clients have to support both.=A0 = =A0The
servers reap the benefit in needing to implement support only one, which is=
important for constrained devices.=A0 Do we think "both mandatory"= ; is OK for
all servers?


What are the alternatives?
mandatory for the client to implement both?
mandatory for the server to implement at least one?
This means the client has to retrieve the server capabilities
before sending any requests with a message body?
(Or just try 1 format and if it fails, assume the other will work?)

Another option:
=A0 =A0server SHOULD implement both; MAY implement one if resource constrai= ned
The goal is still interoperability.=A0 So why not simply:

=A0 server MUST implement XML and SHOULD implement JSON.
It would probably make more sense the other way around as for constrained d= evices JSON is generally much easier to deal with than XML.

Lada


/martin

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--001a11c2bbc0b4cb0605017d71f4-- From nobody Mon Aug 25 18:01:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24431A058E for ; Mon, 25 Aug 2014 18:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 THRhkmuZrsT0 for ; Mon, 25 Aug 2014 18:01:12 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE0B1A055D for ; Mon, 25 Aug 2014 18:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14348; q=dns/txt; s=iport; t=1409014871; x=1410224471; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=xoKDDz7futiZEav89oJk6Rft1cbU1DyahHcYZPOqaKU=; b=bp9RcEq2F/GLeY/JjnfJrJhVwP6Bonl5LKhJHc3VWWD8mlMZ1aTQ2bX/ JVHC3BJX6vQnXdo6tZR8Bd9vbY1+rXDRqNr50aZ5pPUmyccfbfFx++uHs RTPPqAn6gbUdTelKchJ9Qic9gzfHUC1LAefWfmbrldUYGYK0/yj/gCVjI E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAPLb+1OtJV2Z/2dsb2JhbABZgw1TVwTMRwEJhnpTAYEbFneEAwEBAQMBAQEBawoBBQsLGAkWCAcJAwIBAgEVHxEGDQEFAgEBiDYIDb8kEwSPTAeETAWLIoNxjTaHL41dg35MgUiBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,400,1406592000"; d="scan'208,217"; a="72281135" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 26 Aug 2014 01:01:00 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7Q110xq006043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 01:01:00 GMT Received: from [10.21.94.61] (10.21.94.61) by xhc-rcd-x07.cisco.com (173.37.183.81) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 Aug 2014 20:00:59 -0500 Message-ID: <53FBDC4A.9020106@cisco.com> Date: Mon, 25 Aug 2014 18:00:58 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Andy Bierman References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040205070306020003010904" X-Originating-IP: [10.21.94.61] Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/r4pzHtAavVxxFzTQXGNRJ3p_dqU Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 01:01:22 -0000 --------------040205070306020003010904 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 8/25/14 5:32 PM, Andy Bierman wrote: > > > > On Mon, Aug 25, 2014 at 4:34 PM, Reinaldo Penno > wrote: > > Hi, > > I would also support JSON being at least equal footing with XML. > Ideally being MTI. > > > IMO 2 mandatory encoding formats is overkill. > RESTCONF is supposed to be lightweight compared to NETCONF, [RP] Then JSON is the perfect choice. > and NETCONF does not require more than 1 encoding format. > > XML is a mature standard. It supports namespaces and attributes. > The YANG-to-JSON standard is still an work-in-progress with no > full implementations. > > I don't see why the server SHOULD or MUST implement multiple formats. > Seems like that is moving the complexity from the client to the server. > Since there are many more servers (and they may be constrained) > this seems like the wrong place to dump complexity for the sake of > client flexibility. > > I think a constrained server should only need 1 encoding format, and I > could > see how the vendor could choose JSON over XML. But implementation details > are usually left out of standards. That is why my first choice > is not to pick a mandatory between XML and JSON. > > > thanks, > > Reinaldo > > > Andy > > > On 8/25/14 12:50 PM, Ladislav Lhotka wrote: > > On 25 Aug 2014, at 20:50, Martin Bjorklund > wrote: > > Andy Bierman > wrote: > > On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen > > wrote: > > I agree the client will end up implementing > both, but a constrained > > server might not > > implement both. "equal footing" means both are > mandatory or both are > > optional. > > Currently both are mandatory and XML is the > default. > > "both optional" does mean that clients have to > support both. The > servers reap the benefit in needing to implement > support only one, which is > important for constrained devices. Do we think > "both mandatory" is OK for > all servers? > > > What are the alternatives? > mandatory for the client to implement both? > mandatory for the server to implement at least one? > This means the client has to retrieve the server > capabilities > before sending any requests with a message body? > (Or just try 1 format and if it fails, assume the > other will work?) > > Another option: > server SHOULD implement both; MAY implement one if > resource constrained > > The goal is still interoperability. So why not simply: > > server MUST implement XML and SHOULD implement JSON. > > It would probably make more sense the other way around as for > constrained devices JSON is generally much easier to deal with > than XML. > > Lada > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --------------040205070306020003010904 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit
On 8/25/14 5:32 PM, Andy Bierman wrote:



On Mon, Aug 25, 2014 at 4:34 PM, Reinaldo Penno <repenno@cisco.com> wrote:
Hi,

I would also support JSON being at least equal footing with XML. Ideally being MTI.


IMO 2 mandatory encoding formats is overkill.
RESTCONF is supposed to be lightweight compared to NETCONF,

[RP] Then JSON is the perfect choice.

and NETCONF does not require more than 1 encoding format.

XML is a mature standard.  It supports namespaces and attributes.
The YANG-to-JSON standard is still an work-in-progress with no
full implementations.

I don't see why the server SHOULD or MUST implement multiple formats.
Seems like that is moving the complexity from the client to the server.
Since there are many more servers (and they may be constrained)
this seems like the wrong place to dump complexity for the sake of client flexibility.

I think a constrained server should only need 1 encoding format, and I could
see how the vendor could choose JSON over XML.  But implementation details
are usually left out of standards. That is why my first choice
is not to pick a mandatory between XML and JSON.


thanks,

Reinaldo


Andy


 
On 8/25/14 12:50 PM, Ladislav Lhotka wrote:
On 25 Aug 2014, at 20:50, Martin Bjorklund <mbj@tail-f.com> wrote:

Andy Bierman <andy@yumaworks.com> wrote:
On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen <kwatsen@juniper.net> wrote:

I agree the client will end up implementing both, but a constrained
server might not
implement both. "equal footing" means both are mandatory or both are
optional.
Currently both are mandatory and XML is the default.
"both optional" does mean that clients have to support both.   The
servers reap the benefit in needing to implement support only one, which is
important for constrained devices.  Do we think "both mandatory" is OK for
all servers?


What are the alternatives?
mandatory for the client to implement both?
mandatory for the server to implement at least one?
This means the client has to retrieve the server capabilities
before sending any requests with a message body?
(Or just try 1 format and if it fails, assume the other will work?)

Another option:
   server SHOULD implement both; MAY implement one if resource constrained
The goal is still interoperability.  So why not simply:

  server MUST implement XML and SHOULD implement JSON.
It would probably make more sense the other way around as for constrained devices JSON is generally much easier to deal with than XML.

Lada


/martin

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--------------040205070306020003010904-- From nobody Tue Aug 26 02:31:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DB31A6EF3 for ; Tue, 26 Aug 2014 02:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.668] 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 c72rv11QHkjO for ; Tue, 26 Aug 2014 02:31:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6830B1A6EF9 for ; Tue, 26 Aug 2014 02:31:23 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id AE274141B94; Tue, 26 Aug 2014 11:31:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409045481; bh=OiiBRxALUUwgYy+5zxvRvojk+3Qp3mfYTlZtxpEw6wc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uL5TA00OBA2FFMhp89E2+1SHexoRfO/lmXzCUkpg8fdVjOZYgZ7KQRYgMNZPbs+8d qyAg5nVwq2byfNzUyfFzfWecIr60HVhq6wa+zx3LV2jgdAG3+0VfnfkdPNEUX+Xf1k ATNAJ4uV6wl/BqmOUeetc0Pt1LON6ib2lijiznZk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 26 Aug 2014 11:31:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/72f-IhLIA6QemTeGUTNEFBmAxGc Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 09:31:25 -0000 On 26 Aug 2014, at 02:32, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 25, 2014 at 4:34 PM, Reinaldo Penno = wrote: > Hi, >=20 > I would also support JSON being at least equal footing with XML. = Ideally being MTI. >=20 >=20 > IMO 2 mandatory encoding formats is overkill. > RESTCONF is supposed to be lightweight compared to NETCONF, > and NETCONF does not require more than 1 encoding format. >=20 > XML is a mature standard. It supports namespaces and attributes. > The YANG-to-JSON standard is still an work-in-progress with no > full implementations. >=20 > I don't see why the server SHOULD or MUST implement multiple formats. > Seems like that is moving the complexity from the client to the = server. > Since there are many more servers (and they may be constrained) > this seems like the wrong place to dump complexity for the sake of = client flexibility. >=20 > I think a constrained server should only need 1 encoding format, and I = could > see how the vendor could choose JSON over XML. But implementation = details > are usually left out of standards. That is why my first choice > is not to pick a mandatory between XML and JSON. I=92d support this, too. I don=92t think this breaks interoperability. Lada >=20 >=20 > thanks, >=20 > Reinaldo >=20 >=20 > Andy >=20 >=20 > =20 > On 8/25/14 12:50 PM, Ladislav Lhotka wrote: > On 25 Aug 2014, at 20:50, Martin Bjorklund wrote: >=20 > Andy Bierman wrote: > On Fri, Aug 22, 2014 at 1:12 PM, Kent Watsen = wrote: >=20 > I agree the client will end up implementing both, but a constrained > server might not > implement both. "equal footing" means both are mandatory or both are > optional. > Currently both are mandatory and XML is the default. > "both optional" does mean that clients have to support both. The > servers reap the benefit in needing to implement support only one, = which is > important for constrained devices. Do we think "both mandatory" is OK = for > all servers? >=20 >=20 > What are the alternatives? > mandatory for the client to implement both? > mandatory for the server to implement at least one? > This means the client has to retrieve the server capabilities > before sending any requests with a message body? > (Or just try 1 format and if it fails, assume the other will work?) >=20 > Another option: > server SHOULD implement both; MAY implement one if resource = constrained > The goal is still interoperability. So why not simply: >=20 > server MUST implement XML and SHOULD implement JSON. > It would probably make more sense the other way around as for = constrained devices JSON is generally much easier to deal with than XML. >=20 > Lada >=20 >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 26 03:07:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0F21A6F14 for ; Tue, 26 Aug 2014 03:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 BupWb_eDQMSJ for ; Tue, 26 Aug 2014 03:06:54 -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 3219A1A6F0A for ; Tue, 26 Aug 2014 03:06:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A716C1419; Tue, 26 Aug 2014 12:06:48 +0200 (CEST) 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 ZHLhenGrtama; Tue, 26 Aug 2014 12:06:47 +0200 (CEST) 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; Tue, 26 Aug 2014 12:06:47 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6F9620035; Tue, 26 Aug 2014 12:06:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GX-vrKRHlP-2; Tue, 26 Aug 2014 12:06:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56D7120033; Tue, 26 Aug 2014 12:06:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7080B2E4F673; Tue, 26 Aug 2014 12:06:40 +0200 (CEST) Date: Tue, 26 Aug 2014 12:06:39 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140826100638.GA55618@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HeEvuk9zaeAS7POiYAAJJ7IGFtU Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:06:58 -0000 On Tue, Aug 26, 2014 at 11:31:21AM +0200, Ladislav Lhotka wrote: > > On 26 Aug 2014, at 02:32, Andy Bierman wrote: > > > I think a constrained server should only need 1 encoding format, and I could > > see how the vendor could choose JSON over XML. But implementation details > > are usually left out of standards. That is why my first choice > > is not to pick a mandatory between XML and JSON. > > I’d support this, too. I don’t think this breaks interoperability. > I find it surprising to consider the mandatory to implement encoding format an implementation detail. Usually a standard gives clear guidance about data encoding for the sake of interoperability. So far, I only see these three options: a) XML is mandatory b) JSON is mandatory c) XML and JSON are both mandatory I expect that the fourth option put on the table, namely d) implementors can decide whether they implement JSON or XML leads eventually to c), after a certain period of frustration when things do not interoperate. Hence, I believe the decision needs to be made between a) and b) and c). If people argue about constrained implementations, it would help if they can provide more details what they mean with the term 'constrained' and if they can put numbers on the table concerning resource usage of the two alternatives. /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 Tue Aug 26 03:17:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989AD1A6F28 for ; Tue, 26 Aug 2014 03:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 BQMI3wKxJGWT for ; Tue, 26 Aug 2014 03:17:05 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id EAC771A6F29 for ; Tue, 26 Aug 2014 03:17:03 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id 7101012809BC; Tue, 26 Aug 2014 12:14:35 +0200 (CEST) Date: Tue, 26 Aug 2014 12:17:02 +0200 (CEST) Message-Id: <20140826.121702.1080653718976095871.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140826100638.GA55618@elstar.local> References: <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FrsZMfOggtJcs4FVbFmzG79uhv4 Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:17:07 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBPbiBUdWUsIEF1ZyAyNiwgMjAxNCBhdCAxMTozMToyMUFNICswMjAwLCBM YWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4gDQo+ID4gT24gMjYgQXVnIDIwMTQsIGF0IDAyOjMy LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4gDQo+ID4gPiBJ IHRoaW5rIGEgY29uc3RyYWluZWQgc2VydmVyIHNob3VsZCBvbmx5IG5lZWQgMSBlbmNvZGluZyBm b3JtYXQsIGFuZCBJIGNvdWxkDQo+ID4gPiBzZWUgaG93IHRoZSB2ZW5kb3IgY291bGQgY2hvb3Nl IEpTT04gb3ZlciBYTUwuICBCdXQgaW1wbGVtZW50YXRpb24gZGV0YWlscw0KPiA+ID4gYXJlIHVz dWFsbHkgbGVmdCBvdXQgb2Ygc3RhbmRhcmRzLiBUaGF0IGlzIHdoeSBteSBmaXJzdCBjaG9pY2UN Cj4gPiA+IGlzIG5vdCB0byBwaWNrIGEgbWFuZGF0b3J5IGJldHdlZW4gWE1MIGFuZCBKU09OLg0K PiA+IA0KPiA+IEnigJlkIHN1cHBvcnQgdGhpcywgdG9vLiBJIGRvbuKAmXQgdGhpbmsgdGhpcyBi cmVha3MgaW50ZXJvcGVyYWJpbGl0eS4NCj4gPiANCj4gDQo+IEkgZmluZCBpdCBzdXJwcmlzaW5n IHRvIGNvbnNpZGVyIHRoZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGVuY29kaW5nDQo+IGZvcm1h dCBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuIFVzdWFsbHkgYSBzdGFuZGFyZCBnaXZlcyBjbGVh cg0KPiBndWlkYW5jZSBhYm91dCBkYXRhIGVuY29kaW5nIGZvciB0aGUgc2FrZSBvZiBpbnRlcm9w ZXJhYmlsaXR5LiBTbyBmYXIsDQo+IEkgb25seSBzZWUgdGhlc2UgdGhyZWUgb3B0aW9uczoNCj4g DQo+IGEpIFhNTCBpcyBtYW5kYXRvcnkNCj4gYikgSlNPTiBpcyBtYW5kYXRvcnkNCj4gYykgWE1M IGFuZCBKU09OIGFyZSBib3RoIG1hbmRhdG9yeQ0KPiANCj4gSSBleHBlY3QgdGhhdCB0aGUgZm91 cnRoIG9wdGlvbiBwdXQgb24gdGhlIHRhYmxlLCBuYW1lbHkNCj4gDQo+IGQpIGltcGxlbWVudG9y cyBjYW4gZGVjaWRlIHdoZXRoZXIgdGhleSBpbXBsZW1lbnQgSlNPTiBvciBYTUwNCj4gDQo+IGxl YWRzIGV2ZW50dWFsbHkgdG8gYyksIGFmdGVyIGEgY2VydGFpbiBwZXJpb2Qgb2YgZnJ1c3RyYXRp b24gd2hlbg0KPiB0aGluZ3MgZG8gbm90IGludGVyb3BlcmF0ZS4gSGVuY2UsIEkgYmVsaWV2ZSB0 aGUgZGVjaXNpb24gbmVlZHMgdG8gYmUNCj4gbWFkZSBiZXR3ZWVuIGEpIGFuZCBiKSBhbmQgYyku DQoNCkkgYWdyZWUuDQoNCj4gSWYgcGVvcGxlIGFyZ3VlIGFib3V0IGNvbnN0cmFpbmVkDQo+IGlt cGxlbWVudGF0aW9ucywgaXQgd291bGQgaGVscCBpZiB0aGV5IGNhbiBwcm92aWRlIG1vcmUgZGV0 YWlscyB3aGF0DQo+IHRoZXkgbWVhbiB3aXRoIHRoZSB0ZXJtICdjb25zdHJhaW5lZCcgYW5kIGlm IHRoZXkgY2FuIHB1dCBudW1iZXJzIG9uDQo+IHRoZSB0YWJsZSBjb25jZXJuaW5nIHJlc291cmNl IHVzYWdlIG9mIHRoZSB0d28gYWx0ZXJuYXRpdmVzLg0KDQpSaWdodC4gIEFuZCBmb3IgdGhlIG90 aGVyIGVuZCBvZiB0aGUgc3BlY3RydW0sIGRldmljZXMgZGVhbGluZyB3aXRoDQpsYXJnZSBkYXRh IHNldHMsIEpTT04gaXMgaW5mZXJpb3Igc2luY2UgcGFyc2VycyBuZWVkIHRvIGJ1ZmZlcg0KZXZl cnl0aGluZyAoYi9jIG9iamVjdCBtZW1iZXJzIGFyZSB1bm9yZGVyZWQpLiAgTWF5YmUgdGhpcyBp cyBhbHNvIGFuDQppc3N1ZSBmb3IgY29uc3RyYWluZWQgZGV2aWNlcy4NCg0KSSBhbSBhbHNvIG5v dCBjb252aW5jZWQgdGhhdCBSRVNUQ09ORiBpcyB0aGUgcmlnaHQgc29sdXRpb24gZm9yIGF0DQps ZWFzdCBzb21lIG9mIHRoZXNlIGNvbnN0cmFpbmVkIGRldmljZXMuICBNYXliZSBhIGJldHRlciBh cmNoaXRlY3R1cmUNCmlzIHRvIHVzZSBhIHNwZWNpYWwtcHVycG9zZSBjb250cm9sIHByb3RvY29s IGZyb20gYSAiY29udHJvbGxlciIgdG8NCnRoZXNlIGRldmljZXMsIGFuZCBsZXQgdGhlICJjb250 cm9sbGVyIiBleHBvc2UgWUFORyBtb2RlbHMgb3Zlcg0KTkVUQ09ORiAoYW5kL29yIFJFU1RDT05G KS4NCg0KDQovbWFydGluDQo= From nobody Tue Aug 26 03:38:47 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4551A6F4D for ; Tue, 26 Aug 2014 03:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 zbZG6EnSGnk9 for ; Tue, 26 Aug 2014 03:38:45 -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 107B61A6F44 for ; Tue, 26 Aug 2014 03:38:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D5DE4F7F; Tue, 26 Aug 2014 12:38:43 +0200 (CEST) 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 RsPuVkgnskhz; Tue, 26 Aug 2014 12:38:42 +0200 (CEST) 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; Tue, 26 Aug 2014 12:38:43 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A86B20036; Tue, 26 Aug 2014 12:38:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R_ieHyvK3daJ; Tue, 26 Aug 2014 12:38:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A46F20038; Tue, 26 Aug 2014 12:38:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A0DA2E4F6E2; Tue, 26 Aug 2014 12:38:41 +0200 (CEST) Date: Tue, 26 Aug 2014 12:38:41 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140826103841.GB55618@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netconf@ietf.org References: <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> <20140826.121702.1080653718976095871.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140826.121702.1080653718976095871.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bEzkezhAlYrhXFo-Zb5_IlOAVQY Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:38:46 -0000 On Tue, Aug 26, 2014 at 12:17:02PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > If people argue about constrained > > implementations, it would help if they can provide more details what > > they mean with the term 'constrained' and if they can put numbers on > > the table concerning resource usage of the two alternatives. > > Right. And for the other end of the spectrum, devices dealing with > large data sets, JSON is inferior since parsers need to buffer > everything (b/c object members are unordered). Maybe this is also an > issue for constrained devices. > > I am also not convinced that RESTCONF is the right solution for at > least some of these constrained devices. Maybe a better architecture > is to use a special-purpose control protocol from a "controller" to > these devices, and let the "controller" expose YANG models over > NETCONF (and/or RESTCONF). > Exactly my point - the word 'constrained' is not sufficiently clear enough. If we talk about constrained devices considered by the IoT work in the IETF, then you like want to have a proxy that translates RESTCONF to COAP and part of the translation might even be a change of the data encoding to something like CBOR. There are many open questions in this space though, e.g. to what extend such a gateway needs to be able to understand the underlying YANG data models or how to encode URLs efficiently into something short and compact. But I have a certain feeling that people use 'constrained implementations' here in a somewhat different sense, e.g. targeting boxes capable to run an embedded Linux but where you like to avoid too many library dependencies. I am guessing though because people are not very clear what their concerns are. /js PS: The streaming issue is actually important for constrained devices as well. Having to buffer data is really hard if your RAM is only a few KB. It is likely less an issue for embedded Linux systems where the data size likely matches more easily the available RAM. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Aug 26 04:07:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5C71A6F67 for ; Tue, 26 Aug 2014 04:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 ENIdHbK-WNhX for ; Tue, 26 Aug 2014 04:07:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7F41A6F5B for ; Tue, 26 Aug 2014 04:07:49 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id C2A4C13F9DE; Tue, 26 Aug 2014 13:07:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409051268; bh=cws4z+eoqJXFF02wBuS7qTme1mTAQGIUHe7eARKpbv4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=v18aWGy1rRmLLuwg2YkN7jS+AjYdn53AaxOWvVcoALR84XBOzIvNvghn/rrl5P/vA tCG0YBPTId+awFUWHcIheaKd1VHxYUGysMBbQNLLqD3iwL5c7p6w5Qi/jVgD5JDJS/ tvv02dCXIY7AbPJeDAOzuJW4FKJy5ymb6DhCLZhU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140826100638.GA55618@elstar.local> Date: Tue, 26 Aug 2014 13:07:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01CB83B7-E64F-4BFD-A42C-197F325CF2D7@nic.cz> References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dbgj9pOtD-GqISKvxPK_i8lwNgs Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 11:07:51 -0000 On 26 Aug 2014, at 12:06, Juergen Schoenwaelder = wrote: > On Tue, Aug 26, 2014 at 11:31:21AM +0200, Ladislav Lhotka wrote: >>=20 >> On 26 Aug 2014, at 02:32, Andy Bierman wrote: >>=20 >>> I think a constrained server should only need 1 encoding format, and = I could >>> see how the vendor could choose JSON over XML. But implementation = details >>> are usually left out of standards. That is why my first choice >>> is not to pick a mandatory between XML and JSON. >>=20 >> I=92d support this, too. I don=92t think this breaks = interoperability. >>=20 >=20 > I find it surprising to consider the mandatory to implement encoding > format an implementation detail. Usually a standard gives clear > guidance about data encoding for the sake of interoperability. So far, > I only see these three options: >=20 > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory >=20 > I expect that the fourth option put on the table, namely >=20 > d) implementors can decide whether they implement JSON or XML >=20 > leads eventually to c), after a certain period of frustration when > things do not interoperate. Hence, I believe the decision needs to be c) on the client and d) on the server (+ a method how the client can = find out what media type(s) the server supports) is interoperable. Lada > made between a) and b) and c). If people argue about constrained > implementations, it would help if they can provide more details what > they mean with the term 'constrained' and if they can put numbers on > the table concerning resource usage of the two alternatives. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 26 07:07:54 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295C41A7033 for ; Tue, 26 Aug 2014 07:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 GROY58VEiQFA for ; Tue, 26 Aug 2014 07:07:48 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F403E1A7032 for ; Tue, 26 Aug 2014 07:07:47 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so14805714qga.15 for ; Tue, 26 Aug 2014 07:07:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=SzBpgCbNIm0xME1yw5QQ57qPv6V+UBlXi0aNMdf/gNk=; b=VHg9ml09oKpO/SFpXYCEeexYVgJCqQ3ntop8CGDQiFG+X+FNPiMCBX8GKR8cIq/SDa CP512KFvqszNf1/SVBoHTJs4KkJaSdvKCnvjOu/VKj0EoQpy7FscU9g2SJiuoe6BrwQ7 L42I0bEliaWSG7Mf0lhYc698UpXR19jJgkWXsD+y+c1RmZyrbRhi6HdGXoaaK1VhTiCj y+Pb4L4RQa06Ote6ysiq9vLKW3gAbIo9Z7RkwGWkRROlzIaMk3KOh9kpsn5DK5gxpqmm RjwQqhWkV5E5WXK2nOeWW36XZENpT0c+vFgl3LYEzcUaH4K9ibWZRV3t2uGTXWDVr0il er9Q== X-Gm-Message-State: ALoCoQlFEch5SmqM8xv5EeHzx/qOVQ/Den7KHFfOII7vnp/MPqa/SrjG+8p0rQHwg5B6f8s0BzkJ MIME-Version: 1.0 X-Received: by 10.224.112.1 with SMTP id u1mr46071308qap.7.1409062067079; Tue, 26 Aug 2014 07:07:47 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 07:07:46 -0700 (PDT) In-Reply-To: <20140826100638.GA55618@elstar.local> References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> Date: Tue, 26 Aug 2014 07:07:46 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=047d7b673a4efa7931050188d3c4 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gbzvpp6y_p6czB89H-UugqEqFdA Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:07:51 -0000 --047d7b673a4efa7931050188d3c4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 26, 2014 at 3:06 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Aug 26, 2014 at 11:31:21AM +0200, Ladislav Lhotka wrote: > > > > On 26 Aug 2014, at 02:32, Andy Bierman wrote: > > > > > I think a constrained server should only need 1 encoding format, and I > could > > > see how the vendor could choose JSON over XML. But implementation > details > > > are usually left out of standards. That is why my first choice > > > is not to pick a mandatory between XML and JSON. > > > > I'd support this, too. I don't think this breaks interoperability. > > > > I find it surprising to consider the mandatory to implement encoding > format an implementation detail. Usually a standard gives clear > guidance about data encoding for the sake of interoperability. So far, > I meant the selection of JSON or XML seems to be based on implementation details, which is why we can't pick a clear winner. > I only see these three options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > > I expect that the fourth option put on the table, namely > > d) implementors can decide whether they implement JSON or XML > > This is a strawman -- nobody is proposing this option. The discussion is over server requirements: A) XML and JSON are both MTI [current] B) XML is mandatory and JSON is optional C) JSON is mandatory and XML is optional D) server MUST support XML or JSON (vendor picks 1) > leads eventually to c), after a certain period of frustration when > things do not interoperate. Hence, I believe the decision needs to be > made between a) and b) and c). If people argue about constrained > implementations, it would help if they can provide more details what > they mean with the term 'constrained' and if they can put numbers on > the table concerning resource usage of the two alternatives. > > +1 JSON is about 40% smaller on-the-wire +1 JSON should require less code space than XML to implement -1 JSON is horrible for streaming (too much state to know and keep) -1 JSON does not currently support YANG module namespaces -1 JSON does not currently support meta-data (like XML attributes) -1 JSON does not support 64 bit numbers (So JSON loses to XML 4 - 2 ? :-) > /js > Andy --047d7b673a4efa7931050188d3c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 26, 2014 at 3:06 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Aug 26, 2014 at 11:31:21AM +0200, Ladislav Lhotka = wrote:
>
> On 26 Aug 2014, at 02:32, Andy Bierman <andy@yumaworks.com> wrote:
>
> > I think a constrained server should only need 1 encoding format, = and I could
> > see how the vendor could choose JSON over XML.  But implemen= tation details
> > are usually left out of standards. That is why my first choice > > is not to pick a mandatory between XML and JSON.
>
> I’d support this, too. I don’t think this breaks interoper= ability.
>

I find it surprising to consider the mandatory to implement encoding
format an implementation detail. Usually a standard gives clear
guidance about data encoding for the sake of interoperability. So far,
<= /blockquote>

I meant the selection of JSON or XML seems = to be based on implementation
details, which is why we can't = pick a clear winner.
 
I only see these three options:

a) XML is mandatory
b) JSON is mandatory
c) XML and JSON are both mandatory

I expect that the fourth option put on the table, namely

d) implementors can decide whether they implement JSON or XML


This is a strawman -- nobody is propos= ing this option.
The discussion is over server requirements:

  A) XML and JSON are both MTI  [current]
  B) XML is mandatory and JSON is optional
  C) JSON is= mandatory and XML is optional
  D) server MUST support XML = or JSON (vendor picks 1)

 
leads eventually to c), after a certain period of frustration when
things do not interoperate. Hence, I believe the decision needs to be
made between a) and b) and c). If people argue about constrained
implementations, it would help if they can provide more details what
they mean with the term 'constrained' and if they can put numbers o= n
the table concerning resource usage of the two alternatives.



+1  JSON is about 40% smaller on-the-w= ire
+1 JSON should require less code space than XML to implement<= /div>
-1 JSON is horrible for streaming (too much state to know and keep)
-1 JSON does not currently support YANG module namespaces
-1 JSON does not currently support meta-data (like XML attributes)
-1 JSON does not support 64 bit numbers

(So JSON loses to XML 4 - 2 ?  :-)

 
/js

Andy
 =
--047d7b673a4efa7931050188d3c4-- From nobody Tue Aug 26 07:22:46 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B701A797C for ; Tue, 26 Aug 2014 07:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.668] 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 89k9_pbQ2_9q for ; Tue, 26 Aug 2014 07:22:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE701A70FE for ; Tue, 26 Aug 2014 07:22:42 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 5E6B0141B8C; Tue, 26 Aug 2014 16:22:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409062961; bh=c5UtP867UQLdf7hQBwtH+WNjB+M96i+14As/ntKt8gQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=D49/MKe5Nj6V/N8ohSr42gXgWKqqRSvm3tYMZfVDQnsPsQi+AuFB51ECmpr/N4zLk 0fvx+rETjDTu6f9nTrx1+P+Vq9c2dYyvVoe/MvbPd+3v0RHH7fVrKQUiKEYmGm4wzf /QmQvRbd1cKx9G3nMVRgUoEeU+DYVM2zYbS5i0EY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 26 Aug 2014 16:22:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Ov5CsCwQMZROt7oDki1L1jMa2PI Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:22:44 -0000 On 26 Aug 2014, at 16:07, Andy Bierman wrote: > +1 JSON is about 40% smaller on-the-wire > +1 JSON should require less code space than XML to implement > -1 JSON is horrible for streaming (too much state to know and keep) We should consider draft-ietf-json-text-sequence-06. > -1 JSON does not currently support YANG module namespaces Why not? I don=92t understand. > -1 JSON does not currently support meta-data (like XML attributes) That=92s what we are discussing in the parallel thread. > -1 JSON does not support 64 bit numbers Not true. The issue only appears in I-JSON because presumably some = (most?) existing decoders read JSON numbers into double precision = floats. Lada >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 26 08:13:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B111A871C for ; Tue, 26 Aug 2014 08:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 IVxRgJcD93fC for ; Tue, 26 Aug 2014 08:13:30 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA651A8711 for ; Tue, 26 Aug 2014 08:13:29 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so14023285qae.34 for ; Tue, 26 Aug 2014 08:13:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7qIpfbhWodKR3knGu4Hke8XCNR95MpxgTfugxTwdNlA=; b=BmPiuVIOlRY1hG+ms8zgvFCgQ6uVfMnnDFAI3H3K4d4HsfHPgfcQ5SEdAgyKH33/e+ xhu4Y2fHBMobcH0OZUr5iLpEzV5ID2V0KMsv385vYDCDzWRRQDk87ppJT+cYEqd40XGt Ji7EKSvqVK9nirra5MvXiSywchwDtdoTruFrpXHhRxVvwRZnDv6JgKfiyw6eDqtMMAIh 5dG6Nx3jVxbCVagTNJdiJ7cn1vkOhGx4URBwVCRlI28LSCgaAGHvS+h3PJFBTEdAabE3 KsVLAKat5xxslgwzKxIia4HZRW+pIG76tREH4/5EjIo+SQfSr9Y8Mb747dJ9+dsCqfdT 2kgw== X-Gm-Message-State: ALoCoQlYAaJ7jQotkbAMLhokOwbkM3KnC8vKKvN0Q/y0X4Zkw1doiNUwXKmAUnQ1FIfsMi4dJHjR MIME-Version: 1.0 X-Received: by 10.224.112.1 with SMTP id u1mr46707972qap.7.1409066008766; Tue, 26 Aug 2014 08:13:28 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 08:13:28 -0700 (PDT) In-Reply-To: References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> Date: Tue, 26 Aug 2014 08:13:28 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b673a4eeb1eab050189be20 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4QOETtNWHiPZTj5J_0-4SmLqUqY Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:13:33 -0000 --047d7b673a4eeb1eab050189be20 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 26, 2014 at 7:22 AM, Ladislav Lhotka wrote: > > On 26 Aug 2014, at 16:07, Andy Bierman wrote: > > > +1 JSON is about 40% smaller on-the-wire > > +1 JSON should require less code space than XML to implement > > -1 JSON is horrible for streaming (too much state to know and keep) > > We should consider draft-ietf-json-text-sequence-06. > > More brand new code to write? > > -1 JSON does not currently support YANG module namespaces > > Why not? I don't understand. > XML is a deployed standard with lots of implementations and free tools. The YANG-to-JSON standard is still a work-in-progress with minimal deployment and tools. > > > -1 JSON does not currently support meta-data (like XML attributes) > > That's what we are discussing in the parallel thread. > XML has a deployed solution > > > -1 JSON does not support 64 bit numbers > > Not true. The issue only appears in I-JSON because presumably some (most?) > existing decoders read JSON numbers into double precision floats. > > OK. > Lada > > Andy --047d7b673a4eeb1eab050189be20 Content-Type: text/html; charset=ISO-8859-1



On Tue, Aug 26, 2014 at 7:22 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

On 26 Aug 2014, at 16:07, Andy Bierman <andy@yumaworks.com> wrote:

> +1  JSON is about 40% smaller on-the-wire
> +1 JSON should require less code space than XML to implement
> -1 JSON is horrible for streaming (too much state to know and keep)

We should consider draft-ietf-json-text-sequence-06.


More brand new code to write?
 
> -1 JSON does not currently support YANG module namespaces

Why not? I don’t understand.

XML is a deployed standard with lots of implementations and free tools.
The YANG-to-JSON standard is still a work-in-progress with minimal deployment
and tools.
 

> -1 JSON does not currently support meta-data (like XML attributes)

That’s what we are discussing in the parallel thread.

XML has a deployed solution
 

> -1 JSON does not support 64 bit numbers

Not true. The issue only appears in I-JSON because presumably some (most?) existing decoders read JSON numbers into double precision floats.


OK.


 
Lada


Andy
 
--047d7b673a4eeb1eab050189be20-- From nobody Tue Aug 26 08:20:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B491A8718 for ; Tue, 26 Aug 2014 08:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 5MF0VSPHKIhK for ; Tue, 26 Aug 2014 08:20:24 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425951A8728 for ; Tue, 26 Aug 2014 08:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7630; q=dns/txt; s=iport; t=1409066424; x=1410276024; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=Mr4AvER3hFXJIsRd71MZaWTkzx6pnQiQTq5nPp0t1R0=; b=Fv8o8fL7sVcd2dyDQJESLXJlaiwd6hE5//AUIdDovBuNDubrJa3XnxjC KPFCTyQsYd7Um49+97Be2FulSNU0MdlTSUG2tRjRQRr5Dz7SQryKnZY4v ZsAIlUeItOMe8ILDs9mAI+zWXfaaqRRywVEKpUjN4cc+8ZvDGvnLvfeC1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFALik/FOtJV2U/2dsb2JhbABbgw1TVwTMSQEJhnpTAYESFneEAwEBAQMBAQEBawoGCwsYCRYIBwkDAgECARUfEQYNBgIBAReIHwgNqGOWORMEj1OCOFOBQQWLIoNxjTaHL41dg35MgUiBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,405,1406592000"; d="scan'208,217"; a="72456281" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP; 26 Aug 2014 15:20:23 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7QFKNVd023152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Aug 2014 15:20:23 GMT Received: from [10.21.94.61] (10.21.94.61) by xhc-rcd-x07.cisco.com (173.37.183.81) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 26 Aug 2014 10:20:23 -0500 Message-ID: <53FCA5B7.3030105@cisco.com> Date: Tue, 26 Aug 2014 08:20:23 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070802050203070508020500" X-Originating-IP: [10.21.94.61] Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Gfhb7LuTXWGVwIO8qAx-7UOimL0 Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:20:27 -0000 --------------070802050203070508020500 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Let's be fair and compare apples to apples. "XML is a deployed standard with lots of implementations and free tools." [RP] And JSON is also a deployed standards with lots of implementation and free tools. And, if anything, JSON is overtaking XML in tools, deployment and programming language support. "The YANG-to-JSON standard is still a work-in-progress with minimal deployment and tools." [RP] RESTConf is also a work-in-progress. And I see this as an opportunity to make sure our standards embrace the JSON and not a standard that is in decline. On 8/26/14 8:13 AM, Andy Bierman wrote: > > > > On Tue, Aug 26, 2014 at 7:22 AM, Ladislav Lhotka > wrote: > > > On 26 Aug 2014, at 16:07, Andy Bierman > wrote: > > > +1 JSON is about 40% smaller on-the-wire > > +1 JSON should require less code space than XML to implement > > -1 JSON is horrible for streaming (too much state to know and keep) > > We should consider draft-ietf-json-text-sequence-06. > > > More brand new code to write? > > > -1 JSON does not currently support YANG module namespaces > > Why not? I don’t understand. > > > XML is a deployed standard with lots of implementations and free tools. > The YANG-to-JSON standard is still a work-in-progress with minimal > deployment > and tools. > > > > -1 JSON does not currently support meta-data (like XML attributes) > > That’s what we are discussing in the parallel thread. > > > XML has a deployed solution > > > > -1 JSON does not support 64 bit numbers > > Not true. The issue only appears in I-JSON because presumably some > (most?) existing decoders read JSON numbers into double precision > floats. > > > OK. > > > Lada > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------070802050203070508020500 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Let's be fair and compare apples to apples.

"XML is a deployed standard with lots of implementations and free tools."

[RP] And JSON is also a deployed standards with lots of implementation and free tools. And, if anything, JSON is overtaking XML in tools, deployment and programming language support.

"The YANG-to-JSON standard is still a work-in-progress with minimal deployment
and tools."

[RP] RESTConf is also a work-in-progress. And I see this as an opportunity to make sure our standards embrace the JSON and not a standard that is in decline.

On 8/26/14 8:13 AM, Andy Bierman wrote:



On Tue, Aug 26, 2014 at 7:22 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

On 26 Aug 2014, at 16:07, Andy Bierman <andy@yumaworks.com> wrote:

> +1  JSON is about 40% smaller on-the-wire
> +1 JSON should require less code space than XML to implement
> -1 JSON is horrible for streaming (too much state to know and keep)

We should consider draft-ietf-json-text-sequence-06.


More brand new code to write?
 
> -1 JSON does not currently support YANG module namespaces

Why not? I don’t understand.

XML is a deployed standard with lots of implementations and free tools.

The YANG-to-JSON standard is still a work-in-progress with minimal deployment
and tools.
 

> -1 JSON does not currently support meta-data (like XML attributes)

That’s what we are discussing in the parallel thread.

XML has a deployed solution
 

> -1 JSON does not support 64 bit numbers

Not true. The issue only appears in I-JSON because presumably some (most?) existing decoders read JSON numbers into double precision floats.


OK.


 
Lada


Andy
 


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--------------070802050203070508020500-- From nobody Tue Aug 26 08:39:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E969E1A8724 for ; Tue, 26 Aug 2014 08:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ZLsRfm7Vt1aJ for ; Tue, 26 Aug 2014 08:39:22 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D331A874C for ; Tue, 26 Aug 2014 08:39:20 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so11157997qgd.19 for ; Tue, 26 Aug 2014 08:39:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g65wUhY4PIdT6mbV1aBmzpCHtevM1TGgS1Waun/wSug=; b=OdMskGSMSvkZ0zRkGRsB1flAiqQIThdhWyyXOki6GhC7vDDdMDhknTxiQnCOuN/k2r p4JhQhrzc0/BcK4s5sKTt0ao3QySV6YKBRwagppcmtSp55TQIXYPxjAnf/1SyaG4mORr Hi4E1lU9GaUciu232ymDfj5xgdyqMWoeEO6SVJYwhe4H/cfgHipiDzxPMdXy6Cy5BTHp EsUDN4PNilxEKwLpkipaGpp8Y1tp01S3hXUqlscufCzfwfJYfA1MTcV9gE6wgSUWsxgS UVUPY02/4bToQJarShwwDJhvu67rc+t35EjZiQJ9QxoVyVH9tULiy4L+BaA8MlTkp9Eu GkTw== X-Gm-Message-State: ALoCoQkPabT69Tdseo4G4/rQJobtxWm8vgOBDw2S/GR+cvMUcWPdWlGWcqdtnZ0U2u0zuIy6Ydeh MIME-Version: 1.0 X-Received: by 10.140.98.7 with SMTP id n7mr44756863qge.83.1409067559808; Tue, 26 Aug 2014 08:39:19 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 08:39:19 -0700 (PDT) In-Reply-To: <53FCA5B7.3030105@cisco.com> References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> <53FCA5B7.3030105@cisco.com> Date: Tue, 26 Aug 2014 08:39:19 -0700 Message-ID: From: Andy Bierman To: Reinaldo Penno Content-Type: multipart/alternative; boundary=001a113ac3c65e0b3105018a1b72 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/s9H2PK-f5BZU6mCwcdsL2muv0hw Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:39:31 -0000 --001a113ac3c65e0b3105018a1b72 Content-Type: text/plain; charset=ISO-8859-1 Hi, So maybe we are confirming that we don't have consensus to pick 1 mandatory encoding format. Nobody has complained that the client needs to support both, so the issue seems to be what to require for the server. Since the client MUST support both, then it really doesn't matter at all which of the 2 formats the server supports. It is trivial to discover the supported formats from the server. I still have not heard any justification for 2 mandatory formats for the server. IMO, if we can't pick 1 mandatory, then let the vendor pick, rather than requiring both. Andy On Tue, Aug 26, 2014 at 8:20 AM, Reinaldo Penno wrote: > Let's be fair and compare apples to apples. > > "XML is a deployed standard with lots of implementations and free tools." > > [RP] And JSON is also a deployed standards with lots of implementation and > free tools. And, if anything, JSON is overtaking XML in tools, deployment > and programming language support. > > "The YANG-to-JSON standard is still a work-in-progress with minimal > deployment > and tools." > > [RP] RESTConf is also a work-in-progress. And I see this as an opportunity > to make sure our standards embrace the JSON and not a standard that is in > decline. > > On 8/26/14 8:13 AM, Andy Bierman wrote: > > > > > On Tue, Aug 26, 2014 at 7:22 AM, Ladislav Lhotka wrote: > >> >> On 26 Aug 2014, at 16:07, Andy Bierman wrote: >> >> > +1 JSON is about 40% smaller on-the-wire >> > +1 JSON should require less code space than XML to implement >> > -1 JSON is horrible for streaming (too much state to know and keep) >> >> We should consider draft-ietf-json-text-sequence-06. >> >> > More brand new code to write? > > >> > -1 JSON does not currently support YANG module namespaces >> >> Why not? I don't understand. >> > > XML is a deployed standard with lots of implementations and free tools. > > > The YANG-to-JSON standard is still a work-in-progress with minimal > deployment > and tools. > > >> >> > -1 JSON does not currently support meta-data (like XML attributes) >> >> That's what we are discussing in the parallel thread. >> > > XML has a deployed solution > > >> >> > -1 JSON does not support 64 bit numbers >> >> Not true. The issue only appears in I-JSON because presumably some >> (most?) existing decoders read JSON numbers into double precision floats. >> >> > OK. > > > > >> Lada >> >> > Andy > > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a113ac3c65e0b3105018a1b72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

So maybe we are confirming that we = don't have consensus to pick
1 mandatory encoding format.

Nobody has complained that the client needs to suppor= t both,
so the issue seems to be what to require for the server.
Sin= ce the client MUST support both, then it really doesn't matter at all
which of the 2 formats the server supports. It is trivial to disco= ver the
supported formats from the server.

I still ha= ve not heard any justification for 2 mandatory formats for the server.
IMO, if we can't pick 1 mandatory, then let the vendor pick, rath= er than requiring both.


Andy


On Tue, Aug 26, 2014 at 8:20 AM, Reinaldo Penno <repenno= @cisco.com> wrote:
=20 =20 =20
Let's be fair and compare apples to apples.

"XML is a deployed standard with lots of implementations and free tools."

[RP] And JSON is also a deployed standards with lots of implementation and free tools. And, if anything, JSON is overtaking XML in tools, deployment and programming language support.

"The YANG-to-JSON standard is still a work-in-progress with minima= l deployment
and tools."

[RP] RESTConf is also a work-in-progress. And I see this as an opportunity to make sure our standards embrace the JSON and not a standard that is in decline.

On 8/26/14 8:13 AM, Andy Bierman wrote:
=20



On Tue, Aug 26, 2014 at 7:22 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

On 26 Aug 2014, at 16:07, Andy Bierman <andy@yumaworks.com> wrote:

> +1  JSON is about 40% smaller on-the-wire
> +1 JSON should require less code space than XML to implement
> -1 JSON is horrible for streaming (too much state to know and keep)

We should consider draft-ietf-json-text-sequence-06.


More brand new code to write?
 
> -1 JSON does not currently support YANG module namespaces

Why not? I don’t understand.

XML is a deployed standard with lots of implementations and free tools.

The YANG-to-JSON standard is still a work-in-progress with minimal deployment
and tools.
 

> -1 JSON does not currently support meta-data (like XML attributes)

That’s what we are discussing in the parallel thread.

XML has a deployed solution
 

> -1 JSON does not support 64 bit numbers

Not true. The issue only appears in I-JSON because presumably some (most?) existing decoders read JSON numbers into double precision floats.


OK.


 
Lada


Andy
 


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--001a113ac3c65e0b3105018a1b72-- From nobody Tue Aug 26 09:06:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C641A87A3 for ; Tue, 26 Aug 2014 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.668] 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 sq_SbpYHdhSn for ; Tue, 26 Aug 2014 09:06:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A711A879D for ; Tue, 26 Aug 2014 09:06:08 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id E96CE141B8B; Tue, 26 Aug 2014 18:06:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409069167; bh=Lv70tbkVCzi8X0wSOf/XIydSUpUQ90nuPfx5GPpQIDg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KK5i/ZbO5zYFMGi1z27J0IxQk82ojHstBXFNKx92mA814Pmrwx9TWWRus9TT9VKqI Eb3vjuY/hKpf9L8PLGnMAvw4XK4Fwo6j1d0PUbUmuFRr2UntQwgWwpGacmS9mZgOTb +9+Iv/JlYh160OGi2DaJEvxRtStdS7jToc9o/LRw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 26 Aug 2014 18:05:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/G4xiBQG0ovov3bDVnYpMU-xiznc Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:06:10 -0000 On 26 Aug 2014, at 17:13, Andy Bierman wrote: > =20 > > -1 JSON does not currently support YANG module namespaces >=20 > Why not? I don=92t understand. >=20 > XML is a deployed standard with lots of implementations and free = tools. > The YANG-to-JSON standard is still a work-in-progress with minimal = deployment > and tools. This is true for RESTCONF and YANG in the first place. Objectively, JSON = is a far better fit for YANG data than XML - you just have to work out a = few things. In XML, on the other hand, you have to carry along all the = baggage that=92s not needed. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Aug 26 09:10:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CD91A8727 for ; Tue, 26 Aug 2014 09:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 42FH0VmFI3qO for ; Tue, 26 Aug 2014 09:10:30 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21EA91A877C for ; Tue, 26 Aug 2014 09:10:30 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so15150595qga.29 for ; Tue, 26 Aug 2014 09:10:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=N+7NCRNC3LoxoczlMdkPB8Aa0JrvBINy0Kiif1ygZz4=; b=k2bbnJSAX8vijmVHXFqwzAWXmMHrcVG5TYD9lUt7Q2dXVoINJ3OSkDSV6goaZLJoNf nlj8U2JiLf4rPT7LXNo6JC+ZsXRnX18MBU9xbdOCs3RGeAb78L6SUvRJymiHw0aaTShO 24AhchhgiabZOVZ6+9YmFc6P0kMDf522mp50IMoCOcQDN44ohVi/1V4uKX30QddY31G8 rWWu7fwd00rBq+oTGJOKKdsGb0mKTgv1YIuCRSq9P4S0pmeKbPVrTJf/tf1+zlnRqWGz 6nwj2IoDAms8BOa31ANBf/MOMxbSc6mOVRrf/PkSNLwAJwqzHWryUUXluIYhAp1KSK3C Vczg== X-Gm-Message-State: ALoCoQnorJa45y2RdDYD9HkWVasZfYnQhHchB9CNSgnmJrOyzUlH6aewnDjsLvZpG3w8yasO7NCm MIME-Version: 1.0 X-Received: by 10.224.112.1 with SMTP id u1mr47261066qap.7.1409069429321; Tue, 26 Aug 2014 09:10:29 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 09:10:29 -0700 (PDT) Date: Tue, 26 Aug 2014 09:10:29 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=047d7b673a4ecc9c6005018a8a6f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xE13V-YYpaMEwzApa4XGek5joAI Subject: [Netconf] RESTCONF capabilities and optional features solution proposal X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:10:32 -0000 --047d7b673a4ecc9c6005018a8a6f Content-Type: text/plain; charset=ISO-8859-1 Hi, The WG agreed at the last IETF to identify protocol capabilities and consider base functionality + optional features. Solution proposal: A) Add following data to /restconf container: container parameters { list parameter { description "Query parameters supported by the server."; key name; leaf name { type string; description "Parameter name (e.g. 'depth')"; } leaf organization { type string; mandatory true; description "Parameter organization (e.g. 'ietf.org or example.com ')"; } } } container capabilities { leaf-list capability { type inet:uri; description "Protocol capability identifier."; } } B) Make all query parameters optional to implement C) Server MUST advertise the parameters it supports. D) No change in RESTCONF protocol operation requirements E) Specify 2 URIs (1 for XML and 1 for JSON format) F) Server MUST advertise at least 1 of (JSON or XML) URIs G) Move complex retrieval (collection resource, pagination, etc.) to a new document, but leave query parameters already defined in RESTCONF Andy --047d7b673a4ecc9c6005018a8a6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The WG agreed at the last IETF to i= dentify protocol capabilities and
consider base functionality + o= ptional features.

Solution proposal:
A) Add following data to /restconf container:


=A0 container parameters {
=A0 =A0 list par= ameter {
=A0 =A0 =A0 =A0description "Query parameters suppor= ted by the server.";
=A0 =A0 =A0 =A0key name;
=A0 =A0 =A0 =A0leaf name {=A0
=
=A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 =A0 =A0 descrip= tion "Parameter name (e.g. 'depth')";
=A0 =A0 = =A0 =A0}
=A0 =A0 =A0 =A0leaf organization {=A0
=A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 =A0 =A0 mandato= ry true;
=A0 =A0 =A0 =A0 =A0 description "Parameter organiza= tion (e.g. 'ietf.org or example.com')";
=A0 =A0 =A0 =A0}
=A0 =A0 =A0}
=A0 }

=A0container capabilities {
=A0 =A0 leaf-list ca= pability {
=A0 =A0 =A0 =A0type inet:uri;
=A0 =A0 =A0 = =A0description "Protocol capability identifier.";
=A0 =A0 }
=A0 }

B) Make all query p= arameters optional to implement
C) Server MUST advertise the para= meters it supports.
D) No change in RESTCONF protocol operation r= equirements
E) Specify 2 URIs (1 for XML and 1 for JSON format)
F) Serve= r MUST advertise at least 1 of (JSON =A0or XML) URIs
G) Move comp= lex retrieval (collection resource, pagination, etc.)
=A0 =A0 to = a new document, but leave query parameters already defined
=A0 =A0 in RESTCONF


Andy
=

--047d7b673a4ecc9c6005018a8a6f-- From nobody Tue Aug 26 09:49:14 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4B1A87CE for ; Tue, 26 Aug 2014 09:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 G3Z8WWlyCpIr for ; Tue, 26 Aug 2014 09:49:08 -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 AA7AF1A882A for ; Tue, 26 Aug 2014 09:44:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7E5061383; Tue, 26 Aug 2014 18:44:24 +0200 (CEST) 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 XXLP-ndb5I66; Tue, 26 Aug 2014 18:44:22 +0200 (CEST) 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; Tue, 26 Aug 2014 18:44:23 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B79D220035; Tue, 26 Aug 2014 18:44:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r2dcB0jv1wfO; Tue, 26 Aug 2014 18:44:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F1E120033; Tue, 26 Aug 2014 18:44:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1AEDF2E5051D; Tue, 26 Aug 2014 18:44:22 +0200 (CEST) Date: Tue, 26 Aug 2014 18:44:22 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140826164422.GA56605@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> 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/netconf/6kDZZhkr0-4SFOi599-fOzB_2Dk Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 16:49:10 -0000 On Tue, Aug 26, 2014 at 04:22:35PM +0200, Ladislav Lhotka wrote: > > > -1 JSON does not support 64 bit numbers > > Not true. The issue only appears in I-JSON because presumably some (most?) existing decoders read JSON numbers into double precision floats. > I disagree with both statements. a) The JSON specification [RFC7159] says: This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available. Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. So this is not an I-JSON issue. b) 64-bit numbers can of course be encoded in JSON by encoding them as strings. (This is not worse than encoding them as strings in XML.) Note that this may also affect YANG's decimal64 type. The YANG to JSON I-D simply needs to say the right thing. /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 Tue Aug 26 10:22:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2463A1A0087 for ; Tue, 26 Aug 2014 10:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 FxuY7P5fhpwE for ; Tue, 26 Aug 2014 10:22:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3013F1A0022 for ; Tue, 26 Aug 2014 10:22:15 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 26 Aug 2014 17:22:12 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.109]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.72]) with mapi id 15.00.1015.018; Tue, 26 Aug 2014 17:22:12 +0000 From: Kent Watsen To: Andy Bierman , Netconf Thread-Topic: [Netconf] RESTCONF capabilities and optional features solution proposal Thread-Index: AQHPwVJFShLrLqfAXU+QrWaqqGmnmw== Date: Tue, 26 Aug 2014 17:22:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(377454003)(86362001)(15975445006)(99396002)(83506001)(15202345003)(54356999)(76176999)(50986999)(95666004)(21056001)(46102001)(85306004)(76482001)(36756003)(77982001)(90102001)(83072002)(85852003)(99286002)(101416001)(20776003)(79102001)(31966008)(74662001)(107886001)(107046002)(87936001)(106356001)(105586002)(106116001)(561944003)(74502001)(92726001)(77096002)(19580395003)(2656002)(4396001)(66066001)(81542001)(80022001)(83322001)(19580405001)(64706001)(92566001)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <71B4CAA59827B94F909B18360F89C12C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/lE4Tb1usMZAlXvPqh-kdtJvLwQY Subject: Re: [Netconf] RESTCONF capabilities and optional features solution proposal X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 17:22:19 -0000 I've heard this approach mentioned before =AD having all query params be optional but otherwise the base protocol is unchanged. It seems to be a clean way to approach modularity, but what about: 1. Servers that don't want to support sub-URLs. That is, they only want to support reading/writing the entire config. 2. Normal HTTP would have a POST to a resource create that resource, but REST APIs usually have a POST to a "collection" add an entry to the collection (not create a new collection). I fully support moving "collection" support to another document, but I'm unsure how it could build on top of this "base" definition. Resolving these, can we consider the base protocol only supporting a top-level resource/URL and then leave it to another draft to fill in support for nested URLs and collections? > E) Specify 2 URIs (1 for XML and 1 for JSON format) This is usually done via media-type: foobar+xml or foorbar+json - is there a reason to use URIs? Thanks, Kent From: Andy Bierman Date: Tuesday, August 26, 2014 at 9:10 AM To: NetConf Subject: [Netconf] RESTCONF capabilities and optional features solution proposal Hi, The WG agreed at the last IETF to identify protocol capabilities and consider base functionality + optional features. Solution proposal: A) Add following data to /restconf container: container parameters { list parameter { description "Query parameters supported by the server."; key name; leaf name {=20 type string; description "Parameter name (e.g. 'depth')"; } leaf organization { type string; mandatory true; description "Parameter organization (e.g. 'ietf.org or example.com ')"; } } } container capabilities { leaf-list capability { type inet:uri; description "Protocol capability identifier."; } } B) Make all query parameters optional to implement C) Server MUST advertise the parameters it supports. D) No change in RESTCONF protocol operation requirements E) Specify 2 URIs (1 for XML and 1 for JSON format) F) Server MUST advertise at least 1 of (JSON or XML) URIs G) Move complex retrieval (collection resource, pagination, etc.) to a new document, but leave query parameters already defined in RESTCONF Andy From nobody Tue Aug 26 10:51:32 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6A41A01C5 for ; Tue, 26 Aug 2014 10:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 LchEksTqYqkR for ; Tue, 26 Aug 2014 10:51:28 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF051A0010 for ; Tue, 26 Aug 2014 10:51:28 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id z107so11613318qgd.0 for ; Tue, 26 Aug 2014 10:51:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8RdkF6QkWoeSiDg8vsz0ZqkDWqHYOwHHD2MiK7SynHM=; b=ZMtZYrbH6WiZvlSDcmbHFUAoCMcOItEUdyi7uDOL7EfmNxlK0ROo83Z4X8ixL5jghk /mGLbzhBjrhAplyUDQjA+crw2y2KHfTEpkfHahTPUAeAqfssIxLcaNw1o2/87z/y4aRT lFDR5gSAfwRvEhKPuTkaydhEHVwKaaOWP5JH5vutp/hIA3lYdEu7V3MmBYISfXuHaGzZ 1HE0wVAVIm3V0/XG4Kfc1YJwUeBajGzEm9Iz4Pzd6w5bIPj1v47nmCpxJded+FAQP0V9 PvXA6L9QrJxl7by9ROQ0bLWpVs7svgt5AO8u5tEbVE41zuOkXzIzaYfK40jR4IZ6PmL2 v7kw== X-Gm-Message-State: ALoCoQmHl6GdcTYCkkPG8mLywDXjhP84EZf5LfzsQlT1SQ8ktiAFQ/QWYNe8YYnx8+xOaJ8ehQdh MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr258639qab.7.1409075486376; Tue, 26 Aug 2014 10:51:26 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 10:51:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Aug 2014 10:51:26 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c1c560d4349605018bf333 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-8WbvVNbwG1wXyDZ_2GV9z-W9As Cc: Netconf Subject: Re: [Netconf] RESTCONF capabilities and optional features solution proposal X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 17:51:30 -0000 --001a11c1c560d4349605018bf333 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2014 at 10:22 AM, Kent Watsen wrote: > > I've heard this approach mentioned before =AD having all query params be > optional but otherwise the base protocol is unchanged. It seems to be a > clean way to approach modularity, but what about: > > 1. Servers that don't want to support sub-URLs. That is, they only want > to support reading/writing the entire config. > > This isn't very REST-like though. We also don't have a good definition of "constrained". I don't really agree that only reading/writing the entire config is a limitation that should be in the standard. > 2. Normal HTTP would have a POST to a resource create that resource, but > REST APIs usually have a POST to a "collection" add an entry to the > collection (not create a new collection). I fully support moving > "collection" support to another document, but I'm unsure how it could > build on top of this "base" definition. > > We do not require every list to be in ots own container, to mimic this collection approach. IMO the current approach works for the resource mapping we defined for YANG= . I think a new draft could just invent a new media type in order to distinguish a new type of POST for RESTCONF. > Resolving these, can we consider the base protocol only supporting a > top-level resource/URL and then leave it to another draft to fill in > support for nested URLs and collections? > > > I do not want existing RESTCONF to split into multiple documents, or support a "base" protocol that only supports one giant "datastore" resource. Such a device does not really need a modular solution like RESTCONF or YANG= . > > E) Specify 2 URIs (1 for XML and 1 for JSON format) > > This is usually done via media-type: foobar+xml or foorbar+json - is > there a reason to use URIs? > > That is what we use for generic capabilities. There should be something for the client to read. It could be a separate leaf: /restconf/encoding leaf encoding { type bits { // not allowed to be empty bit xml; bit json; } mandatory true; } > Thanks, > Kent > Andy > > > > From: Andy Bierman > Date: Tuesday, August 26, 2014 at 9:10 AM > To: NetConf > Subject: [Netconf] RESTCONF capabilities and optional features > solution proposal > > > Hi, > > The WG agreed at the last IETF to identify protocol capabilities and > consider base functionality + optional features. > > Solution proposal: > > A) Add following data to /restconf container: > > > container parameters { > list parameter { > description "Query parameters supported by the server."; > key name; > leaf name { > type string; > description "Parameter name (e.g. 'depth')"; > } > leaf organization { > type string; > mandatory true; > description "Parameter organization (e.g. 'ietf.org > or > example.com ')"; > } > > } > } > > container capabilities { > leaf-list capability { > type inet:uri; > description "Protocol capability identifier."; > } > } > > B) Make all query parameters optional to implement > C) Server MUST advertise the parameters it supports. > D) No change in RESTCONF protocol operation requirements > E) Specify 2 URIs (1 for XML and 1 for JSON format) > F) Server MUST advertise at least 1 of (JSON or XML) URIs > G) Move complex retrieval (collection resource, pagination, etc.) > to a new document, but leave query parameters already defined > in RESTCONF > > > Andy > > --001a11c1c560d4349605018bf333 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 26, 2014 at 10:22 AM, Kent Watsen <= ;kwatsen@juniper.n= et> wrote:

I've heard this approach mentioned before =AD having all query params b= e
optional but otherwise the base protocol is unchanged.=A0 It seems to be a<= br> clean way to approach modularity, but what about:

1. Servers that don't want to support sub-URLs.=A0 That is, they only w= ant
to support reading/writing the entire config.


This isn't very REST-like though.<= /div>
We also don't have a good definition of "constrained&quo= t;.
I don't really agree that only reading/writing the entire= config is a limitation
that should be in the standard.

=A0
2. Normal HTTP would have a POST to a resource create that resource, but REST APIs usually have a POST to a "collection" add an entry to t= he
collection (not create a new collection).=A0 =A0 I fully support moving
"collection" support to another document, but I'm unsure how = it could
build on top of this "base" definition.


We do not require every list to be in = ots own container, to mimic this collection approach.
IMO the cur= rent approach works for the resource mapping we defined for YANG.
I think a new draft could just invent a new media type
in or= der to distinguish a new type of POST for RESTCONF.

=A0
Resolving these, can we consider the base protocol only supporting a
top-level resource/URL and then leave it to another draft to fill in
support for nested URLs and collections?



I do not want existing RESTCONF to spl= it into multiple documents,
or support a "base" protoco= l that only supports one giant "datastore" resource.
Such a device does not really need a modular solution like RESTCONF or YANG= .


> E) Specify 2 URIs (1 for XML and 1 for JSON format)

This is usually done via media-type: foobar+xml or foorbar+json=A0 - is
there a reason to use URIs?


That is what we use for generic capabi= lities.
There should be something for the client to read.
It could be a separate leaf:

=A0 /restconf/= encoding

=A0 =A0leaf encoding {
=A0 =A0 =A0 type bits = { =A0// not allowed to be empty
=A0 =A0 =A0 =A0 bit xml;
=A0 =A0 =A0 =A0 bit json;
=A0 =A0 =A0}
=A0 =A0 =A0man= datory true;
=A0 }



Thanks,
Kent


Andy
=A0<= /div>



From:=A0 Andy Bierman <andy@yumawo= rks.com>
Date:=A0 Tuesday, August 26, 2014 at 9:10 AM
To:=A0 NetConf <netconf@ietf.org= >
Subject:=A0 [Netconf] RESTCONF capabilities and optional features
solution=A0 =A0 =A0 =A0 proposal


Hi,

The WG agreed at the last IETF to identify protocol capabilities and
consider base functionality + optional features.

Solution proposal:

A) Add following data to /restconf container:


=A0 container parameters {
=A0 =A0 list parameter {
=A0 =A0 =A0 =A0description "Query parameters supported by the server.&= quot;;
=A0 =A0 =A0 =A0key name;
=A0 =A0 =A0 =A0leaf name {
=A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 =A0 =A0 description "Parameter name (e.g. 'depth')= ";
=A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0leaf organization {
=A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 =A0 =A0 mandatory true;
=A0 =A0 =A0 =A0 =A0 description "Parameter organization (e.g. 'ietf.org
<http://ietf.org> o= r
example.com <http://example.com>')= ";
=A0 =A0 =A0 =A0}

=A0 =A0 =A0}
=A0 }

=A0container capabilities {
=A0 =A0 leaf-list capability {
=A0 =A0 =A0 =A0type inet:uri;
=A0 =A0 =A0 =A0description "Protocol capability identifier.";
=A0 =A0 }
=A0 }

B) Make all query parameters optional to implement
C) Server MUST advertise the parameters it supports.
D) No change in RESTCONF protocol operation requirements
E) Specify 2 URIs (1 for XML and 1 for JSON format)
F) Server MUST advertise at least 1 of (JSON=A0 or XML) URIs
G) Move complex retrieval (collection resource, pagination, etc.)
=A0 =A0 to a new document, but leave query parameters already defined
=A0 =A0 in RESTCONF


Andy


--001a11c1c560d4349605018bf333-- From nobody Tue Aug 26 13:29:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E611A8821 for ; Tue, 26 Aug 2014 13:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 IKGNRflgvrfy for ; Tue, 26 Aug 2014 13:29:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFA71A87D9 for ; Tue, 26 Aug 2014 13:29:27 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E1E5128097A; Tue, 26 Aug 2014 22:26:57 +0200 (CEST) Date: Tue, 26 Aug 2014 22:29:25 +0200 (CEST) Message-Id: <20140826.222925.527517544.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FheSd-EZIAlwp9cCazpZ1omn8Zk Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:29:28 -0000 Andy Bierman wrote: > On Tue, Aug 26, 2014 at 7:22 AM, Ladislav Lhotka wrote: > > > > > On 26 Aug 2014, at 16:07, Andy Bierman wrote: > > > > > +1 JSON is about 40% smaller on-the-wire > > > +1 JSON should require less code space than XML to implement > > > -1 JSON is horrible for streaming (too much state to know and keep) > > > > We should consider draft-ietf-json-text-sequence-06. > > > > > More brand new code to write? Also it is not clear how this works with the hierarchical data models we have. /martin From nobody Tue Aug 26 13:34:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18491A885C for ; Tue, 26 Aug 2014 13:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham 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 37x9KdY26HjJ for ; Tue, 26 Aug 2014 13:34:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B6A731A02F9 for ; Tue, 26 Aug 2014 13:34:24 -0700 (PDT) Received: from localhost (s193-12-221-208.cust.tele2.se [193.12.221.208]) by mail.tail-f.com (Postfix) with ESMTPSA id D9BFB128097A; Tue, 26 Aug 2014 22:31:54 +0200 (CEST) Date: Tue, 26 Aug 2014 22:34:23 +0200 (CEST) Message-Id: <20140826.223423.176169295.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <53FCA5B7.3030105@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Pu6BTZSo0tIibzdgXQAdmRbuKUM Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:34:25 -0000 Andy Bierman wrote: > Hi, > > So maybe we are confirming that we don't have consensus to pick > 1 mandatory encoding format. > > Nobody has complained that the client needs to support both, > so the issue seems to be what to require for the server. I disagree. If it is ok to say that the client MUST support both, it is obvious that it would be ok for the server to pick any format, and we'll still get interoperability. If everybody agreed with this, we wouldn't have this argument. > Since the client MUST support both, then it really doesn't matter at all > which of the 2 formats the server supports. It is trivial to discover the > supported formats from the server. > > I still have not heard any justification for 2 mandatory formats for the > server. > IMO, if we can't pick 1 mandatory, then let the vendor pick, rather than > requiring both. I still think we should pick 1 mandatory for both sides. I don't want to require all clients (or servers) to implement both encodings. /martin From nobody Tue Aug 26 13:50:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1AB1A8834 for ; Tue, 26 Aug 2014 13:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 CeCQkS18cJl5 for ; Tue, 26 Aug 2014 13:50:00 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6877F1A035F for ; Tue, 26 Aug 2014 13:50:00 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id l6so16162692qcy.33 for ; Tue, 26 Aug 2014 13:49:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mopwrybUHIJQf7l9itRyD9lQap0VCGkRjQSylBagkLg=; b=fGNhKBCJ6s/hTVEvf5eSF3uOeZkaB27+tdWXIbRr3ZIFlonlMEFMPddT/UghBtDn96 SOMOxkMqE4JhjwQ+UWKvRwjIYe1HNTzq/pr9cg1JrsAFm0ptJKEBXFJP0gykJSj3m5iX lERI+LyETj168MpKyi9zWZbTqPUsGaQdWYdGC8/ZEWiiZ4H3EgipdKCjfjCLPP8jD9Pc xH1FO2/A3Y0t+T9KhkdwM7PtTYNOeKrHkU9447o/Cv4lhfK/3/9CwWoS0hUfEIzXDQma 3Ame05yWk7ECvfd8C1UtRKCUKnBSW51mwzcojU5GmI1SJ3PxpzZakVxr8NJJGXG3Qt3f C5tA== X-Gm-Message-State: ALoCoQlA0gG7BELdg+z8Urf2wgU5I2xw1vDOoLe7TcNt4H24jStKQNDvov4hEsej7c/7rAyUKJr9 MIME-Version: 1.0 X-Received: by 10.140.98.147 with SMTP id o19mr6815414qge.21.1409086199537; Tue, 26 Aug 2014 13:49:59 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 26 Aug 2014 13:49:59 -0700 (PDT) In-Reply-To: <20140826.223423.176169295.mbj@tail-f.com> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> Date: Tue, 26 Aug 2014 13:49:59 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113a923c62c12805018e727e Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/MqKjCRz_tuU2VRRzWnA7ojHy38U Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:50:03 -0000 --001a113a923c62c12805018e727e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 26, 2014 at 1:34 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > So maybe we are confirming that we don't have consensus to pick > > 1 mandatory encoding format. > > > > Nobody has complained that the client needs to support both, > > so the issue seems to be what to require for the server. > > I disagree. If it is ok to say that the client MUST support both, it > is obvious that it would be ok for the server to pick any format, and > we'll still get interoperability. If everybody agreed with this, we > wouldn't have this argument. > > > Since the client MUST support both, then it really doesn't matter at all > > which of the 2 formats the server supports. It is trivial to discover the > > supported formats from the server. > > > > I still have not heard any justification for 2 mandatory formats for the > > server. > > IMO, if we can't pick 1 mandatory, then let the vendor pick, rather than > > requiring both. > > I still think we should pick 1 mandatory for both sides. I don't want > to require all clients (or servers) to implement both encodings. > > I don't much care which one we choose as mandatory. Both have pros and cons that makes each one imperfect. I've implemented both of them already (except JSON attributes). I don't like the current text which says both are mandatory. I know in our server the custom JSON code is much smaller and faster than libxml2, but somebody could have a small and fast XML library, so IMO implementation details are not a good way to decide. Perhaps the co-chairs should decide how to proceed somehow. > /martin > Andy --001a113a923c62c12805018e727e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 26, 2014 at 1:34 PM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Andy Bierman <and= y@yumaworks.com> wrote:
> Hi,
>
> So maybe we are confirming that we don't have consensus to pick > 1 mandatory encoding format.
>
> Nobody has complained that the client needs to support both,
> so the issue seems to be what to require for the server.

I disagree.=A0 If it is ok to say that the client MUST support both, it
is obvious that it would be ok for the server to pick any format, and
we'll still get interoperability.=A0 If everybody agreed with this, we<= br> wouldn't have this argument.

> Since the client MUST support both, then it really doesn't matter = at all
> which of the 2 formats the server supports. It is trivial to discover = the
> supported formats from the server.
>
> I still have not heard any justification for 2 mandatory formats for t= he
> server.
> IMO, if we can't pick 1 mandatory, then let the vendor pick, rathe= r than
> requiring both.

I still think we should pick 1 mandatory for both sides.=A0 I don't wan= t
to require all clients (or servers) to implement both encodings.



I don't much care which one we choose a= s mandatory.
Both have pros and cons that makes each one imperfec= t.
I've implemented both of them already (except JSON attributes).
I don't like the current text which says both are mandatory.

I know in our server the custom JSON code is much sm= aller and faster than libxml2,
but somebody could have a small and fast XML library, so
IMO= implementation details are not a good way to decide.

<= div>Perhaps the co-chairs should decide how to proceed somehow.


/martin

Andy<= /div>

--001a113a923c62c12805018e727e-- From nobody Wed Aug 27 00:03:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15DE1A0427 for ; Wed, 27 Aug 2014 00:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 EF8LR9c1RDkh for ; Wed, 27 Aug 2014 00:03:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1B01A042D for ; Wed, 27 Aug 2014 00:03:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 879E054075D; Wed, 27 Aug 2014 09:03:13 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjPRGUGk2gN4; Wed, 27 Aug 2014 09:03:08 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 33166540145; Wed, 27 Aug 2014 09:03:08 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140826164422.GA56605@elstar.local> References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> <20140826164422.GA56605@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 27 Aug 2014 09:03:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/67prhgS7F8eNpqdep1lps1xHwnA Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:03:20 -0000 Juergen Schoenwaelder writes: > On Tue, Aug 26, 2014 at 04:22:35PM +0200, Ladislav Lhotka wrote: >> >> > -1 JSON does not support 64 bit numbers >> >> Not true. The issue only appears in I-JSON because presumably some (most?) existing decoders read JSON numbers into double precision floats. >> > > I disagree with both statements. > > a) The JSON specification [RFC7159] says: > > This specification allows implementations to set limits on the range > and precision of numbers accepted. Since software that implements > IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is > generally available and widely used, good interoperability can be > achieved by implementations that expect no more precision or range > than these provide, in the sense that implementations will > approximate JSON numbers within the expected precision. A JSON > number such as 1E400 or 3.141592653589793238462643383279 may indicate > potential interoperability problems, since it suggests that the > software that created it expects receiving software to have greater > capabilities for numeric magnitude and precision than is widely > available. > > Note that when such software is used, numbers that are integers and > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > sense that implementations will agree exactly on their numeric > values. > > So this is not an I-JSON issue. JSON as "a text format for the serialization of structured data" impose no restrictions whatsoever on the size of a number. The text you mention says that *some implementations* may set restrictions. It is certainly not the case for all implementations: $ python Python 2.7.8 (default, Jul 2 2014, 10:14:46) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> json.loads('{"pi40": 1415926535897932384626433832795028841971}') {u'pi40': 1415926535897932384626433832795028841971L} The aeson decoder in Haskell also provides integers of unbounded size when asked to do so. I-JSON is a restricted profile of JSON that tries to ensure interoperability, no matter what JSON decoder is used. So it says: "I-JSON messages SHOULD NOT include numbers which express greater magnitude or precision than an IEEE 754 double precision number provides, ..." > > b) 64-bit numbers can of course be encoded in JSON by encoding them as > strings. (This is not worse than encoding them as strings in XML.) How is this related to the question whether JSON or I-JSON support 64-bit numbers? > > Note that this may also affect YANG's decimal64 type. The YANG to JSON > I-D simply needs to say the right thing. Yes, we can use this as a workaround for ensuring maximum interoperability. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 00:13:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2AD1A0422 for ; Wed, 27 Aug 2014 00:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 Fs_WSc-6pZJQ for ; Wed, 27 Aug 2014 00:13:04 -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 EA8531A0450 for ; Wed, 27 Aug 2014 00:13:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BB9141376; Wed, 27 Aug 2014 09:13:02 +0200 (CEST) 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 hSIrrfIRu1Zz; Wed, 27 Aug 2014 09:13:00 +0200 (CEST) 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; Wed, 27 Aug 2014 09:13:01 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C891A20035; Wed, 27 Aug 2014 09:13:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1zc0gaD3nBhi; Wed, 27 Aug 2014 09:13:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E229720033; Wed, 27 Aug 2014 09:12:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3E2FD2E50A26; Wed, 27 Aug 2014 09:12:59 +0200 (CEST) Date: Wed, 27 Aug 2014 09:12:58 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140827071258.GA57886@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> <20140826164422.GA56605@elstar.local> 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/netconf/LHJH1DSx_aorgh1DtrpAJocRQ_o Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:13:06 -0000 On Wed, Aug 27, 2014 at 09:03:05AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Tue, Aug 26, 2014 at 04:22:35PM +0200, Ladislav Lhotka wrote: > >> > >> > -1 JSON does not support 64 bit numbers > >> > >> Not true. The issue only appears in I-JSON because presumably some (most?) existing decoders read JSON numbers into double precision floats. > >> > > > > I disagree with both statements. > > > > a) The JSON specification [RFC7159] says: > > > > This specification allows implementations to set limits on the range > > and precision of numbers accepted. Since software that implements > > IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is > > generally available and widely used, good interoperability can be > > achieved by implementations that expect no more precision or range > > than these provide, in the sense that implementations will > > approximate JSON numbers within the expected precision. A JSON > > number such as 1E400 or 3.141592653589793238462643383279 may indicate > > potential interoperability problems, since it suggests that the > > software that created it expects receiving software to have greater > > capabilities for numeric magnitude and precision than is widely > > available. > > > > Note that when such software is used, numbers that are integers and > > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > > sense that implementations will agree exactly on their numeric > > values. > > > > So this is not an I-JSON issue. > > JSON as "a text format for the serialization of structured data" impose > no restrictions whatsoever on the size of a number. The text you mention > says that *some implementations* may set restrictions. It is certainly > not the case for all implementations: > > $ python > Python 2.7.8 (default, Jul 2 2014, 10:14:46) > [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import json > >>> json.loads('{"pi40": 1415926535897932384626433832795028841971}') > {u'pi40': 1415926535897932384626433832795028841971L} > > The aeson decoder in Haskell also provides integers of unbounded size > when asked to do so. > > I-JSON is a restricted profile of JSON that tries to ensure > interoperability, no matter what JSON decoder is used. So it says: > > "I-JSON messages SHOULD NOT include numbers which express greater > magnitude or precision than an IEEE 754 double precision number > provides, ..." The IETF work is about interoperability. It is great if Python or Haskell implementations do not suffer from this problem but the fact that some implementations do not map numbers to IEEE doubles does not change the fact that other popular implementations make this assumption. And the reason is that IEEE doubles are JavaScript numbers and remember that JSON has its roots in JavaScript. Since the IETF is about interoperability, I think we really should try hard to follow I-JSON. > > b) 64-bit numbers can of course be encoded in JSON by encoding them as > > strings. (This is not worse than encoding them as strings in XML.) > > How is this related to the question whether JSON or I-JSON support 64-bit numbers? Since I believe JSON does not support 64-bit numbers in an interoperable way if they are encoded as numbers, we need to find workarounds. If you know a better one, tell us. /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 Wed Aug 27 00:34:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7851A0452 for ; Wed, 27 Aug 2014 00:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 TjaK53Ych0si for ; Wed, 27 Aug 2014 00:34:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209CD1A0457 for ; Wed, 27 Aug 2014 00:34:26 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id BB2D4141B80; Wed, 27 Aug 2014 09:34:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409124865; bh=Wlj3fpzncQsuERraD7H8v5pEWizn5ONLrQulCyohmIU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nQK2wOQFfX1MLj5hcgVAdFX/kRUbDGniG3spdNwW9RqV5TWXVLKW4kI7KbfygoIon c79q+7Xsn8SPy050IMAi1Wq9nGQ44NWN0/Ej61yjRpBIikuWfh4j1Tek6qVnsqOXjO 7DeXo6rrK7C9t1sY5LZtwY8HzEJkNfeL73VJXtww= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140827071258.GA57886@elstar.local> Date: Wed, 27 Aug 2014 09:34:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0AF35C39-3DD5-49BF-9404-5B503E298EF4@nic.cz> References: <20140825.205054.364839469.mbj@tail-f.com> <6F76D04C-6E4F-4DEE-9ABB-0D4499734CC4@nic.cz> <53FBC7F1.4080706@cisco.com> <8C3624C3-2207-4746-A638-2555510545DB@nic.cz> <20140826100638.GA55618@elstar.local> <20140826164422.GA56605@elstar.local> <20140827071258.GA57886@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Z1YMNDjg22fEA9QLb2vmX2Rg0kE Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:34:29 -0000 On 27 Aug 2014, at 09:12, Juergen Schoenwaelder = wrote: > On Wed, Aug 27, 2014 at 09:03:05AM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Tue, Aug 26, 2014 at 04:22:35PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>> -1 JSON does not support 64 bit numbers >>>>=20 >>>> Not true. The issue only appears in I-JSON because presumably some = (most?) existing decoders read JSON numbers into double precision = floats. >>>>=20 >>>=20 >>> I disagree with both statements. >>>=20 >>> a) The JSON specification [RFC7159] says: >>>=20 >>> This specification allows implementations to set limits on the = range >>> and precision of numbers accepted. Since software that = implements >>> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is >>> generally available and widely used, good interoperability can = be >>> achieved by implementations that expect no more precision or = range >>> than these provide, in the sense that implementations will >>> approximate JSON numbers within the expected precision. A JSON >>> number such as 1E400 or 3.141592653589793238462643383279 may = indicate >>> potential interoperability problems, since it suggests that the >>> software that created it expects receiving software to have = greater >>> capabilities for numeric magnitude and precision than is widely >>> available. >>>=20 >>> Note that when such software is used, numbers that are integers = and >>> are in the range [-(2**53)+1, (2**53)-1] are interoperable in = the >>> sense that implementations will agree exactly on their numeric >>> values. >>>=20 >>> So this is not an I-JSON issue. >>=20 >> JSON as "a text format for the serialization of structured data" = impose >> no restrictions whatsoever on the size of a number. The text you = mention >> says that *some implementations* may set restrictions. It is = certainly >> not the case for all implementations: >>=20 >> $ python >> Python 2.7.8 (default, Jul 2 2014, 10:14:46)=20 >> [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin >> Type "help", "copyright", "credits" or "license" for more = information. >>>>> import json >>>>> json.loads('{"pi40": 1415926535897932384626433832795028841971}') >> {u'pi40': 1415926535897932384626433832795028841971L}=20 >>=20 >> The aeson decoder in Haskell also provides integers of unbounded size >> when asked to do so. >>=20 >> I-JSON is a restricted profile of JSON that tries to ensure >> interoperability, no matter what JSON decoder is used. So it says: >>=20 >> "I-JSON messages SHOULD NOT include numbers which express greater >> magnitude or precision than an IEEE 754 double precision number >> provides, ..." >=20 > The IETF work is about interoperability. It is great if Python or > Haskell implementations do not suffer from this problem but the fact > that some implementations do not map numbers to IEEE doubles does not > change the fact that other popular implementations make this > assumption. And the reason is that IEEE doubles are JavaScript numbers > and remember that JSON has its roots in JavaScript. This is all fine, but Andy listed =93lack of support for 64-bit numbers=94= as a minus point for JSON and I objected against that. >=20 > Since the IETF is about interoperability, I think we really should try > hard to follow I-JSON. That=92s the question that is important for yang-json. I plan to open it = in another thread. >=20 >>> b) 64-bit numbers can of course be encoded in JSON by encoding them = as >>> strings. (This is not worse than encoding them as strings in XML.) >>=20 >> How is this related to the question whether JSON or I-JSON support = 64-bit numbers?=20 >=20 > Since I believe JSON does not support 64-bit numbers in an > interoperable way if they are encoded as numbers, we need to find > workarounds. If you know a better one, tell us. Again, JSON is a text format that supports numbers of any size. = Interoperability is a concern for those who want to use JSON for = encoding protocol messages. And yes, that=92s us. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Aug 27 00:52:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A8E1A048E for ; Wed, 27 Aug 2014 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 ZfC8Rj0dhmzW for ; Wed, 27 Aug 2014 00:52:09 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id BA54B1A0484 for ; Wed, 27 Aug 2014 00:52:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=I8sBYUsQNWOG6nZbhyTni3C7A1HwbAWnhn9UBOZW+RDH8RqrsPgbdlro8d/Oxowq; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XMY1T-0001dl-Jf; Wed, 27 Aug 2014 03:52:03 -0400 Received: from 76.254.52.166 by webmail.earthlink.net with HTTP; Wed, 27 Aug 2014 03:52:03 -0400 Message-ID: <1458904.1409125923504.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Wed, 27 Aug 2014 00:52:03 -0700 (GMT-07:00) From: Randy Presuhn To: Ladislav Lhotka , Juergen Schoenwaelder Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd81c9ccbcce28d88f48b427303e9d93151e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hVyAiNFUagd_o3lnfz-f5q3DIeY Cc: Netconf Subject: Re: [Netconf] RESTCONF modularilty X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 07:52:16 -0000 Hi - >From: Ladislav Lhotka >Sent: Aug 27, 2014 12:03 AM >To: Juergen Schoenwaelder >Cc: Netconf >Subject: Re: [Netconf] RESTCONF modularilty ... >I-JSON is a restricted profile of JSON that tries to ensure >interoperability, no matter what JSON decoder is used. So it says: > >"I-JSON messages SHOULD NOT include numbers which express greater >magnitude or precision than an IEEE 754 double precision number >provides, ..." Which is to say, not all 64-bit integers can be safely represented, since they require greater precision than IEEE 754 double precision provides, since the latter uses 11 of its 64 bits for exponent. Randy