From bertietf@bwijnen.net Mon Mar 5 12:12:07 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E40C21F88FF for ; Mon, 5 Mar 2012 12:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWeVIL08H+IT for ; Mon, 5 Mar 2012 12:12:06 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83A21F88B5 for ; Mon, 5 Mar 2012 12:12:06 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1S4eGK-0008Nl-5F for netconf@ietf.org; Mon, 05 Mar 2012 21:12:05 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1S4eGJ-0004oX-QF for netconf@ietf.org; Mon, 05 Mar 2012 21:12:03 +0100 Message-ID: <4F551E13.2000907@bwijnen.net> Date: Mon, 05 Mar 2012 21:12:03 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4247a3f148150f32ee19ee32c672a5c45 Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:12:07 -0000 If I am correct, then, after Mehmet's call for discussion and to express interest, I have seen - Badra supports (editor/author) - Juergen supports (contributed to the document) - Mehmet supports Did I miss any? Do our other netconf implementers (Andy, Martin, Lada? Juniper-folk) not want to express an opinion? Bert (co-chair hat on) On 2/14/12 1:00 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > we had a discussion on draft-badra-netconf-rfc5539bis in Taipei and people > > were agreeing that this work is needed if we want to keep NETCONF over TLS > > on the standards track. > > The revision posted yesterday updates RFC 5539 fitting the changes in RFC > > 6241 and is covered by our charter. > > The co-chairs believe that there is sufficient interest on this document > > to be a working group item. So we encourage discussion here so that we > > can make the next steps and if the interest indeed shows, then make it a > > WG document. > > Please state your opinion (including draft authors and contributors) on the > > ML concerning the importance of this draft and updating RFC 5539, within > > the next two weeks. > > Another important questions is: Who is going to implement the update? > > The optimal case would be if we can already discuss any implementation > > experience in IETF #83. > > Mehmet & Bert > > *From:*ext Mohamad Badra [mailto:mbadra@gmail.com] > *Sent:* Monday, February 13, 2012 11:00 PM > *To:* netconf@ietf.org > *Cc:* Ersue, Mehmet (NSN - DE/Munich); ext Bert Wijnen (IETF) > *Subject:* New version of draft-badra-netconf-rfc5539bis > > Dear All, > > I posted a new version of draft-badra-netconf-rfc5539bis and would appreciate your comments. Enclosed is the diff file. > > The document URL: http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-01.txt > > WG Chairs, I would like to ask adoption the document as WG item. > > Best regards, > > Badra > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Mon Mar 5 12:23:55 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D884121F8870 for ; Mon, 5 Mar 2012 12:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0V01r7N4VE2 for ; Mon, 5 Mar 2012 12:23:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0E75811E809B for ; Mon, 5 Mar 2012 12:23:47 -0800 (PST) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 462512A01A6; Mon, 5 Mar 2012 21:23:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330979026; bh=J18ooT/BGeX4VBS9Sxg4fgtdCeLgtqwvdzYHp9VM+Wk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KDbxIBCF7P8WSrblzb17W0SJ4y8QfAniy4k5TWUwxC+UhvD3kYS0BDELU5Ka6rsyW 2EdDfuuCxwI3snYuSAS7Jdnm7zVVNQvy2zCnMIb10ugpMY8afnbxYS99KMVxTUhrZq E0c56KSS+JvpnO4qa0s+IXbj19ZTLI+NbbiisF4w= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4F551E13.2000907@bwijnen.net> Date: Mon, 5 Mar 2012 21:23:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <773CFBCB-3BE8-4D83-886A-9CF99C516561@nic.cz> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> To: "Bert Wijnen (IETF)" X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:23:56 -0000 On Mar 5, 2012, at 9:12 PM, Bert Wijnen (IETF) wrote: > If I am correct, then, after Mehmet's call for > discussion and to express interest, I have seen >=20 > - Badra supports (editor/author) > - Juergen supports (contributed to the document) > - Mehmet supports >=20 > Did I miss any? >=20 > Do our other netconf implementers (Andy, Martin, Lada? > Juniper-folk) not want to express an opinion? I do support the update of 5539, but since I recently changed my job I = cannot promise an implementation. Lada >=20 > Bert (co-chair hat on) >=20 > On 2/14/12 1:00 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Dear NETCONF WG, >>=20 >> we had a discussion on draft-badra-netconf-rfc5539bis in Taipei and = people >>=20 >> were agreeing that this work is needed if we want to keep NETCONF = over TLS >>=20 >> on the standards track. >>=20 >> The revision posted yesterday updates RFC 5539 fitting the changes in = RFC >>=20 >> 6241 and is covered by our charter. >>=20 >> The co-chairs believe that there is sufficient interest on this = document >>=20 >> to be a working group item. So we encourage discussion here so that = we >>=20 >> can make the next steps and if the interest indeed shows, then make = it a >>=20 >> WG document. >>=20 >> Please state your opinion (including draft authors and contributors) = on the >>=20 >> ML concerning the importance of this draft and updating RFC 5539, = within >>=20 >> the next two weeks. >>=20 >> Another important questions is: Who is going to implement the update? >>=20 >> The optimal case would be if we can already discuss any = implementation >>=20 >> experience in IETF #83. >>=20 >> Mehmet & Bert >>=20 >> *From:*ext Mohamad Badra [mailto:mbadra@gmail.com] >> *Sent:* Monday, February 13, 2012 11:00 PM >> *To:* netconf@ietf.org >> *Cc:* Ersue, Mehmet (NSN - DE/Munich); ext Bert Wijnen (IETF) >> *Subject:* New version of draft-badra-netconf-rfc5539bis >>=20 >> Dear All, >>=20 >> I posted a new version of draft-badra-netconf-rfc5539bis and would = appreciate your comments. Enclosed is the diff file. >>=20 >> The document URL: = http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-01.txt >>=20 >> WG Chairs, I would like to ask adoption the document as WG item. >>=20 >> Best regards, >>=20 >> Badra >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From wwwrun@rfc-editor.org Wed Mar 7 17:43:05 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2914F21E8034; Wed, 7 Mar 2012 17:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYMFs9H3lNZo; Wed, 7 Mar 2012 17:43:04 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B2A8221E8033; Wed, 7 Mar 2012 17:43:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7D99372E00C; Wed, 7 Mar 2012 17:42:54 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120308014254.7D99372E00C@rfc-editor.org> Date: Wed, 7 Mar 2012 17:42:54 -0800 (PST) Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 6536 on Network Configuration Protocol (NETCONF) Access Control Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:43:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6536 Title: Network Configuration Protocol (NETCONF) Access Control Model Author: A. Bierman, M. Bjorklund Status: Standards Track Stream: IETF Date: March 2012 Mailbox: andy@yumaworks.com, mbj@tail-f.com Pages: 49 Characters: 90803 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-access-control-07.txt URL: http://www.rfc-editor.org/rfc/rfc6536.txt The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From bertietf@bwijnen.net Thu Mar 8 04:41:17 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF7721F867D for ; Thu, 8 Mar 2012 04:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.39 X-Spam-Level: X-Spam-Status: No, score=-99.39 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_93=0.6, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLX3yUn6m417 for ; Thu, 8 Mar 2012 04:41:17 -0800 (PST) Received: from relay57.tele2.vuurwerk.nl (relay57.tele2.vuurwerk.nl [62.250.3.57]) by ietfa.amsl.com (Postfix) with ESMTP id BCFCA21F8664 for ; Thu, 8 Mar 2012 04:41:16 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1S5ceg-0005gq-MF for netconf@ietf.org; Thu, 08 Mar 2012 13:41:14 +0100 Message-ID: <63BEB15F2AD541958D85A957125060CC@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" Date: Thu, 8 Mar 2012 13:33:30 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: [Netconf] Fw: RFC 6536 on Network Configuration Protocol (NETCONF)Access Control Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:41:17 -0000 Congrats to the WG for another good RFC. Soecial thanks go of course to Andy and Martin. Bert Wijnen co-chair and document shepherd ----- Original Message ----- From: To: ; Cc: ; Sent: Thursday, March 08, 2012 2:42 AM Subject: [Netconf] RFC 6536 on Network Configuration Protocol (NETCONF)Access Control Model > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6536 > > Title: Network Configuration Protocol (NETCONF) Access > Control Model > Author: A. Bierman, M. Bjorklund > Status: Standards Track > Stream: IETF > Date: March 2012 > Mailbox: andy@yumaworks.com, > mbj@tail-f.com > Pages: 49 > Characters: 90803 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-netconf-access-control-07.txt > > URL: http://www.rfc-editor.org/rfc/rfc6536.txt > > The standardization of network configuration interfaces for use with > the Network Configuration Protocol (NETCONF) requires a structured > and secure operating environment that promotes human usability and > multi-vendor interoperability. There is a need for standard > mechanisms to restrict NETCONF protocol access for particular users > to a pre-configured subset of all available NETCONF protocol > operations and content. This document defines such an access control > model. [STANDARDS-TRACK] > > This document is a product of the Network Configuration Working Group of the > IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From dromasca@avaya.com Thu Mar 8 06:25:57 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D7F21F8630; Thu, 8 Mar 2012 06:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.068 X-Spam-Level: X-Spam-Status: No, score=-103.068 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCWcCWrpPSkl; Thu, 8 Mar 2012 06:25:56 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 141CE21F84A1; Thu, 8 Mar 2012 06:25:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAD7AWE+HCzI1/2dsb2JhbABDtR6BB4IKAQEBAQMBAQEPHgoUIAsMBAIBCA0EAwEBAQsCBAwLAQYBJgoVCQgBAQQBEggBCwcCBAGHaAueCZwsiieFZGMEm0yKEYJkgVs X-IronPort-AV: E=Sophos;i="4.73,552,1325480400"; d="scan'208";a="295761288" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Mar 2012 09:25:13 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 08 Mar 2012 09:09:57 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 15:25:04 +0100 Message-ID: In-Reply-To: <20120308014254.7D99372E00C@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 6536 on Network Configuration Protocol (NETCONF) Access ControlModel Thread-Index: Acz8zPoL0dFl6hMiQNWI2K13l2EitwAaisNg References: <20120308014254.7D99372E00C@rfc-editor.org> From: "Romascanu, Dan (Dan)" To: , , Cc: netconf@ietf.org Subject: Re: [Netconf] RFC 6536 on Network Configuration Protocol (NETCONF) Access ControlModel X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:25:57 -0000 Thanks and congratulations to the editors, chairs, and the whole WG for having this important NETCONF RFC published.=20 > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org > Sent: Thursday, March 08, 2012 3:43 AM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netconf@ietf.org; rfc-editor@rfc-editor.org > Subject: RFC 6536 on Network Configuration Protocol (NETCONF) Access > ControlModel >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6536 >=20 > Title: Network Configuration Protocol (NETCONF) Access > Control Model > Author: A. Bierman, M. Bjorklund > Status: Standards Track > Stream: IETF > Date: March 2012 > Mailbox: andy@yumaworks.com, > mbj@tail-f.com > Pages: 49 > Characters: 90803 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-netconf-access-control-07.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6536.txt >=20 > The standardization of network configuration interfaces for use with > the Network Configuration Protocol (NETCONF) requires a structured > and secure operating environment that promotes human usability and > multi-vendor interoperability. There is a need for standard > mechanisms to restrict NETCONF protocol access for particular users > to a pre-configured subset of all available NETCONF protocol > operations and content. This document defines such an access control > model. [STANDARDS-TRACK] >=20 > This document is a product of the Network Configuration Working Group > of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From kwatsen@juniper.net Thu Mar 8 19:20:51 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B045611E8072 for ; Thu, 8 Mar 2012 19:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3Y+mYrFPDoy for ; Thu, 8 Mar 2012 19:20:49 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 56A6E21E8011 for ; Thu, 8 Mar 2012 19:20:49 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT1l3EI8avleXkYoaCGGhkXZv8OiHYwuM@postini.com; Thu, 08 Mar 2012 19:20:49 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 8 Mar 2012 19:19:57 -0800 From: Kent Watsen To: Netconf Date: Thu, 8 Mar 2012 19:19:54 -0800 Thread-Topic: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis Thread-Index: Acz7DEAvuZduDkM2T+ulrHmLNx3UqwCVmlNQ Message-ID: <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> In-Reply-To: <4F551E13.2000907@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 03:20:51 -0000 Section 2.1: "It MUST connect to the server that passively listens for the = incoming TLS connection on the TCP port 6513". This language eliminates th= e possibility of implementing a "reverse-tls" mechanism like we have with "= reverse-ssh". Since one of the motivators for this work is to support low-= end devices, I would think a need for a call-home mechanism would be desire= d. That said, it might be hard to implement since SSH uses a named subsyst= em ("netconf"), maybe this is more reason to support bidirectional TLS conn= ections? [Note: this language was also in RFC5539] Section 2.2: what about ? - why define another mechanism? = If important, then why doesn't RFC6242 require the client to send SSH_MSG_C= HANNEL_CLOSE and/or SSH_MSG_DISCONNECT. Regardless, I disagree with the i= ntent of forcing graceful closures - in reality, devices MUST be coded to s= upport ungraceful closures and, once the code is written, there isn't much = value to a graceful close anymore. Also the second paragraph seems out of = place - shouldn't it be in the TLS RFC? [Note: this language was also in RF= C5539] Section 3.1 - RFC4642 places these recommendations into its "Security Consi= derations" section - should this draft do the same? If this draft is going= to specify this information, then should it first state that the client SH= OULD validate the server's certificate chain (i.e. a trusted CA, no expirat= ions, no revocations, etc.)? Note: this language was also in RFC5539] Section 3.2.1 - What happens if subjectAltName contains more than one ipAdd= ress, dnsName, or rfc822Name - as allowed by RFC 5280 section 4.2.1.6? Section 3.2.1.1 - This whole section should be rewritten - it's hard to fol= low as is. I think there is an implicit assumption that the client's certi= ficate is trusted; that is, that the TLS layer would not have allowed the c= onnection if couldn't validate the certificate. Does this assumption need t= o be stated explicitly? Third paragraph is about being able to apply tran= sformation based on the identification of the issuing CA, a good idea, but = shouldn't this be after exhausting all direct-match options. Lastly, what i= s a "transformation container"? Section 3.2.1.3: Regarding "description" - Is the second sentence redundant? "It specifies h= ow NETCONF servers transform X.509 certificates presented by clients into N= ETCONF usernames. It also specifies how NETCONF clients transform NETCONF = usernames into X.509 certificates for presentation to NETCONF servers." Regarding "tls-fingerprint-type" - how can it be of length '0'? - the last= paragraph says it's to support containers where the fingerprint may be opt= ional, but shouldn't those containers simply not specific "mandatory true"?= The 2nd paragraph regards an encoding, does this mean that implementation= s MUST support all the hash algorithms listed in IANA's registry? Regarding "certificate-to-username-transform-count" - this type doesn't see= m to be referenced anywhere - remove it? Regarding "certificate-to-username-transform-last-changed" - this type does= n't seem to be referenced anywhere - remove it? Besides, why reset the val= ue to '0' just because the NetConf server restarted? Regarding "certificate-to-username-transforms" 1) the statement "the client's presented certificate MUST either be valid= ated based on an established trust anchor, or it MUST directly match a fing= erprint in this container." is surprising - does this mean that the TLS se= rver MUST be coded to allow connections having client certificates that can= not be authenticated at the TLS-level? I had assumed that this RFC was onl= y proscribing how to extract an identity, but this proscribes an authentica= tion strategy - is that right? 2) the statement "If the list entry's certificate-fingerprint value match= es that of a locally held copy of a trusted CA certificate, and that CA cer= tificate was used to validate the path to the presented certificate, then c= onsider the list entry as a successful match." - what is the "path"? - do y= ou mean the certificate chain? - how does the server know this? I need to = see an example. 3) the statement "Non-consecutive values of index are acceptable and impl= ementations should continue to the next highest numbered list entry. It is= recommended that administrators skip index values to leave room for the in= sertion of future list entries (for example, use values of 10 and 20 when c= reating initial list entries)." - why not just use an ordered list? Regarding certificate-fingerprint - why is the length on "tls-fingerprint-t= ype" further constrained? Regarding "data" - should a regex be used to constrain it to valid username= format? Regarding "psk-map" - why have "valid-not-before" and "valid-not-after" - a= ren't these already specified in the certificate? If not, then why not jus= t have the configuration added/removed when becoming valid/invalid? Should= we start adding time-based constraints to all our YANG models? PS: I will not be checking mail tomorrow, in case you're wondering why I do= n't post any follow-up responses Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Bert Wijnen (IETF) Sent: Monday, March 05, 2012 3:12 PM To: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra= -netconf-rfc5539bis If I am correct, then, after Mehmet's call for discussion and to express interest, I have seen - Badra supports (editor/author) - Juergen supports (contributed to the document) - Mehmet supports Did I miss any? Do our other netconf implementers (Andy, Martin, Lada? Juniper-folk) not want to express an opinion? Bert (co-chair hat on) On 2/14/12 1:00 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > we had a discussion on draft-badra-netconf-rfc5539bis in Taipei and peopl= e > > were agreeing that this work is needed if we want to keep NETCONF over TL= S > > on the standards track. > > The revision posted yesterday updates RFC 5539 fitting the changes in RFC > > 6241 and is covered by our charter. > > The co-chairs believe that there is sufficient interest on this document > > to be a working group item. So we encourage discussion here so that we > > can make the next steps and if the interest indeed shows, then make it a > > WG document. > > Please state your opinion (including draft authors and contributors) on t= he > > ML concerning the importance of this draft and updating RFC 5539, within > > the next two weeks. > > Another important questions is: Who is going to implement the update? > > The optimal case would be if we can already discuss any implementation > > experience in IETF #83. > > Mehmet & Bert > > *From:*ext Mohamad Badra [mailto:mbadra@gmail.com] > *Sent:* Monday, February 13, 2012 11:00 PM > *To:* netconf@ietf.org > *Cc:* Ersue, Mehmet (NSN - DE/Munich); ext Bert Wijnen (IETF) > *Subject:* New version of draft-badra-netconf-rfc5539bis > > Dear All, > > I posted a new version of draft-badra-netconf-rfc5539bis and would apprec= iate your comments. Enclosed is the diff file. > > The document URL: http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-0= 1.txt > > WG Chairs, I would like to ask adoption the document as WG item. > > Best regards, > > Badra > > > > _______________________________________________ > 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 From andy@netconfcentral.org Thu Mar 8 19:30:32 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2984F21F85B1 for ; Thu, 8 Mar 2012 19:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjU7KPG9cppJ for ; Thu, 8 Mar 2012 19:30:31 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 737EF21F85AF for ; Thu, 8 Mar 2012 19:30:31 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q293UU2T013390 for ; Thu, 8 Mar 2012 22:30:30 -0500 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:46397] helo=[192.168.0.9]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 49/94-25317-659795F4; Thu, 08 Mar 2012 22:30:30 -0500 Message-ID: <4F597956.6000807@netconfcentral.org> Date: Thu, 08 Mar 2012 19:30:30 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> In-Reply-To: <4F551E13.2000907@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 03:30:32 -0000 On 03/05/2012 12:12 PM, Bert Wijnen (IETF) wrote: > If I am correct, then, after Mehmet's call for > discussion and to express interest, I have seen > > - Badra supports (editor/author) > - Juergen supports (contributed to the document) > - Mehmet supports > > Did I miss any? > > Do our other netconf implementers (Andy, Martin, Lada? > Juniper-folk) not want to express an opinion? > I have not received any requests so far to implement a TLS transport for yuma. Nobody has volunteered either. I do not oppose this draft, but I do not have the resources to implement it or even review it. > Bert (co-chair hat on) Andy > > On 2/14/12 1:00 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Dear NETCONF WG, >> >> we had a discussion on draft-badra-netconf-rfc5539bis in Taipei and people >> >> were agreeing that this work is needed if we want to keep NETCONF over TLS >> >> on the standards track. >> >> The revision posted yesterday updates RFC 5539 fitting the changes in RFC >> >> 6241 and is covered by our charter. >> >> The co-chairs believe that there is sufficient interest on this document >> >> to be a working group item. So we encourage discussion here so that we >> >> can make the next steps and if the interest indeed shows, then make it a >> >> WG document. >> >> Please state your opinion (including draft authors and contributors) on the >> >> ML concerning the importance of this draft and updating RFC 5539, within >> >> the next two weeks. >> >> Another important questions is: Who is going to implement the update? >> >> The optimal case would be if we can already discuss any implementation >> >> experience in IETF #83. >> >> Mehmet & Bert >> >> *From:*ext Mohamad Badra [mailto:mbadra@gmail.com] >> *Sent:* Monday, February 13, 2012 11:00 PM >> *To:* netconf@ietf.org >> *Cc:* Ersue, Mehmet (NSN - DE/Munich); ext Bert Wijnen (IETF) >> *Subject:* New version of draft-badra-netconf-rfc5539bis >> >> Dear All, >> >> I posted a new version of draft-badra-netconf-rfc5539bis and would appreciate your comments. Enclosed is the diff file. >> >> The document URL: http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-01.txt >> >> WG Chairs, I would like to ask adoption the document as WG item. >> >> Best regards, >> >> Badra >> >> >> >> _______________________________________________ >> 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 > > From j.schoenwaelder@jacobs-university.de Thu Mar 8 23:06:52 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6488421F8623 for ; Thu, 8 Mar 2012 23:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cuXMBI-Uq6P for ; Thu, 8 Mar 2012 23:06:51 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8195A21F85B1 for ; Thu, 8 Mar 2012 23:06:51 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DDDA20D36; Fri, 9 Mar 2012 08:06:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z5VDkBy-aGGS; Fri, 9 Mar 2012 08:06:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D88920D35; Fri, 9 Mar 2012 08:06:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C0D571DAB0A1; Fri, 9 Mar 2012 08:06:49 +0100 (CET) Date: Fri, 9 Mar 2012 08:06:49 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120309070649.GA4699@elstar.local> Mail-Followup-To: Kent Watsen , Netconf References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 07:06:52 -0000 On Thu, Mar 08, 2012 at 07:19:54PM -0800, Kent Watsen wrote: > > Section 2.2: what about ? - why define another mechanism? If important, then why doesn't RFC6242 require the client to send SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT. Regardless, I disagree with the intent of forcing graceful closures - in reality, devices MUST be coded to support ungraceful closures and, once the code is written, there isn't much value to a graceful close anymore. Also the second paragraph seems out of place - shouldn't it be in the TLS RFC? [Note: this language was also in RFC5539] > Proper closure of the TLS session is important to be able to distinguish a proper closing of the session from a potentially malicious closing of the session. I guess the same applies for SSH. Sure, you can't prevent arbitrary TCP failures but a proper shutdown procedure tells the other end that the closure was done by intention. In other words, from a security point of view, I think RFC6242 should have also encouraged proper SSH shutdown. > Regarding "psk-map" - why have "valid-not-before" and > "valid-not-after" - aren't these already specified in the > certificate? If not, then why not just have the configuration > added/removed when becoming valid/invalid? Should we start adding > time-based constraints to all our YANG models? With pre-shared keys, there are no certificates involved. To accomplish key rollovers, you need to provision multiple keys and tell the server when they are valid. (You obviously can't install a new key with NETCONF if the old key has expired - so this really needs to be done before the old key expires.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Mar 8 23:40:33 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22ED321F8666 for ; Thu, 8 Mar 2012 23:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZMQ5XJnsdjc for ; Thu, 8 Mar 2012 23:40:32 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3172F21F8663 for ; Thu, 8 Mar 2012 23:40:32 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6873012008FC; Fri, 9 Mar 2012 08:40:30 +0100 (CET) Date: Fri, 09 Mar 2012 08:40:29 +0100 (CET) Message-Id: <20120309.084029.1194116037571574718.mbj@tail-f.com> To: andy@netconfcentral.org From: Martin Bjorklund In-Reply-To: <4F597956.6000807@netconfcentral.org> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <4F597956.6000807@netconfcentral.org> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 07:40:33 -0000 Andy Bierman wrote: > On 03/05/2012 12:12 PM, Bert Wijnen (IETF) wrote: > > If I am correct, then, after Mehmet's call for > > discussion and to express interest, I have seen > > > > - Badra supports (editor/author) > > - Juergen supports (contributed to the document) > > - Mehmet supports > > > > Did I miss any? > > > > Do our other netconf implementers (Andy, Martin, Lada? > > Juniper-folk) not want to express an opinion? > > > > I have not received any requests so far to implement a TLS transport > for yuma. Same for us. We haven't implemented it, and we have never had any requests for it. > Nobody has volunteered either. I do not oppose this draft, I don't oppose it either, but at the same time I don't quite see the value in having this transport. I will review if the WG decides to do it though. /martin From mbadra@gmail.com Fri Mar 9 01:39:23 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004EE21F8574 for ; Fri, 9 Mar 2012 01:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.023 X-Spam-Level: X-Spam-Status: No, score=-3.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLPbXLUDtp0i for ; Fri, 9 Mar 2012 01:39:22 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBDB21F8446 for ; Fri, 9 Mar 2012 01:39:18 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1406552vcb.31 for ; Fri, 09 Mar 2012 01:39:17 -0800 (PST) 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=RI6KzEDsBKs/yuDy72W6l103oz7gEFpEpd1k55WJPE8=; b=FdT5S6B3RBzGKh3bL/4v6J61n7ajZb/nLVdgYpvwg2MkpEYj238qmMm5ZsgQWZh1P4 +Auow3KoHwVIhQyF6xuTUXTEDWc1j2shvJ0woAUzRuWGcZa6euWN3L/7d6RS2PYQLyRX Flhb9YVQrOZYvO6F8VXC8WCbgLtETPieTp/7T17bpLgDBvbfN8S0WRmiaev8M37EvSs3 3a1BMVHa19w2xm9G8HejUorJJUeaH9UEXG6zeDA3d0oPvarH6w7f3iBdzJUt8cLOewMH HQ0GCzhwWQMS81mRG3/ViDlz+PmgoWuViXytDak2rKiT3xPgpbpQWgjdYuR4PLxwkiUJ 1uHQ== MIME-Version: 1.0 Received: by 10.52.26.65 with SMTP id j1mr2224611vdg.113.1331285957402; Fri, 09 Mar 2012 01:39:17 -0800 (PST) Received: by 10.220.108.135 with HTTP; Fri, 9 Mar 2012 01:39:17 -0800 (PST) In-Reply-To: <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> References: <80A0822C5E9A4440A5117C2F4CD36A64036645FF@DEMUEXC006.nsn-intra.net> <4F551E13.2000907@bwijnen.net> <84600D05C20FF943918238042D7670FD48B8829189@EMBX01-HQ.jnpr.net> Date: Fri, 9 Mar 2012 10:39:17 +0100 Message-ID: From: Mohamad Badra To: Kent Watsen , Alan Luchuk , Juergen Schoenwaelder Content-Type: multipart/alternative; boundary=20cf307d037095df1d04bacc2a76 Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 09:39:23 -0000 --20cf307d037095df1d04bacc2a76 Content-Type: text/plain; charset=ISO-8859-1 Dear Kent, Section 2.1: "It MUST connect to the server that passively listens for the > incoming TLS connection on the TCP port 6513". This language eliminates > the possibility of implementing a "reverse-tls" mechanism like we have with > "reverse-ssh". Since one of the motivators for this work is to support > low-end devices, I would think a need for a call-home mechanism would be > desired. That said, it might be hard to implement since SSH uses a named > subsystem ("netconf"), maybe this is more reason to support bidirectional > TLS connections? [Note: this language was also in RFC5539] > RFC5246 doesn't support reverse proxy as well, and all RFCs' Applications over TLS have the same above language. However, what about rewriting it as follow: The peer actively opens the TLS connection, and the server passively listens for the incoming TLS connection. Section 2.2: what about ? - why define another mechanism? > If important, then why doesn't RFC6242 require the client to send > SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT. Regardless, I disagree > with the intent of forcing graceful closures - in reality, devices MUST be > coded to support ungraceful closures and, once the code is written, there > isn't much value to a graceful close anymore. Also the second paragraph > seems out of place - shouldn't it be in the TLS RFC? [Note: this language > was also in RFC5539] > > Section 3.1 - RFC4642 places these recommendations into its "Security > Considerations" section - should this draft do the same? If this draft is > going to specify this information, then should it first state that the > client SHOULD validate the server's certificate chain (i.e. a trusted CA, > no expirations, no revocations, etc.)? Note: this language was also in > RFC5539] > I would prefer not moving it to the "Security Considerations" and I will replace the 1st paragraph with If the server's presented certificate has passed certification path validation [RFC5280] to a configured trust anchor, the client MUST carefully examine the certificate presented by the server to determine if it meets the client's expectations. Particularly, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man- in-the-middle attacks. Section 3.2.1 - > Section 3.2.1.1 > Section 3.2.1.3 > Alan and Juergen will be able to address your concerns much better than me. Best regards, Badra --20cf307d037095df1d04bacc2a76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Kent,

Section 2.1: "It MUST connect to the server that pa= ssively listens for the incoming TLS connection on the TCP port 6513".= =A0This language eliminates the possibility of implementing a "revers= e-tls" mechanism like we have with "reverse-ssh". =A0Since o= ne of the motivators for this work is to support low-end devices, I would t= hink a need for a call-home mechanism would be desired. =A0That said, it mi= ght be hard to implement since SSH uses a named subsystem ("netconf&qu= ot;), maybe this is more reason to support bidirectional TLS connections? [= Note: this language was also in RFC5539]


RFC5246 doesn't support= reverse proxy as well, and all RFCs' Applications over TLS have the sa= me above language.=A0

However, what about=A0rewrit= ing=A0it as follow:

The peer actively = opens the TLS connection, and the server passively
listens for the incoming TLS connection.
=A0

Section 2.2: wh= at about <close-session>? =A0- why define another mechanism? =A0If im= portant, then why doesn't RFC6242 require the client to send SSH_MSG_CH= ANNEL_CLOSE and/or SSH_MSG_DISCONNECT. =A0 Regardless, I disagree with the = intent of forcing graceful closures - in reality, devices MUST be coded to = support ungraceful closures and, once the code is written, there isn't = much value to a graceful close anymore. =A0Also the second paragraph seems = out of place - shouldn't it be in the TLS RFC? [Note: this language was= also in RFC5539]

Section 3.1 - RFC4642 places these recommendations into its "Security = Considerations" section - should this draft do the same? =A0If this dr= aft is going to specify this information, then should it first state that t= he client SHOULD validate the server's certificate chain (i.e. a truste= d CA, no expirations, no revocations, etc.)? =A0Note: this language was als= o in RFC5539]


I would prefer not moving i= t to the "Security Considerations" and I will replace the 1st par= agraph with
If the server's presented cer= tificate has passed
c= ertification path validation [RFC5280] to a configured
trust anchor, the client MUST carefully examine the
certificate presented by the serv= er to determine if it meets the
client's expectations. Particularly, the client MUST check = its
understanding of the server hostn= ame against the server's identity as
presented in the server Certificate message, in order t= o prevent man-
in-the-middle attacks.

<= /div>
Section 3.2.1 -
Section 3.2.1.1=A0
Section 3.2.1.3

Alan and Juergen will b= e able to address your concerns much better than me.

Best regards,
Badra
--20cf307d037095df1d04bacc2a76-- From mehmet.ersue@nsn.com Fri Mar 9 05:32:19 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD8F21F8647 for ; Fri, 9 Mar 2012 05:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDilG69oGZRq for ; Fri, 9 Mar 2012 05:32:18 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 93DE221F8623 for ; Fri, 9 Mar 2012 05:32:17 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q29DW7Vi023513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Mar 2012 14:32:07 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q29DW4Q3028449; Fri, 9 Mar 2012 14:32:06 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 14:32:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 14:32:02 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64037FAC28@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] RFC 6536 on Network Configuration Protocol (NETCONF)Access ControlModel Thread-Index: Acz8zPoL0dFl6hMiQNWI2K13l2EitwAaisNgADBlL9A= References: <20120308014254.7D99372E00C@rfc-editor.org> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , , "ext Andy Bierman" , "Martin Bjorklund" X-OriginalArrivalTime: 09 Mar 2012 13:32:03.0484 (UTC) FILETIME=[038825C0:01CCFDF9] 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: 3948 X-purgate-ID: 151667::1331299927-000044A2-D982C4E0/0-0/0-0 Subject: Re: [Netconf] RFC 6536 on Network Configuration Protocol (NETCONF)Access ControlModel X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:32:20 -0000 Same here! Thanks and congratulations to everybody who supported and contributed to this substantial work in NETCONF WG. Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Romascanu, Dan (Dan) > Sent: Thursday, March 08, 2012 3:25 PM > To: rfc-editor@rfc-editor.org; ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: netconf@ietf.org > Subject: Re: [Netconf] RFC 6536 on Network Configuration Protocol (NETCONF)Access > ControlModel >=20 > Thanks and congratulations to the editors, chairs, and the whole WG for > having this important NETCONF RFC published. >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > > bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org > > Sent: Thursday, March 08, 2012 3:43 AM > > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > > Cc: netconf@ietf.org; rfc-editor@rfc-editor.org > > Subject: RFC 6536 on Network Configuration Protocol (NETCONF) Access > > ControlModel > > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 6536 > > > > Title: Network Configuration Protocol (NETCONF) Access > > Control Model > > Author: A. Bierman, M. Bjorklund > > Status: Standards Track > > Stream: IETF > > Date: March 2012 > > Mailbox: andy@yumaworks.com, > > mbj@tail-f.com > > Pages: 49 > > Characters: 90803 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-netconf-access-control-07.txt > > > > URL: http://www.rfc-editor.org/rfc/rfc6536.txt > > > > The standardization of network configuration interfaces for use with > > the Network Configuration Protocol (NETCONF) requires a structured > > and secure operating environment that promotes human usability and > > multi-vendor interoperability. There is a need for standard > > mechanisms to restrict NETCONF protocol access for particular users > > to a pre-configured subset of all available NETCONF protocol > > operations and content. This document defines such an access control > > model. [STANDARDS-TRACK] > > > > This document is a product of the Network Configuration Working Group > > of the IETF. > > > > This is now a Proposed Standard Protocol. > > > > STANDARDS TRACK: This document specifies an Internet standards track > > protocol for the Internet community,and requests discussion and > > suggestions > > for improvements. Please refer to the current edition of the Internet > > Official Protocol Standards (STD 1) for the standardization state and > > status of this protocol. Distribution of this memo is unlimited. > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > To subscribe or unsubscribe, see > > http://www.ietf.org/mailman/listinfo/ietf-announce > > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > For searching the RFC series, see http://www.rfc- > > editor.org/rfcsearch.html. > > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless > > specifically noted otherwise on the RFC itself, all RFCs are for > > unlimited distribution. > > > > > > The RFC Editor Team > > Association Management Solutions, LLC > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Fri Mar 9 06:44:36 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909FB21F8668 for ; Fri, 9 Mar 2012 06:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF2thGhQ5ItA for ; Fri, 9 Mar 2012 06:44:36 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6CD21F85A1 for ; Fri, 9 Mar 2012 06:44:33 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT1oXUa05zs6w6vRuDtf+WoFqa2iJ/dP6@postini.com; Fri, 09 Mar 2012 06:44:35 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Mar 2012 06:44:09 -0800 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 q29Ei8187035; Fri, 9 Mar 2012 06:44:08 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id q29EDkph083149; Fri, 9 Mar 2012 14:13:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201203091413.q29EDkph083149@idle.juniper.net> To: Andy Bierman In-Reply-To: <4F597956.6000807@netconfcentral.org> Date: Fri, 9 Mar 2012 09:13:46 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:44:36 -0000 >On 03/05/2012 12:12 PM, Bert Wijnen (IETF) wrote: >> If I am correct, then, after Mehmet's call for >> discussion and to express interest, I have seen >> >> - Badra supports (editor/author) >> - Juergen supports (contributed to the document) >> - Mehmet supports >> >> Did I miss any? >> >> Do our other netconf implementers (Andy, Martin, Lada? >> Juniper-folk) not want to express an opinion? We have a proprietary SSL-based connection mechanism that predates this draft, but it is rarely used. On the other hand, customers complain about the amount of time required for starting up an ssh connection, so if this access mechanism is quicker, perhaps it can find a niche. I've never done these timing comparisons myself. Thanks, Phil From luchuk@snmp.com Mon Mar 12 12:23:07 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5452821E8058 for ; Mon, 12 Mar 2012 12:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY2sZYHOdBHJ for ; Mon, 12 Mar 2012 12:23:03 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82C21E8073 for ; Mon, 12 Mar 2012 12:22:57 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA11024; Mon, 12 Mar 2012 15:22:50 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id PAA06844; Mon, 12 Mar 2012 15:22:40 -0400 (EDT) Date: Mon, 12 Mar 2012 15:22:40 -0400 (EDT) From: Alan Luchuk Message-Id: <201203121922.PAA06844@adminfs.snmp.com> To: kwatsen@juniper.net Cc: netconf@ietf.org Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 19:23:07 -0000 Hello, >Section 3.2.1 - What happens if subjectAltName contains more than one >ipAddress, dnsName, or rfc822Name - as allowed by RFC 5280 section 4.2.1.6? Only the first ipAddress, dnsName, or rfc822Name is used; subsequent ones are ignored. How about the following text (note the new paragraph)? o Extract the subjectAltName's rfc822Name from the certificate, then use the extracted rfc822Name as the NETCONF username; o Extract the subjectAltName's dnsName from the certificate, then use the extracted dnsName as the NETCONF username; o Extract the subjectAltName's iPAddress from the certificate, then use the extracted iPAddress as the NETCONF username; o Examine the subjectAltName's rfc822Name, dnsName, and iPAddress fields in a pre-defined order. Return the value from the first subjectAltName field that is examined, defined, and populated with a non-empty value. If no subjectAltName field of a specific type is defined, then the examination skips that field and proceeds to examine the next field type. If a subjectAltName field is defined, but the value is not populated, or is populated by an empty value, then the examination skips that field and proceeds to examine the next field type. If the subjectAltName contains more than one rfc822Name, dnsName, or iPAddress, then only the first rfc822Name, dnsName, or iPAddress is extracted and used. Subsequent rfc822Names, dnsNames, or iPAddresses are ignored. The NETCONF server MUST implement all of these algorithms, and allow the deployer to choose the algorithm used. The certificate-to- username-transforms container in the ietf-netconf-tls YANG module specifies how a NETCONF server transforms a certificate into a NETCONF username. >Section 3.2.1.1 - This whole section should be rewritten - it's hard to >follow as is. I think there is an implicit assumption that the client's >certificate is trusted; that is, that the TLS layer would not have allowed >the connection if couldn't validate the certificate. Does this assumption >need to be stated explicitly? Third paragraph is about being able to >apply transformation based on the identification of the issuing CA, a good idea, but shouldn't this be after exhausting all direct-match options. Lastly, what is a "transformation container"? How about completely replacing the existing text in section 3.2.1.1 with the following text: 3.2.1.1. Identifying a Certificate The ietf-netconf-tls YANG module identifies the TLS certificate by the "fingerprint" of the certificate presented by the peer. The certificate fingerprint is a string of octets composed of a 1-octet hashing algorithm identifier followed by the results of the hashing algorithm. The 1-octet hashing algorithm identifier is encoded with values taken from the IANA TLS HashAlgorithm Registry (RFC 5246). Implementations are not required to implement all of the hash algorithms listed in the IANA TLS HashAlgorithm Registry (RFC 5246). If a locally held copy of a trusted CA certificate is configured in the certificate-to-username-transforms container of the ietf-netconf-tls YANG module, and that CA certificate was used to validate the path to the presented certificate, then the NETCONF server SHOULD derive the NETCONF username from that entry in the certificate-to-username-transforms container of the ietf-netconf-tls YANG module. In this case, the same NETCONF username will be derived from all presented certificates that have been validated by the CA certificate configured in the certificate-to-username-transforms container of the ietf-netconf-tls YANG module. >Section 3.2.1.3: > >Regarding "description" - Is the second sentence redundant? "It specifies >how NETCONF servers transform X.509 certificates presented by clients into >NETCONF usernames. It also specifies how NETCONF clients transform NETCONF >usernames into X.509 certificates for presentation to NETCONF servers." Yes, the second sentence is redundent and should be deleted. The text should read: description "This module applies to NETCONF over TLS. It specifies how NETCONF servers transform X.509 certificates presented by clients into NETCONF usernames. >Regarding "tls-fingerprint-type" - how can it be of length '0'? - the last >paragraph says it's to support containers where the fingerprint may be >optional, but shouldn't those containers simply not specific "mandatory >true"? The 2nd paragraph regards an encoding, does this mean that >implementations MUST support all the hash algorithms listed in IANA's >registry? > >Regarding certificate-fingerprint - why is the length on >"tls-fingerprint-type" further constrained? The suggestions sound reasonable. How about changing the typedef and YANG object to: typedef tls-fingerprint-type { type binary { length "1..255"; } description "A fingerprint value that can be used to uniquely reference other data of potentially arbitrary length. An tls-fingerprint-type value is composed of a 1-octet hashing algorithm identifier followed by the fingerprint value. The octet value encoded is taken from the IANA TLS HashAlgorithm Registry (RFC 5246). The remaining octets are filled using the results of the hashing algorithm. Implementations are not required to implement all of the hash algorithms listed in the IANA TLS HashAlgorithm Registry (RFC 5246). } leaf certificate-fingerprint { type tls-fingerprint-type; mandatory true; description "A cryptographic hash of a X.509 certificate. The results of a successful matching fingerprint to either the trusted CA in the certificate validation path or to the certificate itself is dictated by the map-type leaf."; } >Regarding "certificate-to-username-transform-count" - this type doesn't >seem to be referenced anywhere - remove it? > >Regarding "certificate-to-username-transform-last-changed" - this type >doesn't seem to be referenced anywhere - remove it? Besides, why reset >the value to '0' just because the NetConf server restarted? These are patterned after informational objects in the SNMP-TLS-TM-MIB. I have no strong preference whether or not these are retained in the YANG module. Resetting the value to 0 is intended to allow implementation on devices that cannot keep time across reboots. >Regarding "certificate-to-username-transforms" > 1) the statement "the client's presented certificate MUST either be > validated based on an established trust anchor, or it MUST directly > match a fingerprint in this container." is surprising - does this > mean that the TLS server MUST be coded to allow connections having > client certificates that cannot be authenticated at the TLS-level? > I had assumed that this RFC was only proscribing how to extract an > identity, but this proscribes an authentication strategy - is that > right? I think you understand correctly -- this is an OR choice. This text is strongly patterned after the description clause of the snmpTlstmCertTo- TSNTable on Page 41 of RFC 6353. I have no preference about how this should work, but people with more security experience than I thought it was a useful idea for mapping certificates to usernames, so it was copied in the ietf-netconf-tls YANG module. > > 2) the statement "If the list entry's certificate-fingerprint value > matches that of a locally held copy of a trusted CA certificate, and > that CA certificate was used to validate the path to the presented > certificate, then consider the list entry as a successful match." - > what is the "path"? - do you mean the certificate chain? - how does > the server know this? I need to see an example. I think the words "path" and "certificate chain" are used interchangably in RFC 6353. Would changing "path" to "certificate chain" be sufficient here? The basic idea is that multiple certificates can easily be mapped to a single NETCONF username. In some situations, this is conceptually easier and reduces the configuration of the certificate-to-username-transforms container. For example, let's say a network operations group has 10 network operators, each of which has a personal certificate that identifies a single operator. Let's also say that the network operations group has a CA that signs these personal certificates. Rather than having to configure 10 individual certificate-to-username-transforms in a NETCONF server, one for each network operator, a single certificate-to-username-transform could be configured for the network operations CA certificate. This single entry might be mapped to the NETCONF username "NetworkOperator", and access rights granted to this single NETCONF username. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From wjhns1@hardakers.net Tue Mar 13 07:18:10 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D2F21F88A3 for ; Tue, 13 Mar 2012 07:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKqwU7155Jkl for ; Tue, 13 Mar 2012 07:18:09 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9091A21F88A0 for ; Tue, 13 Mar 2012 07:18:09 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 3CB0A9B3; Tue, 13 Mar 2012 07:18:06 -0700 (PDT) From: Wes Hardaker To: Alan Luchuk References: <201203121922.PAA06844@adminfs.snmp.com> Date: Tue, 13 Mar 2012 07:18:06 -0700 In-Reply-To: <201203121922.PAA06844@adminfs.snmp.com> (Alan Luchuk's message of "Mon, 12 Mar 2012 15:22:40 -0400 (EDT)") Message-ID: <0lty1s8u01.fsf@wjh.hardakers.net> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 14:18:10 -0000 AL> Only the first ipAddress, dnsName, or rfc822Name is used; subsequent ones AL> are ignored. How about the following text (note the new paragraph)? That's pretty much what we ended up doing in ISMS, and I certainly think it's good to have cross-protocol equality when possible. The only different is that for the case of searching for "Any": o Examine the subjectAltName's rfc822Name, dnsName, and iPAddress fields in a pre-defined order. you're not specifying what the pre-defined order is. I assume that really means that the user can pick between 1 of 6 or maybe 7 options? 1) rfc822Name then dnsName then iPAddress 2) dnsName then rfc822Name then iPAddress 3) iPAddress then ... and maybe: 7) dnsName, rfc822Name, iPAddress always taking the first occurring. For ISMS, we chose to do only #7 for the "any" case as anything else meant a fair amount of complexity and it was less likely to help interchangeability. -- Wes Hardaker SPARTA, Inc. From j.schoenwaelder@jacobs-university.de Mon Mar 19 03:15:11 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804B321F864C; Mon, 19 Mar 2012 03:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.211 X-Spam-Level: X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faY4SjOcjEQ7; Mon, 19 Mar 2012 03:15:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0974521F8647; Mon, 19 Mar 2012 03:15:07 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5FA120D0A; Mon, 19 Mar 2012 11:15:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AfP6YxAOSG-W; Mon, 19 Mar 2012 11:15:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7036A20CEE; Mon, 19 Mar 2012 11:15:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 64F491E0CF1A; Mon, 19 Mar 2012 11:15:05 +0100 (CET) Date: Mon, 19 Mar 2012 11:15:05 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org, netmod@ietf.org Message-ID: <20120319101505.GA85201@elstar.local> Mail-Followup-To: netconf@ietf.org, netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 19 Mar 2012 10:15:11 -0000 Hi, a number of NETCONF / YANG contributors plan to meet on Monday morning 09:00-11:30 in order to informally discuss where we are with NETCONF and YANG adoption and if there is any useful work that people find valuable to spent their time on and which might be relevant from an IETF perspective. Some topics that have popped up several times include: - REST interface to NETCONF/YANG - Modeling operational state - XPATH function library for YANG - Issues with the candidate editing model The goal of the meeting is to dive into a certain level of technical depth to better understand the feasibility / complexity of potential solutions. People who like to attend should thus be warned that this meeting is not about high-level lets dream up something in the blue sky discussions. Note that this is an informal meeting. We plan to report in the AOB part of the NETMOD or NETCONF meetings (likely the NETMOD meeting since the NETCONF meeting is rather short). We are trying to find a suitable room. I will post a pointer once we have one. The fallback is to simply meet at the registration area. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Mar 22 10:38:53 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7EA21F855D; Thu, 22 Mar 2012 10:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7haUINFPezAc; Thu, 22 Mar 2012 10:38:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8471721F8549; Thu, 22 Mar 2012 10:38:52 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D72020D3B; Thu, 22 Mar 2012 18:38:51 +0100 (CET) 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 9wcGRCPuWtSq; Thu, 22 Mar 2012 18:38:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 067F920D33; Thu, 22 Mar 2012 18:38:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F12F61E185CA; Thu, 22 Mar 2012 18:38:50 +0100 (CET) Date: Thu, 22 Mar 2012 18:38:50 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org, netmod@ietf.org Message-ID: <20120322173850.GC23587@elstar.local> Mail-Followup-To: netconf@ietf.org, netmod@ietf.org References: <20120319101505.GA85201@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120319101505.GA85201@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 22 Mar 2012 17:38:53 -0000 On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: > Hi, > > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: > > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model > > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. > > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). > > We are trying to find a suitable room. I will post a pointer once we > have one. The fallback is to simply meet at the registration area. The room has been found: Room 237M is available on Monday, 26th (0900-1130). Thanks to Dan for organizing the room. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From james.huy.nguyen@gmail.com Thu Mar 22 11:46:21 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD4B21F854B; Thu, 22 Mar 2012 11:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZwm089EIiN7; Thu, 22 Mar 2012 11:46:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5932B21F8526; Thu, 22 Mar 2012 11:46:20 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2313577ggm.31 for ; Thu, 22 Mar 2012 11:46:20 -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 :content-type; bh=YFllUGiWDJXfnTmGc8bOA5tps/0wvhukeZsZF8+v0B4=; b=ZLd0I7Sg+7UHjYajBo7LAHe/KlLqmbJgPxStnPRecciotqKigzq6uEEfKsPAVocl2D iLad4lmmLprzCtCNkI8LjvSV/fQXCOZx/NyiGxf6DJ3XYT1rd1PhrUFnjHIo+RskTZ6q CWJaqfUXHbOsmbBd6S1wP9kKCwGkCMDFxUo5FktQGfwdfS+ehhJqK18XjtgAiHOIDhPr GU5m+JmkaKQRSoqSsaTGQEeWIwxBDERTks8Q+B0W1Q9jmgLaUjfk1+xRUZGS5WbRPknF OypxVL8Gu/Waldux3Vhem8E5P7kzsOV1yQfk0hm3D71GkHKa3oQLNigtBjU8WRICf0+g Yp2g== MIME-Version: 1.0 Received: by 10.236.136.99 with SMTP id v63mr4576254yhi.27.1332441979990; Thu, 22 Mar 2012 11:46:19 -0700 (PDT) Received: by 10.101.112.9 with HTTP; Thu, 22 Mar 2012 11:46:19 -0700 (PDT) In-Reply-To: <20120319101505.GA85201@elstar.local> References: <20120319101505.GA85201@elstar.local> Date: Thu, 22 Mar 2012 14:46:19 -0400 Message-ID: From: James Nguyen To: Juergen Schoenwaelder , netconf@ietf.org, netmod@ietf.org Content-Type: multipart/alternative; boundary=485b397dd125e6b21804bbd9527f Subject: Re: [Netconf] [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:46:21 -0000 --485b397dd125e6b21804bbd9527f Content-Type: text/plain; charset=UTF-8 Hi Juergen, Our team, US Army CERDEC, is currently working on improving NETCONF by adding a common interface on top of it. The current proposal is to use US Naval Research Laboratory (NRL)'s NORM while REST over NETCONF is in discussion. Thus, I'm interested in listening the discussion of REST interface to NETCONF/YANG. Unfortunately, I won't be able to attend the meeting in Paris. Is there a conference bridge and time that I could dial in? Thanks, James On Mon, Mar 19, 2012 at 6:15 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: > > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model > > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. > > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). > > We are trying to find a suitable room. I will post a pointer once we > have one. The fallback is to simply meet at the registration area. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > -- James Nguyen Email: james.huy.nguyen@gmail.com --485b397dd125e6b21804bbd9527f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Juergen,

Our team, US Army CERDEC, is currently worki= ng on improving NETCONF by adding a common interface on top of it. =C2=A0Th= e current proposal is to use US Naval Research Laboratory (NRL)'s NORM = while REST over NETCONF is in discussion. =C2=A0Thus, I'm interested in= listening the discussion of REST interface to NETCONF/YANG. =C2=A0Unfortun= ately, I won't be able to attend the meeting in Paris. =C2=A0Is there a= conference bridge and time that I could dial in?

Thanks,

James

On Mon, Mar 19, 2012 at 6:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

a number of NETCONF / YANG contributors plan to meet on Monday morning
09:00-11:30 in order to informally discuss where we are with NETCONF
and YANG adoption and if there is any useful work that people find
valuable to spent their time on and which might be relevant from an
IETF perspective. Some topics that have popped up several times
include:

- REST interface to NETCONF/YANG
- Modeling operational state
- XPATH function library for YANG
- Issues with the candidate editing model

The goal of the meeting is to dive into a certain level of technical
depth to better understand the feasibility / complexity of potential
solutions. People who like to attend should thus be warned that this
meeting is not about high-level lets dream up something in the blue
sky discussions.

Note that this is an informal meeting. We plan to report in the AOB
part of the NETMOD or NETCONF meetings (likely the NETMOD meeting
since the NETCONF meeting is rather short).

We are trying to find a suitable room. I will post a pointer once we
have one. The fallback is to simply meet at the registration area.

/js

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49= 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, = Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.de/= >
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod



-- James Nguyen
Email: jame= s.huy.nguyen@gmail.com
--485b397dd125e6b21804bbd9527f-- From alex@cisco.com Mon Mar 26 11:56:48 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032D621E80E4; Mon, 26 Mar 2012 11:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdIyKgAyUcrX; Mon, 26 Mar 2012 11:56:47 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 185C521E80BD; Mon, 26 Mar 2012 11:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=2317; q=dns/txt; s=iport; t=1332788207; x=1333997807; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=uEb7NO6ZadCQuo8WdnxHG+Qq5FmL24+dnrqEXyMZp1Y=; b=kSM2dwc9nla1PeEF6p/ZT/uasyBJqpV9ZPhZqdeRQRFQTD4L+jY2YR0p Ffxo704ZHlb7cl3FcphvgWEDHuh/WYJKGAnfHxWo3Z8M909muj+uGv+bs 4cHX6GCvJfUeh3/0tYtTxXk7y+lPemOgxgGwgCV1d5fapyglKc3WEASqI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGe7cE+rRDoI/2dsb2JhbABBA7g2gQeCCQEBAQQBAQEPAR0KNBcCAgIBCA4CAQQBAQEKBhcBBgEaDB8JCAEBBAESCBMHh2cBC5o8jVGRJQSNe4JGYwSIV5tOgWiDBw X-IronPort-AV: E=Sophos;i="4.73,652,1325462400"; d="scan'208";a="35151063" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 26 Mar 2012 18:56:46 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2QIui5m016461; Mon, 26 Mar 2012 18:56:44 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 11:56:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Mar 2012 11:56:42 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20120322173850.GC23587@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0IUqpTYzkF2SPZTe2VrenNjtbAWgDLv0jg References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> From: "Alexander Clemm (alex)" To: "Juergen Schoenwaelder" , , X-OriginalArrivalTime: 26 Mar 2012 18:56:44.0451 (UTC) FILETIME=[301D8F30:01CD0B82] Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 18:56:48 -0000 A significant topic from my perspective concerns the topic of REST. Unfortunately I cannot be at IETF, but I just wanted to underscore / express my support for this topic from remote. This is also something I would be willing to spend time and engage on. =20 Kind regards --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, March 22, 2012 10:39 AM To: netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: > Hi, >=20 > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: >=20 > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model >=20 > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. >=20 > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). >=20 > We are trying to find a suitable room. I will post a pointer once we > have one. The fallback is to simply meet at the registration area. The room has been found: Room 237M is available on Monday, 26th (0900-1130). Thanks to Dan for organizing the room. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Mon Mar 26 13:21:08 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959B521E809C; Mon, 26 Mar 2012 13:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M02XxhttbUNm; Mon, 26 Mar 2012 13:21:07 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5D31621E8013; Mon, 26 Mar 2012 13:21:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT3DPr+kCjpUlFPw6OsZiHgRnx5r/wNrV@postini.com; Mon, 26 Mar 2012 13:21:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 26 Mar 2012 13:18:56 -0700 From: Kent Watsen To: "Alexander Clemm (alex)" , Juergen Schoenwaelder , "netconf@ietf.org" , "netmod@ietf.org" Date: Mon, 26 Mar 2012 13:18:37 -0700 Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0IUqpTYzkF2SPZTe2VrenNjtbAWgDLv0jgAAKH7ZA= Message-ID: <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 20:21:08 -0000 Having defined the standards and conventions for REST APIs at my company, I= have a working understanding. The fundamental question will be if the dat= astores are the "resources" on which PATCH is used or if the config hierarc= hy is mapped onto URL space. The other key decisions will be how far we ta= ke HATEOAS and custom media-types... Thanks, Kent -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Alexander Clemm (alex) Sent: Monday, March 26, 2012 2:57 PM To: Juergen Schoenwaelder; netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning A significant topic from my perspective concerns the topic of REST. Unfortunately I cannot be at IETF, but I just wanted to underscore / express my support for this topic from remote. This is also something I would be willing to spend time and engage on. =20 Kind regards --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, March 22, 2012 10:39 AM To: netconf@ietf.org; netmod@ietf.org Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: > Hi, >=20 > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: >=20 > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model >=20 > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. >=20 > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). >=20 > We are trying to find a suitable room. I will post a pointer once we > have one. The fallback is to simply meet at the registration area. The room has been found: Room 237M is available on Monday, 26th (0900-1130). Thanks to Dan for organizing the room. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 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 From j.schoenwaelder@jacobs-university.de Mon Mar 26 16:00:07 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A228221F8573; Mon, 26 Mar 2012 16:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pLymrqZRHW9; Mon, 26 Mar 2012 16:00:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BB0EB21F856D; Mon, 26 Mar 2012 16:00:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC16220C59; Tue, 27 Mar 2012 01:00:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t5Ax6gLmA7W8; Tue, 27 Mar 2012 01:00:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4515E209D7; Tue, 27 Mar 2012 01:00:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D60F71E1E41F; Tue, 27 Mar 2012 01:00:04 +0200 (CEST) Date: Tue, 27 Mar 2012 01:00:04 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120326230004.GA34802@elstar.local> Mail-Followup-To: Kent Watsen , "Alexander Clemm (alex)" , "netconf@ietf.org" , "netmod@ietf.org" References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 26 Mar 2012 23:00:07 -0000 On Mon, Mar 26, 2012 at 01:18:37PM -0700, Kent Watsen wrote: > > Having defined the standards and conventions for REST APIs at my company, I have a working understanding. The fundamental question will be if the datastores are the "resources" on which PATCH is used or if the config hierarchy is mapped onto URL space. The other key decisions will be how far we take HATEOAS and custom media-types... > And your preferred answer to these questions is? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Mar 26 16:04:17 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983CC21E800F; Mon, 26 Mar 2012 16:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HThK0xo-0BED; Mon, 26 Mar 2012 16:04:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8855C21E800C; Mon, 26 Mar 2012 16:04:16 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC55E20C59; Tue, 27 Mar 2012 01:04:15 +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 Aw-9Gurmv44s; Tue, 27 Mar 2012 01:04:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67468209D7; Tue, 27 Mar 2012 01:04:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 78BFD1E1E49F; Tue, 27 Mar 2012 01:04:13 +0200 (CEST) Date: Tue, 27 Mar 2012 01:04:12 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org, netmod@ietf.org Message-ID: <20120326230411.GB34802@elstar.local> Mail-Followup-To: netconf@ietf.org, netmod@ietf.org References: <20120319101505.GA85201@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20120319101505.GA85201@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 26 Mar 2012 23:04:17 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: > Hi, > > a number of NETCONF / YANG contributors plan to meet on Monday morning > 09:00-11:30 in order to informally discuss where we are with NETCONF > and YANG adoption and if there is any useful work that people find > valuable to spent their time on and which might be relevant from an > IETF perspective. Some topics that have popped up several times > include: > > - REST interface to NETCONF/YANG > - Modeling operational state > - XPATH function library for YANG > - Issues with the candidate editing model > > The goal of the meeting is to dive into a certain level of technical > depth to better understand the feasibility / complexity of potential > solutions. People who like to attend should thus be warned that this > meeting is not about high-level lets dream up something in the blue > sky discussions. > > Note that this is an informal meeting. We plan to report in the AOB > part of the NETMOD or NETCONF meetings (likely the NETMOD meeting > since the NETCONF meeting is rather short). Hi, the meeting took place but we did not manage to cover all the topics nor did we manage to explore all the details in the time we had available. Anyway, I think it is good to have such discussions in order to reflect where we are with NETCONF and where we might want to go or where we might not want to go. Attached are my meeting notes. They might be incomplete or even wrong. Participants, feel free to send me updates and corrections. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netconf-side-meeting-notes.txt" NETCONF Side Meeting, Monday 26th, 09:00-11:30, Paris IETF Meeting * Attendees Andy Bierman (AB), Martin Bjorklund (MB), Benoit Claise (BC), Bert Wijnen (BW), Mehmet Ersue (ME), Juergen Schoenwaelder (JS), Ladislav Lhotka (LL), Carl Moberg (CM), Nikolay Melnikov (NM), Vladislav Perelman (VP), David Harrington (DH) * REST API for NETCONF ** Why are REST APIs so interesting for many people? Availability of tools and APIs, (perceived) simplicity, no complexity like candidate data stores etc. REST assumes the server does not keep client state (but the client can of course keep server state). AB expresses concerns that breaking a complex configuration into a large collection of resources causes resource interaction problems, e.g. we are moving back to SNMP's peek and poke operations with complex side effects. ** How are today's NETCONF editing features used? CM says that their NETCONF management application uses candidate if it is available and usually the manager sends a single edit-config. MB says that the code to adapt to the capabilities of a server in a generic way is really small. ** Where does REST stand in the IETF? DBH says that there is a strong push towards REST APIs in the IETF. If you are living in a REST world, then learning a new tool for configuring network devices is difficult to sell. ** What does the customer want? AB says NETCONF/YANG stability is important. CM says that people want simplifying abstractions, NETCONF exposes lots of server details. MB asks since devices are complex and users want simple abstractions, where do we provide these abstractions? MB asks whether it would be valuable to provide a REST interface to high-level (network wide) management operations? AB argues for consistency of the implementations. NETCONF does not really deliver this in reality. Probably we need some more interoperability test? Do we need to explain the limits of REST when it comes to complex configuration transactions? ** Can open source help? CM likes to see a decent API for Ruby or even better a suitable C library can be used for providing various language bindings. ** Complexity questions? - Persistence? - Concurrent and conflicting changes? - Confirmed commits - configuration transactions across devices? - Preconfiguration? ** YANG mapping rules to JSON LL suggests to write a mapping of YANG to JSON. JS is concerned if YANG -> JSON and YANG -> XML -> JSON would lead to different results. The seem to be many XML -> JSON translations out there, it is not clear whether there is a standard or at least a common proposal. ** Action items? The following next steps were suggested: - Create a one slide summary explaining what NETCONF does right and that designers of other configuration protocols should consider. - Write an IPJ article that explains the important things NETCONF is doing right and which designers of other configuration protocols should consider. - Consult with APP area people to learn whether XML to JSON is somewhere on the radar. * Modeling Operational State There are interfaces that are not configured. There are addresses on interfaces that are not configured but dynamically learned. The architecture document discusses this without arriving at a conclusion. MB asks whether a operation could be a solution? MB likes to avoid large duplication of trees. JS seconds this. Some examples discussed: DHCP on an IP interface. The config of the interface just says dhcp enabled. The operational state is the IP address assigned by DHCP. As a consequence, operational state for this interface is different from its configuration state. (If config true objects are used to represent operational state. designers have to be careful to not over-constraint the data models.) * Meeting End --/04w6evG8XlLl3ft-- From andy@netconfcentral.org Mon Mar 26 20:56:01 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C544721E8045 for ; Mon, 26 Mar 2012 20:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZdvRm7oe3cv for ; Mon, 26 Mar 2012 20:56:01 -0700 (PDT) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by ietfa.amsl.com (Postfix) with SMTP id 1948721E8051 for ; Mon, 26 Mar 2012 20:56:01 -0700 (PDT) Received: (qmail 26373 invoked from network); 27 Mar 2012 03:56:00 -0000 Received: from unknown (213.41.80.49) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 27 Mar 2012 03:55:59 -0000 Message-ID: <4F713A4C.4040801@netconfcentral.org> Date: Mon, 26 Mar 2012 20:55:56 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: Kent Watsen References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 03:56:01 -0000 On 03/26/2012 01:18 PM, Kent Watsen wrote: > > Having defined the standards and conventions for REST APIs at my company, I have a working understanding. The fundamental question will be if the datastores are the "resources" on which PATCH is used or if the config hierarchy is mapped onto URL space. The other key decisions will be how far we take HATEOAS and custom media-types... > The top-level issue is "what problem are we trying to solve"? IMO, NETCONF is so server-centric that application developers have too much complexity punted their way. Are we trying to pass all that complexity to a WEB app? Are we running NETCONF over HTTP or are we providing consistent CRUD operations on a YANG-specified resource model? The REST resource model has no concept of 'candidate config' or 'copy-config from running to startup'. Creation of a resource is activated right away and no extra steps for persistence are expected. There are many more issues than the mechanics of mapping CRUD operations on a subset of the datastore. IMO, fitting into the REST application toolsets and 'world view' are just as important as the mechanics. HTTP/REST is much better than NETCONF at separating meta-data and real data (HEAD operation). High level iterators (startPage=i, pageCount=N) could be much more efficient than subtree or XPath filtering. NETCONF has much more info than HTTP error codes, which is a problem that needs to be solved. REST resource discovery is also interesting. How does this interact with NETCONF capability URIs? Do we expect the WEB app to use :with-defaults, or :partial-lock? (IMO, just the YANG module capability URIs are mandatory.) > Thanks, > Kent Andy > > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Alexander Clemm (alex) > Sent: Monday, March 26, 2012 2:57 PM > To: Juergen Schoenwaelder; netconf@ietf.org; netmod@ietf.org > Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning > > A significant topic from my perspective concerns the topic of REST. > Unfortunately I cannot be at IETF, but I just wanted to underscore / > express my support for this topic from remote. This is also something I > would be willing to spend time and engage on. > > Kind regards > --- Alex > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Thursday, March 22, 2012 10:39 AM > To: netconf@ietf.org; netmod@ietf.org > Subject: Re: [Netconf] netconf/yang side meeting in paris on monday > morning > > On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder wrote: >> Hi, >> >> a number of NETCONF / YANG contributors plan to meet on Monday morning >> 09:00-11:30 in order to informally discuss where we are with NETCONF >> and YANG adoption and if there is any useful work that people find >> valuable to spent their time on and which might be relevant from an >> IETF perspective. Some topics that have popped up several times >> include: >> >> - REST interface to NETCONF/YANG >> - Modeling operational state >> - XPATH function library for YANG >> - Issues with the candidate editing model >> >> The goal of the meeting is to dive into a certain level of technical >> depth to better understand the feasibility / complexity of potential >> solutions. People who like to attend should thus be warned that this >> meeting is not about high-level lets dream up something in the blue >> sky discussions. >> >> Note that this is an informal meeting. We plan to report in the AOB >> part of the NETMOD or NETCONF meetings (likely the NETMOD meeting >> since the NETCONF meeting is rather short). >> >> We are trying to find a suitable room. I will post a pointer once we >> have one. The fallback is to simply meet at the registration area. > > The room has been found: Room 237M is available on Monday, 26th > (0900-1130). Thanks to Dan for organizing the room. > > /js > From lhotka@nic.cz Tue Mar 27 01:59:32 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1A121F892D; Tue, 27 Mar 2012 01:59:32 -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=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnQffito8kLD; Tue, 27 Mar 2012 01:59:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 99D2221F88FC; Tue, 27 Mar 2012 01:59:30 -0700 (PDT) Received: from [IPv6:2001:df8::16:38dc:f1da:a79e:a6c0] (unknown [IPv6:2001:df8:0:16:38dc:f1da:a79e:a6c0]) by mail.nic.cz (Postfix) with ESMTPSA id 8675F14045A; Tue, 27 Mar 2012 10:59:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1332838769; bh=s5sIFml1WCbiQ1WgLLAVEomijb7HVQoEfMxcSWkXMi8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UJHVlJYXkWROxNmIWjpi1qMtE1xr/xiUof5R4jmRH6O4tnOJzweR/K9Hc+guEhQsG x6eBixfsYac64/NBdfuqJj/ra5P+kdgaauYv60m1t7DOImXoT+YtTkNsKrFx7rS3fx YJzBdBIH+uH/SF1fUQsjUrr11qBLaW3ILE99UFHE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <4F713A4C.4040801@netconfcentral.org> Date: Tue, 27 Mar 2012 10:59:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09F23D7C-E770-4B8D-B97D-64047F7A5C2E@nic.cz> References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> <4F713A4C.4040801@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:59:32 -0000 On Mar 27, 2012, at 5:55 AM, Andy Bierman wrote: > On 03/26/2012 01:18 PM, Kent Watsen wrote: >>=20 >> Having defined the standards and conventions for REST APIs at my = company, I have a working understanding. The fundamental question will = be if the datastores are the "resources" on which PATCH is used or if = the config hierarchy is mapped onto URL space. The other key decisions = will be how far we take HATEOAS and custom media-types... >>=20 >=20 > The top-level issue is "what problem are we trying to solve"? >=20 > IMO, NETCONF is so server-centric that application developers have too = much > complexity punted their way. Are we trying to pass all that = complexity > to a WEB app? Are we running NETCONF over HTTP or are we providing > consistent CRUD operations on a YANG-specified resource model? I think a RESTful approach requires a different perspective, namely = "model-view-controller". This could by the way also help resolve the = issue of operational state versus configuration. Specifically: - Model is a complete set of state parameters that determines the device = behaviour, configured manually or=20 otherwise. This is the representational state in REST terms. - View can be the contents of a get (or get-operational) reply, or an = HTML rendering of the Model. - The Controller part represents the procedures for changing the Model. = For simple changes the HTTP methods=20 (PUT, POST, DELETE) can be used while complicated changes (e.g. adding = a new OSPF adjacency) might require an=20 edit-config.=20 >=20 > The REST resource model has no concept of 'candidate config' > or 'copy-config from running to startup'. Creation of a resource > is activated right away and no extra steps for persistence are = expected. A (user-specific) candidate may be treated as a special View in which a = sequence of edits performed by the user have been made. A commit then = boils down to applying the same sequence of edits to the Model = (atomically). With this approach, many of the issues concerning access = control wouldn't exist - it would only be necessary to check whether the = user has the permissions to perform all the edits. >=20 > There are many more issues than the mechanics of mapping CRUD = operations > on a subset of the datastore. IMO, fitting into the REST application > toolsets and 'world view' are just as important as the mechanics. >=20 > HTTP/REST is much better than NETCONF at separating meta-data and real = data > (HEAD operation). High level iterators (startPage=3Di, pageCount=3DN) > could be much more efficient than subtree or XPath filtering. >=20 > NETCONF has much more info than HTTP error codes, which is = a problem > that needs to be solved. IMO HTTP and NETCONF approaches are not mutually exclusive. Lada >=20 > REST resource discovery is also interesting. How does this interact > with NETCONF capability URIs? Do we expect the WEB app to use = :with-defaults, > or :partial-lock? (IMO, just the YANG module capability URIs are = mandatory.) >=20 >=20 >> Thanks, >> Kent >=20 > Andy >=20 >>=20 >>=20 >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On = Behalf Of Alexander Clemm (alex) >> Sent: Monday, March 26, 2012 2:57 PM >> To: Juergen Schoenwaelder; netconf@ietf.org; netmod@ietf.org >> Subject: Re: [Netconf] netconf/yang side meeting in paris on monday = morning >>=20 >> A significant topic from my perspective concerns the topic of REST. >> Unfortunately I cannot be at IETF, but I just wanted to underscore / >> express my support for this topic from remote. This is also = something I >> would be willing to spend time and engage on. >>=20 >> Kind regards >> --- Alex >>=20 >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Juergen Schoenwaelder >> Sent: Thursday, March 22, 2012 10:39 AM >> To: netconf@ietf.org; netmod@ietf.org >> Subject: Re: [Netconf] netconf/yang side meeting in paris on monday >> morning >>=20 >> On Mon, Mar 19, 2012 at 11:15:05AM +0100, Juergen Schoenwaelder = wrote: >>> Hi, >>>=20 >>> a number of NETCONF / YANG contributors plan to meet on Monday = morning >>> 09:00-11:30 in order to informally discuss where we are with NETCONF >>> and YANG adoption and if there is any useful work that people find >>> valuable to spent their time on and which might be relevant from an >>> IETF perspective. Some topics that have popped up several times >>> include: >>>=20 >>> - REST interface to NETCONF/YANG >>> - Modeling operational state >>> - XPATH function library for YANG >>> - Issues with the candidate editing model >>>=20 >>> The goal of the meeting is to dive into a certain level of technical >>> depth to better understand the feasibility / complexity of potential >>> solutions. People who like to attend should thus be warned that this >>> meeting is not about high-level lets dream up something in the blue >>> sky discussions. >>>=20 >>> Note that this is an informal meeting. We plan to report in the AOB >>> part of the NETMOD or NETCONF meetings (likely the NETMOD meeting >>> since the NETCONF meeting is rather short). >>>=20 >>> We are trying to find a suitable room. I will post a pointer once we >>> have one. The fallback is to simply meet at the registration area. >>=20 >> The room has been found: Room 237M is available on Monday, 26th >> (0900-1130). Thanks to Dan for organizing the room. >>=20 >> /js >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From kwatsen@juniper.net Tue Mar 27 09:36:05 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7621E8174; Tue, 27 Mar 2012 09:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez0UZ+hKm1C9; Tue, 27 Mar 2012 09:36:04 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4C49621E80EC; Tue, 27 Mar 2012 09:36:04 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT3HscNmZtqxgS1OZi/Z7W+2+XyrveCJM@postini.com; Tue, 27 Mar 2012 09:36:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 27 Mar 2012 09:34:38 -0700 From: Kent Watsen To: Andy Bierman Date: Tue, 27 Mar 2012 09:34:32 -0700 Thread-Topic: [netmod] [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0LzYdW1y/XcOamSe6teKsCzhHvpgAZhBuQ Message-ID: <84600D05C20FF943918238042D7670FD48C031EAE8@EMBX01-HQ.jnpr.net> References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> <4F713A4C.4040801@netconfcentral.org> In-Reply-To: <4F713A4C.4040801@netconfcentral.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:36:06 -0000 Andy Bierman writes: > > The top-level issue is "what problem are we trying to solve"? Yes, this is the top-level question. It seems to that there are 3 use-cases: 1. off-box scripts 2. off-box NMS apps 3. on-box web interface Did I miss any? Considering these in turn: 1. off-box scripts The API should be simple to use via a scripting language. HTTP is ubiquitous, every scripting language has built-in=20 support. NETCONF API bindings can be provided, but they'll never be built into the language nor be as popular. 2. off-box NMS apps The complexity of the API doesn't matter as much as the scalability and performance of the protocol. NETCONF may have the edge here, though HTTP caching servers may make up for much of that. 3. on-box web-interface Assuming the web-interface is AJAX/AJAJ, then a REST interface would be preferred - not only because the HTTP bindings are built into Javascript, but also because the client could use JSON and there would be no uncertainty for if the REST API is available, since it uses the same protocol as the web interface. Thoughts? Kent From kwatsen@juniper.net Tue Mar 27 10:39:10 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5091F0C57; Tue, 27 Mar 2012 10:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHE-TECxw+Bq; Tue, 27 Mar 2012 10:39:09 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 59DB91F0C56; Tue, 27 Mar 2012 10:39:09 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT3H7Okm3+F2baiP+0HET0nF3tMnJBzBs@postini.com; Tue, 27 Mar 2012 10:39:09 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 27 Mar 2012 10:38:45 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Tue, 27 Mar 2012 10:38:43 -0700 Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0LpDByKe6p7cu3TKmd42ATr7o2fgAjoC0w Message-ID: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> <20120326230004.GA34802@elstar.local> In-Reply-To: <20120326230004.GA34802@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:39:10 -0000 Juergen writes: > >And your preferred answer to these questions is? Just thinking out loud. We know that a YANG module can define config/state= , RPCs, and notifications. From NETCONF, we know that the device can have c= onfig datastores and capabilities. Lastly, from REST, we know that HTTP is= the protocol (not NETCONF). Given its simplicity, my preference would be to model each datastore as sin= gle resource (not a hierarchy of URLs). For granular retrievals, I would u= se XPath with GET; for granular updates, I would use PATCH (RFC 5789) - thi= s implies using ETags and If-Match. For the PATCH document format, we coul= d define one to be like the body of an operation. For RPCs, I= would define "methods" (more on this later) and for notifications, I would= define a long-poll (comet) interface. Lastly, to support capabilities exc= hange, I would define RFC 6022's "netconf-state" as a top-level resource. While I'm generally a proponent for custom media-types, I envision them as = being more useful when defined by the vendor than IETF. We might define a = few like: datastore, netconf-state, and edit-config. That said, "datastore= " might be better identified as "application/json" and/or "application/xml"= , so the document can be defined in the vendor's namespace. As for HATEOAS, I don't see the use-case for supporting clients that aren't= explicitly programmed to know that they're connecting to a device. Thus, = I think that it's OK for us to assume the client knows about the /netconf-s= tate and / resources without having to discover them via the Hos= t Metadata service (RFC 6415). If we want something more elegant than retu= rning 404 on /netconf-state, we could register a single element in t= he .well-known XDP for a "netconf" relation. What do you think? Kent From j.schoenwaelder@jacobs-university.de Tue Mar 27 11:11:11 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0B21E80AE; Tue, 27 Mar 2012 11:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.185 X-Spam-Level: X-Spam-Status: No, score=-102.185 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxNk58U9Lo7W; Tue, 27 Mar 2012 11:11:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6947121E808D; Tue, 27 Mar 2012 11:11:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D88320C7C; Tue, 27 Mar 2012 20:11:09 +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 aaG-H4my6fKP; Tue, 27 Mar 2012 20:11:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECC6620C75; Tue, 27 Mar 2012 20:11:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 182511E1FD0A; Tue, 27 Mar 2012 20:11:08 +0200 (CEST) Date: Tue, 27 Mar 2012 20:11:08 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120327181108.GA37080@elstar.local> Mail-Followup-To: Kent Watsen , "Alexander Clemm (alex)" , "netconf@ietf.org" , "netmod@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 18:11:11 -0000 On Tue, Mar 27, 2012 at 10:38:43AM -0700, Kent Watsen wrote: > > Juergen writes: > > > >And your preferred answer to these questions is? > > Just thinking out loud. We know that a YANG module can define config/state, RPCs, and notifications. From NETCONF, we know that the device can have config datastores and capabilities. Lastly, from REST, we know that HTTP is the protocol (not NETCONF). > > Given its simplicity, my preference would be to model each datastore as single resource (not a hierarchy of URLs). For granular retrievals, I would use XPath with GET; for granular updates, I would use PATCH (RFC 5789) - this implies using ETags and If-Match. For the PATCH document format, we could define one to be like the body of an operation. For RPCs, I would define "methods" (more on this later) and for notifications, I would define a long-poll (comet) interface. Lastly, to support capabilities exchange, I would define RFC 6022's "netconf-state" as a top-level resource. There is a JSON patch format and it would be nice to use that together with HTTP PATCH (RFC 5789) to do modifications. > While I'm generally a proponent for custom media-types, I envision them as being more useful when defined by the vendor than IETF. We might define a few like: datastore, netconf-state, and edit-config. That said, "datastore" might be better identified as "application/json" and/or "application/xml", so the document can be defined in the vendor's namespace. > > As for HATEOAS, I don't see the use-case for supporting clients that aren't explicitly programmed to know that they're connecting to a device. Thus, I think that it's OK for us to assume the client knows about the /netconf-state and / resources without having to discover them via the Host Metadata service (RFC 6415). If we want something more elegant than returning 404 on /netconf-state, we could register a single element in the .well-known XDP for a "netconf" relation. > > What do you think? I share the concern that exposing fine grained resources might be cumbersome. But we would need to support filtered retrieval in some way. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Mar 27 11:21:56 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0017821E80AE; Tue, 27 Mar 2012 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd43E85Sx9M2; Tue, 27 Mar 2012 11:21:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DB70D21E808D; Tue, 27 Mar 2012 11:21:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1210920CA8; Tue, 27 Mar 2012 20:21:54 +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 4QsT3BFh6_X7; Tue, 27 Mar 2012 20:21:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8163F20C8E; Tue, 27 Mar 2012 20:21:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB0A21E1FD50; Tue, 27 Mar 2012 20:21:53 +0200 (CEST) Date: Tue, 27 Mar 2012 20:21:53 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120327182153.GB37080@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , "Alexander Clemm (alex)" , "netconf@ietf.org" , "netmod@ietf.org" References: <20120319101505.GA85201@elstar.local> <20120322173850.GC23587@elstar.local> <196FFAC4F80A9142A8C30A7EE9C33B790B34EC5A@xmb-sjc-239.amer.cisco.com> <84600D05C20FF943918238042D7670FD48BFFB57CA@EMBX01-HQ.jnpr.net> <4F713A4C.4040801@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C031EAE8@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48C031EAE8@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 18:21:56 -0000 On Tue, Mar 27, 2012 at 09:34:32AM -0700, Kent Watsen wrote: > Considering these in turn: > > 1. off-box scripts > > The API should be simple to use via a scripting language. > HTTP is ubiquitous, every scripting language has built-in > support. NETCONF API bindings can be provided, but they'll > never be built into the language nor be as popular. > > 2. off-box NMS apps > > The complexity of the API doesn't matter as much as the > scalability and performance of the protocol. NETCONF may > have the edge here, though HTTP caching servers may make > up for much of that. > > 3. on-box web-interface > > Assuming the web-interface is AJAX/AJAJ, then a REST interface > would be preferred - not only because the HTTP bindings are > built into Javascript, but also because the client could use > JSON and there would be no uncertainty for if the REST API is > available, since it uses the same protocol as the web interface. > > Thoughts? But are all three use cases at the end not boiling down to the same argument, namely the ubiquity of HTTP and JSON support? For me, the question really is whether we are fine with NETCONF being used as a well designed and optimized configuration protocol of bigger networking gear or whether we want to reach out of that niche and seek wider application on say constrained devices or as an interface to network managers (that is software components that configure collections of boxes to provide a certain service) etc. If we want to reach out, then a REST interface is going to make a difference. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Tue Mar 27 12:50:32 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B8C21E80AD; Tue, 27 Mar 2012 12:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezCyothCMmfN; Tue, 27 Mar 2012 12:50:31 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 01BD321E804B; Tue, 27 Mar 2012 12:50:30 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT3IaAxnTpN0dTXg06SefWt/Swnaxv0VC@postini.com; Tue, 27 Mar 2012 12:50:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 27 Mar 2012 12:50:18 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Tue, 27 Mar 2012 12:50:14 -0700 Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0MRQCkJgxV6tpfTAyH/eCRbcL62AACllbg Message-ID: <84600D05C20FF943918238042D7670FD48C031ED4D@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> <20120327181108.GA37080@elstar.local> In-Reply-To: <20120327181108.GA37080@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:50:32 -0000 > There is a JSON patch format and it would be nice to use that together with HTTP PATCH= (RFC 5789) to do modifications. And the XML Patch format is defined in RFC 5261. If we do this, we'd need = to support both XML and JSON. > we would need to support filtered retrieval in some way. Following mimics the example given in RFC 6241 for the Xpath capability: ---Request--- (pretend I escaped the URL yuk) GET /running?xmlns:t=3D"http://example.com/schema/1.2/config"& select=3D"/t= :top/t:users/t:user[t:name=3D'fred']" HTTP/1.1 Host: acme.company.com Authorization: Basic xxxxxxxxxxxxxxxxxxx Accept: application/xml; application/json =20 ---Response--- HTTP/1.1 200 OK Content-Type: application/xml Content-Length: nnn fred 2 From j.schoenwaelder@jacobs-university.de Tue Mar 27 15:26:14 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B03E21E8139 for ; Tue, 27 Mar 2012 15:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJo9cc5NgVxv for ; Tue, 27 Mar 2012 15:26:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C0EF821E8011 for ; Tue, 27 Mar 2012 15:26:13 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8886020CAD; Wed, 28 Mar 2012 00:26:12 +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 ezOtGCEFY71Q; Wed, 28 Mar 2012 00:26:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C23D20C9E; Wed, 28 Mar 2012 00:26:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3FEE11E201E0; Wed, 28 Mar 2012 00:26:12 +0200 (CEST) Date: Wed, 28 Mar 2012 00:26:12 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120327222612.GC37380@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> <20120327181108.GA37080@elstar.local> <84600D05C20FF943918238042D7670FD48C031ED4D@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48C031ED4D@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 22:26:14 -0000 On Tue, Mar 27, 2012 at 12:50:14PM -0700, Kent Watsen wrote: > > > There is a JSON patch format and it would be nice to use that together with HTTP PATCH (RFC 5789) to do modifications. > > And the XML Patch format is defined in RFC 5261. If we do this, we'd need to support both XML and JSON. You seem to assume that a REST interface supports both XML and JSON. I am not convinced yet this is a good idea. At least one of the formats should be mandatory (or there should just be one format in the first place). If both formats are possible, you force the support for both formats on all implementations, which is costly (or you loose interoperability). /js (trying to stop cross postings - lets have this discussion on netconf) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Tue Mar 27 15:44:07 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7832121E8147 for ; Tue, 27 Mar 2012 15:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk++Z99qLKlZ for ; Tue, 27 Mar 2012 15:44:07 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id C273B21E8024 for ; Tue, 27 Mar 2012 15:44:06 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT3JCtPNPv40BLg//a9LDSuTbRpSzr4NV@postini.com; Tue, 27 Mar 2012 15:44:06 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 27 Mar 2012 15:43:17 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Tue, 27 Mar 2012 15:43:15 -0700 Thread-Topic: [Netconf] netconf/yang side meeting in paris on monday morning Thread-Index: Ac0MaJ688skK1blAQDqcCK4UL3+c4QAAEOpg Message-ID: <84600D05C20FF943918238042D7670FD48C031F00B@EMBX01-HQ.jnpr.net> References: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> <20120327181108.GA37080@elstar.local> <84600D05C20FF943918238042D7670FD48C031ED4D@EMBX01-HQ.jnpr.net> <20120327222612.GC37380@elstar.local> In-Reply-To: <20120327222612.GC37380@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:44:07 -0000 Juergen writes: > You seem to assume that a REST interface supports both XML and JSON.=20 I do and, in fact, our REST API does support both. Our analysis is that so= me developers prefer JSON for its simplicity, but it's limited (e.g. doesn'= t support namespaces). If we had to pick just one, I would pick XML. Thanks, Kent From j.schoenwaelder@jacobs-university.de Wed Mar 28 00:29:22 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA5321F860F for ; Wed, 28 Mar 2012 00:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6zTJ5TJf3hA for ; Wed, 28 Mar 2012 00:29:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F1C9121F852E for ; Wed, 28 Mar 2012 00:29:12 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2672F20CBF; Wed, 28 Mar 2012 09:29:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iMa_YPUmISuG; Wed, 28 Mar 2012 09:29:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9AE020CBB; Wed, 28 Mar 2012 09:29:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EB8161E20A0F; Wed, 28 Mar 2012 09:29:11 +0200 (CEST) Date: Wed, 28 Mar 2012 09:29:11 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20120328072911.GB38587@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <84600D05C20FF943918238042D7670FD48C031EBA9@EMBX01-HQ.jnpr.net> <20120327181108.GA37080@elstar.local> <84600D05C20FF943918238042D7670FD48C031ED4D@EMBX01-HQ.jnpr.net> <20120327222612.GC37380@elstar.local> <84600D05C20FF943918238042D7670FD48C031F00B@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD48C031F00B@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf/yang side meeting in paris on monday morning X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 07:29:22 -0000 On Tue, Mar 27, 2012 at 03:43:15PM -0700, Kent Watsen wrote: > > > Juergen writes: > > You seem to assume that a REST interface supports both XML and JSON. > > I do and, in fact, our REST API does support both. Our analysis is > that some developers prefer JSON for its simplicity, but it's > limited (e.g. doesn't support namespaces). If we had to pick just > one, I would pick XML. For interoperability, it is usually better to have either only one format or one that is mandatory to implement. If its true that JSON has no way to deal with namespaces properly (at this point in time), than in my view JSON is not even an option to consider (at this point in time). Namespaces are essential for NETCONF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Mar 28 04:26:02 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C74C21F890E for ; Wed, 28 Mar 2012 04:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwaOL84qf1mF for ; Wed, 28 Mar 2012 04:25:59 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D1F5221F88E1 for ; Wed, 28 Mar 2012 04:25:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFT0ck+HCzI1/2dsb2JhbAA4Crh2gQeCCQEBAQEDAQEBDx4KNBcGAQgNBAQBAQsGDAsBByYfBwEBBQQBBBMIGodoC51ohBuUPQSKboMAgkFjBJtyihyCaYFa X-IronPort-AV: E=Sophos;i="4.75,331,1330923600"; d="scan'208";a="1699069" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 28 Mar 2012 07:25:58 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Mar 2012 07:10:06 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Mar 2012 13:25:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Confirming Consensus: WebSockets Thread-Index: Ac0MxNy8CxwzNLl+RW+7bSWYE1qjZQAEDqgQ From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] FW: [sipcore] Confirming Consensus: WebSockets X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:26:03 -0000 As NETCONF has on its table a proposal for NETCONF over Web Sockets I believe that this step taken by SIPCORE may be of interest, and so would be talking with SIPCORE chairs and other participants to try to identify where the requirements and concerns are similar and where they differ. Regards, Dan -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach - SIPCORE Chair Sent: Wednesday, March 28, 2012 11:26 AM To: SIPCORE (Session Initiation Protocol Core) WG Subject: [sipcore] Confirming Consensus: WebSockets [as chair] During the face-to-face meeting yesterday, the chairs asked for a feel=20 of the room to gauge support for working on the WebSockets transport for SIP. Consensus among those present was strongly in favor. Based on this impression, the SIPCORE chairs plan to take the following=20 actions unless objections are raised on this email list prior to Friday, April 6th: - We will add a new milestone to our charter: "WebSockets SIP Transport to IESG (PS)" - We will adopt draft-ibc-sipcore-sip-websocket-01 as the basis for fulfilling the new milestone, and request that the authors submit a new version with a filename reflecting this adoption. Thank you. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From tomoyuki.iijima.fg@hitachi.com Wed Mar 28 07:53:59 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83D921F87BE for ; Wed, 28 Mar 2012 07:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM+Ge8574kij for ; Wed, 28 Mar 2012 07:53:59 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id B46F421F87B2 for ; Wed, 28 Mar 2012 07:53:58 -0700 (PDT) Received: from mlsv7.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id B26B837C84; Wed, 28 Mar 2012 23:53:57 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv7.hitachi.co.jp (8.13.1/8.13.1) id q2SErvH3032739; Wed, 28 Mar 2012 23:53:57 +0900 Received: from vshuts4.hitachi.co.jp (vshuts4.hitachi.co.jp [10.201.6.80]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q2SEruWk030425; Wed, 28 Mar 2012 23:53:57 +0900 X-AuditID: b753bd60-96f90ba000007b1b-b2-4f73260422a4 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id 9A6512042F8; Wed, 28 Mar 2012 23:53:56 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id q2SEruP24101056; Wed, 28 Mar 2012 23:53:56 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Wed, 28 Mar 2012 23:53:42 +0900 References: Priority: normal Importance: normal X400-Content-Identifier: X4F7325E900000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28120328235329U5V] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] FW: [sipcore] Confirming Consensus: WebSockets X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 14:54:00 -0000 Hi Dan, >As NETCONF has on its table a proposal for NETCONF over Web Sockets I >believe that this step taken by SIPCORE may be of interest, and so would >be talking with SIPCORE chairs and other participants to try to identify >where the requirements and concerns are similar and where they differ. Thank you for your valuable information! I'd also like to learn how SIPCORE develops by making the best use of WebSocket. Kind regards, Tomoyuki Iijima >As NETCONF has on its table a proposal for NETCONF over Web Sockets I >believe that this step taken by SIPCORE may be of interest, and so would >be talking with SIPCORE chairs and other participants to try to identify >where the requirements and concerns are similar and where they differ. > >Regards, > >Dan > > > >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Adam Roach - SIPCORE Chair >Sent: Wednesday, March 28, 2012 11:26 AM >To: SIPCORE (Session Initiation Protocol Core) WG >Subject: [sipcore] Confirming Consensus: WebSockets > >[as chair] > >During the face-to-face meeting yesterday, the chairs asked for a feel >of the room to gauge support for working on the WebSockets transport for > >SIP. Consensus among those present was strongly in favor. > >Based on this impression, the SIPCORE chairs plan to take the following >actions unless objections are raised on this email list prior to Friday, > >April 6th: > >- We will add a new milestone to our charter: "WebSockets SIP > Transport to IESG (PS)" > >- We will adopt draft-ibc-sipcore-sip-websocket-01 as the basis > for fulfilling the new milestone, and request that the authors > submit a new version with a filename reflecting this adoption. > >Thank you. > >/a >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Thu Mar 29 04:57:27 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0888E21F86DE for ; Thu, 29 Mar 2012 04:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMIAkzUq12jp for ; Thu, 29 Mar 2012 04:57:26 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 205F721F86D4 for ; Thu, 29 Mar 2012 04:57:26 -0700 (PDT) Received: from localhost (dhcp-1682.meeting.ietf.org [130.129.22.130]) by mail.tail-f.com (Postfix) with ESMTPSA id F18D112008BF for ; Thu, 29 Mar 2012 13:57:24 +0200 (CEST) Date: Thu, 29 Mar 2012 13:57:23 +0200 (CEST) Message-Id: <20120329.135723.374607814.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] review of draft-badra-netconf-rfc5539bis-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:57:27 -0000 Hi, Here are my comments on draft-badra-netconf-rfc5539bis-01: o 3.2 OLD: The server MUST verify the identity of the client to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. NEW: The server MUST verify the identity of the client to ensure that the incoming client request is legitimate before the NETCONF session is started. o 3.2.1 The NETCONF server MAY use any of the following algorithms to produce the NETCONF username from the certificate presented by the NETCONF client: This sounds as the server also may use some other algorithm? o 3.2.1.1 If a locally held copy of a trusted CA certificate is configured in the transformation container, What is "the transformation container"? and that CA certificate was used to validate the path to the presented certificate, then the NETCONF server SHOULD use that list entry in the transformation container. What should the server use that list entry for? And since this is a SHOULD, it seems it doesn't have to use it? During which circumstances can it choose not to use it? o 3.2.1.2 If the selected pre-shared keys match and the key is valid, then the client is authenticated and the NETCONF username associated with the PSK identity. Bad sentence. o 3.2.1.2 For details on how the PSK identity MAY be encoded in UTF-8, see section 5.1. of RFC [RFC6241]. Wrong reference. o YANG module The YANG module is not valid: ietf-netconf-tls.yang:376: error: prefix "nacm" is not defined (reported only once) o data model leaf certificate-to-username-transform-count { leaf certificate-to-username-transform-last-changed { Are these leafs really necessary...? o container certificate-to-username-transforms This is done by considering each active list entry from this container in prioritized order according to its index value. s/active// o container certificate-to-username-transforms The NETCONF server requires only a single container entry to configure this behavior. s/container entry/list entry/ o list certificate-to-username-transform Instead of using an integer key, I suggest you use an ordered-by user list with an arbitratry string as key. This use case is why ordered-by user lists exist. o leaf map-type { Instead of enumerating all different combinations, I suggest you use an ordered-by user leaf-list. Also, I think the following structure would be more natural: choice map-type { leaf specified { type nacm:user-name-type; // note the new type // replaces your "data" leaf } leaf-list from-certificate { type enumeration { enum rfc822Name; enum dNSName; enum ipAddress; } ordered-by user; } } Then you can use for example: bob or dnsName rfc822Name o container psk-map I suggest you align the name of this container with the other container. Currently you have: +--rw certificate-to-username-transforms +--rw psk-map Also, you should have a sinlge top-level container with a descriptive name, under which you can stuff these two containers. o leaf valid-not-before { leaf valid-not-after { Why are these needed? o features Do you expect that all implementations of this document implement both certs and psk? If not, consider adding features. /martin From j.schoenwaelder@jacobs-university.de Thu Mar 29 08:17:54 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B4E21E81F7 for ; Thu, 29 Mar 2012 08:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf1EEmV3IO0s for ; Thu, 29 Mar 2012 08:17:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6121E81FE for ; Thu, 29 Mar 2012 08:17:52 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 728A620C21; Thu, 29 Mar 2012 17:17:51 +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 a8JezySW7AiC; Thu, 29 Mar 2012 17:17:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17A8220C1F; Thu, 29 Mar 2012 17:17:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5666F1E23567; Thu, 29 Mar 2012 17:17:51 +0200 (CEST) Date: Thu, 29 Mar 2012 17:17:51 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120329151751.GB44004@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20120329.135723.374607814.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120329.135723.374607814.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-badra-netconf-rfc5539bis-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 29 Mar 2012 15:17:54 -0000 On Thu, Mar 29, 2012 at 01:57:23PM +0200, Martin Bjorklund wrote: > o container psk-map > > I suggest you align the name of this container with the other > container. Currently you have: > > +--rw certificate-to-username-transforms > +--rw psk-map Yang written by different people. ;-) I liked shorter names... > Also, you should have a sinlge top-level container with a > descriptive name, under which you can stuff these two containers. > > o leaf valid-not-before { > leaf valid-not-after { > > Why are these needed? The idea is that you can provision multiple keys that are valid for different time spans. > o features > > Do you expect that all implementations of this document implement > both certs and psk? If not, consider adding features. Good point. Our code will likely only do psk for any time soon. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Mar 29 14:33:05 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EF921F85CE for ; Thu, 29 Mar 2012 14:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQrhzqmGj2dR for ; Thu, 29 Mar 2012 14:33:04 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 838A121F8514 for ; Thu, 29 Mar 2012 14:33:04 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 952E412008BF; Thu, 29 Mar 2012 23:33:02 +0200 (CEST) Date: Thu, 29 Mar 2012 23:33:01 +0200 (CEST) Message-Id: <20120329.233301.395163114.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120329151751.GB44004@elstar.local> References: <20120329.135723.374607814.mbj@tail-f.com> <20120329151751.GB44004@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-badra-netconf-rfc5539bis-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:33:05 -0000 Juergen Schoenwaelder wrote: > On Thu, Mar 29, 2012 at 01:57:23PM +0200, Martin Bjorklund wrote: > > o leaf valid-not-before { > > leaf valid-not-after { > > > > Why are these needed? > > The idea is that you can provision multiple keys that are valid for > different time spans. So why is this important for this particular use case? Why not for certs? passwords and keys in the system module? /martin From j.schoenwaelder@jacobs-university.de Thu Mar 29 14:47:39 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530D921E801B for ; Thu, 29 Mar 2012 14:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szkJu8c3iJ7N for ; Thu, 29 Mar 2012 14:47:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72E21F85AC for ; Thu, 29 Mar 2012 14:47:38 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB15120C17; Thu, 29 Mar 2012 23:47:36 +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 s0Wkju8NYP_3; Thu, 29 Mar 2012 23:47:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 300C820C0E; Thu, 29 Mar 2012 23:47:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 721BF1E24236; Thu, 29 Mar 2012 23:47:36 +0200 (CEST) Date: Thu, 29 Mar 2012 23:47:36 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120329214736.GA49063@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20120329.135723.374607814.mbj@tail-f.com> <20120329151751.GB44004@elstar.local> <20120329.233301.395163114.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120329.233301.395163114.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-badra-netconf-rfc5539bis-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 29 Mar 2012 21:47:39 -0000 On Thu, Mar 29, 2012 at 11:33:01PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Mar 29, 2012 at 01:57:23PM +0200, Martin Bjorklund wrote: > > > o leaf valid-not-before { > > > leaf valid-not-after { > > > > > > Why are these needed? > > > > The idea is that you can provision multiple keys that are valid for > > different time spans. > > So why is this important for this particular use case? Why not for > certs? passwords and keys in the system module? Certs include this information in the cert. SSH keys are usually (correct me if I am wrong) not time limited. Operating system accounts may be time limited (the whole account) as well as the passwords on some systems. But so far, my understanding was that in this space we focus on basic things that are common across platforms. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Fri Mar 30 01:32:43 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A45C21F8887 for ; Fri, 30 Mar 2012 01:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq+fAWmv2YAh for ; Fri, 30 Mar 2012 01:32:42 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1898E21F8883 for ; Fri, 30 Mar 2012 01:32:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2U8Wc4Y012866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Mar 2012 10:32:38 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2U8WU3C011964 for ; Fri, 30 Mar 2012 10:32:38 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 10:32:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 10:32:16 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: NETCONF WG Session Summary thread-index: Ac0OTGOAZ1FdgMfZQBWmxHO507FChwAAjGyA From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Mar 2012 08:32:17.0283 (UTC) FILETIME=[9D986D30:01CD0E4F] 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: 2822 X-purgate-ID: 151667::1333096359-00007415-42251D10/0-0/0-0 Subject: [Netconf] FW: NETCONF WG Session Summary X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:32:43 -0000 Dear NETCONF WG, please find below the summary of the NETCONF session in Paris. The co-chairs would like to encourage the WG to debate on the issue for NETCONF-Light discussed during the session as noted below. Please discuss the pros and cons for a "netconf light with no need to support any capabilities" vs. a "must document deviations" approach. Mehmet & Bert _____________________________________________ From: Ersue, Mehmet (NSN - DE/Munich)=20 Sent: Friday, March 30, 2012 10:09 AM To: ext Benoit Claise Cc: 'ext Bert Wijnen (IETF)'; 'ext Romascanu, Dan (Dan)' Subject: NETCONF WG Session Summary Hi Benoit,=20 below is a summary from the NETCONF WG session on March 27, 2012 in Paris, France:=20 - We had approx. 32 participants in the 1 hour NETCONF session.=20 - We reviewed the status of the WG. All chartered WG items are finished. - We went through the non-chartered documents and had a good discussion and review of the documents. Status of the documents: Both chartered items, NETCONF Access Control Model and NETCONF System Notifications documents have been published as RFC. Non-chartered items: Update of NETCONF over TLS (5539bis): Badra presented remaining issues which he is going to address with a new I-D. The sense in the room was in favor of the draft and it will become WG item after the approval on the maillist. NETCONF over Web Sockets: Tomoyuki Iijima explained the changes to address the username handling as required in the updated NETCONF base protocol document. There is a security issue in the draft because of the independent handling of the two security layers for TLS and the authentication based on cookies. It has been recommended to address the issue and submit a new draft. NETCONF-Light: Juergen Schoenwaelder described the updated document, which defines only the hello message as mandatory. Andy Bierman questioned the strategy to provide a solution which is competing with the current NETCONF protocol standard, where deviations can be used to reduce the standard features for an implementation. The WG was in favor of the draft however the issue needs to be solved and needs a discussion on the maillist as one of the key contributors of the draft was not present. NETCONF-Light makes use of the TLS Pre-Shared Key (PSK) authentication introduced in the update of NETCONF over TLS. AOB: Juergen reported from the discussion on the REST API on Monday morning. The discussion was useful to understand the details. However, it has been proposed, for the time being, not to plan the REST API as=20 a chartered document. Action item: The co-chairs will provide a charter update for approval including the update of NETCONF over TLS and=20 NETCONF-Light documents. Bert & Mehmet From j.schoenwaelder@jacobs-university.de Fri Mar 30 01:42:17 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B6021F8653 for ; Fri, 30 Mar 2012 01:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OaE2ZAj1j5K for ; Fri, 30 Mar 2012 01:42:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A3FDC21F864E for ; Fri, 30 Mar 2012 01:42:16 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D20620BE9; Fri, 30 Mar 2012 10:42:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4tj9eRcSLv-k; Fri, 30 Mar 2012 10:42:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3181520BE2; Fri, 30 Mar 2012 10:42:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6BBA31E248E0; Fri, 30 Mar 2012 10:42:14 +0200 (CEST) Date: Fri, 30 Mar 2012 10:42:13 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120330084213.GA49824@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] FW: NETCONF WG Session Summary X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 08:42:17 -0000 On Fri, Mar 30, 2012 at 10:32:16AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > please find below the summary of the NETCONF session in Paris. > > The co-chairs would like to encourage the WG to debate on the issue for > NETCONF-Light discussed during the session as noted below. > Please discuss the pros and cons for a "netconf light with no need to > support any capabilities" vs. a "must document deviations" approach. There surely are more than those two options. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Fri Mar 30 01:47:38 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0C321F86DD for ; Fri, 30 Mar 2012 01:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkZx6Fl9ZP5q for ; Fri, 30 Mar 2012 01:47:38 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id D2C6A21F86D6 for ; Fri, 30 Mar 2012 01:47:37 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SDXUc-0006kU-PG for netconf@ietf.org; Fri, 30 Mar 2012 10:47:36 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-53c6.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SDXUc-00085m-K1 for netconf@ietf.org; Fri, 30 Mar 2012 10:47:34 +0200 Message-ID: <4F757326.8090002@bwijnen.net> Date: Fri, 30 Mar 2012 10:47:34 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40b567d81c7ea34c73d973631816cac1f Subject: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:47:38 -0000 We would like to encourage the WG participants to engage in a discussion on how to allow for the use of NetConf for constrained devices. See below the summary of our discussion at this weeks session in IETF83. Please express your opinions and pls describe the pros and cons (as you see them) of each possible approach. It might also be good if someone (Andy?) could summarize/describe how exactly one can in fact support constrained devices with standard Netconf plus a "deviations" approach. Maybe an example would be the best way to demonstrate how that would be done. Bert and Mehmet On 3/30/12 10:32 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > NETCONF-Light: > > Juergen Schoenwaelder described the updated document, which defines only > the hello message as mandatory. Andy Bierman questioned the strategy to > provide a solution which is competing with the current NETCONF protocol > standard, where deviations can be used to reduce the standard features > for an implementation. The WG was in favor of the draft however the > issue needs to be solved and needs a discussion on the maillist as one > of the key contributors of the draft was not present. NETCONF-Light > makes use of the TLS Pre-Shared Key (PSK) authentication introduced in > the update of NETCONF over TLS. From phil@juniper.net Fri Mar 30 05:45:02 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F8221F8692 for ; Fri, 30 Mar 2012 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rupwXkYcTkLk for ; Fri, 30 Mar 2012 05:44:58 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id CDEAB21F84C9 for ; Fri, 30 Mar 2012 05:44:50 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKT3WqwQQWZBFJzWxXz2T/iRd7aVBygVEm@postini.com; Fri, 30 Mar 2012 05:44:58 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 30 Mar 2012 05:44:47 -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 q2UCil148417; Fri, 30 Mar 2012 05:44:47 -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 q2UCj90q072673; Fri, 30 Mar 2012 08:45:09 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201203301245.q2UCj90q072673@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20120330084213.GA49824@elstar.local> Date: Fri, 30 Mar 2012 08:45:09 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] FW: NETCONF WG Session Summary X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:45:02 -0000 Juergen Schoenwaelder writes: >On Fri, Mar 30, 2012 at 10:32:16AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Dear NETCONF WG, >> >> please find below the summary of the NETCONF session in Paris. >> >> The co-chairs would like to encourage the WG to debate on the issue for >> NETCONF-Light discussed during the session as noted below. >> Please discuss the pros and cons for a "netconf light with no need to >> support any capabilities" vs. a "must document deviations" approach. > >There surely are more than those two options. What is a '"must document deviations" approach'? IIRC our discussions of deviation had the underlaying belief that many vendors would be unwilling to document deviations and tools would need an out-of-band way to learn deviations for unwilling vendors. Is "MUST" supposed to address this issue or some other issue? Thanks, Phil From andy@netconfcentral.org Fri Mar 30 10:07:53 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CF321F861A for ; Fri, 30 Mar 2012 10:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+CM3FOmtWa8 for ; Fri, 30 Mar 2012 10:07:49 -0700 (PDT) Received: from m1plsmtpa01-06.prod.mesa1.secureserver.net (m1plsmtpa01-06.prod.mesa1.secureserver.net [64.202.165.34]) by ietfa.amsl.com (Postfix) with ESMTP id 21CF221F85B5 for ; Fri, 30 Mar 2012 10:07:48 -0700 (PDT) Received: from [10.59.89.170] ([213.41.80.49]) by m1plsmtpa01-06.prod.mesa1.secureserver.net with id rt7m1i00S13qFst01t7nED; Fri, 30 Mar 2012 10:07:48 -0700 Message-ID: <4F75E862.8000509@netconfcentral.org> Date: Fri, 30 Mar 2012 10:07:46 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> <4F757326.8090002@bwijnen.net> In-Reply-To: <4F757326.8090002@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 17:07:53 -0000 On 03/30/2012 01:47 AM, Bert Wijnen (IETF) wrote: > We would like to encourage the WG participants to > engage in a discussion on how to allow for > the use of NetConf for constrained devices. > > See below the summary of our discussion at this weeks > session in IETF83. > > Please express your opinions and pls describe > the pros and cons (as you see them) of each > possible approach. > > It might also be good if someone (Andy?) could > summarize/describe how exactly one can in fact support > constrained devices with standard Netconf plus > a "deviations" approach. Maybe an example would be > the best way to demonstrate how that would be done. > First, I do not agree that NETCONF Light provides any value to application developers. If the device can only push or pull an entire config at once, then FTP already does that. I strongly oppose this work because it is too server-centric and appears to exist simply so the IETF can rubber-stamp anything a server vendor wants to ship and call NETCONF. But assuming one insisted on using a subset of NETCONF for some reason, one can write an applicability statement that documented how to advertise the ietf-netconf module plus some deviations to identify what is missing from the implementation. (The AS is only needed because we are assuming implementers are too dumb to understand RFC 6020 I suppose.) The AS would remind people that YANG has deviation statements and how they are used. It would not violate any YANG rules because the deviation is just an example and published in an AS, not in a YANG module. It would include some examples, such as: E1) is not supported The following example shows a deviation statement that indicates the server does not implement the operation: Example capabilities: The server would advertise both the 'ietf-netconf' module and its own set of deviations for that server implementation (called 'acme-mydevs' in this example): urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2011-06-01&deviations=mydevs http://acme.com/xml/acme-ncdevs?module=acme-mydevs&revision=2012-03-30 Example deviations module 'acme-ncdevs' module acme-ncdevs { namespace "http://acme.com/xml/acme-ncdevs"; prefix ncdevs; import ietf-netconf { prefix nc; } organization "Acme"; description "NETCONF Protocol Deviations."; revision 2012-03-30 { description "Initial revision"; } deviation "/nc:get" { deviate not-supported; } } YANG already has a standard mechanism for describing a module subset. I do not care if vendors do not want to use it. Too bad it makes it appear to customers that the implementation does not support the entire mandatory portion of a module -- that is exactly its purpose, so not surprising that's what it looks like. Andy From andy@netconfcentral.org Fri Mar 30 10:11:29 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290C221F8644 for ; Fri, 30 Mar 2012 10:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMVKFod8Crpz for ; Fri, 30 Mar 2012 10:11:28 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by ietfa.amsl.com (Postfix) with SMTP id 94E4321F85B5 for ; Fri, 30 Mar 2012 10:11:28 -0700 (PDT) Received: (qmail 11776 invoked from network); 30 Mar 2012 17:11:28 -0000 Received: from unknown (213.41.80.50) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 30 Mar 2012 17:11:27 -0000 Message-ID: <4F75E93D.8030505@netconfcentral.org> Date: Fri, 30 Mar 2012 10:11:25 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> <4F757326.8090002@bwijnen.net> <4F75E862.8000509@netconfcentral.org> In-Reply-To: <4F75E862.8000509@netconfcentral.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 17:11:29 -0000 Oops: changed mydevs to acme-mydevs but missed one of them: OLD: urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2011-06-01&deviations=mydevs NEW: urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf-netconf&revision=2011-06-01&deviations=acme-mydevs From robert.g.cole.civ@mail.mil Fri Mar 30 09:51:54 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B7421F8697 for ; Fri, 30 Mar 2012 09:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHLFPPaohKPz for ; Fri, 30 Mar 2012 09:51:53 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7434A21F84D6 for ; Fri, 30 Mar 2012 09:51:52 -0700 (PDT) Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 30 Mar 2012 16:51:45 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.78]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.01.0339.001; Fri, 30 Mar 2012 16:51:45 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: "'bertietf@bwijnen.net'" , "'netconf@ietf.org'" Thread-Topic: [Netconf] Netconf Light or Netconf for constrained devices Thread-Index: AQHNDlHJQcaO5HCRVU+6KqDoAc5GmpaDDiGU Date: Fri, 30 Mar 2012 16:51:42 +0000 Message-ID: In-Reply-To: <4F757326.8090002@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 30 Mar 2012 16:08:49 -0700 Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 16:51:54 -0000 Bert, I am interested in a NETCONF-lite for constrained devises. However, I worr= y about approaches that either baseline at either a) NETCONF- zero with ven= dors adding whatever features they think appropriate or b) NETCONF with ve= ndors subtracting whatever deviations they think appropriate. I would, fo= r simplicity sake, prefer the expertise in the WG to define a baseline NETC= ONF-lite feature set that I could easily explain to my acquisition and proc= urement folks. Thanks, Bob=20 ----- Original Message ----- From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] Sent: Friday, March 30, 2012 08:47 AM=0A= To: netconf@ietf.org Subject: [Netconf] Netconf Light or Netconf for constrained devices We would like to encourage the WG participants to engage in a discussion on how to allow for the use of NetConf for constrained devices. See below the summary of our discussion at this weeks session in IETF83. Please express your opinions and pls describe the pros and cons (as you see them) of each possible approach. It might also be good if someone (Andy?) could summarize/describe how exactly one can in fact support constrained devices with standard Netconf plus a "deviations" approach. Maybe an example would be the best way to demonstrate how that would be done. Bert and Mehmet On 3/30/12 10:32 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > NETCONF-Light: > > Juergen Schoenwaelder described the updated document, which defines only > the hello message as mandatory. Andy Bierman questioned the strategy to > provide a solution which is competing with the current NETCONF protocol > standard, where deviations can be used to reduce the standard features > for an implementation. The WG was in favor of the draft however the > issue needs to be solved and needs a discussion on the maillist as one > of the key contributors of the draft was not present. NETCONF-Light > makes use of the TLS Pre-Shared Key (PSK) authentication introduced in > the update of NETCONF over TLS. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From andy@netconfcentral.org Fri Mar 30 18:13:56 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BE921E8019 for ; Fri, 30 Mar 2012 18:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVSUPh8NSe2C for ; Fri, 30 Mar 2012 18:13:55 -0700 (PDT) Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) by ietfa.amsl.com (Postfix) with SMTP id 08D4721F8575 for ; Fri, 30 Mar 2012 18:13:54 -0700 (PDT) Received: (qmail 2661 invoked from network); 31 Mar 2012 01:13:53 -0000 Received: from unknown (93.158.47.209) by p3plsmtpa07-08.prod.phx3.secureserver.net (173.201.192.237) with ESMTP; 31 Mar 2012 01:13:53 -0000 Message-ID: <4F765A4F.3040805@netconfcentral.org> Date: Fri, 30 Mar 2012 18:13:51 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "Cole, Robert G CIV USARMY CERDEC (US)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'netconf@ietf.org'" Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 01:13:56 -0000 On 03/30/2012 09:51 AM, Cole, Robert G CIV USARMY CERDEC (US) wrote: > Bert, > > I am interested in a NETCONF-lite for constrained devises. However, I worry about approaches that either baseline at either a) NETCONF- zero with vendors adding whatever features they think appropriate or b) NETCONF with vendors subtracting whatever deviations they think appropriate. I would, for simplicity sake, prefer the expertise in the WG to define a baseline NETCONF-lite feature set that I could easily explain to my acquisition and procurement folks. > This seems reasonable -- if we can agree on the definition of a constrained device. According to the draft, 'constrained' can mean either the device resources or the server developer resources. NETCONF is intended to provide configuration management functionality. I think the people who want NETCONF-Light should write a requirements document that defines a constrained device, identifies the specific use cases and specific subset of CM functionality that is mandatory for constrained devices. I am concerned about application developers who need to provide meaningful CM functionality to customers, and this will be nearly impossible unless the IETF agrees on a mandatory-to-implement subset of NETCONF. > Thanks, Bob Andy > > ----- Original Message ----- > From: Bert Wijnen (IETF) [mailto:bertietf@bwijnen.net] > Sent: Friday, March 30, 2012 08:47 AM > To: netconf@ietf.org > Subject: [Netconf] Netconf Light or Netconf for constrained devices > > We would like to encourage the WG participants to > engage in a discussion on how to allow for > the use of NetConf for constrained devices. > > See below the summary of our discussion at this weeks > session in IETF83. > > Please express your opinions and pls describe > the pros and cons (as you see them) of each > possible approach. > > It might also be good if someone (Andy?) could > summarize/describe how exactly one can in fact support > constrained devices with standard Netconf plus > a "deviations" approach. Maybe an example would be > the best way to demonstrate how that would be done. > > Bert and Mehmet > > On 3/30/12 10:32 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> NETCONF-Light: >> >> Juergen Schoenwaelder described the updated document, which defines only >> the hello message as mandatory. Andy Bierman questioned the strategy to >> provide a solution which is competing with the current NETCONF protocol >> standard, where deviations can be used to reduce the standard features >> for an implementation. The WG was in favor of the draft however the >> issue needs to be solved and needs a discussion on the maillist as one >> of the key contributors of the draft was not present. NETCONF-Light >> makes use of the TLS Pre-Shared Key (PSK) authentication introduced in >> the update of NETCONF over TLS. > _______________________________________________ > 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 > > From j.schoenwaelder@jacobs-university.de Fri Mar 30 22:10:56 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE71E21F86C4 for ; Fri, 30 Mar 2012 22:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffFGLXtLEPVc for ; Fri, 30 Mar 2012 22:10:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 226D621F86C2 for ; Fri, 30 Mar 2012 22:10:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 121EC20C14; Sat, 31 Mar 2012 07:10:53 +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 aONZ5xIX9LDc; Sat, 31 Mar 2012 07:10:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F77620BEB; Sat, 31 Mar 2012 07:10:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B3B961E26E27; Sat, 31 Mar 2012 07:10:51 +0200 (CEST) Date: Sat, 31 Mar 2012 07:10:51 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120331051051.GA70150@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> <4F757326.8090002@bwijnen.net> <4F75E862.8000509@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F75E862.8000509@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 31 Mar 2012 05:10:57 -0000 On Fri, Mar 30, 2012 at 10:07:46AM -0700, Andy Bierman wrote: > But assuming one insisted on using a subset of NETCONF for some reason, > one can write an applicability statement that documented how to > advertise the ietf-netconf module plus some deviations to > identify what is missing from the implementation. (The AS is only needed > because we are assuming implementers are too dumb to understand RFC 6020 > I suppose.) This is kind of funny. The I-D actually says an incomplete NETCONF implementation calls itself 'NETCONF Light' (and not 'NETCONF'2) while you seem to prefer that an incomplete NETCONF implementation calls itself 'NETCONF' and then posts some deviations. (While server implementors might be too dumb, it might also be that client implementors are too dumb to handle deviations well.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Mar 30 22:15:39 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE8C21F871E for ; Fri, 30 Mar 2012 22:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdRIbMJthq3j for ; Fri, 30 Mar 2012 22:15:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 084CA21F871D for ; Fri, 30 Mar 2012 22:15:39 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 535FB20BF6; Sat, 31 Mar 2012 07:15:38 +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 Cmxuf8i2J-6i; Sat, 31 Mar 2012 07:15:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D362020BEC; Sat, 31 Mar 2012 07:15:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 36D611E26E6B; Sat, 31 Mar 2012 07:15:38 +0200 (CEST) Date: Sat, 31 Mar 2012 07:15:38 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120331051538.GB70150@elstar.local> Mail-Followup-To: Andy Bierman , "Cole, Robert G CIV USARMY CERDEC (US)" , "'netconf@ietf.org'" References: <4F765A4F.3040805@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F765A4F.3040805@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Cole, Robert G CIV USARMY CERDEC \(US\)" , "'netconf@ietf.org'" Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 31 Mar 2012 05:15:39 -0000 On Fri, Mar 30, 2012 at 06:13:51PM -0700, Andy Bierman wrote: > NETCONF is intended to provide configuration management functionality. > I think the people who want NETCONF-Light should write a requirements > document that defines a constrained device, identifies the specific > use cases and specific subset of CM functionality that is mandatory > for constrained devices. There is text describing the use cases etc. Perhaps you can help us by telling us which of the features that the YANG module defines should be manadatory for you to be happy. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Fri Mar 30 23:48:38 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEA121F85DB for ; Fri, 30 Mar 2012 23:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0iuu2mLUU3g for ; Fri, 30 Mar 2012 23:48:37 -0700 (PDT) Received: from p3plsmtpa08-02.prod.phx3.secureserver.net (p3plsmtpa08-02.prod.phx3.secureserver.net [173.201.193.103]) by ietfa.amsl.com (Postfix) with SMTP id 9F63621F85D7 for ; Fri, 30 Mar 2012 23:48:37 -0700 (PDT) Received: (qmail 25286 invoked from network); 31 Mar 2012 06:48:31 -0000 Received: from unknown (93.158.42.164) by p3plsmtpa08-02.prod.phx3.secureserver.net (173.201.193.103) with ESMTP; 31 Mar 2012 06:48:31 -0000 Message-ID: <4F76A8BE.6050708@netconfcentral.org> Date: Fri, 30 Mar 2012 23:48:30 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> <4F757326.8090002@bwijnen.net> <4F75E862.8000509@netconfcentral.org> <20120331051051.GA70150@elstar.local> In-Reply-To: <20120331051051.GA70150@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 06:48:38 -0000 On 03/30/2012 10:10 PM, Juergen Schoenwaelder wrote: > On Fri, Mar 30, 2012 at 10:07:46AM -0700, Andy Bierman wrote: > >> But assuming one insisted on using a subset of NETCONF for some reason, >> one can write an applicability statement that documented how to >> advertise the ietf-netconf module plus some deviations to >> identify what is missing from the implementation. (The AS is only needed >> because we are assuming implementers are too dumb to understand RFC 6020 >> I suppose.) > > This is kind of funny. The I-D actually says an incomplete NETCONF > implementation calls itself 'NETCONF Light' (and not 'NETCONF'2) while > you seem to prefer that an incomplete NETCONF implementation calls > itself 'NETCONF' and then posts some deviations. > > (While server implementors might be too dumb, it might also be that > client implementors are too dumb to handle deviations well.) > There is no NETCONF Light -- and I hope there never will be one. That is just a meaningless marketing term. NETCONF for Constrained Devices might be OK if it provided some meaningful set of CM functionality. Your draft assumes that customers are too dumb to know the difference. > /js > Andy From andy@netconfcentral.org Fri Mar 30 23:54:01 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072A921F8625 for ; Fri, 30 Mar 2012 23:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC1TkED1yPIp for ; Fri, 30 Mar 2012 23:54:00 -0700 (PDT) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by ietfa.amsl.com (Postfix) with SMTP id EFD5021F8610 for ; Fri, 30 Mar 2012 23:53:59 -0700 (PDT) Received: (qmail 12134 invoked from network); 31 Mar 2012 06:53:55 -0000 Received: from unknown (93.158.42.164) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 31 Mar 2012 06:53:55 -0000 Message-ID: <4F76AA02.4030401@netconfcentral.org> Date: Fri, 30 Mar 2012 23:53:54 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "Cole, Robert G CIV USARMY CERDEC (US)" , "'netconf@ietf.org'" References: <4F765A4F.3040805@netconfcentral.org> <20120331051538.GB70150@elstar.local> In-Reply-To: <20120331051538.GB70150@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 06:54:01 -0000 On 03/30/2012 10:15 PM, Juergen Schoenwaelder wrote: > On Fri, Mar 30, 2012 at 06:13:51PM -0700, Andy Bierman wrote: > >> NETCONF is intended to provide configuration management functionality. >> I think the people who want NETCONF-Light should write a requirements >> document that defines a constrained device, identifies the specific >> use cases and specific subset of CM functionality that is mandatory >> for constrained devices. > > There is text describing the use cases etc. Perhaps you can help us by > telling us which of the features that the YANG module defines should > be manadatory for you to be happy. > You seem to think that constrained devices includes server developers unwilling to implement NETCONF correctly. I do not recognize that class of power constrained devices. But I'll play along -- I already did this and it got ignored: - get-config (with subtree filtering mandatory) - edit-config - close-session - lock - unlock There is my minimum set that provides CM functionality. One can perform CRUD operations safely on a device with these operations. > /js > Andy From andy@netconfcentral.org Sat Mar 31 00:08:11 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5977021E802B for ; Sat, 31 Mar 2012 00:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sckjBQbfiOlx for ; Sat, 31 Mar 2012 00:08:10 -0700 (PDT) Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) by ietfa.amsl.com (Postfix) with SMTP id D136621E8020 for ; Sat, 31 Mar 2012 00:08:10 -0700 (PDT) Received: (qmail 17573 invoked from network); 31 Mar 2012 07:08:09 -0000 Received: from unknown (93.158.42.164) by p3plsmtpa06-09.prod.phx3.secureserver.net (173.201.192.110) with ESMTP; 31 Mar 2012 07:08:09 -0000 Message-ID: <4F76AD57.5000604@netconfcentral.org> Date: Sat, 31 Mar 2012 00:08:07 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> <4F757326.8090002@bwijnen.net> <4F75E862.8000509@netconfcentral.org> <20120331051051.GA70150@elstar.local> In-Reply-To: <20120331051051.GA70150@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 07:08:11 -0000 On 03/30/2012 10:10 PM, Juergen Schoenwaelder wrote: > On Fri, Mar 30, 2012 at 10:07:46AM -0700, Andy Bierman wrote: > >> But assuming one insisted on using a subset of NETCONF for some reason, >> one can write an applicability statement that documented how to >> advertise the ietf-netconf module plus some deviations to >> identify what is missing from the implementation. (The AS is only needed >> because we are assuming implementers are too dumb to understand RFC 6020 >> I suppose.) > > This is kind of funny. The I-D actually says an incomplete NETCONF > implementation calls itself 'NETCONF Light' (and not 'NETCONF'2) while > you seem to prefer that an incomplete NETCONF implementation calls > itself 'NETCONF' and then posts some deviations. > You probably need to re-read section 5.6.4 of RFC 6020. Advertising + deviations is the way YANG is designed. > > /js > Andy From andy@netconfcentral.org Sat Mar 31 00:27:18 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436C521F845D for ; Sat, 31 Mar 2012 00:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqFemhCbCzb7 for ; Sat, 31 Mar 2012 00:27:17 -0700 (PDT) Received: from m1plsmtpa01-04.prod.mesa1.secureserver.net (m1plsmtpa01-04.prod.mesa1.secureserver.net [64.202.165.6]) by ietfa.amsl.com (Postfix) with ESMTP id 62D5821F845C for ; Sat, 31 Mar 2012 00:27:17 -0700 (PDT) Received: from [10.216.7.195] ([93.158.42.164]) by m1plsmtpa01-04.prod.mesa1.secureserver.net with id s7TF1i0083YXBEd017TGKb; Sat, 31 Mar 2012 00:27:16 -0700 Message-ID: <4F76B1D3.1040508@netconfcentral.org> Date: Sat, 31 Mar 2012 00:27:15 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> <4F757326.8090002@bwijnen.net> <4F75E862.8000509@netconfcentral.org> <20120331051051.GA70150@elstar.local> In-Reply-To: <20120331051051.GA70150@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 07:27:18 -0000 On 03/30/2012 10:10 PM, Juergen Schoenwaelder wrote: > On Fri, Mar 30, 2012 at 10:07:46AM -0700, Andy Bierman wrote: ... > This is kind of funny. The I-D actually says an incomplete NETCONF > implementation calls itself 'NETCONF Light' (and not 'NETCONF'2) while > you seem to prefer that an incomplete NETCONF implementation calls > itself 'NETCONF' and then posts some deviations. > The solution defined in this draft is completely broken. It specifies several meaningless YANG features. They have no affect on YANG modules whatsoever unless a module contains 'if-feature' statements identifying which nodes are conditional for the feature. Your solution does not use YANG correctly. > > /js > Andy From j.schoenwaelder@jacobs-university.de Sat Mar 31 02:28:50 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6497D21F84D6 for ; Sat, 31 Mar 2012 02:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0iru-B49PfW for ; Sat, 31 Mar 2012 02:28:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA6621F848A for ; Sat, 31 Mar 2012 02:28:49 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E026F20C15; Sat, 31 Mar 2012 11:28:48 +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 TIPRnhHxzu73; Sat, 31 Mar 2012 11:28:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F6AB20BF3; Sat, 31 Mar 2012 11:28:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 314171E27173; Sat, 31 Mar 2012 11:28:48 +0200 (CEST) Date: Sat, 31 Mar 2012 11:28:47 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120331092847.GA70620@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , netconf@ietf.org References: <80A0822C5E9A4440A5117C2F4CD36A640398E384@DEMUEXC006.nsn-intra.net> <4F757326.8090002@bwijnen.net> <4F75E862.8000509@netconfcentral.org> <20120331051051.GA70150@elstar.local> <4F76A8BE.6050708@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F76A8BE.6050708@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 31 Mar 2012 09:28:50 -0000 On Fri, Mar 30, 2012 at 11:48:30PM -0700, Andy Bierman wrote: > On 03/30/2012 10:10 PM, Juergen Schoenwaelder wrote: > >On Fri, Mar 30, 2012 at 10:07:46AM -0700, Andy Bierman wrote: > > > >>But assuming one insisted on using a subset of NETCONF for some reason, > >>one can write an applicability statement that documented how to > >>advertise the ietf-netconf module plus some deviations to > >>identify what is missing from the implementation. (The AS is only needed > >>because we are assuming implementers are too dumb to understand RFC 6020 > >>I suppose.) > > > >This is kind of funny. The I-D actually says an incomplete NETCONF > >implementation calls itself 'NETCONF Light' (and not 'NETCONF'2) while > >you seem to prefer that an incomplete NETCONF implementation calls > >itself 'NETCONF' and then posts some deviations. > > > >(While server implementors might be too dumb, it might also be that > >client implementors are too dumb to handle deviations well.) > > > > There is no NETCONF Light -- and I hope there never will be one. > That is just a meaningless marketing term. NETCONF for Constrained > Devices might be OK if it provided some meaningful set of CM functionality. > > Your draft assumes that customers are too dumb to know the difference. The way NETCONF Light is defined in the I-D, it is not a marketing term. I understand you do not like the -01 I-D, I can follow your argument that some set of NETCONF operations should be mandatory, the rest however just seems to be noise. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sat Mar 31 02:38:11 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A6B21F85F6 for ; Sat, 31 Mar 2012 02:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvyw-ivcYX6V for ; Sat, 31 Mar 2012 02:38:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F1C5A21F85D1 for ; Sat, 31 Mar 2012 02:38:10 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAA8E20C15; Sat, 31 Mar 2012 11:38:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6wC43HV3bwH2; Sat, 31 Mar 2012 11:38:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B37620C06; Sat, 31 Mar 2012 11:38:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 50E831E271B6; Sat, 31 Mar 2012 11:38:09 +0200 (CEST) Date: Sat, 31 Mar 2012 11:38:09 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120331093809.GB70620@elstar.local> Mail-Followup-To: Andy Bierman , "Cole, Robert G CIV USARMY CERDEC (US)" , "'netconf@ietf.org'" References: <4F765A4F.3040805@netconfcentral.org> <20120331051538.GB70150@elstar.local> <4F76AA02.4030401@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F76AA02.4030401@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Cole, Robert G CIV USARMY CERDEC \(US\)" , "'netconf@ietf.org'" Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 31 Mar 2012 09:38:12 -0000 On Fri, Mar 30, 2012 at 11:53:54PM -0700, Andy Bierman wrote: > > But I'll play along -- I already did this and it got ignored: > > - get-config (with subtree filtering mandatory) > - edit-config > - close-session > - lock > - unlock > > There is my minimum set that provides CM functionality. > One can perform CRUD operations safely on a device with these operations. On constrained devices, you do not need subtree filtering nor do you have the resources to implement edit-config. But valuable to know that your requirements differ from the -00 requirements as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Sat Mar 31 06:09:15 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4921F8503 for ; Sat, 31 Mar 2012 06:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUKpJo-qV2Ux for ; Sat, 31 Mar 2012 06:09:15 -0700 (PDT) Received: from m1plsmtpa01-02.prod.mesa1.secureserver.net (m1plsmtpa01-02.prod.mesa1.secureserver.net [64.202.165.174]) by ietfa.amsl.com (Postfix) with ESMTP id E05E821F84FE for ; Sat, 31 Mar 2012 06:09:14 -0700 (PDT) Received: from [10.216.7.195] ([93.158.47.30]) by m1plsmtpa01-02.prod.mesa1.secureserver.net with id sD9D1i0020f4d0D01D9D1P; Sat, 31 Mar 2012 06:09:14 -0700 Message-ID: <4F7701F9.7020802@netconfcentral.org> Date: Sat, 31 Mar 2012 06:09:13 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "Cole, Robert G CIV USARMY CERDEC (US)" , "'netconf@ietf.org'" References: <4F765A4F.3040805@netconfcentral.org> <20120331051538.GB70150@elstar.local> <4F76AA02.4030401@netconfcentral.org> <20120331093809.GB70620@elstar.local> In-Reply-To: <20120331093809.GB70620@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 13:09:15 -0000 On 03/31/2012 02:38 AM, Juergen Schoenwaelder wrote: > On Fri, Mar 30, 2012 at 11:53:54PM -0700, Andy Bierman wrote: >> >> But I'll play along -- I already did this and it got ignored: >> >> - get-config (with subtree filtering mandatory) >> - edit-config >> - close-session >> - lock >> - unlock >> >> There is my minimum set that provides CM functionality. >> One can perform CRUD operations safely on a device with these operations. > > On constrained devices, you do not need subtree filtering nor do you > have the resources to implement edit-config. But valuable to know that > your requirements differ from the -00 requirements as well. > Do you have any proof to support these claims? Why is subtree filtering not needed? What if the bandwidth is very constrained and getting the entire config is too slow? IMO it is quite easy to implement these features if they are hard-wired for the specific data models the server supports. But let's ignore the solution space for now because we do not agree on the problem space. The draft does not describe the problem to be solved in terms of the minimum set of configuration management functionality that is needed. There is no mention at all of the conceptual CRUD operations or data models. The WG must agree on this minimum set of CM functionality before working on a solution. Section 2.2 does not seem to have anything to do with constrained devices: 2.2. Gradually Adding NETCONF Support While the NETCONF protocol defines a number of capabilities that may be optionally implemented, the base protocol remains a significant effort to add for existing devices. For these devices, adding support for NETCONF is primarily driven by a specific integration target, thus the intrinsic goal is to have an initial release that satisfies the integration target and a subsequent release that implements the remainder of the NETCONF protocol. Some scenarios where phasing in the imeplmentation would be helpful include: o The device's primary goal is to implement a vendor-specific capability. In this case, the device is only using NETCONF for its "Messages" layer (i.e. RPC, RPC-reply, and Notification). This is not standard NETCONF at all so it is not relevant to the IETF. o The device's primary goal is to just support read-only access to its configuration. In this case, it only needs to implement initially, leaving the remaining operations for a future release. This is not useful configuration management. read-only is monitoring. o The device's primary goal is to enable full configuration, but it doesn't have the time to implement all the operations. In this case, the device could implement just . This is not a standards problem. There is nothing in any of the RFCs that says you have to ship incomplete code. o The device's primary goal is to enable full configuration, but it is unable to implement or due to its platform not having a locking mechanism yet. This is simply an incomplete implementation and not a standards problem. I cannot find any terminology in the CoAP documents that would suggest that constrained devices includes any of the use cases above. The term always seems to refer to device resources at run-time, not developer resources at build-time. I suggest removing all text from your draft that is not related to run-time device resources. I would like to hear from other WG members if they think the definition of constrained devices includes the use-cases in sec. 2.2. > /js > Andy From j.schoenwaelder@jacobs-university.de Sat Mar 31 07:29:41 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E527C21F866B for ; Sat, 31 Mar 2012 07:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sRkIQscBMuH for ; Sat, 31 Mar 2012 07:29:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BECF021F855A for ; Sat, 31 Mar 2012 07:29:40 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB9A720C24; Sat, 31 Mar 2012 16:29:39 +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 UqcnpTvWG0me; Sat, 31 Mar 2012 16:29:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0F9420C23; Sat, 31 Mar 2012 16:29:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 90AEA1E274B8; Sat, 31 Mar 2012 16:29:37 +0200 (CEST) Date: Sat, 31 Mar 2012 16:29:37 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120331142936.GA71199@elstar.local> Mail-Followup-To: Andy Bierman , "Cole, Robert G CIV USARMY CERDEC (US)" , "'netconf@ietf.org'" References: <4F765A4F.3040805@netconfcentral.org> <20120331051538.GB70150@elstar.local> <4F76AA02.4030401@netconfcentral.org> <20120331093809.GB70620@elstar.local> <4F7701F9.7020802@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F7701F9.7020802@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Cole, Robert G CIV USARMY CERDEC \(US\)" , "'netconf@ietf.org'" Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 31 Mar 2012 14:29:42 -0000 On Sat, Mar 31, 2012 at 06:09:13AM -0700, Andy Bierman wrote: > On 03/31/2012 02:38 AM, Juergen Schoenwaelder wrote: > >On Fri, Mar 30, 2012 at 11:53:54PM -0700, Andy Bierman wrote: > >> > >>But I'll play along -- I already did this and it got ignored: > >> > >> - get-config (with subtree filtering mandatory) > >> - edit-config > >> - close-session > >> - lock > >> - unlock > >> > >>There is my minimum set that provides CM functionality. > >>One can perform CRUD operations safely on a device with these operations. > > > >On constrained devices, you do not need subtree filtering nor do you > >have the resources to implement edit-config. But valuable to know that > >your requirements differ from the -00 requirements as well. > > > > Do you have any proof to support these claims? > Why is subtree filtering not needed? > What if the bandwidth is very constrained and getting the > entire config is too slow? > > IMO it is quite easy to implement these features if they are hard-wired > for the specific data models the server supports. > > But let's ignore the solution space for now because we do not agree > on the problem space. > > > The draft does not describe the problem to be solved in terms of > the minimum set of configuration management functionality that > is needed. There is no mention at all of the conceptual CRUD > operations or data models. The WG must agree on this minimum > set of CM functionality before working on a solution. > > Section 2.2 does not seem to have anything to do with constrained devices: > > 2.2. Gradually Adding NETCONF Support > > While the NETCONF protocol defines a number of capabilities that may > be optionally implemented, the base protocol remains a significant > effort to add for existing devices. For these devices, adding > support for NETCONF is primarily driven by a specific integration > target, thus the intrinsic goal is to have an initial release that > satisfies the integration target and a subsequent release that > implements the remainder of the NETCONF protocol. > > Some scenarios where phasing in the imeplmentation would be helpful > include: > > o The device's primary goal is to implement a vendor-specific > capability. In this case, the device is only using NETCONF for > its "Messages" layer (i.e. RPC, RPC-reply, and Notification). > > This is not standard NETCONF at all so it is not relevant to the IETF. > > o The device's primary goal is to just support read-only access to > its configuration. In this case, it only needs to implement config> initially, leaving the remaining operations for a future > release. > > This is not useful configuration management. read-only is monitoring. > > o The device's primary goal is to enable full configuration, but it > doesn't have the time to implement all the > operations. In this case, the device could implement just config>. > > This is not a standards problem. There is nothing in any of the RFCs > that says you have to ship incomplete code. > > o The device's primary goal is to enable full configuration, but it > is unable to implement or due to its platform not > having a locking mechanism yet. > > This is simply an incomplete implementation and not a standards problem. > > > I cannot find any terminology in the CoAP documents that would suggest > that constrained devices includes any of the use cases above. The term > always seems to refer to device resources at run-time, not developer > resources at build-time. I suggest removing all text from your draft > that is not related to run-time device resources. > > I would like to hear from other WG members if they think the definition > of constrained devices includes the use-cases in sec. 2.2. You correctly figured out that section 2 provides two motivations (sections 2.1 and 2.2) but you incorrectly lump them together thereby creating noise but not a sound argument. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Sat Mar 31 08:10:33 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D9D21F8589 for ; Sat, 31 Mar 2012 08:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgplXNONeilZ for ; Sat, 31 Mar 2012 08:10:32 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id B03B521F8559 for ; Sat, 31 Mar 2012 08:10:29 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT3ceZJIS1XPMAjVOgxOjDLyaBTXV7I4E@postini.com; Sat, 31 Mar 2012 08:10:32 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 31 Mar 2012 08:10:24 -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 q2VFAN180638; Sat, 31 Mar 2012 08:10:23 -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 q2VFAkIG082223; Sat, 31 Mar 2012 11:10:46 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201203311510.q2VFAkIG082223@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20120331093809.GB70620@elstar.local> Date: Sat, 31 Mar 2012 11:10:46 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "'netconf@ietf.org'" , "Cole, Robert G CIV USARMY CERDEC \(US\)" Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 15:10:33 -0000 Juergen Schoenwaelder writes: >On constrained devices, you do not need subtree filtering nor do you >have the resources to implement edit-config. But valuable to know that >your requirements differ from the -00 requirements as well. Since subtree filtering is tied to the data model, can you constrained device simply say that your data models do not support subtree filtering? Thanks, Phil From mbj@tail-f.com Sat Mar 31 13:25:02 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A5B21F8742 for ; Sat, 31 Mar 2012 13:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DLcZR+lP12E for ; Sat, 31 Mar 2012 13:25:01 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 92FBB21F8741 for ; Sat, 31 Mar 2012 13:25:01 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 3D67F1200AE5; Sat, 31 Mar 2012 22:24:59 +0200 (CEST) Date: Sat, 31 Mar 2012 22:24:58 +0200 (CEST) Message-Id: <20120331.222458.230676809.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201203311510.q2VFAkIG082223@idle.juniper.net> References: <20120331093809.GB70620@elstar.local> <201203311510.q2VFAkIG082223@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: robert.g.cole.civ@mail.mil, netconf@ietf.org Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 20:25:02 -0000 Phil Shafer wrote: > Since subtree filtering is tied to the data model Subtree filtering is tied to the NETCONF protocol, independent of the data model or data modelling language. /martin From andy@netconfcentral.org Sat Mar 31 13:27:07 2012 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05921F8742 for ; Sat, 31 Mar 2012 13:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QylIk3EYQLHp for ; Sat, 31 Mar 2012 13:27:06 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) by ietfa.amsl.com (Postfix) with SMTP id B9B1321F8741 for ; Sat, 31 Mar 2012 13:27:06 -0700 (PDT) Received: (qmail 23666 invoked from network); 31 Mar 2012 20:27:06 -0000 Received: from unknown (93.158.46.90) by p3plsmtpa07-06.prod.phx3.secureserver.net (173.201.192.235) with ESMTP; 31 Mar 2012 20:27:06 -0000 Message-ID: <4F776898.9060904@netconfcentral.org> Date: Sat, 31 Mar 2012 13:27:04 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "'netconf@ietf.org'" References: <4F765A4F.3040805@netconfcentral.org> <20120331051538.GB70150@elstar.local> <4F76AA02.4030401@netconfcentral.org> <20120331093809.GB70620@elstar.local> <4F7701F9.7020802@netconfcentral.org> <20120331142936.GA71199@elstar.local> In-Reply-To: <20120331142936.GA71199@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 20:27:07 -0000 ... > You correctly figured out that section 2 provides two motivations > (sections 2.1 and 2.2) but you incorrectly lump them together thereby > creating noise but not a sound argument. > So you admit that sec. 2.2 has nothing to do with constrained devices. Because the WG chairs asked if people wanted to work on NETCONF for constrained devices. They did not ask if the WG wants to work on NETCONF Light. Does anybody besides the co-authors want to solve the problems identified in sec 2.2? Please speak up, yes or no. I agree with Bob that a standard subset of NETCONF picked by the WG is better than a random subset picked by each vendor. Does anybody prefer a vendor-selected random subset instead of a meaningful subset selected by the WG? If the WG comes to some consensus on the problem space, then we can talk about your 'feature-based' solution that doesn't actually work because there are no corresponding if-feature statements in the ietf-netconf module that would make the new features relevant in YANG. > /js > Andy