From nobody Fri Oct 2 06:27: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 C90FA1A8A3D for ; Fri, 2 Oct 2015 06:27:16 -0700 (PDT) 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 TmGjMA0kw7fO for ; Fri, 2 Oct 2015 06:27:10 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 32D901A910B for ; Fri, 2 Oct 2015 06:27:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id t92DR7Vd012537 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Oct 2015 13:27:08 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t92DR5Cc027936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Oct 2015 15:27:06 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 2 Oct 2015 15:27:05 +0200 Received: from DEMUMBX006.nsn-intra.net ([169.254.6.213]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0248.002; Fri, 2 Oct 2015 15:27:05 +0200 From: "Uveges, Balint (Nokia - HU/Budapest)" To: EXT Andy Bierman Thread-Topic: [Netconf] Long-lasting RESTCONF operations Thread-Index: AdD2qlN3N/lWCzBIQVO6Z0AWvW6WZAALB++AAPYv1rA= Date: Fri, 2 Oct 2015 13:27:04 +0000 Message-ID: <28B876C36C5AA84CBAB912BA734FAC350164B30B@DEMUMBX006.nsn-intra.net> References: <28B876C36C5AA84CBAB912BA734FAC35016469DA@DEMUMBX006.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: 5014 X-purgate-ID: 151667::1443792428-00005272-9D759877/0/0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Long-lasting RESTCONF operations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 02 Oct 2015 13:27:17 -0000 SGkgQW5keSwNCg0KPiAgRnJvbTogRVhUIEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdv cmtzLmNvbV0gDQo+ICBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI0LCAyMDE1IDY6MzcgUE0N Cj4gIFRvOiBVdmVnZXMsIEJhbGludCAoTm9raWEgLSBIVS9CdWRhcGVzdCkNCj4gIENjOiBuZXRj b25mQGlldGYub3JnDQo+ICBTdWJqZWN0OiBSZTogW05ldGNvbmZdIExvbmctbGFzdGluZyBSRVNU Q09ORiBvcGVyYXRpb25zDQo+DQo+DQo+DQo+ID4gIE9uIFRodSwgU2VwIDI0LCAyMDE1IGF0IDI6 MjEgQU0sIFV2ZWdlcywgQmFsaW50IChOb2tpYSAtIEhVL0J1ZGFwZXN0KSA8YmFsaW50LnV2ZWdl c0Bub2tpYS5jb20+IHdyb3RlOg0KPiA+ICBIaSBBbGwsDQo+ID4NCj4gPiAgSSB3b3VsZCBsaWtl IHRvIGNsYXJpZnkgYW4gaXNzdWUgcmVnYXJkaW5nIHRoZSBmb2xsb3dpbmcgUkVTVENPTkYgc2Nl bmFyaW8uDQo+ID4NCj4gPiAgTGV0J3MgYXNzdW1lIHRoYXQgY2VydGFpbiBSRVNUQ09ORiBvcGVy YXRpb25zIHRha2UgcXVpdGUgc29tZSB0aW1lIG9uDQo+ID4gIHRoZSBzZXJ2ZXIgc2lkZSwgZm9y IGV4YW1wbGUgdGhlIGV2YWx1YXRpb24gb2YgYSByZWNlaXZlZCBQT1NUIG1ldGhvZA0KPiA+ICAo aW4gQ3JlYXRlIFJlc291cmNlIE1vZGUpLCBkdWUgdG8gaW50ZXJuYWwgdmFsaWRhdGlvbnMgb3Ig ZHVlIHRvIHRoZQ0KPiA+ICBwcm9jZXNzaW5nIG9mIGxhcmdlIGFtb3VudCBvZiByZWNlaXZlZCBk YXRhLiBBY2NvcmRpbmcgdG8gdGhlIFJFU1RDT05GDQo+ID4gIGRyYWZ0IChzZWN0aW9uIDQuNC4x KToNCj4gPg0KPiA+ICAgICJJZiB0aGUgUE9TVCBtZXRob2Qgc3VjY2VlZHMsIGEgIjIwMSBDcmVh dGVkIiBzdGF0dXMtbGluZSBpcyByZXR1cm5lZA0KPiA+ICAgICBhbmQgdGhlcmUgaXMgbm8gcmVz cG9uc2UgbWVzc2FnZS1ib2R5LiINCj4gPg0KPiA+ICBJZiBJIGludGVycHJldCB0aGlzIHJpZ2h0 LCBhIFJFU1RDT05GIGNsaWVudCBoYXMgdG8gd2FpdCBmb3IgMjAxIENyZWF0ZWQNCj4gPiAgKG9y IGZvciA0eHgvNXh4IGlmIHNvbWV0aGluZyBnb2VzIHdyb25nKSBubyBtYXR0ZXIgaG93IGxvbmcg aXQgdGFrZXMgZm9yDQo+ID4gIHRoZSBzZXJ2ZXIgdG8gcHJvY2VzcyBhbmQgYW5zd2VyIHRoZSBQ T1NUIG1ldGhvZC4gVGhpcyBiZWhhdmlvciBoYXMgbm8NCj4gPiAgc2lnbmlmaWNhbmNlIGlmIGEg UkVTVENPTkYgY2xpZW50IG1hbmFnZXMgb25seSBhIGZldyBSRVNUQ09ORiBzZXJ2ZXIsDQo+ID4g IGJ1dCBjb3VsZCBsZWFkIGVhc2lseSB0byBhIGJvdHRsZW5lY2sgaW4gdGhlIGNsaWVudCBpbiBj YXNlIG9mIGxhcmdlDQo+ID4gIGFtb3VudCBvZiBSRVNUQ09ORiBzZXJ2ZXJzLCB3aGVuIHRoZSBj bGllbnQgbWFuYWdlcyB0aGVtIGluIHBhcmFsbGVsLg0KPiA+DQo+ID4gIFJFU1RDT05GIGlzIGFu IEhUVFAtYmFzZWQgcHJvdG9jb2wgYW5kIFJGQyA3MjMxIGRlZmluZXMgdGhlIHN0YXR1cyBjb2Rl DQo+ID4gIDIwMiBBY2NlcHRlZCAoc2VjdGlvbiA2LjMuMykgYXM6DQo+ID4NCj4gPiAgICAiVGhl IDIwMiAoQWNjZXB0ZWQpIHN0YXR1cyBjb2RlIGluZGljYXRlcyB0aGF0IHRoZSByZXF1ZXN0IGhh cyBiZWVuDQo+ID4gICAgIGFjY2VwdGVkIGZvciBwcm9jZXNzaW5nLCBidXQgdGhlIHByb2Nlc3Np bmcgaGFzIG5vdCBiZWVuIGNvbXBsZXRlZC4NCj4gPiAgLiAuIC4NCj4gPiAgICAgVGhlIHJlcHJl c2VudGF0aW9uIHNlbnQgd2l0aCB0aGlzDQo+ID4gICAgIHJlc3BvbnNlIG91Z2h0IHRvIGRlc2Ny aWJlIHRoZSByZXF1ZXN0J3MgY3VycmVudCBzdGF0dXMgYW5kIHBvaW50IHRvDQo+ID4gICAgIChv ciBlbWJlZCkgYSBzdGF0dXMgbW9uaXRvciB0aGF0IGNhbiBwcm92aWRlIHRoZSB1c2VyIHdpdGgg YW4NCj4gPiAgICAgZXN0aW1hdGUgb2Ygd2hlbiB0aGUgcmVxdWVzdCB3aWxsIGJlIGZ1bGZpbGxl ZC4iDQo+ID4NCj4gPiAgV2l0aCAyMDIgQWNjZXB0ZWQgaXQgd291bGQgYmUgcG9zc2libGUgbm90 IGp1c3QgdG8gaW5mb3JtIHRoZSBSRVNUQ09ORg0KPiA+ICBjbGllbnQsIHRoYXQgdGhlIG1ldGhv ZCBpcyBhY2NlcHRlZCBhbmQgaXMgd2FpdGluZyB0byBiZSBwcm9jZXNzZWQgYnV0DQo+ID4gIGFs c28gdGhlIEhUVFAgY29ubmVjdGlvbiBjb3VsZCBiZSB0ZXJtaW5hdGVkIChpZiBuZWVkZWQpLiBN b3Jlb3ZlciBpdA0KPiA+ICB3b3VsZCBwcm92aWRlIG1lYW5zIGZvciB0aGUgY2xpZW50IHRvIHBv bGwgdGhlIHN0YXR1cyBvZiB0aGUgcmVxdWVzdCBhdA0KPiA+ICB0aGUgVVJJIHByb3ZpZGVkIGlu IHRoZSBMb2NhdGlvbiBoZWFkZXIgb2YgMjAyIEFjY2VwdGVkLg0KPiA+DQo+ID4gIFNpZGUgbm90 ZTogVGhlIFJFU1RDT05GIGRyYWZ0IGxpc3RzIHRoZSBIVFRQIG1ldGhvZCAyMDIgQWNjZXB0ZWQg YXMgd2VsbA0KPiA+ICBpbiBjaGFwdGVyIDcsIGJ1dCBpdCBkb2VzIG5vdCBkZWZpbmUgYW55IHNl bWFudGljcy4gIA0KPiA+DQo+ID4gVGhhbmsgeW91IGluIGFkdmFuY2UgZm9yIHlvdXIgY29tbWVu dHMuDQo+DQo+DQo+ICBTbyB5b3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCBhIHNlcnZlciBjYW4gb3B0 aW9uYWxseSBzdXBwb3J0IDIwMiBBY2NlcHRlZCwNCj4gIHdoaWNoIG1lYW5zIG9mIGNvdXJzZSBp dCBpcyBtYW5kYXRvcnkgdG8gc3VwcG9ydCBmb3IgdGhlIGNsaWVudC4NCj4NCj4gIFRoZXJlIHNl ZW1zIHRvIGJlIHNvbWUgaW50ZXJlc3QgaW4gdGhlIElFVEYgcmlnaHQgbm93IHdydC8gY2xhcmlm eWluZyB3aGF0IGl0DQo+ICBtZWFucyB3aGVuIHRoZSBzZXJ2ZXIgcmV0dXJucyA8b2svPiB0byBh biBlZGl0IHJlcXVlc3QuICBJZiBpdCBtZWFucyAieW91ciBlZGl0DQo+ICBpcyBwYXJ0IG9mIHRo ZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIiB0aGVuIDIwMiBBY2NlcHRlZCBpcyBub3QgcmVhbGx5 IG5lZWRlZCBhcw0KPiAgYW55IGRlY2VudCBzZXJ2ZXIgY2FuIGRvIHRoaXMgd2l0aG91dCBkZWxh eS4gIElmIGl0IG1lYW5zICJ5b3VyIGVkaXQgaXMgbm93DQo+ICByZWZsZWN0ZWQgaW4gYWN0dWFs IG5ldHdvcmsgYmVoYXZpb3IiIHRoZW4gcGVyaGFwcyBpdCB3aWxsIGJlIHVzZWZ1bC4NCg0KVGhl IDIwMiBBY2NlcHRlZCB3b3VsZCBtZWFuIHRoYXQgdGhlIHNlcnZlciBzdGFydGVkIHRvIHByb2Nl c3MgdGhlIGVkaXQgcmVxdWVzdC4NCllvdSdyZSByaWdodCB0aGF0IGEgZGVjZW50IHNlcnZlciBj b3VsZCBpbW1lZGlhdGVseSByZXNwb25kIHdpdGggYSAyMDEgQ3JlYXRlZCwNCmJ1dCB0aGVyZSBh cmUgY2FzZXMgd2hlcmUgdGhlIHVuZGVybHlpbmcgKGFuZCBub3Qgc28gZGVjZW50KSBzeXN0ZW0g YWxzbyBkb2VzDQpzb21lIHZhbGlkYXRpb24gYW5kIHByb3Zpc2lvbmluZyB3b3JrLCB0aGF0IGNv dWxkIGVhc2lseSBkZWxheSB0aGUgd2hvbGUgb3BlcmF0aW9uLg0KDQpUaGUgc3RhdHVzIG9mIHRo ZSBlZGl0IHJlcXVlc3QgKGUuZy4gaXMgaXQgdW5kZXIgcHJvY2Vzc2luZywgYXBwbGllZCB0byB0 aGUgc3lzdGVtDQpvciByZWplY3RlZCkgY291bGQgYmUgaW5kaWNhdGVkIHRocm91Z2ggdGhlIHN0 YXR1cyBVUkkgdGhhdCBpcyBwcm92aWRlZCBpbg0KdGhlIDIwMiBBY2NlcHRlZC4NCg0KDQo+DQo+ DQo+ICAgDQo+ID4gIEJlc3QgcmVnYXJkcywNCj4gPiAgLUJhbGludA0KPg0KPiAgQW5keQ0KDQpC ciwNCi1CYWxpbnQNCg== From nobody Fri Oct 2 07:45: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 8BFF61B2BD4; Fri, 2 Oct 2015 07:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.399, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju-iIHgPqWrx; Fri, 2 Oct 2015 07:45:54 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 E2AE71A6F61; Fri, 2 Oct 2015 07:45:53 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so37260071wic.0; Fri, 02 Oct 2015 07:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=SSLBZ680a2iYMcPAcULsKrPBxsMQWwVm5tuMf9ymr5Q=; b=rFj6SAkyfLQ4eEIYsAqqoKkvpPWgU3ICAO50x1IpoEALAiUXg8KURNHeZYS0Cs9IM3 4TpLm2AnAy6Pjlps9QItjoEft96cBX8tHrOjoVlRwPjFYXi0NIAbWIuhsLf+iFYBsJ2w MuWukFUr27tusxalWtTZOtRr2obg1ID+3GeagG/Kgyx7W4FMK2ocYT/52TrodJqkYtDQ XehHOD1bBQbLq0TAnTFwmC0wGUkya8cvmJwFomndH9RfLXhuMOYRfE7PTrcvHbo4aZcY XNEYHbGEzfxv5ZnBPromPcKAMyNi0lluV9AyWYObATUk2VAEIpIHs99LPXtW0vyl3oya KlTw== MIME-Version: 1.0 X-Received: by 10.180.23.134 with SMTP id m6mr5096215wif.32.1443797152387; Fri, 02 Oct 2015 07:45:52 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.88.98 with HTTP; Fri, 2 Oct 2015 07:45:52 -0700 (PDT) In-Reply-To: <004201d0e5e0$280537d0$780fa770$@ndzh.com> References: <005101d0e4d8$fb07ddd0$f1179970$@ndzh.com> <4A95BA014132FF49AE685FAB4B9F17F657D1D986@dfweml701-chm> <004201d0e5e0$280537d0$780fa770$@ndzh.com> Date: Fri, 2 Oct 2015 10:45:52 -0400 X-Google-Sender-Auth: bN38larIUzZAsmeLrnW6H_91mMA Message-ID: From: Daniel Migault To: Susan Hares Content-Type: multipart/alternative; boundary=e89a8f6430cc655a690521203808 Archived-At: Cc: i2rs@ietf.org, Netconf , Linda Dunbar Subject: Re: [Netconf] [i2rs] 1 week extension to WG Adoption call for draft-mglt-i2rs-security-environments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 02 Oct 2015 14:45:57 -0000 --e89a8f6430cc655a690521203808 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Linda, Thank you for your feed back. We considered them - with all other feed backs we receievd. We beleive the new version address all of them. Feel free to let us know if we missed something. Here is a small recap of the modifications performed to address your comments. BR, The co-authors Comments / Responses for Linda's comments: - Communication channel between I2RS client and Agent (and the channel between I2RS client and applications): The channel can be o Via physical Private network (e.g. within a secured direct connect within one site), o within one administrative domain, via virtual private network o Secured connection, such as TLS or IPSec o Public internet o .. MGLT: Thank for the clarification. I think that our REQ1 catches these aspects as a way to isolate the I2RS plane from other. For communications themselves, this version mostly redirects to hares-securtity I-D.hares-i2rs-auth-trans. Please let me know if you think we do not address your purpose. - Authentication & Authorization o the authentication & authorization requirement for different communication channels can be different. Therefore, should have separate sections to address specific requirement for each communication channels between I2RS agent <-> clients (and client <-> applications) MGLT: Thank you for the comment. We have re-written the section 4 and I hope the current section 4 on access control considers these aspects with the following sections: 4.1. I2RS Access Control architecture . . . . . . . . . . . . 8 4.2. I2RS Agent Access Control policies . . . . . . . . . . . 12 4.3. I2RS Client Access Control policies . . . . . . . . . . . 13 4.4. Application and Access Control policies . . . . . . . . . 14 The current Section 4 of the draft already has very good description on the subject. I think 4.4.1 and 4.42 can be separated out of the section. MGLT: Thank you for pointing out the split. the section 4.4 has been removed and outsourced to the I2RS Access Control and in the draft-ietf-ares-protocol security requirements draft. - Encryption for the actual content between Client and Agent MGLT: Similarly, we have moved to the I2RS Access Control and in the draft-ietf-ares-protocol security requirements - DoS Design requirement (currently in Section 5.2.1) - Management of conflict with other plane (e.g. the management plane, multi-headed control, which has been discussed extensively in ephemeral draft) MGLT: The reference to the draft has been added. However, the recommendations were mostly pointing to the text from the i2rs architecture document. I think the draft should be organized from the aspects of the security to I2RS as suggested above. Here are some detailed questions and comments to the requirements listed in the document: Section 1: The second paragraph stated the security recommendations must =C3=A2=E2=82= =AC=C5=93specifying where security functions may be hosted=C3=A2=E2=82=AC=C2=9D. First of all I= don=C3=A2=E2=82=AC=E2=84=A2t see the draft address this aspect. Second, I think =C3=A2=E2=82=AC=C5=93where sec= urity functions are hosted=C3=A2=E2=82=AC=C2=9D is orthogonal to =C3=A2=E2=82=AC=C5=93I2RS = security=C3=A2=E2=82=AC=C2=9D . MGLT: I agree with your comment and we have removed the text from the section. Section 3: what does isolating two planes mean? does it mean they have different security requirement/issues? Or does it mean they need different protocols? MGLT: Each plane has a specific scope of function. What are the key differences with regard to the security requirements for = I2RS plane and for management plane? Section 3.1 describes the interaction between I2RS plane and management plane. But I see the security requirement for the management plane is similar to I2RS plane . If you think that they are very different, can you elaborate more? MGLT: Thanks for the remark. Here is the text we added. Feel free to us know is you think it is not clear enough. "The I2RS plane purpose is to provide a standard programmatic interface of the routing system resources to network oriented applications. Control plane and forwarding planes are related to routing protocols, and I2RS is based on top of those. The management plane is usually vendor specific, provides a broader control over the networking equipment such as system service. Given its associated privileges it is expected to be reserved to highly trusted users like network administrators." Section 3.4 has title =C3=A2=E2=82=AC=C5=93Recommendations=C3=A2=E2=82=AC= =C2=9D, but the content are all requirements. Why not name the section =C3=A2=E2=82=AC=C5=93Requirement=C3= =A2=E2=82=AC=C2=9D? MGLT: I prefer "Recommendation" at least for this section, as the way they are implemented and enforce vary widely according to the environment. However, I am open for discussion, and it could be moved to Requirements in the future. REQ 2: Does it that a different IP address than the one used by the management system? MGLT: Yes, we recommend that having a dedicated IP address or dedicated NIC to enforce isolation. How is REQ 22 different from REQ 21? MGLT: Agree, they are very closed. We have outsourced these requirements to the transport requirements. REQ 27 is hard to enforce. How about say something like "shouldn't send any information beyond what have been defined by the I2RS data model"? MGLT: Agree. This is much better. However, we have outsourced this requirements to the transport requirements. REQ 30: simply controlling the resource can hardly prevent DoS. Malicious client can occupy the resource while the valid one can't access. MGLT: This is true, however, what I meant here was to control resource so one tenant does not over consume resources. On Wed, Sep 2, 2015 at 8:33 PM, Susan Hares wrote: > Linda > > > > We will include closed environments in the revised document. > > > > Sue > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Linda Dunbar > *Sent:* Wednesday, September 02, 2015 12:54 PM > *To:* Susan Hares; i2rs@ietf.org > *Cc:* 'Jeffrey Haas'; 'Netconf' > *Subject:* Re: [i2rs] 1 week extension to WG Adoption call for > draft-mglt-i2rs-security-environments > > > > Can the authors address my comments and the suggested changes to add a > section on security threats and the associated requirements with Closed > Environment? > > > > Closed environment deployment can easily give people a sense of secure > because the links between I2RS Client and I2RS Agent are guided by a > physical =E2=80=9CWall=E2=80=9D. The false sense of =E2=80=9CSecure=E2= =80=9D is actually more dangerous > because it can easily make the deployment miss the crucial security > procedure. > > > > Therefore, I think it is important to have a dedicated section on securit= y > threats and requirement for the Closed Environment. > > > > Attached is my suggested text. > > > > Linda > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org ] *On > Behalf Of *Susan Hares > *Sent:* Tuesday, September 01, 2015 12:10 PM > *To:* i2rs@ietf.org > *Cc:* 'Jeffrey Haas'; 'Netconf' > *Subject:* [i2rs] 1 week extension to WG Adoption call for > draft-mglt-i2rs-security-environments > > > > This is a 1 week extension to the WG adoption call for > draft-mglt-i2rs-security. Due error in the initial call email, the exact > text to review was unclear ( > https://mailarchive.ietf.org/arch/msg/i2rs/wwv1o8_mwurB05dN4D2yjr9tNFg). > > > > In reviewing the email, it appears that the authors have agree to change > or delete most of the concerns except for combining this draft with > draft-hares-i2rs-auth-trans-04.txt. The chairs have decided to adopt bo= th > drafts as WG drafts, and make a subsequent WG calls to determine if the > drafts should be combined. > > > > This draft is at: > > > > https://www.ietf.org/id/draft-mglt-i2rs-security-environment-reqs-00.txt > > > > Daniel has indicated several changes on the list. If you would like to > see a revised draft for further comments, please indicate this on the lis= t. > > > > Sue Hares and Jeff Haas > > I2RS co-chairs > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --e89a8f6430cc655a690521203808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Linda,

Thank you for your = feed back. We considered them - with all other feed backs we receievd. We b= eleive the new version address all of them. Feel free to let us know if we = missed something. Here is a small recap of the modifications performed to a= ddress your comments.

BR,
The co-authors

Comments / Responses for Linda's comments:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Communication channel between I2RS client and Agent (and the channel between I2RS client and applications): The channel can be

o=C2=A0=C2=A0 Via phy= sical Private network (e.g. within a secured direct connect within one site),

o=C2=A0=C2=A0 within = one administrative domain,=C2=A0 via vi= rtual private network

o=C2=A0=C2=A0 Secured connection, such as TLS or IPSec

o=C2=A0=C2=A0 Public = internet

o=C2=A0=C2=A0 ..

=C2=A0

MGLT: Thank for the clarification.=C2=A0 I think that our REQ1 catches these aspects as a way to isolate the I2RS plane from other. For communications themselve= s, this version mostly redirects to hares-securtity=C2=A0 I-D.hares-i2rs-auth-trans. Please let me know if you think we do not address your purpose.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Authentication & Authorization

=C2=A0

o=C2=A0=C2=A0 the authentication & authorization requirement for different communication channels can be different. Therefore, should have separate sections to addr= ess specific requirement=C2=A0 for each communication channels between I2RS agent <-> clients (and client <-> applications)

=C2=A0

MGLT: Thank you for the comment. We have re-written the secti= on 4 and I hope the current section 4 on access control considers these aspect= s with the following sections:

=C2=A0=C2=A0=C2=A0=C2=A0= 4.1.=C2=A0 I2RS Access Cont= rol architecture=C2=A0 . . . . . . = . . . . . .=C2=A0=C2=A0 8

=C2=A0=C2=A0=C2=A0=C2=A0 4.2.=C2=A0 I2RS Agent Access Co= ntrol policies=C2=A0 . . . . . . . = . . . .=C2=A0 12

=C2=A0=C2=A0=C2=A0=C2=A0 4.3.=C2=A0 I2RS Client Access C= ontrol policies . . . . . . . . . . .=C2=A0 13

=C2=A0=C2=A0=C2=A0 =C2=A04.4.=C2=A0 Application and Access Control policies . . . . . . . . .=C2=A0 14

=C2=A0

The current Section 4 of the draft already has very good description on the subject. I think 4.4.1 and 4.42 can be separated out of = the section.

=C2=A0

MGLT: Thank you for pointing out the split. the section 4.4 has been removed and outsourced to the I2RS Access Control and in the draft-ietf-ares-protocol security requirements draft.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Encryption for the actual content between Client and Agent

=C2=A0

MGLT: Similarly, we have moved to the=C2=A0 I2RS Access Control and in the draft-ietf-ares-protocol security requirements

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 DoS Design requirement (currently in Section 5.2.1)

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Management of conflict with other plane (e.g. the management plane, multi-headed control, which has been discussed extensively in ephemeral dra= ft)

=C2=A0

MGLT: The reference to the draft has been added. However, the recommendations were mostly pointing to the text from the i2rs architec= ture document.

=C2=A0

=C2=A0

I think the draft should be organized from the aspects of the security to I2RS as suggested above. Here are some detailed questions a= nd comments to the requirements listed in the document:

=C2=A0

Section 1:

=C2=A0

The second paragraph stated the security recommendations must =C3=A2=E2=82=AC=C5=93specifying where security functions may be hosted= =C3=A2=E2=82=AC=C2=9D. = First of all I don=C3=A2=E2=82= =AC=E2=84=A2t see the draft address this aspect. Second, I think=C2=A0=C2=A0 =C3=A2=E2=82=AC=C5=93w= here security functions are hosted=C3=A2=E2=82=AC=C2=9D is orthogonal to =C3=A2= =E2=82=AC=C5=93I2RS security=C3=A2=E2=82=AC=C2=9D .

=C2=A0

MGLT: I agree with your comment and we have removed the text from the section.

=C2=A0

Section 3:

=C2=A0

what does isolating two planes mean? does it mean they have different security requirement/issues? Or does it mean they need diffe= rent protocols?

=C2=A0

MGLT: Each plane has a specific scope of function.=C2=A0

=C2=A0

What are the key differences with regard to the security requirements for=C2=A0 I2RS plane a= nd for management plane?=C2=A0 Section 3.1= describes the interaction between I2RS plane and management plane. But I see the secu= rity requirement for the management plane is similar to I2RS plane . If you thin= k that they are very different, can you elaborate more?

=C2=A0

MGLT:=C2=A0 Thanks fo= r the remark. Here is the text we added. Feel free to us know is you think it= is not clear enough.

"The I2RS plane purpose is to provide a standard programmatic interface of the routing system resources to network oriented applications. Control plane and forwarding planes are related to routing protocols, and I2RS is based on top of those. The management plane is usual= ly vendor specific, provides a broader control over the networking equipment s= uch as system service. Given its associated privileges it is expected to be reserved to highly trusted users like network administrators."

=C2=A0

=C2=A0

Section 3.4 has title =C3=A2=E2=82=AC=C5=93Recommendations=C3= =A2=E2=82=AC=C2=9D, but= the content are all requirements. Why not name the section =C3=A2=E2=82=AC=C5=93Requirement=C3=A2=E2=82=AC=C2=9D?

MGLT: I prefer "Recommendation" at least for this section, as the way they are implemented and enforce vary widely accor= ding to the environment. However, I am open for discussion, and it could be move= d to Requirements in the future.

=C2=A0

REQ 2: Does it that a different IP address than the one used by the management system?

=C2=A0

MGLT: Yes, we recommend that having a dedicated IP address or dedicated NIC to enforce isolation.=C2=A0

=C2=A0

How is REQ 22 different from REQ 21?

=C2=A0

MGLT: Agree, they are very closed. We have outsourced these requirements to the transport requirements.

=C2=A0

REQ 27 is hard to enforce. How about say something like "shouldn't send any information beyond what have been defined by t= he I2RS data model"?

=C2=A0

MGLT: Agree. This is much better. However, we have outsourced this requirements to the transport requirements.

=C2=A0

REQ 30: simply controlling the resource can hardly prevent DoS. Malicious client can occupy the resource while the valid one c= an't access.

MGLT:

This is true, however, what I meant here was to control resource so one tenant does not over consume resources.=C2=A0



On Wed, Sep 2, 2015 at 8:33 PM,= Susan Hares <shares@ndzh.com> wrote:

Linda

<co-author hat on&= gt;

We will include closed environments in the revised document. =

<= /u>=C2=A0

Sue

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Wednesday, September 02, 201= 5 12:54 PM
To: Susan Hares; i2rs@ietf.org
Cc: 'Jeffrey Haas'; '= Netconf'
Subject: Re: [i2rs] 1 week extension to WG Adoption = call for draft-mglt-i2rs-security-environments

=C2=A0<= /p>

Can the authors add= ress my comments and the suggested changes to add a section on security thr= eats and the associated requirements =C2=A0with Closed Environment?<= u>

=C2=A0

Closed environment deployment can easily give people a sense of secure = because the links between I2RS Client and I2RS Agent are guided by a physic= al =E2=80=9CWall=E2=80=9D.=C2=A0 The false sense of =E2=80=9CSecure=E2=80= =9D is actually more dangerous because it can easily make the deployment mi= ss the crucial security procedure.

=C2=A0

Therefore, I think it is imp= ortant to have a dedicated section on security threats and requirement for = the Closed Environment.

=C2=A0

Attached is my suggested text. <= u>

=C2=A0

Linda

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, September 01, 2015 1= 2:10 PM
To: i2= rs@ietf.org
Cc: 'Jeffrey Haas'; 'Netconf'
= Subject: [i2rs] 1 week extension to WG Adoption call for draft-mglt-= i2rs-security-environments

=C2=A0

This is a 1 week = extension to the WG adoption call for draft-mglt-i2rs-security.=C2=A0 Due e= rror in the initial call email, the exact text to review was unclear ( https://mailarchive.ietf.org/arch/msg/i2rs/wwv1o8_mwu= rB05dN4D2yjr9tNFg).

=C2= =A0

In reviewing the email, it appears tha= t the authors have agree to change or delete most of the concerns except fo= r combining this draft with draft-hares-i2rs-auth-trans-04.txt. =C2=A0=C2= =A0The chairs have decided to adopt both drafts as WG drafts, and make a su= bsequent WG calls to determine if the drafts should be combined. =

=C2=A0

This draft is at: =C2=A0

=C2=A0<= u>

https:/= /www.ietf.org/id/draft-mglt-i2rs-security-environment-reqs-00.txt

=C2=A0

Daniel has indicated several changes on the list.=C2=A0 If you would= like to see a revised draft for further comments, please indicate this on = the list.

=C2=A0

=

Sue Hares and Jeff Haas

I2RS co-chairs

=C2= =A0= =C2=A0


_________= ______________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs


--e89a8f6430cc655a690521203808-- From nobody Fri Oct 2 13:28: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 2258E1B2D46 for ; Fri, 2 Oct 2015 13:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxdKXwPChy89 for ; Fri, 2 Oct 2015 13:28:37 -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 263111B2D30 for ; Fri, 2 Oct 2015 13:28:37 -0700 (PDT) Received: by lafb9 with SMTP id b9so10576211laf.0 for ; Fri, 02 Oct 2015 13:28:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=fRQ+siGQvaLvT3LnD1rw32WG2p1q1Y+GDrM/9Nemtcg=; b=Jjr25XkDFqFT0lRWvk/RqBpzjQtcKyeLcGvem7ZaVi9OK3mgk0tYvttkkdO4M6Awyd +9NTJ/y+SiyPjhskmiVEdPmfnHRGMFywTWxp98xfiP6QXMKhVwdItCLeonO3DcBVUNcA ypnd7Le7YA2J6TINiXXkuSpwYtbsef1tgwmN9cETgpuia5DDOrIlRpWhbEr67Kw+G6cg MqglKUY/R1p7q9kOi+r1bsbCWjtPUVLJXAiobsjixQFVgc0FB/aeXGHesBUgyCzcD63S GcLnM88jo4FoYHFgkzsZY9BLLe+Dyj0c18mXqQmSmLvwStlS/1HzwrvWx9fJWJBzKhlD 28iQ== X-Gm-Message-State: ALoCoQmEPjuXC15Rf1liLpK4C5LFK6iYpE2/SKKNhbfUDLHws9d4OrPhLizzyiznfKy/FbBfhpU5 MIME-Version: 1.0 X-Received: by 10.112.200.229 with SMTP id jv5mr6498670lbc.123.1443817715424; Fri, 02 Oct 2015 13:28:35 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Fri, 2 Oct 2015 13:28:35 -0700 (PDT) Date: Fri, 2 Oct 2015 13:28:35 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c266500c79fe0521250230 Archived-At: Subject: [Netconf] NETCONF warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 02 Oct 2015 20:28:39 -0000 --001a11c266500c79fe0521250230 Content-Type: text/plain; charset=UTF-8 Hi, The issue of warnings keeps coming up with customers. Technically, there are no error-tags that have an assigned error-severity of 'warning'. The message is supposed to use 1 of the standard error-tags. So how should the server send warnings in NETCONF? A) new message like B) new error-tag with assigned severity 'warning' C) pick an existing error-tag to allow as a warning D) allow any error-tag to be severity warning E) something else? Andy --001a11c266500c79fe0521250230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The issue of warnings keeps coming = up with customers.
Technically, there are no error-tags that have= an assigned
error-severity of 'warning'. The <rpc-err= or> message is
supposed to use 1 of the standard error-tags.

So how should the server send warnings in NETCONF?<= /div>

=C2=A0A) new message like <rpc-warning>
=C2=A0B) new error-tag with assigned severity 'warning'
=
=C2=A0C) pick an existing error-tag to allow as a warning
= =C2=A0D) allow any error-tag to be severity warning
=C2=A0E) some= thing else?



Andy

--001a11c266500c79fe0521250230-- From nobody Sat Oct 3 04:34: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 95A871B361D for ; Sat, 3 Oct 2015 04:34:56 -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, 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 Xe-owTEZlw1T for ; Sat, 3 Oct 2015 04:34:54 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E351B361C for ; Sat, 3 Oct 2015 04:34:52 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (31.54.179.163) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.280.20; Sat, 3 Oct 2015 11:34:32 +0000 Message-ID: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Netconf References: Date: Sat, 3 Oct 2015 12:34:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [31.54.179.163] X-ClientProxiedBy: AM3PR04CA0102.eurprd04.prod.outlook.com (25.163.180.156) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB061; 2:VhuT0yU3KuBnk+BmxUIioinlTQAuH4rPnYrTidJpKEdJxVEW9ILzUp3mXmUxCkfsOUB5v0w/CKHdMxqqRDCrQjbnrNtRmTIl9eHH9bmbAvkJJEgvf1x8v6mDdki8W/t4wBtVUOJkGrnkQbHMiitvIlR6Tdyr9zviBLazUs79vjM=; 3:ThwUA32nN6t9rNU956vauvKfq094SuDuhtKKhiKN9Ce0wr/o6doctpMiNmwGEzqIu8g5QtvLoL17vK6SF+1/haZE5pwLqsD+KG5IkYejQVbn0C7R8QgMn5dT46lEqEwHs0PEeZw2LwN1/CFKkawGVw==; 25:Flk87WCoXHX5A4rQnk8JGZAPJRXt3darrcQx+dFvYMDsxgjOON8D3KJZC2pPS5rM0NwuscXwYzv0g7ZR/hIZM78Qr4UJQP8hTVxhMb+BErVsW67NYHpDvXfdzhaxjPXQ97ZvBJdvxWh+bnTdKYTSFb3tyW14L3VRsJLyUn662wBcbztu4LdO52a1gRllod0tjrc+rvAK0eAdz9phiIoUr6ik5zuk7Zdezr/2u1BMeqS4yME5YP7WRvISPguNfehnlg6lWOgbx8SoSxNxma7M0A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:DBXPR07MB061; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB061; X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB061; 4:2drWhAe2P+Yhumbh6Hm/kMRGqjdv+NCEpzdU+9WnsyoogpexeM1rfDmEt81fmNoUqp7P+orTJBD42+axKwnaXuShalQvDfYAi60A+vX6Z4QfU9j85NIWq4h1lHQSbV3RM4IRmIp/66M+iM93xaeUKXBi2i4yTS3iET32JwU0VXj0/0+dfMNnII8B1tG/zmS6gKLw1IP6A3/0RNHXp+y264lUM21gOpryVQtLg+lyWBDbfg/3ptXkhfwHZKmQNisdw1IR2gkHvhXXyenAQeZPF8b6MAILT1bxORH06Z/PH6kSqYzs7fMLfGvlEDjEcT0FiqGGREgsI36+NjH7CGjIwMuwcOVWdFSZKTTEI2f906s= X-Forefront-PRVS: 0718908305 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(377454003)(189002)(33646002)(5007970100001)(68736005)(5001960100002)(122386002)(40100003)(77096005)(97736004)(5004730100002)(1456003)(107886002)(15975445007)(92566002)(81816999)(62966003)(76176999)(46102003)(189998001)(4001540100001)(77156002)(81686999)(105586002)(50466002)(23676002)(19580405001)(5001770100001)(5001830100001)(81156007)(5008740100001)(19580395003)(5001860100001)(14496001)(47776003)(42186005)(66066001)(44716002)(62236002)(64706001)(50986999)(44736004)(106356001)(50226001)(84392001)(87976001)(86362001)(101416001)(61296003)(116806002)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQlhQUjA3TUIwNjE7MjM6SEVIVjNRQnFWbEFuMXZISDNhUUVISklNYmlQ?= =?utf-8?B?Y1h2RHZOdUpVenRHM1kzcmZadHhRWTdiRnBQeWdxTUxiM2xFZ0U2YTM2OUNF?= =?utf-8?B?MGZlVTh0bVhoclg5Z3hxbU96dGZ3dXVtbDVPZ0tuSEJva3pTSUpmYlFjazV2?= =?utf-8?B?S0pmcVkxTWVSNWhQRGNLUXZubDNFdko4S2lKM0pOSTJZOFFQOWloS1I5UHAy?= =?utf-8?B?UVpvM0ZEQUs3VXVMdU8yVXhHblp4V2RLZGwzN1U4N3NNVXhRdTh3blZEdmVI?= =?utf-8?B?bHpYRlEyRmtSaXNDL1lXVzdseWt5U1RreWFGWkppT3FiN2lTemFiaTc4Wm1Y?= =?utf-8?B?WjQ3VzlsOE96T0JiNm5XZXJIL0lZd05zWWNqTHlNSkYxOUVGeGxnT2w2K0sv?= =?utf-8?B?aHQ0OHFjNFRZbjkwWTUzRUxPd2RiaHdYVU5vR0VZRHVWMWM4RCtTZ3BhRDJm?= =?utf-8?B?eWxWbStYMm5jYlh4RFJ1VFU1ZDdpaVpOSld0dnlOUXRSR0EvZ0YyU08rMmZk?= =?utf-8?B?TGJOWHBqV0RpbHRLMmtjT3k4WksrOWRGSzB6b3hjSUx5V3VtS3NPUjZleWxr?= =?utf-8?B?Nnc3bDh4Rzl3RVNBTFF0OW9RVFlqOEErOG1yVkJpMXdYTHR2TE0xMzRsRzc2?= =?utf-8?B?blNVVHNEL3MvVzNvdyt3SzFwMWZYODRlR2RIN0ZHWDMwQUhQVkVtRTR5MWtU?= =?utf-8?B?d0ptSlhJZU5LMEpIQlRWOEJOQTNkejkyN3hqQjFMSmZKcFFScGFoUHZIM25v?= =?utf-8?B?Nk1MWnJjRFc1Vnh4dlVsWXVVN09sOCtOVmFVWE5kNzFnZU9XL3kyWURiSmJW?= =?utf-8?B?LzY4QnFmWVJJczVZR2Qyblh2UzFHeTBnN0hDRXZ4L2tRc2NtbnFmMkFBSGQ2?= =?utf-8?B?WGdzK2U2bUI4WUxtTzU3MmhFdkM1ZnV5VE9ySVVsb0hTZjNmZnQrOEpFNHJZ?= =?utf-8?B?VnRwMEtIdmN0Nndaem16M0xJdzF5ODRHeE1nUWpIVDRvdlZUOGx3dXJaMysz?= =?utf-8?B?dklrbnlVcE1vbmRMWTQvWGJxUzBDNWxoV2w5Qjg5SEFudHVQL0R4VHlSa0FX?= =?utf-8?B?OEZ1WldCanNJWjcxZlpxV0VPSnJ3dnJWQzJOYXdTblJOOVZLZEVRZEs0Z3JO?= =?utf-8?B?T3ljWVh0TmRJZU1SbHJaOVpkTHErTC9HN3VnU1lWWHJwVGFaNnlVQWREY1NF?= =?utf-8?B?dUEvQXl2ay95eXNBdmIxdTNZbkhyYlBOTXdPaW9iUVhGcVZGbmFBQ0Vzam50?= =?utf-8?B?VzVRdWhEUXEzSlNOb2ZIY1JGcjFBaDhVd1FrY1kvcWtuajhyaFBic0pLZ3JX?= =?utf-8?B?WUVFWGJMQXo5c1g2eEwwdlMvQU90SGloeFB3UlV6ZE50OXNoMGZ3dlJBYndO?= =?utf-8?B?SFA4dFhjd3N0R1paMC9pR01xSlczRTZaYVZJUlZONFljKzZQYi9PWHJsUlE3?= =?utf-8?B?cXorYXQvaW4wUEtrb2Q0azBEb1BlbENyZ0FJWTdJZlZjOU9aMEVVRCs0QWYv?= =?utf-8?B?TkxnYzl4TjRlMk1ZSWNPb3dBYVVVdlNOVU1aSXNqNHlYdFhmR0k5Tnhsc2pr?= =?utf-8?B?d2thTkZUTVVESHhVS1B4NjdQVFYvWVl4TFMreExEZ0NQWE1UeHdpTkJUNk9t?= =?utf-8?B?ZkltbXpIVGN3YnFFTEkvckZIaklmYWt3K0hqZmRjTFFuc056dnVCMXBYVzlh?= =?utf-8?B?OVd3NHpiTzhQVjlOdXhMM0pMZS9xZ0RRcm9wMlc5eHJCN0V3SXRsQ2kzUG8z?= =?utf-8?B?UWZLTWRhd29lK0Q5QTgxNXE5R2FYMTRTUWFHOHdoZEhQZWNQT1I2eWl1bnpU?= =?utf-8?B?dzV5enc5RXlzQmc2U3pwRkNqaWx4eExSbmhuZUhmdGFhZEJNcytweGhnT3N6?= =?utf-8?B?R3dTREFTazZmemVTdXRJT1BIVS9mVVU3UHFUdExKckhWY0hiL0RLQTVBeDdq?= =?utf-8?B?ZXhPQ05DUU5FczNHa1pJd213czMzR2tzcHlmZTdzSVNYQlRVTm9lbmQ2QTVp?= =?utf-8?Q?/zK8s?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB061; 5:nfns4kYTNgtR71AGJUgmo9Th7TiNOdOhMa05EKO+xp921R6b4SKC59ZXVt1W08ug42FOmCQUKqsptC1vIiwdp5ScQK0L5WyZz71gaJw/HDI3HmP9HhE/aP3VqzvxFD/5IybjnRAzYH9HIhcttGeuPw==; 24:p6obi/0X5JT4zs7w7ZjnBN0wtEXu+xIYOUthv11yjBuq4hEthQzFts+DGTgqSmgGDQcRLVay/yyXw1NKn23YFLAyJpb3NLEmvQdpUVuSKNs=; 20:Othqu09L0Sukomv4ntIajomkBkRUfGLCfPL5jaTvzpkvcZRHXhLUHyXA9HEYSD96VbzAAfJCyNCm+0pgerrFHw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Oct 2015 11:34:32.7350 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB061 Archived-At: Subject: Re: [Netconf] NETCONF warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 11:34:56 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Netconf" Sent: Friday, October 02, 2015 9:28 PM > Hi, > > The issue of warnings keeps coming up with customers. > Technically, there are no error-tags that have an assigned > error-severity of 'warning'. The message is > supposed to use 1 of the standard error-tags. > > So how should the server send warnings in NETCONF? > > A) new message like > B) new error-tag with assigned severity 'warning' > C) pick an existing error-tag to allow as a warning > D) allow any error-tag to be severity warning > E) something else? Depends what you mean by a warning. I have worked with manufacturers that have a clearly defined hierarchy of, say, four levels of result, of which warning is one. Other manufacturers take a different view. Another slant on this is the various return codes of e.g HTTP. So first I would like the semantics of 'warning' clarified, then I can make an informed choice. Tom Petch > > > > Andy > ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Sat Oct 3 07:32: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 876001B29C7 for ; Sat, 3 Oct 2015 07:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bttvHjRit94s for ; Sat, 3 Oct 2015 07:32:33 -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 C86BC1B29C4 for ; Sat, 3 Oct 2015 07:32:32 -0700 (PDT) Received: by lbwr8 with SMTP id r8so38942794lbw.2 for ; Sat, 03 Oct 2015 07:32:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nzcF4DeB1nLST72ZgVyHp+wtsJeNVH9DSKAkA8iFAWw=; b=A9sPXn4JC3fU8ZWvP/vG9C/h4H+xEGBy+DONvdqB1Wij+8GKtChpKlt8Gx3qVxJnJj n542KN2wXgDGqDObJnjDYMvVmhyLzVq9K5Ixj0bpoSf5m8vKAwpQgs6pdV5rvL+xtRhw 7hkXeDuRyxNe2eWuWLlokXWx8lFCevOTyVpiEuAn43i2mhhmjEu8xRGjhayLm8YmWQgv 84ZS2Y4FuncHUE5xFJJnV8d9SyL5XWaPsfBJ3M+MsmyzmyGozJZr2GrJPJEV2vrde9ZJ MVNSXSUfb3FXO+SLnkfZcCz+ZkYPWXAJrzNiyQBjMc1nJyUO08gEBCFbqiqV8z/NaUW+ 2O6w== X-Gm-Message-State: ALoCoQnBS1Q6os/rb2MqrPlJfDEqrQvVCSAQffF9wSmpWQD7jzfriE8XJleIFG3iG8YUuN0+RpGL MIME-Version: 1.0 X-Received: by 10.112.160.138 with SMTP id xk10mr7608503lbb.119.1443882750983; Sat, 03 Oct 2015 07:32:30 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Sat, 3 Oct 2015 07:32:30 -0700 (PDT) In-Reply-To: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> References: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> Date: Sat, 3 Oct 2015 07:32:30 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c38b9078614205213426c3 Archived-At: Cc: Netconf Subject: Re: [Netconf] NETCONF warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 14:32:34 -0000 --001a11c38b9078614205213426c3 Content-Type: text/plain; charset=UTF-8 On Sat, Oct 3, 2015 at 4:34 AM, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "Netconf" > Sent: Friday, October 02, 2015 9:28 PM > > > Hi, > > > > The issue of warnings keeps coming up with customers. > > Technically, there are no error-tags that have an assigned > > error-severity of 'warning'. The message is > > supposed to use 1 of the standard error-tags. > > > > So how should the server send warnings in NETCONF? > > > > A) new message like > > B) new error-tag with assigned severity 'warning' > > C) pick an existing error-tag to allow as a warning > > D) allow any error-tag to be severity warning > > E) something else? > > Depends what you mean by a warning. > > I have worked with manufacturers that have a clearly defined hierarchy > of, say, four levels of result, of which warning is one. Other > manufacturers take a different view. Another slant on this is the > various return codes of e.g HTTP. > > So first I would like the semantics of 'warning' clarified, then I can > make an informed choice. > > > Tom Petch > > > > > > > > > > > Andy > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > --001a11c38b9078614205213426c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 3, 2015 at 4:34 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
----- Original Message -= ----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "Netconf" <netconf@iet= f.org>
Sent: Friday, October 02, 2015 9:28 PM

> Hi,
>
> The issue of warnings keeps coming up with customers.
> Technically, there are no error-tags that have an assigned
> error-severity of 'warning'. The <rpc-error> message is<= br> > supposed to use 1 of the standard error-tags.
>
> So how should the server send warnings in NETCONF?
>
>=C2=A0 A) new message like <rpc-warning>
>=C2=A0 B) new error-tag with assigned severity 'warning'
>=C2=A0 C) pick an existing error-tag to allow as a warning
>=C2=A0 D) allow any error-tag to be severity warning
>=C2=A0 E) something else?

Depends what you mean by a warning.

I have worked with manufacturers that have a clearly defined hierarchy
of, say, four levels of result, of which warning is one.=C2=A0 Other
manufacturers take a different view.=C2=A0 Another slant on this is the
various return codes of e.g HTTP.

So first I would like the semantics of 'warning' clarified, then I = can
make an informed choice.


=C2=A0
Tom Petch



>
>
>
> Andy
>


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


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


--001a11c38b9078614205213426c3-- From nobody Sat Oct 3 07:38: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 424231B29DA for ; Sat, 3 Oct 2015 07:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlrQllxIm4is for ; Sat, 3 Oct 2015 07:38:16 -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 56F5C1B29D7 for ; Sat, 3 Oct 2015 07:38:16 -0700 (PDT) Received: by lalw10 with SMTP id w10so7745539lal.3 for ; Sat, 03 Oct 2015 07:38:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KyemPuyleB2kcAN+h6TEgrWilS98SYgZ6ZXZSu8IK7I=; b=TEe12HiOOVkl7P7V7SdF4xcIM+hbQ1X3L5jyCcqchBw9HOKLuvspioTwFzo/aEHaxw eDBAYX6m01PU95Llo3JyHpePnW5ZeUdVjkrzG2Q3h+NVeBaz9uNQYI/uFS0fTNLTBhsj JR8tqWXPsSTR1Krod9BHXyZufun7y5bKiJW/+0KaIBToi2Nyec/3ISHK480EW9dkEn6J uZlDEiFZ6PGDIBOD/3ISHk9gU2AfO7DQlpgvyMSfXnHObRnGEvhjdZND4LIIPpzE0Q5i VeFPttJavnXqjslacFIrZXfYttHO/l/8/1qE+7/jPrWqzVGfBhaBnr5+fvbTdE2qv43y gjXw== X-Gm-Message-State: ALoCoQkxJejeB5S54pW4OZImByt/qCmCmMXKqs8WKVJHNIs63+FTa0kFH9ArC0YYBfMqJOm0Rlj/ MIME-Version: 1.0 X-Received: by 10.112.200.229 with SMTP id jv5mr7888006lbc.123.1443883094436; Sat, 03 Oct 2015 07:38:14 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Sat, 3 Oct 2015 07:38:14 -0700 (PDT) In-Reply-To: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> References: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> Date: Sat, 3 Oct 2015 07:38:14 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c26650f10afc0521343a42 Archived-At: Cc: Netconf Subject: Re: [Netconf] NETCONF warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 14:38:18 -0000 --001a11c26650f10afc0521343a42 Content-Type: text/plain; charset=UTF-8 Hi, The RFC sways almost nothing about it: error-severity: Contains a string identifying the error severity, as determined by the device. One of: * error * warning Note that there are no values defined in this document that utilize the "warning" enumeration. This is reserved for future use. There is no definition of a warning in the RFC. That would be up to each vendor or would require the WG to define a warning. Currently, the field is just a waste of bandwidth. Andy On Sat, Oct 3, 2015 at 4:34 AM, t.petch wrote: > ----- Original Message ----- > From: "Andy Bierman" > To: "Netconf" > Sent: Friday, October 02, 2015 9:28 PM > > > Hi, > > > > The issue of warnings keeps coming up with customers. > > Technically, there are no error-tags that have an assigned > > error-severity of 'warning'. The message is > > supposed to use 1 of the standard error-tags. > > > > So how should the server send warnings in NETCONF? > > > > A) new message like > > B) new error-tag with assigned severity 'warning' > > C) pick an existing error-tag to allow as a warning > > D) allow any error-tag to be severity warning > > E) something else? > > Depends what you mean by a warning. > > I have worked with manufacturers that have a clearly defined hierarchy > of, say, four levels of result, of which warning is one. Other > manufacturers take a different view. Another slant on this is the > various return codes of e.g HTTP. > > So first I would like the semantics of 'warning' clarified, then I can > make an informed choice. > > Tom Petch > > > > > > > > > > > Andy > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > --001a11c26650f10afc0521343a42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The RFC sways almost not= hing about it:

  error-severity:  Contains a string=
 identifying the error severity, as
      determined by the device.  One of:

      *  error

      *  warning

      Note that there are no <error-tag> values defined in this docum=
ent
      that utilize the "warning" enumeration.  This is reserved f=
or
      future use.

There is no definition of a warning in the = RFC.
That would be up to each vendor or would require the WG to
define a warning.

Currently, the <erro= r-severity> field is just a waste of bandwidth.


Andy

<= br>
On Sat, Oct 3, 2015 at 4:34 AM, t.petch <i= etfc@btconnect.com> wrote:
= ----- Original Message -----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "Netconf" <netconf@iet= f.org>
Sent: Friday, October 02, 2015 9:28 PM

> Hi,
>
> The issue of warnings keeps coming up with customers.
> Technically, there are no error-tags that have an assigned
> error-severity of 'warning'. The <rpc-error> message is<= br> > supposed to use 1 of the standard error-tags.
>
> So how should the server send warnings in NETCONF?
>
>=C2=A0 A) new message like <rpc-warning>
>=C2=A0 B) new error-tag with assigned severity 'warning'
>=C2=A0 C) pick an existing error-tag to allow as a warning
>=C2=A0 D) allow any error-tag to be severity warning
>=C2=A0 E) something else?

Depends what you mean by a warning.

I have worked with manufacturers that have a clearly defined hierarchy
of, say, four levels of result, of which warning is one.=C2=A0 Other
manufacturers take a different view.=C2=A0 Another slant on this is the
various return codes of e.g HTTP.

So first I would like the semantics of 'warning' clarified, then I = can
make an informed choice.

Tom Petch



>
>
>
> Andy
>


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


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


--001a11c26650f10afc0521343a42-- From nobody Mon Oct 5 11:53: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 2FB4C1B335F for ; Mon, 5 Oct 2015 11:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4FokIAnWWyi for ; Mon, 5 Oct 2015 11:53:43 -0700 (PDT) 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 AB3F61B3351 for ; Mon, 5 Oct 2015 11:53:41 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.280.20; Mon, 5 Oct 2015 18:53:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.93]) with mapi id 15.01.0280.017; Mon, 5 Oct 2015 18:53:38 +0000 From: Kent Watsen To: Andy Bierman , t.petch Thread-Topic: [Netconf] NETCONF warnings Thread-Index: AQHQ/VDv+9z4JsF2X0q6etdYO00Mwp5ZpHXGgAAzLQCAAyj0gA== Date: Mon, 5 Oct 2015 18:53:38 +0000 Message-ID: References: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:fHd0Ar6z6BW1P8vrrQfz8y8PPM6ZmTvMM5iopoQ1jF53RYo29IzQmcgI+jruIwfBPtXy+JY9HGiVpeUX0JghIDU4V4dxbakDy6Dr012iMKWuQDDiCvPA8HzYHe88kDIu5C05netmIWKe8qGf0huWsA==; 24:TZ1CRR/5J60WyOtKHHjlt3LFdmpxLUpc6XzOpSoHUiXbgayy46ymmVavbvSjjlk2qm4Fj9pFl4JIG9THNbCXdOYgnHgFX5EOurineY/K74Q=; 20:x5CZN87ppgDUQWa2KQ/GMOwBl0gsALJdLf78h6eQV1nbptpt5cEx3E74AQL4spY3ucEgBJehkzJ2SlszvERswA== 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)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 07200C0526 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(13464003)(189002)(377454003)(199003)(2950100001)(2900100001)(36756003)(50986999)(54356999)(122556002)(5007970100001)(11100500001)(189998001)(16236675004)(87936001)(76176999)(5001770100001)(5008740100001)(83506001)(5004730100002)(5001960100002)(19617315012)(66066001)(101416001)(81156007)(97736004)(4001350100001)(64706001)(105586002)(99286002)(46102003)(10400500002)(5002640100001)(15975445007)(40100003)(102836002)(106116001)(86362001)(19580405001)(92566002)(106356001)(19580395003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D2383D98E43CDkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2015 18:53:38.7296 (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 Subject: Re: [Netconf] NETCONF warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 05 Oct 2015 18:53:45 -0000 --_000_D2383D98E43CDkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The general definition is "error" means the process did not complete wherea= s "warning" means the process completed with issues. That said, I'm unsur= e what happens for continue-on-error: continue-on-error: Continue to process configuration data on error; error is recorded, and negative response is generated if any errors occur. A negative response sounds like an (since we don't have an yet), but I don't see which error-tag would be used for it. If = it's not defined, maybe we use and for it instead? Kent From: Andy Bierman > Date: Saturday, October 3, 2015 at 10:38 AM To: "t.petch" > Cc: "netconf@ietf.org" > Subject: Re: [Netconf] NETCONF warnings Hi, The RFC sways almost nothing about it: error-severity: Contains a string identifying the error severity, as determined by the device. One of: * error * warning Note that there are no values defined in this document that utilize the "warning" enumeration. This is reserved for future use. There is no definition of a warning in the RFC. That would be up to each vendor or would require the WG to define a warning. Currently, the field is just a waste of bandwidth. Andy On Sat, Oct 3, 2015 at 4:34 AM, t.petch > wrote: ----- Original Message ----- From: "Andy Bierman" > To: "Netconf" > Sent: Friday, October 02, 2015 9:28 PM > Hi, > > The issue of warnings keeps coming up with customers. > Technically, there are no error-tags that have an assigned > error-severity of 'warning'. The message is > supposed to use 1 of the standard error-tags. > > So how should the server send warnings in NETCONF? > > A) new message like > B) new error-tag with assigned severity 'warning' > C) pick an existing error-tag to allow as a warning > D) allow any error-tag to be severity warning > E) something else? Depends what you mean by a warning. I have worked with manufacturers that have a clearly defined hierarchy of, say, four levels of result, of which warning is one. Other manufacturers take a different view. Another slant on this is the various return codes of e.g HTTP. So first I would like the semantics of 'warning' clarified, then I can make an informed choice. Tom Petch > > > > Andy > ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --_000_D2383D98E43CDkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <79646569F5158B42BDCCF3ED3EB54DE6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

The general definition is "error" means the process did not = complete whereas "warning" means the process completed with issue= s.   That said, I'm unsure what happens for continue-on-error:

         continue-on-error:  Continue to= process configuration data on
            error; error is recorded, an= d negative response is generated
            if any errors occur.

A negative response sounds like an <rpc-error> (since we don't h= ave an <rpc-warning> yet), but I don't see which error-tag would be u= sed for it.   If it's not defined, maybe we use and <rpc-warning>= ; for it instead?

Kent

From: Andy Bierman <andy@yumaworks.com>
Date: Saturday, October 3, 2015 at = 10:38 AM
To: "t.petch" <ietfc@btconnect.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] NETCONF warn= ings

Hi,

The RFC sways almost nothing about it:

 =
 error-severity:  Contains a string identifying the error severity, as
      determined by the device.  One of:

      *  error

      *  warning

      Note that there are no <error-tag> values defined in this docum=
ent
      that utilize the "warning" enumeration.  This is reserved f=
or
      future use.

There is no definition of a warning in the RFC.
That would be up to each vendor or would require the WG to
define a warning.

Currently, the <error-severity> field is just a waste of bandwid= th.


Andy


On Sat, Oct 3, 2015 at 4:34 AM, t.petch <ietfc@btconnec= t.com> wrote:
----- Original Message -----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "Netconf" <netconf@iet= f.org>
Sent: Friday, October 02, 2015 9:28 PM

> Hi,
>
> The issue of warnings keeps coming up with customers.
> Technically, there are no error-tags that have an assigned
> error-severity of 'warning'. The <rpc-error> message is
> supposed to use 1 of the standard error-tags.
>
> So how should the server send warnings in NETCONF?
>
>  A) new message like <rpc-warning>
>  B) new error-tag with assigned severity 'warning'
>  C) pick an existing error-tag to allow as a warning
>  D) allow any error-tag to be severity warning
>  E) something else?

Depends what you mean by a warning.

I have worked with manufacturers that have a clearly defined hierarchy
of, say, four levels of result, of which warning is one.  Other
manufacturers take a different view.  Another slant on this is the
various return codes of e.g HTTP.

So first I would like the semantics of 'warning' clarified, then I can
make an informed choice.

Tom Petch



>
>
>
> Andy
>


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


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


 --_000_D2383D98E43CDkwatsenjunipernet_-- From nobody Mon Oct 5 12:40: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 C0E7C1B4F45 for ; Mon, 5 Oct 2015 12:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-Sul7yKpUkU for ; Mon, 5 Oct 2015 12:40:24 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 D64971B34A6 for ; Mon, 5 Oct 2015 12:40:24 -0700 (PDT) Received: by padhy16 with SMTP id hy16so45196919pad.1 for ; Mon, 05 Oct 2015 12:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=C2BjxXmPUbpNKvgrIJe9aSUbQGxwUK9IBAp6vFJOOyo=; b=lryykHIp4u5hv1yvTG4odJEz6kbQdWs03NhupyaUUS5aiYRyXN2tr/G/wPprXBAdS9 LGGdFbe9WOh3Tp4zXMv27Hb3AL1X0UYd2fBLxrbNgu2dca/rdbP+8a5NJ3DY414gPcbN 8MjDQiF8ypIR4Tce0UBWuBQMEqdZk0is1Cq7CAofuEFGzFAk6yoOGsNbyPp9WhqpTrpl kOYpJvo7haByuC7sIJtQVSEyScQ3Kk2WYsdDBWEYT8h2FI9Wt5lRefX4tettBYj8Qy8h Alj+x9wQIdMWx87+E5RUvTeWSEyhq8RuO0/Cv7tgnydUwPpjbDtdY71jQCumvFDHOZ7K nr7A== X-Received: by 10.66.61.205 with SMTP id s13mr15593574par.96.1444074024493; Mon, 05 Oct 2015 12:40:24 -0700 (PDT) Received: from [10.157.20.11] ([128.107.241.175]) by smtp.gmail.com with ESMTPSA id qn5sm29083333pbc.74.2015.10.05.12.40.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Oct 2015 12:40:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_69ACEAB7-1330-443C-BB71-D6FC9371DEF2" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Mon, 5 Oct 2015 12:41:19 -0700 Message-Id: <49923B80-97E3-4101-8648-E9931A9BDDCC@gmail.com> References: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> To: Kent Watsen X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Netconf Subject: Re: [Netconf] NETCONF warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 05 Oct 2015 19:40:27 -0000 --Apple-Mail=_69ACEAB7-1330-443C-BB71-D6FC9371DEF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Could we define a set of new error-tags with error-severity as warning = and still use ? What would be the advantage of defining = vs using error-severity of warning within ? > On Oct 5, 2015, at 11:53 AM, Kent Watsen wrote: >=20 >=20 > The general definition is "error" means the process did not complete = whereas "warning" means the process completed with issues. That said, = I'm unsure what happens for continue-on-error: >=20 > continue-on-error: Continue to process configuration data on > error; error is recorded, and negative response is = generated > if any errors occur. >=20 > A negative response sounds like an (since we don't have an = yet), but I don't see which error-tag would be used for = it. If it's not defined, maybe we use and for it = instead? >=20 > Kent >=20 > From: Andy Bierman > > Date: Saturday, October 3, 2015 at 10:38 AM > To: "t.petch" > > Cc: "netconf@ietf.org " > > Subject: Re: [Netconf] NETCONF warnings >=20 > Hi, >=20 > The RFC sways almost nothing about it: >=20 > error-severity: Contains a string identifying the error severity, = as > determined by the device. One of: >=20 > * error >=20 > * warning >=20 > Note that there are no values defined in this = document > that utilize the "warning" enumeration. This is reserved for > future use. >=20 > There is no definition of a warning in the RFC. > That would be up to each vendor or would require the WG to > define a warning. >=20 > Currently, the field is just a waste of bandwidth. >=20 >=20 > Andy >=20 >=20 > On Sat, Oct 3, 2015 at 4:34 AM, t.petch > wrote: >> ----- Original Message ----- >> From: "Andy Bierman" > >> To: "Netconf" > >> Sent: Friday, October 02, 2015 9:28 PM >>=20 >> > Hi, >> > >> > The issue of warnings keeps coming up with customers. >> > Technically, there are no error-tags that have an assigned >> > error-severity of 'warning'. The message is >> > supposed to use 1 of the standard error-tags. >> > >> > So how should the server send warnings in NETCONF? >> > >> > A) new message like >> > B) new error-tag with assigned severity 'warning' >> > C) pick an existing error-tag to allow as a warning >> > D) allow any error-tag to be severity warning >> > E) something else? >>=20 >> Depends what you mean by a warning. >>=20 >> I have worked with manufacturers that have a clearly defined = hierarchy >> of, say, four levels of result, of which warning is one. Other >> manufacturers take a different view. Another slant on this is the >> various return codes of e.g HTTP. >>=20 >> So first I would like the semantics of 'warning' clarified, then I = can >> make an informed choice. >>=20 >> Tom Petch >>=20 >>=20 >>=20 >> > >> > >> > >> > Andy >> > >>=20 >>=20 >> = ------------------------------------------------------------------------ >> -------- >>=20 >>=20 >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf = >> > >>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_69ACEAB7-1330-443C-BB71-D6FC9371DEF2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Could we define a set of new error-tags with error-severity as warning and still use <rpc-error>? What would be the advantage of defining <rpc-warnings> vs using error-severity of warning within <rcp-error>?

On Oct 5, 2015, at 11:53 AM, Kent Watsen <kwatsen@juniper.net> wrote:


The general definition is "error" means the process did not complete whereas "warning" means the process completed with issues.   That said, I'm unsure what happens for continue-on-error:

         continue-on-error:  Continue to process configuration data on
            error; error is recorded, and negative response is generated
            if any errors occur.

A negative response sounds like an <rpc-error> (since we don't have an <rpc-warning> yet), but I don't see which error-tag would be used for it.   If it's not defined, maybe we use and <rpc-warning> for it instead?

Kent

From: Andy Bierman <andy@yumaworks.com>
Date: Saturday, October 3, 2015 at 10:38 AM
To: "t.petch" <ietfc@btconnect.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] NETCONF warnings

Hi,

The RFC sways almost nothing about it:

  error-severity:  Contains a string identifying the error severity, as
      determined by the device.  One of:

      *  error

      *  warning

      Note that there are no <error-tag> values defined in this document
      that utilize the "warning" enumeration.  This is reserved for
      future use.

There is no definition of a warning in the RFC.
That would be up to each vendor or would require the WG to
define a warning.

Currently, the <error-severity> field is just a waste of bandwidth.


Andy


On Sat, Oct 3, 2015 at 4:34 AM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Andy Bierman" <andy@yumaworks.com>
To: "Netconf" <netconf@ietf.org>
Sent: Friday, October 02, 2015 9:28 PM

> Hi,
>
> The issue of warnings keeps coming up with customers.
> Technically, there are no error-tags that have an assigned
> error-severity of 'warning'. The <rpc-error> message is
> supposed to use 1 of the standard error-tags.
>
> So how should the server send warnings in NETCONF?
>
>  A) new message like <rpc-warning>
>  B) new error-tag with assigned severity 'warning'
>  C) pick an existing error-tag to allow as a warning
>  D) allow any error-tag to be severity warning
>  E) something else?

Depends what you mean by a warning.

I have worked with manufacturers that have a clearly defined hierarchy
of, say, four levels of result, of which warning is one.  Other
manufacturers take a different view.  Another slant on this is the
various return codes of e.g HTTP.

So first I would like the semantics of 'warning' clarified, then I can
make an informed choice.

Tom Petch



>
>
>
> Andy
>


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


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

Mahesh Jethanandani



--Apple-Mail=_69ACEAB7-1330-443C-BB71-D6FC9371DEF2-- From nobody Mon Oct 5 12:46: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 7D10F1B4F60 for ; Mon, 5 Oct 2015 12:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VVU3q2JNcJP for ; Mon, 5 Oct 2015 12:46:53 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 2C5241B4F52 for ; Mon, 5 Oct 2015 12:46:53 -0700 (PDT) Received: by lbos8 with SMTP id s8so64170655lbo.0 for ; Mon, 05 Oct 2015 12:46: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=ureBl/mpLUTloL9j6QwHupGSwas/xtusrrFx8QGp+gc=; b=Ldls5PBsctRUMbH3I02lsiY+T3pN9elDVZBILIqtGh5L5GXiqwZaYjBQh6wsmIXIfg lRxG8vsHBClt8Q0UP5YKA3wXGcZBCLkwFcvALKCno4XPwyWk7XBzknKmu7MzgdDR/WSY 5GCOia/SWNn9wojHUd2zdbVxMtA45/s8Jf7yIn31AkVC0mG44PQgtG3UBr3BSb1IvyQ6 m9NPSMjRVJL4ZVhC0+ITBrgsG+XxLYKl3OgHNBRYrAi4J6uxikycvKiUQW+ycBVj5pwl OsBt3FVkUNXRJFda3mf3Hoe9XdqFre6nqppPV/UR/ciVVUbq/PWY5bjCtoqj1f5wczY1 DZrQ== X-Gm-Message-State: ALoCoQkzL0Fsw7Fpu/5BS0txwHR0oRjIwYpa4h6Y8u1FeAY+9+P5hNFVQxtzQeNVnS1JGtbWGWHM MIME-Version: 1.0 X-Received: by 10.112.135.136 with SMTP id ps8mr12534334lbb.38.1444074411387; Mon, 05 Oct 2015 12:46:51 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Mon, 5 Oct 2015 12:46:51 -0700 (PDT) In-Reply-To: References: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> Date: Mon, 5 Oct 2015 12:46:51 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=089e0116071251fedb052160c6eb Archived-At: Cc: Netconf Subject: Re: [Netconf] NETCONF warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 05 Oct 2015 19:46:55 -0000 --089e0116071251fedb052160c6eb Content-Type: text/plain; charset=UTF-8 Hi, I think NETCONF clients are programmed to treat as an operation failure. A new protocol version will be needed to introduce a new message like . IMO stop-on-error and continue-on-error are both implementation-dependent, especially since NETCONF has no concept of edit order. Only all-or-none semantics are really interoperable (yet this is the only optional mode in NETCONF!) Andy On Mon, Oct 5, 2015 at 11:53 AM, Kent Watsen wrote: > > The general definition is "error" means the process did not complete > whereas "warning" means the process completed with issues. That said, I'm > unsure what happens for continue-on-error: > > continue-on-error: Continue to process configuration data on > error; error is recorded, and negative response is generated > if any errors occur. > > A negative response sounds like an (since we don't have an > yet), but I don't see which error-tag would be used for it. > If it's not defined, maybe we use and for it instead? > > Kent > > From: Andy Bierman > Date: Saturday, October 3, 2015 at 10:38 AM > To: "t.petch" > Cc: "netconf@ietf.org" > Subject: Re: [Netconf] NETCONF warnings > > Hi, > > The RFC sways almost nothing about it: > > error-severity: Contains a string identifying the error severity, as > determined by the device. One of: > > * error > > * warning > > Note that there are no values defined in this document > that utilize the "warning" enumeration. This is reserved for > future use. > > > There is no definition of a warning in the RFC. > That would be up to each vendor or would require the WG to > define a warning. > > Currently, the field is just a waste of bandwidth. > > > Andy > > > On Sat, Oct 3, 2015 at 4:34 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "Andy Bierman" >> To: "Netconf" >> Sent: Friday, October 02, 2015 9:28 PM >> >> > Hi, >> > >> > The issue of warnings keeps coming up with customers. >> > Technically, there are no error-tags that have an assigned >> > error-severity of 'warning'. The message is >> > supposed to use 1 of the standard error-tags. >> > >> > So how should the server send warnings in NETCONF? >> > >> > A) new message like >> > B) new error-tag with assigned severity 'warning' >> > C) pick an existing error-tag to allow as a warning >> > D) allow any error-tag to be severity warning >> > E) something else? >> >> Depends what you mean by a warning. >> >> I have worked with manufacturers that have a clearly defined hierarchy >> of, say, four levels of result, of which warning is one. Other >> manufacturers take a different view. Another slant on this is the >> various return codes of e.g HTTP. >> >> So first I would like the semantics of 'warning' clarified, then I can >> make an informed choice. >> >> Tom Petch >> >> >> >> > >> > >> > >> > Andy >> > >> >> >> ------------------------------------------------------------------------ >> -------- >> >> >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> > >> >> > --089e0116071251fedb052160c6eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think NETCONF clients are program= med to treat <rpc-error> as an operation failure.
A new pro= tocol version will be needed to introduce a new message like <rpc-warnin= g>.

IMO stop-on-error and continue-on-error are= both implementation-dependent,
especially since NETCONF has no c= oncept of edit order. =C2=A0 Only all-or-none
semantics are reall= y interoperable (yet this is the only optional mode in NETCONF!)
=

Andy


On Mon, Oct 5, 2015 at 11:53 AM= , Kent Watsen <kwatsen@juniper.net> wrote:

The general definition is "error" means the process did not = complete whereas "warning" means the process completed with issue= s. =C2=A0 That said, I'm unsure what happens for=C2=A0continue-on-error= :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0continue-on-error: =C2=A0Continue to= process configuration data on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error; error is recorded, an= d negative response is generated
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if any errors occur.

A negative response sounds like an <rpc-error> (since we don'= ;t have an <rpc-warning> yet), but I don't see which error-tag wo= uld be used for it. =C2=A0 If it's not defined, maybe we use and <rp= c-warning> for it instead?

Kent

From: Andy Bierman <andy@yumaworks.com>
Date: Saturday, October 3, 2015 at = 10:38 AM
To: "t.petch" <ietfc@btconnect.com&g= t;
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] NETCONF warn= ings

Hi,

The RFC sways almost nothing about it:

 =
 error-severity:  Contains a string identifying the error severity, as
      determined by the device.  One of:

      *  error

      *  warning

      Note that there are no <error-tag> values defined in this docum=
ent
      that utilize the "warning" enumeration.  This is reserved f=
or
      future use.

There is no definition of a warning in the RFC.
That would be up to each vendor or would require the WG to
define a warning.

Currently, the <error-severity> field is just a waste of bandwid= th.


Andy


On Sat, Oct 3, 2015 at 4:34 AM, t.petch <ietfc@btconnec= t.com> wrote:
----- Original Message -----
From: "Andy Bierman" <andy@yumaworks.com>
To: "Netconf" <netconf@ietf.org>
Sent: Friday, October 02, 2015 9:28 PM

> Hi,
>
> The issue of warnings keeps coming up with customers.
> Technically, there are no error-tags that have an assigned
> error-severity of 'warning'. The <rpc-error> message is<= br> > supposed to use 1 of the standard error-tags.
>
> So how should the server send warnings in NETCONF?
>
>=C2=A0 A) new message like <rpc-warning>
>=C2=A0 B) new error-tag with assigned severity 'warning'
>=C2=A0 C) pick an existing error-tag to allow as a warning
>=C2=A0 D) allow any error-tag to be severity warning
>=C2=A0 E) something else?

Depends what you mean by a warning.

I have worked with manufacturers that have a clearly defined hierarchy
of, say, four levels of result, of which warning is one.=C2=A0 Other
manufacturers take a different view.=C2=A0 Another slant on this is the
various return codes of e.g HTTP.

So first I would like the semantics of 'warning' clarified, then I = can
make an informed choice.

Tom Petch



>
>
>
> Andy
>


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


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

--089e0116071251fedb052160c6eb-- From nobody Tue Oct 6 01:47: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 4C6B21B3D52 for ; Tue, 6 Oct 2015 01:47:26 -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 UJ_V5CQM0LUB for ; Tue, 6 Oct 2015 01:47:24 -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 82DA01B3D4E for ; Tue, 6 Oct 2015 01:47:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20D8FAC2; Tue, 6 Oct 2015 10:47:22 +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 TAuSm9JKDWGe; Tue, 6 Oct 2015 10:47:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Oct 2015 10:47:20 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F6D02004E; Tue, 6 Oct 2015 10:47:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QDZxZFn0YyIA; Tue, 6 Oct 2015 10:47:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F9E220054; Tue, 6 Oct 2015 10:47:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6321E377DE6F; Tue, 6 Oct 2015 10:47:17 +0200 (CEST) Date: Tue, 6 Oct 2015 10:47:17 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20151006084717.GA39763@elstar.local> Mail-Followup-To: Mahesh Jethanandani , Kent Watsen , Netconf References: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> <49923B80-97E3-4101-8648-E9931A9BDDCC@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49923B80-97E3-4101-8648-E9931A9BDDCC@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] NETCONF warnings 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, 06 Oct 2015 08:47:26 -0000 On Mon, Oct 05, 2015 at 12:41:19PM -0700, Mahesh Jethanandani wrote: > Could we define a set of new error-tags with error-severity as warning and still use ? What would be the advantage of defining vs using error-severity of warning within ? > RFC 6241: The element is sent in messages if an error occurs during the processing of an request. I think a warning is not an error. But then RFC 6241 says: Note that there are no values defined in this document that utilize the "warning" enumeration. This is reserved for future use. And it also says: The element is sent in messages if no errors or warnings occurred during the processing of an request, and no data was returned from the operation. For example: This seems to be somewhat interesting, at least with my common sense interpretation of a warning ("the server could succcessfully process the input but there are a few things the client should pay attention to"). The current design makes sense if I have an option to tell the server 'treat all warnings as errors' but such an option does not exist in RFC 6241. If we go with my layman definition of a warnings (i.e., warnings are not errors unless specifically requested), then there are a couple of options to communicate warnings: - warnings go to a system log - warnings go into specific notifications - warnings go into metadata that is attached to specific nodes I think I have seen systems that send certain warnings inline as XML comments but this seems to be targeting mainly developers since tools usually do not bother processing XML 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 Thu Oct 8 04:48: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 972A81B32AB; Thu, 8 Oct 2015 04:48:26 -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 MdkLmohsP9tv; Thu, 8 Oct 2015 04:48:23 -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 081B51A876F; Thu, 8 Oct 2015 04:48:22 -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 CCG40195; Thu, 08 Oct 2015 11:48:21 +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.235.1; Thu, 8 Oct 2015 12:48:18 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.178]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Thu, 8 Oct 2015 19:48:07 +0800 From: Yangang To: "netmod@ietf.org" , "netconf@ietf.org" , "Zhangxianping (A)" Thread-Topic: One questions about the RESTCONF. Thread-Index: AQHRAb8yGCsQfAqJY0qmQPPXIMxByg== Date: Thu, 8 Oct 2015 11:48:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netconf] One questions about the RESTCONF. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 11:48:26 -0000 Hi, All: Recently, I try to use RESTCONF to support some functions. But I get one is= sue. Maybe somebody can help me to make it clear. It is about how to use the "augment", there is one example in RFC6020, and = it is clear. But maybe there is a little confused in RESTCONF draft. >From the example in RFC6020, the namespace http://example.com/schema/interf= aces, container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type iana:IfType; } leaf ifMtu { type int32; } } } Then, in namespace http://example.com/schema/ds0, we have: import interface-module { prefix "if"; } augment "/if:interfaces/if:ifEntry" { when "if:ifType=3D'ds0'"; leaf ds0ChannelNumber { type ChannelNumber; } } A corresponding netconf XML instance example: 1 Flintstone Inc Ethernet A562 ethernetCsmacd 1500 2 Flintstone Inc DS0 ds0 1 About the RESTCONF, my problems are: 1. In the GET operation, how to support it, we have download the GET two ti= mes? To get "http://example.com/schema/interfaces" and "http://example.com/= schema/ds0" separately? Or something I missed to get all information in one= request. 2. In the PUT operation. The question is same, how to set the namespace, ma= y I change the MTU and ChannelNumber together? Maybe I miss some important operation, can somebody provide a example? Thanks Yangang. From nobody Thu Oct 8 09:40: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 9F4231A9234 for ; Thu, 8 Oct 2015 09:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 FWw3E8tyr2Tw for ; Thu, 8 Oct 2015 09:40:35 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 5CDD91A9176 for ; Thu, 8 Oct 2015 09:40:31 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so54173625lbc.3 for ; Thu, 08 Oct 2015 09:40:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4NLIZgGuArIjkh8Ui3PLbxn6NnhZ05v4GVDYpkkYILI=; b=Lz+4uzP7Xo1eouc917asYtKRSZRxoJBM8Lh11isSXbdJjIUditHFFahFNBlO+eae2K LuU4TFlYZMT/zq5dVzqQ5EQTRXJQkCcy8Ptt6KAyDj3uvdlKzjeigj8iHA3VaOm6Yvuo auPahPbU5Bw/syFEMqNTLLf0PBYp2W40rAi3wAVw13WwPYXIsPPPZ0dZ3RVNolqZsRHN l/igZrptu9RtkUy6TVl+1B5a89CfF2Z6VddhNiq8ZvrFEuBrlkDzO5q/z2r72Nbbrtsk msiFET7sd86Vy6bB1vNxEEakmZt46Nmz8ZxisSjltakkOKTZOmrY1mkmOOyyQoRFg5Md Lx/A== X-Gm-Message-State: ALoCoQnC9I6dmqPQ2aQGtSDojWnvylp2Stjozlh67hpdjQXcPvruikAeRQyPoNRmeu7mi+DE4jOJ MIME-Version: 1.0 X-Received: by 10.25.218.205 with SMTP id r196mr2751107lfg.82.1444322429227; Thu, 08 Oct 2015 09:40:29 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Thu, 8 Oct 2015 09:40:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Oct 2015 09:40:29 -0700 Message-ID: From: Andy Bierman To: Yangang Content-Type: multipart/alternative; boundary=001a1140215455eb7805219a8530 Archived-At: Cc: "Zhangxianping \(A\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] One questions about the RESTCONF. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 16:40:36 -0000 --001a1140215455eb7805219a8530 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 8, 2015 at 4:48 AM, Yangang wrote: > Hi, All: > > Recently, I try to use RESTCONF to support some functions. But I get one > issue. Maybe somebody can help me to make it clear. > > It is about how to use the "augment", there is one example in RFC6020, and > it is clear. But maybe there is a little confused in RESTCONF draft. > > >From the example in RFC6020, the namespace > http://example.com/schema/interfaces, > > container interfaces { > list ifEntry { > key "ifIndex"; > leaf ifIndex { > type uint32; > } > leaf ifDescr { > type string; > } > leaf ifType { > type iana:IfType; > } > leaf ifMtu { > type int32; > } > } > } > > Then, in namespace http://example.com/schema/ds0, we have: > > import interface-module { > prefix "if"; > } > > augment "/if:interfaces/if:ifEntry" { > when "if:ifType='ds0'"; > leaf ds0ChannelNumber { > type ChannelNumber; > } > } > > A corresponding netconf XML instance example: > > > > 1 > Flintstone Inc Ethernet A562 > ethernetCsmacd > 1500 > > > 2 > Flintstone Inc DS0 > ds0 > 1 > > > > About the RESTCONF, my problems are: > > 1. In the GET operation, how to support it, we have download the GET two > times? To get "http://example.com/schema/interfaces" and " > http://example.com/schema/ds0" separately? Or something I missed to get > all information in one request. > > You don't get namespaces, you get subtrees. The "fields" parameter is available to select multiple disjoint subtrees in one request. 2. In the PUT operation. The question is same, how to set the namespace, > may I change the MTU and ChannelNumber together? > > You would use PATCH for that, not PUT. Either YANG Patch or a plain patch on the interface entry would allow multiple descendant nodes to be changed at once. > Maybe I miss some important operation, can somebody provide a example? > > Thanks > Yangang. > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1140215455eb7805219a8530 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 8, 2015 at 4:48 AM, Yangang <yangang@huawei.com>= wrote:
Hi, All:

Recently, I try to use RESTCONF to support some functions. But I get one is= sue. Maybe somebody can help me to make it clear.

It is about how to use the "augment", there is one example in RFC= 6020, and it is clear. But maybe there is a little confused in RESTCONF dra= ft.

>From the example in RFC6020, the namespace http://example.co= m/schema/interfaces,

=C2=A0container interfaces {
=C2=A0 =C2=A0 =C2=A0list ifEntry {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key "ifIndex";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ifIndex {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type uint32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ifDescr {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ifType {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type iana:IfType;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf ifMtu {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type int32;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 }
=C2=A0}

=C2=A0Then, in namespace http://example.com/schema/ds0, we have:
=C2=A0import interface-module {
=C2=A0 =C2=A0 =C2=A0prefix "if";
=C2=A0}

=C2=A0augment "/if:interfaces/if:ifEntry" {
=C2=A0 =C2=A0 =C2=A0when "if:ifType=3D'ds0'";
=C2=A0 =C2=A0 =C2=A0leaf ds0ChannelNumber {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type ChannelNumber;
=C2=A0 =C2=A0 =C2=A0}
=C2=A0}

=C2=A0A corresponding netconf XML instance example:

=C2=A0<interfaces xmlns=3D"http://example.com/schema/int= erfaces" xmlns:ds0=3D"http://example.com/schema/ds0&q= uot;>
=C2=A0 =C2=A0<ifEntry>
=C2=A0 =C2=A0 =C2=A0<ifIndex>1</ifIndex>
=C2=A0 =C2=A0 =C2=A0<ifDescr>Flintstone Inc Ethernet A562</ifDescr= >
=C2=A0 =C2=A0 =C2=A0<ifType>ethernetCsmacd</ifType>
=C2=A0 =C2=A0 =C2=A0<ifMtu>1500</ifMtu>
=C2=A0 =C2=A0</ifEntry>
=C2=A0 =C2=A0<ifEntry>
=C2=A0 =C2=A0 =C2=A0<ifIndex>2</ifIndex>
=C2=A0 =C2=A0 =C2=A0<ifDescr>Flintstone Inc DS0</ifDescr>
=C2=A0 =C2=A0 =C2=A0<ifType>ds0</ifType>
=C2=A0 =C2=A0 =C2=A0<ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber&= gt;
=C2=A0 =C2=A0</ifEntry>
=C2=A0</interfaces>

About the RESTCONF, my problems are:

1. In the GET operation, how to support it, we have download the GET two ti= mes? To get "http://example.com/schema/interfaces"= and "http://example.com/schema/ds0" separately? Or somet= hing I missed to get all information in one request.


You don't get namespaces, you get = subtrees.
The "fields" parameter is available to select= multiple disjoint
subtrees in one request.

<= div>
2. In the PUT operation. The question is same, how to set the namespace, ma= y I change the MTU and ChannelNumber together?


You would use PATCH for that, not PUT.=
Either YANG Patch or a plain patch on the interface entry
<= div>would allow multiple descendant nodes to be changed at once.
=
=C2=A0
Maybe I miss some important operation, can somebody provide a example?

Thanks
Yangang.

Andy
=C2=A0

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

--001a1140215455eb7805219a8530-- From nobody Thu Oct 8 12:21: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 059221A1AC9 for ; Thu, 8 Oct 2015 12:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXPmbmT7Ddpl for ; Thu, 8 Oct 2015 12:21:25 -0700 (PDT) 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 75C831A1AC6 for ; Thu, 8 Oct 2015 12:21:24 -0700 (PDT) Received: by lbbwt4 with SMTP id wt4so58262553lbb.1 for ; Thu, 08 Oct 2015 12:21:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=IWE+ssatw6h2tUzkbOFPcWoQIFqw4TD3ARYlawhu8Qw=; b=SuzwjwWeN74otaWdCMVgBJnOtEmq+w6C0SBxkJlW7LlPpoZcLpsqm+pNnhvPhBMDIZ QwZpldjJE9WkmSWobCVCKib71HI8miwjN+KxWGH9peMCS8juO/LSu8o0iieiGZZkxmwp dy1r8eu7M/9VKua64jbYB4tyRqoSNK1Huz787ibDntcYArzHfjbPs0ERz+yomnObfHh2 n8TCMYQfcu2ygjqSWkNDKpXxUJuBTFzqOf1j2xqsQO8NEfInIC06gPal7G1Z6gJ4QJ/6 7UORk+L3cICzEgHO7sstHVRJdKVqKeZzJ7lBx5ic+cjqkSdMfU8rPDSnL7QEbvFoeatb lFng== X-Gm-Message-State: ALoCoQlQElBW3IeqyQ+CFr83MELOy8tqQkcxH4OlXZqrQYvnws2YxzA3/0yQeeYMvlyh723LXUpk MIME-Version: 1.0 X-Received: by 10.112.170.165 with SMTP id an5mr3648517lbc.33.1444332082608; Thu, 08 Oct 2015 12:21:22 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Thu, 8 Oct 2015 12:21:22 -0700 (PDT) In-Reply-To: <20151006084717.GA39763@elstar.local> References: <00d201d0fdcf$70964be0$4001a8c0@gateway.2wire.net> <49923B80-97E3-4101-8648-E9931A9BDDCC@gmail.com> <20151006084717.GA39763@elstar.local> Date: Thu, 8 Oct 2015 12:21:22 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Mahesh Jethanandani , Kent Watsen , Netconf Content-Type: multipart/alternative; boundary=001a11c37a24b8ded405219cc45d Archived-At: Subject: Re: [Netconf] NETCONF warnings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 08 Oct 2015 19:21:27 -0000 --001a11c37a24b8ded405219cc45d Content-Type: text/plain; charset=UTF-8 On Tue, Oct 6, 2015 at 1:47 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Oct 05, 2015 at 12:41:19PM -0700, Mahesh Jethanandani wrote: > > Could we define a set of new error-tags with error-severity as warning > and still use ? What would be the advantage of defining > vs using error-severity of warning within ? > > > > RFC 6241: > > The element is sent in messages if an error > occurs during the processing of an request. > > I think a warning is not an error. But then RFC 6241 says: > > Note that there are no values defined in this document > that utilize the "warning" enumeration. This is reserved for > future use. > > And it also says: > > The element is sent in messages if no errors or > warnings occurred during the processing of an request, and no > data was returned from the operation. For example: > > This seems to be somewhat interesting, at least with my common sense > interpretation of a warning ("the server could succcessfully process > the input but there are a few things the client should pay attention > to"). The current design makes sense if I have an option to tell the > server 'treat all warnings as errors' but such an option does not > exist in RFC 6241. > > If we go with my layman definition of a warnings (i.e., warnings are > not errors unless specifically requested), then there are a couple of > options to communicate warnings: > > - warnings go to a system log > - warnings go into specific notifications > - warnings go into metadata that is attached to specific nodes > > I guess metadata would be the best choice here because it is the easiest to implement (and does not rely on optional features or parsing XML comments) Except attributes cannot be used multiple times in the same element, so only 1 warning could really be sent A new protocol version is probably needed to do anything with warnings. > I think I have seen systems that send certain warnings inline as XML > comments but this seems to be targeting mainly developers since tools > usually do not bother processing XML comments. > > /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 > --001a11c37a24b8ded405219cc45d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 6, 2015 at 1:47 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Oct 05, 2015 at 12:41:19PM -0700, Mahesh Jeth= anandani wrote:
> Could we define a set of new error-tags with error-severity as warning= and still use <rpc-error>? What would be the advantage of defining &= lt;rpc-warnings> vs using error-severity of warning within <rcp-error= >?
>

RFC 6241:

=C2=A0 =C2=A0The <rpc-error> element is sent in <rpc-reply> mes= sages if an error
=C2=A0 =C2=A0occurs during the processing of an <rpc> request.

I think a warning is not an error. But then RFC 6241 says:

=C2=A0 =C2=A0 =C2=A0 Note that there are no <error-tag> values define= d in this document
=C2=A0 =C2=A0 =C2=A0 that utilize the "warning" enumeration.=C2= =A0 This is reserved for
=C2=A0 =C2=A0 =C2=A0 future use.

And it also says:

=C2=A0 =C2=A0The <ok> element is sent in <rpc-reply> messages i= f no errors or
=C2=A0 =C2=A0warnings occurred during the processing of an <rpc> requ= est, and no
=C2=A0 =C2=A0data was returned from the operation.=C2=A0 For example:

This seems to be somewhat interesting, at least with my common sense
interpretation of a warning ("the server could succcessfully process the input but there are a few things the client should pay attention
to"). The current design makes sense if I have an option to tell the server 'treat all warnings as errors' but such an option does not exist in RFC 6241.

If we go with my layman definition of a warnings (i.e., warnings are
not errors unless specifically requested), then there are a couple of
options to communicate warnings:

- warnings go to a system log
- warnings go into specific notifications
- warnings go into metadata that is attached to specific nodes



I guess metadata would = be the best choice here because it is
the easiest to implement (a= nd does not rely on optional
features or parsing XML comments)

Except attributes cannot be used multiple times in t= he
same element, so only 1 warning could really be sent

=C2=A0 =C2=A0 =C2=A0 <rpc-reply>
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0<ok nc:warning=3D"Low memory warning" = />
=C2=A0 =C2=A0 =C2=A0 </rpc-reply>

A new protocol version is probably needed to do anything with warning= s.

=C2=A0
I think I have seen systems that send certain warnings inline as XML
comments but this seems to be targeting mainly developers since tools
usually do not bother processing XML comments.

/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a11c37a24b8ded405219cc45d-- From nobody Fri Oct 9 02:05: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 363031B2C5A; Fri, 9 Oct 2015 02:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 aUlsT5LwOj_v; Fri, 9 Oct 2015 02:05:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3B21AD151; Fri, 9 Oct 2015 02:04:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCH38783; Fri, 09 Oct 2015 09:04:14 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 9 Oct 2015 10:04:12 +0100 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.178]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Fri, 9 Oct 2015 17:04:02 +0800 From: Yangang To: Andy Bierman Thread-Topic: [netmod] One questions about the RESTCONF. Thread-Index: AQHRAb8yGCsQfAqJY0qmQPPXIMxByp5hRnqAgAGXWfA= Date: Fri, 9 Oct 2015 09:04:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.212] Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC734184AAB4D0nkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Zhangxianping \(A\)" , "netconf@ietf.org" , "netmod@ietf.org" Subject: [Netconf] =?utf-8?b?562U5aSNOiBbbmV0bW9kXSBPbmUgcXVlc3Rpb25zIGFi?= =?utf-8?q?out_the_RESTCONF=2E?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2015 09:05:06 -0000 --_000_D496C972D1A13540A730720631EC734184AAB4D0nkgeml507mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEFuZHk6DQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4NCg0KSSB3cml0ZSBhbiBSRVNU Q09ORiBzYW1wbGUgY29kZSwgY291bGQgeW91IGNoZWNrIHdoaWNoIG9wdGlvbiBpcyBnb29kLg0K DQpUaGUgbW9kdWxlIGlzIHN0aWxsIHRoYXQgZXhhbXBsZSBvbiB0aGUgbGFzdCBtYWlsLg0KDQpF eGFtcGxlIDENClRoZSBSZXF1ZXN0Og0KR0VUIC9yZXN0Y29uZi9kYXRhL2ludGVyZmFjZS1tb2R1 bGU6aW50ZXJmYWNlcw0KSFRUUC8xLjENCkhvc3Q6IGV4YW1wbGUuY29tDQpBY2NlcHQ6IGFwcGxp Y2F0aW9uL3lhbmcuZGF0YSt4bWwNCg0KRm9yIHRoZSBhYm92ZSByZXF1ZXN0LCB3aGljaCByZXNw b25zZSBpcyBjb3JyZWN0PyBSZXNwb25zZSAxIG9yIFJlc3BvbnNlIDI/DQpSZXNwb25zZSAxDQpI VFRQLzEuMSAyMDAgT0sNCkRhdGU6IE1vbiwgMjMgQXByIDIwMTIgMTc6MDI6NDAgR01UDQpTZXJ2 ZXI6IGV4YW1wbGUtc2VydmVyDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmcuZGF0YSt4 bWwNCkNhY2hlLUNvbnRyb2w6IG5vLWNhY2hlDQpQcmFnbWE6IG5vLWNhY2hlDQpFVGFnOiBhNzRl ZWZjOTkzYTJiDQpMYXN0LU1vZGlmaWVkOiBNb24sIDIzIEFwciAyMDEyIDExOjAyOjE0IEdNVA0K DQo8aW50ZXJmYWNlcyB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2Vz IiB4bWxuczpkczA9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvZHMwIj4NCiAgIDxpZkVudHJ5 Pg0KICAgICA8aWZJbmRleD4xPC9pZkluZGV4Pg0KICAgICA8aWZEZXNjcj5GbGludHN0b25lIElu YyBFdGhlcm5ldCBBNTYyPC9pZkRlc2NyPg0KICAgICA8aWZUeXBlPmV0aGVybmV0Q3NtYWNkPC9p ZlR5cGU+DQogICAgIDxpZk10dT4xNTAwPC9pZk10dT4NCiAgIDwvaWZFbnRyeT4NCiAgIDxpZkVu dHJ5Pg0KICAgICA8aWZJbmRleD4yPC9pZkluZGV4Pg0KICAgICA8aWZEZXNjcj5GbGludHN0b25l IEluYyBEUzA8L2lmRGVzY3I+DQogICAgIDxpZlR5cGU+ZHMwPC9pZlR5cGU+DQogICAgIDxkczA6 ZHMwQ2hhbm5lbE51bWJlcj4xPC9kczA6ZHMwQ2hhbm5lbE51bWJlcj4NCiAgIDwvaWZFbnRyeT4N CiA8L2ludGVyZmFjZXM+DQoNClJlc3BvbnNlIDINCkhUVFAvMS4xIDIwMCBPSw0KRGF0ZTogTW9u LCAyMyBBcHIgMjAxMiAxNzowMjo0MCBHTVQNClNlcnZlcjogZXhhbXBsZS1zZXJ2ZXINCkNvbnRl bnQtVHlwZTogYXBwbGljYXRpb24veWFuZy5kYXRhK3htbA0KQ2FjaGUtQ29udHJvbDogbm8tY2Fj aGUNClByYWdtYTogbm8tY2FjaGUNCkVUYWc6IGE3NGVlZmM5OTNhMmINCkxhc3QtTW9kaWZpZWQ6 IE1vbiwgMjMgQXByIDIwMTIgMTE6MDI6MTQgR01UDQoNCjxpbnRlcmZhY2VzIHhtbG5zPSJodHRw Oi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMiPg0KICAgPGlmRW50cnk+DQogICAgIDxp ZkluZGV4PjE8L2lmSW5kZXg+DQogICAgIDxpZkRlc2NyPkZsaW50c3RvbmUgSW5jIEV0aGVybmV0 IEE1NjI8L2lmRGVzY3I+DQogICAgIDxpZlR5cGU+ZXRoZXJuZXRDc21hY2Q8L2lmVHlwZT4NCiAg ICAgPGlmTXR1PjE1MDA8L2lmTXR1Pg0KICAgPC9pZkVudHJ5Pg0KICAgPGlmRW50cnk+DQogICAg IDxpZkluZGV4PjI8L2lmSW5kZXg+DQogICAgIDxpZkRlc2NyPkZsaW50c3RvbmUgSW5jIERTMDwv aWZEZXNjcj4NCiAgICAgPGlmVHlwZT5kczA8L2lmVHlwZT4NCiAgIDwvaWZFbnRyeT4NCiA8L2lu dGVyZmFjZXM+DQoNCg0KRXhhbXBsZSAyDQpJZiB3ZSB3YW50IHRvIGdldCBlbGVtZW50cyBvZiBp ZkVudHJ5KGlmSW5kZXgsIGlmRGVzY3IsIGlmVHlwZSwgaWZNVFUpIGFuZCBhdWdtZW50IGVsZW1l bnQg4oCYZHMwQ2hhbm5lbE51bWJlcuKAmSwgd2hpY2ggUmVxdWVzdCBpcyBjb3JyZWN0PyBSZXF1 ZXN0IDEsUmVxdWVzdCAyIG9yIFJlcXVlc3QgMz8NClJlcXVlc3QgMToNCkdFVCAvcmVzdGNvbmYv ZGF0YS9kczAtbW9kdWxlOmludGVyZmFjZXMNCkhUVFAvMS4xDQpIb3N0OiBleGFtcGxlLmNvbQ0K QWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLmRhdGEreG1sDQoNClJlcXVlc3QgMjoNCkdFVCAvcmVz dGNvbmYvZGF0YS9pbnRlcmZhY2VzLW1vZHVsZTppbnRlcmZhY2VzDQpIVFRQLzEuMQ0KSG9zdDog ZXhhbXBsZS5jb20NCkFjY2VwdDogYXBwbGljYXRpb24veWFuZy5kYXRhK3htbA0KDQpSZXF1ZXN0 IDM6DQpHRVQgL3Jlc3Rjb25mL2RhdGE/ZmllbGRzPWludGVyZmFjZXMtbW9kdWxlOmludGVyZmFj ZXM7ZHMwLW1vZHVsZTpkczBDaGFubmVsTnVtYmVyDQpIVFRQLzEuMQ0KSG9zdDogZXhhbXBsZS5j b20NCkFjY2VwdDogYXBwbGljYXRpb24veWFuZy5kYXRhK3htbA0KDQpUaGFua3MNCllhbmdhbmcN Cg0K5Y+R5Lu25Lq6OiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQrl j5HpgIHml7bpl7Q6IDIwMTXlubQxMOaciDnml6UgMDo0MA0K5pS25Lu25Lq6OiBZYW5nYW5nDQrm ioTpgIE6IG5ldG1vZEBpZXRmLm9yZzsgbmV0Y29uZkBpZXRmLm9yZzsgWmhhbmd4aWFucGluZyAo QSkNCuS4u+mimDogUmU6IFtuZXRtb2RdIE9uZSBxdWVzdGlvbnMgYWJvdXQgdGhlIFJFU1RDT05G Lg0KDQoNCg0KT24gVGh1LCBPY3QgOCwgMjAxNSBhdCA0OjQ4IEFNLCBZYW5nYW5nIDx5YW5nYW5n QGh1YXdlaS5jb208bWFpbHRvOnlhbmdhbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGksIEFsbDoN Cg0KUmVjZW50bHksIEkgdHJ5IHRvIHVzZSBSRVNUQ09ORiB0byBzdXBwb3J0IHNvbWUgZnVuY3Rp b25zLiBCdXQgSSBnZXQgb25lIGlzc3VlLiBNYXliZSBzb21lYm9keSBjYW4gaGVscCBtZSB0byBt YWtlIGl0IGNsZWFyLg0KDQpJdCBpcyBhYm91dCBob3cgdG8gdXNlIHRoZSAiYXVnbWVudCIsIHRo ZXJlIGlzIG9uZSBleGFtcGxlIGluIFJGQzYwMjAsIGFuZCBpdCBpcyBjbGVhci4gQnV0IG1heWJl IHRoZXJlIGlzIGEgbGl0dGxlIGNvbmZ1c2VkIGluIFJFU1RDT05GIGRyYWZ0Lg0KDQo+RnJvbSB0 aGUgZXhhbXBsZSBpbiBSRkM2MDIwLCB0aGUgbmFtZXNwYWNlIGh0dHA6Ly9leGFtcGxlLmNvbS9z Y2hlbWEvaW50ZXJmYWNlcywNCg0KIGNvbnRhaW5lciBpbnRlcmZhY2VzIHsNCiAgICAgbGlzdCBp ZkVudHJ5IHsNCiAgICAgICAgIGtleSAiaWZJbmRleCI7DQogICAgICAgICBsZWFmIGlmSW5kZXgg ew0KICAgICAgICAgICAgIHR5cGUgdWludDMyOw0KICAgICAgICAgfQ0KICAgICAgICAgbGVhZiBp ZkRlc2NyIHsNCiAgICAgICAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgICAgIH0NCiAgICAgICAg IGxlYWYgaWZUeXBlIHsNCiAgICAgICAgICAgICB0eXBlIGlhbmE6SWZUeXBlOw0KICAgICAgICAg fQ0KICAgICAgICAgbGVhZiBpZk10dSB7DQogICAgICAgICAgICAgdHlwZSBpbnQzMjsNCiAgICAg ICAgIH0NCiAgICB9DQogfQ0KDQogVGhlbiwgaW4gbmFtZXNwYWNlIGh0dHA6Ly9leGFtcGxlLmNv bS9zY2hlbWEvZHMwLCB3ZSBoYXZlOg0KDQogaW1wb3J0IGludGVyZmFjZS1tb2R1bGUgew0KICAg ICBwcmVmaXggImlmIjsNCiB9DQoNCiBhdWdtZW50ICIvaWY6aW50ZXJmYWNlcy9pZjppZkVudHJ5 IiB7DQogICAgIHdoZW4gImlmOmlmVHlwZT0nZHMwJyI7DQogICAgIGxlYWYgZHMwQ2hhbm5lbE51 bWJlciB7DQogICAgICAgICB0eXBlIENoYW5uZWxOdW1iZXI7DQogICAgIH0NCiB9DQoNCiBBIGNv cnJlc3BvbmRpbmcgbmV0Y29uZiBYTUwgaW5zdGFuY2UgZXhhbXBsZToNCg0KIDxpbnRlcmZhY2Vz IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMiIHhtbG5zOmRzMD0i aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9kczAiPg0KICAgPGlmRW50cnk+DQogICAgIDxpZklu ZGV4PjE8L2lmSW5kZXg+DQogICAgIDxpZkRlc2NyPkZsaW50c3RvbmUgSW5jIEV0aGVybmV0IEE1 NjI8L2lmRGVzY3I+DQogICAgIDxpZlR5cGU+ZXRoZXJuZXRDc21hY2Q8L2lmVHlwZT4NCiAgICAg PGlmTXR1PjE1MDA8L2lmTXR1Pg0KICAgPC9pZkVudHJ5Pg0KICAgPGlmRW50cnk+DQogICAgIDxp ZkluZGV4PjI8L2lmSW5kZXg+DQogICAgIDxpZkRlc2NyPkZsaW50c3RvbmUgSW5jIERTMDwvaWZE ZXNjcj4NCiAgICAgPGlmVHlwZT5kczA8L2lmVHlwZT4NCiAgICAgPGRzMDpkczBDaGFubmVsTnVt YmVyPjE8L2RzMDpkczBDaGFubmVsTnVtYmVyPg0KICAgPC9pZkVudHJ5Pg0KIDwvaW50ZXJmYWNl cz4NCg0KQWJvdXQgdGhlIFJFU1RDT05GLCBteSBwcm9ibGVtcyBhcmU6DQoNCjEuIEluIHRoZSBH RVQgb3BlcmF0aW9uLCBob3cgdG8gc3VwcG9ydCBpdCwgd2UgaGF2ZSBkb3dubG9hZCB0aGUgR0VU IHR3byB0aW1lcz8gVG8gZ2V0ICJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMi IGFuZCAiaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9kczAiIHNlcGFyYXRlbHk/IE9yIHNvbWV0 aGluZyBJIG1pc3NlZCB0byBnZXQgYWxsIGluZm9ybWF0aW9uIGluIG9uZSByZXF1ZXN0Lg0KDQpZ b3UgZG9uJ3QgZ2V0IG5hbWVzcGFjZXMsIHlvdSBnZXQgc3VidHJlZXMuDQpUaGUgImZpZWxkcyIg cGFyYW1ldGVyIGlzIGF2YWlsYWJsZSB0byBzZWxlY3QgbXVsdGlwbGUgZGlzam9pbnQNCnN1YnRy ZWVzIGluIG9uZSByZXF1ZXN0Lg0KDQoNCjIuIEluIHRoZSBQVVQgb3BlcmF0aW9uLiBUaGUgcXVl c3Rpb24gaXMgc2FtZSwgaG93IHRvIHNldCB0aGUgbmFtZXNwYWNlLCBtYXkgSSBjaGFuZ2UgdGhl IE1UVSBhbmQgQ2hhbm5lbE51bWJlciB0b2dldGhlcj8NCg0KWW91IHdvdWxkIHVzZSBQQVRDSCBm b3IgdGhhdCwgbm90IFBVVC4NCkVpdGhlciBZQU5HIFBhdGNoIG9yIGEgcGxhaW4gcGF0Y2ggb24g dGhlIGludGVyZmFjZSBlbnRyeQ0Kd291bGQgYWxsb3cgbXVsdGlwbGUgZGVzY2VuZGFudCBub2Rl cyB0byBiZSBjaGFuZ2VkIGF0IG9uY2UuDQoNCg0KTWF5YmUgSSBtaXNzIHNvbWUgaW1wb3J0YW50 IG9wZXJhdGlvbiwgY2FuIHNvbWVib2R5IHByb3ZpZGUgYSBleGFtcGxlPw0KDQpUaGFua3MNCllh bmdhbmcuDQoNCkFuZHkNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpu ZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KDQo= --_000_D496C972D1A13540A730720631EC734184AAB4D0nkgeml507mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QiPkhpLCBBbmR5OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNl Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdDtjb2xvcjojMUY0OTdEIj5JIHdyaXRlIGFuIFJF U1RDT05GIHNhbXBsZSBjb2RlLCBjb3VsZCB5b3UgY2hlY2sgd2hpY2ggb3B0aW9uIGlzIGdvb2Qu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoZSBtb2R1bGUgaXMg c3RpbGwgdGhhdCBleGFtcGxlIG9uIHRoZSBsYXN0IG1haWwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTQuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cmVkIj5F eGFtcGxlIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoZSBSZXF1ZXN0OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5H RVQgL3Jlc3Rjb25mL2RhdGEvaW50ZXJmYWNlLW1vZHVsZTppbnRlcmZhY2VzDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SFRU UC8xLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SG9zdDogZXhhbXBsZS5jb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWNjZXB0OiBhcHBsaWNhdGlvbi95 YW5nLmRhdGEmIzQzO3htbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcw QzAiPkZvciB0aGUgYWJvdmUgcmVxdWVzdCwgd2hpY2ggcmVzcG9uc2UgaXMgY29ycmVjdD8gUmVz cG9uc2UgMSBvciBSZXNwb25zZSAyPzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlJl c3BvbnNlIDE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IVFRQLzEuMSAyMDAgT0s8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+RGF0ZTogTW9uLCAyMyBBcHIgMjAxMiAxNzowMjo0MCBHTVQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VydmVyOiBl eGFtcGxlLXNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Db250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmcuZGF0YSYj NDM7eG1sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkNhY2hlLUNvbnRyb2w6IG5vLWNhY2hlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlByYWdtYTogbm8tY2Fj aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+RVRhZzogYTc0ZWVmYzk5M2EyYjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MYXN0LU1vZGlmaWVkOiBNb24sIDIz IEFwciAyMDEyIDExOjAyOjE0IEdNVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmx0O2ludGVyZmFjZXMg eG1sbnM9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2Vz IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2VzPC9h PiZxdW90OyB4bWxuczpkczA9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVt YS9kczAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2RzMDwvYT4m cXVvdDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDtpZkVudHJ5Jmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7Jmx0O2lmSW5kZXgmZ3Q7MSZsdDsvaWZJbmRleCZndDs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDtpZkRlc2NyJmd0O0ZsaW50c3RvbmUgSW5jIEV0aGVybmV0IEE1NjIm bHQ7L2lmRGVzY3ImZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZUeXBlJmd0O2V0 aGVybmV0Q3NtYWNkJmx0Oy9pZlR5cGUmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 aWZNdHUmZ3Q7MTUwMCZsdDsvaWZNdHUmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDsvaWZFbnRy eSZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0O2lmRW50cnkmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7aWZJbmRleCZndDsyJmx0Oy9pZkluZGV4Jmd0Ozxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0O2lmRGVzY3ImZ3Q7RmxpbnRzdG9uZSBJbmMgRFMwJmx0Oy9pZkRlc2NyJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2lmVHlwZSZndDtkczAmbHQ7L2lmVHlwZSZn dDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtkczA6ZHMwQ2hhbm5lbE51bWJlciZndDsx Jmx0Oy9kczA6ZHMwQ2hhbm5lbE51bWJlciZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0Oy9pZkVu dHJ5Jmd0Ozxicj4NCiZuYnNwOyZsdDsvaW50ZXJmYWNlcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMDA3MEMwIj5SZXNwb25zZSAyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SFRUUC8xLjEgMjAwIE9LPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRhdGU6IE1vbiwgMjMgQXByIDIwMTIgMTc6 MDI6NDAgR01UPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlNlcnZlcjogZXhhbXBsZS1zZXJ2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q29udGVudC1UeXBl OiBhcHBsaWNhdGlvbi95YW5nLmRhdGEmIzQzO3htbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DYWNoZS1Db250cm9sOiBuby1j YWNoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5QcmFnbWE6IG5vLWNhY2hlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkVUYWc6IGE3NGVlZmM5OTNhMmI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+TGFzdC1Nb2RpZmllZDogTW9uLCAyMyBBcHIgMjAxMiAxMTowMjoxNCBHTVQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZsdDtpbnRlcmZhY2VzIHhtbG5zPSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9leGFt cGxlLmNvbS9zY2hlbWEvaW50ZXJmYWNlcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9leGFtcGxl LmNvbS9zY2hlbWEvaW50ZXJmYWNlczwvYT4mcXVvdDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZs dDtpZkVudHJ5Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2lmSW5kZXgmZ3Q7MSZs dDsvaWZJbmRleCZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtpZkRlc2NyJmd0O0Zs aW50c3RvbmUgSW5jIEV0aGVybmV0IEE1NjImbHQ7L2lmRGVzY3ImZ3Q7PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7aWZUeXBlJmd0O2V0aGVybmV0Q3NtYWNkJmx0Oy9pZlR5cGUmZ3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZNdHUmZ3Q7MTUwMCZsdDsvaWZNdHUmZ3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOyZsdDsvaWZFbnRyeSZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0O2lm RW50cnkmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZJbmRleCZndDsyJmx0Oy9p ZkluZGV4Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2lmRGVzY3ImZ3Q7RmxpbnRz dG9uZSBJbmMgRFMwJmx0Oy9pZkRlc2NyJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0 O2lmVHlwZSZndDtkczAmbHQ7L2lmVHlwZSZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0Oy9pZkVu dHJ5Jmd0Ozxicj4NCiZuYnNwOyZsdDsvaW50ZXJmYWNlcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cmVkIj5FeGFtcGxlIDI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMwMDcwQzAiPklmIHdlIHdhbnQgdG8gZ2V0IGVsZW1lbnRzIG9mIGlmRW50cnkoaWZJbmRl eCwgaWZEZXNjciwgaWZUeXBlLCBpZk1UVSkgYW5kIGF1Z21lbnQgZWxlbWVudA0KPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj7igJg8c3BhbiBsYW5nPSJFTi1VUyI+ZHMwQ2hhbm5l bE51bWJlcjwvc3Bhbj7igJk8c3BhbiBsYW5nPSJFTi1VUyI+LCB3aGljaCBSZXF1ZXN0IGlzIGNv cnJlY3Q/IFJlcXVlc3QgMSxSZXF1ZXN0IDIgb3IgUmVxdWVzdCAzPzxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPlJlcXVlc3QgMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+R0VUIC9yZXN0Y29uZi9kYXRhL2Rz MC1tb2R1bGU6aW50ZXJmYWNlcyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IVFRQLzEuMTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3N0OiBleGFtcGxl LmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5BY2NlcHQ6IGFwcGxpY2F0aW9uL3lhbmcuZGF0YSYjNDM7eG1sPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+UmVxdWVzdCAyOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HRVQgL3Jl c3Rjb25mL2RhdGEvaW50ZXJmYWNlcy1tb2R1bGU6aW50ZXJmYWNlczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IVFRQLzEuMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Ib3N0OiBleGFtcGxlLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BY2NlcHQ6IGFwcGxpY2F0aW9uL3lhbmcuZGF0 YSYjNDM7eG1sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+UmVxdWVzdCAzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HRVQgL3Jl c3Rjb25mL2RhdGE/ZmllbGRzPWludGVyZmFjZXMtbW9kdWxlOmludGVyZmFjZXM7ZHMwLW1vZHVs ZTpkczBDaGFubmVsTnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhUVFAvMS4xPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhvc3Q6IGV4YW1wbGUuY29t PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkFjY2VwdDogYXBwbGljYXRpb24veWFuZy5kYXRhJiM0Mzt4bWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdDtjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox NC4wcHQ7Y29sb3I6IzFGNDk3RCI+WWFuZ2FuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gQW5keSBCaWVy bWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+IDIwMTU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxh bmc9IkVOLVVTIj4xMDwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+OTwvc3Bhbj7ml6U8c3Bh biBsYW5nPSJFTi1VUyI+IDA6NDA8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0i RU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gWWFuZ2FuZzxicj4NCjwvc3Bh bj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBuZXRtb2RAaWV0Zi5vcmc7IG5ldGNvbmZAaWV0Zi5vcmc7IFpoYW5neGlhbnBpbmcgKEEp PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IFJlOiBbbmV0bW9kXSBPbmUgcXVlc3Rpb25zIGFib3V0IHRoZSBSRVNU Q09ORi48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBPY3QgOCwgMjAxNSBhdCA0OjQ4 IEFNLCBZYW5nYW5nICZsdDs8YSBocmVmPSJtYWlsdG86eWFuZ2FuZ0BodWF3ZWkuY29tIiB0YXJn ZXQ9Il9ibGFuayI+eWFuZ2FuZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGksIEFsbDo8YnI+DQo8YnI+DQpSZWNlbnRseSwgSSB0 cnkgdG8gdXNlIFJFU1RDT05GIHRvIHN1cHBvcnQgc29tZSBmdW5jdGlvbnMuIEJ1dCBJIGdldCBv bmUgaXNzdWUuIE1heWJlIHNvbWVib2R5IGNhbiBoZWxwIG1lIHRvIG1ha2UgaXQgY2xlYXIuPGJy Pg0KPGJyPg0KSXQgaXMgYWJvdXQgaG93IHRvIHVzZSB0aGUgJnF1b3Q7YXVnbWVudCZxdW90Oywg dGhlcmUgaXMgb25lIGV4YW1wbGUgaW4gUkZDNjAyMCwgYW5kIGl0IGlzIGNsZWFyLiBCdXQgbWF5 YmUgdGhlcmUgaXMgYSBsaXR0bGUgY29uZnVzZWQgaW4gUkVTVENPTkYgZHJhZnQuPGJyPg0KPGJy Pg0KJmd0O0Zyb20gdGhlIGV4YW1wbGUgaW4gUkZDNjAyMCwgdGhlIG5hbWVzcGFjZSA8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvaW50ZXJmYWNlczwvYT4sPGJyPg0KPGJyPg0KJm5i c3A7Y29udGFpbmVyIGludGVyZmFjZXMgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7bGlzdCBp ZkVudHJ5IHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7a2V5ICZxdW90 O2lmSW5kZXgmcXVvdDs7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xl YWYgaWZJbmRleCB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7dHlwZSB1aW50MzI7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO308YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGVhZiBpZkRlc2Ny IHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0 eXBlIHN0cmluZzs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIGlmVHlwZSB7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBpYW5hOklm VHlwZTs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIGlmTXR1IHs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0eXBlIGludDMyOzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyPg0KJm5ic3A7ICZuYnNwOyB9PGJy Pg0KJm5ic3A7fTxicj4NCjxicj4NCiZuYnNwO1RoZW4sIGluIG5hbWVzcGFjZSA8YSBocmVmPSJo dHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2RzMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9leGFt cGxlLmNvbS9zY2hlbWEvZHMwPC9hPiwgd2UgaGF2ZTo8YnI+DQo8YnI+DQombmJzcDtpbXBvcnQg aW50ZXJmYWNlLW1vZHVsZSB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtwcmVmaXggJnF1b3Q7 aWYmcXVvdDs7PGJyPg0KJm5ic3A7fTxicj4NCjxicj4NCiZuYnNwO2F1Z21lbnQgJnF1b3Q7L2lm OmludGVyZmFjZXMvaWY6aWZFbnRyeSZxdW90OyB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt3 aGVuICZxdW90O2lmOmlmVHlwZT0nZHMwJyZxdW90Ozs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw O2xlYWYgZHMwQ2hhbm5lbE51bWJlciB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3R5cGUgQ2hhbm5lbE51bWJlcjs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO308YnI+ DQombmJzcDt9PGJyPg0KPGJyPg0KJm5ic3A7QSBjb3JyZXNwb25kaW5nIG5ldGNvbmYgWE1MIGlu c3RhbmNlIGV4YW1wbGU6PGJyPg0KPGJyPg0KJm5ic3A7Jmx0O2ludGVyZmFjZXMgeG1sbnM9JnF1 b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2VzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9pbnRlcmZhY2VzPC9hPiZxdW90OyB4 bWxuczpkczA9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS9kczAiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2RzMDwvYT4mcXVvdDsmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDtpZkVudHJ5Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0O2lmSW5kZXgmZ3Q7MSZsdDsvaWZJbmRleCZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyZsdDtpZkRlc2NyJmd0O0ZsaW50c3RvbmUgSW5jIEV0aGVybmV0IEE1NjImbHQ7L2lmRGVz Y3ImZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZUeXBlJmd0O2V0aGVybmV0Q3Nt YWNkJmx0Oy9pZlR5cGUmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7aWZNdHUmZ3Q7 MTUwMCZsdDsvaWZNdHUmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDsvaWZFbnRyeSZndDs8YnI+ DQombmJzcDsgJm5ic3A7Jmx0O2lmRW50cnkmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsm bHQ7aWZJbmRleCZndDsyJmx0Oy9pZkluZGV4Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O2lmRGVzY3ImZ3Q7RmxpbnRzdG9uZSBJbmMgRFMwJmx0Oy9pZkRlc2NyJmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2lmVHlwZSZndDtkczAmbHQ7L2lmVHlwZSZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtkczA6ZHMwQ2hhbm5lbE51bWJlciZndDsxJmx0Oy9kczA6 ZHMwQ2hhbm5lbE51bWJlciZndDs8YnI+DQombmJzcDsgJm5ic3A7Jmx0Oy9pZkVudHJ5Jmd0Ozxi cj4NCiZuYnNwOyZsdDsvaW50ZXJmYWNlcyZndDs8YnI+DQo8YnI+DQpBYm91dCB0aGUgUkVTVENP TkYsIG15IHByb2JsZW1zIGFyZTo8YnI+DQo8YnI+DQoxLiBJbiB0aGUgR0VUIG9wZXJhdGlvbiwg aG93IHRvIHN1cHBvcnQgaXQsIHdlIGhhdmUgZG93bmxvYWQgdGhlIEdFVCB0d28gdGltZXM/IFRv IGdldCAmcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXMi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2ludGVyZmFjZXM8L2E+ JnF1b3Q7IGFuZCAmcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hL2RzMCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvZHMwPC9hPiZxdW90Ow0K IHNlcGFyYXRlbHk/IE9yIHNvbWV0aGluZyBJIG1pc3NlZCB0byBnZXQgYWxsIGluZm9ybWF0aW9u IGluIG9uZSByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PllvdSBkb24ndCBnZXQgbmFtZXNwYWNlcywgeW91IGdldCBzdWJ0cmVlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhlICZxdW90O2ZpZWxkcyZxdW90OyBwYXJhbWV0ZXIgaXMgYXZhaWxhYmxlIHRv IHNlbGVjdCBtdWx0aXBsZSBkaXNqb2ludDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5zdWJ0cmVlcyBp biBvbmUgcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjIuIEluIHRoZSBQVVQgb3BlcmF0aW9uLiBUaGUgcXVlc3Rpb24gaXMgc2Ft ZSwgaG93IHRvIHNldCB0aGUgbmFtZXNwYWNlLCBtYXkgSSBjaGFuZ2UgdGhlIE1UVSBhbmQgQ2hh bm5lbE51bWJlciB0b2dldGhlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Ugd291bGQgdXNlIFBBVENIIGZvciB0aGF0LCBub3QgUFVU LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5FaXRoZXIgWUFORyBQYXRjaCBvciBhIHBsYWluIHBhdGNo IG9uIHRoZSBpbnRlcmZhY2UgZW50cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+d291bGQgYWxsb3cg bXVsdGlwbGUgZGVzY2VuZGFudCBub2RlcyB0byBiZSBjaGFuZ2VkIGF0IG9uY2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+TWF5YmUgSSBtaXNzIHNvbWUgaW1wb3J0YW50IG9wZXJhdGlvbiwg Y2FuIHNvbWVib2R5IHByb3ZpZGUgYSBleGFtcGxlPzxicj4NCjxicj4NClRoYW5rczxicj4NCllh bmdhbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1v ZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D496C972D1A13540A730720631EC734184AAB4D0nkgeml507mbschi_-- From nobody Fri Oct 9 14:58: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 49CC91B4D6C; Fri, 9 Oct 2015 14:57:59 -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 fpoEWYTg9iUw; Fri, 9 Oct 2015 14:57:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C441B4D6A; Fri, 9 Oct 2015 14:57:57 -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: 6.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151009215757.20574.48772.idtracker@ietfa.amsl.com> Date: Fri, 09 Oct 2015 14:57:57 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 21:57:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Server and RESTCONF Server Configuration Models Authors : Kent Watsen Juergen Schoenwaelder Filename : draft-ietf-netconf-server-model-08.txt Pages : 65 Date : 2015-10-09 Abstract: This draft defines a NETCONF server configuration data model and a RESTCONF server configuration data model. These data models enable configuration of the NETCONF and RESTCONF services themselves, including which transports are supported, what ports the servers listen on, call-home parameters, client authentication, and related parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-server-model-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-server-model-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 9 15:31: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 3BB281B2B3E for ; Fri, 9 Oct 2015 15:31: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, 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 sJI0URHNmd2n for ; Fri, 9 Oct 2015 15:31:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5F51B2A60 for ; Fri, 9 Oct 2015 15:31:56 -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.293.16; Fri, 9 Oct 2015 22:31:54 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) with mapi id 15.01.0293.007; Fri, 9 Oct 2015 22:31:54 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-08.txt Thread-Index: AQHRAt2hDCTo5g0U+0WNOO6VWBX0YJ5je8yA Date: Fri, 9 Oct 2015 22:31:54 +0000 Message-ID: References: <20151009215757.20574.48772.idtracker@ietfa.amsl.com> In-Reply-To: <20151009215757.20574.48772.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 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:B+XUuZW9ewNELy0HAwfyfK2BeuUJ2EqV+Oj231lq1Cbb4IEeE4dFIokz3mZ0RLy7nnvvTSivmtVt4ZQCF9unSbQtXx9dRQwxhLWgZZYKcokR/iABrJBcpoRp01ab7kr/sQXCjhR7q9ZR9fdUyBFf8A==; 24:ClQD5aayQydeq4J/UxVn+56gc/+WkXPkIeI2FNu5BzP5oxHuJED21nkxbzU8JsL1eA2XK1dTsSMlehWC2R8/rfGyccCpVUK2ym8s+Dyr7vE=; 20:z8aqp9KJBOxwgydyztPzFQS9XMTQqyaxsI6/j13xYtGbYXjbm0OmKmM6FfRel2OgKBgHSsFAHF7jQLLM2XTNJw== 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)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0724FCD4CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(164054003)(53754006)(199003)(24454002)(377454003)(189002)(479174004)(19580395003)(66066001)(101416001)(5008740100001)(86362001)(19580405001)(189998001)(102836002)(11100500001)(5002640100001)(92566002)(2501003)(105586002)(230783001)(50986999)(40100003)(122556002)(76176999)(15975445007)(54356999)(106116001)(106356001)(10400500002)(2351001)(5004730100002)(64706001)(36756003)(450100001)(46102003)(5007970100001)(99286002)(4001350100001)(5001920100001)(107886002)(2950100001)(5001960100002)(83506001)(87936001)(97736004)(81156007)(2900100001)(110136002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM 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: 09 Oct 2015 22:31:54.1436 (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] I-D Action: draft-ietf-netconf-server-model-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 22:31:58 -0000 Hi All, This update primarily implements the decision from IETF 93 to adopt the keychain-based approach that was described in the Appendix of the -07 draft. This is the draft that I hope to present at the SAAG meeting, to recruit interest from security experts there. Thanks, Kent On 10/9/15, 5:57 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Server and RESTCONF Server >Configuration Models > Authors : Kent Watsen > Juergen Schoenwaelder > Filename : draft-ietf-netconf-server-model-08.txt > Pages : 65 > Date : 2015-10-09 > >Abstract: > This draft defines a NETCONF server configuration data model and a > RESTCONF server configuration data model. These data models enable > configuration of the NETCONF and RESTCONF services themselves, > including which transports are supported, what ports the servers > listen on, call-home parameters, client authentication, and related > parameters. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-netconf-server-model-08 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-server-model-08 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Oct 12 00:50: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 34B4E1A6F22; Mon, 12 Oct 2015 00:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 mICwDCCr0mvG; Mon, 12 Oct 2015 00:50:35 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD221A6F38; Mon, 12 Oct 2015 00:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6769; q=dns/txt; s=iport; t=1444636234; x=1445845834; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=t3SbzoYl07T9GNPEEDwSzlqYViob5A9Zg1xZwm11U/U=; b=XAF0Oe+PZpiz0KKvWpGwsX4MIJ/xMKDj5O9lfzKdrkYLKJVi6MsmZMUz fXycD2Eo3pFGSrmVjKJjoiE5tbJ7JAsvymmus48WKpk268hRtmJtjp6YK HSndsZoOH9rt8I3OqaMY+g93w0ZNc5QweSprwIjINuFonMQr4N7vkrlkU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnAwD1ZRtW/xbLJq1dg3puvgMBDYFaI4Jwggo1SgKBZRQBAQEBAQEBgQqEJwEBBHgRCyEWDwkDAgECAUUGAQwIAQEFiCUNvQMBAQEBAQEBAQEBAQEBAQEBAQEBGYZzhH6EOwEBBVKELgWWE4UZiAGBWIc7I45eg28fAQFChAQ8MwEBhiiBQAEBAQ X-IronPort-AV: E=Sophos;i="5.17,671,1437436800"; d="scan'208,217";a="612162071" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 12 Oct 2015 07:50:32 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9C7oVer016326; Mon, 12 Oct 2015 07:50:31 GMT To: Simon Josefsson , iesg@ietf.org, secdir@ietf.org, draft-ietf-netconf-call-home.all@tools.ietf.org, NETCONF References: <8737xnp0rm.fsf@latte.josefsson.org> From: Benoit Claise Message-ID: <561B663C.7080408@cisco.com> Date: Mon, 12 Oct 2015 09:50:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8737xnp0rm.fsf@latte.josefsson.org> Content-Type: multipart/alternative; boundary="------------030800050004050509040603" Archived-At: Subject: Re: [Netconf] review of draft-ietf-netconf-call-home-11 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 12 Oct 2015 07:50:37 -0000 This is a multi-part message in MIME format. --------------030800050004050509040603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Simon, Thanks for your review. One comment below. > Hi. > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > I believe the document is ready. > > One main security concern is the reversal of roles that this document > introduce, but letting TCP clients act as TLS/SSH servers, and vice > versa, is not unheard of. As long as proper peer authentication is > performed, and other parts of the security protocols are properly > performed, I see no fundamental problem with this. I'm sure some > implementations will need to be tweaked to deal with this, and > terminology might confusing at times. The 'Security Considerations' > section does a good job discussing this, and some other issues too. > > Two minor questions: > > 1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF? I > see no discussion of it in this draft, and text in the document > implicitly assumes host keys (SSH) or certificates (TLS) are used. > Think about TLS-PSK for example, which seems like a relevant idea for > embedded devices. This may not be the document to adress this, but if > there is work towards that goal already, it might be useful to align > this document with that. > > 2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the > [RFC6241], Section 1.1 "client".'. Shouldn't this say the term may > refer to a RESTCONF client and reference draft-ietf-netconf-restconf? > Or is that not intentional? The use of the word 'can' make this text > vague to me. The previous section (1.5) says that 'NETCONF/RESTCONF' is > an abbrevation for 'the NETCONF or the RESTCONF'. The same comment > applies to section 3. Maybe this is a misunderstanding on my side, but > the text confused me so it may be useful to resolve. I mentioned this point in my AD review (http://www.ietf.org/mail-archive/web/netconf/current/msg10535.html). I now realize that I made a typo in my email: NETCONF/RESTCONF client" _can refers_ to the RFC 6241 section 1.1 "client" This should read: "NETCONF/RESTCONF client" refers to the RFC 6241 section 1.1 "client" Ditto for NETCONF/RESTCONF server. This takes care of the confusing "can" word. Thanks for spotting that. Regarding the draft-ietf-netconf-restconf reference now. https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-1.4.1 refers to RFC 6241 for the client. So I believe that we're good with a single reference to RFC 6241 in this draft. Regards, Benoit > > Thanks, > /Simon --------------030800050004050509040603 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Simon,

Thanks for your review.
One comment below.
Hi.

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

I believe the document is ready.

One main security concern is the reversal of roles that this document
introduce, but letting TCP clients act as TLS/SSH servers, and vice
versa, is not unheard of.  As long as proper peer authentication is
performed, and other parts of the security protocols are properly
performed, I see no fundamental problem with this.  I'm sure some
implementations will need to be tweaked to deal with this, and
terminology might confusing at times.  The 'Security Considerations'
section does a good job discussing this, and some other issues too.

Two minor questions:

1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF?  I
see no discussion of it in this draft, and text in the document
implicitly assumes host keys (SSH) or certificates (TLS) are used.
Think about TLS-PSK for example, which seems like a relevant idea for
embedded devices.  This may not be the document to adress this, but if
there is work towards that goal already, it might be useful to align
this document with that.

2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the
[RFC6241], Section 1.1 "client".'.  Shouldn't this say the term may
refer to a RESTCONF client and reference draft-ietf-netconf-restconf?
Or is that not intentional?  The use of the word 'can' make this text
vague to me.  The previous section (1.5) says that 'NETCONF/RESTCONF' is
an abbrevation for 'the NETCONF or the RESTCONF'.  The same comment
applies to section 3.  Maybe this is a misunderstanding on my side, but
the text confused me so it may be useful to resolve.
I mentioned this point in my AD review (http://www.ietf.org/mail-archive/web/netconf/current/msg10535.html).
I now realize that I made a typo in my email: NETCONF/RESTCONF client" can refers to the RFC 6241 section 1.1 "client"
This should read: "NETCONF/RESTCONF client" refers to the RFC 6241 section 1.1 "client"
Ditto for NETCONF/RESTCONF server.
This takes care of the confusing "can" word. Thanks for spotting that.

Regarding the draft-ietf-netconf-restconf reference now.
https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-1.4.1 refers to RFC 6241 for the client.
So I believe that we're good with a single reference to RFC 6241 in this draft.

Regards, Benoit

Thanks,
/Simon

--------------030800050004050509040603-- From nobody Mon Oct 12 07:23: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 3F6571B3327; Mon, 12 Oct 2015 07:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0jJOlI3IwkQO; Mon, 12 Oct 2015 07:23:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5321B3325; Mon, 12 Oct 2015 07:23:10 -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.293.16; Mon, 12 Oct 2015 14:22:47 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 12 Oct 2015 14:22:47 +0000 From: Kent Watsen To: Benoit Claise , Simon Josefsson , "iesg@ietf.org" , "secdir@ietf.org" , NETCONF , "draft-ietf-netconf-call-home.all@ietf.org" Thread-Topic: [Netconf] review of draft-ietf-netconf-call-home-11 Thread-Index: AQHRANYkB04UoC2GL0O6JoJSU3KY855ng5wAgAAqloA= Date: Mon, 12 Oct 2015 14:22:47 +0000 Message-ID: References: <8737xnp0rm.fsf@latte.josefsson.org> <561B663C.7080408@cisco.com> In-Reply-To: <561B663C.7080408@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 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:mtMJbu/hjTiUoNx8Q92XiUakzMn05EW5vLtzfRCmWjo8/UXLiMNYqaZHUIXiWswR1OWoMZ+5RbY1V22a7AbOcVUquw4ZtKZYpsCJzvStuW+9B5K3OGWIDZcTAhT38dz6iwLxeDKC67K/e8Zj67zMtg==; 24:eN7ZhYoU+Tj/Lhpboey59x3sST/fvuQuUNRZyZpyFHs8bgaahZOho1/hsx3Szj8vVn0RpI+MJKYCYZBfyu2rPOIjtxdZ5+YaUZhPMDo1zSM=; 20:EZ+kCxYZi73CQNX9Y30LYbkVu9v8LgybcQpcY4aSjygIVlR4Dcwgb9gnZI5re3wjp0AiWkbJVrabi+jFBRYXxw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0727122FC6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52604005)(199003)(164054003)(377454003)(189002)(2501003)(102836002)(11100500001)(122556002)(15975445007)(2201001)(107886002)(36756003)(86362001)(5007970100001)(87936001)(105586002)(2950100001)(106116001)(189998001)(106356001)(10400500002)(2900100001)(99286002)(83506001)(40100003)(230783001)(66066001)(50986999)(5008740100001)(4001350100001)(19580405001)(76176999)(19580395003)(64706001)(97736004)(101416001)(5001770100001)(5001960100002)(5004730100002)(5002640100001)(46102003)(16236675004)(54356999)(19617315012)(92566002)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D24136E6E6AAAkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2015 14:22:47.5849 (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] review of draft-ietf-netconf-call-home-11 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 12 Oct 2015 14:23:14 -0000 --_000_D24136E6E6AAAkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Simon, Regarding your two comments: 1. Are non-certificate-based TLS out of scope for NETCONF/RESTCONF? Yes or, more specifically, both NETCONF over TLS and and RESTCONF restrict = TLS to certificates. The relevant text is in RFC 7589, Section 1 and draft= -ietf-netconf-restconf-07, Section 2.2. Do you think there should be a no= te in this draft stating this as well? 2. Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the [RFC= 6241], Section 1.1 "client".' Does Benoit's suggestion to replace "can refer" with "refers" satisfy the l= anguage vagueness issue? - And also, are you satisfied with having the si= ngle reference to RFC6241, since RESTCONF pulls the term from RFC6241 as we= ll? Thanks Kent From: Benoit Claise > Date: Monday, October 12, 2015 at 3:50 AM To: Simon Josefsson >, "ies= g@ietf.org" >, "s= ecdir@ietf.org" >, "draft-ietf-netconf-call-home.all@tools.ietf.org" >, "net= conf@ietf.org" > Subject: Re: [Netconf] review of draft-ietf-netconf-call-home-11 Hi Simon, Thanks for your review. One comment below. Hi. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe the document is ready. One main security concern is the reversal of roles that this document introduce, but letting TCP clients act as TLS/SSH servers, and vice versa, is not unheard of. As long as proper peer authentication is performed, and other parts of the security protocols are properly performed, I see no fundamental problem with this. I'm sure some implementations will need to be tweaked to deal with this, and terminology might confusing at times. The 'Security Considerations' section does a good job discussing this, and some other issues too. Two minor questions: 1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF? I see no discussion of it in this draft, and text in the document implicitly assumes host keys (SSH) or certificates (TLS) are used. Think about TLS-PSK for example, which seems like a relevant idea for embedded devices. This may not be the document to adress this, but if there is work towards that goal already, it might be useful to align this document with that. 2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the [RFC6241], Section 1.1 "client".'. Shouldn't this say the term may refer to a RESTCONF client and reference draft-ietf-netconf-restconf? Or is that not intentional? The use of the word 'can' make this text vague to me. The previous section (1.5) says that 'NETCONF/RESTCONF' is an abbrevation for 'the NETCONF or the RESTCONF'. The same comment applies to section 3. Maybe this is a misunderstanding on my side, but the text confused me so it may be useful to resolve. I mentioned this point in my AD review (http://www.ietf.org/mail-archive/we= b/netconf/current/msg10535.html). I now realize that I made a typo in my email: NETCONF/RESTCONF client" can = refers to the RFC 6241 section 1.1 "client" This should read: "NETCONF/RESTCONF client" refers to the RFC 6241 section= 1.1 "client" Ditto for NETCONF/RESTCONF server. This takes care of the confusing "can" word. Thanks for spotting that. Regarding the draft-ietf-netconf-restconf reference now. https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-1.4.1 re= fers to RFC 6241 for the client. So I believe that we're good with a single reference to RFC 6241 in this dr= aft. Regards, Benoit Thanks, /Simon --_000_D24136E6E6AAAkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <46940D7A31DB374695DC0CB634C6641E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Simon,


Regarding your two comments:

1. Are non-certificate-based TLS out= of scope for NETCONF/RESTCONF?

Yes or, more specifically, both NETC= ONF over TLS and and RESTCONF= restrict TLS to certificates.  The relevant text is in RFC 7589, Section 1 and draft-ietf-netconf-restconf-07, Section 2.2.   Do you t= hink there should be a note in this draft stating this as well?

2. Secti= on 2 says 'The term "NETCONF/RESTCONF client" can refer to the [R= FC6241], Section 1.1 "client".'

Does Benoit's suggestion to replace = "can refer" with "refers" satisfy the language vaguenes= s issue?   - And also, are you satisfied with having the single refere= nce to RFC6241, since RESTCONF pulls the term from RFC6241 as well?


Thanks
Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Monday, October 12, 2015 at 3= :50 AM
To: Simon Josefsson <simon@josefsson.org>, "iesg@ietf.org" <iesg@ietf.org>, "secd= ir@ietf.org" <secdir@ietf.org>, "draft-ietf-n= etconf-call-home.all@tools.ietf.org" <draft-ietf-netconf-call-home.all@= tools.ietf.org>, "netconf@ietf.org" <<= a href=3D"mailto:netconf@ietf.org">netconf@ietf.org>
Subject: Re: [Netconf] review of dr= aft-ietf-netconf-call-home-11

Hi Simon,

Thanks for your review.
One comment below.
Hi.

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

I believe the document is ready.

One main security concern is the reversal of roles that this document
introduce, but letting TCP clients act as TLS/SSH servers, and vice
versa, is not unheard of.  As long as proper peer authentication is
performed, and other parts of the security protocols are properly
performed, I see no fundamental problem with this.  I'm sure some
implementations will need to be tweaked to deal with this, and
terminology might confusing at times.  The 'Security Considerations'
section does a good job discussing this, and some other issues too.

Two minor questions:

1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF?  I
see no discussion of it in this draft, and text in the document
implicitly assumes host keys (SSH) or certificates (TLS) are used.
Think about TLS-PSK for example, which seems like a relevant idea for
embedded devices.  This may not be the document to adress this, but if
there is work towards that goal already, it might be useful to align
this document with that.

2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer t=
o the
[RFC6241], Section 1.1 "client".'.  Shouldn't this say the term m=
ay
refer to a RESTCONF client and reference draft-ietf-netconf-restconf?
Or is that not intentional?  The use of the word 'can' make this text
vague to me.  The previous section (1.5) says that 'NETCONF/RESTCONF' is
an abbrevation for 'the NETCONF or the RESTCONF'.  The same comment
applies to section 3.  Maybe this is a misunderstanding on my side, but
the text confused me so it may be useful to resolve.
I mentioned this point in my AD review (http://www.ietf.org/mail-archive/web/netconf/current/msg10535.html). I now realize that I made a typo in my email: NETCONF/RESTCONF client"= can refers to the RFC 6241 section 1.1 "client"
This should read:  "NETCONF/RESTCONF client" refers to the R= FC 6241 section 1.1 "client"
Ditto for NETCONF/RESTCONF server.
This takes care of the confusing "can" word. Thanks for spotting = that.

Regarding the draft-ietf-netconf-restconf reference now.
https://tools.ietf.org/html/draft= -ietf-netconf-restconf-07#section-1.4.1 refers to RFC 6241 for the clie= nt.
So I believe that we're good with a single reference to RFC 6241 in this dr= aft.

Regards, Benoit
Thanks,
/Simon

--_000_D24136E6E6AAAkwatsenjunipernet_-- From nobody Tue Oct 13 20:37: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 78D9D1A3B9B for ; Tue, 13 Oct 2015 20:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 O6LonTd1FIGs for ; Tue, 13 Oct 2015 20:37:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5BF1A1BEC for ; Tue, 13 Oct 2015 20:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6620; q=dns/txt; s=iport; t=1444793835; x=1446003435; h=from:to:cc:subject:date:message-id:mime-version; bh=697mx2CNhnsC0yE68xSzZENz37XDmy89XDCxQH/3cZQ=; b=E4IQndd9pZGYHJu6+1A+0F1UzSJInFzusXOAqahe2SEUA4HriTG3UJ+O 1SUT2j8oBmHMh2F3D1FJKxhwPyYaRmtqMm63d6AL3+ZJqbGBxwLnd5qqR wWe+dEQtFX/YJZ4euAEbLNU9UxoenklzVIMBiKWkeFT1Cbe8ZdLYJiPlU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DrAgDxzB1W/49dJa1egllNVG4GuWmEIgENgVoXAQmCcoIKNUqBRjgUAQEBAQEBAX8LhCkELUwSAS1TJgEEDg0BiCUNwlgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnWEfoQ7AQFQgjVPgTEFlhYBjRKBX5ZBg24BHwEBQoQCcQGFMDqBBgEBAQ X-IronPort-AV: E=Sophos; i="5.17,681,1437436800"; d="scan'208,217"; a="35487505" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP; 14 Oct 2015 03:37:14 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t9E3bEHE003532 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 14 Oct 2015 03:37:14 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 13 Oct 2015 22:37:01 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Tue, 13 Oct 2015 22:37:01 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9w== Date: Wed, 14 Oct 2015 03:37:01 +0000 Message-ID: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> 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: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_203b7493c8b0494fa6c266cebe37381eXCHALN013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 14 Oct 2015 03:37:20 -0000 --_000_203b7493c8b0494fa6c266cebe37381eXCHALN013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: * proposes Restconf subscription and push mechanisms to continuously st= ream information from YANG datastores over HTTP * provides a mechanism to support static subscriptions so that an opera= tor can stream updates over HTTP without Restconf * provides YANG model extensions to leverage HTTP/2 so that individual = subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard --_000_203b7493c8b0494fa6c266cebe37381eXCHALN013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are a couple new drafts posted in NETCONF:

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-netconf-yang-push-02= .txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-restconf-yang-push-00= .txt

Extends draft-clemm-netconf-yang-push in the following ways:

· =     proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

· =     provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

· =     provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 

--_000_203b7493c8b0494fa6c266cebe37381eXCHALN013ciscocom_-- From nobody Wed Oct 14 15:50:12 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 D68741B2BA7; Wed, 14 Oct 2015 15:50: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 W08mXD91dIsa; Wed, 14 Oct 2015 15:50:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BEB1B2B9C; Wed, 14 Oct 2015 15:50:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151014225009.10542.33559.idtracker@ietfa.amsl.com> Date: Wed, 14 Oct 2015 15:50:09 -0700 Archived-At: Cc: netconf-chairs@ietf.org, netconf@ietf.org Subject: [Netconf] Ben Campbell's No Objection on charter-ietf-netconf-17-00: (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: Wed, 14 Oct 2015 22:50:11 -0000 Ben Campbell has entered the following ballot position for charter-ietf-netconf-17-00: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- You might consider moving the paragraph about producing a status report in a later stage to after the text about work items for the current phase. Item 1: Can you give the full draft names for the mentioned drafts? item 2: This seems like several items. From nobody Wed Oct 14 19:50:16 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 A04231B2F43; Wed, 14 Oct 2015 19:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoYdRDeFvBxF; Wed, 14 Oct 2015 19:50:13 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 37F801B2F40; Wed, 14 Oct 2015 19:50:10 -0700 (PDT) Received: by vkaw128 with SMTP id w128so41585675vka.0; Wed, 14 Oct 2015 19:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f0LKR+LYZ3qRuvuaRoboyd9puF1WTQzPbpmvcwDsyb8=; b=qdUzzIOEEwNcDMgoq7UA2F4hpZdcIw5YmgBM4R2+rIj+dV0siF4K/6FHx9uZmDW+3d 7La8v9XTrJ6C5xAEWEA1Jy+Ojeih8Gvc+1VrB0Q7ZtBPfg6dZrVq2IOrqHCjIBfG5ugo JK6pd5RhF59srFMR0twiu4nZV0WvtZRxcx6sMu7K8jLnyxbA8AnDhQeUeVvgrXYaqlPt wtyOzE79lzV7ZtMCdaWqI6L2VI0qdyW2hdvpbMAYXMtEydsDLeKcoMgmOJjYz0dAOpGm XJ3ZB9Thkj5zMzmkWpBYTIkm3t5qh+cqrtt+VIoL643TsEEqiAdvBYR3j+m6vO3NMmde SLMw== MIME-Version: 1.0 X-Received: by 10.31.58.137 with SMTP id h131mr3458071vka.130.1444877409336; Wed, 14 Oct 2015 19:50:09 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Wed, 14 Oct 2015 19:50:09 -0700 (PDT) Date: Wed, 14 Oct 2015 22:50:09 -0400 X-Google-Sender-Auth: Ao8jvunf8FmXrXrFDqa_l2hYRFk Message-ID: From: Barry Leiba To: Netconf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netconf-ads@ietf.org Subject: [Netconf] On the registration policy for the NETCONF Capability URNs registry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2015 02:50:14 -0000 For any who haven't followed it, we had a discussion about the experimental document draft-mm-netconf-time-capability, which registers a NETCONF capability URN. Here's my last comment on the point, after I cleared my DISCUSS ballot: ---------- The registration policy for the NETCONF Capability URNs registry is Standards Action, and this document, with Experimental status, does not meet the requirement that the registration come from a Standards Track RFC. This document cannot make that registration. After discussion about whether the IESG should make an exception in this case and allow the registration, I agree that it's the right thing to do for this document, so I've cleared my DISCUSS ballot on that point. But at the same time, it seems that the registration policy is too strict, and should be IETF Review, which allows the NETCONF working group to make the decision by getting IETF consensus on the registration -- there's no need to specifically require a Standards Track RFC. To that end, I've submitted an Internet draft, draft-leiba-netmod-regpolicy-update, which I ask the Network Operations AD to sponsor, in coordination with the NETCONF working group. ---------- I typo'ed the filename (made it "-netmod-" rather than "-netconf-"); sorry about that. In any case, the NETCONF working group should look at it and comment. It's straightforward, just changing the registration policy and explaining why. I don't expect there'll be controversy with it, but please do give it a review and comment, and let Beno=C3=AEt and Joel know if y'all think it's acceptable for one of them to AD-sponsor: https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/ Please keep me on CC for any discussion, so I'll see the messages, though I'll also keep an eye on the mailing list archive. Thanks, Barry, ART AD From nobody Thu Oct 15 01:36: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 8C8D71A90C3; Thu, 15 Oct 2015 01:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 cF1zqUJHzWrh; Thu, 15 Oct 2015 01:36:14 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29901A908F; Thu, 15 Oct 2015 01:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1986; q=dns/txt; s=iport; t=1444898174; x=1446107774; h=to:cc:from:subject:message-id:date:mime-version; bh=YCg2jHhXPWCZ3gqSmjo8M59ULPlwPLK4kZjhS4ZpHqk=; b=JoX4+RYg8pIz1LgkxQwTygnpel7IyKrMTulL3tH8YUnjJc3emGRMrWOs p2Bl0g1w15QsBmRUnc4pQLeWFshr9z+vf+qRMkLYZNlmC8YTAThS/Gmxm 3P8mK4YFPQ0AxAnBQJhBsmNSM5VNhh5SYLsNH+UU7vDgG0ZNJm1vTRPkq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoBADNZB9W/xbLJq1eg3qtV4wthggjhXmCDQEBAQEBAYELhCknVQEfARwWCwILAwIBAgFLAQwIAQGIKg2vUpM3AQEBAQEBAQMBAQEBAQEBARYEhnaKC4JwgUUFlheFGYgCiROSeGOEBTyGGgEBAQ X-IronPort-AV: E=Sophos;i="5.17,684,1437436800"; d="scan'208,217";a="607623161" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 15 Oct 2015 08:36:11 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9F8a9aR032231; Thu, 15 Oct 2015 08:36:10 GMT To: "'Barry Leiba'" , IESG IESG From: Benoit Claise Message-ID: <561F656A.8030407@cisco.com> Date: Thu, 15 Oct 2015 10:35:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010605000409090502090706" Archived-At: Cc: NETCONF , "netconf-chairs@tools.ietf.org" Subject: [Netconf] Barry Leiba's No Objection on charter-ietf-netconf-17-00: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2015 08:36:15 -0000 This is a multi-part message in MIME format. --------------010605000409090502090706 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is Barry's comment at https://datatracker.ietf.org/doc/charter-ietf-netconf/ballot/#barry-leiba One question: For work item 2, is it intended to have that be https-only? If so, should the charter say that? If not, why not? That makes sense. https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-2 mandates https-only. I modified the charter text (https://datatracker.ietf.org/doc/charter-ietf-netconf/) to include "secure HTTP" Regards, Benoit --------------010605000409090502090706 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Here is Barry's comment at https://datatracker.ietf.org/doc/charter-ietf-netconf/ballot/#barry-leiba
One question:
For work item 2, is it intended to have that be https-only?  
If so, should the charter say that?  If not, why not?
That makes sense. https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-2 mandates https-only.
I modified the charter text (https://datatracker.ietf.org/doc/charter-ietf-netconf/) to include "secure HTTP"

Regards, Benoit
--------------010605000409090502090706-- From nobody Thu Oct 15 05:53: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 00EAD1B3141; Thu, 15 Oct 2015 05:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6Xai3wJSacH; Thu, 15 Oct 2015 05:53:15 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 D3D2F1B313F; Thu, 15 Oct 2015 05:53:14 -0700 (PDT) Received: by vkex70 with SMTP id x70so41190816vke.3; Thu, 15 Oct 2015 05:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FGmuP8KgkTENtitofdJkfKMIgJ3tirvrl9cnSEEDqHk=; b=rr1twoOxdBeyOWLZBlExsOY9UogZ9g1k4WKxoQJ43YgFkNI7N5wUxr5bOfQzLaEgg8 I9f/tGvNz0yWkuh0zh/t0nwuMhz11S9zy0Z6j9wyHRsJ5JVMhHhyC/0KoZegYqB1Ow50 F7IjrRodKHTl62zeX8hs4+NpZY25KCQCz10tj/P1pv9FP2stcobkCsHQ1mbosSMxf5er xq/9Z/fCwsanEcWGSwkXQexZiNPvOHQjJHAEvx0Cfj3fX2K/lliJw7PKe1DS/UJzTbBg msIfrih2if7sTIjTjF57ANqrn2bbjlTMFEBtFslqmMKFCcnbN+rAGdto0xbjutjKVzcl HdYA== MIME-Version: 1.0 X-Received: by 10.31.170.80 with SMTP id t77mr5531182vke.156.1444913594010; Thu, 15 Oct 2015 05:53:14 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Thu, 15 Oct 2015 05:53:13 -0700 (PDT) In-Reply-To: <561F656A.8030407@cisco.com> References: <561F656A.8030407@cisco.com> Date: Thu, 15 Oct 2015 08:53:13 -0400 X-Google-Sender-Auth: MT3toU4xbLjYIN8mNR5gMSlBN2M Message-ID: From: Barry Leiba To: Benoit Claise Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IESG IESG , "netconf-chairs@tools.ietf.org" , NETCONF Subject: Re: [Netconf] Barry Leiba's No Objection on charter-ietf-netconf-17-00: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2015 12:53:16 -0000 >> One question: >> For work item 2, is it intended to have that be https-only? >> If so, should the charter say that? If not, why not? > > That makes sense. > https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-2 > mandates https-only. > I modified the charter text > (https://datatracker.ietf.org/doc/charter-ietf-netconf/) to include "secure > HTTP" Thanks! Barry From nobody Thu Oct 15 06:32: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 8A5C31B31DC; Thu, 15 Oct 2015 06:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 WIkcNvkrLb8m; Thu, 15 Oct 2015 06:32:51 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEEB1B31DA; Thu, 15 Oct 2015 06:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5284; q=dns/txt; s=iport; t=1444915972; x=1446125572; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=DKgu+9MT7Us/gfEegLAqhdugIaoJV9M3R+ZMH+lYR74=; b=M4Wa7KzWaHC7MmSglT18zmEc9Zfl4eHeh1oi8BGzAjioFr8bi/AVqVqm rugm7YGMV6TCjLzC18fPohDWIe8MaRh04J7Q9BcBGsknd+eSqgs01iQgP tAt/6Q0OCFkeiqN3XCcYoEtFcgbv/7NVx++yfzhJlx3nT28ExgGA4xidt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DfAQBwqh9W/xbLJq1eg3pvtB2EfoQhAQ2BWSGFewKBaBQBAQEBAQEBgQqEJwEBBCNRBAEQCwQUCRYLAgIJAwIBAgFFBgEMCAEBiCoNr1eTMQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGdoR+hCoRAQZLB4JpgUUFhz2OXoUZiAKBWEiDcoMBknwfAQFChAU8hFqBQAEBAQ X-IronPort-AV: E=Sophos;i="5.17,685,1437436800"; d="scan'208,217";a="612233478" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 15 Oct 2015 13:32:49 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t9FDWm5C027424; Thu, 15 Oct 2015 13:32:48 GMT To: Ben Campbell , The IESG References: <20151014225009.10542.33559.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <561FAAF2.1030903@cisco.com> Date: Thu, 15 Oct 2015 15:32:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151014225009.10542.33559.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090400070703070803000401" Archived-At: Cc: netconf-chairs@ietf.org, netconf@ietf.org Subject: Re: [Netconf] Ben Campbell's No Objection on charter-ietf-netconf-17-00: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2015 13:32:53 -0000 This is a multi-part message in MIME format. --------------090400070703070803000401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/15/2015 12:50 AM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > charter-ietf-netconf-17-00: 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.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-netconf/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > You might consider moving the paragraph about producing a status report > in a later stage to after the text about work items for the current > phase. > > Item 1: Can you give the full draft names for the mentioned drafts? The current charter text is: 1. Combine the server configuration data models from the Call Home and RFC5539bis drafts in a separate Server Configuration YANG module by addressing the need for NETCONF as well as RESTCONF. It's true that RFC5539bis is now rfc7589, so explaining the history in the charter probably doesn't make sense any longer. The charter text has been changed to: 1. Provide a Server Configuration YANG module for both NETCONF and RESTCONF. > > item 2: This seems like several items. That's right. It was initially a single document, but the WG decided to split it into draft-ietf-netconf-yang-library-01 draft-ietf-netconf-yang-patch-05 draft-ietf-netconf-restconf-07 The charter text reflects the different work items (without mentioning the draft names, granted) Note that these are already WG documents. Regards, Benoit > > > . > --------------090400070703070803000401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/15/2015 12:50 AM, Ben Campbell wrote:
Ben Campbell has entered the following ballot position for
charter-ietf-netconf-17-00: 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.)



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



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

You might consider moving the paragraph about producing a status report
in a later stage to after the text about work items for the current
phase.

Item 1: Can you give the full draft names for the mentioned drafts?
The current charter text is:
  1. Combine the server configuration data models from the Call Home and
RFC5539bis drafts in a separate Server Configuration YANG module by addressing
the need for NETCONF as well as RESTCONF.
It's true that RFC5539bis is now rfc7589, so explaining the history in the charter probably doesn't make sense any longer.

The charter text has been changed to:
  1. Provide a Server Configuration YANG module for both NETCONF and RESTCONF.   

item 2: This seems like several items.
That's right. It was initially a single document, but the WG decided to split it into
draft-ietf-netconf-yang-library-01
draft-ietf-netconf-yang-patch-05
draft-ietf-netconf-restconf-07

The charter text reflects the different work items (without mentioning the draft names, granted)
Note that these are already WG documents.

Regards, Benoit






.

--------------090400070703070803000401-- From nobody Thu Oct 15 06:55:06 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 6F8861B3225; Thu, 15 Oct 2015 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 O-pr1Qb6LD4J; Thu, 15 Oct 2015 06:55:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 574761B3230; Thu, 15 Oct 2015 06:55:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151015135502.25454.19209.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 06:55:02 -0700 Archived-At: Cc: netconf-chairs@ietf.org, netconf@ietf.org Subject: [Netconf] Kathleen Moriarty's No Objection on charter-ietf-netconf-17-02: (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: Thu, 15 Oct 2015 13:55:03 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-netconf-17-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Could you expand on "secure HTTP"? Does this mean session encryption and authentication will be secure, one or the other, or something else? Thanks. From nobody Thu Oct 15 07:02: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 0ED911B324A; Thu, 15 Oct 2015 07:02: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 S55WCztlajEj; Thu, 15 Oct 2015 07:02:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2DD1B322B; Thu, 15 Oct 2015 07:02:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151015140218.4784.90071.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 07:02:18 -0700 Archived-At: Cc: netconf-chairs@ietf.org, netconf@ietf.org Subject: [Netconf] Stephen Farrell's No Objection on charter-ietf-netconf-17-02: (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: Thu, 15 Oct 2015 14:02:20 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-netconf-17-02: 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.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netconf/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hmm - how is the push mechanism going to work? There is a chance such a proposal might cause a fuss later, so could be useful to ensure we have a sane starting point now - do we? From nobody Thu Oct 15 13:48:06 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 4EBFF1A1A1E; Thu, 15 Oct 2015 13:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D09InP4rIxGk; Thu, 15 Oct 2015 13:48:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 037A81A1B1D; Thu, 15 Oct 2015 13:48:02 -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: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151015204802.12988.78970.idtracker@ietfa.amsl.com> Date: Thu, 15 Oct 2015 13:48:02 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 20:48:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Subscribing to YANG datastore push updates Authors : Alexander Clemm Alberto Gonzalez Prieto Eric Voit Filename : draft-ietf-netconf-yang-push-00.txt Pages : 51 Date : 2015-10-15 Abstract: This document defines a subscription and push mechanism for YANG datastores. This mechanism allows client applications to request updates from a YANG datastore, which are then pushed by the server to the client per a subscription policy, without requiring additional client requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 15 13:56: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 84FF31A1B63 for ; Thu, 15 Oct 2015 13:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 RRmF04weK8W9 for ; Thu, 15 Oct 2015 13:56:50 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F211A010C for ; Thu, 15 Oct 2015 13:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9052; q=dns/txt; s=iport; t=1444942610; x=1446152210; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mvXegE+DszNPYcF2ihExNiec8+fZFqK2DE56rqUlJwM=; b=gZdBbDBQ+kNo40fuspyg+ouYLhrD3yfQWVKOF0NH1jXT5WoK1dEkr3Y/ c5m5j4gM9DH3Us7sudGjda5NwusGJOeEwpfoHOeI1kmMQxG/8jtfkDZUT PGeekm558rXQz6TAToWv1//r09JA+j+sFc8ccxEs9icYbIVllAP8s0FO5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AGAgCnEiBW/4YNJK1egllNVG4GuRaEIQENgVkXAQmFM0oCgTw4FAEBAQEBAQF/C4QmAQEBBC1MEAIBCBEEAQEOITIdCAEBBA4FCAGIJQ3DWwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLdIQ7AQFMBAeCLk+BMQWWHQGFGId7gV+WSYNuAR8BAUKEA3EBhCY6gQYBAQE X-IronPort-AV: E=Sophos;i="5.17,687,1437436800"; d="scan'208,217";a="198472462" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 15 Oct 2015 20:56:49 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9FKunAu011656 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Oct 2015 20:56:49 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 15:56:34 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 15:56:34 -0500 From: "Alexander Clemm (alex)" To: "netconf@ietf.org" Thread-Topic: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9wBWjM0g Date: Thu, 15 Oct 2015 20:56:34 +0000 Message-ID: <71c53c5ed57e448eb9dee71ced2afcac@XCH-RCD-001.cisco.com> References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> In-Reply-To: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> 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: [10.154.204.93] Content-Type: multipart/alternative; boundary="_000_71c53c5ed57e448eb9dee71ced2afcacXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2015 20:56:53 -0000 --_000_71c53c5ed57e448eb9dee71ced2afcacXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, below we noted that "draft-clemm-netconf-yang-push" would become "draft-iet= f-netconf-yang-push-00" this week. Just as an FYI, the WG draft is now po= sted: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ Kind regards --- Alex From: Eric Voit (evoit) Sent: Tuesday, October 13, 2015 8:37 PM To: netconf@ietf.org Cc: Alexander Clemm (alex) ; Alberto Gonzalez Prieto (alber= tgo) ; Ambika Prasad Tripathy (ambtripa) ; Einar Nilsen-Nygaard (einarnn) Subject: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: * proposes Restconf subscription and push mechanisms to continuously st= ream information from YANG datastores over HTTP * provides a mechanism to support static subscriptions so that an opera= tor can stream updates over HTTP without Restconf * provides YANG model extensions to leverage HTTP/2 so that individual = subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard --_000_71c53c5ed57e448eb9dee71ced2afcacXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

below we noted that “draft-clemm-netconf-yang-= push” would become “draft-ietf-netconf-yang-push-00” this= week.   Just as an FYI, the WG draft is now posted:

https://datatracker.ietf.org/doc/draft-ietf-netconf-= yang-push/

 

Kind regards

--- Alex

 

 

From: Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 8:37 PM
To: netconf@ietf.org
Cc: Alexander Clemm (alex) <alex@cisco.com>; Alberto Gonzalez = Prieto (albertgo) <albertgo@cisco.com>; Ambika Prasad Tripathy (ambtr= ipa) <ambtripa@cisco.com>; Einar Nilsen-Nygaard (einarnn) <einarnn= @cisco.com>
Subject: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

 

There are a couple new drafts posted in NETCONF:

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-netconf-yang-push-02= .txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-restconf-yang-push-00= .txt

Extends draft-clemm-netconf-yang-push in the following ways:

·   =   proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

·   =   provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

·   =   provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 

--_000_71c53c5ed57e448eb9dee71ced2afcacXCHRCD001ciscocom_-- From nobody Thu Oct 15 14: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 DE2D81A1F70 for ; Thu, 15 Oct 2015 14:15:22 -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 7h5vuMPQgArQ for ; Thu, 15 Oct 2015 14:15:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 DA85E1A1BDB for ; Thu, 15 Oct 2015 14:15:18 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id t9FLFEci019126 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Oct 2015 21:15:14 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t9FLFDQ1016857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Oct 2015 23:15:14 +0200 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 15 Oct 2015 23:15:13 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.148]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 23:15:13 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "EXT Alexander Clemm (alex)" , "netconf@ietf.org" Thread-Topic: NETCONF charter approved by the IESG WAS:RE: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEHjZ6P7XiyoHcmSZewH/BucPpFfg== Date: Thu, 15 Oct 2015 21:15:12 +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.120] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8197F73E4DEMUMBX005nsnin_" 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: 11941 X-purgate-ID: 151667::1444943714-0000047E-A5D70A02/0/0 Archived-At: Subject: [Netconf] NETCONF charter approved by the IESG WAS:RE: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2015 21:15:23 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8197F73E4DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, the draft NETCONF charter has been approved by the IESG today. As such draft-clemm-netconf-yang-push is now officially a chartered NETCONF= WG item. Please review and comment on https://tools.ietf.org/id/draft-ietf-netconf-yang-push-00.txt Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of EXT Alexander = Clemm (alex) Sent: Thursday, October 15, 2015 10:57 PM To: netconf@ietf.org Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Hello all, below we noted that "draft-clemm-netconf-yang-push" would become "draft-iet= f-netconf-yang-push-00" this week. Just as an FYI, the WG draft is now po= sted: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ Kind regards --- Alex From: Eric Voit (evoit) Sent: Tuesday, October 13, 2015 8:37 PM To: netconf@ietf.org Cc: Alexander Clemm (alex) >; Alberto= Gonzalez Prieto (albertgo) >= ; Ambika Prasad Tripathy (ambtripa) >; Einar Nilsen-Nygaard (einarnn) > Subject: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: * proposes Restconf subscription and push mechanisms to continuously st= ream information from YANG datastores over HTTP * provides a mechanism to support static subscriptions so that an opera= tor can stream updates over HTTP without Restconf * provides YANG model extensions to leverage HTTP/2 so that individual = subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard --_000_E4DE949E6CE3E34993A2FF8AE79131F8197F73E4DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,=

 

the draft NETCONF char= ter has been approved by the IESG today.

As such draft-clemm-ne= tconf-yang-push is now officially a chartered NETCONF WG item.

 

Please review and comm= ent on

https://tools.ietf.org/= id/draft-ietf-netconf-yang-push-00.txt

 

Mehmet

 

From: Netconf [mailto:netconf-bounces@ietf.or= g] On Behalf Of EXT Alexander Clemm (alex)
Sent: Thursday, October 15, 2015 10:57 PM
To: netconf@ietf.org
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF,= HTTP/2

 

Hello all,

 

below we noted that “draft-clemm-netconf-yang-= push” would become “draft-ietf-netconf-yang-push-00” this= week.   Just as an FYI, the WG draft is now posted:

https://datatracker.ietf.org/doc/draft-ietf-netconf-= yang-push/

 

Kind regards

--- Alex

 

 

From: Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 8:37 PM
To: netconf@ietf.org
Cc: Alexander Clemm (alex) <ale= x@cisco.com>; Alberto Gonzalez Prieto (albertgo) <albertgo@cisco.com>; Ambika Prasad Tripathy (= ambtripa) <ambtripa@cisco.com&= gt;; Einar Nilsen-Nygaard (einarnn) <ei= narnn@cisco.com>
Subject: New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2

 

There are a couple new drafts posted in NETCONF:

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-netconf-yang-push-02= .txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-restconf-yang-push-00= .txt

Extends draft-clemm-netconf-yang-push in the following ways:

·   =   proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

·   =   provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

·   =   provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F8197F73E4DEMUMBX005nsnin_-- From nobody Fri Oct 16 02:25: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 5B9601B34A2; Fri, 16 Oct 2015 02:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, 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 iSRLBahPBMKh; Fri, 16 Oct 2015 02:25:22 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C0A1B348C; Fri, 16 Oct 2015 02:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2750; q=dns/txt; s=iport; t=1444987518; x=1446197118; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zU5l4TKaTTTIJvBEe/AlMGl+1bexCFjvlTDRviTBLmc=; b=KC6kw4ZXk4A7ism0IRr8Ljmdt6NLwvyvFGIaP49h6RRAI2IJzbAANV9I XaFIWx3fmZl/iaiC0aF4xcPPot+3cDFPvsBXnXSZGnKJWvJctLLuGZS6v WPapPV4GA+Jm4gVlVQfbJxtzUbcUraeql1Wef1jFecyveU5fXlSKbdD2c 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DKAQD/wSBW/xbLJq1dg3q6NIQhAQ2BWSGFfQKBbBQBAQEBAQEBgQqEJwEBAwEjDwEFNgoBBQsLGgIFFgsCAgkDAgECAUUGAQwIAQGIIggNsAWTOAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKFVIR+hQ0HgmmBRQEEhz2OYIUZiAKBWIQ6gwGKNYhIHwEBQoQFPIYaAQEB X-IronPort-AV: E=Sophos;i="5.17,688,1437436800"; d="scan'208";a="612245381" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Oct 2015 09:25:15 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9G9PFjt025332; Fri, 16 Oct 2015 09:25:15 GMT To: Barry Leiba , Netconf References: From: Benoit Claise Message-ID: <5620C26D.7050202@cisco.com> Date: Fri, 16 Oct 2015 11:25:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netconf-ads@ietf.org Subject: Re: [Netconf] On the registration policy for the NETCONF Capability URNs registry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Oct 2015 09:25:23 -0000 Dear all, https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00 This document, which updates the NETCONF Capability URNs registry policy, requires the process defined in RFC 2026. This means that it needs to be discussed, reviewed by the responsible AD, given an IETF-wide last call, and reviewed and approved by the IESG. I hope that it can go fairly quickly, as it's a simple action. Therefore, I propose to keep this document as an individual submission, which I will AD sponsor. However, neither Bary nor I are going to push this ahead against the working group's opposition. So it's time to speak up if you disagree with that policy change. A final consensus call will be made during the NETCONF meeting in Yokohama. Regards, Benoit (OPS AD) > For any who haven't followed it, we had a discussion about the > experimental document draft-mm-netconf-time-capability, which > registers a NETCONF capability URN. Here's my last comment on the > point, after I cleared my DISCUSS ballot: > > ---------- > The registration policy for the NETCONF Capability URNs registry is > Standards Action, and this document, with Experimental status, does > not meet the requirement that the registration come from a Standards > Track RFC. This document cannot make that registration. > > After discussion about whether the IESG should make an exception in > this case and allow the registration, I agree that it's the right > thing to do for this document, so I've cleared my DISCUSS ballot on > that point. > > But at the same time, it seems that the registration policy is too > strict, and should be IETF Review, which allows the NETCONF working > group to make the decision by getting IETF consensus on the > registration -- there's no need to specifically require a Standards > Track RFC. To that end, I've submitted an Internet draft, > draft-leiba-netmod-regpolicy-update, which I ask the Network > Operations AD to sponsor, in coordination with the NETCONF working > group. > ---------- > > I typo'ed the filename (made it "-netmod-" rather than "-netconf-"); > sorry about that. In any case, the NETCONF working group should look > at it and comment. It's straightforward, just changing the > registration policy and explaining why. I don't expect there'll be > controversy with it, but please do give it a review and comment, and > let Benoît and Joel know if y'all think it's acceptable for one of > them to AD-sponsor: > https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/ > > Please keep me on CC for any discussion, so I'll see the messages, > though I'll also keep an eye on the mailing list archive. > > Thanks, > Barry, ART AD > . > From nobody Fri Oct 16 04:28: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 790B21A9091; Fri, 16 Oct 2015 04:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMAIkb2sdt_C; Fri, 16 Oct 2015 04:28:52 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 AE8881A9081; Fri, 16 Oct 2015 04:28:51 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t9GBSWp1016921 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 16 Oct 2015 13:28:33 +0200 Date: Fri, 16 Oct 2015 13:28:31 +0200 From: Simon Josefsson To: Kent Watsen Message-ID: <20151016132831.64b45561@latte.josefsson.org> In-Reply-To: References: <8737xnp0rm.fsf@latte.josefsson.org> <561B663C.7080408@cisco.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/XZb1.S/1zz0iQDF6+s8p5dP"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: NETCONF , "draft-ietf-netconf-call-home.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [Netconf] review of draft-ietf-netconf-call-home-11 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Oct 2015 11:28:53 -0000 --Sig_/XZb1.S/1zz0iQDF6+s8p5dP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello. Re 1: Thank you for clarification. I don't believe there is any need to repeat text from a normative reference. Re 2: Benoit's suggestion would resolv the concern for me. Thanks, /Simon > Hi Simon, >=20 >=20 > Regarding your two comments: >=20 > 1. Are non-certificate-based TLS out of scope for NETCONF/RESTCONF? >=20 > Yes or, more specifically, both NETCONF over TLS and and RESTCONF > restrict TLS to certificates. The relevant text is in RFC 7589, > Section 1 and draft-ietf-netconf-restconf-07, Section 2.2. Do you > think there should be a note in this draft stating this as well? >=20 > 2. Section 2 says 'The term "NETCONF/RESTCONF client" can refer to > the [RFC6241], Section 1.1 "client".' >=20 > Does Benoit's suggestion to replace "can refer" with "refers" satisfy > the language vagueness issue? - And also, are you satisfied with > having the single reference to RFC6241, since RESTCONF pulls the term > from RFC6241 as well? >=20 >=20 > Thanks > Kent >=20 >=20 > From: Benoit Claise > > Date: Monday, October 12, 2015 at 3:50 AM > To: Simon Josefsson > >, > "iesg@ietf.org" > >, > "secdir@ietf.org" > >, > "draft-ietf-netconf-call-home.all@tools.ietf.org" > >, > "netconf@ietf.org" > > Subject: Re: [Netconf] > review of draft-ietf-netconf-call-home-11 >=20 > Hi Simon, >=20 > Thanks for your review. > One comment below. >=20 > Hi. >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > I believe the document is ready. >=20 > One main security concern is the reversal of roles that this document > introduce, but letting TCP clients act as TLS/SSH servers, and vice > versa, is not unheard of. As long as proper peer authentication is > performed, and other parts of the security protocols are properly > performed, I see no fundamental problem with this. I'm sure some > implementations will need to be tweaked to deal with this, and > terminology might confusing at times. The 'Security Considerations' > section does a good job discussing this, and some other issues too. >=20 > Two minor questions: >=20 > 1) Are non-certificate-based TLS out of scope for NETCONF/RESTCONF? I > see no discussion of it in this draft, and text in the document > implicitly assumes host keys (SSH) or certificates (TLS) are used. > Think about TLS-PSK for example, which seems like a relevant idea for > embedded devices. This may not be the document to adress this, but if > there is work towards that goal already, it might be useful to align > this document with that. >=20 > 2) Section 2 says 'The term "NETCONF/RESTCONF client" can refer to the > [RFC6241], Section 1.1 "client".'. Shouldn't this say the term may > refer to a RESTCONF client and reference draft-ietf-netconf-restconf? > Or is that not intentional? The use of the word 'can' make this text > vague to me. The previous section (1.5) says that 'NETCONF/RESTCONF' > is an abbrevation for 'the NETCONF or the RESTCONF'. The same comment > applies to section 3. Maybe this is a misunderstanding on my side, > but the text confused me so it may be useful to resolve. >=20 > I mentioned this point in my AD review > (http://www.ietf.org/mail-archive/web/netconf/current/msg10535.html). > I now realize that I made a typo in my email: NETCONF/RESTCONF > client" can refers to the RFC 6241 section 1.1 "client" This should > read: "NETCONF/RESTCONF client" refers to the RFC 6241 section 1.1 > "client" Ditto for NETCONF/RESTCONF server. This takes care of the > confusing "can" word. Thanks for spotting that. >=20 > Regarding the draft-ietf-netconf-restconf reference now. > https://tools.ietf.org/html/draft-ietf-netconf-restconf-07#section-1.4.1 > refers to RFC 6241 for the client. So I believe that we're good with > a single reference to RFC 6241 in this draft. >=20 > Regards, Benoit >=20 > Thanks, > /Simon >=20 >=20 --Sig_/XZb1.S/1zz0iQDF6+s8p5dP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWIN9fAAoJEIYLf7sy+BGd5tEH/0kFzvGBuc72odkQ3Spn0XZP n8SZRkKWJoGy23OiMccZNdj/DeDjSdujvkvpQCOx4S2ONPY9wTWDw7GKYnq/9va+ GLCICkQhhabds9Rqjp4yp/D30C1CRaQuEFdeC5ng4qVQr/CCicZMaGqvxbae4oZG JfvmLRTx4iCIaQZPFx5ap8gLCoUJEMGzZt1+GDIL1eHeTH195q6oxbeHy65ckE6h +1HYBPuD0eNacfBSMh5CAyS/0xrdLWCFJ/n/jQoM7YQGDpc685hW/7FNlNSATis9 xJyLsAxPiXhnKgcnVc8vmcUXSMCyWET+ymJRqTyC2/P1MUkhlMenl6tyDxvpzgQ= =acQw -----END PGP SIGNATURE----- --Sig_/XZb1.S/1zz0iQDF6+s8p5dP-- From nobody Fri Oct 16 07:13:06 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 733E11B2AAC; Fri, 16 Oct 2015 07:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwkTEIldvUgT; Fri, 16 Oct 2015 07:13:02 -0700 (PDT) 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 906A11B2B68; Fri, 16 Oct 2015 07:13:01 -0700 (PDT) Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 16 Oct 2015 14:12:57 +0000 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.293.16; Fri, 16 Oct 2015 14:12:55 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Fri, 16 Oct 2015 14:12:55 +0000 From: Kent Watsen To: Benoit Claise , Barry Leiba , Netconf Thread-Topic: [Netconf] On the registration policy for the NETCONF Capability URNs registry Thread-Index: AQHRB/Sg5pV4xmykV0OJvrIRdwQYyJ5t5oaA Date: Fri, 16 Oct 2015 14:12:55 +0000 Message-ID: References: <5620C26D.7050202@cisco.com> In-Reply-To: <5620C26D.7050202@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 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:C50t5nNG7+I5oqoFOBpjpFr0k+WsFgXDT8cDgh8ENSKnQP81/bY5tUDGo35x5o5tGqxVGMZ9qS4PFkeoEhzdTuIswroUTod2uVBsv8d/oR8t0i8NbpTycM7PxHAJhTDNsSNWpBPzCszfGe9RryEnnQ==; 24:bOdJt1mSy6Vdb4rZi4ugxQwtbIwikVyDPw2OldO79V7ySxC0qUTPnHYgZUarh+tD9lQNMjKkKWjhOI2oLa3ZW07XD245eRP2r296j8D0Xv4=; 20:UX7w3d6w/Ve7fPBuDpOllxmhOBqcAa319dW290WdQoQBdJABrv0Ehiy0pd/skDJ16WfZkai3ZLlQ+Joxu/BSLQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 0731AA2DE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(20324004)(24454002)(377454003)(199003)(164054003)(479174004)(106356001)(86362001)(122556002)(66066001)(10400500002)(189998001)(106116001)(5002640100001)(5001960100002)(87936001)(40100003)(5008740100001)(4001350100001)(81156007)(11100500001)(50986999)(83506001)(97736004)(54356999)(2900100001)(102836002)(105586002)(19580405001)(99286002)(64706001)(101416001)(76176999)(5004730100002)(92566002)(2950100001)(46102003)(36756003)(19580395003)(5001770100001)(5007970100001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2015 14:12:55.3603 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB441; 2:T9sjIfzuFMOWpPDVDXRUziT06PZ2Dy423UDFDmp8ZTiZLr/DWQD4PSccftbbzALgP+ezJpBMFr3td3ZU4coHrTsFy5oJ3L3+El6QlKJniIdcul52wmoCpY/IYwKH7yURdgbzUobv+zWOFCyK1ZXO0KauF0Wmq7N11ByVWr07LdQ=; 23:tu6S8N5j1grokNewhDbfdl9zXp2+iBzuRggArMuY/BwiaFvnfFB+t1j5vbCB9PncUVGONl5KIFt/enrPd9dWaWKCtj+wlwaCGojRoI74JzFX9BpAfF8jRTf74YB2MvC7WTFfLDFVVVLG9+4v4mKEMMsiESbV2lA+XzVse928qSeUHweQd+fLsr6yPmHTPRaB X-OriginatorOrg: juniper.net Archived-At: Cc: "netconf-ads@ietf.org" Subject: Re: [Netconf] On the registration policy for the NETCONF Capability URNs registry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Oct 2015 14:13:04 -0000 I'm okay with the change, but how does it affect 6241? Specifically, RFC 6241 Section 10.4 says: Additions to the registry require IETF Standards Action. which would no longer be accurate. Should draft-leiba-netmod-regpolicy-update "update" 6241? Thanks, Kent On 10/16/15, 5:25 AM, "Benoit Claise" wrote: >Dear all, > >https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00 > >This document, which updates the NETCONF Capability URNs registry >policy, requires the process defined in RFC 2026. This means that it >needs to be discussed, reviewed by the responsible AD, given an >IETF-wide last call, and reviewed and approved by the IESG. > >I hope that it can go fairly quickly, as it's a simple action. >Therefore, I propose to keep this document as an individual submission, >which I will AD sponsor. However, neither Bary nor I are going to push >this ahead against the working group's opposition. > >So it's time to speak up if you disagree with that policy change. >A final consensus call will be made during the NETCONF meeting in >Yokohama. > >Regards, Benoit (OPS AD) > >> For any who haven't followed it, we had a discussion about the >> experimental document draft-mm-netconf-time-capability, which >> registers a NETCONF capability URN. Here's my last comment on the >> point, after I cleared my DISCUSS ballot: >> >> ---------- >> The registration policy for the NETCONF Capability URNs registry is >> Standards Action, and this document, with Experimental status, does >> not meet the requirement that the registration come from a Standards >> Track RFC. This document cannot make that registration. >> >> After discussion about whether the IESG should make an exception in >> this case and allow the registration, I agree that it's the right >> thing to do for this document, so I've cleared my DISCUSS ballot on >> that point. >> >> But at the same time, it seems that the registration policy is too >> strict, and should be IETF Review, which allows the NETCONF working >> group to make the decision by getting IETF consensus on the >> registration -- there's no need to specifically require a Standards >> Track RFC. To that end, I've submitted an Internet draft, >> draft-leiba-netmod-regpolicy-update, which I ask the Network >> Operations AD to sponsor, in coordination with the NETCONF working >> group. >> ---------- >> >> I typo'ed the filename (made it "-netmod-" rather than "-netconf-"); >> sorry about that. In any case, the NETCONF working group should look >> at it and comment. It's straightforward, just changing the >> registration policy and explaining why. I don't expect there'll be >> controversy with it, but please do give it a review and comment, and >> let Beno=EEt and Joel know if y'all think it's acceptable for one of >> them to AD-sponsor: >> https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/ >> >> Please keep me on CC for any discussion, so I'll see the messages, >> though I'll also keep an eye on the mailing list archive. >> >> Thanks, >> Barry, ART AD >> . >> > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Oct 16 07:40:05 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 A30CB1B2C90; Fri, 16 Oct 2015 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUNLGjt6hfTR; Fri, 16 Oct 2015 07:40:03 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 B99AE1B2CA2; Fri, 16 Oct 2015 07:40:03 -0700 (PDT) Received: by vkha6 with SMTP id a6so69400188vkh.2; Fri, 16 Oct 2015 07:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IQoZAozmGxsCYy2b8HCvfzXhPzK10Xnga6GILV8+Jmw=; b=FIwtRXjOjjiVpAUPDxV9wwTJP8mvUpS1eVdISyoUcoM7Qn59TDpqDjdLHq/4T+XtAY 58wte5cLYXdqreIcC/0iNAsW5dF4wtz5jfi7UBb4RYZFyI/8/5+ZWvWqYE3DiW4ifgsx H858OOF5z+XEk1oZGGTN1lntPtSepuhLbTe5Qw0x8BvP+8KYWboRYDGlz2hPXgs8cDnu AkEMG96v8zkrVZpkWs+Dqd4POCuft3Tlffzu3WmvYO6iKso1SOISINZ3pAhpW6TbKvUm wNZyE8nBe29wzBgtuyWAm8MZDR1m7gx2k7WZARtRQEQq3K610t3okxHNyFTwDXjdke2E ZmLg== MIME-Version: 1.0 X-Received: by 10.31.132.79 with SMTP id g76mr10607138vkd.40.1445006402858; Fri, 16 Oct 2015 07:40:02 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Fri, 16 Oct 2015 07:40:02 -0700 (PDT) In-Reply-To: References: <5620C26D.7050202@cisco.com> Date: Fri, 16 Oct 2015 10:40:02 -0400 X-Google-Sender-Auth: Ht1XeevrDbDRd705-jANh7KqiLg Message-ID: From: Barry Leiba To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf , "netconf-ads@ietf.org" Subject: Re: [Netconf] On the registration policy for the NETCONF Capability URNs registry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Oct 2015 14:40:04 -0000 > Should > draft-leiba-netmod-regpolicy-update "update" 6241? Yes, it should, and I'll make that revision. Thanks, Kent. Barry From nobody Fri Oct 16 09:14:03 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 18FC81A21AC; Fri, 16 Oct 2015 09:13:59 -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 zCHTdXwS9cpM; Fri, 16 Oct 2015 09:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4789C1A6EDA; Fri, 16 Oct 2015 09:13:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151016161344.2819.65320.idtracker@ietfa.amsl.com> Date: Fri, 16 Oct 2015 09:13:44 -0700 Archived-At: Cc: netconf@ietf.org, The IESG , netconf-chairs@ietf.org Subject: [Netconf] WG Action: Rechartered Network Configuration (netconf) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 16:13:59 -0000 The Network Configuration (netconf) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Network Configuration (netconf) ------------------------------------------------ Current Status: Active WG Chairs: Mahesh Jethanandani Mehmet Ersue Assigned Area Director: Benoit Claise Mailing list Address: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: https://mailarchive.ietf.org/arch/browse/netconf/ Charter: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF is based on the secure transport (SSH is mandatory to implement while TLS is an optional transport) and uses an XML-based data representation. The NETCONF protocol is data modeling language independent, but YANG (RFC 6020) is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Provide a Server Configuration YANG module for both NETCONF and RESTCONF. 2. Develop RESTCONF, a protocol based on NETCONF in terms of capabilities, but over HTTPs and with some REST characteristics, for accessing YANG data in NETCONF datastores. An "ordered edit list" approach is needed (the YANG patch) to provide client developers with a simpler edit request format that can be more efficient and also allow more precise client control of the transaction procedure than existing mechanisms. The YANG patch operation, based on the HTTP PATCH method, will be prepared in a separate draft. In addition develop a YANG library, which identifies the information about all YANG modules used by a server. Furthermore develop a collection resource for the RESTCONF protocol to provide enhanced filtering features for the retrieval of data nodes with the GET method. RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented. The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS). 3. Develop a zero touch configuration document (a technique to establish a secure network management relationship between a newly delivered network device configured with just its factory default settings, and the Network Management System), specific to the NETCONF use case. 4. Develop a subscription and push mechanism that allows client applications to request notifications for changes in the datastore. These updates will be pushed by the server to the client based on a subscription policy. 5. Update RFC 6536 (NETCONF Access Control Model) to introduce access control rights associated with actions. 6. Enhance RFC 5277 with the ability to delete subscriptions without closing the client session, to modify existing subscriptions, and to have multiple subscriptions on a established client session. These changes should not affect older clients that do not support these particular subscription requirements. The RPCs and the data models in RFC 5277 should be converted to YANG. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. Milestones: Done - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard Done - Submit NETCONF call home mechanism to AD/IESG for consideration as Proposed Standard Oct 2015 - WGLC for RESTCONF, YANG patch operation and YANG Library drafts Nov 2015 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard Jan 2016 - WGLC for RFC5277bis draft Jan 2016 - Submit RFC5277bis to AD/IESG for consideration as Proposed Standard Jan 2016 - WGLC for YANG datastore push update draft Feb 2016 - Submit YANG datastore push update to AD/IESG for consideration as Proposed Standard Feb 2016 - WGLC for RFC6536bis draft Feb 2016 - Submit RFC6536bis to AD/IESG for consideration as Proposed Standard Feb 2016 - WGLC for zero touch configuration Feb 2016 - WGLC for RESTCONF Collection Resource draft Mar 2016 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard Mar 2016 - Submit RESTCONF Collection to AD/IESG for consideration as Proposed Standard Mar 2016 - WGLC for NETCONF server configuration data model Apr 2016 - Submit server configuration data model to AD/IESG for consideration as Proposed Standard From nobody Fri Oct 16 09:15: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 8DBE61A1B8A for ; Fri, 16 Oct 2015 09:15:36 -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 GFbtRUqR3cCy for ; Fri, 16 Oct 2015 09:15:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 239131A21A0 for ; Fri, 16 Oct 2015 09:15:33 -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: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151016161533.8534.63611.idtracker@ietfa.amsl.com> Date: Fri, 16 Oct 2015 09:15:33 -0700 From: IETF Secretariat Archived-At: Subject: [Netconf] Milestones changed for netconf WG X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 16:15:36 -0000 Changed milestone "Submit RFC5539bis to AD/IESG for consideration as Proposed Standard", resolved as "Done". Changed milestone "Submit NETCONF call home mechanism to AD/IESG for consideration as Proposed Standard", resolved as "Done". URL: https://datatracker.ietf.org/wg/netconf/charter/ From nobody Sun Oct 18 12:21: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 C53B11ACE67; Sun, 18 Oct 2015 12:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSWoD6rpoIo9; Sun, 18 Oct 2015 12:21:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECDD1ACE6A; Sun, 18 Oct 2015 12:21:10 -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: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151018192110.14085.40289.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 12:21:10 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 19:21:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-08.txt Pages : 104 Date : 2015-10-18 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 18 12:22: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 17E931ACE67; Sun, 18 Oct 2015 12:22:39 -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 OAhciKVVI2WL; Sun, 18 Oct 2015 12:22:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C23D71ACE86; Sun, 18 Oct 2015 12:22:31 -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: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151018192231.24009.12222.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 12:22:31 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 19:22:39 -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 : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-patch-06.txt Pages : 30 Date : 2015-10-18 Abstract: This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 18 12:23: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 312D91ACE77; Sun, 18 Oct 2015 12:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm8OEhYXqVVf; Sun, 18 Oct 2015 12:23:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1800C1ACE36; Sun, 18 Oct 2015 12:23:24 -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: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151018192324.24009.99154.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 12:23:24 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-library-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: Sun, 18 Oct 2015 19:23:25 -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 : YANG Module Library Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-library-02.txt Pages : 13 Date : 2015-10-18 Abstract: This document describes a YANG library, which provides information about all the YANG modules used by a device to represent management and protocol information. A YANG library can be shared by multiple protocols within the same device. Simple caching mechanisms are needed to allow clients to minimize retrieval of this information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-library-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-library-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 Oct 19 01:36:18 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A711A70FE; Mon, 19 Oct 2015 01:36:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 01:36:15 -0700 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and 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, 19 Oct 2015 08:36:15 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netconf-call-home-11: Discuss 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have three points to discuss, I think these may be fairly easy to resolve, or maybe not, but I'd like to chat about 'em. (1) HTTP Auth: is it ok for a client to send it's e.g. basic auth credential to any of the servers that the client can validate? I.e., is an additional level of pinning needed for this? That would be a new form of pinning and is not defined for either TLS or SSH afaik. That could also be done in various ways and I'm not sure if those might have interoperability consequences. Or perhaps if not doing that, this draft should say something about a need for stronger credentials esp. for basic auth. Did the WG consider this? (2) The secdir review [1] calls out issues related to TLS-PSK and (I guess also) bare keys. I think it'd be good to be speific as to wheher or how those are to be supported here. If you are going to say those are supported, then I suspect some additional text is needed. Kent's answer to that (which was "see RFC7589" as I read it) doesn't quite do it here I think. that says that certificates must be supported (which is fine) but doesn't say that TLS-PSK or bare keys can or cannot be supported. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html (3) Consider zmap. When this is deployed, what'll be the effect of surveys that fingerprint all of the devices on the visible Internet who implement this protocol? Did the WG consider that? I'm not sure of the impact, if any, but it could be good if there's a way to help deployments end up less vulnerable to fingerprinting (and the ensuing exposure to unpatched vulns). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - OCSP: any issue there? is it mandatory to use in any case for TLS? From nobody Mon Oct 19 11:17: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 772C61B2B5C; Mon, 19 Oct 2015 11:17: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 6807EzyUEJB9; Mon, 19 Oct 2015 11:17:30 -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 3C8D31B2B36; Mon, 19 Oct 2015 11:17:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D8DEF85; Mon, 19 Oct 2015 20:17:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hPItN4xDmymp; Mon, 19 Oct 2015 20:17:24 +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, 19 Oct 2015 20:17:24 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97A1520053; Mon, 19 Oct 2015 20:17:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kNk-KObNxygp; Mon, 19 Oct 2015 20:17:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A72EF2004E; Mon, 19 Oct 2015 20:17:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7E0A437B849D; Mon, 19 Oct 2015 20:17:21 +0200 (CEST) Date: Mon, 19 Oct 2015 20:17:20 +0200 From: Juergen Schoenwaelder To: Stephen Farrell Message-ID: <20151019181719.GA81250@elstar.local> Mail-Followup-To: Stephen Farrell , The IESG , netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org, The IESG , draft-ietf-netconf-call-home@ietf.org, netconf-chairs@ietf.org Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and 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: Mon, 19 Oct 2015 18:17:37 -0000 On Mon, Oct 19, 2015 at 01:36:15AM -0700, Stephen Farrell wrote: > > (2) The secdir review [1] calls out issues related to TLS-PSK > and (I guess also) bare keys. I think it'd be good to be > speific as to wheher or how those are to be supported here. If > you are going to say those are supported, then I suspect some > additional text is needed. Kent's answer to that (which was > "see RFC7589" as I read it) doesn't quite do it here I think. > that says that certificates must be supported (which is fine) > but doesn't say that TLS-PSK or bare keys can or cannot be > supported. > > [1] > https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html > RFC 7589 only covers X.509 authentication and this was a deliberate decision. Earlier I-Ds did include support for pre-shared keys but this was taken out and the WG concensus was to write another NETCONF over TLS with PSK document if the usage of pre-shared keys with NETCONF gets more traction. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Oct 19 14:41:56 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5D01B2D12; Mon, 19 Oct 2015 14:41:51 -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: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019214151.16129.3388.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 14:41:51 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 21:41:51 -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 Authors : Kent Watsen Joe Clarke Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-04.txt Pages : 52 Date : 2015-10-19 Abstract: This draft presents a technique for establishing a secure NETCONF or RESTCONF connection between a newly deployed 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: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 14:47: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 432AA1ACD0C for ; Mon, 19 Oct 2015 14:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GyvsKhuMjQ0 for ; Mon, 19 Oct 2015 14:47:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD2F1A8A87 for ; Mon, 19 Oct 2015 14:47:49 -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.293.16; Mon, 19 Oct 2015 21:47:32 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.74]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.193]) with mapi id 15.01.0293.007; Mon, 19 Oct 2015 21:47:32 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-04.txt Thread-Index: AQHRCrcD2/9CEMGu5UytSU77PofB6Z5zFwMA Date: Mon, 19 Oct 2015 21:47:31 +0000 Message-ID: References: <20151019214151.16129.3388.idtracker@ietfa.amsl.com> In-Reply-To: <20151019214151.16129.3388.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 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:Gn2jI26Alqbh654mMSc8g0Hqdvjx7PBiZsvM/qnSt9oLuBMBYmfzusK7IvYVUAEFO1C7Coc+JKE8Qg2EGf6mhz2LzvH/RaedWk0knqz3UOzcdPqKyyFcFiKiqaelK4liAP++maIfcHoV0hd9SkPRiA==; 24:BbdBfjW/h+0IZGvAwfS1zsJFvEmcfH5Rc7zqdikbiAD7vMycrJNFvmrs+DTwQ0x9BUbXMrqKcUhCSEEa3CAWyDt41RIhGv6T1ZsIPTRYr5Y=; 20:oiVZ433Ht5gRYrVcl0F6B/aiHrmeKbOTLZAUvOO1sXOlXS7V1+eCt5S/tvL6FhqogEQQ/lYaRMJiBgLeVxGCGg== 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)(2401047)(520078)(5005006)(8121501046)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(479174004)(24454002)(54534003)(199003)(189002)(377424004)(4001350100001)(106116001)(10400500002)(64706001)(110136002)(2501003)(81156007)(122556002)(230783001)(106356001)(107886002)(40100003)(46102003)(5008740100001)(2900100001)(50986999)(15975445007)(19580405001)(5002640100001)(102836002)(5004730100002)(11100500001)(2950100001)(92566002)(5007970100001)(189998001)(101416001)(76176999)(5001960100002)(19580395003)(99286002)(105586002)(450100001)(4001150100001)(97736004)(83506001)(86362001)(87936001)(66066001)(2351001)(54356999)(36756003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <4F62692C3CC49045BEB7B246641179B5@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 21:47:31.7599 (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-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 21:47:55 -0000 Here's the change log for this update: o Major update formally introducing unsigned data and support for Internet-based redirect servers. The privacy issue raised during IETF 93. o Added many terms to Terminology section. o Added all new "Guiding Principles" section. o Added all new "Sources for Bootstrapping Data" section. o Rewrote the "Interactions" section and renamed it "Workflow Overview". Draft draft is looking close to done. The only major outstanding issue currently is needing the define a specific data-signing algorithm. Cheers, Kent On 10/19/15, 5:41 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 > Authors : Kent Watsen > Joe Clarke > Mikael Abrahamsson > Filename : draft-ietf-netconf-zerotouch-04.txt > Pages : 52 > Date : 2015-10-19 > >Abstract: > This draft presents a technique for establishing a secure NETCONF or > RESTCONF connection between a newly deployed 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: >https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-04 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-zerotouch-04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Oct 19 20:26: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 77AFB1B2A91 for ; Mon, 19 Oct 2015 20:26:43 -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 DkiVvS29RBk6 for ; Mon, 19 Oct 2015 20:26:38 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 98E891B2A98 for ; Mon, 19 Oct 2015 20:26:38 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so6803806pac.3 for ; Mon, 19 Oct 2015 20:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=XqRuap3H/txNNloWcN/6qaU0xZk00Hbc/I15bRZH6e8=; b=q2PSjXhrqfwVFoqOk9rahTIwNX8RkBFRf2Fm15mTzKo5oFGzhkblm1LO+l2zSePurN yXK7VHpvFoZIluUPDTSt4z9TvJff3z+Pe+pkTpRG5Yf3SqHgriqRODceyTSlNSeme0uW 6xzDx4VmdZe9Ew7qhFOhUfKMg/koPoYbnv+JPlvoBI6blvNhxEkHRtWmsT91fDgwwARq mj2pcD6jxQIMNUOAVQYQo/mCQ2FIvZSKL9QTz1Z6WR4gM60jbzZDrOlEK3cPOyvOr+lE tuuz8dp4IiqU+HBzFAPoSDtSAKiXkcxsYqbMZnfVsj2aQ61wqMbY8tk+VGG+vK5GRyVc hMkA== X-Received: by 10.68.242.130 with SMTP id wq2mr1093872pbc.117.1445311598345; Mon, 19 Oct 2015 20:26:38 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1004::4c1? ([2001:420:c0c8:1004::4c1]) by smtp.gmail.com with ESMTPSA id cn4sm665711pbc.94.2015.10.19.20.26.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Oct 2015 20:26:37 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_7BBD1D25-3AAE-4B44-B6DE-2F6F40BB11CB" Date: Mon, 19 Oct 2015 19:13:18 -0700 Message-Id: <2D05CCAB-1AB1-4BB9-8486-394E1C7EAD29@gmail.com> To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Cc: NETCONF Chairs Subject: [Netconf] Slot request X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 20 Oct 2015 03:26:43 -0000 --Apple-Mail=_7BBD1D25-3AAE-4B44-B6DE-2F6F40BB11CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We are starting to build the agenda for NETCONF WG meeting in Yokohama. = The agenda for IETF 94 is available here = . The NETCONF WG is slated to meet on Thursday from 1-3 p.m. in Room 501. Please reply to this e-mail, making sure to include = netconf-chairs@ietf.org your request = for presentation. Please indicate - draft name: - presenter: - desired duration (covering both presentation and Q & A): Thanks. Mahesh & Mehmet --Apple-Mail=_7BBD1D25-3AAE-4B44-B6DE-2F6F40BB11CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We are starting to build the agenda for NETCONF WG meeting in = Yokohama. The agenda for IETF 94 is available here.

The NETCONF WG is slated to meet on Thursday from 1-3 p.m. in = Room 501.

Please= reply to this e-mail, making sure to include netconf-chairs@ietf.org your request for = presentation. Please indicate

- draft name:
- = presenter:
- desired duration (covering both = presentation and Q & A):

Thanks.

Mahesh & Mehmet





= --Apple-Mail=_7BBD1D25-3AAE-4B44-B6DE-2F6F40BB11CB-- From nobody Tue Oct 20 11:47:38 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5B41ACE13; Tue, 20 Oct 2015 11:47:35 -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: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151020184735.19913.19977.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 11:47:35 -0700 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: [Netconf] Barry Leiba's No Objection on draft-ietf-netconf-call-home-11: (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: Tue, 20 Oct 2015 18:47:36 -0000 Barry Leiba has entered the following ballot position for draft-ietf-netconf-call-home-11: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 2.1, C5: This validation MAY be accomplished by certificate path validation or by comparing the host key or certificate to a previously trusted or "pinned" value. It's a finnicky point, but I think it's an important one: You list two methods for validation: (1) cert path validation, and (2) comparing to a pinned value. Is it (A) acceptable for the validation to be done by other methods as well as those two? Or is it (B) required that one of those two be used, but either is acceptable? If (A), then the text is fine as it is. But if (B), the text as written doesn't require the use of one of the specified methods, because "MAY" is optional. If you mean (B), you should write it as "MUST be accomplished either by [...] or by [...]." Alternatively, you could just add it to the previous sentence, as, '...client MUST validate the server's presented host key or certificate, either using certificate path validation or by comparing the host key or certificate to a previously trusted or "pinned" value.' (That wasn't a DISCUSS point because I think implmentors are likely to get it right anyway. But I do think the text needs to be tightened up in order to make it fully clear.) In Section 2.1, C8, an even more finnicky and not very important point: Once the SSH or TLS connection is established, the NETCONF/ RESTCONF client MUST immediately start using either the NETCONF- client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] protocol. What *else* might the client do, which merits a MUST here? I think all you should say here is, "Once the SSH or TLS connection is established, the NETCONF/RESCONF client starts using either [...the protocols...]." Continuing... Assuming the use of the IANA-assigned ports, the NETCONF-client protocol is started when the connection is accepted on either port PORT-X or PORT-Y and the RESTCONF-client protocol is started when the connection is accepted on port PORT- Z. But no: the (NETCONF/RESCONF)-client protocol is NOT started when the connection is accepted (that was in C2), but when the SSH/TLS connection/session is established. Which you already said in the previous sentence, and C1 already said what ports the client listens on. Why is this sentence even here? Why not just remove it? These same two comments apply to S6 in Section 3.1. From nobody Tue Oct 20 11:48:21 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AAB1ACE13; Tue, 20 Oct 2015 11:48:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151020184820.19822.34012.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 11:48:20 -0700 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: [Netconf] Spencer Dawkins' No Objection on draft-ietf-netconf-call-home-11: (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: Tue, 20 Oct 2015 18:48:20 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-netconf-call-home-11: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In this text: C1 The NETCONF/RESTCONF client listens for TCP connection requests from NETCONF/RESTCONF servers. The client SHOULD listen for connections on the IANA-assigned ports defined in section Section 5, but MAY be configured to use a non-standard port. are SHOULD/MAY mutually exclusive here, or can you do both? I'd be guessing if I said I knew, from this text. Could you provide "as well as" or "instead of" guidance? From nobody Tue Oct 20 15:05:29 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB2F1B355D; Tue, 20 Oct 2015 15:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 15:05:28 -0700 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (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: Tue, 20 Oct 2015 22:05:28 -0000 Ben Campbell has entered the following ballot position for draft-ietf-netconf-call-home-11: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One comment and a question: - 3.1, S1: If the client MAY be configured to listen on a non-standard port, doesn’t that imply that the server MUST be _capable_ of being configured to connect to a non-standard port? - 4: I'm curious why people felt it necessary to reverse the usual TLS or SSH client and server roles. Did the working group consider having the NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the reasons be summarized in a sentence or two? From nobody Tue Oct 20 21:47: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 13BE51A0035; Tue, 20 Oct 2015 21:47:24 -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 v30WJl1PTxy6; Tue, 20 Oct 2015 21:47:22 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 3BAC61A0033; Tue, 20 Oct 2015 21:47:22 -0700 (PDT) Received: by oies66 with SMTP id s66so22460704oie.1; Tue, 20 Oct 2015 21:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EXFYoatUJtEuSXgNiuZRpq56+EdBBFRHJ6djXZMIRjM=; b=YH9RQTZBeRft7oK32OkdW/3QWD4d8V/roaISUsSjd2m15ejtJCWDAoWRxGopnqzL0m Ko91fpmWCysq+NMSnCN00qscqYfN8uGcZt6604mtciMSywfPIw7q2KV4eH5yt0ona4Gi v6IdvHFg3GGv9anM4NnH0tPkhqFSzrhhJ3YR/muOqD/YbCVTGIaAQvHl0fHj2pw8yIAx 3JOURUZowzAcKwK4q9npCKb3Z8y7LsLNDTvbHtPimsIMBeZs/ZceAWvsmt0/yrGpWYcN z8GOgLwGeOHP9VripW9ZYuEve+9+MzS0+XxMbIGfV8PpQTvTZ0oqtOi/NFhf7D+Nk4D0 mFZA== X-Received: by 10.202.59.86 with SMTP id i83mr4437311oia.63.1445402841681; Tue, 20 Oct 2015 21:47:21 -0700 (PDT) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:e145:47c4:ccf2:b9b1]) by smtp.gmail.com with ESMTPSA id h23sm2891976oic.11.2015.10.20.21.47.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Oct 2015 21:47:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B5CFE34E-8172-47F9-8D3C-081CD5A47178" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <20151020184820.19822.34012.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 21:47:18 -0700 Message-Id: <7E421EBF-750C-4A25-A7DD-474D38987745@gmail.com> References: <20151020184820.19822.34012.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netconf@ietf.org, The IESG , draft-ietf-netconf-call-home@ietf.org, netconf-chairs@ietf.org Subject: Re: [Netconf] Spencer Dawkins' No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 04:47:24 -0000 --Apple-Mail=_B5CFE34E-8172-47F9-8D3C-081CD5A47178 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Spencer, > On Oct 20, 2015, at 11:48 AM, Spencer Dawkins = wrote: >=20 > Spencer Dawkins has entered the following ballot position for > draft-ietf-netconf-call-home-11: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In this text: >=20 > C1 The NETCONF/RESTCONF client listens for TCP connection requests > from NETCONF/RESTCONF servers. The client SHOULD listen for > connections on the IANA-assigned ports defined in section > Section 5, but MAY be configured to use a non-standard port. >=20 > are SHOULD/MAY mutually exclusive here, or can you do both? I'd be > guessing if I said I knew, from this text. Could you provide "as well = as" > or "instead of" guidance? >=20 As I read the content, I can see some implementations deciding to =E2=80=9C= as well as=E2=80=9D while others deciding that they would have nothing = but =E2=80=9Cinstead of=E2=80=9D. Could this be left up to implementors = to decide? Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_B5CFE34E-8172-47F9-8D3C-081CD5A47178 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Spencer,

On Oct 20, 2015, at 11:48 AM, = Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

Spencer Dawkins has = entered the following ballot position for
draft-ietf-netconf-call-home-11: 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 https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/<= /a>



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

In this text:

  C1  The NETCONF/RESTCONF client listens for = TCP connection requests
=       from NETCONF/RESTCONF servers. =  The client SHOULD listen for
=       connections on the IANA-assigned = ports defined in section
=       Section 5, but MAY be configured to = use a non-standard port.

are SHOULD/MAY = mutually exclusive here, or can you do both? I'd be
guessing= if I said I knew, from this text. Could you provide "as well as"
or "instead of" guidance?


As I read the content, I can see some implementations = deciding to =E2=80=9Cas well as=E2=80=9D while others deciding that they = would have nothing but =E2=80=9Cinstead of=E2=80=9D. Could this be left = up to implementors to decide?




= --Apple-Mail=_B5CFE34E-8172-47F9-8D3C-081CD5A47178-- From nobody Tue Oct 20 23:05: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 D9F3B1B35C3; Tue, 20 Oct 2015 23:05:52 -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 WDOMgyTSjTRf; Tue, 20 Oct 2015 23:05:50 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 C00811B3548; Tue, 20 Oct 2015 23:05:50 -0700 (PDT) Received: by pasz6 with SMTP id z6so44676694pas.2; Tue, 20 Oct 2015 23:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=w07izCa9rddyDOHvmegNTQ2zeoBQLYXEDOSATLq/VI8=; b=AF4p+bZzRVwWuZqP7fIxG8teoshDMD8EhJ98mR2HPgXwLzTRBfy4nspCZV133QsukG Oe7QKYPOy8NR2JmpTG+y2eC2GZ9rBulkw595ILWy9cikW3OYuh5QNN8vIDeZW+owRH/u LqJR96tWl4Jaust3O8rVtlYbdhjNrQEAd/R/Tw0pWIpd+Tu8LDcj3aZ0VwW2+qEw2lZ6 Y5Z9I0q/n82a0h0fnKUDMaWX5AHaLBF6PBcWV+OuC15NiTdVUIIKA1wQ7+nrsazPxa+S cvAjDVpCCK/YiUxYaoFtoNUnl8NKjj42xOgzNyJeWBH3yivpnaNwV4Hl3nn4Xjb8YCvB NoEA== X-Received: by 10.68.57.197 with SMTP id k5mr8555488pbq.142.1445407550422; Tue, 20 Oct 2015 23:05:50 -0700 (PDT) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:e145:47c4:ccf2:b9b1]) by smtp.gmail.com with ESMTPSA id yq2sm7019561pbb.39.2015.10.20.23.05.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Oct 2015 23:05:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6F11A5EB-D0B5-46F5-BC5B-B19D295A6873" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> Date: Tue, 20 Oct 2015 23:05:48 -0700 Message-Id: References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netconf@ietf.org, The IESG , draft-ietf-netconf-call-home@ietf.org, netconf-chairs@ietf.org Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 06:05:53 -0000 --Apple-Mail=_6F11A5EB-D0B5-46F5-BC5B-B19D295A6873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben, > On Oct 20, 2015, at 3:05 PM, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-netconf-call-home-11: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > One comment and a question: >=20 > - 3.1, S1: >=20 > If the client MAY be configured to listen on a non-standard port, = doesn=E2=80=99t > that imply that the server MUST be _capable_ of being configured to > connect to a non-standard port? That is correct. The client and the server would have to decide up-front = that they would negotiate the connection on a non-standard port and for = the server to be configured with that capability. >=20 > - 4: >=20 > I'm curious why people felt it necessary to reverse the usual TLS or = SSH > client and server roles. Did the working group consider having the > NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the > reasons be summarized in a sentence or two? I believe that the NETCONF/RESTCONF server is acting as the TLS or SSH = client during call home. What (I think) Kent is trying to imply is that = "NETCONF/RESTCONF server=E2=80=9D is the entity that runs on the network = element, and is a server for NETCONF/RESTCONF and TLS/SSH during normal = operations, but which acts as a TLS or SSH client during call home. Would it help to say as such? >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6F11A5EB-D0B5-46F5-BC5B-B19D295A6873 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ben,

On Oct 20, 2015, at 3:05 PM, = Ben Campbell <ben@nostrum.com> wrote:

Ben Campbell has = entered the following ballot position for
draft-ietf-netconf-call-home-11: 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 https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/<= /a>



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

One comment and a question:

- 3.1, S1:

If the = client MAY be configured to listen on a non-standard port, doesn=E2=80=99t=
that imply that the server MUST be _capable_ of being = configured to
connect to a non-standard port?

That is correct. = The client and the server would have to decide up-front that they would = negotiate the connection on a non-standard port and for the server to be = configured with that capability.








= --Apple-Mail=_6F11A5EB-D0B5-46F5-BC5B-B19D295A6873-- From nobody Wed Oct 21 00:51: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 4BC821B3695; Wed, 21 Oct 2015 00:51:26 -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 kr42aDivL7Sz; Wed, 21 Oct 2015 00:51:24 -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 681931B3691; Wed, 21 Oct 2015 00:51:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3998C1273; Wed, 21 Oct 2015 09:51:23 +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 tBGo4X0smXrg; Wed, 21 Oct 2015 09:51:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Oct 2015 09:51:22 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFB7F2004E; Wed, 21 Oct 2015 09:51:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iYKD36UKJY7v; Wed, 21 Oct 2015 09:51:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 320D82003B; Wed, 21 Oct 2015 09:51:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C22737EA5D7; Wed, 21 Oct 2015 09:51:18 +0200 (CEST) Date: Wed, 21 Oct 2015 09:51:18 +0200 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20151021075118.GD64783@elstar.local> Mail-Followup-To: Mahesh Jethanandani , Ben Campbell , netconf@ietf.org, The IESG , draft-ietf-netconf-call-home@ietf.org, netconf-chairs@ietf.org References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> 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: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Ben Campbell , netconf-chairs@ietf.org, netconf@ietf.org, draft-ietf-netconf-call-home@ietf.org, The IESG Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (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: Wed, 21 Oct 2015 07:51:26 -0000 On Tue, Oct 20, 2015 at 11:05:48PM -0700, Mahesh Jethanandani wrote: > Ben, > > > On Oct 20, 2015, at 3:05 PM, Ben Campbell wrote: > > > > Ben Campbell has entered the following ballot position for > > draft-ietf-netconf-call-home-11: 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 https://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: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > One comment and a question: > > > > - 3.1, S1: > > > > If the client MAY be configured to listen on a non-standard port, doesn’t > > that imply that the server MUST be _capable_ of being configured to > > connect to a non-standard port? > > That is correct. The client and the server would have to decide up-front that they would negotiate the connection on a non-standard port and for the server to be configured with that capability. > > > > > - 4: > > > > I'm curious why people felt it necessary to reverse the usual TLS or SSH > > client and server roles. Did the working group consider having the > > NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the > > reasons be summarized in a sentence or two? > > I believe that the NETCONF/RESTCONF server is acting as the TLS or SSH client during call home. What (I think) Kent is trying to imply is that "NETCONF/RESTCONF server” is the entity that runs on the network element, and is a server for NETCONF/RESTCONF and TLS/SSH during normal operations, but which acts as a TLS or SSH client during call home. > I am confused by the answer. My understanding is that the NETCONF/RESTCONF server hosts the SSH/TLS server no matter whether there is call-home or not. Both NETCONF Call Home and RESTCONF Call Home preserve all but one of the client/server roles in their respective protocol stacks, as compared to client-initiated NETCONF and RESTCONF connections. The one and only role reversal that occurs is at the TCP layer; that is, which peer is the TCP-client and which is the TCP-server. Early versions of this document (actually when this was still part of the NC over TLS document) had the SSH/TLS roles swapped but this was troublesome since authentication mechanisms are not necessarily symmetric (and this is in particular true for SSH). We had a longer discussion about this at one of the IETF meeting a couple of IETF's ago where Bert also managed to bring in security experts and this lead to the current design. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Oct 21 02:28: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 7A0411A03A1; Wed, 21 Oct 2015 02:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD6-FXNqahZp; Wed, 21 Oct 2015 02:28:34 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 6775C1A039B; Wed, 21 Oct 2015 02:28:34 -0700 (PDT) Received: by vkgy127 with SMTP id y127so25666226vkg.0; Wed, 21 Oct 2015 02:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gXLthS6/wGAdQLdW32ShEQ3gPSYzdOvL7LHjvB4P5eg=; b=YVRGwXOer38TjtE4EIE7SpOx3XftkTmeJK0Hq2XQEXkkPzbeJpsWjnp/4xiF4kprK1 0lOOfcZnDxigQiSwB2MzsLbqA5yw3k+RMzFQpDIzN0qck6qnSKOo3iBpDGDk/8kzeroQ eO66mlT3TUGQSDiEU8sXUIoqF5lE9WJZCNqFEx+xAx233BLS9mt4EQXxKvNjRk9kD9x8 6IVatSn7duNpeFiIU4vJPECxKXwENfIp/PSwHJa5Uj9Q34bhdexVtjiqlNsUhg8En9S/ MVCw1U/Xi98jlE16V/eYGGjJLpl8YJipblBztzehVXhGBaPF7czKELTPIK6+vBqTvGXg PUWw== MIME-Version: 1.0 X-Received: by 10.31.9.81 with SMTP id 78mr4716871vkj.10.1445419713594; Wed, 21 Oct 2015 02:28:33 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Wed, 21 Oct 2015 02:28:33 -0700 (PDT) In-Reply-To: References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 05:28:33 -0400 X-Google-Sender-Auth: 66imGiAVFCyw6KTiMGiHqaqr0-k Message-ID: From: Barry Leiba To: Mahesh Jethanandani Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ben Campbell , netconf-chairs@ietf.org, Netconf , draft-ietf-netconf-call-home@ietf.org, The IESG Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 09:28:35 -0000 >> I'm curious why people felt it necessary to reverse the usual TLS or SSH >> client and server roles. Did the working group consider having the >> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the >> reasons be summarized in a sentence or two? > > I believe that the NETCONF/RESTCONF server is acting as the TLS or SSH > client during call home. What (I think) Kent is trying to imply is that > "NETCONF/RESTCONF server=E2=80=9D is the entity that runs on the network = element, > and is a server for NETCONF/RESTCONF and TLS/SSH during normal operations= , > but which acts as a TLS or SSH client during call home. No, not so. Normally, if protocol XX will run over, say, TLS, the XX client opens a TCP connection to the XX server, and then the XX client starts a TLS handshake. Here, where XX =3D=3D NETCONF or RESCONF, the XX *server* opens a TCP connection to the XX *client*... and then the XX client responds by starting a TLS handshake. What Ben is asking is this: Why doesn't the NETCONF/RESCONF server start the TLS handshake (and similarly for SSH), maintaining the normal TLS or SSH setup? What was the reason for reversing it? Barry From nobody Wed Oct 21 02:40: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 2CAEB1A0AF1; Wed, 21 Oct 2015 02:40:16 -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 DwJt4B5ooCCs; Wed, 21 Oct 2015 02:40:14 -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 7D83E1A079D; Wed, 21 Oct 2015 02:40:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4E34D15E2; Wed, 21 Oct 2015 11:40:13 +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 KsBBx7q753RS; Wed, 21 Oct 2015 11:40:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 21 Oct 2015 11:40:12 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F20AC20097; Wed, 21 Oct 2015 11:40:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id v4HTeit8OQJm; Wed, 21 Oct 2015 11:40:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 778402008C; Wed, 21 Oct 2015 11:40:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 89B7437EA736; Wed, 21 Oct 2015 11:40:08 +0200 (CEST) Date: Wed, 21 Oct 2015 11:40:08 +0200 From: Juergen Schoenwaelder To: Barry Leiba Message-ID: <20151021094008.GB65099@elstar.local> Mail-Followup-To: Barry Leiba , Mahesh Jethanandani , Ben Campbell , netconf-chairs@ietf.org, Netconf , draft-ietf-netconf-call-home@ietf.org, The IESG References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> 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: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Ben Campbell , netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, The IESG , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (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: Wed, 21 Oct 2015 09:40:16 -0000 On Wed, Oct 21, 2015 at 05:28:33AM -0400, Barry Leiba wrote: > >> I'm curious why people felt it necessary to reverse the usual TLS or SSH > >> client and server roles. Did the working group consider having the > >> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the > >> reasons be summarized in a sentence or two? > > > > I believe that the NETCONF/RESTCONF server is acting as the TLS or SSH > > client during call home. What (I think) Kent is trying to imply is that > > "NETCONF/RESTCONF server” is the entity that runs on the network element, > > and is a server for NETCONF/RESTCONF and TLS/SSH during normal operations, > > but which acts as a TLS or SSH client during call home. > > No, not so. Normally, if protocol XX will run over, say, TLS, the XX > client opens a TCP connection to the XX server, and then the XX client > starts a TLS handshake. > > Here, where XX == NETCONF or RESCONF, the XX *server* opens a TCP > connection to the XX *client*... and then the XX client responds by > starting a TLS handshake. > > What Ben is asking is this: Why doesn't the NETCONF/RESCONF server > start the TLS handshake (and similarly for SSH), maintaining the > normal TLS or SSH setup? What was the reason for reversing it? Authentication is not symmetrics, in particular with SSH where the server is authenticated by its hostkey and the client by credentials (of different forms) associated with the notion of a user. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Oct 21 06:53:34 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACCE1A0AC8; Wed, 21 Oct 2015 06:53:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021135330.20048.35548.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 06:53:30 -0700 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and 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: Wed, 21 Oct 2015 13:53:30 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netconf-call-home-11: Discuss 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2.1 & 3.1 Why is authentication limited to server-side authentication? It seems that this really should be mutual authentication to ensure the server is also connecting to the correct client and there was no attack prior to the callback. 3.1 S3 - Why is client-side authentication optional? Without this must, there should be a security consideration that the call back could go to a malicious client. The types of authentication matter as well, but that's covered in Stephen's discuss points along with the SecDir review questions on TLS-PSK. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In section 1.3, please add a sentence that points to the threat/security analysis for use of this function with NETCONF and RESTCONF after the last sentence: In such circumstances, allowing the SSH/TLS server to contact the SSH/TLS client would open new vulnerabilities. Any use of call home with SSH/TLS for purposes other than NETCONF or RESTCONF will need a thorough, contextual security analysis. From nobody Wed Oct 21 07:34: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 7934E1A8BBD for ; Wed, 21 Oct 2015 07:34:28 -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 p8WK4v10vKTL for ; Wed, 21 Oct 2015 07:34:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CFB031A8FD4 for ; Wed, 21 Oct 2015 07:34:21 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9LEYJ2B091318 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2015 09:34:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Juergen Schoenwaelder" Date: Wed, 21 Oct 2015 09:34:19 -0500 Message-ID: <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> In-Reply-To: <20151021094008.GB65099@elstar.local> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, The IESG , Barry Leiba , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 14:34:28 -0000 On 21 Oct 2015, at 4:40, Juergen Schoenwaelder wrote: > On Wed, Oct 21, 2015 at 05:28:33AM -0400, Barry Leiba wrote: >>>> I'm curious why people felt it necessary to reverse the usual TLS >>>> or SSH >>>> client and server roles. Did the working group consider having the >>>> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can >>>> the >>>> reasons be summarized in a sentence or two? >>> >>> I believe that the NETCONF/RESTCONF server is acting as the TLS or >>> SSH >>> client during call home. What (I think) Kent is trying to imply is >>> that >>> "NETCONF/RESTCONF server” is the entity that runs on the network >>> element, >>> and is a server for NETCONF/RESTCONF and TLS/SSH during normal >>> operations, >>> but which acts as a TLS or SSH client during call home. >> >> No, not so. Normally, if protocol XX will run over, say, TLS, the XX >> client opens a TCP connection to the XX server, and then the XX >> client >> starts a TLS handshake. >> >> Here, where XX == NETCONF or RESCONF, the XX *server* opens a TCP >> connection to the XX *client*... and then the XX client responds by >> starting a TLS handshake. >> >> What Ben is asking is this: Why doesn't the NETCONF/RESCONF server >> start the TLS handshake (and similarly for SSH), maintaining the >> normal TLS or SSH setup? What was the reason for reversing it? > > Authentication is not symmetrics, in particular with SSH where the > server is authenticated by its hostkey and the client by credentials > (of different forms) associated with the notion of a user. Paraphrasing back to check my understanding: At least for the case of TLS, The NETCONF/RESTCONF server is authenticated by TLS, and the client by credentials that are exchanged after the TLS handshake completes? I'm going to go out on a limb and guess that that approach is an artifact of the normal (non-call-home) connection direction, and a lack of client certs? I am no NETCONF expert, so forgive me if I am missing some other obvious reason. That motivation appears reasonable on the surface. I will leave it to people who have a deeper understanding of TLS subtleties than I to say if that causes any problems. However, this does make me wonder about the statement in the Security Considerations that the DoS potential is "no different than for any other secured service". The reversed connection approach seems to allow an attacker to cause the NETCONF client to perform computationally intense operations with just a TCP connection--that is, with marginally less effort on the part of the attacker. I'm not sure that's enough difference to make a real-world difference, but it might be worth a mention. Thanks! Ben. From nobody Wed Oct 21 10:34:06 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 15BD31A92F1; Wed, 21 Oct 2015 10:34:02 -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 wew24EnvPZHi; Wed, 21 Oct 2015 10:34:00 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 4F9F31B2B44; Wed, 21 Oct 2015 10:34:00 -0700 (PDT) Received: by vkex70 with SMTP id x70so32807148vke.3; Wed, 21 Oct 2015 10:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xADNjLUJ9VZWLejHeJVs/+q/HgM6jaTwuYot1QV3lzg=; b=v99Z2Syh8i3Dt3xMcuPOHyA8XinPlKcwqKW0mQC13lw8kLF7919Ob77uloTATrISMc xdJ+kY1ISHquN0wnAm+7w2L7q2l3Nit8pKbdE5LUEMqcXHDUVf8ZXsmoVzDqOg0GIGdQ UNh1J63eLT5Z7NUQ1nxEylE3NRZDgLbvuaWqk1WSEJY/i5wFMvKd2acFWWf/KFmHS0hg XCbpNjddlnytiXg757UX3Y65/jHj1q0WRlQGsZA9C0Img+mO7pnYIKzl9lVomMgaJ5mD I50iJGUfBZNXwG/q+VM8LpSbH7TWtL19djYiRXI24sBmdbEl+cRn6hFqSptEgfzRsRSj XhGA== MIME-Version: 1.0 X-Received: by 10.31.9.81 with SMTP id 78mr6276270vkj.10.1445448839378; Wed, 21 Oct 2015 10:33:59 -0700 (PDT) Received: by 10.31.54.8 with HTTP; Wed, 21 Oct 2015 10:33:59 -0700 (PDT) In-Reply-To: <7E421EBF-750C-4A25-A7DD-474D38987745@gmail.com> References: <20151020184820.19822.34012.idtracker@ietfa.amsl.com> <7E421EBF-750C-4A25-A7DD-474D38987745@gmail.com> Date: Wed, 21 Oct 2015 12:33:59 -0500 Message-ID: From: Spencer Dawkins at IETF To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=001a1143c0f69ce9fe0522a0c8bf Archived-At: Cc: netconf@ietf.org, The IESG , draft-ietf-netconf-call-home@ietf.org, netconf-chairs@ietf.org Subject: Re: [Netconf] Spencer Dawkins' No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 17:34:02 -0000 --001a1143c0f69ce9fe0522a0c8bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Manesh, On Tue, Oct 20, 2015 at 11:47 PM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > Spencer, > > On Oct 20, 2015, at 11:48 AM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > Spencer Dawkins has entered the following ballot position for > draft-ietf-netconf-call-home-11: 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 https://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: > https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In this text: > > C1 The NETCONF/RESTCONF client listens for TCP connection requests > from NETCONF/RESTCONF servers. The client SHOULD listen for > connections on the IANA-assigned ports defined in section > Section 5, but MAY be configured to use a non-standard port. > > are SHOULD/MAY mutually exclusive here, or can you do both? I'd be > guessing if I said I knew, from this text. Could you provide "as well as" > or "instead of" guidance? > > > As I read the content, I can see some implementations deciding to =E2=80= =9Cas well > as=E2=80=9D while others deciding that they would have nothing but =E2=80= =9Cinstead of=E2=80=9D. > Could this be left up to implementors to decide? > Absolutely. My point was that it wasn't clear to me that implementors can do either/both. If you think that's clear, that's fine. Thanks for the quick response. Spencer --001a1143c0f69ce9fe0522a0c8bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Manesh,

On Tue, Oct 20, 2015 at 11:47 PM, Mahesh Jethanandani <m= jethanandani@gmail.com> wrote:
Spencer,

On Oct 20, 2015, at 11:48 AM, Spen= cer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

Spencer = Dawkins has entered the following ballot position for
draft-ietf-netconf= -call-home-11: 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.)

<= br>Please refer to https://www.ietf.org/iesg/statement/discuss= -criteria.html
for more information about IESG DISCUSS and COMMENT p= ositions.


The document, along with other ballot positions, can b= e found here:
https://datatracker.ietf.org/doc/draft-i= etf-netconf-call-home/



---------------------------------= -------------------------------------
COMMENT:
----------------------= ------------------------------------------------

In this text:
=C2=A0=C2=A0C1 =C2=A0The NETCONF/RESTCONF client listens for TCP connect= ion requests
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0from NETCONF/RESTCONF = servers.=C2=A0 The client SHOULD listen for
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0connections on the IANA-assigned ports defined in section
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Section 5, but MAY be configured to use a = non-standard port.

are SHOULD/MAY mutually exclusive here, or can yo= u do both? I'd be
guessing if I said I knew, from this text. Could y= ou provide "as well as"
or "instead of" guidance?

As I read the cont= ent, I can see some implementations deciding to =E2=80=9Cas well as=E2=80= =9D while others deciding that they would have nothing but =E2=80=9Cinstead= of=E2=80=9D. Could this be left up to implementors to decide?
<= /blockquote>

Absolutely. My point was that it wasn't= clear to me that implementors can do either/both. If you think that's = clear, that's fine.

Thanks for the quick respo= nse.

Spencer=C2=A0
--001a1143c0f69ce9fe0522a0c8bf-- From nobody Wed Oct 21 12:19: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 29A2A1B2A0C; Wed, 21 Oct 2015 12:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Iwma_WSa6jQv; Wed, 21 Oct 2015 12:19:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412BF1ACDF1; Wed, 21 Oct 2015 12:19:31 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.306.13; Wed, 21 Oct 2015 19:19:28 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Wed, 21 Oct 2015 19:19:28 +0000 From: Kent Watsen To: Spencer Dawkins at IETF , "Mahesh Jethanandani" Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRC7uVkMstiGLw60OU/kxY93ncGp52Nd+A///aaYA= Date: Wed, 21 Oct 2015 19:19:28 +0000 Message-ID: <33E2A8C1-73AF-427C-A1B9-EDC3B16A0483@juniper.net> References: <20151020184820.19822.34012.idtracker@ietfa.amsl.com> <7E421EBF-750C-4A25-A7DD-474D38987745@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:6WrwP8gKQ88K6KhORiJXgZrIB+mC+rvqG7vyOzr5+jFHZ5Y3/C8I4gV+Ko4lUOAuhArHgi/DFY+AsAkaPUTdGetjeVoAXyw5LPJEJGXNcnHc/uvJ6xllosnOGomKpJUjbspJq7H9K3mBPzi5TW/Spg==; 24:P/KQjP6+/ROsqSBG+ySKX+EBGCGGRgIGgZzHHOJkCP2JqAw6ZzVop1Tf8vQM97I08AS/gX3gPoQMVr42nyZhIgDWxwziE/If6ZbcNBpBLck=; 20:EvWTXbcdD/crkFdH6xPJVhywUWThI4qXcwdyzMRu24jUSVsTzKoEwbbYHww+0OhFIrS9gV2LFuJD2cydnHl/DQ== 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)(2401047)(8121501046)(520078)(5005006)(3002001)(102115026); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(43784003)(52044002)(51914003)(199003)(189002)(5007970100001)(189998001)(64706001)(83506001)(82746002)(5008740100001)(10400500002)(2950100001)(122556002)(5002640100001)(2900100001)(5001960100002)(86362001)(101416001)(40100003)(102836002)(19580395003)(230783001)(19580405001)(15975445007)(46102003)(87936001)(11100500001)(16236675004)(83716003)(5004730100002)(4001350100001)(105586002)(36756003)(99286002)(106116001)(106356001)(92566002)(5001770100001)(66066001)(97736004)(33656002)(76176999)(81156007)(19617315012)(54356999)(50986999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_33E2A8C173AF427CA1B9EDC3B16A0483junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2015 19:19:28.0969 (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" , The IESG , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Spencer Dawkins' No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 19:19:34 -0000 --_000_33E2A8C173AF427CA1B9EDC3B16A0483junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BlbmNlciwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlldy4NCg0KQmFzZWQgb24gdGhp cyBkaXNjdXNzaW9uLCBJIHdpbGwgbm90IHBsYW4gdG8gbWFrZSBhbnkgY2hhbmdlIHRvIHRoZSBk cmFmdC4NCg0KVGhhbmtzIGFnYWluLA0KS2VudA0KDQoNCkZyb206IFNwZW5jZXIgRGF3a2lucyBh dCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBPY3RvYmVyIDIxLCAyMDE1IGF0 IDE6MzMgUE0NClRvOiBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNv bTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+Pg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj4sICJkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1o b21lQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lQGlldGYub3Jn PiIgPGRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWVAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWll dGYtbmV0Y29uZi1jYWxsLWhvbWVAaWV0Zi5vcmc+PiwgIm5ldGNvbmYtY2hhaXJzQGlldGYub3Jn PG1haWx0bzpuZXRjb25mLWNoYWlyc0BpZXRmLm9yZz4iIDxuZXRjb25mLWNoYWlyc0BpZXRmLm9y ZzxtYWlsdG86bmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmc+PiwgIm5ldGNvbmZAaWV0Zi5vcmc8bWFp bHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogU3BlbmNlciBEYXdraW5zJyBObyBPYmplY3Rpb24gb24g ZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0xMTogKHdpdGggQ09NTUVOVCkNCg0KSGksIE1h bmVzaCwNCg0KT24gVHVlLCBPY3QgMjAsIDIwMTUgYXQgMTE6NDcgUE0sIE1haGVzaCBKZXRoYW5h bmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWls LmNvbT4+IHdyb3RlOg0KU3BlbmNlciwNCg0KT24gT2N0IDIwLCAyMDE1LCBhdCAxMTo0OCBBTSwg U3BlbmNlciBEYXdraW5zIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3Bl bmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KU3BlbmNlciBEYXdraW5zIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1u ZXRjb25mLWNhbGwtaG9tZS0xMTogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxl YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSBy ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZS8NCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkluIHRoaXMgdGV4dDoNCg0KICBDMSAgVGhl IE5FVENPTkYvUkVTVENPTkYgY2xpZW50IGxpc3RlbnMgZm9yIFRDUCBjb25uZWN0aW9uIHJlcXVl c3RzDQogICAgICBmcm9tIE5FVENPTkYvUkVTVENPTkYgc2VydmVycy4gIFRoZSBjbGllbnQgU0hP VUxEIGxpc3RlbiBmb3INCiAgICAgIGNvbm5lY3Rpb25zIG9uIHRoZSBJQU5BLWFzc2lnbmVkIHBv cnRzIGRlZmluZWQgaW4gc2VjdGlvbg0KICAgICAgU2VjdGlvbiA1LCBidXQgTUFZIGJlIGNvbmZp Z3VyZWQgdG8gdXNlIGEgbm9uLXN0YW5kYXJkIHBvcnQuDQoNCmFyZSBTSE9VTEQvTUFZIG11dHVh bGx5IGV4Y2x1c2l2ZSBoZXJlLCBvciBjYW4geW91IGRvIGJvdGg/IEknZCBiZQ0KZ3Vlc3Npbmcg aWYgSSBzYWlkIEkga25ldywgZnJvbSB0aGlzIHRleHQuIENvdWxkIHlvdSBwcm92aWRlICJhcyB3 ZWxsIGFzIg0Kb3IgImluc3RlYWQgb2YiIGd1aWRhbmNlPw0KDQoNCkFzIEkgcmVhZCB0aGUgY29u dGVudCwgSSBjYW4gc2VlIHNvbWUgaW1wbGVtZW50YXRpb25zIGRlY2lkaW5nIHRvIOKAnGFzIHdl bGwgYXPigJ0gd2hpbGUgb3RoZXJzIGRlY2lkaW5nIHRoYXQgdGhleSB3b3VsZCBoYXZlIG5vdGhp bmcgYnV0IOKAnGluc3RlYWQgb2bigJ0uIENvdWxkIHRoaXMgYmUgbGVmdCB1cCB0byBpbXBsZW1l bnRvcnMgdG8gZGVjaWRlPw0KDQpBYnNvbHV0ZWx5LiBNeSBwb2ludCB3YXMgdGhhdCBpdCB3YXNu J3QgY2xlYXIgdG8gbWUgdGhhdCBpbXBsZW1lbnRvcnMgY2FuIGRvIGVpdGhlci9ib3RoLiBJZiB5 b3UgdGhpbmsgdGhhdCdzIGNsZWFyLCB0aGF0J3MgZmluZS4NCg0KVGhhbmtzIGZvciB0aGUgcXVp Y2sgcmVzcG9uc2UuDQoNClNwZW5jZXINCg== --_000_33E2A8C173AF427CA1B9EDC3B16A0483junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3A9382E6C2FFF945840926425E58A134@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+SGkg U3BlbmNlciw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rIHlvdSBmb3IgeW91 ciByZXZpZXcuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CYXNlZCBvbiB0aGlzIGRp c2N1c3Npb24sIEkgd2lsbCBub3QgcGxhbiB0byBtYWtlIGFueSBjaGFuZ2UgdG8gdGhlIGRyYWZ0 LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGFnYWluLDwvZGl2Pg0KPGRp dj5LZW50PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRM T09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsg Qk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsg Qk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206 IDwvc3Bhbj5TcGVuY2VyIERhd2tpbnMgYXQgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwZW5j ZXJkYXdraW5zLmlldGZAZ21haWwuY29tIj5zcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5X ZWRuZXNkYXksIE9jdG9iZXIgMjEsIDIwMTUgYXQgMTozMyBQTTxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPk1haGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhy ZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5j b208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFu PlRoZSBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9y ZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwt aG9tZUBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZUBpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lQGll dGYub3JnIj5kcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lQGlldGYub3JnPC9hPiZndDssDQog JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtY2hhaXJzQGlldGYub3JnIj5uZXRjb25mLWNo YWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWNoYWly c0BpZXRmLm9yZyI+bmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5S ZTogU3BlbmNlciBEYXdraW5zJyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1uZXRjb25mLWNh bGwtaG9tZS0xMTogKHdpdGggQ09NTUVOVCk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPkhpLCBNYW5lc2gsDQo8ZGl2IGNsYXNzPSJn bWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgT2N0IDIw LCAyMDE1IGF0IDExOjQ3IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIDxzcGFuIGRpcj0ibHRyIj4N CiZsdDs8YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDpicmVhay13b3JkIj5TcGVuY2VyLA0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNz PSJoNSI+PGJyPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj5PbiBPY3Qg MjAsIDIwMTUsIGF0IDExOjQ4IEFNLCBTcGVuY2VyIERhd2tpbnMgJmx0OzxhIGhyZWY9Im1haWx0 bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNwZW5jZXJk YXdraW5zLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnI+DQo8ZGl2PlNw ZW5jZXIgRGF3a2lucyBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBm b3I8YnI+DQpkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lLTExOiBObyBPYmplY3Rpb248YnI+ DQo8YnI+DQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50 YWN0IGFuZCByZXBseSB0byBhbGw8YnI+DQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhl IFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpczxicj4NCmludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxicj4NCjxicj4NCjxicj4NClBsZWFzZSByZWZlciB0byA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbDwvYT48YnI+DQpmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxicj4NCjxicj4NCjxi cj4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZTo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUv PC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpDT01NRU5UOjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpJbiB0aGlzIHRleHQ6PGJyPg0KPGJyPg0KJm5i c3A7Jm5ic3A7QzEgJm5ic3A7VGhlIE5FVENPTkYvUkVTVENPTkYgY2xpZW50IGxpc3RlbnMgZm9y IFRDUCBjb25uZWN0aW9uIHJlcXVlc3RzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ZnJvbSBORVRDT05GL1JFU1RDT05GIHNlcnZlcnMuJm5ic3A7IFRoZSBjbGllbnQg U0hPVUxEIGxpc3RlbiBmb3I8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtjb25uZWN0aW9ucyBvbiB0aGUgSUFOQS1hc3NpZ25lZCBwb3J0cyBkZWZpbmVkIGluIHNlY3Rp b248YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTZWN0aW9uIDUsIGJ1 dCBNQVkgYmUgY29uZmlndXJlZCB0byB1c2UgYSBub24tc3RhbmRhcmQgcG9ydC48YnI+DQo8YnI+ DQphcmUgU0hPVUxEL01BWSBtdXR1YWxseSBleGNsdXNpdmUgaGVyZSwgb3IgY2FuIHlvdSBkbyBi b3RoPyBJJ2QgYmU8YnI+DQpndWVzc2luZyBpZiBJIHNhaWQgSSBrbmV3LCBmcm9tIHRoaXMgdGV4 dC4gQ291bGQgeW91IHByb3ZpZGUgJnF1b3Q7YXMgd2VsbCBhcyZxdW90Ozxicj4NCm9yICZxdW90 O2luc3RlYWQgb2YmcXVvdDsgZ3VpZGFuY2U/PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KQXMgSSByZWFk IHRoZSBjb250ZW50LCBJIGNhbiBzZWUgc29tZSBpbXBsZW1lbnRhdGlvbnMgZGVjaWRpbmcgdG8g 4oCcYXMgd2VsbCBhc+KAnSB3aGlsZSBvdGhlcnMgZGVjaWRpbmcgdGhhdCB0aGV5IHdvdWxkIGhh dmUgbm90aGluZyBidXQg4oCcaW5zdGVhZCBvZuKAnS4gQ291bGQgdGhpcyBiZSBsZWZ0IHVwIHRv IGltcGxlbWVudG9ycyB0byBkZWNpZGU/PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFic29sdXRlbHkuIE15IHBvaW50IHdhcyB0aGF0IGl0IHdh c24ndCBjbGVhciB0byBtZSB0aGF0IGltcGxlbWVudG9ycyBjYW4gZG8gZWl0aGVyL2JvdGguIElm IHlvdSB0aGluayB0aGF0J3MgY2xlYXIsIHRoYXQncyBmaW5lLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5TcGVuY2VyJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_33E2A8C173AF427CA1B9EDC3B16A0483junipernet_-- From nobody Wed Oct 21 13:18: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 89C231B2A24; Wed, 21 Oct 2015 13:18:43 -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 9frBPRTyVWWM; Wed, 21 Oct 2015 13:18:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1: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 A5B641AD066; Wed, 21 Oct 2015 13:18:40 -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.306.13; Wed, 21 Oct 2015 20:18:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Wed, 21 Oct 2015 20:18:34 +0000 From: Kent Watsen To: Ben Campbell , Juergen Schoenwaelder Thread-Topic: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRC4NwSO9HeS5EiE2jlg9x14GRTZ51dggAgAA4poCAAAM9AIAAUjGAgAAdHgA= Date: Wed, 21 Oct 2015 20:18:34 +0000 Message-ID: <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> In-Reply-To: <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:3pXjb79zIkAPXMEKkgqd9cw4wOowb00eD3whJv2muGyAGDXZCMWmKsN4Mo5W3b/Jzef9Q+GbHnJ0ysRSdH+d1aOPFRJsYHMKBYrTJ2g1NxOVoo5XJUnPqKQT3odMydItOWrix7Hlugc+7aTcL6UoPw==; 24:EVO9ySX1pb5JT9D4WOmSoSlkP6TY2dS48X08DC2HIbc5LoCkkcL0DUGmLD+Dyma7sQhIZhuK2axF2hvhSKfpSS9KzpQKjcoEFTjUa20zkME=; 20:0W1kmLNUOsxpYepKsK3fUHTYVZgbhk906991V05pA0RAkJbYGZO28Co8ExjsOuINH/YqcOBpiKI/m3M+l+13fw== 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)(2401047)(8121501046)(520078)(5005006)(3002001)(102115026); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(43784003)(93886004)(36756003)(105586002)(4001350100001)(106116001)(106356001)(99286002)(5001770100001)(97736004)(66066001)(33656002)(54356999)(50986999)(76176999)(81156007)(92566002)(86362001)(5002640100001)(2950100001)(122556002)(2900100001)(5001960100002)(5008740100001)(101416001)(40100003)(82746002)(10400500002)(64706001)(5007970100001)(189998001)(83506001)(102836002)(11100500001)(5004730100002)(83716003)(230783001)(87936001)(46102003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2015 20:18:34.5297 (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 , Barry Leiba , "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , The IESG Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 20:18:43 -0000 SGkgQmVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQoNClJlZ2FyZGluZyB5b3Vy IG9yaWdpbmFsIGNvbW1lbnRzOg0KDQoNCj4gSWYgdGhlIGNsaWVudCBNQVkgYmUgY29uZmlndXJl ZCB0byBsaXN0ZW4gb24gYSBub24tc3RhbmRhcmQgcG9ydCwgZG9lc27igJl0DQo+IHRoYXQgaW1w bHkgdGhhdCB0aGUgc2VydmVyIE1VU1QgYmUgX2NhcGFibGVfIG9mIGJlaW5nIGNvbmZpZ3VyZWQg dG8NCj4gY29ubmVjdCB0byBhIG5vbi1zdGFuZGFyZCBwb3J0Pw0KDQpUaGlzIGlzIGNvcnJlY3Qg YW5kIHdoYXQgZHJhZnQtaWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbC0wOCBhbGxvd3MuICAgV2Vy ZSB5b3UgdGhpbmtpbmcgdGhhdCB0aGVyZSBuZWVkcyB0byBiZSBhIGNoYW5nZSBpbiB0aGlzIGRy YWZ0Pw0KDQoNCj4gSSdtIGN1cmlvdXMgd2h5IHBlb3BsZSBmZWx0IGl0IG5lY2Vzc2FyeSB0byBy ZXZlcnNlIHRoZSB1c3VhbCBUTFMgb3IgU1NIDQo+IGNsaWVudCBhbmQgc2VydmVyIHJvbGVzLiBE aWQgdGhlIHdvcmtpbmcgZ3JvdXAgY29uc2lkZXIgaGF2aW5nIHRoZQ0KPiBORVRDT05GL1JFU1RD T05GIHNlcnZlciBhY3QgYXMgdGhlIFRMUyBvciBTU0ggY2xpZW50PyBJZiBzbywgY2FuIHRoZQ0K DQpBcyBKdWVyZ2VuIG5vdGVkLCB0aGlzIGFsbG93cyB0aGF0IGFsbCBleGlzdGluZyBhdXRoZW50 aWNhdGlvbiB0byBjb250aW51ZSB3b3JraW5nLiAgQWxzbywgc2luY2UgU1NIIGlzIG5vdCBhIHN5 bW1ldHJpYyBwcm90b2NvbCwgaXTigJlzIGFjdHVhbGx5IGltcG9ydGFudCBmb3IgdGhlIGNsaWVu dCB0byBiZSB0aGUgU1NILWNsaWVudCBzbyBpdCBjYW4gb3Blbi9jbG9zZSBTU0ggY2hhbm5lbHMg KGUuZy4sIHRvIHN0YXJ0IHRoZSDigJxuZXRjb25m4oCdIHN1YnN5c3RlbSkuDQoNCg0KDQoNCg0K QW5kIHJlZ2FyZGluZyB5b3VyIGxhdGVzdCBtZXNzYWdlOg0KDQo+UGFyYXBocmFzaW5nIGJhY2sg dG8gY2hlY2sgbXkgdW5kZXJzdGFuZGluZzoNCj4NCj5BdCBsZWFzdCBmb3IgdGhlIGNhc2Ugb2Yg VExTLCBUaGUgTkVUQ09ORi9SRVNUQ09ORiBzZXJ2ZXIgaXMgDQo+YXV0aGVudGljYXRlZCBieSBU TFMsIGFuZCB0aGUgY2xpZW50IGJ5IGNyZWRlbnRpYWxzIHRoYXQgYXJlIGV4Y2hhbmdlZCANCj5h ZnRlciB0aGUgVExTIGhhbmRzaGFrZSBjb21wbGV0ZXM/DQoNCk5FVENPTkYgb3ZlciBUTFMgcmVx dWlyZXMgdGhlIGNsaWVudCB0byB1c2UgY2xpZW50LWNlcnRpZmljYXRlIGJhc2VkIGF1dGhlbnRp Y2F0aW9uIGFuZCB0aGlzIGhhcHBlbnMgYXQgdGhlIHRpbWUgdGhlIFRMUyBzZXNzaW9uIGlzIGJl aW5nIGVzdGFibGlzaGVkLCBmb3IgdGhlIE5FVENPTkYgcHJvdG9jb2wgbGF5ZXIgc3RhcnRzLg0K DQpSRVNUQ09ORiBvdmVyIFRMUyAodGhlIG9ubHkgY2hvaWNlKSB1c2VzIEhUVFAgQXV0aGVudGlj YXRpb24gW1JGQzcyMzVdLiAgV2hlbiDigJxCYXNpY+KAnSBvciDigJxEaWdlc3TigJ0gYXJlIHVz ZWQsIHRoZSBjbGllbnQtYXV0aGVudGljYXRpb24gaXMgYWZ0ZXIgdGhlIFRMUyBzZXNzaW9uIGhh cyBiZWVuIGVzdGFibGlzaGVkLiAgVGhlIOKAnENsaWVudENlcnRpZmljYXRl4oCdIGlzIHVzZWQs IHRoZW4gdGhlIGNsaWVudC1hdXRoZW50aWNhdGlvbiBvY2N1cnMgYXQgdGhlIHRpbWUgdGhlIFRM UyBzZXNzaW9uIGlzIGJlaW5nIGVzdGFibGlzaGVkIChzYW1lIGFzIE5FVENPTkYgb3ZlciBUTFMp LiANCg0KDQoNCg0KPkknbSBnb2luZyB0byBnbyBvdXQgb24gYSBsaW1iIGFuZCBndWVzcyB0aGF0 IHRoYXQgYXBwcm9hY2ggaXMgYW4gDQo+YXJ0aWZhY3Qgb2YgdGhlIG5vcm1hbCAobm9uLWNhbGwt aG9tZSkgY29ubmVjdGlvbiBkaXJlY3Rpb24sIGFuZCBhIGxhY2sgDQo+b2YgY2xpZW50IGNlcnRz PyBJIGFtIG5vIE5FVENPTkYgZXhwZXJ0LCBzbyBmb3JnaXZlIG1lIGlmIEkgYW0gbWlzc2luZyAN Cj5zb21lIG90aGVyIG9idmlvdXMgcmVhc29uLg0KDQpZZXMsIHRoYXQgaXMgZmFpciB0byBzYXks IGluIHRoZSBzZW5zZSB0aGF0IGl0IGlzIHZlcnkgZWFzeSB0byBpbXBsZW1lbnQgaXQgdGhpcyB3 YXkuICAgRm9yIGluc3RhbmNlLCBKVU5PUyB1c2VzIGBpbmV0ZGAgdG8gbGlzdGVuIG9uIHBvcnQg MjIgYW5kLCB3aGVuIGEgVENQIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQsIGl0IGZvcmtzL2V4 ZWNzIGBzc2hkIC1pYCBwYXNzaW5nIHRoZSBvcGVuIHNvY2tldCBkZXNjcmlwdG9yLiAgIFNvIHRv IGltcGxlbWVudCBjYWxsIGhvbWUsIGFsbCB0aGF0IGhhZCB0byBiZSBkb25lIHdhcyB0byB3cml0 ZSBhIGRhZW1vbiB0aGF0IGluaXRpYXRlcyB0aGUgVENQIGNvbm5lY3Rpb24gdG8gdGhlIGNsaWVu dCBhbmQgdGhlbiwgYXMgc29vbiBhcyB0aGUgVENQIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQs IGl0IGZvcmtzL2V4ZWNzIGBzc2hkIC1pYCBleGFjdGx5IGxpa2UgaG93IGBpbmV0ZGAgZG9lcyBp dC4gICBFdmVyeXRoaW5nIGVsc2Ugc3RheXMgdGhlIHNhbWUuICBJbiBmYWN0LCB0aGUgU1NIIGhh cyBubyBhd2FyZW5lc3Mgb2YgaG93IGl0IHdhcyBpbnZva2VkLg0KDQoNCg0KPkhvd2V2ZXIsIHRo aXMgZG9lcyBtYWtlIG1lIHdvbmRlciBhYm91dCB0aGUgc3RhdGVtZW50IGluIHRoZSBTZWN1cml0 eQ0KPkNvbnNpZGVyYXRpb25zIHRoYXQgdGhlIERvUyBwb3RlbnRpYWwgaXMgIm5vIGRpZmZlcmVu dCB0aGFuIGZvciBhbnkgDQo+b3RoZXIgc2VjdXJlZCBzZXJ2aWNlIi4gVGhlIHJldmVyc2VkIGNv bm5lY3Rpb24gYXBwcm9hY2ggc2VlbXMgdG8gYWxsb3cgDQo+YW4gYXR0YWNrZXIgdG8gY2F1c2Ug dGhlIE5FVENPTkYgY2xpZW50IHRvIHBlcmZvcm0gY29tcHV0YXRpb25hbGx5IA0KPmludGVuc2Ug b3BlcmF0aW9ucyB3aXRoIGp1c3QgYSBUQ1AgY29ubmVjdGlvbi0tdGhhdCBpcywgd2l0aCBtYXJn aW5hbGx5IA0KPmxlc3MgZWZmb3J0IG9uIHRoZSBwYXJ0IG9mIHRoZSBhdHRhY2tlci4gSSdtIG5v dCBzdXJlIHRoYXQncyBlbm91Z2ggDQo+ZGlmZmVyZW5jZSB0byBtYWtlIGEgcmVhbC13b3JsZCBk aWZmZXJlbmNlLCBidXQgaXQgbWlnaHQgYmUgd29ydGggYSANCj5tZW50aW9uLg0KDQoNCkEgbm9y bWFsIFNTSCBvciBUTFMgc2VydmVyIGFjY2VwdHMgdGhlIFRDUCBjb25uZWN0aW9uIGFuZCBpbW1l ZGlhdGVseSBzdGFydHMgYSBjb21wdXRhdGlvbmFsbHkgZXhwZW5zaXZlIG9wZXJhdGlvbiAocHJv dmluZyBpdCBoYXMgdGhlIHByaXZhdGUga2V5IGFzc29jaWF0ZWQgd2l0aCBpdHMgU1NIIGhvc3Qg a2V5IG9yIFRMUyBzZXJ2ZXIgY2VydGlmaWNhdGUpLiAgIA0KDQpIZXJlIHdlIGhhdmUgc2ltaWxh ciBzZXR1cCwgZXhjZXB0IHRoZSBjbGllbnQgaGFzIHRoZSBwb3J0IG9wZW4gYW5kIGl0IHN0YXJ0 cyB0aGUgU1NIL1RMUyBjbGllbnQgcHJvdG9jb2wuICBJdCBjb3VsZCBiZSBhcmd1ZWQgdGhhdCB0 aGUgY2xpZW50IHByb3RvY29sIGlzIGxlc3MgZXhwZW5zaXZlIHRoYW4gdGhlIHNlcnZlciBwcm90 b2NvbCwgc28gcGVyaGFwcyBpdOKAmXMgbm90IHNvIGJhZC4NCg0KU3RpbGwsIGZvciB0aGUgZHJh ZnQsIHdoYXQgZG8geW91IHJlY29tbWVuZCBjaGFuZ2luZz8gICBUaGUgY3VycmVudCB0ZXh0IGZv bGxvd3M6DQoNCiAgICBBbiBhdHRhY2tlciBjb3VsZCBsYXVuY2ggYSBkZW5pYWwgb2Ygc2Vydmlj ZSAoRG9TKSBhdHRhY2sgb24gdGhlDQogICAgTkVUQ09ORi9SRVNUQ09ORiBjbGllbnQgYnkgaGF2 aW5nIGl0IHBlcmZvcm0gY29tcHV0YXRpb25hbGx5DQogICAgZXhwZW5zaXZlIG9wZXJhdGlvbnMs IGJlZm9yZSBkZWR1Y2luZyB0aGF0IHRoZSBhdHRhY2tlciBkb2Vzbid0DQogICAgcG9zc2VzIGEg dmFsaWQga2V5LiAgVGhpcyBpcyBubyBkaWZmZXJlbnQgdGhhbiBhbnkgc2VjdXJlZCBzZXJ2aWNl DQogICAgYW5kIGFsbCBjb21tb24gcHJlY2F1dGlvbnMgYXBwbHkgKGUuZy4sIGJsYWNrbGlzdGlu ZyB0aGUgc291cmNlDQogICAgYWRkcmVzcyBhZnRlciBhIHNldCBudW1iZXIgb2YgdW5zdWNjZXNz ZnVsIGxvZ2luIGF0dGVtcHRzKS4NCg0KDQoNCg0KVGhhbmtzIGFnYWluLA0KS2VudA0KDQoNCg0K DQoNCg0K From nobody Wed Oct 21 13:40:03 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7DF1B2FD4; Wed, 21 Oct 2015 13:40:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> Date: Wed, 21 Oct 2015 13:40:01 -0700 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (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: Wed, 21 Oct 2015 20:40:02 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-netconf-call-home-11: 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 https://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: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Three points in decreasing order of importance: 1) Why is this parapraph below (and subsequently the other similar ones) using RFC 2119 language with respect to the port numbers The NETCONF/RESTCONF client listens for TCP connection requests from NETCONF/RESTCONF servers. The client SHOULD listen for connections on the IANA-assigned ports defined in section Section 5, but MAY be configured to use a non-standard port. Using the right port number is not something that influences the interoperability of the protocol per se, but is an operational parameter. Checking other protocol specifications, e.g. HTTP/1.1, there is no RFC 2119 language about the usage of specific port numbers. 2) I am not a fan of having different port numbers to differentiate different vanilla flavors of a protocol. However, I can understand the why this is happening this way. But what is happening if there is X-over-TLS/SSH/foo coming after RESTCONF? Are you again in need of more port numbers? This does not look like a tactical wise and sustainable way. 3) This document will benefit from an overview figure that details who is the server/client on what level for what. From nobody Wed Oct 21 13:52: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 EE31D1A8AE5; Wed, 21 Oct 2015 13:52:21 -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 jBxOPfobNEbh; Wed, 21 Oct 2015 13:52:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::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 44CD61A1A99; Wed, 21 Oct 2015 13:52:19 -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.306.13; Wed, 21 Oct 2015 20:52:12 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Wed, 21 Oct 2015 20:52:12 +0000 From: Kent Watsen To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHRDAfgpOfZU3eYFEWbvakAFJEjNJ52KZiA Date: Wed, 21 Oct 2015 20:52:12 +0000 Message-ID: <4F2C1542-6FCB-4B67-91A8-7AD55BC34EB5@juniper.net> References: <20151021135330.20048.35548.idtracker@ietfa.amsl.com> In-Reply-To: <20151021135330.20048.35548.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:pKaXAE4SwL17USJpPKlb+TS3cAQOJqUdHqk0BgvGXk7cgTzmfHHubjDps7EQ8f1J0svyV2/pUYoNsN/q79SGrDkLuZklofGQ/42FNpw9d29KaVqG1RVrtobFnq4n2I4Dq0gcH+yAhmgPf7wvQ/8O9A==; 24:AdaZP5fqjNrc/TPLzvDtpQ+OOvIjqrkig8wn/3us0uangIMhpHiM5hL8rgemULcuuuZYEQCS5dI4jX8i+GVVkZ2wdpMfQsLvALGbuPlzuUM=; 20:BwV90rB62NMAXzWlSj7gdcIOe6eMZMVdL2PV5UpmdHesurv7TtCuRkv17jcd1GYoh00VGMUCfWjCMaG7SSTMFw== 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)(2401047)(8121501046)(5005006)(520078)(3002001)(102115026); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(57704003)(43784003)(36756003)(105586002)(4001350100001)(106356001)(106116001)(99286002)(5001770100001)(97736004)(66066001)(33656002)(54356999)(50986999)(76176999)(81156007)(92566002)(86362001)(5002640100001)(2950100001)(122556002)(2900100001)(5001960100002)(5008740100001)(101416001)(40100003)(82746002)(10400500002)(64706001)(5007970100001)(189998001)(83506001)(102836002)(11100500001)(5004730100002)(83716003)(230783001)(87936001)(46102003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <062089CA7C315447AC7ADF14B31694AB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2015 20:52:12.7601 (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-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 20:52:22 -0000 DQpIaSBLYXRobGVlbiwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlldy4NCg0KDQoNCg0KDQoN Cj5TZWN0aW9uIDIuMSAmIDMuMQ0KPldoeSBpcyBhdXRoZW50aWNhdGlvbiBsaW1pdGVkIHRvIHNl cnZlci1zaWRlIGF1dGhlbnRpY2F0aW9uPyAgSXQgc2VlbXMNCj50aGF0IHRoaXMgcmVhbGx5IHNo b3VsZCBiZSBtdXR1YWwgYXV0aGVudGljYXRpb24gdG8gZW5zdXJlIHRoZSBzZXJ2ZXIgaXMNCj5h bHNvIGNvbm5lY3RpbmcgdG8gdGhlIGNvcnJlY3QgY2xpZW50IGFuZCB0aGVyZSB3YXMgbm8gYXR0 YWNrIHByaW9yIHRvDQo+dGhlIGNhbGxiYWNrLg0KDQoNCkJvdGggTkVUQ09ORiBhZCBSRVNUQ09O RiByZXF1aXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbiwgYW5kIHRoaXMgaXMgY2FsbGVkIG91dCBp biB0aGUgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQgKFNlY3Rpb24gMS4zKS4gIEFsc28sIGluIHRo ZSAiVGhlIE5FVENPTkYgb3IgUkVTVENPTkYgQ2xpZW504oCdIHNlY3Rpb24sIGl0IHNheXM6DQoN CiAgIEM3ICBBZnRlciB0aGUgc2VydmVyJ3MgaG9zdCBrZXkgb3IgY2VydGlmaWNhdGUgaXMgdmFs aWRhdGVkLCB0aGUgU1NIDQogICBvciBUTFMgcHJvdG9jb2wgcHJvY2VlZHMgYXMgbm9ybWFsIHRv IGVzdGFibGlzaCBhIFNTSCBvciBUTFMNCiAgIGNvbm5lY3Rpb24uDQoNClRoZSDigJxwcm9jZWVk cyBhcyBub3JtYWzigJ0gaXMgaW50ZW5kZWQgdG8gY292ZXIgY2xpZW50IGF1dGhlbnRpY2F0aW9u LiAgQWxzbywgaW4gdGhlICJUaGUgTkVUQ09ORiBvciBSRVNUQ09ORiBTZXJ2ZXLigJ0gc2VjdGlv biwgaXQgc2F5czoNCg0KDQogICBTNSAgSW4gbW9zdCBjYXNlcywgZXN0YWJsaXNoaW5nIHRoZSBT U0ggb3IgVExTIGNvbm5lY3Rpb24gYWxzbw0KICAgZW50YWlscyBzZXJ2ZXIgYXV0aGVudGljYXRp b24gb2YgY2xpZW50IGNyZWRlbnRpYWxzOyBvbmx5IHdpdGgNCiAgIFJFU1RDT05GIGRvIHNvbWUg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgb2NjdXIgYWZ0ZXIgdGhlDQogICBzZWN1cmUg dHJhbnNwb3J0IGNvbm5lY3Rpb24gKFRMUykgaGFzIGJlZW4gZXN0YWJsaXNoZWQuICBJZg0KICAg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIHJlcXVpcmVkLCBhbmQgdGhlIGNsaWVudCBpcyB1bmFi bGUgdG8NCiAgIHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXIg aW4gYW4gYW1vdW50IG9mDQogICB0aW1lIGRlZmluZWQgYnkgbG9jYWwgcG9saWN5LCB0aGUgc2Vy dmVyIE1VU1QgY2xvc2UgdGhlDQogICBjb25uZWN0aW9uLg0KDQpXaGljaCBzcGVha3MgdG8gaXQg YXMgd2VsbC4NCg0KDQpEbyB5b3UgYmVsaWV2ZSB0aGVyZSBpcyBhIG5lZWQgdG8gY2hhbmdlIHRo ZSB0ZXh0Pw0KDQoNCg0KDQo+My4xIFMzIC0gV2h5IGlzIGNsaWVudC1zaWRlIGF1dGhlbnRpY2F0 aW9uIG9wdGlvbmFsPw0KPg0KPldpdGhvdXQgdGhpcyBtdXN0LCB0aGVyZSBzaG91bGQgYmUgYSBz ZWN1cml0eSBjb25zaWRlcmF0aW9uIHRoYXQgdGhlIGNhbGwNCj5iYWNrIGNvdWxkIGdvIHRvIGEg bWFsaWNpb3VzIGNsaWVudC4gIFRoZSB0eXBlcyBvZiBhdXRoZW50aWNhdGlvbiBtYXR0ZXINCj5h cyB3ZWxsLCBidXQgdGhhdCdzIGNvdmVyZWQgaW4gU3RlcGhlbidzIGRpc2N1c3MgcG9pbnRzIGFs b25nIHdpdGggdGhlDQo+U2VjRGlyIHJldmlldyBxdWVzdGlvbnMgb24gVExTLVBTSy4NCg0KRG8g bWVhbiBTNSBwYXN0ZWQgYWJvdmUgd2hlcmUgaXQgc2F5cyDigJxJZiBjbGllbnQgYXV0aGVudGlj YXRpb24gaXMgcmVxdWlyZWTigJ0/DQoNClRoaXMgdGV4dCBpcyBzcGVha2luZyBhYm91dCB0cmFu c3BvcnQtbGV2ZWwgY2xpZW50LWF1dGguICBORVRDT05GIG92ZXIgU1NIIG9yIG92ZXIgVExTIGJv dGggaGF2ZSB0cmFuc3BvcnQtbGV2ZWwgYXV0aGVudGljYXRpb24sIGJ1dCBSRVNUQ09ORiAoZS5n LiwgSFRUUFMpIGFsbG93cyB0aGUgQmFzaWMgYW5kIERpZ2VzdCBhdXRoZW50aWNhdGlvbiBtb2Rl cywgYW5kIHRoYXQgY2xpZW50IGF1dGggaGFwcGVuIGFmdGVyIHRoZSBUTFMgc2Vzc2lvbiBpcyBl c3RhYmxpc2hlZC4NCg0KSXMgaXQgY2xlYXIgbm93LCBvciBkbyB5b3UgdGhpbmsgdGhhdCB0ZXh0 IHNob3VsZCBiZSB1cGRhdGVkPw0KDQoNCg0KDQo+SW4gc2VjdGlvbiAxLjMsIHBsZWFzZSBhZGQg YSBzZW50ZW5jZSB0aGF0IHBvaW50cyB0byB0aGUgdGhyZWF0L3NlY3VyaXR5DQo+YW5hbHlzaXMg Zm9yIHVzZSBvZiB0aGlzIGZ1bmN0aW9uIHdpdGggTkVUQ09ORiBhbmQgUkVTVENPTkYgYWZ0ZXIg dGhlDQo+bGFzdCBzZW50ZW5jZToNCj4NCj4gICBJbiBzdWNoIGNpcmN1bXN0YW5jZXMsIGFsbG93 aW5nIHRoZSBTU0gvVExTIHNlcnZlciB0byBjb250YWN0IHRoZQ0KPiAgIFNTSC9UTFMgY2xpZW50 IHdvdWxkIG9wZW4gbmV3IHZ1bG5lcmFiaWxpdGllcy4gIEFueSB1c2Ugb2YgY2FsbCBob21lDQo+ ICAgd2l0aCBTU0gvVExTIGZvciBwdXJwb3NlcyBvdGhlciB0aGFuIE5FVENPTkYgb3IgUkVTVENP TkYgd2lsbCBuZWVkIGENCj4gICB0aG9yb3VnaCwgY29udGV4dHVhbCBzZWN1cml0eSBhbmFseXNp cy4NCg0KVW5mb3J0dW5hdGVseSwgdGhlcmUgaXNuJ3QgYW4gYW5hbHlzaXMgdG8gcG9pbnQgdG8u ICBUaGUg4oCcYW5hbHlzaXPigJ0gaXMgaGFwcGVuaW5nIG5vdyBhbG9uZyB3aXRoIHRoZSBTZWNE aXIgcmV2aWV3LiAgIERvIHdlIG5lZWQgdG8gcGVyZm9ybSBzdWNoIGFuIGFuYWx5c2lzIG5vdz8N Cg0KDQpUaGFua3MgYWdhaW4sDQpLZW50DQoNCg0KDQo= From nobody Wed Oct 21 14:19: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 57DF51B30E1; Wed, 21 Oct 2015 14:19: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 7zE126--_Suw; Wed, 21 Oct 2015 14:19:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54911B30DD; Wed, 21 Oct 2015 14:19:55 -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.306.13; Wed, 21 Oct 2015 21:19:48 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Wed, 21 Oct 2015 21:19:48 +0000 From: Kent Watsen To: Martin Stiemerling , The IESG Thread-Topic: Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRDECqumWzTp3zDkeqqgbImWNS8p52MN2A Date: Wed, 21 Oct 2015 21:19:48 +0000 Message-ID: <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> References: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> In-Reply-To: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:zqTynvohLUriDOfdAUeb6DOuuYvemIsYXl+d6EMQkMdAgPjtZMuaSPdAYnn49BKAuHNj7pUjnjzLa2u5PlUUBaJUbtfO26eO7xlag9+vVecLtzJVsfcQX5b73nIyteNghtG9uOjblxCDP9jcctp0+g==; 24:S2tbXIJ9mxNTCEvgNfKLef8H6kz2cQxFdCFiVpV0m6m8FRRsvzzjclP3hBwYpxbVyyICzWN6gDRyeCRLUA/YWMFFt1v3hZiwymx0tctXjuU=; 20:yuMizF94U0TsJCtKGhfQ5mVJrc8N5VlW0SHzHEq37s8r5UR85Zlc61u29yjEYgW15yUFoybITnBWXz09zoOmbw== 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)(2401047)(8121501046)(520078)(5005006)(3002001)(102115026); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(189002)(199003)(43784003)(36756003)(11100500001)(33656002)(50986999)(76176999)(4001350100001)(19580395003)(189998001)(97736004)(2950100001)(2900100001)(5007970100001)(64706001)(5002640100001)(5001960100002)(5001770100001)(54356999)(5004730100002)(66066001)(81156007)(102836002)(15975445007)(86362001)(83716003)(106116001)(230783001)(105586002)(40100003)(87936001)(106356001)(82746002)(10400500002)(101416001)(46102003)(99286002)(122556002)(5008740100001)(83506001)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3381C234A1097C4D9C3B72A6C4D58C60@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2015 21:19:48.5169 (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-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 21:19:58 -0000 SGkgTWFydGluLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3Lg0KDQoNCg0KDQo+MSkgV2h5 IGlzIHRoaXMgcGFyYXByYXBoIGJlbG93IChhbmQgc3Vic2VxdWVudGx5IHRoZSBvdGhlciBzaW1p bGFyIG9uZXMpIA0KPnVzaW5nIFJGQyAyMTE5IGxhbmd1YWdlIHdpdGggcmVzcGVjdCB0byB0aGUg cG9ydCBudW1iZXJzDQo+ICAgICAgIFRoZSBORVRDT05GL1JFU1RDT05GIGNsaWVudCBsaXN0ZW5z IGZvciBUQ1AgY29ubmVjdGlvbiByZXF1ZXN0cw0KPiAgICAgICBmcm9tIE5FVENPTkYvUkVTVENP TkYgc2VydmVycy4gIFRoZSBjbGllbnQgU0hPVUxEIGxpc3RlbiBmb3INCj4gICAgICAgY29ubmVj dGlvbnMgb24gdGhlIElBTkEtYXNzaWduZWQgcG9ydHMgZGVmaW5lZCBpbiBzZWN0aW9uDQo+ICAg ICAgIFNlY3Rpb24gNSwgYnV0IE1BWSBiZSBjb25maWd1cmVkIHRvIHVzZSBhIG5vbi1zdGFuZGFy ZCBwb3J0Lg0KPg0KPlVzaW5nIHRoZSByaWdodCBwb3J0IG51bWJlciBpcyBub3Qgc29tZXRoaW5n IHRoYXQgaW5mbHVlbmNlcyB0aGUNCj5pbnRlcm9wZXJhYmlsaXR5IG9mIHRoZSBwcm90b2NvbCBw ZXIgc2UsIGJ1dCBpcyBhbiBvcGVyYXRpb25hbCBwYXJhbWV0ZXIuDQo+Q2hlY2tpbmcgb3RoZXIg cHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMsIGUuZy4gSFRUUC8xLjEsIHRoZXJlIGlzIG5vIFJGQw0K PjIxMTkgbGFuZ3VhZ2UgYWJvdXQgdGhlIHVzYWdlIG9mIHNwZWNpZmljIHBvcnQgbnVtYmVycy4g IA0KDQpUaGlzIGlzIHRydWUuICBJIGRvbuKAmXQgc2VlIFJGQyAyMTE5IGxhbmd1YWdlIGluIFJG QyA0MjUzIGVpdGhlci4gICBUaGF0IHNhaWQsIGlzIGl0IGluIGFueSB3YXkgd3Jvbmcgb3IgYmFk PyAgIEnigJltIGhhcHB5IHRvIGNoYW5nZSB0aGUgdGV4dCBvZiBjb3Vyc2UsIGp1c3Qgd2FudCB0 byBjb25maXJtLi4uDQoNCg0KDQo+MikgSSBhbSBub3QgYSBmYW4gb2YgaGF2aW5nIGRpZmZlcmVu dCBwb3J0IG51bWJlcnMgdG8gZGlmZmVyZW50aWF0ZQ0KPmRpZmZlcmVudCB2YW5pbGxhIGZsYXZv cnMgb2YgYSBwcm90b2NvbC4gSG93ZXZlciwgSSBjYW4gdW5kZXJzdGFuZCB0aGUNCj53aHkgdGhp cyBpcyBoYXBwZW5pbmcgdGhpcyB3YXkuIEJ1dCB3aGF0IGlzIGhhcHBlbmluZyBpZiB0aGVyZSBp cw0KPlgtb3Zlci1UTFMvU1NIL2ZvbyBjb21pbmcgYWZ0ZXIgUkVTVENPTkY/IEFyZSB5b3UgYWdh aW4gaW4gbmVlZCBvZiBtb3JlDQo+cG9ydCBudW1iZXJzPyBUaGlzIGRvZXMgbm90IGxvb2sgbGlr ZSBhIAl0YWN0aWNhbCB3aXNlIGFuZCBzdXN0YWluYWJsZQ0KPndheS4NCg0KSm9lIFRvdWNoIG1h ZGUgYSBzaW1pbGFyIGNvbW1lbnQgYWJvdXQgYSB5ZWFyIGFuZCBhIGhhbGYgYWdvLiAgIFRoZXJl IHdhcyBxdWl0ZSBhIGRlYmF0ZSBhYm91dCBpdCB0aGVuLiAgIFdlIGRpc2N1c3NlZCB0aGUgb3B0 aW9uIG9mIGhhdmluZyBqdXN0IG9uZSBwb3J0IGZvciBhbnkgbnVtYmVyIHRvIFRDUC1iYXNlZCBj YWxsIGhvbWUgcHJvdG9jb2xzLiAgIEluIHRoZSBlbmQsIHRoZSBXRyBjb25zZW5zdXMgd2FzIHRv IHVzZSBkaXN0aW5jdCBwb3J0cyBhcyB3cml0dGVuIGluIHRoZSBjdXJyZW50IHRleHQuICBJcyB0 aGlzIHNvbWV0aGluZyB5b3Ugd291bGQgbGlrZSB0byByYWlzZSBhZ2FpbiBub3c/DQoNCg0KDQo+ IA0KPjMpIFRoaXMgZG9jdW1lbnQgd2lsbCBiZW5lZml0IGZyb20gYW4gb3ZlcnZpZXcgZmlndXJl IHRoYXQgZGV0YWlscyB3aG8gaXMNCj50aGUgc2VydmVyL2NsaWVudCBvbiB3aGF0IGxldmVsIGZv ciB3aGF0Lg0KDQoNCkkgdHJlZCB0aGlzIGJlZm9yZSBhbmQgdGhlIGNvbW1lbnQgcmVjZWl2ZWQg d2FzIHRoYXQgaXQgd2FzIGNvbmZ1c2luZzogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwOTk3OC5odG1sLiAgIEJ1dCB0aGF0IHdhcyBqdXN0 IG9uZSBvcGluaW9uLiAgV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhlIGRpYWdyYW0gaW4gdGhl IGxpbmtlZCBtZXNzYWdlPw0KDQoNCg0KVGhhbmtzIGFnYWluLA0KS2VudA0KDQoNCg== From nobody Wed Oct 21 14:24:32 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 65B081B3111; Wed, 21 Oct 2015 14:24:30 -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 Evm9f8z-r1_N; Wed, 21 Oct 2015 14:24:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9D4C01B30F8; Wed, 21 Oct 2015 14:24:28 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9LLOQm3056546 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2015 16:24:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Kent Watsen" Date: Wed, 21 Oct 2015 16:24:26 -0500 Message-ID: <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> In-Reply-To: <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , The IESG , Barry Leiba , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 21:24:30 -0000 On 21 Oct 2015, at 15:18, Kent Watsen wrote: > Hi Ben, > > Thank you for your review. > > > Regarding your original comments: > > >> If the client MAY be configured to listen on a non-standard port, >> doesn’t >> that imply that the server MUST be _capable_ of being configured to >> connect to a non-standard port? > > This is correct and what draft-ietf-netconf-server-model-08 allows. > Were you thinking that there needs to be a change in this draft? I think it's worth a mention. People will probably figure it out for themselves, but it's usually better to be explicit. > > >> I'm curious why people felt it necessary to reverse the usual TLS or >> SSH >> client and server roles. Did the working group consider having the >> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the > > As Juergen noted, this allows that all existing authentication to > continue working. Also, since SSH is not a symmetric protocol, it’s > actually important for the client to be the SSH-client so it can > open/close SSH channels (e.g., to start the “netconf” subsystem). > > > > > > And regarding your latest message: > >> Paraphrasing back to check my understanding: >> >> At least for the case of TLS, The NETCONF/RESTCONF server is >> authenticated by TLS, and the client by credentials that are >> exchanged >> after the TLS handshake completes? > > NETCONF over TLS requires the client to use client-certificate based > authentication and this happens at the time the TLS session is being > established, for the NETCONF protocol layer starts. > > RESTCONF over TLS (the only choice) uses HTTP Authentication > [RFC7235]. When “Basic” or “Digest” are used, the > client-authentication is after the TLS session has been established. > The “ClientCertificate” is used, then the client-authentication > occurs at the time the TLS session is being established (same as > NETCONF over TLS). > > > > >> I'm going to go out on a limb and guess that that approach is an >> artifact of the normal (non-call-home) connection direction, and a >> lack >> of client certs? I am no NETCONF expert, so forgive me if I am >> missing >> some other obvious reason. > > Yes, that is fair to say, in the sense that it is very easy to > implement it this way. For instance, JUNOS uses `inetd` to listen on > port 22 and, when a TCP connection is established, it forks/execs > `sshd -i` passing the open socket descriptor. So to implement call > home, all that had to be done was to write a daemon that initiates the > TCP connection to the client and then, as soon as the TCP connection > is established, it forks/execs `sshd -i` exactly like how `inetd` does > it. Everything else stays the same. In fact, the SSH has no > awareness of how it was invoked. > > > >> However, this does make me wonder about the statement in the Security >> Considerations that the DoS potential is "no different than for any >> other secured service". The reversed connection approach seems to >> allow >> an attacker to cause the NETCONF client to perform computationally >> intense operations with just a TCP connection--that is, with >> marginally >> less effort on the part of the attacker. I'm not sure that's enough >> difference to make a real-world difference, but it might be worth a >> mention. > > > A normal SSH or TLS server accepts the TCP connection and immediately > starts a computationally expensive operation (proving it has the > private key associated with its SSH host key or TLS server > certificate). > > Here we have similar setup, except the client has the port open and it > starts the SSH/TLS client protocol. It could be argued that the > client protocol is less expensive than the server protocol, so perhaps > it’s not so bad. My point is not that this increases the work of the NETCONF client, it's that it decreased the work of an attacker. In the normal case, the client has to open a TCP connection and send a ClientHello before the server is forced to send the ServerHello. In this case, an attacker could force the client to send the ClientHello by merely opening a TCP connection. Admittedly, the ClientHello is not a particularly heavyweight operation, so the required work for the NETCONF client, and the reduced work for the attacker may be too trivial to matter. > > Still, for the draft, what do you recommend changing? The current > text follows: > > An attacker could launch a denial of service (DoS) attack on the > NETCONF/RESTCONF client by having it perform computationally > expensive operations, before deducing that the attacker doesn't > posses a valid key. This is no different than any secured service > and all common precautions apply (e.g., blacklisting the source > address after a set number of unsuccessful login attempts). I think it wouldn't hurt to change the "This is no different" text to say "This is slightly different...because...". But if you believe the trigger of the ClientHello is too trivial to matter, then the text is okay as is. (In any case, this is a non-blocking comment, so don't get too wrapped around it.) Thanks! Ben. From nobody Wed Oct 21 14:29: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 B75351B3117; Wed, 21 Oct 2015 14:29:34 -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 DOBnIz1Kuneb; Wed, 21 Oct 2015 14:29:33 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::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 28E301B3132; Wed, 21 Oct 2015 14:29:31 -0700 (PDT) Received: by wicll6 with SMTP id ll6so93204221wic.1; Wed, 21 Oct 2015 14:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=mnfiho0NgGHNPhThB1TKsUorPXzOEV9jGtoe/TvmhAs=; b=T4zaO06dHSlcDEf5dIrS8XeWzcuDxEkTODa39eqkfQ1EaX9SyiigoyPCww4D821hpa +DhUyMlNWaT7Ehj4TvJtPcizSKGE+tv1Ffs7Fc8DCrbJQ3j1G3fMsf2zM7FN2Y64mf02 pIMcfqpzWP17QbICKKGHu1BnPdUoVvNdP75JYsWbaL3hQ2xxCL2D7hte2O0Qo/jHI2HO 38jC1WwglkZFA4dqqMTP59iGGC/4EH6bKgCEa8XPIJbgZ+YFjzb19HI6u6VQoD2upKke HQUc2YwIdVNYqpTN5nmbyN2xhR891qia3fxX9u04waJAGA3fTS+KpoJrVIk+5m9/O4xg CnSA== X-Received: by 10.194.120.131 with SMTP id lc3mr12516741wjb.99.1445462969697; Wed, 21 Oct 2015 14:29:29 -0700 (PDT) Received: from Martins-MBP.fritz.box ([2001:1a80:280b:500:a0a0:f6a6:f640:6c47]) by smtp.googlemail.com with ESMTPSA id m9sm8917384wib.13.2015.10.21.14.29.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2015 14:29:28 -0700 (PDT) To: Ben Campbell , Kent Watsen References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> From: Martin Stiemerling Message-ID: <562803B6.8000209@gmail.com> Date: Wed, 21 Oct 2015 23:29:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , Netconf , Barry Leiba , The IESG Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 21:29:34 -0000 Am 21.10.15 um 23:24 schrieb Ben Campbell: >> >> A normal SSH or TLS server accepts the TCP connection and immediately >> starts a computationally expensive operation (proving it has the >> private key associated with its SSH host key or TLS server certificate). >> >> Here we have similar setup, except the client has the port open and it >> starts the SSH/TLS client protocol. It could be argued that the >> client protocol is less expensive than the server protocol, so perhaps >> it’s not so bad. > > My point is not that this increases the work of the NETCONF client, it's > that it decreased the work of an attacker. In the normal case, the > client has to open a TCP connection and send a ClientHello before the > server is forced to send the ServerHello. In this case, an attacker > could force the client to send the ClientHello by merely opening a TCP > connection. > > Admittedly, the ClientHello is not a particularly heavyweight operation, > so the required work for the NETCONF client, and the reduced work for > the attacker may be too trivial to matter. The question is how 'expensive' the state keeping for a ClientHello is on the client side, especially since an attacker could send a large amount of TCP connection requests, and handle them so that the TCP connection is set up, and potentially drive the client out of memory. Just my two cents Martin From nobody Wed Oct 21 15:00: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 11C821B324C; Wed, 21 Oct 2015 15:00: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 NAMYx6qE8csD; Wed, 21 Oct 2015 15:00: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 188DB1B324A; Wed, 21 Oct 2015 15:00: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 8857A8DD; Thu, 22 Oct 2015 00:00: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 tfoiWsxcm-bG; Thu, 22 Oct 2015 00:00: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; Thu, 22 Oct 2015 00:00:50 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBFB020053; Thu, 22 Oct 2015 00:00:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VKn5KLrG9vKj; Thu, 22 Oct 2015 00:00:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 346352003B; Thu, 22 Oct 2015 00:00:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1162E386110D; Thu, 22 Oct 2015 00:00:45 +0200 (CEST) Date: Thu, 22 Oct 2015 00:00:45 +0200 From: Juergen Schoenwaelder To: Ben Campbell Message-ID: <20151021220045.GB20407@elstar.local> Mail-Followup-To: Ben Campbell , Barry Leiba , Mahesh Jethanandani , netconf-chairs@ietf.org, Netconf , draft-ietf-netconf-call-home@ietf.org, The IESG References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> 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: <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, The IESG , Barry Leiba , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (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: Wed, 21 Oct 2015 22:00:55 -0000 On Wed, Oct 21, 2015 at 09:34:19AM -0500, Ben Campbell wrote: > On 21 Oct 2015, at 4:40, Juergen Schoenwaelder wrote: > > >On Wed, Oct 21, 2015 at 05:28:33AM -0400, Barry Leiba wrote: > >>>>I'm curious why people felt it necessary to reverse the usual TLS > >>>>or SSH > >>>>client and server roles. Did the working group consider having the > >>>>NETCONF/RESTCONF server act as the TLS or SSH client? If so, can > >>>>the > >>>>reasons be summarized in a sentence or two? > >>> > >>>I believe that the NETCONF/RESTCONF server is acting as the TLS or > >>>SSH > >>>client during call home. What (I think) Kent is trying to imply is > >>>that > >>>"NETCONF/RESTCONF server” is the entity that runs on the network > >>>element, > >>>and is a server for NETCONF/RESTCONF and TLS/SSH during normal > >>>operations, > >>>but which acts as a TLS or SSH client during call home. > >> > >>No, not so. Normally, if protocol XX will run over, say, TLS, the XX > >>client opens a TCP connection to the XX server, and then the XX > >>client > >>starts a TLS handshake. > >> > >>Here, where XX == NETCONF or RESCONF, the XX *server* opens a TCP > >>connection to the XX *client*... and then the XX client responds by > >>starting a TLS handshake. > >> > >>What Ben is asking is this: Why doesn't the NETCONF/RESCONF server > >>start the TLS handshake (and similarly for SSH), maintaining the > >>normal TLS or SSH setup? What was the reason for reversing it? > > > >Authentication is not symmetrics, in particular with SSH where the > >server is authenticated by its hostkey and the client by credentials > >(of different forms) associated with the notion of a user. > > Paraphrasing back to check my understanding: > > At least for the case of TLS, The NETCONF/RESTCONF server is > authenticated by TLS, and the client by credentials that are exchanged > after the TLS handshake completes? No. > I'm going to go out on a limb and guess that that approach is an > artifact of the normal (non-call-home) connection direction, and a lack > of client certs? I am no NETCONF expert, so forgive me if I am missing > some other obvious reason. RFC 7589 uses X.509 on both sides. > That motivation appears reasonable on the surface. I will leave it to > people who have a deeper understanding of TLS subtleties than I to say > if that causes any problems. We got told back at that IETF meeting that even with TLS, server and client certs may not be fully interchangeable. Anyway, with SSH credentials and the authentication mechanisms clearly are not symmetric. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Oct 21 15: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 48D711B3267; Wed, 21 Oct 2015 15:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 imRKGbL6NWEM; Wed, 21 Oct 2015 15:04:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9D21B326B; Wed, 21 Oct 2015 15:04:05 -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.306.13; Wed, 21 Oct 2015 22:03:59 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Wed, 21 Oct 2015 22:03:59 +0000 From: Kent Watsen To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRC2fK1cpI6GApn0KSl4VpDLgb8552PucA Date: Wed, 21 Oct 2015 22:03:59 +0000 Message-ID: References: <20151020184735.19913.19977.idtracker@ietfa.amsl.com> In-Reply-To: <20151020184735.19913.19977.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:fmX52Wk4sxH0Na0XtdkCdfaxEzOn+DAczhmBYm/lT41N65h2X8HqPeWVu87hjwhd4xC3LPJyhAlul4TRW31Yrd+THtf/4qVJrhoNe2Evr8eQl17KqEhcVDsS5WDp+e/Ye7fVpZPyPxXK8Pl8dbd0Fw==; 24:ReaBRK07gdgUmm0ZzT0nnt0D4LveIOGczpwCHE89myZLdkD5qlgI3nJ7DsR3Tzuq5O4kT/vhtWsS0N+oqApJk3POfHpiD19b+OVrBHUT7Hs=; 20:zvGJFPyF9yZKQgbYfQeveH/AKPPOJVAvqoR0Y66A+br1TEPHR6fHhvQSQu/cK0cwYZFuc9Y52y5ojnblWFzRYg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102115026); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 073631BD3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51444003)(43784003)(199003)(83716003)(40100003)(102836002)(66066001)(87936001)(64706001)(2900100001)(2950100001)(92566002)(122556002)(230783001)(5002640100001)(82746002)(46102003)(83506001)(36756003)(5001770100001)(97736004)(50986999)(54356999)(76176999)(189998001)(5004730100002)(11100500001)(10400500002)(101416001)(81156007)(5008740100001)(4001350100001)(5001960100002)(5007970100001)(99286002)(86362001)(106116001)(33656002)(106356001)(105586002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5A292ABB3EBB43408AA9E14B821F23D9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2015 22:03:59.5826 (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: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Barry Leiba's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 22:04:13 -0000 DQpIaSBCYXJyeSwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlldy4NCg0KDQoNCg0KPkluIFNl Y3Rpb24gMi4xLCBDNToNCj4NCj4gICAgICAgVGhpcyB2YWxpZGF0aW9uIE1BWSBiZSBhY2NvbXBs aXNoZWQgYnkgY2VydGlmaWNhdGUNCj4gICAgICAgcGF0aCB2YWxpZGF0aW9uIG9yIGJ5IGNvbXBh cmluZyB0aGUgaG9zdCBrZXkgb3IgY2VydGlmaWNhdGUgdG8gYQ0KPiAgICAgICBwcmV2aW91c2x5 IHRydXN0ZWQgb3IgInBpbm5lZCIgdmFsdWUuDQo+DQo+SXQncyBhIGZpbm5pY2t5IHBvaW50LCBi dXQgSSB0aGluayBpdCdzIGFuIGltcG9ydGFudCBvbmU6ICBZb3UgbGlzdCB0d28NCj5tZXRob2Rz IGZvciB2YWxpZGF0aW9uOiAoMSkgY2VydCBwYXRoIHZhbGlkYXRpb24sIGFuZCAoMikgY29tcGFy aW5nIHRvIGENCj5waW5uZWQgdmFsdWUuICBJcyBpdCAoQSkgYWNjZXB0YWJsZSBmb3IgdGhlIHZh bGlkYXRpb24gdG8gYmUgZG9uZSBieQ0KPm90aGVyIG1ldGhvZHMgYXMgd2VsbCBhcyB0aG9zZSB0 d28/ICBPciBpcyBpdCAoQikgcmVxdWlyZWQgdGhhdCBvbmUgb2YNCj50aG9zZSB0d28gYmUgdXNl ZCwgYnV0IGVpdGhlciBpcyBhY2NlcHRhYmxlPw0KDQpJdCBpcyBBLCBidXQgdGhlc2UgdHdvIGFy ZSBieSBmYXIgdGhlIG1vc3QgY29tbW9uLg0KDQoNCj5JZiAoQSksIHRoZW4gdGhlIHRleHQgaXMg ZmluZSBhcyBpdCBpcy4gIEJ1dCBpZiAoQiksIHRoZSB0ZXh0IGFzIHdyaXR0ZW4NCj5kb2Vzbid0 IHJlcXVpcmUgdGhlIHVzZSBvZiBvbmUgb2YgdGhlIHNwZWNpZmllZCBtZXRob2RzLCBiZWNhdXNl ICJNQVkiIGlzDQo+b3B0aW9uYWwuICBJZiB5b3UgbWVhbiAoQiksIHlvdSBzaG91bGQgd3JpdGUg aXQgYXMgIk1VU1QgYmUgYWNjb21wbGlzaGVkDQo+ZWl0aGVyIGJ5IFsuLi5dIG9yIGJ5IFsuLi5d LiIgIEFsdGVybmF0aXZlbHksIHlvdSBjb3VsZCBqdXN0IGFkZCBpdCB0bw0KPnRoZSBwcmV2aW91 cyBzZW50ZW5jZSwgYXMsICcuLi5jbGllbnQgTVVTVCB2YWxpZGF0ZSB0aGUgc2VydmVyJ3MNCj5w cmVzZW50ZWQgaG9zdCBrZXkgb3IgY2VydGlmaWNhdGUsIGVpdGhlciB1c2luZyBjZXJ0aWZpY2F0 ZSBwYXRoDQo+dmFsaWRhdGlvbiBvciBieSBjb21wYXJpbmcgdGhlIGhvc3Qga2V5IG9yIGNlcnRp ZmljYXRlIHRvIGEgcHJldmlvdXNseQ0KPnRydXN0ZWQgb3IgInBpbm5lZCIgdmFsdWUuJw0KDQpJ 4oCZbGwgcGxhbiB0byBrZWVwIHRoZSBjdXJyZW50IHRleHQgdGhlbi4NCg0KDQoNCg0KPkluIFNl Y3Rpb24gMi4xLCBDOCwgYW4gZXZlbiBtb3JlIGZpbm5pY2t5IGFuZCBub3QgdmVyeSBpbXBvcnRh bnQgcG9pbnQ6DQo+DQo+ICAgICAgIE9uY2UgdGhlIFNTSCBvciBUTFMgY29ubmVjdGlvbiBpcyBl c3RhYmxpc2hlZCwgdGhlIE5FVENPTkYvDQo+ICAgICAgIFJFU1RDT05GIGNsaWVudCBNVVNUIGlt bWVkaWF0ZWx5IHN0YXJ0IHVzaW5nIGVpdGhlciB0aGUgTkVUQ09ORi0NCj4gICAgICAgY2xpZW50 IFtSRkM2MjQxXSBvciBSRVNUQ09ORi1jbGllbnQgW2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29u Zl0NCj4gICAgICAgcHJvdG9jb2wuDQo+DQo+V2hhdCAqZWxzZSogbWlnaHQgdGhlIGNsaWVudCBk bywgd2hpY2ggbWVyaXRzIGEgTVVTVCBoZXJlPyAgSSB0aGluayBhbGwNCj55b3Ugc2hvdWxkIHNh eSBoZXJlIGlzLCAiT25jZSB0aGUgU1NIIG9yIFRMUyBjb25uZWN0aW9uIGlzIGVzdGFibGlzaGVk LA0KPnRoZSBORVRDT05GL1JFU0NPTkYgY2xpZW50IHN0YXJ0cyB1c2luZyBlaXRoZXIgWy4uLnRo ZSBwcm90b2NvbHMuLi5dLiINCg0KQSBtaXNiZWhhdmluZyBjbGllbnQgbWlnaHQgdHJ5IHRvIHN0 YXJ0IGFub3RoZXIgcHJvdG9jb2wsIG9yIHNlbmQgc29tZSBvdGhlciBraW5kIG9mIGRhdGEsIG9y IG1heWJlIG5vdCBkbyBpdCDigJxpbW1lZGlhdGVseeKAnS4gICBUaGF0IHNhaWQsIEnigJltIG9r YXkgcmVtb3ZpbmcgdGhlICJNVVNUIGltbWVkaWF0ZWx54oCdIGlmIHlvdSB0aGluayBpdCBpbXBy b3ZlcyB0aGUgdGV4dC4NCg0KDQoNCg0KPkNvbnRpbnVpbmcuLi4NCj4NCj4gICAgICAgQXNzdW1p bmcgdGhlIHVzZSBvZiB0aGUgSUFOQS1hc3NpZ25lZCBwb3J0cywgdGhlDQo+ICAgICAgIE5FVENP TkYtY2xpZW50IHByb3RvY29sIGlzIHN0YXJ0ZWQgd2hlbiB0aGUgY29ubmVjdGlvbiBpcw0KPiAg ICAgICBhY2NlcHRlZCBvbiBlaXRoZXIgcG9ydCBQT1JULVggb3IgUE9SVC1ZIGFuZCB0aGUgUkVT VENPTkYtY2xpZW50DQo+ICAgICAgIHByb3RvY29sIGlzIHN0YXJ0ZWQgd2hlbiB0aGUgY29ubmVj dGlvbiBpcyBhY2NlcHRlZCBvbiBwb3J0IFBPUlQtDQo+ICAgICAgIFouDQo+DQo+QnV0IG5vOiB0 aGUgKE5FVENPTkYvUkVTQ09ORiktY2xpZW50IHByb3RvY29sIGlzIE5PVCBzdGFydGVkIHdoZW4g dGhlDQo+Y29ubmVjdGlvbiBpcyBhY2NlcHRlZCAodGhhdCB3YXMgaW4gQzIpLCBidXQgd2hlbiB0 aGUgU1NIL1RMUw0KPmNvbm5lY3Rpb24vc2Vzc2lvbiBpcyBlc3RhYmxpc2hlZC4gIFdoaWNoIHlv dSBhbHJlYWR5IHNhaWQgaW4gdGhlDQo+cHJldmlvdXMgc2VudGVuY2UsIGFuZCBDMSBhbHJlYWR5 IHNhaWQgd2hhdCBwb3J0cyB0aGUgY2xpZW50IGxpc3RlbnMgb24uIA0KPldoeSBpcyB0aGlzIHNl bnRlbmNlIGV2ZW4gaGVyZT8gIFdoeSBub3QganVzdCByZW1vdmUgaXQ/DQoNCkkgdGhpbmsgeW91 4oCZcmUgc2F5aW5nIHR3byB0aGluZ3MuDQoNCjEuIFRoZSAiaXMgc3RhcnRlZCB3aGVuIHRoZSBj b25uZWN0aW9uIGlzIGFjY2VwdGVk4oCdIGlzIGluYWNjdXJhdGUsIGluIHRoYXQgaXQgaXNu4oCZ dCByZWFsbHkgc3RhcnRlZCB0aGVuLiAgUGVyaGFwcyDigJxpcyB1c2VkIHdoZW4gdGhlIGNvbm5l Y3Rpb24gaXMgYWNjZXB0ZWTigJ0gd291bGQgYmUgYmV0dGVyPw0KDQoyLiBUaGUgc2VudGVuY2Ug bWF5IG5vdCBiZSBuZWVkZWQgYXQgYWxsLiAgIEkgdGhpbmsgdGhhdCBpdCBpcyBuZWVkZWQgaW4g dGhhdCBpdCBjbGFyaWZpZXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yLiBGb3IgaW5zdGFuY2UsIHdl IHdvdWxkbuKAmXQgd2FudCBhIGNsaWVudCB0aGF0IGlzIHN1cHBvc2UgdG8gc3RhcnQgTkVUQ09O RiB0byBhY2NpZGVudGFsbHkgc3RhcnQgUkVTVENPTkYuICBNYWtlcyBzZW5zZSwgb3IgZG8geW91 IHN0aWxsIGZlZWwgdGhhdCB0aGUgc2VudGVuY2Ugc2hvdWxkIGJlIHJlbW92ZWQ/DQoNCg0KDQo+ VGhlc2Ugc2FtZSB0d28gY29tbWVudHMgYXBwbHkgdG8gUzYgaW4gU2VjdGlvbiAzLjEuDQoNCkFD Sy4NCg0KDQpUaGFua3MgYWdhaW4sDQpLZW50DQoNCg== From nobody Wed Oct 21 15: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 F33CD1B3274; Wed, 21 Oct 2015 15:08:03 -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 ltfy-J61QT4f; Wed, 21 Oct 2015 15:08:01 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::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 21D7F1B3263; Wed, 21 Oct 2015 15:08:01 -0700 (PDT) Received: by ykdr3 with SMTP id r3so64598233ykd.1; Wed, 21 Oct 2015 15:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PA+rQijQowYiz9d58dYxtXILhDR3MPU3GwryYFnYl1w=; b=GSLOgepqfVI4epQqCvwBBI860X1yV/ZgXeQ/4gHVrqVFbfM/BVsAXCUbuSqY7iNDcT 3TBXCTeCEz9Agt+kW1Zsfov5RhyoAuuQcuRZZmcbcxJvosDaLz2HSanGTXtGkm3hcUoF K2HllEI1ewn6Bb3uJcISjxBr7+9uuWrNdB9JID2cMHm6K2qD2MX0VpKeK/04RXbbU+0p /lTtRKgonQjh++MlgGZnS/7kSliOIOXJBUchq40AZfrpvEJqwzGjvJsjzTvCjNtY2Ebt SOwYYzpPJ29yzMcY0KmAGaHBvBX6Z8QaGO2r5U0RFbA6jBo3Dzt59NlpOcwA+By9Y4d2 kgow== X-Received: by 10.129.32.195 with SMTP id g186mr9554873ywg.18.1445465280388; Wed, 21 Oct 2015 15:08:00 -0700 (PDT) Received: from [192.168.1.14] (pool-96-233-21-91.bstnma.east.verizon.net. [96.233.21.91]) by smtp.gmail.com with ESMTPSA id g5sm7464128ywf.16.2015.10.21.15.07.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Oct 2015 15:07:58 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <4F2C1542-6FCB-4B67-91A8-7AD55BC34EB5@juniper.net> Date: Wed, 21 Oct 2015 18:07:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151021135330.20048.35548.idtracker@ietfa.amsl.com> <4F2C1542-6FCB-4B67-91A8-7AD55BC34EB5@juniper.net> To: Kent Watsen Archived-At: Cc: "netconf@ietf.org" , The IESG , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 22:08:04 -0000 Hi Kent, Thanks for your quick response. I'm just on an iPhone, but don't want to wa= it to respond in case it helps you. Inline. Sent from my iPhone > On Oct 21, 2015, at 4:52 PM, Kent Watsen wrote: >=20 >=20 > Hi Kathleen, >=20 > Thank you for your review. >=20 >=20 >=20 >=20 >=20 >=20 >> Section 2.1 & 3.1 >> Why is authentication limited to server-side authentication? It seems >> that this really should be mutual authentication to ensure the server is >> also connecting to the correct client and there was no attack prior to >> the callback. >=20 >=20 > Both NETCONF ad RESTCONF require client authentication, and this is called= out in the Applicability Statement (Section 1.3). Also, in the "The NETCON= F or RESTCONF Client=E2=80=9D section, it says: >=20 > C7 After the server's host key or certificate is validated, the SSH > or TLS protocol proceeds as normal to establish a SSH or TLS > connection. >=20 > The =E2=80=9Cproceeds as normal=E2=80=9D is intended to cover client authe= ntication. =20 Ok, this wasn't clear to me, but probably isn't the sentence to fix. > Also, in the "The NETCONF or RESTCONF Server=E2=80=9D section, it says: >=20 >=20 > S5 In most cases, establishing the SSH or TLS connection also > entails server authentication of client credentials; only with > RESTCONF do some client authentication schemes occur after the > secure transport connection (TLS) has been established. =20 I think if this said, "Establishing an SSH or TLS session requires server au= thentication of client credentials, with the exception of..." The point would be more clear as I didn't realize this was already the case f= rom the language in this draft. > If > client authentication is required, and the client is unable to > successfully authenticate itself to the server in an amount of > time defined by local policy, the server MUST close the > connection. >=20 > Which speaks to it as well. >=20 >=20 > Do you believe there is a need to change the text? Yes, but just the text where I made a suggestions u be enough to get the poi= nt across more clearly. >=20 >=20 >=20 >=20 >> 3.1 S3 - Why is client-side authentication optional? >>=20 >> Without this must, there should be a security consideration that the call= >> back could go to a malicious client. The types of authentication matter >> as well, but that's covered in Stephen's discuss points along with the >> SecDir review questions on TLS-PSK. >=20 > Do mean S5 pasted above where it says =E2=80=9CIf client authentication is= required=E2=80=9D? Yes. >=20 > This text is speaking about transport-level client-auth. NETCONF over SSH= or over TLS both have transport-level authentication, but RESTCONF (e.g., H= TTPS) allows the Basic and Digest authentication modes, and that client auth= happen after the TLS session is established. Ok, is it possible to make this more clear? I think Stephen has a discuss o= n HTTPAuth methods already, so that can be discussed in his thread. I just a= sk that you point to the newly updated RFCs on these 2 standards as they do a= good job of outlining all of the security considerations, which are substan= tial. RFC7616 & RFC 7615 >=20 > Is it clear now, or do you think that text should be updated? >=20 >=20 >=20 >=20 >> In section 1.3, please add a sentence that points to the threat/security >> analysis for use of this function with NETCONF and RESTCONF after the >> last sentence: >>=20 >> In such circumstances, allowing the SSH/TLS server to contact the >> SSH/TLS client would open new vulnerabilities. Any use of call home >> with SSH/TLS for purposes other than NETCONF or RESTCONF will need a >> thorough, contextual security analysis. >=20 > Unfortunately, there isn't an analysis to point to. The =E2=80=9Canalysis= =E2=80=9D is happening now along with the SecDir review. Do we need to per= form such an analysis now? >=20 The section reads as if one exists and that you've mitigated the risks. As s= uch, I'd expect to see all of the security considerations for using the meth= od defined in this draft. Making the auth requirements more clear will help= and pointing out the vulnerability of the HTTPAuth basic and digest modes f= or RESTCONF in the security considerations is part of that. =20 Mention of the possibility of connecting to an incorrect client (possibly ma= licious) in the few instances where client auth isn't required or is weak is= important as well for the reader. Thank you! Kathleen=20 >=20 > Thanks again, > Kent >=20 >=20 >=20 From nobody Wed Oct 21 16:24: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 641E01B2D29; Wed, 21 Oct 2015 16:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_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 pRoao6cvUsSo; Wed, 21 Oct 2015 16:24:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2E21B2D25; Wed, 21 Oct 2015 16:24:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7C201BE57; Thu, 22 Oct 2015 00:24:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCFUowAWHqfF; Thu, 22 Oct 2015 00:24:00 +0100 (IST) Received: from [10.87.48.91] (unknown [86.42.31.61]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7CA97BE53; Thu, 22 Oct 2015 00:23:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445469840; bh=9ghkBjGdYWPqf1NAUv5iPAnkdz2kSaIRMHyOGqrG/Kw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Isv9ROiwdcBZRhCwCAlN1A1e7JeWlx5fhzFQEy0NPlxRjuWhf+tvKh/SRM+QWPFsW 0MVD2fzVMQeFvI3aUVWxbfyCJMJjEPsnXdOy/DUVUpcdRXBas2m60kYoBXnCJ5LUmF YB8vAedTfKnE7nUMbegF83sTSoSNtCDIiBOD9J1k= To: Martin Stiemerling , Ben Campbell , Kent Watsen References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> <562803B6.8000209@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56281E8F.9030008@cs.tcd.ie> Date: Thu, 22 Oct 2015 00:23:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562803B6.8000209@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , The IESG , Barry Leiba , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 23:24:05 -0000 Hiya, On 21/10/15 22:29, Martin Stiemerling wrote: > > The question is how 'expensive' the state keeping for a ClientHello is > on the client side, especially since an attacker could send a large > amount of TCP connection requests, and handle them so that the TCP > connection is set up, and potentially drive the client out of memory. I think that'd be worth checking, and maybe documenting yeah. I doubt there's a really bad thing here, e.g. I can't see there's a way to get the client to accept a session ticket from a bogus source but it would still be worth a look. But TLS clients could well be allocating space to hold a running hash for the finished and so be somewhat worse than a raw socket. I don't know if server-side mitigations for that kind of thing would be common in clients. Probably best to just wait 'till all the IESG comments are in and then we can work on a crisp (set of) question(s) to ask the TLS WG, and the openssh list, including Martin's. I'm happy to help with crafting that if folks want. S. From nobody Wed Oct 21 16:27: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 9B7A71B2D6F; Wed, 21 Oct 2015 16:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_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 rn6lG2l9_Pje; Wed, 21 Oct 2015 16:27:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207AF1A86EE; Wed, 21 Oct 2015 16:27:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D4C74BE83; Thu, 22 Oct 2015 00:27:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkIDOVsJTltG; Thu, 22 Oct 2015 00:27:39 +0100 (IST) Received: from [10.87.48.91] (unknown [86.42.31.61]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 308E9BE5D; Thu, 22 Oct 2015 00:27:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445470059; bh=MvuBoFFu1RjtHYWrVoA4rMv/CPORh543BIB4hnYjuEQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BzGQKA93Cbj44wdmYOGQKzdbQFn0Nl6Xg3uc7hcA3O6S7sTx91WNDnMQHAfQwSJBC gcW2g7d07M6J1OrvfiISt58T+IWLsOhnzFWhiGm1M/ohMvLXdBa5Rvuib0NfQqyvsQ ybmtMLPPXs/4nRIpnKJ60yS0Hk5vCjWHmFuM2kUA= To: The IESG , netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> <20151019181719.GA81250@elstar.local> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56281F5A.8050208@cs.tcd.ie> Date: Thu, 22 Oct 2015 00:27:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151019181719.GA81250@elstar.local> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2015 23:27:43 -0000 Hiya, (Aside: I don't think I've seen a response to my points 1 and 3 but my mail client's a bit flakey at the 'mo so please re-tx if I missed something.) 19/10/15 19:17, Juergen Schoenwaelder wrote: > On Mon, Oct 19, 2015 at 01:36:15AM -0700, Stephen Farrell wrote: >> >> (2) The secdir review [1] calls out issues related to TLS-PSK >> and (I guess also) bare keys. I think it'd be good to be >> speific as to wheher or how those are to be supported here. If >> you are going to say those are supported, then I suspect some >> additional text is needed. Kent's answer to that (which was >> "see RFC7589" as I read it) doesn't quite do it here I think. >> that says that certificates must be supported (which is fine) >> but doesn't say that TLS-PSK or bare keys can or cannot be >> supported. >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html >> > > RFC 7589 only covers X.509 authentication and this was a deliberate > decision. I'm fine with that decision. The discuss is only about whether or not it's sufficiently well documented that you don't want folks doing bare keys. S. > Earlier I-Ds did include support for pre-shared keys but > this was taken out and the WG concensus was to write another NETCONF > over TLS with PSK document if the usage of pre-shared keys with > NETCONF gets more traction. > > /js > From nobody Wed Oct 21 17:34: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 101771B345A; Wed, 21 Oct 2015 17: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, 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 BfvVq77CGNiG; Wed, 21 Oct 2015 17:34:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965B31B3459; Wed, 21 Oct 2015 17:34:34 -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.306.13; Thu, 22 Oct 2015 00:34:14 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Thu, 22 Oct 2015 00:34:14 +0000 From: Kent Watsen To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHRCkk5+GfvZN93g0WK01hCV3RAd552ax0A Date: Thu, 22 Oct 2015 00:34:13 +0000 Message-ID: <8F4A49AE-1160-4685-B878-39A087496FDF@juniper.net> References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> In-Reply-To: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:Uw85BKVHM45aXc2tDSW9olnvK1zyRzJiIwrDWkD3SYzaVUs4p3YIA7GqjIMbEhzBaBgu39Gq0OEOuC2WTomxndIldICuBDnWbTCiAE6m2HvF4rwZfMPYNfj647P52nq/y0BIq5dC5ckGwDJtK1AMEQ==; 24:8G48utxFN2ce80j+g2BX+KWMSe2Q2Q7FzNzKw1izSEr3cuL7Ua3LYzcSMkgYFd8KsXXI+ucxKDaRW+1kpIAnXbcafA5med1O+sSbeC/ojY0=; 20:5+Cenh2ytNZnM/cerubImiRkjPuaWIttxH5dP4KBm4cP9scV1vo31V5Ia2tly6XPnKYHzma7hYUFjrm0/6+NuQ== 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)(2401047)(5005006)(520078)(8121501046)(3002001); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(43784003)(76104003)(199003)(189002)(5007970100001)(83506001)(64706001)(82746002)(10400500002)(189998001)(102836002)(122556002)(2950100001)(2900100001)(5008740100001)(5001960100002)(5002640100001)(40100003)(101416001)(19580395003)(230783001)(87936001)(46102003)(15975445007)(11100500001)(5004730100002)(83716003)(4001350100001)(105586002)(36756003)(106116001)(99286002)(106356001)(86362001)(92566002)(33656002)(66066001)(5001770100001)(97736004)(81156007)(54356999)(76176999)(50986999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 00:34:13.8920 (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-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2015 00:34:37 -0000 DQpIaSBTdGVwaGVuLA0KDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlldy4NCg0KPkkgaGF2 ZSB0aHJlZSBwb2ludHMgdG8gZGlzY3VzcywgSSB0aGluayB0aGVzZSBtYXkgYmUgZmFpcmx5DQo+ ZWFzeSB0byByZXNvbHZlLCBvciBtYXliZSBub3QsIGJ1dCBJJ2QgbGlrZSB0byBjaGF0IGFib3V0 ICdlbS4NCg0KT2theSwgZ3JlYXQuDQoNCg0KPigxKSBIVFRQIEF1dGg6IGlzIGl0IG9rIGZvciBh IGNsaWVudCB0byBzZW5kIGl0J3MgZS5nLiBiYXNpYw0KPmF1dGggY3JlZGVudGlhbCB0byBhbnkg b2YgdGhlIHNlcnZlcnMgdGhhdCB0aGUgY2xpZW50IGNhbg0KPnZhbGlkYXRlPyBJLmUuLCBpcyBh biBhZGRpdGlvbmFsIGxldmVsIG9mIHBpbm5pbmcgbmVlZGVkIGZvcg0KPnRoaXM/IFRoYXQgd291 bGQgYmUgYSBuZXcgZm9ybSBvZiBwaW5uaW5nIGFuZCBpcyBub3QgZGVmaW5lZA0KPmZvciBlaXRo ZXIgVExTIG9yIFNTSCBhZmFpay4gVGhhdCBjb3VsZCBhbHNvIGJlIGRvbmUgaW4NCj52YXJpb3Vz IHdheXMgYW5kIEknbSBub3Qgc3VyZSBpZiB0aG9zZSBtaWdodCBoYXZlDQo+aW50ZXJvcGVyYWJp bGl0eSBjb25zZXF1ZW5jZXMuIE9yIHBlcmhhcHMgaWYgbm90IGRvaW5nIHRoYXQsDQo+dGhpcyBk cmFmdCBzaG91bGQgc2F5IHNvbWV0aGluZyBhYm91dCBhIG5lZWQgZm9yIHN0cm9uZ2VyDQo+Y3Jl ZGVudGlhbHMgZXNwLiBmb3IgYmFzaWMgYXV0aC4gRGlkIHRoZSBXRyBjb25zaWRlciB0aGlzPw0K DQpJcyB0aGlzIGNvbW1lbnQgbmV3IHRvIGNhbGwgaG9tZSwgb3IgaXQgaXMgcmVhbGx5IGEgY29t bWVudCBvbiB0aGUgUkVTVENPTkYgZHJhZnQ/ICBTcGVjaWZpY2FsbHksIHBsZWFzZSBzZWUgdGhp cyBzZWN0aW9uOiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29u Zi1yZXN0Y29uZi0wOCNzZWN0aW9uLTIuNQ0KDQpBbnN3ZXJpbmcgeW91ciBxdWVzdGlvbnM6DQoN Cj4gaXMgaXQgb2sgZm9yIGEgY2xpZW50IHRvIHNlbmQgaXQncyBlLmcuIEJhc2ljIGF1dGggY3Jl ZGVudGlhbCB0byBhbnkgb2YgdGhlIHNlcnZlcnMgdGhhdCB0aGUgY2xpZW50IGNhbiB2YWxpZGF0 ZT8gDQoNClllcy4NCg0KPiBJLmUuLCBpcyBhbiBhZGRpdGlvbmFsIGxldmVsIG9mIHBpbm5pbmcg bmVlZGVkIGZvciB0aGlzPyANCg0KTm90IHRoYXQgSeKAmW0gYXdhcmUgb2YuDQoNCg0KPiBEaWQg dGhlIFdHIGNvbnNpZGVyIHRoaXM/DQoNCg0KTm8sIGJ1dCBLYXRobGVlbiBtYWRlIGEgZ29vZCBw b2ludCB0byByZWZlcmVuY2UgUkZDcyA3NjE1IGFuZCA3NjE2LCB3aGljaCBJIHdpbGwgZG8uICAg U3RpbGwsIEkgdGhpbmsgdGhpcyBjb21tZW50IGlzIG1vcmUgb24gdGhlIFJFU1RDT05GIGRyYWZ0 IHRoYW4gdGhpcyBvbmUuICBZZXM/DQoNCg0KDQoNCj4oMikgVGhlIHNlY2RpciByZXZpZXcgWzFd IGNhbGxzIG91dCBpc3N1ZXMgcmVsYXRlZCB0byBUTFMtUFNLDQo+YW5kIChJIGd1ZXNzIGFsc28p IGJhcmUga2V5cy4gSSB0aGluayBpdCdkIGJlIGdvb2QgdG8gYmUNCj5zcGVpZmljIGFzIHRvIHdo ZWhlciBvciBob3cgdGhvc2UgYXJlIHRvIGJlIHN1cHBvcnRlZCBoZXJlLiBJZg0KPnlvdSBhcmUg Z29pbmcgdG8gc2F5IHRob3NlIGFyZSBzdXBwb3J0ZWQsIHRoZW4gSSBzdXNwZWN0IHNvbWUNCj5h ZGRpdGlvbmFsIHRleHQgaXMgbmVlZGVkLiBLZW50J3MgYW5zd2VyIHRvIHRoYXQgKHdoaWNoIHdh cw0KPiJzZWUgUkZDNzU4OSIgYXMgSSByZWFkIGl0KSBkb2Vzbid0IHF1aXRlIGRvIGl0IGhlcmUg SSB0aGluay4NCj50aGF0IHNheXMgdGhhdCBjZXJ0aWZpY2F0ZXMgbXVzdCBiZSBzdXBwb3J0ZWQg KHdoaWNoIGlzIGZpbmUpIA0KPmJ1dCBkb2Vzbid0IHNheSB0aGF0IFRMUy1QU0sgb3IgYmFyZSBr ZXlzIGNhbiBvciBjYW5ub3QgYmUgDQo+c3VwcG9ydGVkLg0KPg0KPiAgIFsxXQ0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDYwODcuaHRt bA0KDQoNCkp1ZXJnZW4gbWVudGlvbmVkIHRoYXQgUFNLIHdhcyBkZWxpYmVyYXRlbHkgdGFrZW4g b3V0IG9mIHJmYzc1ODkgLSBhbmQgdGhpcyBkcmFmdCBoYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNl IHRvIGl0Lg0KDQpTZXBhcmF0ZWx5LCB5b3UganVzdCBub3cgd3JvdGUgdG8gSnVlcmdlbjogIkkn bSBmaW5lIHdpdGggdGhhdCBkZWNpc2lvbi4gVGhlIGRpc2N1c3MgaXMgb25seSBhYm91dCB3aGV0 aGVyIG9yIG5vdCBpdCdzIHN1ZmZpY2llbnRseSB3ZWxsIGRvY3VtZW50ZWQgdGhhdCB5b3UgZG9u J3Qgd2FudCBmb2xrcyBkb2luZyBiYXJlIGtleXMu4oCdICAgDQoNCldvdWxkIHRoYXQgYmUgaW4g dGhpcyBkcmFmdCwgb3Igc2hvdWxkIGl0IGJlIGluIFJSQzc1ODk/DQoNCg0KDQoNCj4oMykgQ29u c2lkZXIgem1hcC4gV2hlbiB0aGlzIGlzIGRlcGxveWVkLCB3aGF0J2xsIGJlIHRoZQ0KPmVmZmVj dCBvZiBzdXJ2ZXlzIHRoYXQgZmluZ2VycHJpbnQgYWxsIG9mIHRoZSBkZXZpY2VzIG9uIHRoZQ0K PnZpc2libGUgSW50ZXJuZXQgd2hvIGltcGxlbWVudCB0aGlzIHByb3RvY29sPyBEaWQgdGhlIFdH DQo+Y29uc2lkZXIgdGhhdD8gSSdtIG5vdCBzdXJlIG9mIHRoZSBpbXBhY3QsIGlmIGFueSwgYnV0 IGl0DQo+Y291bGQgYmUgZ29vZCBpZiB0aGVyZSdzIGEgd2F5IHRvIGhlbHAgZGVwbG95bWVudHMg ZW5kIHVwIGxlc3MNCj52dWxuZXJhYmxlIHRvIGZpbmdlcnByaW50aW5nIChhbmQgdGhlIGVuc3Vp bmcgZXhwb3N1cmUgdG8NCj51bnBhdGNoZWQgdnVsbnMpLg0KDQpUaGUgV0cgZGlkIG5vdCBkaXNj dXNzIHRoaXMuICANCg0KSSBrbm93IHRoYXQgeW91IG1lbnRpb24gem1hcCBieSBleGFtcGxlLCBi dXQgcmVhZGluZyBvbiBpdCBJIHNlZSB0aGF0IGlzIHNlbmRzIGEgU1lOIG1lc3NhZ2UsIGFuZCB0 ZXN0cyBpZiBhIFNZTi1BQ0sgaXMgcmV0dXJuZWQuICBJIG5ldmVyIGNvbXBsZXRlcyB0aGUgVENQ IGNvbm5lY3Rpb24gYW5kLCBpbiBmYWN0IHNlbmRzIGEgUlNULg0KDQpUaGlzIGNvbmNlcm4gc2Vl bXMgdG8gYmUgdHJ1ZSBmb3IgYW55IHByb3RvY29sLCBub3Qgc3BlY2lmaWMgdG8gY2FsbC1ob21l LiAgU3RpbGwsIEkgY291bGQgYWRkIHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0 aW9uIHNvbWV0aGluZyBsaWtlOg0KDQogIE5FVENPTkYvUkVTVENPTkYgY2xpZW50cyBoYXZpbmcg YSBvcGVuIHBvcnQgZm9yIGNhbGwgaG9tZQ0KICBzaG91bGQgYmUgYXdhcmUgdGhhdCBuZXR3b3Jr IHNjYW5uaW5nIHRvb2xzIGFyZSBtYW55IHRpbWVzDQogIHVzZWQgdG8gZmluZ2VycHJpbnQgaG9z dHMgd2l0aCB0aGUgaG9wZSBvZiBmaW5kaW5nIHVucGF0Y2hlZA0KICB2dWxuZXJhYmlsaXRpZXMu ICBFZmZvcnQgc2hvdWxkIGJlIG1hZGUgdG8gbGltaXQgZXhwb3N1cmUNCiAgb25seSB0byBuZWVk aW5nIHRvIGFjY2VzcyB0aGUgTkVUQ09ORi9SRVNUQ09ORiBjbGllbnQuDQoNCldoYXQgZG8geW91 IHRoaW5rPw0KDQoNCg0KPi0gT0NTUDogYW55IGlzc3VlIHRoZXJlPyBpcyBpdCBtYW5kYXRvcnkg dG8gdXNlIGluIGFueSBjYXNlDQo+Zm9yIFRMUz8NCg0KQWdhaW4sIHRoaXMgZHJhZnQgaGFzIGEg bm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gUkZDIDc1ODksIHdoaWNoIHNheXM6DQoNCiAgIEJvdGgg cGVlcnMgTVVTVCB1c2UgWC41MDkgY2VydGlmaWNhdGUgcGF0aCB2YWxpZGF0aW9uIFtSRkM1Mjgw XSB0bw0KICAgdmVyaWZ5IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIGNlcnRpZmljYXRlIHByZXNlbnRl ZCBieSB0aGUgcGVlci4NCg0KDQpBbmQgUkZDNTI4MCBkZWZpbmVzIGNlcnRpZmljYXRlIHBhdGgg dmFsaWRhdGlvbiBhcyBpbmNsdWRpbmcgcmV2b2NhdGlvbiBjaGVja2luZy4gIFNvIGJvdGggQ1JM IGFuZCBPU0NQIGFyZSBhdmFpbGFibGUsIGFuZCB3b3VsZCBiZSB1cCB0byB0aGUgQ0EgdG8gc3Bl Y2lmeSBDUkwgZGlzdHJpYnV0aW9uIHBvaW50cyBvciBhdXRob3JpdHkgaW5mbyBhY2Nlc3MgaW4g dGhlaXIgY2VydGlmaWNhdGVzLg0KDQoNCg0KVGhhbmtzIGFnYWluLA0KS2VudA0KDQoNCg== From nobody Wed Oct 21 18:08: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 97E2C1B34E0; Wed, 21 Oct 2015 18:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_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 hOG9xmaiFtfM; Wed, 21 Oct 2015 18:08:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D351B34DF; Wed, 21 Oct 2015 18:08:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AED79BE53; Thu, 22 Oct 2015 02:08:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5F-igNv2lSa; Thu, 22 Oct 2015 02:08:00 +0100 (IST) Received: from [10.87.48.91] (unknown [86.42.31.61]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D35BBE51; Thu, 22 Oct 2015 02:07:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445476079; bh=llUfYrhhK2YujUTgKU5GJl45ZTXqba8e0qUQMI9Uecc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=UFIrirKRuiVe4f2E7yO9dIohOPcDg2kf+UG78F7fyLZynQIIEKAI/71a3Msi8r0JQ 41oJwGWbi1AbMwKImHNxNg4kQZMZvUVwPmB+jccz+KX6zngPy+cBxwPqu4Bt5HVj7G 9DVYcZvJ6Bsns+ZMyxUIn8WJKpraDqgJf26+H6Eg= To: Kent Watsen , The IESG References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> <8F4A49AE-1160-4685-B878-39A087496FDF@juniper.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <562836EE.40904@cs.tcd.ie> Date: Thu, 22 Oct 2015 02:07:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8F4A49AE-1160-4685-B878-39A087496FDF@juniper.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2015 01:08:06 -0000 Hiya, On 22/10/15 01:34, Kent Watsen wrote: > > Hi Stephen, > > > > Thank you for your review. > >> I have three points to discuss, I think these may be fairly easy to >> resolve, or maybe not, but I'd like to chat about 'em. > > Okay, great. > > >> (1) HTTP Auth: is it ok for a client to send it's e.g. basic auth >> credential to any of the servers that the client can validate? >> I.e., is an additional level of pinning needed for this? That would >> be a new form of pinning and is not defined for either TLS or SSH >> afaik. That could also be done in various ways and I'm not sure if >> those might have interoperability consequences. Or perhaps if not >> doing that, this draft should say something about a need for >> stronger credentials esp. for basic auth. Did the WG consider >> this? > > Is this comment new to call home, or it is really a comment on the > RESTCONF draft? Specifically, please see this section: > https://tools.ietf.org/html/draft-ietf-netconf-restconf-08#section-2.5 I'd say it perhaps affects both. But could arguably be a broader issue. See below. > > Answering your questions: > >> is it ok for a client to send it's e.g. Basic auth credential to >> any of the servers that the client can validate? > > Yes. Ick - at least, that's ickky if only the basic-auth realm is used to select the password to send out (effectively in clear). Both basic and digest I think talk about a user selecting the password to input based on the realm, but here you're automating that based on a packet received over the network. What ensures a client here never sends the password to an incorrect server? Say a client has two servers (A and B) that can call-home to the client, and A cheats on B by using B's realm (which is not considered a strong secret) in A's WWW-Authenticate? Now if that is a real issue, I think we could argue that basic and digest, unmodified, are just not safe here. I'm not sure what modification could usefully be done if one is needed other than maybe pinning the password to the server identity. Having just now re-read RFC7617 I think we may need to tackle that issue somehow as 7617 envisages the user not typing the password as the control here. (Or we could short-circuit this is the wg were willing to give up on use of crappy http auth schemes like basic and only allow better things - do you really really need this so badly as to put these devices at risk?) > >> I.e., is an additional level of pinning needed for this? > > Not that I’m aware of. We may want to chat about that more. > > >> Did the WG consider this? > > > No, but Kathleen made a good point to reference RFCs 7615 and 7616, > which I will do. Still, I think this comment is more on the > RESTCONF draft than this one. Yes? Sorry no, I don't think so. > > > > >> (2) The secdir review [1] calls out issues related to TLS-PSK and >> (I guess also) bare keys. I think it'd be good to be speific as to >> wheher or how those are to be supported here. If you are going to >> say those are supported, then I suspect some additional text is >> needed. Kent's answer to that (which was "see RFC7589" as I read >> it) doesn't quite do it here I think. that says that certificates >> must be supported (which is fine) but doesn't say that TLS-PSK or >> bare keys can or cannot be supported. >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html > > > Juergen mentioned that PSK was deliberately taken out of rfc7589 - > and this draft has a normative reference to it. > > Separately, you just now wrote to Juergen: "I'm fine with that > decision. The discuss is only about whether or not it's sufficiently > well documented that you don't want folks doing bare keys.” > > Would that be in this draft, or should it be in RRC7589? Show me where it says "don't do bare keys" and I'll answer you;-) I think it perhaps needs to be here. > > > > >> (3) Consider zmap. When this is deployed, what'll be the effect of >> surveys that fingerprint all of the devices on the visible Internet >> who implement this protocol? Did the WG consider that? I'm not sure >> of the impact, if any, but it could be good if there's a way to >> help deployments end up less vulnerable to fingerprinting (and the >> ensuing exposure to unpatched vulns). > > The WG did not discuss this. > > I know that you mention zmap by example, but reading on it I see that > is sends a SYN message, and tests if a SYN-ACK is returned. I never > completes the TCP connection and, in fact sends a RST. zmap has been used for all sorts of more complex handshakes. > > This concern seems to be true for any protocol, not specific to > call-home. I think a role-change like this makes it far more notable. > Still, I could add to the Security Considerations section > something like: > > NETCONF/RESTCONF clients having a open port for call home should be > aware that network scanning tools are many times used to fingerprint > hosts with the hope of finding unpatched vulnerabilities. Effort > should be made to limit exposure only to needing to access the > NETCONF/RESTCONF client. > > What do you think? But what efforts can one make and what is the impact of not making those (for this protocol). The role-change here is a minor transport change but doing that for publicly reachable hosts has a lot of consequences. > > > >> - OCSP: any issue there? is it mandatory to use in any case for >> TLS? > > Again, this draft has a normative references to RFC 7589, which > says: > > Both peers MUST use X.509 certificate path validation [RFC5280] to > verify the integrity of the certificate presented by the peer. > > > And RFC5280 defines certificate path validation as including > revocation checking. No. Revocation checking is optional in 5280. (Sorry;-) > So both CRL and OSCP are available, and would > be up to the CA to specify CRL distribution points or authority info > access in their certificates. If you want clients here to support status checking I think you need to say that or reference something that says that. Cheers, S. > > > > Thanks again, Kent > > From nobody Wed Oct 21 23:10: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 892D31B30CD; Wed, 21 Oct 2015 23:10:03 -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 2323SHkBtZ0I; Wed, 21 Oct 2015 23:10:01 -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 052B61B3770; Wed, 21 Oct 2015 23:09:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A44437DE; Thu, 22 Oct 2015 08:09:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WYCS_9CsEAki; Thu, 22 Oct 2015 08:09:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 22 Oct 2015 08:09:56 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7469D2004E; Thu, 22 Oct 2015 08:09:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RsMCCzd2PyuU; Thu, 22 Oct 2015 08:09:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5491C2003B; Thu, 22 Oct 2015 08:09:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B8A0C386133F; Thu, 22 Oct 2015 08:09:50 +0200 (CEST) Date: Thu, 22 Oct 2015 08:09:49 +0200 From: Juergen Schoenwaelder To: Stephen Farrell Message-ID: <20151022060946.GA21176@elstar.local> Mail-Followup-To: Stephen Farrell , The IESG , netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> <20151019181719.GA81250@elstar.local> <56281F5A.8050208@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56281F5A.8050208@cs.tcd.ie> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org, The IESG , draft-ietf-netconf-call-home@ietf.org, netconf-chairs@ietf.org Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and 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: Thu, 22 Oct 2015 06:10:03 -0000 On Thu, Oct 22, 2015 at 12:27:22AM +0100, Stephen Farrell wrote: > > Hiya, > > (Aside: I don't think I've seen a response to my points 1 and > 3 but my mail client's a bit flakey at the 'mo so please re-tx > if I missed something.) > 19/10/15 19:17, Juergen Schoenwaelder wrote: > > On Mon, Oct 19, 2015 at 01:36:15AM -0700, Stephen Farrell wrote: > >> > >> (2) The secdir review [1] calls out issues related to TLS-PSK > >> and (I guess also) bare keys. I think it'd be good to be > >> speific as to wheher or how those are to be supported here. If > >> you are going to say those are supported, then I suspect some > >> additional text is needed. Kent's answer to that (which was > >> "see RFC7589" as I read it) doesn't quite do it here I think. > >> that says that certificates must be supported (which is fine) > >> but doesn't say that TLS-PSK or bare keys can or cannot be > >> supported. > >> > >> [1] > >> https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html > >> > > > > RFC 7589 only covers X.509 authentication and this was a deliberate > > decision. > > I'm fine with that decision. The discuss is only about whether or > not it's sufficiently well documented that you don't want folks > doing bare keys. > I think all we can do is to mention that RFC7589 supports X.509 authentication only in case that is not clear enough. I am not sure we have strong technical reasons to rule out other mechanisms. SSH supports a number of differnt user authentication mechanisms and we did not restrict them here. /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 Oct 22 01:14: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 73F351B2F2D for ; Thu, 22 Oct 2015 01:14:48 -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 Rh3ATKYxrM7g for ; Thu, 22 Oct 2015 01:14:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144491B2F24 for ; Thu, 22 Oct 2015 01:14:45 -0700 (PDT) Received: from BL2PR05MB065.namprd05.prod.outlook.com (10.255.232.16) by BL2PR05MB067.namprd05.prod.outlook.com (10.255.232.22) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 08:14:27 +0000 Received: from BL2PR05MB065.namprd05.prod.outlook.com ([169.254.4.206]) by BL2PR05MB065.namprd05.prod.outlook.com ([169.254.4.206]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 08:14:27 +0000 From: "Lisa (Yi) Huang" To: "netconf@ietf.org" Thread-Topic: restconf data namespace Thread-Index: AQHRDKGqKmgQf+uEG0iXpaJIWjcgvA== Date: Thu, 22 Oct 2015 08:14: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.5.5.150821 authentication-results: spf=none (sender IP is ) smtp.mailfrom=lyihuang@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-exchange-diagnostics: 1; BL2PR05MB067; 5:23Yxpxrdjd10lsA8NtUxg7E+Gege8NaRPSpCsfsSdqCnDr6HWCLSkQUxw0Lcprpjvk33EBcksw0wVD5LonaxKYD/3zMI7GfyWAlOvtggct/2wOSFnCWI8XdwoL7BnuOAxz40ryosuUtGLkfOzwoczw==; 24:Xtj+AEf1nuZywdSgUltlh6k7+ckK8B+Vdok6E4yTx9gg0spbf4APKEnsh07G8ZXzc6/67g0z9TcOhZUw8ujFzjBQi3ptQlWzdqmehKFWQw4=; 20:l5oZ6fDnT5ZIqCek0+RA6z/GKnhvcNRvJbxbryUznO0MSrDkm9ZhJkXIkMXij19z9MGfVsD5FUlWWXJ3SMhACw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BL2PR05MB067; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(102215026); SRVR:BL2PR05MB067; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB067; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(164054003)(15395725005)(16236675004)(92566002)(5004730100002)(5007970100001)(11100500001)(10400500002)(50986999)(46102003)(54356999)(15975445007)(102836002)(189998001)(107886002)(110136002)(66066001)(64706001)(450100001)(106116001)(106356001)(36756003)(40100003)(122556002)(5002640100001)(19617315012)(101416001)(2501003)(5001960100002)(99286002)(105586002)(83506001)(19580395003)(86362001)(87936001)(4001350100001)(81156007)(97736004)(2351001)(229853001)(2900100001)(5001920100001)(5008740100001)(94096001)(133083001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB067; H:BL2PR05MB065.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D24DE8F1C584lyihuangjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 08:14:26.9065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB067 Archived-At: Subject: [Netconf] restconf data namespace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2015 08:14:48 -0000 --_000_D24DE8F1C584lyihuangjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi netconf experts, I have some questions regarding namespace specified in RESTCONF Protocol dr= aft-ietf-netconf-restconf-08. For this notification example: 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; } } } In RFC6020 2008-07-08T00:01:00Z fault Ethernet0 major In restconf I-D data: data: 2013-12-21T00:01:00Z data: data: fault data: data: Ethernet0 data: data: major data: data: 1. The name space changed from netconf:notification to yang:ietf-restconf. = Here are my questions: What is the rule for the namespace change? Json data: data: { data: "ietf-restconf:notification": { data: "event-time": "2013-12-21T00:01:00Z", data: "example-mod:event": { data: "event-class": "fault", data: "reporting-entity": { "card": "Ethernet0" }, data: "severity": "major" data: } data: } data: } 2. How does example-mod namespace in json map to http://example.com/event/1= .0 in xml? Section D.3.6 explained how filter looks like. Question and comments follow= s: // filter =3D /event/event-class=3D'fault' GET /mystreams/NETCONF?filter=3D%2Fevent%2Fevent-class%3D'fault' // Note: the module name is used as prefix. // filter =3D (/example-mod:event1/name=3D'joe' and // /example-mod:event1/status=3D'online') GET /mystreams/NETCONF? filter=3D(%2Fexample-mod%3Aevent1%2Fname%3D'joe'%20and %20%2Fexample-mod%3Aevent1%2Fstatus%3D'online') 3. The url /mystreams/NETCONF is not consistent with /streams/NETCONF used = for stream subscription. 4. For the first filter without namespace, what events will be streamed if = the two yang modules have the same notification name (different data ) in t= he server? Thanks, Lisa --_000_D24DE8F1C584lyihuangjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <781D52CF6A1D7B45B856D30B9A66A26A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi netcon= f experts,

I have so= me questions regarding namespace specified in RESTCONF Protocol draft-ietf-netconf-restconf-08. 

For this notification = example:
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; }
       }
     }

In RFC6020 
<notification
       xmlns=3D"ur=
n:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2008-07-08T00:01:00Z</eventTime>
       <event xmlns=3D"http://example.com/event">
         <event-class>fault</event-class>
         <reporting-entity>
           <card>Ethernet0</card>
         </reporting-entity>
         <severity>major</severity>
       </event>
     </notification>

In restconf I-D
<=
pre class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; page-br=
eak-before: always;">data: =
<notification
   data:    xmlns=3D&qu=
ot;urn:ietf:params:xml:ns:yang:ietf-restconf">
   data:    <event-time>2013-12-21T00:01:00Z</event-time>
   data:    <event xmlns=3D"http://example.com/event/1.0">
   data:       <event-class>fault</event-class>
   data:       <reporting-entity>
   data:           <card>Ethernet0</card>
   data:       </reporting-entity>
   data:       <severity>major</severity>
   data:     </event>
   data: </notification>

1. The name space changed from netconf:notification to yang:ietf-rest=
conf. Here are my questions: What is the rule for the namespace change?

Json data:
exam=
ple-mod:event": {
   data:       "event-class": "fault",
   data:       "reporting-entity": { "card": "Ethe=
rnet0" },
   data:       "severity": "major"
   data:     }
   data:   }
   data: }

2. How does example-mod namespace in json map to http://example.com/event/1.0 in xml?

Section D.3.6 explained how filter looks like. Question and comm=
ents follows:

               // filter =3D /event/event-class=3D'fault'

      GET /mystreams/NETCONF?filter=3D%2Fevent%2Fevent-class%3D'fault=
'


      // Note: the module name is used as prefix.
      // filter =3D (/example-mod:event1/name=3D'joe' and
      //           /example-mod:event1/status=3D'online')
      GET /mystreams/NETCONF?
        filter=3D(%2Fexample-mod%3Aevent1%2Fname%3D'joe'%20and
                %20%2Fexample-mod%3Aevent1%2Fstatus%3D'online')







3. The url /mystreams/NETCONF is not consistent with /streams/NETC=
ONF used for stream subscription. 


4. For the first filter without namespace, what events will be str=
eamed if the two yang modules have the same notification name (different da=
ta ) in the server?





Thanks,


Lisa
--_000_D24DE8F1C584lyihuangjunipernet_-- From nobody Thu Oct 22 01:48:06 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 21D7B1A00C0 for ; Thu, 22 Oct 2015 01:48:04 -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 v9DQoKYlVHl6 for ; Thu, 22 Oct 2015 01:48:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C037D1A00BB for ; Thu, 22 Oct 2015 01:48:01 -0700 (PDT) Received: from localhost (unknown [173.38.220.37]) by mail.tail-f.com (Postfix) with ESMTPSA id 9563E1AE046C; Thu, 22 Oct 2015 10:47:59 +0200 (CEST) Date: Thu, 22 Oct 2015 10:47:58 +0200 (CEST) Message-Id: <20151022.104758.216186742504224313.mbj@tail-f.com> To: lyihuang@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] restconf data namespace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2015 08:48:04 -0000 Hi, "Lisa (Yi) Huang" wrote: > Hi netconf experts, > > I have some questions regarding namespace specified in RESTCONF > Protocol draft-ietf-netconf-restconf-08. > > For this notification example: > > 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; } > } > } > > > In RFC6020 > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2008-07-08T00:01:00Z > > fault > > Ethernet0 > > major > > > > > In restconf I-D > > data: data: xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf"> > data: 2013-12-21T00:01:00Z > data: > data: fault > data: > data: Ethernet0 > data: > data: major > data: > data: > > > 1. The name space changed from netconf:notification to > yang:ietf-restconf. Here are my questions: What is the rule for the > namespace change? The element "notification" in the namespace "urn:ietf:params:xml:ns:netconf:notification:1.0" is used in NETCONF to send a notification. The element "notification" in the namespace "urn:ietf:params:xml:ns:yang:ietf-restconf" is used in RESTCONF to send a notification. These are simply protocol-specific wrappers. > Json data: > > data: { > data: "ietf-restconf:notification": { > data: "event-time": "2013-12-21T00:01:00Z", > data: "example-mod:event": { > data: "event-class": "fault", > data: "reporting-entity": { "card": "Ethernet0" }, > data: "severity": "major" > data: } > data: } > data: } > > > 2. How does example-mod namespace in json map to > http://example.com/event/1.0 in xml? "example-mod" is the name of the module that defines the xml namespace "http://example.com/event/1.0". The JSON mapping uses the module name instead of the namespace, see draft-ietf-netmod-yang-json. > Section D.3.6 explained how filter looks like. Question and comments > follows: > > > // filter = /event/event-class='fault' > > GET /mystreams/NETCONF?filter=%2Fevent%2Fevent-class%3D'fault' > > > // Note: the module name is used as prefix. > // filter = (/example-mod:event1/name='joe' and > // /example-mod:event1/status='online') > GET /mystreams/NETCONF? > filter=(%2Fexample-mod%3Aevent1%2Fname%3D'joe'%20and > %20%2Fexample-mod%3Aevent1%2Fstatus%3D'online') > > > > 3. The url /mystreams/NETCONF is not consistent with /streams/NETCONF > used for stream subscription. Ok, I changed the examples to make them consistent. But note that the "/streams/NETCONF" is just an example. A server is free to use any location for the streams. The client learns where the stream is found by looking at the "location" leaf for the stream. > 4. For the first filter without namespace, what events will be > streamed if the two yang modules have the same notification name > (different data ) in the server? All events that match the filter are streamed. So in your example, events from both modules will be streamed. /martin From nobody Thu Oct 22 04:11: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 3E7381A1B5B; Thu, 22 Oct 2015 04:11:20 -0700 (PDT) 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 dS0ZGlbOvhm9; Thu, 22 Oct 2015 04:11:18 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1E71A1B5C; Thu, 22 Oct 2015 04:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1038; q=dns/txt; s=iport; t=1445512278; x=1446721878; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=X8ioFKkwo9gPNL3+lVJ/VpRGLgm6TmvYixwzSyHtsjw=; b=b3op/M5/AxSWfaMendH2qyXd54/+L4kn+FDUAaV/AI44eF3Bz78OqDWU E79C9eYc6eLy69W46PB9a1dDmdey40tadPEkpkxmcazO2Oqio5Acis8DF 0pF3cfuUL9A6WLl36L+D5iGLDK1+9p/iyPcr8HxRyobKSgKCe+GXMJQ0o s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOAQAJxChW/xbLJq1evnGEIQENgVmDRoJXAoF/FAEBAQEBAQGBCoQvAQEEIw8BBUABEAsOCgICBRYLAgIJAwIBAgFFBgEMCAEBiCyxWpMMAQEBAQEBAQEBAQEBAQEBAQEBG4EihVWEfoRCSweCaYFFAQSWK40egViHQI8eg3AfAQFCghEdFoFBPIZ3AQEB X-IronPort-AV: E=Sophos;i="5.20,181,1444694400"; d="scan'208";a="612331577" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 22 Oct 2015 11:11:15 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9MBBFf5012247; Thu, 22 Oct 2015 11:11:15 GMT To: Kent Watsen , Ben Campbell , Juergen Schoenwaelder References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> From: Benoit Claise Message-ID: <5628C43F.1030304@cisco.com> Date: Thu, 22 Oct 2015 13:10:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , Barry Leiba , Netconf , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2015 11:11:20 -0000 On 10/21/2015 10:18 PM, Kent Watsen wrote: > Hi Ben, > > Thank you for your review. > > > Regarding your original comments: > > >> If the client MAY be configured to listen on a non-standard port, doesn’t >> that imply that the server MUST be _capable_ of being configured to >> connect to a non-standard port? > This is correct and what draft-ietf-netconf-server-model-08 allows. Were you thinking that there needs to be a change in this draft? > > >> I'm curious why people felt it necessary to reverse the usual TLS or SSH >> client and server roles. Did the working group consider having the >> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the > As Juergen noted, this allows that all existing authentication to continue working. Also, since SSH is not a symmetric protocol, it’s actually important for the client to be the SSH-client so it can open/close SSH channels (e.g., to start the “netconf” subsystem). Ben, do you feel we need to mention it in the draft? Regards, Benoit From nobody Thu Oct 22 05:21: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 B0C6E1B3671; Thu, 22 Oct 2015 05:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQX3rVSRh3be; Thu, 22 Oct 2015 05:21:37 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 DDE001B366E; Thu, 22 Oct 2015 05:21:36 -0700 (PDT) Received: by vkgy127 with SMTP id y127so45610272vkg.0; Thu, 22 Oct 2015 05:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=LVivhGzdmuSD56MfvKfG/hLa+OibqzINV4G5EB6coBs=; b=stchTlPoYGYSO+9xGjEjCls+IgzzSWX1XrtI32nOpH2K4AzgvDonJ18IViBvsMpe3r kxlkJoZsxDdeLlY8clYVtea5ljOdC478AsyfL1HMshKPWL73t7gv0ih4Hz5fTmYQAi8U vBXXNPv7qNKyXugJiCyf5nX08iKkptYZNwosrNAPSp5Uk9XJ2k57qyoK0vo+reBgG1D1 dN52j/87ZlfsfMrC+hsaLarS4yVfdS3EIDqa3rveds9aNFvkuouIysoe+g3vm7k7oAcH nL56cyjIpISZxUEHkhA5JaKyFjQLuASmA6SoMGTvrG8kPOytrZK8rMDWVEnibIIoj5vW EmEQ== MIME-Version: 1.0 X-Received: by 10.31.9.81 with SMTP id 78mr8244926vkj.10.1445516496028; Thu, 22 Oct 2015 05:21:36 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.31.54.65 with HTTP; Thu, 22 Oct 2015 05:21:35 -0700 (PDT) In-Reply-To: References: <20151020184735.19913.19977.idtracker@ietfa.amsl.com> Date: Thu, 22 Oct 2015 08:21:35 -0400 X-Google-Sender-Auth: nuPONwtb1XGyFBsk09FHh60R37w Message-ID: From: Barry Leiba To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netconf@ietf.org" , The IESG , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Barry Leiba's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2015 12:21:38 -0000 Hi, Kent, and thanks for the response. First, note that all my comments are non-blocking review comments, which you should consider no differently to any other last-call comments. >>It's a finnicky point, but I think it's an important one: You list two >>methods for validation: (1) cert path validation, and (2) comparing to a >>pinned value. Is it (A) acceptable for the validation to be done by >>other methods as well as those two? Or is it (B) required that one of >>those two be used, but either is acceptable? > > It is A, but these two are by far the most common. Good; then, as you say, leave the text as it is. >> Once the SSH or TLS connection is established, the NETCONF/ >> RESTCONF client MUST immediately start using either the NETCONF- >> client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] >> protocol. >> >>What *else* might the client do, which merits a MUST here? I think all >>you should say here is, "Once the SSH or TLS connection is established, >>the NETCONF/RESCONF client starts using either [...the protocols...]." > > A misbehaving client might try to start another protocol, or send some > other kind of data, or maybe not do it =E2=80=9Cimmediately=E2=80=9D. T= hat said, I=E2=80=99m > okay removing the "MUST immediately=E2=80=9D if you think it improves the= text. Well, as I say, it's not an important point, so please do as you think best. I personally think it's better as I suggest above, and it's pretty far-fetched to think that a NETCONF client would suddenly start talking RESCONF or FTP or some such. But just consider that as input, and no need to discuss it further.. >> Assuming the use of the IANA-assigned ports, the >> NETCONF-client protocol is started when the connection is >> accepted on either port PORT-X or PORT-Y and the RESTCONF-client >> protocol is started when the connection is accepted on port PORT- >> Z. >> >>But no: the (NETCONF/RESCONF)-client protocol is NOT started when the >>connection is accepted (that was in C2), but when the SSH/TLS >>connection/session is established. Which you already said in the >>previous sentence, and C1 already said what ports the client listens on. >>Why is this sentence even here? Why not just remove it? > > I think you=E2=80=99re saying two things. Yes. > 1. The "is started when the connection is accepted=E2=80=9D is inaccurate= , in that > it isn=E2=80=99t really started then. Perhaps =E2=80=9Cis used when the = connection is > accepted=E2=80=9D would be better? Not really. "...is started after the TLS/SSH connection is established" seems to be the correct thing. But that's already said in the first sentence, which is why... > 2. The sentence may not be needed at all. Yes. > I think that it is needed in that it clarifies the expected behavior. For > instance, we wouldn=E2=80=99t want a client that is suppose to start NETC= ONF > to accidentally start RESTCONF. Makes sense, or do you still feel > that the sentence should be removed? As I noted above, I think that's a pretty far-fetched scenario. You're basically saying "a NETCONF client needs to behave as a NETCONF client, and not as something else." If you really think that needs to be said, go ahead and say it (as I said, these are just comments). Maybe it'd be better to say that up in the front, in a summary of how this works: the NETCONF/RESCONF server opens a TCP connection to the NETCONF/RESCONF client, which accepts the connection, secures the connection with SSH or TLS, and then behaves as a normal NETCONF/RESCONF client afterward. Do you really think there's a danger of anyone misunderstanding that down here? (And, again, no need to answer that to me: at this point just do as you think best, and thanks for considering my comments.) Barry From nobody Thu Oct 22 08:48: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 2BBFA1B38F6 for ; Thu, 22 Oct 2015 08:48:56 -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 TZHbUxiGoUGM for ; Thu, 22 Oct 2015 08:48:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BB0F1A1BC3 for ; Thu, 22 Oct 2015 08:48:43 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.306.13; Thu, 22 Oct 2015 15:48:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Thu, 22 Oct 2015 15:48:38 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-04.txt Thread-Index: AQHRCrcD2/9CEMGu5UytSU77PofB6Z5zFwMAgARSugA= Date: Thu, 22 Oct 2015 15:48:37 +0000 Message-ID: References: <20151019214151.16129.3388.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/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:uBkST5tZn9K0AMWu5UMbIPV33vF8cJ+LR91QxKmAkiaFHTjcGC8gd2jzqpXInfWI2UOFN7EqDGB3xO4kCSquCuVeFutAZ5YM09Su0Rq4xs0ddp5X/MJlSwHbytUZq/zBM2zklYjFCMYtElTjqDbJrQ==; 24:UisQeld7wnIglRGKiTZUVxwdaTv/IhVRMvZ2FTOpLvWxFfgY5A9CnkldJMRYbGUOwfEe+sG8bJCfdZDU/xdyX2x3XCXF0SujUzxncTUE1DI=; 20:MpNefPv8xPlgI2znInGQLW7uf613nCslX3dKNyzIkQiuxSe0VvQKlVTDG90W6W09x43yDHQi9jUmz2Vx1asUxg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(102215026); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(54534003)(199003)(189002)(377454003)(377424004)(164054003)(5007970100001)(76176999)(11100500001)(36756003)(33656002)(450100001)(19580395003)(110136002)(4001350100001)(66066001)(189998001)(2950100001)(2900100001)(54356999)(81156007)(97736004)(107886002)(64706001)(4001150100001)(19580405001)(2501003)(5004730100002)(5002640100001)(5001960100002)(102836002)(83716003)(86362001)(15975445007)(106356001)(105586002)(50986999)(106116001)(40100003)(87936001)(230783001)(99286002)(82746002)(2351001)(101416001)(122556002)(46102003)(10400500002)(83506001)(5008740100001)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 15:48:37.9961 (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-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 15:48:56 -0000 DQpJIGp1c3Qgbm90aWNlZCBhIG1pc3Rha2UgaW4gZm91ciBleGFtcGxlcyBpbiB0aGUgemVybyB0 b3VjaCBkcmFmdC4NCg0KSW4gZXhhbXBsZXMgNi4yLjEgdGhyb3VnaCA2LjIuNCwgdGhlIHRvcC1s ZXZlbCBub2RlIHJldHVybmVkIHNob3VsZCBiZSA8ZGV2aWNlIHhtbG5zPScuLi7igJk+ICAobm90 IDxkZXZpY2VzIHhtbG5zPScuLi7igJk+KS4NCg0KSeKAmXZlIGFscmVhZHkgbWFkZSB0aGlzIGNo YW5nZSBsb2NhbGx5IGFuZCB0aHVzIGl0IHdpbGwgY29ycmVjdGVkIGJlIGluIHRoZSBuZXh0IHVw ZGF0ZS4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQoNCg0KT24gMTAvMTkvMTUsIDU6NDcgUE0s ICJOZXRjb25mIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiIgPG5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj4NCj5IZXJl J3MgdGhlIGNoYW5nZSBsb2cgZm9yIHRoaXMgdXBkYXRlOg0KPg0KPiAgIG8gIE1ham9yIHVwZGF0 ZSBmb3JtYWxseSBpbnRyb2R1Y2luZyB1bnNpZ25lZCBkYXRhIGFuZCBzdXBwb3J0IGZvcg0KPiAg ICAgIEludGVybmV0LWJhc2VkIHJlZGlyZWN0IHNlcnZlcnMuICBUaGUgcHJpdmFjeSBpc3N1ZSBy YWlzZWQgZHVyaW5nDQo+ICAgICAgSUVURiA5My4NCj4NCj4gICBvICBBZGRlZCBtYW55IHRlcm1z IHRvIFRlcm1pbm9sb2d5IHNlY3Rpb24uDQo+DQo+ICAgbyAgQWRkZWQgYWxsIG5ldyAiR3VpZGlu ZyBQcmluY2lwbGVzIiBzZWN0aW9uLg0KPg0KPiAgIG8gIEFkZGVkIGFsbCBuZXcgIlNvdXJjZXMg Zm9yIEJvb3RzdHJhcHBpbmcgRGF0YSIgc2VjdGlvbi4NCj4NCj4gICBvICBSZXdyb3RlIHRoZSAi SW50ZXJhY3Rpb25zIiBzZWN0aW9uIGFuZCByZW5hbWVkIGl0ICJXb3JrZmxvdw0KPiAgICAgIE92 ZXJ2aWV3Ii4NCj4NCj4NCj4NCj5EcmFmdCBkcmFmdCBpcyBsb29raW5nIGNsb3NlIHRvIGRvbmUu ICBUaGUgb25seSBtYWpvciBvdXRzdGFuZGluZyBpc3N1ZQ0KPmN1cnJlbnRseSBpcyBuZWVkaW5n IHRoZSBkZWZpbmUgYSBzcGVjaWZpYyBkYXRhLXNpZ25pbmcgYWxnb3JpdGhtLg0KPg0KPkNoZWVy cywNCj5LZW50DQo+DQo+DQo+T24gMTAvMTkvMTUsIDU6NDEgUE0sICJpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciDQo+PGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQo+DQo+Pg0KPj5B IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMNCj4+ZGlyZWN0b3JpZXMuDQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m IHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gV29ya2luZyBHcm91cCBvZg0KPj50aGUgSUVURi4N Cj4+DQo+PiAgICAgICAgVGl0bGUgICAgICAgICAgIDogWmVybyBUb3VjaCBQcm92aXNpb25pbmcg Zm9yIE5FVENPTkYgQ2FsbCBIb21lDQo+PiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VudCBX YXRzZW4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBKb2UgQ2xhcmtlDQo+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgTWlrYWVsIEFicmFoYW1zc29uDQo+PglGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA0LnR4dA0KPj4JUGFnZXMgICAgICAgICAg IDogNTINCj4+CURhdGUgICAgICAgICAgICA6IDIwMTUtMTAtMTkNCj4+DQo+PkFic3RyYWN0Og0K Pj4gICBUaGlzIGRyYWZ0IHByZXNlbnRzIGEgdGVjaG5pcXVlIGZvciBlc3RhYmxpc2hpbmcgYSBz ZWN1cmUgTkVUQ09ORiBvcg0KPj4gICBSRVNUQ09ORiBjb25uZWN0aW9uIGJldHdlZW4gYSBuZXds eSBkZXBsb3llZCBkZXZpY2UsIGNvbmZpZ3VyZWQgd2l0aA0KPj4gICBqdXN0IGl0cyBmYWN0b3J5 IGRlZmF1bHQgc2V0dGluZ3MsIGFuZCBpdHMgcmlnaHRmdWwgb3duZXIncyBuZXR3b3JrDQo+PiAg IG1hbmFnZW1lbnQgc3lzdGVtIChOTVMpLg0KPj4NCj4+DQo+PlRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLw0KPj4NCj4+VGhlcmUncyBh bHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+Pmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA0DQo+Pg0KPj5BIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA0DQo+ Pg0KPj4NCj4+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2YNCj4+c3VibWlzc2lvbg0KPj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+SW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj5m dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+TmV0Y29uZiBtYWlsaW5nIGxpc3QN Cj4+TmV0Y29uZkBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmYNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPk5ldGNvbmYgbWFpbGluZyBsaXN0DQo+TmV0Y29uZkBpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Thu Oct 22 09:44: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 091FD1AD33F for ; Thu, 22 Oct 2015 09:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFC9XqSNr7b1 for ; Thu, 22 Oct 2015 09:44:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC3C1AD338 for ; Thu, 22 Oct 2015 09:44:02 -0700 (PDT) Received: from BL2PR05MB065.namprd05.prod.outlook.com (10.255.232.16) by BL2PR05MB068.namprd05.prod.outlook.com (10.255.232.23) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 22 Oct 2015 16:43:48 +0000 Received: from BL2PR05MB065.namprd05.prod.outlook.com ([169.254.4.206]) by BL2PR05MB065.namprd05.prod.outlook.com ([169.254.4.206]) with mapi id 15.01.0300.010; Thu, 22 Oct 2015 16:43:48 +0000 From: "Lisa (Yi) Huang" To: Martin Bjorklund Thread-Topic: [Netconf] restconf data namespace Thread-Index: AQHRDKGqKmgQf+uEG0iXpaJIWjcgvJ53M3AAgAAPloA= Date: Thu, 22 Oct 2015 16:43:48 +0000 Message-ID: References: <20151022.104758.216186742504224313.mbj@tail-f.com> In-Reply-To: <20151022.104758.216186742504224313.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.5.5.150821 authentication-results: spf=none (sender IP is ) smtp.mailfrom=lyihuang@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; BL2PR05MB068; 5:1Bf8YUrk2UUbf2rJNn7t0kJhxiFHzwmVgPa62UfExrg6+NcNHlL5JQBU18KR1RqDUIlypvDOYiM2WHGKZTep0S67HlkNVeuMYEk4wclG/6m63BLNOUse7/LOhRxe/ONLvARt+kJ2cti+7h7kEuYH2g==; 24:3RNYmVyB+pkA4jgHkHS6H8kFIFdnQofCVeGKZekcYMA/dzyPy8XtqHB71L6HZngv8yu6FXUKXnMDvDl1AgJ+QWLYlF/ctglIf2WYa2MPo5Y=; 20:A7aQzQ/Zu5uK9nuj8wcxyVq0DdJnI0gyPdq/8mB21sG/56EaDpVRrxxEG/2ism+LtYwG/iAT3ev5ZsZ1krj8Tw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BL2PR05MB068; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102215026); SRVR:BL2PR05MB068; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB068; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(199003)(479174004)(164054003)(377454003)(11100500001)(101416001)(99286002)(46102003)(5002640100001)(2900100001)(122556002)(40100003)(106116001)(105586002)(106356001)(36756003)(2950100001)(189998001)(15975445007)(102836002)(5007970100001)(10400500002)(92566002)(5008740100001)(5004730100002)(86362001)(5001960100002)(110136002)(66066001)(4001350100001)(87936001)(81156007)(19580405001)(19580395003)(83506001)(64706001)(97736004)(5001920100001)(50986999)(76176999)(54356999)(15395725005)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB068; H:BL2PR05MB065.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2015 16:43:48.4218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB068 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] restconf data namespace X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2015 16:44:07 -0000 Thanks Martin. Follow up questions: >>>4. For the first filter without namespace, what events will be >>>streamed if the two yang modules have the same notification name >>>(different data ) in the server? >All events that match the filter are streamed. So in your example, events from both modules will be streamed. Hmm. This "no namespace" filter doesn=B9t seem to be consistent with rfc527= 7 which this draft referenced. There are two filtering illustrated in Rfc5277-- subtree filtering and xpath filtering. Both examples of section 5.1 and 5.2 included namespace. Could you clarify which type of this =B3no namespace=B2 belongs to? Thanks, Lisa On 10/22/15, 1:47 AM, "Martin Bjorklund" wrote: >Hi, > >"Lisa (Yi) Huang" wrote: >> Hi netconf experts, >>=20 >> I have some questions regarding namespace specified in RESTCONF >> Protocol draft-ietf-netconf-restconf-08. >>=20 >> For this notification example: >>=20 >> module example-mod { >> namespace "http://example.com/event/1.0"; >>=20 >> notification event { >> leaf event-class { type string; } >> container reporting-entity { >> leaf card { type string; } >> } >> leaf severity { type string; } >> } >> } >>=20 >>=20 >> In RFC6020 >>=20 >> > xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> >> 2008-07-08T00:01:00Z >> >> fault >> >> Ethernet0 >> >> major >> >> >>=20 >>=20 >> In restconf I-D >>=20 >> data: > data: xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-restconf"> >> data: 2013-12-21T00:01:00Z >> data: >> data: fault >> data: >> data: Ethernet0 >> data: >> data: major >> data: >> data: >>=20 >>=20 >> 1. The name space changed from netconf:notification to >> yang:ietf-restconf. Here are my questions: What is the rule for the >> namespace change? > >The element "notification" in the namespace >"urn:ietf:params:xml:ns:netconf:notification:1.0" is used in NETCONF >to send a notification. > >The element "notification" in the namespace >"urn:ietf:params:xml:ns:yang:ietf-restconf" is used in RESTCONF to >send a notification. > >These are simply protocol-specific wrappers. > >> Json data: >>=20 >> data: { >> data: "ietf-restconf:notification": { >> data: "event-time": "2013-12-21T00:01:00Z", >> data: "example-mod:event": { >> data: "event-class": "fault", >> data: "reporting-entity": { "card": "Ethernet0" }, >> data: "severity": "major" >> data: } >> data: } >> data: } >>=20 >>=20 >> 2. How does example-mod namespace in json map to >> http://example.com/event/1.0 in xml? > >"example-mod" is the name of the module that defines the xml namespace >"http://example.com/event/1.0". > >The JSON mapping uses the module name instead of the namespace, see >draft-ietf-netmod-yang-json. > > >> Section D.3.6 explained how filter looks like. Question and comments >> follows: >>=20 >>=20 >> // filter =3D /event/event-class=3D'fault' >>=20 >> GET /mystreams/NETCONF?filter=3D%2Fevent%2Fevent-class%3D'fault' >>=20 >>=20 >> // Note: the module name is used as prefix. >> // filter =3D (/example-mod:event1/name=3D'joe' and >> // /example-mod:event1/status=3D'online') >> GET /mystreams/NETCONF? >> filter=3D(%2Fexample-mod%3Aevent1%2Fname%3D'joe'%20and >> %20%2Fexample-mod%3Aevent1%2Fstatus%3D'online') >>=20 >>=20 >>=20 >> 3. The url /mystreams/NETCONF is not consistent with /streams/NETCONF >> used for stream subscription. > >Ok, I changed the examples to make them consistent. > >But note that the "/streams/NETCONF" is just an example. A server is >free to use any location for the streams. The client learns where >the stream is found by looking at the "location" leaf for the stream. > >> 4. For the first filter without namespace, what events will be >> streamed if the two yang modules have the same notification name >> (different data ) in the server? > >All events that match the filter are streamed. So in your example, >events from both modules will be streamed. > > >/martin From nobody Thu Oct 22 13:18: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 08EC11B404D; Thu, 22 Oct 2015 13:18:35 -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 GTfwYjJ6ZsxS; Thu, 22 Oct 2015 13:18:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D92871B404B; Thu, 22 Oct 2015 13:18:33 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9MKIJZW092461 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 22 Oct 2015 15:18:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Benoit Claise" Date: Thu, 22 Oct 2015 15:18:18 -0500 Message-ID: <74936F60-A7E9-4E21-8E5A-DE709C315763@nostrum.com> In-Reply-To: <5628C43F.1030304@cisco.com> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <5628C43F.1030304@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , Netconf , Barry Leiba , The IESG Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Oct 2015 20:18:35 -0000 On 22 Oct 2015, at 6:10, Benoit Claise wrote: > On 10/21/2015 10:18 PM, Kent Watsen wrote: >> Hi Ben, >> >> Thank you for your review. >> >> >> Regarding your original comments: >> >> >>> If the client MAY be configured to listen on a non-standard port, >>> doesn’t >>> that imply that the server MUST be _capable_ of being configured to >>> connect to a non-standard port? >> This is correct and what draft-ietf-netconf-server-model-08 allows. >> Were you thinking that there needs to be a change in this draft? >> >> >>> I'm curious why people felt it necessary to reverse the usual TLS or >>> SSH >>> client and server roles. Did the working group consider having the >>> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the >> As Juergen noted, this allows that all existing authentication to >> continue working. Also, since SSH is not a symmetric protocol, >> it’s actually important for the client to be the SSH-client so it >> can open/close SSH channels (e.g., to start the “netconf” >> subsystem). > Ben, do you feel we need to mention it in the draft? I am happy with Stephen's suggestion (in a different branch of the thread) to send some questions to the TLS wg and openssh list. I will be fine with whatever results from that. Thanks! Ben. From nobody Thu Oct 22 17:11: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 7E6F81B2C72; Thu, 22 Oct 2015 17:11:26 -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 VsBiAEWNV_RQ; Thu, 22 Oct 2015 17:11:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7231B2C57; Thu, 22 Oct 2015 17:11:23 -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.306.13; Fri, 23 Oct 2015 00:11:01 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Fri, 23 Oct 2015 00:11:01 +0000 From: Kent Watsen To: Barry Leiba Thread-Topic: Barry Leiba's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRC2fK1cpI6GApn0KSl4VpDLgb8552PucAgAEyq4CAAIMlAA== Date: Fri, 23 Oct 2015 00:11:00 +0000 Message-ID: References: <20151020184735.19913.19977.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/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:qQwKXDRtO67rpkkZgUugnV430WvNdvXVzdb9JWIpBrr2oyL3H2VsGdVA4O38BK7403oFo5dnjOYJU+VMzRppNLZGQhAUxaWEFM4iSik7ZYv+dWboM6gnn2NBrtgoYUDvkmf3yPNgAohuo4GuM1f/uw==; 24:aevQ8uOKKxHtPm3Y84pYLjHJLPwuMlpyldb7Aj6jVop07WyTj6o5rpjEAQ6G/Cmqz9BkTqFegkgc86seF0uZeHpZ9TZwlAhuyizeJSpphro=; 20:BfrMaE0e6tfpsLoHVNAF3tsrMZb2EsiWwImCIMpKdfYkurgexffy8kZI7m4IGgYVbMWzQGBvFJHPF8WO3oxI0A== 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)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(52604005)(83506001)(5007970100001)(102836002)(5002640100001)(122556002)(2900100001)(82746002)(40100003)(110136002)(2950100001)(10400500002)(189998001)(5001960100002)(19580395003)(230783001)(87936001)(101416001)(5008740100001)(15975445007)(83716003)(5004730100002)(11100500001)(105586002)(36756003)(4001350100001)(99286002)(86362001)(106116001)(106356001)(76176999)(81156007)(92566002)(54356999)(66066001)(97736004)(33656002)(50986999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <73EE4522C842CC4498BB40BE3B400FFD@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 00:11:00.6524 (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" , The IESG , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Barry Leiba's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 00:11:26 -0000 DQoNCg0KDQo+Pj4gICAgICAgT25jZSB0aGUgU1NIIG9yIFRMUyBjb25uZWN0aW9uIGlzIGVzdGFi bGlzaGVkLCB0aGUgTkVUQ09ORi8NCj4+PiAgICAgICBSRVNUQ09ORiBjbGllbnQgTVVTVCBpbW1l ZGlhdGVseSBzdGFydCB1c2luZyBlaXRoZXIgdGhlIE5FVENPTkYtDQo+Pj4gICAgICAgY2xpZW50 IFtSRkM2MjQxXSBvciBSRVNUQ09ORi1jbGllbnQgW2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29u Zl0NCj4+PiAgICAgICBwcm90b2NvbC4NCj4+Pg0KPj4+V2hhdCAqZWxzZSogbWlnaHQgdGhlIGNs aWVudCBkbywgd2hpY2ggbWVyaXRzIGEgTVVTVCBoZXJlPyAgSSB0aGluayBhbGwNCj4+PnlvdSBz aG91bGQgc2F5IGhlcmUgaXMsICJPbmNlIHRoZSBTU0ggb3IgVExTIGNvbm5lY3Rpb24gaXMgZXN0 YWJsaXNoZWQsDQo+Pj50aGUgTkVUQ09ORi9SRVNDT05GIGNsaWVudCBzdGFydHMgdXNpbmcgZWl0 aGVyIFsuLi50aGUgcHJvdG9jb2xzLi4uXS4iDQo+Pg0KPj4gQSBtaXNiZWhhdmluZyBjbGllbnQg bWlnaHQgdHJ5IHRvIHN0YXJ0IGFub3RoZXIgcHJvdG9jb2wsIG9yIHNlbmQgc29tZQ0KPj4gb3Ro ZXIga2luZCBvZiBkYXRhLCBvciBtYXliZSBub3QgZG8gaXQg4oCcaW1tZWRpYXRlbHnigJ0uICAg VGhhdCBzYWlkLCBJ4oCZbQ0KPj4gb2theSByZW1vdmluZyB0aGUgIk1VU1QgaW1tZWRpYXRlbHni gJ0gaWYgeW91IHRoaW5rIGl0IGltcHJvdmVzIHRoZSB0ZXh0Lg0KPg0KPldlbGwsIGFzIEkgc2F5 LCBpdCdzIG5vdCBhbiBpbXBvcnRhbnQgcG9pbnQsIHNvIHBsZWFzZSBkbyBhcyB5b3UgdGhpbmsN Cj5iZXN0LiAgSSBwZXJzb25hbGx5IHRoaW5rIGl0J3MgYmV0dGVyIGFzIEkgc3VnZ2VzdCBhYm92 ZSwgYW5kIGl0J3MNCj5wcmV0dHkgZmFyLWZldGNoZWQgdG8gdGhpbmsgdGhhdCBhIE5FVENPTkYg Y2xpZW50IHdvdWxkIHN1ZGRlbmx5IHN0YXJ0DQo+dGFsa2luZyBSRVNDT05GIG9yIEZUUCBvciBz b21lIHN1Y2guICBCdXQganVzdCBjb25zaWRlciB0aGF0IGFzIGlucHV0LA0KPmFuZCBubyBuZWVk IHRvIGRpc2N1c3MgaXQgZnVydGhlci4uDQoNCg0KSGkgQmFycnksDQoNCkkgQ0MtZWQgeW91IG9u IGEgcmVzcG9uc2UgdG8gU3VyZXNoIGFuZCBKYXJpIG9uIHRoZSBHZW4tQVJUIFRlbGVjaGF0IHJl dmlldyB0aHJlYWQuICBBcyB5b3Ugc2F3LCBTdXJlc2ggYWxzbyB3b3VsZCBsaWtlIHRvIHNlZSB0 aGUgdHdvIHdvcmRzIOKAnE1VU1QgaW1tZWRpYXRlbHnigJ0gYmUgcmVtb3ZlZC4NCg0KVG8gYmUg Y2xlYXIsIHRoZSDigJxNVVNUIGltbWVkaWF0ZWx5IHN0YXJ04oCdIHRleHQgc2hvd3MgdXAgaW4g Zm91ciBwbGFjZXM6IEMzLCBDOCwgUzMsIGFuZCBTNi4gIEluIGFsbCBmb3VyIG9mIHRoZXNlIHBs YWNlcywgSSB3b3VsZCByZXBsYWNlICJtdXN0IGltbWVkaWF0ZWx5IHN0YXJ04oCdIHdpdGgganVz dCDigJxzdGFydOKAnS4gIA0KDQpCYXJyeSBzYWlkIHRoYXQgaGlzIGNvbW1lbnRzIHNob3VsZCBi ZSBoYW5kbGVkIGxpa2UgYW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50LiAgVG8gdGhhdCBlbmQs IEkgaGF2ZSBqdXN0IG9wZW5lZCBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9jYWxsLWhv bWUvaXNzdWVzLzEyIHRvIHRyYWNrIHRoaXMgaXNzdWUuICBUaGUgaXNzdWVzIGlzIGN1cnJlbnRs eSBpbiB0aGUgVkVSSUZZIHN0YXRlLg0KDQpOb3cgSSBhc2sgdGhlIHdvcmtpbmcgZ3JvdXAsIGRv IHdlIGhhdmUgY29uc2Vuc3VzIHRvIHJlbW92ZSDigJxNVVNUIGltbWVkaWF0ZWx54oCdIGZyb20g dGhlIHRleHQgaW4gQzMsIEM4LCBTMywgYW5kIFM2PyAgIEnigJlsbCBwbGFuIHRvIG1ha2UgdGhp cyBjaGFuZ2Ugb24gTW9uZGF5IGlmIG5vIG9iamVjdGlvbiBpcyByYWlzZWQgYnkgdGhlbi4NCg0K DQoNCg0KDQo+RG8geW91IHJlYWxseSB0aGluayB0aGVyZSdzIGEgZGFuZ2VyIG9mIGFueW9uZSBt aXN1bmRlcnN0YW5kaW5nIHRoYXQNCj5kb3duIGhlcmU/ICAoQW5kLCBhZ2Fpbiwgbm8gbmVlZCB0 byBhbnN3ZXIgdGhhdCB0byBtZTogYXQgdGhpcyBwb2ludA0KPmp1c3QgZG8gYXMgeW91IHRoaW5r IGJlc3QsIGFuZCB0aGFua3MgZm9yIGNvbnNpZGVyaW5nIG15IGNvbW1lbnRzLikNCg0KQWN0dWFs bHksIEkgZG8uICBUaGUgaGlzdG9yeSBvZiB0aGlzIGRyYWZ0IGlzIHRoYXQgdGhlcmUgaGFzIGJl ZW4gYSBsb3Qgb2YgbWlzdW5kZXJzdGFuZGluZyBhYm91dCBob3cgdGhlIHNvbHV0aW9uIHdvcmtz IGFuZCBvdmVyLWNvbW11bmNhdGluZyBoYXMgYmVlbiBrZXkgdG8gY2xlYXJpbmcgaXQgdXAuICBT byBJIHJlYWxseSBkbyB0aGluayBpdCBiZXN0IHRvIGtlZXAgdGhlIGZvbGxvd2luZyB0ZXh0IGFz IGl0IGlzOg0KDQogICBBc3N1bWluZyB0aGUgdXNlIG9mIHRoZSBJQU5BLWFzc2lnbmVkIHBvcnRz LCB0aGUNCiAgIE5FVENPTkYtY2xpZW50IHByb3RvY29sIGlzIHN0YXJ0ZWQgd2hlbiB0aGUgY29u bmVjdGlvbiBpcw0KICAgYWNjZXB0ZWQgb24gZWl0aGVyIHBvcnQgUE9SVC1YIG9yIFBPUlQtWSBh bmQgdGhlIFJFU1RDT05GLWNsaWVudA0KICAgcHJvdG9jb2wgaXMgc3RhcnRlZCB3aGVuIHRoZSBj b25uZWN0aW9uIGlzIGFjY2VwdGVkIG9uIHBvcnQgUE9SVC1aLg0KDQpUaGFuayB5b3UgYWdhaW4g QmFycnkuICBJJ2xsIGNvbnNpZGVyIHRoaXMgY29tbWVudCByZXNvbHZlZCB1bmxlc3MgYW55b25l IGRpc2FncmVlcy4NCg0KDQoNCg0KS2VudA0KDQo= From nobody Thu Oct 22 17:26: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 AE5D11B2D75; Thu, 22 Oct 2015 17:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMLuk6w7PDzB; Thu, 22 Oct 2015 17:26:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FF71B2D58; Thu, 22 Oct 2015 17:26:22 -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.306.13; Fri, 23 Oct 2015 00:26:20 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Fri, 23 Oct 2015 00:26:20 +0000 From: Kent Watsen To: Ben Campbell , Benoit Claise Thread-Topic: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRC4NwSO9HeS5EiE2jlg9x14GRTZ51dggAgAA4poCAAAM9AIAAUjGAgAAdHgCAATxjgIAAmPAAgAACPAA= Date: Fri, 23 Oct 2015 00:26:19 +0000 Message-ID: <85DC7141-7A79-4923-AA4E-D493299DBCFE@juniper.net> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <5628C43F.1030304@cisco.com> <74936F60-A7E9-4E21-8E5A-DE709C315763@nostrum.com> In-Reply-To: <74936F60-A7E9-4E21-8E5A-DE709C315763@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:oVks2EQzNYFPD+/Wl3/WsfY0zzqROfO6/mt4DaFyA0BL35n24+HiN5A7IcVrs7n91sJt6UTctfP5YwVLrUlWHmUrNqQvF5jrDLx2SFbmYTTY/up4X3Xy8S+0nyrKXq5f519mmpdwJ7mpArnrLD1psA==; 24:IfkU96b2TF8oaIXck3DCtZrCF2d9fXrXD89IV1xS87C2WP30DnDkflK+1mxQmlrRVeYc6+NZzdYvf7/9M4PZS6wgNc8KAiIqXh7XlJ0xf0o=; 20:KS6pBrV1NT0+Wq2VTgFjDKPB8GHRd6w3C3daNCV6vCg3LWdAbyem4r6M58GeD/dq0xEOAKqkQS0IxI68z9ebTA== 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)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(189002)(76176999)(92566002)(93886004)(81156007)(86362001)(99286002)(106116001)(36756003)(4001350100001)(106356001)(97736004)(33656002)(66066001)(5001770100001)(50986999)(54356999)(40100003)(2950100001)(10400500002)(122556002)(82746002)(2900100001)(5001960100002)(189998001)(83506001)(5007970100001)(102836002)(5002640100001)(105586002)(11100500001)(83716003)(5004730100002)(87936001)(230783001)(101416001)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 00:26:19.9955 (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-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , The IESG , Barry Leiba , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 00:26:24 -0000 DQoNCg0KDQo+Pj4+IEknbSBjdXJpb3VzIHdoeSBwZW9wbGUgZmVsdCBpdCBuZWNlc3NhcnkgdG8g cmV2ZXJzZSB0aGUgdXN1YWwgVExTIG9yIA0KPj4+PiBTU0gNCj4+Pj4gY2xpZW50IGFuZCBzZXJ2 ZXIgcm9sZXMuIERpZCB0aGUgd29ya2luZyBncm91cCBjb25zaWRlciBoYXZpbmcgdGhlDQo+Pj4+ IE5FVENPTkYvUkVTVENPTkYgc2VydmVyIGFjdCBhcyB0aGUgVExTIG9yIFNTSCBjbGllbnQ/IElm IHNvLCBjYW4gdGhlDQo+Pj4gQXMgSnVlcmdlbiBub3RlZCwgdGhpcyBhbGxvd3MgYWxsIGV4aXN0 aW5nIGF1dGhlbnRpY2F0aW9uIHRvIA0KPj4+IGNvbnRpbnVlIHdvcmtpbmcuICBBbHNvLCBzaW5j ZSBTU0ggaXMgbm90IGEgc3ltbWV0cmljIHByb3RvY29sLCANCj4+PiBpdOKAmXMgYWN0dWFsbHkg aW1wb3J0YW50IGZvciB0aGUgY2xpZW50IHRvIGJlIHRoZSBTU0gtY2xpZW50IHNvIGl0IA0KPj4+ IGNhbiBvcGVuL2Nsb3NlIFNTSCBjaGFubmVscyAoZS5nLiwgdG8gc3RhcnQgdGhlIOKAnG5ldGNv bmbigJ0gDQo+Pj4gc3Vic3lzdGVtKS4NCj4+IEJlbiwgZG8geW91IGZlZWwgd2UgbmVlZCB0byBt ZW50aW9uIGl0IGluIHRoZSBkcmFmdD8NCg0KQWN0dWFsbHksIHRoZSBkcmFmdCBhbHJlYWR5IGhh cyB0aGlzOg0KDQogIEhhdmluZyBjb25zaXN0ZW5jeSBpbiBib3RoIHRoZSBzZWN1cmUgdHJhbnNw b3J0IGxheWVyIChTU0gsIFRMUykgYW5kDQogIGFwcGxpY2F0aW9uIGxheWVyIChORVRDT05GLCBS RVNUQ09ORikgcm9sZXMgY29udmVuaWVudGx5IGVuYWJsZXMNCiAgZGVwbG95ZWQgbmV0d29yayBt YW5hZ2VtZW50IGluZnJhc3RydWN0dXJlIHRvIHN1cHBvcnQgY2FsbCBob21lIGFsc28uDQogIEZv ciBpbnN0YW5jZSwgZXhpc3RpbmcgY2VydGlmaWNhdGUgY2hhaW5zIGFuZCB1c2VyIGF1dGhlbnRp Y2F0aW9uDQogIG1lY2hhbmlzbXMgYXJlIHVuYWZmZWN0ZWQgYnkgY2FsbCBob21lLg0KDQpHb29k IGVub3VnaD8NCg0KDQoNCj5JIGFtIGhhcHB5IHdpdGggU3RlcGhlbidzIHN1Z2dlc3Rpb24gKGlu IGEgZGlmZmVyZW50IGJyYW5jaCBvZiB0aGUgDQo+dGhyZWFkKSB0byBzZW5kIHNvbWUgcXVlc3Rp b25zIHRvIHRoZSBUTFMgd2cgYW5kIG9wZW5zc2ggbGlzdC4gSSB3aWxsIGJlIA0KPmZpbmUgd2l0 aCB3aGF0ZXZlciByZXN1bHRzIGZyb20gdGhhdC4NCg0KWWVzLCB3ZeKAmWxsIHNlZSBob3cgdGhh dCBwbGF5cyBvdXQuDQoNClRoYW5rcywNCktlbnQNCg0K From nobody Thu Oct 22 17:35: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 96C4E1B3043; Thu, 22 Oct 2015 17:35:50 -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 IPDMJGpQwQkK; Thu, 22 Oct 2015 17:35:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 205651B3042; Thu, 22 Oct 2015 17:35:49 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9N0ZhgE015663 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 22 Oct 2015 19:35:43 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Kent Watsen" Date: Thu, 22 Oct 2015 19:35:43 -0500 Message-ID: In-Reply-To: <85DC7141-7A79-4923-AA4E-D493299DBCFE@juniper.net> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <5628C43F.1030304@cisco.com> <74936F60-A7E9-4E21-8E5A-DE709C315763@nostrum.com> <85DC7141-7A79-4923-AA4E-D493299DBCFE@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , The IESG , Barry Leiba , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 00:35:50 -0000 On 22 Oct 2015, at 19:26, Kent Watsen wrote: >>>>> I'm curious why people felt it necessary to reverse the usual TLS or >>>>> SSH >>>>> client and server roles. Did the working group consider having the >>>>> NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the >>>> As Juergen noted, this allows all existing authentication to >>>> continue working. Also, since SSH is not a symmetric protocol, >>>> it’s actually important for the client to be the SSH-client so it >>>> can open/close SSH channels (e.g., to start the “netconf” >>>> subsystem). >>> Ben, do you feel we need to mention it in the draft? > > Actually, the draft already has this: > > Having consistency in both the secure transport layer (SSH, TLS) and > application layer (NETCONF, RESTCONF) roles conveniently enables > deployed network management infrastructure to support call home also. > For instance, existing certificate chains and user authentication > mechanisms are unaffected by call home. > > Good enough? Yes for the "why" part. > > > >> I am happy with Stephen's suggestion (in a different branch of the >> thread) to send some questions to the TLS wg and openssh list. I will be >> fine with whatever results from that. > > Yes, we’ll see how that plays out. > > Thanks, > Kent From nobody Thu Oct 22 17:53:32 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 20BDB1A923B; Thu, 22 Oct 2015 17:53:27 -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 txG7ZanUl7S4; Thu, 22 Oct 2015 17:53:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17261A9236; Thu, 22 Oct 2015 17:53:25 -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.306.13; Fri, 23 Oct 2015 00:53:24 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Fri, 23 Oct 2015 00:53:24 +0000 From: Kent Watsen To: Ben Campbell Thread-Topic: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRC4NwSO9HeS5EiE2jlg9x14GRTZ51dggAgAA4poCAAAM9AIAAUjGAgAAdHgCAAFV4AIABiacA Date: Fri, 23 Oct 2015 00:53:23 +0000 Message-ID: <23D01C9B-C786-446B-9725-E584018300C0@juniper.net> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> In-Reply-To: <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:HQUZL2+Oe3L/l5xHG6ZauAiUCPS9/u9Jxi980OzhQ2eyT0SYZdQZnkebE+EQLMnlJ1zAKWdlWxgKsPcjxqRewOO55jAzeSzd99T2cmBRaZbpk83O8AwCosP9a7CR2odlRDB8teve8bzgQbGqdb/Z1w==; 24:4NxvJjvVIIzOht7ikqpv7iBvxpYazKuKxIY2RJABMeJIWy84fU+UNbnOmEqUsN3fvlIsDt2HIbLJDRaSG3XqPAO1UMor96D8gmV6ZZq3rBw=; 20:yHjijMKmpIbO64ka1A9ZMzVQc6fCQrQuPPir8GVFclgcLiPdVb2X3BR0ERNeSazBqX1rSIOeIypKn/v22gy96A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(164054003)(199003)(189002)(10400500002)(230783001)(99286002)(4001350100001)(97736004)(50986999)(101416001)(81156007)(54356999)(11100500001)(189998001)(5008740100001)(5004730100002)(106116001)(86362001)(33656002)(36756003)(105586002)(110136002)(106356001)(5001960100002)(5007970100001)(40100003)(5001920100001)(87936001)(93886004)(2950100001)(2900100001)(92566002)(5002640100001)(102836002)(76176999)(83716003)(66066001)(83506001)(82746002)(122556002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <29B7C15188F2CC429952AE478E7EA26F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 00:53:23.7822 (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: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , The IESG , Barry Leiba , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 00:53:27 -0000 DQoNCg0KDQoNCj4+PklmIHRoZSBjbGllbnQgTUFZIGJlIGNvbmZpZ3VyZWQgdG8gbGlzdGVuIG9u IGEgbm9uLXN0YW5kYXJkIHBvcnQsIA0KPj4+IGRvZXNu4oCZdA0KPj4+IHRoYXQgaW1wbHkgdGhh dCB0aGUgc2VydmVyIE1VU1QgYmUgX2NhcGFibGVfIG9mIGJlaW5nIGNvbmZpZ3VyZWQgdG8NCj4+ PiBjb25uZWN0IHRvIGEgbm9uLXN0YW5kYXJkIHBvcnQ/DQo+Pg0KPj4gVGhpcyBpcyBjb3JyZWN0 IGFuZCB3aGF0IGRyYWZ0LWlldGYtbmV0Y29uZi1zZXJ2ZXItbW9kZWwtMDggYWxsb3dzLiAgIA0K Pj4gV2VyZSB5b3UgdGhpbmtpbmcgdGhhdCB0aGVyZSBuZWVkcyB0byBiZSBhIGNoYW5nZSBpbiB0 aGlzIGRyYWZ0Pw0KPg0KPkkgdGhpbmsgaXQncyB3b3J0aCBhIG1lbnRpb24uIFBlb3BsZSB3aWxs IHByb2JhYmx5IGZpZ3VyZSBpdCBvdXQgZm9yIA0KPnRoZW1zZWx2ZXMsIGJ1dCBpdCdzIHVzdWFs bHkgYmV0dGVyIHRvIGJlIGV4cGxpY2l0Lg0KDQpIaSBCZW4sDQoNClRoZSBkcmFmdCBjdXJyZW50 bHkgaGFzIHRoaXM6DQoNCiAgUzEgIFRoZSBORVRDT05GL1JFU1RDT05GIHNlcnZlciBpbml0aWF0 ZXMgYSBUQ1AgY29ubmVjdGlvbiByZXF1ZXN0IHRvDQogICAgIHRoZSBORVRDT05GL1JFU1RDT05G IGNsaWVudC4gIFRoZSBzZXJ2ZXIgU0hPVUxEIGNvbm5lY3QgdG8gb25lIG9mDQogICAgIHRoZSBJ QU5BLWFzc2lnbmVkIHBvcnRzIGRlZmluZWQgaW4gc2VjdGlvbiBTZWN0aW9uIDUsIGJ1dCBNQVkg YmUNCiAgICAgY29uZmlndXJlZCB0byB1c2UgYSBub24tc3RhbmRhcmQgcG9ydC4gIFVzaW5nIHRo ZSBJQU5BLWFzc2lnbmVkDQogICAgIHBvcnRzLCB0aGUgc2VydmVyIGNvbm5lY3RzIHRvIHBvcnQg UE9SVC1YIGZvciBORVRDT05GIG92ZXIgU1NILA0KICAgICBwb3J0IFBPUlQtWSBmb3IgTkVUQ09O RiBvdmVyIFRMUywgYW5kIHBvcnQgUE9SVC1aIGZvciBSRVNUQ09ORg0KICAgICBvdmVyIFRMUy4N Cg0KDQpJIHNob3VsZOKAmXZlIHBvaW50ZWQgb3V0IHRoZSBhYm92ZSBvbiBteSBlYXJsaWVyIHJl c3BvbnNlLiBXZSBjb3VsZCByZXBsYWNlIHRoZSBzZWNvbmQgc2VudGVuY2Ugd2l0aDoNCg0KDQog ICAgVGhlIHNlcnZlciBNVVNUIGRlZmF1bHQgdG8gY29ubmVjdGluZyB0byBvbmUgb2YgdGhlIElB TkEtYXNzaWduZWQNCiAgICBwb3J0cyBkZWZpbmVkIGluIFNlY3Rpb24gNSBhbmQgYmUgY29uZmln dXJhYmxlIHRvIHVzZSBhIG5vbi1zdGFuZGFyZA0KICAgIHBvcnQuDQoNCg0KV2hhdCBkbyB5b3Ug dGhpbms/DQoNCg0KQlRXOiBJIGp1c3QgY2F1Z2h0IGEgdHlwbzog4oCcc2VjdGlvbiBTZWN0aW9u IDXigJ0gIChmaXhlZCBpbiBteSBsb2NhbCBjb3B5KS4NCg0KDQoNClRoYW5rcywNCktlbnQNCg0K From nobody Fri Oct 23 01:40: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 4406F1B333E; Fri, 23 Oct 2015 01:40:33 -0700 (PDT) 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 nW-sBvrzb7pV; Fri, 23 Oct 2015 01:40:32 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABAA1B3329; Fri, 23 Oct 2015 01:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1830; q=dns/txt; s=iport; t=1445589631; x=1446799231; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=122UeoveI+wG9jHB+uzTxv1TzFv+OV2UgtDgyAprQWc=; b=EbJjs7h7Qv8SGXVRYJ/9w6vX70UCsxqTAWyG9NZjmene1FSfR45hixLw mEXwNQWIEHgnE2JWCfDyngVhcgjMGxJvdDMTK5jfJ7OZbRCImaghVfC+a v07C97DhYzAZZxRaAXEH4LYK0t0fuCxc3pbtFVqtigfCfURUd5X5f5N1J I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CqBAB28SlW/xbLJq1ehAq6dIYIhh0CghEBAQEBAQGBC4QzAQEEIw8BBUABEAsODAIFFgsCAgkDAgECAUUGAQwIAQGILLJRkmsBAQEBAQEBAQEBAQEBAQEBAQEbgSKFVYR+hQ0HgmmBRQEEliuNHoFYh0CPHoNwY4IRHRaBQTyGdwEBAQ X-IronPort-AV: E=Sophos;i="5.20,185,1444694400"; d="scan'208";a="605865988" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2015 08:40:29 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9N8eSHq011655; Fri, 23 Oct 2015 08:40:28 GMT To: Kent Watsen , Martin Stiemerling , The IESG References: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> From: Benoit Claise Message-ID: <5629F268.1080108@cisco.com> Date: Fri, 23 Oct 2015 10:40:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 08:40:33 -0000 Dear all, > Hi Martin, > > Thank you for your review. > > > > >> 1) Why is this parapraph below (and subsequently the other similar ones) >> using RFC 2119 language with respect to the port numbers >> The NETCONF/RESTCONF client listens for TCP connection requests >> from NETCONF/RESTCONF servers. The client SHOULD listen for >> connections on the IANA-assigned ports defined in section >> Section 5, but MAY be configured to use a non-standard port. >> >> Using the right port number is not something that influences the >> interoperability of the protocol per se, but is an operational parameter. >> Checking other protocol specifications, e.g. HTTP/1.1, there is no RFC >> 2119 language about the usage of specific port numbers. > This is true. I don’t see RFC 2119 language in RFC 4253 either. That said, is it in any way wrong or bad? I’m happy to change the text of course, just want to confirm... > > > >> 2) I am not a fan of having different port numbers to differentiate >> different vanilla flavors of a protocol. However, I can understand the >> why this is happening this way. But what is happening if there is >> X-over-TLS/SSH/foo coming after RESTCONF? Are you again in need of more >> port numbers? This does not look like a tactical wise and sustainable >> way. > Joe Touch made a similar comment about a year and a half ago. There was quite a debate about it then. We discussed the option of having just one port for any number to TCP-based call home protocols. In the end, the WG consensus was to use distinct ports as written in the current text. Is this something you would like to raise again now? We went through this already, and we had consensus on the decision. I don't think we should revisit this now. Regards, Benoit From nobody Fri Oct 23 04:43: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 C52841B3521 for ; Fri, 23 Oct 2015 04:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.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, 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 3Pu_472MwekY for ; Fri, 23 Oct 2015 04:43:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283201B351A for ; Fri, 23 Oct 2015 04:43:07 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:b049:36d0:8adb:aee6] (unknown [IPv6:2001:718:1a02:1:b049:36d0:8adb:aee6]) by mail.nic.cz (Postfix) with ESMTPSA id 79BB41818B7 for ; Fri, 23 Oct 2015 13:43:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1445600585; bh=WXAVSO8UfsX+IZwrkSVsYiq81ZoUfq/HeNt+WYiYOCw=; h=From:Date:To; b=oY52wIYCCATpYuyAaIT+Kh8ISBFrAfDKzqDiznyIgVwDQWdn34g29QGXWb0NErj1r GXOakoqWX8J5JDDnTOnGQA32cVn3+FYAvRzTJPt2D5czpk7zSDcU4p5nzcBQGJvVSG wSD0QTPpgTWZngAEpQXAL1RtJCGmInAREpbxyhMw= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <8535BDDF-C7EF-4D50-8A84-C4D88EF51E1C@nic.cz> Date: Fri, 23 Oct 2015 13:43:06 +0200 To: NETCONF Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [Netconf] web 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, 23 Oct 2015 11:43:09 -0000 Hi, perhaps this might be of interest to RESTCONF? http://www.w3.org/TR/2015/REC-notifications-20151022/ Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Oct 23 05:10: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 6D65D1B3571; Fri, 23 Oct 2015 05:10:48 -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 ei_T-ElTk7Uq; Fri, 23 Oct 2015 05:10:46 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::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 D0F041B3570; Fri, 23 Oct 2015 05:10:45 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 23 Oct 2015 12:10:39 +0000 Message-ID: <025d01d10d8b$bc328de0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Barry Leiba References: <20151020184735.19913.19977.idtracker@ietfa.amsl.com> Date: Fri, 23 Oct 2015 13:09:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: AM3PR04CA0089.eurprd04.prod.outlook.com (25.163.180.143) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB059; 2:/XWWijH/N2tG0ZyBOlbXFSImfGojhiR2d8GvhV6ZM7+pkV4gYztevNHKoqli5pY31HOIVzUdaro8wbz3IepgdsFl6S03T/q8Wbpc298dJ85tmEfx8YKoJtzXRA9PoTcWgDzxBQu+O/f0gep7zQov3PtcP2dQh+pxlfIhEk4SHkM=; 3:OZ7czmAA7vzr+vpSWIQqKfr7a+IWbN+UJklzj3iKz6gH9NOwisAeVmrZKg+8eSwWBzzWnvwp+tOMQ3dSXrbqd7ypGZI+tnRNBEe8V9e4yL3IIga5JonpNsHR6I1+mTAqmAjI0jsJasmO1rm2BfsPYA==; 25:cPNUBJGULMk51xAYW3V0G76hT9JeP3g8e4g0JbZmApyy14zKabCFwPPvTeq05dDPVZiOpnOG+jqvIlq4BOQoIljVWLgVZkeFx0DUnm/kNAn5VNv0yZEEdCv4vrXpKNLAm3HI6NECiUOlDAC/G/JfOyEHe/m7ffztFCYRqoGbwW0ElXCGd1cq1XLREfoIdaMne0Ao2nCsGWE/3Qjjjrkx54vYKDVApS8nJNAZaLnim41W50oj7F22HxXSIAlWfpzgG2DK4Tx2AH0uGvyCtqZWZQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:DB3PR07MB059; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB059; X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB059; 4:NTbVi5aXxBAkDcaZ1DtuYMSoIRzVu3+RX5cW2965OnRwcSHR/K1c4dl2ArRYdlIDNGppBxhcLtIDnzij/Lrdn7dmE5a2wY8Z/aIwuXFnhchJS+5s1+/JqREtuNCvVCp8xWC5JFJ6aCsVbAyP6ugtuEjCOEjWEFfFFEded9Vnt5Q5FHiIPJQGzzG6nZDFfxTBn8k8V5FdD2X3IOuRc5nkcJyME4ui5VnRfts7oZ7my0pNEDY0/yzuVGTiXgdYRC0vppZewzEuWwSsNHrgH8T4IgHAjBL5VGPmpsA2Hn453NRG0rZ+L2BV/z3JeX6HJYH0/xwW+cjwQX6+C2axVe0Pbo6uDs3UMXQ/N4cLSYjAFAxjzZ+bxTHbZSFEmoBxv22x X-Forefront-PRVS: 0738AF4208 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(199003)(52604005)(51444003)(5001770100001)(93886004)(77096005)(15975445007)(1456003)(92566002)(5001960100002)(66066001)(189998001)(40100003)(122386002)(14496001)(47776003)(5008740100001)(33646002)(97736004)(1941001)(42186005)(105586002)(106356001)(50986999)(230783001)(5007970100001)(61296003)(5004730100002)(81156007)(1556002)(116806002)(23676002)(19580405001)(81816999)(76176999)(19580395003)(44716002)(50466002)(84392001)(62236002)(87976001)(86362001)(5820100001)(44736004)(50226001)(81686999)(101416001)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB059; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNTk7MjM6QnBiRFYvOVZFZDBXckpSY0NrLzgvaE9Na09I?= =?utf-8?B?c0RJb2lEcHBPaTJabzltSGFaYVZ1ZnByYTVFREpNdzdFMCtoRGdvd3NNQjBn?= =?utf-8?B?bW05QnEvdmt5UkZydHJJd2ExU0NYS0VncTd4b1Y0UlZpS0dqYnJXUWxiSVRl?= =?utf-8?B?WHRzVE0zeXZRdWRCckdONWdWSEh2U1pDVWs3c0ZhT1d0QXFVbUpXUXl1RkJR?= =?utf-8?B?M051bHdvVEswUmtZTEdKSm1ia280eEhxcXZRTXBmYnozTERBRXBDNkV1cE0z?= =?utf-8?B?YWlrd2gyZ1QwdEMvNnZOZVkyTWtscFFETFdTUzNvZ3cyclUwckdtRDRpRjNK?= =?utf-8?B?Tyt0ZnJoT0NOWVYzdVlYQ2RQNGtaY3dlR0NxY1U0RG9WSjU0b3pCcWpaMUJS?= =?utf-8?B?bzBCU2U1Z1p2eWRIanZHK0d3SkV5MENBMENUMWhRbEtMR0VqL1Jhc0FnUE5Z?= =?utf-8?B?d3JJOU9Edmd4MDF1WWJJWEpZQjdONkZ5M2JOVEFxQzM4RTk1M2NDTktQMXJP?= =?utf-8?B?bnNVNEQ3ajJZMFQ5dzJGMTVnMXN0b0JaQmZKaXN6MnNLOWhKNitpOEtPSGRK?= =?utf-8?B?MTRCWm1wSlRtL2h2dUZKS1RyUkw5TEpsVlM3aDVWNUFRaDRPTXhiSytHK2Iv?= =?utf-8?B?UWpBRWNmZWkrb3hPS2VacjVQblVhODdYcU1XTTlMRFY2UC8zbWp3YVRXZFZD?= =?utf-8?B?Q1hNWlNOZmFNU0QvdXEzclk5aS9wUXhpT1dSZ2pOTHNMbGxaTCtadFhTL0NC?= =?utf-8?B?RWhNZ2hyU0RFdlFrRlVMKzNiYXluTHZlM0RSSDdFYUhsbUlpYm44dUFORTB0?= =?utf-8?B?U0dlKzlaeE0xdzRGU2Zha1dqNkNybTNTQjlGRFIwOGpFTmV0ejg4Y2hVd2lq?= =?utf-8?B?Mmk5azBoU1RxNDFYdThmR2RZbXRaN3ZFb1AvcmJBWm1MVk13SkZjRzU1V21k?= =?utf-8?B?TjZFRnN1WjFDY1AxblJSLzZ6WWE4dlEzVTNBcGE1ZUtCVGpEZTFSb3ZnazlP?= =?utf-8?B?WDJIRnZBOGs0TVhlUmpHRzAydThwcEszV05XVGlJNHhGaXVYcE5aUHVsU3g1?= =?utf-8?B?cWIwZ1NkWi80NGZPRkhzQ2NyYmRTMHdJaThFRUNMN0pzalJlcng4WHE5QmVv?= =?utf-8?B?Q3dMUlhJam9sUFZhaWZYSmhUWFZqT0MyV2R6d2EyaHF6WXFnQVBHRmE3dHlJ?= =?utf-8?B?Z1Npa3pOUlRIWm8wQzIxVTIrM0VsMzB5MGlZUHNQSTZ6djdRNEczNXpIbXdY?= =?utf-8?B?NVJDQkk3YlJ4bm8vVlE5Kzh2dlVWWjVFSjNCdW9YTW5OZ0Mrb08wcldURUlT?= =?utf-8?B?NXdFUVJPcEV3YnZ1ZW0vOFJ1bXlWZmV2L1hWS2cvaUwzZzM5OFBXdWJxV3NP?= =?utf-8?B?RFpUTHhYWXptTU0wTW5HVWFzK0grUnYwOVQxSzZGL1RBcS91TitGWTN1eWlF?= =?utf-8?B?cFdGMDRsR0tWc0k3Ym5aUFBNbkxQZENLME15U0pmdit6cUNqUkVnOExwc01M?= =?utf-8?B?djE4dE9GWEtjMDkzTlRLUXRqY0F5MmpjczNGREhDN1NpbjRhSEVmQ04zZE5y?= =?utf-8?B?VmVMSWR3WUdpL1pYazFIeno5d3V3Z2pRTHFrMi9qbERIRFV0VkFBcUJqbXRp?= =?utf-8?B?NnFxQjZ0Wlg4dHNNWFpjMVBkSUxNM1ducmREaFc2bVUvOCtTbjA2T1piYjZ1?= =?utf-8?B?Q1R5TWN2RTRsSTM1R1Vvb3ZmNDZYUXFhZGpiVys4WHRJdGZMOGNqQ0gzS0Nq?= =?utf-8?B?V3FtdlpoLzN6SEdKZ1ZVem5ONzlPdWNGc2NSTS9TdEsrS3BCTlBvMElQSjZG?= =?utf-8?B?THRORm9udjdrWE9TWFR1a3Z4V0sxS0dkcnJJZTA0eDBlejIwejVURUVXK3JN?= =?utf-8?Q?ghoQFfL5cw=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB059; 5:qNGh3x0comHQhI3Z1CV4vhJ6Cs0m76EoXC58NTrSH7KHvkaz8FsR+SV7gLvapymZdybRjw7FHfOAzB1N8QrU6owidwWQVHLeNNX8fBKsn9vuFrPO8Ya4ti3DgFe+bL3p/UgSgepSeQLao6A3y/KB2A==; 24:vw43rrFyTFmQrAsZ/dxaqokfh8YQ+kLUQBlhV4yvIHckAr5e1A+pYPiGMRpOVnYtHUwOtQzMZDdw0E3/vbIA9Iao7akWaQJwj+b0XZf5wI4=; 20:FGQW1iad5x7dvof7RANvHX54ADXRPr1tpxbUfJ9fbVY6tnKeTXd6EMeGMjmDZfoaXeiLBmMDVWTEM3hw+dtfwQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2015 12:10:39.8110 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB059 Archived-At: Cc: netconf-chairs@ietf.org, netconf@ietf.org, draft-ietf-netconf-call-home@ietf.org, The IESG Subject: Re: [Netconf] Barry Leiba's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 12:10:48 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Barry Leiba" Cc: ; "The IESG" ; ; Sent: Friday, October 23, 2015 1:11 AM > >>> Once the SSH or TLS connection is established, the NETCONF/ > >>> RESTCONF client MUST immediately start using either the NETCONF- > >>> client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] > >>> protocol. > >>> > >>>What *else* might the client do, which merits a MUST here? I think all > >>>you should say here is, "Once the SSH or TLS connection is established, > >>>the NETCONF/RESCONF client starts using either [...the protocols...]." > >> > >> A misbehaving client might try to start another protocol, or send some > >> other kind of data, or maybe not do it “immediately”. That said, I’m > >> okay removing the "MUST immediately” if you think it improves the text. > > > >Well, as I say, it's not an important point, so please do as you think > >best. I personally think it's better as I suggest above, and it's > >pretty far-fetched to think that a NETCONF client would suddenly start > >talking RESCONF or FTP or some such. But just consider that as input, > >and no need to discuss it further.. > > Hi Barry, > > I CC-ed you on a response to Suresh and Jari on the Gen-ART Telechat review thread. As you saw, Suresh also would like to see the two words “MUST immediately” be removed. > > To be clear, the “MUST immediately start” text shows up in four places: C3, C8, S3, and S6. In all four of these places, I would replace "must immediately start” with just “start”. > > Barry said that his comments should be handled like any other Last Call comment. To that end, I have just opened https://github.com/netconf-wg/call-home/issues/12 to track this issue. The issues is currently in the VERIFY state. > > Now I ask the working group, do we have consensus to remove “MUST immediately” from the text in C3, C8, S3, and S6? I’ll plan to make this change on Monday if no objection is raised by then. > Weeell, I am happy with the change in principle but grammatically it becomes 'starts' and not 'start'. And that is not quite the same meaning but I think that that is ok. I did contemplate /starts using/uses/ but that is a further shift in the semantics which I think goes too far. Tom Petch > >Do you really think there's a danger of anyone misunderstanding that > >down here? (And, again, no need to answer that to me: at this point > >just do as you think best, and thanks for considering my comments.) > > Actually, I do. The history of this draft is that there has been a lot of misunderstanding about how the solution works and over-communcating has been key to clearing it up. So I really do think it best to keep the following text as it is: > > Assuming the use of the IANA-assigned ports, the > NETCONF-client protocol is started when the connection is > accepted on either port PORT-X or PORT-Y and the RESTCONF-client > protocol is started when the connection is accepted on port PORT-Z. > > Thank you again Barry. I'll consider this comment resolved unless anyone disagrees. > > > > > Kent > > From nobody Fri Oct 23 05:22: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 CF1061B3585 for ; Fri, 23 Oct 2015 05:22:14 -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 z6hTPdfH1nh0 for ; Fri, 23 Oct 2015 05:22:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.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 458AA1B3575 for ; Fri, 23 Oct 2015 05:22:13 -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.306.13; Fri, 23 Oct 2015 12:22:10 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Fri, 23 Oct 2015 12:22:10 +0000 From: Kent Watsen To: Ladislav Lhotka , NETCONF Thread-Topic: [Netconf] web notifications Thread-Index: AQHRDYgACZhQKGgZA0Gcd76OLFZBUZ54vMAA Date: Fri, 23 Oct 2015 12:22:09 +0000 Message-ID: <248DE4BA-750E-4E99-992A-DE6AE598657B@juniper.net> References: <8535BDDF-C7EF-4D50-8A84-C4D88EF51E1C@nic.cz> In-Reply-To: <8535BDDF-C7EF-4D50-8A84-C4D88EF51E1C@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB459; 5:XRs+XHsLe3gFdO11B060YBknrzNIa9JIZvgXdd63wWo45OCsUU0f57aEZgvr5pdCfmhGQHNNyMKE2u+VkiC/J5vVJsap38lSGESAQEpmqbLEiK9gpbgLxVeuCkVRYE4JIinA3/YY0hwvaOPTSz0KmA==; 24:oxJd3tFYE3BZoSpvbfWpNoOpLDsS+bNc/+1ARmTOm3sb0QmX9P8sqEdF4ZaMBtGZPOyYfVfvz9Tvc2sm5mHGubfE8zCQV2ok4NgSmo1xASg=; 20:RVAWe9ho7RuaeswxV2qbJ8K5u7mkEg1LahDQ8Nf3rVXWU4/W5ZW5llRgiEZAB+fZLquE+i0v71BxHXxLjq3HZQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026); SRVR:CO1PR05MB459; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB459; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(377454003)(479174004)(189002)(101416001)(99286002)(107886002)(10400500002)(10710500006)(4001350100001)(2420400006)(50986999)(81156007)(5008740100001)(5004730100002)(189998001)(11100500001)(7110500001)(86362001)(106116001)(5001770100001)(36756003)(33656002)(106356001)(575784001)(5001960100002)(105586002)(5007970100001)(15975445007)(87936001)(2950100001)(102836002)(5002640100001)(2900100001)(92566002)(76176999)(19580405001)(83716003)(66066001)(83506001)(122556002)(82746002)(97736004)(40100003)(19580395003)(54356999)(5001920100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 12:22:09.5657 (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] web 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, 23 Oct 2015 12:22:15 -0000 DQpXaGF0IEkgdmVyeSBtdWNoIGRpc2xpa2UgYWJvdXQgVzNDIHNwZWNzIGxpa2UgdGhpcyBvbmUg YW5kIFNTRSwgaXMgdGhhdCB0aGV54oCZcmUgZGVmaW5lZCBpbiB0aGUgZm9ybSBvZiB1c2VyLWFn ZW50IChicm93c2VyKSBjb2RlIGFzIG9wcG9zZSB0byBhbiBvdmVyLXRoZS13aXJlIHByb3RvY29s LiAgIFRoZSAqb25seSogd2F5IHRoYXQgSSBmaWd1cmVkIG91dCB0aGF0IFNTRSBzdGFydHMgd2l0 aCBhIEdFVCByZXF1ZXN0IHdhcyBieSB1c2luZyB3aXJlc2hhcmsuICBGb3IgV2ViIE5vdGlmaWNh dGlvbnMsIEnigJltIHVuc3VyZSBpZiBpdCBidWlsZHMgb24gdG9wIG9mIFNTRSBvciBXZWJTb2Nr ZXQsIG9yIGlmIGl0IGlzIGFub3RoZXIgcHJvdG9jb2wgYWx0b2dldGhlci4NCg0KS2VudA0KDQoN Cg0KDQoNCk9uIDEwLzIzLzE1LCA3OjQzIEFNLCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgTGFkaXNs YXYgTGhvdGthIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FA bmljLmN6PiB3cm90ZToNCg0KPkhpLA0KPg0KPnBlcmhhcHMgdGhpcyBtaWdodCBiZSBvZiBpbnRl cmVzdCB0byBSRVNUQ09ORj8NCj4NCj5odHRwOi8vd3d3LnczLm9yZy9UUi8yMDE1L1JFQy1ub3Rp ZmljYXRpb25zLTIwMTUxMDIyLw0KPg0KPkxhZGENCj4NCj4tLQ0KPkxhZGlzbGF2IExob3RrYSwg Q1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPg0KPg0KPg0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+TmV0Y29uZiBtYWlsaW5n IGxpc3QNCj5OZXRjb25mQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mDQo= From nobody Fri Oct 23 05:25: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 BFBDC1B3591 for ; Fri, 23 Oct 2015 05:25:41 -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 fMcXHBe5gBTj for ; Fri, 23 Oct 2015 05:25:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06C81B3598 for ; Fri, 23 Oct 2015 05:25:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 26902F60; Fri, 23 Oct 2015 14:25:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id o8v5mQZ8adje; Fri, 23 Oct 2015 14:25:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Oct 2015 14:25:37 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 806D02004E; Fri, 23 Oct 2015 14:25:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DuPNTGMOZE-o; Fri, 23 Oct 2015 14:25:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C0EB2003B; Fri, 23 Oct 2015 14:25:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BAD5A38648F1; Fri, 23 Oct 2015 14:25:34 +0200 (CEST) Date: Fri, 23 Oct 2015 14:25:33 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20151023122533.GA32540@elstar.local> Mail-Followup-To: Ladislav Lhotka , NETCONF References: <8535BDDF-C7EF-4D50-8A84-C4D88EF51E1C@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8535BDDF-C7EF-4D50-8A84-C4D88EF51E1C@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETCONF Subject: Re: [Netconf] web 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, 23 Oct 2015 12:25:41 -0000 Hi, I suggest to look instead closer into HTTP/2. /js On Fri, Oct 23, 2015 at 01:43:06PM +0200, Ladislav Lhotka wrote: > Hi, > > perhaps this might be of interest to RESTCONF? > > http://www.w3.org/TR/2015/REC-notifications-20151022/ > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > 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 Oct 23 07:25: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 B82861A1A7D; Fri, 23 Oct 2015 07:25:42 -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 0wgyJiAT1G3c; Fri, 23 Oct 2015 07:25:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6301A1A76; Fri, 23 Oct 2015 07:25: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.306.13; Fri, 23 Oct 2015 14:25:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Fri, 23 Oct 2015 14:25:35 +0000 From: Kent Watsen To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHRCkk5+GfvZN93g0WK01hCV3RAd552ax0AgABMfgCAAi4egA== Date: Fri, 23 Oct 2015 14:25:34 +0000 Message-ID: References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> <8F4A49AE-1160-4685-B878-39A087496FDF@juniper.net> <562836EE.40904@cs.tcd.ie> In-Reply-To: <562836EE.40904@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB457; 5:+oyvmVy9rOBwA0kY77HEVf+r9bRM0JNGd0R3OnLSOOUDXs58WgeIsDPBHN1GssyrRty25Ew92TYwPFyT+oIIYqTB0J3TMmlBn6yJ5JFUQup+wb13abbr0Srn7SoXWs1eFfBsM7y/mPSugFSTsX/+nQ==; 24:xoAh8Gpzj3gF7nr3hYpCscT9J8kGodSkU2ahDsA3xVjCfY3s9GTknYhq14heZTRDPslGk012c0zfUJvKB74Y7N6oJpEMJ/Nn/ApTqOmePyY=; 20:b2b4nChK7Jju2wbZ9wh3Et3ujS17DimJA6mGodNKlsPAOsQMDuxhjB61/IaenPiusU9Ai0OdrN8AYENukLs9DQ== 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)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026); SRVR:CO1PR05MB457; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB457; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(40224003)(43784003)(54094003)(76104003)(10400500002)(81156007)(76176999)(551544002)(92566002)(106356001)(106116001)(99286002)(86362001)(4001350100001)(97736004)(33656002)(5001770100001)(36756003)(50986999)(66066001)(54356999)(82746002)(2950100001)(122556002)(2900100001)(189998001)(5001960100002)(83506001)(5007970100001)(102836002)(5002640100001)(101416001)(105586002)(5004730100002)(83716003)(230783001)(19580395003)(5008740100001)(15975445007)(87936001)(40100003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <69B0DB96AFB2E34CAC7195FE17C68CE0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 14:25:34.9557 (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-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 14:25:42 -0000 DQpIaXlhIFN0ZXBoZW4hDQoNCg0KDQoNCg0KDQo+PiANCj4+IA0KPj4+ICgxKSBIVFRQIEF1dGg6 IGlzIGl0IG9rIGZvciBhIGNsaWVudCB0byBzZW5kIGl0J3MgZS5nLiBiYXNpYyBhdXRoDQo+Pj4g Y3JlZGVudGlhbCB0byBhbnkgb2YgdGhlIHNlcnZlcnMgdGhhdCB0aGUgY2xpZW50IGNhbiB2YWxp ZGF0ZT8NCj4+PiBJLmUuLCBpcyBhbiBhZGRpdGlvbmFsIGxldmVsIG9mIHBpbm5pbmcgbmVlZGVk IGZvciB0aGlzPyBUaGF0IHdvdWxkDQo+Pj4gYmUgYSBuZXcgZm9ybSBvZiBwaW5uaW5nIGFuZCBp cyBub3QgZGVmaW5lZCBmb3IgZWl0aGVyIFRMUyBvciBTU0gNCj4+PiBhZmFpay4gVGhhdCBjb3Vs ZCBhbHNvIGJlIGRvbmUgaW4gdmFyaW91cyB3YXlzIGFuZCBJJ20gbm90IHN1cmUgaWYNCj4+PiB0 aG9zZSBtaWdodCBoYXZlIGludGVyb3BlcmFiaWxpdHkgY29uc2VxdWVuY2VzLiBPciBwZXJoYXBz IGlmIG5vdA0KPj4+IGRvaW5nIHRoYXQsIHRoaXMgZHJhZnQgc2hvdWxkIHNheSBzb21ldGhpbmcg YWJvdXQgYSBuZWVkIGZvcg0KPj4+IHN0cm9uZ2VyIGNyZWRlbnRpYWxzIGVzcC4gZm9yIGJhc2lj IGF1dGguIERpZCB0aGUgV0cgY29uc2lkZXINCj4+PiB0aGlzPw0KPj4gDQo+PiBJcyB0aGlzIGNv bW1lbnQgbmV3IHRvIGNhbGwgaG9tZSwgb3IgaXQgaXMgcmVhbGx5IGEgY29tbWVudCBvbiB0aGUN Cj4+IFJFU1RDT05GIGRyYWZ0PyAgU3BlY2lmaWNhbGx5LCBwbGVhc2Ugc2VlIHRoaXMgc2VjdGlv bjoNCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtcmVz dGNvbmYtMDgjc2VjdGlvbi0yLjUNCj4NCj5JJ2Qgc2F5IGl0IHBlcmhhcHMgYWZmZWN0cyBib3Ro LiBCdXQgY291bGQgYXJndWFibHkgYmUgYSBicm9hZGVyDQo+aXNzdWUuIFNlZSBiZWxvdy4NCg0K U3VyZSwgYnV0IHRoaXMgZHJhZnQgaGFzIGEgTm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGUgUkVT VENPTkYgZHJhZnQgZm9yIHVzZXIgYXV0aC4gIFVubGVzcyB5b3XigJlyZSBzYXlpbmcgdGhhdCDi gJxjYWxsIGhvbWXigJ0gaXMgaW50cm9kdWNpbmcgYSBuZXcvc3RyaWN0ZXIgcmVxdWlyZW1lbnQs IHdvdWxkbuKAmXQgaXQgYmUgYmVzdCB0byBub3QgcmVwZWF0IHRleHQgZnJvbSBhIG5vcm1hdGl2 ZSByZWZlcmVuY2U/DQoNCg0KDQoNCj4+ICBBbnN3ZXJpbmcgeW91ciBxdWVzdGlvbnM6DQo+PiAN Cj4+PiBpcyBpdCBvayBmb3IgYSBjbGllbnQgdG8gc2VuZCBpdCdzIGUuZy4gQmFzaWMgYXV0aCBj cmVkZW50aWFsIHRvDQo+Pj4gYW55IG9mIHRoZSBzZXJ2ZXJzIHRoYXQgdGhlIGNsaWVudCBjYW4g dmFsaWRhdGU/DQo+PiANCj4+IFllcy4NCj4NCj5JY2sgLSBhdCBsZWFzdCwgdGhhdCdzIGlja2t5 IGlmIG9ubHkgdGhlIGJhc2ljLWF1dGggcmVhbG0gaXMgdXNlZA0KPnRvIHNlbGVjdCB0aGUgcGFz c3dvcmQgdG8gc2VuZCBvdXQgKGVmZmVjdGl2ZWx5IGluIGNsZWFyKS4gQm90aA0KPmJhc2ljIGFu ZCBkaWdlc3QgSSB0aGluayB0YWxrIGFib3V0IGEgdXNlciBzZWxlY3RpbmcgdGhlIHBhc3N3b3Jk DQo+dG8gaW5wdXQgYmFzZWQgb24gdGhlIHJlYWxtLCBidXQgaGVyZSB5b3UncmUgYXV0b21hdGlu ZyB0aGF0IGJhc2VkDQo+b24gYSBwYWNrZXQgcmVjZWl2ZWQgb3ZlciB0aGUgbmV0d29yay4NCg0K Tm90IHRydWUuICBDYWxsIGhvbWUgKm9ubHkqIGltcGFjdHMgdGhlIFRDUCBwcm90b2NvbCBsYXll ci4gIFRoZSBUTFMgYW5kIEhUVFAgcHJvdG9jb2wgbGF5ZXJzIGFyZSB1bmNoYW5nZWQuICBJdCBp cyBzdGlsbCB0aGUgY2FzZSB0aGF0IHRoZSBjbGllbnQgKE5NUykgc2VuZHMgYW4gSFRUUCByZXF1 ZXN0IChHRVQpIGFuZCwgaWYgaW5hZGVxdWF0ZSBjcmVkZW50aWFscyBhcmUgcHJvdmlkZXMsIHRo ZSBzZXJ2ZXIgKGRldmljZSkgc2VuZHMgYSBXV1ctQXV0aGVudGljYXRlIGNoYWxsZW5nZSwgaW5j bHVkaW5nIHRoZSDigJhyZWFsbeKAmSwgYXMgUkVRVUlSRUQgYnkgUkZDIDc2MTcuDQoNCg0KDQo+ V2hhdCBlbnN1cmVzIGEgY2xpZW50IGhlcmUgbmV2ZXIgc2VuZHMgdGhlIHBhc3N3b3JkIHRvIGFu IGluY29ycmVjdA0KPnNlcnZlcj8gU2F5IGEgY2xpZW50IGhhcyB0d28gc2VydmVycyAoQSBhbmQg QikgdGhhdCBjYW4gY2FsbC1ob21lDQo+dG8gdGhlIGNsaWVudCwgYW5kIEEgY2hlYXRzIG9uIEIg YnkgdXNpbmcgQidzIHJlYWxtICh3aGljaCBpcyBub3QNCj5jb25zaWRlcmVkIGEgc3Ryb25nIHNl Y3JldCkgaW4gQSdzIFdXVy1BdXRoZW50aWNhdGU/DQo+DQo+Tm93IGlmIHRoYXQgaXMgYSByZWFs IGlzc3VlLCBJIHRoaW5rIHdlIGNvdWxkIGFyZ3VlIHRoYXQgYmFzaWMgYW5kDQo+ZGlnZXN0LCB1 bm1vZGlmaWVkLCBhcmUganVzdCBub3Qgc2FmZSBoZXJlLiBJJ20gbm90IHN1cmUgd2hhdA0KPm1v ZGlmaWNhdGlvbiBjb3VsZCB1c2VmdWxseSBiZSBkb25lIGlmIG9uZSBpcyBuZWVkZWQgb3RoZXIg dGhhbg0KPm1heWJlIHBpbm5pbmcgdGhlIHBhc3N3b3JkIHRvIHRoZSBzZXJ2ZXIgaWRlbnRpdHku IEhhdmluZyBqdXN0IG5vdw0KPnJlLXJlYWQgUkZDNzYxNyBJIHRoaW5rIHdlIG1heSBuZWVkIHRv IHRhY2tsZSB0aGF0IGlzc3VlIHNvbWVob3cNCj5hcyA3NjE3IGVudmlzYWdlcyB0aGUgdXNlciBu b3QgdHlwaW5nIHRoZSBwYXNzd29yZCBhcyB0aGUgY29udHJvbA0KPmhlcmUuDQo+DQo+KE9yIHdl IGNvdWxkIHNob3J0LWNpcmN1aXQgdGhpcyBpcyB0aGUgd2cgd2VyZSB3aWxsaW5nIHRvIGdpdmUN Cj51cCBvbiB1c2Ugb2YgY3JhcHB5IGh0dHAgYXV0aCBzY2hlbWVzIGxpa2UgYmFzaWMgYW5kIG9u bHkgYWxsb3cNCj5iZXR0ZXIgdGhpbmdzIC0gZG8geW91IHJlYWxseSByZWFsbHkgbmVlZCB0aGlz IHNvIGJhZGx5IGFzIHRvDQo+cHV0IHRoZXNlIGRldmljZXMgYXQgcmlzaz8pDQoNCkkgd29uZGVy IGlmIG1heWJlIGFuIGFzcGVjdCBvZiB0aGlzIGRyYWZ0IGlzIGJlaW5nIG92ZXJsb29rZWQuICBU byByZWNhcCwganVzdCBhcyB3aXRoIGEgbm9ybWFsIFJFU1RDT05GIChIVFRQUykgY29ubmVjdGlv biwgd2hlbiBhIGNhbGwgaG9tZSBjb25uZWN0aW9uIGlzIGJlaW5nIGVzdGFibGlzaGVkLCB0aGUg UkVTVENPTkYgc2VydmVyIHdpbGwgcHJlc2VudCBpdHMgc2VydmVyIGNlcnRpZmljYXRlIGFuZCB0 aGUgVExTIGNyeXB0byBzZXNzaW9uIHdpbGwgYmUgZXN0YWJsaXNoZWQgKmJlZm9yZSogQmFzaWMv RGlnZXN0IGF1dGguICAgVGhhdCBpcywgdGhlIFJFU1RDT05GIGNsaWVudCB3b3VsZCBOT1Qgc2Vu ZCBpdHMgQmFzaWMvRGlnZXN0IGF1dGggdG8gYSBzZXJ2ZXIgaWYgaXQgY2Fu4oCZdCBmaXJzdCBh dXRoZW50aWNhdGUgdGhlIHNlcnZlciAodmlhIGl0cyBzZXJ2ZXIgY2VydGlmaWNhdGUpLiAgSW4g dGhpcyBkcmFmdCwgdGhpcyBpcyBjYXB0dXJlZCBieSBDNS1DNyAoc2VlIGJlbG93KS4gIFBsZWFz ZSBub3RlIHRoYXQg4oCccHJvY2VlZHMgYXMgbm9ybWFs4oCdIGluIEM3IGJlbG93IGlzIHdoZW4g dGhlIEJhc2ljIC9EaWdlc3QgYXV0aCB3b3VsZCBvY2N1cjoNCg0KICBDNSAgQXMgcGFydCBvZiBl c3RhYmxpc2hpbmcgYW4gU1NIIG9yIFRMUyBjb25uZWN0aW9uLCB0aGUgTkVUQ09ORi8NCiAgICAg UkVTVENPTkYgY2xpZW50IE1VU1QgdmFsaWRhdGUgdGhlIHNlcnZlcidzIHByZXNlbnRlZCBob3N0 IGtleSBvcg0KICAgICBjZXJ0aWZpY2F0ZS4gIFRoaXMgdmFsaWRhdGlvbiBNQVkgYmUgYWNjb21w bGlzaGVkIGJ5IGNlcnRpZmljYXRlDQogICAgIHBhdGggdmFsaWRhdGlvbiBvciBieSBjb21wYXJp bmcgdGhlIGhvc3Qga2V5IG9yIGNlcnRpZmljYXRlIHRvIGENCiAgICAgcHJldmlvdXNseSB0cnVz dGVkIG9yICJwaW5uZWQiIHZhbHVlLg0KDQogIEM2ICBJZiBjZXJ0aWZpY2F0ZSBwYXRoIHZhbGlk YXRpb24gaXMgdXNlZCwgdGhlIE5FVENPTkYvUkVTVENPTkYNCiAgICAgY2xpZW50IE1VU1QgZW5z dXJlIHRoYXQgdGhlIGNlcnRpZmljYXRlIGhhcyBhIHZhbGlkIGNoYWluIG9mDQogICAgIHRydXN0 IHRvIGEgcHJlY29uZmlndXJlZCB0cnVzdCBhbmNob3IgYW5kIHRoYXQgdGhlIGNlcnRpZmljYXRl DQogICAgIGVuY29kZXMgYW4gImlkZW50aWZpZXIiIFtSRkM2MTI1XSB0aGF0IHRoZSBjbGllbnQg aGFkIGF3YXJlbmVzcw0KICAgICBvZiBwcmlvciB0byB0aGUgY29ubmVjdGlvbiBhdHRlbXB0LiAg SG93IGlkZW50aWZpZXJzIGFyZSBlbmNvZGVkDQogICAgIGluIGNlcnRpZmljYXRlcyBNQVkgYmUg ZGV0ZXJtaW5lZCBieSBhIHBvbGljeSBhc3NvY2lhdGVkIHdpdGggdGhlDQogICAgIGNlcnRpZmlj YXRlJ3MgdHJ1c3QgYW5jaG9yLiAgRm9yIGluc3RhbmNlLCBhIGdpdmVuIHRydXN0IGFuY2hvcg0K ICAgICBtYXkgYmUga25vd24gdG8gb25seSBzaWduIElEZXZJRCBjZXJ0aWZpY2F0ZXMgW1N0ZC04 MDIuMUFSLTIwMDldDQogICAgIGhhdmluZyBhIHVuaXF1ZSBpZGVudGlmaWVyIChlLmcuLCBzZXJp YWwgbnVtYmVyKSBpbiB0aGUgWC41MDkNCiAgICAgY2VydGlmaWNhdGUncyAiQ29tbW9uTmFtZSIg ZmllbGQuDQoNCiAgQzcgIEFmdGVyIHRoZSBzZXJ2ZXIncyBob3N0IGtleSBvciBjZXJ0aWZpY2F0 ZSBpcyB2YWxpZGF0ZWQsIHRoZSBTU0gNCiAgICAgb3IgVExTIHByb3RvY29sIHByb2NlZWRzIGFz IG5vcm1hbCB0byBlc3RhYmxpc2ggYSBTU0ggb3IgVExTDQogICAgIGNvbm5lY3Rpb24uDQoNCg0K UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoZXJlIHdhcyBhIG1pc3VuZGVyc3RhbmRpbmcgaGVyZSwg b3IgaWYgSeKAmW0gYWx0b2dldGhlciBtaXNzaW5nIHNvbWV0aGluZyBpbiB5b3VyIGNvbW1lbnQh DQoNCg0KDQoNCg0KDQoNCg0KPj4gDQo+Pj4gSS5lLiwgaXMgYW4gYWRkaXRpb25hbCBsZXZlbCBv ZiBwaW5uaW5nIG5lZWRlZCBmb3IgdGhpcz8NCj4+IA0KPj4gTm90IHRoYXQgSeKAmW0gYXdhcmUg b2YuDQo+DQo+V2UgbWF5IHdhbnQgdG8gY2hhdCBhYm91dCB0aGF0IG1vcmUuDQoNClRoaXMgaXMg dGllZCB0byB0aGUgYWJvdmUgY29tbWVudC4NCg0KDQoNCg0KPj4gDQo+PiANCj4+PiBEaWQgdGhl IFdHIGNvbnNpZGVyIHRoaXM/DQo+PiANCj4+IA0KPj4gTm8sIGJ1dCBLYXRobGVlbiBtYWRlIGEg Z29vZCBwb2ludCB0byByZWZlcmVuY2UgUkZDcyA3NjE1IGFuZCA3NjE2LA0KPj4gd2hpY2ggSSB3 aWxsIGRvLiAgIFN0aWxsLCBJIHRoaW5rIHRoaXMgY29tbWVudCBpcyBtb3JlIG9uIHRoZQ0KPj4g UkVTVENPTkYgZHJhZnQgdGhhbiB0aGlzIG9uZS4gIFllcz8NCj4NCj5Tb3JyeSBubywgSSBkb24n dCB0aGluayBzby4NCg0KQWdhaW4sIHRoaXMgaXMgdGllZCB0byB0aGUgYWJvdmUgY29tbWVudC4g ICBJ4oCZbSBob3BpbmcgdGhhdCB0aGlzIGlzIGEgc2ltcGxlIG1pc3VuZGVyc3RhbmRpbmcgd3J0 IGhvdyB0aGUgUkVTVENPTkYvSFRUUFMgY2xpZW50IGF1dGhzIHRoZSBzZXJ2ZXLigJlzIFRMUyBj ZXJ0aWZpY2F0ZSAqYmVmb3JlKiBwYXNzaW5nIEJhc2ljL0RpZ2VzdCBhdXRoIGNyZWRlbnRpYWxz Li4uDQoNCg0KDQoNCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4+ICgyKSBUaGUgc2VjZGlyIHJldmll dyBbMV0gY2FsbHMgb3V0IGlzc3VlcyByZWxhdGVkIHRvIFRMUy1QU0sgYW5kDQo+Pj4gKEkgZ3Vl c3MgYWxzbykgYmFyZSBrZXlzLiBJIHRoaW5rIGl0J2QgYmUgZ29vZCB0byBiZSBzcGVpZmljIGFz IHRvDQo+Pj4gd2hlaGVyIG9yIGhvdyB0aG9zZSBhcmUgdG8gYmUgc3VwcG9ydGVkIGhlcmUuIElm IHlvdSBhcmUgZ29pbmcgdG8NCj4+PiBzYXkgdGhvc2UgYXJlIHN1cHBvcnRlZCwgdGhlbiBJIHN1 c3BlY3Qgc29tZSBhZGRpdGlvbmFsIHRleHQgaXMNCj4+PiBuZWVkZWQuIEtlbnQncyBhbnN3ZXIg dG8gdGhhdCAod2hpY2ggd2FzICJzZWUgUkZDNzU4OSIgYXMgSSByZWFkDQo+Pj4gaXQpIGRvZXNu J3QgcXVpdGUgZG8gaXQgaGVyZSBJIHRoaW5rLiB0aGF0IHNheXMgdGhhdCBjZXJ0aWZpY2F0ZXMN Cj4+PiBtdXN0IGJlIHN1cHBvcnRlZCAod2hpY2ggaXMgZmluZSkgYnV0IGRvZXNuJ3Qgc2F5IHRo YXQgVExTLVBTSyBvcg0KPj4+IGJhcmUga2V5cyBjYW4gb3IgY2Fubm90IGJlIHN1cHBvcnRlZC4N Cj4+PiANCj4+PiBbMV0gDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9zZWNkaXIvY3VycmVudC9tc2cwNjA4Ny5odG1sDQo+PiANCj4+IA0KPj4gSnVlcmdlbiBtZW50 aW9uZWQgdGhhdCBQU0sgd2FzIGRlbGliZXJhdGVseSB0YWtlbiBvdXQgb2YgcmZjNzU4OSAtDQo+ PiBhbmQgdGhpcyBkcmFmdCBoYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGl0Lg0KPj4gDQo+ PiBTZXBhcmF0ZWx5LCB5b3UganVzdCBub3cgd3JvdGUgdG8gSnVlcmdlbjogIkknbSBmaW5lIHdp dGggdGhhdA0KPj4gZGVjaXNpb24uIFRoZSBkaXNjdXNzIGlzIG9ubHkgYWJvdXQgd2hldGhlciBv ciBub3QgaXQncyBzdWZmaWNpZW50bHkNCj4+IHdlbGwgZG9jdW1lbnRlZCB0aGF0IHlvdSBkb24n dCB3YW50IGZvbGtzIGRvaW5nIGJhcmUga2V5cy7igJ0NCj4+IA0KPj4gV291bGQgdGhhdCBiZSBp biB0aGlzIGRyYWZ0LCBvciBzaG91bGQgaXQgYmUgaW4gUlJDNzU4OT8NCj4NCj5TaG93IG1lIHdo ZXJlIGl0IHNheXMgImRvbid0IGRvIGJhcmUga2V5cyIgYW5kIEknbGwgYW5zd2VyIHlvdTstKQ0K PkkgdGhpbmsgaXQgcGVyaGFwcyBuZWVkcyB0byBiZSBoZXJlLg0KDQoNCkkgbWF5IG5lZWQgeW91 ciBoZWxwIGhlcmUsIGJ1dCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYmFyZSBrZXlzIChhbmQg UFNLKSBhcmUgYWx0ZXJuYXRpdmVzIHRvIFBLSS4gIFNvIGlmIHdlIGhhdmUgYSBzdGF0ZW1lbnQg bGlrZSDigJx5b3UgTVVTVCBkbyBQS0nigJ0sIGRvZXMgaXQgbm90IHByZWNsdWRlIHRoZSB1c2Ug b2YgYmFyZSBrZXlzPw0KDQpCb3RoIFJGQyA3NTg5IGFuZCBkcmFmdC1pZXRmLW5ldGNvbmYtcmVz dG9uZiAod2hpY2ggdGhlIGNhbGwtaG9tZSBkcmFmdCBkZXBlbmRzIG9uKSByZXF1aXJlIFguNTA5 IGNlcnRpZmljYXRlcy4gICBUaGVzZSBzdGF0ZW1lbnRzIGNhbiBiZSBmb3VuZCBoZXJlOg0KDQog IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTg5I3NlY3Rpb24tNToNCg0KICAiQm90 aCBwZWVycyBNVVNUIHVzZSBYLjUwOSBjZXJ0aWZpY2F0ZSBwYXRoIHZhbGlkYXRpb24gW1JGQzUy ODBdIHRvDQogICB2ZXJpZnkgdGhlIGludGVncml0eSBvZiB0aGUgY2VydGlmaWNhdGUgcHJlc2Vu dGVkIGJ5IHRoZSBwZWVyLuKAnQ0KDQpBbmQgaGVyZToNCg0KICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLTA4I3NlY3Rpb24tMi4yOg0KDQog ICJDb25zaXN0ZW50IHdpdGggdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgWC41MDl2MyBjZXJ0aWZpY2F0 ZXMgZm9yIE5FVENPTkYNCiAgIG92ZXIgVExTIFtkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJp cy0xMF0sIHVzZSBvZiBjZXJ0aWZpY2F0ZXMgaW4NCiAgIFJFU1RDT05GIGlzIGFsc28gbGltaXRl ZCB0byBYLjUwOXYzIGNlcnRpZmljYXRlcy4iDQoNCg0KDQoNClNvIEnigJltIG5vdCBzdXJlLCBk b2VzIHRoaXMgc3VmZmljaWVudGx5IGxvY2sgdGhlIHVzZSBvZiBUTFMgKGZvciBib3RoIE5FVENP TkYgYW5kIFJFU1RDT05GKSB0byBYLjUwOSBjZXJ0aWZpY2F0ZXM/ICAtIG9yIGlzIG1vcmUgdGV4 dCBuZWVkZWQ/DQoNCg0KDQoNCg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+Pj4gKDMpIENvbnNpZGVy IHptYXAuIFdoZW4gdGhpcyBpcyBkZXBsb3llZCwgd2hhdCdsbCBiZSB0aGUgZWZmZWN0IG9mDQo+ Pj4gc3VydmV5cyB0aGF0IGZpbmdlcnByaW50IGFsbCBvZiB0aGUgZGV2aWNlcyBvbiB0aGUgdmlz aWJsZSBJbnRlcm5ldA0KPj4+IHdobyBpbXBsZW1lbnQgdGhpcyBwcm90b2NvbD8gRGlkIHRoZSBX RyBjb25zaWRlciB0aGF0PyBJJ20gbm90IHN1cmUNCj4+PiBvZiB0aGUgaW1wYWN0LCBpZiBhbnks IGJ1dCBpdCBjb3VsZCBiZSBnb29kIGlmIHRoZXJlJ3MgYSB3YXkgdG8NCj4+PiBoZWxwIGRlcGxv eW1lbnRzIGVuZCB1cCBsZXNzIHZ1bG5lcmFibGUgdG8gZmluZ2VycHJpbnRpbmcgKGFuZCB0aGUN Cj4+PiBlbnN1aW5nIGV4cG9zdXJlIHRvIHVucGF0Y2hlZCB2dWxucykuDQo+PiANCj4+IFRoZSBX RyBkaWQgbm90IGRpc2N1c3MgdGhpcy4NCj4+IA0KPj4gSSBrbm93IHRoYXQgeW91IG1lbnRpb24g em1hcCBieSBleGFtcGxlLCBidXQgcmVhZGluZyBvbiBpdCBJIHNlZSB0aGF0DQo+PiBpcyBzZW5k cyBhIFNZTiBtZXNzYWdlLCBhbmQgdGVzdHMgaWYgYSBTWU4tQUNLIGlzIHJldHVybmVkLiAgSSBu ZXZlcg0KPj4gY29tcGxldGVzIHRoZSBUQ1AgY29ubmVjdGlvbiBhbmQsIGluIGZhY3Qgc2VuZHMg YSBSU1QuDQo+DQo+em1hcCBoYXMgYmVlbiB1c2VkIGZvciBhbGwgc29ydHMgb2YgbW9yZSBjb21w bGV4IGhhbmRzaGFrZXMuDQo+DQo+PiANCj4+IFRoaXMgY29uY2VybiBzZWVtcyB0byBiZSB0cnVl IGZvciBhbnkgcHJvdG9jb2wsIG5vdCBzcGVjaWZpYyB0bw0KPj4gY2FsbC1ob21lLiAgDQo+DQo+ SSB0aGluayBhIHJvbGUtY2hhbmdlIGxpa2UgdGhpcyBtYWtlcyBpdCBmYXIgbW9yZSBub3RhYmxl Lg0KPj5TdGlsbCwgSSBjb3VsZCBhZGQgdG8gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNl Y3Rpb24NCj4+IHNvbWV0aGluZyBsaWtlOg0KPj4gDQo+PiBORVRDT05GL1JFU1RDT05GIGNsaWVu dHMgaGF2aW5nIGEgb3BlbiBwb3J0IGZvciBjYWxsIGhvbWUgc2hvdWxkIGJlDQo+PiBhd2FyZSB0 aGF0IG5ldHdvcmsgc2Nhbm5pbmcgdG9vbHMgYXJlIG1hbnkgdGltZXMgdXNlZCB0byBmaW5nZXJw cmludA0KPj4gaG9zdHMgd2l0aCB0aGUgaG9wZSBvZiBmaW5kaW5nIHVucGF0Y2hlZCB2dWxuZXJh YmlsaXRpZXMuICBFZmZvcnQNCj4+IHNob3VsZCBiZSBtYWRlIHRvIGxpbWl0IGV4cG9zdXJlIG9u bHkgdG8gbmVlZGluZyB0byBhY2Nlc3MgdGhlDQo+PiBORVRDT05GL1JFU1RDT05GIGNsaWVudC4N Cj4+IA0KPj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+DQo+QnV0IHdoYXQgZWZmb3J0cyBjYW4gb25l IG1ha2UgYW5kIHdoYXQgaXMgdGhlIGltcGFjdCBvZiBub3QgbWFraW5nDQo+dGhvc2UgKGZvciB0 aGlzIHByb3RvY29sKS4gVGhlIHJvbGUtY2hhbmdlIGhlcmUgaXMgYSBtaW5vciB0cmFuc3BvcnQN Cj5jaGFuZ2UgYnV0IGRvaW5nIHRoYXQgZm9yIHB1YmxpY2x5IHJlYWNoYWJsZSBob3N0cyBoYXMg YSBsb3Qgb2YNCj5jb25zZXF1ZW5jZXMuDQoNCkkgaG9wZSB0aGF0IHRoaXMgd2lsbCBiZSBkaXNj dXNzZWQgb24gdGhlIFRMUyBXRyBhbmQgb3BlbnNzaCBsaXN0cy4gIEkgaW1hZ2luZSB0aGF0IGl0 IG1heSBjdWxtaW5hdGUgaW4gYmV0dGVyIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGxhbmd1YWdl IGluIHRoaXMgZHJhZnQuDQoNCg0KDQoNCg0KPj4+LSBPQ1NQOiBhbnkgaXNzdWUgdGhlcmU/IGlz IGl0IG1hbmRhdG9yeSB0byB1c2UgaW4gYW55IGNhc2UgZm9yDQo+Pj4gVExTPw0KPj4gDQo+PiBB Z2FpbiwgdGhpcyBkcmFmdCBoYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBSRkMgNzU4OSwg d2hpY2gNCj4+IHNheXM6DQo+PiANCj4+IEJvdGggcGVlcnMgTVVTVCB1c2UgWC41MDkgY2VydGlm aWNhdGUgcGF0aCB2YWxpZGF0aW9uIFtSRkM1MjgwXSB0byANCj4+IHZlcmlmeSB0aGUgaW50ZWdy aXR5IG9mIHRoZSBjZXJ0aWZpY2F0ZSBwcmVzZW50ZWQgYnkgdGhlIHBlZXIuDQo+PiANCj4+IA0K Pj4gQW5kIFJGQzUyODAgZGVmaW5lcyBjZXJ0aWZpY2F0ZSBwYXRoIHZhbGlkYXRpb24gYXMgaW5j bHVkaW5nDQo+PiByZXZvY2F0aW9uIGNoZWNraW5nLiAgDQo+DQo+Tm8uIFJldm9jYXRpb24gY2hl Y2tpbmcgaXMgb3B0aW9uYWwgaW4gNTI4MC4gKFNvcnJ5Oy0pDQoNCk9LLCBmYWlyIHBvaW50LiAg IFRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uIHRoZW4sIG5laXRoZXIgT0NTUCBub3IgQ1JMIHJldm9j YXRpb24gY2hlY2tpbmcgaXMgcmVxdWlyZWQgKGJ1dCBzZWUgbmV4dCBjb21tZW50IGJlbG93KS4N Cg0KDQoNCj4+IFNvIGJvdGggQ1JMIGFuZCBPU0NQIGFyZSBhdmFpbGFibGUsIGFuZCB3b3VsZA0K Pj4gYmUgdXAgdG8gdGhlIENBIHRvIHNwZWNpZnkgQ1JMIGRpc3RyaWJ1dGlvbiBwb2ludHMgb3Ig YXV0aG9yaXR5IGluZm8NCj4+IGFjY2VzcyBpbiB0aGVpciBjZXJ0aWZpY2F0ZXMuDQo+DQo+SWYg eW91IHdhbnQgY2xpZW50cyBoZXJlIHRvIHN1cHBvcnQgc3RhdHVzIGNoZWNraW5nIEkgdGhpbmsg eW91IG5lZWQNCj50byBzYXkgdGhhdCBvciByZWZlcmVuY2Ugc29tZXRoaW5nIHRoYXQgc2F5cyB0 aGF0Lg0KDQpJdOKAmXMgY2VydGFpbmx5IHRydWUgdGhhdCB3ZSB3b3VsZCAqd2FudCogTkVUQ09O Ri9SRVNUQ09ORiBjbGllbnRzIHRvIGRvIHJldm9jYXRpb24gY2hlY2tpbmcsIGJ1dCB3ZSBjYW5u b3QgbWFuZGF0ZSBpdCBhcyBzb21lIGRlcGxveW1lbnRzIGFyZSBvbiBwcml2YXRlIG5ldHdvcmtz IGFuZCBoZW5jZSB1bmFibGUgdG8gZG93bmxvYWQgYSBDUkwgb3IgYWNjZXNzIGFuIE9DU1Agc2Vy dmVyLg0KDQpUaGF0IHNhaWQsIEkgYmVsaWV2ZSB0aGF0IEM1IGNvdWxkIGJlIGVuaGFuY2VkIHdp dGggYSBTSE9VTEQgYW5kIGEgTVVTVCBhcyBmb2xsb3dzIChzZWUgbGFzdCB0d28gc2VudGVuY2Vz KS4gIFdvdWxkIHRoaXMgdXBkYXRlIGFkZHJlc3MgeW91ciBjb25jZXJuPw0KDQpPTEQ6DQoNCiAg IEM1ICBBcyBwYXJ0IG9mIGVzdGFibGlzaGluZyBhbiBTU0ggb3IgVExTIGNvbm5lY3Rpb24sIHRo ZSBORVRDT05GLw0KICAgICAgUkVTVENPTkYgY2xpZW50IE1VU1QgdmFsaWRhdGUgdGhlIHNlcnZl cidzIHByZXNlbnRlZCBob3N0IGtleSBvcg0KICAgICAgY2VydGlmaWNhdGUuICBUaGlzIHZhbGlk YXRpb24gTUFZIGJlIGFjY29tcGxpc2hlZCBieSBjZXJ0aWZpY2F0ZQ0KICAgICAgcGF0aCB2YWxp ZGF0aW9uIG9yIGJ5IGNvbXBhcmluZyB0aGUgaG9zdCBrZXkgb3IgY2VydGlmaWNhdGUgdG8gYQ0K ICAgICAgcHJldmlvdXNseSB0cnVzdGVkIG9yICJwaW5uZWQiIHZhbHVlLg0KDQoNCk5FVzoNCg0K ICAgQzUgQXMgcGFydCBvZiBlc3RhYmxpc2hpbmcgYW4gU1NIIG9yIFRMUyBjb25uZWN0aW9uLCB0 aGUgTkVUQ09ORi8NCiAgICAgIFJFU1RDT05GIGNsaWVudCBNVVNUIHZhbGlkYXRlIHRoZSBzZXJ2 ZXIncyBwcmVzZW50ZWQgaG9zdCBrZXkgb3INCiAgICAgIGNlcnRpZmljYXRlLiBUaGlzIHZhbGlk YXRpb24gTUFZIGJlIGFjY29tcGxpc2hlZCBieSBjZXJ0aWZpY2F0ZQ0KICAgICAgcGF0aCB2YWxp ZGF0aW9uIG9yIGJ5IGNvbXBhcmluZyB0aGUgaG9zdCBrZXkgb3IgY2VydGlmaWNhdGUgdG8gYQ0K ICAgICAgcHJldmlvdXNseSB0cnVzdGVkIG9yICJwaW5uZWQiIHZhbHVlLiAgSWYgYSBjZXJ0aWZp Y2F0ZSBjb250YWlucw0KICAgICAgcmV2b2NhdGlvbiBjaGVja2luZyBpbmZvcm1hdGlvbiwgdGhl IE5FVENPTkYvUkVTVENPTkYgY2xpZW50DQogICAgICBTSE9VTEQgY2hlY2sgdGhlIHJldm9jYXRp b24gc3RhdHVzIG9mIHRoZSBjZXJ0aWZpY2F0ZS4gIElmIGl0IGlzDQoNCiAgICAgIGRldGVybWlu ZWQgdGhhdCBhIGNlcnRpZmljYXRlIGhhcyBiZWVuIHJldm9rZWQsIHRoZSBjbGllbnQgTVVTVA0K ICAgICAgaW1tZWRpYXRlbHkgY2xvc2UgdGhlIGNvbm5lY3Rpb24uDQoNCg0KDQoNClRoYW5rcyBh Z2FpbiwgYW5kIEkgYXBvbG9naXplIGlmIHRoaXMgdGhyZWFkIGlzIGJlZ2lubmluZyB0byBiZWNv bWUgbG9uZyAtIGhvcGVmdWxseSB3ZeKAmWxsIHN0YXJ0IGNsb3Npbmcgb3V0IHNvbWUgb2YgdGhl c2UgRElTQ1VTUyBwb2ludHMgc29vbiB0aG91Z2ggIDopDQoNCktlbnQNCg0KDQo= From nobody Fri Oct 23 07:49: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 0FACC1A1B96; Fri, 23 Oct 2015 07:49:51 -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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmSwN0vGcOMW; Fri, 23 Oct 2015 07:49:48 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 E25CA1A1BAE; Fri, 23 Oct 2015 07:49:47 -0700 (PDT) Received: by qkca6 with SMTP id a6so78355510qkc.3; Fri, 23 Oct 2015 07:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ViGOBrCfdHoWdtMnf78MlJyLydmpg+icJcBe0dBgpEc=; b=tGfVm/wD4i9NoKjfizBE1s6iH8lpmKSfYnCF2be/GQdH/q4FHnypbzU7tZoYummwNZ FBkfj0zQhAwiq1SEFFKtHRazVR7562/YjFPSX+JQ0ikczdgf5JmfdlbK23ZEau+0QHC8 3rFTUYMx4ndgLVo4A3Br1yDZvgRegFtn3E0DYH04d2+lSFz//f1tYxLwlcyReXZjDGma IXq2sWo+nWwDSuy3YJSQ9NP+hyiBVuaRmwYxPBtKHcbnBVe/5RJFTtt5APsacj/nJym0 i9p3va/kjaB1ml7P9OVKgMuIKcfgUypGts8abbYpl0wMZqgaW06f8b3F2PCnwXTtPGqV TA/w== X-Received: by 10.140.233.130 with SMTP id e124mr27248487qhc.79.1445611787064; Fri, 23 Oct 2015 07:49:47 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id 14sm7535185qhx.10.2015.10.23.07.49.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Oct 2015 07:49:46 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Fri, 23 Oct 2015 10:49:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> <8F4A49AE-1160-4685-B878-39A087496FDF@juniper.net> <562836EE.40904@cs.tcd.ie> To: Kent Watsen Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" , Stephen Farrell , The IESG Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 14:49:51 -0000 Sent from my iPhone > On Oct 23, 2015, at 10:25 AM, Kent Watsen wrote: >=20 >=20 > Hiya Stephen! >=20 >=20 >=20 >=20 >=20 >=20 >>>=20 >>>=20 >>>> (1) HTTP Auth: is it ok for a client to send it's e.g. basic auth >>>> credential to any of the servers that the client can validate? >>>> I.e., is an additional level of pinning needed for this? That would >>>> be a new form of pinning and is not defined for either TLS or SSH >>>> afaik. That could also be done in various ways and I'm not sure if >>>> those might have interoperability consequences. Or perhaps if not >>>> doing that, this draft should say something about a need for >>>> stronger credentials esp. for basic auth. Did the WG consider >>>> this? >>>=20 >>> Is this comment new to call home, or it is really a comment on the >>> RESTCONF draft? Specifically, please see this section: >>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-08#section-2.5 >>=20 >> I'd say it perhaps affects both. But could arguably be a broader >> issue. See below. >=20 > Sure, but this draft has a Normative reference to the RESTCONF draft for u= ser auth. Unless you=E2=80=99re saying that =E2=80=9Ccall home=E2=80=9D is i= ntroducing a new/stricter requirement, wouldn=E2=80=99t it be best to not re= peat text from a normative reference? >=20 Right, but your adding a new capability in the callback that adds risk. Thanks, Kathleen=20 >=20 >=20 >=20 >>> Answering your questions: >>>=20 >>>> is it ok for a client to send it's e.g. Basic auth credential to >>>> any of the servers that the client can validate? >>>=20 >>> Yes. >>=20 >> Ick - at least, that's ickky if only the basic-auth realm is used >> to select the password to send out (effectively in clear). Both >> basic and digest I think talk about a user selecting the password >> to input based on the realm, but here you're automating that based >> on a packet received over the network. >=20 > Not true. Call home *only* impacts the TCP protocol layer. The TLS and H= TTP protocol layers are unchanged. It is still the case that the client (NM= S) sends an HTTP request (GET) and, if inadequate credentials are provides, t= he server (device) sends a WWW-Authenticate challenge, including the =E2=80=98= realm=E2=80=99, as REQUIRED by RFC 7617. >=20 >=20 >=20 >> What ensures a client here never sends the password to an incorrect >> server? Say a client has two servers (A and B) that can call-home >> to the client, and A cheats on B by using B's realm (which is not >> considered a strong secret) in A's WWW-Authenticate? >>=20 >> Now if that is a real issue, I think we could argue that basic and >> digest, unmodified, are just not safe here. I'm not sure what >> modification could usefully be done if one is needed other than >> maybe pinning the password to the server identity. Having just now >> re-read RFC7617 I think we may need to tackle that issue somehow >> as 7617 envisages the user not typing the password as the control >> here. >>=20 >> (Or we could short-circuit this is the wg were willing to give >> up on use of crappy http auth schemes like basic and only allow >> better things - do you really really need this so badly as to >> put these devices at risk?) >=20 > I wonder if maybe an aspect of this draft is being overlooked. To recap, j= ust as with a normal RESTCONF (HTTPS) connection, when a call home connectio= n is being established, the RESTCONF server will present its server certific= ate and the TLS crypto session will be established *before* Basic/Digest aut= h. That is, the RESTCONF client would NOT send its Basic/Digest auth to a s= erver if it can=E2=80=99t first authenticate the server (via its server cert= ificate). In this draft, this is captured by C5-C7 (see below). Please not= e that =E2=80=9Cproceeds as normal=E2=80=9D in C7 below is when the Basic /D= igest auth would occur: >=20 > C5 As part of establishing an SSH or TLS connection, the NETCONF/ > RESTCONF client MUST validate the server's presented host key or > certificate. This validation MAY be accomplished by certificate > path validation or by comparing the host key or certificate to a > previously trusted or "pinned" value. >=20 > C6 If certificate path validation is used, the NETCONF/RESTCONF > client MUST ensure that the certificate has a valid chain of > trust to a preconfigured trust anchor and that the certificate > encodes an "identifier" [RFC6125] that the client had awareness > of prior to the connection attempt. How identifiers are encoded > in certificates MAY be determined by a policy associated with the > certificate's trust anchor. For instance, a given trust anchor > may be known to only sign IDevID certificates [Std-802.1AR-2009] > having a unique identifier (e.g., serial number) in the X.509 > certificate's "CommonName" field. >=20 > C7 After the server's host key or certificate is validated, the SSH > or TLS protocol proceeds as normal to establish a SSH or TLS > connection. >=20 >=20 > Please let me know if there was a misunderstanding here, or if I=E2=80=99m= altogether missing something in your comment! >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>>=20 >>>> I.e., is an additional level of pinning needed for this? >>>=20 >>> Not that I=E2=80=99m aware of. >>=20 >> We may want to chat about that more. >=20 > This is tied to the above comment. >=20 >=20 >=20 >=20 >>>=20 >>>=20 >>>> Did the WG consider this? >>>=20 >>>=20 >>> No, but Kathleen made a good point to reference RFCs 7615 and 7616, >>> which I will do. Still, I think this comment is more on the >>> RESTCONF draft than this one. Yes? >>=20 >> Sorry no, I don't think so. >=20 > Again, this is tied to the above comment. I=E2=80=99m hoping that this i= s a simple misunderstanding wrt how the RESTCONF/HTTPS client auths the serv= er=E2=80=99s TLS certificate *before* passing Basic/Digest auth credentials.= .. >=20 >=20 >=20 >=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> (2) The secdir review [1] calls out issues related to TLS-PSK and >>>> (I guess also) bare keys. I think it'd be good to be speific as to >>>> wheher or how those are to be supported here. If you are going to >>>> say those are supported, then I suspect some additional text is >>>> needed. Kent's answer to that (which was "see RFC7589" as I read >>>> it) doesn't quite do it here I think. that says that certificates >>>> must be supported (which is fine) but doesn't say that TLS-PSK or >>>> bare keys can or cannot be supported. >>>>=20 >>>> [1]=20 >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html >>>=20 >>>=20 >>> Juergen mentioned that PSK was deliberately taken out of rfc7589 - >>> and this draft has a normative reference to it. >>>=20 >>> Separately, you just now wrote to Juergen: "I'm fine with that >>> decision. The discuss is only about whether or not it's sufficiently >>> well documented that you don't want folks doing bare keys.=E2=80=9D >>>=20 >>> Would that be in this draft, or should it be in RRC7589? >>=20 >> Show me where it says "don't do bare keys" and I'll answer you;-) >> I think it perhaps needs to be here. >=20 >=20 > I may need your help here, but my understanding is that bare keys (and PSK= ) are alternatives to PKI. So if we have a statement like =E2=80=9Cyou MUST= do PKI=E2=80=9D, does it not preclude the use of bare keys? >=20 > Both RFC 7589 and draft-ietf-netconf-restonf (which the call-home draft de= pends on) require X.509 certificates. These statements can be found here: >=20 > https://tools.ietf.org/html/rfc7589#section-5: >=20 > "Both peers MUST use X.509 certificate path validation [RFC5280] to > verify the integrity of the certificate presented by the peer.=E2=80=9D >=20 > And here: >=20 > https://tools.ietf.org/html/draft-ietf-netconf-restconf-08#section-2.2: >=20 > "Consistent with the exclusive use of X.509v3 certificates for NETCONF > over TLS [draft-ietf-netconf-rfc5539bis-10], use of certificates in > RESTCONF is also limited to X.509v3 certificates." >=20 >=20 >=20 >=20 > So I=E2=80=99m not sure, does this sufficiently lock the use of TLS (for b= oth NETCONF and RESTCONF) to X.509 certificates? - or is more text needed? >=20 >=20 >=20 >=20 >=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> (3) Consider zmap. When this is deployed, what'll be the effect of >>>> surveys that fingerprint all of the devices on the visible Internet >>>> who implement this protocol? Did the WG consider that? I'm not sure >>>> of the impact, if any, but it could be good if there's a way to >>>> help deployments end up less vulnerable to fingerprinting (and the >>>> ensuing exposure to unpatched vulns). >>>=20 >>> The WG did not discuss this. >>>=20 >>> I know that you mention zmap by example, but reading on it I see that >>> is sends a SYN message, and tests if a SYN-ACK is returned. I never >>> completes the TCP connection and, in fact sends a RST. >>=20 >> zmap has been used for all sorts of more complex handshakes. >>=20 >>>=20 >>> This concern seems to be true for any protocol, not specific to >>> call-home. =20 >>=20 >> I think a role-change like this makes it far more notable. >>> Still, I could add to the Security Considerations section >>> something like: >>>=20 >>> NETCONF/RESTCONF clients having a open port for call home should be >>> aware that network scanning tools are many times used to fingerprint >>> hosts with the hope of finding unpatched vulnerabilities. Effort >>> should be made to limit exposure only to needing to access the >>> NETCONF/RESTCONF client. >>>=20 >>> What do you think? >>=20 >> But what efforts can one make and what is the impact of not making >> those (for this protocol). The role-change here is a minor transport >> change but doing that for publicly reachable hosts has a lot of >> consequences. >=20 > I hope that this will be discussed on the TLS WG and openssh lists. I ima= gine that it may culminate in better Security Considerations language in thi= s draft. >=20 >=20 >=20 >=20 >=20 >>>> - OCSP: any issue there? is it mandatory to use in any case for >>>> TLS? >>>=20 >>> Again, this draft has a normative references to RFC 7589, which >>> says: >>>=20 >>> Both peers MUST use X.509 certificate path validation [RFC5280] to=20 >>> verify the integrity of the certificate presented by the peer. >>>=20 >>>=20 >>> And RFC5280 defines certificate path validation as including >>> revocation checking. =20 >>=20 >> No. Revocation checking is optional in 5280. (Sorry;-) >=20 > OK, fair point. To answer your question then, neither OCSP nor CRL revoc= ation checking is required (but see next comment below). >=20 >=20 >=20 >>> So both CRL and OSCP are available, and would >>> be up to the CA to specify CRL distribution points or authority info >>> access in their certificates. >>=20 >> If you want clients here to support status checking I think you need >> to say that or reference something that says that. >=20 > It=E2=80=99s certainly true that we would *want* NETCONF/RESTCONF clients t= o do revocation checking, but we cannot mandate it as some deployments are o= n private networks and hence unable to download a CRL or access an OCSP serv= er. >=20 > That said, I believe that C5 could be enhanced with a SHOULD and a MUST as= follows (see last two sentences). Would this update address your concern? >=20 > OLD: >=20 > C5 As part of establishing an SSH or TLS connection, the NETCONF/ > RESTCONF client MUST validate the server's presented host key or > certificate. This validation MAY be accomplished by certificate > path validation or by comparing the host key or certificate to a > previously trusted or "pinned" value. >=20 >=20 > NEW: >=20 > C5 As part of establishing an SSH or TLS connection, the NETCONF/ > RESTCONF client MUST validate the server's presented host key or > certificate. This validation MAY be accomplished by certificate > path validation or by comparing the host key or certificate to a > previously trusted or "pinned" value. If a certificate contains > revocation checking information, the NETCONF/RESTCONF client > SHOULD check the revocation status of the certificate. If it is >=20 > determined that a certificate has been revoked, the client MUST > immediately close the connection. >=20 >=20 >=20 >=20 > Thanks again, and I apologize if this thread is beginning to become long -= hopefully we=E2=80=99ll start closing out some of these DISCUSS points soon= though :) >=20 > Kent >=20 >=20 From nobody Fri Oct 23 10:10: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 6A6FC1A87C8; Fri, 23 Oct 2015 10:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=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 eWsm_1IKGezP; Fri, 23 Oct 2015 10:10:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D9D1A87C7; Fri, 23 Oct 2015 10:10:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7FF0ABE79; Fri, 23 Oct 2015 18:10:01 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO2rq2p3CJBp; Fri, 23 Oct 2015 18:10:01 +0100 (IST) Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DA108BE58; Fri, 23 Oct 2015 18:10:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445620201; bh=im3yENBQo2TsoJIPa7KMJD0fvQp6oh3nGdwxo/KL3AE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=T5+1IJOqFs9bqKyYRoxd9srcYXSslSuuSJBMoaH8t4L0viKwWPCjaK2IayXP/MA4l kcRjxf68nAB/U6lbDY4rTzj4YxSW9omrD1bBbB/+HBtDfWLo+/hFtLH6v2fWC/ErlT 2R2BOXLEwc30FVl254tj2sNfVl6dCVfwpClStnjM= To: Kent Watsen , The IESG References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> <8F4A49AE-1160-4685-B878-39A087496FDF@juniper.net> <562836EE.40904@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <562A69E8.5040006@cs.tcd.ie> Date: Fri, 23 Oct 2015 18:10:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 17:10:06 -0000 Hiya, various bits down below... On 23/10/15 15:25, Kent Watsen wrote: > > Hiya Stephen! > > > > > > >>> >>> >>>> (1) HTTP Auth: is it ok for a client to send it's e.g. basic >>>> auth credential to any of the servers that the client can >>>> validate? I.e., is an additional level of pinning needed for >>>> this? That would be a new form of pinning and is not defined >>>> for either TLS or SSH afaik. That could also be done in various >>>> ways and I'm not sure if those might have interoperability >>>> consequences. Or perhaps if not doing that, this draft should >>>> say something about a need for stronger credentials esp. for >>>> basic auth. Did the WG consider this? >>> >>> Is this comment new to call home, or it is really a comment on >>> the RESTCONF draft? Specifically, please see this section: >>> https://tools.ietf.org/html/draft-ietf-netconf-restconf-08#section-2.5 >> >> >>> I'd say it perhaps affects both. But could arguably be a broader >> issue. See below. > > Sure, but this draft has a Normative reference to the RESTCONF draft > for user auth. Unless you’re saying that “call home” is introducing > a new/stricter requirement, wouldn’t it be best to not repeat text > from a normative reference? > > > > >>> Answering your questions: >>> >>>> is it ok for a client to send it's e.g. Basic auth credential >>>> to any of the servers that the client can validate? >>> >>> Yes. >> >> Ick - at least, that's ickky if only the basic-auth realm is used >> to select the password to send out (effectively in clear). Both >> basic and digest I think talk about a user selecting the password >> to input based on the realm, but here you're automating that based >> on a packet received over the network. > > Not true. Call home *only* impacts the TCP protocol layer. The TLS > and HTTP protocol layers are unchanged. It is still the case that > the client (NMS) sends an HTTP request (GET) and, if inadequate > credentials are provides, the server (device) sends a > WWW-Authenticate challenge, including the ‘realm’, as REQUIRED by RFC > 7617. > > > >> What ensures a client here never sends the password to an >> incorrect server? Say a client has two servers (A and B) that can >> call-home to the client, and A cheats on B by using B's realm >> (which is not considered a strong secret) in A's WWW-Authenticate? >> >> Now if that is a real issue, I think we could argue that basic and >> digest, unmodified, are just not safe here. I'm not sure what >> modification could usefully be done if one is needed other than >> maybe pinning the password to the server identity. Having just now >> re-read RFC7617 I think we may need to tackle that issue somehow as >> 7617 envisages the user not typing the password as the control >> here. >> >> (Or we could short-circuit this is the wg were willing to give up >> on use of crappy http auth schemes like basic and only allow better >> things - do you really really need this so badly as to put these >> devices at risk?) > > I wonder if maybe an aspect of this draft is being overlooked. To > recap, just as with a normal RESTCONF (HTTPS) connection, when a call > home connection is being established, the RESTCONF server will > present its server certificate and the TLS crypto session will be > established *before* Basic/Digest auth. That is, the RESTCONF > client would NOT send its Basic/Digest auth to a server if it can’t > first authenticate the server (via its server certificate). In this > draft, this is captured by C5-C7 (see below). Please note that > “proceeds as normal” in C7 below is when the Basic /Digest auth would > occur: > > C5 As part of establishing an SSH or TLS connection, the NETCONF/ > RESTCONF client MUST validate the server's presented host key or > certificate. This validation MAY be accomplished by certificate path > validation or by comparing the host key or certificate to a > previously trusted or "pinned" value. > > C6 If certificate path validation is used, the NETCONF/RESTCONF > client MUST ensure that the certificate has a valid chain of trust to > a preconfigured trust anchor and that the certificate encodes an > "identifier" [RFC6125] that the client had awareness of prior to the > connection attempt. How identifiers are encoded in certificates MAY > be determined by a policy associated with the certificate's trust > anchor. For instance, a given trust anchor may be known to only sign > IDevID certificates [Std-802.1AR-2009] having a unique identifier > (e.g., serial number) in the X.509 certificate's "CommonName" field. > > C7 After the server's host key or certificate is validated, the SSH > or TLS protocol proceeds as normal to establish a SSH or TLS > connection. > > > Please let me know if there was a misunderstanding here, or if I’m > altogether missing something in your comment! Go back to my example. The TLS client/TCP server ("C") is correctly configured to accept connections from two different TLS servers/TCP clients, A and B. (I don't know why that'd be sensible, but you do not preclude it that I can see.) Now C will correctly validate either A or B via their TLS server certs and all's well, but for some reason C has different passwords for basic when authenticating to A and B via basic auth or digest. And A is not supposed to know the password to use for basic auth to B. Let's say A uses realm=A-realm in the WWW-authenticate and B uses B-realm. What happens when A sends a WWW-authenticate with realm=B-realm? The basic auth RFC assumes there's a warm body at the keyboard who might or might not notice and not type (and hence expose) the wrong password. (Whether that's a reasonable assumption is not our business, but it is explicitly in the RFCs.) This spec has no warm body therefore more is needed. That might be trivial enough but is a change to how basic auth works, and one that might or might not be supported in a library. I'd not be surprised either way, but a library for basic auth may well not be dependent on TLS at all, in which case this attack by A on B could work. One fix could be to say that implementations of this (or just those that support more than one TLS server/TCP client) need to be able to pin any vulnerable credential to the TLS server and the HTTP auth realm. But that's likely a code change somewhere. And the above argument I think also applies to SSH password auth or any similarly vulnerable auth mechanism. And now that I think of it, there's a possible additional wrinkle here related to a question Benoit asked on the call. If the way that the TLS client/TCP server is configured is to have specific information about A and B (e.g. their certs/names/public keys) then this new kind of pinning would be easy enough, as there's no new configuration needed on the TLS client/TCP server, just a bit of new code. But if the TLS client/TCP server is only configured with CA information, the this new kind of pinning is a bit more work. And since either is possible, we may need to talk about that too. > >>> >>>> I.e., is an additional level of pinning needed for this? >>> >>> Not that I’m aware of. >> >> We may want to chat about that more. > > This is tied to the above comment. > > > > >>> >>> >>>> Did the WG consider this? >>> >>> >>> No, but Kathleen made a good point to reference RFCs 7615 and >>> 7616, which I will do. Still, I think this comment is more on >>> the RESTCONF draft than this one. Yes? >> >> Sorry no, I don't think so. > > Again, this is tied to the above comment. I’m hoping that this is a > simple misunderstanding wrt how the RESTCONF/HTTPS client auths the > server’s TLS certificate *before* passing Basic/Digest auth > credentials... > > > > >>> >>> >>> >>> >>>> (2) The secdir review [1] calls out issues related to TLS-PSK >>>> and (I guess also) bare keys. I think it'd be good to be >>>> speific as to wheher or how those are to be supported here. If >>>> you are going to say those are supported, then I suspect some >>>> additional text is needed. Kent's answer to that (which was >>>> "see RFC7589" as I read it) doesn't quite do it here I think. >>>> that says that certificates must be supported (which is fine) >>>> but doesn't say that TLS-PSK or bare keys can or cannot be >>>> supported. >>>> >>>> [1] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06087.html >>> >>> >>> >>>> Juergen mentioned that PSK was deliberately taken out of rfc7589 - >>> and this draft has a normative reference to it. >>> >>> Separately, you just now wrote to Juergen: "I'm fine with that >>> decision. The discuss is only about whether or not it's >>> sufficiently well documented that you don't want folks doing bare >>> keys.” >>> >>> Would that be in this draft, or should it be in RRC7589? >> >> Show me where it says "don't do bare keys" and I'll answer you;-) I >> think it perhaps needs to be here. > > > I may need your help here, but my understanding is that bare keys > (and PSK) are alternatives to PKI. So if we have a statement like > “you MUST do PKI”, does it not preclude the use of bare keys? No. A TLS stack may support all of 'em. If you don't want bare keys used, you need to say explicitly that I think. If you do want to allow bare keys, then that could also be done but may be more work in this case. > > Both RFC 7589 and draft-ietf-netconf-restonf (which the call-home > draft depends on) require X.509 certificates. These statements can > be found here: > > https://tools.ietf.org/html/rfc7589#section-5: > > "Both peers MUST use X.509 certificate path validation [RFC5280] to > verify the integrity of the certificate presented by the peer.” Yeah, but that doesn't say the peer MUST present a cert. (This is probably because bare keys is newish.) > > And here: > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-08#section-2.2: > > "Consistent with the exclusive use of X.509v3 certificates for > NETCONF over TLS [draft-ietf-netconf-rfc5539bis-10], use of > certificates in RESTCONF is also limited to X.509v3 certificates." > That one is ok, yes. > So I’m not sure, does this sufficiently lock the use of TLS (for both > NETCONF and RESTCONF) to X.509 certificates? - or is more text > needed? I think a simple "X.509 server authentication MUST be used for all TLS sessions" or similar would be enough. >>>> (3) Consider zmap. When this is deployed, what'll be the effect >>>> of surveys that fingerprint all of the devices on the visible >>>> Internet who implement this protocol? Did the WG consider that? >>>> I'm not sure of the impact, if any, but it could be good if >>>> there's a way to help deployments end up less vulnerable to >>>> fingerprinting (and the ensuing exposure to unpatched vulns). >>> >>> The WG did not discuss this. >>> >>> I know that you mention zmap by example, but reading on it I see >>> that is sends a SYN message, and tests if a SYN-ACK is returned. >>> I never completes the TCP connection and, in fact sends a RST. >> >> zmap has been used for all sorts of more complex handshakes. >> >>> >>> This concern seems to be true for any protocol, not specific to >>> call-home. >> >> I think a role-change like this makes it far more notable. >>> Still, I could add to the Security Considerations section >>> something like: >>> >>> NETCONF/RESTCONF clients having a open port for call home should >>> be aware that network scanning tools are many times used to >>> fingerprint hosts with the hope of finding unpatched >>> vulnerabilities. Effort should be made to limit exposure only to >>> needing to access the NETCONF/RESTCONF client. >>> >>> What do you think? >> >> But what efforts can one make and what is the impact of not making >> those (for this protocol). The role-change here is a minor >> transport change but doing that for publicly reachable hosts has a >> lot of consequences. > > I hope that this will be discussed on the TLS WG and openssh lists. > I imagine that it may culminate in better Security Considerations > language in this draft. Not quite. I think the tls/ssh folks can help us with the detail of possible differences wrt DoS issues. In this case, I think we need to ponder it a bit, and I certainly need to better understand where these TLS client/TCP server things are likely to be deployed. So I'd say we ought chat about it and see what we think first. > > > > > >>>> - OCSP: any issue there? is it mandatory to use in any case >>>> for TLS? >>> >>> Again, this draft has a normative references to RFC 7589, which >>> says: >>> >>> Both peers MUST use X.509 certificate path validation [RFC5280] >>> to verify the integrity of the certificate presented by the >>> peer. >>> >>> >>> And RFC5280 defines certificate path validation as including >>> revocation checking. >> >> No. Revocation checking is optional in 5280. (Sorry;-) > > OK, fair point. To answer your question then, neither OCSP nor CRL > revocation checking is required (but see next comment below). Modulo my discuss point #3, that's fine. > > > >>> So both CRL and OSCP are available, and would be up to the CA to >>> specify CRL distribution points or authority info access in their >>> certificates. >> >> If you want clients here to support status checking I think you >> need to say that or reference something that says that. > > It’s certainly true that we would *want* NETCONF/RESTCONF clients to > do revocation checking, but we cannot mandate it as some deployments > are on private networks and hence unable to download a CRL or access > an OCSP server. > > That said, I believe that C5 could be enhanced with a SHOULD and a > MUST as follows (see last two sentences). Would this update address > your concern? > > OLD: > > C5 As part of establishing an SSH or TLS connection, the NETCONF/ > RESTCONF client MUST validate the server's presented host key or > certificate. This validation MAY be accomplished by certificate path > validation or by comparing the host key or certificate to a > previously trusted or "pinned" value. > > > NEW: > > C5 As part of establishing an SSH or TLS connection, the NETCONF/ > RESTCONF client MUST validate the server's presented host key or > certificate. This validation MAY be accomplished by certificate path > validation or by comparing the host key or certificate to a > previously trusted or "pinned" value. If a certificate contains > revocation checking information, the NETCONF/RESTCONF client SHOULD > check the revocation status of the certificate. If it is > > determined that a certificate has been revoked, the client MUST > immediately close the connection. > Again, that seems good, modulo thinking about discuss point #3 which could touch on this. (E.g. if there're loads of deployments that will likely be able to use public CAs and if one can characterise those crisply in a way meaningful to a developer, then one might want to mandate status checking for those cases.) > > > Thanks again, and I apologize if this thread is beginning to become > long - hopefully we’ll start closing out some of these DISCUSS points > soon though :) No need to apologise, mail on stuff like this is just a bit cumbersome. And in any case, it's me that's holding the DISCUSS ballot so if anyone should be blamed, I'm it:-) Cheers, S. > > Kent > > From nobody Fri Oct 23 13:50:03 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 4F9321A908F; Fri, 23 Oct 2015 13:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdRukmssA_cA; Fri, 23 Oct 2015 13:49:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CED1A908D; Fri, 23 Oct 2015 13:49:58 -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.306.13; Fri, 23 Oct 2015 20:49:55 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Fri, 23 Oct 2015 20:49:55 +0000 From: Kent Watsen To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHRCkk5+GfvZN93g0WK01hCV3RAd552ax0AgABMfgCAAi4egIAAcQEA///6YgA= Date: Fri, 23 Oct 2015 20:49:54 +0000 Message-ID: <7B1435AE-2A64-4A69-8950-B49E76BD3B02@juniper.net> References: <20151019083615.13851.76254.idtracker@ietfa.amsl.com> <8F4A49AE-1160-4685-B878-39A087496FDF@juniper.net> <562836EE.40904@cs.tcd.ie> <562A69E8.5040006@cs.tcd.ie> In-Reply-To: <562A69E8.5040006@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB458; 5:nHUUXOnKIn0osNpHsLswZdPdqLZIxF+arEXHGswU6/4huZp7t7I5CexrP+Nkcb3JmRcVCIkE+ZMYTQApgbVoFJksgkbf61naxZu7vA8+TOmGmWzLJXUiBtOujs+jVaEKFGHu4zx47X3ZctB5AvV2Gg==; 24:VOVAk2IC28etXJLzxL/wBj07gSxbZ0UViqrELFIhlX3czEABD9pDdH9O8c/uECUCc4/z4BRIJFj7WKMc4Vw0aV2VSyITvDIX4lZkVwqJ1CI=; 20:JNRrHggCHCVIQa98E1RdE9ChTpY0hEmq+8C/XLXhBDOSXU7jzljr28yzgu5pEYPpDhZKWU8xUbQ/AUpTjVdYoQ== 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)(2401047)(520078)(8121501046)(5005006)(3002001)(102215026); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(76104003)(199003)(189002)(40224003)(51444003)(164054003)(54094003)(43784003)(76176999)(5007970100001)(81156007)(5001770100001)(33656002)(11100500001)(66066001)(2900100001)(93886004)(189998001)(19580395003)(2950100001)(36756003)(5002640100001)(5004730100002)(5001960100002)(54356999)(97736004)(4001350100001)(551544002)(83716003)(106116001)(15975445007)(102836002)(106356001)(87936001)(40100003)(105586002)(86362001)(50986999)(230783001)(99286002)(122556002)(10400500002)(101416001)(5008740100001)(92566002)(83506001)(82746002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3F1F5E578381FF40AAE9B980943D1875@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 20:49:54.9726 (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-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Stephen Farrell's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 20:50:02 -0000 DQoNCg0KDQpIaSBTdGVwaGVuLA0KDQo+PiANCj4+IA0KPj4gDQo+Pj4gV2hhdCBlbnN1cmVzIGEg Y2xpZW50IGhlcmUgbmV2ZXIgc2VuZHMgdGhlIHBhc3N3b3JkIHRvIGFuDQo+Pj4gaW5jb3JyZWN0 IHNlcnZlcj8gU2F5IGEgY2xpZW50IGhhcyB0d28gc2VydmVycyAoQSBhbmQgQikgdGhhdCBjYW4N Cj4+PiBjYWxsLWhvbWUgdG8gdGhlIGNsaWVudCwgYW5kIEEgY2hlYXRzIG9uIEIgYnkgdXNpbmcg QidzIHJlYWxtDQo+Pj4gKHdoaWNoIGlzIG5vdCBjb25zaWRlcmVkIGEgc3Ryb25nIHNlY3JldCkg aW4gQSdzIFdXVy1BdXRoZW50aWNhdGU/DQo+Pj4gDQo+Pj4gTm93IGlmIHRoYXQgaXMgYSByZWFs IGlzc3VlLCBJIHRoaW5rIHdlIGNvdWxkIGFyZ3VlIHRoYXQgYmFzaWMgYW5kIA0KPj4+IGRpZ2Vz dCwgdW5tb2RpZmllZCwgYXJlIGp1c3Qgbm90IHNhZmUgaGVyZS4gSSdtIG5vdCBzdXJlIHdoYXQg DQo+Pj4gbW9kaWZpY2F0aW9uIGNvdWxkIHVzZWZ1bGx5IGJlIGRvbmUgaWYgb25lIGlzIG5lZWRl ZCBvdGhlciB0aGFuIA0KPj4+IG1heWJlIHBpbm5pbmcgdGhlIHBhc3N3b3JkIHRvIHRoZSBzZXJ2 ZXIgaWRlbnRpdHkuIEhhdmluZyBqdXN0IG5vdyANCj4+PiByZS1yZWFkIFJGQzc2MTcgSSB0aGlu ayB3ZSBtYXkgbmVlZCB0byB0YWNrbGUgdGhhdCBpc3N1ZSBzb21laG93IGFzDQo+Pj4gNzYxNyBl bnZpc2FnZXMgdGhlIHVzZXIgbm90IHR5cGluZyB0aGUgcGFzc3dvcmQgYXMgdGhlIGNvbnRyb2wg DQo+Pj4gaGVyZS4NCj4+PiANCj4+PiAoT3Igd2UgY291bGQgc2hvcnQtY2lyY3VpdCB0aGlzIGlz IHRoZSB3ZyB3ZXJlIHdpbGxpbmcgdG8gZ2l2ZSB1cA0KPj4+IG9uIHVzZSBvZiBjcmFwcHkgaHR0 cCBhdXRoIHNjaGVtZXMgbGlrZSBiYXNpYyBhbmQgb25seSBhbGxvdyBiZXR0ZXINCj4+PiB0aGlu Z3MgLSBkbyB5b3UgcmVhbGx5IHJlYWxseSBuZWVkIHRoaXMgc28gYmFkbHkgYXMgdG8gcHV0IHRo ZXNlDQo+Pj4gZGV2aWNlcyBhdCByaXNrPykNCj4+IA0KPj4gSSB3b25kZXIgaWYgbWF5YmUgYW4g YXNwZWN0IG9mIHRoaXMgZHJhZnQgaXMgYmVpbmcgb3Zlcmxvb2tlZC4gIFRvDQo+PiByZWNhcCwg anVzdCBhcyB3aXRoIGEgbm9ybWFsIFJFU1RDT05GIChIVFRQUykgY29ubmVjdGlvbiwgd2hlbiBh IGNhbGwNCj4+IGhvbWUgY29ubmVjdGlvbiBpcyBiZWluZyBlc3RhYmxpc2hlZCwgdGhlIFJFU1RD T05GIHNlcnZlciB3aWxsDQo+PiBwcmVzZW50IGl0cyBzZXJ2ZXIgY2VydGlmaWNhdGUgYW5kIHRo ZSBUTFMgY3J5cHRvIHNlc3Npb24gd2lsbCBiZQ0KPj4gZXN0YWJsaXNoZWQgKmJlZm9yZSogQmFz aWMvRGlnZXN0IGF1dGguICAgVGhhdCBpcywgdGhlIFJFU1RDT05GDQo+PiBjbGllbnQgd291bGQg Tk9UIHNlbmQgaXRzIEJhc2ljL0RpZ2VzdCBhdXRoIHRvIGEgc2VydmVyIGlmIGl0IGNhbuKAmXQN Cj4+IGZpcnN0IGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyICh2aWEgaXRzIHNlcnZlciBjZXJ0aWZp Y2F0ZSkuICBJbiB0aGlzDQo+PiBkcmFmdCwgdGhpcyBpcyBjYXB0dXJlZCBieSBDNS1DNyAoc2Vl IGJlbG93KS4gIFBsZWFzZSBub3RlIHRoYXQNCj4+IOKAnHByb2NlZWRzIGFzIG5vcm1hbOKAnSBp biBDNyBiZWxvdyBpcyB3aGVuIHRoZSBCYXNpYyAvRGlnZXN0IGF1dGggd291bGQNCj4+IG9jY3Vy Og0KPj4gDQo+PiBDNSAgQXMgcGFydCBvZiBlc3RhYmxpc2hpbmcgYW4gU1NIIG9yIFRMUyBjb25u ZWN0aW9uLCB0aGUgTkVUQ09ORi8gDQo+PiBSRVNUQ09ORiBjbGllbnQgTVVTVCB2YWxpZGF0ZSB0 aGUgc2VydmVyJ3MgcHJlc2VudGVkIGhvc3Qga2V5IG9yIA0KPj4gY2VydGlmaWNhdGUuICBUaGlz IHZhbGlkYXRpb24gTUFZIGJlIGFjY29tcGxpc2hlZCBieSBjZXJ0aWZpY2F0ZSBwYXRoDQo+PiB2 YWxpZGF0aW9uIG9yIGJ5IGNvbXBhcmluZyB0aGUgaG9zdCBrZXkgb3IgY2VydGlmaWNhdGUgdG8g YSANCj4+IHByZXZpb3VzbHkgdHJ1c3RlZCBvciAicGlubmVkIiB2YWx1ZS4NCj4+IA0KPj4gQzYg IElmIGNlcnRpZmljYXRlIHBhdGggdmFsaWRhdGlvbiBpcyB1c2VkLCB0aGUgTkVUQ09ORi9SRVNU Q09ORiANCj4+IGNsaWVudCBNVVNUIGVuc3VyZSB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBoYXMgYSB2 YWxpZCBjaGFpbiBvZiB0cnVzdCB0bw0KPj4gYSBwcmVjb25maWd1cmVkIHRydXN0IGFuY2hvciBh bmQgdGhhdCB0aGUgY2VydGlmaWNhdGUgZW5jb2RlcyBhbg0KPj4gImlkZW50aWZpZXIiIFtSRkM2 MTI1XSB0aGF0IHRoZSBjbGllbnQgaGFkIGF3YXJlbmVzcyBvZiBwcmlvciB0byB0aGUNCj4+IGNv bm5lY3Rpb24gYXR0ZW1wdC4gIEhvdyBpZGVudGlmaWVycyBhcmUgZW5jb2RlZCBpbiBjZXJ0aWZp Y2F0ZXMgTUFZDQo+PiBiZSBkZXRlcm1pbmVkIGJ5IGEgcG9saWN5IGFzc29jaWF0ZWQgd2l0aCB0 aGUgY2VydGlmaWNhdGUncyB0cnVzdA0KPj4gYW5jaG9yLiAgRm9yIGluc3RhbmNlLCBhIGdpdmVu IHRydXN0IGFuY2hvciBtYXkgYmUga25vd24gdG8gb25seSBzaWduDQo+PiBJRGV2SUQgY2VydGlm aWNhdGVzIFtTdGQtODAyLjFBUi0yMDA5XSBoYXZpbmcgYSB1bmlxdWUgaWRlbnRpZmllcg0KPj4g KGUuZy4sIHNlcmlhbCBudW1iZXIpIGluIHRoZSBYLjUwOSBjZXJ0aWZpY2F0ZSdzICJDb21tb25O YW1lIiBmaWVsZC4NCj4+IA0KPj4gQzcgIEFmdGVyIHRoZSBzZXJ2ZXIncyBob3N0IGtleSBvciBj ZXJ0aWZpY2F0ZSBpcyB2YWxpZGF0ZWQsIHRoZSBTU0ggDQo+PiBvciBUTFMgcHJvdG9jb2wgcHJv Y2VlZHMgYXMgbm9ybWFsIHRvIGVzdGFibGlzaCBhIFNTSCBvciBUTFMgDQo+PiBjb25uZWN0aW9u Lg0KPj4gDQo+PiANCj4+IFBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGVyZSB3YXMgYSBtaXN1bmRl cnN0YW5kaW5nIGhlcmUsIG9yIGlmIEnigJltDQo+PiBhbHRvZ2V0aGVyIG1pc3Npbmcgc29tZXRo aW5nIGluIHlvdXIgY29tbWVudCENCj4NCj5HbyBiYWNrIHRvIG15IGV4YW1wbGUuIFRoZSBUTFMg Y2xpZW50L1RDUCBzZXJ2ZXIgKCJDIikgaXMgY29ycmVjdGx5DQo+Y29uZmlndXJlZCB0byBhY2Nl cHQgY29ubmVjdGlvbnMgZnJvbSB0d28gZGlmZmVyZW50IFRMUyBzZXJ2ZXJzL1RDUA0KPmNsaWVu dHMsIEEgYW5kIEIuIChJIGRvbid0IGtub3cgd2h5IHRoYXQnZCBiZSBzZW5zaWJsZSwgYnV0IHlv dSBkbw0KPm5vdCBwcmVjbHVkZSBpdCB0aGF0IEkgY2FuIHNlZS4pDQoNCg0KSXTigJlzIGluY3Jl ZGlibHkgc2Vuc2libGUsIG1vcmUgbGlrZSDigJxjb21tb24iLiAgQSBuZXR3b3JrIG1hbmFnZW1l bnQgc3lzdGVtIChhY3RpbmcgYXMgYSBDKSBpcyBtYW55IHRpbWVzIG1hbmFnaW5nIGxhcmdlIG51 bWJlcnMgb2YgZGV2aWNlcyAoYWN0aW5nIGFzIFMncykuDQoNCg0KPk5vdyBDIHdpbGwgY29ycmVj dGx5IHZhbGlkYXRlIGVpdGhlciBBIG9yIEIgdmlhIHRoZWlyIFRMUyBzZXJ2ZXINCj5jZXJ0cyBh bmQgYWxsJ3Mgd2VsbCwgYnV0IGZvciBzb21lIHJlYXNvbiBDIGhhcyBkaWZmZXJlbnQgcGFzc3dv cmRzDQo+Zm9yIGJhc2ljIHdoZW4gYXV0aGVudGljYXRpbmcgdG8gQSBhbmQgQiB2aWEgYmFzaWMg YXV0aCBvciBkaWdlc3QuDQo+QW5kIEEgaXMgbm90IHN1cHBvc2VkIHRvIGtub3cgdGhlIHBhc3N3 b3JkIHRvIHVzZSBmb3IgYmFzaWMgYXV0aA0KPnRvIEIuIExldCdzIHNheSBBIHVzZXMgcmVhbG09 QS1yZWFsbSBpbiB0aGUgV1dXLWF1dGhlbnRpY2F0ZSBhbmQNCj5CIHVzZXMgQi1yZWFsbS4NCg0K QWxzbyBhIHZlcnkgcG9zc2libGUgc2NlbmFyaW8gdG9kYXksIGFzIHNvbWUgTk1TIGRlcGxveW1l bnRzIG1heSBoYXZlIGRpZmZlcmVudCB1c2VyIGF1dGggcGVyIGRldmljZS4NCg0KDQo+V2hhdCBo YXBwZW5zIHdoZW4gQSBzZW5kcyBhIFdXVy1hdXRoZW50aWNhdGUgd2l0aCByZWFsbT1CLXJlYWxt Pw0KDQpPSy4gIE5vdyBJIHVuZGVyc3RhbmQgeW91ciBwb2ludC4gIFRoYW5rIHlvdSBmb3IgdGFr aW5nIHRoZSB0aW1lIHRvIGV4cGxhaW4gaXQuDQoNCk15IGZpcnN0IHRob3VnaHQgb24gdGhpcyBp cyB0byBub3RlIHRoYXQgdGhlIFJFU1RDT05GIGRyYWZ0IGlzIGNvbXBsZXRlbHkgbXV0ZSBvbiB0 aGUgc3ViamVjdCBvZiByZWFsbXMgLSBhbiBvbWlzc2lvbiBmb3Igc3VyZS4gIEFzIGFuIGF1dGhv ciBvbiB0aGF0IGRyYWZ0LCBteSBpbmNsaW5hdGlvbiBpcyB0byBhZGQgYSBzdGF0ZW1lbnQgYWxv bmcgdGhlIGxpbmVzIG9mIOKAnE1VU1QgdXNlIHRoZSByZWFsbSBGT0/igJ0sIHdoaWNoIHdvdWxk IGVxdWF0ZSBpdCB0byBORVRDT05GLCB3aGVyZSB0aGVyZSBpcyBubyBlcXVpdmFsZW50IGNvbmNl cHQgdG8gYSByZWFsbS4NCg0KQnV0IHRoZSBiZXR0ZXIgYW5zd2VyIGlzIHRoYXQgQyBuZWVkcyB0 byBmb2xsb3cgQzYgKGFib3ZlKSBlc3BlY2lhbGx5IHdpdGggcmVnYXJkcyB0byBlbnN1cmluZyB0 aGF0IHRoZSBzZXJ2ZXIncyBjZXJ0aWZpY2F0ZSBlbmNvZGVzIGFuICJpZGVudGlmaWVyIiBbUkZD NjEyNV0gdGhhdCB0aGUgY2xpZW50IGhhZCBhd2FyZW5lc3Mgb2YgcHJpb3IgdG8gdGhlDQpjb25u ZWN0aW9uIGF0dGVtcHQsIGRyaXZpbmcgaXQgdG8gdXNlIHRoZSByaWdodCBjcmVkZW50aWFscyBm b3IgdGhhdCBpZGVudGlmaWVyLiAgIFNvLCB3aGVuIEEgY2FsbHMgaG9tZSwgaXQgcHJlc2VudHMg YSBjZXJ0aWZpY2F0ZSB0aGF0IHNheXMg4oCcSeKAmW0gQeKAnSwgYW5kIHRoZW4gQyB1c2VzIHRo ZSBjcmVkZW50aWFscyBpdCBoYXMgcGlubmVkIHRvIGJlaW5nIGFzc29jaWF0ZWQgd2l0aCBBIChh bmQgTk9UIHVzZSBC4oCZcyBjcmVkZW50aWFscyB1bmRlciBhbnkgY2lyY3Vtc3RhbmNlKS4NCg0K UGVyaGFwcyB0aGUgaXNzdWUgaXMgdGhhdCB0aGlzIGlzIG9ubHkgaW1wbGllZCAobm90IGV4cGxp Y2l0bHkgc3RhdGVkKSBpbiBDN+KAmXMgInByb2NlZWRzIGFzIG5vcm1hbOKAnSBjbGF1c2UuICBX b3VsZCBpdCBoZWxwIHRvIGFkZCB0aGlzIHRleHQgdG8gdGhlIGVuZCBvZiBDNzoNCg0KICBXaGVu IHBlcmZvcm1pbmcgY2xpZW50LWF1dGhlbnRjYXRpb24gd2l0aCB0aGUgTkVUQ09ORi9SRVNUQ09O Rg0KICBzZXJ2ZXIsIHRoZSBORVRDT05GL1JFU1RDT05GIGNsaWVudCBNVVNUIGVuc3VyZSB0byBv bmx5IHVzZQ0KICBjcmVkZW50aWFscyB0aGF0IGhhZCBwcmV2aW91c2x5IGFzc29jaWF0ZWQgZm9y IHRoZSBORVRDT05GL1JFU1RDT05GDQogIHNlcnZlcuKAmXMgcHJlc2VudGVkIGhvc3Qga2V5IG9y IHNlcnZlciBjZXJ0aWZpY2F0ZS4NCg0KDQoNCg0KPlRoZSBiYXNpYyBhdXRoIFJGQyBhc3N1bWVz IHRoZXJlJ3MgYSB3YXJtIGJvZHkgYXQgdGhlIGtleWJvYXJkIHdobw0KPm1pZ2h0IG9yIG1pZ2h0 IG5vdCBub3RpY2UgYW5kIG5vdCB0eXBlIChhbmQgaGVuY2UgZXhwb3NlKSB0aGUNCj53cm9uZyBw YXNzd29yZC4gKFdoZXRoZXIgdGhhdCdzIGEgcmVhc29uYWJsZSBhc3N1bXB0aW9uIGlzIG5vdCBv dXINCj5idXNpbmVzcywgYnV0IGl0IGlzIGV4cGxpY2l0bHkgaW4gdGhlIFJGQ3MuKQ0KPg0KPlRo aXMgc3BlYyBoYXMgbm8gd2FybSBib2R5IHRoZXJlZm9yZSBtb3JlIGlzIG5lZWRlZC4NCj4NCj5U aGF0IG1pZ2h0IGJlIHRyaXZpYWwgZW5vdWdoIGJ1dCBpcyBhIGNoYW5nZSB0byBob3cgYmFzaWMg YXV0aA0KPndvcmtzLCBhbmQgb25lIHRoYXQgbWlnaHQgb3IgbWlnaHQgbm90IGJlIHN1cHBvcnRl ZCBpbiBhIGxpYnJhcnkuDQo+SSdkIG5vdCBiZSBzdXJwcmlzZWQgZWl0aGVyIHdheSwgYnV0IGEg bGlicmFyeSBmb3IgYmFzaWMgYXV0aA0KPm1heSB3ZWxsIG5vdCBiZSBkZXBlbmRlbnQgb24gVExT IGF0IGFsbCwgaW4gd2hpY2ggY2FzZSB0aGlzDQo+YXR0YWNrIGJ5IEEgb24gQiBjb3VsZCB3b3Jr Lg0KPg0KPk9uZSBmaXggY291bGQgYmUgdG8gc2F5IHRoYXQgaW1wbGVtZW50YXRpb25zIG9mIHRo aXMgKG9yIGp1c3QNCj50aG9zZSB0aGF0IHN1cHBvcnQgbW9yZSB0aGFuIG9uZSBUTFMgc2VydmVy L1RDUCBjbGllbnQpIG5lZWQgdG8NCj5iZSBhYmxlIHRvIHBpbiBhbnkgdnVsbmVyYWJsZSBjcmVk ZW50aWFsIHRvIHRoZSBUTFMgc2VydmVyIGFuZA0KPnRoZSBIVFRQIGF1dGggcmVhbG0uIEJ1dCB0 aGF0J3MgbGlrZWx5IGEgY29kZSBjaGFuZ2Ugc29tZXdoZXJlLg0KDQpBY3R1YWxseSwgSSB0aGlu ayB0aGF0IHRoaXMgaXMgd2hhdCB3ZSBzaG91bGQgZG8gKHNlZSBhYm92ZSksIGJ1dCBJIGRvbuKA mXQgdGhpbmsgdGhhdCBpdCBpcyBtdWNoIG9mIGEgY29kZSBjaGFuZ2UuIEF0IGxlYXN0IG91ciBO TVMgKFRMUyBjbGllbnQvVENQIHNlcnZlcikgZG9lcyB0aGlzIHRvZGF5LiBGb3IgaW5zdGFuY2Us IHdoZW4gdXNpbmcgdGhlIGoyc3NoIEphdmEgbGlicmFyeSwgdGhlcmUgaXMgYSBjYWxsYmFjayB0 byB0aGUgdXNlciBjb2RlIHRvIGF1dGhlbnRpY2F0ZSB0aGUgcHJlc2VudGVkIFNTSCBob3N0IGtl eS4gIE91ciBjb2RlIHVzZXMgdGhhdCBob3N0IGtleSB0byB0aGVuIGxvb2t1cCBwaW5uZWQgaW5m b3JtYXRpb24gaW5jbHVkaW5nIGNsaWVudC1hdXRoIGNyZWRlbnRpYWxzLiAgU2FtZSBjb3VsZCBi ZSBkb25lIHVzaW5nIGFuIEhUVFAgY2xpZW50IGxpYnJhcnkgSSBpbWFnaW5lLg0KDQoNCj5BbmQg dGhlIGFib3ZlIGFyZ3VtZW50IEkgdGhpbmsgYWxzbyBhcHBsaWVzIHRvIFNTSCBwYXNzd29yZCBh dXRoDQo+b3IgYW55IHNpbWlsYXJseSB2dWxuZXJhYmxlIGF1dGggbWVjaGFuaXNtLg0KPg0KPkFu ZCBub3cgdGhhdCBJIHRoaW5rIG9mIGl0LCB0aGVyZSdzIGEgcG9zc2libGUgYWRkaXRpb25hbCB3 cmlua2xlDQo+aGVyZSByZWxhdGVkIHRvIGEgcXVlc3Rpb24gQmVub2l0IGFza2VkIG9uIHRoZSBj YWxsLiBJZiB0aGUgd2F5DQo+dGhhdCB0aGUgVExTIGNsaWVudC9UQ1Agc2VydmVyIGlzIGNvbmZp Z3VyZWQgaXMgdG8gaGF2ZSBzcGVjaWZpYw0KPmluZm9ybWF0aW9uIGFib3V0IEEgYW5kIEIgKGUu Zy4gdGhlaXIgY2VydHMvbmFtZXMvcHVibGljIGtleXMpDQo+dGhlbiB0aGlzIG5ldyBraW5kIG9m IHBpbm5pbmcgd291bGQgYmUgZWFzeSBlbm91Z2gsIGFzIHRoZXJlJ3MNCj5ubyBuZXcgY29uZmln dXJhdGlvbiBuZWVkZWQgb24gdGhlIFRMUyBjbGllbnQvVENQIHNlcnZlciwganVzdCBhDQo+Yml0 IG9mIG5ldyBjb2RlLiBCdXQgaWYgdGhlIFRMUyBjbGllbnQvVENQIHNlcnZlciBpcyBvbmx5IGNv bmZpZ3VyZWQNCj53aXRoIENBIGluZm9ybWF0aW9uLCB0aGUgdGhpcyBuZXcga2luZCBvZiBwaW5u aW5nIGlzIGEgYml0IG1vcmUgd29yay4NCj5BbmQgc2luY2UgZWl0aGVyIGlzIHBvc3NpYmxlLCB3 ZSBtYXkgbmVlZCB0byB0YWxrIGFib3V0IHRoYXQgdG9vLg0KDQpJIHRoaW5rIHRoYXQgaXQgaXMg bW9yZSB0aGUgZm9ybWVyIHRoYW4gdGhlIGxhdHRlci4gIChzZWUgbXkgcmVzcG9uc2UgYWJvdmUp LiAgRG8geW91IGFncmVlPw0KDQoNCg0KDQoNCj4+IA0KPj4+PiANCj4+Pj4+KDIpIFRoZSBzZWNk aXIgcmV2aWV3IFsxXSBjYWxscyBvdXQgaXNzdWVzIHJlbGF0ZWQgdG8gVExTLVBTSw0KPj4+Pj4g YW5kIChJIGd1ZXNzIGFsc28pIGJhcmUga2V5cy4gSSB0aGluayBpdCdkIGJlIGdvb2QgdG8gYmUN Cj4+Pj4+IHNwZWlmaWMgYXMgdG8gd2hlaGVyIG9yIGhvdyB0aG9zZSBhcmUgdG8gYmUgc3VwcG9y dGVkIGhlcmUuIElmDQo+Pj4+PiB5b3UgYXJlIGdvaW5nIHRvIHNheSB0aG9zZSBhcmUgc3VwcG9y dGVkLCB0aGVuIEkgc3VzcGVjdCBzb21lDQo+Pj4+PiBhZGRpdGlvbmFsIHRleHQgaXMgbmVlZGVk LiBLZW50J3MgYW5zd2VyIHRvIHRoYXQgKHdoaWNoIHdhcw0KPj4+Pj4gInNlZSBSRkM3NTg5IiBh cyBJIHJlYWQgaXQpIGRvZXNuJ3QgcXVpdGUgZG8gaXQgaGVyZSBJIHRoaW5rLg0KPj4+Pj4gdGhh dCBzYXlzIHRoYXQgY2VydGlmaWNhdGVzIG11c3QgYmUgc3VwcG9ydGVkICh3aGljaCBpcyBmaW5l KQ0KPj4+Pj4gYnV0IGRvZXNuJ3Qgc2F5IHRoYXQgVExTLVBTSyBvciBiYXJlIGtleXMgY2FuIG9y IGNhbm5vdCBiZQ0KPj4+Pj4gc3VwcG9ydGVkLg0KPj4+Pj4gDQo+Pj4+PiBbMV0gDQo+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA2 MDg3Lmh0bWwNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4+IA0KPkp1ZXJnZW4gbWVudGlvbmVkIHRo YXQgUFNLIHdhcyBkZWxpYmVyYXRlbHkgdGFrZW4gb3V0IG9mIHJmYzc1ODkgLQ0KPj4+PiBhbmQg dGhpcyBkcmFmdCBoYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGl0Lg0KPj4+PiANCj4+Pj4g U2VwYXJhdGVseSwgeW91IGp1c3Qgbm93IHdyb3RlIHRvIEp1ZXJnZW46ICJJJ20gZmluZSB3aXRo IHRoYXQgDQo+Pj4+IGRlY2lzaW9uLiBUaGUgZGlzY3VzcyBpcyBvbmx5IGFib3V0IHdoZXRoZXIg b3Igbm90IGl0J3MNCj4+Pj4gc3VmZmljaWVudGx5IHdlbGwgZG9jdW1lbnRlZCB0aGF0IHlvdSBk b24ndCB3YW50IGZvbGtzIGRvaW5nIGJhcmUNCj4+Pj4ga2V5cy7igJ0NCj4+Pj4gDQo+Pj4+IFdv dWxkIHRoYXQgYmUgaW4gdGhpcyBkcmFmdCwgb3Igc2hvdWxkIGl0IGJlIGluIFJSQzc1ODk/DQo+ Pj4gDQo+Pj4gU2hvdyBtZSB3aGVyZSBpdCBzYXlzICJkb24ndCBkbyBiYXJlIGtleXMiIGFuZCBJ J2xsIGFuc3dlciB5b3U7LSkgSQ0KPj4+IHRoaW5rIGl0IHBlcmhhcHMgbmVlZHMgdG8gYmUgaGVy ZS4NCj4+IA0KPj4gDQo+PiBJIG1heSBuZWVkIHlvdXIgaGVscCBoZXJlLCBidXQgbXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IGJhcmUga2V5cw0KPj4gKGFuZCBQU0spIGFyZSBhbHRlcm5hdGl2ZXMg dG8gUEtJLiAgU28gaWYgd2UgaGF2ZSBhIHN0YXRlbWVudCBsaWtlDQo+PiDigJx5b3UgTVVTVCBk byBQS0nigJ0sIGRvZXMgaXQgbm90IHByZWNsdWRlIHRoZSB1c2Ugb2YgYmFyZSBrZXlzPw0KPg0K Pk5vLiBBIFRMUyBzdGFjayBtYXkgc3VwcG9ydCBhbGwgb2YgJ2VtLiBJZiB5b3UgZG9uJ3Qgd2Fu dCBiYXJlIGtleXMNCj51c2VkLCB5b3UgbmVlZCB0byBzYXkgZXhwbGljaXRseSB0aGF0IEkgdGhp bmsuIElmIHlvdSBkbyB3YW50IHRvDQo+YWxsb3cgYmFyZSBrZXlzLCB0aGVuIHRoYXQgY291bGQg YWxzbyBiZSBkb25lIGJ1dCBtYXkgYmUgbW9yZSB3b3JrDQo+aW4gdGhpcyBjYXNlLg0KDQoNCkFo LCBJIHNlZSBub3cuICBXZSBuZWVkIHRvIHBhdGNoIFM0IHdpdGggc29tZXRoaW5nIGFsb25nIHRo ZSBsaW5lcyBvZiDigJxXaGVuIHNlbmRpbmcgYSBjZXJ0aWZpY2F0ZSwgdGhlIE5FVENPTkYvUkVT VENPTkYgc2VydmVyIE1VU1Qgb25seSBzZW5kIGFuIFguNTA5djMgYmFzZWQgY2VydGlmaWNhdGUg KFBTSyBhbmQgYmFyZSBrZXkgY2VydGlmaWNhdGVzIE1VU1Qgbm90IGJlIGFkdmVydGlzZWQpLuKA nS4gICAgV291bGQgdGhpcyByZXNvbHZlIHlvdXIgY29uY2VybiBoZXJlPw0KDQoNCg0KPj4gDQo+ PiBCb3RoIFJGQyA3NTg5IGFuZCBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdG9uZiAod2hpY2ggdGhl IGNhbGwtaG9tZQ0KPj4gZHJhZnQgZGVwZW5kcyBvbikgcmVxdWlyZSBYLjUwOSBjZXJ0aWZpY2F0 ZXMuICAgVGhlc2Ugc3RhdGVtZW50cyBjYW4NCj4+IGJlIGZvdW5kIGhlcmU6DQo+PiANCj4+IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTg5I3NlY3Rpb24tNToNCj4+IA0KPj4gIkJv dGggcGVlcnMgTVVTVCB1c2UgWC41MDkgY2VydGlmaWNhdGUgcGF0aCB2YWxpZGF0aW9uIFtSRkM1 MjgwXSB0byANCj4+IHZlcmlmeSB0aGUgaW50ZWdyaXR5IG9mIHRoZSBjZXJ0aWZpY2F0ZSBwcmVz ZW50ZWQgYnkgdGhlIHBlZXIu4oCdDQo+DQo+WWVhaCwgYnV0IHRoYXQgZG9lc24ndCBzYXkgdGhl IHBlZXIgTVVTVCBwcmVzZW50IGEgY2VydC4NCj4NCj4oVGhpcyBpcyBwcm9iYWJseSBiZWNhdXNl IGJhcmUga2V5cyBpcyBuZXdpc2guKQ0KDQpSaWdodCwgYW5kIHdlIGNhbiBwYXRjaCBTNCBhYm92 ZS4gIFBlcmhhcHMgYWxzbyBwdXQgZXJyYXRhIG9uIFJGQyA1MjgwLi4uDQoNCg0KPg0KPj4gDQo+ PiBBbmQgaGVyZToNCj4+IA0KPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbmV0Y29uZi1yZXN0Y29uZi0wOCNzZWN0aW9uLTIuMjoNCj4+DQo+PiAgIkNvbnNpc3RlbnQg d2l0aCB0aGUgZXhjbHVzaXZlIHVzZSBvZiBYLjUwOXYzIGNlcnRpZmljYXRlcyBmb3INCj4+IE5F VENPTkYgb3ZlciBUTFMgW2RyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5YmlzLTEwXSwgdXNlIG9m DQo+PiBjZXJ0aWZpY2F0ZXMgaW4gUkVTVENPTkYgaXMgYWxzbyBsaW1pdGVkIHRvIFguNTA5djMg Y2VydGlmaWNhdGVzLiINCj4+IA0KPg0KPlRoYXQgb25lIGlzIG9rLCB5ZXMuDQo+DQo+PiBTbyBJ 4oCZbSBub3Qgc3VyZSwgZG9lcyB0aGlzIHN1ZmZpY2llbnRseSBsb2NrIHRoZSB1c2Ugb2YgVExT IChmb3IgYm90aA0KPj4gTkVUQ09ORiBhbmQgUkVTVENPTkYpIHRvIFguNTA5IGNlcnRpZmljYXRl cz8gIC0gb3IgaXMgbW9yZSB0ZXh0DQo+PiBuZWVkZWQ/DQo+DQo+SSB0aGluayBhIHNpbXBsZSAi WC41MDkgc2VydmVyIGF1dGhlbnRpY2F0aW9uIE1VU1QgYmUgdXNlZCBmb3IgYWxsDQo+VExTIHNl c3Npb25zIiBvciBzaW1pbGFyIHdvdWxkIGJlIGVub3VnaC4NCg0KVGhpcyBzb3VuZHMgbGlrZSBh IHN0YXRlbWVudCB0aGF0IHdvdWxkIGJlIG1hZGUgZm9yIHRoZSBjbGllbnQgKEMpLCBidXQgd2Ug d2VyZSB0YWxraW5nIGFib3V0IHRoZSBzZXJ2ZXIgaW4gUzQgYWJvdmUuICBTbyBwdXQgYSBzaW1p bGFyIHBhdGNoIG9uIEM1Pw0KDQoNCg0KPj4+Pj4gKDMpIENvbnNpZGVyIHptYXAuIFdoZW4gdGhp cyBpcyBkZXBsb3llZCwgd2hhdCdsbCBiZSB0aGUgZWZmZWN0DQo+Pj4+PiBvZiBzdXJ2ZXlzIHRo YXQgZmluZ2VycHJpbnQgYWxsIG9mIHRoZSBkZXZpY2VzIG9uIHRoZSB2aXNpYmxlDQo+Pj4+PiBJ bnRlcm5ldCB3aG8gaW1wbGVtZW50IHRoaXMgcHJvdG9jb2w/IERpZCB0aGUgV0cgY29uc2lkZXIg dGhhdD8NCj4+Pj4+IEknbSBub3Qgc3VyZSBvZiB0aGUgaW1wYWN0LCBpZiBhbnksIGJ1dCBpdCBj b3VsZCBiZSBnb29kIGlmDQo+Pj4+PiB0aGVyZSdzIGEgd2F5IHRvIGhlbHAgZGVwbG95bWVudHMg ZW5kIHVwIGxlc3MgdnVsbmVyYWJsZSB0bw0KPj4+Pj4gZmluZ2VycHJpbnRpbmcgKGFuZCB0aGUg ZW5zdWluZyBleHBvc3VyZSB0byB1bnBhdGNoZWQgdnVsbnMpLg0KPj4+PiANCj4+Pj4gVGhlIFdH IGRpZCBub3QgZGlzY3VzcyB0aGlzLg0KPj4+PiANCj4+Pj4gSSBrbm93IHRoYXQgeW91IG1lbnRp b24gem1hcCBieSBleGFtcGxlLCBidXQgcmVhZGluZyBvbiBpdCBJIHNlZQ0KPj4+PiB0aGF0IGlz IHNlbmRzIGEgU1lOIG1lc3NhZ2UsIGFuZCB0ZXN0cyBpZiBhIFNZTi1BQ0sgaXMgcmV0dXJuZWQu DQo+Pj4+IEkgbmV2ZXIgY29tcGxldGVzIHRoZSBUQ1AgY29ubmVjdGlvbiBhbmQsIGluIGZhY3Qg c2VuZHMgYSBSU1QuDQo+Pj4gDQo+Pj4gem1hcCBoYXMgYmVlbiB1c2VkIGZvciBhbGwgc29ydHMg b2YgbW9yZSBjb21wbGV4IGhhbmRzaGFrZXMuDQo+Pj4gDQo+Pj4+IA0KPj4+PiBUaGlzIGNvbmNl cm4gc2VlbXMgdG8gYmUgdHJ1ZSBmb3IgYW55IHByb3RvY29sLCBub3Qgc3BlY2lmaWMgdG8gDQo+ Pj4+IGNhbGwtaG9tZS4NCj4+PiANCj4+PiBJIHRoaW5rIGEgcm9sZS1jaGFuZ2UgbGlrZSB0aGlz IG1ha2VzIGl0IGZhciBtb3JlIG5vdGFibGUuDQo+Pj4+IFN0aWxsLCBJIGNvdWxkIGFkZCB0byB0 aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiANCj4+Pj4gc29tZXRoaW5nIGxpa2U6 DQo+Pj4+IA0KPj4+PiBORVRDT05GL1JFU1RDT05GIGNsaWVudHMgaGF2aW5nIGEgb3BlbiBwb3J0 IGZvciBjYWxsIGhvbWUgc2hvdWxkDQo+Pj4+IGJlIGF3YXJlIHRoYXQgbmV0d29yayBzY2Fubmlu ZyB0b29scyBhcmUgbWFueSB0aW1lcyB1c2VkIHRvDQo+Pj4+IGZpbmdlcnByaW50IGhvc3RzIHdp dGggdGhlIGhvcGUgb2YgZmluZGluZyB1bnBhdGNoZWQNCj4+Pj4gdnVsbmVyYWJpbGl0aWVzLiAg RWZmb3J0IHNob3VsZCBiZSBtYWRlIHRvIGxpbWl0IGV4cG9zdXJlIG9ubHkgdG8NCj4+Pj4gbmVl ZGluZyB0byBhY2Nlc3MgdGhlIE5FVENPTkYvUkVTVENPTkYgY2xpZW50Lg0KPj4+PiANCj4+Pj4g V2hhdCBkbyB5b3UgdGhpbms/DQo+Pj4gDQo+Pj4gQnV0IHdoYXQgZWZmb3J0cyBjYW4gb25lIG1h a2UgYW5kIHdoYXQgaXMgdGhlIGltcGFjdCBvZiBub3QgbWFraW5nIA0KPj4+IHRob3NlIChmb3Ig dGhpcyBwcm90b2NvbCkuIFRoZSByb2xlLWNoYW5nZSBoZXJlIGlzIGEgbWlub3INCj4+PiB0cmFu c3BvcnQgY2hhbmdlIGJ1dCBkb2luZyB0aGF0IGZvciBwdWJsaWNseSByZWFjaGFibGUgaG9zdHMg aGFzIGENCj4+PiBsb3Qgb2YgY29uc2VxdWVuY2VzLg0KPj4gDQo+PiBJIGhvcGUgdGhhdCB0aGlz IHdpbGwgYmUgZGlzY3Vzc2VkIG9uIHRoZSBUTFMgV0cgYW5kIG9wZW5zc2ggbGlzdHMuDQo+PiBJ IGltYWdpbmUgdGhhdCBpdCBtYXkgY3VsbWluYXRlIGluIGJldHRlciBTZWN1cml0eSBDb25zaWRl cmF0aW9ucw0KPj4gbGFuZ3VhZ2UgaW4gdGhpcyBkcmFmdC4NCj4NCj5Ob3QgcXVpdGUuIEkgdGhp bmsgdGhlIHRscy9zc2ggZm9sa3MgY2FuIGhlbHAgdXMgd2l0aCB0aGUgZGV0YWlsDQo+b2YgcG9z c2libGUgZGlmZmVyZW5jZXMgd3J0IERvUyBpc3N1ZXMuIEluIHRoaXMgY2FzZSwgSSB0aGluayB3 ZQ0KPm5lZWQgdG8gcG9uZGVyIGl0IGEgYml0LCBhbmQgSSBjZXJ0YWlubHkgbmVlZCB0byBiZXR0 ZXIgdW5kZXJzdGFuZA0KPndoZXJlIHRoZXNlIFRMUyBjbGllbnQvVENQIHNlcnZlciB0aGluZ3Mg YXJlIGxpa2VseSB0byBiZSBkZXBsb3llZC4NCj5TbyBJJ2Qgc2F5IHdlIG91Z2h0IGNoYXQgYWJv dXQgaXQgYW5kIHNlZSB3aGF0IHdlIHRoaW5rIGZpcnN0Lg0KDQpPSy4gIFBlcmhhcHMgYSBjaGF0 IGluIFlva29oYW1hIHdvdWxkIGJlIG1vcmUgY29uZHVjaXZlLg0KDQoNCj4+IA0KPj4gDQo+PiAN Cj4+IA0KPj4gDQo+Pj4+PiAtIE9DU1A6IGFueSBpc3N1ZSB0aGVyZT8gaXMgaXQgbWFuZGF0b3J5 IHRvIHVzZSBpbiBhbnkgY2FzZQ0KPj4+Pj4gZm9yIFRMUz8NCj4+Pj4gDQo+Pj4+IEFnYWluLCB0 aGlzIGRyYWZ0IGhhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIFJGQyA3NTg5LCB3aGljaCAN Cj4+Pj4gc2F5czoNCj4+Pj4gDQo+Pj4+IEJvdGggcGVlcnMgTVVTVCB1c2UgWC41MDkgY2VydGlm aWNhdGUgcGF0aCB2YWxpZGF0aW9uIFtSRkM1MjgwXQ0KPj4+PiB0byB2ZXJpZnkgdGhlIGludGVn cml0eSBvZiB0aGUgY2VydGlmaWNhdGUgcHJlc2VudGVkIGJ5IHRoZQ0KPj4+PiBwZWVyLg0KPj4+ PiANCj4+Pj4gDQo+Pj4+IEFuZCBSRkM1MjgwIGRlZmluZXMgY2VydGlmaWNhdGUgcGF0aCB2YWxp ZGF0aW9uIGFzIGluY2x1ZGluZyANCj4+Pj4gcmV2b2NhdGlvbiBjaGVja2luZy4NCj4+PiANCj4+ PiBOby4gUmV2b2NhdGlvbiBjaGVja2luZyBpcyBvcHRpb25hbCBpbiA1MjgwLiAoU29ycnk7LSkN Cj4+IA0KPj4gT0ssIGZhaXIgcG9pbnQuICAgVG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24gdGhlbiwg bmVpdGhlciBPQ1NQIG5vciBDUkwNCj4+IHJldm9jYXRpb24gY2hlY2tpbmcgaXMgcmVxdWlyZWQg KGJ1dCBzZWUgbmV4dCBjb21tZW50IGJlbG93KS4NCj4NCj5Nb2R1bG8gbXkgZGlzY3VzcyBwb2lu dCAjMywgdGhhdCdzIGZpbmUuDQoNClRoYW5rcyBmb3IgdGhlIGNvbmZpcm1hdGlvbi4NCg0KDQo+ PiANCj4+IA0KPj4gDQo+Pj4+IFNvIGJvdGggQ1JMIGFuZCBPU0NQIGFyZSBhdmFpbGFibGUsIGFu ZCB3b3VsZCBiZSB1cCB0byB0aGUgQ0EgdG8NCj4+Pj4gc3BlY2lmeSBDUkwgZGlzdHJpYnV0aW9u IHBvaW50cyBvciBhdXRob3JpdHkgaW5mbyBhY2Nlc3MgaW4gdGhlaXINCj4+Pj4gY2VydGlmaWNh dGVzLg0KPj4+IA0KPj4+IElmIHlvdSB3YW50IGNsaWVudHMgaGVyZSB0byBzdXBwb3J0IHN0YXR1 cyBjaGVja2luZyBJIHRoaW5rIHlvdQ0KPj4+IG5lZWQgdG8gc2F5IHRoYXQgb3IgcmVmZXJlbmNl IHNvbWV0aGluZyB0aGF0IHNheXMgdGhhdC4NCj4+IA0KPj4gSXTigJlzIGNlcnRhaW5seSB0cnVl IHRoYXQgd2Ugd291bGQgKndhbnQqIE5FVENPTkYvUkVTVENPTkYgY2xpZW50cyB0bw0KPj4gZG8g cmV2b2NhdGlvbiBjaGVja2luZywgYnV0IHdlIGNhbm5vdCBtYW5kYXRlIGl0IGFzIHNvbWUgZGVw bG95bWVudHMNCj4+IGFyZSBvbiBwcml2YXRlIG5ldHdvcmtzIGFuZCBoZW5jZSB1bmFibGUgdG8g ZG93bmxvYWQgYSBDUkwgb3IgYWNjZXNzDQo+PiBhbiBPQ1NQIHNlcnZlci4NCj4+IA0KPj4gVGhh dCBzYWlkLCBJIGJlbGlldmUgdGhhdCBDNSBjb3VsZCBiZSBlbmhhbmNlZCB3aXRoIGEgU0hPVUxE IGFuZCBhDQo+PiBNVVNUIGFzIGZvbGxvd3MgKHNlZSBsYXN0IHR3byBzZW50ZW5jZXMpLiAgV291 bGQgdGhpcyB1cGRhdGUgYWRkcmVzcw0KPj4geW91ciBjb25jZXJuPw0KPj4gDQo+PiBPTEQ6DQo+ PiANCj4+IEM1ICBBcyBwYXJ0IG9mIGVzdGFibGlzaGluZyBhbiBTU0ggb3IgVExTIGNvbm5lY3Rp b24sIHRoZSBORVRDT05GLyANCj4+IFJFU1RDT05GIGNsaWVudCBNVVNUIHZhbGlkYXRlIHRoZSBz ZXJ2ZXIncyBwcmVzZW50ZWQgaG9zdCBrZXkgb3IgDQo+PiBjZXJ0aWZpY2F0ZS4gIFRoaXMgdmFs aWRhdGlvbiBNQVkgYmUgYWNjb21wbGlzaGVkIGJ5IGNlcnRpZmljYXRlIHBhdGgNCj4+IHZhbGlk YXRpb24gb3IgYnkgY29tcGFyaW5nIHRoZSBob3N0IGtleSBvciBjZXJ0aWZpY2F0ZSB0byBhIA0K Pj4gcHJldmlvdXNseSB0cnVzdGVkIG9yICJwaW5uZWQiIHZhbHVlLg0KPj4gDQo+PiANCj4+IE5F VzoNCj4+IA0KPj4gQzUgQXMgcGFydCBvZiBlc3RhYmxpc2hpbmcgYW4gU1NIIG9yIFRMUyBjb25u ZWN0aW9uLCB0aGUgTkVUQ09ORi8gDQo+PiBSRVNUQ09ORiBjbGllbnQgTVVTVCB2YWxpZGF0ZSB0 aGUgc2VydmVyJ3MgcHJlc2VudGVkIGhvc3Qga2V5IG9yIA0KPj4gY2VydGlmaWNhdGUuIFRoaXMg dmFsaWRhdGlvbiBNQVkgYmUgYWNjb21wbGlzaGVkIGJ5IGNlcnRpZmljYXRlIHBhdGgNCj4+IHZh bGlkYXRpb24gb3IgYnkgY29tcGFyaW5nIHRoZSBob3N0IGtleSBvciBjZXJ0aWZpY2F0ZSB0byBh IA0KPj4gcHJldmlvdXNseSB0cnVzdGVkIG9yICJwaW5uZWQiIHZhbHVlLiAgSWYgYSBjZXJ0aWZp Y2F0ZSBjb250YWlucyANCj4+IHJldm9jYXRpb24gY2hlY2tpbmcgaW5mb3JtYXRpb24sIHRoZSBO RVRDT05GL1JFU1RDT05GIGNsaWVudCBTSE9VTEQNCj4+IGNoZWNrIHRoZSByZXZvY2F0aW9uIHN0 YXR1cyBvZiB0aGUgY2VydGlmaWNhdGUuICBJZiBpdCBpcw0KPj4gDQo+PiBkZXRlcm1pbmVkIHRo YXQgYSBjZXJ0aWZpY2F0ZSBoYXMgYmVlbiByZXZva2VkLCB0aGUgY2xpZW50IE1VU1QgDQo+PiBp bW1lZGlhdGVseSBjbG9zZSB0aGUgY29ubmVjdGlvbi4NCj4+IA0KPg0KPkFnYWluLCB0aGF0IHNl ZW1zIGdvb2QsIG1vZHVsbyB0aGlua2luZyBhYm91dCBkaXNjdXNzIHBvaW50ICMzDQo+d2hpY2gg Y291bGQgdG91Y2ggb24gdGhpcy4gKEUuZy4gaWYgdGhlcmUncmUgbG9hZHMgb2YgZGVwbG95bWVu dHMNCj50aGF0IHdpbGwgbGlrZWx5IGJlIGFibGUgdG8gdXNlIHB1YmxpYyBDQXMgYW5kIGlmIG9u ZSBjYW4NCj5jaGFyYWN0ZXJpc2UgdGhvc2UgY3Jpc3BseSBpbiBhIHdheSBtZWFuaW5nZnVsIHRv IGEgZGV2ZWxvcGVyLA0KPnRoZW4gb25lIG1pZ2h0IHdhbnQgdG8gbWFuZGF0ZSBzdGF0dXMgY2hl Y2tpbmcgZm9yIHRob3NlIGNhc2VzLikNCg0KT0ssIHRoYW5rcyBmb3IgdGhlIGNvbmZpcm1hdGlv biBvbiB0aGUgdGV4dCBhYm92ZS4gICBSZWdhcmRpbmcgeW91ciB2ZXJ5IGxhc3QgY29tbWVudCBh Ym91dCBtYW5kYXRpbmcgZm9yIHNvbWUgZGVwbG95bWVudHMsIEnigJltIG5vdCBzdXJlIGhvdyB0 byBjb25zdHJ1Y3QgYSBNVVNUIHN0YXRlbWVudCB0aGF0IGhhcyBhbnkgbW9yZSB0ZWV0aCB0aGFu IHRoZSBTSE9VTEQgYWJvdmUuICBGb3IgaW5zdGFuY2UsIHNheWluZyBzb21ldGhpbmcgbGlrZTog IElmIHRoZSBjZXJ0aWZpY2F0ZSBjb250YWlucyByZXZvY2F0aW9uIHBvaW50ZXJzLCB0aGVuIGNs aWVudCBNVVNUIHRyeSB0byBhY2Nlc3MgYW5kIHVzZSB0aGUgcmV2b2NhdGlvbiBpbmZvcm1hdGlv buKAnSBzdGlsbCBzb3VuZHMgbGlrZSBhIFNIT1VMRCB0byBtZS4gIE1heWJlIHNvbWV0aGluZyBi ZXR0ZXIgd2lsbCBjb21lIG91dCBvZiB0aGUgZGlzY3Vzc2lvbiB3aXRoIHRoZSBUTFMgV0cgYW5k IG9wZW5zc2ggbGlzdC4NCg0KDQoNCj4+IA0KPj4gDQo+PiBUaGFua3MgYWdhaW4sIGFuZCBJIGFw b2xvZ2l6ZSBpZiB0aGlzIHRocmVhZCBpcyBiZWdpbm5pbmcgdG8gYmVjb21lDQo+PiBsb25nIC0g aG9wZWZ1bGx5IHdl4oCZbGwgc3RhcnQgY2xvc2luZyBvdXQgc29tZSBvZiB0aGVzZSBESVNDVVNT IHBvaW50cw0KPj4gc29vbiB0aG91Z2ggIDopDQo+DQo+Tm8gbmVlZCB0byBhcG9sb2dpc2UsIG1h aWwgb24gc3R1ZmYgbGlrZSB0aGlzIGlzIGp1c3QgYSBiaXQNCj5jdW1iZXJzb21lLiBBbmQgaW4g YW55IGNhc2UsIGl0J3MgbWUgdGhhdCdzIGhvbGRpbmcgdGhlIERJU0NVU1MNCj5iYWxsb3Qgc28g aWYgYW55b25lIHNob3VsZCBiZSBibGFtZWQsIEknbSBpdDotKQ0KDQpUaGF0IGlzIGRlZmluaXRl bHkgbm90IHRoZSBjYXNlIGhlcmUsIEkgYXBwcmVjaWF0ZSB5b3VyIGhlbHAhDQoNCg0KVGhhbmtz LA0KS2VudA0KDQoNCg0KDQoNCg== From nobody Fri Oct 23 15:29: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 398441B2DA6 for ; Fri, 23 Oct 2015 15:29:09 -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=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 zJbFu5OKnttd for ; Fri, 23 Oct 2015 15:29:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 62A2D1B2DA8 for ; Fri, 23 Oct 2015 15:29:08 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9NMT40t051443 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 23 Oct 2015 17:29:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Kent Watsen" Date: Fri, 23 Oct 2015 17:29:07 -0500 Message-ID: <36301A50-FA31-42ED-AD53-FB58CBFA1912@nostrum.com> In-Reply-To: <23D01C9B-C786-446B-9725-E584018300C0@juniper.net> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> <23D01C9B-C786-446B-9725-E584018300C0@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , Netconf , Barry Leiba , The IESG Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Oct 2015 22:29:09 -0000 On 22 Oct 2015, at 19:53, Kent Watsen wrote: >>>> If the client MAY be configured to listen on a non-standard port, >>>> doesn’t >>>> that imply that the server MUST be _capable_ of being configured to >>>> connect to a non-standard port? >>> >>> This is correct and what draft-ietf-netconf-server-model-08 allows. >>> Were you thinking that there needs to be a change in this draft? >> >> I think it's worth a mention. People will probably figure it out for >> themselves, but it's usually better to be explicit. > > Hi Ben, > > The draft currently has this: > > S1 The NETCONF/RESTCONF server initiates a TCP connection request to > the NETCONF/RESTCONF client. The server SHOULD connect to one of > the IANA-assigned ports defined in section Section 5, but MAY be > configured to use a non-standard port. Using the IANA-assigned > ports, the server connects to port PORT-X for NETCONF over SSH, > port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF > over TLS. > > > I should’ve pointed out the above on my earlier response. We could > replace the second sentence with: > > > The server MUST default to connecting to one of the IANA-assigned > ports defined in Section 5 and be configurable to use a non-standard > port. > > > What do you think? That works for me, thanks! > > > BTW: I just caught a typo: “section Section 5” (fixed in my local > copy). > > > > Thanks, > Kent From nobody Fri Oct 23 22:17: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 10D311ACEB6; Fri, 23 Oct 2015 22:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj5P39UxFspe; Fri, 23 Oct 2015 22:17:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615D31ACEB1; Fri, 23 Oct 2015 22:17:41 -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.306.13; Sat, 24 Oct 2015 05:17:22 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.16.52]) with mapi id 15.01.0306.003; Sat, 24 Oct 2015 05:17:22 +0000 From: Kent Watsen To: Kathleen Moriarty Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHRDAfgpOfZU3eYFEWbvakAFJEjNJ52KZiAgABYOoCAA1mSgA== Date: Sat, 24 Oct 2015 05:17:21 +0000 Message-ID: <93A12F18-FB21-4D08-B559-2E04295C5047@juniper.net> References: <20151021135330.20048.35548.idtracker@ietfa.amsl.com> <4F2C1542-6FCB-4B67-91A8-7AD55BC34EB5@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; CO1PR05MB460; 5:j0yH9nEg3uaEYvWfBKCjoZJaSCR1zBcQ6GIwSP8UMQOyqYjT2HjV9CZBJTXstD41WtIkTdzFoaD3Y9+MYOLX7D2oC/3I6tlkGaSzl/OpBWhnOHz7KQ46SdtPY4cjThm4fQm16p422iiWzaDKrQis+g==; 24:KUgXh0zrq07uo80zgMbcK9c2AQFt+qvdnlyizktFAPziNsGp9L2EYKnQZjzb67nmbOjWAfezevhjOZiqz5mmWMV30z3GjN+cd6HTDVoP3co=; 20:ykZbgAQo4SGmpHz5ii2P7MbCVq402R1vOnlaj4B7UtCgj4LGV1RNFvooM/rvIgSHMNGjROyda5vSLV8O22gL1A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102215026); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(57704003)(189002)(199003)(164054003)(87936001)(83716003)(33656002)(5007970100001)(5004730100002)(11100500001)(66066001)(36756003)(230783001)(54356999)(50986999)(76176999)(189998001)(40100003)(99286002)(82746002)(106356001)(105586002)(83506001)(106116001)(92566002)(2900100001)(10400500002)(2950100001)(4001350100001)(102836002)(5008740100001)(81156007)(5002640100001)(110136002)(5001960100002)(122556002)(97736004)(86362001)(101416001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2015 05:17:21.3567 (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: Cc: "netconf@ietf.org" , The IESG , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 05:17:46 -0000 DQpIaSBLYXRobGVlbiwNCg0KDQoNCg0KPj4+U2VjdGlvbiAyLjEgJiAzLjENCj4+PiBXaHkgaXMg YXV0aGVudGljYXRpb24gbGltaXRlZCB0byBzZXJ2ZXItc2lkZSBhdXRoZW50aWNhdGlvbj8gIEl0 IHNlZW1zDQo+Pj4gdGhhdCB0aGlzIHJlYWxseSBzaG91bGQgYmUgbXV0dWFsIGF1dGhlbnRpY2F0 aW9uIHRvIGVuc3VyZSB0aGUgc2VydmVyIGlzDQo+Pj4gYWxzbyBjb25uZWN0aW5nIHRvIHRoZSBj b3JyZWN0IGNsaWVudCBhbmQgdGhlcmUgd2FzIG5vIGF0dGFjayBwcmlvciB0bw0KPj4+IHRoZSBj YWxsYmFjay4NCj4+IA0KPj4gDQo+PiBCb3RoIE5FVENPTkYgYWQgUkVTVENPTkYgcmVxdWlyZSBj bGllbnQgYXV0aGVudGljYXRpb24sIGFuZCB0aGlzIGlzIGNhbGxlZCBvdXQgaW4gdGhlIEFwcGxp Y2FiaWxpdHkgU3RhdGVtZW50IChTZWN0aW9uIDEuMykuICBBbHNvLCBpbiB0aGUgIlRoZSBORVRD T05GIG9yIFJFU1RDT05GIENsaWVudOKAnSBzZWN0aW9uLCBpdCBzYXlzOg0KPj4gDQo+PiAgIEM3 ICBBZnRlciB0aGUgc2VydmVyJ3MgaG9zdCBrZXkgb3IgY2VydGlmaWNhdGUgaXMgdmFsaWRhdGVk LCB0aGUgU1NIDQo+PiAgIG9yIFRMUyBwcm90b2NvbCBwcm9jZWVkcyBhcyBub3JtYWwgdG8gZXN0 YWJsaXNoIGEgU1NIIG9yIFRMUw0KPj4gICBjb25uZWN0aW9uLg0KPj4gDQo+PiBUaGUg4oCccHJv Y2VlZHMgYXMgbm9ybWFs4oCdIGlzIGludGVuZGVkIHRvIGNvdmVyIGNsaWVudCBhdXRoZW50aWNh dGlvbi4gIA0KPg0KPk9rLCB0aGlzIHdhc24ndCBjbGVhciB0byBtZSwgYnV0IHByb2JhYmx5IGlz bid0IHRoZSBzZW50ZW5jZSB0byBmaXguDQoNCg0KSW4gdGhlIERJU0NVU1Mgd2l0aCBTdGVwaGVu LCBJIG9mZmVyZWQgdG8gYWRkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byB0aGUgZW5kIG9mIEM3Og0K DQogIFdoZW4gcGVyZm9ybWluZyBjbGllbnQtYXV0aGVudGNhdGlvbiB3aXRoIHRoZSBORVRDT05G L1JFU1RDT05GDQogIHNlcnZlciwgdGhlIE5FVENPTkYvUkVTVENPTkYgY2xpZW50IE1VU1QgZW5z dXJlIHRvIG9ubHkgdXNlDQogIGNyZWRlbnRpYWxzIHRoYXQgaGFkIHByZXZpb3VzbHkgYXNzb2Np YXRlZCBmb3IgdGhlIE5FVENPTkYvUkVTVENPTkYNCiAgc2VydmVy4oCZcyBwcmVzZW50ZWQgaG9z dCBrZXkgb3Igc2VydmVyIGNlcnRpZmljYXRlLg0KDQpJIGtub3cgeW91IHNhaWQgdGhpcyBtYXkg bm90IGJlIHRoZSBzZW50ZW5jZSB0byBmaXgsIGJ1dCBkb2VzIGl0IHJlc29sdmUgdGhpcyBpc3N1 ZSBmb3IgeW91Pw0KDQoNCg0KDQoNCg0KPj4gQWxzbywgaW4gdGhlICJUaGUgTkVUQ09ORiBvciBS RVNUQ09ORiBTZXJ2ZXLigJ0gc2VjdGlvbiwgaXQgc2F5czoNCj4+IA0KPj4gDQo+PiAgIFM1ICBJ biBtb3N0IGNhc2VzLCBlc3RhYmxpc2hpbmcgdGhlIFNTSCBvciBUTFMgY29ubmVjdGlvbiBhbHNv DQo+PiAgIGVudGFpbHMgc2VydmVyIGF1dGhlbnRpY2F0aW9uIG9mIGNsaWVudCBjcmVkZW50aWFs czsgb25seSB3aXRoDQo+PiAgIFJFU1RDT05GIGRvIHNvbWUgY2xpZW50IGF1dGhlbnRpY2F0aW9u IHNjaGVtZXMgb2NjdXIgYWZ0ZXIgdGhlDQo+PiAgIHNlY3VyZSB0cmFuc3BvcnQgY29ubmVjdGlv biAoVExTKSBoYXMgYmVlbiBlc3RhYmxpc2hlZC4gIA0KPg0KPkkgdGhpbmsgaWYgdGhpcyBzYWlk LCAiRXN0YWJsaXNoaW5nIGFuIFNTSCBvciBUTFMgc2Vzc2lvbiByZXF1aXJlcyBzZXJ2ZXIgYXV0 aGVudGljYXRpb24gb2YgY2xpZW50IGNyZWRlbnRpYWxzLCB3aXRoIHRoZSBleGNlcHRpb24gb2Yu Li4iDQo+DQo+VGhlIHBvaW50IHdvdWxkIGJlIG1vcmUgY2xlYXIgYXMgSSBkaWRuJ3QgcmVhbGl6 ZSB0aGlzIHdhcyBhbHJlYWR5IHRoZSBjYXNlIGZyb20gdGhlIGxhbmd1YWdlIGluIHRoaXMgZHJh ZnQuDQoNCkNvbnNpZGVyIGl0IGRvbmUuDQoNCg0KDQoNCg0KPj4gSWYNCj4+ICAgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGlzIHJlcXVpcmVkLCBhbmQgdGhlIGNsaWVudCBpcyB1bmFibGUgdG8NCj4+ ICAgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZSBpdHNlbGYgdG8gdGhlIHNlcnZlciBpbiBhbiBh bW91bnQgb2YNCj4+ICAgdGltZSBkZWZpbmVkIGJ5IGxvY2FsIHBvbGljeSwgdGhlIHNlcnZlciBN VVNUIGNsb3NlIHRoZQ0KPj4gICBjb25uZWN0aW9uLg0KPj4gDQo+PiBXaGljaCBzcGVha3MgdG8g aXQgYXMgd2VsbC4NCj4+IA0KPj4gDQo+PiBEbyB5b3UgYmVsaWV2ZSB0aGVyZSBpcyBhIG5lZWQg dG8gY2hhbmdlIHRoZSB0ZXh0Pw0KPg0KPlllcywgYnV0IGp1c3QgdGhlIHRleHQgd2hlcmUgSSBt YWRlIGEgc3VnZ2VzdGlvbnMgdSBiZSBlbm91Z2ggdG8gZ2V0IHRoZSBwb2ludCBhY3Jvc3MgbW9y ZSBjbGVhcmx5Lg0KDQpTdXJlLCBJ4oCZbGwgbWFrZSB0aGUgZml4IG1lbnRpb25lZCBhYm92ZS4N Cg0KDQoNCg0KDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+PiAzLjEgUzMgLSBXaHkgaXMgY2xpZW50 LXNpZGUgYXV0aGVudGljYXRpb24gb3B0aW9uYWw/DQo+Pj4gDQo+Pj4gV2l0aG91dCB0aGlzIG11 c3QsIHRoZXJlIHNob3VsZCBiZSBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gdGhhdCB0aGUgY2Fs bA0KPj4+IGJhY2sgY291bGQgZ28gdG8gYSBtYWxpY2lvdXMgY2xpZW50LiAgVGhlIHR5cGVzIG9m IGF1dGhlbnRpY2F0aW9uIG1hdHRlcg0KPj4+IGFzIHdlbGwsIGJ1dCB0aGF0J3MgY292ZXJlZCBp biBTdGVwaGVuJ3MgZGlzY3VzcyBwb2ludHMgYWxvbmcgd2l0aCB0aGUNCj4+PiBTZWNEaXIgcmV2 aWV3IHF1ZXN0aW9ucyBvbiBUTFMtUFNLLg0KPj4gDQo+PiBEbyBtZWFuIFM1IHBhc3RlZCBhYm92 ZSB3aGVyZSBpdCBzYXlzIOKAnElmIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyByZXF1aXJlZOKA nT8NCj4NCj5ZZXMuDQoNCk9MRDoNCg0KICAgUzUgIEluIG1vc3QgY2FzZXMsIGVzdGFibGlzaGlu ZyB0aGUgU1NIIG9yIFRMUyBjb25uZWN0aW9uIGFsc28NCiAgICAgIGVudGFpbHMgc2VydmVyIGF1 dGhlbnRpY2F0aW9uIG9mIGNsaWVudCBjcmVkZW50aWFsczsgb25seSB3aXRoDQogICAgICBSRVNU Q09ORiBkbyBzb21lIGNsaWVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIG9jY3VyIGFmdGVyIHRo ZQ0KICAgICAgc2VjdXJlIHRyYW5zcG9ydCBjb25uZWN0aW9uIChUTFMpIGhhcyBiZWVuIGVzdGFi bGlzaGVkLiAgSWYNCiAgICAgIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyByZXF1aXJlZCwgYW5k IHRoZSBjbGllbnQgaXMgdW5hYmxlIHRvDQogICAgICBzdWNjZXNzZnVsbHkgYXV0aGVudGljYXRl IGl0c2VsZiB0byB0aGUgc2VydmVyIGluIGFuIGFtb3VudCBvZg0KICAgICAgdGltZSBkZWZpbmVk IGJ5IGxvY2FsIHBvbGljeSwgdGhlIHNlcnZlciBNVVNUIGNsb3NlIHRoZQ0KICAgICAgY29ubmVj dGlvbi4NCg0KTkVXOiAgIHMvY2xpZW50L3RyYW5zcG9ydCAoU1NIIG9yIFRMUykgbGV2ZWwgY2xp ZW50Lw0KDQoNCiAgIFM1IEluIG1vc3QgY2FzZXMsIGVzdGFibGlzaGluZyB0aGUgU1NIIG9yIFRM UyBjb25uZWN0aW9uIGFsc28NCiAgICAgIGVudGFpbHMgc2VydmVyIGF1dGhlbnRpY2F0aW9uIG9m IGNsaWVudCBjcmVkZW50aWFsczsgb25seSB3aXRoDQogICAgICBSRVNUQ09ORiBkbyBzb21lIGNs aWVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIG9jY3VyIGFmdGVyIHRoZQ0KICAgICAgc2VjdXJl IHRyYW5zcG9ydCBjb25uZWN0aW9uIChUTFMpIGhhcyBiZWVuIGVzdGFibGlzaGVkLiBJZg0KICAg ICAgdHJhbnNwb3J0IChTU0ggb3IgVExTKSBsZXZlbCBjbGllbnQgYXV0aGVudGljYXRpb24gaXMg cmVxdWlyZWQsIGFuZCB0aGUgY2xpZW50IGlzIHVuYWJsZSB0bw0KICAgICAgc3VjY2Vzc2Z1bGx5 IGF1dGhlbnRpY2F0ZSBpdHNlbGYgdG8gdGhlIHNlcnZlciBpbiBhbiBhbW91bnQgb2YNCiAgICAg IHRpbWUgZGVmaW5lZCBieSBsb2NhbCBwb2xpY3ksIHRoZSBzZXJ2ZXIgTVVTVCBjbG9zZSB0aGUN CiAgICAgIGNvbm5lY3Rpb24uDQoNCg0KRG9lcyB0aGlzIHRleHQgcmVzb2x2ZSB5b3VyIGlzc3Vl Pw0KDQoNCg0KDQoNCj4+IA0KPj4gVGhpcyB0ZXh0IGlzIHNwZWFraW5nIGFib3V0IHRyYW5zcG9y dC1sZXZlbCBjbGllbnQtYXV0aC4gIE5FVENPTkYgb3ZlciBTU0ggb3Igb3ZlciBUTFMgYm90aCBo YXZlIHRyYW5zcG9ydC1sZXZlbCBhdXRoZW50aWNhdGlvbiwgYnV0IFJFU1RDT05GIChlLmcuLCBI VFRQUykgYWxsb3dzIHRoZSBCYXNpYyBhbmQgRGlnZXN0IGF1dGhlbnRpY2F0aW9uIG1vZGVzLCBh bmQgdGhhdCBjbGllbnQgYXV0aCBoYXBwZW4gYWZ0ZXIgdGhlIFRMUyBzZXNzaW9uIGlzIGVzdGFi bGlzaGVkLg0KPg0KPk9rLCBpcyBpdCBwb3NzaWJsZSB0byBtYWtlIHRoaXMgbW9yZSBjbGVhcj8g IEkgdGhpbmsgU3RlcGhlbiBoYXMgYSBkaXNjdXNzIG9uIEhUVFBBdXRoIG1ldGhvZHMgYWxyZWFk eSwgc28gdGhhdCBjYW4gYmUgZGlzY3Vzc2VkIGluIGhpcyB0aHJlYWQuICBJIGp1c3QgYXNrIHRo YXQgeW91IHBvaW50IHRvIHRoZSBuZXdseSB1cGRhdGVkIFJGQ3Mgb24gdGhlc2UgMiBzdGFuZGFy ZHMgYXMgdGhleSBkbyBhIGdvb2Qgam9iIG9mIG91dGxpbmluZyBhbGwgb2YgdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zLCB3aGljaCBhcmUgc3Vic3RhbnRpYWwuICBSRkM3NjE2ICYgUkZDIDc2 MTUNCg0KU3VyZSAgKGJ1dCBJ4oCZbGwgYXNzdW1lIHlvdSBtZWFudCA3NjE3LCBpbnN0ZWFkIG9m IDc2MTYpDQoNCg0KDQoNCg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+Pj4gSW4gc2VjdGlvbiAxLjMs IHBsZWFzZSBhZGQgYSBzZW50ZW5jZSB0aGF0IHBvaW50cyB0byB0aGUgdGhyZWF0L3NlY3VyaXR5 DQo+Pj4gYW5hbHlzaXMgZm9yIHVzZSBvZiB0aGlzIGZ1bmN0aW9uIHdpdGggTkVUQ09ORiBhbmQg UkVTVENPTkYgYWZ0ZXIgdGhlDQo+Pj4gbGFzdCBzZW50ZW5jZToNCj4+PiANCj4+PiAgSW4gc3Vj aCBjaXJjdW1zdGFuY2VzLCBhbGxvd2luZyB0aGUgU1NIL1RMUyBzZXJ2ZXIgdG8gY29udGFjdCB0 aGUNCj4+PiAgU1NIL1RMUyBjbGllbnQgd291bGQgb3BlbiBuZXcgdnVsbmVyYWJpbGl0aWVzLiAg QW55IHVzZSBvZiBjYWxsIGhvbWUNCj4+PiAgd2l0aCBTU0gvVExTIGZvciBwdXJwb3NlcyBvdGhl ciB0aGFuIE5FVENPTkYgb3IgUkVTVENPTkYgd2lsbCBuZWVkIGENCj4+PiAgdGhvcm91Z2gsIGNv bnRleHR1YWwgc2VjdXJpdHkgYW5hbHlzaXMuDQo+PiANCj4+IFVuZm9ydHVuYXRlbHksIHRoZXJl IGlzbid0IGFuIGFuYWx5c2lzIHRvIHBvaW50IHRvLiAgVGhlIOKAnGFuYWx5c2lz4oCdIGlzIGhh cHBlbmluZyBub3cgYWxvbmcgd2l0aCB0aGUgU2VjRGlyIHJldmlldy4gICBEbyB3ZSBuZWVkIHRv IHBlcmZvcm0gc3VjaCBhbiBhbmFseXNpcyBub3c/DQo+PiANCj5UaGUgc2VjdGlvbiByZWFkcyBh cyBpZiBvbmUgZXhpc3RzIGFuZCB0aGF0IHlvdSd2ZSBtaXRpZ2F0ZWQgdGhlIHJpc2tzLiAgQXMg c3VjaCwgSSdkIGV4cGVjdCB0byBzZWUgYWxsIG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBmb3IgdXNpbmcgdGhlIG1ldGhvZCBkZWZpbmVkIGluIHRoaXMgZHJhZnQuICBNYWtpbmcgdGhl IGF1dGggcmVxdWlyZW1lbnRzIG1vcmUgY2xlYXIgd2lsbCBoZWxwIGFuZCBwb2ludGluZyBvdXQg dGhlIHZ1bG5lcmFiaWxpdHkgb2YgdGhlIEhUVFBBdXRoIGJhc2ljIGFuZCBkaWdlc3QgbW9kZXMg Zm9yIFJFU1RDT05GIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpcyBwYXJ0IG9mIHRo YXQuICANCj4NCj5NZW50aW9uIG9mIHRoZSBwb3NzaWJpbGl0eSBvZiBjb25uZWN0aW5nIHRvIGFu IGluY29ycmVjdCBjbGllbnQgKHBvc3NpYmx5IG1hbGljaW91cykgaW4gdGhlIGZldyBpbnN0YW5j ZXMgd2hlcmUgY2xpZW50IGF1dGggaXNuJ3QgcmVxdWlyZWQgb3IgaXMgd2VhayBpcyBpbXBvcnRh bnQgYXMgd2VsbCBmb3IgdGhlIHJlYWRlci4NCg0KDQpIbW1tLCBzbyBJ4oCZbSBub3Qgc3VyZSB3 aGF0IHRvIGRvIHdpdGggdGhpcyBjb21tZW50LiAgDQoNClllcywgcGVyIFN0ZXBoZW7igJlzIERJ U0NVU1MsIG1ha2UgdGhlIGF1dGggcmVxdWlyZW1lbnRzIG1vcmUgY2xlYXIsIGFuZCBwb2ludCBv dXQgdGhlIHZ1bG5lcmFiaWxpdHkgb2YgdGhlIEhUVFBBdXRoIGJhc2ljIGFuZCBkaWdlc3QgbW9k ZXMgZm9yIFJFU1RDT05GIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyAocGVuZGluZyBm ZWVkYmFjayBmcm9tIFRMUyBXRyBhbmQgb3BlbnNzaCBsaXN0KS4NCg0KQnV0IGJhY2sgdG8gU2Vj dGlvbiAxLjMsIGlzIHRoZXJlIGEgc3BlY2lmaWMgY2hhbmdlIGluIHRoZSB0ZXh0IHRoYXQgeW91 4oCZcmUgaG9waW5nIHRvIHNlZSBoZXJlPw0KDQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQoN Cg== From nobody Sat Oct 24 04:42: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 2E6B41B337D; Sat, 24 Oct 2015 04:42: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, 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 MNWV4XiDxSs9; Sat, 24 Oct 2015 04:42:39 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8101B3382; Sat, 24 Oct 2015 04:42:37 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.1.306.13; Sat, 24 Oct 2015 11:42:16 +0000 Message-ID: <019401d10e50$ee9d16e0$4001a8c0@gateway.2wire.net> From: t.petch To: Ben Campbell , Kent Watsen References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> <23D01C9B-C786-446B-9725-E584018300C0@juniper.net> <36301A50-FA31-42ED-AD53-FB58CBFA1912@nostrum.com> Date: Sat, 24 Oct 2015 12:41:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: AM3PR02CA0043.eurprd02.prod.outlook.com (10.242.240.43) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 2:HOd5fvJ/YXKDEja+R8HNT5w5vsrJl2htTSA1/v2A5/mhPqLsDpwnUxP1t26qQEbR+Ukpl/yCF2uzMwxg/iVEXEH0duyb40X+yymQAySBxp+P7rcXSnLwU10I0JdmS74nkRIJDOSUDdGWJDt99a0OuKRLLflurwRolc9zMcoFG2w=; 3:PFTdJf9tE8Hg0Jh9f3a4+OYgDAMUSlQONmjbq+A6TJm8rc8bCrDQN2xk/wE7NwV+9VFRbbS3oJhjHSckmfx6KJVQgCv9vzP6WFlGqVsfbjLbl4cDHt+n2Rjkcy4t8Qa6rHV5tceOYzvoRfMcKu6MwQ==; 25:ghplYnGaEai6YyIERR1/FSYSJSQruOsKQ2bdlHgwTDajCY9kvucCnwVq2F1BypKGhojRzTXiRr5RyxEFAVQuaCzw0UkpLHX+vWIs9epwX/Ou6ycsF25WeeS6Z53UtfHypZMx1g6k2eyLdRGhKXnk6ECZq43ZXtgl8AzPgXxPXlpQ1U+/OG72hOL/Yai0OpKMuZnJ1e5Ke5JJlAY7rNz2ZtG4XcF0kzzkQA0nO+24EjbRDhfKF8+SMMQ9soPNWDnscW8BStMGRh6kPsutupJx6w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026); SRVR:DBXPR07MB062; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB062; X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 4:hUiHYsqKnV1oQkaB29Bho3GubnMdLZdDgFPRxvHdlx0rcPYatwB4TDdaDr8l2OZjs/Huz0CsNfU0gIbEpF8H3zRW2tCZjzDZgkedbs0M5JccJ8Z27NMlmuuByw1/9yUAEEfXWcpDDQPxeM8kD6MH+wB2tRax9XcZhRlL1iWSn0tC62cHoypSF9E47zwdtyx7Y7eQoSeucV2Jn3KyZ3HPk2D52munUWkxMFowbk05g18LqvquMQ1pY5WoLZxvCt+MV8pw3k6KYG2Kbnk/RZeh1tpF9SUgUd+E63QmkpsDufYxedHWeSFaW+K9+moRUfvJP36B4tOpLFhHxldXQIsyASFCYEajqT/ERnMUGPjvcA4P1kzrNZYA8rCI4UOzlfDk X-Forefront-PRVS: 073966E86B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(199003)(76104003)(51444003)(24454002)(189002)(164054003)(81156007)(106356001)(40100003)(5001960100002)(5001770100001)(105586002)(97736004)(14496001)(50986999)(15975445007)(62236002)(44716002)(47776003)(77096005)(189998001)(81816999)(101416001)(76176999)(81686999)(23676002)(87976001)(1556002)(66066001)(1456003)(86362001)(93886004)(92566002)(230783001)(33646002)(44736004)(5004730100002)(1941001)(50226001)(19580395003)(84392001)(42186005)(19580405001)(61296003)(122386002)(5007970100001)(50466002)(5008740100001)(116806002)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQlhQUjA3TUIwNjI7MjM6OERORjF0RWZ1V25BcytWM2cyQVUzSGdOSExI?= =?utf-8?B?UFRTdzJhKzgrRS9CelQwQkx2QnhYZzQwaFZ1dWlReHhBQzRsQ3h6R2M1Yk1B?= =?utf-8?B?VEVUb1d2N2d2NnB1RlJlZzd3akt6QUxKSk5EakVndVRWdWZWUDJNcHd5d0xk?= =?utf-8?B?VHovYllIbmgveDVTcmJobkZKWmg0dE1DRUhpNlJUUjNUUG9PTDZzVW9yalA4?= =?utf-8?B?ZTBtTmpNaGIyNFBYSVBiNGRXZGZVYXZQUFoza3NBRWtTM0orQitpVkNLeUp1?= =?utf-8?B?R2RnUFZvSzJWVE10bjJxSCtMcytCNmp5U1ZDTzBMc0FFOU00R09xL1ROaHVN?= =?utf-8?B?ZkdobjFqd0hvdlJvdjd4Zkt4bG15eHB5cHhmU0ZieS8vZDIxUlp2N2R5ZHhD?= =?utf-8?B?UERXa0ZXbmhnMkx2cG5OcjBQUTJnejRhT1kvR2tuSHl1R1k2YmJXbkt5TFdi?= =?utf-8?B?T1F6VXgxTFloNk1oOVpzOE1JTmI5YmlZR1Z5MGNIam44ZEZVbDNUT1BJOEZL?= =?utf-8?B?YzQ3RUhFbjFOYUc0aWhmZVJwYkhGZVBjWnFBd09nY2hkRlRIRlJwcjB5dHRo?= =?utf-8?B?TTYrVmRWZkY0ckZoK2VNUEJlVHdhckV4M0ZuREZIWTE0NC9nb1c5VlozdWdN?= =?utf-8?B?MmN2TkR6ZDNBV3BhYklJUzRqMit1UHczenB4dE56TEJYY2wvM2hTZksxdTRT?= =?utf-8?B?Rjlmb0hXdStTVmtLa2FGVllhbjkyK2dIVFZsZTltY0JqUForanIzdjlFZWZh?= =?utf-8?B?RXNjWDJYdW8xcXl3VFgrUUhFQmcxTFA3ZXpTWklsWnY3UnBQRkI1dVhKZnpP?= =?utf-8?B?YVh2Rk40MSsveS9HSHJ2TS9tRWRHMkc3RU1pWmU5V3RGQ3MzYWtsbFhzbzY0?= =?utf-8?B?bFZ2eXFNd21jUzJ4Z0ZjTFR3bzN3SDlsQW5CS1dMd2RJSjcwMWNHUFJKWS9W?= =?utf-8?B?L3BkNHVqbVZhQUszVjExWkhwSlpucmVERzgyRlBoQWExN1J6NFFRNkRxOEJm?= =?utf-8?B?RnRYcjlLRHdHandnWEhUZjZON29PSU5taWhlNm1MUXNjMk5JTnBlalJuclZ1?= =?utf-8?B?a05xdk9rTGREY2kwdzhZblJZUkt0d1N6YXY5aVNockF6d1NKQUdHTGhTeHdq?= =?utf-8?B?cWVrcmNDMkYrY2g0d1MyUXJqS2JNaU85WWRGSDJyRlp3VURaZVdndis4NUIy?= =?utf-8?B?RklGeTRDeDE5L0I1eStMNmhDQXV3YmpCd0ljL3FmSE5qZEhpeng1OEtBK1JU?= =?utf-8?B?N2R3SFNaSzdFZTJRZDNtWmNtcVVQdnZmOC9NSk9mSFpPUklENzZOVnRrQ3VK?= =?utf-8?B?c3QyeVM1aW5IU243U1BCeDByU1l0UUlpZi90aVlrTUd3U3llMjIramJHczZm?= =?utf-8?B?R1JHbStPQ1dRQ2dQM2lha25sOFEzNE5udnRpK0tqTkFhVXMyOUhGSjJMcldD?= =?utf-8?B?M2FXS0R0WFJtYlpCbERycXdGTUoxazYwWnlSSFlrSzBjbmpBUlk4dzREVlpZ?= =?utf-8?B?V1FqOWZuZHNWaVdYblZvbmZXRDRwSHJ6TXo1U3JsV0N1dGh5R3hxcXJTTHVG?= =?utf-8?B?Vy9Dcks5Um8yOUJTRCtvVlZSZnRoZDE1OStrVWV5aTlabDVmNjlZSis5M2Zj?= =?utf-8?B?N2JUcWRnY3Q5aFBGWVBGV1B2NEUxakxsOWpVdkN6THdzdHpzZkkrK29aZUFQ?= =?utf-8?B?U3dibXRMRHNKSkExdjliZEJLQXg4cVh1V0VoT3FrTjBBYis1U2o3S2cza3cr?= =?utf-8?B?U2VYZWxpcGZiM3ZYZkFVQnhHM3VzbUFLK2J0bHJMMVQ3Z3VUR2FKQjYyT29j?= =?utf-8?B?TzFvNWpFQU5GRndSNFRNa0JqdEVNZU9NTUdSZmhaYUlyOCs2L2pva1dMNk5E?= =?utf-8?Q?9zcY4uSsF2kiZPmBsTzKC3z0E5PssTu?= X-Microsoft-Exchange-Diagnostics: 1; DBXPR07MB062; 5:mx5f94Jvm1x/PDC1izedZFg/quGvUeMYRAI33zuSIHos18tt56LeW/lx6t3wzGJWkDqJtBm7+paQggdf+570i/Dhvp2RXUekI1/zqvmOBRHoSn3RBLFXUHt3muGwb/DOeKQODHmIS3Sq9Y8EJxQ1dw==; 24:ykA1k2PV/71t86g2WEfTj6unYETus7GSRbsbIFlDJCVAp3PDaM0z/IcjxOlMUMP4x3lywlvo6YiY3B8OXfMhEg9r94jmyGcPM6Db3JVtDRg=; 20:riFwjxB9Jm8IPg0SKgk33xi6KrsWMN6DkhYSWZHhCIKgj+BcF4L/umgkPYS8Taopa02jjIWe03/4WXi3Pd0N+w== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2015 11:42:16.2685 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062 Archived-At: Cc: The IESG , Barry Leiba , netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 11:42:41 -0000 ----- Original Message ----- From: "Ben Campbell" To: "Kent Watsen" Cc: ; ; "Netconf" ; "Barry Leiba" ; "The IESG" Sent: Friday, October 23, 2015 11:29 PM > On 22 Oct 2015, at 19:53, Kent Watsen wrote: > > >>>> If the client MAY be configured to listen on a non-standard port, > >>>> doesn’t > >>>> that imply that the server MUST be _capable_ of being configured to > >>>> connect to a non-standard port? > >>> > >>> This is correct and what draft-ietf-netconf-server-model-08 allows. > >>> Were you thinking that there needs to be a change in this draft? > >> > >> I think it's worth a mention. People will probably figure it out for > >> themselves, but it's usually better to be explicit. > > > > Hi Ben, > > > > The draft currently has this: > > > > S1 The NETCONF/RESTCONF server initiates a TCP connection request to > > the NETCONF/RESTCONF client. The server SHOULD connect to one of > > the IANA-assigned ports defined in section Section 5, but MAY be > > configured to use a non-standard port. Using the IANA-assigned > > ports, the server connects to port PORT-X for NETCONF over SSH, > > port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF > > over TLS. > > > > I should’ve pointed out the above on my earlier response. We could > > replace the second sentence with: > > > > > > The server MUST default to connecting to one of the IANA-assigned > > ports defined in Section 5 and be configurable to use a non-standard > > port. > > > > What do you think? I think that that introduces a fresh ambiguity. Does it mean MUST default and MUST be configurable? Probably not. I suggest The server MUST default to connecting to one of the IANA-assigned ports defined in Section 5 and MAY be configurable to use a non-standard port which I think more in line with the consensus of theWorking Group. Except that you are now moving S1 out-of-line with C1 which I think will cause confusion. The original wording allows them to be the same. Introducing the idea of 'MUST default' may force them to be different. Tom Petch > > That works for me, thanks! > > > > > > > BTW: I just caught a typo: “section Section 5” (fixed in my local > > copy). > > > > > > > > Thanks, > > Kent > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Oct 26 01:31: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 BD6721B2C02; Mon, 26 Oct 2015 01:31:04 -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 zOKRlApGu4O9; Mon, 26 Oct 2015 01:31:03 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 DBFA41B2C01; Mon, 26 Oct 2015 01:31:02 -0700 (PDT) Received: by wijp11 with SMTP id p11so153864088wij.0; Mon, 26 Oct 2015 01:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=HOsh0x5sxya/k9zZfqw9HnYnNcSpRcMgFNY5/+5x058=; b=gIRbSs0THl23Iy6mJhzVVhq82mIL6cpkS0kLYJhOGIrZ61d5lRsFpN1KBCTNTKs55Y lLLA06lp1ODTDpTRbwZUZFZYo+fssxH75NO0M05JvpghXBu/O/PH/+N+mT436m13YUP4 bGqJEWP+K0uMU+Rqeg03LQNXMiCDvWUwF6fwT9jdEzmWSCe0e7NfUY3jvMBif7+PXTwN iSz+oV2yNR9sO5ZIrLFabXDeTOIccxTo3RtOfYf/INvD2KAENsZUXF7KFzjH3OVF0pWw 1sJX7PcyyWF8qg1c9D8BAYb776cOabNorPEsgzRXiD1fC6wdljlrNUnn+K/Bm824/ojv Xt2Q== X-Received: by 10.180.10.104 with SMTP id h8mr17395688wib.21.1445848261281; Mon, 26 Oct 2015 01:31:01 -0700 (PDT) Received: from Martins-MacBook-Pro.local (tmo-107-127.customers.d1-online.com. [80.187.107.127]) by smtp.googlemail.com with ESMTPSA id lb2sm688727wjc.15.2015.10.26.01.30.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Oct 2015 01:30:59 -0700 (PDT) To: Kent Watsen , The IESG References: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> From: Martin Stiemerling Message-ID: <562DE4BD.3040504@gmail.com> Date: Mon, 26 Oct 2015 09:30:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 08:31:04 -0000 Hi Ken, all, Am 21.10.15 um 23:19 schrieb Kent Watsen: > Hi Martin, > > Thank you for your review. > > > > >> 1) Why is this parapraph below (and subsequently the other similar >> ones) using RFC 2119 language with respect to the port numbers The >> NETCONF/RESTCONF client listens for TCP connection requests from >> NETCONF/RESTCONF servers. The client SHOULD listen for connections >> on the IANA-assigned ports defined in section Section 5, but MAY be >> configured to use a non-standard port. >> >> Using the right port number is not something that influences the >> interoperability of the protocol per se, but is an operational >> parameter. Checking other protocol specifications, e.g. HTTP/1.1, >> there is no RFC 2119 language about the usage of specific port >> numbers. > > This is true. I don’t see RFC 2119 language in RFC 4253 either. > That said, is it in any way wrong or bad? I’m happy to change the > text of course, just want to confirm... I would remove RFC 2119 language in those paragraphs, as this does not need RFC 2119 language. > > > >> 2) I am not a fan of having different port numbers to >> differentiate different vanilla flavors of a protocol. However, I >> can understand the why this is happening this way. But what is >> happening if there is X-over-TLS/SSH/foo coming after RESTCONF? Are >> you again in need of more port numbers? This does not look like a >> tactical wise and sustainable way. > > Joe Touch made a similar comment about a year and a half ago. There > was quite a debate about it then. We discussed the option of having > just one port for any number to TCP-based call home protocols. In > the end, the WG consensus was to use distinct ports as written in the > current text. Is this something you would like to raise again now? No, as this has been discussed in the WG and there is consensus to do it as it is documented. This is just to state that this design is not future proof nor sustainable. > > > >> >> 3) This document will benefit from an overview figure that details >> who is the server/client on what level for what. > > > I tred this before and the comment received was that it was > confusing: > http://www.ietf.org/mail-archive/web/netconf/current/msg09978.html. > But that was just one opinion. What do you think about the diagram > in the linked message? This would be good, may be it is worth saying that the arrows are pointing from the initiator away. Thanks! Martin > > > > Thanks again, Kent > > From nobody Mon Oct 26 02:38: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 E713E1B39AB; Mon, 26 Oct 2015 02:38:41 -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, 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 Rfn40nXfVoYL; Mon, 26 Oct 2015 02:38:38 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFA91B39A6; Mon, 26 Oct 2015 02:38:36 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.1.306.13; Mon, 26 Oct 2015 09:38:19 +0000 Message-ID: <01a401d10fd1$ef98b900$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , The IESG , Martin Stiemerling References: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> <562DE4BD.3040504@gmail.com> Date: Mon, 26 Oct 2015 09:37:22 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB4PR02CA0029.eurprd02.prod.outlook.com (10.242.174.157) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 2:zwkSOzCfwgMmr5yp4Y6vZaLHImoD6Naf8341YUeHYnnbjA6tLwKqC8XsQLVqHv3UEoUrWVDloE6pfHjZ+Hs+Ef+W//rbSa414hYQLX5ibx3XRtvlkUthjPgWoW6y8q7VevB4PGlCONAgxQzLNkX27kMoCq+I1OG5TX6vm+Ygmwc=; 3:mUlQy5PGje6T7HIzYH6xLCKGeRfXgS4TVa3NqztlRmJE8KsCX6Np6EsdfKyf1IahUsuzyvarShkTN7cxfitP6vyafJ0AKT2ppp7Pe3jwj4bxWcMP6Rc6JH+vC/WGgIRvbzzdzGDh/babY2gTn+uTkw==; 25:Ut0lI8BIYAdSIyYzvNqFxykaENsYooJPZfHrZ+tomzf3PNiLltNyoWPXbunbIk8a6wehrf4rScW428Z4EUB/A8FT6hkI8yb0k2yNbI7hnJuxGxfGV0vHO/CE/Qntto6kfq+o7lFtuKBpKvU/LQlvFQhIS+MzUIU+W+rE11SW1jA5uvRYwT7M/D9MZ8p90Xe5S4l9brILbmPzk4kbCKGY180bAbeJBGnajiqV1na61WNVuUiFrbyb+mwK8PYYXUnOqKute8HFLLIivLOtVwTu3w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:AMSPR07MB052; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB052; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 4:NjIxurzlaxOWrykJdL493U00Om/zi/EWNRrQ/EbQeeL61nttuMo79Ops6M0hFRT3onJl3KOcbY9HNuGScaZ8WTLZVSGV4MYONc/8yhaAY7Ly0U+OzqdxRJxJLA38NeyhS064sGjyBM8xThBupu4EeNP+CaMke9vZJoedMyBfssCCfZrZcGspskgmanQZKwWRF8rrFjNBWoIWi4V4GFHPVONRMJSpmK7wBHi55r4pwt2eKDt864T42ItRLyOUqx/3EjlRKq40tF6olU824cmjhJNBFavaTsAQGd6/Zkd6x4LcPUalEwysjpMCQ5l9P68Z6G9phvbQwZe966E1X5Qu3rQIEYrsGPFPXzOtDeYI0uyndyHwh1NmoRAzsUHML3fj X-Forefront-PRVS: 0741C77572 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(43784003)(199003)(189002)(51444003)(377454003)(76104003)(77096005)(5008740100001)(50466002)(1941001)(5007970100001)(61296003)(23676002)(19580405001)(122386002)(19580395003)(5004730100002)(97736004)(92566002)(5001770100001)(42186005)(1456003)(81156007)(86362001)(15975445007)(101416001)(62236002)(33646002)(116806002)(14496001)(44716002)(84392001)(230783001)(40100003)(87976001)(105586002)(1556002)(50986999)(76176999)(106356001)(5001960100002)(81686999)(47776003)(66066001)(189998001)(50226001)(81816999)(44736004)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTVNQUjA3TUIwNTI7MjM6ZUVOUk1hSHA4VTlpRmlKcXNsOFRDanhQY0lx?= =?utf-8?B?VjVWK3pqQnRHWjJiVTI2Q3M0KzFIa1NVZ2lZa1p3dzlNRWN5dVc5dmRSNWxF?= =?utf-8?B?cnVHMG5yV2hPa2R0YlBDQ0dkZTcwQWRpR2dkcFdFUTVMM1o3SXZ2dHloOVhL?= =?utf-8?B?ZzFYeHFITTB6R1VmUWE1OWgxOUJYN2hxOXBZbU9vY2xzTitoWlBUSzIxU2Vh?= =?utf-8?B?bE9UVTlkVmVibTNjZEdhTysvNjhqRG0rSFpIR01CanN6MGJnNkxIaGdGSjNQ?= =?utf-8?B?N3MzL3h2K21JMDNLRWZpQnNCSklrNkN1TUEyN3FSby9tejVSV1NwU2JDN1gv?= =?utf-8?B?SjB1K3FoeUJrN1NVeG05dldRZXNhTW9HZHFLQ2s3NGgxQkNZYS95T1JwYkhh?= =?utf-8?B?Vjl5ZGhXQ3FmME5heGcxT2swQTZteDZ4Z053a3Y2dlJFSnRaTXg2aVVNQ1Uy?= =?utf-8?B?UUszajIxUGdlK3JEcGxQWHNOZTQ1bjUwWFcrSVVPRFZ4eXdzYnpyOXZUMnRk?= =?utf-8?B?WlMrVUp4bTdlb0FwbG9QOE8vV0tTNlI5dEhGc3FRSkZjL1dGY3hIU0xmSWtY?= =?utf-8?B?MmJUVUxNU3RZRWNUUlpFYS9ncnZtdGJZMWI4UGVleWplUnR5Z0pIQy9HZkw4?= =?utf-8?B?VmJ6aTBFNEFhTUt5Q1BTTXhuSm9DaGNIOVQwamNCVCtQNmdjcURnSGFqWktF?= =?utf-8?B?VW84R2ZsNWR5OWlnczZyRGtlRVpjVUx6Nno5bTVaUXBRdDhYTkVHbVk0R3B3?= =?utf-8?B?SXZuK2Ntendib2Z6aEpka1VXWVNVd1k1MUMrR2NucThGNXRRNlByYWtGVUpO?= =?utf-8?B?UHZ4bDZKSm85bkE2aGVyTTRYblRVTlZpNno1WDJIVEV0U0pBQVZrTUh0Mmdu?= =?utf-8?B?RHN2WEt0a25SMktKVVg4VzB5SExPT0Zwd1M3aDh1UXRrbGx4Qk0xbXNKanBQ?= =?utf-8?B?Uy9vLzh2d1hzWnpnM0NFT1BRa08xbTF6Mk9XTzZsR0VydGd6TTF0dXF5bmhR?= =?utf-8?B?cnEydUZWY0d0cXI2bDNMdGk5UVN2eTRUOCtSVlRXTmFGZkNLTkVsUk91S29z?= =?utf-8?B?SlVuRmcwT3ZZbFkrQlozTndJSFpiVEljaG1mcGFmbFFISmM3dHhjNU9GN3JF?= =?utf-8?B?NmtoL2h3R0pDaTVrSjBsZGhJL1pPcDVvSUFvWnlWVy9aWWt1MnVabUVYd2wv?= =?utf-8?B?SXRlL0JLODhHdlQvbFVva2g0TEEwK0s3cHhzN0VNQS9kSHc0bkJtekFrU0Zs?= =?utf-8?B?YW9jbGd6TE5JdDJQL1pKTE92ZWlXSHZTYW1CbW1EaFFTazdxTk9YVWtpU1VG?= =?utf-8?B?ZlNwUCtrRFJvWXRxaktLZE5wb0lmMXFYWWo2TnVoOTlSbjNNU2hiOHBXRTV0?= =?utf-8?B?Z2JHZTZyWDNuNDEyS040alQzWWE5UkhBNGlmT3Q0WWxiTnNGOVVqS0w2Mi9q?= =?utf-8?B?Yk4yUmRhbkhmemVwZW9sdWptdzZtMFRkUVVFK0xKMWFReXIrZ0NWcnlMV1VX?= =?utf-8?B?ZVVGLzNmS0lneCtIempnREVYVnBCSDFpM2s2cnAwMFRRSENlRmNJU1liVXJU?= =?utf-8?B?WlhMM01uSjY3bFNmdEJtSVdsd0d0SWZXVjR6K0NSN3lqLzlEcytyYmE5cUJH?= =?utf-8?B?RVYwWWd2b0RuMUhaUmIyRWRHdngwK2dCNDhrNGk5bUVCVUlGcW1zOW5rMjA5?= =?utf-8?B?djlhcGw0NEpKcHA3b1F1YTNnU1drQjBpWmY1WnBsbXRTeXk0TWp5YWUvWW0z?= =?utf-8?B?UVZnM01BZkNXdjg4MWpLaTVUdDNiQ2oxSk1BZTNkVHgyOHRDZU16VjhoamR3?= =?utf-8?B?NUF4bGcyUEkyWU51Y2JJVWhDT2JrYk9pTUhMbmZzN3BRZz09?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 5:vqNR0p3oUq11h9uUjsz8ue1O/OlA3+3dfiMzGsQT5VcTAhbbeAU+8e1Y50RZjeB8tFWeh2aLhv8ES6beMXOxNDJTYvIsMBNdlpwKzAMGwQ43Z3g/uJxFDRRwjnR+cYdVlM484N/zde7BQc/j4FtUrA==; 24:yRDcIoQv/zOgdUR/ox+Zll9T1Vvu6sj79I29rUkDCVpJ6uEI78ZdCDst7Ey0Im32jwrssZk29gqw39EnueMghcjMc0WhSq56VfH93SeqJFc=; 20:5M602/4Ae0/WcszMU27ZpMEhIddHJDOgm9tKqBadi3HsKwkGIQvL6ajH154GSX/R5kGJGsB5J1Epv5ubaBrIVg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2015 09:38:19.7694 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB052 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: Re: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 09:38:42 -0000 ----- Original Message ----- From: "Martin Stiemerling" To: "Kent Watsen" ; "The IESG" Cc: ; ; Sent: Monday, October 26, 2015 8:30 AM > Hi Ken, all, > > Am 21.10.15 um 23:19 schrieb Kent Watsen: > > Hi Martin, > > > > Thank you for your review. > > > >> 1) Why is this parapraph below (and subsequently the other similar > >> ones) using RFC 2119 language with respect to the port numbers The > >> NETCONF/RESTCONF client listens for TCP connection requests from > >> NETCONF/RESTCONF servers. The client SHOULD listen for connections > >> on the IANA-assigned ports defined in section Section 5, but MAY be > >> configured to use a non-standard port. > >> > >> Using the right port number is not something that influences the > >> interoperability of the protocol per se, but is an operational > >> parameter. Checking other protocol specifications, e.g. HTTP/1.1, > >> there is no RFC 2119 language about the usage of specific port > >> numbers. > > > > This is true. I don’t see RFC 2119 language in RFC 4253 either. > > That said, is it in any way wrong or bad? I’m happy to change the > > text of course, just want to confirm... > > I would remove RFC 2119 language in those paragraphs, as this does not > need RFC 2119 language. But RFC5426 says " Syslog receivers MUST support accepting syslog datagrams on the well- known UDP port 514, but MAY be configurable to listen on a different port. " and I think that this is a better analogy than RFC4253, the former being a network management protocol for operators running over a transport which the reader may or may not be expert in, whereas the latter is written by experts for experts. Tom Petch > > > > > > > > >> 2) I am not a fan of having different port numbers to > >> differentiate different vanilla flavors of a protocol. However, I > >> can understand the why this is happening this way. But what is > >> happening if there is X-over-TLS/SSH/foo coming after RESTCONF? Are > >> you again in need of more port numbers? This does not look like a > >> tactical wise and sustainable way. > > > > Joe Touch made a similar comment about a year and a half ago. There > > was quite a debate about it then. We discussed the option of having > > just one port for any number to TCP-based call home protocols. In > > the end, the WG consensus was to use distinct ports as written in the > > current text. Is this something you would like to raise again now? > > No, as this has been discussed in the WG and there is consensus to do it > as it is documented. This is just to state that this design is not > future proof nor sustainable. > > > > > > > > >> > >> 3) This document will benefit from an overview figure that details > >> who is the server/client on what level for what. > > > > > > I tred this before and the comment received was that it was > > confusing: > > http://www.ietf.org/mail-archive/web/netconf/current/msg09978.html. > > But that was just one opinion. What do you think about the diagram > > in the linked message? > > This would be good, may be it is worth saying that the arrows are > pointing from the initiator away. > > Thanks! > > Martin > > > > > > > > > Thanks again, Kent > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Oct 26 07:44: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 96CF01B462C; Mon, 26 Oct 2015 07:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTatCfHscoch; Mon, 26 Oct 2015 07:44:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28ADB1B462A; Mon, 26 Oct 2015 07:44:19 -0700 (PDT) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.306.13; Mon, 26 Oct 2015 14:44:17 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0306.003; Mon, 26 Oct 2015 14:44:18 +0000 From: Kent Watsen To: t.petch , The IESG , "Martin Stiemerling" Thread-Topic: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRDECqumWzTp3zDkeqqgbImWNS8p52MN2AgAdH4oCAABLec4AAEmiA Date: Mon, 26 Oct 2015 14:44:17 +0000 Message-ID: <650DF556-95DC-4039-9C94-BC78A1D74267@juniper.net> References: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> <562DE4BD.3040504@gmail.com> <01a401d10fd1$ef98b900$4001a8c0@gateway.2wire.net> In-Reply-To: <01a401d10fd1$ef98b900$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:DZkacS2KH8nn1pcYg/8YMWHG/lYHcxGgtBSzj2YF1u5EZ2KcU1dBtSI7Msw276KLub4wTkuSghxToHtCLmTlnLQDUwTptPhvvaR3w5tb3D1Du+F7knDww0+jYo36994u6EQ42KPah3O1Ev5ZUXWVpQ==; 24:DHgS6rTk45/0aGdFAOxq5gjIUbsGoiv0J9Y/Pu8ONilrnhM4uDLAQ5sEkc2vgrNjHjqImppxLTyDNI+k70B0Xs1kJtXFpJwsLZVkbtR5TFY=; 20:E9UlbReNzJYweqjTsLblUgoxrkZ0Rj8RvqodIClKlzwzHwILrS6ldfpsjOGBtZMOwpgDU2f+xaW2+1L9hLCVzQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(178726229863574); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0741C77572 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(52604005)(189002)(43784003)(479174004)(51444003)(377454003)(24454002)(199003)(76104003)(122556002)(15975445007)(83506001)(50986999)(77096005)(76176999)(54356999)(102836002)(5007970100001)(101416001)(66066001)(87936001)(83716003)(5004730100002)(19580405001)(19580395003)(82746002)(40100003)(2950100001)(2900100001)(10400500002)(106116001)(4001350100001)(5001920100001)(99286002)(92566002)(81156007)(106356001)(105586002)(97736004)(5001960100002)(5002640100001)(86362001)(230783001)(5001770100001)(189998001)(5008740100001)(36756003)(33656002)(93886004)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2015 14:44:17.9092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 14:44:22 -0000 DQoNCg0KDQoNCk9uIDEwLzI2LzE1LCA1OjM3IEFNLCAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVj dC5jb20+IHdyb3RlOg0KDQo+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206ICJN YXJ0aW4gU3RpZW1lcmxpbmciIDxtbHMuaWV0ZkBnbWFpbC5jb20+DQo+VG86ICJLZW50IFdhdHNl biIgPGt3YXRzZW5AanVuaXBlci5uZXQ+OyAiVGhlIElFU0ciIDxpZXNnQGlldGYub3JnPg0KPkNj OiA8bmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmc+OyA8ZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9t ZUBpZXRmLm9yZz47DQo+PG5ldGNvbmZAaWV0Zi5vcmc+DQo+U2VudDogTW9uZGF5LCBPY3RvYmVy IDI2LCAyMDE1IDg6MzAgQU0NCj4NCj4+IEhpIEtlbiwgYWxsLA0KPj4NCj4+IEFtIDIxLjEwLjE1 IHVtIDIzOjE5IHNjaHJpZWIgS2VudCBXYXRzZW46DQo+PiA+IEhpIE1hcnRpbiwNCj4+ID4NCj4+ ID4gVGhhbmsgeW91IGZvciB5b3VyIHJldmlldy4NCj4+ID4NCj4+ID4+IDEpIFdoeSBpcyB0aGlz IHBhcmFwcmFwaCBiZWxvdyAoYW5kIHN1YnNlcXVlbnRseSB0aGUgb3RoZXIgc2ltaWxhcg0KPj4g Pj4gb25lcykgdXNpbmcgUkZDIDIxMTkgbGFuZ3VhZ2Ugd2l0aCByZXNwZWN0IHRvIHRoZSBwb3J0 IG51bWJlcnMgVGhlDQo+PiA+PiBORVRDT05GL1JFU1RDT05GIGNsaWVudCBsaXN0ZW5zIGZvciBU Q1AgY29ubmVjdGlvbiByZXF1ZXN0cyBmcm9tDQo+PiA+PiBORVRDT05GL1JFU1RDT05GIHNlcnZl cnMuICBUaGUgY2xpZW50IFNIT1VMRCBsaXN0ZW4gZm9yIGNvbm5lY3Rpb25zDQo+PiA+PiBvbiB0 aGUgSUFOQS1hc3NpZ25lZCBwb3J0cyBkZWZpbmVkIGluIHNlY3Rpb24gU2VjdGlvbiA1LCBidXQg TUFZIGJlDQo+PiA+PiBjb25maWd1cmVkIHRvIHVzZSBhIG5vbi1zdGFuZGFyZCBwb3J0Lg0KPj4g Pj4NCj4+ID4+IFVzaW5nIHRoZSByaWdodCBwb3J0IG51bWJlciBpcyBub3Qgc29tZXRoaW5nIHRo YXQgaW5mbHVlbmNlcyB0aGUNCj4+ID4+IGludGVyb3BlcmFiaWxpdHkgb2YgdGhlIHByb3RvY29s IHBlciBzZSwgYnV0IGlzIGFuIG9wZXJhdGlvbmFsDQo+PiA+PiBwYXJhbWV0ZXIuIENoZWNraW5n IG90aGVyIHByb3RvY29sIHNwZWNpZmljYXRpb25zLCBlLmcuIEhUVFAvMS4xLA0KPj4gPj4gdGhl cmUgaXMgbm8gUkZDIDIxMTkgbGFuZ3VhZ2UgYWJvdXQgdGhlIHVzYWdlIG9mIHNwZWNpZmljIHBv cnQNCj4+ID4+IG51bWJlcnMuDQo+PiA+DQo+PiA+IFRoaXMgaXMgdHJ1ZS4gIEkgZG9u4oCZdCBz ZWUgUkZDIDIxMTkgbGFuZ3VhZ2UgaW4gUkZDIDQyNTMgZWl0aGVyLg0KPj4gPiBUaGF0IHNhaWQs IGlzIGl0IGluIGFueSB3YXkgd3Jvbmcgb3IgYmFkPyAgIEnigJltIGhhcHB5IHRvIGNoYW5nZSB0 aGUNCj4+ID4gdGV4dCBvZiBjb3Vyc2UsIGp1c3Qgd2FudCB0byBjb25maXJtLi4uDQo+Pg0KPj4g SSB3b3VsZCByZW1vdmUgUkZDIDIxMTkgbGFuZ3VhZ2UgaW4gdGhvc2UgcGFyYWdyYXBocywgYXMg dGhpcyBkb2VzIG5vdA0KPj4gbmVlZCBSRkMgMjExOSBsYW5ndWFnZS4NCj4NCj5CdXQgUkZDNTQy NiBzYXlzDQo+DQo+IiBTeXNsb2cgcmVjZWl2ZXJzIE1VU1Qgc3VwcG9ydCBhY2NlcHRpbmcgc3lz bG9nIGRhdGFncmFtcyBvbiB0aGUgd2VsbC0NCj4gICBrbm93biBVRFAgcG9ydCA1MTQsIGJ1dCBN QVkgYmUgY29uZmlndXJhYmxlIHRvIGxpc3RlbiBvbiBhIGRpZmZlcmVudA0KPiAgIHBvcnQuICAi DQo+DQo+YW5kIEkgdGhpbmsgdGhhdCB0aGlzIGlzIGEgYmV0dGVyIGFuYWxvZ3kgdGhhbiBSRkM0 MjUzLCB0aGUgZm9ybWVyIGJlaW5nDQo+YSBuZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2wgZm9y IG9wZXJhdG9ycyBydW5uaW5nIG92ZXIgYSB0cmFuc3BvcnQNCj53aGljaCB0aGUgcmVhZGVyIG1h eSBvciBtYXkgbm90IGJlIGV4cGVydCBpbiwgd2hlcmVhcyB0aGUgbGF0dGVyIGlzDQo+d3JpdHRl biBieSBleHBlcnRzIGZvciBleHBlcnRzLg0KPg0KPlRvbSBQZXRjaA0KDQoNCkhpIFRvbSwNCg0K VGhhbmtzIGZvciBwb2ludGluZyB0aGlzIG91dC4gIEkgYWN0dWFsbHkgbGlrZSB0aGUgUkZDIDU0 MjYgbGFuZ3VhZ2UgbW9yZSB0aGFuIHRoZSBjdXJyZW50IHRleHQsIGl0IHNlZW1zIG1vcmUgcHJl Y2lzZSB0byBtZS4gIFNvIGhvdyBhYm91dCB0aGUgZm9sbG93aW5nPyAgDQoNCk9MRDoNCg0KICAg IFRoZSBORVRDT05GL1JFU1RDT05GIGNsaWVudCBsaXN0ZW5zIGZvciBUQ1AgY29ubmVjdGlvbiBy ZXF1ZXN0cw0KICAgIGZyb20gTkVUQ09ORi9SRVNUQ09ORiBzZXJ2ZXJzLiAgVGhlIGNsaWVudCBT SE9VTEQgbGlzdGVuIGZvcg0KICAgIGNvbm5lY3Rpb25zIG9uIHRoZSBJQU5BLWFzc2lnbmVkIHBv cnRzIGRlZmluZWQgaW4gc2VjdGlvbg0KICAgIFNlY3Rpb24gNSwgYnV0IE1BWSBiZSBjb25maWd1 cmVkIHRvIHVzZSBhIG5vbi1zdGFuZGFyZCBwb3J0Lg0KDQpORVc6DQoNCg0KICAgIFRoZSBORVRD T05GL1JFU1RDT05GIGNsaWVudCBsaXN0ZW5zIGZvciBUQ1AgY29ubmVjdGlvbiByZXF1ZXN0cw0K ICAgIGZyb20gTkVUQ09ORi9SRVNUQ09ORiBzZXJ2ZXJzLiBUaGUgY2xpZW50IE1VU1Qgc3VwcG9y dCBhY2NlcHRpbmcNCiAgICBUQ1AgY29ubmVjdGlvbnMgb24gdGhlIElBTkEtYXNzaWduZWQgcG9y dHMgZGVmaW5lZCBpbiBzZWN0aW9uDQogICAgU2VjdGlvbiA1LCBidXQgTUFZIGJlIGNvbmZpZ3Vy YWJsZSB0byBsaXN0ZW4gb24gYSBkaWZmZXJlbnQgcG9ydC4NCg0KDQpNYXJ0aW4sIGRvZXMgc2Vl aW5nIFJGQyA1NDI2IGhlbHA/DQoNCg0KDQoNCg0KDQo+PiA+PiAzKSBUaGlzIGRvY3VtZW50IHdp bGwgYmVuZWZpdCBmcm9tIGFuIG92ZXJ2aWV3IGZpZ3VyZSB0aGF0IGRldGFpbHMNCj4+ID4+IHdo byBpcyB0aGUgc2VydmVyL2NsaWVudCBvbiB3aGF0IGxldmVsIGZvciB3aGF0Lg0KPj4gPg0KPj4g Pg0KPj4gPiBJIHRyZWQgdGhpcyBiZWZvcmUgYW5kIHRoZSBjb21tZW50IHJlY2VpdmVkIHdhcyB0 aGF0IGl0IHdhcw0KPj4gPiBjb25mdXNpbmc6DQo+PiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDk5NzguaHRtbC4NCj4+ID4gQnV0IHRo YXQgd2FzIGp1c3Qgb25lIG9waW5pb24uICBXaGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGUgZGlh Z3JhbQ0KPj4gPiBpbiB0aGUgbGlua2VkIG1lc3NhZ2U/DQo+Pg0KPj4gVGhpcyB3b3VsZCBiZSBn b29kLCBtYXkgYmUgaXQgaXMgd29ydGggc2F5aW5nIHRoYXQgdGhlIGFycm93cyBhcmUNCj4+IHBv aW50aW5nIGZyb20gdGhlIGluaXRpYXRvciBhd2F5Lg0KDQoNClBTOiBJ4oCZbSBwbGFubmluZyB0 byBhZGQgdGhpcyBkaWFncmFtIGludG8gdGhlIGRyYWZ0Lg0KDQoNClRoYW5rcyBhZ2FpbiwNCktl bnQNCg0KDQoNCg== From nobody Mon Oct 26 08:16:05 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 8E5951B4982; Mon, 26 Oct 2015 08:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SLIrJeXyH1zz; Mon, 26 Oct 2015 08:15:56 -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 869F81B497D; Mon, 26 Oct 2015 08:15:55 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 26 Oct 2015 15:15:35 +0000 Message-ID: <00db01d11001$0c8f88c0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , The IESG , Martin Stiemerling References: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> <562DE4BD.3040504@gmail.com> <01a401d10fd1$ef98b900$4001a8c0@gateway.2wire.net> <650DF556-95DC-4039-9C94-BC78A1D74267@juniper.net> Date: Mon, 26 Oct 2015 15:14:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: AM3PR02CA0084.eurprd02.prod.outlook.com (25.163.180.52) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB060; 2:9/xzTKDJvEMh/g6Tr3Gbocy1DF+PH6lrSkBf5xRkk26tYiNEvHApfvxGuz5ASBqauAzL9AfqT6jrHqrCocn4nGqsydwWhTadRDhM1W7TgO68MH77oq+ht3v3rhEaNhqoruxFEd8lf55fQ/kj1XDXDkBI6H9200oy1ZrAIraev2k=; 3:O99vb7yH9XxdTpChj/vdihshwkbYl0YpRstdZF9+PMAzJNFrZG1XBVYRcogTa7ZYvYih9V1mcpgfZavRyTnu3ntrM7dX+/U1tpBubdXpxq4GZUlhxCuFoMnLnUGlCXWeigAQqbfEyNcbWvf1KNgs1g==; 25:126GoozJFZhDEqg1eSE2apwyBNwvwI4t7lkGzgerpV0NDXlS7ui6jUpDqnp3oTs3AZPzEU6RbJxLRkDmjv6V+x6BGOSyBYaBJZaHLVOPBgOpe7WAKzbhcNHrdRdPHiURv0AdRgZ+cEFlY81ahs3t5TmtXnR8D8y2WXPQTELGoA/J6nSfJ3WlmxosV0Go+JvEawqqH+cDoSqnFRKyIqvMjRerNnkQSrABJC5EsToAV4M8Gh2xFXyu7LUtcf6yXLhR; 4:5uZtv5i0r7mhTJBeqs2PTwxsddLN9QUqmweN7mWvF/eEuDPPaPsP0PmPoYGLGs5ed4xgFnVhTdlgDMyxFo5OWEEFdXLAXGWIekeyhvWnYNSJxRZ/JgJubcVqVGxlP/gmASj7OpOUQ7yZT9OWlCOAvXuPPTtbgHxDcUpIOOLF4jQG53eU7eePkc7ujtVK9FcA7IAb5NNn+I0QmV6F0Ht9FSHs2/Wqro/41cy9H1fzfvQiIIeZ3WvFOK8M1zsEHd2wrTTeB8WnYS/DKPDy/wUh9f0dJNnwp66OlBDbQh43bLBR3/o58M+VBUkRhQHkC7KBSbCczqjdOR1mHuj39HGPLMzsRGQ835mbDfrmIkiDSB9pbEdAMFElqj0ERxXxxvlo X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB060; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(102215026); SRVR:DB3PR07MB060; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB060; X-Forefront-PRVS: 0741C77572 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(52604005)(377454003)(479174004)(189002)(43784003)(51444003)(76104003)(199003)(24454002)(105586002)(5007970100001)(106356001)(33646002)(42186005)(61296003)(5001960100002)(93886004)(92566002)(5004730100002)(66066001)(86362001)(5008740100001)(76176999)(19580395003)(230783001)(50986999)(122386002)(116806002)(189998001)(1941001)(40100003)(97736004)(19580405001)(81816999)(81156007)(1556002)(84392001)(5001920100001)(87976001)(101416001)(62236002)(5001770100001)(44716002)(50466002)(14496001)(23676002)(1456003)(15975445007)(50226001)(77096005)(44736004)(81686999)(47776003)(7059030)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB060; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjNQUjA3TUIwNjA7MjM6cHZlMktBbU41M3BOcTdKTzFkaEo4MnpISnRy?= =?utf-8?B?ak50QkppYmRBN0UvT1hiVDE2UlhLNXBrNUlwSUppOTB2UkExaC9hclN2WjNn?= =?utf-8?B?dG9XUDMyNEEzanhicFI4WHJWL21Xb1Z4U1JpYU1vQ3J3OTlPNzV5dXNtSjdm?= =?utf-8?B?blNQODNrRjNod0UrSmRQeVZkVWpkZ0NEUU85ZmVuTnduN1ptNEdYY20wMnpK?= =?utf-8?B?aDF0ajlnbWo5OXpraDJSZFRSdS9UaUpxKzdSQzdZUzJmcWZWdno4cWJFdVl4?= =?utf-8?B?NTBuRmVhOXR5VXYvN2V5VC9NZ3UxRUhVekIxN3JMMVVjdkp5TlhoUkZ4bTBo?= =?utf-8?B?WWV2NzlDSUloR0RJenpGbUxVTG9HNUhzdEpVV3NtNkpXQVc2QVV0M2lVcXlt?= =?utf-8?B?bzNXdUtld1pyV3BwOFovQlFlclpOcVZ4RUNQUElTNEFLYzFIcDFrSS9xbDRE?= =?utf-8?B?enlqWGd4TWlYdGZ6M3Vra0NFMXF0RWZraVp2MmR1RURYTi9RSENqNVd0QU9P?= =?utf-8?B?bU5iN3htODFrOFRaNzFtQmF2cEVHTERCc2E1R3oyMElXd2VUL3FBQnlRZ3hk?= =?utf-8?B?Yy9wSDlKTWlJdjFlT0IvZW96Ym1DZzhUeWFUSUljWk5mYWdQTVVUekJpV29x?= =?utf-8?B?S0JGVWZMMXE3MGNrbmxoRGhrcHVzYmgrekVEeW5HN2dCSm9qZ0RyakRYaXRm?= =?utf-8?B?MWROeEgwYzZ6NXovMzhwRjhkdmVscEtYRzFCanIwVGhPUzdUeWFXMEtDRG1L?= =?utf-8?B?ejVlejdJZGlzNHFMNDRJNmNWOWs0Ykgrb0N3SjhxaU9FaTdzNTZvVzNHN1hJ?= =?utf-8?B?MGFrdEQrT2dhT0tyYnRjeTFnNC9OYlo3bGc2WWdoQk1qMDVSYytOaWtweUdD?= =?utf-8?B?M0o0MExtQjg4aWdKMm5EM1EvZzA3Sy9wcFpqek5TNkFyUmVCMVNaUklDT0kw?= =?utf-8?B?VGlkYld1YUkySWd4VmQya1VJNmFxK1VkTFhQcm9qTFVyT3poQnlxdi96dVhq?= =?utf-8?B?alREMDVqMXN0RENrbTl2THpEQVBaZHlyNCtyS2t0YnVwNnh5eXErcCs1U2hM?= =?utf-8?B?R2FXRitXSnRhTDR5TjNBVDY3MUczTUtHVWd4Rk1uSVZaeXRpdEpOM2tUTko4?= =?utf-8?B?YU5KdzRiRDB0WDBqNDhBWkZrcC9LUnJPZm9RMUpFR2xQZlpkdjc3bW1uc3FE?= =?utf-8?B?OE9JY0V3cVpBcDhNNllKVnJBM0dud203cmNwbjR3OUdKMEtyVGoxeUp5YzBK?= =?utf-8?B?ODk0OFM3TjRQTkd2ZGNublN5S2h2V2dDR2Q3TU16NnFYR2FJeVV1UGZYZGtG?= =?utf-8?B?WDNvZXpjZVhFc1RkUUEyVThuUitOcWxiajY5ZlhkRkdvR3N5YzR4VmRmSFFG?= =?utf-8?B?RWpmME1kZU5MNC9jVC93dlNXSStCbnBPTVVkMWJ4VzBvK1ZURGJjbitMc0k4?= =?utf-8?B?QkdqQzBYZFdBbVhmQW05eVI3bGtMZlBnc1NHWFladWhROFRvbGZqYXFhY1Vi?= =?utf-8?B?aE5qTXZuTHZKWlJSTS9hT3I5alRPM3pqQjBhYmxxRitPcGFacWhzM01rRlBk?= =?utf-8?B?L3JNL3Y5Q1NnaXllZjlWLzhxWXh2T0RnaWwyV2RtSGFIcWRkNHNaUXdvY2U3?= =?utf-8?B?a3BNOEJGSDRDQkQydTRRMTBBZTV5bGY1eVdmZDFiRVlsRjJTNkxJLzdsdFFY?= =?utf-8?B?QmhKcGJvLyszbjVGU2RRdG1ScU0yWlhOYVNFTjByQ3JhMmJMeDNzZ0ZZTmRN?= =?utf-8?B?aTl5VUE2Zk90REllSW5mSVJVc0RteFZHVDZ4Uy9tOVMzZ3FWWWVjSXBnUVJy?= =?utf-8?B?UVlFc0NqNG8wSWVzajV5cERrV29KWlNNL0Z2K0FNSnBOaElTbDROL0orTnRr?= =?utf-8?B?SHZUNkh5VzBTV1E4UWpWdXRacnFtRkFlTm1TeHo3cHV2T2tNdUo2T3U1bmgz?= =?utf-8?B?aG56YkpOOTZodEFrM3praFJncDVVbTVTVjBDNm9NMUc0Zm9aK2h3anFDclNn?= =?utf-8?B?TUFUaUE0UWZmRUhQcTVaTHZBbXdnZEpnSDFBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB060; 5:bFb4SgHoHLIwlH3lJ9T6ZOjSIoxdZ309yEkq9bf+XXMYQOaEuWZRCqftz8qXgU4oADjIMRsk6JLCw0kd6F2eQnjXMJKAuRyk2/GcU5QOFT0QMiJX9fP4VH9+hYhDBPYhI5Ktoo7HY3wTFIRWrLJW/A==; 24:pzhwnzWli1snnCQaoOGVzZicFPmMpsyxAzB5FW88rP6WCpWnOPOxENZMS9B3MhTJBCudN4qrsNnuZT4M6cjCil3cGqLdC2I0w4qxmnN0xsk=; 20:xlGV04RZrmyRGdFBCiTKxilNjRcQkZvu607YfaSal1K4rxAtPAEYMmtNHH33mkVK0w7YOAzCRHHrN19a68RX0Q== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2015 15:15:35.2912 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB060 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: Re: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 15:16:00 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "The IESG" ; "Martin Stiemerling" Sent: Monday, October 26, 2015 2:44 PM > > On 10/26/15, 5:37 AM, "t.petch" wrote: > > >----- Original Message ----- > >From: "Martin Stiemerling" > >To: "Kent Watsen" ; "The IESG" > >Sent: Monday, October 26, 2015 8:30 AM > > > >> Hi Ken, all, > >> > >> Am 21.10.15 um 23:19 schrieb Kent Watsen: > >> > Hi Martin, > >> > > >> > Thank you for your review. > >> > > >> >> 1) Why is this parapraph below (and subsequently the other similar > >> >> ones) using RFC 2119 language with respect to the port numbers The > >> >> NETCONF/RESTCONF client listens for TCP connection requests from > >> >> NETCONF/RESTCONF servers. The client SHOULD listen for connections > >> >> on the IANA-assigned ports defined in section Section 5, but MAY be > >> >> configured to use a non-standard port. > >> >> > >> >> Using the right port number is not something that influences the > >> >> interoperability of the protocol per se, but is an operational > >> >> parameter. Checking other protocol specifications, e.g. HTTP/1.1, > >> >> there is no RFC 2119 language about the usage of specific port > >> >> numbers. > >> > > >> > This is true. I don’t see RFC 2119 language in RFC 4253 either. > >> > That said, is it in any way wrong or bad? I’m happy to change the > >> > text of course, just want to confirm... > >> > >> I would remove RFC 2119 language in those paragraphs, as this does not > >> need RFC 2119 language. > > > >But RFC5426 says > > > >" Syslog receivers MUST support accepting syslog datagrams on the well- > > known UDP port 514, but MAY be configurable to listen on a different > > port. " > > > >and I think that this is a better analogy than RFC4253, the former being > >a network management protocol for operators running over a transport > >which the reader may or may not be expert in, whereas the latter is > >written by experts for experts. > > > >Tom Petch > > Hi Tom, > > Thanks for pointing this out. I actually like the RFC 5426 language more than the current text, it seems more precise to me. So how about the following? > > OLD: > > The NETCONF/RESTCONF client listens for TCP connection requests > from NETCONF/RESTCONF servers. The client SHOULD listen for > connections on the IANA-assigned ports defined in section > Section 5, but MAY be configured to use a non-standard port. > > NEW: > > The NETCONF/RESTCONF client listens for TCP connection requests > from NETCONF/RESTCONF servers. The client MUST support accepting > TCP connections on the IANA-assigned ports defined in section > Section 5, but MAY be configurable to listen on a different port. > WFM Martin seems to making a general comment that RFC2119 language is inappropriate for the whole of s.2.1and s.3.1, a comment which I disagree with. As we are writing for operations-oriented people, who may not be versed in the nuances of transport protocols, I think that MUST, SHOULD and MAY makes things clearer so I would argue for keeping them all in and I think that that needs resolving (and it is a No Objection not a Discuss). Making the change above to C1 moves it out of line with S1 so I would revisit S1, currently (assuming that there are no changes from this round of IESG comments) OLD S1 The NETCONF/RESTCONF server initiates a TCP connection request to the NETCONF/RESTCONF client. The server SHOULD connect to one of the IANA-assigned ports defined in section Section 5, but MAY be configured to use a non-standard port. Using the IANA-assigned ports, the server connects to port PORT-X for NETCONF over SSH, port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF over TLS. Perhaps NEW S1 The NETCONF/RESTCONF server initiates a TCP connection request to the NETCONF/RESTCONF client. The server MUST suppport connections to one of the IANA-assigned ports defined in Section 5, but MAY be configurable to support connections to a non-standard port. Using the IANA-assigned ports, the server connects to port PORT-X for NETCONF over SSH, port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF over TLS. Tom Petch > Martin, does seeing RFC 5426 help? > > > > > > > >> >> 3) This document will benefit from an overview figure that details > >> >> who is the server/client on what level for what. > >> > > >> > > >> > I tred this before and the comment received was that it was > >> > confusing: > >> > http://www.ietf.org/mail-archive/web/netconf/current/msg09978.html. > >> > But that was just one opinion. What do you think about the diagram > >> > in the linked message? > >> > >> This would be good, may be it is worth saying that the arrows are > >> pointing from the initiator away. > > > PS: I’m planning to add this diagram into the draft. > > > Thanks again, > Kent > > > > From nobody Mon Oct 26 09:31: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 2BED41B4EE0; Mon, 26 Oct 2015 09:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Bz_GlP-CYn; Mon, 26 Oct 2015 09:31:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400641B4EDE; Mon, 26 Oct 2015 09:31:50 -0700 (PDT) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (TLS) id 15.1.306.13; Mon, 26 Oct 2015 16:31:34 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0306.003; Mon, 26 Oct 2015 16:31:34 +0000 From: Kent Watsen To: t.petch , Ben Campbell Thread-Topic: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) Thread-Index: AQHRC4NwSO9HeS5EiE2jlg9x14GRTZ51dggAgAA4poCAAAM9AIAAUjGAgAAdHgCAAFV4AIABiacAgAGtFYCAAN2gV4ADMmsA Date: Mon, 26 Oct 2015 16:31:34 +0000 Message-ID: <60C52588-8339-4C31-93E4-7464CEA75717@juniper.net> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> <23D01C9B-C786-446B-9725-E584018300C0@juniper.net> <36301A50-FA31-42ED-AD53-FB58CBFA1912@nostrum.com> <019401d10e50$ee9d16e0$4001a8c0@gateway.2wire.net> In-Reply-To: <019401d10e50$ee9d16e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:EbMOTWqZUFpPPowOUDdNWhjbj5IuT7Nr7sjacyg9N0PWsOLN+rTZlMRueq7unLS6rNSq/8IxfwnQVWnaytZunnTIcFLcwj8h9bKwheKsedIFItcL/rxbPx4+sFuRlHkZlTJpIEWtNRB0EgE/k2QGVA==; 24:Tctgefv/hIKIGKNNDCMcL8i2SvbzZZm5HpJZ9XzTGstWdGR8RbYG5CAAl8PHJys5y0160qOTKP8T2MFmhft5fJpizebpAQcrKGu5XoFnl/A=; 20:FFs2IeUWsuyMI+FcnC6bj2bT3WWbCTUPHtP0v0VRt2IP2ZGoKC8x4WKBGZZxZZ/OpwPkzBpZrXyg9HdVUPc71A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(102215026); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0741C77572 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(199003)(164054003)(51444003)(189002)(76176999)(5008740100001)(102836002)(93886004)(11100500001)(92566002)(33656002)(66066001)(10400500002)(77096005)(5002640100001)(5004730100002)(2900100001)(2950100001)(5007970100001)(5001960100002)(189998001)(5001770100001)(83716003)(81156007)(4001350100001)(83506001)(106356001)(82746002)(87936001)(40100003)(122556002)(86362001)(230783001)(99286002)(106116001)(54356999)(101416001)(50986999)(105586002)(36756003)(97736004)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <73B8F33E3D903A4FA58F2C3E999D6229@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2015 16:31:34.6256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: The IESG , Barry Leiba , "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , Netconf Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 16:31:53 -0000 DQoNCg0KDQo+Pj4gUzEgIFRoZSBORVRDT05GL1JFU1RDT05GIHNlcnZlciBpbml0aWF0ZXMgYSBU Q1AgY29ubmVjdGlvbiByZXF1ZXN0DQo+dG8NCj4+ID4gICB0aGUgTkVUQ09ORi9SRVNUQ09ORiBj bGllbnQuICBUaGUgc2VydmVyIFNIT1VMRCBjb25uZWN0IHRvIG9uZSBvZg0KPj4gPiAgIHRoZSBJ QU5BLWFzc2lnbmVkIHBvcnRzIGRlZmluZWQgaW4gc2VjdGlvbiBTZWN0aW9uIDUsIGJ1dCBNQVkg YmUNCj4+ID4gICBjb25maWd1cmVkIHRvIHVzZSBhIG5vbi1zdGFuZGFyZCBwb3J0LiAgVXNpbmcg dGhlIElBTkEtYXNzaWduZWQNCj4+ID4gICBwb3J0cywgdGhlIHNlcnZlciBjb25uZWN0cyB0byBw b3J0IFBPUlQtWCBmb3IgTkVUQ09ORiBvdmVyIFNTSCwNCj4+ID4gICBwb3J0IFBPUlQtWSBmb3Ig TkVUQ09ORiBvdmVyIFRMUywgYW5kIHBvcnQgUE9SVC1aIGZvciBSRVNUQ09ORg0KPj4gPiAgIG92 ZXIgVExTLg0KPj4gPg0KPj4gPiBJIHNob3VsZOKAmXZlIHBvaW50ZWQgb3V0IHRoZSBhYm92ZSBv biBteSBlYXJsaWVyIHJlc3BvbnNlLiBXZSBjb3VsZA0KPj4gPiByZXBsYWNlIHRoZSBzZWNvbmQg c2VudGVuY2Ugd2l0aDoNCj4+ID4NCj4+ID4NCj4+ID4gIFRoZSBzZXJ2ZXIgTVVTVCBkZWZhdWx0 IHRvIGNvbm5lY3RpbmcgdG8gb25lIG9mIHRoZSBJQU5BLWFzc2lnbmVkDQo+PiA+ICBwb3J0cyBk ZWZpbmVkIGluIFNlY3Rpb24gNSBhbmQgYmUgY29uZmlndXJhYmxlIHRvIHVzZSBhDQo+bm9uLXN0 YW5kYXJkDQo+PiA+ICBwb3J0Lg0KPj4gPg0KPj4gPiBXaGF0IGRvIHlvdSB0aGluaz8NCj4NCj5J IHRoaW5rIHRoYXQgdGhhdCBpbnRyb2R1Y2VzIGEgZnJlc2ggYW1iaWd1aXR5LiAgRG9lcyBpdCBt ZWFuIE1VU1QNCj5kZWZhdWx0IGFuZCBNVVNUIGJlIGNvbmZpZ3VyYWJsZT8gIFByb2JhYmx5IG5v dC4gIEkgc3VnZ2VzdA0KPg0KPlRoZSBzZXJ2ZXIgTVVTVCBkZWZhdWx0IHRvIGNvbm5lY3Rpbmcg dG8gb25lIG9mIHRoZSBJQU5BLWFzc2lnbmVkDQo+cG9ydHMgZGVmaW5lZCBpbiBTZWN0aW9uIDUg YW5kIE1BWSBiZSBjb25maWd1cmFibGUgdG8gdXNlIGEgbm9uLXN0YW5kYXJkDQo+cG9ydA0KPg0K PndoaWNoIEkgdGhpbmsgbW9yZSBpbiBsaW5lIHdpdGggdGhlIGNvbnNlbnN1cyBvZiB0aGVXb3Jr aW5nIEdyb3VwLg0KPg0KPkV4Y2VwdCB0aGF0IHlvdSBhcmUgbm93IG1vdmluZyBTMSBvdXQtb2Yt bGluZSB3aXRoIEMxIHdoaWNoIEkgdGhpbmsgd2lsbA0KPmNhdXNlIGNvbmZ1c2lvbi4gIFRoZSBv cmlnaW5hbCB3b3JkaW5nIGFsbG93cyB0aGVtIHRvIGJlIHRoZSBzYW1lLg0KPkludHJvZHVjaW5n IHRoZSBpZGVhIG9mICdNVVNUIGRlZmF1bHQnIG1heSBmb3JjZSB0aGVtIHRvIGJlIGRpZmZlcmVu dC4NCj4NCj5Ub20gUGV0Y2gNCj4NCj4NCj4+DQo+PiBUaGF0IHdvcmtzIGZvciBtZSwgdGhhbmtz IQ0KDQoNCkhpIEJlbiwNCg0KVGhpcyBzYW1lIHRleHQgaXMgYmVpbmcgZGlzY3Vzc2VkIGluIHRo ZSBNYXJ0aW4gU3RpZW1lcmxpbmcgdGhyZWFkLCB3aGVyZSBzeW1tZXRyaWMgdXBkYXRlcyB0byBi b3RoIEMxIGFuZCBTMSB1c2luZyBSRkMgNTQyNiBsYW5ndWFnZSBhcmUgcHJvcG9zZWQuIEJlbiwg SeKAmW0gaG9waW5nIHRoYXQgbGFuZ3VhZ2Ugd29ya3MgZm9yIHlvdSB0b28uLj8gIFJlZ2FyZGxl c3MsIGxldOKAmXMgdXNlIHRoYXQgb3RoZXIgdGhyZWFkIHRvIGZpbmlzaCBvZmYgdGhpcyBkaXNj dXNzaW9uLg0KDQpCVFcsIHRoYW5rcyBUb20gUGV0Y2ggZm9yIGhlbHBpbmcgb24gdGhlc2UhDQoN ClRoYW5rcywNCktlbnQNCg0KDQoNCg0K From nobody Mon Oct 26 10:13: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 011C71B4FC1; Mon, 26 Oct 2015 10:13:30 -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=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 xJS5gv0dFLYJ; Mon, 26 Oct 2015 10:13:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6C1B51B4FD1; Mon, 26 Oct 2015 10:13:27 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9QHDMj2079454 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2015 12:13:22 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Kent Watsen" Date: Mon, 26 Oct 2015 12:13:34 -0500 Message-ID: <446C820B-C9C7-4FD1-8985-9545AEE86CED@nostrum.com> In-Reply-To: <60C52588-8339-4C31-93E4-7464CEA75717@juniper.net> References: <20151020220528.1103.2866.idtracker@ietfa.amsl.com> <20151021094008.GB65099@elstar.local> <5C065838-2633-4BDF-A514-9A0E31207C1B@nostrum.com> <8034DC26-F098-42C6-A90D-F15E2B2DAEE6@juniper.net> <64695F1B-8AE9-4ECD-BB00-18D27D14E075@nostrum.com> <23D01C9B-C786-446B-9725-E584018300C0@juniper.net> <36301A50-FA31-42ED-AD53-FB58CBFA1912@nostrum.com> <019401d10e50$ee9d16e0$4001a8c0@gateway.2wire.net> <60C52588-8339-4C31-93E4-7464CEA75717@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , Netconf , Barry Leiba , The IESG Subject: Re: [Netconf] Ben Campbell's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 17:13:30 -0000 On 26 Oct 2015, at 11:31, Kent Watsen wrote: > This same text is being discussed in the Martin Stiemerling thread, > where symmetric updates to both C1 and S1 using RFC 5426 language are > proposed. Ben, I’m hoping that language works for you too..? > Regardless, let’s use that other thread to finish off this > discussion. That is fine with me. I'm sure I will be okay with whatever people come up with after discussion. Thanks! Ben. From nobody Mon Oct 26 12:03: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 181271B50E4; Mon, 26 Oct 2015 12:02:57 -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 760EH0QWEVqd; Mon, 26 Oct 2015 12:02:56 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 EFC721B2ACC; Mon, 26 Oct 2015 12:02:52 -0700 (PDT) Received: by oiad129 with SMTP id d129so106338702oia.0; Mon, 26 Oct 2015 12:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:content-type:message-id:date:cc :content-transfer-encoding:to; bh=22gI6b0YeSheiTzT7hUJI17swWCpkDXPF/BxRbK8Lc8=; b=cQ9CADjNf/c4q9QJGlvixYxXXcFM8WHFx92LuelysMQaLJkhi+yZFSaTZjNLBGtXCp aA+OBRMuiNFDqgC8aop29i0F5KbsyUfV3iuJ+oEUNhCgq3bxr7Rm1Qu2JSvTXZAcj8F9 dhOaKbJX/2VmDaDAZ/J8F6tFGJI/KsnXiUIixNluH9xXBrDrjOP+c7oRBbq5sgiwhm3z mHer0ztC/u0F3BAm4ZEmA1ksNDdhCODwanDW8Rk1Dmeau4cTQ96efAluGmGC79sML8MZ JeuuJY2tr20PzJRqDt47H5KX38aWq946gmwohPjrrImm+X/2xYPyAMyARLrj+ivmfw2s 47Mg== X-Received: by 10.202.90.139 with SMTP id o133mr7474365oib.41.1445886172338; Mon, 26 Oct 2015 12:02:52 -0700 (PDT) Received: from [172.27.6.45] (75-104-68-33.mobility.exede.net. [75.104.68.33]) by smtp.gmail.com with ESMTPSA id dh3sm15502487obb.29.2015.10.26.12.02.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Oct 2015 12:02:51 -0700 (PDT) Mime-Version: 1.0 (1.0) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (12B466) Message-Id: Date: Mon, 26 Oct 2015 12:02:47 -0700 Content-Transfer-Encoding: quoted-printable To: "draft-ietf-netconf-yang-push@ietf.org" Archived-At: Cc: Netconf Subject: [Netconf] IPR disclosures on draft-ietf-netconf-yang-push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 19:02:57 -0000 Can each of the authors on the above draft disclose if they are aware of any= IPRs related to this draft. Please respond to the mailing list. Thanks Mahesh & Mehmet= From nobody Mon Oct 26 12: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 6FB211B50A7; Mon, 26 Oct 2015 12:04:30 -0700 (PDT) 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 1GqveDWHGfhg; Mon, 26 Oct 2015 12:04:29 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61D91B5108; Mon, 26 Oct 2015 12:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=507; q=dns/txt; s=iport; t=1445886252; x=1447095852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=81JxRTP+zITN0hAZEDWFUOJikYlIRl7N9C9EvbHqDi4=; b=ASxMQAdbg0lwC4mlmJ3EsXO/+gfzuzWwnFHrII/pnV6912s+OG1guT/i utl3uUqG64HpnJJSBs945f+JC5Tv+0V7eXEAeQ47jQxuw9pmLvcPTmgHf zEW/OBjlTkjuIaVn+fFfEHDf7flbZkoIWEcoYL1Ocs9Jx2HvDupIFp2Ys k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ACAgB6eC5W/4QNJK1egzaBQwa+PwENgVqGHQKBNzgUAQEBAQEBAYEKhDIBAQEEOjQLDAQCAQgOAwQBAR8JByERFAkIAgQBDQUIiBMDEsESDYRFAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIt1glCCPQcGhCgFljYBiyyBboFghD+OSIdOAR8BAUKEA3KGEoEGAQEB X-IronPort-AV: E=Sophos;i="5.20,201,1444694400"; d="scan'208";a="201447701" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2015 19:04:12 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t9QJ4CkW005724 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 19:04:12 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 26 Oct 2015 14:03:48 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.000; Mon, 26 Oct 2015 14:03:48 -0500 From: "Alexander Clemm (alex)" To: Mahesh Jethanandani , "draft-ietf-netconf-yang-push@ietf.org" Thread-Topic: IPR disclosures on draft-ietf-netconf-yang-push Thread-Index: AQHRECDkxnCcMNaU+EqAKT6yQ67U2Z5+IapA Date: Mon, 26 Oct 2015 19:03:48 +0000 Message-ID: <9b59aa7c8db24af9b6ea5ceb2bbc3189@XCH-RCD-001.cisco.com> References: In-Reply-To: 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: [10.154.205.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] IPR disclosures on draft-ietf-netconf-yang-push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 19:04:30 -0000 Hi, I am not aware of any IPR related to this draft --- Alex -----Original Message----- From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]=20 Sent: Monday, October 26, 2015 12:03 PM To: draft-ietf-netconf-yang-push@ietf.org Cc: Netconf Subject: IPR disclosures on draft-ietf-netconf-yang-push Can each of the authors on the above draft disclose if they are aware of an= y IPRs related to this draft. Please respond to the mailing list. Thanks Mahesh & Mehmet From nobody Mon Oct 26 12:55: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 CC9C11A002D for ; Mon, 26 Oct 2015 12:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIEuZkSu9awU for ; Mon, 26 Oct 2015 12:55:06 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 90EA71A005A for ; Mon, 26 Oct 2015 12:54:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id t9QJsrnn015282 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Oct 2015 19:54:54 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 t9QJsr6f026337 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Oct 2015 20:54:53 +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.248.2; Mon, 26 Oct 2015 20:54:53 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.30]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0248.002; Mon, 26 Oct 2015 20:54:53 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WGLC for RESTCONF starting right after the IETF #94 Meeting Thread-Index: AdEQKBBy7T2grynxQZGvHEDrKqOWRg== Date: Mon, 26 Oct 2015 19:54:52 +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.122] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819817A66DEMUMBX005nsnin_" 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: 2412 X-purgate-ID: 151667::1445889294-0000047E-0EBB4E33/0/0 Archived-At: Subject: [Netconf] WGLC for RESTCONF starting right after the IETF #94 Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 19:55:11 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819817A66DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, we will go with the 3 drafts below to WGLC right after the IETF #94 meeting= . Please start reviewing and comment on the maillist. http://tools.ietf.org/html/draft-ietf-netconf-restconf http://tools.ietf.org/html/draft-ietf-netconf-yang-patch http://tools.ietf.org/html/draft-ietf-netconf-yang-library Best Regards, Mehmet & Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F819817A66DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
 
we will go with the 3 drafts below to WGLC rig= ht after the IETF #94 meeting.
Please start reviewing and comment on the mail= list.
 
 
 
Best Regards,
Mehmet & Mahesh
 
 
 
--_000_E4DE949E6CE3E34993A2FF8AE79131F819817A66DEMUMBX005nsnin_-- From nobody Mon Oct 26 13:18: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 EF03C1A0173 for ; Mon, 26 Oct 2015 13:18:18 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 cgGjmAi7NKaB for ; Mon, 26 Oct 2015 13:18:17 -0700 (PDT) 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 760031A0187 for ; Mon, 26 Oct 2015 13:18:13 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id D254BD649286A; Mon, 26 Oct 2015 20:18:07 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t9QKIBnw028390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Oct 2015 21:18:11 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.114]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 26 Oct 2015 21:18:11 +0100 From: "Scharf, Michael (Michael)" To: "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" Thread-Topic: [Netconf] WGLC for RESTCONF starting right after the IETF #94 Meeting Thread-Index: AdEQKBBy7T2grynxQZGvHEDrKqOWRgAAizpA Date: Mon, 26 Oct 2015 20:18:10 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48529244@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48529244FR712WXCHMBA15z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] WGLC for RESTCONF starting right after the IETF #94 Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 20:18:19 -0000 --_000_655C07320163294895BBADA28372AF5D48529244FR712WXCHMBA15z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding draft-ietf-netconf-restconf-08: In https://mailarchive.ietf.org/arch/msg/netconf/RrapU9E4csg-hRU8MlcAc1ckLs= A there was a discussion about a potential SHOULD/MUST mismatch between Sec= tions 1.2 and Section 10./10.1.1. Have those sections been aligned? Thanks Michael From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (Nokia - DE/Munich) Sent: Monday, October 26, 2015 8:55 PM To: netconf@ietf.org Subject: [Netconf] WGLC for RESTCONF starting right after the IETF #94 Meet= ing Dear All, we will go with the 3 drafts below to WGLC right after the IETF #94 meeting= . Please start reviewing and comment on the maillist. http://tools.ietf.org/html/draft-ietf-netconf-restconf http://tools.ietf.org/html/draft-ietf-netconf-yang-patch http://tools.ietf.org/html/draft-ietf-netconf-yang-library Best Regards, Mehmet & Mahesh --_000_655C07320163294895BBADA28372AF5D48529244FR712WXCHMBA15z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding = draft-ietf-netconf-restconf-08:

 = ;

In https://m= ailarchive.ietf.org/arch/msg/netconf/RrapU9E4csg-hRU8MlcAc1ckLsA= there was a discussion about a potential SHOULD/MUST m= ismatch between Sections 1.2 and Section 10./10.1.1.

 = ;

Have those= sections been aligned?

 = ;

Thanks

 = ;

Michael

 = ;

 = ;

 = ;

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (Nokia - DE/Munich)
Sent: Monday, October 26, 2015 8:55 PM
To: netconf@ietf.org
Subject: [Netconf] WGLC for RESTCONF starting right after the IETF #= 94 Meeting

 

Dear All,

 

we will go with the 3 dra= fts below to WGLC right after the IETF #94 meeting.

Please start reviewing an= d comment on the maillist.

 

 

 

Best Regards,
Mehmet & Mahesh

 

 

 

--_000_655C07320163294895BBADA28372AF5D48529244FR712WXCHMBA15z_-- From nobody Mon Oct 26 13: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 EF3C31A01F6 for ; Mon, 26 Oct 2015 13:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meilNsE4m3C5 for ; Mon, 26 Oct 2015 13:25:47 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 14C9D1A01EC for ; Mon, 26 Oct 2015 13:25:47 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so48952671lbc.3 for ; Mon, 26 Oct 2015 13:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L0ULGQLO3gSHdg1nZlRaXXag8h4DMAX7W63aik6+p/Y=; b=lTsFJwe5whWqmCL2XfGQawOgiNwKfiVBw/OhFSwx8yTPdxkrBdNL/uKemfKQJZqLdw eIG8iq4Rh22WKBEihPgbHBvqbEbrDZBbQPtGZmHLysg1Fv8c/GrADiDJZgGUJ4NIC2vq 0EAUBiXNKPHPatSVZ5FD78PtvGyDwKrONzlemKvNiaHHTrcvul+t96ACJ05sZKgi3JTt ej5yp96sG7jArHzNMuaeAsQVHTEKQciClUOBlAHW50PDcSKHd6J3ILef7aloFs7934gP 6oc1qeiGYwcYkixdjqxoAk4OP/ymRnSDuPmCujsrNHUUkbuzU2AJney20h7hJgNBxRIx 80AQ== 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=L0ULGQLO3gSHdg1nZlRaXXag8h4DMAX7W63aik6+p/Y=; b=IsaPt+8My4QYlgfQw5mZxwCRG4APmL+gigjh94L4mQ8bkf18PWkUxBApVo9ngTf05S fTATUcyb+sDLE8PfhAEHLpfJgR1RzdAjOGH4jDWSa9Oqm2Iu9DtshGaU1k70i+7XfSQ6 7eBcznWvYudplkimnFi8E22zNXrYCewRXJKmU7TWFxMPgLUHSFwQer/80YA2lrJNkkjp H2ZsDRyo9FmwgOMkhR9pmxUBF1APawu4JFfavBxUAHLoKSHgi0EpFGPeaUH2o2LmZ6EB 8WcdzKAazahqTbSMyF+3XAVTcyBRFVKbX6BL8puhfGNdCVmINEUDCKRQX5ZODGfVi5lo pFjg== X-Gm-Message-State: ALoCoQkA37lPe/yVHMWBCiRnodw712b3TErE80yyRSgvMdTx4Dgs0ZQSRNByQFsKG3RhzTjqEI90 MIME-Version: 1.0 X-Received: by 10.112.141.7 with SMTP id rk7mr17417776lbb.82.1445891145092; Mon, 26 Oct 2015 13:25:45 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Mon, 26 Oct 2015 13:25:45 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D48529244@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D48529244@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 26 Oct 2015 13:25:45 -0700 Message-ID: From: Andy Bierman To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=001a11c37e1a166be3052307c4e5 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WGLC for RESTCONF starting right after the IETF #94 Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 20:25:49 -0000 --001a11c37e1a166be3052307c4e5 Content-Type: text/plain; charset=UTF-8 Hi, I think this edit was missed. The SHOULD in sec 1.2 will be changed to MUST. sorry, Andy On Mon, Oct 26, 2015 at 1:18 PM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > Regarding draft-ietf-netconf-restconf-08: > > > > In > https://mailarchive.ietf.org/arch/msg/netconf/RrapU9E4csg-hRU8MlcAc1ckLsA there > was a discussion about a potential SHOULD/MUST mismatch between Sections > 1.2 and Section 10./10.1.1. > > > > Have those sections been aligned? > > > > Thanks > > > > Michael > > > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Ersue, > Mehmet (Nokia - DE/Munich) > *Sent:* Monday, October 26, 2015 8:55 PM > *To:* netconf@ietf.org > *Subject:* [Netconf] WGLC for RESTCONF starting right after the IETF #94 > Meeting > > > > Dear All, > > > > we will go with the 3 drafts below to WGLC right after the IETF #94 > meeting. > > Please start reviewing and comment on the maillist. > > > > http://tools.ietf.org/html/draft-ietf-netconf-restconf > > http://tools.ietf.org/html/draft-ietf-netconf-yang-patch > > http://tools.ietf.org/html/draft-ietf-netconf-yang-library > > > > > > Best Regards, > Mehmet & Mahesh > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c37e1a166be3052307c4e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think this edit was missed.
=
The SHOULD in sec 1.2 will be changed to MUST.


sorry,
Andy


On Mon, Oct 26, 2015 at 1:18 PM, Scharf= , Michael (Michael) <michael.scharf@alcatel-lucent.com= > wrote:

Regarding = draft-ietf-netconf-restconf-08:

=C2= =A0

In https://mailarchive.ietf.org/arch/msg/netconf/RrapU9E4csg-hRU8Ml= cAc1ckLsA there was a discussion about a potential SHOULD/MUST m= ismatch between Sections 1.2 and Section 10./10.1.1.

=C2= =A0

Have those= sections been aligned?

=C2= =A0

Thanks<= /u>

=C2= =A0

Michael=

=C2= =A0

=C2= =A0

=C2= =A0

From: Netconf = [mailto:netco= nf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (Nokia - DE/Munich)
Sent: Monday, October 26, 2015 8:55 PM
To: netconf@ie= tf.org
Subject: [Netconf] WGLC for RESTCONF starting right after the IETF #= 94 Meeting

=C2=A0

Dear All,

=C2=A0

we will go with the 3 dra= fts below to WGLC right after the IETF #94 meeting.<= /u>

Please start reviewing an= d comment on the maillist.

=C2=A0

=C2=A0

=C2=A0

Best Regards,
Mehmet & Mahesh

=C2=A0

=C2=A0

=C2=A0


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


--001a11c37e1a166be3052307c4e5-- From nobody Mon Oct 26 13:46: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 B9E4D1A03F9 for ; Mon, 26 Oct 2015 13:46:53 -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 VMnxcj6bJfEp for ; Mon, 26 Oct 2015 13:46:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 C89F71A03E1 for ; Mon, 26 Oct 2015 13:46:46 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id t9QKkh9V020525 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Oct 2015 20:46: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 t9QKkd83010107 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 21:46:42 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.30]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0248.002; Mon, 26 Oct 2015 21:46:39 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: EXT Andy Bierman , "Scharf, Michael (Michael)" Thread-Topic: [Netconf] WGLC for RESTCONF starting right after the IETF #94 Meeting Thread-Index: AQHRECx+YvEXnErLRUGqo5xbxERmu55+PaCg Date: Mon, 26 Oct 2015 20:46:37 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48529244@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.103] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819817B3EDEMUMBX005nsnin_" 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: 20054 X-purgate-ID: 151667::1445892403-00005272-129DD745/0/0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WGLC for RESTCONF starting right after the IETF #94 Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 20:46:53 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819817B3EDEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCwgQW5keSwNCg0Kc2ltaWxhciBidWcgZml4aW5nIGNhbiBiZSBzdGlsbCBkb25l IGR1cmluZyBJRVRGIHdlZWsuDQoNCk1laG1ldA0KDQpGcm9tOiBFWFQgQW5keSBCaWVybWFuIFtt YWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDI2LCAyMDE1 IDk6MjYgUE0NClRvOiBTY2hhcmYsIE1pY2hhZWwgKE1pY2hhZWwpIDxtaWNoYWVsLnNjaGFyZkBh bGNhdGVsLWx1Y2VudC5jb20+DQpDYzogRXJzdWUsIE1laG1ldCAoTm9raWEgLSBERS9NdW5pY2gp IDxtZWhtZXQuZXJzdWVAbm9raWEuY29tPjsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtOZXRjb25mXSBXR0xDIGZvciBSRVNUQ09ORiBzdGFydGluZyByaWdodCBhZnRlciB0aGUgSUVU RiAjOTQgTWVldGluZw0KDQpIaSwNCg0KSSB0aGluayB0aGlzIGVkaXQgd2FzIG1pc3NlZC4NClRo ZSBTSE9VTEQgaW4gc2VjIDEuMiB3aWxsIGJlIGNoYW5nZWQgdG8gTVVTVC4NCg0KDQpzb3JyeSwN CkFuZHkNCg0KDQpPbiBNb24sIE9jdCAyNiwgMjAxNSBhdCAxOjE4IFBNLCBTY2hhcmYsIE1pY2hh ZWwgKE1pY2hhZWwpIDxtaWNoYWVsLnNjaGFyZkBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOm1p Y2hhZWwuc2NoYXJmQGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdyb3RlOg0KUmVnYXJkaW5nIGRyYWZ0 LWlldGYtbmV0Y29uZi1yZXN0Y29uZi0wODoNCg0KSW4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9uZXRjb25mL1JyYXBVOUU0Y3NnLWhSVThNbGNBYzFja0xzQSB0aGVyZSB3 YXMgYSBkaXNjdXNzaW9uIGFib3V0IGEgcG90ZW50aWFsIFNIT1VMRC9NVVNUIG1pc21hdGNoIGJl dHdlZW4gU2VjdGlvbnMgMS4yIGFuZCBTZWN0aW9uIDEwLi8xMC4xLjEuPGh0dHA6Ly8xMC4xLjEu Pg0KDQpIYXZlIHRob3NlIHNlY3Rpb25zIGJlZW4gYWxpZ25lZD8NCg0KVGhhbmtzDQoNCk1pY2hh ZWwNCg0KDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBFcnN1ZSwgTWVo bWV0IChOb2tpYSAtIERFL011bmljaCkNClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNiwgMjAxNSA4 OjU1IFBNDQpUbzogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NClN1 YmplY3Q6IFtOZXRjb25mXSBXR0xDIGZvciBSRVNUQ09ORiBzdGFydGluZyByaWdodCBhZnRlciB0 aGUgSUVURiAjOTQgTWVldGluZw0KDQpEZWFyIEFsbCwNCg0Kd2Ugd2lsbCBnbyB3aXRoIHRoZSAz IGRyYWZ0cyBiZWxvdyB0byBXR0xDIHJpZ2h0IGFmdGVyIHRoZSBJRVRGICM5NCBtZWV0aW5nLg0K UGxlYXNlIHN0YXJ0IHJldmlld2luZyBhbmQgY29tbWVudCBvbiB0aGUgbWFpbGxpc3QuDQoNCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZg0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcGF0Y2gNCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi15YW5nLWxpYnJhcnkN Cg0KDQpCZXN0IFJlZ2FyZHMsDQpNZWhtZXQgJiBNYWhlc2gNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0 DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg== --_000_E4DE949E6CE3E34993A2FF8AE79131F819817B3EDEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAwMDk5Ow0KCWZvbnQtd2VpZ2h0Om5v cm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPkhpIE1pY2hhZWwsIEFuZHksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5zaW1pbGFyIGJ1ZyBmaXhpbmcgY2FuIGJl IHN0aWxsIGRvbmUgZHVyaW5nIElFVEYgd2Vlay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5OSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDAwQ0MiPk1laG1ldA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFWFQg QW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgT2N0b2JlciAyNiwgMjAxNSA5OjI2IFBNPGJyPg0KPGI+VG86PC9iPiBTY2hh cmYsIE1pY2hhZWwgKE1pY2hhZWwpICZsdDttaWNoYWVsLnNjaGFyZkBhbGNhdGVsLWx1Y2VudC5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBFcnN1ZSwgTWVobWV0IChOb2tpYSAtIERFL011bmljaCkg Jmx0O21laG1ldC5lcnN1ZUBub2tpYS5jb20mZ3Q7OyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gV0dMQyBmb3IgUkVTVENPTkYgc3RhcnRpbmcgcmln aHQgYWZ0ZXIgdGhlIElFVEYgIzk0IE1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgdGhpcyBlZGl0IHdhcyBtaXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgU0hPVUxEIGluIHNlYyAxLjIgd2lsbCBi ZSBjaGFuZ2VkIHRvIE1VU1QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+c29ycnksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBNb24sIE9jdCAyNiwgMjAxNSBhdCAxOjE4IFBNLCBTY2hhcmYsIE1pY2hhZWwg KE1pY2hhZWwpICZsdDs8YSBocmVmPSJtYWlsdG86bWljaGFlbC5zY2hhcmZAYWxjYXRlbC1sdWNl bnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWljaGFlbC5zY2hhcmZAYWxjYXRlbC1sdWNlbnQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkaW5nIGRyYWZ0LWlldGYt bmV0Y29uZi1yZXN0Y29uZi0wODo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5Jbg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvbmV0Y29uZi9ScmFwVTlFNGNzZy1oUlU4TWxjQWMxY2tMc0EiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvbmV0Y29uZi9ScmFwVTlFNGNzZy1oUlU4TWxjQWMxY2tMc0E8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4NCiB0aGVyZSB3YXMgYSBkaXNjdXNzaW9uIGFib3V0 IGEgcG90ZW50aWFsIFNIT1VMRC9NVVNUIG1pc21hdGNoIGJldHdlZW4gU2VjdGlvbnMgMS4yIGFu ZCBTZWN0aW9uIDEwLi88L3NwYW4+PGEgaHJlZj0iaHR0cDovLzEwLjEuMS4iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEwLjEuMS48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGF2ZSB0aG9zZSBzZWN0aW9ucyBiZWVuIGFsaWduZWQ/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIj4gTmV0Y29uZiBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPm5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+RXJzdWUsIE1laG1ldCAoTm9raWEgLSBERS9NdW5pY2gpPGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgT2N0b2JlciAyNiwgMjAxNSA4OjU1IFBNPGJyPg0KPGI+VG86PC9iPiA8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+bmV0Y29uZkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBbTmV0Y29uZl0gV0dMQyBmb3IgUkVTVENPTkYgc3RhcnRpbmcgcmln aHQgYWZ0ZXIgdGhlIElFVEYgIzk0IE1lZXRpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAw MENDIj5EZWFyIEFsbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj53ZSB3aWxsIGdvIHdpdGggdGhlIDMg ZHJhZnRzIGJlbG93IHRvIFdHTEMgcmlnaHQgYWZ0ZXIgdGhlIElFVEYgIzk0IG1lZXRpbmcuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+UGxlYXNlIHN0YXJ0IHJldmlld2luZyBh bmQgY29tbWVudCBvbiB0aGUgbWFpbGxpc3QuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAwMENDIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDU2M0MxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l dGNvbmYtcmVzdGNvbmY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wYXRjaCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDU2M0MxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldGNvbmYteWFuZy1wYXRjaDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi15YW5nLWxpYnJhcnkiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzA1NjNDMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctbGlicmFyeTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDAwQ0MiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDBDQyI+QmVzdCBSZWdhcmRzLA0KPGJyPg0KTWVobWV0ICZh bXA7IE1haGVzaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwQ0MiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E4DE949E6CE3E34993A2FF8AE79131F819817B3EDEMUMBX005nsnin_-- From nobody Mon Oct 26 14:30: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 034691A1AFF; Mon, 26 Oct 2015 14:30:26 -0700 (PDT) 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 0q-SE0CzAJ0s; Mon, 26 Oct 2015 14:30:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9FC1A1AFB; Mon, 26 Oct 2015 14:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=226; q=dns/txt; s=iport; t=1445895024; x=1447104624; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MNgd20rh7cmy8VdULkNgofghJY5BqJQE0IGWm10tJdE=; b=ipqAgMZ7V/pcaesOybxtZKLsayXnB3whHQHTZmDunUPDlZd7jLJXXgwB 8XAtFsk6w5bnkbTOmhDkA8ZW04+mBQD5mx3wpw09FpoiRMUtknzK5GiYo YNhpoW2FBKRRBUdBFicf9v6uKbnXQzR3jgeudELO9TRA+4WhyFFOdFK1n w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABAgCimi5W/5NdJa1egzaBQwa+PgENgVqGHQKBODgUAQEBAQEBAYEKhDMBAQQ6PxACAQg2EDIlAgQBDQWIMMYFAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIt1hQ0HhC4BBJY2AY0hnC4BHwEBQoQDcoYSgQYBAQE X-IronPort-AV: E=Sophos;i="5.20,201,1444694400"; d="scan'208";a="201492140" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2015 21:30:24 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t9QLUOaI032490 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Oct 2015 21:30:24 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 26 Oct 2015 16:30:00 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Mon, 26 Oct 2015 16:30:00 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: "Alexander Clemm (alex)" , Mahesh Jethanandani , "draft-ietf-netconf-yang-push@ietf.org" Thread-Topic: IPR disclosures on draft-ietf-netconf-yang-push Thread-Index: AQHRECDkG5kH3Fec5kiAEIda13QrJ55+daYA//+zmwA= Date: Mon, 26 Oct 2015 21:30:00 +0000 Message-ID: References: <9b59aa7c8db24af9b6ea5ceb2bbc3189@XCH-RCD-001.cisco.com> In-Reply-To: <9b59aa7c8db24af9b6ea5ceb2bbc3189@XCH-RCD-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.156.49.255] Content-Type: text/plain; charset="us-ascii" Content-ID: <47581797682CFB469D5C11602DEAAFEC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] IPR disclosures on draft-ietf-netconf-yang-push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 26 Oct 2015 21:30:26 -0000 Hi, I am not aware of any IPR related to this draft Thanks, Alberto On 10/26/15, 12:03 PM, "Alexander Clemm (alex)" wrote: >Hi, >I am not aware of any IPR related to this draft >--- Alex From nobody Mon Oct 26 18:40: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 8BA511B329B for ; Mon, 26 Oct 2015 18:40:06 -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 m-MzYUKFmmPX for ; Mon, 26 Oct 2015 18:40:05 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 44ED21B329A for ; Mon, 26 Oct 2015 18:40:05 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so214094727pac.3 for ; Mon, 26 Oct 2015 18:40:05 -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=1X6Hqiw1ir4z6GzoCWEnvO1uRVTTBY7NF67UfzkiMN8=; b=ZkSjyxzsqAx2XYlblry7AyIM01o0Rj4iBmzOUwrmnbQdykZoKcL3hiQw/jVmr5+M2O cZwd9VpkHrWq3vsCqXZA/RvxxsnEDVQlt5GE+Cp4RDwInsfow0QtDlr93hsxc1nHqGc+ fYARxUPZtYcH2c0uxWZBeJwkNZ51t228cCAlEKbjpEInWbf41v/OO5pno9SxbC8uSi+c VpQsT6QGBMGU5yxlh6WGUTrgL4pXJPv3vyi+QKKW0VdimfNJJn9RQIUcTLy9Hth2FrDU bHRsTr5+9yFyJYUVMZltMoHGKVJaDP46aI6dQcJ1raeeLiz7Rg2nLZKDBcucubS8x8kh co/Q== X-Received: by 10.68.239.105 with SMTP id vr9mr25301176pbc.161.1445910004933; Mon, 26 Oct 2015 18:40:04 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1003::64? ([2001:420:c0c8:1003::64]) by smtp.gmail.com with ESMTPSA id iy1sm36173761pbb.85.2015.10.26.18.40.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Oct 2015 18:40:03 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_0AF626E8-BB13-4CBA-AFA6-087AB5DD43D2" Message-Id: <2290CCC0-7803-4FA8-9E3B-C81601AA0371@gmail.com> Date: Mon, 26 Oct 2015 18:40:00 -0700 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Netconf] Preliminary Agenda has been posted. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 01:40:06 -0000 --Apple-Mail=_0AF626E8-BB13-4CBA-AFA6-087AB5DD43D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please find the agenda for netconf WG posted at = https://www.ietf.org/proceedings/94/agenda/agenda-94-netconf = . If you are one of the presenters, please submit your slides to the = chairs (netconf-chairs@ietf.org) by this Friday. Cheers Mahesh & Mehmet. --Apple-Mail=_0AF626E8-BB13-4CBA-AFA6-087AB5DD43D2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Please find the agenda for netconf WG posted at https://www.ietf.org/proceedings/94/agenda/agenda-94-netconf.

If you are one of the presenters, please submit your slides to the chairs (netconf-chairs@ietf.org) by this Friday.

Cheers

Mahesh & Mehmet.



--Apple-Mail=_0AF626E8-BB13-4CBA-AFA6-087AB5DD43D2-- From nobody Mon Oct 26 20:49:05 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 D80781A90E6; Mon, 26 Oct 2015 20:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_DR=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 jWwJmbjv2VTZ; Mon, 26 Oct 2015 20:49:02 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 C60CB1A90E0; Mon, 26 Oct 2015 20:49:01 -0700 (PDT) Received: by lffz202 with SMTP id z202so166563260lff.3; Mon, 26 Oct 2015 20:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7U5vz1QPu9Hg/dB2on217N16kKtTwKowWZuaAAulJZA=; b=YKI6nMQYqM0f4YkwoDjrvRDff/NtAGUx0ZX18li/dgevXpqsCDXtYso9/oXFWl96oF jz3D4lW/sjCt23zY8CfBsSAHDAd94qlwKeyjU2RISwW92Asu9sdPa+SXOTu18joQDpzc olgtPCmoPlQRJabbW5XM8JE4oB/CUYUWvYPq3uFE5Sw6t634tE1wV66+wqfVpIX56IrJ NkzEOt0ODvdKNOxgEFg2LHu1DwMNA5WmxAg0yIBC3RqIfbUpq3iTGrvCb93TDdrJ98Dw GHmnS6vwDEFPhAP8lMgtbh+CUC1LnnkNC6nuHSHU4LKRm++Ot+d6pPAiLJY8icVcUa2Q nnIg== MIME-Version: 1.0 X-Received: by 10.25.167.2 with SMTP id q2mr3763351lfe.15.1445917740075; Mon, 26 Oct 2015 20:49:00 -0700 (PDT) Received: by 10.25.8.5 with HTTP; Mon, 26 Oct 2015 20:49:00 -0700 (PDT) In-Reply-To: References: <9b59aa7c8db24af9b6ea5ceb2bbc3189@XCH-RCD-001.cisco.com> Date: Tue, 27 Oct 2015 09:19:00 +0530 Message-ID: From: "Dr. Karan Verma" To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a113fbdc645952e05230df5f2 Archived-At: Cc: "draft-ietf-netconf-yang-push@ietf.org" , Netconf Subject: Re: [Netconf] IPR disclosures on draft-ietf-netconf-yang-push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 03:49:04 -0000 --001a113fbdc645952e05230df5f2 Content-Type: text/plain; charset=UTF-8 Hello, I also not aware any IPR related this draft Thanks Dr. Karan On Tue, Oct 27, 2015 at 3:00 AM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Hi, > I am not aware of any IPR related to this draft > > Thanks, > > Alberto > > > > > On 10/26/15, 12:03 PM, "Alexander Clemm (alex)" wrote: > > >Hi, > >I am not aware of any IPR related to this draft > >--- Alex > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- *Kind Regards, * *Dr. Karan Verma * *UTP, Malaysia* *Phone: +60-166245082 <%2B60-166245082>* --001a113fbdc645952e05230df5f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I also not aware any IPR related= this draft=C2=A0

Thanks=C2=A0

Dr. Karan=C2=A0

On Tue, Oct 27, 2015 at 3:00 AM, Alberto Gonzalez Prieto (= albertgo) <albertgo@cisco.com> wrote:
Hi,
I am not aware of any IPR related to this draft

Thanks,

Alberto




On 10/26/15, 12:03 PM, "Alexander Clemm (alex)" <alex@cisco.com> wrote:

>Hi,
>I am not aware of any IPR related to this draft
>--- Alex

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



--
=
Kind Regards,=C2=A0

Dr. K= aran Verma=C2=A0
UTP, Malaysia
Phone:=C2=A0+60-166245082
--001a113fbdc645952e05230df5f2-- From nobody Tue Oct 27 08:24: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 0B06A1A9051; Tue, 27 Oct 2015 08:24:47 -0700 (PDT) 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 23IDEjFse3UM; Tue, 27 Oct 2015 08:24:45 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F361A904F; Tue, 27 Oct 2015 08:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=460; q=dns/txt; s=iport; t=1445959485; x=1447169085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FGzoKOAaSt3YRrsNz8FM76Kbv1y8ETciPh3B9NTmECs=; b=ROCy+xL8xuHIS266eiTFIzVUyNYE8g90SfXUVD2X3frurdsfzhHwT0yd n00euvwpq+dtJCrfa4VoiN613AY6eHnf4YYp94Fk7GK2nkWw4KDDJ5Krd ZRMuZIO8L8x+poPzaxpP7gvXgxSKePL7xEdDzhthB5peMIzlHfPaIsjUl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQDgli9W/5xdJa1egzZUbwa+fwENgVoXCoUvSgKBPDgUAQEBAQEBAYEKhDIBAQEDAQEBATc0CwULAgEIGB4QJwslAgQBDQUIiCAIDcVaAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGd4R+hQ0HhC4FljgBjRycOAEfAQFChARyhGiBBgEBAQ X-IronPort-AV: E=Sophos;i="5.20,205,1444694400"; d="scan'208";a="201766254" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2015 15:24:45 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t9RFOibC004747 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Oct 2015 15:24:44 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Oct 2015 10:24:20 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Tue, 27 Oct 2015 10:24:20 -0500 From: "Eric Voit (evoit)" To: "Alberto Gonzalez Prieto (albertgo)" , "Alexander Clemm (alex)" , Mahesh Jethanandani , "draft-ietf-netconf-yang-push@ietf.org" Thread-Topic: IPR disclosures on draft-ietf-netconf-yang-push Thread-Index: AQHRECDkG5kH3Fec5kiAEIda13QrJ55+daYA//+zmwCAAUwwwA== Date: Tue, 27 Oct 2015 15:24:20 +0000 Message-ID: <2261a10856834958bcba71c7a949aa22@XCH-ALN-013.cisco.com> References: <9b59aa7c8db24af9b6ea5ceb2bbc3189@XCH-RCD-001.cisco.com> In-Reply-To: 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: [10.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] IPR disclosures on draft-ietf-netconf-yang-push X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 15:24:47 -0000 Not aware of any IPR on this draft. Eric > Hi, > I am not aware of any IPR related to this draft >=20 > Thanks, >=20 > Alberto >=20 =20 >=20 > On 10/26/15, 12:03 PM, "Alexander Clemm (alex)" wrote: >=20 > >Hi, > >I am not aware of any IPR related to this draft > >--- Alex >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Oct 27 11:52: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 5C2F61ACDF5 for ; Tue, 27 Oct 2015 11:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 34pe3qnPlN72 for ; Tue, 27 Oct 2015 11:52:04 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 7814A1ACDDB for ; Tue, 27 Oct 2015 11:52:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Eric Voit \(evoit\)'" , References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> In-Reply-To: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> Date: Tue, 27 Oct 2015 14:52:04 -0400 Message-ID: <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_047C_01D110C7.0BD52770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG5besfxvOA7SwAHLssW9AMBuPuyJ6u7tDQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 18:52:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_047C_01D110C7.0BD52770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit NETCONF: These drafts is important to the I2RS pub/sub. Is the RESTCONF draft going to be adopted (draft-voit-restconf-yang-push-00.txt)? It would be really helpful. Sue Hares I2RS WG chair From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Tuesday, October 13, 2015 11:37 PM To: netconf@ietf.org Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-ietf-netconf-yang-push in the coming days (once the NETCONF charter is approved). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: . proposes Restconf subscription and push mechanisms to continuously stream information from YANG datastores over HTTP . provides a mechanism to support static subscriptions so that an operator can stream updates over HTTP without Restconf . provides YANG model extensions to leverage HTTP/2 so that individual subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard ------=_NextPart_000_047C_01D110C7.0BD52770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

NETCONF:

 

These drafts is = important to the I2RS pub/sub.   Is the RESTCONF draft going = to be adopted (draft-voit-restconf-yang-push-00.txt)? =

 

It would be really = helpful. 

 

Sue Hares =

I2RS WG chair

 

From:= = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit = (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: = netconf@ietf.org
Subject: [Netconf] New YANG PubSub drafts for = NETCONF, RESTCONF, HTTP/2

 

There are a = couple new drafts posted in NETCONF:

 

(1)  = Subscribing to YANG datastore push updates

http= ://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt =

As per earlier NETCONF discussions we are expecting this draft to become = draft-ietf-netconf-yang-push in the coming days (once the NETCONF = charter is approved).  Look for an OpenDaylight client in the = Beryllium release (Feb). 

 

(2) Restconf = subscription and HTTP push for YANG datastores

http= ://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt =

Extends = draft-clemm-netconf-yang-push in the following ways:

·     proposes Restconf = subscription and push mechanisms to continuously stream information from = YANG datastores over HTTP

·     provides a mechanism to = support static subscriptions so that an operator can stream updates over = HTTP without Restconf

·     provides YANG model = extensions to leverage HTTP/2 so that individual subscriptions can get = custom treatment via their own HTTP streams. 

 

Thanks for = your interest, and we look forward to the discussions!

 

- Alexander = Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripathy, & = Einar Nilsen-Nygaard

 

 

 

 

------=_NextPart_000_047C_01D110C7.0BD52770-- From nobody Tue Oct 27 11:55: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 C2AC51ACE01; Tue, 27 Oct 2015 11:55:38 -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 nery_cG_JHGi; Tue, 27 Oct 2015 11:55:36 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 448EB1ACDFF; Tue, 27 Oct 2015 11:55:36 -0700 (PDT) Received: by wijp11 with SMTP id p11so228080005wij.0; Tue, 27 Oct 2015 11:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=i9t2eIvMrjOSTHvbuwON/8OXw8hONtUUsL8fB4sW85c=; b=mIOIJwupDRnpuH6vr4Ahlh4Pg2uX1cgiDqfCaH3mpvTsg/dq7lTITFNf8JcidfXIVp YW9VC//MCFgs9/CcA4l1Du5wXtH9dA+OPUB05Hfp3b42MCIDoSSZMGcT/eQEw8pVcotB r4HfMvAl1fv7+UTFmmjuZMdwhx1nSU64vlXDJQRLFiw89dAPGF5cgRLR3JrkQ2a9Vjqi dCgI7y13+m6xHCu60r2EdNN81IXcQvGVJVsFhL9fCdryADUI+yJ+AIPtm65QH/2tUmbK bAQFHWeZJOfxbPveATLK3PXAObCWF9LYQ+0WycY8YLkcF50RG5g/0l8IKqpEGyLc+KJn jwqA== MIME-Version: 1.0 X-Received: by 10.180.93.163 with SMTP id cv3mr26570579wib.36.1445972134665; Tue, 27 Oct 2015 11:55:34 -0700 (PDT) Received: by 10.28.214.142 with HTTP; Tue, 27 Oct 2015 11:55:34 -0700 (PDT) In-Reply-To: <93A12F18-FB21-4D08-B559-2E04295C5047@juniper.net> References: <20151021135330.20048.35548.idtracker@ietfa.amsl.com> <4F2C1542-6FCB-4B67-91A8-7AD55BC34EB5@juniper.net> <93A12F18-FB21-4D08-B559-2E04295C5047@juniper.net> Date: Tue, 27 Oct 2015 14:55:34 -0400 Message-ID: From: Kathleen Moriarty To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netconf@ietf.org" , The IESG , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 18:55:38 -0000 Hi Kent, Responses in-line. I think we are about good-to-go with one correction and suggested text for the last item. On Sat, Oct 24, 2015 at 1:17 AM, Kent Watsen wrote: > > Hi Kathleen, > > > > >>>>Section 2.1 & 3.1 >>>> Why is authentication limited to server-side authentication? It seems >>>> that this really should be mutual authentication to ensure the server = is >>>> also connecting to the correct client and there was no attack prior to >>>> the callback. >>> >>> >>> Both NETCONF ad RESTCONF require client authentication, and this is cal= led out in the Applicability Statement (Section 1.3). Also, in the "The NE= TCONF or RESTCONF Client=E2=80=9D section, it says: >>> >>> C7 After the server's host key or certificate is validated, the SSH >>> or TLS protocol proceeds as normal to establish a SSH or TLS >>> connection. >>> >>> The =E2=80=9Cproceeds as normal=E2=80=9D is intended to cover client au= thentication. >> >>Ok, this wasn't clear to me, but probably isn't the sentence to fix. > > > In the DISCUSS with Stephen, I offered to add the following text to the e= nd of C7: > > When performing client-authentcation with the NETCONF/RESTCONF > server, the NETCONF/RESTCONF client MUST ensure to only use > credentials that had previously associated for the NETCONF/RESTCONF > server=E2=80=99s presented host key or server certificate. > > I know you said this may not be the sentence to fix, but does it resolve = this issue for you? > Sure, this works with the update you agreed to below. > > > > > >>> Also, in the "The NETCONF or RESTCONF Server=E2=80=9D section, it says: >>> >>> >>> S5 In most cases, establishing the SSH or TLS connection also >>> entails server authentication of client credentials; only with >>> RESTCONF do some client authentication schemes occur after the >>> secure transport connection (TLS) has been established. >> >>I think if this said, "Establishing an SSH or TLS session requires server= authentication of client credentials, with the exception of..." >> >>The point would be more clear as I didn't realize this was already the ca= se from the language in this draft. > > Consider it done. Thank you! > > > > > >>> If >>> client authentication is required, and the client is unable to >>> successfully authenticate itself to the server in an amount of >>> time defined by local policy, the server MUST close the >>> connection. >>> >>> Which speaks to it as well. >>> >>> >>> Do you believe there is a need to change the text? >> >>Yes, but just the text where I made a suggestions u be enough to get the = point across more clearly. > > Sure, I=E2=80=99ll make the fix mentioned above. > Thank you! > > > > >>> >>> >>> >>> >>>> 3.1 S3 - Why is client-side authentication optional? >>>> >>>> Without this must, there should be a security consideration that the c= all >>>> back could go to a malicious client. The types of authentication matt= er >>>> as well, but that's covered in Stephen's discuss points along with the >>>> SecDir review questions on TLS-PSK. >>> >>> Do mean S5 pasted above where it says =E2=80=9CIf client authentication= is required=E2=80=9D? >> >>Yes. > > OLD: > > S5 In most cases, establishing the SSH or TLS connection also > entails server authentication of client credentials; only with > RESTCONF do some client authentication schemes occur after the > secure transport connection (TLS) has been established. If > client authentication is required, and the client is unable to > successfully authenticate itself to the server in an amount of > time defined by local policy, the server MUST close the > connection. > > NEW: s/client/transport (SSH or TLS) level client/ > > > S5 In most cases, establishing the SSH or TLS connection also > entails server authentication of client credentials; only with > RESTCONF do some client authentication schemes occur after the > secure transport connection (TLS) has been established. If > transport (SSH or TLS) level client authentication is required, and= the client is unable to > successfully authenticate itself to the server in an amount of > time defined by local policy, the server MUST close the > connection. > > > Does this text resolve your issue? This works for me, thanks. > > > > > >>> >>> This text is speaking about transport-level client-auth. NETCONF over = SSH or over TLS both have transport-level authentication, but RESTCONF (e.g= ., HTTPS) allows the Basic and Digest authentication modes, and that client= auth happen after the TLS session is established. >> >>Ok, is it possible to make this more clear? I think Stephen has a discus= s on HTTPAuth methods already, so that can be discussed in his thread. I j= ust ask that you point to the newly updated RFCs on these 2 standards as th= ey do a good job of outlining all of the security considerations, which are= substantial. RFC7616 & RFC 7615 > > Sure (but I=E2=80=99ll assume you meant 7617, instead of 7616) Basic is in RFC7616 and digest is in RFC7617, so you are partially correct and I had the incorrect number in my message. > > > > > >>> >>> >>> >>> >>>> In section 1.3, please add a sentence that points to the threat/securi= ty >>>> analysis for use of this function with NETCONF and RESTCONF after the >>>> last sentence: >>>> >>>> In such circumstances, allowing the SSH/TLS server to contact the >>>> SSH/TLS client would open new vulnerabilities. Any use of call home >>>> with SSH/TLS for purposes other than NETCONF or RESTCONF will need a >>>> thorough, contextual security analysis. >>> >>> Unfortunately, there isn't an analysis to point to. The =E2=80=9Canaly= sis=E2=80=9D is happening now along with the SecDir review. Do we need to= perform such an analysis now? >>> >>The section reads as if one exists and that you've mitigated the risks. = As such, I'd expect to see all of the security considerations for using the= method defined in this draft. Making the auth requirements more clear wil= l help and pointing out the vulnerability of the HTTPAuth basic and digest = modes for RESTCONF in the security considerations is part of that. >> >>Mention of the possibility of connecting to an incorrect client (possibly= malicious) in the few instances where client auth isn't required or is wea= k is important as well for the reader. > > > Hmmm, so I=E2=80=99m not sure what to do with this comment. > > Yes, per Stephen=E2=80=99s DISCUSS, make the auth requirements more clear= , and point out the vulnerability of the HTTPAuth basic and digest modes fo= r RESTCONF in the security considerations (pending feedback from TLS WG and= openssh list). > > But back to Section 1.3, is there a specific change in the text that you= =E2=80=99re hoping to see here? How about the following: OLD: This contrasts with the base SSH and TLS protocols, which do not require programmatic verification of the other party (section 9.3.4 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). In such circumstances, allowing the SSH/TLS server to contact the SSH/TLS client would open new vulnerabilities. Any use of call home with SSH/TLS for purposes other than NETCONF or RESTCONF will need a thorough, contextual security analysis. NEW: This contrasts with the base SSH and TLS protocols, which do not require programmatic verification of the other party (section 9.3.4 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). In such circumstances, allowing the SSH/TLS server to contact the SSH/TLS client would open new vulnerabilities. Any use of call home with SSH/TLS needs a thorough, contextual security analysis. The analysis for NETCONF and RESTCONF is underway. I don't think you have a reference to add for this, correct? If you do, I would put that in as well. > > > > Thanks, > Kent > > > > > --=20 Best regards, Kathleen From nobody Tue Oct 27 12:21: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 AD2D31ACE7E for ; Tue, 27 Oct 2015 12:21:29 -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 hRrdbw5QydoC for ; Tue, 27 Oct 2015 12:21:23 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 6E4541ACE77 for ; Tue, 27 Oct 2015 12:21:23 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id t9RJLHpD006391 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Oct 2015 19:21:17 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t9RJLF3T017068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Oct 2015 20:21:17 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 27 Oct 2015 20:21:16 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.30]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 20:21:16 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: EXT Susan Hares , "'Eric Voit (evoit)'" , "netconf@ietf.org" Thread-Topic: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AQG5besfxvOA7SwAHLssW9AMBuPuyJ6u7tDQgAAL4pA= Date: Tue, 27 Oct 2015 19:21:15 +0000 Message-ID: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.com> In-Reply-To: <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.111] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819819104DEMUMBX005nsnin_" 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: 11579 X-purgate-ID: 151667::1445973678-0000047E-D4E2D2E4/0/0 Archived-At: Cc: 'Alia Atlas' Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 19:21:29 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819819104DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, whether draft-voit-restconf-yang-push can be seen as covered by the current= charter needs to be discussed in IETF 94. I can imagine the result is positive. Whether we go for a merged or an additional draft is more or less a matter = of practical thinking. Cheers, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of EXT Susan Hare= s Sent: Tuesday, October 27, 2015 7:52 PM To: 'Eric Voit (evoit)' ; netconf@ietf.org Cc: 'Alia Atlas' Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 NETCONF: These drafts is important to the I2RS pub/sub. Is the RESTCONF draft goin= g to be adopted (draft-voit-restconf-yang-push-00.txt)? It would be really helpful. Sue Hares I2RS WG chair From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Tuesday, October 13, 2015 11:37 PM To: netconf@ietf.org Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: * proposes Restconf subscription and push mechanisms to continuously st= ream information from YANG datastores over HTTP * provides a mechanism to support static subscriptions so that an opera= tor can stream updates over HTTP without Restconf * provides YANG model extensions to leverage HTTP/2 so that individual = subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard --_000_E4DE949E6CE3E34993A2FF8AE79131F819819104DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

whether draft-voit-restconf-yang-push can be seen as covered= by the current charter needs to be discussed in IETF 94.=

I can imagine the resu= lt is positive.

 

Whether we go for a me= rged or an additional draft is more or less a matter of practical thinking.=

 

Cheers, Mehmet

 

From: Netconf [mailto:netconf-bounces@ietf.or= g] On Behalf Of EXT Susan Hares
Sent: Tuesday, October 27, 2015 7:52 PM
To: 'Eric Voit (evoit)' <evoit@cisco.com>; netconf@ietf.org Cc: 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF,= HTTP/2

 

NETCONF:

 

These drafts is import= ant to the I2RS pub/sub.   Is the RESTCONF draft going to be adop= ted (draft-voit-restconf-yang-push-00.txt)?

 

It would be really hel= pful. 

 

Sue Hares <= /span>

I2RS WG chair

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: netconf@ietf.org
Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTT= P/2

 

There are a couple new drafts posted in NETCONF:

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-netconf-yang-push-02= .txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-restconf-yang-push-00= .txt

Extends draft-clemm-netconf-yang-push in the following ways:

·   =   proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

·   =   provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

·   =   provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819819104DEMUMBX005nsnin_-- From nobody Tue Oct 27 12:22: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 1F3B61ACE6C for ; Tue, 27 Oct 2015 12:22: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 cTx7djU4kCnS for ; Tue, 27 Oct 2015 12:22:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D90D1ACE78 for ; Tue, 27 Oct 2015 12:22:31 -0700 (PDT) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 27 Oct 2015 19:22:29 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0306.003; Tue, 27 Oct 2015 19:22:29 +0000 From: Kent Watsen To: Susan Hares , "'Eric Voit (evoit)'" , "netconf@ietf.org" Thread-Topic: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9wKtwvoA///Fb4A= Date: Tue, 27 Oct 2015 19:22:29 +0000 Message-ID: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.com> In-Reply-To: <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:rPKcgDOi9iHXzpsoGtq8L5dMYfqnVhkmVXOSsFVSq9a8qchoH4mfXbMaz1juSgdA846whhX1/god0SMy9UzOan7AzU8QrniXXptcIuzhNwWZ+r5aH2/xg2ySEoXNXWPQ1AZiL6BZ9j/eH/UWtAsdxg==; 24:vjaPCXMwmx0UttR/kA/c3HFQ0b1T+nlDYTpnY6LQCI9xDdNTx3BiGwrYWE5eR4oiedfVvggNNgmQqZOHvFud675ukxkH6PQyge7eekZT+3c=; 20:NZIlunS/N8ap3h9iVUD8VpgAjCLSWuPmK6ssT7tgRHp4iziKiGvCyA9E1WvnsEpfs6EdANIK0gzTs0etaPuH5Q== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102215026); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(199003)(189002)(105586002)(40100003)(92566002)(16236675004)(5007970100001)(11100500001)(86362001)(19580395003)(36756003)(5001960100002)(122556002)(15975445007)(189998001)(19580405001)(106356001)(2950100001)(99286002)(19300405004)(5002640100001)(10400500002)(2501003)(19617315012)(5004730100002)(97736004)(87936001)(83716003)(5001770100001)(81156007)(82746002)(66066001)(2900100001)(33656002)(5001920100001)(83506001)(101416001)(19625215002)(50986999)(4001350100001)(76176999)(54356999)(77096005)(102836002)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FA8545464B9648DE81EA3F490A6F95EDjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 19:22:29.1303 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: 'Alia Atlas' Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 19:22:37 -0000 --_000_FA8545464B9648DE81EA3F490A6F95EDjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIHRoaW5rIGl0IGltcG9ydGFudCB0aGF0IHdoYXRldmVyIHdlIGRvIGluIE5FVENPTkYgd2Ug Y2FuIGFsc28gZG8gaW4gUkVTVENPTkYuICAgVG8gdGhhdCBlbmQsIEkgc3VwcG9ydCB0aGUgV0cg ZGVmaW5pbmcgInlhbmctcHVzaOKAnSBmb3IgYm90aCBwcm90b2NvbHMuDQoNCkFjdHVhbGx5LCBJ 4oCZbSBhIGxpdHRsZSBzdXJwcmlzZWQgdGhhdCB3ZeKAmXJlIGRpc2N1c3NpbmcgdGhpcy4gIE1h eWJlIGl04oCZcyBqdXN0IG1lLCBidXQgd2hlbiB0aGUgV0cgYWRvcHRlZCBkcmFmdC1pZXRmLW5l dGNvbmYteWFuZy1wdXNoLCBJIHRob3VnaHQgdGhhdCBpdCB3b3VsZCBjb3ZlciBib3RoIHByb3Rv Y29scyBldmVudHVhbGx5LiAgIFBlcmhhcHMgdGhhdCBhIHNlcGFyYXRlIGRyYWZ0IGhhcyBiZWVu IHByb2R1Y2VkIGlzIGFub3RoZXIgc3VycHJpc2UgaGVyZSAtIGRvIHdlIHJlYWxseSBuZWVkIGFu b3RoZXIgZHJhZnQ/DQoNCktlbnQNCg0KRnJvbTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3Vz YW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6 IFR1ZXNkYXksIE9jdG9iZXIgMjcsIDIwMTUgYXQgMjo1MiBQTQ0KVG86ICInRXJpYyBWb2l0IChl dm9pdCknIiA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PiwgIm5ldGNv bmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxt YWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpDYzogJ0FsaWEgQXRsYXMnIDxha2F0bGFzQGdtYWls LmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBO ZXcgWUFORyBQdWJTdWIgZHJhZnRzIGZvciBORVRDT05GLCBSRVNUQ09ORiwgSFRUUC8yDQoNCk5F VENPTkY6DQoNClRoZXNlIGRyYWZ0cyBpcyBpbXBvcnRhbnQgdG8gdGhlIEkyUlMgcHViL3N1Yi4g ICBJcyB0aGUgUkVTVENPTkYgZHJhZnQgZ29pbmcgdG8gYmUgYWRvcHRlZCAoZHJhZnQtdm9pdC1y ZXN0Y29uZi15YW5nLXB1c2gtMDAudHh0KT8NCg0KSXQgd291bGQgYmUgcmVhbGx5IGhlbHBmdWwu DQoNClN1ZSBIYXJlcw0KSTJSUyBXRyBjaGFpcg0KDQpGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0IChldm9pdCkNClNl bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTMsIDIwMTUgMTE6MzcgUE0NClRvOiBuZXRjb25mQGlldGYu b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogW05ldGNvbmZdIE5ldyBZQU5H IFB1YlN1YiBkcmFmdHMgZm9yIE5FVENPTkYsIFJFU1RDT05GLCBIVFRQLzINCg0KVGhlcmUgYXJl IGEgY291cGxlIG5ldyBkcmFmdHMgcG9zdGVkIGluIE5FVENPTkY6DQoNCigxKSAgU3Vic2NyaWJp bmcgdG8gWUFORyBkYXRhc3RvcmUgcHVzaCB1cGRhdGVzDQpodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoLTAyLnR4dA0KQXMgcGVyIGVhcmxpZXIgTkVU Q09ORiBkaXNjdXNzaW9uczxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0 Y29uZi9jdXJyZW50L21zZzEwNDMyLmh0bWw+IHdlIGFyZSBleHBlY3RpbmcgdGhpcyBkcmFmdCB0 byBiZWNvbWUgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaCBpbiB0aGUgY29taW5nIGRheXMg KG9uY2UgdGhlIE5FVENPTkYgY2hhcnRlciBpcyBhcHByb3ZlZCkuICBMb29rIGZvciBhbiBPcGVu RGF5bGlnaHQgY2xpZW50IGluIHRoZSBCZXJ5bGxpdW0gcmVsZWFzZSAoRmViKS4NCg0KKDIpIFJl c3Rjb25mIHN1YnNjcmlwdGlvbiBhbmQgSFRUUCBwdXNoIGZvciBZQU5HIGRhdGFzdG9yZXMNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtdm9pdC1yZXN0Y29uZi15YW5nLXB1c2gtMDAudHh0 DQpFeHRlbmRzIGRyYWZ0LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoIGluIHRoZSBmb2xsb3dpbmcg d2F5czoNCg0KwrcgICAgIHByb3Bvc2VzIFJlc3Rjb25mIHN1YnNjcmlwdGlvbiBhbmQgcHVzaCBt ZWNoYW5pc21zIHRvIGNvbnRpbnVvdXNseSBzdHJlYW0gaW5mb3JtYXRpb24gZnJvbSBZQU5HIGRh dGFzdG9yZXMgb3ZlciBIVFRQDQoNCsK3ICAgICBwcm92aWRlcyBhIG1lY2hhbmlzbSB0byBzdXBw b3J0IHN0YXRpYyBzdWJzY3JpcHRpb25zIHNvIHRoYXQgYW4gb3BlcmF0b3IgY2FuIHN0cmVhbSB1 cGRhdGVzIG92ZXIgSFRUUCB3aXRob3V0IFJlc3Rjb25mDQoNCsK3ICAgICBwcm92aWRlcyBZQU5H IG1vZGVsIGV4dGVuc2lvbnMgdG8gbGV2ZXJhZ2UgSFRUUC8yIHNvIHRoYXQgaW5kaXZpZHVhbCBz dWJzY3JpcHRpb25zIGNhbiBnZXQgY3VzdG9tIHRyZWF0bWVudCB2aWEgdGhlaXIgb3duIEhUVFAg c3RyZWFtcy4NCg0KVGhhbmtzIGZvciB5b3VyIGludGVyZXN0LCBhbmQgd2UgbG9vayBmb3J3YXJk IHRvIHRoZSBkaXNjdXNzaW9ucyENCg0KLSBBbGV4YW5kZXIgQ2xlbW0sIEVyaWMgVm9pdCwgQWxi ZXJ0byBHb256YWxleiBQcmlldG8sIEFtYmlrYSBQcmFzYWQgVHJpcGF0aHksICYgRWluYXIgTmls c2VuLU55Z2FhcmQNCg0KDQoNCg0K --_000_FA8545464B9648DE81EA3F490A6F95EDjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <46CAAC4D408C4D43B9D4287C627EB68F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSSB0aGlu ayBpdCBpbXBvcnRhbnQgdGhhdCB3aGF0ZXZlciB3ZSBkbyBpbiBORVRDT05GIHdlIGNhbiBhbHNv IGRvIGluIFJFU1RDT05GLiAmbmJzcDsgVG8gdGhhdCBlbmQsIEkgc3VwcG9ydCB0aGUgV0cgZGVm aW5pbmcgJnF1b3Q7eWFuZy1wdXNo4oCdIGZvciBib3RoIHByb3RvY29scy48L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KQWN0dWFsbHksIEnigJltIGEgbGl0dGxlIHN1cnByaXNlZCB0aGF0IHdl4oCZ cmUgZGlzY3Vzc2luZyB0aGlzLiAmbmJzcDtNYXliZSBpdOKAmXMganVzdCBtZSwgYnV0IHdoZW4g dGhlIFdHIGFkb3B0ZWQgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaCwgSSB0aG91Z2h0IHRo YXQgaXQgd291bGQgY292ZXIgYm90aCBwcm90b2NvbHMgZXZlbnR1YWxseS4gJm5ic3A7IFBlcmhh cHMgdGhhdCBhIHNlcGFyYXRlIGRyYWZ0IGhhcyBiZWVuIHByb2R1Y2VkIGlzIGFub3RoZXIgc3Vy cHJpc2UNCiBoZXJlIC0gZG8gd2UgcmVhbGx5IG5lZWQgYW5vdGhlciBkcmFmdD88L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KS2VudDwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K PGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPk5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBv ZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVz QG5kemguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0 ZTogPC9zcGFuPlR1ZXNkYXksIE9jdG9iZXIgMjcsIDIwMTUgYXQgMjo1MiBQTTxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OydFcmljIFZvaXQgKGV2 b2l0KScmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20iPmV2b2l0QGNp c2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+ bmV0Y29uZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGll dGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4nQWxpYSBBdGxhcycgJmx0OzxhIGhyZWY9Im1haWx0bzph a2F0bGFzQGdtYWlsLmNvbSI+YWthdGxhc0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtOZXRjb25mXSBOZXcg WUFORyBQdWJTdWIgZHJhZnRzIGZvciBORVRDT05GLCBSRVNUQ09ORiwgSFRUUC8yPGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2Zm aWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxu czptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHht bG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVy YXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk5FVENPTkY6IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlc2UgZHJhZnRzIGlzIGltcG9ydGFudCB0byB0aGUg STJSUyBwdWIvc3ViLiAmbmJzcDsmbmJzcDtJcyB0aGUgUkVTVENPTkYgZHJhZnQgZ29pbmcgdG8g YmUgYWRvcHRlZCAoZHJhZnQtdm9pdC1yZXN0Y29uZi15YW5nLXB1c2gtMDAudHh0KT8NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SXQgd291bGQgYmUgcmVhbGx5IGhlbHBm dWwuJm5ic3A7IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdWUgSGFy ZXMgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkkyUlMgV0cgY2hhaXIgPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij4gTmV0 Y29uZiBbPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgVm9p dCAoZXZvaXQpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMTMsIDIwMTUgMTE6 MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5u ZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbTmV0Y29uZl0gTmV3IFlB TkcgUHViU3ViIGRyYWZ0cyBmb3IgTkVUQ09ORiwgUkVTVENPTkYsIEhUVFAvMjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBhIGNvdXBsZSBu ZXcgZHJhZnRzIHBvc3RlZCBpbiBORVRDT05GOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oMSkm bmJzcDsgU3Vic2NyaWJpbmcgdG8gWUFORyBkYXRhc3RvcmUgcHVzaCB1cGRhdGVzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoLTAyLnR4dCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaC0wMi50eHQ8L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjYu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6OS4zNXB0 O21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQpBcyBwZXIgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cxMDQzMi5odG1sIj4NCmVh cmxpZXIgTkVUQ09ORiBkaXNjdXNzaW9uczwvYT4gd2UgYXJlIGV4cGVjdGluZyB0aGlzIGRyYWZ0 IHRvIGJlY29tZSBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoIGluIHRoZSBjb21pbmcgZGF5 cyAob25jZSB0aGUgTkVUQ09ORiBjaGFydGVyIGlzIGFwcHJvdmVkKS4mbmJzcDsgTG9vayBmb3Ig YW4gT3BlbkRheWxpZ2h0IGNsaWVudCBpbiB0aGUgQmVyeWxsaXVtIHJlbGVhc2UgKEZlYikuJm5i c3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDIpIFJlc3Rjb25mIHN1YnNjcmlwdGlvbiBh bmQgSFRUUCBwdXNoIGZvciBZQU5HIGRhdGFzdG9yZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtdm9pdC1y ZXN0Y29uZi15YW5nLXB1c2gtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXZv aXQtcmVzdGNvbmYteWFuZy1wdXNoLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDo5LjM1cHQ7bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij4NCkV4dGVuZHMgZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2ggaW4gdGhlIGZv bGxvd2luZyB3YXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDozMS41cHQ7dGV4dC1pbmRlbnQ6LTEzLjVwdCI+PHNwYW4gc3R5 bGU9IiI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogN3B0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+cHJvcG9zZXMgUmVzdGNvbmYgc3Vic2NyaXB0aW9uIGFuZCBwdXNoIG1lY2hhbmlzbXMgdG8g Y29udGludW91c2x5IHN0cmVhbSBpbmZvcm1hdGlvbiBmcm9tIFlBTkcgZGF0YXN0b3JlcyBvdmVy IEhUVFANCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDozMS41cHQ7dGV4dC1pbmRlbnQ6LTEzLjVwdCI+PHNwYW4gc3R5bGU9IiI+ wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogN3B0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+cHJv dmlkZXMgYSBtZWNoYW5pc20gdG8gc3VwcG9ydCBzdGF0aWMgc3Vic2NyaXB0aW9ucyBzbyB0aGF0 IGFuIG9wZXJhdG9yIGNhbiBzdHJlYW0gdXBkYXRlcyBvdmVyIEhUVFAgd2l0aG91dCBSZXN0Y29u ZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDozMS41cHQ7dGV4dC1pbmRlbnQ6LTEzLjVwdCI+PHNwYW4gc3R5bGU9IiI+wrc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogN3B0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+cHJvdmlkZXMg WUFORyBtb2RlbCBleHRlbnNpb25zIHRvIGxldmVyYWdlIEhUVFAvMiBzbyB0aGF0IGluZGl2aWR1 YWwgc3Vic2NyaXB0aW9ucyBjYW4gZ2V0IGN1c3RvbSB0cmVhdG1lbnQgdmlhIHRoZWlyIG93biBI VFRQIHN0cmVhbXMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB5 b3VyIGludGVyZXN0LCBhbmQgd2UgbG9vayBmb3J3YXJkIHRvIHRoZSBkaXNjdXNzaW9ucyE8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBBbGV4YW5kZXIgQ2xlbW0sIEVyaWMgVm9pdCwgQWxiZXJ0 byBHb256YWxleiBQcmlldG8sIEFtYmlrYSBQcmFzYWQgVHJpcGF0aHksICZhbXA7IEVpbmFyIE5p bHNlbi1OeWdhYXJkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FA8545464B9648DE81EA3F490A6F95EDjunipernet_-- From nobody Tue Oct 27 12:33: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 2B78C1ACE6D for ; Tue, 27 Oct 2015 12:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjaaRlGkuTra for ; Tue, 27 Oct 2015 12:33:19 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 1C1101ACE89 for ; Tue, 27 Oct 2015 12:33:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id t9RJXDXR009292 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Oct 2015 19:33:13 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t9RJXDvU015560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Oct 2015 20:33:13 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 27 Oct 2015 20:33:13 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.30]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 20:33:13 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: EXT Kent Watsen , Susan Hares , "'Eric Voit (evoit)'" , "netconf@ietf.org" Thread-Topic: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuxvOA7SwAHLssW9AMBuPuyAKtwvoA///Fb4D//7o4IA== Date: Tue, 27 Oct 2015 19:33:12 +0000 Message-ID: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.111] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8198191C4DEMUMBX005nsnin_" 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: 20368 X-purgate-ID: 151667::1445974393-00005272-99948DAF/0/0 Archived-At: Cc: 'Alia Atlas' Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 19:33:23 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8198191C4DEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlcmUgYXJlIHR3byBkcmFmdHMgdGhleSBuZWVkIHRvIGJlIGZpbmFsaXplZCBhbmQgZ28g dG8gV0dMQyB0b2dldGhlci4NCkFzIHN1Y2ggdGhlIHF1ZXN0aW9uIGlzIHZhbGlkLg0KDQpXaGF0 IGlzIHRoZSBvdmVybGFwcGluZyBwYXJ0Pw0KRG8gd2UgbmVlZCAyIGRyYWZ0cz8NCg0KTWVobWV0 DQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBFWFQgS2VudCBXYXRzZW4NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjcsIDIwMTUg ODoyMiBQTQ0KVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+OyAnRXJpYyBWb2l0IChl dm9pdCknIDxldm9pdEBjaXNjby5jb20+OyBuZXRjb25mQGlldGYub3JnDQpDYzogJ0FsaWEgQXRs YXMnIDxha2F0bGFzQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gTmV3IFlBTkcg UHViU3ViIGRyYWZ0cyBmb3IgTkVUQ09ORiwgUkVTVENPTkYsIEhUVFAvMg0KDQoNCkkgdGhpbmsg aXQgaW1wb3J0YW50IHRoYXQgd2hhdGV2ZXIgd2UgZG8gaW4gTkVUQ09ORiB3ZSBjYW4gYWxzbyBk byBpbiBSRVNUQ09ORi4gICBUbyB0aGF0IGVuZCwgSSBzdXBwb3J0IHRoZSBXRyBkZWZpbmluZyAi eWFuZy1wdXNo4oCdIGZvciBib3RoIHByb3RvY29scy4NCg0KQWN0dWFsbHksIEnigJltIGEgbGl0 dGxlIHN1cnByaXNlZCB0aGF0IHdl4oCZcmUgZGlzY3Vzc2luZyB0aGlzLiAgTWF5YmUgaXTigJlz IGp1c3QgbWUsIGJ1dCB3aGVuIHRoZSBXRyBhZG9wdGVkIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5n LXB1c2gsIEkgdGhvdWdodCB0aGF0IGl0IHdvdWxkIGNvdmVyIGJvdGggcHJvdG9jb2xzIGV2ZW50 dWFsbHkuICAgUGVyaGFwcyB0aGF0IGEgc2VwYXJhdGUgZHJhZnQgaGFzIGJlZW4gcHJvZHVjZWQg aXMgYW5vdGhlciBzdXJwcmlzZSBoZXJlIC0gZG8gd2UgcmVhbGx5IG5lZWQgYW5vdGhlciBkcmFm dD8NCg0KS2VudA0KDQpGcm9tOiBOZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8 c2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+Pg0KRGF0ZTogVHVlc2RheSwg T2N0b2JlciAyNywgMjAxNSBhdCAyOjUyIFBNDQpUbzogIidFcmljIFZvaXQgKGV2b2l0KSciIDxl dm9pdEBjaXNjby5jb208bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+LCAibmV0Y29uZkBpZXRmLm9y ZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4iIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRj b25mQGlldGYub3JnPj4NCkNjOiAnQWxpYSBBdGxhcycgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0 bzpha2F0bGFzQGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIE5ldyBZQU5HIFB1 YlN1YiBkcmFmdHMgZm9yIE5FVENPTkYsIFJFU1RDT05GLCBIVFRQLzINCg0KTkVUQ09ORjoNCg0K VGhlc2UgZHJhZnRzIGlzIGltcG9ydGFudCB0byB0aGUgSTJSUyBwdWIvc3ViLiAgIElzIHRoZSBS RVNUQ09ORiBkcmFmdCBnb2luZyB0byBiZSBhZG9wdGVkIChkcmFmdC12b2l0LXJlc3Rjb25mLXlh bmctcHVzaC0wMC50eHQpPw0KDQpJdCB3b3VsZCBiZSByZWFsbHkgaGVscGZ1bC4NCg0KU3VlIEhh cmVzDQpJMlJTIFdHIGNoYWlyDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFZvaXQgKGV2b2l0KQ0KU2VudDogVHVlc2Rh eSwgT2N0b2JlciAxMywgMjAxNSAxMTozNyBQTQ0KVG86IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRv Om5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTmV0Y29uZl0gTmV3IFlBTkcgUHViU3ViIGRy YWZ0cyBmb3IgTkVUQ09ORiwgUkVTVENPTkYsIEhUVFAvMg0KDQpUaGVyZSBhcmUgYSBjb3VwbGUg bmV3IGRyYWZ0cyBwb3N0ZWQgaW4gTkVUQ09ORjoNCg0KKDEpICBTdWJzY3JpYmluZyB0byBZQU5H IGRhdGFzdG9yZSBwdXNoIHVwZGF0ZXMNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtY2xl bW0tbmV0Y29uZi15YW5nLXB1c2gtMDIudHh0DQpBcyBwZXIgZWFybGllciBORVRDT05GIGRpc2N1 c3Npb25zPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJl bnQvbXNnMTA0MzIuaHRtbD4gd2UgYXJlIGV4cGVjdGluZyB0aGlzIGRyYWZ0IHRvIGJlY29tZSBk cmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoIGluIHRoZSBjb21pbmcgZGF5cyAob25jZSB0aGUg TkVUQ09ORiBjaGFydGVyIGlzIGFwcHJvdmVkKS4gIExvb2sgZm9yIGFuIE9wZW5EYXlsaWdodCBj bGllbnQgaW4gdGhlIEJlcnlsbGl1bSByZWxlYXNlIChGZWIpLg0KDQooMikgUmVzdGNvbmYgc3Vi c2NyaXB0aW9uIGFuZCBIVFRQIHB1c2ggZm9yIFlBTkcgZGF0YXN0b3Jlcw0KaHR0cDovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC12b2l0LXJlc3Rjb25mLXlhbmctcHVzaC0wMC50eHQNCkV4dGVuZHMg ZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2ggaW4gdGhlIGZvbGxvd2luZyB3YXlzOg0KDQrC tyAgICAgcHJvcG9zZXMgUmVzdGNvbmYgc3Vic2NyaXB0aW9uIGFuZCBwdXNoIG1lY2hhbmlzbXMg dG8gY29udGludW91c2x5IHN0cmVhbSBpbmZvcm1hdGlvbiBmcm9tIFlBTkcgZGF0YXN0b3JlcyBv dmVyIEhUVFANCg0KwrcgICAgIHByb3ZpZGVzIGEgbWVjaGFuaXNtIHRvIHN1cHBvcnQgc3RhdGlj IHN1YnNjcmlwdGlvbnMgc28gdGhhdCBhbiBvcGVyYXRvciBjYW4gc3RyZWFtIHVwZGF0ZXMgb3Zl ciBIVFRQIHdpdGhvdXQgUmVzdGNvbmYNCg0KwrcgICAgIHByb3ZpZGVzIFlBTkcgbW9kZWwgZXh0 ZW5zaW9ucyB0byBsZXZlcmFnZSBIVFRQLzIgc28gdGhhdCBpbmRpdmlkdWFsIHN1YnNjcmlwdGlv bnMgY2FuIGdldCBjdXN0b20gdHJlYXRtZW50IHZpYSB0aGVpciBvd24gSFRUUCBzdHJlYW1zLg0K DQpUaGFua3MgZm9yIHlvdXIgaW50ZXJlc3QsIGFuZCB3ZSBsb29rIGZvcndhcmQgdG8gdGhlIGRp c2N1c3Npb25zIQ0KDQotIEFsZXhhbmRlciBDbGVtbSwgRXJpYyBWb2l0LCBBbGJlcnRvIEdvbnph bGV6IFByaWV0bywgQW1iaWthIFByYXNhZCBUcmlwYXRoeSwgJiBFaW5hciBOaWxzZW4tTnlnYWFy ZA0KDQoNCg0KDQo= --_000_E4DE949E6CE3E34993A2FF8AE79131F8198191C4DEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMDA5OTsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDk5Ij5JZiB0aGVyZSBhcmUg dHdvIGRyYWZ0cyB0aGV5IG5lZWQgdG8gYmUgZmluYWxpemVkIGFuZCBnbyB0byBXR0xDIHRvZ2V0 aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAwMDk5Ij5BcyBzdWNoIHRoZSBxdWVzdGlvbiBpcyB2YWxpZC4gPG86cD4N CjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMDA5OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwOTkiPldoYXQgaXMgdGhlIG92ZXJsYXBwaW5n IHBhcnQ/IDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDAwOTkiPkRvIHdlIG5lZWQgMiBkcmFmdHM/IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAw MDk5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPk1laG1ldCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YNCjwvYj5FWFQgS2VudCBXYXRzZW48YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgT2N0b2JlciAyNywgMjAxNSA4OjIyIFBNPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJl cyAmbHQ7c2hhcmVzQG5kemguY29tJmd0OzsgJ0VyaWMgVm9pdCAoZXZvaXQpJyAmbHQ7ZXZvaXRA Y2lzY28uY29tJmd0OzsgbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gJ0FsaWEgQXRs YXMnICZsdDtha2F0bGFzQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtO ZXRjb25mXSBOZXcgWUFORyBQdWJTdWIgZHJhZnRzIGZvciBORVRDT05GLCBSRVNUQ09ORiwgSFRU UC8yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SSB0aGluayBpdCBpbXBvcnRh bnQgdGhhdCB3aGF0ZXZlciB3ZSBkbyBpbiBORVRDT05GIHdlIGNhbiBhbHNvIGRvIGluIFJFU1RD T05GLiAmbmJzcDsgVG8gdGhhdCBlbmQsIEkgc3VwcG9ydCB0aGUgV0cgZGVmaW5pbmcgJnF1b3Q7 eWFuZy1wdXNo4oCdIGZvciBib3RoIHByb3RvY29scy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPkFjdHVhbGx5LCBJ4oCZbSBhIGxpdHRsZSBzdXJwcmlzZWQgdGhhdCB3 ZeKAmXJlIGRpc2N1c3NpbmcgdGhpcy4gJm5ic3A7TWF5YmUgaXTigJlzIGp1c3QgbWUsIGJ1dCB3 aGVuIHRoZSBXRyBhZG9wdGVkIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gsIEkgdGhvdWdo dCB0aGF0IGl0IHdvdWxkIGNvdmVyIGJvdGggcHJvdG9jb2xzIGV2ZW50dWFsbHkuDQogJm5ic3A7 IFBlcmhhcHMgdGhhdCBhIHNlcGFyYXRlIGRyYWZ0IGhhcyBiZWVuIHByb2R1Y2VkIGlzIGFub3Ro ZXIgc3VycHJpc2UgaGVyZSAtIGRvIHdlIHJlYWxseSBuZWVkIGFub3RoZXIgZHJhZnQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5LZW50PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5OZXRjb25mICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBi ZWhhbGYgb2YgU3VzYW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20i PnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIE9jdG9i ZXIgMjcsIDIwMTUgYXQgMjo1MiBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7J0VyaWMgVm9pdCAo ZXZvaXQpJyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+ZXZvaXRA Y2lzY28uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3Jn Ij5uZXRjb25mQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZA aWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+J0FsaWEg QXRsYXMnICZsdDs8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iPmFrYXRsYXNAZ21h aWwuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtOZXRjb25mXSBOZXcgWUFO RyBQdWJTdWIgZHJhZnRzIGZvciBORVRDT05GLCBSRVNUQ09ORiwgSFRUUC8yPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5ORVRDT05GOiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlRoZXNlIGRyYWZ0cyBpcyBpbXBvcnRhbnQgdG8gdGhlIEkyUlMgcHViL3N1 Yi4gJm5ic3A7Jm5ic3A7SXMgdGhlIFJFU1RDT05GIGRyYWZ0IGdvaW5nIHRvIGJlIGFkb3B0ZWQg KGRyYWZ0LXZvaXQtcmVzdGNvbmYteWFuZy1wdXNoLTAwLnR4dCk/DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IHdvdWxkIGJlIHJlYWxseSBoZWxwZnVs LiZuYnNwOyA8L3NwYW4+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ U3VlIEhhcmVzIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5JMlJTIFdHIGNoYWlyIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IE5ldGNvbmYgWzxhIGhyZWY9Im1haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFZvaXQgKGV2b2l0KTxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDEzLCAyMDE1IDExOjM3IFBNPGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW05ldGNvbmZdIE5ldyBZQU5HIFB1YlN1YiBkcmFmdHMgZm9yIE5F VENPTkYsIFJFU1RDT05GLCBIVFRQLzI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZXJlIGFy ZSBhIGNvdXBsZSBuZXcgZHJhZnRzIHBvc3RlZCBpbiBORVRDT05GOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4oMSkmbmJzcDsgU3Vic2NyaWJpbmcgdG8gWUFORyBkYXRhc3RvcmUg cHVzaCB1cGRhdGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LWNsZW1tLW5ldGNvbmYteWFuZy1wdXNoLTAyLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaC0wMi50eHQ8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDo2LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0Ojku MzVwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5B cyBwZXIgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNv bmYvY3VycmVudC9tc2cxMDQzMi5odG1sIj4NCmVhcmxpZXIgTkVUQ09ORiBkaXNjdXNzaW9uczwv YT4gd2UgYXJlIGV4cGVjdGluZyB0aGlzIGRyYWZ0IHRvIGJlY29tZSBkcmFmdC1pZXRmLW5ldGNv bmYteWFuZy1wdXNoIGluIHRoZSBjb21pbmcgZGF5cyAob25jZSB0aGUgTkVUQ09ORiBjaGFydGVy IGlzIGFwcHJvdmVkKS4mbmJzcDsgTG9vayBmb3IgYW4gT3BlbkRheWxpZ2h0IGNsaWVudCBpbiB0 aGUgQmVyeWxsaXVtIHJlbGVhc2UgKEZlYikuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+KDIpIFJlc3Rjb25mIHN1YnNjcmlwdGlvbiBhbmQgSFRUUCBwdXNoIGZvciBZ QU5HIGRhdGFzdG9yZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtdm9pdC1yZXN0Y29uZi15YW5nLXB1c2gtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LXZvaXQtcmVzdGNvbmYteWFuZy1wdXNoLTAwLnR4dDwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OjYuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6 OS4zNXB0O21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkV4dGVuZHMgZHJhZnQtY2xlbW0tbmV0Y29uZi15YW5nLXB1c2ggaW4gdGhlIGZvbGxvd2luZyB3 YXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzEuNXB0O3RleHQtaW5kZW50Oi0xMy41cHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ cHJvcG9zZXMgUmVzdGNvbmYgc3Vic2NyaXB0aW9uIGFuZCBwdXNoIG1lY2hhbmlzbXMgdG8gY29u dGludW91c2x5IHN0cmVhbSBpbmZvcm1hdGlvbiBmcm9tIFlBTkcgZGF0YXN0b3JlcyBvdmVyIEhU VFANCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzEuNXB0O3RleHQtaW5kZW50Oi0xMy41cHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ cHJvdmlkZXMgYSBtZWNoYW5pc20gdG8gc3VwcG9ydCBzdGF0aWMgc3Vic2NyaXB0aW9ucyBzbyB0 aGF0IGFuIG9wZXJhdG9yIGNhbiBzdHJlYW0gdXBkYXRlcyBvdmVyIEhUVFAgd2l0aG91dCBSZXN0 Y29uZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzEuNXB0O3RleHQtaW5kZW50Oi0xMy41cHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ cHJvdmlkZXMgWUFORyBtb2RlbCBleHRlbnNpb25zIHRvIGxldmVyYWdlIEhUVFAvMiBzbyB0aGF0 IGluZGl2aWR1YWwgc3Vic2NyaXB0aW9ucyBjYW4gZ2V0IGN1c3RvbSB0cmVhdG1lbnQgdmlhIHRo ZWlyIG93biBIVFRQIHN0cmVhbXMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhhbmtzIGZvciB5b3VyIGludGVyZXN0LCBhbmQgd2UgbG9vayBmb3J3YXJkIHRvIHRo ZSBkaXNjdXNzaW9ucyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSBBbGV4YW5k ZXIgQ2xlbW0sIEVyaWMgVm9pdCwgQWxiZXJ0byBHb256YWxleiBQcmlldG8sIEFtYmlrYSBQcmFz YWQgVHJpcGF0aHksICZhbXA7IEVpbmFyIE5pbHNlbi1OeWdhYXJkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_E4DE949E6CE3E34993A2FF8AE79131F8198191C4DEMUMBX005nsnin_-- From nobody Tue Oct 27 12:50: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 5F0C81ACEB0 for ; Tue, 27 Oct 2015 12:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V_ONdBpOVHw for ; Tue, 27 Oct 2015 12:50:35 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 A4CDC1ACEA7 for ; Tue, 27 Oct 2015 12:50:33 -0700 (PDT) Received: by lffz202 with SMTP id z202so178211833lff.3 for ; Tue, 27 Oct 2015 12:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eqgeuCUmwnTWZRpPkE0g37MpcMMrTj5RBVbfOSzTM/0=; b=k2FiULhqf1+DuwjqMBbieG+HuErCsdmxa1ibOLmGv3VuQdkorb7FfsK/MQZn/HGlA3 YXHJEEC9y4OZAb4X1KUzV9Q2Y1Kc6GNZOc+heBKy/Nxqw/kgpN/GKK6ViyL/PF1HVO3y SxU657hTdsdksf8RmVeWlvvRLLHYoKx734duk7xsWrmr16o4W4kch4WqxP4xAP+WsfxP L8py3+qrRh5CdHVNJs4Aa1B+J9EXCRTpBxchPRdiqlb/9l3nDQR5e1fM+8ig4dqx3LDc FiLO92VmgbJbfDc1I1u4/80C+KwSccBUansVd/tarGfEOpDcjOkUyCqcp76fqhuaotNK Fung== 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=eqgeuCUmwnTWZRpPkE0g37MpcMMrTj5RBVbfOSzTM/0=; b=Iw4fz5u/25Q5OpEHLPrlvR91ilAl/sUL+qYnuJ+VGLJONGjQD7rnYtmWnTFb1ay574 dXolWR2Yz8PPjv2yRCNQNN3hrVF/kXVkamyu2X8d2EuLu/iG9SoCoVOsOb1D/aOS6XiE yf0C5Y8hNHnk8P8QmR+NAK6EhaHwI9DbcvdcZd6FYtbUsyY8v1NhntBzfhsZiNDUPn3q CQxyUM0kWyVrVxXGuqUclkuArluit3Ooq6OLiUU4iWj/SJtXRnMcrstmj5tTUxta8mk8 ViE2NmjNyEMn1ZbeB8d0P5Jzvo1xCwnEzZEfiowcg39gx7JpoTkmMfoTIF9WlTo/thY4 QVhg== X-Gm-Message-State: ALoCoQkYZ/htq7ekZdLJkBIZEt+flgHJbfDI+mqO4PxIgiK0byl61bmmf4Mvjf77Pk8GMOgouL8C MIME-Version: 1.0 X-Received: by 10.25.153.18 with SMTP id b18mr10310422lfe.33.1445975431796; Tue, 27 Oct 2015 12:50:31 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Tue, 27 Oct 2015 12:50:31 -0700 (PDT) In-Reply-To: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.com> Date: Tue, 27 Oct 2015 12:50:31 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a114730c0f77b0f05231b635e Archived-At: Cc: "netconf@ietf.org" , Alia Atlas Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 19:50:37 -0000 --001a114730c0f77b0f05231b635e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I support the feature in general as an optional addition to NETCONF or RESTCONF. I was looking at the details a bit, and I don't think it covers all YANG operations (such as insert, move, delete). I am implementing a datastore replication protocol based on deltas represented with YANG Patch. This looks much more efficient in practice than sending complete updates of resource representations to the client, especially for delete, insert, and move. You basically end up with PUT instead of PATCH, with all the inefficiencies that involves. I think the subscription and push control in the yang-push draft is great, but the messages on the wire should be more efficient. Andy On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen wrote: > > I think it important that whatever we do in NETCONF we can also do in > RESTCONF. To that end, I support the WG defining "yang-push=E2=80=9D fo= r both > protocols. > > Actually, I=E2=80=99m a little surprised that we=E2=80=99re discussing th= is. Maybe it=E2=80=99s > just me, but when the WG adopted draft-ietf-netconf-yang-push, I thought > that it would cover both protocols eventually. Perhaps that a separate > draft has been produced is another surprise here - do we really need > another draft? > > Kent > > From: Netconf on behalf of Susan Hares < > shares@ndzh.com> > Date: Tuesday, October 27, 2015 at 2:52 PM > To: "'Eric Voit (evoit)'" , "netconf@ietf.org" < > netconf@ietf.org> > Cc: 'Alia Atlas' > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, > HTTP/2 > > NETCONF: > > > > These drafts is important to the I2RS pub/sub. Is the RESTCONF draft > going to be adopted (draft-voit-restconf-yang-push-00.txt)? > > > > It would be really helpful. > > > > Sue Hares > > I2RS WG chair > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org > ] *On Behalf Of *Eric Voit (evoit) > *Sent:* Tuesday, October 13, 2015 11:37 PM > *To:* netconf@ietf.org > *Subject:* [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 > > > > There are a couple new drafts posted in NETCONF: > > > > (1) Subscribing to YANG datastore push updates > > http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt > > As per earlier NETCONF discussions > we > are expecting this draft to become draft-ietf-netconf-yang-push in the > coming days (once the NETCONF charter is approved). Look for an > OpenDaylight client in the Beryllium release (Feb). > > > > (2) Restconf subscription and HTTP push for YANG datastores > > http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt > > Extends draft-clemm-netconf-yang-push in the following ways: > > =C2=B7 proposes Restconf subscription and push mechanisms to continuo= usly > stream information from YANG datastores over HTTP > > =C2=B7 provides a mechanism to support static subscriptions so that a= n > operator can stream updates over HTTP without Restconf > > =C2=B7 provides YANG model extensions to leverage HTTP/2 so that > individual subscriptions can get custom treatment via their own HTTP > streams. > > > > Thanks for your interest, and we look forward to the discussions! > > > > - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad > Tripathy, & Einar Nilsen-Nygaard > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a114730c0f77b0f05231b635e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I support the feature in general as= an optional addition to NETCONF or RESTCONF.
I was looking at th= e details a bit, and I don't think it covers all YANG operations
<= div>(such as insert, move, delete).

I am implement= ing a datastore replication protocol based on deltas
represented = with YANG Patch.=C2=A0 This looks much more efficient in practice
than sending complete updates of resource representations to the client,
especially for delete, insert, and move.=C2=A0 You basically end u= p with PUT
instead of PATCH, with all the inefficiencies that inv= olves.

I think the subscription and push control i= n the yang-push draft is great,
but the messages on the wire shou= ld be more efficient.


Andy


= On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen <kwatsen@juniper.net&g= t; wrote:

I think it important that whatever we do in NETCONF we can also do in RESTC= ONF. =C2=A0 To that end, I support the WG defining "yang-push=E2=80=9D= for both protocols.

Actually, I=E2=80=99m a little surprised that we=E2=80=99re discussing this= .=C2=A0 Maybe it=E2=80=99s just me, but when the WG adopted draft-ietf-netc= onf-yang-push, I thought that it would cover both protocols eventually. =C2= =A0 Perhaps that a separate draft has been produced is another surprise here - do we really need another draft?

Kent

From: Netconf <netconf-bounces@ietf.org&g= t; on behalf of Susan Hares <shares@ndzh.com>
Date: Tuesday, October 27, 2015 at = 2:52 PM
To: "'Eric Voit (evoit)= 9;" <evoit@cis= co.com>, "netconf@ietf.org" <netconf@ietf.org>
Cc: 'Alia Atlas' <akatlas@gmail.com><= br> Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

NETCONF:

=C2=A0

These drafts is import= ant to the I2RS pub/sub. =C2=A0=C2=A0Is the RESTCONF draft going to be adop= ted (draft-voit-restconf-yang-push-00.txt)?

=C2=A0

It would be really hel= pful.=C2=A0

=C2=A0

Sue Hares

I2RS WG chair <= u>

=C2=A0

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: netconf@ie= tf.org
Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTT= P/2

=C2=A0

There are a couple new drafts posted in NETCONF:<= /u>

=C2=A0

(1)=C2=A0 Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-ne= tconf-yang-push-02.txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).=C2=A0 Look for an OpenDaylight client in the Beryllium release (Feb= ).=C2=A0

=C2=A0

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-res= tconf-yang-push-00.txt

Extends draft-clemm-netconf-yang-push in the following ways:<= /p>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0 proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0 provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0 provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams.=C2=A0

=C2=A0

Thanks for your interest, and we look forward to the= discussions!

=C2=A0

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

=C2=A0

=C2=A0

=C2=A0

=C2=A0

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


--001a114730c0f77b0f05231b635e-- From nobody Tue Oct 27 12:51: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 AC3CC1ACECC for ; Tue, 27 Oct 2015 12:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 B244iFLEw2P3 for ; Tue, 27 Oct 2015 12:51:27 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF941ACEA7 for ; Tue, 27 Oct 2015 12:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16629; q=dns/txt; s=iport; t=1445975486; x=1447185086; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vJGBm30QdFFfxcSSFBEq11ZIYiGIv4YOVsR5H1TnGoc=; b=FZ2tyQFJ5IpcumvBO2YkgHksaUoeXZkLfY67kuiDCElLr+fC2FiOx5Hp aywu/i0F1J6i2k0newuofYpbNfEsBM5itcR6QWknXgzBk8Wm18iEm+0Fq g0X+3LDfRLPsMa+c8fW0ugg8UTy3tCzgL3m/jVtQuNInJQfAVG2roJH7Y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AbAgBT1C9W/4ENJK1egmlNVG8GumKEIQENgVohhS9KAoFFOBQBAQEBAQEBgQqEMgEBAQQtQAwQAgEIDgMDAQEBDhoHIREUCQgBAQQBDQUJiBIDEg3BKQ2EQQEBAQEBAQEBAQEBAQEBAQEBAQEBARiLdYJQgWUGAQE/EQYBhC4FjVKFEYNVAYstgXaBWZMKg1+DbwEfAQFChARyAYQlCBcjgQYBAQE X-IronPort-AV: E=Sophos; i="5.20,206,1444694400"; d="scan'208,217"; a="41513002" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 27 Oct 2015 19:51:25 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t9RJpPKx001513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Oct 2015 19:51:25 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Oct 2015 14:51:01 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Tue, 27 Oct 2015 14:51:00 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Kent Watsen , Susan Hares , "Eric Voit (evoit)" , "netconf@ietf.org" Thread-Topic: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9wK4PTAAAAEP8oD//5K3gA== Date: Tue, 27 Oct 2015 19:51:00 +0000 Message-ID: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.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.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.156.48.200] Content-Type: multipart/alternative; boundary="_000_D2551E7D52612albertgociscocom_" MIME-Version: 1.0 Archived-At: Cc: 'Alia Atlas' Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 19:51:30 -0000 --_000_D2551E7D52612albertgociscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Kent, On 1 vs 2 drafts. I am open to discuss a merge of the two drafts, and I will be happy to list= en to the WG opinions and discuss them. To start the discussion, let me state some reasons why the authors tend to = prefer keeping them separate: 1. Keep modularity. If using a single document, would compliance requir= e supporting both netconf and restconf? This should not be the case, and i= t might become a hurdle for adoption. Also additional extensions are likely= (e.g., other transports and encoding), and keeping different flavors/exten= sion in different modules would facilitate that. Alternatively, should the = definition of extensions result in revisions of a common document? 2. Limit the complexity of docs. This may facilitate newcomers learning = the technology. Thanks, Alberto From: Netconf > o= n behalf of Kent Watsen > Date: Tuesday, October 27, 2015 at 12:22 PM To: Susan Hares >, "Eric Voit (evoi= t)" >, "netconf@ietf.org" > Cc: 'Alia Atlas' > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 I think it important that whatever we do in NETCONF we can also do in RESTC= ONF. To that end, I support the WG defining "yang-push" for both protocol= s. Actually, I'm a little surprised that we're discussing this. Maybe it's ju= st me, but when the WG adopted draft-ietf-netconf-yang-push, I thought that= it would cover both protocols eventually. Perhaps that a separate draft = has been produced is another surprise here - do we really need another draf= t? Kent From: Netconf > o= n behalf of Susan Hares > Date: Tuesday, October 27, 2015 at 2:52 PM To: "'Eric Voit (evoit)'" >, "netco= nf@ietf.org" > Cc: 'Alia Atlas' > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 NETCONF: These drafts is important to the I2RS pub/sub. Is the RESTCONF draft goin= g to be adopted (draft-voit-restconf-yang-push-00.txt)? It would be really helpful. Sue Hares I2RS WG chair From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Tuesday, October 13, 2015 11:37 PM To: netconf@ietf.org Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: =B7 proposes Restconf subscription and push mechanisms to continuously = stream information from YANG datastores over HTTP =B7 provides a mechanism to support static subscriptions so that an ope= rator can stream updates over HTTP without Restconf =B7 provides YANG model extensions to leverage HTTP/2 so that individua= l subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard --_000_D2551E7D52612albertgociscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6CCD66B93FFA7F44BBB099F2C5970556@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Kent,

On 1 vs 2 drafts.
I am open to discuss a merge of the two drafts, and I will be happy to= listen to the WG opinions and discuss them.
To start the discussion, let me state some reasons why the authors ten= d to prefer keeping them separate:
  1. Keep modularity.  If using a single document, would compliance req= uire supporting both netconf and restconf?  This should not be the cas= e, and it might become a hurdle for adoption. Also additional extensions ar= e likely (e.g., other transports and encoding), and keeping different flavors/extension in different modules would facilit= ate that. Alternatively, should the definition of extensions result in revi= sions of a common document?
  2. Limit the complexity of docs. This may = facilitate newcomers learning the technology.
Thanks,

Alberto


From: Netconf <netconf-bounces@ietf.org> on behalf of Ke= nt Watsen <kwatsen@juniper.net>
Date: Tuesday, October 27, 2015 at = 12:22 PM
To: Susan Hares <shares@ndzh.com>, "Eric Voit (evoit)" = <evoit@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
Cc: 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2


I think it important that whatever we do in NETCONF we can also do in RESTC= ONF.   To that end, I support the WG defining "yang-push” f= or both protocols.

Actually, I’m a little surprised that we’re discussing this. &n= bsp;Maybe it’s just me, but when the WG adopted draft-ietf-netconf-ya= ng-push, I thought that it would cover both protocols eventually.   Pe= rhaps that a separate draft has been produced is another surprise here - do we really need another draft?

Kent

From: Netconf <netconf-bounces@ietf.org> on behalf of Su= san Hares <shares@ndzh.com> Date: Tuesday, October 27, 2015 at = 2:52 PM
To: "'Eric Voit (evoit)'"= <evoit@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>
Cc: 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

NETCONF:

 

These drafts is import= ant to the I2RS pub/sub.   Is the RESTCONF draft going to be adop= ted (draft-voit-restconf-yang-push-00.txt)?

 

It would be really hel= pful. 

 

Sue Hares <= /span>

I2RS WG chair

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: netconf@ietf.org
Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTT= P/2

 

There are a couple new drafts posted in NETCONF:

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-netconf-yang-push-02= .txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-restconf-yang-push-00= .txt

Extends draft-clemm-netconf-yang-push in the following ways:

=B7     proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

=B7     provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

=B7     provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 

 --_000_D2551E7D52612albertgociscocom_-- From nobody Tue Oct 27 16:08: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 A85661B2CFA; Tue, 27 Oct 2015 16: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, 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 7G3qXRDB4Gmn; Tue, 27 Oct 2015 16:08:31 -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 166F91B2CF4; Tue, 27 Oct 2015 16:08:30 -0700 (PDT) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.306.13; Tue, 27 Oct 2015 23:08:29 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0306.003; Tue, 27 Oct 2015 23:08:29 +0000 From: Kent Watsen To: Kathleen Moriarty Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) Thread-Index: AQHRDAfgpOfZU3eYFEWbvakAFJEjNJ52KZiAgABYOoCAA1mSgIAF3qoAgAADmoA= Date: Tue, 27 Oct 2015 23:08:28 +0000 Message-ID: <87836B01-BF69-42FC-89F5-7786213358B8@juniper.net> References: <20151021135330.20048.35548.idtracker@ietfa.amsl.com> <4F2C1542-6FCB-4B67-91A8-7AD55BC34EB5@juniper.net> <93A12F18-FB21-4D08-B559-2E04295C5047@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:KqdKiSYaOqvuJC0tQeA8pjyb78jOHsLECM2T3GBuO6+O5K8YCsj2ypsNVdzUZlbYFUPtTV3MI92WuJjkxytTOuxifGWt2fbVmJHdt+tDGRpneXQa6Ful/UJAmsn3kZh3SK37SO2kwDBlbc96LBnTnA==; 24:nFMDB6WHmsZWbEM/zicH2GYPWxmId11VvJzVE7g+Rvfa/craCBLU+9tflLpfpQsT0QTM6sYY8a76uT8Yn4ordoSDYhjQRcReE/F/hQ5L8iQ=; 20:ZWSQ+Ur4oS7vl+lEMZPpQLK8E/Ia2v7uiL545DJcjbliNPkFOyu3T2BaKle4MjGQzWTweZqQgwOJBHnMl/O3Rg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(102215026); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0742443479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174004)(199003)(189002)(24454002)(164054003)(57704003)(83716003)(10400500002)(105586002)(40100003)(77096005)(76176999)(2900100001)(87936001)(101416001)(50986999)(83506001)(122556002)(99286002)(19580395003)(66066001)(106116001)(92566002)(82746002)(54356999)(2950100001)(19580405001)(230783001)(33656002)(4001350100001)(81156007)(5008740100001)(189998001)(5001960100002)(5002640100001)(5004730100002)(110136002)(97736004)(5007970100001)(86362001)(102836002)(106356001)(36756003)(93886004)(11100500001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <96FEA9674F6FC446BCF4C31AB6AB6AA6@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2015 23:08:28.7529 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netconf@ietf.org" , The IESG , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 27 Oct 2015 23:08:34 -0000 W3RvcC1wb3N0aW5nIGZvciBjb252ZW5pZW5jZV0NCg0KSGkgS2F0aGxlZW4sDQoNClJlZ2FyZGlu ZyAiVGhlIGFuYWx5c2lzIGZvciBORVRDT05GIGFuZCBSRVNUQ09ORiBpcyB1bmRlcndheS7igJ0s IEnigJltIGhhcHB5IHRvIGFkZCB0aGUgdGV4dCBidXQgd29uZGVyIHdoYXQgaXQgcmVmZXJzIHRv LiAgRG9lcyBpdCByZWZlciB0byB0aGlzIElFU0cgcmV2aWV3LCBvciB0aGUgcGVuZGluZyBkaXNj dXNzIHdpdGggdGhlIFRMUyBXRyBhbmQgb3BlbnNzaCBsaXN0LCBvciBzb21ldGhpbmcgZWxzZT8g ICBJZiBpdOKAmXMg4oCcc29tZXRoaW5nIGVsc2XigJ0sIHdlIG1heSBiZSBpbiB0cm91YmxlLCBh cyB0aGVyZSBpcyBub3RoaW5nIGVsc2UgSeKAmW0gYXdhcmUgb2YuLi4NCg0KVGhhbmtzLA0KS2Vu dA0KDQoNCg0KDQoNCg0KT24gMTAvMjcvMTUsIDI6NTUgUE0sICJLYXRobGVlbiBNb3JpYXJ0eSIg PGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KPkhpIEtlbnQsDQo+ DQo+UmVzcG9uc2VzIGluLWxpbmUuICBJIHRoaW5rIHdlIGFyZSBhYm91dCBnb29kLXRvLWdvIHdp dGggb25lDQo+Y29ycmVjdGlvbiBhbmQgc3VnZ2VzdGVkIHRleHQgZm9yIHRoZSBsYXN0IGl0ZW0u DQo+DQo+T24gU2F0LCBPY3QgMjQsIDIwMTUgYXQgMToxNyBBTSwgS2VudCBXYXRzZW4gPGt3YXRz ZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4NCj4+IEhpIEthdGhsZWVuLA0KPj4NCj4+DQo+Pg0K Pj4NCj4+Pj4+U2VjdGlvbiAyLjEgJiAzLjENCj4+Pj4+IFdoeSBpcyBhdXRoZW50aWNhdGlvbiBs aW1pdGVkIHRvIHNlcnZlci1zaWRlIGF1dGhlbnRpY2F0aW9uPyAgSXQgc2VlbXMNCj4+Pj4+IHRo YXQgdGhpcyByZWFsbHkgc2hvdWxkIGJlIG11dHVhbCBhdXRoZW50aWNhdGlvbiB0byBlbnN1cmUg dGhlIHNlcnZlciBpcw0KPj4+Pj4gYWxzbyBjb25uZWN0aW5nIHRvIHRoZSBjb3JyZWN0IGNsaWVu dCBhbmQgdGhlcmUgd2FzIG5vIGF0dGFjayBwcmlvciB0bw0KPj4+Pj4gdGhlIGNhbGxiYWNrLg0K Pj4+Pg0KPj4+Pg0KPj4+PiBCb3RoIE5FVENPTkYgYWQgUkVTVENPTkYgcmVxdWlyZSBjbGllbnQg YXV0aGVudGljYXRpb24sIGFuZCB0aGlzIGlzIGNhbGxlZCBvdXQgaW4gdGhlIEFwcGxpY2FiaWxp dHkgU3RhdGVtZW50IChTZWN0aW9uIDEuMykuICBBbHNvLCBpbiB0aGUgIlRoZSBORVRDT05GIG9y IFJFU1RDT05GIENsaWVudOKAnSBzZWN0aW9uLCBpdCBzYXlzOg0KPj4+Pg0KPj4+PiAgIEM3ICBB ZnRlciB0aGUgc2VydmVyJ3MgaG9zdCBrZXkgb3IgY2VydGlmaWNhdGUgaXMgdmFsaWRhdGVkLCB0 aGUgU1NIDQo+Pj4+ICAgb3IgVExTIHByb3RvY29sIHByb2NlZWRzIGFzIG5vcm1hbCB0byBlc3Rh Ymxpc2ggYSBTU0ggb3IgVExTDQo+Pj4+ICAgY29ubmVjdGlvbi4NCj4+Pj4NCj4+Pj4gVGhlIOKA nHByb2NlZWRzIGFzIG5vcm1hbOKAnSBpcyBpbnRlbmRlZCB0byBjb3ZlciBjbGllbnQgYXV0aGVu dGljYXRpb24uDQo+Pj4NCj4+Pk9rLCB0aGlzIHdhc24ndCBjbGVhciB0byBtZSwgYnV0IHByb2Jh Ymx5IGlzbid0IHRoZSBzZW50ZW5jZSB0byBmaXguDQo+Pg0KPj4NCj4+IEluIHRoZSBESVNDVVNT IHdpdGggU3RlcGhlbiwgSSBvZmZlcmVkIHRvIGFkZCB0aGUgZm9sbG93aW5nIHRleHQgdG8gdGhl IGVuZCBvZiBDNzoNCj4+DQo+PiAgIFdoZW4gcGVyZm9ybWluZyBjbGllbnQtYXV0aGVudGNhdGlv biB3aXRoIHRoZSBORVRDT05GL1JFU1RDT05GDQo+PiAgIHNlcnZlciwgdGhlIE5FVENPTkYvUkVT VENPTkYgY2xpZW50IE1VU1QgZW5zdXJlIHRvIG9ubHkgdXNlDQo+PiAgIGNyZWRlbnRpYWxzIHRo YXQgaGFkIHByZXZpb3VzbHkgYXNzb2NpYXRlZCBmb3IgdGhlIE5FVENPTkYvUkVTVENPTkYNCj4+ ICAgc2VydmVy4oCZcyBwcmVzZW50ZWQgaG9zdCBrZXkgb3Igc2VydmVyIGNlcnRpZmljYXRlLg0K Pj4NCj4+IEkga25vdyB5b3Ugc2FpZCB0aGlzIG1heSBub3QgYmUgdGhlIHNlbnRlbmNlIHRvIGZp eCwgYnV0IGRvZXMgaXQgcmVzb2x2ZSB0aGlzIGlzc3VlIGZvciB5b3U/DQo+Pg0KPg0KPlN1cmUs IHRoaXMgd29ya3Mgd2l0aCB0aGUgdXBkYXRlIHlvdSBhZ3JlZWQgdG8gYmVsb3cuDQo+DQo+Pg0K Pj4NCj4+DQo+Pg0KPj4NCj4+Pj4gQWxzbywgaW4gdGhlICJUaGUgTkVUQ09ORiBvciBSRVNUQ09O RiBTZXJ2ZXLigJ0gc2VjdGlvbiwgaXQgc2F5czoNCj4+Pj4NCj4+Pj4NCj4+Pj4gICBTNSAgSW4g bW9zdCBjYXNlcywgZXN0YWJsaXNoaW5nIHRoZSBTU0ggb3IgVExTIGNvbm5lY3Rpb24gYWxzbw0K Pj4+PiAgIGVudGFpbHMgc2VydmVyIGF1dGhlbnRpY2F0aW9uIG9mIGNsaWVudCBjcmVkZW50aWFs czsgb25seSB3aXRoDQo+Pj4+ICAgUkVTVENPTkYgZG8gc29tZSBjbGllbnQgYXV0aGVudGljYXRp b24gc2NoZW1lcyBvY2N1ciBhZnRlciB0aGUNCj4+Pj4gICBzZWN1cmUgdHJhbnNwb3J0IGNvbm5l Y3Rpb24gKFRMUykgaGFzIGJlZW4gZXN0YWJsaXNoZWQuDQo+Pj4NCj4+PkkgdGhpbmsgaWYgdGhp cyBzYWlkLCAiRXN0YWJsaXNoaW5nIGFuIFNTSCBvciBUTFMgc2Vzc2lvbiByZXF1aXJlcyBzZXJ2 ZXIgYXV0aGVudGljYXRpb24gb2YgY2xpZW50IGNyZWRlbnRpYWxzLCB3aXRoIHRoZSBleGNlcHRp b24gb2YuLi4iDQo+Pj4NCj4+PlRoZSBwb2ludCB3b3VsZCBiZSBtb3JlIGNsZWFyIGFzIEkgZGlk bid0IHJlYWxpemUgdGhpcyB3YXMgYWxyZWFkeSB0aGUgY2FzZSBmcm9tIHRoZSBsYW5ndWFnZSBp biB0aGlzIGRyYWZ0Lg0KPj4NCj4+IENvbnNpZGVyIGl0IGRvbmUuDQo+DQo+VGhhbmsgeW91IQ0K Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pj4+IElmDQo+Pj4+ICAgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIGlzIHJlcXVpcmVkLCBhbmQgdGhlIGNsaWVudCBpcyB1bmFibGUgdG8NCj4+Pj4gICBzdWNj ZXNzZnVsbHkgYXV0aGVudGljYXRlIGl0c2VsZiB0byB0aGUgc2VydmVyIGluIGFuIGFtb3VudCBv Zg0KPj4+PiAgIHRpbWUgZGVmaW5lZCBieSBsb2NhbCBwb2xpY3ksIHRoZSBzZXJ2ZXIgTVVTVCBj bG9zZSB0aGUNCj4+Pj4gICBjb25uZWN0aW9uLg0KPj4+Pg0KPj4+PiBXaGljaCBzcGVha3MgdG8g aXQgYXMgd2VsbC4NCj4+Pj4NCj4+Pj4NCj4+Pj4gRG8geW91IGJlbGlldmUgdGhlcmUgaXMgYSBu ZWVkIHRvIGNoYW5nZSB0aGUgdGV4dD8NCj4+Pg0KPj4+WWVzLCBidXQganVzdCB0aGUgdGV4dCB3 aGVyZSBJIG1hZGUgYSBzdWdnZXN0aW9ucyB1IGJlIGVub3VnaCB0byBnZXQgdGhlIHBvaW50IGFj cm9zcyBtb3JlIGNsZWFybHkuDQo+Pg0KPj4gU3VyZSwgSeKAmWxsIG1ha2UgdGhlIGZpeCBtZW50 aW9uZWQgYWJvdmUuDQo+Pg0KPg0KPlRoYW5rIHlvdSENCj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+PiAzLjEgUzMgLSBXaHkgaXMgY2xpZW50LXNpZGUgYXV0 aGVudGljYXRpb24gb3B0aW9uYWw/DQo+Pj4+Pg0KPj4+Pj4gV2l0aG91dCB0aGlzIG11c3QsIHRo ZXJlIHNob3VsZCBiZSBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gdGhhdCB0aGUgY2FsbA0KPj4+ Pj4gYmFjayBjb3VsZCBnbyB0byBhIG1hbGljaW91cyBjbGllbnQuICBUaGUgdHlwZXMgb2YgYXV0 aGVudGljYXRpb24gbWF0dGVyDQo+Pj4+PiBhcyB3ZWxsLCBidXQgdGhhdCdzIGNvdmVyZWQgaW4g U3RlcGhlbidzIGRpc2N1c3MgcG9pbnRzIGFsb25nIHdpdGggdGhlDQo+Pj4+PiBTZWNEaXIgcmV2 aWV3IHF1ZXN0aW9ucyBvbiBUTFMtUFNLLg0KPj4+Pg0KPj4+PiBEbyBtZWFuIFM1IHBhc3RlZCBh Ym92ZSB3aGVyZSBpdCBzYXlzIOKAnElmIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyByZXF1aXJl ZOKAnT8NCj4+Pg0KPj4+WWVzLg0KPj4NCj4+IE9MRDoNCj4+DQo+PiAgICBTNSAgSW4gbW9zdCBj YXNlcywgZXN0YWJsaXNoaW5nIHRoZSBTU0ggb3IgVExTIGNvbm5lY3Rpb24gYWxzbw0KPj4gICAg ICAgZW50YWlscyBzZXJ2ZXIgYXV0aGVudGljYXRpb24gb2YgY2xpZW50IGNyZWRlbnRpYWxzOyBv bmx5IHdpdGgNCj4+ICAgICAgIFJFU1RDT05GIGRvIHNvbWUgY2xpZW50IGF1dGhlbnRpY2F0aW9u IHNjaGVtZXMgb2NjdXIgYWZ0ZXIgdGhlDQo+PiAgICAgICBzZWN1cmUgdHJhbnNwb3J0IGNvbm5l Y3Rpb24gKFRMUykgaGFzIGJlZW4gZXN0YWJsaXNoZWQuICBJZg0KPj4gICAgICAgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGlzIHJlcXVpcmVkLCBhbmQgdGhlIGNsaWVudCBpcyB1bmFibGUgdG8NCj4+ ICAgICAgIHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBzZXJ2ZXIgaW4g YW4gYW1vdW50IG9mDQo+PiAgICAgICB0aW1lIGRlZmluZWQgYnkgbG9jYWwgcG9saWN5LCB0aGUg c2VydmVyIE1VU1QgY2xvc2UgdGhlDQo+PiAgICAgICBjb25uZWN0aW9uLg0KPj4NCj4+IE5FVzog ICBzL2NsaWVudC90cmFuc3BvcnQgKFNTSCBvciBUTFMpIGxldmVsIGNsaWVudC8NCj4+DQo+Pg0K Pj4gICAgUzUgSW4gbW9zdCBjYXNlcywgZXN0YWJsaXNoaW5nIHRoZSBTU0ggb3IgVExTIGNvbm5l Y3Rpb24gYWxzbw0KPj4gICAgICAgZW50YWlscyBzZXJ2ZXIgYXV0aGVudGljYXRpb24gb2YgY2xp ZW50IGNyZWRlbnRpYWxzOyBvbmx5IHdpdGgNCj4+ICAgICAgIFJFU1RDT05GIGRvIHNvbWUgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgb2NjdXIgYWZ0ZXIgdGhlDQo+PiAgICAgICBzZWN1 cmUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gKFRMUykgaGFzIGJlZW4gZXN0YWJsaXNoZWQuIElmDQo+ PiAgICAgICB0cmFuc3BvcnQgKFNTSCBvciBUTFMpIGxldmVsIGNsaWVudCBhdXRoZW50aWNhdGlv biBpcyByZXF1aXJlZCwgYW5kIHRoZSBjbGllbnQgaXMgdW5hYmxlIHRvDQo+PiAgICAgICBzdWNj ZXNzZnVsbHkgYXV0aGVudGljYXRlIGl0c2VsZiB0byB0aGUgc2VydmVyIGluIGFuIGFtb3VudCBv Zg0KPj4gICAgICAgdGltZSBkZWZpbmVkIGJ5IGxvY2FsIHBvbGljeSwgdGhlIHNlcnZlciBNVVNU IGNsb3NlIHRoZQ0KPj4gICAgICAgY29ubmVjdGlvbi4NCj4+DQo+Pg0KPj4gRG9lcyB0aGlzIHRl eHQgcmVzb2x2ZSB5b3VyIGlzc3VlPw0KPg0KPlRoaXMgd29ya3MgZm9yIG1lLCB0aGFua3MuDQo+ DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+Pj4NCj4+Pj4gVGhpcyB0ZXh0IGlzIHNwZWFraW5nIGFi b3V0IHRyYW5zcG9ydC1sZXZlbCBjbGllbnQtYXV0aC4gIE5FVENPTkYgb3ZlciBTU0ggb3Igb3Zl ciBUTFMgYm90aCBoYXZlIHRyYW5zcG9ydC1sZXZlbCBhdXRoZW50aWNhdGlvbiwgYnV0IFJFU1RD T05GIChlLmcuLCBIVFRQUykgYWxsb3dzIHRoZSBCYXNpYyBhbmQgRGlnZXN0IGF1dGhlbnRpY2F0 aW9uIG1vZGVzLCBhbmQgdGhhdCBjbGllbnQgYXV0aCBoYXBwZW4gYWZ0ZXIgdGhlIFRMUyBzZXNz aW9uIGlzIGVzdGFibGlzaGVkLg0KPj4+DQo+Pj5PaywgaXMgaXQgcG9zc2libGUgdG8gbWFrZSB0 aGlzIG1vcmUgY2xlYXI/ICBJIHRoaW5rIFN0ZXBoZW4gaGFzIGEgZGlzY3VzcyBvbiBIVFRQQXV0 aCBtZXRob2RzIGFscmVhZHksIHNvIHRoYXQgY2FuIGJlIGRpc2N1c3NlZCBpbiBoaXMgdGhyZWFk LiAgSSBqdXN0IGFzayB0aGF0IHlvdSBwb2ludCB0byB0aGUgbmV3bHkgdXBkYXRlZCBSRkNzIG9u IHRoZXNlIDIgc3RhbmRhcmRzIGFzIHRoZXkgZG8gYSBnb29kIGpvYiBvZiBvdXRsaW5pbmcgYWxs IG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgd2hpY2ggYXJlIHN1YnN0YW50aWFsLiAg UkZDNzYxNiAmIFJGQyA3NjE1DQo+Pg0KPj4gU3VyZSAgKGJ1dCBJ4oCZbGwgYXNzdW1lIHlvdSBt ZWFudCA3NjE3LCBpbnN0ZWFkIG9mIDc2MTYpDQo+DQo+QmFzaWMgaXMgaW4gUkZDNzYxNiBhbmQg ZGlnZXN0IGlzIGluIFJGQzc2MTcsIHNvIHlvdSBhcmUgcGFydGlhbGx5DQo+Y29ycmVjdCBhbmQg SSBoYWQgdGhlIGluY29ycmVjdCBudW1iZXIgaW4gbXkgbWVzc2FnZS4NCj4NCj4+DQo+Pg0KPj4N Cj4+DQo+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pj4gSW4gc2VjdGlvbiAxLjMsIHBs ZWFzZSBhZGQgYSBzZW50ZW5jZSB0aGF0IHBvaW50cyB0byB0aGUgdGhyZWF0L3NlY3VyaXR5DQo+ Pj4+PiBhbmFseXNpcyBmb3IgdXNlIG9mIHRoaXMgZnVuY3Rpb24gd2l0aCBORVRDT05GIGFuZCBS RVNUQ09ORiBhZnRlciB0aGUNCj4+Pj4+IGxhc3Qgc2VudGVuY2U6DQo+Pj4+Pg0KPj4+Pj4gIElu IHN1Y2ggY2lyY3Vtc3RhbmNlcywgYWxsb3dpbmcgdGhlIFNTSC9UTFMgc2VydmVyIHRvIGNvbnRh Y3QgdGhlDQo+Pj4+PiAgU1NIL1RMUyBjbGllbnQgd291bGQgb3BlbiBuZXcgdnVsbmVyYWJpbGl0 aWVzLiAgQW55IHVzZSBvZiBjYWxsIGhvbWUNCj4+Pj4+ICB3aXRoIFNTSC9UTFMgZm9yIHB1cnBv c2VzIG90aGVyIHRoYW4gTkVUQ09ORiBvciBSRVNUQ09ORiB3aWxsIG5lZWQgYQ0KPj4+Pj4gIHRo b3JvdWdoLCBjb250ZXh0dWFsIHNlY3VyaXR5IGFuYWx5c2lzLg0KPj4+Pg0KPj4+PiBVbmZvcnR1 bmF0ZWx5LCB0aGVyZSBpc24ndCBhbiBhbmFseXNpcyB0byBwb2ludCB0by4gIFRoZSDigJxhbmFs eXNpc+KAnSBpcyBoYXBwZW5pbmcgbm93IGFsb25nIHdpdGggdGhlIFNlY0RpciByZXZpZXcuICAg RG8gd2UgbmVlZCB0byBwZXJmb3JtIHN1Y2ggYW4gYW5hbHlzaXMgbm93Pw0KPj4+Pg0KPj4+VGhl IHNlY3Rpb24gcmVhZHMgYXMgaWYgb25lIGV4aXN0cyBhbmQgdGhhdCB5b3UndmUgbWl0aWdhdGVk IHRoZSByaXNrcy4gIEFzIHN1Y2gsIEknZCBleHBlY3QgdG8gc2VlIGFsbCBvZiB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgZm9yIHVzaW5nIHRoZSBtZXRob2QgZGVmaW5lZCBpbiB0aGlzIGRy YWZ0LiAgTWFraW5nIHRoZSBhdXRoIHJlcXVpcmVtZW50cyBtb3JlIGNsZWFyIHdpbGwgaGVscCBh bmQgcG9pbnRpbmcgb3V0IHRoZSB2dWxuZXJhYmlsaXR5IG9mIHRoZSBIVFRQQXV0aCBiYXNpYyBh bmQgZGlnZXN0IG1vZGVzIGZvciBSRVNUQ09ORiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgaXMgcGFydCBvZiB0aGF0Lg0KPj4+DQo+Pj5NZW50aW9uIG9mIHRoZSBwb3NzaWJpbGl0eSBv ZiBjb25uZWN0aW5nIHRvIGFuIGluY29ycmVjdCBjbGllbnQgKHBvc3NpYmx5IG1hbGljaW91cykg aW4gdGhlIGZldyBpbnN0YW5jZXMgd2hlcmUgY2xpZW50IGF1dGggaXNuJ3QgcmVxdWlyZWQgb3Ig aXMgd2VhayBpcyBpbXBvcnRhbnQgYXMgd2VsbCBmb3IgdGhlIHJlYWRlci4NCj4+DQo+Pg0KPj4g SG1tbSwgc28gSeKAmW0gbm90IHN1cmUgd2hhdCB0byBkbyB3aXRoIHRoaXMgY29tbWVudC4NCj4+ DQo+PiBZZXMsIHBlciBTdGVwaGVu4oCZcyBESVNDVVNTLCBtYWtlIHRoZSBhdXRoIHJlcXVpcmVt ZW50cyBtb3JlIGNsZWFyLCBhbmQgcG9pbnQgb3V0IHRoZSB2dWxuZXJhYmlsaXR5IG9mIHRoZSBI VFRQQXV0aCBiYXNpYyBhbmQgZGlnZXN0IG1vZGVzIGZvciBSRVNUQ09ORiBpbiB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgKHBlbmRpbmcgZmVlZGJhY2sgZnJvbSBUTFMgV0cgYW5kIG9wZW5z c2ggbGlzdCkuDQo+Pg0KPj4gQnV0IGJhY2sgdG8gU2VjdGlvbiAxLjMsIGlzIHRoZXJlIGEgc3Bl Y2lmaWMgY2hhbmdlIGluIHRoZSB0ZXh0IHRoYXQgeW914oCZcmUgaG9waW5nIHRvIHNlZSBoZXJl Pw0KPg0KPkhvdyBhYm91dCB0aGUgZm9sbG93aW5nOg0KPg0KPk9MRDoNCj4NCj4gICBUaGlzIGNv bnRyYXN0cyB3aXRoIHRoZSBiYXNlIFNTSCBhbmQgVExTIHByb3RvY29scywgd2hpY2ggZG8gbm90 DQo+ICAgcmVxdWlyZSBwcm9ncmFtbWF0aWMgdmVyaWZpY2F0aW9uIG9mIHRoZSBvdGhlciBwYXJ0 eSAoc2VjdGlvbiA5LjMuNA0KPiAgIG9mIFtSRkM0MjUxXSwgc2VjdGlvbiA0IG9mIFtSRkM0MjUy XSwgYW5kIHNlY3Rpb24gNy4zIG9mIFtSRkM1MjQ2XSkuDQo+ICAgSW4gc3VjaCBjaXJjdW1zdGFu Y2VzLCBhbGxvd2luZyB0aGUgU1NIL1RMUyBzZXJ2ZXIgdG8gY29udGFjdCB0aGUNCj4gICBTU0gv VExTIGNsaWVudCB3b3VsZCBvcGVuIG5ldyB2dWxuZXJhYmlsaXRpZXMuICBBbnkgdXNlIG9mIGNh bGwgaG9tZQ0KPiAgIHdpdGggU1NIL1RMUyBmb3IgcHVycG9zZXMgb3RoZXIgdGhhbiBORVRDT05G IG9yIFJFU1RDT05GIHdpbGwgbmVlZCBhDQo+ICAgdGhvcm91Z2gsIGNvbnRleHR1YWwgc2VjdXJp dHkgYW5hbHlzaXMuDQo+DQo+TkVXOg0KPg0KPiAgIFRoaXMgY29udHJhc3RzIHdpdGggdGhlIGJh c2UgU1NIIGFuZCBUTFMgcHJvdG9jb2xzLCB3aGljaCBkbyBub3QNCj4gICByZXF1aXJlIHByb2dy YW1tYXRpYyB2ZXJpZmljYXRpb24gb2YgdGhlIG90aGVyIHBhcnR5IChzZWN0aW9uIDkuMy40DQo+ ICAgb2YgW1JGQzQyNTFdLCBzZWN0aW9uIDQgb2YgW1JGQzQyNTJdLCBhbmQgc2VjdGlvbiA3LjMg b2YgW1JGQzUyNDZdKS4NCj4gICBJbiBzdWNoIGNpcmN1bXN0YW5jZXMsIGFsbG93aW5nIHRoZSBT U0gvVExTIHNlcnZlciB0byBjb250YWN0IHRoZQ0KPiAgIFNTSC9UTFMgY2xpZW50IHdvdWxkIG9w ZW4gbmV3IHZ1bG5lcmFiaWxpdGllcy4gIEFueSB1c2Ugb2YgY2FsbCBob21lDQo+ICAgd2l0aCBT U0gvVExTIG5lZWRzIGENCj4gICB0aG9yb3VnaCwgY29udGV4dHVhbCBzZWN1cml0eSBhbmFseXNp cy4gIFRoZSBhbmFseXNpcyBmb3IgTkVUQ09ORiBhbmQNCj4gICBSRVNUQ09ORiBpcyB1bmRlcndh eS4NCj4NCj5JIGRvbid0IHRoaW5rIHlvdSBoYXZlIGEgcmVmZXJlbmNlIHRvIGFkZCBmb3IgdGhp cywgY29ycmVjdD8gIElmIHlvdQ0KPmRvLCBJIHdvdWxkIHB1dCB0aGF0IGluIGFzIHdlbGwuDQo+ DQo+DQo+Pg0KPj4NCj4+DQo+PiBUaGFua3MsDQo+PiBLZW50DQo+Pg0KPj4NCj4+DQo+Pg0KPj4N Cj4NCj4NCj4NCj4tLSANCj4NCj5CZXN0IHJlZ2FyZHMsDQo+S2F0aGxlZW4NCg== From nobody Tue Oct 27 19:06: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 562851B3FD2; Tue, 27 Oct 2015 19:06:20 -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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHMg3iRXFP42; Tue, 27 Oct 2015 19:06:17 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 ABC561B3FD1; Tue, 27 Oct 2015 19:06:16 -0700 (PDT) Received: by qgad10 with SMTP id d10so161433046qga.3; Tue, 27 Oct 2015 19:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YMgMkK3Q3pJj3O8hgTiuVHud9nHWS02iwcEd/2mz7ZA=; b=nJQPSDRXAX4B3WqSSCLuVv1XiFe3qmdubROmfyS92Iy1ilKAHjx4mi6hC1wiFbefrS nGn8vYmDykDOJHuO1kxQREJS8gk/DGlDipu3O1CWLg17LOWSJ3xztbZl4fcwvFUbpF6Z zNka7BgGcgQR8+IpfBjkaw36vHkl8vNwEaSk6zBV/PG4pXUXsLUGmKOVhFpWdf50/GkK LmqA0crueDBFM2Ia5gWoA2rRVc1rEkDf4mMaAEQ+JNscx0/9/EVSfFNmCi8XCyQEximu 4E8+A8oVgqtziHlBKlk4mu+eS3sNGp6g++1fn+oDPBbNcGOj5CsWmbESeA4mdN/Yq54I Oi9Q== X-Received: by 10.140.216.135 with SMTP id m129mr56804259qhb.90.1445997975844; Tue, 27 Oct 2015 19:06:15 -0700 (PDT) Received: from [172.20.2.201] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id e204sm13561921qhc.19.2015.10.27.19.06.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Oct 2015 19:06:15 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <87836B01-BF69-42FC-89F5-7786213358B8@juniper.net> Date: Tue, 27 Oct 2015 22:06:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151021135330.20048.35548.idtracker@ietfa.amsl.com> <4F2C1542-6FCB-4B67-91A8-7AD55BC34EB5@juniper.net> <93A12F18-FB21-4D08-B559-2E04295C5047@juniper.net> <87836B01-BF69-42FC-89F5-7786213358B8@juniper.net> To: Kent Watsen Archived-At: Cc: "netconf@ietf.org" , The IESG , "draft-ietf-netconf-call-home@ietf.org" , "netconf-chairs@ietf.org" Subject: Re: [Netconf] Kathleen Moriarty's Discuss on draft-ietf-netconf-call-home-11: (with DISCUSS and COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2015 02:06:20 -0000 Sent from my iPhone > On Oct 27, 2015, at 7:08 PM, Kent Watsen wrote: >=20 > [top-posting for convenience] >=20 > Hi Kathleen, >=20 > Regarding "The analysis for NETCONF and RESTCONF is underway.=E2=80=9D, I=E2= =80=99m happy to add the text but wonder what it refers to. Does it refer t= o this IESG review, or the pending discuss with the TLS WG and openssh list,= or something else? If it=E2=80=99s =E2=80=9Csomething else=E2=80=9D, we m= ay be in trouble, as there is nothing else I=E2=80=99m aware of... >=20 I thought you said this was underway in Stephen's discuss. If not, please t= weak the text to say this has not been done and there are associated risks. = The current text reads as if RESTCONF and NETCONF are somehow exempt from t= he risks. Thanks, Kathleen=20 > Thanks, > Kent >=20 >=20 >=20 >=20 >=20 >=20 >> On 10/27/15, 2:55 PM, "Kathleen Moriarty" wrote: >>=20 >> Hi Kent, >>=20 >> Responses in-line. I think we are about good-to-go with one >> correction and suggested text for the last item. >>=20 >>> On Sat, Oct 24, 2015 at 1:17 AM, Kent Watsen wrote= : >>>=20 >>> Hi Kathleen, >>>=20 >>>=20 >>>=20 >>>=20 >>>>>> Section 2.1 & 3.1 >>>>>> Why is authentication limited to server-side authentication? It seem= s >>>>>> that this really should be mutual authentication to ensure the server= is >>>>>> also connecting to the correct client and there was no attack prior t= o >>>>>> the callback. >>>>>=20 >>>>>=20 >>>>> Both NETCONF ad RESTCONF require client authentication, and this is ca= lled out in the Applicability Statement (Section 1.3). Also, in the "The NE= TCONF or RESTCONF Client=E2=80=9D section, it says: >>>>>=20 >>>>> C7 After the server's host key or certificate is validated, the SSH >>>>> or TLS protocol proceeds as normal to establish a SSH or TLS >>>>> connection. >>>>>=20 >>>>> The =E2=80=9Cproceeds as normal=E2=80=9D is intended to cover client a= uthentication. >>>>=20 >>>> Ok, this wasn't clear to me, but probably isn't the sentence to fix. >>>=20 >>>=20 >>> In the DISCUSS with Stephen, I offered to add the following text to the e= nd of C7: >>>=20 >>> When performing client-authentcation with the NETCONF/RESTCONF >>> server, the NETCONF/RESTCONF client MUST ensure to only use >>> credentials that had previously associated for the NETCONF/RESTCONF >>> server=E2=80=99s presented host key or server certificate. >>>=20 >>> I know you said this may not be the sentence to fix, but does it resolve= this issue for you? >>=20 >> Sure, this works with the update you agreed to below. >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>> Also, in the "The NETCONF or RESTCONF Server=E2=80=9D section, it says= : >>>>>=20 >>>>>=20 >>>>> S5 In most cases, establishing the SSH or TLS connection also >>>>> entails server authentication of client credentials; only with >>>>> RESTCONF do some client authentication schemes occur after the >>>>> secure transport connection (TLS) has been established. >>>>=20 >>>> I think if this said, "Establishing an SSH or TLS session requires serv= er authentication of client credentials, with the exception of..." >>>>=20 >>>> The point would be more clear as I didn't realize this was already the c= ase from the language in this draft. >>>=20 >>> Consider it done. >>=20 >> Thank you! >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>> If >>>>> client authentication is required, and the client is unable to >>>>> successfully authenticate itself to the server in an amount of >>>>> time defined by local policy, the server MUST close the >>>>> connection. >>>>>=20 >>>>> Which speaks to it as well. >>>>>=20 >>>>>=20 >>>>> Do you believe there is a need to change the text? >>>>=20 >>>> Yes, but just the text where I made a suggestions u be enough to get th= e point across more clearly. >>>=20 >>> Sure, I=E2=80=99ll make the fix mentioned above. >>=20 >> Thank you! >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> 3.1 S3 - Why is client-side authentication optional? >>>>>>=20 >>>>>> Without this must, there should be a security consideration that the c= all >>>>>> back could go to a malicious client. The types of authentication mat= ter >>>>>> as well, but that's covered in Stephen's discuss points along with th= e >>>>>> SecDir review questions on TLS-PSK. >>>>>=20 >>>>> Do mean S5 pasted above where it says =E2=80=9CIf client authenticatio= n is required=E2=80=9D? >>>>=20 >>>> Yes. >>>=20 >>> OLD: >>>=20 >>> S5 In most cases, establishing the SSH or TLS connection also >>> entails server authentication of client credentials; only with >>> RESTCONF do some client authentication schemes occur after the >>> secure transport connection (TLS) has been established. If >>> client authentication is required, and the client is unable to >>> successfully authenticate itself to the server in an amount of >>> time defined by local policy, the server MUST close the >>> connection. >>>=20 >>> NEW: s/client/transport (SSH or TLS) level client/ >>>=20 >>>=20 >>> S5 In most cases, establishing the SSH or TLS connection also >>> entails server authentication of client credentials; only with >>> RESTCONF do some client authentication schemes occur after the >>> secure transport connection (TLS) has been established. If >>> transport (SSH or TLS) level client authentication is required, and= the client is unable to >>> successfully authenticate itself to the server in an amount of >>> time defined by local policy, the server MUST close the >>> connection. >>>=20 >>>=20 >>> Does this text resolve your issue? >>=20 >> This works for me, thanks. >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>>=20 >>>>> This text is speaking about transport-level client-auth. NETCONF over= SSH or over TLS both have transport-level authentication, but RESTCONF (e.g= ., HTTPS) allows the Basic and Digest authentication modes, and that client a= uth happen after the TLS session is established. >>>>=20 >>>> Ok, is it possible to make this more clear? I think Stephen has a disc= uss on HTTPAuth methods already, so that can be discussed in his thread. I j= ust ask that you point to the newly updated RFCs on these 2 standards as the= y do a good job of outlining all of the security considerations, which are s= ubstantial. RFC7616 & RFC 7615 >>>=20 >>> Sure (but I=E2=80=99ll assume you meant 7617, instead of 7616) >>=20 >> Basic is in RFC7616 and digest is in RFC7617, so you are partially >> correct and I had the incorrect number in my message. >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> In section 1.3, please add a sentence that points to the threat/secur= ity >>>>>> analysis for use of this function with NETCONF and RESTCONF after the= >>>>>> last sentence: >>>>>>=20 >>>>>> In such circumstances, allowing the SSH/TLS server to contact the >>>>>> SSH/TLS client would open new vulnerabilities. Any use of call home >>>>>> with SSH/TLS for purposes other than NETCONF or RESTCONF will need a >>>>>> thorough, contextual security analysis. >>>>>=20 >>>>> Unfortunately, there isn't an analysis to point to. The =E2=80=9Canal= ysis=E2=80=9D is happening now along with the SecDir review. Do we need to= perform such an analysis now? >>>> The section reads as if one exists and that you've mitigated the risks.= As such, I'd expect to see all of the security considerations for using th= e method defined in this draft. Making the auth requirements more clear wil= l help and pointing out the vulnerability of the HTTPAuth basic and digest m= odes for RESTCONF in the security considerations is part of that. >>>>=20 >>>> Mention of the possibility of connecting to an incorrect client (possib= ly malicious) in the few instances where client auth isn't required or is we= ak is important as well for the reader. >>>=20 >>>=20 >>> Hmmm, so I=E2=80=99m not sure what to do with this comment. >>>=20 >>> Yes, per Stephen=E2=80=99s DISCUSS, make the auth requirements more clea= r, and point out the vulnerability of the HTTPAuth basic and digest modes fo= r RESTCONF in the security considerations (pending feedback from TLS WG and o= penssh list). >>>=20 >>> But back to Section 1.3, is there a specific change in the text that you= =E2=80=99re hoping to see here? >>=20 >> How about the following: >>=20 >> OLD: >>=20 >> This contrasts with the base SSH and TLS protocols, which do not >> require programmatic verification of the other party (section 9.3.4 >> of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). >> In such circumstances, allowing the SSH/TLS server to contact the >> SSH/TLS client would open new vulnerabilities. Any use of call home >> with SSH/TLS for purposes other than NETCONF or RESTCONF will need a >> thorough, contextual security analysis. >>=20 >> NEW: >>=20 >> This contrasts with the base SSH and TLS protocols, which do not >> require programmatic verification of the other party (section 9.3.4 >> of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). >> In such circumstances, allowing the SSH/TLS server to contact the >> SSH/TLS client would open new vulnerabilities. Any use of call home >> with SSH/TLS needs a >> thorough, contextual security analysis. The analysis for NETCONF and >> RESTCONF is underway. >>=20 >> I don't think you have a reference to add for this, correct? If you >> do, I would put that in as well. >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> Thanks, >>> Kent >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen From nobody Wed Oct 28 02:17: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 B58B31B3714 for ; Wed, 28 Oct 2015 02:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 65RrBSUgagAH for ; Wed, 28 Oct 2015 02:17:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541AF1B3712 for ; Wed, 28 Oct 2015 02:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17812; q=dns/txt; s=iport; t=1446023844; x=1447233444; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X0YaYKeTYoEkAHefDODMc0G5pku1cew+1eOvuRAC6lE=; b=fBxM1nI50vSxcjqQ46qpZcroYPMI+JurdxMTnA6eRviEs2CglX3hM7xE U//A09XlhhVw7rFjqtM2iu+V6ATt9i4C8Nm6ScbE7f3MM3KbFY08DDJxr ANj78NAkBbR8/qkWNr57u/QOH/oEFLvi5fNysMxuJQrkstzPocBEPq8Ik U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D8AQCqkTBW/4cNJK1egmlNVG8GvwIBDYFaFwEJhTBKAoE5OBQBAQEBAQEBgQqENQEBAQQBAQFrCxACAQgRAwEBAQ4aByEGCxQJCAEBBAENBQmIEgMSDcBPDYRNAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIt1glOBawEBPw0EBgGELgWHR4YNhRGDWAGLLYF2gVmSCYEBg1+DbwEfAQFChARyAYQ8OoEGAQEB X-IronPort-AV: E=Sophos; i="5.20,209,1444694400"; d="scan'208,217"; a="41835269" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 28 Oct 2015 09:17:22 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t9S9HMYD032248 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2015 09:17:22 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 28 Oct 2015 04:16:57 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Wed, 28 Oct 2015 04:16:57 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Andy Bierman , Kent Watsen Thread-Topic: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9wK4PTAAAAEP8oAAAPqjgAANgmkA Date: Wed, 28 Oct 2015 09:16:57 +0000 Message-ID: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.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.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.161.219] Content-Type: multipart/alternative; boundary="_000_D255D6BE52759albertgociscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , Alia Atlas Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2015 09:17:28 -0000 --_000_D255D6BE52759albertgociscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the input Andy. In the NETCONF draft, for on-change updates, we consider the operations in = RFC6241 for edit-config, including merge, and delete. (when using json encoding, the changes are encoded based on yang-patch) Does that address the PUT/PATCH inefficiencies you mention? FWIW, we do not explicitly include yang:insert from RFC6020. It makes sense= to me including it since not using would lead to inefficiencies, as you co= rrectly point out. It also makes sense to me adding "move" to the list of operations in on-cha= nge updates. Thanks for bringing this up. For periodic updates, the updates contain a snapshot of the current state. = That is analogous to a PUT. The rationale was that to compute the deltas, w= e would need (a potentially sizable) per-subscription state. E.g., a subscription for fast-changing oper data subtrees with a large numb= er of descendants. Such data may not be versioned and its incremental delta= s may not be tracked. In such cases, the state to keep would be a replica o= f the snapshot used for the last update. Thanks, Alberto From: Netconf > o= n behalf of Andy Bierman > Date: Tuesday, October 27, 2015 at 12:50 PM To: Kent Watsen > Cc: "netconf@ietf.org" >, Alia Atlas > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Hi, I support the feature in general as an optional addition to NETCONF or REST= CONF. I was looking at the details a bit, and I don't think it covers all YANG op= erations (such as insert, move, delete). I am implementing a datastore replication protocol based on deltas represented with YANG Patch. This looks much more efficient in practice than sending complete updates of resource representations to the client, especially for delete, insert, and move. You basically end up with PUT instead of PATCH, with all the inefficiencies that involves. I think the subscription and push control in the yang-push draft is great, but the messages on the wire should be more efficient. Andy On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen > wrote: I think it important that whatever we do in NETCONF we can also do in RESTC= ONF. To that end, I support the WG defining "yang-push" for both protocol= s. Actually, I'm a little surprised that we're discussing this. Maybe it's ju= st me, but when the WG adopted draft-ietf-netconf-yang-push, I thought that= it would cover both protocols eventually. Perhaps that a separate draft = has been produced is another surprise here - do we really need another draf= t? Kent From: Netconf > o= n behalf of Susan Hares > Date: Tuesday, October 27, 2015 at 2:52 PM To: "'Eric Voit (evoit)'" >, "netco= nf@ietf.org" > Cc: 'Alia Atlas' > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 NETCONF: These drafts is important to the I2RS pub/sub. Is the RESTCONF draft goin= g to be adopted (draft-voit-restconf-yang-push-00.txt)? It would be really helpful. Sue Hares I2RS WG chair From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Tuesday, October 13, 2015 11:37 PM To: netconf@ietf.org Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: =B7 proposes Restconf subscription and push mechanisms to continuously = stream information from YANG datastores over HTTP =B7 provides a mechanism to support static subscriptions so that an ope= rator can stream updates over HTTP without Restconf =B7 provides YANG model extensions to leverage HTTP/2 so that individua= l subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_D255D6BE52759albertgociscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks for the input Andy.  

In the NETCONF draft, for on-change updates, we consider the operation= s in RFC6241 for edit-config, including merge, and delete.
(when using json encoding, the changes are encoded based on yang-patch= )
Does that address the PUT/PATCH inefficiencies you mention?

FWIW, we do not explicitly include yang:insert from RFC6020. It makes = sense to me including it since not using would lead to inefficiencies, as y= ou correctly point out.
It also makes sense to me adding “move” to the list of ope= rations in on-change updates.  Thanks for bringing this up.


For periodic updates, the updates contain a snapshot of the current st= ate. That is analogous to a PUT. The rationale was that to compute the delt= as, we would need (a potentially sizable) per-subscription state.
E.g., a subscription for fast-changing oper data subtrees with a large= number of descendants. Such data may not be versioned and its incremental = deltas may not be tracked. In such cases, the state to keep would be a repl= ica of the snapshot used for the last update.

Thanks,

Alberto


From: Netconf <netconf-bounces@ietf.org> on behalf of An= dy Bierman <andy@yumaworks.com= >
Date: Tuesday, October 27, 2015 at = 12:50 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>, Alia Atlas <akatlas@gmail.com>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

Hi,

I support the feature in general as an optional addition to NETCONF or= RESTCONF.
I was looking at the details a bit, and I don't think it covers all YA= NG operations
(such as insert, move, delete).

I am implementing a datastore replication protocol based on deltas
represented with YANG Patch.  This looks much more efficient in p= ractice
than sending complete updates of resource representations to the clien= t,
especially for delete, insert, and move.  You basically end up wi= th PUT
instead of PATCH, with all the inefficiencies that involves.

I think the subscription and push control in the yang-push draft is gr= eat,
but the messages on the wire should be more efficient.


Andy


On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen <kwatsen@junipe= r.net> wrote:

I think it important that whatever we do in NETCONF we can also do in RE= STCONF.   To that end, I support the WG defining "yang-push”= ; for both protocols.

Actually, I’m a little surprised that we’re discussing this.=   Maybe it’s just me, but when the WG adopted draft-ietf-netconf= -yang-push, I thought that it would cover both protocols eventually.   Perhaps that a separate draft has been produced is anot= her surprise here - do we really need another draft?

Kent

From: Netconf <netconf-bounces@ietf.org&g= t; on behalf of Susan Hares <shares@ndzh.com>
Date: Tuesday, October 27, 2015 at = 2:52 PM
To: "'Eric Voit (evoit)'"= <evoit@cisco.com>, "netconf= @ietf.org" <netconf@ietf.org>
Cc: 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

NETCONF:

 

These drafts is import= ant to the I2RS pub/sub.   Is the RESTCONF draft going to be adop= ted (draft-voit-restconf-yang-push-00.txt)?

 

It would be really hel= pful. 

 

Sue Hares

I2RS WG chair <= u>

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: netconf@ie= tf.org
Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTT= P/2

 

There are a couple new drafts posted in NETCONF:<= /u>

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-ne= tconf-yang-push-02.txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-res= tconf-yang-push-00.txt

Extends draft-clemm-netconf-yang-push in the following ways:<= /p>

=B7     proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

=B7     provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

=B7     provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 


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


--_000_D255D6BE52759albertgociscocom_-- From nobody Wed Oct 28 02:38: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 723891B375A for ; Wed, 28 Oct 2015 02:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 tvj1v_-dTSxO for ; Wed, 28 Oct 2015 02:38:30 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCB01B3761 for ; Wed, 28 Oct 2015 02:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21192; q=dns/txt; s=iport; t=1446025110; x=1447234710; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xb/gV6aVPiaTvaZjDby73GavrFyXDMiTurk3ckPZfLw=; b=Uis+XYCfIXKkVENi57fqxJA6UMjT6OgHAiQTRz2rTcSRw6JQ7VD2nzLY IzhoPewlgvtBHQKag2wlfWlYuaNwH6gRX+C/dIwhn8FHtX9cl8HRPk0qP H+sRCdnvplN+JxP5/YGB6+PfpRXOqFJ26xn1KMs3nNx0+mPa9QRniLikN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQAclzBW/4wNJK1egmlNVG8GumGEIQENgVohhTBKAoE7OBQBAQEBAQEBgQqENQEBAQQtQAwQAgEIEQMBAQEOGgchERQJCAEBBAENBQmIEgMSDcBDDYRNAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIt1glOBZQYBAT8RBgGELgWNVIURg1gBiy2BdoFZkwqDX4NvAR8BAUKEBHIBhDQIFyOBBgEBAQ X-IronPort-AV: E=Sophos; i="5.20,209,1444694400"; d="scan'208,217"; a="41706083" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 28 Oct 2015 09:38:28 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t9S9cSK8021226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2015 09:38:28 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 28 Oct 2015 04:38:04 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Wed, 28 Oct 2015 04:38:03 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: "Ersue, Mehmet (Nokia - DE/Munich)" , "EXT Kent Watsen" , Susan Hares , "Eric Voit (evoit)" , "netconf@ietf.org" Thread-Topic: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9wK4PTAAAAEP8oAAAF/QAAAO2eIA Date: Wed, 28 Oct 2015 09:38:03 +0000 Message-ID: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.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.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.161.219] Content-Type: multipart/alternative; boundary="_000_D255E2A1527C0albertgociscocom_" MIME-Version: 1.0 Archived-At: Cc: 'Alia Atlas' Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2015 09:38:34 -0000 --_000_D255E2A1527C0albertgociscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Mehmet, On the overlap. The idea is using the NETCONF draft as the base document an= d the RESTCONF one referring to it, so that the overlap is minimal. Exampl= es of this show in section III of the RESTCONF draft, and also in the augme= ntation of the base (NETCONF draft) model in the RESTCONF draft. On the 1 vs. 2 drafts, for your reference, I paste below my response to Ken= t's very same question Thanks, Alberto Thanks Kent, On 1 vs 2 drafts. I am open to discuss a merge of the two drafts, and I will be happy to list= en to the WG opinions and discuss them. To start the discussion, let me state some reasons why the authors tend to = prefer keeping them separate: 1. Keep modularity. If using a single document, would compliance requir= e supporting both netconf and restconf? This should not be the case, and i= t might become a hurdle for adoption. Also additional extensions are likely= (e.g., other transports and encoding), and keeping different flavors/exten= sion in different modules would facilitate that. Alternatively, should the = definition of extensions result in revisions of a common document? 2. Limit the complexity of docs. This may facilitate newcomers learning = the technology. Thanks, Alberto From: Netconf > o= n behalf of "Ersue, Mehmet (Nokia - DE/Munich)" > Date: Tuesday, October 27, 2015 at 12:33 PM To: EXT Kent Watsen >, Susa= n Hares >, "Eric Voit (evoit)" >, "netconf@ietf.org" > Cc: 'Alia Atlas' > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 If there are two drafts they need to be finalized and go to WGLC together. As such the question is valid. What is the overlapping part? Do we need 2 drafts? Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of EXT Kent Watse= n Sent: Tuesday, October 27, 2015 8:22 PM To: Susan Hares >; 'Eric Voit (evoi= t)' >; netconf@ietf.org Cc: 'Alia Atlas' > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 I think it important that whatever we do in NETCONF we can also do in RESTC= ONF. To that end, I support the WG defining "yang-push" for both protocol= s. Actually, I'm a little surprised that we're discussing this. Maybe it's ju= st me, but when the WG adopted draft-ietf-netconf-yang-push, I thought that= it would cover both protocols eventually. Perhaps that a separate draft = has been produced is another surprise here - do we really need another draf= t? Kent From: Netconf > o= n behalf of Susan Hares > Date: Tuesday, October 27, 2015 at 2:52 PM To: "'Eric Voit (evoit)'" >, "netco= nf@ietf.org" > Cc: 'Alia Atlas' > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 NETCONF: These drafts is important to the I2RS pub/sub. Is the RESTCONF draft goin= g to be adopted (draft-voit-restconf-yang-push-00.txt)? It would be really helpful. Sue Hares I2RS WG chair From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Tuesday, October 13, 2015 11:37 PM To: netconf@ietf.org Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: =B7 proposes Restconf subscription and push mechanisms to continuously = stream information from YANG datastores over HTTP =B7 provides a mechanism to support static subscriptions so that an ope= rator can stream updates over HTTP without Restconf =B7 provides YANG model extensions to leverage HTTP/2 so that individua= l subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard --_000_D255E2A1527C0albertgociscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <38B435ABBAB65E4AAB136C87D6630AEA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Mehmet,

On the overlap. The idea is using the NETCONF draft as the base docume= nt and the RESTCONF one referring to it,  so that the overlap is minim= al. Examples of this show in section III of the RESTCONF draft, and also in= the augmentation of the base (NETCONF draft) model in the RESTCONF draft. 
On the 1 vs. 2 drafts, for your reference, I paste below my response t= o Kent’s very same question

Thanks,

Alberto


Thanks Kent,

On 1 vs 2 drafts.
I am open to discuss a merge of the two drafts, and I will be happy to= listen to the WG opinions and discuss them.
To start the discussion, let me state some reasons why the authors ten= d to prefer keeping them separate:
  1. Keep modularity.  If using a single document, would compliance req= uire supporting both netconf and restconf?  This should not be the cas= e, and it might become a hurdle for adoption. Also additional extensions ar= e likely (e.g., other transports and encoding), and keeping different flavors/extension in different modules would facilit= ate that. Alternatively, should the definition of extensions result in revi= sions of a common document?
  2. Limit the complexity of docs. This may = facilitate newcomers learning the technology.
Thanks,

Alberto



From: Netconf <netconf-bounces@ietf.org> on behalf of &q= uot;Ersue, Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com>
Date: Tuesday, October 27, 2015 at = 12:33 PM
To: EXT Kent Watsen <kwatsen@juniper.net>, Susan Hares <shares@ndzh.com>, "Eric Voit (= evoit)" <evoit@cisco.com>= , "netconf@ietf.org" <<= a href=3D"mailto:netconf@ietf.org">netconf@ietf.org>
Cc: 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

If there are two draft= s they need to be finalized and go to WGLC together.

As such the question i= s valid.

 

What is the overlappin= g part?

Do we need 2 drafts? <= o:p>

 

Mehmet

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of EXT Kent Watsen
Sent: Tuesday, October 27, 2015 8:22 PM
To: Susan Hares <shares@ndzh.c= om>; 'Eric Voit (evoit)' <evoi= t@cisco.com>; netconf@ietf.org
Cc: 'Alia Atlas' <akatlas@gm= ail.com>
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF,= HTTP/2

 

&n= bsp;

I think= it important that whatever we do in NETCONF we can also do in RESTCONF. &n= bsp; To that end, I support the WG defining "yang-push” for both= protocols.

&n= bsp;

Actuall= y, I’m a little surprised that we’re discussing this.  May= be it’s just me, but when the WG adopted draft-ietf-netconf-yang-push= , I thought that it would cover both protocols eventually.   Perhaps that a separate draft has been produced is another surprise= here - do we really need another draft?

&n= bsp;

Kent

&n= bsp;

From: Netconf <netconf-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
Date: Tuesday, October 27, 2015 at 2:52 PM
To: "'Eric Voit (evoit)'" <evoit@cisco.com>, "n= etconf@ietf.org" <netconf@i= etf.org>
Cc: 'Alia Atlas' <akatlas@gm= ail.com>
Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF,= HTTP/2

&n= bsp;

NETCONF:

 

These drafts is import= ant to the I2RS pub/sub.   Is the RESTCONF draft going to be adop= ted (draft-voit-restconf-yang-push-00.txt)?

 

It would be really hel= pful. 

 

Sue Hares

I2RS WG chair <= span style=3D"color:black">

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: netconf@ietf.org
Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTT= P/2

 =

There are a couple new d= rafts posted in NETCONF:

 =

(1)  Subscribing to= YANG datastore push updates

http://www.ietf.org/id/draf= t-clemm-netconf-yang-push-02.txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 =

(2) Restconf subscriptio= n and HTTP push for YANG datastores

http://www.ietf.org/id/draf= t-voit-restconf-yang-push-00.txt

Extends draft-clemm-netconf-yang-push in the fo= llowing ways:

=B7    = ; proposes Restconf subscription and push = mechanisms to continuously stream information from YANG datastores over HTT= P

=B7    = ; provides a mechanism to support static s= ubscriptions so that an operator can stream updates over HTTP without Restc= onf

=B7    = ; provides YANG model extensions to levera= ge HTTP/2 so that individual subscriptions can get custom treatment via the= ir own HTTP streams. 

 =

Thanks for your interest= , and we look forward to the discussions!

 =

- Alexander Clemm, Eric = Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripathy, & Einar Nilsen-N= ygaard

 =

 =

 =

 =

--_000_D255E2A1527C0albertgociscocom_-- From nobody Wed Oct 28 12:03: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 C2C441ACD02 for ; Wed, 28 Oct 2015 12:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAmu-PNbm4Ac for ; Wed, 28 Oct 2015 12:03:46 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 C777C1ACCFD for ; Wed, 28 Oct 2015 12:03:45 -0700 (PDT) Received: by lfbn126 with SMTP id n126so8387751lfb.2 for ; Wed, 28 Oct 2015 12:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZaPbxk4XEh0Al+sQDZ23S95eAXKyRvl9LoGEYwL4J1c=; b=FAq5BxYuH0fSziw446+2rasuJEh0r9r3U39JQgjqDFRgD1Vrh9th+KRHgoMlKadcD5 3iPL2O3CX7ktUTTugSUY0cWY5tIn1ala2xb2jNbDDVmNYC6CDgcl2MYYSAm14jqXec6Q Lnj3dcO9L44wejYUfSVaMdlAjKsZRnIAeqOaP76I6+Dt1mN0koH+BT1g0IPhm0plYy9B KQyLqzpYgD+DFBl+LnzizQdsBt67oVzQ7X/vMvBVPOv36xsjyyYtgMjxZHYYfjeFJF// wi9eNpvGwB9Y24Ay+tVheRs+UjS8ZUbvHsEck0LGi0Twh744hwY3fZPsUZ1s91TiAc+F OqvQ== 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=ZaPbxk4XEh0Al+sQDZ23S95eAXKyRvl9LoGEYwL4J1c=; b=F4Kc6rKx/D09eVQnihNYn10/IIATMKSwElG3RTmuRaboC6VveBf1FZPlfFViyzL6Xv AUDb/wQhf+MK8rr3hqlfn8mU5e/W/EPm+SAsC/Erdb3IweT0+LVlf7LBeXCtZYmeAt9d f7CzPILu/ctt6oyixwfbQtAY8ReeGmt0gFkXGuGuGV1cnJ974C0LuyBo8GizXZXhK+85 TTEWpAhhewkPNpNnitLtk2YneFUKFti0sr1qpkis/t5Nu57FDLRTJi44JLxJ8Tc1JyBh iXuBSsp7BipzgFmxx1Uz7clnZIz8e7JmluwNWmie+0uxNGRF8Y0l2sfUKseVhx71oqaO K9zg== X-Gm-Message-State: ALoCoQl5eTjytFnS1FxVPcJlAO3FItoDq6FR+DbxQkkKvGM/pWX6Be/bQOVKdRv3X0QaFcuKJ+/r MIME-Version: 1.0 X-Received: by 10.25.143.82 with SMTP id r79mr8726201lfd.123.1446059023803; Wed, 28 Oct 2015 12:03:43 -0700 (PDT) Received: by 10.112.138.72 with HTTP; Wed, 28 Oct 2015 12:03:43 -0700 (PDT) In-Reply-To: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.com> Date: Wed, 28 Oct 2015 12:03:43 -0700 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a11401b1a70453a05232edaaf Archived-At: Cc: "netconf@ietf.org" , Alia Atlas Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2015 19:03:49 -0000 --001a11401b1a70453a05232edaaf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The issue wrt/ PUT vs. PATCH is really a matter of context and priorities. If you delete 1 interface out of 100,000, and you need to send the updated parent container, instead of just sending "delete interface X", the message could be 10,000 times bigger on-the-wire. The internal processing could be much higher (e.g., compare 99,999 interfaces to the saved values to determine there were no changes). If efficiency is of no concern, then updating the parent resource is probably OK. Andy On Wed, Oct 28, 2015 at 2:16 AM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Thanks for the input Andy. > > In the NETCONF draft, for on-change updates, we consider the operations > in RFC6241 for edit-config, including merge, and delete. > (when using json encoding, the changes are encoded based on yang-patch) > Does that address the PUT/PATCH inefficiencies you mention? > > FWIW, we do not explicitly include yang:insert from RFC6020. It makes > sense to me including it since not using would lead to inefficiencies, as > you correctly point out. > It also makes sense to me adding =E2=80=9Cmove=E2=80=9D to the list of op= erations in > on-change updates. Thanks for bringing this up. > > > For periodic updates, the updates contain a snapshot of the current state= . > That is analogous to a PUT. The rationale was that to compute the deltas, > we would need (a potentially sizable) per-subscription state. > E.g., a subscription for fast-changing oper data subtrees with a large > number of descendants. Such data may not be versioned and its incremental > deltas may not be tracked. In such cases, the state to keep would be a > replica of the snapshot used for the last update. > > Thanks, > > Alberto > > > From: Netconf on behalf of Andy Bierman < > andy@yumaworks.com> > Date: Tuesday, October 27, 2015 at 12:50 PM > To: Kent Watsen > Cc: "netconf@ietf.org" , Alia Atlas > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, > HTTP/2 > > Hi, > > I support the feature in general as an optional addition to NETCONF or > RESTCONF. > I was looking at the details a bit, and I don't think it covers all YANG > operations > (such as insert, move, delete). > > I am implementing a datastore replication protocol based on deltas > represented with YANG Patch. This looks much more efficient in practice > than sending complete updates of resource representations to the client, > especially for delete, insert, and move. You basically end up with PUT > instead of PATCH, with all the inefficiencies that involves. > > I think the subscription and push control in the yang-push draft is great= , > but the messages on the wire should be more efficient. > > > Andy > > > On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen wrote= : > >> >> I think it important that whatever we do in NETCONF we can also do in >> RESTCONF. To that end, I support the WG defining "yang-push=E2=80=9D f= or both >> protocols. >> >> Actually, I=E2=80=99m a little surprised that we=E2=80=99re discussing t= his. Maybe it=E2=80=99s >> just me, but when the WG adopted draft-ietf-netconf-yang-push, I thought >> that it would cover both protocols eventually. Perhaps that a separate >> draft has been produced is another surprise here - do we really need >> another draft? >> >> Kent >> >> From: Netconf on behalf of Susan Hares < >> shares@ndzh.com> >> Date: Tuesday, October 27, 2015 at 2:52 PM >> To: "'Eric Voit (evoit)'" , "netconf@ietf.org" < >> netconf@ietf.org> >> Cc: 'Alia Atlas' >> Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, >> HTTP/2 >> >> NETCONF: >> >> >> >> These drafts is important to the I2RS pub/sub. Is the RESTCONF draft >> going to be adopted (draft-voit-restconf-yang-push-00.txt)? >> >> >> >> It would be really helpful. >> >> >> >> Sue Hares >> >> I2RS WG chair >> >> >> >> *From:* Netconf [mailto:netconf-bounces@ietf.org >> ] *On Behalf Of *Eric Voit (evoit) >> *Sent:* Tuesday, October 13, 2015 11:37 PM >> *To:* netconf@ietf.org >> *Subject:* [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/= 2 >> >> >> >> There are a couple new drafts posted in NETCONF: >> >> >> >> (1) Subscribing to YANG datastore push updates >> >> http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt >> >> As per earlier NETCONF discussions >> we >> are expecting this draft to become draft-ietf-netconf-yang-push in the >> coming days (once the NETCONF charter is approved). Look for an >> OpenDaylight client in the Beryllium release (Feb). >> >> >> >> (2) Restconf subscription and HTTP push for YANG datastores >> >> http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt >> >> Extends draft-clemm-netconf-yang-push in the following ways: >> >> =C2=B7 proposes Restconf subscription and push mechanisms to continu= ously >> stream information from YANG datastores over HTTP >> >> =C2=B7 provides a mechanism to support static subscriptions so that = an >> operator can stream updates over HTTP without Restconf >> >> =C2=B7 provides YANG model extensions to leverage HTTP/2 so that >> individual subscriptions can get custom treatment via their own HTTP >> streams. >> >> >> >> Thanks for your interest, and we look forward to the discussions! >> >> >> >> - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad >> Tripathy, & Einar Nilsen-Nygaard >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > --001a11401b1a70453a05232edaaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The issue wrt/ PUT vs. PATCH is rea= lly a matter of context
and priorities.=C2=A0 If you delete 1 int= erface out of 100,000, and you
need to send the updated parent co= ntainer, instead of just
sending "delete interface X", = the message could be 10,000
times bigger on-the-wire.=C2=A0 The i= nternal processing could be much
higher (e.g., compare 99,999 int= erfaces to the saved values
to determine there were no changes).= =C2=A0 If efficiency is of
no concern, then updating the parent r= esource is probably OK.


Andy
<= div>




<= /div>

On Wed, Oct = 28, 2015 at 2:16 AM, Alberto Gonzalez Prieto (albertgo) &= lt;albertgo@cisco.c= om> wrote:
Thanks for the input Andy. =C2=A0

In the NETCONF draft, for on-change updates, we consider the operation= s in=C2=A0RFC6241 for edit-config, including merge, and delete.
(when using json encoding, the changes are encoded based on yang-patch= )
Does that address the PUT/PATCH inefficiencies you mention?

FWIW, we do not explicitly include yang:insert from RFC6020. It makes = sense to me including it since not using would lead to inefficiencies, as y= ou correctly point out.
It also makes sense to me adding =E2=80=9Cmove=E2=80=9D to the list of= operations in on-change updates.=C2=A0 Thanks for bringing this up.


For periodic updates, the updates contain a snapshot of the current st= ate. That is analogous to a PUT. The rationale was that to compute the delt= as, we would need (a potentially sizable) per-subscription state.
E.g., a subscription for fast-changing oper data subtrees with a large= number of descendants. Such data may not be versioned and its incremental = deltas may not be tracked. In such cases, the state to keep would be a repl= ica of the snapshot used for the last update.

Thanks,

Alberto


From: Netconf <netconf-bounces@ietf.org&g= t; on behalf of Andy Bierman <andy@yumaworks.com>
Date: Tuesday, October 27, 2015 at = 12:50 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>, Alia Atlas= <akatlas@gmail.c= om>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

Hi,

I support the feature in general as an optional addition to NETCONF or= RESTCONF.
I was looking at the details a bit, and I don't think it covers al= l YANG operations
(such as insert, move, delete).

I am implementing a datastore replication protocol based on deltas
represented with YANG Patch.=C2=A0 This looks much more efficient in p= ractice
than sending complete updates of resource representations to the clien= t,
especially for delete, insert, and move.=C2=A0 You basically end up wi= th PUT
instead of PATCH, with all the inefficiencies that involves.

I think the subscription and push control in the yang-push draft is gr= eat,
but the messages on the wire should be more efficient.


Andy


On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen <kwatsen@junipe= r.net> wrote:

I think it important that whatever we do in NETCONF we can also do in RE= STCONF. =C2=A0 To that end, I support the WG defining "yang-push=E2=80= =9D for both protocols.

Actually, I=E2=80=99m a little surprised that we=E2=80=99re discussing t= his.=C2=A0 Maybe it=E2=80=99s just me, but when the WG adopted draft-ietf-n= etconf-yang-push, I thought that it would cover both protocols eventually. =C2=A0 Perhaps that a separate draft has been produced is anot= her surprise here - do we really need another draft?

Kent

From: Netconf <netconf-bounces@ietf.org&g= t; on behalf of Susan Hares <shares@ndzh.com>
Date: Tuesday, October 27, 2015 at = 2:52 PM
To: "'Eric Voit (evoit)= 9;" <evoit@cis= co.com>, "netconf@ietf.org" <netconf@ietf.org>
Cc: 'Alia Atlas' <akatlas@gmail.com><= br> Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

NETCONF:

=C2=A0

These drafts is import= ant to the I2RS pub/sub. =C2=A0=C2=A0Is the RESTCONF draft going to be adop= ted (draft-voit-restconf-yang-push-00.txt)?

=C2=A0

It would be really hel= pful.=C2=A0

=C2=A0

Sue Hares

I2RS WG chair <= u>

=C2=A0

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: netconf@ie= tf.org
Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTT= P/2

=C2=A0

There are a couple new drafts posted in NETCONF:<= /u>

=C2=A0

(1)=C2=A0 Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-ne= tconf-yang-push-02.txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).=C2=A0 Look for an OpenDaylight client in the Beryllium release (Feb= ).=C2=A0

=C2=A0

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-res= tconf-yang-push-00.txt

Extends draft-clemm-netconf-yang-push in the following ways:<= /p>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0 proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0 provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0 provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams.=C2=A0

=C2=A0

Thanks for your interest, and we look forward to the= discussions!

=C2=A0

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

=C2=A0

=C2=A0

=C2=A0

=C2=A0


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



--001a11401b1a70453a05232edaaf-- From nobody Wed Oct 28 16:08: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 C4D7B1B5EC5 for ; Wed, 28 Oct 2015 16:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 GjL08huCTxZz for ; Wed, 28 Oct 2015 16:08:21 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0BC1B5EC0 for ; Wed, 28 Oct 2015 16:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23236; q=dns/txt; s=iport; t=1446073701; x=1447283301; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i1PHwDGcvF944+osHn6MkaElWHq5P+G93HDAUTs9XW8=; b=KztJst40JmNLfcV5s6hOBKPGLG2Q1OFUyKFUWQIqFYt49TxdkdlXmBV7 HOJEEGH2P50KI41kvT1KiuYXSRc055k+GFFc0Pr0V2ky2NLsN+VJyWNyQ KdCINMdnEBS1cxfaXJo/8/xXuHMfBXXntBPz/YRXnGkpwC1W/HBj4NzSX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQCqVDFW/4YNJK1egmlNVG8GvxkBDYFaFwEJhTBKAoEsOBQBAQEBAQEBgQqENQEBAQQBAQFrCxACAQgRAwEBAQ4aByEGCxQJCAIEDgUJiBIDEg3Aew2ETwEBAQEBAQEBAQEBAQEBAQEBAQEBARiLdYJTgWsBAS4RDQQGAQaEKAWHR4seg1gBiy2BdoFZkguBAYNfg28BHwEBQoQEcgGEPDqBBgEBAQ X-IronPort-AV: E=Sophos;i="5.20,212,1444694400"; d="scan'208,217";a="202341924" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2015 23:08:20 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t9SN8K3g024256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2015 23:08:20 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 28 Oct 2015 18:07:54 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1104.000; Wed, 28 Oct 2015 18:07:54 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Andy Bierman Thread-Topic: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Thread-Index: AdEGMYYuBt91fZS4QJ2ekMkkyW+o9wK4PTAAAAEP8oAAAPqjgAANgmkAACMlxYD//87+gA== Date: Wed, 28 Oct 2015 23:07:54 +0000 Message-ID: References: <203b7493c8b0494fa6c266cebe37381e@XCH-ALN-013.cisco.com> <047b01d110e8$92e3ba30$b8ab2e90$@ndzh.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.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.156.48.39] Content-Type: multipart/alternative; boundary="_000_D25691AF52A62albertgociscocom_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , Alia Atlas Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2015 23:08:25 -0000 --_000_D25691AF52A62albertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Andy, Agreed. For the example below, using a periodic subscription on the list of interfa= ces would result in ~100k entries. Alternatively, using an on-change subscription would result in a single ent= ry on the wire (I.e., just the config delta). How efficient the delta computation (on the publisher) would be is implemen= tation-specific. A publisher implementation has the option of not accepting/supporting on-ch= ange subscriptions. A reason for not accepting an on-change subscription is= a high computational cost for serving it. That is, there are trade-offs that publishers can control wrt computational= cost, space requirements, generated traffic. Thanks, Alberto From: Andy Bierman > Date: Wednesday, October 28, 2015 at 12:03 PM To: Alberto Gonzalez Prieto > Cc: Kent Watsen >, "netconf= @ietf.org" >, Alia Atlas > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Hi, The issue wrt/ PUT vs. PATCH is really a matter of context and priorities. If you delete 1 interface out of 100,000, and you need to send the updated parent container, instead of just sending "delete interface X", the message could be 10,000 times bigger on-the-wire. The internal processing could be much higher (e.g., compare 99,999 interfaces to the saved values to determine there were no changes). If efficiency is of no concern, then updating the parent resource is probably OK. Andy On Wed, Oct 28, 2015 at 2:16 AM, Alberto Gonzalez Prieto (albertgo) > wrote: Thanks for the input Andy. In the NETCONF draft, for on-change updates, we consider the operations in = RFC6241 for edit-config, including merge, and delete. (when using json encoding, the changes are encoded based on yang-patch) Does that address the PUT/PATCH inefficiencies you mention? FWIW, we do not explicitly include yang:insert from RFC6020. It makes sense= to me including it since not using would lead to inefficiencies, as you co= rrectly point out. It also makes sense to me adding =93move=94 to the list of operations in on= -change updates. Thanks for bringing this up. For periodic updates, the updates contain a snapshot of the current state. = That is analogous to a PUT. The rationale was that to compute the deltas, w= e would need (a potentially sizable) per-subscription state. E.g., a subscription for fast-changing oper data subtrees with a large numb= er of descendants. Such data may not be versioned and its incremental delta= s may not be tracked. In such cases, the state to keep would be a replica o= f the snapshot used for the last update. Thanks, Alberto From: Netconf > o= n behalf of Andy Bierman > Date: Tuesday, October 27, 2015 at 12:50 PM To: Kent Watsen > Cc: "netconf@ietf.org" >, Alia Atlas > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 Hi, I support the feature in general as an optional addition to NETCONF or REST= CONF. I was looking at the details a bit, and I don't think it covers all YANG op= erations (such as insert, move, delete). I am implementing a datastore replication protocol based on deltas represented with YANG Patch. This looks much more efficient in practice than sending complete updates of resource representations to the client, especially for delete, insert, and move. You basically end up with PUT instead of PATCH, with all the inefficiencies that involves. I think the subscription and push control in the yang-push draft is great, but the messages on the wire should be more efficient. Andy On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen > wrote: I think it important that whatever we do in NETCONF we can also do in RESTC= ONF. To that end, I support the WG defining "yang-push=94 for both protoc= ols. Actually, I=92m a little surprised that we=92re discussing this. Maybe it= =92s just me, but when the WG adopted draft-ietf-netconf-yang-push, I thoug= ht that it would cover both protocols eventually. Perhaps that a separate= draft has been produced is another surprise here - do we really need anoth= er draft? Kent From: Netconf > o= n behalf of Susan Hares > Date: Tuesday, October 27, 2015 at 2:52 PM To: "'Eric Voit (evoit)'" >, "netco= nf@ietf.org" > Cc: 'Alia Atlas' > Subject: Re: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 NETCONF: These drafts is important to the I2RS pub/sub. Is the RESTCONF draft goin= g to be adopted (draft-voit-restconf-yang-push-00.txt)? It would be really helpful. Sue Hares I2RS WG chair From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evo= it) Sent: Tuesday, October 13, 2015 11:37 PM To: netconf@ietf.org Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTTP/2 There are a couple new drafts posted in NETCONF: (1) Subscribing to YANG datastore push updates http://www.ietf.org/id/draft-clemm-netconf-yang-push-02.txt As per earlier NETCONF discussions we are expecting this draft to become draft-iet= f-netconf-yang-push in the coming days (once the NETCONF charter is approve= d). Look for an OpenDaylight client in the Beryllium release (Feb). (2) Restconf subscription and HTTP push for YANG datastores http://www.ietf.org/id/draft-voit-restconf-yang-push-00.txt Extends draft-clemm-netconf-yang-push in the following ways: =B7 proposes Restconf subscription and push mechanisms to continuously = stream information from YANG datastores over HTTP =B7 provides a mechanism to support static subscriptions so that an ope= rator can stream updates over HTTP without Restconf =B7 provides YANG model extensions to leverage HTTP/2 so that individua= l subscriptions can get custom treatment via their own HTTP streams. Thanks for your interest, and we look forward to the discussions! - Alexander Clemm, Eric Voit, Alberto Gonzalez Prieto, Ambika Prasad Tripat= hy, & Einar Nilsen-Nygaard _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_D25691AF52A62albertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <21B68D8308614C43BD58F77BF8590A3F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Andy,

Agreed. 

For the example below, using a periodic subscription on the list of in= terfaces would result in ~100k entries.
Alternatively, using an on-change subscription would result in a singl= e entry on the wire (I.e., just the config delta).
How efficient the delta computation (on the publisher) would be is imp= lementation-specific. 
A publisher implementation has the option of not accepting/supporting = on-change subscriptions. A reason for not accepting an on-change subscripti= on is a high  computational cost for serving it.
That is, there are trade-offs that publishers can control wrt computat= ional cost, space requirements, generated traffic.

Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, October 28, 2015 a= t 12:03 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com>
Cc: Kent Watsen <kwatsen@juniper.net>, "netconf@ietf.org" <netconf@ietf.org>, Alia Atlas <akatlas@gmail.com>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

Hi,

The issue wrt/ PUT vs. PATCH is really a matter of context
and priorities.  If you delete 1 interface out of 100,000, and yo= u
need to send the updated parent container, instead of just
sending "delete interface X", the message could be 10,000
times bigger on-the-wire.  The internal processing could be much<= /div>
higher (e.g., compare 99,999 interfaces to the saved values
to determine there were no changes).  If efficiency is of
no concern, then updating the parent resource is probably OK.


Andy






On Wed, Oct 28, 2015 at 2:16 AM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Thanks for the input Andy.  

In the NETCONF draft, for on-change updates, we consider the operation= s in RFC6241 for edit-config, including merge, and delete.
(when using json encoding, the changes are encoded based on yang-patch= )
Does that address the PUT/PATCH inefficiencies you mention?

FWIW, we do not explicitly include yang:insert from RFC6020. It makes = sense to me including it since not using would lead to inefficiencies, as y= ou correctly point out.
It also makes sense to me adding =93move=94 to the list of operations = in on-change updates.  Thanks for bringing this up.


For periodic updates, the updates contain a snapshot of the current st= ate. That is analogous to a PUT. The rationale was that to compute the delt= as, we would need (a potentially sizable) per-subscription state.
E.g., a subscription for fast-changing oper data subtrees with a large= number of descendants. Such data may not be versioned and its incremental = deltas may not be tracked. In such cases, the state to keep would be a repl= ica of the snapshot used for the last update.

Thanks,

Alberto


From: Netconf <netconf-bounces@ietf.org&g= t; on behalf of Andy Bierman <andy@yumaworks.com>
Date: Tuesday, October 27, 2015 at = 12:50 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>, Alia Atlas= <akatlas@gmail.c= om>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

Hi,

I support the feature in general as an optional addition to NETCONF or= RESTCONF.
I was looking at the details a bit, and I don't think it covers all YA= NG operations
(such as insert, move, delete).

I am implementing a datastore replication protocol based on deltas
represented with YANG Patch.  This looks much more efficient in p= ractice
than sending complete updates of resource representations to the clien= t,
especially for delete, insert, and move.  You basically end up wi= th PUT
instead of PATCH, with all the inefficiencies that involves.

I think the subscription and push control in the yang-push draft is gr= eat,
but the messages on the wire should be more efficient.


Andy


On Tue, Oct 27, 2015 at 12:22 PM, Kent Watsen <kwatsen@junipe= r.net> wrote:

I think it important that whatever we do in NETCONF we can also do in RE= STCONF.   To that end, I support the WG defining "yang-push=94 fo= r both protocols.

Actually, I=92m a little surprised that we=92re discussing this.  M= aybe it=92s just me, but when the WG adopted draft-ietf-netconf-yang-push, = I thought that it would cover both protocols eventually.   Perhaps that a separate draft has been produced is anot= her surprise here - do we really need another draft?

Kent

From: Netconf <netconf-bounces@ietf.org&g= t; on behalf of Susan Hares <shares@ndzh.com>
Date: Tuesday, October 27, 2015 at = 2:52 PM
To: "'Eric Voit (evoit)'"= <evoit@cisco.com>, "netconf= @ietf.org" <netconf@ietf.org>
Cc: 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [Netconf] New YANG Pub= Sub drafts for NETCONF, RESTCONF, HTTP/2

NETCONF:

 

These drafts is import= ant to the I2RS pub/sub.   Is the RESTCONF draft going to be adop= ted (draft-voit-restconf-yang-push-00.txt)?

 

It would be really hel= pful. 

 

Sue Hares

I2RS WG chair <= u>

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Eric Voit (evoit)
Sent: Tuesday, October 13, 2015 11:37 PM
To: netconf@ie= tf.org
Subject: [Netconf] New YANG PubSub drafts for NETCONF, RESTCONF, HTT= P/2

 

There are a couple new drafts posted in NETCONF:<= /u>

 

(1)  Subscribing to YANG datastore push updates=

http://www.ietf.org/id/draft-clemm-ne= tconf-yang-push-02.txt

As per earlier NETCONF discussions we are expecting this draft to become draft= -ietf-netconf-yang-push in the coming days (once the NETCONF charter is app= roved).  Look for an OpenDaylight client in the Beryllium release (Feb= ). 

 

(2) Restconf subscription and HTTP push for YANG dat= astores

http://www.ietf.org/id/draft-voit-res= tconf-yang-push-00.txt

Extends draft-clemm-netconf-yang-push in the following ways:<= /p>

=B7     proposes Restconf subscription and push mechanisms to continuously s= tream information from YANG datastores over HTTP

=B7     provides a mechanism to support static subscriptions so that an oper= ator can stream updates over HTTP without Restconf

=B7     provides YANG model extensions to leverage HTTP/2 so that individual= subscriptions can get custom treatment via their own HTTP streams. 

 

Thanks for your interest, and we look forward to the= discussions!

 

- Alexander Clemm, Eric Voit, Alberto Gonzalez Priet= o, Ambika Prasad Tripathy, & Einar Nilsen-Nygaard

 

 

 

 


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



--_000_D25691AF52A62albertgociscocom_-- From nobody Thu Oct 29 22:33: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 5FDD21B3738; Thu, 29 Oct 2015 22:33:40 -0700 (PDT) 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 MFI7fa-awFCG; Thu, 29 Oct 2015 22:33:39 -0700 (PDT) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB201B3736; Thu, 29 Oct 2015 22:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2737; q=dns/txt; s=iport; t=1446183218; x=1447392818; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ZANYjH5YERb/cO2ii18NC0lLm5xcgCdVmPmBLtCRr+4=; b=WQ9dwQMagXi7ILg2PW/xyCbd9x+KgHYmpOiqe78f53BoxPWNgsC6Ql8N DHXe1zR0kwaEFP3a4zRr8dWttWeGtQpSeNKd8zBTHKPCl2IP5GfhOHyC7 XlW+6NV6KTJSPYG+hI0d1+CtYB2dcMH2vw/8eNYlZqBJEuY5uvhyfnmit o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DNAQC0ADNW/xjFo0hexC0BDYFahhkCgXIUAQEBAQEBAYEKhDYBAQQ4NgoBEAshBBIPCQMCAQIBRQYBDAgBAYgsxGUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhneEfoRFhHsBBI4QiDONJYFZh0AjiiqIUh8BAUKEEy+GMgEBAQ X-IronPort-AV: E=Sophos;i="5.20,217,1444694400"; d="scan'208";a="21622546" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 30 Oct 2015 05:33:32 +0000 Received: from [10.70.231.100] (tky-vpn-client-231-100.cisco.com [10.70.231.100]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t9U5XUpj032743; Fri, 30 Oct 2015 05:33:30 GMT To: Takeshi Takahashi , draft-ietf-netconf-yang-push.all@tools.ietf.org References: <007301d112c1$93241aa0$b96c4fe0$@nict.go.jp> From: Benoit Claise Message-ID: <56330110.9020708@cisco.com> Date: Fri, 30 Oct 2015 14:33:04 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <007301d112c1$93241aa0$b96c4fe0$@nict.go.jp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NETCONF , netconf-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [Netconf] Early secdir review of c-02 (draft-ietf-netconf-yang-push-00) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 05:33:40 -0000 Thanks Take, [bcc'ed the IESG, which was in the initial distribution] I would like this discussion to take place on the NETCONF mailing list, which I added. Note also that this draft is now a WG document: draft-ietf-netconf-yang-push Regards, Benoit > Hello, > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > [overall feeling on this draft] > > As an early review, this document is fine. > I believe the topic is very important. > > [overview] > > This draft deals with the push mechanism of the YANG datastore's updats. > The usability of push mechanism is obvious. > The draft elaborates parameters needed for the mechanism, including filters > and subscription-config. > > [questions] > > It was fun to read the article, though I am not that familiar with this > area. > > Here are several clarification questions. > I would appreciate if you could answer them to deepen my understanding. > > 1. > Let me assue that I send a create-subscription message with the period=500 > parameter. If the server can only send updates with period=1000, what will > happen? > Is the subscription declined? Or is the subscription accepted with > period=1000? > > If it is declined, how can I know the supported period value? > I guess the error response message does not explain the minimum value for > the period. > > 2. > I guess arbitrary value can be set for stop-time. > Then, the updates will be sent periodically for very long time, once the > subscription is accepted. > I am wondering if we need to check whether the subscriber is still alive > (whether the subscriber is still the authorized one). > Would you have any means to check the subscriber status ? (I guess no) > Or, do we need to specify stop-time that is not that far from now to avoid > any accident? > > I am not sure how sensitive the update information is, so it could be a > nonsense question... > > 3. > Are you going to use the IANA tables for the values, such as the "encoding" > field? > > 4. > Regarding the security consideration, I have got the impression that the > current text focuses on DDoS scenarios. > How about the false update? > Malicious entity may send false update to the subscriber. > The false update may let the subscriber mis-judge the situation and initiate > some operations. > Is it going to be a viable concern? > > > Thanks, and kind regards, > Take > > > > . > From nobody Fri Oct 30 00:18: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 F0ECF1B382D; Fri, 30 Oct 2015 00:18:11 -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_42=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 52cR0Ma4ooeM; Fri, 30 Oct 2015 00:18:10 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 724A71B382E; Fri, 30 Oct 2015 00:18:08 -0700 (PDT) Received: from mb.local ([172.56.7.207]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t9U7HtTF052288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 30 Oct 2015 07:18:04 GMT (envelope-from joelja@bogus.com) To: Benoit Claise , Barry Leiba , Netconf References: <5620C26D.7050202@cisco.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <5632F60E.1000304@bogus.com> Date: Fri, 30 Oct 2015 13:46:06 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: <5620C26D.7050202@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RPLFOAbeX9PmBKXvWsp95OsCfvafk5JI6" Archived-At: Cc: netconf-ads@ietf.org Subject: Re: [Netconf] On the registration policy for the NETCONF Capability URNs registry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 30 Oct 2015 07:18:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RPLFOAbeX9PmBKXvWsp95OsCfvafk5JI6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/16/15 6:25 PM, Benoit Claise wrote: > Dear all, >=20 > https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00 >=20 > This document, which updates the NETCONF Capability URNs registry > policy, requires the process defined in RFC 2026. This means that it > needs to be discussed, reviewed by the responsible AD, given an > IETF-wide last call, and reviewed and approved by the IESG. >=20 > I hope that it can go fairly quickly, as it's a simple action. > Therefore, I propose to keep this document as an individual submission,= > which I will AD sponsor. However, neither Bary nor I are going to push= > this ahead against the working group's opposition. With time capability, I thing a pretty decent case was made that experimentation rather than standardization was a necessary step. I think the document stood up to the test of exception handly but, in the future we should imho be more easily able to assign codepoints as necessary on the basis of ietf consensus. Personally I'd be fine without having to repeat process. In favor, thanks joel > So it's time to speak up if you disagree with that policy change. > A final consensus call will be made during the NETCONF meeting in Yokoh= ama. >=20 > Regards, Benoit (OPS AD) >=20 >> For any who haven't followed it, we had a discussion about the >> experimental document draft-mm-netconf-time-capability, which >> registers a NETCONF capability URN. Here's my last comment on the >> point, after I cleared my DISCUSS ballot: >> >> ---------- >> The registration policy for the NETCONF Capability URNs registry is >> Standards Action, and this document, with Experimental status, does >> not meet the requirement that the registration come from a Standards >> Track RFC. This document cannot make that registration. >> >> After discussion about whether the IESG should make an exception in >> this case and allow the registration, I agree that it's the right >> thing to do for this document, so I've cleared my DISCUSS ballot on >> that point. >> >> But at the same time, it seems that the registration policy is too >> strict, and should be IETF Review, which allows the NETCONF working >> group to make the decision by getting IETF consensus on the >> registration -- there's no need to specifically require a Standards >> Track RFC. To that end, I've submitted an Internet draft, >> draft-leiba-netmod-regpolicy-update, which I ask the Network >> Operations AD to sponsor, in coordination with the NETCONF working >> group. >> ---------- >> >> I typo'ed the filename (made it "-netmod-" rather than "-netconf-"); >> sorry about that. In any case, the NETCONF working group should look >> at it and comment. It's straightforward, just changing the >> registration policy and explaining why. I don't expect there'll be >> controversy with it, but please do give it a review and comment, and >> let Beno=C3=AEt and Joel know if y'all think it's acceptable for one o= f >> them to AD-sponsor: >> https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/ >> >> Please keep me on CC for any discussion, so I'll see the messages, >> though I'll also keep an eye on the mailing list archive. >> >> Thanks, >> Barry, ART AD >> . >> >=20 --RPLFOAbeX9PmBKXvWsp95OsCfvafk5JI6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlYy9g4ACgkQ8AA1q7Z/VrJ2zgCeNNCrmOHU2Kt4pNH+siHXcnUZ 2/YAn1UsAfeKvpwUyQ0QCjZtMG5LPtis =61sv -----END PGP SIGNATURE----- --RPLFOAbeX9PmBKXvWsp95OsCfvafk5JI6-- From nobody Fri Oct 30 16:56: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 682701A01BA; Fri, 30 Oct 2015 16:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXv3aOhECCEJ; Fri, 30 Oct 2015 16:56:17 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 AF8561A014B; Fri, 30 Oct 2015 16:56:17 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so91050942pac.3; Fri, 30 Oct 2015 16:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=g6YNJzk1z2s0bm5t3k5/RqDxN68YGzcHKgUbWS1rkwY=; b=WvYH/PwQv49A58uPnhq0ge5ZlF8UK3dkFF4i48eJGkeZHXHLCd9L80d1F2Ix9bdQqg JVJSwjohjZ6zNaJNiSpjTTV9p48s/CQQXyAxci1f6wn1dXdMKYsI24LukriXrnMkE22I 3dTm8YKmHMedC8io4lj1W4qVa/BM/+YUd3aEimdGZBelqCseE4nKLQEcy1AzqLHjROmZ e5EzWPFH9oc5lHmSft5GeiDRJlJcKMIioDLjlUVxbBEKTQHUWSTVX7yHT/23kI97r3zF UfU5GjCYm74W5ruwEDU+JDb6PSvPCtiTAxSV//xR7poki6Ne4eyrACVJ36FC4jPuelLY 0yfg== X-Received: by 10.66.153.166 with SMTP id vh6mr11793227pab.83.1446249377270; Fri, 30 Oct 2015 16:56:17 -0700 (PDT) Received: from Martins-MacBook-Pro.local (y125063.ppp.asahi-net.or.jp. [118.243.125.63]) by smtp.googlemail.com with ESMTPSA id bo5sm10248630pbb.76.2015.10.30.16.56.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Oct 2015 16:56:16 -0700 (PDT) To: Kent Watsen , "t.petch" , The IESG References: <20151021204001.1120.3050.idtracker@ietfa.amsl.com> <71108EB6-9AF3-4458-ACC9-53F805E18602@juniper.net> <562DE4BD.3040504@gmail.com> <01a401d10fd1$ef98b900$4001a8c0@gateway.2wire.net> <650DF556-95DC-4039-9C94-BC78A1D74267@juniper.net> From: Martin Stiemerling Message-ID: <5633D27D.6070704@gmail.com> Date: Fri, 30 Oct 2015 21:26:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <650DF556-95DC-4039-9C94-BC78A1D74267@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netconf-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 30 Oct 2015 23:56:19 -0000 Am 26.10.15 um 15:44 schrieb Kent Watsen: > > > > > > On 10/26/15, 5:37 AM, "t.petch" wrote: > >> ----- Original Message ----- >> From: "Martin Stiemerling" >> To: "Kent Watsen" ; "The IESG" >> Cc: ; ; >> >> Sent: Monday, October 26, 2015 8:30 AM >> >>> Hi Ken, all, >>> >>> Am 21.10.15 um 23:19 schrieb Kent Watsen: >>>> Hi Martin, >>>> >>>> Thank you for your review. >>>> >>>>> 1) Why is this parapraph below (and subsequently the other similar >>>>> ones) using RFC 2119 language with respect to the port numbers The >>>>> NETCONF/RESTCONF client listens for TCP connection requests from >>>>> NETCONF/RESTCONF servers. The client SHOULD listen for connections >>>>> on the IANA-assigned ports defined in section Section 5, but MAY be >>>>> configured to use a non-standard port. >>>>> >>>>> Using the right port number is not something that influences the >>>>> interoperability of the protocol per se, but is an operational >>>>> parameter. Checking other protocol specifications, e.g. HTTP/1.1, >>>>> there is no RFC 2119 language about the usage of specific port >>>>> numbers. >>>> >>>> This is true. I don’t see RFC 2119 language in RFC 4253 either. >>>> That said, is it in any way wrong or bad? I’m happy to change the >>>> text of course, just want to confirm... >>> >>> I would remove RFC 2119 language in those paragraphs, as this does not >>> need RFC 2119 language. >> >> But RFC5426 says >> >> " Syslog receivers MUST support accepting syslog datagrams on the well- >> known UDP port 514, but MAY be configurable to listen on a different >> port. " >> >> and I think that this is a better analogy than RFC4253, the former being >> a network management protocol for operators running over a transport >> which the reader may or may not be expert in, whereas the latter is >> written by experts for experts. >> >> Tom Petch > > > Hi Tom, > > Thanks for pointing this out. I actually like the RFC 5426 language more than the current text, it seems more precise to me. So how about the following? > > OLD: > > The NETCONF/RESTCONF client listens for TCP connection requests > from NETCONF/RESTCONF servers. The client SHOULD listen for > connections on the IANA-assigned ports defined in section > Section 5, but MAY be configured to use a non-standard port. > > NEW: > > > The NETCONF/RESTCONF client listens for TCP connection requests > from NETCONF/RESTCONF servers. The client MUST support accepting > TCP connections on the IANA-assigned ports defined in section > Section 5, but MAY be configurable to listen on a different port. > > > Martin, does seeing RFC 5426 help? That would work for me. Martin > > > > > > >>>>> 3) This document will benefit from an overview figure that details >>>>> who is the server/client on what level for what. >>>> >>>> >>>> I tred this before and the comment received was that it was >>>> confusing: >>>> http://www.ietf.org/mail-archive/web/netconf/current/msg09978.html. >>>> But that was just one opinion. What do you think about the diagram >>>> in the linked message? >>> >>> This would be good, may be it is worth saying that the arrows are >>> pointing from the initiator away. > > > PS: I’m planning to add this diagram into the draft. > > > Thanks again, > Kent > > > From nobody Fri Oct 30 22:59: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 ECCBB1B3472 for ; Fri, 30 Oct 2015 22:59:00 -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 uIFQV9kbdGO0 for ; Fri, 30 Oct 2015 22:58:58 -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 C9F1F1B3471 for ; Fri, 30 Oct 2015 22:58:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDI28065; Sat, 31 Oct 2015 05:58:55 +0000 (GMT) Received: from SZXEML429-HUB.china.huawei.com (10.82.67.184) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 31 Oct 2015 05:58:54 +0000 Received: from SZXEML512-MBS.china.huawei.com ([169.254.8.196]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0235.001; Sat, 31 Oct 2015 13:58:44 +0800 From: Rohit R Ranade To: "netconf@ietf.org" Thread-Topic: Queries about notification in draft-ietf-netconf-restconf-07 Thread-Index: AdEToTHvSmqSRw3mRlu+4NDxjp44oA== Date: Sat, 31 Oct 2015 05:58:43 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A67220EA6@szxeml512-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.242.206] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A67220EA6szxeml512mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "a71831@notesmail.huawei.com" Subject: [Netconf] Queries about notification in draft-ietf-netconf-restconf-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 05:59:01 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A67220EA6szxeml512mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, In Section 6.3. Subscribing to Receive Notifications, " The RESTCONF client can then use this URL value to start monitoring the eve= nt stream: GET /streams/NETCONF HTTP/1.1 Host: example.com Accept: text/event-stream Cache-Control: no-cache Connection: keep-alive " =F0 This mentions about when the client can start getting the notification= s. Furthermore in Section 4.8.8. The "stop-time" Query Parameter, when describ= ing this parameter, " If this parameter is not present, the notifications will continue until the= subscription is terminated. " =F0 This means that there is indeed a mechanism where the subscription can= be terminated. But in this draft I am not able to find the exact RESTCONF = request to be sent to stop receiving these notifications. So can you please provide the RESTCONF request that will unsubscribe the ev= ents. With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A67220EA6szxeml512mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

In Section 6.3. Subscribing to Receive Notifications= ,

“

The RESTCONF client can then use this URL value to s= tart monitoring the event stream:

GET /streams/NETCONF HTTP/1.1

Host: example.com

Accept: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

”

=F0  This mentions about when the client can star= t getting the notifications.

 

 

Furthermore in Section 4.8.8. The "stop-time&qu= ot; Query Parameter, when describing this parameter,

“

If this parameter is not present, the notifications = will continue until the subscription is terminated.

”

=F0  This means that there is indeed a mechanism = where the subscription can be terminated. But in this draft I am not able t= o find the exact RESTCONF request to be sent to stop receiving these notifi= cations.

 

So can you please provide the RESTCONF request that = will unsubscribe the events.

 

With Regards,

Rohit

 

--_000_991B70D8B4112A4699D5C00DDBBF878A67220EA6szxeml512mbschi_-- From nobody Sat Oct 31 23:18: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 3D9241B682D for ; Sat, 31 Oct 2015 23:18:54 -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 IsL36tnzmrFc for ; Sat, 31 Oct 2015 23:18:52 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 A9B4B1B682B for ; Sat, 31 Oct 2015 23:18:52 -0700 (PDT) Received: by pasz6 with SMTP id z6so114439345pas.2 for ; Sat, 31 Oct 2015 23:18:52 -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=ejajl+kGL2O+GbUegJ4yot/XAYSNvZmzYUHPTKBs4Gg=; b=REBHDLRg5cZ47i+XA4UoFVakEsKTiJVxdF8uWBmoLQ2jaEuy+wImJcxYuHbz0gVgmn oFNDrMpT0Rl8JTwIrecK7JFXJHkaIkd11ze4dBVgVG2/xd76SlCVWXcfdF5LT8G/qluL q01hi23kbK1we2c8UFA962szyKsIndc8MQmnf4/tdRTIXL8XeuYeIcrJH710a+rCUDTl VL//uLTiXUalEMjtjFw3Uv6ZYF1JF0vKC3QvvVo+LG9Cki+kygGtX7xVjivX0WFqCk2E DuN3bJd9VkwXx5HnxzUQU4+4XrDejivr6DMJwLNe2PzvjhiJEWKCW95WpM8KlVl3TyAX qzuw== X-Received: by 10.67.14.194 with SMTP id fi2mr18627963pad.146.1446358732408; Sat, 31 Oct 2015 23:18:52 -0700 (PDT) Received: from [10.24.149.23] ([128.107.241.182]) by smtp.gmail.com with ESMTPSA id xa4sm16985219pac.28.2015.10.31.23.18.51 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 31 Oct 2015 23:18:52 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_3C8F1510-0FE2-4CDE-A719-D0F5E319BF5A" Message-Id: <7C5D794E-DBF4-4D56-8875-BD105F29FEE8@gmail.com> Date: Sun, 1 Nov 2015 15:18:49 +0900 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Netconf] Reminder: Need your presentations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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 Nov 2015 06:18:54 -0000 --Apple-Mail=_3C8F1510-0FE2-4CDE-A719-D0F5E319BF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you are presenting at IETF 94, this is a gentle reminder that you = need to send in your slides by end of day Sunday. Please send the slides = to netconf-chairs@ietf.org. The agenda for the meeting is posted here - = http://tools.ietf.org/wg/netconf/agenda?item=3Dagenda-94-netconf.html = Thanks. Mahesh & Mehmet --Apple-Mail=_3C8F1510-0FE2-4CDE-A719-D0F5E319BF5A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii If you are presenting at IETF 94, this is a gentle reminder that you need to send in your slides by end of day Sunday. Please send the slides to netconf-chairs@ietf.org.

The agenda for the meeting is posted here - http://tools.ietf.org/wg/netconf/agenda?item=agenda-94-netconf.html

Thanks.

Mahesh & Mehmet



--Apple-Mail=_3C8F1510-0FE2-4CDE-A719-D0F5E319BF5A--