From nobody Tue Sep 2 03:23:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2471A872A for ; Tue, 2 Sep 2014 03:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEVVJu4sBYHw for ; Tue, 2 Sep 2014 03:23:41 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329FE1A8724 for ; Tue, 2 Sep 2014 03:23:41 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XOlFR-00046z-Qf for netconf@ietf.org; Tue, 02 Sep 2014 12:23:38 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest108.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XOlFR-0002HI-NP for netconf@ietf.org; Tue, 02 Sep 2014 12:23:37 +0200 Message-ID: <54059AA9.4080902@bwijnen.net> Date: Tue, 02 Sep 2014 12:23:37 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Netconf References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd41e733cf7edb4856cd60a74be5db18f3f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2V5cNlyeEpK_zhakP7CI3f3iFnQ Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 10:23:42 -0000 On 26/08/14 22:49, Andy Bierman wrote: > > Perhaps the co-chairs should decide how to proceed somehow. Dear NETCONF WG participants, do you have an opinion? So far I have seen only a few people express their opinion. Please speak up so that we (WG chairs) have better data to judge if we do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. Please speak your mind about these options: a) XML is mandatory b) JSON is mandatory c) XML and JSON are both mandatory d) Both XML and JSON mandatory on client, server can implement whatever it chooses. Not clear yet how the client would find out, but that would of course be something to be worked out if we choose this option Bert From nobody Tue Sep 2 03:54:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CC81A006F for ; Tue, 2 Sep 2014 03:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFbRGYbDDudl for ; Tue, 2 Sep 2014 03:54:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F8B1A0068 for ; Tue, 2 Sep 2014 03:54:13 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 838B91411EA; Tue, 2 Sep 2014 12:54:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409655251; bh=8UKJsJiqLHT+3D+bgn8+tzaejbxCcaMl1ROnYNk28lk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CoM8/FOcMdQbFC2acLfRVqC4pm07ZwwVa8jS60jKhLYdj0O1ODdc4cCsxzgy6IW4f 8etiASeUIACXPMFW3/xPjOIa+q3nRaDBDDQ9/+g1XRUEYnDs6mWcSex0hN3nJb7acp gqzvQpY2dg9XxlE/MpjQuDlBRbshciW/wTAbxbqo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <54059AA9.4080902@bwijnen.net> Date: Tue, 2 Sep 2014 12:54:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5803AA31-FB2E-4141-B84D-824264EB87EE@nic.cz> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> To: Bert Wijnen X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FsPgRoO7TA7UYci5_qQqoMLpNMk Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 10:54:15 -0000 On 02 Sep 2014, at 12:23, Bert Wijnen (IETF) = wrote: > On 26/08/14 22:49, Andy Bierman wrote: >>=20 >> Perhaps the co-chairs should decide how to proceed somehow. >=20 > Dear NETCONF WG participants, do you have an opinion? >=20 > So far I have seen only a few people express their opinion. >=20 > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept = 2014. >=20 > Please speak your mind about these options: >=20 > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. I vote for d), but obviously the server has to choose at least one of = XML or JSON. > Not clear yet how the client would find out, but that would of = course > be something to be worked out if we choose this option Yes. Lada >=20 > Bert >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Sep 2 03:58:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2404C1A0068 for ; Tue, 2 Sep 2014 03:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMZCJESr3dvS for ; Tue, 2 Sep 2014 03:58:47 -0700 (PDT) Received: from rock.dronejett.com (unknown [192.157.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id DD4C11A0061 for ; Tue, 2 Sep 2014 03:58:46 -0700 (PDT) Received: from [80.157.8.200] (unknown [80.157.8.200]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rock.dronejett.com (Postfix) with ESMTPSA id 12064B39; Tue, 2 Sep 2014 06:58:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Bannister In-Reply-To: <54059AA9.4080902@bwijnen.net> Date: Tue, 2 Sep 2014 06:59:56 -0400 Content-Transfer-Encoding: 7bit Message-Id: <291B397E-7994-4CF0-BE71-5221AD2C4711@mojo.net> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> To: "Bert Wijnen (IETF)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HesSww_mzL4Z8rzh0KX1j294Iz0 Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 10:58:48 -0000 D, need both with the option to choose as stated below. On Sep 2, 2014, at 6:23 AM, Bert Wijnen (IETF) wrote: > On 26/08/14 22:49, Andy Bierman wrote: >> >> Perhaps the co-chairs should decide how to proceed somehow. > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 2 04:18:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6651A0185 for ; Tue, 2 Sep 2014 04:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaofCyQCSw0D for ; Tue, 2 Sep 2014 04:18:46 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C0E891A0164 for ; Tue, 2 Sep 2014 04:18:46 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 4A03B1280B42; Tue, 2 Sep 2014 13:15:46 +0200 (CEST) Date: Tue, 02 Sep 2014 13:18:45 +0200 (CEST) Message-Id: <20140902.131845.2031888905641456543.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <54059AA9.4080902@bwijnen.net> References: <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/G7Lhcb76EOhFiC-HKWvtUkD2CUY Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 11:18:48 -0000 "Bert Wijnen (IETF)" wrote: > On 26/08/14 22:49, Andy Bierman wrote: > > > > Perhaps the co-chairs should decide how to proceed somehow. > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept > 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option I prefer (a). I prefer (a) over (b) for the technical reasons already mentioned. (c) is not good for constrained environments. (d) means we raise the bar for implementing clients. /martin From nobody Tue Sep 2 07:32:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731691A045D for ; Tue, 2 Sep 2014 07:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fnvpBdV8b0j for ; Tue, 2 Sep 2014 07:32:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DFF61A0427 for ; Tue, 2 Sep 2014 07:32:22 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 2 Sep 2014 14:32:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.243]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.83]) with mapi id 15.00.1015.018; Tue, 2 Sep 2014 14:32:19 +0000 From: Kent Watsen To: "Bert Wijnen (IETF)" , Netconf Thread-Topic: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity Thread-Index: AQHPxpf7oQcD6jS4CketzovkXj97oJvtpSOA Date: Tue, 2 Sep 2014 14:32:19 +0000 Message-ID: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> In-Reply-To: <54059AA9.4080902@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0322B4EDE1 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(24454002)(199003)(479174003)(377454003)(51704005)(31966008)(87936001)(77982001)(36756003)(76176999)(83506001)(79102001)(46102001)(95666004)(21056001)(20776003)(101416001)(83072002)(93886004)(90102001)(85852003)(74502001)(76482001)(50986999)(99286002)(106116001)(107046002)(92726001)(77096002)(19580395003)(2656002)(4396001)(66066001)(85306004)(81542001)(83322001)(106356001)(54356999)(86362001)(99396002)(107886001)(105586002)(15975445006)(81342001)(80022001)(92566001)(19580405001)(64706001)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <8E7EBAD9346EF74A90D4C4C4E0639B7B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JH-dYbgcjC221Cach4qUDSpMhvw Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:32:24 -0000 I prefer (d), but am OK with (a) Neither (b) nor (c) are viable options IMO. K. On 9/2/14, 6:23 AM, "Bert Wijnen (IETF)" wrote: >On 26/08/14 22:49, Andy Bierman wrote: >> >> Perhaps the co-chairs should decide how to proceed somehow. > >Dear NETCONF WG participants, do you have an opinion? > >So far I have seen only a few people express their opinion. > >Please speak up so that we (WG chairs) have better data to judge if we >do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > >Please speak your mind about these options: > >a) XML is mandatory >b) JSON is mandatory >c) XML and JSON are both mandatory >d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > >Bert > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 2 07:36:43 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB06C1A6F07 for ; Tue, 2 Sep 2014 07:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpSMjxdcjHMA for ; Tue, 2 Sep 2014 07:36:41 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96DE1A069D for ; Tue, 2 Sep 2014 07:36:40 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id DCFEAECB0E2; Tue, 2 Sep 2014 16:36:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1409668598; bh=ItaU+S76raCIkreFxCm6DvRBNj8z1vDJX7k2i8NWQ1o=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mtzOOuPoC+urtxVVgQyCrLhbBe2t4v0rrFYAK+APO5ByY6t58oyD89ymAaQEHECeS xSSF74t3kp7I5/cRCbTjqZ8hC6apqh0JokXaZzmQ4Cgztuq5PggRYi8U64sEVRIVHv pENL+MdHk26iPMpiu7fxvoPLmJtLvZopwOOofp98= Message-ID: <5405D50A.1010506@cesnet.cz> Date: Tue, 02 Sep 2014 16:32:42 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , Netconf References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> In-Reply-To: <54059AA9.4080902@bwijnen.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/QL04nqYAT7io3sml6Cx8jAp2za0 Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:36:43 -0000 Hi, I prefer (a), but I'm ok with (d) Radek Dne 2.9.2014 12:23, Bert Wijnen (IETF) napsal(a): > On 26/08/14 22:49, Andy Bierman wrote: >> >> Perhaps the co-chairs should decide how to proceed somehow. > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci@cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET Association of Legal Entities 160 00 Praha 6, Zikova 4 Czech Republic From nobody Tue Sep 2 07:39:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF51A0466 for ; Tue, 2 Sep 2014 07:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N6Geprg0SRH for ; Tue, 2 Sep 2014 07:39:52 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48B71A044D for ; Tue, 2 Sep 2014 07:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=968; q=dns/txt; s=iport; t=1409668791; x=1410878391; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=we8x5ceDlVgAj81D+id6o2GdJ8td/zK9tUzRe30/+dE=; b=Tc5ceOeg7BCF1V18HcduV+l1c1xvfE/daJcHSS+TuyamvwzF21URLktd p8knjCxcIxt3qJoWmUspZZwIcf/IMOwiO0a4N+JZKkEu6qlsTn8f4wKuR /N78B+8G2G/f4ID4b5uLMGd9DWYR9iwkEh/P5jViqDdzWhHPj2u4+xqkX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAN3VBVStJA2N/2dsb2JhbABagw1TVwTIBwqGeVMBgRMWd4QEAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTAGDQYCAQGIPg27IwETBIwegzYWhDYFiyyRMIc3hF6JCYIbgWZMgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,449,1406592000"; d="scan'208";a="74245051" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 02 Sep 2014 14:39:51 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s82EdpTr019387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Sep 2014 14:39:51 GMT Received: from [10.21.96.91] (10.21.96.91) by xhc-rcd-x12.cisco.com (173.37.183.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Sep 2014 09:39:50 -0500 Message-ID: <5405D6B6.5020207@cisco.com> Date: Tue, 2 Sep 2014 07:39:50 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> In-Reply-To: <54059AA9.4080902@bwijnen.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.21.96.91] Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/cufLYenE3Pw6nPRzI3yWcN4rvA0 Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:39:53 -0000 (d) On 9/2/14 3:23 AM, Bert Wijnen (IETF) wrote: > On 26/08/14 22:49, Andy Bierman wrote: >> >> Perhaps the co-chairs should decide how to proceed somehow. > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 2 07:46:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272D61A070F for ; Tue, 2 Sep 2014 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgDrIF6Tnr6m for ; Tue, 2 Sep 2014 07:46:25 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D34C1A6F8D for ; Tue, 2 Sep 2014 07:46:25 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id w7so6949423qcr.32 for ; Tue, 02 Sep 2014 07:46:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MFQ0x9klb9rzj5JDYtIZXlV75wfNH1hVwocdrG10hmA=; b=DKS9XJdefeprcJSZcKMr1nR4cfXp3j6D2FY3XMkBjIEM7CxlwPZSWYXo2oU/q0fqta UByqdlyHw7VSQzA/IzhPGwBRnulUoGwRY52bVkOY5ReAaFu0ELroqaUD5G9uGgBw43w3 4dAAECrO1W746NB0jVrZ2nAeqT8LZsaJS3Mxeevut9bRkqur7cBZciKaoT4WiKWV8SAZ Z9BlEEnH6xxpRkQO94R+wlRV38kemKo37JILZcHUdOrVJny1kSLPZuUMO1cnR26tlEMv aPfAC9NUPtmYBDsx03kBIg8OjxSQJbWY/VXvOKmsGGC/g3g4e74DelpQ4y+U1fcj3R8I Nwfg== X-Gm-Message-State: ALoCoQlz+808BhExDCPlUO3Q2aOMgXzuG1AToE53gGgs+bBwBTt4SQ+RLPVhieJvODvwjjkyZh9H MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr55638284qab.7.1409669184637; Tue, 02 Sep 2014 07:46:24 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 2 Sep 2014 07:46:24 -0700 (PDT) In-Reply-To: <54059AA9.4080902@bwijnen.net> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> Date: Tue, 2 Sep 2014 07:46:24 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=001a11c1c56000677a0502162f58 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Mns44HwrmiVnB3Viu9f5KQ3UckY Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 14:46:27 -0000 --001a11c1c56000677a0502162f58 Content-Type: text/plain; charset=ISO-8859-1 Hi, 1st choice: d 2nd choice: a Andy On Tue, Sep 2, 2014 at 3:23 AM, Bert Wijnen (IETF) wrote: > On 26/08/14 22:49, Andy Bierman wrote: > >> >> Perhaps the co-chairs should decide how to proceed somehow. >> > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c1c56000677a0502162f58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

1st choice: d
2nd choice:= a

Andy

=
On Tue, Sep 2, 2014 at 3:23 AM, Bert Wijnen (IETF) <bertietf@bwijnen.ne= t> wrote:
On 26/08/14 22:49, Andy Bierman wrote:

Perhaps the co-chairs should decide how to proceed somehow.

Dear NETCONF WG participants, do you have an opinion?

So far I have seen only a few people express their opinion.

Please speak up so that we (WG chairs) have better data to judge if we
do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014.
Please speak your mind about these options:

a) XML is mandatory
b) JSON is mandatory
c) XML and JSON are both mandatory
d) Both XML and JSON mandatory on client,
=A0 =A0server can implement whatever it chooses.
=A0 =A0Not clear yet how the client would find out, but that would of cours= e
=A0 =A0be something to be worked out if we choose this option

Bert

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

--001a11c1c56000677a0502162f58-- From nobody Tue Sep 2 09:08:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6041A0564 for ; Tue, 2 Sep 2014 09:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2diGCoohMPN for ; Tue, 2 Sep 2014 09:07:56 -0700 (PDT) Received: from p3plsmtpa06-07.prod.phx3.secureserver.net (p3plsmtpa06-07.prod.phx3.secureserver.net [173.201.192.108]) by ietfa.amsl.com (Postfix) with ESMTP id 07CDF1A0465 for ; Tue, 2 Sep 2014 09:07:55 -0700 (PDT) Received: from [192.168.2.10] ([50.179.41.78]) by p3plsmtpa06-07.prod.phx3.secureserver.net with id mG7t1o00f1hB5UJ01G7u3G; Tue, 02 Sep 2014 09:07:54 -0700 Message-ID: <5405EB52.5030609@seguesoft.com> Date: Tue, 02 Sep 2014 11:07:46 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: netconf@ietf.org References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> In-Reply-To: <54059AA9.4080902@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/jfAv6vQplh1sD_fcb1cd10EqyCs Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 16:07:57 -0000 I prefer a) , and then d). --Xiang On 9/2/2014 5:23 AM, Bert Wijnen (IETF) wrote: > On 26/08/14 22:49, Andy Bierman wrote: >> >> Perhaps the co-chairs should decide how to proceed somehow. > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- -- Xiang Li, Seguesoft, Champaign, IL (217) 721-5341 From nobody Tue Sep 2 09:57:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E56C1A046C for ; Tue, 2 Sep 2014 09:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAwIAC9RkxbH for ; Tue, 2 Sep 2014 09:57:44 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0721A031A for ; Tue, 2 Sep 2014 09:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1011; q=dns/txt; s=iport; t=1409677060; x=1410886660; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=/erLpsrx01a3lVCYlK9HckGCNrP8uCID/XbzNGFR9fs=; b=XAPx4FVIKUrWqtTwpcmEZl/YGKqdIAj3nH6vfD3nrk+OWXr6FbZvnESC 8XoBj8eNwFIzUY0O2yAOrCml1JIhVJ1vT5+7ExpoDAE16Sd1o1fTif98B g/hKGBYCvxESubfIkOBkIQoyrs1mmcvRmFBPSXRMJGtCmP9JEiTUTyyT8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAKz2BVStJA2D/2dsb2JhbABagw1TVwTIGAqGeVMBgRMWd4QEAQEEAQEBNzQdAQgYHjcLJQIEARKIQg27ewETBIwegzaETAWRMYsrjBWJCYIbgUZsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,450,1406592000"; d="scan'208";a="74285711" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 02 Sep 2014 16:57:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s82GvIBb016002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 16:57:18 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 11:57:18 -0500 From: "Lisa Huang (yihuan)" To: "Bert Wijnen (IETF)" , Netconf Thread-Topic: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity Thread-Index: AQHPxpf/LQXBjg0WwEGPp9st0ZpIr5vt7z0A Date: Tue, 2 Sep 2014 16:57:17 +0000 Message-ID: In-Reply-To: <54059AA9.4080902@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.83.176] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zvxtZ2nvxfuOGFY2klLuMHD7ZK4 Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 16:57:46 -0000 I prefer (d), but am OK with (a) On 9/2/14 3:23 AM, "Bert Wijnen (IETF)" wrote: >On 26/08/14 22:49, Andy Bierman wrote: >> >> Perhaps the co-chairs should decide how to proceed somehow. > >Dear NETCONF WG participants, do you have an opinion? > >So far I have seen only a few people express their opinion. > >Please speak up so that we (WG chairs) have better data to judge if we >do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > >Please speak your mind about these options: > >a) XML is mandatory >b) JSON is mandatory >c) XML and JSON are both mandatory >d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > >Bert > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 2 10:00:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00711A031A for ; Tue, 2 Sep 2014 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC7TARKLlaKa for ; Tue, 2 Sep 2014 10:00:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149321A046C for ; Tue, 2 Sep 2014 10:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1197; q=dns/txt; s=iport; t=1409677238; x=1410886838; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fBQ5olizRbGb6xcFHkn6DDYmZ8H+V/QYABpXIfquX5I=; b=bftNHSgrlcgOI6VyZmf5yGIaf4JKxlUnu5W9TRDux8VcETcMzC1RS6Qy WE0zD/9nBZYdORnUC7XhgSgeYzv0wjcyf/PoBbmVzSIoSrF6g26xUflWO ovjTGefvn1fzU7xuQCCFocziADpx0sN70nOXtBSjyJZJDud4TIsn+7p5+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAKz2BVStJV2S/2dsb2JhbABagw1TVwTIGAqGeVMBgRMWd4QDAQEBBAEBATc0FwQCAQgRBAEBAQoUCQcnCxQJCAIEARIIiDoNu3sBEwSMHoJ+OAaDKYEdBZExl0CJCYIbgUZsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,450,1406592000"; d="scan'208";a="74286062" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 02 Sep 2014 17:00:37 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s82H0b2W030698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 17:00:37 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 12:00:37 -0500 From: "Alexander Clemm (alex)" To: "Bert Wijnen (IETF)" , Netconf Thread-Topic: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity Thread-Index: AQHPxpf/fV5PxP1NXE29xbG2jjCaoJvuEWww Date: Tue, 2 Sep 2014 17:00:36 +0000 Message-ID: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> In-Reply-To: <54059AA9.4080902@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.78.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/l8HcFPOmdCznZTH0bA3airk3NnE Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:00:40 -0000 Option (d) seems preferable to me. --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (I= ETF) Sent: Tuesday, September 02, 2014 3:24 AM To: Netconf Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your opinio= n on RESTCONF modularity On 26/08/14 22:49, Andy Bierman wrote: > > Perhaps the co-chairs should decide how to proceed somehow. Dear NETCONF WG participants, do you have an opinion? So far I have seen only a few people express their opinion. Please speak up so that we (WG chairs) have better data to judge if we do o= r do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. Please speak your mind about these options: a) XML is mandatory b) JSON is mandatory c) XML and JSON are both mandatory d) Both XML and JSON mandatory on client, server can implement whatever it chooses. Not clear yet how the client would find out, but that would of course be something to be worked out if we choose this option Bert _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 2 10:58:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A671A03E1 for ; Tue, 2 Sep 2014 10:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-kxz8BzEw6r for ; Tue, 2 Sep 2014 10:58:30 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 08F651A039B for ; Tue, 2 Sep 2014 10:58:29 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA11.westchester.pa.mail.comcast.net with comcast id mBoF1o0021swQuc5BHyVLD; Tue, 02 Sep 2014 17:58:29 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta15.westchester.pa.mail.comcast.net with comcast id mHyU1o00W2yZEBF3bHyVu3; Tue, 02 Sep 2014 17:58:29 +0000 From: "ietfdbh" To: "'Bert Wijnen \(IETF\)'" , "'Netconf'" References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> In-Reply-To: <54059AA9.4080902@bwijnen.net> Date: Tue, 2 Sep 2014 13:58:28 -0400 Message-ID: <039f01cfc6d7$809a7c30$81cf7490$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJNBF+dKU8S8HVgbLsBnJzxTDtdxQGMjoPBAgnrnXwBo9w/cALHHffsAepRd1CapDyGEA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409680709; bh=Txs8IjbbX+TIAqQN3U5tZHqQXhm8PLnsv9I1MwHznm8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=vndd9YEvj0NCEeDgU2kM2mi6Jj5vjeRuhu0JTxFZTTap14/BiVv7Y6pORumBtHBxq 4iQ9P9ikakajeon6Qe3juzVHtQ24BkDqWUn6TKSvDSBFf1wOp9N2WoA4vVraIhjYPy DNsXswsmGmF1ufEiXdsQk10ssHZJhqFdRxNGSojr91n4tZ/MajHb0nvdZf0TJ4m4gc y6fpQV8QgVpqDAyVe9sYZAtHQ0n//Tx4Ft5jKSk3ffaEReBdufgUqDzOrgbkoYrcEJ S15IyIMJM8NXjUt0n1MvoeXEvQnyromhhZYpJnDU9RPGWqBefXy7RCkjPTnKlx2XHF BwxY/Fi1sQwGw== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/I0AbSYy6LJc7GviSu2HxJjBRArk Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:58:32 -0000 I prefer a) - the idea is to standardize for interoperability, and XML is already the standard for netconf. b) changes the whole Netconf direction, and might justify having restconf+json be a separate WG from Netconf, subject to IETSG/IETF approval of yet another protocol for the same purpose. c) is too heavy weight for servers. d) creates complexity, and a potential for non-interoperability. I have a question about d), motivated by my background in NMS development. What are the potential problems for the NMS of having to collect the information model using different data models, to manage a heterogeneous network? The data models are obviously different; are the Information Models guaranteed to be exactly the same? If a client talks to two implementations of the same information model, one server supports XML and the other supports JSON, and the client compares the configurations and operational state; all else being equal, will the two variations report exactly the same information (in all cases), and support configuration using the same IM knobs (in all cases), or will these actually be two slightly different information models? You could also ask this question for one server supporting both XML and JSON; if the client accesses the data using XML and also using JSON, will the data be exactly the same information model, or will there be differences due to data modeling constraints? (We already face this with the MIB/YANG modeling variations; do we need more close-but-not-quite-the-same information models?) Can a client talking to two implementations, one that supports XML and another that supports JSON, use information validation, such as ranges and datatypes, that would be identical across the two interfaces? I am thinking of an NMS that collects data using these interfaces; it validates the XML or JSON formatting/structure, then puts the values into a database, where it then uses data-model-independent code to perform validation of the information model, independent of the format used to transport the data, (OR it imports one or the other data model to perform validation of **information value/range/datatype/etc.** based on having imported, say, the XML version of the information model). David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen > (IETF) > Sent: Tuesday, September 02, 2014 6:24 AM > To: Netconf > Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion > on RESTCONF modularity > > On 26/08/14 22:49, Andy Bierman wrote: > > > > Perhaps the co-chairs should decide how to proceed somehow. > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 2 13:19:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5DA1A88B2 for ; Tue, 2 Sep 2014 13:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yaKL5vS1D9Z for ; Tue, 2 Sep 2014 13:19:10 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DF61A88C3 for ; Tue, 2 Sep 2014 13:19:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 78F961439; Tue, 2 Sep 2014 22:19:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7Dk4pwhC3Bku; Tue, 2 Sep 2014 22:18:58 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 2 Sep 2014 22:19:07 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6673120035; Tue, 2 Sep 2014 22:19:07 +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 L1wcwNjcTxnX; Tue, 2 Sep 2014 22:19: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 6470920033; Tue, 2 Sep 2014 22:19:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9B2B82E579EB; Tue, 2 Sep 2014 22:19:04 +0200 (CEST) Date: Tue, 2 Sep 2014 22:19:04 +0200 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20140902201904.GB78273@elstar.local> Mail-Followup-To: ietfdbh , "'Bert Wijnen (IETF)'" , 'Netconf' References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <039f01cfc6d7$809a7c30$81cf7490$@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039f01cfc6d7$809a7c30$81cf7490$@comcast.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/70eKUEJDQWu7DmDQPe4f5PP8kLw Cc: 'Netconf' Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:19:14 -0000 David, I am not sure you understand the details of the technical background. The YANG data model is the same in both encodings. There might be technical issues because of the way the JSON mapping is defined right now but hopefully the next revision will have those fixed. Since the data model is the same, the information model is going to be the same as well. I do not understand your concerns. /js On Tue, Sep 02, 2014 at 01:58:28PM -0400, ietfdbh wrote: > I prefer a) - the idea is to standardize for interoperability, and XML is > already the standard for netconf. > b) changes the whole Netconf direction, and might justify having > restconf+json be a separate WG from Netconf, subject to IETSG/IETF approval > of yet another protocol for the same purpose. > c) is too heavy weight for servers. > d) creates complexity, and a potential for non-interoperability. > > I have a question about d), motivated by my background in NMS development. > What are the potential problems for the NMS of having to collect the > information model using different data models, to manage a heterogeneous > network? > The data models are obviously different; are the Information Models > guaranteed to be exactly the same? > If a client talks to two implementations of the same information model, one > server supports XML and the other supports JSON, and the client compares the > configurations and operational state; all else being equal, will the two > variations report exactly the same information (in all cases), and support > configuration using the same IM knobs (in all cases), or will these actually > be two slightly different information models? > You could also ask this question for one server supporting both XML and > JSON; if the client accesses the data using XML and also using JSON, will > the data be exactly the same information model, or will there be differences > due to data modeling constraints? (We already face this with the MIB/YANG > modeling variations; do we need more close-but-not-quite-the-same > information models?) > Can a client talking to two implementations, one that supports XML and > another that supports JSON, use information validation, such as ranges and > datatypes, that would be identical across the two interfaces? I am thinking > of an NMS that collects data using these interfaces; it validates the XML or > JSON formatting/structure, then puts the values into a database, where it > then uses data-model-independent code to perform validation of the > information model, independent of the format used to transport the data, (OR > it imports one or the other data model to perform validation of > **information value/range/datatype/etc.** based on having imported, say, the > XML version of the information model). > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen > > (IETF) > > Sent: Tuesday, September 02, 2014 6:24 AM > > To: Netconf > > Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your > opinion > > on RESTCONF modularity > > > > On 26/08/14 22:49, Andy Bierman wrote: > > > > > > Perhaps the co-chairs should decide how to proceed somehow. > > > > Dear NETCONF WG participants, do you have an opinion? > > > > So far I have seen only a few people express their opinion. > > > > Please speak up so that we (WG chairs) have better data to judge if we > > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > > > Please speak your mind about these options: > > > > a) XML is mandatory > > b) JSON is mandatory > > c) XML and JSON are both mandatory > > d) Both XML and JSON mandatory on client, > > server can implement whatever it chooses. > > Not clear yet how the client would find out, but that would of course > > be something to be worked out if we choose this option > > > > Bert > > > > _______________________________________________ > > 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Sep 2 13:24:09 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376221A06A3 for ; Tue, 2 Sep 2014 13:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ-a6_MtUFVI for ; Tue, 2 Sep 2014 13:24:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9851A0694 for ; Tue, 2 Sep 2014 13:24:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A5004143D; Tue, 2 Sep 2014 22:24:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mOksjyCQ1Hbh; Tue, 2 Sep 2014 22:23:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 2 Sep 2014 22:24:02 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAA1620036; Tue, 2 Sep 2014 22:24:02 +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 aaccb5bNaaKK; Tue, 2 Sep 2014 22:24:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8478720033; Tue, 2 Sep 2014 22:24:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 70AEB2E57A25; Tue, 2 Sep 2014 22:24:01 +0200 (CEST) Date: Tue, 2 Sep 2014 22:24:01 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20140902202401.GC78273@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54059AA9.4080902@bwijnen.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iNPe1SvENuV3h6J_YoMl517Q-SQ Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:24:09 -0000 On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > I have neither implemented a server nor a client. That said, I think I prefer a) because having less options improves interoperability (I am old school on this). I also note that the JSON encoding is not final yet and depending on how some of the details are resolved, I may be OK with d) or not. The question is how much complexity is added to a client for supporting both XML and JSON. If the JSON mappings requires that all clients are able to dynamically parse and interpret YANG models, I am going to be strictly against d). Sorry for a complicated answer. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Sep 2 13:59:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9351A06C1 for ; Tue, 2 Sep 2014 13:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgGkCj0TQPWf for ; Tue, 2 Sep 2014 13:59:54 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DAC1A06CE for ; Tue, 2 Sep 2014 13:59:54 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id i17so7639902qcy.12 for ; Tue, 02 Sep 2014 13:59:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=clGFe60r/4hTL6TOqLnnFEkN7r6Ve0AmrCFQSPOXSpw=; b=RdWf/Ix2u4ZzhJsIR+/4WOGR4kbAXpffYZo8RjIXU+NlPcVA4Ji0mivRLQSBD0qCXB 4xVcfAozJWIiGgxjiDk1S9m8u9CeuEzBmX0hRMyasqgatVOLKjSgfciedIWnqEOXSv5G 0IW7IZmhQ3P8kWKbDWxbEO4CZE/1cAsslw7SD0u1VWCFZC9+lMZLKpG8NX5IjTavKNPQ Aqggd9lm2tHAPz3dvqAgcqBrLf/Fj4fI+Tcx9StitH5VQxXn9N+fKDAEbGAkXFgwkgr6 LWeCCwvFm65wKjtJXJlFkD5icAiEuMZDX7ORTASDoIuAX7p/zekC2u2JXH4hTqr3xtUs ODKw== X-Gm-Message-State: ALoCoQl4ekd3inSS/jZh6Fx+rcC9GWbQNVSifqlENB/PJlQ156/CvI6oBh4ohAsbOklBqP9JjTfm MIME-Version: 1.0 X-Received: by 10.229.231.68 with SMTP id jp4mr59603989qcb.4.1409691593381; Tue, 02 Sep 2014 13:59:53 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 2 Sep 2014 13:59:53 -0700 (PDT) In-Reply-To: <20140902202401.GC78273@elstar.local> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> Date: Tue, 2 Sep 2014 13:59:53 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Bert Wijnen (IETF)" , Netconf Content-Type: multipart/alternative; boundary=001a1134497aaaadc105021b6648 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/SWInbUZUTCGvz2Z4_87-472OzsE Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:59:56 -0000 --001a1134497aaaadc105021b6648 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: > > > > Please speak your mind about these options: > > > > a) XML is mandatory > > b) JSON is mandatory > > c) XML and JSON are both mandatory > > d) Both XML and JSON mandatory on client, > > server can implement whatever it chooses. > > Not clear yet how the client would find out, but that would of course > > be something to be worked out if we choose this option > > > > I have neither implemented a server nor a client. That said, I think I > prefer a) because having less options improves interoperability (I am > old school on this). I also note that the JSON encoding is not final > yet and depending on how some of the details are resolved, I may be OK > with d) or not. The question is how much complexity is added to a > client for supporting both XML and JSON. If the JSON mappings requires > that all clients are able to dynamically parse and interpret YANG > models, I am going to be strictly against d). > > I do not understand your last sentence. We expect a compliant server to implement the entry points and monitoring data defined in the draft. The client MUST understand at least the static API data, such as /restconf/modules. The client could also put its preferred encoding in the Accept header for a GET request and see if the server responds with 406 Not Acceptable. This does not require any YANG parsing. Sorry for a complicated answer. > > /js > > Andy > -- > 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 > --001a1134497aaaadc105021b6648 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 02, 2014 at 12:23:37PM +0200, Be= rt Wijnen (IETF) wrote:
>
> Please speak your mind about these options:
>
> a) XML is mandatory
> b) JSON is mandatory
> c) XML and JSON are both mandatory
> d) Both XML and JSON mandatory on client,
>=A0 =A0 server can implement whatever it chooses.
>=A0 =A0 Not clear yet how the client would find out, but that would of = course
>=A0 =A0 be something to be worked out if we choose this option
>

I have neither implemented a server nor a client. That said, I think I
prefer a) because having less options improves interoperability (I am
old school on this). I also note that the JSON encoding is not final
yet and depending on how some of the details are resolved, I may be OK
with d) or not. The question is how much complexity is added to a
client for supporting both XML and JSON. If the JSON mappings requires
that all clients are able to dynamically parse and interpret YANG
models, I am going to be strictly against d).


I do not understand your last sentence= .
We expect a compliant server to implement the entry points and = monitoring data
defined in the draft. =A0The client MUST understa= nd at least the static API data,
such as /restconf/modules. =A0The client could also put its preferred = encoding
in the Accept header for a GET request and see if the se= rver responds with 406 Not Acceptable.
This does not require any = YANG parsing.




Sorry for a complicated answer.

/js


Andy
=A0
=
--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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

--001a1134497aaaadc105021b6648-- From nobody Tue Sep 2 14:12:47 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E61A1A06C1 for ; Tue, 2 Sep 2014 14:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz95jDy_WuMo for ; Tue, 2 Sep 2014 14:12:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9900F1A06DD for ; Tue, 2 Sep 2014 14:12:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5CC4F1436; Tue, 2 Sep 2014 23:12:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sAzXsj2KPywB; Tue, 2 Sep 2014 23:12:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 2 Sep 2014 23:12:42 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F82B20033; Tue, 2 Sep 2014 23:12:42 +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 AaA6OH-mJ7JA; Tue, 2 Sep 2014 23:12:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18AA020035; Tue, 2 Sep 2014 23:12:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B6EBB2E57BE3; Tue, 2 Sep 2014 23:12:39 +0200 (CEST) Date: Tue, 2 Sep 2014 23:12:39 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140902211238.GA78502@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , Netconf References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HRBJ0PaikfbR57llJH0PHvbg7l8 Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 21:12:46 -0000 On Tue, Sep 02, 2014 at 01:59:53PM -0700, Andy Bierman wrote: > On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: > > > > > > Please speak your mind about these options: > > > > > > a) XML is mandatory > > > b) JSON is mandatory > > > c) XML and JSON are both mandatory > > > d) Both XML and JSON mandatory on client, > > > server can implement whatever it chooses. > > > Not clear yet how the client would find out, but that would of course > > > be something to be worked out if we choose this option > > > > > > > I have neither implemented a server nor a client. That said, I think I > > prefer a) because having less options improves interoperability (I am > > old school on this). I also note that the JSON encoding is not final > > yet and depending on how some of the details are resolved, I may be OK > > with d) or not. The question is how much complexity is added to a > > client for supporting both XML and JSON. If the JSON mappings requires > > that all clients are able to dynamically parse and interpret YANG > > models, I am going to be strictly against d). > > > > > I do not understand your last sentence. We expect a compliant > server to implement the entry points and monitoring data defined in > the draft. The client MUST understand at least the static API data, > such as /restconf/modules. The client could also put its preferred > encoding in the Accept header for a GET request and see if the > server responds with 406 Not Acceptable. This does not require any > YANG parsing. Option d) says that client has to be able to try both JSON and XML. This means the client must be able to 'transform' the two encoding into a common internal representation. If, for example, one encoding uses URIs to identify namespaces while the other encoding uses module names or one encoding requires type information to be available while the other does not, then I _expect_ this adds significant complexity. The current JSON I-D (as far as I understand it) does not allow a simple 'stateless' (means data model agnostic) transformation between the two encodings. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Sep 2 14:31:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E581A06ED for ; Tue, 2 Sep 2014 14:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFsDduz_pg4f for ; Tue, 2 Sep 2014 14:31:12 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8B61A0701 for ; Tue, 2 Sep 2014 14:31:11 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id r5so7844702qcx.29 for ; Tue, 02 Sep 2014 14:31:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jK6Rba4GJ9r+2fzleL0g5PwxVFCjDfdyBg9H3nQtaiQ=; b=WXJ5UDvQIxh2s4ZV0DyEpsOJsVjYNGtsWKcu7Ms7Sw6SANAI1Km+BLyHaR7W9BJ5n/ 6xmeWnO8qKRdATDSpgcan/hoqhmZRG4agzXLSl5ZPF77tRpp1Occj8yi2hFDWSOVUbfh 0f9RjOMdylieUvy6V0XaUCxIevY01pZ6cNzNpbvjIykGFtDUW86p1JHBPfT7pPd4E0dc ZdxQmA1nl3esvDbfY+k4gUK90gLRBbqjhj3FpqII/5a1/5sXnkJNYrMlevkfBo7W4x3V Z2wKZ2WE3f9oKCRcp+B7ROs8FopZBBxCscx+247ak78pU7gbFGsYTphpihd+AOua+MLv mq2Q== X-Gm-Message-State: ALoCoQkr+bHtCU6uFvXdx6ZFzozKoiuaDubIoinEQtmz1plHN6cIdltQeSJ7t9T13BWGinOdNq18 MIME-Version: 1.0 X-Received: by 10.140.98.147 with SMTP id o19mr43969535qge.21.1409693470642; Tue, 02 Sep 2014 14:31:10 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 2 Sep 2014 14:31:10 -0700 (PDT) In-Reply-To: <20140902211238.GA78502@elstar.local> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> Date: Tue, 2 Sep 2014 14:31:10 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Bert Wijnen (IETF)" , Netconf Content-Type: multipart/alternative; boundary=001a113a923c8f9f2505021bd6c0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XMkSYSMzA6_LU-f2Lm4eDc_Chp4 Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 21:31:14 -0000 --001a113a923c8f9f2505021bd6c0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 2, 2014 at 2:12 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Sep 02, 2014 at 01:59:53PM -0700, Andy Bierman wrote: > > On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: > > > > > > > > Please speak your mind about these options: > > > > > > > > a) XML is mandatory > > > > b) JSON is mandatory > > > > c) XML and JSON are both mandatory > > > > d) Both XML and JSON mandatory on client, > > > > server can implement whatever it chooses. > > > > Not clear yet how the client would find out, but that would of > course > > > > be something to be worked out if we choose this option > > > > > > > > > > I have neither implemented a server nor a client. That said, I think I > > > prefer a) because having less options improves interoperability (I am > > > old school on this). I also note that the JSON encoding is not final > > > yet and depending on how some of the details are resolved, I may be OK > > > with d) or not. The question is how much complexity is added to a > > > client for supporting both XML and JSON. If the JSON mappings requires > > > that all clients are able to dynamically parse and interpret YANG > > > models, I am going to be strictly against d). > > > > > > > > I do not understand your last sentence. We expect a compliant > > server to implement the entry points and monitoring data defined in > > the draft. The client MUST understand at least the static API data, > > such as /restconf/modules. The client could also put its preferred > > encoding in the Accept header for a GET request and see if the > > server responds with 406 Not Acceptable. This does not require any > > YANG parsing. > > Option d) says that client has to be able to try both JSON and > XML. This means the client must be able to 'transform' the two > encoding into a common internal representation. If, for example, one > encoding uses URIs to identify namespaces while the other encoding > uses module names or one encoding requires type information to be > available while the other does not, then I _expect_ this adds > significant complexity. The current JSON I-D (as far as I understand > it) does not allow a simple 'stateless' (means data model agnostic) > transformation between the two encodings. > > But using the reply message from the server is an implementation detail no matter what encoding is used. An XML or JSON document in RESTCONF is a serialized encoding of some data structures. If the client wants the data to be hierarchical, then it has to be converted to something else. There are issues with the JSON draft that need to be addressed, but that is a different topic. IMO it is OK to restrict RESTCONF XML to the same printable characters as JSON. That's what NETCONF does wrt/ mixed mode XML. (No rewrite to XML needed). /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a113a923c8f9f2505021bd6c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 2, 2014 at 2:12 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 02, 2014 at 01:59:53PM -0700, An= dy Bierman wrote:
> On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrot= e:
> > >
> > > Please speak your mind about these options:
> > >
> > > a) XML is mandatory
> > > b) JSON is mandatory
> > > c) XML and JSON are both mandatory
> > > d) Both XML and JSON mandatory on client,
> > >=A0 =A0 server can implement whatever it chooses.
> > >=A0 =A0 Not clear yet how the client would find out, but that= would of course
> > >=A0 =A0 be something to be worked out if we choose this optio= n
> > >
> >
> > I have neither implemented a server nor a client. That said, I th= ink I
> > prefer a) because having less options improves interoperability (= I am
> > old school on this). I also note that the JSON encoding is not fi= nal
> > yet and depending on how some of the details are resolved, I may = be OK
> > with d) or not. The question is how much complexity is added to a=
> > client for supporting both XML and JSON. If the JSON mappings req= uires
> > that all clients are able to dynamically parse and interpret YANG=
> > models, I am going to be strictly against d).
> >
> >
> I do not understand your last sentence.=A0 We expect a compliant
> server to implement the entry points and monitoring data defined in > the draft.=A0 The client MUST understand at least the static API data,=
> such as /restconf/modules.=A0 The client could also put its preferred<= br> > encoding in the Accept header for a GET request and see if the
> server responds with 406 Not Acceptable.=A0 This does not require any<= br> > YANG parsing.

Option d) says that client has to be able to try both JSON and
XML. This means the client must be able to 'transform' the two
encoding into a common internal representation. If, for example, one
encoding uses URIs to identify namespaces while the other encoding
uses module names or one encoding requires type information to be
available while the other does not, then I _expect_ this adds
significant complexity. The current JSON I-D (as far as I understand
it) does not allow a simple 'stateless' (means data model agnostic)=
transformation between the two encodings.


But using the reply message from the server is an im= plementation detail
no matter what encoding is used. =A0An XML or= JSON document in RESTCONF is a serialized
encoding of some data structures. =A0If the client wants the data to b= e hierarchical,
then it has to be converted to something else.

There are issues with the JSON draft that need to be= addressed, but that is a different topic.
IMO it is OK to restrict RESTCONF XML to the same printable characters= as JSON.
That's what NETCONF does wrt/ mixed mode XML. (No r= ewrite to XML needed).


/js

Andy
=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a113a923c8f9f2505021bd6c0-- From nobody Tue Sep 2 15:11:47 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121281A0894 for ; Tue, 2 Sep 2014 15:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7hDTJLLl6cQ for ; Tue, 2 Sep 2014 15:11:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F6C1A086B for ; Tue, 2 Sep 2014 15:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12011; q=dns/txt; s=iport; t=1409695902; x=1410905502; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=EkKvvFXUB+sHSCz1FtPkDT095VsiTJTaW7AN+pNEBSA=; b=gMNXJDhK1s2jPvAUBO21nmCSP9iflistJIad0cAT5dPDJoRvGSZFd6yv QMNI2OFnpwqFdsB4hOk2L5Os3l01gEuJ2+d5GeB5nCf/iVGxFOFY3Q9wb KbqUnzgvrelvTDkglJ6DJT06tQJkrUEs0CIUCw8wFMoZg/Z1yvzpS4ryq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkGABVABlStJV2Q/2dsb2JhbABQBwODDVNXBIhTv0cBCYZ5UwGBExZ3hAQBAQQBAQFrGQILEAgJHgcPAgoMHxEGDQYCAQGIPg29DQEXBIwaglNMFxGCJ1OBQQWLLJEwhzeEXokJghuBZkyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,452,1406592000"; d="scan'208,217";a="348967174" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP; 02 Sep 2014 22:11:40 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s82MBeec032002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Sep 2014 22:11:40 GMT Received: from [10.21.123.100] (10.21.123.100) by xhc-rcd-x11.cisco.com (173.37.183.85) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Sep 2014 17:11:40 -0500 Message-ID: <5406409B.70903@cisco.com> Date: Tue, 2 Sep 2014 15:11:39 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090107070600040101050406" X-Originating-IP: [10.21.123.100] Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3trUBTTFqbpXgltdVQUfRznVSlc Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 22:11:45 -0000 --------------090107070600040101050406 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Agreed. I've coded a client and do not use the data from the server "as is". Internally I use other data structures and therefore transform the data into something else. On 9/2/14 2:31 PM, Andy Bierman wrote: > > > > On Tue, Sep 2, 2014 at 2:12 PM, Juergen Schoenwaelder > > wrote: > > On Tue, Sep 02, 2014 at 01:59:53PM -0700, Andy Bierman wrote: > > On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de > > wrote: > > > > > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) > wrote: > > > > > > > > Please speak your mind about these options: > > > > > > > > a) XML is mandatory > > > > b) JSON is mandatory > > > > c) XML and JSON are both mandatory > > > > d) Both XML and JSON mandatory on client, > > > > server can implement whatever it chooses. > > > > Not clear yet how the client would find out, but that > would of course > > > > be something to be worked out if we choose this option > > > > > > > > > > I have neither implemented a server nor a client. That said, I > think I > > > prefer a) because having less options improves > interoperability (I am > > > old school on this). I also note that the JSON encoding is not > final > > > yet and depending on how some of the details are resolved, I > may be OK > > > with d) or not. The question is how much complexity is added to a > > > client for supporting both XML and JSON. If the JSON mappings > requires > > > that all clients are able to dynamically parse and interpret YANG > > > models, I am going to be strictly against d). > > > > > > > > I do not understand your last sentence. We expect a compliant > > server to implement the entry points and monitoring data defined in > > the draft. The client MUST understand at least the static API data, > > such as /restconf/modules. The client could also put its preferred > > encoding in the Accept header for a GET request and see if the > > server responds with 406 Not Acceptable. This does not require any > > YANG parsing. > > Option d) says that client has to be able to try both JSON and > XML. This means the client must be able to 'transform' the two > encoding into a common internal representation. If, for example, one > encoding uses URIs to identify namespaces while the other encoding > uses module names or one encoding requires type information to be > available while the other does not, then I _expect_ this adds > significant complexity. The current JSON I-D (as far as I understand > it) does not allow a simple 'stateless' (means data model agnostic) > transformation between the two encodings. > > > But using the reply message from the server is an implementation detail > no matter what encoding is used. An XML or JSON document in RESTCONF > is a serialized > encoding of some data structures. If the client wants the data to be > hierarchical, > then it has to be converted to something else. > > There are issues with the JSON draft that need to be addressed, but > that is a different topic. > IMO it is OK to restrict RESTCONF XML to the same printable characters > as JSON. > That's what NETCONF does wrt/ mixed mode XML. (No rewrite to XML needed). > > > /js > > > Andy > > > -- > 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 --------------090107070600040101050406 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Agreed. I've coded a client and do not use the data from the server "as is". Internally I use other data structures and therefore transform the data into something else.


On 9/2/14 2:31 PM, Andy Bierman wrote:



On Tue, Sep 2, 2014 at 2:12 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 02, 2014 at 01:59:53PM -0700, Andy Bierman wrote:
> On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
> > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote:
> > >
> > > Please speak your mind about these options:
> > >
> > > a) XML is mandatory
> > > b) JSON is mandatory
> > > c) XML and JSON are both mandatory
> > > d) Both XML and JSON mandatory on client,
> > >    server can implement whatever it chooses.
> > >    Not clear yet how the client would find out, but that would of course
> > >    be something to be worked out if we choose this option
> > >
> >
> > I have neither implemented a server nor a client. That said, I think I
> > prefer a) because having less options improves interoperability (I am
> > old school on this). I also note that the JSON encoding is not final
> > yet and depending on how some of the details are resolved, I may be OK
> > with d) or not. The question is how much complexity is added to a
> > client for supporting both XML and JSON. If the JSON mappings requires
> > that all clients are able to dynamically parse and interpret YANG
> > models, I am going to be strictly against d).
> >
> >
> I do not understand your last sentence.  We expect a compliant
> server to implement the entry points and monitoring data defined in
> the draft.  The client MUST understand at least the static API data,
> such as /restconf/modules.  The client could also put its preferred
> encoding in the Accept header for a GET request and see if the
> server responds with 406 Not Acceptable.  This does not require any
> YANG parsing.

Option d) says that client has to be able to try both JSON and
XML. This means the client must be able to 'transform' the two
encoding into a common internal representation. If, for example, one
encoding uses URIs to identify namespaces while the other encoding
uses module names or one encoding requires type information to be
available while the other does not, then I _expect_ this adds
significant complexity. The current JSON I-D (as far as I understand
it) does not allow a simple 'stateless' (means data model agnostic)
transformation between the two encodings.


But using the reply message from the server is an implementation detail
no matter what encoding is used.  An XML or JSON document in RESTCONF is a serialized
encoding of some data structures.  If the client wants the data to be hierarchical,
then it has to be converted to something else.

There are issues with the JSON draft that need to be addressed, but that is a different topic.
IMO it is OK to restrict RESTCONF XML to the same printable characters as JSON.
That's what NETCONF does wrt/ mixed mode XML. (No rewrite to XML needed).


/js

Andy
 

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>



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

--------------090107070600040101050406-- From nobody Tue Sep 2 20:11:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C721A89A6 for ; Tue, 2 Sep 2014 20:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POV_cBVkK9fz for ; Tue, 2 Sep 2014 20:11:03 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF661A6F83 for ; Tue, 2 Sep 2014 20:11:03 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id z60so7761881qgd.11 for ; Tue, 02 Sep 2014 20:11:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nQM++tAnkc22CvDCfmPbuEmaUaweJS5YTZNrS9ZQ1yU=; b=Sez85uOLZyOscWrB3HblcHpX9cmlbkfUThfN8RLG5p7vttIS5qgg5NO96+Er0H6isR 2YpDqZKkXiZ4rT3sQnve4zBCUEN8toHwNUwomjmv7Fv30P5UH/yW4+9d+6sZKOGU2weE 5Y/uuhgKjL0nqyoSLvMA8HOmB42V2sg+fag7cxk+1kwz4AndlDERSLlYoZFZVn9BNe/n eca+/3vSROnqiC2w2vp4JYcPKoafETKDmJROMUUIMVYvwQGokUIFb3yVcqXGQOjwdYnO L0Lmmu/VoEL+rKt4BEgOKePtVPyFe/r4BFa4yuVe9jibZwXENMgktc3VVNGdJBpI5Kt5 jSXQ== X-Gm-Message-State: ALoCoQmAQC6yklCD3teIM3MrfYx1V9JrbixXvqTFNgKvTBRsz0b0K/bjHS8c/u6gOMEt/uIH+8Cy MIME-Version: 1.0 X-Received: by 10.140.98.7 with SMTP id n7mr58936979qge.83.1409713862665; Tue, 02 Sep 2014 20:11:02 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 2 Sep 2014 20:11:02 -0700 (PDT) In-Reply-To: <54059AA9.4080902@bwijnen.net> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> Date: Tue, 2 Sep 2014 20:11:02 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=001a113ac3c60543ac05022096f2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ZBDcl-lXsH5IVBLRW2MjFYbh2_M Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 03:11:05 -0000 --001a113ac3c60543ac05022096f2 Content-Type: text/plain; charset=ISO-8859-1 Hi, I added the issue in the issue tracker. We do not plan to use the tracker for discussion. It will capture significant events for each issue. The WG will be added as an email recipient soon so manual notices like this one will not be needed. https://github.com/netconf-wg/restconf/issues/7 Andy On Tue, Sep 2, 2014 at 3:23 AM, Bert Wijnen (IETF) wrote: > On 26/08/14 22:49, Andy Bierman wrote: > >> >> Perhaps the co-chairs should decide how to proceed somehow. >> > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113ac3c60543ac05022096f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I added the issue in the issue trac= ker.
We do not plan to use the tracker for discussion.
= It will capture significant events for each issue.
The WG will be= added as an email recipient soon so manual notices
like this one will not be needed.



Andy<= /div>



On Tue, Sep 2, 2014 at 3:23 AM, Bert Wijnen (IETF) <bertietf@bw= ijnen.net> wrote:
On 26/08/14 22:49, Andy Bierman wrote:

Perhaps the co-chairs should decide how to proceed somehow.

Dear NETCONF WG participants, do you have an opinion?

So far I have seen only a few people express their opinion.

Please speak up so that we (WG chairs) have better data to judge if we
do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014.
Please speak your mind about these options:

a) XML is mandatory
b) JSON is mandatory
c) XML and JSON are both mandatory
d) Both XML and JSON mandatory on client,
=A0 =A0server can implement whatever it chooses.
=A0 =A0Not clear yet how the client would find out, but that would of cours= e
=A0 =A0be something to be worked out if we choose this option

Bert

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

--001a113ac3c60543ac05022096f2-- From nobody Tue Sep 2 22:11:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62ABB1A8A16 for ; Tue, 2 Sep 2014 22:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NOU5HPYzGBs for ; Tue, 2 Sep 2014 22:11:07 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912801A6FDE for ; Tue, 2 Sep 2014 22:11:07 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so7852985qga.3 for ; Tue, 02 Sep 2014 22:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=BDYaK9/cJKnbofmPbPW/I0NOv7K54fZCwO4KEBpdnPs=; b=gIxIUJKz4Qczigpe7PoTsm+x95grCXK4abBah4tCHyx6NQzYvnQCL+7NCKg4L0rPwJ gyuP61VNFzm3/yV1rdObB5QObMzQSVl9MxEwuQN01Mxzs6lvz4N3QVmuAwifVKQ3Gcrq E4pqVnCf1lp8bvYzlWnkjZIDWkXg6gua6E8YuPHNrvgkKHJy/D5/WVjXQ7MmXp64PABH f5tmlDqxv1XDH77gsU75xozF9lpI00tOqoFVyDimeBlmtMmxDXCfc5x5mgWZx7ZuWEcp FSk4LMpd4f2nsBOPOFxgnQe/I3N3p9DUhr3yC6afD/KDiMHeYm9V9kB2T/wdhNPE1bS5 MU0w== X-Received: by 10.224.38.10 with SMTP id z10mr63125560qad.52.1409721066774; Tue, 02 Sep 2014 22:11:06 -0700 (PDT) Received: from [192.168.1.108] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id l30sm7659581qgf.9.2014.09.02.22.11.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 22:11:06 -0700 (PDT) References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> Mime-Version: 1.0 (1.0) In-Reply-To: <54059AA9.4080902@bwijnen.net> Content-Type: multipart/alternative; boundary=Apple-Mail-F486596F-BF50-443C-9226-E0BA7CC89B47 Content-Transfer-Encoding: 7bit Message-Id: <2EB9ECB8-C70E-48E7-9F60-440EB29E84B2@gmail.com> X-Mailer: iPad Mail (11D257) From: Mahesh Jethanandani Date: Tue, 2 Sep 2014 22:11:06 -0700 To: "Bert Wijnen (IETF)" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sQyMEEg-tt93cKtlYiWIXGdclpw Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 05:11:11 -0000 --Apple-Mail-F486596F-BF50-443C-9226-E0BA7CC89B47 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Prefer a). Mahesh Jethanandani mjethanandani@gmail.com > On Sep 2, 2014, at 3:23 AM, "Bert Wijnen (IETF)" wr= ote: >=20 >> On 26/08/14 22:49, Andy Bierman wrote: >>=20 >> Perhaps the co-chairs should decide how to proceed somehow. >=20 > Dear NETCONF WG participants, do you have an opinion? >=20 > So far I have seen only a few people express their opinion. >=20 > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. >=20 > Please speak your mind about these options: >=20 > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option >=20 > Bert >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail-F486596F-BF50-443C-9226-E0BA7CC89B47 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Prefer a).

Mahesh Jethanandani

On Sep 2, 2014, at 3:23 AM, "B= ert Wijnen (IETF)" <bertietf@bwij= nen.net> wrote:

On 2= 6/08/14 22:49, Andy Bierman wrote:

Perhaps the co-chai= rs should decide how to proceed somehow.

Dear NETCONF WG participants, do you have an opinion?
<= span>
So far I have seen only a few people express their opi= nion.

Please speak up so that we (WG chairs= ) have better data to judge if we
do or do not have WG (roug= h) consensus. Pls do speak up by 18 Sept 2014.

Please speak your mind about these options:

<= span>a) XML is mandatory
b) JSON is mandatory
c) XML and JSON are both mandatory
d) Both XML and JSON ma= ndatory on client,
  server can implement whateve= r it chooses.
  Not clear yet how the client woul= d find out, but that would of course
  be somethi= ng to be worked out if we choose this option

Bert

____________________________________= ___________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/lis= tinfo/netconf
= --Apple-Mail-F486596F-BF50-443C-9226-E0BA7CC89B47-- From nobody Tue Sep 2 23:10:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBA61A6FF8 for ; Tue, 2 Sep 2014 23:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYWQyfDtEINb for ; Tue, 2 Sep 2014 23:10:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED591A6FEC for ; Tue, 2 Sep 2014 23:10:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 303541419; Wed, 3 Sep 2014 08:10:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KrvQPHt8cCit; Wed, 3 Sep 2014 08:10:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 08:10:19 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D051F20035; Wed, 3 Sep 2014 08:10:19 +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 9WePpZvPROXs; Wed, 3 Sep 2014 08:10:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6869320033; Wed, 3 Sep 2014 08:10:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2424A2E57FAC; Wed, 3 Sep 2014 08:10:16 +0200 (CEST) Date: Wed, 3 Sep 2014 08:10:16 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140903061014.GA79257@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , Netconf References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/i-AuFbRhJzJnS5eWrknRsmtjiCw Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 06:10:25 -0000 On Tue, Sep 02, 2014 at 02:31:10PM -0700, Andy Bierman wrote: > On Tue, Sep 2, 2014 at 2:12 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Sep 02, 2014 at 01:59:53PM -0700, Andy Bierman wrote: > > > On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: > > > > > > > > > > Please speak your mind about these options: > > > > > > > > > > a) XML is mandatory > > > > > b) JSON is mandatory > > > > > c) XML and JSON are both mandatory > > > > > d) Both XML and JSON mandatory on client, > > > > > server can implement whatever it chooses. > > > > > Not clear yet how the client would find out, but that would of > > course > > > > > be something to be worked out if we choose this option > > > > > > > > > > > > > I have neither implemented a server nor a client. That said, I think I > > > > prefer a) because having less options improves interoperability (I am > > > > old school on this). I also note that the JSON encoding is not final > > > > yet and depending on how some of the details are resolved, I may be OK > > > > with d) or not. The question is how much complexity is added to a > > > > client for supporting both XML and JSON. If the JSON mappings requires > > > > that all clients are able to dynamically parse and interpret YANG > > > > models, I am going to be strictly against d). > > > > > > > > > > > I do not understand your last sentence. We expect a compliant > > > server to implement the entry points and monitoring data defined in > > > the draft. The client MUST understand at least the static API data, > > > such as /restconf/modules. The client could also put its preferred > > > encoding in the Accept header for a GET request and see if the > > > server responds with 406 Not Acceptable. This does not require any > > > YANG parsing. > > > > Option d) says that client has to be able to try both JSON and > > XML. This means the client must be able to 'transform' the two > > encoding into a common internal representation. If, for example, one > > encoding uses URIs to identify namespaces while the other encoding > > uses module names or one encoding requires type information to be > > available while the other does not, then I _expect_ this adds > > significant complexity. The current JSON I-D (as far as I understand > > it) does not allow a simple 'stateless' (means data model agnostic) > > transformation between the two encodings. > > > > > But using the reply message from the server is an implementation > detail no matter what encoding is used. An XML or JSON document in > RESTCONF is a serialized encoding of some data structures. If the > client wants the data to be hierarchical, then it has to be > converted to something else. As of today, I can't translate XML encoding to JSON encoding and vice versa without having access to some information defined in YANG modules. I believe this raises the bar for certain implementations. If my client API (e.g. ncclient) exposes values as untyped strings (the way things are encoded in NETCONF, which uses XML) to higher layers, then adding support for JSON encoding adds complexity since now I need at least access to some type information and I need to be able to map different namespace identifiers (URIs and module names). Yes, this is an implementation detail but I would not want to add this complexity to something like ncclient. Anyway, I provided an answer plus a reasoning. There is no need to agree on it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 03:45:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331AB1A0267 for ; Wed, 3 Sep 2014 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNpD44oL6JuV for ; Wed, 3 Sep 2014 03:45:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD251A01CB for ; Wed, 3 Sep 2014 03:45:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BCEF9540764; Wed, 3 Sep 2014 12:45:18 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBwyzED4U5WB; Wed, 3 Sep 2014 12:45:13 +0200 (CEST) Received: from localhost (unknown [217.31.205.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B282A540336; Wed, 3 Sep 2014 12:45:12 +0200 (CEST) From: Ladislav Lhotka To: ietfdbh , "'Bert Wijnen \(IETF\)'" , 'Netconf' In-Reply-To: <039f01cfc6d7$809a7c30$81cf7490$@comcast.net> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <039f01cfc6d7$809a7c30$81cf7490$@comcast.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 03 Sep 2014 12:45:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/h7KUBt6ysl-BVnWeuLWmYsqru84 Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 10:45:23 -0000 Hi Dave, ietfdbh writes: > I prefer a) - the idea is to standardize for interoperability, and XML is > already the standard for netconf. > b) changes the whole Netconf direction, and might justify having > restconf+json be a separate WG from Netconf, subject to IETSG/IETF approval > of yet another protocol for the same purpose. > c) is too heavy weight for servers. > d) creates complexity, and a potential for non-interoperability. > > I have a question about d), motivated by my background in NMS development. > What are the potential problems for the NMS of having to collect the > information model using different data models, to manage a heterogeneous > network? > The data models are obviously different; are the Information Models > guaranteed to be exactly the same? I am not sure it is correct to talk about different data models if the difference is only in encoding. The data model, expressed in YANG, is the same. > If a client talks to two implementations of the same information model, one > server supports XML and the other supports JSON, and the client compares the > configurations and operational state; all else being equal, will the two > variations report exactly the same information (in all cases), and support > configuration using the same IM knobs (in all cases), or will these actually > be two slightly different information models? The ietf-netmod-yang-json draft tries hard to make sure it is the case. And it should be, except a few corner cases, such as ambiguous unions, that are currently being discussed in the NETMOD mailing list. > You could also ask this question for one server supporting both XML and > JSON; if the client accesses the data using XML and also using JSON, will > the data be exactly the same information model, or will there be differences > due to data modeling constraints? (We already face this with the MIB/YANG > modeling variations; do we need more close-but-not-quite-the-same > information models?) > Can a client talking to two implementations, one that supports XML and > another that supports JSON, use information validation, such as ranges and > datatypes, that would be identical across the two interfaces? I am thinking > of an NMS that collects data using these interfaces; it validates the XML or > JSON formatting/structure, then puts the values into a database, where it > then uses data-model-independent code to perform validation of the > information model, independent of the format used to transport the data, (OR > it imports one or the other data model to perform validation of > **information value/range/datatype/etc.** based on having imported, say, the > XML version of the information model). Currently the only validation I can do is using DSDL schemas. For JSON encoding, I first translate JSON to XML using pyang's jtox plugin and then perform the validation. I have tried it with a number of data models and example instance documents, and it seems to work fine. Lada > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >> -----Original Message----- >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen >> (IETF) >> Sent: Tuesday, September 02, 2014 6:24 AM >> To: Netconf >> Subject: [Netconf] WG Last Call (expires Sept 18 2014): express your > opinion >> on RESTCONF modularity >> >> On 26/08/14 22:49, Andy Bierman wrote: >> > >> > Perhaps the co-chairs should decide how to proceed somehow. >> >> Dear NETCONF WG participants, do you have an opinion? >> >> So far I have seen only a few people express their opinion. >> >> Please speak up so that we (WG chairs) have better data to judge if we >> do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. >> >> Please speak your mind about these options: >> >> a) XML is mandatory >> b) JSON is mandatory >> c) XML and JSON are both mandatory >> d) Both XML and JSON mandatory on client, >> server can implement whatever it chooses. >> Not clear yet how the client would find out, but that would of course >> be something to be worked out if we choose this option >> >> Bert >> >> _______________________________________________ >> 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 nobody Wed Sep 3 04:00:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994901A86E9 for ; Wed, 3 Sep 2014 04:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MANGLED_DIET=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNDAUWvXsBJX for ; Wed, 3 Sep 2014 04:00:42 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710F31A86EE for ; Wed, 3 Sep 2014 04:00:42 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id y20so9052607ier.6 for ; Wed, 03 Sep 2014 04:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:message-id:date:subject:from:in-reply-to :references:to:cc; bh=4Mf4gXwVsLzzcZdJgB1woOZlO4kKLCE3L4RLgRHQyBI=; b=VM3HhEtG8dXWnT6IJX01Z5NfxjeTQYmJquPmA2Kyvz1YyZ8soBkTHEmQ5GM1bZJ2WG OAbJjpC0Xii5o+pLsAeZsxDai6n1WevFXCULpvhOgFaTpu8iR2FmKv9O9S2CeMFCYULG 0mZlHpuT9Jsk8m7DM+F1yEBGuAYPPxpnIbd8QQinpfNADMh4gZavNysI5ypMCR7JSlh7 1DiVEp760t4XK5EO3s9UzCqVazgmp33pmcxDermLUGgv63EZJgq4JbCx8mW0WbHa1lhM YPyYPR6/jDs4gu4qxKTLRFqlmvfOfw+QaiyzS8Nfnx1R57cRIIYo3LXWPOVEQXQniGIL 4n4g== X-Received: by 10.50.82.98 with SMTP id h2mr4451724igy.26.1409742041853; Wed, 03 Sep 2014 04:00:41 -0700 (PDT) Received: from [127.0.0.1] ([24.114.107.184]) by mx.google.com with ESMTPSA id z2sm4458524igl.16.2014.09.03.04.00.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 04:00:40 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============0399330285==" MIME-Version: 1.0 X-Mailer: BlackBerry Email (10.2.1.3247) Message-ID: <20140903110039.6693011.17963.13087@gmail.com> Date: Wed, 03 Sep 2014 07:00:39 -0400 From: ian.hamish.duncan@gmail.com In-Reply-To: <2EB9ECB8-C70E-48E7-9F60-440EB29E84B2@gmail.com> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <2EB9ECB8-C70E-48E7-9F60-440EB29E84B2@gmail.com> To: Mahesh Jethanandani , "Bert Wijnen (IETF)" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FlL8Bj51x3yXRLgeuB_SlpRTk1Y Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 11:00:43 -0000 --===============0399330285== Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Nope. Or at least my judgment was for d). Let's = talk.
=

= =
From my thumb or too.
= = =
=
From: Mahesh Jethanandan= i
Sent: Wednesday, September 3, 2014 01:11
To= : Bert Wijnen (IETF)
Cc: Netconf
Subject:= Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinio= n on RESTCONF modularity

Prefer a).

Mahesh Je= thanandani

On Sep 2, 2014, at 3:23 AM, "Bert Wijnen (IETF)" <bertietf@bwijnen.net> wrote:
On 26/08/14 22:49, Andy Bierma= n wrote:

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

Dear NETCONF= WG participants, do you have an opinion?

= So far I have seen only a few people express their opinion.

Please speak up so that we (WG chairs) have better data t= o judge if we
do or do not have WG (rough) consensus. Pls d= o speak up by 18 Sept 2014.

Please speak y= our mind about these options:

a) XML is ma= ndatory
b) JSON is mandatory
c) XML and JSO= N are both mandatory
d) Both XML and JSON mandatory on clie= nt,
  server can implement whatever it chooses.<= /span>
  Not clear yet how the client would find out, b= ut that would of course
  be something to be wor= ked out if we choose this option

Bert

______________________________________________= _
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/n= etconf

=
--===============0399330285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="ATT001.txt" _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0399330285==-- From nobody Wed Sep 3 04:08:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930C21A86E9 for ; Wed, 3 Sep 2014 04:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH6UfIr970XF for ; Wed, 3 Sep 2014 04:07:59 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730A11A0AF2 for ; Wed, 3 Sep 2014 04:07:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4CCEE540764; Wed, 3 Sep 2014 13:07:57 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOtlo0yi75wR; Wed, 3 Sep 2014 13:07:52 +0200 (CEST) Received: from localhost (unknown [217.31.205.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6D755540396; Wed, 3 Sep 2014 13:07:52 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Andy Bierman In-Reply-To: <20140903061014.GA79257@elstar.local> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> <20140903061014.GA79257@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 03 Sep 2014 13:07:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XDVkpt5SLxWhWaJfFLjYu-xR_YY Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 11:08:02 -0000 Juergen Schoenwaelder writes: > On Tue, Sep 02, 2014 at 02:31:10PM -0700, Andy Bierman wrote: >> On Tue, Sep 2, 2014 at 2:12 PM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >> > On Tue, Sep 02, 2014 at 01:59:53PM -0700, Andy Bierman wrote: >> > > On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder < >> > > j.schoenwaelder@jacobs-university.de> wrote: >> > > >> > > > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: >> > > > > >> > > > > Please speak your mind about these options: >> > > > > >> > > > > a) XML is mandatory >> > > > > b) JSON is mandatory >> > > > > c) XML and JSON are both mandatory >> > > > > d) Both XML and JSON mandatory on client, >> > > > > server can implement whatever it chooses. >> > > > > Not clear yet how the client would find out, but that would of >> > course >> > > > > be something to be worked out if we choose this option >> > > > > >> > > > >> > > > I have neither implemented a server nor a client. That said, I think I >> > > > prefer a) because having less options improves interoperability (I am >> > > > old school on this). I also note that the JSON encoding is not final >> > > > yet and depending on how some of the details are resolved, I may be OK >> > > > with d) or not. The question is how much complexity is added to a >> > > > client for supporting both XML and JSON. If the JSON mappings requires >> > > > that all clients are able to dynamically parse and interpret YANG >> > > > models, I am going to be strictly against d). >> > > > >> > > > >> > > I do not understand your last sentence. We expect a compliant >> > > server to implement the entry points and monitoring data defined in >> > > the draft. The client MUST understand at least the static API data, >> > > such as /restconf/modules. The client could also put its preferred >> > > encoding in the Accept header for a GET request and see if the >> > > server responds with 406 Not Acceptable. This does not require any >> > > YANG parsing. >> > >> > Option d) says that client has to be able to try both JSON and >> > XML. This means the client must be able to 'transform' the two >> > encoding into a common internal representation. If, for example, one >> > encoding uses URIs to identify namespaces while the other encoding >> > uses module names or one encoding requires type information to be >> > available while the other does not, then I _expect_ this adds >> > significant complexity. The current JSON I-D (as far as I understand >> > it) does not allow a simple 'stateless' (means data model agnostic) >> > transformation between the two encodings. >> > >> > >> But using the reply message from the server is an implementation >> detail no matter what encoding is used. An XML or JSON document in >> RESTCONF is a serialized encoding of some data structures. If the >> client wants the data to be hierarchical, then it has to be >> converted to something else. > > As of today, I can't translate XML encoding to JSON encoding and vice > versa without having access to some information defined in YANG > modules. I believe this raises the bar for certain implementations. That's a feature, not bug. :-) But what's much more important, and a source of some confusion, is that the yang-json draft is NOT primarily about translating XML to JSON and back! Its main point is to define JSON encoding for YANG-modelled data, and it does so by means of the XML-JSON mapping, simply because it's easier given that the XML encoding is precisely defined in RFC 6020. Imagine there ain't no XML and 6020 explicitly defines only JSON encoding. Do you think the JSON encoding for leaf foo { type uint16; } should then be "foo": "42" In my view, it could happen that JSON becomes prevalent, and in this case option a) wouldn't make much sense. Lada > > If my client API (e.g. ncclient) exposes values as untyped strings > (the way things are encoded in NETCONF, which uses XML) to higher > layers, then adding support for JSON encoding adds complexity since > now I need at least access to some type information and I need to be > able to map different namespace identifiers (URIs and module > names). Yes, this is an implementation detail but I would not want to > add this complexity to something like ncclient. > > Anyway, I provided an answer plus a reasoning. There is no need to > agree on it. > > /js > > -- > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 3 05:01:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF89F1A00BA for ; Wed, 3 Sep 2014 05:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq48BVIi4OOi for ; Wed, 3 Sep 2014 05:01:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49271A00E2 for ; Wed, 3 Sep 2014 05:01:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9D20C1C7A; Wed, 3 Sep 2014 14:01:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1_BcOTky2TjR; Wed, 3 Sep 2014 14:01:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 14:01:51 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E70A20035; Wed, 3 Sep 2014 14:01:51 +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 W6fu1caj1Auo; Wed, 3 Sep 2014 14:01:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8C9420033; Wed, 3 Sep 2014 14:01:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 983FE2E58BD0; Wed, 3 Sep 2014 14:01:49 +0200 (CEST) Date: Wed, 3 Sep 2014 14:01:49 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140903120149.GC80206@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf References: <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> <20140903061014.GA79257@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/urN2uSseH_uPLBGWfDH8TCDdecs Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 12:01:56 -0000 On Wed, Sep 03, 2014 at 01:07:51PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Tue, Sep 02, 2014 at 02:31:10PM -0700, Andy Bierman wrote: > >> On Tue, Sep 2, 2014 at 2:12 PM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >> > On Tue, Sep 02, 2014 at 01:59:53PM -0700, Andy Bierman wrote: > >> > > On Tue, Sep 2, 2014 at 1:24 PM, Juergen Schoenwaelder < > >> > > j.schoenwaelder@jacobs-university.de> wrote: > >> > > > >> > > > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: > >> > > > > > >> > > > > Please speak your mind about these options: > >> > > > > > >> > > > > a) XML is mandatory > >> > > > > b) JSON is mandatory > >> > > > > c) XML and JSON are both mandatory > >> > > > > d) Both XML and JSON mandatory on client, > >> > > > > server can implement whatever it chooses. > >> > > > > Not clear yet how the client would find out, but that would of > >> > course > >> > > > > be something to be worked out if we choose this option > >> > > > > > >> > > > > >> > > > I have neither implemented a server nor a client. That said, I think I > >> > > > prefer a) because having less options improves interoperability (I am > >> > > > old school on this). I also note that the JSON encoding is not final > >> > > > yet and depending on how some of the details are resolved, I may be OK > >> > > > with d) or not. The question is how much complexity is added to a > >> > > > client for supporting both XML and JSON. If the JSON mappings requires > >> > > > that all clients are able to dynamically parse and interpret YANG > >> > > > models, I am going to be strictly against d). > >> > > > > >> > > > > >> > > I do not understand your last sentence. We expect a compliant > >> > > server to implement the entry points and monitoring data defined in > >> > > the draft. The client MUST understand at least the static API data, > >> > > such as /restconf/modules. The client could also put its preferred > >> > > encoding in the Accept header for a GET request and see if the > >> > > server responds with 406 Not Acceptable. This does not require any > >> > > YANG parsing. > >> > > >> > Option d) says that client has to be able to try both JSON and > >> > XML. This means the client must be able to 'transform' the two > >> > encoding into a common internal representation. If, for example, one > >> > encoding uses URIs to identify namespaces while the other encoding > >> > uses module names or one encoding requires type information to be > >> > available while the other does not, then I _expect_ this adds > >> > significant complexity. The current JSON I-D (as far as I understand > >> > it) does not allow a simple 'stateless' (means data model agnostic) > >> > transformation between the two encodings. > >> > > >> > > >> But using the reply message from the server is an implementation > >> detail no matter what encoding is used. An XML or JSON document in > >> RESTCONF is a serialized encoding of some data structures. If the > >> client wants the data to be hierarchical, then it has to be > >> converted to something else. > > > > As of today, I can't translate XML encoding to JSON encoding and vice > > versa without having access to some information defined in YANG > > modules. I believe this raises the bar for certain implementations. > > That's a feature, not bug. :-) > > But what's much more important, and a source of some confusion, is that > the yang-json draft is NOT primarily about translating XML to JSON and > back! Its main point is to define JSON encoding for YANG-modelled data, > and it does so by means of the XML-JSON mapping, simply because it's > easier given that the XML encoding is precisely defined in RFC 6020. > > Imagine there ain't no XML and 6020 explicitly defines only JSON > encoding. Do you think the JSON encoding for > > leaf foo { > type uint16; > } > > should then be > > "foo": "42" > > In my view, it could happen that JSON becomes prevalent, and in this > case option a) wouldn't make much sense. You argue that (a) using two different ways to identify namespaces (URIs vs module names) and (b) using two different encodings where one is carrying everything as a string while the other carries _some_ type information is a feature. I pointed out that (a) falls flat for anyxml encoding - you argue that does not matter since anyxml can be treated as the implementor likes anyway, which I find problematic. Others pointed out that (b) may lead to issues with unions so we already need to install an expection for unions (and large numbers we need as strings as well). I argue that the requirement to have type information available and module name to URI mapping information available to support both encoding adds complexity. So is it a feature or a bug? Since there is RFC 6020 and NETCONF is using XML, answering a hypothetical question does not help us much to resolve our different views on this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 05:07:10 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28D01A00E2 for ; Wed, 3 Sep 2014 05:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwyQr99oJ8aw for ; Wed, 3 Sep 2014 05:07:06 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19ED1A00BA for ; Wed, 3 Sep 2014 05:07:05 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id eb12so5991743oac.12 for ; Wed, 03 Sep 2014 05:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wILQ7dDC287hy8dn97Pi03qGkEYRaPFRCgHs2JbOHXg=; b=PEPz9vKNyUhZBJwv4/+8ChK5yZNJuqUI0aT8+6SmR+44S0O9jnW11t2t01UdYGQfKx Nk3cG1ahVR73Stfj5AmklRewyVF32ZEVeoVkeYL8rfFVgJsiWpq+0juG1452DfaCtHYq /hASmJzu3vIA+ahVYCm15pPeJl8jF5ENrs0Gq1L8uPic8rqO/Bwtzs8Yfc61W/AuHjvJ zhxdln9FNv8j8qXTs1Xn43yxeRfeezjmAeyzXqRGmbvMH0EB3ZEIG5umWQyhwUAHilh2 qlZWiCg0xy/XYh6AX++pNZSkWfw7UCN/u447YK442nirSYAj0Ty444xipNH1hKrXcmsQ pQSA== MIME-Version: 1.0 X-Received: by 10.182.19.195 with SMTP id h3mr37707430obe.43.1409746025260; Wed, 03 Sep 2014 05:07:05 -0700 (PDT) Received: by 10.182.107.33 with HTTP; Wed, 3 Sep 2014 05:07:05 -0700 (PDT) In-Reply-To: <20140903110039.6693011.17963.13087@gmail.com> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <2EB9ECB8-C70E-48E7-9F60-440EB29E84B2@gmail.com> <20140903110039.6693011.17963.13087@gmail.com> Date: Wed, 3 Sep 2014 08:07:05 -0400 Message-ID: From: ian duncan To: Mahesh Jethanandani , "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=001a11c215000f2b240502281313 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ixRKMRpBvD0nF0kElqtTbws1I88 Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 12:07:08 -0000 --001a11c215000f2b240502281313 Content-Type: text/plain; charset=UTF-8 Hello --- Apologies to Mahesh & the entire list. My intended as private message but defeated by fumbled finger on a bad phone UI and inadequate caffeination. Best .. Ian --001a11c215000f2b240502281313 Content-Type: text/html; charset=UTF-8
Hello ---

Apologies to Mahesh & the entire list.

My intended as private message but defeated by fumbled finger on a bad phone UI and inadequate caffeination.

Best .. Ian
--001a11c215000f2b240502281313-- From nobody Wed Sep 3 12:21:35 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C517A1A6F14 for ; Wed, 3 Sep 2014 12:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhHGdCTygzIA for ; Wed, 3 Sep 2014 12:21:26 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835D31A6F27 for ; Wed, 3 Sep 2014 12:21:23 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XPG7L-0005di-L9; Wed, 03 Sep 2014 21:21:20 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-6.fritz.box) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XPG7L-0001KK-Al; Wed, 03 Sep 2014 21:21:19 +0200 Message-ID: <54076A2E.5000507@bwijnen.net> Date: Wed, 03 Sep 2014 21:21:18 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Andy Bierman References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd4afd1edf6a43e8077b492b134c92c9fc8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/LQduL-PNHsPjhIYY5NrDiAG6hfg Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 19:21:29 -0000 thanks Andy. Bert On 03/09/14 05:11, Andy Bierman wrote: > Hi, > > I added the issue in the issue tracker. > We do not plan to use the tracker for discussion. > It will capture significant events for each issue. > The WG will be added as an email recipient soon so manual notices > like this one will not be needed. > > https://github.com/netconf-wg/restconf/issues/7 > > > Andy > > > > On Tue, Sep 2, 2014 at 3:23 AM, Bert Wijnen (IETF) > wrote: > > On 26/08/14 22:49, Andy Bierman wrote: > > > Perhaps the co-chairs should decide how to proceed somehow. > > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _________________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/__listinfo/netconf > > From nobody Thu Sep 4 00:02:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862911A0B83 for ; Thu, 4 Sep 2014 00:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox-mpwE6hU7u for ; Thu, 4 Sep 2014 00:02:50 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B681A0B7D for ; Thu, 4 Sep 2014 00:02:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 57D49540466; Thu, 4 Sep 2014 09:02:47 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0Rhkp-BFVNB; Thu, 4 Sep 2014 09:02:43 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 97EA3540336; Thu, 4 Sep 2014 09:02:42 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140903120149.GC80206@elstar.local> References: <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> <20140903061014.GA79257@elstar.local> <20140903120149.GC80206@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 04 Sep 2014 09:02:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UsGXCcPbjuZx4bC_yf7RMEx-QuU Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:02:52 -0000 Juergen Schoenwaelder writes: > > You argue that (a) using two different ways to identify namespaces > (URIs vs module names) and (b) using two different encodings where one > is carrying everything as a string while the other carries _some_ type > information is a feature. It's simpler - I argue that draft-ietf-netmod-yang-json provides quite a natural JSON encoding for instances of YANG data nodes. It was not my goal to develop an "XML compatibility" profile for JSON. Having some data type information already in the encoding can hardly be seen as a drawback. A module name is a way better namespace identifier than an URI, and we are lucky to have it. I don't think it could pose any problems because module names and corresponding URIs mostly appear together - in modules, hellos, IANA registry. > > I pointed out that (a) falls flat for anyxml encoding - you argue that > does not matter since anyxml can be treated as the implementor likes It seems the purpose of anyxml/anydata needs to be reconsidered on a more general level. We can then return to its XML/JSON encoding. > anyway, which I find problematic. Others pointed out that (b) may lead > to issues with unions so we already need to install an expection for > unions (and large numbers we need as strings as well). I argue that I don't agree that values of the union type should always be encoded as strings in JSON, we just have to find a solution for some corner cases. As for large numbers, the proposal to encode them as strings is only an ugly workaround for inferior JSON parsers. Another option would be to recommend implementors to avoid such parsers. > the requirement to have type information available and module name to > URI mapping information available to support both encoding adds > complexity. > > So is it a feature or a bug? Since there is RFC 6020 and NETCONF is > using XML, answering a hypothetical question does not help us much > to resolve our different views on this. This discussion focuses too much on the situation where both XML and JSON clients are supposed to work with the same server. Whilst it is important to make this possible, it's not the only criterion - and in Bert's scenarios (a), (b) and (d), servers even needn't support it. What's IMO equally important is to offer first-class APIs for XML and JSON separately. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 4 04:26:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1897B1A7030 for ; Thu, 4 Sep 2014 04:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cymSbRAgOeBv for ; Thu, 4 Sep 2014 04:26:47 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id A6FB81A7029 for ; Thu, 4 Sep 2014 04:26:47 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id myyd1o0051wpRvQ58zSnzw; Thu, 04 Sep 2014 11:26:47 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta18.westchester.pa.mail.comcast.net with comcast id mzSm1o00C2yZEBF3ezSmyF; Thu, 04 Sep 2014 11:26:47 +0000 From: "ietfdbh" To: "'Ladislav Lhotka'" , "'Juergen Schoenwaelder'" References: <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> <20140903061014.GA79257@elstar.local> <20140903120149.GC80206@elstar.local> In-Reply-To: Date: Thu, 4 Sep 2014 07:26:44 -0400 Message-ID: <007e01cfc833$1b9dafc0$52d90f40$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIJ6518j2FGIjgX9w91+P4BziZ8gQGj3D9wAscd9+wB6lF3UAFMhGeJAVMS4QsB6EQuDQEwsNi4AoPKQucCqQFpTAJQvFKTAfVgD+Ka0H3jkA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409830007; bh=Y3N54IY3lfI5extiegHNuSdHSwmfxVL2MOaYWSzBUDM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=RximvsW7VMm4tar3b3XeHy58z4fzXjA4qE+vGMQ5VwdP3ZzNLI0vdjySO8AF93oiu 8crqCDElQQq9VPDpeWF7aJRuFow2stoEAz3Z3MIhjngAVrHCuBmmRLxpllNOzUcPuC MVSvxFIAg3sUMEbNwW2hRS76opRPkeiuyxRYIwggfyKlVEkMlGDLSist9C+j8zquhz RfUz/bgrK+lqCl2eDKesbVr0tC0JafUEPYgO68jJYpT3WYCzKQFEkaUOHH2RrOVMGx K7g2boU7oDE5L/Rb4EbLVzPSiJa/UX6OC06YLlQhRe9j5Ndb0U20sEBCLRUq2b61Zt QJ+iiLoBMNiqA== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ZRI53HsCgW4zdMKEvjz65d7-SLI Cc: 'Netconf' Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:26:49 -0000 Hi Lada, > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ladislav > Lhotka [...] > > This discussion focuses too much on the situation where both XML and > JSON clients are supposed to work with the same server. Whilst it is > important to make this possible, it's not the only criterion - and in > Bert's scenarios (a), (b) and (d), servers even needn't support > it. What's IMO equally important is to offer first-class APIs for XML > and JSON separately. > Do you make that assessment as an NMS developer, an agent developer, a toolkit developer, or a user (or a JSON promoter)? I'm not sure what your perspective is based on. My background is primarily as an NMS developer and user of the information. As an NMS user, when I ask a server for some data, I want to know whether asking that data to be encoded using XML or using JSON might give me different results. I would assume the 90/10 rule applies - 90% of the time, they will be identical. But I need to know whether the specific data I want to get falls within that 90%, or within the exceptional 10%. Even if we get to 97/3 or 98/2, I still want to know where those exceptions are, because getting misleading information is a bad thing, and issues like datatype conversions can cause data to be interpreted incorrectly, and be hard to detect that a faulty conversion has corrupted the information (think casts in C, for example). If I have a single client managing a heterogeneous network, where half my Netconf servers support XML and the other half support JSON, will both interfaces give me data that is truly equivalent - to the point that I can reliably compare data from one type of server with those of the other type of server? >From an NMS/user perspective I need to know I can correlate the data from multiple servers reliably. So the focus on whether both XML and JSON clients are supposed to work **interoperably** with the same server is rather important. I strongly support the desire for first-class APIs. But for an industry standard from an SDO focused on vendor-neutral interoperability, having ONE mandatory-to-implement first-class API that ensures interoperability should trump having TWO (optional or MTI) first-class APIs, if we cannot ensure interoperability across the two standards-compliant implementations. David Harrington ietfdbh@comcast.net +1-603-828-1401 From nobody Thu Sep 4 07:26:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DAE1A88F2 for ; Thu, 4 Sep 2014 07:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.668] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ7jSAkxbaY4 for ; Thu, 4 Sep 2014 07:26:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9111A88F1 for ; Thu, 4 Sep 2014 07:26:18 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 4C34113F63D; Thu, 4 Sep 2014 16:26:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409840776; bh=20gu+0S7VVlmywVk9+wP7pZnWk0VIQ4CkouhSWXpAas=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N9P9Xx9+MzgOeQzdgev19lGY1McELR2lj/d4g7thUbM1ujJRH/Rn6XmEUKUiP5aDq sm3q5LukpdZkvERncSv8Xhm09fekpgRbhI2PZLkTjPHNGDf6uNcpbXO1CVjzqoVAE6 Mr+WQ+3fKn03GcHo684I57gKj9PF8hcBnpaTgwe0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <007e01cfc833$1b9dafc0$52d90f40$@comcast.net> Date: Thu, 4 Sep 2014 16:26:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D549198-ECEA-4789-A2A8-B7E089F5C5DA@nic.cz> References: <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> <20140903061014.GA79257@elstar.local> <20140903120149.GC80206@elstar.local> <007e01cfc833$1b9dafc0$52d90f40$@comcast.net> To: David Harrington X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wf3COVEo18LN_6Z3QrOcPzlfsEg Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 14:26:24 -0000 On 04 Sep 2014, at 13:26, ietfdbh wrote: > Hi Lada, >=20 >> -----Original Message----- >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ladislav >> Lhotka > [...] >>=20 >> This discussion focuses too much on the situation where both XML and >> JSON clients are supposed to work with the same server. Whilst it is >> important to make this possible, it's not the only criterion - and in >> Bert's scenarios (a), (b) and (d), servers even needn't support >> it. What's IMO equally important is to offer first-class APIs for XML >> and JSON separately. >>=20 >=20 > Do you make that assessment as an NMS developer, an agent developer, a > toolkit developer, or a user (or a JSON promoter)? > I'm not sure what your perspective is based on. None of the above, I am an amateur in all these areas. But I certainly don=92t want to blindly promote JSON over XML. I = invested much effort in learning XML and XSLT is one of my favourite = programming languages, which I truly miss in JSON. >=20 > My background is primarily as an NMS developer and user of the = information. > As an NMS user, when I ask a server for some data, I want to know = whether > asking that data to be encoded using XML or using JSON might give me > different results.=20 > I would assume the 90/10 rule applies - 90% of the time, they will be > identical. > But I need to know whether the specific data I want to get falls = within that > 90%, or within the exceptional 10%.=20 > Even if we get to 97/3 or 98/2, I still want to know where those = exceptions > are, because getting misleading information is a bad thing, and issues = like > datatype conversions can cause data to be interpreted incorrectly, and = be > hard to detect that a faulty conversion has corrupted the information = (think > casts in C, for example). As I said, our aim to achieve 100 % for data that are subject to data = modelling (anyxml in its current form is not). And it doesn=92t seem = really that difficult. >=20 > If I have a single client managing a heterogeneous network, where half = my > Netconf servers support XML and the other half support JSON, will both > interfaces give me data that is truly equivalent - to the point that I = can > reliably compare data from one type of server with those of the other = type > of server? > =46rom an NMS/user perspective I need to know I can correlate the data = from > multiple servers reliably. > So the focus on whether both XML and JSON clients are supposed to work > **interoperably** with the same server is rather important. Yes, it is important, and I don=92t want any ambiguity. My point was = that it would be useless to achieve this goal by extending and bending = JSON so that everything will work exactly as in XML. =20 >=20 > I strongly support the desire for first-class APIs. > But for an industry standard from an SDO focused on vendor-neutral > interoperability, having ONE mandatory-to-implement first-class API = that > ensures interoperability should trump having TWO (optional or MTI) > first-class APIs, if we cannot ensure interoperability across the two > standards-compliant implementations. Selecting one for all classes of devices is difficult. Lada >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Sep 5 15:07:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6A11A030E for ; Fri, 5 Sep 2014 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0KP3eyIMa0J for ; Fri, 5 Sep 2014 15:07:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227D81A01A5 for ; Fri, 5 Sep 2014 15:07:43 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Fri, 5 Sep 2014 22:07:40 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.106]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.106]) with mapi id 15.00.1019.015; Fri, 5 Sep 2014 22:07:40 +0000 From: Kent Watsen To: NetConf Thread-Topic: draft-ietf-netconf-call-home-00 Thread-Index: AQHPyVXP6AoaVeb0nkiw7tdmFD8icw== Date: Fri, 5 Sep 2014 22:07:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(199003)(164054003)(189002)(107046002)(107886001)(99286002)(106116001)(20776003)(105586002)(95666004)(77096002)(4396001)(92726001)(92566001)(110136001)(90102001)(64706001)(229853001)(86362001)(79102001)(76482001)(106356001)(230783001)(21056001)(85306004)(85852003)(54356999)(50986999)(31966008)(46102001)(83072002)(19580395003)(80022001)(19617315012)(74502001)(74662001)(15202345003)(81542001)(81342001)(36756003)(16236675004)(77982001)(83506001)(99396002)(66066001)(87936001)(83322001)(15975445006)(101416001)(97736003)(2656002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D02FAC6C803D0kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/SSXaceo8Ua1imLzHFIvRznUU-LY Subject: [Netconf] draft-ietf-netconf-call-home-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:07:46 -0000 --_000_D02FAC6C803D0kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, For the upcoming NETCONF virtual meetings, following is the URL to the new = call-home draft, which merges the reverse-ssh and 5539bis drafts into one: http://www.ietf.org/staging/draft-ietf-netconf-call-home-00.txt If issues are found when reviewing it, please consider logging your issues = here: https://github.com/netconf-wg/call-home Note that this document has not been officially published yet, hence why it= 's in the "staging" directory and no notification has been sent to the list= yet. Thanks, Kent --_000_D02FAC6C803D0kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <937A0A746E774E4ABC0F846959A978B1@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

All,

For the upcoming NETCONF virtual meetings, following is the URL to the new = call-home draft, which merges the reverse-ssh and 5539bis drafts into one:<= /div>


If issues are found when reviewing i= t, please consider logging your issues here:


Note that this document has not been= officially published yet, hence why it's in the "staging" direct= ory and no notification has been sent to the list yet.

Thanks,
Kent

--_000_D02FAC6C803D0kwatsenjunipernet_-- From nobody Fri Sep 5 23:24:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E101A6F5D for ; Fri, 5 Sep 2014 23:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsFpy1AEj1HF for ; Fri, 5 Sep 2014 23:24:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F231A0415 for ; Fri, 5 Sep 2014 23:24:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8BED4263F; Sat, 6 Sep 2014 08:24:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lSOH6BRlsPB5; Sat, 6 Sep 2014 08:24:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 6 Sep 2014 08:24:04 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5449720035; Sat, 6 Sep 2014 08:24:04 +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 FtfbU-PRE7SI; Sat, 6 Sep 2014 08:24:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 355B420036; Sat, 6 Sep 2014 08:24:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4F19A2E5C093; Sat, 6 Sep 2014 08:24:02 +0200 (CEST) Date: Sat, 6 Sep 2014 08:24:01 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140906062401.GA89532@elstar.local> Mail-Followup-To: Ladislav Lhotka , Netconf References: <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> <20140902211238.GA78502@elstar.local> <20140903061014.GA79257@elstar.local> <20140903120149.GC80206@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ELrLl-JbzchwpTK_wIeOCOW1h0Y Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 06:24:10 -0000 On Thu, Sep 04, 2014 at 09:02:41AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > > > You argue that (a) using two different ways to identify namespaces > > (URIs vs module names) and (b) using two different encodings where one > > is carrying everything as a string while the other carries _some_ type > > information is a feature. > > It's simpler - I argue that draft-ietf-netmod-yang-json provides quite a > natural JSON encoding for instances of YANG data nodes. It was not my > goal to develop an "XML compatibility" profile for JSON. Having some > data type information already in the encoding can hardly be seen as a > drawback. > > A module name is a way better namespace identifier than an URI, and we > are lucky to have it. I don't think it could pose any problems because > module names and corresponding URIs mostly appear together - in modules, > hellos, IANA registry. > I disagree that a module name is "way better" and I strongly believe that using different identifiers to identify the same namespace in different encodings adds operational complexity that can and should be avoided. I do not think it makes sense to further iterate this point between us since we go in circles. > I don't agree that values of the union type should always be encoded as > strings in JSON, we just have to find a solution for some corner cases. The only solution presented so far has been to encode unions as strings. Unless someone presents an alternative, I assume this is what we have to do. > As for large numbers, the proposal to encode them as strings is only an > ugly workaround for inferior JSON parsers. Another option would be to > recommend implementors to avoid such parsers. The world is as it is. What is the value of defining a JSON encoding where I can't use many off the shelf JSON libraries? The encoding must be robust, we can accept to loose precision. Again, we go in circles here. > This discussion focuses too much on the situation where both XML and > JSON clients are supposed to work with the same server. Whilst it is > important to make this possible, it's not the only criterion - and in > Bert's scenarios (a), (b) and (d), servers even needn't support > it. What's IMO equally important is to offer first-class APIs for XML > and JSON separately. Network management systems tend to talk to many devices. If we do not define a single mandatory to implement encoding, clients and servers will have to support both in the real world. And now we are getting back to the subject of this thread at least. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sat Sep 6 02:31:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079DA1A01DD; Sat, 6 Sep 2014 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8ACFGStyfXq; Sat, 6 Sep 2014 02:31:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B19251A01CA; Sat, 6 Sep 2014 02:31:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140906093146.24669.38634.idtracker@ietfa.amsl.com> Date: Sat, 06 Sep 2014 02:31:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/St7AeXKiv2O38A3qlh6yp1E9aFQ Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 09:31:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-00.txt Pages : 9 Date : 2014-08-19 Abstract: This document presents NETCONF Call Home, which enables a NETCONF server to initiate a secure connection to the NETCONF client. NETCONF Call Home supports both the SSH and TLS transports, and does so in a way that preserves the SSH and TLS roles when compared to standard NETCONF over SSH or TLS connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-call-home-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 8 06:26:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6B1A87D6 for ; Mon, 8 Sep 2014 06:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc8HoAPRGR4N for ; Mon, 8 Sep 2014 06:26:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D4FCA1A87D1 for ; Mon, 8 Sep 2014 06:26:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 69C2AC306; Mon, 8 Sep 2014 09:26:01 -0400 (EDT) Date: Mon, 8 Sep 2014 09:26:01 -0400 From: Jeffrey Haas To: "Bert Wijnen (IETF)" Message-ID: <20140908132601.GC15163@pfrc> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54059AA9.4080902@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/kwrSHXtRmshgj6PjZeFRAxnjsm4 Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:26:03 -0000 On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option I prefer a first and then d second. While I'm not currently a netconf developer, I have prior experience in both xml and json in development at a prior employer. While I dislike the heavy weight of xml, I vastly prefer its flexibility. -- Jeff From nobody Mon Sep 8 09:11:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161FD1A88A9; Mon, 8 Sep 2014 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEChbQJPq1aj; Mon, 8 Sep 2014 09:11:53 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1CE1A88A7; Mon, 8 Sep 2014 09:11:50 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id cm18so14518140qab.9 for ; Mon, 08 Sep 2014 09:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4b2DUk1oosg4N259J2TWNCgoraHv3WkXD3673SygXY0=; b=SYe/LTJHtKt/haa86Rz3EEPdBL63iJMtyFpH5jm+e0df3cWB5t1HDhvBbl8Jm7TmLr QIzvsz4G3U279uGLnSTwmsaLuY2iLWYvQmj0BAvXPEmSuVORUnbdcPSxme353lHOJZOb 2lrgL6kC6HKkSya9mYkzsOo+xxiJOXn6MCJqowt7250oElfKPP1Q1+EjUnN9J0i2xkzX 0GHTLNb6cfineYpau1zub0M1pMDAwPhcJ3zM4AInjOilq+sGNvm/lSSFk7OsDZTErWZ8 o0IGoWPcgsnwwaP0vwxqlvkLLgfoPneXiDFU6NK7fejXINVYfYfuNphl8fOsgB/mOu3T QqCQ== MIME-Version: 1.0 X-Received: by 10.224.36.4 with SMTP id r4mr42600021qad.69.1410192709394; Mon, 08 Sep 2014 09:11:49 -0700 (PDT) Received: by 10.140.19.16 with HTTP; Mon, 8 Sep 2014 09:11:49 -0700 (PDT) In-Reply-To: <20140820174629.27343.42011.idtracker@ietfa.amsl.com> References: <20140820174629.27343.42011.idtracker@ietfa.amsl.com> Date: Mon, 8 Sep 2014 09:11:49 -0700 Message-ID: From: Mahesh Jethanandani To: ietf@ietf.org Content-Type: multipart/alternative; boundary=089e0153728082293c05029013e5 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7DwOx5PYTw-ad8JUNfdSIGSZqBk Cc: Netconf , IETF Announcement List Subject: Re: [Netconf] NETCONF WG Bi-Weekly Virtual Interim Meetings beginning September 8, 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:11:56 -0000 --089e0153728082293c05029013e5 Content-Type: text/plain; charset=UTF-8 Is there a meeting today? WebEx says the meeting has not started. On Wed, Aug 20, 2014 at 10:46 AM, IESG Secretary wrote: > The NETCONF WG will have a series of bi-weekly virtual interim meetings. > The meetings will take place every other Monday from 1900-2100 CEST. > The first meeting will be on Monday, September 8, 2014, and the series > will end on Monday, November 2, 2014. > > ------------------------------------------------------- > Topic: NETCONF Bi-weekly Meeting > Date: Every 2 weeks on Monday, from Monday, September 8, 2014 to Monday, > November 3, 2014 > Time: 7:00 pm, Europe Summer Time (Berlin, GMT+02:00) > Meeting Number: 649 602 794 > Meeting Password: restconf > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ietf.webex.com/ietf/j.php?MTID=m3376a52e7a0e41672bed8e07d6c65d67 > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: restconf > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://ietf.webex.com/ietf/j.php?MTID=me875d958a9d772d851399d42e20ae8d4 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): 1-650-479-3208 > > Access code:649 602 794 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > netconf-chairs@tools.ietf.org > > > To update this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ietf.webex.com/ietf/j.php?MTID=m25825e3bf1347d5a34f89769b2cdcd01 > > > WebEx will automatically setup Meeting Manager for Windows the first > time you join a meeting. To save time, you can setup prior to the > meeting by clicking this link: > https://ietf.webex.com/ietf/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in > the meeting, please check whether you have the players installed on your > computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+16504793208x649602794# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Mahesh Jethanandani mjethanandani@gmail.com --089e0153728082293c05029013e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a meeting today? WebEx says the meeting has not s= tarted.

On W= ed, Aug 20, 2014 at 10:46 AM, IESG Secretary <iesg-secretary@ietf.o= rg> wrote:
The NETCONF WG w= ill have a series of bi-weekly virtual interim meetings.
The meetings will take place every other Monday from 1900-2100 CEST.
The first meeting will be on Monday, September 8, 2014, and the series
will end on Monday, November 2, 2014.

-------------------------------------------------------
Topic: NETCONF Bi-weekly Meeting
Date: Every 2 weeks on Monday, from Monday, September 8, 2014 to Monday, November 3, 2014
Time: 7:00 pm, Europe Summer Time (Berlin, GMT+02:00)
Meeting Number: 649 602 794
Meeting Password: restconf


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MT= ID=3Dm3376a52e7a0e41672bed8e07d6c65d67
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: restconf
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=3Dme87= 5d958a9d772d851399d42e20ae8d4

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:649 602 794

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https= ://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
netconf-chairs@tools.ietf.= org


To update this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm258= 25e3bf1347d5a34f89769b2cdcd01


WebEx will automatically setup Meeting Manager for Windows the first
time you join a meeting. To save time, you can setup prior to the
meeting by clicking this link:
https://ietf.webex.com/ietf/meetingcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in
the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php= .

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+16504793208x649602794#

IMPORTANT NOTICE: This WebEx service includes a feature that allows
audio and any documents and other materials exchanged or viewed during
the session to be recorded. By joining this session, you automatically
consent to such recordings. If you do not consent to the recording,
discuss your concerns with the meeting host prior to the start of the
recording or do not join the session. Please note that any such
recordings may be subject to discovery in the event of litigation.

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



--
Mahesh Jethanandani
mjethanandani@gmail.com
--089e0153728082293c05029013e5-- From nobody Mon Sep 8 09:13:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD271A889A for ; Mon, 8 Sep 2014 09:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbh_BiM2i9Ds for ; Mon, 8 Sep 2014 09:13:43 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4651A8866 for ; Mon, 8 Sep 2014 09:13:43 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id l6so15963684qcy.0 for ; Mon, 08 Sep 2014 09:13:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=IFwzSEzIJpJK84tlFMjgsWBsW0xILRwmv0kCx8aII6E=; b=K7ThZeiFO6YS24OC9Ol23dI4MGDrpexLFulpiUah2K8ntO4Js5VlIQPOXSLnSNij/V I2cKI8GQSGvfPe3D0mDmVnalcXyW5j2QwCMcGVunpFDEXx5huzBHhN6trrP9waJf1GYZ u44xWkZV2HldEOd3BghT8nqeW751xgCWhw0O5lwDlW1lhojF1BC1Wqc/eITIGcI/3giq 9Id64WdihIY9z/IWrhhfOl5MDnhC7wfQ5SXAiXdTgZFEtRpKoj+f3ggOUEMp8UAlonfN WLHdVRrEiyvup/VGrDdlaXu4OVtgh7JQpB65lckUU8KOs/oFOCW/7P2/ei9KgScaLZYF mi4g== X-Gm-Message-State: ALoCoQn40pFtshWhcgpVhi/Cq2cUm64yCUU9Vk2xlqemNvh3nE/4IO8pZvxZzoQZhLrdmTbYH5HS MIME-Version: 1.0 X-Received: by 10.224.88.137 with SMTP id a9mr10336814qam.88.1410192822804; Mon, 08 Sep 2014 09:13:42 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 8 Sep 2014 09:13:42 -0700 (PDT) In-Reply-To: <20140820174629.27343.42011.idtracker@ietfa.amsl.com> References: <20140820174629.27343.42011.idtracker@ietfa.amsl.com> Date: Mon, 8 Sep 2014 09:13:42 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c2bbc04532db0502901a04 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iFIuZDQ9nsx1HNd7EsjBUJ4_eRU Subject: [Netconf] Fwd: NETCONF WG Bi-Weekly Virtual Interim Meetings beginning September 8, 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:13:46 -0000 --001a11c2bbc04532db0502901a04 Content-Type: text/plain; charset=ISO-8859-1 FYI, The NETCONF WG Interim meeting will begin in less than an hour. The RESTCONF Issue List: https://github.com/netconf-wg/restconf/issues Andy ---------- Forwarded message ---------- From: IESG Secretary Date: Wed, Aug 20, 2014 at 10:46 AM Subject: NETCONF WG Bi-Weekly Virtual Interim Meetings beginning September 8, 2014 To: IETF Announcement List Cc: netconf@ietf.org The NETCONF WG will have a series of bi-weekly virtual interim meetings. The meetings will take place every other Monday from 1900-2100 CEST. The first meeting will be on Monday, September 8, 2014, and the series will end on Monday, November 2, 2014. ------------------------------------------------------- Topic: NETCONF Bi-weekly Meeting Date: Every 2 weeks on Monday, from Monday, September 8, 2014 to Monday, November 3, 2014 Time: 7:00 pm, Europe Summer Time (Berlin, GMT+02:00) Meeting Number: 649 602 794 Meeting Password: restconf ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=m3376a52e7a0e41672bed8e07d6c65d67 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: restconf 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=me875d958a9d772d851399d42e20ae8d4 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 602 794 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: netconf-chairs@tools.ietf.org To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=m25825e3bf1347d5a34f89769b2cdcd01 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x649602794# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --001a11c2bbc04532db0502901a04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

The NETCONF WG Interim meeting wil= l begin in less than an hour.

The RESTCONF Issue L= ist:


Andy

---------- Forwarded message ---------= -
From: IESG Secretary <iesg-secretary@ietf.org>
Date: Wed, Aug 20, 2014 at 10:46 AM
Subject: NETCONF WG= Bi-Weekly Virtual Interim Meetings beginning September 8, 2014
To: IET= F Announcement List <ietf-anno= unce@ietf.org>
Cc: netconf@ie= tf.org


The NETCONF WG will have a series of bi-weekly virtua= l interim meetings.
The meetings will take place every other Monday from 1900-2100 CEST.
The first meeting will be on Monday, September 8, 2014, and the series
will end on Monday, November 2, 2014.

-------------------------------------------------------
Topic: NETCONF Bi-weekly Meeting
Date: Every 2 weeks on Monday, from Monday, September 8, 2014 to Monday, November 3, 2014
Time: 7:00 pm, Europe Summer Time (Berlin, GMT+02:00)
Meeting Number: 649 602 794
Meeting Password: restconf


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?MT= ID=3Dm3376a52e7a0e41672bed8e07d6c65d67
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: restconf
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?MTID=3Dme87= 5d958a9d772d851399d42e20ae8d4

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:649 602 794

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https= ://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
netconf-chairs@tools.ietf.= org


To update this meeting to your calendar program (for example Microsoft
Outlook), click this link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm258= 25e3bf1347d5a34f89769b2cdcd01


WebEx will automatically setup Meeting Manager for Windows the first
time you join a meeting. To save time, you can setup prior to the
meeting by clicking this link:
https://ietf.webex.com/ietf/meetingcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in
the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php= .

Sign up for a free trial of WebEx
http://= www.webex.com/go/mcemfreetrial

http://www.webex.com=

CCP:+16504793208x649602794#

IMPORTANT NOTICE: This WebEx service includes a feature that allows
audio and any documents and other materials exchanged or viewed during
the session to be recorded. By joining this session, you automatically
consent to such recordings. If you do not consent to the recording,
discuss your concerns with the meeting host prior to the start of the
recording or do not join the session. Please note that any such
recordings may be subject to discovery in the event of litigation.


--001a11c2bbc04532db0502901a04-- From nobody Mon Sep 8 14:47:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0E21A03D9 for ; Mon, 8 Sep 2014 14:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbu6cbcUjuwh for ; Mon, 8 Sep 2014 14:47:26 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164751A03CA for ; Mon, 8 Sep 2014 14:47:26 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q107so6285684qgd.5 for ; Mon, 08 Sep 2014 14:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4z+opQe2lUJHbhl77Ge/1SAa7TK+RY7M5rRpeQsaz+0=; b=LvomAxPo2+CtIBJv91IwnYmXWrHljbOwYkE1kOF/HxEAmuA4yYI2KJmUelThL3Ey3P NHNu1E/JVotZWkTyz7dHqz77xxQOeuXslzBN3vOMnCHq0iuzLyWYRxP4WgEnvfos7kqy CzRfpxTl81ehYCTqC9ZiZwYyj14WOweF+hS3/DsBLPjUmxBbBeAAhMeWcjHfHDtW4CqA j88zqc9WtQDWvynPVwVpObR1VkWyM4IXMHv2EOZkD+6T1sUwUAzQjBBF+T2WLMmeQMrn kas0s4rwIAwdjOr1e4Wj34PHt+L7Z1KLQ9wM3klVhhEdoNSTo6FoeUMo/M7XZ+2i5il8 1liQ== MIME-Version: 1.0 X-Received: by 10.224.47.130 with SMTP id n2mr13173481qaf.87.1410212845360; Mon, 08 Sep 2014 14:47:25 -0700 (PDT) Received: by 10.140.19.16 with HTTP; Mon, 8 Sep 2014 14:47:25 -0700 (PDT) Date: Mon, 8 Sep 2014 14:47:25 -0700 Message-ID: From: Mahesh Jethanandani To: Netconf Content-Type: multipart/alternative; boundary=001a1134b004b49dce050294c33d Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/b0-ltZMzEB-dVE3k8eqR4b_Bwws Subject: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 21:47:28 -0000 --001a1134b004b49dce050294c33d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I was asked to fashion a problem statement around how NETCONF deals with what I call "interactive CLI" models. That model includes commands that are today issued on a CLI and involve a command being issued, and a continuous response coming back till such time it is interrupted either by the CLI or because there is a terminating condition. In the period that the command is running, the CLI may be blocked from issuing any other commands. Commands issued like these are fairly common debug commands issued as part of testing the configuration on the box and are unlike getting statistics which are not interactive in nature. A very common example of this is the ping command. Other examples include traceroute command. A successful ping would have a response like this. > ping google.com PING google.com (74.125.239.98) 56(84) bytes of data. 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D1 ttl=3D= 55 time=3D4.38 ms 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D2 ttl=3D= 55 time=3D4.26 ms 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D3 ttl=3D= 55 time=3D4.38 ms --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev =3D 4.260/4.343/4.389/0.096 ms Here also the response is split in two parts, one that is interactive response which spits out one line at a time as the ping reply comes back and the second which for the lack of a better term a "terminating response" - a cumulative response of the complete interaction, prompted by the issuance of a terminating condition i.e. CTRL-C or TTL expiry. In the case ping fails, there is no interactive response, but there is a terminating response like in this case. > ping pyramid.com PING pyramid.com (109.228.17.0) 56(84) bytes of data. =03 --- pyramid.com ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 5999ms Without getting into specific implementation details, these commands today would follow a pattern of ... .... .... .... CTRL-C for the above NETCONF session .... How does NETCONF deal with such a command? I would not confuse this with another thread that was talking about "bulk response" because this issue is more than how to deal with fragments of large responses. It has to do with the interactive nature that the current NETCONF protocol does not seem to support. If it does not, what are semantics needed to support these kind of commands. --=20 Mahesh Jethanandani mjethanandani@gmail.com --001a1134b004b49dce050294c33d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was asked to fashion a problem statement around how NETC= ONF deals with what I call "interactive CLI" models.

That model includes commands that are today issued on a CLI and invo= lve a command being issued, and a continuous response coming back till such= time it is interrupted either by the CLI or because there is a terminating= condition. In the period that the command is running, the CLI may be block= ed from issuing any other commands.

Commands issue= d like these are fairly common debug commands issued as part of testing the= configuration on the box and are unlike getting statistics which are not i= nteractive in nature.

A very common example of thi= s is the ping command. Other examples include traceroute command. A success= ful ping would have a response like this.

=C2= =A0> ping google.com
PING google.com (74.125.239.98) 56(84) bytes of = data.
64 bytes from n= uq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D1 ttl=3D55 time=3D4= .38 ms
64 bytes from = nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D2 ttl=3D55 time=3D= 4.26 ms
64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D3 ttl=3D55 time= =3D4.38 ms

--- = google.com ping statistics ---
3 packets transmitted, 3 recei= ved, 0% packet loss, time 2002ms
rtt min/avg/max/mdev =3D 4.260/4= .343/4.389/0.096 ms

Here also the response i= s split in two parts, one that is interactive response which spits out one = line at a time as the ping reply comes back and the second which for the la= ck of a better term a "terminating response" - a cumulative respo= nse of the complete interaction, prompted by the issuance of a terminating = condition i.e. CTRL-C or TTL expiry.

In the case p= ing fails, there is no interactive response, but there is a terminating res= ponse like in this case.

=C2=A0> ping pyramid.com
PING pyramid.com (109.228.17.0) 56(84) bytes of data.
=03

--- pyramid.c= om ping statistics ---
7 packets transmitted, 0 received, 100= % packet loss, time 5999ms

Without getting i= nto specific implementation details, these commands today would follow a pa= ttern of

<rpc>
...
<r= pc/>

<rpc-reply>
....=C2=A0
<rpc-reply/>

<rpc-reply>
<= div>....
<rpc-reply/>

<rpc-repl= y>
....
<rpc-reply/>

= <rpc>
CTRL-C for the above NETCONF session
<rp= c/>

<rpc-reply>
....
= <rpc-reply/>

How does NETCONF deal with such= a command? I would not confuse this with another thread that was talking a= bout "bulk response" because this issue is more than how to deal = with fragments of large responses. It has to do with the interactive nature= that the current NETCONF protocol does not seem to support. If it does not= , what are semantics needed to support these kind of commands.
--
Mahesh Jethanandani
mjethanandani@gmail.c= om
--001a1134b004b49dce050294c33d-- From nobody Mon Sep 8 14:59:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA74D1A03FA for ; Mon, 8 Sep 2014 14:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGOrZd8FWUn7 for ; Mon, 8 Sep 2014 14:58:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD901A03F6 for ; Mon, 8 Sep 2014 14:58:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 13DDB1339; Mon, 8 Sep 2014 23:58:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ziE_uN2Aq6cI; Mon, 8 Sep 2014 23:58:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Sep 2014 23:58:56 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C10320036; Mon, 8 Sep 2014 23:58:56 +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 ONzGlzYR3ZJr; Mon, 8 Sep 2014 23:58:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77D7020035; Mon, 8 Sep 2014 23:58:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 645C02E5E4EA; Mon, 8 Sep 2014 23:58:55 +0200 (CEST) Date: Mon, 8 Sep 2014 23:58:55 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20140908215855.GA95794@elstar.local> Mail-Followup-To: Mahesh Jethanandani , Netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/tLk35TwsgT7bGHe8cP476g_S6KM Cc: Netconf Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 21:59:03 -0000 On Mon, Sep 08, 2014 at 02:47:25PM -0700, Mahesh Jethanandani wrote: [...] > How does NETCONF deal with such a command? I would not confuse this with > another thread that was talking about "bulk response" because this issue is > more than how to deal with fragments of large responses. It has to do with > the interactive nature that the current NETCONF protocol does not seem to > support. If it does not, what are semantics needed to support these kind of > commands. I believe a proper solution should address both your requirement as well as the fragmentation requirement discussed in the other thread and I also think a proper solution needs support from the messages layer so that we do not have to hand-craft solutions for an increasing number of RPCs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 8 15:03:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069FC1A03E7 for ; Mon, 8 Sep 2014 15:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS3VpF3cysdc for ; Mon, 8 Sep 2014 15:03:36 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9AD1A038C for ; Mon, 8 Sep 2014 15:03:36 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id x13so3184131qcv.41 for ; Mon, 08 Sep 2014 15:03:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UftruvM7oDDN2e9rcw2QUkpokQqSnxKwKOFs1JiHdlU=; b=kSRtNki96qdWhkZC1PtHQtXTzrNqme6ePeVwpIR2HAi+3v6dzrk9lFioDAqzG1rFQT 6HVYAcLJPsZ+zKqsgzuZP9DT18x37Vgc684+0yLDYuH3fI6yzg5k3rhy8XtjuheM4q0U j81hBIz6UDK+SYD5Ey09ymMeZChkPMGjzXHsNp4zBg2dGOHbX2s2zGaYXkXvz0NcGUy8 A5RqK5NFgJ+esaYuAtPGb+iMsgMDvxeDElYuqksqdIcOUVm6dtSz/gfcU24sNIqh6vGa LQB1R4tqkl7zFmIDjy3gxpK7EmbeYXAgtAr1KV4UCm0xqqLMZg69y3WRb963ULwIJeFB C6pA== X-Gm-Message-State: ALoCoQnAQI3OenJPlJvO4L7P4gJbGGwL7tMDwM3lLY2MtXYrMXQTVWiZ67m2q/qVvvOpmZulz9Ry MIME-Version: 1.0 X-Received: by 10.140.98.7 with SMTP id n7mr44399972qge.83.1410213815673; Mon, 08 Sep 2014 15:03:35 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 8 Sep 2014 15:03:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Sep 2014 15:03:35 -0700 Message-ID: From: Andy Bierman To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=001a113ac3c68a8ef2050294fd89 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/35OUNkqoQ50AXGWQ1hLJe88qpDA Cc: Netconf Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 22:03:40 -0000 --001a113ac3c68a8ef2050294fd89 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 8, 2014 at 2:47 PM, Mahesh Jethanandani wrote: > I was asked to fashion a problem statement around how NETCONF deals with > what I call "interactive CLI" models. > > That model includes commands that are today issued on a CLI and involve a > command being issued, and a continuous response coming back till such time > it is interrupted either by the CLI or because there is a terminating > condition. In the period that the command is running, the CLI may be > blocked from issuing any other commands. > > Commands issued like these are fairly common debug commands issued as part > of testing the configuration on the box and are unlike getting statistics > which are not interactive in nature. > > A very common example of this is the ping command. Other examples include > traceroute command. A successful ping would have a response like this. > > > ping google.com > PING google.com (74.125.239.98) 56(84) bytes of data. > 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=1 ttl=55 > time=4.38 ms > 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=2 ttl=55 > time=4.26 ms > 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3 ttl=55 > time=4.38 ms > > --- google.com ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms > rtt min/avg/max/mdev = 4.260/4.343/4.389/0.096 ms > > Here also the response is split in two parts, one that is interactive > response which spits out one line at a time as the ping reply comes back > and the second which for the lack of a better term a "terminating response" > - a cumulative response of the complete interaction, prompted by the > issuance of a terminating condition i.e. CTRL-C or TTL expiry. > > In the case ping fails, there is no interactive response, but there is a > terminating response like in this case. > > > ping pyramid.com > PING pyramid.com (109.228.17.0) 56(84) bytes of data. > > --- pyramid.com ping statistics --- > 7 packets transmitted, 0 received, 100% packet loss, time 5999ms > > Without getting into specific implementation details, these commands today > would follow a pattern of > > > ... > > > > .... > > > > .... > > > > .... > > > > CTRL-C for the above NETCONF session > > > > .... > > > How does NETCONF deal with such a command? I would not confuse this with > another thread that was talking about "bulk response" because this issue is > more than how to deal with fragments of large responses. It has to do with > the interactive nature that the current NETCONF protocol does not seem to > support. If it does not, what are semantics needed to support these kind of > commands. > > NETCONF does not support multiple messages for the same . Once the client receives the first reply with a matching message-id, then it does not expect to receive more messages for the . NETCONF servers do not maintain state for an . There is no concept of "Control-C for the above NETCONF session". I think there are proposals already to do ping and traceroute in some module. IMO, updating the NETCONF protocol so it behaves more like a CLI is not a high priority. A YANG module to do ping or traceroute is good enough. It should use the available protocol mechanisms and not require a new protocol revision. Andy > -- > Mahesh Jethanandani > mjethanandani@gmail.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a113ac3c68a8ef2050294fd89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 8, 2014 at 2:47 PM, Mahesh Jethanandani &= lt;mjethananda= ni@gmail.com> wrote:
I was asked to fashion a problem statement around how NETCONF de= als with what I call "interactive CLI" models.

That model includes commands that are today issued on a CLI and involve a = command being issued, and a continuous response coming back till such time = it is interrupted either by the CLI or because there is a terminating condi= tion. In the period that the command is running, the CLI may be blocked fro= m issuing any other commands.

Commands issued like= these are fairly common debug commands issued as part of testing the confi= guration on the box and are unlike getting statistics which are not interac= tive in nature.

A very common example of this is t= he ping command. Other examples include traceroute command. A successful pi= ng would have a response like this.

=A0> p= ing google.com
PING google.com (74.1= 25.239.98) 56(84) bytes of data.
64 bytes from nuq05s01-in-f2.1e100.net (7= 4.125.239.98): icmp_req=3D1 ttl=3D55 time=3D4.38 ms
64 bytes from= nuq05s01-in-= f2.1e100.net (74.125.239.98): icmp_req=3D2 ttl=3D55 time=3D4.26 ms
64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D3 ttl=3D55 = time=3D4.38 ms

--- google.com ping statistics ---
3 packet= s transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/av= g/max/mdev =3D 4.260/4.343/4.389/0.096 ms

He= re also the response is split in two parts, one that is interactive respons= e which spits out one line at a time as the ping reply comes back and the s= econd which for the lack of a better term a "terminating response"= ; - a cumulative response of the complete interaction, prompted by the issu= ance of a terminating condition i.e. CTRL-C or TTL expiry.

In the case ping fails, there is no interactive response, but ther= e is a terminating response like in this case.

=A0> ping pyramid.com=
PING pyrami= d.com (109.228.17.0) 56(84) bytes of data.





<= /blockquote>

NETCONF does not support multiple <rpc-r= eply> messages for the same <rpc>.
Once the client recei= ves the first reply with a matching message-id, then it does
not = expect to receive more messages for the <rpc>.

NETCONF servers do not maintain state for an <rpc>.

--001a113ac3c68a8ef2050294fd89-- From nobody Mon Sep 8 15:31:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841701A0463 for ; Mon, 8 Sep 2014 15:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpmGkS4jTwnN for ; Mon, 8 Sep 2014 15:30:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11081A045F for ; Mon, 8 Sep 2014 15:30:58 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Mon, 8 Sep 2014 22:30:35 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.106]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.1019.015; Mon, 8 Sep 2014 22:30:35 +0000 From: Kent Watsen To: Mahesh Jethanandani , Netconf Thread-Topic: [Netconf] NETCONF and interactive CLI's Thread-Index: AQHPy66A+GmVN8OnL065iUOObq41Bpv3jpiA Date: Mon, 8 Sep 2014 22:30:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03283976A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019018)(6009001)(189002)(377454003)(76104003)(199003)(83506001)(81542001)(81342001)(105586002)(106116001)(74662001)(74502001)(80022001)(15202345003)(15975445006)(97736003)(19580405001)(101416001)(2656002)(83322001)(99396002)(87936001)(20776003)(36756003)(66066001)(4396001)(77096002)(77982001)(95666004)(99286002)(107046002)(107886001)(83072002)(85852003)(19580395003)(21056001)(76176999)(54356999)(76482001)(85306004)(31966008)(106356001)(50986999)(46102001)(86362001)(92566001)(90102001)(92726001)(64706001)(79102001)(16940595002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/n-O_F2MFoCTZEAAUDzGM9hndWXE Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 22:31:01 -0000 I'm sure others have their opinions, but to me this follows the pattern of a long-running request, whereby I'd expect a general mechanism to query/cancel currently running tasks, something like this: 23424 // listing of all currently running tasks 23424 1 23 55 admin ping foobar.com ... 23424 // details on this one task 1 23 55 admin ping foobar.com 64 bytes from foobar.com (11.222.333.44): icmp_req=3D1 ttl=3D55 time=3D4= .38 ms 23424 23424 // details on this one task task id does not exist =20 Just an idea, what do you think? Kent From: Mahesh Jethanandani Date: Monday, September 8, 2014 at 5:47 PM To: NetConf Subject: [Netconf] NETCONF and interactive CLI's I was asked to fashion a problem statement around how NETCONF deals with what I call "interactive CLI" models. That model includes commands that are today issued on a CLI and involve a command being issued, and a continuous response coming back till such time it is interrupted either by the CLI or because there is a terminating condition. In the period that the command is running, the CLI may be blocked from issuing any other commands. Commands issued like these are fairly common debug commands issued as part of testing the configuration on the box and are unlike getting statistics which are not interactive in nature. A very common example of this is the ping command. Other examples include traceroute command. A successful ping would have a response like this. > ping google.com PING google.com (74.125.239.98) 56(84) bytes of data. 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D1 ttl=3D55 time=3D4.38 ms 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D2 ttl=3D55 time=3D4.26 ms 64 bytes from nuq05s01-in-f2.1e100.net (74.125.239.98): icmp_req=3D3 ttl=3D55 time=3D4.38 ms --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev =3D 4.260/4.343/4.389/0.096 ms Here also the response is split in two parts, one that is interactive response which spits out one line at a time as the ping reply comes back and the second which for the lack of a better term a "terminating response" - a cumulative response of the complete interaction, prompted by the issuance of a terminating condition i.e. CTRL-C or TTL expiry. In the case ping fails, there is no interactive response, but there is a terminating response like in this case. > ping pyramid.com PING pyramid.com (109.228.17.0) 56(84) bytes of data. =03 --- pyramid.com ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 5999ms Without getting into specific implementation details, these commands today would follow a pattern of ... ....=20 .... .... CTRL-C for the above NETCONF session .... How does NETCONF deal with such a command? I would not confuse this with another thread that was talking about "bulk response" because this issue is more than how to deal with fragments of large responses. It has to do with the interactive nature that the current NETCONF protocol does not seem to support. If it does not, what are semantics needed to support these kind of commands. --=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Sep 8 15:41:46 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B151A1A04AC for ; Mon, 8 Sep 2014 15:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w3v1ZzPjlK3 for ; Mon, 8 Sep 2014 15:41:40 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1181A04A4 for ; Mon, 8 Sep 2014 15:41:39 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cm18so14776249qab.16 for ; Mon, 08 Sep 2014 15:41:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wAh+GOeWbkK5a5Hq3Q0SNAEPGICr7sDExK+YGnQqBIg=; b=i0dDGcFkSfwpqKupTaQmcNhnnbNKuXbKgePrxp3EECFjpPk8n/uNPU6TXnXCKFrWJE s9bojOlRtM0pFmdBEbQN6TBnBq+uzoispprf4djgJ8aiOkao9iqzfruQiKeUhBbyZ28P 1xzT3Oag9ufEBrqAynpCxp6UsPEjFrfOVVL2oyY1loVLsuaeuzS69Ta/9Ex8Kk/GzML4 RlCWayb6vq/LA9ps/YpOYfy9+t8ugF6TtlIBVn/TFAJveXg7qDymW2mA+elGUp7s8HqJ H6lk1wrZCwAa4lMtfC9T3/3ZDBjyTl1Slh91OaiKCiBrTmF7FECIhyNUesaH/8MnPmcT uMPw== X-Gm-Message-State: ALoCoQkMxZJlkxGCtZ/zO/dbORmo09PoQ20DK7/QC/jvBsPrjGBl9l4L8mr4mU4uo6IwLgGygs3v MIME-Version: 1.0 X-Received: by 10.140.21.177 with SMTP id 46mr43987118qgl.90.1410216098816; Mon, 08 Sep 2014 15:41:38 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 8 Sep 2014 15:41:38 -0700 (PDT) In-Reply-To: <20140908215855.GA95794@elstar.local> References: <20140908215855.GA95794@elstar.local> Date: Mon, 8 Sep 2014 15:41:38 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Mahesh Jethanandani , Netconf Content-Type: multipart/alternative; boundary=001a11c13986a09ef7050295851b Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/U0DxD-R7tlOZzbCS_HMvKKh7AiI Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 22:41:42 -0000 --001a11c13986a09ef7050295851b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 8, 2014 at 2:58 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Sep 08, 2014 at 02:47:25PM -0700, Mahesh Jethanandani wrote: > > [...] > > > How does NETCONF deal with such a command? I would not confuse this with > > another thread that was talking about "bulk response" because this issue > is > > more than how to deal with fragments of large responses. It has to do > with > > the interactive nature that the current NETCONF protocol does not seem to > > support. If it does not, what are semantics needed to support these kind > of > > commands. > > I believe a proper solution should address both your requirement as > well as the fragmentation requirement discussed in the other thread > and I also think a proper solution needs support from the messages > layer so that we do not have to hand-craft solutions for an increasing > number of RPCs. > I think a generic approach could be done with existing mechanisms. The YANG would need 'anyxml' but we are used to that. rpc start-command { input { anyxml request; } output { leaf handle { mandatory true; type string; } } } rpc terminate-command { input { leaf handle { mandatory true; type string; } } } notification command-data { leaf handle { mandatory true; type string; } leaf is-last { type boolean; default false; } leaf data-id { type string; } anyxml data; } Example: .... returns handle XJE43 notifications follow: XJE43 1 .... XJE43 true 2 .... Termination via handle: XJE43 > > /js > Andy > > -- > 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 > --001a11c13986a09ef7050295851b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 8, 2014 at 2:58 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Sep 08, 2014 at 02:47:25PM -0700, Mahesh Jethanandani wrote= :

[...]

> How does NETCONF deal with such a command? I would not confuse this wi= th
> another thread that was talking about "bulk response" becaus= e this issue is
> more than how to deal with fragments of large responses. It has to do = with
> the interactive nature that the current NETCONF protocol does not seem= to
> support. If it does not, what are semantics needed to support these ki= nd of
> commands.

I believe a proper solution should address both your requirement as
well as the fragmentation requirement discussed in the other thread
and I also think a proper solution needs support from the messages
layer so that we do not have to hand-craft solutions for an increasing
number of RPCs.

I think a generic appro= ach could be done with existing mechanisms.
The YANG would need &= #39;anyxml' but we are used to that.

=A0 rpc s= tart-command {
=A0 =A0 =A0input {
=A0 =A0 =A0 =A0 =A0an= yxml request;
=A0 =A0 =A0}
=A0 =A0 =A0output {
=A0 =A0 =A0 =A0 =A0leaf handle {=A0
=A0 =A0 =A0 =A0 =A0 =A0 man= datory true;
=A0 =A0 =A0 =A0 =A0 =A0 type string;
=A0 = =A0 =A0 =A0 =A0}
=A0 =A0 =A0}
=A0 }

=A0 rpc terminate-command {
=A0 =A0 =A0input {
=A0 =A0 =A0 =A0 leaf handle {
=A0 =A0 =A0 =A0 =A0 =A0 mandator= y true;
=A0 =A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 = =A0 =A0 }
=A0 =A0 =A0}
=A0 }

=
=A0 notification command-data {
=A0 =A0 =A0 =A0leaf handle {= =A0
=A0 =A0 =A0 =A0 =A0 mandatory true;
=A0 =A0 =A0 =A0= =A0 type string;
=A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0= leaf is-last {
=A0 =A0 =A0 =A0 =A0 type boolean;
=A0 = =A0 =A0 =A0 =A0 default false;
=A0 =A0 =A0 =A0}
<= div>=A0 =A0 =A0 =A0leaf data-id {=A0
=A0 =A0 =A0 =A0 =A0 type str= ing;
=A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0anyxml data;=
=A0 }

Example:

=A0 <start-command>
=A0 =A0 =A0 <request>
= =A0 =A0 =A0 =A0 <ping>
=A0 =A0 =A0 =A0 =A0 =A0....
=A0 =A0 =A0 =A0 =A0</ping>
=A0 =A0 =A0 =A0</request>= ;
=A0 =A0</start-command>

returns = handle XJE43

notifications follow:

<= /div>
=A0 <command-data>
=A0 =A0 =A0 <handle>= ;XJE43</handle>
=A0 =A0 =A0 <data-id>1</data-id>= ;
=A0 =A0 =A0 <data>
=A0 =A0 =A0 =A0 =A0 ....
=A0 =A0 =A0 </data>
=A0 =A0</command-data>
=A0=A0
=A0 <command-data>
= =A0 =A0 =A0 <handle>XJE43</handle>
=A0 =A0 =A0 <is= -last>true</is-last>
=A0 =A0 =A0 <data-id>2<= ;/data-id>
=A0 =A0 =A0 <data>
=A0 =A0 =A0 =A0 = =A0 ....
=A0 =A0 =A0 </data>
=A0 =A0</command-= data>

Termination via handle:
<= br>
=A0<terminate-command >
=A0 =A0 =A0 <= handle>XJE43</handle>
=A0 =A0</terminate-command><= /div>
=A0=A0

/js

Andy

=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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

--001a11c13986a09ef7050295851b-- From nobody Mon Sep 8 16:54:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1D41A038F for ; Mon, 8 Sep 2014 16:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0MHXhFjN9k9 for ; Mon, 8 Sep 2014 16:53:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD911A034B for ; Mon, 8 Sep 2014 16:53:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8A99B18F5; Tue, 9 Sep 2014 01:53:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6seBvAXNUxM7; Tue, 9 Sep 2014 01:53:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 9 Sep 2014 01:53:55 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56E1920036; Tue, 9 Sep 2014 01:53:55 +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 5Bh4Kj5-ucP6; Tue, 9 Sep 2014 01:53:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 938C420035; Tue, 9 Sep 2014 01:53:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E1E542E5E639; Tue, 9 Sep 2014 01:53:52 +0200 (CEST) Date: Tue, 9 Sep 2014 01:53:52 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140908235352.GA95999@elstar.local> Mail-Followup-To: Andy Bierman , Mahesh Jethanandani , Netconf References: <20140908215855.GA95794@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/KMEHvTxbtdlRycer_nwmk69g4_0 Cc: Netconf Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 23:53:59 -0000 On Mon, Sep 08, 2014 at 03:41:38PM -0700, Andy Bierman wrote: > > I think a generic approach could be done with existing mechanisms. > The YANG would need 'anyxml' but we are used to that. > > rpc start-command { > input { > anyxml request; > } > output { > leaf handle { > mandatory true; > type string; > } > } > } > > rpc terminate-command { > input { > leaf handle { > mandatory true; > type string; > } > } > } > > notification command-data { > leaf handle { > mandatory true; > type string; > } > leaf is-last { > type boolean; > default false; > } > leaf data-id { > type string; > } > anyxml data; > } > > Example: > > > > > .... > > > > > returns handle XJE43 > > notifications follow: > > > XJE43 > 1 > > .... > > > > > XJE43 > true > 2 > > .... > > > > Termination via handle: > > > XJE43 > How do you define the 'commands' in YANG? Why are they not simply RPCs? You left out the detail that notifications require a notification subscription. Do you require :interleave? I guess you have to. Changing the message layer to support multiple responses to an RPC invocation and providing a cancel mechanism at the RPC layer is relatively simple and fixes the problem where it is rather than adding a new protocol layer on top of RPCs and notifications. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 8 18:11:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC021A0348 for ; Mon, 8 Sep 2014 18:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JijHi0iqr5ar for ; Mon, 8 Sep 2014 18:11:38 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1171A031C for ; Mon, 8 Sep 2014 18:11:38 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so3144680qac.32 for ; Mon, 08 Sep 2014 18:11:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BwhkzKzV2wr6OHUReHMlOsqmkQdYA5bQS6LMbfUt+tE=; b=A2SyBFkrICS17yzWwaco2JqlKtc4kLq4ZR+jcNGVUDs4ozWVgU2+v70uewxBd1Pb8d oN0wEXw24YPy9nDo1Xrjz0z6gAIf/Kdq/FMPkuNB56x2Rvl+8SCN+xylBZE5AKiIqEko NFscluiMc5hiy6FHshOfy7M6twokcwAMDLghyhdhjp/TRHt+ru2frdR0ln5C2lGgsMu3 ybrrTkGCLDQnuR65i/gpzJYG9a22/2U7dD+8ExPU/C1cl4yt2ZD3GR1H/klj41ZxW0cb cR+PV0wM17NWjQDVF5B+x/ffdjS2TdOQyfvevdO3pSRxivrZDWobO0pRvt85YCsOXzig wQdw== X-Gm-Message-State: ALoCoQmZEkeRb3ZwaSigauWPYYSW/uepUx6rai7vIEc8LZ/HUuBP0EThSpgA6Wh/+W6u2VI06lXf MIME-Version: 1.0 X-Received: by 10.140.40.179 with SMTP id x48mr29113955qgx.36.1410225097648; Mon, 08 Sep 2014 18:11:37 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 8 Sep 2014 18:11:37 -0700 (PDT) In-Reply-To: <20140908235352.GA95999@elstar.local> References: <20140908215855.GA95794@elstar.local> <20140908235352.GA95999@elstar.local> Date: Mon, 8 Sep 2014 18:11:37 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Mahesh Jethanandani , Netconf Content-Type: multipart/alternative; boundary=001a11c12da2ffc6e00502979dbd Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/R3PqY5b0AusnsQGjxwu4VKNQ-FA Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 01:11:40 -0000 --001a11c12da2ffc6e00502979dbd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 8, 2014 at 4:53 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Sep 08, 2014 at 03:41:38PM -0700, Andy Bierman wrote: > > > > I think a generic approach could be done with existing mechanisms. > > The YANG would need 'anyxml' but we are used to that. > > > > rpc start-command { > > input { > > anyxml request; > > } > > output { > > leaf handle { > > mandatory true; > > type string; > > } > > } > > } > > > > rpc terminate-command { > > input { > > leaf handle { > > mandatory true; > > type string; > > } > > } > > } > > > > notification command-data { > > leaf handle { > > mandatory true; > > type string; > > } > > leaf is-last { > > type boolean; > > default false; > > } > > leaf data-id { > > type string; > > } > > anyxml data; > > } > > > > Example: > > > > > > > > > > .... > > > > > > > > > > returns handle XJE43 > > > > notifications follow: > > > > > > XJE43 > > 1 > > > > .... > > > > > > > > > > XJE43 > > true > > 2 > > > > .... > > > > > > > > Termination via handle: > > > > > > XJE43 > > > > How do you define the 'commands' in YANG? Why are they not simply > RPCs? You left out the detail that notifications require a > notification subscription. Do you require :interleave? I guess you > have to. > > Changing the message layer to support multiple responses to an RPC > invocation and providing a cancel mechanism at the RPC layer is > relatively simple and fixes the problem where it is rather than adding > a new protocol layer on top of RPCs and notifications. > > That solution requires a new version of NETCONF. Next time we update the protocol, then changes to the layer can be made. I was trying to suggest a solution that uses the existing protocol. Maybe this can be done with an optional capability, but if even 1 sentence in RFC 6241 says is handled a specific way that does not include the proposed changes, then a capability will not work. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c12da2ffc6e00502979dbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 8, 2014 at 4:53 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Sep 08, 2014 at 03:41:38PM -0700, Andy Bierma= n wrote:
>
> I think a generic approach could be done with existing mechanisms.
> The YANG would need 'anyxml' but we are used to that.
>
>=A0 =A0rpc start-command {
>=A0 =A0 =A0 input {
>=A0 =A0 =A0 =A0 =A0 anyxml request;
>=A0 =A0 =A0 }
>=A0 =A0 =A0 output {
>=A0 =A0 =A0 =A0 =A0 leaf handle {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0mandatory true;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
>=A0 =A0 =A0 =A0 =A0 }
>=A0 =A0 =A0 }
>=A0 =A0}
>
>=A0 =A0rpc terminate-command {
>=A0 =A0 =A0 input {
>=A0 =A0 =A0 =A0 =A0leaf handle {
>=A0 =A0 =A0 =A0 =A0 =A0 =A0mandatory true;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
>=A0 =A0 =A0 =A0 =A0}
>=A0 =A0 =A0 }
>=A0 =A0}
>
>=A0 =A0notification command-data {
>=A0 =A0 =A0 =A0 leaf handle {
>=A0 =A0 =A0 =A0 =A0 =A0mandatory true;
>=A0 =A0 =A0 =A0 =A0 =A0type string;
>=A0 =A0 =A0 =A0 }
>=A0 =A0 =A0 =A0 leaf is-last {
>=A0 =A0 =A0 =A0 =A0 =A0type boolean;
>=A0 =A0 =A0 =A0 =A0 =A0default false;
>=A0 =A0 =A0 =A0 }
>=A0 =A0 =A0 =A0 leaf data-id {
>=A0 =A0 =A0 =A0 =A0 =A0type string;
>=A0 =A0 =A0 =A0 }
>=A0 =A0 =A0 =A0 anyxml data;
>=A0 =A0}
>
> Example:
>
>=A0 =A0<start-command>
>=A0 =A0 =A0 =A0<request>
>=A0 =A0 =A0 =A0 =A0<ping>
>=A0 =A0 =A0 =A0 =A0 =A0 ....
>=A0 =A0 =A0 =A0 =A0 </ping>
>=A0 =A0 =A0 =A0 </request>
>=A0 =A0 </start-command>
>
> returns handle XJE43
>
> notifications follow:
>
>=A0 =A0<command-data>
>=A0 =A0 =A0 =A0<handle>XJE43</handle>
>=A0 =A0 =A0 =A0<data-id>1</data-id>
>=A0 =A0 =A0 =A0<data>
>=A0 =A0 =A0 =A0 =A0 =A0....
>=A0 =A0 =A0 =A0</data>
>=A0 =A0 </command-data>
>
>=A0 =A0<command-data>
>=A0 =A0 =A0 =A0<handle>XJE43</handle>
>=A0 =A0 =A0 =A0<is-last>true</is-last>
>=A0 =A0 =A0 =A0<data-id>2</data-id>
>=A0 =A0 =A0 =A0<data>
>=A0 =A0 =A0 =A0 =A0 =A0....
>=A0 =A0 =A0 =A0</data>
>=A0 =A0 </command-data>
>
> Termination via handle:
>
>=A0 <terminate-command >
>=A0 =A0 =A0 =A0<handle>XJE43</handle>
>=A0 =A0 </terminate-command>

How do you define the 'commands' in YANG? Why are they not simply RPCs? You left out the detail that notifications require a
notification subscription. Do you require :interleave? I guess you
have to.

Changing the message layer to support multiple responses to an RPC
invocation and providing a cancel mechanism at the RPC layer is
relatively simple and fixes the problem where it is rather than adding
a new protocol layer on top of RPCs and notifications.


That solution requires a new version of NETCONF.
Next time we update the protocol, then changes to the <rpc> la= yer can be made.
I was trying to suggest a solution that uses the= existing protocol.
Maybe this can be done with an optional capab= ility,
but if even 1 sentence in RFC 6241 says <rpc> is han= dled a specific way
that does not include the proposed changes, t= hen a capability will not work.

=A0
/js

Andy
=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c12da2ffc6e00502979dbd-- From nobody Mon Sep 8 22:41:46 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A3F1A0860 for ; Mon, 8 Sep 2014 22:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wan1lXRJp2W6 for ; Mon, 8 Sep 2014 22:41:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72DAC1A0792 for ; Mon, 8 Sep 2014 22:41:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DDB831A78; Tue, 9 Sep 2014 07:41:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 248SUJd0nAfa; Tue, 9 Sep 2014 07:41:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 9 Sep 2014 07:41:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0ED4520036; Tue, 9 Sep 2014 07:41: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 LHKT_BXBbNNM; Tue, 9 Sep 2014 07:41:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABC2320035; Tue, 9 Sep 2014 07:41:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 15A762E5E869; Tue, 9 Sep 2014 07:41:35 +0200 (CEST) Date: Tue, 9 Sep 2014 07:41:35 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140909054135.GA96517@elstar.local> Mail-Followup-To: Andy Bierman , Mahesh Jethanandani , Netconf References: <20140908215855.GA95794@elstar.local> <20140908235352.GA95999@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2Vucq_LzxscsYvWnwfB89U9rEVo Cc: Netconf Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 05:41:43 -0000 On Mon, Sep 08, 2014 at 06:11:37PM -0700, Andy Bierman wrote: > On Mon, Sep 8, 2014 at 4:53 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Sep 08, 2014 at 03:41:38PM -0700, Andy Bierman wrote: > > > > > > I think a generic approach could be done with existing mechanisms. > > > The YANG would need 'anyxml' but we are used to that. > > > > > > rpc start-command { > > > input { > > > anyxml request; > > > } > > > output { > > > leaf handle { > > > mandatory true; > > > type string; > > > } > > > } > > > } > > > > > > rpc terminate-command { > > > input { > > > leaf handle { > > > mandatory true; > > > type string; > > > } > > > } > > > } > > > > > > notification command-data { > > > leaf handle { > > > mandatory true; > > > type string; > > > } > > > leaf is-last { > > > type boolean; > > > default false; > > > } > > > leaf data-id { > > > type string; > > > } > > > anyxml data; > > > } > > > > > > Example: > > > > > > > > > > > > > > > .... > > > > > > > > > > > > > > > returns handle XJE43 > > > > > > notifications follow: > > > > > > > > > XJE43 > > > 1 > > > > > > .... > > > > > > > > > > > > > > > XJE43 > > > true > > > 2 > > > > > > .... > > > > > > > > > > > > Termination via handle: > > > > > > > > > XJE43 > > > > > > > How do you define the 'commands' in YANG? Why are they not simply > > RPCs? You left out the detail that notifications require a > > notification subscription. Do you require :interleave? I guess you > > have to. > > > > Changing the message layer to support multiple responses to an RPC > > invocation and providing a cancel mechanism at the RPC layer is > > relatively simple and fixes the problem where it is rather than adding > > a new protocol layer on top of RPCs and notifications. > > > That solution requires a new version of NETCONF. > Next time we update the protocol, then changes to the layer can be > made. > I was trying to suggest a solution that uses the existing protocol. > Maybe this can be done with an optional capability, > but if even 1 sentence in RFC 6241 says is handled a specific way > that does not include the proposed changes, then a capability will not work. Yes. I also always thought a proper solution requires a revision of RFC 6241. I just now tried to search in RFC 6241 where it actually says that multiple messages with the same message-id is an error. I did not find anything that makes a clear statements. So perhaps an update of RFC 6241 could even work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 8 23:31:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358521A0AF2 for ; Mon, 8 Sep 2014 23:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE4gGqmRVGz0 for ; Mon, 8 Sep 2014 23:31:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 48C591A0B03 for ; Mon, 8 Sep 2014 23:31:08 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id AE1EC1280402; Tue, 9 Sep 2014 08:31:05 +0200 (CEST) Date: Tue, 09 Sep 2014 08:31:05 +0200 (CEST) Message-Id: <20140909.083105.946657420905938182.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140909054135.GA96517@elstar.local> References: <20140908235352.GA95999@elstar.local> <20140909054135.GA96517@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/k3_l96pZpRaCdVnT3I9RDcnlyfo Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 06:31:10 -0000 Juergen Schoenwaelder wrote: > On Mon, Sep 08, 2014 at 06:11:37PM -0700, Andy Bierman wrote: > > On Mon, Sep 8, 2014 at 4:53 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Mon, Sep 08, 2014 at 03:41:38PM -0700, Andy Bierman wrote: > > That solution requires a new version of NETCONF. > > Next time we update the protocol, then changes to the layer can be > > made. > > I was trying to suggest a solution that uses the existing protocol. > > Maybe this can be done with an optional capability, > > but if even 1 sentence in RFC 6241 says is handled a specific way > > that does not include the proposed changes, then a capability will not work. > > Yes. I also always thought a proper solution requires a revision of > RFC 6241. I just now tried to search in RFC 6241 where it actually > says that multiple messages with the same message-id is an > error. I did not find anything that makes a clear statements. So > perhaps an update of RFC 6241 could even work. Even if this was doable, it is still not possible to make the server process a new rpc like "" while it is sending the rpc-replies. /martin From nobody Mon Sep 8 23:38:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981241A0B0E for ; Mon, 8 Sep 2014 23:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfwtyBFow9vh for ; Mon, 8 Sep 2014 23:38:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 56F281A0B0B for ; Mon, 8 Sep 2014 23:38:54 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 965B31280402; Tue, 9 Sep 2014 08:38:53 +0200 (CEST) Date: Tue, 09 Sep 2014 08:38:53 +0200 (CEST) Message-Id: <20140909.083853.1378645628350562249.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PZgD-0xLYyqHR33auDTCBzPegn4 Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 06:38:55 -0000 Kent Watsen wrote: > > I'm sure others have their opinions, but to me this follows the pattern of > a long-running request, whereby I'd expect a general mechanism to > query/cancel currently running tasks, something like this: [...] On the call yesterday I suggested something similiar, but more direct: rpc start-ping-job { input { // ping parameters here... } output { leaf ping-job-handle { ... } } } rpc get-one-ping-result { input { leaf ping-job-handle { ... } } output { // ping result here } } rpc cancel-ping-job { input { leaf ping-job-handle { ... } } } The call sequence would be: start-ping-job ---> get-one-ping-result ---> get-one-ping-result ---> ... [cancel-ping-job ---> ok] Yes, this is not as elegant as built-in support, but it works today. Built-in support needs an updated protocol *and* updatad data modelling language. /martin From nobody Tue Sep 9 00:34:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804E61A0B75; Tue, 9 Sep 2014 00:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mF8kd6kOfdDJ; Tue, 9 Sep 2014 00:34:01 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9F71A0B72; Tue, 9 Sep 2014 00:34:01 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XRFw5-0005oL-Ci; Tue, 09 Sep 2014 09:33:58 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest108.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XRFw5-0001TQ-9P; Tue, 09 Sep 2014 09:33:57 +0200 Message-ID: <540EAD65.2010109@bwijnen.net> Date: Tue, 09 Sep 2014 09:33:57 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mahesh Jethanandani , ietf@ietf.org References: <20140820174629.27343.42011.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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] 0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal information X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e4bf921995dd514247a1deb0a1999bd6 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/RL28vNBRrZg9Gpdhm4Stgz1ckek Cc: Netconf , IETF Announcement List Subject: Re: [Netconf] NETCONF WG Bi-Weekly Virtual Interim Meetings beginning September 8, 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 07:34:03 -0000 So we did have the meeting yesterday (and I did see Mahesh present, so I guess he found out the correct time). To be clear, it is noted in CET time. During "summer" time that is 19:00 (Amsterdam, Berlin, Paris etc) and it is 17:00 UTC. Bert On 08/09/14 18:11, Mahesh Jethanandani wrote: > Is there a meeting today? WebEx says the meeting has not started. > > On Wed, Aug 20, 2014 at 10:46 AM, IESG Secretary > wrote: > > The NETCONF WG will have a series of bi-weekly virtual interim meetings. > The meetings will take place every other Monday from 1900-2100 CEST. > The first meeting will be on Monday, September 8, 2014, and the series > will end on Monday, November 2, 2014. > > ------------------------------------------------------- > Topic: NETCONF Bi-weekly Meeting > Date: Every 2 weeks on Monday, from Monday, September 8, 2014 to Monday, > November 3, 2014 > Time: 7:00 pm, Europe Summer Time (Berlin, GMT+02:00) > Meeting Number: 649 602 794 > Meeting Password: restconf > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/j.php?MTID=m3376a52e7a0e41672bed8e07d6c65d67 > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: restconf > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://ietf.webex.com/ietf/j.php?MTID=me875d958a9d772d851399d42e20ae8d4 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): 1-650-479-3208 > > Access code:649 602 794 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > netconf-chairs@tools.ietf.org > > > To update this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ietf.webex.com/ietf/j.php?MTID=m25825e3bf1347d5a34f89769b2cdcd01 > > > WebEx will automatically setup Meeting Manager for Windows the first > time you join a meeting. To save time, you can setup prior to the > meeting by clicking this link: > https://ietf.webex.com/ietf/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in > the meeting, please check whether you have the players installed on your > computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+16504793208x649602794# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > > -- > Mahesh Jethanandani > mjethanandani@gmail.com > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Sep 9 00:43:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B44F1A0B75 for ; Tue, 9 Sep 2014 00:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z85RqYtqBzPG for ; Tue, 9 Sep 2014 00:43:17 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B0B1A0B78 for ; Tue, 9 Sep 2014 00:43:16 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XRG52-0007Dc-F9; Tue, 09 Sep 2014 09:43:13 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest108.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XRG52-0002cH-8q; Tue, 09 Sep 2014 09:43:12 +0200 Message-ID: <540EAF90.1010601@bwijnen.net> Date: Tue, 09 Sep 2014 09:43:12 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Martin Bjorklund , kwatsen@juniper.net References: <20140909.083853.1378645628350562249.mbj@tail-f.com> In-Reply-To: <20140909.083853.1378645628350562249.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd4a3d2e3da1b7aec55ef5b421d8adb2dc5 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CQBVKi0ULkrIfZZkwjLhZqH8cvo Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 07:43:19 -0000 Interesting discussion. In my head I have his question: NETCONF was for Network CONFIGURATION So what do traceroute, ping and possibly other long running commands have to do with network configuration?? In my mind they seem to be debugging or monitoring tools. Bert (speaking as a contributor) On 09/09/14 08:38, Martin Bjorklund wrote: > Kent Watsen wrote: >> >> I'm sure others have their opinions, but to me this follows the pattern of >> a long-running request, whereby I'd expect a general mechanism to >> query/cancel currently running tasks, something like this: > > [...] > > On the call yesterday I suggested something similiar, but more direct: > > rpc start-ping-job { > input { > // ping parameters here... > } > output { > leaf ping-job-handle { ... } > } > } > > rpc get-one-ping-result { > input { > leaf ping-job-handle { ... } > } > output { > // ping result here > } > } > > rpc cancel-ping-job { > input { > leaf ping-job-handle { ... } > } > } > > The call sequence would be: > > start-ping-job ---> > get-one-ping-result ---> > get-one-ping-result ---> > ... > [cancel-ping-job ---> ok] > > > > Yes, this is not as elegant as built-in support, but it works today. > > > Built-in support needs an updated protocol *and* updatad data > modelling language. > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Sep 9 01:00:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CF01A1F73 for ; Tue, 9 Sep 2014 00:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.603 X-Spam-Level: X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpxKcTpF9sI9 for ; Tue, 9 Sep 2014 00:59:55 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F291A0B7D for ; Tue, 9 Sep 2014 00:59:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5CBC9A2; Tue, 9 Sep 2014 09:59:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1410249593; bh=xoZapj5K1a8QPWg011qYYekuCwvDbtGj2GSKLySUDxw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QY7SPb9CBb/pf2O+n66Zq5+5KHUU9nMvOrid8YOREBrNSq3N5DY5PvFaKfdGHtX2C Jjxd1V2aFKcdrmmGav2PUiHI53QyJlUxvrqLXuV5DWraTqYLSoQmhx+ViHj2ZZUXNz t4rOOk5HEWNu2kIBeqTtqYhtIelK55G+WdbLAJy4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 577B49F; Tue, 9 Sep 2014 09:59:53 +0200 (CEST) Date: Tue, 9 Sep 2014 09:59:53 +0200 (CEST) From: Mikael Abrahamsson To: "Bert Wijnen (IETF)" In-Reply-To: <540EAF90.1010601@bwijnen.net> Message-ID: References: <20140909.083853.1378645628350562249.mbj@tail-f.com> <540EAF90.1010601@bwijnen.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/EZGPyqX2dNidyq4RmXgX3LIRSPk Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 07:59:57 -0000 On Tue, 9 Sep 2014, Bert Wijnen (IETF) wrote: > Interesting discussion. > > In my head I have his question: > > NETCONF was for Network CONFIGURATION > > So what do traceroute, ping and possibly other long running commands > have to do with network configuration?? > > In my mind they seem to be debugging or monitoring tools. I want to stop using SNMP and CLI for network monitoring. What should I use? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 9 02:25:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5BA1A86E0 for ; Tue, 9 Sep 2014 02:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv8K8zhpyKgm for ; Tue, 9 Sep 2014 02:25:08 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712EB1A898C for ; Tue, 9 Sep 2014 02:25:08 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XRHfa-0007N5-PB for netconf@ietf.org; Tue, 09 Sep 2014 11:25:03 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest108.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XRHfa-0006no-LO for netconf@ietf.org; Tue, 09 Sep 2014 11:25:02 +0200 Message-ID: <540EC76E.4060706@bwijnen.net> Date: Tue, 09 Sep 2014 11:25:02 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Netconf References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> In-Reply-To: <54059AA9.4080902@bwijnen.net> Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd49441af2d69830ad895d957c0d54bf5c9 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8EhIVndveGw2QrHTefsYsADPC6Y Subject: [Netconf] Reminder: WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 09:25:10 -0000 I'd like to remind everyone that this WG last call ends on Sept 18. Several people have already expressed their opinion. If you want to be heard, pls speak up asap, certainly before Sept 18th. The WG chairs need your input and opinions to try and determine WG (rough) consensus on this topic. Bert On 02/09/14 12:23, Bert Wijnen (IETF) wrote: > On 26/08/14 22:49, Andy Bierman wrote: >> >> Perhaps the co-chairs should decide how to proceed somehow. > > Dear NETCONF WG participants, do you have an opinion? > > So far I have seen only a few people express their opinion. > > Please speak up so that we (WG chairs) have better data to judge if we > do or do not have WG (rough) consensus. Pls do speak up by 18 Sept 2014. > > Please speak your mind about these options: > > a) XML is mandatory > b) JSON is mandatory > c) XML and JSON are both mandatory > d) Both XML and JSON mandatory on client, > server can implement whatever it chooses. > Not clear yet how the client would find out, but that would of course > be something to be worked out if we choose this option > > Bert > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Sep 9 04:34:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1794B1A0046 for ; Tue, 9 Sep 2014 04:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGv1KV0P6YgY for ; Tue, 9 Sep 2014 04:34:10 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607C01A002F for ; Tue, 9 Sep 2014 04:34:09 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XRJgT-0004PF-Ru for netconf@ietf.org; Tue, 09 Sep 2014 13:34:07 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest108.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XRJgT-0003TT-PQ for netconf@ietf.org; Tue, 09 Sep 2014 13:34:05 +0200 Message-ID: <540EE5AD.9020306@bwijnen.net> Date: Tue, 09 Sep 2014 13:34:05 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Netconf References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd495be11ec30f67d491b5259d17d30f5c5 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0BV59i1x-P8J6b2uqrCprIyn910 Subject: [Netconf] draft minutes/notes of our Virtual Interim Meeting on 8 Sept 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 11:34:14 -0000 Dear WG participants, we had our first virtual interim meeting yesterday. here are the draft minutes (thanks to Kent for taking notes, amended/merged with my own notes): The meetings run from 8 Sept - 3 Nov 2014. Biweekly on Mondays from 7pm-9pm CET (Berlin, Amsterdam, Paris). That is 17:00-19:00 UTC. They are webex based meetings. We have decided last night to record the meetings. But the WG chair(s) will ensure at the start of every meeting that everyone is aware and that nobody objects. The recording of yesterdays meeting is here: - The main objective of the call is to help us (WG) move faster on our chartered work items. RESTCONF is a big piece of that. Whatever we want to decide must be verified on the WG mailing list. Of course some discussion end up in changes to a document, which will always be presented to the WG mailing list and which will eventually be Last Called, so everyone has a say. - We had 10 participants on the call - Kent presented GitHub, which is used to track issues and which also is used by various editors to work together on the documents * DECISION: We will NOT forward all changes in GITHUB to the WG mailing list. * Pull-requests for editorial changes are OK, * but more substantial issues (in fact all issues) should be discussed on our NETCONF WG mailing list. We can use github to keep track of the status and to record summaries, proposed solutions and the final resolution. - Andy presented RESTCONF issues see: https://github.com/netconf-wg/restconf/issues We discussed them in reverse order (will try to get them properly discussed in order next time). I (Bert) have added all issues, also those that were created new as a result o the virtual meeting and those that were not discussed. If you want to comment or voice an opinion on any issue (that would be VERY GOOD and HELPFUL), then pls set the subject line to the issue number plus issue title. * issue # 10: Naming convention for Query Parameters o opened by Bert as a result of our first virual meeting o split ioff from issue # 6 * issue # 9: Define how authentication is performed o opened by Andy as a result of our first virtual meeting * issue #7: Mandatory-to-implement encoding o WG chairs did a poll on the WG list for opinions: see: http://www.ietf.org/mail-archive/web/netconf/current/msg09218.html It runs till Sept 18, so those who have not expressed an opinion yet are encouraged to do so. o For now, "Optional" encoding (choice d) got more votes than "XML mandatory" (choice a). o Martin mentions technical motivations were expressed with choice 'a' o Bert reminded that STANDARDIZATION means making choices and making interoperability easy. From that point of view, choice a seems more appropriate. o ACTION: Bert will send reminder to collect more opinions (done) * issue #6: how to identify query parameters supported by the server o No prefix for ietf-defined (this is naming, see new issue #10) o We basically have 2 issues, one is Naming,the other is discovery of which parameters are supported by the server. So issue #6 stays as is, issue #10 opened by Bert for Naming conventions o Capability encoding in the air: Lada is thinking a json object o Proposal to collapse into a single URI string o Opinions of other WG participants are welcome! Please speak up * issue #5: protocol capability URIs o was not discussed on this call o Toronto consensus: Add protocol capabilities somehow o so we need to see new text in a revision of the draft *issue #4: Defaults handling o Mapping to RESTCONF straight forward o the server MUST report what basic-mode it supports o Question: Should full support of with-defaults RFC be added to base RESTCONF? Please speak up and express opinions? * issue #3: add collection resource o Put collections media-type and query-parameters into main draft, but? o There seems to be consensus to put collections resource in another document. o Need to deal with GET on a list with no keys given: GET /restconf/data/interfaces/interface --> Maybe this will be an error unless collection resource requested o Need text proposals on mailing list. * issue #2 Netconf state monitoring o Need to create an issue for authentication (done by Andy, that is issue #9 o Do we need to have a 6022-bis document or can RESTCONF just update the text in order to support non-NETCONF sessions. o An idea is to let this doc "update" RFC 6022 * issue #1: Select parameter o What syntax should be used for the "select" query parameter? The current choices are "XPath" and "path-expr". Perhaps an additional parameter to identify the select string format is needed to allow extensibility? o Martin's proposal stands...issue seems closed o WG participants, please speak up if you cannot live with Martin's proposal, see https://github.com/netconf-wg/restconf/issues/1 - A question was raised by Mahesh, regarding CLI type uses as ping and traceroute. He was asked to post the problem statement to the WG list, which he has done now see: http://www.ietf.org/mail-archive/web/netconf/current/msg09254.html - Next time we will discuss restconf issues again, but also: call-home. It seems like a good idea to then have the accompanying documents updated as well, so: o ACTION: Juergen should update 5539bis 0 ACTION: Kent to submit server-model Bert Wijnen, with special thanks to Kent and Andy. From nobody Tue Sep 9 04:44:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651A31A004E for ; Tue, 9 Sep 2014 04:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcIjyrm3Px4C for ; Tue, 9 Sep 2014 04:44:48 -0700 (PDT) Received: from rock.dronejett.com (unknown [192.157.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id F2E431A0052 for ; Tue, 9 Sep 2014 04:44:47 -0700 (PDT) Received: from [80.157.8.200] (unknown [80.157.8.200]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rock.dronejett.com (Postfix) with ESMTPSA id DE8F95F1; Tue, 9 Sep 2014 07:44:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Bannister In-Reply-To: <20140909.083853.1378645628350562249.mbj@tail-f.com> Date: Tue, 9 Sep 2014 07:46:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <57489B51-C5E0-4D78-881E-76640B10085D@mojo.net> References: <20140909.083853.1378645628350562249.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UjeevcDtFHuHR2_ZL1NxqB8pkyU Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 11:44:49 -0000 On Sep 9, 2014, at 2:38 AM, Martin Bjorklund wrote: > Kent Watsen wrote: >>=20 >> I'm sure others have their opinions, but to me this follows the = pattern of >> a long-running request, whereby I'd expect a general mechanism to >> query/cancel currently running tasks, something like this: >=20 > [...] >=20 > On the call yesterday I suggested something similiar, but more direct: >=20 > rpc start-ping-job { > input { > // ping parameters here... > } > output { > leaf ping-job-handle { ... } > } > } >=20 > rpc get-one-ping-result { > input { > leaf ping-job-handle { ... } > } > output { > // ping result here > } > } =20 >=20 > rpc cancel-ping-job { > input { > leaf ping-job-handle { ... } > } > } >=20 > The call sequence would be: >=20 > start-ping-job ---> > get-one-ping-result ---> > get-one-ping-result ---> > ... > [cancel-ping-job ---> ok] >=20 >=20 >=20 > Yes, this is not as elegant as built-in support, but it works today. That would kind of work. What you are suggesting is highly = transactional in nature which means one of two things. There is a human = at the other end watching dots & bangs form on the screen in a blocking = state until he/she sends the cancel request. Or, a process at the other = end sending a large number of micro-rpc messages waiting for some event = or group of events to happen before sending the cancel rpc. My goal is = to eliminate the first and hopefully avoid the second. I would lean = towards an approach that uses a model to define the monitoring or = testing action bounding it by time, failure conditions, etc. Also = contained in that model is an identifier, a single use crypto key or = nonce, a transport method and a destination host(s) etc. Once the = network element completes the test it forwards the results to host(s) = responsible for analysis. This approach also allows me to constantly = send out monitoring and performance tests in an asynchronous fashion and = farm the results out to free compute in the datacenter. I would think = Netconf could handle this RJE type action, we just need to develop the = models. >=20 >=20 > Built-in support needs an updated protocol *and* updatad data > modelling language. >=20 >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 9 04:50:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841C01A0053 for ; Tue, 9 Sep 2014 04:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5usFnOnfm04O for ; Tue, 9 Sep 2014 04:50:19 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544001A0055 for ; Tue, 9 Sep 2014 04:50:17 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XRJw5-0006Q3-Sq for netconf@ietf.org; Tue, 09 Sep 2014 13:50:15 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest108.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XRJw5-0005EI-P9 for netconf@ietf.org; Tue, 09 Sep 2014 13:50:13 +0200 Message-ID: <540EE975.3040705@bwijnen.net> Date: Tue, 09 Sep 2014 13:50:13 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Netconf References: <540EE5AD.9020306@bwijnen.net> In-Reply-To: <540EE5AD.9020306@bwijnen.net> Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd4beee6fa5ee76a8556d7cad8a60b1ee7f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UbbZuVRBOfzbJxhlxQrRVTwzsy0 Subject: Re: [Netconf] draft minutes/notes of our Virtual Interim Meeting on 8 Sept 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 11:50:25 -0000 I found at: http://www.ietf.org/iesg/statement/interim-meetings.html The minutes, including a list of attendees, must be sent to proceedings@ietf.org within 10 days after the meeting, conference call or jabber session concludes. So I will add this list of participants (speak up if you think I missed somone): I intend send the complete set to processdings by the end of this week. Meeting start: 8 Sept 2014, 17:00 UTC Meeting end: 8 Sept 2014, 19:05 UTC Chair: Bert Wijnen Attendees: Juergen Schoenwaelder Ladislav Lhotka Martin Bjorklund Kent Watsen Andy Bierman Michael Scharf Mahesh Jethanandi Alberto Gonzalez Priedro Benoit CLaise (AD) Regrets: Mehmet Ersue (vacation) On 09/09/14 13:34, Bert Wijnen (IETF) wrote: > Dear WG participants, we had our first virtual interim meeting yesterday. > here are the draft minutes (thanks to Kent for taking notes, amended/merged > with my own notes): > > The meetings run from 8 Sept - 3 Nov 2014. Biweekly on Mondays from 7pm-9pm > CET (Berlin, Amsterdam, Paris). That is 17:00-19:00 UTC. They are webex based > meetings. We have decided last night to record the meetings. But the WG chair(s) > will ensure at the start of every meeting that everyone is aware and that > nobody objects. The recording of yesterdays meeting is here: > > > > - The main objective of the call is to help us (WG) move faster on our > chartered work items. RESTCONF is a big piece of that. Whatever we want > to decide must be verified on the WG mailing list. Of course some discussion > end up in changes to a document, which will always be presented to the WG > mailing list and which will eventually be Last Called, so everyone has a say. > > - We had 10 participants on the call > > - Kent presented GitHub, which is used to track issues and which also > is used by various editors to work together on the documents > * DECISION: We will NOT forward all changes in GITHUB to the WG > mailing list. > * Pull-requests for editorial changes are OK, > * but more substantial issues (in fact all issues) should be discussed > on our NETCONF WG mailing list. We can use github to keep track of the > status and to record summaries, proposed solutions and the final > resolution. > > - Andy presented RESTCONF issues > see: https://github.com/netconf-wg/restconf/issues > We discussed them in reverse order (will try to get them properly > discussed in order next time). I (Bert) have added all issues, > also those that were created new as a result o the virtual meeting and > those that were not discussed. If you want to comment or voice an > opinion on any issue (that would be VERY GOOD and HELPFUL), then pls > set the subject line to the issue number plus issue title. > > * issue # 10: Naming convention for Query Parameters > o opened by Bert as a result of our first virual meeting > o split ioff from issue # 6 > * issue # 9: Define how authentication is performed > o opened by Andy as a result of our first virtual meeting > * issue #7: Mandatory-to-implement encoding > o WG chairs did a poll on the WG list for opinions: > see: http://www.ietf.org/mail-archive/web/netconf/current/msg09218.html > It runs till Sept 18, so those who have not expressed an opinion yet > are encouraged to do so. > o For now, "Optional" encoding (choice d) got more votes than "XML mandatory" > (choice a). > o Martin mentions technical motivations were expressed with choice 'a' > o Bert reminded that STANDARDIZATION means making choices and making interoperability > easy. From that point of view, choice a seems more appropriate. > o ACTION: Bert will send reminder to collect more opinions (done) > * issue #6: how to identify query parameters supported by the server > o No prefix for ietf-defined (this is naming, see new issue #10) > o We basically have 2 issues, one is Naming,the other is discovery of which > parameters are supported by the server. So issue #6 stays as is, > issue #10 opened by Bert for Naming conventions > o Capability encoding in the air: Lada is thinking a json object > o Proposal to collapse into a single URI string > o Opinions of other WG participants are welcome! Please speak up > * issue #5: protocol capability URIs > o was not discussed on this call > o Toronto consensus: Add protocol capabilities somehow > o so we need to see new text in a revision of the draft > *issue #4: Defaults handling > o Mapping to RESTCONF straight forward > o the server MUST report what basic-mode it supports > o Question: Should full support of with-defaults RFC be added to base RESTCONF? > Please speak up and express opinions? > * issue #3: add collection resource > o Put collections media-type and query-parameters into main draft, but? > o There seems to be consensus to put collections resource in another document. > o Need to deal with GET on a list with no keys given: > GET /restconf/data/interfaces/interface > --> Maybe this will be an error unless collection resource requested > o Need text proposals on mailing list. > * issue #2 Netconf state monitoring > o Need to create an issue for authentication > (done by Andy, that is issue #9 > o Do we need to have a 6022-bis document or can RESTCONF just update the text > in order to support non-NETCONF sessions. > o An idea is to let this doc "update" RFC 6022 > * issue #1: Select parameter > o What syntax should be used for the "select" query parameter? The > current choices are "XPath" and "path-expr". Perhaps an > additional parameter to identify the select string format is > needed to allow extensibility? > o Martin's proposal stands...issue seems closed > o WG participants, please speak up if you cannot live with > Martin's proposal, see > https://github.com/netconf-wg/restconf/issues/1 > > - A question was raised by Mahesh, regarding CLI type uses as ping and traceroute. > He was asked to post the problem statement to the WG list, which he has done now > see: http://www.ietf.org/mail-archive/web/netconf/current/msg09254.html > > - Next time we will discuss restconf issues again, but also: call-home. > It seems like a good idea to then have the accompanying documents updated as well, > so: > o ACTION: Juergen should update 5539bis > 0 ACTION: Kent to submit server-model > > Bert Wijnen, with special thanks to Kent and Andy. > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Sep 9 08:34:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6451A0AE9 for ; Tue, 9 Sep 2014 08:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNhTXYY53mwD for ; Tue, 9 Sep 2014 08:34:18 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7E01A6FB3 for ; Tue, 9 Sep 2014 08:34:18 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta05.westchester.pa.mail.comcast.net with comcast id p0go1o0031HzFnQ553aHGa; Tue, 09 Sep 2014 15:34:17 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta14.westchester.pa.mail.comcast.net with comcast id p3aH1o0082yZEBF3a3aHGC; Tue, 09 Sep 2014 15:34:17 +0000 From: "ietfdbh" To: "'Bert Wijnen \(IETF\)'" , "'Martin Bjorklund'" , References: <20140909.083853.1378645628350562249.mbj@tail-f.com> <540EAF90.1010601@bwijnen.net> In-Reply-To: <540EAF90.1010601@bwijnen.net> Date: Tue, 9 Sep 2014 11:34:16 -0400 Message-ID: <00dd01cfcc43$845b6110$8d122330$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIRA/nWJbICRRlsSY+8MI3haa01wAJJRo6JAnZlXl8BlyLxtZtDyDcg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410276857; bh=Hl3lNip7Dx126bIiowDQ5PX1OvRK7RI5sJNomSvphIg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=B1PvixXI5RwTC9kEZhlyYiiFwOzdlC5MgahaI6dZaeC6a+ewLEOf08492BNeAPY5h f/L+c2A2eFeUBVoqtrQXAiJRk2SIYBxi/lHdTSVWHNMneRyLuhz0GlhH6z78/KKZv4 2Qn+yRjFfRI8ca+uw82ZkeEhjiCJxrlgKnAyXahryrs8y6UUm+/OrhwPtqoCqdNWio b0qHDHTpOzXmk9/M2PnPy8jd5ADloB2MbiftmXau+GWW0bEraISQA5wI+pnHmsdyoL fn/SR7ARi6wxG/OtO2pkhzPu41U55Z5q87OTzDmRNRbjI0lzEeX8Kqk2gGnujMFdqq EUD4zmqSUw5lw== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ee3oH3W2srUNxj7vX8_Q_1-mpF4 Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 15:34:19 -0000 +1 Are we now trying to build a full CLI replacement, rather than just a protocol to standardize configuration? David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen > (IETF) > Sent: Tuesday, September 09, 2014 3:43 AM > To: Martin Bjorklund; kwatsen@juniper.net > Cc: netconf@ietf.org > Subject: Re: [Netconf] NETCONF and interactive CLI's > > Interesting discussion. > > In my head I have his question: > > NETCONF was for Network CONFIGURATION > > So what do traceroute, ping and possibly other long running commands > have to do with network configuration?? > > In my mind they seem to be debugging or monitoring tools. > > Bert (speaking as a contributor) > From nobody Tue Sep 9 08:47:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7FB1A6FE8 for ; Tue, 9 Sep 2014 08:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDbdq_p6X7dv for ; Tue, 9 Sep 2014 08:47:36 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DECA1A6FF3 for ; Tue, 9 Sep 2014 08:47:36 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so367980qgd.7 for ; Tue, 09 Sep 2014 08:47:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=evHs1MDQhAvmRqPjcC2bHV4hBFsG/l8PQq3/B9qy9Lk=; b=klJCWIPYWbO58uNyADT5XgaUrByX5Xyn1J0VpTk4vXVmG3fwRl4m1/tmOwTsMGdYfU 6Ls2b38DvGQ1O5BkEv0YXBR9k90/5YfptKCMhIHjTCUQuVpn1YRHlFVXX85JWI9FyNjI uuOdVrCay/6ydftZjtv1iK0k/mokCf02b0Am0qXLfm6/DaPItLW9h5Yoxc1L/2+XmjNK FFCp5wmFVlJIV7lVdSAHYm8jpOkccVzLPz7XAdN4eUuwz+nweEUXXPUcXGabTgLmxb6I Hephafss1ZCi4RWNq5G3ACy2afw2G/muyJzAerK8h+GGGlyk/+r5MxfwS0691NPrv9u6 wMPA== X-Gm-Message-State: ALoCoQmKSz7oicYsq5YegN7Ta/n7jgsYYK4367sMHQUVWrOFjN4ULolrdJ9vdukyybQzP1mpWY9H MIME-Version: 1.0 X-Received: by 10.140.22.203 with SMTP id 69mr6214386qgn.35.1410277654814; Tue, 09 Sep 2014 08:47:34 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Tue, 9 Sep 2014 08:47:34 -0700 (PDT) In-Reply-To: <540EAF90.1010601@bwijnen.net> References: <20140909.083853.1378645628350562249.mbj@tail-f.com> <540EAF90.1010601@bwijnen.net> Date: Tue, 9 Sep 2014 08:47:34 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=001a11c14f78a67eae0502a3dadf Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9qASglCwSPhZ9hgwo-QmjC7QKu0 Cc: Netconf Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 15:47:39 -0000 --001a11c14f78a67eae0502a3dadf Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 9, 2014 at 12:43 AM, Bert Wijnen (IETF) wrote: > Interesting discussion. > > In my head I have his question: > > NETCONF was for Network CONFIGURATION > > So what do traceroute, ping and possibly other long running commands > have to do with network configuration?? > > In my mind they seem to be debugging or monitoring tools. > > What if the operator needs to measure some behavior of the network in order to adjust the configuration somehow? Remote ping and traceroute have been needed and available in the CLI for a long time, so using a Remote Procedure Call in NETCONF to manage it is not such a stretch. Andy Bert (speaking as a contributor) > > On 09/09/14 08:38, Martin Bjorklund wrote: > >> Kent Watsen wrote: >> >>> >>> I'm sure others have their opinions, but to me this follows the pattern >>> of >>> a long-running request, whereby I'd expect a general mechanism to >>> query/cancel currently running tasks, something like this: >>> >> >> [...] >> >> On the call yesterday I suggested something similiar, but more direct: >> >> rpc start-ping-job { >> input { >> // ping parameters here... >> } >> output { >> leaf ping-job-handle { ... } >> } >> } >> >> rpc get-one-ping-result { >> input { >> leaf ping-job-handle { ... } >> } >> output { >> // ping result here >> } >> } >> >> rpc cancel-ping-job { >> input { >> leaf ping-job-handle { ... } >> } >> } >> >> The call sequence would be: >> >> start-ping-job ---> >> get-one-ping-result ---> >> get-one-ping-result ---> >> ... >> [cancel-ping-job ---> ok] >> >> >> >> Yes, this is not as elegant as built-in support, but it works today. >> >> >> Built-in support needs an updated protocol *and* updatad data >> modelling language. >> >> >> /martin >> >> _______________________________________________ >> 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 > --001a11c14f78a67eae0502a3dadf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 9, 2014 at 12:43 AM, Bert Wijnen (IETF) &= lt;bertietf@bwijn= en.net> wrote:
Interesting = discussion.

In my head I have his question:

=A0 =A0NETCONF was for Network CONFIGURATION

=A0 =A0So what do traceroute, ping and possibly other long running commands=
=A0 =A0have to do with network configuration??

In my mind they seem to be debugging or monitoring tools.


What if the operator needs to measure = some behavior
of the network in order to adjust the configuration= somehow?

Remote ping and traceroute have been nee= ded and available in the CLI for
a long time, so using a Remote P= rocedure Call in NETCONF to manage it
is not such a stretch.=A0


Andy


Bert (speaking as a contributor)

On 09/09/14 08:38, Martin Bjorklund wrote:
Kent Watsen <kw= atsen@juniper.net> wrote:

I'm sure others have their opinions, but to me this follows the pattern= of
a long-running request, whereby I'd expect a general mechanism to
query/cancel currently running tasks, something like this:

[...]

On the call yesterday I suggested something similiar, but more direct:

=A0 =A0rpc start-ping-job {
=A0 =A0 =A0input {
=A0 =A0 =A0 =A0// ping parameters here...
=A0 =A0 =A0}
=A0 =A0 =A0output {
=A0 =A0 =A0 =A0leaf ping-job-handle { ... }
=A0 =A0 =A0}
=A0 =A0}

=A0 =A0rpc get-one-ping-result {
=A0 =A0 =A0input {
=A0 =A0 =A0 =A0leaf ping-job-handle { ... }
=A0 =A0 =A0}
=A0 =A0 =A0output {
=A0 =A0 =A0 =A0// ping result here
=A0 =A0 =A0}
=A0 =A0}

=A0 =A0rpc cancel-ping-job {
=A0 =A0 =A0input {
=A0 =A0 =A0 =A0leaf ping-job-handle { ... }
=A0 =A0 =A0}
=A0 =A0}

The call sequence would be:

=A0 =A0 start-ping-job=A0 =A0 =A0 =A0 =A0---> <handle>
=A0 =A0 get-one-ping-result=A0 =A0 ---> <data>
=A0 =A0 get-one-ping-result=A0 =A0 ---> <data>
=A0 =A0 ...
=A0 =A0 [cancel-ping-job=A0 =A0 =A0 =A0 ---> ok]



Yes, this is not as elegant as built-in support, but it works today.


Built-in support needs an updated protocol *and* updatad data
modelling language.


/martin

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


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

--001a11c14f78a67eae0502a3dadf-- From nobody Tue Sep 9 09:12:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664271A6FF9 for ; Tue, 9 Sep 2014 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC9G7HrZ7Ihg for ; Tue, 9 Sep 2014 09:12:33 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C560E1A6FF1 for ; Tue, 9 Sep 2014 09:12:23 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-c2-540f26e5bfd6 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.58.24955.5E62F045; Tue, 9 Sep 2014 18:12:21 +0200 (CEST) Received: from [159.107.197.75] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.174.1; Tue, 9 Sep 2014 18:12:20 +0200 Message-ID: <540F26E4.2000101@ericsson.com> Date: Tue, 9 Sep 2014 18:12:20 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andy Bierman , "Bert Wijnen (IETF)" References: <20140909.083853.1378645628350562249.mbj@tail-f.com> <540EAF90.1010601@bwijnen.net> In-Reply-To: Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvje5TNf4Qg03X9S0eHJnFbtHR8YrN Yuqm26wOzB63rj9i8Viy5CeTR0v/RZYA5igum5TUnMyy1CJ9uwSujF13vrEXfLOt+Lj2DXMD 4wr1LkZODgkBE4mXz4+zQdhiEhfurQeyuTiEBI4yShxd+gbKWc0oMf/FPmaQKl4BbYlLS2ex g9gsAioSj14+YQKx2QSMJKb2n2cBsUUFoiTuXOpnhagXlDg58wlYXEQgROLH1udgvcwCchKL f/SA9QoDXXHn30xWiGV9TBLTPj8HS3AKBEr8PTqVFaJBV+LC/yksELa8xPa3c8AOEhLQkHh4 4S/rBEbBWUj2zULSMgtJywJG5lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgWF8cMtv1R2M l984HmIU4GBU4uFNnM4XIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGBMvB7ZODi7nOCgq0i2WavZzhq1PQrNr1pUfvpHCgqVJG2x4YvtbpETV1VuYik5N eqF6itOEK7V55TOGnbVTr6vMd2mRSkqw2Bn98AVHyJvQ8MW/vlw6k8J/hPtp7tQ1Z1P3cv29 5/es1/+C2VU1FauFdgtPOFzwUZme0eN0+L7gkrgtNyVUlFiKMxINtZiLihMBo1hyS0QCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pd0XJ_-81PmWvNeeJdgx-kFUhwc Cc: Netconf Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:12:35 -0000 Hello,
We have similar long running operations in configuration management as well. E.g. upgrade, restore-backup, create-backup, restart-card. 
IMHO this could be solved by using an operation-handle to query the state of the operation, to cancel it,  and notifications for interim results. As I remember Andy proposed something similar.
regards Balazs

On 2014-09-09 17:47, Andy Bierman wrote:


On Tue, Sep 9, 2014 at 12:43 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:
Interesting discussion.

In my head I have his question:

   NETCONF was for Network CONFIGURATION

   So what do traceroute, ping and possibly other long running commands
   have to do with network configuration??

In my mind they seem to be debugging or monitoring tools.


What if the operator needs to measure some behavior
of the network in order to adjust the configuration somehow?

Remote ping and traceroute have been needed and available in the CLI for
a long time, so using a Remote Procedure Call in NETCONF to manage it
is not such a stretch. 


Andy


Bert (speaking as a contributor)

On 09/09/14 08:38, Martin Bjorklund wrote:
Kent Watsen <kwatsen@juniper.net> wrote:

I'm sure others have their opinions, but to me this follows the pattern of
a long-running request, whereby I'd expect a general mechanism to
query/cancel currently running tasks, something like this:

[...]

On the call yesterday I suggested something similiar, but more direct:

   rpc start-ping-job {
     input {
       // ping parameters here...
     }
     output {
       leaf ping-job-handle { ... }
     }
   }

   rpc get-one-ping-result {
     input {
       leaf ping-job-handle { ... }
     }
     output {
       // ping result here
     }
   }

   rpc cancel-ping-job {
     input {
       leaf ping-job-handle { ... }
     }
   }

The call sequence would be:

    start-ping-job         ---> <handle>
    get-one-ping-result    ---> <data>
    get-one-ping-result    ---> <data>
    ...
    [cancel-ping-job        ---> ok]



Yes, this is not as elegant as built-in support, but it works today.


Built-in support needs an updated protocol *and* updatad data
modelling language.


/martin

_______________________________________________
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



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


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Tue Sep 9 09:34:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C221A7018 for ; Tue, 9 Sep 2014 09:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ7U5VC6LWi1 for ; Tue, 9 Sep 2014 09:34:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14CD1A6FF6 for ; Tue, 9 Sep 2014 09:34:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D7E2111F2; Tue, 9 Sep 2014 18:34:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 70gCAOAHeCNj; Tue, 9 Sep 2014 18:33:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 9 Sep 2014 18:34:04 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F5AB20037; Tue, 9 Sep 2014 18:34:04 +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 NjJ2DAhQLeCl; Tue, 9 Sep 2014 18:34:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E21520035; Tue, 9 Sep 2014 18:34:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1CF342E5F1C0; Tue, 9 Sep 2014 18:34:01 +0200 (CEST) Date: Tue, 9 Sep 2014 18:34:01 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20140909163401.GB97914@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org References: <20140909.083853.1378645628350562249.mbj@tail-f.com> <540EAF90.1010601@bwijnen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <540EAF90.1010601@bwijnen.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/celHQEk5tmkglsFRJbA2bIAVfyI Cc: netconf@ietf.org Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:34:28 -0000 On Tue, Sep 09, 2014 at 09:43:12AM +0200, Bert Wijnen (IETF) wrote: > Interesting discussion. > > In my head I have his question: > > NETCONF was for Network CONFIGURATION > > So what do traceroute, ping and possibly other long running commands > have to do with network configuration?? > > In my mind they seem to be debugging or monitoring tools. Successful protocols are often used beyond their original scope. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Sep 9 09:46:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4137C1A7006 for ; Tue, 9 Sep 2014 09:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eIoIfp60KU7 for ; Tue, 9 Sep 2014 09:46:28 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9192C1A7023 for ; Tue, 9 Sep 2014 09:46:14 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so16140576qaq.31 for ; Tue, 09 Sep 2014 09:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ukxvba/nFJd5h7ZjZlU45w9kysdvw/QW9olaqPxOGOE=; b=u4x7yPpLyr5AjaeNJRebVHE91cW7FHNltgh7IIv1o92IGTciMfvn7oAY9wiHYxA8SC x26OZ7Y3U6jEIJhGjMEetcU+A+Y68oRdmzNNMR8o05YqKKIUkkT4L/YsKblXODqz/yhZ Nsh198gm03HdHu+FYQbSJLyqtAClwAC6htDx2M0Cpw5m2JvF3xqqclm07fRDLoS9s7GU p7kg9m2A4CpNuU/9z63ktTjLZXaC0Q3TSvr/peJ3ckao132orDQg4beYVYVl1Ni5+IIW arFqcjuY4uU+StUKyJ4DfZHB0/kxQ9ObTja0pEJ03vtKkNJZAZfiXra66gimo3pGY8yQ zV6A== X-Received: by 10.224.75.73 with SMTP id x9mr53022232qaj.63.1410281173710; Tue, 09 Sep 2014 09:46:13 -0700 (PDT) Received: from [192.168.1.101] (108-247-124-220.lightspeed.sntcca.sbcglobal.net. [108.247.124.220]) by mx.google.com with ESMTPSA id v90sm10214497qge.31.2014.09.09.09.46.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 09:46:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Mahesh Jethanandani In-Reply-To: <540EC76E.4060706@bwijnen.net> Date: Tue, 9 Sep 2014 09:46:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <19773560-D1B2-4309-B591-DEAF5C326AE3@gmail.com> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <540EC76E.4060706@bwijnen.net> To: Bert Wijnen (IETF) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Q53aFzi1p-6T1ocAiEWFs_O79r8 Cc: Netconf Subject: Re: [Netconf] Reminder: WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:46:30 -0000 Is there room to change ones opinion :-) ? I had voted for a) but was reminded that there are existing solutions = with JSON that will not accept a strict XML solution. d) provides the = maximum flexibility in that regard, leaving the server to implement what = it prefers. On Sep 9, 2014, at 2:25 AM, Bert Wijnen (IETF) wrote: > I'd like to remind everyone that this WG last call ends on Sept 18. > Several people have already expressed their opinion. If you want to be = heard, pls > speak up asap, certainly before Sept 18th. The WG chairs need your = input and > opinions to try and determine WG (rough) consensus on this topic. >=20 >=20 > Bert >=20 > On 02/09/14 12:23, Bert Wijnen (IETF) wrote: >> On 26/08/14 22:49, Andy Bierman wrote: >>>=20 >>> Perhaps the co-chairs should decide how to proceed somehow. >>=20 >> Dear NETCONF WG participants, do you have an opinion? >>=20 >> So far I have seen only a few people express their opinion. >>=20 >> Please speak up so that we (WG chairs) have better data to judge if = we >> do or do not have WG (rough) consensus. Pls do speak up by 18 Sept = 2014. >>=20 >> Please speak your mind about these options: >>=20 >> a) XML is mandatory >> b) JSON is mandatory >> c) XML and JSON are both mandatory >> d) Both XML and JSON mandatory on client, >> server can implement whatever it chooses. >> Not clear yet how the client would find out, but that would of = course >> be something to be worked out if we choose this option >>=20 >> Bert >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Sep 10 03:19:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF9E1A06FC for ; Wed, 10 Sep 2014 03:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.552 X-Spam-Level: X-Spam-Status: No, score=-8.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wlbwo8hyTwn5 for ; Wed, 10 Sep 2014 03:19:04 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46331A06DA for ; Wed, 10 Sep 2014 03:19:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkALADUlEFTGmAcV/2dsb2JhbABWA4JqI1NXBLESBphpHwqGeVMBgQwWeIQDAQEBAQMBAQEPKDQLDAICAgEIDQECAQQBAQEKFAkHGwwLFAkIAgQBDQUIGoggAQydXp9vARcEhXiJICEQBwYLgx6BHQWRQZMcjUSDYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,498,1406606400"; d="scan'208";a="84164463" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Sep 2014 06:19:02 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Sep 2014 06:19:02 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Wed, 10 Sep 2014 12:19:01 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , "Bert Wijnen (IETF)" Thread-Topic: [Netconf] NETCONF and interactive CLI's Thread-Index: AQHPy66AwMrW/ujCtESlsnBcogG+qZv4FLMAgAAj2oCAABH4AIAAlE+AgAFKmXA= Date: Wed, 10 Sep 2014 10:19:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C896F73@AZ-FFEXMB04.global.avaya.com> References: <20140909.083853.1378645628350562249.mbj@tail-f.com> <540EAF90.1010601@bwijnen.net> <20140909163401.GB97914@elstar.local> In-Reply-To: <20140909163401.GB97914@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Dvu-5V2iTm0k-pVS-lvA_f6A2bk Cc: "netconf@ietf.org" Subject: Re: [Netconf] NETCONF and interactive CLI's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 10:19:05 -0000 +1=20 What we and other had in mind in 2004 when the NETCONF work started is impo= rtant for historians.=20 What is important now is what is useful and works for the operators of 2014= and beyond.=20 Regards, Dan > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, September 09, 2014 7:34 PM > To: Bert Wijnen (IETF) > Cc: netconf@ietf.org > Subject: Re: [Netconf] NETCONF and interactive CLI's >=20 > On Tue, Sep 09, 2014 at 09:43:12AM +0200, Bert Wijnen (IETF) wrote: > > Interesting discussion. > > > > In my head I have his question: > > > > NETCONF was for Network CONFIGURATION > > > > So what do traceroute, ping and possibly other long running commands > > have to do with network configuration?? > > > > In my mind they seem to be debugging or monitoring tools. >=20 > Successful protocols are often used beyond their original scope. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From jing.zhao@ni.com Tue Sep 9 20:13:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9461A03DB for ; Tue, 9 Sep 2014 20:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DR-h04dVYcg for ; Tue, 9 Sep 2014 20:13:50 -0700 (PDT) Received: from ni.com (skprod3.natinst.com [130.164.80.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9581A016D for ; Tue, 9 Sep 2014 20:13:50 -0700 (PDT) Received: from us-aus-mgwout2.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod3.natinst.com (8.14.5/8.14.5) with ESMTP id s8A3DkHF021982 for ; Tue, 9 Sep 2014 22:13:49 -0500 Received: from cn-sha-domino1.apac.corp.natinst.com ([130.164.14.198]) by us-aus-mgwout2.amer.corp.natinst.com (Lotus Domino Release 8.5.3FP6) with ESMTP id 2014090922134631-1061749 ; Tue, 9 Sep 2014 22:13:46 -0500 To: netconf@ietf.org MIME-Version: 1.0 X-KeepSent: 503882CE:06FC8D0B-48257D4F:000CBBBC; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 From: Jing Zhao Message-ID: Date: Wed, 10 Sep 2014 11:13:43 +0800 X-MIMETrack: Serialize by Router on Nimbus/SHA/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/10/2014 11:13:46 AM, Serialize complete at 09/10/2014 11:13:46 AM, Itemize by SMTP Server on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/09/2014 10:13:46 PM, Serialize by Router on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/09/2014 10:13:49 PM, Serialize complete at 09/09/2014 10:13:49 PM Content-Type: multipart/alternative; boundary="=_alternative 0011BBB248257D4F_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-09-10_01:2014-09-09,2014-09-09,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GIoikWUCoCqkFhcG3l6S1qN95j8 X-Mailman-Approved-At: Wed, 10 Sep 2014 04:25:00 -0700 Subject: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 04:23:36 -0000 This is a multipart message in MIME format. --=_alternative 0011BBB248257D4F_= Content-Type: text/plain; charset="US-ASCII" Hi all, I'm working on a NETCONF research project hoping to find out a way to build layer 2 network topology. There are some open algorithms to build topology based on the information read from switch MIB. For example, each switch port has one entry in MIB dot1dStpPortTable which includes designated switch id, designated port, the root switch, etc. But I'm looking for a way to use NETCONF to read the MIB from switches. What I can expect is that switches implement some special YANG module which maps to this MIB and provides a new RPC function like, e.g., get-stp-table. I think this should be a normal use case for NETCONF. It's actually listed as one issue here. But I cannot find anything related on the Web. The most I can get is ietf-routing.yang draft listing at www.netconfcentral.org. So is there any IETF RFC or draft defining something pertaining to layer 2 topology discovery using NETCONF? Thanks! Best regards, Eric --=_alternative 0011BBB248257D4F_= Content-Type: text/html; charset="US-ASCII" Hi all,

I'm working on a NETCONF research project hoping to find out a way to build layer 2 network topology. There are some open algorithms to build topology based on the information read from switch MIB.

For example, each switch port has one entry in MIB dot1dStpPortTable which includes designated switch id, designated port, the root switch, etc.

But I'm looking for a way to use NETCONF to read the MIB from switches. What I can expect is that switches implement some special YANG module which maps to this MIB and provides a new RPC function like, e.g., get-stp-table.

I think this should be a normal use case for NETCONF. It's actually listed as one issue here.

But I cannot find anything related on the Web. The most I can get is ietf-routing.yang draft listing at www.netconfcentral.org. So is there any IETF RFC or draft defining something pertaining to layer 2 topology discovery using NETCONF?

Thanks!

Best regards,
Eric --=_alternative 0011BBB248257D4F_=-- From nobody Wed Sep 10 04:34:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59901A6F6F for ; Wed, 10 Sep 2014 04:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KygkVfceDwoJ for ; Wed, 10 Sep 2014 04:34:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444E01A06DE for ; Wed, 10 Sep 2014 04:34:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DABC213BC; Wed, 10 Sep 2014 13:34:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EEGw-Q537IBG; Wed, 10 Sep 2014 13:34:06 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 10 Sep 2014 13:34:18 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 396E120035; Wed, 10 Sep 2014 13:34:18 +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 tUC1Mi-aXsfI; Wed, 10 Sep 2014 13:34:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D51B20036; Wed, 10 Sep 2014 13:34:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E4B5E2E5FD36; Wed, 10 Sep 2014 13:34:16 +0200 (CEST) Date: Wed, 10 Sep 2014 13:34:16 +0200 From: Juergen Schoenwaelder To: Jing Zhao Message-ID: <20140910113416.GB99920@elstar.local> Mail-Followup-To: Jing Zhao , netconf@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8sU8kCHiNWOYTf0AajbkYLMymwI Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 11:34:22 -0000 Hi, you can turn a MIB module into a read-only YANG model following RFC 6643. While L2 discovery via MIB modules may work in certain situations, using something like LLDP and an interface to extract information from stations speaking LLDP may be an alternative to consider. /js On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote: > Hi all, > > I'm working on a NETCONF research project hoping to find out a way to > build layer 2 network topology. There are some open algorithms to build > topology based on the information read from switch MIB. > > For example, each switch port has one entry in MIB dot1dStpPortTable which > includes designated switch id, designated port, the root switch, etc. > > But I'm looking for a way to use NETCONF to read the MIB from switches. > What I can expect is that switches implement some special YANG module > which maps to this MIB and provides a new RPC function like, e.g., > get-stp-table. > > I think this should be a normal use case for NETCONF. It's actually listed > as one issue here. > > But I cannot find anything related on the Web. The most I can get is > ietf-routing.yang draft listing at www.netconfcentral.org. So is there any > IETF RFC or draft defining something pertaining to layer 2 topology > discovery using NETCONF? > > Thanks! > > Best regards, > Eric > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 10 08:07:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9241A8750 for ; Wed, 10 Sep 2014 08:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNp9nBRmoHop for ; Wed, 10 Sep 2014 08:07:06 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B671A8737 for ; Wed, 10 Sep 2014 08:06:28 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by resqmta-ch2-01v.sys.comcast.net with comcast id pQuc1o0010SCNGk01T6Ulp; Wed, 10 Sep 2014 15:06:28 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta09.westchester.pa.mail.comcast.net with comcast id pT6S1o00E2yZEBF3VT6TGS; Wed, 10 Sep 2014 15:06:27 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" , "'Jing Zhao'" References: <20140910113416.GB99920@elstar.local> In-Reply-To: <20140910113416.GB99920@elstar.local> Date: Wed, 10 Sep 2014 11:06:24 -0400 Message-ID: <017901cfcd08$cad73e50$6085baf0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK/a12n9YicgiCdTEnAum+8yOUpwQI8VgkmmglXbSA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410361588; bh=soGsPOwITHBI7+PhOHAUPiF8KVZnFCJrYbY+pgs6zjk=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=cFXEzppQWKil6Uf1RTp0us02SOYBQePaj6a1f/kaVLxxyQhiIbtpNvBfkag6yOtOr 4SphxiknnO9HoYmXyDH9zZ6fXCskbvS6ZaZN45ez6NVAAvKLZTwC9CmBZge3SjX7Uu IKfdZorQwfdJ72dpRaZJx7gxuJ43kTWINSPRywv4j5zrhqC/Mv4CAqgot+rdDvY7kQ n94lFo9m0s6iDTpbo47ENQPvrxIwgpUQxSEb6dq8Vpcojf8PnEZYwePn8/CPtx8mkA ia5Ye+RFsLmB/pGekbRfzlwwc0MPJjTgPPfUZo2yNYaXcxtpo4vUJUryAkkeYj2dkJ P6oEn+ZOpQgYw== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fHbox6fYEO7q4a0ctMNYutBTzy4 Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 15:07:13 -0000 To expand on Juergen's response, See http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol And RFC2922 David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, September 10, 2014 7:34 AM > To: Jing Zhao > Cc: netconf@ietf.org > Subject: Re: [Netconf] L2 topology discovery with NETCONF > > Hi, > > you can turn a MIB module into a read-only YANG model following RFC > 6643. While L2 discovery via MIB modules may work in certain > situations, using something like LLDP and an interface to extract > information from stations speaking LLDP may be an alternative to > consider. > > /js > > On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote: > > Hi all, > > > > I'm working on a NETCONF research project hoping to find out a way to > > build layer 2 network topology. There are some open algorithms to build > > topology based on the information read from switch MIB. > > > > For example, each switch port has one entry in MIB dot1dStpPortTable > which > > includes designated switch id, designated port, the root switch, etc. > > > > But I'm looking for a way to use NETCONF to read the MIB from switches. > > What I can expect is that switches implement some special YANG module > > which maps to this MIB and provides a new RPC function like, e.g., > > get-stp-table. > > > > I think this should be a normal use case for NETCONF. It's actually listed > > as one issue here. > > > > But I cannot find anything related on the Web. The most I can get is > > ietf-routing.yang draft listing at www.netconfcentral.org. So is there any > > IETF RFC or draft defining something pertaining to layer 2 topology > > discovery using NETCONF? > > > > Thanks! > > > > Best regards, > > Eric > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > 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 nobody Wed Sep 10 18:46:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5010E1A01AE for ; Wed, 10 Sep 2014 18:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wToIwTNSsqt5 for ; Wed, 10 Sep 2014 18:46:44 -0700 (PDT) Received: from ni.com (skprod3.natinst.com [130.164.80.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8DBF1A01AA for ; Wed, 10 Sep 2014 18:46:43 -0700 (PDT) Received: from us-aus-mgwout2.amer.corp.natinst.com (nb-chan1-1338.natinst.com [130.164.19.134]) by us-aus-skprod3.natinst.com (8.14.5/8.14.5) with ESMTP id s8B1kf7V028640; Wed, 10 Sep 2014 20:46:41 -0500 Received: from cn-sha-domino1.apac.corp.natinst.com ([130.164.14.198]) by us-aus-mgwout2.amer.corp.natinst.com (Lotus Domino Release 8.5.3FP6) with ESMTP id 2014091020464101-1126595 ; Wed, 10 Sep 2014 20:46:41 -0500 In-Reply-To: <20140910113416.GB99920@elstar.local> References: <20140910113416.GB99920@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-KeepSent: 02A550BF:6FB28B16-48257D50:0003B306; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 From: Jing Zhao Message-ID: Date: Thu, 11 Sep 2014 09:46:41 +0800 X-MIMETrack: Serialize by Router on Nimbus/SHA/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/11/2014 09:46:41 AM, Serialize complete at 09/11/2014 09:46:41 AM, Itemize by SMTP Server on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/10/2014 08:46:41 PM, Serialize by Router on US-AUS-MGWOut2/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/10/2014 08:46:41 PM, Serialize complete at 09/10/2014 08:46:41 PM Content-Type: multipart/alternative; boundary="=_alternative 0009C3A948257D50_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-09-11_01:2014-09-09,2014-09-11,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/i3b3dyy8uh-AMpQtYAkKf1Vn-ic Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 01:46:45 -0000 This is a multipart message in MIME format. --=_alternative 0009C3A948257D50_= Content-Type: text/plain; charset="US-ASCII" Thanks guys. Yes, LLDP is an alternative in my research. Either way, I guess we need some way to fetch those distributed info from switches, in order to build the topology. In the case of NETCONF, those switches must announce and support an extra capability of a read-only YANG module translated from the according MIB. What I'm worried about is the lack of a standard-defined YANG module for this purpose. Different vendors may implement their own YANG modules if they ever have one. It's thus hard to discover the network topology when there are switches from different vendors, or at least not scalable. To me, missing a standard module may limit the usage of NETCONF in this area. People will have to fall back and use SNMP to read MIB on different switches. So I want to know if there is something defined in NETCONF standard pertaining to L2 topology discovery. If not, is there any plan for that? Best regards, Eric Juergen Schoenwaelder wrote on 2014/09/10 19:34:16: > From: Juergen Schoenwaelder > To: Jing Zhao , > Cc: netconf@ietf.org > Date: 2014/09/10 19:34 > Subject: Re: [Netconf] L2 topology discovery with NETCONF > > Hi, > > you can turn a MIB module into a read-only YANG model following RFC > 6643. While L2 discovery via MIB modules may work in certain > situations, using something like LLDP and an interface to extract > information from stations speaking LLDP may be an alternative to > consider. > > /js > > On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote: > > Hi all, > > > > I'm working on a NETCONF research project hoping to find out a way to > > build layer 2 network topology. There are some open algorithms to build > > topology based on the information read from switch MIB. > > > > For example, each switch port has one entry in MIB dot1dStpPortTable which > > includes designated switch id, designated port, the root switch, etc. > > > > But I'm looking for a way to use NETCONF to read the MIB from switches. > > What I can expect is that switches implement some special YANG module > > which maps to this MIB and provides a new RPC function like, e.g., > > get-stp-table. > > > > I think this should be a normal use case for NETCONF. It's actually listed > > as one issue here. > > > > But I cannot find anything related on the Web. The most I can get is > > ietf-routing.yang draft listing at www.netconfcentral.org. So is there any > > IETF RFC or draft defining something pertaining to layer 2 topology > > discovery using NETCONF? > > > > Thanks! > > > > Best regards, > > Eric > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --=_alternative 0009C3A948257D50_= Content-Type: text/html; charset="US-ASCII" Thanks guys.

Yes, LLDP is an alternative in my research. Either way, I guess we need some way to fetch those distributed info from switches, in order to build the topology. In the case of NETCONF, those switches must announce and support an extra capability of a read-only YANG module translated from the according MIB.

What I'm worried about is the lack of a standard-defined YANG module for this purpose. Different vendors may implement their own YANG modules if they ever have one. It's thus hard to discover the network topology when there are switches from different vendors, or at least not scalable.

To me, missing a standard module may limit the usage of NETCONF in this area. People will have to fall back and use SNMP to read MIB on different switches.

So I want to know if there is something defined in NETCONF standard pertaining to L2 topology discovery. If not, is there any plan for that?

Best regards,
Eric

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote on 2014/09/10 19:34:16:

> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> To: Jing Zhao <jing.zhao@ni.com>,
> Cc: netconf@ietf.org
> Date: 2014/09/10 19:34
> Subject: Re: [Netconf] L2 topology discovery with NETCONF
>
> Hi,
>
> you can turn a MIB module into a read-only YANG model following RFC
> 6643. While L2 discovery via MIB modules may work in certain
> situations, using something like LLDP and an interface to extract
> information from stations speaking LLDP may be an alternative to
> consider.
>
> /js
>
> On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote:
> > Hi all,
> >
> > I'm working on a NETCONF research project hoping to find out a way to
> > build layer 2 network topology. There are some open algorithms to build
> > topology based on the information read from switch MIB.
> >
> > For example, each switch port has one entry in MIB dot1dStpPortTable which
> > includes designated switch id, designated port, the root switch, etc.
> >
> > But I'm looking for a way to use NETCONF to read the MIB from switches.
> > What I can expect is that switches implement some special YANG module
> > which maps to this MIB and provides a new RPC function like, e.g.,
> > get-stp-table.
> >
> > I think this should be a normal use case for NETCONF. It's actually listed
> > as one issue here.
> >
> > But I cannot find anything related on the Web. The most I can get is
> > ietf-routing.yang draft listing at www.netconfcentral.org. So is there any
> > IETF RFC or draft defining something pertaining to layer 2 topology
> > discovery using NETCONF?
> >
> > Thanks!
> >
> > Best regards,
> > Eric
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
 --=_alternative 0009C3A948257D50_=-- From nobody Wed Sep 10 21:02:52 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441F81A03E3 for ; Wed, 10 Sep 2014 21:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOhAm4F96vdK for ; Wed, 10 Sep 2014 21:02:40 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 672071A03DF for ; Wed, 10 Sep 2014 21:02:40 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id pg1i1o0010vyq2s5Bg2gYV; Thu, 11 Sep 2014 04:02:40 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta05.westchester.pa.mail.comcast.net with comcast id pg2f1o0052yZEBF3Rg2fwE; Thu, 11 Sep 2014 04:02:39 +0000 From: "ietfdbh" To: "'Jing Zhao'" , "'Juergen Schoenwaelder'" References: <20140910113416.GB99920@elstar.local> In-Reply-To: Date: Thu, 11 Sep 2014 00:02:37 -0400 Message-ID: <009c01cfcd75$3a0186c0$ae049440$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01CFCD53.B2F2CCF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK/a12n9YicgiCdTEnAum+8yOUpwQI8VgkmAkijzeqZ9+hScA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410408160; bh=fwzIVxDXk59y2rJYqYNgtged80Bmexo49aJz63AJQWE=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Com54cGMtMwQMN4N7693n5nMZ+9Z1Wlr9zMQJ9W05lr+z6LwkV0AwHZQizV3oAo87 wQcRwyCeZlgsb8H8grIM+Qtngk+JZkOZ7CALYZpgCFERWOukWkpIgO3Un29JnXl4GD EG3QSjjrGIA5m2d1w5HUSXUVqAVDRn06oOt8cFJfZ0llqu7uwmSWo0NSheeg+d6GtN E108obwKMQLj5fyfuvzrADAqZJf9VHHYuRT2avr4SFQaHJxcNWTRv/FQgJYOXR1qDA j/WeREm5lMqGKln0KRJ0kh4aqoUryOU2BlGORZGnCya5S2E2vehqFUkHRJBxvpiYdt d6eFjBsQPq/NQ== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/buAD8tWZqAR4NQyyc2UH0PZFEK0 Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 04:02:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009D_01CFCD53.B2F2CCF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I don't understand why you think the lack of a standard YANG module is a problem for discovering network topology. There are standard MIB modules supporting LLDP, and for discovering the network topology, they can be read using NETCONF, for those who want to use NETCONF, and they can be read using SNMP for those who want to use SNMP. That actually follows the original intention of having a standard MIB that could be accessed using different protocols. The only place where the MIB is inadequate is for configuring the read-write objects in the RFC2922 ptopoConfigGroup and the LLDP-MIB lldpConfiguration groups. But since most SNMP deployments don't support SNMP SETs, these MIB objects probably aren't used directly anyway. If they are used, but configured via CLI commands or other mechanisms, then a YANG module to configure them might be helpful. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Jing Zhao [mailto:jing.zhao@ni.com] Sent: Wednesday, September 10, 2014 9:47 PM To: Juergen Schoenwaelder Cc: netconf@ietf.org; ietfdbh Subject: Re: [Netconf] L2 topology discovery with NETCONF Thanks guys. Yes, LLDP is an alternative in my research. Either way, I guess we need some way to fetch those distributed info from switches, in order to build the topology. In the case of NETCONF, those switches must announce and support an extra capability of a read-only YANG module translated from the according MIB. What I'm worried about is the lack of a standard-defined YANG module for this purpose. Different vendors may implement their own YANG modules if they ever have one. It's thus hard to discover the network topology when there are switches from different vendors, or at least not scalable. To me, missing a standard module may limit the usage of NETCONF in this area. People will have to fall back and use SNMP to read MIB on different switches. So I want to know if there is something defined in NETCONF standard pertaining to L2 topology discovery. If not, is there any plan for that? Best regards, Eric Juergen Schoenwaelder wrote on 2014/09/10 19:34:16: > From: Juergen Schoenwaelder > To: Jing Zhao , > Cc: netconf@ietf.org > Date: 2014/09/10 19:34 > Subject: Re: [Netconf] L2 topology discovery with NETCONF > > Hi, > > you can turn a MIB module into a read-only YANG model following RFC > 6643. While L2 discovery via MIB modules may work in certain > situations, using something like LLDP and an interface to extract > information from stations speaking LLDP may be an alternative to > consider. > > /js > > On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote: > > Hi all, > > > > I'm working on a NETCONF research project hoping to find out a way to > > build layer 2 network topology. There are some open algorithms to build > > topology based on the information read from switch MIB. > > > > For example, each switch port has one entry in MIB dot1dStpPortTable which > > includes designated switch id, designated port, the root switch, etc. > > > > But I'm looking for a way to use NETCONF to read the MIB from switches. > > What I can expect is that switches implement some special YANG module > > which maps to this MIB and provides a new RPC function like, e.g., > > get-stp-table. > > > > I think this should be a normal use case for NETCONF. It's actually listed > > as one issue here. > > > > But I cannot find anything related on the Web. The most I can get is > > ietf-routing.yang draft listing at www.netconfcentral.org. So is there any > > IETF RFC or draft defining something pertaining to layer 2 topology > > discovery using NETCONF? > > > > Thanks! > > > > Best regards, > > Eric > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < http://www.jacobs-university.de/> ------=_NextPart_000_009D_01CFCD53.B2F2CCF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I don’t understand why you think the lack of a standard YANG = module is a problem for discovering network = topology.

There are standard MIB modules supporting LLDP, and for discovering = the network topology, they can be read using NETCONF, for those who want = to use NETCONF, and they can be read using SNMP for those who want to = use SNMP.

That actually follows the original intention of having a standard MIB = that could be accessed using different = protocols.

 

The only place where the MIB is inadequate is for configuring the = read-write objects in the RFC2922 ptopoConfigGroup and the LLDP-MIB = lldpConfiguration groups.

But since most SNMP deployments don’t support SNMP SETs, these = MIB objects probably aren’t used directly = anyway.

If they are used, but configured via CLI commands or other = mechanisms, then a YANG module to configure them might be = helpful.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = Jing Zhao [mailto:jing.zhao@ni.com]
Sent: Wednesday, = September 10, 2014 9:47 PM
To: Juergen = Schoenwaelder
Cc: netconf@ietf.org; ietfdbh
Subject: = Re: [Netconf] L2 topology discovery with = NETCONF

 

Thanks = guys.

Yes, LLDP is = an alternative in my research. Either way, I guess we need some way to = fetch those distributed info from switches, in order to build the = topology. In the case of NETCONF, those switches must announce and = support an extra capability of a read-only YANG module translated from = the according MIB.

What I'm = worried about is the lack of a standard-defined YANG module for this = purpose. Different vendors may implement their own YANG modules if they = ever have one. It's thus hard to discover the network topology when = there are switches from different vendors, or at least not = scalable.

To me, = missing a standard module may limit the usage of NETCONF in this area. = People will have to fall back and use SNMP to read MIB on different = switches.

So I want to = know if there is something defined in NETCONF standard pertaining to L2 = topology discovery. If not, is there any plan for that? =

Best = regards,
Eric =

Juergen Schoenwaelder = <j.schoenwaelder@jaco= bs-university.de> wrote on 2014/09/10 19:34:16:

> = From: Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de>
> To: Jing Zhao <jing.zhao@ni.com>, =
> Cc: netconf@ietf.org =
> Date: 2014/09/10 = 19:34
> Subject: = Re: [Netconf] L2 topology discovery with NETCONF =
>
> = Hi,
>
> you can turn a MIB module into a = read-only YANG model following RFC
> 6643. While L2 = discovery via MIB modules may work in certain
> = situations, using something like LLDP and an interface to = extract
> information from stations speaking LLDP may be = an alternative to
> consider.
> =
> /js
>
> On Wed, Sep 10, = 2014 at 11:13:43AM +0800, Jing Zhao wrote:
> > Hi = all,
> >
> > I'm working on a = NETCONF research project hoping to find out a way to
> = > build layer 2 network topology. There are some open algorithms to = build
> > topology based on the information read from = switch MIB.
> >
> > For example, = each switch port has one entry in MIB dot1dStpPortTable which =
> > includes designated switch id, designated port, = the root switch, etc.
> >
> > But = I'm looking for a way to use NETCONF to read the MIB from switches. =
> > What I can expect is that switches implement some = special YANG module
> > which maps to this MIB and = provides a new RPC function like, e.g.,
> > = get-stp-table.
> >
> > I think this = should be a normal use case for NETCONF. It's actually listed =
> > as one issue here.
> > =
> > But I cannot find anything related on the Web. = The most I can get is
> > ietf-routing.yang draft = listing at www.netconfcentral.org. So is there any
> > = IETF RFC or draft defining something pertaining to layer 2 topology =
> > discovery using NETCONF?
> > =
> > Thanks!
> >
> = > Best regards,
> > Eric
> > = _______________________________________________
> > = Netconf mailing list
> > Netconf@ietf.org
> = > https://www.ietf.org/mailman/listinfo/netconf<= /span>
>
>
> -- =
> Juergen Schoenwaelder         =   Jacobs University Bremen gGmbH
> Phone: +49 421 = 200 3587         Campus Ring 1, 28759 Bremen, = Germany
> Fax:   +49 421 200 3103     =     <http://www.jacobs-university.de/>

------=_NextPart_000_009D_01CFCD53.B2F2CCF0-- From nobody Wed Sep 10 21:56:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D87B1A03E5 for ; Wed, 10 Sep 2014 21:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D8g9mYe3d7T for ; Wed, 10 Sep 2014 21:56:24 -0700 (PDT) Received: from ni.com (skprod3.natinst.com [130.164.80.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D522A1A03C8 for ; Wed, 10 Sep 2014 21:56:23 -0700 (PDT) Received: from us-aus-mgwout1.amer.corp.natinst.com (nb-snip2-1338.natinst.com [130.164.19.135]) by us-aus-skprod3.natinst.com (8.14.5/8.14.5) with ESMTP id s8B4uMJS024001; Wed, 10 Sep 2014 23:56:22 -0500 Received: from cn-sha-domino1.apac.corp.natinst.com ([130.164.14.198]) by us-aus-mgwout1.amer.corp.natinst.com (Lotus Domino Release 8.5.3FP6) with ESMTP id 2014091023562131-1133850 ; Wed, 10 Sep 2014 23:56:21 -0500 In-Reply-To: <009c01cfcd75$3a0186c0$ae049440$@comcast.net> References: <20140910113416.GB99920@elstar.local> <009c01cfcd75$3a0186c0$ae049440$@comcast.net> To: "ietfdbh" MIME-Version: 1.0 X-KeepSent: 27BD0EBA:9D478CBD-48257D50:0016E43D; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 From: Jing Zhao Message-ID: Date: Thu, 11 Sep 2014 12:56:21 +0800 X-MIMETrack: Serialize by Router on Nimbus/SHA/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/11/2014 12:56:21 PM, Serialize complete at 09/11/2014 12:56:21 PM, Itemize by SMTP Server on US-AUS-MGWOut1/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/10/2014 11:56:21 PM, Serialize by Router on US-AUS-MGWOut1/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/10/2014 11:56:22 PM, Serialize complete at 09/10/2014 11:56:22 PM Content-Type: multipart/alternative; boundary="=_alternative 001B212348257D50_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-09-11_01:2014-09-09,2014-09-11,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/181dS4B4M8zXKqPIS76aY3tzk5A Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 04:56:26 -0000 This is a multipart message in MIME format. --=_alternative 001B212348257D50_= Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="GB2312" VGhhbmtzLg0KDQpNeSBjb25jZXJuIGlzIHRoYXQgbm90IGFsbCBzd2l0Y2hlcyBhbGxvdyBhY2Nl c3MgdG8gdGhhdCBNSUIgdmlhIE5FVENPTkYuIA0KQnV0IHllcywgYWRkaW5nIGEgc3RhbmRhcmQg bW9kZWwgZG9lc24ndCBoZWxwIHdoYXRzb2V2ZXIuDQoNClRoZW4gc2hvdWxkIEkgdXNlIFNOTVAg aW5zdGVhZCBvZiBORVRDT05GPyBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYXMgDQpsb25nIGFz IFNOTVAgaXMgZW5hYmxlZCBvbiBhIHN3aXRjaCwgd2UgY2FuIGFjY2VzcyB0aGF0IE1JQiB2aWEg U05NUC4gQnV0IA0KZXZlbiBpZiBORVRDT05GIGlzIGVuYWJsZWQsIHdlIHN0aWxsIG1heSBub3Qg YWNjZXNzIHRoYXQgTUlCIHZpYSBORVRDT05GLCANCmJlY2F1c2UgdGhhdCBzd2l0Y2ggdmVuZG9y IG1heSBub3QgdHJhbnNsYXRlIHRoYXQgTUlCIHRvIGEgWUFORyBtb2R1bGUuIA0KV2lsbCB0aGlz IGJlIGEgcmVhbCBwcm9ibGVtPw0KDQpTbyBhY2NvcmRpbmcgdG8geW91ciBleHBlcmllbmNlLCB3 aGVuIHRoZXJlIGFyZSBzd2l0Y2hlcyBmcm9tIGRpZmZlcmVudCANCnZlbmRvcnMgaW4gYSBzdWJu ZXQsIHdoaWNoIHByb3RvY29sIHNob3VsZCBJIHVzZSB0byBmZXRjaCB0aGUgTUlCIGZyb20gDQp0 aG9zZSBzd2l0Y2hlcz8NCg0KQmVzdCByZWdhcmRzLA0KRXJpYw0KDQoiaWV0ZmRiaCIgPGlldGZk YmhAY29tY2FzdC5uZXQ+IHdyb3RlIG9uIDIwMTQvMDkvMTEgMTI6MDI6Mzc6DQoNCj4gRnJvbTog ImlldGZkYmgiIDxpZXRmZGJoQGNvbWNhc3QubmV0Pg0KPiBUbzogIidKaW5nIFpoYW8nIiA8amlu Zy56aGFvQG5pLmNvbT4sICInSnVlcmdlbiBTY2hvZW53YWVsZGVyJyIgDQo+IDxqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+LCANCj4gQ2M6IDxuZXRjb25mQGlldGYub3JnPg0K PiBEYXRlOiAyMDE0LzA5LzExIDEyOjAyDQo+IFN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gTDIgdG9w b2xvZ3kgZGlzY292ZXJ5IHdpdGggTkVUQ09ORg0KPiANCj4gSGksDQo+IA0KPiBJIGRvbqGvdCB1 bmRlcnN0YW5kIHdoeSB5b3UgdGhpbmsgdGhlIGxhY2sgb2YgYSBzdGFuZGFyZCBZQU5HIG1vZHVs ZSANCj4gaXMgYSBwcm9ibGVtIGZvciBkaXNjb3ZlcmluZyBuZXR3b3JrIHRvcG9sb2d5Lg0KPiBU aGVyZSBhcmUgc3RhbmRhcmQgTUlCIG1vZHVsZXMgc3VwcG9ydGluZyBMTERQLCBhbmQgZm9yIGRp c2NvdmVyaW5nIA0KPiB0aGUgbmV0d29yayB0b3BvbG9neSwgdGhleSBjYW4gYmUgcmVhZCB1c2lu ZyBORVRDT05GLCBmb3IgdGhvc2Ugd2hvIA0KPiB3YW50IHRvIHVzZSBORVRDT05GLCBhbmQgdGhl eSBjYW4gYmUgcmVhZCB1c2luZyBTTk1QIGZvciB0aG9zZSB3aG8gDQo+IHdhbnQgdG8gdXNlIFNO TVAuDQo+IFRoYXQgYWN0dWFsbHkgZm9sbG93cyB0aGUgb3JpZ2luYWwgaW50ZW50aW9uIG9mIGhh dmluZyBhIHN0YW5kYXJkIA0KPiBNSUIgdGhhdCBjb3VsZCBiZSBhY2Nlc3NlZCB1c2luZyBkaWZm ZXJlbnQgcHJvdG9jb2xzLg0KPiANCj4gVGhlIG9ubHkgcGxhY2Ugd2hlcmUgdGhlIE1JQiBpcyBp bmFkZXF1YXRlIGlzIGZvciBjb25maWd1cmluZyB0aGUgDQo+IHJlYWQtd3JpdGUgb2JqZWN0cyBp biB0aGUgUkZDMjkyMiBwdG9wb0NvbmZpZ0dyb3VwIGFuZCB0aGUgTExEUC1NSUIgDQo+IGxsZHBD b25maWd1cmF0aW9uIGdyb3Vwcy4NCj4gQnV0IHNpbmNlIG1vc3QgU05NUCBkZXBsb3ltZW50cyBk b26hr3Qgc3VwcG9ydCBTTk1QIFNFVHMsIHRoZXNlIE1JQiANCj4gb2JqZWN0cyBwcm9iYWJseSBh cmVuoa90IHVzZWQgZGlyZWN0bHkgYW55d2F5Lg0KPiBJZiB0aGV5IGFyZSB1c2VkLCBidXQgY29u ZmlndXJlZCB2aWEgQ0xJIGNvbW1hbmRzIG9yIG90aGVyIA0KPiBtZWNoYW5pc21zLCB0aGVuIGEg WUFORyBtb2R1bGUgdG8gY29uZmlndXJlIHRoZW0gbWlnaHQgYmUgaGVscGZ1bC4NCj4gDQo+IERh dmlkIEhhcnJpbmd0b24NCj4gaWV0ZmRiaEBjb21jYXN0Lm5ldA0KPiArMS02MDMtODI4LTE0MDEN Cj4gRnJvbTogSmluZyBaaGFvIFttYWlsdG86amluZy56aGFvQG5pLmNvbV0gDQo+IFNlbnQ6IFdl ZG5lc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE0IDk6NDcgUE0NCj4gVG86IEp1ZXJnZW4gU2Nob2Vu d2FlbGRlcg0KPiBDYzogbmV0Y29uZkBpZXRmLm9yZzsgaWV0ZmRiaA0KPiBTdWJqZWN0OiBSZTog W05ldGNvbmZdIEwyIHRvcG9sb2d5IGRpc2NvdmVyeSB3aXRoIE5FVENPTkYNCj4gDQo+IFRoYW5r cyBndXlzLiANCj4gDQo+IFllcywgTExEUCBpcyBhbiBhbHRlcm5hdGl2ZSBpbiBteSByZXNlYXJj aC4gRWl0aGVyIHdheSwgSSBndWVzcyB3ZSANCj4gbmVlZCBzb21lIHdheSB0byBmZXRjaCB0aG9z ZSBkaXN0cmlidXRlZCBpbmZvIGZyb20gc3dpdGNoZXMsIGluIA0KPiBvcmRlciB0byBidWlsZCB0 aGUgdG9wb2xvZ3kuIEluIHRoZSBjYXNlIG9mIE5FVENPTkYsIHRob3NlIHN3aXRjaGVzIA0KPiBt dXN0IGFubm91bmNlIGFuZCBzdXBwb3J0IGFuIGV4dHJhIGNhcGFiaWxpdHkgb2YgYSByZWFkLW9u bHkgWUFORyANCj4gbW9kdWxlIHRyYW5zbGF0ZWQgZnJvbSB0aGUgYWNjb3JkaW5nIE1JQi4gDQo+ IA0KPiBXaGF0IEknbSB3b3JyaWVkIGFib3V0IGlzIHRoZSBsYWNrIG9mIGEgc3RhbmRhcmQtZGVm aW5lZCBZQU5HIG1vZHVsZQ0KPiBmb3IgdGhpcyBwdXJwb3NlLiBEaWZmZXJlbnQgdmVuZG9ycyBt YXkgaW1wbGVtZW50IHRoZWlyIG93biBZQU5HIA0KPiBtb2R1bGVzIGlmIHRoZXkgZXZlciBoYXZl IG9uZS4gSXQncyB0aHVzIGhhcmQgdG8gZGlzY292ZXIgdGhlIA0KPiBuZXR3b3JrIHRvcG9sb2d5 IHdoZW4gdGhlcmUgYXJlIHN3aXRjaGVzIGZyb20gZGlmZmVyZW50IHZlbmRvcnMsIG9yIA0KPiBh dCBsZWFzdCBub3Qgc2NhbGFibGUuIA0KPiANCj4gVG8gbWUsIG1pc3NpbmcgYSBzdGFuZGFyZCBt b2R1bGUgbWF5IGxpbWl0IHRoZSB1c2FnZSBvZiBORVRDT05GIGluIA0KPiB0aGlzIGFyZWEuIFBl b3BsZSB3aWxsIGhhdmUgdG8gZmFsbCBiYWNrIGFuZCB1c2UgU05NUCB0byByZWFkIE1JQiBvbg0K PiBkaWZmZXJlbnQgc3dpdGNoZXMuIA0KPiANCj4gU28gSSB3YW50IHRvIGtub3cgaWYgdGhlcmUg aXMgc29tZXRoaW5nIGRlZmluZWQgaW4gTkVUQ09ORiBzdGFuZGFyZCANCj4gcGVydGFpbmluZyB0 byBMMiB0b3BvbG9neSBkaXNjb3ZlcnkuIElmIG5vdCwgaXMgdGhlcmUgYW55IHBsYW4gZm9yIHRo YXQ/IA0KDQo+IA0KPiBCZXN0IHJlZ2FyZHMsIA0KPiBFcmljIA0KPiANCj4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlIA0K PiBvbiAyMDE0LzA5LzEwIDE5OjM0OjE2Og0KPiANCj4gPiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gDQo+ID4gVG86IEpp bmcgWmhhbyA8amluZy56aGFvQG5pLmNvbT4sIA0KPiA+IENjOiBuZXRjb25mQGlldGYub3JnIA0K PiA+IERhdGU6IDIwMTQvMDkvMTAgMTk6MzQgDQo+ID4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBM MiB0b3BvbG9neSBkaXNjb3Zlcnkgd2l0aCBORVRDT05GIA0KPiA+IA0KPiA+IEhpLA0KPiA+IA0K PiA+IHlvdSBjYW4gdHVybiBhIE1JQiBtb2R1bGUgaW50byBhIHJlYWQtb25seSBZQU5HIG1vZGVs IGZvbGxvd2luZyBSRkMNCj4gPiA2NjQzLiBXaGlsZSBMMiBkaXNjb3ZlcnkgdmlhIE1JQiBtb2R1 bGVzIG1heSB3b3JrIGluIGNlcnRhaW4NCj4gPiBzaXR1YXRpb25zLCB1c2luZyBzb21ldGhpbmcg bGlrZSBMTERQIGFuZCBhbiBpbnRlcmZhY2UgdG8gZXh0cmFjdA0KPiA+IGluZm9ybWF0aW9uIGZy b20gc3RhdGlvbnMgc3BlYWtpbmcgTExEUCBtYXkgYmUgYW4gYWx0ZXJuYXRpdmUgdG8NCj4gPiBj b25zaWRlci4NCj4gPiANCj4gPiAvanMNCj4gPiANCj4gPiBPbiBXZWQsIFNlcCAxMCwgMjAxNCBh dCAxMToxMzo0M0FNICswODAwLCBKaW5nIFpoYW8gd3JvdGU6DQo+ID4gPiBIaSBhbGwsDQo+ID4g PiANCj4gPiA+IEknbSB3b3JraW5nIG9uIGEgTkVUQ09ORiByZXNlYXJjaCBwcm9qZWN0IGhvcGlu ZyB0byBmaW5kIG91dCBhIHdheSANCnRvIA0KPiA+ID4gYnVpbGQgbGF5ZXIgMiBuZXR3b3JrIHRv cG9sb2d5LiBUaGVyZSBhcmUgc29tZSBvcGVuIGFsZ29yaXRobXMgdG8gDQpidWlsZCANCj4gPiA+ IHRvcG9sb2d5IGJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiByZWFkIGZyb20gc3dpdGNoIE1JQi4N Cj4gPiA+IA0KPiA+ID4gRm9yIGV4YW1wbGUsIGVhY2ggc3dpdGNoIHBvcnQgaGFzIG9uZSBlbnRy eSBpbiBNSUIgDQo+IGRvdDFkU3RwUG9ydFRhYmxlIHdoaWNoIA0KPiA+ID4gaW5jbHVkZXMgZGVz aWduYXRlZCBzd2l0Y2ggaWQsIGRlc2lnbmF0ZWQgcG9ydCwgdGhlIHJvb3Qgc3dpdGNoLCANCmV0 Yy4NCj4gPiA+IA0KPiA+ID4gQnV0IEknbSBsb29raW5nIGZvciBhIHdheSB0byB1c2UgTkVUQ09O RiB0byByZWFkIHRoZSBNSUIgZnJvbSANCnN3aXRjaGVzLiANCj4gPiA+IFdoYXQgSSBjYW4gZXhw ZWN0IGlzIHRoYXQgc3dpdGNoZXMgaW1wbGVtZW50IHNvbWUgc3BlY2lhbCBZQU5HIA0KbW9kdWxl IA0KPiA+ID4gd2hpY2ggbWFwcyB0byB0aGlzIE1JQiBhbmQgcHJvdmlkZXMgYSBuZXcgUlBDIGZ1 bmN0aW9uIGxpa2UsIGUuZy4sIA0KPiA+ID4gZ2V0LXN0cC10YWJsZS4NCj4gPiA+IA0KPiA+ID4g SSB0aGluayB0aGlzIHNob3VsZCBiZSBhIG5vcm1hbCB1c2UgY2FzZSBmb3IgTkVUQ09ORi4gSXQn cyANCj4gYWN0dWFsbHkgbGlzdGVkIA0KPiA+ID4gYXMgb25lIGlzc3VlIGhlcmUuDQo+ID4gPiAN Cj4gPiA+IEJ1dCBJIGNhbm5vdCBmaW5kIGFueXRoaW5nIHJlbGF0ZWQgb24gdGhlIFdlYi4gVGhl IG1vc3QgSSBjYW4gZ2V0IGlzIA0KDQo+ID4gPiBpZXRmLXJvdXRpbmcueWFuZyBkcmFmdCBsaXN0 aW5nIGF0IHd3dy5uZXRjb25mY2VudHJhbC5vcmcuIFNvIA0KaXN0aGVyZSBhbnkgDQo+ID4gPiBJ RVRGIFJGQyBvciBkcmFmdCBkZWZpbmluZyBzb21ldGhpbmcgcGVydGFpbmluZyB0byBsYXllciAy IHRvcG9sb2d5IA0KPiA+ID4gZGlzY292ZXJ5IHVzaW5nIE5FVENPTkY/DQo+ID4gPiANCj4gPiA+ IFRoYW5rcyENCj4gPiA+IA0KPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gRXJpYw0KPiA+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IE5l dGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gPiBOZXRjb25mQGlldGYub3JnDQo+ID4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiANCj4gPiANCj4gPiAt LSANCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5 IEJyZW1lbiBnR21iSA0KPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVz IFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMx MDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= --=_alternative 001B212348257D50_= Content-Transfer-Encoding: base64 Content-Type: text/html; charset="GB2312" PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcy48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk15IGNvbmNlcm4gaXMgdGhhdCBub3QgYWxs IHN3aXRjaGVzDQphbGxvdyBhY2Nlc3MgdG8gdGhhdCBNSUIgdmlhIE5FVENPTkYuIEJ1dCB5ZXMs IGFkZGluZyBhIHN0YW5kYXJkIG1vZGVsDQpkb2Vzbid0IGhlbHAgd2hhdHNvZXZlci48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZW4gc2hvdWxkIEkg dXNlIFNOTVAgaW5zdGVhZCBvZiBORVRDT05GPw0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGFz IGxvbmcgYXMgU05NUCBpcyBlbmFibGVkIG9uIGEgc3dpdGNoLCB3ZSBjYW4NCmFjY2VzcyB0aGF0 IE1JQiB2aWEgU05NUC4gQnV0IGV2ZW4gaWYgTkVUQ09ORiBpcyBlbmFibGVkLCB3ZSBzdGlsbCBt YXkNCm5vdCBhY2Nlc3MgdGhhdCBNSUIgdmlhIE5FVENPTkYsIGJlY2F1c2UgdGhhdCBzd2l0Y2gg dmVuZG9yIG1heSBub3QgdHJhbnNsYXRlDQp0aGF0IE1JQiB0byBhIFlBTkcgbW9kdWxlLiBXaWxs IHRoaXMgYmUgYSByZWFsIHByb2JsZW0/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5TbyBhY2NvcmRpbmcgdG8geW91ciBleHBlcmllbmNlLCB3aGVuDQp0 aGVyZSBhcmUgc3dpdGNoZXMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycyBpbiBhIHN1Ym5ldCwgd2hp Y2ggcHJvdG9jb2wgc2hvdWxkDQpJIHVzZSB0byBmZXRjaCB0aGUgTUlCIGZyb20gdGhvc2Ugc3dp dGNoZXM/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5C ZXN0IHJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5F cmljPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7aWV0ZmRiaCZxdW90 OyAmbHQ7aWV0ZmRiaEBjb21jYXN0Lm5ldCZndDsgd3JvdGUNCm9uIDIwMTQvMDkvMTEgMTI6MDI6 Mzc6PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDtpZXRmZGJoJnF1b3Q7ICZsdDtpZXRmZGJo QGNvbWNhc3QubmV0Jmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBU bzogJnF1b3Q7J0ppbmcgWmhhbycmcXVvdDsgJmx0O2ppbmcuemhhb0BuaS5jb20mZ3Q7LA0KJnF1 b3Q7J0p1ZXJnZW4gU2Nob2Vud2FlbGRlcicmcXVvdDsgPGJyPg0KJmd0OyAmbHQ7ai5zY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0OywgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IENjOiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRGF0ZTogMjAxNC8wOS8xMSAxMjowMjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTdWJqZWN0OiBSRTogW05ldGNvbmZdIEwy IHRvcG9sb2d5IGRpc2NvdmVyeQ0Kd2l0aCBORVRDT05GPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgSGksPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyBJIGRvbqGvdCB1bmRlcnN0YW5kIHdoeSB5b3UgdGhpbmsgdGhlIGxhY2sgb2YNCmEgc3RhbmRh cmQgWUFORyBtb2R1bGUgPGJyPg0KJmd0OyBpcyBhIHByb2JsZW0gZm9yIGRpc2NvdmVyaW5nIG5l dHdvcmsgdG9wb2xvZ3kuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRo ZXJlIGFyZSBzdGFuZGFyZCBNSUIgbW9kdWxlcyBzdXBwb3J0aW5nIExMRFAsDQphbmQgZm9yIGRp c2NvdmVyaW5nIDxicj4NCiZndDsgdGhlIG5ldHdvcmsgdG9wb2xvZ3ksIHRoZXkgY2FuIGJlIHJl YWQgdXNpbmcgTkVUQ09ORiwgZm9yIHRob3NlIHdobw0KPGJyPg0KJmd0OyB3YW50IHRvIHVzZSBO RVRDT05GLCBhbmQgdGhleSBjYW4gYmUgcmVhZCB1c2luZyBTTk1QIGZvciB0aG9zZSB3aG8NCjxi cj4NCiZndDsgd2FudCB0byB1c2UgU05NUC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgVGhhdCBhY3R1YWxseSBmb2xsb3dzIHRoZSBvcmlnaW5hbCBpbnRlbnRpb24NCm9m IGhhdmluZyBhIHN0YW5kYXJkIDxicj4NCiZndDsgTUlCIHRoYXQgY291bGQgYmUgYWNjZXNzZWQg dXNpbmcgZGlmZmVyZW50IHByb3RvY29scy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRo ZSBvbmx5IHBsYWNlIHdoZXJlIHRoZSBNSUIgaXMgaW5hZGVxdWF0ZSBpcw0KZm9yIGNvbmZpZ3Vy aW5nIHRoZSA8YnI+DQomZ3Q7IHJlYWQtd3JpdGUgb2JqZWN0cyBpbiB0aGUgUkZDMjkyMiBwdG9w b0NvbmZpZ0dyb3VwIGFuZCB0aGUgTExEUC1NSUINCjxicj4NCiZndDsgbGxkcENvbmZpZ3VyYXRp b24gZ3JvdXBzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBCdXQgc2lu Y2UgbW9zdCBTTk1QIGRlcGxveW1lbnRzIGRvbqGvdCBzdXBwb3J0DQpTTk1QIFNFVHMsIHRoZXNl IE1JQiA8YnI+DQomZ3Q7IG9iamVjdHMgcHJvYmFibHkgYXJlbqGvdCB1c2VkIGRpcmVjdGx5IGFu eXdheS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSWYgdGhleSBhcmUg dXNlZCwgYnV0IGNvbmZpZ3VyZWQgdmlhIENMSSBjb21tYW5kcw0Kb3Igb3RoZXIgPGJyPg0KJmd0 OyBtZWNoYW5pc21zLCB0aGVuIGEgWUFORyBtb2R1bGUgdG8gY29uZmlndXJlIHRoZW0gbWlnaHQg YmUgaGVscGZ1bC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERhdmlkIEhhcnJpbmd0b248 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgaWV0ZmRiaEBjb21jYXN0Lm5l dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyArMS02MDMtODI4LTE0MDE8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJvbTogSmluZyBaaGFvIFs8 L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpqaW5nLnpoYW9AbmkuY29tPjx0dD48Zm9udCBzaXpl PTI+bWFpbHRvOmppbmcuemhhb0BuaS5jb208L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9 Mj5dDQo8YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE0IDk6NDcg UE08YnI+DQomZ3Q7IFRvOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXI8YnI+DQomZ3Q7IENjOiBuZXRj b25mQGlldGYub3JnOyBpZXRmZGJoPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW05ldGNvbmZdIEwy IHRvcG9sb2d5IGRpc2NvdmVyeSB3aXRoIE5FVENPTkY8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IFRoYW5rcyBndXlzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgWWVzLCBMTERQIGlzIGFuIGFs dGVybmF0aXZlIGluIG15IHJlc2VhcmNoLiBFaXRoZXIgd2F5LCBJIGd1ZXNzIHdlDQo8YnI+DQom Z3Q7IG5lZWQgc29tZSB3YXkgdG8gZmV0Y2ggdGhvc2UgZGlzdHJpYnV0ZWQgaW5mbyBmcm9tIHN3 aXRjaGVzLCBpbiA8YnI+DQomZ3Q7IG9yZGVyIHRvIGJ1aWxkIHRoZSB0b3BvbG9neS4gSW4gdGhl IGNhc2Ugb2YgTkVUQ09ORiwgdGhvc2Ugc3dpdGNoZXMNCjxicj4NCiZndDsgbXVzdCBhbm5vdW5j ZSBhbmQgc3VwcG9ydCBhbiBleHRyYSBjYXBhYmlsaXR5IG9mIGEgcmVhZC1vbmx5IFlBTkcNCjxi cj4NCiZndDsgbW9kdWxlIHRyYW5zbGF0ZWQgZnJvbSB0aGUgYWNjb3JkaW5nIE1JQi4gPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFdoYXQgSSdtIHdvcnJpZWQgYWJvdXQgaXMgdGhlIGxhY2sgb2YgYSBz dGFuZGFyZC1kZWZpbmVkIFlBTkcgbW9kdWxlPGJyPg0KJmd0OyBmb3IgdGhpcyBwdXJwb3NlLiBE aWZmZXJlbnQgdmVuZG9ycyBtYXkgaW1wbGVtZW50IHRoZWlyIG93biBZQU5HIDxicj4NCiZndDsg bW9kdWxlcyBpZiB0aGV5IGV2ZXIgaGF2ZSBvbmUuIEl0J3MgdGh1cyBoYXJkIHRvIGRpc2NvdmVy IHRoZSA8YnI+DQomZ3Q7IG5ldHdvcmsgdG9wb2xvZ3kgd2hlbiB0aGVyZSBhcmUgc3dpdGNoZXMg ZnJvbSBkaWZmZXJlbnQgdmVuZG9ycywgb3INCjxicj4NCiZndDsgYXQgbGVhc3Qgbm90IHNjYWxh YmxlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVG8gbWUsIG1pc3NpbmcgYSBzdGFuZGFyZCBtb2R1 bGUgbWF5IGxpbWl0IHRoZSB1c2FnZSBvZiBORVRDT05GIGluDQo8YnI+DQomZ3Q7IHRoaXMgYXJl YS4gUGVvcGxlIHdpbGwgaGF2ZSB0byBmYWxsIGJhY2sgYW5kIHVzZSBTTk1QIHRvIHJlYWQgTUlC DQpvbjxicj4NCiZndDsgZGlmZmVyZW50IHN3aXRjaGVzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg U28gSSB3YW50IHRvIGtub3cgaWYgdGhlcmUgaXMgc29tZXRoaW5nIGRlZmluZWQgaW4gTkVUQ09O RiBzdGFuZGFyZA0KPGJyPg0KJmd0OyBwZXJ0YWluaW5nIHRvIEwyIHRvcG9sb2d5IGRpc2NvdmVy eS4gSWYgbm90LCBpcyB0aGVyZSBhbnkgcGxhbiBmb3INCnRoYXQ/IDxicj4NCiZndDsgPGJyPg0K Jmd0OyBCZXN0IHJlZ2FyZHMsIDxicj4NCiZndDsgRXJpYyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg SnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGUmZ3Q7DQp3cm90ZSA8YnI+DQomZ3Q7IG9uIDIwMTQvMDkvMTAgMTk6MzQ6MTY6PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsgRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNj aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgVG86 IEppbmcgWmhhbyAmbHQ7amluZy56aGFvQG5pLmNvbSZndDssIDxicj4NCiZndDsgJmd0OyBDYzog bmV0Y29uZkBpZXRmLm9yZyA8YnI+DQomZ3Q7ICZndDsgRGF0ZTogMjAxNC8wOS8xMCAxOTozNCA8 YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtOZXRjb25mXSBMMiB0b3BvbG9neSBkaXNjb3Zl cnkgd2l0aCBORVRDT05GIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSGksPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyB5b3UgY2FuIHR1cm4gYSBNSUIgbW9kdWxlIGludG8g YSByZWFkLW9ubHkgWUFORyBtb2RlbCBmb2xsb3dpbmcNClJGQzxicj4NCiZndDsgJmd0OyA2NjQz LiBXaGlsZSBMMiBkaXNjb3ZlcnkgdmlhIE1JQiBtb2R1bGVzIG1heSB3b3JrIGluIGNlcnRhaW48 YnI+DQomZ3Q7ICZndDsgc2l0dWF0aW9ucywgdXNpbmcgc29tZXRoaW5nIGxpa2UgTExEUCBhbmQg YW4gaW50ZXJmYWNlIHRvIGV4dHJhY3Q8YnI+DQomZ3Q7ICZndDsgaW5mb3JtYXRpb24gZnJvbSBz dGF0aW9ucyBzcGVha2luZyBMTERQIG1heSBiZSBhbiBhbHRlcm5hdGl2ZQ0KdG88YnI+DQomZ3Q7 ICZndDsgY29uc2lkZXIuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAvanM8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIFdlZCwgU2VwIDEwLCAyMDE0IGF0IDExOjEzOjQz QU0gKzA4MDAsIEppbmcgWmhhbyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBhbGwsPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSdtIHdvcmtpbmcgb24gYSBO RVRDT05GIHJlc2VhcmNoIHByb2plY3QgaG9waW5nIHRvIGZpbmQNCm91dCBhIHdheSB0byA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBidWlsZCBsYXllciAyIG5ldHdvcmsgdG9wb2xvZ3kuIFRoZXJlIGFy ZSBzb21lIG9wZW4gYWxnb3JpdGhtcw0KdG8gYnVpbGQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdG9w b2xvZ3kgYmFzZWQgb24gdGhlIGluZm9ybWF0aW9uIHJlYWQgZnJvbSBzd2l0Y2ggTUlCLjxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEZvciBleGFtcGxlLCBlYWNoIHN3 aXRjaCBwb3J0IGhhcyBvbmUgZW50cnkgaW4gTUlCIDxicj4NCiZndDsgZG90MWRTdHBQb3J0VGFi bGUgd2hpY2ggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW5jbHVkZXMgZGVzaWduYXRlZCBzd2l0Y2gg aWQsIGRlc2lnbmF0ZWQgcG9ydCwgdGhlIHJvb3QNCnN3aXRjaCwgZXRjLjxicj4NCiZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEJ1dCBJJ20gbG9va2luZyBmb3IgYSB3YXkgdG8g dXNlIE5FVENPTkYgdG8gcmVhZCB0aGUgTUlCDQpmcm9tIHN3aXRjaGVzLiA8YnI+DQomZ3Q7ICZn dDsgJmd0OyBXaGF0IEkgY2FuIGV4cGVjdCBpcyB0aGF0IHN3aXRjaGVzIGltcGxlbWVudCBzb21l IHNwZWNpYWwNCllBTkcgbW9kdWxlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHdoaWNoIG1hcHMgdG8g dGhpcyBNSUIgYW5kIHByb3ZpZGVzIGEgbmV3IFJQQyBmdW5jdGlvbiBsaWtlLA0KZS5nLiwgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgZ2V0LXN0cC10YWJsZS48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGEgbm9ybWFsIHVzZSBjYXNl IGZvciBORVRDT05GLiBJdCdzDQo8YnI+DQomZ3Q7IGFjdHVhbGx5IGxpc3RlZCA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBhcyBvbmUgaXNzdWUgaGVyZS48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgJmd0OyBCdXQgSSBjYW5ub3QgZmluZCBhbnl0aGluZyByZWxhdGVkIG9uIHRoZSBX ZWIuIFRoZSBtb3N0DQpJIGNhbiBnZXQgaXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaWV0Zi1yb3V0 aW5nLnlhbmcgZHJhZnQgbGlzdGluZyBhdCA8L2ZvbnQ+PC90dD48YSBocmVmPXd3dy5uZXRjb25m Y2VudHJhbC5vcmc+PHR0Pjxmb250IHNpemU9Mj53d3cubmV0Y29uZmNlbnRyYWwub3JnPC9mb250 PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Lg0KU28gaXN0aGVyZSBhbnkgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgSUVURiBSRkMgb3IgZHJhZnQgZGVmaW5pbmcgc29tZXRoaW5nIHBlcnRhaW5pbmcg dG8gbGF5ZXINCjIgdG9wb2xvZ3kgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZGlzY292ZXJ5IHVzaW5n IE5FVENPTkY/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhbmtz ITxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcyw8 YnI+DQomZ3Q7ICZndDsgJmd0OyBFcmljPGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBO ZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IE5ldGNvbmZAaWV0Zi5vcmc8 YnI+DQomZ3Q7ICZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvZm9udD48L3R0PjwvYT48dHQ+PGZv bnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IC0tIDxicj4NCiZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBKYWNvYnMNClVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPg0K Jmd0OyAmZ3Q7IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBDYW1wdXMgUmluZw0KMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55PGJyPg0KJmd0OyAmZ3Q7 IEZheDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl LyI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvZm9u dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDs8L2ZvbnQ+PC90dD4NCg== --=_alternative 001B212348257D50_=-- From vathsala.narayanan@gmail.com Wed Sep 10 10:41:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45641A702F for ; Wed, 10 Sep 2014 10:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5sIxFNxDLAR for ; Wed, 10 Sep 2014 10:41:24 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12811A7028 for ; Wed, 10 Sep 2014 10:41:24 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 142so2316680ykq.6 for ; Wed, 10 Sep 2014 10:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=V8z3ryPpKOv90qtL44k4PME9kClLuahIEiAUTWUDcsg=; b=Ta5TSyXIMJXlqPR5nWmSHBB8VPABLOoa0UXgl9JDkIdpjIP/MxM4/UNv2Iwzb/gYuf Aeyii0wNBsS/XoEjAJR4GTt8RyQMuz73c3M0HofeV1Y1jxvVQVA+xAqfp2vjCOjPjubB XXm1uExMCsykfZoIfQT8xBfoHVmHTjMbufMDqrJwgz4lOlxANNFiZ0HkXxbbi4Y2eNxp FYnczqKe9geQv2DQd+Ckx/LQGVl6KBqJ0kip4Dm/Ejzmr71CV1P6fkB/WmkVp1WoKvI5 IUiQ8Q4b7BYhEiRxkHf7mGw/dlwXCT336U0OvDU801d+DtvD8Yw2dAmxveUYhcNzt3cL z80w== X-Received: by 10.236.31.4 with SMTP id l4mr1834909yha.158.1410370883790; Wed, 10 Sep 2014 10:41:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.123.134 with HTTP; Wed, 10 Sep 2014 10:41:03 -0700 (PDT) From: vathsala narayanan Date: Wed, 10 Sep 2014 23:11:03 +0530 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary=089e01177af587c8970502b98f1e Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/OCMRCF8n1rkks5hXfWrPOXKrnG0 X-Mailman-Approved-At: Thu, 11 Sep 2014 00:38:14 -0700 Subject: [Netconf] NETCONF- read-write objects retrieval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 17:45:04 -0000 --089e01177af587c8970502b98f1e Content-Type: text/plain; charset=UTF-8 Hi all, I'm currently working on a NETCONF research project. To understand the working of NETCONF, I have taken the mib objects (from std IP mib) ipForwarding and ipDefaultTTL as example. I have used a tool which generates a yang module that maps to this MIB and provide a new rpc function to configure values(say set-ipmib). My configuration is a success as I can see a rpc-reply from the server. But I'm looking for a way to retrieve the configured values. When I do a get/xget, I am able to see only the read-only objects getting listed. Is there a way to retrieve read-write objects through netconf? Best Regards, Vathsala --089e01177af587c8970502b98f1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm currently working on a = NETCONF research project. To understand the working of NETCONF, I have take= n the mib objects =C2=A0(from std IP mib) ipForwarding and ipDefaultTTL as = example.

=C2=A0I have used a tool which generates = a yang module that maps to this MIB and provide a new rpc function to confi= gure values(say set-ipmib). My configuration =C2=A0is a success as I can se= e a rpc-reply from the server. But I'm looking for a way to retrieve th= e configured values. When I do a get/xget, I am able to see only the read-o= nly objects getting listed. Is there =C2=A0a way to retrieve read-write obj= ects through netconf?

Best Regards,
Vath= sala
--089e01177af587c8970502b98f1e-- From nobody Thu Sep 11 01:11:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B3D1A065F for ; Thu, 11 Sep 2014 01:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.551 X-Spam-Level: X-Spam-Status: No, score=-8.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaiwqLpMkzrc for ; Thu, 11 Sep 2014 01:11:21 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985071A0645 for ; Thu, 11 Sep 2014 01:11:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQLAOVYEVTGmAcV/2dsb2JhbABdA4JHIyNTVwSxCAEFBpZ2GgEJhnlUAYEKFniEAwEBAQECAQEBAQ8bHCULBQkCAgEIDQMBAwEBAQEKHQcbDAsUCQgCBAENBQgaiAwDCQgBDJ9HmTAIhmcBFwSFeIh6JiABDAQGAQkIgx6BHQWGTohlghaGbYwyhDyJEYNhbIEHQYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,504,1406606400"; d="scan'208,217"; a="71815225" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Sep 2014 04:10:53 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 11 Sep 2014 04:10:52 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 10:10:51 +0200 From: "Romascanu, Dan (Dan)" To: ietfdbh , 'Jing Zhao' , "'Juergen Schoenwaelder'" Thread-Topic: [Netconf] L2 topology discovery with NETCONF Thread-Index: AQHPzOnfByR6kYNj0Eq91P7g54I64Zv6f4gAgACJlICAACX7gIAAZqQQ Date: Thu, 11 Sep 2014 08:10:50 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C89848E@AZ-FFEXMB04.global.avaya.com> References: <20140910113416.GB99920@elstar.local> <009c01cfcd75$3a0186c0$ae049440$@comcast.net> In-Reply-To: <009c01cfcd75$3a0186c0$ae049440$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C89848EAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/25s38H673aHTJBzAOWbXArk3odo Cc: "netconf@ietf.org" Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:11:28 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89848EAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would strongly recommend using the MIB module defined in IEEE 802.1AB rat= her than RFC 2922. Regards, Dan From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ietfdbh Sent: Thursday, September 11, 2014 7:03 AM To: 'Jing Zhao'; 'Juergen Schoenwaelder' Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF Hi, I don't understand why you think the lack of a standard YANG module is a pr= oblem for discovering network topology. There are standard MIB modules supporting LLDP, and for discovering the net= work topology, they can be read using NETCONF, for those who want to use NE= TCONF, and they can be read using SNMP for those who want to use SNMP. That actually follows the original intention of having a standard MIB that = could be accessed using different protocols. The only place where the MIB is inadequate is for configuring the read-writ= e objects in the RFC2922 ptopoConfigGroup and the LLDP-MIB lldpConfiguratio= n groups. But since most SNMP deployments don't support SNMP SETs, these MIB objects = probably aren't used directly anyway. If they are used, but configured via CLI commands or other mechanisms, then= a YANG module to configure them might be helpful. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Jing Zhao [mailto:jing.zhao@ni.com] Sent: Wednesday, September 10, 2014 9:47 PM To: Juergen Schoenwaelder Cc: netconf@ietf.org; ietfdbh Subject: Re: [Netconf] L2 topology discovery with NETCONF Thanks guys. Yes, LLDP is an alternative in my research. Either way, I guess we need som= e way to fetch those distributed info from switches, in order to build the = topology. In the case of NETCONF, those switches must announce and support = an extra capability of a read-only YANG module translated from the accordin= g MIB. What I'm worried about is the lack of a standard-defined YANG module for th= is purpose. Different vendors may implement their own YANG modules if they = ever have one. It's thus hard to discover the network topology when there a= re switches from different vendors, or at least not scalable. To me, missing a standard module may limit the usage of NETCONF in this are= a. People will have to fall back and use SNMP to read MIB on different swit= ches. So I want to know if there is something defined in NETCONF standard pertain= ing to L2 topology discovery. If not, is there any plan for that? Best regards, Eric Juergen Schoenwaelder > wrote on 2014/09/10 19:34:16: > From: Juergen Schoenwaelder > > To: Jing Zhao >, > Cc: netconf@ietf.org > Date: 2014/09/10 19:34 > Subject: Re: [Netconf] L2 topology discovery with NETCONF > > Hi, > > you can turn a MIB module into a read-only YANG model following RFC > 6643. While L2 discovery via MIB modules may work in certain > situations, using something like LLDP and an interface to extract > information from stations speaking LLDP may be an alternative to > consider. > > /js > > On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote: > > Hi all, > > > > I'm working on a NETCONF research project hoping to find out a way to > > build layer 2 network topology. There are some open algorithms to build > > topology based on the information read from switch MIB. > > > > For example, each switch port has one entry in MIB dot1dStpPortTable wh= ich > > includes designated switch id, designated port, the root switch, etc. > > > > But I'm looking for a way to use NETCONF to read the MIB from switches. > > What I can expect is that switches implement some special YANG module > > which maps to this MIB and provides a new RPC function like, e.g., > > get-stp-table. > > > > I think this should be a normal use case for NETCONF. It's actually lis= ted > > as one issue here. > > > > But I cannot find anything related on the Web. The most I can get is > > ietf-routing.yang draft listing at www.netconfcentral.org. So is there = any > > IETF RFC or draft defining something pertaining to layer 2 topology > > discovery using NETCONF? > > > > Thanks! > > > > Best regards, > > Eric > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89848EAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would strongly recommen= d using the MIB module defined in IEEE 802.1AB rather than RFC 2922.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of ietfdbh
Sent: Thursday, September 11, 2014 7:03 AM
To: 'Jing Zhao'; 'Juergen Schoenwaelder'
Cc: netconf@ietf.org
Subject: Re: [Netconf] L2 topology discovery with NETCONF=

 

Hi,

 <= /p>

I don’t understand = why you think the lack of a standard YANG module is a problem for discoveri= ng network topology.

There are standard MIB mo= dules supporting LLDP, and for discovering the network topology, they can b= e read using NETCONF, for those who want to use NETCONF, and they can be read using SNMP for those who want to use SNMP.=

That actually follows the= original intention of having a standard MIB that could be accessed using d= ifferent protocols.

 <= /p>

The only place where the = MIB is inadequate is for configuring the read-write objects in the RFC2922 = ptopoConfigGroup and the LLDP-MIB lldpConfiguration groups.

But since most SNMP deplo= yments don’t support SNMP SETs, these MIB objects probably aren’= ;t used directly anyway.

If they are used, but con= figured via CLI commands or other mechanisms, then a YANG module to configu= re them might be helpful.

 <= /p>

David Harrington

= ietfdbh@comcast.net

+1-603-828-1401<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">

From: Jing Zha= o [mailto:jing.zhao@ni.com]
Sent: Wednesday, September 10, 2014 9:47 PM
To: Juergen Schoenwaelder
Cc: netconf@ietf.org; ietfdb= h
Subject: Re: [Netconf] L2 topology discovery with NETCONF=

 

Thanks guys.

Yes, LLDP is an alternative in my research. Either way, I guess = we need some way to fetch those distributed info from switches, in order to= build the topology. In the case of NETCONF, those switches must announce and support an extra capability of a read-only YANG module t= ranslated from the according MIB.

What I'm worried about is the lack of a standard-defined YANG mo= dule for this purpose. Different vendors may implement their own YANG modul= es if they ever have one. It's thus hard to discover the network topology when there are switches from different vendors, or at lea= st not scalable.

To me, missing a standard module may limit the usage of NETCONF = in this area. People will have to fall back and use SNMP to read MIB on dif= ferent switches.

So I want to know if there is something defined in NETCONF stand= ard pertaining to L2 topology discovery. If not, is there any plan for that= ?

Best regards,
Eric

Juergen Schoenwaelder <j.schoenwaelder@jacobs-universi= ty.de> wrote on 2014/09/10 19:34:16:

> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> To: Jing Zhao <jing.zhao@ni.com>,
> Cc: netconf@ietf.org
> Date: 2014/09/10 19:34
> Subject: Re: [Netconf] L2 topolog= y discovery with NETCONF
>
> Hi,
>
> you can turn a MIB module into a read-only YANG model following RF= C
> 6643. While L2 discovery via MIB modules may work in certain<= br> > situations, using something like LLDP and an interface to extract<= /tt>
> information from stations speaking LLDP may be an alternative to
> consider.
>
> /js
>
> On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote:
> > Hi all,
> >
> > I'm working on a NETCONF research project hoping to find out = a way to
> > build layer 2 network topology. There are some open algorithm= s to build
> > topology based on the information read from switch MIB.<= br> > >
> > For example, each switch port has one entry in MIB dot1dStpPo= rtTable which
> > includes designated switch id, designated port, the root swit= ch, etc.
> >
> > But I'm looking for a way to use NETCONF to read the MIB from= switches.
> > What I can expect is that switches implement some special YAN= G module
> > which maps to this MIB and provides a new RPC function like, = e.g.,
> > get-stp-table.
> >
> > I think this should be a normal use case for NETCONF. It's ac= tually listed
> > as one issue here.
> >
> > But I cannot find anything related on the Web. The most I can= get is
> > ietf-routing.yang draft listing at www.netconfcentra= l.org. So is there any
> > IETF RFC or draft defining something pertaining to layer 2 to= pology
> > discovery using NETCONF?
> >
> > Thanks!
> >
> > Best regards,
> > Eric
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org=
> > https://www.ietf.org/mailman/= listinfo/netconf
>
>
> --
> Juergen Schoenwaelder           Jacobs Un= iversity Bremen gGmbH
> Phone: +49 421 200 3587         Campus Rin= g 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <<= /tt>http://www.jacobs-university.de/>

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C89848EAZFFEXMB04globa_-- From nobody Thu Sep 11 01:16:39 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBCB1A0698 for ; Thu, 11 Sep 2014 01:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.551 X-Spam-Level: X-Spam-Status: No, score=-8.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9AVuyMmk4IX for ; Thu, 11 Sep 2014 01:16:34 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4351A1A0673 for ; Thu, 11 Sep 2014 01:16:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQLAGBZEVTGmAcV/2dsb2JhbABdA4JHIyNTVwSxCAEFBpZ2GgEJhnlUAYEKFniEAwEBAQECAQEBAQ8bHCULBQkCAgEIDQMBAwEBAQEKHQcbDAsUCQgCBAEJBAUIGogYCAEMn0igHwEXBIV4hASEdiYgAQwEBgEJCIInUySBHQWPM4IWhm2MMoQ8iRGDYWyBB0GBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,504,1406606400"; d="scan'208,217"; a="81997792" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Sep 2014 04:16:32 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 11 Sep 2014 04:16:32 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 10:16:31 +0200 From: "Romascanu, Dan (Dan)" To: Jing Zhao , Juergen Schoenwaelder Thread-Topic: [Netconf] L2 topology discovery with NETCONF Thread-Index: AQHPzOnfByR6kYNj0Eq91P7g54I64Zv6f4gAgACJlICAAIzicA== Date: Thu, 11 Sep 2014 08:16:30 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8984B6@AZ-FFEXMB04.global.avaya.com> References: <20140910113416.GB99920@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C8984B6AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3kP4tB52xvfYMewLnmu9ccehED8 Cc: "netconf@ietf.org" Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:16:37 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8984B6AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Development of MIB modules for L2 bridging, including topology discovery wa= s transferred from the IETF to the IEEE 802.1 Working Group. By now they de= velop only SMIv2 MIB modules, including the one that supports IEEE 802.1AB,= which is an evolution of the IETF ptopo MIB supporting LLDP. The IEEE 802 = started a process of evolution towards YANG (they had a tutorial in July, s= tarted discussions about YANG support in new projects) but it's hard to est= imate when and how these discussions will end. However, I do not believe th= at the NETCONF WG (or other IETF WG) should re-enter the business of develo= ping data models for non-IETF technologies, so such questions may better be= directed to the IEEE 802.1 WG - they may actually help them understand the= need and accelerate their transition to NETCONF/YANG. Regards, Dan From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Jing Zhao Sent: Thursday, September 11, 2014 4:47 AM To: Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF Thanks guys. Yes, LLDP is an alternative in my research. Either way, I guess we need som= e way to fetch those distributed info from switches, in order to build the = topology. In the case of NETCONF, those switches must announce and support = an extra capability of a read-only YANG module translated from the accordin= g MIB. What I'm worried about is the lack of a standard-defined YANG module for th= is purpose. Different vendors may implement their own YANG modules if they = ever have one. It's thus hard to discover the network topology when there a= re switches from different vendors, or at least not scalable. To me, missing a standard module may limit the usage of NETCONF in this are= a. People will have to fall back and use SNMP to read MIB on different swit= ches. So I want to know if there is something defined in NETCONF standard pertain= ing to L2 topology discovery. If not, is there any plan for that? Best regards, Eric Juergen Schoenwaelder > wrote on 2014/09/10 19:34:16: > From: Juergen Schoenwaelder > > To: Jing Zhao >, > Cc: netconf@ietf.org > Date: 2014/09/10 19:34 > Subject: Re: [Netconf] L2 topology discovery with NETCONF > > Hi, > > you can turn a MIB module into a read-only YANG model following RFC > 6643. While L2 discovery via MIB modules may work in certain > situations, using something like LLDP and an interface to extract > information from stations speaking LLDP may be an alternative to > consider. > > /js > > On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote: > > Hi all, > > > > I'm working on a NETCONF research project hoping to find out a way to > > build layer 2 network topology. There are some open algorithms to build > > topology based on the information read from switch MIB. > > > > For example, each switch port has one entry in MIB dot1dStpPortTable wh= ich > > includes designated switch id, designated port, the root switch, etc. > > > > But I'm looking for a way to use NETCONF to read the MIB from switches. > > What I can expect is that switches implement some special YANG module > > which maps to this MIB and provides a new RPC function like, e.g., > > get-stp-table. > > > > I think this should be a normal use case for NETCONF. It's actually lis= ted > > as one issue here. > > > > But I cannot find anything related on the Web. The most I can get is > > ietf-routing.yang draft listing at www.netconfcentral.org. So is there = any > > IETF RFC or draft defining something pertaining to layer 2 topology > > discovery using NETCONF? > > > > Thanks! > > > > Best regards, > > Eric > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8984B6AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Development of MIB module= s for L2 bridging, including topology discovery was transferred from the IE= TF to the IEEE 802.1 Working Group. By now they develop only SMIv2 MIB modules, including the one that supports IEEE 802.1AB, whic= h is an evolution of the IETF ptopo MIB supporting LLDP. The IEEE 802 start= ed a process of evolution towards YANG (they had a tutorial in July, starte= d discussions about YANG support in new projects) but it’s hard to estimate when and how these discus= sions will end. However, I do not believe that the NETCONF WG (or other IET= F WG) should re-enter the business of developing data models for non-IETF t= echnologies, so such questions may better be directed to the IEEE 802.1 WG – they may actually help them under= stand the need and accelerate their transition to NETCONF/YANG.

 <= /p>

Regards,


Dan

 <= /p>

 <= /p>

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of Jing Zhao
Sent: Thursday, September 11, 2014 4:47 AM
To: Juergen Schoenwaelder
Cc: netconf@ietf.org
Subject: Re: [Netconf] L2 topology discovery with NETCONF=

 

Thanks guys.

Yes, LLDP is an alternative in my research. Either way, I guess = we need some way to fetch those distributed info from switches, in order to= build the topology. In the case of NETCONF, those switches must announce and support an extra capability of a read-only YANG module t= ranslated from the according MIB.

What I'm worried about is the lack of a standard-defined YANG mo= dule for this purpose. Different vendors may implement their own YANG modul= es if they ever have one. It's thus hard to discover the network topology when there are switches from different vendors, or at lea= st not scalable.

To me, missing a standard module may limit the usage of NETCONF = in this area. People will have to fall back and use SNMP to read MIB on dif= ferent switches.

So I want to know if there is something defined in NETCONF stand= ard pertaining to L2 topology discovery. If not, is there any plan for that= ?

Best regards,
Eric

Juergen Schoenwaelder <j.schoenwaelder@jacobs-universi= ty.de> wrote on 2014/09/10 19:34:16:

> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> To: Jing Zhao <jing.zhao@ni.com>,
> Cc: netconf@ietf.org
> Date: 2014/09/10 19:34
> Subject: Re: [Netconf] L2 topolog= y discovery with NETCONF
>
> Hi,
>
> you can turn a MIB module into a read-only YANG model following RF= C
> 6643. While L2 discovery via MIB modules may work in certain<= br> > situations, using something like LLDP and an interface to extract<= /tt>
> information from stations speaking LLDP may be an alternative to
> consider.
>
> /js
>
> On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote:
> > Hi all,
> >
> > I'm working on a NETCONF research project hoping to find out = a way to
> > build layer 2 network topology. There are some open algorithm= s to build
> > topology based on the information read from switch MIB.<= br> > >
> > For example, each switch port has one entry in MIB dot1dStpPo= rtTable which
> > includes designated switch id, designated port, the root swit= ch, etc.
> >
> > But I'm looking for a way to use NETCONF to read the MIB from= switches.
> > What I can expect is that switches implement some special YAN= G module
> > which maps to this MIB and provides a new RPC function like, = e.g.,
> > get-stp-table.
> >
> > I think this should be a normal use case for NETCONF. It's ac= tually listed
> > as one issue here.
> >
> > But I cannot find anything related on the Web. The most I can= get is
> > ietf-routing.yang draft listing at www.netconfcentra= l.org. So is there any
> > IETF RFC or draft defining something pertaining to layer 2 to= pology
> > discovery using NETCONF?
> >
> > Thanks!
> >
> > Best regards,
> > Eric
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org=
> > https://www.ietf.org/mailman/= listinfo/netconf
>
>
> --
> Juergen Schoenwaelder           Jacobs Un= iversity Bremen gGmbH
> Phone: +49 421 200 3587         Campus Rin= g 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <<= /tt>http://www.jacobs-university.de/>

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8984B6AZFFEXMB04globa_-- From nobody Thu Sep 11 02:14:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092BD1A0666 for ; Thu, 11 Sep 2014 02:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCn6bPf6UUMJ for ; Thu, 11 Sep 2014 02:14:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3431A0695 for ; Thu, 11 Sep 2014 02:13:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJH51681; Thu, 11 Sep 2014 09:13:43 +0000 (GMT) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Sep 2014 10:13:05 +0100 Received: from szxeml561-mbs.china.huawei.com ([169.254.6.80]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.03.0158.001; Thu, 11 Sep 2014 17:13:00 +0800 From: Rohit pobbathi To: vathsala narayanan , "netconf@ietf.org" Thread-Topic: [Netconf] NETCONF- read-write objects retrieval Thread-Index: AQHPzZNeFY+Byhtlo0uCIY8HpS1StJv7pdaA Date: Thu, 11 Sep 2014 09:13:00 +0000 Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB44B70D40@SZXEML561-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.151.62] Content-Type: multipart/alternative; boundary="_000_2730B0D5F3302249A30EBF0DAE96D4CB44B70D40SZXEML561MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/drfQ0t-VJgLpevYqGPxX7iIyCHY Subject: Re: [Netconf] NETCONF- read-write objects retrieval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 09:14:05 -0000 --_000_2730B0D5F3302249A30EBF0DAE96D4CB44B70D40SZXEML561MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNhbiB1c2UgZ2V0LWNvbmZpZyBvcGVyYXRpb24gb2YgTkVUQ09ORiB0byByZXRyaWV2ZSBj b25maWcgZGF0YS4NCg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIHZhdGhzYWxhIG5hcmF5YW5hbg0KU2VudDogMjAxNOW5tDnmnIgx MeaXpSAxOjQxDQpUbzogbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogW05ldGNvbmZdIE5FVENP TkYtIHJlYWQtd3JpdGUgb2JqZWN0cyByZXRyaWV2YWwNCg0KSGkgYWxsLA0KDQpJJ20gY3VycmVu dGx5IHdvcmtpbmcgb24gYSBORVRDT05GIHJlc2VhcmNoIHByb2plY3QuIFRvIHVuZGVyc3RhbmQg dGhlIHdvcmtpbmcgb2YgTkVUQ09ORiwgSSBoYXZlIHRha2VuIHRoZSBtaWIgb2JqZWN0cyAgKGZy b20gc3RkIElQIG1pYikgaXBGb3J3YXJkaW5nIGFuZCBpcERlZmF1bHRUVEwgYXMgZXhhbXBsZS4N Cg0KIEkgaGF2ZSB1c2VkIGEgdG9vbCB3aGljaCBnZW5lcmF0ZXMgYSB5YW5nIG1vZHVsZSB0aGF0 IG1hcHMgdG8gdGhpcyBNSUIgYW5kIHByb3ZpZGUgYSBuZXcgcnBjIGZ1bmN0aW9uIHRvIGNvbmZp Z3VyZSB2YWx1ZXMoc2F5IHNldC1pcG1pYikuIE15IGNvbmZpZ3VyYXRpb24gIGlzIGEgc3VjY2Vz cyBhcyBJIGNhbiBzZWUgYSBycGMtcmVwbHkgZnJvbSB0aGUgc2VydmVyLiBCdXQgSSdtIGxvb2tp bmcgZm9yIGEgd2F5IHRvIHJldHJpZXZlIHRoZSBjb25maWd1cmVkIHZhbHVlcy4gV2hlbiBJIGRv IGEgZ2V0L3hnZXQsIEkgYW0gYWJsZSB0byBzZWUgb25seSB0aGUgcmVhZC1vbmx5IG9iamVjdHMg Z2V0dGluZyBsaXN0ZWQuIElzIHRoZXJlICBhIHdheSB0byByZXRyaWV2ZSByZWFkLXdyaXRlIG9i amVjdHMgdGhyb3VnaCBuZXRjb25mPw0KDQpCZXN0IFJlZ2FyZHMsDQpWYXRoc2FsYQ0K --_000_2730B0D5F3302249A30EBF0DAE96D4CB44B70D40SZXEML561MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Z b3UgY2FuIHVzZSBnZXQtY29uZmlnIG9wZXJhdGlvbiBvZiBORVRDT05GIHRvIHJldHJpZXZlIGNv bmZpZyBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+dmF0aHNhbGEgbmFyYXlhbmFuPGJyPg0KPGI+ U2VudDo8L2I+IDIwMTQ8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij45PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTrlrovkvZMiPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+MTE8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kyI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4N CiAxOjQxPGJyPg0KPGI+VG86PC9iPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtOZXRjb25mXSBORVRDT05GLSByZWFkLXdyaXRlIG9iamVjdHMgcmV0cmlldmFsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gY3VycmVudGx5IHdvcmtp bmcgb24gYSBORVRDT05GIHJlc2VhcmNoIHByb2plY3QuIFRvIHVuZGVyc3RhbmQgdGhlIHdvcmtp bmcgb2YgTkVUQ09ORiwgSSBoYXZlIHRha2VuIHRoZSBtaWIgb2JqZWN0cyAmbmJzcDsoZnJvbSBz dGQgSVAgbWliKSBpcEZvcndhcmRpbmcgYW5kIGlwRGVmYXVsdFRUTCBhcyBleGFtcGxlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtJ IGhhdmUgdXNlZCBhIHRvb2wgd2hpY2ggZ2VuZXJhdGVzIGEgeWFuZyBtb2R1bGUgdGhhdCBtYXBz IHRvIHRoaXMgTUlCIGFuZCBwcm92aWRlIGEgbmV3IHJwYyBmdW5jdGlvbiB0byBjb25maWd1cmUg dmFsdWVzKHNheSBzZXQtaXBtaWIpLiBNeSBjb25maWd1cmF0aW9uICZuYnNwO2lzIGEgc3VjY2Vz cyBhcyBJIGNhbiBzZWUgYSBycGMtcmVwbHkgZnJvbSB0aGUgc2VydmVyLiBCdXQgSSdtIGxvb2tp bmcgZm9yIGEgd2F5DQogdG8gcmV0cmlldmUgdGhlIGNvbmZpZ3VyZWQgdmFsdWVzLiBXaGVuIEkg ZG8gYSBnZXQveGdldCwgSSBhbSBhYmxlIHRvIHNlZSBvbmx5IHRoZSByZWFkLW9ubHkgb2JqZWN0 cyBnZXR0aW5nIGxpc3RlZC4gSXMgdGhlcmUgJm5ic3A7YSB3YXkgdG8gcmV0cmlldmUgcmVhZC13 cml0ZSBvYmplY3RzIHRocm91Z2ggbmV0Y29uZj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VmF0aHNhbGE8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2730B0D5F3302249A30EBF0DAE96D4CB44B70D40SZXEML561MBSchi_-- From nobody Thu Sep 11 04:13:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447611A8939 for ; Thu, 11 Sep 2014 03:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDV9Rk9LFfIK for ; Thu, 11 Sep 2014 03:47:54 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4EAA1A06D3 for ; Thu, 11 Sep 2014 03:47:53 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id f10so2038209yha.34 for ; Thu, 11 Sep 2014 03:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OCvkXMac+ASLD1REyYzmD6p3tpBAEJq8dhEaXfUwsH4=; b=inbCplvvE50nKTk5MRX8drGgdoUdH+28Gi2/4nPvXnRIqno0EePvCmTXT8rJfkyTDe D7XWvHdYEA/oiXN5xvJ9wonK3/5GTqSCOpZYyFya8Smpdm5E/QMngd4i0uDhC14uf/Nz RM1uC5VBwuB+MDgcsATTv7RkCkxp81UJK/0AN30yHUT8XaDAMDE/lRF0laHksVIIGKUk 8KRlN/fEV67Pn7HF9MonkYdPFXw+h+eNyoUifWXBCC11f8ZUpskhPAIfNtdG+qwGV5vV JxDZUJa03cvAMTRNHWQemOKC3Bj5bpPbgPj7TaysB9Km3Q/k9lCn8lSnfKAhcbQu/dK8 V7dg== X-Received: by 10.236.35.103 with SMTP id t67mr68766yha.7.1410432473202; Thu, 11 Sep 2014 03:47:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.123.134 with HTTP; Thu, 11 Sep 2014 03:47:33 -0700 (PDT) In-Reply-To: <2730B0D5F3302249A30EBF0DAE96D4CB44B70D40@SZXEML561-MBS.china.huawei.com> References: <2730B0D5F3302249A30EBF0DAE96D4CB44B70D40@SZXEML561-MBS.china.huawei.com> From: vathsala narayanan Date: Thu, 11 Sep 2014 16:17:33 +0530 Message-ID: To: Rohit pobbathi Content-Type: multipart/alternative; boundary=20cf3011e2438b84640502c7e629 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zRImlLxyA_ThGC7Yr83Gjx_BShQ X-Mailman-Approved-At: Thu, 11 Sep 2014 04:13:31 -0700 Cc: "netconf@ietf.org" Subject: Re: [Netconf] NETCONF- read-write objects retrieval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 10:47:55 -0000 --20cf3011e2438b84640502c7e629 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, When I try to use get-config after configuring a mib object, I get only the container name listed in the output. I am not able to see the configured mib objects. Am I missing something ? Please find snippet of logs below: yangcli root@localhost> set-ip ipDefaultTTL=3D1 ipForwarding=3D2 RPC OK Reply 28 for session 1: yangcli root@localhost> get-config source=3Drunning RPC Data Reply 31 for session 1: rpc-reply { data { ip { >>>>>>>>object display missing here . } } } Regards, Vathsala On Thu, Sep 11, 2014 at 2:43 PM, Rohit pobbathi wrote: > You can use get-config operation of NETCONF to retrieve config data. > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *vathsala > narayanan > *Sent:* 2014=E5=B9=B49=E6=9C=8811=E6=97=A5 1:41 > *To:* netconf@ietf.org > *Subject:* [Netconf] NETCONF- read-write objects retrieval > > > > Hi all, > > > > I'm currently working on a NETCONF research project. To understand the > working of NETCONF, I have taken the mib objects (from std IP mib) > ipForwarding and ipDefaultTTL as example. > > > > I have used a tool which generates a yang module that maps to this MIB > and provide a new rpc function to configure values(say set-ipmib). My > configuration is a success as I can see a rpc-reply from the server. But > I'm looking for a way to retrieve the configured values. When I do a > get/xget, I am able to see only the read-only objects getting listed. Is > there a way to retrieve read-write objects through netconf? > > > > Best Regards, > > Vathsala > --20cf3011e2438b84640502c7e629 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

When I try to use=C2= =A0 get-config after configuring a mib object, I get only the container nam= e listed in the output. I am not able to see the configured mib objects.
Am I missing something ?


Please fi= nd snippet of logs below:

yangcli root@localhost> set-ip ipDefaul= tTTL=3D1 ipForwarding=3D2

RPC OK Reply 28 for session 1:

yang= cli root@localhost> get-config source=3Drunning

RPC Data Reply 31= for session 1:

rpc-reply {
=C2=A0 data {
=C2=A0=C2=A0=C2=A0 i= p {
>>>>>>>>object display missing he= re .
=C2=A0=C2=A0=C2=A0 }
}
}


Regards,=
Vathsala

On Thu, Sep 11, 2014 at 2:43 PM, Rohit pobbathi <rohit.= pobbathi@huawei.com> wrote:

You can use get-config op= eration of NETCONF to retrieve config data.

=C2=A0

From: Netconf = [mailto:netco= nf-bounces@ietf.org] On Behalf Of vathsala narayanan
Sent: 2014=E5=B9=B49=E6=9C= =8811=E6=97=A5 1:41
To: netconf@ie= tf.org
Subject: [Netconf] NETCONF- read-write objects retrieval

=C2=A0

Hi all,

=C2=A0

I'm currently working on a NETCONF research proj= ect. To understand the working of NETCONF, I have taken the mib objects =C2= =A0(from std IP mib) ipForwarding and ipDefaultTTL as example.

=C2=A0

=C2=A0I have used a tool which generates a yang modu= le that maps to this MIB and provide a new rpc function to configure values= (say set-ipmib). My configuration =C2=A0is a success as I can see a rpc-rep= ly from the server. But I'm looking for a way to retrieve the configured values. When I do a get/xget, I am able to see = only the read-only objects getting listed. Is there =C2=A0a way to retrieve= read-write objects through netconf?

=C2=A0

Best Regards,

Vathsala


--20cf3011e2438b84640502c7e629-- From nobody Thu Sep 11 04:18:01 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632801A06EB for ; Thu, 11 Sep 2014 04:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5uG-1lnnBZU for ; Thu, 11 Sep 2014 04:17:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BBF1A8916 for ; Thu, 11 Sep 2014 04:17:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 52C80134C; Thu, 11 Sep 2014 13:17:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mXx11P16Clfz; Thu, 11 Sep 2014 13:17:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Sep 2014 13:17:55 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86EFB20038; Thu, 11 Sep 2014 13:17:55 +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 wskGc4SSQ6KQ; Thu, 11 Sep 2014 13:17:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81ABC20037; Thu, 11 Sep 2014 13:17:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B97BF2E6260C; Thu, 11 Sep 2014 13:17:53 +0200 (CEST) Date: Thu, 11 Sep 2014 13:17:53 +0200 From: Juergen Schoenwaelder To: vathsala narayanan Message-ID: <20140911111753.GA3224@elstar.local> Mail-Followup-To: vathsala narayanan , Rohit pobbathi , "netconf@ietf.org" References: <2730B0D5F3302249A30EBF0DAE96D4CB44B70D40@SZXEML561-MBS.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7ZEXt_FsC2yrbmvxN00k0xI8HHs Cc: "netconf@ietf.org" Subject: Re: [Netconf] NETCONF- read-write objects retrieval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 11:18:00 -0000 Hi, I do not think we can solve implementation issue here. /js On Thu, Sep 11, 2014 at 04:17:33PM +0530, vathsala narayanan wrote: > Hi, > > When I try to use get-config after configuring a mib object, I get only > the container name listed in the output. I am not able to see the > configured mib objects. > Am I missing something ? > > > Please find snippet of logs below: > > yangcli root@localhost> set-ip ipDefaultTTL=1 ipForwarding=2 > > RPC OK Reply 28 for session 1: > > yangcli root@localhost> get-config source=running > > RPC Data Reply 31 for session 1: > > rpc-reply { > data { > ip { > >>>>>>>>object display missing here . > } > } > } > > > Regards, > Vathsala > > On Thu, Sep 11, 2014 at 2:43 PM, Rohit pobbathi > wrote: > > > You can use get-config operation of NETCONF to retrieve config data. > > > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *vathsala > > narayanan > > *Sent:* 2014年9月11日 1:41 > > *To:* netconf@ietf.org > > *Subject:* [Netconf] NETCONF- read-write objects retrieval > > > > > > > > Hi all, > > > > > > > > I'm currently working on a NETCONF research project. To understand the > > working of NETCONF, I have taken the mib objects (from std IP mib) > > ipForwarding and ipDefaultTTL as example. > > > > > > > > I have used a tool which generates a yang module that maps to this MIB > > and provide a new rpc function to configure values(say set-ipmib). My > > configuration is a success as I can see a rpc-reply from the server. But > > I'm looking for a way to retrieve the configured values. When I do a > > get/xget, I am able to see only the read-only objects getting listed. Is > > there a way to retrieve read-write objects through netconf? > > > > > > > > Best Regards, > > > > Vathsala > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 11 08:00:43 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1141A6FD7 for ; Thu, 11 Sep 2014 08:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maoqguZsp8u6 for ; Thu, 11 Sep 2014 08:00:34 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9941A00BB for ; Thu, 11 Sep 2014 08:00:34 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id ppnn1o0020bG4ec55r0Z5n; Thu, 11 Sep 2014 15:00:33 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta03.westchester.pa.mail.comcast.net with comcast id pr0Y1o0172yZEBF3Pr0ZAz; Thu, 11 Sep 2014 15:00:33 +0000 From: "ietfdbh" To: "'Romascanu, Dan \(Dan\)'" , "'Jing Zhao'" , "'Juergen Schoenwaelder'" References: <20140910113416.GB99920@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C8984B6@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8984B6@AZ-FFEXMB04.global.avaya.com> Date: Thu, 11 Sep 2014 11:00:30 -0400 Message-ID: <00ff01cfcdd1$219278e0$64b76aa0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0100_01CFCDAF.9A840D30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK/a12n9YicgiCdTEnAum+8yOUpwQI8VgkmAkijzeoB5JjJa5npftkg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410447633; bh=yycBkHON398IxFqMFEH+7YYMc4/OwbUEqBTyqsuEmXo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=P8L+UZF0smVuVlyfHaihFPT3HNkhyit3RHd0lLqEGetTqjRuIpWzDMDvbPNVtlSaT 6JXGi2yxLkCT9RFWGsKt33H5QwwilrC4vhxeqsN7IjykOCgoh+/BRPHdNfw9tueazG dwfXaQMM1MS3t6SGx2xOePSZiXbBZ3shPk8amZPpNdaL/ObS+9BOmLIhGtCt2v3wn8 DE4UBxhcKvLeRhXlZLWQG+BZRwvocAEYCOKkTA52yNUl6BdmBZztQRgA+ROU2JHsRG B3wk0DagC2sslmdFINhWPDGs1/Sxr4D23AJ2EVXtn99+XnHKipgXle44VWC3xjv4px eNA2tUCMpZMaw== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/g5HyHeR7IWJA3wWTq2BTrPa7QMg Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 15:00:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0100_01CFCDAF.9A840D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Thursday, September 11, 2014 4:17 AM To: Jing Zhao; Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF Hi, Development of MIB modules for L2 bridging, including topology discovery was transferred from the IETF to the IEEE 802.1 Working Group. By now they develop only SMIv2 MIB modules, including the one that supports IEEE 802.1AB, which is an evolution of the IETF ptopo MIB supporting LLDP. The IEEE 802 started a process of evolution towards YANG (they had a tutorial in July, started discussions about YANG support in new projects) but it's hard to estimate when and how these discussions will end. However, I do not believe that the NETCONF WG (or other IETF WG) should re-enter the business of developing data models for non-IETF technologies, so such questions may better be directed to the IEEE 802.1 WG - they may actually help them understand the need and accelerate their transition to NETCONF/YANG. Regards, Dan From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Jing Zhao Sent: Thursday, September 11, 2014 4:47 AM To: Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [Netconf] L2 topology discovery with NETCONF Thanks guys. Yes, LLDP is an alternative in my research. Either way, I guess we need some way to fetch those distributed info from switches, in order to build the topology. In the case of NETCONF, those switches must announce and support an extra capability of a read-only YANG module translated from the according MIB. What I'm worried about is the lack of a standard-defined YANG module for this purpose. Different vendors may implement their own YANG modules if they ever have one. It's thus hard to discover the network topology when there are switches from different vendors, or at least not scalable. To me, missing a standard module may limit the usage of NETCONF in this area. People will have to fall back and use SNMP to read MIB on different switches. So I want to know if there is something defined in NETCONF standard pertaining to L2 topology discovery. If not, is there any plan for that? Best regards, Eric Juergen Schoenwaelder wrote on 2014/09/10 19:34:16: > From: Juergen Schoenwaelder > To: Jing Zhao , > Cc: netconf@ietf.org > Date: 2014/09/10 19:34 > Subject: Re: [Netconf] L2 topology discovery with NETCONF > > Hi, > > you can turn a MIB module into a read-only YANG model following RFC > 6643. While L2 discovery via MIB modules may work in certain > situations, using something like LLDP and an interface to extract > information from stations speaking LLDP may be an alternative to > consider. > > /js > > On Wed, Sep 10, 2014 at 11:13:43AM +0800, Jing Zhao wrote: > > Hi all, > > > > I'm working on a NETCONF research project hoping to find out a way to > > build layer 2 network topology. There are some open algorithms to build > > topology based on the information read from switch MIB. > > > > For example, each switch port has one entry in MIB dot1dStpPortTable which > > includes designated switch id, designated port, the root switch, etc. > > > > But I'm looking for a way to use NETCONF to read the MIB from switches. > > What I can expect is that switches implement some special YANG module > > which maps to this MIB and provides a new RPC function like, e.g., > > get-stp-table. > > > > I think this should be a normal use case for NETCONF. It's actually listed > > as one issue here. > > > > But I cannot find anything related on the Web. The most I can get is > > ietf-routing.yang draft listing at www.netconfcentral.org. So is there any > > IETF RFC or draft defining something pertaining to layer 2 topology > > discovery using NETCONF? > > > > Thanks! > > > > Best regards, > > Eric > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < http://www.jacobs-university.de/> ------=_NextPart_000_0100_01CFCDAF.9A840D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu, = Dan (Dan)
Sent: Thursday, September 11, 2014 4:17 = AM
To: Jing Zhao; Juergen Schoenwaelder
Cc: = netconf@ietf.org
Subject: Re: [Netconf] L2 topology discovery = with NETCONF

 

Hi,

 

Development of MIB modules for L2 bridging, including topology = discovery was transferred from the IETF to the IEEE 802.1 Working Group. = By now they develop only SMIv2 MIB modules, including the one that = supports IEEE 802.1AB, which is an evolution of the IETF ptopo MIB = supporting LLDP. The IEEE 802 started a process of evolution towards = YANG (they had a tutorial in July, started discussions about YANG = support in new projects) but it’s hard to estimate when and how = these discussions will end. However, I do not believe that the NETCONF = WG (or other IETF WG) should re-enter the business of developing data = models for non-IETF technologies, so such questions may better be = directed to the IEEE 802.1 WG – they may actually help them = understand the need and accelerate their transition to NETCONF/YANG. =

 

Regards,


Dan

 

 

 

Thanks = guys.

Yes, LLDP is = an alternative in my research. Either way, I guess we need some way to = fetch those distributed info from switches, in order to build the = topology. In the case of NETCONF, those switches must announce and = support an extra capability of a read-only YANG module translated from = the according MIB.

What I'm = worried about is the lack of a standard-defined YANG module for this = purpose. Different vendors may implement their own YANG modules if they = ever have one. It's thus hard to discover the network topology when = there are switches from different vendors, or at least not = scalable.

To me, = missing a standard module may limit the usage of NETCONF in this area. = People will have to fall back and use SNMP to read MIB on different = switches.

So I want to = know if there is something defined in NETCONF standard pertaining to L2 = topology discovery. If not, is there any plan for that? =

Best = regards,
Eric =

Juergen Schoenwaelder = <j.schoenwaelder@jaco= bs-university.de> wrote on 2014/09/10 19:34:16:

> = From: Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de>
> To: Jing Zhao <jing.zhao@ni.com>, =
> Cc: netconf@ietf.org =
> Date: 2014/09/10 = 19:34
> Subject: = Re: [Netconf] L2 topology discovery with NETCONF =
>
> = Hi,
>
> you can turn a MIB module into a = read-only YANG model following RFC
> 6643. While L2 = discovery via MIB modules may work in certain
> = situations, using something like LLDP and an interface to = extract
> information from stations speaking LLDP may be = an alternative to
> consider.
> =
> /js
>
> On Wed, Sep 10, = 2014 at 11:13:43AM +0800, Jing Zhao wrote:
> > Hi = all,
> >
> > I'm working on a = NETCONF research project hoping to find out a way to
> = > build layer 2 network topology. There are some open algorithms to = build
> > topology based on the information read from = switch MIB.
> >
> > For example, = each switch port has one entry in MIB dot1dStpPortTable which =
> > includes designated switch id, designated port, = the root switch, etc.
> >
> > But = I'm looking for a way to use NETCONF to read the MIB from switches. =
> > What I can expect is that switches implement some = special YANG module
> > which maps to this MIB and = provides a new RPC function like, e.g.,
> > = get-stp-table.
> >
> > I think this = should be a normal use case for NETCONF. It's actually listed =
> > as one issue here.
> > =
> > But I cannot find anything related on the Web. = The most I can get is
> > ietf-routing.yang draft = listing at www.netconfcentral.org. So is there any
> > = IETF RFC or draft defining something pertaining to layer 2 topology =
> > discovery using NETCONF?
> > =
> > Thanks!
> >
> = > Best regards,
> > Eric
> > = _______________________________________________
> > = Netconf mailing list
> > Netconf@ietf.org
> = > https://www.ietf.org/mailman/listinfo/netconf<= /span>
>
>
> -- =
> Juergen Schoenwaelder         =   Jacobs University Bremen gGmbH
> Phone: +49 421 = 200 3587         Campus Ring 1, 28759 Bremen, = Germany
> Fax:   +49 421 200 3103     =     <http://www.jacobs-university.de/>

------=_NextPart_000_0100_01CFCDAF.9A840D30-- From nobody Thu Sep 11 10:17:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603F71A8951 for ; Thu, 11 Sep 2014 10:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5w8SacXT0_O for ; Thu, 11 Sep 2014 10:17:43 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD241A896B for ; Thu, 11 Sep 2014 10:17:24 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q107so10837866qgd.19 for ; Thu, 11 Sep 2014 10:17:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=msH/VWr/vzETjjmP9OYYQZ4fiu5BZtGnuT9lnCFRDNM=; b=mLBikND/KLXi7SDeR9a8tjQZWbrmSUr3MZwmt43g+lPUGJOz2w5J7wYTjtEnekT3s/ 9qqxte7uXlMgkdmFVcBSjlRtxVwchoXlRhytm54+/DfAVtL8pQdjfSs5ldu50vITJXcq wU1QgvfCgUhAwolSb/FciRDgZPk8ImQ6V6jZmsweC1NXjl+IKCEX7XDCAA2CYuaW4JdY kO/Cfzt8A/1gsUqjJ2sEF/jnJ/jjuGwAdseK5m/O4P6H5C8iN/Vs0YIP4hFWQ0ZZHBPk S8a2Y6aIKiP3yPF2Cmv6djDpVqEnAFK2X1OaIZkQ0/mD/ilf55tHmrmnVmf1B1TVCB3n KrOA== X-Gm-Message-State: ALoCoQln0ahMQyHKZza2H2unTNuQPbQXS6nc/M6ZRHvNHReCJ/GyElji6WcV6PXSlG9+smITkEVb MIME-Version: 1.0 X-Received: by 10.229.212.66 with SMTP id gr2mr3585299qcb.27.1410455839864; Thu, 11 Sep 2014 10:17:19 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 11 Sep 2014 10:17:19 -0700 (PDT) In-Reply-To: References: <2730B0D5F3302249A30EBF0DAE96D4CB44B70D40@SZXEML561-MBS.china.huawei.com> Date: Thu, 11 Sep 2014 10:17:19 -0700 Message-ID: From: Andy Bierman To: vathsala narayanan Content-Type: multipart/alternative; boundary=001a11339b584ebf1a0502cd57ad Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NitM-_AAQc1VZ8O2E27qXIpveQA Cc: "netconf@ietf.org" Subject: Re: [Netconf] NETCONF- read-write objects retrieval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 17:17:44 -0000 --001a11339b584ebf1a0502cd57ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 11, 2014 at 3:47 AM, vathsala narayanan < vathsala.narayanan@gmail.com> wrote: > Hi, > > When I try to use get-config after configuring a mib object, I get only > the container name listed in the output. I am not able to see the > configured mib objects. > Am I missing something ? > > Lots. #1 is that this question should go to the OpenYuma mailing list, not this one. > > Please find snippet of logs below: > > yangcli root@localhost> set-ip ipDefaultTTL=3D1 ipForwarding=3D2 > I assume the "set-ip" command is a custom RPC provided by the server? It is not a yangcli command. Or is it a yangcli alias? Normal NETCONF usage would be to define "ip" as data and use to edit it, instead of a custom RPC that does the same thing. Using a "set-ip" custom command is strongly discouraged. > RPC OK Reply 28 for session 1: > > yangcli root@localhost> get-config source=3Drunning > > RPC Data Reply 31 for session 1: > > rpc-reply { > data { > ip { > >>>>>>>>object display missing here . > } > Where is the "ip" config=3Dtrue data node defined? If there is none, then it cannot possibly be returned in a response. Are you sure you committed this data and it is not sitting in the candidate datastore? } > } > > > Regards, > Vathsala > Andy > > On Thu, Sep 11, 2014 at 2:43 PM, Rohit pobbathi > wrote: > >> You can use get-config operation of NETCONF to retrieve config data. >> >> >> >> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *vathsal= a >> narayanan >> *Sent:* 2014=E5=B9=B49=E6=9C=8811=E6=97=A5 1:41 >> *To:* netconf@ietf.org >> *Subject:* [Netconf] NETCONF- read-write objects retrieval >> >> >> >> Hi all, >> >> >> >> I'm currently working on a NETCONF research project. To understand the >> working of NETCONF, I have taken the mib objects (from std IP mib) >> ipForwarding and ipDefaultTTL as example. >> >> >> >> I have used a tool which generates a yang module that maps to this MIB >> and provide a new rpc function to configure values(say set-ipmib). My >> configuration is a success as I can see a rpc-reply from the server. Bu= t >> I'm looking for a way to retrieve the configured values. When I do a >> get/xget, I am able to see only the read-only objects getting listed. Is >> there a way to retrieve read-write objects through netconf? >> >> >> >> Best Regards, >> >> Vathsala >> > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11339b584ebf1a0502cd57ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 3:47 AM, vathsala narayanan &= lt;vathsa= la.narayanan@gmail.com> wrote:
Hi,

When I try to use= =C2=A0 get-config after configuring a mib object, I get only the container = name listed in the output. I am not able to see the configured mib objects.=
Am I missing something ?


Lots. #1 is that this question sho= uld go to the OpenYuma mailing list, not this one.
=C2=A0

Plea= se find snippet of logs below:

yangcli root@localhost> set-ip ipD= efaultTTL=3D1 ipForwarding=3D2

<= /div>
I assume the "set-ip" =C2=A0command is a custom RPC pro= vided by the server?
It is not a yangcli command. Or is it a yang= cli alias?

Normal NETCONF usage would be to define= "ip" as data and use <edit-config>
to edit it, i= nstead of a custom RPC that does the same thing. Using a "set-ip"= custom
command is strongly discouraged.



RP= C OK Reply 28 for session 1:

yangcli root@localhost> get-config s= ource=3Drunning

RPC Data Reply 31 for session 1:

rpc-reply {<= br>=C2=A0 data {
=C2=A0=C2=A0=C2=A0 ip {
>>>>&= gt;>>>object display missing here .
=C2=A0=C2=A0=C2= =A0 }

Where is the &q= uot;ip" config=3Dtrue data node defined?
If there is none, t= hen it cannot possibly be returned in a <get-config> response.
<= div>
Are you sure you committed this data and it is not sitti= ng in
the candidate datastore?


}
}

Regards,
Vathsala

Andy

=C2=A0
=

On Thu, Sep 11, 2014 at 2:43 PM, Rohit pobbathi <= ;rohit.pobba= thi@huawei.com> wrote:

You can use get-config op= eration of NETCONF to retrieve config data.

=C2=A0

From: Netconf = [mailto:netco= nf-bounces@ietf.org] On Behalf Of vathsala narayanan
Sent: 2014=E5=B9=B49=E6=9C= =8811=E6=97=A5 1:41
To: netconf@ie= tf.org
Subject: [Netconf] NETCONF- read-write objects retrieval

=C2=A0

Hi all,

=C2=A0

I'm currently working on a NETCONF research proj= ect. To understand the working of NETCONF, I have taken the mib objects =C2= =A0(from std IP mib) ipForwarding and ipDefaultTTL as example.

=C2=A0

=C2=A0I have used a tool which generates a yang modu= le that maps to this MIB and provide a new rpc function to configure values= (say set-ipmib). My configuration =C2=A0is a success as I can see a rpc-rep= ly from the server. But I'm looking for a way to retrieve the configured values. When I do a get/xget, I am able to see = only the read-only objects getting listed. Is there =C2=A0a way to retrieve= read-write objects through netconf?

=C2=A0

Best Regards,

Vathsala



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


--001a11339b584ebf1a0502cd57ad-- From nobody Thu Sep 11 16:41:09 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942681A0252 for ; Thu, 11 Sep 2014 16:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRThfziL_f9B for ; Thu, 11 Sep 2014 16:41:06 -0700 (PDT) Received: from ni.com (skprod2.natinst.com [130.164.80.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7F51A001E for ; Thu, 11 Sep 2014 16:41:06 -0700 (PDT) Received: from us-aus-mgwout1.amer.corp.natinst.com (nb-chan1-1338.natinst.com [130.164.19.134]) by us-aus-skprod2.natinst.com (8.14.5/8.14.5) with ESMTP id s8BNf3JI014637; Thu, 11 Sep 2014 18:41:03 -0500 Received: from cn-sha-domino1.apac.corp.natinst.com ([130.164.14.198]) by us-aus-mgwout1.amer.corp.natinst.com (Lotus Domino Release 8.5.3FP6) with ESMTP id 2014091118410317-1185202 ; Thu, 11 Sep 2014 18:41:03 -0500 In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8984B6@AZ-FFEXMB04.global.avaya.com> References: <20140910113416.GB99920@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA5C8984B6@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" MIME-Version: 1.0 X-KeepSent: 34E7BF84:FA47437C-48257D50:0082039A; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 16, 2012 From: Jing Zhao Message-ID: Date: Fri, 12 Sep 2014 07:41:05 +0800 X-MIMETrack: Serialize by Router on Nimbus/SHA/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/12/2014 07:41:03 AM, Serialize complete at 09/12/2014 07:41:03 AM, Itemize by SMTP Server on US-AUS-MGWOut1/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/11/2014 06:41:03 PM, Serialize by Router on US-AUS-MGWOut1/AUS/H/NIC(Release 8.5.3FP6|November 21, 2013) at 09/11/2014 06:41:03 PM, Serialize complete at 09/11/2014 06:41:03 PM Content-Type: multipart/alternative; boundary="=_alternative 008219F448257D50_=" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-09-11_07:2014-09-11,2014-09-11,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/f9Wk7R42exNJLaGKV0w9KVpDF88 Cc: "netconf@ietf.org" Subject: Re: [Netconf] L2 topology discovery with NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:41:08 -0000 This is a multipart message in MIME format. --=_alternative 008219F448257D50_= Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="GB2312" SSBnZXQgaXQsIGFuZCB0aGFua3MhDQoNCkJlc3QgcmVnYXJkcywNCkVyaWMNCg0KIlJvbWFzY2Fu dSwgRGFuIChEYW4pIiA8ZHJvbWFzY2FAYXZheWEuY29tPiB3cm90ZSBvbiAyMDE0LzA5LzExIDE2 OjE2OjMwOg0KDQo+IEZyb206ICJSb21hc2NhbnUsIERhbiAoRGFuKSIgPGRyb21hc2NhQGF2YXlh LmNvbT4NCj4gVG86IEppbmcgWmhhbyA8amluZy56aGFvQG5pLmNvbT4sIEp1ZXJnZW4gU2Nob2Vu d2FlbGRlciANCj4gPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4sIA0KPiBD YzogIm5ldGNvbmZAaWV0Zi5vcmciIDxuZXRjb25mQGlldGYub3JnPg0KPiBEYXRlOiAyMDE0LzA5 LzExIDE2OjE2DQo+IFN1YmplY3Q6IFJFOiBbTmV0Y29uZl0gTDIgdG9wb2xvZ3kgZGlzY292ZXJ5 IHdpdGggTkVUQ09ORg0KPiANCj4gSGksDQo+IA0KPiBEZXZlbG9wbWVudCBvZiBNSUIgbW9kdWxl cyBmb3IgTDIgYnJpZGdpbmcsIGluY2x1ZGluZyB0b3BvbG9neSANCj4gZGlzY292ZXJ5IHdhcyB0 cmFuc2ZlcnJlZCBmcm9tIHRoZSBJRVRGIHRvIHRoZSBJRUVFIDgwMi4xIFdvcmtpbmcgDQo+IEdy b3VwLiBCeSBub3cgdGhleSBkZXZlbG9wIG9ubHkgU01JdjIgTUlCIG1vZHVsZXMsIGluY2x1ZGlu ZyB0aGUgb25lDQo+IHRoYXQgc3VwcG9ydHMgSUVFRSA4MDIuMUFCLCB3aGljaCBpcyBhbiBldm9s dXRpb24gb2YgdGhlIElFVEYgcHRvcG8gDQo+IE1JQiBzdXBwb3J0aW5nIExMRFAuIFRoZSBJRUVF IDgwMiBzdGFydGVkIGEgcHJvY2VzcyBvZiBldm9sdXRpb24gDQo+IHRvd2FyZHMgWUFORyAodGhl eSBoYWQgYSB0dXRvcmlhbCBpbiBKdWx5LCBzdGFydGVkIGRpc2N1c3Npb25zIGFib3V0DQo+IFlB Tkcgc3VwcG9ydCBpbiBuZXcgcHJvamVjdHMpIGJ1dCBpdKGvcyBoYXJkIHRvIGVzdGltYXRlIHdo ZW4gYW5kIGhvdw0KPiB0aGVzZSBkaXNjdXNzaW9ucyB3aWxsIGVuZC4gSG93ZXZlciwgSSBkbyBu b3QgYmVsaWV2ZSB0aGF0IHRoZSANCj4gTkVUQ09ORiBXRyAob3Igb3RoZXIgSUVURiBXRykgc2hv dWxkIHJlLWVudGVyIHRoZSBidXNpbmVzcyBvZiANCj4gZGV2ZWxvcGluZyBkYXRhIG1vZGVscyBm b3Igbm9uLUlFVEYgdGVjaG5vbG9naWVzLCBzbyBzdWNoIHF1ZXN0aW9ucyANCj4gbWF5IGJldHRl ciBiZSBkaXJlY3RlZCB0byB0aGUgSUVFRSA4MDIuMSBXRyCoQyB0aGV5IG1heSBhY3R1YWxseSBo ZWxwDQo+IHRoZW0gdW5kZXJzdGFuZCB0aGUgbmVlZCBhbmQgYWNjZWxlcmF0ZSB0aGVpciB0cmFu c2l0aW9uIHRvIA0KTkVUQ09ORi9ZQU5HLiANCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBEYW4NCj4g DQo+IA0KPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSmluZyBaaGFvDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTEsIDIw MTQgNDo0NyBBTQ0KPiBUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+IENjOiBuZXRjb25mQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gTDIgdG9wb2xvZ3kgZGlzY292ZXJ5IHdp dGggTkVUQ09ORg0KPiANCj4gVGhhbmtzIGd1eXMuIA0KPiANCj4gWWVzLCBMTERQIGlzIGFuIGFs dGVybmF0aXZlIGluIG15IHJlc2VhcmNoLiBFaXRoZXIgd2F5LCBJIGd1ZXNzIHdlIA0KPiBuZWVk IHNvbWUgd2F5IHRvIGZldGNoIHRob3NlIGRpc3RyaWJ1dGVkIGluZm8gZnJvbSBzd2l0Y2hlcywg aW4gDQo+IG9yZGVyIHRvIGJ1aWxkIHRoZSB0b3BvbG9neS4gSW4gdGhlIGNhc2Ugb2YgTkVUQ09O RiwgdGhvc2Ugc3dpdGNoZXMgDQo+IG11c3QgYW5ub3VuY2UgYW5kIHN1cHBvcnQgYW4gZXh0cmEg Y2FwYWJpbGl0eSBvZiBhIHJlYWQtb25seSBZQU5HIA0KPiBtb2R1bGUgdHJhbnNsYXRlZCBmcm9t IHRoZSBhY2NvcmRpbmcgTUlCLiANCj4gDQo+IFdoYXQgSSdtIHdvcnJpZWQgYWJvdXQgaXMgdGhl IGxhY2sgb2YgYSBzdGFuZGFyZC1kZWZpbmVkIFlBTkcgbW9kdWxlDQo+IGZvciB0aGlzIHB1cnBv c2UuIERpZmZlcmVudCB2ZW5kb3JzIG1heSBpbXBsZW1lbnQgdGhlaXIgb3duIFlBTkcgDQo+IG1v ZHVsZXMgaWYgdGhleSBldmVyIGhhdmUgb25lLiBJdCdzIHRodXMgaGFyZCB0byBkaXNjb3ZlciB0 aGUgDQo+IG5ldHdvcmsgdG9wb2xvZ3kgd2hlbiB0aGVyZSBhcmUgc3dpdGNoZXMgZnJvbSBkaWZm ZXJlbnQgdmVuZG9ycywgb3IgDQo+IGF0IGxlYXN0IG5vdCBzY2FsYWJsZS4gDQo+IA0KPiBUbyBt ZSwgbWlzc2luZyBhIHN0YW5kYXJkIG1vZHVsZSBtYXkgbGltaXQgdGhlIHVzYWdlIG9mIE5FVENP TkYgaW4gDQo+IHRoaXMgYXJlYS4gUGVvcGxlIHdpbGwgaGF2ZSB0byBmYWxsIGJhY2sgYW5kIHVz ZSBTTk1QIHRvIHJlYWQgTUlCIG9uDQo+IGRpZmZlcmVudCBzd2l0Y2hlcy4gDQo+IA0KPiBTbyBJ IHdhbnQgdG8ga25vdyBpZiB0aGVyZSBpcyBzb21ldGhpbmcgZGVmaW5lZCBpbiBORVRDT05GIHN0 YW5kYXJkIA0KPiBwZXJ0YWluaW5nIHRvIEwyIHRvcG9sb2d5IGRpc2NvdmVyeS4gSWYgbm90LCBp cyB0aGVyZSBhbnkgcGxhbiBmb3IgdGhhdD8gDQoNCj4gDQo+IEJlc3QgcmVnYXJkcywgDQo+IEVy aWMgDQo+IA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt dW5pdmVyc2l0eS5kZT4gd3JvdGUgDQo+IG9uIDIwMTQvMDkvMTAgMTk6MzQ6MTY6DQo+IA0KPiA+ IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPiANCj4gPiBUbzogSmluZyBaaGFvIDxqaW5nLnpoYW9AbmkuY29tPiwgDQo+ID4g Q2M6IG5ldGNvbmZAaWV0Zi5vcmcgDQo+ID4gRGF0ZTogMjAxNC8wOS8xMCAxOTozNCANCj4gPiBT dWJqZWN0OiBSZTogW05ldGNvbmZdIEwyIHRvcG9sb2d5IGRpc2NvdmVyeSB3aXRoIE5FVENPTkYg DQo+ID4gDQo+ID4gSGksDQo+ID4gDQo+ID4geW91IGNhbiB0dXJuIGEgTUlCIG1vZHVsZSBpbnRv IGEgcmVhZC1vbmx5IFlBTkcgbW9kZWwgZm9sbG93aW5nIFJGQw0KPiA+IDY2NDMuIFdoaWxlIEwy IGRpc2NvdmVyeSB2aWEgTUlCIG1vZHVsZXMgbWF5IHdvcmsgaW4gY2VydGFpbg0KPiA+IHNpdHVh dGlvbnMsIHVzaW5nIHNvbWV0aGluZyBsaWtlIExMRFAgYW5kIGFuIGludGVyZmFjZSB0byBleHRy YWN0DQo+ID4gaW5mb3JtYXRpb24gZnJvbSBzdGF0aW9ucyBzcGVha2luZyBMTERQIG1heSBiZSBh biBhbHRlcm5hdGl2ZSB0bw0KPiA+IGNvbnNpZGVyLg0KPiA+IA0KPiA+IC9qcw0KPiA+IA0KPiA+ IE9uIFdlZCwgU2VwIDEwLCAyMDE0IGF0IDExOjEzOjQzQU0gKzA4MDAsIEppbmcgWmhhbyB3cm90 ZToNCj4gPiA+IEhpIGFsbCwNCj4gPiA+IA0KPiA+ID4gSSdtIHdvcmtpbmcgb24gYSBORVRDT05G IHJlc2VhcmNoIHByb2plY3QgaG9waW5nIHRvIGZpbmQgb3V0IGEgd2F5IA0KdG8gDQo+ID4gPiBi dWlsZCBsYXllciAyIG5ldHdvcmsgdG9wb2xvZ3kuIFRoZXJlIGFyZSBzb21lIG9wZW4gYWxnb3Jp dGhtcyB0byANCmJ1aWxkIA0KPiA+ID4gdG9wb2xvZ3kgYmFzZWQgb24gdGhlIGluZm9ybWF0aW9u IHJlYWQgZnJvbSBzd2l0Y2ggTUlCLg0KPiA+ID4gDQo+ID4gPiBGb3IgZXhhbXBsZSwgZWFjaCBz d2l0Y2ggcG9ydCBoYXMgb25lIGVudHJ5IGluIE1JQiANCj4gZG90MWRTdHBQb3J0VGFibGUgd2hp Y2ggDQo+ID4gPiBpbmNsdWRlcyBkZXNpZ25hdGVkIHN3aXRjaCBpZCwgZGVzaWduYXRlZCBwb3J0 LCB0aGUgcm9vdCBzd2l0Y2gsIA0KZXRjLg0KPiA+ID4gDQo+ID4gPiBCdXQgSSdtIGxvb2tpbmcg Zm9yIGEgd2F5IHRvIHVzZSBORVRDT05GIHRvIHJlYWQgdGhlIE1JQiBmcm9tIA0Kc3dpdGNoZXMu IA0KPiA+ID4gV2hhdCBJIGNhbiBleHBlY3QgaXMgdGhhdCBzd2l0Y2hlcyBpbXBsZW1lbnQgc29t ZSBzcGVjaWFsIFlBTkcgDQptb2R1bGUgDQo+ID4gPiB3aGljaCBtYXBzIHRvIHRoaXMgTUlCIGFu ZCBwcm92aWRlcyBhIG5ldyBSUEMgZnVuY3Rpb24gbGlrZSwgZS5nLiwgDQo+ID4gPiBnZXQtc3Rw LXRhYmxlLg0KPiA+ID4gDQo+ID4gPiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGEgbm9ybWFsIHVz ZSBjYXNlIGZvciBORVRDT05GLiBJdCdzIA0KPiBhY3R1YWxseSBsaXN0ZWQgDQo+ID4gPiBhcyBv bmUgaXNzdWUgaGVyZS4NCj4gPiA+IA0KPiA+ID4gQnV0IEkgY2Fubm90IGZpbmQgYW55dGhpbmcg cmVsYXRlZCBvbiB0aGUgV2ViLiBUaGUgbW9zdCBJIGNhbiBnZXQgaXMgDQoNCj4gPiA+IGlldGYt cm91dGluZy55YW5nIGRyYWZ0IGxpc3RpbmcgYXQgd3d3Lm5ldGNvbmZjZW50cmFsLm9yZy4gU28g DQppc3RoZXJlIGFueSANCj4gPiA+IElFVEYgUkZDIG9yIGRyYWZ0IGRlZmluaW5nIHNvbWV0aGlu ZyBwZXJ0YWluaW5nIHRvIGxheWVyIDIgdG9wb2xvZ3kgDQo+ID4gPiBkaXNjb3ZlcnkgdXNpbmcg TkVUQ09ORj8NCj4gPiA+IA0KPiA+ID4gVGhhbmtzIQ0KPiA+ID4gDQo+ID4gPiBCZXN0IHJlZ2Fy ZHMsDQo+ID4gPiBFcmljDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+IE5ldGNvbmZA aWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZg0KPiA+IA0KPiA+IA0KPiA+IC0tIA0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAg ICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhvbmU6ICs0OSA0MjEg MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCj4g PiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2 ZXJzaXR5LmRlLz4NCg== --=_alternative 008219F448257D50_= Content-Transfer-Encoding: base64 Content-Type: text/html; charset="GB2312" PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgZ2V0IGl0LCBhbmQgdGhhbmtzITwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRz LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RXJpYzwvZm9udD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O1JvbWFzY2FudSwgRGFuIChEYW4pJnF1 b3Q7ICZsdDtkcm9tYXNjYUBhdmF5YS5jb20mZ3Q7DQp3cm90ZSBvbiAyMDE0LzA5LzExIDE2OjE2 OjMwOjxicj4NCjxicj4NCiZndDsgRnJvbTogJnF1b3Q7Um9tYXNjYW51LCBEYW4gKERhbikmcXVv dDsgJmx0O2Ryb21hc2NhQGF2YXlhLmNvbSZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgVG86IEppbmcgWmhhbyAmbHQ7amluZy56aGFvQG5pLmNvbSZndDssIEp1ZXJn ZW4NClNjaG9lbndhZWxkZXIgPGJyPg0KJmd0OyAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlJmd0OywgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IENjOiAmcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0 OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBEYXRlOiAyMDE0LzA5LzEx IDE2OjE2PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFN1YmplY3Q6IFJF OiBbTmV0Y29uZl0gTDIgdG9wb2xvZ3kgZGlzY292ZXJ5DQp3aXRoIE5FVENPTkY8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBIaSw8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IERldmVsb3BtZW50IG9mIE1JQiBtb2R1bGVzIGZvciBMMiBicmlkZ2lu ZywgaW5jbHVkaW5nDQp0b3BvbG9neSA8YnI+DQomZ3Q7IGRpc2NvdmVyeSB3YXMgdHJhbnNmZXJy ZWQgZnJvbSB0aGUgSUVURiB0byB0aGUgSUVFRSA4MDIuMSBXb3JraW5nDQo8YnI+DQomZ3Q7IEdy b3VwLiBCeSBub3cgdGhleSBkZXZlbG9wIG9ubHkgU01JdjIgTUlCIG1vZHVsZXMsIGluY2x1ZGlu ZyB0aGUgb25lPGJyPg0KJmd0OyB0aGF0IHN1cHBvcnRzIElFRUUgODAyLjFBQiwgd2hpY2ggaXMg YW4gZXZvbHV0aW9uIG9mIHRoZSBJRVRGIHB0b3BvDQo8YnI+DQomZ3Q7IE1JQiBzdXBwb3J0aW5n IExMRFAuIFRoZSBJRUVFIDgwMiBzdGFydGVkIGEgcHJvY2VzcyBvZiBldm9sdXRpb24gPGJyPg0K Jmd0OyB0b3dhcmRzIFlBTkcgKHRoZXkgaGFkIGEgdHV0b3JpYWwgaW4gSnVseSwgc3RhcnRlZCBk aXNjdXNzaW9ucyBhYm91dDxicj4NCiZndDsgWUFORyBzdXBwb3J0IGluIG5ldyBwcm9qZWN0cykg YnV0IGl0oa9zIGhhcmQgdG8gZXN0aW1hdGUgd2hlbiBhbmQNCmhvdzxicj4NCiZndDsgdGhlc2Ug ZGlzY3Vzc2lvbnMgd2lsbCBlbmQuIEhvd2V2ZXIsIEkgZG8gbm90IGJlbGlldmUgdGhhdCB0aGUg PGJyPg0KJmd0OyBORVRDT05GIFdHIChvciBvdGhlciBJRVRGIFdHKSBzaG91bGQgcmUtZW50ZXIg dGhlIGJ1c2luZXNzIG9mIDxicj4NCiZndDsgZGV2ZWxvcGluZyBkYXRhIG1vZGVscyBmb3Igbm9u LUlFVEYgdGVjaG5vbG9naWVzLCBzbyBzdWNoIHF1ZXN0aW9ucw0KPGJyPg0KJmd0OyBtYXkgYmV0 dGVyIGJlIGRpcmVjdGVkIHRvIHRoZSBJRUVFIDgwMi4xIFdHIKhDIHRoZXkgbWF5IGFjdHVhbGx5 IGhlbHA8YnI+DQomZ3Q7IHRoZW0gdW5kZXJzdGFuZCB0aGUgbmVlZCBhbmQgYWNjZWxlcmF0ZSB0 aGVpciB0cmFuc2l0aW9uIHRvIE5FVENPTkYvWUFORy4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgUmVnYXJkcyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyBEYW48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBOZXRjb25mIFs8L2ZvbnQ+PC90dD48 YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj48dHQ+PGZvbnQgc2l6ZT0y Pm1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250 IHNpemU9Mj5dDQpPbiBCZWhhbGYgT2YgSmluZyBaaGFvPGJyPg0KJmd0OyBTZW50OiBUaHVyc2Rh eSwgU2VwdGVtYmVyIDExLCAyMDE0IDQ6NDcgQU08YnI+DQomZ3Q7IFRvOiBKdWVyZ2VuIFNjaG9l bndhZWxkZXI8YnI+DQomZ3Q7IENjOiBuZXRjb25mQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0 OiBSZTogW05ldGNvbmZdIEwyIHRvcG9sb2d5IGRpc2NvdmVyeSB3aXRoIE5FVENPTkY8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoYW5rcyBndXlzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg WWVzLCBMTERQIGlzIGFuIGFsdGVybmF0aXZlIGluIG15IHJlc2VhcmNoLiBFaXRoZXIgd2F5LCBJ IGd1ZXNzIHdlDQo8YnI+DQomZ3Q7IG5lZWQgc29tZSB3YXkgdG8gZmV0Y2ggdGhvc2UgZGlzdHJp YnV0ZWQgaW5mbyBmcm9tIHN3aXRjaGVzLCBpbiA8YnI+DQomZ3Q7IG9yZGVyIHRvIGJ1aWxkIHRo ZSB0b3BvbG9neS4gSW4gdGhlIGNhc2Ugb2YgTkVUQ09ORiwgdGhvc2Ugc3dpdGNoZXMNCjxicj4N CiZndDsgbXVzdCBhbm5vdW5jZSBhbmQgc3VwcG9ydCBhbiBleHRyYSBjYXBhYmlsaXR5IG9mIGEg cmVhZC1vbmx5IFlBTkcNCjxicj4NCiZndDsgbW9kdWxlIHRyYW5zbGF0ZWQgZnJvbSB0aGUgYWNj b3JkaW5nIE1JQi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdoYXQgSSdtIHdvcnJpZWQgYWJvdXQg aXMgdGhlIGxhY2sgb2YgYSBzdGFuZGFyZC1kZWZpbmVkIFlBTkcgbW9kdWxlPGJyPg0KJmd0OyBm b3IgdGhpcyBwdXJwb3NlLiBEaWZmZXJlbnQgdmVuZG9ycyBtYXkgaW1wbGVtZW50IHRoZWlyIG93 biBZQU5HIDxicj4NCiZndDsgbW9kdWxlcyBpZiB0aGV5IGV2ZXIgaGF2ZSBvbmUuIEl0J3MgdGh1 cyBoYXJkIHRvIGRpc2NvdmVyIHRoZSA8YnI+DQomZ3Q7IG5ldHdvcmsgdG9wb2xvZ3kgd2hlbiB0 aGVyZSBhcmUgc3dpdGNoZXMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycywgb3INCjxicj4NCiZndDsg YXQgbGVhc3Qgbm90IHNjYWxhYmxlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVG8gbWUsIG1pc3Np bmcgYSBzdGFuZGFyZCBtb2R1bGUgbWF5IGxpbWl0IHRoZSB1c2FnZSBvZiBORVRDT05GIGluDQo8 YnI+DQomZ3Q7IHRoaXMgYXJlYS4gUGVvcGxlIHdpbGwgaGF2ZSB0byBmYWxsIGJhY2sgYW5kIHVz ZSBTTk1QIHRvIHJlYWQgTUlCDQpvbjxicj4NCiZndDsgZGlmZmVyZW50IHN3aXRjaGVzLiA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgU28gSSB3YW50IHRvIGtub3cgaWYgdGhlcmUgaXMgc29tZXRoaW5n IGRlZmluZWQgaW4gTkVUQ09ORiBzdGFuZGFyZA0KPGJyPg0KJmd0OyBwZXJ0YWluaW5nIHRvIEwy IHRvcG9sb2d5IGRpc2NvdmVyeS4gSWYgbm90LCBpcyB0aGVyZSBhbnkgcGxhbiBmb3INCnRoYXQ/ IDxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMsIDxicj4NCiZndDsgRXJpYyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7DQp3cm90ZSA8YnI+DQomZ3Q7IG9uIDIwMTQvMDkv MTAgMTk6MzQ6MTY6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgRnJvbTogSnVlcmdlbiBTY2hv ZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7DQo8 YnI+DQomZ3Q7ICZndDsgVG86IEppbmcgWmhhbyAmbHQ7amluZy56aGFvQG5pLmNvbSZndDssIDxi cj4NCiZndDsgJmd0OyBDYzogbmV0Y29uZkBpZXRmLm9yZyA8YnI+DQomZ3Q7ICZndDsgRGF0ZTog MjAxNC8wOS8xMCAxOTozNCA8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtOZXRjb25mXSBM MiB0b3BvbG9neSBkaXNjb3Zlcnkgd2l0aCBORVRDT05GIDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgSGksPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyB5b3UgY2FuIHR1cm4g YSBNSUIgbW9kdWxlIGludG8gYSByZWFkLW9ubHkgWUFORyBtb2RlbCBmb2xsb3dpbmcNClJGQzxi cj4NCiZndDsgJmd0OyA2NjQzLiBXaGlsZSBMMiBkaXNjb3ZlcnkgdmlhIE1JQiBtb2R1bGVzIG1h eSB3b3JrIGluIGNlcnRhaW48YnI+DQomZ3Q7ICZndDsgc2l0dWF0aW9ucywgdXNpbmcgc29tZXRo aW5nIGxpa2UgTExEUCBhbmQgYW4gaW50ZXJmYWNlIHRvIGV4dHJhY3Q8YnI+DQomZ3Q7ICZndDsg aW5mb3JtYXRpb24gZnJvbSBzdGF0aW9ucyBzcGVha2luZyBMTERQIG1heSBiZSBhbiBhbHRlcm5h dGl2ZQ0KdG88YnI+DQomZ3Q7ICZndDsgY29uc2lkZXIuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAvanM8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIFdlZCwgU2VwIDEw LCAyMDE0IGF0IDExOjEzOjQzQU0gKzA4MDAsIEppbmcgWmhhbyB3cm90ZTo8YnI+DQomZ3Q7ICZn dDsgJmd0OyBIaSBhbGwsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg SSdtIHdvcmtpbmcgb24gYSBORVRDT05GIHJlc2VhcmNoIHByb2plY3QgaG9waW5nIHRvIGZpbmQN Cm91dCBhIHdheSB0byA8YnI+DQomZ3Q7ICZndDsgJmd0OyBidWlsZCBsYXllciAyIG5ldHdvcmsg dG9wb2xvZ3kuIFRoZXJlIGFyZSBzb21lIG9wZW4gYWxnb3JpdGhtcw0KdG8gYnVpbGQgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgdG9wb2xvZ3kgYmFzZWQgb24gdGhlIGluZm9ybWF0aW9uIHJlYWQgZnJv bSBzd2l0Y2ggTUlCLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEZv ciBleGFtcGxlLCBlYWNoIHN3aXRjaCBwb3J0IGhhcyBvbmUgZW50cnkgaW4gTUlCIDxicj4NCiZn dDsgZG90MWRTdHBQb3J0VGFibGUgd2hpY2ggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW5jbHVkZXMg ZGVzaWduYXRlZCBzd2l0Y2ggaWQsIGRlc2lnbmF0ZWQgcG9ydCwgdGhlIHJvb3QNCnN3aXRjaCwg ZXRjLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEJ1dCBJJ20gbG9v a2luZyBmb3IgYSB3YXkgdG8gdXNlIE5FVENPTkYgdG8gcmVhZCB0aGUgTUlCDQpmcm9tIHN3aXRj aGVzLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBXaGF0IEkgY2FuIGV4cGVjdCBpcyB0aGF0IHN3aXRj aGVzIGltcGxlbWVudCBzb21lIHNwZWNpYWwNCllBTkcgbW9kdWxlIDxicj4NCiZndDsgJmd0OyAm Z3Q7IHdoaWNoIG1hcHMgdG8gdGhpcyBNSUIgYW5kIHByb3ZpZGVzIGEgbmV3IFJQQyBmdW5jdGlv biBsaWtlLA0KZS5nLiwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZ2V0LXN0cC10YWJsZS48YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHRoaW5rIHRoaXMgc2hvdWxkIGJl IGEgbm9ybWFsIHVzZSBjYXNlIGZvciBORVRDT05GLiBJdCdzDQo8YnI+DQomZ3Q7IGFjdHVhbGx5 IGxpc3RlZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyBhcyBvbmUgaXNzdWUgaGVyZS48YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBCdXQgSSBjYW5ub3QgZmluZCBhbnl0aGlu ZyByZWxhdGVkIG9uIHRoZSBXZWIuIFRoZSBtb3N0DQpJIGNhbiBnZXQgaXMgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgaWV0Zi1yb3V0aW5nLnlhbmcgZHJhZnQgbGlzdGluZyBhdCA8L2ZvbnQ+PC90dD48 YSBocmVmPXd3dy5uZXRjb25mY2VudHJhbC5vcmc+PHR0Pjxmb250IHNpemU9Mj53d3cubmV0Y29u ZmNlbnRyYWwub3JnPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Lg0KU28gaXN0aGVy ZSBhbnkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSUVURiBSRkMgb3IgZHJhZnQgZGVmaW5pbmcgc29t ZXRoaW5nIHBlcnRhaW5pbmcgdG8gbGF5ZXINCjIgdG9wb2xvZ3kgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgZGlzY292ZXJ5IHVzaW5nIE5FVENPTkY/PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgVGhhbmtzITxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBFcmljPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7ICZndDsgJmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7 IE5ldGNvbmZAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVm PWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZj48dHQ+PGZvbnQg c2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvZm9u dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IC0tIDxicj4NCiZndDsgJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKYWNvYnMNClVuaXZlcnNpdHkg QnJlbWVuIGdHbWJIPGJyPg0KJmd0OyAmZ3Q7IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDYW1wdXMgUmluZw0KMSwgMjg3NTkgQnJlbWVuLCBHZXJt YW55PGJyPg0KJmd0OyAmZ3Q7IEZheDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8vd3d3Lmph Y29icy11bml2ZXJzaXR5LmRlLyI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LmphY29icy11 bml2ZXJzaXR5LmRlLzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDs8L2ZvbnQ+ PC90dD4NCg== --=_alternative 008219F448257D50_=-- From nobody Fri Sep 12 00:40:49 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207DF1A048E; Fri, 12 Sep 2014 00:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0dheEfYUenE; Fri, 12 Sep 2014 00:40:17 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820201A0664; Fri, 12 Sep 2014 00:40:17 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XSLSn-0006RK-Ng; Fri, 12 Sep 2014 09:40:15 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest108.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XSLSn-00058s-K2; Fri, 12 Sep 2014 09:40:13 +0200 Message-ID: <5412A35D.1080703@bwijnen.net> Date: Fri, 12 Sep 2014 09:40:13 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: proceedings@ietf.org References: <540EE975.3040705@bwijnen.net> In-Reply-To: <540EE975.3040705@bwijnen.net> X-Forwarded-Message-Id: <540EE975.3040705@bwijnen.net> Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd41a09219c019f1304707c5b93c10667f4 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/F06N_U5AN4SWT4cnEkfphcWpyaE Cc: netconf Subject: [Netconf] minutes/notes/virtual-bluesheet of our NETCONF Virtual Interim Meeting on 8 Sept 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 07:40:37 -0000 Here are the proceeding materials for our NETCONF virtual meeting (webex) on 8 Sept 2014 Meeting start: 8 Sept 2014, 17:11 UTC Meeting end: 8 Sept 2014, 19:05 UTC Chair: Bert Wijnen Attendees: Juergen Schoenwaelder Ladislav Lhotka Martin Bjorklund Kent Watsen Andy Bierman Michael Scharf Mahesh Jethanandani Alberto Gonzalez Prieto Benoit CLaise (AD) Regrets: Mehmet Ersue (co-chair, vacation) > Dear WG participants, we had our first virtual interim meeting yesterday. > here are the draft minutes (thanks to Kent for taking notes, amended/merged > with my own notes): > > The meetings run from 8 Sept - 3 Nov 2014. Biweekly on Mondays from 7pm-9pm > CET (Berlin, Amsterdam, Paris). That is 17:00-19:00 UTC. They are webex based > meetings. We have decided last night to record the meetings. But the WG chair(s) > will ensure at the start of every meeting that everyone is aware and that > nobody objects. The recording of yesterdays meeting is here: > > Streaming recording link: > https://ietf.webex.com/ietf/ldr.php?RCID=2fd2a151d4ef7ebe95f310880f92fdad > Download recording link: > https://ietf.webex.com/ietf/lsr.php?RCID=b57f37cff1571be1061b1963a16bd472 > > - The main objective of the call is to help us (WG) move faster on our > chartered work items. RESTCONF is a big piece of that. Whatever we want > to decide must be verified on the WG mailing list. Of course some discussion > end up in changes to a document, which will always be presented to the WG > mailing list and which will eventually be Last Called, so everyone has a say. > > - We had 10 participants on the call > > - Kent presented GitHub, which is used to track issues and which also > is used by various editors to work together on the documents > * DECISION: We will NOT forward all changes in GITHUB to the WG > mailing list. > * Pull-requests for editorial changes are OK, > * but more substantial issues (in fact all issues) should be discussed > on our NETCONF WG mailing list. We can use github to keep track of the > status and to record summaries, proposed solutions and the final > resolution. > > - Andy presented RESTCONF issues > see: https://github.com/netconf-wg/restconf/issues > We discussed them in reverse order (will try to get them properly > discussed in order next time). I (Bert) have added all issues, > also those that were created new as a result o the virtual meeting and > those that were not discussed. If you want to comment or voice an > opinion on any issue (that would be VERY GOOD and HELPFUL), then pls > set the subject line to the issue number plus issue title. > > * issue # 10: Naming convention for Query Parameters > o opened by Bert as a result of our first virual meeting > o split off from issue # 6 > * issue # 9: Define how authentication is performed > o opened by Andy as a result of our first virtual meeting > * issue #7: Mandatory-to-implement encoding > o WG chairs did a poll on the WG list for opinions: > see: http://www.ietf.org/mail-archive/web/netconf/current/msg09218.html > It runs till Sept 18, so those who have not expressed an opinion yet > are encouraged to do so. > o For now, "Optional" encoding (choice d) got more votes than "XML mandatory" > (choice a). > o Martin mentions technical motivations were expressed with choice 'a' > o Bert reminded that STANDARDIZATION means making choices and making interoperability > easy. From that point of view, choice a seems more appropriate. > o ACTION: Bert will send reminder to collect more opinions (done) > * issue #6: how to identify query parameters supported by the server > o No prefix for ietf-defined (this is naming, see new issue #10) > o We basically have 2 issues, one is Naming,the other is discovery of which > parameters are supported by the server. So issue #6 stays as is, > issue #10 opened by Bert for Naming conventions > o Capability encoding in the air: Lada is thinking a json object > o Proposal to collapse into a single URI string > o Opinions of other WG participants are welcome! Please speak up > * issue #5: protocol capability URIs > o was not discussed on this call > o Toronto consensus: Add protocol capabilities somehow > o so we need to see new text in a revision of the draft > *issue #4: Defaults handling > o Mapping to RESTCONF straight forward > o the server MUST report what basic-mode it supports > o Question: Should full support of with-defaults RFC be added to base RESTCONF? > Please speak up and express opinions? > * issue #3: add collection resource > o Put collections media-type and query-parameters into main draft, but? > o There seems to be consensus to put collections resource in another document. > o Need to deal with GET on a list with no keys given: > GET /restconf/data/interfaces/interface > --> Maybe this will be an error unless collection resource requested > o Need text proposals on mailing list. > * issue #2 Netconf state monitoring > o Need to create an issue for authentication > (done by Andy, that is issue #9 > o Do we need to have a 6022-bis document or can RESTCONF just update the text > in order to support non-NETCONF sessions. > o An idea is to let this doc "update" RFC 6022 > * issue #1: Select parameter > o What syntax should be used for the "select" query parameter? The > current choices are "XPath" and "path-expr". Perhaps an > additional parameter to identify the select string format is > needed to allow extensibility? > o Martin's proposal stands...issue seems closed > o WG participants, please speak up if you cannot live with > Martin's proposal, see > https://github.com/netconf-wg/restconf/issues/1 > > - A question was raised by Mahesh, regarding CLI type uses as ping and traceroute. > He was asked to post the problem statement to the WG list, which he has done now > see: http://www.ietf.org/mail-archive/web/netconf/current/msg09254.html > > - Next time we will discuss restconf issues again, but also: call-home. > It seems like a good idea to then have the accompanying documents updated as well, > so: > o ACTION: Juergen should update 5539bis > 0 ACTION: Kent to submit server-model > > Bert Wijnen, with special thanks to Kent and Andy. > From nobody Fri Sep 12 15:23:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B401A0077 for ; Fri, 12 Sep 2014 15:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPoU7FeTAVM2 for ; Fri, 12 Sep 2014 15:23:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:709]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882571A004C for ; Fri, 12 Sep 2014 15:23:53 -0700 (PDT) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB347.namprd05.prod.outlook.com (10.141.52.11) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 12 Sep 2014 22:23:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Fri, 12 Sep 2014 22:23:28 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.88]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.176]) with mapi id 15.00.1029.000; Fri, 12 Sep 2014 22:23:28 +0000 From: Kent Watsen To: netconf Thread-Topic: RESTCONF data modeling issue Thread-Index: AQHPztgtxkNwDc5xeEO1pJ8JWyGpUg== Date: Fri, 12 Sep 2014 22:23:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(74662001)(74502001)(31966008)(77982001)(81342001)(110136001)(101416001)(50986999)(99286002)(77096002)(79102001)(95666004)(99396002)(64706001)(107886001)(106116001)(66066001)(76482001)(229853001)(107046002)(80022001)(83322001)(85306004)(86362001)(2656002)(46102001)(92566001)(92726001)(97736003)(21056001)(83506001)(90102001)(36756003)(4396001)(20776003)(81542001)(54356999)(105586002)(106356001)(87936001)(83072002)(85852003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <89A86840B76A7D43BBFE002941658215@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/jI-_xz4__E4Pe6YYegBo9vUEvmM Subject: [Netconf] RESTCONF data modeling issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 22:23:55 -0000 I have this simplified data model in draft-ietf-netconf-server-model: +--rw netconf-server +--rw listen* [name] | +--rw name string | ... +--rw call-home* [name] +--rw name string | ... This is following guidelines set in draft-schoenw-netmod-yang-pattern. The RESTCONF issue is how to POST a new listen or call-home instance? Normally we'd POST to the parent container, but here netconf-server is the parent to more than one collection. Since RESTCONF does not using media-types to differentiate the subtrees, how can this be supported? - or is it that this data-model can not be supported by RESTCONF and it should be restructured like this: +--rw netconf-server +--rw listen | +--rw endpoint* [name] | +--rw name string | ... +--rw call-home +--rw application* [name] +--rw name string | ... ??? Thanks, Kent From nobody Fri Sep 12 15:37:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8683F1A0077 for ; Fri, 12 Sep 2014 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjCrvpDjmfcs for ; Fri, 12 Sep 2014 15:37:00 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C752F1A004C for ; Fri, 12 Sep 2014 15:37:00 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id i13so1461141qae.8 for ; Fri, 12 Sep 2014 15:37:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q43qUFoDpGDRNR5YOv2Cd+BP28O3QLX5MKHEyvOjJ3U=; b=fs2zBGln5wMqWF8GbNCXQstvyzLuQKgO1W4JYBAs7tEA+5Wv4eq1ammyl8LRBOUuNA techjuLXDgeVxwCD3auGQWJhh8QUqxiXTIsIsUp2XoZE+SsyRr2DbwZxS3nw6o7o5Y7e pNEoCsLKhjhldMy8xju3cVBcVPay7p+cLTXxErt3t/OzXoU4jQAsgn262X8Kusl1ZmhT UuiFTNJlh6oLKJ+ZLniia1d8I4vAFoUo/SzvCvg7DV8CYEcKBKbJihojogu4q3rV+u/B 3hJP1Vhj2qkGmC7vMJz7iJOWaVJ7dQ+cDfaAVMTwAR5JuJ1IxV39hw1Wqn1sJWacUKIt tH9Q== X-Gm-Message-State: ALoCoQnSz1UP1AYJM7Jc5GPrmMVyc4KHoadPHWqxcqW1JS1Xdu1lpPaWwOzBpsc269IYVzFyNhSR MIME-Version: 1.0 X-Received: by 10.140.21.177 with SMTP id 46mr17383575qgl.90.1410561419990; Fri, 12 Sep 2014 15:36:59 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 12 Sep 2014 15:36:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Sep 2014 15:36:59 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c139865f710c0502e5ecb7 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/uAdCeJLtfS1AbJx2uXr7p3ZwCwo Cc: netconf Subject: Re: [Netconf] RESTCONF data modeling issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 22:37:02 -0000 --001a11c139865f710c0502e5ecb7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 12, 2014 at 3:23 PM, Kent Watsen wrote: > > I have this simplified data model in draft-ietf-netconf-server-model: > > +--rw netconf-server > +--rw listen* [name] > | +--rw name string > | ... > +--rw call-home* [name] > +--rw name string > | ... > > > This is following guidelines set in draft-schoenw-netmod-yang-pattern. > > The RESTCONF issue is how to POST a new listen or call-home instance? > Normally we'd POST to the parent container, but here netconf-server is the > parent to more than one collection. Since RESTCONF does not using > media-types to differentiate the subtrees, how can this be supported? - > or is it that this data-model can not be supported by RESTCONF and it > should be restructured like this: > > +--rw netconf-server > +--rw listen > | +--rw endpoint* [name] > | +--rw name string > | ... > +--rw call-home > +--rw application* [name] > +--rw name string > | ... > > > > I think you just use application/yang.data and the message body contains either a listen or a call-home instance. POST /restconf/data/netconf-server { "listen" : { "endpoint":"???", "name":"???" } } ??? > > Thanks, > Kent > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c139865f710c0502e5ecb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 12, 2014 at 3:23 PM, Kent Watsen <kwatsen@juniper.net> wrote:

I have this simplified data model in draft-ietf-netconf-server-model:

=A0 =A0+--rw netconf-server
=A0 =A0 =A0 +--rw listen* [name]
=A0 =A0 =A0 |=A0 +--rw name=A0 =A0 string
=A0 =A0 =A0 |=A0 ...
=A0 =A0 =A0 +--rw call-home* [name]
=A0 =A0 =A0 =A0 =A0+--rw name=A0 =A0 string
=A0 =A0 =A0 =A0 =A0| ...


This is following guidelines set in draft-schoenw-netmod-yang-pattern.

The RESTCONF issue is how to POST a new listen or call-home instance?
Normally we'd POST to the parent container, but here netconf-server is = the
parent to more than one collection.=A0 Since RESTCONF does not using
media-types to differentiate the subtrees, how can this be supported?=A0 -<= br> or is it that this data-model can not be supported by RESTCONF and it
should be restructured like this:

=A0 =A0+--rw netconf-server
=A0 =A0 =A0 +--rw listen
=A0 =A0 =A0 |=A0 +--rw endpoint* [name]
=A0 =A0 =A0 |=A0 =A0 =A0+--rw name=A0 =A0 string
=A0 =A0 =A0 |=A0 =A0 =A0...
=A0 =A0 =A0 +--rw call-home
=A0 =A0 =A0 =A0 =A0+--rw application* [name]
=A0 =A0 =A0 =A0 =A0 =A0 +--rw name=A0 =A0 string
=A0 =A0 =A0 =A0 =A0 =A0 | ...




I think you just use application/yang.= data and the message body contains
either a listen or a call-home= instance.

--001a11c139865f710c0502e5ecb7-- From nobody Fri Sep 12 16:35:01 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A8B1A00E1 for ; Fri, 12 Sep 2014 16:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XtAPj-xRXRO for ; Fri, 12 Sep 2014 16:34:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D4E1A00DD for ; Fri, 12 Sep 2014 16:34:58 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Fri, 12 Sep 2014 23:34:55 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.88]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.176]) with mapi id 15.00.1029.000; Fri, 12 Sep 2014 23:34:55 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] RESTCONF data modeling issue Thread-Index: AQHPztgtxkNwDc5xeEO1pJ8JWyGpUpv+FnCA///NIYA= Date: Fri, 12 Sep 2014 23:34:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(199003)(24454002)(377454003)(189002)(81342001)(99286002)(54356999)(101416001)(76176999)(74662001)(87936001)(92726001)(21056001)(99396002)(107046002)(86362001)(4396001)(92566001)(90102001)(77982001)(19617315012)(76482001)(83072002)(2656002)(105586002)(19580405001)(85306004)(36756003)(64706001)(106356001)(77096002)(66066001)(97736003)(83506001)(50986999)(81542001)(15975445006)(106116001)(80022001)(31966008)(74502001)(95666004)(85852003)(46102001)(79102001)(16236675004)(20776003)(19580395003)(83322001)(110136001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D038FA668143Akwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XUlyfRqDS9fdWJz4nZe-MGIud6Y Cc: netconf Subject: Re: [Netconf] RESTCONF data modeling issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 23:35:00 -0000 --_000_D038FA668143Akwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So the "collections" solution says that, in case of ambiguity, the RESTCONF= *server* MUST inspect the contents to discern which collection to POST to? Kent From: Andy Bierman > Date: Friday, September 12, 2014 at 6:36 PM To: Kent Watsen > Cc: NetConf > Subject: Re: [Netconf] RESTCONF data modeling issue On Fri, Sep 12, 2014 at 3:23 PM, Kent Watsen > wrote: I have this simplified data model in draft-ietf-netconf-server-model: +--rw netconf-server +--rw listen* [name] | +--rw name string | ... +--rw call-home* [name] +--rw name string | ... This is following guidelines set in draft-schoenw-netmod-yang-pattern. The RESTCONF issue is how to POST a new listen or call-home instance? Normally we'd POST to the parent container, but here netconf-server is the parent to more than one collection. Since RESTCONF does not using media-types to differentiate the subtrees, how can this be supported? - or is it that this data-model can not be supported by RESTCONF and it should be restructured like this: +--rw netconf-server +--rw listen | +--rw endpoint* [name] | +--rw name string | ... +--rw call-home +--rw application* [name] +--rw name string | ... I think you just use application/yang.data and the message body contains either a listen or a call-home instance. POST /restconf/data/netconf-server { "listen" : { "endpoint":"???", "name":"???" } } ??? Thanks, Kent Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_D038FA668143Akwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <8A908B8C239D274A8D76822D0CCF6BA1@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

So the "collections" solution says that, in case of ambiguit= y, the RESTCONF *server* MUST inspect the contents to discern which collect= ion to POST to?

Kent


From: Andy Bierman <andy@yumaworks.com>
Date: Friday, September 12, 2014 at= 6:36 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] RESTCONF dat= a modeling issue



On Fri, Sep 12, 2014 at 3:23 PM, Kent Watsen <kwatsen@junipe= r.net> wrote:

I have this simplified data model in draft-ietf-netconf-server-model:

   +--rw netconf-server
      +--rw listen* [name]
      |  +--rw name    string
      |  ...
      +--rw call-home* [name]
         +--rw name    string
         | ...


This is following guidelines set in draft-schoenw-netmod-yang-pattern.

The RESTCONF issue is how to POST a new listen or call-home instance?
Normally we'd POST to the parent container, but here netconf-server is the<= br> parent to more than one collection.  Since RESTCONF does not using
media-types to differentiate the subtrees, how can this be supported? = -
or is it that this data-model can not be supported by RESTCONF and it
should be restructured like this:

   +--rw netconf-server
      +--rw listen
      |  +--rw endpoint* [name]
      |     +--rw name    strin= g
      |     ...
      +--rw call-home
         +--rw application* [name]
            +--rw name    strin= g
            | ...




I think you just use application/yang.data and the message body contai= ns
either a listen or a call-home instance.

POST /restconf/data/netconf-server

{ "listen" : {
     "endpoint":"???",
     "name":"???"
   }
}

???

Thanks,
Kent



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

 --_000_D038FA668143Akwatsenjunipernet_-- From nobody Fri Sep 12 16:45:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080011A00EF for ; Fri, 12 Sep 2014 16:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOILyCIAEi3A for ; Fri, 12 Sep 2014 16:45:24 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8691A00F0 for ; Fri, 12 Sep 2014 16:45:23 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id v10so1436224qac.21 for ; Fri, 12 Sep 2014 16:45:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6YjNX8D2H1T/CF0OAZnwqs/JPN3aXStlc9WkJZlAYRw=; b=foLHnLzuqct9QHDB9capKN/BMpbuuXPhuQyIOrp5DqP+PL2MMpBClI+jccuPRMB2Tt gYQbr4FmsCwLELb07u8JtOw/ChVg+2aYF9i34/tN9N8hvabDC2RcGEIG3FfE9zKa/3oY GKjGpFsceBGsQnBDMlLjN9Odrt32JEG4QFtB0+B9jn6PhkZKIUCdUSSNnLmRIIOOXJGs /ENCfRity93yRUs31uRovf0F9iz7aAj7Jqs2mbAZWUDMOy7rlQC1d/OIKhUHcsBZa9KG jSbNXhWxkrF/COx3TCggTQDNT6DL4/HA5C0rOCq0bJN05LEYlo5nxtul91zMNugojPiv spOg== X-Gm-Message-State: ALoCoQlzNfBq9UHZoJ5AE8JiM+XbhE+gmwGCPPwAGSmsgBbjk+396No4ubtXUmtQ5i4kQGkIT6Ok MIME-Version: 1.0 X-Received: by 10.229.84.133 with SMTP id j5mr17283072qcl.14.1410565522026; Fri, 12 Sep 2014 16:45:22 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 12 Sep 2014 16:45:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Sep 2014 16:45:21 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11345256df8da00502e6e078 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ABLvregJ-rYkLix-LPJHV1_3j6Q Cc: netconf Subject: Re: [Netconf] RESTCONF data modeling issue X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 23:45:26 -0000 --001a11345256df8da00502e6e078 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 12, 2014 at 4:34 PM, Kent Watsen wrote: > > So the "collections" solution says that, in case of ambiguity, the > RESTCONF *server* MUST inspect the contents to discern which collection to > POST to? > > I don't know what the collections have to do with it. The server knows the YANG module so it knows the child nodes (sub-resources) for the parent node. > Kent > > Andy > > From: Andy Bierman > Date: Friday, September 12, 2014 at 6:36 PM > To: Kent Watsen > Cc: NetConf > Subject: Re: [Netconf] RESTCONF data modeling issue > > > > On Fri, Sep 12, 2014 at 3:23 PM, Kent Watsen wrote: > >> >> I have this simplified data model in draft-ietf-netconf-server-model: >> >> +--rw netconf-server >> +--rw listen* [name] >> | +--rw name string >> | ... >> +--rw call-home* [name] >> +--rw name string >> | ... >> >> >> This is following guidelines set in draft-schoenw-netmod-yang-pattern. >> >> The RESTCONF issue is how to POST a new listen or call-home instance? >> Normally we'd POST to the parent container, but here netconf-server is the >> parent to more than one collection. Since RESTCONF does not using >> media-types to differentiate the subtrees, how can this be supported? - >> or is it that this data-model can not be supported by RESTCONF and it >> should be restructured like this: >> >> +--rw netconf-server >> +--rw listen >> | +--rw endpoint* [name] >> | +--rw name string >> | ... >> +--rw call-home >> +--rw application* [name] >> +--rw name string >> | ... >> >> >> >> > I think you just use application/yang.data and the message body contains > either a listen or a call-home instance. > > POST /restconf/data/netconf-server > > { "listen" : { > "endpoint":"???", > "name":"???" > } > } > > ??? >> >> Thanks, >> Kent >> >> > > Andy > > >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > --001a11345256df8da00502e6e078 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 12, 2014 at 4:34 PM, Kent Watsen <kwatsen@juniper.net> wrote:

So the "collections" solution says that, in case of ambiguit= y, the RESTCONF *server* MUST inspect the contents to discern which collect= ion to POST to?


I don't know what= the collections have to do with it.
The server knows the YANG mo= dule so it knows the child nodes
(sub-resources) for the parent n= ode.

=A0
Kent


Andy
=A0

From: Andy Bierman <andy@yumaworks.com>
Date: Friday, September 12, 2014 at= 6:36 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] RESTCONF dat= a modeling issue



On Fri, Sep 12, 2014 at 3:23 PM, Kent Watsen <kwatsen@junipe= r.net> wrote:

I have this simplified data model in draft-ietf-netconf-server-model:

=A0 =A0+--rw netconf-server
=A0 =A0 =A0 +--rw listen* [name]
=A0 =A0 =A0 |=A0 +--rw name=A0 =A0 string
=A0 =A0 =A0 |=A0 ...
=A0 =A0 =A0 +--rw call-home* [name]
=A0 =A0 =A0 =A0 =A0+--rw name=A0 =A0 string
=A0 =A0 =A0 =A0 =A0| ...


This is following guidelines set in draft-schoenw-netmod-yang-pattern.

The RESTCONF issue is how to POST a new listen or call-home instance?
Normally we'd POST to the parent container, but here netconf-server is = the
parent to more than one collection.=A0 Since RESTCONF does not using
media-types to differentiate the subtrees, how can this be supported?=A0 -<= br> or is it that this data-model can not be supported by RESTCONF and it
should be restructured like this:

=A0 =A0+--rw netconf-server
=A0 =A0 =A0 +--rw listen
=A0 =A0 =A0 |=A0 +--rw endpoint* [name]
=A0 =A0 =A0 |=A0 =A0 =A0+--rw name=A0 =A0 string
=A0 =A0 =A0 |=A0 =A0 =A0...
=A0 =A0 =A0 +--rw call-home
=A0 =A0 =A0 =A0 =A0+--rw application* [name]
=A0 =A0 =A0 =A0 =A0 =A0 +--rw name=A0 =A0 string
=A0 =A0 =A0 =A0 =A0 =A0 | ...




I think you just use application/yang.data and the message body contai= ns
either a listen or a call-home instance.

POST /restconf/data/netconf-server

{ "listen" : {
=A0 =A0 =A0"endpoint":"???",
=A0 =A0 =A0"name":"???"
=A0 =A0}
}

???

Thanks,
Kent



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


--001a11345256df8da00502e6e078-- From nobody Sat Sep 13 11:19:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68301A0008 for ; Sat, 13 Sep 2014 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrhSH_TYr7YC for ; Sat, 13 Sep 2014 11:19:44 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014CC1A0053 for ; Sat, 13 Sep 2014 11:19:43 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q107so2266103qgd.33 for ; Sat, 13 Sep 2014 11:19:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=iFGZ9+++NAbhl7iS9UhgaWg6CAAR++xTCa6nytGXrEc=; b=aR3oFWlbwaOPuWBCZLWm+RqhyvBU/TPVeLqwE387cnCV+KEjW1DY4PadXZO6BoXVp1 oQmLdqFNvQ/CheiGmGm52mz1PydyMYQRFf0klqOzaymt8qCHyjjW2UvOVCYTJS5NJjfW 8KxqnQ7aH4gKpLO4GWOdOQDjLfeBWPy7xh90O7TXjLKeudebeFysBBSNcn6ljyWYTqRd OD8uNQi8t4lsXPouPs5doXfyxNZ2yxl+k668K4Jn/47fAf7jVsbShQl1NjQfwtTdLkBw +OnTJeGwJLPppXxETTZaKG2YQ3Y9hm2iYjtQ5FVFEtCxeKuw5/M3ZXu9XI0rLHFAfXqt ceqQ== X-Gm-Message-State: ALoCoQnz/L5CRfe6cdjmFNKNBgLsCwPxs2UdQFjueEQLhjkhXvpCEGqMgyjLwgT5IHAToj8kkuta MIME-Version: 1.0 X-Received: by 10.140.22.203 with SMTP id 69mr24658576qgn.35.1410632382697; Sat, 13 Sep 2014 11:19:42 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Sat, 13 Sep 2014 11:19:42 -0700 (PDT) Date: Sat, 13 Sep 2014 11:19:42 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c14f781489f30502f67288 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/cphhLlKilwyCesDquj9yy3HNX4w Subject: [Netconf] RESTCONF YANG module changes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 18:19:46 -0000 --001a11c14f781489f30502f67288 Content-Type: text/plain; charset=ISO-8859-1 Hi, Martin suggested moving the RESTCONF API data to a real YANG module. I have been trying to figure out how that would work. Here is the first draft: (It includes the new capability URI leaf-list we agreed to add) OLD: ietf-restconf.yang Abstract module (defined in a grouping) because read-only nodes contain a writable data root and not intended for NETCONF advertisement) +--rw restconf +--rw data +--rw modules | +--rw module* [name revision] | +--rw name yang:yang-identifier | +--rw revision union | +--rw schema? empty | +--rw namespace inet:uri | +--rw feature* yang:yang-identifier | +--rw deviation* yang:yang-identifier | +--rw submodule* [name revision] | +--rw name yang:yang-identifier | +--rw revision union | +--rw schema? empty +--rw operations +--rw streams +--rw stream* [name] +--rw name string +--rw description? string +--rw replay-support? boolean +--rw replay-log-creation-time? yang:date-and-time +--rw events? empty NEW: ietf-restconf-api.yang Abstract module (defined in a grouping) because read-only nodes contain a writable data root and not intended for NETCONF advertisement) +--rw restconf +--rw data +--rw operations ietf-restconf-state.yang (Almost) normal YANG module that is populated under /restconf/data +--ro ietf-restconf-state + ro capabilities | +-ro capability* +--ro modules | +--ro module* [name revision] | +--ro name yang:yang-identifier | +--ro revision union | +--ro schema? empty | +--ro namespace inet:uri | +--ro feature* yang:yang-identifier | +--ro deviation* yang:yang-identifier | +--ro submodule* [name revision] | +--ro name yang:yang-identifier | +--ro revision union | +--ro schema? empty [1] +--ro streams +--ro stream* [name] +--ro name string +--ro description? string +--ro replay-support? boolean +--ro replay-log-creation-time? yang:date-and-time +--ro events? empty [2] [1] This is the node that magically sends plain YANG application/yang. In NETCONF it is just an empty leaf, but in RESTCONF it needs to be flagged somehow. It looks like application/yang.data in the schema. [2] This is the node that magically sends SSE text/event-stream data until the client drops the connection. In NETCONF it is just an empty leaf, but in RESTCONF it needs to be flagged somehow. It looks like application/yang.data in the schema. (Notice how the name ietf-restconf.yang is now reserved for a configuration module for RESTCONF when we are ready for that?). YANG extension proposal for RESTCONF: This extension could be used in the [1] and [2] cases above to help tools automate the processing. extension media-type { argument media-type; description "Identifies the media type associated with a YANG data node. Ignored unless defined as a sub-statement within a data-def-stmt. If this extension is not present, then the default is the media type associated with the parent data-def-stmt. If there is no parent node then the media type is 'application/yang.data'."; } Andy --001a11c14f781489f30502f67288 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Martin suggested moving the RESTCON= F API data to a real YANG module.
I have been trying to figure ou= t how that would work. Here is the first draft:
(It includes the ne= w capability URI leaf-list we agreed to add)

OLD:<= /div>

=A0 ietf-restconf.yang =A0
=A0 Abstract = module (defined in a grouping) because read-only nodes contain a writable d= ata root
=A0 and not intended for NETCONF advertisement)

=A0 =A0 =A0 +--rw restconf
=A0 =A0 =A0 =A0 = =A0+--rw data
=A0 =A0 =A0 =A0 =A0+--rw modules
=A0 =A0 = =A0 =A0 =A0| =A0+--rw module* [name revision]
=A0 =A0 =A0 =A0 =A0= | =A0 =A0 +--rw name =A0 =A0 =A0 =A0 yang:yang-identifier
=A0 =A0= =A0 =A0 =A0| =A0 =A0 +--rw revision =A0 =A0 union
=A0 =A0 =A0 = =A0 =A0| =A0 =A0 +--rw schema? =A0 =A0 =A0empty
=A0 =A0 =A0 =A0 = =A0| =A0 =A0 +--rw namespace =A0 =A0inet:uri
=A0 =A0 =A0 =A0 =A0|= =A0 =A0 +--rw feature* =A0 =A0 yang:yang-identifier
=A0 =A0 =A0 = =A0 =A0| =A0 =A0 +--rw deviation* =A0 yang:yang-identifier
=A0 = =A0 =A0 =A0 =A0| =A0 =A0 +--rw submodule* [name revision]
=A0 =A0= =A0 =A0 =A0| =A0 =A0 =A0 =A0+--rw name =A0 =A0 =A0 =A0yang:yang-identifier=
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0+--rw revision =A0 =A0union<= /div>
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0+--rw schema? =A0 =A0 empty
=A0 =A0 =A0 =A0 =A0+--rw operations
=A0 =A0 =A0 =A0 =A0+= --rw streams
=A0 =A0 =A0 =A0 =A0 =A0 +--rw stream* [name]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw name =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0string
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw de= scription? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0string
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0+--rw replay-support? =A0 =A0 =A0 =A0 =A0 =A0 boolean
<= div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw replay-log-creation-time? =A0 yang= :date-and-time
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw events? =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 empty

NE= W:

=A0ietf-restconf-api.yang =A0
= =A0 Abstract module (defined in a grouping) because read-only nodes contain= a writable data root
=A0 and not intended for NETCONF advertisem= ent)

=A0 =A0 =A0 +--rw restconf
=A0 =A0 =A0 =A0 =A0+--rw data
=A0 =A0 =A0 =A0 =A0+--rw op= erations

ietf-restconf-state.yang
=A0 = =A0(Almost) normal YANG module that is populated under /restconf/data
=

=A0 =A0 =A0 +--ro ietf-restconf-state
=A0 =A0 =A0 = =A0 + ro capabilities
=A0 =A0 =A0 =A0 =A0| =A0 +-ro capability*
=A0 =A0 =A0 =A0 +--ro modules
=A0 =A0 =A0 =A0 =A0| =A0+-= -ro module* [name revision]
=A0 =A0 =A0 =A0 =A0| =A0 =A0 +--ro na= me =A0 =A0 =A0 =A0 yang:yang-identifier
=A0 =A0 =A0 =A0 =A0| =A0 = =A0 +--ro revision =A0 =A0 union
=A0 =A0 =A0 =A0 =A0| =A0 =A0 +--= ro schema? =A0 =A0 =A0empty
=A0 =A0 =A0 =A0 =A0| =A0 =A0 +--ro na= mespace =A0 =A0inet:uri
=A0 =A0 =A0 =A0 =A0| =A0 =A0 +--ro featur= e* =A0 =A0 yang:yang-identifier
=A0 =A0 =A0 =A0 =A0| =A0 =A0 +--r= o deviation* =A0 yang:yang-identifier
=A0 =A0 =A0 =A0 =A0| =A0 = =A0 +--ro submodule* [name revision]
=A0 =A0 =A0 =A0 =A0| =A0 =A0= =A0 =A0+--ro name =A0 =A0 =A0 =A0yang:yang-identifier
=A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0+--ro revision =A0 =A0union
=A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0+--ro schema? =A0 =A0 empty =A0 =A0 [1]
=A0 =A0 =A0 =A0 =A0+--ro streams
=A0 =A0 =A0 =A0 =A0 =A0 +--ro= stream* [name]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--ro name =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0string
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0+--ro description? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0string
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--ro replay-support? =A0 =A0 =A0 =A0= =A0 =A0 boolean
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--ro replay-log-= creation-time? =A0 yang:date-and-time
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0+--ro events? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 empty =A0 [2]

[1] =A0This is the node that magically sen= ds plain YANG =A0application/yang.=A0
In NETCONF it is just an em= pty leaf, but in RESTCONF
it needs to be flagged somehow. It look= s like application/yang.data in the schema.

= [2] =A0This is the node that magically sends SSE text/event-stream data unt= il the client
drops the connection. =A0In NETCONF it is just an e= mpty leaf, but in RESTCONF
it needs to be flagged somehow. It loo= ks like application/yang.data in the schema.

= (Notice how the name ietf-restconf.yang is now reserved for a configuration= module
for RESTCONF when we are ready for that?).

YANG extension proposal for RESTCONF:
This exten= sion could be used in the [1] and [2] cases above to help tools automate th= e processing.

=A0 =A0extension media-type {
<= div>=A0 =A0 =A0 =A0argument media-type;
=A0 =A0 =A0 =A0descriptio= n
=A0 =A0 =A0 =A0 =A0 "Identifies the media type associated = with a YANG data node.
=A0 =A0 =A0 =A0 =A0 =A0Ignored unless defi= ned as a sub-statement within a data-def-stmt.
=A0 =A0 =A0 =A0 = =A0 =A0If this extension is not present, then the default is the media type= associated
=A0 =A0 =A0 =A0 =A0 =A0with the parent data-def-stmt.= =A0If there is no parent node then the
=A0 =A0 =A0 =A0 =A0 =A0me= dia type is 'application/yang.data'.";
=A0 =A0 =A0}<= /div>



Andy

<= /div>

--001a11c14f781489f30502f67288-- From nobody Sun Sep 14 04:52:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086651A031C for ; Sun, 14 Sep 2014 04:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1gAGXIQ-2Qa for ; Sun, 14 Sep 2014 04:51:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AFA1A0316 for ; Sun, 14 Sep 2014 04:51:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 160821237; Sun, 14 Sep 2014 13:51:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5vCjIygxRyY5; Sun, 14 Sep 2014 13:51:25 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 14 Sep 2014 13:51:56 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2209620036; Sun, 14 Sep 2014 13:51:56 +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 zwC-FsTpBqs7; Sun, 14 Sep 2014 13:51:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C491120035; Sun, 14 Sep 2014 13:51:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 167682E64D82; Sun, 14 Sep 2014 13:51:52 +0200 (CEST) Date: Sun, 14 Sep 2014 13:51:52 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140914115152.GA10359@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pGQ1C6PFvaHWz09yaYQfMX-uuS0 Cc: Netconf Subject: Re: [Netconf] RESTCONF YANG module changes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 11:52:03 -0000 Hi, can someone give a high-level overview why this is all needed given that we have ietf-netconf-monitoring.yang? Is it because the existing monitoring data model is not detailed enough? Or is it because it says 'netconf' in the name and thus people feel it is not applicable? /js On Sat, Sep 13, 2014 at 11:19:42AM -0700, Andy Bierman wrote: > Hi, > > Martin suggested moving the RESTCONF API data to a real YANG module. > I have been trying to figure out how that would work. Here is the first > draft: > (It includes the new capability URI leaf-list we agreed to add) > > OLD: > > ietf-restconf.yang > Abstract module (defined in a grouping) because read-only nodes contain a > writable data root > and not intended for NETCONF advertisement) > > +--rw restconf > +--rw data > +--rw modules > | +--rw module* [name revision] > | +--rw name yang:yang-identifier > | +--rw revision union > | +--rw schema? empty > | +--rw namespace inet:uri > | +--rw feature* yang:yang-identifier > | +--rw deviation* yang:yang-identifier > | +--rw submodule* [name revision] > | +--rw name yang:yang-identifier > | +--rw revision union > | +--rw schema? empty > +--rw operations > +--rw streams > +--rw stream* [name] > +--rw name string > +--rw description? string > +--rw replay-support? boolean > +--rw replay-log-creation-time? yang:date-and-time > +--rw events? empty > > NEW: > > ietf-restconf-api.yang > Abstract module (defined in a grouping) because read-only nodes contain a > writable data root > and not intended for NETCONF advertisement) > > +--rw restconf > +--rw data > +--rw operations > > ietf-restconf-state.yang > (Almost) normal YANG module that is populated under /restconf/data > > +--ro ietf-restconf-state > + ro capabilities > | +-ro capability* > +--ro modules > | +--ro module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro schema? empty > | +--ro namespace inet:uri > | +--ro feature* yang:yang-identifier > | +--ro deviation* yang:yang-identifier > | +--ro submodule* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro schema? empty [1] > +--ro streams > +--ro stream* [name] > +--ro name string > +--ro description? string > +--ro replay-support? boolean > +--ro replay-log-creation-time? yang:date-and-time > +--ro events? empty [2] > > [1] This is the node that magically sends plain YANG application/yang. > In NETCONF it is just an empty leaf, but in RESTCONF > it needs to be flagged somehow. It looks like application/yang.data in the > schema. > > [2] This is the node that magically sends SSE text/event-stream data until > the client > drops the connection. In NETCONF it is just an empty leaf, but in RESTCONF > it needs to be flagged somehow. It looks like application/yang.data in the > schema. > > (Notice how the name ietf-restconf.yang is now reserved for a configuration > module > for RESTCONF when we are ready for that?). > > YANG extension proposal for RESTCONF: > This extension could be used in the [1] and [2] cases above to help tools > automate the processing. > > extension media-type { > argument media-type; > description > "Identifies the media type associated with a YANG data node. > Ignored unless defined as a sub-statement within a data-def-stmt. > If this extension is not present, then the default is the media > type associated > with the parent data-def-stmt. If there is no parent node then > the > media type is 'application/yang.data'."; > } > > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Sep 14 06:44:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BBB1A0382 for ; Sun, 14 Sep 2014 06:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwl5ei2pUFdp for ; Sun, 14 Sep 2014 06:44:02 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A401A031D for ; Sun, 14 Sep 2014 06:44:01 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id v10so2712748qac.7 for ; Sun, 14 Sep 2014 06:44:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=mdrCGRVj5v2k0XA84uTjTkfx/Xr0/2700vQIrPaZe0g=; b=XgUwfXFixwPfOvhLEKHY/t9GAWoPAmM5zO2tfKxrNMzf7uNnLzlUCGf4XpOXqgU1YE CJy/W3dWA1YDLR51kAnAR9Xh56kjj+/Oty6/snx8McYQpXZHVEg5Ep6mHAHfAbUR/r5i zlNhQIFzdpoAI/zK4welEEE+XNyO4f3zi2ITjVx1LDYYtXas4Oi/sjUzxl11yrMb1Dtn Sq6QSj80uOUY/XvDszMgD05Ch0uRlSdl679ewrfqEDsZA/+wtJUQNbqufvekJUCdvZF2 fd7txVPFKSFe10j9D/9lfD2Oh5fs8qd6k94jYN5BBVU0Bd08VOxKP4BbiwVdbmKNhBJW vhTw== X-Gm-Message-State: ALoCoQkcCCpHD3UM08/Ph64qHF/+JoXz5SnmhhVIMdNgEWwW+RDXy+rAtj4r7zIaifo1W0+BESUw MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr28218582qab.7.1410702240847; Sun, 14 Sep 2014 06:44:00 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Sun, 14 Sep 2014 06:44:00 -0700 (PDT) In-Reply-To: <20140914115152.GA10359@elstar.local> References: <20140914115152.GA10359@elstar.local> Date: Sun, 14 Sep 2014 06:44:00 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=001a11c1c560f335f5050306b580 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/rmF66oVIa3FN50E-Ox4dlZsaFa8 Subject: Re: [Netconf] RESTCONF YANG module changes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 13:44:04 -0000 --001a11c1c560f335f5050306b580 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 14, 2014 at 4:51 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > can someone give a high-level overview why this is all needed given > that we have ietf-netconf-monitoring.yang? Is it because the existing > monitoring data model is not detailed enough? Or is it because it says > 'netconf' in the name and thus people feel it is not applicable? > > There is no requirement that NETCONF and RESTCONF advertise the same set of modules or capabilities. RESTCONF does not use the RPC. RFC 6022 is written to be specific to NETCONF. It is optional to implement in NETCONF but this info is mandatory in RESTCONF. We might be able to use an update to this RFC, but it cannot be used as-is. It would be subject to additions and improvements (needs both). /js > Andy > > On Sat, Sep 13, 2014 at 11:19:42AM -0700, Andy Bierman wrote: > > Hi, > > > > Martin suggested moving the RESTCONF API data to a real YANG module. > > I have been trying to figure out how that would work. Here is the first > > draft: > > (It includes the new capability URI leaf-list we agreed to add) > > > > OLD: > > > > ietf-restconf.yang > > Abstract module (defined in a grouping) because read-only nodes > contain a > > writable data root > > and not intended for NETCONF advertisement) > > > > +--rw restconf > > +--rw data > > +--rw modules > > | +--rw module* [name revision] > > | +--rw name yang:yang-identifier > > | +--rw revision union > > | +--rw schema? empty > > | +--rw namespace inet:uri > > | +--rw feature* yang:yang-identifier > > | +--rw deviation* yang:yang-identifier > > | +--rw submodule* [name revision] > > | +--rw name yang:yang-identifier > > | +--rw revision union > > | +--rw schema? empty > > +--rw operations > > +--rw streams > > +--rw stream* [name] > > +--rw name string > > +--rw description? string > > +--rw replay-support? boolean > > +--rw replay-log-creation-time? yang:date-and-time > > +--rw events? empty > > > > NEW: > > > > ietf-restconf-api.yang > > Abstract module (defined in a grouping) because read-only nodes > contain a > > writable data root > > and not intended for NETCONF advertisement) > > > > +--rw restconf > > +--rw data > > +--rw operations > > > > ietf-restconf-state.yang > > (Almost) normal YANG module that is populated under /restconf/data > > > > +--ro ietf-restconf-state > > + ro capabilities > > | +-ro capability* > > +--ro modules > > | +--ro module* [name revision] > > | +--ro name yang:yang-identifier > > | +--ro revision union > > | +--ro schema? empty > > | +--ro namespace inet:uri > > | +--ro feature* yang:yang-identifier > > | +--ro deviation* yang:yang-identifier > > | +--ro submodule* [name revision] > > | +--ro name yang:yang-identifier > > | +--ro revision union > > | +--ro schema? empty [1] > > +--ro streams > > +--ro stream* [name] > > +--ro name string > > +--ro description? string > > +--ro replay-support? boolean > > +--ro replay-log-creation-time? yang:date-and-time > > +--ro events? empty [2] > > > > [1] This is the node that magically sends plain YANG application/yang. > > In NETCONF it is just an empty leaf, but in RESTCONF > > it needs to be flagged somehow. It looks like application/yang.data in > the > > schema. > > > > [2] This is the node that magically sends SSE text/event-stream data > until > > the client > > drops the connection. In NETCONF it is just an empty leaf, but in > RESTCONF > > it needs to be flagged somehow. It looks like application/yang.data in > the > > schema. > > > > (Notice how the name ietf-restconf.yang is now reserved for a > configuration > > module > > for RESTCONF when we are ready for that?). > > > > YANG extension proposal for RESTCONF: > > This extension could be used in the [1] and [2] cases above to help tools > > automate the processing. > > > > extension media-type { > > argument media-type; > > description > > "Identifies the media type associated with a YANG data node. > > Ignored unless defined as a sub-statement within a > data-def-stmt. > > If this extension is not present, then the default is the > media > > type associated > > with the parent data-def-stmt. If there is no parent node > then > > the > > media type is 'application/yang.data'."; > > } > > > > > > > > Andy > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c1c560f335f5050306b580 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 14, 2014 at 4:51 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

can someone give a high-level overview why this is all needed given
that we have ietf-netconf-monitoring.yang? Is it because the existing
monitoring data model is not detailed enough? Or is it because it says
'netconf' in the name and thus people feel it is not applicable?

There is no requirement that NETCONF a= nd RESTCONF advertise the
same set of modules or capabilities. RE= STCONF does not use the
<get-schema> RPC.=A0

=
RFC 6022 is written to be specific to NETCONF. =A0It is optional= to implement
in NETCONF but this info is mandatory in RESTCONF. = =A0We might be able
to use an update to this RFC, but it cannot b= e used as-is. =A0It would be subject
to additions and improvement= s (needs both).=A0


/js

Andy
=A0

On Sat, Sep 13, 2014 at 11:19:42AM -0700, Andy Bierman wrote:
> Hi,
>
> Martin suggested moving the RESTCONF API data to a real YANG module. > I have been trying to figure out how that would work. Here is the firs= t
> draft:
> (It includes the new capability URI leaf-list we agreed to add)
>
> OLD:
>
>=A0 =A0ietf-restconf.yang
>=A0 =A0Abstract module (defined in a grouping) because read-only nodes = contain a
> writable data root
>=A0 =A0and not intended for NETCONF advertisement)
>
>=A0 =A0 =A0 =A0+--rw restconf
>=A0 =A0 =A0 =A0 =A0 +--rw data
>=A0 =A0 =A0 =A0 =A0 +--rw modules
>=A0 =A0 =A0 =A0 =A0 |=A0 +--rw module* [name revision]
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw name=A0 =A0 =A0 =A0 =A0yang:yang-= identifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw revision=A0 =A0 =A0union
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw schema?=A0 =A0 =A0 empty
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw namespace=A0 =A0 inet:uri
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw feature*=A0 =A0 =A0yang:yang-iden= tifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw deviation*=A0 =A0yang:yang-identi= fier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw submodule* [name revision]
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--rw name=A0 =A0 =A0 =A0 yang:yan= g-identifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--rw revision=A0 =A0 union
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--rw schema?=A0 =A0 =A0empty
>=A0 =A0 =A0 =A0 =A0 +--rw operations
>=A0 =A0 =A0 =A0 =A0 +--rw streams
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw stream* [name]
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw name=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw description?=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw replay-support?=A0 =A0 =A0 =A0 = =A0 =A0 =A0boolean
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw replay-log-creation-time?=A0 =A0y= ang:date-and-time
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw events?=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0empty
>
> NEW:
>
>=A0 ietf-restconf-api.yang
>=A0 =A0Abstract module (defined in a grouping) because read-only nodes = contain a
> writable data root
>=A0 =A0and not intended for NETCONF advertisement)
>
>=A0 =A0 =A0 =A0+--rw restconf
>=A0 =A0 =A0 =A0 =A0 +--rw data
>=A0 =A0 =A0 =A0 =A0 +--rw operations
>
> ietf-restconf-state.yang
>=A0 =A0 (Almost) normal YANG module that is populated under /restconf/d= ata
>
>=A0 =A0 =A0 =A0+--ro ietf-restconf-state
>=A0 =A0 =A0 =A0 =A0+ ro capabilities
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0+-ro capability*
>=A0 =A0 =A0 =A0 =A0+--ro modules
>=A0 =A0 =A0 =A0 =A0 |=A0 +--ro module* [name revision]
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro name=A0 =A0 =A0 =A0 =A0yang:yang-= identifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro revision=A0 =A0 =A0union
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro schema?=A0 =A0 =A0 empty
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro namespace=A0 =A0 inet:uri
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro feature*=A0 =A0 =A0yang:yang-iden= tifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro deviation*=A0 =A0yang:yang-identi= fier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro submodule* [name revision]
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro name=A0 =A0 =A0 =A0 yang:yan= g-identifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro revision=A0 =A0 union
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro schema?=A0 =A0 =A0empty=A0 = =A0 =A0[1]
>=A0 =A0 =A0 =A0 =A0 +--ro streams
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--ro stream* [name]
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro name=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro description?=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro replay-support?=A0 =A0 =A0 =A0 = =A0 =A0 =A0boolean
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro replay-log-creation-time?=A0 =A0y= ang:date-and-time
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro events?=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0empty=A0 =A0[2]
>
> [1]=A0 This is the node that magically sends plain YANG=A0 application= /yang.
> In NETCONF it is just an empty leaf, but in RESTCONF
> it needs to be flagged somehow. It looks like application/yang.data in= the
> schema.
>
> [2]=A0 This is the node that magically sends SSE text/event-stream dat= a until
> the client
> drops the connection.=A0 In NETCONF it is just an empty leaf, but in R= ESTCONF
> it needs to be flagged somehow. It looks like application/yang.data in= the
> schema.
>
> (Notice how the name ietf-restconf.yang is now reserved for a configur= ation
> module
> for RESTCONF when we are ready for that?).
>
> YANG extension proposal for RESTCONF:
> This extension could be used in the [1] and [2] cases above to help to= ols
> automate the processing.
>
>=A0 =A0 extension media-type {
>=A0 =A0 =A0 =A0 argument media-type;
>=A0 =A0 =A0 =A0 description
>=A0 =A0 =A0 =A0 =A0 =A0"Identifies the media type associated with = a YANG data node.
>=A0 =A0 =A0 =A0 =A0 =A0 Ignored unless defined as a sub-statement withi= n a data-def-stmt.
>=A0 =A0 =A0 =A0 =A0 =A0 If this extension is not present, then the defa= ult is the media
> type associated
>=A0 =A0 =A0 =A0 =A0 =A0 with the parent data-def-stmt.=A0 If there is n= o parent node then
> the
>=A0 =A0 =A0 =A0 =A0 =A0 media type is 'application/yang.data'.&= quot;;
>=A0 =A0 =A0 }
>
>
>
> Andy

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


--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c1c560f335f5050306b580-- From nobody Sun Sep 14 09:50:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFE31A00D5 for ; Sun, 14 Sep 2014 09:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uFATAB6xQKE for ; Sun, 14 Sep 2014 09:50:26 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F22A1A00C2 for ; Sun, 14 Sep 2014 09:50:25 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j5so2841873qga.22 for ; Sun, 14 Sep 2014 09:50:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=WsQVEEDOAdHswwrHis55QM/+u1y+ST4Wb2G1DlPmDIU=; b=gdL1yOcIAHsaefxDRfeOrRsXSOTvIkAt5dXtrO556BIP8hDpIbyCJOaOXNp71ITkiX Xy0ZqT89fab+9sIF0lPVXcISxMfXGdNR95aABrQ0vv8bqamQlDtjjgsbX0sbuWNgie4+ +7i4PP7R05rGf8IxSL5uMRDXmmS5iArMFaDt2zrJs8bsLCiVbnhMmHj4jLCk2J/CQ+7F x3Z0Qt2LxZjqdgt03Y4pK/v9nOC0JORMFqHn+GvV2lpfoRlxWf5NoVavWgG7B0DZGyxO Cuxz10vgOoHMT8NmfP7BomvHxGX1TSC1MDj6e0HxFtSrioW2brsu+9mbZ8U/PpWaqeE5 uVgA== X-Gm-Message-State: ALoCoQkT6za6podFicLqKNoVXmWZqvA24H1A2ULUjg31Lh5pdiHK4A5bbtWDC2KtYwm6jJeGrVkc MIME-Version: 1.0 X-Received: by 10.140.98.166 with SMTP id o35mr30465088qge.21.1410713425049; Sun, 14 Sep 2014 09:50:25 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Sun, 14 Sep 2014 09:50:24 -0700 (PDT) In-Reply-To: <20140914115152.GA10359@elstar.local> References: <20140914115152.GA10359@elstar.local> Date: Sun, 14 Sep 2014 09:50:24 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=001a1139304e949aaa0503095029 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6WzAAYJdcqMNB-P8g-9sGxAWYAE Subject: Re: [Netconf] RESTCONF YANG module changes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 16:50:30 -0000 --001a1139304e949aaa0503095029 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 14, 2014 at 4:51 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > can someone give a high-level overview why this is all needed given > that we have ietf-netconf-monitoring.yang? Is it because the existing > monitoring data model is not detailed enough? Or is it because it says > 'netconf' in the name and thus people feel it is not applicable? > > Do you think we should work on rfc6022bis instead? I would be willing to do that. Many of the RFC YANG objects came from yuma modules, but I think I was co-chair then (and IMO chairs should never be authors on documents in their own WG). We have more extensions for submodules, RESTCONF, and conformance now. Maybe other vendors do as well. I was going to stay quiet on all the duplication, but now that you bring it up, an updated ietf-netconf-monitoring will have more value to operators. E.g., I still have not figured out how to write RESTCONF text that explains to a reader of RFC 6022 why the session data and counters are "wrong". /js > > Andy > On Sat, Sep 13, 2014 at 11:19:42AM -0700, Andy Bierman wrote: > > Hi, > > > > Martin suggested moving the RESTCONF API data to a real YANG module. > > I have been trying to figure out how that would work. Here is the first > > draft: > > (It includes the new capability URI leaf-list we agreed to add) > > > > OLD: > > > > ietf-restconf.yang > > Abstract module (defined in a grouping) because read-only nodes > contain a > > writable data root > > and not intended for NETCONF advertisement) > > > > +--rw restconf > > +--rw data > > +--rw modules > > | +--rw module* [name revision] > > | +--rw name yang:yang-identifier > > | +--rw revision union > > | +--rw schema? empty > > | +--rw namespace inet:uri > > | +--rw feature* yang:yang-identifier > > | +--rw deviation* yang:yang-identifier > > | +--rw submodule* [name revision] > > | +--rw name yang:yang-identifier > > | +--rw revision union > > | +--rw schema? empty > > +--rw operations > > +--rw streams > > +--rw stream* [name] > > +--rw name string > > +--rw description? string > > +--rw replay-support? boolean > > +--rw replay-log-creation-time? yang:date-and-time > > +--rw events? empty > > > > NEW: > > > > ietf-restconf-api.yang > > Abstract module (defined in a grouping) because read-only nodes > contain a > > writable data root > > and not intended for NETCONF advertisement) > > > > +--rw restconf > > +--rw data > > +--rw operations > > > > ietf-restconf-state.yang > > (Almost) normal YANG module that is populated under /restconf/data > > > > +--ro ietf-restconf-state > > + ro capabilities > > | +-ro capability* > > +--ro modules > > | +--ro module* [name revision] > > | +--ro name yang:yang-identifier > > | +--ro revision union > > | +--ro schema? empty > > | +--ro namespace inet:uri > > | +--ro feature* yang:yang-identifier > > | +--ro deviation* yang:yang-identifier > > | +--ro submodule* [name revision] > > | +--ro name yang:yang-identifier > > | +--ro revision union > > | +--ro schema? empty [1] > > +--ro streams > > +--ro stream* [name] > > +--ro name string > > +--ro description? string > > +--ro replay-support? boolean > > +--ro replay-log-creation-time? yang:date-and-time > > +--ro events? empty [2] > > > > [1] This is the node that magically sends plain YANG application/yang. > > In NETCONF it is just an empty leaf, but in RESTCONF > > it needs to be flagged somehow. It looks like application/yang.data in > the > > schema. > > > > [2] This is the node that magically sends SSE text/event-stream data > until > > the client > > drops the connection. In NETCONF it is just an empty leaf, but in > RESTCONF > > it needs to be flagged somehow. It looks like application/yang.data in > the > > schema. > > > > (Notice how the name ietf-restconf.yang is now reserved for a > configuration > > module > > for RESTCONF when we are ready for that?). > > > > YANG extension proposal for RESTCONF: > > This extension could be used in the [1] and [2] cases above to help tools > > automate the processing. > > > > extension media-type { > > argument media-type; > > description > > "Identifies the media type associated with a YANG data node. > > Ignored unless defined as a sub-statement within a > data-def-stmt. > > If this extension is not present, then the default is the > media > > type associated > > with the parent data-def-stmt. If there is no parent node > then > > the > > media type is 'application/yang.data'."; > > } > > > > > > > > Andy > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a1139304e949aaa0503095029 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 14, 2014 at 4:51 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

can someone give a high-level overview why this is all needed given
that we have ietf-netconf-monitoring.yang? Is it because the existing
monitoring data model is not detailed enough? Or is it because it says
'netconf' in the name and thus people feel it is not applicable?

Do you think we should work on rfc6022= bis instead?
I would be willing to do that. =A0Many of the RFC YA= NG objects came from yuma modules,
but I think I was co-chair the= n (and IMO chairs should never be authors on documents
in their o= wn WG).

We have more extensions for submodules, RE= STCONF, and conformance now.
Maybe other vendors do as well.

I was going to stay quiet on all the duplication, but = now that you bring it up,
an updated ietf-netconf-monitoring will= have more value to operators.
E.g., I still have not figured out= how to write RESTCONF text that explains
to a reader of RFC 6022= why the session data and counters are "wrong".


/js


Andy
=A0
On Sat, Sep 13, 2014 at 11:19:42AM -0700, Andy Bierman wrote:
> Hi,
>
> Martin suggested moving the RESTCONF API data to a real YANG module. > I have been trying to figure out how that would work. Here is the firs= t
> draft:
> (It includes the new capability URI leaf-list we agreed to add)
>
> OLD:
>
>=A0 =A0ietf-restconf.yang
>=A0 =A0Abstract module (defined in a grouping) because read-only nodes = contain a
> writable data root
>=A0 =A0and not intended for NETCONF advertisement)
>
>=A0 =A0 =A0 =A0+--rw restconf
>=A0 =A0 =A0 =A0 =A0 +--rw data
>=A0 =A0 =A0 =A0 =A0 +--rw modules
>=A0 =A0 =A0 =A0 =A0 |=A0 +--rw module* [name revision]
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw name=A0 =A0 =A0 =A0 =A0yang:yang-= identifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw revision=A0 =A0 =A0union
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw schema?=A0 =A0 =A0 empty
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw namespace=A0 =A0 inet:uri
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw feature*=A0 =A0 =A0yang:yang-iden= tifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw deviation*=A0 =A0yang:yang-identi= fier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--rw submodule* [name revision]
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--rw name=A0 =A0 =A0 =A0 yang:yan= g-identifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--rw revision=A0 =A0 union
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--rw schema?=A0 =A0 =A0empty
>=A0 =A0 =A0 =A0 =A0 +--rw operations
>=A0 =A0 =A0 =A0 =A0 +--rw streams
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw stream* [name]
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw name=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw description?=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw replay-support?=A0 =A0 =A0 =A0 = =A0 =A0 =A0boolean
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw replay-log-creation-time?=A0 =A0y= ang:date-and-time
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--rw events?=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0empty
>
> NEW:
>
>=A0 ietf-restconf-api.yang
>=A0 =A0Abstract module (defined in a grouping) because read-only nodes = contain a
> writable data root
>=A0 =A0and not intended for NETCONF advertisement)
>
>=A0 =A0 =A0 =A0+--rw restconf
>=A0 =A0 =A0 =A0 =A0 +--rw data
>=A0 =A0 =A0 =A0 =A0 +--rw operations
>
> ietf-restconf-state.yang
>=A0 =A0 (Almost) normal YANG module that is populated under /restconf/d= ata
>
>=A0 =A0 =A0 =A0+--ro ietf-restconf-state
>=A0 =A0 =A0 =A0 =A0+ ro capabilities
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0+-ro capability*
>=A0 =A0 =A0 =A0 =A0+--ro modules
>=A0 =A0 =A0 =A0 =A0 |=A0 +--ro module* [name revision]
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro name=A0 =A0 =A0 =A0 =A0yang:yang-= identifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro revision=A0 =A0 =A0union
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro schema?=A0 =A0 =A0 empty
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro namespace=A0 =A0 inet:uri
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro feature*=A0 =A0 =A0yang:yang-iden= tifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro deviation*=A0 =A0yang:yang-identi= fier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0+--ro submodule* [name revision]
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro name=A0 =A0 =A0 =A0 yang:yan= g-identifier
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro revision=A0 =A0 union
>=A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro schema?=A0 =A0 =A0empty=A0 = =A0 =A0[1]
>=A0 =A0 =A0 =A0 =A0 +--ro streams
>=A0 =A0 =A0 =A0 =A0 =A0 =A0+--ro stream* [name]
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro name=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro description?=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 string
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro replay-support?=A0 =A0 =A0 =A0 = =A0 =A0 =A0boolean
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro replay-log-creation-time?=A0 =A0y= ang:date-and-time
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--ro events?=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0empty=A0 =A0[2]
>
> [1]=A0 This is the node that magically sends plain YANG=A0 application= /yang.
> In NETCONF it is just an empty leaf, but in RESTCONF
> it needs to be flagged somehow. It looks like application/yang.data in= the
> schema.
>
> [2]=A0 This is the node that magically sends SSE text/event-stream dat= a until
> the client
> drops the connection.=A0 In NETCONF it is just an empty leaf, but in R= ESTCONF
> it needs to be flagged somehow. It looks like application/yang.data in= the
> schema.
>
> (Notice how the name ietf-restconf.yang is now reserved for a configur= ation
> module
> for RESTCONF when we are ready for that?).
>
> YANG extension proposal for RESTCONF:
> This extension could be used in the [1] and [2] cases above to help to= ols
> automate the processing.
>
>=A0 =A0 extension media-type {
>=A0 =A0 =A0 =A0 argument media-type;
>=A0 =A0 =A0 =A0 description
>=A0 =A0 =A0 =A0 =A0 =A0"Identifies the media type associated with = a YANG data node.
>=A0 =A0 =A0 =A0 =A0 =A0 Ignored unless defined as a sub-statement withi= n a data-def-stmt.
>=A0 =A0 =A0 =A0 =A0 =A0 If this extension is not present, then the defa= ult is the media
> type associated
>=A0 =A0 =A0 =A0 =A0 =A0 with the parent data-def-stmt.=A0 If there is n= o parent node then
> the
>=A0 =A0 =A0 =A0 =A0 =A0 media type is 'application/yang.data'.&= quot;;
>=A0 =A0 =A0 }
>
>
>
> Andy

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


--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a1139304e949aaa0503095029-- From nobody Sun Sep 14 09:56:08 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44FA1A00CF for ; Sun, 14 Sep 2014 09:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqGngQnE8SFQ for ; Sun, 14 Sep 2014 09:56:04 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9530B1A00C2 for ; Sun, 14 Sep 2014 09:56:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 57E2E10F4; Sun, 14 Sep 2014 18:56:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NQx2NnpsrrcF; Sun, 14 Sep 2014 18:55:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 14 Sep 2014 18:56:02 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB37320037; Sun, 14 Sep 2014 18:56:02 +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 PiAudSNnBP80; Sun, 14 Sep 2014 18:56:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3617920035; Sun, 14 Sep 2014 18:56:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2A6312E64F3C; Sun, 14 Sep 2014 18:55:59 +0200 (CEST) Date: Sun, 14 Sep 2014 18:55:59 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140914165559.GA10855@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: <20140914115152.GA10359@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qNuszKhWV6f8TVzix6o-BEmc5nM Cc: Netconf Subject: Re: [Netconf] RESTCONF YANG module changes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 16:56:07 -0000 On Sun, Sep 14, 2014 at 09:50:24AM -0700, Andy Bierman wrote: > On Sun, Sep 14, 2014 at 4:51 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Hi, > > > > can someone give a high-level overview why this is all needed given > > that we have ietf-netconf-monitoring.yang? Is it because the existing > > monitoring data model is not detailed enough? Or is it because it says > > 'netconf' in the name and thus people feel it is not applicable? > > > > > Do you think we should work on rfc6022bis instead? > I would be willing to do that. Many of the RFC YANG objects came from yuma > modules, > but I think I was co-chair then (and IMO chairs should never be authors on > documents > in their own WG). > > We have more extensions for submodules, RESTCONF, and conformance now. > Maybe other vendors do as well. > > I was going to stay quiet on all the duplication, but now that you bring it > up, > an updated ietf-netconf-monitoring will have more value to operators. > E.g., I still have not figured out how to write RESTCONF text that explains > to a reader of RFC 6022 why the session data and counters are "wrong". > I would prefer if things remain consistent as much as possible. While there might be some differences, we should try to minimize this. Things like the module list should really be the same. I would find it strange if one protocol interfaces provides more detail than the other. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Sep 14 10:17:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD481A00D8 for ; Sun, 14 Sep 2014 10:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVlxpGXK-Pxs for ; Sun, 14 Sep 2014 10:17:27 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8381A00D7 for ; Sun, 14 Sep 2014 10:17:26 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id i17so2992736qcy.10 for ; Sun, 14 Sep 2014 10:17:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=LtnFVmlfk5YwRBH0553kIRRiNPC6vQU9RCVQgcnHeIc=; b=DFFWXkGu/IlTw6oHIgW43XEBh5qcyAJulgCU8M73WX3JFj07odMEV92yrIZnyk/6RK 8tmdKujjQ8GoMkd8zG5iSZcRbR3EqVQn7KOAHKpL8iiPcSqy18DKLFXHJF+I/lPhUvVo 3FwPNnLoa5vUflLkQsO75tJDjn2SAvXCPYoyY+7Oq5xw3iAiB8pmRtsmTNyKiBTijIxy VJiWgb5O+v/69BcecWRelxe+LTH1D2MicHvYbLEGJZQZJe2pTw8Fl33YBuc0tVrOgdg6 Aupp08P2YFOu9e5FBNCjXEh6cGjJ4VzjsKVYbJDhilrcHslJZiTh+obu+36iuLe4odDs 88yQ== X-Gm-Message-State: ALoCoQk44HmRhSKf4inV6oEDh0Sz3JqPnraGlfTGrqUp7Q8qmMxwVi28RUrv1zUtLZJ9LDOVv6GZ MIME-Version: 1.0 X-Received: by 10.224.60.129 with SMTP id p1mr2682598qah.99.1410715046123; Sun, 14 Sep 2014 10:17:26 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Sun, 14 Sep 2014 10:17:26 -0700 (PDT) In-Reply-To: <20140914165559.GA10855@elstar.local> References: <20140914115152.GA10359@elstar.local> <20140914165559.GA10855@elstar.local> Date: Sun, 14 Sep 2014 10:17:26 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=001a11c3d8d4343800050309b1d2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1WSZrMXU1_jMGiUzyE6SVq6DczI Subject: Re: [Netconf] RESTCONF YANG module changes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 17:17:29 -0000 --001a11c3d8d4343800050309b1d2 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 14, 2014 at 9:55 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Sep 14, 2014 at 09:50:24AM -0700, Andy Bierman wrote: > > On Sun, Sep 14, 2014 at 4:51 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > Hi, > > > > > > can someone give a high-level overview why this is all needed given > > > that we have ietf-netconf-monitoring.yang? Is it because the existing > > > monitoring data model is not detailed enough? Or is it because it says > > > 'netconf' in the name and thus people feel it is not applicable? > > > > > > > > Do you think we should work on rfc6022bis instead? > > I would be willing to do that. Many of the RFC YANG objects came from > yuma > > modules, > > but I think I was co-chair then (and IMO chairs should never be authors > on > > documents > > in their own WG). > > > > We have more extensions for submodules, RESTCONF, and conformance now. > > Maybe other vendors do as well. > > > > I was going to stay quiet on all the duplication, but now that you bring > it > > up, > > an updated ietf-netconf-monitoring will have more value to operators. > > E.g., I still have not figured out how to write RESTCONF text that > explains > > to a reader of RFC 6022 why the session data and counters are "wrong". > > > > I would prefer if things remain consistent as much as possible. While > there might be some differences, we should try to minimize this. Things > like the module list should really be the same. I would find it > strange if one protocol interfaces provides more detail than the other. > The ietf-restconf version of the module list has features, deviations, and a submodule list, that are not in 6022. I completely agree that the device should have 1 YANG library with the same revision, features enabled, deviations applied, and same submodules. Service-level conformance for should describe the APIs constructed from these building blocks in the YANG library. Not all YANG modules apply to all protocols -- e.g. , or how about ietf-netconf? Many operations are session-specific and do not apply to RESTCONF. I think an identityref leaf-list can be used in each module entry to identify the protocols that apply. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c3d8d4343800050309b1d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 14, 2014 at 9:55 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Sep 14, 2014 at 09:50:24AM -0700, Andy Bierm= an wrote:
> On Sun, Sep 14, 2014 at 4:51 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > Hi,
> >
> > can someone give a high-level overview why this is all needed giv= en
> > that we have ietf-netconf-monitoring.yang? Is it because the exis= ting
> > monitoring data model is not detailed enough? Or is it because it= says
> > 'netconf' in the name and thus people feel it is not appl= icable?
> >
> >
> Do you think we should work on rfc6022bis instead?
> I would be willing to do that.=A0 Many of the RFC YANG objects came fr= om yuma
> modules,
> but I think I was co-chair then (and IMO chairs should never be author= s on
> documents
> in their own WG).
>
> We have more extensions for submodules, RESTCONF, and conformance now.=
> Maybe other vendors do as well.
>
> I was going to stay quiet on all the duplication, but now that you bri= ng it
> up,
> an updated ietf-netconf-monitoring will have more value to operators.<= br> > E.g., I still have not figured out how to write RESTCONF text that exp= lains
> to a reader of RFC 6022 why the session data and counters are "wr= ong".
>

I would prefer if things remain consistent as much as possible. While
there might be some differences, we should try to minimize this. Things
like the module list should really be the same. I would find it
strange if one protocol interfaces provides more detail than the other.
=


The ietf-restconf version o= f the module list has features, deviations, and a
submodule list,= that are not in 6022.

I completely agree that the= device should have 1 YANG library with the
same revision, featur= es enabled, deviations applied, and same submodules.
Service-leve= l conformance for should describe the APIs constructed from
these= building blocks in the YANG library.

Not all YANG= modules apply to all protocols -- e.g. <partial-lock>,
or = how about ietf-netconf? =A0Many operations are session-specific
a= nd do not apply to RESTCONF. =A0I think an identityref leaf-list can
<= div>be used in each module entry to identify the protocols that apply.






/js

Andy
=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a11c3d8d4343800050309b1d2-- From nobody Mon Sep 15 05:03:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C509B1A212D for ; Mon, 15 Sep 2014 05:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uq4EJk_IdYT for ; Mon, 15 Sep 2014 05:03:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 79CAB1A0B04 for ; Mon, 15 Sep 2014 05:03:42 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id E61011280972; Mon, 15 Sep 2014 14:03:40 +0200 (CEST) Date: Mon, 15 Sep 2014 14:03:40 +0200 (CEST) Message-Id: <20140915.140340.874027086794229388.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140914165559.GA10855@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/e7AxIyweQ_YarQMCwrON0Lis94I Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF YANG module changes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 12:03:44 -0000 Andy Bierman wrote: > On Sun, Sep 14, 2014 at 9:55 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Sun, Sep 14, 2014 at 09:50:24AM -0700, Andy Bierman wrote: > > > On Sun, Sep 14, 2014 at 4:51 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > Hi, > > > > > > > > can someone give a high-level overview why this is all needed given > > > > that we have ietf-netconf-monitoring.yang? Is it because the existing > > > > monitoring data model is not detailed enough? Or is it because it says > > > > 'netconf' in the name and thus people feel it is not applicable? > > > > > > > > > > > Do you think we should work on rfc6022bis instead? > > > I would be willing to do that. Many of the RFC YANG objects came from > > yuma > > > modules, > > > but I think I was co-chair then (and IMO chairs should never be authors > > on > > > documents > > > in their own WG). > > > > > > We have more extensions for submodules, RESTCONF, and conformance now. > > > Maybe other vendors do as well. > > > > > > I was going to stay quiet on all the duplication, but now that you bring > > it > > > up, > > > an updated ietf-netconf-monitoring will have more value to operators. > > > E.g., I still have not figured out how to write RESTCONF text that > > explains > > > to a reader of RFC 6022 why the session data and counters are "wrong". > > > > > > > I would prefer if things remain consistent as much as possible. While > > there might be some differences, we should try to minimize this. Things > > like the module list should really be the same. I would find it > > strange if one protocol interfaces provides more detail than the other. > > > > > The ietf-restconf version of the module list has features, deviations, and a > submodule list, that are not in 6022. Also, there is the 'streams' info in ietf-restconf. For NETCONF, this is still defined in XSD in RFC 5277. It would be good to fix that as well. /martin From nobody Mon Sep 15 10:36:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B261A8763 for ; Mon, 15 Sep 2014 10:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeDWc7rvpxW3 for ; Mon, 15 Sep 2014 10:36:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C723E1ACD26 for ; Mon, 15 Sep 2014 09:51:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 925A7732; Mon, 15 Sep 2014 18:51:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Zh_SHrIMVeEe; Mon, 15 Sep 2014 18:51:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Sep 2014 18:51:17 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0376120036; Mon, 15 Sep 2014 18:51:17 +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 WyJOjhlql-jd; Mon, 15 Sep 2014 18:51:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27EEC20035; Mon, 15 Sep 2014 18:51:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0A4792E65856; Mon, 15 Sep 2014 18:51:14 +0200 (CEST) Date: Mon, 15 Sep 2014 18:51:14 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org, arne.oslebo@uninett.no Message-ID: <20140915165114.GA13011@elstar.local> Mail-Followup-To: netconf@ietf.org, arne.oslebo@uninett.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/EMWkgxUoBg3fXaHtAYkk9s8FEos Subject: [Netconf] lmap restconf proposal (push vs. pull) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:36:26 -0000 Hi, I am sitting in the LMAP interim meeting and there is an I-D proposing to use RESTCONF, but it kind of changes the roles of the RESTCONF client and server. draft-oslebo-lmap-control-yang-00.txt My traditional understanding of RESTCONF is that it more or less follows NETCONF in the sense that the to be configured device runs a RESTCONF server and the RESTCONF client pushes config to the RESTCONF server on the device. The I-D mentioned above uses a pull model where the device to be configured runs a RESTCONF client getting its configuration from a RESTCONF server. The RESTCONF server in this case acts as a configuration server providing the configuration to a number of clients, each one pulling it via GETs as needed. The motivation for all this are devices sitting behind NATs and so this overlaps perhaps also with NETCONF configlets. Anyway, I wanted to start a thread here in order to hear what RESTCONF experts thing about this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 15 11:41:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5E51A8733 for ; Mon, 15 Sep 2014 11:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmr9vzUwScra for ; Mon, 15 Sep 2014 11:41:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C301A702D for ; Mon, 15 Sep 2014 11:17:00 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Mon, 15 Sep 2014 18:16:58 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.179]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.173]) with mapi id 15.00.1029.000; Mon, 15 Sep 2014 18:16:57 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" , "arne.oslebo@uninett.no" Thread-Topic: [Netconf] lmap restconf proposal (push vs. pull) Thread-Index: AQHP0QuYkCNByNfiOkKJixk4t5k5L5wCPVEA Date: Mon, 15 Sep 2014 18:16:57 +0000 Message-ID: References: <20140915165114.GA13011@elstar.local> In-Reply-To: <20140915165114.GA13011@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174003)(377454003)(24454002)(51704005)(199003)(189002)(86362001)(83072002)(85852003)(92726001)(92566001)(2201001)(107886001)(107046002)(106116001)(106356001)(74662001)(74502001)(31966008)(21056001)(101416001)(85306004)(77096002)(66066001)(97736003)(80022001)(90102001)(2501002)(81542001)(99396002)(76176999)(50986999)(54356999)(105586002)(95666004)(99286002)(81342001)(87936001)(2656002)(83322001)(19580405001)(19580395003)(20776003)(64706001)(83506001)(15202345003)(15975445006)(77982001)(79102001)(36756003)(4396001)(76482001)(46102001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/llqJruz8nQRs3HLm4AY3kZ-z4uU Subject: Re: [Netconf] lmap restconf proposal (push vs. pull) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 18:41:49 -0000 To support devices behind NATs with RESTCONF, we should use the TLS call-home strategy. That is, the device initiates a TCP connection to the northbound system, which in turn starts HTTPS. Note that the TCP/TLS connection can be long-lived while the HTTP protocol is start/stopped many times. Using call-home this way is preferred for the same reasons why its preferred for SSH and TLS transports for NETCONF - because it preserves the directionality of the authentication mechanisms. I know RESTCONF call-home came up and was shot down in Toronto, but I think that was done erroneously and the decision re-examined. Kent On 9/15/14, 12:51 PM, "Juergen Schoenwaelder" wrote: >Hi, > >I am sitting in the LMAP interim meeting and there is an I-D proposing >to use RESTCONF, but it kind of changes the roles of the RESTCONF >client and server. > > draft-oslebo-lmap-control-yang-00.txt > >My traditional understanding of RESTCONF is that it more or less >follows NETCONF in the sense that the to be configured device runs a >RESTCONF server and the RESTCONF client pushes config to the RESTCONF >server on the device. The I-D mentioned above uses a pull model where >the device to be configured runs a RESTCONF client getting its >configuration from a RESTCONF server. The RESTCONF server in this case >acts as a configuration server providing the configuration to a number >of clients, each one pulling it via GETs as needed. > >The motivation for all this are devices sitting behind NATs and so >this overlaps perhaps also with NETCONF configlets. Anyway, I wanted >to start a thread here in order to hear what RESTCONF experts thing >about this. > >/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 nobody Mon Sep 15 12:14:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64251A0026 for ; Mon, 15 Sep 2014 12:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDDS8TQBApIa for ; Mon, 15 Sep 2014 12:14:10 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1025F1A03A8 for ; Mon, 15 Sep 2014 12:05:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B0AC7C245; Mon, 15 Sep 2014 15:05:02 -0400 (EDT) Date: Mon, 15 Sep 2014 15:05:02 -0400 From: Jeffrey Haas To: Kent Watsen Message-ID: <20140915190502.GA28454@pfrc> References: <20140915165114.GA13011@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zz4Bn13tmuXvEk8ob-6cji5V57E Cc: "netconf@ietf.org" Subject: Re: [Netconf] lmap restconf proposal (push vs. pull) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:14:13 -0000 On Mon, Sep 15, 2014 at 06:16:57PM +0000, Kent Watsen wrote: > I know RESTCONF call-home came up and was shot down in Toronto, but I > think that was done erroneously and the decision re-examined. +1. -- Jeff From nobody Mon Sep 15 12:48:43 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4D31A6F51 for ; Mon, 15 Sep 2014 12:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ6sbthhC8op for ; Mon, 15 Sep 2014 12:48:39 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54F31A6F6D for ; Mon, 15 Sep 2014 12:48:39 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XTcGI-0006Pm-CI for netconf@ietf.org; Mon, 15 Sep 2014 21:48:35 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-6.fritz.box) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XTcGI-0002Cc-4i for netconf@ietf.org; Mon, 15 Sep 2014 21:48:34 +0200 Message-ID: <54174291.2090605@bwijnen.net> Date: Mon, 15 Sep 2014 21:48:33 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: netconf References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=utf-8; 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: 86ab03e524994f79ca2c75a176445dd4f181a75ac656435a4ecb89bc8006b48f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NtRJB7L1pEMrS9L_kQSMh6UAEps Subject: [Netconf] Fwd: [www.ietf.org/rt #68474] minutes/notes/virtual-bluesheet of our NETCONF Virtual Interim Meeting on 8 Sept 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:48:41 -0000 These can now be found at: http://www.ietf.org/proceedings/interim/2014/09/08/netconf/proceedings.html Bert From nobody Mon Sep 15 14:21:32 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EABE1A6F6B for ; Mon, 15 Sep 2014 14:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW-zV-lM4QFs for ; Mon, 15 Sep 2014 14:21:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5483C1A8766 for ; Mon, 15 Sep 2014 14:21:27 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB489.namprd05.prod.outlook.com (10.141.71.144) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Mon, 15 Sep 2014 21:21:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Mon, 15 Sep 2014 21:21:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.179]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.4]) with mapi id 15.00.1029.000; Mon, 15 Sep 2014 21:21:23 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: remove psk-maps from netconf-server model? Thread-Index: AQHP0SsAbpK+8GvDzUGtNrtfZrrx2g== Date: Mon, 15 Sep 2014 21:21:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(85306004)(54356999)(21056001)(74662001)(4396001)(92726001)(85852003)(83072002)(97736003)(50986999)(77982001)(99396002)(86362001)(74502001)(79102001)(2656002)(87936001)(80022001)(229853001)(46102001)(105586002)(81542001)(77096002)(106116001)(81342001)(66066001)(99286002)(95666004)(106356001)(83506001)(20776003)(36756003)(64706001)(101416001)(83322001)(107046002)(110136001)(90102001)(76482001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <05E10FF457859C4A8D97BC6C85904E9B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hmy-ec64ghSRZT3OcYdpWPe5CIM Cc: netconf Subject: [Netconf] remove psk-maps from netconf-server model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:21:29 -0000 Hi Juergen, I recall your saying in Toronto that we could/should remove the "psk-maps" from the netconf-server model, but there isn't anything about it in the minutes. Why aren't psk-maps aren't needed anymore? - do we now assume the client always has a cert and therefore "cert-maps" are all that is needed now? Thanks, Kent From nobody Mon Sep 15 14:46:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BD71A87A3 for ; Mon, 15 Sep 2014 14:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.553 X-Spam-Level: X-Spam-Status: No, score=-15.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK0hoHFAMpRS for ; Mon, 15 Sep 2014 14:46:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86921A875A for ; Mon, 15 Sep 2014 14:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=783; q=dns/txt; s=iport; t=1410817582; x=1412027182; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=VQMMFC8pufh1EXiQBrV+BGqMk/mrUxJQGhdPph70We4=; b=K59U+/WDuynx7ag3xhoWMnADKxW57as3KDD4hfGLIrmnDEEKEUnAGiP1 W80ZOet+RKrNgeB5i8BwrKzfDwyOZHBE2WJTZcY2XY74V5yXiOopDhYNN gogguHR7AU+MzzeP7LLRMhGbJG76KjUBgazSfxvhFuuzIslS92lvt8zO4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADddF1StJV2Z/2dsb2JhbABggw1TVwTKZwqGelQBgRsWeIQEAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTAGDQYCAQGIOg27MwETBI9UFoQ1AQSLP5FJh0eNeIN+TIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,530,1406592000"; d="scan'208";a="78186992" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 15 Sep 2014 21:46:22 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8FLkMXQ007552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Sep 2014 21:46:22 GMT Received: from [10.21.71.125] (10.21.71.125) by xhc-rcd-x09.cisco.com (173.37.183.83) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Sep 2014 16:46:21 -0500 Message-ID: <54175E2D.2090209@cisco.com> Date: Mon, 15 Sep 2014 14:46:21 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: References: <20140915165114.GA13011@elstar.local> <20140915190502.GA28454@pfrc> In-Reply-To: <20140915190502.GA28454@pfrc> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.21.71.125] Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UPbRewrvLeCDeqWCiCaGfCnVXUo Subject: Re: [Netconf] lmap restconf proposal (push vs. pull) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:46:24 -0000 +1. and FWIW a feature in current design in Opendaylight. In our current thinking device uses one of the many NAT traversal techniques available to procure a stable public ip:port. Then device conveys the IP:port in the RESTconf call home to the controller. Controller turns around and connect to server (used to be client) in that IP:port. thanks, On 9/15/14 12:05 PM, Jeffrey Haas wrote: > On Mon, Sep 15, 2014 at 06:16:57PM +0000, Kent Watsen wrote: >> I know RESTCONF call-home came up and was shot down in Toronto, but I >> think that was done erroneously and the decision re-examined. > +1. > > -- Jeff > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Sep 15 15:44:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10071A87D8 for ; Mon, 15 Sep 2014 15:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peVY3BQNuIR7 for ; Mon, 15 Sep 2014 15:44:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0783.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::783]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABAD1A8785 for ; Mon, 15 Sep 2014 15:44:41 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB316.namprd05.prod.outlook.com (10.141.69.142) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Mon, 15 Sep 2014 22:44:18 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Mon, 15 Sep 2014 22:44:16 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.179]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.185]) with mapi id 15.00.1029.000; Mon, 15 Sep 2014 22:44:16 +0000 From: Kent Watsen To: Reinaldo Penno , "netconf@ietf.org" Thread-Topic: [Netconf] lmap restconf proposal (push vs. pull) Thread-Index: AQHP0QuYkCNByNfiOkKJixk4t5k5L5wCPVEAgABQfwCAAC0SgP//zR+A Date: Mon, 15 Sep 2014 22:44:16 +0000 Message-ID: References: <20140915165114.GA13011@elstar.local> <20140915190502.GA28454@pfrc> <54175E2D.2090209@cisco.com> In-Reply-To: <54175E2D.2090209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 03355EE97E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(189002)(51704005)(479174003)(377454003)(24454002)(199003)(164054003)(93886004)(85306004)(54356999)(92726001)(92566001)(74662001)(21056001)(4396001)(79102001)(85852003)(97736003)(83072002)(50986999)(77982001)(99396002)(86362001)(80022001)(74502001)(76176999)(31966008)(2656002)(87936001)(46102001)(105586002)(81542001)(77096002)(106116001)(81342001)(66066001)(99286002)(19580395003)(95666004)(83506001)(106356001)(20776003)(36756003)(101416001)(107886001)(83322001)(19580405001)(15975445006)(107046002)(90102001)(76482001)(2501002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <6596D1FB1B591B4AAD131CE6A1D16968@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JuIPe0yqib0jgEyipFR6snZRnC0 Subject: Re: [Netconf] lmap restconf proposal (push vs. pull) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 22:44:42 -0000 Hi Reinaldo, I think you are describing something a bit different, what I might refer to as "knocking". E.g. there are two separate TCP connections, one for the HTTP connection from the NE to the controller (the knock) and another when the controller connects back to the NE. Did I capture your use-case correctly? The call-home that's been discussed for NETCONF differs in that there is only one TCP connection, the one from the NE to the controller, *on top of which* the controller runs whatever protocol is desired *as the client*. That is, for the same TCP connection, the NE would start out as the TCP client, but then switch to become the TLS server and then the HTTP server (as each layer in the protocol stack is initialized). See draft-ietf-netconf-call-home for more details. Admittedly, the current draft is just for NETCONF, but the exact same strategy used for NETCONF TLS-transport could work for RESTCONF, the only difference being that the controller would start HTTP rather than NETCONF. What do you think, would it work for ODL? - is this for the Secure Network BootStrapping project? Thanks, Kent On 9/15/14, 5:46 PM, "Reinaldo Penno" wrote: >+1. > >and FWIW a feature in current design in Opendaylight. > >In our current thinking device uses one of the many NAT traversal >techniques available to procure a stable public ip:port. Then device >conveys the IP:port in the RESTconf call home to the controller. >Controller turns around and connect to server (used to be client) in >that IP:port. > >thanks, > >On 9/15/14 12:05 PM, Jeffrey Haas wrote: >> On Mon, Sep 15, 2014 at 06:16:57PM +0000, Kent Watsen wrote: >>> I know RESTCONF call-home came up and was shot down in Toronto, but I >>> think that was done erroneously and the decision re-examined. >> +1. >> >> -- Jeff >> >> _______________________________________________ >> 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 nobody Mon Sep 15 16:04:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860111A8864 for ; Mon, 15 Sep 2014 16:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.553 X-Spam-Level: X-Spam-Status: No, score=-15.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O34AIL2R1lko for ; Mon, 15 Sep 2014 16:04:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FD41A8868 for ; Mon, 15 Sep 2014 16:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2734; q=dns/txt; s=iport; t=1410822261; x=1412031861; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=W1fAbrfivA7cz2vJ4Ix8ujsFFEFrw+OY/VZl5haBP8A=; b=V+y8b4HJd/O4br72Q6WMX9VIchyOtSoHq7FETYMR3zF+7NztV+w1qCaN Ud1wc9304CPit//iV8KxtsAhpmGyG17UCQPky5VykrrQEIk6HNn16Uylb Z2U+7h0eHARqBTDKxvjRnSkYbld3KeFdDydol8b6/OecdhpWpuNZuH7u8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFADNwF1StJA2D/2dsb2JhbABggw1TVwTKaQqGelQBgRsWeIQDAQEBAwEBAQE1NgoRCw4KCRYPCQMCAQIBFTAGAQwGAgEBF4gbCA27HwETBI9UhEsBBIs/kUmHR414g35MgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,531,1406592000"; d="scan'208";a="78206024" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 15 Sep 2014 23:04:09 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8FN49o5026444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Sep 2014 23:04:09 GMT Received: from [10.21.71.125] (10.21.71.125) by xhc-rcd-x09.cisco.com (173.37.183.83) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 15 Sep 2014 18:04:08 -0500 Message-ID: <54177066.7040902@cisco.com> Date: Mon, 15 Sep 2014 16:04:06 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" References: <20140915165114.GA13011@elstar.local> <20140915190502.GA28454@pfrc> <54175E2D.2090209@cisco.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.21.71.125] Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6iL4FnV15YJwvLDQhVF3n_Qi6FQ Subject: Re: [Netconf] lmap restconf proposal (push vs. pull) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 23:04:26 -0000 On 9/15/14 3:44 PM, Kent Watsen wrote: > Hi Reinaldo, > > I think you are describing something a bit different, what I might refer > to as "knocking". E.g. there are two separate TCP connections, one for the > HTTP connection from the NE to the controller (the knock) and another when > the controller connects back to the NE. Did I capture your use-case > correctly? [RP] Yes. > > The call-home that's been discussed for NETCONF differs in that there is > only one TCP connection, the one from the NE to the controller, *on top of > which* the controller runs whatever protocol is desired *as the client*. > That is, for the same TCP connection, the NE would start out as the TCP > client, but then switch to become the TLS server and then the HTTP server > (as each layer in the protocol stack is initialized). See > draft-ietf-netconf-call-home for more details. [RP] Yes, I understand your proposal and we thought about using Websockets for that purpose. But we want to provide a call home using core HTTP 1.1 techniques such that almost every device out there that uses a Java/Python HTTP library (sensors, small appliances, etc) can make use of it right off the bat. There are trade-offs amongst all possible solutions and would like to keep the discussion going. > > Admittedly, the current draft is just for NETCONF, but the exact same > strategy used for NETCONF TLS-transport could work for RESTCONF, the only > difference being that the controller would start HTTP rather than NETCONF. > > What do you think, would it work for ODL? - is this for the Secure Network > BootStrapping project? > > Thanks, > Kent > > > > On 9/15/14, 5:46 PM, "Reinaldo Penno" wrote: > >> +1. >> >> and FWIW a feature in current design in Opendaylight. >> >> In our current thinking device uses one of the many NAT traversal >> techniques available to procure a stable public ip:port. Then device >> conveys the IP:port in the RESTconf call home to the controller. >> Controller turns around and connect to server (used to be client) in >> that IP:port. >> >> thanks, >> >> On 9/15/14 12:05 PM, Jeffrey Haas wrote: >>> On Mon, Sep 15, 2014 at 06:16:57PM +0000, Kent Watsen wrote: >>>> I know RESTCONF call-home came up and was shot down in Toronto, but I >>>> think that was done erroneously and the decision re-examined. >>> +1. >>> >>> -- Jeff >>> >>> _______________________________________________ >>> 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 nobody Tue Sep 16 03:16:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9ED1A048D for ; Tue, 16 Sep 2014 03:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnqmMKutM3lJ for ; Tue, 16 Sep 2014 03:16:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70B91A027C for ; Tue, 16 Sep 2014 03:16:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 80E1487A; Tue, 16 Sep 2014 12:16:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hf5vzIPxctk8; Tue, 16 Sep 2014 12:16:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 16 Sep 2014 12:16:33 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EEE1C20036; Tue, 16 Sep 2014 12:16:32 +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 DKxiD_LA-YnG; Tue, 16 Sep 2014 12:16:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 230F820035; Tue, 16 Sep 2014 12:16:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 666A72E66089; Tue, 16 Sep 2014 12:16:31 +0200 (CEST) Date: Tue, 16 Sep 2014 12:16:30 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140916101630.GD14591@elstar.local> Mail-Followup-To: Kent Watsen , netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0pnWGQWmVYBPjNAHNygeMvyyUQ4 Cc: netconf Subject: Re: [Netconf] remove psk-maps from netconf-server model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 10:16:36 -0000 On Mon, Sep 15, 2014 at 09:21:23PM +0000, Kent Watsen wrote: > > Hi Juergen, > > I recall your saying in Toronto that we could/should remove the "psk-maps" > from the netconf-server model, but there isn't anything about it in the > minutes. Why aren't psk-maps aren't needed anymore? - do we now assume > the client always has a cert and therefore "cert-maps" are all that is > needed now? > I believe PSKs are only useful for very low-end devices that do not afford the complexity that comes with certifications. It seems that NC is likely not implemented on such devices and hence in order to remove complexity, I suggested to remove PSKs from the spec. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Sep 16 05:29:35 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4F1A0426; Tue, 16 Sep 2014 05:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.901 X-Spam-Level: X-Spam-Status: No, score=-99.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wof4B2vAiqF7; Tue, 16 Sep 2014 05:29:31 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07F1A030C; Tue, 16 Sep 2014 05:29:30 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 27A84128586E; Tue, 16 Sep 2014 20:29:13 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 77415CDAEDA; Tue, 16 Sep 2014 20:29:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s8GCTKCJ087200; Tue, 16 Sep 2014 20:29:20 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) To: netconf@ietf.org, netmod@ietf.org MIME-Version: 1.0 X-KeepSent: A00A6FAE:C8E0515A-48257D55:0044412C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Tue, 16 Sep 2014 20:29:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-09-16 20:29:04, Serialize complete at 2014-09-16 20:29:04 Content-Type: multipart/alternative; boundary="=_alternative 0044960948257D55_=" X-MAIL: mse01.zte.com.cn s8GCTKCJ087200 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WY3pGf1UlCeugL7dt0Ki5dqTvM8 Cc: ye.xu1@zte.com.cn, chen.wei3@zte.com.cn, xiao.yuqing@zte.com.cn Subject: [Netconf] =?gb2312?b?16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?gb2312?b?ciBkcmFmdC1mcmFuay1uZXRjb25mLWNvbmZvcm1hbmNlLTAwLnR4dA==?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 12:29:33 -0000 This is a multipart message in MIME format. --=_alternative 0044960948257D55_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQogICBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGZvciBuZXRjb25mIHNj aGVtYSBjb25mb3JtYW5jZSANCmFkdmVydGlzZW1lbnQgbWVjaGFuaXNtLg0KcGxlYXNlIHJldmll dyBpdCBhbmQgZ2l2ZSBtZSBzb21lIGFkdmljZS4gDQoNCnRoYW5rcyENCiAgICAgICAgICAgICAg L2ZyYW5rDQoNCg0KDQotLS0tLSDXqreiyMsgt+uz5TEwMTM2NDkyL3VzZXIvenRlX2x0ZCDKsbzk IDIwMTQtMDktMTYgMjA6MjUgLS0tLS0NCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC009og MjAxNC0wOS0xNiAyMDoyMTozMDoNCg0KPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQo+IDIw MTQtMDktMTYgMjA6MjENCj4gDQo+IMrVvP7Iyw0KPiANCj4gIlh1IFllIiA8eWUueHUxQHp0ZS5j b20uY24+LCAiRnJhbmsgRmVuZyIgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiwNCj4gRnJhbmsg RmVuZyA8ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24+LCBYdSBZZSA8eWUueHUxQHp0ZS5jb20uY24+ LCANCj4gDQo+ILOty80NCj4gDQo+INb3zOINCj4gDQo+IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS0wMC50eHQNCj4gDQo+IA0KPiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS0wMC50 eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBGcmFuayBGZW5nIGFuZCBw b3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6ICAgICAgZHJhZnQt ZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZQ0KPiBSZXZpc2lvbjogICAwMA0KPiBUaXRsZTogICAg ICBUaGUgbWVjaGFuaXNtIHRvIGFkdmVydGlzZSBzY2hlbWEgY29uZm9ybWFuY2Ugb2YgTkVUQ09O Rg0KPiBEb2N1bWVudCBkYXRlOiAgIDIwMTQtMDktMTYNCj4gR3JvdXA6ICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAgIDEyDQo+IFVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1mcmFuay0NCj4gbmV0Y29uZi1jb25m b3JtYW5jZS0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZyYW5rLQ0KPiBuZXRjb25mLWNvbmZvcm1hbmNlLw0KPiBIdG1saXpl ZDogICAgICAgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mcmFuay1uZXRjb25m LWNvbmZvcm1hbmNlLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSB1bmlmaWVkIG1lY2hhbmlzbSB0byBhZHZlcnRpc2Ugc2NoZW1hDQo+ICAg IGNvbmZvcm1hbmNlIG9mIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENP TkYpLg0KPiANCj4gIA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0Kc3VibWlzc2lvbg0KPiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAo YW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFu ZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0 aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBh bnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2Vt aW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVh c2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9u IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwg KGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBh bmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwg YW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3Nl bWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxl YXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 0044960948257D55_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtJIGhhdmUg c3VibWl0dGVkIGEgbmV3DQpkcmFmdCBmb3IgbmV0Y29uZiBzY2hlbWEgY29uZm9ybWFuY2UgYWR2 ZXJ0aXNlbWVudCBtZWNoYW5pc20uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5wbGVhc2UgcmV2aWV3IGl0IGFuZCBnaXZlIG1lIHNvbWUgYWR2aWNlLg0KPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFua3MhPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IC9mcmFuazwvZm9udD4NCjx0YWJsZT4NCjx0 cj4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jODAw MDgwIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tINeqt6LIyyC367PlMTAxMzY0OTIvdXNlci96dGVf bHRkDQrKsbzkIDIwMTQtMDktMTYgMjA6MjUgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg0LTT2iAyMDE0LTA5LTE2IDIwOjIx OjMwOjxicj4NCjxicj4NCiZndDsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE0LTA5LTE2IDIwOjIxPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJnF1b3Q7WHUgWWUmcXVvdDsg Jmx0O3llLnh1MUB6dGUuY29tLmNuJmd0OywgJnF1b3Q7RnJhbmsgRmVuZyZxdW90Ow0KJmx0O2Zl bmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Oyw8YnI+DQomZ3Q7IEZyYW5rIEZlbmcgJmx0O2Zlbmcu Y2hvbmczM0B6dGUuY29tLmNuJmd0OywgWHUgWWUgJmx0O3llLnh1MUB6dGUuY29tLmNuJmd0OywN CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98ziPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mcmFuay1uZXRjb25mLWNvbmZvcm1hbmNlLTAwLnR4 dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZyYW5rLW5ldGNvbmYtY29uZm9ybWFu Y2UtMDAudHh0PGJyPg0KJmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEZy YW5rIEZlbmcgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQomZ3Q7IElFVEYgcmVwb3NpdG9yeS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgTmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1mcmFuay1u ZXRjb25mLWNvbmZvcm1hbmNlPGJyPg0KJmd0OyBSZXZpc2lvbjogJm5ic3A7IDAwPGJyPg0KJmd0 OyBUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgbWVjaGFuaXNtIHRvIGFkdmVydGlzZSBz Y2hlbWEgY29uZm9ybWFuY2UNCm9mIE5FVENPTkY8YnI+DQomZ3Q7IERvY3VtZW50IGRhdGU6ICZu YnNwOyAyMDE0LTA5LTE2PGJyPg0KJmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRp dmlkdWFsIFN1Ym1pc3Npb248YnI+DQomZ3Q7IFBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzEy PGJyPg0KJmd0OyBVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtZnJhbmstIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWZyYW5rLTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxi cj4NCiZndDsgbmV0Y29uZi1jb25mb3JtYW5jZS0wMC50eHQ8YnI+DQomZ3Q7IFN0YXR1czogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZyYW5rLSI+PHR0Pjxmb250IHNpemU9Mj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mcmFuay08L2ZvbnQ+PC90dD48L2E+ PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IG5ldGNvbmYtY29uZm9ybWFuY2UvPGJyPg0KJmd0 OyBIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS0w MCI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mcmFu ay1uZXRjb25mLWNvbmZvcm1hbmNlLTAwPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVuaWZpZWQgbWVjaGFuaXNtIHRv IGFkdmVydGlzZQ0Kc2NoZW1hPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Y29uZm9ybWFuY2Ugb2Yg dGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBQcm90b2NvbCAoTkVUQ09ORikuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCnN1Ym1pc3Npb248YnI+ DQomZ3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBJRVRGIFNlY3JldGFy aWF0PGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9 ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRp c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l ZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJs dWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBh biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlh dGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0044960948257D55_=-- From nobody Tue Sep 16 11:13:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81DC1A87C8 for ; Tue, 16 Sep 2014 11:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orq9sgNoxU2U for ; Tue, 16 Sep 2014 11:13:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0921A8849 for ; Tue, 16 Sep 2014 11:13:29 -0700 (PDT) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB426.namprd05.prod.outlook.com (10.141.74.24) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Tue, 16 Sep 2014 18:13:06 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Tue, 16 Sep 2014 18:13:04 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.179]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) with mapi id 15.00.1029.000; Tue, 16 Sep 2014 18:13:04 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: remove psk-maps from netconf-server model? Thread-Index: AQHP0SsAbpK+8GvDzUGtNrtfZrrx2pwDjDoAgABCF4A= Date: Tue, 16 Sep 2014 18:13:03 +0000 Message-ID: References: <20140916101630.GD14591@elstar.local> In-Reply-To: <20140916101630.GD14591@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(51704005)(189002)(377454003)(164054003)(479174003)(99396002)(54356999)(66066001)(92726001)(83506001)(106116001)(2656002)(50986999)(19580405001)(81542003)(79102003)(81342003)(80022003)(74502003)(99286002)(74662003)(77982003)(85306004)(46102003)(85852003)(92566001)(105586002)(15975445006)(21056001)(19580395003)(106356001)(95666004)(97736003)(4396001)(76482001)(77096002)(15202345003)(90102001)(36756003)(110136001)(87936001)(83072002)(31966008)(107046002)(86362001)(64706001)(76176999)(83322001)(101416001)(20776003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <28772FC9D4EBC34FA33B7EFB939C8E50@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/kzW5SOfpY5RwNybTauGvPs016yU Cc: "netconf@ietf.org" Subject: Re: [Netconf] remove psk-maps from netconf-server model? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 18:13:39 -0000 I wasn't involved when the PSK-maps construct was added originally and don't have enough context to argue either way. Right now PSK is still defined in 5539bis, and thus have to be kept in draft-ietf-netconf-server-model. 5539bis also still has the call-home text in it, so I guess an update is coming, one that could also remove PSKs. I'll update the server-model to match 5539bis whichever way it goes. Thanks, Kent On 9/16/14, 6:16 AM, "Juergen Schoenwaelder" wrote: >On Mon, Sep 15, 2014 at 09:21:23PM +0000, Kent Watsen wrote: >>=20 >> Hi Juergen, >>=20 >> I recall your saying in Toronto that we could/should remove the >>"psk-maps" >> from the netconf-server model, but there isn't anything about it in the >> minutes. Why aren't psk-maps aren't needed anymore? - do we now >>assume >> the client always has a cert and therefore "cert-maps" are all that is >> needed now? >>=20 > >I believe PSKs are only useful for very low-end devices that do not >afford the complexity that comes with certifications. It seems that NC >is likely not implemented on such devices and hence in order to remove >complexity, I suggested to remove PSKs from the spec. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Tue Sep 16 17:00:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3761A03C3; Tue, 16 Sep 2014 17:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1fnJ6VGJNKb; Tue, 16 Sep 2014 17:00:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC20B1A00AE; Tue, 16 Sep 2014 17:00:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140917000007.2634.5523.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 17:00:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PYnBsf_A542jKuG6D3fYAgUcJfQ Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:00:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Server Configuration Model Authors : Kent Watsen Juergen Schoenwaelder Filename : draft-ietf-netconf-server-model-02.txt Pages : 28 Date : 2014-09-16 Abstract: This draft defines a NETCONF server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports it supports, what ports they listen on, whether they support device-initiated connections, and associated parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-server-model-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-server-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 16 17:05:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34451A6F3E for ; Tue, 16 Sep 2014 17:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nouu-sA3J4MW for ; Tue, 16 Sep 2014 17:05:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4461A0685 for ; Tue, 16 Sep 2014 17:05:45 -0700 (PDT) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB505.namprd05.prod.outlook.com (10.141.71.140) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Wed, 17 Sep 2014 00:05:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Wed, 17 Sep 2014 00:05:40 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.179]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) with mapi id 15.00.1029.000; Wed, 17 Sep 2014 00:05:41 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-02.txt Thread-Index: AQHP0gpeQ9va7SF9vkyRAKTR/K5zFJwELxoA Date: Wed, 17 Sep 2014 00:05:40 +0000 Message-ID: References: <20140917000007.2634.5523.idtracker@ietfa.amsl.com> In-Reply-To: <20140917000007.2634.5523.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(24454002)(51704005)(189002)(164054003)(377424004)(479174003)(2501002)(106116001)(79102003)(81542003)(15975445006)(83506001)(81342003)(92726001)(54356999)(97736003)(106356001)(2656002)(66066001)(99396002)(77096002)(19580395003)(105586002)(77982003)(74662003)(85852003)(74502003)(46102003)(85306004)(21056001)(95666004)(92566001)(15202345003)(4396001)(80022003)(76176999)(99286002)(90102001)(110136001)(87936001)(36756003)(83072002)(31966008)(20776003)(86362001)(2351001)(107046002)(101416001)(107886001)(230783001)(50986999)(76482002)(83322001)(64706001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <936EF63D2B947943B53BEFF206EEC163@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/38a3hQJ6JyUwr-Dn0932x9ebfvc Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-server-model-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:05:47 -0000 For next Monday's virtual NETCONF meeting. This update has the following changes: o removed the "one-to-many" construct o removed "address" as a key field o removed "network-manager" terminology o brought TLS client auth back into model o moved open issues to github issues As the last bullet item mentions, please go to https://github.com/netconf-wg/server-model/issues to track current open issues (as well as to see all the closed issues) Thanks, Kent On 9/16/14, 8:00 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Server Configuration Model > Authors : Kent Watsen > Juergen Schoenwaelder > Filename : draft-ietf-netconf-server-model-02.txt > Pages : 28 > Date : 2014-09-16 > >Abstract: > This draft defines a NETCONF server configuration data model. This > data model enables configuration of the NETCONF service itself, > including which transports it supports, what ports they listen on, > whether they support device-initiated connections, and associated > parameters. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-server-model-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-server-model-02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Sep 17 09:31:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF491A0695 for ; Wed, 17 Sep 2014 09:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G42VqcgQj-ej for ; Wed, 17 Sep 2014 09:31:32 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::768]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16131A0675 for ; Wed, 17 Sep 2014 09:31:31 -0700 (PDT) Received: from DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) by DBXPR07MB048.eurprd07.prod.outlook.com (10.242.147.23) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Wed, 17 Sep 2014 16:31:08 +0000 Received: from pc6 (86.184.59.221) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Wed, 17 Sep 2014 16:31:07 +0000 Message-ID: <027a01cfd294$91be6300$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , "Bert Wijnen (IETF)" References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <20140902202401.GC78273@elstar.local> Date: Wed, 17 Sep 2014 17:29:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.59.221] X-ClientProxiedBy: DB4PR03CA0032.eurprd03.prod.outlook.com (25.160.39.170) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; X-Forefront-PRVS: 0337AFFE9A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(199003)(51704005)(377454003)(13464003)(105586002)(106356001)(102836001)(33646002)(44716002)(62236002)(95666004)(23756003)(77156001)(31966008)(50466002)(97736003)(61296003)(107046002)(14496001)(42186005)(104166001)(93886004)(85306004)(77096002)(116806002)(47776003)(20776003)(88136002)(92566001)(92726001)(87976001)(76482002)(89996001)(66066001)(85852003)(83072002)(64706001)(101416001)(76176999)(81686999)(81816999)(99396002)(19580395003)(19580405001)(50986999)(83322001)(4396001)(74502003)(80022003)(81542003)(77982003)(50226001)(62966002)(44736004)(93916002)(86362001)(79102003)(46102003)(81342003)(15975445006)(87286001)(21056001)(15202345003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Yhp4hi_9ULLLYg6b6GRvbWd2WSE Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 16:31:35 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Bert Wijnen (IETF)" Cc: "Netconf" Sent: Tuesday, September 02, 2014 9:24 PM > On Tue, Sep 02, 2014 at 12:23:37PM +0200, Bert Wijnen (IETF) wrote: > > > > Please speak your mind about these options: > > > > a) XML is mandatory > > b) JSON is mandatory > > c) XML and JSON are both mandatory > > d) Both XML and JSON mandatory on client, > > server can implement whatever it chooses. > > Not clear yet how the client would find out, but that would of course > > be something to be worked out if we choose this option > > > > I have neither implemented a server nor a client. That said, I think I > prefer a) because having less options improves interoperability (I am > old school on this). I also note that the JSON encoding is not final > yet and depending on how some of the details are resolved, I may be OK > with d) or not. The question is how much complexity is added to a > client for supporting both XML and JSON. If the JSON mappings requires > that all clients are able to dynamically parse and interpret YANG > models, I am going to be strictly against d). > > Sorry for a complicated answer. It's a complicated question! I go for a), less options, less complexity, better understood at this point in time, warts and all. I am not involved in implementing it. Tom Petch > > /js > > -- > 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 nobody Wed Sep 17 11:22:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5736F1A0ACF; Wed, 17 Sep 2014 11:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.554 X-Spam-Level: X-Spam-Status: No, score=-108.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCKOKov_PS7N; Wed, 17 Sep 2014 11:22:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDE61A0AD7; Wed, 17 Sep 2014 11:22:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 31CA818044F; Wed, 17 Sep 2014 11:21:35 -0700 (PDT) To: andy@yumaworks.com, andy@yumaworks.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140917182135.31CA818044F@rfc-editor.org> Date: Wed, 17 Sep 2014 11:21:35 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nvT4gT9yDTqdQH83y2vaUft-xvk Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Held for Document Update] RFC6470 (4073) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 18:22:15 -0000 The following errata report has been held for document update for RFC6470, "Network Configuration Protocol (NETCONF) Base Notifications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6470&eid=4073 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Andy Bierman Date Reported: 2014-08-07 Held by: Benoit Claise (IESG) Section: 2.2 Original Text ------------- file="ietf-netconf-notifications@2011-12-09.yang" Corrected Text -------------- file="ietf-netconf-notifications@2012-02-06.yang" Notes ----- Reported to me by Martin Bjorklund -------------------------------------- RFC6470 (draft-ietf-netconf-system-notifications-07) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Base Notifications Publication Date : February 2012 Author(s) : A. Bierman Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Sep 18 05:28:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5572B1A878C for ; Thu, 18 Sep 2014 05:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJQTSisYEYaL for ; Thu, 18 Sep 2014 05:28:09 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 70CA11A8755 for ; Thu, 18 Sep 2014 05:27:56 -0700 (PDT) Received: from [IPv6:2001:700:1:0:d0a2:85ec:37b3:f6d3] (unknown [IPv6:2001:700:1:0:d0a2:85ec:37b3:f6d3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by epost.uninett.no (Postfix) with ESMTPSA id B73153364D4 for ; Thu, 18 Sep 2014 14:27:53 +0200 (CEST) Message-ID: <541ACFC9.9050909@uninett.no> Date: Thu, 18 Sep 2014 14:27:53 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "netconf@ietf.org" References: <20140915165114.GA13011@elstar.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/KDY4KprVBwzA4sY-vAui9P3orns Subject: Re: [Netconf] lmap restconf proposal (push vs. pull) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 12:28:11 -0000 On 15. sep. 2014 20:16, Kent Watsen wrote: > To support devices behind NATs with RESTCONF, we should use the TLS > call-home strategy. That is, the device initiates a TCP connection to the > northbound system, which in turn starts HTTPS. Note that the TCP/TLS > connection can be long-lived while the HTTP protocol is start/stopped many > times. > > Using call-home this way is preferred for the same reasons why its > preferred for SSH and TLS transports for NETCONF - because it preserves > the directionality of the authentication mechanisms. In LMAP the managed devices can be behind multiple NATs and firewalls so there is a group consensus that HTTP with two-way SSL authentication should be used and the devices should pull information from the controller in a JSON format. The alternative to RESTCONF is to define a LMAP specific REST API. The LMAP information model maps very nicely to a YANG module and so far it looks like RESTCONF has all the features that are needed. So the question is whether this is an acceptable use of RESTCONF or if it is better to do the work of defining a LMAP specific REST API that will need to include many of the features already found in RESTCONF? Arne > > I know RESTCONF call-home came up and was shot down in Toronto, but I > think that was done erroneously and the decision re-examined. > > Kent > > > > > > On 9/15/14, 12:51 PM, "Juergen Schoenwaelder" > wrote: > >> Hi, >> >> I am sitting in the LMAP interim meeting and there is an I-D proposing >> to use RESTCONF, but it kind of changes the roles of the RESTCONF >> client and server. >> >> draft-oslebo-lmap-control-yang-00.txt >> >> My traditional understanding of RESTCONF is that it more or less >> follows NETCONF in the sense that the to be configured device runs a >> RESTCONF server and the RESTCONF client pushes config to the RESTCONF >> server on the device. The I-D mentioned above uses a pull model where >> the device to be configured runs a RESTCONF client getting its >> configuration from a RESTCONF server. The RESTCONF server in this case >> acts as a configuration server providing the configuration to a number >> of clients, each one pulling it via GETs as needed. >> >> The motivation for all this are devices sitting behind NATs and so >> this overlaps perhaps also with NETCONF configlets. Anyway, I wanted >> to start a thread here in order to hear what RESTCONF experts thing >> about this. >> >> /js >> >> -- >> 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 nobody Thu Sep 18 06:34:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6271A87D0 for ; Thu, 18 Sep 2014 06:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YweJvyTryjXh for ; Thu, 18 Sep 2014 06:34:55 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFEC1A87CB for ; Thu, 18 Sep 2014 06:34:55 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XUbrH-0003YC-M9 for netconf@ietf.org; Thu, 18 Sep 2014 15:34:52 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest105.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XUbrH-0001T2-Ik for netconf@ietf.org; Thu, 18 Sep 2014 15:34:51 +0200 Message-ID: <541ADF7A.8020607@ripe.net> Date: Thu, 18 Sep 2014 15:34:50 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885ee03a0936f5f7083b05a1aa31144c041d Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gHs6_hffam3FOapz4Jk3oEtNpIA Subject: [Netconf] Details about our upcoming Bi-weekly NETCONF Virtual Interim on 22 Sept 2014, 17:00-19:00 UTC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 13:34:57 -0000 NETCONF participants This coming Monday 22 Sept, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time) we will have our second NETCONF virtual interim meeting. Agenda - 5 min chair intro - recording the meeting, scribe, agenda bashing - 60 min restconf open issues (Andy) See https://github.com/netconf-wg/restconf/issues note that for issue https://github.com/netconf-wg/restconf/issues/7 we have a WG concensus call outstanding that ends today (Sept 18th). If you have not yet expressed your opinion, please do so ASAP today (any timezone). See consensus the formal call on wglist: http://www.ietf.org/mail-archive/web/netconf/current/msg09218.html - 40 min netconf-server model open issues (Kent) see: https://github.com/netconf-wg/server-model/issues - 15 min AOB other topics If you want specific topics on the agenda, please let us (WG Chairs) know ASAP. I believe the webex info for the meeting is this: To JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m9f461ea30a23d08e29f45c40c0814e7d Meeting number: 649 602 794 Meeting password: restconf JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 602 794 Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc In case you want to check, proceedings (including ptr to the recording) of our first virtual meeting on 8 Sept are here: http://www.ietf.org/proceedings/interim/2014/09/08/netconf/minutes/minutes-interim-2014-netconf-1 Bert and Mehmet From nobody Thu Sep 18 12:03:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100191A050E for ; Thu, 18 Sep 2014 12:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCyigctd_3pX for ; Thu, 18 Sep 2014 12:03:23 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F101A04A6 for ; Thu, 18 Sep 2014 12:03:23 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-07v.sys.comcast.net with comcast id sj3B1o00X4yXVJQ01j3Bqj; Thu, 18 Sep 2014 19:03:11 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-po-06v.sys.comcast.net with comcast id sj3A1o00M2yZEBF01j3B6N; Thu, 18 Sep 2014 19:03:11 +0000 From: "David Harrington" To: Date: Thu, 18 Sep 2014 15:03:05 -0400 Message-ID: <04b501cfd373$2e1ce8a0$8a56b9e0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/TQ1rXv4DBGaPUTj+otN6AD2/tsQ== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411066991; bh=OO9E9YXfDJGqrOriCQNwrc/M8h44jjMW9PeYRsKGYlU=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=nQ653WLJU3SdANebi9Q9ckpg/wqzVlSFl9iGIH4Lph248GbJVlqMwVFLzbKGWyoOA NF0Il4UZkgFEyMPq/7/y8Zil/Cf91p6ii+Lv4B37+Z1O2L/QyX7A02PFRqyY41OGvm v6UL4iG2RTnkV9+k2IEmPMRP+xa8bptMVukZwi6iefQRHIq67VQpuAseP/8awC+6be PEJBmFv2ZZeDq6y8NIHeh9hzD/o2+1zqMsi7Dv+4iYUMPOBhor+ut0boUkY0tCYIVN qucokkITeU8QFEfs4/CnxZRPdlzQ62pCL5roVyLv7OyqrTUAvSddq8AqVzkGE7uti9 QcNu3ErSgrxMg== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ZtN-MbJQoVpmApODpWOhqaBxjWw Subject: [Netconf] open source implementations of restconf? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 19:03:25 -0000 Hi, Are there any open source reference implementations of RESTCONF? Do they require an additional YANG and/or NETCONF implementation to work? David Harrington dbharrington@comcast.net +1-603-828-1401 From nobody Fri Sep 19 07:19:38 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD6C1A01AE for ; Fri, 19 Sep 2014 07:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6l8SOuvpYnq for ; Fri, 19 Sep 2014 07:19:32 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0750.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::750]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE54E1A0199 for ; Fri, 19 Sep 2014 07:19:31 -0700 (PDT) Received: from pc6 (86.184.59.221) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 19 Sep 2014 14:19:08 +0000 Message-ID: <01b701cfd414$748bff00$4001a8c0@gateway.2wire.net> From: t.petch To: Bert Wijnen , Netconf References: <53D01A8A.6030703@ripe.net> <53D15B74.7000404@ripe.net> Date: Fri, 19 Sep 2014 15:16:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.59.221] X-ClientProxiedBy: AM3PR03CA023.eurprd03.prod.outlook.com (10.141.191.151) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Forefront-PRVS: 0339F89554 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(13464003)(62966002)(80022003)(74662003)(46102003)(81542003)(77982003)(79102003)(81342003)(86362001)(4396001)(74502003)(83322001)(23746002)(88136002)(47776003)(105586002)(116806002)(85306004)(95666004)(77156001)(50226001)(93916002)(84392001)(106356001)(44716002)(19580395003)(21056001)(44736004)(20776003)(66066001)(62236002)(107046002)(102836001)(77096002)(50466002)(19580405001)(101416001)(92726001)(33646002)(107886001)(14496001)(87286001)(76482002)(87976001)(61296003)(89996001)(42186005)(85852003)(83072002)(99396002)(104166001)(31966008)(561944003)(92566001)(90102001)(15975445006)(76176999)(81686999)(81816999)(97736003)(50986999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NuugeZbpMNq8B9gT4prxM6vzsuU Subject: Re: [Netconf] Action by August 1st: WG call for consensus to have ONE netconf-callhome document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:19:33 -0000 Bert I never saw a follow up to this - I say more in my e-mail to Mehmet. Tom Petch ----- Original Message ----- From: "Bert Wijnen" To: "Netconf" Sent: Thursday, July 24, 2014 8:16 PM Subject: [Netconf] Action by August 1st: WG call for consensus to have ONE netconf-callhome document WG participants, during our IET90 session, Kent presented and we discussed reverse ssh this issue: Asymmetric document structure 5539bis vs RFC6242 + reverse-ssh -> 6242bis instead? Placement for generic content, Including: Section 3: "Benefits to Device Management” Section 5: "SSH Server Identification and Verification” Best if moved to a common “Call Home” draft A “6242bis” wouldn’t work after all… Proposal: Have a single “NETCONF Call Home” (draft-ietf-netconf-call-home) draft that is equally valid for all NETCONF transports rename this draft and move 5539bis content into it We did a hum in the room and there was overwhelming support to accept the proposal. No-one hummed against or abstained. So we're confirming this consensus on the WG mailing list. Please speak up by Friday August 1st if you disagree. Bert and Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Sep 19 07:19:39 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C021A01AE for ; Fri, 19 Sep 2014 07:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgnF1wfuHK16 for ; Fri, 19 Sep 2014 07:19:31 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0750.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::750]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E351A0193 for ; Fri, 19 Sep 2014 07:19:30 -0700 (PDT) Received: from pc6 (86.184.59.221) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 19 Sep 2014 14:19:07 +0000 Message-ID: <01b601cfd414$7448db80$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" , Benoit Claise , netconf References: Date: Fri, 19 Sep 2014 15:15:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.59.221] X-ClientProxiedBy: AM3PR03CA023.eurprd03.prod.outlook.com (10.141.191.151) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Forefront-PRVS: 0339F89554 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(189002)(377454003)(52604005)(66654002)(199003)(13464003)(62966002)(80022003)(74662003)(46102003)(81542003)(77982003)(79102003)(81342003)(86362001)(4396001)(74502003)(64706001)(83322001)(88136002)(47776003)(105586002)(116806002)(85306004)(95666004)(77156001)(50226001)(93916002)(84392001)(106356001)(44716002)(19580395003)(21056001)(44736004)(20776003)(66066001)(62236002)(107046002)(102836001)(77096002)(50466002)(23756003)(19580405001)(101416001)(92726001)(33646002)(107886001)(14496001)(87286001)(76482002)(87976001)(61296003)(89996001)(42186005)(85852003)(83072002)(99396002)(104166001)(31966008)(561944003)(92566001)(90102001)(15975445006)(15202345003)(76176999)(81686999)(81816999)(97736003)(50986999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eKxlv3HvtG4K1k8rviGO7NfB7L8 Subject: Re: [Netconf] Summary of the Netconf Session at IETF #90 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:19:34 -0000 Mehmet I never saw a follow up to the actions suggested in this. We now have a netconf-call-home so reverse-ssh may be obsolete. This e-mail suggests that rfc5539bis will be cleaned up with the publication of netconf-call-home, but not obsoleted. However, a search of the IETF I-Ds shows that reverse-ssh is alive and well, as -06 while 5539bis has vanished from the Netconf pages and is expired (dead?). Just back from holiday, I am trying to refresh my memory as to what should be happening. I had hoped to comment on call home (ideally before Monday next) - I think that the language needs clarification - but the big issue, without which it seems not worth starting, is how many I-Ds are there now, which I-Ds have been updated in the light of the decisions proposed at the July IETF, which I-Ds are now dead and which I-Ds are we waiting still to appear. And the I-Ds themselves are, well, useless? netconf-call-home says nothing about its status wrt other I-Ds, what it replaces wholy or in part. If, as I guess, netconf-call-home replaces reverse-ssh, then I think it a bad idea, for all time, to have changed the name, especially without any content explaining the relationship, old and new. You say below "Update charter if WG consensus is confirmed. " Well, the former has not happened; did the latter? Mmmm Tom Petch ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Benoit Claise" ; "netconf" Cc: "Jeffrey Haas" ; "ext Edward Crabbe" Sent: Thursday, July 24, 2014 9:31 PM Dear Benoit, NETCONF WG, below is a summary and action items from the NETCONF WG session on July 22, 2014, Toronto Canada. - We had approx. 92(!!) participants in the 2 hour NETCONF session, - We reviewed the status of the WG, - We had a discussion on all 6 chartered documents. - Note takers were: Dan Romascanu and Lada Lhotka. Many thanks for volunteering. Chartered items: 1. Reverse Secure Shell (Reverse SSH) - K. Watsen http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh Issues discussed. Some of the issues will be taken to the list. 2. NETCONF Over TLS update - RFC 5539bis - J. Schoenwaelder http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis Issues discussed. Some of the issues will be taken to the list. 3. A YANG Data Model for NETCONF Server Configuration - K. Watsen http://tools.ietf.org/html/draft-ietf-netconf-server Issues discussed. The proposal to provide a I-D draft-ietf-netconf-call-home has been discussed. This draft would replace reverse-ssh and also clean up call home related part in 5539bis. Humming showed that the WG is in favor of this I-D. Based on this the co-chairs sent a consensus call to the WG list. AI Co-chairs: Update charter if WG consensus is confirmed. 4. RESTCONF Protocol - A. Bierman http://tools.ietf.org/html/draft-ietf-netconf-restconf Issues discussed. Some of the issues will be taken to the list. 5. YANG Patch Media Type - A. Bierman http://tools.ietf.org/html/draft-ietf-netconf-yang-patch Issue discussed. 6. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen http://tools.ietf.org/html/draft-ietf-netconf-zerotouch Issues discussed. AI for the authors of the chartered items: Please provide an update for your draft by September 1st. Non-Chartered items: 1. I2RS Requirements on NETCONF - Jeff Haas I2RS WG will provide a draft describing the requirements on NETCONF. It has been proposed to start a discussion as early as possible to figure out whether single requirements can be already addressed with available NETCONF protocol features. AI Jeff Haas: to get the I2RS WG (plus any volunteers) to do this. 2. A NETCONF Extension for Data Fragmentation - G. Zheng http://tools.ietf.org/html/draft-liu-netconf-fragmentation Humming showed that the WG sees the issues as a valid problem. It needs to be discussed whether it can be addressed with a bis-draft. For the time being NETCONF charter will not be changed. Once active WG items are finalized the draft can be re-discussed. 3. Multi-Instances Configuration Issue in NETCONF - G. Yan http://tools.ietf.org/html/draft-liu-netconf-multi-instances The presenter has been proposed that he should check with the I2RS WG as they have similar issues to address. Regards, Mehmet & Bert From nobody Fri Sep 19 11:58:49 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667D21A04FA for ; Fri, 19 Sep 2014 11:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tWH30Jw5xt2 for ; Fri, 19 Sep 2014 11:58:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0123C1A02EB for ; Fri, 19 Sep 2014 11:58:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 76411BEB; Fri, 19 Sep 2014 20:58:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 04s0AIoB1zeJ; Fri, 19 Sep 2014 20:58:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 19 Sep 2014 20:58:43 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B11FD20036; Fri, 19 Sep 2014 20:58:43 +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 2TltQii4s630; Fri, 19 Sep 2014 20:58:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F29D220035; Fri, 19 Sep 2014 20:58:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D25142E8248B; Fri, 19 Sep 2014 20:58:41 +0200 (CEST) Date: Fri, 19 Sep 2014 20:58:41 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20140919185841.GB11277@elstar.local> Mail-Followup-To: "t. petch" , Bert Wijnen , Netconf References: <53D01A8A.6030703@ripe.net> <53D15B74.7000404@ripe.net> <01b701cfd414$748bff00$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01b701cfd414$748bff00$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yqyMrH5A8pVsd9MynWRJoyJ_ces Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] Action by August 1st: WG call for consensus to have ONE netconf-callhome document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:58:48 -0000 Tom, there is https://tools.ietf.org/html/draft-ietf-netconf-call-home-00 and there is an update of 5539bis pending that removes call home from it. And then there is the NC server configuration model https://tools.ietf.org/html/draft-ietf-netconf-server-model-02 I think we are doing exactly what was discussed in Toronto. /js On Fri, Sep 19, 2014 at 03:16:25PM +0100, t. petch wrote: > Bert > > I never saw a follow up to this - I say more in my e-mail to Mehmet. > > Tom Petch > > > ----- Original Message ----- > From: "Bert Wijnen" > To: "Netconf" > Sent: Thursday, July 24, 2014 8:16 PM > Subject: [Netconf] Action by August 1st: WG call for consensus to have > ONE netconf-callhome document > > > WG participants, during our IET90 session, Kent presented > and we discussed reverse ssh this issue: > > Asymmetric document structure > 5539bis vs RFC6242 + reverse-ssh -> 6242bis instead? > > Placement for generic content, Including: > Section 3: "Benefits to Device Management†> Section 5: "SSH Server Identification and Verification†> > Best if moved to a common “Call Home†draft > A “6242bis†wouldn’t work after all… > > Proposal: > Have a single “NETCONF Call Home†(draft-ietf-netconf-call-home) > draft that is equally valid for all NETCONF transports > rename this draft and move 5539bis content into it > > > We did a hum in the room and there was overwhelming support to accept > the proposal. No-one hummed against or abstained. > > So we're confirming this consensus on the WG mailing list. > > Please speak up by Friday August 1st if you disagree. > > Bert and Mehmet > > > _______________________________________________ > 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Sep 19 13:15:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8111A0721 for ; Fri, 19 Sep 2014 13:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdFsW7n3jXOq for ; Fri, 19 Sep 2014 13:15:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::790]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6331A06A4 for ; Fri, 19 Sep 2014 13:15:20 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 19 Sep 2014 20:14:56 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.179]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.00.1029.000; Fri, 19 Sep 2014 20:14:56 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "t. petch" Thread-Topic: [Netconf] Action by August 1st: WG call for consensus to have ONE netconf-callhome document Thread-Index: AQHPp3O9vZj6SBd2MEehKjcLoumaLJwI2pkZgABN9ID//9JAgA== Date: Fri, 19 Sep 2014 20:14:56 +0000 Message-ID: References: <53D01A8A.6030703@ripe.net> <53D15B74.7000404@ripe.net> <01b701cfd414$748bff00$4001a8c0@gateway.2wire.net> <20140919185841.GB11277@elstar.local> In-Reply-To: <20140919185841.GB11277@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 0339F89554 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(479174003)(189002)(24454002)(199003)(377454003)(50986999)(90102001)(76176999)(83506001)(4396001)(79102003)(64706001)(80022003)(19580395003)(19580405001)(561944003)(99286002)(85852003)(15975445006)(20776003)(95666004)(93886004)(31966008)(83072002)(85306004)(46102003)(2656002)(76482002)(83322001)(92566001)(107046002)(106116001)(77982003)(21056001)(92726001)(106356001)(81342003)(97736003)(36756003)(77096002)(74662003)(99396002)(74502003)(86362001)(101416001)(54356999)(81542003)(105586002)(66066001)(87936001)(15202345003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <4B002697D1E72E48ADEE488BFB9AB64C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/aEeBuCo3r0MI2iMokRBPWZ6M4fY Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] Action by August 1st: WG call for consensus to have ONE netconf-callhome document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:15:23 -0000 But to Tom's point, the reverse-ssh is still listed as an "Active" draft and the charter has not yet been updated. Kent On 9/19/14, 2:58 PM, "Juergen Schoenwaelder" wrote: >Tom, > >there is > >https://tools.ietf.org/html/draft-ietf-netconf-call-home-00 > >and there is an update of 5539bis pending that removes call home >from it. And then there is the NC server configuration model > >https://tools.ietf.org/html/draft-ietf-netconf-server-model-02 > >I think we are doing exactly what was discussed in Toronto. > >/js > >On Fri, Sep 19, 2014 at 03:16:25PM +0100, t. petch wrote: >> Bert >>=20 >> I never saw a follow up to this - I say more in my e-mail to Mehmet. >>=20 >> Tom Petch >>=20 >>=20 >> ----- Original Message ----- >> From: "Bert Wijnen" >> To: "Netconf" >> Sent: Thursday, July 24, 2014 8:16 PM >> Subject: [Netconf] Action by August 1st: WG call for consensus to have >> ONE netconf-callhome document >>=20 >>=20 >> WG participants, during our IET90 session, Kent presented >> and we discussed reverse ssh this issue: >>=20 >> Asymmetric document structure >> 5539bis vs RFC6242 + reverse-ssh -> 6242bis instead? >>=20 >> Placement for generic content, Including: >> Section 3: "Benefits to Device Management=B2 >> Section 5: "SSH Server Identification and Verification=B2 >>=20 >> Best if moved to a common =B3Call Home=B2 draft >> A =B36242bis=B2 wouldn=B9t work after all=8A >>=20 >> Proposal: >> Have a single =B3NETCONF Call Home=B2 (draft-ietf-netconf-call-home) >> draft that is equally valid for all NETCONF transports >> rename this draft and move 5539bis content into it >>=20 >>=20 >> We did a hum in the room and there was overwhelming support to accept >> the proposal. No-one hummed against or abstained. >>=20 >> So we're confirming this consensus on the WG mailing list. >>=20 >> Please speak up by Friday August 1st if you disagree. >>=20 >> Bert and Mehmet >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > >--=20 >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 nobody Sun Sep 21 01:57:07 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC721A0060 for ; Sun, 21 Sep 2014 01:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLyqVZoHltYN for ; Sun, 21 Sep 2014 01:55:51 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::751]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECF61A0023 for ; Sun, 21 Sep 2014 01:55:50 -0700 (PDT) Received: from pc6 (86.184.59.221) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Sun, 21 Sep 2014 08:55:26 +0000 Message-ID: <012301cfd579$90490f60$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <53D01A8A.6030703@ripe.net> <53D15B74.7000404@ripe.net> <01b701cfd414$748bff00$4001a8c0@gateway.2wire.net> <20140919185841.GB11277@elstar.local> Date: Sun, 21 Sep 2014 09:45:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.184.59.221] X-ClientProxiedBy: DB4PR02CA0027.eurprd02.prod.outlook.com (10.242.174.155) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Forefront-PRVS: 034119E4F6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(189002)(13464003)(199003)(24454002)(19580405001)(93886004)(85306004)(86362001)(116806002)(104166001)(50466002)(107046002)(77156001)(92566001)(15975445006)(19580395003)(83322001)(33646002)(93916002)(31966008)(76482002)(92726001)(110136001)(90102001)(87976001)(42186005)(87286001)(88136002)(61296003)(46102003)(77096002)(81342003)(23676002)(95666004)(105586002)(106356001)(62966002)(97736003)(79102003)(81542003)(4396001)(47776003)(81686999)(62236002)(74662003)(14496001)(76176999)(81816999)(80022003)(74502003)(44736004)(101416001)(102836001)(64706001)(44716002)(85852003)(83072002)(50226001)(77982003)(50986999)(66066001)(21056001)(99396002)(20776003)(89996001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PUJx_gsYQ3jtP0o7KQca_7mLag4 Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] Action by August 1st: WG call for consensus to have ONE netconf-callhome document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 08:56:21 -0000 X-List-Received-Date: Sun, 21 Sep 2014 08:56:21 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: "Bert Wijnen" ; "Netconf" Sent: Friday, September 19, 2014 7:58 PM > Tom, > > there is > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-00 > > and there is an update of 5539bis pending that removes call home > from it. And then there is the NC server configuration model > > https://tools.ietf.org/html/draft-ietf-netconf-server-model-02 > > I think we are doing exactly what was discussed in Toronto. Yes, but I was hoping for a confirmation on the list, as being the usual way to proceed (and which the report from Toronto says will happen). And if we are taking a chunk out of A to form A' and adding a chunk to B to form B', then I want to see both A' and B' together, to see that they fit together, do not have gaps left, do not contradict each other and so on. I was asked to look at call-home (!:-( before Monday and decided that I could not adequately do that without the corresponding update to 5539bis. I still think that. After that, it would make sense to me to look at server-model. Tom Petch > > /js > > On Fri, Sep 19, 2014 at 03:16:25PM +0100, t. petch wrote: > > Bert > > > > I never saw a follow up to this - I say more in my e-mail to Mehmet. > > > > Tom Petch > > .de/> From nobody Mon Sep 22 00:51:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44531A1A5F for ; Mon, 22 Sep 2014 00:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3y7Yp-ol_h6 for ; Mon, 22 Sep 2014 00:51:23 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3162C1A1A44 for ; Mon, 22 Sep 2014 00:51:23 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XVyP1-0005Eu-4P; Mon, 22 Sep 2014 09:51:20 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh-6.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XVyP1-0003S1-0W; Mon, 22 Sep 2014 09:51:19 +0200 Message-ID: <541FD4F6.4040208@ripe.net> Date: Mon, 22 Sep 2014 09:51:18 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "t.petch" , Juergen Schoenwaelder References: <53D01A8A.6030703@ripe.net> <53D15B74.7000404@ripe.net> <01b701cfd414$748bff00$4001a8c0@gateway.2wire.net> <20140919185841.GB11277@elstar.local> <012301cfd579$90490f60$4001a8c0@gateway.2wire.net> In-Reply-To: <012301cfd579$90490f60$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e03ec0f2277ca8306779245aded3c493e Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XeIzz1oJDgQ_QN9t_vynqfMhADM Cc: Netconf Subject: Re: [Netconf] Action by August 1st: WG call for consensus to have ONE netconf-callhome document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 07:51:26 -0000 Tom, others, We (WG chairs directly or on mlist) did not receive any objections to the consensus call on the mailing list that we used to verify the f2f consensus. We should have (as promised and as you say) re-confirmed that on the list. I guess our vacations got us somewhat out of focus. We believe we now have wg consensus on merging the callhome material. You are correct that it would be good to have all related documents (with changes because of this) available at the same time. Juergen was busy however with his NETMOD interim in NY and so he was unable to deliver the 5539bis revision sofar. I am sure he will do so as soon as he gets a chance. Hope this helps, Bert On 21/09/14 10:45, t.petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "t. petch" > Cc: "Bert Wijnen" ; "Netconf" > Sent: Friday, September 19, 2014 7:58 PM > >> Tom, >> >> there is >> >> https://tools.ietf.org/html/draft-ietf-netconf-call-home-00 >> >> and there is an update of 5539bis pending that removes call home >> from it. And then there is the NC server configuration model >> >> https://tools.ietf.org/html/draft-ietf-netconf-server-model-02 >> >> I think we are doing exactly what was discussed in Toronto. > > Yes, but I was hoping for a confirmation on the list, as being the usual > way to proceed (and which the report from Toronto says will happen). > > And if we are taking a chunk out of A to form A' and adding a chunk to B > to form B', then I want to see both A' and B' together, to see that they > fit together, do not have gaps left, do not contradict each other and so > on. > > I was asked to look at call-home (!:-( before Monday and decided that I > could not adequately do that without the corresponding update to > 5539bis. I still think that. After that, it would make sense to me to > look at server-model. > > Tom Petch >> >> /js >> >> On Fri, Sep 19, 2014 at 03:16:25PM +0100, t. petch wrote: >>> Bert >>> >>> I never saw a follow up to this - I say more in my e-mail to Mehmet. >>> >>> Tom Petch >>> .de/> > From nobody Mon Sep 22 03:39:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922361A1A98; Mon, 22 Sep 2014 03:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruKLxKZDSqnw; Mon, 22 Sep 2014 03:39:13 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C11A1A1A97; Mon, 22 Sep 2014 03:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59244; q=dns/txt; s=iport; t=1411382353; x=1412591953; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=lE1voPxZl1asYZ5BDj9GQLkJGqFVtEQhblaYksQlUUE=; b=lzX9ZSH8sUEF9W6B6vfWzlDFim2o74TS2asppcfFok8SUyjrHRiF4qQ+ KTp65iLd8YjhWVll+pxLeFW9qkpFui8KV2AB47EJFajpkB3hI0Zm9rz5x RcxZO7tif8T0r0YLzgNeVtsyFN6e4bnjFrNxT67XJiYID6YCxSbSsxiIR A=; X-IronPort-AV: E=Sophos;i="5.04,571,1406592000"; d="scan'208,217";a="181244852" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 22 Sep 2014 10:39:11 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8MAdAxU012387; Mon, 22 Sep 2014 10:39:10 GMT Message-ID: <541FFC4E.3000907@cisco.com> Date: Mon, 22 Sep 2014 12:39:10 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Andy Bierman , "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> <53C522F0.1030107@bwijnen.net> <53C537E0.3090105@bwijnen.net> <1405435684.19255.2.camel@ksekera-fedora> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010009030705040905090807" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/I6enB6bJmJLU3DDwk10xO3qrMug Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "randy_presuhn@mindspring.com" , "netconf@ietf.org" , "netconf-bounces@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 10:39:18 -0000 This is a multi-part message in MIME format. --------------010009030705040905090807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, Let me come back to this errata http://www.rfc-editor.org/errata_search.php?eid=3980 I have some difficulties to draw the conclusion... Regards, Benoit > > > > On Tue, Jul 15, 2014 at 7:48 AM, Klement Sekera -X (ksekera - Pantheon > Technologies SRO at Cisco) > wrote: > > Hi Andy, > > just to clarify, your filter would select only the one disabled > interface even if you specified the there. All the other > instances would be dropped, since the content-match on is > false. > > > you're right. > > been awhile since I implemented this section. > I notice sec. 6.2.5 also has this text: > > o If any sibling nodes of the selection node are instance identifier > components for a conceptual data structure (e.g., list key leaf), > then they MAY also be included in the filter output. > > Andy > > Klement > > On Tue, 2014-07-15 at 07:35 -0700, Andy Bierman wrote: > > On Tue, Jul 15, 2014 at 7:17 AM, Bert Wijnen (IETF) > > > > wrote: > > > > > Well, I added text that explains that if a client wnts to be > sure that it > > > better > > > asks for the leafs in its filter > > > > > > > > > The subtree filtering is much more useful if the server supplies > missing > > keys. > > (I guess we agree on that). Consider a simple use-case: there > are 10,000 > > interface > > entries and 1 of them is disabled. Which one? > > > > > > > > false > > > > > > > > If I add the leaf to the filter, I will get back 10,000 > matches. > > If I don't, then all I get back is the filter I sent, confirming > there is > > indeed 1 disabled interface. > > The only useful response is to include the leaf for the 1 > entry that > > matched. > > > > It seems like SHOULD is more appropriate than MAY. It does not > force old > > servers to > > be non-compliant like MUST. > > > > > > > Bert > > > > > > > Andy > > > > > > > > > > On 15/07/14 15:51, Andy Bierman wrote: > > > > > >> > > >> > > >> > > >> On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) > > > >> >> > wrote: > > >> > > >> Or.... maybe use MAY and add that if the client wants to > be sure that > > >> such leafs are returned, then the client better asks for > those leaf > > >> explicitly > > >> in the filter. > > >> > > >> > > >> So what is the point of this errata? The client already MAY > include > > >> whatever > > >> nodes it wants in the filter. IMO the new text adds no value and > > >> clarifies nothing. > > >> > > >> > > >> > > >> Bert > > >> > > >> > > >> Andy > > >> > > >> > > >> On 15/07/14 14:39, Martin Björklund wrote: > > >> > > >> I agree with Juergen. Thus, I think the new text > should use MAY > > >> instead of MUST. > > >> > > >> On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-__university.de > > > >> >> wrote: > > >> > > >> But since the original spec did not say clearly > such leafs > > >> must be > > >> included, I think the only safe bet for a client > is to > > >> explicitely > > >> request key leafs in the filter - unless we are > sure the > > >> _every_ > > >> implementation actually returns key leafs (and > since nobody > > >> knows the > > >> number of implementations around, establishing > this fact is > > >> hard). > > >> > > >> /js > > >> > > >> On Tue, Jul 15, 2014 at 08:58:14AM +0800, > > >> feng.chong33@zte.com.cn > > > > >> wrote: > > >> > > >> I agree instance identifier MUST be present > in output. > > >> /frank > > >> > > >> > > >> "Netconf" > >> netconf-bounces@ietf.org >> > ?? 2014-07-14 20:38:16: > > >> > > >> Benoit Claise > >> bclaise@cisco.com >> > > >> ???: "Netconf" > >> netconf-bounces@ietf.org >> > > >> > > >> 2014-07-14 20:38 > > >> > > >> ??? > > >> > > >> Martin Björklund > >> mbj@tail-f.com >>, Randy Presuhn > > >> > > >> mindspring.com >>__, "Klement Sekera > -X (ksekera - > > >> Pantheon Technologies SRO at Cisco)" < > > >> ksekera@cisco.com > >>, > > >> > > >> ?? > > >> > > >> "rob.enns@gmail.com > >" < > > >> rob.enns@gmail.com > >>, > > >> "joelja@bogus.com > >" > > >> >>, " > > >> netconf@ietf.org > >" > > > >> >> > > >> > > >> ?? > > >> > > >> Re: [Netconf] [Technical Errata Reported] > RFC6241 > > >> (3980) > > >> > > >> Dear all, > > >> > > >> Let me try to bring some closure on this > errata > > >> http://www.rfc- > > >> editor.org/errata_search.php?__eid=3980 > < > > >> http://editor.org/errata_search.php?eid=3980> > > >> Before proceeding (I want to check with > the IESG if > > >> this is allowed > > >> > > >> > > >> to introduce a new MUST sentence in an > errata), I > > >> would like to > > >> 1. check that text below is the final > proposal > > >> 2. understand if there is agreement in > the WG. Do > > >> someone object > > >> > > >> this > > >> > > >> change? > > >> > > >> OLD: > > >> For each sibling set, the server > determines > > >> which nodes are > > >> > > >> included > > >> > > >> (or potentially included) in the > filter output, > > >> and which > > >> > > >> sibling > > >> > > >> subtrees are excluded (pruned) from > the filter > > >> output. The > > >> > > >> server > > >> > > >> first determines which types of > nodes are > > >> present in the sibling > > >> > > >> set > > >> > > >> and processes the nodes according to > the rules > > >> for their type. > > >> > > >> If > > >> > > >> any nodes in the sibling set are > selected, then > > >> the process is > > >> recursively applied to the sibling > sets of each > > >> selected node. > > >> > > >> The > > >> > > >> algorithm continues until all > sibling sets in > > >> all subtrees > > >> > > >> specified > > >> > > >> in the filter have been processed. > > >> > > >> NEW: > > >> For each sibling set, the server > determines > > >> which nodes are > > >> > > >> included > > >> > > >> (or potentially included) in the > filter output, > > >> and which > > >> > > >> sibling > > >> > > >> subtrees are excluded (pruned) from > the filter > > >> output. The > > >> > > >> server > > >> > > >> first determines which types of > nodes are > > >> present in the sibling > > >> > > >> set > > >> > > >> and processes the nodes according to > the rules > > >> for their type. > > >> > > >> If > > >> > > >> any nodes in the sibling set are > selected, then > > >> the process is > > >> recursively applied to the sibling > sets of each > > >> selected node. > > >> > > >> The > > >> > > >> algorithm continues until all > sibling sets in > > >> all subtrees > > >> > > >> specified > > >> > > >> in the filter have been processed. > If any > > >> sibling nodes of a > > >> > > >> node > > >> > > >> are instance identifier components for a > > >> conceptual data > > >> > > >> structure > > >> > > >> (e.g., list key leaf), then they MUST be > > >> included in the filter > > >> > > >> output. > > >> > > >> Regards, Benoit > > >> > > >> > > >> I agree that MUST would be better. But I > don't think > > >> we can/should > > >> do thar change in an errata. > > >> > > >> On 20 juni 2014 13:57:24 PDT, Randy Presuhn > > >> > > >> > > >> mindspring.com >> > > >> > > >> wrote: > > >> > > >> > > >> Hi - > > >> > > >> > > >> From: Benoit Claise > >> bclaise@cisco.com >> > > >> Sent: Jun 20, 2014 2:01 AM > > >> > > >> > > >> ... > > >> > > >> > > >> Subject: Re: [Netconf] [Technical Errata > Reported] > > >> RFC6241 (3980) > > >> > > >> One last check (till mid next week) for > everybody in > > >> the WG before > > >> > > >> I > > >> > > >> apply this change below to the errata, > and accept it. > > >> > > >> > > >> > > >> "SHOULD" is no better than "MAY" or > "OPTIONAL" from an > > >> interoperability perspective. "MUST" > would be much > > >> simpler > > >> for all concerned. > > >> > > >> Randy > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> > > >> > > >> /martin > > >> . > > >> > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> ------------------------------ > > >> __-------------------------- > > >> ZTE Information Security Notice: The information > > >> contained in this > > >> > > >> mail (and any attachment transmitted herewith) is > privileged > > >> and > > >> confidential and is intended for the exclusive > use of the > > >> addressee(s). > > >> If you are not an intended recipient, any disclosure, > > >> reproduction, > > >> distribution or other dissemination or use of the > information > > >> contained > > >> is strictly prohibited. If you have received > this mail in > > >> error, > > >> please delete it and notify us immediately. > > >> > > >> ------------------------------ > > >> __-------------------------- > > >> ZTE Information Security Notice: The information > > >> contained in this > > >> > > >> mail (and any attachment transmitted herewith) is > privileged > > >> and > > >> confidential and is intended for the exclusive > use of the > > >> addressee(s). > > >> If you are not an intended recipient, any disclosure, > > >> reproduction, > > >> distribution or other dissemination or use of the > information > > >> contained > > >> is strictly prohibited. If you have received > this mail in > > >> error, > > >> please delete it and notify us immediately. > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> > > >> -- > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, > > >> Germany > > >> Fax: +49 421 200 3103 < > > >> http://www.jacobs-university.__de/ > > > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> > > >> /martin > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> > > _______________________________________________ > > 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 --------------010009030705040905090807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Let me come back to this errata http://www.rfc-editor.org/errata_search.php?eid=3980
I have some difficulties to draw the conclusion...

Regards, Benoit



On Tue, Jul 15, 2014 at 7:48 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
Hi Andy,

just to clarify, your filter would select only the one disabled
interface even if you specified the <name> there. All the other
instances would be dropped, since the content-match on <enabled> is
false.


you're right.

been awhile since I implemented this section.
I notice sec. 6.2.5 also has this text:

   o  If any sibling nodes of the selection node are instance identifier
      components for a conceptual data structure (e.g., list key leaf),
      then they MAY also be included in the filter output.

Andy
 
Klement

On Tue, 2014-07-15 at 07:35 -0700, Andy Bierman wrote:
> On Tue, Jul 15, 2014 at 7:17 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net>
> wrote:
>
> > Well, I added text that explains that if a client wnts to be sure that it
> > better
> > asks for the leafs in its filter
> >
>
>
> The subtree filtering is much more useful if the server supplies missing
> keys.
> (I guess we agree on that).  Consider a simple use-case: there are 10,000
> interface
> entries and 1 of them is disabled.  Which one?
>
>    <interfaces>
>       <interface>
>          <enabled>false</enabled>
>       </interface>
>    </interfaces>
>
> If I add the <name> leaf to the filter, I will get back 10,000 matches.
> If I don't, then all I get back is the filter I sent, confirming there is
> indeed 1 disabled interface.
> The only useful response is to include the <name> leaf for the 1 entry that
> matched.
>
> It seems like SHOULD is more appropriate than MAY.  It does not force old
> servers to
> be non-compliant like MUST.
>
>
> > Bert
> >
>
> Andy
>
>
> >
> > On 15/07/14 15:51, Andy Bierman wrote:
> >
> >>
> >>
> >>
> >> On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net
> >> <mailto:bertietf@bwijnen.net>> wrote:
> >>
> >>     Or.... maybe use MAY and add that if the client wants to be sure that
> >>     such leafs are returned, then the client better asks for those leaf
> >> explicitly
> >>     in the filter.
> >>
> >>
> >> So what is the point of this errata?  The client already MAY include
> >> whatever
> >> nodes it wants in the filter. IMO the new text adds no value and
> >> clarifies nothing.
> >>
> >>
> >>
> >>     Bert
> >>
> >>
> >> Andy
> >>
> >>
> >>     On 15/07/14 14:39, Martin Björklund wrote:
> >>
> >>         I agree with Juergen. Thus, I think the new text should use MAY
> >> instead of MUST.
> >>
> >>         On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder <
> >> j.schoenwaelder@jacobs-__university.de
> >>         <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
> >>
> >>             But since the original spec did not say clearly such leafs
> >> must be
> >>             included, I think the only safe bet for a client is to
> >> explicitely
> >>             request key leafs in the filter - unless we are sure the
> >> _every_
> >>             implementation actually returns key leafs (and since nobody
> >> knows the
> >>             number of implementations around, establishing this fact is
> >> hard).
> >>
> >>             /js
> >>
> >>             On Tue, Jul 15, 2014 at 08:58:14AM +0800,
> >> feng.chong33@zte.com.cn <mailto:feng.chong33@zte.com.cn>
> >>             wrote:
> >>
> >>                 I agree instance identifier MUST be present in output.
> >>                 /frank
> >>
> >>
> >>                 "Netconf" <netconf-bounces@ietf.org <mailto:
> >> netconf-bounces@ietf.org>> 写于 2014-07-14 20:38:16:
> >>
> >>                     Benoit Claise <bclaise@cisco.com <mailto:
> >> bclaise@cisco.com>>
> >>                     发件人:  "Netconf" <netconf-bounces@ietf.org <mailto:
> >> netconf-bounces@ietf.org>>
> >>
> >>                     2014-07-14 20:38
> >>
> >>                     收件人
> >>
> >>                     Martin Björklund <mbj@tail-f.com <mailto:
> >> mbj@tail-f.com>>, Randy Presuhn
> >>                     <randy_presuhn@mindspring.com <mailto:randy_presuhn@
> >> mindspring.com>>__, "Klement Sekera -X (ksekera -
> >>                     Pantheon Technologies SRO at Cisco)" <
> >> ksekera@cisco.com <mailto:ksekera@cisco.com>>,
> >>
> >>                     抄送
> >>
> >>                     "rob.enns@gmail.com <mailto:rob.enns@gmail.com>" <
> >> rob.enns@gmail.com <mailto:rob.enns@gmail.com>>,
> >>                     "joelja@bogus.com <mailto:joelja@bogus.com>"
> >>                     <joelja@bogus.com <mailto:joelja@bogus.com>>, "
> >> netconf@ietf.org <mailto:netconf@ietf.org>" <netconf@ietf.org
> >>                     <mailto:netconf@ietf.org>>
> >>
> >>                     主题
> >>
> >>                     Re: [Netconf] [Technical Errata Reported] RFC6241
> >> (3980)
> >>
> >>                     Dear all,
> >>
> >>                     Let me try to bring some closure on this errata
> >> http://www.rfc-
> >>                     editor.org/errata_search.php?__eid=3980 <
> >> http://editor.org/errata_search.php?eid=3980>
> >>                     Before proceeding (I want to check with the IESG if
> >> this is allowed
> >>
> >>
> >>                     to introduce a new MUST sentence in an errata), I
> >> would like to
> >>                     1. check that text below is the final proposal
> >>                     2. understand if there is agreement in the WG. Do
> >> someone object
> >>
> >>             this
> >>
> >>                 change?
> >>
> >>                     OLD:
> >>                          For each sibling set, the server determines
> >> which nodes are
> >>
> >>             included
> >>
> >>                          (or potentially included) in the filter output,
> >> and which
> >>
> >>             sibling
> >>
> >>                          subtrees are excluded (pruned) from the filter
> >> output.  The
> >>
> >>             server
> >>
> >>                          first determines which types of nodes are
> >> present in the sibling
> >>
> >>             set
> >>
> >>                          and processes the nodes according to the rules
> >> for their type.
> >>
> >>             If
> >>
> >>                          any nodes in the sibling set are selected, then
> >> the process is
> >>                          recursively applied to the sibling sets of each
> >> selected node.
> >>
> >>             The
> >>
> >>                          algorithm continues until all sibling sets in
> >> all subtrees
> >>
> >>             specified
> >>
> >>                          in the filter have been processed.
> >>
> >>                     NEW:
> >>                          For each sibling set, the server determines
> >> which nodes are
> >>
> >>             included
> >>
> >>                          (or potentially included) in the filter output,
> >> and which
> >>
> >>             sibling
> >>
> >>                          subtrees are excluded (pruned) from the filter
> >> output.  The
> >>
> >>             server
> >>
> >>                          first determines which types of nodes are
> >> present in the sibling
> >>
> >>             set
> >>
> >>                          and processes the nodes according to the rules
> >> for their type.
> >>
> >>             If
> >>
> >>                          any nodes in the sibling set are selected, then
> >> the process is
> >>                          recursively applied to the sibling sets of each
> >> selected node.
> >>
> >>             The
> >>
> >>                          algorithm continues until all sibling sets in
> >> all subtrees
> >>
> >>             specified
> >>
> >>                          in the filter have been processed. If any
> >> sibling nodes of a
> >>
> >>             node
> >>
> >>                          are instance identifier components for a
> >> conceptual data
> >>
> >>             structure
> >>
> >>                          (e.g., list key leaf), then they MUST be
> >> included in the filter
> >>
> >>                 output.
> >>
> >>                     Regards, Benoit
> >>
> >>
> >>                     I agree that MUST would be better. But I don't think
> >> we can/should
> >>                     do thar change in an errata.
> >>
> >>                     On 20 juni 2014 13:57:24 PDT, Randy Presuhn
> >>
> >>                 <randy_presuhn@mindspring.com <mailto:randy_presuhn@
> >> mindspring.com>>
> >>
> >>                     wrote:
> >>
> >>
> >>                     Hi -
> >>
> >>
> >>                     From: Benoit Claise <bclaise@cisco.com <mailto:
> >> bclaise@cisco.com>>
> >>                     Sent: Jun 20, 2014 2:01 AM
> >>
> >>
> >>                     ...
> >>
> >>
> >>                     Subject: Re: [Netconf] [Technical Errata Reported]
> >> RFC6241 (3980)
> >>
> >>                     One last check (till mid next week) for everybody in
> >> the WG before
> >>
> >>             I
> >>
> >>                     apply this change below to the errata, and accept it.
> >>
> >>
> >>
> >>                     "SHOULD" is no better than "MAY" or "OPTIONAL" from an
> >>                     interoperability perspective.  "MUST" would be much
> >> simpler
> >>                     for all concerned.
> >>
> >>                     Randy
> >>
> >>                     _________________________________________________
> >>                     Netconf mailing list
> >>                     Netconf@ietf.org <mailto:Netconf@ietf.org>
> >>                     https://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>
> >>
> >>                     /martin
> >>                     .
> >>
> >>
> >>                     _________________________________________________
> >>                     Netconf mailing list
> >>                     Netconf@ietf.org <mailto:Netconf@ietf.org>
> >>                     https://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>                 ------------------------------
> >> __--------------------------
> >>                 ZTE Information Security Notice: The information
> >> contained in this
> >>
> >>             mail (and any attachment transmitted herewith) is privileged
> >> and
> >>             confidential and is intended for the exclusive use of the
> >> addressee(s).
> >>             If you are not an intended recipient, any disclosure,
> >> reproduction,
> >>             distribution or other dissemination or use of the information
> >> contained
> >>             is strictly prohibited.  If you have received this mail in
> >> error,
> >>             please delete it and notify us immediately.
> >>
> >>                 ------------------------------
> >> __--------------------------
> >>                 ZTE Information Security Notice: The information
> >> contained in this
> >>
> >>             mail (and any attachment transmitted herewith) is privileged
> >> and
> >>             confidential and is intended for the exclusive use of the
> >> addressee(s).
> >>             If you are not an intended recipient, any disclosure,
> >> reproduction,
> >>             distribution or other dissemination or use of the information
> >> contained
> >>             is strictly prohibited.  If you have received this mail in
> >> error,
> >>             please delete it and notify us immediately.
> >>
> >>                 _________________________________________________
> >>                 Netconf mailing list
> >>                 Netconf@ietf.org <mailto:Netconf@ietf.org>
> >>                 https://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>
> >>             --
> >>             Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>             Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen,
> >> Germany
> >>             Fax:   +49 421 200 3103         <
> >> http://www.jacobs-university.__de/ <http://www.jacobs-university.de/>>
> >>
> >>             _________________________________________________
> >>             Netconf mailing list
> >>             Netconf@ietf.org <mailto:Netconf@ietf.org>
> >>             https://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>
> >>         /martin
> >>
> >>         _________________________________________________
> >>         Netconf mailing list
> >>         Netconf@ietf.org <mailto:Netconf@ietf.org>
> >>         https://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>     _________________________________________________
> >>     Netconf mailing list
> >>     Netconf@ietf.org <mailto:Netconf@ietf.org>
> >>     https://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>
> _______________________________________________
> 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

--------------010009030705040905090807-- From nobody Mon Sep 22 05:44:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CBC1A1ABE for ; Mon, 22 Sep 2014 05:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbELCMCRucXI for ; Mon, 22 Sep 2014 05:44:27 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913D81A1ABA for ; Mon, 22 Sep 2014 05:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7164; q=dns/txt; s=iport; t=1411389866; x=1412599466; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=/9gkHZSGHMbBnubrBS0O7SWqvFAOOoq02oo1t1C7Xbk=; b=WDdPqYmWRFsTVrAw3CzWOZytnzB8a9RtsEzK8peWwogng9KItMe4r6UI Rz4ni9xiLWQ3LuLav6z7xp4m85AMwprpDy1OWl2QIDl3STYjbDjjcdTuK 5pyd8/7kCQxI5unW/PaFQaoMjP3gYgx8+B53CB+SC65WMLI0utJlgQTLh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgEAKoYIFStJssW/2dsb2JhbABGGoNhV8pUh00BgSEBeYQDAQEBBHgNBBsBAwECChYPCQMCAQIBDywCCAYNBgIBAYgmAxENNrwlDYcvAReMToEJgh4YBoRFBYYglGaCEIdMh0GGRYF5gWo7LwETgjYBAQE X-IronPort-AV: E=Sophos;i="5.04,571,1406592000"; d="scan'208,217";a="181329065" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 22 Sep 2014 12:44:24 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8MCiOxF021295 for ; Mon, 22 Sep 2014 12:44:24 GMT Message-ID: <542019A8.3040705@cisco.com> Date: Mon, 22 Sep 2014 14:44:24 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETCONF References: <20140730151636.1C5E218001B@rfc-editor.org> In-Reply-To: <20140730151636.1C5E218001B@rfc-editor.org> X-Forwarded-Message-Id: <20140730151636.1C5E218001B@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------070905030508090605010207" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8GspkBAZAdzfCA5pPBc3vg0vWpY Subject: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:44:29 -0000 This is a multi-part message in MIME format. --------------070905030508090605010207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Should this reported technical errata be accepted? Regards, Beonit -------- Original Message -------- Subject: [Technical Errata Reported] RFC6241 (4066) Date: Wed, 30 Jul 2014 08:16:36 -0700 From: RFC Errata System To: , , , , , , , CC: , , The following errata report has been submitted for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4066 -------------------------------------- Type: Technical Reported by: Andy Bierman Section: 7.2 Original Text ------------- If the "operation" attribute is not specified, the configuration is merged into the configuration datastore. Corrected Text -------------- If the "operation" attribute is not specified, then the operation applied to the parent data node of the configuration is used. If no parent data node is available, then the "default-operation" value is used. Notes ----- sentence in para 6 is not correct. The default-operation value is used, not the value "merge". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG . --------------070905030508090605010207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Should this reported technical errata be accepted?

Regards, Beonit


-------- Original Message --------
Subject: [Technical Errata Reported] RFC6241 (4066)
Date: Wed, 30 Jul 2014 08:16:36 -0700
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: <rob.enns@gmail.com>, <mbj@tail-f.com>, <j.schoenwaelder@jacobs-university.de>, <andy@yumaworks.com>, <bclaise@cisco.com>, <joelja@bogus.com>, <bertietf@bwijnen.net>, <mehmet.ersue@nsn.com>
CC: <andy@yumaworks.com>, <netconf@ietf.org>, <rfc-editor@rfc-editor.org> 


The following errata report has been submitted for RFC6241,
"Network Configuration Protocol (NETCONF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4066

--------------------------------------
Type: Technical
Reported by: Andy Bierman <andy@yumaworks.com>

Section: 7.2

Original Text
-------------
If the "operation" attribute is not specified, the
configuration is merged into the configuration datastore.

Corrected Text
--------------
If the "operation" attribute is not specified, then the operation
applied to the parent data node of the configuration is used.
If no parent data node is available, then the "default-operation"
value is used.

Notes
-----
sentence in para 6 is not correct.
The default-operation value is used, not the value "merge".

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6241 (draft-ietf-netconf-4741bis-10)
--------------------------------------
Title               : Network Configuration Protocol (NETCONF)
Publication Date    : June 2011
Author(s)           : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

.


--------------070905030508090605010207-- From nobody Mon Sep 22 05:54:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDCD1A00B7 for ; Mon, 22 Sep 2014 05:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt0-YxkeMxuP for ; Mon, 22 Sep 2014 05:54:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2683A1A1AC0 for ; Mon, 22 Sep 2014 05:54:42 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 175AF1280457; Mon, 22 Sep 2014 14:54:41 +0200 (CEST) Date: Mon, 22 Sep 2014 14:54:40 +0200 (CEST) Message-Id: <20140922.145440.10915271733439530.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <542019A8.3040705@cisco.com> References: <20140730151636.1C5E218001B@rfc-editor.org> <542019A8.3040705@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hrlwuwiq9NMr1SVz5TMz7fwsgpg Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:54:46 -0000 Benoit Claise wrote: > Dear all, > > Should this reported technical errata be accepted? I suggested a variant of the proposed text in: http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html /martin > > Regards, Beonit > > > -------- Original Message -------- > Subject: [Technical Errata Reported] RFC6241 (4066) > Date: Wed, 30 Jul 2014 08:16:36 -0700 > From: RFC Errata System > To: , , > , , > , , , > > CC: , , > > > > > The following errata report has been submitted for RFC6241, > "Network Configuration Protocol (NETCONF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4066 > > -------------------------------------- > Type: Technical > Reported by: Andy Bierman > > Section: 7.2 > > Original Text > ------------- > If the "operation" attribute is not specified, the > configuration is merged into the configuration datastore. > > Corrected Text > -------------- > If the "operation" attribute is not specified, then the operation > applied to the parent data node of the configuration is used. > If no parent data node is available, then the "default-operation" > value is used. > > Notes > ----- > sentence in para 6 is not correct. > The default-operation value is used, not the value "merge". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6241 (draft-ietf-netconf-4741bis-10) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) > Publication Date : June 2011 > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., > A. Bierman, Ed. > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > . > > > From nobody Mon Sep 22 05:57:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A7B1A00B7 for ; Mon, 22 Sep 2014 05:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoFeUZZcZItx for ; Mon, 22 Sep 2014 05:57:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D7D1A1AC0 for ; Mon, 22 Sep 2014 05:57:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C2CAC764; Mon, 22 Sep 2014 14:57:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qrepcFYcTmtN; Mon, 22 Sep 2014 14:57:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 14:57:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31B1620036; Mon, 22 Sep 2014 14:57: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 9rtAN0s_6fgk; Mon, 22 Sep 2014 14:57:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B6BC20035; Mon, 22 Sep 2014 14:57:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 38FD12E85181; Mon, 22 Sep 2014 14:57:37 +0200 (CEST) Date: Mon, 22 Sep 2014 14:57:37 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140922125737.GA18011@elstar.local> Mail-Followup-To: Martin Bjorklund , bclaise@cisco.com, netconf@ietf.org References: <20140730151636.1C5E218001B@rfc-editor.org> <542019A8.3040705@cisco.com> <20140922.145440.10915271733439530.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140922.145440.10915271733439530.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FDdJx5l5wDeR9B3Ek8UnfM1FC1E Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:57:43 -0000 On Mon, Sep 22, 2014 at 02:54:40PM +0200, Martin Bjorklund wrote: > Benoit Claise wrote: > > Dear all, > > > > Should this reported technical errata be accepted? > > I suggested a variant of the proposed text in: > > http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html > I like Martin's text. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 22 06:00:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906541A1AC6 for ; Mon, 22 Sep 2014 06:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8hENwCDnPJl for ; Mon, 22 Sep 2014 06:00:38 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FA51A00B7 for ; Mon, 22 Sep 2014 06:00:37 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XW3EG-0005cW-Bv; Mon, 22 Sep 2014 15:00:33 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-6.fritz.box) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XW3EG-0003ob-7K; Mon, 22 Sep 2014 15:00:32 +0200 Message-ID: <54201D6F.10902@bwijnen.net> Date: Mon, 22 Sep 2014 15:00:31 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Martin Bjorklund , bclaise@cisco.com, netconf@ietf.org References: <20140730151636.1C5E218001B@rfc-editor.org> <542019A8.3040705@cisco.com> <20140922.145440.10915271733439530.mbj@tail-f.com> <20140922125737.GA18011@elstar.local> In-Reply-To: <20140922125737.GA18011@elstar.local> Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd4c44cd7752841c14f3d0a8c5471a65945 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ajrdDGOCUCZouaHansYIrGrT6B8 Subject: Re: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:00:45 -0000 On 22/09/14 14:57, Juergen Schoenwaelder wrote: > On Mon, Sep 22, 2014 at 02:54:40PM +0200, Martin Bjorklund wrote: >> Benoit Claise wrote: >>> Dear all, >>> >>> Should this reported technical errata be accepted? >> >> I suggested a variant of the proposed text in: >> >> http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html >> > > I like Martin's text. same here, Bert > > /js > From nobody Mon Sep 22 07:05:46 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0ED1A1B0D; Mon, 22 Sep 2014 07:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.688 X-Spam-Level: X-Spam-Status: No, score=-102.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpwYhENzGwCX; Mon, 22 Sep 2014 07:05:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC561A1BE9; Mon, 22 Sep 2014 06:49:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 92E2B180015; Mon, 22 Sep 2014 06:49:42 -0700 (PDT) To: andy@yumaworks.com, rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140922134942.92E2B180015@rfc-editor.org> Date: Mon, 22 Sep 2014 06:49:42 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/d5haa0Fv1RY5dqWlIhXN6M1ZUxk Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Verified] RFC6241 (4066) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:05:36 -0000 The following errata report has been verified for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4066 -------------------------------------- Status: Verified Type: Technical Reported by: Andy Bierman Date Reported: 2014-07-30 Verified by: Benoit Claise (IESG) Section: 7.2 Original Text ------------- If the "operation" attribute is not specified, the configuration is merged into the configuration datastore. Corrected Text -------------- If the "operation" attribute is not specified, then the operation applied to the parent data node of the configuration is used. If no parent data node is available, then the value of the parameter is used. If the parameter is not given, the configuration is merged into the configuration datastore. Notes ----- sentence in para 6 is not correct. The default-operation value is used, not the value "merge". Discussion on the NETCONF mailing list. See http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Sep 22 09:17:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D091A1A93 for ; Mon, 22 Sep 2014 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgH7UrHRB0R7 for ; Mon, 22 Sep 2014 09:17:20 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B401A1B5B for ; Mon, 22 Sep 2014 09:17:19 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so346615qaq.10 for ; Mon, 22 Sep 2014 09:17:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j43rmIvf6vmoNJitCFFRBPQ68gtAVm/nDpMrpVLPDus=; b=jdqHEkaVL1SHedZCynl6/YIbbAO4GfR4k99stci5uRbGD7UIxAttOT7pxl85ivaSZI zVz4RXm/pDkdGHoxuQCdExEmPAm3V4cYiMHKotlkqyNzsgmnxf7bYZEpFMf9RJ6K2dPG WkDeJFEnMIR5YIXbSnVsKFkEntA7oSQY6ZhHc4GQ/gpPA8r2RYK4ANXrCxEDOfNYdN9R NWUAU/zrDp2d4lzUbtcj62nJ+2BrqXR8F1WJdEAcA7T5N+yp/Os30WXYAdzztLL9F36l xQANlf3bAQtx/xY5c/hVlxrK8wCe3AL7B8//YsHOQxf21oHXKdPvQd720jU2Fe23jDro DA4g== X-Gm-Message-State: ALoCoQn4QnKn4roPOBJBXzuKenFulkZ0e1qPsR1e2anWVYOsZpoMgC7/XzUj1LB+GFQwMPWFT0xY MIME-Version: 1.0 X-Received: by 10.224.60.129 with SMTP id p1mr3980623qah.99.1411402638878; Mon, 22 Sep 2014 09:17:18 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 22 Sep 2014 09:17:18 -0700 (PDT) In-Reply-To: <541ADF7A.8020607@ripe.net> References: <541ADF7A.8020607@ripe.net> Date: Mon, 22 Sep 2014 09:17:18 -0700 Message-ID: From: Andy Bierman To: Bert Wijnen Content-Type: multipart/mixed; boundary=001a11c3d8d4ed3dc50503a9c8f2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/kx8kgy3_zXK8ROn63YeFwE7D6Ms Cc: Netconf Subject: Re: [Netconf] Details about our upcoming Bi-weekly NETCONF Virtual Interim on 22 Sept 2014, 17:00-19:00 UTC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 16:17:23 -0000 --001a11c3d8d4ed3dc50503a9c8f2 Content-Type: multipart/alternative; boundary=001a11c3d8d4ed3dbd0503a9c8f0 --001a11c3d8d4ed3dbd0503a9c8f0 Content-Type: text/plain; charset=ISO-8859-1 Hi, Here are the slides for the RESTCONF portion of the meeting. I think it will take 10 minutes, not 60. On Thu, Sep 18, 2014 at 6:34 AM, Bert Wijnen wrote: > NETCONF participants > > This coming Monday 22 Sept, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time) > we will have our second NETCONF virtual interim meeting. > > Agenda > > - 5 min chair intro - recording the meeting, scribe, agenda bashing > > - 60 min restconf open issues (Andy) > See https://github.com/netconf-wg/restconf/issues > note that for issue https://github.com/netconf-wg/restconf/issues/7 > we have a WG concensus call outstanding that ends today (Sept 18th). > If you have not yet expressed your opinion, > please do so ASAP today (any timezone). > See consensus the formal call on wglist: > http://www.ietf.org/mail-archive/web/netconf/current/msg09218.html > > - 40 min netconf-server model open issues (Kent) > see: https://github.com/netconf-wg/server-model/issues > > - 15 min AOB other topics > > If you want specific topics on the agenda, please let us (WG Chairs) know > ASAP. > > I believe the webex info for the meeting is this: > > To JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=m9f461ea30a23d08e29f45c40c0814 > e7d > Meeting number: 649 602 794 > Meeting password: restconf > > JOIN BY PHONE > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 649 602 794 > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > In case you want to check, proceedings (including ptr to the recording) of > our first > virtual meeting on 8 Sept are here: > http://www.ietf.org/proceedings/interim/2014/09/ > 08/netconf/minutes/minutes-interim-2014-netconf-1 > > > Bert and Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c3d8d4ed3dbd0503a9c8f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Here are the slides for the RESTCON= F portion of the meeting.
I think it will take 10 minutes, not 60= .



<= div class=3D"gmail_quote">On Thu, Sep 18, 2014 at 6:34 AM, Bert Wijnen <bwi= jnen@ripe.net> wrote:
NETCO= NF participants

This coming Monday 22 Sept, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time)<= br> we will have our second NETCONF virtual interim meeting.

Agenda

- 5 min chair intro - recording the meeting, scribe, agenda bashing

- 60 min restconf open issues (Andy)
=A0 See https://github.com/netconf-wg/restconf/issues
=A0 note that for issue https://github.com/netconf-wg/restconf/is= sues/7
=A0 we have a WG concensus call outstanding that ends today (Sept 18th). =A0 If you have not yet expressed your opinion,
=A0 please do so ASAP today (any timezone).
=A0 See consensus the formal call on wglist:
=A0 =A0 =A0http://www.ietf.org/mail-archive/we= b/netconf/current/msg09218.html

- 40 min netconf-server model open issues=A0 (Kent)
=A0 see: https://github.com/netconf-wg/server-model/issues<= br>
- 15 min AOB other topics

If you want specific topics on the agenda, please let us (WG Chairs) know A= SAP.

I believe the webex info for the meeting is this:

=A0 =A0To JOIN WEBEX MEETING
=A0 =A0https://ietf.webex.com/ietf/j.p= hp?MTID=3Dm9f461ea30a23d08e29f45c40c0814e7d
=A0 =A0Meeting number: 649 602 794
=A0 =A0Meeting password: restconf

=A0 =A0JOIN BY PHONE
=A0 =A01-650-479-3208 Call-in toll number (US/Canada)
=A0 =A0Access code: 649 602 794

=A0 =A0Can't join the meeting? Contact support here:
=A0 =A0https:/= /ietf.webex.com/ietf/mc

In case you want to check, proceedings (including ptr to the recording) of = our first
virtual meeting on 8 Sept are here:
=A0 =A0 http://www.iet= f.org/proceedings/interim/2014/09/08/netconf/minutes/minutes-= interim-2014-netconf-1


Bert and Mehmet

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

--001a11c3d8d4ed3dbd0503a9c8f0-- --001a11c3d8d4ed3dc50503a9c8f2 Content-Type: application/pdf; name="restconf_slides_2014-09-22.pdf" Content-Disposition: attachment; filename="restconf_slides_2014-09-22.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i0e0oe5j0 JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nJWRy2rDMBBF9/qKWQcsz+hhWWAMcewUujMVdFGya5NSkpa4i/5+R6O0 hT4WRTC60tx7JCTUBG/qDAgVagMhWt2Aj5718qBuV/CsCPJYDgpzA04qm4LoIxQt2eMHJIvSfVT7 lcDzYMKQlI3sd9mW7qHeMtpB2ndIfXpSU1LzD7/X/j8Bg15H8NhoWxIGXE7ccQRNX1GHVqpDNmHA FiOu+8p0OOAgnQ2OrHbp+ld+bPjNTBv5lAvfmsKfhLIlzDORrCIZsjjKjiPf89QU218HWHL8B8a7 b3gKAmmlRqlybRqopc1FFU/4Ys/w+X9nqKerGw+HV6jT4mB8gVm9A3AMbe0KZW5kc3RyZWFtCmVu ZG9iagoKMyAwIG9iagoyNTgKZW5kb2JqCgo0IDAgb2JqCjw8L1R5cGUvWE9iamVjdAovU3VidHlw ZS9Gb3JtCi9CQm94WyAzOTcgOCAzOTcgNTg3LjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCA4Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnicAwAAAAABCmVuZHN0cmVhbQplbmRvYmoKCjUgMCBvYmoKPDwvQ0EgMC41CiAgIC9jYSAw LjUKPj4KZW5kb2JqCgo3IDAgb2JqCjw8L0xlbmd0aCA4IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJydVslq3EAQvesr+myYcVd1t1oCIfDMSIHcTAZyMLkldghOgp1Dfj+1tSR7FnvC gNxLLa9eLW2/Bve3enLerfwaXW7DunapTbR+/lZ9vnK/KnD8e36oPF+4nxULZVk/Ol2L7mMxwgu9 /V7dX4lx/pGFzb4KLclHFtt/ddcjmY5uf9956Pc/qmFf3R7Ip3W6RAEaWEeXfL0OqoEussZdBzsY YOxX0Pmdb3nnRwjo+xV2MPTQQYTgRwTfIkKNHur+y/7jMScxE00xJGJPfAQHgddncGUgQBEbCt9g IVPBwHxWUAwEAwHxLR8QGD3yvMPICDf9KhBO/lIQG7nQ6yQqFJKoLITpIk4XEi/LyUbsaMy8N7dm SSS834q9WqGQxEtlPajlbmT91PktZtXVc3E4qZ8gVNjhXIcDdjQ+dSruiGKmq+GlYFXc2EAjftV7 xtPOWqqmkCZnlL2W15Q9PFVVnuAlnMDVmrggoHbiXpLIIYNwE23N8EORuelXWeCGDjd+M9/oGWsk IrsPzLgc+bHUBnBtkFkT9bM7dXG6WoGKMznK/Bxwu27Od1GIVOEBEvVSiRmFozsmaVV3uJVvJrT0 l4FQxEHAjgpTz3QHwFJ0FpWxosXQk+lxios8c0PWd7NV5petUlsOhYai6UUOPZU9n236CUS5SOLO HCzEuNjTC89skTybF5BGWoTFnSLBlWupSlMCMzGrKoBJwJ8uSk0SNrlMuvcmCRtcdM2UJHFo8Wct R0WraUFfoHE7BUuqaWlrJ/lqb2dZN9rysDtGmtYhn5ufI6yZr2Zh/xWTluatYdQkW5K45qe7WuN7 UQZWeCcpVr5SLmN7ydfFLBzG8sbEQQzr9qKJg9Sy+fXMSUwY2FzHwcLXSZFsUuh04HETbF7oqOIM 5cWQAjuxmRLtoaETTNiI6UZk8/zFwR6nzcI6MA/EfeJ9tqmlQDGcyYgUPTTNTMz7ih6aeCyJNzo3 5jkjHCWdJTajohKhd9qk+m6N1hF6obW2079vtS3QY9JcGEE6xI+jUL8rr8eiBbTBokHd6DjjGmh5 mg6LseOX85afjNAtJzFZNI5Ku84TSquqnaY6hW8ebHCKxn+NjOVb4AvhM2qJ82zbAk4ULzOeF0jO Ygj+ctTl2TBWhoM37kh53LrpH+Yndz18+ATePfxx1/vn1u1+u9vqH7vLcR8KZW5kc3RyZWFtCmVu ZG9iagoKOCAwIG9iago4OTAKZW5kb2JqCgo5IDAgb2JqCjw8L1R5cGUvWE9iamVjdAovU3VidHlw ZS9Gb3JtCi9CQm94WyAzOTcgOCAzOTcgNTg3LjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0IvSyB0cnVlPj4KL0xlbmd0aCA4Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCnicAwAAAAABCmVuZHN0cmVhbQplbmRvYmoKCjEwIDAgb2JqCjw8L0NBIDAuNQogICAvY2Eg MC41Cj4+CmVuZG9iagoKMTIgMCBvYmoKPDwvTGVuZ3RoIDEzIDAgUi9GaWx0ZXIvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJylVE1r3DAQvftX6BxYZz4kWwIj6K7tQm9LDT2U3tqklKQl20P/fudJ3k02 HwulGGyN5o3mzZuRqWX3p3lw5DbUiuuTtp0LKdj68K35dOV+NuzwHG4bgsPdNwD1ZX3n6rrE3h0P waJ6vzc3V+VwPHbCdmk0Gd4Dtnx117Md7d1yMxDn5UczLc3+BT604Z8CVFygrtWKF+eB/zxQT1Pe 8ECBx/xl+fBarI+Wxqseg9WStZfTUZtSYi477Hqo4aWz93LfILuxQXaRrANPNNKWEvVm0EQBeyOl LAPN5hphEyXu4J/zxvYT7cyQngnOTqigLGZju2QnIpon8ZnjIJ4V6MBqUHuYzf9Gsa8w10RtfMbc CFcGxmFibwQKXybJfiAljw8qoa7WFTMP8mbWKCax+h4KVYmFi8ByQeCY4kqTCZHqPVpUeUqsCs9Z oATtpINyEBL9Xi01VspQjcbVQXgXBfE1mB94thoBNbnNXF0eFfkSEyTCoaJqKlRDaghtcboW3JoB ZOjRNphROdsJhVztEyKYxpP/Qt9eCMLSpmeC2FD0VqsNVqnsKIevVVtRZbyqVXNKQdJYCj7VDtjI HW1NqrkWWX0aAHtXYL1dEAChykkCoUG7HMlmHSPTowX9k+KTxvV7eVzEhjP8x7iYDvabO1eHQH6d Fl7V8egHRqEMe+npLPw4CGtnRtnV23fW6fHUY4RVw0RhUC3CwPa4IEW27qgIxaeXZe9Ov9sHdz29 /8jB3f5218vBfnvjL7dv/gJ6pDWFCmVuZHN0cmVhbQplbmRvYmoKCjEzIDAgb2JqCjU3OQplbmRv YmoKCjE0IDAgb2JqCjw8L1R5cGUvWE9iamVjdAovU3VidHlwZS9Gb3JtCi9CQm94WyAzOTcgOCAz OTcgNTg3LjEgXQovR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSyB0cnVlPj4K L0xlbmd0aCA4Ci9GaWx0ZXIvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnicAwAAAAABCmVuZHN0cmVh bQplbmRvYmoKCjE1IDAgb2JqCjw8L0NBIDAuNQogICAvY2EgMC41Cj4+CmVuZG9iagoKMTcgMCBv YmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSA1ODI4Pj4Kc3Ry ZWFtCnic5VdtbFvVGX7Pvf5q08ZOKVGQS32825RkTuy0AZp2oXES20malDgfZnbKWt/YN7FLYlv2 TUo7qmZIQOXS0cFWYFRim7QNbUi9btmUTh0NGtM0aQz2Yz8YBCKNfzRr161oAtrsPcfXaRJakMak /dhNfO/zPu/nec859rlqdkKBNTAFInhj43JmPSGA1x8AyLrYpEoX2rwU8RyAUDmSGR2vaXznbwDi vwDMxtGxgyO/+fNPawHKmE84ocjxlianB+UwyvcmkOi8ftCM8gmUNyXG1Yd9cNGA8isoW8bSMbkO 6hCWncebaVx+OKOaDjP96yjTlDyu7FZ++F2UP0Dznkw6p8Zh0wLA+gamz2SVzNWhZy0oB7E+FTkC vHwcERATl//PL+NxuB06jfeBFTL8vuwSX4Y72HPh4vL79Z6Fj/+bVViKj+fgJ/AKHIe34Ru6IgBB SMIEMkuv1+BPyLIrCEPwM8jfIuzLMI36ol0UnoLnb2EXhGfhLPxuWZYgjMM3sZZfwNtkC/wel0oa rhALfAt+i1GvILf7ZqGEcryNcDiyhH0HXhCOwS4B1ylWgRrBI9jgdThF9mJkFcd5fHHEzZ8J+gQc xvsAJGASMb+M9336F1i18A8c1WHYBY9CK4wt8ThPXhRX4/wNwovY09c45ykpzZ3ifuGXgnDtGRS+ A6P4kQmOXTgutoLPWEFw93n9kXBocKC/L9h7/+6e7l1dnR0Bv6+9rdXbsvO+5q/t2N607d57tjR4 3PV1NXdtrt4kfcXpqFpfYbOWry1bvcpiNhkNokCgzi8FolTbHNUMm6XOznomSzIS8hIiqlGkAstt NBrlZnS5pRctR1ZYeouW3kVLYqPN0FxfR/0S1d7wSXSaDPWFER/3SRGqzXO8m2PDZi6sRcHpRA/q r0r4qEai1K8FJhN5f9SH8Qplq9uldmV1fR0UVpchLEOk1UiZAqnZSTgQavw7CgJY1rK0mljtl+Na sC/s99mdzkh9XZdWLvm4Ctp5SM3Urpl5SJpkpcMxWqibyT85bYPhqGtNXIrLD4Y1UUbfvOjP55/Q KlxareTTag99UIUjV7Q6yefXXCxqd/9inu4bKYlmrLZJNH8VcDjS/MXljKwzpmrbVWAwgO3N5wMS DeSjeXl6YWpYojYpX1izJp/xY4chGEav6YVfHbNrgScjmi2aIDv0wQb6u7Xb+vaENaE6QBMyMvjf Ijmb7M6KSMkmeCs1YCOwHdhTp5MN/Ni0F4ZR0Kb6wkWZwrD9DHg9rogmRJlmpqS5PcQ0UyXNontU wtnsHgjnNUN1V1zyY4+PydrUMK6n/WwqJJtW/pHdKeXXVdDtngi3pVhVVzxJNeNmbAt6LXXAlcJc 8jYulH9UfMzbMcHminV0u4RhWBy/5I/q/5OJKgxA6+u0Tldx6gfDmteHwCvrc+QvNHjQQ47iFCV9 fPo0j5TR1ktti/PJyvInB8LcRXfT1rdrEI3pXprH72OZqT8f9RVLYLGkvvA5aFyYK9xN7Wcb4W6I +JhxZTuuq83+fDg+ojmi9jjutBEatjs1bwQnOCKFlQhbaNih2jlM5+QZNaF9MNw9IHX3DYWb9EKK ChbOUO1fEUYK24thcMlplmoLDQt2MYKGNiRoAIHU1ox3zVxtwY8NG85ZtlTbmmmY2KFkjWVotdSv +HQ7Ji8LamTLqb2zFM3ERIzT3ml3RpzFq75OQDXVE6OHhTW1s6QSq/GbADkBw3CK9bKKrXkalhQp IiWo5g2G2dhYe3iX9WbwnutzNbhMWtIsbBM4UV0SWDO1gMu+tLlaB5cXxc4V6q6SmuYtUvdAngWX 9ICAlXdpwJawt6nCznc/289SQMZNjDua7+d8wetleznBtm1e6ornpYFwM7fGb5DD9kMs1zroJt2D bfV1+GXWVpDI0b6ClxwdGAqfs+GR6uhg+IxAhPZoW6SwCXXhcxR/KzgrMJaRTKBMYJH6UbBwe/s5 L8AU1xo4weXYNAHOWUocgdi0UORsJU5AzlDkvJxjF85SVQJ7jN/ffhpn8/NIJJGPRtgah0rsCP4T jUg7sTvSzgIRTGu01ZLSppVJbYxvYXxLkTcx3owrg1SS+rpDeZtfulpVz3+6wYe3uDGEJ2AzuAsE PM1nzAbL/NaCyfhu8xlRQAgFkdFGRp8xm1Z92nyGML6xwllR7axw+gR6fRN57nrCGPr45z7DG1A8 eZKKD5+59ug9+6zNV8FRPAP9MT+77EzKM7MDkqATqDU7r/vh64smK8+wgnARfLp58fhM+DhKMQSw 4VkAz0WGMtN2HBVjN5AHFuNEF2MStIzqWMDRZ3Qsgh0O6NiANk/r2Ajl8CMdm/AsqenYDIfggo4t sJ5s1/EqKCe7dVyGNexZPJ27SSn+WkiTH+u4HHYK6zE7MaxCaUbo1zEBKq7TsQDl4lYdi3Cv6NWx AW0mdWyEDeJJHZtgo3hGx2b4p/iWji1QY3hdx6tgg+GijsugyWjR8Rp40FiKvxbeM57ScTk8YjrU ns4czCZHEyqtidXSrQ0N22i/EqedslpHu1IxN20dG6PcIEezSk7JTipxN+3pavP3tw529d5Pkzk8 FqlZOa6My9mHaHpkuX9PcljJymoynaIDSjY50q+MTozJ2dZcTEnFlSytpystVsoPKNkcE7a4G7a5 G29oVxp/QSFY/WgypypZJJMpGnIPuGlQVpWUSuVUnA4uOvaOjCRjCidjSlaV0TitJrDU/RPZZC6e jLFsOffiCNrT2UxaL0lVJhW6W1ZVJZdOJVQ1s8PjOXDggFvWjWNo646lxz2fp1MPZpS4kkuOpnDk 7oQ6PtaDBaVyWPgEz4jVLO1aIJ3CyRkr2tTRnKJQFj6H8UeUOJaWyab3KzHVnc6Oeg4kH0p6ivGS qVHPjTAsip7ny3lDO6RxDx6ELL79jOLbgAoUaiAGtfjcCg34tw1RPygQx2cnyGhRh6gLUmjlRsTe EsbweSNCjksKPhV8TnJfZtmDXm3gx2itMIi4F+5HNsntZfyoaC2jrYLvSTLih5BL45vN5+XvQf9h nodpkmifQu0AZ5LoyzxH8W1vjEdsxVwxZFI8SxYt63ldnx/ji/QPcJRb1GzBuljf3NB4U98vivzl OlLs/SiPovLYRcskjx1CiwFuFeSerBcqz5biVoM3ydiLGUfQn3XuhmWMx1ZRLkZOI07oXd2PHc/y CuLcrzS2HGb+7BywNZjFVZhe0SVW3STPuZvzKl9TTJfgUgZ24K+OB3832J8bbZZHjulx3RyNo+V/ 6qfiDsnwPip8nkfRtjjnbh5zHNdXj96hFF/3rEMTS8ZY7M2t1lqAP4s7Z2xZHDaz7Ml8S9Xn9PpH eJ5i1zJ4T2PfFd5tN2dH+RiTOIdJREvrYzM2qnMrqynVsnw8/8vcYvEQseDEjDe5CquirxIz/mK3 8PsFYvBGyNw18uY1Qq+RI5+Q4Cdk6sqJK8LfL9c6Tl++cFnovbTv0ulLYsMlYr1ELDBvmw/OR+cz 8z+YN622XiRr4ENS8de5Jsf7jbOh9xrfDcEsaQ7OTs1qs+L0wox3aNZSFpglYuhdsdJhm6EzDTOZ mamZt2bmZi7PWKZePfGq8OvzHof1vOO84Djbe/bIWTH6ErG+5HhJCL4QfUE4cYpYTzlOeU6J33/e 7Xi+Y6Pj2ZN3OeZOXj4psPD3nFxbEdj3PXLk6aeeFjKPTz1+4nFx6rETjwmnJy9MCrlgrSOdcjlS HV913NFYFTI3iiGTuOBgnr7h6ppAdJ/XsQ+N9gw1OIY6ah23Na4LGbFYAxpaRYfYIvaKafEp8YJo tvQHNzr68DMXvBwUrL2OXk8vjnDOK3c7MdCuzK6pXWJXoNbR2dHksHY4Ojwdb3a833Gpw7Svg7yI /4HTgQsB0Ruo9QS8gY3OwIZOe6iy8faQrdEaEgiESCOEPNYFq2C17rMesYpWaAFhqpIYyTQ5URgc cLm6p80L+KZvCe7RyFGteoDdvX1DmumoBqGhPeECId+OPHb8OLTd2a1tHQhr0Tsj3VocgZeBKQS2 OwuV0BbJ5VQXu4jLhXAC7+CaQGpvrkiCq6QGV47kcpDLERfTcYgM5FyMZgzzIei5NwfsxrQubsVQ Lle199/GcCR/CmVuZHN0cmVhbQplbmRvYmoKCjE4IDAgb2JqCjMwODMKZW5kb2JqCgoxOSAwIG9i ago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0JBQUFBQStMaWJlcmF0aW9uU2VyaWYK L0ZsYWdzIDQKL0ZvbnRCQm94Wy0xNzYgLTMwMyAxMDA1IDk4MV0vSXRhbGljQW5nbGUgMAovQXNj ZW50IDg5MQovRGVzY2VudCAtMjE2Ci9DYXBIZWlnaHQgOTgxCi9TdGVtViA4MAovRm9udEZpbGUy IDE3IDAgUgo+PgplbmRvYmoKCjIwIDAgb2JqCjw8L0xlbmd0aCAyMjEvRmlsdGVyL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnicXZBBT8QgEIXv/Io57h420J6bJmbNJj3oGqs/gMK0ktiBTOmh/94pVk08 QPJ474M36Gv32FHI+oWj6zHDGMgzLnFlhzDgFEhVNfjg8qHK7mablBa235aMc0djbBqlX8VbMm9w evBxwLPSd/bIgSY4vV970f2a0ifOSBmMalvwOMo9TzY92xl1oS6dFzvk7SLIX+BtSwh10dV3FRc9 Lsk6ZEsTqsaYFprbrVVI/p93EMPoPixLspKkMbUp2eN0p/axftqAW5mlSZm9VNgfD4S/35Ni2qmy vgB9WW11CmVuZHN0cmVhbQplbmRvYmoKCjIxIDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1Ry dWVUeXBlL0Jhc2VGb250L0JBQUFBQStMaWJlcmF0aW9uU2VyaWYKL0ZpcnN0Q2hhciAwCi9MYXN0 Q2hhciAxCi9XaWR0aHNbMzY1IDI1MCBdCi9Gb250RGVzY3JpcHRvciAxOSAwIFIKL1RvVW5pY29k ZSAyMCAwIFIKPj4KZW5kb2JqCgoyMiAwIG9iago8PC9MZW5ndGggMjMgMCBSL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGgxIDI1MTY+PgpzdHJlYW0KeJzlVetvFFUUP3dmH6X03YrFBb3j8LSzfaFV koKbdrd0W9ouuy3O6AaZbqftkn1ld9tQIwEiKm4CidEQiARawBhj0LurMcT4QYN+wppoSDVGgx+a +EEw0cQPKqWeO50+JP0P3Nk793fOPef8zjkz9042PWZACRwDETyRuJ6qIUQAgK8ASFVkPEvD607b Ef+MusBwaiR+c1vhFwChEYcxEpsYvnjhg7MANhwwO2roQ6dypbhmfxHlllFUvDT3jBPlj1DeNBrP HqbwSQnK36NcEktG9AsQRmifxVtRXD+cqhY3EpRvo0wTetw48/XxXwEc6CMeTiUz2Ro4NA+w5gRf T6WNVG3dH1dRvoJyPQ6CF/+hPXFwWYD//e9NeB1eg6vgh0ugQQM8Dgo0w0HYBzJ4oQ0k+By+hG/g OlyBV+AMHIe3YBIYvAMeOAonyHlYL87Yn7a/C8/ZKxkoDKq72WMBlXWNawzkp2uZo07dpZm6Ixq9 yUh1fa2bEYX+wErq3ExQuoOqT9YkNxOVaC1lnoAqMY/mZjaFu0qy9IL6k2tac6GdOue6o7lkidnr VNYxrpkLmobx7Epp+Fk3cyj5R8lJZKcnw2EXAwzjVPKbTJVnSVWkVFXSnQ1utkahRzjJFxiGMnGz X6bMtqWLQUDNGTmdcvCUS5I0V86UggsSJyxeyK7CVSFhxLUK/dYsp0ShDcxZF1Yp3SN36IeoSocG F0Jwu1LOjNQ0R/fkOnQ5R3OySSfz4MyDllgfVzCPwQX0KTOZds3USpKLzuSwDejkx2wGrNwk06xc kemMRS5TtTvkkhjR1BwW5JdzMs35c7LOHRZc+ORmFfwxVGHelbwADqruKyDHJ1k/dHBlJdy1WsEi cq/ytnUNyTknowG11fUZrtQoH4KHeNraSPe1CoiAeefGAyq/B1V5ELOX21w4EbkNO+8JqgWg0B5p KxBKcGI0wtYbGxa5HlAYarEveHPzt1bAdxOEIfsAnkxOqM8TaGgtOG3ld5rzDvuPrQVRQAh5kavt XF1wOrbebS0Qrt9RKVVuliolr0DvbSJn743aB/5+z2ubBn5C3MLz5ahtEkphMxRQU8ec04szYWUN zDbD1k7jP19O6qCxSaJbt1Q82SLRB9dVOB2i+97vFycnL5JyUnr50qXLU5PCw5NTU1Nzs1NTPG8y f5fcsCWFA5h3Fe6iBiZiVFtD3m4GE6UnJJst888pcuMN86waPnfuwIZ98efLW/+ER4rMDTv919tT i5t3/i7PFruA5yMsHmbo59w/d3TFHif37XlRuA1eRxhu2dI8Au74MKRNKxHKrDgCygKs487ion8Z vL8Uq7AUl0AxSsTycsKnFhZRf93CNsTTFrZjb7+zsAP1s2hJbGsw0BD8ZmECNULQwgKUCcMWFlGf tbAN8UkL2+Eh4byFHaj/eFtkO21ubNxJQ2MJ2hONpJOZiUzWiGeoPxGpL+7v9AV91NvnC9Hevn7q U/2hfrrg09REu8ZiUSNBe/VBI1scCPrafV40bHXvXvYIDbS3+3zeZZ++WHQ8aqRppx6LJbmXv8dn uvQH/YG9PrqgsMx30B49OxrVM2ieyRixuJ5I9KWMRGgiPpiMBY2RsZieXlYso/1GOhNNJmhTY3N9 y7IatuE22447qBka8dqJKARjkMC5B6K4loYkZGACRxYMiONM8cRP4Eo9PoF+6AQfBHFQ3Fd9OIcQ 9SLqx9kHKtqGTLySpwkvCl3IE0MOw2TrBR0GEWcxasCM2I7Da0VsBTfsXpUjBANoyW259Wo8fSbL uMmURrkTmWJ4JZe4/FirbwVLv6kLwF5Tu9Liv9F3mF3SMc4oRtfN3nSacwa5YtgtHWtLYAYps8oQ 9jGOVSZxLYiaEbMDOma1msVquv1mDRlkS5pda8I8mvFJtKxqLVp7fQRqVvuAXyPzLzNyCrpZUUDN E3Jay3fwLxOrwI9uTRDBMW0jfkHCqsZq6gD+BXw++YMKZW5kc3RyZWFtCmVuZG9iagoKMjMgMCBv YmoKMTQ4NAplbmRvYmoKCjI0IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUv REFBQUFBK09wZW5TeW1ib2wKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xNzkgLTMxMiAxMDgyIDkxNl0v SXRhbGljQW5nbGUgMAovQXNjZW50IDc5OQovRGVzY2VudCAtMjAwCi9DYXBIZWlnaHQgOTE2Ci9T dGVtViA4MAovRm9udEZpbGUyIDIyIDAgUgo+PgplbmRvYmoKCjI1IDAgb2JqCjw8L0xlbmd0aCAy MzAvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicXZBBa8QgEIXv/gqPu4dFY+lNAiXLQg7b lqb9AUYnqdCoTMwh/76ju22hB8XHe9/wHNH15z74LF4x2gEyn3xwCGvc0AIfYfaBNYo7b/Nd1dsu JjFB7LCvGZY+TFFrJt7IWzPu/PDk4ghHJl7QAfow88NHN5AetpS+YIGQuWRtyx1MNOdq0rNZQFTq 1Duyfd5PhPwF3vcEXFXd3KrY6GBNxgKaMAPTUrZcXy4tg+D+eepGjJP9NEjJhpLqsaOslqq8ZfNQ uXuiTChf/GnG7YZIreoeap1SxAf4XVWKqVD1fAMs5m/qCmVuZHN0cmVhbQplbmRvYmoKCjI2IDAg b2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0RBQUFBQStPcGVuU3lt Ym9sCi9GaXJzdENoYXIgMAovTGFzdENoYXIgMgovV2lkdGhzWzM2NSA3OTQgNTU1IF0KL0ZvbnRE ZXNjcmlwdG9yIDI0IDAgUgovVG9Vbmljb2RlIDI1IDAgUgo+PgplbmRvYmoKCjI3IDAgb2JqCjw8 L0xlbmd0aCAyOCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMjQ3MDQ+PgpzdHJlYW0K eJzdvAt4U8e1MDprZm9JW7KsLcmS35Zk+S1Z2lj4bdkbsIUcBzBggx8Y2+AH5mEb25AAaTAJEDAk OCklIZBAW5qGvBCEENIkxW05SfNqOGnac3LSFk5PmnPShMLJSfM3Bdv/zJbMI6S597v//b77fVe2 9p7HmjVr1p5Zr5mtoYF1nSgKDSOC5OVr2vtff+KRHQihtxEC0/L1Q/ZLsx9NpekLCGFrV3/3mizf h39BiPwNITXfvXpD151v/UcWQjraJLh6RWd7R3ThDB9CC1fTgoIVtGDnxD1qmj9C82kr1gzduSru oz/Q/C9p/r9W9y1vf+OLVX9HqC5E8+vXtN/ZX6yqJgjVU5zI3tu+pjP/c/wRzQcR0sj9fYND+1DO JEItjEZ7/0Bnf8HSX5bT/JOUvt/QMqB/7BNFkyqWx4TjVWqNoNVF6aMNotFkjrFYY+PiExKTklNs dkeqMy09IzMrO8flzvV4pWl5vun5BYVFxej/Jx/+bf5t9B1+C7KgDcr1pg9XgmLQHQhNfsZy168T i//fpUITvp1Er6Jj6PBNVTvQ3fT6zE1lZ9Av0NNK6gC6/1vQvoSeiqT2ov3ovn8ItxLdS/Ecof1f /7TR0g3oEdrzafRjOlFSwUd7XRWp/RC98c2o4N/hDfQQepJCPoRepNcDdOZtwp+jh/AC1Iv/hWxB 96CddIyHoAftofBt6Ag0o6W0NPxZijpR39eQjqBR9CO0ka7Cax9+y+T/IP3VH1PKd1I8+1APWntD iyfhK3YjNkr7c+gFpWzLVKU6SFbiUxiPf5dmHkTd9NsOH1A67yczUCVvhKMIyVWNDfV1CxfMr503 d87tNbdVB2cHqipnzZwhV5T7y0pLiosKC/KnSV5PrjsrMyM9zZnqsMXFGEVDtF6nFTRqFc8RDMhd 5Qy02UMZbSEuwxkM5rK8s50WtN9Q0Bay06LAzTAhe5sCZr8ZUqaQXV+DlMOQ8jVIEO1lqCzXba9y 2kPvVDrtp6FpfgNN31/pbLSHLirpOUqay1AyeppxOGgLe1Xcikp7CNrsVaHA+hUjVW2VFN9xnXaW c1anNteNjmt1NKmjqVCWs/84ZJWDksBZVSXHMdLoWbchkl7V3hGqnd9QVZnocDTmuqtD0c5KpQrN UlCGVLNCagWlvYeRjnbZj7vHRnafFtGyNldUh7OjfUlDiLTTtiOkamTkvpDRFcp2VoayN34UR0fe GXI7K6tCLoa1ZsG1fmqudwkhPl102kf+iuhwnBc/u7mkPVKiShf/ilgyQNk7MhJw2gMjbSPtpyeH lzntonPkeFTUSH8V5TCqbaCtTk/+ZFdiKLC7MSS2rYCSyGADC2pC5vnNDSGcHrCvaKcl9L/C6ShK dBgbp2Bq/1E1ooyg7KA8dTjYwHedltEymgkNz28I5+1oWeIJJHtdjSHcxmrGpmos9axmeKrmWvM2 J32aNQsbRkJcenWHs4ryeFd7aHgZnU8r2aNwiqHoLxMdzhGT0V7sbVRg7ZSq6o4ee4jPoGyhrW5s QGcKazIiKpnoL8O3i4m0gwyjyV7spGgYnipnVVvkf/2KOIrAnusOBV3hR1/XEJIraUJujzyjquOS l7Zob6OPqKdSeXwhr7M/FOOcee15MrKqehY2KE0izUIxs0KobXmkVchbVcl6tleNtFWGSWC4nPMb XkK+yQvHp9sTn/eh6aixkgFbZ9F5lVE10tDRFbK1JXbQldZlb0h0hORG+oAbnQ2djWyiUQ5lX6Dd OZQeQ3hWXUPNQmfN/KaGoggh4QqGjkuv+hoaZ0NiGA2dciFNusbegBNJIwUUaYE9QBPOmWX0GlKn a+hXpAxXStlUnVlmb4BENAVNyQhl26s6KyNwLH8TUp5Np1nBKWwqlqV4ZgUTHY2O8CfXjWm1PdIx baFhTA1OVZF0KgloGaZolCLGyzg25+0Nzk5no3OFPSTXNrCxMfYoXI4wQ+F55FnV3ZS7gVmUTchB q6cyjJmhgCvxRuaGZiv5a9ng16qrp6rtIxpnzcIRhtwZQYgo5dUhxKawXGRMVFY/W8/OQDtdxHRF K+t55Lgss7W8gi3bEWd1x4hzYUOZAk0lyHcSN7K+TKgGaupm5rqpMJt53Ak75h+XYcfCpoaXRGpS 7ahrOIEBz2qb2Xg8jdY1vGSnukIpxayUFbKMnWUYpgU0o1HgE1+SERpWajmlQMkvPw1IKdNMlQFa fhqHy8SpMkzLuHCZrJSxD31KcSsoj6n8rrJ3sOdzV+OKkbZGNseRlXKE/kMInOWUO87y44BVUSGt s3NmSOecycorWHlFuFzFytV0ZoAVct0bR8Qq51/jcpmyxKiSXjr4emoBq5HnOCBv2Qk1p7mYd1zF /67sBME0iY4TVsyz4hNqlXC17ASwcp/RYUx3GB2V2D6RBo9MrODr//50JfeOgpfapPwKanMZUQp6 Ty4/qoeRmEdjnoohe5NhXfK2ZPwcgscQ3IV2I3wbaqL2CCGHAQbgHngICF4OIAP4ANIBiHh6sl9e bKzuF4fFUZHUiR0inikCdoo+EYMoxpuadNQIN0pG2dhmHDUeNqqMsn3UfthO4kkT4kRO5oiaE3Gr N741vi9+TzwXH4/iWnnCIROqyKu4aCr2tlzMA+9Sem3xtviKvbTI6JsmtbS2tLS42IWllDtiFwc4 jE6jIy8FW2KisRrIdA92Ul7klWNu98RDE9Vn8MN3vnT3zMy6e5ph9G/uujtvnyiFdxbcOScdV4+/ yG8pXLFv6ax7Vs8Vx79PPpOXVtjG/5YdXKYYWYx33ATlnQ7NeUFN1ARpT0+OyelqXVCr1fNCE0Ii khFRI7seNK2beeB5gWsFIrSy4VxUhrP2IrQowzH6vC5TMRXf0yT6wCyOyPdJLvfqQyTv6q/Iw/yW gxNlj05YDrK+WyY/4/7G70MV6I9y775yqCyHJ0phewFsnQYPZ8FRB+gciQ6X44CDa0w+mox3GWGX GvZh4HAMxltLoK0Aeiyw3gg5TdnZqEkOmcE8Y1ho0siiOajRTG9CNtEm24jaZhbN1uCd5h3mR8yk 1AzTT09elr206I7p901/eDopmQ7m6by3tS8HGnOgJgdUOZCTxkW3tgmwQIBKAQTejCp89GlcVK4t dNzF9GnRf+VJ0oFfTBB/15JwMc97cZqkPDdoufED9Nk57WmZhSnER59cPn2ImR4+f3o59tEnG6v2 EGdqNH3CNJ3Cc3+rGv1w38RXE/+W9VJ0yfKHuuof6CquGHi8rfSONW2BrPmjZwfu/cnwnNhXovMX bVq4bNt8Z8XqB2pnbFnffbsLtjXuW+M//Vx6YdOMtOSy1plVi4oyrHqbq2T+qkDHniU52Qs21Dp8 tQVJzrL53or5BWkmA62sG1Dmg4fOh5N0PqjhfXlSEOAN4QPhK4G8LEC10ChsEHYKXCnlhhAv4C8F 2C+8IeBd4Xy10CNwr38gfCLgtwQ4JUA2bdBDG+wX+EQBVALEC9kKjv3CUYpV/QlFjD8U4KgA+wQo prA4VwDQCfDwKmGTsEt4WnhZ+FS4IqjrBFrqEkoZHVcEfESAUqGGgpA0AXYJByjYW7Sc3ywAnie0 ClgSwCBA97vCeQGHWJqV7hG4ywIcEo4JrJzrF6BVAFkAG/uvoAB9wiFacUlQIwEKLwkwLLcIo8I5 gfQJUCuAVwBacU6AYwKMCtAnbBawKNgFWagVuEkBLghwhiFso40OC1yFAHaFDDXhuWhoovJWHd2v PqwOqYldPazGarbQDLFJQbWdKgLEUREBdElVMNnQ8rarZa0LEuLEOeMf5bUujcyhtewzoHyWRnJr w2kmLq7lWiPQ1yCnWk6TgEmSfIcFn/vpRBK3nfvTlUTuTwcPhmXBisnP+A10PWaiZ+V5G6J3RuN1 +m16vCl9VzpemQF3pe1OwyvTYGUS1KuhiUBO8spkvD0WcmJXxmJeY9FgHlsw5ptrE9oS8LGEMwnY ngCGBEhIFdlgc9T6oChm27NhnhOcTtRq45BBNGDJIBv6DcOGMcM5g8pg0LZa6FqjS6plrXKFFiZX aIIOg66tlohghGt3iCwctq4KY6PpQkrLoAvMVJDmy+PYyiJxd770Hblqy8vrFty3ZpHjYEb/w2fW Pz0x+eyi5mOAjvw7eGa/EFPZtZP7e+3ec5s3//qROtfcVTPmztvRUbzmFxB16Eegfbkz9GxZXnMg h+qbdsqnf6F8MlNOrZZva06HhHQQ0mGBAywOUDugLhEsidAcC/Gx0GWEFVGAmmVDDMRkD9uzh7Nx SvMx7RkttmvBoLVpsTa+1cA5W5mEoQIV2EAvtlBpsjZharjXZAhWcTeNzmpSM21wAwP4f2k9OXH1 R89N/P25hiUngD/6JPDHl/xixuZXNt39080VMza/umnrmU2l+PUfTXw+tuL68Lpemfjyh5vP7a0N s2B//aL974f1A2+n8sCMzr6EtJMX5MwoV7BAG9BiZKepbFSMqhHRicmOoM5uSgru0z2hw9k6ACph n6eF9H5BzqcVj8JTgEkGgHkJqhTrxL0iuUD1KhIlURb7xTHxnKgSZQvIljHLOcsFC2dhU0aMNga1 6iVII2pkDVFrQClMdgWNIBCdTBM6pKGrxudzsW9Yq9K146WLYK1PkcStLS4mpl1ApbXLAdbYFLDQ VeCDjEwP5Bt9Rq5kPBoTTJ76A/47IZh7hgtNk7KbnVcb+C1XgtOm5SzPJQf/vvm6vnyQ8kNAPS8h PDl2Sh8XxFilYXSVqKOo1tEB34RUokpWEbVK0gHXegnAABXQB5vhEByDd+E8aDQgx6YEAXjUSgWE su6pJnUtbfmaMvW62KJlepQuXAt0E9PVv5whn3B/Gv/i8fF/ouqU0vQqJewuShNBG+UAaTIgYFE5 v4js6BwibaifzllFjdeiEOLV6BgPiD/Mh3iCeJGX+VolM8Zf5jV2fpTeCE+H83yRP6jccyXlfkov BoEwrV8BLsrStQOMzrVUvlBqmcL3GV89w29RGAWoePIzcoqrQYXoVbl+yLPVg/ssmy17LGSVFdIL IIeukOmgiAtdSmIKTqum8iAo282SGY+aD5tDZmIuHtZVa+X4FGqJuIPzkluTsT0ZktuKx4rxcDEU KxIlMydYUQxiMZjdfHatHaXBaNrlNJyWZheja/k2Xb8OD+tAp+OtdI5QgSJejNyo+gamv+lMWXtN e6+NqG8mVyBsfSlqO5Xq6sIUuK63Sf70Al+eNay1VRGlTU6V9v+wZ+nDA3NMh2JHh0vaA5meBesC M4a75V+/+fyvk34gSJX1no1DrjmrZ7ia6muKHOC6/Y75rmS553bb4vli5gxpWkWOzWzMqeqas/fA 3bticoqdhttq3MWZyaIu3umd2RCeg9sobz/lSlA62iBX7SOQ4MhxlDhIfHRA9ur26PAZHezRHdJN 6ogucxgC59MupWGUJqZJlDWcJi2UOZZ5LpOEMi9n4slM6M+ETMZLvTk2GK+qtVnNlihkYKYqU0Uu pkfYcw4zaCDhok8xb8AYkTdsBbHxOylTnEz2emgRlMROr6+Qu6uzTgLGysrHJKF8wcpA0z11mXTB LZi3ckZibv135uPBq8+m1syS1Ly7uDTGe3t+snvJaCf+Z2bXL6b2YRw3FyXRka6SPU3OlU7clLIy BdeTTuotVAtC4mzZlgyjdFpkDqej2TYjGKXw6JQhmVOcdEHyqDY9nbfXWkW+Nto6ZbReNBZ7wbWW 2eI3PXo2NmVoBWFVgo0REy0ZqLxgklYNMc7qgdp198c/bvR37V99+crtW0MdO17s8/7EMHpf7vK6 Eg7+V/2e7uKlwdzc5movpEDCI7/eWtpw4L2NcSNPP5Z82+Zlit/CUdm6gNlaKAZM8q+68Hq8HZMu 83rzdjPpgQ2wE0hPzIaYnTFkUHWvCneq6DLfzeOVPGxEIwgXo0bUg8g6so3gArKIdBHSxEGQY+p5 thrMmEAMsqjSVfkqolLBx6ovVTiBz+FLeCLw8An/FY9VvF7PJaAcVIKIgOAT9BWlS1Tb1RKzUkCt tlpIOsknREXgY/IlfYrHuDMc5mqtISuWrG3WUeuY9bKV91oBcGuM2bxeD/prvo6vpdjro5OohS0z HzVCjGzxsYSp2O/1sYSSLqb/N2s6xe8hDuIEnwAekhlNXRMHt+f743f/4DVc8QEuGH9OTLYaAEfH JhtOYgMcnOhgsofDWQtm5fK8p3JB1sQ0ulZ2IET+QudQOlrzEkqluiiNujbpAbkWwSE0SQebOYyU GXMhkxvLBEMmDEfWg52th6jAmB6QXtRL+gv6y3peo2dLRDQb9MgytUSU1cGUDl0d4Zk0TXI5jFN6 mQpuJjN8KcTiKydsJlmMpPjb1gd+bmp1jN9PFn59dTzYMe4N+9OLqBy4xL+NbMiHNsmL61M7U3FT 3so8XAzVgBUlLXDx3AZuJ8ep1Fb1evV2NWcOyDloj+mSCZvyh+2zbSpQ9eeP5mNbPkzmw1j+hXwc bzEhnbdWI6L0WsIWTB77r2CPka0XNsi8vIQpN6elJT0a2DoRHVQi+qZ7YPqNMgGm5ESEHyQ/70cb 3/kZPLDpSB4GUMb/DKZ6d/zfksrbqmavqc7IuG1VYGabbHtuRRPEQBwuaFqmdXlzBPjhFXNmsMwl aNOl/ATo7z/cLXm6n7hz8NAyl6frh4ps5CcWk6tUNtrwu3Lpdwl8F8N+EfYhuF98TMT3o8cQ3pg8 kvxoMulJhsdSIEWkau0hM2w3w4AZFpm7zPghExATcxDTaJWI4jT0z5hiE/fbYLsNGm0QsEG8DVQ2 0NhMRgXQqHKAypHhKHAEHF2O9Y7tjiccpxyvOT52fOmIep1dsYPNqckPPgmedQCrxFtvbqL6h+1V DiutCjgW0SpWES7WPfyFAy444OeO9xz4pAMOO+Aex0MOPOSANgfMdCxw4OkOsDsAO0wO/JHjCwdW QI84TjqwAtnhGHJgBTDNMd2Bvx1uEcMJCqCV4YRuBfS3jABQYPcxAuCbgadg5ScoNCU1xIa/14Hb HP0OXOmoc2C7Q3JgzhHjwBcclx34rON9B/52uEI6+AgYRIAgAgIRRLfUY+RgCGodXK1j2DHqGHNw Xgcgh+jAavqkkT3FaIiq5ROZkqAGDf0H5j6tbb3B84p4VNe8KqVy4IbP0usibO3atTe1DFcrWRdL eIt83gh4kY8KQb83zku7pfIj7MO5bnB1HEwbZWTmMzukoALAZ04hseWk0OzDSzLmLbtzbmoJNZ+M 83b4jBMLxz7S2mxxmMQmp2jf/+myx/pKOfV9hKzf4uLyx59KbGoKCroZtQtS8EpqNTKb9s9UD1mR g/r/B+TVB+KejsPftcM2O3w3F9blbsvFG9NG0h5NI7zOokvXERW24gxMnjbBIROsMm0y7TIRU5K+ KVbWG4OxsSwWY0v1puJjqZAqDSdlXzeITVmtm5MgKSk7kdq92a2qG4JIxWHrPSJDmelLdTQdeNge ux5EcVyPhaUQmJ4RiYWZbwiL/bnugVdWjJ/FaN3p4VmOWZ2z6u9t8Ez85eDeiTMwo24oaJ8/bcmW 2omDMFi9qTEP7l/1cKub35JZt6WpdEW936AtaboDzxxYNjHT4V80/tNZS8uSJri4sg4qc3cyy5rK XBbDHJT1RB1ALOgncUTDKRapJS7IcRohHBA4L0BIGBPwIQH6hWEB25QYwmWlQmDgxtT04DwlBsEb OAtaCIjxg4rata7rs8YY9gyoJp0mmfN9FkLF686TJ0/y9mee+fsFruTKa2G7kOo6vIPqOhsql7NE i2TBFosjyhYYY3v1IpLQBXQZ8RoUn2W2UtVmEtUGpsUqKnzvuCJajCloZsvfpLGssZaw5WMxPhBW V4QAZ3aV1BZbs3QmKaV8cWECKU+dPbMkNra0vDimvLk0WU1+xPNFy3fOH387QpvKSWkrxT9/CeVM XnheowvamW84SROppZSLek/gA+9XXnzKC9neRu9OL1F54QnvKe9vvR97uZ1eWO+FRi+ovFZvwEvU XqqbX9ODSm/VF+g/1n/JdPMVP7zh/8D/iZ+87If9ftjlhx7/Bj9u9kO1H1z+Uj/+yg+f+uEDP7zl h1evAwEFyfYX+3GiHwQ/vPmp/4of9/h3+vf7X/K/4edp9ZzrEGEkrCt8raPv+IH2UONv9q/yczY/ cKyLT/34mP+MH9P6zf6bqnV+eHSSoZEn4bwfKJpjDM0BP97MiFnlx/P8UOqHNAWU9nYN6ADDtceP O/xQ44cKhhYMfpsfh4E2+Xf5n/a/7Of6lPbhrla+7GfEEKUPUHoAip8O5QprdImN4y1GK3T497Ih MlIJHcIXrMHT/g/9hDZa5YfpSiODH4pfpoVX/OSwH4ZYk/DYSLg71hetO8KAWfEmP0cRnfMDbvOP +g/7x/wc7V3yg9cPSDb7QZOaX5slRkwrb9i2UowrZl+FBWQ4wHWzhL1Zun6t9Fa5e6269abqG+T1 DY3D6yEinVmB4jRQMxW5vsW4owbQlI3nvA5EELXdCouXzHA+f93ciyuqaZc37UkicWW1HfKCO25P OzEF9W0G4LJV183AMJyr7u6F4/dH/KVBusby0Az0fTlvA52+eEPUziiMswR9UMsn8NgVJxiDfJIl CaenpwRkj9BXtLloTxEpmjUcM1uJuMRYkoIWS8VsGwEizRqbhQ/PglmKPUydKcf8LGvxfEFI8LXG gDdmTwyOiTHUJogeXy2KGIrMwmcCi0WyFPf6mnfNbMY8L5XmrhYXled8agaLflfAlGWozlQ4aDHG WJn3ZWFWJeUtdSozqUz3gzqaWGKs8PgPj8y/98nF/5NUsrh0el15huoVbVH3gd63f5VTakiJTp2V 4av2xBFVctWSdc5FW+pz/mnmHU35rTHP7Fu1c24K5kpnLS1JNGTO8hnlVXNdLx+f8NTO50i/RpNY OL9gel2p/b6KZUP5jRwY85qqG9qY7OqmIj6K34eyKFfnrONgXcK2BLxRHBFxZzosSodsR6Ojx0F6 nJDkhHgLrEvclohViZCZ3Ctr5IycoKyBPRrQ5Aybes1DGVszsDmDBWcwYny1pWQEkSbjARMsMa02 3WUiWlMCNc71g3FqyBiiRknFxWLKVjoLTVRDulqo2+QNO+OuBKYRIsoxEq/w5ZfzNzNUUZUqtcPS 7fvuDw4Nz0urbC0paL3Nqz4tzBz64aqeI2vLfPX9G+9asygOn9+87vkH77prx6Ky5nJbSlljqfH2 7Z0lectGl84eHlrd3dnVU7w/7HvU0rnmjMRA++XaxvSedBw2UcmixK5E3BjbE4s5E6w3bjfiDfqd eqyLAp0GNqh3qvF6sp1gDoMa9cqjMYfpLMoeTumt0II2ftCgdg7y8VOR0MimyjTppkUKMViZHMDi oOXUHkqBW+KgnHPOtpNd3SfuranZenJl5/Gtt7+YNXdt8PaheVnZ8waqZw/Mc+GfvTXx6dO33fYU WN7+DcQ+MWvWExOf/ObJ89sKi7ad//EP/nBfael9f6DP/yB9/gZqH2nRUtluZ3pcEDS9eJQDzgt7 gHoxnIogLGKsxjzzBxJEa7CSr+M7eMJzRKQ5jjrgGgg/zTwWqfT6wjtHsXS9eFtEujCY3s13GPn8 dLZ3dhC6J34Oc56Axfu5sv946k9X4vYrfKeuH1eo0BKL1sm1jxpgvwp2qGCb+D0Rrxchzgrrrdut +6zEystRliDfrF2l3aQlWg30xapsGPrxBYwZsRKupUlegxE3qLFaQadSASWvgtqhitOuBPd8NJXX 4nVRVz3soKOW8BYCUNvYAtQtZ18HWfvU+Aq87dXXJkaxGGPRTDzMm2NiVPA5VEz8DCp2k1NXb3+A 3MEnp6VHjX+mSUhMUFO+NsM5PA/3U1vKIccgLON+KhcRevkQvAvYCwCIBefAy1hjzndYmuELOHf4 sMKHNjr/THT+paEi9FO552gm/FAH34v6URR+ygj7jTDk3OrEQ/at9r12stE2YnvURjYmjiQ+mkg2 JexKOJBAmrJWZuFG3IOxGKfVBws0kI56veYKM55nPmPGyMxikbI5ZObV5hJdn1br7WXhR7ZiE+0Z wWTz9MHWuL44HBfH5wymqqMHY3WgYxPX10KnrjGyyeti4u+i+DvGSxY5Yxb9VGxx6jo1m6/FGAsj YTQl8HTrxDbN3vrq+vn3dAWtzyTd0Vy9oV7CluqW1YVtB1aXVtx5rO/Tz8+mV68KzFgRzHQGVlTl dS/Mx79/ZeJPryx1BPrnJTbXV42c2+29zZdYddexVWtCm2ZOHDk2d6Sr1FO/sWb2xkZfamDVtVi3 CtO55sZuOeqRbHjYBlGiKS4YxWL71NDXs7meSAuy9KAXaUGO3ZFOL6YkeqF6JoXad8/TEuVOC1MU e49W6KPS0hLdS3LS0HSE30ewCx1AmEOgQZ5dHhjyQKkH3vLASQ/oPPDu0x6Y7gG7B2I8gDzwhQfO eeCsB0IMdKvniIe0eaDOA7ICJ3qA88DDl1nzs56PPOQwA9vrwbUeqPSAxKrTPJhiucBA3vfgUQ9s 9UA/a13p6fCQcE/hbsIdnPVwbay6zoPD6LsZxjB+vjaMsdJDYjxhDFs9DO8XHg1r+YWH7GIQrPWQ hyuUF36kDI61CGPh6SAZOH7ZA6wxrmEE0Kd+xQNHwmMYpqJO9tR6+j2kgjHB7sEpiUtQkpyE1Ukq S3irxER5b0kmNWmA9GkkiXpWsb4WJmuoFxs+bRA+VXDN9Fka2SS8xXD6Bk82XLk0nGDzmSbyLobD eNRdDX9a2LeFWkcFhQWFKnU0qMHJoncZmdd3XcJOKxUf/CKMMYk26G2Gib3bJ/ao9AaD2ihSAwk/ dQXuUMeYDISIlhgN9P+VPONb6fZJvjxXe+ZVmYwZsnK9sfnFRYXe7syrdfyWq96Yipmlolg2szyG /HN4r0aJj3HJ1B6KRqloSC7dYN9px0NJW5Mwk5B4g2mnCe+LeiIKc1ExUVgnJApYxyfyWDldoEaz 5VEDGNKGpTRIUwwjav+cT4P42TaqymNqtWJKODgW1lMtrrW3qioQlb2DfJE5rLes4+S//2XtiU0z 4E93v7iu6NXMmtWVVX1zs91zesqr+ufm4JSJjyb+XLn713uwFNj93u67jyzLzF5+ZNPdP1qWlbns CbY+1QiRr7gSJOJmuVCJ+e0HKEABhLejfQiXGG4zYKogegwbDDsNJJ9UEfw9atV1kzvIfYREsxXL sSVcThPULxWwQRRd4iYRc2JM+MI26raKe8Wz4vui5kMRruf5RBE4ETQiwQzFpA43Y5yDdaZEk3Kp MTWbdpkOmN4yfWjSTJrgrOl9Ez5sgq2mvSbcZoJKU50J203AmWJM+PUL1wFYAatkgKqpBKtUJbJK +JCBwgGGCZoZHgiXP3xLr+EboXBf7+/CrfRMdct130gAg9L8ox7D5eFu5eXhjlWFN5KgqjDBt/R5 E01fr8S1JvCaAJlEE1YbsEEA6hT5KsIBqdavB5eW3phfeuNyviladXP0iu3rTAWgaBWLQE0tZ7Z9 SgvZn8N5Y6ip8zcTd4z9RW2OMapUZqrpvzzDlYzL1orKCuo0zKyw4p+HdYdt8jLO4d3UK9gkL86K hp5odqCAUE3Ro2fmINlFrSc7dUtWc3dxB7lnOI7mooJ91s1WbI3SW4kYEDR72EalyNt5mefU/HAc GFS1UcxMFAzmyOJ7p0XZYGDGCrVVYhUzCrlalH2rlrVKZDrf6Mz3FfosPosz4lrgnOz6on/9ztb8 O3/5S19FwrRkjU7/V/zevZ9/fu94/dwKjSoiPyYWk0tcDZqGqtAHcnDjtJFpmMXQcWc51Ed1RuGm kpUlOIMUEJxhol4ACLHxsRtid8ZyqmRr8vrk7cmc4A3IealSNGyOPh+No2cPqwJsL1WeH5sU5Pmy 2YYE0CbYZ8uz8buzAc22zx6dHZrN1Z6fDWOzYd5sGJ59eDY2zPbOxudmX2Yp0GQbUgupn2yYUWux CrX5KshQgQolUo+ZHU4Kx+pBOR4SOSZy4/mktZHA/Q2SHW6wPPzgvNH2YOF8ao74qONljFGZvybA cFrLaJcc/YJpU4e/I5CBY0rr+4Pd36VKoP1A3+BRDyaEw08zh/e8e1ptd0HV8hk2m7yssqB7Qd7E 4ozZy8oSauan1ty56LnsmhJn1cg7991z7sE5Pe3x5YVZRHCVVWde/af/+BN5be33uySp+/v96w4t y/F0PI6unfnrpLZJFIpHHXLgaBxsioNnYiEx1hVbGrspljsqQiKVZqVUnnGbqJVMYAMG1CR7qa2S OCwnQsz1oKS5VU1ipmKRiq689fhF2Epj8cWpQxfhWCPfufL0lQfH/xve+yGYX+sbW7D3V5sm/htK +l4dmYvfDU38zwst/Jb5Ryeuntzz1j3+K8eDD7xP18fkOHtjhMruHHJcTvtTLJRk35aNN2aPZD+a TfLFKhGvE5lJTwqSA8m4QDE8L8tWKqiLk6qTcHESJDHxrQh7xKoEHc3pA3qsGGU+mlMUAogsFV0d TTWtSC2vaL01OUkNyJnlhAYnWNVOp9pKDNk5Yg6bltXevGB1DkzPgYwc+CoHXsv5OAcfyYF9ObAh BwpyAjldOSQ+B77IgVOsamvO3hzclbM+BxcrTWKUk3OaHNGgKAXB0Ghg2ofTGl5zf+z+0k2OuGGf Gza4ocsNdW4ocAfcON4NX7jhYzecdcMpN+x3w3Y3DCkgxW6Icae5scoNb37Fmp5yM0RcT6Sp4I53 Y9ryJTcscne5t7sJbeFijYA2+cgNv53C+gM37FUQD7ihg0HDdHelG6dOwe7/0g0/d7/nxifd8IQb trphPaOww41nMlCwujPcmHPDH92fu/H7bnjNDXQsDymQXe71bjw1mjQGCxwbk/ybyKhOKMCMvn1u Uumuc+OCqX57vmQ44f2pwZEh91ZWHaDDIWkMxOrGX7AhfOzGe91H3JiOoUcZQCWrLXDja8N8gmLA O5UhQhujIY12RYqOuM+633d/4eaGFbbWuEGKsPWK0uywwppNYY50uEmiGy4rzHuLsWqre6/7pJur cANGbtGNNWpmxWdFG4Mz1TBdDalqUCdlE4PBmRVlDObSOaXcrQBWJ4m2KEYoNQzZjR2WnDqd9vUI XGvLjcXfZIHeENa7Ma53U2DgZry3mK/hsN71PZcbwV1U/cVS/ef1rh1Qdn58kY2Yta7wXwv7Z39U IxIPUKNWsXCJoh4h1hpbUFgOVEXelOH2/fOzGqNGKwhajVlz4tzEP594UR2tVms0gkZUnf3Zq2qR pjUatUF9JoR/klib4fbmujMW2MZvo3rVETvLnp6ZkWaTLfg/x+MTZianOmluVgI+z3RsMhWEZfyb VPZ/X9YRrVnr087Scnote0ArNVHBBIMI0WK8CAEeYTBhW7I3mZ2j2Zy8J/lQstqQXEGTx5LPJJ9P vpSsLm2lKRyuI8nyoo5gspzpDtqTpeS2ZHJMASJyMhgoFmyujaLGZ228ysDMkgofUztsl2qty7VW 2dhStitY+JQdF3EtVaIGVA1P6ZXIhkIy+CzQc/KRR6ylXfPtVQnGXFOWL1n3a/Li1Wry4r0bSztr XCrVTsJbs8sy2++lY148+Rl5k9r0mWidPH+DCBtiYXk6LCdgD9hsmsBhdhY1G822mcHsrE2w2Tfb 99jP2zm7PUG0a/o1w5pzmgsanp0na1OyY7SAPgF2MsSWDS1T5w59LCbD7Hqj7zvetXHMiQ/rgpvO hih6kouc31UGBOZEuWdO2xbDKaGse2/75hN9eWkzGroHSpof6Jb1L0UP9MzplhNxasvBteUrVkfN umtp8aKH37lzzY+/U++LzVu8vjK6aaWvO3Iec4ReypW9pj55OmHbOOemdnIuI06DLvCXeXyeB3Z2 Cx/ioZ8f5rGBt/H4Mg+0XLE0EtkOEw+T4eox/hx/gacgQBGxJxd+aFMrSon5RA5zjZzk3/77dKZr t04spn7UHJSBStBeWewp2lCEe3I25ODtafvScBqbbma1Nlhta7ThanWjGm8n+wgmrLyCllNP6nAm ZJYNT0syBJAoipJ4WeQ0YqgMKsqgv2y0DNvKYLIMxsoulOEkd22qaDUYEjUFtXw4pqycsggbNIof mzflabHtUVfL1CGtjExnCvmG4xa3Ol5ZLfv7h57zUCZEDiA8B4QaK/Hygs6K/v0tWa/GlS67rWzl PE9G9epAzfLSOJy66dy++oYObJdKkycaeVVmsDRHIGm+koTp1V5L7YPvbOk4uLoote3ofewwQknv Ica3FdT/jI/EqI7J0m4LbLSOWHGjukeNm8hKspGQOtyBcZ2zwznkJHWpHalDqSQ/pSoFb8uDPKZC c7X64NYESE/IT6hKWJfAWRPA0hcTg3plb/qhdDyaDuklw97kXlFr12Ll6H5cSkZQm5yzzm6fHjcY b9lvwRaDenokpOprUXYxwoGpm889MU5eC0pdO/d2PcJ6bYpbwtlbuBpfOvhU36bTG/1V97y8Pnh3 99zYZ5I2zb/tzrrcaScG2w72+V9MC64MTOuY78uqWTlzRncwA95ZeXzz7KXHAY68Akk/bUuZ1Vtr a54f2PXe7ubW8nU/7q9evzA3ecbK2+fe11GSW7+R8bQOIS6T8jQdZaOdcuW6tG1peJ1zmxM3JaxM wE0WaIreGD0STZr0G/UjelKiuk2FhaBWG8oey8bZ+zIyzImBJGo1me1m2TzKwntmxrXYDHfQbHa0 avdQNmYezLg9ERLjWh0ckwct3vHXWoxK7P2iV+HfWl/4kP/UGUHGLZXaWa4OR95VU4F3yPdZuMz0 8nkL5lVkwjGcWT63dk5Zes6cNbN2H4k+rZu14fmNAyc2yeN7fsFpZq+un1VWUrmwsGpFbUVxcaCh tHRJhX33xqi67/XPKOree+WxN94I274vU7lwN7Ud2R50gZxG1PsoU0Y5LHO13AXuMkfThznMyXox yPEHOXQQDHQc3otsBGsHrm8j0+/Lv/jFL8iqd9+9+r1331VkzuOTn/HZ1K6ORztkvxLEbyQ9JBwo rRKhSguWJlk21ZoOm4hkGjVdNpE9pkOmYyZiUqxqOXEs8VzihUQukbE1jZoJmqZ5fCvfx5M9/CEe vxt26WSeqHmziuhbkXLqWYlQMdlDKZw6aDh1vohXjhT6bjpwGI3xh0PnHltyprhr18IFD/VW/LTl 8L/ElN/7xgjZcnXPqu8tdbnbDvSRjqsP3v/ujpl0XLFUXf2Z8kyHfysH92LYjuF+zWMavEED96ge UuH1KlAOB21AUKi9Q4uTtLCRAzMHJA7uhB3wCHCx6vvUD6uJSqMFNccJgqjE+kt5gRcI0onZumId 5nQxtAfdx7ovdeSsDthp6FM6slUHKl2GLqDr0m3XsbLXKISg0VEWvRBnC+qYrLws6wQCAikmWEuo ET8sD53/JLheDx16WKSHSj0U6CFND1Y9cHpgG974PT2M6eGEHrbq9+qP6Mk/An79Sz18pIff6uGs Hk7p4QjbNg/oF+m36/fpn9C/pv+t/mO9sI8mmPcwJr/84lhwK0PUpV+vJxRZhr5Ajymih1mCFT6h P0WhGRHCx6x7WM86rdN36MmNHd/a73qlT9IR3rjPUKjgu69TE6ZFs1//gR5/41h+q/RKzjIEjJqA nivsUuhRzgAo9Bf4ZwaL9ZCqB+XoHv6C8emc/oKenNTDsH5Uf1hPhvTQpoc6Pch6mK4HO/UKWdNU U1zwsJ6aurRdrb5fz6BVai3HqYFgjcqAcDgKQ01FI/iYMeu6wSptDR/ruTUUc2uRq+Wbdp+vQbno chighio7EK7Yp8rxIK+3qIj2nBc5gtt6Y0uHAE6BnZak/8Qx8fuJD38OWyYefB2iIeqNiQdhO7wy UYndOHqiGX40/sX4e2Eb4wF2PpLaGA52PlLDlqxaF9QF5NooOBQ1GYWjnMPIOeY857zg5MacYHDC sBOcU+cjk+ICY/GA4sV4Kf5C/OV4XhOfgOJ1FmSq5cXwVlfFN5+PhG/YJneGV7Ya/CmBuo7yFdvm JL9glBoCyjnJk5hgIFsK5+TFFnXurmOb31Urqpyeujtrxu/h35642zGzKFOtyMetLO4bORf5kCz0 TNswDW9wgo0ZJHHUINmesi8FVyc2JuJqrpHD22EfdZRvtFbsYM8fzuHNARZ9k6iM4zSmUD5U5MMt RyXTa5NFE4qy8N5a/H/DWmHmCogOZquwkTrLiSLOVGqV2sf0qoncYqxMDGz6oQ9T+4RaKdRUOcmM Fk45Q/nqtQOT1ExhByZx6vibjcsTiqRUTnCVBTO5ixONKYWWeOuKponPJv6onJfseuLOoceXXzsv KSCk3k7lvYdbLFdTv3ydETbhXRhXYxiK2hqFA1GwMWWEsiulMaUnhayzbbPh2bbFtm4beSAXmnNX 5W7KJVtE6BCHRFwvAl1JysbQBXmSJqjFvg5BJdXaHYgUINgdDRujoSa6OXpVNAtIUB8lOie6JJoI 0fBJ9Fd02Pp0fb6eqCISLlpvTUjJSSlJIUIKfJLyFZ0wtnRbvo2obPCx7UsbtqWoEyAHSoAIAJ/A V0DXZzrKR0SF4GP0JXV7UOamTBiybrViqzozkwU7EnJzcktyCdHkwn/l/i0X537ogXc98LIHjnng gAf2eGCTB/o80OyBedQCmufZ4znmIR45Pilo90gebPCA4OFF+JP4VxGfEl8TfysSImoMRYY7DTsM jxhOG1RRBlmejM8IGu6QHpb+RSIFUkBaJJFYKVPCKgkKpW7pDunH0ovS69J/Sv9L0mRIoJZiJfzG 6xT6PyVyp/SI9KR0WuJ6JMiSiqQGicQzEPgvCT6Q4EnplxLeL8GIBA3SCglXM5SgkeIk/J8S/FKC H4dzWVJQ2iHx+18Pw+1QsPLVDCcIUryE/1X6Lwm/JcGj0lPSTySySwJp7K7NwWIJciSgPWol+EqC PyudvinBaQl2Svulo4xAoKSVSLdJTRLJliBBgigJVoxL8JkEv5fgbQnkyVcleFqCgxJQvHdJsEqC JRLUSFAmgUuCJAl0ElyV4FMJficBpeKVKXh0vwSbJVgjQasEcyTwShUSTpbAIAHt4ZLSw7sSUPzH JHhMgj0M9jsSblagSyXIlSBRAr0ERVckuCjBhxK8I8HLEjwrwQEJKPpNCvoaqVnCxQo58Qo5Xynk /F4hJ0z+Ywr531HIb1HI90vAGtgkwK3SZumQdEY6L01KKkSZXqmuU2N1Si4xkEzZYN1k3UUnnl2I DlohOvyeUovRx4IhLETbev0o0q3nlW6NbVzTDq3fDH7rSSbXzbGQr/UzpamUw4Wt4UgxFVA3kORj R18jYZEWSnjkxP6tiYh0YwLO9TWi/3G0hCjREkIzbNPb7OP/86MvdPHaqCh9lC5O9+VHE+2vjxtt Or3OIKqjDQbVX1/8q8pgiFaLBhDjkg1fvU42Z6zwFhaXFEpdGVe38Fuubqm4a1rJ9KpZSeVlhbFk zdXvxhaWlifNClSt2DCdbGbyDk1+hosVn9onJ2xAO6mEiKOCKhsDFtmpCDsexpwSUj3JoM3MRfYW vdNSpOzdW9hr4gcen+iJ4S/83R7x0TlC8enQFbnuLgwbNbBeDYuELmG7sE/glJ1t9pbGBkSGtFu1 e7WkUgug1epyNEA0gjjEAhbUeqzTDen26gi7nNS9r/tI94WOvTyGmY0o91C9pFOTQPikKTXwNZxN X6HH7NKqn9RzBn04uVnPF+vlhYuCbdRyOaxnVg9/nr3AEM5z4TcZ5Egle6NBUGOg9o3GwCPOEj4N WhFbDMzsGGDGR1iHedl55LVFPp+3pcjXOmAMv6/OPswJQi0OUCvaWzE+pImHtp48CR/+eqIafgV/ WTOxmX/7ajvWT3jHH1Z0zgJFP29BbvSCnMSszO16Uo87seIU43pXpwvX53Tm4IzTk/8qN1IXwqIB lRbi0/an4Z1pH6RhUukAldNOa5w66grbLOC1HLLgUQtYPMNptvReh92u6z2nBbZXlDCYlSWmDTlU 4uCg7l4d7taB9dpRDWXLhLl0EH4PzBfR18z/MBa7pkmtdAEMKIN0KSNVvtffCSM3vtqgdpodFgcJ +8dcsnz3y5v6fjQwK/qULquqMxgYmO/Ombs2mHv7jPzYkJc4xu9NlEaX9zy5Xoa3VoY2B6Y3bwxY smpKna66jfNmrJnnFpPSY/CX+ydmpOfL634QttfmRmIKpehf5e9tJCMEr8PbMF5Xsq0Er/Nt8+F1 3m3e8Hu7G9NH0nGzcZURJ2QDZeF6z3YPpk58dSZk9BbET2M/T4Az4zPjtWZ777RpjJFmr/mQmYya wewf1vVeCjOwIH4oIUG8PwOWZKzOuCuDaDMSMnCGc9CtFge36GChbrluUEdidMDfwFbG1/CZNS87 2D31/pgSbTAqpmwLvV1ce+1d+etv9N7M3gLGXRf1pBVGZ9zgXSsnwC0phIuv2PD84L3PD5UIP9G4 blt9244DVd0bfF3LfL3NpdvuveO7US/oajc93rj+qdW+1GDf3Pq7F2TDtvZHegpnrNpZbSxaMjNt +9a5rfmmg5bCpdVr793YF90y0pxb2rljTvnqReUiJ5Q29DPen574O2xBH6IoNPclxE1eeFFnDGof RvuUN7mtgjGoHo4ajcJyVG1UKIqMRh2m5jOris7IDkYxbzxK/SQ6oEPe8Y+oK6744q5xZhimW8LG IOQ782GLEJMcsyl3WsOHT+Yvrplpn7F1xofhZ795ogE/TmWNFc2Uc+/Tw30CNMRAAwZjHF0KPLuI KlFUDauwSvc5CxTaqZwTE3mkSLGWi2+3FOUpu7v0Y57a2Zt6UWdzTtPu9ueW7mxwuRp2Ln2ufXdT Do7ZNfHn3/X0/P7TiV27Jj6jqd/9eXy3QksuQkqcQIMXyjEpaohSgzouyhA08kB4ENkbpP8lT9IC novGoIlW92iOarBKY9UUaAIaLlqjgqYMvAjvw2Q9/hjjYmpxYhUGEe/XHtW+oSWLtCBoi7U4Xtuo 3an9SstRCfDmV1r4mJXHa1+iMNxrWmjUbqDwpEAL2RT6Je0nWk6nhf0U8DXtb7X4hBaOaGGfFu7R wpAWFmm7tHimFtK007XYpAVOC18oKM9q39fiJ7SntPghLWzVwnotLNNCnRaUt6jStGBVgD+nsvuc 9oIWn9XCYW1Ii/dqoV8LHVqQtRCjZWgJ0kLPR9ovtPicVj5Fez+pPaslw9pRLaYE1GrbtJhqADtD F6PFtPcLkd5DrL8O7RDVEUe0vKSVlX4Rq6XIRsMN0rSV2jot0yTq4guM0iO0KelnlaxzhoBXOh/T wkktRFqxiq1a/n3tR1r8ssIR2gJLjBaD1qvFiJSSGrKJ+RgaLvwrBNTdpPoebjxqcMs5g1vNjtab dmm+fvx67bUtaWUfht7Hi39F73kuiBPnfMymZuvSsItEtYniyxLhp+N/fA+ehaffw8Hx0zhIisfb 8aHweuie/Iw/TGVhLnpJvme7C1a6YGb6gnTMx1ni6uPIolhYZAbeZDHVm8jGqJEo3BjVE4VXEliJ oTq9MR3nJ8Mm/S49pg9Pq01bYpMdDrTZtoe6Fd5hu7fNO+wlluZj6AzCdgQG2qOj9XIqpKbyCa3Z ZrGVl3SyDo/qLuiwTsdz194wDp/+u/Ye/9stNJ8QOeIZjhde/5jDL/Lf/AsgyiHAfEe+wxj5MYPu xuOgevaes6MdzlMJ1St2Ngy/epd/5j0/27xw99pFyRPNuN67+fFXVp2Y+PJ4I35deZ/fs2jTnILp 9WWOqff5k3ILkyYOTyRIi2dmsNf+wzxUYolUphHkke1kH0KjCIdfFFdeFhlFh6lDzWQXggMITcUQ 2RaBEj388EOKI4rKJZcil4KyfocedgiwOAYWU7lEhcDzTDTR+0lFOrE4l2hT7aESCn2+h+oLEbG3 rZh0Gr9ROsGUdzwVy8eubxBP4u5xJp5+9xkTT5/+nomniV3hcdGv8dMr5QtIq6Hsr8gW/l3EX438 HqZ+u29yfGIx9XzfRuxHE3GkkNaqyyfmolnXfv/vGnzkU4I/Q5X86+hJfpHybeH+A3lofoWqGLWz cpp/Ehcj9nbuqxxCxdwg2ka/iyksR+876HcRe/GXtYfX0U78FNqhekopX0y/3fRbS78H6ddL65rp vY3WPxlpp6Z4bSyt0PD65DjNJ9PyxRTXCC3fSr8r6LeOlr9MYR6ndbE0/wCrU9+PBEYbLWOwC+h3 Ls2fpv1spvTk0jF0s3Y0z6aHG70JGngPnyMd5N+4Zdwz9O9L/ogqTrVDXaJ+UpMnvK1dRqXgRFRI v0T/cfSS6B8YNIYMw78ai4xPmr40N8RkxGy3PhmbGvtI7O/i7oxPjT8S/15CeeKbSdOT3rTNtK20 c/YfONochx0fO7Ocbzo/SyuIcLwEBeiMDEe7ReRFTQiRx/kxWsaeVBIsuvZc2q49I0AGmoNIKzXq i6QJSkDrI2mOwoxG0jyKRociaRVNPxtJq9FGuirCaQ2KgfxIWkDRUB1J6ygNi6/9AqoHBiNpPeqD 70fS0aicuhQEASfQ3BieG0kDSiHRkTRG0cQdSRM0nZRE0hyF6Y2keZREdkfSKpp+MpJWoy/I2Uha g7K405G0gJK4C5G0DhVxVyPpKLSEnx5J69Ef6NIOp6PRXareWX39GwZ6ulcM2bOWZ9vzJKnQvqCz wx5sH3Lbq3uXe+wzVq+2KwCD9oHOwc6B9Z0dHvvt1TOrFsyoq543194zaG+3Dw20d3SuaR9YZe/r urn97T3LOgfah3r6eu0L23sHF3R2r1vdPjBjcHlnb0fngD3X/jWAr2UXdQ4MsvQ0j1To8V2v/Bro /wURlPLunsGhzgFa2NNrr/cs9Nhr24c6e4fs7b0d9rprDed1dfUs71QKl3cODLVT4L6hFZTOlesG egY7epaz3gY918if1TfQ3xehaKhzfad9TvvQUOdgX++KoaH+Eq/3jjvu8LRHgJdTWM/yvjXeb6sb 2tDf2dE52NPdSwfuWTG0ZvXtlKDeQUr4OqVHSs2NLAv09dIHszoM47YPdnbaGfpBir+rs4OS1j/Q t7Jz+ZCnb6Dbe0fPqh5vGF9Pb7f3OhqGJdLP/1lrKj/7UD/1eQeo59uNVqAhaolmoeUom97zkET/ CmlqAepEHfQeRO0Uwk1T1aiXQnloagZaTf/sN2AYVHKd9N5J7+uVtgzydtpqJqqi2GagOpqeh+bS 0h4Fvp1+hyh0O4XtRGvofQCtomV9qOtb+7+dtl+m9MNqeih8L61dSHO9FC9r143WUfoYvhm0ZDkt 6VX6GKBwuQpV34bh22sXKTWD18qnUYoYxzzI940tvx3r/xknwjzvVrAMKbjDkD0K7noKsVCBqlVa Mi4MKb31KlB139DjPNpjF23PeHYdcrmCe4jmw5j7aHpFhJ8rKa8HFAo6lHZTYxukPd/KfTb3Bujs 6/sajxh165U+5yjlQ8pcYnUrlFw/1Tpe+neH8uehMDdjXh7B61FSayjk/9N2Q3Rl9Ct87FSecjeF DT9xj4JzDZ1Zt0c41KvMd8ahdTeMMcybfzTLAso9vGJW34SHPVl2Z22nqB+M0N+l9BPmWj+99lG+ dyrc9iil3coYe+gz7KGpG+ljT6w7UvZ1aqZouXk8/1/2TSL2Xybah77hc1yQfwrs7SSbcj0EnPwA jI3DsXFA46CddwXsV+CvtVm2zwNZtv8O5NguB1y21kubL2HDpXmXWi/tuXTsEq/700cptv/4Y8Bm +CPIfwxYbf9+IWB798L5C5cuEPmCryBwIRBn+73/fP0f/KT+PJD635FJm+E3tt9g5SK/GZcYePfn 8OpYme1ntRm2V36aZZt8CWpP958ePk2UH5I4bcoL2F6seHHei30vbn7x0IvHXlT3nzh8InSCGE7A 6AsQegEML4DG8HzF85eeJ8Oh0RAOhcZC50LEe6ziGD78bOhZPPbsuWex95mKZ/Chp2HsqXNP4XlH 9xzF3qN9R88cnTzKHTyQZqs9AH374Mw+2BdItn1vb6xt8949eyf3EulB+UE8/CD07xneg0f3wNie c3vwvN2tu/t2k+2BSduhbbD13mm2ocEK2yAdQV9vma03kG9LgLj6eF9cvdpH6lV0zG20rpV+lwSm 2ZqbgrYmejfnmep5yhMuj9T3ETCQCoIvzZ+cj+X5+UUBeX56VuBdua4WqgN2W5DinE2/xwJwPnAp gIcDYM2z1BvBUC/mGeoxoHpAYLMZKgyths0GzmDwGuYZ+gx7DOcNkwZ1BS27ZCDUVBy2Ag+nYfR4 3UKXq+a0enJBTUhd2xyCHaH0hewqz28KqXaEUH1Tc8NxgAcat91/P5qZXBPKW9gQakturAl10ITM EsM0ISYft6KZjUODQ+uUV2MgnEBDLtfgIEux39BC4ddmQEmBa5BWU7DBoUGaGVqHBl2DQzA4SBfy EC0fhKU0PTjIigeBtqDfQVcYPcVAES+lCOhlKIx6cJDCD9L2g3FL6bz+30iDwbYKZW5kc3RyZWFt CmVuZG9iagoKMjggMCBvYmoKMTY4MDUKZW5kb2JqCgoyOSAwIG9iago8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnROYW1lL0NBQUFBQStMaWJlcmF0aW9uU2FucwovRmxhZ3MgNAovRm9udEJCb3hb LTIwMyAtMzAzIDEwNDkgOTEwXS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQgOTA1Ci9EZXNjZW50IC0y MTEKL0NhcEhlaWdodCA5MTAKL1N0ZW1WIDgwCi9Gb250RmlsZTIgMjcgMCBSCj4+CmVuZG9iagoK MzAgMCBvYmoKPDwvTGVuZ3RoIDQ2OC9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdk8Fu 4jAQhu95Ch/bQ5XYJnGRUCQKReLQ3dXSPkBIDI1UksiEA29f//N7d6U9gD6Px+OPwZNv9tv90M/5 rzC2Bz+rUz90wV/HW2i9OvpzP2TaqK5v57SS7/bSTFkezx7u19lf9sNpXK2y/Hfcu87hrh7W3Xj0 j1n+M3Q+9MNZPXxsDnF9uE3Tl7/4YVZFVteq86dY562ZfjQXn8upp30Xt/v5/hSP/Et4v09eGVlr qrRj569T0/rQDGefrYqiVqvdrs780P23VzoeOZ7azybEVB1Ti6I0dWQjvCjBlnELXpAX4JI5Eq/I O7Ajv4KfyRV4KWwK8JrxJfhF2EmdDVnu3QpXwq/M1+Ad46ivCzJ8NP0daurkj9+i6V9JnP5O4vSv tmD6V6iv6W8lh/4Wzpr+VnLob+Ve+hupQ38rd9F/IXH6V+iPpr9DTwz9HeoY+lcOnPwlTn8ncfpX cjb5o28m+W/A9HdwNslf8pM/HEzyX4PpX6LPJvX/GZz6L5z80RND/xI+lv4GNW3yfwHT36Kmpb+F p6W/gaelv0F9S/8SfbPp/Uh9+hv81za9n6U85vRq8awxd3/GRbW3EOKoyHDKjGA6+sH/nd9pnHBK Pt/flPCOCmVuZHN0cmVhbQplbmRvYmoKCjMxIDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1Ry dWVUeXBlL0Jhc2VGb250L0NBQUFBQStMaWJlcmF0aW9uU2FucwovRmlyc3RDaGFyIDAKL0xhc3RD aGFyIDU3Ci9XaWR0aHNbMzY1IDcyMiA2NjYgNjY2IDYxMCA3MjIgNzc3IDcyMiA2MTAgMjc3IDI3 NyA1MDAgNTU2IDU1NiA2NjYgNTU2CjU1NiA1MDAgNjY2IDIyMiAzMzMgODMzIDU1NiA1NTYgNTU2 IDU1NiA1NTYgMzMzIDU1NiA4MzMgNTU2IDUwMAoyNzcgNTU2IDcyMiA3MjIgMjc3IDUwMCAyMjIg NTU2IDU1NiA1NTYgMjc3IDcyMiA1MDAgNTU2IDU1NiA5NDMKMjc3IDUwMCA1NTYgNTU2IDI3NyAz MzMgNjY2IDc3NyAyNzcgMzMzIF0KL0ZvbnREZXNjcmlwdG9yIDI5IDAgUgovVG9Vbmljb2RlIDMw IDAgUgo+PgplbmRvYmoKCjMyIDAgb2JqCjw8L0YxIDIxIDAgUi9GMiAzMSAwIFIvRjMgMjYgMCBS Cj4+CmVuZG9iagoKMzMgMCBvYmoKPDwvRm9udCAzMiAwIFIKL1hPYmplY3Q8PC9UcjE0IDE0IDAg Ui9UcjQgNCAwIFIvVHI5IDkgMCBSPj4KL0V4dEdTdGF0ZTw8L0VHUzEwIDEwIDAgUi9FR1MxNSAx NSAwIFIvRUdTNSA1IDAgUj4+Ci9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJL0ltYWdl Ql0KPj4KZW5kb2JqCgoxIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMTYgMCBSL1Jlc291cmNl cyAzMyAwIFIvTWVkaWFCb3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1Mv RGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDIgMCBSPj4KZW5kb2JqCgo2IDAgb2JqCjw8L1R5 cGUvUGFnZS9QYXJlbnQgMTYgMCBSL1Jlc291cmNlcyAzMyAwIFIvTWVkaWFCb3hbMCAwIDc5NCA1 OTVdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRz IDcgMCBSPj4KZW5kb2JqCgoxMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDE2IDAgUi9SZXNv dXJjZXMgMzMgMCBSL01lZGlhQm94WzAgMCA3OTQgNTk1XS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5 L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyAxMiAwIFI+PgplbmRvYmoKCjM0IDAgb2Jq Cjw8L0NvdW50IDMvRmlyc3QgMzUgMCBSL0xhc3QgMzcgMCBSCj4+CmVuZG9iagoKMzUgMCBvYmoK PDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MzAwNkMwMDY5MDA2NDAwNjUwMDIwMDAzMT4KL0Rlc3Rb MSAwIFIvWFlaIDAgNTk1IDBdL1BhcmVudCAzNCAwIFIvTmV4dCAzNiAwIFI+PgplbmRvYmoKCjM2 IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzI+ Ci9EZXN0WzYgMCBSL1hZWiAwIDU5NSAwXS9QYXJlbnQgMzQgMCBSL1ByZXYgMzUgMCBSL05leHQg MzcgMCBSPj4KZW5kb2JqCgozNyAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUzMDA2QzAw NjkwMDY0MDA2NTAwMjAwMDMzPgovRGVzdFsxMSAwIFIvWFlaIDAgNTk1IDBdL1BhcmVudCAzNCAw IFIvUHJldiAzNiAwIFI+PgplbmRvYmoKCjE2IDAgb2JqCjw8L1R5cGUvUGFnZXMKL1Jlc291cmNl cyAzMyAwIFIKL01lZGlhQm94WyAwIDAgNzk0IDU5NSBdCi9LaWRzWyAxIDAgUiA2IDAgUiAxMSAw IFIgXQovQ291bnQgMz4+CmVuZG9iagoKMzggMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1BhZ2VzIDE2 IDAgUgovT3BlbkFjdGlvblsxIDAgUiAvWFlaIG51bGwgbnVsbCAwXQovT3V0bGluZXMgMzQgMCBS Cj4+CmVuZG9iagoKMzkgMCBvYmoKPDwvQ3JlYXRvcjxGRUZGMDA0OTAwNkQwMDcwMDA3MjAwNjUw MDczMDA3Mz4KL1Byb2R1Y2VyPEZFRkYwMDRDMDA2OTAwNjIwMDcyMDA2NTAwNEYwMDY2MDA2NjAw NjkwMDYzMDA2NTAwMjAwMDM0MDAyRTAwMzI+Ci9DcmVhdGlvbkRhdGUoRDoyMDE0MDkyMjA4MTAx Ni0wNycwMCcpPj4KZW5kb2JqCgp4cmVmCjAgNDAKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDI3 MDMyIDAwMDAwIG4gCjAwMDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAwMDM0OCAwMDAwMCBuIAowMDAw MDAwMzY4IDAwMDAwIG4gCjAwMDAwMDA1NDQgMDAwMDAgbiAKMDAwMDAyNzE3NiAwMDAwMCBuIAow MDAwMDAwNTg0IDAwMDAwIG4gCjAwMDAwMDE1NDUgMDAwMDAgbiAKMDAwMDAwMTU2NSAwMDAwMCBu IAowMDAwMDAxNzQxIDAwMDAwIG4gCjAwMDAwMjczMjAgMDAwMDAgbiAKMDAwMDAwMTc4MiAwMDAw MCBuIAowMDAwMDAyNDM0IDAwMDAwIG4gCjAwMDAwMDI0NTUgMDAwMDAgbiAKMDAwMDAwMjYzMiAw MDAwMCBuIAowMDAwMDI3ODk4IDAwMDAwIG4gCjAwMDAwMDI2NzMgMDAwMDAgbiAKMDAwMDAwNTg0 MiAwMDAwMCBuIAowMDAwMDA1ODY0IDAwMDAwIG4gCjAwMDAwMDYwNjEgMDAwMDAgbiAKMDAwMDAw NjM1MiAwMDAwMCBuIAowMDAwMDA2NTE4IDAwMDAwIG4gCjAwMDAwMDgwODggMDAwMDAgbiAKMDAw MDAwODExMCAwMDAwMCBuIAowMDAwMDA4MzAyIDAwMDAwIG4gCjAwMDAwMDg2MDIgMDAwMDAgbiAK MDAwMDAwODc2NyAwMDAwMCBuIAowMDAwMDI1NjU5IDAwMDAwIG4gCjAwMDAwMjU2ODIgMDAwMDAg biAKMDAwMDAyNTg3OCAwMDAwMCBuIAowMDAwMDI2NDE2IDAwMDAwIG4gCjAwMDAwMjY4MDYgMDAw MDAgbiAKMDAwMDAyNjg1OSAwMDAwMCBuIAowMDAwMDI3NDY2IDAwMDAwIG4gCjAwMDAwMjc1MjIg MDAwMDAgbiAKMDAwMDAyNzY0MyAwMDAwMCBuIAowMDAwMDI3Nzc2IDAwMDAwIG4gCjAwMDAwMjgw MTEgMDAwMDAgbiAKMDAwMDAyODExMyAwMDAwMCBuIAp0cmFpbGVyCjw8L1NpemUgNDAvUm9vdCAz OCAwIFIKL0luZm8gMzkgMCBSCi9JRCBbIDw3NjMwMUMzODRBMjAzQzA5RkFDQjQ0MUJGRkZGMjYw OT4KPDc2MzAxQzM4NEEyMDNDMDlGQUNCNDQxQkZGRkYyNjA5PiBdCi9Eb2NDaGVja3N1bSAvQkUx RUY0OTkwMDFGNjg5MDg2MUZCOUU3QzNEQTIzQjEKPj4Kc3RhcnR4cmVmCjI4MjkyCiUlRU9GCg== --001a11c3d8d4ed3dc50503a9c8f2-- From nobody Mon Sep 22 10:01:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA61A1B37 for ; Mon, 22 Sep 2014 10:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNhfCCX6ulL7 for ; Mon, 22 Sep 2014 10:01:30 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091D91A1B61 for ; Mon, 22 Sep 2014 10:01:29 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XW6zM-00074F-GB; Mon, 22 Sep 2014 19:01:25 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-6.fritz.box) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XW6zM-0004qT-Cf; Mon, 22 Sep 2014 19:01:24 +0200 Message-ID: <542055E3.9040900@ripe.net> Date: Mon, 22 Sep 2014 19:01:23 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Andy Bierman References: <541ADF7A.8020607@ripe.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.7 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.8 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885ee5d9961e42ba1738c2447f0f201c642e Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/idtLWxKyk18QCQv8Pi87fUpnho0 Cc: Netconf Subject: Re: [Netconf] Details about our upcoming Bi-weekly NETCONF Virtual Interim on 22 Sept 2014, 17:00-19:00 UTC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:01:39 -0000 On 22/09/14 18:17, Andy Bierman wrote: > Hi, > > Here are the slides for the RESTCONF portion of the meeting. > I think it will take 10 minutes, not 60. > OK, whatever tome we need. Juergen and you also wanted a high level discussion I believe, so we then have time for that. Bert > > > On Thu, Sep 18, 2014 at 6:34 AM, Bert Wijnen > wrote: > > NETCONF participants > > This coming Monday 22 Sept, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time) > we will have our second NETCONF virtual interim meeting. > > Agenda > > - 5 min chair intro - recording the meeting, scribe, agenda bashing > > - 60 min restconf open issues (Andy) > See https://github.com/netconf-wg/__restconf/issues > note that for issue https://github.com/netconf-wg/__restconf/issues/7 > we have a WG concensus call outstanding that ends today (Sept 18th). > If you have not yet expressed your opinion, > please do so ASAP today (any timezone). > See consensus the formal call on wglist: > http://www.ietf.org/mail-__archive/web/netconf/current/__msg09218.html > > > - 40 min netconf-server model open issues (Kent) > see: https://github.com/netconf-wg/__server-model/issues > > - 15 min AOB other topics > > If you want specific topics on the agenda, please let us (WG Chairs) know ASAP. > > I believe the webex info for the meeting is this: > > To JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.__php?MTID=__m9f461ea30a23d08e29f45c40c0814__e7d > > Meeting number: 649 602 794 > Meeting password: restconf > > JOIN BY PHONE > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 649 602 794 > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > In case you want to check, proceedings (including ptr to the recording) of our first > virtual meeting on 8 Sept are here: > http://www.ietf.org/__proceedings/interim/2014/09/__08/netconf/minutes/minutes-__interim-2014-netconf-1 > > > > Bert and Mehmet > > _________________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/__listinfo/netconf > > From nobody Mon Sep 22 10:27:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0311A1BBF for ; Mon, 22 Sep 2014 10:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0c4Wo1182vm for ; Mon, 22 Sep 2014 10:27:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E541A1BB2 for ; Mon, 22 Sep 2014 10:27:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 438A9751; Mon, 22 Sep 2014 19:27:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5yYEr8OmJWI5; Mon, 22 Sep 2014 19:27:17 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 19:27:17 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FF8320036; Mon, 22 Sep 2014 19:27:17 +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 m0-0V230kP89; Mon, 22 Sep 2014 19:27:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0286C20035; Mon, 22 Sep 2014 19:27:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 46B172E85B04; Mon, 22 Sep 2014 19:27:14 +0200 (CEST) Date: Mon, 22 Sep 2014 19:27:14 +0200 From: Juergen Schoenwaelder To: Bert Wijnen Message-ID: <20140922172714.GA18962@elstar.local> Mail-Followup-To: Bert Wijnen , Andy Bierman , Netconf References: <541ADF7A.8020607@ripe.net> <542055E3.9040900@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542055E3.9040900@ripe.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xsLDWJkPY9YLDbTbD4Ybn1DdgMQ Cc: Netconf Subject: Re: [Netconf] Details about our upcoming Bi-weekly NETCONF Virtual Interim on 22 Sept 2014, 17:00-19:00 UTC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:27:21 -0000 On Mon, Sep 22, 2014 at 07:01:23PM +0200, Bert Wijnen wrote: > On 22/09/14 18:17, Andy Bierman wrote: > >Hi, > > > >Here are the slides for the RESTCONF portion of the meeting. > >I think it will take 10 minutes, not 60. > > > OK, whatever tome we need. > > Juergen and you also wanted a high level discussion I believe, so we then > have time for that. > No, I did not necessarily ask for discussion time - at least I do not feel well prepared for that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 22 10:58:08 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280C71A1BA2 for ; Mon, 22 Sep 2014 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cE-zG5-4lJr for ; Mon, 22 Sep 2014 10:58:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6897F1A1B94 for ; Mon, 22 Sep 2014 10:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=681; q=dns/txt; s=iport; t=1411408683; x=1412618283; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=0HeoqVG2ri8D5pPCcsw/psmTeuw5g78J4D76qsPrIwA=; b=Z9mYeokclybUN5eijnCd6wbUpxuYk27AC5E8zzcFqMcoMuFbgzmv+4YK J4jTQzJJIe5rAuu6Cd3PX+IG7sZOcCiqomUiqKb+EtHt0st0QeLVJZqOZ Vo2EFarft4YSveJGVkV0UBLCx4Yt41g2OA/VhuDenWKOUDp5w9o+H1rB7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAA5iIFStJA2D/2dsb2JhbABggw5TVwTKRQqGeVQBgQ4WAXqEBAEBBAEBATc0HQEIGB43CyUCBAESCYg1DcQ/AReMToJnAQFRBYRLBZFXiz+VUoF5gWhsAYEOOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,572,1406592000"; d="scan'208";a="354144061" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 22 Sep 2014 17:58:02 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8MHw2Zl002691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 17:58:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 12:58:02 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: "Bert Wijnen (IETF)" , Martin Bjorklund , "Benoit Claise (bclaise)" , "netconf@ietf.org" Thread-Topic: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) Thread-Index: AQHP1mL4neTjAmOZVEmOEvjCiL26ZJwNb8oAgAAA04CAAADPgP//3caA Date: Mon, 22 Sep 2014 17:58:02 +0000 Message-ID: In-Reply-To: <54201D6F.10902@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.154.204.94] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4WTUpkinzDQdvU1s6XEXMkMHayI Subject: Re: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:58:05 -0000 +1 On 9/22/14, 6:00 AM, "Bert Wijnen (IETF)" wrote: > > >On 22/09/14 14:57, Juergen Schoenwaelder wrote: >> On Mon, Sep 22, 2014 at 02:54:40PM +0200, Martin Bjorklund wrote: >>> Benoit Claise wrote: >>>> Dear all, >>>> >>>> Should this reported technical errata be accepted? >>> >>> I suggested a variant of the proposed text in: >>> >>> http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html >>> >> >> I like Martin's text. > >same here, Bert >> >> /js >> > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Sep 22 11:10:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6041A1BA6 for ; Mon, 22 Sep 2014 11:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfNq1QP8Pl_4 for ; Mon, 22 Sep 2014 11:10:17 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DE91A1BA2 for ; Mon, 22 Sep 2014 11:10:17 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 9A762EBB97D8F; Mon, 22 Sep 2014 18:10:14 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s8MIAGM9021381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 14:10:16 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 14:10:16 -0400 From: "Sterne, Jason (Jason)" To: "Bert Wijnen (IETF)" , Martin Bjorklund , "bclaise@cisco.com" , "netconf@ietf.org" Thread-Topic: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) Thread-Index: AQHP1mU/+w5JLw/czEaE+QlA2SSJY5wNdBPA Date: Mon, 22 Sep 2014 18:10:15 +0000 Message-ID: References: <20140730151636.1C5E218001B@rfc-editor.org> <542019A8.3040705@cisco.com> <20140922.145440.10915271733439530.mbj@tail-f.com> <20140922125737.GA18011@elstar.local> <54201D6F.10902@bwijnen.net> In-Reply-To: <54201D6F.10902@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hVIk2SOqz0jvCwU1TrkNDCKvCmM Subject: Re: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:10:19 -0000 +1 on Martin's. -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (I= ETF) Sent: Monday, September 22, 2014 9:01 AM To: Martin Bjorklund; bclaise@cisco.com; netconf@ietf.org Subject: Re: [Netconf] Fwd: [Technical Errata Reported] RFC6241 (4066) On 22/09/14 14:57, Juergen Schoenwaelder wrote: > On Mon, Sep 22, 2014 at 02:54:40PM +0200, Martin Bjorklund wrote: >> Benoit Claise wrote: >>> Dear all, >>> >>> Should this reported technical errata be accepted? >> >> I suggested a variant of the proposed text in: >> >> http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html >> > > I like Martin's text. same here, Bert > > /js > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Sep 22 15:05:10 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9C71A1B42 for ; Mon, 22 Sep 2014 15:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh1O38X4odSg for ; Mon, 22 Sep 2014 15:05:06 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7EC1A1B3C for ; Mon, 22 Sep 2014 15:05:05 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 22 Sep 2014 22:05:03 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.87]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.87]) with mapi id 15.00.1034.003; Mon, 22 Sep 2014 22:05:03 +0000 From: Kent Watsen To: NetConf Thread-Topic: regarding my action items from today's meeting Thread-Index: AQHP1rFBajl92QbI4UKYTqSD/KjKmg== Date: Mon, 22 Sep 2014 22:05:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 034215E98F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(189002)(74502003)(74662003)(81542003)(85852003)(87936001)(97736003)(36756003)(77096002)(86362001)(54356999)(101416001)(105586002)(10300001)(99396002)(120916001)(66066001)(99286002)(83072002)(107886001)(77982003)(85306004)(46102003)(31966008)(20776003)(95666004)(80022003)(79102003)(4396001)(50986999)(64706001)(21056001)(90102001)(83506001)(19580395003)(106116001)(107046002)(92726001)(106356001)(81342003)(76482002)(229853001)(15975445006)(110136001)(2656002)(83322001)(92566001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <77916F646F7E954480FEADE10B7BEDF2@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Sdtl4Hr7Fvu-hlzC57sGy6UKoVs Subject: [Netconf] regarding my action items from today's meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:05:08 -0000 *** ACTION: Kent to lookup who raised the call-hone [sic] enable knobs (bwijnen, 18:46:57) This regards https://github.com/netconf-wg/server-model/issues/7. I traced this comment to the Open Issues section in the original netconf-server draft (it was NOT posted to the mailing list). Juergen had added it to the Open Issues section (via revision 3991 on his SVN server), but it was more an open-ended question rather than an assertion of any kind. Juergen further clarified on today's call that he wouldn't push for it, and Andy/Kent are against it, so it seems that we could close this issue with resolution of not adding "enable[d]" knobs to the draft... Anybody disagree? PS: my plan is to resurrect the conditional-enablement draft so that metadata (e.g., XML attributes) can be used to enable/disable subtrees. *** ACTION: Kent to check what Junos allows (kwatsen_, 18:54:05) This regards https://github.com/netconf-wg/server-model/issues/8. The JUNOS model looks like this: +--rw configuration! +--rw system +--rw services! +--rw netconf +--rw ssh! +--rw apply-advanced +--rw connection-limit? uint32 +--rw rate-limit? uint32 +--rw port? int32 Or in YANG: container netconf { description "Allow NETCONF connections"; container ssh { presence "enable ssh"; description "Allow NETCONF over SSH"; leaf connection-limit { description "Maximum number of allowed connections"; default 75; type uint32 { range "1 .. 250"; } } leaf rate-limit { description "Maximum number of connections per minute"; default 150; type uint32 { range "1 .. 250"; } } leaf port { description "Service port number"; type int32 { range "1 .. 65535"; } } } Cheers, Kent From nobody Mon Sep 22 16:37:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4261A6F5D; Mon, 22 Sep 2014 16:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Qve4PoyUdVS; Mon, 22 Sep 2014 16:37:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ED31A02BB; Mon, 22 Sep 2014 16:37:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922233711.27080.670.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 16:37:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ZmoqnrdTESTTW2PmurxCix883Pw Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 23:37:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Server Configuration Model Authors : Kent Watsen Juergen Schoenwaelder Filename : draft-ietf-netconf-server-model-03.txt Pages : 28 Date : 2014-09-22 Abstract: This draft defines a NETCONF server configuration data model. This data model enables configuration of the NETCONF service itself, including which transports it supports, what ports they listen on, whether they support device-initiated connections, and associated parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-server-model-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-server-model-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 22 17:00:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119FF1A6F5D for ; Mon, 22 Sep 2014 17:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JKbn9PZGAMj for ; Mon, 22 Sep 2014 17:00:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0707.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:707]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA631A6F3F for ; Mon, 22 Sep 2014 17:00:32 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 00:00:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.87]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.87]) with mapi id 15.00.1034.003; Tue, 23 Sep 2014 00:00:09 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-03.txt Thread-Index: AQHP1r4mSMtHoAKpcUesreERkS6AEpwNkiEA Date: Tue, 23 Sep 2014 00:00:08 +0000 Message-ID: References: <20140922233711.27080.670.idtracker@ietfa.amsl.com> In-Reply-To: <20140922233711.27080.670.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(24454002)(164054003)(377424004)(377454003)(199003)(479174003)(87936001)(77096002)(85852003)(15975445006)(80022003)(79102003)(81542003)(92726001)(4396001)(97736003)(92566001)(2656002)(99286002)(50986999)(76176999)(2501002)(83506001)(19580405001)(85306004)(10300001)(95666004)(99396002)(19580395003)(106356001)(83322001)(54356999)(120916001)(83072002)(86362001)(105586002)(15202345003)(74502003)(106116001)(2351001)(31966008)(66066001)(90102001)(101416001)(76482002)(36756003)(230783001)(81342003)(77982003)(107886001)(74662003)(20776003)(46102003)(110136001)(64706001)(107046002)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/uIE1XbIgAU8zYXLkaC0LCV-lulg Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-server-model-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 00:00:35 -0000 This update has the following change log entry: - fixed tree diagrams and surrounding text This to address the issue found during today's interim meeting, of the call-home tree-diagram being the same as in the -01 draft. I also found that the surrounding text was in need of a clean-up and so took care of that as well. Thanks, Kent On 9/22/14, 7:37 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Server Configuration Model > Authors : Kent Watsen > Juergen Schoenwaelder > Filename : draft-ietf-netconf-server-model-03.txt > Pages : 28 > Date : 2014-09-22 > >Abstract: > This draft defines a NETCONF server configuration data model. This > data model enables configuration of the NETCONF service itself, > including which transports it supports, what ports they listen on, > whether they support device-initiated connections, and associated > parameters. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-server-model-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-server-model-03 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 23 00:13:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32D1A6EFE; Mon, 22 Sep 2014 14:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcCCo918-beL; Mon, 22 Sep 2014 14:05:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 675401A6EFB; Mon, 22 Sep 2014 14:05:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F0E53C3DE; Mon, 22 Sep 2014 17:05:46 -0400 (EDT) Date: Mon, 22 Sep 2014 17:05:46 -0400 From: Jeffrey Haas To: i2rs@ietf.org, netmod@ietf.org Message-ID: <20140922210546.GA5676@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/E3-OPTRHVQ05PW9pK2vsH6d50Ik X-Mailman-Approved-At: Tue, 23 Sep 2014 00:13:20 -0700 Subject: [Netconf] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:05:49 -0000 [BCC: netconf] The netmod interim in New York City last week was a productive discussion for I2RS, although it was frustrating in its conclusions. (Those conclusions mostly being, "There's mostly no work needed here, go talk to netconf!") However, given the large overlap of WG membership between netmod and netconf, it should hopefully make the next form of this meeting somewhat easier to have. Thanks to Cisco for providing the venue for the interim. This writeup is presented to document my perception of our discussion and provide the seed to start further discussion in i2rs. No specific requests are being made to netconf at this point - and to reduce accidental noise as we try to converge on our discussion points, I have placed them in the BCC field. We can make more formal requests once the i2rs discussion of the netmod interim has gotten some traction. Juergen has placed the full netmod minutes here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt A small excerpt from those minutes: : Conclusion: We do not need any changes for YANG 1.1 (hurray) but : instead we need a document that introduces ephemeral datastores and : clarifies what validation means with ephemeral datastores. In : addition, the NETCONF WG needs to do work to define suitable : protocol operations and RESTCONF needs to make sure it is prepared : to support ephemeral datastores. There is also NETCONF work to be : done to improve notification handling. The only YANG 1.1 homework is : to make sure that the language in the YANG 1.1 specification is : flexible enough to enable the introduction of ephemeral datastores. Background: The seed for the discussion at this interim was the somewhat hastily authored document: https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 ----- Ephemeral state: The I2RS portion of the discussion was kicked off by talking about the ephemeral state that I2RS wants to have and why it is important that it is ephemeral. The three options from section 2.1 were presented and discussed at length. The points about the advantages of a separate datastore (easy cleanup, clear segregation of state) were compared against the desire of other non-I2RS users wanting ephemeral state. A point that was raised early was, "why can't we simply let the operators choose whether something is ephemeral or not?" This lead to a discussion regarding the nature of "priority" and what its impact was with regard to how ephemeral state was kept. One thing that became apparent during this discussion is the I2RS Architecture draft is potentially not clear enough about the distinction of I2RS state priority vs. Local Config priority (section 6.3 of the Architecture draft) and client priority (section 7.8); the word priority is overloaded. Clarifying client priority vs. state priority lead further into where such data is kept and how it is used. Room discussion eventually went to identity and how it was associated with priority. An observation was made that this information is effectively meta-state being kept on the configuration nodes. Such information, not being yang specific, was suggested as a point for netconf. It was observed that the identity may be useful information for general users and may not be i2rs specific. The analogy was made to "git blame" (and other similar source-control annotation mechanisms). The "where is the ephemeral state kept" conversation began to converge around a possible fourth option - one that apparently had some discussion much earlier in the i2rs working group's life, apparently. Here's my attempt to describe the conclusions of that discussion: - There is a new ephemeral datastore. - It may be used by my many applications, including I2RS. - It has the property that the schema of config state is "visible" in it from a read-only perspective. - It has the property that writes to it may either create new state that is disjoint from the config data store state or it may cause changes to information that is/was visible from the config state. Such changes may be merge, override, delete, e.g. - This "shadowing" behavior avoids issues in the existing yang by not requiring additional language semantics that would require mechanisms to cross-reference between datastores. (One might observe this is somewhat similar to Object Oriented programming where the configuration state serves as a "base class" with ephemeral configuration extending that base. A different analogy is the union filesystem semantic.) Issues that came up with this model under discussion: - Validation is a problem with this design. (And was likely even more complicated in the original 3 discussion points. This was one of the elements that drove us to this fourth option.) - It is possible to refer to config state from ephemeral state for conditions (must, when), but not vice-versa. - We (i2rs) must decide what happens when ephemeral state has conditions that are invalidated by a change to the underlying config state. In such a case, the config state may validate, but i2rs may not. Does the operation succeed or fail? - Such constraints and their validation impact may negatively impact the desired speed properties of i2rs. However, it was also observed this is only the case when such references exist and that "fast" i2rs operations could simply be modeled with no dependencies on config state. - Ephemeral state priority vs. Local Config priority is difficult to fully support in such a model. In the above discussion, ephemeral state always has priority over Local Config. - Providing for Local Config to have lower priority may be possible, but introduces some unusual semantics. - Does I2RS have clear use cases for Local Config winning? The example of "configuration of last resort" was offered but is potentially a weak case. In summary, the fourth option was strongly driven by the arguments of "what keeps things simple". The original three options were apparently not simple enough and there's some doubt about the impacts of the fourth. Possible yang 1.1 implications: If the above model works, the discussed configuration semantic may be the previously discussed "config (false|true|ephemeral);" ------ Mutual authentication was also discussed. As noted on list conversation after draft-haas-* was published, while restconf doesn't currently require it, it is suspected that it will have such a requirement before working through IESG. I suggest that I2RS requirements are addressed for this point. ----- Identity requirements for the primary identity are covered by authentication requirements for the existing protocols. The "secondary identity" requirement is a netconf issues and we should talk to them about the implications. Since the primary requirement for this feature is for auditing, this may simply be meta-data that is kept on configuration state. (See commentary above.) It is noted, however, that introducing something like a secondary identity would require changes to SSH and/or TLS and may be somewhat difficult to make the case to the owning working groups. Per-client priority effectively becomes the ability to say "you can't write to this if the state exists and has an owner with a higher priority". Further discussion on this point is needed in light of the fourth option we were presented. ------ Persistance of subscriptions. Effectively we were told "go talk to netconf, it's out of scope for yang 1.1". Some discussion was given to the filtering considerations. Extending the filtering options of the ietf-inet-types module may be appropriate. [Juergen, is this an action item for yang 1.1?] ----- Hopefully this is clear enough to kick off discussion. -- Jeff From nobody Tue Sep 23 00:50:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEF91A1BAD; Tue, 23 Sep 2014 00:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtbdCGDKQHhY; Tue, 23 Sep 2014 00:50:46 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653A41A1BAF; Tue, 23 Sep 2014 00:50:46 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XWKrv-0002h1-Nx; Tue, 23 Sep 2014 09:50:42 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest125.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XWKrv-0006eB-9H; Tue, 23 Sep 2014 09:50:39 +0200 Message-ID: <5421264E.3020103@bwijnen.net> Date: Tue, 23 Sep 2014 09:50:38 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jeffrey Haas , netconf References: <20140922210546.GA5676@pfrc> In-Reply-To: <20140922210546.GA5676@pfrc> Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd4e612c824b427cae28f7af699a306405d Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XuEKnUGKXXQ8Yd2qVaCe-8CuOlA Subject: Re: [Netconf] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 07:50:49 -0000 [bcc to i2rs and netmod]; I propose to discuss the netconf aspects of this on the netconf mailing list. However, for i2rs "consensus" on the specific netconf requirements, I think it MUSR be dealth with on i2rs list. Thanks Jeff, this is good for netconf participants to be aware of. And to discuss/comment on. Bert On 22/09/14 23:05, Jeffrey Haas wrote: > [BCC: netconf] > > The netmod interim in New York City last week was a productive discussion for > I2RS, although it was frustrating in its conclusions. (Those conclusions > mostly being, "There's mostly no work needed here, go talk to netconf!") > However, given the large overlap of WG membership between netmod and > netconf, it should hopefully make the next form of this meeting somewhat > easier to have. > > Thanks to Cisco for providing the venue for the interim. > > This writeup is presented to document my perception of our discussion and > provide the seed to start further discussion in i2rs. No specific requests > are being made to netconf at this point - and to reduce accidental noise as > we try to converge on our discussion points, I have placed them in the BCC > field. We can make more formal requests once the i2rs discussion of the > netmod interim has gotten some traction. > > Juergen has placed the full netmod minutes here: > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt > > A small excerpt from those minutes: > : Conclusion: We do not need any changes for YANG 1.1 (hurray) but > : instead we need a document that introduces ephemeral datastores and > : clarifies what validation means with ephemeral datastores. In > : addition, the NETCONF WG needs to do work to define suitable > : protocol operations and RESTCONF needs to make sure it is prepared > : to support ephemeral datastores. There is also NETCONF work to be > : done to improve notification handling. The only YANG 1.1 homework is > : to make sure that the language in the YANG 1.1 specification is > : flexible enough to enable the introduction of ephemeral datastores. > > Background: > > The seed for the discussion at this interim was the somewhat hastily > authored document: > https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 > > ----- > > Ephemeral state: > > The I2RS portion of the discussion was kicked off by talking about the > ephemeral state that I2RS wants to have and why it is important that it is > ephemeral. The three options from section 2.1 were presented and discussed > at length. The points about the advantages of a separate datastore (easy > cleanup, clear segregation of state) were compared against the desire of > other non-I2RS users wanting ephemeral state. A point that was raised early > was, "why can't we simply let the operators choose whether something is > ephemeral or not?" > > This lead to a discussion regarding the nature of "priority" and what its > impact was with regard to how ephemeral state was kept. One thing that > became apparent during this discussion is the I2RS Architecture draft is > potentially not clear enough about the distinction of I2RS state priority > vs. Local Config priority (section 6.3 of the Architecture draft) and client > priority (section 7.8); the word priority is overloaded. > > Clarifying client priority vs. state priority lead further into where such > data is kept and how it is used. Room discussion eventually went to > identity and how it was associated with priority. An observation was made > that this information is effectively meta-state being kept on the > configuration nodes. Such information, not being yang specific, was > suggested as a point for netconf. It was observed that the identity may be > useful information for general users and may not be i2rs specific. The > analogy was made to "git blame" (and other similar source-control annotation > mechanisms). > > The "where is the ephemeral state kept" conversation began to converge > around a possible fourth option - one that apparently had some discussion > much earlier in the i2rs working group's life, apparently. Here's my > attempt to describe the conclusions of that discussion: > > - There is a new ephemeral datastore. > - It may be used by my many applications, including I2RS. > - It has the property that the schema of config state is "visible" in it > from a read-only perspective. > - It has the property that writes to it may either create new state that is > disjoint from the config data store state or it may cause changes to > information that is/was visible from the config state. Such changes may > be merge, override, delete, e.g. > - This "shadowing" behavior avoids issues in the existing yang by not > requiring additional language semantics that would require mechanisms to > cross-reference between datastores. (One might observe this is somewhat > similar to Object Oriented programming where the configuration state > serves as a "base class" with ephemeral configuration extending that > base. A different analogy is the union filesystem semantic.) > > Issues that came up with this model under discussion: > > - Validation is a problem with this design. (And was likely even more > complicated in the original 3 discussion points. This was one of the > elements that drove us to this fourth option.) > - It is possible to refer to config state from ephemeral state for > conditions (must, when), but not vice-versa. > - We (i2rs) must decide what happens when ephemeral state has conditions > that are invalidated by a change to the underlying config state. In such > a case, the config state may validate, but i2rs may not. Does the > operation succeed or fail? > - Such constraints and their validation impact may negatively impact the > desired speed properties of i2rs. However, it was also observed this is > only the case when such references exist and that "fast" i2rs operations > could simply be modeled with no dependencies on config state. > > - Ephemeral state priority vs. Local Config priority is difficult to fully > support in such a model. In the above discussion, ephemeral state always > has priority over Local Config. > - Providing for Local Config to have lower priority may be possible, but > introduces some unusual semantics. > - Does I2RS have clear use cases for Local Config winning? The example of > "configuration of last resort" was offered but is potentially a weak case. > > In summary, the fourth option was strongly driven by the arguments of "what > keeps things simple". The original three options were apparently not simple > enough and there's some doubt about the impacts of the fourth. > > Possible yang 1.1 implications: If the above model works, the discussed > configuration semantic may be the previously discussed > "config (false|true|ephemeral);" > > ------ > > Mutual authentication was also discussed. As noted on list conversation > after draft-haas-* was published, while restconf doesn't currently require > it, it is suspected that it will have such a requirement before working > through IESG. > > I suggest that I2RS requirements are addressed for this point. > > ----- > > Identity requirements for the primary identity are covered by authentication > requirements for the existing protocols. The "secondary identity" > requirement is a netconf issues and we should talk to them about the > implications. Since the primary requirement for this feature is for > auditing, this may simply be meta-data that is kept on configuration state. > (See commentary above.) > > It is noted, however, that introducing something like a secondary identity > would require changes to SSH and/or TLS and may be somewhat difficult to > make the case to the owning working groups. > > Per-client priority effectively becomes the ability to say "you can't write > to this if the state exists and has an owner with a higher priority". > Further discussion on this point is needed in light of the fourth option we > were presented. > > ------ > > Persistance of subscriptions. Effectively we were told "go talk to netconf, > it's out of scope for yang 1.1". > > Some discussion was given to the filtering considerations. Extending the > filtering options of the ietf-inet-types module may be appropriate. > [Juergen, is this an action item for yang 1.1?] > > ----- > > Hopefully this is clear enough to kick off discussion. > > -- Jeff > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Sep 23 00:54:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75EE1A6EFF for ; Tue, 23 Sep 2014 00:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNWe36pVRmTZ for ; Tue, 23 Sep 2014 00:54:19 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AAB1A6EE7 for ; Tue, 23 Sep 2014 00:54:19 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XWKvQ-0000WX-Gn for netconf@ietf.org; Tue, 23 Sep 2014 09:54:17 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest125.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XWKvQ-0005pF-D3 for netconf@ietf.org; Tue, 23 Sep 2014 09:54:16 +0200 Message-ID: <54212728.2000201@bwijnen.net> Date: Tue, 23 Sep 2014 09:54:16 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Netconf References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------070200070105050308000607" 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: 86ab03e524994f79ca2c75a176445dd418622ecfa2107fe62a509e325439c609 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/S-RkdZzYZvgJke_kGA7QkrdW7No Subject: [Netconf] Fwd: I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 07:54:20 -0000 This is a multi-part message in MIME format. --------------070200070105050308000607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Copied (by me) from netmod mailing list. I believe that NACM issues belong in our NETCONF WG. So we should all be aware of this. I also suggest we discuss this on THIS NETCONF mailinglist and not on netmod. (or am I missing something)? Bert -------- Forwarded Message -------- Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) Date: Mon, 22 Sep 2014 14:09:52 -0700 From: Andy Bierman To: Jeffrey Haas CC: i2rs@ietf.org , netmod@ietf.org , Susan Hares On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas > wrote: Sue, On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > Where does the priority live ??? in I2RS or in config module or in BGP > routing model? How does this work with the three datastore proposals: 1) > separate empheral data store, 2) configuration state in existing datastore > tagged by model as empheral, and 3) whole data stores tagged empheral, > config, or both. Is the routing code that sets the priority and handles > the rollback? Priority received quite a bit of discussion during the netmod interim. The reason why it was not explicitly spelled out in my first version of the draft is that the implementation would vary considerably depending on which answer netmod guided us toward for how we get ephemeral state. The rationale for the priority-based "first one wins" access control model is still unclear to me. A simple NACM extension to add group priority has already been proposed, which seems fine to me. So is this how it works? #1) NACM data rules can be used to grant or deny access to specific I2RS data nodes. Steps #2 and #3 assume access is granted here #2) the I2RS agent maintains the owner and owner priority of the data somehow. The priority is configured in each NACM group for enforcement purposes. This data used to decide if existing data can be overwritten by a different client. (I think highest priority wins if target data already exists) #3) if both writer and current owner have the same priority, then current owner wins Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. It seems to be based on the order that the networking devices will boot. Can somebody explain why it is better? I am still unclear how the operator know the exact data each client will want to use, and how they determine the meaningful overlap (e.g. what will break for client B if client A causes 2 of its 7 entries to be deleted?) This information seems to be required in order to configure the tie-breaking priorities properly, but I think the intent is that the operator will just know what I2RS clients are installed and know how to prioritize them, just based on their purpose. It turned out they gave us a fourth option. I'll be summarizing that in my meeting minutes. If you don't believe I've adequately addressed it in that writeup (coming shortly), please let me know and we'll resume. -- Jeff Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --------------070200070105050308000607 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --------------070200070105050308000607-- From nobody Tue Sep 23 00:59:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFD81A6F0B for ; Tue, 23 Sep 2014 00:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfzVaz4LR7UR for ; Tue, 23 Sep 2014 00:59:24 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323721A6EFB for ; Tue, 23 Sep 2014 00:59:24 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XWL0L-0001AN-Bb; Tue, 23 Sep 2014 09:59:22 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest125.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XWL0L-0006Vk-93; Tue, 23 Sep 2014 09:59:21 +0200 Message-ID: <54212858.8000909@bwijnen.net> Date: Tue, 23 Sep 2014 09:59:20 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: NetConf References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd45e7dd3bb1e6e64fb3941ea4ae77bd71d Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_FDXA5dPQSK_O8WZEL1UNtSFjLs Subject: [Netconf] WG Consensus call on: remove "enabl[d]" knobs in netconf server model. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 07:59:26 -0000 W.r.t. On 23/09/14 00:05, Kent Watsen wrote: > > *** ACTION: Kent to lookup who raised the call-hone [sic] enable knobs > (bwijnen, 18:46:57) > > This regards https://github.com/netconf-wg/server-model/issues/7. > > I traced this comment to the Open Issues section in the original > netconf-server draft (it was NOT posted to the mailing list). Juergen had > added it to the Open Issues section (via revision 3991 on his SVN server), > but it was more an open-ended question rather than an assertion of any > kind. Juergen further clarified on today's call that he wouldn't push > for it, and Andy/Kent are against it, so it seems that we could close this > issue with resolution of not adding "enable[d]" knobs to the draft... > > Anybody disagree? > Please speak up ASAP (by Okt 1st at the latest) if you believe that we do need those "enable[d]" knobs. If we hear no strong objections, then we will do as suggested by Kent, "do not add those knobs". Bert and Mehmet > PS: my plan is to resurrect the conditional-enablement draft so that > metadata (e.g., XML attributes) can be used to enable/disable subtrees. > > > > *** ACTION: Kent to check what Junos allows (kwatsen_, 18:54:05) > > This regards https://github.com/netconf-wg/server-model/issues/8. > > The JUNOS model looks like this: > > +--rw configuration! > +--rw system > +--rw services! > +--rw netconf > +--rw ssh! > +--rw apply-advanced > +--rw connection-limit? uint32 > +--rw rate-limit? uint32 > +--rw port? int32 > > > > Or in YANG: > > container netconf { > description "Allow NETCONF connections"; > container ssh { > presence "enable ssh"; > description "Allow NETCONF over SSH"; > leaf connection-limit { > description "Maximum number of allowed connections"; > default 75; > type uint32 { > range "1 .. 250"; > } > } > leaf rate-limit { > description "Maximum number of connections per minute"; > default 150; > type uint32 { > range "1 .. 250"; > } > } > leaf port { > description "Service port number"; > type int32 { > range "1 .. 65535"; > } > } > } > > > > > Cheers, > Kent > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Sep 25 05:05:39 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB961A6FC6 for ; Thu, 25 Sep 2014 05:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTuSr1WVpKy7 for ; Thu, 25 Sep 2014 05:05:33 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3F71A6FC4 for ; Thu, 25 Sep 2014 05:05:33 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XX7nd-0004Kf-PR for netconf@ietf.org; Thu, 25 Sep 2014 14:05:31 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest172.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XX7nd-0003IT-LL for netconf@ietf.org; Thu, 25 Sep 2014 14:05:29 +0200 Message-ID: <54240509.5030202@bwijnen.net> Date: Thu, 25 Sep 2014 14:05:29 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Netconf References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd4c7ce65d59d4b91d27db24672f1537e0e Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Bns2tQoon4ces7NMX83qqzIiFIg Subject: [Netconf] Draft minutes/notes for our Virtual meting we had on Monday Sept 22, 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:05:37 -0000 Below are "minutes" as taken by our meeting robot (see webchat.freenode.net). Kent introduced us to this tool Would be good to hear if people prefer this over etherpad. Attendees: * Kent Watsen * Juergen Schoenwaelder * Andy Bierman * Dan Romascanu * Mahesh Jethhanandani * Bert Wijnen (WG co-chair) * Mehmet Ersue (WG co-chair) Regrets: Benoit Claise Recording Information: NETCONF Bi-weekly Meeting-20140922 1706-1 Topic: NETCONF Bi-weekly Meeting-20140922 1706-1 Create time: 9/22/14 9:00 pm File size: 135.52MB Duration: 1 hour 51 minutes Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=4471a74e39db0527e20450dee7e0c83d Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=74685966dcfe937c9452e65e80931d65 Bert: w.r.t. meeting recordings, we have decided to not store them someplace permanently. WEBEX keeps the recordings for a while, but when they expire they will be gone. (does anyone know how long they will stick around?) =================== #netconf-wg Meeting =================== Meeting started by kwatsen at 17:21:06 UTC. The full logs are available at netconf-wg/2014/netconf-wg.2014-09-22-17.21.log.html . Meeting summary --------------- * Agenda Bashing (kwatsen, 17:22:40) * Bert asks around... (kwatsen, 17:32:11) * RESTCONF (kwatsen, 17:32:23) * Bert asked about the issue of CLI and NETCONF. Advised that since it is not part of the charter that a draft be written and brought on the mailing list. (mj, 17:33:51) * Andy asks about monitoring being part of RESTCONF or keep separate (kwatsen, 17:34:28) * We are talking about how to announce supported modules and the idea in NY was to do that in a separate YANG module. (js__, 17:37:21) * Juergen prefers a distinct capability for RESTCONF for monitoring (kwatsen, 17:37:33) * No, Juergen said that the announcement of capabilities and data models supported should be driven by a common data model. (js__, 17:38:03) * Makes sense that both RESTCONF and NETCONF return a similar format, but doesn't have to be same content (kwatsen, 17:47:02) * Bert: leave 6022 alone for now (andy agrees) (kwatsen, 17:52:27) * does this mean 6022 will have redundant info for a while? (Andy says yes, until changed, only redundant if implement both protocols) (kwatsen, 17:55:30) * ACTION: Andy will capture in draft text and then we'll discuss more (kwatsen, 17:58:29) * I assume the data model for announcements of data models will be very small and it will be YANG specific (and not support other data modeling languages, which RFC 6022 allows) (js__, 17:58:37) * now starting discussion on NACM (kwatsen, 17:58:41) * ACTION: Andy will try to capture a minimal set of rules (kwatsen, 18:01:51) * Juergen mentions desire for better notifications (SNMP trap like) - maybe best to put in RESTCONF now? (kwatsen, 18:05:03) * LINK: https://tools.ietf.org/html/draft-swhyte-i2rs-data-collection-system-00 (kwatsen, 18:05:05) * LINK: https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 (js__, 18:06:53) * maybe better to remove notifications (SSE) from RESTCONF (kwatsen, 18:09:32) * Call Home (kwatsen, 18:09:13) * no comments * Call Home (kwatsen, 18:12:52) * ACTION: Kent to lookup who raised the call-hone enable knobs (bwijnen, 18:46:57) * ACTION: Kent to find out who raised the enable-knob (kwatsen_, 18:53:05) * ACTION: Andy and Martin to check which config knobs might be good to tune at runtime (kwatsen_, 18:53:51) * ACTION: Kent to check what Junos allows (kwatsen_, 18:54:05) * ACTION: Juergen says he'll send 5539bis update tomorrow (kwatsen_, 18:57:57) * I (mahesh) will try to work on a -00 draft for CLI support before the 91 meeting. (mj, 18:59:18) Meeting ended at 19:00:12 UTC. People present (lines said) --------------------------- * kwatsen (20) * kwatsen_ (10) * js__ (4) * meetbot (3) * mj (3) * bwijnen (2) Generated by `MeetBot`_ 0.1.4 From nobody Fri Sep 26 18:05:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715E21A00A7 for ; Fri, 26 Sep 2014 18:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM6VhLg0Jczv for ; Fri, 26 Sep 2014 18:05:47 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5775C1A0083 for ; Fri, 26 Sep 2014 18:05:47 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hq11so848376vcb.21 for ; Fri, 26 Sep 2014 18:05:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=nI+7I/72RcM8mD34LEEamXKRkPYgO7WJ65MUKvHxtNY=; b=Sn8B0eheZUXrCCFY8TUa7/hxngoCSmf7cW9bYLY7uRHVZev2M7iZnMLSNTu+Vs/CuL /gyNA5X1hdCjjJ/Zz1xuzFy8AGLrqB2TIW0oU5u0uLF/YcBIta9DIZ+2qiI/p9T0D93C SQ71vOWsV13RGvySbK6GtbKh4YRoQsSi4RtHnEZ9wNwG4wyQQu0fuS3dhYL8d9vRh7HQ XzqwvWWFkR7zgmwcenbTHNpy6se9CPXwa0rrKcS1Xh2njGCPLPy6EReSCloBjv9Pmfdl W4XnVVWjJEZjKI/x2amQWXsNORY5Oi79CUtKJEQzdguhdTeal7XcpYfkHR4IeiVLED7C SlRw== X-Gm-Message-State: ALoCoQnM6etsWr+tr0OOkRNnzNS5rX6nioIneNNg+sHI+fyY0QP6BL2Ea+DJHNw38PYsEpeQ0YrV MIME-Version: 1.0 X-Received: by 10.220.169.2 with SMTP id w2mr3141713vcy.33.1411779946291; Fri, 26 Sep 2014 18:05:46 -0700 (PDT) Received: by 10.31.168.200 with HTTP; Fri, 26 Sep 2014 18:05:46 -0700 (PDT) Date: Fri, 26 Sep 2014 18:05:46 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c2d150333813050401a293 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1w6snER5PVwSbvSD7_RHHtn3e34 Subject: [Netconf] parameter list for netconf-server module action item X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2014 01:05:51 -0000 --001a11c2d150333813050401a293 Content-Type: text/plain; charset=ISO-8859-1 Hi, I was asked to look through our proprietary server config module and pick out the leafs that were not implementation-specific. I picked a server subset (left out all logging, module config). I am not proposing that all these leafs be added to the netconf-server module. I am just completing an action item from the last virtual interim to post this list to the mailing list. I would suggest that "hello-timeout" and "idle-timeout" are common enough to add. Not sure about the rest. leaf default-style { type enumeration { enum "report-all" { value 0; } enum "trim" { value 1; } enum "explicit" { value 2; } } default 'explicit'; description "Selects the type of filtering behavior the server will advertise as the 'basic' behavior in the 'with-defaults' capability. The server will use this default handling behavior if the 'with-defaults' parameter is not explicitly set. Also, when saving a configuration to NV-storage, this value will be used for filtering defaults from the saved configuration. See wd:with-defaults leaf for enumeration details."; } leaf eventlog-size { type uint32; default '1000'; description "Specifies the maximum number of notification events that will be saved in the notification replay buffer. The oldest entries will be deleted first."; } leaf hello-timeout { type uint32 { range "0 | 10 .. 3600"; } units "seconds"; default '600'; description "Specifies the number of seconds that a session may exist before the hello PDU is received. A session will be dropped if no hello PDU is received before this number of seconds elapses. If this parameter is set to zero, then the server will wait forever for a hello message, and not drop any sessions stuck in 'hello-wait' state. Setting this parameter to zero may permit denial of service attacks, since only a limited number of concurrent sessions are supported by the server."; } leaf idle-timeout { type uint32 { range "0 | 10 .. 360000"; } units "seconds"; default '3600'; description "Specifies the number of seconds that a session may remain idle without issuing any RPC requests. A session will be dropped if it is idle for an interval longer than this number of seconds. Sessions that have a notification subscription active are never dropped. If this parameter is set to zero, then the server will never drop a session because it is idle."; } leaf max-sessions { type uint16 { range "0 .. 1024"; } default '8'; description "Specifies the maximum number of concurrent sessions that can be active at one time. The value 0 indicates that no artificial session limit should be used."; } leaf message-indent { type int8 { range "-1 .. 9"; } default "-1"; description "The number of spaces to indent for each level of output in a protocol message, e.g. NETCONF request. The value zero means no indent, just line feeds. The value -1 means no indent and no line feeds either."; } leaf protocols { type bits { bit netconf1.0 { position 0; description "RFC 4741 base:1.0"; } bit netconf1.1 { position 1; description "RFC 6241 base:1.1"; } } must ". != ''"; description "Specifies which protocol versions the program or session will attempt to use. Empty set is not allowed."; } leaf superuser { type union { type nt:NcxName; type string { length "0"; } } description "The user name to use as the superuser account. Any session associated with this user name will bypass all access control enforcement. See yuma-nacm.yang for more details. To disable the superuser account completely, set this parameter to the empty string or do not set it at all. The default mode is to disable superuser access."; } leaf system-sorted { type boolean; default 'true'; description "Indicates whether ordered-by system leaf-lists and lists will be kept in sorted order."; } leaf target { type enumeration { enum "running" { value 0; description "Write to the running config and support the :writable-running capability."; } enum "candidate" { value 1; description "Write to the candidate config and support the :candidate and :confirmed-commit capabilities."; } } default 'candidate'; description "The database to use as the target of edit-config operations."; } leaf usexmlorder { type empty; description "If present, then XML element order will be enforced. Otherwise, XML element order errors will not be generated if possible. Default is no enforcement of strict XML order."; } leaf with-notifications { type boolean; default 'true'; description "If set to 'true', then the :notification:1.0 and :interleave:1.0 capabilities will be enabled. Otherwise, these capabilities will not be enabled."; } leaf with-startup { type boolean; default 'false'; description "If set to 'true', then the :startup capability will be enabled. Otherwise, the :startup capability will not be enabled. This capability makes the NV-save operation an explicit operation instead of an automatic save."; } leaf with-url { type boolean; default 'true'; description "If set to 'true', then the :url capability will be enabled. Otherwise, the :url capability will not be enabled. This capability requires a file system and may introduce security risks because internal files such as startup-cfg.xml and backup-cfg.xml will be exposed."; } leaf with-validate { type boolean; default 'true'; description "If set to 'true', then the :validate capability will be enabled. Otherwise, the :validate capability will not be enabled. This capability requires extensive memory resources."; } --001a11c2d150333813050401a293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I was asked to look through our pro= prietary server config module
and pick out the leafs that were no= t implementation-specific.
I picked a server subset (left out all= logging, module config).

I am not proposing that = all these leafs be added to the netconf-server
module.=A0 I am ju= st completing an action item from
the last virtual interim to pos= t this list to the mailing list.
I would suggest that "hello= -timeout" and "idle-timeout"
are common enough to = add. Not sure about the rest.


=
=A0 =A0 leaf default-style {
=A0 =A0 =A0 type enum= eration {
=A0 =A0 =A0 =A0 enum "report-all" {
=A0 =A0 =A0 =A0 =A0 value 0;
=A0 =A0 =A0 =A0 }
=A0 =A0= =A0 =A0 enum "trim" {
=A0 =A0 =A0 =A0 =A0 value 1;
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 enum "explicit"= ; {
=A0 =A0 =A0 =A0 =A0 value 2;
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 }
=A0 =A0 =A0 default 'explicit';
=
=A0 =A0 =A0 description
=A0 =A0 =A0 =A0 "Selects the ty= pe of filtering behavior the server will
=A0 =A0 =A0 =A0 =A0 =A0 = advertise as the 'basic' behavior in the 'with-defaults'
=A0 =A0 =A0 =A0 =A0 =A0 capability.=A0 The server will use this def= ault handling
=A0 =A0 =A0 =A0 =A0 =A0 behavior if the 'with-d= efaults' parameter is not=A0
=A0 =A0 =A0 =A0 =A0 =A0 explicit= ly set.

=A0 =A0 =A0 =A0 =A0 =A0 Also, when saving = a configuration to NV-storage,
=A0 =A0 =A0 =A0 =A0 =A0 this value= will be used for filtering defaults
=A0 =A0 =A0 =A0 =A0 =A0 from= the saved configuration.

=A0 =A0 =A0 =A0 =A0 =A0 = See wd:with-defaults leaf for enumeration details.";
=A0 =A0= }

=A0 =A0 leaf eventlog-size {
=A0 =A0 = =A0 type uint32;
=A0 =A0 =A0 default '1000';
= =A0 =A0 =A0 description
=A0 =A0 =A0 =A0 "Specifies the maxim= um number of notification events
=A0 =A0 =A0 =A0 =A0 =A0 that wil= l be saved in the notification replay buffer.
=A0 =A0 =A0 =A0 =A0= =A0 The oldest entries will be deleted first.";
=A0 =A0 }

=A0 =A0 leaf hello-timeout {
=A0 =A0 =A0 = type uint32 {
=A0 =A0 =A0 =A0 range "0 | 10 .. 3600";
=A0 =A0 =A0 }
=A0 =A0 =A0 units "seconds";
=A0 =A0 =A0 default '600';
=A0 =A0 =A0 description=
=A0 =A0 =A0 =A0 "Specifies the number of seconds that a ses= sion
=A0 =A0 =A0 =A0 =A0 =A0 may exist before the hello PDU is re= ceived.
=A0 =A0 =A0 =A0 =A0 =A0 A session will be dropped if no h= ello PDU=A0
=A0 =A0 =A0 =A0 =A0 =A0 is received before this numbe= r of seconds elapses.

=A0 =A0 =A0 =A0 =A0 =A0 If t= his parameter is set to zero, then the server
=A0 =A0 =A0 =A0 =A0= =A0 will wait forever for a hello message, and not
=A0 =A0 =A0 = =A0 =A0 =A0 drop any sessions stuck in 'hello-wait' state.

=A0 =A0 =A0 =A0 =A0 =A0 Setting this parameter to zero may= permit
=A0 =A0 =A0 =A0 =A0 =A0 denial of service attacks, since = only a limited
=A0 =A0 =A0 =A0 =A0 =A0 number of concurrent sessi= ons are supported
=A0 =A0 =A0 =A0 =A0 =A0 by the server.";
=A0 =A0 }


=A0 =A0 leaf idl= e-timeout {
=A0 =A0 =A0 type uint32 {
=A0 =A0 =A0 =A0 r= ange "0 | 10 .. 360000";
=A0 =A0 =A0 }
=A0 = =A0 =A0 units "seconds";
=A0 =A0 =A0 default '3600&= #39;;
=A0 =A0 =A0 description
=A0 =A0 =A0 =A0 "Spe= cifies the number of seconds that a session
=A0 =A0 =A0 =A0 =A0 = =A0 may remain idle without issuing any RPC requests.
=A0 =A0 =A0= =A0 =A0 =A0 A session will be dropped if it is idle for an
=A0 = =A0 =A0 =A0 =A0 =A0 interval longer than this number of seconds.
=
=A0 =A0 =A0 =A0 =A0 =A0 Sessions that have a notification su= bscription
=A0 =A0 =A0 =A0 =A0 =A0 active are never dropped.=A0

=A0 =A0 =A0 =A0 =A0 =A0 If this parameter is set to= zero, then the server
=A0 =A0 =A0 =A0 =A0 =A0 will never drop a = session because it is idle.";
=A0 =A0 }

=
=A0 =A0 leaf max-sessions {
=A0 =A0 =A0 type uint16 {
<= div>=A0 =A0 =A0 =A0 range "0 .. 1024";
=A0 =A0 =A0 }
=A0 =A0 =A0 default '8';
=A0 =A0 =A0 description<= /div>
=A0 =A0 =A0 =A0 "Specifies the maximum number of concurrent = sessions
=A0 =A0 =A0 =A0 =A0 =A0that can be active at one time.= =A0 The value 0 indicates
=A0 =A0 =A0 =A0 =A0 =A0that no artifici= al session limit should be used.";
=A0 =A0 }

<= /div>
=A0 =A0 leaf message-indent {
=A0 =A0 =A0 type int8 {
=A0 =A0 =A0 =A0 range "-1 .. 9";
=A0 =A0 =A0 }=
=A0 =A0 =A0 default "-1";
=A0 =A0 =A0 descri= ption
=A0 =A0 =A0 =A0 "The number of spaces to indent for ea= ch level of
=A0 =A0 =A0 =A0 =A0output in a protocol message, e.g.= NETCONF request.
=A0 =A0 =A0 =A0 =A0The value zero means no inde= nt, just line feeds.
=A0 =A0 =A0 =A0 =A0The value -1 means no ind= ent and no line feeds either.";
=A0 =A0 }

=A0 =A0 leaf protocols {
=A0 =A0 =A0 type bits {
=A0 =A0 =A0 =A0 bit netconf1.0 {
=A0 =A0 =A0 =A0 =A0 position 0;=
=A0 =A0 =A0 =A0 =A0 description "RFC 4741 base:1.0";
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 bit netconf1.1 {
=
=A0 =A0 =A0 =A0 =A0 position 1;
=A0 =A0 =A0 =A0 =A0 descript= ion "RFC 6241 base:1.1";
=A0 =A0 =A0 =A0 }
= =A0 =A0 =A0 }
=A0 =A0 =A0 must ". !=3D ''";
=A0 =A0 =A0 description
=A0 =A0 =A0 =A0 "Specifies wh= ich protocol versions the program or session
=A0 =A0 =A0 =A0 =A0w= ill attempt to use. Empty set is not allowed.";
=A0 =A0 }

=A0 =A0 leaf superuser {
=A0 =A0 =A0 type = union {
=A0 =A0 =A0 =A0 type nt:NcxName;
=A0 =A0 =A0 = =A0 type string {
=A0 =A0 =A0 =A0 =A0 length "0";
=
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 }
=A0 =A0 =A0 descri= ption
=A0 =A0 =A0 =A0 "The user name to use as the superuser= account.
=A0 =A0 =A0 =A0 =A0 =A0Any session associated with this= user name=A0
=A0 =A0 =A0 =A0 =A0 =A0will bypass all access contr= ol enforcement.
=A0 =A0 =A0 =A0 =A0 =A0See yuma-nacm.yang for mor= e details.

=A0 =A0 =A0 =A0 =A0 =A0To disable the s= uperuser account completely,
=A0 =A0 =A0 =A0 =A0 =A0set this para= meter to the empty string or do
=A0 =A0 =A0 =A0 =A0 =A0not set it= at all. The default mode is to
=A0 =A0 =A0 =A0 =A0 disable super= user access.";
=A0 =A0 }

=A0 =A0 le= af system-sorted {
=A0 =A0 =A0 type boolean;
=A0 =A0 = =A0 default 'true';
=A0 =A0 =A0 description
=A0= =A0 =A0 =A0 "Indicates whether ordered-by system leaf-lists=A0
<= div>=A0 =A0 =A0 =A0 =A0 =A0and lists will be kept in sorted order.";
=A0 =A0 }

=A0 =A0 leaf target {
=A0 =A0 =A0 type enumeration {
=A0 =A0 =A0 =A0 enum "runnin= g" {
=A0 =A0 =A0 =A0 =A0 value 0;
=A0 =A0 =A0 =A0 = =A0 description
=A0 =A0 =A0 =A0 =A0 =A0 "Write to the runnin= g config and support
=A0 =A0 =A0 =A0 =A0 =A0 =A0 the :writable-ru= nning capability.";
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 = =A0 enum "candidate" {
=A0 =A0 =A0 =A0 =A0 value 1;
=A0 =A0 =A0 =A0 =A0 description
=A0 =A0 =A0 =A0 =A0 =A0 &q= uot;Write to the candidate config and support
=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0the :candidate and :confirmed-commit=A0
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0capabilities.";
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 }
=A0 =A0 =A0 default 'candidate';
=A0 =A0 =A0 description
=A0 =A0 =A0 =A0 "The database to = use as the target of edit-config
=A0 =A0 =A0 =A0 =A0 =A0operation= s.";
=A0 =A0 }

=A0 =A0 leaf usexmlo= rder {
=A0 =A0 =A0 type empty;
=A0 =A0 =A0 description<= /div>
=A0 =A0 =A0 =A0 "If present, then XML element order will be = enforced.
=A0 =A0 =A0 =A0 =A0 =A0Otherwise, XML element order err= ors will not be
=A0 =A0 =A0 =A0 =A0 =A0generated if possible. Def= ault is no enforcement of
=A0 =A0 =A0 =A0 =A0 =A0strict XML order= .";
=A0 =A0 }

=A0 =A0 leaf with-not= ifications {
=A0 =A0 =A0 type boolean;
=A0 =A0 =A0 defa= ult 'true';
=A0 =A0 =A0 description
=A0 =A0 =A0= =A0 "If set to 'true', then the :notification:1.0 and
=A0 =A0 =A0 =A0 =A0 =A0:interleave:1.0 capabilities will be enabled.
=A0 =A0 =A0 =A0 =A0 =A0Otherwise, these capabilities will not be ena= bled.";
=A0 =A0 }

=A0 =A0 leaf with= -startup {
=A0 =A0 =A0 type boolean;
=A0 =A0 =A0 defaul= t 'false';
=A0 =A0 =A0 description
=A0 =A0 =A0 = =A0 "If set to 'true', then the :startup capability will be=A0=
=A0 =A0 =A0 =A0 =A0 =A0enabled. Otherwise, the :startup capabili= ty
=A0 =A0 =A0 =A0 =A0 =A0will not be enabled.=A0 This capability= =A0
=A0 =A0 =A0 =A0 =A0 =A0makes the NV-save operation an explici= t operation
=A0 =A0 =A0 =A0 =A0 =A0instead of an automatic save.&= quot;;
=A0 =A0 }

=A0 =A0 leaf with-url {=
=A0 =A0 =A0 type boolean;
=A0 =A0 =A0 default 'tru= e';
=A0 =A0 =A0 description
=A0 =A0 =A0 =A0 "I= f set to 'true', then the :url capability will be=A0
=A0 = =A0 =A0 =A0 =A0 =A0enabled. Otherwise, the :url capability
=A0 = =A0 =A0 =A0 =A0 =A0will not be enabled.=A0 This capability requires a
=
=A0 =A0 =A0 =A0 =A0 =A0file system and may introduce security risks
=A0 =A0 =A0 =A0 =A0 =A0because internal files such as startup-cfg.x= ml
=A0 =A0 =A0 =A0 =A0 =A0and backup-cfg.xml will be exposed.&quo= t;;
=A0 =A0 }

=A0 =A0 leaf with-validate= {
=A0 =A0 =A0 type boolean;
=A0 =A0 =A0 default 't= rue';
=A0 =A0 =A0 description
=A0 =A0 =A0 =A0 "= ;If set to 'true', then the :validate capability will be=A0
=A0 =A0 =A0 =A0 =A0 =A0enabled. Otherwise, the :validate capability
=A0 =A0 =A0 =A0 =A0 =A0will not be enabled.=A0 This capability requir= es
=A0 =A0 =A0 =A0 =A0 =A0extensive memory resources.";
=A0 =A0 }



 --001a11c2d150333813050401a293-- From nobody Mon Sep 29 15:23:54 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8251ACD69; Mon, 29 Sep 2014 15:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vIBlxJdLaf2; Mon, 29 Sep 2014 15:23:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1661ACD40; Mon, 29 Sep 2014 15:23:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: kwatsen@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140929222350.27001.823.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 15:23:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3KKqqMNFVB4-KDEmAaoOLodXD5g Cc: joelja@bogus.com, netconf@ietf.org, ipr-announce@ietf.org Subject: [Netconf] IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-netconf-call-home-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 22:23:52 -0000 Dear Kent Watsen: An IPR disclosure that pertains to your Internet-Draft entitled "NETCONF Call Home" (draft-ietf-netconf-call-home) was submitted to the IETF Secretariat on 2014-09-29 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2445/). The title of the IPR disclosure is "Juniper's Statement of IPR related to draft-ietf-netconf-call- home-00.""); The IETF Secretariat From nobody Mon Sep 29 17:00:55 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E95B1ACE29 for ; Mon, 29 Sep 2014 17:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1wUN-ycogZO for ; Mon, 29 Sep 2014 17:00:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71751ACDEA for ; Mon, 29 Sep 2014 17:00:51 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 00:00:28 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.194]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.194]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 00:00:28 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-netconf-call-home-00 Thread-Index: AQHP3DQSl3xqyO+geEuW7oc1k1PrhZwYVVOA Date: Tue, 30 Sep 2014 00:00:27 +0000 Message-ID: References: <20140929222350.27001.823.idtracker@ietfa.amsl.com> In-Reply-To: <20140929222350.27001.823.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(24454002)(377454003)(377424004)(189002)(164054003)(479174003)(107046002)(36756003)(106116001)(99286002)(83506001)(85306004)(105586002)(4396001)(2501002)(95666004)(97736003)(31966008)(77096002)(101416001)(19580395003)(19580405001)(85852003)(92726001)(230783001)(15975445006)(46102003)(86362001)(66066001)(110136001)(76482002)(20776003)(99396003)(80022003)(92566001)(76176999)(107886001)(21056001)(50986999)(106356001)(54356999)(2656002)(64706001)(120916001)(10300001)(2351001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zZ3znJXTgeDFCyj0IRNCo4KwhSg Subject: Re: [Netconf] IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-netconf-call-home-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 00:00:53 -0000 All, This is the same IPR that we discussed before when it was on the reverse-ssh draft. Since the call-home draft subsumes the reverse-ssh draft, the IPR needed to be attached to the new draft as well. Thanks, Kent On 9/29/14, 3:23 PM, "IETF Secretariat" wrote: > >Dear Kent Watsen: > > An IPR disclosure that pertains to your Internet-Draft entitled "NETCONF >Call >Home" (draft-ietf-netconf-call-home) was submitted to the IETF >Secretariat on >2014-09-29 and has been posted on the "IETF Page of Intellectual Property >Rights >Disclosures" (https://datatracker.ietf.org/ipr/2445/). The title of the >IPR >disclosure is "Juniper's Statement of IPR related to >draft-ietf-netconf-call- >home-00.""); > >The IETF Secretariat > From nobody Tue Sep 30 06:39:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B821A1A12; Tue, 30 Sep 2014 06:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saUkhRDEr2rB; Tue, 30 Sep 2014 06:39:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 303C91A0362; Tue, 30 Sep 2014 06:39:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140930133904.2655.9211.idtracker@ietfa.amsl.com> Date: Tue, 30 Sep 2014 06:39:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/QFG7S7xoZKR7X4rT84qy_cT3I3g Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 13:39:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Protocol over Transport Layer Security (TLS) Authors : Mohamad Badra Alan Luchuk Juergen Schoenwaelder Filename : draft-ietf-netconf-rfc5539bis-06.txt Pages : 10 Date : 2014-09-30 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing for NETCONF 1.1 and it obsoletes RFC 5539. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 30 14:46:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E301A924B for ; Tue, 30 Sep 2014 14:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8r0mVHN9mjY4 for ; Tue, 30 Sep 2014 14:45:54 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id D58B71A9177 for ; Tue, 30 Sep 2014 14:45:53 -0700 (PDT) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA12525; Tue, 30 Sep 2014 17:45:51 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id s8ULjrvL024178; Tue, 30 Sep 2014 17:45:53 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id s8ULjq7q024177; Tue, 30 Sep 2014 17:45:52 -0400 (EDT) (envelope-from luchuk) Date: Tue, 30 Sep 2014 17:45:52 -0400 (EDT) From: Alan Luchuk Message-Id: <201409302145.s8ULjq7q024177@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/idDekw0KBd-mfxq8aeTULQazLC0 Cc: jshoenwaelder@jacobs-university.de Subject: [Netconf] Comments on draft-ietf-netconf-server-model-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:45:58 -0000 Hello, Included below are comments about draft-ietf-netconf-server-model-03.txt. I gave the most thought to the sections relating to NETCONF over TLS, but did look over the rest of the document fairly carefully. I hope these are helpful and useful to the WG. Section 1, Page 2-3: Nit ------------------------- s/what ports does the server listen on/what port the server listens on/ Section 2: Page 3: Nit ------------------------- s/the NETCONF service on the/the NETCONF communication service on the/ Sections 2.1 and 2.3, Pages 3 and 4 Nit ---------------------------------------- s/Since/Because/ Section 2.4.2, Page 4: Spelling -------------------------------- s/any of the applications/any of the application's/ Section 2.4.6, Page 5: Nit --------------------------- s/aliveness/"aliveness"/ Section 2.4.6, Page 5: Spelling -------------------------------- s/applications requirements/applications' requirements/ General comments ---------------- Not sure if all of the groupings would be useful outside of this document. Some of the groupings have only a single "uses" within the document; e.g., call-home-transport-config, call-home-config, etc. It seems as if this was done to break up one large config into smaller chunks. I find this use of grouping/uses makes the YANG module more difficult to read and understand than if these single-use grouping/users were simply inserted in-line. Comments on the listen-per-transport-config grouping, Page 12: -------------------------------------------------------------- Under the description of the address leaf: s/IP address\/name/IP address or host name/ Under the port leaf: Should this leaf be mandatory, or have a default of 0? The listen-per-transport-config grouping seems roughly like a "sockaddr_storage" structure. An "endpoint", or perhaps a "sockaddr" or "socket" grouping seems like it would be useful in many YANG modules beyond this one. Would it be worthwhile to generalize this grouping, and simplify its use either by putting it in its own (non-server-specific) YANG module, or possibly by promoting into a new rev of the ietf-inet-types YANG module? Perhaps the following might be a generalized grouping: grouping endpoint { description "Specifies the address and port for a transport endpoint." leaf address { type inet:host; mandatory true; description "The IP address or host name for the transport endpoint."; } leaf port { type inet:port-number; description "The port number for the transport endpoint."; default 0; } } /* grouping endpoint */ Comments on the call-home-per-transport-config grouping, Page 14: ----------------------------------------------------------------- This grouping seems generally useful beyond the configuration of call-home configuration. It looks like basically like a list of endpoints, or "sockaddrs". Perhaps generalizing this and putting it into the same YANG module with the revised listen-per-transport-config grouping might simplify its wider use. I _suspect_ I know the answer to this, but what is the purpose of the "endpoints" container around the "endpoint" list? The name leaf seems to serve basically as a key for the list. Would it be possible to eliminate this leaf, and use the address and port leaves as keys? This would slightly simplify the grouping. It might also use the "endpoint" grouping suggested above, and further re-use definitions. Perhaps the following might be a generalized grouping? grouping endpoints-grouping { description "Grouping for a list of transport endpoints."; container endpoints { description "Container for the list of endpoints."; list endpoint-list { key "address port"; /* min-elements 1; Necessary or useful if generalized? */ /* ordered-by user; Necessary or useful if generalized? */ description "List of transport endpoints." uses endpoint; } /* list endpoint-list */ } /* container endpoints */ } /* grouping endpoints-grouping */ Comments on the listen-config grouping, Page 11: ------------------------------------------------ It seems like the listen-per-transport-config could be promoted from from below each case branch to above the "choice transport". Does the name leaf does have a function other than providing a list key? If the listen-per-transport-config were promoted, then the address and port could be used as keys, no? This would simplify the grouping. Perhaps something like: grouping listen-config { description "Grouping for listen configuration."; uses endpoint; /* The new grouping, described above */ choice transport { mandatory true; description "Selects between SSH and TLS transports."; case ssh { if-feature ssh-listen; container ssh { description "SSH-specific listening configuration for inbound connections."; refine port { default 830; } } } case tls { if-feature tls-listen; container tls { description "TLS-specific listening configuration for inbound connections."; refine port { default 6513; } } } } } Then, where this grouping is used: container netconf-server { description "Top-level container for NETCONF server configuration."; list listen { key "address port"; description "List of endpoints to listen for connections on."; //if-feature "(ssh-listen or tls-listen)"; uses listen-config; Comments on the call-home-connection-type-config grouping, Page 15: ------------------------------------------------------------------- Under the persistent-connection case, there is a "container persistent" and, under that, a "container keep-alives". What is the function of the extra containment layer? Would it make sense to remove one of these containment layers? Comments on the call-home-reconnection-strategy-config grouping, Page 17: ------------------------------------------------------------------------- What determines the order in which management applications are contacted by call-home connections? Is it the name key of the endpoint list in the call-home-per-transport-config grouping? How is the last-connected reconnection strategy handled across reboots of devices without stable storage? Or is the "no stable storage" situ- ation out-of-scope? Comments on the trusted-ca-certs-grouping grouping, Page 17: ------------------------------------------------------------ Is it expected that this grouping may be used elsewhere in other YANG modules? Is it intended that the trusted-ca-cert leaf-list is used for root (self-signed) CA certs only, or are subordinate CA certs allowed also? If this leaf-list is intended for self-signed CA certs only, then how are CA cert chains handled? Comments on the trusted-client-certs-grouping grouping, Page 17: ---------------------------------------------------------------- What is the purpose of this grouping? As it is documented, this grouping may be unnecessary. When a management application connects to the NETCONF Server, either by forward or reverse (call-home) TLS, the management application will present an application cert (or cert chain) that identifies it. Two things have to happen for the NETCONF Server to authenticate the management application: 1) The application cert presented by the management application must pass certificate verification up through one of the CA certs configured (in the NETCONF server) in the trusted-ca-certs-grouping, and 2) the NETCONF server must be able to convert this application cert to the NETCONF NACM username. Based upon the way the TLS authentication works (described in the previous paragraph), and the description of the trusted-client-certs container, I don't see what the function of this grouping is. What am I missing here? Should the trusted-client-certs-grouping be deleted? Comments on the cert-maps-grouping, Page 19: -------------------------------------------- The x509c2n:cert-to-name grouping defined in the ietf-x509-cert-to-name YANG module defined in draft-ietf-netmod-snmp-cfg-08.txt looks fine. Other comments on the NETCONF-over-TLS configuration: ------------------------------------------------------- When a NETCONF over TLS session is initiated, the NETCONF server must present an X.509 certificate to the NETCONF client so the client can verify the identity of the NETCONF server. I do not see any mechanism for configuring an X.509 certificate that identifies the NETCONF server. Should there be such an object, or is this something that can only be configured out-of-band, or perhaps only by the manufacturer? 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 at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Tue Sep 30 23:35:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A4E1A0065 for ; Tue, 30 Sep 2014 23:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIdZf4rGPvTe for ; Tue, 30 Sep 2014 23:35:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7411A00E8 for ; Tue, 30 Sep 2014 23:34:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 982EDE7D; Wed, 1 Oct 2014 08:34:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4uVB4Lpaq3YT; Wed, 1 Oct 2014 08:34:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 1 Oct 2014 08:34:57 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2903820035; Wed, 1 Oct 2014 08:34:57 +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 6bnkR18ic8UN; Wed, 1 Oct 2014 08:34:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DE9520036; Wed, 1 Oct 2014 08:34:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1166F2EBD3CE; Wed, 1 Oct 2014 08:34:56 +0200 (CEST) Date: Wed, 1 Oct 2014 08:34:56 +0200 From: Juergen Schoenwaelder To: Alan Luchuk Message-ID: <20141001063455.GE36781@elstar.local> Mail-Followup-To: Alan Luchuk , netconf@ietf.org References: <201409302145.s8ULjq7q024177@mainfs.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409302145.s8ULjq7q024177@mainfs.snmp.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zKXo9L-Q8IgBxRKBewGoon5wgKs Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-server-model-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 06:35:01 -0000 On Tue, Sep 30, 2014 at 05:45:52PM -0400, Alan Luchuk wrote: > It seems like the listen-per-transport-config could be promoted from > from below each case branch to above the "choice transport". Does the > name leaf does have a function other than providing a list key? If the > listen-per-transport-config were promoted, then the address and port > could be used as keys, no? This would simplify the grouping. I would be very careful about making addres and port the key since this makes extensions impossible, e.g., if you have to support VRFs. See also draft-schoenw-netmod-yang-pattern-00.txt. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103