From nobody Wed Oct 1 06:21: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 A45D91A03A6; Wed, 1 Oct 2014 06:20:56 -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 hU9gq2p4nfA9; Wed, 1 Oct 2014 06:20:52 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416C61A047A; Wed, 1 Oct 2014 06:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=480; q=dns/txt; s=iport; t=1412169652; x=1413379252; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=fcpXfOV5zBjfYmmEMJyQUpQ7tdthexNWcmIfQFunruk=; b=dnlAIGeZoDoY+B/jIOJIWZbYYlLRYNiZzKylrwHOrV9qwXGAdQbkam+C PFMdeZaHLAXOeBh2CA9FcD61XHDcTMGjNPe72c1XdRKy5WmO22tBJhGqq 3h4gvtwrNmZ+WgWfIcd3duxaHMtHi+V8M1dBGrFwoYB2J592Y3Jmky5xP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsEABX/K1StJssW/2dsb2JhbABgg2FayjuHTYEjAXuEQkABPBYYAwIBAgFLDQEHAQGIOg2+GAEXkCaEUgEElimHCoFlhXOOG4NlO4J5AQEB X-IronPort-AV: E=Sophos;i="5.04,632,1406592000"; d="scan'208";a="191267289" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Oct 2014 13:20:50 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s91DKnsU026195; Wed, 1 Oct 2014 13:20:49 GMT Message-ID: <542BFFB1.2070708@cisco.com> Date: Wed, 01 Oct 2014 15:20:49 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/D1CNsviA99tlYtR0P8lgORcuJlo Cc: "anima@ietf.org" Subject: [Netconf] NETCONF feedback on the ANIMA charter 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, 01 Oct 2014 13:20:56 -0000 Dear all, Based on the previous UCAN BoF, we are considering having an ANIMA WG: Autonomic Networking Integrated Model and Approach This is now a proposed charter, under consideration by the IESG. This is your chance to provide feedback on http://datatracker.ietf.org/wg/anima/charter/ Note also that a BoF has been requested, just in case. Since NETCONF (zero-touch) was mentioned during the UCAN BoF, I thought of double-checking with you guys. Regards, Benoit From nobody Wed Oct 1 17:11: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 AB8B61A8860; Wed, 1 Oct 2014 17:11: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, 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 Le4erQeFi3SU; Wed, 1 Oct 2014 17:11:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621571A8843; Wed, 1 Oct 2014 17:11:17 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB501.namprd05.prod.outlook.com (10.141.59.140) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 2 Oct 2014 00:11:16 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 2 Oct 2014 00:11:14 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Thu, 2 Oct 2014 00:11:14 +0000 From: Dean Bogdanovic To: Brian E Carpenter Thread-Topic: [Anima] NETCONF feedback on the ANIMA charter Thread-Index: AQHP3XqXxIOoSxhu4E6EWmKeKRaI65wb14qAgAAYQYA= Date: Thu, 2 Oct 2014 00:11:14 +0000 Message-ID: <72CD9A3D-F4E4-4E06-A27F-54E06D4674E3@juniper.net> References: <542BFFB1.2070708@cisco.com> <542C83C9.3010700@gmail.com> In-Reply-To: <542C83C9.3010700@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174003)(24454002)(189002)(199003)(51704005)(15202345003)(104166001)(92726001)(33656002)(101416001)(87286001)(31966008)(107046002)(82746002)(19580395003)(62966002)(2656002)(99396003)(50226001)(87936001)(4396001)(110136001)(89996001)(85852003)(83716003)(76176999)(120916001)(97736003)(19580405001)(88136002)(57306001)(92566001)(93916002)(76482002)(86362001)(20776003)(85306004)(105586002)(66066001)(77156001)(15975445006)(64706001)(21056001)(10300001)(95666004)(36756003)(80022003)(77096002)(99286002)(46102003)(106116001)(50986999)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <9518215537358645A3ED00AA2C3AD1A6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB501; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/OQbHu4tgmroy_p94iyDEaGOkPyg Cc: NETCONF , "anima@ietf.org" Subject: Re: [Netconf] [Anima] NETCONF feedback on the ANIMA charter 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, 02 Oct 2014 00:11:23 -0000 Brian, I believe that ANIMA WG can raise some additional requirements to the NETCO= NF group for configuration protocol requirements, hence it would be useful = to follow what is being developed in that group. Dean On Oct 1, 2014, at 6:44 PM, Brian E Carpenter = wrote: > Hi, >=20 > Several of us learned about draft-ietf-netconf-zerotouch > for the first time in Toronto. Clearly, the Anima WG if formed > will have to consider it as well as any other proposals for > that functionality. We have an explicit statement in the charter: >=20 > "Where suitable protocols, models or methods exist, they will be > preferred over creating new ones." >=20 > Apart from that, coexistence with netconf is a clear constraint > on what we do, and that is also explicit in the charter. >=20 > Brian >=20 > On 02/10/2014 02:20, Benoit Claise wrote: >> Dear all, >>=20 >> Based on the previous UCAN BoF, we are considering having an ANIMA WG: >> Autonomic Networking Integrated Model and Approach >> This is now a proposed charter, under consideration by the IESG. >> This is your chance to provide feedback on >> http://datatracker.ietf.org/wg/anima/charter/ >> Note also that a BoF has been requested, just in case. >> Since NETCONF (zero-touch) was mentioned during the UCAN BoF, I thought >> of double-checking with you guys. >>=20 >> Regards, Benoit >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Oct 2 00:14: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 93ABE1A8821; Wed, 1 Oct 2014 15:44:23 -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 RJUyu1YaOOWr; Wed, 1 Oct 2014 15:44:22 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e: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 B8A1C1A87CC; Wed, 1 Oct 2014 15:44:21 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id rd3so1089044pab.20 for ; Wed, 01 Oct 2014 15:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OZKm7vXKtGga32l7FrxqxzHibgDyJBBW9Wq2gfu5uQA=; b=hylJV73QTonRiBkCnQFFiy0hTpo784bBYB/zXKGrH1kTe6jLJ8GaSpyb9zRO2xf8zc 6rwU3meLT0ipT86RE64v+RQKBeD9EZ5AUTpQLPGmKmUBMpDYR7/0AQp0VlQf8Clxt62/ psJbRg2tCkP6CuZvDb+4RW0JVN3lgL2ir7I4rM0gCN2GYLF+v3D/hEfUAjJ2p3aYN6FR Z8CjZbm7CgvE8WCkD2CFKGirix+V3pOFlSIahau5h0ke+vbmmOOF2thRAZ6irP7PONLa 7iT+pT7EAkXPB1++NfPgsm3LkpCHvpoiHsdSNr3OZ4lTgCWIU7w+VvAc8AEAYQqcdipi w36Q== X-Received: by 10.67.1.9 with SMTP id bc9mr81997798pad.42.1412203461493; Wed, 01 Oct 2014 15:44:21 -0700 (PDT) Received: from [192.168.178.23] (89.199.69.111.dynamic.snap.net.nz. [111.69.199.89]) by mx.google.com with ESMTPSA id qj2sm1839248pbc.78.2014.10.01.15.44.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 15:44:20 -0700 (PDT) Message-ID: <542C83C9.3010700@gmail.com> Date: Thu, 02 Oct 2014 11:44:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: NETCONF References: <542BFFB1.2070708@cisco.com> In-Reply-To: <542BFFB1.2070708@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/kDqWTyW16C3xTq6ilAkJluRbrR8 X-Mailman-Approved-At: Thu, 02 Oct 2014 00:14:19 -0700 Cc: "anima@ietf.org" Subject: Re: [Netconf] [Anima] NETCONF feedback on the ANIMA charter 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, 01 Oct 2014 22:44:23 -0000 Hi, Several of us learned about draft-ietf-netconf-zerotouch for the first time in Toronto. Clearly, the Anima WG if formed will have to consider it as well as any other proposals for that functionality. We have an explicit statement in the charter: "Where suitable protocols, models or methods exist, they will be preferred over creating new ones." Apart from that, coexistence with netconf is a clear constraint on what we do, and that is also explicit in the charter. Brian On 02/10/2014 02:20, Benoit Claise wrote: > Dear all, > > Based on the previous UCAN BoF, we are considering having an ANIMA WG: > Autonomic Networking Integrated Model and Approach > This is now a proposed charter, under consideration by the IESG. > This is your chance to provide feedback on > http://datatracker.ietf.org/wg/anima/charter/ > Note also that a BoF has been requested, just in case. > Since NETCONF (zero-touch) was mentioned during the UCAN BoF, I thought > of double-checking with you guys. > > Regards, Benoit > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Oct 3 05:08: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 AFD131A030C for ; Fri, 3 Oct 2014 05:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C0IkD5q4Zg8w for ; Fri, 3 Oct 2014 05:08:47 -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 158C21A02EF for ; Fri, 3 Oct 2014 05:08:46 -0700 (PDT) Received: from pc6 (31.49.54.177) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 3 Oct 2014 11:55:53 +0000 Message-ID: <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> From: t.petch To: References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> <20140321074646.GA12080@elstar.local> Date: Fri, 3 Oct 2014 11:45:32 +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: [31.49.54.177] X-ClientProxiedBy: AM3PR03CA044.eurprd03.prod.outlook.com (10.141.191.172) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-Forefront-PRVS: 0353563E2B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(199003)(189002)(62236002)(44716002)(116806002)(23756003)(77096002)(50466002)(14496001)(97736003)(95666004)(93886004)(85306004)(84392001)(105586002)(106356001)(107046002)(2351001)(107886001)(42186005)(110136001)(61296003)(229853001)(33646002)(76482002)(122386001)(76176999)(81816999)(50986999)(81686999)(104166001)(44736004)(101416001)(10300001)(4396001)(120916001)(99396003)(50226001)(93916002)(86362001)(21056001)(230783001)(87976001)(85852003)(66066001)(89996001)(88136002)(87286001)(92566001)(92726001)(64706001)(46102003)(80022003)(47776003)(62966002)(20776003)(31966008)(77156001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/VWoYdDrpZxyqgEx-NTu7BVDpnkU Subject: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 03 Oct 2014 12:08:49 -0000 I think that this still needs a tweak. In s.2.4.1, the sentence "If the NETCONF client has external information as to the expected identity of the NETCONF server, the hostname check MAY be omitted. " has been moved, to be immediately after the comment about performing certificate validation as per RFC5280. Which does not make good sense since RFC5280 is not about hostname checks. The sentence used to come after the references to RFC6125 which is about hostnames and so made more sense. But more fundamentally, I am unclear what this is saying. 'hostname check' does not appear anywhere else. There is talk of matching but I am unclear if that is intended. As it stands, the sentence would seem to say, get a certificate and then ignore its contents, in which case, I think that an example, or list, of suitable conditions needs to be there alongside the sentence, whereever the sentence is. Separately, given the focus there has been on call home and the different flavours thereof, I would like a sentence at the end of 2.1 pointing to the call-home document Tom Petch From nobody Fri Oct 3 05:14: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 A092B1A030C for ; Fri, 3 Oct 2014 05:14:53 -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_15=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 Mj8SUPhm9ZSt for ; Fri, 3 Oct 2014 05:14:51 -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 EC77F1A0352 for ; Fri, 3 Oct 2014 05:14:50 -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 1Xa1kz-0007oU-1z; Fri, 03 Oct 2014 14:14:47 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest126.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Xa1ky-0006wj-Ty; Fri, 03 Oct 2014 14:14:44 +0200 Message-ID: <542E9334.6010304@bwijnen.net> Date: Fri, 03 Oct 2014 14:14:44 +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: "t.petch" , netconf@ietf.org References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> <20140321074646.GA12080@elstar.local> <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> In-Reply-To: <002101cfdf00$b930a240$4001a8c0@gateway.2wire.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: 86ab03e524994f79ca2c75a176445dd47f0fa0838111b4c39a38d3588ed3a052 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/jQJdcFDg9TFQFNrDw3uIZ5hMK9k Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 03 Oct 2014 12:14:53 -0000 Thanks Tom. I am assuming that the authors/editors of the document will answer. Anyone else who has an opinion, please chime in too if you like. Bert (co-chair of NETCONF WG) On 03/10/14 12:45, t.petch wrote: > I think that this still needs a tweak. > > In s.2.4.1, the sentence > "If > the NETCONF client has external information as to the expected > identity of the NETCONF server, the hostname check MAY be omitted. > " > has been moved, to be immediately after the comment about performing > certificate validation as per RFC5280. Which does not make good sense > since RFC5280 is not about hostname checks. The sentence used to come > after the references to RFC6125 which is about hostnames and so made > more sense. > > But more fundamentally, I am unclear what this is saying. 'hostname > check' does not appear anywhere else. There is talk of matching but I > am unclear if that is intended. As it stands, the sentence would seem > to say, get a certificate and then ignore its contents, in which case, I > think that an example, or list, of suitable conditions needs to be there > alongside the sentence, whereever the sentence is. > > Separately, given the focus there has been on call home and the > different flavours thereof, I would like a sentence at the end of 2.1 > pointing to the call-home document > > Tom Petch > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Oct 3 12:02: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 3D7321A8897 for ; Fri, 3 Oct 2014 12:02:57 -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 PzH3rgSqVMpA for ; Fri, 3 Oct 2014 12:02:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27AA41A8884 for ; Fri, 3 Oct 2014 12:02:54 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Fri, 3 Oct 2014 19:02:51 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.196]) with mapi id 15.00.1044.008; Fri, 3 Oct 2014 19:02:51 +0000 From: Kent Watsen To: Alan Luchuk , "netconf@ietf.org" Thread-Topic: Comments on draft-ietf-netconf-server-model-03.txt Thread-Index: AQHP3PfuIWXKEogrdkyrjScW4AT0uZwefEcA Date: Fri, 3 Oct 2014 19:02:51 +0000 Message-ID: References: <201409302145.s8ULjq7q024177@mainfs.snmp.com> In-Reply-To: <201409302145.s8ULjq7q024177@mainfs.snmp.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.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(76104003)(189002)(43784003)(199003)(105586002)(230783001)(106116001)(106356001)(76482002)(99286002)(95666004)(64706001)(10300001)(85306004)(120916001)(99396003)(40100001)(77096002)(66066001)(4396001)(107046002)(122386001)(101416001)(20776003)(54356999)(76176999)(50986999)(36756003)(97736003)(2656002)(85852003)(21056001)(31966008)(87936001)(92566001)(86362001)(92726001)(19580395003)(15975445006)(83506001)(2501002)(15202345003)(46102003)(80022003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; 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/wrNFGGPnZv6eyqhsUARD6Ijq5VQ Cc: "jshoenwaelder@jacobs-university.de" 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 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:02:57 -0000 Hi Alan, Thank you for a fantastic review. I have already incorporated all your Nit comments. Please see below for other responses. Thanks again, Kent =20 >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=20 >of grouping/uses makes the YANG module more difficult to read and >understand=20 >than if these single-use grouping/users were simply inserted in-line. Correct, all but 2 of the 11 groupings are only used once. Interestingly, I did this to help make the module more readable. Of course I understand that chasing the definition can be cumbersome, but the tradeoff is that now each parent container can easily fit on the screen. I don't know, is there best practice to follow on this? FWIW, I added https://github.com/netconf-wg/server-model/issues/12 to track this issue. >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/ Fixed! >Under the port leaf: > > Should this leaf be mandatory, or have a default of 0? In both places where this grouping is used, a transport-specific default is provided (830 for SSH, 6513 for TLS). Is it good enough? >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. True, it would've been a nice addition to ietf-inet-types. What do others think? >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. Another good point. What do others think? >I _suspect_ I know the answer to this, but what is the purpose of the >"endpoints" container around the "endpoint" list? I thought that it was best practice to always have a parent container for a list. In RESTCONF terms, the container would be the "collection" and would render URLs like .../widgets/widget=3D/, which is a pretty commo= n idiom. That said, the module is itself inconsistent in that the top-level "listen" and "call-home" do NOT have parent containers. The module is trying to follow guildlines set by http://tools.ietf.org/html/draft-schoenw-netmod-yang-pattern-00. One option might be use this: +--rw netconf-server +--rw listen | +--rw endpoint* [name] | +--rw name string | ... +--rw call-home +--rw application* [name] +--rw name string | ... What do you think, is it better? >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. As Juergen mentioned already, this would prevent augmentations from supporting multiple routing instances (VRFs) if needed. >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 */ > =20 > 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; The solution used follows the guidelines set by draft-schoenw-netmod-yang-pattern-00. That said, I agree with you that flattening the model some would be nice. One issue in doing that, though, is how to set the transport-specific default port values, as the port node would longer be refine-able... >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? This is me just grouping things together for readability and extensibility. We could flatten the model some by having "keep-alive-interval-secs" and "keep-alive-count-max" - does that seem bester to you? Also, while the model doesn't currently have any other nodes under the "persistent" node, it may someday (perhaps through an augmentation), such that having this structure helps keeps things nice and organized. Thoughts? >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? No order is expected, a device could even connect to all it's "call-home" nodes in parallel. The draft defines the "call-home" list as unordered - is it good enough? - if not, what text would you suggest adding? The draft says in the description statement: "If no previous connection has ever been established, last-connected defaults to the first endpoint listed". What the draft fails to say is if the "previous connection" information needs to survive reboots. Do you think this choice could be left to implementations? >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? AFAIK, there is no known intension to use the grouping elsewhere. That said, you never know and, besides, I like to use groupings because I think it improves readability (YMMV). Yes, absolutely, subordinate certs are allowed. That said, there may still be an issue with supporting chains, such as when a client cert is signed by an intermediate CA that is signed by trust anchor CA. That is, the end user would like to configure the device to auth any client cert having a chain of trust leading to the trust anchor. Currently this is not possible because the wording "A client's certificate is authenticated if its Issuer matches one of the configured trusted CA certificates." does allow for indirections. This seems like an oversight to me, but I inherited this text and don't know if there is a reason behind it. Added https://github.com/netconf-wg/server-model/issues/13 to track this. >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? This grouping is provides an alternate mechanism to authenticate client certs. It is to auth a specific user without authenticating every other user's cert having the same Issuer. This came from issue #3 in this thread:=20 http://www.ietf.org/mail-archive/web/netconf/current/msg08825.html. Makes sense? >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? Yes, and this issue is tracked here: https://github.com/netconf-wg/server-model/issues/4 Question, do you think configuring the TLS-server-cert/SSH-host-key to use should be a system-wide configuration, or something specific to the NETCONF server? Thanks again, Kent From nobody Sun Oct 5 23:17: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 D21A21A1B43 for ; Sun, 5 Oct 2014 23:17:06 -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 q8JhyRCZcAGH for ; Sun, 5 Oct 2014 23:16:41 -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 040811A1B2C for ; Sun, 5 Oct 2014 23:16:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7E287E6F; Mon, 6 Oct 2014 08:16:39 +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 RVRJGdO3mZ7Y; Mon, 6 Oct 2014 08:16:37 +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, 6 Oct 2014 08:16:38 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45BC920036; Mon, 6 Oct 2014 08:16:38 +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 XZ-gcBJsg2bq; Mon, 6 Oct 2014 08:16: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 281FC20035; Mon, 6 Oct 2014 08:16:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16CC82EC3455; Mon, 6 Oct 2014 08:16:37 +0200 (CEST) Date: Mon, 6 Oct 2014 08:16:37 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20141006061636.GB51842@elstar.local> Mail-Followup-To: "t. petch" , netconf@ietf.org References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> <20140321074646.GA12080@elstar.local> <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pI2z8SYDfZzLx29drrZ9y7E12ek Cc: netconf@ietf.org Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 06 Oct 2014 06:17:07 -0000 On Fri, Oct 03, 2014 at 11:45:32AM +0100, t. petch wrote: > I think that this still needs a tweak. > > In s.2.4.1, the sentence > "If > the NETCONF client has external information as to the expected > identity of the NETCONF server, the hostname check MAY be omitted. > " > has been moved, to be immediately after the comment about performing > certificate validation as per RFC5280. Which does not make good sense > since RFC5280 is not about hostname checks. The sentence used to come > after the references to RFC6125 which is about hostnames and so made > more sense. To tell the truth, I find the section still confusing. There are too many MUST and MAYs interacting here. I also see that the second paragraph says MUST ask for user confirmation or terminate the connection. This also seems to conflict with the notion of 'whitelisted' certificates (which I think the 'client has external information as to the expected identity' boils down to). If you can come up with a rewrite of section 2.4.1 that makes all of this simpler and straight forward, this would actually be very much appreciated. > But more fundamentally, I am unclear what this is saying. 'hostname > check' does not appear anywhere else. There is talk of matching but I > am unclear if that is intended. As it stands, the sentence would seem > to say, get a certificate and then ignore its contents, in which case, I > think that an example, or list, of suitable conditions needs to be there > alongside the sentence, whereever the sentence is. No, it is not 'ignore its contents'. My understanding is you validate the certificate but the contained in the ticket is not checked against the expected hostname - instead you verify that the certificated is a known one. > Separately, given the focus there has been on call home and the > different flavours thereof, I would like a sentence at the end of 2.1 > pointing to the call-home document I disagree with this. We have moved all the call-home stuff to a different document and hence this transport specification should really be silent about call home. /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 Oct 6 06:35: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 18DE91A6F51 for ; Mon, 6 Oct 2014 06:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 TJAUrvt6Os1q for ; Mon, 6 Oct 2014 06:35:36 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::755]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE581A6F24 for ; Mon, 6 Oct 2014 06:35:35 -0700 (PDT) Received: from pc6 (31.49.54.177) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 13:31:47 +0000 Message-ID: <011501cfe169$9bc924a0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> <20140321074646.GA12080@elstar.local> <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> <20141006061636.GB51842@elstar.local> Date: Mon, 6 Oct 2014 14:29:42 +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: [31.49.54.177] X-ClientProxiedBy: DB4PR03CA0005.eurprd03.prod.outlook.com (25.160.39.143) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Forefront-PRVS: 03569407CC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51444003)(24454002)(199003)(377454003)(189002)(40100001)(47776003)(44716002)(15202345003)(62236002)(92566001)(122386002)(23756003)(66066001)(50466002)(50226001)(15975445006)(19580395003)(4396001)(19580405001)(92726001)(64706001)(44736004)(116806002)(85306004)(102836001)(93886004)(20776003)(101416001)(230783001)(76176999)(86362001)(93916002)(50986999)(81686999)(97736003)(87286001)(81816999)(14496001)(77096002)(95666004)(107046002)(105586002)(106356001)(77156001)(89996001)(85852003)(31966008)(110136001)(80022003)(33646002)(61296003)(46102003)(87976001)(62966002)(42186005)(120916001)(10300001)(76482002)(104166001)(21056001)(99396003); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/akz4ZMsbp3xSDguYW1V6STvIUXo Cc: netconf@ietf.org Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 06 Oct 2014 13:35:39 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: Sent: Monday, October 06, 2014 7:16 AM > On Fri, Oct 03, 2014 at 11:45:32AM +0100, t. petch wrote: > > I think that this still needs a tweak. > > > > In s.2.4.1, the sentence > > "If > > the NETCONF client has external information as to the expected > > identity of the NETCONF server, the hostname check MAY be omitted. > > " > > has been moved, to be immediately after the comment about performing > > certificate validation as per RFC5280. Which does not make good sense > > since RFC5280 is not about hostname checks. The sentence used to come > > after the references to RFC6125 which is about hostnames and so made > > more sense. > > To tell the truth, I find the section still confusing. There are too > many MUST and MAYs interacting here. I also see that the second > paragraph says MUST ask for user confirmation or terminate the > connection. This also seems to conflict with the notion of > 'whitelisted' certificates (which I think the 'client has external > information as to the expected identity' boils down to). If you can > come up with a rewrite of section 2.4.1 that makes all of this simpler > and straight forward, this would actually be very much appreciated. Juergen, I too am confused. I can start with " If the certificate presented by a NETCONF server has passed certification path validation [RFC5280] to a configured trust anchor, the NETCONF client MUST examine the certificate presented by the server to verify that it meets the client's expectations. The NETCONF client SHOULD check its understanding of the NETCONF server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. This check is performed according to the rules and guidelines defined in [RFC6125]. If the check fails, the NETCONF client MUST either ask for the user for confirmation that the certificate is acceptable or terminate the connection with an indication that the NETCONF server's identity is suspect. The NETCONF client MAY have external information as to the expected identity of the NETCONF server, such as ....." at which point, my understanding runs out Tom Petch > > But more fundamentally, I am unclear what this is saying. 'hostname > > check' does not appear anywhere else. There is talk of matching but I > > am unclear if that is intended. As it stands, the sentence would seem > > to say, get a certificate and then ignore its contents, in which case, I > > think that an example, or list, of suitable conditions needs to be there > > alongside the sentence, whereever the sentence is. > > No, it is not 'ignore its contents'. My understanding is you validate the > certificate but the contained in the ticket is not checked against the > expected hostname - instead you verify that the certificated is a known > one. > > > Separately, given the focus there has been on call home and the > > different flavours thereof, I would like a sentence at the end of 2.1 > > pointing to the call-home document > > I disagree with this. We have moved all the call-home stuff to a > different document and hence this transport specification should > really be silent about call home. > > /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 Oct 6 07:26: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 EF4C81A0300 for ; Mon, 6 Oct 2014 07:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1xt9IQs6zoxF for ; Mon, 6 Oct 2014 07:26:05 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::765]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D4F11A0303 for ; Mon, 6 Oct 2014 07:26:04 -0700 (PDT) Received: from pc6 (31.49.54.177) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Mon, 6 Oct 2014 14:25:40 +0000 Message-ID: <013001cfe171$22e1a140$4001a8c0@gateway.2wire.net> From: t.petch To: References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> <20140321074646.GA12080@elstar.local> <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> <20141006061636.GB51842@elstar.local> Date: Mon, 6 Oct 2014 15:23:34 +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: [31.49.54.177] X-ClientProxiedBy: DB4PR03CA0017.eurprd03.prod.outlook.com (25.160.39.155) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058; X-Forefront-PRVS: 03569407CC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(189002)(199003)(10300001)(120916001)(99396003)(105586002)(76482002)(42186005)(106356001)(77096002)(97736003)(95666004)(85306004)(107046002)(50226001)(40100001)(77156001)(23756003)(93886004)(44736004)(4396001)(46102003)(33646002)(104166001)(62236002)(50466002)(80022003)(116806002)(44716002)(92726001)(61296003)(20776003)(47776003)(66066001)(92566001)(87976001)(87286001)(101416001)(102836001)(89996001)(93916002)(14496001)(86362001)(64706001)(50986999)(85852003)(110136001)(84392001)(31966008)(81816999)(2351001)(107886001)(21056001)(88136002)(229853001)(122386002)(81686999)(76176999)(62966002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB058; 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/apiM-PDriMON0y26Q7W5sO_BHtw Subject: [Netconf] Call home reviewed 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, 06 Oct 2014 14:26:07 -0000 I think that draft-ietf-netconf-call-home needs quite a lot of tweaking. 'TCP connection' I would like to see used throughout, rather than a mix of connection/session/stream 'element' is used extensively within Netconf but, AFAIK, always to refer to a protocol element. The two ends of Netconf are commonly client and server, so I would like to see 'network element' eradicated from this I-D (unless it is not applicable to the management of all the other boxes that are currently managed:-) There is no Introduction. Commonly the Abstract serves as part or all of the Introduction, and I think that that is needed here, before Motivation s.3 references section 3 which I think is section 2 until you add an Introduction in which case it becomes section 3 once more. s.4 /connection/underlying connection/ - connection on its own is ambiguous s.6 would be easier to comment on with more subsections "Using this TCP connection, the NETCONF server immediately starts either the SSH-server or TLS-server protocol. That is, the next message sent on the TCP stream is the initial message defined for these protocols, per [RFC4253] or [RFC5246]." Odd wording. For SSH there is a defined initial SSH server message, as per RFC4253; for TLS, there is not - this paragraph could be read as requiring the TLS server to send HelloRequest which I think wrong - split the description of the two protocols. "The NETCONF protocol proceeds normally for SSH and TLS, as defined in [RFC4253] and [RFC5539] respectively." Odd wording. The next step is the setting up of the secure SSH or TLS channel which I think warrants a mention. Once that is complete, then RFC4253 is irrelevant - it is RFC6242 that matters " The NETCONF client's perspective (e.g., the management system)" e.g. or I.e. or omit altogether! " o The NETCONF client listens for TCP connections on one or both of the IANA-assigned ports for NETCONF Call Home port (YYYY and/or ZZZZ)." remove second port " o Using this TCP connection, the NETCONF client immediately starts either the SSH-server or TLS-server protocol. That is, the next message sent on the TCP stream is the initial message defined for these protocols, per xref target="RFC4253"/> or [RFC5246]. " I would rather the NETCONF client started the client protocols, else we are into a reverse call home:-) The xref is awry but RFC4253 is appropriate here for SSH " o The NETCONF protocol proceeds normally for SSH and TLS, as defined in [RFC4253] and [RFC5539] respectively." As before, we have moved beyond RFC4253 into RFC6242 Enough for the moment. I would like to see this lot incorporated into a fresh I-D (or rejected) before I carry on. Tom Petch From nobody Mon Oct 6 09:22: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 30BBF1A0350 for ; Mon, 6 Oct 2014 09:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.387 X-Spam-Level: X-Spam-Status: No, score=-5.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 oQgFnxUPNZQs for ; Mon, 6 Oct 2014 09:22:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1791A0329 for ; Mon, 6 Oct 2014 09:22:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s96GMQtu029437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Oct 2014 16:22:26 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s96GMQJO015124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Oct 2014 18:22:26 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 18:22:26 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: Details about the Bi-weekly NETCONF Virtual Interim today at 17:00-19:00 UTC Thread-Index: AQHP4YG3o2tieBT4XUmY5aBiJe6L6w== Date: Mon, 6 Oct 2014 16:22:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 633 X-purgate-ID: 151667::1412612546-00001FC1-00076AE5/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ujyrCw3TxZjxWzXqe2lpwEJAFNA Subject: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim today at 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, 06 Oct 2014 16:22:31 -0000 NETCONF participants, today, Monday October 6, 2014, 17:00-19:00 UTC (19-21 Amsterdam, Berlin tim= e) we will have our NETCONF virtual interim meeting. The virtual meeting is used mainly for issue solving of active WG item draf= ts. To JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=3Dm9f461ea30a23d08e29f45c40c0814= 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 Cheers, Mehmet From nobody Tue Oct 7 00:23: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 D2A141A9139 for ; Tue, 7 Oct 2014 00:23:29 -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 eHWv0rV7hJck for ; Tue, 7 Oct 2014 00:23: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 5C6961A9141 for ; Tue, 7 Oct 2014 00:23:23 -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 1XbP79-00028k-TR for netconf@ietf.org; Tue, 07 Oct 2014 09:23:21 +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 1XbP79-0001t0-Pc for netconf@ietf.org; Tue, 07 Oct 2014 09:23:19 +0200 Message-ID: <543394E7.7050902@bwijnen.net> Date: Tue, 07 Oct 2014 09:23:19 +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: 86ab03e524994f79ca2c75a176445dd4c09150d5057d90a6142612874b00a3cb Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DA06wmh44L2TQlqZor9mRB3PLYE 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, 07 Oct 2014 07:23:30 -0000 Dear NETCONF WG participants, Appologies for being a bit late with trying to draw a conclusion on this one. As WG chairs, we believe that option a) had reasonable support with good technical arguments why the choice was for that option. On pure numerical count, we believe that option c won, but it was/is also clear that it just complicates things and has more risk of interoperability problems. So we as chairs propose to go with option a). If anyone still has REAL STRONG objections, pls speak up before the end of this week. If we hear none by Friday Okt 10th, we conclude that we have (rough) consensus to go with option a) Bert and Mehmet. 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 Oct 7 09:27: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 D1CDF1A6FD3 for ; Tue, 7 Oct 2014 09:26:59 -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 Y97Vrv3ZfafY for ; Tue, 7 Oct 2014 09:26:57 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA7C1A9149 for ; Tue, 7 Oct 2014 09:26:57 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id z60so5770117qgd.29 for ; Tue, 07 Oct 2014 09:26:56 -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=qh3CybTRzsUkFHZDfcat2q+hdInbWxSfkhMFP0Uuihk=; b=GF/+iHfoAvsyGNGd3n8TNvMDAoHYAadC9BuOusEuRA7Ru39OCYwStzMlVCh+0iyQj/ w1pG8tzTN82NQ6+0C3f6J0P1n3wudtohKzp6mwoEnmhOCzcH6oVFa9r0L5bw21jFQMWP b1L3pC/UiOZ6rGSbgwtGkCCh9s4TJT97DhMPdCnYrC5fSXAOlNWNxIh7TxJUZHiFr6T1 iSxC8bnOufU3VjKXUeU0R+4t+FV1NcGew/gMfJz/JJklaeW9Fsi8NIbWPhcICz9af0sn 9hOybQ8MuQZJSPCtu8RLLatV40OSPoEXC/vr3AQRLVtOytR1B+eXvpJap+aoskYpJ3Hz l/Pg== X-Gm-Message-State: ALoCoQlhLGX1hj2Md+D8xqNTamJ4/ULeIu7rz7DH9y3X6o6VYMUKZO3TehDB2rWcyHHWRUe1Z6Sa MIME-Version: 1.0 X-Received: by 10.140.102.235 with SMTP id w98mr37723191qge.35.1412699216706; Tue, 07 Oct 2014 09:26:56 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Tue, 7 Oct 2014 09:26:56 -0700 (PDT) In-Reply-To: <543394E7.7050902@bwijnen.net> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> Date: Tue, 7 Oct 2014 09:26:56 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=001a11c1664cfcb6470504d7aaeb Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/QFk7T8VcYOuDWpeyE7rxzBxCJhc 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, 07 Oct 2014 16:27:00 -0000 --001a11c1664cfcb6470504d7aaeb Content-Type: text/plain; charset=ISO-8859-1 Hi, On Tue, Oct 7, 2014 at 12:23 AM, Bert Wijnen (IETF) wrote: > Dear NETCONF WG participants, > > Appologies for being a bit late with trying to draw a conclusion on this > one. > > As WG chairs, we believe that option a) had reasonable support with > good technical arguments why the choice was for that option. > > On pure numerical count, we believe that option c won, but it was/is also > clear that it just complicates things and has more risk of > interoperability problems. > I think you meant that (d) got the most. And it wasn't "whatever it chooses", it was "XML or JSON or both". > > So we as chairs propose to go with option a). > > If anyone still has REAL STRONG objections, pls speak up before > the end of this week. If we hear none by Friday Okt 10th, > we conclude that we have (rough) consensus to go with option a) > > Bert and Mehmet. > > Andy > 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 >> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c1664cfcb6470504d7aaeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,



=
On Tue, Oct 7, 2014 at 12:23 AM, Bert Wijnen (IE= TF) <bertietf@bwijnen.net> wrote:
Dea= r NETCONF WG participants,

Appologies for being a bit late with trying to draw a conclusion on this one.

As WG chairs, we believe that option a) had reasonable support with
good technical arguments why the choice was for that option.

On pure numerical count, we believe that option c won, but it was/is also clear that it just complicates things and has more risk of
interoperability problems.
=A0

I think you meant that (d) got the most. And it wasn't "whatever= it chooses",
it was "XML or JSON or both".
<= div>
=A0

So we as chairs propose to go with option a).

If anyone still has REAL STRONG objections, pls speak up before
the end of this week. If we hear none by Friday Okt 10th,
we conclude that we have (rough) consensus to go with option a)


Bert and Mehmet.


Andy

=A0
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,
=A0 =A0 server can implement whatever it chooses.
=A0 =A0 Not clear yet how the client would find out, but that would of cour= se
=A0 =A0 be 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


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

--001a11c1664cfcb6470504d7aaeb-- From nobody Tue Oct 7 18:18: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 D121D1A8AE0 for ; Tue, 7 Oct 2014 18:18:00 -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 dhKC89sTzqLo for ; Tue, 7 Oct 2014 18:17:58 -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 4996F1A8ADD for ; Tue, 7 Oct 2014 18:17:58 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id s7so5100244qap.18 for ; Tue, 07 Oct 2014 18:17:57 -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=g4lEEX2XgX5ejDAdpoQYjsqYmgR9Vxot4FFod6FYV/Q=; b=Ad8m7hhytrXzYYBbYKuFKp467cGZGEmuD1WccS/6cIGbM4Ki4qdRZZu1ZKa/znSh4Q yn0FFjef759dtm2OMaEQW4LXA6mzH/2DDbzhaMBfVPTAEhirZbhNSmlHZNOKJJhJ74JE /l6Vps8Km1cSeFuzJOI9isTDb8CnlnbeyjPyP3AAtWth5e+WpEINWyIkunA5kJafj/bM yiQGtU07xLefuQwXffG7I6rJkUJvBCtwX5CXrX1I96xDaie/3NYIis+j1kPS+iYd5IdW emZ6FTwYaXBcc82V/5PIYOmu7CmCNdEUJgBRgwhbEEn5QBtgzF2SFEPwNM4UvZ2MPKPr EglQ== X-Gm-Message-State: ALoCoQlcYQp5fl9aG5PlM+a0boOATrtFfVk4fWtwQkQtITbC2C29dBv0UN+lBCsl54Wcckid10Vo MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr8867266qab.7.1412731077366; Tue, 07 Oct 2014 18:17:57 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Tue, 7 Oct 2014 18:17:57 -0700 (PDT) Date: Tue, 7 Oct 2014 18:17:57 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c1c56007bd2e0504df16d4 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/lbov_kXuHBGjHFe91yXsAAbB_LE Subject: [Netconf] RESTCONF Issue #3: collection resource 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, 08 Oct 2014 01:18:01 -0000 --001a11c1c56007bd2e0504df16d4 Content-Type: text/plain; charset=ISO-8859-1 Hi, If XML is mandatory then a limitation of XML for retrieval needs to be addressed. https://github.com/netconf-wg/restconf/issues/3 If a leaf-list or list is specified as the target resource in a GET operation, then the server needs to add a top-level wrapper to the response if multiple instances are possible. It is quite useful to retrieve an entire leaf-list or list in one simple request. The only thing preventing RESTCONF from supporting this feature is the lack of a top-level container for XML GET responses. (e.g. ). The resource type for this top-level container can be defined as a new media type called "application/yang.collection". IMO we should define the basic container for a collection now and define advanced operations on collection resources in a future RFC. The choices are: A) allow GET of multiple leaf-list or list instances at once in XML by defining a top-level container for the response, as a new collection resource B) do not allow GET of multiple leaf-list or list instances at once in XML The server will return some error instead. Andy --001a11c1c56007bd2e0504df16d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

If XML is mandatory then a limitati= on of XML for retrieval
needs to be addressed.


If= a leaf-list or list is specified as the target resource in a GET operation= ,
then the server needs to add a top-level wrapper to the respons= e
if multiple instances are possible.

It= is quite useful to retrieve an entire leaf-list or list in one simple requ= est.
The only thing preventing RESTCONF from supporting this feat= ure
is the lack of a top-level container for XML GET responses. (= e.g. <collection>).

The resource type for th= is top-level container can be defined
as a new media type called = "application/yang.collection".
IMO we should define the= basic container for a collection now and
define advanced operati= ons on collection resources in a future RFC.

The c= hoices are:


=A0A) allow GET of= multiple leaf-list or list instances at once in XML
=A0 =A0 =A0 = =A0by defining a top-level container for the response, as a
=A0 = =A0 =A0 =A0new collection resource

=A0 B) do= not allow GET of multiple leaf-list or list instances at once in XML
=
=A0 =A0 =A0 The server will return some error instead.

<= /div>


Andy


<= /div>
--001a11c1c56007bd2e0504df16d4-- From nobody Wed Oct 8 10:49: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 F2FA81ACD67 for ; Wed, 8 Oct 2014 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgmVE55Pzps4 for ; Wed, 8 Oct 2014 10:48:59 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CC81ACD62 for ; Wed, 8 Oct 2014 10:48:58 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s98HmrkV007538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Oct 2014 17:48:53 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s98Hmqk3029067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 19:48:53 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Oct 2014 19:48:52 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 19:48:52 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: Draft minutes/notes from the Virtual meting on Monday October 6, 2014 Thread-Index: Ac/jIB6WDu63AvOrTe2fO3OMZ2E2cQ== Date: Wed, 8 Oct 2014 17:48:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81950C3EDDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 21658 X-purgate-ID: 151667::1412790534-00001FC1-2D3F3F7B/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hgyR9TkQWwsfXlgAQ_8xCLtdY_U Subject: [Netconf] Draft minutes/notes from the Virtual meting on Monday October 6, 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: Wed, 08 Oct 2014 17:49:03 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81950C3EDDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, below are the draft minutes as taken by the meeting robot, which we used al= ready in the last meeting. Many thanks to Kent for preparing the output. As for all physical and virtual WG meetings the issue discussion needs to b= e verified on the maillist. If there is no objection to the conclusions from the issue discussion below= , the draft authors are going to extend or modify as discussed. Please send your comments to the maillist. Additional information on the issue discussion is available on netconf-wg g= ithub: https://github.com/netconf-wg/restconf/issues and https://github.com/netconf-wg/server-model/issues Regards, Mehmet ----------- Virtual meeting attendees: * Kent Watsen * Juergen Schoenwaelder * Andy Bierman * Mahesh Jethhanandani * Mehmet Ersue (WG co-chair) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D #netconf-wg Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Meeting started by kwatsen at 17:19:54 UTC. The full logs are available at netconf-wg/2014/netconf-wg.2014-10-06-17.19.log.html . Meeting summary ------------------- * Agenda Bashing (kwatsen, 17:20:04) * meta meeting discussion (kwatsen, 17:21:03) * need key participants (kwatsen, 17:21:21) * focus is to go over issues as tracked by GitHub (kwatsen, 17:21:36) * Who are key contributors for the meeting to happen? How are these "key contributors" defined? (mj, 17:22:17) * I wish we had more time to discuss, how about 80% of any mailing list participants in drafts being discussed? (kwatsen, 17:23:40) * RESTCONF Issue #2 (kwatsen, 17:24:45) * LINK: https://github.com/netconf-wg/restconf/issues/2 (kwatsen, 17:25:28) * kent says that auth mechanism may drive this (kwatsen, 17:27:15) * juergen says for TLS, would want long-lived sessions too (kwatsen, 17:27:38) * sounds like there is agreement to try to make it show up as a session - we need to find how to satisfy the requirement (kwatsen, 17:30:36) * looks like an agreement (Mehmet, 17:31:06) * Juergen: schema announcement should be protocol independent (Mehmet, 17:47:42) * juergen says reason we're discussing 6022 is so RESTCONF clients can discover module's supported (kwatsen, 17:48:30) * there is a duplication concerning capabilities (Mehmet, 17:53:22) * Monitoring can be kept protocol specific (Mehmet, 17:54:03) * My requirement is that the same schema information is available to both NETCONF and RESTCONF clients (JS__, 18:13:07) * factor out module list into separate module (abierman, 18:13:19) * netconf capability and restconf capability list are different (abierman, 18:13:42) * module list is mandatory to implement in restconf (abierman, 18:14:32) * A generic session data model may be a separate piece of work. (JS__, 18:14:45) * this to address a catch-22 situation (kwatsen, 18:14:50) * do not open RFC 6022 (abierman, 18:14:51) * how to show restconf sessions in /netconf-state/sessions (abierman, 18:15:40) * add identity restconf-tls (similar to netconf-tls) for transport (abierman, 18:15:58) * could not define any 6022 extensions now and define restconf-specific extensions later (abierman, 18:16:57) * what about streams monitoring? (abierman, 18:17:30) * defer all session monitoring to a future draft (abierman, 18:19:16) * RESTCONF Issue #7 (kwatsen, 18:21:14) * there was a call on this list (kwatsen, 18:22:08) * two weeks ago it was ~ 11-9 (almost a split) (kwatsen, 18:22:32) * 11 for option 'D', 9 for option 'A' (kwatsen, 18:24:28) * Mehmet says we should discuss at next IETF meeting (kwatsen, 18:24:50) * Andy concerned it will delay the draft more (kwatsen, 18:25:09) * Juergen says chairs should like to define a rough consensus statement (kwatsen, 18:25:54) * ACTION: Mehmet to discuss with Bert (kwatsen, 18:26:04) * RESTCONF Issue #9 (kwatsen, 18:26:37) * Juergen notes that netconf-tls uses certificates (kwatsen, 18:28:45) * Kent says we should try that option first, to see how well it works for REST (kwatsen, 18:29:19) * Juergen suggests we find other REST protocols and copy them (kwatsen, 18:29:56) * Andy asks if RESTCONF has requirement to extract username (Juergen confirms - for NACM) (kwatsen, 18:30:33) * RFC 7285 says use HTTP digest for auth (abierman, 18:31:50) * LINK: https://tools.ietf.org/html/rfc7285 (kwatsen, 18:31:59) * Wrapping up RESTCONF (kwatsen, 18:38:23) * charter dates have been exceeded (kwatsen, 18:38:53) * fixed deadlines aren't helpful (kwatsen, 18:39:05) * need to prevent feature-creep (kwatsen, 18:39:13) * server-model #7 (Mehmet, 18:43:34) * issue #7 Do we need enable/disable knobs (Mehmet, 18:44:24) * no strong objections. So the issue is closed. (Mehmet, 18:45:42) * Bert has started consensus call. (Mehmet, 18:45:58) * server-model #10 (Mehmet, 18:46:00) * Add support for Restconf? (Mehmet, 18:46:20) * better to have separate modules so do not need to make everything purely optional (abierman, 18:53:34) * andy/kent say another model should be created specific for restconf (kwatsen, 18:54:23) * server model issue #12 (kwatsen, 18:56:11) * Do you guys hear me? (Mehmet, 18:57:16) * Andy and Juergen think that lot's of groupings make harder to read (kwatsen, 19:05:48) * Andy mentions that ODL also uses lots of groupings (kwatsen, 19:06:21) * kent to collect more opinions (kwatsen, 19:07:10) Meeting ended at 19:07:15 UTC. Action items, by person ----------------------- * Mehmet * Mehmet to discuss with Bert on the result of the consensus call for "RE= STCONF modularity" and propose a way forward. People present (lines said) --------------------------- * kwatsen (41) * abierman (11) * Mehmet (11) * meetbot (4) * JS__ (2) * mj (1) --_000_E4DE949E6CE3E34993A2FF8AE79131F81950C3EDDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
below are the draft minutes as taken by the me= eting robot, which we used already in the last meeting.
Many thanks to Kent for preparing the output.<= /font>
 
As for all physical and virtual WG meetings th= e issue discussion needs to be verified on the maillist.
 
If there is no objection to the conclusions fr= om the issue discussion below, the draft authors are going to extend or mod= ify as discussed.
Please send your comments to the maillist.
 
Additional information on the issue discussion= is available on netconf-wg github:
https://github.com/netconf-wg/restconf/issues and
 
Regards,
Mehmet
 
-----------
 
Virtual meeting attendees:
 
* Kent Watsen
* Juergen Schoenwaelder
* Andy Bierman
* Mahesh Jethhanandani
* Mehmet Ersue (WG co-chair)
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
#netconf-wg Meeting
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
Meeting started by kwatsen at 17:19:54 UTC.&nb= sp; The full logs are available
at netconf-wg/2014/netconf-wg.2014-10-06-17.19= .log.html .
 
Meeting summary
-------------------
 
* Agenda Bashing  (kwatsen, 17:20:04)
  * meta meeting discussion  (kwatse= n, 17:21:03)
  * need key participants  (kwatsen,= 17:21:21)
  * focus is to go over issues as tracked= by GitHub  (kwatsen, 17:21:36)
  * Who are key contributors for the meet= ing to happen? How are these
    "key contributors"= ; defined?  (mj, 17:22:17)
  * I wish we had more time to discuss, h= ow about 80% of any mailing
    list participants in drafts= being discussed?  (kwatsen, 17:23:40)
 
* RESTCONF Issue #2  (kwatsen, 17:24:45)<= /font>
  * LINK: https://github.com/netconf-wg/restconf/issues/2  (kwatsen,<= /div>
    17:25:28)
  * kent says that auth mechanism may dri= ve this  (kwatsen, 17:27:15)
  * juergen says for TLS, would want long= -lived sessions too  (kwatsen,
    17:27:38)
  * sounds like there is agreement to try= to make it show up as a
    session - we need to find h= ow to satisfy the requirement  (kwatsen,
    17:30:36)
  * looks like an agreement  (Mehmet= , 17:31:06)
  * Juergen: schema announcement should b= e protocol independent
    (Mehmet, 17:47:42)
  * juergen says reason we're discussing = 6022 is so RESTCONF clients can
    discover module's supported=   (kwatsen, 17:48:30)
  * there is a duplication concerning cap= abilities  (Mehmet, 17:53:22)
  * Monitoring can be kept protocol speci= fic  (Mehmet, 17:54:03)
  * My requirement is that the same schem= a information is available to
    both NETCONF and RESTCONF c= lients  (JS__, 18:13:07)
  * factor out module list into separate = module  (abierman, 18:13:19)
  * netconf capability and restconf capab= ility list are different
    (abierman, 18:13:42)=
  * module list is mandatory to implement= in restconf  (abierman,
    18:14:32)
  * A generic session data model may be a= separate piece of work.
    (JS__, 18:14:45)
  * this to address a catch-22 situation&= nbsp; (kwatsen, 18:14:50)
  * do not open RFC 6022  (abierman,= 18:14:51)
  * how to show restconf sessions in /net= conf-state/sessions  (abierman,
    18:15:40)
  * add identity restconf-tls (similar to= netconf-tls) for transport
    (abierman, 18:15:58)=
  * could not define any 6022 extensions = now and define
    restconf-specific extension= s later  (abierman, 18:16:57)
  * what about streams monitoring?  = (abierman, 18:17:30)
  * defer all session monitoring to a fut= ure draft  (abierman, 18:19:16)
 
* RESTCONF Issue #7  (kwatsen, 18:21:14)<= /font>
  * there was a call on this list  (= kwatsen, 18:22:08)
  * two weeks ago it was ~ 11-9  (al= most a split)  (kwatsen, 18:22:32)
  * 11 for option 'D', 9 for option 'A'&n= bsp; (kwatsen, 18:24:28)
  * Mehmet says we should discuss at next= IETF meeting  (kwatsen,
    18:24:50)
  * Andy concerned it will delay the draf= t more  (kwatsen, 18:25:09)
  * Juergen says chairs should like to de= fine a rough consensus
    statement  (kwatsen, 1= 8:25:54)
  * ACTION: Mehmet to discuss with Bert&n= bsp; (kwatsen, 18:26:04)
 
* RESTCONF Issue #9  (kwatsen, 18:26:37)<= /font>
  * Juergen notes that netconf-tls uses c= ertificates  (kwatsen,
    18:28:45)
  * Kent says we should try that option f= irst, to see how well it works
    for REST  (kwatsen, 18= :29:19)
  * Juergen suggests we find other REST p= rotocols and copy them
    (kwatsen, 18:29:56)<= /div>
  * Andy asks if RESTCONF has requirement= to extract username (Juergen
    confirms - for NACM)  = (kwatsen, 18:30:33)
  * RFC 7285 says use HTTP digest for aut= h  (abierman, 18:31:50)
  * LINK: https://tools.ietf.org/html/rfc7285  (kwatsen, 18:31:59)
 
* Wrapping up RESTCONF  (kwatsen, 18:38:2= 3)
  * charter dates have been exceeded = ; (kwatsen, 18:38:53)
  * fixed deadlines aren't helpful  = (kwatsen, 18:39:05)
  * need to prevent feature-creep  (= kwatsen, 18:39:13)
 
* server-model #7  (Mehmet, 18:43:34)
  * issue #7 Do we need enable/disable kn= obs  (Mehmet, 18:44:24)
  * no strong objections. So the issue is= closed.  (Mehmet, 18:45:42)
  * Bert has started consensus call. = ; (Mehmet, 18:45:58)
 
* server-model #10 (Mehmet, 18:46:00)
  * Add support for Restconf?  (Mehm= et, 18:46:20)
  * better to have separate modules so do= not need to make everything
    purely optional  (abie= rman, 18:53:34)
  * andy/kent say another model should be= created specific for restconf
    (kwatsen, 18:54:23)<= /div>
 
* server model issue #12  (kwatsen, 18:56= :11)
  * Do you guys hear me?  (Mehmet, 1= 8:57:16)
  * Andy and Juergen think that lot's of = groupings make harder to read
    (kwatsen, 19:05:48)<= /div>
  * Andy mentions that ODL also uses lots= of groupings  (kwatsen,
    19:06:21)
  * kent to collect more opinions  (= kwatsen, 19:07:10)
 
 
 
Meeting ended at 19:07:15 UTC.
 
 
 
Action items, by person
-----------------------
 
* Mehmet
  * Mehmet to discuss with Bert on the re= sult of the consensus call for "RESTCONF modularity" and propose = a way forward.
 
 
 
People present (lines said)
---------------------------
 
* kwatsen (41)
* abierman (11)
* Mehmet (11)
* meetbot (4)
* JS__ (2)
* mj (1)
 
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F81950C3EDDEMUMBX005nsnin_-- From nobody Wed Oct 8 15:10: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 D3EB11A1AB6; Wed, 8 Oct 2014 15:10: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 g1PNp-o69Ozo; Wed, 8 Oct 2014 15:10:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 996931A1AD7; Wed, 8 Oct 2014 15:09:23 -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.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141008220923.28291.36219.idtracker@ietfa.amsl.com> Date: Wed, 08 Oct 2014 15:09:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2SU6-KLilDgqiuHaNawsQQj_7KY Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-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, 08 Oct 2014 22:10:21 -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 : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-02.txt Pages : 95 Date : 2014-10-08 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-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 Wed Oct 8 15:31: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 5B6A01A1B60 for ; Wed, 8 Oct 2014 15:31: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 gJx8duDFH2EP for ; Wed, 8 Oct 2014 15:31:24 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701201A1AD7 for ; Wed, 8 Oct 2014 15:31:24 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id a108so50551qge.12 for ; Wed, 08 Oct 2014 15:31:23 -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=n0W4pon3PKAHaE2BmP5ZASoi6jJxmXERGlK8J18lFRI=; b=RE0cg9vCmTHpGUOXlcu0sdKhYzk2M5qMMsCEjcegMQsiUYS+ovb8AypE+i1oPxquHJ /a+SgWMFHDxnKsMzJMvbiFVNLPHmPigKzFR/LiFhUxTlcBwEIBqn6tIiT3pvmu7aXwnK dQSpn0mnJpNzNIAQFgvD2V/+bZpo2fvq3L/d/yV9N58wqWFcOEEUiZ0EaYfWnsmwkO/G geb/t0HFKlpA18gV0c1j09N4KBXz1v8rzFRW/Gble9jJUGJAUGVwM+ToiCExnnzzxc5g JN6jTYPcabD5whKasSRHxvtGJnThtNuqduxcdOhJJTBjvtIDgsn2KuxHCDonEVo37Vta xXEQ== X-Gm-Message-State: ALoCoQkxzFKyUgw7u+HwiEocGbIZy4iHNj7MXSBB9XW7+cLfYOCT6xfPPS/IP1M3GrRGl0DWI+Py MIME-Version: 1.0 X-Received: by 10.224.88.137 with SMTP id a9mr17980697qam.88.1412807483507; Wed, 08 Oct 2014 15:31:23 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 8 Oct 2014 15:31:23 -0700 (PDT) In-Reply-To: <20141008220923.28291.36219.idtracker@ietfa.amsl.com> References: <20141008220923.28291.36219.idtracker@ietfa.amsl.com> Date: Wed, 8 Oct 2014 15:31:23 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c2bbc030d98d0504f0e08d Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/tJCLlFTnpWMTxbzd9iBP8A9lu5g Subject: [Netconf] Fwd: I-D Action: draft-ietf-netconf-restconf-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, 08 Oct 2014 22:31:26 -0000 --001a11c2bbc030d98d0504f0e08d Content-Type: text/plain; charset=ISO-8859-1 FYI, This version addresses several open issues. The issue tracker has been updated accordingly: https://github.com/netconf-wg/restconf/issues Please review this draft ASAP and review the issues list as well. The XML content type decision is not in this draft. That will be added in the next revision. We would like to start WGLC as soon as possible. There are still some open issues to resolve before that can happen. thanks, Andy ---------- Forwarded message ---------- From: Date: Wed, Oct 8, 2014 at 3:09 PM Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-02.txt To: i-d-announce@ietf.org Cc: netconf@ietf.org 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 : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-02.txt Pages : 95 Date : 2014-10-08 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-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 --001a11c2bbc030d98d0504f0e08d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

This version addresses several ope= n issues.
The issue tracker has been updated accordingly:


Please review this draft ASAP and review the issues list as well.
The XML content type decision is not in this draft. That will
b= e added in the next revision.

We would like to sta= rt WGLC as soon as possible.
There are still some open issues to = resolve before that can happen.

thanks,
= Andy



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Oct 8, 20= 14 at 3:09 PM
Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf= -02.txt
To: i-d-announce@ietf.o= rg
Cc: netconf@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Network Configuration Working Group of = the IETF.

=A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0 =A0: RESTCONF Protocol
=A0 =A0 =A0 =A0 Authors=A0 =A0 =A0 =A0 =A0: Andy Bierman
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Bjorklund
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kent Watsen
=A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-netconf-restconf-02.tx= t
=A0 =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 =A0: 95
=A0 =A0 =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-10-08

Abstract:
=A0 =A0This document describes an HTTP-based protocol that provides a
=A0 =A0programmatic interface for accessing data defined in YANG, using the=
=A0 =A0datastores defined in NETCONF.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-restco= nf/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netconf-restconf-02<= br>
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-= restconf-02


Please note that it may take a couple of minutes from the time of submissio= n
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

--001a11c2bbc030d98d0504f0e08d-- From nobody Thu Oct 9 10:43: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 EB4261AD466 for ; Thu, 9 Oct 2014 10:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvVCsEY3bcXB for ; Thu, 9 Oct 2014 10:43:42 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216401AD467 for ; Thu, 9 Oct 2014 10:43:41 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s99HhcIw016747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Oct 2014 17:43:39 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s99Hhbd1013861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 19:43:38 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 19:43:37 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman , Netconf Thread-Topic: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity Thread-Index: AQHP4kuCWskhNgGUiUOwBv6Ya3YWfZwoCczQ Date: Thu, 9 Oct 2014 17:43:36 +0000 Message-ID: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.103] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 13388 X-purgate-ID: 151667::1412876619-0000437E-CA79C0C3/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/YSEbLd-nnI0dlkeiIeGW-z6JqDg 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, 09 Oct 2014 17:43:46 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, All, in reality it was 8 for a) and 8 for d) until Mahesh changed his mind in fa= vor of d). However with the conclusion mail below you may count both co-chair's votes = in favor of a). We indeed think that a) had reasonable support with good technical argument= s, which are mainly "less options, less complexity, better understood". You may count the co-chairs now to "old-school" but we believe that a) impr= oves interoperability. Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierm= an Sent: Tuesday, October 07, 2014 6:27 PM To: Bert Wijnen (IETF) Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your op= inion on RESTCONF modularity Hi, On Tue, Oct 7, 2014 at 12:23 AM, Bert Wijnen (IETF) > wrote: Dear NETCONF WG participants, Appologies for being a bit late with trying to draw a conclusion on this one. As WG chairs, we believe that option a) had reasonable support with good technical arguments why the choice was for that option. On pure numerical count, we believe that option c won, but it was/is also clear that it just complicates things and has more risk of interoperability problems. I think you meant that (d) got the most. And it wasn't "whatever it chooses= ", it was "XML or JSON or both". So we as chairs propose to go with option a). If anyone still has REAL STRONG objections, pls speak up before the end of this week. If we hear none by Friday Okt 10th, we conclude that we have (rough) consensus to go with option a) Bert and Mehmet. Andy 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy, All,

 

in reality it was 8 for a)= and 8 for d) until Mahesh changed his mind in favor of d).

However with the conclusio= n mail below you may count both co-chair’s votes in favor of a).=

 

We indeed think that a) ha= d reasonable support with good technical arguments, which are mainly “= ;less options, less complexity, better understood”.=

You may count the co-chair= s now to “old-school” but we believe that a) improves interoper= ability.

 

Mehmet=

 

From: Netconf [m= ailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman
Sent: Tuesday, October 07, 2014 6:27 PM
To: Bert Wijnen (IETF)
Cc: Netconf
Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express = your opinion on RESTCONF modularity

 

Hi,

 

 

 

On Tue, Oct 7, 2014= at 12:23 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:

Dear NETCONF WG par= ticipants,

Appologies for being a bit late with trying to draw a conclusion on this one.

As WG chairs, we believe that option a) had reasonable support with
good technical arguments why the choice was for that option.

On pure numerical count, we believe that option c won, but it was/is also clear that it just complicates things and has more risk of
interoperability problems.

 

 

I think you meant t= hat (d) got the most. And it wasn't "whatever it chooses",

it was "XML or= JSON or both".

 

 


So we as chairs propose to go with option a).

If anyone still has REAL STRONG objections, pls speak up before
the end of this week. If we hear none by Friday Okt 10th,
we conclude that we have (rough) consensus to go with option a)<= /span>

 

Bert and Mehmet.

 

Andy

 

 

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 o= f course
    be 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


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

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F81950D70CDEMUMBX005nsnin_-- From nobody Fri Oct 10 03: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 9A0101A8A43 for ; Fri, 10 Oct 2014 03:59:25 -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 oSE95mjtb0aT for ; Fri, 10 Oct 2014 03:59:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E9A111A8A42 for ; Fri, 10 Oct 2014 03:59:23 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 8EFFD12801AA for ; Fri, 10 Oct 2014 12:59:22 +0200 (CEST) Date: Fri, 10 Oct 2014 12:59:22 +0200 (CEST) Message-Id: <20141010.125922.123878611.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <011501cfe169$9bc924a0$4001a8c0@gateway.2wire.net> References: <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> <20141006061636.GB51842@elstar.local> <011501cfe169$9bc924a0$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iTcHNx-lfUYGf_Ar5_n3saygXr0 Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 10 Oct 2014 10:59:25 -0000 Hi, I also find the first two pararaphs of 2.4.1 confusing. Some additional comments: 2.4 says: Implementations MAY optionally support TLS certificate-based authentication [RFC5246]. If the implementation supports TLS certificate-based authentication, then the following sections apply. Ok, so if my implementation does not support certificate-based authentication, how is the NETCONF username derived? ------------- The text in 2.4.2 doesn't make much sense on its own. Maybe merge the text in 2.4.3 into 2.4.2? ------------- 2.4.3 says: The NETCONF server uses the algorithm defined in [I-D.ietf-netconf-server-model] to extract a NETCONF username from the X.509 certificate presented by the NETCONF client. is this a MUST, or is this one way to do this? /martin From nobody Fri Oct 10 07:37: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 C7F261A1A18 for ; Fri, 10 Oct 2014 07:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 j_MzrRMEKJC6 for ; Fri, 10 Oct 2014 07:37:03 -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 93EA91A1A07 for ; Fri, 10 Oct 2014 07:37:03 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id D673313FA54; Fri, 10 Oct 2014 16:37:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1412951822; bh=+u6jMOCa9xSthm1wFX/bTMZndarCxzKGGBJIACSD2oI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=M1lac/GE/7bar15VHJ72YGZNe5bHkYZEsUrJ5GNw4T6C18PooREakIKiigpx5ijXU 7piz0s70HS8aUHCa7yg5dBo+y0Y6yXnrpQDsJxcHw9DRYI3HxdtEohyM2YuJQoHo/P eOMNcZGQ7f5qGK/TLihimog3IgVk7eMrg2ydwV1A= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 10 Oct 2014 16:37:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> To: Mehmet Ersue 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/e6-9U-pqGwbMA7UBgkBEJYNVe9s 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: Fri, 10 Oct 2014 14:37:06 -0000 Hi Mehmet, On 09 Oct 2014, at 19:43, Ersue, Mehmet (NSN - DE/Munich) = wrote: > Hi Andy, All, > =20 > in reality it was 8 for a) and 8 for d) until Mahesh changed his mind = in favor of d). > However with the conclusion mail below you may count both co-chair=92s = votes in favor of a). Either way, it is IMO nowhere near to rough consensus. > =20 > We indeed think that a) had reasonable support with good technical = arguments, which are mainly =93less options, less complexity, better = understood=94. If JSON becomes the preferred choice - and I think we cannot exclude = this alternative - than a) will actually mean more complexity for server = implementors. Some 20+ years ago I heard many good technical arguments why ISO OSI was = better than TCP/IP. > You may count the co-chairs now to =93old-school=94 but we believe = that a) improves interoperability. The interoperability argument neglects the fact that RESTCONF clients = won=92t pick their servers out of the blue (or vice versa for call = home). NMSes are usually selected for a concrete network, and the = capabilities of network devices (including support for RESTCONF = encodings) can be taken into account. Lada > =20 > Mehmet > =20 > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy = Bierman > Sent: Tuesday, October 07, 2014 6:27 PM > To: Bert Wijnen (IETF) > Cc: Netconf > Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express = your opinion on RESTCONF modularity > =20 > Hi, > =20 > =20 > =20 > On Tue, Oct 7, 2014 at 12:23 AM, Bert Wijnen (IETF) = wrote: > Dear NETCONF WG participants, >=20 > Appologies for being a bit late with trying to draw a conclusion on = this > one. >=20 > As WG chairs, we believe that option a) had reasonable support with > good technical arguments why the choice was for that option. >=20 > On pure numerical count, we believe that option c won, but it was/is = also > clear that it just complicates things and has more risk of > interoperability problems. > =20 > =20 > I think you meant that (d) got the most. And it wasn't "whatever it = chooses", > it was "XML or JSON or both". > =20 > =20 >=20 > So we as chairs propose to go with option a). >=20 > If anyone still has REAL STRONG objections, pls speak up before > the end of this week. If we hear none by Friday Okt 10th, > we conclude that we have (rough) consensus to go with option a) >=20 > =20 > Bert and Mehmet. >=20 > =20 > Andy > =20 > =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 > =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 Fri Oct 10 10:03:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9471A6FEE for ; Fri, 10 Oct 2014 10:03:19 -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 LWjG_H48KFdp for ; Fri, 10 Oct 2014 10:03:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::752]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFB01A6FCC for ; Fri, 10 Oct 2014 10:03:17 -0700 (PDT) Received: from pc6 (86.167.152.56) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 10 Oct 2014 16:59:29 +0000 Message-ID: <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> From: t.petch To: , Martin Bjorklund References: <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> <20141006061636.GB51842@elstar.local> <011501cfe169$9bc924a0$4001a8c0@gateway.2wire.net> <20141010.125922.123878611.mbj@tail-f.com> Date: Fri, 10 Oct 2014 17:56:20 +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.167.152.56] X-ClientProxiedBy: AM3PR03CA015.eurprd03.prod.outlook.com (10.141.191.143) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Forefront-PRVS: 03607C04F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(51704005)(13464003)(88136002)(87286001)(104166001)(77096002)(87976001)(93886004)(85306004)(76176999)(81686999)(122386002)(116806002)(95666004)(89996001)(81816999)(105586002)(86362001)(93916002)(92726001)(92566001)(40100002)(107046002)(21056001)(106356001)(46102003)(50466002)(230783001)(80022003)(33646002)(23756003)(107886001)(85852003)(66066001)(50226001)(14496001)(4396001)(97736003)(84392001)(120916001)(77156001)(76482002)(42186005)(101416001)(19580405001)(62966002)(102836001)(99396003)(19580395003)(50986999)(64706001)(15975445006)(44736004)(61296003)(20776003)(47776003)(44716002)(62236002)(31966008)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; 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/58gKhFkzyXBkOrbJ1T1d9hdX_5Y Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 10 Oct 2014 17:03:19 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Sent: Friday, October 10, 2014 11:59 AM > > I also find the first two pararaphs of 2.4.1 confusing. > > Some additional comments: > > 2.4 says: > > Implementations MAY optionally support TLS certificate-based > authentication [RFC5246]. If the implementation supports TLS > certificate-based authentication, then the following sections > apply. > > Ok, so if my implementation does not support certificate-based > authentication, how is the NETCONF username derived? Martin We did have " Implementations MAY optionally support TLS Pre-Shared Key (PSK) authentication [RFC4279]. RFC4279 describes pre-shared key ciphersuites for TLS. The description of the psk-maps container in the ietf-netconf-server YANG module, defined in [I-D.kwatsen-netconf-server], specifies how a NETCONF server associates a TLS pre-shared key with a NETCONF username." as the only alternative to certificate based authentication so that was covered. I am unclear whether or not PSK is still a use case for NETCONF. Tom Petch > ------------- > > The text in 2.4.2 doesn't make much sense on its own. Maybe merge the > text in 2.4.3 into 2.4.2? > > ------------- > > 2.4.3 says: > > The NETCONF server uses the algorithm defined in > [I-D.ietf-netconf-server-model] to extract a NETCONF username from > the X.509 certificate presented by the NETCONF client. > > is this a MUST, or is this one way to do this? > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Oct 10 11:36: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 142B41A0233 for ; Fri, 10 Oct 2014 11:36:17 -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 vhziZKLOqgv6 for ; Fri, 10 Oct 2014 11:36:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:743]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E32A1ACDE9 for ; Fri, 10 Oct 2014 11:36:14 -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.1049.19; Fri, 10 Oct 2014 18:35:51 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 18:35:50 +0000 From: Kent Watsen To: t.petch , "netconf@ietf.org" , Martin Bjorklund Thread-Topic: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 Thread-Index: AQHP4S04QE86eeFbMkG3+q863EPCyZwjEoMbgAYdoQCAAGW6ev//1r4A Date: Fri, 10 Oct 2014 18:35:50 +0000 Message-ID: References: <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> <20141006061636.GB51842@elstar.local> <011501cfe169$9bc924a0$4001a8c0@gateway.2wire.net> <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> In-Reply-To: <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> 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-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(189002)(164054003)(83506001)(76176999)(19580395003)(101416001)(50986999)(54356999)(66066001)(64706001)(31966008)(86362001)(92726001)(15975445006)(92566001)(20776003)(40100002)(230783001)(105586002)(106116001)(106356001)(87936001)(97736003)(2656002)(36756003)(2501002)(21056001)(95666004)(85852003)(122556002)(76482002)(80022003)(46102003)(107046002)(99396003)(107886001)(120916001)(85306004)(99286002)(4396001)(77096002)(93886004); 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: 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/l5-8Rc98wj7B93-5B3vNSF3ZJ_Y Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 10 Oct 2014 18:36:17 -0000 >> >> 2.4 says: >> >> Implementations MAY optionally support TLS certificate-based >> authentication [RFC5246]. If the implementation supports TLS >> certificate-based authentication, then the following sections >> apply. >> >> Ok, so if my implementation does not support certificate-based >> authentication, how is the NETCONF username derived? > >Martin > >We did have >" Implementations MAY optionally support TLS Pre-Shared Key (PSK) > authentication [RFC4279]. RFC4279 describes pre-shared key > ciphersuites for TLS. The description of the psk-maps container in > the ietf-netconf-server YANG module, defined in > [I-D.kwatsen-netconf-server], specifies how a NETCONF server > associates a TLS pre-shared key with a NETCONF username." >as the only alternative to certificate based authentication so that was >covered. > >I am unclear whether or not PSK is still a use case for NETCONF. ...and by "we did have", Tom means that PSK is no longer defined in the current draft. FWIW, the server-model has this data-model: module: ietf-netconf-server +--rw netconf-server +--rw tls-client-auth +--rw trusted-ca-certs | +--rw trusted-ca-cert* binary +--rw trusted-client-certs | +--rw trusted-client-cert* binary +--rw cert-maps {tls-map-certificates}? | +--rw cert-to-name* [id] | +--rw id uint32 | +--rw fingerprint x509c2n:tls-fingerprint | +--rw map-type identityref | +--rw name string +--rw psk-maps {tls-map-pre-shared-keys}? +--rw psk-map* [psk-identity] +--rw psk-identity string +--rw user-name nacm:user-name-type +--rw not-valid-before? yang:date-and-time +--rw not-valid-after? yang:date-and-time +--rw key yang:hex-string which will be extended by https://github.com/netconf-wg/server-model/issues/4. But there currently isn't much description about this data-model other than in the "description" statements in the YANG module itself. While I agree that the server-model draft is missing a section under Section 2 (Objectives) (e.g., "Support SSH and TLS transports"), I also think that 5539bis needs to declare its requirements without making server-model a Normative reference. Just added https://github.com/netconf-wg/server-model/issues/14 to track this. Thanks, Kent From nobody Fri Oct 10 12:22: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 577B01ACE83 for ; Fri, 10 Oct 2014 12:22:29 -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 NUrZMfy6-d25 for ; Fri, 10 Oct 2014 12:22:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFA1ACE7F for ; Fri, 10 Oct 2014 12:22:27 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id A94B712801AA; Fri, 10 Oct 2014 21:22:25 +0200 (CEST) Date: Fri, 10 Oct 2014 21:22:25 +0200 (CEST) Message-Id: <20141010.212225.300681995.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-zzF1Cr87zC9EbMYMTUgSkjO3cw Cc: netconf@ietf.org Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 10 Oct 2014 19:22:29 -0000 Kent Watsen wrote: > > > >> > >> 2.4 says: > >> > >> Implementations MAY optionally support TLS certificate-based > >> authentication [RFC5246]. If the implementation supports TLS > >> certificate-based authentication, then the following sections > >> apply. > >> > >> Ok, so if my implementation does not support certificate-based > >> authentication, how is the NETCONF username derived? > > > >Martin > > > >We did have > >" Implementations MAY optionally support TLS Pre-Shared Key (PSK) > > authentication [RFC4279]. RFC4279 describes pre-shared key > > ciphersuites for TLS. The description of the psk-maps container in > > the ietf-netconf-server YANG module, defined in > > [I-D.kwatsen-netconf-server], specifies how a NETCONF server > > associates a TLS pre-shared key with a NETCONF username." > >as the only alternative to certificate based authentication so that was > >covered. > > > >I am unclear whether or not PSK is still a use case for NETCONF. > > > ...and by "we did have", Tom means that PSK is no longer defined in the > current draft. Yes, I understand this. But if the doc says that certificate-based authentication is optional, it should at least also say that there might be other auth mechanisms, out of the scope for this document. > FWIW, the server-model has this data-model: > > module: ietf-netconf-server > +--rw netconf-server > +--rw tls-client-auth > +--rw trusted-ca-certs > | +--rw trusted-ca-cert* binary > +--rw trusted-client-certs > | +--rw trusted-client-cert* binary > +--rw cert-maps {tls-map-certificates}? > | +--rw cert-to-name* [id] > | +--rw id uint32 > | +--rw fingerprint x509c2n:tls-fingerprint > | +--rw map-type identityref > | +--rw name string > +--rw psk-maps {tls-map-pre-shared-keys}? > +--rw psk-map* [psk-identity] > +--rw psk-identity string > +--rw user-name nacm:user-name-type > +--rw not-valid-before? yang:date-and-time > +--rw not-valid-after? yang:date-and-time > +--rw key yang:hex-string > > which will be extended by > https://github.com/netconf-wg/server-model/issues/4. > > But there currently isn't much description about this data-model other > than in the "description" statements in the YANG module itself. While I > agree that the server-model draft is missing a section under Section 2 > (Objectives) (e.g., "Support SSH and TLS transports"), I also think that > 5539bis needs to declare its requirements without making server-model a > Normative reference. > > > Just added https://github.com/netconf-wg/server-model/issues/14 to track > this. Hmm, so why does 5539bis talk about one auth mechanism but not the other? /martin From nobody Fri Oct 10 13:03:56 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 CA5911ACF95 for ; Fri, 10 Oct 2014 13:03:51 -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 r6s35IX24cJn for ; Fri, 10 Oct 2014 13:03:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0147.outbound.protection.outlook.com [65.55.169.147]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC671ACF8E for ; Fri, 10 Oct 2014 13:03:46 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 10 Oct 2014 20:03:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 20:03:43 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 Thread-Index: AQHP4S04QE86eeFbMkG3+q863EPCyZwjEoMbgAYdoQCAAGW6ev//1r4AgABQFID//8h6gA== Date: Fri, 10 Oct 2014 20:03:43 +0000 Message-ID: References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> <20141010.212225.300681995.mbj@tail-f.com> In-Reply-To: <20141010.212225.300681995.mbj@tail-f.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:CO1PR05MB457; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(76482002)(21056001)(110136001)(77096002)(20776003)(4396001)(122556002)(101416001)(83506001)(93886004)(40100003)(85306004)(230783001)(31966008)(105586002)(106116001)(64706001)(92566001)(85852003)(66066001)(50986999)(95666004)(2656002)(80022003)(99396003)(87936001)(99286002)(97736003)(106356001)(46102003)(92726001)(558084003)(76176999)(54356999)(120916001)(107046002)(86362001)(36756003); 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: <3E2B885A3F12F042839D2A240CF42CDF@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/BVfqwAIbhjbCzN7YNrT6AFRuLt8 Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 10 Oct 2014 20:03:53 -0000 >Hmm, so why does 5539bis talk about one auth mechanism but not the >other? There is a sequencing issue, the server-model update came out before the PSK info was removed from 5539bis. If the intent is to remove support for PSK, then the next update to server-model will remove it too. Kent From nobody Fri Oct 10 13:11: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 260AD1A700B for ; Fri, 10 Oct 2014 13:11:40 -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 lwCAftMCVU7E for ; Fri, 10 Oct 2014 13:11:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0757.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::757]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D8E1A6FE6 for ; Fri, 10 Oct 2014 13:11:23 -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.1049.19; Fri, 10 Oct 2014 20:10:59 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 20:10:59 +0000 From: Kent Watsen To: t.petch , netconf Thread-Topic: [Netconf] Call home reviewed Thread-Index: AQHP4XF8vLBTa1R9lEmAP2kbitRA5pwphqmA Date: Fri, 10 Oct 2014 20:10:59 +0000 Message-ID: References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> <20140321074646.GA12080@elstar.local> <002101cfdf00$b930a240$4001a8c0@gateway.2wire.net> <20141006061636.GB51842@elstar.local> <013001cfe171$22e1a140$4001a8c0@gateway.2wire.net> In-Reply-To: <013001cfe171$22e1a140$4001a8c0@gateway.2wire.net> 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:CO1PR05MB458; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(164054003)(43784003)(199003)(189002)(51704005)(20776003)(76482002)(66066001)(86362001)(64706001)(106356001)(106116001)(107886001)(77096002)(40100003)(97736003)(31966008)(105586002)(93886004)(85306004)(95666004)(99286002)(107046002)(2656002)(87936001)(50986999)(76176999)(19580395003)(36756003)(122556002)(99396003)(120916001)(85852003)(4396001)(92726001)(80022003)(46102003)(21056001)(92566001)(83506001)(15975445006)(54356999)(101416001); 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: <0E604252A64A9F47954D06A3E3AF3D00@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/YuTu6PoIG7QCDDG_oKaK05vnQIU Subject: Re: [Netconf] Call home reviewed 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, 10 Oct 2014 20:11:40 -0000 Hi Tom, Thank you for your review! Please see below for responses. Thanks, Kent >'TCP connection' I would like to see used throughout, rather than a mix >of >connection/session/stream Done >'element' is used extensively within Netconf but, AFAIK, always to refer >to a protocol element. The two ends of Netconf are commonly client and >server, so I would like to see 'network element' eradicated from this >I-D (unless it is not applicable to the management of all the other >boxes that are currently managed:-) Mostly done. I left the "network element" and "management system" terms in the Motivation section, which refers to these roles independent of any particular protocol. >There is no Introduction. Commonly the Abstract serves as part or all >of the Introduction, and I think that that is needed here, before >Motivation Done >s.3 references section 3 which I think is section 2 until you add an >Introduction in which case it becomes section 3 once more. Done. >s.4 /connection/underlying connection/ - connection on its own is >Ambiguous You are correct that it is an ambiguous statement. But this is exactly how it is written in RFC4253 and qualifying it may not be right. How about this instead? This document updates the SSH Transport Layer Protocol [RFC4253] only by removing the "The client initiates the connection" statement made in Section 4 (Connection Setup). This document assumes that the reference to "connection" refers to the underlying transport connection (e.g., TCP). Security implications related to this change are discussed in Security Considerations (Section 10). >s.6 would be easier to comment on with more subsections Done. Actually, I wound up re-arranging the doc a little, to group things more logically - please let me know if you like it. >"Using this TCP connection, the NETCONF server immediately starts > either the SSH-server or TLS-server protocol. That is, the next > message sent on the TCP stream is the initial message defined for > these protocols, per [RFC4253] or [RFC5246]." >Odd wording. For SSH there is a defined initial SSH server message, as >per RFC4253; for TLS, there is not - this paragraph could be read as >requiring the TLS server to send HelloRequest which I think wrong - >split the description of the two protocols. > >"The NETCONF protocol proceeds normally for SSH and TLS, as defined > in [RFC4253] and [RFC5539] respectively." >Odd wording. The next step is the setting up of the secure SSH or TLS >channel which I think warrants a mention. Once that is complete, then >RFC4253 is irrelevant - it is RFC6242 that matters Good catch - that was a copy/paste error, it was suppose to be RFC6242. >" The NETCONF client's perspective (e.g., the management system)" >e.g. or I.e. or omit altogether! I omitted altogether, but beware that "e.g.," is proper syntax with the comma... >" o The NETCONF client listens for TCP connections on one or both of > the IANA-assigned ports for NETCONF Call Home port (YYYY and/or > ZZZZ)." >remove second port Currently there is a port per transport, so we really do need two listed here for now. The potential to have a single "call-home" port is tracked by https://github.com/netconf-wg/call-home/issues/4 >" o Using this TCP connection, the NETCONF client immediately starts > either the SSH-server or TLS-server protocol. That is, the next > message sent on the TCP stream is the initial message defined for > these protocols, per xref target=3D"RFC4253"/> or [RFC5246]. " >I would rather the NETCONF client started the client protocols, else we >are into a reverse call home:-) Fixed - another copy/paste error. >The xref is awry but RFC4253 is appropriate here for SSH > >" o The NETCONF protocol proceeds normally for SSH and TLS, as >defined in [RFC4253] and [RFC5539] respectively." >As before, we have moved beyond RFC4253 into RFC6242 Same root-cause and fix as above. >Enough for the moment. I would like to see this lot incorporated into a >fresh I-D (or rejected) before I carry on. Coming up! ;) Thanks again, Kent From nobody Fri Oct 10 14:44: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 EB98B1A882B; Fri, 10 Oct 2014 14:44:49 -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 d38JLv_Mm1Bw; Fri, 10 Oct 2014 14:44:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA1E1A87D2; Fri, 10 Oct 2014 14:44:48 -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.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010214448.15637.19105.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 14:44:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/d3UUjSNj2ZYFMOhfDBYV9SBVs7w Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-01.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: Fri, 10 Oct 2014 21:44:50 -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-01.txt Pages : 10 Date : 2014-10-10 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-01 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 Fri Oct 10 14:47: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 B15511A87ED for ; Fri, 10 Oct 2014 14:47: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, 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 J96f0Hs2Zfbh for ; Fri, 10 Oct 2014 14:47:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332821A8854 for ; Fri, 10 Oct 2014 14:47:36 -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.1049.19; Fri, 10 Oct 2014 21:47:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Fri, 10 Oct 2014 21:47:34 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-01.txt Thread-Index: AQHP5NN6XD/V0BblhkKvHG8jqxuUtJwpmuEA Date: Fri, 10 Oct 2014 21:47:34 +0000 Message-ID: References: <20141010214448.15637.19105.idtracker@ietfa.amsl.com> In-Reply-To: <20141010214448.15637.19105.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:CO1PR05MB458; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377424004)(199003)(377454003)(479174003)(51704005)(164054003)(24454002)(85852003)(99396003)(120916001)(4396001)(92726001)(2656002)(87936001)(19580395003)(2501002)(122556002)(36756003)(19580405001)(50986999)(76176999)(54356999)(101416001)(15975445006)(21056001)(92566001)(83506001)(80022003)(46102003)(86362001)(110136001)(64706001)(66066001)(76482002)(20776003)(95666004)(85306004)(2351001)(107046002)(15202345003)(99286002)(106356001)(106116001)(77096002)(107886001)(105586002)(230783001)(31966008)(97736003)(40100003); 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/oszmbQUhfjI4KhuIujXDm3X5Om0 Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-01.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: Fri, 10 Oct 2014 21:47:39 -0000 This update addresses all of Tom's comments. Specifically: * The term "TCP connection" is now used throughout. * The terms "network element" and "management system" are now only used in the Motivation section. * Restructured doc a little to create an Introduction section. * Fixed reference in Applicability Statement so it would work equally well for SSH and TLS. * Fixed reported odd wording and three references. Thanks, Kent On 10/10/14, 5:44 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 Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-call-home-01.txt > Pages : 10 > Date : 2014-10-10 > >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-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-call-home-01 > > >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 Sun Oct 12 10:02:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CA61A6F56 for ; Sun, 12 Oct 2014 10:02:11 -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 nWU4GgeQMN_w for ; Sun, 12 Oct 2014 10:02:09 -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 838C71A6F8C for ; Sun, 12 Oct 2014 10:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4019; q=dns/txt; s=iport; t=1413133328; x=1414342928; h=message-id:date:from:mime-version:to:subject; bh=YQfMmypBeyWJaDS6abG0gnpAm8z3P150OFmxmdj+4Rk=; b=l2OWoINVkhu54x9K5I2EOPbfVeXs5GuKmNAYarDiAxY1xfBV5O0pvyd/ fHd3aLf07kqpikdoK/gLzr+s+kHBp/GmCw+pWTl2nSLkKP3Wwn3QqD7R/ BvqSDEQtBLnejyeMwnBqKlnqoRfCex3gGBsaKIFIpuG9UFlaMUfsPYv8k I=; X-IronPort-AV: E=Sophos;i="5.04,705,1406592000"; d="scan'208,217";a="203890660" 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; 12 Oct 2014 17:02:06 +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 s9CH23ta005508; Sun, 12 Oct 2014 17:02:06 GMT Message-ID: <543AB40B.3030708@cisco.com> Date: Sun, 12 Oct 2014 19:02:03 +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: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" , NETCONF Content-Type: multipart/alternative; boundary="------------000108070301040009080905" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/G-16tUafClodIA6Y2mus9Y7WgUU Subject: [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: Sun, 12 Oct 2014 17:02:11 -0000 This is a multi-part message in MIME format. --------------000108070301040009080905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I would like to close the errata 3980, http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3980 Mehmet summarized the situation below. (Thanks Mehmet) If you have a problem with the proposal, quickly let us know (a few days) Martin proposed in June to put the text into section 6.3. Klement proposed in the mail from 19.06.2014 following change: In section 6.3: OLD: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. NEW: 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 MAY be included in the filter output. Implicitly in section 6.2.5 to delete the moved text: OLD: 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. NEW: Regards, Mehmet and Benoit --------------000108070301040009080905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Dear all,

I would like to close the errata 3980, http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3980
Mehmet summarized the situation below. (Thanks Mehmet)
If you have a problem with the proposal, quickly let us know (a few days)


Martin proposed in June to put the text into section 6.3.
Klement proposed in the mail from 19.06.2014 following change:

In section 6.3:

OLD:

  The algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed.

NEW:

   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 MAY be included in the filter output.

Implicitly in section 6.2.5 to delete the moved text:

OLD:

   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.

NEW:

   <void>

Regards, Mehmet and Benoit
--------------000108070301040009080905-- From nobody Mon Oct 13 01:24: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 F37AB1A88E1 for ; Mon, 13 Oct 2014 01:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsFoR2qvNgIq for ; Mon, 13 Oct 2014 01:24:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14D81A88DC for ; Mon, 13 Oct 2014 01:24:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9D8OT1V021682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Oct 2014 08:24:29 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9D8OSbP011495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 10:24:29 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 13 Oct 2014 10:24:28 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 10:24:28 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Benoit Claise , "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" , NETCONF Thread-Topic: [Netconf] [Technical Errata Reported] RFC6241 (3980) Thread-Index: AQHP5j5J4ywEdVQfD0yZrGsVXU8BdZwtrxkw Date: Mon, 13 Oct 2014 08:24:27 +0000 Message-ID: References: <543AB40B.3030708@cisco.com> In-Reply-To: <543AB40B.3030708@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.155] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81950FB0EDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 32447 X-purgate-ID: 151667::1413188669-0000437E-78BA5593/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/I46k9m5RCjojUf2-eNRVqUYaVAE 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, 13 Oct 2014 08:24:37 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81950FB0EDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, All, we should add that there was no consensus on the use of more strong formula= tion with SHOULD or MUST. Regards, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Benoit Cla= ise Sent: Sunday, October 12, 2014 7:02 PM To: Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco); NETCO= NF Subject: [Netconf] [Technical Errata Reported] RFC6241 (3980) Dear all, I would like to close the errata 3980, http://www.rfc-editor.org/errata_sea= rch.php?rfc=3D6241&eid=3D3980 Mehmet summarized the situation below. (Thanks Mehmet) If you have a problem with the proposal, quickly let us know (a few days) Martin proposed in June to put the text into section 6.3. Klement proposed in the mail from 19.06.2014 following change: In section 6.3: OLD: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. NEW: 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 MAY be included in the filter output. Implicitly in section 6.2.5 to delete the moved text: OLD: 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. NEW: Regards, Mehmet and Benoit --_000_E4DE949E6CE3E34993A2FF8AE79131F81950FB0EDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Benoit, All,

 

we should add that there w= as no consensus on the use of more strong formulation with SHOULD or MUST.

 

Regards,
Mehmet

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Benoit C= laise
Sent: Sunday, October 12, 2014 7:02 PM
To: Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)= ; NETCONF
Subject: [Netconf] [Technical Errata Reported] RFC6241 (3980)

 

Dear al= l,

I would= like to close the errata 3980, http://www.rfc-editor.org/errata_search.php?rfc=3D6241&eid=3D3= 980
Mehmet summarized the situation below. (Thanks Mehmet)
If you have a problem with the proposal, quickly let us know (a few days)


Martin proposed in June to put the text into section 6.3.
Klement proposed in the mail from 19.06.2014 following change: <= /span>

In section 6.3:

OLD:

  The algorithm continues until all sibling sets in all subtrees specified
   in the filter have bee= n processed.

NEW:

   The algorithm continues until all sibling sets in all subtrees specified
   in the filter have bee= n processed. If any sibling nodes of a node
   are instance iden= tifier components for a conceptual data structure
   (e.g., list key l= eaf), then they MAY be included in the filter output.

Implici= tly in section 6.2.5 to delete the moved text:

OLD:

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

NEW:

   <= ;void>

Regards, Mehmet and Benoit

--_000_E4DE949E6CE3E34993A2FF8AE79131F81950FB0EDEMUMBX005nsnin_-- From nobody Mon Oct 13 04:50: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 63AB21A898E for ; Mon, 13 Oct 2014 04:50:23 -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 QQjtC0hkT-nW for ; Mon, 13 Oct 2014 04:50:20 -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 35DB01A898D for ; Mon, 13 Oct 2014 04:50:20 -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 1Xde8n-0007om-6m for netconf@ietf.org; Mon, 13 Oct 2014 13:50:19 +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 1Xde8n-0007nO-1g for netconf@ietf.org; Mon, 13 Oct 2014 13:50:17 +0200 Message-ID: <543BBC77.9030903@bwijnen.net> Date: Mon, 13 Oct 2014 13:50:15 +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> <543394E7.7050902@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: 86ab03e524994f79ca2c75a176445dd4d7f1678162ffa84a24889655c7f9a0d6 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/S0Tw9AgSxM_TfU8mDypcDtqwEo0 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, 13 Oct 2014 11:50:23 -0000 So with Mehemt and myself choosing/vouching for a), we have 10 for a) and 8 for d) (sorry that I said c) in an earlier email). Lada then claims: > Either way, it is IMO nowhere near to rough consensus. Can anyone tell us what then constitutues "rough consensus"? I am OK if yount to call it "very rough consensus". But I do not see we cann claim that option d) has "rough consensus". Bert On 09/10/14 19:43, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Andy, All, > > in reality it was 8 for a) and 8 for d) until Mahesh changed his mind in favor of d). > > However with the conclusion mail below you may count both co-chair’s votes in favor of a). > > We indeed think that a) had reasonable support with good technical arguments, which are mainly “less options, less complexity, > better understood”. > > You may count the co-chairs now to “old-school” but we believe that a) improves interoperability. > > Mehmet > From nobody Mon Oct 13 05:04: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 A207C1A89B5 for ; Mon, 13 Oct 2014 05:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 T8lkxXe6zLmj for ; Mon, 13 Oct 2014 05:04:39 -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 C11E11A89C4 for ; Mon, 13 Oct 2014 05:04:36 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 54FB514012E; Mon, 13 Oct 2014 14:04:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413201875; bh=sN5jDG/W42fvXL6vtDXpZfSwACZ96sFRveRZr+w1C9o=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FmD3DnPj6ZbA5Kx9ffZ203jsKjlpzAu75bV/q3zH4ssZt1sljtaxlT4C2d/v2qcfD 8+bqWLDDtjX/l/4NXP9r3/JuCyLpK6dzAmG7xrquL37n+qrTwWQhT15bmI9vvtk4RU HRkRfYSl5mpFcDsNEu8EjpwxkXV3D0LV9avjX9C8= 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: <543BBC77.9030903@bwijnen.net> Date: Mon, 13 Oct 2014 14:04:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5EEFD16A-7B1E-4127-AB02-1A469E469AB4@nic.cz> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> <543BBC77.9030903@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/zC09nNyNmK2xVIjizTF2Uw_qNIs 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, 13 Oct 2014 12:04:40 -0000 On 13 Oct 2014, at 13:50, Bert Wijnen (IETF) = wrote: > So with Mehemt and myself choosing/vouching for a), we have 10 for a) > and 8 for d) (sorry that I said c) in an earlier email). >=20 > Lada then claims: > > Either way, it is IMO nowhere near to rough consensus. >=20 > Can anyone tell us what then constitutues "rough consensus=94? =46rom =93The Tao of IETF=94: The general rule on disputed topics is that the Working Group has to = come to "rough consensus", meaning that a very large majority of those = who care must agree. > I am OK if yount to call it "very rough consensus". But I do not > see we cann claim that option d) has "rough consensus=94. I didn=92t say that. Without rough consensus, I think the RESTCONF spec = should not require any encoding to be mandatory and leave it to = implementors to choose one that=92s appropriate for a particular use = case. Lada >=20 > Bert >=20 > On 09/10/14 19:43, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Hi Andy, All, >>=20 >> in reality it was 8 for a) and 8 for d) until Mahesh changed his mind = in favor of d). >>=20 >> However with the conclusion mail below you may count both co-chair=92s = votes in favor of a). >>=20 >> We indeed think that a) had reasonable support with good technical = arguments, which are mainly =93less options, less complexity, >> better understood=94. >>=20 >> You may count the co-chairs now to =93old-school=94 but we believe = that a) improves interoperability. >>=20 >> Mehmet >>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 13 05:53: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 950091A8A5A for ; Mon, 13 Oct 2014 05:53:27 -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 4riBi41MZgJS for ; Mon, 13 Oct 2014 05:53: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 529291A8A59 for ; Mon, 13 Oct 2014 05:53:25 -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 1Xdf7n-0001eI-7F; Mon, 13 Oct 2014 14:53:21 +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 1Xdf7n-0003wo-3Q; Mon, 13 Oct 2014 14:53:19 +0200 Message-ID: <543BCB3D.7080806@bwijnen.net> Date: Mon, 13 Oct 2014 14:53:17 +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: Ladislav Lhotka References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> <543BBC77.9030903@bwijnen.net> <5EEFD16A-7B1E-4127-AB02-1A469E469AB4@nic.cz> In-Reply-To: <5EEFD16A-7B1E-4127-AB02-1A469E469AB4@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: 86ab03e524994f79ca2c75a176445dd4232188829d63ee5ad363edae3c57fc8f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/J_LPkHC4zW9MXmFEvxcGtxB-5n4 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, 13 Oct 2014 12:53:27 -0000 inline On 13/10/14 14:04, Ladislav Lhotka wrote: > On 13 Oct 2014, at 13:50, Bert Wijnen (IETF) wrote: > >> >So with Mehemt and myself choosing/vouching for a), we have 10 for a) >> >and 8 for d) (sorry that I said c) in an earlier email). >> > >> >Lada then claims: >>> > >Either way, it is IMO nowhere near to rough consensus. >> > >> >Can anyone tell us what then constitutues "rough consensus”? > From “The Tao of IETF”: > > The general rule on disputed topics is that the Working Group has to come to "rough consensus", > meaning that a very large majority of those who care must agree. > >> >I am OK if you want to call it "very rough consensus". But I do not >> >see we can claim that option d) has "rough consensus”. > I didn’t say that. Without rough consensus, I think the RESTCONF spec should not require any > encoding to be mandatory and leave it to implementors to choose one that’s appropriate for a > particular use case. > Lada, apologies if you understood me to say that "you said that option d) did have rough concensus". You did not. But as chairs we cannot claim that d) has rough consensus. This what I meant to say. We as WG chairs still believe that a) had the best support and best supporting arguments. One can quibble about it not being "very large majority". In my view, a "very large majority basically means consensus". Consensus does not require 100% agreement from all. In my view: - consensus means: a very large majority agrees, no MAJOR OBJECTIONS - rough consensus: majority agrees, no MAJOR OBJECTIONS - very rough consensus: small majority (just above 50% of casted opinions) agrees, and no MAJOR OBJECTIONS. So I'd say we have "very rough consensus". I can't help that most people on our mailing list seem to not be bothered and do not express their opinion one way or another. So as a WG co-chair, I do not see how we can move forward if we as WG chairs do not just take a decision and declare what we think is consensus. So: do you have a MAJOR OBJECTION, and do you want us to continue the discussion for another x months? We can issue (re-issue) another WGLC and state that if we do not get at least say 500 responses that we will drop the document all together. Maybe that wakes up people??? Or can you accept our interpretation for "rough consensus for a)."? Bert > Lada > >> > From nobody Mon Oct 13 06:43: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 579991A1A82 for ; Mon, 13 Oct 2014 06:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 1jz-Ry08Gs19 for ; Mon, 13 Oct 2014 06:43:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1C51A1A7B for ; Mon, 13 Oct 2014 06:43:48 -0700 (PDT) Received: from [192.168.1.108] (unknown [195.113.220.254]) by mail.nic.cz (Postfix) with ESMTPSA id 5C024140C6A; Mon, 13 Oct 2014 15:43:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413207827; bh=IXW38FlmzkPe4GVI5amDvqLKTVvS4Lqv+nIzXQWW+W8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VAS7gGbBm3yNX7zh/xdDnwlT+JcQYu50lZTztWBQVbD/Vf/bVvlYQTbdwrPedBRNS QjAFhXrKtQKcGcwDphwoZk/N9QBSqYK3O0Y1auk5S/+4Rj9FUQ4euX38g2Y5f6wi2E YOpdp9c3tG01z1Uhkcnl5+r6lczjhpQKEE4fE9dQ= 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: <543BCB3D.7080806@bwijnen.net> Date: Mon, 13 Oct 2014 15:43:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> <543BBC77.9030903@bwijnen.net> <5EEFD16A-7B1E-4127-AB02-1A469E469AB4@nic.cz> <543BCB3D.7080806@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/DU_FrJom0VjYUkz0DP2p2JBTClw 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, 13 Oct 2014 13:43:50 -0000 On 13 Oct 2014, at 14:53, Bert Wijnen (IETF) = wrote: > inline >=20 > On 13/10/14 14:04, Ladislav Lhotka wrote: >> On 13 Oct 2014, at 13:50, Bert Wijnen (IETF) = wrote: >>=20 >>> >So with Mehemt and myself choosing/vouching for a), we have 10 for = a) >>> >and 8 for d) (sorry that I said c) in an earlier email). >>> > >>> >Lada then claims: >>>> > >Either way, it is IMO nowhere near to rough consensus. >>> > >>> >Can anyone tell us what then constitutues "rough consensus=94? >> =46rom =93The Tao of IETF=94: >>=20 >> The general rule on disputed topics is that the Working Group has to = come to "rough consensus", >> meaning that a very large majority of those who care must agree. >>=20 >>> >I am OK if you want to call it "very rough consensus". But I do not >>> >see we can claim that option d) has "rough consensus=94. >> I didn=92t say that. Without rough consensus, I think the RESTCONF = spec should not require any >> encoding to be mandatory and leave it to implementors to choose one = that=92s appropriate for a >> particular use case. >>=20 > Lada, apologies if you understood me to say that "you said that option = d) did have rough concensus". > You did not. But as chairs we cannot claim that d) has rough = consensus. This what I meant to say. Right, I think it is fair to say there is no rough consensus for any of = the options. >=20 > We as WG chairs still believe that a) had the best support and best = supporting arguments. > One can quibble about it not being "very large majority". In my view, = a "very large majority > basically means consensus". Consensus does not require 100% agreement = from all. > In my view: > - consensus means: a very large majority agrees, no MAJOR OBJECTIONS > - rough consensus: majority agrees, no MAJOR OBJECTIONS In my view, marginal majority is not the same as rough consensus. > - very rough consensus: small majority (just above 50% of casted = opinions) agrees, > and no MAJOR OBJECTIONS. >=20 > So I'd say we have "very rough consensus". > I can't help that most people on our mailing list seem to not be = bothered and do not express > their opinion one way or another. So as a WG co-chair, I do not see = how we can move forward > if we as WG chairs do not just take a decision and declare what we = think is consensus. >=20 > So: do you have a MAJOR OBJECTION, and do you want us to continue the = discussion > for another x months? We can issue (re-issue) another WGLC and state = that if we do not get > at least say 500 responses that we will drop the document all = together. Maybe that wakes up > people??? >=20 > Or can you accept our interpretation for "rough consensus for a).=94? The Tao also says it is up to WG chairs to decide when rough consensus = was reached, so I will have to accept it. I just think going for a) = would be a mistake because it is at odds with 2014 reality. =46rom the = feedback I receive it seems clear to me that the momentum is now behind = JSON and not XML, whether we like it or not. The main technical argument in favor of JSON is that it is *dead simple* = and yet it will do the job in many/most cases. This is often what = counts. Lada >=20 > Bert >=20 >> Lada >>=20 >>> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 13 08:08: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 34A2C1A01E0 for ; Mon, 13 Oct 2014 08:08:44 -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 cBKLGI9XS0SU for ; Mon, 13 Oct 2014 08:08:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A201A1A0327 for ; Mon, 13 Oct 2014 08:08:38 -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.1049.19; Mon, 13 Oct 2014 15:08:13 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Mon, 13 Oct 2014 15:08:13 +0000 From: Kent Watsen To: Ladislav Lhotka , Bert Wijnen Thread-Topic: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity Thread-Index: AQHPxpf7oQcD6jS4CketzovkXj97oJwkcfKAgACX4wCAAzoVAIAF5pqAgAAD/gCAAA2egIAADhiA///UigA= Date: Mon, 13 Oct 2014 15:08:13 +0000 Message-ID: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> <543BBC77.9030903@bwijnen.net> <5EEFD16A-7B1E-4127-AB02-1A469E469AB4@nic.cz> <543BCB3D.7080806@bwijnen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.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-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(19580395003)(101416001)(122556002)(54356999)(15202345003)(76176999)(50986999)(92726001)(31966008)(20776003)(86362001)(66066001)(64706001)(92566001)(15975445006)(83506001)(4396001)(85306004)(120916001)(93886004)(77096002)(97736003)(46102003)(80022003)(36756003)(21056001)(2656002)(87936001)(76482002)(85852003)(99286002)(95666004)(106116001)(105586002)(40100003)(106356001); 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: text/plain; charset="us-ascii" Content-ID: <82727145B2CE4A4AAF26AD61003AEA60@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/b88uaGn7xjkK_EuVia2u4xxbBqk 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, 13 Oct 2014 15:08:44 -0000 I think folks are overlooking that fact that (d) will be implemented regardless what the RFC says. This is much like how some devices may only implement TLS, even though the standard says SSH is required. Is this not a MAJOR OBJECTION? That said, I still don't understand the interoperability or complexity concerns, and I think it more worthwhile to focus on how (d) could be implemented. One way to do this is to put annotations into the .well-known/host-meta document, specifically using the "Property" element: Request ------- GET /.well-known/host-meta users HTTP/1.1 Host: example.com Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn json xml // This RESTCONF server supports both JSON and XML (future encodings TBD) Per RFC6415, the .well-known/host-meta document is of type application/xrd+xml (i.e. a fixed-format, easy to parse). Additionally, this document is static - no code needs to generate it, which means it doesn't swing the RESTCONF server towards implementing either XML or JSON (it's neutral). Thanks, Kent From nobody Mon Oct 13 08:49: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 1A0FA1A0352 for ; Mon, 13 Oct 2014 08:49:52 -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 GHQGcrpi-Jwd for ; Mon, 13 Oct 2014 08:49:51 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916E01A1A4A for ; Mon, 13 Oct 2014 08:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1734; q=dns/txt; s=iport; t=1413215390; x=1414424990; h=message-id:date:from:mime-version:to:subject; bh=ITePW0SqNeg3U1FKKPZI2MT7Xkbq+WCc6wUpK7o14AA=; b=degwjAujlnGQ18sRsm//WxKT9ETKawDNBNiE8bvve/ghwxEjMxG8vesU XE7lu7haO6ZKrXLrFuR1pyFc0ZmgHEQIgOHKp6xX5kkmZANVQ9N47lWb0 /L8K9DqdsiE8fBAzK3QxHT/9DnlKF6ogW1QhDzDol/PCJT0VxrjxMo/cv 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUGAET0O1StJssW/2dsb2JhbABb1ygDgTcBfYN5gQgfAR0WGAMCAQIBSw0IAQGIOqBGpFQBCgEBAR6VFwEEnUuBLoNGgnKKLYN+g3k7gnkBAQE X-IronPort-AV: E=Sophos;i="5.04,711,1406592000"; d="scan'208,217";a="209884241" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 13 Oct 2014 15:49:29 +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 s9DFnT2Z017757 for ; Mon, 13 Oct 2014 15:49:29 GMT Message-ID: <543BF489.7000708@cisco.com> Date: Mon, 13 Oct 2014 17:49:29 +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 Content-Type: multipart/alternative; boundary="------------000401040206090507080409" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/MCSGKq2UrhKNtMMd2aFTRXM7Gkw Subject: [Netconf] Looking for a new NETCONF co-chair 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, 13 Oct 2014 15:49:52 -0000 This is a multi-part message in MIME format. --------------000401040206090507080409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I have to announce, with mixed feelings, that one of my mentors at the IETF decided to retire. On one hand, I'm pretty happy for *Bert Wijnen* to enjoy his well deserved retirement. On the hand, Bert will be missed, for sure. Not only as a leader, a mentor, but also a friend. Note that Bert will be attending his last IETF meeting in Honolulu. This is your chance... Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested. Regards, Benoit --------------000401040206090507080409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I have to announce, with mixed feelings, that one of my mentors at the IETF decided to retire.
On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor, but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is your chance...

Practically, this implies that we are looking for a new NETCONF co-chair.
Please let Joel and I know if you are interested.

Regards, Benoit


--------------000401040206090507080409-- From nobody Mon Oct 13 09:16: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 3DC151A039A for ; Mon, 13 Oct 2014 09:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 pDX6oMa16qB8 for ; Mon, 13 Oct 2014 09:16:46 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA941A0393 for ; Mon, 13 Oct 2014 09:16:45 -0700 (PDT) Received: from Vanguard ([84.92.149.4]) by avasout04 with smtp id 2gGh1p00105w0Nk01gGi0t; Mon, 13 Oct 2014 17:16:43 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=V9zz0IXi c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=0B8HqoTn75oA:10 a=kj9zAlcOel0A:10 a=6bkCdLdQAAAA:8 a=48vgC7mUAAAA:8 a=A1X0JdhQAAAA:8 a=mkMtH7XpAAAA:8 a=w_UAShrQXqrRJ9h1ByIA:9 a=XGxIkNX1_K1_PBWS:21 a=mcFPCVh-NUgdIslu:21 a=CjuIK1q_8ugA:10 a=4rq7TwIXcRUA:10 a=lZB815dzVvQA:10 From: "Jonathan Hansford" To: "'Kent Watsen'" , "'Ladislav Lhotka'" , "'Bert Wijnen'" References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> <543BBC77.9030903@bwijnen.net> <5EEFD16A-7B1E-4127-AB02-1A469E469AB4@nic.cz> <543BCB3D.7080806@bwijnen.net> In-Reply-To: Date: Mon, 13 Oct 2014 17:16:47 +0100 Message-ID: <030b01cfe701$17dee1a0$479ca4e0$@hansfords.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJNBF+dKU8S8HVgbLsBnJzxTDtdxQGMjoPBAgnrnXwBo9w/cALHHffsAepRd1ACFgxdaAIgG8OwAdQ6nAUC7qfp3gDtr8tdAY116soDLVaLVAFLv/wimmUvHwA= Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/aGwG0aIsY-58eIG-yftmwq_Kd4Y 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, 13 Oct 2014 16:16:48 -0000 I have been advised by my security people that, for the environment where we are considering NETCONF, SSH is not acceptable. Consequently I would not want to burden manufacturers with having to implement SSH on their devices (despite the RFC). On that basis, though my initial unstated preference was for (a), I can understand the argument for (d) below. -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen Sent: 13 October 2014 16:08 To: Ladislav Lhotka; Bert Wijnen Cc: Netconf Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity I think folks are overlooking that fact that (d) will be implemented regardless what the RFC says. This is much like how some devices may only implement TLS, even though the standard says SSH is required. Is this not a MAJOR OBJECTION? That said, I still don't understand the interoperability or complexity concerns, and I think it more worthwhile to focus on how (d) could be implemented. One way to do this is to put annotations into the .well-known/host-meta document, specifically using the "Property" element: Request ------- GET /.well-known/host-meta users HTTP/1.1 Host: example.com Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn xml // This RESTCONF server supports both JSON and XML (future encodings TBD) Per RFC6415, the .well-known/host-meta document is of type application/xrd+xml (i.e. a fixed-format, easy to parse). Additionally, this document is static - no code needs to generate it, which means it doesn't swing the RESTCONF server towards implementing either XML or JSON (it's neutral). Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Oct 13 10:20: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 6C2361A1B92 for ; Mon, 13 Oct 2014 10:20:53 -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 9Udk1wHQooto for ; Mon, 13 Oct 2014 10:20:49 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCEE1A1B8E for ; Mon, 13 Oct 2014 10:20:45 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so5430984qcz.9 for ; Mon, 13 Oct 2014 10:20:45 -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=8tUL1gMV1kdOxtxou2TrH5rp/H+EINCgaq/rNAdpxxM=; b=Fd7P+rtZfDAK7oa3WxUQlB0CaY/azQDh1r/RHhnyE5z9mNoYVWD/ku4BsNpXILY5QS ZEBExGdyHS0TD50WqZ3pjBOf935ELhSdRsjo9PzyABCxgVQHmAD47HXriBc4FiNqhTGN JNkC2kkAIRp5ZsuQKA5EPLx3dgP/9qVHEZd5gmzRafFzDmFtB1yt5ZWEiVsHPqCxt/mR m7DaJkqioRIN2L4l1OuxJuo80OXxuVHQX3RFvGzKnQDJTk16ZIdHgrtelrm7kLEUUWRV K2Mi8on3ug6ySCgwb1VR1q3WhwzyNsy1G8whYVCkdUzdr/wlxYPZ3Zfe+fk6/FclmqPt oAvw== X-Gm-Message-State: ALoCoQkhI/P9oN0tgqzLeOZvIBGRgmIStGrxxLY9keRBpbj0xiuNT1ltbULANnTf1doHjmaP/EdH MIME-Version: 1.0 X-Received: by 10.140.39.103 with SMTP id u94mr1620951qgu.36.1413220845120; Mon, 13 Oct 2014 10:20:45 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 13 Oct 2014 10:20:44 -0700 (PDT) In-Reply-To: <030b01cfe701$17dee1a0$479ca4e0$@hansfords.net> References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> <543BBC77.9030903@bwijnen.net> <5EEFD16A-7B1E-4127-AB02-1A469E469AB4@nic.cz> <543BCB3D.7080806@bwijnen.net> <030b01cfe701$17dee1a0$479ca4e0$@hansfords.net> Date: Mon, 13 Oct 2014 10:20:44 -0700 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=001a11c13ae2768eee0505511e76 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/acoRh2LlKs7CjJKlgY-uBTv--iA 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, 13 Oct 2014 17:20:55 -0000 --001a11c13ae2768eee0505511e76 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Mon, Oct 13, 2014 at 9:16 AM, Jonathan Hansford wrote: > I have been advised by my security people that, for the environment where > we > are considering NETCONF, SSH is not acceptable. Consequently I would not > want to burden manufacturers with having to implement SSH on their devices > (despite the RFC). On that basis, though my initial unstated preference was > for (a), I can understand the argument for (d) below. > > I do not object to the XML requirement because it is clearly a more mature standard than JSON at this time -- but JSON adoption is growing rapidly, and we know it. At the time SSH was made the mandatory transport for NETCONF in 2004, there was nothing else replacing CLI over SSH. Making XML mandatory ensures that servers will have to implement both JSON and XML for many years to come, and the clients will be free to choose which encoding to support. (The exact opposite of what is really needed.) Andy > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: 13 October 2014 16:08 > To: Ladislav Lhotka; Bert Wijnen > Cc: Netconf > Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your > opinion on RESTCONF modularity > > > I think folks are overlooking that fact that (d) will be implemented > regardless what the RFC says. This is much like how some devices may only > implement TLS, even though the standard says SSH is required. Is this not > a > MAJOR OBJECTION? > > That said, I still don't understand the interoperability or complexity > concerns, and I think it more worthwhile to focus on how (d) could be > implemented. One way to do this is to put annotations into the > .well-known/host-meta document, specifically using the "Property" element: > > Request > ------- > GET /.well-known/host-meta users HTTP/1.1 > Host: example.com > Accept: application/xrd+xml > > > Response > -------- > HTTP/1.1 200 OK > Content-Type: application/xrd+xml > Content-Length: nnn > > > type="urn:ietf:params:xml:ns:yang:ietf-restconf/encoding>json > type="urn:ietf:params:xml:ns:yang:ietf-restconf/encoding>xml > > > > > // This RESTCONF server supports both JSON and XML (future encodings > TBD) > > > > Per RFC6415, the .well-known/host-meta document is of type > application/xrd+xml (i.e. a fixed-format, easy to parse). Additionally, > this document is static - no code needs to generate it, which means it > doesn't swing the RESTCONF server towards implementing either XML or JSON > (it's neutral). > > Thanks, > Kent > > > > > _______________________________________________ > 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 > --001a11c13ae2768eee0505511e76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Mon, Oct 13, 2014 at 9:16 AM, Jonathan Hansford <jonat= han@hansfords.net> wrote:
I= have been advised by my security people that, for the environment where we=
are considering NETCONF, SSH is not acceptable. Consequently I would not want to burden manufacturers with having to implement SSH on their devices<= br> (despite the RFC). On that basis, though my initial unstated preference was=
for (a), I can understand the argument for (d) below.



I do not object to the = XML requirement because it is clearly a more mature standard
than= JSON at this time -- but JSON adoption is growing rapidly, and we know it.=
At the time SSH was made the mandatory transport for NETCONF in = 2004, there was
nothing else replacing CLI over SSH.
Making XML mandatory ensures that servers will have to impleme= nt both JSON and XML
for many years to come, and the clients will= be free to choose which encoding to support.
(The exact opposite= of what is really needed.)


Andy

=A0
-----Original Message-----
From: Netconf [mailto:netconf-b= ounces@ietf.org] On Behalf Of Kent Watsen
Sent: 13 October 2014 16:08
To: Ladislav Lhotka; Bert Wijnen
Cc: Netconf
Subject: Re: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity


I think folks are overlooking that fact that (d) will be implemented
regardless what the RFC says.=A0 This is much like how some devices may onl= y
implement TLS, even though the standard says SSH is required.=A0 Is this no= t a
MAJOR OBJECTION?

That said, I still don't understand the interoperability or complexity<= br> concerns, and I think it more worthwhile to focus on how (d) could be
implemented.=A0 One way to do this is to put annotations into the
.well-known/host-meta document, specifically using the "Property"= element:

=A0 =A0 =A0 Request
=A0 =A0 =A0 -------
=A0 =A0 =A0 GET /.well-known/host-meta users HTTP/1.1
=A0 =A0 =A0 Host: example.= com
=A0 =A0 =A0 Accept: application/xrd+xml


=A0 =A0 =A0 Response
=A0 =A0 =A0 --------
=A0 =A0 =A0 HTTP/1.1 200 OK
=A0 =A0 =A0 Content-Type: application/xrd+xml
=A0 =A0 =A0 Content-Length: nnn
=A0 =A0 =A0 <XRD xmlns=3D'http://docs.oasis-open.org/ns/xri/xrd-1.0= '>
=A0 =A0 =A0 =A0 =A0 <Link rel=3D'restconf' href=3D'/restconf= '>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <Property
type=3D"urn:ietf:params:xml:ns:yang:ietf-restconf/encoding>json<= /Property>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 <Property
type=3D"urn:ietf:params:xml:ns:yang:ietf-restconf/encoding>xml</= Property>
=A0 =A0 =A0 =A0 =A0 </Link>
=A0 =A0 =A0 </XRD>


=A0 =A0 =A0 // This RESTCONF server supports both JSON and XML (future enco= dings
TBD)



Per RFC6415, the .well-known/host-meta document is of type
application/xrd+xml (i.e. a fixed-format, easy to parse).=A0 Additionally,<= br> this document is static - no code needs to generate it, which means it
doesn't swing the RESTCONF server towards implementing either XML or JS= ON
(it's neutral).

Thanks,
Kent




_______________________________________________
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

--001a11c13ae2768eee0505511e76-- From nobody Mon Oct 13 11:03: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 A19321A86F3 for ; Mon, 13 Oct 2014 11:03:50 -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 yrOmAd3F7_2W for ; Mon, 13 Oct 2014 11:03:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:711]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E251A6F3F for ; Mon, 13 Oct 2014 11:03:48 -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.1049.19; Mon, 13 Oct 2014 18:03:24 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Mon, 13 Oct 2014 18:03:24 +0000 From: Kent Watsen To: Jonathan Hansford Thread-Topic: [Netconf] WG Last Call (expires Sept 18 2014): express your opinion on RESTCONF modularity Thread-Index: AQHPxpf7oQcD6jS4CketzovkXj97oJwkcfKAgACX4wCAAzoVAIAF5pqAgAAD/gCAAA2egIAADhiA///UigCAAFY6gP//2rqA Date: Mon, 13 Oct 2014 18:03:24 +0000 Message-ID: References: <53FCA5B7.3030105@cisco.com> <20140826.223423.176169295.mbj@tail-f.com> <54059AA9.4080902@bwijnen.net> <543394E7.7050902@bwijnen.net> <543BBC77.9030903@bwijnen.net> <5EEFD16A-7B1E-4127-AB02-1A469E469AB4@nic.cz> <543BCB3D.7080806@bwijnen.net> <030b01cfe701$17dee1a0$479ca4e0$@hansfords.net> In-Reply-To: <030b01cfe701$17dee1a0$479ca4e0$@hansfords.net> 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:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(479174003)(189002)(24454002)(199003)(93886004)(85306004)(36756003)(106116001)(87936001)(2656002)(77096002)(40100003)(106356001)(95666004)(99286002)(19580405001)(19580395003)(85852003)(105586002)(21056001)(46102003)(66066001)(80022003)(110136001)(101416001)(120916001)(64706001)(76482002)(20776003)(122556002)(86362001)(92726001)(92566001)(83506001)(97736003)(4396001)(76176999)(54356999)(50986999)(31966008); 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: <6E3102812BB06740815171ADDD56449D@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/IwIQ3I0YUepwl6YV4yjjJ8FIsM8 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, 13 Oct 2014 18:03:50 -0000 Hi Jonathan, Can say anything about why SSH is not acceptable? In particular, if only using SSH with X.509 certificates (RFC6187), would there still be an objection? Thanks, Kent On 10/13/14, 12:16 PM, "Jonathan Hansford" wrote: >I have been advised by my security people that, for the environment where >we >are considering NETCONF, SSH is not acceptable. Consequently I would not >want to burden manufacturers with having to implement SSH on their devices >(despite the RFC). On that basis, though my initial unstated preference >was >for (a), I can understand the argument for (d) below. From nobody Mon Oct 13 11:51: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 4665A1A02ED for ; Mon, 13 Oct 2014 11:51: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, HTML_MESSAGE=0.001, 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 eQDVHvhRcNgq for ; Mon, 13 Oct 2014 11:51:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090E71A0301 for ; Mon, 13 Oct 2014 11:51:30 -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.1049.19; Mon, 13 Oct 2014 18:51:07 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Mon, 13 Oct 2014 18:51:07 +0000 From: Kent Watsen To: NETCONF Thread-Topic: [Netconf] Looking for a new NETCONF co-chair Thread-Index: AQHP5v1ZeBTNpK5sQ0+4wZBF5rpYG5wuHEEA Date: Mon, 13 Oct 2014 18:51:07 +0000 Message-ID: References: <543BF489.7000708@cisco.com> In-Reply-To: <543BF489.7000708@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.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(43784003)(199003)(120916001)(21056001)(36756003)(77096002)(97736003)(46102003)(80022003)(85306004)(4396001)(107886001)(106116001)(95666004)(107046002)(106356001)(105586002)(40100003)(99286002)(85852003)(76482002)(2656002)(87936001)(16236675004)(122556002)(54356999)(50986999)(76176999)(19580395003)(19580405001)(101416001)(110136001)(83506001)(20776003)(31966008)(92726001)(64706001)(66066001)(92566001)(86362001); 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: multipart/alternative; boundary="_000_D061949284FD4kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/cXr9Cmy8YsaVZsn2vnRxG-rZKsk Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 13 Oct 2014 18:51:33 -0000 --_000_D061949284FD4kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bert, Thank you for pouring yourself into this working group and providing the gu= idance that helped bring us to where we are now. Thanks again, Kent From: Benoit Claise > Date: Monday, October 13, 2014 at 11:49 AM To: NetConf > Subject: [Netconf] Looking for a new NETCONF co-chair Dear all, I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire. On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved re= tirement. On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend. Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance... Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested. Regards, Benoit --_000_D061949284FD4kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Bert, 

Thank you for pouring yourself into = this working group and providing the guidance that helped bring us to where= we are now.

Thanks again,
Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Monday, October 13, 2014 at 1= 1:49 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf] Looking for a ne= w NETCONF co-chair

Dear all,

I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire.
On one hand, I'm pretty happy for Bert Wijnen to enjoy his well dese= rved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance...

Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested.

Regards, Benoit


 --_000_D061949284FD4kwatsenjunipernet_-- From nobody Mon Oct 13 11:54: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 C03401A0301 for ; Mon, 13 Oct 2014 11:54:48 -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 C02kz1An_qZp for ; Mon, 13 Oct 2014 11:54:47 -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 29F341A01B0 for ; Mon, 13 Oct 2014 11:54:47 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id r5so5426094qcx.40 for ; Mon, 13 Oct 2014 11:54: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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=31+nTMD+aZfOCLHhC9Dii92xsGt2Tp3t3pyRpgzhJ0Q=; b=hL+iYladmoiuKF1crE2NmytfR/QPo7di/zkxUmmv3rOU8W2Z8+uU2khQBsLY6wL6CN 0zc5xJxZWy4O83/6uuXruvMkPiE2KmYJJzmeYlGp3iWjv/I3MRYVv79mFesRB8PBnDeM kH0Ge92Nl3eL9nGOOtp6TLjjns0VEDYxTf9Y7AuuUh/84hlnWu+g/ZaefFERNhJhWjL4 1EMAj9xy8W6E97ixWFgo4Rugn6b1kopA4Bdw5e4/QskVbkKejlnwo8KaProv6L++4Q1u enPRpFO9KUa04oHboY+Za4BCqPJ0Yru05HMy+nh7/1xxAN9rZHjbed2YkhdX4Q1yyZF0 /HNA== X-Gm-Message-State: ALoCoQnqUwWlYYm/wiP9cgk/Tm6kbUR71FFfwlAsWryyfGs9gelTwBJlF/073bLB5KIXV9YW+xHL MIME-Version: 1.0 X-Received: by 10.224.130.198 with SMTP id u6mr441814qas.99.1413226486308; Mon, 13 Oct 2014 11:54:46 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 13 Oct 2014 11:54:46 -0700 (PDT) In-Reply-To: References: <543BF489.7000708@cisco.com> Date: Mon, 13 Oct 2014 11:54:46 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=089e0158b38cb446aa0505526e9a Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FkvC9bDsfW_kWjKm54ftSovc8G8 Cc: NETCONF Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 13 Oct 2014 18:54:49 -0000 --089e0158b38cb446aa0505526e9a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 13, 2014 at 11:51 AM, Kent Watsen wrote: > > Bert, > > Thank you for pouring yourself into this working group and providing the > guidance that helped bring us to where we are now. > > +1 Now I have a good reason to go to the Honolulu IETF! > Thanks again, > Kent > Andy > > > From: Benoit Claise > Date: Monday, October 13, 2014 at 11:49 AM > To: NetConf > Subject: [Netconf] Looking for a new NETCONF co-chair > > Dear all, > > I have to announce, with mixed feelings, that one of my mentors at the > IETF decided to retire. > On one hand, I'm pretty happy for *Bert Wijnen* to enjoy his well > deserved retirement. > On the hand, Bert will be missed, for sure. Not only as a leader, a > mentor, but also a friend. > Note that Bert will be attending his last IETF meeting in Honolulu. This > is your chance... > > Practically, this implies that we are looking for a new NETCONF co-chair. > Please let Joel and I know if you are interested. > > Regards, Benoit > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --089e0158b38cb446aa0505526e9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 13, 2014 at 11:51 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Bert,=A0

Thank you for pouring yourself into = this working group and providing the guidance that helped bring us to where= we are now.


+1

Now I have a good reason to go to the Honolulu IETF!

=
=A0
Thanks again,
Kent


Andy
<= div>=A0


From: Benoit Claise <bclaise@cisco.com>
Date: Monday, October 13, 2014 at 1= 1:49 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf] Looking for a ne= w NETCONF co-chair

Dear all,

I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire.
On one hand, I'm pretty happy for Bert Wijnen to enjoy his well = deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance...

Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested.

Regards, Benoit



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


--089e0158b38cb446aa0505526e9a-- From nobody Mon Oct 13 12:10: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 7470C1A700F for ; Mon, 13 Oct 2014 12:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 fVs9V77jJJFj for ; Mon, 13 Oct 2014 12:10:28 -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 EB03A1A1B6F for ; Mon, 13 Oct 2014 12:10:27 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 5A84313F97B for ; Mon, 13 Oct 2014 21:10:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1413227426; bh=UtMe+b66Q80FhP9VgFEHA3+Y0+riXbGcf3exWThRO38=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=X1woiDopfAEyI3qRVDpLIEJZZr4l3v606SNXbOwPA2HSbgyuudUW9F13dC3OSPSbQ JhZPM1PyOSrqPoeYQx3PiEA+QKjOygXeAyazBwJ2VoKTuvxAm0goS4NemJYl2BKs1X FGy9OnaiZOlfqduOgOHDJaz/E49i7+0aAD03VDwI= 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: Date: Mon, 13 Oct 2014 21:10:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <32028825-1432-4E8D-BFCD-1707B8A246F8@nic.cz> References: <543BF489.7000708@cisco.com> To: Netconf 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/pwQZqlgKiILwZSsFvZtzQcKd8OI Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 13 Oct 2014 19:10:29 -0000 On 13 Oct 2014, at 20:51, Kent Watsen wrote: >=20 > Bert,=20 >=20 > Thank you for pouring yourself into this working group and providing = the guidance that helped bring us to where we are now. Indeed. No question about rough consensus here. :-) Bert, dankjewel! Lada >=20 > Thanks again, > Kent >=20 >=20 > From: Benoit Claise > Date: Monday, October 13, 2014 at 11:49 AM > To: NetConf > Subject: [Netconf] Looking for a new NETCONF co-chair >=20 > Dear all, >=20 > I have to announce, with mixed feelings, that one of my mentors at the = IETF decided to retire. > On one hand, I'm pretty happy for Bert Wijnen to enjoy his well = deserved retirement. > On the hand, Bert will be missed, for sure. Not only as a leader, a = mentor, but also a friend. > Note that Bert will be attending his last IETF meeting in Honolulu. = This is your chance... >=20 > Practically, this implies that we are looking for a new NETCONF = co-chair. > Please let Joel and I know if you are interested. >=20 > Regards, Benoit >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Oct 13 12:17:16 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 722151A8A9C for ; Mon, 13 Oct 2014 12:17:14 -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 CBVe6gIUbgKZ for ; Mon, 13 Oct 2014 12:17:12 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744FE1A8A90 for ; Mon, 13 Oct 2014 12:17:12 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id c9so5423302qcz.8 for ; Mon, 13 Oct 2014 12:17:11 -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=AkXAhqxxBd2Lt9PTlAT+PXkurf8DCyed59h0F2VzVJo=; b=ppfW3mZ2DpogctriW5ceG9UodBPjb3xD3CzA3j5hfzuLCatobVRQ17utD3QxEPK6VK V1ep43SWdyt+b44vaa/o+xtTaxfQLAr5QdtTSrSI1Se3HlMaLoC56qYQ1Xy6yCxEnVxC 2UW1RzNe0b4qTM1L4cFSglcaHJICQKtdeUP6QvkaEKHD06PTGrHaC4u7L7UdHo3ImpQy QxFxMrf7saNHS/tNDTiKfdXP4tkbxBEStbTW1Ygat5Z5UIO3/2UBniYXocB5zYOy5QMb ZOsu5WtkYtSRtB2oioxFzjQWz6w5CRwQG61NYzf2kOswlEU/19G5/rbE7n7gGlluJ2mq wi9Q== MIME-Version: 1.0 X-Received: by 10.140.44.6 with SMTP id f6mr41602429qga.93.1413227831630; Mon, 13 Oct 2014 12:17:11 -0700 (PDT) Received: by 10.140.93.202 with HTTP; Mon, 13 Oct 2014 12:17:11 -0700 (PDT) In-Reply-To: References: <543BF489.7000708@cisco.com> Date: Mon, 13 Oct 2014 12:17:11 -0700 Message-ID: From: Mahesh Jethanandani To: Kent Watsen Content-Type: multipart/alternative; boundary=001a113a9cd0e42658050552bee9 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/E4NB5Kv_Z_w2WMc8zEE00Dt5EnE Cc: NETCONF Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 13 Oct 2014 19:17:14 -0000 --001a113a9cd0e42658050552bee9 Content-Type: text/plain; charset=UTF-8 Bert, Thank you for all your efforts. On Mon, Oct 13, 2014 at 11:51 AM, Kent Watsen wrote: > > Bert, > > Thank you for pouring yourself into this working group and providing the > guidance that helped bring us to where we are now. > > Thanks again, > Kent > > > From: Benoit Claise > Date: Monday, October 13, 2014 at 11:49 AM > To: NetConf > Subject: [Netconf] Looking for a new NETCONF co-chair > > Dear all, > > I have to announce, with mixed feelings, that one of my mentors at the > IETF decided to retire. > On one hand, I'm pretty happy for *Bert Wijnen* to enjoy his well > deserved retirement. > On the hand, Bert will be missed, for sure. Not only as a leader, a > mentor, but also a friend. > Note that Bert will be attending his last IETF meeting in Honolulu. This > is your chance... > > Practically, this implies that we are looking for a new NETCONF co-chair. > Please let Joel and I know if you are interested. > > Regards, Benoit > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > -- Mahesh Jethanandani mjethanandani@gmail.com --001a113a9cd0e42658050552bee9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bert,

Thank you for all your efforts.

On Mon,= Oct 13, 2014 at 11:51 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Bert,=C2=A0

Thank you for pouring yourself into = this working group and providing the guidance that helped bring us to where= we are now.

Thanks again,
Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Monday, October 13, 2014 at 1= 1:49 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf] Looking for a ne= w NETCONF co-chair

Dear all,

I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire.
On one hand, I'm pretty happy for Bert Wijnen to enjoy his well = deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance...

Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested.

Regards, Benoit

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




--
Mahesh Jethanandani
mjethanandani@gmail.com
--001a113a9cd0e42658050552bee9-- From nobody Mon Oct 13 12:44: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 31DF11A9034 for ; Mon, 13 Oct 2014 12:44:34 -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 WGZHzFYSFnZV for ; Mon, 13 Oct 2014 12:44:32 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D761A8A96 for ; Mon, 13 Oct 2014 12:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9134; q=dns/txt; s=iport; t=1413229473; x=1414439073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UWXoF9eMLYy9vuEDW4qFxKmIOps4SU6kaEFNxwy/CIo=; b=Yb3BKF2oINJFqPuA7WVNS1KKbSIef6u3FolL6w0jwal9/zCAUBt6jQeC uBjdVfMM43sCD35I7ohCRmtzk4Nm9Gnm8XEUCwOZf+7QgvrTIf2n9fJef DGZDafi8ozMs2U6pIrbPNsrUT8SVVSGuK9CNCKs8TonefrOI+MKVNO52s 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFABMrPFStJV2b/2dsb2JhbABbgkhGU1gEgwLIJQEJhnlUAhuBAxYBfYQCAQEBBAEBASAKQQsQAgEIEQMBAgsdAwICAh8GCxQJCAIEDgUIiCIDEQ2wCo4sDYYuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSOE4IBIA0EBgGCdzaBHgWReYlBgz+DRopJglaDfoN3bIFIgQIBAQE X-IronPort-AV: E=Sophos; i="5.04,712,1406592000"; d="scan'208,217"; a="86571472" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 13 Oct 2014 19:44:30 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9DJiTdU005527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Oct 2014 19:44:29 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 13 Oct 2014 14:44:29 -0500 From: "Alexander Clemm (alex)" To: "Bert Wijnen (IETF)" Thread-Topic: [Netconf] Looking for a new NETCONF co-chair Thread-Index: AQHP5v1cWgSiVrOqGUqGxoQBiTnJ1pwusyKAgAAHSID//7NLcA== Date: Mon, 13 Oct 2014 19:44:28 +0000 Message-ID: References: <543BF489.7000708@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.45] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571C819FFFxmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/P5OTWlx2vDxk2Tj_dvxmvBK5RWE Cc: NETCONF Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 13 Oct 2014 19:44:34 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571C819FFFxmbrcdx05ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQmVydCwNCg0KYmVzdCB3aXNoZXMgZm9yIHlvdXIgcmV0aXJlbWVudCENCg0KLS0tIEFs ZXgNCg0KRnJvbTogQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFp c2VAY2lzY28uY29tPj4NCkRhdGU6IE1vbmRheSwgT2N0b2JlciAxMywgMjAxNCBhdCAxMTo0OSBB TQ0KVG86IE5ldENvbmYgPG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogW05ldGNvbmZdIExvb2tpbmcgZm9yIGEgbmV3IE5FVENPTkYgY28tY2hhaXIN Cg0KRGVhciBhbGwsDQoNCkkgaGF2ZSB0byBhbm5vdW5jZSwgd2l0aCBtaXhlZCBmZWVsaW5ncywg dGhhdCBvbmUgb2YgbXkgbWVudG9ycyBhdCB0aGUgSUVURiBkZWNpZGVkIHRvIHJldGlyZS4NCk9u IG9uZSBoYW5kLCBJJ20gcHJldHR5IGhhcHB5IGZvciBCZXJ0IFdpam5lbiB0byBlbmpveSBoaXMg d2VsbCBkZXNlcnZlZCByZXRpcmVtZW50Lg0KT24gdGhlIGhhbmQsIEJlcnQgd2lsbCBiZSBtaXNz ZWQsIGZvciBzdXJlLiBOb3Qgb25seSBhcyBhIGxlYWRlciwgYSBtZW50b3IsIGJ1dCBhbHNvIGEg ZnJpZW5kLg0KTm90ZSB0aGF0IEJlcnQgd2lsbCBiZSBhdHRlbmRpbmcgaGlzIGxhc3QgSUVURiBt ZWV0aW5nIGluIEhvbm9sdWx1LiBUaGlzIGlzIHlvdXIgY2hhbmNlLi4uDQoNClByYWN0aWNhbGx5 LCB0aGlzIGltcGxpZXMgdGhhdCB3ZSBhcmUgbG9va2luZyBmb3IgYSBuZXcgTkVUQ09ORiBjby1j aGFpci4NClBsZWFzZSBsZXQgSm9lbCBhbmQgSSBrbm93IGlmIHlvdSBhcmUgaW50ZXJlc3RlZC4N Cg0KUmVnYXJkcywgQmVub2l0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1h aWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRjb25mDQoNCg0KDQotLQ0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFu aUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0K --_000_DBC595ED2346914F9F81D17DD5C32B571C819FFFxmbrcdx05ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBCZXJ0LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YmVz dCB3aXNoZXMgZm9yIHlvdXIgcmV0aXJlbWVudCEmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPkJlbm9pdCBDbGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+TW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0IGF0IDExOjQ5IEFNPGJyPg0KPGI+VG86IDwvYj5O ZXRDb25mICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bTmV0Y29u Zl0gTG9va2luZyBmb3IgYSBuZXcgTkVUQ09ORiBjby1jaGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkRlYXIgYWxsLDxicj4NCjxicj4NCkkgaGF2ZSB0byBhbm5vdW5jZSwgd2l0aCBt aXhlZCBmZWVsaW5ncywgdGhhdCBvbmUgb2YgbXkgbWVudG9ycyBhdCB0aGUgSUVURiBkZWNpZGVk IHRvIHJldGlyZS48YnI+DQpPbiBvbmUgaGFuZCwgSSdtIHByZXR0eSBoYXBweSBmb3IgPGI+QmVy dCBXaWpuZW48L2I+IHRvIGVuam95IGhpcyB3ZWxsIGRlc2VydmVkIHJldGlyZW1lbnQuPGJyPg0K T24gdGhlIGhhbmQsIEJlcnQgd2lsbCBiZSBtaXNzZWQsIGZvciBzdXJlLiBOb3Qgb25seSBhcyBh IGxlYWRlciwgYSBtZW50b3IsIGJ1dCBhbHNvIGEgZnJpZW5kLjxicj4NCk5vdGUgdGhhdCBCZXJ0 IHdpbGwgYmUgYXR0ZW5kaW5nIGhpcyBsYXN0IElFVEYgbWVldGluZyBpbiBIb25vbHVsdS4gVGhp cyBpcyB5b3VyIGNoYW5jZS4uLjxicj4NCjxicj4NClByYWN0aWNhbGx5LCB0aGlzIGltcGxpZXMg dGhhdCB3ZSBhcmUgbG9va2luZyBmb3IgYSBuZXcgTkVUQ09ORiBjby1jaGFpci48YnI+DQpQbGVh c2UgbGV0IEpvZWwgYW5kIEkga25vdyBpZiB5b3UgYXJlIGludGVyZXN0ZWQuPGJyPg0KPGJyPg0K UmVnYXJkcywgQmVub2l0PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DBC595ED2346914F9F81D17DD5C32B571C819FFFxmbrcdx05ciscoc_-- From nobody Mon Oct 13 13:33: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 6C6721A001E for ; Mon, 13 Oct 2014 13:33:28 -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 sUVG2pEwbErq for ; Mon, 13 Oct 2014 13:33:25 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id A81F91A0070 for ; Mon, 13 Oct 2014 13:33:24 -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 QAA13150; Mon, 13 Oct 2014 16:33:17 -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 s9DKdc3n006027; Mon, 13 Oct 2014 16:39:38 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id s9DKdbCn006026; Mon, 13 Oct 2014 16:39:37 -0400 (EDT) (envelope-from luchuk) Date: Mon, 13 Oct 2014 16:39:37 -0400 (EDT) From: Alan Luchuk Message-Id: <201410132039.s9DKdbCn006026@mainfs.snmp.com> To: , , , "jshoenwaelder@jacobs-university.de" In-Reply-To: Your message of Fri, 3 Oct 2014 19:02:51 +0000 References: <201409302145.s8ULjq7q024177@mainfs.snmp.com> X-Mailer: mail (GNU Mailutils 2.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/OS5ziJ_UcIbxLuvAQXUlP8N_A8c 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 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:33:28 -0000 Hello, Thanks for considering, and replying to, my comments on draft-ietf- netconf-server-model-03.txt. For most of the issues raised, I have no strong opinion about what the "correct" answers are, and can align with WG consensus. I attempted to give closer attention to the schema nodes related to NETCONF over TLS. Just after pressing "send" for my comments, I realized I failed to suggest the schema nodes related to NETCONF over TLS using pre-shared keys should be removed to match the text of draft-ietf-netconf-rfc5539bis-06.txt. This includes the removal of the "feature tls-map-pre-shared-keys", the "grouping psk-maps-grouping", and the single "uses psk-maps-grouping". That said, here are replies to Juergen's and Kent's replies. On Wed, Oct 1, 2014 at 08:34:56 +0200, Juergen Schoenwaelder 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 I looked this document over, and did a bit more reading about VRFs. I'm not well-versed on the related issues, so I'll defer to Juergen on this. >Thank you for a fantastic review. I have already incorporated all >your Nit comments. Please see below for other responses. > >Thanks again, >Kent > > > >>>Comments on the listen-per-transport-config grouping, Page 12: >>-------------------------------------------------------------- >> > >>Under the port leaf: >> >> Should this leaf be mandatory, or have a default of 0? > >In both places where this grouping is used, a transport-specific default >is provided (830 for SSH, 6513 for TLS). Is it good enough? This answer is fine. The only problem that _might_ arise is if the listen-per-transport-config grouping is used again in the future, and the necessary port refinement is forgotten. In this case, the port would be underspecified, and presumably be implementation-dependent, no? >>Comments on the call-home-per-transport-config grouping, Page 14: >>----------------------------------------------------------------- > >>I _suspect_ I know the answer to this, but what is the purpose of the >>"endpoints" container around the "endpoint" list? > >I thought that it was best practice to always have a parent container for >a list. In RESTCONF terms, the container would be the "collection" and >would render URLs like .../widgets/widget=/, which is a pretty common >idiom. That said, the module is itself inconsistent in that the top-level >"listen" and "call-home" do NOT have parent containers. The module is >trying to follow guildlines set by >http://tools.ietf.org/html/draft-schoenw-netmod-yang-pattern-00. One >option might be use this: OK, thanks for the explanation. > > +--rw netconf-server > +--rw listen > | +--rw endpoint* [name] > | +--rw name string > | ... > +--rw call-home > +--rw application* [name] > +--rw name string > | ... > > >What do you think, is it better? This arrangement of the schema nodes seems clearer, but that doesn't mean it is clearer :-) Deferring to WG consensus is a good plan. >>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. > >As Juergen mentioned already, this would prevent augmentations from >supporting multiple routing instances (VRFs) if needed. OK. Others understand the issues better than I do, so I can align with the WG consensus. > > >>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? > >This is me just grouping things together for readability and >extensibility. We could flatten the model some by having >"keep-alive-interval-secs" and "keep-alive-count-max" - does that seem >bester to you? Also, while the model doesn't currently have any other >nodes under the "persistent" node, it may someday (perhaps through an >augmentation), such that having this structure helps keeps things nice and >organized. Thoughts? Leave the schema as it is. This explanation is reasonable, and the suggested simplification(s) are not sufficient to justify a change. > > > >>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? > >No order is expected, a device could even connect to all it's "call-home" >nodes in parallel. The draft defines the "call-home" list as unordered - >is it good enough? - if not, what text would you suggest adding? > >The draft says in the description statement: "If no previous connection >has ever been established, last-connected defaults to the first endpoint >listed". What the draft fails to say is if the "previous connection" >information needs to survive reboots. Do you think this choice could be >left to implementations? That sounds fine, but perhaps something along following line should be added to the description clause for the last-connected enum: "If a NETCONF server does not have non-volatile memory to store the last-connected endpoint across reboots, then upon reboot, the NETCONF server chooses an reconnect transport endpoint in an implementation-dependent manner." > > > >>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? > > > >AFAIK, there is no known intension to use the grouping elsewhere. That >said, you never know and, besides, I like to use groupings because I think >it improves readability (YMMV). > >Yes, absolutely, subordinate certs are allowed. > >That said, there may still be an issue with supporting chains, such as >when a client cert is signed by an intermediate CA that is signed by trust >anchor CA. That is, the end user would like to configure the device to >auth any client cert having a chain of trust leading to the trust anchor. >Currently this is not possible because the wording "A client's certificate >is authenticated if its Issuer matches one of the configured trusted CA >certificates." does allow for indirections. This seems like an >oversight to me, but I inherited this text and don't know if there is a >reason behind it. > >Added https://github.com/netconf-wg/server-model/issues/13 to track this. OK, I think this should be fixed. I'll look at it a bit more. > > > >>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? > >This grouping is provides an alternate mechanism to authenticate client >certs. It is to auth a specific user without authenticating every other >user's cert having the same Issuer. This came from issue #3 in this >thread: >http://www.ietf.org/mail-archive/web/netconf/current/msg08825.html. Makes >sense? OK. So basically, if a specific X.509 cert is stored in the trusted-client-cert list, then when a connecting NETCONF client presents that X.509 cert to the NETCONF server, the NETCONF server authorizes it. The mere presence of an X.509 cert in the trusted-client-cert list authorizes it when that cert is presented by a NETCONF client. > > > >>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? > >Yes, and this issue is tracked here: >https://github.com/netconf-wg/server-model/issues/4 > >Question, do you think configuring the TLS-server-cert/SSH-host-key to use >should be a system-wide configuration, or something specific to the >NETCONF server? System-wide configuration seems simpler. Something specific to the NETCONF server would allow multiple instances of a NETCONF server on a single system, and thus seems more flexible. 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 Mon Oct 13 18:08: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 3DC501A1A76 for ; Mon, 13 Oct 2014 18:08:16 -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, 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 g_FyPGboI3sl for ; Mon, 13 Oct 2014 18:08:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::764]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414731A1A72 for ; Mon, 13 Oct 2014 18:08:03 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB518.namprd05.prod.outlook.com (10.141.65.143) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 01:07:40 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 01:07:38 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.226]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.226]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 01:07:38 +0000 From: Dean Bogdanovic To: "Bert Wijnen (IETF)" Thread-Topic: [Netconf] Looking for a new NETCONF co-chair Thread-Index: AQHP5v1YMHVg1TmTC0mairQCHinp05wuX1CAgAAHSICAAAegAIAAWkmA Date: Tue, 14 Oct 2014 01:07:38 +0000 Message-ID: References: <543BF489.7000708@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(24454002)(199003)(2656002)(99396003)(19580395003)(19580405001)(4396001)(16236675004)(57306001)(87936001)(120916001)(122556002)(64706001)(87286001)(15975445006)(50226001)(89996001)(85852003)(66066001)(21056001)(88136002)(104166001)(106116001)(101416001)(105586002)(36756003)(50986999)(46102003)(106356001)(97736003)(92726001)(80022003)(20776003)(99286002)(107046002)(76482002)(93916002)(62966002)(86362001)(77156001)(95666004)(85306004)(76176999)(110136001)(19617315012)(92566001)(93886004)(31966008)(40100003)(77096002)(33656002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_FA4FCBEC1E3F405F8D14C5940B7F4C8Ajunipernet_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB518; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/k-ncXrClIu9bO6I4l--Pfagk4Zg Cc: NETCONF Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 14 Oct 2014 01:08:17 -0000 --_000_FA4FCBEC1E3F405F8D14C5940B7F4C8Ajunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bert, I'll raise a toast to your retirement and best wishes to you. Dean On Oct 13, 2014, at 3:44 PM, Alexander Clemm (alex) > wrote: Hello Bert, best wishes for your retirement! --- Alex From: Benoit Claise > Date: Monday, October 13, 2014 at 11:49 AM To: NetConf > Subject: [Netconf] Looking for a new NETCONF co-chair Dear all, I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire. On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved re= tirement. On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend. Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance... Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested. Regards, Benoit _______________________________________________ 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 --_000_FA4FCBEC1E3F405F8D14C5940B7F4C8Ajunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Bert,

I'll raise a toast to your retirement and best wishes to you.

Dean

On Oct 13, 2014, at 3:44 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:

Hello Bert,
 
best wishes for your retirement! <= /div>
 
--- Alex
 = ;
From= : Benoit Claise <= bclaise@cisco.com>
Date: Monday, Octo= ber 13, 2014 at 11:49 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf]= Looking for a new NETCONF co-chair
 = ;

Dear = all,

I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire.
On one hand, I'm pretty happy for&nbs= p;Bert Wijnen to enjoy his well deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance...

Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested.

Regards, Benoit


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



 
--
Mahesh Jethanandani
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/= netconf

--_000_FA4FCBEC1E3F405F8D14C5940B7F4C8Ajunipernet_-- From nobody Tue Oct 14 04:53: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 179581A8718 for ; Tue, 14 Oct 2014 04:53:23 -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 fFa6-VnKBpaz for ; Tue, 14 Oct 2014 04:53:21 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::760]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8AD1A00C6 for ; Tue, 14 Oct 2014 04:53:20 -0700 (PDT) Received: from pc6 (86.184.62.161) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 11:52:57 +0000 Message-ID: <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Martin Bjorklund References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> <20141010.212225.300681995.mbj@tail-f.com> Date: Tue, 14 Oct 2014 10:11:27 +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.62.161] X-ClientProxiedBy: DB3PR05CA0018.eurprd05.prod.outlook.com (25.160.41.146) 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-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 03648EFF89 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(51444003)(199003)(77096002)(33646002)(106356001)(120916001)(44736004)(4396001)(50226001)(87286001)(62966002)(21056001)(105586002)(99396003)(14496001)(104166001)(107046002)(61296003)(95666004)(42186005)(93916002)(86362001)(87976001)(92566001)(92726001)(31966008)(97736003)(76176999)(89996001)(50986999)(81686999)(76482002)(85852003)(81816999)(20776003)(47776003)(116806002)(85306004)(93886004)(64706001)(66066001)(50466002)(44716002)(1941001)(101416001)(230783001)(122386002)(23756003)(84392001)(46102003)(40100003)(80022003)(88136002)(62236002)(77156001)(19580395003)(19580405001)(74416001)(7059027)(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/Lv0z7DiNCxE_SMuQfiCgp-0mlAQ Cc: netconf@ietf.org Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 14 Oct 2014 11:53:23 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Martin Bjorklund" Cc: ; Sent: Friday, October 10, 2014 9:03 PM >Hmm, so why does 5539bis talk about one auth mechanism but not the >other? There is a sequencing issue, the server-model update came out before the PSK info was removed from 5539bis. If the intent is to remove support for PSK, then the next update to server-model will remove it too. Which is the question I think we need to resolve first, after which updates to the I-Ds will follow. In a way it is unfortunate that RFC6241 says "NETCONF connections MUST provide authentication, data integrity, confidentiality, and replay protection. " and " The authentication process MUST result in an authenticated client identity whose permissions are known to the server." because that then means, to me, that rfc5539bis is obliged to say how, and make it mandatory. We could, simplistically, say that that means TLS client and server certificates are mandatory, other options are for further study; or else I think we have quite a bit of discussion, perhaps starting with PSK. I think that here, we are going against the grain, in that TLS is (almost) all about server authentication by certificate, and the issues are which algorithms to use, and other forms of authentication, let alone a prescribed method of client authentication (as opposed to an application's RYO), get little attention. Whatever, we have to solve this in order to progress this set of I-Ds. Tom Petch Kent From nobody Tue Oct 14 04:53: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 8C1531A00C6 for ; Tue, 14 Oct 2014 04:53:23 -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 RYrFWtezGNXO for ; Tue, 14 Oct 2014 04:53:21 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::760]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A8B1A8716 for ; Tue, 14 Oct 2014 04:53:21 -0700 (PDT) Received: from pc6 (86.184.62.161) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 11:52:58 +0000 Message-ID: <061901cfe7a5$1a222860$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , References: <20141010214448.15637.19105.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 12:47:44 +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.62.161] X-ClientProxiedBy: DB3PR05CA0018.eurprd05.prod.outlook.com (25.160.41.146) 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: 03648EFF89 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(13464003)(51704005)(479174003)(377454003)(377424004)(164054003)(51914003)(199003)(77096002)(33646002)(106356001)(120916001)(44736004)(4396001)(50226001)(87286001)(62966002)(21056001)(105586002)(99396003)(14496001)(104166001)(107046002)(107886001)(61296003)(95666004)(42186005)(93916002)(86362001)(87976001)(92566001)(92726001)(31966008)(97736003)(76176999)(89996001)(50986999)(81686999)(76482002)(85852003)(81816999)(20776003)(47776003)(116806002)(85306004)(64706001)(66066001)(50466002)(44716002)(1941001)(101416001)(230783001)(122386002)(23756003)(84392001)(15975445006)(46102003)(40100003)(80022003)(88136002)(62236002)(77156001)(15202345003)(19580395003)(19580405001)(74416001)(7059027)(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/dygzp1sPzUFfV-d4Hg-bSCrI2mc Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-01.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, 14 Oct 2014 11:53:23 -0000 Kent Thanks for the prompt update, and also for undertaking the work - I do think that this is the best document structure, within which to iron out the wrinkles. Talking of which, I find it hard to comment on the new Section 3.2 until we have fixed the issue in rfc5539bis, namely what forms of authentication are we covering with TLS. The SSH side seems stable, the TLS not. We could require TLS client and server X.509 certificates which would be simplest; I am unsure whether that would be acceptable or not. In passing, I note that the new RFC Editor Style Guide recommends the use of TBD1 and TBD2, and not XXXX and YYYY - I think this is silly and so would go on using XXXX and YYYY (and ZZZZ) Tom Petch ---- Original Message ----- From: "Kent Watsen" To: Sent: Friday, October 10, 2014 10:47 PM > > This update addresses all of Tom's comments. Specifically: > > * The term "TCP connection" is now used throughout. > > * The terms "network element" and "management system" are now only > used in the Motivation section. > > * Restructured doc a little to create an Introduction section. > > * Fixed reference in Applicability Statement so it would work > equally well for SSH and TLS. > > * Fixed reported odd wording and three references. > > > Thanks, > Kent > > > On 10/10/14, 5:44 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 Call Home > > Author : Kent Watsen > > Filename : draft-ietf-netconf-call-home-01.txt > > Pages : 10 > > Date : 2014-10-10 > > > >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-01 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-01 > > > > > >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 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Oct 14 05: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 5C82E1A8749 for ; Tue, 14 Oct 2014 05:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJjy0_5ZUb9q for ; Tue, 14 Oct 2014 05:13:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA72C1A873F for ; Tue, 14 Oct 2014 05:13:57 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9ECDrKP016938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Oct 2014 12:13:53 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9ECDq68013497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 14:13:53 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 14:13:52 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: NETCONF , ext Benoit Claise Thread-Topic: [Netconf] Looking for a new NETCONF co-chair Thread-Index: AQHP5v1ZAc4HZoI9A0ekZv6BsChgKZwuHEEAgAAo0ICAAAegAIAAWkoAgADbFnA= Date: Tue, 14 Oct 2014 12:13:52 +0000 Message-ID: References: <543BF489.7000708@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819510F56DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 38237 X-purgate-ID: 151667::1413288833-0000437E-42C418F0/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/69vmGIvgrH60J0jZYjUY75HWmc4 Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 14 Oct 2014 12:14:02 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819510F56DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, All, > Not only as a leader, a mentor, but also a friend. I would like to underline these words, but they are not sufficient. More than you guys I will miss Bert. I really enjoyed the last 6.5 years wi= th Bert as my co-chair. Let's use the time in Honolulu for a nice and appropriate farewell. Cheers, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Dean Bogda= novic Sent: Tuesday, October 14, 2014 3:08 AM To: Bert Wijnen (IETF) Cc: NETCONF Subject: Re: [Netconf] Looking for a new NETCONF co-chair Bert, I'll raise a toast to your retirement and best wishes to you. Dean On Oct 13, 2014, at 3:44 PM, Alexander Clemm (alex) > wrote: Hello Bert, best wishes for your retirement! --- Alex From: Benoit Claise > Date: Monday, October 13, 2014 at 11:49 AM To: NetConf > Subject: [Netconf] Looking for a new NETCONF co-chair Dear all, I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire. On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved re= tirement. On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend. Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance... Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested. Regards, Benoit _______________________________________________ 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 --_000_E4DE949E6CE3E34993A2FF8AE79131F819510F56DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit, All,=

 

> Not only as= a leader, a mentor, but also a friend.

I would like to underline = these words, but they are not sufficient.

More than you guys I will = miss Bert. I really enjoyed the last 6.5 years with Bert as my co-chair.

 

Let’s use the time i= n Honolulu for a nice and appropriate farewell.

 

Cheers,
Mehmet

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Dean Bogdanovic<= br> Sent: Tuesday, October 14, 2014 3:08 AM
To: Bert Wijnen (IETF)
Cc: NETCONF
Subject: Re: [Netconf] Looking for a new NETCONF co-chair=

 

Bert,

 

I'll raise a toast to your retirement and best wishes to yo= u.

 

Dean

 

On Oct 13, 2014, at 3:44 PM, Alexander Clemm (alex) <alex@cisco.com> wrote:



Hello Bert,

 

best wishes for your retirement! 

 

--- Alex

 

From: Benoit Claise <bclaise@cisco.com>
Date: Monday, Octo= ber 13, 2014 at 11:49 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf]= Looking for a new NETCONF co-chair

 

Dear all= ,

I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire.
On one hand, I'm pretty happy for&nbs= p;Bert Wijnen to enjoy his well deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance...

Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested.

Regards, Benoit



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



 

--

Mahesh Jethanandani

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

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819510F56DEMUMBX005nsnin_-- From nobody Tue Oct 14 05:23:56 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 AD99C1A8771 for ; Tue, 14 Oct 2014 05:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 pczZffXQKM_o for ; Tue, 14 Oct 2014 05:23:48 -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 294C61A875B for ; Tue, 14 Oct 2014 05:23:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoLADsVPVSHCzIm/2dsb2JhbABbgkgjI1NYBLhsBpMVHQEJhnlUAoEVFgEBfIQCAQEBAQIBAQEBDxtBEAsCAQgNBAMBAQELHQchBgsUCQgCBAESCBqICAMJCAEMpimZJw2GLgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhiCHc4IBIA0KAYI2UySBHgWReYlAAYM/g0aDG4cuglaDfoN3bIFIgQIBAQE X-IronPort-AV: E=Sophos; i="5.04,717,1406606400"; d="scan'208,217"; a="89668860" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Oct 2014 08:23:29 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 14 Oct 2014 08:23:28 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 14:23:27 +0200 From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , NETCONF , ext Benoit Claise Thread-Topic: [Netconf] Looking for a new NETCONF co-chair Thread-Index: AQHP5v1ZAc4HZoI9A0ekZv6BsChgKZwuHEEAgAAo0ICAAAegAIAAWkoAgADbFnCAAAKx4A== Date: Tue, 14 Oct 2014 12:23:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8CB68B@AZ-FFEXMB04.global.avaya.com> References: <543BF489.7000708@cisco.com> 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_9904FB1B0159DA42B0B887B7FA8119CA5C8CB68BAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/uUr6kxOSKpxU9PL1ddTVgz4tT7I Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 14 Oct 2014 12:23:51 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB68BAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bert's huge contributions in NETCONF and network management in general dese= rve a BIG party! Thanks, Bert! Dan From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN - DE/Munich) Sent: Tuesday, October 14, 2014 3:14 PM To: NETCONF; ext Benoit Claise Subject: Re: [Netconf] Looking for a new NETCONF co-chair Hi Benoit, All, > Not only as a leader, a mentor, but also a friend. I would like to underline these words, but they are not sufficient. More than you guys I will miss Bert. I really enjoyed the last 6.5 years wi= th Bert as my co-chair. Let's use the time in Honolulu for a nice and appropriate farewell. Cheers, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Dean Bogda= novic Sent: Tuesday, October 14, 2014 3:08 AM To: Bert Wijnen (IETF) Cc: NETCONF Subject: Re: [Netconf] Looking for a new NETCONF co-chair Bert, I'll raise a toast to your retirement and best wishes to you. Dean On Oct 13, 2014, at 3:44 PM, Alexander Clemm (alex) > wrote: Hello Bert, best wishes for your retirement! --- Alex From: Benoit Claise > Date: Monday, October 13, 2014 at 11:49 AM To: NetConf > Subject: [Netconf] Looking for a new NETCONF co-chair Dear all, I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire. On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved re= tirement. On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend. Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance... Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested. Regards, Benoit _______________________________________________ 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 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB68BAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bert’s huge contrib= utions in NETCONF and network management in general deserve a BIG party!

 <= /p>

Thanks, Bert!<= /span>

 <= /p>

Dan

 <= /p>

 <= /p>

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Tuesday, October 14, 2014 3:14 PM
To: NETCONF; ext Benoit Claise
Subject: Re: [Netconf] Looking for a new NETCONF co-chair=

 

Hi Benoit, All,=

 

> Not only as a = leader, a mentor, but also a friend.

I would like to underline = these words, but they are not sufficient.

More than you guys I will = miss Bert. I really enjoyed the last 6.5 years with Bert as my co-chair.

 

Let’s use the time i= n Honolulu for a nice and appropriate farewell.

 

Cheers= ,
Mehmet

 

From: Netconf = [mailto:netconf-bounces@ietf.or= g] On Behalf Of ext Dean Bogdanovic
Sent: Tuesday, October 14, 2014 3:08 AM
To: Bert Wijnen (IETF)
Cc: NETCONF
Subject: Re: [Netconf] Looking for a new NETCONF co-chair=

 

Bert,

 

I'll raise a toast to your retirement and best wishe= s to you.

 

Dean

 

On Oct 13, 2014, at 3:44 PM, Alexander Clemm (alex) = <alex@cisco.com> wrote:



Hello Bert,

 <= /p>

best wishes for your reti= rement! 

 <= /p>

--- Alex

 

From: Benoit Claise <bcla= ise@cisco.com>
Date: Monday, Octo= ber 13, 2014 at 11:49 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf]= Looking for a new NETCONF co-chair

 

Dear all= ,

I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire.
On one hand, I'm pretty happy for&nbs= p;Bert Wijnen to enjoy his well deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance...

Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested.

Regards, Benoit



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



 

--

Mahesh Jethanandani

_____________________________________= __________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C8CB68BAZFFEXMB04globa_-- From nobody Tue Oct 14 06:09: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 E69BC1A87EB for ; Tue, 14 Oct 2014 06:09:09 -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 BtAKvpvyA-pL for ; Tue, 14 Oct 2014 06:09:06 -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 11AE51A87EE for ; Tue, 14 Oct 2014 06:09: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 9782CA45; Tue, 14 Oct 2014 15:09: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 yLu1HHqKtnHv; Tue, 14 Oct 2014 15:09: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; Tue, 14 Oct 2014 15:09:03 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B5DD20035; Tue, 14 Oct 2014 15:09:03 +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 o-l6-ReWSLFt; Tue, 14 Oct 2014 15:09: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 92E7520037; Tue, 14 Oct 2014 15:09:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1A3562EF6648; Tue, 14 Oct 2014 15:09:00 +0200 (CEST) Date: Tue, 14 Oct 2014 15:09:00 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20141014130900.GA70425@elstar.local> Mail-Followup-To: "t. petch" , netconf@ietf.org References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> <20141010.212225.300681995.mbj@tail-f.com> <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bcrqoFN_fw9HVMOcc9ZmlT0Ph1o Cc: netconf@ietf.org Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 14 Oct 2014 13:09:10 -0000 On Tue, Oct 14, 2014 at 10:11:27AM +0100, t. petch wrote: > > I think that here, we are going against the grain, in that TLS is > (almost) all about server authentication by certificate, and the issues > are which algorithms to use, and other forms of authentication, let > alone a prescribed method of client authentication (as opposed to an > application's RYO), get little attention. > RFC 5539 says both ends use a certificate. I assume this is the default unless someone makes a clear proposal otherwise. Are you making such a proposal? If not, lets go ahead with both ends use a certificate. I was pushing for PSK authentication back in a day when we did NC light. I think it is meanwhile clear that NC light is not a viable option and hence I proposed to remove PSK authentication at the Toronto meeting as not many people seem to care to implement this (slide #7 of my slide set). Perhaps the chairs should do an explicit call for concensus on this so that we can move on. /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 Oct 14 06:11: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 7A5FC1A87F2 for ; Tue, 14 Oct 2014 06:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 i_st_PQ98tNa for ; Tue, 14 Oct 2014 06:11:37 -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 42ECC1A87D9 for ; Tue, 14 Oct 2014 06:11:37 -0700 (PDT) Received: from [147.229.12.223] (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 D1331ECB1DF; Tue, 14 Oct 2014 15:11:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1413292294; bh=ia71wbapPFAE/xjtow/+GhUDr3u1z1k25B5KN4Ggqrw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=rjJRr7CU7yxll4UtEssgGhVXDzVF9Ffr7Yi4L8MppxQU6Es/fc6wWVtz5/N2I+1qn eubBOBg4RbhsQF9a2GfJOWnc3EfcAvteyRcK+5k8Mo781UMqPh1APZyfwNrGLWdXB6 nl1F3hP4eLaSYmzIyCLuPdHg7ETNP3gZwrJ46zJU= Message-ID: <543D1FA3.4070607@cesnet.cz> Date: Tue, 14 Oct 2014 15:05:39 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <543BF489.7000708@cisco.com> In-Reply-To: <543BF489.7000708@cisco.com> Content-Type: multipart/alternative; boundary="------------030304020107050705090602" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1oeJaD3GiQIY7VBrECdAYZoe_xA Cc: NETCONF Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 14 Oct 2014 13:11:40 -0000 This is a multi-part message in MIME format. --------------030304020107050705090602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Bert, all the best to your retirement. I'm looking forward to meeting you again in Honolulu. Radek Dne 13.10.2014 v 17:49 Benoit Claise napsal(a): > Dear all, > > I have to announce, with mixed feelings, that one of my mentors at the > IETF decided to retire. > On one hand, I'm pretty happy for *Bert Wijnen* to enjoy his well > deserved retirement. > On the hand, Bert will be missed, for sure. Not only as a leader, a > mentor, but also a friend. > Note that Bert will be attending his last IETF meeting in Honolulu. > This is your chance... > > Practically, this implies that we are looking for a new NETCONF co-chair. > Please let Joel and I know if you are interested. > > Regards, Benoit > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------030304020107050705090602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Bert,

all the best to your retirement. I'm looking forward to meeting you again in Honolulu.

Radek


Dne 13.10.2014 v 17:49 Benoit Claise napsal(a):
Dear all,

I have to announce, with mixed feelings, that one of my mentors at the IETF decided to retire.
On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor, but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is your chance...

Practically, this implies that we are looking for a new NETCONF co-chair.
Please let Joel and I know if you are interested.

Regards, Benoit




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

--------------030304020107050705090602-- From nobody Tue Oct 14 06:15: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 DDFAB1A87E1 for ; Tue, 14 Oct 2014 06:15:36 -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 1ZYVs2HyqM8H for ; Tue, 14 Oct 2014 06:15:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 549D21A877A for ; Tue, 14 Oct 2014 06:15:35 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 872371280098; Tue, 14 Oct 2014 15:15:34 +0200 (CEST) Date: Tue, 14 Oct 2014 15:15:34 +0200 (CEST) Message-Id: <20141014.151534.2215345713407265939.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20141014130900.GA70425@elstar.local> References: <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> <20141014130900.GA70425@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/--Orw38nbXyU88YEnvO3RB5SGwM Cc: netconf@ietf.org Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 14 Oct 2014 13:15:37 -0000 Juergen Schoenwaelder wrote: > On Tue, Oct 14, 2014 at 10:11:27AM +0100, t. petch wrote: > > > > I think that here, we are going against the grain, in that TLS is > > (almost) all about server authentication by certificate, and the issues > > are which algorithms to use, and other forms of authentication, let > > alone a prescribed method of client authentication (as opposed to an > > application's RYO), get little attention. > > > > RFC 5539 says both ends use a certificate. I assume this is the > default unless someone makes a clear proposal otherwise. Are you > making such a proposal? If not, lets go ahead with both ends use a > certificate. Do you want to say certificate-based auth is a MUST? This seems to imply that if someone someday wants to do PSK, that won't be possible. The alternative is to define certificate-based auth as the only current option, but open the spec for other auth mechanisms. (this is almost how the doc is written today...) /martin > > I was pushing for PSK authentication back in a day when we did NC > light. I think it is meanwhile clear that NC light is not a viable > option and hence I proposed to remove PSK authentication at the > Toronto meeting as not many people seem to care to implement this > (slide #7 of my slide set). Perhaps the chairs should do an explicit > call for concensus on this so that we can move on. > > /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 Tue Oct 14 06:27: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 7DAA21A8848 for ; Tue, 14 Oct 2014 06:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DzxjhQfeyB4s for ; Tue, 14 Oct 2014 06:27:39 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A45D1A8737 for ; Tue, 14 Oct 2014 06:27:39 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-93-543d24c8437d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.49.21334.8C42D345; Tue, 14 Oct 2014 15:27:37 +0200 (CEST) Received: from [159.107.198.88] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.174.1; Tue, 14 Oct 2014 15:27:36 +0200 Message-ID: <543D24C8.7040301@ericsson.com> Date: Tue, 14 Oct 2014 15:27:36 +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: Ladislav Lhotka , Netconf , "ext Bert (IETF) Wijnen" References: <543BF489.7000708@cisco.com> <32028825-1432-4E8D-BFCD-1707B8A246F8@nic.cz> In-Reply-To: <32028825-1432-4E8D-BFCD-1707B8A246F8@nic.cz> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvje5JFdsQgzl7ZCw6Ol6xWVxYNZfN Yuqm26wOzB63rj9i8Viy5CeTx6bLdxgDmKO4bFJSczLLUov07RK4Mi7Pf8VS0MFXcfZQE3sD YwN3FyMnh4SAiUTTwRusELaYxIV769lAbCGBo4wSXzdUdjFyAdlrGCWuLm1h6WLk4OAV0JaY /IERpIZFQFXiQss+dhCbTcBIYmr/eRYQW1QgSuLOpX6wmbwCghInZz4Bi4sIFEnsf7sSbL6w gKXE3Rc/GSF2VUvMfzuTCcTmFLCSmD7nMTOIzSxgK3FhznUWCFteYvvbOcwQ9RoSDy/8ZZ3A KDALyYpZSFpmIWlZwMi8ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwUA9u+a27g3H1a8dD jAIcjEo8vAuabUKEWBPLiitzDzFKc7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAPjuuyMkteWJRwMD55Kn4tvtFMu3OScved/RJKPyZ3j8ovPsv9MZUlK2iepq+o76aDN5IJH bYceG9opPtwkH8q6qc7WZlVFBku7sNrRAzxecxsnqG/fdaV9o/ZCa6bdzem3b+k7yLBUTV3k GXn6DO/i7xX7PzQLJGl7L3KaXCX7KGCjwdNN/rOVWIozEg21mIuKEwE5PYyjNQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HvE9yLJkXdo_xvwhO6J13XM6uHM Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 14 Oct 2014 13:27:41 -0000 Bert, Thanks for the all help and the friendly attitude. Balazs On 2014-10-13 21:10, Ladislav Lhotka wrote: > On 13 Oct 2014, at 20:51, Kent Watsen wrote: > >> Bert, >> >> Thank you for pouring yourself into this working group and providing the guidance that helped bring us to where we are now. > Indeed. No question about rough consensus here. :-) > > Bert, dankjewel! > > Lada > >> Thanks again, >> Kent >> >> >> From: Benoit Claise >> Date: Monday, October 13, 2014 at 11:49 AM >> To: NetConf >> Subject: [Netconf] Looking for a new NETCONF co-chair >> >> Dear all, >> >> I have to announce, with mixed feelings, that one of my mentors at the IETF decided to retire. >> On one hand, I'm pretty happy for Bert Wijnen to enjoy his well deserved retirement. >> On the hand, Bert will be missed, for sure. Not only as a leader, a mentor, but also a friend. >> Note that Bert will be attending his last IETF meeting in Honolulu. This is your chance... >> >> Practically, this implies that we are looking for a new NETCONF co-chair. >> Please let Joel and I know if you are interested. >> >> Regards, Benoit >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- 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 Oct 14 06:46: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 0E7C91A878B for ; Tue, 14 Oct 2014 06:46:04 -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 1BShbUjk6ipN for ; Tue, 14 Oct 2014 06:46: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 A9C091A8779 for ; Tue, 14 Oct 2014 06:46: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 1Xe2QH-0004Ox-TV; Tue, 14 Oct 2014 15:45:59 +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 1Xe2QH-0002BJ-O6; Tue, 14 Oct 2014 15:45:57 +0200 Message-ID: <543D2914.8060805@bwijnen.net> Date: Tue, 14 Oct 2014 15:45:56 +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: Juergen Schoenwaelder , netconf@ietf.org References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> <20141010.212225.300681995.mbj@tail-f.com> <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> <20141014130900.GA70425@elstar.local> In-Reply-To: <20141014130900.GA70425@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: 86ab03e524994f79ca2c75a176445dd47f48741ef5a1b89db6b9a11199917143 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/w4IaiwmzTHxro7qLIC85vRjid9g Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 14 Oct 2014 13:46:04 -0000 Juergen, do we have an open issue on an issues list somewhere that we can point to? - it should describe the issue - a proposed solution We can then do a consensus call for the proposed solution Maybe this is somewhere already in my email archives or in meeting notes, but it would be good to have it listed as an issue that we can easily point to. Thanks, Bert On 14/10/14 15:09, Juergen Schoenwaelder wrote: > I was pushing for PSK authentication back in a day when we did NC > light. I think it is meanwhile clear that NC light is not a viable > option and hence I proposed to remove PSK authentication at the > Toronto meeting as not many people seem to care to implement this > (slide #7 of my slide set). Perhaps the chairs should do an explicit > call for concensus on this so that we can move on. From nobody Tue Oct 14 11:47: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 4EA6A1ACDBF for ; Tue, 14 Oct 2014 11:47:43 -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 G5AlTZo1jQGg for ; Tue, 14 Oct 2014 11:47:38 -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 2C28A1ACDCB for ; Tue, 14 Oct 2014 11:47:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 496BE75C; Tue, 14 Oct 2014 20:47:25 +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 YNf2YuxLFe_q; Tue, 14 Oct 2014 20:47:23 +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, 14 Oct 2014 20:47:24 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B3FA20036; Tue, 14 Oct 2014 20:47:24 +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 wEgDk_sQdVld; Tue, 14 Oct 2014 20:47:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74D4320035; Tue, 14 Oct 2014 20:47:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A79D32EF6BAA; Tue, 14 Oct 2014 20:47:21 +0200 (CEST) Date: Tue, 14 Oct 2014 20:47:21 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20141014184721.GA71137@elstar.local> Mail-Followup-To: Martin Bjorklund , ietfc@btconnect.com, netconf@ietf.org References: <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> <20141014130900.GA70425@elstar.local> <20141014.151534.2215345713407265939.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141014.151534.2215345713407265939.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/V88RcXUW5E1aHhervyDQANDOMgo Cc: netconf@ietf.org Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 14 Oct 2014 18:47:43 -0000 On Tue, Oct 14, 2014 at 03:15:34PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Oct 14, 2014 at 10:11:27AM +0100, t. petch wrote: > > > > > > I think that here, we are going against the grain, in that TLS is > > > (almost) all about server authentication by certificate, and the issues > > > are which algorithms to use, and other forms of authentication, let > > > alone a prescribed method of client authentication (as opposed to an > > > application's RYO), get little attention. > > > > > > > RFC 5539 says both ends use a certificate. I assume this is the > > default unless someone makes a clear proposal otherwise. Are you > > making such a proposal? If not, lets go ahead with both ends use a > > certificate. > > Do you want to say certificate-based auth is a MUST? This seems to > imply that if someone someday wants to do PSK, that won't be possible. > > The alternative is to define certificate-based auth as the only > current option, but open the spec for other auth mechanisms. (this is > almost how the doc is written today...) > I believe we should allow for other authentication mechanisms (in particular client authentication mechanism) to be defined in the future. Hence, we should say that this document defines one possible client authentication mechanism namely the use of certificates. The real problem I personally have is that the algorithm to extract a username from the cert is defined a path of about 3 references away from this doucment. This creates and interesting dependency to other documents. But this is not so much a technical issue but more an organizational issue. I have to read up on the documents coming out of the UTA working group since ideally their work should simplify our work. The problem is that their BCP draft is the beginning of a longer recursive descent. /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 Oct 15 16:23: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 7BD291ACE1A for ; Wed, 15 Oct 2014 16:23:36 -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 1FuE6_nEeFLl for ; Wed, 15 Oct 2014 16:23:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6441ACE19 for ; Wed, 15 Oct 2014 16:23:34 -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.1049.19; Wed, 15 Oct 2014 23:23:32 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 23:23:32 +0000 From: Kent Watsen To: Alan Luchuk , "netconf@ietf.org" , "jshoenwaelder@jacobs-university.de" Thread-Topic: Comments on draft-ietf-netconf-server-model-03.txt Thread-Index: AQHP3PfuIWXKEogrdkyrjScW4AT0uZwefEcAgBATxCmAAxEKAA== Date: Wed, 15 Oct 2014 23:23:32 +0000 Message-ID: References: <201409302145.s8ULjq7q024177@mainfs.snmp.com> <201410132039.s9DKdbCn006026@mainfs.snmp.com> In-Reply-To: <201410132039.s9DKdbCn006026@mainfs.snmp.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:;SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(199003)(189002)(43784003)(51704005)(99286002)(122556002)(66066001)(85852003)(80022003)(20776003)(105586002)(46102003)(106356001)(64706001)(106116001)(15975445006)(2501002)(95666004)(21056001)(86362001)(230783001)(87936001)(19580395003)(97736003)(77096002)(50986999)(31966008)(54356999)(76482002)(76176999)(36756003)(2656002)(85306004)(101416001)(107046002)(2201001)(92566001)(120916001)(92726001)(4396001)(99396003)(40100003)(107886001); 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: <7EBABB49025FB54391DCD911FD9B9C37@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/_6b_CtrDV1rPyyngC3yX3PzkpGI 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 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 23:23:36 -0000 Hi Alan, >I attempted to give closer attention to the schema nodes related to >NETCONF=20 >over TLS. Just after pressing "send" for my comments, I realized I >failed=20 >to suggest the schema nodes related to NETCONF over TLS using pre-shared >keys >should be removed to match the text of >draft-ietf-netconf-rfc5539bis-06.txt. >This includes the removal of the "feature tls-map-pre-shared-keys", the >"grouping psk-maps-grouping", and the single "uses psk-maps-grouping". Yes, the server-model will be updated to reflect what 5539bis settles on. >>>Under the port leaf: >>> >>> Should this leaf be mandatory, or have a default of 0? >> >>In both places where this grouping is used, a transport-specific default >>is provided (830 for SSH, 6513 for TLS). Is it good enough? > >This answer is fine. The only problem that _might_ arise is if the >listen-per-transport-config grouping is used again in the future, >and the necessary port refinement is forgotten. In this case, the port >would be underspecified, and presumably be implementation-dependent, no? When a grouping is used, it is the responsibility of the modeler to ensure it's augmented/refined as needed for their use. I think it's OK the way it is now. >> +--rw netconf-server >> +--rw listen >> | +--rw endpoint* [name] >> | +--rw name string >> | ... >> +--rw call-home >> +--rw application* [name] >> +--rw name string >> | ... >> >> >>What do you think, is it better? > >This arrangement of the schema nodes seems clearer, but that doesn't >mean it is clearer :-) Deferring to WG consensus is a good plan. Cool, I just added https://github.com/netconf-wg/server-model/issues/15 to track this issue. >>>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? >> >>This is me just grouping things together for readability and >>extensibility. We could flatten the model some by having >>"keep-alive-interval-secs" and "keep-alive-count-max" - does that seem >>better to you? Also, while the model doesn't currently have any other >>nodes under the "persistent" node, it may someday (perhaps through an >>augmentation), such that having this structure helps keeps things nice >>and >>organized. Thoughts? > >Leave the schema as it is. This explanation is reasonable, and the >suggested simplification(s) are not sufficient to justify a change. Will do. >That sounds fine, but perhaps something along following line should be >added to the description clause for the last-connected enum: > > "If a NETCONF server does not have non-volatile memory to store > the last-connected endpoint across reboots, then upon reboot, the > NETCONF server chooses an reconnect transport endpoint in an > implementation-dependent manner." Just added https://github.com/netconf-wg/server-model/issues/16 to track this >OK. So basically, if a specific X.509 cert is stored in the >trusted-client-cert list, then when a connecting NETCONF client presents >that X.509 cert to the NETCONF server, the NETCONF server authorizes it. >The mere presence of an X.509 cert in the trusted-client-cert list >authorizes it when that cert is presented by a NETCONF client. Correct. >>Yes, and this issue is tracked here: >>https://github.com/netconf-wg/server-model/issues/4 >> >>Question, do you think configuring the TLS-server-cert/SSH-host-key to >>use >>should be a system-wide configuration, or something specific to the >>NETCONF server? > >System-wide configuration seems simpler. Something specific to the >NETCONF server would allow multiple instances of a NETCONF server on >a single system, and thus seems more flexible. True, but I think the WG consensus is for this model to be specifically for the NETCONF server. I'll add the ability to configure them in this model and them folks can discuss if it should be moved to another model. Thanks again, Kent From nobody Wed Oct 15 16:27: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 92EEC1ACE26 for ; Wed, 15 Oct 2014 16:27:34 -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 THnL_uNO-rP5 for ; Wed, 15 Oct 2014 16:27:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D3A1ACE16 for ; Wed, 15 Oct 2014 16:27:33 -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.1049.19; Wed, 15 Oct 2014 23:27:31 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Wed, 15 Oct 2014 23:27:31 +0000 From: Kent Watsen To: t.petch , NETCONF Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-01.txt Thread-Index: AQHP5NN6XD/V0BblhkKvHG8jqxuUtJwpmuEAgAXmSzaAAhFOAA== Date: Wed, 15 Oct 2014 23:27:30 +0000 Message-ID: References: <20141010214448.15637.19105.idtracker@ietfa.amsl.com> <061901cfe7a5$1a222860$4001a8c0@gateway.2wire.net> In-Reply-To: <061901cfe7a5$1a222860$4001a8c0@gateway.2wire.net> 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:;SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(51914003)(199003)(80022003)(46102003)(21056001)(36756003)(97736003)(77096002)(2656002)(230783001)(4396001)(99286002)(120916001)(95666004)(106356001)(106116001)(105586002)(40100003)(107886001)(107046002)(85852003)(76482002)(54356999)(50986999)(87936001)(99396003)(76176999)(122556002)(101416001)(31966008)(85306004)(20776003)(92726001)(66066001)(86362001)(64706001)(92566001); 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: <15AC664D774CEB45AA927857461141FE@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/5bJaHRok5tRJoouH4O8a09puHNM Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-01.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, 15 Oct 2014 23:27:34 -0000 Hi Tom, >Thanks for the prompt update, and also for undertaking the work - I do >think that this is the best document structure, within which to iron out >the wrinkles. Excellent - good to know the new doc structure is working out. >Talking of which, I find it hard to comment on the new Section 3.2 until >we have fixed the issue in rfc5539bis, namely what forms of >authentication are we covering with TLS. The SSH side seems stable, the >TLS not. We could require TLS client and server X.509 certificates >which would be simplest; I am unsure whether that would be acceptable or >not. Fair enough, we'll wait for 5539bis to settle down. >In passing, I note that the new RFC Editor Style Guide recommends the >use of TBD1 and TBD2, and not XXXX and YYYY - I think this is silly and >so would go on using XXXX and YYYY (and ZZZZ) But I see XXXX and YYYY in many drafts - weird. I personally think that XXXX is more eye-catching, but am willing to change to meeting RFC Editor guild lines if others feel its important. Thanks, Kent From nobody Wed Oct 15 20:42:14 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606D41A0164 for ; Wed, 15 Oct 2014 20:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 vJp5M1jEZQII for ; Wed, 15 Oct 2014 20:42:06 -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 BAAE01A0151 for ; Wed, 15 Oct 2014 20:42:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNR80136; Thu, 16 Oct 2014 03:42:03 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Oct 2014 04:42:02 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 11:41:56 +0800 From: Qin Wu To: "Romascanu, Dan (Dan)" , "Ersue, Mehmet (NSN - DE/Munich)" , NETCONF , "ext Benoit Claise" Thread-Topic: [Netconf] Looking for a new NETCONF co-chair Thread-Index: AQHP5v1aQ+QfSYL7QUWxZC7pBa3AMpwt2TSAgAAHSICAAAegAIAAWkoAgAC6JQCAAAKtgIADGIlQ Date: Thu, 16 Oct 2014 03:41:55 +0000 Message-ID: References: <543BF489.7000708@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA5C8CB68B@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8CB68B@AZ-FFEXMB04.global.avaya.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA845FCA0Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/U9PX505opIjMMk2iU1zgjXMEBl0 Subject: Re: [Netconf] Looking for a new NETCONF co-chair 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, 16 Oct 2014 03:42:09 -0000 --_000_B8F9A780D330094D99AF023C5877DABA845FCA0Fnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 KzENClNhbHV0ZSENCg0KUmVnYXJkcyENCi1RaW4NCreivP7IyzogTmV0Y29uZiBbbWFpbHRvOm5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb21hc2NhbnUsIERhbiAoRGFuKQ0Kt6LLzcqx vOQ6IDIwMTTE6jEw1MIxNMjVIDIwOjIzDQrK1bz+yMs6IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERF L011bmljaCk7IE5FVENPTkY7IGV4dCBCZW5vaXQgQ2xhaXNlDQrW98ziOiBSZTogW05ldGNvbmZd IExvb2tpbmcgZm9yIGEgbmV3IE5FVENPTkYgY28tY2hhaXINCg0KQmVydKGvcyBodWdlIGNvbnRy aWJ1dGlvbnMgaW4gTkVUQ09ORiBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGluIGdlbmVyYWwgZGVz ZXJ2ZSBhIEJJRyBwYXJ0eSENCg0KVGhhbmtzLCBCZXJ0IQ0KDQpEYW4NCg0KDQpGcm9tOiBOZXRj b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJzdWUs IE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxNCwgMjAx NCAzOjE0IFBNDQpUbzogTkVUQ09ORjsgZXh0IEJlbm9pdCBDbGFpc2UNClN1YmplY3Q6IFJlOiBb TmV0Y29uZl0gTG9va2luZyBmb3IgYSBuZXcgTkVUQ09ORiBjby1jaGFpcg0KDQpIaSBCZW5vaXQs IEFsbCwNCg0KPiBOb3Qgb25seSBhcyBhIGxlYWRlciwgYSBtZW50b3IsIGJ1dCBhbHNvIGEgZnJp ZW5kLg0KSSB3b3VsZCBsaWtlIHRvIHVuZGVybGluZSB0aGVzZSB3b3JkcywgYnV0IHRoZXkgYXJl IG5vdCBzdWZmaWNpZW50Lg0KTW9yZSB0aGFuIHlvdSBndXlzIEkgd2lsbCBtaXNzIEJlcnQuIEkg cmVhbGx5IGVuam95ZWQgdGhlIGxhc3QgNi41IHllYXJzIHdpdGggQmVydCBhcyBteSBjby1jaGFp ci4NCg0KTGV0oa9zIHVzZSB0aGUgdGltZSBpbiBIb25vbHVsdSBmb3IgYSBuaWNlIGFuZCBhcHBy b3ByaWF0ZSBmYXJld2VsbC4NCg0KQ2hlZXJzLA0KTWVobWV0DQoNCkZyb206IE5ldGNvbmYgW21h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgRGVhbiBCb2dk YW5vdmljDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE0LCAyMDE0IDM6MDggQU0NClRvOiBCZXJ0 IFdpam5lbiAoSUVURikNCkNjOiBORVRDT05GDQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIExvb2tp bmcgZm9yIGEgbmV3IE5FVENPTkYgY28tY2hhaXINCg0KQmVydCwNCg0KSSdsbCByYWlzZSBhIHRv YXN0IHRvIHlvdXIgcmV0aXJlbWVudCBhbmQgYmVzdCB3aXNoZXMgdG8geW91Lg0KDQpEZWFuDQoN Ck9uIE9jdCAxMywgMjAxNCwgYXQgMzo0NCBQTSwgQWxleGFuZGVyIENsZW1tIChhbGV4KSA8YWxl eEBjaXNjby5jb208bWFpbHRvOmFsZXhAY2lzY28uY29tPj4gd3JvdGU6DQoNCkhlbGxvIEJlcnQs DQoNCmJlc3Qgd2lzaGVzIGZvciB5b3VyIHJldGlyZW1lbnQhDQoNCi0tLSBBbGV4DQoNCkZyb206 IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2NvLmNv bT4+DQpEYXRlOiBNb25kYXksIE9jdG9iZXIgMTMsIDIwMTQgYXQgMTE6NDkgQU0NClRvOiBOZXRD b25mIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1YmplY3Q6 IFtOZXRjb25mXSBMb29raW5nIGZvciBhIG5ldyBORVRDT05GIGNvLWNoYWlyDQoNCkRlYXIgYWxs LA0KDQpJIGhhdmUgdG8gYW5ub3VuY2UsIHdpdGggbWl4ZWQgZmVlbGluZ3MsIHRoYXQgb25lIG9m IG15IG1lbnRvcnMgYXQgdGhlIElFVEYgZGVjaWRlZCB0byByZXRpcmUuDQpPbiBvbmUgaGFuZCwg SSdtIHByZXR0eSBoYXBweSBmb3IgQmVydCBXaWpuZW4gdG8gZW5qb3kgaGlzIHdlbGwgZGVzZXJ2 ZWQgcmV0aXJlbWVudC4NCk9uIHRoZSBoYW5kLCBCZXJ0IHdpbGwgYmUgbWlzc2VkLCBmb3Igc3Vy ZS4gTm90IG9ubHkgYXMgYSBsZWFkZXIsIGEgbWVudG9yLCBidXQgYWxzbyBhIGZyaWVuZC4NCk5v dGUgdGhhdCBCZXJ0IHdpbGwgYmUgYXR0ZW5kaW5nIGhpcyBsYXN0IElFVEYgbWVldGluZyBpbiBI b25vbHVsdS4gVGhpcyBpcyB5b3VyIGNoYW5jZS4uLg0KDQpQcmFjdGljYWxseSwgdGhpcyBpbXBs aWVzIHRoYXQgd2UgYXJlIGxvb2tpbmcgZm9yIGEgbmV3IE5FVENPTkYgY28tY2hhaXIuDQpQbGVh c2UgbGV0IEpvZWwgYW5kIEkga25vdyBpZiB5b3UgYXJlIGludGVyZXN0ZWQuDQoNClJlZ2FyZHMs IEJlbm9pdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0Y29u ZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u Zg0KDQoNCg0KLS0NCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29t PG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBp ZXRmLm9yZzxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA845FCA0Fnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+1

Salute!

 = ;

Regards!

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB: Netconf [mailto:netco= nf-bounces@ietf.org] =B4=FA=B1=ED = Romascanu, Dan (Dan)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA10=D4=C2= 14=C8=D5 20:23
=CA=D5=BC=FE=C8=CB: Ersue, Mehmet (NSN - DE/Munich); NETCONF; ext Benoit Claise
=D6=F7=CC=E2: Re: [Netconf] Looking for a new NETCONF co-chair=

 

Bert=A1=AF= s huge contributions in NETCONF and network management in general deserve a= BIG party!

 = ;

Thanks, Be= rt!

 = ;

Dan

 = ;

 = ;

From: Netconf [= mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Tuesday, October 14, 2014 3:14 PM
To: NETCONF; ext Benoit Claise
Subject: Re: [Netconf] Looking for a new NETCONF co-chair=

 

Hi Benoit, = All,

 

> Not only as a leader, a mentor, but also a = friend.

I would lik= e to underline these words, but they are not sufficient.<= /p>

More than y= ou guys I will miss Bert. I really enjoyed the last 6.5 years with Bert as = my co-chair.

 =

Let=A1=AFs = use the time in Honolulu for a nice and appropriate farewell.

 =

Cheers= ,
Mehmet

 =

From: Netconf [= mailto:netconf-bounces@ietf.org] On Behalf Of ext Dean Bogdanovic
Sent: Tuesday, October 14, 2014 3:08 AM
To: Bert Wijnen (IETF)
Cc: NETCONF
Subject: Re: [Netconf] Looking for a new NETCONF co-chair=

 

Bert,

 

I'll raise a toast to your reti= rement and best wishes to you.

 

Dean

 

On Oct 13, 2014, at 3:44 PM, Al= exander Clemm (alex) <alex@cisco.com> wrote:

=  

Hello Bert,=

 

best wishe= s for your retirement! <= /p>

 

--- Alex

 

From: B= enoit Claise <bclaise@cisco.com>
Date: Monday, Octo= ber 13, 2014 at 11:49 AM
To: NetConf <netconf@ietf.org>
Subject: [Netconf]= Looking for a new NETCONF co-chair<= /span>

 

Dear all,

I have to announce, with mixed feelings, that one of my mentors at the IETF= decided to retire.
On one hand, I'm pretty happy for&nbs= p;Bert Wijnen to enjoy his well deserved retirement.
On the hand, Bert will be missed, for sure. Not only as a leader, a mentor,= but also a friend.
Note that Bert will be attending his last IETF meeting in Honolulu. This is= your chance...

Practically, this implies that we are looking for a new NETCONF co-chair. Please let Joel and I know if you are interested.

Regards, Benoit

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



 

--

Mahesh Jethanandani<= /span>

______________________= _________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

 

--_000_B8F9A780D330094D99AF023C5877DABA845FCA0Fnkgeml501mbschi_-- From nobody Thu Oct 16 02:13: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 3A6FE1A014F for ; Thu, 16 Oct 2014 02:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2mfP9Jv0sjFO for ; Thu, 16 Oct 2014 02:13:13 -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 4B5811A19E3 for ; Thu, 16 Oct 2014 02:13:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKP48047; Thu, 16 Oct 2014 09:13:10 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Oct 2014 10:13:09 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 16 Oct 2014 17:13:03 +0800 From: Qin Wu To: Juergen Schoenwaelder , "t. petch" Thread-Topic: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 Thread-Index: AQHP4S06jPg1u++jTUq2pIkkEYRBtJwjEoS2gAWXgwCAAOvVz///k7QAgAANBICAAAuKgIAGRnzy//+O+QCAA2XFQA== Date: Thu, 16 Oct 2014 09:13:02 +0000 Message-ID: References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> <20141010.212225.300681995.mbj@tail-f.com> <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> <20141014130900.GA70425@elstar.local> In-Reply-To: <20141014130900.GA70425@elstar.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_mP_Xv5pGu1TKPudbP1qPX-ze3w Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 16 Oct 2014 09:13:15 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gSnVlcmdlbiBTY2hvZW53YWVsZGVyDQq3osvNyrG85DogMjAxNMTq MTDUwjE0yNUgMjE6MDkNCsrVvP7IyzogdC4gcGV0Y2gNCrOty806IG5ldGNvbmZAaWV0Zi5vcmcN Ctb3zOI6IFJlOiBbTmV0Y29uZl0gY29tbWVudCBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUz OWJpcy0wNg0KDQpPbiBUdWUsIE9jdCAxNCwgMjAxNCBhdCAxMDoxMToyN0FNICswMTAwLCB0LiBw ZXRjaCB3cm90ZToNCj4gDQo+IEkgdGhpbmsgdGhhdCBoZXJlLCB3ZSBhcmUgZ29pbmcgYWdhaW5z dCB0aGUgZ3JhaW4sIGluIHRoYXQgVExTIGlzDQo+IChhbG1vc3QpIGFsbCBhYm91dCBzZXJ2ZXIg YXV0aGVudGljYXRpb24gYnkgY2VydGlmaWNhdGUsIGFuZCB0aGUgDQo+IGlzc3VlcyBhcmUgd2hp Y2ggYWxnb3JpdGhtcyB0byB1c2UsIGFuZCBvdGhlciBmb3JtcyBvZiBhdXRoZW50aWNhdGlvbiwg DQo+IGxldCBhbG9uZSBhIHByZXNjcmliZWQgbWV0aG9kIG9mIGNsaWVudCBhdXRoZW50aWNhdGlv biAoYXMgb3Bwb3NlZCB0byANCj4gYW4gYXBwbGljYXRpb24ncyBSWU8pLCBnZXQgbGl0dGxlIGF0 dGVudGlvbi4NCj4gDQoNClJGQyA1NTM5IHNheXMgYm90aCBlbmRzIHVzZSBhIGNlcnRpZmljYXRl LiBJIGFzc3VtZSB0aGlzIGlzIHRoZSBkZWZhdWx0IHVubGVzcyBzb21lb25lIG1ha2VzIGEgY2xl YXIgcHJvcG9zYWwgb3RoZXJ3aXNlLiBBcmUgeW91IG1ha2luZyBzdWNoIGEgcHJvcG9zYWw/IElm IG5vdCwgbGV0cyBnbyBhaGVhZCB3aXRoIGJvdGggZW5kcyB1c2UgYSBjZXJ0aWZpY2F0ZS4NCg0K W1Fpbl06IFN1cHBvcnQuDQoNCkkgd2FzIHB1c2hpbmcgZm9yIFBTSyBhdXRoZW50aWNhdGlvbiBi YWNrIGluIGEgZGF5IHdoZW4gd2UgZGlkIE5DIGxpZ2h0LiBJIHRoaW5rIGl0IGlzIG1lYW53aGls ZSBjbGVhciB0aGF0IE5DIGxpZ2h0IGlzIG5vdCBhIHZpYWJsZSBvcHRpb24gYW5kIGhlbmNlIEkg cHJvcG9zZWQgdG8gcmVtb3ZlIFBTSyBhdXRoZW50aWNhdGlvbiBhdCB0aGUgVG9yb250byBtZWV0 aW5nIGFzIG5vdCBtYW55IHBlb3BsZSBzZWVtIHRvIGNhcmUgdG8gaW1wbGVtZW50IHRoaXMgKHNs aWRlICM3IG9mIG15IHNsaWRlIHNldCkuIFBlcmhhcHMgdGhlIGNoYWlycyBzaG91bGQgZG8gYW4g ZXhwbGljaXQgY2FsbCBmb3IgY29uY2Vuc3VzIG9uIHRoaXMgc28gdGhhdCB3ZSBjYW4gbW92ZSBv bi4NCg0KW1Fpbl06IEFyZSB5b3Ugc2F5aW5nIGNvbnN0cmFpbmVkIGRldmljZSB3aWxsIG5vdCBi ZSBzdXBwb3J0ZWQgYnkgdGhpcyBkcmFmdD8NCg0KL2pzDQoNCi0tIA0KSnVlcmdlbiBTY2hvZW53 YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiAr NDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJt YW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11 bml2ZXJzaXR5LmRlLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Thu Oct 16 03:12: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 2E4ED1ACCED for ; Thu, 16 Oct 2014 03:12:40 -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 T7kpL0ySG-eN for ; Thu, 16 Oct 2014 03:12:35 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::767]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5478F1A0194 for ; Thu, 16 Oct 2014 03:12:35 -0700 (PDT) Received: from pc6 (86.184.62.161) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 16 Oct 2014 10:12:11 +0000 Message-ID: <004301cfe929$59259580$4001a8c0@gateway.2wire.net> From: t.petch To: "Bert Wijnen (IETF)" , Juergen Schoenwaelder , References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> <20141010.212225.300681995.mbj@tail-f.com> <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> <20141014130900.GA70425@elstar.local> <543D2914.8060805@bwijnen.net> Date: Thu, 16 Oct 2014 11:09:44 +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.62.161] X-ClientProxiedBy: DB3PR05CA0043.eurprd05.prod.outlook.com (25.160.41.171) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 036614DD9C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(479174003)(199003)(51704005)(189002)(377454003)(164054003)(50466002)(230783001)(14496001)(116806002)(120916001)(23756003)(21056001)(93886004)(122386002)(85306004)(40100003)(47776003)(44736004)(85852003)(20776003)(62236002)(44716002)(42186005)(61296003)(64706001)(50226001)(4396001)(80022003)(46102003)(89996001)(99396003)(76482002)(19580395003)(77096002)(19580405001)(77156001)(107046002)(15975445006)(107886001)(66066001)(93916002)(86362001)(62966002)(31966008)(92566001)(92726001)(102836001)(97736003)(95666004)(105586002)(106356001)(104166001)(33646002)(101416001)(88136002)(87976001)(81816999)(87286001)(81686999)(76176999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/RkjIRVB8vH1xOUZyadawczmoRKw Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 16 Oct 2014 10:12:40 -0000 ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Juergen Schoenwaelder" ; Sent: Tuesday, October 14, 2014 2:45 PM > Juergen, do we have an open issue on an issues list somewhere that we > can point to? > - it should describe the issue > - a proposed solution > > We can then do a consensus call for the proposed solution > > Maybe this is somewhere already in my email archives or in meeting notes, > but it would be good to have it listed as an issue that we can easily point to. There is a pptx slide from IETF90 on the netconf materials page with a list of issues - sometimes I can access it, sometimes I cannot. The minutes of IETF90 do reference slides but not in a way that I find easy to correlate and the minutes on their own do not give me the complete picture (but who cares, everything will be confirmed on the list:-) So that slide set is the closest I know of to an issues list and 'Required Authentication Schemes' seems to fit the bill. I do think limiting ourselves to client and server X.509 certificates is the right way forward at this time but it does leave issues. One is that my reading of RFC6241 is that we need a mandatory, interoperable technique and if other methods appear in future, e.g. PSK, PAKE, raw public keys, then we would have to revise the I-D but this is life (Netconf started with SSH, BEEP, SOAP!). Certificate validation I see as straightforward based on RFC5280. Certificate authentication is tricky, the waters now being muddied by RFC6125 which, like much around TLS, focusses on HTTP with a user sitting at a screen ready to intervene - not much use for a network device looking at a client certificate. Pre-configured certificate fingerprints seems the best bet, as a SHOULD. The work of the UTA WG I think irrelevant - it is chartered for HTTP, SMTP and such like; client certificates will never be on its radar. Currently, it is rather hung up on what Opportunistic xxxxx means and what UTA should do about it. And then there is extracting the user name, which is even worse. X.509 could have had a user name extension for us to use, but we are out on a limb in our use of TLS so it does not. As I said before, I think that most TLS applications are RYO for client authentication. On the plus side, we have been here before and done it with RFC5539 so the best hope is that what was acceptable then, will be now, but where Security Area ADs are concerned, my pessimism is usually well-founded. Tom Petch > Thanks, > Bert > > On 14/10/14 15:09, Juergen Schoenwaelder wrote: > > I was pushing for PSK authentication back in a day when we did NC > > light. I think it is meanwhile clear that NC light is not a viable > > option and hence I proposed to remove PSK authentication at the > > Toronto meeting as not many people seem to care to implement this > > (slide #7 of my slide set). Perhaps the chairs should do an explicit > > call for concensus on this so that we can move on. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Oct 16 09:52:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA48F1A00E9 for ; Thu, 16 Oct 2014 09:52:14 -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 7NlBIHG7q5ct for ; Thu, 16 Oct 2014 09:52:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::721]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5D01A01A9 for ; Thu, 16 Oct 2014 09:51:57 -0700 (PDT) Received: from pc6 (86.184.62.161) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 16:48:09 +0000 Message-ID: <075d01cfe960$a9e62c00$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf References: Date: Thu, 16 Oct 2014 17:45:53 +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.62.161] X-ClientProxiedBy: DB3PR05CA0052.eurprd05.prod.outlook.com (25.160.41.180) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Forefront-PRVS: 036614DD9C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(9763003)(189002)(51704005)(62966002)(81816999)(61296003)(76176999)(4396001)(551544002)(50226001)(15975445006)(101416001)(104166001)(85306004)(62236002)(77096002)(92566001)(86362001)(93916002)(50986999)(40100003)(42186005)(122386002)(87286001)(81686999)(44736004)(77156001)(95666004)(64706001)(21056001)(20776003)(105586002)(116806002)(47776003)(33646002)(80022003)(46102003)(99396003)(66066001)(85852003)(23756003)(102836001)(16799955002)(50466002)(88136002)(87976001)(76482002)(89996001)(120916001)(107886001)(92726001)(84392001)(106356001)(19580405001)(97736003)(19580395003)(44716002)(31966008)(107046002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/BNLlzHHz_JtdlaOJA9Pw5P2XxMY Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim today at 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, 16 Oct 2014 16:52:15 -0000 Anything I should know about 5539bis from any interim? The last proceedings I can find were for 8th September Tom Petch ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" Sent: Monday, October 06, 2014 5:22 PM Subject: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim today at 17:00-19:00 UTC > NETCONF participants, > > today, Monday October 6, 2014, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time) > we will have our NETCONF virtual interim meeting. > > The virtual meeting is used mainly for issue solving of active WG item drafts. > > 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 > > Cheers, > Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Oct 16 11:19: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 D7CC51A7031 for ; Thu, 16 Oct 2014 11:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETIIcklYb-IQ for ; Thu, 16 Oct 2014 11:19:42 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7DA1A6FF6 for ; Thu, 16 Oct 2014 11:19:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9GIJahX008599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Oct 2014 18:19:36 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9GIJZuL003362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 20:19:36 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 20:19:35 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext t.petch" , netconf Thread-Topic: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim today at 17:00-19:00 UTC Thread-Index: AQHP4YG3o2tieBT4XUmY5aBiJe6L65wy/vU6gAAYemA= Date: Thu, 16 Oct 2014 18:19:34 +0000 Message-ID: References: <075d01cfe960$a9e62c00$4001a8c0@gateway.2wire.net> In-Reply-To: <075d01cfe960$a9e62c00$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1841 X-purgate-ID: 151667::1413483576-0000437E-7F53C24D/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/QTbeTA5Cc4sC4nzonwOiiOzWTqg Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim today at 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, 16 Oct 2014 18:19:47 -0000 There was no discussion on 5539bis in the last virtual interim meetings. The minutes for the meeting on October 6, 2014 are available at: https://mailarchive.ietf.org/arch/msg/netconf/hgyR9TkQWwsfXlgAQ_8xCLtdY_U=20 Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext t.petch [mailto:ietfc@btconnect.com] > Sent: Thursday, October 16, 2014 6:46 PM > To: Ersue, Mehmet (NSN - DE/Munich); netconf > Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interi= m today at > 17:00-19:00 UTC >=20 > Anything I should know about 5539bis from any interim? The last > proceedings I can find were for 8th September >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > To: "netconf" > Sent: Monday, October 06, 2014 5:22 PM > Subject: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim > today at 17:00-19:00 UTC >=20 >=20 > > NETCONF participants, > > > > today, Monday October 6, 2014, 17:00-19:00 UTC (19-21 Amsterdam, > Berlin time) > > we will have our NETCONF virtual interim meeting. > > > > The virtual meeting is used mainly for issue solving of active WG item > drafts. > > > > To JOIN WEBEX MEETING > > > https://ietf.webex.com/ietf/j.php?MTID=3Dm9f461ea30a23d08e29f45c40c0814e7= d > > 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 > > > > Cheers, > > Mehmet > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Oct 16 11:54: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 3A2691A8710 for ; Thu, 16 Oct 2014 11:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIk52YFU_wMr for ; Thu, 16 Oct 2014 11:53:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F3F1A710D for ; Thu, 16 Oct 2014 11:53:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9GIrpBv002649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Oct 2014 18:53:51 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9GIrpKQ009342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 20:53:51 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 20:53:51 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: Details about the Bi-weekly NETCONF Virtual Interim on October 20, 2014, 17:00-19:00 UTC Thread-Index: AQHP6XKGEHfD0/+XU0CKDkI2k2ndRQ== Date: Thu, 16 Oct 2014 18:53:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2822 X-purgate-ID: 151667::1413485632-00001FC1-DF67A064/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dVYKXJvxGysWX3CWmhpiV4e1Vrw Subject: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 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, 16 Oct 2014 18:53:59 -0000 Dear NETCONF WG, our next NETCONF virtual interim meeting will take place on Monday, October= 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time). Below is the agenda and the issue list we plan to discuss. @All: Please read the issue descriptions in github and state your opinion c= oncerning the possible solution as well as the way forward on the ML before= the meeting. @Draft authors: Please raise a discussion on concerning open issues and fee= dback you would like to have. You may also extend the agenda below as neces= sary. The co-chairs would also like to invite all people on NETCONF ML, but espec= ially=20 Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Luchuk, and Lad= a Lothka to join the virtual interim meeting and to contribute to the issue discussi= on. Your participation is required and greatly appreciated.=20 Thank You! Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC ---------------------------------------------------------------------------= -------- - 5 min chair intro - recording the meeting?, scribe, agenda bashing - 50 min restconf open issues (Andy) See https://github.com/netconf-wg/restconf/issues RESTCONF #3: add collection resource https://github.com/netconf-wg/restconf/issues/3 http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html RESTCONF #12: target resource list or leaf-list keys required for GET https://github.com/netconf-wg/restconf/issues/12 Not on the tracker yet: - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RF= C? - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for rel= ease 1? - 40 min netconf-server model open issues (Kent) see: https://github.com/netconf-wg/server-model/issues Issue #4: How to configure NETCONF server's SSH host-keys or TLS certifi= cates Issue #8: what other server config knobs are needed? Issue #13: enable indirect Issuer authentications? Issue #15: Should the "listen" and "call-home" lists have parent contain= ers? - 20 min netconf-call-home open issues (Kent) Issue #3: Extend to support RESTCONF as well? Issue #4: Have a call-home port? - 5 min AOB other topics Please let the co-chairs know ASAP if you have comments or requests concern= ing the agenda. Following is the webex+audio info for the meeting: To JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=3Dm9f461ea30a23d08e29f45c40c0814= 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 Mehmet and Bert From nobody Thu Oct 16 13: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 D39DC1A8986 for ; Thu, 16 Oct 2014 13:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD-Y07U3ZmWj for ; Thu, 16 Oct 2014 13:34:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBF51A892E for ; Thu, 16 Oct 2014 13:34:59 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 70E17128048B; Thu, 16 Oct 2014 22:34:58 +0200 (CEST) Date: Thu, 16 Oct 2014 22:34:57 +0200 (CEST) Message-Id: <20141016.223457.371317785.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <201409302145.s8ULjq7q024177@mainfs.snmp.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HwBCiFuRJew3RKD2iwEXaAe3tek Cc: netconf@ietf.org, jshoenwaelder@jacobs-university.de 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 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:35:01 -0000 Hi, Below is a comment on Alan's comment, and some additional comments from my review of this document. Kent Watsen wrote: > >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. > > Correct, all but 2 of the 11 groupings are only used once. Interestingly, > I did this to help make the module more readable. Of course I understand > that chasing the definition can be cumbersome, but the tradeoff is that > now each parent container can easily fit on the screen. I don't know, is > there best practice to follow on this? > > FWIW, I added https://github.com/netconf-wg/server-model/issues/12 to > track this issue. I also think that excessive usage of groupings make models more difficult to follow. So I suggest the groupings are inlined. -------------------- In the grouping listen-per-transport-config, address leaf has the type inet:host. Do we really suggest that the listen address is a DNS name? If we do, how should an implementation handle multiple addresses (and/or address families)? -------------------- In the grouping call-home-transport-config, there is a list host-key, indexed by 'name'. The 'name' is specified as "the name of a host key". What does this name refer to? (I think we have discussed this one before...?) -------------------- In the grouping call-home-connection-type-config, there is a container keep-alives. When I read this I didn't know what this keep alive thing refered to. I suggest at minimum add a reference statement, refering to rfc XXXX, section 4. Maybe also additional text. /martin From nobody Thu Oct 16 18:29: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 D52451A1BB5 for ; Thu, 16 Oct 2014 18:29:09 -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_65=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 uDkLxHtKj91I for ; Thu, 16 Oct 2014 18:29:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:746]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5461A0386 for ; Thu, 16 Oct 2014 18:29:07 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Fri, 17 Oct 2014 01:28:44 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.104]) with mapi id 15.00.1049.012; Fri, 17 Oct 2014 01:28:44 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [Netconf] Comments on draft-ietf-netconf-server-model-03.txt Thread-Index: AQHP3PfuIWXKEogrdkyrjScW4AT0uZwefEcAgBTLFYCAAA7SAA== Date: Fri, 17 Oct 2014 01:28:43 +0000 Message-ID: References: <201409302145.s8ULjq7q024177@mainfs.snmp.com> <20141016.223457.371317785.mbj@tail-f.com> In-Reply-To: <20141016.223457.371317785.mbj@tail-f.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:;SRVR:CO1PR05MB457; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(76104003)(189002)(164054003)(122556002)(97736003)(83506001)(4396001)(31966008)(120916001)(230783001)(85852003)(15975445006)(19580395003)(99396003)(101416001)(86362001)(92566001)(92726001)(21056001)(110136001)(76482002)(85306004)(77096002)(80022003)(46102003)(95666004)(99286002)(107046002)(66066001)(40100003)(20776003)(64706001)(50986999)(105586002)(76176999)(54356999)(106116001)(36756003)(87936001)(106356001)(2656002); 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: <2FDFE51CCCEE7C40970BB54EE6D9BCCA@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/GivweTFfLrQEzBMyIiFC75xquXs 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 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 01:29:10 -0000 Hi Martin, >I also think that excessive usage of groupings make models more >difficult to follow. So I suggest the groupings are inlined. OK, that makes 4, so I'll collapse some of the groupings >In the grouping listen-per-transport-config, address leaf has the type >inet:host. Do we really suggest that the listen address is a DNS >name? If we do, how should an implementation handle multiple >addresses (and/or address families)? Good catch. I had already fixed this in my local copy too. >In the grouping call-home-transport-config, there is a list host-key, >indexed by 'name'. The 'name' is specified as "the name of a host >key". What does this name refer to? (I think we have discussed this >one before...?) Yes, this came up in Toronto and is tracked here: https://github.com/netconf-wg/server-model/issues/4 I'm going to add new top-level containers netconf-server/{ssh,tls} to the configured certificates and host-keys, and then this can become an instance-identifier to an entry in said lists. These lists will be config=3Dfalse. In order to add new entries, I'm thinking to have RPCs lik= e and . What do you think? >In the grouping call-home-connection-type-config, there is a container >keep-alives. When I read this I didn't know what this keep alive >thing refered to. I suggest at minimum add a reference statement, >refering to rfc XXXX, section 4. Maybe also additional text. Here's the new text, what do you think? container keep-alives { description "Configures the keep-alive policy, to proactively test the aliveness of the NETCONF client, in order to know when a new call home connection should be established. How keep-alives are implemented is described in RFC XXXX, section 4."; Thanks, Kent From nobody Fri Oct 17 00:16:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6676E1A90F4 for ; Fri, 17 Oct 2014 00:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE0Udb2pr0F9 for ; Fri, 17 Oct 2014 00:16:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 45FBC1A90F3 for ; Fri, 17 Oct 2014 00:16:21 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F8A31280457; Fri, 17 Oct 2014 09:16:18 +0200 (CEST) Date: Fri, 17 Oct 2014 09:16:18 +0200 (CEST) Message-Id: <20141017.091618.679582233883996238.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20141016.223457.371317785.mbj@tail-f.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/RGibPboVVfEVWZpPSVpipg1Notg 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 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 07:16:23 -0000 Hi, Kent Watsen wrote: > >In the grouping call-home-transport-config, there is a list host-key, > >indexed by 'name'. The 'name' is specified as "the name of a host > >key". What does this name refer to? (I think we have discussed this > >one before...?) > > Yes, this came up in Toronto and is tracked here: > https://github.com/netconf-wg/server-model/issues/4 > > I'm going to add new top-level containers netconf-server/{ssh,tls} to the > configured certificates and host-keys, and then this can become an > instance-identifier to an entry in said lists. These lists will be > config=false. In order to add new entries, I'm thinking to have RPCs like > and . What > do you think? Why do we have specified host-keys for callhome, but not for the normal netconf server case? And should we really have separate host-keys for callhome and normal server? > >In the grouping call-home-connection-type-config, there is a container > >keep-alives. When I read this I didn't know what this keep alive > >thing refered to. I suggest at minimum add a reference statement, > >refering to rfc XXXX, section 4. Maybe also additional text. > > Here's the new text, what do you think? > > container keep-alives { > description > "Configures the keep-alive policy, to proactively > test the aliveness of the NETCONF client, in order > to know when a new call home connection should be > established. How keep-alives are implemented is > described in RFC XXXX, section 4."; Ok, but also add: reference "RFC XXX: NETCONF Server Configuration Model Section 4"; /martin From nobody Fri Oct 17 03:32: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 1C80F1AC3C7 for ; Fri, 17 Oct 2014 03:32:52 -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, J_CHICKENPOX_55=0.6, SPF_HELO_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 44aeroLqYm2o for ; Fri, 17 Oct 2014 03:32:50 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::782]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B44E1AC3C6 for ; Fri, 17 Oct 2014 03:32:50 -0700 (PDT) Received: from AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) by AMXPR07MB117.eurprd07.prod.outlook.com (10.242.70.142) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 10:32:27 +0000 Received: from pc6 (86.184.62.161) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 10:32:26 +0000 Message-ID: <014601cfe9f5$57122520$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf References: Date: Fri, 17 Oct 2014 11:21:12 +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.62.161] X-ClientProxiedBy: DB4PR03CA0022.eurprd03.prod.outlook.com (25.160.39.160) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Forefront-PRVS: 0367A50BB1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(9763003)(377454003)(199003)(51444003)(13464003)(189002)(33646002)(81816999)(50466002)(16799955002)(76176999)(61296003)(15202345003)(85852003)(20776003)(47776003)(66066001)(15975445006)(104166001)(86362001)(92566001)(62966002)(21056001)(97736003)(101416001)(46102003)(85306004)(40100003)(99396003)(80022003)(81686999)(50986999)(23756003)(19580405001)(44736004)(120916001)(42186005)(19580395003)(14496001)(44716002)(106356001)(62236002)(50226001)(116806002)(4396001)(105586002)(93916002)(92726001)(76482002)(77156001)(88136002)(77096002)(64706001)(122386002)(84392001)(107886001)(31966008)(87286001)(107046002)(95666004)(89996001)(87976001)(102836001)(551544002)(74416001)(7726001)(276003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB117; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bEirv4de0nW0hAr-Mr8njlPuoWo Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 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: Fri, 17 Oct 2014 10:32:52 -0000 ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" Sent: Thursday, October 16, 2014 7:53 PM > Dear NETCONF WG, > > our next NETCONF virtual interim meeting will take place on Monday, October 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time). > Below is the agenda and the issue list we plan to discuss. > > @All: Please read the issue descriptions in github and state your opinion concerning the possible solution as well as the way forward on the ML before the meeting. > @Draft authors: Please raise a discussion on concerning open issues and feedback you would like to have. You may also extend the agenda below as necessary. > > The co-chairs would also like to invite all people on NETCONF ML, but especially > > Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Luchuk, and Lada Lothka Mehmet, I hear you; trouble is, the agenda is not very appealing. I am a simple-minded man, who likes to progress in small steps and scope, or requirements, comes early on. Currently, I am unclear about how a NETCONF user will be authenticated, especially with TLS; once that is determined, I will feel able to comment more on 5539bis. After which, I can move on to the second half of call-home, which in turn determines what goes, or does not go, into server-model; while RESTCONF is not yet on my radar (I note that in Apps, there is some debate about RESTful and whether or not it is well-enough defined to talk about meaningfully). So when I see 50 minutes of RESTCONF followed by 50 minutes of server-model, I think that that is two hours of sitting and listening for me:-( Tom Petch > > to join the virtual interim meeting and to contribute to the issue discussion. > Your participation is required and greatly appreciated. > Thank You! > > > Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC > ---------------------------------------------------------------------- ------------- > > - 5 min chair intro - recording the meeting?, scribe, agenda bashing > > - 50 min restconf open issues (Andy) > See https://github.com/netconf-wg/restconf/issues > > RESTCONF #3: add collection resource > https://github.com/netconf-wg/restconf/issues/3 > http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html > > RESTCONF #12: target resource list or leaf-list keys required for GET > https://github.com/netconf-wg/restconf/issues/12 > > Not on the tracker yet: > - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RFC? > - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for release 1? > > > - 40 min netconf-server model open issues (Kent) > see: https://github.com/netconf-wg/server-model/issues > > Issue #4: How to configure NETCONF server's SSH host-keys or TLS certificates > Issue #8: what other server config knobs are needed? > Issue #13: enable indirect Issuer authentications? > Issue #15: Should the "listen" and "call-home" lists have parent containers? > > - 20 min netconf-call-home open issues (Kent) > > Issue #3: Extend to support RESTCONF as well? > Issue #4: Have a call-home port? > > - 5 min AOB other topics > > > Please let the co-chairs know ASAP if you have comments or requests concerning the agenda. > > Following is the webex+audio info for the meeting: > > 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 > > Mehmet and Bert > From nobody Fri Oct 17 08:21: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 E31A81A1AAF for ; Fri, 17 Oct 2014 08:21:30 -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 XClhtiZew1hd for ; Fri, 17 Oct 2014 08:21:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73A91A1AD9 for ; Fri, 17 Oct 2014 08:20:41 -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.1049.19; Fri, 17 Oct 2014 15:20:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) with mapi id 15.00.1049.012; Fri, 17 Oct 2014 15:20:39 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [Netconf] Comments on draft-ietf-netconf-server-model-03.txt Thread-Index: AQHP3PfuIWXKEogrdkyrjScW4AT0uZwefEcAgBTLFYCAAA7SAIAApF8AgABEQIA= Date: Fri, 17 Oct 2014 15:20:39 +0000 Message-ID: References: <20141016.223457.371317785.mbj@tail-f.com> <20141017.091618.679582233883996238.mbj@tail-f.com> In-Reply-To: <20141017.091618.679582233883996238.mbj@tail-f.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:;SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(51704005)(189002)(64706001)(40100003)(97736003)(101416001)(110136001)(107046002)(20776003)(66066001)(85852003)(80022003)(46102003)(93886004)(85306004)(31966008)(86362001)(77096002)(21056001)(95666004)(76482002)(36756003)(230783001)(99396003)(92726001)(105586002)(99286002)(92566001)(4396001)(83506001)(122556002)(120916001)(87936001)(54356999)(76176999)(106116001)(50986999)(106356001)(2656002)(276003)(21314002); 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: <77D0F312127E33458C42538A58FB34A7@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/zYGMkUawYM5eyWIhBEZfrkf4y6k Cc: netconf 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 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:21:31 -0000 >Why do we have specified host-keys for callhome, but not for the >normal netconf server case? And should we really have separate >host-keys for callhome and normal server? For zero-touch, which uses call home, it is critical that an X.509-based host-key is the *only* host-key advertised, as the client needs it to automatically authenticate the device. Normal SSH typically uses RSA or DSA host-keys; the server could also advertise an X.509-based key, but it's not required.=20 Keep in mind that there are multiple instances of `sshd` running - one for port 22, another (or maybe the same) for port 830, and one for each call-home. In OpenSSH terms, there can be a distinct sshd_config file for each. >Ok, but also add: > > reference > "RFC XXX: NETCONF Server Configuration Model > Section 4"; Added in my local copy. Thanks, Kent From nobody Fri Oct 17 08:55: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 CFF381A1B80 for ; Fri, 17 Oct 2014 08:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=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 t0rlzHk9P2oM for ; Fri, 17 Oct 2014 08:55:15 -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 89DCE1A1B97 for ; Fri, 17 Oct 2014 08:55:15 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id q108so749631qgd.11 for ; Fri, 17 Oct 2014 08:55:14 -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=nMtX1J7DnCHXC8Ivgcc7DcBat6sxi4IruuCKOw61Ah8=; b=mWj+qf3ok6L4aJPVm7PNAMFUcwoYs9bgIP1QgUZdb8URwfGB1FcAw5a2ASofucvb4A AJvCG7lsVrBBOZ89bXCRD7CVCFxs6MmzLrpHL1hxDBNjc56evsQ1mVe2nwmxhegpomty MOGpMZr6ZLTdLNLZfgqlUE/Dv5h/+zpvzjsw0/YsoZAD4BbrnFWO7Xq++dUaw/Fm81eI FZwaNXoXkanvHMv5n74wwCPr2RrbztDKWs0dFXclV9nnDLQ3gJSGQDYo7b9aMcu1HlvB qPmY+OKXiRn6P5Mqt23jMRRdIhjeooyjy41D0ftQ7aBHF40wgjjSirlTdDoD/MMMTYE2 5OaQ== X-Gm-Message-State: ALoCoQlIujj7gYzUi+17comr5xMe5wnZf5Yl+m9PtGyoCI9eHnt2Cdu11EppoNhKpD0pjULnkahZ MIME-Version: 1.0 X-Received: by 10.140.108.67 with SMTP id i61mr12410248qgf.90.1413561314491; Fri, 17 Oct 2014 08:55:14 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Fri, 17 Oct 2014 08:55:14 -0700 (PDT) In-Reply-To: <014601cfe9f5$57122520$4001a8c0@gateway.2wire.net> References: <014601cfe9f5$57122520$4001a8c0@gateway.2wire.net> Date: Fri, 17 Oct 2014 08:55:14 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a113ac1a204d8a60505a0640c Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/d-vLgfZGIMX7aMhGf7iQO60cRPs Cc: netconf Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 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: Fri, 17 Oct 2014 15:55:18 -0000 --001a113ac1a204d8a60505a0640c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 17, 2014 at 3:21 AM, t.petch wrote: > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > To: "netconf" > Sent: Thursday, October 16, 2014 7:53 PM > > Dear NETCONF WG, > > > > our next NETCONF virtual interim meeting will take place on Monday, > October 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time). > > Below is the agenda and the issue list we plan to discuss. > > > > @All: Please read the issue descriptions in github and state your > opinion concerning the possible solution as well as the way forward on > the ML before the meeting. > > @Draft authors: Please raise a discussion on concerning open issues > and feedback you would like to have. You may also extend the agenda > below as necessary. > > > > The co-chairs would also like to invite all people on NETCONF ML, but > especially > > > > Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Luchuk, and > Lada Lothka > > Mehmet, > > I hear you; trouble is, the agenda is not very appealing. > > I am a simple-minded man, who likes to progress in small steps and > scope, or requirements, comes early on. Currently, I am unclear about > how a NETCONF user will be authenticated, especially with TLS; once that > is determined, I will feel able to comment more on 5539bis. After > which, I can move on to the second half of call-home, which in turn > determines what goes, or does not go, into server-model; while RESTCONF > is not yet on my radar (I note that in Apps, there is some debate about > RESTful and whether or not it is well-enough defined to talk about > meaningfully). > > So when I see 50 minutes of RESTCONF followed by 50 minutes of > server-model, I think that that is two hours of sitting and listening > for me:-( > > How about if your issues were first? RESTCONF does not have to go first each time. > Tom Petch > > Andy > > > > to join the virtual interim meeting and to contribute to the issue > discussion. > > Your participation is required and greatly appreciated. > > Thank You! > > > > > > Agenda of the virtual interim meeting on October 20, 2014 1700-1900 > UTC > > ---------------------------------------------------------------------- > ------------- > > > > - 5 min chair intro - recording the meeting?, scribe, agenda bashing > > > > - 50 min restconf open issues (Andy) > > See https://github.com/netconf-wg/restconf/issues > > > > RESTCONF #3: add collection resource > > https://github.com/netconf-wg/restconf/issues/3 > > http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html > > > > RESTCONF #12: target resource list or leaf-list keys required for > GET > > https://github.com/netconf-wg/restconf/issues/12 > > > > Not on the tracker yet: > > - ietf-yang-library.yang in RESTCONF-02: Should this be in a > separate RFC? > > - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete > for release 1? > > > > > > - 40 min netconf-server model open issues (Kent) > > see: https://github.com/netconf-wg/server-model/issues > > > > Issue #4: How to configure NETCONF server's SSH host-keys or TLS > certificates > > Issue #8: what other server config knobs are needed? > > Issue #13: enable indirect Issuer authentications? > > Issue #15: Should the "listen" and "call-home" lists have parent > containers? > > > > - 20 min netconf-call-home open issues (Kent) > > > > Issue #3: Extend to support RESTCONF as well? > > Issue #4: Have a call-home port? > > > > - 5 min AOB other topics > > > > > > Please let the co-chairs know ASAP if you have comments or requests > concerning the agenda. > > > > Following is the webex+audio info for the meeting: > > > > 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 > > > > Mehmet and Bert > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113ac1a204d8a60505a0640c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 17, 2014 at 3:21 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -= ----
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: "netconf" <netconf@iet= f.org>
Sent: Thursday, October 16, 2014 7:53 PM
> Dear NETCONF WG,
>
> our next NETCONF virtual interim meeting will take place on Monday, October 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time).
> Below is the agenda and the issue list we plan to discuss.
>
> @All: Please read the issue descriptions in github and state your
opinion concerning the possible solution as well as the way forward on
the ML before the meeting.
> @Draft authors: Please raise a discussion on concerning open issues and feedback you would like to have. You may also extend the agenda
below as necessary.
>
> The co-chairs would also like to invite all people on NETCONF ML, but<= br> especially
>
>=A0 =A0Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Luchuk, = and
Lada Lothka

Mehmet,

I=A0 hear you; trouble is, the agenda is not very appealing.

I am a simple-minded man, who likes to progress in small steps and
scope, or requirements, comes early on.=A0 Currently, I am unclear about how a NETCONF user will be authenticated, especially with TLS; once that is determined, I will feel able to comment more on 5539bis.=A0 After
which, I can move on to the second half of call-home, which in turn
determines what goes, or does not go, into server-model; while RESTCONF
is not yet on my radar (I note that in Apps, there is some debate about
RESTful and whether or not it is well-enough defined to talk about
meaningfully).

So when I see 50 minutes of RESTCONF followed by 50 minutes of
server-model, I think that that is two hours of sitting and listening
for me:-(


How about if your issues were first?
RESTCONF does not have to go first each time.

=
=A0
Tom Petch


Andy
=A0
>
> to join the virtual interim meeting and to contribute to the issue
discussion.
> Your participation is required and greatly appreciated.
> Thank You!
>
>
> Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC
> ----------------------------------------------------------------------=
-------------
>
> - 5 min chair intro - recording the meeting?, scribe, agenda bashing >
> - 50 min restconf open issues (Andy)
>=A0 =A0 See https://github.com/netconf-wg/restconf/issues
>
>=A0 =A0 RESTCONF #3: add collection resource
>=A0 =A0 https://github.com/netconf-wg/restconf/issues/3
>=A0 =A0 http://www.ietf.org/mail-archive/web/netc= onf/current/msg09365.html
>
>=A0 =A0 RESTCONF #12:=A0 =A0target resource list or leaf-list keys requ= ired for
GET
>=A0 =A0 https://github.com/netconf-wg/restconf/issues/12
>
>=A0 =A0 Not on the tracker yet:
>=A0 =A0 - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RFC?
>=A0 =A0 - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complet= e
for release 1?
>
>
> - 40 min netconf-server model open issues=A0 (Kent)
>=A0 =A0 see: https://github.com/netconf-wg/server-model/issues=
>
>=A0 =A0 Issue #4: How to configure NETCONF server's SSH host-keys o= r TLS
certificates
>=A0 =A0 Issue #8: what other server config knobs are needed?
>=A0 =A0 Issue #13: enable indirect Issuer authentications?
>=A0 =A0 Issue #15: Should the "listen" and "call-home&qu= ot; lists have parent
containers?
>
> - 20 min netconf-call-home open issues=A0 (Kent)
>
>=A0 =A0 Issue #3: Extend to support RESTCONF as well?
>=A0 =A0 Issue #4:=A0 Have a call-home port?
>
> - 5 min AOB other topics
>
>
> Please let the co-chairs know ASAP if you have comments or requests concerning the agenda.
>
> Following is the webex+audio info for the meeting:
>
>=A0 =A0 =A0To JOIN WEBEX MEETING
>
https://ietf.webex.com/ietf/j.php?MTID=3Dm9f4= 61ea30a23d08e29f45c40c0814e7d
>=A0 =A0 =A0Meeting number: 649 602 794
>=A0 =A0 =A0Meeting password: restconf
>
>=A0 =A0 =A0JOIN BY PHONE
>=A0 =A0 =A01-650-479-3208 Call-in toll number (US/Canada)
>=A0 =A0 =A0Access code: 649 602 794
>
>=A0 =A0 =A0Can't join the meeting? Contact support here:
>=A0 =A0 =A0https://ietf.webex.com/ietf/mc
>
> Mehmet and Bert
>

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

--001a113ac1a204d8a60505a0640c-- From nobody Fri Oct 17 09:16: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 8A43A1A1BB1 for ; Fri, 17 Oct 2014 09:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEEq7RkKWAJo for ; Fri, 17 Oct 2014 09:16:00 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2561A1BC5 for ; Fri, 17 Oct 2014 09:15:35 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9HGFWlR031121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Oct 2014 16:15:32 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9HGFVn3028533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 18:15:31 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 17 Oct 2014 18:15:31 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 18:15:31 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman , "t.petch" Thread-Topic: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 2014, 17:00-19:00 UTC Thread-Index: AQHP6iK9EHfD0/+XU0CKDkI2k2ndRZw0dWSw Date: Fri, 17 Oct 2014 16:15:30 +0000 Message-ID: References: <014601cfe9f5$57122520$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195161FDDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 40481 X-purgate-ID: 151667::1413562532-00001FC1-1C291B21/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/K_ALxj6wjvkrL-bEaQFaVlWh6jo Cc: netconf Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 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: Fri, 17 Oct 2014 16:16:05 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195161FDDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom, we can for sure put 5539bis issues onto the agenda. @Juergen: Please jump in. Cheers, Mehmet From: ext Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, October 17, 2014 5:55 PM To: t.petch Cc: Ersue, Mehmet (NSN - DE/Munich); netconf Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim = on October 20, 2014, 17:00-19:00 UTC On Fri, Oct 17, 2014 at 3:21 AM, t.petch > wrote: ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" > To: "netconf" > Sent: Thursday, October 16, 2014 7:53 PM > Dear NETCONF WG, > > our next NETCONF virtual interim meeting will take place on Monday, October 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time). > Below is the agenda and the issue list we plan to discuss. > > @All: Please read the issue descriptions in github and state your opinion concerning the possible solution as well as the way forward on the ML before the meeting. > @Draft authors: Please raise a discussion on concerning open issues and feedback you would like to have. You may also extend the agenda below as necessary. > > The co-chairs would also like to invite all people on NETCONF ML, but especially > > Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Luchuk, and Lada Lothka Mehmet, I hear you; trouble is, the agenda is not very appealing. I am a simple-minded man, who likes to progress in small steps and scope, or requirements, comes early on. Currently, I am unclear about how a NETCONF user will be authenticated, especially with TLS; once that is determined, I will feel able to comment more on 5539bis. After which, I can move on to the second half of call-home, which in turn determines what goes, or does not go, into server-model; while RESTCONF is not yet on my radar (I note that in Apps, there is some debate about RESTful and whether or not it is well-enough defined to talk about meaningfully). So when I see 50 minutes of RESTCONF followed by 50 minutes of server-model, I think that that is two hours of sitting and listening for me:-( How about if your issues were first? RESTCONF does not have to go first each time. Tom Petch Andy > > to join the virtual interim meeting and to contribute to the issue discussion. > Your participation is required and greatly appreciated. > Thank You! > > > Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC > ---------------------------------------------------------------------- ------------- > > - 5 min chair intro - recording the meeting?, scribe, agenda bashing > > - 50 min restconf open issues (Andy) > See https://github.com/netconf-wg/restconf/issues > > RESTCONF #3: add collection resource > https://github.com/netconf-wg/restconf/issues/3 > http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html > > RESTCONF #12: target resource list or leaf-list keys required for GET > https://github.com/netconf-wg/restconf/issues/12 > > Not on the tracker yet: > - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RFC? > - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for release 1? > > > - 40 min netconf-server model open issues (Kent) > see: https://github.com/netconf-wg/server-model/issues > > Issue #4: How to configure NETCONF server's SSH host-keys or TLS certificates > Issue #8: what other server config knobs are needed? > Issue #13: enable indirect Issuer authentications? > Issue #15: Should the "listen" and "call-home" lists have parent containers? > > - 20 min netconf-call-home open issues (Kent) > > Issue #3: Extend to support RESTCONF as well? > Issue #4: Have a call-home port? > > - 5 min AOB other topics > > > Please let the co-chairs know ASAP if you have comments or requests concerning the agenda. > > Following is the webex+audio info for the meeting: > > To JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=3Dm9f461ea30a23d08e29f45c40c0814e7d > 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 > > Mehmet and Bert > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_E4DE949E6CE3E34993A2FF8AE79131F8195161FDDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tom,<= /p>

 

we can for sure put 5539bi= s issues onto the agenda.

 

@Juergen: Please jump in.<= o:p>

 

Cheers,
Mehmet

 

From: ext Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, October 17, 2014 5:55 PM
To: t.petch
Cc: Ersue, Mehmet (NSN - DE/Munich); netconf
Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual I= nterim on October 20, 2014, 17:00-19:00 UTC

 

 

 

On Fri, Oct 17, 2014 at 3:21 AM, t.petch <ietfc@btconnect.com> wrote:

<= span style=3D"font-size:11.0pt;mso-bidi-font-size:12.0pt">----- Original Me= ssage -----
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: "netconf" <netconf@iet= f.org>
Sent: Thursday, October 16, 2014 7:53 PM
> Dear NETCONF WG,
>
> our next NETCONF virtual interim meeting will take place on Monday, October 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time).
> Below is the agenda and the issue list we plan to discuss.
>
> @All: Please read the issue descriptions in github and state your
opinion concerning the possible solution as well as the way forward on
the ML before the meeting.
> @Draft authors: Please raise a discussion on concerning open issues and feedback you would like to have. You may also extend the agenda
below as necessary.
>
> The co-chairs would also like to invite all people on NETCONF ML, but<= br> especially
>
>   Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Lu= chuk, and
Lada Lothka

Mehmet,

I  hear you; trouble is, the agenda is not very appealing.

I am a simple-minded man, who likes to progress in small steps and
scope, or requirements, comes early on.  Currently, I am unclear about=
how a NETCONF user will be authenticated, especially with TLS; once that is determined, I will feel able to comment more on 5539bis.  After
which, I can move on to the second half of call-home, which in turn
determines what goes, or does not go, into server-model; while RESTCONF
is not yet on my radar (I note that in Apps, there is some debate about
RESTful and whether or not it is well-enough defined to talk about
meaningfully).

So when I see 50 minutes of RESTCONF followed by 50 minutes of
server-model, I think that that is two hours of sitting and listening
for me:-(

 

How about if your issues were first?

RESTCONF does not have to go first each time.

 

 

Tom Petch

 

Andy

 

>
> to join the virtual interim meeting and to contribute to the issue
discussion.
> Your participation is required and greatly appreciated.
> Thank You!
>
>
> Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC
> ----------------------------------------------------------------------=
-------------
>
> - 5 min chair intro - recording the meeting?, scribe, agenda bashing >
> - 50 min restconf open issues (Andy)
>    See https://github.com/netconf-wg/restconf/issues
>
>    RESTCONF #3: add collection resource
>    https://github.com/netconf-wg/restconf/issues/3 >    http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html
>
>    RESTCONF #12:   target resource list or leaf-li= st keys required for
GET
>    https://github.com/netconf-wg/restconf/issues/12<= br> >
>    Not on the tracker yet:
>    - ietf-yang-library.yang in RESTCONF-02: Should this be i= n a
separate RFC?
>    - ietf-restconf-monitoring.yang in RESTCONF-02: Is this c= omplete
for release 1?
>
>
> - 40 min netconf-server model open issues  (Kent)
>    see: https://github.com/netconf-wg/server-model/issues
>
>    Issue #4: How to configure NETCONF server's SSH host-keys= or TLS
certificates
>    Issue #8: what other server config knobs are needed?
>    Issue #13: enable indirect Issuer authentications?
>    Issue #15: Should the "listen" and "call-h= ome" lists have parent
containers?
>
> - 20 min netconf-call-home open issues  (Kent)
>
>    Issue #3: Extend to support RESTCONF as well?
>    Issue #4:  Have a call-home port?
>
> - 5 min AOB other topics
>
>
> Please let the co-chairs know ASAP if you have comments or requests concerning the agenda.
>
> Following is the webex+audio info for the meeting:
>
>     To JOIN WEBEX MEETING
>
https://ietf.webex.com/ietf/j.php?MTID=3Dm9f4= 61ea30a23d08e29f45c40c0814e7d
>     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
>
> Mehmet and Bert
>

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

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F8195161FDDEMUMBX005nsnin_-- From nobody Fri Oct 17 09:51: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 BF3861A6F0D for ; Fri, 17 Oct 2014 09:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, SPF_HELO_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 xDc77DkM6arO for ; Fri, 17 Oct 2014 09:50:57 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::778]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2D01A6F0B for ; Fri, 17 Oct 2014 09:50:55 -0700 (PDT) Received: from pc6 (86.184.62.161) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 16:48:49 +0000 Message-ID: <0b7501cfea29$ebb06b40$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (NSN - DE/Munich)" References: <014601cfe9f5$57122520$4001a8c0@gateway.2wire.net> Date: Fri, 17 Oct 2014 17:46:32 +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.62.161] X-ClientProxiedBy: DB4PR03CA0033.eurprd03.prod.outlook.com (25.160.39.171) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-Forefront-PRVS: 0367A50BB1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(9763003)(199003)(51704005)(189002)(13464003)(24454002)(21056001)(80022003)(46102003)(551544002)(89996001)(99396003)(85852003)(120916001)(87976001)(87286001)(77156001)(66066001)(47776003)(62236002)(97736003)(122386002)(20776003)(15975445006)(44716002)(64706001)(84392001)(31966008)(14496001)(93886004)(85306004)(33646002)(88136002)(40100003)(62966002)(104166001)(95666004)(19580405001)(19580395003)(77096002)(50986999)(76482002)(16799955002)(86362001)(93916002)(107046002)(81816999)(102836001)(101416001)(50226001)(76176999)(61296003)(81686999)(15202345003)(105586002)(50466002)(4396001)(92566001)(23756003)(42186005)(106356001)(92726001)(110136001)(74416001)(7726001)(276003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3nt0QUDItTvcIXhpaJ3dse_lQx4 Cc: netconf Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 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: Fri, 17 Oct 2014 16:50:59 -0000 Mehmet My sense is that we are heading towards X.509 certificates for client and server authentication with NETCONF over TLS and that what it needs is a consensus call to effect that. I don't think there is anything to discuss, ar at least, not worth putting on the Agenda of a Virtual Interim. And if, in a week or two, we have that consensus, then it is a question of updating the three I-Ds to reflect that and seeing what comes next. May be how to extract a user id will be then worth discussing. So it is probably right that the Virtual Interim focuses on RESTCONF because I suspect that that is the area where discussions will be most fruitful, just that I don't see anything I can contribute there at this time. Tom Petch ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" ; "t.petch" Cc: "netconf" Sent: Friday, October 17, 2014 5:15 PM Subject: RE: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 2014, 17:00-19:00 UTC Hi Tom, we can for sure put 5539bis issues onto the agenda. @Juergen: Please jump in. Cheers, Mehmet From: ext Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, October 17, 2014 5:55 PM To: t.petch Cc: Ersue, Mehmet (NSN - DE/Munich); netconf Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 2014, 17:00-19:00 UTC On Fri, Oct 17, 2014 at 3:21 AM, t.petch > wrote: ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" > To: "netconf" > Sent: Thursday, October 16, 2014 7:53 PM > Dear NETCONF WG, > > our next NETCONF virtual interim meeting will take place on Monday, October 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time). > Below is the agenda and the issue list we plan to discuss. > > @All: Please read the issue descriptions in github and state your opinion concerning the possible solution as well as the way forward on the ML before the meeting. > @Draft authors: Please raise a discussion on concerning open issues and feedback you would like to have. You may also extend the agenda below as necessary. > > The co-chairs would also like to invite all people on NETCONF ML, but especially > > Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Luchuk, and Lada Lothka Mehmet, I hear you; trouble is, the agenda is not very appealing. I am a simple-minded man, who likes to progress in small steps and scope, or requirements, comes early on. Currently, I am unclear about how a NETCONF user will be authenticated, especially with TLS; once that is determined, I will feel able to comment more on 5539bis. After which, I can move on to the second half of call-home, which in turn determines what goes, or does not go, into server-model; while RESTCONF is not yet on my radar (I note that in Apps, there is some debate about RESTful and whether or not it is well-enough defined to talk about meaningfully). So when I see 50 minutes of RESTCONF followed by 50 minutes of server-model, I think that that is two hours of sitting and listening for me:-( How about if your issues were first? RESTCONF does not have to go first each time. Tom Petch Andy > > to join the virtual interim meeting and to contribute to the issue discussion. > Your participation is required and greatly appreciated. > Thank You! > > > Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC > ---------------------------------------------------------------------- ------------- > > - 5 min chair intro - recording the meeting?, scribe, agenda bashing > > - 50 min restconf open issues (Andy) > See https://github.com/netconf-wg/restconf/issues > > RESTCONF #3: add collection resource > https://github.com/netconf-wg/restconf/issues/3 > http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html > > RESTCONF #12: target resource list or leaf-list keys required for GET > https://github.com/netconf-wg/restconf/issues/12 > > Not on the tracker yet: > - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RFC? > - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for release 1? > > > - 40 min netconf-server model open issues (Kent) > see: https://github.com/netconf-wg/server-model/issues > > Issue #4: How to configure NETCONF server's SSH host-keys or TLS certificates > Issue #8: what other server config knobs are needed? > Issue #13: enable indirect Issuer authentications? > Issue #15: Should the "listen" and "call-home" lists have parent containers? > > - 20 min netconf-call-home open issues (Kent) > > Issue #3: Extend to support RESTCONF as well? > Issue #4: Have a call-home port? > > - 5 min AOB other topics > > > Please let the co-chairs know ASAP if you have comments or requests concerning the agenda. > > Following is the webex+audio info for the meeting: > > 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 > > Mehmet and Bert > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Oct 19 11:50: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 5916A1A1AF4 for ; Sun, 19 Oct 2014 11:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aGHescYxYQQ for ; Sun, 19 Oct 2014 11:50:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043A61A1AE2 for ; Sun, 19 Oct 2014 11:50:42 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9JIocKS008733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Oct 2014 18:50:38 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9JIobv2012956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 Oct 2014 20:50:37 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 19 Oct 2014 20:50:37 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 20:50:37 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext t.petch" Thread-Topic: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 2014, 17:00-19:00 UTC Thread-Index: AQHP6iK9EHfD0/+XU0CKDkI2k2ndRZw0dWSwgAAK0IeAA0TzQA== Date: Sun, 19 Oct 2014 18:50:36 +0000 Message-ID: References: <014601cfe9f5$57122520$4001a8c0@gateway.2wire.net> <0b7501cfea29$ebb06b40$4001a8c0@gateway.2wire.net> In-Reply-To: <0b7501cfea29$ebb06b40$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.157] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6664 X-purgate-ID: 151667::1413744638-0000437E-058E6E9E/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/z85tu9P7ZgN_ugiQx8Gw3zVEI0A Cc: netconf Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on October 20, 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: Sun, 19 Oct 2014 18:50:46 -0000 Agree basically. Though I think a discussion on X.509 usage in the interim = meeting will be valuable. BR, Mehmet=20 > -----Original Message----- > From: ext t.petch [mailto:ietfc@btconnect.com] > Sent: Friday, October 17, 2014 6:47 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: netconf; Juergen Schoenwaelder > Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual Interi= m on > October 20, 2014, 17:00-19:00 UTC >=20 > Mehmet >=20 > My sense is that we are heading towards X.509 certificates for client > and server authentication with NETCONF over TLS and that what it needs > is a consensus call to effect that. I don't think there is anything to > discuss, ar at least, not worth putting on the Agenda of a Virtual > Interim. And if, in a week or two, we have that consensus, then it is a > question of updating the three I-Ds to reflect that and seeing what > comes next. May be how to extract a user id will be then worth > discussing. >=20 > So it is probably right that the Virtual Interim focuses on RESTCONF > because I suspect that that is the area where discussions will be most > fruitful, just that I don't see anything I can contribute there at this > time. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > To: "ext Andy Bierman" ; "t.petch" > > Cc: "netconf" > Sent: Friday, October 17, 2014 5:15 PM > Subject: RE: [Netconf] Details about the Bi-weekly NETCONF Virtual > Interim on October 20, 2014, 17:00-19:00 UTC >=20 >=20 > Hi Tom, >=20 > we can for sure put 5539bis issues onto the agenda. >=20 > @Juergen: Please jump in. >=20 > Cheers, > Mehmet >=20 > From: ext Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, October 17, 2014 5:55 PM > To: t.petch > Cc: Ersue, Mehmet (NSN - DE/Munich); netconf > Subject: Re: [Netconf] Details about the Bi-weekly NETCONF Virtual > Interim on October 20, 2014, 17:00-19:00 UTC >=20 >=20 >=20 > On Fri, Oct 17, 2014 at 3:21 AM, t.petch > > wrote: > ----- Original Message ----- > From: "Ersue, Mehmet (NSN - DE/Munich)" > > > To: "netconf" > > Sent: Thursday, October 16, 2014 7:53 PM > > Dear NETCONF WG, > > > > our next NETCONF virtual interim meeting will take place on Monday, > October 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time). > > Below is the agenda and the issue list we plan to discuss. > > > > @All: Please read the issue descriptions in github and state your > opinion concerning the possible solution as well as the way forward on > the ML before the meeting. > > @Draft authors: Please raise a discussion on concerning open issues > and feedback you would like to have. You may also extend the agenda > below as necessary. > > > > The co-chairs would also like to invite all people on NETCONF ML, but > especially > > > > Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Luchuk, and > Lada Lothka >=20 > Mehmet, >=20 > I hear you; trouble is, the agenda is not very appealing. >=20 > I am a simple-minded man, who likes to progress in small steps and > scope, or requirements, comes early on. Currently, I am unclear about > how a NETCONF user will be authenticated, especially with TLS; once that > is determined, I will feel able to comment more on 5539bis. After > which, I can move on to the second half of call-home, which in turn > determines what goes, or does not go, into server-model; while RESTCONF > is not yet on my radar (I note that in Apps, there is some debate about > RESTful and whether or not it is well-enough defined to talk about > meaningfully). >=20 > So when I see 50 minutes of RESTCONF followed by 50 minutes of > server-model, I think that that is two hours of sitting and listening > for me:-( >=20 > How about if your issues were first? > RESTCONF does not have to go first each time. >=20 >=20 > Tom Petch >=20 > Andy >=20 > > > > to join the virtual interim meeting and to contribute to the issue > discussion. > > Your participation is required and greatly appreciated. > > Thank You! > > > > > > Agenda of the virtual interim meeting on October 20, 2014 1700-1900 > UTC > > ---------------------------------------------------------------------- > ------------- > > > > - 5 min chair intro - recording the meeting?, scribe, agenda bashing > > > > - 50 min restconf open issues (Andy) > > See https://github.com/netconf-wg/restconf/issues > > > > RESTCONF #3: add collection resource > > https://github.com/netconf-wg/restconf/issues/3 > > http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html > > > > RESTCONF #12: target resource list or leaf-list keys required for > GET > > https://github.com/netconf-wg/restconf/issues/12 > > > > Not on the tracker yet: > > - ietf-yang-library.yang in RESTCONF-02: Should this be in a > separate RFC? > > - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete > for release 1? > > > > > > - 40 min netconf-server model open issues (Kent) > > see: https://github.com/netconf-wg/server-model/issues > > > > Issue #4: How to configure NETCONF server's SSH host-keys or TLS > certificates > > Issue #8: what other server config knobs are needed? > > Issue #13: enable indirect Issuer authentications? > > Issue #15: Should the "listen" and "call-home" lists have parent > containers? > > > > - 20 min netconf-call-home open issues (Kent) > > > > Issue #3: Extend to support RESTCONF as well? > > Issue #4: Have a call-home port? > > > > - 5 min AOB other topics > > > > > > Please let the co-chairs know ASAP if you have comments or requests > concerning the agenda. > > > > Following is the webex+audio info for the meeting: > > > > To JOIN WEBEX MEETING > > > https://ietf.webex.com/ietf/j.php?MTID=3Dm9f461ea30a23d08e29f45c40c0814e7= d > > 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 > > > > Mehmet and Bert > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From nobody Sun Oct 19 11:51: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 0B2A21A1AF8 for ; Sun, 19 Oct 2014 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chr5iEUVkbfw for ; Sun, 19 Oct 2014 11:51:48 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15261A1AF4 for ; Sun, 19 Oct 2014 11:51:47 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9JIpjmR030554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 19 Oct 2014 18:51:45 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9JIpj9J014570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 19 Oct 2014 20:51:45 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Sun, 19 Oct 2014 20:51:45 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: Virtual Interim Agenda update WAS:FW: Details about the Bi-weekly NETCONF Virtual Interim on October 20, 2014, 17:00-19:00 UTC Thread-Index: AQHP6826mz2qYL2obkmWGkyrgBdsPA== Date: Sun, 19 Oct 2014 18:51:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.157] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4743 X-purgate-ID: 151667::1413744705-00001FC1-6FB47BE5/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/uQvlW4q_jiBp1qUX4m68jD6JAVA Subject: [Netconf] Virtual Interim Agenda update WAS:FW: Details about the Bi-weekly NETCONF Virtual Interim on October 20, 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: Sun, 19 Oct 2014 18:51:50 -0000 Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC ---------------------------------------------------------------------------= -------- - 5 min chair intro - recording the meeting?, scribe, agenda bashing - 10 min rfc5539bis and X.509 certificate authentication (Juergen) - 45 min restconf open issues (Andy) See https://github.com/netconf-wg/restconf/issues RESTCONF #3: add collection resource https://github.com/netconf-wg/restconf/issues/3 http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html RESTCONF #12: target resource list or leaf-list keys required for GET https://github.com/netconf-wg/restconf/issues/12 Not on the tracker yet: - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RF= C? - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for rel= ease 1? - 35 min netconf-server model open issues (Kent) see: https://github.com/netconf-wg/server-model/issues Issue #4: How to configure NETCONF server's SSH host-keys or TLS certifi= cates Issue #8: what other server config knobs are needed? Issue #13: enable indirect Issuer authentications? Issue #15: Should the "listen" and "call-home" lists have parent contain= ers? - 20 min netconf-call-home open issues (Kent) Issue #3: Extend to support RESTCONF as well? Issue #4: Have a call-home port? - 5 min AOB other topics Cheers,=20 Mehmet=20 -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Thursday, October 16, 2014 8:54 PM To: netconf Subject: [Netconf] Details about the Bi-weekly NETCONF Virtual Interim on O= ctober 20, 2014, 17:00-19:00 UTC Dear NETCONF WG, our next NETCONF virtual interim meeting will take place on Monday, October= 20th, 17:00-19:00 UTC (19-21 Amsterdam, Berlin time). Below is the agenda and the issue list we plan to discuss. @All: Please read the issue descriptions in github and state your opinion c= oncerning the possible solution as well as the way forward on the ML before= the meeting. @Draft authors: Please raise a discussion on concerning open issues and fee= dback you would like to have. You may also extend the agenda below as neces= sary. The co-chairs would also like to invite all people on NETCONF ML, but espec= ially=20 Tom Petch, Martin Bjorklund, Mahesh Jethhanandani, Alan Luchuk, and Lad= a Lothka to join the virtual interim meeting and to contribute to the issue discussi= on. Your participation is required and greatly appreciated.=20 Thank You! Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC ---------------------------------------------------------------------------= -------- - 5 min chair intro - recording the meeting?, scribe, agenda bashing - 50 min restconf open issues (Andy) See https://github.com/netconf-wg/restconf/issues RESTCONF #3: add collection resource https://github.com/netconf-wg/restconf/issues/3 http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html RESTCONF #12: target resource list or leaf-list keys required for GET https://github.com/netconf-wg/restconf/issues/12 Not on the tracker yet: - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RF= C? - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for rel= ease 1? - 40 min netconf-server model open issues (Kent) see: https://github.com/netconf-wg/server-model/issues Issue #4: How to configure NETCONF server's SSH host-keys or TLS certifi= cates Issue #8: what other server config knobs are needed? Issue #13: enable indirect Issuer authentications? Issue #15: Should the "listen" and "call-home" lists have parent contain= ers? - 20 min netconf-call-home open issues (Kent) Issue #3: Extend to support RESTCONF as well? Issue #4: Have a call-home port? - 5 min AOB other topics Please let the co-chairs know ASAP if you have comments or requests concern= ing the agenda. Following is the webex+audio info for the meeting: To JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=3Dm9f461ea30a23d08e29f45c40c0814= 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 Mehmet and Bert _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Oct 19 13:26:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DF81A6F85 for ; Sun, 19 Oct 2014 13:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TXxfqIRlCie for ; Sun, 19 Oct 2014 13:26:22 -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 E482E1A6F82 for ; Sun, 19 Oct 2014 13:26:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3BD588A5; Sun, 19 Oct 2014 22:26:20 +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 2eETbXwRYtCm; Sun, 19 Oct 2014 22:26:18 +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, 19 Oct 2014 22:26:19 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EBBD20037; Sun, 19 Oct 2014 22:26: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 EIVzfVg82xdC; Sun, 19 Oct 2014 22:26:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58D9720035; Sun, 19 Oct 2014 22:26:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 23B652F0307A; Sun, 19 Oct 2014 22:26:16 +0200 (CEST) Date: Sun, 19 Oct 2014 22:26:16 +0200 From: Juergen Schoenwaelder To: Qin Wu Message-ID: <20141019202616.GA85744@elstar.local> Mail-Followup-To: Qin Wu , "t. petch" , "netconf@ietf.org" References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> <20141010.212225.300681995.mbj@tail-f.com> <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> <20141014130900.GA70425@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/1j0mvjEe9tHUtUDCG5_o0VTi54g Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 19 Oct 2014 20:26:23 -0000 On Thu, Oct 16, 2014 at 09:13:02AM +0000, Qin Wu wrote: > > I was pushing for PSK authentication back in a day when we did NC light. I think it is meanwhile clear that NC light is not a viable option and hence I proposed to remove PSK authentication at the Toronto meeting as not many people seem to care to implement this (slide #7 of my slide set). Perhaps the chairs should do an explicit call for concensus on this so that we can move on. > > [Qin]: Are you saying constrained device will not be supported by this draft? > You need to say more clearly what you mean with 'constrained devices' before I can answer 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 Sun Oct 19 23:30:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D631A0378 for ; Sun, 19 Oct 2014 23:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeO7UhApjHux for ; Sun, 19 Oct 2014 23:30: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 3E31F1A1BE3 for ; Sun, 19 Oct 2014 23:30:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 97A2C8D1; Mon, 20 Oct 2014 08:30: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 dRDOJjAQnJBg; Mon, 20 Oct 2014 08:30: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; Mon, 20 Oct 2014 08:30:21 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAF7F20037; Mon, 20 Oct 2014 08:30:20 +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 GU1tCq-M1x7H; Mon, 20 Oct 2014 08:30:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B139E20035; Mon, 20 Oct 2014 08:30:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C750E2F03BAD; Mon, 20 Oct 2014 08:30:18 +0200 (CEST) Date: Mon, 20 Oct 2014 08:30:18 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20141020063018.GB86545@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , netconf References: <20141016.223457.371317785.mbj@tail-f.com> <20141017.091618.679582233883996238.mbj@tail-f.com> 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/B70OW15kZRP_E6OW9KWFX2Isl-8 Cc: netconf 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: Mon, 20 Oct 2014 06:30:25 -0000 On Fri, Oct 17, 2014 at 03:20:39PM +0000, Kent Watsen wrote: > > > >Why do we have specified host-keys for callhome, but not for the > >normal netconf server case? And should we really have separate > >host-keys for callhome and normal server? > > For zero-touch, which uses call home, it is critical that an X.509-based > host-key is the *only* host-key advertised, as the client needs it to > automatically authenticate the device. Normal SSH typically uses RSA or > DSA host-keys; the server could also advertise an X.509-based key, but > it's not required. > Call home requires an X.509-based host-key? If so, why? /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 Oct 20 08:16: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 089F51A8871 for ; Mon, 20 Oct 2014 08:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 eJwGkrj__XcC for ; Mon, 20 Oct 2014 08:15:55 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8570C1A01AE for ; Mon, 20 Oct 2014 07:58:06 -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 KAA07248 for ; Mon, 20 Oct 2014 10:58:05 -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 s9KEw5sn064084 for ; Mon, 20 Oct 2014 10:58:05 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id s9KEw5Qm064083; Mon, 20 Oct 2014 10:58:05 -0400 (EDT) (envelope-from luchuk) Date: Mon, 20 Oct 2014 10:58:05 -0400 (EDT) From: Alan Luchuk Message-Id: <201410201458.s9KEw5Qm064083@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/x41LWdndlcfFqjTvJiRsZK_i448 Subject: Re: [Netconf] rfc5539bis 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, 20 Oct 2014 15:16:00 -0000 Hello, Related to RFC 5539bis and NETCONF over TLS using X.509 certificates, the intent was to largely reuse the mechanisms described in RFC 6353 for generating SNMP security names from X.509 certificates. Devising a new and different scheme for NETCONF over TLS seems unproductive. For those who may be unfamiliar with RFC 6353, the basic ideas are summarized below. In RFC 6353, both ends mutually authenticate. This assures the server of the identity of who wishes to manipulate the management information. It assures the client of the identity of the server for which it wishes to manipulate the management information. Both ends use X.509 certificate path validation to verify the integrity of the application certificate presented by its peer. The server uses three additional steps to control the access to the management information: S1) The application certificate presented by the client must be recognized by the server; S2) The application certificate presented by the client must be transformable by the server to a valid security name; and S3) The resulting security name must be authorized to access management information. The client uses an additional step to verify the identity of the server for which it wishes to manipulate the management information: C1) The application certificate presented by the client must be recognized by the server; -or- C2) Some piece of identifying information bound within the application certificate must match what the client is expecting. To implement item S1, the fingerprint of the received application certificate must be preconfigured in a table of recognized certificates. To implement item S2, the table of recognized certificates must specify a transformation to a valid security name. To implement item S3, the security name generated from the transformation must be allowed access to the management information. To implement item C1, the fingerprint of the application certificate the client expects to receive from the server must be be known to the client _before_ the connection is attempted. If the fingerprint does not match the fingerprint the client expects, then the connection is failed. To implement item C2, the piece of identifying information the client expects to receive from the server must be be known to the client _before_ the connection is attempted. If the piece of identifying information does not match the client expects, then the connection is failed. Typically this identifying information is something like the DNS name(s) or IP address(es) of the server. 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 Oct 21 07:38: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 9B4A61A6F0B for ; Tue, 21 Oct 2014 07:38:36 -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 ihIcSy__IGfQ for ; Tue, 21 Oct 2014 07:38:33 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::760]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86851A6F67 for ; Tue, 21 Oct 2014 07:38:32 -0700 (PDT) Received: from pc6 (86.184.62.161) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 21 Oct 2014 14:38:09 +0000 Message-ID: <03ae01cfed3c$50d39d20$4001a8c0@gateway.2wire.net> From: t.petch To: Alan Luchuk , References: <201410201458.s9KEw5Qm064083@mainfs.snmp.com> Date: Tue, 21 Oct 2014 15:35:44 +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.62.161] X-ClientProxiedBy: DB4PR02CA0040.eurprd02.prod.outlook.com (10.242.174.168) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0371762FE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(377454003)(13464003)(51704005)(21056001)(101416001)(99396003)(77096002)(95666004)(87286001)(93916002)(106356001)(86362001)(107046002)(120916001)(85852003)(4396001)(15202345003)(97736003)(116806002)(105586002)(50226001)(85306004)(14496001)(92726001)(87976001)(92566001)(88136002)(50466002)(76482002)(102836001)(19580405001)(33646002)(77156001)(104166001)(61296003)(19580395003)(23756003)(50986999)(89996001)(64706001)(44736004)(42186005)(62966002)(15975445006)(107886001)(46102003)(80022003)(76176999)(20776003)(47776003)(40100003)(81686999)(62236002)(44716002)(66066001)(31966008)(81816999)(122386002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; 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/VKae0jLu9Vr_v1_qH18bDkp5JP8 Subject: Re: [Netconf] rfc5539bis 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, 21 Oct 2014 14:38:36 -0000 ----- Original Message ----- From: "Alan Luchuk" To: Sent: Monday, October 20, 2014 3:58 PM > Hello, > > Related to RFC 5539bis and NETCONF over TLS using X.509 certificates, the > intent was to largely reuse the mechanisms described in RFC 6353 for > generating SNMP security names from X.509 certificates. Devising a new > and different scheme for NETCONF over TLS seems unproductive. For those > who may be unfamiliar with RFC 6353, the basic ideas are summarized below. Alan I broadly agree, once we have decided what forms of authentication NETCONF over TLS will use. If that is only X.509 certificates, then the next question is where to put the text about it. SNMP has the data model integral with the procedural specification, NETCONF does not, so it is likely that the protocol goes into rfc5539bis but what you then do with it goes into netconf-server, for the server, and into ???, for the client. Which, as Juergen pointed out, is not ideal but is probably the best we can do. And NETCONF has not specified access control in the same way as SNMP has done so that will be different too. So I broadly agree with you but do want that agreement on what authentication is valid before going further - I like to progress one step at a time. Tom Petch > > In RFC 6353, both ends mutually authenticate. This assures the server > of the identity of who wishes to manipulate the management information. > It assures the client of the identity of the server for which it wishes > to manipulate the management information. > > Both ends use X.509 certificate path validation to verify the integrity > of the application certificate presented by its peer. > > The server uses three additional steps to control the access to the > management information: > > S1) The application certificate presented by the client must be > recognized by the server; > > S2) The application certificate presented by the client must be > transformable by the server to a valid security name; and > > S3) The resulting security name must be authorized to access > management information. > > The client uses an additional step to verify the identity of the server > for which it wishes to manipulate the management information: > > C1) The application certificate presented by the client must be recognized > by the server; -or- > > C2) Some piece of identifying information bound within the application > certificate must match what the client is expecting. > > > To implement item S1, the fingerprint of the received application > certificate must be preconfigured in a table of recognized certificates. > To implement item S2, the table of recognized certificates must specify > a transformation to a valid security name. To implement item S3, the > security name generated from the transformation must be allowed access > to the management information. > > To implement item C1, the fingerprint of the application certificate > the client expects to receive from the server must be be known to the > client _before_ the connection is attempted. If the fingerprint does > not match the fingerprint the client expects, then the connection is > failed. > > To implement item C2, the piece of identifying information the client > expects to receive from the server must be be known to the client > _before_ the connection is attempted. If the piece of identifying > information does not match the client expects, then the connection is > failed. Typically this identifying information is something like the > DNS name(s) or IP address(es) of the server. > > > 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/ > --------------------------------------------------------------------- --------- > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Oct 21 08:35: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 1F49C1A8746 for ; Tue, 21 Oct 2014 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFKwWjlir9Zy for ; Tue, 21 Oct 2014 08:35:06 -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 E35661A870A for ; Tue, 21 Oct 2014 08:35:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6B7D18F4; Tue, 21 Oct 2014 17:35: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 iQ1TgwE4Jo0b; Tue, 21 Oct 2014 17:35: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; Tue, 21 Oct 2014 17:35:03 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66DD620037; Tue, 21 Oct 2014 17:35:03 +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 Tp3Hy2tPlSt7; Tue, 21 Oct 2014 17:34:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A5CD20035; Tue, 21 Oct 2014 17:35:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 667DC2F0773F; Tue, 21 Oct 2014 17:34:58 +0200 (CEST) Date: Tue, 21 Oct 2014 17:34:55 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20141021153455.GA91264@elstar.local> Mail-Followup-To: "t. petch" , Alan Luchuk , netconf@ietf.org References: <201410201458.s9KEw5Qm064083@mainfs.snmp.com> <03ae01cfed3c$50d39d20$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03ae01cfed3c$50d39d20$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zLVuUe50GnmqQHhgXFhYGYjZSw8 Cc: netconf@ietf.org Subject: Re: [Netconf] rfc5539bis 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, 21 Oct 2014 15:35:08 -0000 On Tue, Oct 21, 2014 at 03:35:44PM +0100, t. petch wrote: > ----- Original Message ----- > From: "Alan Luchuk" > To: > Sent: Monday, October 20, 2014 3:58 PM > > Hello, > > > > Related to RFC 5539bis and NETCONF over TLS using X.509 certificates, > the > > intent was to largely reuse the mechanisms described in RFC 6353 for > > generating SNMP security names from X.509 certificates. Devising a > new > > and different scheme for NETCONF over TLS seems unproductive. For > those > > who may be unfamiliar with RFC 6353, the basic ideas are summarized > below. > > Alan > > I broadly agree, once we have decided what forms of authentication > NETCONF over TLS will use. > > If that is only X.509 certificates, then the next question is where to > put the text about it. SNMP has the data model integral with the > procedural specification, NETCONF does not, so it is likely that the > protocol goes into rfc5539bis but what you then do with it goes into > netconf-server, for the server, and into ???, for the client. Which, as > Juergen pointed out, is not ideal but is probably the best we can do. > > And NETCONF has not specified access control in the same way as SNMP has > done so that will be different too. > > So I broadly agree with you but do want that agreement on what > authentication is valid before going further - I like to progress one > step at a time. RFC 5539 has used X.509 certificates and nobody seems to request any changes. Why do you make this complicated? Yes, NC access control is different from SNMP access control but this is irrelevant. All the transport has to deliver is a user name. Why do we have to make this complicated? /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 Oct 21 08: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 650A01A88B4 for ; Tue, 21 Oct 2014 08:51:25 -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 orDSrMbpEIW1 for ; Tue, 21 Oct 2014 08:51:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0147.outbound.protection.outlook.com [65.55.169.147]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF52D1A8882 for ; Tue, 21 Oct 2014 08:51: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.1049.19; Tue, 21 Oct 2014 15:51:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) with mapi id 15.00.1049.012; Tue, 21 Oct 2014 15:51:18 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] Comments on draft-ietf-netconf-server-model-03.txt Thread-Index: AQHP3PfuIWXKEogrdkyrjScW4AT0uZwefEcAgBTLFYCAAA7SAIAApF8AgABEQICABGXkAIAB7AuA Date: Tue, 21 Oct 2014 15:51:17 +0000 Message-ID: References: <20141016.223457.371317785.mbj@tail-f.com> <20141017.091618.679582233883996238.mbj@tail-f.com> <20141020063018.GB86545@elstar.local> In-Reply-To: <20141020063018.GB86545@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-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(20776003)(101416001)(110136001)(92726001)(31966008)(85306004)(64706001)(92566001)(86362001)(230783001)(66066001)(120916001)(77096002)(46102003)(21056001)(36756003)(2656002)(99396003)(85852003)(50986999)(54356999)(93886004)(4396001)(76176999)(76482002)(105586002)(87936001)(80022003)(122556002)(97736003)(40100003)(95666004)(106356001)(107046002)(106116001)(99286002); 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: 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/Kany2weiASPKsUzlC_qeNLIXJbs 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 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:51:25 -0000 > Call home requires an X.509-based host-key? If so, why? No, draft-ieft-netconf-call-home does not require X.509 based host-keys. Further, the next version of draft-ietf-netconf-server-model will show that the host-keys can be any standard SSH host-key. The requirement for X.509 host-keys is only in draft-ietf-netconf-zero-touch. This use of call-home (e.g. zero-touch) places a requirement on the NETCONF server's host-key being something that encodes both an identity as well as a chain of trust (e.g., PKI), hence X.509. =20 FWIW, we could try to also support PGP-based host-keys (defined in RFC 4253), but I don't think PGP is used much anymore (if ever) as a SSH host-key, and so I rather not invest the effort to update the draft to support PGP keys too. Thanks, Kent From nobody Tue Oct 21 20:32: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 D1CB81A8A76 for ; Tue, 21 Oct 2014 20:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_JXihJzekJA for ; Tue, 21 Oct 2014 20:32:52 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA721A8A70 for ; Tue, 21 Oct 2014 20:32:52 -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.1049.19; Wed, 22 Oct 2014 03:32:49 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) with mapi id 15.00.1049.012; Wed, 22 Oct 2014 03:32:49 +0000 From: Kent Watsen To: Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] review of draft-ietf-netconf-zerotouch-00 Thread-Index: AQHPpsoH8lNfmq9s1k26R1Lt7oe1kpw7wR8A Date: Wed, 22 Oct 2014 03:32:49 +0000 Message-ID: References: <20140723.190110.325781546.mbj@tail-f.com> In-Reply-To: <20140723.190110.325781546.mbj@tail-f.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.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(52314003)(51704005)(51444003)(199003)(99286002)(92726001)(101416001)(86362001)(122556002)(15975445006)(36756003)(76482002)(95666004)(99396003)(230783001)(87936001)(76176999)(50986999)(106356001)(19580395003)(2656002)(106116001)(4396001)(54356999)(83506001)(105586002)(107886001)(92566001)(107046002)(66066001)(20776003)(120916001)(77096002)(64706001)(97736003)(40100003)(31966008)(85306004)(2501002)(85852003)(21056001)(80022003)(46102003); 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: <4C7CFF259A2AEF4FA95873DAF62EA6E9@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/r2AE8GxsDxtbU6YpsJp-qDcGc9E Subject: Re: [Netconf] review of draft-ietf-netconf-zerotouch-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: Wed, 22 Oct 2014 03:32:57 -0000 A late response, but I've been focused on call-home and server-model...and there were very few comments on zero-touch. Anyway, here goes! Kent >o sec. 1.4 > > Vendors are the de facto Configuration Signer > for the devices it manufactures, but may delegate that role to > external Configuration Signers. > > What eactly do you mean with "de facto Configuration Signer" in this > case? "de facto " =3D=3D preordained root of trust. The vendor itself is the ultimate root of trust for the devices it manufactures. Is there a better way to say this? >o sec. 1.4 > > Also mention boot images in your list and in the diagram. Ah yes, boot-images came in late and I missed adding them here. Fixed in my local copy. >o sec. 2 > > This section describes the service > interface a Configuration Server must implement as well as what's > needed for transport security. > > s/must/MUST/ ? Unclear to me, but if you're calling it out now, I'll make the change to be safe. >o sec 2.1 > > The term IDevID is used for the first time here. It would probably > be a good idea to mention this term in a Terminology section. Can I add a ", which is described in Section 4.2." instead? This draft doesn't have a terminology section as of yet... - actually, I don't any of my drafts do >o sec 2.3 > > Therefore, it is RECOMMENDED for > Configuration Servers to support transport-level encryption. > > Doesn't this contradict section 2.1 which says that https MUST be > supported? > > Maybe you mean that it is RECOMMENDED that _devices_ use > transport-level encryption? Yes, or even more specifically, that only "https" URIs are used (no "http") Fixed. >o sec 2.4 > > An expiration policy is needed to limit how long a Configuration > Server needs to retain a configuration and, in turn, how many > configurations it might need to retain at a given time. > > I do not understand this sentence. Why is the expiration policy > needed? What does the number of configs it retains has to do with > anything? To your point, it's not germane to the focus of the draft, but I did receive a comment from someone who was concerned that the Configuration Server would have to hold onto all Configlets (and boot-images) for perpetuity. Rather than remove the section from the draft, can we provide the above context so as to clarify why it's mentioned? >o sec 3. > > Terminology: "Configuration Signer" vs. "Configlet Signer". Fixed this and all other instances of "Configlet Signer" (now they all say "Configuration Signer") >o sec 4.2 > > The picture says "IDevID entity". What is this entity? The line is intended to be expanded to read "IDevID entity *certificate* and associated intermediate certificates". I'm trying to economize space so it'll fit within the 72-column limit. Or is your question more generally what is an IDevID, as defined in the subsequent paragraph? >o sec 4.2 > > Devices supporting ZeroTouch MUST be pre-provisioned with one or more > URIs for Internet-based Configuration Servers. > > Why is this a MUST? (or why "one or more"?). It seems to me that > the DHCP option could be used instead of manual pre-provisioning. > > Do you expect these config server URIs to be part of the normal > config? See more below. The DHCP option is only effective for the "locally administered network" use case (see section 1.3). When the network is administered remotely, the DHCP option is very unlikely to be set and therefore the device will have no resource but to fallback to trying URIs. Makes sense? Instead of "one or more" I could put "at least one" - is it better? >o sec 4.2 > > confidentially and not available outside the DevID module > > What is "DevID module"? This sentence is based on Section 6.2.5 (Storage) of the 802.1AR spec, which that sentence references just before the section you clipped out. It refers to the cryptographic boundary defined by the specification. Two options: 1. Call out more specifically section 6.2.5 2. Replace the term "IDevID module" with simple text meaning the same thing >o sec 4.3 > > The test is: [if running config !=3D factory default, boot normally] > > So if the user has done any local configuration, e.g. configured the > Configuration Servers, it means that zerotouch won't be used? Correct. At that point the device has been *configured* and thus zero-touch is disabled. >o sec 4.3 > > I think that the picture and text could use some numbering of the > steps to make it easier to follow, i.e., number ot match the text > with the diagram. Yes, a lot of feedback on this diagram being difficult to follow. Your suggestion is the best I've heard yet, so I'll try it. Won't be easy, though, as I've already at the 72-column limit... Added https://github.com/netconf-wg/zero-touch/issues/1 (since I'm not doing it right now) >o sec 4.3 > > You introduce the term GUID w/o explanation. True, I refer to it as UID earlier. Fixed. >o sec 4.3 > > However, since the Configlet configured > the device to "call home," upon entering its normal operating mode, > the device immediately begins trying to establish a call home > connection, as specified by the Configlet. > >s/However, since the Configlet configured/ > However, if the Configlet configured/ ? > >It seems to me this process can be used w/o call home as well. Yes, since we changed the Configlet payload to anyxml, there is nothing left saying that the Configlet has to result in a call-home connection, though that is the entire point of the draft. Nonetheless, I'll update the text to be more accommodating... >o sec 5.1 > > You have the list of expected device identifiers in immutable > storage - that seems to indicate that it not possible to ever add a > new device! I think you mean section 5.2. Nonetheless, to your point, the diagram is trying to express storage attributes from the perspective of an entity outside the module (the NMS in this case). An outsider cannot write the immutable storage and cannot read or write secure storage. Anyway, that's what I meant by this diagram and also the one in section 4.2. Is it OK? >o sec 6.1. > > s/preconfigure/configure/ ? Fair enough. Though it needs to be done prior to the commencement of ZeroTouch, I agree that it doesn't need to be hinted at here this way. >o sec 6.2 > > Should this step also be in the diagram in 1.4? Added! >o sec 7.1. > > The second paragraph should probably be removed. This was a hold-over from when the Configlet did assert call-home config. Instead of deleting the paragraph, I instead now have: The Configlet data-model, defined by the YANG module in Section 7.5, contains information for the device to ensure that it's safe for it to load the configlet (target-requirements) along with a payload, the configuration the device is to merge into its running datastore. In order for the device to call-home, the configuration contained within the Configlet MUST at least configure a local user account and configure the connection information for the NMS the device is to call home to. This configuration MAY use IETF-defined modules "ietf- system" in [RFC7317] and "ietf-netconf-server" in [NETCONF-SERVER-MODEL]. Better? >o sec 7.2 > > The term "unique-identifier" is pretty generic. Should it simply be > "device-identifier" instead? > > Also, here you are using "DevID". Did you mean "IDevID"? If not, > you need to explain the difference. True, but "unique-identifier" or "UID" is used throughout the draft, and both the text and the YANG module state exactly what it needs to be. As for DevID vs IDevID. The IEEE spec defines the general DevID, which is then refined into IDevID ('I' for "Initial") and LDevID ('L' for "Local"). So, it's not overstepping too far. Still, for ZeroTouch, I think we're only ever interested in the IDevID and so I'll s/ DevID/ IDevID/g (3 substitutions) >o sec 7.2 > > If the device finds that it is > not running the correct version of software, it can pull the > correct version from the Configuration Server. > > "can pull" - section 4.3 had "MUST". Good catch, this is fixed. >o sec 7.5 > > You define a "container configlet". With YANG version 1, I think it > is better to follow the restconf example and define a grouping with > this container: >=20 > grouping configlet { > container configlet { ... } > } > > and explain that the grouping is not intended to be used. > > (side note: maybe we should have an explicit statement for this in > YANG 1.1; it seems we have the need for it, since we use this hack > already in several places) This dovetails into Andy's comments captured in the IETF90 minutes: "This creates a top-level mandatory node, it should be presence container." To be honest, I still don't get what the issue is. We never expect a NETCONF server to advertise this YANG module, so there should be no concern for anyone thinking this is actually configuration. Here, I'm only using YANG to describe a file format, in which this top-level container is very much needed. I mentioned before that I could instead use XSD to describe this XML file-format (no JSON!). I only picked YANG initially because I very much was trying to reference the ietf-system and ietf-netconf-server modules, but now that is no longer the case, I'm beginning to think XSD is more appropriate. What do you think? Added https://github.com/netconf-wg/zero-touch/issues/2 >o sec 7.5, leaf unique-identifier > > This means that it is not possible to have a single configlet for > all devices of a certain type. Is this necessary? Correct, and I wish it weren't the case, but without this there is an easy substitution attack whereby a nefarious individual obtains a Configlet for an authorized device and yet loads it into an authorized device. The only way to remove this constraint is to assert that only HTTPS (not HTTP) is used and that the device authenticates the HTTPS server's certificate. But doing this would complicate use of the ZeroTouch DHCP option, as then the locally-deployed HTTPS server would have to have a certificate signed by a CA known to the device (e.g., VeriSign, RSA, Thwart, etc.), but it might be difficult for vendors to know-of or even keep-up with this changing list. This is why HTTP (without the 'S') is supported at all, to simplify use in internal networks. >o sec 7.5, leaf software-version > > "The device MUST must be running this version of software. > The value for this field is device-specific, but it MUST > be an exact match (e.g., 14.1R2.5)"; > > Why is this MUST be exact match? It seems inflexible to me. Since > the field is vendor specific anyway, why not let the match > algorithm be vendor specific as well? > > Also, should this really be mandatory? This is a tough question. On one hand, we have cases where the Configlet is using vendor-specific data-models (not ietf-system and ietf-netconf-server), and hence is specific to a software release...or at least generated using a specific revision of the vendor-specific module. It *might* work with other versions, we only know for sure that it will work on the specific version. If the NETCONF server is namespace-aware, it likely results in it only supporting exact matches. Of course, SDO-defined modules are used, there is a greater likelihood that more than one version can support it. Then there is the case of expectations, the NMS very likely requires the device to be running a very specific software version, as it is what has been qualified for production. If the device doesn't so up with an exact match, the NMS will have to first push the correct image to the device. Yes, it could be done, but why should NMSs have to do this if the network infrastructure can do it for them? Thoughts? >o sec 8.2 > > Remove the text about how a timestamp *could* be used? But this is the Security Considerations section and clock-based attacks are not uncommon. What is your suggestion? >o signing / encrypting configlets > > I think you need to specify somewhere how the signature is inserted > into the configlet XML document. Currently the only hint the reader > get is from an example... > > Same for encryption, and in this case the example is also tbd. Did you see sections 7.3 (Signature) and 7.4 (Encryption)? Are you looking for something like a tutorial that starts with an unsigned Configlet and then signs it with a key and then shows the resulting signed Configlet? I agree that the encryption example needs to be filled in. Added https://github.com/netconf-wg/zero-touch/issues/3 >o sec A.1 > > This comment is related to the netconf-server data model. > > In this example teh configlet pushes a config with host keys, > referred to by file name. How does the device get these keys? This was discussed in yesterday's virtual meeting - now there will be config=3Dfalse lists of the server's SSH host-keys and TLS certificates, so that this can then become an instance-identifier. >Editorial: >---------- > >o sec. 1.4 > >OLD: > > The device > is preconfigured with a secure device identity, for > Configuration Servers URIs, and certificates for Configuration > Signers and Configuration Servers it trusts by default. > >NEW: > > The device > is preconfigured with a secure device identity, > Configuration Servers URIs, and certificates for Configuration > Signers and Configuration Servers it trusts by default. Fixed. >o sec 2 > > s/The unique identifies/The unique identifier/ Had gotten this one already, but thanks anyway >o sec 2.2 > >OLD: > > The Configuration server SHOULD to provide some user-facing interface > to enable to the end-user to provide a Configlet and, optionally, an > bootimage file. > >NEW: > > The Configuration server SHOULD provide some user-facing interface > to enable the end-user to provide a Configlet and, optionally, a > bootimage file. Egads, how did that one get past the editor? ;) >o sec 3.4 > >s/may prefer a this role be/may prefer that this role be/ Fixed. >o sec 4.3 > > s/MAY also try both the raw/MAY also try the raw/ Fixed. >o sec 5.1 > >s/either a SSH/either SSH/ Fixed. >o sec 7.5, leaf configuration > >OLD: > support both the following standard data-models: > >NEW: > > support the following standard data-models: Fixed. From nobody Wed Oct 22 11:30: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 847201ACF5C for ; Wed, 22 Oct 2014 11:30: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 7-4F6tskmnVS for ; Wed, 22 Oct 2014 11:29:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7484D1ACF5B for ; Wed, 22 Oct 2014 11:29:59 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Wed, 22 Oct 2014 18:29:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) with mapi id 15.00.1049.012; Wed, 22 Oct 2014 18:29:36 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "t. petch" Thread-Topic: [Netconf] rfc5539bis Thread-Index: AQHP7HjHf9V5xBNPv0yjz+04P12ZX5w6oH4SgAAPsICAAYAUgA== Date: Wed, 22 Oct 2014 18:29:35 +0000 Message-ID: References: <201410201458.s9KEw5Qm064083@mainfs.snmp.com> <03ae01cfed3c$50d39d20$4001a8c0@gateway.2wire.net> <20141021153455.GA91264@elstar.local> In-Reply-To: <20141021153455.GA91264@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.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(51704005)(36756003)(107046002)(85306004)(77096002)(64706001)(95666004)(106356001)(80022003)(106116001)(40100003)(66066001)(46102003)(99286002)(20776003)(105586002)(31966008)(76482002)(2656002)(83506001)(101416001)(50986999)(87936001)(85852003)(54356999)(99396003)(76176999)(97736003)(120916001)(21056001)(4396001)(122556002)(86362001)(92566001)(92726001)(7059028); 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-Js1eybRB2SPRiDmkPIbxYCZ-xQ Cc: "netconf@ietf.org" Subject: Re: [Netconf] rfc5539bis 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, 22 Oct 2014 18:30:01 -0000 >RFC 5539 has used X.509 certificates and nobody seems to request any >changes. Why do you make this complicated? > >Yes, NC access control is different from SNMP access control but this >is irrelevant. All the transport has to deliver is a user name. Why do >we have to make this complicated? I kind of agree with both sides. On one hand, 5539bis-06 clearly intends to define mutual certificate-based authentication - just search for the word "mutual". Additionally, Juergen already explained that he put PSK in (-02, according to the change log ) to support NETCONF-light, and since took it out. So we're essentially back to just trying to clean up 5539 and make it be in-line with NETCONF 1.1.=20 On the other hand, there are a couple issues with 5539bis-06: 1) section 2.4.2 (Client Identity) doesn't actually say that certificate-based authentication is required. For instance, this text from RFC5539 was left out: "with certificate-based authentication according to local policy" 2) I'm confused by these seemingly conflicting statements: - section 2.4 (X.509-based Authentication...) says "Implementations MAY optionally support TLS certificate-based authentication" - section 2.5 (Cipher Suites) says "However, implementations MUST support TLS 1.2". =20 So, to Juergen's point, I don't think this needs to be complicated, but I do think we need to be methodical about ensuring the text says what we want it to say. One last point, I'm opposed to 5539bis using draft-ietf-netconf-server-model as a Normative Reference. I believe that 5539bis should define the protocol on its own, and view draft-ietf-netconf-server-model as just one data-model that could configure it. FWIW, neither 6242 nor draft-ietf-netconf-call-home have a Normative Reference draft-ietf-netconf-server-model. Thanks, Kent From nobody Wed Oct 22 13:36: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 15B561A1B07; Wed, 22 Oct 2014 13:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DSp1p7mg8GMV; Wed, 22 Oct 2014 13:36:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7881A19F7; Wed, 22 Oct 2014 13:36:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022203624.17928.55068.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 13:36:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xNvDT5IHSgQFZAIGW2Y_WprclLE Cc: netconf@ietf.org Subject: [Netconf] UPDATE Re: NETCONF WG Bi-Weekly Virtual Interim Meetings beginning September 8, 2014 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 20:36:27 -0000 Please note that the last meeting of the NETCONF WG virtual meeting series announced below has been canceled. The meeting on November 3, 2014 will not take place. On 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 3, 2014. > From nobody Thu Oct 23 02:06: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 DE1681A1A2C for ; Thu, 23 Oct 2014 02:06:52 -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 ZWhkG1GeANvB for ; Thu, 23 Oct 2014 02:06:50 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::796]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B526F1A8910 for ; Thu, 23 Oct 2014 02:06:49 -0700 (PDT) Received: from pc6 (86.184.62.161) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 23 Oct 2014 09:06:26 +0000 Message-ID: <021801cfeea0$4d7ab860$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Juergen Schoenwaelder References: <201410201458.s9KEw5Qm064083@mainfs.snmp.com> <03ae01cfed3c$50d39d20$4001a8c0@gateway.2wire.net> <20141021153455.GA91264@elstar.local> Date: Thu, 23 Oct 2014 10:04:00 +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.62.161] X-ClientProxiedBy: DB4PR05CA0021.eurprd05.prod.outlook.com (25.160.40.31) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-Forefront-PRVS: 0373D94D15 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(13464003)(51704005)(189002)(377454003)(23756003)(76482002)(99396003)(102836001)(92566001)(46102003)(86362001)(50986999)(21056001)(19580395003)(81686999)(122386002)(93886004)(76176999)(19580405001)(87286001)(84392001)(92726001)(120916001)(77156001)(14496001)(97736003)(106356001)(93916002)(80022003)(95666004)(88136002)(101416001)(105586002)(62236002)(64706001)(4396001)(44716002)(62966002)(42186005)(50226001)(31966008)(20776003)(44736004)(47776003)(50466002)(33646002)(40100003)(77096002)(116806002)(89996001)(81816999)(85852003)(61296003)(85306004)(87976001)(66066001)(107046002)(104166001)(7059028); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB059; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7tQ6bKrnMmn5OWyGh3bSB2J8OeM Cc: netconf@ietf.org Subject: Re: [Netconf] rfc5539bis 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, 23 Oct 2014 09:06:53 -0000 ---- Original Message ----- From: "Kent Watsen" To: "Juergen Schoenwaelder" ; "t. petch" Cc: Sent: Wednesday, October 22, 2014 7:29 PM >RFC 5539 has used X.509 certificates and nobody seems to request any >changes. Why do you make this complicated? > >Yes, NC access control is different from SNMP access control but this >is irrelevant. All the transport has to deliver is a user name. Why do >we have to make this complicated? I kind of agree with both sides. On one hand, 5539bis-06 clearly intends to define mutual certificate-based authentication - just search for the word "mutual". Additionally, Juergen already explained that he put PSK in (-02, according to the change log ) to support NETCONF-light, and since took it out. So we're essentially back to just trying to clean up 5539 and make it be in-line with NETCONF 1.1. On the other hand, there are a couple issues with 5539bis-06: 1) section 2.4.2 (Client Identity) doesn't actually say that certificate-based authentication is required. For instance, this text from RFC5539 was left out: "with certificate-based authentication according to local policy" 2) I'm confused by these seemingly conflicting statements: - section 2.4 (X.509-based Authentication...) says "Implementations MAY optionally support TLS certificate-based authentication" - section 2.5 (Cipher Suites) says "However, implementations MUST support TLS 1.2". So, to Juergen's point, I don't think this needs to be complicated, but I do think we need to be methodical about ensuring the text says what we want it to say. Kent This is what I keep saying or at least, try to say - not sure how clear I am being. But until those loose ends of text are removed, then 5539bis remains ambiguous IMHO (and I then remain reluctant to move on to other issues and other I-Ds). I would go slightly further and change the title and Intro. Martin raised the point about this I-D seeming to exclude other forms of authentication with TLS so I would entitle this one " Using the NETCONF Protocol over Transport Layer Security (TLS) with X.509 Certificates" Then anyone is free to write another I-D entitled " Using the NETCONF Protocol over Transport Layer Security (TLS) with PAKE" or " Using the NETCONF Protocol over Transport Layer Security (TLS) with PSK" etc etc That leaves us free to be as 'MUST' as we like about authentication, because our use case is simple. I want to see a fresh I-D along these lines - but see below ... One last point, I'm opposed to 5539bis using draft-ietf-netconf-server-model as a Normative Reference. I believe that 5539bis should define the protocol on its own, and view draft-ietf-netconf-server-model as just one data-model that could configure it. FWIW, neither 6242 nor draft-ietf-netconf-call-home have a Normative Reference draft-ietf-netconf-server-model. suive ... There is another issue in here. RFC6241 mandates "The authentication process MUST result in an authenticated client identity whose permissions are known to the server." which suggests we should say something about how. 5539bis did have text about this but that is now in server-model. Which sort of leads to having a normative dependency of 5539bis on server-model, not for configuration reasons but for the algorithm used to extract an authenticated client identity from what information the server has gotten.. But I do see this as a separate, more debatable issue, to be discussed once there is clarity in the published I-D about the use of certificates. And I do think that the document structure is right, that is, how to extract the identity does belong in server-model and not in TLS or SSH or other transport I-Ds. Tom Petch Thanks, Kent From nobody Thu Oct 23 11:01:23 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 822851ACE61 for ; Thu, 23 Oct 2014 11:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAlw4sQhN4hX for ; Thu, 23 Oct 2014 11:01:14 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9994D1ACE54 for ; Thu, 23 Oct 2014 11:00:50 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9NI0kFs020929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Oct 2014 18:00:46 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9NI0i8b020306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Oct 2014 20:00:44 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 23 Oct 2014 20:00:44 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Thu, 23 Oct 2014 20:00:44 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: Draft minutes from the NETCONF Virtual Meeting on Monday, October 20, 2014 1800 UTC Thread-Index: Ac/jIB6WDu63AvOrTe2fO3OMZ2E2cQLyTrww Date: Thu, 23 Oct 2014 18:00:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.158] Content-Type: multipart/mixed; boundary="_004_E4DE949E6CE3E34993A2FF8AE79131F81951C804DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 57029 X-purgate-ID: 151667::1414087246-00001FC1-16EA52DC/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Jeu_yhlMd_VY0MxKe_f1Cg59hGk Subject: [Netconf] Draft minutes from the NETCONF Virtual Meeting on Monday, October 20, 2014 1800 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, 23 Oct 2014 18:01:20 -0000 --_004_E4DE949E6CE3E34993A2FF8AE79131F81951C804DEMUMBX005nsnin_ Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81951C804DEMUMBX005nsnin_" --_000_E4DE949E6CE3E34993A2FF8AE79131F81951C804DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, below are the minutes from the NETCONF virtual meeting on Monday, October 2= 0, 2014. As for all physical and virtual WG meetings the issue discussion needs to b= e verified on the maillist. All: Please provide your comments and feedback to the maillist concerning t= he conclusions from the virtual meeting. If there is no objection to the conclusions, the draft authors are going to= act as discussed. Additional information on the issue discussion is available on netconf-wg g= ithub: https://github.com/netconf-wg/restconf/issues and https://github.com/netconf-wg/server-model/issues https://github.com/netconf-wg/call-home/issues If there are no change requests from the attendees, the minutes below will = be sent to proceedings@ietf.org tomorrow EOB (= please send your request to the co-chairs). PS: Please be aware that the virtual meeting on November 3, 2014 has been c= anceled by the organizers. Regards, Mehmet Minutes of the NETCONF Virtual Meeting on October 20, 2014 Attendees: JS =3D Juergen Schoenwaelder MB =3D Martin Bjorklund AB =3D Andy Bierman ME =3D Mehmet Ersue MJ =3D Mahesh Jethanandani LL =3D Lada Lhotka AL =3D Alan Luchuk JT =3D JF Tremblay KW =3D Kent Watsen AI =3D Action Item Agenda of the virtual interim meeting on October 20, 2014 1700-1900 UTC ----------------------------------------------------------------------- - 5 min chair intro - recording the meeting?, scribe, agenda bashing The tool Etherpad has been used for notetaking. - 10 min rfc5539bis and X.509 certificate authentication (Juergen) JS: certificate based auth is already there. We should remain consistent with the usage in SNMP. AI: JS to ask Tom Petch what he is missing. MB: Consistent set of document is probably what Tom is missing. Server model can be updated to state that these are now consistent. KW: 5539bis should be self-standing without normative reference to server model draft. AI: Mehmet will ask Kent to update. - 45 min restconf open issues (Andy) See https://github.com/netconf-wg/restconf/issues RESTCONF #3: add collection resource https://github.com/netconf-wg/restconf/issues/3 http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html Conclusion in Github: The original plan to add a basic collection resource will be done in the next release (if possible). Only basic pagination (offset + limit) will be supported. Future work may extend the basic features. AI: Martin will attempt to add a basic collection resource in time for IETF #91 RESTCONF #12: target resource list or leaf-list keys required for GET https://github.com/netconf-wg/restconf/issues/12 Not on the tracker yet: - ietf-yang-library.yang in RESTCONF-02: Should this be in a separate RF= C? JS: One way of discovering models for Restconf and Netconf. Where this is defined is 2nd prio - ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for rel= ease 1? MB: Why don't we introduce an ID for Restconf? Will there be different streams for rest- and netconf? It'll be the same stream. AB: We need an agreement on what it means they are colocated. One more issue concerning add collection resource To be returned (currently) when doing a GET on a URL that points to the list, w/o any keys. Should support offset / limit query parameters. LL: invalidity of the reply any concern for JSON. Conclusion in Github: This issue is related to #13, which has been opened now. The basic collection resource support should resolve this issue Conclusion for issue #13: The ietf-yang-library contains YANG module information that may be applicable to NETCONF or other protocols that use YANG modules. Should this module be in a separate RFC? Current consensus is no, leave it in RESTCONF RFC. - 35 min netconf-server model open issues (Kent) see: https://github.com/netconf-wg/server-model/issues Issue #4: How to configure NETCONF server's SSH host-keys or TLS certifi= cates Conclusion in Github: There was consensus for the proposal to add top-level "netconf-server/ssh" and "netconf-server/tls" containers to, in part, list out the (config false) system's SSH host-keys and TLS certificates. This so that these keys can then be referenced by both the listen and call-home configurations= . Additionally, Kent explained that configuring said keys has turned out to be more difficult than first thought, due to the wide array of algorithm= s and key-generation/signing strategies involved. Perhaps RFC 7210 (mentioned by Mahesh above) should be looked at. Issue #8: what other server config knobs are needed? Conlusion: AI for MB to provide parameters their server supports. Then KW will try to find the common parameters between the three servers. Issue #13: enable indirect Issuer authentications? Conclusion: There was general consensus that this was the way to go. AI: Take to the maillist. Issue #15: Should the "listen" and "call-home" lists have parent contain= ers? Turns out that there is no best-practice around use of parent containers for lists. There wasn't even consensus that a single module need be self-consistent. In the end, it was decided that it was purely a modeler's discretion and that this is essentially a non-issue. AI: Take to the maillist. - 20 min netconf-call-home open issues (Kent) https://github.com/netconf-wg/call-home/issues Issue #3: Extend to support RESTCONF as well? KW explained that the config model for NETCONF call-home using TLS was essentially identical to what would be needed for RESTCONF call-home using TLS (HTTPS). And further that the concern for HTTP sessions was unwarranted if RESTCONF requires HTTP/1.1 (which defaults to persistent connections) and recommends setting http server timeouts to something reasonable like 5 minutes. MB questioned if the need for call-home existed. That is, if RESTCONF is used primarily for off-box applications/controllers - do they need to call home too? Kent agreed that applications/controllers would likely not need to call-home, but that we should't dismiss RESTCONF being deployed instead of NETCONF on a NE, in which case RESTCONF call home would be important. The discussion went further into why RESTCONF wasn't deemed suitable for production, to which it landed on not having a confirmed-commi= t equivalent. Martin said that he tried once, but couldn't find a simple solution. Kent and Martin to sync up offline. Conclusion: MB and KW agreed that, if we do support RESTCONF call-home (or even not), it would be best for draft-ietf-netconf-server-model to have another top-level module (e.g., ietf-restconf-server) that shared groupings with the existing ietf-netconf-server module. Issue #4: Have a call-home port? KW explained that with RESTCONF call home, the number of ports requested from IANA would then be three, which ratchets up the potential need to define a single port. And that since now we have a single call-home draft for all transports, it would be much simpler to do than before. AI: KW to provide a proposal and ask the maillist for feedback. - 5 min AOB other topics The next virtual interim meeting on November 3, 2014 just before IETF #91 meeting has been canceled. --_000_E4DE949E6CE3E34993A2FF8AE79131F81951C804DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NETCONF WG,

 

below are the minutes from the NETCONF virtual me= eting on Monday, October 20, 2014.

As for all physical and virtual WG meetings the i= ssue discussion needs to be verified on the maillist.

 

All: Please provide your comments and feedback to the maillist concerning the conclusions from the virtual meeting.

If there is no objection to the conclusions, the = draft authors are going to act as discussed.

 

Additional information on the issue discussion is= available on netconf-wg github:

https://github.com/netconf-wg/call-home/issues

 

If there are no change requests from the attendee= s, the minutes below will be sent to = proceedings@ietf.org tomorrow EOB (please send your request to the co-c= hairs).

 

PS: Please be aware that the virtual meeting on N= ovember 3, 2014 has been canceled by the organizers.

 

Regards,

Mehmet

 

Minutes of the NETCONF Virtual Meeting on October= 20, 2014

 

Attendees:

 

JS =3D Juergen Schoenwaelder

MB =3D Martin Bjorklund

AB =3D Andy Bierman

ME =3D Mehmet Ersue

MJ =3D Mahesh Jethanandani=

LL =3D Lada Lhotka<= o:p>

AL =3D Alan Luchuk

JT =3D JF Tremblay

KW =3D Kent Watsen

 

AI =3D Action Item

 

Agenda of the virtual interim meeting on October = 20, 2014 1700-1900 UTC

-------------------------------------------------= ----------------------

- 5 min chair intro - recording the meeting?, scr= ibe, agenda bashing

The tool Etherpad h= as been used for notetaking.

- 10 min rfc5539bis and X.509 certificate authent= ication (Juergen)

 

JS: certificate based auth is already there.=

We should remain consistent with the usage in SNM= P.

AI: JS to ask Tom Petch what he is missing.<= /o:p>

MB: Consistent set of document is probably what T= om is missing.

Server model can be updated to state that these a= re now consistent.

KW: 5539bis should be self-standing without norma= tive reference to

server model draft.

AI: Mehmet will ask Kent to update.

 

 

 

- 45 min restconf o= pen issues (Andy)

   See https://github.com/netconf-wg/restconf/issues

  &nbs= p;RESTCONF #3: add collection resource

   https://git= hub.com/netconf-wg/restconf/issues/3

   http://www.ietf.org/mail-archive/web/netconf/current/msg09365.html<= /a>

Conclusion in Github:

The original plan to add a basic collection resou= rce will be

done in the next release (if possible). Only basi= c pagination

(offset + limit) will be supported. Future wo= rk may extend the basic

features.

 

AI: Martin will attempt to add a basic collection= resource in time for

IETF #91

  &nbs= p;RESTCONF #12:   target resource list or leaf-list keys required for GET

   https://gi= thub.com/netconf-wg/restconf/issues/12

  &nbs= p;Not on the tracker yet:

   - ietf-yang-library.yang in RESTCONF-02: = Should this be in a separate RFC?

 

   JS: One way of discovering models for Restconf and Netconf.

   Where this is defined is 2nd prio

  

  &nbs= p;- ietf-restconf-monitoring.yang in RESTCONF-02: Is this complete for release 1?

 MB:= Why don't we introduce an ID for Restconf?

Will there be different streams for rest- and net= conf?

It'll be the same stream.

 AB:= We need an agreement on what it means they are colocated.

 One= more issue concerning add collection resource

 

To be returned (currently) when doing a GET on a = URL that points to

the list, w/o any keys. Should support offset / l= imit query parameters.

LL: invalidity of the reply any concern for JSON.=

 

Conclusion in Github:

This issue is related to #13, which has been open= ed now.

The basic collection resource support should reso= lve this issue

 

Conclusion for issue #13:

The ietf-yang-library contains YANG module inform= ation that may

be applicable to NETCONF or other protocols that = use YANG modules.

Should this module be in a separate RFC?

Current consensus is no, leave it in RESTCONF RFC= .

 

- 35 min netconf-server model open issues  (Kent)

   see: https://github.com/netconf-wg/server-model/issues

  &nbs= p;Issue #4: How to configure NETCONF server's SSH host-keys or TLS c= ertificates

 

Conclusion in Github:

There was consensus for the proposal to add top-l= evel “netconf-server/ssh”

and “netconf-server/= tls” containers to, in part, list out the (config

false) system's SSH host-keys and TLS certificate= s. This so that these

keys can then be referenced by both the listen an= d call-home configurations.

 

Additionally, Kent explained that configuring sai= d keys has turned out

to be more difficult than first thought, due to t= he wide array of algorithms

and key-generation/signing strategies involved. P= erhaps RFC 7210 (mentioned

by Mahesh above) should be looked at.<= /p>

 

   Issue #8: what other server config knobs are needed?

  

Conlusion:

AI for MB to provide parameters their server supp= orts.

Then KW will try to find the common parameters be= tween the three servers.

 

   Issue #13: enable indirect Issuer authentications?

 

Conclusion:

There was general consensus that this was the way= to go.

 

AI: Take to the maillist.

 

   Issue #15: Should the "listen" and "call-home" list= s have parent containers?

 

Turns out that there is no best-practice around u= se of parent containers

for lists. There wasn't even consensus that a sin= gle module need be

self-consistent. In the end, it was decided that = it was purely a modeler's

discretion and that this is essentially a non-iss= ue.

 

AI: Take to the maillist.

 

- 20 min netconf-call-home open issues  (Kent)

  ht= tps://github.com/netconf-wg/call-home/issues  

 

   Issue #3: Extend to support RESTCONF as well?

 

KW explained that the config model for NETCONF ca= ll-home using TLS was

essentially identical to what would be needed for= RESTCONF call-home using

TLS (HTTPS). And further that the concern for HTT= P sessions was unwarranted

if RESTCONF requires HTTP/1.1 (which defaults to = persistent connections)

and recommends setting http server timeouts to so= mething reasonable like

5 minutes.

 

MB questioned if the need for call-home existed. = That is, if RESTCONF is

used primarily for off-box applications/controlle= rs - do they need to

call home too? Kent agreed that applications/cont= rollers would likely not

need to call-home, but that we should't dismiss RESTCONF being deployed

instead of NETCONF on a NE, in which case RESTCON= F call home would be

important. The discussion went further into why R= ESTCONF wasn't deemed

suitable for production, to which it landed on no= t having a confirmed-commit

equivalent. Martin said that he tried once, but c= ouldn't find a simple

solution. Kent and Martin to sync up offline.

 

Conclusion:

MB and KW agreed that, if we do support RESTCONF = call-home (or even not),

it would be best for draft-ietf-netconf-server-mo= del to have another

top-level module (e.g., ietf-restconf-server) that shared groupings with

the existing ietf-netconf-server module.

 

   Issue #4:  Have a call-home port?

KW explained that with RESTCONF call home, the nu= mber of ports requested

from IANA would then be three, which ratchets up = the potential need to

define a single port. And that since now we have = a single call-home draft

for all transports, it would be much simpler to d= o than before.

 

AI: KW to provide a proposal and ask the maillist= for feedback.

 

- 5 min AOB other topics

 

The next virtual interim meeting on November 3, 2= 014 just before IETF #91

meeting has been canceled.

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F81951C804DEMUMBX005nsnin_-- --_004_E4DE949E6CE3E34993A2FF8AE79131F81951C804DEMUMBX005nsnin_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=136; creation-date="Wed, 08 Oct 2014 17:49:10 GMT"; modification-date="Wed, 08 Oct 2014 17:49:10 GMT" Content-ID: <1BD6E17ECAC89445980DA9B67E8E55AD@internal.nsn.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_004_E4DE949E6CE3E34993A2FF8AE79131F81951C804DEMUMBX005nsnin_-- From nobody Thu Oct 23 15:26: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 803C11AD537 for ; Thu, 23 Oct 2014 15:26:33 -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_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPuZEmyPecqh for ; Thu, 23 Oct 2014 15:26:32 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9E51A1B26 for ; Thu, 23 Oct 2014 15:26:31 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 23 Oct 2014 22:26:28 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.50]) with mapi id 15.00.1049.012; Thu, 23 Oct 2014 22:26:28 +0000 From: Kent Watsen To: NetConf Thread-Topic: server-model issue with specifying which keys/certs a server instance use Thread-Index: AQHP7xBjjIveFPu6SUWXgEdLWsYYLA== Date: Thu, 23 Oct 2014 22:26: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:;SRVR:CO1PR05MB457; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(107046002)(107886001)(229853001)(20776003)(85306004)(110136001)(36756003)(106116001)(77096002)(106356001)(80022003)(95666004)(46102003)(99286002)(66066001)(40100003)(105586002)(31966008)(76482002)(2656002)(83506001)(101416001)(50986999)(87936001)(85852003)(54356999)(99396003)(97736003)(120916001)(21056001)(4396001)(122556002)(19580395003)(92566001)(92726001)(86362001); 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: <0C9DAF260DA9D84D81965DD5B899B773@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/P1eGBH1PeA1jyBqfxTwPm7g6O8s Subject: [Netconf] server-model issue with specifying which keys/certs a server instance use 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, 23 Oct 2014 22:26:33 -0000 In order to resolve the host-key "name" issue (issue #4), the plan discussed during this week's virtual meeting was to introduce a couple config=3Dfalse lists for the server's host-keys and certs, something like this: +--rw netconf-server +--rw listen | ... +--rw call-home | ... +--rw ssh | +--rw host-keys | +--ro host-key* [name] | +--ro name string | +--ro format-identifier string | +--ro data binary | +--ro fingerprint string +--rw tls +--rw certificates | +--ro certificate* [name] | +--ro name string | +--ro data binary | ... and then the have specific listen/call-home configurations use a leafref to identify which one(s) they wanted to use. For instance: leaf host-key { type leafref { path "/netconf-server/ssh/host-keys/host-key/name"; } } But this doesn't work because the path is not part of the accessible tree: error: the path for host-key is config but refers to a non-config leaf name defined at ../ietf-netconf-server.yang:109 OK, but what to do now? One option is to define a full-on configuration model for both TLS and SSH, which would then enable the leafref to work. But I'm hesitant to do this though, because it seems like a huge (potentially out of scope) addition and it looks complicated, so I'm looking for options - anyone? As a recap, the reason why we want to configure which hostkeys are advertised is call-home SHOULD *only* advertise an X.509 key, whereas listen SHOULD advertise the common set of keys (rsa, dsa, etc.). One simplification would be to have a single setting for all "listen" instances and a separate single instance for "call home" instances. But this simplification doesn't resolve the issue above of how to identify/reference which key(s) should be used... Thanks, Kent From nobody Thu Oct 23 15:33: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 0053D1A1C06 for ; Thu, 23 Oct 2014 15:33:42 -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_65=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 URZ4yMGp8yoJ for ; Thu, 23 Oct 2014 15:33:40 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313791A6F11 for ; Thu, 23 Oct 2014 15:33:40 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id q107so190003qgd.18 for ; Thu, 23 Oct 2014 15:33:39 -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=vOykQ5KEznr5Lg80AAd/34xyrOADCgt9VqYJBhlW3G0=; b=ANoUfTLM+PGGBNjnf7h+nNRmGjCl3+8ySA+cXY8vx1C9yWAIx9QzOnzDj506abOQd0 NcQMh839RaKaomJMmwz2KCsiRmZLCpZebW+PoQAsf2pUAA2i5Ea2g1JteQOpo/zg7yot Ozdf0AuO7EV/hzaNw9Tg/jHSNVwjeqNtIJEF3SEAkdhDEO2QuMuuqup8QETroZ4ntRF4 qNxa7NV1kghhfBEIxnH2g5xI6oLWXbTsEbWWjj35hJ65+vr6yX5gAuNXmq2LXVkrJcXJ 6XvUI7F+flqWtQyV7JTFN3Fi1C6ZiiHHA/mJP11ZSjiflmsMxhkVD1Wv7X8OmSacjwc0 BZIQ== X-Gm-Message-State: ALoCoQncpdtqMhACemue1F+SmHQf+MXdylByvl46s5HOMOiBp0zWwhW19if7dVtgoFzQC9WKAeYo MIME-Version: 1.0 X-Received: by 10.170.74.85 with SMTP id q82mr336600ykq.119.1414103619178; Thu, 23 Oct 2014 15:33:39 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Thu, 23 Oct 2014 15:33:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Oct 2014 15:33:39 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a113a51d0e5b16605061ea703 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/AzJt14GDDEqWzoqEUEs1U5KX8KY Cc: NetConf Subject: Re: [Netconf] server-model issue with specifying which keys/certs a server instance use 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, 23 Oct 2014 22:33:42 -0000 --001a113a51d0e5b16605061ea703 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 23, 2014 at 3:26 PM, Kent Watsen wrote: > > In order to resolve the host-key "name" issue (issue #4), the plan > discussed during this week's virtual meeting was to introduce a couple > config=false lists for the server's host-keys and certs, something like > this: > > +--rw netconf-server > +--rw listen > | ... > +--rw call-home > | ... > +--rw ssh > | +--rw host-keys > | +--ro host-key* [name] > | +--ro name string > | +--ro format-identifier string > | +--ro data binary > | +--ro fingerprint string > +--rw tls > +--rw certificates > | +--ro certificate* [name] > | +--ro name string > | +--ro data binary > | ... > > > and then the have specific listen/call-home configurations use a leafref > to identify which one(s) they wanted to use. For instance: > > leaf host-key { > type leafref { > path "/netconf-server/ssh/host-keys/host-key/name"; > } > } > > But this doesn't work because the path is not part of the accessible tree: > > > error: the path for host-key is config but refers to a non-config > leaf name defined at ../ietf-netconf-server.yang:109 > > > OK, but what to do now? One option is to define a full-on configuration > model for both TLS and SSH, which would then enable the leafref to work. > But I'm hesitant to do this though, because it seems like a huge > (potentially out of scope) addition and it looks complicated, so I'm > looking for options - anyone? > > IMO do not use a leafref. Let's not keep expanding the scope of this work or it will never get done. Write a description-stmt that explains the constraints. It should be OK to change a type-stmt from "foo" to "leafref to leaf with type foo" in a module update. So we just have to get the data type correct. > As a recap, the reason why we want to configure which hostkeys are > advertised is call-home SHOULD *only* advertise an X.509 key, whereas > listen SHOULD advertise the common set of keys (rsa, dsa, etc.). > > One simplification would be to have a single setting for all "listen" > instances and a separate single instance for "call home" instances. But > this simplification doesn't resolve the issue above of how to > identify/reference which key(s) should be used... > > > Thanks, > Kent > > Andy > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a113a51d0e5b16605061ea703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 23, 2014 at 3:26 PM, Kent Watsen <kwatsen@juniper.net> wrote:

In order to resolve the host-key "name" issue (issue #4), the pla= n
discussed during this week's virtual meeting was to introduce a couple<= br> config=3Dfalse lists for the server's host-keys and certs, something li= ke
this:

=A0 =A0+--rw netconf-server
=A0 =A0 =A0 +--rw listen
=A0 =A0 =A0 | ...
=A0 =A0 =A0 +--rw call-home
=A0 =A0 =A0 |=A0 ...
=A0 =A0 =A0 +--rw ssh
=A0 =A0 =A0 |=A0 +--rw host-keys
=A0 =A0 =A0 |=A0 =A0 =A0+--ro host-key* [name]
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro name=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s= tring
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro format-identifier=A0 =A0 string
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro data=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b= inary
=A0 =A0 =A0 |=A0 =A0 =A0 =A0 +--ro fingerprint=A0 =A0 =A0 =A0 =A0 string =A0 =A0 =A0 +--rw tls
=A0 =A0 =A0 =A0 =A0+--rw certificates
=A0 =A0 =A0 =A0 =A0|=A0 +--ro certificate* [name]
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0+--ro name=A0 =A0 string
=A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0+--ro data=A0 =A0 binary
=A0 =A0 =A0 =A0 =A0|=A0 ...


and then the have specific listen/call-home configurations use a leafref to identify which one(s) they wanted to use.=A0 =A0For instance:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf host-key {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type leafref {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 path "/netconf-server/ssh/host-key= s/host-key/name";
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 =A0 }

But this doesn't work because the path is not part of the accessible tr= ee:


=A0 =A0 error: the path for host-key is config but refers to a non-config =A0 =A0 leaf name defined at ../ietf-netconf-server.yang:109


OK, but what to do now?=A0 =A0One option is to define a full-on configurati= on
model for both TLS and SSH, which would then enable the leafref to work. But I'm hesitant to do this though, because it seems like a huge
(potentially out of scope) addition and it looks complicated, so I'm looking for options - anyone?


IMO do not use a leafref.=A0 Let's= not keep expanding the scope of
this work or it will never get d= one. Write a description-stmt that
explains the constraints. It s= hould be OK to change a type-stmt
from "foo" to "l= eafref to leaf with type foo" in a module update.
So we just= have to get the data type correct.

=A0
As a recap, the reason why we want to configure which hostkeys are
advertised is call-home SHOULD *only* advertise an X.509 key, whereas
listen SHOULD advertise the common set of keys (rsa, dsa, etc.).

One simplification would be to have a single setting for all "listen&q= uot;
instances and a separate single instance for "call home" instance= s.=A0 =A0But
this simplification doesn't resolve the issue above of how to
identify/reference which key(s) should be used...


Thanks,
Kent



Andy

--001a113a51d0e5b16605061ea703-- From nobody Fri Oct 24 00:17: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 8B9551AD6CD for ; Fri, 24 Oct 2014 00:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKep3MFYkZfM for ; Fri, 24 Oct 2014 00:17: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 4CB571AD6C8 for ; Fri, 24 Oct 2014 00:17: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 A1074A31; Fri, 24 Oct 2014 09:17: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 98GZ_igkOC_3; Fri, 24 Oct 2014 09:17: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; Fri, 24 Oct 2014 09:17:17 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A953620035; Fri, 24 Oct 2014 09:17:17 +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 3o-3M1RiLf7p; Fri, 24 Oct 2014 09:17: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 463F120037; Fri, 24 Oct 2014 09:17:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0A7652F0D65A; Fri, 24 Oct 2014 09:17:14 +0200 (CEST) Date: Fri, 24 Oct 2014 09:17:14 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20141024071714.GC99632@elstar.local> Mail-Followup-To: Andy Bierman , 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/PEEOQ8mTx2cON353zdHpHAOMHjY Cc: NetConf Subject: Re: [Netconf] server-model issue with specifying which keys/certs a server instance use 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, 24 Oct 2014 07:17:22 -0000 On Thu, Oct 23, 2014 at 03:33:39PM -0700, Andy Bierman wrote: > On Thu, Oct 23, 2014 at 3:26 PM, Kent Watsen wrote: > > > > > In order to resolve the host-key "name" issue (issue #4), the plan > > discussed during this week's virtual meeting was to introduce a couple > > config=false lists for the server's host-keys and certs, something like > > this: > > > > +--rw netconf-server > > +--rw listen > > | ... > > +--rw call-home > > | ... > > +--rw ssh > > | +--rw host-keys > > | +--ro host-key* [name] > > | +--ro name string > > | +--ro format-identifier string > > | +--ro data binary > > | +--ro fingerprint string > > +--rw tls > > +--rw certificates > > | +--ro certificate* [name] > > | +--ro name string > > | +--ro data binary > > | ... > > > > > > and then the have specific listen/call-home configurations use a leafref > > to identify which one(s) they wanted to use. For instance: > > > > leaf host-key { > > type leafref { > > path "/netconf-server/ssh/host-keys/host-key/name"; > > } > > } > > > > But this doesn't work because the path is not part of the accessible tree: > > > > > > error: the path for host-key is config but refers to a non-config > > leaf name defined at ../ietf-netconf-server.yang:109 > > > > > > OK, but what to do now? One option is to define a full-on configuration > > model for both TLS and SSH, which would then enable the leafref to work. > > But I'm hesitant to do this though, because it seems like a huge > > (potentially out of scope) addition and it looks complicated, so I'm > > looking for options - anyone? > > > > > IMO do not use a leafref. Let's not keep expanding the scope of > this work or it will never get done. Write a description-stmt that > explains the constraints. It should be OK to change a type-stmt > from "foo" to "leafref to leaf with type foo" in a module update. > So we just have to get the data type correct. > A data model to manage certificates and host keys would surely be useful but this is big project on its own and I agree that we should not try to solve it here. So all we can do is probably refer to a certificate or host key by name and leave the details how these credentials are configured undefined for now. The only assumption we would make is that a future data model to manage certificates and host keys identifies certificates and host keys by a name. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Oct 24 05: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 CC87D1A8ABD for ; Fri, 24 Oct 2014 05:21:25 -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_20=-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 n4eZVzRThyfW for ; Fri, 24 Oct 2014 05:21:22 -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 B14AE1A8AA4 for ; Fri, 24 Oct 2014 05:21:21 -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 1Xhdrq-0004VP-L8 for netconf@ietf.org; Fri, 24 Oct 2014 14:21:20 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest154.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Xhdrq-0005ME-Gh for netconf@ietf.org; Fri, 24 Oct 2014 14:21:18 +0200 Message-ID: <544A443E.9000405@bwijnen.net> Date: Fri, 24 Oct 2014 14: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: Netconf References: <544981D8.5030004@meetecho.com> In-Reply-To: <544981D8.5030004@meetecho.com> X-Forwarded-Message-Id: <544981D8.5030004@meetecho.com> Content-Type: text/plain; charset=iso-8859-15; 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: 86ab03e524994f79ca2c75a176445dd4d5b292ca67a9614f14c0982045db23f6 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/AALa9Us0UDDp4vcchF9ZLXC3Q0s Subject: [Netconf] Fwd: Meetecho coverage at IETF91 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, 24 Oct 2014 12:21:26 -0000 We will have standard jabber and now also meetecho coverage of our meeting at IETF91. If there is anyone who needs to present remotely, pls let us know, so we can make proper arrangements. Our session slot is Tuesday 1-3pm Honolulu time. Bert and Mehmet -------- Forwarded Message -------- Subject: Meetecho coverage at IETF91 Date: Fri, 24 Oct 2014 00:31:52 +0200 From: Meetecho IETF support To: wgchairs@ietf.org Dear chairs, as you probably know, Meetecho will cover all WG meeting session in Honolulu. If you plan to have remote _presentations_, you're kindly requested to inform us in proper advance, since this needs a special set-up and a preliminary test with the remote speakers. *Please be aware that the deadline for requesting remote presentation support is November 6.* Thanks, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From nobody Sat Oct 25 15:46: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 B5E7F1A1A66; Sat, 25 Oct 2014 15:46:03 -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 cr-xxBn8ajON; Sat, 25 Oct 2014 15:46:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A011A6D3F; Sat, 25 Oct 2014 15:46:01 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 15:46:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sLgIT9FjTtivj_P2DCpfHP-ehZc Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-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: Sat, 25 Oct 2014 22:46:04 -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 : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-03.txt Pages : 99 Date : 2014-10-25 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-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 Sat Oct 25 16:16: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 4DCBF1A1C04 for ; Sat, 25 Oct 2014 16:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MISSING_HEADERS=1.021, 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 ePB0YEBJQ9PP for ; Sat, 25 Oct 2014 16:16:31 -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 B35A61A1ABB for ; Sat, 25 Oct 2014 16:16:31 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so2318467qcy.15 for ; Sat, 25 Oct 2014 16:16:30 -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:cc:content-type; bh=6vkE/AFk9ExUMYkTyk9vitZMQd1NEiilCMKpmsV9KkI=; b=RSccc/S9kEcaqGKEoboX4QDc54PyaC1vahRaoZbi2+Tls+9tpjyDzKlX04++Emm2E8 Aoa3kKpXfM/W/yTfPuX15lkQUFCSLhmuBmh4AQDtfTf7gKwtxlhFgQvKP1OzwIxaAc8S Sa/2V46O55rLnMX6oHo/mqJp7VJ6WiyturVIA3hsyHB5KyXcL7OPZje5ofFSVonb2xVV X2U9SxHw8zgfivgm3ckqFCBy15czJ2cjH/e+ugwhQN6XfHtTtJD2zMebiNOwxSMQG+b6 WbRXb/yyqjD2cVXgfux5Coj7lPwsqMMQzcJbhPSMl21+ml8ZIR+wh8tUDnZhrIOFZm5i UZKA== X-Gm-Message-State: ALoCoQnMs8w1fnHRFkRDp4rPQMolVNtRFMVRQn/VGhrP6tBlZWnTl9L28qDkWtOJrfmO0OYSdeMg MIME-Version: 1.0 X-Received: by 10.229.239.74 with SMTP id kv10mr19521052qcb.27.1414278990691; Sat, 25 Oct 2014 16:16:30 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Sat, 25 Oct 2014 16:16:30 -0700 (PDT) In-Reply-To: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> References: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 16:16:30 -0700 Message-ID: From: Andy Bierman Cc: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/b_PEATzH_KrZxo4SzAjgS5ryWCc Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-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: Sat, 25 Oct 2014 23:16:33 -0000 FYI, This version of RESTCONF addresses all issues on the github tracker except maybe #9. Also, #11 was deferred to a future release. A change was made to the "stream" list in ietf-restconf-monitoring.yang to allow separate stream links for XML and (optionally) JSON encoding of notifications. A "collection" resource, plus "limit" and "offset" query parameters, have been added to allow multiple leaf-list and list instances to be retrieved. The optional "page" capability allows pagination of list entries, using the limit and offset parameters. Issue List: https://github.com/netconf-wg/restconf/issues Please review the draft and send any comments to the mailing list. Please post any objections to closing the issues #2 - #8 and #10 - #13. thanks, Andy On Sat, Oct 25, 2014 at 3:46 PM, 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 : RESTCONF Protocol > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-restconf-03.txt > Pages : 99 > Date : 2014-10-25 > > Abstract: > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using the > datastores defined in NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Oct 26 12:08:32 2014 Return-Path: <81joseh@gmail.com> 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 323951A039F for ; Sun, 26 Oct 2014 12:08:30 -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 v8SEnzz5cp-n for ; Sun, 26 Oct 2014 12:08:23 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418B41A0127 for ; Sun, 26 Oct 2014 12:08:23 -0700 (PDT) Received: by mail-oi0-f52.google.com with SMTP id a3so2392227oib.39 for ; Sun, 26 Oct 2014 12:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:in-reply-to:references :content-type; bh=FvUV9rpzrVOW3f2ECgGlZu21CJH57vmEiMNGzWtD+SE=; b=K+Sp47uO0GWuVIWLNiZ8xqqOpLNKnbfaBN3ep7frpFb1enJVKq9+1QMvPTzkF8Tl4J nuKvuxIJFoM+vxvRf1jc2NXMuAh1Wkj6vHSxz/OiC1JDlCfoAkaYh3Z3ghgXh+KzyBIq XmFjJUNHctfCUTnH51F+YJ2xjFPe2k8vX7NWO9u5V31NGEY4HLYI268RAjGXNVppV53w SYu8uZECQHoe9DKplxd+96x4Ovw0CsUzBMYxiOORJ22ib1hHq8PAurRvo23CC6/hXJFj sQEwVXmQ4vNLqdzSpJMoZyaqib3v3njRTcULkXAzNwJe+JpnTCIs3/CfE179uzVPivnz KxlA== X-Received: by 10.182.33.138 with SMTP id r10mr2383935obi.67.1414350502690; Sun, 26 Oct 2014 12:08:22 -0700 (PDT) Received: from [192.168.1.8] (174-126-36-211.cpe.cableone.net. [174.126.36.211]) by mx.google.com with ESMTPSA id g5sm4270842obx.8.2014.10.26.12.08.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 26 Oct 2014 12:08:22 -0700 (PDT) Message-ID: <544d46a6.254fb60a.73e2.75d3@mx.google.com> MIME-Version: 1.0 To: From: C <81joseh@gmail.com> Date: Sun, 26 Oct 2014 14:08:11 -0500 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_7A04B7CE-73C2-406D-8A5E-AD796FEE17BF_" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-WZaT6_sSRB50tkK5ztU9RDrjbk Subject: Re: [Netconf] Netconf Digest, Vol 80, Issue 31 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, 26 Oct 2014 19:08:30 -0000 --_7A04B7CE-73C2-406D-8A5E-AD796FEE17BF_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Netconf@icloud.com -----Original Message----- From: "netconf-request@ietf.org" Sent: =E2=80=8E10/=E2=80=8E26/=E2=80=8E2014 2:00 PM To: "netconf@ietf.org" Subject: Netconf Digest, Vol 80, Issue 31 Send Netconf mailing list submissions to netconf@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/netconf or, via email, send a message with subject or body 'help' to netconf-request@ietf.org You can reach the person managing the list at netconf-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Netconf digest..." Today's Topics: 1. I-D Action: draft-ietf-netconf-restconf-03.txt (internet-drafts@ietf.org) 2. Re: I-D Action: draft-ietf-netconf-restconf-03.txt (Andy Bierman) ---------------------------------------------------------------------- Message: 1 Date: Sat, 25 Oct 2014 15:46:01 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt Message-ID: <20141025224601.22229.53242.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of th= e IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-03.txt Pages : 99 Date : 2014-10-25 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03 Please note that it may take a couple of minutes from the time of submissio= n 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/ ------------------------------ Message: 2 Date: Sat, 25 Oct 2014 16:16:30 -0700 From: Andy Bierman Cc: Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt Message-ID: Content-Type: text/plain; charset=3DUTF-8 FYI, This version of RESTCONF addresses all issues on the github tracker except maybe #9. Also, #11 was deferred to a future release. A change was made to the "stream" list in ietf-restconf-monitoring.yang to allow separate stream links for XML and (optionally) JSON encoding of notifications. A "collection" resource, plus "limit" and "offset" query parameters, have been added to allow multiple leaf-list and list instances to be retrieved. The optional "page" capability allows pagination of list entries, using the limit and offset parameters. Issue List: https://github.com/netconf-wg/restconf/issues Please review the draft and send any comments to the mailing list. Please post any objections to closing the issues #2 - #8 and #10 - #13. thanks, Andy On Sat, Oct 25, 2014 at 3:46 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration Working Group of = the IETF. > > Title : RESTCONF Protocol > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Filename : draft-ietf-netconf-restconf-03.txt > Pages : 99 > Date : 2014-10-25 > > Abstract: > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using the > datastores defined in NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netconf-restconf-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------------------------------ Subject: Digest Footer _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------------------------------ End of Netconf Digest, Vol 80, Issue 31 *************************************** --_7A04B7CE-73C2-406D-8A5E-AD796FEE17BF_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Netconf@icloud.com
From: netconf-request@ietf.or= g
Sent: =E2=80=8E10/=E2=80=8E26/=E2=80=8E2014 2:00 PM=
To: netconf@ietf.org=
Subject: Netconf Digest, Vol 80, Issue 31
=
Send Netconf mailing list submissions to
netconf@ietf.org
=
To subscribe or unsubscribe via the World Wide Web, visit
https://w= ww.ietf.org/mailman/listinfo/netconf
or, via email, send a message with = subject or body 'help' to
netconf-request@ietf.org

You can reach= the person managing the list at
netconf-owner@ietf.org

When rep= lying, please edit your Subject line so it is more specific
than "Re: Co= ntents of Netconf digest..."


Today's Topics:

  = 1. I-D Action: draft-ietf-netconf-restconf-03.txt
   &nb= sp;  (internet-drafts@ietf.org)
   2. Re: I-D Action: dra= ft-ietf-netconf-restconf-03.txt (Andy Bierman)


-----------------= -----------------------------------------------------

Message: 1
= Date: Sat, 25 Oct 2014 15:46:01 -0700
From: internet-drafts@ietf.org
= To: i-d-announce@ietf.org
Cc: netconf@ietf.org
Subject: [Netconf] I-D= Action: draft-ietf-netconf-restconf-03.txt
Message-ID: <201410252246= 01.22229.53242.idtracker@ietfa.amsl.com>
Content-Type: text/plain; ch= arset=3D"utf-8"


A New Internet-Draft is available from the on-li= ne Internet-Drafts directories.
This draft is a work item of the Networ= k Configuration Working Group of the IETF.

    &= nbsp;   Title        &nbs= p;  : RESTCONF Protocol
        = Authors         : Andy Bierman
&= nbsp;           &nbs= p;             = Martin Bjorklund
         &= nbsp;           &nbs= p;    Kent Watsen
Filename     =    : draft-ietf-netconf-restconf-03.txt
Pages  &nbs= p;        : 99
Date   = ;         : 2014-10-25

Abstr= act:
   This document describes an HTTP-based protocol that pr= ovides a
   programmatic interface for accessing data defined = in YANG, using the
   datastores defined in NETCONF.

The IETF datatracker status page for this draft is:
https://datatracke= r.ietf.org/doc/draft-ietf-netconf-restconf/

There's also a htmlized = version available at:
http://tools.ietf.org/html/draft-ietf-netconf-rest= conf-03

A diff from the previous version is available at:
http://= www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03


Pleas= e 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/



------------------------------

M= essage: 2
Date: Sat, 25 Oct 2014 16:16:30 -0700
From: Andy Bierman &l= t;andy@yumaworks.com>
Cc: Netconf <netconf@ietf.org>
Subject= : Re: [Netconf] I-D Action: draft-ietf-netconf-restconf-03.txt
Message-I= D:
<CABCOCHR3nefkq3q4z7Ungks6XnoeCjuSxPpM_dpOj5V49f4ycw@mail.gmail.c= om>
Content-Type: text/plain; charset=3DUTF-8

FYI,

This= version of RESTCONF addresses all issues on the github tracker
except m= aybe #9. Also,  #11 was deferred to a future release.

A change = was made to the "stream" list in ietf-restconf-monitoring.yang
to allow = separate stream links for XML and (optionally) JSON encoding
of notifica= tions.

A "collection" resource, plus "limit" and "offset" query para= meters,
have been added to allow multiple leaf-list and list instancesto be retrieved. The optional "page" capability allows pagination of
l= ist entries, using the limit and offset parameters.

Issue List:
h= ttps://github.com/netconf-wg/restconf/issues


Please review the d= raft and send any comments to the mailing list.
Please post any objectio= ns to closing the issues #2 - #8 and #10 - #13.

thanks,
Andy
<= br>On Sat, Oct 25, 2014 at 3:46 PM,  <internet-drafts@ietf.org> = wrote:
>
> A New Internet-Draft is available from the on-line I= nternet-Drafts directories.
>  This draft is a work item of the = Network Configuration Working Group of the IETF.
>
>  = ;       Title     &n= bsp;     : RESTCONF Protocol
>   &= nbsp;     Authors      &n= bsp;  : Andy Bierman
>       =             &nb= sp;       Martin Bjorklund
>  = ;            &n= bsp;            Kent= Watsen
>         Filename&nb= sp;       : draft-ietf-netconf-restconf-03.tx= t
>         Pages  =          : 99
>  &n= bsp;      Date      =       : 2014-10-25
>
> Abstract:
&g= t;    This document describes an HTTP-based protocol that pr= ovides a
>    programmatic interface for accessing dat= a defined in YANG, using the
>    datastores defined i= n NETCONF.
>
>
> The IETF datatracker status page for thi= s draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-res= tconf/
>
> There's also a htmlized version available at:
>= ; http://tools.ietf.org/html/draft-ietf-netconf-restconf-03
>
>= A diff from the previous version is available at:
> http://www.ietf.= org/rfcdiff?url2=3Ddraft-ietf-netconf-restconf-03
>
>
> P= lease 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.or= g.
>
> Internet-Drafts are also available by anonymous FTP at:<= br>> ftp://ftp.ietf.org/internet-drafts/
>
> _______________= ________________________________
> I-D-Announce mailing list
> = I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



--------= ----------------------

Subject: Digest Footer

_______________= ________________________________
Netconf mailing list
Netconf@ietf.or= g
https://www.ietf.org/mailman/listinfo/netconf


-------------= -----------------

End of Netconf Digest, Vol 80, Issue 31
*******= ********************************
= --_7A04B7CE-73C2-406D-8A5E-AD796FEE17BF_-- From nobody Sun Oct 26 14:22: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 9EC0E1A1AAB; Sun, 26 Oct 2014 14:22:15 -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 24N3638fI6by; Sun, 26 Oct 2014 14:22:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CFC1A1AA8; Sun, 26 Oct 2014 14:22:13 -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.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026212213.8303.89823.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 14:22:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/z9mrQemdzmTmUK9ED4DnYSkAfRA Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-04.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: Sun, 26 Oct 2014 21:22:16 -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-04.txt Pages : 34 Date : 2014-10-26 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 call-home is supported, 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-server-model-04 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 Sun Oct 26 14:31:19 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573B21A1AAF for ; Sun, 26 Oct 2014 14:31:17 -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 xUdretWVdA73 for ; Sun, 26 Oct 2014 14:31:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77191A1AC9 for ; Sun, 26 Oct 2014 14:31:14 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.6.9; Sun, 26 Oct 2014 21:30:51 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.172]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.172]) with mapi id 15.01.0006.000; Sun, 26 Oct 2014 21:30:51 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-04.txt Thread-Index: AQHP8WL0xkJ4XZar10SWkJhu6yANQpxComKA Date: Sun, 26 Oct 2014 21:30:51 +0000 Message-ID: References: <20141026212213.8303.89823.idtracker@ietfa.amsl.com> In-Reply-To: <20141026212213.8303.89823.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.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0376ECF4DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174003)(199003)(189002)(377424004)(24454002)(164054003)(51704005)(19580395003)(46102003)(76482002)(99396003)(77096002)(80022003)(85852003)(2351001)(107886001)(92726001)(4396001)(20776003)(92566001)(19580405001)(15975445006)(36756003)(230783001)(101416001)(85306004)(40100003)(86362001)(107046002)(87936001)(50986999)(106356001)(76176999)(54356999)(106116001)(21056001)(110136001)(15202345003)(83506001)(2501002)(2656002)(105586002)(66066001)(97736003)(64706001)(122556002)(120916001)(99286002)(95666004)(31966008); 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: <5065E69669499149B665D7B68A2F16A8@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/Ueyp6V94ZfUEnO69lzS6RPADSTo Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-server-model-04.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: Sun, 26 Oct 2014 21:31:17 -0000 This updated has the following changes: - reduced the number of grouping statements - removed psk-maps and associated feature statements - added ability for listen/call-home instances to specify which host-keys/certificates (of all listed) to use - clarified that last-connected should span reboots - added missing "objectives" for selecting which keys to use, authenticating client-certificates, and mapping authenticated client-certificates to usernames - clarified indirect client certificate authentication - added keep-alive configuration for listen connections - added global-level NETCONF session parameters Thanks, Kent On 10/26/14, 5:22 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-04.txt > Pages : 34 > Date : 2014-10-26 > >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 call-home is supported, 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-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-server-model-04 > > >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 Mon Oct 27 07:56: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 E01091A89E5 for ; Mon, 27 Oct 2014 07:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRaZzXqDtH99 for ; Mon, 27 Oct 2014 07:55:48 -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 38AC11A8839 for ; Mon, 27 Oct 2014 07:55:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B38338F2; Mon, 27 Oct 2014 15:55:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HKCOJgW9OFLT; Mon, 27 Oct 2014 15:55:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 27 Oct 2014 15:55:45 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8233D20037; Mon, 27 Oct 2014 15:55:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Mw39EVwriNeK; Mon, 27 Oct 2014 15:55:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D100720035; Mon, 27 Oct 2014 15:55:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 199552F140CA; Mon, 27 Oct 2014 15:55:43 +0100 (CET) Date: Mon, 27 Oct 2014 15:55:42 +0100 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20141027145542.GB8819@elstar.local> Mail-Followup-To: "t. petch" , Kent Watsen , netconf@ietf.org References: <201410201458.s9KEw5Qm064083@mainfs.snmp.com> <03ae01cfed3c$50d39d20$4001a8c0@gateway.2wire.net> <20141021153455.GA91264@elstar.local> <021801cfeea0$4d7ab860$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <021801cfeea0$4d7ab860$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/G0U-Iwpl3_KFu9U2C0N6qNSOrnU Cc: netconf@ietf.org Subject: Re: [Netconf] rfc5539bis 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, 27 Oct 2014 14:55:51 -0000 Hi, the editor does not understand the edits since I do not see clear agreement of the scope of the document and thus there won't be a new version before the cutoff. It makes a major difference to me whether the document is - NC over TLS with mutual X.509 authentication or - NC over TLS plus a structure to plug in new authentication mechanisms and it is not clear whether - we details the algorithm to extract a username out of an X.509 certificate in this spec or - leave it to the server configuration model. If fact, we would be duplicating some elements from RFC 6353 and the reusable YANG grouping is in draft-ietf-netmod-snmp-cfg-08 (yes, an interesting dependency chain results from that). I think the WG needs to sort out what set of documents is wanted before making further edits. /js On Thu, Oct 23, 2014 at 10:04:00AM +0100, t. petch wrote: > ---- Original Message ----- > From: "Kent Watsen" > To: "Juergen Schoenwaelder" ; "t. > petch" > Cc: > Sent: Wednesday, October 22, 2014 7:29 PM > > >RFC 5539 has used X.509 certificates and nobody seems to request any > >changes. Why do you make this complicated? > > > >Yes, NC access control is different from SNMP access control but this > >is irrelevant. All the transport has to deliver is a user name. Why do > >we have to make this complicated? > > I kind of agree with both sides. > > On one hand, 5539bis-06 clearly intends to define mutual > certificate-based > authentication - just search for the word "mutual". Additionally, > Juergen > already explained that he put PSK in (-02, according to the change log ) > to support NETCONF-light, and since took it out. So we're essentially > back to just trying to clean up 5539 and make it be in-line with NETCONF > 1.1. > > On the other hand, there are a couple issues with 5539bis-06: > > 1) section 2.4.2 (Client Identity) doesn't actually say that > certificate-based authentication is required. For instance, this text > from RFC5539 was left out: "with certificate-based authentication > according to local policy" > > 2) I'm confused by these seemingly conflicting statements: > > - section 2.4 (X.509-based Authentication...) says "Implementations > MAY > optionally > support TLS certificate-based authentication" > - section 2.5 (Cipher Suites) says "However, implementations MUST > support TLS 1.2". > > So, to Juergen's point, I don't think this needs to be complicated, but > I > do think we need to be methodical about ensuring the text says what we > want it to say. > > > > Kent > > This is what I keep saying or at least, try to say - not sure how clear > I am being. But until those loose ends of text are removed, then > 5539bis remains ambiguous IMHO (and I then remain reluctant to move on > to other issues and other I-Ds). > > I would go slightly further and change the title and Intro. Martin > raised the point about this I-D seeming to exclude other forms of > authentication with TLS so I would entitle this one > > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > X.509 Certificates" > > Then anyone is free to write another I-D entitled > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > PAKE" > or > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > PSK" > etc etc > > That leaves us free to be as 'MUST' as we like about authentication, > because our use case is simple. > > I want to see a fresh I-D along these lines - but see below ... > > > > One last point, I'm opposed to 5539bis using > draft-ietf-netconf-server-model as a Normative Reference. I believe > that > 5539bis should define the protocol on its own, and view > draft-ietf-netconf-server-model as just one data-model that could > configure it. FWIW, neither 6242 nor draft-ietf-netconf-call-home have > a > Normative Reference draft-ietf-netconf-server-model. > > > suive ... There is another issue in here. RFC6241 mandates > "The authentication process MUST result in an authenticated client > identity whose permissions are known to the server." > which suggests we should say something about how. 5539bis did have text > about this but that is now in server-model. Which sort of leads to > having a normative dependency of 5539bis on server-model, not for > configuration reasons but for the algorithm used to extract an > authenticated client identity from what information the server has > gotten.. > > But I do see this as a separate, more debatable issue, to be discussed > once there is clarity in the published I-D about the use of > certificates. And I do think that the document structure is right, that > is, how to extract the identity does belong in server-model and not in > TLS or SSH or other transport I-Ds. > > Tom Petch > > Thanks, > Kent > -- 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 Oct 27 08:24: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 EA2AD1A6F3D for ; Sat, 25 Oct 2014 13:18:58 -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 k__x4RRTo0dO for ; Sat, 25 Oct 2014 13:18:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 597181A6F6D for ; Sat, 25 Oct 2014 13:18:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141025201856.15106.76396.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 13:18:56 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gm3NrNbCs2Mgm9hQ0cUVHkYsXvo X-Mailman-Approved-At: Mon, 27 Oct 2014 08:24:12 -0700 Subject: [Netconf] Milestones changed for netconf WG 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, 25 Oct 2014 20:18:59 -0000 Deleted milestone "Submit initial WG draft for call home YANG module as WG item". Deleted milestone "WGLC for Reverse SSH". Deleted milestone "Submit call home YANG module to AD/IESG for consideration as Proposed Standard". Deleted milestone "Submit Reverse SSH to AD/IESG for consideration as Proposed Standard". Changed milestone "Submit initial WG draft for zero touch configuration as WG item", set due date to July 2014 from February 2014, resolved as "Done", added draft-ietf-netconf-zerotouch to milestone. Changed milestone "WGLC for NETCONF server configuration data model", set due date to December 2014 from April 2014, added draft-ietf-netconf-server-model to milestone. Changed milestone "WGLC for zero touch configuration", set due date to December 2014 from April 2014, added draft-ietf-netconf-zerotouch to milestone. Deleted milestone "WGLC for call home YANG module". Changed milestone "WGLC for RFC5539bis", set due date to December 2014 from April 2014, added draft-ietf-netconf-rfc5539bis to milestone. Changed milestone "WGLC for RESTCONF and patch operation drafts", set due date to December 2014 from June 2014, added draft-ietf-netconf-restconf, draft-ietf-netconf-yang-patch to milestone. Changed milestone "Submit zero touch configuration to AD/IESG for consideration as Proposed Standard", set due date to January 2015 from May 2014, added draft-ietf-netconf-zerotouch to milestone. Changed milestone "Submit RFC5539bis to AD/IESG for consideration as Proposed Standard", set due date to January 2015 from May 2014, added draft-ietf-netconf-rfc5539bis to milestone. Changed milestone "Submit RESTCONF to AD/IESG for consideration as Proposed Standard", set due date to January 2015 from August 2014, added draft-ietf-netconf-restconf, draft-ietf-netconf-yang-patch to milestone. URL: http://datatracker.ietf.org/wg/netconf/charter/ From nobody Mon Oct 27 08:24: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 9DC5A1A6F93 for ; Sat, 25 Oct 2014 13:20:53 -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 Fp5ktM6a3eRj for ; Sat, 25 Oct 2014 13:20:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2979D1A6F96 for ; Sat, 25 Oct 2014 13:20:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141025202050.6365.31881.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 13:20:50 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/tTJxADChJ5-0HZ_dQHhu9UdECS4 X-Mailman-Approved-At: Mon, 27 Oct 2014 08:24:41 -0700 Subject: [Netconf] Milestones changed for netconf WG 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, 25 Oct 2014 20:20:53 -0000 Changed milestone "Submit initial WG drafts for RESTCONF and patch operation as WG items", resolved as "Done". URL: http://datatracker.ietf.org/wg/netconf/charter/ From nobody Mon Oct 27 08:45: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 4CE111ACDAA for ; Mon, 27 Oct 2014 08:45:16 -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 QYP10VXjIg9X for ; Mon, 27 Oct 2014 08:45:10 -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 4BB5E1A9073 for ; Mon, 27 Oct 2014 08:45:08 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so4095203qgd.19 for ; Mon, 27 Oct 2014 08:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=SnrI2Fh5hmYc7hC5CjwOP0OoSGxHMKNKgu/e6mUeBtU=; b=Y9hOb2g7NAfrkSKT5tX38+9uxfgxFEbflWrLOmlYTZtec6Z1LNSnVWFlJGVaGXnlbr +rGs9vqfjMGjjUmtYw8lFdqAhV31voB91nciRB0JBCwM9QOpDBNSRDTpK0MZkK/tshD1 2zeTtqCUirbTtWZuGS7KoSHQw7Kl017dyUGiAwUYSzsTEzfknwhPUwe6GmQKCur+T9nG P589vw8oN8popktsMSBnfVk9kP/MeLY+9KlEg9Yyiy0MsjqTOH2nARm/E/hXyPuBrW8C H5QNnr2rYhn3o4LsxbvWpHv/FU+fOzsiPsoC043fzv6JgsFfMYieS8kyhFZaspo0kbFE Waug== X-Received: by 10.140.104.200 with SMTP id a66mr33344265qgf.37.1414424707469; Mon, 27 Oct 2014 08:45:07 -0700 (PDT) Received: from [10.10.4.191] (50-201-180-2-static.hfc.comcastbusiness.net. [50.201.180.2]) by mx.google.com with ESMTPSA id n46sm11425432qgn.9.2014.10.27.08.45.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 08:45:00 -0700 (PDT) References: <20141027121016.1994.1105.idtracker@ietfa.amsl.com> From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=Apple-Mail-EA984998-EB3C-4D40-B350-49A92C605F54 X-Mailer: iPad Mail (11D257) Message-Id: <02617A6B-9E01-43C1-B29C-64091E11D9CD@gmail.com> Date: Mon, 27 Oct 2014 11:44:56 -0400 To: Netconf Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/5aXu9Z36eyteZ5ZGidxSaXg58lQ Subject: [Netconf] Fwd: New Version Notification for draft-mahesh-netconf-persistent-00.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: Mon, 27 Oct 2014 15:45:16 -0000 --Apple-Mail-EA984998-EB3C-4D40-B350-49A92C605F54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I had taken an action item during one of the interim meetings to come up wit= h a draft to address support for commands such as ping and traceroute in a N= ETCONF setup. This short draft takes a stab at defining the problem statement, a set of re= quirements and at least one solution. Should make for some easy reading. Mahesh Jethanandani mjethanandani@gmail.com Begin forwarded message: > From: internet-drafts@ietf.org > Date: October 27, 2014 at 8:10:16 AM EDT > To: "Mahesh Jethanandani" , Mahesh Jethanandani <= mjethanandani@gmail.com> > Subject: New Version Notification for draft-mahesh-netconf-persistent-00.t= xt >=20 >=20 > A new version of I-D, draft-mahesh-netconf-persistent-00.txt > has been successfully submitted by Mahesh Jethanandani and posted to the > IETF repository. >=20 > Name: draft-mahesh-netconf-persistent > Revision: 00 > Title: NETCONF and persistent responses > Document date: 2014-10-27 > Group: Individual Submission > Pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-mahesh-netconf-p= ersistent-00.txt > Status: https://datatracker.ietf.org/doc/draft-mahesh-netconf-pers= istent/ > Htmlized: http://tools.ietf.org/html/draft-mahesh-netconf-persistent= -00 >=20 >=20 > Abstract: > This document outlines a solution for NETCONF operations that might > be initiated with a single request but require multiple responses to > be received, with an ability to terminate the operation at any time. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail-EA984998-EB3C-4D40-B350-49A92C605F54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I had taken an action item during one o= f the interim meetings to come up with a draft to address support for comman= ds such as ping and traceroute in a NETCONF setup.

= This short draft takes a stab at defining the problem statement, a set of re= quirements and at least one solution. Should make for some easy reading.
=
Mahesh Jethanandanimjethanandani@gmail.com

Begin f= orwarded message:

From: <= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org
<= b>Date: October 27, 2014 at 8:10:16 AM EDT
To: "Mahesh Jethana= ndani" <mjethanandani@gmail.co= m>, Mahesh Jethanandani <mjethanandani@gmail.com>
Subject: New Version Notifica= tion for draft-mahesh-netconf-persistent-00.txt


A new version of I-D= , draft-mahesh-netconf-persistent-00.txt
has been successful= ly submitted by Mahesh Jethanandani and posted to the
IETF r= epository.

Name:        = ;draft-mahesh-netconf-persistent
Revision:    00
Title:        NETCONF and persistent resp= onses
Document date:    2014-10-27
Group:        Individual Submission
Pag= es:        4
URL:    &nbs= p;       http://www.ietf.org/i= nternet-drafts/draft-mahesh-netconf-persistent-00.txt
St= atus:         https://datatracker.= ietf.org/doc/draft-mahesh-netconf-persistent/
Htmlized: &= nbsp;     http://tools.ietf.org/html/draft-mahesh-net= conf-persistent-00


Abs= tract:
  This document outlines a solution for NE= TCONF operations that might
  be initiated with a= single request but require multiple responses to
 &nb= sp;be received, with an ability to terminate the operation at any time.




Please note that it may take a couple of minutes from the time of submis= sion
until the htmlized version and diff are available at tools.ietf.org.
<= br>The IETF Secretariat

= = --Apple-Mail-EA984998-EB3C-4D40-B350-49A92C605F54-- From nobody Mon Oct 27 15:30: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 56F711A1AF6; Mon, 27 Oct 2014 15:30:49 -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 9dnPZJ7KAQ8P; Mon, 27 Oct 2014 15:30:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0DD1A0AF8; Mon, 27 Oct 2014 15:30:47 -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.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027223047.23918.15060.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 15:30:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/As1Qktsn_cnasGmRn9vkIHoejqM Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-01.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, 27 Oct 2014 22:30:49 -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 : Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) Authors : Kent Watsen Stephen Hanna Joe Marcus Clarke Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-01.txt Pages : 37 Date : 2014-10-27 Abstract: This draft presents a technique for establishing a secure NETCONF connection between a newly deployed IP-based device, configured with just its factory default settings, and the new owner's Network Management System (NMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-zerotouch-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-01 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 Oct 27 15:35: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 94EBB1A1B85 for ; Mon, 27 Oct 2014 15:35:07 -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 UFxMoAYHI-wV for ; Mon, 27 Oct 2014 15:35:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD72C1A1B3A for ; Mon, 27 Oct 2014 15:34:21 -0700 (PDT) Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by CO1PR05MB298.namprd05.prod.outlook.com (10.141.70.25) with Microsoft SMTP Server (TLS) id 15.1.6.9; Mon, 27 Oct 2014 22:33:57 +0000 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.1.6.9; Mon, 27 Oct 2014 22:33:55 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.172]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.172]) with mapi id 15.01.0006.000; Mon, 27 Oct 2014 22:33:55 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-01.txt Thread-Index: AQHP8jWxh+zEheGhWEWCzO848x3mUJxERLYA Date: Mon, 27 Oct 2014 22:33:55 +0000 Message-ID: References: <20141027223047.23918.15060.idtracker@ietfa.amsl.com> In-Reply-To: <20141027223047.23918.15060.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.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;UriScan:; x-forefront-prvs: 0377802854 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(51704005)(24454002)(377454003)(479174003)(189002)(199003)(19580395003)(122556002)(77096002)(20776003)(80022003)(92726001)(15202345003)(92566001)(19580405001)(40100003)(230783001)(86362001)(15975445006)(2501002)(76482002)(85306004)(120916001)(101416001)(83506001)(66066001)(46102003)(99396003)(64706001)(97736003)(85852003)(107046002)(21056001)(36756003)(31966008)(105586002)(4396001)(95666004)(99286002)(106116001)(50986999)(2656002)(54356999)(110136001)(106356001)(107886001)(2351001)(76176999)(87936001); 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: <7CDE5D94184DE24C82275E5901487B12@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB298; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/BDulkC2AczgsV2HHTPjrFxn6y1M Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-01.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: Mon, 27 Oct 2014 22:35:07 -0000 This update has the following changes: - Added boot-image and validate-owner annotations to the "Actors and Roles" diagram - Fixed 2nd paragrph in section 7.1 to reflect current use of anyxml - Added encrypted and signed-encrypted examples - Replaced YANG module with XSD schema - Added IANA request for the ZeroTouch Information DHCP Option - Added IANA request for media types for boot-image and configuration Cheers, Kent On 10/27/14, 6:30 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 : Zero Touch Provisioning for NETCONF Call Home >(ZeroTouch) > Authors : Kent Watsen > Stephen Hanna > Joe Marcus Clarke > Mikael Abrahamsson > Filename : draft-ietf-netconf-zerotouch-01.txt > Pages : 37 > Date : 2014-10-27 > >Abstract: > This draft presents a technique for establishing a secure NETCONF > connection between a newly deployed IP-based device, configured with > just its factory default settings, and the new owner's Network > Management System (NMS). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-zerotouch-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-zerotouch-01 > > >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 Oct 29 05:14: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 5F75C1A007B for ; Wed, 29 Oct 2014 05:14:23 -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 bK57N8FWC0Ls for ; Wed, 29 Oct 2014 05:14: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 C16F61A0076 for ; Wed, 29 Oct 2014 05:14:19 -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 1XjS8m-0007bU-5H for netconf@ietf.org; Wed, 29 Oct 2014 13:14:17 +0100 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 1XjS8m-0007jb-18 for netconf@ietf.org; Wed, 29 Oct 2014 13:14:16 +0100 Message-ID: <5450DA17.8040403@bwijnen.net> Date: Wed, 29 Oct 2014 13:14:15 +0100 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: <88F56A4D-804E-44CB-A2EF-28892985EC50@lucidvision.com> In-Reply-To: <88F56A4D-804E-44CB-A2EF-28892985EC50@lucidvision.com> X-Forwarded-Message-Id: <88F56A4D-804E-44CB-A2EF-28892985EC50@lucidvision.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: 86ab03e524994f79ca2c75a176445dd4d5452661c8ebc3a824326d4c18a2f456 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ytd4oBC1FlYWscGbSDy1IcNsWkU Subject: [Netconf] Fwd: open config pushes open routing 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: Wed, 29 Oct 2014 12:14:23 -0000 FYI for those of you who are not on netmod list -------- Forwarded Message -------- Subject: open config pushes open routing model Date: Wed, 29 Oct 2014 07:49:43 -0400 From: Thomas D. Nadeau To: NETMOD Working Group , rtg-yang-coord@ietf.org CC: Mehmet >> Ersue, Mehmet (NSN - DE/Munich) , Dan Romascanu , ext Bert Wijnen (IETF) FYI. https://www.sdncentral.com/news/google-openconfig-pushes-open-routing-model/2014/10/ —Tom From nobody Wed Oct 29 05:55:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB21A00AD for ; Wed, 29 Oct 2014 05:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sWyPZezPFkz for ; Wed, 29 Oct 2014 05:55:21 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D810F1A00AB for ; Wed, 29 Oct 2014 05:55:20 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9TCtI0A024474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Oct 2014 12:55:18 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9TCtIEh013230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Oct 2014 13:55:18 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Oct 2014 13:55:17 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.176]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0195.001; Wed, 29 Oct 2014 13:55:17 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: RFC5539bis Issues to decide in IETF 91 Thread-Index: Ac/zd5aR4K2jd/eAQYepD66aNjzxlw== Date: Wed, 29 Oct 2014 12:55:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195256CDDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5091 X-purgate-ID: 151667::1414587318-0000437E-BE0B9FCC/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/uzNwnzcCYGrURlfagvNT0iu-uFI Subject: [Netconf] RFC5539bis Issues to decide in IETF 91 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, 29 Oct 2014 12:55:23 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195256CDDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, unfortunately the authors of the rfc5539bis draft will not be in IETF 91 me= eting. Below are two issues Juergen and the co-chairs would like to clarify. As a preparation for the IETF 91 meeting please answer the questions below = by November 8, 2014 EOB PT. The co-chairs will lead to a conclusion and finalize the decision taking in= IETF 91 NETCONF session. Especially, please state for a) and b) separately, which options you prefer= and why. I.e. add your motivation/reasoning for your choices/answers. a) Should the document become "NC over TLS with mutual X.509 authentication" and hence a different auth scheme requires another "NC over TLS with FOOBAR authentication" document or should the document be NC over TLS and we find some other way to say "if you do X.509 mutual authentication, then you have to do what is defined here; other forms of authentication may be defined in future documents". b) Should RFC 5539bis detail the algorithm how to extract a username from a certificate and then the server config model refers to that algorithm (this allows someone to implement RFC 5539bis without having to have the server config model implemented) or shall we leave the way a username is extract to the server config model document. Regards, Mehmet and Bert --_000_E4DE949E6CE3E34993A2FF8AE79131F8195256CDDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
unfortunately the authors of the rfc5539bis dr= aft will not be in IETF 91 meeting.
Below are two issues Juergen and the co-chairs= would like to clarify.
 
As a preparation for the IETF 91 meeting pleas= e answer the questions below by November 8, 2014 EOB PT.
The co-chairs will lead to a conclusion and fi= nalize the decision taking in IETF 91 NETCONF session.
 
Especially, please state for a) and b) separat= ely, which options you prefer and why.
I.e. add your motivation/reasoning for your ch= oices/answers.
 
a) Should the document become "NC over TL= S with mutual X.509
   authentication" and hence a = different auth scheme requires another
   "NC over TLS with FOOBAR aut= hentication" document or should the
   document be NC over TLS and we fi= nd some other way to say "if you
   do X.509 mutual authentication, t= hen you have to do what is defined
   here; other forms of authenticati= on may be defined in future
   documents".
 
b) Should RFC 5539bis detail the algorithm how= to extract a username
   from a certificate and then the s= erver config model refers to that
   algorithm (this allows someone to= implement RFC 5539bis without
   having to have the server config = model implemented) or shall we
   leave the way a username is extra= ct to the server config model
   document.
 
Regards,
Mehmet and Bert
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195256CDDEMUMBX005nsnin_-- From nobody Thu Oct 30 02:23: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 E9A911AD05B for ; Thu, 30 Oct 2014 02:23:37 -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 g-9zNsZbHIp4 for ; Thu, 30 Oct 2014 02:23:34 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::701]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655E01AD04B for ; Thu, 30 Oct 2014 02:23:34 -0700 (PDT) Received: from pc6 (86.184.62.161) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.6.9; Thu, 30 Oct 2014 09:16:22 +0000 Message-ID: <004101cff421$d3569a40$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Martin Bjorklund , Alan Luchuk References: <201410201458.s9KEw5Qm064083@mainfs.snmp.com> <03ae01cfed3c$50d39d20$4001a8c0@gateway.2wire.net> <20141021153455.GA91264@elstar.local> <021801cfeea0$4d7ab860$4001a8c0@gateway.2wire.net> <20141027145542.GB8819@elstar.local> Date: Thu, 30 Oct 2014 09:13:47 +0000 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.62.161] X-ClientProxiedBy: AM3PR01CA026.eurprd01.prod.exchangelabs.com (10.141.191.16) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) X-MS-Exchange-Transport-FromEntityHeader: Hosted X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Forefront-PRVS: 038002787A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(377454003)(164054003)(51704005)(13464003)(24454002)(87976001)(106356001)(92566001)(86362001)(20776003)(66066001)(77156001)(93916002)(50226001)(40100003)(80022003)(19580395003)(92726001)(50986999)(15975445006)(122386002)(19580405001)(23756003)(87286001)(84392001)(50466002)(64706001)(62236002)(44736004)(47776003)(89996001)(46102003)(85852003)(44716002)(62966002)(4396001)(15202345003)(88136002)(81816999)(116806002)(105586002)(31966008)(21056001)(14496001)(76482002)(95666004)(107046002)(97736003)(42186005)(104166001)(76176999)(101416001)(120916001)(33646002)(81686999)(61296003)(85306004)(102836001)(99396003)(77096002)(93886004)(74416001)(7059028)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UkPfJxDRcQTIKD8bpiHRUTI7VMw Cc: netconf@ietf.org Subject: Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication 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, 30 Oct 2014 09:23:38 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: "Kent Watsen" ; Sent: Monday, October 27, 2014 2:55 PM > > the editor does not understand the edits since I do not see clear > agreement of the scope of the document and thus there won't be a new > version before the cutoff. It makes a major difference to me > whether the document is > > - NC over TLS with mutual X.509 authentication > > or > > - NC over TLS plus a structure to plug in new authentication > mechanisms I think that limiting this I-D to mutual X.509 authentication resolves the issues that have been raised. Juergen commented on the mix of MAY, MUST etc causing confusion and that becomes simpler when there is just one approach to be specified. Martin commented on not knowing what to do about other forms of authentication - well, keep them out of this I-D and let anyone who wants to produce a separate I-D thereon. After all, the specification of TLS, and of SSH, is littered with I-Ds adding new forms of authentication so that would be nothing new. Tom Petch > and it is not clear whether > > - we details the algorithm to extract a username out of an X.509 > certificate in this spec > > or > > - leave it to the server configuration model. > > If fact, we would be duplicating some elements from RFC 6353 and the > reusable YANG grouping is in draft-ietf-netmod-snmp-cfg-08 (yes, an > interesting dependency chain results from that). > > I think the WG needs to sort out what set of documents is wanted > before making further edits. > > /js > > On Thu, Oct 23, 2014 at 10:04:00AM +0100, t. petch wrote: > > ---- Original Message ----- > > From: "Kent Watsen" > > To: "Juergen Schoenwaelder" ; "t. > > petch" > > Cc: > > Sent: Wednesday, October 22, 2014 7:29 PM > > > > >RFC 5539 has used X.509 certificates and nobody seems to request any > > >changes. Why do you make this complicated? > > > > > >Yes, NC access control is different from SNMP access control but this > > >is irrelevant. All the transport has to deliver is a user name. Why do > > >we have to make this complicated? > > > > I kind of agree with both sides. > > > > On one hand, 5539bis-06 clearly intends to define mutual > > certificate-based > > authentication - just search for the word "mutual". Additionally, > > Juergen > > already explained that he put PSK in (-02, according to the change log ) > > to support NETCONF-light, and since took it out. So we're essentially > > back to just trying to clean up 5539 and make it be in-line with NETCONF > > 1.1. > > > > On the other hand, there are a couple issues with 5539bis-06: > > > > 1) section 2.4.2 (Client Identity) doesn't actually say that > > certificate-based authentication is required. For instance, this text > > from RFC5539 was left out: "with certificate-based authentication > > according to local policy" > > > > 2) I'm confused by these seemingly conflicting statements: > > > > - section 2.4 (X.509-based Authentication...) says "Implementations > > MAY > > optionally > > support TLS certificate-based authentication" > > - section 2.5 (Cipher Suites) says "However, implementations MUST > > support TLS 1.2". > > > > So, to Juergen's point, I don't think this needs to be complicated, but > > I > > do think we need to be methodical about ensuring the text says what we > > want it to say. > > > > > > > > Kent > > > > This is what I keep saying or at least, try to say - not sure how clear > > I am being. But until those loose ends of text are removed, then > > 5539bis remains ambiguous IMHO (and I then remain reluctant to move on > > to other issues and other I-Ds). > > > > I would go slightly further and change the title and Intro. Martin > > raised the point about this I-D seeming to exclude other forms of > > authentication with TLS so I would entitle this one > > > > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > > X.509 Certificates" > > > > Then anyone is free to write another I-D entitled > > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > > PAKE" > > or > > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > > PSK" > > etc etc > > > > That leaves us free to be as 'MUST' as we like about authentication, > > because our use case is simple. > > > > I want to see a fresh I-D along these lines - but see below ... > > > > > > > > One last point, I'm opposed to 5539bis using > > draft-ietf-netconf-server-model as a Normative Reference. I believe > > that > > 5539bis should define the protocol on its own, and view > > draft-ietf-netconf-server-model as just one data-model that could > > configure it. FWIW, neither 6242 nor draft-ietf-netconf-call-home have > > a > > Normative Reference draft-ietf-netconf-server-model. > > > > > > suive ... There is another issue in here. RFC6241 mandates > > "The authentication process MUST result in an authenticated client > > identity whose permissions are known to the server." > > which suggests we should say something about how. 5539bis did have text > > about this but that is now in server-model. Which sort of leads to > > having a normative dependency of 5539bis on server-model, not for > > configuration reasons but for the algorithm used to extract an > > authenticated client identity from what information the server has > > gotten.. > > > > But I do see this as a separate, more debatable issue, to be discussed > > once there is clarity in the published I-D about the use of > > certificates. And I do think that the document structure is right, that > > is, how to extract the identity does belong in server-model and not in > > TLS or SSH or other transport I-Ds. > > > > Tom Petch > > > > Thanks, > > Kent > > > > -- > 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 Oct 30 07:34: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 9C1B91A00FB for ; Thu, 30 Oct 2014 07:34:13 -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 wCGhAtEaxhaJ for ; Thu, 30 Oct 2014 07:34:10 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::735]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D841A00E6 for ; Thu, 30 Oct 2014 07:34:09 -0700 (PDT) Received: from pc6 (86.184.62.161) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.1.11.14; Thu, 30 Oct 2014 14:15:55 +0000 Message-ID: <048801cff44b$aba6e5c0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Alan Luchuk References: <201410201458.s9KEw5Qm064083@mainfs.snmp.com> <03ae01cfed3c$50d39d20$4001a8c0@gateway.2wire.net> <20141021153455.GA91264@elstar.local> <021801cfeea0$4d7ab860$4001a8c0@gateway.2wire.net> <20141027145542.GB8819@elstar.local> Date: Thu, 30 Oct 2014 11:28:51 +0000 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.62.161] X-ClientProxiedBy: AM3PR01CA048.eurprd01.prod.exchangelabs.com (10.141.191.38) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) X-MS-Exchange-Transport-FromEntityHeader: Hosted X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057; X-Forefront-PRVS: 038002787A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(164054003)(13464003)(377454003)(51704005)(189002)(77096002)(62236002)(44716002)(47776003)(20776003)(61296003)(42186005)(89996001)(50466002)(106356001)(76482002)(80022003)(46102003)(95666004)(105586002)(107046002)(120916001)(64706001)(33646002)(66066001)(23756003)(81686999)(81816999)(116806002)(87286001)(104166001)(19580395003)(76176999)(50986999)(93886004)(86362001)(62966002)(93916002)(85306004)(19580405001)(102836001)(84392001)(15975445006)(15202345003)(97736003)(88136002)(122386002)(85852003)(21056001)(87976001)(31966008)(101416001)(40100003)(92726001)(50226001)(92566001)(4396001)(77156001)(44736004)(7059028); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Qh_VtCDSMVuByYIjgNOIXqQ8zOU Cc: netconf@ietf.org Subject: Re: [Netconf] rfc5539bis- leave it to the server configuration 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: Thu, 30 Oct 2014 14:34:13 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: "Kent Watsen" ; Sent: Monday, October 27, 2014 2:55 PM > the editor does not understand the edits since I do not see clear > agreement of the scope of the document and thus there won't be a new > version before the cutoff. It makes a major difference to me > whether the document is > > - NC over TLS with mutual X.509 authentication > > or > > - NC over TLS plus a structure to plug in new authentication > mechanisms > > and it is not clear whether > > - we details the algorithm to extract a username out of an X.509 > certificate in this spec > > or > > - leave it to the server configuration model. I think that the right place for this is in the server configuration model. Alan made the point that he wanted to keep this in line with SNMP, and that is exactly what this would do. SNMP puts the details in the MIB DESCRIPTION so the parallel would be to put it in the YANG model. And it means we will ultimately have it in just the one place, as opposed to having parallel and perhaps different definitions for TLS and, e.g., SSH. Tom Petch > If fact, we would be duplicating some elements from RFC 6353 and the > reusable YANG grouping is in draft-ietf-netmod-snmp-cfg-08 (yes, an > interesting dependency chain results from that). > > I think the WG needs to sort out what set of documents is wanted > before making further edits. > > /js > > On Thu, Oct 23, 2014 at 10:04:00AM +0100, t. petch wrote: > > ---- Original Message ----- > > From: "Kent Watsen" > > To: "Juergen Schoenwaelder" ; "t. > > petch" > > Cc: > > Sent: Wednesday, October 22, 2014 7:29 PM > > > > >RFC 5539 has used X.509 certificates and nobody seems to request any > > >changes. Why do you make this complicated? > > > > > >Yes, NC access control is different from SNMP access control but this > > >is irrelevant. All the transport has to deliver is a user name. Why do > > >we have to make this complicated? > > > > I kind of agree with both sides. > > > > On one hand, 5539bis-06 clearly intends to define mutual > > certificate-based > > authentication - just search for the word "mutual". Additionally, > > Juergen > > already explained that he put PSK in (-02, according to the change log ) > > to support NETCONF-light, and since took it out. So we're essentially > > back to just trying to clean up 5539 and make it be in-line with NETCONF > > 1.1. > > > > On the other hand, there are a couple issues with 5539bis-06: > > > > 1) section 2.4.2 (Client Identity) doesn't actually say that > > certificate-based authentication is required. For instance, this text > > from RFC5539 was left out: "with certificate-based authentication > > according to local policy" > > > > 2) I'm confused by these seemingly conflicting statements: > > > > - section 2.4 (X.509-based Authentication...) says "Implementations > > MAY > > optionally > > support TLS certificate-based authentication" > > - section 2.5 (Cipher Suites) says "However, implementations MUST > > support TLS 1.2". > > > > So, to Juergen's point, I don't think this needs to be complicated, but > > I > > do think we need to be methodical about ensuring the text says what we > > want it to say. > > > > > > > > Kent > > > > This is what I keep saying or at least, try to say - not sure how clear > > I am being. But until those loose ends of text are removed, then > > 5539bis remains ambiguous IMHO (and I then remain reluctant to move on > > to other issues and other I-Ds). > > > > I would go slightly further and change the title and Intro. Martin > > raised the point about this I-D seeming to exclude other forms of > > authentication with TLS so I would entitle this one > > > > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > > X.509 Certificates" > > > > Then anyone is free to write another I-D entitled > > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > > PAKE" > > or > > " Using the NETCONF Protocol over Transport Layer Security (TLS) with > > PSK" > > etc etc > > > > That leaves us free to be as 'MUST' as we like about authentication, > > because our use case is simple. > > > > I want to see a fresh I-D along these lines - but see below ... > > > > > > > > One last point, I'm opposed to 5539bis using > > draft-ietf-netconf-server-model as a Normative Reference. I believe > > that > > 5539bis should define the protocol on its own, and view > > draft-ietf-netconf-server-model as just one data-model that could > > configure it. FWIW, neither 6242 nor draft-ietf-netconf-call-home have > > a > > Normative Reference draft-ietf-netconf-server-model. > > > > > > suive ... There is another issue in here. RFC6241 mandates > > "The authentication process MUST result in an authenticated client > > identity whose permissions are known to the server." > > which suggests we should say something about how. 5539bis did have text > > about this but that is now in server-model. Which sort of leads to > > having a normative dependency of 5539bis on server-model, not for > > configuration reasons but for the algorithm used to extract an > > authenticated client identity from what information the server has > > gotten.. > > > > But I do see this as a separate, more debatable issue, to be discussed > > once there is clarity in the published I-D about the use of > > certificates. And I do think that the document structure is right, that > > is, how to extract the identity does belong in server-model and not in > > TLS or SSH or other transport I-Ds. > > > > Tom Petch > > > > Thanks, > > Kent > > > > -- > 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 Oct 30 20:58: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 ACED11A8A83 for ; Thu, 30 Oct 2014 20:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 xSwktzfZXju4 for ; Thu, 30 Oct 2014 20:58:25 -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 F2F171A8A96 for ; Thu, 30 Oct 2014 20:58:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOG11770; Fri, 31 Oct 2014 03:58:23 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 03:58:21 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 11:58:14 +0800 From: Qin Wu To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf Thread-Topic: RFC5539bis Issues to decide in IETF 91 Thread-Index: Ac/zd5aR4K2jd/eAQYepD66aNjzxlwBRCagg Date: Fri, 31 Oct 2014 03:58:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84625BEAnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JShy6mnpPZcPdUqwpOPn89XrTMo Subject: Re: [Netconf] RFC5539bis Issues to decide in IETF 91 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, 31 Oct 2014 03:58:27 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84625BEAnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 t6K8/sjLOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEVy c3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCkNCreiy83KsbzkOiAyMDE0xOoxMNTCMjnI1SAy MDo1NQ0KytW8/sjLOiBuZXRjb25mDQrW98ziOiBbTmV0Y29uZl0gUkZDNTUzOWJpcyBJc3N1ZXMg dG8gZGVjaWRlIGluIElFVEYgOTENCg0KRGVhciBORVRDT05GIFdHLA0KDQp1bmZvcnR1bmF0ZWx5 IHRoZSBhdXRob3JzIG9mIHRoZSByZmM1NTM5YmlzIGRyYWZ0IHdpbGwgbm90IGJlIGluIElFVEYg OTEgbWVldGluZy4NCkJlbG93IGFyZSB0d28gaXNzdWVzIEp1ZXJnZW4gYW5kIHRoZSBjby1jaGFp cnMgd291bGQgbGlrZSB0byBjbGFyaWZ5Lg0KDQpBcyBhIHByZXBhcmF0aW9uIGZvciB0aGUgSUVU RiA5MSBtZWV0aW5nIHBsZWFzZSBhbnN3ZXIgdGhlIHF1ZXN0aW9ucyBiZWxvdyBieSBOb3ZlbWJl ciA4LCAyMDE0IEVPQiBQVC4NClRoZSBjby1jaGFpcnMgd2lsbCBsZWFkIHRvIGEgY29uY2x1c2lv biBhbmQgZmluYWxpemUgdGhlIGRlY2lzaW9uIHRha2luZyBpbiBJRVRGIDkxIE5FVENPTkYgc2Vz c2lvbi4NCg0KRXNwZWNpYWxseSwgcGxlYXNlIHN0YXRlIGZvciBhKSBhbmQgYikgc2VwYXJhdGVs eSwgd2hpY2ggb3B0aW9ucyB5b3UgcHJlZmVyIGFuZCB3aHkuDQpJLmUuIGFkZCB5b3VyIG1vdGl2 YXRpb24vcmVhc29uaW5nIGZvciB5b3VyIGNob2ljZXMvYW5zd2Vycy4NCg0KYSkgU2hvdWxkIHRo ZSBkb2N1bWVudCBiZWNvbWUgIk5DIG92ZXIgVExTIHdpdGggbXV0dWFsIFguNTA5DQogICBhdXRo ZW50aWNhdGlvbiIgYW5kIGhlbmNlIGEgZGlmZmVyZW50IGF1dGggc2NoZW1lIHJlcXVpcmVzIGFu b3RoZXINCiAgICJOQyBvdmVyIFRMUyB3aXRoIEZPT0JBUiBhdXRoZW50aWNhdGlvbiIgZG9jdW1l bnQgb3Igc2hvdWxkIHRoZQ0KICAgZG9jdW1lbnQgYmUgTkMgb3ZlciBUTFMgYW5kIHdlIGZpbmQg c29tZSBvdGhlciB3YXkgdG8gc2F5ICJpZiB5b3UNCiAgIGRvIFguNTA5IG11dHVhbCBhdXRoZW50 aWNhdGlvbiwgdGhlbiB5b3UgaGF2ZSB0byBkbyB3aGF0IGlzIGRlZmluZWQNCiAgIGhlcmU7IG90 aGVyIGZvcm1zIG9mIGF1dGhlbnRpY2F0aW9uIG1heSBiZSBkZWZpbmVkIGluIGZ1dHVyZQ0KICAg ZG9jdW1lbnRzIi4NCg0KW1Fpbl06IEl0IGRvZXNuoa90IG1ha2Ugc2Vuc2UsIGluIG15IG9waW5p b24sIHRvIGNyZWF0ZSBhIG5ldyBkb2N1bWVudCBlYWNoIHRpbWUgd2hlbiBhIG5ldyBhdXRoIHNj aGVtZSBjb21lcyB1cC4NCkhhdmluZyBSRkM1NTM5YmlzIGFzIGEgY29tcHJlaGVuc2l2ZSBkb2N1 bWVudCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgY2hvaWNlLiBBbHNvIG11dHVhbCBYLjUwOSBhdXRo ZW50aWNhdGlvbiBpcyBqdXN0IGEgb3B0aW9uYWwNCmZlYXR1cmUgc3VwcG9ydGVkIGJ5IE5DIG92 ZXIgVExTLg0KDQpiKSBTaG91bGQgUkZDIDU1MzliaXMgZGV0YWlsIHRoZSBhbGdvcml0aG0gaG93 IHRvIGV4dHJhY3QgYSB1c2VybmFtZQ0KICAgZnJvbSBhIGNlcnRpZmljYXRlIGFuZCB0aGVuIHRo ZSBzZXJ2ZXIgY29uZmlnIG1vZGVsIHJlZmVycyB0byB0aGF0DQogICBhbGdvcml0aG0gKHRoaXMg YWxsb3dzIHNvbWVvbmUgdG8gaW1wbGVtZW50IFJGQyA1NTM5YmlzIHdpdGhvdXQNCiAgIGhhdmlu ZyB0byBoYXZlIHRoZSBzZXJ2ZXIgY29uZmlnIG1vZGVsIGltcGxlbWVudGVkKSBvciBzaGFsbCB3 ZQ0KICAgbGVhdmUgdGhlIHdheSBhIHVzZXJuYW1lIGlzIGV4dHJhY3QgdG8gdGhlIHNlcnZlciBj b25maWcgbW9kZWwNCiAgIGRvY3VtZW50Lg0KDQpbUWluXTogSSBmYXZvciByZW1vdmluZyBjcm9z cyByZWZlcmVuY2UgYmV0d2VlbiBSRkM1NTM5YmlzIGFuZCBkcmFmdC1pZXRmLW5ldGNvbmYtc2Vy dmVyLW1vZGVsLTA0Lg0KU3BlY2lmeWluZyB0aGUgYWxnb3JpdGhtIG9uIGhvdyB0byBleHRyYWN0 IGEgdXNlcm5hbWUgZnJvbSBhIGNlcnRpZmljYXRlIHdpdGhpbiBSRkM1NTM5YmlzIG1vcmUgbWFr ZXMgc2Vuc2UgdG8gbWUuDQoNClJlZ2FyZHMsDQpNZWhtZXQgYW5kIEJlcnQNCg0K --_000_B8F9A780D330094D99AF023C5877DABA84625BEAnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

=B7=A2=BC=FE=C8=CB: Netconf= [mailto:netconf-bounces@ietf.org] =B4=FA= =B1=ED Ersue, Mehmet (NSN - DE/Munich)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA10=D4=C229=C8=D5 20:55
=CA=D5=BC=FE=C8=CB: netconf
=D6=F7=CC=E2: [Netconf] RFC5539bis Issues to decide in IETF 91=

 

Dear NETCON= F WG,

 

unfortunate= ly the authors of the rfc5539bis draft will not be in IETF 91 meeting.

Below are t= wo issues Juergen and the co-chairs would like to clarify.

 

As a prepar= ation for the IETF 91 meeting please answer the questions below by November= 8, 2014 EOB PT.

The co-chai= rs will lead to a conclusion and finalize the decision taking in IETF 91 NE= TCONF session.

 

Especially,= please state for a) and b) separately, which options you prefer and why.

I.e. add yo= ur motivation/reasoning for your choices/answers.

 

a) Should t= he document become "NC over TLS with mutual X.509

  = ; authentication" and hence a different auth scheme requires another

  = ; "NC over TLS with FOOBAR authentication" document or should the=

  = ; document be NC over TLS and we find some other way to say "if you

  = ; do X.509 mutual authentication, then you have to do what is defined

  = ; here; other forms of authentication may be defined in future

  = ; documents".

 = ;

[Qin]: It = doesn=A1=AFt make sense, in my opinion, to create a new document each time = when a new auth scheme comes up.

Having RFC= 5539bis as a comprehensive document seems more reasonable choice. Also mutu= al X.509 authentication is just a optional

feature su= pported by NC over TLS.

 

b) Should R= FC 5539bis detail the algorithm how to extract a username

  = ; from a certificate and then the server config model refers to that=

  = ; algorithm (this allows someone to implement RFC 5539bis without

  = ; having to have the server config model implemented) or shall we

  = ; leave the way a username is extract to the server config model

  = ; document.

 

[Qin]: I f= avor removing cross reference between RFC5539bis and draft-ietf-netconf-ser= ver-model-04.

Specifying= the algorithm on how to extract a username from a certificate within RFC55= 39bis more makes sense to me.

 = ;

Regards,

Mehmet and = Bert

 

--_000_B8F9A780D330094D99AF023C5877DABA84625BEAnkgeml501mbschi_-- From nobody Thu Oct 30 21:14: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 69F5C1A8A98 for ; Thu, 30 Oct 2014 21:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0Uc6Uu_w1LYP for ; Thu, 30 Oct 2014 21:14:37 -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 D0CBE1A8A9E for ; Thu, 30 Oct 2014 21:14:36 -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 BLD07050; Fri, 31 Oct 2014 04:14:35 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 31 Oct 2014 04:14:34 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 31 Oct 2014 12:14:31 +0800 From: Qin Wu To: Juergen Schoenwaelder Thread-Topic: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 Thread-Index: AQHP4S06jPg1u++jTUq2pIkkEYRBtJwjEoS2gAWXgwCAAOvVz///k7QAgAANBICAAAuKgIAGRnzy//+O+QCAA2XFQIAE8A8AgBJQ51A= Date: Fri, 31 Oct 2014 04:14:30 +0000 Message-ID: References: <20141010.125922.123878611.mbj@tail-f.com> <013b01cfe4ab$45a956e0$4001a8c0@gateway.2wire.net> <20141010.212225.300681995.mbj@tail-f.com> <061701cfe7a5$19605f00$4001a8c0@gateway.2wire.net> <20141014130900.GA70425@elstar.local> <20141019202616.GA85744@elstar.local> In-Reply-To: <20141019202616.GA85744@elstar.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HiH5W8gsQfXj17MUQTO1Y-m4eP8 Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-06 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, 31 Oct 2014 04:14:39 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRv Omouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gDQq3osvNyrG85DogMjAxNMTq MTDUwjIwyNUgNDoyNg0KytW8/sjLOiBRaW4gV3UNCrOty806IHQuIHBldGNoOyBuZXRjb25mQGll dGYub3JnDQrW98ziOiBSZTogW05ldGNvbmZdIGNvbW1lbnQgb24gZHJhZnQtaWV0Zi1uZXRjb25m LXJmYzU1MzliaXMtMDYNCg0KT24gVGh1LCBPY3QgMTYsIDIwMTQgYXQgMDk6MTM6MDJBTSArMDAw MCwgUWluIFd1IHdyb3RlOg0KPiANCj4gSSB3YXMgcHVzaGluZyBmb3IgUFNLIGF1dGhlbnRpY2F0 aW9uIGJhY2sgaW4gYSBkYXkgd2hlbiB3ZSBkaWQgTkMgbGlnaHQuIEkgdGhpbmsgaXQgaXMgbWVh bndoaWxlIGNsZWFyIHRoYXQgTkMgbGlnaHQgaXMgbm90IGEgdmlhYmxlIG9wdGlvbiBhbmQgaGVu Y2UgSSBwcm9wb3NlZCB0byByZW1vdmUgUFNLIGF1dGhlbnRpY2F0aW9uIGF0IHRoZSBUb3JvbnRv IG1lZXRpbmcgYXMgbm90IG1hbnkgcGVvcGxlIHNlZW0gdG8gY2FyZSB0byBpbXBsZW1lbnQgdGhp cyAoc2xpZGUgIzcgb2YgbXkgc2xpZGUgc2V0KS4gUGVyaGFwcyB0aGUgY2hhaXJzIHNob3VsZCBk byBhbiBleHBsaWNpdCBjYWxsIGZvciBjb25jZW5zdXMgb24gdGhpcyBzbyB0aGF0IHdlIGNhbiBt b3ZlIG9uLg0KPiANCj4gW1Fpbl06IEFyZSB5b3Ugc2F5aW5nIGNvbnN0cmFpbmVkIGRldmljZSB3 aWxsIG5vdCBiZSBzdXBwb3J0ZWQgYnkgdGhpcyBkcmFmdD8NCj4gDQoNCllvdSBuZWVkIHRvIHNh eSBtb3JlIGNsZWFybHkgd2hhdCB5b3UgbWVhbiB3aXRoICdjb25zdHJhaW5lZCBkZXZpY2VzJw0K YmVmb3JlIEkgY2FuIGFuc3dlciB0aGlzLg0KDQpKdXN0IGZvciBjdXJpb3NpdHksIHRoZSBjb25z dHJhaW5lZCBkZXZpY2UgSSBhbSByZWZlcnJlZCB0byBpcyB0aGUgZGV2aWNlIHdpdGggc21hbGwg UkFNLCBsaW1pdGVkIHBvd2VyLCBsaW1pdGVkIHByb2Nlc3NpbmcgY2FwYWJpbGl0eS4NCkl0IGxv b2tzIHRoZXNlIGRldmljZXMgbW9yZSBmYXZvciB1c2luZyBSRVNUQ09ORi4NCi9qcw0KDQotLSAN Ckp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVu IGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4 NzU5IEJyZW1lbiwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= From nobody Fri Oct 31 03:51: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 1BF261A1AA4 for ; Fri, 31 Oct 2014 03:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bINfvAyX0L-r for ; Fri, 31 Oct 2014 03:51:47 -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 7FAEE1A19E5 for ; Fri, 31 Oct 2014 03:51:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4FF9EF8B; Fri, 31 Oct 2014 11:51:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id d5nwMPrHef8E; Fri, 31 Oct 2014 11:51:19 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 31 Oct 2014 11:51:45 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8403420038; Fri, 31 Oct 2014 11:51:45 +0100 (CET) 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 4gwk61_V5yeY; Fri, 31 Oct 2014 11:50:47 +0100 (CET) Received: from exchange.jacobs-university.de (shubcas04.jacobs.jacobs-university.de [10.70.0.154]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A536F20035; Fri, 31 Oct 2014 11:51:44 +0100 (CET) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS04.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0210.002; Fri, 31 Oct 2014 11:51:44 +0100 From: "Bajpai, Vaibhav" To: Qin Wu Thread-Topic: [Netconf] RFC5539bis Issues to decide in IETF 91 Thread-Index: Ac/zd5aR4K2jd/eAQYepD66aNjzxlwBRCaggAA0iVoA= Date: Fri, 31 Oct 2014 10:51:43 +0000 Message-ID: <1658B2EE-C98F-41F2-B313-400D568D08EC@jacobs-university.de> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: text/plain; charset="utf-8" Content-ID: <3D8D870EB63BFC40841DED0855931693@jacobs.jacobs-university.de> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FuwzbNPB9AnysvUPGjunzo87BLU Cc: netconf Subject: Re: [Netconf] RFC5539bis Issues to decide in IETF 91 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, 31 Oct 2014 10:51:49 -0000 DQo+IE9uIDMxIE9jdCAyMDE0LCBhdCAwNDo1OCwgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+ IHdyb3RlOg0KDQpbLi4uXQ0KDQo+IGEpIFNob3VsZCB0aGUgZG9jdW1lbnQgYmVjb21lICJOQyBv dmVyIFRMUyB3aXRoIG11dHVhbCBYLjUwOQ0KPiAgICBhdXRoZW50aWNhdGlvbiIgYW5kIGhlbmNl IGEgZGlmZmVyZW50IGF1dGggc2NoZW1lIHJlcXVpcmVzIGFub3RoZXINCj4gICAgIk5DIG92ZXIg VExTIHdpdGggRk9PQkFSIGF1dGhlbnRpY2F0aW9uIiBkb2N1bWVudCBvciBzaG91bGQgdGhlDQo+ ICAgIGRvY3VtZW50IGJlIE5DIG92ZXIgVExTIGFuZCB3ZSBmaW5kIHNvbWUgb3RoZXIgd2F5IHRv IHNheSAiaWYgeW91DQo+ICAgIGRvIFguNTA5IG11dHVhbCBhdXRoZW50aWNhdGlvbiwgdGhlbiB5 b3UgaGF2ZSB0byBkbyB3aGF0IGlzIGRlZmluZWQNCj4gICAgaGVyZTsgb3RoZXIgZm9ybXMgb2Yg YXV0aGVudGljYXRpb24gbWF5IGJlIGRlZmluZWQgaW4gZnV0dXJlDQo+ICAgIGRvY3VtZW50cyIu DQo+ICANCj4gW1Fpbl06IEl0IGRvZXNu4oCZdCBtYWtlIHNlbnNlLCBpbiBteSBvcGluaW9uLCB0 byBjcmVhdGUgYSBuZXcgZG9jdW1lbnQgZWFjaCB0aW1lIHdoZW4gYSBuZXcgYXV0aCBzY2hlbWUg Y29tZXMgdXAuDQo+IEhhdmluZyBSRkM1NTM5YmlzIGFzIGEgY29tcHJlaGVuc2l2ZSBkb2N1bWVu dCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgY2hvaWNlLg0KDQpJZGVhbGx5IHllcywgYnV0IGluIHBy YWN0aXNlIGl0IHdvdWxkIGJlIG11Y2ggZWFzaWVyIHRvIGRldmVsb3AgDQpjb25zZW5zdXMgd2l0 aCBzZXBhcmF0ZSBkb2N1bWVudHMgdGhhdCBoYXZlIGEgY3Jpc3BpZXIgc2NvcGUuDQoNCkJlc3Qs IFZhaWJoYXYNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NClZhaWJoYXYgQmFqcGFpDQoNClJlc2VhcmNoIEksIFJvb20gOTENCkNvbXB1dGVy IE5ldHdvcmtzIGFuZCBEaXN0cmlidXRlZCBTeXN0ZW1zICAoQ05EUykgTGFiDQpTY2hvb2wgb2Yg RW5naW5lZXJpbmcgYW5kIFNjaWVuY2VzDQpKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4sIEdlcm1h bnkNCg0Kd3d3LnZhaWJoYXZiYWpwYWkuY29tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQo= From nobody Fri Oct 31 07:20:23 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 8EFE81A8AA9 for ; Fri, 31 Oct 2014 07:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 S5OfmBYvMFy2 for ; Fri, 31 Oct 2014 07:20:12 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4420D1A9028 for ; Fri, 31 Oct 2014 07:20:05 -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 KAA08155; Fri, 31 Oct 2014 10:19:44 -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 s9VEJirC009063; Fri, 31 Oct 2014 10:19:44 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id s9VEJQWY009047; Fri, 31 Oct 2014 10:19:26 -0400 (EDT) (envelope-from luchuk) Date: Fri, 31 Oct 2014 10:19:26 -0400 (EDT) From: Alan Luchuk Message-Id: <201410311419.s9VEJQWY009047@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gS2DH_9pnaW_aWIRuzufWiEoWG4 Subject: Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication 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, 31 Oct 2014 14:20:17 -0000 Hello, >From: "Juergen Schoenwaelder" >To: "t. petch" >Cc: "Kent Watsen" ; >Sent: Monday, October 27, 2014 2:55 PM >> >> the editor does not understand the edits since I do not see clear >> agreement of the scope of the document and thus there won't be a new >> version before the cutoff. It makes a major difference to me >> whether the document is >> >> - NC over TLS with mutual X.509 authentication >> >> or >> >> - NC over TLS plus a structure to plug in new authentication >> mechanisms > >I think that limiting this I-D to mutual X.509 authentication resolves >the issues that have been raised. +1 > >Juergen commented on the mix of MAY, MUST etc causing confusion and that >becomes simpler when there is just one approach to be specified. > >Martin commented on not knowing what to do about other forms of >authentication - well, keep them out of this I-D and let anyone who >wants to produce a separate I-D thereon. After all, the specification >of TLS, and of SSH, is littered with I-Ds adding new forms of >authentication so that would be nothing new. > >Tom Petch > Also, included below is the following new proposed text for Section 2.4.1, and a new section 2.4.2. The new section 2.4.2 would displace the existing section 2.4.2 to have 2.4.3, and so on. Thoughts on this? Regards, --Alan Section 2.4.1 Verifying the NETCONF Server Identity ---------------------------------------------------- The NETCONF client MUST verify the identity of the NETCONF server. The NETCONF client MAY use the procedure documented in Section 2.4.2 to verify the identify of the NETCONF server. The NETCONF client MAY use an alternate procedure to verify the identity the NETCONF server. If the NETCONF client uses an alternate procedure to verify the identity of the NETCONF server, then the alternate procedure must provide a level of verification comparable to the procedure documented in Section 2.4.2. One example of an alternate procedure for verifying the NETCONF server's identity would be to compare the X.509 certificate presented by the NETCONF server against a local store of already-verified X.509 certificates and identity bindings. If the NETCONF client attempts to connect to a NETCONF server, and the NETCONF server fails the identity verification step, then the NETCONF client MUST notify the user that the NETCONF server identity verification failed, and 1) either terminate the connection, or 2) request user confirmation to proceed with the connection. Section 2.4.2 Standard Procedure for Verifying the NETCONF Server Identity --------------------------------------------------------------------------- If the NETCONF client uses this documented procedure to verify the identify of the NETCONF server, then the NETCONF client MUST follow follow this procedure completely. The NETCONF client MUST verify the integrity of the X.509 certificate presented by the NETCONF server. To do this, the NETCONF client MUST: - Use the certificate path validation algorithm described in Section 6 of [RFC 5280]. - Validate the X.509 certificate presented by the NETCONF server to a trust anchor configured in the NETCONF client. To prevent man-in-the-middle attacks, after verifying the integrity of X.509 certificate presented by the NETCONF server, the NETCONF client MUST verify the identity of the NETCONF server. To verify the identity of the NETCONF server: - The NETCONF client MUST have information about the expected identity of the NETCONF server to which it connected, and from which it received a presented X.509 certificate. This NETCONF server identity information MUST be pre-configured in the NETCONF client before it initiates the connection to the NETCONF server. - The X.509 certificate presented by the NETCONF server must contain information about the NETCONF server's identity. - The NETCONF client MUST extract the NETCONF server identity information from the X.509 certificate presented by the server. The NETCONF client MUST compare the extracted server identity to the pre-configured server identity information according to the rules and guidelines defined in [RFC 6125]. If the comparison succeeds, then the NETCONF server identity is verified, and the connection can proceed. If the comparison fails, then the NETCONF server identity verification has failed. The NETCONF client must handle the NETCONF server identity verification failure as documented above. From nobody Fri Oct 31 08:57: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 879E41ACD22 for ; Fri, 31 Oct 2014 08:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVXqsYrBwjrY for ; Fri, 31 Oct 2014 08:57:38 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1D01ACD23 for ; Fri, 31 Oct 2014 08:57:37 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s9VFvZEI019421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 31 Oct 2014 15:57:35 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s9VFvZHd010741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Oct 2014 16:57:35 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 31 Oct 2014 16:57:34 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.14]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0195.001; Fri, 31 Oct 2014 16:57:34 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: Draft Agenda for the IETF 91 NETCONF Session Thread-Index: Ac/1I2JNxjyaskpwS3qb4yNVOD65Pg== Date: Fri, 31 Oct 2014 15:57:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819537729DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 12183 X-purgate-ID: 151667::1414771055-00001FC1-A18FB81C/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1FJP82B_ipLKwEUxaIdozAMZeHI Subject: [Netconf] Draft Agenda for the IETF 91 NETCONF Session 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, 31 Oct 2014 15:57:41 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819537729DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, please find below the draft agenda for the NETCONF Session in IETF #91. Please send your comments to the co-chairs. Mehmet & Bert Agenda for the NETCONF WG Session in IETF 91 -------------------------------------------- IETF 91, Honolulu, November 9-14, 2014 TUESDAY, July 22, 2014 1300-1500 HAST - Tuesday Afternoon Session I Room: Lehua Suite WG Chairs: Bert Wijnen Mehmet Ersue Scribes (IF no_volunteers THEN wait_forever) Agenda bashing (2 minutes) WG status review (5 minutes) Chartered items: 1. NETCONF Call Home - K. Watsen (20 min.) http://tools.ietf.org/html/draft-ietf-netconf-call-home 2. RFC5539bis issue discussion - All (15 min.) http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis 3. NETCONF Server Configuration Model - K. Watsen (10 min.) http://tools.ietf.org/html/draft-ietf-netconf-server-model 4. RESTCONF Protocol - A. Bierman (20 min.) http://tools.ietf.org/html/draft-ietf-netconf-restconf 5. YANG Patch Media Type - A. Bierman (10 min.) http://tools.ietf.org/html/draft-ietf-netconf-yang-patch 6. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Wat= sen (20 min.) http://tools.ietf.org/html/draft-ietf-netconf-zerotouch Non-Chartered items: 1. NETCONF and persistent responses - M. Jethanandani (10min.) http://tools.ietf.org/html/draft-mahesh-netconf-persistent-00 2. A NETCONF Extension for Data Fragmentation - G. Zheng (10 min.) http://tools.ietf.org/html/draft-liu-netconf-fragmentation-01 Open mike: AOB --_000_E4DE949E6CE3E34993A2FF8AE79131F819537729DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
please find below the draft agenda for the NET= CONF Session in IETF #91.
 
Please send your comments to the co-chairs.
 
Mehmet & Bert
 
Agenda for the NETCONF WG Session in IETF 91
--------------------------------------------
 
IETF 91, Honolulu, November 9–14, 2014
TUESDAY, July 22, 2014
1300-1500 HAST - Tuesday Afternoon Session I
Room: Lehua Suite
 
   WG Chairs:
   Bert Wijnen <bertietf@bwijnen.net>
   Mehmet Ersue <mehmet.ersue@nsn.com>
 
   Scribes (IF no_volunteers THEN wait_forever)=
   Agenda bashing (2 minutes)
   WG status review (5 minutes) <= /div>
 
   Chartered items:
 
      1. NETCONF Call Home - K. = Watsen (20 min.)
 
      2. RFC5539bis issue discus= sion - All (15 min.)
 
      3. NETCONF Server Configur= ation Model - K. Watsen (10 min.)
 
      4. RESTCONF Protocol - A. = Bierman (20 min.)
 
      5. YANG Patch Media Type -= A. Bierman (10 min.)
 
      6. Zero Touch Provisioning= for NETCONF Call Home (ZeroTouch) - K. Watsen (20 min.)
 
   Non-Chartered items:
 
      1. NETCONF and persistent = responses - M. Jethanandani (10min.)
 
      2. A NETCONF Extension for= Data Fragmentation - G. Zheng (10 min.)
 
 
   Open mike:
 
   AOB
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F819537729DEMUMBX005nsnin_-- From nobody Fri Oct 31 14:42: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 B4CDD1A6F05 for ; Fri, 31 Oct 2014 14:42:46 -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 PadK8fWS-HDp for ; Fri, 31 Oct 2014 14:42:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::742]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB931A6F04 for ; Fri, 31 Oct 2014 14:42:44 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.6.9; Fri, 31 Oct 2014 21:42:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.172]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.172]) with mapi id 15.01.0006.000; Fri, 31 Oct 2014 21:42:21 +0000 From: Kent Watsen To: Alan Luchuk , netconf Thread-Topic: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication Thread-Index: AQHP9RWsg/t9lw3qYUakrH+lFZuVkpxKed4A Date: Fri, 31 Oct 2014 21:42:20 +0000 Message-ID: References: <201410311419.s9VEJQWY009047@mainfs.snmp.com> In-Reply-To: <201410311419.s9VEJQWY009047@mainfs.snmp.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.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 03818C953D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(189002)(199003)(164054003)(51444003)(76176999)(31966008)(101416001)(40100003)(64706001)(66066001)(20776003)(92566001)(92726001)(50986999)(86362001)(62966003)(106116001)(105586002)(106356001)(4396001)(122556002)(99396003)(120916001)(99286002)(95666004)(107886001)(107046002)(97736003)(54356999)(87936001)(21056001)(83506001)(77156002)(46102003)(77096003)(36756003)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; 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: <10AF6DB77124D24790798BFE9418EEFE@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/kKNm-3Zl4TAMBwUfPt1wVwOnM24 Subject: Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication 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, 31 Oct 2014 21:42:46 -0000 >>I think that limiting this I-D to mutual X.509 authentication resolves >>the issues that have been raised. > >+1 I also +1 to limiting 5539bis to just mutual X.509 auth. That said, I thought that this was already the case, or at least the intent, with all the references to RFCs 5280 and 6125 and what not. >Also, included below is the following new proposed text for Section 2.4.1, >and a new section 2.4.2. The new section 2.4.2 would displace the >existing=20 >section 2.4.2 to have 2.4.3, and so on. Thoughts on this? I'm not sure if adding more sections or more words is needed - maybe this is a case where less is more? Maybe we *only* need to 1) state that server authentication MUST be via PKIX as defined in RFCs 5280 and 6125 and 2) state anything not already covered by RFCs 5280 and 6125. Also, I noticed that you didn't touch the original section 2.4.2. (Client Identity). This is the section that is currently missing a statements along the lines of: - the client MUST present a X.509 certificate - the client MAY also present a chain of intermediate certs to a trust anchor the server is expected to trust - the server MUST authenticate the client's certificate - the server MAY authenticate the client's certificate using PKIX to a configured trust anchor - the server MAY authenticate the client's certificate if it's an exact match to a previously trusted client certificate. Also, I think the last two paragraphs in 2.4.2 should be moved to 2.4.3 (group everything about usernames to one section) and the add a statement to 2.4.3 like: - the server MUST have a configurable mapping from the presented client certificate to the NETCONF username, such as the cert-to-name algorithm defined in section 4.1 of draft-ietf-netmod-snmp-cfg-08 Thanks, Kent From nobody Fri Oct 31 21:32: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 6F7411A87D7 for ; Fri, 31 Oct 2014 21:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.91 X-Spam-Level: X-Spam-Status: No, score=-100.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 VvxlqsTrMVpa for ; Fri, 31 Oct 2014 21:32:25 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D888A1A87D5 for ; Fri, 31 Oct 2014 21:32:24 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id E475F193D3B3 for ; Sat, 1 Nov 2014 12:32:10 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id D7DBA7007B0; Sat, 1 Nov 2014 12:32:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id sA14WC5M038200; Sat, 1 Nov 2014 12:32:13 +0800 (GMT-8) (envelope-from dai.xianxian@zte.com.cn) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com MIME-Version: 1.0 X-KeepSent: 1096F232:B8124830-48257D83:0017788E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: dai.xianxian@zte.com.cn Date: Sat, 1 Nov 2014 12:32:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-11-01 12:32:08, Serialize complete at 2014-11-01 12:32:08 Content-Type: multipart/alternative; boundary="=_alternative 0018E98D48257D83_=" X-MAIL: mse01.zte.com.cn sA14WC5M038200 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/kTYnK1iDFungJy6VcNoC84xRNrY Cc: "netconf@ietf.org" , dai_sissi@126.com Subject: [Netconf] some issues ,like subtree filtering(RFC5277 & RFC6241 ) 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, 01 Nov 2014 04:32:30 -0000 This is a multipart message in MIME format. --=_alternative 0018E98D48257D83_= Content-Type: text/plain; charset="US-ASCII" RFC5277 editors: On RFC5277, The fifth section does not provide definition, just provides some simple examples to illustrate the various methods of filtering content on an event notification subscription. I want to know, about subtree filtering whether there is a correlation between RFC6241 (Chapter 6)and RFC5277 (Chapter 5). In my opinion, the two are in conflict.And I am confused. Here are some specific questions. 1.RFC5277,Chapter 5 notification example defines like this: event container |-----eventClass leaf enum |-----reportingEntity anyxml |-----choice |-------severity leaf enum |-------operState leaf enum/boolean The filtering criteria evaluation is as follows:( state | config | ( fault & ( card=Ethernet0))) subscription like this: state config fault Ethernet0 If some service-reported notifications like these: 2007-07-08T00:10:00Z state Ethernet1 major 2007-07-08T00:10:00Z fault Ethernet0 major In accordance with RFC6241 rules, the second notification "major" should be skipped. 2007-07-08T00:10:00Z state Ethernet1 major 2007-07-08T00:10:00Z fault Ethernet0 As previous implementations, "filter" statement is only used as judgment to meet the requirements of the rules,it does not act on output. 2.subscription like this: In accordance with RFC6241 rules, the expected output like this: 2007-07-08T00:10:00Z fault Is it reasonable? -------------------------------------------------------- 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. --=_alternative 0018E98D48257D83_= Content-Type: text/html; charset="US-ASCII"  
RFC5277 editors:


On RFC5277, The fifth section does not provide definition, just provides some simple examples to illustrate the various
   methods of filtering content on an event notification subscription.
   
I want to know, about subtree filtering whether there is a correlation between RFC6241 (Chapter 6)and RFC5277 (Chapter 5).
In my opinion, the two are in conflict.And I am confused.

Here are some specific questions.
1.RFC5277,Chapter 5
notification example defines like this:
event container
  |-----eventClass         leaf enum
  |-----reportingEntity    anyxml
  |-----choice
           |-------severity  leaf enum
           |-------operState leaf enum/boolean
                   
The filtering criteria evaluation is as follows:( state | config | ( fault & ( card=Ethernet0)))                  
subscription like this:
<netconf:rpc netconf:message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<filter netconf:type="subtree">
   <event xmlns="http://example.com/event/1.0">
      <eventClass>state</eventClass>
   </event>
   <event xmlns="http://example.com/event/1.0">
      <eventClass>config</eventClass>
   </event>
   <event xmlns="http://example.com/event/1.0">
      <eventClass>fault</eventClass>
      <reportingEntity>
         <card>Ethernet0</card>
      </reportingEntity>
    </event>
</filter>
</create-subscription>
</netconf:rpc>

If some service-reported notifications like these:
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2007-07-08T00:10:00Z</eventTime>
   <event xmlns="http://example.com/event/1.0">
      <eventClass>state</eventClass>
      <reportingEntity>
         <card>Ethernet1</card>
      </reportingEntity>
      <severity>major</severity>
</event>
</notification>

<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2007-07-08T00:10:00Z</eventTime>
   <event xmlns="http://example.com/event/1.0">
      <eventClass>fault</eventClass>
      <reportingEntity>
         <card>Ethernet0</card>
      </reportingEntity>
      <severity>major</severity>
</event>
</notification>

In accordance with RFC6241 rules, the second notification "<severity>major</severity>" should be skipped.
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2007-07-08T00:10:00Z</eventTime>
   <event xmlns="http://example.com/event/1.0">
      <eventClass>state</eventClass>
      <reportingEntity>
         <card>Ethernet1</card>
      </reportingEntity>
      <severity>major</severity>
</event>
</notification>

<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2007-07-08T00:10:00Z</eventTime>
   <event xmlns="http://example.com/event/1.0">
      <eventClass>fault</eventClass>
      <reportingEntity>
         <card>Ethernet0</card>
      </reportingEntity>
</event>
</notification>

As previous implementations, "filter" statement is only used as judgment to meet the requirements of the rules,it does not act on output.


2.subscription like this:
<netconf:rpc netconf:message-id="101"
xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
<create-subscription
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<filter netconf:type="subtree">
   <event xmlns="http://example.com/event/1.0">
      <eventClass/>
   </event>
</filter>
</create-subscription>
</netconf:rpc>

In accordance with RFC6241 rules, the expected output like this:
<notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
   <eventTime>2007-07-08T00:10:00Z</eventTime>
   <event xmlns="http://example.com/event/1.0">
      <eventClass>fault</eventClass>
</event>
</notification>

Is it reasonable? 











--------------------------------------------------------
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.

--=_alternative 0018E98D48257D83_=--