From nobody Sun Mar 1 09:10:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642861A1A3E for ; Sun, 1 Mar 2015 09:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 fhamSBb4tU2d for ; Sun, 1 Mar 2015 09:10:04 -0800 (PST) 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 317F21A000F for ; Sun, 1 Mar 2015 09:10:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D15728FB for ; Sun, 1 Mar 2015 18:10:02 +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 X-_x-5_3mZ5F for ; Sun, 1 Mar 2015 18:09:22 +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 for ; Sun, 1 Mar 2015 18:10:01 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 766F020036 for ; Sun, 1 Mar 2015 18:10:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pJ00UjwD-utP; Sun, 1 Mar 2015 18:09:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1C1E20031; Sun, 1 Mar 2015 18:09:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C90C03248A50; Sun, 1 Mar 2015 18:09:56 +0100 (CET) Date: Sun, 1 Mar 2015 18:09:56 +0100 From: Juergen Schoenwaelder To: "netconf@ietf.org" Message-ID: <20150301170956.GA38279@elstar.local> Mail-Followup-To: "netconf@ietf.org" References: <20150226140426.GA31778@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150226140426.GA31778@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 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, 01 Mar 2015 17:10:07 -0000 On Thu, Feb 26, 2015 at 03:04:26PM +0100, Juergen Schoenwaelder wrote: > On Thu, Feb 05, 2015 at 01:22:43PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear NETCONF WG, > > we hereby issue a WG Last Call for 3 weeks for the drafts below: > > > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 > > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 > > > > Please review and send your comments to the NETCONF WG mailing list by February 26, 2015 EOB PT. > > Hi, > > Here is my review of draft-ietf-netconf-restconf-04. Comments come > roughly in the order of the document. I am running out of time to get > a review done of draft-ietf-netconf-yang-patch-03 by today's deadline. > I may get to it by Monday (but no hard promise). > And here is my review of draft-ietf-netconf-yang-patch-03... - I wonder whether the title can be improved; this document does not only define a media type, it actually defines a complete datastore patch method. Perhaps a more descriptive title can be found? - The introduction is kind of mis-leading since NETCONF has a method to patch a datastore (edit-config). This document is primarily written to support RESTCONF I assume. And then the first paragraph says "simpler edit request format" - simpler compared to what? - What is the reason for not defining a NETCONF RPC operation? - Should it no be 'datastore resource' instead 'datasource resource' in 1.1.4? - Change "1.1.5. Terms" to "1.1.5. YANG Patch"? The whole section 1.1 is about terminology. - I did not know how to understand this sentence in section 2 until looking up the YANG module: The specific fields are defined with the 'application/yang.patch' extension definition in the YANG module Section 3. Perhaps less is more: The specific fields are defined in the YANG module in Section 3. - Again, I find it somewhat strange that the document says how one has to define the NETCONF RPC operation (e.g., section 2.1) - why not simply define this instead of leaving this out? - In section 2.3, I again stumbled across " syntax specification is defined by the 'application/yang.patch-status' extension statement". The statement defining application/yang.patch-status is rc:restconf-media-type but the text makes it sound as if application/yang.patch-status would be a statement. - Perhaps some text can be added to 2.2 and 2.3 to briefly outline what the various objects do. Some like: A YANG patch is optionally identified by a unique patch-id and it may have an optional comment. A patch is an ordered collection of edits. Each edit is identified by an edit-id and it has an edit operation (create, delete, insert, merge, move, replace, remove) that is applied to ... I think that in particular target, point, and where may need some explanation for a first time reader. - Why is it useful to have absolute and relative target paths? Would it not be simpler if target path would always be absolute that the root would always be a datastore? Perhaps it makes sense to have both but it is not clear why. - Should the edit operations not be described using YANG terminology? This is supposed to be YANG patch and not RESTCONF patch. - Why is there an automatic commit to startup? Would this not be somewhat surprising from a NETCONF point of view? Can I use YANG patch to modify some other datastore, e.g., candidate with NETCONF? If so, why would this lead to a copy of running to startup? Perhaps this is not the intention but the text is not clear. I am also not clear why the text says "after the edits have been attempted" - why does the text not require that all edits have been successful? - If there would be an RPC binding for NETCONF, would I also be able to invoke this RPC via RESTCONF if the corresponding module is announce? I would assume so - perhaps this does not need clarification (just checking). - Why do we use RESTCONF specific types in the YANG module? Why not be protocol agnostic by using instance-identifier instead of target-resource-offset? I also do not know where "Data Resource Identifier" is defined and as such target-resource-offset is under specified (and "offset" may be misleading people, no?). - What about the TBDs in sections 4.2 and 4.3? - How can the error objects use RESTCONF specific definitions if we claim that this would also work with NETCONF? - The description of yang-patch says on error the datastore MUST NOT be changed while previously the text said "SHOULD be returned to its original state". - I do not understand this: A patch MUST be validated by the server to be a well-formed message before any of the patch edits are validated or attempted. Where is it detailed how an implementation has to validate a patch edit? While applying a sequence of edits, things may temporarily not validate. Does this matter? Why not simply require that the datastore must be valid if the complete patch succeeds and if validation fails after all edits have been applied, then this is reported? That is, validate the result obtained after applying all all edits but not all intermediate steps. - Why is the comment restricted to 1024 characters? Seems like an arbitrary restriction. - The description of the operation enumeration is less RESTCONF specific but it still talks about data resources, which I think it should not. Same for target and other leafs. - It is not entirely clear whether say a move moves the data node identified by point + where to the target or whether it moves the target to point + where. - The usage of anyxml seems under-specified. It is non-interoperable using the JSON encoding document (which is not even referenced from this document - even though we have several examples with JSON encoding - but for this anyxml usage, we need some normative text that clearly says how anyxml is encoded). This actually seems to be a usage of anydata. - What about putting the ok leaf into an explicit case? Might be easier to read. - Why is edit-id numeric in some of JSON examples? The YANG model says it is a string. Lada would throw an error on this... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Mar 1 10:40:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC291A1B29 for ; Sun, 1 Mar 2015 10:40:28 -0800 (PST) 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 pexIdpKUkXSE for ; Sun, 1 Mar 2015 10:40:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983511A1A60 for ; Sun, 1 Mar 2015 10:40:26 -0800 (PST) Received: from BLUPR05CA0041.namprd05.prod.outlook.com (10.141.20.11) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.99.14; Sun, 1 Mar 2015 18:40:06 +0000 Received: from BN1BFFO11FD004.protection.gbl (2a01:111:f400:7c10::1:168) by BLUPR05CA0041.outlook.office365.com (2a01:111:e400:855::11) with Microsoft SMTP Server (TLS) id 15.1.99.14 via Frontend Transport; Sun, 1 Mar 2015 18:40:06 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1BFFO11FD004.mail.protection.outlook.com (10.58.144.67) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Sun, 1 Mar 2015 18:40:06 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 1 Mar 2015 10:40:04 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t21Ie3D94224; Sun, 1 Mar 2015 10:40:03 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t21Id94h023428; Sun, 1 Mar 2015 13:39:09 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201503011839.t21Id94h023428@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20150301170956.GA38279@elstar.local> Date: Sun, 1 Mar 2015 13:39:09 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(199003)(47776003)(76506005)(62966003)(110136001)(77156002)(46102003)(48376002)(86362001)(92566002)(230783001)(2950100001)(77096005)(105596002)(53416004)(106466001)(50466002)(87936001)(6806004)(54356999)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BLUPR05MB436; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB436; X-Forefront-PRVS: 0502983C0E X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2015 18:40:06.0200 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 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, 01 Mar 2015 18:40:28 -0000 Juergen Schoenwaelder writes: >- The introduction is kind of mis-leading since NETCONF has a method > to patch a datastore (edit-config). This document is primarily > written to support RESTCONF I assume. And then the first paragraph > says "simpler edit request format" - simpler compared to what? This is my big issue with yang-patch: Why can't this be done using edit-config? What does yang-patch add that can't be performed with edit-config? Does restconf not expose an edit-config operation? What's the value of inventing a second way of doing config edits? How does a second way help us in advancing standardized network management operations? Are there sufficient benefits with yang-patch to justify the expense, churn, duplication, and confusion it will bring? Thanks, Phil From nobody Mon Mar 2 06:38:26 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9DC1A879C for ; Mon, 2 Mar 2015 06:38:22 -0800 (PST) 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 mc7b0T4WDtbq for ; Mon, 2 Mar 2015 06:38:20 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08731A8789 for ; Mon, 2 Mar 2015 06:38:19 -0800 (PST) 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.1.99.14; Mon, 2 Mar 2015 14:38:17 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) with mapi id 15.01.0099.004; Mon, 2 Mar 2015 14:38:17 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] zerotouch issues and fixes Thread-Index: AQHQVPaFjCwJhqkRAkKZiaLOBLskpA== Date: Mon, 2 Mar 2015 14:38:17 +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-originating-ip: [66.129.239.11] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0503FF9A3E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(51704005)(479174004)(24454002)(76104003)(2351001)(107886001)(110136001)(19580395003)(450100001)(2656002)(87936001)(106116001)(77156002)(50986999)(54356999)(62966003)(19580405001)(99286002)(83506001)(86362001)(40100003)(92566002)(122556002)(2501003)(66066001)(15975445007)(102836002)(46102003)(36756003)(2900100001)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: <5E9B134A26E5814893BCD48A994982E8@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2015 14:38:17.0585 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] zerotouch issues and fixes 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, 02 Mar 2015 14:38:22 -0000 DQpUaGUgY3V0LW9mZiBkYXRlIGZvciBkcmFmdC1zdWJtaXNzaW9ucyBpcyBpbiA3IGRheXMuICBJ IHdhcyBob3BpbmcgdG8gZ2V0DQpzb21lIGZlZWRiYWNrIGJlZm9yZSBlZGl0aW5nIHRoaXMgZHJh ZnQuICBEb2VzIGFueW9uZSBsaWtlIHRoZSBmaXhlcw0KZGlzY3Vzc2VkIGJlbG93Pw0KDQpUaGFu a3MsDQpLZW50DQoNCg0KDQpPbiAyLzIzLzE1LCA1OjMyIFBNLCAiS2VudCBXYXRzZW4iIDxrd2F0 c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPg0KPk5vdyB0aGF0IHRoZSBjYWxsLWhvbWUgYW5k IHNlcnZlci1tb2RlbCBkcmFmdHMgaGF2ZSBubyBtb3JlIHBsYW5uZWQNCj51cGRhdGVzIGJlZm9y ZSBlbnRlcmluZyBMYXN0IENhbGwsIEknbSByZWFkeSB0byBmb2N1cyBvbiB0aGUgemVyb3RvdWNo DQo+ZHJhZnQgYWdhaW4uICBUaGUgZ29vZCBuZXdzIGlzIHRoYXQgSSd2ZSBiZWVuIHRoaW5raW5n IGFib3V0IHNvbWUgaXNzdWVzDQo+d2l0aCB0aGUgY3VycmVudCBkcmFmdCBhbmQgYWxyZWFkeSBo YXZlIGEgcHJvcG9zYWwgZm9yIGhvdyB0byBmaXggdGhlbS4NCj5UaGUgaXNzdWVzIEknbSB0aGlu a2luZyBhYm91dCBhcmU6DQo+DQo+MSkgTG9zcyBvZiBwcml2YWN5IGFzIE5NUyBhZG1pbnMgbmVl ZCB0byBpbnRlcmFjdCB3aXRoIDNyZC1wYXJ0eSBzaWduaW5nDQo+c2VydmVycyBpbiBvcmRlciB0 byBnZXQgdGhlaXIgQ29uZmlnbGV0cyBzaWduZWQuDQo+DQo+MikgQ29tcGxleGl0eSBpbiBob3cg M3JkLXBhcnR5IHNpZ25pbmcgc2VydmVyIHdvdWxkIGJlIGFibGUgdG8ga25vdyB3aG8NCj5vd25z IHdoaWNoIGRldmljZXMsIHRoZSBidXJkZW4gb2YgaXRzIHJvbGUuDQo+DQo+MykgTG9zcyBvZiBm bGV4aWJpbGl0eSBhcyBhIENvbmZpZ2xldCBoYXMgdG8gZW5jb2RlIHRoZSBkZXZpY2UgaWRlbnRp ZmllcnMNCj5mb3IgdGhlIGRldmljZXMgYWxsb3dlZCB0byBsb2FkIGl0Lg0KPg0KPg0KPlRoZSBw cm9wb3NhbCB0byBmaXggdGhlIGFib3ZlIGlzc3VlcyBpcyB0byByZXBsYWNlIHRoZSBjb25jZXB0 IG9mIGENCj4zcmQtcGFydHkgU2lnbmluZyBBdXRob3JpdHkgd2l0aCAxKSBOTVNzIGNhbiBzaWdu IHRoZWlyIG93biBjb25maWd1cmF0aW9ucw0KPndpdGggYSBWZW5kb3ItY2VydGlmaWVkIGtleSBh bmQgMikgRGV2aWNlcyB1c2UgYSBWZW5kb3ItcHJvdmlkZWQgqfh2b3VjaGVyqfcNCj50byBhdXRo ZW50aWNhdGUgTk1Tcy4gIFN0ZXBwaW5nIHRocm91Z2ggdGhpcyBpbiBkZXRhaWwsIHdlIGhhdmUg dGhlDQo+Zm9sbG93aW5nIGFydGlmYWN0czoNCj4NCj5OTVMgQ2VydGlmaWNhdGU6DQo+ICAqIHRo ZSBmaXJzdCB0aW1lIE5NUyB3YW50cyB0byBlbnJvbGwgaW4gVmVuZG9yJ3MgWmVyb1RvdWNoIHBy b2dyYW06DQo+ICAgICogTk1TIGdlbmVyYXRlcyBhIHByaXZhdGUga2V5DQo+ICAgICogTk1TIGdl bmVyYXRlcyBhIGNlcnRpZmljYXRlIHNpZ25pbmcgcmVxdWVzdCAoQ1NSKQ0KPiAgICAqIE5NUyBz ZW5kcyB0byBWZW5kb3IgaXRzIENTUg0KPiAgICAqIFZlbmRvciBzaWducyB0aGUgQ1NSLCBmaWxs aW5nIGluIGFuICJPd25lciBJRCIgdmFsdWUNCj4gICAgKiBWZW5kb3Igc2lnbnMgdGhlIENTUiB3 aXRoIFZlbmRvciBwcml2YXRlIGtleQ0KPiAgICAqIFZlbmRvciBzZW5kcyB0byBOTVMgdGhlIHJl c3VsdGluZyBOTVMgQ2VydGlmaWNhdGUNCj4NCj5EZXZpY2UtT3duZXIgVm91Y2hlcjoNCj4gICog YXQgYW55IHRpbWUsIFZlbmRvciBjYW4gZ2VuZXJhdGUgYSBWb3VjaGVyIHRoYXQ6DQo+ICAgICAq IGVuY29kZXMgYW4gIk93bmVyIElEIiAoc2VlIE5NUyBDZXJ0aWZpY2F0ZSBhYm92ZSkNCj4gICAg ICogZW5jb2RlcyBvbmUgb3IgbW9yZSBkZXZpY2UgaWRlbnRpZmllcnMgKGUuZy4sIHNlcmlhbC1u dW1iZXIpDQo+ICAgICAqIGVuY29kZXMgYW4gZXhwaXJhdGlvbiB0aW1lIChlLmcuIG1vbnRocywg eWVhcnMsIGZvcmV2ZXIpDQo+ICAgICAqIHNpZ25lZCBieSBWZW5kb3IgcHJpdmF0ZSBrZXkNCj4N Cj5Db25maWd1cmF0aW9uOg0KPiAgKiB3aGVuIE5NUyByZWFkeSB0byBzdGFnZSBaZXJvVG91Y2gg Y29uZmlndXJhdGlvbjoNCj4gICAgICogTk1TIGdlbmVyYXRlcyBjb25maWd1cmF0aW9uDQo+ICAg ICAqIE5NUyBzaWducyBjb25maWd1cmF0aW9uIHdpdGggcHJpdmF0ZSBrZXkNCj4gICAgICogTk1T IHBsYWNlcyBvbnRvIENvbmZpZ3VyYXRpb24gU2VydmVyIGFsbCBvZiB0aGUgZm9sbG93aW5nOg0K PiAgICAgICAgMSkgc2lnbmVkIENvbmZpZ3VyYXRpb24NCj4gICAgICAgIDIpIERldmljZS1Pd25l ciBWb3VjaGVyDQo+ICAgICAgICAzKSBOTVMgQ2VydGlmaWNhdGUNCj4NCj5XaXRoIHRoaXMgc2V0 dXAsIHRoZSBkZXZpY2UncyBib290IHVwIHByb2NlZHVyZSBpcyByb3VnaGx5Og0KPiAgKiBkb3du bG9hZCB0aGUgMyBhcnRpZmFjdHMgZnJvbSBDb25maWd1cmF0aW9uIFNlcnZlcg0KPiAgKiBwcm9j ZXNzIHRoZSBEZXZpY2UtT3duZXIgVm91Y2hlcjoNCj4gICAgICogdmVyaWZ5IHRoYXQgaXQgd2Fz IHNpZ25lZCBieSBWZW5kb3IgcHJpdmF0ZSBrZXkNCj4gICAgICogdmVyaWZ5IHRoYXQgaXRzIGRl dmljZS1pZGVudGlmaWVyIGlzIGxpc3RlZA0KPiAgICAgKiBleHRyYWN0IHRoZSBlbmNvZGVkIE93 bmVyIElEDQo+ICAqIHByb2Nlc3MgdGhlIE5NUyBDZXJ0aWZpY2F0ZToNCj4gICAgICogdmVyaWZ5 IHRoYXQgaXQgd2FzIHNpZ25lZCBieSBWZW5kb3IgcHJpdmF0ZSBrZXkNCj4gICAgICogdmVyaWZ5 IHRoYXQgdGhlIE93bmVyIElEIGlzIHNhbWUgYXMgZXh0cmFjdGVkIGZyb20gVm91Y2hlcg0KPiAg ICAgKiBleHRyYWN0IE5NUyBwdWJsaWMga2V5DQo+ICAqIHByb2Nlc3MgdGhlIHNpZ25lZCBDb25m aWd1cmF0aW9uDQo+ICAgICAqIHZlcmlmeSB0aGF0IGl0IHdhcyBzaWduZWQgYnkgdGhlIE5NUyBw cml2YXRlIGtleQ0KPiAgICAgKiBjb21taXQgY29uZmlndXJhdGlvbiBpbnRvIHJ1bm5pbmcgZGF0 YXN0b3JlDQo+DQo+UGxlYXNlIGFzc3VtZSBldmVyeXRoaW5nIGVsc2UgaW4gemVyb3RvdWNoLTAx IGRyYWZ0IHdvdWxkIHJlbWFpbiB0aGUgc2FtZS4NCj4gTm90ZSBob3cgdGhpcyBzb2x1dGlvbiBm aXhlcyBhbGwgdGhlIGFib3ZlIGxpc3RlZCBpc3N1ZXM6IDEpIE5NUyBhZG1pbnMNCj5ub3cgc2ln bmVkIHRoZWlyIG93biBjb25maWd1cmF0aW9ucywgMikgVmVuZG9ycyBub3cgb25seSBuZWVkIHRv IHByb3ZpZGUgYQ0KPlZvdWNoZXIsIDMpIENvbmZpZ3VyYXRpb25zIG5vIGxvbmdlciBoYXMgdG8g ZW5jb2RlIHdoaWNoIGRldmljZXMgdGhlaXINCj5mb3IuDQo+DQo+DQo+QXMgYSBkZXNpZ24gY29u c2lkZXJhdGlvbiwgbm90ZSB0aGF0IGFsbCB0aGUgemVyb3RvdWNoIHByb3Bvc2FscyBlbXBoYXNp emUNCj50aGUgdXNlIG9mIHN0YXRpYyBhcnRpZmFjdHMgb3ZlciBwcm90b2NvbC4gIFRoaXMgaXMg c28gdGhlIGFydGlmYWN0cyBjYW4NCj5vcHRpb25hbGx5IGJlIGxvYWRlZCBmcm9tIGFsdGVybmF0 ZSBzb3VyY2VzIChpLmUuIFVTQiBkcml2ZSwgb3ZlciBhbiBMMg0KPnByb3RvY29sLCBvdmVyIGEg bm9uLUlQIHByb3RvY29sLCBldGMuKS4NCj4NCj5Tbywgd2hhdCBkbyB5b3UgdGhpbms/ICAtIEkn ZCBsaWtlIHRvIGdldCBzb21lIGZlZWRiYWNrIGJlZm9yZSBwb3N0aW5nIGENCj4tMDIgZHJhZnQh DQo+DQo+DQo+VGhhbmtzLA0KPktlbnQNCj4NCj4NCj4NCj4NCj4NCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk5ldGNvbmYgbWFpbGluZyBsaXN0 DQo+TmV0Y29uZkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZg0KDQo= From nobody Mon Mar 2 07:15:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02F91A88FC for ; Mon, 2 Mar 2015 07:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 8FEHsSmLejKO for ; Mon, 2 Mar 2015 07:14:58 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23271A8839 for ; Mon, 2 Mar 2015 07:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4230; q=dns/txt; s=iport; t=1425308893; x=1426518493; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=jvrqOjao3gzlRcr/1aDnrb8hVrjpfGPq7xouQCPjw28=; b=Jq4KxCZHfiDdR0UbPC0C644kH41lsIG7nZGFSV6cq9yGG8xrqoQXgGsG cKrPnRzrnfvYJilWK6Uicejj3nwx82/lBjmXA5FN0xSBxQwy4FFVveVq/ l9rWu48Oc4IeG/2l7YjjAm4SuV3zESQEspw69ErZH3fGN0V5mWodafVat I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AJBQCqaeJU/40NJK1bgwbJXQKBGEMBAQEBAQF8hA0BAQQyAQU8BBELDgoJFg8JAwIBAgFFBgEMCAEBFgGIEs41AQEBAQEBAQECAQEBAQEBARuLDIR0hCoBBIo6imiDTYEYgw2CKow+IoQMIIJ0AQEB X-IronPort-AV: E=Sophos;i="5.09,675,1418083200"; d="scan'208";a="400032864" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 02 Mar 2015 15:08:12 +0000 Received: from [10.150.55.87] (dhcp-10-150-55-87.cisco.com [10.150.55.87]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t22F8COd024149; Mon, 2 Mar 2015 15:08:12 GMT Message-ID: <54F47CDA.9080908@cisco.com> Date: Mon, 02 Mar 2015 10:08:10 -0500 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Netconf] zerotouch issues and fixes 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, 02 Mar 2015 15:14:59 -0000 On 2/23/15 5:32 PM, Kent Watsen wrote: > > Now that the call-home and server-model drafts have no more planned > updates before entering Last Call, I'm ready to focus on the zerotouch > draft again. The good news is that I've been thinking about some issues > with the current draft and already have a proposal for how to fix them. > The issues I'm thinking about are: > > 1) Loss of privacy as NMS admins need to interact with 3rd-party signing > servers in order to get their Configlets signed. > > 2) Complexity in how 3rd-party signing server would be able to know who > owns which devices, the burden of its role. > > 3) Loss of flexibility as a Configlet has to encode the device identifiers > for the devices allowed to load it. > > > The proposal to fix the above issues is to replace the concept of a > 3rd-party Signing Authority with 1) NMSs can sign their own configurations > with a Vendor-certified key and 2) Devices use a Vendor-provided voucher > to authenticate NMSs. Stepping through this in detail, we have the > following artifacts: > > NMS Certificate: > * the first time NMS wants to enroll in Vendor's ZeroTouch program: > * NMS generates a private key > * NMS generates a certificate signing request (CSR) > * NMS sends to Vendor its CSR > * Vendor signs the CSR, filling in an "Owner ID" value > * Vendor signs the CSR with Vendor private key > * Vendor sends to NMS the resulting NMS Certificate > > Device-Owner Voucher: > * at any time, Vendor can generate a Voucher that: > * encodes an "Owner ID" (see NMS Certificate above) > * encodes one or more device identifiers (e.g., serial-number) > * encodes an expiration time (e.g. months, years, forever) > * signed by Vendor private key > > Configuration: > * when NMS ready to stage ZeroTouch configuration: > * NMS generates configuration > * NMS signs configuration with private key > * NMS places onto Configuration Server all of the following: > 1) signed Configuration > 2) Device-Owner Voucher > 3) NMS Certificate > > With this setup, the device's boot up procedure is roughly: > * download the 3 artifacts from Configuration Server > * process the Device-Owner Voucher: > * verify that it was signed by Vendor private key > * verify that its device-identifier is listed > * extract the encoded Owner ID > * process the NMS Certificate: > * verify that it was signed by Vendor private key > * verify that the Owner ID is same as extracted from Voucher > * extract NMS public key > * process the signed Configuration > * verify that it was signed by the NMS private key > * commit configuration into running datastore > > Please assume everything else in zerotouch-01 draft would remain the same. > Note how this solution fixes all the above listed issues: 1) NMS admins > now signed their own configurations, 2) Vendors now only need to provide a > Voucher, 3) Configurations no longer has to encode which devices their for. > > > As a design consideration, note that all the zerotouch proposals emphasize > the use of static artifacts over protocol. This is so the artifacts can > optionally be loaded from alternate sources (i.e. USB drive, over an L2 > protocol, over a non-IP protocol, etc.). > > So, what do you think? - I'd like to get some feedback before posting a > -02 draft! I think this approach is reasonable. The interaction with the vendor is minimal (only to claim the device-IDs and get the voucher). Though, the time-to-live of the voucher needs to be accounted for by the device. It needs to confirm the voucher is still "alive." Would it make sense to have a per-device TTL in the voucher? I also think there needs to be a way for the NMS to request an owner ID. The reason for this is what happens if I have to replace the NMS. I would need a new private key and a new CSR. While I could get a new voucher with the new owner ID, this would likely be more of a hassle as the vendor will likely associate the devices with one owner ID. Joe From nobody Mon Mar 2 07:43:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944F61A0023 for ; Mon, 2 Mar 2015 07:43:27 -0800 (PST) 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 Weuy2MSzdEz8 for ; Mon, 2 Mar 2015 07:43:21 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9151A0115 for ; Mon, 2 Mar 2015 07:43:14 -0800 (PST) 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.99.14; Mon, 2 Mar 2015 15:43:11 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) with mapi id 15.01.0099.004; Mon, 2 Mar 2015 15:43:11 +0000 From: Kent Watsen To: Joe Clarke , "netconf@ietf.org" Thread-Topic: [Netconf] zerotouch issues and fixes Thread-Index: AQHQT7iOdPe2gMCB50i3hPM2i00zr50JVfMA//+19IA= Date: Mon, 2 Mar 2015 15:43:10 +0000 Message-ID: References: <54F47CDA.9080908@cisco.com> In-Reply-To: <54F47CDA.9080908@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-originating-ip: [66.129.239.11] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0503FF9A3E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(164054003)(87936001)(86362001)(106116001)(66066001)(2656002)(2950100001)(46102003)(92566002)(2900100001)(122556002)(36756003)(40100003)(62966003)(77156002)(2501003)(83506001)(107886001)(50986999)(76176999)(102836002)(99286002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <7A2331CD82A8D14492B3D30030DAB8D2@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2015 15:43:10.8477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] zerotouch issues and fixes 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, 02 Mar 2015 15:43:27 -0000 >I think this approach is reasonable. The interaction with the vendor is >minimal (only to claim the device-IDs and get the voucher). Exactly, this solution optimizes for the vendor - it's very low-touch and doesn't rely on a realtime lookup service. But "reasonable" sounds uncommitted - what we need to know is it's better - what do you think? >Though, the=20 >time-to-live of the voucher needs to be accounted for by the device. It >needs to confirm the voucher is still "alive." Yes, there is a presumption that the device has an accurate clock. Such it is with PKI in general. For instance, CRLs are only useful if they're relatively fresh (a year-old CRL is not very useful). >Would it make sense to >have a per-device TTL in the voucher? This would be doable. As a voucher is a data file (not a X.509 certificate), for which we could define schema for, and thus it could take any form we deem best. That said, I question if it makes sense for a vendor to issue a voucher with varying TTLs. Is the vendor suppose to know that some device's ownership is more volatile than others? - or do you see this as user-input? >I also think there needs to be a way for the NMS to request an owner ID. > The reason for this is what happens if I have to replace the NMS. I >would need a new private key and a new CSR. While I could get a new >voucher with the new owner ID, this would likely be more of a hassle as >the vendor will likely associate the devices with one owner ID. Yes, vendors would have to be able to reissue the NMS certificates. Vendors could re-assign the same Owner ID the NMS had before or generate a new one. If a new Owner ID is generated, then the vendor would also need to reissue Vouchers for devices that have not yet been claimed (e.g., gone through the zerotouch process). Thanks, Kent From nobody Mon Mar 2 18:31:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2241A90B9 for ; Mon, 2 Mar 2015 18:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 FQIpWw5o0DOg for ; Mon, 2 Mar 2015 18:31:39 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A211A90B4 for ; Mon, 2 Mar 2015 18:31:39 -0800 (PST) Received: by lbiz12 with SMTP id z12so11327972lbi.5 for ; Mon, 02 Mar 2015 18:31:38 -0800 (PST) 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=PRkqrjC+bAvU+RKClpVzB3p5b6i4TeRI5RXMX5X3q8g=; b=hwxWVSI6HjnG9nmMRy9ZrFXDNPd6s5TmaHJW31PMTyxe1r7GDdImDMh50owTzdvaAk pfglGNgP/BTkJhWZi6WjmIx4ZhLfJCKSA4zoYG4bMFJUQvK+83fTM/nlqLqP872Uucbf vVAw8PcFUmTw35V1vWig+tH1Ldu0LBy7wF4jpKticF/CtGZSZf9hz9sKWlcBczW1Hj8S Wv092ZwMUhpk4o+3jDSUiWrnL7J7WI33Cx1HuIy/KaqoPvEaJQVRdbjhUN+KZ9bPiPRp W9BQuVM5797H18mrdajLAvpIeEDgaZegn0mZkOUmG7bVN1dQQNZDTxU0eSVEvS7quDvG +5yw== X-Gm-Message-State: ALoCoQkUtSqi3tIApUhJ1h11/e+q0hPmt0LD0l33xmC2k0koL8DJXAlgvO8F0IKtfUSppdVnm1dd MIME-Version: 1.0 X-Received: by 10.112.148.38 with SMTP id tp6mr26832372lbb.82.1425349897927; Mon, 02 Mar 2015 18:31:37 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 2 Mar 2015 18:31:37 -0800 (PST) In-Reply-To: <201503011839.t21Id94h023428@idle.juniper.net> References: <20150301170956.GA38279@elstar.local> <201503011839.t21Id94h023428@idle.juniper.net> Date: Mon, 2 Mar 2015 18:31:37 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 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, 03 Mar 2015 02:31:41 -0000 On Sun, Mar 1, 2015 at 10:39 AM, Phil Shafer wrote: > Juergen Schoenwaelder writes: >>- The introduction is kind of mis-leading since NETCONF has a method >> to patch a datastore (edit-config). This document is primarily >> written to support RESTCONF I assume. And then the first paragraph >> says "simpler edit request format" - simpler compared to what? > > This is my big issue with yang-patch: Why can't this be done using > edit-config? What does yang-patch add that can't be performed with > edit-config? Does restconf not expose an edit-config operation? > What's the value of inventing a second way of doing config edits? > How does a second way help us in advancing standardized network > management operations? Are there sufficient benefits with yang-patch > to justify the expense, churn, duplication, and confusion it will > bring? RESTCONF edit operations are done on data resources. NETCONF is not resource-oriented. YANG Patch edits are ordered. NETCONF order (and whether or not a real edit is invoked) is implementation-dependent. YANG Patch might allow edits to be encoded more efficiently since the config 'scaffolding' is not part of the each edit. Operations such as 'move' are explicit and more efficient to encode than YANG insert. > > Thanks, > Phil Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Mar 2 19:47:26 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9876B1A039D for ; Mon, 2 Mar 2015 19:47:24 -0800 (PST) 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 lA0-HVuGniV1 for ; Mon, 2 Mar 2015 19:47:22 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547C71A0396 for ; Mon, 2 Mar 2015 19:47:22 -0800 (PST) Received: from BL2PR05CA0042.namprd05.prod.outlook.com (10.255.226.42) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (TLS) id 15.1.99.14; Tue, 3 Mar 2015 03:47:01 +0000 Received: from BL2FFO11FD053.protection.gbl (2a01:111:f400:7c09::163) by BL2PR05CA0042.outlook.office365.com (2a01:111:e400:c04::42) with Microsoft SMTP Server (TLS) id 15.1.99.14 via Frontend Transport; Tue, 3 Mar 2015 03:47:01 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Tue, 3 Mar 2015 03:47:00 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Mar 2015 19:46:59 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t233kwD98601; Mon, 2 Mar 2015 19:46:58 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t233k2Qt036627; Mon, 2 Mar 2015 22:46:03 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201503030346.t233k2Qt036627@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Mon, 2 Mar 2015 22:46:02 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(199003)(51704005)(50986999)(47776003)(105596002)(77096005)(54356999)(86362001)(106466001)(46102003)(48376002)(92566002)(2950100001)(53416004)(87936001)(230783001)(50466002)(76506005)(110136001)(6806004)(62966003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB437; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB437; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN1PR05MB437; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB437; X-Forefront-PRVS: 0504F29D72 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2015 03:47:00.7007 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB437 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 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, 03 Mar 2015 03:47:24 -0000 Andy Bierman writes: >RESTCONF edit operations are done on data resources. >NETCONF is not resource-oriented. > >YANG Patch edits are ordered. >NETCONF order (and whether or not a real >edit is invoked) is implementation-dependent. > >YANG Patch might allow edits to be encoded more efficiently >since the config 'scaffolding' is not part of the each edit. >Operations such as 'move' are explicit and more efficient >to encode than YANG insert. That's a really short list, and it looks like the first and last are the same (since "data resource" means a path into a datastore, right?). Encoding efficiency aside, what's the big innovation in yang-patch? If it's really just putting multiple change payloads in a single request such that any of them can fail independently, aren't we better served by adding this to edit-config, perhaps as a sister attribute to "op"? Thanks, Phil P.s.: The term "urlpath" sounds odd; URLs _are_ paths, right? From nobody Mon Mar 2 23:56:44 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE3D1A1A3C for ; Mon, 2 Mar 2015 23:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 WOSfhV9uLTTV for ; Mon, 2 Mar 2015 23:56:41 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8355F1A1A33 for ; Mon, 2 Mar 2015 23:56:41 -0800 (PST) Received: by lbvn10 with SMTP id n10so35361834lbv.6 for ; Mon, 02 Mar 2015 23:56:40 -0800 (PST) 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=1drRq2R2p3BBBIa55l+MhCkw9TC5t9V8/iSSZmcxX7o=; b=KTLEwANnJ9vwBqYYGInNvttR538mekWLlo1L7orH3T6b8nKQgB4A0ZQdySBdmXANUU K5tUWJBN44D0SgUiEoIc3LvLJbINjMEDqc3iNcOSZQjPI4Y0aCiBbFHiD6x6NmDMwxIC F88jwmUc+XmAgHgJfAK7IASy+4QJYUBwsURPwk/yu/XYYkJZMjHcjq8ENG1pUtPWBh84 U1oe8yWRjLS0mdBIywetY78+tsbORYiLdhLpELoGBiS218eevgtCjrXtD1my0c3gnnvq j158usQYaS+kQt5hhXe/nDObjeEcDk37VVr+wdf/CU9ELXiT5n2mIDsxlqdvqO7vWRGG YopQ== X-Gm-Message-State: ALoCoQnhURIOADF/Owz2SSTH/N96kxYauKsXV6NScXB7vhUOLh6O43hsVDVrgd11KQniHFCC5VX8 MIME-Version: 1.0 X-Received: by 10.112.64.193 with SMTP id q1mr27977751lbs.88.1425369399877; Mon, 02 Mar 2015 23:56:39 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 2 Mar 2015 23:56:39 -0800 (PST) In-Reply-To: <201503030346.t233k2Qt036627@idle.juniper.net> References: <201503030346.t233k2Qt036627@idle.juniper.net> Date: Mon, 2 Mar 2015 23:56:39 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 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, 03 Mar 2015 07:56:43 -0000 On Mon, Mar 2, 2015 at 7:46 PM, Phil Shafer wrote: > Andy Bierman writes: >>RESTCONF edit operations are done on data resources. >>NETCONF is not resource-oriented. >> >>YANG Patch edits are ordered. >>NETCONF order (and whether or not a real >>edit is invoked) is implementation-dependent. >> >>YANG Patch might allow edits to be encoded more efficiently >>since the config 'scaffolding' is not part of the each edit. >>Operations such as 'move' are explicit and more efficient >>to encode than YANG insert. > > That's a really short list, and it looks like the first and last > are the same (since "data resource" means a path into a datastore, > right?). > > Encoding efficiency aside, what's the big innovation in yang-patch? > If it's really just putting multiple change payloads in a single > request such that any of them can fail independently, aren't we > better served by adding this to edit-config, perhaps as a sister > attribute to "op"? > What is so great about the implementation-dependent blob? Why are a set of attributes (1 in NETCONF, the rest defined in YANG) better than an edit list? I have heard some comments that the patch approach is more direct and easier for the client to convey its intent. A set of ordered edits provides more client control for setting up dependencies. IMO the NETCONF encoding of an edit is irrelevant to RESTCONF. RESTCONF does not use an element wrapper for operations either. Most (if not all) of the message encoding details are different. > Thanks, > Phil > > P.s.: The term "urlpath" sounds odd; URLs _are_ paths, right? Andy From nobody Tue Mar 3 00:12:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372EB1A1A67 for ; Tue, 3 Mar 2015 00:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pbIMoBV6F1Ph for ; Tue, 3 Mar 2015 00:12:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 66C471A1A6F for ; Tue, 3 Mar 2015 00:12:22 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 676A01280A40; Tue, 3 Mar 2015 09:12:21 +0100 (CET) Date: Tue, 03 Mar 2015 09:12:21 +0100 (CET) Message-Id: <20150303.091221.1320688875820544524.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <201503030346.t233k2Qt036627@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 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, 03 Mar 2015 08:12:36 -0000 Andy Bierman wrote: > On Mon, Mar 2, 2015 at 7:46 PM, Phil Shafer wrote: > > Andy Bierman writes: > >>RESTCONF edit operations are done on data resources. > >>NETCONF is not resource-oriented. > >> > >>YANG Patch edits are ordered. > >>NETCONF order (and whether or not a real > >>edit is invoked) is implementation-dependent. > >> > >>YANG Patch might allow edits to be encoded more efficiently > >>since the config 'scaffolding' is not part of the each edit. > >>Operations such as 'move' are explicit and more efficient > >>to encode than YANG insert. > > > > That's a really short list, and it looks like the first and last > > are the same (since "data resource" means a path into a datastore, > > right?). > > > > Encoding efficiency aside, what's the big innovation in yang-patch? > > If it's really just putting multiple change payloads in a single > > request such that any of them can fail independently, aren't we > > better served by adding this to edit-config, perhaps as a sister > > attribute to "op"? > > > > What is so great about the implementation-dependent blob? > Why are a set of attributes (1 in NETCONF, the rest defined in YANG) > better than an edit list? To be fair, I think Phil is right in that the expressiveness of both formats are equal. Which one you prefer is subjective, possibly influenced by implementation choices. The question boils down to if we think it is good to have two more or less equal ways of doing things, or if there is value in having one single mechanism. > I have heard some comments that the patch approach is more direct > and easier for the client to convey its intent. A set of ordered edits > provides more client control for setting up dependencies. Even with YANG PATCH, it is the resulting datastore that is validated, so the order of the edits doesn't matter. /martin > IMO the NETCONF encoding of an edit is irrelevant to RESTCONF. > RESTCONF does not use an element wrapper for operations > either. Most (if not all) of the message encoding details are different. > > > > Thanks, > > Phil > > > > P.s.: The term "urlpath" sounds odd; URLs _are_ paths, right? > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Mar 3 05:42:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD091A7018; Tue, 3 Mar 2015 05:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vdwrSy98lDT0; Tue, 3 Mar 2015 05:42:26 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 313521A7007; Tue, 3 Mar 2015 05:42:25 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 272BB8905B13E; Tue, 3 Mar 2015 13:42:20 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t23DgLIT015235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Mar 2015 08:42:21 -0500 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.170]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 08:42:21 -0500 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder , David Ball Thread-Topic: [Rtg-yang-coord] YANG leaf writing to running-datastore Thread-Index: AQHQVTpEq/zNRT6jCUKq/19v/CWVfp0K2boAgAAEp4D//+UsUA== Date: Tue, 3 Mar 2015 13:42:20 +0000 Message-ID: References: <54F58512.2080900@cisco.com> <20150303101209.GB62331@elstar.local> In-Reply-To: <20150303101209.GB62331@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-yang-coord@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [Rtg-yang-coord] YANG leaf writing to running-datastore 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, 03 Mar 2015 13:42:28 -0000 Adding netconf into this as we're talking about generic netconf functionali= ty here. The concept of having other (somewhat arbitrary) data stores is something t= hat may be useful for this "debug" type of configuration. It may even make= sense to have both a debug-running & a debug-startup datastore for debug (= and perhaps a debug-candidate as well). Some implementations effectively t= reat debug as a separate datastore (e.g. allow saving debug info separately= from the rest of the configuration). A similar approach may also make sense for Lawful Interception configuratio= n which is often treated separately from the rest of config. I think we'd have to extend the in some way to indicate which capab= ilities (which yang modules) apply to which datastores. Jason -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Juergen Schoenwaelder Sent: Tuesday, March 03, 2015 5:12 AM To: David Ball Cc: Mahesh Jethanandani; rtg-yang-coord@ietf.org Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore On Tue, Mar 03, 2015 at 09:55:30AM +0000, David Ball wrote: > Wouldn't that be best done with an RPC? > An ephemeral data store would provide a generic solution for this kind of p= roblem. RPCs tend to be specific (or you invent a generic RPC that actually= models an ephemeral data store). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Tue Mar 3 05:57:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B19F1A7007; Tue, 3 Mar 2015 05:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 T0qFdsyiFyab; Tue, 3 Mar 2015 05:57:18 -0800 (PST) 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 413601A7D80; Tue, 3 Mar 2015 05:57:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 079ABA45; Tue, 3 Mar 2015 14:57:14 +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 gcsup5ws0nnb; Tue, 3 Mar 2015 14:57:05 +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; Tue, 3 Mar 2015 14:57:13 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F21B2003F; Tue, 3 Mar 2015 14:57:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BLD4v3Rg6LDG; Tue, 3 Mar 2015 14:57:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A13AD2003D; Tue, 3 Mar 2015 14:57:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 158DC3259903; Tue, 3 Mar 2015 14:57:10 +0100 (CET) Date: Tue, 3 Mar 2015 14:57:10 +0100 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20150303135710.GA62789@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , David Ball , Mahesh Jethanandani , "rtg-yang-coord@ietf.org" , "netconf@ietf.org" References: <54F58512.2080900@cisco.com> <20150303101209.GB62331@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: Cc: "rtg-yang-coord@ietf.org" , David Ball , "netconf@ietf.org" Subject: Re: [Netconf] [Rtg-yang-coord] YANG leaf writing to running-datastore 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, 03 Mar 2015 13:57:20 -0000 Hi, please consult the NETMOD physical interim minutes (September 2015) and followup discussions on the I2RS list concerning ephemeral datastores. If people find some of this useful, someone needs to condense the ideas into an I-D. (Note that the motivation back then was to deal with I2RS injected ephemeral config state.) /js On Tue, Mar 03, 2015 at 01:42:20PM +0000, Sterne, Jason (Jason) wrote: > Adding netconf into this as we're talking about generic netconf functionality here. > > The concept of having other (somewhat arbitrary) data stores is something that may be useful for this "debug" type of configuration. It may even make sense to have both a debug-running & a debug-startup datastore for debug (and perhaps a debug-candidate as well). Some implementations effectively treat debug as a separate datastore (e.g. allow saving debug info separately from the rest of the configuration). > > A similar approach may also make sense for Lawful Interception configuration which is often treated separately from the rest of config. > > I think we'd have to extend the in some way to indicate which capabilities (which yang modules) apply to which datastores. > > Jason > > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, March 03, 2015 5:12 AM > To: David Ball > Cc: Mahesh Jethanandani; rtg-yang-coord@ietf.org > Subject: Re: [Rtg-yang-coord] YANG leaf writing to running-datastore > > On Tue, Mar 03, 2015 at 09:55:30AM +0000, David Ball wrote: > > Wouldn't that be best done with an RPC? > > > > An ephemeral data store would provide a generic solution for this kind of problem. RPCs tend to be specific (or you invent a generic RPC that actually models an ephemeral data store). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- 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 Mar 3 06:16:14 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C9E1A7D83 for ; Tue, 3 Mar 2015 06:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 rFPtjryAboiQ for ; Tue, 3 Mar 2015 06:16:06 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364391A86DD for ; Tue, 3 Mar 2015 06:16:06 -0800 (PST) Received: by lams18 with SMTP id s18so37621921lam.13 for ; Tue, 03 Mar 2015 06:16:04 -0800 (PST) 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=Mz+2nb4tN+kvPREqNFej2SKzA70FHZrQpjjPz+a4JcI=; b=QzZv8W0M/wUgfhmAnKnHetz7wx22w9uOsJULVyZb3I8WmnK/dKkHxjoQBiCjZWm62y Ep9bm1BGRNtj2yrhW8/G5f7T3XDe4qUE4Xltc8mSlOaTpIEGhLqou8jHJLEBaYqyzDp6 /nGyO4yjBq+fkTe6E4l9Y/oi16V0D4vYxJVK2xiZ3oIiF8xQfMhzbbs7f/Q8+mb8Mg2d suzYEpixniz+DywJzGsOxiOAuBaGU12k5ctiGy9syQIVK1l87VrzpGpZyDJds39V+ZNo r03gxPOtWzM/eMA0y7gGieDa6+F4UWrabif1ShyZ7qNXO8A/6M58oDaX6RH5aQ1Htfpj EDIg== X-Gm-Message-State: ALoCoQmnW1EqomkMtLRGFjMkZyiGIgcUUzr3gbYQrmXOywTJRUM6ovrWw2+IGew1v6AEv7qqyzx8 MIME-Version: 1.0 X-Received: by 10.112.139.136 with SMTP id qy8mr29246176lbb.38.1425392164626; Tue, 03 Mar 2015 06:16:04 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 3 Mar 2015 06:16:04 -0800 (PST) In-Reply-To: <20150303.091221.1320688875820544524.mbj@tail-f.com> References: <201503030346.t233k2Qt036627@idle.juniper.net> <20150303.091221.1320688875820544524.mbj@tail-f.com> Date: Tue, 3 Mar 2015 06:16:04 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 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, 03 Mar 2015 14:16:13 -0000 On Tue, Mar 3, 2015 at 12:12 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Mon, Mar 2, 2015 at 7:46 PM, Phil Shafer wrote: >> > Andy Bierman writes: >> >>RESTCONF edit operations are done on data resources. >> >>NETCONF is not resource-oriented. >> >> >> >>YANG Patch edits are ordered. >> >>NETCONF order (and whether or not a real >> >>edit is invoked) is implementation-dependent. >> >> >> >>YANG Patch might allow edits to be encoded more efficiently >> >>since the config 'scaffolding' is not part of the each edit. >> >>Operations such as 'move' are explicit and more efficient >> >>to encode than YANG insert. >> > >> > That's a really short list, and it looks like the first and last >> > are the same (since "data resource" means a path into a datastore, >> > right?). >> > >> > Encoding efficiency aside, what's the big innovation in yang-patch? >> > If it's really just putting multiple change payloads in a single >> > request such that any of them can fail independently, aren't we >> > better served by adding this to edit-config, perhaps as a sister >> > attribute to "op"? >> > >> >> What is so great about the implementation-dependent blob? >> Why are a set of attributes (1 in NETCONF, the rest defined in YANG) >> better than an edit list? > > To be fair, I think Phil is right in that the expressiveness of both > formats are equal. Which one you prefer is subjective, possibly > influenced by implementation choices. > I think I could find examples where the patch XML was shorter than the XML. IMO there very few interoperability ambiguities with an edit list approach. I bet there are differences in the way servers handle nested operation/insert attributes. Embedding the actions in the data is not equivalent. > The question boils down to if we think it is good to have two more or > less equal ways of doing things, or if there is value in having one > single mechanism. > But we are not creating NETCONF over HTTP. RESTCONF is a different protocol than NETCONF. I don't understand why the message encoding should be the same for this subset of NETCONF functionality. >> I have heard some comments that the patch approach is more direct >> and easier for the client to convey its intent. A set of ordered edits >> provides more client control for setting up dependencies. > > Even with YANG PATCH, it is the resulting datastore that is validated, > so the order of the edits doesn't matter. > > > /martin > Andy > >> IMO the NETCONF encoding of an edit is irrelevant to RESTCONF. >> RESTCONF does not use an element wrapper for operations >> either. Most (if not all) of the message encoding details are different. >> >> >> > Thanks, >> > Phil >> > >> > P.s.: The term "urlpath" sounds odd; URLs _are_ paths, right? >> >> >> Andy >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> From nobody Tue Mar 3 08:15:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5C01A883D for ; Tue, 3 Mar 2015 08:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 v32z4xwWAJMX for ; Tue, 3 Mar 2015 08:15:32 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82AAC1A8846 for ; Tue, 3 Mar 2015 08:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2822; q=dns/txt; s=iport; t=1425399332; x=1426608932; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=4ItymLCNzJFEElpcoO1JWbj1wWDIaclYGCcnu8w+MOE=; b=By87BpeZeKNND/wDRYH4U8VCIXDpqeoiKRwYBHAX5qZI3icYlsZvADTi sUO4MHM1GGG80ZGlK5bNEwGqfnoVv/3nc0f+d7DdtQVK6UNlbDi9CcdiV 7rqC6pZG+SH0N6CsdtexhTfms9xcjLFEr9+lNVkgc973SRCVMtOCntZHN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQBo3fVU/4kNJK1agwLIZAKBKE0BAQEBAQF8hBABAQQ4QBELDgoJFg8JAwIBAgFFBgEMCAEBF4gU1jABAQEBAQEBAwEBAQEBARyKFH6EdYQrAQSKXY5lgRqFVIkzgz4jggIcgW4ggnQBAQE X-IronPort-AV: E=Sophos;i="5.09,682,1418083200"; d="scan'208";a="397393909" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP; 03 Mar 2015 16:15:31 +0000 Received: from [10.150.55.87] (dhcp-10-150-55-87.cisco.com [10.150.55.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t23GFV1j023980; Tue, 3 Mar 2015 16:15:31 GMT Message-ID: <54F5DE23.9090605@cisco.com> Date: Tue, 03 Mar 2015 11:15:31 -0500 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" References: <54F47CDA.9080908@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] zerotouch issues and fixes 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, 03 Mar 2015 16:15:34 -0000 On 3/2/15 10:43 AM, Kent Watsen wrote: > > >> I think this approach is reasonable. The interaction with the vendor is >> minimal (only to claim the device-IDs and get the voucher). > > Exactly, this solution optimizes for the vendor - it's very low-touch and > doesn't rely on a realtime lookup service. But "reasonable" sounds > uncommitted - what we need to know is it's better - what do you think? Sorry, didn't mean to sound noncommittal. I like it. I just think the questions I had raised need to be addressed (i.e., around Owner ID and verifying expiry on the device's part). > > >> Though, the >> time-to-live of the voucher needs to be accounted for by the device. It >> needs to confirm the voucher is still "alive." > > Yes, there is a presumption that the device has an accurate clock. Such > it is with PKI in general. For instance, CRLs are only useful if they're > relatively fresh (a year-old CRL is not very useful). Of course. It's just you didn't mention that in your rough walk-through. That needs to be part of the process. > > > >> Would it make sense to >> have a per-device TTL in the voucher? > > This would be doable. As a voucher is a data file (not a X.509 > certificate), for which we could define schema for, and thus it could take > any form we deem best. That said, I question if it makes sense for a > vendor to issue a voucher with varying TTLs. Is the vendor suppose to > know that some device's ownership is more volatile than others? - or do > you see this as user-input? I see this as user input. The use case I envision is that the owner might set a certain timeline for other devices to give a safety net to prevent old devices from bootstrapping. It may not be common, and thus this could be a MAY. It just offers flexibility. > > >> I also think there needs to be a way for the NMS to request an owner ID. >> The reason for this is what happens if I have to replace the NMS. I >> would need a new private key and a new CSR. While I could get a new >> voucher with the new owner ID, this would likely be more of a hassle as >> the vendor will likely associate the devices with one owner ID. > > Yes, vendors would have to be able to reissue the NMS certificates. > Vendors could re-assign the same Owner ID the NMS had before or generate a > new one. If a new Owner ID is generated, then the vendor would also need > to reissue Vouchers for devices that have not yet been claimed (e.g., gone > through the zerotouch process). How do we state this in the draft? I think it deserves a callout. The Owner ID can't simply be a random thing, but needs to tie to the owner entity (yet still be unique between entities). Can we say that the owner entity can suggest an Owner ID? Joe From nobody Tue Mar 3 12:54:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3024E1A8973 for ; Tue, 3 Mar 2015 12:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 X4RKTBX1zHlK for ; Tue, 3 Mar 2015 12:54:46 -0800 (PST) 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 BD05A1A897F for ; Tue, 3 Mar 2015 12:54:45 -0800 (PST) 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 t23KshVi013959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Mar 2015 20:54:43 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 t23Ksg56028942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Mar 2015 21:54:43 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 3 Mar 2015 21:54:42 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.51]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0224.002; Tue, 3 Mar 2015 21:54:42 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 Thread-Index: AQHQVfRFiDZYLk7nAUSRP8UJhEDU+g== Date: Tue, 3 Mar 2015 20:54:42 +0000 Message-ID: References: <20150226140426.GA31778@elstar.local> In-Reply-To: <20150226140426.GA31778@elstar.local> 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: 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: 11163 X-purgate-ID: 151667::1425416083-000067C4-B77FFD00/0/0 Archived-At: Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 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, 03 Mar 2015 20:54:49 -0000 All, it seems that we had only one serious review of the Restconf and YANG patch= drafts so far. This is not sufficient for drafts with such substantial content. To be able to call the WGLC successful we need more detailed reviews. Please continue reviewing and commenting on the Restconf/YANG Patch drafts. Thank you. Mehmet=20 -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Juergen Sc= hoenwaelder Sent: Thursday, February 26, 2015 3:04 PM To: netconf@ietf.org Subject: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04 On Thu, Feb 05, 2015 at 01:22:43PM +0000, Ersue, Mehmet (NSN - DE/Munich) w= rote: > Dear NETCONF WG, > we hereby issue a WG Last Call for 3 weeks for the drafts below: >=20 > https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 > https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 >=20 > Please review and send your comments to the NETCONF WG mailing list by Fe= bruary 26, 2015 EOB PT. Hi, Here is my review of draft-ietf-netconf-restconf-04. Comments come roughly in the order of the document. I am running out of time to get a review done of draft-ietf-netconf-yang-patch-03 by today's deadline. I may get to it by Monday (but no hard promise). /js - I suggest to follow RFC 6020 and use 'RPC operations' instead of 'protocol operations' but then I note that RFC 6241 uses 'protocol operations'. Too bad that we are not consistent. (Should we try to settle on a single term? Perhaps we should fix this in YANG 1.1?) - I suggest to use 'event notifications' instead of 'notification events'. The model, I think, is that event occurs that leads to a notification. I later parts of the document the term 'event notification' is actually used. - What exactly is the 'framework' and in particular the 'meta-model' referred to in section 1.1? I do not understand the 'instead' - instead of what? - The document talks about API resources pretty early but it is somewhat unclear what API resources are. Even section 3.3 is leaving me as an almost first time reader somewhat confused. Why is this thing called an API resource? Section 3.3 makes me believe this is simply a top-level container for data and operations (not sure where the other resources hang in the URI space or why they are not API resources). - What does it meant that "configuration persistence are handled by the server and not controlled by the client." Is this trying to tell me that the client has no way of knowing whether any config changes persist? If so, is this useful? Or is the idea that all edits will eventually persist but not necessarily immediately, which seems to be what the last paragraph in 3.4 hints at. I am also unsure what this means: "There is no guarantee [...] that the saved configuration is always a mirror of the NETCONF running datastore, if the server also supports NETCONF." What is a NETCONF/RESTCONF server that supports #startup doing if edits are received via both NETCONF and RESTCONF? Perhaps there is a need to factor all this out into a separate section discussing NETCONF/RESTCONF coexistence. I think there are additional things to discuss, e.g. that a combined server also MUST maintain NETCONF last change time stamps, no? - It often reads as if there can be multiple datastore resources but then at other places it seems there is only one datastore resource, namely {+restconf}/data. (I am wondering why this is actually a good idea, why do we not have {+restconf}/running plus optionally {+restconf}/startup? I can understand why exposing candidate may not be useful, but saying there is {+restconf}/data and it magically interacts with NETCONF's running and startup datastores makes it difficult for me to understand what is going on. If the goal is to not expose startup, then why not {+restconf}/running? How does {+restconf}/data different from NETCONF's running? - I am not sure I fully understand how key values are encoded in corner cases where the value includes characters that conflict with the format. What exactly is 'a quoted or unquoted empty string'? Which quoting rules apply? And is the syntax defined in section 3.5.1 the syntax before or after URI pct-encoding? I guess this is before pct-encoding, no? I think this encoding needs additional clarification and perhaps some examples showing how clashes are handled. - It seems section 3.6 says operation resources only need a module name if the server supports operations with conflicting names. I think this makes interoperability actually more complex. I would prefer is both top-level data resources as well as operations resources require to use a module name. - In section 3.6, why is sending a body a MAY if the "rpc" statement defines either input or output? Should this not be a MUST? - Since XML is the default to implement encoding, would it make sense to show the examples in XML instead of JSON? Or show them in both encodings? (A few examples, e.g. section 4.6, do show both.) - Perhaps add 'module example-ops { ... }' around the examples in sections 3.6.1 and 3.6.2 so that it is clear where example-ops is coming from. - The example insection 3.7 seems to use the data model defined in draft-ietf-netconf-yang-library-00.txt. I think there should be an explicit reference to it (and this needs to be consistent with the above mentioned I-D). - Section 4.5 says that data resources can be created using PUT, which is slightly at odds with Table 1. - Section 4.2 and following sections refer to an "entry point component". Is this the same as "entry point" or something different? I am not sure what it is. Should this term be defined in the terminology or can we replace it with something already defined? - Section 4.3, when do I return 403 and when 404 or can I choose between these error responses as I like? This seems to also apply to subsequent sections. - The line wrapping in the table in section 4.8.1 is unfortunate since it makes with-defaults to read as two separate entries. - Section 4.8 is about query parameters but then it section 4.8.1 and subsequent sections discuss restconf capabilities that are not query parameters. I found this a bit confusing and perhaps the document structure should be changed to avoid discussing general protocol capabilities where a reader expects a discussion of query parameters. When discussing (protocol) capabilities, it may be useful to mention how they can be retrieved. - In section 4.8.4, I am not sure yet how nest levels are counted. If I request {+restconf}/data/foo which contains the child bar, is the child bar at nest level 2 or 1? An explicit example might help. - Should the "insert" and "point" parameters not be required to implement? If they are optional, then adding something to a list or leaf-list ordered by user will be impossible, no? - For the notification examples, would it make sense to provide an outline of the the corresponding YANG definition, e.g, module example-mod { namespace "http://example.com/event/1.0"; notification event { leaf event-class { type string; } container reporting-entity { leaf card { type string; } } leaf severity { type string; } } } Did I get this right? Not sure this is the best example. Perhaps we should consider using already RFC published data model snippets as examples instead of mock-up examples. Well, this already leads to another question. Does netconf-config-change (RFC 6470) makes sense for RESTCONF? If so, how to fill in the details? So perhaps these notifications do only apply to a NETCONF server but not to a RESTCONF server. So do we have similar definitions for RESTCONF? - Looking at the tree diagram of the ietf-restconf-monitoring module, I was wondering whether +--ro encoding* [type] +--ro type string +--ro events inet:uri should not be better named +--ro access* [encoding] +--ro encoding string +--ro location inet:uri - I am also wondering whether ietf-restconf-monitoring is really the right module name. It defines objects to obtain the restconf capabilities and to find access points for the notification streams, this is not exactly monitoring. Perhaps -monitoring was a not so good choice back then and we now stay with it for consistency... Anyway, should there be explicit text that restconf capabilities must not show up in ietf-netconf-monitoring and that the counters in ietf-netconf-monitoring will not be bumped by restconf interactions? Perhaps this also belongs into a section discussing NETCONF/RESTCONF coexistance issues, see above. - Section 10 normatively depends on draft-ietf-netconf-yang-library (as correctly stated in 14.1 - there are acutally quite a few things that we need to finish up in order to publish this document). I am not sure, though, that [rest-dissertation] really is normative. [XPATH] on the other hand seems to be normative rather than informative (see the filter option). - Several TBD in 11.3 probably need to be filled in. - For creating a RESTCONF Capability Registry (section 11.4), it will be necessary to specify the rules IANA should use to handle the registry. - In section 12, I do not understand what is meant with this: Implementors SHOULD provide a comprehensive authorization scheme with RESTCONF and ensure that the resulting NETCONF username is made available to the RESTCONF server. Is this authorization or authentication? And what does "comprehensive" translate to? What does "SHOULD be implemented carefully with adequate attention to all manner of attack one might expect to experience with other management interfaces." mean? Do you mean 'implemented' or 'deployed'? - In the jukebox YANG module (I understand it is only an example), I am somewhat concerned to see rc:data-resource-identifier. This kind of sends the signal that it is OK to write RESTCONF specific YANG data models. Frankly, if the end result is that we get RESTCONF and NETCONF specific data models, then perhaps we should not even do RESTCONF in the first place. I do understand the value of having a REST interface but I am also very much concerned if data models become either NETCONF or RESTCONF specific. - I have not reviewed the examples in appendix D. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Mar 3 14:16:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3B1A89BB for ; Tue, 3 Mar 2015 14:16:28 -0800 (PST) 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 5uQobTDreOXU for ; Tue, 3 Mar 2015 14:16:26 -0800 (PST) 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 D6CB91A89B8 for ; Tue, 3 Mar 2015 14:16:25 -0800 (PST) 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 t23MGNLn002362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 3 Mar 2015 22:16:24 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 t23MGLYO032465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Mar 2015 23:16:23 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 3 Mar 2015 23:16:21 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.51]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0224.002; Tue, 3 Mar 2015 23:16:21 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: [Netconf] call-home-04 and server-model-06 available - All Open issues closed Thread-Index: AQHQVf+tT/7bNpWPUkyuK74/P/SDow== Date: Tue, 3 Mar 2015 22:16:21 +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_E4DE949E6CE3E34993A2FF8AE79131F81964E27ADEMUMBX005nsnin_" 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: 36151 X-purgate-ID: 151667::1425420984-000067C4-0BBF6E88/0/0 Archived-At: Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed 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, 03 Mar 2015 22:16:28 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81964E27ADEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, we hereby issue a WG Last Call for 2 weeks for the drafts below: https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 Please review and send your comments to the NETCONF WG mailing list by Marc= h 17, 2015 EOB PT. Call Home and Server Model drafts are planned to publish as standard track = documents. Please state explicitly that you have read/reviewed and whether you support= the publication of the drafts. Please indicate also if you plan to implement or have already implementatio= n experience with the these drafts. Thank you, Mehmet and Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Thursday, February 05, 2015 5:30 PM To: netconf@ietf.org Subject: [Netconf] call-home-04 and server-model-06 available - All Open is= sues closed All, all call-home issues have been solved and there are 3 issues for server-mod= el draft in REVIEW state. See https://github.com/netconf-wg/call-home/issues?q=3Dis%3Aissue+is%3Aclos= ed and https://github.com/netconf-wg/server-model/issues. Please check the provided solutions in the updated drafts and comment befor= e we go to WGLC after the end of Restconf LC. https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F81964E27ADEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear NETCONF WG,

=  

= we hereby issue a WG Last Call for 2 weeks for the drafts below:

=  

= https://tools.ietf.org/html/draft-ietf-netconf-call= -home-04

= https://tools.ietf.org/html/draft-ietf-netconf-s= erver-model-06

=  

= Please review and send your comments to the NETC= ONF WG mailing list by March 17, 2015 EOB PT.

=  

= Call Home and Server Model drafts are planned to publish as standard track documents.

=  

= Please state explicitly that you have read/revie= wed and whether you support the publication of the drafts.

= Please indicate also if you plan to implement or have already implementation experience with the these drafts.

=  

= Thank you,

= Mehmet and Mahesh

=  

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Thursday, February 05,= 2015 5:30 PM
To: netconf@ietf.org
Subject: [Netconf] call-home= -04 and server-model-06 available - All Open issues closed

 

= All,=

=  

= all call-home issues h= ave been solved and there are 3 issues for server-model draft in REVIEW state.

= See https://github.com/netconf-wg/call-home/issues?q=3Dis%3Aissue+is%3Aclos= ed and

= https://github.com/netconf-wg/serve= r-model/issues.

=  

= Please check the provi= ded solutions in the updated drafts and comment before we go to WGLC after the end of Restconf LC.

=  

= https://tools.ietf.org/ht= ml/draft-ietf-netconf-call-home-04&nbs= p;

= https://tools.ietf.org= /html/draft-ietf-netconf-server-model-06 

=  

= Regards,

= Mehmet

=  

--_000_E4DE949E6CE3E34993A2FF8AE79131F81964E27ADEMUMBX005nsnin_-- From nobody Tue Mar 3 15:35:45 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C321A1EF2 for ; Tue, 3 Mar 2015 15:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 83aHNo-B-38J for ; Tue, 3 Mar 2015 15:35:42 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3563B1A1C06 for ; Tue, 3 Mar 2015 15:35:42 -0800 (PST) Received: by lamq1 with SMTP id q1so17814584lam.0 for ; Tue, 03 Mar 2015 15:35:40 -0800 (PST) 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=6J/FJbnLKqlDFc4FN6rUDegfHnjTYiEfrdxfH+/1zXE=; b=B/5Wqgv43BEKplZCkqJkAAwVWZet1mjpv/QRYvIAYqMl4JXBVCww/x3wqUPKbuqxXQ /nZaOSTNOECQFfIha2X5kIR4gn/EKt+ZSTYXuymkB9RmyZ2GBNKs4r/n7Z/B5W1phr7Z TWEntCTT2p/IQZ+Gmmw14zYtX1s+O+wG807qe/mpESaT8q4E0STpSK4azLBWUYIiuLOb CqHaJ42u8UQkk9aN4bxpCmTh2QOr7N+9RAnb8tPonffLevhmERkD0sC6YGwGGccARKoo g0y2Iasee6RTY6QC5wUgsa8oMe/c1AagU7VA02qDOMl2sNh0fAmWyRcWllbFvdhLrwIT i7Zw== X-Gm-Message-State: ALoCoQkjDFZ8omBKDYEiUuiTV8gIZQHEsqYkApAg8b0du/H+rSn0molKlRT2neYQDia0/4Yn71Zd MIME-Version: 1.0 X-Received: by 10.152.88.99 with SMTP id bf3mr1003162lab.37.1425425740699; Tue, 03 Mar 2015 15:35:40 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 3 Mar 2015 15:35:40 -0800 (PST) In-Reply-To: <20150226.180400.1762013018376155853.mbj@tail-f.com> References: <20150226.180400.1762013018376155853.mbj@tail-f.com> Date: Tue, 3 Mar 2015 15:35:40 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 03 Mar 2015 23:35:44 -0000 On Thu, Feb 26, 2015 at 9:04 AM, Martin Bjorklund wrote: > "Ersue, Mehmet (NSN - DE/Munich)" wrote: >> Dear NETCONF WG, >> we hereby issue a WG Last Call for 3 weeks for the drafts below: >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 > > I have mentioned this before, but I don't think it has been resolved > yet - the usage of anyxml in the patch document needs more work. > Together with the latest json draft, the anyxml usage is > underspecified, and will not be interoperable. > I think the draft is clear how to encode YANG data nodes within the "value" anyxml node. The problem is if the data node pointed at by "target" (or its descendants) is an anyxml node. IMO Phil's string leaf encoding of the web-banner applies to XML as well as JSON when the content is any XML. The anyxml node is supposed to be a terminal (i.e., it can only be edited or retrieved as a whole). It cannot be a terminal and also (sometimes) have child nodes. This is the difference between anyxml and anydata. The "anyxml" node is any XML. It is a terminal. It never has any child nodes. Any nested XML elements are just part of the terminal node, not child data nodes. The "anydata" node is an arbitrary YANG data subtree. Anyxml usage such as "root" and other containers are useful hacks, but they are really expecting any data, not any XML. > > /martin Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Mar 4 05:34:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04EB1A1AC7 for ; Wed, 4 Mar 2015 05:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 L_nrH5WLqJaD for ; Wed, 4 Mar 2015 05:34:33 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id AD1AA1A1AB8 for ; Wed, 4 Mar 2015 05:34:32 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 8620B1280D07; Wed, 4 Mar 2015 14:34:31 +0100 (CET) Date: Wed, 04 Mar 2015 14:34:31 +0100 (CET) Message-Id: <20150304.143431.863393506364661618.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150226.180400.1762013018376155853.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: Cc: mehmet.ersue@nsn.com, netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 04 Mar 2015 13:34:34 -0000 Andy Bierman wrote: > On Thu, Feb 26, 2015 at 9:04 AM, Martin Bjorklund wrote: > > "Ersue, Mehmet (NSN - DE/Munich)" wrote: > >> Dear NETCONF WG, > >> we hereby issue a WG Last Call for 3 weeks for the drafts below: > >> > >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 > >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 > > > > I have mentioned this before, but I don't think it has been resolved > > yet - the usage of anyxml in the patch document needs more work. > > Together with the latest json draft, the anyxml usage is > > underspecified, and will not be interoperable. > > > > > I think the draft is clear how to encode YANG data nodes > within the "value" anyxml node. I don't understand this. Assume we have: container servers { list server { key name; leaf name { type string; } container address { leaf ip { type inet:ip-address; } leaf port { type inet:port-number; } } } } Now I want to set address/port and enabled in a given server instance. In XML I would do: PATCH /restconf/data/my-module:servers/server=srv1 1 merge . srv1
42
true Now, I want to do this in JSON. First of all I just noticed that YANG PATCH is missing a reference to draft-ietf-netmod-yang-json. Anyway, there is no special text in YANG PATCH about json encoding, so I assume that the rules defined in draft-ietf-netmod-yang-json applies. "value" is of type anyxml, so I look at draft-ietf-netmod-yang-json to see what it says about "anyxml": An anyxml instance is encoded as a name/value pair. The value can be of any valid JSON type, i.e. an object, array, number, string or one of the literals "true", "false" and "null". So maybe I do: "value": [ "server": { "name": "srv1", "address": { "port": 42 } "enabled": "true" } ] This seems to be valid according to draft-ietf-netmod-yang-json. Will all servers understand it? > The problem is if the > data node pointed at by "target" (or its descendants) > is an anyxml node. > > IMO Phil's string leaf encoding of the web-banner applies to > XML as well as JSON when the content is any XML. If the leaf is of type "string", and contains a web-banner, there is no problem. > The anyxml node is supposed to be a terminal > (i.e., it can only be edited or retrieved as a whole). Yes. > It cannot be a terminal and also (sometimes) have child nodes. > > This is the difference between anyxml and anydata. > > The "anyxml" node is any XML. > It is a terminal. It never has any child nodes. > Any nested XML elements are just part of the terminal node, > not child data nodes. > > The "anydata" node is an arbitrary YANG data subtree. No, I think that "anydata" should also be treated as a terminal node. /martin From nobody Wed Mar 4 06:13:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0B1A1B22 for ; Wed, 4 Mar 2015 06:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 n-rP9i1fcLoi for ; Wed, 4 Mar 2015 06:13:19 -0800 (PST) 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 4E2CB1A1B18 for ; Wed, 4 Mar 2015 06:13:19 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:f418:f30:9ac2:9c67] (unknown [IPv6:2001:718:1a02:1:f418:f30:9ac2:9c67]) by mail.nic.cz (Postfix) with ESMTPSA id C534B13F7A6; Wed, 4 Mar 2015 15:13:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1425478397; bh=qrMAn00nXfkKASW9/Ivz1jr5tsF7o6TkzSHI7LEYPFw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=uJx9RwPvAIGVUVk+QqikS2iN7fKMZeHMGqVQ3AePUCbBMM1W+scDTZefudbLNBKJm KKG/EacDe7QS2rjeuohKJ9YI3pjTZwFTP13PJlOPFSn4sT8GCcKKCeEpwjHteNX7pU /NJoGtUKEJWUbF9Xqoe5Z0th0BZjfOvFxdrsZx9w= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150304.143431.863393506364661618.mbj@tail-f.com> Date: Wed, 4 Mar 2015 15:13:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150226.180400.1762013018376155853.mbj@tail-f.com> <20150304.143431.863393506364661618.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: Mehmet Ersue , Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 04 Mar 2015 14:13:21 -0000 > On 04 Mar 2015, at 14:34, Martin Bjorklund wrote: >=20 > Andy Bierman wrote: >> On Thu, Feb 26, 2015 at 9:04 AM, Martin Bjorklund = wrote: >>> "Ersue, Mehmet (NSN - DE/Munich)" wrote: >>>> Dear NETCONF WG, >>>> we hereby issue a WG Last Call for 3 weeks for the drafts below: >>>>=20 >>>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 >>>> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 >>>=20 >>> I have mentioned this before, but I don't think it has been resolved >>> yet - the usage of anyxml in the patch document needs more work. >>> Together with the latest json draft, the anyxml usage is >>> underspecified, and will not be interoperable. >>>=20 >>=20 >>=20 >> I think the draft is clear how to encode YANG data nodes >> within the "value" anyxml node. >=20 > I don't understand this. >=20 > Assume we have: >=20 > container servers { > list server { > key name; > leaf name { type string; } > container address { > leaf ip { type inet:ip-address; } > leaf port { type inet:port-number; } > } > } > } >=20 > Now I want to set address/port and enabled in a given server > instance. >=20 > In XML I would do: >=20 > PATCH /restconf/data/my-module:servers/server=3Dsrv1 >=20 > > > 1 > merge > . > > > srv1 >
> 42 >
> true > > > > >=20 > Now, I want to do this in JSON. >=20 > First of all I just noticed that YANG PATCH is missing a reference to > draft-ietf-netmod-yang-json. >=20 > Anyway, there is no special text in YANG PATCH about json encoding, so > I assume that the rules defined in draft-ietf-netmod-yang-json > applies. IMO this is not automatic and the description of =E2=80=9Canyxml = value=E2=80=9D should explicitly state that the value must be an = instance of a container whose schema is determined by the sibling = =E2=80=9Ctarget=E2=80=9D leaf, and that its encoding in XML and JSON = must follow the rules of RFC 6020 and draft-ietf-netmod-yang-json, = respectively. Lada >=20 > "value" is of type anyxml, so I look at draft-ietf-netmod-yang-json to > see what it says about "anyxml": >=20 > An anyxml instance is encoded as a name/value pair. The value can > be of any valid JSON type, i.e. an object, array, number, string or > one of the literals "true", "false" and "null". >=20 > So maybe I do: >=20 > "value": [ "server": { "name": "srv1", > "address": { "port": 42 } > "enabled": "true" > } ] >=20 > This seems to be valid according to draft-ietf-netmod-yang-json. Will > all servers understand it? >=20 >=20 >> The problem is if the >> data node pointed at by "target" (or its descendants) >> is an anyxml node. >>=20 >> IMO Phil's string leaf encoding of the web-banner applies to >> XML as well as JSON when the content is any XML. >=20 > If the leaf is of type "string", and contains a web-banner, there is > no problem. >=20 >> The anyxml node is supposed to be a terminal >> (i.e., it can only be edited or retrieved as a whole). >=20 > Yes. >=20 >> It cannot be a terminal and also (sometimes) have child nodes. >>=20 >> This is the difference between anyxml and anydata. >>=20 >> The "anyxml" node is any XML. >> It is a terminal. It never has any child nodes. >> Any nested XML elements are just part of the terminal node, >> not child data nodes. >>=20 >> The "anydata" node is an arbitrary YANG data subtree. >=20 > No, I think that "anydata" should also be treated as a terminal node. >=20 >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 4 06:53:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B443C1A1BE7 for ; Wed, 4 Mar 2015 06:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 cU4BMTQFqjcY for ; Wed, 4 Mar 2015 06:53:51 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7041A1EF1 for ; Wed, 4 Mar 2015 06:53:51 -0800 (PST) Received: by labgm9 with SMTP id gm9so5357291lab.7 for ; Wed, 04 Mar 2015 06:53:50 -0800 (PST) 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 :content-transfer-encoding; bh=ooVAhXl88GsFjIxPwHg7n4Y3Fpgl6KB5sR8WXKGofUA=; b=jRCPcOFCxWZGvZRR3UWzGVgf+Akwe4Hnawj+PQoXXv73Vr3bAO8m6kvk8Nuv5pfsBF 7+sH+aIkRtQQ/d0hVGdtHGprEhj3WirHjATZn+FwuMF5Z/Mu4Ht9yWOiQumYTsfWs59Z VAQmeUtCwG5ET7cegkK59n32MWrf//3KreoaoFIW8Jlm72v9n1Ndl1nFr1FVeIEyJOFX LW0zlpsGI4H/bXyDaBa17OZQ1U/HsBZnETAK4M5tA2hZI7ducT/lxmw+IAH0Eg56e+I2 FmdVeseTHNjo/kVr0oMp7I1PCsH4lNzeBd9ZWuUMUOMB/q2pHFspPiykObpsYAQrUZt3 mN3Q== X-Gm-Message-State: ALoCoQlcAMaHWlNm4fV24hX6XF3SBYgOIxEAziEyjMacuPavoqTHNAmZ+v57G5k3J+Z767NtWBu6 MIME-Version: 1.0 X-Received: by 10.152.243.4 with SMTP id wu4mr3808929lac.33.1425480829899; Wed, 04 Mar 2015 06:53:49 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 4 Mar 2015 06:53:49 -0800 (PST) In-Reply-To: References: <20150226.180400.1762013018376155853.mbj@tail-f.com> <20150304.143431.863393506364661618.mbj@tail-f.com> Date: Wed, 4 Mar 2015 06:53:49 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mehmet Ersue , Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 04 Mar 2015 14:53:53 -0000 On Wed, Mar 4, 2015 at 6:13 AM, Ladislav Lhotka wrote: > >> On 04 Mar 2015, at 14:34, Martin Bjorklund wrote: >> >> Andy Bierman wrote: >>> On Thu, Feb 26, 2015 at 9:04 AM, Martin Bjorklund wrot= e: >>>> "Ersue, Mehmet (NSN - DE/Munich)" wrote: >>>>> Dear NETCONF WG, >>>>> we hereby issue a WG Last Call for 3 weeks for the drafts below: >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 >>>>> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 >>>> >>>> I have mentioned this before, but I don't think it has been resolved >>>> yet - the usage of anyxml in the patch document needs more work. >>>> Together with the latest json draft, the anyxml usage is >>>> underspecified, and will not be interoperable. >>>> >>> >>> >>> I think the draft is clear how to encode YANG data nodes >>> within the "value" anyxml node. >> >> I don't understand this. >> >> Assume we have: >> >> container servers { >> list server { >> key name; >> leaf name { type string; } >> container address { >> leaf ip { type inet:ip-address; } >> leaf port { type inet:port-number; } >> } >> } >> } >> >> Now I want to set address/port and enabled in a given server >> instance. >> >> In XML I would do: >> >> PATCH /restconf/data/my-module:servers/server=3Dsrv1 >> >> >> >> 1 >> merge >> . >> >> >> srv1 >>
>> 42 >>
>> true >> >> >> >> >> >> Now, I want to do this in JSON. >> >> First of all I just noticed that YANG PATCH is missing a reference to >> draft-ietf-netmod-yang-json. >> >> Anyway, there is no special text in YANG PATCH about json encoding, so >> I assume that the rules defined in draft-ietf-netmod-yang-json >> applies. > > IMO this is not automatic and the description of =E2=80=9Canyxml value=E2= =80=9D should explicitly state that the value must be an instance of a cont= ainer whose schema is determined by the sibling =E2=80=9Ctarget=E2=80=9D le= af, and that its encoding in XML and JSON must follow the rules of RFC 6020= and draft-ietf-netmod-yang-json, respectively. > It does say that. I don't really see any consensus forming wrt/ anyxml or anydata. Perhaps it is time to declare the issue dead. If a vendor really wants to store raw XML in their config, they will figure out a way to do that. > Lada Andy > >> >> "value" is of type anyxml, so I look at draft-ietf-netmod-yang-json to >> see what it says about "anyxml": >> >> An anyxml instance is encoded as a name/value pair. The value can >> be of any valid JSON type, i.e. an object, array, number, string or >> one of the literals "true", "false" and "null". >> >> So maybe I do: >> >> "value": [ "server": { "name": "srv1", >> "address": { "port": 42 } >> "enabled": "true" >> } ] >> >> This seems to be valid according to draft-ietf-netmod-yang-json. Will >> all servers understand it? >> >> >>> The problem is if the >>> data node pointed at by "target" (or its descendants) >>> is an anyxml node. >>> >>> IMO Phil's string leaf encoding of the web-banner applies to >>> XML as well as JSON when the content is any XML. >> >> If the leaf is of type "string", and contains a web-banner, there is >> no problem. >> >>> The anyxml node is supposed to be a terminal >>> (i.e., it can only be edited or retrieved as a whole). >> >> Yes. >> >>> It cannot be a terminal and also (sometimes) have child nodes. >>> >>> This is the difference between anyxml and anydata. >>> >>> The "anyxml" node is any XML. >>> It is a terminal. It never has any child nodes. >>> Any nested XML elements are just part of the terminal node, >>> not child data nodes. >>> >>> The "anydata" node is an arbitrary YANG data subtree. >> >> No, I think that "anydata" should also be treated as a terminal node. >> >> >> /martin >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Wed Mar 4 06:58:45 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6821F1A1BE7 for ; Wed, 4 Mar 2015 06:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 57moPZdnQmoR for ; Wed, 4 Mar 2015 06:58:41 -0800 (PST) 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 92DCF1A1B8B for ; Wed, 4 Mar 2015 06:58:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D1DCAB1A; Wed, 4 Mar 2015 15:58:37 +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 fYnEg3mN0eho; Wed, 4 Mar 2015 15:58:22 +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; Wed, 4 Mar 2015 15:58:36 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C25B20039; Wed, 4 Mar 2015 15:58:36 +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 plWLFGIa9M-i; Wed, 4 Mar 2015 15:58:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB6AC20036; Wed, 4 Mar 2015 15:58:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EEABC325AC53; Wed, 4 Mar 2015 15:58:31 +0100 (CET) Date: Wed, 4 Mar 2015 15:58:30 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150304145830.GA67626@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Mehmet Ersue , Netconf References: <20150226.180400.1762013018376155853.mbj@tail-f.com> <20150304.143431.863393506364661618.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Mehmet Ersue , Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 14:58:43 -0000 On Wed, Mar 04, 2015 at 06:53:49AM -0800, Andy Bierman wrote: > On Wed, Mar 4, 2015 at 6:13 AM, Ladislav Lhotka wrote: > > > >> On 04 Mar 2015, at 14:34, Martin Bjorklund wrote: > >> > >> Andy Bierman wrote: > >>> On Thu, Feb 26, 2015 at 9:04 AM, Martin Bjorklund wrote: > >>>> "Ersue, Mehmet (NSN - DE/Munich)" wrote: > >>>>> Dear NETCONF WG, > >>>>> we hereby issue a WG Last Call for 3 weeks for the drafts below: > >>>>> > >>>>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 > >>>>> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 > >>>> > >>>> I have mentioned this before, but I don't think it has been resolved > >>>> yet - the usage of anyxml in the patch document needs more work. > >>>> Together with the latest json draft, the anyxml usage is > >>>> underspecified, and will not be interoperable. > >>>> > >>> > >>> > >>> I think the draft is clear how to encode YANG data nodes > >>> within the "value" anyxml node. > >> > >> I don't understand this. > >> > >> Assume we have: > >> > >> container servers { > >> list server { > >> key name; > >> leaf name { type string; } > >> container address { > >> leaf ip { type inet:ip-address; } > >> leaf port { type inet:port-number; } > >> } > >> } > >> } > >> > >> Now I want to set address/port and enabled in a given server > >> instance. > >> > >> In XML I would do: > >> > >> PATCH /restconf/data/my-module:servers/server=srv1 > >> > >> > >> > >> 1 > >> merge > >> . > >> > >> > >> srv1 > >>
> >> 42 > >>
> >> true > >> > >> > >> > >> > >> > >> Now, I want to do this in JSON. > >> > >> First of all I just noticed that YANG PATCH is missing a reference to > >> draft-ietf-netmod-yang-json. > >> > >> Anyway, there is no special text in YANG PATCH about json encoding, so > >> I assume that the rules defined in draft-ietf-netmod-yang-json > >> applies. > > > > IMO this is not automatic and the description of “anyxml value” should explicitly state that the value must be an instance of a container whose schema is determined by the sibling “target” leaf, and that its encoding in XML and JSON must follow the rules of RFC 6020 and draft-ietf-netmod-yang-json, respectively. > > > > It does say that. > I don't really see any consensus forming wrt/ anyxml or anydata. > Perhaps it is time to declare the issue dead. > If a vendor really wants to store raw XML in their config, > they will figure out a way to do that. > No, there is nothing about JSON I can find. /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 Mar 4 07:20:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55E61A6F34 for ; Wed, 4 Mar 2015 07:20:16 -0800 (PST) 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 3P8_LBWIwUsV for ; Wed, 4 Mar 2015 07:20:12 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC621A6F28 for ; Wed, 4 Mar 2015 07:20:11 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.99.14; Wed, 4 Mar 2015 15:13:31 +0000 Message-ID: <032f01d0568d$7a8728c0$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (Nokia - DE/Munich)" , References: Date: Wed, 4 Mar 2015 15:11:17 +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: [81.151.167.59] X-ClientProxiedBy: DB4PR02CA0032.eurprd02.prod.outlook.com (10.242.174.160) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Forefront-PRVS: 0505147DDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(377454003)(13464003)(50466002)(107886001)(122386002)(15975445007)(81686999)(81816999)(77096005)(46102003)(92566002)(40100003)(33646002)(84392001)(44736004)(50226001)(23756003)(61296003)(19580395003)(42186005)(230783001)(14496001)(116806002)(50986999)(76176999)(44716002)(47776003)(66066001)(62236002)(1456003)(19580405001)(1556002)(87976001)(77156002)(62966003)(86362001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2015 15:13:31.7770 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed 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, 04 Mar 2015 15:20:16 -0000 I have read call-home and find it problematic. I am reminded of Alan Luchuk's comments of almost a year ago when it was still reverse-ssh. I find it unclear, hard to understand, confusing in places without knowing things that are unsaid. The improvements made to the text then have mostly disappeared with a change of scope. I think that the scope of the document - NETCONF, RESTCONF, TLS, SSH, certificates, public keys - is right but that does not mean it is always possible to cover all the cases in a single sentence and that more fleshing out is needed. Thus repeatedly the use of NETCONF/RESTCONF allows combinations that I suspect are invalid, such as RESTCONF over SSH or NETCONF using the port assigned to RESTCONF. What then is the scope? For most of the I-D, I infer NETCONF with SSH and TLS, RESTCONF (which I am not competent to review) with TLS, TLS with certificates, SSH with public keys. But then I see at the end of s.3 " However, to use X.509 certificates with SSH, ..." so it looks like SSH with certificates is there too. How about TLS with something else? We did debate this at length for another I-D and slowly converged on X.509 certificates only. Is this true here? If so, it needs saying up front IMO. SSH makes a rather sudden appearance in the Introduction (lack of scope again); I think it should be in the Abstract e.g. NEW (In both Abstract and Introduction) This document presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The RESTCONFconnection is over TLS, the NETCONF over TLS or SSH. " [Note that the current use of respectively is wrong IMO; you have 'A and B', but no 'C and D' to be respective to.] 1 "preserve the client/server roles of underlying transport, as when compared" Well no, the whole point is to reverse the transport. Of course, if TCP is not a transport, well, I part company there. It is argued just what TLS is, transport or not, with TCPM and TLS WGs apt to part company. SO " preserve the client/server roles of underlying secure connection, as when compared" I would add at the end of this paragraph "References to SSH in this document are only applicable to NETCONF" (as well as fleshing this out later). 1.3 A year ago, we had " these techniques MUST only be used for NETCONF Call Home" which Benoit said was impossible. Now we have 'SHOULD' but it still seems impossible to me. 'SHOULD' should be accompanied by indications of when it does not apply and I don't really see this. I think we are still leaving the barn door wide open. I would say something like "These techniques are only defined for ..." since I think any RFC2119 language unenforceable. 1.4 "Security implications related to this change are discussed in Security Considerations (Section 4)." Not really, section 4 refers you to section 3. 2.1 "The NETCONF/RESTCONF server initiates a TCP connection request (SYN) to the NETCONF/RESTCONF client. " A strict reading of this allows a NETCONF server to initiate connection of a RESTCONF client! I think you need 'NETCONF server or RESTCONF server' twice with a ',respectively' tacked on "depending on how it is configured." Again, this allows you to configure a RESTCONF server to use port X. It is not configuration, it is a question of which port you have just called that determines what the server fires up. "Using this TCP connection, the NETCONF/RESTCONF server MUST immediately start using either the SSH-server [RFC4253] or the TLS-server [RFC5246] protocol. If the connection was made to PORT-X (or a user chosen non-default port), then the SSH-server protocol is initiated; if the connection was made to either port PORT-Y or PORT-Z (or a user-chosen non-deault port), then the TLS-server protocol is initiated." " Once the SSH or TLS connection is established, the NETCONF/ RESTCONF server MUST immediately start using either the NETCONF-server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] protocol, depending on how it is configured. " Same story, it is the port not the configuration that matters. Perhaps " Once the SSH or TLS connection is established, the NETCONF/ RESTCONF server MUST immediately start using either the NETCONF-server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] protocol, depending on the port to which the connection has been established." 3 same comments about "depending on how it is configured" twice 3.2 I need to go through this many more times but meanwhile "information persisted previously." I don't understand. "This IP address could be used as an identifier directly, but doing " so should come with a health warning; source IP addresses are forgeable in the Internet. "Yet another option for identifying a NETCONF/RESTCONF server is for its host key or certificate to encode its identity directly (e.g., within the "Subject" field). " What 'Subject field' is that? I am not familiar with one. 4 "An attacker could DoS the " I just read an AD review (in IESG review I think ) that said 'Dos is not a verb'! Tom Petch ----- Original Message ----- From: "Ersue, Mehmet (Nokia - DE/Munich)" To: Sent: Tuesday, March 03, 2015 10:16 PM Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed Dear NETCONF WG, we hereby issue a WG Last Call for 2 weeks for the drafts below: https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 Please review and send your comments to the NETCONF WG mailing list by March 17, 2015 EOB PT. Call Home and Server Model drafts are planned to publish as standard track documents. Please state explicitly that you have read/reviewed and whether you support the publication of the drafts. Please indicate also if you plan to implement or have already implementation experience with the these drafts. Thank you, Mehmet and Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Thursday, February 05, 2015 5:30 PM To: netconf@ietf.org Subject: [Netconf] call-home-04 and server-model-06 available - All Open issues closed All, all call-home issues have been solved and there are 3 issues for server-model draft in REVIEW state. See https://github.com/netconf-wg/call-home/issues?q=is%3Aissue+is%3Aclosed and https://github.com/netconf-wg/server-model/issues. Please check the provided solutions in the updated drafts and comment before we go to WGLC after the end of Restconf LC. https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 Regards, Mehmet ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Mar 5 08:15:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB2D1A1B0C for ; Thu, 5 Mar 2015 08:15:29 -0800 (PST) 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 kGyovoQceRp3 for ; Thu, 5 Mar 2015 08:15:26 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11C81A1B47 for ; Thu, 5 Mar 2015 08:09:49 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.99.14; Thu, 5 Mar 2015 16:09:29 +0000 Message-ID: <00a901d0575e$754f0680$4001a8c0@gateway.2wire.net> From: t.petch To: "Ersue, Mehmet (Nokia - DE/Munich)" , References: <032f01d0568d$7a8728c0$4001a8c0@gateway.2wire.net> Date: Thu, 5 Mar 2015 16:06:26 +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: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0008.eurprd05.prod.outlook.com (25.160.40.18) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056; X-Forefront-Antispam-Report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(51444003)(377454003)(13464003)(51704005)(122386002)(50466002)(44736004)(33646002)(77096005)(15975445007)(107886001)(92566002)(40100003)(84392001)(46102003)(230783001)(23756003)(19580395003)(42186005)(50226001)(81816999)(61296003)(116806002)(50986999)(76176999)(47776003)(66066001)(62236002)(1456003)(19580405001)(81686999)(44716002)(77156002)(14496001)(1556002)(87976001)(86362001)(62966003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; X-Forefront-PRVS: 05066DEDBB Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2015 16:09:29.3512 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed 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, 05 Mar 2015 16:15:29 -0000 A separate comment to those I made earlier. What is the right term to refer to Netconf connections that are NOT using call home? This I-D sometimes talks of 'standard' (which makes call home nonstandard), sometimes of 'normal circumstances' (which makes call home abnormal). These seem judgmental to me and I would like a less judgmental term. 'Orthodox' (which makes call home heterodox), 'Classic' (which makes call home modern) or ... but I think that it needs changing. But then server-model has 'listen' or 'listening for connections', fairly consistently, along with 'call home' I think that this I-D should be consistent and perhaps consistent with server-model. Tom Petch > ----- Original Message ----- > From: "Ersue, Mehmet (Nokia - DE/Munich)" > To: > Sent: Tuesday, March 03, 2015 10:16 PM > > Dear NETCONF WG, > > we hereby issue a WG Last Call for 2 weeks for the drafts below: > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > Please review and send your comments to the NETCONF WG mailing list by > March 17, 2015 EOB PT. > > Call Home and Server Model drafts are planned to publish as standard > track documents. > > Please state explicitly that you have read/reviewed and whether you > support the publication of the drafts. > Please indicate also if you plan to implement or have already > implementation experience with the these drafts. > > Thank you, > Mehmet and Mahesh > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, > Mehmet (NSN - DE/Munich) > Sent: Thursday, February 05, 2015 5:30 PM > To: netconf@ietf.org > Subject: [Netconf] call-home-04 and server-model-06 available - All Open > issues closed > > All, > > all call-home issues have been solved and there are 3 issues for > server-model draft in REVIEW state. > See > https://github.com/netconf-wg/call-home/issues?q=is%3Aissue+is%3Aclosed > and > https://github.com/netconf-wg/server-model/issues. > > Please check the provided solutions in the updated drafts and comment > before we go to WGLC after the end of Restconf LC. > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > Regards, > Mehmet > > > > > ---------------------------------------------------------------------- -- > -------- > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Mar 5 08:27:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7C51A03F9 for ; Thu, 5 Mar 2015 08:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 ADsMbGsHWA2g for ; Thu, 5 Mar 2015 08:26:56 -0800 (PST) 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 83A471A0146 for ; Thu, 5 Mar 2015 08:17:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1AC94F87; Thu, 5 Mar 2015 17:17:49 +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 60SE-3vMe07J; Thu, 5 Mar 2015 17:17:27 +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; Thu, 5 Mar 2015 17:17:48 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 036FE20039; Thu, 5 Mar 2015 17:17:48 +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 P1Vu7eQ8tpag; Thu, 5 Mar 2015 17:17:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D409D20036; Thu, 5 Mar 2015 17:17:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ECD26325E033; Thu, 5 Mar 2015 17:17:44 +0100 (CET) Date: Thu, 5 Mar 2015 17:17:44 +0100 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20150305161744.GB71013@elstar.local> Mail-Followup-To: "t. petch" , "Ersue, Mehmet (Nokia - DE/Munich)" , netconf@ietf.org References: <032f01d0568d$7a8728c0$4001a8c0@gateway.2wire.net> <00a901d0575e$754f0680$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a901d0575e$754f0680$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:27:00 -0000 While I like some of the words, it might be that 'server initiated connections' and 'client initiated connections' may be easiest to grasp. /js On Thu, Mar 05, 2015 at 04:06:26PM +0000, t. petch wrote: > A separate comment to those I made earlier. > > What is the right term to refer to Netconf connections that are NOT > using call home? > > This I-D sometimes talks of 'standard' (which makes call home > nonstandard), sometimes of 'normal circumstances' (which makes call home > abnormal). > > These seem judgmental to me and I would like a less judgmental term. > 'Orthodox' (which makes call home heterodox), 'Classic' (which makes > call home modern) or ... but I think that it needs changing. > > But then server-model has 'listen' or 'listening for connections', > fairly consistently, along with 'call home' > > I think that this I-D should be consistent and perhaps consistent with > server-model. > > Tom Petch > > > ----- Original Message ----- > > From: "Ersue, Mehmet (Nokia - DE/Munich)" > > To: > > Sent: Tuesday, March 03, 2015 10:16 PM > > > > Dear NETCONF WG, > > > > we hereby issue a WG Last Call for 2 weeks for the drafts below: > > > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > > > Please review and send your comments to the NETCONF WG mailing list by > > March 17, 2015 EOB PT. > > > > Call Home and Server Model drafts are planned to publish as standard > > track documents. > > > > Please state explicitly that you have read/reviewed and whether you > > support the publication of the drafts. > > Please indicate also if you plan to implement or have already > > implementation experience with the these drafts. > > > > Thank you, > > Mehmet and Mahesh > > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Ersue, > > Mehmet (NSN - DE/Munich) > > Sent: Thursday, February 05, 2015 5:30 PM > > To: netconf@ietf.org > > Subject: [Netconf] call-home-04 and server-model-06 available - All > Open > > issues closed > > > > All, > > > > all call-home issues have been solved and there are 3 issues for > > server-model draft in REVIEW state. > > See > > > https://github.com/netconf-wg/call-home/issues?q=is%3Aissue+is%3Aclosed > > and > > https://github.com/netconf-wg/server-model/issues. > > > > Please check the provided solutions in the updated drafts and comment > > before we go to WGLC after the end of Restconf LC. > > > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > > > Regards, > > Mehmet > > > > > > > > > > ---------------------------------------------------------------------- > -- > > -------- > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Mar 5 11:17:15 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25151A872A for ; Thu, 5 Mar 2015 11:17:13 -0800 (PST) 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 R7tpmRoCGUyM for ; Thu, 5 Mar 2015 11:17:12 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93C81A8728 for ; Thu, 5 Mar 2015 11:17:11 -0800 (PST) Received: by qgaj5 with SMTP id j5so7135540qga.12 for ; Thu, 05 Mar 2015 11:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=3B6upPm8Pi1p5BEU8FdhVri3MLKzy+YVf/E7sfKbO+w=; b=Xb9uCtEGTJDbOrA5uOMbChHQR3VF4cZb+bRjidhbCZYEEFqcve1eAkoXeWbcgFfqmL WGxU8BTh2vUpEoQiuJpgbj9h7ppS39UePf/aE+5D/uGVAyeSVUYmn9Yu4ELls1wQTrfa 76tsgz56XP3sPzcrTomJSfFrFdMCnnKAHkKJcn30Q3p69D6ZOZ8L0hCMsrP5+xOHpe/I mzuASneDA7FfoivZEKViTkrNFs0L7rCYO9wEOw+gzGBunLbb7itoGi3177m4sI/uuJN/ M+ZChzD0RvYODLxsW1yn8jdx9hQaPrCYz0QGaCitSJoyCZZQQdgFjSSVUjWdjznVMhtS QxUg== X-Received: by 10.55.42.17 with SMTP id q17mr7535521qkh.61.1425583031061; Thu, 05 Mar 2015 11:17:11 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id x143sm3176743qkx.28.2015.03.05.11.17.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 11:17:10 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_8573B952-B0BD-4436-879D-101139C8CE3D" Date: Thu, 5 Mar 2015 11:17:08 -0800 References: <01fd01d05768$48479350$d8d6b9f0$@gmail.com> To: netconf Message-Id: <55BD04C0-8B49-4D79-8DDC-0868BF5DAF8F@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Netconf] IETF92 NETCONF WG 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: Thu, 05 Mar 2015 19:17:14 -0000 --Apple-Mail=_8573B952-B0BD-4436-879D-101139C8CE3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Folks, =20 IETF92 NETCONF WG session is on Tuesday, March 24, 2015. =20 Time: 1300-1500 CDT Place: Gold =20 Session agenda has also been posted. =20 https://datatracker.ietf.org/meeting/92/agenda/netconf/ = =20 If you are a owner of unpublished or a revised documents, publication = cut-off is March 9th which is fast approaching. =20 If you are a owner of one of the agenda items, please send Mehmet and I = your presentation material no later than March 20th. Of course, sooner = is better. =20 Thanks! =20 Mahesh and Mehmet --Apple-Mail=_8573B952-B0BD-4436-879D-101139C8CE3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Folks,
 
IETF92 = NETCONF WG session is on Tuesday, March 24, 2015.
 
Time:  = 1300-1500 CDT
Place: Gold
 
Session agenda has also been posted.
 
https://datatracker.ietf.org/meeting/92/agenda/netconf/
 
If you are a = owner of unpublished or a revised documents, publication cut-off is = March 9th which is fast = approaching.
 
If you are a owner of one of the = agenda items, please send Mehmet and I your presentation material no = later than March 20th. Of course, sooner is better.
 
Thanks!
 
Mahesh and = Mehmet




= --Apple-Mail=_8573B952-B0BD-4436-879D-101139C8CE3D-- From nobody Fri Mar 6 02:11:26 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEBA1A1A15 for ; Fri, 6 Mar 2015 02:11:24 -0800 (PST) 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 mQ2ObIvJHUZn for ; Fri, 6 Mar 2015 02:11:23 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895A31A03E3 for ; Fri, 6 Mar 2015 02:11:22 -0800 (PST) Received: from pc6 (86.185.85.149) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.99.14; Fri, 6 Mar 2015 10:06:26 +0000 Message-ID: <023701d057f4$e75098c0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <032f01d0568d$7a8728c0$4001a8c0@gateway.2wire.net> <00a901d0575e$754f0680$4001a8c0@gateway.2wire.net> <20150305161744.GB71013@elstar.local> Date: Fri, 6 Mar 2015 10:04:08 +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.185.85.149] X-ClientProxiedBy: VI1PR04CA0042.eurprd04.prod.outlook.com (25.163.3.52) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Forefront-Antispam-Report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(51444003)(24454002)(44716002)(86362001)(230783001)(66066001)(62236002)(122386002)(40100003)(76176999)(50466002)(50226001)(81816999)(23756003)(81686999)(62966003)(14496001)(50986999)(61296003)(44736004)(1556002)(77096005)(19580395003)(19580405001)(15975445007)(47776003)(110136001)(33646002)(77156002)(87976001)(46102003)(92566002)(116806002)(42186005)(1456003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:AMXPR07MB053; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB053; X-Forefront-PRVS: 05079D8470 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2015 10:06:26.4708 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB053 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed 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, 06 Mar 2015 10:11:25 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: "Ersue, Mehmet (Nokia - DE/Munich)" ; Sent: Thursday, March 05, 2015 4:17 PM > While I like some of the words, it might be that 'server initiated > connections' and 'client initiated connections' may be easiest to > grasp. Yes, I like that. I am not sure how far you would take it. 'server-model' has many instances of 'call-home' and 'listen' in the YANG modules for feature, grouping and container where a shorter identifier seems right. But it then goes on to use 'call home' and 'listen' extensively in the 'description' clauses, which seems to follow logically, and also in the textual sections, s.1 and s.2. It seems unnatural to draw a line between the terminology of the textual sections and the YANG modules so 'server-model' then ends up with 'call(-)home' and 'listen(ing)' everywhere (with some tidying up of the actual spelling perhaps) . Logically, then, we end up with 'server initiated connections' and 'client initiated connections' in the call home I-D with an explanation somewhere, probably in both I-Ds, that this maps onto 'call-home' and 'listen'. Mmmmm... I am ok with that even if it is not as tidy as I first envisioned. Tom Petch > /js > > On Thu, Mar 05, 2015 at 04:06:26PM +0000, t. petch wrote: > > A separate comment to those I made earlier. > > > > What is the right term to refer to Netconf connections that are NOT > > using call home? > > > > This I-D sometimes talks of 'standard' (which makes call home > > nonstandard), sometimes of 'normal circumstances' (which makes call home > > abnormal). > > > > These seem judgmental to me and I would like a less judgmental term. > > 'Orthodox' (which makes call home heterodox), 'Classic' (which makes > > call home modern) or ... but I think that it needs changing. > > > > But then server-model has 'listen' or 'listening for connections', > > fairly consistently, along with 'call home' > > > > I think that this I-D should be consistent and perhaps consistent with > > server-model. > > > > Tom Petch > > > > > ----- Original Message ----- > > > From: "Ersue, Mehmet (Nokia - DE/Munich)" > > > To: > > > Sent: Tuesday, March 03, 2015 10:16 PM > > > > > > Dear NETCONF WG, > > > > > > we hereby issue a WG Last Call for 2 weeks for the drafts below: > > > > > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > > > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > > > > > Please review and send your comments to the NETCONF WG mailing list by > > > March 17, 2015 EOB PT. > > > > > > Call Home and Server Model drafts are planned to publish as standard > > > track documents. > > > > > > Please state explicitly that you have read/reviewed and whether you > > > support the publication of the drafts. > > > Please indicate also if you plan to implement or have already > > > implementation experience with the these drafts. > > > > > > Thank you, > > > Mehmet and Mahesh > > > > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext > > Ersue, > > > Mehmet (NSN - DE/Munich) > > > Sent: Thursday, February 05, 2015 5:30 PM > > > To: netconf@ietf.org > > > Subject: [Netconf] call-home-04 and server-model-06 available - All > > Open > > > issues closed > > > > > > All, > > > > > > all call-home issues have been solved and there are 3 issues for > > > server-model draft in REVIEW state. > > > See > > > > > https://github.com/netconf-wg/call-home/issues?q=is%3Aissue+is%3Aclosed > > > and > > > https://github.com/netconf-wg/server-model/issues. > > > > > > Please check the provided solutions in the updated drafts and comment > > > before we go to WGLC after the end of Restconf LC. > > > > > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > > > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > > > > > Regards, > > > Mehmet > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > -------- > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Mar 6 09:02:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B481A0092 for ; Fri, 6 Mar 2015 09:02:37 -0800 (PST) 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 JoS0vOyar5w8 for ; Fri, 6 Mar 2015 09:02:34 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340301A0178 for ; Fri, 6 Mar 2015 09:02:33 -0800 (PST) Received: from pc6 (86.185.85.149) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.99.14; Fri, 6 Mar 2015 17:02:18 +0000 Message-ID: <043e01d0582e$ff915980$4001a8c0@gateway.2wire.net> From: t.petch To: , Date: Fri, 6 Mar 2015 16:59:58 +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.185.85.149] X-ClientProxiedBy: VI1PR04CA0002.eurprd04.prod.outlook.com (25.163.3.12) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Forefront-Antispam-Report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(51704005)(23756003)(77096005)(87976001)(33646002)(50466002)(1456003)(15975445007)(61296003)(42186005)(81686999)(50986999)(14496001)(46102003)(81816999)(50226001)(107886001)(92566002)(62236002)(122386002)(1556002)(47776003)(44736004)(19580405001)(86362001)(40100003)(19580395003)(84392001)(62966003)(66066001)(44716002)(116806002)(230783001)(77156002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Forefront-PRVS: 05079D8470 Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2015 17:02:18.2941 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Subject: [Netconf] Fw: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed 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, 06 Mar 2015 17:02:38 -0000 I have read, and re-read and re-read ... section 3.2 of call-home and I am struggling. I am reminded of rfc5539bis where we started out with something similar and ended up with " The NETCONF client MUST check the identity of the server according to Section 6 of [RFC6125]." which I think was a great idea. We cannot go quite that far with the call-home I-D but think we should be heading in that direction. Surely all we need to say, in essence, is that because the server has initiated the connection then we have no reference identity and so RFC6125 cannot apply. Therefore the client must be preconfigured with whatever it will trust from the server, be that a certificate or a host key. And it should be the certificate of the server; a CA certificate on its own is not enough since, as we have said already, we have no reference identity so knowing that the end user certificate chains back to a valid CA is not enough (in general). And yes, preconfiguring information is a pain but if you want security, you have to do it. So along those lines I offer a new 3.2 ==================================================== 3.2. Server Identification and Authentication When a NETCONF/RESTCONF client initiates the connection to the NETCONF/RESTCONF server, the client has prior knowledge of the identity of the NETCONF/RESTCONF server it is connecting to. When using TLS or SSH with certificates, the NETCONF client can then check the identity of the server according to Section 6 of [RFC6125]. Similar considerations apply when using SSH with host keys. When the connection is initiated by the NETCONF/RESTCONF server, the NETCONF/RESTCONF client does not have any prior knowledge of the identity of the NETCONF/RESTCONF server which has initiated the connection. The NETCONF/RESTCONF client must derive the identity of the NETCONF/RESTCONF server from information provided by the network or by the NETCONF/RESTCONF server itself. This section describes strategies a NETCONF/RESTCONF client can then use to identify a NETCONF/RESTCONF server. A NETCONF/RESTCONF client must also authenticate the identity of the server. This is always an issue but especially so when the NETCONF/RESTCONF server initiates the connection since this approach is common for newly deployed NETCONF/RESTCONF servers. The first piece of information that a NETCONF/RESTCONF client learns when the server initiates the connection is the IP address of the NETCONF/RESTCONF server, i.e the source address of the TCP connection. This IP address is an identifier but is only reliable in networks that use known static addresses. This case is infrequent; so it is NOT RECOMMENDED to identify a NETCONF/RESTCONF server by its source IP address. The next piece of information a NETCONF/RESTCONF client learns is provided by the NETCONF/RESTCONF server in the form of a host-key (for SSH) or a certificate (for SSH or TLS). This host-key or certificate, either in its entirety or as a fingerprint, can be used to look up an identifier for the NETCONF/RESTCONF server. Each NETCONF/RESTCONF server is assumed to have a statistically unique public key, even in virtualized environments. This approach also provides authentication in that a secure connection can only be established when the NETCONF/RESTCONF server can demonstrate possession of the matching private key. This approach is common with SSH clients but could be used equally well by TLS clients. It may be the required when the NETCONF/RESTCONF servers have self-signed certificates. [** I do not understand the next OLD paragraph and so am guessing here. Doubtless I will be told where my guesses are wrong] A variation on the previous option can be used when the manufacturer of the NETCONF/RESTCONF servers is a trusted CA and provisions the NETCONF/RESTCONF servers with certificates such as is described by [Std-802.1AR-2009]. After verifying that the certificate is valid [RFC5280], an identifier can be extracted from the certificate, e.g. from the subjectAltName. The NETCONF/RESTCONF client SHOULD still be configured with the CA certificate and a list of expected identifiers of the NETCONF/RESTCONF servers, as supplied by the manufacturer. [Which seems very close to the usual RFC6125 case - what am I missing?] Note that while TLS uses X.509 certificates by default, using X.509 certificates with SSH requires both the NETCONF client and server to support [RFC6187]. ================================================== I would probably cut down on the number of times NETCONF/RESTCONF appears but am not too bothered by it. Which is all the comments I currently have on draft-ietf-netconf-call-home-04. Tom Petch > ----- Original Message ----- > From: "Ersue, Mehmet (Nokia - DE/Munich)" > To: > Sent: Tuesday, March 03, 2015 10:16 PM > Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and > server-model-06 available - All Open issues closed > > > Dear NETCONF WG, > > we hereby issue a WG Last Call for 2 weeks for the drafts below: > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > Please review and send your comments to the NETCONF WG mailing list by > March 17, 2015 EOB PT. > > Call Home and Server Model drafts are planned to publish as standard > track documents. > > Please state explicitly that you have read/reviewed and whether you > support the publication of the drafts. > Please indicate also if you plan to implement or have already > implementation experience with the these drafts. > > Thank you, > Mehmet and Mahesh > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, > Mehmet (NSN - DE/Munich) > Sent: Thursday, February 05, 2015 5:30 PM > To: netconf@ietf.org > Subject: [Netconf] call-home-04 and server-model-06 available - All Open > issues closed > > All, > > all call-home issues have been solved and there are 3 issues for > server-model draft in REVIEW state. > See > https://github.com/netconf-wg/call-home/issues?q=is%3Aissue+is%3Aclosed > and > https://github.com/netconf-wg/server-model/issues. > > Please check the provided solutions in the updated drafts and comment > before we go to WGLC after the end of Restconf LC. > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > Regards, > Mehmet > > --=====2634486923681469604=- > From nobody Fri Mar 6 10:31:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805861A1ABB for ; Fri, 6 Mar 2015 10:31:06 -0800 (PST) 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 W4ZfZcR2cdRk for ; Fri, 6 Mar 2015 10:31:04 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0A51A1AA6 for ; Fri, 6 Mar 2015 10:31:04 -0800 (PST) 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.1.99.14; Fri, 6 Mar 2015 18:31:01 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) with mapi id 15.01.0099.004; Fri, 6 Mar 2015 18:31:01 +0000 From: Kent Watsen To: Joe Clarke , "netconf@ietf.org" Thread-Topic: [Netconf] zerotouch issues and fixes Thread-Index: AQHQT7iOdPe2gMCB50i3hPM2i00zr50JVfMA//+19ICAAe8ygIAEiQaA Date: Fri, 6 Mar 2015 18:31:01 +0000 Message-ID: References: <54F47CDA.9080908@cisco.com> <54F5DE23.9090605@cisco.com> In-Reply-To: <54F5DE23.9090605@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-originating-ip: [66.129.239.10] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(979002)(6009001)(24454002)(76104003)(164054003)(377454003)(51704005)(479174004)(36756003)(54356999)(102836002)(2900100001)(46102003)(2950100001)(66066001)(19580405001)(19580395003)(99286002)(76176999)(62966003)(93886004)(107886001)(83506001)(106116001)(92566002)(77156002)(86362001)(122556002)(87936001)(2656002)(50986999)(40100003)(2501003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 05079D8470 received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <510BA1ABE7A8244390779DFC78C6F559@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2015 18:31:01.1684 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] zerotouch issues and fixes 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, 06 Mar 2015 18:31:06 -0000 OK, it seems that there is some support for this approach. I'd plan to post an updated draft that captures the idea more completely. We can always roll it back if needed... Thanks, Kent On 3/3/15, 11:15 AM, "Joe Clarke" wrote: >On 3/2/15 10:43 AM, Kent Watsen wrote: >> >> >>> I think this approach is reasonable. The interaction with the vendor >>>is >>> minimal (only to claim the device-IDs and get the voucher). >> >> Exactly, this solution optimizes for the vendor - it's very low-touch >>and >> doesn't rely on a realtime lookup service. But "reasonable" sounds >> uncommitted - what we need to know is it's better - what do you think? > >Sorry, didn't mean to sound noncommittal. I like it. I just think the >questions I had raised need to be addressed (i.e., around Owner ID and >verifying expiry on the device's part). > >> >> >>> Though, the >>> time-to-live of the voucher needs to be accounted for by the device. >>>It >>> needs to confirm the voucher is still "alive." >> >> Yes, there is a presumption that the device has an accurate clock. Such >> it is with PKI in general. For instance, CRLs are only useful if >>they're >> relatively fresh (a year-old CRL is not very useful). > >Of course. It's just you didn't mention that in your rough >walk-through. That needs to be part of the process. > >> >> >> >>> Would it make sense to >>> have a per-device TTL in the voucher? >> >> This would be doable. As a voucher is a data file (not a X.509 >> certificate), for which we could define schema for, and thus it could >>take >> any form we deem best. That said, I question if it makes sense for a >> vendor to issue a voucher with varying TTLs. Is the vendor suppose to >> know that some device's ownership is more volatile than others? - or do >> you see this as user-input? > >I see this as user input. The use case I envision is that the owner >might set a certain timeline for other devices to give a safety net to >prevent old devices from bootstrapping. It may not be common, and thus >this could be a MAY. It just offers flexibility. > >> >> >>> I also think there needs to be a way for the NMS to request an owner >>>ID. >>> The reason for this is what happens if I have to replace the NMS. I >>> would need a new private key and a new CSR. While I could get a new >>> voucher with the new owner ID, this would likely be more of a hassle as >>> the vendor will likely associate the devices with one owner ID. >> >> Yes, vendors would have to be able to reissue the NMS certificates. >> Vendors could re-assign the same Owner ID the NMS had before or >>generate a >> new one. If a new Owner ID is generated, then the vendor would also >>need >> to reissue Vouchers for devices that have not yet been claimed (e.g., >>gone >> through the zerotouch process). > >How do we state this in the draft? I think it deserves a callout. The >Owner ID can't simply be a random thing, but needs to tie to the owner >entity (yet still be unique between entities). Can we say that the >owner entity can suggest an Owner ID? > >Joe From nobody Fri Mar 6 10:40:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BED61A1AA6 for ; Fri, 6 Mar 2015 10:40:06 -0800 (PST) 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 GiA42T1H17NW for ; Fri, 6 Mar 2015 10:40:03 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448A91A07BE for ; Fri, 6 Mar 2015 10:40:03 -0800 (PST) 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.1.99.14; Fri, 6 Mar 2015 18:39:47 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) with mapi id 15.01.0099.004; Fri, 6 Mar 2015 18:39:47 +0000 From: Kent Watsen To: t.petch , "netconf@ietf.org" , "mehmet.ersue@nokia.com" Thread-Topic: [Netconf] Fw: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed Thread-Index: AQHQWC9cJOeLbHJQdUCzHoi9ITRHop0PdaKA Date: Fri, 6 Mar 2015 18:39:46 +0000 Message-ID: References: <043e01d0582e$ff915980$4001a8c0@gateway.2wire.net> In-Reply-To: <043e01d0582e$ff915980$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-originating-ip: [66.129.239.10] authentication-results: btconnect.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(43784003)(13464003)(24454002)(51694002)(479174004)(377454003)(51704005)(122556002)(15975445007)(2201001)(66066001)(36756003)(2501003)(46102003)(102836002)(2900100001)(99286002)(2656002)(50986999)(92566002)(86362001)(40100003)(230783001)(77156002)(19580395003)(107886001)(2950100001)(87936001)(83506001)(106116001)(76176999)(54356999)(19580405001)(62966003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001007)(5005006); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 05079D8470 Content-Type: text/plain; charset="us-ascii" Content-ID: <7FCC86EF4310D44A945B2856A455EF73@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2015 18:39:46.9401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [Netconf] Fw: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed 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, 06 Mar 2015 18:40:06 -0000 Hi Tom and Juergen, Thank you for all your comments so far. I will more fully engage in this thread after the draft submission deadline has past. I just wanted to let you know why I haven't replied yet. Thanks again, Kent On 3/6/15, 11:59 AM, "t.petch" wrote: > > I have read, and re-read and re-read ... section 3.2 of call-home and I > am struggling. I am reminded of rfc5539bis where we started out with > something similar and ended up with > " The NETCONF client MUST check the identity of the server according >to > Section 6 of [RFC6125]." > which I think was a great idea. > > We cannot go quite that far with the call-home I-D but think we should > be > heading in that direction. > > Surely all we need to say, in essence, is that because the server has > initiated the connection then we have no reference identity and so > RFC6125 cannot apply. Therefore the client must be preconfigured with > whatever it will trust from the server, be that a certificate or a host > key. And it should be the certificate of the server; a CA certificate > on > its own is not enough since, as we have said already, we have no > reference identity so knowing that the end user certificate chains back > to a valid CA is not enough (in general). > > And yes, preconfiguring information is a pain but if you want security, > you have to do it. > > So along those lines I offer a new 3.2 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 3.2. Server Identification and Authentication > > When a NETCONF/RESTCONF client initiates the > connection to the NETCONF/RESTCONF server, the client has prior > knowledge of the identity of the NETCONF/RESTCONF server it is > connecting to. When using TLS or SSH with certificates, > the NETCONF client can then check the identity of the server > according to > Section 6 of [RFC6125]. > Similar considerations apply when using SSH with host keys. > > When the connection is initiated by the NETCONF/RESTCONF server, the > NETCONF/RESTCONF client does not have any prior knowledge of the > identity of the NETCONF/RESTCONF server which has initiated the > connection. The NETCONF/RESTCONF > client must derive the identity of the NETCONF/RESTCONF server from > information provided by the network or by the NETCONF/RESTCONF server > itself. This section describes strategies a NETCONF/RESTCONF client > can then use to identify a NETCONF/RESTCONF server. > > A NETCONF/RESTCONF client must also authenticate the identity of the > server. This is always an issue but especially so when the > NETCONF/RESTCONF server initiates the connection since this approach is > common for newly deployed NETCONF/RESTCONF servers. > > The first piece of information that a NETCONF/RESTCONF client learns > when the server initiates the connection is the IP address of the > NETCONF/RESTCONF server, i.e the source address of the TCP connection. > This IP address is an identifier but is only reliable in networks that > use known static addresses. This case is infrequent; so it is NOT > RECOMMENDED to identify a NETCONF/RESTCONF server by its source IP > address. > > The next piece of information a NETCONF/RESTCONF client learns is > provided by the NETCONF/RESTCONF server in the form of a host-key (for > SSH) or a certificate (for SSH or TLS). This host-key or certificate, > either in its > entirety or as a fingerprint, can be used to look up an identifier for > the NETCONF/RESTCONF server. Each NETCONF/RESTCONF > server is assumed to have a statistically unique public key, even in > virtualized environments. This approach also provides authentication >in > that a secure connection can only be established when the > NETCONF/RESTCONF server can demonstrate possession of > the matching private key. This approach is common with SSH clients but > could be used equally well by TLS clients. It may be the required when > the NETCONF/RESTCONF servers have self-signed certificates. > > [** I do not understand the next OLD paragraph and so am guessing here. > Doubtless I will be told where my guesses are wrong] > > A variation on the previous option can be used when the manufacturer of > the NETCONF/RESTCONF servers is a trusted CA and provisions the > NETCONF/RESTCONF servers with certificates such as is described by > [Std-802.1AR-2009]. After verifying that the certificate is valid > [RFC5280], an identifier can be extracted from the certificate, e.g. > from the subjectAltName. The NETCONF/RESTCONF client SHOULD still be > configured with the CA certificate and a list of expected identifiers >of > the NETCONF/RESTCONF servers, as supplied by the manufacturer. > > [Which seems very close to the usual RFC6125 case - what am I missing?] > > Note that while TLS uses X.509 certificates by default, using X.509 > certificates with SSH requires both the NETCONF client and server to > support [RFC6187]. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > I would probably cut down on the number of times NETCONF/RESTCONF > appears but am not too bothered by it. > > Which is all the comments I currently have on > draft-ietf-netconf-call-home-04. > > Tom Petch > >> ----- Original Message ----- >> From: "Ersue, Mehmet (Nokia - DE/Munich)" >> To: >> Sent: Tuesday, March 03, 2015 10:16 PM >> Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 >and >> draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and >> server-model-06 available - All Open issues closed >> >> >> Dear NETCONF WG, >> >> we hereby issue a WG Last Call for 2 weeks for the drafts below: >> >> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 >> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 >> >> Please review and send your comments to the NETCONF WG mailing list by >> March 17, 2015 EOB PT. >> >> Call Home and Server Model drafts are planned to publish as standard >> track documents. >> >> Please state explicitly that you have read/reviewed and whether you >> support the publication of the drafts. >> Please indicate also if you plan to implement or have already >> implementation experience with the these drafts. >> >> Thank you, >> Mehmet and Mahesh >> >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext >Ersue, >> Mehmet (NSN - DE/Munich) >> Sent: Thursday, February 05, 2015 5:30 PM >> To: netconf@ietf.org >> Subject: [Netconf] call-home-04 and server-model-06 available - All >Open >> issues closed >> >> All, >> >> all call-home issues have been solved and there are 3 issues for >> server-model draft in REVIEW state. >> See >> >https://github.com/netconf-wg/call-home/issues?q=3Dis%3Aissue+is%3Aclosed >> and >> https://github.com/netconf-wg/server-model/issues. >> >> Please check the provided solutions in the updated drafts and comment >> before we go to WGLC after the end of Restconf LC. >> >> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 >> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 >> >> Regards, >> Mehmet >> >> --=3D=3D=3D=3D=3D2634486923681469604=3D- >> > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Mar 8 13:02:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260C81A012D; Sun, 8 Mar 2015 13:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 GAoeJ7hBV0hR; Sun, 8 Mar 2015 13:02:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3E31A1A00FA; Sun, 8 Mar 2015 13:02:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F1959C1B4; Sun, 8 Mar 2015 16:02:40 -0400 (EDT) Date: Sun, 8 Mar 2015 16:02:40 -0400 From: Jeffrey Haas To: i2rs@ietf.org, netmod@ietf.org, netconf@ietf.org Message-ID: <20150308200240.GA14435@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Netconf] Update to draft-haas-i2rs-netmod-netconf-requirements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 20:02:42 -0000 I've updated my personal tracking draft for I2RS requirements upon NETMOD and NETCONF. The primary changes are: - To correct the NETCONF over SSH case which is believed to be complete - I had failed to read that RFC's security considerations section fully. - I've removed the subscription section and pointed to the separate draft, draft-ietf-i2rs-pub-sub-requirements. The primary sticking point remains what to do about the ephemeral state. At IETF 91, we had volunteers willing to document what their ephemeral implementations actually did rather than trying to invent our own. However, these individuals appear to have been consistently busy during that time frame. I'd like to use this email to prod them again to lend their efforts on documenting their ephemeral implementations. -- Jeff ----- Forwarded message from IETF Secretariat ----- Date: Sun, 08 Mar 2015 12:43:40 -0700 From: IETF Secretariat To: jhaas@pfrc.org Subject: Personal ID list of jhaas@pfrc.org notification: Changes on draft-haas-i2rs-netmod-netconf-requirements Hello, This is a notification from the Personal ID list of jhaas@pfrc.org. Document: draft-haas-i2rs-netmod-netconf-requirements, https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements Change: New version available: *draft-haas-i2rs-netmod-netconf-requirements-01.txt* Best regards, The datatracker draft tracking service (for the IETF Secretariat) ----- End forwarded message ----- From nobody Sun Mar 8 13:36:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B221A0105 for ; Sun, 8 Mar 2015 13:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, 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 VknclDADucni for ; Sun, 8 Mar 2015 13:36:05 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8041A011E for ; Sun, 8 Mar 2015 13:35:52 -0700 (PDT) Received: by labgf13 with SMTP id gf13so42550423lab.5 for ; Sun, 08 Mar 2015 13:35:51 -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=Xyqa5HSJMY0IxxCWX391L6CWwh4OMioiC+7oNNYKgK8=; b=K7XBHL2y10ozWxtaIqKL/Anpvq2DuCZPZiryNIoVkbh6oJWo47+JlB0vHlaVoqgfaF syEOZnaGd5J6ixA/2tEGgRHZv1XWFqab6vjUn6C7WjxQrzsPRjQthHZE/8Ic9AoKhNCv J7g0MBO2v90XCZXLUXLCQGXksLgrjF8a/7rzS8OLYzZlZB93otdWThSdd6fQ56rOe9PV H3SjUYpRurVFGviMzFnYLlLHHJWk+hin3NU6CCJmtfgR75Ah6lbrUbHvLMc7PGtZeuAP o4FrG+GoTNdzwSKiA2JoPyM+pNdaLObWcyypNuOJXed0JU6T5lQubmznVnWH+kZOTr0v 7LqA== X-Gm-Message-State: ALoCoQmHXlwBx3Csr6MO79iV7w7fbqPtHvBwwAF3V9kIgkiCotFnpDDw1UoCFN6P1/nnstS89fod MIME-Version: 1.0 X-Received: by 10.152.207.37 with SMTP id lt5mr22669571lac.38.1425846950919; Sun, 08 Mar 2015 13:35:50 -0700 (PDT) Received: by 10.112.144.36 with HTTP; Sun, 8 Mar 2015 13:35:50 -0700 (PDT) In-Reply-To: <20150304.143431.863393506364661618.mbj@tail-f.com> References: <20150226.180400.1762013018376155853.mbj@tail-f.com> <20150304.143431.863393506364661618.mbj@tail-f.com> Date: Sun, 8 Mar 2015 13:35:50 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Ersue, Mehmet \(NSN - DE/Munich\)" , Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 08 Mar 2015 20:36:07 -0000 On Wed, Mar 4, 2015 at 5:34 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Thu, Feb 26, 2015 at 9:04 AM, Martin Bjorklund wrote: >> > "Ersue, Mehmet (NSN - DE/Munich)" wrote: >> >> Dear NETCONF WG, >> >> we hereby issue a WG Last Call for 3 weeks for the drafts below: >> >> >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 >> >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 >> > >> > I have mentioned this before, but I don't think it has been resolved >> > yet - the usage of anyxml in the patch document needs more work. >> > Together with the latest json draft, the anyxml usage is >> > underspecified, and will not be interoperable. >> > >> >> >> I think the draft is clear how to encode YANG data nodes >> within the "value" anyxml node. > > I don't understand this. > > Assume we have: > > container servers { > list server { > key name; > leaf name { type string; } > container address { > leaf ip { type inet:ip-address; } > leaf port { type inet:port-number; } > } > } > } > > Now I want to set address/port and enabled in a given server > instance. > > In XML I would do: > > PATCH /restconf/data/my-module:servers/server=srv1 > > > > 1 > merge > . > > > srv1 >
> 42 >
> true > > > > > > Now, I want to do this in JSON. > > First of all I just noticed that YANG PATCH is missing a reference to > draft-ietf-netmod-yang-json. > > Anyway, there is no special text in YANG PATCH about json encoding, so > I assume that the rules defined in draft-ietf-netmod-yang-json > applies. > > "value" is of type anyxml, so I look at draft-ietf-netmod-yang-json to > see what it says about "anyxml": > > An anyxml instance is encoded as a name/value pair. The value can > be of any valid JSON type, i.e. an object, array, number, string or > one of the literals "true", "false" and "null". > > So maybe I do: > > "value": [ "server": { "name": "srv1", > "address": { "port": 42 } > "enabled": "true" > } ] > I tried an online XML to JSON converter: { "yang-patch": { "-xmlns": "urn:ietf:params:xml:ns:yang:ietf-yang-patch", "edit": { "edit-id": "1", "operation": "merge", "target": ".", "value": { "server": { "-xmlns": "http://example.com/my-module", "name": "srv1", "address": { "port": "42" }, "enabled": "true" } } } } } Whether object or array-of-1 is used is not that interesting. A parser should handle both. > This seems to be valid according to draft-ietf-netmod-yang-json. Will > all servers understand it? > > >> The problem is if the >> data node pointed at by "target" (or its descendants) >> is an anyxml node. >> >> IMO Phil's string leaf encoding of the web-banner applies to >> XML as well as JSON when the content is any XML. > > If the leaf is of type "string", and contains a web-banner, there is > no problem. > It needs to be a string to contain mixed XML on most (if not all) implementations in the wild. >> The anyxml node is supposed to be a terminal >> (i.e., it can only be edited or retrieved as a whole). > > Yes. > >> It cannot be a terminal and also (sometimes) have child nodes. >> >> This is the difference between anyxml and anydata. >> >> The "anyxml" node is any XML. >> It is a terminal. It never has any child nodes. >> Any nested XML elements are just part of the terminal node, >> not child data nodes. >> >> The "anydata" node is an arbitrary YANG data subtree. > > No, I think that "anydata" should also be treated as a terminal node. > So we still need use-specific description-stmts to completely define the intent and constraints when applying a schema-specific object template? (NETCONF , , , etc.) It seems like we are ignoring the real use-cases and focusing on converting mixed mode XML to JSON. IMO, not very important, but just make sure we do not ruin the solution for the 98% use-cases. > > /martin Andy From nobody Sun Mar 8 14:41:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277DE1A0173; Sun, 8 Mar 2015 14:41:40 -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 TqtR4J3Gcx7T; Sun, 8 Mar 2015 14:41:38 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3471A0154; Sun, 8 Mar 2015 14:41:38 -0700 (PDT) Received: by pdjy10 with SMTP id y10so20285960pdj.12; Sun, 08 Mar 2015 14:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=QK7zVvHlFO0D/t8rjn0eWRs+4slqqkqalwAyOS8HTSc=; b=ynbE3U9lc81pUuQwI/kcEyWSwCq5+/fVwDDxysl0sgc0am+dJndq6rQ2FbiIq1V0lh zFAmqXyZnsUSacBpPgjHZpcDqmn2nPQB6xaGbrMcxxX7G4VONxZy5yKp20DQjQiLNMa9 22I0rrssKOKuVSBvykDPiYmTiyLU2xdjXWsV+gzPcYyT19pPWNeDt1kFb53u96xXoHcD guN3PpEzd+ubfYCX/xx9FWSOdT0v5eq/QpI+5HJ19l6DUUoJ2PbsMJKrz5elJbJS6Gra xZrH7mfFf3BYQmkgJN9dn94lKQVW9mGDICbJjdVuAvbQHdi7VZUNxoZetx3oxLtKfc+e urVA== X-Received: by 10.66.145.41 with SMTP id sr9mr9687284pab.18.1425850896957; Sun, 08 Mar 2015 14:41:36 -0700 (PDT) Received: from [10.102.145.87] ([166.170.38.255]) by mx.google.com with ESMTPSA id fx13sm15802652pdb.7.2015.03.08.14.41.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Mar 2015 14:41:36 -0700 (PDT) References: <20150308200240.GA14435@pfrc> Mime-Version: 1.0 (1.0) In-Reply-To: <20150308200240.GA14435@pfrc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Mahesh Jethanandani Date: Sun, 8 Mar 2015 14:41:32 -0700 To: Jeffrey Haas Archived-At: Cc: "i2rs@ietf.org" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Update to draft-haas-i2rs-netmod-netconf-requirements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 21:41:40 -0000 [Speaking as contributor] Jeff, I must have missed the previous reminder or notification about where to add e= phemeral requirements.=20 But would like to add the case which I described on the rtg-yang-coord maili= ng list. Basically there is a requirement that certain configurations should= not be stored in a running configuration but could be saved in ephemeral da= ta store. Example - loop back configuration on a interface. Can be configure= d but never stored in a startup configuration.=20 This might be different from i2rs requirements in that the configuration is m= arked for not writable to a startup and remain as part of ephemeral store.=20= Mahesh Jerhanandani mjethanandani@gmail.com > On Mar 8, 2015, at 1:02 PM, Jeffrey Haas wrote: >=20 > I've updated my personal tracking draft for I2RS requirements upon NETMOD > and NETCONF. The primary changes are: > - To correct the NETCONF over SSH case which is believed to be complete - I= > had failed to read that RFC's security considerations section fully. > - I've removed the subscription section and pointed to the separate draft,= =20 > draft-ietf-i2rs-pub-sub-requirements. >=20 > The primary sticking point remains what to do about the ephemeral state. A= t > IETF 91, we had volunteers willing to document what their ephemeral > implementations actually did rather than trying to invent our own. Howeve= r, > these individuals appear to have been consistently busy during that time > frame. I'd like to use this email to prod them again to lend their effort= s > on documenting their ephemeral implementations. >=20 > -- Jeff >=20 > ----- Forwarded message from IETF Secretariat ----- >=20 > Date: Sun, 08 Mar 2015 12:43:40 -0700 > From: IETF Secretariat > To: jhaas@pfrc.org > Subject: Personal ID list of jhaas@pfrc.org notification: Changes on draft= -haas-i2rs-netmod-netconf-requirements >=20 >=20 > Hello, >=20 > This is a notification from the Personal ID list of jhaas@pfrc.org. >=20 > Document: draft-haas-i2rs-netmod-netconf-requirements, > https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requiremen= ts >=20 > Change: > New version available: *draft-haas-i2rs-netmod-netconf-requirements-01.txt= * >=20 > Best regards, >=20 > The datatracker draft tracking service > (for the IETF Secretariat) >=20 > ----- End forwarded message ----- >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Mar 8 22:50:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753351A701A for ; Sun, 8 Mar 2015 22:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_15=0.6, 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 Dxx9KTGw9jmt for ; Sun, 8 Mar 2015 22:50:34 -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 D64F21A6FF7 for ; Sun, 8 Mar 2015 22:50:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQA35875; Mon, 09 Mar 2015 05:50:32 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Mar 2015 05:50:31 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0158.001; Mon, 9 Mar 2015 13:50:25 +0800 From: Rohit R Ranade To: "netconf@ietf.org" Thread-Topic: Few points about draft-ietf-netconf-call-home-04 Thread-Index: AQHQWizwBMyIx9kg1E+XWWVaZjXOfg== Date: Mon, 9 Mar 2015 05:50:25 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E54C5@szxeml512-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AQib AVVD CjtM DfCu Dson Eg3O FYTo F6pc GgZd HBXp HL0m HMmx HNU+ Hywy I84s JEOX; 1; bgBlAHQAYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {98AC7B20-62D3-4B99-9E88-F188C1A3FB0C}; cgBvAGgAaQB0AHIAcgBhAG4AYQBkAGUAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Mon, 09 Mar 2015 05:50:21 GMT; RgBlAHcAIABwAG8AaQBuAHQAcwAgAGEAYgBvAHUAdAAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBuAGUAdABjAG8AbgBmAC0AYwBhAGwAbAAtAGgAbwBtAGUALQAwADQA x-cr-puzzleid: {98AC7B20-62D3-4B99-9E88-F188C1A3FB0C} x-originating-ip: [10.18.144.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netconf] Few points about draft-ietf-netconf-call-home-04 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, 09 Mar 2015 05:50:43 -0000 Hi All, I have a scenario where in my network element comes up and My management el= ement needs to know when it comes up. The current draft seems to solve it, but a few pain points. 1) In the normal Client-Server model, Client connects and Server accepts co= nnections. But in this case, the Client has to connect and also accept conn= ections. The Server has to connect and also accept connections. The NETCONF= Server will have to depend on SSHS and SSHC . The NETCONF Client will have= to depend on both SSHS and SSHC. This I feel is not right.=20 2) Consider a case where in my management element has multiple IPs, how wil= l the Network element know which IP to connect to ? How will it know the ma= nagement element's IP ? 3) Currently is there any other Protocol where in this feature of intermixi= ng of Client and Server features has been done ? Are the pain points of tho= se implementations=20 Applicable to NETCONF also ? Can those pain points be resolved as part of t= his draft? With Regards, Rohit -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of netconf-reques= t@ietf.org Sent: 07 March, 2015 00:10 To: netconf@ietf.org Subject: Netconf Digest, Vol 85, Issue 9 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. Re: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed (t.petch) 2. Fw: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed (t.petch) 3. Re: zerotouch issues and fixes (Kent Watsen) 4. Re: Fw: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed (Kent Watsen) ---------------------------------------------------------------------- Message: 1 Date: Fri, 6 Mar 2015 10:04:08 +0000 From: t.petch To: Juergen Schoenwaelder Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed Message-ID: <023701d057f4$e75098c0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=3D"iso-8859-1" ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t. petch" Cc: "Ersue, Mehmet (Nokia - DE/Munich)" ; Sent: Thursday, March 05, 2015 4:17 PM > While I like some of the words, it might be that 'server initiated > connections' and 'client initiated connections' may be easiest to > grasp. Yes, I like that. I am not sure how far you would take it. 'server-model' has many instances of 'call-home' and 'listen' in the YANG modules for feature, grouping and container where a shorter identifier seems right. But it then goes on to use 'call home' and 'listen' extensively in the 'description' clauses, which seems to follow logically, and also in the textual sections, s.1 and s.2. It seems unnatural to draw a line between the terminology of the textual sections and the YANG modules so 'server-model' then ends up with 'call(-)home' and 'listen(ing)' everywhere (with some tidying up of the actual spelling perhaps) . Logically, then, we end up with 'server initiated connections' and 'client initiated connections' in the call home I-D with an explanation somewhere, probably in both I-Ds, that this maps onto 'call-home' and 'listen'. Mmmmm... I am ok with that even if it is not as tidy as I first envisioned. Tom Petch > /js > > On Thu, Mar 05, 2015 at 04:06:26PM +0000, t. petch wrote: > > A separate comment to those I made earlier. > > > > What is the right term to refer to Netconf connections that are NOT > > using call home? > > > > This I-D sometimes talks of 'standard' (which makes call home > > nonstandard), sometimes of 'normal circumstances' (which makes call home > > abnormal). > > > > These seem judgmental to me and I would like a less judgmental term. > > 'Orthodox' (which makes call home heterodox), 'Classic' (which makes > > call home modern) or ... but I think that it needs changing. > > > > But then server-model has 'listen' or 'listening for connections', > > fairly consistently, along with 'call home' > > > > I think that this I-D should be consistent and perhaps consistent with > > server-model. > > > > Tom Petch > > > > > ----- Original Message ----- > > > From: "Ersue, Mehmet (Nokia - DE/Munich)" > > > To: > > > Sent: Tuesday, March 03, 2015 10:16 PM > > > > > > Dear NETCONF WG, > > > > > > we hereby issue a WG Last Call for 2 weeks for the drafts below: > > > > > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > > > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > > > > > Please review and send your comments to the NETCONF WG mailing list by > > > March 17, 2015 EOB PT. > > > > > > Call Home and Server Model drafts are planned to publish as standard > > > track documents. > > > > > > Please state explicitly that you have read/reviewed and whether you > > > support the publication of the drafts. > > > Please indicate also if you plan to implement or have already > > > implementation experience with the these drafts. > > > > > > Thank you, > > > Mehmet and Mahesh > > > > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext > > Ersue, > > > Mehmet (NSN - DE/Munich) > > > Sent: Thursday, February 05, 2015 5:30 PM > > > To: netconf@ietf.org > > > Subject: [Netconf] call-home-04 and server-model-06 available - All > > Open > > > issues closed > > > > > > All, > > > > > > all call-home issues have been solved and there are 3 issues for > > > server-model draft in REVIEW state. > > > See > > > > > https://github.com/netconf-wg/call-home/issues?q=3Dis%3Aissue+is%3Aclosed > > > and > > > https://github.com/netconf-wg/server-model/issues. > > > > > > Please check the provided solutions in the updated drafts and comment > > > before we go to WGLC after the end of Restconf LC. > > > > > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > > > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > > > > > Regards, > > > Mehmet > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > -------- > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 ------------------------------ Message: 2 Date: Fri, 6 Mar 2015 16:59:58 +0000 From: t.petch To: , Subject: [Netconf] Fw: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed Message-ID: <043e01d0582e$ff915980$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=3D"iso-8859-1" I have read, and re-read and re-read ... section 3.2 of call-home and I am struggling. I am reminded of rfc5539bis where we started out with something similar and ended up with " The NETCONF client MUST check the identity of the server according to Section 6 of [RFC6125]." which I think was a great idea. We cannot go quite that far with the call-home I-D but think we should be heading in that direction. Surely all we need to say, in essence, is that because the server has initiated the connection then we have no reference identity and so RFC6125 cannot apply. Therefore the client must be preconfigured with whatever it will trust from the server, be that a certificate or a host key. And it should be the certificate of the server; a CA certificate on its own is not enough since, as we have said already, we have no reference identity so knowing that the end user certificate chains back to a valid CA is not enough (in general). And yes, preconfiguring information is a pain but if you want security, you have to do it. So along those lines I offer a new 3.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 3.2. Server Identification and Authentication When a NETCONF/RESTCONF client initiates the connection to the NETCONF/RESTCONF server, the client has prior knowledge of the identity of the NETCONF/RESTCONF server it is connecting to. When using TLS or SSH with certificates, the NETCONF client can then check the identity of the server according to Section 6 of [RFC6125]. Similar considerations apply when using SSH with host keys. When the connection is initiated by the NETCONF/RESTCONF server, the NETCONF/RESTCONF client does not have any prior knowledge of the identity of the NETCONF/RESTCONF server which has initiated the connection. The NETCONF/RESTCONF client must derive the identity of the NETCONF/RESTCONF server from information provided by the network or by the NETCONF/RESTCONF server itself. This section describes strategies a NETCONF/RESTCONF client can then use to identify a NETCONF/RESTCONF server. A NETCONF/RESTCONF client must also authenticate the identity of the server. This is always an issue but especially so when the NETCONF/RESTCONF server initiates the connection since this approach is common for newly deployed NETCONF/RESTCONF servers. The first piece of information that a NETCONF/RESTCONF client learns when the server initiates the connection is the IP address of the NETCONF/RESTCONF server, i.e the source address of the TCP connection. This IP address is an identifier but is only reliable in networks that use known static addresses. This case is infrequent; so it is NOT RECOMMENDED to identify a NETCONF/RESTCONF server by its source IP address. The next piece of information a NETCONF/RESTCONF client learns is provided by the NETCONF/RESTCONF server in the form of a host-key (for SSH) or a certificate (for SSH or TLS). This host-key or certificate, either in its entirety or as a fingerprint, can be used to look up an identifier for the NETCONF/RESTCONF server. Each NETCONF/RESTCONF server is assumed to have a statistically unique public key, even in virtualized environments. This approach also provides authentication in that a secure connection can only be established when the NETCONF/RESTCONF server can demonstrate possession of the matching private key. This approach is common with SSH clients but could be used equally well by TLS clients. It may be the required when the NETCONF/RESTCONF servers have self-signed certificates. [** I do not understand the next OLD paragraph and so am guessing here. Doubtless I will be told where my guesses are wrong] A variation on the previous option can be used when the manufacturer of the NETCONF/RESTCONF servers is a trusted CA and provisions the NETCONF/RESTCONF servers with certificates such as is described by [Std-802.1AR-2009]. After verifying that the certificate is valid [RFC5280], an identifier can be extracted from the certificate, e.g. from the subjectAltName. The NETCONF/RESTCONF client SHOULD still be configured with the CA certificate and a list of expected identifiers of the NETCONF/RESTCONF servers, as supplied by the manufacturer. [Which seems very close to the usual RFC6125 case - what am I missing?] Note that while TLS uses X.509 certificates by default, using X.509 certificates with SSH requires both the NETCONF client and server to support [RFC6187]. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D I would probably cut down on the number of times NETCONF/RESTCONF appears but am not too bothered by it. Which is all the comments I currently have on draft-ietf-netconf-call-home-04. Tom Petch > ----- Original Message ----- > From: "Ersue, Mehmet (Nokia - DE/Munich)" > To: > Sent: Tuesday, March 03, 2015 10:16 PM > Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and > server-model-06 available - All Open issues closed > > > Dear NETCONF WG, > > we hereby issue a WG Last Call for 2 weeks for the drafts below: > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > Please review and send your comments to the NETCONF WG mailing list by > March 17, 2015 EOB PT. > > Call Home and Server Model drafts are planned to publish as standard > track documents. > > Please state explicitly that you have read/reviewed and whether you > support the publication of the drafts. > Please indicate also if you plan to implement or have already > implementation experience with the these drafts. > > Thank you, > Mehmet and Mahesh > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, > Mehmet (NSN - DE/Munich) > Sent: Thursday, February 05, 2015 5:30 PM > To: netconf@ietf.org > Subject: [Netconf] call-home-04 and server-model-06 available - All Open > issues closed > > All, > > all call-home issues have been solved and there are 3 issues for > server-model draft in REVIEW state. > See > https://github.com/netconf-wg/call-home/issues?q=3Dis%3Aissue+is%3Aclosed > and > https://github.com/netconf-wg/server-model/issues. > > Please check the provided solutions in the updated drafts and comment > before we go to WGLC after the end of Restconf LC. > > https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 > https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 > > Regards, > Mehmet > > --=3D=3D=3D=3D=3D2634486923681469604=3D- > ------------------------------ Message: 3 Date: Fri, 6 Mar 2015 18:31:01 +0000 From: Kent Watsen To: Joe Clarke , "netconf@ietf.org" Subject: Re: [Netconf] zerotouch issues and fixes Message-ID: Content-Type: text/plain; charset=3D"us-ascii" OK, it seems that there is some support for this approach. I'd plan to post an updated draft that captures the idea more completely. We can always roll it back if needed... Thanks, Kent On 3/3/15, 11:15 AM, "Joe Clarke" wrote: >On 3/2/15 10:43 AM, Kent Watsen wrote: >> >> >>> I think this approach is reasonable. The interaction with the vendor >>>is >>> minimal (only to claim the device-IDs and get the voucher). >> >> Exactly, this solution optimizes for the vendor - it's very low-touch >>and >> doesn't rely on a realtime lookup service. But "reasonable" sounds >> uncommitted - what we need to know is it's better - what do you think? > >Sorry, didn't mean to sound noncommittal. I like it. I just think the >questions I had raised need to be addressed (i.e., around Owner ID and >verifying expiry on the device's part). > >> >> >>> Though, the >>> time-to-live of the voucher needs to be accounted for by the device. >>>It >>> needs to confirm the voucher is still "alive." >> >> Yes, there is a presumption that the device has an accurate clock. Such >> it is with PKI in general. For instance, CRLs are only useful if >>they're >> relatively fresh (a year-old CRL is not very useful). > >Of course. It's just you didn't mention that in your rough >walk-through. That needs to be part of the process. > >> >> >> >>> Would it make sense to >>> have a per-device TTL in the voucher? >> >> This would be doable. As a voucher is a data file (not a X.509 >> certificate), for which we could define schema for, and thus it could >>take >> any form we deem best. That said, I question if it makes sense for a >> vendor to issue a voucher with varying TTLs. Is the vendor suppose to >> know that some device's ownership is more volatile than others? - or do >> you see this as user-input? > >I see this as user input. The use case I envision is that the owner >might set a certain timeline for other devices to give a safety net to >prevent old devices from bootstrapping. It may not be common, and thus >this could be a MAY. It just offers flexibility. > >> >> >>> I also think there needs to be a way for the NMS to request an owner >>>ID. >>> The reason for this is what happens if I have to replace the NMS. I >>> would need a new private key and a new CSR. While I could get a new >>> voucher with the new owner ID, this would likely be more of a hassle as >>> the vendor will likely associate the devices with one owner ID. >> >> Yes, vendors would have to be able to reissue the NMS certificates. >> Vendors could re-assign the same Owner ID the NMS had before or >>generate a >> new one. If a new Owner ID is generated, then the vendor would also >>need >> to reissue Vouchers for devices that have not yet been claimed (e.g., >>gone >> through the zerotouch process). > >How do we state this in the draft? I think it deserves a callout. The >Owner ID can't simply be a random thing, but needs to tie to the owner >entity (yet still be unique between entities). Can we say that the >owner entity can suggest an Owner ID? > >Joe ------------------------------ Message: 4 Date: Fri, 6 Mar 2015 18:39:46 +0000 From: Kent Watsen To: t.petch , "netconf@ietf.org" , "mehmet.ersue@nokia.com" Subject: Re: [Netconf] Fw: WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Tom and Juergen, Thank you for all your comments so far. I will more fully engage in this thread after the draft submission deadline has past. I just wanted to let you know why I haven't replied yet. Thanks again, Kent On 3/6/15, 11:59 AM, "t.petch" wrote: > > I have read, and re-read and re-read ... section 3.2 of call-home and I > am struggling. I am reminded of rfc5539bis where we started out with > something similar and ended up with > " The NETCONF client MUST check the identity of the server according >to > Section 6 of [RFC6125]." > which I think was a great idea. > > We cannot go quite that far with the call-home I-D but think we should > be > heading in that direction. > > Surely all we need to say, in essence, is that because the server has > initiated the connection then we have no reference identity and so > RFC6125 cannot apply. Therefore the client must be preconfigured with > whatever it will trust from the server, be that a certificate or a host > key. And it should be the certificate of the server; a CA certificate > on > its own is not enough since, as we have said already, we have no > reference identity so knowing that the end user certificate chains back > to a valid CA is not enough (in general). > > And yes, preconfiguring information is a pain but if you want security, > you have to do it. > > So along those lines I offer a new 3.2 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > 3.2. Server Identification and Authentication > > When a NETCONF/RESTCONF client initiates the > connection to the NETCONF/RESTCONF server, the client has prior > knowledge of the identity of the NETCONF/RESTCONF server it is > connecting to. When using TLS or SSH with certificates, > the NETCONF client can then check the identity of the server > according to > Section 6 of [RFC6125]. > Similar considerations apply when using SSH with host keys. > > When the connection is initiated by the NETCONF/RESTCONF server, the > NETCONF/RESTCONF client does not have any prior knowledge of the > identity of the NETCONF/RESTCONF server which has initiated the > connection. The NETCONF/RESTCONF > client must derive the identity of the NETCONF/RESTCONF server from > information provided by the network or by the NETCONF/RESTCONF server > itself. This section describes strategies a NETCONF/RESTCONF client > can then use to identify a NETCONF/RESTCONF server. > > A NETCONF/RESTCONF client must also authenticate the identity of the > server. This is always an issue but especially so when the > NETCONF/RESTCONF server initiates the connection since this approach is > common for newly deployed NETCONF/RESTCONF servers. > > The first piece of information that a NETCONF/RESTCONF client learns > when the server initiates the connection is the IP address of the > NETCONF/RESTCONF server, i.e the source address of the TCP connection. > This IP address is an identifier but is only reliable in networks that > use known static addresses. This case is infrequent; so it is NOT > RECOMMENDED to identify a NETCONF/RESTCONF server by its source IP > address. > > The next piece of information a NETCONF/RESTCONF client learns is > provided by the NETCONF/RESTCONF server in the form of a host-key (for > SSH) or a certificate (for SSH or TLS). This host-key or certificate, > either in its > entirety or as a fingerprint, can be used to look up an identifier for > the NETCONF/RESTCONF server. Each NETCONF/RESTCONF > server is assumed to have a statistically unique public key, even in > virtualized environments. This approach also provides authentication >in > that a secure connection can only be established when the > NETCONF/RESTCONF server can demonstrate possession of > the matching private key. This approach is common with SSH clients but > could be used equally well by TLS clients. It may be the required when > the NETCONF/RESTCONF servers have self-signed certificates. > > [** I do not understand the next OLD paragraph and so am guessing here. > Doubtless I will be told where my guesses are wrong] > > A variation on the previous option can be used when the manufacturer of > the NETCONF/RESTCONF servers is a trusted CA and provisions the > NETCONF/RESTCONF servers with certificates such as is described by > [Std-802.1AR-2009]. After verifying that the certificate is valid > [RFC5280], an identifier can be extracted from the certificate, e.g. > from the subjectAltName. The NETCONF/RESTCONF client SHOULD still be > configured with the CA certificate and a list of expected identifiers >of > the NETCONF/RESTCONF servers, as supplied by the manufacturer. > > [Which seems very close to the usual RFC6125 case - what am I missing?] > > Note that while TLS uses X.509 certificates by default, using X.509 > certificates with SSH requires both the NETCONF client and server to > support [RFC6187]. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > I would probably cut down on the number of times NETCONF/RESTCONF > appears but am not too bothered by it. > > Which is all the comments I currently have on > draft-ietf-netconf-call-home-04. > > Tom Petch > >> ----- Original Message ----- >> From: "Ersue, Mehmet (Nokia - DE/Munich)" >> To: >> Sent: Tuesday, March 03, 2015 10:16 PM >> Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 >and >> draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and >> server-model-06 available - All Open issues closed >> >> >> Dear NETCONF WG, >> >> we hereby issue a WG Last Call for 2 weeks for the drafts below: >> >> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 >> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 >> >> Please review and send your comments to the NETCONF WG mailing list by >> March 17, 2015 EOB PT. >> >> Call Home and Server Model drafts are planned to publish as standard >> track documents. >> >> Please state explicitly that you have read/reviewed and whether you >> support the publication of the drafts. >> Please indicate also if you plan to implement or have already >> implementation experience with the these drafts. >> >> Thank you, >> Mehmet and Mahesh >> >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext >Ersue, >> Mehmet (NSN - DE/Munich) >> Sent: Thursday, February 05, 2015 5:30 PM >> To: netconf@ietf.org >> Subject: [Netconf] call-home-04 and server-model-06 available - All >Open >> issues closed >> >> All, >> >> all call-home issues have been solved and there are 3 issues for >> server-model draft in REVIEW state. >> See >> >https://github.com/netconf-wg/call-home/issues?q=3Dis%3Aissue+is%3Aclosed >> and >> https://github.com/netconf-wg/server-model/issues. >> >> Please check the provided solutions in the updated drafts and comment >> before we go to WGLC after the end of Restconf LC. >> >> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04 >> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06 >> >> Regards, >> Mehmet >> >> --=3D=3D=3D=3D=3D2634486923681469604=3D- >> > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf ------------------------------ Subject: Digest Footer _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------------------------------ End of Netconf Digest, Vol 85, Issue 9 ************************************** From nobody Mon Mar 9 02:43:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D481D1A8759 for ; Mon, 9 Mar 2015 02:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 tAvbM3Wzznej for ; Mon, 9 Mar 2015 02:43:50 -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 4D4CB1A8752 for ; Mon, 9 Mar 2015 02:43:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B11D4124F; Mon, 9 Mar 2015 10:43:48 +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 uAQp1Mo4JVYS; Mon, 9 Mar 2015 10:43:47 +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, 9 Mar 2015 10:43:47 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0D192003C; Mon, 9 Mar 2015 10:43:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IyJLtyzbVTUT; Mon, 9 Mar 2015 10:43:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 006E12003D; Mon, 9 Mar 2015 10:43:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A5E7332738EA; Mon, 9 Mar 2015 10:43:44 +0100 (CET) Date: Mon, 9 Mar 2015 10:43:43 +0100 From: Juergen Schoenwaelder To: Rohit R Ranade Message-ID: <20150309094341.GA3212@elstar.local> Mail-Followup-To: Rohit R Ranade , "netconf@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A671E54C5@szxeml512-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E54C5@szxeml512-mbs.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04 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, 09 Mar 2015 09:43:53 -0000 On Mon, Mar 09, 2015 at 05:50:25AM +0000, Rohit R Ranade wrote: > Hi All, > > > I have a scenario where in my network element comes up and My management element needs to know when it comes up. > The current draft seems to solve it, but a few pain points. > > 1) In the normal Client-Server model, Client connects and Server accepts connections. But in this case, the Client has to connect and also accept connections. The Server has to connect and also accept connections. The NETCONF Server will have to depend on SSHS and SSHC . The NETCONF Client will have to depend on both SSHS and SSHC. This I feel is not right. With call home, the server connects to the client (so there needs to be a daemon accepting incoming connections) but then roles are swapped and the same connection is used to run either SSH or TLS over it. > 2) Consider a case where in my management element has multiple IPs, how will the Network element know which IP to connect to ? How will it know the management element's IP ? There once was an ID proposing DHCP options for this... One could perhaps also play with DNS SRV records. I think the question how you learn where to call home is outside of the call home mechanism itself. > 3) Currently is there any other Protocol where in this feature of intermixing of Client and Server features has been done ? Are the pain points of those implementations > Applicable to NETCONF also ? Can those pain points be resolved as part of this draft? I think it would help if you can describe what the pain points are that you see. Otherwise, this is open ended and not actionable. /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 Mar 9 03:05:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27B41A8797 for ; Mon, 9 Mar 2015 03:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F02hEqq9f9bg for ; Mon, 9 Mar 2015 03:05:39 -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 542E91A8795 for ; Mon, 9 Mar 2015 03:05:38 -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 BQA62586; Mon, 09 Mar 2015 10:05:37 +0000 (GMT) Received: from SZXEML427-HUB.china.huawei.com (10.82.67.182) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Mar 2015 10:05:36 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0158.001; Mon, 9 Mar 2015 18:05:18 +0800 From: Rohit R Ranade To: Juergen Schoenwaelder Thread-Topic: [Netconf] Few points about draft-ietf-netconf-call-home-04 Thread-Index: AQHQWk2Q8eM4hVwM+0arega4pvSMSZ0T6A+g Date: Mon, 9 Mar 2015 10:05:18 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E5548@szxeml512-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A671E54C5@szxeml512-mbs.china.huawei.com> <20150309094341.GA3212@elstar.local> In-Reply-To: <20150309094341.GA3212@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04 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, 09 Mar 2015 10:05:41 -0000 Hi, ## With call home, the server connects to the client (so there needs to be a daemon accepting incoming connections) but then roles are swapped and the same connection is used to run either SSH or TLS over it. ## About the above statement, does it mean that after Server connects to the c= lient, the client will initiate the authorization process as if it connecte= d to the Server ? My pain point about the mixing of Client and Server features is that if a m= odule based architecture is considered where NETCONFS sits above SSHS and N= ETCONFC sits above SSHC. 1) NETCONFS will have to sit above SSHS and SSHC (Since all socket and auth= orization related info will be handled by SSHS and its underlying layers). 2) NETCONFS at Network element and at Management element will be slightly d= ifferent (one with call home, one without). Its dependency with underlying = modules will also be dependent on whether the device is NE or management el= ement. With Regards, Rohit -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: 09 March, 2015 15:14 To: Rohit R Ranade Cc: netconf@ietf.org Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04 On Mon, Mar 09, 2015 at 05:50:25AM +0000, Rohit R Ranade wrote: > Hi All, >=20 >=20 > I have a scenario where in my network element comes up and My management = element needs to know when it comes up. > The current draft seems to solve it, but a few pain points. >=20 > 1) In the normal Client-Server model, Client connects and Server accepts = connections. But in this case, the Client has to connect and also accept co= nnections. The Server has to connect and also accept connections. The NETCO= NF Server will have to depend on SSHS and SSHC . The NETCONF Client will ha= ve to depend on both SSHS and SSHC. This I feel is not right. With call home, the server connects to the client (so there needs to be a daemon accepting incoming connections) but then roles are swapped and the same connection is used to run either SSH or TLS over it. =20 > 2) Consider a case where in my management element has multiple IPs, how w= ill the Network element know which IP to connect to ? How will it know the = management element's IP ? There once was an ID proposing DHCP options for this... One could perhaps also play with DNS SRV records. I think the question how you learn where to call home is outside of the call home mechanism itself. > 3) Currently is there any other Protocol where in this feature of intermi= xing of Client and Server features has been done ? Are the pain points of t= hose implementations=20 > Applicable to NETCONF also ? Can those pain points be resolved as part of= this draft? I think it would help if you can describe what the pain points are that you see. Otherwise, this is open ended and not actionable. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Mar 9 03:33:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283E51A8786 for ; Mon, 9 Mar 2015 03:33:03 -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 ukuCWmuoVR5G for ; Mon, 9 Mar 2015 03:33:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7601A875C for ; Mon, 9 Mar 2015 03:33:00 -0700 (PDT) Received: from pc6 (86.185.85.149) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.106.15; Mon, 9 Mar 2015 10:32:41 +0000 Message-ID: <020101d05a54$0ec3a580$4001a8c0@gateway.2wire.net> From: t.petch To: Rohit R Ranade , References: <991B70D8B4112A4699D5C00DDBBF878A671E54C5@szxeml512-mbs.china.huawei.com> Date: Mon, 9 Mar 2015 10:29:15 +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.185.85.149] X-ClientProxiedBy: HE1PR08CA0031.eurprd08.prod.outlook.com (25.161.112.41) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(27574002)(13464003)(377454003)(51704005)(1556002)(23756003)(77096005)(14496001)(1456003)(19580405001)(15975445007)(19580395003)(50466002)(33646002)(46102003)(86362001)(84392001)(66066001)(122386002)(116806002)(50226001)(230783001)(107886001)(81816999)(47776003)(61296003)(87976001)(40100003)(92566002)(50986999)(42186005)(62966003)(76176999)(81686999)(64706001)(44736004)(77156002)(62236002)(44716002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; X-Forefront-PRVS: 05102978A2 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2015 10:32:41.2613 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04 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, 09 Mar 2015 10:33:03 -0000 ----- Original Message ----- From: "Rohit R Ranade" To: Sent: Monday, March 09, 2015 5:50 AM > > I have a scenario where in my network element comes up and My management element needs to know when it comes up. > The current draft seems to solve it, but a few pain points. > > 1) In the normal Client-Server model, Client connects and Server accepts connections. But in this case, the Client has to connect and also accept connections. The Server has to connect and also accept connections. The NETCONF Server will have to depend on SSHS and SSHC . The NETCONF Client will have to depend on both SSHS and SSHC. This I feel is not right. > > 2) Consider a case where in my management element has multiple IPs, how will the Network element know which IP to connect to ? How will it know the management element's IP ? > > 3) Currently is there any other Protocol where in this feature of intermixing of Client and Server features has been done ? Are the pain points of those implementations > Applicable to NETCONF also ? Can those pain points be resolved as part of this draft? Rohit The idea of an internet host being both client and server has been around for decades, with protocols such as mail, FTP, HTTP ... and SNMP. I used to wonder how it was done and then I learnt about TCP and UDP port numbers and all became clear. But that is not what is happening here and if you think it is, then I would be interested to hear which bit of call-home is creating that impression. Here, the NMS is always the NETCONF client, the network element is always the NETCONF server, so at the application level, nothing is reversed. Likewise at the SSH (or TLS) level, nothing is reversed. It is only at the TCP level that a reverse takes place, that the network element is now the TCP client requesting a TCP connection of the NMS as TCP server, after which, normal SSH (or TLS) service resumes. As to finding one or more IP addresses for the NMS, well, it has to be discovered or configured, as ever. Tom Petch > With Regards, > Rohit > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of netconf-request@ietf.org > Sent: 07 March, 2015 00:10 > To: netconf@ietf.org > Subject: Netconf Digest, Vol 85, Issue 9 > > 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. Re: WG Last Call for draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and > server-model-06 available - All Open issues closed (t.petch) > 2. Fw: WG Last Call for draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and > server-model-06 available - All Open issues closed (t.petch) > 3. Re: zerotouch issues and fixes (Kent Watsen) > 4. Re: Fw: WG Last Call for draft-ietf-netconf-call-home-04 and > draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and > server-model-06 available - All Open issues closed (Kent Watsen) > > > ---------------------------------------------------------------------- > > From nobody Mon Mar 9 03:43:44 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2871A876B for ; Mon, 9 Mar 2015 03:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 Ex4NmvAMK4YE for ; Mon, 9 Mar 2015 03:43:35 -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 35FE61A87B3 for ; Mon, 9 Mar 2015 03:43:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 08946108F; Mon, 9 Mar 2015 11:43:34 +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 ApqgajFp_943; Mon, 9 Mar 2015 11:43:32 +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, 9 Mar 2015 11:43:33 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D9412003D; Mon, 9 Mar 2015 11:43:33 +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 NIusQAXw_tek; Mon, 9 Mar 2015 11:43:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 392B42003C; Mon, 9 Mar 2015 11:43:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 227AE3273B4B; Mon, 9 Mar 2015 11:43:24 +0100 (CET) Date: Mon, 9 Mar 2015 11:43:24 +0100 From: Juergen Schoenwaelder To: Rohit R Ranade Message-ID: <20150309104324.GA3424@elstar.local> Mail-Followup-To: Rohit R Ranade , "netconf@ietf.org" References: <991B70D8B4112A4699D5C00DDBBF878A671E54C5@szxeml512-mbs.china.huawei.com> <20150309094341.GA3212@elstar.local> <991B70D8B4112A4699D5C00DDBBF878A671E5548@szxeml512-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671E5548@szxeml512-mbs.china.huawei.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04 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, 09 Mar 2015 10:43:40 -0000 On Mon, Mar 09, 2015 at 10:05:18AM +0000, Rohit R Ranade wrote: > Hi, > > ## > With call home, the server connects to the client (so there needs to > be a daemon accepting incoming connections) but then roles are swapped > and the same connection is used to run either SSH or TLS over it. > ## > > About the above statement, does it mean that after Server connects to the client, the client will initiate the authorization process as if it connected to the Server ? This is my understanding. > My pain point about the mixing of Client and Server features is that if a module based architecture is considered where NETCONFS sits above SSHS and NETCONFC sits above SSHC. > 1) NETCONFS will have to sit above SSHS and SSHC (Since all socket and authorization related info will be handled by SSHS and its underlying layers). > 2) NETCONFS at Network element and at Management element will be slightly different (one with call home, one without). Its dependency with underlying modules will also be dependent on whether the device is NE or management element. Quoting from the Introduction: Both NETCONF Call Home and RESTCONF Call Home preserve the client/ server roles of underlying transport, as when compared to standard NETCONF and RESTCONF connections. Specifically, regardless if call home is used or not, the SSH and TLS client/server roles are the same. I think this answers 1). I do not understand 2). /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 Mar 9 05:00:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC121A87C8 for ; Mon, 9 Mar 2015 05:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, 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 LH4yvlws1rHz for ; Mon, 9 Mar 2015 05:00:30 -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 CA1411A87CC for ; Mon, 9 Mar 2015 05:00:29 -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 BTK96053; Mon, 09 Mar 2015 12:00:28 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Mar 2015 12:00:27 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.141]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0158.001; Mon, 9 Mar 2015 20:00:04 +0800 From: Rohit R Ranade To: "t.petch" , "netconf@ietf.org" Thread-Topic: [Netconf] Few points about draft-ietf-netconf-call-home-04 Thread-Index: AQHQWlRkt4OvOqn+k0WX7mgM1HO1Pp0T+j7g Date: Mon, 9 Mar 2015 12:00:03 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A671E5594@szxeml512-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A671E54C5@szxeml512-mbs.china.huawei.com> <020101d05a54$0ec3a580$4001a8c0@gateway.2wire.net> In-Reply-To: <020101d05a54$0ec3a580$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.144.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04 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, 09 Mar 2015 12:00:32 -0000 Hi, After your explanation of reversing at the TCP level it is quite clear. For= a first time reader of this draft, it was not very clear. But, it will still impact the state-machines of NETCONFS, SSHS and SSHC. I = think this impact is OK, considering the benefits. Maybe the draft can be updated about the changes in the state-machines with= a clear diagram.=20 With Regards, Rohit -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com]=20 Sent: 09 March, 2015 15:59 To: Rohit R Ranade; netconf@ietf.org Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04 ----- Original Message ----- From: "Rohit R Ranade" To: Sent: Monday, March 09, 2015 5:50 AM > > I have a scenario where in my network element comes up and My management element needs to know when it comes up. > The current draft seems to solve it, but a few pain points. > > 1) In the normal Client-Server model, Client connects and Server accepts connections. But in this case, the Client has to connect and also accept connections. The Server has to connect and also accept connections. The NETCONF Server will have to depend on SSHS and SSHC . The NETCONF Client will have to depend on both SSHS and SSHC. This I feel is not right. > > 2) Consider a case where in my management element has multiple IPs, how will the Network element know which IP to connect to ? How will it know the management element's IP ? > > 3) Currently is there any other Protocol where in this feature of intermixing of Client and Server features has been done ? Are the pain points of those implementations > Applicable to NETCONF also ? Can those pain points be resolved as part of this draft? Rohit The idea of an internet host being both client and server has been around for decades, with protocols such as mail, FTP, HTTP ... and SNMP. I used to wonder how it was done and then I learnt about TCP and UDP port numbers and all became clear. But that is not what is happening here and if you think it is, then I would be interested to hear which bit of call-home is creating that impression. Here, the NMS is always the NETCONF client, the network element is always the NETCONF server, so at the application level, nothing is reversed. Likewise at the SSH (or TLS) level, nothing is reversed. It is only at the TCP level that a reverse takes place, that the network element is now the TCP client requesting a TCP connection of the NMS as TCP server, after which, normal SSH (or TLS) service resumes. As to finding one or more IP addresses for the NMS, well, it has to be discovered or configured, as ever. Tom Petch From nobody Mon Mar 9 14:50:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B651ACC81; Mon, 9 Mar 2015 14:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 g44wRdLAJMV8; Mon, 9 Mar 2015 14:50:17 -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 293E01AC3CF; Mon, 9 Mar 2015 14:50: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 EB0D81B6B; Mon, 9 Mar 2015 22:50:04 +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 JeaBOtehRmjc; Mon, 9 Mar 2015 22:50:00 +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, 9 Mar 2015 22:50:04 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8D9A20043; Mon, 9 Mar 2015 22:50:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id T7-6tgPijinU; Mon, 9 Mar 2015 22:50:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF0412003C; Mon, 9 Mar 2015 22:50:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8ADF7327522C; Mon, 9 Mar 2015 22:50:01 +0100 (CET) Date: Mon, 9 Mar 2015 22:50:01 +0100 From: Juergen Schoenwaelder To: Pearl Liang via RT Message-ID: <20150309215001.GA5289@elstar.local> Mail-Followup-To: Pearl Liang via RT , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, netconf@ietf.org, iesg@ietf.org References: <20150225133056.10361.76072.idtracker@ietfa.amsl.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: Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, iesg@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [IANA #810237] Last Call: (Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication) to Proposed Standard 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, 09 Mar 2015 21:50:19 -0000 Hi, your understanding of the IANA action is correct. /js On Mon, Mar 09, 2015 at 09:45:02PM +0000, Pearl Liang via RT wrote: > (BEGIN IANA LAST CALL COMMENTS) > > IESG/Authors/WG Chairs: > > IANA has reviewed draft-ietf-netconf-rfc5539bis-09. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. > > We received the following comments/questions from the IANA's reviewer: > > IANA understands that, upon approval of this document, IANA is required complete a single action. > > In the Service Name and Transport Protocol Port Number Registry located at: > > https://www.iana.org/assignments/service-names-port-numbers/ > > the existing port number 6513 for TCP, described as "NETCONF over TLS" will have its reference changed from RFC5539 to [ RFC-to-be ]. > > IANA understands that this is the only action required to be completed upon approval of this document. > > Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. > > Thanks, > > Pearl Liang > ICANN > > (END IANA LAST CALL COMMENTS) > > On Wed Feb 25 13:31:20 2015, iesg-secretary@ietf.org wrote: > > > > The IESG has received a request from the Network Configuration WG > > (netconf) to consider the following document: > > - 'Using the NETCONF Protocol over Transport Layer Security (TLS) with > > Mutual X.509 Authentication' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2015-03-11. Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > The Network Configuration Protocol (NETCONF) provides mechanisms to > > install, manipulate, and delete the configuration of network devices. > > This document describes how to use the Transport Layer Security (TLS) > > protocol with mutual X.509 authentication to secure the exchange of > > NETCONF messages. This revision of RFC 5539 documents the new > > message framing used by NETCONF 1.1 and it obsoletes RFC 5539. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > -- 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 Mar 9 16:57:15 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E74F1ACE51; Mon, 9 Mar 2015 16:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie55fhuyCsYe; Mon, 9 Mar 2015 16:57:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD601ACE8E; Mon, 9 Mar 2015 16:56:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309235642.2282.21343.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 16:56:42 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-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: Mon, 09 Mar 2015 23:57:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) Authors : Kent Watsen Joe Clarke Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-02.txt Pages : 31 Date : 2015-03-09 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 its rightful 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-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 Mon Mar 9 17:18:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C521A87B2 for ; Mon, 9 Mar 2015 17:18:23 -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 4LBQP_vEL-kq for ; Mon, 9 Mar 2015 17:18:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D468D1A88E8 for ; Mon, 9 Mar 2015 17:18:20 -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.1.99.14; Tue, 10 Mar 2015 00:18:18 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) with mapi id 15.01.0099.004; Tue, 10 Mar 2015 00:18:18 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-02.txt Thread-Index: AQHQWsTnpDmelIemEE+1r4CjGCwXkp0UltQA Date: Tue, 10 Mar 2015 00:18:18 +0000 Message-ID: References: <20150309235642.2282.21343.idtracker@ietfa.amsl.com> In-Reply-To: <20150309235642.2282.21343.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-originating-ip: [66.129.239.11] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(53754006)(377424004)(377454003)(479174004)(51704005)(2900100001)(2950100001)(102836002)(15975445007)(106116001)(99286002)(36756003)(19580405001)(87936001)(50986999)(54356999)(76176999)(1720100001)(2351001)(107886001)(110136001)(46102003)(66066001)(230783001)(450100001)(83506001)(2656002)(40100003)(19580395003)(122556002)(92566002)(2501003)(62966003)(77156002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001009); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 051158ECBB Content-Type: text/plain; charset="us-ascii" Content-ID: <6695F8015ADB564F90D01E2F2794D1D6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2015 00:18:18.2377 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-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: Tue, 10 Mar 2015 00:18:23 -0000 Hey all, If interested in zero touch, please take notice of this update! Changes include: o Renamed Configuration Server to Bootstrap Server, a more representative name given the information devices download from it. o Replaced the concept of a Configlet, by defining a southbound interface for the Bootstrap Server using YANG. This also nicely removes the need to support XMLSIG. o Removed the IANA request for the boot-image and configuration media types, as the Bootstrap server's southbound interface has explicit resources for each, and then some. Hoping to receive comments on list or in Dallas! Cheers, Kent On 3/9/15, 7:56 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 > Joe Clarke > Mikael Abrahamsson > Filename : draft-ietf-netconf-zerotouch-02.txt > Pages : 31 > Date : 2015-03-09 > >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 its rightful 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-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-zerotouch-02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Mar 10 02:14:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94311A7023 for ; Tue, 10 Mar 2015 02:14:35 -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 YwydsHLgwxFl for ; Tue, 10 Mar 2015 02:14:33 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5421A1BF1 for ; Tue, 10 Mar 2015 02:14:33 -0700 (PDT) Received: by obcvb8 with SMTP id vb8so164560obc.10 for ; Tue, 10 Mar 2015 02:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=V62/4lbozxgHQt1/f9PBhjMV6yV906zBl4HID84nueM=; b=FKtorwh/xAIU7OlEtG44HVkHDYSPl36MCrFNgYQhm20URHOXYoUKAdE0Y7qDZKINMC pDQGeu3WJoxRCIaBvaSpxM8lYJAfvcGrXawu/ucFL/E+FMsG1Opx0qsGWKDgYMurnpx0 QHehoYLivvJRjkw+5vKg2pGYGArKTE5pCokUn+rRoO8ZcRX+wj3w/X/BMzwin77UlRVR qHRHuh2By5xOsCh+FL1BnHOFpLD8ukwaBksA5M9EYF+H8fXlNq9gqdqNBJVeFT/Ujfzt ZueR1qq7pEHVDB9ADadYsRSlgA1QHKQaArb/hUgioESWb+exKsMKzto7MpUAETBVe2j6 S9iA== X-Received: by 10.182.120.3 with SMTP id ky3mr24826360obb.33.1425978872595; Tue, 10 Mar 2015 02:14:32 -0700 (PDT) MIME-Version: 1.0 References: <20150309235642.2282.21343.idtracker@ietfa.amsl.com> In-Reply-To: From: Mahesh Jethanandani Date: Tue, 10 Mar 2015 09:14:31 +0000 Message-ID: To: Kent Watsen , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=089e01229de0288c8c0510eb94dd Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-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: Tue, 10 Mar 2015 09:14:36 -0000 --089e01229de0288c8c0510eb94dd Content-Type: text/plain; charset=UTF-8 Kent, Thanks for posting the draft. First, one minor nit. 2.2 Point 6 s/This This/This/ Point 7. I am confused about "in addition to those the device knows of by default". I thought Bootstrap servers are either learnt through DHCP (via its BOOTP extensions) or explicitly configured. If you are referring to configured Bootstrap servers, then I guess they are not "default". Could the certificate be issued/signed by the owner of the device or does it have to be signed/issued by the vendor only? In container boot-image you talk about a signature leaf. It is the first time you are talking about how the signature is being constructed. Could you mention this up front in your document when you talk about Bootstrap servers and how those images are being signed? Section 4.2 NIt. s/Following are the actions performed by the device when bootstrap off/Following are the actions performed by the device when bootstraping off/ Step 5 in that section. The check is really for whether the boot image is new/different from the one currently running. Can you update the text to reflect that? 5. Need to install boot image? ------> Install and reboot Section 5.2. Point 3. Login credentials. Can you clarify this sentence "These credentials may be, for instance, a private key used for SSH or TLS client authentication." Specifically, how are login credentials established when doing TLS client authentication. Section 5.3. s/NSM/NMS/ Thanks. On Mon, Mar 9, 2015 at 5:18 PM Kent Watsen wrote: > > Hey all, > > If interested in zero touch, please take notice of this update! Changes > include: > > o Renamed Configuration Server to Bootstrap Server, a more > representative name given the information devices download > from it. > > o Replaced the concept of a Configlet, by defining a southbound > interface for the Bootstrap Server using YANG. This also nicely > removes the need to support XMLSIG. > > o Removed the IANA request for the boot-image and configuration > media types, as the Bootstrap server's southbound interface > > has explicit resources for each, and then some. > > Hoping to receive comments on list or in Dallas! > > Cheers, > Kent > > > On 3/9/15, 7:56 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 > > Joe Clarke > > Mikael Abrahamsson > > Filename : draft-ietf-netconf-zerotouch-02.txt > > Pages : 31 > > Date : 2015-03-09 > > > >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 its rightful 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-02 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-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 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --089e01229de0288c8c0510eb94dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kent,

Thanks for posting the draft.

First, one mi= nor nit.

2.2 Point 6 s/This This/This/

Point 7. I am confused about "in addition to those=C2=A0the device kno= ws of by default". I thought Bootstrap servers are either learn= t through DHCP (via its BOOTP extensions) or explicitly configured. If you = are referring to configured Bootstrap servers, then I guess they are not &q= uot;default".

Could the certificate be issued= /signed by the owner of the device or does it have to be signed/issued by t= he vendor only?

In container boot-imag= e you talk about a signature leaf. It is the first time you are talking abo= ut how the signature is being constructed. Could you mention this up front = in your document when you talk about Bootstrap servers and how those images= are being signed?

Section 4.2 NIt. s/Following are the ac= tions performed by the device when bootstrap off/Following are the actions pe= rformed by the device when bootstraping off/

Step 5 = in that section. The check is really for whether the boot image is new/diff= erent from the one currently running. Can you update the text to reflect th= at?=C2=A0
 5. Nee=
d to install boot image?  ------> Install and reboot

Section 5.2. Point =
3. Login credentials. Can you clarify this sentence "These credentials may be, for instance, =
a private key used for SSH or TLS client authenti=
cation." Specifically, how are login credentials established when doin=
g TLS client authentication.

Section 5.3. s/NSM/NMS/

Thanks.
<= br>
On Mon, Mar 9, 2015 at 5:18 PM Kent Watsen &l= t;kwatsen@juniper.net> wrote:=

Hey all,

If interested in zero touch, please take notice of this update!=C2=A0 Chang= es
include:

=C2=A0 =C2=A0o=C2=A0 Renamed Configuration Server to Bootstrap Server, a mo= re
=C2=A0 =C2=A0 =C2=A0 representative name given the information devices down= load
=C2=A0 =C2=A0 =C2=A0 from it.

=C2=A0 =C2=A0o=C2=A0 Replaced the concept of a Configlet, by defining a sou= thbound
=C2=A0 =C2=A0 =C2=A0 interface for the Bootstrap Server using YANG. This al= so nicely
=C2=A0 =C2=A0 =C2=A0 removes the need to support XMLSIG.

=C2=A0 =C2=A0o=C2=A0 Removed the IANA request for the boot-image and config= uration
=C2=A0 =C2=A0 =C2=A0 media types, as the Bootstrap server's southbound = interface

=C2=A0 =C2=A0 =C2=A0 has explicit resources for each, and then some.

Hoping to receive comments on list or in Dallas!

Cheers,
Kent


On 3/9/15, 7:56 PM, "internet-drafts@ietf.org" <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 o= f
>the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Zero Touch Provisioning for NETCONF Call Home
>(ZeroTouch)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Kent Watsen
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Joe Clarke
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Mikael Abrahamsson
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-netconf-zerotouch-02.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 31
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2015-03-09
>
>Abstract:
>=C2=A0 =C2=A0This draft presents a technique for establishing a secure = NETCONF
>=C2=A0 =C2=A0connection between a newly deployed IP-based device, confi= gured with
>=C2=A0 =C2=A0just its factory default settings, and its rightful owner&= #39;s network
>=C2=A0 =C2=A0management system (NMS).
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ne= tconf-zerotouch/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-netconf-zero= touch-02
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-netconf-zerotouch-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<= /a>
>https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--089e01229de0288c8c0510eb94dd-- From nobody Tue Mar 10 02:27:19 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 01A461A88B0; Mon, 9 Mar 2015 05:36:38 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5E1A88AD for ; Mon, 9 Mar 2015 05:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 rVXs6MnTh92Z for ; Mon, 9 Mar 2015 05:36:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D101A7034 for ; Mon, 9 Mar 2015 05:36:35 -0700 (PDT) Received: from mail.painless-security.com ([23.30.188.241]:38605) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YUwvC-0000FQ-HE for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Mon, 09 Mar 2015 05:36:34 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 36CB120655; Mon, 9 Mar 2015 08:09:24 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5YmM7uykHrU; Mon, 9 Mar 2015 08:09:23 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 9 Mar 2015 08:09:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A3BD80430; Mon, 9 Mar 2015 08:10:24 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org,secdir@ietf.org,iesg@ietf.org Date: Mon, 09 Mar 2015 08:10:24 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SA-Exim-Connect-IP: 23.30.188.241 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: hartmans@mit.edu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150309123638.05D101A7034@ietfa.amsl.com> Resent-Date: Mon, 9 Mar 2015 05:36:35 -0700 (PDT) Resent-From: hartmans@mit.edu Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 10 Mar 2015 02:27:18 -0700 Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: [Netconf] Secdir Review of draft-ietf-netconf-rfc5539bis-09 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, 09 Mar 2015 12:36:39 -0000 This is an update to netconf over TLS with mutual X.509 authentication. In general, this looks fairly good. I'd ask the security ADs to take a look at two things: * The text on certificate validation in section 5. Certificate validation has a number of options, none of which are described or specified in this text. Is that good enough for this application? (Probably) In section 7, there is a description of how the netconf server finds the username of the client. It talks about a certificate fingerprint without a reference to a specific algorithm. I'm aware of multiple algorithms for fingerprints. This text is probably too vague for interoperability. From nobody Tue Mar 10 04:25:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92071A878B for ; Tue, 10 Mar 2015 04:25:36 -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 fWbJWQfYF_MG for ; Tue, 10 Mar 2015 04:25:34 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C161A00CF for ; Tue, 10 Mar 2015 04:25:34 -0700 (PDT) X-AuditID: c1b4fb25-f79b76d00000113a-2c-54fed4acc384 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 57.02.04410.CA4DEF45; Tue, 10 Mar 2015 12:25:32 +0100 (CET) Received: from [159.107.197.215] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.210.2; Tue, 10 Mar 2015 12:25:31 +0100 Message-ID: <54FED4AB.1070107@ericsson.com> Date: Tue, 10 Mar 2015 12:25:31 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvje6aK/9CDE4+lrWYuuk2qwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mvqa7rIWvGapeDrvL2MD4y7mLkZODgkBE4k1bw8wQthiEhfu rWfrYuTiEBI4wiix9cZrJghnLaPEm8dL2EGqeAW0JS6tOAnWzSKgKtG+9hcbiM0mYCQxtf88 C4gtKhAl0fOnmw2iXlDi5MwnYHERAU2JxlkfWEFsYYEUibndq8FsZgELiZnzzzNC2PIS29/O AZsvJKAh8fDCX9YJjHyzkIyahaRlFpKWBYzMqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjEC g+rglt+qOxgvv3E8xCjAwajEw2sQ9y9EiDWxrLgy9xCjNAeLkjivnfGhECGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MrhM5VO0SeLVZ2FXsYyufL3Q94LsjY8ei1leLyhbE/drl+OHsokJx FetXB2wf67ul/2j8IBSXKKB0oqvZoc75t2nqVCkrjpq519lMWvjO+C6Z/7pJqujCO9320ocy F2M4HubEzDwcN3O/PuPknAfT9/pOPLt4+WTbF7YNQXqxh3cVPKhTiLVVYinOSDTUYi4qTgQA bWo0LAsCAAA= Archived-At: Subject: [Netconf] Multiple operations on the same datastore item in a single - Is it allowed? 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, 10 Mar 2015 11:25:37 -0000 Hello, Is it allowed to edit a specific place of the model tree more then once in a single edit config operation? E.g. create a list-entry and then replace part of it. 1 1 and later in the same operation 1 2 regards Balazs -- 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 Mar 10 04:49:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2B21A87B8; Tue, 10 Mar 2015 04:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iuML88tOdfJH; Tue, 10 Mar 2015 04:49:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DD2C11A8784; Tue, 10 Mar 2015 04:49:19 -0700 (PDT) Received: from localhost (173-38-208-170.cisco.com [173.38.208.170]) by mail.tail-f.com (Postfix) with ESMTPSA id C5D0D1280984; Tue, 10 Mar 2015 12:49:18 +0100 (CET) Date: Tue, 10 Mar 2015 12:49:18 +0100 (CET) Message-Id: <20150310.124918.1580857159128244873.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <54FED4E9.5080503@ericsson.com> References: <54FED4E9.5080503@ericsson.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: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 10 Mar 2015 11:49:21 -0000 Hi, This is a protocol issue. I am sending the reply to netconf as well. New replies should remove netmod from cc. Balazs Lengyel wrote: > Hello, > Is it possible to change a list entry's key or keys without deleting > and re-creating the entry. Can the replace operation be applied > somehow on key leafs? No. This is an side-effect of the way edit-config works, where the identification of *what* is changed it mixed with *how* to change it. > I only found this in the mailing list: > http://www.ietf.org/mail-archive/web/netmod/current/msg01194.html > " > > No, you are right, this is what Sec. 7.8.6 says. The edit-config > operations (including default-operation) probably must not be applied > to > keys in any way. But it also means there is no way for changing values > of leafs that happen to be part of the key. The last sentence says the same. /martin From nobody Tue Mar 10 05:03:10 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319611A87BB for ; Tue, 10 Mar 2015 05:03:09 -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 2vm1K1yp_5VX for ; Tue, 10 Mar 2015 05:03:07 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8421A8784 for ; Tue, 10 Mar 2015 05:03:06 -0700 (PDT) X-AuditID: c1b4fb3a-f79036d000001e94-06-54fedd78e0fd Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1B.90.07828.87DDEF45; Tue, 10 Mar 2015 13:03:05 +0100 (CET) Received: from [159.107.197.215] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.210.2; Tue, 10 Mar 2015 13:03:04 +0100 Message-ID: <54FEDD78.4000209@ericsson.com> Date: Tue, 10 Mar 2015 13:03:04 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Bjorklund References: <54FED4E9.5080503@ericsson.com> <20150310.124918.1580857159128244873.mbj@tail-f.com> In-Reply-To: <20150310.124918.1580857159128244873.mbj@tail-f.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+JvjW7l3X8hBr/n8Vl0dz9jt5i66Tar A5PHkiU/mTw2/lrMEsAUxWWTkpqTWZZapG+XwJXxefcKxoI+3orNe6+zNjB2cXUxcnBICJhI rHxb3MXICWSKSVy4t56ti5GLQ0jgCKPE33OPmCGctYwSVyZeYgWp4hXQlti6awcTiM0ioCqx qeMiG4jNJmAkMbX/PAuILSoQJdHzp5sNol5Q4uTMJ2BxEaD6JzvXsoAsZgbatu6lO0hYWMBN YvqZbrDxQgIJEv9ObQVr5RRwlNjx/zwrRLm9xIOtZSBhZgF5ie1v5zBDlGtIPLzwl3UCo+As JMtmIXTMQtKxgJF5FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgoB7c8ttqB+PB546HGAU4 GJV4eA3i/oUIsSaWFVfmHmKU5mBREue1Mz4UIiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR x/m45sncCaFXlJZGCAmG8i7fai6j/OtIyUZ9k6V58z/7xKSHPXQ9I/n5UKKjsfW7TWJXbaQy 1/7cIOwiIpoYUVqleWGeycTDko933vHer7jcZ7U7l/jZxqDEoA5v/ysT/TgY9pSaaNq1K4ZN iXm6dfL73fc4Ve4qnPpzwnbDyzufOF00w0qVWIozEg21mIuKEwHjPkc3NQIAAA== Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 10 Mar 2015 12:03:09 -0000 Hello, And is possible to change an existing list entry's key in restconf? As I understand yes. If I am right, I am not happy. IMHO the property whether or not a key of an existing list entry can be changed, should be decided by the data modeling language (YANG) not the protocol used. So either make it changeable on all protocols or none. The node itself or some NMS might depend on the keys being unchangeable. regards Balazs On 2015-03-10 12:49, Martin Bjorklund wrote: > Hi, > > This is a protocol issue. I am sending the reply to netconf as well. > New replies should remove netmod from cc. > > Balazs Lengyel wrote: >> Hello, >> Is it possible to change a list entry's key or keys without deleting >> and re-creating the entry. Can the replace operation be applied >> somehow on key leafs? > No. This is an side-effect of the way edit-config works, where the > identification of *what* is changed it mixed with *how* to change it. > >> I only found this in the mailing list: >> http://www.ietf.org/mail-archive/web/netmod/current/msg01194.html >> " >> >> No, you are right, this is what Sec. 7.8.6 says. The edit-config >> operations (including default-operation) probably must not be applied >> to >> keys in any way. But it also means there is no way for changing values >> of leafs that happen to be part of the key. > The last sentence says the same. > > > /martin > > -- 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 Mar 10 05:21:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2845D1ACD20 for ; Tue, 10 Mar 2015 05:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 WlU_ed9yb2NA for ; Tue, 10 Mar 2015 05:21:37 -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 723221ACD70 for ; Tue, 10 Mar 2015 05:21: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 209D1FB5; Tue, 10 Mar 2015 13:21:25 +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 i2IZKN7jNT7v; Tue, 10 Mar 2015 13:21:17 +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; Tue, 10 Mar 2015 13:21:24 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 601EA2003D; Tue, 10 Mar 2015 13:21:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UNPwMeRTnxVR; Tue, 10 Mar 2015 13:21:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A0CE2003C; Tue, 10 Mar 2015 13:21:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D1B543275E17; Tue, 10 Mar 2015 13:21:20 +0100 (CET) Date: Tue, 10 Mar 2015 13:21:19 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20150310122119.GA6894@elstar.local> Mail-Followup-To: Balazs Lengyel , Martin Bjorklund , netconf@ietf.org References: <54FED4E9.5080503@ericsson.com> <20150310.124918.1580857159128244873.mbj@tail-f.com> <54FEDD78.4000209@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FEDD78.4000209@ericsson.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 10 Mar 2015 12:21:39 -0000 On Tue, Mar 10, 2015 at 01:03:04PM +0100, Balazs Lengyel wrote: > Hello, > And is possible to change an existing list entry's key in restconf? As I > understand yes. > > If I am right, I am not happy. IMHO the property whether or not a key of > an existing list entry can be changed, should be decided by the data > modeling language (YANG) not the protocol used. So either make it > changeable on all protocols or none. The node itself or some NMS might > depend on the keys being unchangeable. What does it mean for a key to be 'unchangeable'? I can delete a list entry and subsequently I create it again with a different name. And this would not be allowed? /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 Mar 10 17:08:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE52B1A8940 for ; Tue, 10 Mar 2015 17:08: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, 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 bufiYS_C2iAy for ; Tue, 10 Mar 2015 17:08:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4859E1A884C for ; Tue, 10 Mar 2015 17:08:29 -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.1.99.14; Wed, 11 Mar 2015 00:08:06 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) with mapi id 15.01.0099.004; Wed, 11 Mar 2015 00:08:06 +0000 From: Kent Watsen To: Mahesh Jethanandani , "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-02.txt Thread-Index: AQHQWsTnpDmelIemEE+1r4CjGCwXkp0UltQAgADY3YCAALaegA== Date: Wed, 11 Mar 2015 00:08:06 +0000 Message-ID: References: <20150309235642.2282.21343.idtracker@ietfa.amsl.com> 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-originating-ip: [66.129.239.11] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(230783001)(66066001)(76176999)(107886001)(87936001)(54356999)(50986999)(46102003)(92566002)(2501003)(122556002)(77156002)(86362001)(40100003)(83506001)(62966003)(99286002)(106116001)(102836002)(2900100001)(2950100001)(36756003)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5001009); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 00:08:06.2361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-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, 11 Mar 2015 00:08:35 -0000 Hi Mahesh, Thank you for your review. My replies to your comments are below. [Mahesh] Point 7. I am confused about "in addition to those the device knows of by default". I thought Bootstrap servers are either learnt through DHCP (via its BOOTP extensions) or explicitly configured. If you are referring to configured Bootstrap servers, then I guess they are not "default". [KENT] I guess it needs some word-smithing, as it is meant to be as you say. =20 [Mahesh] Could the certificate be issued/signed by the owner of the device or does it have to be signed/issued by the vendor only? [KENT] This is what this solution requires in order for the device to authenticate that the configuration was prepared by its rightful owner. To support an owner-signed certificate, the device would have to be manufactured with an owner-specific trust-anchor (e.g., custom SKUs) - I don't think we want to propose that here, do you? [Mahesh] In container boot-image you talk about a signature leaf. It is the first time you are talking about how the signature is being constructed. Could you mention this up front in your document when you talk about Bootstrap servers and how those images are being signed? [Kent] good catch. I'm aware that I left that undefined in my rush to get it out the door. It is a detail that can be filled-in in the next update. [Mahesh] Step 5 in that section. The check is really for whether the boot image is new/different from the one currently running. Can you update the text to reflect that? 5. Need to install boot image? ------> Install and reboot [Kent] will do [Mahesh] Section 5.2. Point 3. Login credentials. Can you clarify this sentence "These credentials may be, for instance, a private key used for SSH or TLS client authentication." Specifically, how are login credentials established when doing TLS client authentication. [Kent] the next line says "It is expected that a device is able to authenticate the NMS's credentials by virtue of the configuration it downloads from the Bootstrap Server." and appendix A.3. provides an example bootstrap configuration , which sets the ssh-key for the admin user account. This is akin to placing your ssh public key into a remote system's ~/.ssh/authorized_keys file - makes sense? Thanks, Kent From nobody Wed Mar 11 00:08:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7821A8F33; Wed, 11 Mar 2015 00:08:48 -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 zsLAM5H5YKze; Wed, 11 Mar 2015 00:08:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B25BB1A8FD4; Wed, 11 Mar 2015 00:08:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311070847.3332.23025.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 00:08:47 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [Netconf] Last Call Expired: 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, 11 Mar 2015 07:08:49 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Wed Mar 11 01:05:25 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E8F1A8AF9 for ; Wed, 11 Mar 2015 01:05:24 -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 t7spgFEo52Qq for ; Wed, 11 Mar 2015 01:05:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781BE1AC3F9 for ; Wed, 11 Mar 2015 01:05:21 -0700 (PDT) X-AuditID: c1b4fb25-f79b76d00000113a-58-54fff73f3b05 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.28.04410.F37FFF45; Wed, 11 Mar 2015 09:05:20 +0100 (CET) Received: from [159.107.196.219] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.210.2; Wed, 11 Mar 2015 09:05:19 +0100 Message-ID: <54FFF73F.3080100@ericsson.com> Date: Wed, 11 Mar 2015 09:05:19 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Bjorklund , , Juergen Schoenwaelder References: <54FED4E9.5080503@ericsson.com> <20150310.124918.1580857159128244873.mbj@tail-f.com> <54FEDD78.4000209@ericsson.com> <20150310122119.GA6894@elstar.local> In-Reply-To: <20150310122119.GA6894@elstar.local> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvja7D9/8hBvf3cFlc3fiT0aK7+xm7 xdRNt1kdmD2WLPnJ5LHhgKfHxl+LWQKYo7hsUlJzMstSi/TtErgy+je0shYc56/4ska/gfEP dxcjJ4eEgInErMk/2SFsMYkL99azdTFycQgJHGGUmPPrGDuEs5ZR4si754wgVbwC2hIH1u5m A7FZBFQlpr77yAxiswkYSUztP88CYosKREn0/Olmg6gXlDg58wlYXESgUqL9+FWwuLBAgMTs BZ9YIRYsZZR48Pck2BmcAoYSWyf1AjVwcDAL2Es82FoGEmYWkJfY/nYO2C4hAQ2Jhxf+sk5g FJiFZMUshI5ZSDoWMDKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAgM04NbfqvuYLz8xvEQ owAHoxIP74b1/0OEWBPLiitzDzFKc7AoifPaGR8KERJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cDY0fSt8iN3+vn99V7mOx8o3ZM1OJZV/a1X/vGMxJ2P717Qv9Ag2Z8kZeldUaY9Jfe+R6uF Y4HaWY6Hetxxf8L69heK5HlNYlG5t4dvxd+7W3641od9lFwfXDC7ZFcNw/S1OWksVlUTdXxe rN5oMp3XoUrHa+Xna92b3sm7zAv6YsDunqzyeoISS3FGoqEWc1FxIgDRRWQANAIAAA== Archived-At: Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 11 Mar 2015 08:05:24 -0000 Hello Jurgen, In a number of (our) systems there is a difference between updating a leaf or deleting a list entry and recreating it with mostly the same content, but one changed leaf. E.g. the keys identify an interface. The interface might have alarms, log entries, counter values connected to it. If you remove it, many of these alarms/log/etc. are removed as they no longer belong to an existing object. When you recreate it, the alarms, logs, the history is already lost. Also if the object/entry is removed that in some cases results in a restart to the object represented by the list entry e.g. an interface, which means traffic disturbance. So while deleting and recreating a list-entry is always allowed, it is important whether just changing the key is allowed or not? And I still believe it should be YANG that decides whether just changing a key for an existing list entry is allowed or not. This is a modeling question not a protocol question. regards Balazs On 2015-03-10 13:21, Juergen Schoenwaelder wrote: > On Tue, Mar 10, 2015 at 01:03:04PM +0100, Balazs Lengyel wrote: >> Hello, >> And is possible to change an existing list entry's key in restconf? As I >> understand yes. >> >> If I am right, I am not happy. IMHO the property whether or not a key of >> an existing list entry can be changed, should be decided by the data >> modeling language (YANG) not the protocol used. So either make it >> changeable on all protocols or none. The node itself or some NMS might >> depend on the keys being unchangeable. > What does it mean for a key to be 'unchangeable'? I can delete a list > entry and subsequently I create it again with a different name. And > this would not be allowed? > > /js > -- 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 Wed Mar 11 01:54:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4A1AC427 for ; Wed, 11 Mar 2015 01:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dkKwnLxm2JaJ for ; Wed, 11 Mar 2015 01:54:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4601AC41F for ; Wed, 11 Mar 2015 01:54:44 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B2EF1280984; Wed, 11 Mar 2015 09:18:27 +0100 (CET) Date: Wed, 11 Mar 2015 09:18:27 +0100 (CET) Message-Id: <20150311.091827.1554874591214682114.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <54FEDD78.4000209@ericsson.com> References: <54FED4E9.5080503@ericsson.com> <20150310.124918.1580857159128244873.mbj@tail-f.com> <54FEDD78.4000209@ericsson.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: Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 11 Mar 2015 08:54:45 -0000 Balazs Lengyel wrote: > Hello, > And is possible to change an existing list entry's key in restconf? As > I understand yes. > > If I am right, I am not happy. IMHO the property whether or not a key > of an existing list entry can be changed, should be decided by the > data modeling language (YANG) not the protocol used. I disagree. Different protocols can have different mechanisms to do things. A very simple protocol for constrained devices might only support replacing the entire config. Should they have to invent their own modelling language because of this? I don't think that would be a good idea. Maybe NETCONF 2.0 supports renaming of instances. Should we then invent a new modelling language as well? /martin From nobody Wed Mar 11 01:55:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9271AC425 for ; Wed, 11 Mar 2015 01:54:58 -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 6qyijPdS8D2K for ; Wed, 11 Mar 2015 01:54:56 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99EF1AC429 for ; Wed, 11 Mar 2015 01:54:54 -0700 (PDT) X-AuditID: c1b4fb3a-f79036d000001e94-78-550002dc509e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4B.47.07828.CD200055; Wed, 11 Mar 2015 09:54:52 +0100 (CET) Received: from [159.107.196.219] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.210.2; Wed, 11 Mar 2015 09:54:52 +0100 Message-ID: <550002DB.7050004@ericsson.com> Date: Wed, 11 Mar 2015 09:54:51 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Bjorklund References: <54FED4E9.5080503@ericsson.com> <20150310.124918.1580857159128244873.mbj@tail-f.com> <54FEDD78.4000209@ericsson.com> <20150311.091827.1554874591214682114.mbj@tail-f.com> In-Reply-To: <20150311.091827.1554874591214682114.mbj@tail-f.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvje4dJoZQg5dz9C26u5+xW0zddJvV gcljyZKfTB4bfy1mCWCK4rJJSc3JLEst0rdL4MqYc2sNU8Fbvoop3TNZGhj3cHcxcnBICJhI fPzo3sXICWSKSVy4t54NxBYSOMIocf2baxcjF5C9llGipWsKC0iCV0BbYumKP8wgNouAqsSF 6zvAGtgEjCSm9p8HqxEViJLo+dPNBlEvKHFy5hOwuAhQ/ZOda1lA9jIDLVv3EmyvsICbxPQz 3awQu7YySpyb3gPWyyngKNE45wgjRL29xIOtZSBhZgF5ie1v5zBD3Kkh8fDCX9YJjIKzkGyb hdAxC0nHAkbmVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBgXpwy2+rHYwHnzseYhTgYFTi 4d2w/n+IEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY3Tq0 GFp5db9+7xDpE0lqiavKrcz2OKrJe+p1udBnzb/dvcZrZa115EL332D6KljmYNB69aZQT+ij 8xaa91pS29OfhbQL5t97G/rt0i271pd1L3k23ec8JHmouZdvUkfrSeeq/rZmIXZNpQiVg1+F 1kmme129yjJ9afGv3aosqdJzTYxa85RYijMSDbWYi4oTAY1Nhlo1AgAA Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 11 Mar 2015 08:54:58 -0000 Hello Martin, As keys are used to identify things ( objects, leaf entries, big subbranches of the model) this is a special case. It is not just any other attribute. A good parallel could be: are you allowed to change the namespace/module name for a YANG module? It is part of what identifies that tree branch and no one wants to change that, although I could design a protocol mechanism to acomplish it. Yes constrained devices might constrain the protocol, but they should never allow changing something that the model says is unchangeable, e.g. write to a read-only leaf. So the question becomes:, is it allowed to change items like keys that are used to address things YES/NO. IMHO this is for YANG to decide. (E.g. Netconf or SNMP does not allow it and I am happy with that.) regards Balazs On 2015-03-11 09:18, Martin Bjorklund wrote: > Balazs Lengyel wrote: >> Hello, >> And is possible to change an existing list entry's key in restconf? As >> I understand yes. >> >> If I am right, I am not happy. IMHO the property whether or not a key >> of an existing list entry can be changed, should be decided by the >> data modeling language (YANG) not the protocol used. > I disagree. Different protocols can have different mechanisms to do > things. A very simple protocol for constrained devices might only > support replacing the entire config. Should they have to invent their > own modelling language because of this? I don't think that would be a > good idea. Maybe NETCONF 2.0 supports renaming of instances. Should > we then invent a new modelling language as well? > > > /martin > > -- 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 Wed Mar 11 02:01:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D761AC431 for ; Wed, 11 Mar 2015 02:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wqfvS4YvEY6b for ; Wed, 11 Mar 2015 02:01:36 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 87EB21AC429 for ; Wed, 11 Mar 2015 02:01:35 -0700 (PDT) Received: from localhost (173-38-208-170.cisco.com [173.38.208.170]) by mail.tail-f.com (Postfix) with ESMTPSA id 7CF621280984; Wed, 11 Mar 2015 10:01:34 +0100 (CET) Date: Wed, 11 Mar 2015 10:01:33 +0100 (CET) Message-Id: <20150311.100133.1816671526870235988.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <550002DB.7050004@ericsson.com> References: <54FEDD78.4000209@ericsson.com> <20150311.091827.1554874591214682114.mbj@tail-f.com> <550002DB.7050004@ericsson.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: Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 11 Mar 2015 09:01:39 -0000 Balazs Lengyel wrote: > Hello Martin, > As keys are used to identify things ( objects, leaf entries, big > subbranches of the model) this is a special case. It is not just any > other attribute. > A good parallel could be: are you allowed to change the > namespace/module name for a YANG module? It is part of what identifies > that tree branch and no one wants to change that, although I could > design a protocol mechanism to acomplish it. > > Yes constrained devices might constrain the protocol, but they should > never allow changing something that the model says is unchangeable, > e.g. write to a read-only leaf. > So the question becomes:, is it allowed to change items like keys that > are used to address things YES/NO. IMHO this is for YANG to > decide. (E.g. Netconf or SNMP does not allow it and I am happy with > that.) YANG stipulates that the keys are used to identifiy instances. If you change the key values of an instance you effectively get a new instance. A "rename" operation would do this; and this is the same as reading the whole instance, delete it, create a new one with new key values. There is no explicit operation to do this in NETCONF, but you can get the same effect with delete/create. If some other protocol had this a builtin that would be fine too. /martin > > regards Balazs > > On 2015-03-11 09:18, Martin Bjorklund wrote: > > Balazs Lengyel wrote: > >> Hello, > >> And is possible to change an existing list entry's key in restconf? As > >> I understand yes. > >> > >> If I am right, I am not happy. IMHO the property whether or not a key > >> of an existing list entry can be changed, should be decided by the > >> data modeling language (YANG) not the protocol used. > > I disagree. Different protocols can have different mechanisms to do > > things. A very simple protocol for constrained devices might only > > support replacing the entire config. Should they have to invent their > > own modelling language because of this? I don't think that would be a > > good idea. Maybe NETCONF 2.0 supports renaming of instances. Should > > we then invent a new modelling language as well? > > > > > > /martin > > > > > > -- > 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 Wed Mar 11 02:07:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B03C1A6F3C for ; Wed, 11 Mar 2015 02:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 IL2xOppI_dar for ; Wed, 11 Mar 2015 02:07:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id BD0C71A1A7D for ; Wed, 11 Mar 2015 02:07:56 -0700 (PDT) Received: from [10.148.226.151] (unknown [10.148.226.151]) by mail.tail-f.com (Postfix) with ESMTPSA id E6F1B1280984; Wed, 11 Mar 2015 10:07:55 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_50430DDB-FD44-45CB-AC75-28439294DAA6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Jan Lindblad In-Reply-To: <20150311.100133.1816671526870235988.mbj@tail-f.com> Date: Wed, 11 Mar 2015 10:06:55 +0100 Message-Id: <07E41A08-847D-4A14-94FA-8556D73AC83C@tail-f.com> References: <54FEDD78.4000209@ericsson.com> <20150311.091827.1554874591214682114.mbj@tail-f.com> <550002DB.7050004@ericsson.com> <20150311.100133.1816671526870235988.mbj@tail-f.com> To: balazs.lengyel@ericsson.com X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 11 Mar 2015 09:07:58 -0000 --Apple-Mail=_50430DDB-FD44-45CB-AC75-28439294DAA6 Content-Type: multipart/alternative; boundary="Apple-Mail=_38DE8FA9-BC24-4DA2-A4A4-B4F660EA9649" --Apple-Mail=_38DE8FA9-BC24-4DA2-A4A4-B4F660EA9649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Balazs, > YANG stipulates that the keys are used to identifiy instances. If you > change the key values of an instance you effectively get a new > instance. A "rename" operation would do this; and this is the same as > reading the whole instance, delete it, create a new one with new key > values. There is no explicit operation to do this in NETCONF, but you > can get the same effect with delete/create. If some other protocol > had this a builtin that would be fine too. You can model your own =E2=80=9Crename=E2=80=9D or =E2=80=9Cmove=E2=80=9D = RPC that does the move if you need particular semantics. /jan --Apple-Mail=_38DE8FA9-BC24-4DA2-A4A4-B4F660EA9649 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Balazs,

YANG stipulates that the keys = are used to identifiy instances.  If you
change the key values of an = instance you effectively get a new
instance.  A "rename" = operation would do this; and this is the same as
reading the whole instance, = delete it, create a new one with new key
values.  There is no = explicit operation to do this in NETCONF, but you
can get the same effect with = delete/create.  If some other protocol
had this a builtin that would be = fine too.

You can = model your own =E2=80=9Crename=E2=80=9D or =E2=80=9Cmove=E2=80=9D RPC = that does the move if you need particular semantics.

/jan

= --Apple-Mail=_38DE8FA9-BC24-4DA2-A4A4-B4F660EA9649-- --Apple-Mail=_50430DDB-FD44-45CB-AC75-28439294DAA6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVAAWvAAoJEBSCnbqufIisevcH/jiqobvufbUwIo905YBeLDkK aYdb18v3dN6oizjsA1l7NapxUCeE1totuKmORA1dW3Kuu/xJtVMuewSSJVTXCstD VfMw3jVDRHHSR304kN+KK5jKKeDjYAW7CcHR1iL6/ROiIoANTOvKqYwRZxViK/aq d6VvfAE/BUncKeaxEFqP4mG2bKmAVsqHvEUL/mGvJmlddfxGThEg5a0+PSYof/SV 2t9Ze2DmeJZO80Kdk+hme9zRNdE1PpgJ2vC1M8tOuR8IDdt/1+DPOk5ZeETbA6Is KR/JJ8084J00iwlRav1p0vZHGBHGbMwQW6L63njs1+NXnZVU3Qy79/a/t+OGlJo= =BNzW -----END PGP SIGNATURE----- --Apple-Mail=_50430DDB-FD44-45CB-AC75-28439294DAA6-- From nobody Wed Mar 11 02:43:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD8A1A8A74 for ; Wed, 11 Mar 2015 02:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 UfVxWk7-XVG6 for ; Wed, 11 Mar 2015 02:43:38 -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 C22981AC429 for ; Wed, 11 Mar 2015 02:43:36 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:15b5:fddf:7083:505] (unknown [IPv6:2001:718:1a02:1:15b5:fddf:7083:505]) by mail.nic.cz (Postfix) with ESMTPSA id 4325413F8A7; Wed, 11 Mar 2015 10:43:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1426067014; bh=VqyQpT2QC6ukX4oQ+NtgIwACBkwnSvFbd8b0kF9nzro=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZNTU2rMiWEgyzMcZ/P2ogKdcx+9BKUwiN8jt29zDLVStqCK1U3ofL52ryNEbhr6Ga GiIa+VXfAcS45WxoXzYa2EMHOfmyD2tVTqOtWXfF29bQ7TnX4Sr1nUPtEXy0xlbVzd nVp0wLaToVbUhzBAXskUUBs4qDOGL2CMGKvDeevg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150311.091827.1554874591214682114.mbj@tail-f.com> Date: Wed, 11 Mar 2015 10:43:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <77531C88-DA70-4DB3-9186-5D636CDF6DCD@nic.cz> References: <54FED4E9.5080503@ericsson.com> <20150310.124918.1580857159128244873.mbj@tail-f.com> <54FEDD78.4000209@ericsson.com> <20150311.091827.1554874591214682114.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys? 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, 11 Mar 2015 09:43:39 -0000 > On 11 Mar 2015, at 09:18, Martin Bjorklund wrote: >=20 > Balazs Lengyel wrote: >> Hello, >> And is possible to change an existing list entry's key in restconf? = As >> I understand yes. >>=20 >> If I am right, I am not happy. IMHO the property whether or not a key >> of an existing list entry can be changed, should be decided by the >> data modeling language (YANG) not the protocol used. >=20 > I disagree. Different protocols can have different mechanisms to do > things. A very simple protocol for constrained devices might only > support replacing the entire config. Should they have to invent their > own modelling language because of this? I don't think that would be a > good idea. Maybe NETCONF 2.0 supports renaming of instances. Should > we then invent a new modelling language as well? >=20 I agree with Martin, in fact I think we should strive for making YANG = *less* dependent on management protocols. And I do find the design of = =E2=80=98edit-config=E2=80=99 in this respect rather peculiar. Robust management applications should be prepared to deal with e.g. = interfaces being renamed at run time because that=E2=80=99s a fact of = life. Lada >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 11 04:49:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786BF1A8886 for ; Wed, 11 Mar 2015 04:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=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 6Mp2ckA37A0L for ; Wed, 11 Mar 2015 04:48:55 -0700 (PDT) Received: from webmail3.hi.local (www.outitgoes.com [79.170.40.67]) (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 3C9331A8885 for ; Wed, 11 Mar 2015 04:48:55 -0700 (PDT) Received: from localhost ([127.0.0.1]) by webmail3.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YVf88-0006rr-6e for netconf@ietf.org; Wed, 11 Mar 2015 11:48:52 +0000 Message-Id: <6c4a8c42791ae4c8922cfd6404a10982a650e8ce@webmail.hansfords.net> From: "Jonathan Hansford" To: netconf@ietf.org X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 10.0.1.196 in-reply-to: Date: Wed, 11 Mar 2015 11:48:52 +0000 Content-Type: multipart/alternative; boundary="=_972732028c296ed4e537fc6fd4e073aa" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 11 Mar 2015 11:48:57 -0000 --=_972732028c296ed4e537fc6fd4e073aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RESTCONF provides a "Simple Subset of NETCONF Functionality",=0Aexcludin= g locking, validation, confirmed commits and the startup and=0Acandidate= datastores. A number of potential suppliers of devices we=0Aare conside= ring for out system already provide a web-based interface=0Aand may be f= ar more comfortable with migrating to (or via) RESTCONF=0Arather than di= rectly to NETCONF. However these excluded features are=0Aones we had hop= ed to leverage.=0A=0ASection 1.1 states "The following transaction featu= res are not=0Adirectly provided in RESTCONF". Is the word "directly" int= ended to=0Aconvey there may be indirect means of providing these feature= s with=0ARESTCONF? If so, is there any guidance on how? If not, would it= not be=0Abetter to remove the word?=0A=0AThanks=0A=0AJonathan=0A=0AOn 5= February 2015 at 13:22, Ersue, Mehmet (NSN - DE/Munich) wrote:=0A=0A= =09Dear NETCONF WG, =0A=0A=09we hereby issue a WG Last Call for 3 weeks= for the drafts below: =0A=0A=09=C2=A0 =0A=0A=09https://tools.ietf.org/= html/draft-ietf-netconf-restconf-04 [2] =0A=0A=09https://tools.ietf.org= /html/draft-ietf-netconf-yang-patch-03 [3] =0A=0A=09=C2=A0 =0A=0A=09Ple= ase review and send your comments to the NETCONF WG mailing list=0Aby Fe= bruary 26, 2015 EOB PT. =0A=0A=09The related draft-ietf-netconf-yang-li= brary will follow with LC as=0Asoon as the remaining two issues are solv= ed =0A=0A=09(see http://tools.ietf.org/html/draft-ietf-netconf-yang-lib= rary [4]).=0A=0A=0A=09RESTCONF documents are planned to publish as stand= ard track=0Adocuments. =0A=0A=09As RESTCONF is a major protocol we expec= t a detailed and thorough=0Areview within NETCONF WG but also by the rel= ated WGs before=0Apublishing. =0A=0A=09Therefore the WGLC is planned for= 3 weeks and APP, INT and RTG area=0AADs will be informed as well as Cor= e, I2rs, 6lo, and 6tisch WGs are=0Ainvited to review. =0A=0A=09Please st= ate explicitly that you have read/reviewed and whether you=0Asupport the= publication. =0A=0A=09Please indicate also if you plan to implement or= have already=0Aimplementation experience with RESTCONF. =0A=0A=09=C2=A0= =0A=0A=09Thank you, =0A=0A=09Mehmet and Mahesh =0A=0A=09=C2=A0 =0A=0A= =09FROM: Netconf [mailto:netconf-bounces@ietf.org [5]] ON BEHALF OF ext= =0AErsue, Mehmet (NSN - DE/Munich)=0ASENT: Saturday, January 31, 2015 4:= 05 PM=0ATO: netconf@ietf.org [6]=0ASUBJECT: [Netconf] Restconf-04 and YA= NG-Patch-03 drafts available =0A=0A=09=C2=A0 =0A=0A=09All, =0A=0A= =09=C2=A0 =0A=0A=091 YANG patch and 9 Restconf issues have been solved= and provided in=0Athe drafts below. =0A=0A=09These issues have been= set to the status Review=0A(https://github.com/netconf-wg/restconf/issu= es [7]). =0A=0A=09=C2=A0 =0A=0A=09Please check and comment on the dr= afts below before we go to WGLC=0Asoon: =0A=0A=09https://tools.ietf.or= g/html/draft-ietf-netconf-restconf-04 [8] =0A=0A=09https://tools.ietf= org/html/draft-ietf-netconf-yang-patch-03 [9] =0A=0A=09=C2=A0 =0A= =0A=09Regards, =0A Mehmet =0A=0A=09=C2=A0 =0A=0A=09=C2=A0 =0A___= ____________________________________________=0A Netconf mailing list=0AN= etconf@ietf.org [10]=0Ahttps://www.ietf.org/mailman/listinfo/netconf [11= ]=0A=0A =0A=0ALinks:=0A------=0A[1] mailto:mehmet.ersue@nsn.com=0A[2] ht= tps://tools.ietf.org/html/draft-ietf-netconf-restconf-04=0A[3] https://t= ools.ietf.org/html/draft-ietf-netconf-yang-patch-03=0A[4] http://tools.i= etf.org/html/draft-ietf-netconf-yang-library=0A[5] mailto:netconf-bounce= s@ietf.org=0A[6] mailto:netconf@ietf.org=0A[7] https://github.com/netcon= f-wg/restconf/issues=0A[8] https://tools.ietf.org/html/draft-ietf-netcon= f-restconf-04=0A[9] https://tools.ietf.org/html/draft-ietf-netconf-yang-= patch-03=0A[10] mailto:Netconf@ietf.org=0A[11] https://www.ietf.org/mail= man/listinfo/netconf=0A --=_972732028c296ed4e537fc6fd4e073aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RESTCONF provides a "Simple Subset of NETCONF F= unctionality", excluding locking, validation, confirmed commits and the= startup and candidate datastores. A number of potential suppliers of de= vices we are considering for out system already provide a web-based inte= rface and may be far more comfortable with migrating to (or via) RESTCON= F rather than directly to NETCONF. However these excluded features are o= nes we had hoped to leverage.

Section 1.1 states "The followi= ng transaction features are not directly provided in RESTCONF". Is the w= ord "directly" intended to convey there may be indirect means of providi= ng these features with RESTCONF? If so, is there any guidance on how? If= not, would it not be better to remove the word?

Thanks
=
Jonathan

On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - D= E/Munich) <= mehmet.ersue@nsn.com> wrote:
=0A=0A=0A=0A=0A=0A=0A=0A<= div lang=3D"en-us" xml:lang=3D"en-us">=0A
=0A

= Dear NETCONF WG,=

=0A

=0A

we hereb= y issue a WG Last Call for 3 weeks for=0A the drafts below:

=0A

=C2=A0

=0A

https://tools.ietf.org/h= tml/draft-ietf-netconf-restconf-04=0A

=0A

https://tools.ietf.org/html/draft-ie= tf-netconf-yang-patch-03=0A

=0A

=C2=A0Please review and send your comme= nts to the NETCONF=0A WG mailing list by February 26, 2015 EOB PT.

=0A

The related draft-ietf-netconf-yang-librar= y will=0A follow with LC as soon as the remaining two issues are solved=

=0A

(see http://tools.ietf.org/html/draft= -ietf-netconf-yang-library).

=0A

=

=0A

RESTCONF documents are planned to publis= h as=0A standard track documents.

=0A

As= RESTCONF is a major protocol we expect a detailed=0A and thorough revie= w within NETCONF WG but also by the related WGs before publishing.

=0A

Therefore the WGLC is planned for 3 weeks= and=0A APP, INT and RTG area ADs will be informed as well as Core, I2rs= , 6lo, and 6tisch WGs are invited to review.=

=0A

<= span style=3D"font-size:10pt;font-family:Verdana, 'sans-serif';color:#00= 00cc;">

=0A

Please state explicitly that y= ou have read/reviewed=0A and whether you support the publication.=

=0A

Please indicate also if you plan to implemen= t=0A or have already implementation experience with RESTCONF.<= /u>

=0A

=C2=A0

=0A

Thank y= ou,

=0A

Mehmet and Mahesh

=0A

=C2=A0

=0A
=0A=0A

From= :=0A Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of=0Aext Ersue, Mehmet (NSN= - DE/Munich)
Sent:= Saturday, January 31, 2015 4:05 PM
To: netconf@ietf.or= g
Subject: [Net= conf] Restconf-04 and YANG-Patch-03 drafts available

=0A
=0A
=0A

=C2=A0<= u>

=0A
=0A

All,

=0A
=0A
=0A

=C2=A0

=0A=0A
=0A

1 YANG patch and= 9 Restconf issues have been solved and provided in the drafts below.=0A=

=0A
=0A
=0A

These issues have been set to the status Review (https://github.c= om/netconf-wg/restconf/issues).

=0A=0A
=0A

=C2=A0<= /u>

=0A
=0A
=0A

Please check and comment on the drafts below before we go to WG= LC soon:

=0A
=0A=0A=0A
=0A<= p class=3D"MsoNormal">= =C2=A0

=0A=
=0A
=0A

Regards,=0A
=0AMehmet

=0A
=0A
=0A

=C2=A0

=0A
=0A
=0A=

=C2=A0

=0A
=0A
=0A
=0A=0A=
_______________________________________________<= br />=0ANetconf mailing list
Ne= tconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

<= /span>

=0A
=0A --=_972732028c296ed4e537fc6fd4e073aa-- From nobody Thu Mar 12 07:20:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D951A1AA0 for ; Thu, 12 Mar 2015 07:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ql-g7RolwokI for ; Thu, 12 Mar 2015 07:20:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6701A1A1A32 for ; Thu, 12 Mar 2015 07:20: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.1.99.14; Thu, 12 Mar 2015 14:20:03 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.21]) with mapi id 15.01.0099.004; Thu, 12 Mar 2015 14:20:03 +0000 From: Kent Watsen To: Jonathan Hansford , "netconf@ietf.org" Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available Thread-Index: AQHQW/FYwZJPpVcPk0eHvz8SI8t8RZ0YcgYA Date: Thu, 12 Mar 2015 14:20:03 +0000 Message-ID: References: <6c4a8c42791ae4c8922cfd6404a10982a650e8ce@webmail.hansfords.net> In-Reply-To: <6c4a8c42791ae4c8922cfd6404a10982a650e8ce@webmail.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-originating-ip: [66.129.239.11] authentication-results: hansfords.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10019020)(24454002)(164054003)(377454003)(16236675004)(102836002)(15975445007)(106116001)(2900100001)(2950100001)(2656002)(76176999)(54356999)(19580405001)(36756003)(46102003)(50986999)(19617315012)(66066001)(230783001)(551934003)(62966003)(107886001)(87936001)(2501003)(99286002)(92566002)(86362001)(122556002)(40100003)(83506001)(19580395003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001009)(5005006); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 05134F8B4F Content-Type: multipart/alternative; boundary="_000_D126E9EA9A4B3kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 14:20:03.1551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 12 Mar 2015 14:20:35 -0000 --_000_D126E9EA9A4B3kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jonathan, I somewhat agree and even raised the same internally with the author's a fe= w weeks ago - including a solution no less, and it wasn't even hard (contra= ry to what others have said). The response to this inquiry has always bee= n along the lines of "use netconf if you want fancy stuff" and "we need to = get this draft out the door". Personally, I feel like this is shortsighte= d and would rather see a complete solution. That said, I haven't pushed i= t because RESTCONF is sufficient the use cases I care about most. Thanks, Kent From: Jonathan Hansford > Date: Wednesday, March 11, 2015 at 7:48 AM To: "netconf@ietf.org" > Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and = draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 draf= ts available RESTCONF provides a "Simple Subset of NETCONF Functionality", excluding loc= king, validation, confirmed commits and the startup and candidate datastore= s. A number of potential suppliers of devices we are considering for out sy= stem already provide a web-based interface and may be far more comfortable = with migrating to (or via) RESTCONF rather than directly to NETCONF. Howeve= r these excluded features are ones we had hoped to leverage. Section 1.1 states "The following transaction features are not directly pro= vided in RESTCONF". Is the word "directly" intended to convey there may be = indirect means of providing these features with RESTCONF? If so, is there a= ny guidance on how? If not, would it not be better to remove the word? Thanks Jonathan On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - DE/Munich) > wrote: Dear NETCONF WG, we hereby issue a WG Last Call for 3 weeks for the drafts below: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Please review and send your comments to the NETCONF WG mailing list by Febr= uary 26, 2015 EOB PT. The related draft-ietf-netconf-yang-library will follow with LC as soon as = the remaining two issues are solved (see http://tools.ietf.org/html/draft-ietf-netconf-yang-library). RESTCONF documents are planned to publish as standard track documents. As RESTCONF is a major protocol we expect a detailed and thorough review wi= thin NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs wil= l be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited to rev= iew. Please state explicitly that you have read/reviewed and whether you support= the publication. Please indicate also if you plan to implement or have already implementatio= n experience with RESTCONF. Thank you, Mehmet and Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) Sent: Saturday, January 31, 2015 4:05 PM To: netconf@ietf.org Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available All, 1 YANG patch and 9 Restconf issues have been solved and provided in the dra= fts below. These issues have been set to the status Review (https://github.com/netconf= -wg/restconf/issues). Please check and comment on the drafts below before we go to WGLC soon: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Regards, Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_D126E9EA9A4B3kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

I somewhat agree and even raised the same internally with the author's= a few weeks ago – including a solution no less, and it wasn't even h= ard (contrary to what others have said).   The response to this inquir= y has always been along the lines of "use netconf if you want fancy stuff" and "we need to get this draft out the = door".   Personally, I feel like this is shortsighted and would r= ather see a complete solution.   That said, I haven't pushed it becaus= e RESTCONF is sufficient the use cases I care about most. 

Thanks,
Kent

From: Jonathan Hansford <jonathan@hansfords.net>
Date: Wednesday, March 11, 2015 at = 7:48 AM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] WG Last Call= for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WA= S:RE: Restconf-04 and YANG-Patch-03 drafts available

 --_000_D126E9EA9A4B3kwatsenjunipernet_-- From nobody Thu Mar 12 07:48:20 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A3E1A7D84 for ; Thu, 12 Mar 2015 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 kqcXISFAzytl for ; Thu, 12 Mar 2015 07:48:10 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B22E1A7022 for ; Thu, 12 Mar 2015 07:48:10 -0700 (PDT) Received: by lbvn10 with SMTP id n10so16442660lbv.11 for ; Thu, 12 Mar 2015 07:48:08 -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 :content-transfer-encoding; bh=XjLjH3mOBGTXmXtm1OSBwaQHysKGoBrmJWXoGAsd8M0=; b=QyFI8U9EPhtrAvr680c+anRBy3mdD9pilLZEyxXjIDgxwx/s74EFeqbprTNw6gYOvB 1b3KEft78jUGbR8OcyCUwTbjUFoKQT4Acj/ssQbndh6x0aL8nBboxR1B+pJlOERXxPIM ziqrOfIYewk25LIUYrBqfIrwG3sPw8jNGk8cQV0zAEVynqCoGKGnzses6iOOIFQQfN3W GZodms5gFZUMGp2Z3OpMRhxp/Cn1/bWA4vIEWOJPCH0QFreaIO0APQ0QZA5RvRmwx12C hrqSiu5owmrb/L9RrRASN4bK0i6/R5ytwlRtSD7R5bWWFGQpg1BiZTHoOcXn3Z6Qtd+Q Snnw== X-Gm-Message-State: ALoCoQn5A76hMCkRnVCHKPaVd/ur/djXrYXHuDfwC+ZOR0dUNScVywEbvMVBmZ2YwngS4EYNrvhO MIME-Version: 1.0 X-Received: by 10.152.87.46 with SMTP id u14mr19042171laz.82.1426171688780; Thu, 12 Mar 2015 07:48:08 -0700 (PDT) Received: by 10.112.144.36 with HTTP; Thu, 12 Mar 2015 07:48:08 -0700 (PDT) In-Reply-To: References: <6c4a8c42791ae4c8922cfd6404a10982a650e8ce@webmail.hansfords.net> Date: Thu, 12 Mar 2015 07:48:08 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 12 Mar 2015 14:48:16 -0000 Hi, One problem I have with exposing multiple targets (e.g.. candidate, running, startup) is that the operations become much more stateful. NETCONF has a concept of application sessions. NETCONF defines locking and cleanup after lost sessions. NETCONF does not embed the target datastore in the URI like RESTCONF. This makes the Location headers returned for new resources datastore-specific. The client should not use hacks to parse the Location header and make new ones for each datastore. That said, it is fairly trivial for one who knows NETCONF to figure out how to use /restconf/operations/edit-config (and commit) to do NETCONF-based editing. Andy On Thu, Mar 12, 2015 at 7:20 AM, Kent Watsen wrote: > > Hi Jonathan, > > I somewhat agree and even raised the same internally with the author's a = few > weeks ago =E2=80=93 including a solution no less, and it wasn't even hard= (contrary > to what others have said). The response to this inquiry has always been > along the lines of "use netconf if you want fancy stuff" and "we need to = get > this draft out the door". Personally, I feel like this is shortsighted = and > would rather see a complete solution. That said, I haven't pushed it > because RESTCONF is sufficient the use cases I care about most. > > Thanks, > Kent > > From: Jonathan Hansford > Date: Wednesday, March 11, 2015 at 7:48 AM > To: "netconf@ietf.org" > Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 an= d > draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 > drafts available > > RESTCONF provides a "Simple Subset of NETCONF Functionality", excluding > locking, validation, confirmed commits and the startup and candidate > datastores. A number of potential suppliers of devices we are considering > for out system already provide a web-based interface and may be far more > comfortable with migrating to (or via) RESTCONF rather than directly to > NETCONF. However these excluded features are ones we had hoped to leverag= e. > > Section 1.1 states "The following transaction features are not directly > provided in RESTCONF". Is the word "directly" intended to convey there ma= y > be indirect means of providing these features with RESTCONF? If so, is th= ere > any guidance on how? If not, would it not be better to remove the word? > > Thanks > > Jonathan > > > On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - DE/Munich) > wrote: >> >> Dear NETCONF WG, >> >> we hereby issue a WG Last Call for 3 weeks for the drafts below: >> >> >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 >> >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 >> >> >> >> Please review and send your comments to the NETCONF WG mailing list by >> February 26, 2015 EOB PT. >> >> The related draft-ietf-netconf-yang-library will follow with LC as soon = as >> the remaining two issues are solved >> >> (see http://tools.ietf.org/html/draft-ietf-netconf-yang-library). >> >> RESTCONF documents are planned to publish as standard track documents. >> >> As RESTCONF is a major protocol we expect a detailed and thorough review >> within NETCONF WG but also by the related WGs before publishing. >> >> Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs >> will be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited = to >> review. >> >> Please state explicitly that you have read/reviewed and whether you >> support the publication. >> >> Please indicate also if you plan to implement or have already >> implementation experience with RESTCONF. >> >> >> >> Thank you, >> >> Mehmet and Mahesh >> >> >> >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, >> Mehmet (NSN - DE/Munich) >> Sent: Saturday, January 31, 2015 4:05 PM >> To: netconf@ietf.org >> Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available >> >> >> >> All, >> >> >> >> 1 YANG patch and 9 Restconf issues have been solved and provided in the >> drafts below. >> >> These issues have been set to the status Review >> (https://github.com/netconf-wg/restconf/issues). >> >> >> >> Please check and comment on the drafts below before we go to WGLC soon: >> >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 >> >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 >> >> >> >> Regards, >> Mehmet >> >> >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Mar 12 08:25:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32FF1A87C0 for ; Thu, 12 Mar 2015 08:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6J7F0WooZxA for ; Thu, 12 Mar 2015 08:25:45 -0700 (PDT) Received: from mailscan1.extendcp.co.uk (mailscan39.extendcp.co.uk [176.32.230.33]) (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 6A1CC1A87E6 for ; Thu, 12 Mar 2015 08:25:36 -0700 (PDT) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan6.hi.local) by mailscan-g71.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YW4zL-00009p-Pp; Thu, 12 Mar 2015 15:25:31 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=www.outitgoes.com) by mailscan6.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YW4zE-0004du-6d; Thu, 12 Mar 2015 15:25:31 +0000 Received: from localhost ([127.0.0.1]) by webmail4.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YW4sL-0000Mr-I6; Thu, 12 Mar 2015 15:18:18 +0000 Message-Id: <641df23e2fc5ecd5933151e3bc565f2d98570655@webmail.hansfords.net> From: "Jonathan Hansford" To: "Andy Bierman" , "Kent Watsen" X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 212.159.131.153 in-reply-to: Date: Thu, 12 Mar 2015 15:18:17 +0000 Content-Type: multipart/alternative; boundary="=_c7b2b4c2e8d8ad9247ed935c1b8d939b" MIME-Version: 1.0 X-Authenticated-As: jonathan@hansfords.net Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 12 Mar 2015 15:25:48 -0000 --=_c7b2b4c2e8d8ad9247ed935c1b8d939b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C2=A0Hi,=0AI'm willing to accept that "it is fairly trivial for one who= knows=0ANETCONF to figure out how to use /restconf/operations/edit-conf= ig (and=0Acommit)=C2=A0to do NETCONF-based editing." However, for anyone= starting=0Awith RESTCONF with a view to possibly migrating to NETCONF a= t a later=0Adate, some guidance would be useful. I, for one, am still wa= iting for=0Amy company to start implementing anything based on NETCONF o= r RESTCONF=0Aand consequently any knowledge is currently theoretical.=0A= =0AJonathan=0A=0A----- Original Message -----=0AFrom: "Andy Bierman" =0A= To:"Kent Watsen" =0ACc:"Jonathan Hansford" , "netconf@ietf.org" =0ASent:= Thu, 12 Mar 2015 07:48:08 -0700=0ASubject:Re: [Netconf] WG Last Call for= draft-ietf-netconf-restconf-04=0Aand draft-ietf-netconf-yang-patch-03 W= AS:RE: Restconf-04 and=0AYANG-Patch-03 drafts available=0A=0A Hi,=0A=0A= One problem I have with exposing multiple targets (e.g..=0A candidate,= running, startup) is that the operations become=0A much more stateful.= NETCONF has a concept of application=0A sessions. NETCONF defines locki= ng and cleanup after=0A lost sessions. NETCONF does not embed the target= datastore=0A in the URI like RESTCONF. This makes the Location headers= =0A returned for new resources datastore-specific. The client should=0A= not use hacks to parse the Location header=0A and make new ones for eac= h datastore.=0A=0A That said, it is fairly trivial for one who knows NET= CONF to=0A figure out how to use /restconf/operations/edit-config (and c= ommit)=0A to do NETCONF-based editing.=0A=0A Andy=0A=0A On Thu, Mar 12,= 2015 at 7:20 AM, Kent Watsen wrote:=0A >=0A > Hi Jonathan,=0A >=0A > I= somewhat agree and even raised the same internally with the=0Aauthor's= a few=0A > weeks ago =E2=80=93 including a solution no less, and it was= n't even hard=0A(contrary=0A > to what others have said). The response t= o this inquiry has always=0Abeen=0A > along the lines of "use netconf if= you want fancy stuff" and "we=0Aneed to get=0A > this draft out the doo= r". Personally, I feel like this is=0Ashortsighted and=0A > would rather= see a complete solution. That said, I haven't pushed=0Ait=0A > because= RESTCONF is sufficient the use cases I care about most.=0A >=0A > Thank= s,=0A > Kent=0A >=0A > From: Jonathan Hansford =0A > Date: Wednesday, Ma= rch 11, 2015 at 7:48 AM=0A > To: "netconf@ietf.org" =0A > Subject: Re: [= Netconf] WG Last Call for=0Adraft-ietf-netconf-restconf-04 and=0A > draf= t-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and=0AYANG-Patch-03=0A= > drafts available=0A >=0A > RESTCONF provides a "Simple Subset of NETC= ONF Functionality",=0Aexcluding=0A > locking, validation, confirmed comm= its and the startup and=0Acandidate=0A > datastores. A number of potenti= al suppliers of devices we are=0Aconsidering=0A > for out system already= provide a web-based interface and may be far=0Amore=0A > comfortable wi= th migrating to (or via) RESTCONF rather than=0Adirectly to=0A > NETCONF= However these excluded features are ones we had hoped to=0Aleverage.= =0A >=0A > Section 1.1 states "The following transaction features are no= t=0Adirectly=0A > provided in RESTCONF". Is the word "directly" intended= to convey=0Athere may=0A > be indirect means of providing these feature= s with RESTCONF? If so,=0Ais there=0A > any guidance on how? If not, wou= ld it not be better to remove the=0Aword?=0A >=0A > Thanks=0A >=0A > Jon= athan=0A >=0A >=0A > On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - D= E/Munich)=0A > wrote:=0A >>=0A >> Dear NETCONF WG,=0A >>=0A >> we hereb= y issue a WG Last Call for 3 weeks for the drafts below:=0A >>=0A >>=0A= >>=0A >> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04=0A= >>=0A >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03= =0A >>=0A >>=0A >>=0A >> Please review and send your comments to the NET= CONF WG mailing=0Alist by=0A >> February 26, 2015 EOB PT.=0A >>=0A >> Th= e related draft-ietf-netconf-yang-library will follow with LC as=0Asoon= as=0A >> the remaining two issues are solved=0A >>=0A >> (see http://to= ols.ietf.org/html/draft-ietf-netconf-yang-library).=0A >>=0A >> RESTCONF= documents are planned to publish as standard track=0Adocuments.=0A >>= =0A >> As RESTCONF is a major protocol we expect a detailed and thorough= =0Areview=0A >> within NETCONF WG but also by the related WGs before pub= lishing.=0A >>=0A >> Therefore the WGLC is planned for 3 weeks and APP,= INT and RTG=0Aarea ADs=0A >> will be informed as well as Core, I2rs, 6l= o, and 6tisch WGs are=0Ainvited to=0A >> review.=0A >>=0A >> Please stat= e explicitly that you have read/reviewed and whether=0Ayou=0A >> support= the publication.=0A >>=0A >> Please indicate also if you plan to implem= ent or have already=0A >> implementation experience with RESTCONF.=0A >>= =0A >>=0A >>=0A >> Thank you,=0A >>=0A >> Mehmet and Mahesh=0A >>=0A >>= =0A >>=0A >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf O= f ext=0AErsue,=0A >> Mehmet (NSN - DE/Munich)=0A >> Sent: Saturday, Janu= ary 31, 2015 4:05 PM=0A >> To: netconf@ietf.org=0A >> Subject: [Netconf]= Restconf-04 and YANG-Patch-03 drafts available=0A >>=0A >>=0A >>=0A >>= All,=0A >>=0A >>=0A >>=0A >> 1 YANG patch and 9 Restconf issues have be= en solved and provided=0Ain the=0A >> drafts below.=0A >>=0A >> These is= sues have been set to the status Review=0A >> (https://github.com/netcon= f-wg/restconf/issues).=0A >>=0A >>=0A >>=0A >> Please check and comment= on the drafts below before we go to WGLC=0Asoon:=0A >>=0A >> https://to= ols.ietf.org/html/draft-ietf-netconf-restconf-04=0A >>=0A >> https://too= ls.ietf.org/html/draft-ietf-netconf-yang-patch-03=0A >>=0A >>=0A >>=0A >= > Regards,=0A >> Mehmet=0A >>=0A >>=0A >>=0A >>=0A >>=0A >>=0A >> ______= _________________________________________=0A >> Netconf mailing list=0A= >> Netconf@ietf.org=0A >> https://www.ietf.org/mailman/listinfo/netconf= =0A >>=0A >=0A >=0A >=0A > _____________________________________________= __=0A > Netconf mailing list=0A > Netconf@ietf.org=0A > https://www.ietf= org/mailman/listinfo/netconf=0A >=0A --=_c7b2b4c2e8d8ad9247ed935c1b8d939b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C2=A0Hi,

I'm willing to a= ccept that "it is fairly trivial for one who knows NETCONF to figure out= how to use /restconf/operations/edit-config (and commit)=C2=A0to do NET= CONF-based editing." However, for anyone starting with RESTCONF with a v= iew to possibly migrating to NETCONF at a later date, some guidance woul= d be useful. I, for one, am still waiting for my company to start implem= enting anything based on NETCONF or RESTCONF and consequently any knowle= dge is currently theoretical.

Jonathan

----- Original Message -----
From:
"Andy Bie= rman" <andy@yumaworks.com>

To:
"Kent Watsen" <kwatsen@juniper.net>
Cc:
"Jonathan Hansford" <jonathan@hansfor= ds.net>, "netconf@ietf.org" <netconf@ietf.org>
Sent:
Thu, 12 Mar 2015 07:48:08 -0700
<= div style=3D"font-weight:bold;">Subject:
Re: [Netconf] WG Last Call= for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03= WAS:RE: Restconf-04 and YANG-Patch-03 drafts available


=0AHi,

=0AOne problem I have with exposing multiple targets= (e.g..
=0Acandidate, running, startup) is that the operations beco= me
=0Amuch more stateful. NETCONF has a concept of application=0Asessions. NETCONF defines locking and cleanup after
=0Alost= sessions. NETCONF does not embed the target datastore
=0Ain the= URI like RESTCONF. This makes the Location headers
=0Areturned fo= r new resources datastore-specific. The client should
=0Anot use h= acks to parse the Location header
=0Aand make new ones for each dat= astore.


=0AThat said, it is fairly trivial for one who= knows NETCONF to
=0Afigure out how to use /restconf/operations/edi= t-config (and commit)
=0Ato do NETCONF-based editing.

=0AAndy

=0AOn Thu, Mar 12, 2015 at 7:20 AM, Kent Watsen &= lt;kwatsen@juniper.net> wrote:
=0A>
=0A> Hi Jonathan,=
=0A>
=0A> I somewhat agree and even raised the same int= ernally with the author's a few
=0A> weeks ago =E2=80=93 includi= ng a solution no less, and it wasn't even hard (contrary
=0A> to= what others have said). The response to this inquiry has always been<= br />=0A> along the lines of "use netconf if you want fancy stuff" an= d "we need to get
=0A> this draft out the door". Personally, I= feel like this is shortsighted and
=0A> would rather see a comp= lete solution. That said, I haven't pushed it
=0A> because RES= TCONF is sufficient the use cases I care about most.
=0A>
= =0A> Thanks,
=0A> Kent
=0A>
=0A> From: Jonath= an Hansford <jonathan@hansfords.net>
=0A> Date: Wednesday,= March 11, 2015 at 7:48 AM
=0A> To: "netconf@ietf.org" <netco= nf@ietf.org>
=0A> Subject: Re: [Netconf] WG Last Call for dra= ft-ietf-netconf-restconf-04 and
=0A> draft-ietf-netconf-yang-pat= ch-03 WAS:RE: Restconf-04 and YANG-Patch-03
=0A> drafts availabl= e
=0A>
=0A> RESTCONF provides a "Simple Subset of NETCON= F Functionality", excluding
=0A> locking, validation, confirmed= commits and the startup and candidate
=0A> datastores. A number= of potential suppliers of devices we are considering
=0A> for o= ut system already provide a web-based interface and may be far more
=0A> comfortable with migrating to (or via) RESTCONF rather than dir= ectly to
=0A> NETCONF. However these excluded features are ones= we had hoped to leverage.
=0A>
=0A> Section 1.1 states= "The following transaction features are not directly
=0A> provi= ded in RESTCONF". Is the word "directly" intended to convey there may=0A> be indirect means of providing these features with RESTCONF?= If so, is there
=0A> any guidance on how? If not, would it not= be better to remove the word?
=0A>
=0A> Thanks
=0A= >
=0A> Jonathan
=0A>
=0A>
=0A> On 5 F= ebruary 2015 at 13:22, Ersue, Mehmet (NSN - DE/Munich)
=0A> <= mehmet.ersue@nsn.com> wrote:
=0A>>
=0A>> Dear N= ETCONF WG,
=0A>>
=0A>> we hereby issue a WG Last C= all for 3 weeks for the drafts below:
=0A>>
=0A>><= br />=0A>>
=0A>> https://tools.ietf.org/html/draft-ietf= -netconf-restconf-04
=0A>>
=0A>> https://tools.iet= f.org/html/draft-ietf-netconf-yang-patch-03
=0A>>
=0A>= ;>
=0A>>
=0A>> Please review and send your comm= ents to the NETCONF WG mailing list by
=0A>> February 26, 201= 5 EOB PT.
=0A>>
=0A>> The related draft-ietf-netco= nf-yang-library will follow with LC as soon as
=0A>> the rema= ining two issues are solved
=0A>>
=0A>> (see http:= //tools.ietf.org/html/draft-ietf-netconf-yang-library).
=0A>>=
=0A>> RESTCONF documents are planned to publish as standard= track documents.
=0A>>
=0A>> As RESTCONF is a maj= or protocol we expect a detailed and thorough review
=0A>> wi= thin NETCONF WG but also by the related WGs before publishing.
=0A&= gt;>
=0A>> Therefore the WGLC is planned for 3 weeks and A= PP, INT and RTG area ADs
=0A>> will be informed as well as Co= re, I2rs, 6lo, and 6tisch WGs are invited to
=0A>> review.=0A>>
=0A>> Please state explicitly that you have re= ad/reviewed and whether you
=0A>> support the publication.=0A>>
=0A>> Please indicate also if you plan to impl= ement or have already
=0A>> implementation experience with RE= STCONF.
=0A>>
=0A>>
=0A>>
=0A>&= gt; Thank you,
=0A>>
=0A>> Mehmet and Mahesh
= =0A>>
=0A>>
=0A>>
=0A>> From: Net= conf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue,
=0A&= gt;> Mehmet (NSN - DE/Munich)
=0A>> Sent: Saturday, Januar= y 31, 2015 4:05 PM
=0A>> To: netconf@ietf.org
=0A>>= ; Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available
=0A>>
=0A>>
=0A>>
=0A>> All,=0A>>
=0A>>
=0A>>
=0A>> 1 YANG= patch and 9 Restconf issues have been solved and provided in the
= =0A>> drafts below.
=0A>>
=0A>> These issues= have been set to the status Review
=0A>> (https://github.com= /netconf-wg/restconf/issues).
=0A>>
=0A>>
=0A= >>
=0A>> Please check and comment on the drafts below b= efore we go to WGLC soon:
=0A>>
=0A>> https://tool= s.ietf.org/html/draft-ietf-netconf-restconf-04
=0A>>
=0A= >> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03=0A>>
=0A>>
=0A>>
=0A>> Regard= s,
=0A>> Mehmet
=0A>>
=0A>>
=0A>= ;>
=0A>>
=0A>>
=0A>>
=0A>>= ; _______________________________________________
=0A>> Netco= nf mailing list
=0A>> Netconf@ietf.org
=0A>> https= ://www.ietf.org/mailman/listinfo/netconf
=0A>>
=0A>=0A>
=0A>
=0A> __________________________________= _____________
=0A> Netconf mailing list
=0A> Netconf@iet= f.org
=0A> https://www.ietf.org/mailman/listinfo/netconf
= =0A>
--=_c7b2b4c2e8d8ad9247ed935c1b8d939b-- From nobody Thu Mar 12 09:13:33 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D595A1A1B98 for ; Thu, 12 Mar 2015 09:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 8i9TqVR3Zib2 for ; Thu, 12 Mar 2015 09:13:29 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218771A0174 for ; Thu, 12 Mar 2015 09:13:29 -0700 (PDT) Received: by labhs14 with SMTP id hs14so16396526lab.5 for ; Thu, 12 Mar 2015 09:13:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rye0HjouVNGafw7geRPW5iB/7BtSgvUB43Bj9weLmGA=; b=EbZ72E0LiFWRjGKNjId87UX9ToLGjW7lWRQVSA556l+wMXnG7rusVMHkVSqABoGFam 4eoQshIN8sIrVYWQuUpOoUtAtViXWpatHWeHn/PMR++S+7PPAGrccARW8VGklx3awS+7 nQ53+vwNhXQ9qCXVTtShsbeusvjc83Un0JyM4b5NWFrsYV2gcTrCZyYQ1OpMW62vSxo1 yaVdgdJUl8zPMKytojIpAqSOP9GnRiMOo7Tv35f+3RlRyGGohiEA6bkr/3AS5D9No79K /6b4+vucwZRueYMfKUWre0n/LvplYAWDoah0NGUXXP8R/xFvEaFGwh/MeluubsjEqvYA vE/A== X-Gm-Message-State: ALoCoQlRizaZsgdPZjTDE5zZVxISRBpjrthzA7881TbYxsbQG9sM20TV/jUEfvnKrNvUnn8at7wf MIME-Version: 1.0 X-Received: by 10.152.5.194 with SMTP id u2mr39824516lau.88.1426176807658; Thu, 12 Mar 2015 09:13:27 -0700 (PDT) Received: by 10.112.144.36 with HTTP; Thu, 12 Mar 2015 09:13:27 -0700 (PDT) In-Reply-To: <641df23e2fc5ecd5933151e3bc565f2d98570655@webmail.hansfords.net> References: <641df23e2fc5ecd5933151e3bc565f2d98570655@webmail.hansfords.net> Date: Thu, 12 Mar 2015 09:13:27 -0700 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 12 Mar 2015 16:13:32 -0000 On Thu, Mar 12, 2015 at 8:18 AM, Jonathan Hansford wrote: > Hi, > > I'm willing to accept that "it is fairly trivial for one who knows NETCON= F > to figure out how to use /restconf/operations/edit-config (and commit) to= do > NETCONF-based editing." However, for anyone starting with RESTCONF with a > view to possibly migrating to NETCONF at a later date, some guidance woul= d > be useful. I, for one, am still waiting for my company to start implement= ing > anything based on NETCONF or RESTCONF and consequently any knowledge is > currently theoretical. > There is no requirement for the server to expose the NETCONF operations in RESTCONF, so it seems inappropriate to discuss it in the RESTCONF draft. I agree with Martin that NETCONF should be used if you wnt these features. I don't really see any benefit to using RESTCONF POST to invoke NETCONF RPC calls. This is not REST-like at all, so leveraging existing code seems unlikely. I also think NETCONF candidate config is a bad transaction model because it is shared and NETCONF locking is so expensive to use. It should be possible to add rollback and control of NV-save to RESTCONF in the future. > Jonathan Andy > > > ----- Original Message ----- > From: > "Andy Bierman" > > To: > "Kent Watsen" > Cc: > "Jonathan Hansford" , "netconf@ietf.org" > > Sent: > Thu, 12 Mar 2015 07:48:08 -0700 > Subject: > Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 and > draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 > drafts available > > > Hi, > > One problem I have with exposing multiple targets (e.g.. > candidate, running, startup) is that the operations become > much more stateful. NETCONF has a concept of application > sessions. NETCONF defines locking and cleanup after > lost sessions. NETCONF does not embed the target datastore > in the URI like RESTCONF. This makes the Location headers > returned for new resources datastore-specific. The client should > not use hacks to parse the Location header > and make new ones for each datastore. > > > That said, it is fairly trivial for one who knows NETCONF to > figure out how to use /restconf/operations/edit-config (and commit) > to do NETCONF-based editing. > > > Andy > > On Thu, Mar 12, 2015 at 7:20 AM, Kent Watsen wrote: >> >> Hi Jonathan, >> >> I somewhat agree and even raised the same internally with the author's a >> few >> weeks ago =E2=80=93 including a solution no less, and it wasn't even har= d >> (contrary >> to what others have said). The response to this inquiry has always been >> along the lines of "use netconf if you want fancy stuff" and "we need to >> get >> this draft out the door". Personally, I feel like this is shortsighted a= nd >> would rather see a complete solution. That said, I haven't pushed it >> because RESTCONF is sufficient the use cases I care about most. >> >> Thanks, >> Kent >> >> From: Jonathan Hansford >> Date: Wednesday, March 11, 2015 at 7:48 AM >> To: "netconf@ietf.org" >> Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-04 a= nd >> draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 >> drafts available >> >> RESTCONF provides a "Simple Subset of NETCONF Functionality", excluding >> locking, validation, confirmed commits and the startup and candidate >> datastores. A number of potential suppliers of devices we are considerin= g >> for out system already provide a web-based interface and may be far more >> comfortable with migrating to (or via) RESTCONF rather than directly to >> NETCONF. However these excluded features are ones we had hoped to >> leverage. >> >> Section 1.1 states "The following transaction features are not directly >> provided in RESTCONF". Is the word "directly" intended to convey there m= ay >> be indirect means of providing these features with RESTCONF? If so, is >> there >> any guidance on how? If not, would it not be better to remove the word? >> >> Thanks >> >> Jonathan >> >> >> On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - DE/Munich) >> wrote: >>> >>> Dear NETCONF WG, >>> >>> we hereby issue a WG Last Call for 3 weeks for the drafts below: >>> >>> >>> >>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 >>> >>> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 >>> >>> >>> >>> Please review and send your comments to the NETCONF WG mailing list by >>> February 26, 2015 EOB PT. >>> >>> The related draft-ietf-netconf-yang-library will follow with LC as soon >>> as >>> the remaining two issues are solved >>> >>> (see http://tools.ietf.org/html/draft-ietf-netconf-yang-library). >>> >>> RESTCONF documents are planned to publish as standard track documents. >>> >>> As RESTCONF is a major protocol we expect a detailed and thorough revie= w >>> within NETCONF WG but also by the related WGs before publishing. >>> >>> Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs >>> will be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited >>> to >>> review. >>> >>> Please state explicitly that you have read/reviewed and whether you >>> support the publication. >>> >>> Please indicate also if you plan to implement or have already >>> implementation experience with RESTCONF. >>> >>> >>> >>> Thank you, >>> >>> Mehmet and Mahesh >>> >>> >>> >>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, >>> Mehmet (NSN - DE/Munich) >>> Sent: Saturday, January 31, 2015 4:05 PM >>> To: netconf@ietf.org >>> Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available >>> >>> >>> >>> All, >>> >>> >>> >>> 1 YANG patch and 9 Restconf issues have been solved and provided in the >>> drafts below. >>> >>> These issues have been set to the status Review >>> (https://github.com/netconf-wg/restconf/issues). >>> >>> >>> >>> Please check and comment on the drafts below before we go to WGLC soon: >>> >>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 >>> >>> https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 >>> >>> >>> >>> Regards, >>> Mehmet >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> From nobody Thu Mar 12 11:24:35 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6EA431B2A3A; Tue, 10 Mar 2015 05:48:14 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4866A1A87E8 for ; Tue, 10 Mar 2015 05:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 qvKbKZk_-pnG for ; Tue, 10 Mar 2015 05:48:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1571B2A2C for ; Tue, 10 Mar 2015 05:48:10 -0700 (PDT) Received: from mail.painless-security.com ([23.30.188.241]:46182) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YVJZx-0003Tp-OE for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Tue, 10 Mar 2015 05:48:10 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9E3A820659; Tue, 10 Mar 2015 08:47:01 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWt2aeH96Q4Y; Tue, 10 Mar 2015 08:47:00 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 10 Mar 2015 08:47:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ED7C382837; Tue, 10 Mar 2015 08:48:04 -0400 (EDT) From: Sam Hartman To: "t.p." References: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> Date: Tue, 10 Mar 2015 08:48:04 -0400 In-Reply-To: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> (t. p.'s message of "Tue, 10 Mar 2015 12:12:14 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SA-Exim-Connect-IP: 23.30.188.241 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: hartmans@mit.edu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150310124810.9D1571B2A2C@ietfa.amsl.com> Resent-Date: Tue, 10 Mar 2015 05:48:10 -0700 (PDT) Resent-From: hartmans@mit.edu Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 11:24:33 -0700 Cc: iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [Netconf] Secdir Review of draft-ietf-netconf-rfc5539bis-09 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, 10 Mar 2015 12:48:14 -0000 >>>>> "t" == t p writes: Well, I think you still need to answer questions like * Is it a fingerprint of the cert or the key? * Is the server expected to re-normalize the DER? Allowed to re-normalize the DER? So that the input to the hash is well specified. Several protocols within the IETF have taken on the challenge of describing how to fingerprint certificates. I think the document would be improved by picking one of these strategies. From nobody Thu Mar 12 11:24:36 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0DF491ACDC9; Tue, 10 Mar 2015 05:59:26 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38C91A885F for ; Tue, 10 Mar 2015 05:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXWpz2N8FmeW for ; Tue, 10 Mar 2015 05:59:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8041A87A8 for ; Tue, 10 Mar 2015 05:59:25 -0700 (PDT) Received: from atlas3.jacobs-university.de ([212.201.44.18]:57835) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YVJkp-0003D4-Hk for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Tue, 10 Mar 2015 05:59:24 -0700 Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE810A31; Tue, 10 Mar 2015 13:59:19 +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 m86mO68B2l0E; Tue, 10 Mar 2015 13:59:11 +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; Tue, 10 Mar 2015 13:59:19 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 486DC2003D; Tue, 10 Mar 2015 13:59:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8n1j5og9Piuc; Tue, 10 Mar 2015 13:59:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7607D2003C; Tue, 10 Mar 2015 13:59:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6953B3275FAB; Tue, 10 Mar 2015 13:59:18 +0100 (CET) Date: Tue, 10 Mar 2015 13:59:18 +0100 From: Juergen Schoenwaelder To: Sam Hartman Message-ID: <20150310125918.GD6978@elstar.local> Mail-Followup-To: Sam Hartman , ietf@ietf.org, secdir@ietf.org, iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-SA-Exim-Connect-IP: 212.201.44.18 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: j.schoenwaelder@jacobs-university.de X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150310125925.0C8041A87A8@ietfa.amsl.com> Resent-Date: Tue, 10 Mar 2015 05:59:25 -0700 (PDT) Resent-From: j.schoenwaelder@jacobs-university.de Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 11:24:33 -0700 Cc: iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [Netconf] Secdir Review of draft-ietf-netconf-rfc5539bis-09 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, 10 Mar 2015 12:59:26 -0000 On Mon, Mar 09, 2015 at 08:10:24AM -0400, Sam Hartman wrote: > > In section 7, there is a description of how the netconf server finds the > username of the client. > It talks about a certificate fingerprint without a reference to a > specific algorithm. > I'm aware of multiple algorithms for fingerprints. > This text is probably too vague for interoperability. Since the fingerprints are not exchanged over the wire, this is a local problem. That said, there is a YANG configuration data model in draft-ietf-netconf-server-model-06 that clarifies details for those implementations that want interoperable configuration and this data model uses tls-fingerprint defined in RFC 7407. /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 Thu Mar 12 11:24:38 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C8FFD1A1A43; Tue, 10 Mar 2015 08:50:45 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09CF1A1A42 for ; Tue, 10 Mar 2015 08:50:45 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neFifVaqoCMG for ; Tue, 10 Mar 2015 08:50:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF8C1A19E9 for ; Tue, 10 Mar 2015 08:50:42 -0700 (PDT) Received: from mail-am1on0139.outbound.protection.outlook.com ([157.56.112.139]:9192 helo=emea01-am1-obe.outbound.protection.outlook.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YVMQa-0006zs-Ok for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Tue, 10 Mar 2015 08:50:42 -0700 Received: from AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141) by AM3PR07MB0711.eurprd07.prod.outlook.com (25.160.6.15) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 12:15:17 +0000 Received: from pc6 (86.185.85.149) by AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 12:15:16 +0000 Message-ID: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> From: t.p. To: Sam Hartman , , , References: Date: Tue, 10 Mar 2015 12:12:14 +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.185.85.149] X-ClientProxiedBy: DB4PR02CA0028.eurprd02.prod.outlook.com (10.242.174.156) To AM3PR07MB242.eurprd07.prod.outlook.com (10.242.18.141) Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB242; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB0711; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(51704005)(129404003)(33646002)(50226001)(61296003)(116806002)(1556002)(86362001)(50466002)(230783001)(19580405001)(23756003)(19580395003)(44716002)(87976001)(2201001)(77096005)(77156002)(62966003)(47776003)(42186005)(40100003)(46102003)(76176999)(92566002)(62236002)(122386002)(81686999)(81816999)(66066001)(44736004)(50986999)(1456003)(2171001)(84392001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB242; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:AM3PR07MB242; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB242; X-Forefront-PRVS: 051158ECBB X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2015 12:15:16.6850 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB242 X-OriginatorOrg: btconnect.com X-Helo-Check-Failed: Verification failed for HELO emea01-am1-obe.outbound.protection.outlook.com X-SA-Exim-Connect-IP: 157.56.112.139 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: daedulus@btconnect.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150310155042.8DF8C1A19E9@ietfa.amsl.com> Resent-Date: Tue, 10 Mar 2015 08:50:42 -0700 (PDT) Resent-From: daedulus@btconnect.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 11:24:33 -0700 Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: Re: [Netconf] Secdir Review of draft-ietf-netconf-rfc5539bis-09 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, 10 Mar 2015 15:50:45 -0000 ----- Original Message ----- From: "Sam Hartman" To: ; ; Cc: Sent: Monday, March 09, 2015 12:10 PM Subject: Secdir Review of draft-ietf-netconf-rfc5539bis-09 > > This is an update to netconf over TLS with mutual X.509 authentication. > > In general, this looks fairly good. > > I'd ask the security ADs to take a look at two things: > > * The text on certificate validation in section 5. > Certificate validation has a number of options, none of which are > described or specified in this text. > Is that good enough for this application? (Probably) > > In section 7, there is a description of how the netconf server finds the > username of the client. > It talks about a certificate fingerprint without a reference to a > specific algorithm. > I'm aware of multiple algorithms for fingerprints. > This text is probably too vague for interoperability. Sam I see what you mean but had a different model in mind. The fingerprint is not transmitted as part of the tls/netconf protocol, I assume that it is only generated within a server when a certificate arrives over the tls/netconf protocol and is then compared with a prestored list of fingerprints within the server. So as long as the same algorithm is used within the server, then it does not matter what is used. If, instead, the prestored list of fingerprints is generated outside the server and installed as a file, then yes, the algorithm used to create the prestored list must be the same as that used within the server when a certificate arrives over the tls/netconf protocol. That is the only issue I can see. However, this I-D used to contain a data model to go with it but that has been put into a different I-D namely netconf-server. That data model imports a YANG data type tls-fingerprint which is defined as a one octet hashing algorithm identifier followed by the fingerprint value. The octet value is taken from the IANA TLS Hash Algorithm Registry (RFC 5246). So if the YANG data model is used, then the algorithm is part of the model and the server can look up what has been used in its prestored list of fingerprints. If users do not use the YANG data model, well that is up to them Hope this helps Tom Petch > From nobody Thu Mar 12 11:24:39 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2A51C1A89B1; Tue, 10 Mar 2015 13:49:38 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A641A89AE for ; Tue, 10 Mar 2015 13:49:38 -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=unavailable Received: 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-PQrQPnN5Es for ; Tue, 10 Mar 2015 13:49:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336F91A89B1 for ; Tue, 10 Mar 2015 13:49:33 -0700 (PDT) Received: from mail-am1on0106.outbound.protection.outlook.com ([157.56.112.106]:10994 helo=emea01-am1-obe.outbound.protection.outlook.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YVR5n-0000Kb-RO for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Tue, 10 Mar 2015 13:49:32 -0700 Received: from pc6 (86.185.85.149) by AMSPR07MB248.eurprd07.prod.outlook.com (10.242.19.27) with Microsoft SMTP Server (TLS) id 15.1.106.15; Tue, 10 Mar 2015 14:18:25 +0000 Message-ID: <006c01d05b3c$c44eac40$4001a8c0@gateway.2wire.net> From: t.p. To: Sam Hartman References: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> Date: Tue, 10 Mar 2015 14:16:04 +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.185.85.149] X-ClientProxiedBy: DB4PR02CA0049.eurprd02.prod.outlook.com (10.242.174.177) To AMSPR07MB248.eurprd07.prod.outlook.com (10.242.19.27) Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB248; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(51704005)(87976001)(47776003)(62236002)(116806002)(44736004)(62966003)(50226001)(46102003)(2171001)(66066001)(92566002)(1556002)(76176999)(50986999)(81686999)(110136001)(81816999)(230783001)(14496001)(19580405001)(122386002)(23756003)(33646002)(44716002)(86362001)(19580395003)(77096005)(1456003)(40100003)(77156002)(84392001)(50466002)(61296003)(42186005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB248; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002009); SRVR:AMSPR07MB248; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB248; X-Forefront-PRVS: 051158ECBB X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2015 14:18:25.3048 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB248 X-Helo-Check-Failed: Verification failed for HELO emea01-am1-obe.outbound.protection.outlook.com X-SA-Exim-Connect-IP: 157.56.112.106 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: daedulus@btconnect.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150310204933.336F91A89B1@ietfa.amsl.com> Resent-Date: Tue, 10 Mar 2015 13:49:33 -0700 (PDT) Resent-From: daedulus@btconnect.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 11:24:33 -0700 Cc: iesg@ietf.org, draft-ietf-netconf-rfc5539bis.all@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [Netconf] Secdir Review of draft-ietf-netconf-rfc5539bis-09 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, 10 Mar 2015 20:49:38 -0000 ----- Original Message ----- From: "Sam Hartman" To: "t.p." Cc: "Sam Hartman" ; ; ; ; Sent: Tuesday, March 10, 2015 12:48 PM > >>>>> "t" == t p writes: > > Well, I think you still need to answer questions like > > * Is it a fingerprint of the cert or the key? > > * Is the server expected to re-normalize the DER? Allowed to > re-normalize the DER? Sam Thank you for your comments. The I-D specifies fingerprint of the certificate so that is specified. Normalisation is not specified and is an interesting point; as you say, something to be considered. Tom Petch > So that the input to the hash is well specified. > Several protocols within the IETF have taken on the challenge of > describing how to fingerprint certificates. I think the document would > be improved by picking one of these strategies. > From nobody Thu Mar 12 11:24:40 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C5CB41A8760; Wed, 11 Mar 2015 04:37:28 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48FE1A8836 for ; Wed, 11 Mar 2015 04:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIBQwkak7eic for ; Wed, 11 Mar 2015 04:37:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E77E1A875E for ; Wed, 11 Mar 2015 04:37:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net ([93.183.12.31]:49107) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YVex2-0007bH-Un for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Wed, 11 Mar 2015 04:37:26 -0700 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 t2BBb8Ec019801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Mar 2015 11:37:08 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t2BBb5mo015965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 12:37:08 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.51]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0224.002; Wed, 11 Mar 2015 12:37:06 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "t.p." , Sam Hartman , "ietf@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: Secdir Review of draft-ietf-netconf-rfc5539bis-09 Thread-Index: AQHQW0n9mJmt5LFRvU2BKdI4qUhc050XKMHA Date: Wed, 11 Mar 2015 11:37:05 +0000 Message-ID: References: <000b01d05b2b$8d3ab2a0$4001a8c0@gateway.2wire.net> In-Reply-To: <000b01d05b2b$8d3ab2a0$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.102] 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: 2681 X-purgate-ID: 151667::1426073829-000067C4-B36833DA/0/0 X-SA-Exim-Connect-IP: 93.183.12.31 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: mehmet.ersue@nokia.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150311113726.8E77E1A875E@ietfa.amsl.com> Resent-Date: Wed, 11 Mar 2015 04:37:26 -0700 (PDT) Resent-From: mehmet.ersue@nokia.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 11:24:33 -0700 Cc: "draft-ietf-netconf-rfc5539bis.all@tools.ietf.org" Subject: Re: [Netconf] Secdir Review of draft-ietf-netconf-rfc5539bis-09 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, 11 Mar 2015 11:37:28 -0000 -----Original Message----- From: t.p. [mailto:daedulus@btconnect.com]=20 Sent: Tuesday, March 10, 2015 1:12 PM To: Sam Hartman; ietf@ietf.org; secdir@ietf.org; iesg@ietf.org Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: Re: Secdir Review of draft-ietf-netconf-rfc5539bis-09 ----- Original Message ----- From: "Sam Hartman" To: ; ; Cc: Sent: Monday, March 09, 2015 12:10 PM Subject: Secdir Review of draft-ietf-netconf-rfc5539bis-09 > > This is an update to netconf over TLS with mutual X.509 authentication. > > In general, this looks fairly good. > > I'd ask the security ADs to take a look at two things: > > * The text on certificate validation in section 5. > Certificate validation has a number of options, none of which are > described or specified in this text. > Is that good enough for this application? (Probably) > > In section 7, there is a description of how the netconf server finds the > username of the client. > It talks about a certificate fingerprint without a reference to a > specific algorithm. > I'm aware of multiple algorithms for fingerprints. > This text is probably too vague for interoperability. Sam I see what you mean but had a different model in mind. The fingerprint is not transmitted as part of the tls/netconf protocol, I assume that it is only generated within a server when a certificate arrives over the tls/netconf protocol and is then compared with a prestored list of fingerprints within the server. So as long as the same algorithm is used within the server, then it does not matter what is used. If, instead, the prestored list of fingerprints is generated outside the server and installed as a file, then yes, the algorithm used to create the prestored list must be the same as that used within the server when a certificate arrives over the tls/netconf protocol. That is the only issue I can see. However, this I-D used to contain a data model to go with it but that has been put into a different I-D namely netconf-server. That data model imports a YANG data type tls-fingerprint which is defined as a one octet hashing algorithm identifier followed by the fingerprint value. The octet value is taken from the IANA TLS Hash Algorithm Registry (RFC 5246). So if the YANG data model is used, then the algorithm is part of the model and the server can look up what has been used in its prestored list of fingerprints. If users do not use the YANG data model, well that is up to them Hope this helps Tom Petch > From nobody Thu Mar 12 11:24:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4980C1A0113; Thu, 12 Mar 2015 06:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.194 X-Spam-Level: ** X-Spam-Status: No, score=2.194 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 ubIAjTzioMYw; Thu, 12 Mar 2015 06:05:42 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id BCD571A00F7; Thu, 12 Mar 2015 06:05:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id E5DD825043; Thu, 12 Mar 2015 14:05:39 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT4RueZCRZXf; Thu, 12 Mar 2015 14:05:36 +0100 (CET) Received: from XMBX1.pantheon.local (fw.pantheon.sk [81.89.59.166]) by amalka.pantheon.sk (Postfix) with ESMTPS; Thu, 12 Mar 2015 14:05:36 +0100 (CET) Received: from XMBX1.pantheon.local (10.10.4.5) by XMBX1.pantheon.local (10.10.4.5) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 12 Mar 2015 14:05:36 +0100 Received: from XMBX1.pantheon.local ([10.10.4.5]) by XMBX1.pantheon.local ([10.10.4.5]) with mapi id 15.00.0847.030; Thu, 12 Mar 2015 14:05:29 +0100 From: =?iso-8859-2?Q?Anton_Tk=E1=E8ik?= To: "netmod@ietf.org" , "netconf@ietf.org" Thread-Topic: draft-ietf-netconf-restconf-04 - Inconsistent JSON serialization between PUT and GET of list item Thread-Index: AQHQXMSLJ1GMJpx7X0eD/fwfwl/RQw== Date: Thu, 12 Mar 2015 13:05:29 +0000 Message-ID: <2fe89c1a458e42d88b6c7871f72e8aa8@XMBX1.pantheon.local> Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.38.208.170] Content-Type: multipart/alternative; boundary="_000_2fe89c1a458e42d88b6c7871f72e8aa8XMBX1pantheonlocal_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 11:24:33 -0700 Subject: [Netconf] draft-ietf-netconf-restconf-04 - Inconsistent JSON serialization between PUT and GET of list item X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 13:05:44 -0000 --_000_2fe89c1a458e42d88b6c7871f72e8aa8XMBX1pantheonlocal_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, I noticed in draft-ietf-netconf-restconf-04 and draft-ietf-netmod-yang-json= -03 some inconsistencies regarding reading (GET) and writing (PUT) list item: ietf-netmod-yang-json-03, clearly says that list is serialized as array of = objects, but draft-ietf-netconf-restconf-04 showcases different serializations: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04#section-4.5 PUT /restconf/data/example-jukebox:jukebox/ library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:album" : { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011 } } Here list-item is serialized as object, no array around it (this is inconsi= stent with referenced ietf-netmod-yang-json-03) The GET example for one list item (https://tools.ietf.org/html/draft-ietf-n= etconf-restconf-04#appendix-D.3.9) shows: GET /restconf/data/interfaces/interface=3Deth1 HTTP/1.1 Host: example.com Accept: application/yang.data+json The server might respond as follows. HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Content-Type: application/yang.data+json { "example:interface": [ { "name" : "eth1", "status" : "up" } ] } Here is serialized according ietf-netmod-yang-json-03. This behaviour is confusing - since you it seems that data retrieved via GE= T to same URL should not be used for PUT to same URL. This inconsistency was uncovered during bug analysis in Opendaylight (https= ://bugs.opendaylight.org/show_bug.cgi?id=3D2818) this was for 02 versions, = but analysis shows it still present in latest drafts. AntonTk=E1=E8ik Head of Java office Mlynsk=E9 Nivy 56 / 821 05 Bratislava / Slovakia +421 911 309 249 / anton.tkacik@pantheon.sk reception: +421 2 206 65 111 / www.pantheon.sk [logo] --_000_2fe89c1a458e42d88b6c7871f72e8aa8XMBX1pantheonlocal_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi,

I noticed in draft-ietf-netconf-restconf-04 and draft-ietf-netmod-y= ang-json-03 some inconsistencies

regarding reading (GET) and writing (PUT) list item:


ietf-netmod-yang-json-03, clearly says that list is serialized as array = of objects,

but draft-ietf-netconf-restconf-04 showcases different serializations:


https://tools.ietf.org/html/draft-ietf-netconf-restconf-04#secti= on-4.5


     PUT /restconf/data/example-jukebox:jukebox/=0A=
         library/artist=3DFoo%20Fighters/album=3DWasting%20Light   HTTP/1.1=
=0A=
      Host: example.com=0A=
      Content-Type: application/yang.data+json=0A=
=0A=
      {=0A=
        "example-jukebox:album" : {=0A=
          "name" : "Wasting Light",=0A=
          "genre" : "example-jukebox:alternative",=0A=
          "year" : 2011=0A=
        }=0A=
      }


Here list-item is serialized as object, no array around it (this is inconsi= stent with referenced ietf-netmod-yang-json-03)




The GET example for one list item (= https://tools.ietf.org/html/draft-ietf-netconf-restconf-04#appendix-D.3.9) shows:






      GET /restconf/data/interfaces/interface=3Deth1 HTTP/1.1=0A=
      Host: example.com=0A=
      Accept: application/yang.data+json=0A=
=0A=
   The server might respond as follows.





      HTTP/1.1 200 OK=0A=
      Date: Mon, 23 Apr 2012 17:01:00 GMT=0A=
      Server: example-server=0A=
      Content-Type: application/yang.data+json=0A=
=0A=
      {=0A=
        "example:interface": [=0A=
          {=0A=
            "name" : "eth1",=0A=
            "status" : "up"=0A=
          }=0A=
        ]=0A=
      }





Here is serialized according ietf-netmod-yang-json-03.











This behaviour is confusing - since you it seems that data retrieved via=
 GET to same URL should not be used for PUT to same URL.

















This inconsistency was uncovered during bug analysis in Openda=
ylight (https://bugs.opendaylight.org/show_bug.cgi?id=3D2818) this was for =
02 versions, but analysis shows it still 


present in latest drafts.











PT_signature

AntonTk=E1=E8ik



Head o=
f Java office

<=
/o:p>=


<=
o:p>Mlynsk=E9 Nivy 56
/ 821 05 Bratislava
/ Slovakia

+421 911 309 249 /
anton.tkacik@pantheon.sk

reception: +421 2 206 65 111 /
www.pantheon.sk



3D"logo"




--_000_2fe89c1a458e42d88b6c7871f72e8aa8XMBX1pantheonlocal_--


From nobody Fri Mar 13 03:18:15 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740E01A1BE4 for ; Fri, 13 Mar 2015 03:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 j2RdiAhcw6PF for ; Fri, 13 Mar 2015 03:18:11 -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 9617C1A1BD2 for ; Fri, 13 Mar 2015 03:18:10 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9FE8E297C; Fri, 13 Mar 2015 11:18:09 +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 VNyuiKTBstmx; Fri, 13 Mar 2015 11:17:43 +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, 13 Mar 2015 11:18:08 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47CAE2004E; Fri, 13 Mar 2015 11:18:08 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id b7xGJXwVH2CK; Fri, 13 Mar 2015 11:18:07 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC0E22004A; Fri, 13 Mar 2015 11:18:06 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id BFA723279007; Fri, 13 Mar 2015 11:18:05 +0100 (CET)
Date: Fri, 13 Mar 2015 11:18:05 +0100
From: Juergen Schoenwaelder 
To: "Ersue, Mehmet (Nokia - DE/Munich)" 
Message-ID: <20150313101805.GB17615@elstar.local>
Mail-Followup-To: "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 13 Mar 2015 10:18:14 -0000

On Tue, Mar 03, 2015 at 10:16:21PM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote:
> Dear NETCONF WG,
> 
> we hereby issue a WG Last Call for 2 weeks for the drafts below:
> 
> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04
> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06
> 
> Please review and send your comments to the NETCONF WG mailing list by March 17, 2015 EOB PT.
>

Here is my review of draft-ietf-netconf-call-home-04.txt.

- Perhaps the second bullet in 2.1 can be improved. Perhaps slight
  rewording helps to make things a bit clearer?

    Change "the SSH-server protocol is used for PORT-X" to "the
    SSH-server protocol is used after connecting to the remote port
    PORT-X" and change "the TLS-server protocol is used for either
    port PORT-Y or PORT-Z" to "the TLS-server protocol is used after
    connecting to one of the remote ports PORT-Y or PORT-Z".
  
- Should the text say something about the assumption that a mismatch
  (a NR server using SSH towards a remote port assuming TLS) leads to
  a failure discovered by the secure transport protocols and to a
  failure of the connection attempt? I guess we do not want systems to
  probe which protocol is available, as this might be a way to try
  downgrade attacks in case one of the protocols has vulnerabities.

- Similarly as above, perhaps change the text in the 3rd bullet in 2.1
  as well:

  OLD
        [...] Assuming the use of
        the IANA-assigned ports, the NETCONF-server protocol is used for
        PORT-X or PORT-Y and the RESTCONF-server protocol is used for
        PORT-Z.

  NEW

        [...] Assuming the use of
	the IANA-assigned ports, the NETCONF-server protocol is used
	over the secure transports to the remote ports PORT-X and
	PORT-Y and the RESTCONF-server protocol is used over the
	secure transport to the remote port PORT-Z.

- Third bullet in section 3.1, similar as suggested above:

  OLD

      For example, assuming the use of the IANA-assigned ports, the SSH-
      client protocol is used for PORT-X and the TLS-client protocol is
      used for either port PORT-Y or PORT-Z.

  NEW

      For example, assuming the use of the IANA-assigned ports, the
      SSH- client protocol is used for connections accepted on PORT-X
      and the TLS-client protocol is used for connections accepted on
      one of the ports PORT-Y or PORT-Z.

- Fourth bullet in section 3.1, similar as suggested above:

- The document refers to [RFC5539] but it should likely refer to
  5539bis. I am not sure the reference of RFC7230 is convincing in the
  last bullet in section 3.1 since this is at the end a generic
  reference to RFC HTTP 1.1.

- If the document uses labels such as S1, S2, S3 and C1, C2, C3 for
  the various server and client protocol operation steps, it becomes a
  bit easier to refer to them ('step C3' is easier to write than
  'third bullet in section 3.1').

- In section 3.2, I think the phrase "this action provides essential
  input" is a bit vague. I think the key here is that the client
  normally has an idea of the expected identity residing at the remote
  server side before even initiating a connection. We probably need to
  make sure we use the proper terminology here (security people should
  tell us).

- 3rd paragraph in section 3.2: For certain NATs, you would get a
  predictable IP address for all N/R servers behind it but then the IP
  address is shared and not unique. This should probably also be
  mentioned as another reason for not using IP addresses (despite the
  fact that they are not strong identifiers from a security
  perspective in any case).

- Is there a reason why verification of the SSH/TLS server's hostkey
  is not required using a MUST? I am actually confused with regard to
  the next paragraph. If the server has a certificate, I may be able
  to verify the certificate and then accept the incoming connection
  because I trust the certificate shown by the server. I do not know
  what his has to do with an identity encoded in the "Subject" field?
  Such a thing would be just a replacement for the fingerprint I would
  otherwise use, no?

- Since the text recommends the usage of certificates, should there be
  explicit text warning about shipping multiple boxes with the same
  certificate? Should there be hints at choosing proper lifetimes and
  the need to handle certificate updates or to handle certificates of
  devices that were 'lost' or 'stolen'? Or at least have hints that
  devices should at least make it difficult to steal certificates?

/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 Mar 13 18:22:40 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11AF1A88A1 for ; Fri, 13 Mar 2015 18:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIp4bab3Bst4 for ; Fri, 13 Mar 2015 18:22:37 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4119E1A88A3 for ; Fri, 13 Mar 2015 18:22:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XD0k+QyqAEzDrRgyHaxqAfML26j2rn0PqefzwJqjd8cramMf/nafLt7mS88YpQgS; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YWamh-00007i-RJ for netconf@ietf.org; Fri, 13 Mar 2015 21:22:35 -0400
Received: from 76.254.54.158 by webmail.earthlink.net with HTTP; Fri, 13 Mar 2015 21:22:35 -0400
Message-ID: <15748819.1426296155831.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
Date: Fri, 13 Mar 2015 18:22:35 -0700 (GMT-07:00)
From: Randy Presuhn 
To: Netconf 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537120ea984e6ecdceefcca7ac3178a5495350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.27
Archived-At: 
Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Mar 2015 01:22:39 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Mar 11, 2015 2:43 AM
>To: Martin Bj=C3=B6rklund 
>Cc: Netconf 
>Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key=
/keys?
...
>Robust management applications should be prepared to deal
>with e.g. interfaces being renamed at run time because that=E2=80=99s
>a fact of life.

What are your expectations of managed systems' ability
to maintain referential integrity (of, e.g., logs,
alarms, and configuration data) across rename events?

Randy


From nobody Mon Mar 16 07:58:49 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D93D1A8824 for ; Mon, 16 Mar 2015 07:58:47 -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 rtPI86YCnf3g for ; Mon, 16 Mar 2015 07:58:45 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 504ED1A882F for ; Mon, 16 Mar 2015 07:58:45 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 733EA1CC0309; Mon, 16 Mar 2015 15:58:45 +0100 (CET)
From: Ladislav Lhotka 
To: Randy Presuhn , Netconf 
In-Reply-To: <15748819.1426296155831.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
References: <15748819.1426296155831.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 16 Mar 2015 15:58:42 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys?
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, 16 Mar 2015 14:58:47 -0000

Randy Presuhn  writes:

> Hi -
>
>>From: Ladislav Lhotka 
>>Sent: Mar 11, 2015 2:43 AM
>>To: Martin Bj=C3=B6rklund 
>>Cc: Netconf 
>>Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's ke=
y/keys?
> ...
>>Robust management applications should be prepared to deal
>>with e.g. interfaces being renamed at run time because that=E2=80=99s
>>a fact of life.
>
> What are your expectations of managed systems' ability
> to maintain referential integrity (of, e.g., logs,
> alarms, and configuration data) across rename events?

If an interface changes its name, then all references to it in the
configuration have to be updated. I think Junos has such a procedure.

You may remember that I advocated using opaque keys that don't have any
meaning outside configuration and thus are not affected by external side
effects.

As for logs, I think the only solution is to log an entry about the name
change, and then use the new name afterwards.

Lada

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

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


From nobody Mon Mar 16 12:20:48 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060DD1A8BAF for ; Mon, 16 Mar 2015 12:20:47 -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 0jW91qQlGGG0 for ; Mon, 16 Mar 2015 12:20:46 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1321A8AFA for ; Mon, 16 Mar 2015 12:20:45 -0700 (PDT)
Received: by pdbcz9 with SMTP id cz9so66362638pdb.3 for ; Mon, 16 Mar 2015 12:20:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=QtD7tEETySBKdP5Oz8jw/gnwe/h+ZgmOp4mB6RJATtk=; b=odyH1MFDgcuJyexcvUH02ZMziAB+Kq3NeWtWX6JG9NOHFJW5Qb3ETlBwJmgCj76uew H+GyGTPb+VeUgY8FBmMrfxkMGWUViKDgUuyThM/pwIll6WYHBmf+kREVfcGzZS8qflET Y+4ANvSbp5OqKY93G1toiyJz/Yu8Um1W/1IylXosZbuV1rUBly7B9QW1uFaa7Jwmtl3w 9QEvw4t6rDVa8oOTN1tmDcdA05xGGWRkqETXlM8LI8aoAmqjdOKKEoSRAPJipl3Ifc/L gznDpZ2LQTQ5U1ngEzVb3e3d8LeRxWLZTsgLcVtgGyt+1R479y5hRVxS+aSXC8pcmnaX 1HBA==
X-Received: by 10.70.126.225 with SMTP id nb1mr141275070pdb.40.1426533645649;  Mon, 16 Mar 2015 12:20:45 -0700 (PDT)
Received: from [10.192.123.124] (mobile-166-171-250-112.mycingular.net. [166.171.250.112]) by mx.google.com with ESMTPSA id ae7sm18626113pac.19.2015.03.16.12.20.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 12:20:45 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPhone Mail (12D508)
Message-Id: <6C6CBF33-4381-49F0-8795-0A5FA1A3C567@gmail.com>
Date: Mon, 16 Mar 2015 12:20:40 -0700
To: netconf@ietf.org
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Archived-At: 
Subject: [Netconf] Slides for IETF 92
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, 16 Mar 2015 19:20:47 -0000

If you are one of the presenters in IETF 92, now would be a great time to se=
nd in your slides for us to upload  them. We meet on Tuesday.=20

Thanks.=20

Mahesh & Mehmet.=20=


From nobody Mon Mar 16 13:59:19 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F791A9126 for ; Mon, 16 Mar 2015 13:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfhBdDRjiacB for ; Mon, 16 Mar 2015 13:58:47 -0700 (PDT)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 18EDC1A9124 for ; Mon, 16 Mar 2015 13:58:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iehHHUp4sKkEZc63MNk8tk68klbYdZgoHMxn+d3L1reKqmIht0aF72lPCkwvIjB8; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YXc62-00080F-AF for netconf@ietf.org; Mon, 16 Mar 2015 15:58:46 -0500
Received: from 76.254.51.180 by webmail.earthlink.net with HTTP; Mon, 16 Mar 2015 16:58:45 -0400
Message-ID: <15505044.1426539526113.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
Date: Mon, 16 Mar 2015 13:58:45 -0700 (GMT-07:00)
From: Randy Presuhn 
To: Netconf 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537168f717bdc5b9ad6ac762181c0ac2ae7350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.34
Archived-At: 
Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Mar 2015 20:58:50 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Mar 16, 2015 7:58 AM
>To: Randy Presuhn , Netconf 
>Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key=
/keys?
>
>Randy Presuhn  writes:
>
>> Hi -
>>
>>>From: Ladislav Lhotka 
>>>Sent: Mar 11, 2015 2:43 AM
>>>To: Martin Bj=C3=B6rklund 
>>>Cc: Netconf 
>>>Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's k=
ey/keys?
>> ...
>>>Robust management applications should be prepared to deal
>>>with e.g. interfaces being renamed at run time because that=E2=80=99s
>>>a fact of life.
>>
>> What are your expectations of managed systems' ability
>> to maintain referential integrity (of, e.g., logs,
>> alarms, and configuration data) across rename events?
>
>If an interface changes its name, then all references to it in the
>configuration have to be updated. I think Junos has such a procedure.
>
>You may remember that I advocated using opaque keys that don't have any
>meaning outside configuration and thus are not affected by external side
>effects.
>
>As for logs, I think the only solution is to log an entry about the name
>change, and then use the new name afterwards.

And alarms?  (Think about alarm aggregation and
trouble ticket systems.)

Randy

Randy


From nobody Mon Mar 16 21:18:51 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7681A0016 for ; Mon, 16 Mar 2015 21:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 PPYstYAa_sKQ for ; Mon, 16 Mar 2015 21:18:48 -0700 (PDT)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5BB1A0007 for ; Mon, 16 Mar 2015 21:18:47 -0700 (PDT)
Received: by lbbzq9 with SMTP id zq9so44772386lbb.0 for ; Mon, 16 Mar 2015 21:18:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Xcdq9Oh9hX52zfPUiD00ip0ZzFOTXY2Gr0MqTbrz3eI=; b=ZJiqU3oFnElGGctjDQ6S0wy9S8rvD9fz21GPjGGHMC/nISwBlVymN8vSiOp8g9+Fcf 6HhUrVhntdE+J56BPRNLMtXM4FT8sb78WkB44r+1D50HQFataxq6nY4vv+1WtWbcryvO GbaJGibWbzR3a5bfE24Xo7uMiF380debT8YGtezNatdX/gUIhLYjDtOpFYWUZ7VCqJN+ ccRGW+aw9qXHSLnFYrJfoFJFCiUHf3oeaS4NMKj/UUe2kaBGhvrAzlSkyU3SiIwuNp4z tRaTmyut3FgAwjbBGKZzPbBGYIsyxBWhu54/1LKZoo7xH7Nzqb18MAGTvAEyiAzJ7X3a mOEg==
X-Gm-Message-State: ALoCoQnTHsNYQgpjt5ObL8T2q4h9DUr2ygOT3NWmDMRgOpyD3h6Ok6Q8ArDycW5vE0QhYjnbK/Vg
MIME-Version: 1.0
X-Received: by 10.152.1.194 with SMTP id 2mr33977594lao.38.1426565925946; Mon, 16 Mar 2015 21:18:45 -0700 (PDT)
Received: by 10.112.144.36 with HTTP; Mon, 16 Mar 2015 21:18:45 -0700 (PDT)
Date: Mon, 16 Mar 2015 21:18:45 -0700
Message-ID: 
From: Andy Bierman 
To: Netconf 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [Netconf] subtree filter normalization
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, 17 Mar 2015 04:18:49 -0000

Hi,

I'm trying to rewrite some NETCONF code, and I cannot
tell if RFC 6241 allows for subtree filters to be normalized.
It is not clear how certain usage should be processed.

This text in 6.1, para 1 seems to suggest the filter does not
need to follow a schema.

   The server does not need to utilize any data-model-
   specific semantics during processing, allowing for simple and
   centralized implementation strategies.


I am not convinced NETCONF is correct here
(and I wrote a lot of this subtree text ;-)
IMO the server MUST return schema-valid content
for YANG modules it advertises,
and that requires the filter to be interpreted
and the response content normalized.


F0 is the well-behaved example on pg 25:

F0:
    
       
         
           
             fred
           
         
       
     

The RFC does not say if the 'name' select node can be repeated,
as in F1:

F1:
   
       
         
           
             fred
             barney
           
         
       
     

6.2.5, bullet 2 says these are ANDed together, so
filter F1 would not match anything.  IMO this should only
apply to different select leafs.  Duplicate select leafs
should be ORed together.  This will help normalization.


F2:
   
       
         
           
             fred
           
           
             fred
           
         
       
     

Is F2 allowed? (container user repeated)
Is the server required to collapse the entries for return
so the rpc-reply is schema-valid?
Same applies to F3 and F4.

F3: variant of F2
   
       
         
           
             fred
           
         
         
           
             fred
           
         
       
     

F4: variant of F2
   
       
         
           
             fred
           
         
       
      
         
           
             barney
           
         
       
     


Andy


From nobody Tue Mar 17 02:00:27 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AE11A0171 for ; Tue, 17 Mar 2015 02:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 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, 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 lrNU3qRkKh8g for ; Tue, 17 Mar 2015 02:00:22 -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 02EDD1A0162 for ; Tue, 17 Mar 2015 02:00:22 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:1da7:321c:8a00:4c6d] (unknown [IPv6:2001:718:1a02:1:1da7:321c:8a00:4c6d]) by mail.nic.cz (Postfix) with ESMTPSA id 1AB8E13F941; Tue, 17 Mar 2015 10:00:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1426582820; bh=XCjknVYdhcUovWkDN+t4b6PTG+opT5BUmv4olHa5NYA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jNI+pUggMkGLR5OzCOQM4keRbj801y62TXushywjbe4BmKvQ8DT5MfVn/ZEbuBy9v G2UkrgjTnyYdUyLu3feR31JYKLosoK/U/LMHsZnIEQY9qfVmefIp5R1HG5fUlk9gl5 UIHbeFIbC4Wd2ufqUt84/gODYo1SAOMFnYEtOunE=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ladislav Lhotka 
In-Reply-To: <15505044.1426539526113.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
Date: Tue, 17 Mar 2015 10:00:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <49E3F8D6-95C4-4063-8D5E-3D67591865CC@nic.cz>
References: <15505044.1426539526113.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.2070.6)
X-Virus-Scanned: clamav-milter 0.98.6 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] [netmod] Is it possible to change a list enty's key/keys?
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, 17 Mar 2015 09:00:24 -0000

> On 16 Mar 2015, at 21:58, Randy Presuhn  =
wrote:
>=20
> Hi -
>=20
>> From: Ladislav Lhotka 
>> Sent: Mar 16, 2015 7:58 AM
>> To: Randy Presuhn , Netconf =

>> Subject: Re: [Netconf] [netmod] Is it possible to change a list =
enty's key/keys?
>>=20
>> Randy Presuhn  writes:
>>=20
>>> Hi -
>>>=20
>>>> From: Ladislav Lhotka 
>>>> Sent: Mar 11, 2015 2:43 AM
>>>> To: Martin Bj=C3=B6rklund 
>>>> Cc: Netconf 
>>>> Subject: Re: [Netconf] [netmod] Is it possible to change a list =
enty's key/keys?
>>> ...
>>>> Robust management applications should be prepared to deal
>>>> with e.g. interfaces being renamed at run time because that=E2=80=99s=

>>>> a fact of life.
>>>=20
>>> What are your expectations of managed systems' ability
>>> to maintain referential integrity (of, e.g., logs,
>>> alarms, and configuration data) across rename events?
>>=20
>> If an interface changes its name, then all references to it in the
>> configuration have to be updated. I think Junos has such a procedure.
>>=20
>> You may remember that I advocated using opaque keys that don't have =
any
>> meaning outside configuration and thus are not affected by external =
side
>> effects.
>>=20
>> As for logs, I think the only solution is to log an entry about the =
name
>> change, and then use the new name afterwards.
>=20
> And alarms?  (Think about alarm aggregation and
> trouble ticket systems.)

I have no experience with such systems but I assume they have to be =
notified about the change and act accordingly. My point was just that a =
system-wide interface name can change, either at run time or after a =
reboot.

Lada

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

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





From nobody Tue Mar 17 07:27:55 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6801A1A6F for ; Tue, 17 Mar 2015 07:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xNyeLXhBIYA5 for ; Tue, 17 Mar 2015 07:27:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 784D81A1A17 for ; Tue, 17 Mar 2015 07:27:51 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A8D21280052 for ; Tue, 17 Mar 2015 15:27:50 +0100 (CET)
Date: Tue, 17 Mar 2015 15:27:56 +0100 (CET)
Message-Id: <20150317.152756.1341316749588622343.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
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: 
Subject: [Netconf] mbj review of draft-ietf-netconf-server-model-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, 17 Mar 2015 14:27:54 -0000

Hi,

Here is my WGLC review of draft-ietf-netconf-server-model-06.


o  I suggest you create a terminology section.

   The term "application" is still used w/o being defined.  Also, the
   YANG model has this:

      list application {
        key name;
        description
          "List of NETCONF clients the NETCONF server is to initiate
           call-home connections to.";
        leaf name {
          type string;
          description
            "An arbitrary name for the remote NETCONF client.";
        }

  Which to me seems as if the term "application" is equivalent to
  "NETCONF client", but I don't think that's the intention.  (Or is
  it?  If so, why do we have two terms for the same thing?)


o  2.6.7: s/as transpired/has transpired/


o  3.1.2  has a reference to 6242; this should probably reference 6242
   and the tls document


o  3.1.2: s/Feature statements/"feature" statements/


o  This is the first of our modules to use import-by revision.
   Esp. since it's meaning is at best underspecified in 6020, I
   suggest you remove the revision-dates.


o  For feature "ssh" and "tls":

   Update the description text to:

     "The ssh feature indicates that the server supports the
      SSH transport protocol for NETCONF.";

   and similar for the tls text.


o  I and others have commented before that the usage of groupings in
   this module makes the model more difficult to read.  I still think
   this is true.  It is very difficult to see the structure in this
   module.   Most groupings in this module are described as:

      "This grouping is used only to help improve readability
       of the YANG module.";

   I suggest you remove these groupings - to improve readability ;-)


o  The other groupings are described as:

      "This grouping is used by both the ssh and tls containers.";

   This doesn't tell the reader what the grouping does.


o  The hello-timeout has this range:

          range "0 | 10 .. 3600";

   Why not allow values 1..9?  This seems like an arbitrary range to
   me.

   Also, maybe we should discuss an alternative design for this leaf,
   and other similar leafs.

    type union {
      type uint32 {
        range "1..3600";
      }
      type enumeration {
        enum "infinity";
      }
    }

  I don't know which design pattern is best.


o  The hello-timeout description talks about the "hello PDU".  This
   should be "hello message".

   The text also mentions "hello-wait" state.  There is no such
   defined state - although I do understand what you mean.  I suggest
   you simply remove the last part of the sentence.

   Also, the text talks about denial of service attacks; maybe you
   should mention this leaf in the Security Considerations section.


o  list endpoint / choice transport

   The text says:

            "Selects between SSH and TLS transports."

   I suggest:

            "Selects between available transports.";

   (this text is already in the call-home transport choice)


o  call-home / application / connection-type

   This choice has "persistent-connection" as the default.  Why is
   this the default?  Wouldn't it be better to not have a default, and
   possibly make the choice mandatory.


o  call-home / application / connection-type

  The call-home draft mentions this objective:

   o  The network element may proactively call home after being powered
      on for the first time in order to register itself with its
      management system.

  How is this use case supported in this model?

  It also mentions:

   o  The network element may access the network in a way that
      dynamically assigns it an IP address and it doesn't register its
      assigned IP addressed to a mapping service, thus complicating the
      ability for a management system to connect to it.

  How is this use case supported in this model?


o  call-home / application / connection-type / persistent-connection

  By default, if we configure a call-home "application", we have a
  persistent-connention with keep-alives being sent on the transport
  layer ever 15 seconds.  But we also have the idle-timeout that works
  on the messages layer default to 3600 seconds.

  So it seems to me that unless there is NETCONF traffic, the
  persistent connection will be closed by the idle-timeout after 3600
  seconds.  But since the connection was persistent, the device will
  immediately re-establish the connection, and so on.


o  reconnect-strategy / start-with

   The description says:

                   NETCONF servers
                   SHOULD support this flag across reboots.";

   "support this flag" is a bit vague.  I think you mean that servers
   SHOULD keep track of the last connected client in non-volatile
   storage.


o  reconnect-strategy / count-max

  Would "max-attempts" be a better name than "count-max"?


o  ordered-by system

  Some lists have an "ordered-by system" statement.  Since this is the
  default, I suggest you remove it.


o  call-home / application / connection-type / periodic-connention

   The leaf timeout-mins is of type uint8.  Isn't this a bit small?  I
   think this should be uint16.

   Also, the text says that a device "should" pro-actively connect to
   the client if it has messages to send.  Maybe this is is good
   enough, but in a deployment with *lots* of devices, maybe you want
   to suppress such messages to a time window when the client is
   prepared to handle it.  Again, maybe this use case is better done
   with a new type of connection-type ("absolute-time" or something),
   and such a container can be augmented later.  I just wonder if you
   thought about this use case.


o  tls / client-auth

   Why do we need both trusted-client-certs and cert-maps?

   Also, I think the text doesn't describe how the "trusted-ca-certs"
   leaf-list should be used.  The cert-to-name list has this:

         2) If the cert-to-name list entry's fingerprint value
            matches that of a locally held copy of a trusted CA
            certificate, [...]

   So I *think* the intention is that the configured
   "trusted-ca-certs" leaf list is supposed to provide these "locally
   held copy".

   Also, is it a bug or a faeture that we have two separate leaf-lists
   of trusted-ca-certs, one for ssh and one for tls?


o  endpoints address / address

  s/The hostname or IP address or hostname/
    The hostname or IP address/


o  container keep-alives

  s/Section 4/Section 5/


o  keep-alives / interval-secs

  s/a message/a transport-protocol specific message/

  Also, is the word "NETCONF client" correct here?  Ths point is that
  the keep-alive message in on the transport layer.


o  keep-alives / count-max

  Would "max-attempts", or "retries" be better names than
  "count-max"?

  The description mentions "The interval timer", but no such timer has
  been defined.


o  Appendix A.2

  The prefix "x509c2n" is not defined.

  When I fixed that, the example valdiates.


o  I have validated the examples in A.1 and A.3.


I plan to implement the data model in this document for NETCONF over
SSH, and RESTCONF over TLS "soon".



/martin


From nobody Tue Mar 17 07:30:31 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15961A1AB2 for ; Tue, 17 Mar 2015 07:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CH48hRSawZ-q for ; Tue, 17 Mar 2015 07:30: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 BFC5B1A1A9B for ; Tue, 17 Mar 2015 07:30:21 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 098D01280052 for ; Tue, 17 Mar 2015 15:30:21 +0100 (CET)
Date: Tue, 17 Mar 2015 15:30:37 +0100 (CET)
Message-Id: <20150317.153037.1712560924448000326.mbj@tail-f.com>
From: Martin Bjorklund 
To: netconf@ietf.org
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: 
Subject: [Netconf] mbj review of draft-ietf-netconf-call-home-04
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, 17 Mar 2015 14:30:27 -0000

Hi,

Here is my WGLC review of draft-ietf-netconf-call-home-04.


o  2.1

  The first bullet says

      The server SHOULD default
      to connecting to one of the IANA-assigned ports defined in section
      Section 5

  This is a bit imprecise; you probably mean that a NETCONF server
  defaults to the IANA assigned NETCONF SSH port for SSH etc.


o  3.2, first paragraph

   s/connection/TCP connection/ ?


o  3.2, third paragraph

  This paragraph essentially says:

    "X is normally necessary, but due to Y, X is necessary."

  (where X is "verifying the server's identity")

  The logic is a bit weird.


o  3.2, fifth paragraph

  This paragraph uses "This strategy" a couple of times.  I *think* it
  always refers to the same thing, namely the idea of using a
  fingerprint of the key/cert for identification.  But at the end of
  the paragraph I wasn't sure anymore...  Maybe this could be
  clarified.


o  3.2, sixth paragraph

  The first sentence describes another identification method.  The
  rest of the paragraph talks about varifation.  Maybe make this a
  separate paragraph.

  The last sentence says "This strategy is recommended for
  all deployment scenarios."  It is not clear what "This strategy"
  refers to.  Is it to use something like the "Subject" field as the
  identity?  (probably not)

  At this point, it is not clear to me what I am supposed to implement
  if I want to create an interoperable implementation.


o  After 3.2

  I suggest you add a section "3.3  Configuration Data Model", with
  similar content as in 2.2 - how to configure this is out of scope.


/martin


From nobody Tue Mar 17 08:09:54 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8201A1B53 for ; Tue, 17 Mar 2015 08:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 QwZFN5fWhgOC for ; Tue, 17 Mar 2015 08:09:49 -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 A7B161A1AB8 for ; Tue, 17 Mar 2015 08:09:49 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 26345278C; Tue, 17 Mar 2015 16:09:48 +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 Buou5BkjVvgG; Tue, 17 Mar 2015 16:09:39 +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; Tue, 17 Mar 2015 16:09:47 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EA6820054; Tue, 17 Mar 2015 16:09:47 +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 oFsIlnteRhn9; Tue, 17 Mar 2015 16:09:46 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0A7A20053; Tue, 17 Mar 2015 16:09:45 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id B5289327CFFC; Tue, 17 Mar 2015 16:09:44 +0100 (CET)
Date: Tue, 17 Mar 2015 16:09:44 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20150317150944.GD33375@elstar.local>
Mail-Followup-To: Martin Bjorklund , netconf@ietf.org
References: <20150317.152756.1341316749588622343.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150317.152756.1341316749588622343.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] mbj review of draft-ietf-netconf-server-model-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, 17 Mar 2015 15:09:53 -0000

On Tue, Mar 17, 2015 at 03:27:56PM +0100, Martin Bjorklund wrote:
 
> o  The hello-timeout has this range:
> 
>           range "0 | 10 .. 3600";
> 
>    Why not allow values 1..9?  This seems like an arbitrary range to
>    me.
> 
>    Also, maybe we should discuss an alternative design for this leaf,
>    and other similar leafs.
> 
>     type union {
>       type uint32 {
>         range "1..3600";
>       }
>       type enumeration {
>         enum "infinity";
>       }
>     }
> 
>   I don't know which design pattern is best.

If we adopt this pattern, we should probably make this

   enum "infinity" { value 0; }

in order to be explicit about the numeric value assigned to this
enum via auto-numbering.

/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 Mar 17 09:04:14 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADDD1A1BF5; Tue, 17 Mar 2015 09:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MLWdQ0B2iuQ; Tue, 17 Mar 2015 09:04:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 736C71A8706; Tue, 17 Mar 2015 09:03:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , , , ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150317160351.16594.7692.idtracker@ietfa.amsl.com>
Date: Tue, 17 Mar 2015 09:03:51 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Netconf] ID Tracker State Update Notice: 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 16:04:10 -0000

IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/


From nobody Tue Mar 17 09:04:22 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6111A8709; Tue, 17 Mar 2015 09:04: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 Yn6gAqDhmrmO; Tue, 17 Mar 2015 09:04:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EF41A870B; Tue, 17 Mar 2015 09:03:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , , , ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150317160357.20184.49931.idtracker@ietfa.amsl.com>
Date: Tue, 17 Mar 2015 09:03:57 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Netconf] ID Tracker State Update Notice: 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 16:04:20 -0000

IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/


From nobody Tue Mar 17 09:04:48 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91771A8722; Tue, 17 Mar 2015 09:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 jwGeL34AyzoK; Tue, 17 Mar 2015 09:04:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6F71A8704; Tue, 17 Mar 2015 09:04:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , , , ,  , , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150317160414.19850.64987.idtracker@ietfa.amsl.com>
Date: Tue, 17 Mar 2015 09:04:14 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Netconf] Telechat update notice: 
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Mar 2015 16:04:44 -0000

Placed on agenda for telechat - 2015-04-09
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/


From nobody Tue Mar 17 14:02:30 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E191A1B7F for ; Tue, 17 Mar 2015 14:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 2Pu2Jl1kYP3h for ; Tue, 17 Mar 2015 14:02:26 -0700 (PDT)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834FC1A1B77 for ; Tue, 17 Mar 2015 14:02:26 -0700 (PDT)
Received: by lbcds1 with SMTP id ds1so16331594lbc.3 for ; Tue, 17 Mar 2015 14:02:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YX79+0HCpxhHnfCoi7eJk+HT3sacJn9qD2ItZ0I1CK8=; b=k5zaqAGLBuLrrhADBCPZY+fAe+XFASsbhAPpCi44KZ9WxRD+iR6DocFjiT7kgpgHoI l7r2TN9rcxxU61V0YSkdTUWY3Mdezq+QVu6mzdiLUEw4xy7yNK+UACrTK3H9qYw5CCTt pgC43/u8sebAxV2q6EMQv7ZGUguoFBWTCm5kImt4kFOZIwKitA0lWEQbNLGMto0nyNSU yNvIg0Z30EE9KEDr6TOzs/3lLbX3d9WOodStXejLeO8hsJV6kJUUg8zVgfkeKID0VsgA axd3FP4L+Q7DBxOpCiFkTcivWInxdZv1aPTnkq/sNqdmYkP0zybN5hqb+SSLx82+wgxV AYrw==
X-Gm-Message-State: ALoCoQnsNHiAyldzly3Ahn4vd87vjDZygcyAHC7iyN3Qb0z5RBmTAmN8LTYHuvNlWYh7NHnMuhnw
MIME-Version: 1.0
X-Received: by 10.112.42.164 with SMTP id p4mr54744559lbl.119.1426626144967; Tue, 17 Mar 2015 14:02:24 -0700 (PDT)
Received: by 10.112.144.36 with HTTP; Tue, 17 Mar 2015 14:02:24 -0700 (PDT)
In-Reply-To: <20150303.091221.1320688875820544524.mbj@tail-f.com>
References:  <201503030346.t233k2Qt036627@idle.juniper.net>  <20150303.091221.1320688875820544524.mbj@tail-f.com>
Date: Tue, 17 Mar 2015 14:02:24 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] WG Last Call review of draft-ietf-netconf-restconf-04
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, 17 Mar 2015 21:02:29 -0000

On Tue, Mar 3, 2015 at 12:12 AM, Martin Bjorklund  wrote:
> Andy Bierman  wrote:
>> On Mon, Mar 2, 2015 at 7:46 PM, Phil Shafer  wrote:
>> > Andy Bierman writes:
>> >>RESTCONF edit operations are done on data resources.
>> >>NETCONF  is not resource-oriented.
>> >>
>> >>YANG Patch edits are ordered.
>> >>NETCONF  order (and whether or not a real
>> >>edit is invoked) is implementation-dependent.
>> >>
>> >>YANG Patch might allow edits to be encoded more efficiently
>> >>since the config 'scaffolding' is not part of the each edit.
>> >>Operations such as 'move' are explicit and more efficient
>> >>to encode than YANG insert.
>> >
>> > That's a really short list, and it looks like the first and last
>> > are the same (since "data resource" means a path into a datastore,
>> > right?).
>> >
>> > Encoding efficiency aside, what's the big innovation in yang-patch?
>> > If it's really just putting multiple change payloads in a single
>> > request such that any of them can fail independently, aren't we
>> > better served by adding this to edit-config, perhaps as a sister
>> > attribute to "op"?
>> >
>>
>> What is so great about the implementation-dependent  blob?
>> Why are a set of attributes (1 in NETCONF, the rest defined in YANG)
>> better than an edit list?
>
> To be fair, I think Phil is right in that the expressiveness of both
> formats are equal.  Which one you prefer is subjective, possibly
> influenced by implementation choices.
>
> The question boils down to if we think it is good to have two more or
> less equal ways of doing things, or if there is value in having one
> single mechanism.
>

This is an important issue to decide because starting over on
the multiple-edits-per-PATCH problem will take awhile.

My motivations for writing YANG Patch, instead of using
the  blob approach:

  1) RESTCONF is supposed to be resource oriented.
      Patching resources vs. patching the entire 
      is an architectural distinction, but that matters to some people

  2)  patch relies on meta-data encoded as XML attributes.
      The JSON attributes solution requires much more server resources.
      I'm not sure there is a CBOR attributes solution for CoMI.
      A solution that does not need meta-data peppered throughout
      the message will be more encoding-neutral.

  3) There are some corner-cases (e.g., nested operation attributes,
       duplicate sub-trees in the edit-config, edit ordering) that
       are very implementation-dependent.  It is possible that an
       ordered edit list will increase predictable server processing of
       edits, but I agree this is just an assumption on my part.


 4) The implementation requirements for  are not
      that clear in RFC 6241.  I have seen some server limitations
      that are never mentioned in the RFC, like inability to create
      multiple list entries at once.  The yang-patch-status response message
      is more granular than , which could allow better
      error messages for implementation-specific error conditions.

I am not 100% opposed to starting over on YANG Patch,
but the solution "just use  is not good enough.


Andy


>> I have heard some comments that the patch approach is more direct
>> and easier for the client to convey its intent.  A set of ordered edits
>> provides more client control for setting up dependencies.
>
> Even with YANG PATCH, it is the resulting datastore that is validated,
> so the order of the edits doesn't matter.
>
>
> /martin
>
>
>> IMO the NETCONF encoding of an edit is irrelevant to RESTCONF.
>> RESTCONF does not use an  element wrapper for operations
>> either. Most (if not all) of the message encoding details are different.
>>
>>
>> > Thanks,
>> >  Phil
>> >
>> > P.s.: The term "urlpath" sounds odd; URLs _are_ paths, right?
>>
>>
>> Andy
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>


From nobody Wed Mar 18 15:40:47 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEB61A8905 for ; Wed, 18 Mar 2015 15:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 2KJxvto0LEnE for ; Wed, 18 Mar 2015 15:40:37 -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 1FC0A1A8927 for ; Wed, 18 Mar 2015 15:40:36 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4323110AC; Wed, 18 Mar 2015 23:40:35 +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 K28gPYSzuo27; Wed, 18 Mar 2015 23:40:17 +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; Wed, 18 Mar 2015 23:40:33 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1022D20057; Wed, 18 Mar 2015 23:40:33 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vx-Kq0WOUnAn; Wed, 18 Mar 2015 23:40:31 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CFFF20056; Wed, 18 Mar 2015 23:40:31 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 49EC0327DD39; Wed, 18 Mar 2015 23:40:29 +0100 (CET)
Date: Wed, 18 Mar 2015 23:40:28 +0100
From: Juergen Schoenwaelder 
To: "netconf@ietf.org" 
Message-ID: <20150318224028.GA38182@elstar.local>
Mail-Followup-To: "netconf@ietf.org" , "Ersue, Mehmet (Nokia - DE/Munich)" 
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: 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Mar 2015 22:40:45 -0000

On Tue, Mar 03, 2015 at 10:16:21PM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote:
> Dear NETCONF WG,
> 
> we hereby issue a WG Last Call for 2 weeks for the drafts below:
> 
> https://tools.ietf.org/html/draft-ietf-netconf-call-home-04
> https://tools.ietf.org/html/draft-ietf-netconf-server-model-06
> 
> Please review and send your comments to the NETCONF WG mailing list by March 17, 2015 EOB PT.
>

Here is my review of draft-ietf-netconf-server-model-06:

* sec 2.4: What is 'TLS _transport-level_ authentication'? Why not
  just use 'TLS authentication' or perhaps even clearer 'TLS client
  authentication'?

* sec 2.6: Do we really need 'northbound application' terminology? Why
  not call it simply a NETCONF/RESTCONF client? There might also be
  possible confusion with phrases such as "Assuming an application has
  more than one server" - the server here seems to be the NETCONF
  client to call home to. Anyway, if we do need new terminology, I
  think we should properly define it to avoid any confusion.

* sec 3: Is it a good idea to name the top-level node netconf-server?
  Is this name consistent with how we name other things?

* sec 3: Can I have a server listening for SSH and accepting call home
  over TLS? Would features work out in such a case or would such a
  server make a client believe that the server is also allowing call
  home via SSH and incoming connections via TLS?
   
* sec 3.1.4: s/when RFC 6187 is supported/when X.509v3 certificates for SSH are supported [RFC6187]/

* sec 3: Are certificates sometimes represented as strings and
  sometimes represented as binary?

* sec 4: Is it a good idea to name the top-level node restconf-server?
  Is this name consistent with how we name other things? (see also above)

* sec 3.2: also mention that the module imports an extension from [RFC6536].

* sec 3.2:

  - is import by revision needed?

  - s/supports RFC 6187/supports X.509v3 certificates for SSH authentication/

  - Are groupings useful that are only used once? Are they really
    improving readability?

  - s/issuing RPC requests/carrying any NETCONF messages/

  - is there any motivation for the upper bounds of hello-timeout and
    idle-timeout?

  - better description for 'listen'?

  - is there a motivation for the upper bound of max-sessions?

  - why is max-sessions part of the listen subtree? do call home
    sessions count in here as well? it seems that max-session may be
    another global session parameter

  - neither address nor port are mandatory for a listening endpoint;
    since the port has a default, should address be mandatory?

  - is it useful to reference the RFC itself in a reference clause of
    a specific leaf (e.g., 'keep-alives' given that there is a
    'global' reference to the RFC? Probably it is useful since it
    references a specific section but then the section references
    does not make much sense...

  - better description for 'call-home'?

  - The description of 'application' talks about NETCONF clients, so
    application == NETCONF clients?

  - is there a motivation for the 15 seconds default for the call home
    keep alive timer?

  - is there a motivation for 30 seconds default linger time and 5
    minutes default reconnect time?

  - What is the meaning of "NETCONF servers SHOULD support this flag
    across reboots."? Perhaps it is clearer if the text said "NETCONF
    servers SHOULD be able to remember the last endpoint connected to
    across reboots".

  - how do interval-secs and count-max work for reconnect-strategy if
    an endpoint resolves to multiple IP addresses? Does the
    interval-secs apply every address of an endpoint or to all
    addresses of an endpoint? Does count-max increment for each
    address of an endpoint or just once for a given endpoint?

  - would it make sense to introduce a typedef for the X509
    certificates?

  - for certs, we copy binary certs into the config but for ssh host
    keys, we reference them using some strings that act as unique
    identifiers into an undefined pool of host keys. This is somewhat
    asymmetric and how do I configure a host-key without knowing which
    host keys the box has available? The problem likely is that we
    lack a generic infrastructure for managing SSH and TLS
    credentials. But would the approach to model pools of keys not be
    the more practical solution?

* sec 4.2: also	mention that the module imports an extension from [RFC6536].

* sec 4.2:

  - is import by revision needed?

  - would it not make sense to factor out some common groupings so
    that things can be reused instead of being defined multiple times?

  - what is "RFC ZZZZ: Client Authentication over New TLS Connection"?
    the editor instructions refer to draft-thomson-httpbis-cant but
    this one does not exist anymore?

  - several of the comments for the netconf server module also apply
    to the restconf server module - I am not repeating them here,
    assuming that any changes will be applied consistently anyway

* sec 5: remove the first sentence?

* sec 5.2: is this document the right place to require (MUST) that
  call home servers advertise "peer_allowed_to_send" per [RFC6520]?
  If this is a general requirement, should it not be in the call home
  document?

* sec 6: the 2nd paragraph should also refer to ietf-restconf-server

* sec 6: there may be more that is worth saying, e.g., that
  misconfigured call home server could be used to DDOS some other
  victim by repeatedly connecting and starting a TLS conversation.

* sec A: please use IP addresses reserved for documentation in the
  examples.

/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 Thu Mar 19 16:05:14 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AA31B2AFD for ; Thu, 19 Mar 2015 16:05:12 -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 p3SQFvxpQB4U for ; Thu, 19 Mar 2015 16:05:10 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE991B2AFB for ; Thu, 19 Mar 2015 16:05:09 -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.1.118.21; Thu, 19 Mar 2015 23:04:52 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Thu, 19 Mar 2015 23:04:52 +0000
From: Kent Watsen 
To: Martin Bjorklund , "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj review of draft-ietf-netconf-server-model-06
Thread-Index: AQHQYL6S+j6YNW/SlUizUEUwx0xDKZ0kLamA
Date: Thu, 19 Mar 2015 23:04:52 +0000
Message-ID: 
References: <20150317.152756.1341316749588622343.mbj@tail-f.com>
In-Reply-To: <20150317.152756.1341316749588622343.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-originating-ip: [66.129.239.12]
authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(54356999)(122556002)(230783001)(50986999)(66066001)(87936001)(2656002)(36756003)(76176999)(86362001)(99286002)(83506001)(2501003)(106116001)(102836002)(2900100001)(92566002)(2950100001)(62966003)(107886001)(46102003)(77156002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 052017CAF1
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2015 23:04:52.2513 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: Re: [Netconf] mbj review of draft-ietf-netconf-server-model-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, 19 Mar 2015 23:05:12 -0000

Martin,

Thank you for your review.  I'll make the changes you recommended.


>o  The hello-timeout has this range:
>
>          range "0 | 10 .. 3600";
>
>   Why not allow values 1..9?  This seems like an arbitrary range to
>   me.

This YANG snippet came from Andy.  I'm not sure why 1-hour was picked.



>o  call-home / application / connection-type
>
>  The call-home draft mentions this objective:
>
>   o  The network element may proactively call home after being powered
>      on for the first time in order to register itself with its
>      management system.
>
>  How is this use case supported in this model?

The zerotouch draft discusses how a network element can obtain an initial
configuration during factory-default power on.  Example A.3 in that draft
uses=20
the module defined in this draft.  The server-model enables NETCONF Call
Home to be configured, that's all.  Is there a specific change in the text
you're hoping to see in this draft?




>  It also mentions:
>
>   o  The network element may access the network in a way that
>      dynamically assigns it an IP address and it doesn't register its
>      assigned IP addressed to a mapping service, thus complicating the
>      ability for a management system to connect to it.
>
>  How is this use case supported in this model?

This bullet point is supported by the NETCONF Call Home, by the device
initiating the TCP connection.  That is, the solution does not rely on
the network element's IP address in any way, it could be static, dynamic,
NAT-ed, or whatever.  The server-model merely enables NETCONF Call Home
to be configured, but doesn't realize this benefit itself.  Is there a
specific change in the text you're hoping to see in this draft?




>o  call-home / application / connection-type / periodic-connention
>
>   The leaf timeout-mins is of type uint8.  Isn't this a bit small?  I
>   think this should be uint16.

Perhaps.  256 minutes is a little more than 4 hours, which in my world
seems like a crazy amount of time for a device to not be connected to its
management system.  That said, I grant you that there are likely some
elements that don't call home but once a day, or maybe even longer.
Further, it's no effort to change to a uint16, so why not?

But I wonder, would it be better to have a 2-tuple whereby one value is a
number and the other is an enum for minutes, hours, and days?



>   Also, the text says that a device "should" pro-actively connect to
>   the client if it has messages to send.  Maybe this is is good
>   enough, but in a deployment with *lots* of devices, maybe you want
>   to suppress such messages to a time window when the client is
>   prepared to handle it.  Again, maybe this use case is better done
>   with a new type of connection-type ("absolute-time" or something),
>   and such a container can be augmented later.  I just wonder if you
>   thought about this use case.

I think you mean "to a time window when the *server* is prepared to handle
it."

The thinking behind this is that the message could be a fault or security
alert that should be delivered with haste, without regards for the
data-collection system's scalability.  That said, I can easily support the
idea of the device buffering low-priority messages and perhaps high-
priority messages too, if that's how it's been designed or configured
- so be it.

Perhaps the SHOULD should be a MAY?  The point is to call out that it's
possible for a device to connect sooner than it's periodic timeout would
have it do.  It's one thing to connect just in case the NETCONF client
has pending messages for the device, and yet another for if the device
itself have something to send.  Maybe there should be two timeouts - one
for each of these cases?  Or nix the whole idea with the assumption the
device has a replay-buffer that the NETCONF client can pull previous
messages from?




>o  tls / client-auth
>
>   Why do we need both trusted-client-certs and cert-maps?

Trusted-client-certs (and trusted-ca-certs) is used by the TLS-layer to
validate the client's certificate.  Separately, cert-maps is used by the
NETCONF/RESTCONF layers to extract a username from the client's
certificate.  Makes sense?



>   Also, I think the text doesn't describe how the "trusted-ca-certs"
>   leaf-list should be used.  The cert-to-name list has this:
>
>         2) If the cert-to-name list entry's fingerprint value
>            matches that of a locally held copy of a trusted CA
>            certificate, [...]
>
>   So I *think* the intention is that the configured
>   "trusted-ca-certs" leaf list is supposed to provide these "locally
>   held copy".

Agreed.  This text was inherited from 5539bis, but looking at it now, it
also doesn't look right to me.


>   Also, is it a bug or a faeture that we have two separate leaf-lists
>   of trusted-ca-certs, one for ssh and one for tls?

It was meant to maximize flexibility, but I don't think it makes sense for
the netconf server to differentiate trusted CA or client-certs by
transport protocol.  Do you agree?


>  Also, is the word "NETCONF client" correct here?  Ths point is that
>  the keep-alive message in on the transport layer.

Unsure.  On one hand, each NETCONF message is a transport-level message
but, on the other hand, it is technically a transport-level message that
matters.   Would you rather see "SSH/TLS client"?


>I plan to implement the data model in this document for NETCONF over
>SSH, and RESTCONF over TLS "soon".

Exciting.  Hopefully one more round of edits will stabilize the model.
I will update the reference code on Github to support the final model
as well.


Thanks,
Kent


From nobody Thu Mar 19 18:26:42 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558821A8A66 for ; Thu, 19 Mar 2015 18:26: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, 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 UaV0l2oqE8Ah for ; Thu, 19 Mar 2015 18:26:37 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171D71A8A54 for ; Thu, 19 Mar 2015 18:26:37 -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.112.19; Fri, 20 Mar 2015 01:26:34 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Fri, 20 Mar 2015 01:26:34 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "netconf@ietf.org" 
Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
Thread-Index: AQHQVf+tT/7bNpWPUkyuK74/P/SDo50i7REAgAF9rYA=
Date: Fri, 20 Mar 2015 01:26:34 +0000
Message-ID: 
References:  <20150318224028.GA38182@elstar.local>
In-Reply-To: <20150318224028.GA38182@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-originating-ip: [66.129.239.12]
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(76104003)(164054003)(51444003)(52314003)(51704005)(99286002)(106116001)(2950100001)(2900100001)(2501003)(107886001)(36756003)(40100003)(122556002)(2656002)(46102003)(551544002)(87936001)(102836002)(15975445007)(86362001)(76176999)(54356999)(50986999)(230783001)(66066001)(92566002)(62966003)(77156002)(83506001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 05214FD68E
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6A6346609E01E441B5B54A093731CA34@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2015 01:26:34.2030 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 20 Mar 2015 01:26:40 -0000

>* sec 2.4: What is 'TLS _transport-level_ authentication'? Why not
>  just use 'TLS authentication' or perhaps even clearer 'TLS client
>  authentication'?

Good catch.  Will use "TLS client authentication"


>* sec 2.6: Do we really need 'northbound application' terminology? Why
>  not call it simply a NETCONF/RESTCONF client? There might also be
>  possible confusion with phrases such as "Assuming an application has
>  more than one server" - the server here seems to be the NETCONF
>  client to call home to. Anyway, if we do need new terminology, I
>  think we should properly define it to avoid any confusion.

The term "application" is coming from the YANG model, where we have:

   module: ietf-netconf-server
      +--rw netconf-server
         +--rw call-home {call-home}?
            +--rw application* [name]
               ...

My intent was to pick a term that would make sense in GUI and CLI.  But
maybe this is better:

   module: ietf-netconf-server
      +--rw netconf-server
         +--rw call-home {call-home}?
            +--rw netconf-client* [name]
               ...

What do you think?   The term used throughout the draft will fallout from
this.  If we decide to use "application", I will add a proper Terminology
section, per Martin's comment.



>* sec 3: Is it a good idea to name the top-level node netconf-server?
>  Is this name consistent with how we name other things?

What else would you have?  FWIW, RFC 6022 has "netconf-state".

In case it helps, example A.1 shows:

  
    ...
    ...

    ...
    ...
  



>* sec 3: Can I have a server listening for SSH and accepting call home
>  over TLS? Would features work out in such a case or would such a
>  server make a client believe that the server is also allowing call
>  home via SSH and incoming connections via TLS?

You can certainly configure that, but the model doesn't support the
NETCONF server being able to only support those specific variations.
This is why I was trying to use the YANG 1.1 style if-feature statements
in -04.  We could use long feature names to cover these specific
variations, but I didn't think it worth the bother.  Do you?



>* sec 3: Are certificates sometimes represented as strings and
>  sometimes represented as binary?

That's an oversight, they should all be binary.



>* sec 4: Is it a good idea to name the top-level node restconf-server?
>  Is this name consistent with how we name other things? (see also above)

Let's apply the resolution to the above comment here as well.



>* sec 3.2:
>
>  - is import by revision needed?

At the time I submitted this draft, it was my understanding that import by
revision was best practice, and that prior YANG modules were in violation.
 Recent YANG 1.1 conformance discussions seem to be swinging the other
direction now, but with potential to swing back again.  I don't know what
to *right* thing to do is.   Perhaps taking it out is the way to go
because, even if it's wrong, it will at least be in the company of other
published modules  ;)


>  - Are groupings useful that are only used once? Are they really
>    improving readability?

Guess not.  I tried twice, but it doesn't seem popular.  I will remove all
groupings that are used only once.


>  - is there any motivation for the upper bounds of hello-timeout and
>    idle-timeout?

This came from a YANG snippet Andy provided.  I'm sure that it's along the
lines of "if more than an hour, it might as well use infinity".
Personally, I don't see a reason to limit it, but I do think that only
having "seconds" units can become unwieldy and thus might suggest a
2-tuple whereby one value is a numeric and the other an enum like
{seconds, minutes, hours, days}.  What do you think?


>  - is there a motivation for the upper bound of max-sessions?

This YANG snippet also came from Andy, but I don't see a reason to limit
it here.   Andy?


>  - why is max-sessions part of the listen subtree? do call home
>    sessions count in here as well? it seems that max-session may be
>    another global session parameter

Yes, this makes sense to me as well, though what happens if we get into
the pathological case of the number of call-home sessions configured is
greater than the configured max-sessions count?  Is there a way to write
a validation expression to test for this?


>  - neither address nor port are mandatory for a listening endpoint;
>    since the port has a default, should address be mandatory?

Sounds reasonable.  An alternative might be to have a default to represent
"all configured interfaces" - what do you think?


>  - is it useful to reference the RFC itself in a reference clause of
>    a specific leaf (e.g., 'keep-alives' given that there is a
>    'global' reference to the RFC? Probably it is useful since it
>    references a specific section but then the section references
>    does not make much sense...

Maybe only mildly useful, but definitely inconsistent to other YANG
modules.  Take it out?



>  - The description of 'application' talks about NETCONF clients, so
>    application =3D=3D NETCONF clients?

Yes.  This is related to comment above as well.



>  - is there a motivation for the 15 seconds default for the call home
>    keep alive timer?
>  - is there a motivation for 30 seconds default linger time and 5
>    minutes default reconnect time?

For all of these, I just figured they were sensible choices.  Do they
seem OK to you?


>  - What is the meaning of "NETCONF servers SHOULD support this flag
>    across reboots."? Perhaps it is clearer if the text said "NETCONF
>    servers SHOULD be able to remember the last endpoint connected to
>    across reboots".

Martin had a similar comment - will clarify in the text


>  - how do interval-secs and count-max work for reconnect-strategy if
>    an endpoint resolves to multiple IP addresses? Does the
>    interval-secs apply every address of an endpoint or to all
>    addresses of an endpoint? Does count-max increment for each
>    address of an endpoint or just once for a given endpoint?

Interesting point, that a hostname may expand into a list of IPs.  What
makes sense to me is that the list of IPs would be treated as if they were
specified explicitly.  For example, let's say a configured application
(netconf client?) has 3 endpoints (EP1, EP2, and EP3), but they're all
hostnames that expand into two IP addresses, then the netconf server
behavior would be as if it had them configured explicitly: EP1.1, EP1.2,
EP2.1, EP2.2, EP3.1, EP3.2.  That is, with would try EP1.1 count-max times
before trying EP1.2 count-max times, and so on. Does this also make sense
to you?  If so, then I think that it's just a matter of writing it up so
the text spells it out.





>  - would it make sense to introduce a typedef for the X509
>    certificates?

Maybe, but I wonder if you're saying this after seeing this:

      leaf-list certificate {
        type string;
        min-elements 1;
        description
          "An unordered list of certificates the TLS server can pick
           from when sending its Server Certificate message.  The value
           of the string is the unique identifier for a certificate
           configured on the system.  How valid values are discovered
           is outside the scope of this module, but they are envisioned
           to be the keys for a list of certificates provided
           by another YANG module";
        reference
          "RFC 5246: The TLS Protocol, Section 7.4.2";
      }


Or this?

      leaf-list trusted-ca-cert {
        type binary;
        ordered-by system;
        nacm:default-deny-write;
        description
          "The binary certificate structure as specified by RFC
           5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
          ";


The former was by yours truly later was lifted from another draft.  My
plan from Martin's review was to make the former look like the later, but
you think a typedef would be better?



>  - for certs, we copy binary certs into the config but for ssh host
>    keys, we reference them using some strings that act as unique
>    identifiers into an undefined pool of host keys. This is somewhat
>    asymmetric and how do I configure a host-key without knowing which
>    host keys the box has available? The problem likely is that we
>    lack a generic infrastructure for managing SSH and TLS
>    credentials. But would the approach to model pools of keys not be
>    the more practical solution?


The binary certs we're copying into the configuration are being used for
client-cert authentication.  Here I'm referring to
/netconf-server/[ssh|tls]/x509/trusted-ca-certs and
/netconf-server/[ssh|tls]/x509/trusted-client-certs.  There is no SSH
equivalent for authenticating clients when the clients use password or key
based authentication, because ietf-system.yang module from 7317 does it
already.  So, yes, there is an asymmetry here, but what can we do?

Separately, there is configuration for what host-keys the SSH-server
presents and what server-certificates the TLS-server presents.  Here I'm
referring to=20
/netconf-server/listen/endpoint/[ssh/host-keys|tls/certificates] and
/netconf-server/call-home/application/[ssh/host-keys|tls/certificates].
Currently these are as you say, a named reference to a value presumed to
be configured elsewhere.  The good news is that how this is done is
symmetric for both SSH and TLS.  As for modeling pools of keys, I think
that this is what sever-model-04 had - read-only lists of SSH host-keys
and certificates just so they could be referenced here.  This was
discussed at IETF 91 meeting with the resolution to remove them from this
draft.  This issue was tracked here as well:
https://github.com/netconf-wg/server-model/issues/20.



>  - would it not make sense to factor out some common groupings so
>    that things can be reused instead of being defined multiple times?

Do you mean between the ietf-netconf-server and ietf-restconf-server
modules?


>  - what is "RFC ZZZZ: Client Authentication over New TLS Connection"?
>    the editor instructions refer to draft-thomson-httpbis-cant but
>    this one does not exist anymore?

It is here, but expired:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01

I've been discussing with Martin Thomson about it.  I'll probably work
with him in the httpbis WG to resurrect it and get it done.


>  - several of the comments for the netconf server module also apply
>    to the restconf server module - I am not repeating them here,
>    assuming that any changes will be applied consistently anyway

Yes, understood, symmetric changes would be made to both


>* sec 5.2: is this document the right place to require (MUST) that
>  call home servers advertise "peer_allowed_to_send" per [RFC6520]?
>  If this is a general requirement, should it not be in the call home
>  document?

Er, yes, I think that you're right


>* sec A: please use IP addresses reserved for documentation in the
>  examples.

I didn't know there was such a thing - can you provide a pointer to the
RFC for this?


Thanks,
Kent


From nobody Fri Mar 20 02:06:38 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C739D1B2C86 for ; Fri, 20 Mar 2015 02:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qDPn6o7uQiSd for ; Fri, 20 Mar 2015 02:06: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 D129A1B2C7F for ; Fri, 20 Mar 2015 02:06:34 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id D769E128040A; Fri, 20 Mar 2015 10:06:33 +0100 (CET)
Date: Fri, 20 Mar 2015 10:06:31 +0100 (CET)
Message-Id: <20150320.100631.1774932159082288559.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: 
References:  <20150318224028.GA38182@elstar.local> 
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: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 20 Mar 2015 09:06:37 -0000

Kent Watsen  wrote:
> >  - is it useful to reference the RFC itself in a reference clause of
> >    a specific leaf (e.g., 'keep-alives' given that there is a
> >    'global' reference to the RFC? Probably it is useful since it
> >    references a specific section but then the section references
> >    does not make much sense...
> 
> Maybe only mildly useful, but definitely inconsistent to other YANG
> modules.  Take it out?

I think you should keep it for this leaf.  The reason is that
otherwise it becomes unclear what keep alive means.  (this was the
reason we added the reference in the first place ;)


/martin


From nobody Fri Mar 20 04:12:42 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C6D1B2C4D for ; Fri, 20 Mar 2015 04:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 qJxIF_X3czC1 for ; Fri, 20 Mar 2015 04:12:35 -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 254711A896E for ; Fri, 20 Mar 2015 04:12:35 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7BDBB6A5; Fri, 20 Mar 2015 12:12:33 +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 ZO1NVorg7Bu1; Fri, 20 Mar 2015 12:12:07 +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, 20 Mar 2015 12:12:32 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA9D72002B; Fri, 20 Mar 2015 12:12:32 +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 BKS70if1LAoB; Fri, 20 Mar 2015 12:12:31 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45CE72002C; Fri, 20 Mar 2015 12:12:31 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E4ED4327E93D; Fri, 20 Mar 2015 12:12:29 +0100 (CET)
Date: Fri, 20 Mar 2015 12:12:29 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20150320111228.GA43672@elstar.local>
Mail-Followup-To: Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org
References:  <20150318224028.GA38182@elstar.local>  <20150320.100631.1774932159082288559.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150320.100631.1774932159082288559.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 20 Mar 2015 11:12:40 -0000

On Fri, Mar 20, 2015 at 10:06:31AM +0100, Martin Bjorklund wrote:
> Kent Watsen  wrote:
> > >  - is it useful to reference the RFC itself in a reference clause of
> > >    a specific leaf (e.g., 'keep-alives' given that there is a
> > >    'global' reference to the RFC? Probably it is useful since it
> > >    references a specific section but then the section references
> > >    does not make much sense...
> > 
> > Maybe only mildly useful, but definitely inconsistent to other YANG
> > modules.  Take it out?
> 
> I think you should keep it for this leaf.  The reason is that
> otherwise it becomes unclear what keep alive means.  (this was the
> reason we added the reference in the first place ;)
>

Well, if it is unclear, why not add text to the description to make it
clearer?

/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 Mar 20 07:51:51 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1061ACC91 for ; Fri, 20 Mar 2015 07:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 lfW1HuULaWoT for ; Fri, 20 Mar 2015 07:51:48 -0700 (PDT)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35E51A01EA for ; Fri, 20 Mar 2015 07:51:43 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id t2KEmlSt017511 for ; Fri, 20 Mar 2015 07:51:43 -0700
Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0a-0016f401.pphosted.com with ESMTP id 1t85thsxwe-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 20 Mar 2015 07:51:43 -0700
Received: from IL-EXCH02.marvell.com (10.4.102.221) by SC-OWA04.marvell.com (10.93.76.33) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 20 Mar 2015 07:51:42 -0700
Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 20 Mar 2015 16:51:39 +0200
Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1044.021; Fri, 20 Mar 2015 16:51:39 +0200
From: Tal Mizrahi 
To: "netconf@ietf.org" 
Thread-Topic: Time Capability in NETCONF
Thread-Index: AdBjHSKNj0rSTvlhTaycu5I+YXT19Q==
Date: Fri, 20 Mar 2015 14:51:38 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [199.203.130.14]
Content-Type: multipart/alternative; boundary="_000_d6650b9886c04e66ae049e83e42e2f11ILEXCH01marvellcom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33,  0.0.0000 definitions=2015-03-20_05:2015-03-20,2015-03-20,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503200151
Archived-At: 
Subject: [Netconf] Time Capability in NETCONF
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2015 14:51:49 -0000

--_000_d6650b9886c04e66ae049e83e42e2f11ILEXCH01marvellcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

We would like to solicit feedback about draft-mm-netconf-time-capability.
https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/

This draft has been around for a while. We received a lot of feedback, and =
made an effort to address all the comments.

We believe the time capability can be a very useful tool for network config=
uration, and we believe the current draft is ready for WG adoption.

Comments will be welcome.

Cheers,
Tal Mizrahi.


--_000_d6650b9886c04e66ae049e83e42e2f11ILEXCH01marvellcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,



We would like to solicit feedback about draft-mm-netconf-time-capability.
https://datatracker.ietf.org/doc/d=
raft-mm-netconf-time-capability/



This draft has been around for a while. We received a lot of feedback, and<=
span class=3D"apple-converted-space"> made an effort to address=
 all the comments.



We believe the time capability can be a very useful tool for network configuration, and we believe t=
he current draft is ready for WG adoption.



Comments will be welcome.



Cheers,

Tal Mizrahi.


 






--_000_d6650b9886c04e66ae049e83e42e2f11ILEXCH01marvellcom_--


From nobody Fri Mar 20 08:01:20 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B72D1B2E4A for ; Fri, 20 Mar 2015 08:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 DX-NenipSWbL for ; Fri, 20 Mar 2015 08:01:16 -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 98FCC1B2E31 for ; Fri, 20 Mar 2015 08:01:15 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6EDF06FC; Fri, 20 Mar 2015 16:01:14 +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 gb9ErZ4wUYCu; Fri, 20 Mar 2015 16:00:47 +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, 20 Mar 2015 16:01:13 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91DF720031; Fri, 20 Mar 2015 16:01:13 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id E5jnOg1hXoEV; Fri, 20 Mar 2015 16:01:13 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC84220013; Fri, 20 Mar 2015 16:01:10 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id BB2B5327EA61; Fri, 20 Mar 2015 16:01:09 +0100 (CET)
Date: Fri, 20 Mar 2015 16:01:09 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20150320150108.GA44313@elstar.local>
Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" 
References: <20150317.152756.1341316749588622343.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: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] mbj review of draft-ietf-netconf-server-model-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: Fri, 20 Mar 2015 15:01:18 -0000

On Thu, Mar 19, 2015 at 11:04:52PM +0000, Kent Watsen wrote:
> 
> 
> >o  call-home / application / connection-type / periodic-connention
> >
> >   The leaf timeout-mins is of type uint8.  Isn't this a bit small?  I
> >   think this should be uint16.
> 
> Perhaps.  256 minutes is a little more than 4 hours, which in my world
> seems like a crazy amount of time for a device to not be connected to its
> management system.  That said, I grant you that there are likely some
> elements that don't call home but once a day, or maybe even longer.
> Further, it's no effort to change to a uint16, so why not?
> 
> But I wonder, would it be better to have a 2-tuple whereby one value is a
> number and the other is an enum for minutes, hours, and days?
>

I do not think that a 2-tuple makes the _programmatic_ interface
easier.

/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 Mar 20 08:32:23 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23401A01EC for ; Fri, 20 Mar 2015 08:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level: 
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, 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 RDOm1mD6HHki for ; Fri, 20 Mar 2015 08:32:20 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 92B7C1A005F for ; Fri, 20 Mar 2015 08:32:20 -0700 (PDT)
Received: from mars.tail-f.com (mars.tail-f.com [192.168.1.70]) by mail.tail-f.com (Postfix) with ESMTPSA id AE32D128040A; Fri, 20 Mar 2015 16:32:19 +0100 (CET)
Message-ID: <550C3D83.4020505@tail-f.com>
Date: Fri, 20 Mar 2015 16:32:19 +0100
From: Per Hedeland 
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Juergen Schoenwaelder 
References: <20150317.152756.1341316749588622343.mbj@tail-f.com>  <20150320150108.GA44313@elstar.local>
In-Reply-To: <20150320150108.GA44313@elstar.local>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] mbj review of draft-ietf-netconf-server-model-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, 20 Mar 2015 15:32:22 -0000

On 2015-03-20 16:01, Juergen Schoenwaelder wrote:
> On Thu, Mar 19, 2015 at 11:04:52PM +0000, Kent Watsen wrote:
>>
>>
>>> o  call-home / application / connection-type / periodic-connention
>>>
>>>   The leaf timeout-mins is of type uint8.  Isn't this a bit small?  I
>>>   think this should be uint16.
>>
>> Perhaps.  256 minutes is a little more than 4 hours, which in my world
>> seems like a crazy amount of time for a device to not be connected to its
>> management system.  That said, I grant you that there are likely some
>> elements that don't call home but once a day, or maybe even longer.
>> Further, it's no effort to change to a uint16, so why not?
>>
>> But I wonder, would it be better to have a 2-tuple whereby one value is a
>> number and the other is an enum for minutes, hours, and days?
>>
> 
> I do not think that a 2-tuple makes the _programmatic_ interface
> easier.

Maybe ietf-yang-types should have something along the lines of
xsd:duration (http://www.w3.org/TR/xmlschema-2/#duration)?

--Per Hedeland


From nobody Fri Mar 20 08:46:27 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAEC1ACD52 for ; Fri, 20 Mar 2015 08:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 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] 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 jxygG-FSbWsc for ; Fri, 20 Mar 2015 08:46:24 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD6C51ACD4D for ; Fri, 20 Mar 2015 08:46:23 -0700 (PDT)
Received: by wibdy8 with SMTP id dy8so20458000wib.0 for ; Fri, 20 Mar 2015 08:46:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=/Rjy83PyAye22WjJroblZxcwhmOhn6cJurKst0NilKg=; b=EJjbYl1pZnCrShSZEK+HwfNkdgRL6ewlG2omQTlDfqOVv0DUm8rvyjJrfYn6G5Z/TN A7zuDKYVy0T8Oyx9D7TmGcMYO3PdaZkFh83BkO6/oD0/mOPOo+NdwYG0ZjPTfnBADGOy wduyl1EPsachzMCtLQf6fKsxhF6m8Smu/wcArAb4g4/xpoSKJd73Bl6ryHfj+SymiUb5 vJdj/jDPnS2JnD640LpKVmgvh0wWcsArS+Edr2qI+TbHIGHspsPxvt+3Bxfx8guvNiYz Uhug5fUWIz9QjbS4PpRUgyWA5M1EmR3p26HlLngqtdd1/eUFWfuTdWlC+qL8uLzKYxWC c6Hw==
X-Gm-Message-State: ALoCoQk6zyH0wYnGHT2JcQSZ96XDMTsiTgehGKReHUT1+5kigBsnCrqHRvxoFkQWBcaBfB52vIDM
MIME-Version: 1.0
X-Received: by 10.180.95.97 with SMTP id dj1mr6243079wib.43.1426866382484; Fri, 20 Mar 2015 08:46:22 -0700 (PDT)
Received: by 10.180.101.2 with HTTP; Fri, 20 Mar 2015 08:46:22 -0700 (PDT)
Date: Fri, 20 Mar 2015 11:46:22 -0400
Message-ID: 
From: Andrew Stone 
To: Netconf 
Content-Type: multipart/alternative; boundary=f46d0418251edec96b0511ba3721
Archived-At: 
Subject: [Netconf] Alarms?
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, 20 Mar 2015 15:46:26 -0000

--f46d0418251edec96b0511ba3721
Content-Type: text/plain; charset=UTF-8

Hi,

Is there any definition for alarms carried by NETCONF notifications?

I see some classic X.733 definitions in
https://tools.ietf.org/html/draft-ietf-netconf-notification-00#appendix-A
but I don't see anything in subsequent RFCs or https://github.com/YangModels
.

What are people using for alarms today?

Regards,
Andrew

--f46d0418251edec96b0511ba3721
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

Is there any definition for alar=
ms carried by NETCONF notifications?

I see some classic X.733 =
definitions in https://tools.ietf.org/html/draft-ietf-netconf-no=
tification-00#appendix-A but I don't see anything in subsequent RFC=
s or https://github.com/YangModel=
s.

What are people using for alarms today?
<=
div>
Regards,
Andrew


--f46d0418251edec96b0511ba3721--


From nobody Fri Mar 20 08:57:28 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E61ACD69 for ; Fri, 20 Mar 2015 08:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.26
X-Spam-Level: 
X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 W4ejn3JUgQJp for ; Fri, 20 Mar 2015 08:57:26 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EC31ACD61 for ; Fri, 20 Mar 2015 08:57: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 8A8144DA; Fri, 20 Mar 2015 16:57:25 +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 mtYglVEYKxwR; Fri, 20 Mar 2015 16:56:58 +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, 20 Mar 2015 16:57:24 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2E692002B; Fri, 20 Mar 2015 16:57:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tpEa3jW3Aamf; Fri, 20 Mar 2015 16:57:24 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 464D720013; Fri, 20 Mar 2015 16:57:23 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 69A80327EB1D; Fri, 20 Mar 2015 16:57:22 +0100 (CET)
Date: Fri, 20 Mar 2015 16:57:21 +0100
From: Juergen Schoenwaelder 
To: Per Hedeland 
Message-ID: <20150320155721.GA44471@elstar.local>
Mail-Followup-To: Per Hedeland , Kent Watsen , Martin Bjorklund , "netconf@ietf.org" 
References: <20150317.152756.1341316749588622343.mbj@tail-f.com>  <20150320150108.GA44313@elstar.local> <550C3D83.4020505@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <550C3D83.4020505@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] mbj review of draft-ietf-netconf-server-model-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: Fri, 20 Mar 2015 15:57:28 -0000

On Fri, Mar 20, 2015 at 04:32:19PM +0100, Per Hedeland wrote:
> On 2015-03-20 16:01, Juergen Schoenwaelder wrote:
> > On Thu, Mar 19, 2015 at 11:04:52PM +0000, Kent Watsen wrote:
> >>
> >>
> >>> o  call-home / application / connection-type / periodic-connention
> >>>
> >>>   The leaf timeout-mins is of type uint8.  Isn't this a bit small?  I
> >>>   think this should be uint16.
> >>
> >> Perhaps.  256 minutes is a little more than 4 hours, which in my world
> >> seems like a crazy amount of time for a device to not be connected to its
> >> management system.  That said, I grant you that there are likely some
> >> elements that don't call home but once a day, or maybe even longer.
> >> Further, it's no effort to change to a uint16, so why not?
> >>
> >> But I wonder, would it be better to have a 2-tuple whereby one value is a
> >> number and the other is an enum for minutes, hours, and days?
> >>
> > 
> > I do not think that a 2-tuple makes the _programmatic_ interface
> > easier.
> 
> Maybe ietf-yang-types should have something along the lines of
> xsd:duration (http://www.w3.org/TR/xmlschema-2/#duration)?
>

Yes, this might be a reasonable way to go if we want to move away from
a number with a fixed unit.

/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 Mar 20 11:31:45 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6B81A6F11 for ; Fri, 20 Mar 2015 11:31: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 u1DlP5UmqbQw for ; Fri, 20 Mar 2015 11:31:41 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329281A6F27 for ; Fri, 20 Mar 2015 11:31:41 -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.1.118.21; Fri, 20 Mar 2015 18:31:22 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Fri, 20 Mar 2015 18:31:23 +0000
From: Kent Watsen 
To: t.petch , "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" 
Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
Thread-Index: AQHQVf+tT/7bNpWPUkyuK74/P/SDo50McXkKgBkXmYA=
Date: Fri, 20 Mar 2015 18:31:22 +0000
Message-ID: 
References:  <032f01d0568d$7a8728c0$4001a8c0@gateway.2wire.net>
In-Reply-To: <032f01d0568d$7a8728c0$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-originating-ip: [66.129.239.12]
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(43784003)(164054003)(51444003)(51704005)(15975445007)(106116001)(62966003)(36756003)(86362001)(102836002)(77156002)(87936001)(107886001)(50986999)(54356999)(2656002)(2501003)(76176999)(83506001)(230783001)(122556002)(46102003)(40100003)(2950100001)(92566002)(2900100001)(66066001)(19580395003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 05214FD68E
Content-Type: text/plain; charset="us-ascii"
Content-ID: <204ED6939CEBD5409B1D0746D87C3E38@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2015 18:31:22.6348 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 20 Mar 2015 18:31:44 -0000

Hi Tom,

Thank you for this review, and the other focusing on section 3.2 of
call-home draft.  For the most part, you're asking for improvements in the
flow and wording in the draft, for which I'll incorporate when editing the
draft next.

Below are some additional responses.

Thanks,
Kent


>I have read call-home and find it problematic.  I am reminded of Alan
>Luchuk's comments of almost a year ago when it was still reverse-ssh.  I
>find it unclear, hard to understand, confusing in places without knowing
>things that are unsaid.  The improvements made to the text then have
>mostly disappeared with a change of scope.

:sigh:


>I think that the scope of the document - NETCONF, RESTCONF, TLS, SSH,
>certificates, public keys - is right

Oh good, the restructuring of the documents we took on is paying off


>but that does not mean it is always
>possible to cover all the cases in a single sentence and that more
>fleshing out is needed.  Thus repeatedly the use of NETCONF/RESTCONF
>allows combinations that I suspect are invalid, such as RESTCONF over
>SSH or NETCONF using the port assigned to RESTCONF.

This came up before.  In fact, I raised the issue originally and did try
to make it better.  Apparently not.  I have reopened
https://github.com/netconf-wg/call-home/issues/6 to track this.



>What then is the scope?  For most of the I-D, I infer NETCONF with SSH
>and TLS, RESTCONF (which I am not competent to review) with TLS, TLS
>with certificates, SSH with public keys.  But then I see at the end of
>s.3
>" However, to use X.509 certificates with SSH, ..."
>so it looks like SSH with certificates is there too.  How about TLS with
>something else?  We did debate this at length for another I-D and slowly
>converged on X.509 certificates only.  Is this true here?  If so, it
>needs saying up front IMO.

The scope is: NETCONF/SSH, NETCONF/TLS, RESTCONF/TLS

But it so happens that NETCONF/SSH can also support X.509 certificates,
which is really important for the zero-touch solution.  To be honest, I'm
beginning to think that we should take out most of section 3.2 (the one
that leads to recommending X.509 host-keys).  For the call-home protocol,
all we need to say is that the client needs to:

 1) extract the server's identity
	- options: source-ip, host-key lookup, or PKI
 2) validate the server's host-key
	- options: pinning or PKI.

I think the current text is overstepping its scope and, in the process,
hiding the essential bits.  You providing an extensive response on section
3.2 separately, but I'm thinking another solution might be to make most of
this section 3.2 disappear
=20


>SSH makes a rather sudden appearance in the Introduction (lack of scope
>again); I think it should be in the Abstract e.g.
>
>NEW (In both Abstract and Introduction)
>
> This document presents NETCONF Call Home and RESTCONF Call Home, which
>enable a NETCONF or RESTCONF server to initiate a
>   secure connection to a NETCONF or RESTCONF client respectively.  The
>RESTCONFconnection is over TLS, the NETCONF over TLS or SSH. "

True, SSH was removed from the abstract when we added RESTCONF, as I
didn't want to introductory paragraphs to already be in the weeds.  I like
your suggested text.



>[Note that the current use of respectively is wrong IMO; you have 'A and
>B', but no 'C and D' to be respective to.]

Not that it matters, but isn't it:

  A =3D NETCONF Call Home
  B =3D RESTCONF Call Home
  C =3D enable a NETCONF server to initiate a
      secure connection to a NETCONF client
  D =3D enable a RESTCONF server to initiate a
      secure connection to a RESTCONF client

So, A goes with C and B goes with D?



>1
>"preserve the client/server roles of underlying transport, as when
>compared"
>
>Well no, the whole point is to reverse the transport.  Of course, if TCP
>is not a transport, well, I part company there.  It is argued just what
>TLS is, transport or not, with TCPM and TLS WGs apt to part company.  SO
>
>" preserve the client/server roles of underlying secure connection, as
>when
>compared"
>I would add at the end of this paragraph
>"References to SSH in this document are only applicable to NETCONF"
>
>(as well as fleshing this out later).


I think the word "transport" simply refers to the layer below.  So TCP is
the transport for SSH and TLS, whereas SSH is a transport for NETCONF and
TLS is a transport for NETCONF and the transport for HTTPS/RESTCONF.
This also seems consistent with the term's usage in RFCs 5539 and 6242.

Nonetheless, as Rohit's recent confusion illustrates, it seems that this
draft still does not spell out clearly enough this point.  So, how about
this:

=3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D

   Both NETCONF Call Home and RESTCONF Call Home preserve all client/
   server roles, except for at the TCP transport layer, as when compared
   to standard NETCONF and RESTCONF connections.  Specifically,
   regardless if call home is used or not, the SSH, TLS, NETCONF, and
   RESTCONF roles are the same, only the TCP roles vary.  Stated another
   way, and depicted below, the network element is always the NETCONF/
   RESTCONF server, as well as also always the SSH/TLS server.  Indeed,
   the only difference is in which peer initiates the underlying TCP
   connection.

            +--------------------+------------+-------------+
            |    Protocol Layer  |  Standard  |  Call home  |
            +--------------------+------------+-------------+
            |  NETCONF/RESTCONF  |   server   |   server    |
            |           SSH/TLS  |   server   |   server    |
            |               TCP  |   server   |   client    |
            +--------------------+------------+-------------+

               Client/Server Roles for the Network Element

  Please note that throughout this document, including the text above,
  are switches such as "NETCONF/RESTCONF" and "SSH/TLS".  It should
  be understood that the only valid combinations are NETCONF/SSH [RFC
  6242], NETCONF/TLS [RFC 5593], and RESTCONF/TLS
[draft-ietf-netconf-restconf].
  In particular, never is it intended that RESTCONF/SSH is a valid
  combination.

=3D=3D=3D=3D=3DSTOP=3D=3D=3D=3D=3D




>
>1.3
>A year ago, we had
>
>" these techniques MUST only be used for NETCONF Call Home"
>
>which Benoit said was impossible.  Now we have 'SHOULD' but it still
>seems impossible to me.  'SHOULD' should be accompanied by indications
>of when it does not apply and I don't really see this.  I think we are
>still leaving the barn door wide open.  I would say something like
>"These techniques are only defined for ..."
>since I think any RFC2119 language unenforceable.

Sound OK to me, do others agree?



>1.4
>"Security implications related to
>  this change are discussed in Security Considerations (Section 4)."
>Not really, section 4 refers you to section 3.

Good point.  There use to be more text there at one time though ;)



>2.1
>"The NETCONF/RESTCONF server initiates a TCP connection request
>      (SYN) to the NETCONF/RESTCONF client.  "
>A strict reading of this allows a NETCONF server to initiate connection
>of a RESTCONF client!  I think you need
>'NETCONF server or RESTCONF server' twice with a ',respectively' tacked
>On

OK


>"depending on how it is configured."
>Again, this allows you to configure a RESTCONF server to use port X.  It
>is not configuration, it is a question of which port you have just
>called that determines what the server fires up.

[assuming section 2.1, there would be a different response if for section
3.1]

No, non-standard and even mismatched IANA-assigned ports are possible.
>From the network-elements POV, what matters is how it was configured.  For
example, in the server-model draft, the configuration allows the
transport-specific default-port destination port to be overwritten.


>"Using this TCP connection, the NETCONF/RESTCONF server MUST
>      immediately start using either the SSH-server [RFC4253] or the
>      TLS-server [RFC5246] protocol.
>If the connection was made to PORT-X (or a user chosen non-default
>port), then the SSH-server protocol is initiated; if the connection was
>made to either port PORT-Y or PORT-Z (or a user-chosen non-deault port),
>then the TLS-server protocol is initiated."

I'm confused, are you providing alternate text here?



>" Once the SSH or TLS connection is established, the NETCONF/
> RESTCONF server MUST immediately start using either the NETCONF-server
>[RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] protocol,
>depending on how it is configured.  "
>
>Same story, it is the port not the configuration that matters. Perhaps
>" Once the SSH or TLS connection is established, the NETCONF/
>RESTCONF server MUST immediately start using either the NETCONF-server
>[RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf]
>protocol, depending on the port to which the connection has been
>established."

See above for my comment on section 2.1



>3
>same comments about
>"depending on how it is configured"
>Twice

Actually, here I think it is different, in that I believe we can use a
MUST (or a SHOULD, since it's not enforceable?) to assert that the right
protocol is started on the IANA-assigned port.  That is, ports must/should
only be used for the protocols as assigned by IANA.  For non-standard
ports, it would be as configured.  Tom, I might need your wordsmithing
prowess here ;)




>3.2 I need to go through this many more times but meanwhile
>
>"information  persisted previously."
>I don't understand.
>
>"This IP address could be used as an identifier directly, but doing "
>so should come with a health warning; source IP addresses are forgeable
>in the Internet.
>
>"Yet another option for identifying a NETCONF/RESTCONF server is for
>its host key or certificate to encode its identity directly (e.g.,
>   within the "Subject" field).  "
>
>What 'Subject field' is that?  I am not familiar with one.

You did provide a separate response focusing on section 3.2, so I'll defer
comment on it here now.



>4
>"An attacker could DoS the "
>I just read an AD review (in IESG review I think ) that said 'Dos is not
>a verb'!

Good point, it should be "An attacker could launch a denial of service
(DoS) attack on the..."


Thanks again,
Kent



From nobody Fri Mar 20 12:34:39 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27C71B2FE8 for ; Fri, 20 Mar 2015 12:34:37 -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 CY-78h5Hbmd5 for ; Fri, 20 Mar 2015 12:34:35 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9899D1A0127 for ; Fri, 20 Mar 2015 12:34:35 -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.1.118.21; Fri, 20 Mar 2015 19:34:34 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Fri, 20 Mar 2015 19:34:34 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "Ersue, Mehmet (Nokia - DE/Munich)" 
Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
Thread-Index: AQHQVf+tT/7bNpWPUkyuK74/P/SDo50aQf2AgAtYugA=
Date: Fri, 20 Mar 2015 19:34:33 +0000
Message-ID: 
References:  <20150313101805.GB17615@elstar.local>
In-Reply-To: <20150313101805.GB17615@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-originating-ip: [66.129.239.12]
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(76104003)(51704005)(43784003)(230783001)(54356999)(76176999)(122556002)(87936001)(2656002)(50986999)(66066001)(36756003)(86362001)(83506001)(19580395003)(106116001)(102836002)(15975445007)(62966003)(2950100001)(2900100001)(92566002)(46102003)(77156002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 05214FD68E
Content-Type: text/plain; charset="us-ascii"
Content-ID: <42B168072BFC404F976E52FE18387570@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2015 19:34:33.7398 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 20 Mar 2015 19:34:38 -0000

Hi Juergen,


>Here is my review of draft-ietf-netconf-call-home-04.txt.

Thank you for this review!




>- Perhaps the second bullet in 2.1 can be improved. Perhaps slight
>  rewording helps to make things a bit clearer?
>
>    Change "the SSH-server protocol is used for PORT-X" to "the
>    SSH-server protocol is used after connecting to the remote port
>    PORT-X" and change "the TLS-server protocol is used for either
>    port PORT-Y or PORT-Z" to "the TLS-server protocol is used after
>    connecting to one of the remote ports PORT-Y or PORT-Z".

Tom also had comments here.  Yes, your sentences are more clear.

 =20
>- Should the text say something about the assumption that a mismatch
>  (a NR server using SSH towards a remote port assuming TLS) leads to
>  a failure discovered by the secure transport protocols and to a
>  failure of the connection attempt? I guess we do not want systems to
>  probe which protocol is available, as this might be a way to try
>  downgrade attacks in case one of the protocols has vulnerabities.

I'm not following you.  Port mapping is certainly a common attack vector
and there is not much that can be done to prevent it. In the case of
mismatched protocols (SSH client --> TLS server, or visa versa), my
expectation is that the both sides will get a protocol error of some sort.
 Do we need to say anything in the text though?


>- Similarly as above, perhaps change the text in the 3rd bullet in 2.1
>  as well:
>
>  OLD
>        [...] Assuming the use of
>        the IANA-assigned ports, the NETCONF-server protocol is used for
>        PORT-X or PORT-Y and the RESTCONF-server protocol is used for
>        PORT-Z.
>
>  NEW
>
>        [...] Assuming the use of
>	the IANA-assigned ports, the NETCONF-server protocol is used
>	over the secure transports to the remote ports PORT-X and
>	PORT-Y and the RESTCONF-server protocol is used over the
>	secure transport to the remote port PORT-Z.

OK



>- Third bullet in section 3.1, similar as suggested above:
>
>  OLD
>
>      For example, assuming the use of the IANA-assigned ports, the SSH-
>      client protocol is used for PORT-X and the TLS-client protocol is
>      used for either port PORT-Y or PORT-Z.
>
>  NEW
>
>      For example, assuming the use of the IANA-assigned ports, the
>      SSH- client protocol is used for connections accepted on PORT-X
>      and the TLS-client protocol is used for connections accepted on
>      one of the ports PORT-Y or PORT-Z.

I'm see ing a pattern here ;)


>- Fourth bullet in section 3.1, similar as suggested above:

Understood


>- The document refers to [RFC5539] but it should likely refer to
>  5539bis.

I actually meant 5539, since 5539bis isn't needed from a normative
perspective.  But I might as well now, since there is a normative
reference to the RESTCONF draft,

>=20

>I am not sure the reference of RFC7230 is convincing in the
>  last bullet in section 3.1 since this is at the end a generic
>  reference to RFC HTTP 1.1.

Yes, in the end, it's just HTTPS, but don't you think something should be
said?  Unfortunately there isn't a more formal HTTP/TLS binding spec we
can reference...


>- If the document uses labels such as S1, S2, S3 and C1, C2, C3 for
>  the various server and client protocol operation steps, it becomes a
>  bit easier to refer to them ('step C3' is easier to write than
>  'third bullet in section 3.1').

Hmmm, at risk of changing the document structure, what do you think about
there being an image like:

        NETCONF/RESTCONF                     NETCONF/RESTCONF
            Server                               Client
              |                                    |

              |         1. TCP                     |

              |----------------------------------->|

              |                                    |

              |                                    |

              |         2. SSH/TLS                 |

              |<-----------------------------------|
              |                                    |

              |                                    |

              |         3. NETCONF/RESTCONF        |

              |<-----------------------------------|
              |                                    |



And then have the text speak to 1-3, something like:

	1 TCP Connection
	1.1 NETCONF/RESTCONF-server's perspective
	1.2 NETCONF/RESTCONF-client's perspective

	2 SSH/TLS Connection
	2.1 NETCONF/RESTCONF-server's perspective
	2.2 NETCONF/RESTCONF-client's perspective


	3 NETCONF/RESTCONF Connection
	3.1 NETCONF/RESTCONF-server's perspective
	3.2 NETCONF/RESTCONF-client's perspective


What do you think?


>- In section 3.2, I think the phrase "this action provides essential
>  input" is a bit vague. I think the key here is that the client
>  normally has an idea of the expected identity residing at the remote
>  server side before even initiating a connection. We probably need to
>  make sure we use the proper terminology here (security people should
>  tell us).

I'll look into it


>- 3rd paragraph in section 3.2: For certain NATs, you would get a
>  predictable IP address for all N/R servers behind it but then the IP
>  address is shared and not unique. This should probably also be
>  mentioned as another reason for not using IP addresses (despite the
>  fact that they are not strong identifiers from a security
>  perspective in any case).

OK


>- Is there a reason why verification of the SSH/TLS server's hostkey
>  is not required using a MUST? I am actually confused with regard to
>  the next paragraph. If the server has a certificate, I may be able
>  to verify the certificate and then accept the incoming connection
>  because I trust the certificate shown by the server. I do not know
>  what his has to do with an identity encoded in the "Subject" field?
>  Such a thing would be just a replacement for the fingerprint I would
>  otherwise use, no?

What you describe is "pinning"
(https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning
).

Recall that under normal circumstances, the client provides an initial
hostname (e.g., https://example.com) and that the Subject field inside the
certificate is expected a match (e.g., DNS:example.com).  So, there are
two steps: 1) have I accepted this cert before and 2) does the identity in
the Subject match the client-provided reference identifier.

Does this help?  If not, can you identify which paragraph your referencing
here?


>- Since the text recommends the usage of certificates, should there be
>  explicit text warning about shipping multiple boxes with the same
>  certificate? Should there be hints at choosing proper lifetimes and
>  the need to handle certificate updates or to handle certificates of
>  devices that were 'lost' or 'stolen'? Or at least have hints that
>  devices should at least make it difficult to steal certificates?

Boxes already should never share certs, as that would mean they share
private keys, which violates a best practice.  Should I look for a
reference on that?=20

Private keys should be protected, ideally by a trust protection module
(TPM).   When protected by a TPM, their expirations are typically set to a
very large value (IEEE 802.1AR-2009 spec actually says to use
"99991231235959Z"), otherwise, it's recommended to periodically refresh
the private key (once a year is what I shoot for on my servers).

I don't know if any of this belongs in the Security Considerations
section, at least not in this draft.  It seems more guidance that would be
provided by other drafts.


Thanks again,
Kent


From nobody Fri Mar 20 13:30:21 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2501B308D for ; Fri, 20 Mar 2015 13:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 8DMJ0eSNCNLb for ; Fri, 20 Mar 2015 13:30:15 -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 245AB1B308B for ; Fri, 20 Mar 2015 13:30:15 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CA1A28A4; Fri, 20 Mar 2015 21:30:13 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ApHBAK_d2xMD; Fri, 20 Mar 2015 21:29:44 +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, 20 Mar 2015 21:30:11 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF0912002C; Fri, 20 Mar 2015 21:30:11 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aTHHHP_ny7uN; Fri, 20 Mar 2015 21:30:09 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01C2A20013; Fri, 20 Mar 2015 21:30:09 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id ADE9D327EDE0; Fri, 20 Mar 2015 21:30:07 +0100 (CET)
Date: Fri, 20 Mar 2015 21:30:06 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20150320203004.GA45312@elstar.local>
Mail-Followup-To: Kent Watsen , "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" 
References:  <20150313101805.GB17615@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: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 20 Mar 2015 20:30:20 -0000

On Fri, Mar 20, 2015 at 07:34:33PM +0000, Kent Watsen wrote:
>   
> >- Should the text say something about the assumption that a mismatch
> >  (a NR server using SSH towards a remote port assuming TLS) leads to
> >  a failure discovered by the secure transport protocols and to a
> >  failure of the connection attempt? I guess we do not want systems to
> >  probe which protocol is available, as this might be a way to try
> >  downgrade attacks in case one of the protocols has vulnerabities.
> 
> I'm not following you.  Port mapping is certainly a common attack vector
> and there is not much that can be done to prevent it. In the case of
> mismatched protocols (SSH client --> TLS server, or visa versa), my
> expectation is that the both sides will get a protocol error of some sort.
>  Do we need to say anything in the text though?

I do not know either but perhaps it makes sense to be explicit that
implementations MUST use the security protocol configured for a
certain port.

> >- The document refers to [RFC5539] but it should likely refer to
> >  5539bis.
> 
> I actually meant 5539, since 5539bis isn't needed from a normative
> perspective.  But I might as well now, since there is a normative
> reference to the RESTCONF draft,
>

I do not see how this relates to RESTCONF since RFC 5539bis is about
NETCONF. Anyway, since 5539bis is on the IESG agenda now and it will
retire RFC 5539 once approved, I think you will just trigger requests
later about a stale reference.

> >I am not sure the reference of RFC7230 is convincing in the
> >  last bullet in section 3.1 since this is at the end a generic
> >  reference to RFC HTTP 1.1.
> 
> Yes, in the end, it's just HTTPS, but don't you think something should be
> said?  Unfortunately there isn't a more formal HTTP/TLS binding spec we
> can reference...

So you are saying that RESTCONF does not have to say anything about
its usage of TLS? Perhaps that is true but even then, would RFC2818
not be the more appropriate RFC to refer to? My understanding is that
RFC7230 only updates RFC2818 by revising the https URI scheme
definition.
 
> >- If the document uses labels such as S1, S2, S3 and C1, C2, C3 for
> >  the various server and client protocol operation steps, it becomes a
> >  bit easier to refer to them ('step C3' is easier to write than
> >  'third bullet in section 3.1').
> 
> Hmmm, at risk of changing the document structure, what do you think about
> there being an image like:
> 
>         NETCONF/RESTCONF                     NETCONF/RESTCONF
>             Server                               Client
>               |                                    |
> 
>               |         1. TCP                     |
> 
>               |----------------------------------->|
> 
>               |                                    |
> 
>               |                                    |
> 
>               |         2. SSH/TLS                 |
> 
>               |<-----------------------------------|
>               |                                    |
> 
>               |                                    |
> 
>               |         3. NETCONF/RESTCONF        |
> 
>               |<-----------------------------------|
>               |                                    |
> 
> 
> 
> And then have the text speak to 1-3, something like:
> 
> 	1 TCP Connection
> 	1.1 NETCONF/RESTCONF-server's perspective
> 	1.2 NETCONF/RESTCONF-client's perspective
> 
> 	2 SSH/TLS Connection
> 	2.1 NETCONF/RESTCONF-server's perspective
> 	2.2 NETCONF/RESTCONF-client's perspective
> 
> 
> 	3 NETCONF/RESTCONF Connection
> 	3.1 NETCONF/RESTCONF-server's perspective
> 	3.2 NETCONF/RESTCONF-client's perspective
> 
> 
> What do you think?

No, this is not what I was asking for (nor does it bring any
additional clarity if you ask me). What I suggested to replace the
bullets in 2.1 and 3.1 with numbered items that I can refer to:

2.1 Protocol Operation

  S1 ...
  
  S2 ...
  
  S3 ...
  
  S4 ...
  
  S5 ...

3.1 Protocol Operation

  C1 ...

  C2 ...

  C3 ...
  
  C4 ...
  
  C5 ...

Its a purely editorial change that allows me to simply refer to 'step
C3'.

> >- Is there a reason why verification of the SSH/TLS server's hostkey
> >  is not required using a MUST? I am actually confused with regard to
> >  the next paragraph. If the server has a certificate, I may be able
> >  to verify the certificate and then accept the incoming connection
> >  because I trust the certificate shown by the server. I do not know
> >  what his has to do with an identity encoded in the "Subject" field?
> >  Such a thing would be just a replacement for the fingerprint I would
> >  otherwise use, no?
> 
> What you describe is "pinning"
> (https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning
> ).
> 
> Recall that under normal circumstances, the client provides an initial
> hostname (e.g., https://example.com) and that the Subject field inside the
> certificate is expected a match (e.g., DNS:example.com).  So, there are
> two steps: 1) have I accepted this cert before and 2) does the identity in
> the Subject match the client-provided reference identifier.
> 
> Does this help?  If not, can you identify which paragraph your referencing
> here?

I think the current text does not require to verify the certificate. I
think there should be a MUST verify somewhere at the last paragraph on
page 7. This is in particular important because the client does not
have an expectation which server is calling in, so everything relies
on a decision whether the presented certificate is valid and is one of
the certificates that the client finds acceptable according to its
local policy.

> >- Since the text recommends the usage of certificates, should there be
> >  explicit text warning about shipping multiple boxes with the same
> >  certificate? Should there be hints at choosing proper lifetimes and
> >  the need to handle certificate updates or to handle certificates of
> >  devices that were 'lost' or 'stolen'? Or at least have hints that
> >  devices should at least make it difficult to steal certificates?
> 
> Boxes already should never share certs, as that would mean they share
> private keys, which violates a best practice.  Should I look for a
> reference on that? 
> 
> Private keys should be protected, ideally by a trust protection module
> (TPM).   When protected by a TPM, their expirations are typically set to a
> very large value (IEEE 802.1AR-2009 spec actually says to use
> "99991231235959Z"), otherwise, it's recommended to periodically refresh
> the private key (once a year is what I shoot for on my servers).
> 
> I don't know if any of this belongs in the Security Considerations
> section, at least not in this draft.  It seems more guidance that would be
> provided by other drafts.

If there are other drafts the security considerations can refer to,
great. If there is nothing suitable, well, then I think we need to
produce some meaningful text. The key here is to help developers
making mistakes that could be disastrous for protocols that have the
power to change configurations.

/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 Mar 20 14:53:52 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB01A907D for ; Fri, 20 Mar 2015 14:53:52 -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 zUBtJSAHvu70 for ; Fri, 20 Mar 2015 14:53:50 -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.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F771A9078 for ; Fri, 20 Mar 2015 14:53:49 -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.112.19; Fri, 20 Mar 2015 21:53:27 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Fri, 20 Mar 2015 21:53:27 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
Thread-Index: AQHQVf+tT/7bNpWPUkyuK74/P/SDo50aQf2AgAtYugCAAFKXAP//1DuA
Date: Fri, 20 Mar 2015 21:53:27 +0000
Message-ID: 
References:  <20150313101805.GB17615@elstar.local>  <20150320203004.GA45312@elstar.local>
In-Reply-To: <20150320203004.GA45312@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-originating-ip: [66.129.239.12]
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(76104003)(52314003)(51704005)(110136001)(99286002)(106116001)(36756003)(2656002)(93886004)(122556002)(46102003)(102836002)(86362001)(76176999)(50986999)(54356999)(230783001)(66066001)(92566002)(87936001)(2950100001)(2900100001)(62966003)(77156002)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 05214FD68E
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3C5ACBC6713A014D9727819E45FA30C7@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2015 21:53:27.3126 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 20 Mar 2015 21:53:52 -0000

>>>- Should the text say something about the assumption that a mismatch
>> >  (a NR server using SSH towards a remote port assuming TLS) leads to
>> >  a failure discovered by the secure transport protocols and to a
>> >  failure of the connection attempt? I guess we do not want systems to
>> >  probe which protocol is available, as this might be a way to try
>> >  downgrade attacks in case one of the protocols has vulnerabities.
>>=20
>> I'm not following you.  Port mapping is certainly a common attack vector
>> and there is not much that can be done to prevent it. In the case of
>> mismatched protocols (SSH client --> TLS server, or visa versa), my
>> expectation is that the both sides will get a protocol error of some
>>sort.
>>  Do we need to say anything in the text though?
>
>I do not know either but perhaps it makes sense to be explicit that
>implementations MUST use the security protocol configured for a
>certain port.

As I replied to Tom P., I think we can say that the client and server MUST
(perhaps SHOULD, since it's not enforceable) run the appropriate protocol
when one of the IANA-assigned port is used.  Beyond that, it seems that
scope of this draft (NETCONF/SSH, NETCONF/TLS, RESTCONF/TLS) is tripping
us up.  The draft for a single protocol wouldn't have such a problem...


>
>> >- The document refers to [RFC5539] but it should likely refer to
>> >  5539bis.
>>=20
>> I actually meant 5539, since 5539bis isn't needed from a normative
>> perspective.  But I might as well now, since there is a normative
>> reference to the RESTCONF draft,
>>
>
>I do not see how this relates to RESTCONF since RFC 5539bis is about
>NETCONF. Anyway, since 5539bis is on the IESG agenda now and it will
>retire RFC 5539 once approved, I think you will just trigger requests
>later about a stale reference.

I only meant to mention the RESTCONF draft since it is also not yet an RFC
- previously the call-home draft only had normative references on RFCs (no
drafts).  Doesn't matter, as you say, I'll ref 5539bis now.


>> >I am not sure the reference of RFC7230 is convincing in the
>> >  last bullet in section 3.1 since this is at the end a generic
>> >  reference to RFC HTTP 1.1.
>>=20
>> Yes, in the end, it's just HTTPS, but don't you think something should
>>be
>> said?  Unfortunately there isn't a more formal HTTP/TLS binding spec we
>> can reference...
>
>So you are saying that RESTCONF does not have to say anything about
>its usage of TLS? Perhaps that is true but even then, would RFC2818
>not be the more appropriate RFC to refer to? My understanding is that
>RFC7230 only updates RFC2818 by revising the https URI scheme
>definition.

Yeah, I guess restconf-04 has more in it now (it didn't before) that might
be worth referencing.


>>>  'third bullet in section 3.1').
>>=20
>> Hmmm, at risk of changing the document structure, what do you think
>>about
>> there being an image like:
>>=20

>>
>>=20
>>=20
>> What do you think?
>
>No, this is not what I was asking for (nor does it bring any
>additional clarity if you ask me). What I suggested to replace the
>bullets in 2.1 and 3.1 with numbered items that I can refer to:

>Its a purely editorial change that allows me to simply refer to 'step
>C3'.

I knew what you meant, I was just offering an option.  It's OK, I prefer
the easier route if you don't think my suggestion helps any.


>I think the current text does not require to verify the certificate. I
>think there should be a MUST verify somewhere at the last paragraph on
>page 7. This is in particular important because the client does not
>have an expectation which server is calling in, so everything relies
>on a decision whether the presented certificate is valid and is one of
>the certificates that the client finds acceptable according to its
>local policy.

This is clear, but I'm still not sure which paragraph in section 3.2
you're referencing here.


>If there are other drafts the security considerations can refer to,
>great. If there is nothing suitable, well, then I think we need to
>produce some meaningful text. The key here is to help developers
>making mistakes that could be disastrous for protocols that have the
>power to change configurations.

OK, I'll see what I can find.


K.


From nobody Fri Mar 20 15:32:41 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276BE1A1DE1 for ; Fri, 20 Mar 2015 15:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 t_LUtIWFinpH for ; Fri, 20 Mar 2015 15:32:37 -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 81EF81A1B7A for ; Fri, 20 Mar 2015 15:32:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5441E676; Fri, 20 Mar 2015 23:32:36 +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 b_Nq6YZsEXn8; Fri, 20 Mar 2015 23:32:06 +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, 20 Mar 2015 23:32:34 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A96E82002B; Fri, 20 Mar 2015 23:32:34 +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 KKnS_AUgaxTJ; Fri, 20 Mar 2015 23:32:33 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B14FB20013; Fri, 20 Mar 2015 23:32:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 11A58327EEDA; Fri, 20 Mar 2015 23:32:30 +0100 (CET)
Date: Fri, 20 Mar 2015 23:32:29 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20150320223227.GA45706@elstar.local>
Mail-Followup-To: Kent Watsen , "netconf@ietf.org" 
References:  <20150313101805.GB17615@elstar.local>  <20150320203004.GA45312@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: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 20 Mar 2015 22:32:40 -0000

On Fri, Mar 20, 2015 at 09:53:27PM +0000, Kent Watsen wrote:
> 
> >>>- Should the text say something about the assumption that a mismatch
> >> >  (a NR server using SSH towards a remote port assuming TLS) leads to
> >> >  a failure discovered by the secure transport protocols and to a
> >> >  failure of the connection attempt? I guess we do not want systems to
> >> >  probe which protocol is available, as this might be a way to try
> >> >  downgrade attacks in case one of the protocols has vulnerabities.
> >> 
> >> I'm not following you.  Port mapping is certainly a common attack vector
> >> and there is not much that can be done to prevent it. In the case of
> >> mismatched protocols (SSH client --> TLS server, or visa versa), my
> >> expectation is that the both sides will get a protocol error of some
> >>sort.
> >>  Do we need to say anything in the text though?
> >
> >I do not know either but perhaps it makes sense to be explicit that
> >implementations MUST use the security protocol configured for a
> >certain port.
> 
> As I replied to Tom P., I think we can say that the client and server MUST
> (perhaps SHOULD, since it's not enforceable) run the appropriate protocol
> when one of the IANA-assigned port is used.  Beyond that, it seems that
> scope of this draft (NETCONF/SSH, NETCONF/TLS, RESTCONF/TLS) is tripping
> us up.  The draft for a single protocol wouldn't have such a problem...
>

It is enforcable whether you run SSH or TLS. This should be a
MUST. And this has nothing to do with NETCONF / RESTCONF. My concern
is that I do connect to a PORT where I expect SSH but then the server
is willing to run TLS over it in case I do not send an SSH hello
message. I am concerned about having a way to change the security
protocol.
 
> >I think the current text does not require to verify the certificate. I
> >think there should be a MUST verify somewhere at the last paragraph on
> >page 7. This is in particular important because the client does not
> >have an expectation which server is calling in, so everything relies
> >on a decision whether the presented certificate is valid and is one of
> >the certificates that the client finds acceptable according to its
> >local policy.
> 
> This is clear, but I'm still not sure which paragraph in section 3.2
> you're referencing here.
>

The paragraph starting with this:

  The next information a NETCONF/RESTCONF client learns is provided by

It could also be that I am simply a bit confused since you talk about
using information embedded in a certificate later. Perhaps this sentence

   [...] This strategy also provides a mechanism to
   verify the identity of the NETCONF/RESTCONF server, in that a secure
   connection can only be established with the NETCONF/RESTCONF server
   having the matching private key.

is addressing my concern but I was kind of looking more for text that
is more explicit what an implementation MUST do. Somehow, section 3.2
reads more like an essay about various server identification options
instead of giving clear guidance what implementors should do (or
should not do).

/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 Mar 22 03:21:39 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77231A8893 for ; Sun, 22 Mar 2015 03:21: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 7B9qdBcl9BRV for ; Sun, 22 Mar 2015 03:21:35 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37D71A8890 for ; Sun, 22 Mar 2015 03:21:34 -0700 (PDT)
Received: from pc6 (86.185.85.149) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sun, 22 Mar 2015 10:17:52 +0000
Message-ID: <01b201d06489$1a626ea0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder , Kent Watsen 
References:  <20150313101805.GB17615@elstar.local>  <20150320203004.GA45312@elstar.local>  <20150320223227.GA45706@elstar.local>
Date: Sun, 22 Mar 2015 09:53:58 +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.185.85.149]
X-ClientProxiedBy: AM2PR08CA0016.eurprd08.prod.outlook.com (25.162.32.26) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143)
Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054;
X-Microsoft-Antispam-PRVS: 
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(57704003)(13464003)(377454003)(24454002)(61296003)(15975445007)(116806002)(42186005)(1556002)(14496001)(81816999)(86362001)(44716002)(77096005)(84392001)(230783001)(87976001)(19580405001)(44736004)(50226001)(1941001)(46102003)(33646002)(106356001)(19580395003)(81686999)(76176999)(1456003)(66066001)(62966003)(77156002)(62236002)(23756003)(47776003)(50986999)(93886004)(40100003)(122386002)(92566002)(50466002)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; 
X-Forefront-PRVS: 0523CF0711
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2015 10:17:52.3795 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 22 Mar 2015 10:21:37 -0000

This is getting tangled; see my comments at the end.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "Kent Watsen" 
Cc: 
Sent: Friday, March 20, 2015 10:32 PM


> On Fri, Mar 20, 2015 at 09:53:27PM +0000, Kent Watsen wrote:
> >
> > >>>- Should the text say something about the assumption that a
mismatch
> > >> >  (a NR server using SSH towards a remote port assuming TLS)
leads to
> > >> >  a failure discovered by the secure transport protocols and to
a
> > >> >  failure of the connection attempt? I guess we do not want
systems to
> > >> >  probe which protocol is available, as this might be a way to
try
> > >> >  downgrade attacks in case one of the protocols has
vulnerabities.
> > >>
> > >> I'm not following you.  Port mapping is certainly a common attack
vector
> > >> and there is not much that can be done to prevent it. In the case
of
> > >> mismatched protocols (SSH client --> TLS server, or visa versa),
my
> > >> expectation is that the both sides will get a protocol error of
some
> > >>sort.
> > >>  Do we need to say anything in the text though?
> > >
> > >I do not know either but perhaps it makes sense to be explicit that
> > >implementations MUST use the security protocol configured for a
> > >certain port.
> >
> > As I replied to Tom P., I think we can say that the client and
server MUST
> > (perhaps SHOULD, since it's not enforceable) run the appropriate
protocol
> > when one of the IANA-assigned port is used.  Beyond that, it seems
that
> > scope of this draft (NETCONF/SSH, NETCONF/TLS, RESTCONF/TLS) is
tripping
> > us up.  The draft for a single protocol wouldn't have such a
problem...
> >
>
> It is enforcable whether you run SSH or TLS. This should be a
> MUST. And this has nothing to do with NETCONF / RESTCONF. My concern
> is that I do connect to a PORT where I expect SSH but then the server
> is willing to run TLS over it in case I do not send an SSH hello
> message. I am concerned about having a way to change the security
> protocol.
>
> > >I think the current text does not require to verify the
certificate. I
> > >think there should be a MUST verify somewhere at the last paragraph
on
> > >page 7. This is in particular important because the client does not
> > >have an expectation which server is calling in, so everything
relies
> > >on a decision whether the presented certificate is valid and is one
of
> > >the certificates that the client finds acceptable according to its
> > >local policy.
> >
> > This is clear, but I'm still not sure which paragraph in section 3.2
> > you're referencing here.
> >
>
> The paragraph starting with this:
>
>   The next information a NETCONF/RESTCONF client learns is provided by
>
> It could also be that I am simply a bit confused since you talk about
> using information embedded in a certificate later. Perhaps this
sentence
>
>    [...] This strategy also provides a mechanism to
>    verify the identity of the NETCONF/RESTCONF server, in that a
secure
>    connection can only be established with the NETCONF/RESTCONF server
>    having the matching private key.
>
> is addressing my concern but I was kind of looking more for text that
> is more explicit what an implementation MUST do. Somehow, section 3.2
> reads more like an essay about various server identification options
> instead of giving clear guidance what implementors should do (or
> should not do).

Juergen

Yes, I agree, more like an essay than a Standard.

I proposed the replacement text below but feel I did not go far enough,
still somewhat essay like.  Kent's response comes after and gave a
succinct summary but I think we need something between the two.

 ====================================================
 3.2.  Server Identification and Authentication

    When a NETCONF/RESTCONF client initiates the
    connection to the NETCONF/RESTCONF server, the client has prior
 knowledge of the identity of the NETCONF/RESTCONF server it is
 connecting to.  When using TLS or SSH with certificates,
    the NETCONF client can then check the identity of the server
 according to
    Section 6 of [RFC6125].
    Similar considerations apply when using SSH with host keys.

 When the connection is initiated by the NETCONF/RESTCONF server, the
 NETCONF/RESTCONF client does not have any prior knowledge of the
 identity of the NETCONF/RESTCONF server which has initiated the
 connection.  The NETCONF/RESTCONF
  client must derive the identity of the NETCONF/RESTCONF server from
  information provided by the network or by the NETCONF/RESTCONF server
    itself.  This section describes strategies a NETCONF/RESTCONF client
    can then use to identify a NETCONF/RESTCONF server.

 A NETCONF/RESTCONF client must also authenticate the identity of the
 server.  This is always an issue but especially so when the
 NETCONF/RESTCONF server initiates the connection since this approach is
 common for newly deployed NETCONF/RESTCONF servers.

 The first piece of information that a NETCONF/RESTCONF client learns
 when the server initiates the connection is the IP address of the
 NETCONF/RESTCONF server, i.e the source address of the TCP connection.
 This IP address is an identifier but is only reliable in networks that
 use known static addresses.  This case is infrequent; so it is NOT
 RECOMMENDED to identify a NETCONF/RESTCONF server by its source IP
 address.

 The next piece of information a NETCONF/RESTCONF client learns is
 provided by the NETCONF/RESTCONF server in the form of a host-key (for
 SSH) or a certificate (for SSH or TLS).  This host-key or certificate,
 either in its
 entirety or as a fingerprint, can be used to look up an identifier for
 the NETCONF/RESTCONF server.  Each NETCONF/RESTCONF
 server is assumed to have a statistically unique public key, even in
 virtualized environments.  This approach also provides authentication
in
 that a secure connection can only be established when the
 NETCONF/RESTCONF server can demonstrate possession of
 the matching private key.  This approach is common with SSH clients but
 could be used equally well by TLS clients.  It may be the required when
 the NETCONF/RESTCONF servers have self-signed certificates.

 [** I do not understand the next OLD paragraph and so am guessing here.
 Doubtless I will be told where my guesses are wrong]

 A variation on the previous option can be used when the manufacturer of
 the NETCONF/RESTCONF servers is a trusted CA and provisions the
 NETCONF/RESTCONF servers with certificates such as is described by
 [Std-802.1AR-2009].  After verifying that the certificate is valid
 [RFC5280], an identifier can be extracted from the certificate, e.g.
 from the subjectAltName.  The NETCONF/RESTCONF client SHOULD still be
 configured with the CA certificate and a list of expected identifiers
of
 the NETCONF/RESTCONF servers, as supplied by the manufacturer.

 [Which seems very close to the usual RFC6125 case - what am I missing?]

    Note that while TLS uses X.509 certificates by default, using X.509
    certificates with SSH requires both the NETCONF client and server to
    support [RFC6187].
 ==================================================
 I would probably cut down on the number of times NETCONF/RESTCONF
 appears but am not too bothered by it.
===================================================

Kent's response

"For the call-home protocol,
all we need to say is that the client needs to:

 1) extract the server's identity
- options: source-ip, host-key lookup, or PKI
 2) validate the server's host-key
- options: pinning or PKI.

I think the current text is overstepping its scope and, in the process,
hiding the essential bits.  You providing an extensive response on
section
3.2 separately, but I'm thinking another solution might be to make most
of
this section 3.2 disappear"


Yes, something along those lines.

Tom Petch









> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Sun Mar 22 03:21:41 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCF1A8890 for ; Sun, 22 Mar 2015 03:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 n0N4vFiJBHgY for ; Sun, 22 Mar 2015 03:21:34 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD791A8888 for ; Sun, 22 Mar 2015 03:21:33 -0700 (PDT)
Received: from pc6 (86.185.85.149) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sun, 22 Mar 2015 10:17:53 +0000
Message-ID: <01b301d06489$1ac723e0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Kent Watsen , "Ersue, Mehmet (Nokia - DE/Munich)" , 
References:  <032f01d0568d$7a8728c0$4001a8c0@gateway.2wire.net> 
Date: Sun, 22 Mar 2015 10:14:48 +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.185.85.149]
X-ClientProxiedBy: AM2PR08CA0016.eurprd08.prod.outlook.com (25.162.32.26) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143)
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054;
X-Microsoft-Antispam-PRVS: 
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(43784003)(164054003)(51444003)(13464003)(377454003)(61296003)(15975445007)(116806002)(107886001)(42186005)(1556002)(14496001)(81816999)(86362001)(44716002)(77096005)(84392001)(230783001)(87976001)(19580405001)(44736004)(50226001)(1941001)(46102003)(33646002)(106356001)(19580395003)(81686999)(76176999)(1456003)(66066001)(62966003)(77156002)(62236002)(23756003)(47776003)(50986999)(40100003)(122386002)(92566002)(50466002)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; 
X-Forefront-PRVS: 0523CF0711
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2015 10:17:53.0347 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054
Archived-At: 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 22 Mar 2015 10:21:38 -0000


Tom Petch

----- Original Message -----
From: "Kent Watsen" 
To: "t.petch" ; "Ersue, Mehmet (Nokia - DE/Munich)"
; 
Sent: Friday, March 20, 2015 6:31 PM

Hi Tom,

Thank you for this review, and the other focusing on section 3.2 of
call-home draft.  For the most part, you're asking for improvements in
the
flow and wording in the draft, for which I'll incorporate when editing
the
draft next.

Below are some additional responses.

Thanks,
Kent



>I think that the scope of the document - NETCONF, RESTCONF, TLS, SSH,
>certificates, public keys - is right

Oh good, the restructuring of the documents we took on is paying off

>but that does not mean it is always
>possible to cover all the cases in a single sentence and that more
>fleshing out is needed.  Thus repeatedly the use of NETCONF/RESTCONF
>allows combinations that I suspect are invalid, such as RESTCONF over
>SSH or NETCONF using the port assigned to RESTCONF.

This came up before.  In fact, I raised the issue originally and did try
to make it better.  Apparently not.  I have reopened
https://github.com/netconf-wg/call-home/issues/6 to track this.


Yes, once we have settled 3.2, then I would take another look at this to
see if there any loose ends.

>What then is the scope?  For most of the I-D, I infer NETCONF with SSH
>and TLS, RESTCONF (which I am not competent to review) with TLS, TLS
>with certificates, SSH with public keys.  But then I see at the end of
>s.3
>" However, to use X.509 certificates with SSH, ..."
>so it looks like SSH with certificates is there too.  How about TLS
with
>something else?  We did debate this at length for another I-D and
slowly
>converged on X.509 certificates only.  Is this true here?  If so, it
>needs saying up front IMO.

The scope is: NETCONF/SSH, NETCONF/TLS, RESTCONF/TLS


Well partially, but I find the I-D unclear on the related credentials,
which I take to be TLS-with-certificates, SSH-with-host-key,
SSH-with-certificates. I am fine with that being the scope but think
that the wording of the I-D does not always bear that out clearly enough
and this was a big issue for 5539bis.


But it so happens that NETCONF/SSH can also support X.509 certificates,
which is really important for the zero-touch solution.  To be honest,
I'm
beginning to think that we should take out most of section 3.2 (the one
that leads to recommending X.509 host-keys).  For the call-home
protocol,
all we need to say is that the client needs to:

 1) extract the server's identity
- options: source-ip, host-key lookup, or PKI
 2) validate the server's host-key
- options: pinning or PKI.

I think the current text is overstepping its scope and, in the process,
hiding the essential bits.  You providing an extensive response on
section
3.2 separately, but I'm thinking another solution might be to make most
of
this section 3.2 disappear


Yes, subject to some agreement on terminology.  As Juergen said, more
like an essay, and my text in my separate response is still too essay
like.

>SSH makes a rather sudden appearance in the Introduction (lack of scope
>again); I think it should be in the Abstract e.g.
>
>NEW (In both Abstract and Introduction)
>
> This document presents NETCONF Call Home and RESTCONF Call Home, which
>enable a NETCONF or RESTCONF server to initiate a
>   secure connection to a NETCONF or RESTCONF client respectively.  The
>RESTCONFconnection is over TLS, the NETCONF over TLS or SSH. "

True, SSH was removed from the abstract when we added RESTCONF, as I
didn't want to introductory paragraphs to already be in the weeds.  I
like
your suggested text.

 Good, use it!



>1
>"preserve the client/server roles of underlying transport, as when
>compared"
>
>Well no, the whole point is to reverse the transport.  Of course, if
TCP
>is not a transport, well, I part company there.  It is argued just what
>TLS is, transport or not, with TCPM and TLS WGs apt to part company.
SO
>
>" preserve the client/server roles of underlying secure connection, as
>when
>compared"
>I would add at the end of this paragraph
>"References to SSH in this document are only applicable to NETCONF"
>
>(as well as fleshing this out later).

I think the word "transport" simply refers to the layer below.  So TCP
is
the transport for SSH and TLS, whereas SSH is a transport for NETCONF
and
TLS is a transport for NETCONF and the transport for HTTPS/RESTCONF.
This also seems consistent with the term's usage in RFCs 5539 and 6242.

Nonetheless, as Rohit's recent confusion illustrates, it seems that this
draft still does not spell out clearly enough this point.  So, how about
this:

=====START=====

   Both NETCONF Call Home and RESTCONF Call Home preserve all client/
   server roles, except for at the TCP transport layer, as when compared
   to standard NETCONF and RESTCONF connections.  Specifically,
   regardless if call home is used or not, the SSH, TLS, NETCONF, and
   RESTCONF roles are the same, only the TCP roles vary.  Stated another
   way, and depicted below, the network element is always the NETCONF/
   RESTCONF server, as well as also always the SSH/TLS server.  Indeed,
   the only difference is in which peer initiates the underlying TCP
   connection.

            +--------------------+------------+-------------+
            |    Protocol Layer  |  Standard  |  Call home  |
            +--------------------+------------+-------------+
            |  NETCONF/RESTCONF  |   server   |   server    |
            |           SSH/TLS  |   server   |   server    |
            |               TCP  |   server   |   client    |
            +--------------------+------------+-------------+

               Client/Server Roles for the Network Element

  Please note that throughout this document, including the text above,
  are switches such as "NETCONF/RESTCONF" and "SSH/TLS".  It should
  be understood that the only valid combinations are NETCONF/SSH [RFC
  6242], NETCONF/TLS [RFC 5593], and RESTCONF/TLS
[draft-ietf-netconf-restconf].
  In particular, never is it intended that RESTCONF/SSH is a valid
  combination.


text fine, diagram less so as it, again, could be read as endorsing
RESTCONF over SSH.  I really do want the I-D to be clear that it
excludes that possibility (I have been reading PPVPN lately and boy, it
is confusing because of this sort of mix and match).

=====STOP=====

>1.3
>A year ago, we had
>
>" these techniques MUST only be used for NETCONF Call Home"
>
>which Benoit said was impossible.  Now we have 'SHOULD' but it still
>seems impossible to me.  'SHOULD' should be accompanied by indications
>of when it does not apply and I don't really see this.  I think we are
>still leaving the barn door wide open.  I would say something like
>"These techniques are only defined for ..."
>since I think any RFC2119 language unenforceable.

Sound OK to me, do others agree?

1.4
>"Security implications related to
>  this change are discussed in Security Considerations (Section 4)."
>Not really, section 4 refers you to section 3.

Good point.  There use to be more text there at one time though ;)

>2.1
>"The NETCONF/RESTCONF server initiates a TCP connection request
>      (SYN) to the NETCONF/RESTCONF client.  "
>A strict reading of this allows a NETCONF server to initiate connection
>of a RESTCONF client!  I think you need
>'NETCONF server or RESTCONF server' twice with a ',respectively' tacked
>On

OK

>"depending on how it is configured."
>Again, this allows you to configure a RESTCONF server to use port X.
It
>is not configuration, it is a question of which port you have just
>called that determines what the server fires up.

[assuming section 2.1, there would be a different response if for
section
3.1]

No, non-standard and even mismatched IANA-assigned ports are possible.
>From the network-elements POV, what matters is how it was configured.
For
example, in the server-model draft, the configuration allows the
transport-specific default-port destination port to be overwritten.


Yes but Juergen has picked up on this point too, that if you call home
on a port configured for SSH, then you should only process SSH packets
and discard TLS ones; that we should be crystal clear on; whether the
port is IANA-assigned or not is immaterial, it just causes the sentence
to introduce an unwanted complication.


>"Using this TCP connection, the NETCONF/RESTCONF server MUST
>      immediately start using either the SSH-server [RFC4253] or the
>      TLS-server [RFC5246] protocol.
>If the connection was made to PORT-X (or a user chosen non-default
>port), then the SSH-server protocol is initiated; if the connection was
>made to either port PORT-Y or PORT-Z (or a user-chosen non-deault
port),
>then the TLS-server protocol is initiated."

I'm confused, are you providing alternate text here?


Yes, it is the same point, and the same as Juergen has picked up on.

>" Once the SSH or TLS connection is established, the NETCONF/
> RESTCONF server MUST immediately start using either the NETCONF-server
>[RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] protocol,
>depending on how it is configured.  "
>
>Same story, it is the port not the configuration that matters. Perhaps
>" Once the SSH or TLS connection is established, the NETCONF/
>RESTCONF server MUST immediately start using either the NETCONF-server
>[RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf]
>protocol, depending on the port to which the connection has been
>established."

See above for my comment on section 2.1


>3
>same comments about
>"depending on how it is configured"
>Twice

Actually, here I think it is different, in that I believe we can use a
MUST (or a SHOULD, since it's not enforceable?) to assert that the right
protocol is started on the IANA-assigned port.  That is, ports
must/should
only be used for the protocols as assigned by IANA.  For non-standard
ports, it would be as configured.  Tom, I might need your wordsmithing
prowess here ;)


SHOULD, I think (flattery will get you everywhere).  If the port is
IANA-assigned, it should only be used for that which it was assigned.
If the port is user chosen, it should only be used for the protocol, SSH
or TLS, for which it is configured.

I assume that user-defined ports follow the IANA model, that a port is
either for NETCONF-SSH or NETCONF-TLS or RESTCONF-TLS and not a
combination thereof; at least, that is what the I-D says they SHOULD
do - if an implementer wants to go further, then we do not give them any
help or encoiuragement.

>3.2 I need to go through this many more times but meanwhile
>
>"information  persisted previously."
>I don't understand.
>
>"This IP address could be used as an identifier directly, but doing "
>so should come with a health warning; source IP addresses are forgeable
>in the Internet.
>
>"Yet another option for identifying a NETCONF/RESTCONF server is for
>its host key or certificate to encode its identity directly (e.g.,
>   within the "Subject" field).  "
>
>What 'Subject field' is that?  I am not familiar with one.

You did provide a separate response focusing on section 3.2, so I'll
defer
comment on it here now.

4
>"An attacker could DoS the "
>I just read an AD review (in IESG review I think ) that said 'Dos is
not
>a verb'!

Good point, it should be "An attacker could launch a denial of service
(DoS) attack on the..."


Phew!

Tom Petch


Thanks again,
Kent



From nobody Sun Mar 22 05:53:25 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A7D1A90A2 for ; Sun, 22 Mar 2015 05:53:24 -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 mqTrJtDocS9G for ; Sun, 22 Mar 2015 05:53:23 -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 190ED1A90A1 for ; Sun, 22 Mar 2015 05:53:22 -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 t2MCrKqI019460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 22 Mar 2015 12:53:20 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 t2MCrKRl001521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 22 Mar 2015 13:53:20 +0100
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.224.2; Sun, 22 Mar 2015 13:53:19 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.51]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0224.002; Sun, 22 Mar 2015 13:53:20 +0100
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: "netconf@ietf.org" 
Thread-Topic: Agenda for the NETCONF Session in IETF 92
Thread-Index: AdBknys7pkooOKObTfOUO3MiOVcx8Q==
Date: Sun, 22 Mar 2015 12:53:18 +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.99]
Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81966A166DEMUMBX005nsnin_"
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: 2436
X-purgate-ID: 151667::1427028800-00007F9C-F816B1AE/0/0
Archived-At: 
Subject: [Netconf] Agenda for the NETCONF Session in IETF 92
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, 22 Mar 2015 12:53:25 -0000

--_000_E4DE949E6CE3E34993A2FF8AE79131F81966A166DEMUMBX005nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

please find on IETF server the updated agenda for the NETCONF Session in IE=
TF 92:

https://datatracker.ietf.org/meeting/92/agenda/netconf/

Best Regards,
Mehmet & Mahesh





--_000_E4DE949E6CE3E34993A2FF8AE79131F81966A166DEMUMBX005nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











All,


 


please find on IETF server the updated agenda =
for the NETCONF Session in IETF 92:


 



 


Best Regards, 


Mehmet & Mahesh


 


 


&nbs=
p;


&nbs=
p;





--_000_E4DE949E6CE3E34993A2FF8AE79131F81966A166DEMUMBX005nsnin_--


From nobody Sun Mar 22 07:04:31 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BAB1A90E1 for ; Sun, 22 Mar 2015 07:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 B4Pe_llY1Q2E for ; Sun, 22 Mar 2015 07:04:26 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7242C1A90DB for ; Sun, 22 Mar 2015 07:04: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 52753A85; Sun, 22 Mar 2015 15:04:25 +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 ZfcLMtOGoBlZ; Sun, 22 Mar 2015 15:03:45 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 22 Mar 2015 15:04:23 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B3752002B; Sun, 22 Mar 2015 15:04:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DcNgP2hRt-0D; Sun, 22 Mar 2015 15:04:22 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BE2220013; Sun, 22 Mar 2015 15:04:21 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 45B2C327FB08; Sun, 22 Mar 2015 15:04:20 +0100 (CET)
Date: Sun, 22 Mar 2015 15:04:18 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20150322140418.GA51799@elstar.local>
Mail-Followup-To: Kent Watsen , "netconf@ietf.org" 
References:  <20150318224028.GA38182@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: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed
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, 22 Mar 2015 14:04:29 -0000

On Fri, Mar 20, 2015 at 01:26:34AM +0000, Kent Watsen wrote:
> 
> >* sec 2.4: What is 'TLS _transport-level_ authentication'? Why not
> >  just use 'TLS authentication' or perhaps even clearer 'TLS client
> >  authentication'?
> 
> Good catch.  Will use "TLS client authentication"
> 
> 
> >* sec 2.6: Do we really need 'northbound application' terminology? Why
> >  not call it simply a NETCONF/RESTCONF client? There might also be
> >  possible confusion with phrases such as "Assuming an application has
> >  more than one server" - the server here seems to be the NETCONF
> >  client to call home to. Anyway, if we do need new terminology, I
> >  think we should properly define it to avoid any confusion.
> 
> The term "application" is coming from the YANG model, where we have:
> 
>    module: ietf-netconf-server
>       +--rw netconf-server
>          +--rw call-home {call-home}?
>             +--rw application* [name]
>                ...
> 
> My intent was to pick a term that would make sense in GUI and CLI.  But
> maybe this is better:
> 
>    module: ietf-netconf-server
>       +--rw netconf-server
>          +--rw call-home {call-home}?
>             +--rw netconf-client* [name]
>                ...
> 
> What do you think?   The term used throughout the draft will fallout from
> this.  If we decide to use "application", I will add a proper Terminology
> section, per Martin's comment.

I think 'application' is very broad. On the technical side, I think
the issue is how we interpret terms for 'applications' that may have
multiple 'entry points'. Is every 'entry point' a netconf client or is
the 'application' a network client with multiple potentially very
distinct endpoints. It may be necessary to make a distinction here to
avoid any confusion, I am not sure what would be the proper terms to
use. But whatever we do, this needs to be clearly defined. 

> >* sec 3: Is it a good idea to name the top-level node netconf-server?
> >  Is this name consistent with how we name other things?
> 
> What else would you have?  FWIW, RFC 6022 has "netconf-state".
> 
> In case it helps, example A.1 shows:
> 
>   
>     ...
>     ...
> 
>     ...
>     ...
>   
> 

We may have to look into how we do our naming. I think other YANG
models do not use -server.

> >* sec 3: Can I have a server listening for SSH and accepting call home
> >  over TLS? Would features work out in such a case or would such a
> >  server make a client believe that the server is also allowing call
> >  home via SSH and incoming connections via TLS?
> 
> You can certainly configure that, but the model doesn't support the
> NETCONF server being able to only support those specific variations.
> This is why I was trying to use the YANG 1.1 style if-feature statements
> in -04.  We could use long feature names to cover these specific
> variations, but I didn't think it worth the bother.  Do you?

Hard to tell - but once you need it and it is not there, you are
somewhat screwed.
 
> >* sec 3.2:
> >
> >  - is import by revision needed?
> 
> At the time I submitted this draft, it was my understanding that import by
> revision was best practice, and that prior YANG modules were in violation.
>  Recent YANG 1.1 conformance discussions seem to be swinging the other
> direction now, but with potential to swing back again.  I don't know what
> to *right* thing to do is.   Perhaps taking it out is the way to go
> because, even if it's wrong, it will at least be in the company of other
> published modules  ;)

There was a VRFY call on the YANG 1.1 issue that did not cause any
reaction saying that import by revision actually leads to a workable
solution. So from this point of view, I would rather remove import by
revision.
 
> >  - neither address nor port are mandatory for a listening endpoint;
> >    since the port has a default, should address be mandatory?
> 
> Sounds reasonable.  An alternative might be to have a default to represent
> "all configured interfaces" - what do you think?

This might make sense but then this should be stated explicitly.
 
> >  - how do interval-secs and count-max work for reconnect-strategy if
> >    an endpoint resolves to multiple IP addresses? Does the
> >    interval-secs apply every address of an endpoint or to all
> >    addresses of an endpoint? Does count-max increment for each
> >    address of an endpoint or just once for a given endpoint?
> 
> Interesting point, that a hostname may expand into a list of IPs.  What
> makes sense to me is that the list of IPs would be treated as if they were
> specified explicitly.  For example, let's say a configured application
> (netconf client?) has 3 endpoints (EP1, EP2, and EP3), but they're all
> hostnames that expand into two IP addresses, then the netconf server
> behavior would be as if it had them configured explicitly: EP1.1, EP1.2,
> EP2.1, EP2.2, EP3.1, EP3.2.  That is, with would try EP1.1 count-max times
> before trying EP1.2 count-max times, and so on. Does this also make sense
> to you?  If so, then I think that it's just a matter of writing it up so
> the text spells it out.

As long as it is clearly specified how things should behave I am fine.

> 
> 
> 
> >  - would it make sense to introduce a typedef for the X509
> >    certificates?
> 
> Maybe, but I wonder if you're saying this after seeing this:
> 
>       leaf-list certificate {
>         type string;
>         min-elements 1;
>         description
>           "An unordered list of certificates the TLS server can pick
>            from when sending its Server Certificate message.  The value
>            of the string is the unique identifier for a certificate
>            configured on the system.  How valid values are discovered
>            is outside the scope of this module, but they are envisioned
>            to be the keys for a list of certificates provided
>            by another YANG module";
>         reference
>           "RFC 5246: The TLS Protocol, Section 7.4.2";
>       }
> 
> 
> Or this?
> 
>       leaf-list trusted-ca-cert {
>         type binary;
>         ordered-by system;
>         nacm:default-deny-write;
>         description
>           "The binary certificate structure as specified by RFC
>            5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
>           ";
> 
> 
> The former was by yours truly later was lifted from another draft.  My
> plan from Martin's review was to make the former look like the later, but
> you think a typedef would be better?
>

I just say this "as specified by RFC 5246, Section 7.4.6 [...]" in
multiple places and hence I thought a typedef could nicely encapsulate
that.

> >  - would it not make sense to factor out some common groupings so
> >    that things can be reused instead of being defined multiple times?
> 
> Do you mean between the ietf-netconf-server and ietf-restconf-server
> modules?

Yes, and probably others. Having the same thing defined multiple times
is an indication that perhaps a single definition could do as well.

> >* sec A: please use IP addresses reserved for documentation in the
> >  examples.
> 
> I didn't know there was such a thing - can you provide a pointer to the
> RFC for this?

The latest version seems to be https://tools.ietf.org/html/rfc6890

/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 Mar 22 07:43:53 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FE81A92DF for ; Sun, 22 Mar 2015 07:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 KWZxlesazKHB for ; Sun, 22 Mar 2015 07:43:44 -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 203041ACD43 for ; Sun, 22 Mar 2015 07:43:43 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTZ68952; Sun, 22 Mar 2015 14:43:42 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 22 Mar 2015 14:43:41 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.93]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sun, 22 Mar 2015 22:43:24 +0800
From: "Liubing (Leo)" 
To: "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" 
Thread-Topic: Agenda for the NETCONF Session in IETF 92
Thread-Index: AdBknys7pkooOKObTfOUO3MiOVcx8QADD9Rw
Date: Sun, 22 Mar 2015 14:43:23 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F457CED697C@nkgeml506-mbx.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.152.66]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F457CED697Cnkgeml506mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [Netconf] Agenda for the NETCONF Session in IETF 92
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, 22 Mar 2015 14:43:51 -0000

--_000_8AE0F17B87264D4CAC7DE0AA6C406F457CED697Cnkgeml506mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dear Chair,

4. A NETCONF Extension for Data Fragmentation - G. Zheng (5 min.)
         http://tools.ietf.org/html/draft-liu-netconf-fragmentation-01

Actually we extended the original scope of the draft to include several oth=
er things that might belong to the same problem space. So we submitted a ne=
w -00 draft rather than an updating it.
Would you mind changing the above item to the following? Sorry for informin=
g you late.


4. Processing Multiple Replies in NETCONF - B. Liu (5 min.)

         http://tools.ietf.org/html/draft-liu-netconf-multiple-replies-00


Thanks a lot.

Best regards,
Bing

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet =
(Nokia - DE/Munich)
Sent: Sunday, March 22, 2015 7:53 AM
To: netconf@ietf.org
Subject: [Netconf] Agenda for the NETCONF Session in IETF 92

All,

please find on IETF server the updated agenda for the NETCONF Session in IE=
TF 92:

https://datatracker.ietf.org/meeting/92/agenda/netconf/

Best Regards,
Mehmet & Mahesh





--_000_8AE0F17B87264D4CAC7DE0AA6C406F457CED697Cnkgeml506mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Dear Ch=
air,


 =
;


4.=
 A NETCONF Extension for Data Fragmentation - G. Zheng (5 min.)<=
/span>


&n=
bsp;        http://tools.ietf.org/html/d=
raft-liu-netconf-fragmentation-01


 


Actually w=
e extended the original scope of the draft to include several other things =
that might belong to the same problem space. So we submitted
 a new -00 draft rather than an updating it.


Would you =
mind changing the above item to the following? Sorry for informing you late=
.


 =
;


4. Processing Multiple Replies in NETCONF –=
 B. Liu (5 min.)


         =
http://tools.ietf.org/html/draft-liu-netconf-multiple-replies-00=



 


Thanks a l=
ot.


 =
;


Best regar=
ds,


Bing<=
/o:p>


 =
;






From: Netconf [mailto:netconf-bounces@ietf.org]
On Behalf Of Ersue, Mehmet (Nokia - DE/Munich)

Sent: Sunday, March 22, 2015 7:53 AM

To: netconf@ietf.org

Subject: [Netconf] Agenda for the NETCONF Session in IETF 92






 




All,






 






please fin=
d on IETF server the updated agenda for the NETCONF Session in IETF 92:






 







 






Best Regar=
ds,


Mehmet & Mahesh





 






 






 






 








--_000_8AE0F17B87264D4CAC7DE0AA6C406F457CED697Cnkgeml506mbxchi_--


From nobody Sun Mar 22 08:22:09 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D8D1ABD3B for ; Sun, 22 Mar 2015 08:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FfUdrpr1bGFW for ; Sun, 22 Mar 2015 08:22:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 068451A89F9 for ; Sun, 22 Mar 2015 08:22:00 -0700 (PDT)
Received: from localhost (unknown [31.133.138.16]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B6D61280978; Sun, 22 Mar 2015 16:21:58 +0100 (CET)
Date: Sun, 22 Mar 2015 10:21:56 -0500 (CDT)
Message-Id: <20150322.102156.1087766788843772165.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: 
References: <20150317.152756.1341316749588622343.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] mbj review of draft-ietf-netconf-server-model-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: Sun, 22 Mar 2015 15:22:05 -0000

Kent Watsen  wrote:
> >o  call-home / application / connection-type
> >
> >  The call-home draft mentions this objective:
> >
> >   o  The network element may proactively call home after being powered
> >      on for the first time in order to register itself with its
> >      management system.
> >
> >  How is this use case supported in this model?
> 
> The zerotouch draft discusses how a network element can obtain an initial
> configuration during factory-default power on.  Example A.3 in that draft
> uses 
> the module defined in this draft.  The server-model enables NETCONF Call
> Home to be configured, that's all.  Is there a specific change in the text
> you're hoping to see in this draft?

If all that is needed in this case is inital call-home, how would the
call home feature be used in this case?  I assume it could be set up
to do a persistent connecttion, and one the management application
receives this initial "registration", it can reconfigure the device to
not have call home enabled.

> >  It also mentions:
> >
> >   o  The network element may access the network in a way that
> >      dynamically assigns it an IP address and it doesn't register its
> >      assigned IP addressed to a mapping service, thus complicating the
> >      ability for a management system to connect to it.
> >
> >  How is this use case supported in this model?
> 
> This bullet point is supported by the NETCONF Call Home, by the device
> initiating the TCP connection.  That is, the solution does not rely on
> the network element's IP address in any way, it could be static, dynamic,
> NAT-ed, or whatever.  The server-model merely enables NETCONF Call Home
> to be configured, but doesn't realize this benefit itself.  Is there a
> specific change in the text you're hoping to see in this draft?

It seems to me that neither persistent nor periodic call home would be
correct for this case.  Wouldn't the device call home after start up,
and after that let the client initiate future sessions as needed?  And
the client cannot disable call home like above, b/c if it gets another
ip address after a reboot, the call home is necessary.  Do we need a
new connection-type for this?

> >o  call-home / application / connection-type / periodic-connention
> >
> >   The leaf timeout-mins is of type uint8.  Isn't this a bit small?  I
> >   think this should be uint16.
> 
> Perhaps.  256 minutes is a little more than 4 hours, which in my world
> seems like a crazy amount of time for a device to not be connected to its
> management system.

I am thinking about a use case like TR-069, where there are *lots* of
CPEs and they don't have to be connection very often.

> >   Also, the text says that a device "should" pro-actively connect to
> >   the client if it has messages to send.  Maybe this is is good
> >   enough, but in a deployment with *lots* of devices, maybe you want
> >   to suppress such messages to a time window when the client is
> >   prepared to handle it.  Again, maybe this use case is better done
> >   with a new type of connection-type ("absolute-time" or something),
> >   and such a container can be augmented later.  I just wonder if you
> >   thought about this use case.
> 
> I think you mean "to a time window when the *server* is prepared to handle
> it."

No I meant the client.  Maybe the client needs to spread out the
connections from the servers in order to scale.

> The thinking behind this is that the message could be a fault or security
> alert that should be delivered with haste, without regards for the
> data-collection system's scalability.  That said, I can easily support the
> idea of the device buffering low-priority messages and perhaps high-
> priority messages too, if that's how it's been designed or configured
> - so be it.
> 
> Perhaps the SHOULD should be a MAY?  The point is to call out that it's
> possible for a device to connect sooner than it's periodic timeout would
> have it do.

Ok.

> It's one thing to connect just in case the NETCONF client
> has pending messages for the device, and yet another for if the device
> itself have something to send.  Maybe there should be two timeouts - one
> for each of these cases?  Or nix the whole idea with the assumption the
> device has a replay-buffer that the NETCONF client can pull previous
> messages from?

I think the MAY solves the issue.  More elaborate connection schemes
can be added in the future.

> >o  tls / client-auth
> >
> >   Why do we need both trusted-client-certs and cert-maps?
> 
> Trusted-client-certs (and trusted-ca-certs) is used by the TLS-layer to
> validate the client's certificate.  Separately, cert-maps is used by the
> NETCONF/RESTCONF layers to extract a username from the client's
> certificate.  Makes sense?

This could be made more clear.  The description for trusted-certs says

      "A list of client certificates that a NETCONF server can use
       to authenticate a NETCONF client's certificate".
          ^^^^^^^^^^^^

But maybe this whole thing goes away if certificates are not stored in
this data model at all, just like the host keys; see Juergen's
comment.

> >   Also, is it a bug or a faeture that we have two separate leaf-lists
> >   of trusted-ca-certs, one for ssh and one for tls?
> 
> It was meant to maximize flexibility, but I don't think it makes sense for
> the netconf server to differentiate trusted CA or client-certs by
> transport protocol.  Do you agree?

Yes.

> >  Also, is the word "NETCONF client" correct here?  Ths point is that
> >  the keep-alive message in on the transport layer.
> 
> Unsure.  On one hand, each NETCONF message is a transport-level message
> but, on the other hand, it is technically a transport-level message that
> matters.   Would you rather see "SSH/TLS client"?

I think so, yes.


/martin


From nobody Mon Mar 23 16:50:57 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526311A6FBC; Mon, 23 Mar 2015 16:50:55 -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 iTihMxCtr8fg; Mon, 23 Mar 2015 16:50:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E30D71A6F7A; Mon, 23 Mar 2015 16:50:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Barry Leiba" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150323235053.4841.85684.idtracker@ietfa.amsl.com>
Date: Mon, 23 Mar 2015 16:50:53 -0700
Archived-At: 
Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org
Subject: [Netconf] Barry Leiba's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT)
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, 23 Mar 2015 23:50:55 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-netconf-rfc5539bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 5 --

   presented X.509 certificate may also be considered valid if it
   matches a locally configured certificate fingerprint.  If X.509
   certificate path validation fails and the presented X.509 certificate
   does not match a locally configured certificate fingerprint,

It's probably worth it here to allow for things such as DANE, by slightly
changing the wording.  what do you think of this, perhaps?:

NEW
   presented X.509 certificate may also be considered valid if it
   matches one obtained by another trusted mechanism, such as
   using a locally configured certificate fingerprint.  If X.509
   certificate path validation fails and the presented X.509 certificate
   does not match a certificate obtained by a trusted mechanism,
END

Does something like that make sense?  Or is it better to limit it to
preconfigured certs?

-- Section 7 --

        Similarily, if the
        username does not comply to the NETCONF requirements on
        usernames [RFC6241] (i.e., the username is not representable in
        XML)

Checking: Is "not representable in XML" really the only way the username
would not comply?  That is, is "i.e." correct here, or do you mean
"e.g."?

-- Section 9 --

   If third-
   party authentication is needed, the SSH transport can be used.

Very small point: you have four citations to 6242 in two paragraphs in
Section 3, but none here.  This would probably be a good place to stick
another citation.



From nobody Tue Mar 24 10:29:46 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC101A9234; Tue, 24 Mar 2015 10:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 fp2JVv1V8IaB; Tue, 24 Mar 2015 10:29:37 -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 7C1F61AC3E7; Tue, 24 Mar 2015 10:29:36 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F2CAF1565; Tue, 24 Mar 2015 18:29:34 +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 Ys0urSfGn9xn; Tue, 24 Mar 2015 18:29:25 +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; Tue, 24 Mar 2015 18:29:34 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AD762002C; Tue, 24 Mar 2015 18:29:34 +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 nB4iUMuyymaW; Tue, 24 Mar 2015 18:29:33 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8600620013; Tue, 24 Mar 2015 18:29:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 0B03A32817E4; Tue, 24 Mar 2015 18:29:30 +0100 (CET)
Date: Tue, 24 Mar 2015 18:29:30 +0100
From: Juergen Schoenwaelder 
To: Barry Leiba 
Message-ID: <20150324172928.GC60179@elstar.local>
Mail-Followup-To: Barry Leiba , The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org
References: <20150323235053.4841.85684.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150323235053.4841.85684.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, The IESG , netconf@ietf.org
Subject: Re: [Netconf] Barry Leiba's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT)
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, 24 Mar 2015 17:29:40 -0000

On Mon, Mar 23, 2015 at 04:50:53PM -0700, Barry Leiba wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -- Section 5 --
> 
>    presented X.509 certificate may also be considered valid if it
>    matches a locally configured certificate fingerprint.  If X.509
>    certificate path validation fails and the presented X.509 certificate
>    does not match a locally configured certificate fingerprint,
> 
> It's probably worth it here to allow for things such as DANE, by slightly
> changing the wording.  what do you think of this, perhaps?:
> 
> NEW
>    presented X.509 certificate may also be considered valid if it
>    matches one obtained by another trusted mechanism, such as
>    using a locally configured certificate fingerprint.  If X.509
>    certificate path validation fails and the presented X.509 certificate
>    does not match a certificate obtained by a trusted mechanism,
> END
> 
> Does something like that make sense?  Or is it better to limit it to
> preconfigured certs?

I think your rewording suggestion makes a lot of sense in order to
future proof things.
 
> -- Section 7 --
> 
>         Similarily, if the
>         username does not comply to the NETCONF requirements on
>         usernames [RFC6241] (i.e., the username is not representable in
>         XML)
> 
> Checking: Is "not representable in XML" really the only way the username
> would not comply?  That is, is "i.e." correct here, or do you mean
> "e.g."?

My counter proposal is to simply remove the text in the parenthesis
entirely, implementors lookup what RFC6241 says anyway.

> -- Section 9 --
> 
>    If third-
>    party authentication is needed, the SSH transport can be used.
> 
> Very small point: you have four citations to 6242 in two paragraphs in
> Section 3, but none here.  This would probably be a good place to stick
> another citation.

Sure, this is easy to add.

/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 Mar 24 15:57:58 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FF61ACC72 for ; Tue, 24 Mar 2015 15:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 Je522J6qV_qQ for ; Tue, 24 Mar 2015 15:57:54 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035781A1BA2 for ; Tue, 24 Mar 2015 15:57:54 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CB05214E6 for ; Tue, 24 Mar 2015 23:57:52 +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 2_DhmNXMos87 for ; Tue, 24 Mar 2015 23:57: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 for ; Tue, 24 Mar 2015 23:57:52 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13DF62002B for ; Tue, 24 Mar 2015 23:57:52 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6eE8TqzAHCNP; Tue, 24 Mar 2015 23:57:50 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1AFB20013; Tue, 24 Mar 2015 23:57:49 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id ABFE73281CC3; Tue, 24 Mar 2015 23:57:49 +0100 (CET)
Date: Tue, 24 Mar 2015 23:57:49 +0100
From: Juergen Schoenwaelder 
To: netconf@ietf.org
Message-ID: <20150324225749.GA61508@elstar.local>
Mail-Followup-To: netconf@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [Netconf] input to the RESTCONF scope discussion
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, 24 Mar 2015 22:57:56 -0000

Hi,

during our discussions after today's NETCONF meeting, it became clear
to me that I might not have been clear enough in my comments that
touch on the scope of RESTCONF. So for the benefit of all, I try to
clarify some things:

- I am fine with the concept of a unified datastore. However, I like
  to have it clearly defined and in particular I like to have it
  defined how the unified datastore interacts with traditional NETCONF
  datastores (in particular when it comes to persistence properties).
  I also like to see explicit text how the unified datastore interacts
  with NETCONF locks etc. (e.g., is the RESTCONF implementation
  acquiring locks behind the scenes, which errors do I get in case
  NETCONF has something conflicting locked). I am _not_ requesting
  that all NETCONF datastores are exposed via RESTCONF.

- I suggest that RESTCONF is _prepared_ to support future extensions
  such as ephemeral datastores.

- I generally like the YANG patch approach for editing but I like to
  see it defined such that it _can_ work with both RESTCONF and
  NETCONF.  I do _not_ request that RESTCONF supports edits by
  exposing the NETCONF edit-config approach to RESTCONF clients.

- I believe we should take advantage of things like anydata or boolean
  if-feature expressions etc. that we have worked on during the last
  year in the context of YANG 1.1. Since the same set of people are
  involved in the various documents, we should be able to make sure
  nothing gets stuck because of dependencies.

- I am somewhat concerned about data models that are NETCONF or
  RESTCONF specific. While there will be such data models, these
  should be rare corner cases. The majority of data models should work
  regardless of the protocol choice. In particular, references in data
  models SHOULD use YANG naming schemes and data types (e.g.,
  instance-identifier) and avoid using protocol specific naming
  schemes.

Perhaps this helps to better understand my other comments.

/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 Mar 25 07:43:38 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B561B2A17 for ; Wed, 25 Mar 2015 07:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 TLhon7I636f9 for ; Wed, 25 Mar 2015 07:43:35 -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 391491AD350 for ; Wed, 25 Mar 2015 07:42:08 -0700 (PDT)
Received: from dhcp-b511.meeting.ietf.org (dhcp-b511.meeting.ietf.org [31.133.181.17]) by mail.nic.cz (Postfix) with ESMTPSA id DEF8A140AD5; Wed, 25 Mar 2015 15:42:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1427294526; bh=bl3YKC3YhDiirr0qsCGCpiKmLSzTtIqJmtoGBfc8A0g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IDURsnSAaJLwNvGvihCsLa71Mr1/LnL1uHS8d85uMiVWesNITPGEkZPd52OMDJJO6 7ZiGrR1gw6a//QYmQXq3vGqtYtlfwM091jqauseuYNRkeEVzIoSewOaq8gflpbcY5H iHUvNIDu3u1mELIuXB8FHAeQkA9VoOPMXOGiuiZ0=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ladislav Lhotka 
In-Reply-To: <20150324225749.GA61508@elstar.local>
Date: Wed, 25 Mar 2015 09:42:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BA8B74E-2BA0-4E4D-A82F-565B4A75B3EB@nic.cz>
References: <20150324225749.GA61508@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.2070.6)
X-Virus-Scanned: clamav-milter 0.98.6 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] input to the RESTCONF scope discussion
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, 25 Mar 2015 14:43:37 -0000

> On 24 Mar 2015, at 17:57, Juergen Schoenwaelder =
 wrote:
>=20
> Hi,
>=20
> during our discussions after today's NETCONF meeting, it became clear
> to me that I might not have been clear enough in my comments that
> touch on the scope of RESTCONF. So for the benefit of all, I try to
> clarify some things:
>=20
> - I am fine with the concept of a unified datastore. However, I like
>  to have it clearly defined and in particular I like to have it
>  defined how the unified datastore interacts with traditional NETCONF
>  datastores (in particular when it comes to persistence properties).
>  I also like to see explicit text how the unified datastore interacts
>  with NETCONF locks etc. (e.g., is the RESTCONF implementation
>  acquiring locks behind the scenes, which errors do I get in case
>  NETCONF has something conflicting locked). I am _not_ requesting
>  that all NETCONF datastores are exposed via RESTCONF.

The RESTCONF spec should indeed define the precise semantics of the =
unified datastore but the interaction with NETCONF is IMO secondary =
because there is no requirement that NETCONF be present as a =
=E2=80=9Cbackend=E2=80=9D to RESTCONF.

Lada

>=20
> - I suggest that RESTCONF is _prepared_ to support future extensions
>  such as ephemeral datastores.
>=20
> - I generally like the YANG patch approach for editing but I like to
>  see it defined such that it _can_ work with both RESTCONF and
>  NETCONF.  I do _not_ request that RESTCONF supports edits by
>  exposing the NETCONF edit-config approach to RESTCONF clients.
>=20
> - I believe we should take advantage of things like anydata or boolean
>  if-feature expressions etc. that we have worked on during the last
>  year in the context of YANG 1.1. Since the same set of people are
>  involved in the various documents, we should be able to make sure
>  nothing gets stuck because of dependencies.
>=20
> - I am somewhat concerned about data models that are NETCONF or
>  RESTCONF specific. While there will be such data models, these
>  should be rare corner cases. The majority of data models should work
>  regardless of the protocol choice. In particular, references in data
>  models SHOULD use YANG naming schemes and data types (e.g.,
>  instance-identifier) and avoid using protocol specific naming
>  schemes.
>=20
> Perhaps this helps to better understand my other comments.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=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 Wed Mar 25 10:12:37 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299EC1A8A67 for ; Wed, 25 Mar 2015 10:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 h1MhX6w7SMr0 for ; Wed, 25 Mar 2015 10:12:34 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B621A88F3 for ; Wed, 25 Mar 2015 10:12:32 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A3EF81264; Wed, 25 Mar 2015 18:12:31 +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 mOkoVyLw7VAG; Wed, 25 Mar 2015 18:12:16 +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; Wed, 25 Mar 2015 18:12:31 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C633B2002B; Wed, 25 Mar 2015 18:12:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zmxwDOC9zRRo; Wed, 25 Mar 2015 18:12:29 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA0D720013; Wed, 25 Mar 2015 18:12:28 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D4E9D3282850; Wed, 25 Mar 2015 18:12:28 +0100 (CET)
Date: Wed, 25 Mar 2015 18:12:28 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20150325171228.GC65972@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Netconf 
References: <20150324225749.GA61508@elstar.local> <0BA8B74E-2BA0-4E4D-A82F-565B4A75B3EB@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <0BA8B74E-2BA0-4E4D-A82F-565B4A75B3EB@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] input to the RESTCONF scope discussion
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 17:12:36 -0000

On Wed, Mar 25, 2015 at 09:42:03AM -0500, Ladislav Lhotka wrote:
> 
> > On 24 Mar 2015, at 17:57, Juergen Schoenwaelder  wrote:
> > 
> > Hi,
> > 
> > during our discussions after today's NETCONF meeting, it became clear
> > to me that I might not have been clear enough in my comments that
> > touch on the scope of RESTCONF. So for the benefit of all, I try to
> > clarify some things:
> > 
> > - I am fine with the concept of a unified datastore. However, I like
> >  to have it clearly defined and in particular I like to have it
> >  defined how the unified datastore interacts with traditional NETCONF
> >  datastores (in particular when it comes to persistence properties).
> >  I also like to see explicit text how the unified datastore interacts
> >  with NETCONF locks etc. (e.g., is the RESTCONF implementation
> >  acquiring locks behind the scenes, which errors do I get in case
> >  NETCONF has something conflicting locked). I am _not_ requesting
> >  that all NETCONF datastores are exposed via RESTCONF.
> 
> The RESTCONF spec should indeed define the precise semantics of the unified datastore but the interaction with NETCONF is IMO secondary because there is no requirement that NETCONF be present as a “backend” to RESTCONF.
>

There are implementations that do both so it better be defined what
happens if things interact so behaviour is predictably. This has
nothing to do with any requirements logic.

/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 Mar 25 11:42:53 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D31AC41C for ; Wed, 25 Mar 2015 11:42:45 -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 kOg6iVqNcJaC for ; Wed, 25 Mar 2015 11:42:42 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6A81AC41D for ; Wed, 25 Mar 2015 11:42:42 -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.1.118.21; Wed, 25 Mar 2015 18:42:26 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Wed, 25 Mar 2015 18:42:26 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #32: rename "application" to netconf/restconf-client
Thread-Index: AQHQZytw+swcmb/HLkawTjQzKpdsqQ==
Date: Wed, 25 Mar 2015 18:42:25 +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-originating-ip: [66.129.239.14]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(19580395003)(19617315012)(54356999)(50986999)(122556002)(40100003)(86362001)(87936001)(2656002)(2501003)(16236675004)(66066001)(99286002)(15975445007)(83506001)(46102003)(106116001)(110136001)(102836002)(2351001)(92566002)(107886001)(2900100001)(229853001)(77156002)(450100001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 052670E5A4
Content-Type: multipart/alternative; boundary="_000_D13879CE9B5D5kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 18:42:26.0049 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Subject: [Netconf] server-model #32: rename "application" to netconf/restconf-client
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, 25 Mar 2015 18:42:46 -0000

--_000_D13879CE9B5D5kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This issue was disused yesterday with an agreement to make this change (see=
 subject line), both in the YANG modules and in the text throughout in the =
draft.  The issue is hence moved to the VERIFY state.  The issue will move =
to the EDIT state If no objection is raised by April 6th.

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

Thanks,
Kent


--_000_D13879CE9B5D5kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable












This issue was disused yesterday with an agreement to make this change=
 (see subject line), both in the YANG modules and in the text throughout in=
 the draft.  The issue is hence moved to the VERIFY state.  The i=
ssue will move to the EDIT state If no objection
 is raised by April 6th.













Thanks,


Kent









--_000_D13879CE9B5D5kwatsenjunipernet_--


From nobody Wed Mar 25 11:52:18 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343BA1B2AA5 for ; Wed, 25 Mar 2015 11:52:17 -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 mClLtgfR0yHM for ; Wed, 25 Mar 2015 11:52:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4151B2A3A for ; Wed, 25 Mar 2015 11:52:14 -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.1.118.21; Wed, 25 Mar 2015 18:51:55 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Wed, 25 Mar 2015 18:51:55 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #33: Is it a good idea to name the top-level node "netconf-server"?
Thread-Index: AQHQZyzD9T1MIMijyUeaLpU6jQNVrg==
Date: Wed, 25 Mar 2015 18:51:55 +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-originating-ip: [66.129.239.14]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(36756003)(50986999)(2656002)(86362001)(122556002)(54356999)(83506001)(66066001)(2501003)(106116001)(15975445007)(102836002)(46102003)(19617315012)(92566002)(229853001)(107886001)(450100001)(77156002)(2351001)(16236675004)(87936001)(99286002)(110136001)(19580395003)(40100003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 052670E5A4
Content-Type: multipart/alternative; boundary="_000_D1387C089B5E7kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 18:51:55.2991 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: [Netconf] server-model #33: Is it a good idea to name the top-level node "netconf-server"?
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, 25 Mar 2015 18:52:17 -0000

--_000_D1387C089B5E7kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



This issue was discussed yesterday and again this morning.  The current agr=
eement is to leave the top-level name as it is.  The issue is hence moved t=
o the VERIFY state.  The issue will move to the DEAD state If no objection =
is raised by April 6th.

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

Thanks,
Kent


--_000_D1387C089B5E7kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable





















This issue was discussed yesterday a=
nd again this morning.  The current agreement is to leave the top-leve=
l name as it is.  The issue is hence moved to the VERIFY state.
  The issue will move to the DEAD state If no objection is raised by A=
pril 6th.


















Thanks,



Kent










--_000_D1387C089B5E7kwatsenjunipernet_--


From nobody Wed Mar 25 11:57:17 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7672F1B2AEA for ; Wed, 25 Mar 2015 11:57:09 -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 Xd5sAGwhedz3 for ; Wed, 25 Mar 2015 11:57:06 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139771B2B0C for ; Wed, 25 Mar 2015 11:56:54 -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.1.118.21; Wed, 25 Mar 2015 18:56:35 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Wed, 25 Mar 2015 18:56:35 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] server-model #32: rename "application" to netconf/restconf-client
Thread-Index: AQHQZytw+swcmb/HLkawTjQzKpdsqZ0tSWwA
Date: Wed, 25 Mar 2015 18:56:35 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [66.129.239.14]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(377454003)(19617315012)(46102003)(2950100001)(92566002)(106116001)(102836002)(15975445007)(40100003)(19580395003)(110136001)(99286002)(2900100001)(77156002)(2351001)(107886001)(450100001)(16236675004)(87936001)(122556002)(54356999)(76176999)(36756003)(86362001)(2656002)(50986999)(2501003)(66066001)(19580405001)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 052670E5A4
Content-Type: multipart/alternative; boundary="_000_D1387CF99B5F1kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 18:56:35.4132 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: Re: [Netconf] server-model #32: rename "application" to netconf/restconf-client
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, 25 Mar 2015 18:57:09 -0000

--_000_D1387CF99B5F1kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

s/disused/discussed/

From: Kent Watsen >
Date: Wednesday, March 25, 2015 at 2:42 PM
To: "netconf@ietf.org" >
Subject: [Netconf] server-model #32: rename "application" to netconf/restco=
nf-client


This issue was disused yesterday with an agreement to make this change (see=
 subject line), both in the YANG modules and in the text throughout in the =
draft.  The issue is hence moved to the VERIFY state.  The issue will move =
to the EDIT state If no objection is raised by April 6th.

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

Thanks,
Kent


--_000_D1387CF99B5F1kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







s/disused/discussed/










From: Kent Watsen <kwatsen@juniper.net>

Date: Wednesday, March 25, 2015 at =
2:42 PM

To: "netconf@ietf.org" <netconf@ietf.org>

Subject: [Netconf] server-model #32=
: rename "application" to netconf/restconf-client


















This issue was disused yesterday with an agreement to make this change=
 (see subject line), both in the YANG modules and in the text throughout in=
 the draft.  The issue is hence moved to the VERIFY state.  The i=
ssue will move to the EDIT state If no objection
 is raised by April 6th.













Thanks,


Kent














--_000_D1387CF99B5F1kwatsenjunipernet_--


From nobody Wed Mar 25 12:29:48 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD211A9171 for ; Wed, 25 Mar 2015 12:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5IyfbTbkHDl for ; Wed, 25 Mar 2015 12:29:45 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9EF1A9090 for ; Wed, 25 Mar 2015 12:29:44 -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.1.118.21; Wed, 25 Mar 2015 19:29:42 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Wed, 25 Mar 2015 19:29:42 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #34: Are the features granular enough?
Thread-Index: AQHQZzIKqzatQ89CvkKIZDVO94EBdA==
Date: Wed, 25 Mar 2015 19:29:42 +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-originating-ip: [66.129.239.19]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(106116001)(46102003)(2351001)(102836002)(92566002)(110136001)(15975445007)(83506001)(36756003)(77156002)(450100001)(2900100001)(107886001)(229853001)(54356999)(50986999)(19617315012)(19580395003)(16236675004)(66066001)(99286002)(122556002)(40100003)(2501003)(87936001)(86362001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 052670E5A4
Content-Type: multipart/alternative; boundary="_000_D13884E19B641kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 19:29:42.0211 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Subject: [Netconf] server-model #34: Are the features granular enough?
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, 25 Mar 2015 19:29:47 -0000

--_000_D13884E19B641kwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This issue was discussed yesterday with no clear agreement on what to do bu=
t, when discussing issue #49, there was an agreement to use the YANG 1.1 if=
-feature statement, which we could apply to this issue as well.

Specifically, we can go back to the feature statements we had in -04: ssh-l=
isten, tls-listen, ssh-call-home, and tls-call-home and use statements like=
 "if-feature "(ssh-listen or tls-listen)".

Essentially, to revert this change: https://github.com/netconf-wg/server-mo=
del/commit/c5ae65b679b9dceff91a2fe03f86330123e88f2a

This issue will move to the EDIT state, with the plan to revert to the -04 =
features, if no objection is raised by April 6th.

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

Thanks,
Kent


--_000_D13884E19B641kwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <1BAB35612AAC6A4090AC44363724143D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
















This issue was discussed yesterday with n=
o clear agreement on what to do but, when discussing issue #49, there was a=
n agreement to use the YANG 1.1 if-feature statement, which we =
could apply to this issue as well.   









Specifically, we can go back to the featu=
re statements we had in =
–04: ssh-listen, tls-li=
sten, ssh-call-home, and tls-call-home and use statements like
 "if-feature "(ssh-listen or tls-listen)".  &nbs=
p;














This issue will move to the EDIT sta=
te, with the plan to revert to the -04 features, if no objection is ra=
ised by April 6th.









https://github.com/netconf-wg/server-mode=
l/issues/34









Thanks,



Kent












--_000_D13884E19B641kwatsenjunipernet_--


From nobody Wed Mar 25 12:39:04 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787E71A89AD for ; Wed, 25 Mar 2015 12:39:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 EFMGIMCHjL3a for ; Wed, 25 Mar 2015 12:39:00 -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 B8BE01A89A6 for ; Wed, 25 Mar 2015 12:39:00 -0700 (PDT)
Received: from [IPv6:2001:67c:370:176:dd1d:1fa:3efc:1eef] (unknown [IPv6:2001:67c:370:176:dd1d:1fa:3efc:1eef]) by mail.nic.cz (Postfix) with ESMTPSA id 9ED85140A40; Wed, 25 Mar 2015 20:38:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1427312339; bh=IFITzbD/V8sfEPkOOx1m0iD97BlLA/8SwLtWwuH6yzQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ne+H6GEhA9m6ljrVoqYwfewnr2zJEyjmJls+8+wxRBVEyrEuu5H+YLKZk1+uQwM7b XeUbqtCLqEwztu+Ce3G0Q0/q8wGKYKyzACtnflOWQfUXSpV3oO6CLupngXI5ttMrzN Z0xsl9Is3x0m6SsRebgunctRdNym8JD57xRJFjus=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ladislav Lhotka 
In-Reply-To: <20150325171228.GC65972@elstar.local>
Date: Wed, 25 Mar 2015 14:38:57 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FF7F932-AE8B-488E-A333-8C43EB43DDEA@nic.cz>
References: <20150324225749.GA61508@elstar.local> <0BA8B74E-2BA0-4E4D-A82F-565B4A75B3EB@nic.cz> <20150325171228.GC65972@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.2070.6)
X-Virus-Scanned: clamav-milter 0.98.6 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] input to the RESTCONF scope discussion
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, 25 Mar 2015 19:39:02 -0000

> On 25 Mar 2015, at 12:12, Juergen Schoenwaelder =
 wrote:
>=20
> On Wed, Mar 25, 2015 at 09:42:03AM -0500, Ladislav Lhotka wrote:
>>=20
>>> On 24 Mar 2015, at 17:57, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> Hi,
>>>=20
>>> during our discussions after today's NETCONF meeting, it became =
clear
>>> to me that I might not have been clear enough in my comments that
>>> touch on the scope of RESTCONF. So for the benefit of all, I try to
>>> clarify some things:
>>>=20
>>> - I am fine with the concept of a unified datastore. However, I like
>>> to have it clearly defined and in particular I like to have it
>>> defined how the unified datastore interacts with traditional NETCONF
>>> datastores (in particular when it comes to persistence properties).
>>> I also like to see explicit text how the unified datastore interacts
>>> with NETCONF locks etc. (e.g., is the RESTCONF implementation
>>> acquiring locks behind the scenes, which errors do I get in case
>>> NETCONF has something conflicting locked). I am _not_ requesting
>>> that all NETCONF datastores are exposed via RESTCONF.
>>=20
>> The RESTCONF spec should indeed define the precise semantics of the =
unified datastore but the interaction with NETCONF is IMO secondary =
because there is no requirement that NETCONF be present as a =
=E2=80=9Cbackend=E2=80=9D to RESTCONF.
>>=20
>=20
> There are implementations that do both so it better be defined what
> happens if things interact so behaviour is predictably. This has
> nothing to do with any requirements logic.

My point is that this part needn=E2=80=99t necessarily be in the base =
RESTCONF spec which is already quite long.

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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





From nobody Wed Mar 25 12:55:41 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F4C1A8A8F for ; Wed, 25 Mar 2015 12:55: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, 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 myMPNRM92GAR for ; Wed, 25 Mar 2015 12:55:38 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9D01B2B45 for ; Wed, 25 Mar 2015 12:55:37 -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.1.118.21; Wed, 25 Mar 2015 19:55:17 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.152]) with mapi id 15.01.0118.021; Wed, 25 Mar 2015 19:55:18 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #38: remove upper-bound on hello-timeout, idle-timeout, and max-sessions?
Thread-Index: AQHQZzWeIp1/A0NbP0CMudOaSEKkfw==
Date: Wed, 25 Mar 2015 19:55:17 +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-originating-ip: [66.129.239.14]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(102836002)(15975445007)(99286002)(2900100001)(2656002)(19580395003)(86362001)(83506001)(106116001)(229853001)(2351001)(110136001)(107886001)(450100001)(77156002)(40100003)(122556002)(2501003)(16236675004)(46102003)(36756003)(87936001)(66066001)(50986999)(92566002)(19617315012)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 052670E5A4
Content-Type: multipart/alternative; boundary="_000_D1388AE39B6A3kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 19:55:17.7708 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: [Netconf] server-model #38: remove upper-bound on hello-timeout, idle-timeout, and max-sessions?
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, 25 Mar 2015 19:55:40 -0000

--_000_D1388AE39B6A3kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This issue was discussed yesterday with an agreement to remove these upper =
bounds from the YANG module.  It is understood that servers may have upper-=
bounds, and would return an error if a client attempts to configure past an=
y of them.  The issue is hence moved to the VERIFY state.  The issue will m=
ove to the EDIT state If no objection is raised by April 6th.

How this issue will be implemented will be guided by the resolution to issu=
e #39.

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

Thanks,
Kent


--_000_D1388AE39B6A3kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable













This issue was discussed yesterday w=
ith an agreement to remove these upper bounds from the YANG module. &n=
bsp;It is understood that servers may have upper-bounds, and would return a=
n error if a client attempts to configure past
 any of them.  The issue is hence moved to the VERIFY state. &n=
bsp;The issue will move to the EDIT state If no objection is raised by Apri=
l 6th.







How this issue will be implemented w=
ill be guided by the resolution to issue #39. 
















Thanks,



Kent










--_000_D1388AE39B6A3kwatsenjunipernet_--


From nobody Wed Mar 25 16:01:20 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474091AC41A for ; Wed, 25 Mar 2015 16:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level: 
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 UaHOEv_Rv81P for ; Wed, 25 Mar 2015 16: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 36A611ABD3A for ; Wed, 25 Mar 2015 16:01:13 -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 t2PN16op010381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Mar 2015 23:01:06 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 t2PN15Bk026500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 00:01:05 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 26 Mar 2015 00:01:05 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.51]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 00:01:05 +0100
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: Benoit Claise , "netconf@ietf.org" 
Thread-Topic: Summary and AIs from the NETCONF Session in IETF #92
Thread-Index: AdBnT5Cv9zJHC7oCQPC9RoJ+RVjt2w==
Date: Wed, 25 Mar 2015 23:01:05 +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: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819670C37DEMUMBX005nsnin_"
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: 14495
X-purgate-ID: 151667::1427324466-00007F9C-C044646A/0/0
Archived-At: 
Subject: [Netconf] Summary and AIs from the NETCONF Session in IETF #92
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, 25 Mar 2015 23:01:19 -0000

--_000_E4DE949E6CE3E34993A2FF8AE79131F819670C37DEMUMBX005nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Benoit, NETCONF WG,

below is a summary and action items from the NETCONF WG session on March 24=
, 2014, Dallas, USA.
A Wiki version of this summary will be made available at OPS area Wiki page=
 soon (at http://trac.tools.ietf.org/area/ops/trac/wiki/IETF92summary).

- We had approx. 90+ participants in the 2 hour NETCONF session,
- We reviewed the status of the WG (https://www.ietf.org/proceedings/92/sli=
des/slides-92-netconf-2.pptx),
- We had a discussion on 7 chartered documents.

- Note taker was: Lada Lhotka. The Jabber scribe was Mikael Abrahamsson.
Many thanks to the note takers and jabber scribe for volunteering.

The session agenda is available at: https://www.ietf.org/proceedings/92/age=
nda/agenda-92-netconf

Following is a summary of the discussion and the decisions taken per show-h=
ands.
If there is no strong objection we will implement as proposed.

*       Issues after the WGLC of the RESTCONF and YANG Patch drafts have be=
en discussed. See https://www.ietf.org/proceedings/92/slides/slides-92-netc=
onf-0.pdf and https://www.ietf.org/proceedings/92/slides/slides-92-netconf-=
1.pdf.
*       Currently open issues for the YANG Library and RESTCONF Collection =
Resource drafts have been discussed. See https://www.ietf.org/proceedings/9=
2/slides/slides-92-netconf-10.pdf and https://www.ietf.org/proceedings/92/s=
lides/slides-92-netconf-11.pdf.
*       A few issues are remaining and will be taken to the maillist. If th=
ere is no objection, the solution described on an issue slide will be reali=
zed as proposed. WG members are asked to speak up on the maillist if there =
is any concern on the proposed solution.
*       RESTCONF, YANG Patch and YANG Library drafts will go to 2nd WGLC a =
few weeks after IETF 92 once the drafts are available after issue solving.
*       WG co-chairs are asking the chairs of related WGs (e.g. Core, 6lo, =
6tisch) to assign individuals as reviewer.

*       Issues after the WGLC of the Call Home and Server Model drafts have=
 been discussed. See https://www.ietf.org/proceedings/92/slides/slides-92-n=
etconf-4.pptx and https://www.ietf.org/proceedings/92/slides/slides-92-netc=
onf-5.pptx.
*       If there is no objection, the solution described on an issue slide =
will be realized as proposed. WG members are asked to speak up on the maill=
ist if there is any concern on the proposed solution.
*       Call Home and Server Model drafts will go to 2nd WGLC once the draf=
ts are available after issue solving and after finalizing the WGLC for the =
RESTCONF drafts.

*       During the discussion of the Server Model draft, the use of the YAN=
G 1.1 features in current NETCONF drafts has been proposed. The opinion pol=
l showed 16 yes, 1 no from Andy B.
*       AI: Co-chairs will send an email to the NETCONF maillist to verify =
the poll in the meeting.
*       The open issues in Zerotouch draft have been discussed briefly. See=
 https://www.ietf.org/proceedings/92/slides/slides-92-netconf-7.pptx.  Kent=
 W. is discussing the details of the requirements on Zerotouch draft with A=
NIMA WG members. ANIMA WG is asked to agree on these requirements first in =
their WG before starting a discussion in the NETCONF WG based on a new draf=
t or subsection in an existing draft.

*       I2RS co-chair Jeff Haas summarized the NETCONF-related issues discu=
ssed in I"RS WG, which are Pub-sub requirements, Ephemeral state, Secondary=
 Identity, Priority, Transactions. See https://www.ietf.org/proceedings/92/=
slides/slides-92-netconf-8.pptx.
*       Ephemeral state is a particular issue important for I2RS WG. The vo=
lunteers for this issue (Dan B, Martin, Ken and Andy) will restart their wo=
rk.
*       draft-haas-i2rs-netmod-netconf-requirements is serving as a trackin=
g document for I2RS protocol requirements. Current requirements on ephemera=
l state are written down in the architecture draft.
*       Mehmet proposed a joint conf call to discuss the details of these i=
ssue in a joint conference call. AI: Mehmet to provide a doodle.

*       Eric Voit presented on draft-ietf-i2rs-pub-sub-requirements-01. See=
 https://www.ietf.org/proceedings/92/slides/slides-92-netconf-9.pdf.
*       The related solution draft addressing these requirements has been p=
resented by Alex Clemm. See https://www.ietf.org/proceedings/92/slides/slid=
es-92-netconf-14.pdf. This draft is proposed to adopt in NETCONF WG. 12 hav=
e read the draft. 12 support the draft and 0 against.
*       Mehmet clarified that new WG items can be adopted after finalizing =
current active items. This will be possibly in IETF 93 time frame.

*       draft-liu-netconf-multiple-replies-00 on Processing Multiple Replie=
s for One Request in NETCONF has been presented by Guangying Zheng. See htt=
ps://www.ietf.org/proceedings/92/slides/slides-92-netconf-3.ppt. 5 people h=
ave read the draft. 5 support adopting the draft. Will take it to the maili=
ng list.
*       draft-mm-netconf-time-capability-02 on Time Capability in NETCONF c=
ouldn't be discussed due to lack of time. See https://www.ietf.org/proceedi=
ngs/92/slides/slides-92-netconf-13.pdf.
*       The chair suggested that both, draft-liu and draft-mm, should raise=
 discussion on the maillist and get the support of the WG members.

Cheers,
Mehmet



--_000_E4DE949E6CE3E34993A2FF8AE79131F819670C37DEMUMBX005nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Benoit, NETCONF WG,


 


below is a summary and action items from the NETCONF WG session on Mar=
ch 24, 2014, Dallas, USA. 


A Wiki version of this summary will be made available at OPS area Wiki=
 page soon (at http://trac.tools.ietf.org/area/ops/tra=
c/wiki/IETF92summary).


 


- We had approx. 90+ participants in the 2 hour NETCONF session,


- We had a discussion on 7 chartered documents.


 


- Note taker was: Lada Lhotka. The Jabber scribe was Mikael Abrahamsso=
n.


Many thanks to the note takers and jabber scribe for volunteering.

 



 


Following is a summary of the discussion and the decisions taken per s=
how-hands.


If there is no strong objection we will implement as proposed.


&nbs=
p;



 



 


    

  • During the discussion of the Server Model draft, the use of the YANG 1.=
1 features in current NETCONF drafts has been proposed. The opinion poll sh=
owed 16 yes, 1 no from Andy B.
  • AI: Co-chairs will send an email to =
the NETCONF maillist to verify the poll in the meeting.
  • The open is=
sues in Zerotouch draft have been discussed briefly. See https://www.i=
etf.org/proceedings/92/slides/slides-92-netconf-7.pptx.  Kent W. is dis=
cussing the details
of the requirements on Zerotouch draft with ANIMA WG members. ANIMA WG is a=
sked to agree on these requirements first in their WG before starting a dis=
cussion in the NETCONF WG based on a new draft or subsection in an existing=
 draft. 


 


    

  • I2RS co-chair Jeff Haas summarized the NETCONF-related issues discussed=
 in I”RS WG, which are Pub-sub requirements, Ephemeral state, Seconda=
ry Identity, Priority, Transactions. See https://www.ietf.org/proceedi=
ngs/92/slides/slides-92-netconf-8.pptx.
  • Ephemeral state is a pa=
rticular issue important for I2RS WG. The volunteers for this issue (Dan B,=
 Martin, Ken and Andy) will restart their work.
  • draft-haas-i2rs-net=
mod-netconf-requirements is serving as a tracking document for I2RS protoco=
l requirements. Current requirements on ephemeral state are written down in=
 the architecture draft.
  • Mehmet proposed a joint conf call to discu=
ss the details of these issue in a joint conference call. AI: Mehmet to pro=
vide a doodle.


 



 



 


Cheers, 


Mehmet 


&nbs=
p;


&nbs=
p;





--_000_E4DE949E6CE3E34993A2FF8AE79131F819670C37DEMUMBX005nsnin_--


From nobody Wed Mar 25 16:50:31 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D831E1B2AA1 for ; Wed, 25 Mar 2015 16:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level: 
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 cDniy0rvhTko for ; Wed, 25 Mar 2015 16:50:25 -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 5C9C81A6F7B for ; Wed, 25 Mar 2015 16:50:24 -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 t2PNoM8J019597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Mar 2015 23:50:22 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t2PNoLZ6004498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Mar 2015 00:50:21 +0100
Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 26 Mar 2015 00:50:21 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.51]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 00:50:21 +0100
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: "netconf@ietf.org" 
Thread-Topic: The use of YANG 1.1 Features in NETCONF Drafts    WAS: Summary and AIs from the NETCONF Session in IETF #92
Thread-Index: AQHQZ1Z0YoNPTvfdOUyHQG8gUTR4Cw==
Date: Wed, 25 Mar 2015 23:50:20 +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: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819670CD1DEMUMBX005nsnin_"
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: 68353
X-purgate-ID: 151667::1427327422-00005972-C651F64E/0/0
Archived-At: 
Subject: [Netconf] The use of YANG 1.1 Features in NETCONF Drafts WAS: Summary and AIs from the NETCONF Session in IETF #92
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, 25 Mar 2015 23:50:31 -0000

--_000_E4DE949E6CE3E34993A2FF8AE79131F819670CD1DEMUMBX005nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear NETCONF WG,

this email is to verify the opinion poll in IETF 92 NETCONF session concern=
ing the use of YANG 1.1 Features in NETCONF Drafts.

As reported in the session summary below, the opinion poll for the use of Y=
ANG 1.1 features has been supported by 16 and disagreed by 1 person.
The disagreement was based on the assumption that the finalization of the Y=
ANG 1.1 draft may possibly take longer than currently expected.

Please speak up by April 1, 2015 23:59 PT, if you have objections to use YA=
NG 1.1 features in current NETCONF drafts.
The co-chairs will declare consensus after the deadline.

Regards,
Mehmet

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh=
met (Nokia - DE/Munich)
Sent: Thursday, March 26, 2015 12:01 AM
To: Benoit Claise; netconf@ietf.org
Subject: [Netconf] Summary and AIs from the NETCONF Session in IETF #92

Hi Benoit, NETCONF WG,

below is a summary and action items from the NETCONF WG session on March 24=
, 2014, Dallas, USA.
A Wiki version of this summary will be made available at OPS area Wiki page=
 soon (at http://trac.tools.ietf.org/area/ops/trac/wiki/IETF92summary).

- We had approx. 90+ participants in the 2 hour NETCONF session,
- We reviewed the status of the WG (https://www.ietf.org/proceedings/92/sli=
des/slides-92-netconf-2.pptx),
- We had a discussion on 7 chartered documents.

- Note taker was: Lada Lhotka. The Jabber scribe was Mikael Abrahamsson.
Many thanks to the note takers and jabber scribe for volunteering.

The session agenda is available at: https://www.ietf.org/proceedings/92/age=
nda/agenda-92-netconf

Following is a summary of the discussion and the decisions taken per show-h=
ands.
If there is no strong objection we will implement as proposed.

*         Issues after the WGLC of the RESTCONF and YANG Patch drafts have =
been discussed. See https://www.ietf.org/proceedings/92/slides/slides-92-ne=
tconf-0.pdf and https://www.ietf.org/proceedings/92/slides/slides-92-netcon=
f-1.pdf.
*         Currently open issues for the YANG Library and RESTCONF Collectio=
n Resource drafts have been discussed. See https://www.ietf.org/proceedings=
/92/slides/slides-92-netconf-10.pdf and https://www.ietf.org/proceedings/92=
/slides/slides-92-netconf-11.pdf.
*         A few issues are remaining and will be taken to the maillist. If =
there is no objection, the solution described on an issue slide will be rea=
lized as proposed. WG members are asked to speak up on the maillist if ther=
e is any concern on the proposed solution.
*         RESTCONF, YANG Patch and YANG Library drafts will go to 2nd WGLC =
a few weeks after IETF 92 once the drafts are available after issue solving=
.
*         WG co-chairs are asking the chairs of related WGs (e.g. Core, 6lo=
, 6tisch) to assign individuals as reviewer.

*         Issues after the WGLC of the Call Home and Server Model drafts ha=
ve been discussed. See https://www.ietf.org/proceedings/92/slides/slides-92=
-netconf-4.pptx and https://www.ietf.org/proceedings/92/slides/slides-92-ne=
tconf-5.pptx.
*         If there is no objection, the solution described on an issue slid=
e will be realized as proposed. WG members are asked to speak up on the mai=
llist if there is any concern on the proposed solution.
*         Call Home and Server Model drafts will go to 2nd WGLC once the dr=
afts are available after issue solving and after finalizing the WGLC for th=
e RESTCONF drafts.

*         During the discussion of the Server Model draft, the use of the Y=
ANG 1.1 features in current NETCONF drafts has been proposed. The opinion p=
oll showed 16 yes, 1 no from Andy B.
*         AI: Co-chairs will send an email to the NETCONF maillist to verif=
y the poll in the meeting.
*         The open issues in Zerotouch draft have been discussed briefly. S=
ee https://www.ietf.org/proceedings/92/slides/slides-92-netconf-7.pptx. Ken=
t W. is discussing the details of the requirements on Zerotouch draft with =
ANIMA WG members. ANIMA WG is asked to agree on these requirements first in=
 their WG before starting a discussion in the NETCONF WG based on a new dra=
ft or subsection in an existing draft.

*         I2RS co-chair Jeff Haas summarized the NETCONF-related issues dis=
cussed in I"RS WG, which are Pub-sub requirements, Ephemeral state, Seconda=
ry Identity, Priority, Transactions. See https://www.ietf.org/proceedings/9=
2/slides/slides-92-netconf-8.pptx.
*         Ephemeral state is a particular issue important for I2RS WG. The =
volunteers for this issue (Dan B, Martin, Ken and Andy) will restart their =
work.
*         draft-haas-i2rs-netmod-netconf-requirements is serving as a track=
ing document for I2RS protocol requirements. Current requirements on epheme=
ral state are written down in the architecture draft.
*         Mehmet proposed a joint conf call to discuss the details of these=
 issue in a joint conference call. AI: Mehmet to provide a doodle.

*         Eric Voit presented on draft-ietf-i2rs-pub-sub-requirements-01. S=
ee https://www.ietf.org/proceedings/92/slides/slides-92-netconf-9.pdf.
*         The related solution draft addressing these requirements has been=
 presented by Alex Clemm. See https://www.ietf.org/proceedings/92/slides/sl=
ides-92-netconf-14.pdf. This draft is proposed to adopt in NETCONF WG. 12 h=
ave read the draft. 12 support the draft and 0 against.
*         Mehmet clarified that new WG items can be adopted after finalizin=
g current active items. This will be possibly in IETF 93 time frame.

*         draft-liu-netconf-multiple-replies-00 on Processing Multiple Repl=
ies for One Request in NETCONF has been presented by Guangying Zheng. See h=
ttps://www.ietf.org/proceedings/92/slides/slides-92-netconf-3.ppt. 5 people=
 have read the draft. 5 support adopting the draft. Will take it to the mai=
ling list.
*         draft-mm-netconf-time-capability-02 on Time Capability in NETCONF=
 couldn't be discussed due to lack of time. See https://www.ietf.org/procee=
dings/92/slides/slides-92-netconf-13.pdf.
*         The chair suggested that both, draft-liu and draft-mm, should rai=
se discussion on the maillist and get the support of the WG members.

Cheers,
Mehmet



--_000_E4DE949E6CE3E34993A2FF8AE79131F819670CD1DEMUMBX005nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













=
Dear NETCONF WG,


=
 


=
this email is to verify the opinion poll in IETF
 92 NETCONF session concerning the use of YANG 1.1 Features in NETCONF Draf=
ts.


=
 


=
As reported in the session summary below, the
 opinion poll for the use of YANG 1.1 features has been supported by 16 and=
 disagreed by 1 person.


=
The disagreement was based on the assumption
 that the finalization of the YANG 1.1 draft may possibly take longer than =
currently expected.


=
 


=
Please speak up by April 1, 2015 23:59 PT, if
 you have objections to use YANG 1.1 features in current NETCONF drafts.


=
The co-chairs will declare consensus after the
 deadline. 


=
 




=
Regards,


Mehmet 




=
 






From:
 Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of
ext Ersue, Mehmet (Nokia - DE/Munich)

Sent: Thursday, March 26, 20=
15 12:01 AM

To: Benoit Claise; netconf@i=
etf.org

Subject: [Netconf] Summary a=
nd AIs from the NETCONF Session in IETF #92






 




Hi Benoit, NETCONF WG,<=
/o:p>






 






below is a summary and actio=
n items from the NETCONF WG session on March 24, 2014, Dallas, USA.







A Wiki version of this summa=
ry will be made available at OPS area Wiki page soon (at
htt=
p://trac.tools.ietf.org/area/ops/trac/wiki/IETF92summary).






 






- We had approx. 90+ par=
ticipants in the 2 hour NETCONF session,







- We had a discussion on 7 c=
hartered documents.






 






- Note taker was: Lada Lhotk=
a. The Jabber scribe was Mikael Abrahamsson.






Many thanks to the note take=
rs and jabber scribe for volunteering.






 







 






Following is a summary of th=
e discussion and the decisions taken per show-hands.






If there is no strong object=
ion we will implement as proposed.






 





·Issues=
 after the WGLC of the RESTCONF and YANG Patch drafts have been discussed.
 See 
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-0.pdf and =

https://www.ietf.org/proceedings/92/slides/slides-92-netconf-1.pdf. 



·Curren=
tly open issues for the YANG Library and RESTCONF Collection Resource
 drafts have been discussed. See 
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-10.pdf and=
 
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-11.pdf. 



·A few =
issues are remaining and will be taken to the maillist. If there is
 no objection, the solution described on an issue slide will be realized as=
 proposed. WG members are asked to speak up on the maillist if there is any=
 concern on the proposed solution.



·RESTCO=
NF, YANG Patch and YANG Library drafts will go to 2nd WGLC a few weeks
 after IETF 92 once the drafts are available after issue solving.



·WG co-=
chairs are asking the chairs of related WGs (e.g. Core, 6lo, 6tisch)
 to assign individuals as reviewer. 




=
 





·Issues=
 after the WGLC of the Call Home and Server Model drafts have been discusse=
d.
 See 
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-4.pptx and=
 
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-5.pptx. 



·If the=
re is no objection, the solution described on an issue slide will be
 realized as proposed. WG members are asked to speak up on the maillist if =
there is any concern on the proposed solution.



·Call H=
ome and Server Model drafts will go to 2nd WGLC once the drafts are
 available after issue solving and after finalizing the WGLC for the RESTCO=
NF drafts.




 





·During=
 the discussion of the Server Model draft, the use of the YANG 1.1 features
 in current NETCONF drafts has been proposed. The opinion poll showed 16 ye=
s, 1 no from Andy B.



·AI: Co=
-chairs will send an email to the NETCONF maillist to verify the poll
 in the meeting.



·The op=
en issues in Zerotouch draft have been discussed briefly. See
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-7.pptx. Kent W. is discussing the details of the requirements on Zerotouch draft=
 with ANIMA WG members. ANIMA WG is
 asked to agree on these requirements first in their WG before starting a d=
iscussion in the NETCONF WG based on a new draft or subsection in an existi=
ng draft.





 





·I2RS c=
o-chair Jeff Haas summarized the NETCONF-related issues discussed in
 I”RS WG, which are Pub-sub requirements, Ephemeral state, Secondary =
Identity, Priority, Transactions. See
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-8.pptx.



·Epheme=
ral state is a particular issue important for I2RS WG. The volunteers
 for this issue (Dan B, Martin, Ken and Andy) will restart their work.=




·draft-=
haas-i2rs-netmod-netconf-requirements is serving as a tracking document
 for I2RS protocol requirements. Current requirements on ephemeral state ar=
e written down in the architecture draft.



·Mehmet=
 proposed a joint conf call to discuss the details of these issue in
 a joint conference call. AI: Mehmet to provide a doodle.=





 





·Eric V=
oit presented on draft-ietf-i2rs-pub-sub-requirements-01. See
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-9.pdf.




·The re=
lated solution draft addressing these requirements has been presented
 by Alex Clemm. See 
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-14.pdf. Th=
is draft is proposed to adopt in NETCONF WG. 12 have read the draft. 12 sup=
port the draft and 0 against.




·Mehmet=
 clarified that new WG items can be adopted after finalizing current
 active items. This will be possibly in IETF 93 time frame.




 





·draft-=
liu-netconf-multiple-replies-00 on Processing Multiple Replies for One
 Request in NETCONF has been presented by Guangying Zheng. See 
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-3.ppt. 5 p=
eople have read the draft. 5 support adopting the draft. Will take it to th=
e mailing list.



·draft-=
mm-netconf-time-capability-02 on Time Capability in NETCONF couldn’t
 be discussed due to lack of time. See 
https://www.ietf.org/proceedings/92/slides/slides-92-netconf-13.pdf.



·The ch=
air suggested that both, draft-liu and draft-mm, should raise discussion
 on the maillist and get the support of the WG members.




=
 





=
Cheers,


Mehmet 






 






 








--_000_E4DE949E6CE3E34993A2FF8AE79131F819670CD1DEMUMBX005nsnin_--


From nobody Thu Mar 26 05:48:48 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11AD1B2CE1 for ; Thu, 26 Mar 2015 05:48:46 -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 2EN_c-ztuChD for ; Thu, 26 Mar 2015 05:48:44 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8B91ACE5A for ; Thu, 26 Mar 2015 05:48:44 -0700 (PDT)
Received: from pc6 (81.151.162.168) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 26 Mar 2015 12:48:23 +0000
Message-ID: <027301d067c3$09aa8c40$4001a8c0@gateway.2wire.net>
From: t.petch 
To: 
Date: Thu, 26 Mar 2015 12:47:32 +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: [81.151.162.168]
X-ClientProxiedBy: DB4PR02CA0048.eurprd02.prod.outlook.com (10.242.174.176) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(377454003)(229853001)(107886001)(2351001)(110136001)(87976001)(1556002)(42186005)(61296003)(116806002)(44716002)(450100001)(77156002)(81686999)(81816999)(50986999)(62966003)(77096005)(66066001)(50466002)(14496001)(23756003)(19580395003)(19580405001)(86362001)(50226001)(44736004)(84392001)(47776003)(62236002)(33646002)(122386002)(92566002)(46102003)(40100003)(1456003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMXPR07MB054; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB054; 
X-Forefront-PRVS: 0527DFA348
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2015 12:48:23.1873 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054
Archived-At: 
Subject: [Netconf] The use of YANG 1.1 Features in NETCONF Drafts WAS: Summary and AIs from the NETCONF Session in IETF #92
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, 26 Mar 2015 12:48:47 -0000

> ---- Original Message -----
> From: "Ersue, Mehmet (Nokia - DE/Munich)" 
> To: 
> Sent: Wednesday, March 25, 2015 11:50 PM
>
> Dear NETCONF WG,
>
> this email is to verify the opinion poll in IETF 92 NETCONF session
> concerning the use of YANG 1.1 Features in NETCONF Drafts.
>
> As reported in the session summary below, the opinion poll for the use
> of YANG 1.1 features has been supported by 16 and disagreed by 1
person.
> The disagreement was based on the assumption that the finalization of
> the YANG 1.1 draft may possibly take longer than currently expected.
>
> Please speak up by April 1, 2015 23:59 PT, if you have objections to
use
> YANG 1.1 features in current NETCONF drafts.
> The co-chairs will declare consensus after the deadline.

 A clarification.

 I assume that this would make YANG 1.1 a Normative Reference for e.g.
 netconf-server so that that I-D and others could not become RFC until
 YANG 1.1 does, which is some months or more away.

 Tom Petch

> Regards,
> Mehmet
>
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext
Ersue,
> Mehmet (Nokia - DE/Munich)
> Sent: Thursday, March 26, 2015 12:01 AM
> To: Benoit Claise; netconf@ietf.org
> Subject: [Netconf] Summary and AIs from the NETCONF Session in IETF
#92
>
>


From nobody Thu Mar 26 06:16:15 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7121B2D1B for ; Thu, 26 Mar 2015 06:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 Eij-AjiqdM8t for ; Thu, 26 Mar 2015 06:16:11 -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 841A51B2CEE for ; Thu, 26 Mar 2015 06:16:11 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0BA291046; Thu, 26 Mar 2015 14:16:10 +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 6V1xP_Dzsphs; Thu, 26 Mar 2015 14:15:49 +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; Thu, 26 Mar 2015 14:16:09 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01C122002C; Thu, 26 Mar 2015 14:16:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UPVFggu68RhO; Thu, 26 Mar 2015 14:16:08 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47A5720013; Thu, 26 Mar 2015 14:16:07 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 22FE4328313F; Thu, 26 Mar 2015 14:16:05 +0100 (CET)
Date: Thu, 26 Mar 2015 14:16:05 +0100
From: Juergen Schoenwaelder 
To: "t. petch" 
Message-ID: <20150326131605.GA69061@elstar.local>
Mail-Followup-To: "t. petch" , netconf@ietf.org
References: <027301d067c3$09aa8c40$4001a8c0@gateway.2wire.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <027301d067c3$09aa8c40$4001a8c0@gateway.2wire.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] The use of YANG 1.1 Features in NETCONF Drafts WAS: Summary and AIs from the NETCONF Session in IETF #92
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 13:16:14 -0000

On Thu, Mar 26, 2015 at 12:47:32PM +0000, t. petch wrote:
> > ---- Original Message -----
> > From: "Ersue, Mehmet (Nokia - DE/Munich)" 
> > To: 
> > Sent: Wednesday, March 25, 2015 11:50 PM
> >
> > Dear NETCONF WG,
> >
> > this email is to verify the opinion poll in IETF 92 NETCONF session
> > concerning the use of YANG 1.1 Features in NETCONF Drafts.
> >
> > As reported in the session summary below, the opinion poll for the use
> > of YANG 1.1 features has been supported by 16 and disagreed by 1
> person.
> > The disagreement was based on the assumption that the finalization of
> > the YANG 1.1 draft may possibly take longer than currently expected.
> >
> > Please speak up by April 1, 2015 23:59 PT, if you have objections to
> use
> > YANG 1.1 features in current NETCONF drafts.
> > The co-chairs will declare consensus after the deadline.
> 
>  A clarification.
> 
>  I assume that this would make YANG 1.1 a Normative Reference for e.g.
>  netconf-server so that that I-D and others could not become RFC until
>  YANG 1.1 does, which is some months or more away.
>

The current plan is to have a complete version of the YANG 1.1
specification in April and then we will go into WG last call mode.  If
things go really well, the extra YANG 1.1 delay will be mostly zero.

Note that netconf-server depends on RESTCONF (which currently also
depends on JSON). Given the discussions around RESTCONF this week, it
might take roughly the same amount of time to finish up RESTCONF as it
might take to finish up NETCONF.

Since mostly the same group of people are actively involved in these
documents, I think we should be able to coordinate and deliver a set
of documents.

/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 Thu Mar 26 18:07:07 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44B01A887B for ; Thu, 26 Mar 2015 18:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 NNoI-8dMhfju for ; Thu, 26 Mar 2015 18:07:04 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70731A0163 for ; Thu, 26 Mar 2015 18:07:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7FBC114D6 for ; Fri, 27 Mar 2015 02:07:02 +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 kGbuRa0IJg-O for ; Fri, 27 Mar 2015 02:06:39 +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 for ; Fri, 27 Mar 2015 02:07:02 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0066220031 for ; Fri, 27 Mar 2015 02:07:02 +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 y5Cq64sb3T9A; Fri, 27 Mar 2015 02:07:01 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E2772002B; Fri, 27 Mar 2015 02:07:01 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 33F713283A52; Fri, 27 Mar 2015 02:07:00 +0100 (CET)
Date: Fri, 27 Mar 2015 02:06:59 +0100
From: Juergen Schoenwaelder 
To: netconf@ietf.org
Message-ID: <20150327010659.GA70967@elstar.local>
Mail-Followup-To: netconf@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [Netconf] restconf selecting encoding for notifications
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, 27 Mar 2015 01:07:06 -0000

Hi,

how do I select in RESTCONF in which encoding I like to receive
notifications?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Mar 26 19:10:13 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E761A8A46 for ; Thu, 26 Mar 2015 19:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 4nwoQPWmZuCK for ; Thu, 26 Mar 2015 19:10:10 -0700 (PDT)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3E21A8A3F for ; Thu, 26 Mar 2015 19:10:09 -0700 (PDT)
Received: by lbbzt2 with SMTP id zt2so1703359lbb.1 for ; Thu, 26 Mar 2015 19:10:08 -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=u3Kh2S+jahUOENzjs2bwUHjqKPBoJ0wJKdJgSGfMd/s=; b=TrQNeCch9dMK8IswMUiWiIy2EpGGk12uM5DGeMeYo4+JhoqtcbJ9CW3w2ckvxWbrwq owJfZRRIYesoUM8YD3StZJ6TaTbBESa3xUS9qEkrWulLCOA2b0YpbTwjc33JEs2zv5vq N8w3yo5KeBoueMmHBM5JNiy8w+usdC/aJnrSp4A5hXPgicDK4EP57ZrvxTXiBXZxvhDo +ZBlqA02dyTWeoyuiJlx48rb3beUhnjxWjgNwdt22ngI3TzxdZjPhFTx//sOQ9aSxF+i H4gZ4NnynADKNi9P/M/BIE8HIzJ8J2auoATlfEtxzkJDXHbh29SqLtgrqLXIGO8UYeEd WhaA==
X-Gm-Message-State: ALoCoQn/CVMY8Ng3Fih7x5weuVH9wuC/a5hWGF/llGtfiO9/TVkK5S3dBuSHDTwIsWwEE7ahFuGb
MIME-Version: 1.0
X-Received: by 10.152.236.42 with SMTP id ur10mr15504444lac.37.1427422207993;  Thu, 26 Mar 2015 19:10:07 -0700 (PDT)
Received: by 10.112.144.36 with HTTP; Thu, 26 Mar 2015 19:10:07 -0700 (PDT)
In-Reply-To: <20150327010659.GA70967@elstar.local>
References: <20150327010659.GA70967@elstar.local>
Date: Thu, 26 Mar 2015 21:10:07 -0500
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Netconf 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [Netconf] restconf selecting encoding for notifications
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, 27 Mar 2015 02:10:11 -0000

On Thu, Mar 26, 2015 at 8:06 PM, Juergen Schoenwaelder
 wrote:
> Hi,
>
> how do I select in RESTCONF in which encoding I like to receive
> notifications?
>

You pick the URI that corresponds to the stream encoding you
want.  There is no requirement that the server support any
particular streams or encoding formats:

   
         
            NETCONF
            default NETCONF event stream
            
            true
            
               2007-07-08T00:00:00Z
            
            
               xml
               https://example.com/streams/NETCONF
            
            
               json
               https://example.com/streams/NETCONF-JSON
            
         
         ....


Note that there is a bug in sec. 6.3 that shows the "encoding=foo"
query parameter (which has been removed).

-----
 The client might send the following request:

      GET /restconf/data/ietf-restconf-monitoring:restconf-state/
         streams/stream=NETCONF/encoding=xml/events HTTP/1.1
      Host: example.com
      Accept: application/yang.data+xml

   The server might send the following response:

      HTTP/1.1 200 OK
      Content-Type: application/yang.api+xml

      
        https://example.com/streams/NETCONF
      
-----






> /js
>

Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Thu Mar 26 20:10:22 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D951A90E8 for ; Thu, 26 Mar 2015 20:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 wm12hbSuSbWp for ; Thu, 26 Mar 2015 20:10:19 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8F91A90DD for ; Thu, 26 Mar 2015 20:10:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A28611337; Fri, 27 Mar 2015 04:10:17 +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 oCW78jRMc9xq; Fri, 27 Mar 2015 04:09:53 +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, 27 Mar 2015 04:10:17 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0823A2002B; Fri, 27 Mar 2015 04:10:17 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nqBVTZgh20xr; Fri, 27 Mar 2015 04:10:16 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11C8120013; Fri, 27 Mar 2015 04:10:16 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 5186C3283B26; Fri, 27 Mar 2015 04:10:15 +0100 (CET)
Date: Fri, 27 Mar 2015 04:10:14 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20150327031014.GA71355@elstar.local>
Mail-Followup-To: Andy Bierman , Netconf 
References: <20150327010659.GA70967@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: 
Cc: Netconf 
Subject: Re: [Netconf] restconf selecting encoding for notifications
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, 27 Mar 2015 03:10:20 -0000

On Thu, Mar 26, 2015 at 09:10:07PM -0500, Andy Bierman wrote:
> On Thu, Mar 26, 2015 at 8:06 PM, Juergen Schoenwaelder
>  wrote:
> > Hi,
> >
> > how do I select in RESTCONF in which encoding I like to receive
> > notifications?
> >
> 
> You pick the URI that corresponds to the stream encoding you
> want.

[...]

>  The client might send the following request:
> 
>       GET /restconf/data/ietf-restconf-monitoring:restconf-state/
>          streams/stream=NETCONF/encoding=xml/events HTTP/1.1
>       Host: example.com
>       Accept: application/yang.data+xml
>

So I would do this:

      GET /restconf/data/ietf-restconf-monitoring:restconf-state/
         streams/stream=NETCONF/encoding=json/events HTTP/1.1
      Host: example.com
      Accept: application/yang.data+xml

Makes sense now. Thanks,

/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 Mar 27 16:12:00 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEF71A0097 for ; Fri, 27 Mar 2015 16:11:58 -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 jswpv_j4bP_Y for ; Fri, 27 Mar 2015 16:11:56 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::791]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8261A00F7 for ; Fri, 27 Mar 2015 16:11:55 -0700 (PDT)
Received: from BLUPR05CA0055.namprd05.prod.outlook.com (10.141.20.25) by CO2PR05MB730.namprd05.prod.outlook.com (10.141.228.15) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 27 Mar 2015 23:11:37 +0000
Received: from BN1AFFO11FD015.protection.gbl (2a01:111:f400:7c10::121) by BLUPR05CA0055.outlook.office365.com (2a01:111:e400:855::25) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Fri, 27 Mar 2015 23:11:36 +0000
Received: from P-EMF03-SAC.jnpr.net ([66.129.239.17]) by BN1AFFO11FD015.mail.protection.outlook.com ([10.58.52.75]) with Microsoft SMTP Server (TLS) id 15.1.130.10 via Frontend Transport; Fri, 27 Mar 2015 23:11:36 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 27 Mar 2015 16:11:33 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t2RNBWD38757;	Fri, 27 Mar 2015 16:11:32 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t2RNAZJV070344; Fri, 27 Mar 2015 19:10:36 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201503272310.t2RNAZJV070344@idle.juniper.net>
To: Juergen Schoenwaelder 
In-Reply-To: <20150327031014.GA71355@elstar.local>
Date: Fri, 27 Mar 2015 19:10:35 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender)
Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(199003)(189002)(51704005)(50986999)(53416004)(77156002)(92566002)(62966003)(47776003)(54356999)(48376002)(46102003)(50466002)(19580405001)(19580395003)(86362001)(87936001)(77096005)(106466001)(2950100001)(105596002)(110136001)(76506005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB730; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB730;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO2PR05MB730; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB730; 
X-Forefront-PRVS: 0528942FD8
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2015 23:11:36.4749 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17];  Helo=[P-EMF03-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB730
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] restconf selecting encoding for notifications
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, 27 Mar 2015 23:11:58 -0000

Juergen Schoenwaelder writes:
>On Thu, Mar 26, 2015 at 09:10:07PM -0500, Andy Bierman wrote:
>> On Thu, Mar 26, 2015 at 8:06 PM, Juergen Schoenwaelder
>>  wrote:
>> > Hi,
>> >
>> > how do I select in RESTCONF in which encoding I like to receive
>> > notifications?
>> >
>> 
>> You pick the URI that corresponds to the stream encoding you
>> want.
>
>[...]
>
>>  The client might send the following request:
>> 
>>       GET /restconf/data/ietf-restconf-monitoring:restconf-state/
>>          streams/stream=NETCONF/encoding=xml/events HTTP/1.1
>>       Host: example.com
>>       Accept: application/yang.data+xml
>>
>
>So I would do this:
>
>      GET /restconf/data/ietf-restconf-monitoring:restconf-state/
>         streams/stream=NETCONF/encoding=json/events HTTP/1.1
>      Host: example.com
>      Accept: application/yang.data+xml
>
>Makes sense now. Thanks,

Is the "json" in the GET line a typo?  Can you "accept" a
different format from the URL's encoding?  Seems strange to
have both and stranger when they disagree?

Thanks,
 Phil


From nobody Sat Mar 28 01:43:49 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788481A6F29 for ; Sat, 28 Mar 2015 01:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 vlcybHui8AxH for ; Sat, 28 Mar 2015 01:43:45 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020C91A00A7 for ; Sat, 28 Mar 2015 01:43:45 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7CBC01036; Sat, 28 Mar 2015 09:43:43 +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 F3-ymxcfWCNR; Sat, 28 Mar 2015 09:43:12 +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; Sat, 28 Mar 2015 09:43:42 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2C0C2002B; Sat, 28 Mar 2015 09:43:42 +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 ekxFJ9LGH4_b; Sat, 28 Mar 2015 09:43:41 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E4B020013; Sat, 28 Mar 2015 09:43:41 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 9155B32988C9; Sat, 28 Mar 2015 09:43:39 +0100 (CET)
Date: Sat, 28 Mar 2015 09:43:38 +0100
From: Juergen Schoenwaelder 
To: Phil Shafer 
Message-ID: <20150328084338.GA61327@elstar.local>
Mail-Followup-To: Phil Shafer , Andy Bierman , Netconf 
References: <20150327031014.GA71355@elstar.local> <201503272310.t2RNAZJV070344@idle.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201503272310.t2RNAZJV070344@idle.juniper.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] restconf selecting encoding for notifications
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Mar 2015 08:43:47 -0000

On Fri, Mar 27, 2015 at 07:10:35PM -0400, Phil Shafer wrote:
> Juergen Schoenwaelder writes:
> >On Thu, Mar 26, 2015 at 09:10:07PM -0500, Andy Bierman wrote:
> >> On Thu, Mar 26, 2015 at 8:06 PM, Juergen Schoenwaelder
> >>  wrote:
> >> > Hi,
> >> >
> >> > how do I select in RESTCONF in which encoding I like to receive
> >> > notifications?
> >> >
> >> 
> >> You pick the URI that corresponds to the stream encoding you
> >> want.
> >
> >[...]
> >
> >>  The client might send the following request:
> >> 
> >>       GET /restconf/data/ietf-restconf-monitoring:restconf-state/
> >>          streams/stream=NETCONF/encoding=xml/events HTTP/1.1
> >>       Host: example.com
> >>       Accept: application/yang.data+xml
> >>
> >
> >So I would do this:
> >
> >      GET /restconf/data/ietf-restconf-monitoring:restconf-state/
> >         streams/stream=NETCONF/encoding=json/events HTTP/1.1
> >      Host: example.com
> >      Accept: application/yang.data+xml
> >
> >Makes sense now. Thanks,
> 
> Is the "json" in the GET line a typo?  Can you "accept" a
> different format from the URL's encoding?  Seems strange to
> have both and stranger when they disagree?
>

This request returns the stream. A subsequent GET request on the
returned stream yields the event notifications. This subsequent
request must be Accept: text/event-stream according to W3C and hence
you can't pass an encoding indicator in this request. Yep, a bit ugly,
but looks like W3C is to blame here.

/js

PS: http://www.w3.org/TR/eventsource/

-- 
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 Mar 29 09:49:50 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E761A1A65 for ; Sun, 29 Mar 2015 09:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 hqbRR6GnodjO for ; Sun, 29 Mar 2015 09:49:47 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4BD1A1B1E for ; Sun, 29 Mar 2015 09:49:46 -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.1.125.19; Sun, 29 Mar 2015 16:49:30 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 16:49:30 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #39: move away from a number with a fixed unit?
Thread-Index: AQHQakBTwhOo1Z+47kaN9en13xmjZQ==
Date: Sun, 29 Mar 2015 16:49:29 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(102836002)(87936001)(450100001)(16236675004)(77156002)(62966003)(83506001)(2656002)(15975445007)(110136001)(19580395003)(50986999)(54356999)(36756003)(2351001)(2501003)(99286002)(86362001)(40100003)(2900100001)(106116001)(107886001)(92566002)(122556002)(66066001)(46102003)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 0530FCB552
Content-Type: multipart/alternative; boundary="_000_D13D97479C251kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 16:49:29.7911 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: [Netconf] server-model #39: move away from a number with a fixed unit?
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, 29 Mar 2015 16:49:49 -0000

--_000_D13D97479C251kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This issue was discussed during the Dallas meeting with an agreement to lea=
ve as seconds (not use xsd's duration). The issue is hence moved to the VER=
IFY state.  The issue will move to the EDIT state If no objection is raised=
 by April 6th.

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

Thanks,
Kent


--_000_D13D97479C251kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <79B57D031065DA418586015D17ECD260@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














This issue was discussed during the =
Dallas meeting with an agreement to leave as seconds (not use xsd's duratio=
n). The issue=
 is hence moved to the VERIFY state.  The
 issue will move to the EDIT state If no objection is raised by April 6th.<=
/span>







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







Thanks,


Kent












--_000_D13D97479C251kwatsenjunipernet_--


From nobody Sun Mar 29 09:54:33 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DABC1A1B3E for ; Sun, 29 Mar 2015 09:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmAP3b9YZ-tH for ; Sun, 29 Mar 2015 09:54:30 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324401A0070 for ; Sun, 29 Mar 2015 09:54:30 -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.1.125.19; Sun, 29 Mar 2015 16:54:27 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 16:54:27 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #40: move "max-sessions" to global session-param?
Thread-Index: AQHQakEEonOI9XVYPEiBtltJ0PPLkA==
Date: Sun, 29 Mar 2015 16:54:26 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(77156002)(92566002)(2656002)(2501003)(99286002)(87936001)(83506001)(450100001)(62966003)(122556002)(2351001)(107886001)(86362001)(229853001)(46102003)(50986999)(102836002)(106116001)(16236675004)(40100003)(66066001)(110136001)(2900100001)(36756003)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0530FCB552
Content-Type: multipart/alternative; boundary="_000_D13D98709C25Bkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 16:54:26.9339 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: [Netconf] server-model #40: move "max-sessions" to global session-param?
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, 29 Mar 2015 16:54:31 -0000

--_000_D13D98709C25Bkwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This issue was discussed during and after the Dallas meeting with an agreem=
ent to leave the "max-sessions" under the
"listen" container.  This because only call-home connections are not variab=
le in number.  The issue is hence moved to the VERIFY state.  The issue wil=
l move to the EDIT state if no objection is raised by April 6th.

Thanks,
Kent


--_000_D13D98709C25Bkwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <840A32961D405048A182E727885345FF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














This issue was discussed during and after the Dallas meeting with an a=
greement to leave the "max-sessions" under the 


"listen" container.  This because only call-home connec=
tions are not variable in number.  The issue is hence moved to the VER=
IFY state.  The issue will move to the EDIT state if no objection is r=
aised by April 6th.









Thanks,


Kent









--_000_D13D98709C25Bkwatsenjunipernet_--


From nobody Sun Mar 29 10:00:11 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F861A1B7D for ; Sun, 29 Mar 2015 10:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n94EUSvk4AxX for ; Sun, 29 Mar 2015 10:00:08 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081E91A1B71 for ; Sun, 29 Mar 2015 10:00: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.1.125.19; Sun, 29 Mar 2015 17:00:05 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 17:00:05 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #41: should address be mandatory?
Thread-Index: AQHQakHNrU+UOSkJF0iEubfncC2Zng==
Date: Sun, 29 Mar 2015 17:00:04 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(66066001)(2900100001)(92566002)(450100001)(15975445007)(102836002)(50986999)(54356999)(99286002)(122556002)(19580395003)(2501003)(62966003)(77156002)(83506001)(229853001)(2351001)(110136001)(107886001)(46102003)(40100003)(36756003)(106116001)(2656002)(86362001)(87936001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0530FCB552
Content-Type: multipart/alternative; boundary="_000_D13D99C29C264kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 17:00:04.5325 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: [Netconf] server-model #41: should address be mandatory?
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, 29 Mar 2015 17:00:09 -0000

--_000_D13D99C29C264kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This issue was discussed during the Dallas meeting with an agreement to man=
datory false and add to the description that a missing address is to be int=
erpreted as a wildcard meaning "all interfaces".

The issue is hence moved to the VERIFY state.  The issue will move to the E=
DIT state If no objection is raised by April 6th.

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

Thanks,
Kent

--_000_D13D99C29C264kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable















This issue was discussed during the =
Dallas meeting with an agreement to mandatory false and add to the des=
cription that a missing address is to be interpreted as a wildcard meaning =
"all interfaces".







The issue is hence moved to the VERI=
FY state.  The issue will move to the EDIT state If no objection is ra=
ised by April 6th.







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











Thanks,



Kent




--_000_D13D99C29C264kwatsenjunipernet_--


From nobody Sun Mar 29 10:03:56 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D706A1A1B87 for ; Sun, 29 Mar 2015 10:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ptbaUxPrrEB for ; Sun, 29 Mar 2015 10:03:54 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A80F1A1B7D for ; Sun, 29 Mar 2015 10:03:54 -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.1.125.19; Sun, 29 Mar 2015 17:03:52 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 17:03:52 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] server-model #41: should address be mandatory?
Thread-Index: AQHQakJUKcuIKIgxBkKS8aaqkUGW7w==
Date: Sun, 29 Mar 2015 17:03:51 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(164054003)(377454003)(50986999)(106116001)(102836002)(86362001)(107886001)(122556002)(2351001)(46102003)(36756003)(19617315012)(54356999)(16236675004)(110136001)(66066001)(2900100001)(40100003)(99286002)(2501003)(2656002)(77156002)(92566002)(450100001)(62966003)(15975445007)(87936001)(19580395003)(19580405001)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0530FCB552
Content-Type: multipart/alternative; boundary="_000_D13D9A6A9C26Akwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 17:03:51.0855 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: Re: [Netconf] server-model #41: should address be mandatory?
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, 29 Mar 2015 17:03:56 -0000

--_000_D13D9A6A9C26Akwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

s/to mandatory false/to leave as mandatory false/

K.

From: Kent Watsen >
Date: Sunday, March 29, 2015 at 12:00 PM
To: "netconf@ietf.org" >
Subject: [Netconf] server-model #41: should address be mandatory?


This issue was discussed during the Dallas meeting with an agreement to man=
datory false and add to the description that a missing address is to be int=
erpreted as a wildcard meaning "all interfaces".

The issue is hence moved to the VERIFY state.  The issue will move to the E=
DIT state If no objection is raised by April 6th.

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

Thanks,
Kent

--_000_D13D9A6A9C26Akwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <9AEC49E0A10E8247A136F64BA15E80A0@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







s/to mandatory false/to leave as mandatory false/







K.









From: Kent Watsen <kwatsen@juniper.net>

Date: Sunday, March 29, 2015 at 12:=
00 PM

To: "netconf@ietf.org" <netconf@ietf.org>

Subject: [Netconf] server-model #41=
: should address be mandatory?





















This issue was discussed during the =
Dallas meeting with an agreement to mandatory false and add to the des=
cription that a missing address is to be interpreted as a wildcard meaning =
"all interfaces".







The issue is hence moved to the VERI=
FY state.  The issue will move to the EDIT state If no objection is ra=
ised by April 6th.

















Thanks,



Kent









--_000_D13D9A6A9C26Akwatsenjunipernet_--


From nobody Sun Mar 29 10:39:50 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A0C1A1B1C for ; Sun, 29 Mar 2015 10:39:48 -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 Vgi_kVxeHVDx for ; Sun, 29 Mar 2015 10:39:47 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2471A1B5F for ; Sun, 29 Mar 2015 10:39:30 -0700 (PDT)
Received: from BLUPR05CA0079.namprd05.prod.outlook.com (10.141.20.49) by BLUPR05MB135.namprd05.prod.outlook.com (10.255.190.146) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sun, 29 Mar 2015 17:39:29 +0000
Received: from BN1AFFO11OLC003.protection.gbl (2a01:111:f400:7c10::139) by BLUPR05CA0079.outlook.office365.com (2a01:111:e400:855::49) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Sun, 29 Mar 2015 17:39:29 +0000
Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1AFFO11OLC003.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (TLS) id 15.1.130.10 via Frontend Transport; Sun, 29 Mar 2015 17:39:28 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 29 Mar 2015 10:39:27 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t2THdPD08177;	Sun, 29 Mar 2015 10:39:26 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t2THcTBL078564; Sun, 29 Mar 2015 13:38:29 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201503291738.t2THcTBL078564@idle.juniper.net>
To: Kent Watsen 
In-Reply-To: 
Date: Sun, 29 Mar 2015 13:38:29 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender)
Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(86362001)(105596002)(106466001)(53416004)(76506005)(50986999)(87936001)(47776003)(6806004)(46102003)(77156002)(2950100001)(48376002)(50466002)(110136001)(62966003)(54356999)(450100001)(92566002)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB135; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB135;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR05MB135; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB135; 
X-Forefront-PRVS: 0530FCB552
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2015 17:39:28.9429 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17];  Helo=[P-EMF03-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB135
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] server-model #40: move "max-sessions" to global session-param?
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, 29 Mar 2015 17:39:48 -0000

Kent Watsen writes:
>This issue was discussed during and after the Dallas meeting with an agreem=
>ent to leave the "max-sessions" under the
>"listen" container.  This because only call-home connections are not variab=
>le in number.  The issue is hence moved to the VERIFY state.  The issue wil=
>l move to the EDIT state if no objection is raised by April 6th.

It's not clear what the "EDIT" is if the decision is to not
change it.  Are you changing the description to be more clear?

Thanks,
 Phil


From nobody Sun Mar 29 13:00:40 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F591A8862 for ; Sun, 29 Mar 2015 13:00:39 -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 p_TEMSp1aHIS for ; Sun, 29 Mar 2015 13:00:37 -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.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238411A885C for ; Sun, 29 Mar 2015 13:00:37 -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.125.19; Sun, 29 Mar 2015 20:00:16 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 20:00:16 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #43: keep-alive, linger, reconnect interval defaults OK?
Thread-Index: AQHQalr5OEpeLICj8UOqu96zVYFF7Q==
Date: Sun, 29 Mar 2015 20:00:15 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(92566002)(450100001)(2900100001)(102836002)(15975445007)(50986999)(54356999)(66066001)(122556002)(99286002)(19580395003)(2501003)(62966003)(77156002)(229853001)(2351001)(110136001)(107886001)(46102003)(40100003)(2656002)(106116001)(87936001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0530FCB552
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <1A0068D2CE76454690B116C2C9966027@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 20:00:15.5332 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK?
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, 29 Mar 2015 20:00:39 -0000

This issue was discussed during and after the Dallas meeting with the
following status:=20

[1]  =8A/connection-type/persistent/keep-alives/interval-secs:
This issue is still open - please reply on it if so inclined.  Some felt
that a keep-alive every 15 seconds was too often, and suggested that a
2=ADhour value would be better.   Searching on this for awhile, it seems
that many use 300 seconds and many others use 15 seconds,  Note, this is a
keep-alive message being sent every 15 to 300 seconds, with a default
count-max of '3', results in a new connection after 45 to 900 seconds -
that's 3/4 of a minute to 15 minutes to proactively bring up a failed
session.  Some of the issue surrounds how the TCP-level  timeout is set.
The introduction in RFC5482 says:

   In the absence of an application-specified user timeout, the TCP
   specification [RFC0793] defines a default user timeout of 5 minutes.
   The Host Requirements RFC [RFC1122] refines this definition by
   introducing two thresholds, R1 and R2 (R2 > R1), that control the
   number of retransmission attempts for a single segment.  It suggests
   that TCP should notify applications when R1 is reached for a segment,
   and close the connection when R2 is reached.  [RFC1122] also defines
   the recommended values for R1 (3 retransmissions) and R2 (100
   seconds), noting that R2 for SYN segments should be at least 3
   minutes.  Instead of a single user timeout, some TCP implementations
   offer finer-grained policies.  For example, Solaris supports
   different timeouts depending on whether a TCP connection is in the
   SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS].

I wonder if we should *add* configuration know for a tcp timeout as well?


[2] =8A/connection-type/periodic/linger-secs:
This leaf is to be removed as it is best to let the NETCONF/RESTCONF
client decide when to close the session =AD the server should leave the
session open, up until the /session-options/idle-timeout limit.


[3] =8A/reconnect-strategy/interval-secs:
This leaf is to be removed.  It doesn't have enough value to leave exposed
as a configurable know.


Due to [1] being still open, this issue only moves to the OPEN state - not
the VERIFY state.

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

Thanks,
Kent




From nobody Sun Mar 29 13:08:09 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49E61A03A2 for ; Sun, 29 Mar 2015 13:07:59 -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 W3AwMrwBYOz5 for ; Sun, 29 Mar 2015 13:07:58 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F340C1A8889 for ; Sun, 29 Mar 2015 13:07:57 -0700 (PDT)
Received: from CO1PR05MB363.namprd05.prod.outlook.com (10.141.51.145) by CO1PR05MB395.namprd05.prod.outlook.com (10.141.75.20) with Microsoft SMTP Server (TLS) id 15.1.125.19; Sun, 29 Mar 2015 20:07:41 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB363.namprd05.prod.outlook.com (10.141.51.145) with Microsoft SMTP Server (TLS) id 15.1.125.19; Sun, 29 Mar 2015 20:07:39 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 20:07:39 +0000
From: Kent Watsen 
To: Phil Shafer 
Thread-Topic: [Netconf] server-model #40: move "max-sessions" to global session-param?
Thread-Index: AQHQakEEonOI9XVYPEiBtltJ0PPLkJ0zudOA///V2AA=
Date: Sun, 29 Mar 2015 20:07:38 +0000
Message-ID: 
References:  <201503291738.t2THcTBL078564@idle.juniper.net>
In-Reply-To: <201503291738.t2THcTBL078564@idle.juniper.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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.17]
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB363; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB395; 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(479174004)(164054003)(24454002)(51704005)(377454003)(102836002)(40100003)(62966003)(450100001)(77156002)(122556002)(36756003)(46102003)(106116001)(110136001)(54356999)(76176999)(2656002)(2950100001)(2900100001)(50986999)(92566002)(19580395003)(19580405001)(87936001)(99286002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB363; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB363; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB363; 
x-forefront-prvs: 0530FCB552
Content-Type: text/plain; charset="us-ascii"
Content-ID: <280131B192DFBD4EA892B2ED373A6BD2@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 20:07:38.9428 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB363
X-OriginatorOrg: juniper.net
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] server-model #40: move "max-sessions" to global session-param?
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, 29 Mar 2015 20:08:00 -0000

Perhaps it just goes to DEAD, with no change in text.  Do you think the
description is currently unclear?  Should the description call out that
max-sessions has no impact on the number of call-home sessions that can be
configured?

Kent


On 3/29/15, 12:38 PM, "Phil Shafer"  wrote:

>Kent Watsen writes:
>>This issue was discussed during and after the Dallas meeting with an
>>agreem=3D
>>ent to leave the "max-sessions" under the
>>"listen" container.  This because only call-home connections are not
>>variab=3D
>>le in number.  The issue is hence moved to the VERIFY state.  The issue
>>wil=3D
>>l move to the EDIT state if no objection is raised by April 6th.
>
>It's not clear what the "EDIT" is if the decision is to not
>change it.  Are you changing the description to be more clear?
>
>Thanks,
> Phil


From nobody Sun Mar 29 13:25:35 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360291A88D6 for ; Sun, 29 Mar 2015 13:25:33 -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 RgIlCtZ5ekxb for ; Sun, 29 Mar 2015 13:25:31 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0171A88D5 for ; Sun, 29 Mar 2015 13:25: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.1.125.19; Sun, 29 Mar 2015 20:25:28 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 20:25:27 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK?
Thread-Index: AQHQalr5OEpeLICj8UOqu96zVYFF7Z0zlHEA
Date: Sun, 29 Mar 2015 20:25:27 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(164054003)(51704005)(377454003)(36756003)(102836002)(92566002)(2501003)(46102003)(2950100001)(15975445007)(450100001)(77156002)(110136001)(62966003)(122556002)(99286002)(2351001)(2900100001)(40100003)(107886001)(66066001)(19580405001)(106116001)(19580395003)(50986999)(76176999)(2656002)(54356999)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 0530FCB552
Content-Type: text/plain; charset="euc-kr"
Content-ID: <5826DC0750794B4E951C822E1F2D7F9F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 20:25:27.4729 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Subject: Re: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK?
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, 29 Mar 2015 20:25:33 -0000

DQpSZWxhdGVkIHRvIFsxXSBpcyB0aGUgZXhwZW5zZSBvZiBoYXZpbmcgdG8gc2V0dXAgYSBuZXcg
Y3J5cHRvIHNlc3Npb24gYXMNCndlbGwgYXMgcmVlc3RhYmxpc2ggYW55IGxvbmctcG9sbCBSUENz
IGxpa2UgbmV0Y29uZi9yZXN0Y29uZg0Kbm90aWZpY2F0aW9ucy4uLg0KDQpUaGFua3MsDQpLZW50
DQoNCg0KDQpPbiAzLzI5LzE1LCAzOjAwIFBNLCAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlw
ZXIubmV0PiB3cm90ZToNCg0KPg0KPlRoaXMgaXNzdWUgd2FzIGRpc2N1c3NlZCBkdXJpbmcgYW5k
IGFmdGVyIHRoZSBEYWxsYXMgbWVldGluZyB3aXRoIHRoZQ0KPmZvbGxvd2luZyBzdGF0dXM6IA0K
Pg0KPlsxXSAuLi4vY29ubmVjdGlvbi10eXBlL3BlcnNpc3RlbnQva2VlcC1hbGl2ZXMvaW50ZXJ2
YWwtc2VjczoNCj5UaGlzIGlzc3VlIGlzIHN0aWxsIG9wZW4gLSBwbGVhc2UgcmVwbHkgb24gaXQg
aWYgc28gaW5jbGluZWQuICBTb21lIGZlbHQNCj50aGF0IGEga2VlcC1hbGl2ZSBldmVyeSAxNSBz
ZWNvbmRzIHdhcyB0b28gb2Z0ZW4sIGFuZCBzdWdnZXN0ZWQgdGhhdCBhDQo+MqGpaG91ciB2YWx1
ZSB3b3VsZCBiZSBiZXR0ZXIuICAgU2VhcmNoaW5nIG9uIHRoaXMgZm9yIGF3aGlsZSwgaXQgc2Vl
bXMNCj50aGF0IG1hbnkgdXNlIDMwMCBzZWNvbmRzIGFuZCBtYW55IG90aGVycyB1c2UgMTUgc2Vj
b25kcywgIE5vdGUsIHRoaXMgaXMgYQ0KPmtlZXAtYWxpdmUgbWVzc2FnZSBiZWluZyBzZW50IGV2
ZXJ5IDE1IHRvIDMwMCBzZWNvbmRzLCB3aXRoIGEgZGVmYXVsdA0KPmNvdW50LW1heCBvZiAnMycs
IHJlc3VsdHMgaW4gYSBuZXcgY29ubmVjdGlvbiBhZnRlciA0NSB0byA5MDAgc2Vjb25kcyAtDQo+
dGhhdCdzIDMvNCBvZiBhIG1pbnV0ZSB0byAxNSBtaW51dGVzIHRvIHByb2FjdGl2ZWx5IGJyaW5n
IHVwIGEgZmFpbGVkDQo+c2Vzc2lvbi4gIFNvbWUgb2YgdGhlIGlzc3VlIHN1cnJvdW5kcyBob3cg
dGhlIFRDUC1sZXZlbCAgdGltZW91dCBpcyBzZXQuDQo+VGhlIGludHJvZHVjdGlvbiBpbiBSRkM1
NDgyIHNheXM6DQo+DQo+ICAgSW4gdGhlIGFic2VuY2Ugb2YgYW4gYXBwbGljYXRpb24tc3BlY2lm
aWVkIHVzZXIgdGltZW91dCwgdGhlIFRDUA0KPiAgIHNwZWNpZmljYXRpb24gW1JGQzA3OTNdIGRl
ZmluZXMgYSBkZWZhdWx0IHVzZXIgdGltZW91dCBvZiA1IG1pbnV0ZXMuDQo+ICAgVGhlIEhvc3Qg
UmVxdWlyZW1lbnRzIFJGQyBbUkZDMTEyMl0gcmVmaW5lcyB0aGlzIGRlZmluaXRpb24gYnkNCj4g
ICBpbnRyb2R1Y2luZyB0d28gdGhyZXNob2xkcywgUjEgYW5kIFIyIChSMiA+IFIxKSwgdGhhdCBj
b250cm9sIHRoZQ0KPiAgIG51bWJlciBvZiByZXRyYW5zbWlzc2lvbiBhdHRlbXB0cyBmb3IgYSBz
aW5nbGUgc2VnbWVudC4gIEl0IHN1Z2dlc3RzDQo+ICAgdGhhdCBUQ1Agc2hvdWxkIG5vdGlmeSBh
cHBsaWNhdGlvbnMgd2hlbiBSMSBpcyByZWFjaGVkIGZvciBhIHNlZ21lbnQsDQo+ICAgYW5kIGNs
b3NlIHRoZSBjb25uZWN0aW9uIHdoZW4gUjIgaXMgcmVhY2hlZC4gIFtSRkMxMTIyXSBhbHNvIGRl
ZmluZXMNCj4gICB0aGUgcmVjb21tZW5kZWQgdmFsdWVzIGZvciBSMSAoMyByZXRyYW5zbWlzc2lv
bnMpIGFuZCBSMiAoMTAwDQo+ICAgc2Vjb25kcyksIG5vdGluZyB0aGF0IFIyIGZvciBTWU4gc2Vn
bWVudHMgc2hvdWxkIGJlIGF0IGxlYXN0IDMNCj4gICBtaW51dGVzLiAgSW5zdGVhZCBvZiBhIHNp
bmdsZSB1c2VyIHRpbWVvdXQsIHNvbWUgVENQIGltcGxlbWVudGF0aW9ucw0KPiAgIG9mZmVyIGZp
bmVyLWdyYWluZWQgcG9saWNpZXMuICBGb3IgZXhhbXBsZSwgU29sYXJpcyBzdXBwb3J0cw0KPiAg
IGRpZmZlcmVudCB0aW1lb3V0cyBkZXBlbmRpbmcgb24gd2hldGhlciBhIFRDUCBjb25uZWN0aW9u
IGlzIGluIHRoZQ0KPiAgIFNZTi1TRU5ULCBTWU4tUkVDRUlWRUQsIG9yIEVTVEFCTElTSEVEIHN0
YXRlIFtTT0xBUklTXS4NCj4NCj5JIHdvbmRlciBpZiB3ZSBzaG91bGQgKmFkZCogY29uZmlndXJh
dGlvbiBrbm93IGZvciBhIHRjcCB0aW1lb3V0IGFzIHdlbGw/DQo+DQo+DQo+WzJdIC4uLi9jb25u
ZWN0aW9uLXR5cGUvcGVyaW9kaWMvbGluZ2VyLXNlY3M6DQo+VGhpcyBsZWFmIGlzIHRvIGJlIHJl
bW92ZWQgYXMgaXQgaXMgYmVzdCB0byBsZXQgdGhlIE5FVENPTkYvUkVTVENPTkYNCj5jbGllbnQg
ZGVjaWRlIHdoZW4gdG8gY2xvc2UgdGhlIHNlc3Npb24goakgdGhlIHNlcnZlciBzaG91bGQgbGVh
dmUgdGhlDQo+c2Vzc2lvbiBvcGVuLCB1cCB1bnRpbCB0aGUgL3Nlc3Npb24tb3B0aW9ucy9pZGxl
LXRpbWVvdXQgbGltaXQuDQo+DQo+DQo+WzNdIC4uLi9yZWNvbm5lY3Qtc3RyYXRlZ3kvaW50ZXJ2
YWwtc2VjczoNCj5UaGlzIGxlYWYgaXMgdG8gYmUgcmVtb3ZlZC4gIEl0IGRvZXNuJ3QgaGF2ZSBl
bm91Z2ggdmFsdWUgdG8gbGVhdmUgZXhwb3NlZA0KPmFzIGEgY29uZmlndXJhYmxlIGtub3cuDQo+
DQo+DQo+RHVlIHRvIFsxXSBiZWluZyBzdGlsbCBvcGVuLCB0aGlzIGlzc3VlIG9ubHkgbW92ZXMg
dG8gdGhlIE9QRU4gc3RhdGUgLSBub3QNCj50aGUgVkVSSUZZIHN0YXRlLg0KPg0KPlJlZmVyZW5j
ZTogIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3NlcnZlci1tb2RlbC9pc3N1ZXMvNDMN
Cj4NCj5UaGFua3MsDQo+S2VudA0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+TmV0Y29uZiBtYWlsaW5nIGxpc3QNCj5OZXRjb25mQGll
dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoN
Cg==


From nobody Sun Mar 29 13:27:43 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83981A88ED for ; Sun, 29 Mar 2015 13:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYRIqFKv8XhF for ; Sun, 29 Mar 2015 13:27:40 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A3D1A88E4 for ; Sun, 29 Mar 2015 13:27:39 -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.125.19; Sun, 29 Mar 2015 20:27:37 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 20:27:37 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #45: how do interval-secs and count-max work for reconnect-strategy if an endpoint resolves to multiple IP addresses?
Thread-Index: AQHQal7LozzKhahidkWEwaktaurFEw==
Date: Sun, 29 Mar 2015 20:27:37 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(92566002)(450100001)(2900100001)(15975445007)(50986999)(102836002)(54356999)(66066001)(122556002)(99286002)(19580395003)(2501003)(62966003)(77156002)(229853001)(2351001)(110136001)(107886001)(46102003)(40100003)(2656002)(106116001)(87936001)(36756003)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; 
x-forefront-prvs: 0530FCB552
Content-Type: multipart/alternative; boundary="_000_D13DCA679C405kwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 20:27:37.2303 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457
Archived-At: 
Subject: [Netconf] server-model #45: how do interval-secs and count-max work for reconnect-strategy if an endpoint resolves to multiple IP addresses?
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, 29 Mar 2015 20:27:42 -0000

--_000_D13DCA679C405kwatsenjunipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


This issue (see subject line and/or link below) was discussed during the Da=
llas meeting with an agreement simply document that hostname expansions occ=
ur in-line.  That is, if an application has two configured endpoints ("name=
1" and "name2") and each expands into two IP addresses ({ip1.1, ip1.2, ip1.=
3}, {ip2.1, ip2.2, ip2.3}), then treat them as if the IP addresses had been=
 configured explicitly (ip1.1, ip1.2, ip1.3, ip2.1, ip2.2, ip2.3).

The issue is hence moved to the VERIFY state.  The issue will move to the E=
DIT state If no objection is raised by April 6th.

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

Thanks,
Kent

--_000_D13DCA679C405kwatsenjunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <55A18CD83D79804CABAB7DF6225FBBEB@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable














This issue (see subject line and/or link =
below) was discussed during the Dallas meeting with an agreement simply=
 document that hostname expansions occur
 in-line.  That is, if an application has two configured e=
ndpoints ("name1" and "name2") and each expands into tw=
o IP addresses ({ip1.1, ip1.2, ip1.3}, {ip2.1, ip2.2, ip2.3}), then treat t=
hem as if the IP addresses had been configured explicitly (ip1.1,
 ip1.2, ip1.3, ip2.1, ip2.2, ip2.3).









The issue is hence moved to the VERIFY st=
ate.  The issue will move to the EDIT state If no objection is raised =
by April 6th.









Reference: https://github.com/netconf-wg/server-model/=
issues/45









Thanks,



Kent




--_000_D13DCA679C405kwatsenjunipernet_--


From nobody Sun Mar 29 14:35:38 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0961A1EF3 for ; Sun, 29 Mar 2015 14:35:37 -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 6sExx3o8FDcL for ; Sun, 29 Mar 2015 14:35:35 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57621A1B72 for ; Sun, 29 Mar 2015 14:35:35 -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.1.125.19; Sun, 29 Mar 2015 21:35:34 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 21:35:33 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK?
Thread-Index: AQHQalr5OEpeLICj8UOqu96zVYFF7Z0zlHEAgAATlgA=
Date: Sun, 29 Mar 2015 21:35:32 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(164054003)(51704005)(377454003)(36756003)(102836002)(92566002)(46102003)(2501003)(2950100001)(450100001)(77156002)(110136001)(62966003)(15975445007)(122556002)(99286002)(2351001)(2900100001)(40100003)(107886001)(66066001)(19580405001)(106116001)(19580395003)(50986999)(76176999)(2656002)(54356999)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 0530FCB552
Content-Type: text/plain; charset="euc-kr"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 21:35:32.6544 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Subject: Re: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK?
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, 29 Mar 2015 21:35:37 -0000

DQpzL2tub3cva25vYi8gICAtIHRoaXMgb24gdHdvIHNlcGFyYXRlIGxpbmVzIGluIHRoZSBvcmln
aW5hbCBtZXNzYWdlLg0KDQoNCktlbnQNCg0KDQpPbiAzLzI5LzE1LCAzOjI1IFBNLCAiS2VudCBX
YXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPg0KPlJlbGF0ZWQgdG8gWzFd
IGlzIHRoZSBleHBlbnNlIG9mIGhhdmluZyB0byBzZXR1cCBhIG5ldyBjcnlwdG8gc2Vzc2lvbiBh
cw0KPndlbGwgYXMgcmVlc3RhYmxpc2ggYW55IGxvbmctcG9sbCBSUENzIGxpa2UgbmV0Y29uZi9y
ZXN0Y29uZg0KPm5vdGlmaWNhdGlvbnMuLi4NCj4NCj5UaGFua3MsDQo+S2VudA0KPg0KPg0KPg0K
Pk9uIDMvMjkvMTUsIDM6MDAgUE0sICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+
IHdyb3RlOg0KPg0KPj4NCj4+VGhpcyBpc3N1ZSB3YXMgZGlzY3Vzc2VkIGR1cmluZyBhbmQgYWZ0
ZXIgdGhlIERhbGxhcyBtZWV0aW5nIHdpdGggdGhlDQo+PmZvbGxvd2luZyBzdGF0dXM6DQo+Pg0K
Pj5bMV0gLi4uL2Nvbm5lY3Rpb24tdHlwZS9wZXJzaXN0ZW50L2tlZXAtYWxpdmVzL2ludGVydmFs
LXNlY3M6DQo+PlRoaXMgaXNzdWUgaXMgc3RpbGwgb3BlbiAtIHBsZWFzZSByZXBseSBvbiBpdCBp
ZiBzbyBpbmNsaW5lZC4gIFNvbWUgZmVsdA0KPj50aGF0IGEga2VlcC1hbGl2ZSBldmVyeSAxNSBz
ZWNvbmRzIHdhcyB0b28gb2Z0ZW4sIGFuZCBzdWdnZXN0ZWQgdGhhdCBhDQo+PjKhqWhvdXIgdmFs
dWUgd291bGQgYmUgYmV0dGVyLiAgIFNlYXJjaGluZyBvbiB0aGlzIGZvciBhd2hpbGUsIGl0IHNl
ZW1zDQo+PnRoYXQgbWFueSB1c2UgMzAwIHNlY29uZHMgYW5kIG1hbnkgb3RoZXJzIHVzZSAxNSBz
ZWNvbmRzLCAgTm90ZSwgdGhpcyBpcw0KPj5hDQo+PmtlZXAtYWxpdmUgbWVzc2FnZSBiZWluZyBz
ZW50IGV2ZXJ5IDE1IHRvIDMwMCBzZWNvbmRzLCB3aXRoIGEgZGVmYXVsdA0KPj5jb3VudC1tYXgg
b2YgJzMnLCByZXN1bHRzIGluIGEgbmV3IGNvbm5lY3Rpb24gYWZ0ZXIgNDUgdG8gOTAwIHNlY29u
ZHMgLQ0KPj50aGF0J3MgMy80IG9mIGEgbWludXRlIHRvIDE1IG1pbnV0ZXMgdG8gcHJvYWN0aXZl
bHkgYnJpbmcgdXAgYSBmYWlsZWQNCj4+c2Vzc2lvbi4gIFNvbWUgb2YgdGhlIGlzc3VlIHN1cnJv
dW5kcyBob3cgdGhlIFRDUC1sZXZlbCAgdGltZW91dCBpcyBzZXQuDQo+PlRoZSBpbnRyb2R1Y3Rp
b24gaW4gUkZDNTQ4MiBzYXlzOg0KPj4NCj4+ICAgSW4gdGhlIGFic2VuY2Ugb2YgYW4gYXBwbGlj
YXRpb24tc3BlY2lmaWVkIHVzZXIgdGltZW91dCwgdGhlIFRDUA0KPj4gICBzcGVjaWZpY2F0aW9u
IFtSRkMwNzkzXSBkZWZpbmVzIGEgZGVmYXVsdCB1c2VyIHRpbWVvdXQgb2YgNSBtaW51dGVzLg0K
Pj4gICBUaGUgSG9zdCBSZXF1aXJlbWVudHMgUkZDIFtSRkMxMTIyXSByZWZpbmVzIHRoaXMgZGVm
aW5pdGlvbiBieQ0KPj4gICBpbnRyb2R1Y2luZyB0d28gdGhyZXNob2xkcywgUjEgYW5kIFIyIChS
MiA+IFIxKSwgdGhhdCBjb250cm9sIHRoZQ0KPj4gICBudW1iZXIgb2YgcmV0cmFuc21pc3Npb24g
YXR0ZW1wdHMgZm9yIGEgc2luZ2xlIHNlZ21lbnQuICBJdCBzdWdnZXN0cw0KPj4gICB0aGF0IFRD
UCBzaG91bGQgbm90aWZ5IGFwcGxpY2F0aW9ucyB3aGVuIFIxIGlzIHJlYWNoZWQgZm9yIGEgc2Vn
bWVudCwNCj4+ICAgYW5kIGNsb3NlIHRoZSBjb25uZWN0aW9uIHdoZW4gUjIgaXMgcmVhY2hlZC4g
IFtSRkMxMTIyXSBhbHNvIGRlZmluZXMNCj4+ICAgdGhlIHJlY29tbWVuZGVkIHZhbHVlcyBmb3Ig
UjEgKDMgcmV0cmFuc21pc3Npb25zKSBhbmQgUjIgKDEwMA0KPj4gICBzZWNvbmRzKSwgbm90aW5n
IHRoYXQgUjIgZm9yIFNZTiBzZWdtZW50cyBzaG91bGQgYmUgYXQgbGVhc3QgMw0KPj4gICBtaW51
dGVzLiAgSW5zdGVhZCBvZiBhIHNpbmdsZSB1c2VyIHRpbWVvdXQsIHNvbWUgVENQIGltcGxlbWVu
dGF0aW9ucw0KPj4gICBvZmZlciBmaW5lci1ncmFpbmVkIHBvbGljaWVzLiAgRm9yIGV4YW1wbGUs
IFNvbGFyaXMgc3VwcG9ydHMNCj4+ICAgZGlmZmVyZW50IHRpbWVvdXRzIGRlcGVuZGluZyBvbiB3
aGV0aGVyIGEgVENQIGNvbm5lY3Rpb24gaXMgaW4gdGhlDQo+PiAgIFNZTi1TRU5ULCBTWU4tUkVD
RUlWRUQsIG9yIEVTVEFCTElTSEVEIHN0YXRlIFtTT0xBUklTXS4NCj4+DQo+Pkkgd29uZGVyIGlm
IHdlIHNob3VsZCAqYWRkKiBjb25maWd1cmF0aW9uIGtub3cgZm9yIGEgdGNwIHRpbWVvdXQgYXMg
d2VsbD8NCj4+DQo+Pg0KPj5bMl0gLi4uL2Nvbm5lY3Rpb24tdHlwZS9wZXJpb2RpYy9saW5nZXIt
c2VjczoNCj4+VGhpcyBsZWFmIGlzIHRvIGJlIHJlbW92ZWQgYXMgaXQgaXMgYmVzdCB0byBsZXQg
dGhlIE5FVENPTkYvUkVTVENPTkYNCj4+Y2xpZW50IGRlY2lkZSB3aGVuIHRvIGNsb3NlIHRoZSBz
ZXNzaW9uIKGpIHRoZSBzZXJ2ZXIgc2hvdWxkIGxlYXZlIHRoZQ0KPj5zZXNzaW9uIG9wZW4sIHVw
IHVudGlsIHRoZSAvc2Vzc2lvbi1vcHRpb25zL2lkbGUtdGltZW91dCBsaW1pdC4NCj4+DQo+Pg0K
Pj5bM10gLi4uL3JlY29ubmVjdC1zdHJhdGVneS9pbnRlcnZhbC1zZWNzOg0KPj5UaGlzIGxlYWYg
aXMgdG8gYmUgcmVtb3ZlZC4gIEl0IGRvZXNuJ3QgaGF2ZSBlbm91Z2ggdmFsdWUgdG8gbGVhdmUN
Cj4+ZXhwb3NlZA0KPj5hcyBhIGNvbmZpZ3VyYWJsZSBrbm93Lg0KPj4NCj4+DQo+PkR1ZSB0byBb
MV0gYmVpbmcgc3RpbGwgb3BlbiwgdGhpcyBpc3N1ZSBvbmx5IG1vdmVzIHRvIHRoZSBPUEVOIHN0
YXRlIC0NCj4+bm90DQo+PnRoZSBWRVJJRlkgc3RhdGUuDQo+Pg0KPj5SZWZlcmVuY2U6ICBodHRw
czovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9zZXJ2ZXItbW9kZWwvaXNzdWVzLzQzDQo+Pg0KPj5U
aGFua3MsDQo+PktlbnQNCj4+DQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4+TmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4+TmV0Y29uZkBp
ZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN
Cj4NCg0K


From nobody Sun Mar 29 15:11:52 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4511A6FCF for ; Sun, 29 Mar 2015 15:11: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 9GY7bo6U10sZ for ; Sun, 29 Mar 2015 15:11:48 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A141A6FBC for ; Sun, 29 Mar 2015 15:11:48 -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.1.125.19; Sun, 29 Mar 2015 22:11:30 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 22:11:30 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #46: move "peer_allowed_to_send" to Call Home draft?
Thread-Index: AQHQam1OLVdFk/Tgw0OjXWX6/Gw/Vw==
Date: Sun, 29 Mar 2015 22:11:29 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(19580395003)(106116001)(50986999)(66066001)(107886001)(2656002)(87936001)(54356999)(561944003)(450100001)(62966003)(110136001)(77156002)(15975445007)(102836002)(36756003)(92566002)(2501003)(46102003)(40100003)(2900100001)(229853001)(2351001)(122556002)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; 
x-forefront-prvs: 0530FCB552
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3275B6E2D54D0D4AA74A2AD61774E094@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 22:11:29.7137 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460
Archived-At: 
Subject: [Netconf] server-model #46: move "peer_allowed_to_send" to Call Home draft?
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, 29 Mar 2015 22:11:50 -0000

This issue (see subject line and link below) was discussed during the
Dallas meeting with no clear agreement, so bringing the discussion to the
list now.

As Juergen questioned originally, if configuring keep-alives (and perhaps
tcp timeouts) is important, then the call-home draft should say something
about it.   This makes sense as the call-home draft intends to describe
the protocol, leaving the server-model draft to focus on the yang modules.
  One issue arises, though, in that the server-model uses keep-alives
under both the "call-home" and "listen" subtrees.  We may want to remove
the keep-alive configuration under the "listen" subtree, where it only
supports a low-value use-case.  If we remove it, then it clears the way to
adding text to the call-home draft, as only the "call-home" subtree would
be left in the netconf/restconf yang modules.

Note: This issue is related to server-model #43 [1], which is about the
default value for /keep-alives/interval-secs, and asks if the server-model
should have a knob to configure the tcp timeout value.   If we agree that
there should be a knob to configure the tcp timeout, then the call-home
draft should discuss this in the same section where is would discuss the
need for SSH/TLS-level keep-alives.


This issue is hence moved to the OPEN (not VERIFY) state.  The issue will
move to the VERIFY state with the above proposal if no objection is raised
by April 6th.

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

Thanks,
Kent



From nobody Sun Mar 29 15:44:04 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86A01A7D85 for ; Sun, 29 Mar 2015 15:44:03 -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 Rg7SjdldiYVz for ; Sun, 29 Mar 2015 15:44:02 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FAE1A2130 for ; Sun, 29 Mar 2015 15:44:01 -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.1.125.19; Sun, 29 Mar 2015 22:43:41 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 22:43:41 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send?
Thread-Index: AQHQanHN/SlTGz/ugUOL8zG3tGhV5w==
Date: Sun, 29 Mar 2015 22:43:41 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(50986999)(106116001)(102836002)(229853001)(107886001)(46102003)(36756003)(54356999)(40100003)(2900100001)(66066001)(122556002)(110136001)(99286002)(2501003)(2656002)(77156002)(92566002)(450100001)(62966003)(2351001)(15975445007)(19580395003)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; 
x-forefront-prvs: 0530FCB552
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9E36AF1F7596FE4293DB63045C489D59@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 22:43:41.3425 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459
Archived-At: 
Subject: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send?
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, 29 Mar 2015 22:44:04 -0000

This issue (see subject line and/or link below) was discussed during the
Dallas meeting with an agreement to change the "should" to a "may", that
the server *may* connect sooner than its periodic timeout would have it do.

OLD:

                  For messages the NETCONF server wants to send to
                  to the NETCONF client, the NETCONF server should
                  proactively connect to the NETCONF client, if
                  not already, to send the messages immediately.";

NEW

                  For messages the NETCONF server wants to send to
                  to the NETCONF client, the NETCONF server may
                  proactively connect to the NETCONF client, if
                  not already, to send its messages sooner than
                  its periodic timeout would have it do.";


This issue is hence moved to the VERIFY state.  The issue will move to the
EDIT state if no objection is raised by April 6th.

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


Thanks,
Kent


From nobody Sun Mar 29 16:06:38 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375021A86F8 for ; Sun, 29 Mar 2015 16:06: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_A2yygmuQ9F for ; Sun, 29 Mar 2015 16:06:35 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1774E1A86EF for ; Sun, 29 Mar 2015 16:06:34 -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.1.125.19; Sun, 29 Mar 2015 23:06:33 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.86]) with mapi id 15.01.0125.002; Sun, 29 Mar 2015 23:06:33 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls?
Thread-Index: AQHQanT/BncK8ydKj0azKXFdHxn57w==
Date: Sun, 29 Mar 2015 23:06:32 +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-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.12]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2351001)(99286002)(2501003)(54356999)(50986999)(19580395003)(36756003)(230783001)(122556002)(92566002)(107886001)(229853001)(106116001)(66066001)(46102003)(40100003)(86362001)(2900100001)(450100001)(16236675004)(83506001)(77156002)(62966003)(102836002)(87936001)(15975445007)(110136001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; 
x-forefront-prvs: 0530FCB552
Content-Type: multipart/alternative; boundary="_000_D13DEFA59C54Fkwatsenjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2015 23:06:32.1445 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458
Archived-At: 
Subject: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls?
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, 29 Mar 2015 23:06:37 -0000

--_000_D13DEFA59C54Fkwatsenjunipernet_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This issue (see subject line and/or link below) was discussed during the Da=
llas meeting with an agreement to combine the configuration for trusted CA-=
certs and client-certs into one container for both SSH and TLS.  The new co=
ntainer would use the following YANG 1.1 if-feature statement (assuming the=
 WG adopts that resolution):

    if-feature "(ssh-x509-certs or tls)";

This issue is hence moved to the VERIFY state.  The issue will move to the =
EDIT state if no objection is raised by April 6th.

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

Thanks,
Kent


--_000_D13DEFA59C54Fkwatsenjunipernet_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable














This issue (see subject line and/or =
link below) was discussed during the Dallas meeting with an agreement to combine the con=
figuration for trusted
 CA-certs and client-certs into one container for both SSH and TLS.  T=
he new container would use the following YANG 1.1 if-feature statement (ass=
uming the WG adopts that resolution):







    if-feature “(ssh-x509-certs or tls)”;







This issue is hence moved to the VER=
IFY state.  The issue will move to the EDIT state if no objection is raised by Apri=
l 6th.







Reference: https://github.com/netcon=
f-wg/server-model/issues/49







Thanks,


Kent











--_000_D13DEFA59C54Fkwatsenjunipernet_--


From nobody Sun Mar 29 17:57:17 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C511A898F for ; Sun, 29 Mar 2015 17:57:15 -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 Y1O0RV48Hzqz for ; Sun, 29 Mar 2015 17:57:14 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E9F1A897B for ; Sun, 29 Mar 2015 17:57:13 -0700 (PDT)
Received: from CO2PR05CA015.namprd05.prod.outlook.com (10.141.241.143) by BL2PR05MB130.namprd05.prod.outlook.com (10.242.198.15) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 30 Mar 2015 00:56:58 +0000
Received: from BL2FFO11FD037.protection.gbl (2a01:111:f400:7c09::196) by CO2PR05CA015.outlook.office365.com (2a01:111:e400:1429::15) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Mon, 30 Mar 2015 00:56:50 +0000
Received: from P-EMF03-SAC.jnpr.net ([66.129.239.17]) by BL2FFO11FD037.mail.protection.outlook.com ([10.173.161.133]) with Microsoft SMTP Server (TLS) id 15.1.130.10 via Frontend Transport; Mon, 30 Mar 2015 00:56:49 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 29 Mar 2015 17:56:48 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t2U0ulD72211;	Sun, 29 Mar 2015 17:56:47 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t2U0tp9o079977; Sun, 29 Mar 2015 20:55:51 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201503300055.t2U0tp9o079977@idle.juniper.net>
To: Kent Watsen 
In-Reply-To: 
Date: Sun, 29 Mar 2015 20:55:51 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender)
Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(164054003)(479174004)(189002)(51704005)(377454003)(199003)(77156002)(2950100001)(48376002)(50466002)(62966003)(47776003)(110136001)(87936001)(105596002)(46102003)(86362001)(50986999)(450100001)(19580395003)(19580405001)(53416004)(76506005)(106466001)(54356999)(77096005)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB130; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB130;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BL2PR05MB130; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB130; 
X-Forefront-PRVS: 05315CBE52
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2015 00:56:49.4745 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17];  Helo=[P-EMF03-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB130
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] server-model #40: move "max-sessions" to global session-param?
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, 30 Mar 2015 00:57:15 -0000

Seems clear to me.

Thanks,
 Phil



Kent Watsen writes:
>
>Perhaps it just goes to DEAD, with no change in text.  Do you think the
>description is currently unclear?  Should the description call out that
>max-sessions has no impact on the number of call-home sessions that can be
>configured?
>
>Kent
>
>
>On 3/29/15, 12:38 PM, "Phil Shafer"  wrote:
>
>>Kent Watsen writes:
>>>This issue was discussed during and after the Dallas meeting with an
>>>agreem=
>>>ent to leave the "max-sessions" under the
>>>"listen" container.  This because only call-home connections are not
>>>variab=
>>>le in number.  The issue is hence moved to the VERIFY state.  The issue
>>>wil=
>>>l move to the EDIT state if no objection is raised by April 6th.
>>
>>It's not clear what the "EDIT" is if the decision is to not
>>change it.  Are you changing the description to be more clear?
>>
>>Thanks,
>> Phil
>


From nobody Sun Mar 29 19:42:34 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA81A8AB8 for ; Sun, 29 Mar 2015 19:42:32 -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 h7k59_tGrUO3 for ; Sun, 29 Mar 2015 19:42:30 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BD31A1A64 for ; Sun, 29 Mar 2015 19:42:30 -0700 (PDT)
Received: from BLUPR05CA0071.namprd05.prod.outlook.com (10.141.20.41) by BN1PR05MB138.namprd05.prod.outlook.com (10.255.205.14) with Microsoft SMTP Server (TLS) id 15.1.125.19; Mon, 30 Mar 2015 02:42:09 +0000
Received: from BL2FFO11FD036.protection.gbl (2a01:111:f400:7c09::103) by BLUPR05CA0071.outlook.office365.com (2a01:111:e400:855::41) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Mon, 30 Mar 2015 02:42:09 +0000
Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD036.mail.protection.outlook.com (10.173.161.132) with Microsoft SMTP Server (TLS) id 15.1.130.10 via Frontend Transport; Mon, 30 Mar 2015 02:42:08 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 29 Mar 2015 19:41:58 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t2U2fvD12163;	Sun, 29 Mar 2015 19:41:57 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t2U2exT4083630; Sun, 29 Mar 2015 22:41:01 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201503300241.t2U2exT4083630@idle.juniper.net>
To: Juergen Schoenwaelder 
In-Reply-To: <20150328084338.GA61327@elstar.local>
Date: Sun, 29 Mar 2015 22:40:59 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender)
Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(199003)(77096005)(92566002)(62966003)(19580395003)(15975445007)(110136001)(2950100001)(77156002)(106466001)(105596002)(54356999)(50986999)(46102003)(50466002)(87936001)(93376004)(86362001)(53416004)(6806004)(47776003)(76506005)(558084003)(48376002)(569964003)(15302535012); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB138; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:nov; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; 
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB138;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BN1PR05MB138; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB138; 
X-Forefront-PRVS: 05315CBE52
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2015 02:42:08.1185 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17];  Helo=[P-EMF03-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB138
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] restconf selecting encoding for notifications
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, 30 Mar 2015 02:42:32 -0000

Juergen Schoenwaelder writes:
>PS: http://www.w3.org/TR/eventsource/

Very cool.  Can we have the draft add a reference to this TR?

Thanks,
 Phil


From nobody Sun Mar 29 22:05:07 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79731A904F for ; Sun, 29 Mar 2015 22:05:05 -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 I0eK9uGx5g2S for ; Sun, 29 Mar 2015 22:05:04 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2961A9058 for ; Sun, 29 Mar 2015 22:05:02 -0700 (PDT)
Received: from BY2PR05CA028.namprd05.prod.outlook.com (10.141.250.18) by DM2PR05MB736.namprd05.prod.outlook.com (10.141.178.25) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 30 Mar 2015 05:04:43 +0000
Received: from BY2FFO11FD052.protection.gbl (2a01:111:f400:7c0c::159) by BY2PR05CA028.outlook.office365.com (2a01:111:e400:2c5f::18) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Mon, 30 Mar 2015 05:04:42 +0000
Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BY2FFO11FD052.mail.protection.outlook.com (10.1.15.189) with Microsoft SMTP Server (TLS) id 15.1.125.13 via Frontend Transport; Mon, 30 Mar 2015 05:04:42 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 29 Mar 2015 22:04:41 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t2U54eD69993;	Sun, 29 Mar 2015 22:04:41 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t2U53jqh084141; Mon, 30 Mar 2015 01:03:45 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201503300503.t2U53jqh084141@idle.juniper.net>
To: Kent Watsen 
In-Reply-To: 
Date: Mon, 30 Mar 2015 01:03:45 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender)
Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none;
X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(106466001)(110136001)(87936001)(53416004)(2950100001)(105596002)(76506005)(92566002)(450100001)(47776003)(48376002)(86362001)(62966003)(50986999)(77156002)(46102003)(77096005)(50466002)(54356999)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB736; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB736;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR05MB736; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB736; 
X-Forefront-PRVS: 05315CBE52
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2015 05:04:42.5756 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17];  Helo=[P-EMF03-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB736
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] server-model #43: keep-alive, linger, reconnect interval defaults OK?
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, 30 Mar 2015 05:05:06 -0000

Kent Watsen writes:
>Note, this is a
>keep-alive message being sent every 15 to 300 seconds, with a default
>count-max of '3', results in a new connection after 45 to 900 seconds -
>that's 3/4 of a minute to 15 minutes to proactively bring up a failed
>session.

Having a connection to your NMS die after 45 seconds during a network
issue, when the network _is_ having trouble, seems unwise.

Thanks,
 Phil


From nobody Mon Mar 30 00:32:56 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C88A1A9111 for ; Mon, 30 Mar 2015 00:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.46
X-Spam-Level: 
X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 2HvTTuj0_QsF for ; Mon, 30 Mar 2015 00:32:53 -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 38CA51A910E for ; Mon, 30 Mar 2015 00:32:53 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 895B01016; Mon, 30 Mar 2015 09:32:51 +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 cnW8Ne1c6Ugt; Mon, 30 Mar 2015 09:32:50 +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, 30 Mar 2015 09:32:50 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA0802002B; Mon, 30 Mar 2015 09:32:50 +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 ijWJAdv8b4dn; Mon, 30 Mar 2015 09:32:49 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F3C720013; Mon, 30 Mar 2015 09:32:48 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7CE5B329932D; Mon, 30 Mar 2015 09:32:45 +0200 (CEST)
Date: Mon, 30 Mar 2015 09:32:45 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20150330073242.GA66374@elstar.local>
Mail-Followup-To: Kent Watsen , "netconf@ietf.org" 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] server-model #45: how do interval-secs and count-max work for reconnect-strategy if an endpoint resolves to multiple IP addresses?
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, 30 Mar 2015 07:32:55 -0000

On Sun, Mar 29, 2015 at 08:27:37PM +0000, Kent Watsen wrote:
> 
> This issue (see subject line and/or link below) was discussed during the Dallas meeting with an agreement simply document that hostname expansions occur in-line.  That is, if an application has two configured endpoints ("name1" and "name2") and each expands into two IP addresses ({ip1.1, ip1.2, ip1.3}, {ip2.1, ip2.2, ip2.3}), then treat them as if the IP addresses had been configured explicitly (ip1.1, ip1.2, ip1.3, ip2.1, ip2.2, ip2.3).
> 
> The issue is hence moved to the VERIFY state.  The issue will move to the EDIT state If no objection is raised by April 6th.
> 
> Reference: https://github.com/netconf-wg/server-model/issues/45
>

Do we keep interval-secs and count-max in the reconnect-strategy
container? If not, then I would say that we can also be silent about
this. It is good practice to iterate over the list getaddrinfo()
returns and I think it is fine if we stay out of the timing and
iteration details.

/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 Mar 30 00:36:50 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874641A9119 for ; Mon, 30 Mar 2015 00:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 rtMWPEoOppva for ; Mon, 30 Mar 2015 00:36:46 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798011A9115 for ; Mon, 30 Mar 2015 00:36:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4C78310CD; Mon, 30 Mar 2015 09:36:45 +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 T7Fi13-YC6aG; Mon, 30 Mar 2015 09:36:43 +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, 30 Mar 2015 09:36:44 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45BAD2002C; Mon, 30 Mar 2015 09:36:44 +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 e-s4GVI4mpOu; Mon, 30 Mar 2015 09:36:43 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AA7D920013; Mon, 30 Mar 2015 09:36:42 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7AA35329936F; Mon, 30 Mar 2015 09:36:41 +0200 (CEST)
Date: Mon, 30 Mar 2015 09:36:41 +0200
From: Juergen Schoenwaelder 
To: Phil Shafer 
Message-ID: <20150330073641.GB66374@elstar.local>
Mail-Followup-To: Phil Shafer , Kent Watsen , "netconf@ietf.org" 
References:  <201503300055.t2U0tp9o079977@idle.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201503300055.t2U0tp9o079977@idle.juniper.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] server-model #40: move "max-sessions" to global session-param?
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, 30 Mar 2015 07:36:48 -0000

Hi,

I think the text needs to clarify that max-session does not include
call-home initiated sessions. We should not assume people will infer
this from the fact that this object sits in the listen branch.

/js

On Sun, Mar 29, 2015 at 08:55:51PM -0400, Phil Shafer wrote:
> Seems clear to me.
> 
> Thanks,
>  Phil
> 
> 
> 
> Kent Watsen writes:
> >
> >Perhaps it just goes to DEAD, with no change in text.  Do you think the
> >description is currently unclear?  Should the description call out that
> >max-sessions has no impact on the number of call-home sessions that can be
> >configured?
> >
> >Kent
> >
> >
> >On 3/29/15, 12:38 PM, "Phil Shafer"  wrote:
> >
> >>Kent Watsen writes:
> >>>This issue was discussed during and after the Dallas meeting with an
> >>>agreem=
> >>>ent to leave the "max-sessions" under the
> >>>"listen" container.  This because only call-home connections are not
> >>>variab=
> >>>le in number.  The issue is hence moved to the VERIFY state.  The issue
> >>>wil=
> >>>l move to the EDIT state if no objection is raised by April 6th.
> >>
> >>It's not clear what the "EDIT" is if the decision is to not
> >>change it.  Are you changing the description to be more clear?
> >>
> >>Thanks,
> >> Phil
> >
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Mar 30 13:21:17 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12171AD49F for ; Mon, 30 Mar 2015 13:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwRuaoGNDOcU for ; Mon, 30 Mar 2015 13:21:14 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDD91B29B9 for ; Mon, 30 Mar 2015 13:19:07 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=B7fvjmtBBNLOFVGJMgI1P4lzD4BKcN32CiTshKyN8eV5BSw8S0rWVRFJ798UJdsf; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ycg9K-0003DC-Gg for netconf@ietf.org; Mon, 30 Mar 2015 16:19:06 -0400
Received: from 76.254.52.212 by webmail.earthlink.net with HTTP; Mon, 30 Mar 2015 16:19:06 -0400
Message-ID: <30896412.1427746746472.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
Date: Mon, 30 Mar 2015 13:19:06 -0700 (GMT-07:00)
From: Randy Presuhn 
To: "netconf@ietf.org" 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115371405e1aef168983bea739290d45ff97f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.45
Archived-At: 
Subject: Re: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Mar 2015 20:21:15 -0000

Hi -

>From: Kent Watsen 
>Sent: Mar 29, 2015 3:43 PM
>To: "netconf@ietf.org" 
>Subject: [Netconf] server-model #47: introduce a 2nd timeout for periodic connections for when there's data to send?
>
>
>This issue (see subject line and/or link below) was discussed during the
>Dallas meeting with an agreement to change the "should" to a "may", that
>the server *may* connect sooner than its periodic timeout would have it do.
>
>OLD:
>
>                  For messages the NETCONF server wants to send to
>                  to the NETCONF client, the NETCONF server should
>                  proactively connect to the NETCONF client, if
>                  not already, to send the messages immediately.";
>
>NEW
>
>                  For messages the NETCONF server wants to send to
>                  to the NETCONF client, the NETCONF server may
>                  proactively connect to the NETCONF client, if
>                  not already, to send its messages sooner than
>                  its periodic timeout would have it do.";

The English is broken.
   s/, if not already,/ (if it is not already connected)/

The English is awkward.
   s/its periodic timeout would have it do/specified by its periodic timeout/

Anthropomorphisms are annoying:
   s/the NETCONF server wants to send/to be sent by the NETCONF server/

Randy


From nobody Tue Mar 31 01:07:14 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1305E1A9107 for ; Tue, 31 Mar 2015 01:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 W_0nNNoSQVsz for ; Tue, 31 Mar 2015 01:07:10 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D341A90F0 for ; Tue, 31 Mar 2015 01:07:10 -0700 (PDT)
Received: from pc6 (81.151.162.168) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 31 Mar 2015 08:06:48 +0000
Message-ID: <00f901d06b89$82faa3e0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Kent Watsen , 
References: 
Date: Tue, 31 Mar 2015 09:05:14 +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: [81.151.162.168]
X-ClientProxiedBy: DB4PR01CA0024.eurprd01.prod.exchangelabs.com (10.242.152.14) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142)
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053;
X-Microsoft-Antispam-PRVS: 
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(13464003)(50226001)(44736004)(44716002)(230783001)(116806002)(84392001)(40100003)(19580395003)(19580405001)(1941001)(122386002)(23756003)(77096005)(33646002)(46102003)(50466002)(1456003)(15975445007)(92566002)(107886001)(14496001)(77156002)(62966003)(86362001)(50986999)(81686999)(81816999)(76176999)(61296003)(1556002)(87976001)(47776003)(42186005)(66066001)(62236002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:AMXPR07MB053; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB053; 
X-Forefront-PRVS: 0532BF6DC2
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2015 08:06:48.9028 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB053
Archived-At: 
Subject: Re: [Netconf] server-model #49: combine trusted-ca-certs and trusted-client-certs for ssh/tls?
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, 31 Mar 2015 08:07:12 -0000

----- Original Message -----
From: "Kent Watsen" 
To: 
Sent: Monday, March 30, 2015 12:06 AM

This issue (see subject line and/or link below) was discussed during the
Dallas meeting with an agreement to combine the configuration for
trusted CA-certs and client-certs into one container for both SSH and
TLS.  The new container would use the following YANG 1.1 if-feature
statement (assuming the WG adopts that resolution):



Does this mean that unless and until the clients and servers are
upgraded to support YANG 1.1, then there will be no YANG server model
that they could use?

Tom Petch


    if-feature "(ssh-x509-certs or tls)";

This issue is hence moved to the VERIFY state.  The issue will move to
the EDIT state if no objection is raised by April 6th.

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

Thanks,
Kent




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


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


From nobody Tue Mar 31 11:34:19 2015
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD581ACE91 for ; Tue, 31 Mar 2015 11:34:17 -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 aSDS7a0TAzbc for ; Tue, 31 Mar 2015 11:34:16 -0700 (PDT)
Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2581ACD2E for ; Tue, 31 Mar 2015 11:33:43 -0700 (PDT)
Received: by qcrf4 with SMTP id f4so8829853qcr.0 for ; Tue, 31 Mar 2015 11:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:subject:message-id:date:to:mime-version; bh=9bRLNuZheHRk94Rvgk8keT3Yqj9ObCb4+8PYpEwBH2k=; b=Z8bESCJZMVEBXZfs6CvB4kU30Jr9omOOT2GUQ14eDOIJr94AAFzgBVCaEH0XGHccIy BfHXBwZBAvodCDZXdCPP6dcjy3tDE7xCAD00mA1XymbKJtFWAHDm8qcLjUL3v9uYknMJ wtWxxGbrMl08H/ts/kqycXtF9rWkITrJIDegO7qXkg9V6QDvCYnrBAyWUrepmhlDD1NX kQtARGKg+7Wro3gX1qi5sa5/hIGyzO2DL8kF3NAG0mLgRr6P5iCL7ENXZU78RY6dh2O4 xz3wdYtxE4pejmeg5o53WNQmjHUphnpAxihTzdZVCEkIxJrFg9ph6MfoBKducLwos9lx TV2A==
X-Received: by 10.140.108.10 with SMTP id i10mr4143930qgf.73.1427826822348; Tue, 31 Mar 2015 11:33:42 -0700 (PDT)
Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id o7sm10460101qge.8.2015.03.31.11.33.41 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 11:33:41 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A3411ED-B89C-4501-A3DC-A813CD409080"
Message-Id: <52FB66CE-47E2-4421-9C23-B2AE03F0FD74@gmail.com>
Date: Tue, 31 Mar 2015 11:33:38 -0700
To: netconf 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Subject: [Netconf] Draft minutes of the NETCONF WG meeting at IETF 92
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, 31 Mar 2015 18:34:17 -0000

--Apple-Mail=_5A3411ED-B89C-4501-A3DC-A813CD409080
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Please find the draft minutes of the NETCONF WG session at IETF 92 here =
.

Send your comments to the chairs by April 7, 2015 EOB PDT.


Mahesh & Mehmet






--Apple-Mail=_5A3411ED-B89C-4501-A3DC-A813CD409080
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Please find the draft minutes of the NETCONF WG session at IETF 92 here.

Send your comments to the chairs by April 7, 2015 EOB PDT.




Mahesh & Mehmet









--Apple-Mail=_5A3411ED-B89C-4501-A3DC-A813CD409080--





RESTCONF provides a "Simple Subset of NETCONF Functionality", exc=
luding locking, validation, confirmed commits and the startup and candidate=
 datastores. A number of potential suppliers of devices we are considering =
for out system already provide a web-based
 interface and may be far more comfortable with migrating to (or via) RESTC=
ONF rather than directly to NETCONF. However these excluded features are on=
es we had hoped to leverage.



Section 1.1 states "The following transaction features are not directl=
y provided in RESTCONF". Is the word "directly" intended to =
convey there may be indirect means of providing these features with RESTCON=
F? If so, is there any guidance on how? If not, would
 it not be better to remove the word?



Thanks



Jonathan















On 5 February 2015 at 13:22, Ersue, Mehmet (NSN - DE/Muni=
ch) 
<mehmet.ersue@nsn.com> wrote:
















Dear NETCONF WG,




we hereby issue a WG Last Call for 3 weeks for the drafts below:



 


https://tools.ietf.org/html=
/draft-ietf-netconf-restconf-04


https://tools.ietf.org/ht=
ml/draft-ietf-netconf-yang-patch-03


 


Please review and send your comments to the NETCONF WG mailing list by =
February 26, 2015 EOB PT.



The related draft-ietf-netconf-yang-library will follow with LC as soon=
 as the remaining two issues are solved



(see
http=
://tools.ietf.org/html/draft-ietf-netconf-yang-library).<=
/span>




RESTCONF documents are planned to publish as standard track documents.<=
u>


As RESTCONF is a major protocol we expect a detailed and thorough revie=
w within NETCONF WG but also by the related
 WGs before publishing.


Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs=
 will be informed as well as Core, I2rs,
 6lo, and 6tisch WGs are invited to review.




Please state explicitly that you have read/reviewed and whether you sup=
port the publication.


Please indicate also if you plan to implement or have already implement=
ation experience with RESTCONF.


 


Thank you,


Mehmet and Mahesh


 






From: Netconf [mailto:netconf-bounces@ietf.org]
On Behalf Of ext Ersue, Meh=
met (NSN - DE/Munich)

Sent: Saturday, January 31,=
 2015 4:05 PM

To: 
netconf@ietf.org

Subject: [Netconf] Restconf=
-04 and YANG-Patch-03 drafts available






 




All,






 





1 YANG patch and 9 Restconf issues ha=
ve been solved and provided in the drafts below.







These issues have been set to the sta=
tus Review (https=
://github.com/netconf-wg/restconf/issues).<=
/p>





 





Please check and comment on the draft=
s below before we go to WGLC soon:








 






Regards,


Mehmet 






 






 













_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.=
org/mailman/listinfo/netconf