From nobody Tue Dec 8 12:49:02 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 62B3B1A700C for ; Tue, 8 Dec 2015 12:49:00 -0800 (PST) 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 aceMCVBjp3Tn for ; Tue, 8 Dec 2015 12:48:58 -0800 (PST) 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 50B211A6FF8 for ; Tue, 8 Dec 2015 12:48:58 -0800 (PST) Received: by lfs39 with SMTP id 39so20834159lfs.3 for ; Tue, 08 Dec 2015 12:48:56 -0800 (PST) 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=Q+9PDGUwVzNtL1HEC8XqdoU/FyKWgz+XSevlI7mjXr0=; b=ArfIyMhU6CWUkamr/T9eq5C3jom46+XUok/C129nCOeMXUnF12TTfoL6nof9+LxVPm kvLgIUkEDldLLdxSFWEubMAy8kkO0a/frDZvsoTw3mUWQZpq3WbPgmZrvQSAOYpEafZ4 P3ZomABg6Ws15Ui3DWvNm/2KCiHvpyh4V3ujsE2VsaS79pnGfhxNpWejebWlox6JfDJD c6Pc53upuDyngvQRqa47pQFEVSzF9ryU9ToO28nNoFSgEpF6bw5m+Itc2Dq+/GS3noap We9D+9/FgQDyFSXssQcw5h9dxWagllp+AqYhzt7PwqXnL9BL01czk6Qn/SzdGCpVYeOr fZFw== 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=Q+9PDGUwVzNtL1HEC8XqdoU/FyKWgz+XSevlI7mjXr0=; b=L2WObgn3o9zT3uXVL4JvTYnfjvWa82+DUqO/XqhVb+KeuNSdxwFqnbm/ZoVcQT3iLL I3coeWTPAE41JsBhT6qkUQYlmLpBNGRLta9xaEfl5CQqaeDnDCcXsj9kitUqfXv4o3Ps KOfWhB+LbIYG2+dR0S3szY8l5BLK9xwCoszEJOLf0RGf9BCDCfz/mKCKwK6Fb/C/Wgs+ Ao9GyD7uTsITqnFNlSnn3p5LX98EdIJhmA1c6Bus9vf+pm5wRVpp3xKUXlif0M9K+TmG OUh0TUPev0Ms24ip7/i7mBzy4mdrKXY1MASIOzGkL97ffklCuKqhGB5wFJ68tFF87mnU NPGg== X-Gm-Message-State: ALoCoQmYosrfn/6vUDOuFxljHkI1ngbdTFdt4gYsC4lvUyviM0fkDDRR2hUoeyht6BJzW7omRXoGXtjGwlnLT+3DqNsmbes5Mw== MIME-Version: 1.0 X-Received: by 10.25.85.200 with SMTP id j191mr641957lfb.131.1449607736382; Tue, 08 Dec 2015 12:48:56 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 8 Dec 2015 12:48:56 -0800 (PST) In-Reply-To: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> References: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> Date: Tue, 8 Dec 2015 12:48:56 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11424d0c30f4530526691a16 Archived-At: Cc: Netconf Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 08 Dec 2015 20:49:00 -0000 --001a11424d0c30f4530526691a16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen wrote: > > Is there a better example than ietf-netconf? - I don=E2=80=99t think > ietf-netconf is a valid example as it=E2=80=99s not listed in a NETCONF <= hello> > message - only it=E2=80=99s namespace is used, but that is quite differen= t... > > Actually it is listed in the , except that nobody actually implements it since the information is already sent in the original capability URIs (e.g. :candidate capability checked, not candidate feature). > If it=E2=80=99s just this one example, then I prefer option #1. > I still prefer 2 because the server data should be protocol-neutral, and clashes between protocols cannot be identified if 1 protocol cannot see what is enabled for other protocols. We already implement RESTCONF, NETCONF, and ietf-yang-library together. Some modules like the library itself will always be enabled for all protocols, but other modules may depend on the protocol or the vendor or the operator. > Kent > Andy > > > From: Netconf on behalf of Andy Bierman < > andy@yumaworks.com> > Date: Tuesday, November 10, 2015 at 6:16 PM > To: "netconf@ietf.org" > Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules > > Hi, > > This open issue needs to be resolved. > https://github.com/netconf-wg/yang-library/issues/5 > > > There are 2 solution paths that have been suggested: > > YLIB5-01: separate views for each protocol. > Each protocol would receive only the modules that are enabled > for that protocol. > > YLIB5-02: add leaf-list to each module entry > NETCONF and RESTCONF identities can be defined right away. > Other protocols can define new identities on their own. > > leaf-list protocol { > type identityref { > base yang-protocol; > } > } > > > IMO both have drawbacks. > The server really tries to avoid protocol-dependent code. > The code that manages data does not care about protocols, > just internal representations of YANG data. > > The leaf-list approach is a waste of bandwidth unless the > YANG library is actually shared by multiple protocols > within a single server instance. > > So please discuss this issue on the mailing list and give your preference > for a solution, or suggest a new solution. > > > Andy > > --001a11424d0c30f4530526691a16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Is there a better example than ietf-netconf? =C2=A0 =C2=A0- I don=E2= =80=99t think ietf-netconf is a valid example as it=E2=80=99s not listed in= a NETCONF <hello> message - only it=E2=80=99s namespace is used, but= that is quite different...


Actually it is = listed in the <hello>, except that nobody actually implements it
since the information is already sent in the original capability URIs=
(e.g. :candidate capability checked, not candidate feature).

=C2=A0
If it=E2=80=99s just this one example, then I prefer option #1.
<= /div>

I still prefer 2 because the se= rver data should be protocol-neutral,
and clashes between protoco= ls cannot be identified if 1 protocol
cannot see what is enabled = for other protocols.

We already implement RESTCONF= , NETCONF, and ietf-yang-library together.
Some modules like the = library itself will always be enabled for =C2=A0all protocols,
bu= t other modules may depend on the protocol or the vendor or the operator.





Kent

Andy
= =C2=A0


From: Netconf <netconf-bounces@ietf.org&g= t; on behalf of Andy Bierman <andy@yumaworks.com>
Date: Tuesday, November 10, 2015 at= 6:16 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] YANGLIB #5: how = to list protocol-specific modules

Hi,

This open issue needs to be resolved.


There are 2 solution paths that have been suggested:

YLIB5-01: separate views for each protocol.
Each protocol would receive only the modules that are enabled
for that protocol.

YLIB5-02: add leaf-list to each module entry
NETCONF and RESTCONF identities can be defined right away.
Other protocols can define new identities on their own.

=C2=A0 =C2=A0leaf-list protocol {
=C2=A0 =C2=A0 =C2=A0 type identityref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 base yang-protocol;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}


IMO both have drawbacks.
The server really tries to avoid protocol-dependent code.
The code that manages data does not care about protocols,
just internal representations of YANG data.

The leaf-list approach is a waste of bandwidth unless the
YANG library is actually shared by multiple protocols
within a single server instance.

So please discuss this issue on the mailing list and give your prefere= nce
for a solution, or suggest a new solution.


Andy


--001a11424d0c30f4530526691a16-- From nobody Tue Dec 8 14:52: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 C06181ACD57 for ; Tue, 8 Dec 2015 14:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jh4QZVT5QEqK for ; Tue, 8 Dec 2015 14:52:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937701ACD4B for ; Tue, 8 Dec 2015 14:52:44 -0800 (PST) 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.337.19; Tue, 8 Dec 2015 22:52:24 +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.0337.015; Tue, 8 Dec 2015 22:52:24 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] YANGLIB #5: how to list protocol-specific modules Thread-Index: AQHRHA3lf+pHkCqT6UWabmA+SfZnrZ6XpYSAgCoWFgD//86rAA== Date: Tue, 8 Dec 2015 22:52:24 +0000 Message-ID: References: <1BE42550-64A1-4063-AD20-7093F51AA351@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.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:HpexyTmRmdJmpFG9GfyiRm0zEivYJJ7CB8CCKwhXuY+LjAgIfutzbV1GlN24HOJIrFXzEK3xRyTazFOuVgvUYZVxoNJ7w3ibkpIvLkTO01eEtMz6WJBKNBJa46g7x+if15FmR/GJgMCQ96CvPY65cA==; 24:f7TQya/dRp3URl7NFQuJQIThvSYp75AGhmTHYPn/endAUhGR66kvjV8JG+VmLZ8Z6HrIhQvkqW2Elag99s6rRxdNibNGgP8WNfU/akMUUS4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; 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)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0784C803FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(199003)(189002)(24454002)(101416001)(86362001)(5001960100002)(81156007)(19580405001)(5002640100001)(5004730100002)(19580395003)(66066001)(106116001)(122556002)(87936001)(36756003)(19617315012)(40100003)(82746002)(83716003)(102836003)(76176999)(1096002)(189998001)(11100500001)(5008740100001)(105586002)(83506001)(2950100001)(16236675004)(1220700001)(586003)(50986999)(6116002)(54356999)(3846002)(33656002)(92566002)(77096005)(4001350100001)(106356001)(15975445007)(2900100001)(110136002)(97736004)(10400500002)(99286002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; 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_B697F0AF6F734A9B8F78F58B697072F2junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2015 22:52:24.3615 (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 Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 08 Dec 2015 22:52:54 -0000 --_000_B697F0AF6F734A9B8F78F58B697072F2junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBBbmR5LA0KDQojMiBpcyBmaW5lIGFsc28sIGVzcGVjaWFsbHkgd2l0aCBNYXJ0aW7igJlz ICJyZXN0cmljdGVkLXByb3RvY2FsIiBlbmhhbmNlbWVudC4NCg0KSy4NCg0KRnJvbTogQW5keSBC aWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQpE YXRlOiBUdWVzZGF5LCBEZWNlbWJlciA4LCAyMDE1IGF0IDM6NDggUE0NClRvOiBLZW50IFdhdHNl biA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+DQpDYzog Im5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRm Lm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIFlB TkdMSUIgIzU6IGhvdyB0byBsaXN0IHByb3RvY29sLXNwZWNpZmljIG1vZHVsZXMNCg0KDQoNCk9u IFdlZCwgTm92IDExLCAyMDE1IGF0IDk6MDcgQU0sIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlw ZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQoNCklzIHRoZXJlIGEg YmV0dGVyIGV4YW1wbGUgdGhhbiBpZXRmLW5ldGNvbmY/ICAgIC0gSSBkb27igJl0IHRoaW5rIGll dGYtbmV0Y29uZiBpcyBhIHZhbGlkIGV4YW1wbGUgYXMgaXTigJlzIG5vdCBsaXN0ZWQgaW4gYSBO RVRDT05GIDxoZWxsbz4gbWVzc2FnZSAtIG9ubHkgaXTigJlzIG5hbWVzcGFjZSBpcyB1c2VkLCBi dXQgdGhhdCBpcyBxdWl0ZSBkaWZmZXJlbnQuLi4NCg0KDQpBY3R1YWxseSBpdCBpcyBsaXN0ZWQg aW4gdGhlIDxoZWxsbz4sIGV4Y2VwdCB0aGF0IG5vYm9keSBhY3R1YWxseSBpbXBsZW1lbnRzIGl0 DQpzaW5jZSB0aGUgaW5mb3JtYXRpb24gaXMgYWxyZWFkeSBzZW50IGluIHRoZSBvcmlnaW5hbCBj YXBhYmlsaXR5IFVSSXMNCihlLmcuIDpjYW5kaWRhdGUgY2FwYWJpbGl0eSBjaGVja2VkLCBub3Qg Y2FuZGlkYXRlIGZlYXR1cmUpLg0KDQoNCklmIGl04oCZcyBqdXN0IHRoaXMgb25lIGV4YW1wbGUs IHRoZW4gSSBwcmVmZXIgb3B0aW9uICMxLg0KDQpJIHN0aWxsIHByZWZlciAyIGJlY2F1c2UgdGhl IHNlcnZlciBkYXRhIHNob3VsZCBiZSBwcm90b2NvbC1uZXV0cmFsLA0KYW5kIGNsYXNoZXMgYmV0 d2VlbiBwcm90b2NvbHMgY2Fubm90IGJlIGlkZW50aWZpZWQgaWYgMSBwcm90b2NvbA0KY2Fubm90 IHNlZSB3aGF0IGlzIGVuYWJsZWQgZm9yIG90aGVyIHByb3RvY29scy4NCg0KV2UgYWxyZWFkeSBp bXBsZW1lbnQgUkVTVENPTkYsIE5FVENPTkYsIGFuZCBpZXRmLXlhbmctbGlicmFyeSB0b2dldGhl ci4NClNvbWUgbW9kdWxlcyBsaWtlIHRoZSBsaWJyYXJ5IGl0c2VsZiB3aWxsIGFsd2F5cyBiZSBl bmFibGVkIGZvciAgYWxsIHByb3RvY29scywNCmJ1dCBvdGhlciBtb2R1bGVzIG1heSBkZXBlbmQg b24gdGhlIHByb3RvY29sIG9yIHRoZSB2ZW5kb3Igb3IgdGhlIG9wZXJhdG9yLg0KDQoNCg0KDQoN CktlbnQNCg0KQW5keQ0KDQoNCg0KRnJvbTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQW5keSBC aWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQpE YXRlOiBUdWVzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNSBhdCA2OjE2IFBNDQpUbzogIm5ldGNvbmZA aWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxtYWls dG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbTmV0Y29uZl0gWUFOR0xJQiAjNTogaG93 IHRvIGxpc3QgcHJvdG9jb2wtc3BlY2lmaWMgbW9kdWxlcw0KDQpIaSwNCg0KVGhpcyBvcGVuIGlz c3VlIG5lZWRzIHRvIGJlIHJlc29sdmVkLg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cv eWFuZy1saWJyYXJ5L2lzc3Vlcy81DQoNCg0KVGhlcmUgYXJlIDIgc29sdXRpb24gcGF0aHMgdGhh dCBoYXZlIGJlZW4gc3VnZ2VzdGVkOg0KDQpZTElCNS0wMTogc2VwYXJhdGUgdmlld3MgZm9yIGVh Y2ggcHJvdG9jb2wuDQpFYWNoIHByb3RvY29sIHdvdWxkIHJlY2VpdmUgb25seSB0aGUgbW9kdWxl cyB0aGF0IGFyZSBlbmFibGVkDQpmb3IgdGhhdCBwcm90b2NvbC4NCg0KWUxJQjUtMDI6IGFkZCBs ZWFmLWxpc3QgdG8gZWFjaCBtb2R1bGUgZW50cnkNCk5FVENPTkYgYW5kIFJFU1RDT05GIGlkZW50 aXRpZXMgY2FuIGJlIGRlZmluZWQgcmlnaHQgYXdheS4NCk90aGVyIHByb3RvY29scyBjYW4gZGVm aW5lIG5ldyBpZGVudGl0aWVzIG9uIHRoZWlyIG93bi4NCg0KICAgbGVhZi1saXN0IHByb3RvY29s IHsNCiAgICAgIHR5cGUgaWRlbnRpdHlyZWYgew0KICAgICAgICAgIGJhc2UgeWFuZy1wcm90b2Nv bDsNCiAgICAgICB9DQogICB9DQoNCg0KSU1PIGJvdGggaGF2ZSBkcmF3YmFja3MuDQpUaGUgc2Vy dmVyIHJlYWxseSB0cmllcyB0byBhdm9pZCBwcm90b2NvbC1kZXBlbmRlbnQgY29kZS4NClRoZSBj b2RlIHRoYXQgbWFuYWdlcyBkYXRhIGRvZXMgbm90IGNhcmUgYWJvdXQgcHJvdG9jb2xzLA0KanVz dCBpbnRlcm5hbCByZXByZXNlbnRhdGlvbnMgb2YgWUFORyBkYXRhLg0KDQpUaGUgbGVhZi1saXN0 IGFwcHJvYWNoIGlzIGEgd2FzdGUgb2YgYmFuZHdpZHRoIHVubGVzcyB0aGUNCllBTkcgbGlicmFy eSBpcyBhY3R1YWxseSBzaGFyZWQgYnkgbXVsdGlwbGUgcHJvdG9jb2xzDQp3aXRoaW4gYSBzaW5n bGUgc2VydmVyIGluc3RhbmNlLg0KDQpTbyBwbGVhc2UgZGlzY3VzcyB0aGlzIGlzc3VlIG9uIHRo ZSBtYWlsaW5nIGxpc3QgYW5kIGdpdmUgeW91ciBwcmVmZXJlbmNlDQpmb3IgYSBzb2x1dGlvbiwg b3Igc3VnZ2VzdCBhIG5ldyBzb2x1dGlvbi4NCg0KDQpBbmR5DQoNCg0K --_000_B697F0AF6F734A9B8F78F58B697072F2junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkhpIEFuZHksPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4j MiBpcyBmaW5lIGFsc28sIGVzcGVjaWFsbHkgd2l0aCBNYXJ0aW7igJlzICZxdW90O3Jlc3RyaWN0 ZWQtcHJvdG9jYWwmcXVvdDsgZW5oYW5jZW1lbnQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5LLjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp emU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5BbmR5IEJpZXJt YW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtz LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv c3Bhbj5UdWVzZGF5LCBEZWNlbWJlciA4LCAyMDE1IGF0IDM6NDggUE08YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5LZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+ UmU6IFtOZXRjb25mXSBZQU5HTElCICM1OiBob3cgdG8gbGlzdCBwcm90b2NvbC1zcGVjaWZpYyBt b2R1bGVzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgTm92IDExLCAyMDE1IGF0IDk6MDcgQU0sIEtlbnQgV2F0 c2VuIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVy Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCwwLDApO2ZvbnQt c2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8ZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+SXMgdGhlcmUgYSBiZXR0ZXIgZXhhbXBsZSB0aGFuIGlldGYtbmV0 Y29uZj8gJm5ic3A7ICZuYnNwOy0gSSBkb27igJl0IHRoaW5rIGlldGYtbmV0Y29uZiBpcyBhIHZh bGlkIGV4YW1wbGUgYXMgaXTigJlzIG5vdCBsaXN0ZWQgaW4gYSBORVRDT05GICZsdDtoZWxsbyZn dDsgbWVzc2FnZSAtIG9ubHkgaXTigJlzIG5hbWVzcGFjZSBpcyB1c2VkLCBidXQgdGhhdCBpcyBx dWl0ZSBkaWZmZXJlbnQuLi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWN0dWFsbHkgaXQgaXMg bGlzdGVkIGluIHRoZSAmbHQ7aGVsbG8mZ3Q7LCBleGNlcHQgdGhhdCBub2JvZHkgYWN0dWFsbHkg aW1wbGVtZW50cyBpdDwvZGl2Pg0KPGRpdj5zaW5jZSB0aGUgaW5mb3JtYXRpb24gaXMgYWxyZWFk eSBzZW50IGluIHRoZSBvcmlnaW5hbCBjYXBhYmlsaXR5IFVSSXM8L2Rpdj4NCjxkaXY+KGUuZy4g OmNhbmRpZGF0ZSBjYXBhYmlsaXR5IGNoZWNrZWQsIG5vdCBjYW5kaWRhdGUgZmVhdHVyZSkuPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJy ZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWYiPg0KPGRpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PklmIGl04oCZcyBqdXN0 IHRoaXMgb25lIGV4YW1wbGUsIHRoZW4gSSBwcmVmZXIgb3B0aW9uICMxLjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgc3RpbGwg cHJlZmVyIDIgYmVjYXVzZSB0aGUgc2VydmVyIGRhdGEgc2hvdWxkIGJlIHByb3RvY29sLW5ldXRy YWwsPC9kaXY+DQo8ZGl2PmFuZCBjbGFzaGVzIGJldHdlZW4gcHJvdG9jb2xzIGNhbm5vdCBiZSBp ZGVudGlmaWVkIGlmIDEgcHJvdG9jb2w8L2Rpdj4NCjxkaXY+Y2Fubm90IHNlZSB3aGF0IGlzIGVu YWJsZWQgZm9yIG90aGVyIHByb3RvY29scy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PldlIGFscmVhZHkgaW1wbGVtZW50IFJFU1RDT05GLCBORVRDT05GLCBhbmQgaWV0Zi15YW5nLWxp YnJhcnkgdG9nZXRoZXIuPC9kaXY+DQo8ZGl2PlNvbWUgbW9kdWxlcyBsaWtlIHRoZSBsaWJyYXJ5 IGl0c2VsZiB3aWxsIGFsd2F5cyBiZSBlbmFibGVkIGZvciAmbmJzcDthbGwgcHJvdG9jb2xzLDwv ZGl2Pg0KPGRpdj5idXQgb3RoZXIgbW9kdWxlcyBtYXkgZGVwZW5kIG9uIHRoZSBwcm90b2NvbCBv ciB0aGUgdmVuZG9yIG9yIHRoZSBvcGVyYXRvci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5LZW50PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+QW5keTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMnB0O3RleHQtYWxpZ246bGVm dDtjb2xvcjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1 bSBub25lO1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJTkctUklHSFQ6 MGluO0JPUkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1lZGl1bSBub25l O1BBRERJTkctVE9QOjNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTog PC9zcGFuPk5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBi ZWhhbGYgb2YgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3Mu Y29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIE5vdmVtYmVy IDEwLCAyMDE1IGF0IDY6MTYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W05l dGNvbmZdIFlBTkdMSUIgIzU6IGhvdyB0byBsaXN0IHByb3RvY29sLXNwZWNpZmljIG1vZHVsZXM8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdj5IaSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgb3BlbiBp c3N1ZSBuZWVkcyB0byBiZSByZXNvbHZlZC48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL25ldGNvbmYtd2cveWFuZy1saWJyYXJ5L2lzc3Vlcy81IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cveWFuZy1saWJyYXJ5L2lzc3Vlcy81PC9h Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlRoZXJlIGFyZSAyIHNvbHV0aW9uIHBhdGhzIHRoYXQgaGF2ZSBiZWVuIHN1Z2dlc3RlZDo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllMSUI1LTAxOiBzZXBhcmF0ZSB2aWV3cyBmb3Ig ZWFjaCBwcm90b2NvbC48L2Rpdj4NCjxkaXY+RWFjaCBwcm90b2NvbCB3b3VsZCByZWNlaXZlIG9u bHkgdGhlIG1vZHVsZXMgdGhhdCBhcmUgZW5hYmxlZDwvZGl2Pg0KPGRpdj5mb3IgdGhhdCBwcm90 b2NvbC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllMSUI1LTAyOiBhZGQgbGVhZi1s aXN0IHRvIGVhY2ggbW9kdWxlIGVudHJ5PC9kaXY+DQo8ZGl2Pk5FVENPTkYgYW5kIFJFU1RDT05G IGlkZW50aXRpZXMgY2FuIGJlIGRlZmluZWQgcmlnaHQgYXdheS48L2Rpdj4NCjxkaXY+T3RoZXIg cHJvdG9jb2xzIGNhbiBkZWZpbmUgbmV3IGlkZW50aXRpZXMgb24gdGhlaXIgb3duLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2xlYWYtbGlzdCBwcm90b2NvbCB7 PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7IHR5cGUgaWRlbnRpdHlyZWYgezwvZGl2 Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJhc2UgeWFuZy1wcm90 b2NvbDs8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTwvZGl2Pg0KPGRp dj4mbmJzcDsgJm5ic3A7fTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PklNTyBib3RoIGhhdmUgZHJhd2JhY2tzLjwvZGl2Pg0KPGRpdj5UaGUgc2VydmVy IHJlYWxseSB0cmllcyB0byBhdm9pZCBwcm90b2NvbC1kZXBlbmRlbnQgY29kZS48L2Rpdj4NCjxk aXY+VGhlIGNvZGUgdGhhdCBtYW5hZ2VzIGRhdGEgZG9lcyBub3QgY2FyZSBhYm91dCBwcm90b2Nv bHMsPC9kaXY+DQo8ZGl2Pmp1c3QgaW50ZXJuYWwgcmVwcmVzZW50YXRpb25zIG9mIFlBTkcgZGF0 YS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBsZWFmLWxpc3QgYXBwcm9hY2gg aXMgYSB3YXN0ZSBvZiBiYW5kd2lkdGggdW5sZXNzIHRoZTwvZGl2Pg0KPGRpdj5ZQU5HIGxpYnJh cnkgaXMgYWN0dWFsbHkgc2hhcmVkIGJ5IG11bHRpcGxlIHByb3RvY29sczwvZGl2Pg0KPGRpdj53 aXRoaW4gYSBzaW5nbGUgc2VydmVyIGluc3RhbmNlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+U28gcGxlYXNlIGRpc2N1c3MgdGhpcyBpc3N1ZSBvbiB0aGUgbWFpbGluZyBsaXN0IGFu ZCBnaXZlIHlvdXIgcHJlZmVyZW5jZTwvZGl2Pg0KPGRpdj5mb3IgYSBzb2x1dGlvbiwgb3Igc3Vn Z2VzdCBhIG5ldyBzb2x1dGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5BbmR5PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_B697F0AF6F734A9B8F78F58B697072F2junipernet_-- From nobody Fri Dec 11 10:22:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A738B1A8F34 for ; Fri, 11 Dec 2015 10:22:38 -0800 (PST) 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 d_p4ok-BSpmc for ; Fri, 11 Dec 2015 10:22:37 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 9C6631A906C for ; Fri, 11 Dec 2015 10:22:25 -0800 (PST) Received: by lbbcs9 with SMTP id cs9so75052950lbb.1 for ; Fri, 11 Dec 2015 10:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=DIp1aTzbU8M93J83oB9qMQOSVuap23rMoCfAm0KXer0=; b=D8+QymJHAOpKi5C2d7BlTkXwq1BvhBLE9MH17Kk3gBcgx6royCsj4USsvdF6Ai94IS WVrQd5byyWfeYjmDUMtukXpGQdM5mPNbhnqgJNOJKp9y84hRkq66u9UeoadAMlEvpAlJ M7HyBSQNoj7cpg3MBTH9KxP04/9KMOlWWThA6eCAE7yR9/2Cvv7vzhK0ZujD0MExTn5p VZ0Bzf7vnRDmtQoyFHCw5XGQPQwPDEBrfGtU4v+GcPvgLfwSGvFn6W5l8bHRzoamnB9/ /qlPM18uKjqY72Gshz3uv9o4BG2IfaI58Gntx1OEbA+Xld/aWwZCIUFWY9Bn20ejffkO XIwQ== 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=DIp1aTzbU8M93J83oB9qMQOSVuap23rMoCfAm0KXer0=; b=P7nbPeKd467sS/QjJJT1JBu5DegKWHNqMu4YpTkvGBKP6M7NdwNOEfYG/wubdWXGH1 fUQYbEiNJ/2B6WjoGsxNCfJFDUW6n8mao2HEN8mAD/KgMpnv6vQZonLdiSQ95qEKKdCn WvNuH/6Lim+WA8ELjPAaDgWFwpNGiZ1W/0Saza3VNHVdLGXQr+naJ74IH4ZuVSxjBXvK vZyOp6o66z7/ZGuze6G7uu+lLvlOHe2MwzfwagA9SHNUtKPQw1dwJcr2fG9YzSxRB1Xh NKlw/t7/YQKUpCso6x8JnhMV1QnGRMn1+sJXWdqA+GtpbmNE5lpg3H4Cp3/fpwO5v6iF 0pEw== X-Gm-Message-State: ALoCoQnkuhla8UmcASCkcxUXZ4DBA848MuuUONVBcaaPtpwRKUyJIqERn+safyjc5ADDrcMkzpScBAd/+KvnyCkGXF3eryfN1w== MIME-Version: 1.0 X-Received: by 10.112.157.133 with SMTP id wm5mr8391662lbb.65.1449858143710; Fri, 11 Dec 2015 10:22:23 -0800 (PST) Received: by 10.112.144.36 with HTTP; Fri, 11 Dec 2015 10:22:23 -0800 (PST) Date: Fri, 11 Dec 2015 10:22:23 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c259b8a18ad60526a367bd Archived-At: Subject: [Netconf] questions on 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, 11 Dec 2015 18:22:38 -0000 --001a11c259b8a18ad60526a367bd Content-Type: text/plain; charset=UTF-8 Hi, I am trying to understand the YANG Push draft. It seems massively complicated. Has anybody implemented these features in a vendor module? XPath filtering is mandatory to implement. JSON is optional, but JSON is not supported by NETCONF at all so, not sure why this YANG feature 'json' is needed. If a RESTCONF server supports JSON, then HTTP will make that clear to the client. Existing NETCONF notifications allow for a shared implementation strategy, meaning the generated events could be stored in a common buffer, and individual subscription filters can be applied to the buffer. With this draft, every client can ask for 1 or more very different event streams, making it difficult to use a common event-store. I cannot find the controls that cause plain updated (e.g., my-sub on pg 14) vs. a datastore-changes (my-on-change-sub on same page). Why should the client need different element names (datastore-contents vs. datastore-changes-xml). I cannot find the controls that would cause YANG Patch formatted events to be sent. There seem to be many ways to do the same thing, all of them mandatory-to-implement by the server. The notification definitions need a lot of work. There should never be "choice XML or JSON" in a YANG module. The YANG definition is conceptual. Only protocol messages between peers have any encoding at all. Also, the use of leaf instead of anyxml (or anydata) is incorrect. The section on reliability seems a little vague. If a server is getting 1000 edits a second, and the client subscribes to hourly YANG Patch updates (which all need to be applied or the replicated datastore will be incorrect) then the server will buffer and then send that client 3.6 million edits at once. Seems just a bit resource-intensive to me. The impact on network congestion could be dramatic. Since the server might not have infinite resources, what does it do it if it cannot buffer new edits? Seems to me that a sequence-id would allow the client to know there are gaps, but the draft insists that no notifications can get dropped so a sequence-id is not needed. If a subscription is altered in between update intervals, does the server toss all the data it had collected and start fresh with the new parameters? Does the interval based on start-time re-synch to the modify-time? (i.e., toss previous interval completely and start a new interval?) Andy --001a11c259b8a18ad60526a367bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to understand the YANG = Push draft.
It seems massively complicated.=C2=A0 Has anybody imp= lemented
these features in a vendor module?=C2=A0 XPath filtering=
is mandatory to implement.=C2=A0 JSON is optional, but JSON
is not supported by NETCONF at all so, not sure why
this YA= NG feature 'json' is needed.=C2=A0 If a RESTCONF server supports
JSON, then HTTP will make that clear to the client.

<= /div>
Existing NETCONF notifications allow for a shared
imple= mentation strategy, meaning the generated events
could be stored = in a common buffer, and individual subscription
filters can be ap= plied to the buffer.=C2=A0 With this draft, every client
can ask = for 1 or more very different event streams, making it
difficult t= o use a common event-store.

I cannot find the cont= rols that cause plain updated (e.g., my-sub on pg 14)
vs. a datas= tore-changes (my-on-change-sub on same page).
Why should the clie= nt need different element names
(datastore-contents vs. datastore= -changes-xml).=C2=A0 I cannot find
the controls that would cause = YANG Patch formatted events to be sent.
There seem to be many way= s to do the same thing, all of them
mandatory-to-implement by the= server.

The notification definitions need a lot o= f work.
There should never be "choice XML or JSON" in a= YANG module.
The YANG definition is conceptual.=C2=A0 Only proto= col messages
between peers have any encoding at all. Also, the us= e of leaf
instead of anyxml (or anydata) is incorrect.
=
The section on reliability seems a little vague.
I= f a server is getting 1000 edits a second, and the client
subscri= bes to hourly YANG Patch updates (which all need to be applied
or= the replicated datastore will be incorrect) then the server will
buffer and then send that client 3.6 million edits at once.
Seem= s just a bit resource-intensive to me. The impact on network
cong= estion could be dramatic.

Since the server might n= ot have infinite resources, what does it
do it if it cannot buffe= r new edits?=C2=A0 Seems to me that a sequence-id
would allow the= client to know there are gaps, but the draft insists
that no not= ifications can get dropped so a sequence-id is not needed.

If a subscription is altered in between update intervals, does
the server toss all the data it had collected and start fresh
<= div>with the new parameters?=C2=A0 Does the interval based on start-time
re-synch to the modify-time? (i.e., toss previous interval complete= ly
and start a new interval?)


=

Andy



=
--001a11c259b8a18ad60526a367bd-- From nobody Fri Dec 11 19:48: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 933501ACE59 for ; Fri, 11 Dec 2015 19:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, 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 WxSD1C4mK9an for ; Fri, 11 Dec 2015 19:48:25 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C601ACE4C for ; Fri, 11 Dec 2015 19:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25660; q=dns/txt; s=iport; t=1449892104; x=1451101704; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sr4VadPdafmCXT0QpJ8QRyBama5+U1QKh39n7WFsxZc=; b=TELLaKRlMiKZKJjAoOD/0d/OKjhr2SXpog2qyn95FbVdjMPGH+8gEfkO ugMiuWH/sSPFbLxRMuh/HQaBis7DO2ZOXhibMroPakk9ylnaTYrCYv1pi 28znm7fAe4wOSpvMfADXGbIjaMTGvSYisPnCe4qI5Z+fUlf9+6msl4pD0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgBRmGtW/5JdJa1egm5MU24GvSwBD?= =?us-ascii?q?YFjhg4CHIEKOBQBAQEBAQEBgQqENAEBAQQjCkwQAgEIEQQBAQ4aAwICAjAUCQg?= =?us-ascii?q?CBAENBQiIJ6wfkWABAQEBAQEBAQEBAQEBAQEBAQEBAQEYi1OENQ0mCSCCZoFJB?= =?us-ascii?q?ZMDg3ABjTyBYpJUhG6DcwEfAQFChARyhBxCgQgBAQE?= X-IronPort-AV: E=Sophos; i="5.20,416,1444694400"; d="scan'208,217"; a="57656818" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2015 03:48:23 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tBC3mMRJ006097 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 12 Dec 2015 03:48:23 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 11 Dec 2015 22:48:22 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 11 Dec 2015 22:48:22 -0500 From: "Alexander Clemm (alex)" To: Andy Bierman , Netconf Thread-Topic: [Netconf] questions on draft-ietf-netconf-yang-push-00 Thread-Index: AQHRNEDwCuwOg+XrskS2OZYEZZZbRp7GqapA Date: Sat, 12 Dec 2015 03:48:22 +0000 Message-ID: <64c05f5d3152467da6412d8bbd0d8e76@XCH-RTP-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.204.222] Content-Type: multipart/alternative; boundary="_000_64c05f5d3152467da6412d8bbd0d8e76XCHRTP001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] questions on 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: Sat, 12 Dec 2015 03:48:27 -0000 --_000_64c05f5d3152467da6412d8bbd0d8e76XCHRTP001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KdGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiAgUmVzcG9uc2VzIGlubGlu ZS4NCg0KSGF2ZSBhIG5pY2Ugd2Vla2VuZA0KLS0tIEFsZXgNCkZyb206IE5ldGNvbmYgW21haWx0 bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNl bnQ6IEZyaWRheSwgRGVjZW1iZXIgMTEsIDIwMTUgMTA6MjIgQU0NClRvOiBOZXRjb25mIDxuZXRj b25mQGlldGYub3JnPg0KU3ViamVjdDogW05ldGNvbmZdIHF1ZXN0aW9ucyBvbiBkcmFmdC1pZXRm LW5ldGNvbmYteWFuZy1wdXNoLTAwDQoNCkhpLA0KDQpJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5k IHRoZSBZQU5HIFB1c2ggZHJhZnQuDQpJdCBzZWVtcyBtYXNzaXZlbHkgY29tcGxpY2F0ZWQuICBI YXMgYW55Ym9keSBpbXBsZW1lbnRlZA0KdGhlc2UgZmVhdHVyZXMgaW4gYSB2ZW5kb3IgbW9kdWxl PyAgWFBhdGggZmlsdGVyaW5nDQppcyBtYW5kYXRvcnkgdG8gaW1wbGVtZW50LiAgSlNPTiBpcyBv cHRpb25hbCwgYnV0IEpTT04NCmlzIG5vdCBzdXBwb3J0ZWQgYnkgTkVUQ09ORiBhdCBhbGwgc28s IG5vdCBzdXJlIHdoeQ0KdGhpcyBZQU5HIGZlYXR1cmUgJ2pzb24nIGlzIG5lZWRlZC4gIElmIGEg UkVTVENPTkYgc2VydmVyIHN1cHBvcnRzDQpKU09OLCB0aGVuIEhUVFAgd2lsbCBtYWtlIHRoYXQg Y2xlYXIgdG8gdGhlIGNsaWVudC4NCg0KPEFMRVg+IFRoZXJlIGFyZSBhIHByb2JhYmx5IGEgbnVt YmVyIG9mIGNsYXJpZmljYXRpb25zIHdlIG5lZWQgdG8gbWFrZS4gICBXZSB3aWxsIGVkaXQgdGhl IGRvY3VtZW50IHRvIGNsYXJpZnkgdGhlIHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgY29udHJvbCBt b2RlbCAod2hlcmUgd2UgY29uZmlndXJlIHN1YnNjcmlwdGlvbnMpLCBhbmQgdGhlIGRlZmluaXRp b24gaG93IHRvIHJlbmRlciB0aGUgdXBkYXRlcyBhbmQgd2hpY2ggdHJhbnNwb3J0IHRvIHVzZSAo dGhpcyBpcyB3aGVyZSB0aGUgcG9zc2liaWxpdHkgb2Ygc3VwcG9ydGluZyBkaWZmZXJlbnQgZW5j b2RpbmdzIGNvbWUgaW4uDQpUaGVyZSBpcyBjdXJyZW50bHkgYW4gT3BlbiBEYXlsaWdodCBwcm9q ZWN0IGluIHByb2dyZXNzIHRoYXQgcHJvdmlkZXMgYSBjbGllbnQgaW1wbGVtZW50YXRpb24gb2Yg dGhpcyBmb3IgdGhlIHVwY29taW5nIEJlcnlsbGl1bSByZWxlYXNlLg0KTWFraW5nIFhQYXRoIG9w dGlvbmFsIGFuZCBzdWJ0cmVlIG1hbmRhdG9yIGFzIGEgZmlsdGVyIG1ha2VzIHNlbnNlLg0KPC9B TEVYPg0KDQpFeGlzdGluZyBORVRDT05GIG5vdGlmaWNhdGlvbnMgYWxsb3cgZm9yIGEgc2hhcmVk DQppbXBsZW1lbnRhdGlvbiBzdHJhdGVneSwgbWVhbmluZyB0aGUgZ2VuZXJhdGVkIGV2ZW50cw0K Y291bGQgYmUgc3RvcmVkIGluIGEgY29tbW9uIGJ1ZmZlciwgYW5kIGluZGl2aWR1YWwgc3Vic2Ny aXB0aW9uDQpmaWx0ZXJzIGNhbiBiZSBhcHBsaWVkIHRvIHRoZSBidWZmZXIuICBXaXRoIHRoaXMg ZHJhZnQsIGV2ZXJ5IGNsaWVudA0KY2FuIGFzayBmb3IgMSBvciBtb3JlIHZlcnkgZGlmZmVyZW50 IGV2ZW50IHN0cmVhbXMsIG1ha2luZyBpdA0KZGlmZmljdWx0IHRvIHVzZSBhIGNvbW1vbiBldmVu dC1zdG9yZS4NCg0KPEFMRVg+IEZvciBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiwgdGhlIHNpdHVh dGlvbiBpcyBubyBkaWZmZXJlbnQgZnJvbSByZWd1bGFyIGdldHMuICBGb3IgYW4gb24tY2hhbmdl LCB5b3UgY291bGQgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBiYXNlZCBvbiBhIGNvbW1vbiBidWZm ZXIgd2l0aCBhbGwgY2hhbmdlcyAob3IgYWxsIGNoYW5nZXMgb24gc3Vic2NyaWJlZCBzdWJ0cmVl cykuDQo8L0FMRVg+DQoNCkkgY2Fubm90IGZpbmQgdGhlIGNvbnRyb2xzIHRoYXQgY2F1c2UgcGxh aW4gdXBkYXRlZCAoZS5nLiwgbXktc3ViIG9uIHBnIDE0KQ0KdnMuIGEgZGF0YXN0b3JlLWNoYW5n ZXMgKG15LW9uLWNoYW5nZS1zdWIgb24gc2FtZSBwYWdlKS4NCldoeSBzaG91bGQgdGhlIGNsaWVu dCBuZWVkIGRpZmZlcmVudCBlbGVtZW50IG5hbWVzDQooZGF0YXN0b3JlLWNvbnRlbnRzIHZzLiBk YXRhc3RvcmUtY2hhbmdlcy14bWwpLiAgSSBjYW5ub3QgZmluZA0KdGhlIGNvbnRyb2xzIHRoYXQg d291bGQgY2F1c2UgWUFORyBQYXRjaCBmb3JtYXR0ZWQgZXZlbnRzIHRvIGJlIHNlbnQuDQpUaGVy ZSBzZWVtIHRvIGJlIG1hbnkgd2F5cyB0byBkbyB0aGUgc2FtZSB0aGluZywgYWxsIG9mIHRoZW0N Cm1hbmRhdG9yeS10by1pbXBsZW1lbnQgYnkgdGhlIHNlcnZlci4NCg0KPEFMRVg+ICBJIGFtIG5v dCBzdXJlIEkgdW5kZXJzdGFuZCB0aGlzIHF1ZXN0aW9uLiAgTm90ZSB0aGVyZSBpcyBhIGRpZmZl cmVuY2UgYmV0d2VlbiBwZXJpb2RpYyBzdWJzY3JpcHRpb24sIGFuZCBvbi1jaGFuZ2Ugc3Vic2Ny aXB0aW9uLiAgRm9yIHBlcmlvZGljLCB3ZSBzZW5kIHRoZSBkYXRhc3RvcmUgY29udGVudHMgbGlr ZSB3ZSB3b3VsZCBmb3IgYSBnZXQuICBGb3IgYW4gb24tY2hhZ2UsIHdlIGRvbuKAmXQgc2VuZCBh bGwgaHRlIGNvbnRlbmN0cy4gIFRvIGZhY2lsaXRhdGUgdGhlIGRpZmZlcmVudGlhdGlvbiwgd2Ug dXNlIGRpZmZlcmVudCBlbGVtZW50cyAod2l0aCBkaWZmZXJlbnQgc2VtYW50aWNzIOKAkyBwZXJp b2RpYyB2cyBvbi1jaGFuZ2UpLg0KPC9BTEVYPg0KDQpUaGUgbm90aWZpY2F0aW9uIGRlZmluaXRp b25zIG5lZWQgYSBsb3Qgb2Ygd29yay4NClRoZXJlIHNob3VsZCBuZXZlciBiZSAiY2hvaWNlIFhN TCBvciBKU09OIiBpbiBhIFlBTkcgbW9kdWxlLg0KVGhlIFlBTkcgZGVmaW5pdGlvbiBpcyBjb25j ZXB0dWFsLiAgT25seSBwcm90b2NvbCBtZXNzYWdlcw0KYmV0d2VlbiBwZWVycyBoYXZlIGFueSBl bmNvZGluZyBhdCBhbGwuIEFsc28sIHRoZSB1c2Ugb2YgbGVhZg0KaW5zdGVhZCBvZiBhbnl4bWwg KG9yIGFueWRhdGEpIGlzIGluY29ycmVjdC4NCg0KPEFMRVg+IFRoaXMgaGFzIHRvIGRvIHdpdGgg c2VwYXJhdGlvbiBiZXR3ZWVuIGNvbnRyb2wgbW9kZWwsIGFuZCBkZWZpbml0aW9uIG9mIHN0cmVh bSBjb250ZW50cy4gIFRoZSBjaG9pY2UgWE1MIG9yIEpTT04gcmVmZXJzIHRvIGEgY29uZmlndXJh YmxlIG9wdGlvbiBhYm91dCBob3cgZGF0YSBzdHJlYW1zIGFyZSBlbmNvZGVkLCBub3QgaG93IHRo ZSBZQU5HIGNvbnRyb2wgbW9kZWwgaXMgcmVwcmVzZW50ZWQuICBXZSBjb3VsZCBoYXZlIG90aGVy IG9wdGlvbnMgaW5jbHVkaW5nIEFTTi4xIEJFUiBhbmQgc3lzbG90IFNEIChTdHJ1Y3R1cmVkIERh dGEpLiAgV2UgbmVlZCB0byBjbGFyaWZ5IHRoaXMgaW4gdGhlIHRoZSBkcmFmdC4gIDwvQUxFWD4N Cg0KVGhlIHNlY3Rpb24gb24gcmVsaWFiaWxpdHkgc2VlbXMgYSBsaXR0bGUgdmFndWUuDQpJZiBh IHNlcnZlciBpcyBnZXR0aW5nIDEwMDAgZWRpdHMgYSBzZWNvbmQsIGFuZCB0aGUgY2xpZW50DQpz dWJzY3JpYmVzIHRvIGhvdXJseSBZQU5HIFBhdGNoIHVwZGF0ZXMgKHdoaWNoIGFsbCBuZWVkIHRv IGJlIGFwcGxpZWQNCm9yIHRoZSByZXBsaWNhdGVkIGRhdGFzdG9yZSB3aWxsIGJlIGluY29ycmVj dCkgdGhlbiB0aGUgc2VydmVyIHdpbGwNCmJ1ZmZlciBhbmQgdGhlbiBzZW5kIHRoYXQgY2xpZW50 IDMuNiBtaWxsaW9uIGVkaXRzIGF0IG9uY2UuDQpTZWVtcyBqdXN0IGEgYml0IHJlc291cmNlLWlu dGVuc2l2ZSB0byBtZS4gVGhlIGltcGFjdCBvbiBuZXR3b3JrDQpjb25nZXN0aW9uIGNvdWxkIGJl IGRyYW1hdGljLg0KDQo8QUxFWD4gTm90ZSBhZ2FpbiB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBw ZXJpb2RpYyBhbmQgb24tY2hhbmdlLiAgRm9yIHBlcmlvZGljLCBubyBuZWVkIGZvciBidWZmZXJp bmcuICBGb3Igb24tY2hhbmdlLCB0aGluZ3MgYXJlIHNlbnQgaW1tZWRpYXRlbHksIGJhciBkYW1w ZW5pbmcgcGVyaW9kcyAoZXhwZWN0ZWQgdG8gYmUgc2hvcnQpLiAgVXBkYXRlcyBpbiB0aGF0IGNh c2Ugd2lsbCBpbmNsdWRlIHRoZSBsYXRlc3QgdmFsdWUgKGkuZS4gbm90IDMuNiBtaWxsaW9uIGVk aXRzLCB1bmxlc3MgdGhlcmUgYXJlIDMuNiBtaWxsaW9uIG9iamVjdHMgdGhhdCB3ZXJlIGVkaXRl ZDsgZGFtcGVuaW5nIHBlcmlvZHMgYXJlIGluIGZhY3QgaW50ZW5kZWQgdG8gbGltaXQgYW5kIHJl ZHVjZSB0aGUgbnVtYmVyIG9mIHVwZGF0ZXMgdGhhdCBtaWdodCBvY2N1ciBvdmVyIGEgcGVyaW9k IG9mIHRpbWUpLiAgQnVmZmVycyBwcm9iYWJseSBuZWVkIHRvIGJlIGRpbWVuc2lvbmVkIHByb3Bv cnRpb25hbGx5IHRvIHRoZSBzaXplIG9mIHRoZSBkYXRhIHRyZWUsIHRoYXTigJlzIHRydWUuDQo8 L0FMRVg+DQoNCg0KU2luY2UgdGhlIHNlcnZlciBtaWdodCBub3QgaGF2ZSBpbmZpbml0ZSByZXNv dXJjZXMsIHdoYXQgZG9lcyBpdA0KZG8gaXQgaWYgaXQgY2Fubm90IGJ1ZmZlciBuZXcgZWRpdHM/ ICBTZWVtcyB0byBtZSB0aGF0IGEgc2VxdWVuY2UtaWQNCndvdWxkIGFsbG93IHRoZSBjbGllbnQg dG8ga25vdyB0aGVyZSBhcmUgZ2FwcywgYnV0IHRoZSBkcmFmdCBpbnNpc3RzDQp0aGF0IG5vIG5v dGlmaWNhdGlvbnMgY2FuIGdldCBkcm9wcGVkIHNvIGEgc2VxdWVuY2UtaWQgaXMgbm90IG5lZWRl ZC4NCg0KSWYgYSBzdWJzY3JpcHRpb24gaXMgYWx0ZXJlZCBpbiBiZXR3ZWVuIHVwZGF0ZSBpbnRl cnZhbHMsIGRvZXMNCnRoZSBzZXJ2ZXIgdG9zcyBhbGwgdGhlIGRhdGEgaXQgaGFkIGNvbGxlY3Rl ZCBhbmQgc3RhcnQgZnJlc2gNCndpdGggdGhlIG5ldyBwYXJhbWV0ZXJzPyAgRG9lcyB0aGUgaW50 ZXJ2YWwgYmFzZWQgb24gc3RhcnQtdGltZQ0KcmUtc3luY2ggdG8gdGhlIG1vZGlmeS10aW1lPyAo aS5lLiwgdG9zcyBwcmV2aW91cyBpbnRlcnZhbCBjb21wbGV0ZWx5DQphbmQgc3RhcnQgYSBuZXcg aW50ZXJ2YWw/KQ0KDQo8QUxFWD4gVGhpcyBpcyBhIGNvcm5lciBjb25kaXRpb24gd2hpY2ggd2ls bCBuZWVkIGNsYXJpZmljYXRpb24uDQo8L0FMRVg+DQoNCg0KQW5keQ0KDQoNCg0K --_000_64c05f5d3152467da6412d8bbd0d8e76XCHRTP001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQW5keSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoYW5rIHlvdSBmb3IgeW91ciBjb21t ZW50cy4mbmJzcDsgUmVzcG9uc2VzIGlubGluZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGF2ZSBhIG5pY2Ugd2Vla2VuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5l dGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDExLCAy MDE1IDEwOjIyIEFNPGJyPg0KPGI+VG86PC9iPiBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbTmV0Y29uZl0gcXVlc3Rpb25zIG9uIGRyYWZ0LWll dGYtbmV0Y29uZi15YW5nLXB1c2gtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg YW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIFlBTkcgUHVzaCBkcmFmdC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIG1hc3NpdmVs eSBjb21wbGljYXRlZC4mbmJzcDsgSGFzIGFueWJvZHkgaW1wbGVtZW50ZWQ8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZXNlIGZlYXR1cmVzIGlu IGEgdmVuZG9yIG1vZHVsZT8mbmJzcDsgWFBhdGggZmlsdGVyaW5nPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcyBtYW5kYXRvcnkgdG8gaW1wbGVt ZW50LiZuYnNwOyBKU09OIGlzIG9wdGlvbmFsLCBidXQgSlNPTjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgbm90IHN1cHBvcnRlZCBieSBORVRD T05GIGF0IGFsbCBzbywgbm90IHN1cmUgd2h5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGlzIFlBTkcgZmVhdHVyZSAnanNvbicgaXMgbmVlZGVk LiZuYnNwOyBJZiBhIFJFU1RDT05GIHNlcnZlciBzdXBwb3J0czxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SlNPTiwgdGhlbiBIVFRQIHdpbGwgbWFr ZSB0aGF0IGNsZWFyIHRvIHRoZSBjbGllbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZsdDtBTEVYJmd0OyZuYnNwO1RoZXJlIGFyZSBhIHByb2JhYmx5 IGEgbnVtYmVyIG9mIGNsYXJpZmljYXRpb25zIHdlIG5lZWQgdG8gbWFrZS4mbmJzcDsgJm5ic3A7 V2Ugd2lsbCBlZGl0IHRoZSBkb2N1bWVudCB0byBjbGFyaWZ5IHRoZSBzZXBhcmF0aW9uIGJldHdl ZW4gdGhlIGNvbnRyb2wgbW9kZWwgKHdoZXJlDQogd2UgY29uZmlndXJlIHN1YnNjcmlwdGlvbnMp LCBhbmQgdGhlIGRlZmluaXRpb24gaG93IHRvIHJlbmRlciB0aGUgdXBkYXRlcyBhbmQgd2hpY2gg dHJhbnNwb3J0IHRvIHVzZSAodGhpcyBpcyB3aGVyZSB0aGUgcG9zc2liaWxpdHkgb2Ygc3VwcG9y dGluZyBkaWZmZXJlbnQgZW5jb2RpbmdzIGNvbWUgaW4uJm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgY3VycmVudGx5IGFu IE9wZW4gRGF5bGlnaHQgcHJvamVjdCBpbiBwcm9ncmVzcyB0aGF0IHByb3ZpZGVzIGEgY2xpZW50 IGltcGxlbWVudGF0aW9uIG9mIHRoaXMgZm9yIHRoZSB1cGNvbWluZyBCZXJ5bGxpdW0gcmVsZWFz ZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NYWtpbmcgWFBhdGggb3B0aW9uYWwgYW5kIHN1 YnRyZWUgbWFuZGF0b3IgYXMgYSBmaWx0ZXIgbWFrZXMgc2Vuc2UuJm5ic3A7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jmx0Oy9BTEVYJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FeGlzdGluZyBORVRDT05GIG5vdGlmaWNhdGlvbnMg YWxsb3cgZm9yIGEgc2hhcmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5pbXBsZW1lbnRhdGlvbiBzdHJhdGVneSwgbWVhbmluZyB0aGUgZ2VuZXJh dGVkIGV2ZW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Y291bGQgYmUgc3RvcmVkIGluIGEgY29tbW9uIGJ1ZmZlciwgYW5kIGluZGl2aWR1YWwg c3Vic2NyaXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5maWx0ZXJzIGNhbiBiZSBhcHBsaWVkIHRvIHRoZSBidWZmZXIuJm5ic3A7IFdpdGgg dGhpcyBkcmFmdCwgZXZlcnkgY2xpZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5jYW4gYXNrIGZvciAxIG9yIG1vcmUgdmVyeSBkaWZmZXJlbnQg ZXZlbnQgc3RyZWFtcywgbWFraW5nIGl0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5kaWZmaWN1bHQgdG8gdXNlIGEgY29tbW9uIGV2ZW50LXN0b3Jl LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7QUxFWCZndDsgRm9yIGEg cGVyaW9kaWMgc3Vic2NyaXB0aW9uLCB0aGUgc2l0dWF0aW9uIGlzIG5vIGRpZmZlcmVudCBmcm9t IHJlZ3VsYXIgZ2V0cy4mbmJzcDsgRm9yIGFuIG9uLWNoYW5nZSwgeW91IGNvdWxkIGhhdmUgYW4g aW1wbGVtZW50YXRpb24gYmFzZWQgb24gYSBjb21tb24gYnVmZmVyDQogd2l0aCBhbGwgY2hhbmdl cyAob3IgYWxsIGNoYW5nZXMgb24gc3Vic2NyaWJlZCBzdWJ0cmVlcykuJm5ic3A7IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbHQ7L0FMRVgmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNhbm5vdCBmaW5kIHRoZSBjb250cm9scyB0 aGF0IGNhdXNlIHBsYWluIHVwZGF0ZWQgKGUuZy4sIG15LXN1YiBvbiBwZyAxNCk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnZzLiBhIGRhdGFzdG9y ZS1jaGFuZ2VzIChteS1vbi1jaGFuZ2Utc3ViIG9uIHNhbWUgcGFnZSkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgc2hvdWxkIHRoZSBjbGll bnQgbmVlZCBkaWZmZXJlbnQgZWxlbWVudCBuYW1lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGRhdGFzdG9yZS1jb250ZW50cyB2cy4gZGF0YXN0 b3JlLWNoYW5nZXMteG1sKS4mbmJzcDsgSSBjYW5ub3QgZmluZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGNvbnRyb2xzIHRoYXQgd291bGQg Y2F1c2UgWUFORyBQYXRjaCBmb3JtYXR0ZWQgZXZlbnRzIHRvIGJlIHNlbnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBzZWVtIHRvIGJl IG1hbnkgd2F5cyB0byBkbyB0aGUgc2FtZSB0aGluZywgYWxsIG9mIHRoZW08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1hbmRhdG9yeS10by1pbXBs ZW1lbnQgYnkgdGhlIHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jmx0O0FMRVgmZ3Q7Jm5ic3A7IEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5k IHRoaXMgcXVlc3Rpb24uJm5ic3A7IE5vdGUgdGhlcmUgaXMgYSBkaWZmZXJlbmNlIGJldHdlZW4g cGVyaW9kaWMgc3Vic2NyaXB0aW9uLCBhbmQgb24tY2hhbmdlIHN1YnNjcmlwdGlvbi4mbmJzcDsg Rm9yIHBlcmlvZGljLCB3ZSBzZW5kDQogdGhlIGRhdGFzdG9yZSBjb250ZW50cyBsaWtlIHdlIHdv dWxkIGZvciBhIGdldC4mbmJzcDsgRm9yIGFuIG9uLWNoYWdlLCB3ZSBkb27igJl0IHNlbmQgYWxs IGh0ZSBjb250ZW5jdHMuJm5ic3A7IFRvIGZhY2lsaXRhdGUgdGhlIGRpZmZlcmVudGlhdGlvbiwg d2UgdXNlIGRpZmZlcmVudCBlbGVtZW50cyAod2l0aCBkaWZmZXJlbnQgc2VtYW50aWNzIOKAkyBw ZXJpb2RpYyB2cyBvbi1jaGFuZ2UpLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZsdDsvQUxF WCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5vdGlmaWNhdGlvbiBkZWZpbml0 aW9ucyBuZWVkIGEgbG90IG9mIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBzaG91bGQgbmV2ZXIgYmUgJnF1b3Q7Y2hvaWNlIFhN TCBvciBKU09OJnF1b3Q7IGluIGEgWUFORyBtb2R1bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgWUFORyBkZWZpbml0aW9uIGlzIGNvbmNl cHR1YWwuJm5ic3A7IE9ubHkgcHJvdG9jb2wgbWVzc2FnZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJldHdlZW4gcGVlcnMgaGF2ZSBhbnkgZW5j b2RpbmcgYXQgYWxsLiBBbHNvLCB0aGUgdXNlIG9mIGxlYWY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluc3RlYWQgb2YgYW55eG1sIChvciBhbnlk YXRhKSBpcyBpbmNvcnJlY3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtB TEVYJmd0OyBUaGlzIGhhcyB0byBkbyB3aXRoIHNlcGFyYXRpb24gYmV0d2VlbiBjb250cm9sIG1v ZGVsLCBhbmQgZGVmaW5pdGlvbiBvZiBzdHJlYW0gY29udGVudHMuJm5ic3A7IFRoZSBjaG9pY2Ug WE1MIG9yIEpTT04gcmVmZXJzIHRvIGEgY29uZmlndXJhYmxlIG9wdGlvbiBhYm91dCBob3cgZGF0 YSBzdHJlYW1zIGFyZSBlbmNvZGVkLCBub3QgaG93IHRoZSBZQU5HIGNvbnRyb2wNCiBtb2RlbCBp cyByZXByZXNlbnRlZC4mbmJzcDsgV2UgY291bGQgaGF2ZSBvdGhlciBvcHRpb25zIGluY2x1ZGlu ZyBBU04uMSBCRVIgYW5kIHN5c2xvdCBTRCAoU3RydWN0dXJlZCBEYXRhKS4mbmJzcDsgV2UgbmVl ZCB0byBjbGFyaWZ5IHRoaXMgaW4gdGhlIHRoZSBkcmFmdC4mbmJzcDsgJmx0Oy9BTEVYJmd0Ozwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlY3Rpb24gb24gcmVsaWFi aWxpdHkgc2VlbXMgYSBsaXR0bGUgdmFndWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhIHNlcnZlciBpcyBnZXR0aW5nIDEwMDAgZWRpdHMg YSBzZWNvbmQsIGFuZCB0aGUgY2xpZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5zdWJzY3JpYmVzIHRvIGhvdXJseSBZQU5HIFBhdGNoIHVwZGF0 ZXMgKHdoaWNoIGFsbCBuZWVkIHRvIGJlIGFwcGxpZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9yIHRoZSByZXBsaWNhdGVkIGRhdGFzdG9yZSB3 aWxsIGJlIGluY29ycmVjdCkgdGhlbiB0aGUgc2VydmVyIHdpbGw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1ZmZlciBhbmQgdGhlbiBzZW5kIHRo YXQgY2xpZW50IDMuNiBtaWxsaW9uIGVkaXRzIGF0IG9uY2UuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWVtcyBqdXN0IGEgYml0IHJlc291cmNl LWludGVuc2l2ZSB0byBtZS4gVGhlIGltcGFjdCBvbiBuZXR3b3JrPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb25nZXN0aW9uIGNvdWxkIGJlIGRy YW1hdGljLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7QUxFWCZndDsg Tm90ZSBhZ2FpbiB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBwZXJpb2RpYyBhbmQgb24tY2hhbmdl LiZuYnNwOyBGb3IgcGVyaW9kaWMsIG5vIG5lZWQgZm9yIGJ1ZmZlcmluZy4mbmJzcDsgRm9yIG9u LWNoYW5nZSwgdGhpbmdzIGFyZSBzZW50IGltbWVkaWF0ZWx5LCBiYXIgZGFtcGVuaW5nDQogcGVy aW9kcyAoZXhwZWN0ZWQgdG8gYmUgc2hvcnQpLiZuYnNwOyBVcGRhdGVzIGluIHRoYXQgY2FzZSB3 aWxsIGluY2x1ZGUgdGhlIGxhdGVzdCB2YWx1ZSAoaS5lLiBub3QgMy42IG1pbGxpb24gZWRpdHMs IHVubGVzcyB0aGVyZSBhcmUgMy42IG1pbGxpb24gb2JqZWN0cyB0aGF0IHdlcmUgZWRpdGVkOyBk YW1wZW5pbmcgcGVyaW9kcyBhcmUgaW4gZmFjdCBpbnRlbmRlZCB0byBsaW1pdCBhbmQgcmVkdWNl IHRoZSBudW1iZXIgb2YgdXBkYXRlcyB0aGF0IG1pZ2h0DQogb2NjdXIgb3ZlciBhIHBlcmlvZCBv ZiB0aW1lKS4mbmJzcDsgQnVmZmVycyBwcm9iYWJseSBuZWVkIHRvIGJlIGRpbWVuc2lvbmVkIHBy b3BvcnRpb25hbGx5IHRvIHRoZSBzaXplIG9mIHRoZSBkYXRhIHRyZWUsIHRoYXTigJlzIHRydWUu Jm5ic3A7ICZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZsdDsvQUxFWCZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSB0aGUgc2VydmVyIG1pZ2h0IG5vdCBoYXZl IGluZmluaXRlIHJlc291cmNlcywgd2hhdCBkb2VzIGl0PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kbyBpdCBpZiBpdCBjYW5ub3QgYnVmZmVyIG5l dyBlZGl0cz8mbmJzcDsgU2VlbXMgdG8gbWUgdGhhdCBhIHNlcXVlbmNlLWlkPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3VsZCBhbGxvdyB0aGUg Y2xpZW50IHRvIGtub3cgdGhlcmUgYXJlIGdhcHMsIGJ1dCB0aGUgZHJhZnQgaW5zaXN0czxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdCBubyBu b3RpZmljYXRpb25zIGNhbiBnZXQgZHJvcHBlZCBzbyBhIHNlcXVlbmNlLWlkIGlzIG5vdCBuZWVk ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PklmIGEgc3Vic2NyaXB0aW9uIGlzIGFsdGVyZWQgaW4gYmV0d2VlbiB1cGRhdGUgaW50ZXJ2YWxz LCBkb2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij50aGUgc2VydmVyIHRvc3MgYWxsIHRoZSBkYXRhIGl0IGhhZCBjb2xsZWN0ZWQgYW5kIHN0YXJ0 IGZyZXNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij53aXRoIHRoZSBuZXcgcGFyYW1ldGVycz8mbmJzcDsgRG9lcyB0aGUgaW50ZXJ2YWwgYmFzZWQg b24gc3RhcnQtdGltZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+cmUtc3luY2ggdG8gdGhlIG1vZGlmeS10aW1lPyAoaS5lLiwgdG9zcyBwcmV2aW91 cyBpbnRlcnZhbCBjb21wbGV0ZWx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5hbmQgc3RhcnQgYSBuZXcgaW50ZXJ2YWw/KTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7QUxFWCZndDsgVGhpcyBpcyBh IGNvcm5lciBjb25kaXRpb24gd2hpY2ggd2lsbCBuZWVkIGNsYXJpZmljYXRpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZsdDsvQUxFWCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_64c05f5d3152467da6412d8bbd0d8e76XCHRTP001ciscocom_-- From nobody Mon Dec 14 10:14:24 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 7101D1B2B36; Mon, 14 Dec 2015 10:14:23 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151214181423.18087.76426.idtracker@ietfa.amsl.com> Date: Mon, 14 Dec 2015 10:14:23 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-14.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, 14 Dec 2015 18:14:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-14.txt Pages : 17 Date : 2015-12-14 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-14 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 Dec 14 10:39:43 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 788C61B2D47; Mon, 14 Dec 2015 10:39:37 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151214183937.15686.93318.idtracker@ietfa.amsl.com> Date: Mon, 14 Dec 2015 10:39:37 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-15.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, 14 Dec 2015 18:39:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-15.txt Pages : 14 Date : 2015-12-14 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-15 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 Dec 14 10:46: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 0317C1B2D60 for ; Mon, 14 Dec 2015 10:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuLWqY_ANMVk for ; Mon, 14 Dec 2015 10:46:34 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E531B2D62 for ; Mon, 14 Dec 2015 10:46:34 -0800 (PST) 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.355.16; Mon, 14 Dec 2015 18:46: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.0355.012; Mon, 14 Dec 2015 18:46:17 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-15.txt Thread-Index: AQHRNp7jtder3qpZTU6/1CkrtxKpvp7Kfl0A Date: Mon, 14 Dec 2015 18:46:17 +0000 Message-ID: <4BA3169D-D646-4AF2-9B31-4025EE0DEF1C@juniper.net> References: <20151214183937.15686.93318.idtracker@ietfa.amsl.com> In-Reply-To: <20151214183937.15686.93318.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.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:FtDBAP01EvxereslLSAuO8h7bbpUcQ+fsRrrjVbAnCn5o8u7nc94w5AUqkxBt+yDSmB6GEiOBtiUfR2TnbvoOH0VcNyHL73XOLJtqmEs5Oo7Lv87wxeAPxpekZrV2cEUXT9domkpwy7qrnIRRCO5cw==; 24:ghnnlKBFI0OI24NrzpYc9pyRj7Ebc9Q4xP5OLdiq9l5SKoGEwk/IkKqf1G1TethW5wybtgY3M/yknd2/Y20Q4Jd38QCXnNkE7zbfiDLahPk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; 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)(10201501046); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0790FB1F33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(377424004)(24454002)(479174004)(199003)(189002)(110136002)(106356001)(189998001)(106116001)(36756003)(4001350100001)(105586002)(87936001)(10400500002)(5004730100002)(5001960100002)(86362001)(107886002)(33656002)(19580405001)(81156007)(19580395003)(99286002)(92566002)(2351001)(2950100001)(66066001)(83506001)(15975445007)(2900100001)(82746002)(101416001)(11100500001)(2501003)(5002640100001)(83716003)(97736004)(77096005)(54356999)(450100001)(102836003)(6116002)(76176999)(1730700002)(50986999)(1096002)(1220700001)(40100003)(586003)(3846002)(5008740100001)(230783001)(122556002)(4001150100001)(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: <00DACFF8A8E9074E91968858900EE3BB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2015 18:46:17.1072 (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: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-15.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, 14 Dec 2015 18:46:39 -0000 QWxsLA0KDQotMTQgYWRkcmVzc2VzIHRoZSBmaW5hbCBESVNDVVNTIGl0ZW0gZnJvbSBLYXRobGVl biBhbmQgLTE1IHdhcyB0byBjbGVhbiB1cCBhIGZldyBvZGRzIGFuZCBlbmRzLg0KDQpUaGlzIGRy YWZ0IHNob3VsZCBwYXNzIElFU0cgcmV2aWV3IG5leHQgdGltZS4NCg0KQ2hlZXJzLA0KS2VudA0K DQoNCg0KDQoNCg0KT24gMTIvMTQvMTUsIDE6MzkgUE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsg Q29uZmlndXJhdGlvbiBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0 bGUgICAgICAgICAgIDogTkVUQ09ORiBDYWxsIEhvbWUgYW5kIFJFU1RDT05GIENhbGwgSG9tZQ0K PiAgICAgICAgQXV0aG9yICAgICAgICAgIDogS2VudCBXYXRzZW4NCj4JRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0xNS50eHQNCj4JUGFnZXMgICAgICAgICAg IDogMTQNCj4JRGF0ZSAgICAgICAgICAgIDogMjAxNS0xMi0xNA0KPg0KPkFic3RyYWN0Og0KPiAg IFRoaXMgUkZDIHByZXNlbnRzIE5FVENPTkYgQ2FsbCBIb21lIGFuZCBSRVNUQ09ORiBDYWxsIEhv bWUsIHdoaWNoDQo+ICAgZW5hYmxlIGEgTkVUQ09ORiBvciBSRVNUQ09ORiBzZXJ2ZXIgdG8gaW5p dGlhdGUgYSBzZWN1cmUgY29ubmVjdGlvbg0KPiAgIHRvIGEgTkVUQ09ORiBvciBSRVNUQ09ORiBj bGllbnQgcmVzcGVjdGl2ZWx5Lg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUvDQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6 ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMTUNCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMTUNCj4NCj4NCj5QbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPk5ldGNvbmYgbWFpbGluZyBsaXN0DQo+TmV0Y29uZkBpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Mon Dec 14 16:24:07 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 582011A8843; Mon, 14 Dec 2015 16:24:04 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215002404.10921.89403.idtracker@ietfa.amsl.com> Date: Mon, 14 Dec 2015 16:24:04 -0800 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: [Netconf] Kathleen Moriarty's No Objection on draft-ietf-netconf-call-home-15: (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, 15 Dec 2015 00:24:04 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netconf-call-home-15: 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: ---------------------------------------------------------------------- Thank for addressing my prior discuss points! 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 Tue Dec 15 08:39:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E9B1A90C7; Tue, 15 Dec 2015 08:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xqCFCVJ8egTG; Tue, 15 Dec 2015 08:39:23 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C8A1A9091; Tue, 15 Dec 2015 08:31:33 -0800 (PST) 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.355.16; Tue, 15 Dec 2015 16:31:31 +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.0355.012; Tue, 15 Dec 2015 16:31:31 +0000 From: Kent Watsen To: Kathleen Moriarty , The IESG Thread-Topic: Kathleen Moriarty's No Objection on draft-ietf-netconf-call-home-15: (with COMMENT) Thread-Index: AQHRNs7p8Av4L1kTtEWUb3KTR/RGCp7L6qmA Date: Tue, 15 Dec 2015 16:31:30 +0000 Message-ID: References: <20151215002404.10921.89403.idtracker@ietfa.amsl.com> In-Reply-To: <20151215002404.10921.89403.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.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:SBljv89TqxP22Tcsf0WssYFXpkFXcoLlHWkSlH6yTKWdOZ+yNNVdJ4rybb6sjx2vnCDkqBxGA8iMdnPwgRwqfcTuGBGSTm/+/VePbPKdncQKOgA8LZB3oE52GYnu+I3JfcvwutMlEB1jN6dvzCXUtg==; 24:WzGyfLg2vaEQ1EI2SdYOeX8cIw45PzUyyKaV9QEXcrOai+14k4D4sQ/OJvPaQzovY29SKLzNpEWMN1gYDAfThuzcYuECWtC6tt5td7qiC2w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; 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)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 07915F544A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52044002)(164054003)(377454003)(24454002)(479174004)(199003)(189002)(4001350100001)(189998001)(81156007)(105586002)(36756003)(106116001)(5001960100002)(5004730100002)(87936001)(10400500002)(106356001)(33656002)(19580405001)(19580395003)(99286002)(82746002)(2950100001)(15975445007)(92566002)(83506001)(101416001)(66066001)(97736004)(5002640100001)(2900100001)(11100500001)(5001770100001)(83716003)(77096005)(54356999)(1220700001)(102836003)(76176999)(6116002)(3846002)(86362001)(1096002)(586003)(40100003)(122556002)(230783001)(50986999)(5008740100001)(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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2015 16:31:30.9302 (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-chairs@ietf.org" , "draft-ietf-netconf-call-home@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] Kathleen Moriarty's No Objection on draft-ietf-netconf-call-home-15: (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: Tue, 15 Dec 2015 16:39:24 -0000 SGkgS2F0aGxlZW4sDQoNCkkgdGhpbmsgdGhlIENPTU1FTlQgYmVsb3cgaXMgYSBob2xkb3ZlciBm cm9tIE9jdCAyMXN0LiAgSSBiZWxpZXZlIHRoYXQgdGhpcyBjb21tZW50IGlzIGFkZHJlc3NlZCB3 aXRoIHRoZSBjaGFuZ2VzIG1hZGUgdG8gLTE1LCB3aGljaCBub3cgaGFzIHRoaXMgYXQgdGhlIGVu ZCBvZiBTZWN0aW9uIDEuMzoNCg0KICAgSW4gc3VjaCBjaXJjdW1zdGFuY2VzLCBhbGxvd2luZyB0 aGUgU1NIL1RMUyBzZXJ2ZXIgdG8gY29udGFjdCB0aGUNCiAgIFNTSC9UTFMgY2xpZW50IHdvdWxk IG9wZW4gbmV3IHZ1bG5lcmFiaWxpdGllcy4gIEFueSB1c2Ugb2YgY2FsbCBob21lDQogICB3aXRo IFNTSC9UTFMgZm9yIHB1cnBvc2VzIG90aGVyIHRoYW4gTkVUQ09ORiBvciBSRVNUQ09ORiB3aWxs IG5lZWQgYQ0KICAgdGhvcm91Z2ggY29udGV4dHVhbCByaXNrIGFzc2Vzc21lbnQuICBBIHJpc2sg YXNzZXNzbWVudCBmb3IgdGhpcyBSRkMNCiAgIGlzIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uIChTZWN0aW9uIDUpLg0KDQpKdXN0IHdvbmRlcmluZyBpZiB0aGVyZSBpcyBz b21ldGhpbmcgSSBzaG91bGQgZG8gbm93LCBvciBpZiB0aGUgQ09NTUVOVCBpcyBiZWluZyBrZXB0 IG1vcmUgZm9yIHBvc3Rlcml0eT8gIFRoaXMgbWF5IGJlLCBhcyBJIHNlZSBvdGhlciBJRVNHIENP TU1FTlRTIG9uIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0 Y29uZi1jYWxsLWhvbWUvYmFsbG90LywgZXZlbiB0aG91Z2ggLTE1IGFkZHJlc3NlcyB0aGVtIGFz IHdlbGwuICBQbGVhc2UgYWR2aXNlLg0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQoNCg0KT24gMTIv MTQvMTUsIDc6MjQgUE0sICJLYXRobGVlbiBNb3JpYXJ0eSIgPEthdGhsZWVuLk1vcmlhcnR5Lmll dGZAZ21haWwuY29tPiB3cm90ZToNCg0KPkthdGhsZWVuIE1vcmlhcnR5IGhhcyBlbnRlcmVkIHRo ZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPmRyYWZ0LWlldGYtbmV0Y29uZi1jYWxs LWhvbWUtMTU6IE5vIE9iamVjdGlvbg0KPg0KPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPmVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz DQo+aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+UGxlYXNlIHJlZmVy IHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEu aHRtbA0KPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQo+DQo+DQo+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUvDQo+DQo+DQo+DQo+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPlRoYW5rIGZvciBhZGRyZXNz aW5nIG15IHByaW9yIGRpc2N1c3MgcG9pbnRzIQ0KPg0KPg0KPkluIHNlY3Rpb24gMS4zLCBwbGVh c2UgYWRkIGEgc2VudGVuY2UgdGhhdCBwb2ludHMgdG8gdGhlIHRocmVhdC9zZWN1cml0eQ0KPmFu YWx5c2lzIGZvciB1c2Ugb2YgdGhpcyBmdW5jdGlvbiB3aXRoIE5FVENPTkYgYW5kIFJFU1RDT05G IGFmdGVyIHRoZQ0KPmxhc3Qgc2VudGVuY2U6DQo+DQo+ICAgSW4gc3VjaCBjaXJjdW1zdGFuY2Vz LCBhbGxvd2luZyB0aGUgU1NIL1RMUyBzZXJ2ZXIgdG8gY29udGFjdCB0aGUNCj4gICBTU0gvVExT IGNsaWVudCB3b3VsZCBvcGVuIG5ldyB2dWxuZXJhYmlsaXRpZXMuICBBbnkgdXNlIG9mIGNhbGwg aG9tZQ0KPiAgIHdpdGggU1NIL1RMUyBmb3IgcHVycG9zZXMgb3RoZXIgdGhhbiBORVRDT05GIG9y IFJFU1RDT05GIHdpbGwgbmVlZCBhDQo+ICAgdGhvcm91Z2gsIGNvbnRleHR1YWwgc2VjdXJpdHkg YW5hbHlzaXMuDQo+DQo+DQo= From nobody Tue Dec 15 08:43: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 C91CC1A907F; Tue, 15 Dec 2015 08:43:45 -0800 (PST) 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 x7apN0i7SIfU; Tue, 15 Dec 2015 08:43:44 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 1D3FA1A90D9; Tue, 15 Dec 2015 08:41:17 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id l126so2316836wml.1; Tue, 15 Dec 2015 08:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wiwTI6wgW6R6HdmGLKe99i6EMotiEalhApxv/Bh+ryc=; b=hvtpIynP3czr/l62NWqNMAF+0WgNOxbXEhsgKq7zEhh1aB7IIYTiDcysDmvKX1ojh4 G9OwBzmUUdXU2Td8RwUOPKv7eAfdZxc8uz/HvxcjmEtVd8a/GzxSPB+48B4w9n6bKe6h 6wTyV0s5ypcNfjUAZ/cnKDYpTNflsCqf60UMoGUXXo1Gg4eyje0KJjHFiyR9LlPCCYRy N4I4StMxUJk9UGfKJyI/kYFWTqoePKhoFhNFzVnJuj03IdejnaD6Zz2kC7Jb7bAqtyj2 ceIJ/KnkMnjM84DYmHq+gnacf0YZ/19lAcae8IzIXwvZz2+AuR6TsidUb67OQK9QCYDs NoCQ== MIME-Version: 1.0 X-Received: by 10.194.222.195 with SMTP id qo3mr45104323wjc.51.1450197675763; Tue, 15 Dec 2015 08:41:15 -0800 (PST) Received: by 10.28.52.130 with HTTP; Tue, 15 Dec 2015 08:41:15 -0800 (PST) In-Reply-To: References: <20151215002404.10921.89403.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 11:41:15 -0500 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 No Objection on draft-ietf-netconf-call-home-15: (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: Tue, 15 Dec 2015 16:43:46 -0000 Hi Kent, Yes, there is no need to worry about the comment. They don't hold up documents and the responsible AD makes a judgement call whether or not they should even be addressed. I think we are good on this one. Thanks very much for the follow up! Kathleen On Tue, Dec 15, 2015 at 11:31 AM, Kent Watsen wrote: > Hi Kathleen, > > I think the COMMENT below is a holdover from Oct 21st. I believe that th= is comment is addressed with the changes made to -15, which now has this at= the end of Section 1.3: > > 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 risk assessment. A risk assessment for this RFC > is in the Security Considerations section (Section 5). > > Just wondering if there is something I should do now, or if the COMMENT i= s being kept more for posterity? This may be, as I see other IESG COMMENTS= on https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ballot/, = even though -15 addresses them as well. Please advise. > > Thanks, > Kent > > > > > > On 12/14/15, 7:24 PM, "Kathleen Moriarty" wrote: > >>Kathleen Moriarty has entered the following ballot position for >>draft-ietf-netconf-call-home-15: 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: >>---------------------------------------------------------------------- >> >>Thank for addressing my prior discuss points! >> >> >>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. >> >> --=20 Best regards, Kathleen From nobody Tue Dec 15 09:12:00 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 750661A908D; Tue, 15 Dec 2015 09:11:56 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215171156.31642.13554.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 09:11:56 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 17:11:56 -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-09.txt Pages : 104 Date : 2015-12-15 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 15 09:12:52 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 CD93D1A90F4; Tue, 15 Dec 2015 09:12:49 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215171249.31845.21013.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 09:12:49 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 17:12:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-patch-07.txt Pages : 30 Date : 2015-12-15 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 15 09:13:55 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 915FB1A8A3A; Tue, 15 Dec 2015 09:13:52 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151215171352.29604.14526.idtracker@ietfa.amsl.com> Date: Tue, 15 Dec 2015 09:13:52 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-library-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 17:13:52 -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-03.txt Pages : 14 Date : 2015-12-15 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-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-library-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 15 10:13: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 67A141A92EA for ; Tue, 15 Dec 2015 10:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, 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 T4FOxohzq6QI for ; Tue, 15 Dec 2015 10:13:01 -0800 (PST) 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 8A7571A92BB for ; Tue, 15 Dec 2015 10:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1501; q=dns/txt; s=iport; t=1450203180; x=1451412780; h=to:from:subject:message-id:date:mime-version; bh=cXgwe1WVPKBsnix+Qkb4zkMqj72LRN/es8fGojaLz94=; b=gjiBidA75mxdIfEWWoIdtTNNMD932m7QMO3jQMS1qPH9BqNDE3N9zrXW k3Lnyc5rHNpOSWxvEiIsY0xRbypt78d7q52LWra3+ZLfHoqYXIGFSGat7 VT6vM+ifeQJvK05OjDB97C+gmZIN/Li2VXgcfFhlOK2HRTZJGB9M6QiyS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBABPV3BW/xbLJq1ehAzANyOIAAEBA?= =?us-ascii?q?QEBAYELhCszVR8BHRYLAgsDAgECAUsNCAEBiCsOnAWPcJF+AQEBBwEBAQEbBIZ?= =?us-ascii?q?WjHSBSQWWfI1IiSaTdGOEBT2FKAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,433,1444694400"; d="scan'208,217";a="609813054" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2015 18:12:57 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBFICurd026813 for ; Tue, 15 Dec 2015 18:12:56 GMT To: NETCONF From: Benoit Claise Message-ID: <56705828.2040408@cisco.com> Date: Tue, 15 Dec 2015 19:12:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010603040800010706090903" Archived-At: Subject: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Dec 2015 18:13:02 -0000 This is a multi-part message in MIME format. --------------010603040800010706090903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Between the version 11, initially transmitted to the IESG, and the latest version 15, addressing all the DISCUSSes, there were a series of changes. I propose a one week review for those changes , before I sent this document to the RFC-editor queue. If you have a problem with those changes, speak up now. Regards, Benoit --------------010603040800010706090903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Between the version 11, initially transmitted to the IESG, and the latest version 15, addressing all the DISCUSSes, there were a series of changes.
I propose a one week review for those changes, before I sent this document to the RFC-editor queue.
If you have a problem with those changes, speak up now.

Regards, Benoit

--------------010603040800010706090903-- From nobody Tue Dec 15 12:59: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 CB7A51ACDC7; Tue, 15 Dec 2015 12:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bif4ehH7v05v; Tue, 15 Dec 2015 12:58:59 -0800 (PST) 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 4BEDE1ACDC0; Tue, 15 Dec 2015 12:58:58 -0800 (PST) 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 tBFKwuxG023544 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Dec 2015 20:58:56 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id tBFKwtji020526 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2015 21:58:56 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 15 Dec 2015 21:58:55 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.48]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 21:58:56 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 Thread-Index: AdE3eTk+yj/4s/NrQu2LeR6gt3+K2g== Date: Tue, 15 Dec 2015 20:58:55 +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.106] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81986CB02DEMUMBX005nsnin_" 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: 9680 X-purgate-ID: 151667::1450213136-00002C61-5AAA8AC2/0/0 Archived-At: Cc: "i2rs@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org>, "core@ietf.org" , "6lo@ietf.org" <6lo@ietf.org> Subject: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Dec 2015 20:59:05 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81986CB02DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, we hereby issue a WG Last Call for the drafts below: http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt Please review and send your comments to the NETCONF WG mailing list by Janu= ary 22, 2015 EOB PT. The drafts on RESTCONF, YANG patch and YANG library are planned to publish = as standard track documents. As RESTCONF is a major protocol we seek a detailed and thorough review with= in NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned to finalize on January 22th (covering the hol= iday time in between) and APP, INT and RTG area ADs will be informed as wel= l as Core, I2RS, 6lo, and 6tisch WGs are invited to review. Please take your time to review the documents and send your comments to the= NETCONF maillist by the deadline. Please state on NETCONF maillist also explicitly, whether you have read/rev= iewed and whether you support the publication. Furthermore please indicate if you plan to implement or have already implem= entations for RESTCONF and its supplementary drafts. Thank you for your review and kind help getting RESTCONF specifications sta= ble. Best Regards, Mehmet and Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F81986CB02DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NETCONF WG,

 

we hereby issue a WG Last Call for th= e drafts below:

 

http://tools.ietf.org/html/draft-ietf-ne= tconf-restconf-09.txt

http://tools.ietf.org/html/draft-ietf-= netconf-yang-patch-07.txt

http://tools.ietf.org/html/draft-iet= f-netconf-yang-library-03.txt

 

Please review and send your comments = to the NETCONF WG mailing list by January 22, 2015 EOB PT.

 

The drafts on RESTCONF, YANG patch an= d YANG library are planned to publish as standard track documents.

 

As RESTCONF is a major protocol we se= ek a detailed and thorough review within NETCONF WG but also by the related= WGs before publishing.

Therefore the WGLC is planned to fina= lize on January 22th (covering the holiday time in between) and APP, INT an= d RTG area ADs will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to review.

 

Please take your time to review the d= ocuments and send your comments to the NETCONF maillist by the deadline.

Please state on NETCONF maillist also= explicitly, whether you have read/reviewed and whether you support the pub= lication.

Furthermore please indicate if you pl= an to implement or have already implementations for RESTCONF and its supplementary drafts.=

 

Thank you for your review and kind he= lp getting RESTCONF specifications stable.

 

Best Regards,

Mehmet and Mahesh

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F81986CB02DEMUMBX005nsnin_-- From nobody Tue Dec 15 13:17:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE661ACE6E for ; Tue, 15 Dec 2015 13:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b35LmcSd1g1Q for ; Tue, 15 Dec 2015 13:17:25 -0800 (PST) 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 49BE81ACE57 for ; Tue, 15 Dec 2015 13:17:25 -0800 (PST) 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 tBFLHNlW019727 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 15 Dec 2015 21:17:23 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 tBFLHNRp002188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 15 Dec 2015 22:17:23 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.48]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 22:17:22 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 Thread-Index: AdE3eTk+yj/4s/NrQu2LeR6gt3+K2gABKaiQ Date: Tue, 15 Dec 2015 21:17:22 +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.106] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81986CBA6DEMUMBX005nsnin_" 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: 12028 X-purgate-ID: 151667::1450214243-00002C61-FFA1D9B2/0/0 Archived-At: Subject: [Netconf] FW: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Dec 2015 21:17:28 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81986CBA6DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The deadline is for sure January 22, 2016 EOB PT. Mehmet From: Ersue, Mehmet (Nokia - DE/Munich) Sent: Tuesday, December 15, 2015 9:59 PM To: netconf@ietf.org Cc: 'core@ietf.org' ; 'i2rs@ietf.org' ; '6lo@= ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch@ietf.org> Subject: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netcon= f-yang-patch-07 and draft-ietf-netconf-yang-library-03 Dear NETCONF WG, we hereby issue a WG Last Call for the drafts below: http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt Please review and send your comments to the NETCONF WG mailing list by Janu= ary 22, 2015 EOB PT. The drafts on RESTCONF, YANG patch and YANG library are planned to publish = as standard track documents. As RESTCONF is a major protocol we seek a detailed and thorough review with= in NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned to finalize on January 22th (covering the hol= iday time in between) and APP, INT and RTG area ADs will be informed as wel= l as Core, I2RS, 6lo, and 6tisch WGs are invited to review. Please take your time to review the documents and send your comments to the= NETCONF maillist by the deadline. Please state on NETCONF maillist also explicitly, whether you have read/rev= iewed and whether you support the publication. Furthermore please indicate if you plan to implement or have already implem= entations for RESTCONF and its supplementary drafts. Thank you for your review and kind help getting RESTCONF specifications sta= ble. Best Regards, Mehmet and Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F81986CBA6DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The deadline is for sure January 22, 2016 EOB PT.

 

Mehmet

 

From: Ersue, Mehmet (Nokia - DE/Muni= ch)
Sent: Tuesday, December 15, 2015 9:59 PM
To: netconf@ietf.org
Cc: 'core@ietf.org' <core@ietf.org>; 'i2rs@ietf.org' <i2rs@= ietf.org>; '6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6t= isch@ietf.org>
Subject: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf= -netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

 

Dear NETCONF WG,

 

we hereby issue a WG Last Call for th= e drafts below:

 

http://tools.ietf.org/html/draft-ietf-ne= tconf-restconf-09.txt

http://tools.ietf.org/html/draft-ietf-= netconf-yang-patch-07.txt

http://tools.ietf.org/html/draft-iet= f-netconf-yang-library-03.txt

 

Please review and send your comments = to the NETCONF WG mailing list by January 22, 2015 EOB PT.

 

The drafts on RESTCONF, YANG patch an= d YANG library are planned to publish as standard track documents.

 

As RESTCONF is a major protocol we se= ek a detailed and thorough review within NETCONF WG but also by the related= WGs before publishing.

Therefore the WGLC is planned to fina= lize on January 22th (covering the holiday time in between) and APP, INT an= d RTG area ADs will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to review.

 

Please take your time to review the d= ocuments and send your comments to the NETCONF maillist by the deadline.

Please state on NETCONF maillist also= explicitly, whether you have read/reviewed and whether you support the pub= lication.

Furthermore please indicate if you pl= an to implement or have already implementations for RESTCONF and its supplementary drafts.=

 

Thank you for your review and kind he= lp getting RESTCONF specifications stable.

 

Best Regards,

Mehmet and Mahesh

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F81986CBA6DEMUMBX005nsnin_-- From nobody Tue Dec 15 13:34: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 C24A71ACEB7 for ; Tue, 15 Dec 2015 13:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m_D_m88ytay5 for ; Tue, 15 Dec 2015 13:34:54 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2338E1A8777 for ; Tue, 15 Dec 2015 13:34:53 -0800 (PST) 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.361.13; Tue, 15 Dec 2015 21:34:49 +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.0355.012; Tue, 15 Dec 2015 21:34:49 +0000 From: Kent Watsen To: Benoit Claise , NETCONF Thread-Topic: [Netconf] draft-ietf-netconf-call-home: one week review period Thread-Index: AQHRN2Q/AAKWEU0VAEuTicTbq77KWZ7MPj4A Date: Tue, 15 Dec 2015 21:34:49 +0000 Message-ID: <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> References: <56705828.2040408@cisco.com> In-Reply-To: <56705828.2040408@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:L7yDgmMarMsWf27j2ojplKBC2mjhymvp2oqo9owEluOXxt2au+jRzDCqis+IwHF7AYsbKhpSUMIVRPvLd7uC7LN1WzBxAyXt1/ZACnsuLYseOSktXUSJetgFDlYhT+0h71R/sojni2a4Q0GcH9mwBA==; 24:4VCrSbWOGSRZKt84sg8SzKcTuXts+3jmimbNI9zSyw4ZSvPLYDBmG3iMkgLD8k2wOhcWU2xYDHtTrq66kbDGNupILyymVN6+PMM5DUtkI8o= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; 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)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 07915F544A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(199003)(99286002)(189998001)(106356001)(83716003)(106116001)(5001960100002)(107886002)(87936001)(105586002)(82746002)(86362001)(83506001)(66066001)(5001770100001)(97736004)(4001350100001)(81156007)(19580405001)(101416001)(54356999)(50986999)(33656002)(19580395003)(5002640100001)(76176999)(77096005)(19617315012)(11100500001)(230783001)(2900100001)(2950100001)(36756003)(15975445007)(5004730100002)(16236675004)(5008740100001)(6116002)(1096002)(3846002)(92566002)(586003)(1220700001)(40100003)(10400500002)(122556002)(102836003)(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: multipart/alternative; boundary="_000_838D12C45EC346C985715AB1D7CA4B5Djunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2015 21:34:49.3984 (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: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Dec 2015 21:34:56 -0000 --_000_838D12C45EC346C985715AB1D7CA4B5Djunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnVubnkgb3Igc2FkLCBkZXBlbmRpbmcgb24gaG93IHlvdSBsb29rIGF0IGl0LCBidXQgSSBqdXN0 IG5vdyBJIGZvdW5kIGEgdHlwbyBpbiBDMToNCg0KICAgIC0gdG8gbGlzdGVuIGEgZGlmZmVyZW50 IHBvcnQuDQogICAgKyB0byBsaXN0ZW4gdG8gYSBkaWZmZXJlbnQgcG9ydC4NCg0KU2hvdWxkIHdl IGxldCB0aGUgUkZDIEVkaXRvciBjYXRjaCBpdD8NCg0KS2VudA0KDQpGcm9tOiBOZXRjb25mIDxu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNs YWlzZUBjaXNjby5jb20+Pg0KRGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgMTUsIDIwMTUgYXQgMTox MiBQTQ0KVG86ICJuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPiIgPG5l dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW05ldGNv bmZdIGRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWU6IG9uZSB3ZWVrIHJldmlldyBwZXJpb2QN Cg0KRGVhciBhbGwsDQoNCkJldHdlZW4gdGhlIHZlcnNpb24gMTEsIGluaXRpYWxseSB0cmFuc21p dHRlZCB0byB0aGUgSUVTRywgYW5kIHRoZSBsYXRlc3QgdmVyc2lvbiAxNSwgYWRkcmVzc2luZyBh bGwgdGhlIERJU0NVU1NlcywgdGhlcmUgd2VyZSBhIHNlcmllcyBvZiBjaGFuZ2VzLg0KSSBwcm9w b3NlIGEgb25lIHdlZWsgcmV2aWV3IGZvciB0aG9zZSBjaGFuZ2VzPGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lLTExJnVybDI9ZHJh ZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0xNT4sIGJlZm9yZSBJIHNlbnQgdGhpcyBkb2N1bWVu dCB0byB0aGUgUkZDLWVkaXRvciBxdWV1ZS4NCklmIHlvdSBoYXZlIGEgcHJvYmxlbSB3aXRoIHRo b3NlIGNoYW5nZXMsIHNwZWFrIHVwIG5vdy4NCg0KUmVnYXJkcywgQmVub2l0DQoNCg== --_000_838D12C45EC346C985715AB1D7CA4B5Djunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <518B98B5C131C4499AFB1FA2583E9CCE@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+DQpGdW5ueSBvciBzYWQsIGRlcGVuZGluZyBvbiBob3cgeW91IGxvb2sgYXQg aXQsIGJ1dCBJIGp1c3Qgbm93IEkgZm91bmQgYSB0eXBvIGluIEMxOjwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAtIHRvIGxpc3RlbiBhIGRpZmZlcmVudCBwb3J0 LjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICYjNDM7IHRvIGxpc3RlbiB0byBhIGRpZmZlcmVudCBwb3J0LjwvZm9udD48L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJ R05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N ClNob3VsZCB3ZSBsZXQgdGhlIFJGQyBFZGl0b3IgY2F0Y2ggaXQ/PC9kaXY+DQo8ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij4NCktlbnQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwv ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+TmV0Y29uZiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsgb24gYmVoYWxmIG9mIEJlbm9pdCBDbGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpi Y2xhaXNlQGNpc2NvLmNvbSI+YmNsYWlzZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgRGVjZW1iZXIgMTUs IDIwMTUgYXQgMToxMiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog PC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5l dGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0OiA8L3NwYW4+W05ldGNvbmZdIGRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWU6 IG9uZSB3ZWVrIHJldmlldyBwZXJpb2Q8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj5EZWFyIGFsbCw8YnI+ DQo8YnI+DQpCZXR3ZWVuIHRoZSB2ZXJzaW9uIDExLCBpbml0aWFsbHkgdHJhbnNtaXR0ZWQgdG8g dGhlIElFU0csIGFuZCB0aGUgbGF0ZXN0IHZlcnNpb24gMTUsIGFkZHJlc3NpbmcgYWxsIHRoZSBE SVNDVVNTZXMsIHRoZXJlIHdlcmUgYSBzZXJpZXMgb2YgY2hhbmdlcy48YnI+DQpJIHByb3Bvc2Ug YSBvbmUgd2VlayByZXZpZXcgZm9yIHRob3NlIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lLTExJmFtcDt1cmwyPWRy YWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMTUiPg0KY2hhbmdlczwvYT4sIGJlZm9yZSBJIHNl bnQgdGhpcyBkb2N1bWVudCB0byB0aGUgUkZDLWVkaXRvciBxdWV1ZS48YnI+DQpJZiB5b3UgaGF2 ZSBhIHByb2JsZW0gd2l0aCB0aG9zZSBjaGFuZ2VzLCBzcGVhayB1cCBub3cuPGJyPg0KPGJyPg0K UmVnYXJkcywgQmVub2l0PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_838D12C45EC346C985715AB1D7CA4B5Djunipernet_-- From nobody Tue Dec 15 13:47: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 EE2111B2A4E for ; Tue, 15 Dec 2015 13:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iehnw_HUlQ6u for ; Tue, 15 Dec 2015 13:47:10 -0800 (PST) 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 E68091B29C4 for ; Tue, 15 Dec 2015 13:47:09 -0800 (PST) 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 tBFLl5T9001579 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Dec 2015 21:47:05 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 tBFLl4uH032650 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Dec 2015 22:47:04 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 15 Dec 2015 22:47:04 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.48]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 22:47:04 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: EXT Kent Watsen , Benoit Claise , NETCONF Thread-Topic: [Netconf] draft-ietf-netconf-call-home: one week review period Thread-Index: AQHRN2Q/AAKWEU0VAEuTicTbq77KWZ7MPj4AgABWrRA= Date: Tue, 15 Dec 2015 21:47:04 +0000 Message-ID: References: <56705828.2040408@cisco.com> <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> In-Reply-To: <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81986CC9DDEMUMBX005nsnin_" 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: 11196 X-purgate-ID: 151667::1450216025-00002C61-049C62F0/0/0 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Dec 2015 21:47:17 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81986CC9DDEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KeWVzLCB5b3UgY2FuLiBSRkMgRWRpdG9yIGlzIGFjdHVhbGx5IHZlcnkgZ29v ZCB0byBjYXRjaCBzdWNoIGJ1Z3MuDQpEdXJpbmcgdGhpcyByZXZpZXcgb24gdGhlIG1haWxsaXN0 IHdlIG1heSBmaW5kIGFsc28gb3RoZXIgYnVncy4NCg0KTWVobWV0DQoNCkZyb206IE5ldGNvbmYg W21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFWFQgS2VudCBX YXRzZW4NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE1LCAyMDE1IDEwOjM1IFBNDQpUbzogQmVu b2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+OyBORVRDT05GIDxuZXRjb25mQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lOiBv bmUgd2VlayByZXZpZXcgcGVyaW9kDQoNCkZ1bm55IG9yIHNhZCwgZGVwZW5kaW5nIG9uIGhvdyB5 b3UgbG9vayBhdCBpdCwgYnV0IEkganVzdCBub3cgSSBmb3VuZCBhIHR5cG8gaW4gQzE6DQoNCiAg ICAtIHRvIGxpc3RlbiBhIGRpZmZlcmVudCBwb3J0Lg0KICAgICsgdG8gbGlzdGVuIHRvIGEgZGlm ZmVyZW50IHBvcnQuDQoNClNob3VsZCB3ZSBsZXQgdGhlIFJGQyBFZGl0b3IgY2F0Y2ggaXQ/DQoN CktlbnQNCg0KRnJvbTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQmVub2l0IENsYWlzZSA8YmNs YWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4NCkRhdGU6IFR1ZXNkYXks IERlY2VtYmVyIDE1LCAyMDE1IGF0IDE6MTIgUE0NClRvOiAibmV0Y29uZkBpZXRmLm9yZzxtYWls dG86bmV0Y29uZkBpZXRmLm9yZz4iIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGll dGYub3JnPj4NClN1YmplY3Q6IFtOZXRjb25mXSBkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21l OiBvbmUgd2VlayByZXZpZXcgcGVyaW9kDQoNCkRlYXIgYWxsLA0KDQpCZXR3ZWVuIHRoZSB2ZXJz aW9uIDExLCBpbml0aWFsbHkgdHJhbnNtaXR0ZWQgdG8gdGhlIElFU0csIGFuZCB0aGUgbGF0ZXN0 IHZlcnNpb24gMTUsIGFkZHJlc3NpbmcgYWxsIHRoZSBESVNDVVNTZXMsIHRoZXJlIHdlcmUgYSBz ZXJpZXMgb2YgY2hhbmdlcy4NCkkgcHJvcG9zZSBhIG9uZSB3ZWVrIHJldmlldyBmb3IgdGhvc2Ug Y2hhbmdlczxodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1uZXRj b25mLWNhbGwtaG9tZS0xMSZ1cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMTU+LCBi ZWZvcmUgSSBzZW50IHRoaXMgZG9jdW1lbnQgdG8gdGhlIFJGQy1lZGl0b3IgcXVldWUuDQpJZiB5 b3UgaGF2ZSBhIHByb2JsZW0gd2l0aCB0aG9zZSBjaGFuZ2VzLCBzcGVhayB1cCBub3cuDQoNClJl Z2FyZHMsIEJlbm9pdA0K --_000_E4DE949E6CE3E34993A2FF8AE79131F81986CC9DDEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMDAwMDk5Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250 LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPkhpIEtlbnQsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij55ZXMsIHlvdSBjYW4uIFJGQyBFZGl0b3Ig aXMgYWN0dWFsbHkgdmVyeSBnb29kIHRvIGNhdGNoIHN1Y2ggYnVncy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMDA5 OSI+RHVyaW5nIHRoaXMgcmV2aWV3IG9uIHRoZSBtYWlsbGlzdCB3ZSBtYXkgZmluZCBhbHNvIG90 aGVyIGJ1Z3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDAwQ0MiPk1laG1ldA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FWFQgS2VudCBXYXRzZW48 YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMTUsIDIwMTUgMTA6MzUgUE08YnI+ DQo8Yj5Ubzo8L2I+IEJlbm9pdCBDbGFpc2UgJmx0O2JjbGFpc2VAY2lzY28uY29tJmd0OzsgTkVU Q09ORiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtO ZXRjb25mXSBkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lOiBvbmUgd2VlayByZXZpZXcgcGVy aW9kPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5GdW5ueSBvciBzYWQs IGRlcGVuZGluZyBvbiBob3cgeW91IGxvb2sgYXQgaXQsIGJ1dCBJIGp1c3Qgbm93IEkgZm91bmQg YSB0eXBvIGluIEMxOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAtIHRvIGxpc3RlbiBhIGRpZmZlcmVudCBwb3J0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg JiM0MzsgdG8gbGlzdGVuIHRvIGEgZGlmZmVyZW50IHBvcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5TaG91bGQgd2UgbGV0IHRoZSBSRkMgRWRpdG9yIGNhdGNoIGl0PzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5l dGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBCZW5vaXQgQ2xhaXNlICZs dDs8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iPmJjbGFpc2VAY2lzY28uY29tPC9h PiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgRGVjZW1iZXIgMTUsIDIwMTUgYXQgMTox MiBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5v cmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29u ZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PltOZXRjb25mXSBkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lOiBvbmUgd2VlayByZXZpZXcg cGVyaW9kPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkRl YXIgYWxsLDxicj4NCjxicj4NCkJldHdlZW4gdGhlIHZlcnNpb24gMTEsIGluaXRpYWxseSB0cmFu c21pdHRlZCB0byB0aGUgSUVTRywgYW5kIHRoZSBsYXRlc3QgdmVyc2lvbiAxNSwgYWRkcmVzc2lu ZyBhbGwgdGhlIERJU0NVU1NlcywgdGhlcmUgd2VyZSBhIHNlcmllcyBvZiBjaGFuZ2VzLjxicj4N CkkgcHJvcG9zZSBhIG9uZSB3ZWVrIHJldmlldyBmb3IgdGhvc2UgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMTEm YW1wO3VybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0xNSI+DQpjaGFuZ2VzPC9hPiwg YmVmb3JlIEkgc2VudCB0aGlzIGRvY3VtZW50IHRvIHRoZSBSRkMtZWRpdG9yIHF1ZXVlLjxicj4N CklmIHlvdSBoYXZlIGEgcHJvYmxlbSB3aXRoIHRob3NlIGNoYW5nZXMsIHNwZWFrIHVwIG5vdy48 YnI+DQo8YnI+DQpSZWdhcmRzLCBCZW5vaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E4DE949E6CE3E34993A2FF8AE79131F81986CC9DDEMUMBX005nsnin_-- From nobody Tue Dec 15 13:50: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 39BB61AD357 for ; Tue, 15 Dec 2015 13:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, 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 0ZrKG4Y7knAA for ; Tue, 15 Dec 2015 13:50:29 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4B51AD21C for ; Tue, 15 Dec 2015 13:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5676; q=dns/txt; s=iport; t=1450216229; x=1451425829; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=U29ikHiOe+2zJbDW3Ms3N9p42II5ZGobxLtLZdYluzg=; b=ji3/b6r9MpcqcdW3w9Yzqpx38GFNxsqL/udbAyGIaIOi0nTfKA9unHNq 8E5V5iqzEI4sYf5CKrepRojzEX7i5R2j937MC1Yz+1m49bwfsjjaawdPq pXWIbV8p6aGxTetna/ZfieHTFujZ5JJNQ5LmecgzLmf3fDFK8qm/uzbVv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBACjinBW/xjFo0hegm6BHm2/SiOFa?= =?us-ascii?q?gKCFgEBAQEBAYELhDQBAQEEI1URCw4DAwECChYIAwICCQMCAQIBNAkIBgEMBgI?= =?us-ascii?q?BAYgrDqtrkXUBAQEBAQEBAQEBAQEBAQEBAQEBARUEhlaEfYR7gnyBSQWTBoN2j?= =?us-ascii?q?UiJJpN0Y4QFPTSEdAEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,434,1444694400"; d="scan'208,217"; a="57139549" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2015 21:50:23 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBFLoLwY013906; Tue, 15 Dec 2015 21:50:22 GMT To: Kent Watsen , NETCONF References: <56705828.2040408@cisco.com> <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> From: Benoit Claise Message-ID: <56708B1D.4010804@cisco.com> Date: Tue, 15 Dec 2015 22:50:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> Content-Type: multipart/alternative; boundary="------------070907020906040503030903" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 15 Dec 2015 21:50:33 -0000 This is a multi-part message in MIME format. --------------070907020906040503030903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit We could add a RFC editor note. Regards, Benoit > Funny or sad, depending on how you look at it, but I just now I found > a typo in C1: > > - to listen a different port. > + to listen to a different port. > > Should we let the RFC Editor catch it? > > Kent > > From: Netconf > on behalf of Benoit Claise > > > Date: Tuesday, December 15, 2015 at 1:12 PM > To: "netconf@ietf.org " > > Subject: [Netconf] draft-ietf-netconf-call-home: one week review period > > Dear all, > > Between the version 11, initially transmitted to the IESG, and the > latest version 15, addressing all the DISCUSSes, there were a series > of changes. > I propose a one week review for those changes > , > before I sent this document to the RFC-editor queue. > If you have a problem with those changes, speak up now. > > Regards, Benoit > --------------070907020906040503030903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
We could add a RFC editor note.

Regards, Benoit
Funny or sad, depending on how you look at it, but I just now I found a typo in C1:

    - to listen a different port.
    + to listen to a different port.

Should we let the RFC Editor catch it?

Kent

From: Netconf <netconf-bounces@ietf.org> on behalf of Benoit Claise <bclaise@cisco.com>
Date: Tuesday, December 15, 2015 at 1:12 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] draft-ietf-netconf-call-home: one week review period

Dear all,

Between the version 11, initially transmitted to the IESG, and the latest version 15, addressing all the DISCUSSes, there were a series of changes.
I propose a one week review for those changes, before I sent this document to the RFC-editor queue.
If you have a problem with those changes, speak up now.

Regards, Benoit

--------------070907020906040503030903-- From nobody Tue Dec 15 18:55:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E720A1A1B49 for ; Tue, 15 Dec 2015 18:55:00 -0800 (PST) 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 wmtX4d5_fNU7 for ; Tue, 15 Dec 2015 18:54:59 -0800 (PST) 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 BCD9B1A1B3E for ; Tue, 15 Dec 2015 18:54:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFM75281; Wed, 16 Dec 2015 02:54:56 +0000 (GMT) Received: from lhreml703-cah.china.huawei.com (10.201.5.104) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Dec 2015 02:54:55 +0000 Received: from SZXEMI411-HUB.china.huawei.com (10.86.210.34) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 16 Dec 2015 02:54:55 +0000 Received: from SZXEMI506-MBS.china.huawei.com ([169.254.6.117]) by szxemi411-hub.china.huawei.com ([10.86.210.34]) with mapi id 14.03.0235.001; Wed, 16 Dec 2015 10:54:52 +0800 From: "fengchong (C)" To: "netconf@ietf.org" Thread-Topic: A question about subtree filter Thread-Index: AdE3rSJuQqZTGlUXQ0eIEMFpfGS1pA== Date: Wed, 16 Dec 2015 02:54:52 +0000 Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D082DB8D@SZXEMI506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.40.226] Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D082DB8DSZXEMI506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5670D281.0050, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dd3d6809527f6ea92765370466fe1d0a Archived-At: Subject: [Netconf] A question about subtree filter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2015 02:55:01 -0000 --_000_5756FB984666AD4BB8E1D63E2E3AA3D082DB8DSZXEMI506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have a question about subtree filter. In sec 6.2.5 If all specified sibling content match nodes in a subtree filter expression are "true", then the filter output nodes are selected in the following manner: o Each content match node in the sibling set is included in the filter output. o If any containment nodes are present in the sibling set, then they are processed further and included if any nested filter criteria are also met. If a containement node is present in the sibling set, and if this contai= nement node has a content node as its child. If this child content node is not met, = then should this containement node be not selected or all the sibling set be not selected= ? For example: Data are listed below: 1 2 1 2 2 2 And filter is : 1 2 Then should return: 1. 1 2 Or 2. /frank --_000_5756FB984666AD4BB8E1D63E2E3AA3D082DB8DSZXEMI506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

   I have a question = about subtree filter.

   In sec 6.2.5 =

     &= nbsp; If all specified sibling content match nodes in a subtree filter=

   expression are &qu= ot;true", then the filter output nodes are selected in

   the following mann= er:

 

   o  Each conte= nt match node in the sibling set is included in the

      = filter output.

 

   o  If any containment nodes are present in the sibling set, th= en they

  = ;    are processed further and included if any nested filter= criteria

  = ;    are also met.

 

   If a containement = node is present in the sibling set, and if this containement node

   has a content node= as its child. If this child content node is not met, then should this=

   containement node = be not selected or all the sibling set be not selected?

 

   For example:<= /o:p>

   Data are listed be= low:

  <top>

     &= nbsp;   <a>

     &= nbsp;           &nbs= p; <a1>1</a1>

     &= nbsp;           &nbs= p; <a2>2</a2>

     &= nbsp;           &nbs= p; <a3>

     &= nbsp;           &nbs= p;   <a31>1</a31>

     &= nbsp;           &nbs= p; </a3>

     &= nbsp;   </a>

     &= nbsp;   <a>

     &= nbsp;           &nbs= p; <a1>2</a1>

     &= nbsp;           &nbs= p; <a2>2</a2>

     &= nbsp;           &nbs= p; <a3>

     &= nbsp;           &nbs= p;   <a31>2</a31>

     &= nbsp;           &nbs= p; </a3>

     &= nbsp;   </a>

</top><= /p>

 

And filter is :

<filter type=3D "subtre= e">

     &= nbsp;   <top>

     &= nbsp;           &nbs= p; <a>

     &= nbsp;           &nbs= p;          <a1>1</a1= >

     &= nbsp;           &nbs= p;          <a2/>

     &= nbsp;           &nbs= p;          <a3>

     &= nbsp;           &nbs= p;            &= nbsp;      <a31>2</a31>

     &= nbsp;           &nbs= p;          </a3>

     &= nbsp;           &nbs= p; </a>

     &= nbsp;   </top>

</filter>

 

Then should return:<= /span>

1.

  <data><= /span>

     &= nbsp;   <top>

     &= nbsp;          <a>

     &= nbsp;           &nbs= p; <a1>1</a1>

     &= nbsp;           &nbs= p; <a2>2</a2>

     &= nbsp;   </a>

     &= nbsp;   </top>

  </data>=

Or

2.

<data/>=

 

/frank

--_000_5756FB984666AD4BB8E1D63E2E3AA3D082DB8DSZXEMI506MBSchina_-- From nobody Tue Dec 15 19:18: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 90B8B1A1BD1 for ; Tue, 15 Dec 2015 19:18:26 -0800 (PST) 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 XA1QVtJSrgiD for ; Tue, 15 Dec 2015 19:18:25 -0800 (PST) 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 5FE6D1A1BCF for ; Tue, 15 Dec 2015 19:18:24 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id l133so20302629lfd.2 for ; Tue, 15 Dec 2015 19:18:24 -0800 (PST) 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=ppZnvl/fKDPXU76BtKbzuaiiFvmobhyQvT3022AXVn8=; b=kDAO6xiAPLwDzvLNkPGpbfWjF95F6oEHaUa7WSC7H04rMerct35lo5OeEHOvM/hqV7 2n4xSvzp2DMyQZJW9wDx3esRa/3q/WwaSChyHTeTz6CeowJWMeCViXMNJbaGfu5GwZZh DqqG6ogFCpoliMHp9KqTE1hLtpOEBUvp4wxri4a8f+glWl/AfuBJfd3qPX/GwI1C8CmI nhVIRbZyhpXxni2z8m51y+XcrZZ/tNb0nn3lcLFOiNzyhCVgS0mP3WxgmJDBnEL9J1M4 uedFBSj0cNOBghxHIznQ4aa64745Rao2c7Z+S5ZCj1pKjRrApUKEXnZCoQbgaAN//nJp Xh1g== 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=ppZnvl/fKDPXU76BtKbzuaiiFvmobhyQvT3022AXVn8=; b=S0f3Xw2L7iAfIsQBntynMMkR/W6ktok8C8QCLVsFcaZzYcRnfj34pWe0PAZSMXcH4J 9mXv2+FRF37MQ/ae6jpjM9KB5IaFf4vcs615rFPV2mkneRB+E6Oh4qJRAvTZE+m4Di8z lVdTp0r6GU/p/K1quy/n+w5lZgUlpVy7E/XY0X7K7FUfYtYDdIHdFskEnTyrJVQBgoCV iVRs4HEy7afL7l8u+lqdQWJPRvmW+lSzAufJUIhgsAop7X+ad3/JjiWIoz7mtc4rnXb4 lTJNd0U0/5NvcxMQCbjsBgi77H0sg6XoGnmWAbXx6tsdKtflrVjhvaIL9fa0fJ/LMvxs LYZg== X-Gm-Message-State: ALoCoQljenMfjaHi7lRMhbj2CjJLoqTsyUhA7nxMUKs8R34AT2qbRde95la37xClWd6ldYyogHJiFAOzp6NZVGhv5ym9A9Y3dA== MIME-Version: 1.0 X-Received: by 10.25.82.144 with SMTP id g138mr9304869lfb.8.1450235902605; Tue, 15 Dec 2015 19:18:22 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 15 Dec 2015 19:18:22 -0800 (PST) In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D082DB8D@SZXEMI506-MBS.china.huawei.com> References: <5756FB984666AD4BB8E1D63E2E3AA3D082DB8D@SZXEMI506-MBS.china.huawei.com> Date: Tue, 15 Dec 2015 19:18:22 -0800 Message-ID: From: Andy Bierman To: "fengchong (C)" Content-Type: multipart/alternative; boundary=001a1141da8ed0d68d0526fb5b95 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] A question about subtree filter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2015 03:18:26 -0000 --001a1141da8ed0d68d0526fb5b95 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 15, 2015 at 6:54 PM, fengchong (C) wrote: > Hi all, > > I have a question about subtree filter. > > In sec 6.2.5 > > If all specified sibling content match nodes in a subtree filter > > expression are "true", then the filter output nodes are selected in > > the following manner: > > > > o Each content match node in the sibling set is included in the > > filter output. > > > > o If any containment nodes are present in the sibling set, then they > > are processed further and included if any nested filter criteria > > are also met. > > > > If a containement node is present in the sibling set, and if this > containement node > > has a content node as its child. If this child content node is not met, > then should this > > containement node be not selected or all the sibling set be not > selected? > > > > For example: > > Data are listed below: > > > > > > 1 > > 2 > > > > 1 > > > > > > > > 2 > > 2 > > > > 2 > > > > > > > > > > And filter is : > > > > > > > > 1 > > > > > > 2 > > > > > > > > > > > > Then should return: > > 1. > > > > > > > > 1 > > 2 > > > > > > > I think (1) is correct -- the content-match node filters out its siblings and the node. It might be OK if an empty node was included. > Or > > 2. > > > > > > /frank > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a1141da8ed0d68d0526fb5b95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 15, 2015 at 6:54 PM, fengchong (C) <frank.fengcho= ng@huawei.com> wrote:

Hi all,

=C2=A0=C2=A0 I have a question = about subtree filter.

=C2=A0=C2=A0 In sec 6.2.5

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0If all specified sibling content match nodes in a subtree filte= r

=C2=A0=C2=A0 expression are &qu= ot;true", then the filter output nodes are selected in

=C2=A0=C2=A0 the following mann= er:

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Each conte= nt match node in the sibling set is included in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = filter output.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 If any containment nodes are present in the sibling set, th= en they

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 are processed further and included if any nested filt= er criteria

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 are also met.

=C2=A0

=C2=A0=C2=A0 If a containement = node is present in the sibling set, and if this containement node=

=C2=A0=C2=A0 has a content node= as its child. If this child content node is not met, then should this

=C2=A0=C2=A0 containement node = be not selected or all the sibling set be not selected?

=C2=A0

=C2=A0=C2=A0 For example:

=C2=A0=C2=A0 Data are listed be= low:

=C2=A0 <top>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <a>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a1>1</a1>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a2>2</a2>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a3>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0 <a31>1</a31>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 </a3>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 </a>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <a>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a1>2</a1>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a2>2</a2>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a3>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =C2=A0 <a31>2</a31>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 </a3>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 </a>

</top>

=C2=A0

And filter is :

<filter type=3D "subtre= e">

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <top>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <a1>1</a= 1>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <a2/>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <a3>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <a31>2</a31>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </a3>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 </a>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 </top>

</filter>

=C2=A0

Then should return:

1.

=C2=A0 <data>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <top>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 <a><= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a1>1</a1>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 <a2>2</a2>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 </a>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 </top>

=C2=A0 </data>

=


I think (1) is = correct -- the <a31> content-match node filters out its siblings
and the <a3> node.=C2=A0 It might be OK if an empty <a3 />= ; node was included.

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

Or

2.

<data/>

=C2=A0

/frank=



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


--001a1141da8ed0d68d0526fb5b95-- From nobody Wed Dec 16 03:29: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 202F51A700B for ; Wed, 16 Dec 2015 03:29:56 -0800 (PST) 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 qylDr3w594EJ for ; Wed, 16 Dec 2015 03:29:51 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0123.outbound.protection.outlook.com [104.47.1.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBC31A1A7C for ; Wed, 16 Dec 2015 03:29:49 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.185.87.133) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.337.19; Wed, 16 Dec 2015 11:29:45 +0000 Message-ID: <014a01d137f4$c9b6bfc0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Benoit Claise , NETCONF References: <56705828.2040408@cisco.com> <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> Date: Wed, 16 Dec 2015 11:27:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB4PR06CA0011.eurprd06.prod.outlook.com (25.160.40.139) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB049; 2:FioXnVQABri2equS2D+joq0PtYxW40JXCpHS0N0jWmQTZo1PvZFzWgsS4XAzD7JCN2gsMN3+z3oLYIH2ijkOhci5+hQkXjsnSjUH0qZzC+Qt0Uxo57ONJQo5DIq+HX3n0vP6+YQyXDC3gRSmgtAysQ==; 3:rJyIuO3VLyVDLDM0djmxBORxK8dGZjH3GmX2WjndHTlStwSVOoZ8gDkSdtyJn9QqERFEaNWMvXLGLFnf9OlAkxQISI8QCXnbYTUdsF7FA2yyA+e+0dz0oBoYdTMRb6Pn; 25:tisVkCw1XEBWLjqHINBMw5cXzr7BE+ux5QuUxAHhr0dVNTe7cXp63Q7iPxES/bxMUOy+ld1fhjFhmG+yvNqgQSTEX9oyM+KKJi4GmkAcHPjWOOXJTPKL7WjX87C6U+YgNHd3IdRztu7rw4FZIOMuPP04lX0ondYMR/seYrmQUEnBsUOXaIFQXQio6dQpq7ZFqzTWf85vRIR/URYb64KHZ9MEYuhhQ7VnvEi3JRntn81dC6Kt5fOJXJByFYPLbudi X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB049; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB049; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB049; 4:pAiXVDDFsox3/HO7Yx0TxJggdKOv2j+fY9/YvoIX9b9hnUiXjULSpKhD10WvvIRhl79P12bwmV3Z78P8ZhmaoETDZ4xP4ahK/RkjZ2h6qnMeoawp68w3886Hg+md1na3JQr+1qeOh0K/djC70tlbXhj0Xc44uGdGRfZ5pAxPumWmN0ZZz2y+zVgzmYy5APcz7sUf67E+Pqo9UGP6+5IolCvgLKh//jN+FKxe9f9fGVfUoEzsxOu/FzHORZSD3NzK4dFrwabt6c69pe/mPLR7ZfRA15m/pnLnJHFaRKyusQfOY68AIf7NdjrU6UJaSvew4CZSkdjREdwpn06Awq3tRlKReuR+4Dn1w7LWjno1UycgUK/DPHuP8JWYfGw1oXDBcpmchJPdzWphKx0YJdwT42I0/fjVJUJ+waMEJZ3aMwL2171QmuP5lkSYi1WsWmrj2x+s0A5XPE/CgN+jRkj4Nw== X-Forefront-PRVS: 0792DBEAD0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(53234004)(13464003)(377454003)(61296003)(5008740100001)(116806002)(230783001)(33646002)(50986999)(107886002)(81156007)(5001960100002)(1456003)(189998001)(97736004)(5001770100001)(15975445007)(3846002)(6116002)(86362001)(586003)(230700001)(105586002)(19580395003)(551544002)(19580405001)(50466002)(106356001)(101416001)(47776003)(23676002)(81816999)(14496001)(1941001)(66066001)(44736004)(92566002)(122386002)(1096002)(40100003)(76176999)(50226001)(1556002)(87976001)(42186005)(84392001)(77096005)(5820100001)(62236002)(44716002)(81686999)(5004730100002)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; 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?MTtBTVNQUjA3TUIwNDk7MjM6a2tlQ1M1UXRFaVEyZFVTcXZqNWhraUwxYVFQ?= =?utf-8?B?NDh0ak0vYU4wVzZ4RFFVbklRQjJYaTdaWFdBMG15eXNOY1phend0NlM1a1Zh?= =?utf-8?B?WkR5ZXQ1bnowMHRLa2FDaHVPd0xPY0ZIY0FOeTNzU1JIdk1uNnA1bHN5RTdR?= =?utf-8?B?K3hVczZUTzU3V256Rm5aeHVhaWIvTW5zVVlCbXE3ak1zSm9kbVNwVE4ycWpi?= =?utf-8?B?RnEvNkt1aWVTMURmTVB6c2wrKzU1VUhtOGFyM2ZDRjEyNHpSbEFJdVhaYlNW?= =?utf-8?B?OGowTk9xKzhaZGIzQVRIcCtXSGZTcFVxTEZ6eVFuYTQwN2IveU5QUWEzMUtS?= =?utf-8?B?UEU1Tzg2N2czdDBBM2p4eXlxbFIvSTl4TFE2WEdLblhzWGQ4UGlwcXpzc00y?= =?utf-8?B?bWRaZ0U3OUhEVUVSZmtWNmxiNWhQMnVCajhlMmFIV1JLV1gyb25uY2ZCZ1hH?= =?utf-8?B?NWRnVUdteXkvTlBLb3BRME9NUnE0TmFYZUJyeFBEYjcvc0x1Z2xiZ0xrN2VT?= =?utf-8?B?cGNvSDNSd0hkY0xmQnovS3d3dkNtdy9RUUpIaGQyUHhabm1MSGFZR0tTL0pU?= =?utf-8?B?bFZsNXpYWFVpZk81aFoyNVlhVlpGTVN4ajhsS3FlaHV5ZmdJdm9mQ1p0TzIz?= =?utf-8?B?ZWtwVEdReHNWaDRyQko1elBJdlFhM3ZRZWV6TGM5YUJrdXR2WE1ObDBxQy9y?= =?utf-8?B?UUhqeFBiZGREZStqaU9kQ0wvTmplNHhtdmpVL3haNTgyQnViajV6cFlCYUJu?= =?utf-8?B?akJWMkwvY0NEV0NkTVFPZVdFVEEzcTJBQXl6aEt5SW5YbWE5dHQyV1BCMndZ?= =?utf-8?B?MXV1M3VKZnlqNzlCbUtueXNma1BTWHkvQmtNZGRRTCs5dGJIUlp3MWFHNFZV?= =?utf-8?B?bmRaaHpCWlVQallBWDdoTzNqNXZQdXU1OGxTMlNYOERyY3dGZytER0Q2bnh3?= =?utf-8?B?anFsWjc2RnJ0SjNtL3o5YXFhcnRQcTlMQjZ3cmRQeW1FVDd4aXc1L2FZL05P?= =?utf-8?B?NlRySGFlMGJnN2lCKy9BTi9FMWM3aUFNV3NXVTRva01za3Z6TVRyS2xTbDJC?= =?utf-8?B?YitJbXlqUWNENmNNWWdwSWltUWhDMTM2aGVJcHEycFd2Qll5TWhBZklkUXh6?= =?utf-8?B?aVBwdmw4bXRUOCtSU1AwcFNjQXMwT1ZmMGR3RnRMc0RPakxaNTdOOE1oYy9n?= =?utf-8?B?RWwyWDdHdzM1N0tSZWNjeWlDTVhKTFc4bUpzQ29EalhGYWczbEF1ZndLcmV4?= =?utf-8?B?SlM0WEhSYUxueUE3WU5OOWlkQ08yS2FsdHhueWFmQUpqTWo2NVQ3QnFIYzM5?= =?utf-8?B?c2pEMzNDaVo5elVONkxXN3IvN2htUU13Z3k5YzhMWmFheVJMV2M4YVJSWk5m?= =?utf-8?B?R0hRUURBNUk2UlBpVW42cGVMcEJpTXpoUjhMeVhicTQ2UEJ4VEhEMmRNOGF1?= =?utf-8?B?ZFIyYU50ajdrUHI3OWxuSFZYT0UvaEthMjl0cklUTEdqNDZrR2NqMGF3L2NH?= =?utf-8?B?RnJwejVlaGJlNFFacVJ4cjN3NE5vYkRzTFhlK2g0MnZjaW8zenFuYzduNGlK?= =?utf-8?B?dkdJL2R5cnU5a3ZZby9LSnIxcVBZUkxlMFJqSFRrZjBpdDZWT0dZalk0NTNq?= =?utf-8?B?UVpBQjB3NWRHZzRUTlBQU2NEWXFMRzc1Z2c0enhLS2YxWjM2aE9xOEcyUXY2?= =?utf-8?B?a2FaenI3REhHUkVvRDMrcWszK0UzTkcvcWVFU1grYmc2NlJsZXpJdGg0c3Nq?= =?utf-8?B?OHd4YVdWTHNMMnF5R3M2VzZkVjFzVUQ0Unh3RERQbk9ramtrNzEyZnZXZUF6?= =?utf-8?B?MXZrVi84c0hwalFyMXo0a05KRkw2VlI3ZVdiQm85L3BUZnE1OTNwSGtvemdV?= =?utf-8?B?ZkxvZzZMdDVyTlB4d01USFNITTNLaTU4eUZjM1RITjZVR0VEdjhCTEVpakdZ?= =?utf-8?Q?FNY/PAkTbyepfFPilaKtm06JzHE+s=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB049; 5:bmKgCKYBbaDG9qjypduqBV+4KvkmXGPOdmNWjrifHJBRPeURSOZr9nybtTYGFcwfGZUVcgcdTvnGoGxrI0d2w9fnhp5c8G1j6DgtZVyuK4QbRznC3IvZmpOUpPc9ExZi5B9eR0bXqgoMtXmBty8puA==; 24:srLQGL0cGO+O0/VMfDOarTG0CWUtX/n1qenzyNmbvKQJXZa0Llw2P/A0VetSpG0vvPg3wAQszhK5YGHfZlRxix+GuEX5CY3f7akavu+seHk= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2015 11:29:45.3100 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2015 11:29:56 -0000 I missed that one in C.1 but I hope that the RFC Editor catches a few more! For example, "the attacker doesn't posses a valid key. " poss v.t. ' to mangle the language as a result of a review such as that of the IESG' :-) Also - the I-D uses a mixture of 'Issuer' and 'trust anchor' seemingly both to refer to the top of the chain of certificates; what is the significance of this? For me, Trust Anchor is where it all starts, where you must verify the chain of certificates to whereas Issuer is the issuer of a certificate, any certificate, from end entity via intermediate to trust anchor, but I realise that that opinions on this vary. RFC6125 uses trust anchor for the top of the chain while RFC5280 uses Issuer for, well, the issuer of any certificate. - likewise, the client security credential used for RESTCONF is a mix of 'shared secret', 'password' or 'shared key' - the last seems wrong to me. I note that the cited RFC, 7616 and 7617, use password. - C.6 "Clients SHOULD ensure that the Issuer used to authenticate the presented certificate defines the namespace for the identifiers of interest. " I don't understand this. If a certificate has a dNSName or iPAddress in it, in what sense does the certificate define the namespace? - S.5 I am surprised that the Security reviews did not mention the need not to action messages prior to successful user authentication. There is a strong drive in the use of TLS by websites to eliminate round trips so that user data is sent before a secure channel has been established, with the data being resent or discarded if the setup of the secure channel does not complete. This requires applications to know what is going on. Likewise, where the user authentication is a separate function, performed after the 'secure' channel has been set up, it may be ok for the web user to send data and for the web server to act upon it, albeit not in a way that could cause harm. The use of these protocols by NETCONF is rather different, acting on data from a yet-to-be authenticated user could be unfortunate, and the server should be cautious about accepting data until the secure channel really has been set up. I am thinking that before too long, we will have TLS stacks that are optimised for fast web access but are a danger to operational applications, and so might have added a phrase at the end of S5 to the effect that any user data must be then discarded. But if this was not raised, then it is probably best left to linger a while longer. - " For cases when the NETCONF/RESTCONF server presents an X.509 certificate, NETCONF/RESTCONF clients should ensure that the Issuer certificate used for certificate path validation is unique to the manufacturer of the server. That is, the certificate should not belong to a 3rd-party certificate authority that might issue intermediate certificates for more than one manufacturer. " This confuses me. Issuer seems to be trust anchor from other uses of the term so this seems to be saying that all servers of a given manufacturer must have certificate chains leading back to the same trust anchor and that that trust anchor must not issue certificates for any other manufacturer - but then what is 'intermediate' doing in there? I would expect the number of intermediate certicates to range from zero to n, but have otherwise no particular properties. I note that the Normative reference to restconf means that this will not advance for many months, but guess that that time is best spent in the RFC-Editor queue. Tom Petch ----- Original Message ----- From: "Kent Watsen" To: "Benoit Claise" ; "NETCONF" Sent: Tuesday, December 15, 2015 9:34 PM > Funny or sad, depending on how you look at it, but I just now I found a typo in C1: > > - to listen a different port. > + to listen to a different port. > > Should we let the RFC Editor catch it? > > Kent > > From: Netconf > on behalf of Benoit Claise > > Date: Tuesday, December 15, 2015 at 1:12 PM > To: "netconf@ietf.org" > > Subject: [Netconf] draft-ietf-netconf-call-home: one week review period > > Dear all, > > Between the version 11, initially transmitted to the IESG, and the latest version 15, addressing all the DISCUSSes, there were a series of changes. > I propose a one week review for those changes, before I sent this document to the RFC-editor queue. > If you have a problem with those changes, speak up now. > > Regards, Benoit > > From nobody Wed Dec 16 08:28: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 BA57B1A01EA for ; Wed, 16 Dec 2015 08:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRE0deljZW7Z for ; Wed, 16 Dec 2015 08:28:43 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B511A03A3 for ; Wed, 16 Dec 2015 08:28:29 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-13-567191258894 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 7A.99.32102.52191765; Wed, 16 Dec 2015 17:28:22 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Wed, 16 Dec 2015 11:28:27 -0500 From: Athanasios Kyparlis To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 Thread-Index: AdE3eTk+yj/4s/NrQu2LeR6gt3+K2gAoCZaQ Date: Wed, 16 Dec 2015 16:28:27 +0000 Message-ID: <4F4A512E4B3EB845A006F77C995C22A73C8D0AC3@eusaamb107.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_4F4A512E4B3EB845A006F77C995C22A73C8D0AC3eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyuXRPrK7axMIwg51bmC2mbrrN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKPPG5gK9hVU7Fx0mq2BcUJqFyMnh4SAicTiI8tYIWwxiQv3 1rN1MXJxCAkcYZR4uPsLG0hCSGA5o8T0DUUgNpuAjUT3r05mEFtEQFOicdYHVpAGYYF2RomX X86xgzgiAh2MEvuW7mGHqDKSONPXBLaCRUBV4vq/o2A2r4CvxNW7O5ghNvhLXF/xHGgbBwen QIDExg2SIGFGoIu+n1rDBGIzC4hL3HoynwniUgGJJXvOM0PYohIvH/+D+kBJYtLSc6wQ9fkS T7+1s0GsEpQ4OfMJywRGkVlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRf xchRWlyQk5tuZLiJERgrxyTYHHcw7u31PMQowMGoxMNrkFwQJsSaWFZcmXuIUYKDWUmE93tv YZgQb0piZVVqUX58UWlOavEhRmkOFiVxXkYGBgYhgfTEktTs1NSC1CKYLBMHp1QDI9f8B1wV /LdZw012FkQ6Ta/pNbovuWqDpiv7CiEe610X61Tapkj/PlbY+qB5Nu/82zka6+JdVuX+i9+y oyHqN+skbw7ja7+nsuevS596tk1oyeIt4Tazf8r85JdLPtop7GZddJBD4fSua9cbLXm33F3d cMLks4za9y3Jgod/cOzfHXJr3jKWVUosxRmJhlrMRcWJAG/A14eRAgAA Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2015 16:28:46 -0000 --_000_4F4A512E4B3EB845A006F77C995C22A73C8D0AC3eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a comment for draft-ietf-netconf-yang-library-03.txt: The document should outline the relationship to schema subtree and get-sche= ma operation defined in rfc6022. Is the schema leaf defined in the draft equivalent to the schema 'location'= defined in rfc6022? Are the two expected to have the same value? It should also describe if the two capabilities (yang-library and rfc6022 s= chema) will be used in parallel or if systems are expected to switch to yan= g-library over rfc6022 or if there is going to be a prescribed preference [= for example, should systems try to use yang-library for YANG and switch to = rfc6022 schema only if the former is not present?]. Thanks, Athanasios Kyparlis From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Ersue, Mehmet (Nokia= - DE/Munich) Sent: Tuesday, December 15, 2015 3:59 PM To: netconf@ietf.org Cc: i2rs@ietf.org; 6tisch@ietf.org; core@ietf.org; 6lo@ietf.org Subject: [i2rs] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf= -netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 Dear NETCONF WG, we hereby issue a WG Last Call for the drafts below: http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt Please review and send your comments to the NETCONF WG mailing list by Janu= ary 22, 2015 EOB PT. The drafts on RESTCONF, YANG patch and YANG library are planned to publish = as standard track documents. As RESTCONF is a major protocol we seek a detailed and thorough review with= in NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned to finalize on January 22th (covering the hol= iday time in between) and APP, INT and RTG area ADs will be informed as wel= l as Core, I2RS, 6lo, and 6tisch WGs are invited to review. Please take your time to review the documents and send your comments to the= NETCONF maillist by the deadline. Please state on NETCONF maillist also explicitly, whether you have read/rev= iewed and whether you support the publication. Furthermore please indicate if you plan to implement or have already implem= entations for RESTCONF and its supplementary drafts. Thank you for your review and kind help getting RESTCONF specifications sta= ble. Best Regards, Mehmet and Mahesh --_000_4F4A512E4B3EB845A006F77C995C22A73C8D0AC3eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a comment for dra= ft-ietf-netconf-yang-library-03.txt:

 <= /p>

The document should outli= ne the relationship to schema subtree and get-schema operation defined in r= fc6022.

 <= /p>

Is the schema leaf define= d in the draft equivalent to the schema ‘location’ defined in r= fc6022? Are the two expected to have the same value?

 <= /p>

It should also describe i= f the two capabilities (yang-library and rfc6022 schema) will be used in pa= rallel or if systems are expected to switch to yang-library over rfc6022 or if there is going to be a prescribed preference [for examp= le, should systems try to use yang-library for YANG and switch to rfc6022 s= chema only if the former is not present?].

 <= /p>

Thanks,=

Athanasios Kyparlis<= /o:p>

 <= /p>

From: i2rs [ma= ilto:i2rs-bounces@ietf.org] On Behalf Of Ersue, Mehmet (Nokia - DE/Munich)
Sent: Tuesday, December 15, 2015 3:59 PM
To: netconf@ietf.org
Cc: i2rs@ietf.org; 6tisch@ietf.org; core@ietf.org; 6lo@ietf.org
Subject: [i2rs] WG Last Call for draft-ietf-netconf-restconf-09, dra= ft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

 

Dear NETCONF WG,

 <= /p>

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

 <= /p>

http://tools.ietf.org/html/d= raft-ietf-netconf-restconf-09.txt

http://tools.ietf.org/html= /draft-ietf-netconf-yang-patch-07.txt

http://tools.ietf.org/ht= ml/draft-ietf-netconf-yang-library-03.txt

 

Please review and send yo= ur comments to the NETCONF WG mailing list by January 22, 2015 EOB PT.

 <= /p>

The drafts on RESTCONF, Y= ANG patch and YANG library are planned to publish as standard track documen= ts.

 <= /p>

As RESTCONF is a major pr= otocol we seek a detailed and thorough review within NETCONF WG but also by= the related WGs before publishing.

Therefore the WGLC is pla= nned to finalize on January 22th (covering the holiday time in between) and= APP, INT and RTG area ADs will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to review.

 <= /p>

Please take your time to = review the documents and send your comments to the NETCONF maillist by the = deadline.

Please state on NETCONF m= aillist also explicitly, whether you have read/reviewed and whether you sup= port the publication.

Furthermore please indica= te if you plan to implement or have already implementations for RESTCONF and its supplementary drafts= .

 <= /p>

Thank you for your review= and kind help getting RESTCONF specifications stable.

 <= /p>

Best Regards,<= /span>

Mehmet and Mahesh

 <= /p>

--_000_4F4A512E4B3EB845A006F77C995C22A73C8D0AC3eusaamb107erics_-- From nobody Wed Dec 16 08:43: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 97DFF1A1B28 for ; Wed, 16 Dec 2015 08:43:29 -0800 (PST) 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 Mq1a1uklqDz9 for ; Wed, 16 Dec 2015 08:43:27 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010: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 3FB131A1A70 for ; Wed, 16 Dec 2015 08:43:27 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id l133so33144923lfd.2 for ; Wed, 16 Dec 2015 08:43:27 -0800 (PST) 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=m4gq7oa4RyKwk58eondyO783yXzhWevPqI0opnuadq0=; b=ZXrsrrn/T5r/f6cW6e0b5h2SxjY+QHAQ3eAH2zXVpDwfHFOhmfxTRdqEKORrbhTVE0 tSkBtCgeD8TsKdWrOgOTotj6A7QQWqQ3Qv65uWqIIrwurTjk+j2Zc02xpsRyUPildDRe v5UEibYogBL+BZaXsNtfB1inYI2azNImCe0fHgdaDDkZ8FJ8gSiSzbGzc0lrLn7qUzLh fvFwRyxCeQdcQ3KCNFMP/XPXzohWdhDb0Xeg+hWtpXCYx/jX0j4HavBKHr+ghBBmD8tr R8R5mx3s1yj96Z5tmx3BZTGPXzNgyyyCL5datja+PtHwharpv4eUT+A8ypYU+JxZCBPw iojQ== 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=m4gq7oa4RyKwk58eondyO783yXzhWevPqI0opnuadq0=; b=DgVrj9UqGOMbI+PBaCQ3TY1Oboe4Aln3VNR0VXIUo7DqNPPB+Q8b/k+vL+zJ2AWwdX Sv/N51ZL3qZc8STKLEz2cAZ2uvUHf/C97nB/WLQxWrgruA9j4lFfXFTTMsWZ3AiHL8cC q5l7SsqUSyDHjmtyj4IaSM+seTmw7QW3+hMLSOAaf9omLCDyAQMatYY0wMVPW4pDfWuN 7pN6U6t0UR1rJvAbaebNd9cMvyF5gga9N1oJ3uPCzmM1G5qIXNDHgwrDmD44lpipzDsK /AeF5hZeVAIULjQ/aurOs1UYcRN+u+ZNMK3WgnVR+qnXxDVijrEOeg0N5qRxzz0SfPOA TJAw== X-Gm-Message-State: ALoCoQmo56IbVTR52tP/hGwqGG8yAr+q/we1bT3TEl0PUHb0MvplJ0v8/3U4XYj4YFPi2FGafyRrd25jQpPHRo1Qbht7TNRBKA== MIME-Version: 1.0 X-Received: by 10.25.82.144 with SMTP id g138mr11161593lfb.8.1450284205420; Wed, 16 Dec 2015 08:43:25 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 16 Dec 2015 08:43:25 -0800 (PST) In-Reply-To: <4F4A512E4B3EB845A006F77C995C22A73C8D0AC3@eusaamb107.ericsson.se> References: <4F4A512E4B3EB845A006F77C995C22A73C8D0AC3@eusaamb107.ericsson.se> Date: Wed, 16 Dec 2015 08:43:25 -0800 Message-ID: From: Andy Bierman To: Athanasios Kyparlis Content-Type: multipart/alternative; boundary=001a1141da8ee360480527069ab2 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2015 16:43:29 -0000 --001a1141da8ee360480527069ab2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The WG decided there was no relationship between the YANG library and the netconf-state schema list. What should this draft say? There is overlap, but not complete overlap. The netconf-state list supports any schema language, not just YANG. The YANG library is used by RESTCONF and YANG 1.1. It has conformance info that does not exist in the schema list. A client could use one or the other, or both of these lists. Andy On Wed, Dec 16, 2015 at 8:28 AM, Athanasios Kyparlis < athanasios.kyparlis@ericsson.com> wrote: > This is a comment for draft-ietf-netconf-yang-library-03.txt: > > > > The document should outline the relationship to schema subtree and > get-schema operation defined in rfc6022. > > > > Is the schema leaf defined in the draft equivalent to the schema > =E2=80=98location=E2=80=99 defined in rfc6022? Are the two expected to ha= ve the same value? > > > > It should also describe if the two capabilities (yang-library and rfc6022 > schema) will be used in parallel or if systems are expected to switch to > yang-library over rfc6022 or if there is going to be a prescribed > preference [for example, should systems try to use yang-library for YANG > and switch to rfc6022 schema only if the former is not present?]. > > > > Thanks, > > Athanasios Kyparlis > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Ersue, Mehmet > (Nokia - DE/Munich) > *Sent:* Tuesday, December 15, 2015 3:59 PM > *To:* netconf@ietf.org > *Cc:* i2rs@ietf.org; 6tisch@ietf.org; core@ietf.org; 6lo@ietf.org > *Subject:* [i2rs] WG Last Call for draft-ietf-netconf-restconf-09, > draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 > > > > Dear NETCONF WG, > > > > we hereby issue a WG Last Call for the drafts below: > > > > http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt > > http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt > > http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt > > > > Please review and send your comments to the NETCONF WG mailing list by > January 22, 2015 EOB PT. > > > > The drafts on RESTCONF, YANG patch and YANG library are planned to publis= h > as standard track documents. > > > > As RESTCONF is a major protocol we seek a detailed and thorough review > within NETCONF WG but also by the related WGs before publishing. > > Therefore the WGLC is planned to finalize on January 22th (covering the > holiday time in between) and APP, INT and RTG area ADs will be informed a= s > well as Core, I2RS, 6lo, and 6tisch WGs are invited to review. > > > > Please take your time to review the documents and send your comments to > the NETCONF maillist by the deadline. > > Please state on NETCONF maillist also explicitly, whether you have > read/reviewed and whether you support the publication. > > Furthermore please indicate if you plan to implement or have already > implementations for RESTCONF and its supplementary drafts. > > > > Thank you for your review and kind help getting RESTCONF specifications > stable. > > > > Best Regards, > > Mehmet and Mahesh > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a1141da8ee360480527069ab2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The WG decided there was no relatio= nship between the YANG library and the netconf-state
schema list.=

What should this draft say?=C2=A0 There is overla= p, but not complete overlap.
The netconf-state list supports any = schema language, not just YANG.

The YANG library i= s used by RESTCONF and YANG 1.1.
It has conformance info that doe= s not exist in the schema list.

A client could use= one or the other, or both of these lists.



Andy

=
On Wed, Dec 16, 2015 at 8:28 AM, Athanasios = Kyparlis <athanasios.kyparlis@ericsson.com> w= rote:

This is a comment for dra= ft-ietf-netconf-yang-library-03.txt:

=C2=A0

The document should outli= ne the relationship to schema subtree and get-schema operation defined in r= fc6022.

=C2=A0

Is the schema leaf define= d in the draft equivalent to the schema =E2=80=98location=E2=80=99 defined = in rfc6022? Are the two expected to have the same value?

=C2=A0

It should also describe i= f the two capabilities (yang-library and rfc6022 schema) will be used in pa= rallel or if systems are expected to switch to yang-library over rfc6022 or if there is going to be a prescribed preference [for examp= le, should systems try to use yang-library for YANG and switch to rfc6022 s= chema only if the former is not present?].

=C2=A0

Thanks,

Athanasios Kyparlis

=C2=A0

From: i2rs [ma= ilto:i2rs-bounce= s@ietf.org] On Behalf Of Ersue, Mehmet (Nokia - DE/Munich)
Sent: Tuesday, December 15, 2015 3:59 PM
To: netconf@ie= tf.org
Cc: i2rs@ietf.org= ; 6tisch@ietf.org<= /a>; core@ietf.org; = 6lo@ietf.org
Subject: [i2rs] WG Last Call for draft-ietf-netconf-restconf-09, dra= ft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03=

=C2=A0

Dear NETCONF WG,

=C2=A0

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

=C2=A0

http://too= ls.ietf.org/html/draft-ietf-netconf-restconf-09.txt

http://t= ools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt

http:/= /tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt

=C2=A0

Please review and send yo= ur comments to the NETCONF WG mailing list by January 22, 2015 EOB PT.

=C2=A0

The drafts on RESTCONF, Y= ANG patch and YANG library are planned to publish as standard track documen= ts.

=C2=A0

As RESTCONF is a major pr= otocol we seek a detailed and thorough review within NETCONF WG but also by= the related WGs before publishing.

Therefore the WGLC is pla= nned to finalize on January 22th (covering the holiday time in between) and= APP, INT and RTG area ADs will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to review.

=C2=A0

Please take your time to = review the documents and send your comments to the NETCONF maillist by the = deadline.

Please state on NETCONF m= aillist also explicitly, whether you have read/reviewed and whether you sup= port the publication.

Furthermore please indica= te if you plan to implement or have already implementations for RESTCONF and its supplementary drafts= .

=C2=A0

Thank you for your review= and kind help getting RESTCONF specifications stable.=

=C2=A0

Best Regards,

Mehmet and Mahesh<= u>

=C2=A0


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


--001a1141da8ee360480527069ab2-- From nobody Wed Dec 16 11:00:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2B1A88BD for ; Wed, 16 Dec 2015 11:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4ZyWuyPMXqM for ; Wed, 16 Dec 2015 11:00:06 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C573D1A888D for ; Wed, 16 Dec 2015 10:59:13 -0800 (PST) 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.355.16; Wed, 16 Dec 2015 18:59:12 +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.0355.012; Wed, 16 Dec 2015 18:59:11 +0000 From: Kent Watsen To: t.petch , Benoit Claise , NETCONF Thread-Topic: [Netconf] draft-ietf-netconf-call-home: one week review period Thread-Index: AQHRN2Q/AAKWEU0VAEuTicTbq77KWZ7MPj4AgAE9ILmAACm5AA== Date: Wed, 16 Dec 2015 18:59:11 +0000 Message-ID: <90DCB502-A719-47C0-855A-7970940DB7F3@juniper.net> References: <56705828.2040408@cisco.com> <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> <014a01d137f4$c9b6bfc0$4001a8c0@gateway.2wire.net> In-Reply-To: <014a01d137f4$c9b6bfc0$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.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:0JRryrkSGIuecFIbh8ys400aY1vGISx/f22J30Lmf7mGkb0vzDeThpi3JL/Xw1rld+Vk2JPpnA6E4IEq/+prskC2bz1YZiFbV7B/s6uVmueUDLMMGjHBfWuIe8L89l+37Pre1RvQNsGcYPsiovvKLA==; 24:Ea7QqDWddTRJPWaH78IOafgiEcZ8NqLBJQ7aPIVPu+jwZQIZBVY9jOzZ2D3ME5ICkVKBC8QFAPPu/OVbz2qvz+y2LEEtmiNg1svyBrtq2hY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; 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)(10201501046); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(43784003)(57704003)(53234004)(199003)(189002)(36756003)(4001350100001)(5001770100001)(81156007)(189998001)(106116001)(5001960100002)(5004730100002)(99286002)(2950100001)(82746002)(92566002)(83506001)(101416001)(66066001)(106356001)(15975445007)(107886002)(97736004)(5002640100001)(83716003)(54356999)(2900100001)(87936001)(77096005)(33656002)(19580395003)(105586002)(10400500002)(6116002)(76176999)(551544002)(86362001)(1096002)(122556002)(3846002)(586003)(40100003)(575784001)(5008740100001)(50986999)(230783001)(102836003)(1220700001)(7059030)(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: <48DCF5BC6572C44FBEF59ECBE6A384F9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2015 18:59:11.4537 (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: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2015 19:00:09 -0000 DQpIaSBUb20sDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcsIHdoaWxlIG1vc3Qgb2YgdGhpcyB0 aGUgZWRpdG9yIGNhbiBjYXRjaCwgYSBjb3VwbGUgaXNzdWVzIHlvdSByYWlzZWQgYXJlIGEgbW9y ZSBpbnZvbHZlZCAoc2VlIGJlbG93KSwgdGh1cyBJIHBsYW4gdG8gcG9zdCBhIC0xNiB3aXRoIHRo ZXNlIGZpeGVzLCBhbG9uZyB3aXRoIHRoZSBmaXggZm9yIHRoZSBpc3N1ZSB0aGF0IEkgZm91bmQg ZWFybGllci4NCg0KUmVnYXJkaW5nIHlvdXIgY29tbWVudHM6DQoNCg0KDQoNCg0KDQoNCj5JIG1p c3NlZCB0aGF0IG9uZSBpbiBDLjEgYnV0IEkgaG9wZSB0aGF0IHRoZSBSRkMgRWRpdG9yIGNhdGNo ZXMgYSBmZXcNCj5tb3JlISBGb3IgZXhhbXBsZSwNCj4NCj4idGhlIGF0dGFja2VyIGRvZXNuJ3Qg cG9zc2VzIGEgdmFsaWQga2V5LiAgIg0KPg0KPnBvc3Mgdi50LiAnIHRvIG1hbmdsZSB0aGUgbGFu Z3VhZ2UgYXMgYSByZXN1bHQgb2YgYSByZXZpZXcgc3VjaCBhcyB0aGF0DQo+b2YNCj50aGUgSUVT RycgOi0pDQoNCmZpeGVkISAgKHMvcG9zc2VzL3Bvc3Nlc3MvKQ0KDQoNCg0KPi0gdGhlIEktRCB1 c2VzIGEgbWl4dHVyZSBvZiAnSXNzdWVyJyBhbmQgJ3RydXN0IGFuY2hvcicgc2VlbWluZ2x5IGJv dGgNCj50byByZWZlciB0byB0aGUgdG9wIG9mIHRoZSBjaGFpbiBvZiBjZXJ0aWZpY2F0ZXM7IHdo YXQgaXMgdGhlDQo+c2lnbmlmaWNhbmNlIG9mIHRoaXM/ICBGb3IgbWUsIFRydXN0IEFuY2hvciBp cyB3aGVyZSBpdCBhbGwgc3RhcnRzLA0KPndoZXJlIHlvdSBtdXN0IHZlcmlmeSB0aGUgY2hhaW4g b2YgY2VydGlmaWNhdGVzIHRvIHdoZXJlYXMgSXNzdWVyIGlzIHRoZQ0KPmlzc3VlciBvZiBhIGNl cnRpZmljYXRlLCBhbnkgY2VydGlmaWNhdGUsIGZyb20gZW5kIGVudGl0eSB2aWENCj5pbnRlcm1l ZGlhdGUgdG8gdHJ1c3QgYW5jaG9yLCBidXQgSSByZWFsaXNlIHRoYXQgdGhhdCBvcGluaW9ucyBv biB0aGlzDQo+dmFyeS4gIFJGQzYxMjUgdXNlcyB0cnVzdCBhbmNob3IgZm9yIHRoZSB0b3Agb2Yg dGhlIGNoYWluIHdoaWxlDQo+UkZDNTI4MCB1c2VzIElzc3VlciBmb3IsIHdlbGwsIHRoZSBpc3N1 ZXIgb2YgYW55IGNlcnRpZmljYXRlLg0KDQpUaGUgZHJhZnQgb3JpZ2luYWxseSBoYWQgVHJ1c3Qg QW5jaG9yIGV2ZXJ5d2hlcmUsIGJ1dCB0aGVuIEpvZSBTYWxvd2V5IChUTFMgY28tY2hhaXIpIGFs c28gc2FpZCB0aGF0IGEgIlRydXN0IEFuY2hvciIgdHlwaWNhbGx5IHJlZmVycyB0byBhIHNlbGYt c2lnbmVkIGNlcnQgKGEgcm9vdCBjZXJ0KSwgYW5kIHNvIEkgc3RhcnRlZCB3cml0aW5nIOKAnElz c3VlcuKAnSBpbiBuZXcgdGV4dCwgYnV0IG5ldmVyIHVwZGF0ZWQgdGhlIG9sZCB0ZXh0LiAgIA0K DQpGaXhlZCEgIChyZXBsYWNlZCDigJxUcnVzdCBBbmNob3LigJ0gd2l0aCDigJxJc3N1ZXLigJ0s IGFuZCByZW1vdmVkIGNhcGl0YWxpemF0aW9uIG9uIOKAnGlzc3VlcuKAnSkNCg0KDQoNCg0KDQo+ LSBsaWtld2lzZSwgdGhlIGNsaWVudCBzZWN1cml0eSBjcmVkZW50aWFsIHVzZWQgZm9yIFJFU1RD T05GIGlzIGEgbWl4IG9mDQo+J3NoYXJlZCBzZWNyZXQnLCAncGFzc3dvcmQnIG9yICdzaGFyZWQg a2V5JyAtIHRoZSBsYXN0IHNlZW1zIHdyb25nIHRvDQo+bWUuICBJIG5vdGUgdGhhdCB0aGUgY2l0 ZWQgUkZDLCA3NjE2IGFuZCA3NjE3LCB1c2UgcGFzc3dvcmQuDQoNCkZpeGVkISAgKHJlcGxhY2Vk ICJzaGFyZWQga2V5IiB3aXRoICJzaGFyZWQgc2VjcmV0IChlLmcuLCBhIHBhc3N3b3JkKeKAnSkN Cg0KDQoNCj4tIEMuNiAiQ2xpZW50cyBTSE9VTEQNCj4gICAgICAgZW5zdXJlIHRoYXQgdGhlIElz c3VlciB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgcHJlc2VudGVkDQo+ICAgICAgIGNlcnRpZmlj YXRlIGRlZmluZXMgdGhlIG5hbWVzcGFjZSBmb3IgdGhlIGlkZW50aWZpZXJzIG9mDQo+ICAgICAg IGludGVyZXN0LiAgIg0KPg0KPkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzLiAgSWYgYSBjZXJ0aWZp Y2F0ZSBoYXMgYSBkTlNOYW1lIG9yIGlQQWRkcmVzcyBpbg0KPml0LCBpbiB3aGF0IHNlbnNlIGRv ZXMgdGhlIGNlcnRpZmljYXRlIGRlZmluZSB0aGUgbmFtZXNwYWNlPw0KDQpJ4oCZbSB0aGluayB0 aGF0IHRoaXMgc2VudGVuY2UgaW4gQy02IHNob3VsZCBiZSByZW1vdmVkLCBhcyB0aGUgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzYXlzIGl0IGJldHRlcjoNCg0KICAgIEZvciBjYXNl cyB3aGVuIHRoZSBORVRDT05GL1JFU1RDT05GIHNlcnZlciBwcmVzZW50cyBhbiBYLjUwOQ0KICAg IGNlcnRpZmljYXRlLCBORVRDT05GL1JFU1RDT05GIGNsaWVudHMgc2hvdWxkIGVuc3VyZSB0aGF0 IHRoZQ0KICAgIGlzc3VlciBjZXJ0aWZpY2F0ZSB1c2VkIGZvciBjZXJ0aWZpY2F0ZSBwYXRoIHZh bGlkYXRpb24gaXMNCiAgICB1bmlxdWUgdG8gdGhlIG1hbnVmYWN0dXJlciBvZiB0aGUgc2VydmVy LiAgVGhhdCBpcywgdGhlIGNlcnRpZmljYXRlDQogICAgc2hvdWxkIG5vdCBiZWxvbmcgdG8gYSAz cmQtcGFydHkgY2VydGlmaWNhdGUgYXV0aG9yaXR5IHRoYXQNCiAgICBtaWdodCBpc3N1ZSBpbnRl cm1lZGlhdGUgY2VydGlmaWNhdGVzIGZvciBtb3JlIHRoYW4gb25lIG1hbnVmYWN0dXJlci4NCg0K Qm90aCB0aGUgc2VudGVuY2UgaW4gQy02IHNlbnRlbmNlIHRoZSB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgcGFyYWdyYXBoIHdlcmUgYWRkZWQgdG8gYWRkcmVzcyBhbiBpdGVtIGZyb20gU3Rl cGhlbiBGYXJyZWxsLiAgIFlvdSBjYW4gc2VlIHRoZW0gYm90aCBpbiBvbmUgZ2l0aHViIGNvbW1p dCBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9jYWxsLWhvbWUvY29tbWl0LzFi OWQ1NGY1ZjRiNDQxYzhjNzlkNjViMDM4MDgwYjQwMmU3ZTBhYjQuDQoNCg0KRG8gd2UgbmVlZCB0 byBnZXQgU3RlcGhlbuKAmXMgYXBwcm92YWwgdG8gcmVtb3ZlIHRoZSBzZW50ZW5jZSBpbiBDLTYg bm93PyAgIChxdWVzdGlvbiBmb3IgY2hhaXJzIG9yIEFEKQ0KDQoNCg0KDQo+LSBTLjUgIEkgYW0g c3VycHJpc2VkIHRoYXQgdGhlIFNlY3VyaXR5IHJldmlld3MgZGlkIG5vdCBtZW50aW9uIHRoZSBu ZWVkDQo+bm90IHRvIGFjdGlvbiBtZXNzYWdlcyBwcmlvciB0byBzdWNjZXNzZnVsIHVzZXIgYXV0 aGVudGljYXRpb24uICBUaGVyZQ0KPmlzIGEgc3Ryb25nIGRyaXZlIGluIHRoZSB1c2Ugb2YgVExT IGJ5IHdlYnNpdGVzIHRvIGVsaW1pbmF0ZSByb3VuZCB0cmlwcw0KPnNvIHRoYXQgdXNlciBkYXRh IGlzIHNlbnQgYmVmb3JlIGEgc2VjdXJlIGNoYW5uZWwgaGFzIGJlZW4gZXN0YWJsaXNoZWQsDQo+ d2l0aCB0aGUgZGF0YSBiZWluZyByZXNlbnQgb3IgZGlzY2FyZGVkIGlmIHRoZSBzZXR1cCBvZiB0 aGUgc2VjdXJlDQo+Y2hhbm5lbCBkb2VzIG5vdCBjb21wbGV0ZS4gIFRoaXMgcmVxdWlyZXMgYXBw bGljYXRpb25zIHRvIGtub3cgd2hhdCBpcw0KPmdvaW5nIG9uLiAgTGlrZXdpc2UsIHdoZXJlIHRo ZSB1c2VyIGF1dGhlbnRpY2F0aW9uIGlzIGEgc2VwYXJhdGUNCj5mdW5jdGlvbiwgcGVyZm9ybWVk IGFmdGVyIHRoZSAnc2VjdXJlJyBjaGFubmVsIGhhcyBiZWVuIHNldCB1cCwgaXQgbWF5DQo+YmUg b2sgZm9yIHRoZSB3ZWIgdXNlciB0byBzZW5kIGRhdGEgYW5kIGZvciB0aGUgd2ViIHNlcnZlciB0 byBhY3QgdXBvbg0KPml0LCBhbGJlaXQgbm90IGluIGEgd2F5IHRoYXQgY291bGQgY2F1c2UgaGFy bS4gIFRoZSB1c2Ugb2YgdGhlc2UNCj5wcm90b2NvbHMgYnkgTkVUQ09ORiBpcyByYXRoZXIgZGlm ZmVyZW50LCBhY3Rpbmcgb24gZGF0YSBmcm9tIGENCj55ZXQtdG8tYmUgYXV0aGVudGljYXRlZCB1 c2VyIGNvdWxkIGJlIHVuZm9ydHVuYXRlLCBhbmQgdGhlIHNlcnZlciBzaG91bGQNCj5iZSBjYXV0 aW91cyBhYm91dCBhY2NlcHRpbmcgZGF0YSB1bnRpbCB0aGUgc2VjdXJlIGNoYW5uZWwgcmVhbGx5 IGhhcw0KPmJlZW4gc2V0IHVwLiAgSSBhbSB0aGlua2luZyB0aGF0IGJlZm9yZSB0b28gbG9uZywg d2Ugd2lsbCBoYXZlIFRMUw0KPnN0YWNrcyB0aGF0IGFyZSBvcHRpbWlzZWQgZm9yIGZhc3Qgd2Vi IGFjY2VzcyBidXQgYXJlIGEgZGFuZ2VyIHRvDQo+b3BlcmF0aW9uYWwgYXBwbGljYXRpb25zLCBh bmQgc28gbWlnaHQgaGF2ZSBhZGRlZCBhIHBocmFzZSBhdCB0aGUgZW5kIG9mDQo+UzUgdG8gdGhl IGVmZmVjdCB0aGF0IGFueSB1c2VyIGRhdGEgbXVzdCBiZSB0aGVuIGRpc2NhcmRlZC4gIEJ1dCBp ZiB0aGlzDQo+d2FzIG5vdCByYWlzZWQsIHRoZW4gaXQgaXMgcHJvYmFibHkgYmVzdCBsZWZ0IHRv IGxpbmdlciBhIHdoaWxlIGxvbmdlci4NCg0KQWdyZWVkIChubyBjaGFuZ2UpDQoNCg0KDQo+LSAi IEZvciBjYXNlcyB3aGVuIHRoZSBORVRDT05GL1JFU1RDT05GIHNlcnZlciBwcmVzZW50cyBhbiBY LjUwOQ0KPiAgIGNlcnRpZmljYXRlLCBORVRDT05GL1JFU1RDT05GIGNsaWVudHMgc2hvdWxkIGVu c3VyZSB0aGF0IHRoZSBJc3N1ZXINCj4gICBjZXJ0aWZpY2F0ZSB1c2VkIGZvciBjZXJ0aWZpY2F0 ZSBwYXRoIHZhbGlkYXRpb24gaXMgdW5pcXVlIHRvIHRoZQ0KPiAgIG1hbnVmYWN0dXJlciBvZiB0 aGUgc2VydmVyLiAgVGhhdCBpcywgdGhlIGNlcnRpZmljYXRlIHNob3VsZCBub3QNCj4gICBiZWxv bmcgdG8gYSAzcmQtcGFydHkgY2VydGlmaWNhdGUgYXV0aG9yaXR5IHRoYXQgbWlnaHQgaXNzdWUN Cj4gICBpbnRlcm1lZGlhdGUgY2VydGlmaWNhdGVzIGZvciBtb3JlIHRoYW4gb25lIG1hbnVmYWN0 dXJlci4gICINCj4NCj5UaGlzIGNvbmZ1c2VzIG1lLiAgSXNzdWVyIHNlZW1zIHRvIGJlIHRydXN0 IGFuY2hvciBmcm9tIG90aGVyIHVzZXMgb2YNCj50aGUgdGVybSBzbyB0aGlzIHNlZW1zIHRvIGJl IHNheWluZyB0aGF0IGFsbCBzZXJ2ZXJzIG9mIGEgZ2l2ZW4NCj5tYW51ZmFjdHVyZXIgbXVzdCBo YXZlIGNlcnRpZmljYXRlIGNoYWlucyBsZWFkaW5nIGJhY2sgdG8gdGhlIHNhbWUgdHJ1c3QNCj5h bmNob3IgYW5kIHRoYXQgdGhhdCB0cnVzdCBhbmNob3IgbXVzdCBub3QgaXNzdWUgY2VydGlmaWNh dGVzIGZvciBhbnkNCj5vdGhlciBtYW51ZmFjdHVyZXIgLSBidXQgdGhlbiB3aGF0IGlzICdpbnRl cm1lZGlhdGUnIGRvaW5nIGluIHRoZXJlPyAgIEkNCj53b3VsZCBleHBlY3QgdGhlIG51bWJlciBv ZiBpbnRlcm1lZGlhdGUgY2VydGljYXRlcyB0byByYW5nZSBmcm9tIHplcm8gdG8NCj5uLCBidXQg aGF2ZSBvdGhlcndpc2Ugbm8gcGFydGljdWxhciBwcm9wZXJ0aWVzLg0KDQpGaXhlZCEgIChyZW1v dmVkIHdvcmQg4oCcaW50ZXJtZWRpYXRl4oCdKQ0KDQoNCg0KPkkgbm90ZSB0aGF0IHRoZSBOb3Jt YXRpdmUgcmVmZXJlbmNlIHRvIHJlc3Rjb25mIG1lYW5zIHRoYXQgdGhpcyB3aWxsIG5vdA0KPmFk dmFuY2UgZm9yIG1hbnkgbW9udGhzLCBidXQgZ3Vlc3MgdGhhdCB0aGF0IHRpbWUgaXMgYmVzdCBz cGVudCBpbiB0aGUNCj5SRkMtRWRpdG9yIHF1ZXVlLg0KDQpUcnVlLCBidXQgaG9wZWZ1bGx5IG5v dCBmb3IgdG9vIG1hbnkgbW9udGhzISAgOykNCg0KDQoNCj5Ub20gUGV0Y2gNCg0KVGhhbmtzIGFn YWluLA0KS2VudA0KDQoNCg0K From nobody Wed Dec 16 11:44: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 6C0931A891C for ; Wed, 16 Dec 2015 11:44:23 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, 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 6aICV8_YUabZ for ; Wed, 16 Dec 2015 11:44:21 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15B81A88D6 for ; Wed, 16 Dec 2015 11:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5828; q=dns/txt; s=iport; t=1450295060; x=1451504660; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=9nHhfxQkC3EHc5k+bjQqEWNqP9xj0NGN/0Odd/fW1Gs=; b=UJaqkYfqFlI8O8ybfRhi1+cxGvRmTfSq510GIoynVXh8NG9+N5PqeqLY 4Cz8XEAzulvey2Qqq9fG9mzt6Qk7dDyeIvnDsgcVZ++Pphvcl+/w0fEU2 wKDF/CC2vrd4UU5+7NoJYCUvy/1ffFFXVvK9pw9nebSijV142RjMY29ME Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrBACRvnFW/xbLJq1ehAzAUiOFMDoCg?= =?us-ascii?q?XkBAQEBAQGBC4Q1AQEDASMPAQVAEQsODAIFDwECBAUGAgIJAwIBAgFFBgEMCAE?= =?us-ascii?q?BiCMIDqwIhTGMVwEBAQEBAQEDAQEBAQEBARgEgQGFVYN3gQaEQmcPAoI9gUkBB?= =?us-ascii?q?Idfjx2FOYgPgVyHSpABg3RjghEdgVc9OWIFgl0lgSQBAQE?= X-IronPort-AV: E=Sophos;i="5.20,437,1444694400"; d="scan'208";a="609070252" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2015 19:44:16 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBGJiGF5018100; Wed, 16 Dec 2015 19:44:16 GMT To: Kent Watsen , "t.petch" , NETCONF , Stephen Farrell References: <56705828.2040408@cisco.com> <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> <014a01d137f4$c9b6bfc0$4001a8c0@gateway.2wire.net> <90DCB502-A719-47C0-855A-7970940DB7F3@juniper.net> From: Benoit Claise Message-ID: <5671BF10.4010506@cisco.com> Date: Wed, 16 Dec 2015 20:44:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <90DCB502-A719-47C0-855A-7970940DB7F3@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2015 19:44:23 -0000 Including Stephen, Stephen, there is a question for you in there. > Hi Tom, > > Thanks for your review, while most of this the editor can catch, a couple issues you raised are a more involved (see below), thus I plan to post a -16 with these fixes, along with the fix for the issue that I found earlier. > > Regarding your comments: > > > > > > > >> I missed that one in C.1 but I hope that the RFC Editor catches a few >> more! For example, >> >> "the attacker doesn't posses a valid key." >> >> poss v.t. ' to mangle the language as a result of a review such as that >> of >> the IESG' :-) > fixed! (s/posses/possess/) > > > >> - the I-D uses a mixture of 'Issuer' and 'trust anchor' seemingly both >> to refer to the top of the chain of certificates; what is the >> significance of this? For me, Trust Anchor is where it all starts, >> where you must verify the chain of certificates to whereas Issuer is the >> issuer of a certificate, any certificate, from end entity via >> intermediate to trust anchor, but I realise that that opinions on this >> vary. RFC6125 uses trust anchor for the top of the chain while >> RFC5280 uses Issuer for, well, the issuer of any certificate. > The draft originally had Trust Anchor everywhere, but then Joe Salowey (TLS co-chair) also said that a "Trust Anchor" typically refers to a self-signed cert (a root cert), and so I started writing “Issuer†in new text, but never updated the old text. > > Fixed! (replaced “Trust Anchor†with “Issuerâ€, and removed capitalization on “issuerâ€) > > > > > >> - likewise, the client security credential used for RESTCONF is a mix of >> 'shared secret', 'password' or 'shared key' - the last seems wrong to >> me. I note that the cited RFC, 7616 and 7617, use password. > Fixed! (replaced "shared key" with "shared secret (e.g., a password)â€) > > > >> - C.6 "Clients SHOULD >> ensure that the Issuer used to authenticate the presented >> certificate defines the namespace for the identifiers of >> interest. " >> >> I don't understand this. If a certificate has a dNSName or iPAddress in >> it, in what sense does the certificate define the namespace? > I’m think that this sentence in C-6 should be removed, as the Security Considerations section says it better: > > For cases when the NETCONF/RESTCONF server presents an X.509 > certificate, NETCONF/RESTCONF clients should ensure that the > issuer certificate used for certificate path validation is > unique to the manufacturer of the server. That is, the certificate > should not belong to a 3rd-party certificate authority that > might issue intermediate certificates for more than one manufacturer. > > Both the sentence in C-6 sentence the the Security Considerations paragraph were added to address an item from Stephen Farrell. You can see them both in one github commit here: https://github.com/netconf-wg/call-home/commit/1b9d54f5f4b441c8c79d65b038080b402e7e0ab4. > > > Do we need to get Stephen’s approval to remove the sentence in C-6 now? (question for chairs or AD) Yes. Regards, Benoit > > > > >> - S.5 I am surprised that the Security reviews did not mention the need >> not to action messages prior to successful user authentication. There >> is a strong drive in the use of TLS by websites to eliminate round trips >> so that user data is sent before a secure channel has been established, >> with the data being resent or discarded if the setup of the secure >> channel does not complete. This requires applications to know what is >> going on. Likewise, where the user authentication is a separate >> function, performed after the 'secure' channel has been set up, it may >> be ok for the web user to send data and for the web server to act upon >> it, albeit not in a way that could cause harm. The use of these >> protocols by NETCONF is rather different, acting on data from a >> yet-to-be authenticated user could be unfortunate, and the server should >> be cautious about accepting data until the secure channel really has >> been set up. I am thinking that before too long, we will have TLS >> stacks that are optimised for fast web access but are a danger to >> operational applications, and so might have added a phrase at the end of >> S5 to the effect that any user data must be then discarded. But if this >> was not raised, then it is probably best left to linger a while longer. > Agreed (no change) > > > >> - " For cases when the NETCONF/RESTCONF server presents an X.509 >> certificate, NETCONF/RESTCONF clients should ensure that the Issuer >> certificate used for certificate path validation is unique to the >> manufacturer of the server. That is, the certificate should not >> belong to a 3rd-party certificate authority that might issue >> intermediate certificates for more than one manufacturer. " >> >> This confuses me. Issuer seems to be trust anchor from other uses of >> the term so this seems to be saying that all servers of a given >> manufacturer must have certificate chains leading back to the same trust >> anchor and that that trust anchor must not issue certificates for any >> other manufacturer - but then what is 'intermediate' doing in there? I >> would expect the number of intermediate certicates to range from zero to >> n, but have otherwise no particular properties. > Fixed! (removed word “intermediateâ€) > > > >> I note that the Normative reference to restconf means that this will not >> advance for many months, but guess that that time is best spent in the >> RFC-Editor queue. > True, but hopefully not for too many months! ;) > > > >> Tom Petch > Thanks again, > Kent > > > From nobody Wed Dec 16 13:58: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 6A7721A8BC4 for ; Wed, 16 Dec 2015 13:58:06 -0800 (PST) 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 r1vrd84113oh for ; Wed, 16 Dec 2015 13:58:03 -0800 (PST) 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 8300F1A8AF3 for ; Wed, 16 Dec 2015 13:58:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CAC6DBE7C; Wed, 16 Dec 2015 21:58:01 +0000 (GMT) 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 9y74_fHXapyz; Wed, 16 Dec 2015 21:58:00 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.31.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6B295BE51; Wed, 16 Dec 2015 21:57:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1450303080; bh=pNeaQSWPQtb6xjavaSKpzGX8bf5pczJl/PyDlaxIKss=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SInBIz2YjYxceePq1hjNMCvUTQRlb+vsJeeESKqpJQ6lCYqWH15xr7MKkGLs+kqBU F1fkWJkaoUfrDRiksQFJlaaF032ak9PVW6GWJijjoknz9sObPynhYgCTII7M5gQUWM Glopm8LnpNLEAiREVjhDK4Yx9wzVRYiD2CkGSZJI= To: Benoit Claise , Kent Watsen , "t.petch" , NETCONF References: <56705828.2040408@cisco.com> <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> <014a01d137f4$c9b6bfc0$4001a8c0@gateway.2wire.net> <90DCB502-A719-47C0-855A-7970940DB7F3@juniper.net> <5671BF10.4010506@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5671DE67.707@cs.tcd.ie> Date: Wed, 16 Dec 2015 21:57:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5671BF10.4010506@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 16 Dec 2015 21:58:06 -0000 Hi Benoit. First, thanks to Benoit and Kent for explaining this to me off-list. (I needed the explanation;-) The changes below seem fine to me, thanks for checking, S. On 16/12/15 19:44, Benoit Claise wrote: > Including Stephen, > > Stephen, there is a question for you in there. >> Hi Tom, >> >> Thanks for your review, while most of this the editor can catch, a >> couple issues you raised are a more involved (see below), thus I plan >> to post a -16 with these fixes, along with the fix for the issue that >> I found earlier. >> >> Regarding your comments: >> >> >> >> >> >> >> >>> I missed that one in C.1 but I hope that the RFC Editor catches a few >>> more! For example, >>> >>> "the attacker doesn't posses a valid key." >>> >>> poss v.t. ' to mangle the language as a result of a review such as that >>> of >>> the IESG' :-) >> fixed! (s/posses/possess/) >> >> >> >>> - the I-D uses a mixture of 'Issuer' and 'trust anchor' seemingly both >>> to refer to the top of the chain of certificates; what is the >>> significance of this? For me, Trust Anchor is where it all starts, >>> where you must verify the chain of certificates to whereas Issuer is the >>> issuer of a certificate, any certificate, from end entity via >>> intermediate to trust anchor, but I realise that that opinions on this >>> vary. RFC6125 uses trust anchor for the top of the chain while >>> RFC5280 uses Issuer for, well, the issuer of any certificate. >> The draft originally had Trust Anchor everywhere, but then Joe Salowey >> (TLS co-chair) also said that a "Trust Anchor" typically refers to a >> self-signed cert (a root cert), and so I started writing “Issuer†in >> new text, but never updated the old text. >> >> Fixed! (replaced “Trust Anchor†with “Issuerâ€, and removed >> capitalization on “issuerâ€) >> >> >> >> >> >>> - likewise, the client security credential used for RESTCONF is a mix of >>> 'shared secret', 'password' or 'shared key' - the last seems wrong to >>> me. I note that the cited RFC, 7616 and 7617, use password. >> Fixed! (replaced "shared key" with "shared secret (e.g., a password)â€) >> >> >> >>> - C.6 "Clients SHOULD >>> ensure that the Issuer used to authenticate the presented >>> certificate defines the namespace for the identifiers of >>> interest. " >>> >>> I don't understand this. If a certificate has a dNSName or iPAddress in >>> it, in what sense does the certificate define the namespace? >> I’m think that this sentence in C-6 should be removed, as the Security >> Considerations section says it better: >> >> For cases when the NETCONF/RESTCONF server presents an X.509 >> certificate, NETCONF/RESTCONF clients should ensure that the >> issuer certificate used for certificate path validation is >> unique to the manufacturer of the server. That is, the certificate >> should not belong to a 3rd-party certificate authority that >> might issue intermediate certificates for more than one >> manufacturer. >> >> Both the sentence in C-6 sentence the the Security Considerations >> paragraph were added to address an item from Stephen Farrell. You >> can see them both in one github commit here: >> https://github.com/netconf-wg/call-home/commit/1b9d54f5f4b441c8c79d65b038080b402e7e0ab4. >> >> >> >> Do we need to get Stephen’s approval to remove the sentence in C-6 >> now? (question for chairs or AD) > Yes. > > Regards, Benoit >> >> >> >> >>> - S.5 I am surprised that the Security reviews did not mention the need >>> not to action messages prior to successful user authentication. There >>> is a strong drive in the use of TLS by websites to eliminate round trips >>> so that user data is sent before a secure channel has been established, >>> with the data being resent or discarded if the setup of the secure >>> channel does not complete. This requires applications to know what is >>> going on. Likewise, where the user authentication is a separate >>> function, performed after the 'secure' channel has been set up, it may >>> be ok for the web user to send data and for the web server to act upon >>> it, albeit not in a way that could cause harm. The use of these >>> protocols by NETCONF is rather different, acting on data from a >>> yet-to-be authenticated user could be unfortunate, and the server should >>> be cautious about accepting data until the secure channel really has >>> been set up. I am thinking that before too long, we will have TLS >>> stacks that are optimised for fast web access but are a danger to >>> operational applications, and so might have added a phrase at the end of >>> S5 to the effect that any user data must be then discarded. But if this >>> was not raised, then it is probably best left to linger a while longer. >> Agreed (no change) >> >> >> >>> - " For cases when the NETCONF/RESTCONF server presents an X.509 >>> certificate, NETCONF/RESTCONF clients should ensure that the Issuer >>> certificate used for certificate path validation is unique to the >>> manufacturer of the server. That is, the certificate should not >>> belong to a 3rd-party certificate authority that might issue >>> intermediate certificates for more than one manufacturer. " >>> >>> This confuses me. Issuer seems to be trust anchor from other uses of >>> the term so this seems to be saying that all servers of a given >>> manufacturer must have certificate chains leading back to the same trust >>> anchor and that that trust anchor must not issue certificates for any >>> other manufacturer - but then what is 'intermediate' doing in there? I >>> would expect the number of intermediate certicates to range from zero to >>> n, but have otherwise no particular properties. >> Fixed! (removed word “intermediateâ€) >> >> >> >>> I note that the Normative reference to restconf means that this will not >>> advance for many months, but guess that that time is best spent in the >>> RFC-Editor queue. >> True, but hopefully not for too many months! ;) >> >> >> >>> Tom Petch >> Thanks again, >> Kent >> >> >> > From nobody Wed Dec 16 14:14:06 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 4C4081A8FD6; Wed, 16 Dec 2015 14:14:03 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151216221403.7633.98728.idtracker@ietfa.amsl.com> Date: Wed, 16 Dec 2015 14:14:03 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-16.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 22:14:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-16.txt Pages : 14 Date : 2015-12-16 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 16 14:19: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 2DC6F1A8FD4 for ; Wed, 16 Dec 2015 14:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flf2djde0ofL for ; Wed, 16 Dec 2015 14:19:05 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159071A8FD3 for ; Wed, 16 Dec 2015 14:19:04 -0800 (PST) Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 16 Dec 2015 22:19:02 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0361.006; Wed, 16 Dec 2015 22:19:02 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-16.txt Thread-Index: AQHROE8e09xVJxF2XEa4dTcc9X2qrJ7N2xeA Date: Wed, 16 Dec 2015 22:19:01 +0000 Message-ID: <6A33CEF0-C0F5-46CE-8991-CB282AA02D72@juniper.net> References: <20151216221403.7633.98728.idtracker@ietfa.amsl.com> In-Reply-To: <20151216221403.7633.98728.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.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 5:+RWJAA9vKPnWJwaKnzzUyCLp7WNmUBYO37poUcUw8Q2uMwe5siJB3Yx65iiPT0LvMFRnfDaPoUWcG2tsd4p7903Ckq6up/hQmGwk+eI7tBv0vi9ZMZ6ra6W1Fe9d6KIq2lRVltq9dNeAWOd7gmp6AA==; 24:8MkZ0lLDteGrZdX93kXxhO5bEBTWBOKjfawIQpgUTXE8hHhMS/fFbSnizxlbzNBk+gACI+TXkXTHfrC2JeRV9g7c+JAzD/UqFfHI4LQC+2c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450; 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)(10201501046); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; x-forefront-prvs: 0792DBEAD0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(24454002)(377424004)(199003)(479174004)(377454003)(189002)(5008740100001)(1096002)(36756003)(1730700002)(97736004)(11100500001)(189998001)(54356999)(76176999)(81156007)(4001150100001)(5004730100002)(6116002)(4001350100001)(92566002)(87936001)(50986999)(83506001)(102836003)(3846002)(586003)(82746002)(5001960100002)(2501003)(83716003)(107886002)(110136002)(1220700001)(33656002)(77096005)(122556002)(66066001)(15975445007)(106116001)(40100003)(105586002)(450100001)(230783001)(106356001)(99286002)(5002640100001)(86362001)(2351001)(19580405001)(2950100001)(101416001)(2900100001)(10400500002)(19580395003)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.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: <37E11724F4CF224B9F0FCB078ABE1792@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2015 22:19:01.9218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-16.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 22:19:07 -0000 DQpUaGlzIHZlcnNpb24gZml4ZXMgdGhlIGlzc3VlIEkgZm91bmQgYXMgd2VsbCBhcyB0aG9zZSBm b3VuZCBieSBUb20sIGluY2x1ZGluZyB0aGUgb25lIHRoYXQgU3RlcGhlbiBGYXJyZWxsIGNvbmZp cm1lZC4gICBUaGFua3MgVG9tIQ0KDQoNCkFueSBvdGhlciBjb21tZW50cyBiZWZvcmUgdGhlIEFE 4oCZcyAxLXdlZWsgcmV2aWV3IGV4cGlyZXM/DQoNCktlbnQNCg0KDQpPbiAxMi8xNi8xNSwgNTox NCBQTSwgIk5ldGNvbmYgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPG5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBORVRDT05GIENhbGwg SG9tZSBhbmQgUkVTVENPTkYgQ2FsbCBIb21lDQo+ICAgICAgICBBdXRob3IgICAgICAgICAgOiBL ZW50IFdhdHNlbg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1o b21lLTE2LnR4dA0KPglQYWdlcyAgICAgICAgICAgOiAxNA0KPglEYXRlICAgICAgICAgICAgOiAy MDE1LTEyLTE2DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBSRkMgcHJlc2VudHMgTkVUQ09ORiBD YWxsIEhvbWUgYW5kIFJFU1RDT05GIENhbGwgSG9tZSwgd2hpY2gNCj4gICBlbmFibGUgYSBORVRD T05GIG9yIFJFU1RDT05GIHNlcnZlciB0byBpbml0aWF0ZSBhIHNlY3VyZSBjb25uZWN0aW9uDQo+ ICAgdG8gYSBORVRDT05GIG9yIFJFU1RDT05GIGNsaWVudCByZXNwZWN0aXZlbHkuDQo+DQo+DQo+ VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9t ZS8NCj4NCj5UaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0x Ng0KPg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLWNh bGwtaG9tZS0xNg0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0K PkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+TmV0Y29uZiBtYWlsaW5nIGxpc3QN Cj5OZXRjb25mQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQo= From nobody Wed Dec 16 18:33: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 8E62C1A0140 for ; Wed, 16 Dec 2015 18:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNqxGY6od1WA for ; Wed, 16 Dec 2015 18:33:42 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D0B1A00F6 for ; Wed, 16 Dec 2015 18:33:41 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-a8-56721e35a056 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 71.1C.06940.53E12765; Thu, 17 Dec 2015 03:30:13 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Wed, 16 Dec 2015 21:33:39 -0500 From: Athanasios Kyparlis To: Andy Bierman Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 Thread-Index: AdE3eTk+yj/4s/NrQu2LeR6gt3+K2gAoCZaQAAxax4AACcVecA== Date: Thu, 17 Dec 2015 02:33:39 +0000 Message-ID: <4F4A512E4B3EB845A006F77C995C22A73C8D17A0@eusaamb107.ericsson.se> References: <4F4A512E4B3EB845A006F77C995C22A73C8D0AC3@eusaamb107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_4F4A512E4B3EB845A006F77C995C22A73C8D17A0eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPrK6pXFGYwc9mFYsHR2axW0zddJvV gcljyZKfTB4t/RdZApiiuGxSUnMyy1KL9O0SuDK673QwF0x5zljx5VwTYwNjx0PGLkYODgkB E4lvBxy7GDmBTDGJC/fWs3UxcnEICRxhlPj7cwULhLOcUeLkxsssIFVsAjYS3b86mUFsEQFV iQtzJ4LZzAKaEmv/fgSzhQUmMkr86ZAEaRYRmMQosWz9AnaIBieJA1e7wGwWoObGFe+YQK7g FfCV2PnUCWLZLUaJGw1bwJZxCgRKNLzazgRiMwKd9/3UGiaIZeISt57MZ4I4W0BiyZ7zzBC2 qMTLx/9YIWxFiX3909kh6vMlvm64D2bzCghKnJz5hGUCo+gsJKNmISmbhaRsFtB5IL+t36UP UaIoMaX7ITuErSHROmcuO7L4Akb2VYwcpcUFObnpRgabGIGRdUyCTXcH4/3pnocYBTgYlXh4 P7wpDBNiTSwrrsw9xCjBwawkwvt9D1CINyWxsiq1KD++qDQntfgQozQHi5I4LyMDA4OQQHpi SWp2ampBahFMlomDU6qBkVVPoDT+9Pn3J+8tCg4+G3nSOtnU4z5HSsQCe1WJ2JdZzJxrQzqN 1l+0NynaLVqwt6tRJ9pCtO9CkOAPc7/jEcY3bzPmLpz/RMZuxo0/86PWlle9VlNVedn5+M9a qz+XvOeEiTD61lQ5Lqmfvv5zsLfW1qzdosxn7y3uuJFVz57y6BWbtIiZEktxRqKhFnNRcSIA zJinr6gCAAA= Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 17 Dec 2015 02:33:44 -0000 --_000_4F4A512E4B3EB845A006F77C995C22A73C8D17A0eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZXRoaW5nIHRvIHRoZSBlZmZlY3Qgb2Ygd2hhdCB5b3UgbWVudGlvbiBiZWxvdyBzaG91bGQg c3VmZmljZS4NClBlcmhhcHM6DQrigJxUaGUgUkZDNjAyMiBuZXRjb25mLXN0YXRlIGxpc3Qgc3Vw cG9ydHMgYW55IHNjaGVtYSBsYW5ndWFnZSwgbm90IGp1c3QgWUFORy4NClRoZSBZQU5HIGxpYnJh cnkgU0hPVUxEIGJlIHVzZWQgYnkgUkVTVENPTkYgYW5kIFlBTkcgMS4xLiBJdCBoYXMgY29uZm9y bWFuY2UgaW5mbyB0aGF0IGRvZXMgbm90IGV4aXN0IGluIHRoZSBSRkM2MDIyIHNjaGVtYSBsaXN0 Lg0KDQpBIGNsaWVudCBjb3VsZCB1c2Ugb25lIG9yIHRoZSBvdGhlciwgb3IgYm90aCBvZiB0aGVz ZSBsaXN0cywgYnV0IHRoZSB1c2Ugb2YgWUFORy1saWJyYXJ5IHNob3VsZCBiZSBwcmVmZXJyZWQg Zm9yIFlBTkcgc2NoZW1hcy4NCkluIHRoZSBjYXNlIHdoZXJlIGJvdGggbGlzdHMgYXJlIHN1cHBv cnRlZCwgdGhlIGluZm9ybWF0aW9uIGluIGVhY2ggbGlzdCBNVVNUIG5vdCBjb250cmFkaWN0IHRo ZSBvdGhlci7igJ0NCg0KVGhhbmtzLA0KQUsNCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86 YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNSAx MTo0MyBBTQ0KVG86IEF0aGFuYXNpb3MgS3lwYXJsaXMNCkNjOiBuZXRjb25mQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW05ldGNvbmZdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25m LXJlc3Rjb25mLTA5LCBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wYXRjaC0wNyBhbmQgZHJhZnQt aWV0Zi1uZXRjb25mLXlhbmctbGlicmFyeS0wMw0KDQpIaSwNCg0KVGhlIFdHIGRlY2lkZWQgdGhl cmUgd2FzIG5vIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBZQU5HIGxpYnJhcnkgYW5kIHRoZSBu ZXRjb25mLXN0YXRlDQpzY2hlbWEgbGlzdC4NCg0KV2hhdCBzaG91bGQgdGhpcyBkcmFmdCBzYXk/ ICBUaGVyZSBpcyBvdmVybGFwLCBidXQgbm90IGNvbXBsZXRlIG92ZXJsYXAuDQpUaGUgbmV0Y29u Zi1zdGF0ZSBsaXN0IHN1cHBvcnRzIGFueSBzY2hlbWEgbGFuZ3VhZ2UsIG5vdCBqdXN0IFlBTkcu DQoNClRoZSBZQU5HIGxpYnJhcnkgaXMgdXNlZCBieSBSRVNUQ09ORiBhbmQgWUFORyAxLjEuDQpJ dCBoYXMgY29uZm9ybWFuY2UgaW5mbyB0aGF0IGRvZXMgbm90IGV4aXN0IGluIHRoZSBzY2hlbWEg bGlzdC4NCg0KQSBjbGllbnQgY291bGQgdXNlIG9uZSBvciB0aGUgb3RoZXIsIG9yIGJvdGggb2Yg dGhlc2UgbGlzdHMuDQoNCg0KDQpBbmR5DQoNCg0KT24gV2VkLCBEZWMgMTYsIDIwMTUgYXQgODoy OCBBTSwgQXRoYW5hc2lvcyBLeXBhcmxpcyA8YXRoYW5hc2lvcy5reXBhcmxpc0Blcmljc3Nvbi5j b208bWFpbHRvOmF0aGFuYXNpb3Mua3lwYXJsaXNAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpUaGlz IGlzIGEgY29tbWVudCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctbGlicmFyeS0wMy50eHQ6 DQoNClRoZSBkb2N1bWVudCBzaG91bGQgb3V0bGluZSB0aGUgcmVsYXRpb25zaGlwIHRvIHNjaGVt YSBzdWJ0cmVlIGFuZCBnZXQtc2NoZW1hIG9wZXJhdGlvbiBkZWZpbmVkIGluIHJmYzYwMjIuDQoN CklzIHRoZSBzY2hlbWEgbGVhZiBkZWZpbmVkIGluIHRoZSBkcmFmdCBlcXVpdmFsZW50IHRvIHRo ZSBzY2hlbWEg4oCYbG9jYXRpb27igJkgZGVmaW5lZCBpbiByZmM2MDIyPyBBcmUgdGhlIHR3byBl eHBlY3RlZCB0byBoYXZlIHRoZSBzYW1lIHZhbHVlPw0KDQpJdCBzaG91bGQgYWxzbyBkZXNjcmli ZSBpZiB0aGUgdHdvIGNhcGFiaWxpdGllcyAoeWFuZy1saWJyYXJ5IGFuZCByZmM2MDIyIHNjaGVt YSkgd2lsbCBiZSB1c2VkIGluIHBhcmFsbGVsIG9yIGlmIHN5c3RlbXMgYXJlIGV4cGVjdGVkIHRv IHN3aXRjaCB0byB5YW5nLWxpYnJhcnkgb3ZlciByZmM2MDIyIG9yIGlmIHRoZXJlIGlzIGdvaW5n IHRvIGJlIGEgcHJlc2NyaWJlZCBwcmVmZXJlbmNlIFtmb3IgZXhhbXBsZSwgc2hvdWxkIHN5c3Rl bXMgdHJ5IHRvIHVzZSB5YW5nLWxpYnJhcnkgZm9yIFlBTkcgYW5kIHN3aXRjaCB0byByZmM2MDIy IHNjaGVtYSBvbmx5IGlmIHRoZSBmb3JtZXIgaXMgbm90IHByZXNlbnQ/XS4NCg0KVGhhbmtzLA0K QXRoYW5hc2lvcyBLeXBhcmxpcw0KDQpGcm9tOiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRXJzdWUs IE1laG1ldCAoTm9raWEgLSBERS9NdW5pY2gpDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNSwg MjAxNSAzOjU5IFBNDQpUbzogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9y Zz4NCkNjOiBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPjsgNnRpc2NoQGlldGYu b3JnPG1haWx0bzo2dGlzY2hAaWV0Zi5vcmc+OyBjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGll dGYub3JnPjsgNmxvQGlldGYub3JnPG1haWx0bzo2bG9AaWV0Zi5vcmc+DQpTdWJqZWN0OiBbaTJy c10gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMDksIGRyYWZ0 LWlldGYtbmV0Y29uZi15YW5nLXBhdGNoLTA3IGFuZCBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1s aWJyYXJ5LTAzDQoNCkRlYXIgTkVUQ09ORiBXRywNCg0Kd2UgaGVyZWJ5IGlzc3VlIGEgV0cgTGFz dCBDYWxsIGZvciB0aGUgZHJhZnRzIGJlbG93Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMDkudHh0DQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wYXRjaC0wNy50eHQNCmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi15YW5nLWxpYnJhcnktMDMudHh0DQoN ClBsZWFzZSByZXZpZXcgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgTkVUQ09ORiBXRyBt YWlsaW5nIGxpc3QgYnkgSmFudWFyeSAyMiwgMjAxNSBFT0IgUFQuDQoNClRoZSBkcmFmdHMgb24g UkVTVENPTkYsIFlBTkcgcGF0Y2ggYW5kIFlBTkcgbGlicmFyeSBhcmUgcGxhbm5lZCB0byBwdWJs aXNoIGFzIHN0YW5kYXJkIHRyYWNrIGRvY3VtZW50cy4NCg0KQXMgUkVTVENPTkYgaXMgYSBtYWpv ciBwcm90b2NvbCB3ZSBzZWVrIGEgZGV0YWlsZWQgYW5kIHRob3JvdWdoIHJldmlldyB3aXRoaW4g TkVUQ09ORiBXRyBidXQgYWxzbyBieSB0aGUgcmVsYXRlZCBXR3MgYmVmb3JlIHB1Ymxpc2hpbmcu DQpUaGVyZWZvcmUgdGhlIFdHTEMgaXMgcGxhbm5lZCB0byBmaW5hbGl6ZSBvbiBKYW51YXJ5IDIy dGggKGNvdmVyaW5nIHRoZSBob2xpZGF5IHRpbWUgaW4gYmV0d2VlbikgYW5kIEFQUCwgSU5UIGFu ZCBSVEcgYXJlYSBBRHMgd2lsbCBiZSBpbmZvcm1lZCBhcyB3ZWxsIGFzIENvcmUsIEkyUlMsIDZs bywgYW5kIDZ0aXNjaCBXR3MgYXJlIGludml0ZWQgdG8gcmV2aWV3Lg0KDQpQbGVhc2UgdGFrZSB5 b3VyIHRpbWUgdG8gcmV2aWV3IHRoZSBkb2N1bWVudHMgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0 byB0aGUgTkVUQ09ORiBtYWlsbGlzdCBieSB0aGUgZGVhZGxpbmUuDQpQbGVhc2Ugc3RhdGUgb24g TkVUQ09ORiBtYWlsbGlzdCBhbHNvIGV4cGxpY2l0bHksIHdoZXRoZXIgeW91IGhhdmUgcmVhZC9y ZXZpZXdlZCBhbmQgd2hldGhlciB5b3Ugc3VwcG9ydCB0aGUgcHVibGljYXRpb24uDQpGdXJ0aGVy bW9yZSBwbGVhc2UgaW5kaWNhdGUgaWYgeW91IHBsYW4gdG8gaW1wbGVtZW50IG9yIGhhdmUgYWxy ZWFkeSBpbXBsZW1lbnRhdGlvbnMgZm9yIFJFU1RDT05GIGFuZCBpdHMgc3VwcGxlbWVudGFyeSBk cmFmdHMuDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGtpbmQgaGVscCBnZXR0aW5n IFJFU1RDT05GIHNwZWNpZmljYXRpb25zIHN0YWJsZS4NCg0KQmVzdCBSZWdhcmRzLA0KTWVobWV0 IGFuZCBNYWhlc2gNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5l dGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYNCg0K --_000_4F4A512E4B3EB845A006F77C995C22A73C8D17A0eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5Tb21ldGhpbmcgdG8gdGhlIGVmZmVjdCBvZiB3aGF0IHlvdSBtZW50aW9uIGJlbG93IHNo b3VsZCBzdWZmaWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZXJoYXBzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+VGhlIFJGQzYwMjIgbmV0Y29uZi1z dGF0ZSBsaXN0IHN1cHBvcnRzIGFueSBzY2hlbWEgbGFuZ3VhZ2UsIG5vdCBqdXN0IFlBTkcuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgWUFORyBsaWJyYXJ5IFNIT1VM RCBiZSB1c2VkIGJ5IFJFU1RDT05GIGFuZCBZQU5HIDEuMS4gSXQgaGFzIGNvbmZvcm1hbmNlIGlu Zm8gdGhhdCBkb2VzIG5vdCBleGlzdCBpbiB0aGUgUkZDNjAyMiBzY2hlbWEgbGlzdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QSBjbGllbnQgY291bGQgdXNlIG9uZSBvciB0aGUgb3RoZXIsIG9y IGJvdGggb2YgdGhlc2UgbGlzdHMsIGJ1dCB0aGUgdXNlIG9mIFlBTkctbGlicmFyeSBzaG91bGQg YmUgcHJlZmVycmVkIGZvciBZQU5HIHNjaGVtYXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiB0aGUgY2FzZSB3aGVyZSBib3RoIGxpc3RzIGFyZSBzdXBwb3J0ZWQsIHRo ZSBpbmZvcm1hdGlvbiBpbiBlYWNoIGxpc3QgTVVTVCBub3QgY29udHJhZGljdCB0aGUgb3RoZXIu 4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QUs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIERlY2VtYmVy IDE2LCAyMDE1IDExOjQzIEFNPGJyPg0KPGI+VG86PC9iPiBBdGhhbmFzaW9zIEt5cGFybGlzPGJy Pg0KPGI+Q2M6PC9iPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb TmV0Y29uZl0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMDks IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXBhdGNoLTA3IGFuZCBkcmFmdC1pZXRmLW5ldGNvbmYt eWFuZy1saWJyYXJ5LTAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGks PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgV0cgZGVj aWRlZCB0aGVyZSB3YXMgbm8gcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIFlBTkcgbGlicmFyeSBh bmQgdGhlIG5ldGNvbmYtc3RhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnNjaGVtYSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHNob3VsZCB0aGlzIGRyYWZ0IHNheT8mbmJz cDsgVGhlcmUgaXMgb3ZlcmxhcCwgYnV0IG5vdCBjb21wbGV0ZSBvdmVybGFwLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG5ldGNvbmYtc3Rh dGUgbGlzdCBzdXBwb3J0cyBhbnkgc2NoZW1hIGxhbmd1YWdlLCBub3QganVzdCBZQU5HLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgWUFO RyBsaWJyYXJ5IGlzIHVzZWQgYnkgUkVTVENPTkYgYW5kIFlBTkcgMS4xLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaGFzIGNvbmZvcm1hbmNl IGluZm8gdGhhdCBkb2VzIG5vdCBleGlzdCBpbiB0aGUgc2NoZW1hIGxpc3QuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgY2xpZW50IGNvdWxk IHVzZSBvbmUgb3IgdGhlIG90aGVyLCBvciBib3RoIG9mIHRoZXNlIGxpc3RzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyAx NiwgMjAxNSBhdCA4OjI4IEFNLCBBdGhhbmFzaW9zIEt5cGFybGlzICZsdDs8YSBocmVmPSJtYWls dG86YXRoYW5hc2lvcy5reXBhcmxpc0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5hdGhh bmFzaW9zLmt5cGFybGlzQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIGEgY29tbWVudCBmb3IgZHJhZnQtaWV0 Zi1uZXRjb25mLXlhbmctbGlicmFyeS0wMy50eHQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGRvY3VtZW50 IHNob3VsZCBvdXRsaW5lIHRoZSByZWxhdGlvbnNoaXAgdG8gc2NoZW1hIHN1YnRyZWUgYW5kIGdl dC1zY2hlbWEgb3BlcmF0aW9uIGRlZmluZWQgaW4NCiByZmM2MDIyLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklz IHRoZSBzY2hlbWEgbGVhZiBkZWZpbmVkIGluIHRoZSBkcmFmdCBlcXVpdmFsZW50IHRvIHRoZSBz Y2hlbWEg4oCYbG9jYXRpb27igJkgZGVmaW5lZCBpbiByZmM2MDIyPyBBcmUNCiB0aGUgdHdvIGV4 cGVjdGVkIHRvIGhhdmUgdGhlIHNhbWUgdmFsdWU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgc2hvdWxkIGFs c28gZGVzY3JpYmUgaWYgdGhlIHR3byBjYXBhYmlsaXRpZXMgKHlhbmctbGlicmFyeSBhbmQgcmZj NjAyMiBzY2hlbWEpIHdpbGwgYmUgdXNlZCBpbg0KIHBhcmFsbGVsIG9yIGlmIHN5c3RlbXMgYXJl IGV4cGVjdGVkIHRvIHN3aXRjaCB0byB5YW5nLWxpYnJhcnkgb3ZlciByZmM2MDIyIG9yIGlmIHRo ZXJlIGlzIGdvaW5nIHRvIGJlIGEgcHJlc2NyaWJlZCBwcmVmZXJlbmNlIFtmb3IgZXhhbXBsZSwg c2hvdWxkIHN5c3RlbXMgdHJ5IHRvIHVzZSB5YW5nLWxpYnJhcnkgZm9yIFlBTkcgYW5kIHN3aXRj aCB0byByZmM2MDIyIHNjaGVtYSBvbmx5IGlmIHRoZSBmb3JtZXIgaXMgbm90IHByZXNlbnQ/XS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXRo YW5hc2lvcyBLeXBhcmxpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBpMnJzIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkycnMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyc3VlLCBNZWhtZXQg KE5va2lhIC0gREUvTXVuaWNoKTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciAx NSwgMjAxNSAzOjU5IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkycnNA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86NnRpc2NoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQo2dGlzY2hAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmNvcmVAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOjZs b0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZsb0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW2kycnNdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rj b25mLTA5LCBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wYXRjaC0wNyBhbmQgZHJhZnQtaWV0Zi1u ZXRjb25mLXlhbmctbGlicmFyeS0wMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBD QyI+RGVhciBORVRDT05GIFdHLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPndlIGhlcmVieSBpc3N1ZSBhIFdHIExh c3QgQ2FsbCBmb3IgdGhlIGRyYWZ0cyBiZWxvdzoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDAwQ0MiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMDkudHh0 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1u ZXRjb25mLXJlc3Rjb25mLTA5LnR4dDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXlh bmctcGF0Y2gtMDcudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcGF0Y2gtMDcudHh0PC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW5ldGNvbmYteWFuZy1saWJyYXJ5LTAzLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi15YW5nLWxpYnJhcnktMDMu dHh0PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPlBsZWFzZSByZXZpZXcgYW5kIHNlbmQgeW91ciBjb21tZW50 cyB0byB0aGUgTkVUQ09ORiBXRyBtYWlsaW5nIGxpc3QgYnkgSmFudWFyeSAyMiwgMjAxNSBFT0Ig UFQuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMENDIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDAwMENDIj5UaGUgZHJhZnRzIG9uIFJFU1RDT05GLCBZQU5HIHBhdGNoIGFu ZCBZQU5HIGxpYnJhcnkgYXJlIHBsYW5uZWQgdG8gcHVibGlzaCBhcyBzdGFuZGFyZCB0cmFjayBk b2N1bWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+QXMgUkVTVENPTkYgaXMgYSBtYWpvciBwcm90b2NvbCB3 ZSBzZWVrIGEgZGV0YWlsZWQgYW5kIHRob3JvdWdoIHJldmlldyB3aXRoaW4gTkVUQ09ORiBXRyBi dXQgYWxzbw0KIGJ5IHRoZSByZWxhdGVkIFdHcyBiZWZvcmUgcHVibGlzaGluZy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMDAwMENDIj5UaGVyZWZvcmUgdGhlIFdHTEMgaXMgcGxhbm5lZCB0byBm aW5hbGl6ZSBvbiBKYW51YXJ5IDIydGggKGNvdmVyaW5nIHRoZSBob2xpZGF5IHRpbWUgaW4gYmV0 d2VlbikNCiBhbmQgQVBQLCBJTlQgYW5kIFJURyBhcmVhIEFEcyB3aWxsIGJlIGluZm9ybWVkIGFz IHdlbGwgYXMgQ29yZSwgSTJSUywgNmxvLCBhbmQgNnRpc2NoIFdHcyBhcmUgaW52aXRlZCB0byBy ZXZpZXcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwMDBDQyI+UGxlYXNlIHRha2UgeW91ciB0aW1lIHRvIHJldmlldyB0aGUg ZG9jdW1lbnRzIGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIE5FVENPTkYgbWFpbGxpc3Qg YnkgdGhlDQogZGVhZGxpbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+UGxlYXNl IHN0YXRlIG9uIE5FVENPTkYgbWFpbGxpc3QgYWxzbyBleHBsaWNpdGx5LCB3aGV0aGVyIHlvdSBo YXZlIHJlYWQvcmV2aWV3ZWQgYW5kIHdoZXRoZXIgeW91DQogc3VwcG9ydCB0aGUgcHVibGljYXRp b24uIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwQ0MiPkZ1cnRoZXJtb3JlIHBsZWFzZSBp bmRpY2F0ZSBpZiB5b3UgcGxhbiB0byBpbXBsZW1lbnQgb3IgaGF2ZSBhbHJlYWR5IGltcGxlbWVu dGF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+cw0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMENDIj5mb3IgUkVT VENPTkYgYW5kIGl0cyBzdXBwbGVtZW50YXJ5IGRyYWZ0cy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDAwMENDIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMENDIj5UaGFuayB5 b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCBraW5kIGhlbHAgZ2V0dGluZyBSRVNUQ09ORiBzcGVjaWZp Y2F0aW9ucyBzdGFibGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA5OSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+QmVzdCBSZWdhcmRzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDAwQ0MiPk1laG1ldCBhbmQgTWFoZXNoPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwMDA5OSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRj b25mIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5O ZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4F4A512E4B3EB845A006F77C995C22A73C8D17A0eusaamb107erics_-- From nobody Wed Dec 16 23:11: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 81BF01B2A3C for ; Wed, 16 Dec 2015 23:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTfSP1poEH0c for ; Wed, 16 Dec 2015 23:11:53 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378051B2A3F for ; Wed, 16 Dec 2015 23:11:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9632F900; Thu, 17 Dec 2015 08:11:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cPsYaKRgOBCK; Thu, 17 Dec 2015 08:11:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Dec 2015 08:11:49 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AF5120058; Thu, 17 Dec 2015 08:11:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02-TdkwGwlDl; Thu, 17 Dec 2015 08:11:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E852920055; Thu, 17 Dec 2015 08:11:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BC7A23940E0E; Thu, 17 Dec 2015 08:11:47 +0100 (CET) Date: Thu, 17 Dec 2015 08:11:47 +0100 From: Juergen Schoenwaelder To: Athanasios Kyparlis Message-ID: <20151217071145.GB67701@elstar.local> Mail-Followup-To: Athanasios Kyparlis , Andy Bierman , "netconf@ietf.org" References: <4F4A512E4B3EB845A006F77C995C22A73C8D0AC3@eusaamb107.ericsson.se> <4F4A512E4B3EB845A006F77C995C22A73C8D17A0@eusaamb107.ericsson.se> 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: <4F4A512E4B3EB845A006F77C995C22A73C8D17A0@eusaamb107.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 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, 17 Dec 2015 07:11:55 -0000 On Thu, Dec 17, 2015 at 02:33:39AM +0000, Athanasios Kyparlis wrote: > Something to the effect of what you mention below should suffice. > Perhaps: > “The RFC6022 netconf-state list supports any schema language, not just YANG. > The YANG library SHOULD be used by RESTCONF and YANG 1.1. It has conformance info that does not exist in the RFC6022 schema list. > > A client could use one or the other, or both of these lists, but the use of YANG-library should be preferred for YANG schemas. > In the case where both lists are supported, the information in each list MUST not contradict the other.†> I do not think this text is helpful. YANG 1.1 has several MUST statements referring to YANG library and hence once an implementation implements YANG 1.1 modules, it will have to support YANG library. So it would be misleading if we state SHOULD here and in general it is desirable to avoid circular dependencies. RESTCONF and YANG 1.1 both depend on YANG library and this is what these documents say and I think this is sufficient. In the long run, I expect that YANG library will be used where functionality overlaps (but as Andy wrote, the overlap is not 1:1). /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 Dec 17 04:09: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 64BF51B2BB5 for ; Thu, 17 Dec 2015 04:09:02 -0800 (PST) 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 Tx3GCu1hIKPH for ; Thu, 17 Dec 2015 04:09:01 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C51281B2BB2 for ; Thu, 17 Dec 2015 04:09:00 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4D0921CC008F for ; Thu, 17 Dec 2015 13:09:02 +0100 (CET) From: Ladislav Lhotka To: Netconf User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 17 Dec 2015 13:08:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Netconf] LL review of yang-patch-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: Thu, 17 Dec 2015 12:09:02 -0000 Hi, I have reviewed the document, it is well-written and has IMO no major problems, so I support its publication. My company plans an implementation. Here are my comments/questions: *** General - The term "target resource" seems to mean two things: in section 2.2 it is probably the "root" resource identified in Request-URI, but later it is the node identified by the "target" leaf. It should be explained, or different terms might be used, e.g. target-subtarget. - The existence of two delete operations ("delete" and "remove") is a historical accident coming from NETCONF. I think it would be better to have just one operation, and a general "no-errors" flag that could be applied to other operations, too ("create"). - Is it possible to delete a whole list at once with yang-patch? *** Specific - sec. 2.1: What happens if there are several roots? Is the patch applied to all? - sec. 2.2: Why is "patch-id" optional? What happens if it's not present in a request? *** Typos - sec. 2.1: s/identity/identify/ Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 17 07:47:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867AA1B2EE5 for ; Thu, 17 Dec 2015 07:47:28 -0800 (PST) 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 N5Q53_Lk-Ofk for ; Thu, 17 Dec 2015 07:47:26 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B299E1B2EE3 for ; Thu, 17 Dec 2015 07:47:26 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 6B54E1CC008F for ; Thu, 17 Dec 2015 16:47:29 +0100 (CET) From: Ladislav Lhotka To: Netconf User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 17 Dec 2015 16:47:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 17 Dec 2015 15:47:28 -0000 Hi, I reviewed the draft and found several issues: - The purpose of "yang-protocol" and "restricted-protocol" is unclear from the text. I know it from the mailing list discussion, but I think this solution is not good. What if a device runs, e.g., multiple RESTCONF servers on different ports, each with a specific data model? IMO the best solution is to have yang-library information specific for each protocol server instance. The "*-protocol" leafs than wouldn't be needed. - The name "conformance" seems to be a misnomer: the leaf gives information about how the module is used by the server. What about "role"? - The descriptions of the enums "implement" and "import" are confusing and maybe incorrect. In my view, a server must include in the yang-library all implemented modules, and then those that are (at least once) imported without revision. Those that are only imported by revision should not be in yang-library at all. IMO *all* modules must appear in yang-library no more than once - otherwise, how a client could determine which revision (of several listed) was used for a particular import without revision? - "implement" should also mean implementing identities defined in the module. - Once upon a time, there was a discussion in XML circles about pros and cons of "xsd:schemaLocation". Some of the considerations also apply to the "schema" leaf. I think the client should either already have the modules/revisions listed in yang-library, or be able to get them from a well-known and reliable location. The schema provided by the device should not be used as authoritative because otherwise vendors might be tempted to serve clients with "improved" versions that pretend to be standard. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 17 08:26: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 93BF51B2F13 for ; Thu, 17 Dec 2015 08:26:07 -0800 (PST) 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 ipsJniFcA1aT for ; Thu, 17 Dec 2015 08:26:05 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 68C731A0383 for ; Thu, 17 Dec 2015 08:26:05 -0800 (PST) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 534E41CC008F for ; Thu, 17 Dec 2015 17:26:08 +0100 (CET) From: Ladislav Lhotka To: Netconf In-Reply-To: References: User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 17 Dec 2015 17:26:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 17 Dec 2015 16:26:07 -0000 Ladislav Lhotka writes: > Hi, > > I reviewed the draft and found several issues: I forgot to include one more thing: - It might be useful to have a standard algorithm for computing "module-set-id". For example, in large deployments comprising essentially identical devices, it could save the client many round-trips if the same "module-set-id" means the same yang-library content on all devices. Lada > > - The purpose of "yang-protocol" and "restricted-protocol" is > unclear from the text. I know it from the mailing list > discussion, but I think this solution is not good. What if a > device runs, e.g., multiple RESTCONF servers on different ports, > each with a specific data model? IMO the best solution is to > have yang-library information specific for each protocol server > instance. The "*-protocol" leafs than wouldn't be needed. > > - The name "conformance" seems to be a misnomer: the leaf gives > information about how the module is used by the server. What > about "role"? > > - The descriptions of the enums "implement" and "import" are > confusing and maybe incorrect. In my view, a server must include > in the yang-library all implemented modules, and then those that > are (at least once) imported without revision. Those that are > only imported by revision should not be in yang-library at > all. IMO *all* modules must appear in yang-library no more than > once - otherwise, how a client could determine which revision > (of several listed) was used for a particular import without > revision? > > - "implement" should also mean implementing identities defined in > the module. > > - Once upon a time, there was a discussion in XML circles about > pros and cons of "xsd:schemaLocation". Some of the > considerations also apply to the "schema" leaf. I think the > client should either already have the modules/revisions listed > in yang-library, or be able to get them from a well-known and > reliable location. The schema provided by the device should not > be used as authoritative because otherwise vendors might be > tempted to serve clients with "improved" versions that pretend > to be standard. > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 17 14:40: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 90F4E1B2C8D for ; Thu, 17 Dec 2015 14:40:46 -0800 (PST) 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 Oz9cscWEVCxk for ; Thu, 17 Dec 2015 14:40:44 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 40B441A8F37 for ; Thu, 17 Dec 2015 14:40:44 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id y184so61468809lfc.1 for ; Thu, 17 Dec 2015 14:40:44 -0800 (PST) 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=ftSnCVtTmavDvPR9GS1Ny4Z9WBSEnEY8z3Jvr7vaMpE=; b=cPC8K158+BNjWx9tByq1CPo36ZaYswzSgbJ/skZI/1WBWEMQjn7ZD/qmqFcZCM4meX bSTAMNpUwY3+LCoHsFor4GqSYYoA47KzA8+KUHHmHMT4iYZVetdpJ+7VJtcUAlivZH4m jwXQseceA8eTM8G8t9nOh5DLS+c67em8QnoMiMWV0SpGCkMBAcGe5aV1ECD0rlQPPyP1 UNQpJTIy5B91Iq5Qlbo84UR2el+u8uVtLlw8+g8RoOtdDQTfz6yKPAxaYxKycMolb6TX ja6LoDLyYNnReGiImDMyGu9nYozF1blgH/mwfKYS3JXl5hM6gRlBL4DfQVKhqbm9/zas gE0A== 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=ftSnCVtTmavDvPR9GS1Ny4Z9WBSEnEY8z3Jvr7vaMpE=; b=PwshLpYIbIrRieyLHkkRsqudfaMDl5hTAZWGV2MCl/zWcxI/K3Ufj1juqRTh5dCDmN FWIl+QV9/c2vcTaTylHTf9TC9LwSW8PgDNbFLbvFSjgoChW0j/mO2bkVYLj31zL/OScF JKQrdO+otd3vpWv5FhKG0DYDXcSwaUUNPPVUQR9/D++ifoKTt+SfjB9hHON1BKhrin7G B1IMOtrOzg58jXX/20ZlNHjEjs+zgeXr+XHp0b3WIYTPuVa02Nt1mMJ3ISqpn2sI+RRY +ImU3YEWdfH081nR1nHzxn8o6OFMX4/SP1NkAzWYPpTRVLbZ9pgORrk1wYgTLVNGjipw f5Xw== X-Gm-Message-State: ALoCoQn1ozdWNwm6NKwCfjj7KT0evJ2COgfXfybKOr3b55wCq2ogsVs0yb3NUqUQUh62GeQuNGcNh4vIURCHvjlJsLhrhvefOQ== MIME-Version: 1.0 X-Received: by 10.25.155.136 with SMTP id d130mr111237lfe.54.1450392042314; Thu, 17 Dec 2015 14:40:42 -0800 (PST) Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 14:40:42 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Dec 2015 14:40:42 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1140223e77b7f005271fb6f3 Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 17 Dec 2015 22:40:46 -0000 --001a1140223e77b7f005271fb6f3 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka wrote: > Hi, > > I reviewed the draft and found several issues: > > - The purpose of "yang-protocol" and "restricted-protocol" is > unclear from the text. I know it from the mailing list > discussion, but I think this solution is not good. What if a > device runs, e.g., multiple RESTCONF servers on different ports, > each with a specific data model? IMO the best solution is to > have yang-library information specific for each protocol server > instance. The "*-protocol" leafs than wouldn't be needed. > > This approach appears simple, but it requires the server to implement dynamic content for this module instead of static content. It also prevents the operator from knowing what other protocols might be clashing with their client. I think the YANG description-stmts for these leaf-lists are clear. Each virtual server has its own YANG library that covers the protocols used just on that virtual server. > - The name "conformance" seems to be a misnomer: the leaf gives > information about how the module is used by the server. What > about "role"? > Role is rather generic. How about conformance-role? > - The descriptions of the enums "implement" and "import" are > confusing and maybe incorrect. In my view, a server must include > in the yang-library all implemented modules, and then those that > are (at least once) imported without revision. Those that are > only imported by revision should not be in yang-library at > all. IMO *all* modules must appear in yang-library no more than > once - otherwise, how a client could determine which revision > (of several listed) was used for a particular import without > revision? > > I disagree. The YANG library needs to list all the modules. A client must be able to predetermine the module set. Otherwise the client has to parse the YANG module and analyze all the imports (and imports in the imported modules, until the end of the dependency chain) What problem are you solving by leaving out modules and forcing the client to parse all the modules instead? > - "implement" should also mean implementing identities defined in > the module. > One does not implement identities. Only leaf or leaf-list of type identityref can be implemented. YANG conformance is incapable of specifying the set of identities that a server MUST support (except the description-stmt). This module is not intended to fix all the deficiencies of YANG conformance. > - Once upon a time, there was a discussion in XML circles about > pros and cons of "xsd:schemaLocation". Some of the > considerations also apply to the "schema" leaf. I think the > client should either already have the modules/revisions listed > in yang-library, or be able to get them from a well-known and > reliable location. The schema provided by the device should not > be used as authoritative because otherwise vendors might be > tempted to serve clients with "improved" versions that pretend > to be standard. > I don't see how the YANG library affects this issue. A vendor can put whatever URL they want in this leaf. It is optional, so they don't have to support schema retrieval at all. > > Lada > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1140223e77b7f005271fb6f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Hi,

I reviewed the draft and found several issues:

=C2=A0 =C2=A0 - The purpose of "yang-protocol" and "restrict= ed-protocol" is
=C2=A0 =C2=A0 =C2=A0 unclear from the text. I know it from the mailing list=
=C2=A0 =C2=A0 =C2=A0 discussion, but I think this solution is not good. Wha= t if a
=C2=A0 =C2=A0 =C2=A0 device runs, e.g., multiple RESTCONF servers on differ= ent ports,
=C2=A0 =C2=A0 =C2=A0 each with a specific data model? IMO the best solution= is to
=C2=A0 =C2=A0 =C2=A0 have yang-library information specific for each protoc= ol server
=C2=A0 =C2=A0 =C2=A0 instance. The "*-protocol" leafs than wouldn= 't be needed.



This approach appears s= imple, but it requires the server
to implement dynamic content fo= r this module instead of static content.
It also prevents the ope= rator from knowing what other protocols might
be clashing with th= eir client.

I think the YANG description-stmts for= these leaf-lists are clear.

Each virtual server h= as its own YANG library that covers the protocols
used just on th= at virtual server.


=C2=A0
=
=C2=A0 =C2=A0 - The name "conformance" seems to be a misnomer: th= e leaf gives
=C2=A0 =C2=A0 =C2=A0 information about how the module is used by the server= . What
=C2=A0 =C2=A0 =C2=A0 about "role"?


Role is rather generic. How about conformance-role?



=C2=A0 =C2=A0 - The descriptions of the enums "implement" and &qu= ot;import" are
=C2=A0 =C2=A0 =C2=A0 confusing and maybe incorrect. In my view, a server mu= st include
=C2=A0 =C2=A0 =C2=A0 in the yang-library all implemented modules, and then = those that
=C2=A0 =C2=A0 =C2=A0 are (at least once) imported without revision. Those t= hat are
=C2=A0 =C2=A0 =C2=A0 only imported by revision should not be in yang-librar= y at
=C2=A0 =C2=A0 =C2=A0 all. IMO *all* modules must appear in yang-library no = more than
=C2=A0 =C2=A0 =C2=A0 once - otherwise, how a client could determine which r= evision
=C2=A0 =C2=A0 =C2=A0 (of several listed) was used for a particular import w= ithout
=C2=A0 =C2=A0 =C2=A0 revision?

=C2=A0

I disagree.
The YANG library needs to list all the modules.
A client must be= able to predetermine the module set.
Otherwise the client has to= parse the YANG module
and analyze all the imports (and imports i= n the imported modules, until
the end of the dependency chain)

What problem are you solving by leaving out modules = and forcing the client to
parse all the modules instead?



=C2=A0
=C2=A0 =C2=A0 - "implement" should also mean implementing identit= ies defined in
=C2=A0 =C2=A0 =C2=A0 the module.


One does not implement identities.
Only leaf or leaf-lis= t of type identityref can be implemented.
YANG conformance is inc= apable of specifying the set of identities
that a server MUST sup= port (except the description-stmt).
This module is not intended t= o fix all the deficiencies of YANG conformance.


=C2=A0 =C2=A0 - Once upon a time, there was a discussion in XML circles abo= ut
=C2=A0 =C2=A0 =C2=A0 pros and cons of "xsd:schemaLocation". Some = of the
=C2=A0 =C2=A0 =C2=A0 considerations also apply to the "schema" le= af. I think the
=C2=A0 =C2=A0 =C2=A0 client should either already have the modules/revision= s listed
=C2=A0 =C2=A0 =C2=A0 in yang-library, or be able to get them from a well-kn= own and
=C2=A0 =C2=A0 =C2=A0 reliable location. The schema provided by the device s= hould not
=C2=A0 =C2=A0 =C2=A0 be used as authoritative because otherwise vendors mig= ht be
=C2=A0 =C2=A0 =C2=A0 tempted to serve clients with "improved" ver= sions that pretend
=C2=A0 =C2=A0 =C2=A0 to be standard.

I don't see how the YANG library affects this issue.
=
A vendor can put whatever URL they want in this leaf.
It is = optional, so they don't have to support schema retrieval at all.
<= div>

=C2=A0

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

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

--001a1140223e77b7f005271fb6f3-- From nobody Thu Dec 17 14:46:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBDE1B30FE for ; Thu, 17 Dec 2015 14:46:25 -0800 (PST) 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 B_jvzhMy63JW for ; Thu, 17 Dec 2015 14:46:24 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 7D66C1B30FF for ; Thu, 17 Dec 2015 14:46:21 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id y184so61535507lfc.1 for ; Thu, 17 Dec 2015 14:46:21 -0800 (PST) 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=eZP6EHix4jx/0A9QMY1ryQeOc1q7zNPDXt5ysQgKYZs=; b=yD8cktIorc9QdVT0MIrh2Wi7hq22hIlcJ68zlO5gM36ckzFwsXJ6dM/AiLm5MOKuzW /QgEcSHzZk1sVARLoU0jkvr7MZpG2zsfr3aLVC5A4JRC7zT6aUBH+X1MdA+pgT9FX9Sa poIriQLzO/O5e12ocdEo3uVSQVivFJQQnsi/uOmAPigVPx0PkuQpPKbmVEUhdMCrK/Cn bT1IHIb3ZrxWSyHaUgUrwAa6VycZbaSkLVQ97BFVToSRloUttL2wtm+B4MNm+8m9Ho/n h7DVRwaSQijOlWykn3KZkzKX5K1C/mU5UMdqfmH+0CtocsfSoqyyrUNoBIJH96cGiXdo WhFg== 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=eZP6EHix4jx/0A9QMY1ryQeOc1q7zNPDXt5ysQgKYZs=; b=ERPfpdWMImXQYhgM8KXtkSxhU3nvQExvX+jiGAeLo6temK++NYQGVlyMw9xMGHuMkR pgOMo0a2TJDE1j6SwTeU9Z5iQj7AkcVu6Z3qsz8sxPB6Km0mmmXwW1PpFFzLHEIqNhH4 n1tlvhNXbTqssKGdkT19DKN7UejB5UveUcc/ZcIRkIle9RPrPr6iXhzocG64AG0nrzDo fuN6eGewTEHizPUMXqDHCh8KOMdiUL+XwcSiRbBRLicQfZDMsCvNneptuxeDlJcir5ow zq3MAMwPRts8GWc/ntjZwUZeTkf7FZNpAx7XCxBrpUzvHCCMz3Y5MOBNsUCH6eistLN/ taCQ== X-Gm-Message-State: ALoCoQmZMEbhKwDM74Tp63cRfG21fpBQ/GsCzmNzLUPSvJte1Fc/RREBwctuduYovA9OwoQ/zP3dMtVvszRGfxpP3JFuap5eMA== MIME-Version: 1.0 X-Received: by 10.25.155.136 with SMTP id d130mr118233lfe.54.1450392379717; Thu, 17 Dec 2015 14:46:19 -0800 (PST) Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 14:46:19 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Dec 2015 14:46:19 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1140223e94055f05271fcac9 Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 17 Dec 2015 22:46:26 -0000 --001a1140223e94055f05271fcac9 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 17, 2015 at 8:26 AM, Ladislav Lhotka wrote: > Ladislav Lhotka writes: > > > Hi, > > > > I reviewed the draft and found several issues: > > I forgot to include one more thing: > > - It might be useful to have a standard algorithm for computing > "module-set-id". For example, in large deployments comprising > essentially identical devices, it could save the client many > round-trips if the same "module-set-id" means the same > yang-library content on all devices. > > Yeah, that is one of the motivations for my YANG Packages draft. I would rather rely on an explicit YANG identifier assignment to classify the server capabilities, than a hash or other algorithm that is not guaranteed to be unique. The module-set-id is just a caching helper for NETCONF (which does not support ETags like RESTCONF). > Lada > Andy > > > > > - The purpose of "yang-protocol" and "restricted-protocol" is > > unclear from the text. I know it from the mailing list > > discussion, but I think this solution is not good. What if a > > device runs, e.g., multiple RESTCONF servers on different ports, > > each with a specific data model? IMO the best solution is to > > have yang-library information specific for each protocol server > > instance. The "*-protocol" leafs than wouldn't be needed. > > > > - The name "conformance" seems to be a misnomer: the leaf gives > > information about how the module is used by the server. What > > about "role"? > > > > - The descriptions of the enums "implement" and "import" are > > confusing and maybe incorrect. In my view, a server must include > > in the yang-library all implemented modules, and then those that > > are (at least once) imported without revision. Those that are > > only imported by revision should not be in yang-library at > > all. IMO *all* modules must appear in yang-library no more than > > once - otherwise, how a client could determine which revision > > (of several listed) was used for a particular import without > > revision? > > > > - "implement" should also mean implementing identities defined in > > the module. > > > > - Once upon a time, there was a discussion in XML circles about > > pros and cons of "xsd:schemaLocation". Some of the > > considerations also apply to the "schema" leaf. I think the > > client should either already have the modules/revisions listed > > in yang-library, or be able to get them from a well-known and > > reliable location. The schema provided by the device should not > > be used as authoritative because otherwise vendors might be > > tempted to serve clients with "improved" versions that pretend > > to be standard. > > > > Lada > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1140223e94055f05271fcac9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 17, 2015 at 8:26 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Ladislav Lhotka <lhotka@nic.cz> writes:

> Hi,
>
> I reviewed the draft and found several issues:

I forgot to include one more thing:

=C2=A0 =C2=A0 - It might be useful to have a standard algorithm for computi= ng
=C2=A0 =C2=A0 =C2=A0 "module-set-id". For example, in large deplo= yments comprising
=C2=A0 =C2=A0 =C2=A0 essentially identical devices, it could save the clien= t many
=C2=A0 =C2=A0 =C2=A0 round-trips if the same "module-set-id" mean= s the same
=C2=A0 =C2=A0 =C2=A0 yang-library content on all devices.



Yeah, that is one of th= e motivations for my YANG Packages draft.
I would rather rely on = an explicit YANG identifier assignment to classify
the server cap= abilities, than a hash or other algorithm that is not
guaranteed = to be unique.

The module-set-id is just a caching = helper for NETCONF
(which does not support ETags like RESTCONF).<= /div>

=C2=A0
Lada


Andy
=C2= =A0

>
>=C2=A0 =C2=A0 =C2=A0- The purpose of "yang-protocol" and &quo= t;restricted-protocol" is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0unclear from the text. I know it from the ma= iling list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0discussion, but I think this solution is not= good. What if a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0device runs, e.g., multiple RESTCONF servers= on different ports,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0each with a specific data model? IMO the bes= t solution is to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0have yang-library information specific for e= ach protocol server
>=C2=A0 =C2=A0 =C2=A0 =C2=A0instance. The "*-protocol" leafs t= han wouldn't be needed.
>
>=C2=A0 =C2=A0 =C2=A0- The name "conformance" seems to be a mi= snomer: the leaf gives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0information about how the module is used by = the server. What
>=C2=A0 =C2=A0 =C2=A0 =C2=A0about "role"?
>
>=C2=A0 =C2=A0 =C2=A0- The descriptions of the enums "implement&quo= t; and "import" are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0confusing and maybe incorrect. In my view, a= server must include
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in the yang-library all implemented modules,= and then those that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0are (at least once) imported without revisio= n. Those that are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0only imported by revision should not be in y= ang-library at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all. IMO *all* modules must appear in yang-l= ibrary no more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0once - otherwise, how a client could determi= ne which revision
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(of several listed) was used for a particula= r import without
>=C2=A0 =C2=A0 =C2=A0 =C2=A0revision?
>
>=C2=A0 =C2=A0 =C2=A0- "implement" should also mean implementi= ng identities defined in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the module.
>
>=C2=A0 =C2=A0 =C2=A0- Once upon a time, there was a discussion in XML c= ircles about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pros and cons of "xsd:schemaLocation&qu= ot;. Some of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0considerations also apply to the "schem= a" leaf. I think the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0client should either already have the module= s/revisions listed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in yang-library, or be able to get them from= a well-known and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reliable location. The schema provided by th= e device should not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be used as authoritative because otherwise v= endors might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0tempted to serve clients with "improved= " versions that pretend
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be standard.
>
> Lada
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

--001a1140223e94055f05271fcac9-- From nobody Fri Dec 18 00:47: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 992E51B3485 for ; Fri, 18 Dec 2015 00:47:37 -0800 (PST) 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 Bb6MV0-x9vKR for ; Fri, 18 Dec 2015 00:47:35 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CD26C1B3483 for ; Fri, 18 Dec 2015 00:47:33 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 297E81CC008F; Fri, 18 Dec 2015 09:47:35 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 18 Dec 2015 09:47:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2015 08:47:37 -0000 Andy Bierman writes: > On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka wrote: > >> Hi, >> >> I reviewed the draft and found several issues: >> >> - The purpose of "yang-protocol" and "restricted-protocol" is >> unclear from the text. I know it from the mailing list >> discussion, but I think this solution is not good. What if a >> device runs, e.g., multiple RESTCONF servers on different ports, >> each with a specific data model? IMO the best solution is to >> have yang-library information specific for each protocol server >> instance. The "*-protocol" leafs than wouldn't be needed. >> >> > > This approach appears simple, but it requires the server > to implement dynamic content for this module instead of static content. > It also prevents the operator from knowing what other protocols might > be clashing with their client. This assumes there is a single server process and each protocol is just an interface to it. But there can also be separate server processes, each with its own configuration. So at least sec. 2.1.2 should talk about "server instance" and not about "managed device". I think it is sensitive information: why should every client of every protocol know all management protocols available on the device? Other state data are often dynamically generated, so I don't think it's such a big problem - each client will just receive the data it is entitled to work with. > > I think the YANG description-stmts for these leaf-lists are clear. Well, the description of "yang-protocol" is: "Identifies a protocol that is using modules described in this library. There SHOULD be one instance of this object for each protocol for each YANG-based protocol using this library."; This is IMO totally unclear. What does "protocol" mean? Is it a protocol interacting with the same server process, or any protocol on any virtual server? Is this "yang-protocol" leaf-list related somehow to the "restricted-protocol" leaf-list? It would be OK to have this info as a part of netconf-monitoring or similar regular state data - also because appropriate access restrictions can be applied. Yang-library is a critical structure, so it should IMO contain only the information that's necessary but nothing else. > > Each virtual server has its own YANG library that covers the protocols > used just on that virtual server. > > > > >> - The name "conformance" seems to be a misnomer: the leaf gives >> information about how the module is used by the server. What >> about "role"? >> > > > Role is rather generic. How about conformance-role? OK. > > > >> - The descriptions of the enums "implement" and "import" are >> confusing and maybe incorrect. In my view, a server must include >> in the yang-library all implemented modules, and then those that >> are (at least once) imported without revision. Those that are >> only imported by revision should not be in yang-library at >> all. IMO *all* modules must appear in yang-library no more than >> once - otherwise, how a client could determine which revision >> (of several listed) was used for a particular import without >> revision? >> >> > > I disagree. > The YANG library needs to list all the modules. > A client must be able to predetermine the module set. > Otherwise the client has to parse the YANG module > and analyze all the imports (and imports in the imported modules, until > the end of the dependency chain) > > What problem are you solving by leaving out modules and forcing the client > to > parse all the modules instead? I think I already described the problem. Let's say three revisions of ietf-inet-types are listed in yang-library, and some module imports ietf-inet-types without revision. How can the client tell which revision should be used for this import? > > > > > >> - "implement" should also mean implementing identities defined in >> the module. >> > > > One does not implement identities. Are modules that contain only identities (iana-if-type) listed as "implement" or "import"? > Only leaf or leaf-list of type identityref can be implemented. > YANG conformance is incapable of specifying the set of identities > that a server MUST support (except the description-stmt). > This module is not intended to fix all the deficiencies of YANG conformance. > > > >> - Once upon a time, there was a discussion in XML circles about >> pros and cons of "xsd:schemaLocation". Some of the >> considerations also apply to the "schema" leaf. I think the >> client should either already have the modules/revisions listed >> in yang-library, or be able to get them from a well-known and >> reliable location. The schema provided by the device should not >> be used as authoritative because otherwise vendors might be >> tempted to serve clients with "improved" versions that pretend >> to be standard. >> > > > I don't see how the YANG library affects this issue. > A vendor can put whatever URL they want in this leaf. > It is optional, so they don't have to support schema retrieval at all. If is it only auxiliary information, it doesn't IMO belong to yang-library. It is already available in ietf-netconf-monitoring so there is no need to duplicate it. Lada > > > > >> >> Lada >> > > > Andy > > >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 18 07:16: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 30B3A1B3426 for ; Fri, 18 Dec 2015 07:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stCQd5_35G_N for ; Fri, 18 Dec 2015 07:16:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F21FE1B342B for ; Fri, 18 Dec 2015 07:16:31 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id AE1FB1AE0A82; Fri, 18 Dec 2015 16:16:30 +0100 (CET) Date: Fri, 18 Dec 2015 16:16:31 +0100 (CET) Message-Id: <20151218.161631.2267320672620851859.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2015 15:16:34 -0000 Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka wrote: > > > >> Hi, > >> > >> I reviewed the draft and found several issues: > >> > >> - The purpose of "yang-protocol" and "restricted-protocol" is > >> unclear from the text. I know it from the mailing list > >> discussion, but I think this solution is not good. What if a > >> device runs, e.g., multiple RESTCONF servers on different ports, > >> each with a specific data model? IMO the best solution is to > >> have yang-library information specific for each protocol server > >> instance. The "*-protocol" leafs than wouldn't be needed. > >> > >> > > > > This approach appears simple, but it requires the server > > to implement dynamic content for this module instead of static content. > > It also prevents the operator from knowing what other protocols might > > be clashing with their client. Yes. But actually the current model doesn't prevent someone from using different instances of ietf-yang-library for different protocols. > This assumes there is a single server process and each protocol is just > an interface to it. But there can also be separate server processes, > each with its own configuration. So at least sec. 2.1.2 should talk > about "server instance" and not about "managed device". > > I think it is sensitive information: why should every client of every > protocol know all management protocols available on the device? > > Other state data are often dynamically generated, so I don't think it's > such a big problem - each client will just receive the data it is > entitled to work with. > > > > > I think the YANG description-stmts for these leaf-lists are clear. > > Well, the description of "yang-protocol" is: > > "Identifies a protocol that is using modules described > in this library. There SHOULD be one instance of > this object for each protocol for each YANG-based > protocol using this library."; > > This is IMO totally unclear. What does "protocol" mean? Is it a protocol > interacting with the same server process, or any protocol on any virtual > server? Is this "yang-protocol" leaf-list related somehow to the > "restricted-protocol" leaf-list? I think that restricted-protocol could as well be a leafref into yang-protocol. > It would be OK to have this info as a part of netconf-monitoring or > similar regular state data - also because appropriate access > restrictions can be applied. Yang-library is a critical structure, so it > should IMO contain only the information that's necessary but nothing else. > > > Each virtual server has its own YANG library that covers the protocols > > used just on that virtual server. > > > > > > > > > >> - The name "conformance" seems to be a misnomer: the leaf gives > >> information about how the module is used by the server. What > >> about "role"? > >> > > > > > > Role is rather generic. How about conformance-role? > > OK. > > > > > > > > >> - The descriptions of the enums "implement" and "import" are > >> confusing and maybe incorrect. In my view, a server must include > >> in the yang-library all implemented modules, and then those that > >> are (at least once) imported without revision. Those that are > >> only imported by revision should not be in yang-library at > >> all. IMO *all* modules must appear in yang-library no more than > >> once - otherwise, how a client could determine which revision > >> (of several listed) was used for a particular import without > >> revision? > >> > >> > > > > I disagree. > > The YANG library needs to list all the modules. > > A client must be able to predetermine the module set. > > Otherwise the client has to parse the YANG module > > and analyze all the imports (and imports in the imported modules, until > > the end of the dependency chain) > > > > What problem are you solving by leaving out modules and forcing the client > > to > > parse all the modules instead? > > I think I already described the problem. Let's say three revisions of > ietf-inet-types are listed in yang-library, and some module imports > ietf-inet-types without revision. How can the client tell which revision > should be used for this import? > > > > > > > > > > > > >> - "implement" should also mean implementing identities defined in > >> the module. > >> > > > > > > One does not implement identities. > > Are modules that contain only identities (iana-if-type) listed as > "implement" or "import"? "import", since "implement": Indicates that the server implements one or more protocol-accessible objects defined in the YANG module identified in this entry. This includes deviation statements defined in the module. /martin > > Only leaf or leaf-list of type identityref can be implemented. > > YANG conformance is incapable of specifying the set of identities > > that a server MUST support (except the description-stmt). > > This module is not intended to fix all the deficiencies of YANG conformance. > > > > > > > >> - Once upon a time, there was a discussion in XML circles about > >> pros and cons of "xsd:schemaLocation". Some of the > >> considerations also apply to the "schema" leaf. I think the > >> client should either already have the modules/revisions listed > >> in yang-library, or be able to get them from a well-known and > >> reliable location. The schema provided by the device should not > >> be used as authoritative because otherwise vendors might be > >> tempted to serve clients with "improved" versions that pretend > >> to be standard. > >> > > > > > > I don't see how the YANG library affects this issue. > > A vendor can put whatever URL they want in this leaf. > > It is optional, so they don't have to support schema retrieval at all. > > If is it only auxiliary information, it doesn't IMO belong to > yang-library. It is already available in ietf-netconf-monitoring so > there is no need to duplicate it. > > Lada > > > > > > > > > > >> > >> Lada > >> > > > > > > Andy > > > > > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Dec 18 07:36: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 668651B35B4 for ; Fri, 18 Dec 2015 07:36:11 -0800 (PST) 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 x6eoRS6wA1nZ for ; Fri, 18 Dec 2015 07:36:08 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 D41151A0115 for ; Fri, 18 Dec 2015 07:36:07 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id z124so70120447lfa.3 for ; Fri, 18 Dec 2015 07:36:07 -0800 (PST) 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=AHKkuXSNrhNrISV7RtYIt/WYLOxlEu94fmLYKD4y234=; b=Mw9eYk+ZEPL6Qxke+JznNXrExrP0f8Y/aCis4lFjfBpjU5WBAwI1V6pOlzqCFQDuHJ XQk06Xz5+SmdkwwVmBsXq6CCGTQKYpoeNYw9nTmEyG9t0POn1zK94WUSTICXlVvUT93H oQx/nphgoAR4z8eu5RX3ZdL/rbF3CUfBUhWsx2aVjHYH3/Sxek2ZAsLuJ0BP1XTUq7pv QLCuU+s0m/3ID6wNAdXHFP3W8btOtTa3MIckHspi99NXdHiL2XzXStiq9EGvYNGks1fk 8Aef7IxKSZenYlxnScFpSA433HoAOFwTlf1K3txVvvpzAIp4qpnHBijidyWRXfQLjAqp SPuQ== 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=AHKkuXSNrhNrISV7RtYIt/WYLOxlEu94fmLYKD4y234=; b=TUD6lIQVfxy7CdUN/gm/2sBfp6/fMiduAXwmFuNwWmLk9NwSBJjUyeN/ZArszJrCly rYoC4pxkwtym/ycxbLwBBDTROTiIYb9J8Hkn+OPAUulOQ5TktaBjZ3AvssLDD6iZW0EM C5YVKTwRT9AM9jIfxT549CAUQvlL4ZG1+UMhWKjS2SKKDEump0StbhVkkMHE/tJIVNNp n9xFBtRZFfutaJ4S8I0cy2BbBFWSQBcxW5jEDggPeOnjyeEoz9kg8W4/FT9lzglwuIsr Y9zTWzSlTM3nFRoz5ebclcp1XydoRte4oSm4sVlITMyxc05+83TRkhWG1pQ7Z7wOaASK dhTg== X-Gm-Message-State: ALoCoQmrJkf1+oByWHU4hRxo6TGG5Hoe/Sg8+P+6LOzo/fLyveoVzLMTJ/fNqkfw5PhyKbVITTh5zm961mtB+/6hyxAQcF90Tw== MIME-Version: 1.0 X-Received: by 10.25.85.200 with SMTP id j191mr1670428lfb.131.1450452965871; Fri, 18 Dec 2015 07:36:05 -0800 (PST) Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 07:36:05 -0800 (PST) In-Reply-To: <20151218.161631.2267320672620851859.mbj@tail-f.com> References: <20151218.161631.2267320672620851859.mbj@tail-f.com> Date: Fri, 18 Dec 2015 07:36:05 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11424d0ccb8cc205272de556 Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2015 15:36:11 -0000 --001a11424d0ccb8cc205272de556 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 18, 2015 at 7:16 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka > wrote: > > > > > >> Hi, > > >> > > >> I reviewed the draft and found several issues: > > >> > > >> - The purpose of "yang-protocol" and "restricted-protocol" is > > >> unclear from the text. I know it from the mailing list > > >> discussion, but I think this solution is not good. What if a > > >> device runs, e.g., multiple RESTCONF servers on different ports, > > >> each with a specific data model? IMO the best solution is to > > >> have yang-library information specific for each protocol server > > >> instance. The "*-protocol" leafs than wouldn't be needed. > > >> > > >> > > > > > > This approach appears simple, but it requires the server > > > to implement dynamic content for this module instead of static content. > > > It also prevents the operator from knowing what other protocols might > > > be clashing with their client. > > Yes. But actually the current model doesn't prevent someone from > using different instances of ietf-yang-library for different > protocols. > > > > This assumes there is a single server process and each protocol is just > > an interface to it. But there can also be separate server processes, > > each with its own configuration. So at least sec. 2.1.2 should talk > > about "server instance" and not about "managed device". > > > > I think it is sensitive information: why should every client of every > > protocol know all management protocols available on the device? > > > > Other state data are often dynamically generated, so I don't think it's > > such a big problem - each client will just receive the data it is > > entitled to work with. > > > > > > > > I think the YANG description-stmts for these leaf-lists are clear. > > > > Well, the description of "yang-protocol" is: > > > > "Identifies a protocol that is using modules described > > in this library. There SHOULD be one instance of > > this object for each protocol for each YANG-based > > protocol using this library."; > > > > This is IMO totally unclear. What does "protocol" mean? Is it a protocol > > interacting with the same server process, or any protocol on any virtual > > server? Is this "yang-protocol" leaf-list related somehow to the > > "restricted-protocol" leaf-list? > > I think that restricted-protocol could as well be a leafref into > yang-protocol. > OK > > > It would be OK to have this info as a part of netconf-monitoring or > > similar regular state data - also because appropriate access > > restrictions can be applied. Yang-library is a critical structure, so it > > should IMO contain only the information that's necessary but nothing > else. > > > > > Each virtual server has its own YANG library that covers the protocols > > > used just on that virtual server. > > > > > > > > > > > > > > >> - The name "conformance" seems to be a misnomer: the leaf gives > > >> information about how the module is used by the server. What > > >> about "role"? > > >> > > > > > > > > > Role is rather generic. How about conformance-role? > > > > OK. > > > > > > > > > > > > > >> - The descriptions of the enums "implement" and "import" are > > >> confusing and maybe incorrect. In my view, a server must include > > >> in the yang-library all implemented modules, and then those that > > >> are (at least once) imported without revision. Those that are > > >> only imported by revision should not be in yang-library at > > >> all. IMO *all* modules must appear in yang-library no more than > > >> once - otherwise, how a client could determine which revision > > >> (of several listed) was used for a particular import without > > >> revision? > > >> > > >> > > > > > > I disagree. > > > The YANG library needs to list all the modules. > > > A client must be able to predetermine the module set. > > > Otherwise the client has to parse the YANG module > > > and analyze all the imports (and imports in the imported modules, until > > > the end of the dependency chain) > > > > > > What problem are you solving by leaving out modules and forcing the > client > > > to > > > parse all the modules instead? > > > > I think I already described the problem. Let's say three revisions of > > ietf-inet-types are listed in yang-library, and some module imports > > ietf-inet-types without revision. How can the client tell which revision > > should be used for this import? > > > > > > > > > > > > > > > > > > > >> - "implement" should also mean implementing identities defined in > > >> the module. > > >> > > > > > > > > > One does not implement identities. > > > > Are modules that contain only identities (iana-if-type) listed as > > "implement" or "import"? > > "import", since "implement": > > Indicates that the server implements one or more > protocol-accessible objects defined in the YANG module > identified in this entry. This includes deviation > statements defined in the module. > > I recently implemented iana-crypt-hash in our server. This has 3 YANG features that can be advertised. It seems strange to advertise that this module is just imported, and yet features are implemented. We currently return conformance 'true' and all 3 features: module iana-crypt-hash 2014-08-06 { name iana-crypt-hash revision 2014-08-06 namespace urn:ietf:params:xml:ns:yang:iana-crypt-hash schema http://localhost/restconf/yang/iana-crypt-hash/2014-08-06 conformance true feature crypt-hash-md5 feature crypt-hash-sha-256 feature crypt-hash-sha-512 } I proposed an RPC called "get-allowed-identities" in 2014 https://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-04 Even though YANG 1.1 allows if-feature in an identity, this does not solve the iana-if-type problem. It would be useful for the client app to know what identities are relevant for a given leaf. Using 100s or 1000s of YANG identities would be unmanageable. There should be some way in a YANG module to say that an identity-stmt value is required for a particular identityref, but not in this draft. > > /martin > Andy > > > > > > Only leaf or leaf-list of type identityref can be implemented. > > > YANG conformance is incapable of specifying the set of identities > > > that a server MUST support (except the description-stmt). > > > This module is not intended to fix all the deficiencies of YANG > conformance. > > > > > > > > > > > >> - Once upon a time, there was a discussion in XML circles about > > >> pros and cons of "xsd:schemaLocation". Some of the > > >> considerations also apply to the "schema" leaf. I think the > > >> client should either already have the modules/revisions listed > > >> in yang-library, or be able to get them from a well-known and > > >> reliable location. The schema provided by the device should not > > >> be used as authoritative because otherwise vendors might be > > >> tempted to serve clients with "improved" versions that pretend > > >> to be standard. > > >> > > > > > > > > > I don't see how the YANG library affects this issue. > > > A vendor can put whatever URL they want in this leaf. > > > It is optional, so they don't have to support schema retrieval at all. > > > > If is it only auxiliary information, it doesn't IMO belong to > > yang-library. It is already available in ietf-netconf-monitoring so > > there is no need to duplicate it. > > > > Lada > > > > > > > > > > > > > > > > >> > > >> Lada > > >> > > > > > > > > > Andy > > > > > > > > >> > > >> -- > > >> Ladislav Lhotka, CZ.NIC Labs > > >> PGP Key ID: E74E8C0C > > >> > > >> _______________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netconf > > >> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > --001a11424d0ccb8cc205272de556 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 18, 2015 at 7:16 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> >
> >> Hi,
> >>
> >> I reviewed the draft and found several issues:
> >>
> >>=C2=A0 =C2=A0 =C2=A0- The purpose of "yang-protocol"= and "restricted-protocol" is
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0unclear from the text. I know it fr= om the mailing list
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0discussion, but I think this soluti= on is not good. What if a
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0device runs, e.g., multiple RESTCON= F servers on different ports,
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0each with a specific data model? IM= O the best solution is to
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0have yang-library information speci= fic for each protocol server
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0instance. The "*-protocol"= ; leafs than wouldn't be needed.
> >>
> >>
> >
> > This approach appears simple, but it requires the server
> > to implement dynamic content for this module instead of static co= ntent.
> > It also prevents the operator from knowing what other protocols m= ight
> > be clashing with their client.

Yes.=C2=A0 But actually the current model doesn't prevent someone from<= br> using different instances of ietf-yang-library for different
protocols.


> This assumes there is a single server process and each protocol is jus= t
> an interface to it. But there can also be separate server processes, > each with its own configuration. So at least sec. 2.1.2 should talk > about "server instance" and not about "managed device&q= uot;.
>
> I think it is sensitive information: why should every client of every<= br> > protocol know all management protocols available on the device?
>
> Other state data are often dynamically generated, so I don't think= it's
> such a big problem - each client will just receive the data it is
> entitled to work with.
>
> >
> > I think the YANG description-stmts for these leaf-lists are clear= .
>
> Well, the description of "yang-protocol" is:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Identifies a protocol th= at is using modules described
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in this library.=C2=A0 There = SHOULD be one instance of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this object for each protocol= for each YANG-based
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol using this library.&= quot;;
>
> This is IMO totally unclear. What does "protocol" mean? Is i= t a protocol
> interacting with the same server process, or any protocol on any virtu= al
> server? Is this "yang-protocol" leaf-list related somehow to= the
> "restricted-protocol" leaf-list?

I think that restricted-protocol could as well be a leafref into
yang-protocol.


OK
<= div>
=C2=A0

> It would be OK to have this info as a part of netconf-monitoring or > similar regular state data - also because appropriate access
> restrictions can be applied. Yang-library is a critical structure, so = it
> should IMO contain only the information that's necessary but nothi= ng else.
>
> > Each virtual server has its own YANG library that covers the prot= ocols
> > used just on that virtual server.
> >
> >
> >
> >
> >>=C2=A0 =C2=A0 =C2=A0- The name "conformance" seems t= o be a misnomer: the leaf gives
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0information about how the module is= used by the server. What
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0about "role"?
> >>
> >
> >
> > Role is rather generic. How about conformance-role?
>
> OK.
>
> >
> >
> >
> >>=C2=A0 =C2=A0 =C2=A0- The descriptions of the enums "impl= ement" and "import" are
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0confusing and maybe incorrect. In m= y view, a server must include
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0in the yang-library all implemented= modules, and then those that
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0are (at least once) imported withou= t revision. Those that are
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0only imported by revision should no= t be in yang-library at
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0all. IMO *all* modules must appear = in yang-library no more than
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0once - otherwise, how a client coul= d determine which revision
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0(of several listed) was used for a = particular import without
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0revision?
> >>
> >>
> >
> > I disagree.
> > The YANG library needs to list all the modules.
> > A client must be able to predetermine the module set.
> > Otherwise the client has to parse the YANG module
> > and analyze all the imports (and imports in the imported modules,= until
> > the end of the dependency chain)
> >
> > What problem are you solving by leaving out modules and forcing t= he client
> > to
> > parse all the modules instead?
>
> I think I already described the problem. Let's say three revisions= of
> ietf-inet-types are listed in yang-library, and some module imports > ietf-inet-types without revision. How can the client tell which revisi= on
> should be used for this import?
>
> >
> >
> >
> >
> >
> >>=C2=A0 =C2=A0 =C2=A0- "implement" should also mean i= mplementing identities defined in
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0the module.
> >>
> >
> >
> > One does not implement identities.
>
> Are modules that contain only identities (iana-if-type) listed as
> "implement" or "import"?

"import", since "implement":

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indicates that the s= erver implements one or more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol-accessible = objects defined in the YANG module
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identified in this e= ntry.=C2=A0 This includes deviation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statements defined i= n the module.



I recently implemented = iana-crypt-hash in our server.
This has 3 YANG features that can = be advertised.
It seems strange to advertise that this module is = just imported,
and yet features are implemented.

We currently return conformance 'true' and all 3 features:=


=C2=A0 =C2=A0module =C2=A0ian= a-crypt-hash 2014-08-06 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 name iana-c= rypt-hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 revision 2014-08-06
=C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace urn:ietf:params:xml:ns:yang:iana-c= rypt-hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = conformance true
=C2=A0 =C2=A0 =C2=A0 =C2=A0 feature crypt-hash-m= d5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 feature crypt-hash-sha-256
=C2=A0 =C2=A0 =C2=A0 =C2=A0 feature crypt-hash-sha-512
=C2=A0 = =C2=A0 =C2=A0 }


I proposed an= RPC called "get-allowed-identities" in 2014
http= s://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-04

Even though YANG 1.1 allows if-feature in an identit= y, this does not
solve the iana-if-type problem.=C2=A0 It would b= e useful for the client app
to know what identities are relevant = for a given leaf.=C2=A0 Using 100s or 1000s
of YANG identities wo= uld be unmanageable.

There should be some way in a= YANG module to say that an identity-stmt
value is required for a= particular identityref, but not in this draft.





/martin

Andy
=C2=A0



> > Only leaf or leaf-list of type identityref can be implemented. > > YANG conformance is incapable of specifying the set of identities=
> > that a server MUST support (except the description-stmt).
> > This module is not intended to fix all the deficiencies of YANG c= onformance.
> >
> >
> >
> >>=C2=A0 =C2=A0 =C2=A0- Once upon a time, there was a discussion= in XML circles about
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0pros and cons of "xsd:schemaLo= cation". Some of the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0considerations also apply to the &q= uot;schema" leaf. I think the
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0client should either already have t= he modules/revisions listed
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0in yang-library, or be able to get = them from a well-known and
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0reliable location. The schema provi= ded by the device should not
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0be used as authoritative because ot= herwise vendors might be
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0tempted to serve clients with "= ;improved" versions that pretend
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be standard.
> >>
> >
> >
> > I don't see how the YANG library affects this issue.
> > A vendor can put whatever URL they want in this leaf.
> > It is optional, so they don't have to support schema retrieva= l at all.
>
> If is it only auxiliary information, it doesn't IMO belong to
> yang-library. It is already available in ietf-netconf-monitoring so > there is no need to duplicate it.
>
> Lada
>
> >
> >
> >
> >
> >>
> >> Lada
> >>
> >
> >
> > Andy
> >
> >
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/net= conf
> >>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br> >

--001a11424d0ccb8cc205272de556-- From nobody Fri Dec 18 07:38: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 781EA1B36A1 for ; Fri, 18 Dec 2015 07:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, 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 h1vw08CeILqa for ; Fri, 18 Dec 2015 07:38:03 -0800 (PST) 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 DEDED1B36A2 for ; Fri, 18 Dec 2015 07:38:02 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:95f1:e5af:5d06:4c6f] (unknown [IPv6:2001:718:1a02:1:95f1:e5af:5d06:4c6f]) by mail.nic.cz (Postfix) with ESMTPSA id 7E7E21816DB; Fri, 18 Dec 2015 16:38:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450453081; bh=fTJdSd+akOOoq7+FjZowECt807SFscoFxWLRN4fvr5Y=; h=From:Date:To; b=EIDri5hW5FVnfmMGTuLuDytHnRS6azvKWHcCH83B0/JapTT6K15kdpdoFN/1ZrBxR sBVT/Vz9yvle+k2zrjaEKV+W8NAHobPbQTemQt8qg1oIqXuU/p4e8FbitiO/ls4bOv yrCFgkdQ4Hqflx6aAIAMKcQlXdYbsryaNv5FpD3s= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20151218.161631.2267320672620851859.mbj@tail-f.com> Date: Fri, 18 Dec 2015 16:38:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1613C54D-CC8B-4DD6-9A07-E971740F6742@nic.cz> References: <20151218.161631.2267320672620851859.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] LL review of yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2015 15:38:05 -0000 > On 18 Dec 2015, at 16:16, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>> On Thu, Dec 17, 2015 at 7:47 AM, Ladislav Lhotka = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> I reviewed the draft and found several issues: >>>>=20 >>>> - The purpose of "yang-protocol" and "restricted-protocol" is >>>> unclear from the text. I know it from the mailing list >>>> discussion, but I think this solution is not good. What if a >>>> device runs, e.g., multiple RESTCONF servers on different = ports, >>>> each with a specific data model? IMO the best solution is to >>>> have yang-library information specific for each protocol = server >>>> instance. The "*-protocol" leafs than wouldn't be needed. >>>>=20 >>>>=20 >>>=20 >>> This approach appears simple, but it requires the server >>> to implement dynamic content for this module instead of static = content. >>> It also prevents the operator from knowing what other protocols = might >>> be clashing with their client. >=20 > Yes. But actually the current model doesn't prevent someone from > using different instances of ietf-yang-library for different > protocols. But then yang-protocol and restricted-protocol are useless. >=20 >=20 >> This assumes there is a single server process and each protocol is = just >> an interface to it. But there can also be separate server processes, >> each with its own configuration. So at least sec. 2.1.2 should talk >> about "server instance" and not about "managed device". >>=20 >> I think it is sensitive information: why should every client of every >> protocol know all management protocols available on the device? >>=20 >> Other state data are often dynamically generated, so I don't think = it's >> such a big problem - each client will just receive the data it is >> entitled to work with. >>=20 >>>=20 >>> I think the YANG description-stmts for these leaf-lists are clear. >>=20 >> Well, the description of "yang-protocol" is: >>=20 >> "Identifies a protocol that is using modules described >> in this library. There SHOULD be one instance of >> this object for each protocol for each YANG-based >> protocol using this library."; >>=20 >> This is IMO totally unclear. What does "protocol" mean? Is it a = protocol >> interacting with the same server process, or any protocol on any = virtual >> server? Is this "yang-protocol" leaf-list related somehow to the >> "restricted-protocol" leaf-list? >=20 > I think that restricted-protocol could as well be a leafref into > yang-protocol. Right, but currently the relationship is not even indicated in the = descriptions. >=20 >> It would be OK to have this info as a part of netconf-monitoring or >> similar regular state data - also because appropriate access >> restrictions can be applied. Yang-library is a critical structure, so = it >> should IMO contain only the information that's necessary but nothing = else. >>=20 >>> Each virtual server has its own YANG library that covers the = protocols >>> used just on that virtual server. >>>=20 >>>=20 >>>=20 >>>=20 >>>> - The name "conformance" seems to be a misnomer: the leaf gives >>>> information about how the module is used by the server. What >>>> about "role"? >>>>=20 >>>=20 >>>=20 >>> Role is rather generic. How about conformance-role? >>=20 >> OK. >>=20 >>>=20 >>>=20 >>>=20 >>>> - The descriptions of the enums "implement" and "import" are >>>> confusing and maybe incorrect. In my view, a server must = include >>>> in the yang-library all implemented modules, and then those = that >>>> are (at least once) imported without revision. Those that are >>>> only imported by revision should not be in yang-library at >>>> all. IMO *all* modules must appear in yang-library no more = than >>>> once - otherwise, how a client could determine which revision >>>> (of several listed) was used for a particular import without >>>> revision? >>>>=20 >>>>=20 >>>=20 >>> I disagree. >>> The YANG library needs to list all the modules. >>> A client must be able to predetermine the module set. >>> Otherwise the client has to parse the YANG module >>> and analyze all the imports (and imports in the imported modules, = until >>> the end of the dependency chain) >>>=20 >>> What problem are you solving by leaving out modules and forcing the = client >>> to >>> parse all the modules instead? >>=20 >> I think I already described the problem. Let's say three revisions of >> ietf-inet-types are listed in yang-library, and some module imports >> ietf-inet-types without revision. How can the client tell which = revision >> should be used for this import? >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> - "implement" should also mean implementing identities defined = in >>>> the module. >>>>=20 >>>=20 >>>=20 >>> One does not implement identities. >>=20 >> Are modules that contain only identities (iana-if-type) listed as >> "implement" or "import"? >=20 > "import", since "implement": Hmm, this seems to be at odds with 6020bis, sec. 9.10.2: Valid values for an identityref are any identities derived from all the identityref's base identities. On a particular server, the valid values are further restricted to the set of identities defined in the modules implemented by the server. Lada >=20 > Indicates that the server implements one or more > protocol-accessible objects defined in the YANG module > identified in this entry. This includes deviation > statements defined in the module. >=20 >=20 >=20 > /martin >=20 >=20 >=20 >>> Only leaf or leaf-list of type identityref can be implemented. >>> YANG conformance is incapable of specifying the set of identities >>> that a server MUST support (except the description-stmt). >>> This module is not intended to fix all the deficiencies of YANG = conformance. >>>=20 >>>=20 >>>=20 >>>> - Once upon a time, there was a discussion in XML circles about >>>> pros and cons of "xsd:schemaLocation". Some of the >>>> considerations also apply to the "schema" leaf. I think the >>>> client should either already have the modules/revisions listed >>>> in yang-library, or be able to get them from a well-known and >>>> reliable location. The schema provided by the device should = not >>>> be used as authoritative because otherwise vendors might be >>>> tempted to serve clients with "improved" versions that pretend >>>> to be standard. >>>>=20 >>>=20 >>>=20 >>> I don't see how the YANG library affects this issue. >>> A vendor can put whatever URL they want in this leaf. >>> It is optional, so they don't have to support schema retrieval at = all. >>=20 >> If is it only auxiliary information, it doesn't IMO belong to >> yang-library. It is already available in ietf-netconf-monitoring so >> there is no need to duplicate it. >>=20 >> Lada >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Lada >>>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>>=20 >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 18 09:47: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 8A3CE1B37A6 for ; Fri, 18 Dec 2015 09:47:47 -0800 (PST) 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 uNB83roeHPG3 for ; Fri, 18 Dec 2015 09:47:42 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0371B37A2 for ; Fri, 18 Dec 2015 09:47:41 -0800 (PST) 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.355.16; Fri, 18 Dec 2015 17:47:21 +0000 Message-ID: <00d301d139bb$dcdd1900$4001a8c0@gateway.2wire.net> From: t.petch To: Benoit Claise , Kent Watsen , NETCONF , Stephen Farrell References: <56705828.2040408@cisco.com> <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> <014a01d137f4$c9b6bfc0$4001a8c0@gateway.2wire.net> <90DCB502-A719-47C0-855A-7970940DB7F3@juniper.net> <5671BF10.4010506@cisco.com> <5671DE67.707@cs.tcd.ie> Date: Fri, 18 Dec 2015 17:30:50 +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: HE1PR08CA0037.eurprd08.prod.outlook.com (25.161.112.47) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 2:GTXqBPdpyJ1Mr4hfniaB0Tmvxxn/jCJhtgSkEjDOib1ImIFGcwWziT0fNMDoNKjg9X7nLz4M13pRD+YQ5L2gLOFI1DF/jinejoZDfV/XgFD/fEo5DsX7+hpot4OvgKrI0+ZaVfXTk2lFyRggbw5Ygg==; 3:lW1yQdwJBVKri7RqGvtEyEmj8xaceynYd2jUkZCKPTdgvOlMX3seRkxKPbygMrdCbs591S3oc/Wr7NvzxRMDEbpEn+1lC4c6AxlWoM4rJ6cgOE5djgA3pdZYHHeMSX8+; 25:q5Fz3d65AKivzkluCrQnjHbtaowSrGYy4PL+mrlX/kQj29pr2L9x5yz+mazoQwr4jOfLwIEsVsChzdru8WoX9J6iWVZdARzhs6gHizPaSTOSA89Y6IsSCaLFQPDT+haoGyLBDrG7mCOOUknjtgBgnvxiP7YH2zvwQcE70Qg4515mFZpuLE8G1gFbjhcYSHI/VUpnlrwDg3j1mtUdNat6Dxwk8kLP9MTJf5tDrOeBEkhQXXTsSUnFEAgm70u1UtqSNNNi2sa68RnkDZqSQTdSIA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(32856632585715)(138986009662008)(95692535739014)(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB052; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB052; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 4:oUOT2Ks5wlh6CR4MqPIQBhsyYKOUegueCeSP3Gyptx5Xdq0D1dKPrhTUe6A5QPkIfP+kkfXePQuRkHglGfDtfQRK3yrJ+wyyLJwU55e28yW6tWwAtl5lmBcUMAycil+wHqEO+mTxxhWVPP7b9o8Jw89Ydc4eZdq7wxWiPICwTerimYEVFsEbY4lYSZofIzzrcarFL7Knsn+rKEimIgDjGScAx7iygKaHfc4S5K0fqSCk8K+FmH4gKLpjoTM3LqBn2DASc5JPZvTg87YG2LYyaGnMx4GFZs1vJHFROk9laA7Qp4Wz+PKJmaNP5UaGcOx75Oy4GmQOwGHUrYXpTB8YZm15H5yULRR5pSlHYHq0aAp00uaNAaXZYuxj682Am+IiWbFLg3k2PX2xcIb/agEdoCBzGXdqgJpRbaJs8RyQjTv0ZhQvY2piFO28VeiddyRNCc7iKgE9D82kELfk9FOnB9xFr31MaOx3ymRd+FPqpxBgOphq7yaM1JlOsmvPfVhpF0ify2PhVOM1f25yLFGG0Q== X-Forefront-PRVS: 07943272E1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(53234004)(13464003)(189002)(43784003)(52604005)(377454003)(24454002)(57704003)(199003)(479174004)(84392001)(42186005)(44736004)(81686999)(1096002)(23676002)(47776003)(3846002)(6116002)(61296003)(33646002)(575784001)(106356001)(5004730100002)(44716002)(105586002)(87976001)(116806002)(1556002)(93886004)(5820100001)(62236002)(86362001)(50226001)(586003)(122386002)(81816999)(50466002)(189998001)(92566002)(76176999)(15975445007)(230783001)(107886002)(5001770100001)(1456003)(66066001)(14496001)(40100003)(5008740100001)(551544002)(97736004)(50986999)(1941001)(77096005)(19580395003)(81156007)(19580405001)(101416001)(5001960100002)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; 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?MTtBTVNQUjA3TUIwNTI7MjM6N2J5Z2ZsMzgwQTZPU05STUd4YXVMR2w0dVN3?= =?utf-8?B?RUJHRWFvZUdKMUZ6WVQzOFBGZU1KS2ZoRERia3pXM3lKc1Z2QzhMK2N3bGk4?= =?utf-8?B?bktOZ29oU3A5RGZ5bkdiQzA5cjFqWWY4aisyTUFKeEo2V3JIdW5HcnNSM0FV?= =?utf-8?B?YkZXQlNxQm9jYjZGVGtGdFNFWTh0ZDVoUzlOc1hQNmpZbDE5dDhIQ0dnNXVz?= =?utf-8?B?bTh5UXVVZXo5VGRBTCtENldXMVlpRndjTVRQRnBoR1VmeVA3K2FIQUJsWmND?= =?utf-8?B?RXVkQTBLL2wzNERaVTBxRnlRK2k3S0s0a0dTcGkyenJWc0hUU2w4OS9GbHAx?= =?utf-8?B?VjFEZGFhUFhYOTIzWDhoamFTTE1kUnhNZk0yVlpvTnFjMU9CcDBFQXZNUmxk?= =?utf-8?B?a2xoakdwbWN1blF1SDBuU3prUG9VQ0hKMkZUc1kzMGRMT1ljWktCcE05Q0ZS?= =?utf-8?B?VFRqNEZHaXVvWk5haGpmdzN1emRmc2hWRTgxQzNHZ2NUSWt0QWd6ZVJvS1ZX?= =?utf-8?B?dU4wMGJabFU4TGFsYWRmY2tTdHVWbjlFb2ZYMHdFamNtTEJRVG5VMkdHQkd3?= =?utf-8?B?SzV0N0IrM2FLbUhUQVorTU1MbEc1Y2hnYTE2SHI1dEhLNkVmeDBzQlF1b2kr?= =?utf-8?B?NDJLSmpacEw4TGszcmF6N05FYnhxRGxNYkJ4L2JVb21VM0NCWk9FbTluaG9v?= =?utf-8?B?VVNERjQ0TWJHTjBzdTZHQjdqbkFPaUhvQXE2NCtON1BPNGswMXhVNjVPMytu?= =?utf-8?B?UTdHUlA5MXZlYlhSOHpFd1FmOEJBZ040K3JjVHZxekJ1VXM5SjRBUnFYMjdx?= =?utf-8?B?MlFRNXlwSHRWWWoxa01rSFQyZVNCcHhkU0tiOVJ1TnFPck5LbndsMTlXd0lG?= =?utf-8?B?Sk9vbTVxYXZmZVdqZUpFZTVJbHFaME9SYitrcEwxNkZaME9iL3hqTU1IV2NI?= =?utf-8?B?NEdsa29RenNYNHc4bjJ0NERqcGY2OHBNSmhWa200eCs5cUNTdVhpNnVBZGw4?= =?utf-8?B?YmdRWGNHN0NaSWV5YnhVempvUDc4OVU4OVFlTHp4RWlsMnB2ZVNFRDF6OXdY?= =?utf-8?B?cnNDZTBJeUxJVjhzR005dEFyYWNnOXNUdyttR1RHRE9QOUJyN2lJSkkzaEU4?= =?utf-8?B?OHBvcWZvcG1XVU5qTVhxOUt1SFJEL29tN1pKRThTSnY4WkxGOW04eVM1ZERO?= =?utf-8?B?YjZ1bTF3akRlSFUxUFp4ajJwQUNXVk00RlZGQjNHcWg1VFlBcEc5cmNPN0ky?= =?utf-8?B?UFh3TXVTOVlScnU2UGdLMHdKd3RVY2tDS2VKQlIxSHJXQm5zazBUajNSa1Nl?= =?utf-8?B?d0tmVytncjZ0aVJyMXFVZmt1R05oWjFVUWMwNlRQY0lhQloxbXlaRXR3Z0h2?= =?utf-8?B?YVA0QS94VURhbVlOZXFwU3cxVmpwbXRrUDhYWndraUlPUkJKOWd6UWlkMExF?= =?utf-8?B?b3JtTjR3OG5DUkZPN3RIdGdETFplSG9LLzVUVkVoSXJ5RzBEcmUrUkxBZnVv?= =?utf-8?B?cmxxcjVqekloaFVhaC9FMGNoeUJEaFhjUjNTWVFBTVN0b1VpL2IvVk9TaDBN?= =?utf-8?B?MTRsS2dmQUtIcG5rWDlrWUw4SGtVcGQ0NTdHcHNFeWJGc0JqcERuRnAxRGk5?= =?utf-8?B?V1hBSmpnMXJhUWpVRXlYTDZtbUJVc1pvL0FDUzVFd241czNQZzkzYk5zVklu?= =?utf-8?B?dXJoZDc4TGkwQkVUK3E2a2RNeWlFWEJxUnVEN2IyeGdzdEJwWWlUbCtNd2wx?= =?utf-8?B?WUdzN2sxYVc5ZUZhT1o4Z0J6UksvUVBwank5MkNrSTM0M0svUFhrMlFZYXNU?= =?utf-8?B?L0hDUnplNmM4c2RKK2YzZUtSekhUNWRLTU1oRlZQVHFhblJxRVdta2hNc3Bu?= =?utf-8?B?VjM1VW9JVUd0NmhlY2pVeGxBT3RGSi9QQTBkeXdJcUwrQ1NBb2FoRENJVmJa?= =?utf-8?B?Q3A5SlVFNG1hUnYvSHNyeTNyajBuVGZnWkIyZXlic0l4SzArbXJRNk9zd2pE?= =?utf-8?B?MFRodFVPNktCcForalBqVTlPMFlEOE1UNHRoVVE1QXZ3d3BIREh6M2VrQzVt?= =?utf-8?B?UkVSNVNzY3NBSmcxSGxKL3ozTGg4dmRtK1kyMndTeXp5U1NETGM1dXJ2dkZa?= =?utf-8?Q?RfGOj+kIjK3cmJHYGTcZhc=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB052; 5:w5mq8aXsZDWMTholg0rUcwj/eiBoddGEy2VZorKlAD6h0uq3c1UvUWJbB6OCwaMhByRUSp/NOQsSA1Cx85gOjO5SScngoPFdK7yosrTByDZwH9hAx59c5dhDtA6RpFjdzwMac9Ua2ytpiBjVRRd6lA==; 24:2lD4Fcip3ixgVGGB6AWEkmf4/u1KCpZ8Ce7iIhVlD09O6z+ANTcpvrL2P5YGeCevRHDx0vNAvIQ/CQ5prwuxyNIDdLs+Y6Ciw5yWCWqr0Aw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2015 17:47:21.1931 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB052 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2015 17:47:47 -0000 Kent [Keeping Stephen on the CC since this is another possible one word change in the Security Considerations. ] Yes, definitely better. I still have one doubt, an ambiguity that I think does make a material difference to certificate validation, now that issuer is a generic term for the issuer of a certificate. 5. Security Considerations .... this RFC requires that the NETCONF/RESTCONF client validate the server's SSH host key or certificate, by certificate path validation to a preconfigured issuer certificate, or by .. [yes, that is clear] ... NETCONF/RESTCONF clients should ensure that the issuer certificate used for certificate path validation is unique to the manufacturer of the server. [ not so clear - should that be 'preconfigured issuer certificate'? - 'the certificate' implies to me a one and only whereas certificate path validation potentially involves many certificates in a path and since we are imposing a condition thereon, that makes a difference. Does ' certificate should not belong to a 3rd-party certificate authority that ... ' apply to all certificates in the path validation or just to the preconfigured issuer certificate? I don't know but see it affecting an implementation and the security implications thereof] Tom Petch ----- Original Message ----- From: "Stephen Farrell" To: "Benoit Claise" ; "Kent Watsen" ; "t.petch" ; "NETCONF" Sent: Wednesday, December 16, 2015 9:57 PM > > Hi Benoit. > > First, thanks to Benoit and Kent for explaining this to me off-list. > (I needed the explanation;-) > > The changes below seem fine to me, thanks for checking, > S. > > On 16/12/15 19:44, Benoit Claise wrote: > > Including Stephen, > > > > Stephen, there is a question for you in there. > >> Hi Tom, > >> > >> Thanks for your review, while most of this the editor can catch, a > >> couple issues you raised are a more involved (see below), thus I plan > >> to post a -16 with these fixes, along with the fix for the issue that > >> I found earlier. > >> > >> Regarding your comments: > >> > >>> I missed that one in C.1 but I hope that the RFC Editor catches a few > >>> more! For example, > >>> > >>> "the attacker doesn't posses a valid key." > >>> > >>> poss v.t. ' to mangle the language as a result of a review such as that > >>> of > >>> the IESG' :-) > >> fixed! (s/posses/possess/) > >> > >>> - the I-D uses a mixture of 'Issuer' and 'trust anchor' seemingly both > >>> to refer to the top of the chain of certificates; what is the > >>> significance of this? For me, Trust Anchor is where it all starts, > >>> where you must verify the chain of certificates to whereas Issuer is the > >>> issuer of a certificate, any certificate, from end entity via > >>> intermediate to trust anchor, but I realise that that opinions on this > >>> vary. RFC6125 uses trust anchor for the top of the chain while > >>> RFC5280 uses Issuer for, well, the issuer of any certificate. > >> The draft originally had Trust Anchor everywhere, but then Joe Salowey > >> (TLS co-chair) also said that a "Trust Anchor" typically refers to a > >> self-signed cert (a root cert), and so I started writing “Issuer†in > >> new text, but never updated the old text. > >> > >> Fixed! (replaced “Trust Anchor†with “Issuerâ€, and removed > >> capitalization on “issuerâ€) > >> > >>> - likewise, the client security credential used for RESTCONF is a mix of > >>> 'shared secret', 'password' or 'shared key' - the last seems wrong to > >>> me. I note that the cited RFC, 7616 and 7617, use password. > >> Fixed! (replaced "shared key" with "shared secret (e.g., a password)â€) > >> > >> > >>> - C.6 "Clients SHOULD > >>> ensure that the Issuer used to authenticate the presented > >>> certificate defines the namespace for the identifiers of > >>> interest. " > >>> > >>> I don't understand this. If a certificate has a dNSName or iPAddress in > >>> it, in what sense does the certificate define the namespace? > >> I’m think that this sentence in C-6 should be removed, as the Security > >> Considerations section says it better: > >> > >> For cases when the NETCONF/RESTCONF server presents an X.509 > >> certificate, NETCONF/RESTCONF clients should ensure that the > >> issuer certificate used for certificate path validation is > >> unique to the manufacturer of the server. That is, the certificate > >> should not belong to a 3rd-party certificate authority that > >> might issue intermediate certificates for more than one > >> manufacturer. > >> > >> Both the sentence in C-6 sentence the the Security Considerations > >> paragraph were added to address an item from Stephen Farrell. You > >> can see them both in one github commit here: > >> https://github.com/netconf-wg/call-home/commit/1b9d54f5f4b441c8c79d65b03 8080b402e7e0ab4. > >> > >> > >> Do we need to get Stephen’s approval to remove the sentence in C-6 > >> now? (question for chairs or AD) > > Yes. > > > > Regards, Benoit > >> > >>> - S.5 I am surprised that the Security reviews did not mention the need > >>> not to action messages prior to successful user authentication. There > >>> is a strong drive in the use of TLS by websites to eliminate round trips > >>> so that user data is sent before a secure channel has been established, > >>> with the data being resent or discarded if the setup of the secure > >>> channel does not complete. This requires applications to know what is > >>> going on. Likewise, where the user authentication is a separate > >>> function, performed after the 'secure' channel has been set up, it may > >>> be ok for the web user to send data and for the web server to act upon > >>> it, albeit not in a way that could cause harm. The use of these > >>> protocols by NETCONF is rather different, acting on data from a > >>> yet-to-be authenticated user could be unfortunate, and the server should > >>> be cautious about accepting data until the secure channel really has > >>> been set up. I am thinking that before too long, we will have TLS > >>> stacks that are optimised for fast web access but are a danger to > >>> operational applications, and so might have added a phrase at the end of > >>> S5 to the effect that any user data must be then discarded. But if this > >>> was not raised, then it is probably best left to linger a while longer. > >> Agreed (no change) > >> > >> > >>> - " For cases when the NETCONF/RESTCONF server presents an X.509 > >>> certificate, NETCONF/RESTCONF clients should ensure that the Issuer > >>> certificate used for certificate path validation is unique to the > >>> manufacturer of the server. That is, the certificate should not > >>> belong to a 3rd-party certificate authority that might issue > >>> intermediate certificates for more than one manufacturer. " > >>> > >>> This confuses me. Issuer seems to be trust anchor from other uses of > >>> the term so this seems to be saying that all servers of a given > >>> manufacturer must have certificate chains leading back to the same trust > >>> anchor and that that trust anchor must not issue certificates for any > >>> other manufacturer - but then what is 'intermediate' doing in there? I > >>> would expect the number of intermediate certicates to range from zero to > >>> n, but have otherwise no particular properties. > >> Fixed! (removed word “intermediateâ€) > >> > >>> I note that the Normative reference to restconf means that this will not > >>> advance for many months, but guess that that time is best spent in the > >>> RFC-Editor queue. > >> True, but hopefully not for too many months! ;) > >> > >>> Tom Petch > >> Thanks again, > >> Kent From nobody Fri Dec 18 10:58:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F681B37A0 for ; Fri, 18 Dec 2015 10:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYsFUWhbnqKO for ; Fri, 18 Dec 2015 10:58:18 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86CB1B37C8 for ; Fri, 18 Dec 2015 10:58:17 -0800 (PST) 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.355.16; Fri, 18 Dec 2015 18:57:55 +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.0355.012; Fri, 18 Dec 2015 18:57:55 +0000 From: Kent Watsen To: t.petch , Benoit Claise , NETCONF , Stephen Farrell Thread-Topic: [Netconf] draft-ietf-netconf-call-home: one week review period Thread-Index: AQHRN2Q/AAKWEU0VAEuTicTbq77KWZ7MPj4AgAE9ILmAACm5AIAAYGsAgAAlXICAAt6q////v92A Date: Fri, 18 Dec 2015 18:57:55 +0000 Message-ID: References: <56705828.2040408@cisco.com> <838D12C4-5EC3-46C9-8571-5AB1D7CA4B5D@juniper.net> <014a01d137f4$c9b6bfc0$4001a8c0@gateway.2wire.net> <90DCB502-A719-47C0-855A-7970940DB7F3@juniper.net> <5671BF10.4010506@cisco.com> <5671DE67.707@cs.tcd.ie> <00d301d139bb$dcdd1900$4001a8c0@gateway.2wire.net> In-Reply-To: <00d301d139bb$dcdd1900$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.151105 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:lAKs+vTvaBESyAp405PSzPZ9g7W6WMVfGmzg6GLv2fh4tCj1jXnSjdPbaCGRQ8qiQvfxaA92SAmzKr7dhYF/K/XGBYAJz+5vUJw414flZg3x3TYXbGfZ0b/erP0QF+FFyUfxKzNuECWXPN98clHuRQ==; 24:00BWMf+OvPzd8x5iJ+Hwx9+lr8+Nm5AdsTph5ihf4h4F4IgLGuKiM+tezVDQIxdn0t221E5wsILOCk/z/eSVye250ZeP8N6VB75F01eGeh0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(138986009662008)(95692535739014)(178726229863574); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 07943272E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(43784003)(57704003)(377454003)(52604005)(24454002)(53234004)(479174004)(189002)(36756003)(189998001)(33656002)(5001960100002)(4001350100001)(5001770100001)(92566002)(106116001)(99286002)(54356999)(81156007)(66066001)(106356001)(83506001)(15975445007)(107886002)(83716003)(101416001)(87936001)(77096005)(19580395003)(10400500002)(97736004)(82746002)(2900100001)(105586002)(5004730100002)(11100500001)(2950100001)(1096002)(122556002)(86362001)(5002640100001)(76176999)(6116002)(586003)(40100003)(19580405001)(551544002)(575784001)(3846002)(50986999)(230783001)(102836003)(1220700001)(93886004)(5008740100001)(7059030)(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: <1D5F7151F31F5A44B4DBF89F780BD845@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2015 18:57:55.3793 (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: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 18 Dec 2015 18:58:26 -0000 SGkgVG9tLA0KDQpUaGFua3MgZm9yIHN0aWNraW5nIHdpdGggdGhpcy4NCg0KT2theSwgc28gcmVz cG9uZGluZyBmcm9tIHRoZSBib3R0b20gdXAuDQoNCjEuIEkgYmVsaWV2ZSB0aGF0IGl0IGlzIG9r YXkgZm9yIHRoZSBjbGF1c2UgImNlcnRpZmljYXRlIHNob3VsZCBub3QgYmVsb25nIHRvIGEgM3Jk LXBhcnR5IGNlcnRpZmljYXRlIGF1dGhvcml0eSIgdG8gYXBwbHkgdG8ganVzdCB0aGUgcHJlY29u ZmlndXJlZCBpc3N1ZXIgY2VydGlmaWNhdGUsIGFzIGFueSBpbnRlcm1lZGlhdGUgQ0EgY2VydGlm aWNhdGVzIGl0IG1heSBzaWduIGFyZSBnb2luZyB0byBiZSB1bmRlciBpdHMgc2NvcGUsIGFuZCBo ZW5jZSBhbHNvIG5vdCBiZWxvbmcgdG8gYSAzcmQtcGFydHkgY2VydGlmaWNhdGUgYXV0aG9yaXR5 Lg0KDQoyLiBSZWdhcmRpbmcgYWRkaW5nIHRoZSB3b3JkIOKAnHByZWNvbmZpZ3VyZWTigJ0gaW4g dGhlIHNlbnRlbmNlICJORVRDT05GL1JFU1RDT05GIGNsaWVudHMgc2hvdWxkIGVuc3VyZSB0aGF0 IHRoZSBbcHJlY29uZmlndXJlZF0gaXNzdWVyIGNlcnRpZmljYXRlIHVzZWQgZm9yIGNlcnRpZmlj YXRlIHBhdGggdmFsaWRhdGlvbiBpcyB1bmlxdWUgdG8gdGhlIG1hbnVmYWN0dXJlciBvZiB0aGUg c2VydmVyLuKAnSwgSSBhZ3JlZSB0aGF0IGl0IGlzIGEgbGl0dGxlIG1vcmUgY2xlYXIsIHNpbmNl IGl0IHVzZXMgdGhlIGV4YWN0IHNhbWUgYWRqZWN0aXZlcywgYnV0IEkgYWxzbyBiZWxpZXZlIHRo YXQgdGhlIGV4aXN0aW5nIHNlbnRlbmNlLCBhcyBpdCBzdGFuZHMsIGlzIHRlY2huaWNhbGx5IGNv cnJlY3QvdW5hbWJpZ3VvdXMuICBKdXN0IHRoZSBzYW1lLCBzaW5jZSB3ZSBhZ3JlZSB0aGF0IGl0 cyBiZXR0ZXIsIEnigJltIHRvIHBvc3QgYSAtMTcgd2l0aCB0aGlzIG9uZSB3b3JkIGNoYW5nZSwg d2hpY2ggYXBwZWFycyB0byBtZSBhcyBhIG1pbm9yIGVkaXRvcmlhbCBmaXguICBUaGF0IHNhaWQs IEnigJlsbCBob2xkIG9mZiBmb3IgYSBjb3VwbGUgZGF5cyBqdXN0IGluIGNhc2UgYW55b25lIHdh bnRzIHRvIHZvaWNlIGFuIG9iamVjdGlvbi4NCg0KVGhhbmtzIGFnYWluLA0KS2VudA0KDQoNCg0K DQoNCk9uIDEyLzE4LzE1LCAxMjozMCBQTSwgInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29t PiB3cm90ZToNCg0KPktlbnQNCj4NCj5bS2VlcGluZyBTdGVwaGVuIG9uIHRoZSBDQyBzaW5jZSB0 aGlzIGlzIGFub3RoZXIgcG9zc2libGUgb25lIHdvcmQNCj5jaGFuZ2UgaW4gdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zLiBdDQo+DQo+WWVzLCBkZWZpbml0ZWx5IGJldHRlci4gIEkgc3RpbGwg aGF2ZSBvbmUgZG91YnQsIGFuIGFtYmlndWl0eSB0aGF0IEkNCj50aGluayBkb2VzIG1ha2UgYSBt YXRlcmlhbCBkaWZmZXJlbmNlIHRvIGNlcnRpZmljYXRlIHZhbGlkYXRpb24sIG5vdw0KPnRoYXQg aXNzdWVyIGlzIGEgZ2VuZXJpYyB0ZXJtIGZvciB0aGUgaXNzdWVyIG9mIGEgY2VydGlmaWNhdGUu DQo+DQo+DQo+NS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+Li4uLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyBSRkMgcmVxdWlyZXMgdGhhdA0KPnRo ZQ0KPiAgIE5FVENPTkYvUkVTVENPTkYgY2xpZW50IHZhbGlkYXRlIHRoZSBzZXJ2ZXIncyBTU0gg aG9zdCBrZXkgb3INCj4gICBjZXJ0aWZpY2F0ZSwgYnkgY2VydGlmaWNhdGUgcGF0aCB2YWxpZGF0 aW9uIHRvIGEgcHJlY29uZmlndXJlZCBpc3N1ZXINCj4gICBjZXJ0aWZpY2F0ZSwgb3IgYnkgLi4N Cj5beWVzLCB0aGF0IGlzIGNsZWFyXQ0KPg0KPi4uLiAgICAgICAgICAgIE5FVENPTkYvUkVTVENP TkYgY2xpZW50cyBzaG91bGQgZW5zdXJlIHRoYXQgdGhlIGlzc3Vlcg0KPiAgIGNlcnRpZmljYXRl IHVzZWQgZm9yIGNlcnRpZmljYXRlIHBhdGggdmFsaWRhdGlvbiBpcyB1bmlxdWUgdG8gdGhlDQo+ ICAgbWFudWZhY3R1cmVyIG9mIHRoZSBzZXJ2ZXIuDQo+WyBub3Qgc28gY2xlYXIgLSBzaG91bGQg dGhhdCBiZSAncHJlY29uZmlndXJlZCBpc3N1ZXIgY2VydGlmaWNhdGUnPyAtDQo+J3RoZSBjZXJ0 aWZpY2F0ZScgaW1wbGllcyB0byBtZSBhIG9uZSBhbmQgb25seSB3aGVyZWFzIGNlcnRpZmljYXRl IHBhdGgNCj52YWxpZGF0aW9uIHBvdGVudGlhbGx5IGludm9sdmVzIG1hbnkgY2VydGlmaWNhdGVz IGluIGEgcGF0aCBhbmQgc2luY2Ugd2UNCj5hcmUgaW1wb3NpbmcgYSBjb25kaXRpb24gdGhlcmVv biwgdGhhdCBtYWtlcyBhIGRpZmZlcmVuY2UuICBEb2VzICcNCj5jZXJ0aWZpY2F0ZSBzaG91bGQg bm90IGJlbG9uZyB0byBhIDNyZC1wYXJ0eSBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkgdGhhdA0KPi4u LiAnIGFwcGx5IHRvIGFsbCBjZXJ0aWZpY2F0ZXMgaW4gdGhlIHBhdGggdmFsaWRhdGlvbiBvciBq dXN0IHRvIHRoZQ0KPnByZWNvbmZpZ3VyZWQgaXNzdWVyIGNlcnRpZmljYXRlPw0KPkkgZG9uJ3Qg a25vdyBidXQgc2VlIGl0IGFmZmVjdGluZyBhbiBpbXBsZW1lbnRhdGlvbiBhbmQgdGhlIHNlY3Vy aXR5DQo+aW1wbGljYXRpb25zIHRoZXJlb2ZdDQo+DQo+VG9tIFBldGNoDQo+DQo+LS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQ0KPkZyb206ICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZh cnJlbGxAY3MudGNkLmllPg0KPlRvOiAiQmVub2l0IENsYWlzZSIgPGJjbGFpc2VAY2lzY28uY29t PjsgIktlbnQgV2F0c2VuIg0KPjxrd2F0c2VuQGp1bmlwZXIubmV0PjsgInQucGV0Y2giIDxpZXRm Y0BidGNvbm5lY3QuY29tPjsgIk5FVENPTkYiDQo+PG5ldGNvbmZAaWV0Zi5vcmc+DQo+U2VudDog V2VkbmVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNSA5OjU3IFBNDQo+Pg0KPj4gSGkgQmVub2l0Lg0K Pj4NCj4+IEZpcnN0LCB0aGFua3MgdG8gQmVub2l0IGFuZCBLZW50IGZvciBleHBsYWluaW5nIHRo aXMgdG8gbWUgb2ZmLWxpc3QuDQo+PiAoSSBuZWVkZWQgdGhlIGV4cGxhbmF0aW9uOy0pDQo+Pg0K Pj4gVGhlIGNoYW5nZXMgYmVsb3cgc2VlbSBmaW5lIHRvIG1lLCB0aGFua3MgZm9yIGNoZWNraW5n LA0KPj4gUy4NCj4+DQo+PiBPbiAxNi8xMi8xNSAxOTo0NCwgQmVub2l0IENsYWlzZSB3cm90ZToN Cj4+ID4gSW5jbHVkaW5nIFN0ZXBoZW4sDQo+PiA+DQo+PiA+IFN0ZXBoZW4sIHRoZXJlIGlzIGEg cXVlc3Rpb24gZm9yIHlvdSBpbiB0aGVyZS4NCj4+ID4+IEhpIFRvbSwNCj4+ID4+DQo+PiA+PiBU aGFua3MgZm9yIHlvdXIgcmV2aWV3LCB3aGlsZSBtb3N0IG9mIHRoaXMgdGhlIGVkaXRvciBjYW4g Y2F0Y2gsIGENCj4+ID4+IGNvdXBsZSBpc3N1ZXMgeW91IHJhaXNlZCBhcmUgYSBtb3JlIGludm9s dmVkIChzZWUgYmVsb3cpLCB0aHVzIEkNCj5wbGFuDQo+PiA+PiB0byBwb3N0IGEgLTE2IHdpdGgg dGhlc2UgZml4ZXMsIGFsb25nIHdpdGggdGhlIGZpeCBmb3IgdGhlIGlzc3VlDQo+dGhhdA0KPj4g Pj4gSSBmb3VuZCBlYXJsaWVyLg0KPj4gPj4NCj4+ID4+IFJlZ2FyZGluZyB5b3VyIGNvbW1lbnRz Og0KPj4gPj4NCj4+ID4+PiBJIG1pc3NlZCB0aGF0IG9uZSBpbiBDLjEgYnV0IEkgaG9wZSB0aGF0 IHRoZSBSRkMgRWRpdG9yIGNhdGNoZXMgYQ0KPmZldw0KPj4gPj4+IG1vcmUhIEZvciBleGFtcGxl LA0KPj4gPj4+DQo+PiA+Pj4gInRoZSBhdHRhY2tlciBkb2Vzbid0IHBvc3NlcyBhIHZhbGlkIGtl eS4iDQo+PiA+Pj4NCj4+ID4+PiBwb3NzIHYudC4gJyB0byBtYW5nbGUgdGhlIGxhbmd1YWdlIGFz IGEgcmVzdWx0IG9mIGEgcmV2aWV3IHN1Y2ggYXMNCj50aGF0DQo+PiA+Pj4gb2YNCj4+ID4+PiB0 aGUgSUVTRycgOi0pDQo+PiA+PiBmaXhlZCEgIChzL3Bvc3Nlcy9wb3NzZXNzLykNCj4+ID4+DQo+ PiA+Pj4gLSB0aGUgSS1EIHVzZXMgYSBtaXh0dXJlIG9mICdJc3N1ZXInIGFuZCAndHJ1c3QgYW5j aG9yJyBzZWVtaW5nbHkNCj5ib3RoDQo+PiA+Pj4gdG8gcmVmZXIgdG8gdGhlIHRvcCBvZiB0aGUg Y2hhaW4gb2YgY2VydGlmaWNhdGVzOyB3aGF0IGlzIHRoZQ0KPj4gPj4+IHNpZ25pZmljYW5jZSBv ZiB0aGlzPyAgRm9yIG1lLCBUcnVzdCBBbmNob3IgaXMgd2hlcmUgaXQgYWxsDQo+c3RhcnRzLA0K Pj4gPj4+IHdoZXJlIHlvdSBtdXN0IHZlcmlmeSB0aGUgY2hhaW4gb2YgY2VydGlmaWNhdGVzIHRv IHdoZXJlYXMgSXNzdWVyDQo+aXMgdGhlDQo+PiA+Pj4gaXNzdWVyIG9mIGEgY2VydGlmaWNhdGUs IGFueSBjZXJ0aWZpY2F0ZSwgZnJvbSBlbmQgZW50aXR5IHZpYQ0KPj4gPj4+IGludGVybWVkaWF0 ZSB0byB0cnVzdCBhbmNob3IsIGJ1dCBJIHJlYWxpc2UgdGhhdCB0aGF0IG9waW5pb25zIG9uDQo+ dGhpcw0KPj4gPj4+IHZhcnkuICBSRkM2MTI1IHVzZXMgdHJ1c3QgYW5jaG9yIGZvciB0aGUgdG9w IG9mIHRoZSBjaGFpbiB3aGlsZQ0KPj4gPj4+IFJGQzUyODAgdXNlcyBJc3N1ZXIgZm9yLCB3ZWxs LCB0aGUgaXNzdWVyIG9mIGFueSBjZXJ0aWZpY2F0ZS4NCj4+ID4+IFRoZSBkcmFmdCBvcmlnaW5h bGx5IGhhZCBUcnVzdCBBbmNob3IgZXZlcnl3aGVyZSwgYnV0IHRoZW4gSm9lDQo+U2Fsb3dleQ0K Pj4gPj4gKFRMUyBjby1jaGFpcikgYWxzbyBzYWlkIHRoYXQgYSAiVHJ1c3QgQW5jaG9yIiB0eXBp Y2FsbHkgcmVmZXJzIHRvDQo+YQ0KPj4gPj4gc2VsZi1zaWduZWQgY2VydCAoYSByb290IGNlcnQp LCBhbmQgc28gSSBzdGFydGVkIHdyaXRpbmcg4oCcSXNzdWVy4oCdDQo+aW4NCj4+ID4+IG5ldyB0 ZXh0LCBidXQgbmV2ZXIgdXBkYXRlZCB0aGUgb2xkIHRleHQuDQo+PiA+Pg0KPj4gPj4gRml4ZWQh ICAocmVwbGFjZWQg4oCcVHJ1c3QgQW5jaG9y4oCdIHdpdGgg4oCcSXNzdWVy4oCdLCBhbmQgcmVt b3ZlZA0KPj4gPj4gY2FwaXRhbGl6YXRpb24gb24g4oCcaXNzdWVy4oCdKQ0KPj4gPj4NCj4+ID4+ PiAtIGxpa2V3aXNlLCB0aGUgY2xpZW50IHNlY3VyaXR5IGNyZWRlbnRpYWwgdXNlZCBmb3IgUkVT VENPTkYgaXMgYQ0KPm1peCBvZg0KPj4gPj4+ICdzaGFyZWQgc2VjcmV0JywgJ3Bhc3N3b3JkJyBv ciAnc2hhcmVkIGtleScgLSB0aGUgbGFzdCBzZWVtcyB3cm9uZw0KPnRvDQo+PiA+Pj4gbWUuICBJ IG5vdGUgdGhhdCB0aGUgY2l0ZWQgUkZDLCA3NjE2IGFuZCA3NjE3LCB1c2UgcGFzc3dvcmQuDQo+ PiA+PiBGaXhlZCEgIChyZXBsYWNlZCAic2hhcmVkIGtleSIgd2l0aCAic2hhcmVkIHNlY3JldCAo ZS5nLiwgYQ0KPnBhc3N3b3JkKeKAnSkNCj4+ID4+DQo+PiA+Pg0KPj4gPj4+IC0gQy42ICJDbGll bnRzIFNIT1VMRA0KPj4gPj4+ICAgICAgICBlbnN1cmUgdGhhdCB0aGUgSXNzdWVyIHVzZWQgdG8g YXV0aGVudGljYXRlIHRoZSBwcmVzZW50ZWQNCj4+ID4+PiAgICAgICAgY2VydGlmaWNhdGUgZGVm aW5lcyB0aGUgbmFtZXNwYWNlIGZvciB0aGUgaWRlbnRpZmllcnMgb2YNCj4+ID4+PiAgICAgICAg aW50ZXJlc3QuICAiDQo+PiA+Pj4NCj4+ID4+PiBJIGRvbid0IHVuZGVyc3RhbmQgdGhpcy4gIElm IGEgY2VydGlmaWNhdGUgaGFzIGEgZE5TTmFtZSBvcg0KPmlQQWRkcmVzcyBpbg0KPj4gPj4+IGl0 LCBpbiB3aGF0IHNlbnNlIGRvZXMgdGhlIGNlcnRpZmljYXRlIGRlZmluZSB0aGUgbmFtZXNwYWNl Pw0KPj4gPj4gSeKAmW0gdGhpbmsgdGhhdCB0aGlzIHNlbnRlbmNlIGluIEMtNiBzaG91bGQgYmUg cmVtb3ZlZCwgYXMgdGhlDQo+U2VjdXJpdHkNCj4+ID4+IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g c2F5cyBpdCBiZXR0ZXI6DQo+PiA+Pg0KPj4gPj4gICAgICBGb3IgY2FzZXMgd2hlbiB0aGUgTkVU Q09ORi9SRVNUQ09ORiBzZXJ2ZXIgcHJlc2VudHMgYW4gWC41MDkNCj4+ID4+ICAgICAgY2VydGlm aWNhdGUsIE5FVENPTkYvUkVTVENPTkYgY2xpZW50cyBzaG91bGQgZW5zdXJlIHRoYXQgdGhlDQo+ PiA+PiAgICAgIGlzc3VlciBjZXJ0aWZpY2F0ZSB1c2VkIGZvciBjZXJ0aWZpY2F0ZSBwYXRoIHZh bGlkYXRpb24gaXMNCj4+ID4+ICAgICAgdW5pcXVlIHRvIHRoZSBtYW51ZmFjdHVyZXIgb2YgdGhl IHNlcnZlci4gIFRoYXQgaXMsIHRoZQ0KPmNlcnRpZmljYXRlDQo+PiA+PiAgICAgIHNob3VsZCBu b3QgYmVsb25nIHRvIGEgM3JkLXBhcnR5IGNlcnRpZmljYXRlIGF1dGhvcml0eSB0aGF0DQo+PiA+ PiAgICAgIG1pZ2h0IGlzc3VlIGludGVybWVkaWF0ZSBjZXJ0aWZpY2F0ZXMgZm9yIG1vcmUgdGhh biBvbmUNCj4+ID4+IG1hbnVmYWN0dXJlci4NCj4+ID4+DQo+PiA+PiBCb3RoIHRoZSBzZW50ZW5j ZSBpbiBDLTYgc2VudGVuY2UgdGhlIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPj4gPj4g cGFyYWdyYXBoIHdlcmUgYWRkZWQgdG8gYWRkcmVzcyBhbiBpdGVtIGZyb20gU3RlcGhlbiBGYXJy ZWxsLiAgIFlvdQ0KPj4gPj4gY2FuIHNlZSB0aGVtIGJvdGggaW4gb25lIGdpdGh1YiBjb21taXQg aGVyZToNCj4+ID4+DQo+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvY2FsbC1ob21lL2Nv bW1pdC8xYjlkNTRmNWY0YjQ0MWM4Yzc5ZDY1YjAzDQo+ODA4MGI0MDJlN2UwYWI0Lg0KPj4gPj4N Cj4+ID4+DQo+PiA+PiBEbyB3ZSBuZWVkIHRvIGdldCBTdGVwaGVu4oCZcyBhcHByb3ZhbCB0byBy ZW1vdmUgdGhlIHNlbnRlbmNlIGluIEMtNg0KPj4gPj4gbm93PyAgIChxdWVzdGlvbiBmb3IgY2hh aXJzIG9yIEFEKQ0KPj4gPiBZZXMuDQo+PiA+DQo+PiA+IFJlZ2FyZHMsIEJlbm9pdA0KPj4gPj4N Cj4+ID4+PiAtIFMuNSAgSSBhbSBzdXJwcmlzZWQgdGhhdCB0aGUgU2VjdXJpdHkgcmV2aWV3cyBk aWQgbm90IG1lbnRpb24NCj50aGUgbmVlZA0KPj4gPj4+IG5vdCB0byBhY3Rpb24gbWVzc2FnZXMg cHJpb3IgdG8gc3VjY2Vzc2Z1bCB1c2VyIGF1dGhlbnRpY2F0aW9uLg0KPlRoZXJlDQo+PiA+Pj4g aXMgYSBzdHJvbmcgZHJpdmUgaW4gdGhlIHVzZSBvZiBUTFMgYnkgd2Vic2l0ZXMgdG8gZWxpbWlu YXRlIHJvdW5kDQo+dHJpcHMNCj4+ID4+PiBzbyB0aGF0IHVzZXIgZGF0YSBpcyBzZW50IGJlZm9y ZSBhIHNlY3VyZSBjaGFubmVsIGhhcyBiZWVuDQo+ZXN0YWJsaXNoZWQsDQo+PiA+Pj4gd2l0aCB0 aGUgZGF0YSBiZWluZyByZXNlbnQgb3IgZGlzY2FyZGVkIGlmIHRoZSBzZXR1cCBvZiB0aGUgc2Vj dXJlDQo+PiA+Pj4gY2hhbm5lbCBkb2VzIG5vdCBjb21wbGV0ZS4gIFRoaXMgcmVxdWlyZXMgYXBw bGljYXRpb25zIHRvIGtub3cNCj53aGF0IGlzDQo+PiA+Pj4gZ29pbmcgb24uICBMaWtld2lzZSwg d2hlcmUgdGhlIHVzZXIgYXV0aGVudGljYXRpb24gaXMgYSBzZXBhcmF0ZQ0KPj4gPj4+IGZ1bmN0 aW9uLCBwZXJmb3JtZWQgYWZ0ZXIgdGhlICdzZWN1cmUnIGNoYW5uZWwgaGFzIGJlZW4gc2V0IHVw LCBpdA0KPm1heQ0KPj4gPj4+IGJlIG9rIGZvciB0aGUgd2ViIHVzZXIgdG8gc2VuZCBkYXRhIGFu ZCBmb3IgdGhlIHdlYiBzZXJ2ZXIgdG8gYWN0DQo+dXBvbg0KPj4gPj4+IGl0LCBhbGJlaXQgbm90 IGluIGEgd2F5IHRoYXQgY291bGQgY2F1c2UgaGFybS4gIFRoZSB1c2Ugb2YgdGhlc2UNCj4+ID4+ PiBwcm90b2NvbHMgYnkgTkVUQ09ORiBpcyByYXRoZXIgZGlmZmVyZW50LCBhY3Rpbmcgb24gZGF0 YSBmcm9tIGENCj4+ID4+PiB5ZXQtdG8tYmUgYXV0aGVudGljYXRlZCB1c2VyIGNvdWxkIGJlIHVu Zm9ydHVuYXRlLCBhbmQgdGhlIHNlcnZlcg0KPnNob3VsZA0KPj4gPj4+IGJlIGNhdXRpb3VzIGFi b3V0IGFjY2VwdGluZyBkYXRhIHVudGlsIHRoZSBzZWN1cmUgY2hhbm5lbCByZWFsbHkNCj5oYXMN Cj4+ID4+PiBiZWVuIHNldCB1cC4gIEkgYW0gdGhpbmtpbmcgdGhhdCBiZWZvcmUgdG9vIGxvbmcs IHdlIHdpbGwgaGF2ZSBUTFMNCj4+ID4+PiBzdGFja3MgdGhhdCBhcmUgb3B0aW1pc2VkIGZvciBm YXN0IHdlYiBhY2Nlc3MgYnV0IGFyZSBhIGRhbmdlciB0bw0KPj4gPj4+IG9wZXJhdGlvbmFsIGFw cGxpY2F0aW9ucywgYW5kIHNvIG1pZ2h0IGhhdmUgYWRkZWQgYSBwaHJhc2UgYXQgdGhlDQo+ZW5k IG9mDQo+PiA+Pj4gUzUgdG8gdGhlIGVmZmVjdCB0aGF0IGFueSB1c2VyIGRhdGEgbXVzdCBiZSB0 aGVuIGRpc2NhcmRlZC4gIEJ1dA0KPmlmIHRoaXMNCj4+ID4+PiB3YXMgbm90IHJhaXNlZCwgdGhl biBpdCBpcyBwcm9iYWJseSBiZXN0IGxlZnQgdG8gbGluZ2VyIGEgd2hpbGUNCj5sb25nZXIuDQo+ PiA+PiBBZ3JlZWQgKG5vIGNoYW5nZSkNCj4+ID4+DQo+PiA+Pg0KPj4gPj4+IC0gIiBGb3IgY2Fz ZXMgd2hlbiB0aGUgTkVUQ09ORi9SRVNUQ09ORiBzZXJ2ZXIgcHJlc2VudHMgYW4gWC41MDkNCj4+ ID4+PiAgICBjZXJ0aWZpY2F0ZSwgTkVUQ09ORi9SRVNUQ09ORiBjbGllbnRzIHNob3VsZCBlbnN1 cmUgdGhhdCB0aGUNCj5Jc3N1ZXINCj4+ID4+PiAgICBjZXJ0aWZpY2F0ZSB1c2VkIGZvciBjZXJ0 aWZpY2F0ZSBwYXRoIHZhbGlkYXRpb24gaXMgdW5pcXVlIHRvDQo+dGhlDQo+PiA+Pj4gICAgbWFu dWZhY3R1cmVyIG9mIHRoZSBzZXJ2ZXIuICBUaGF0IGlzLCB0aGUgY2VydGlmaWNhdGUgc2hvdWxk DQo+bm90DQo+PiA+Pj4gICAgYmVsb25nIHRvIGEgM3JkLXBhcnR5IGNlcnRpZmljYXRlIGF1dGhv cml0eSB0aGF0IG1pZ2h0IGlzc3VlDQo+PiA+Pj4gICAgaW50ZXJtZWRpYXRlIGNlcnRpZmljYXRl cyBmb3IgbW9yZSB0aGFuIG9uZSBtYW51ZmFjdHVyZXIuICAiDQo+PiA+Pj4NCj4+ID4+PiBUaGlz IGNvbmZ1c2VzIG1lLiAgSXNzdWVyIHNlZW1zIHRvIGJlIHRydXN0IGFuY2hvciBmcm9tIG90aGVy IHVzZXMNCj5vZg0KPj4gPj4+IHRoZSB0ZXJtIHNvIHRoaXMgc2VlbXMgdG8gYmUgc2F5aW5nIHRo YXQgYWxsIHNlcnZlcnMgb2YgYSBnaXZlbg0KPj4gPj4+IG1hbnVmYWN0dXJlciBtdXN0IGhhdmUg Y2VydGlmaWNhdGUgY2hhaW5zIGxlYWRpbmcgYmFjayB0byB0aGUgc2FtZQ0KPnRydXN0DQo+PiA+ Pj4gYW5jaG9yIGFuZCB0aGF0IHRoYXQgdHJ1c3QgYW5jaG9yIG11c3Qgbm90IGlzc3VlIGNlcnRp ZmljYXRlcyBmb3INCj5hbnkNCj4+ID4+PiBvdGhlciBtYW51ZmFjdHVyZXIgLSBidXQgdGhlbiB3 aGF0IGlzICdpbnRlcm1lZGlhdGUnIGRvaW5nIGluDQo+dGhlcmU/ICAgSQ0KPj4gPj4+IHdvdWxk IGV4cGVjdCB0aGUgbnVtYmVyIG9mIGludGVybWVkaWF0ZSBjZXJ0aWNhdGVzIHRvIHJhbmdlIGZy b20NCj56ZXJvIHRvDQo+PiA+Pj4gbiwgYnV0IGhhdmUgb3RoZXJ3aXNlIG5vIHBhcnRpY3VsYXIg cHJvcGVydGllcy4NCj4+ID4+IEZpeGVkISAgKHJlbW92ZWQgd29yZCDigJxpbnRlcm1lZGlhdGXi gJ0pDQo+PiA+Pg0KPj4gPj4+IEkgbm90ZSB0aGF0IHRoZSBOb3JtYXRpdmUgcmVmZXJlbmNlIHRv IHJlc3Rjb25mIG1lYW5zIHRoYXQgdGhpcw0KPndpbGwgbm90DQo+PiA+Pj4gYWR2YW5jZSBmb3Ig bWFueSBtb250aHMsIGJ1dCBndWVzcyB0aGF0IHRoYXQgdGltZSBpcyBiZXN0IHNwZW50IGluDQo+ dGhlDQo+PiA+Pj4gUkZDLUVkaXRvciBxdWV1ZS4NCj4+ID4+IFRydWUsIGJ1dCBob3BlZnVsbHkg bm90IGZvciB0b28gbWFueSBtb250aHMhICA7KQ0KPj4gPj4NCj4+ID4+PiBUb20gUGV0Y2gNCj4+ ID4+IFRoYW5rcyBhZ2FpbiwNCj4+ID4+IEtlbnQNCj4NCg== From nobody Tue Dec 22 07:32:55 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 104CE1A1A67; Tue, 22 Dec 2015 07:32:54 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151222153254.14460.35523.idtracker@ietfa.amsl.com> Date: Tue, 22 Dec 2015 07:32:54 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-17.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 15:32:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-17.txt Pages : 14 Date : 2015-12-22 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 22 07:35: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 29B6C1A1A7E for ; Tue, 22 Dec 2015 07:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxU429061g9f for ; Tue, 22 Dec 2015 07:35:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D5E1A1A82 for ; Tue, 22 Dec 2015 07:35:14 -0800 (PST) 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.361.13; Tue, 22 Dec 2015 15:35:13 +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.0361.006; Tue, 22 Dec 2015 15:35:13 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-17.txt Thread-Index: AQHRPM4KJC4G9JsaVEmj8tuxpJYUFJ7Wz0mA Date: Tue, 22 Dec 2015 15:35:12 +0000 Message-ID: <98420D9F-271C-456F-B60F-841BBD5CB300@juniper.net> References: <20151222153254.14460.35523.idtracker@ietfa.amsl.com> In-Reply-To: <20151222153254.14460.35523.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.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:v8LB+SScq312XExaGMo2NYqMxIDvM5eBxJXddj5uOCM8glOEEld+fAhAwB/JAxuY8yiIwtt7O2KvlLwwy4f9+u5y631PoYW4mWr9Qu+BFCe2BZJKFmpts5/cBYw5E6OJGFQ2un7oD4jnypt3uAxZDw==; 24:HND/wt8vK0lYU6MW6Fgx0zFtFy25SSqBr35oJeZXYhj+srXj3V8S+dfp2+cH3Kq14ILXWA7nUYZn1mJwbH88f7CjpWx6CAWBtUBi64lsdCE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; 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)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0798146F16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(24454002)(377454003)(479174004)(164054003)(189002)(199003)(76176999)(92566002)(2950100001)(33656002)(2501003)(5001960100002)(15975445007)(54356999)(77096005)(2900100001)(81156007)(97736004)(10400500002)(586003)(101416001)(122556002)(83716003)(230783001)(6116002)(1220700001)(110136002)(4001350100001)(1096002)(107886002)(3846002)(19580405001)(4001150100001)(2351001)(86362001)(82746002)(5004730100002)(50986999)(87936001)(36756003)(40100003)(189998001)(5002640100001)(19580395003)(1730700002)(83506001)(102836003)(5008740100001)(450100001)(106116001)(105586002)(66066001)(11100500001)(106356001)(99286002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; 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: <2C8D4B82FBE372408377529875068D9A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2015 15:35:12.8543 (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: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-17.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 15:35:18 -0000 DQpUaGlzIHVwZGF0ZSBhZGRzIHRoZSB3b3JkIOKAnHByZWNvbmZpZ3VyZWTigJ0gYXMgVG9tIGFu ZCBJIGRpc2N1c3NlZCBsYXN0IEZyaWRheS4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQoNCk9u IDEyLzIyLzE1LCAxMDozMiBBTSwgIk5ldGNvbmYgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4N Cj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9u IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAg OiBORVRDT05GIENhbGwgSG9tZSBhbmQgUkVTVENPTkYgQ2FsbCBIb21lDQo+ICAgICAgICBBdXRo b3IgICAgICAgICAgOiBLZW50IFdhdHNlbg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LW5ldGNvbmYtY2FsbC1ob21lLTE3LnR4dA0KPglQYWdlcyAgICAgICAgICAgOiAxNA0KPglEYXRl ICAgICAgICAgICAgOiAyMDE1LTEyLTIyDQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBSRkMgcHJl c2VudHMgTkVUQ09ORiBDYWxsIEhvbWUgYW5kIFJFU1RDT05GIENhbGwgSG9tZSwgd2hpY2gNCj4g ICBlbmFibGUgYSBORVRDT05GIG9yIFJFU1RDT05GIHNlcnZlciB0byBpbml0aWF0ZSBhIHNlY3Vy ZSBjb25uZWN0aW9uDQo+ICAgdG8gYSBORVRDT05GIG9yIFJFU1RDT05GIGNsaWVudCByZXNwZWN0 aXZlbHkuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1u ZXRjb25mLWNhbGwtaG9tZS8NCj4NCj5UaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2 YWlsYWJsZSBhdDoNCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRj b25mLWNhbGwtaG9tZS0xNw0KPg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0xNw0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj51 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+TmV0Y29u ZiBtYWlsaW5nIGxpc3QNCj5OZXRjb25mQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= From nobody Tue Dec 22 13:44: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 B17F11A909B for ; Tue, 22 Dec 2015 13:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHggZaeBPkcm for ; Tue, 22 Dec 2015 13:44:39 -0800 (PST) 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 470DE1A9093 for ; Tue, 22 Dec 2015 13:44:39 -0800 (PST) Received: by mail-pa0-x22e.google.com with SMTP id jx14so95223940pad.2 for ; Tue, 22 Dec 2015 13:44:39 -0800 (PST) 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=XbW7S7zfydf31WI4snWHDN0YJMhqpzSz5Qo5GE7B5Lc=; b=AB/1dJNHeReKrW1NixTgAh+rGPh25KZt032Jk8GBb1g2g8RBAc+JQYK845PcfCU6CP YlSRLeMhMoXQR1gktEIvKKD43494q5IMqYRmElXyo8tfOzir6eQhTPSDtDJLijV8Kzkf qGKjftGeHloSJYdulTBAT8l0uyTjfPUEtJMfGWnUY5dk+isc22zXbmA3SXFwyAVKLS+j tixD/AtgmYVcWWc3X7Kq704M+J/cahOfWdogaUCM6Dwlfp27amsLJ+0krEB2gA934pbj bXhWwoMZXpyDSAMSkS46t17AoX6FEWE0gPt/ikU+boGqO4IcIqER88fGid4eyc8lVSxO JIcQ== X-Received: by 10.67.14.201 with SMTP id fi9mr39026426pad.41.1450820678935; Tue, 22 Dec 2015 13:44:38 -0800 (PST) Received: from [10.154.204.209] ([128.107.241.168]) by smtp.gmail.com with ESMTPSA id m68sm30466408pfj.70.2015.12.22.13.44.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Dec 2015 13:44:38 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F45D67A4-D95A-4FB1-B65A-9C12C1D66F4A" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: <56705828.2040408@cisco.com> Date: Tue, 22 Dec 2015 13:44:37 -0800 Message-Id: <004F6BCB-D01C-4867-9033-A4D8E3C37D21@gmail.com> References: <56705828.2040408@cisco.com> To: NETCONF X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 22 Dec 2015 21:44:40 -0000 --Apple-Mail=_F45D67A4-D95A-4FB1-B65A-9C12C1D66F4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The one week review period for the above draft ends today. A -17 = version of = the draft incorporates comments received during this review period. This = document will be forwarded for RFC publication. Thanks. > On Dec 15, 2015, at 10:12 AM, Benoit Claise wrote: >=20 > Dear all, >=20 > Between the version 11, initially transmitted to the IESG, and the = latest version 15, addressing all the DISCUSSes, there were a series of = changes. > I propose a one week review for those changes = , before I sent this document to the = RFC-editor queue. > If you have a problem with those changes, speak up now. >=20 > Regards, Benoit >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F45D67A4-D95A-4FB1-B65A-9C12C1D66F4A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The one week review period for the above draft ends today. A -17 version of the draft incorporates comments received during this review period. This document will be forwarded for RFC publication.

Thanks.


On Dec 15, 2015, at 10:12 AM, Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

Between the version 11, initially transmitted to the IESG, and the latest version 15, addressing all the DISCUSSes, there were a series of changes.
I propose a one week review for those changes, before I sent this document to the RFC-editor queue.
If you have a problem with those changes, speak up now.

Regards, Benoit

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

Mahesh Jethanandani



--Apple-Mail=_F45D67A4-D95A-4FB1-B65A-9C12C1D66F4A-- From nobody Wed Dec 23 01:32: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 AA6991ACE09 for ; Wed, 23 Dec 2015 01:32:07 -0800 (PST) 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 wfKr1ZFDf_CC for ; Wed, 23 Dec 2015 01:32:06 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAE61A8797 for ; Wed, 23 Dec 2015 01:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5368; q=dns/txt; s=iport; t=1450863125; x=1452072725; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=d9+GT1jEHQSm0zsoc5+0XB1efwVV0PDFsxSrgfh7tjI=; b=kakbE9uBOffNnWUhJQcWQkl8KMiKukQzE7EIS2+syVdlKx3baJv1EU3I 5i2mpIqc0iE5Vz2H8C8yrCfGiVi9eHInkmezebH9g/3xAAbO280qHAnuQ tvOX1dWdoHJpJ2Gn6p0DpIE4if/gTcy02rlrwQK6PcfKN8RtYf58jUEdh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBAC5aHpW/xbLJq1ehAxtjFGydhgBC?= =?us-ascii?q?4UhSgKBbgEBAQEBAYELhDUBAQQBAQFrChELDgoJFggHCQMCAQIBDwYfEQYBDAY?= =?us-ascii?q?CAQGIFgMSDrtSDYN1AQEBAQEBAQEBAQEBAQEBAQEBFwSGVoR/gk+GbgWTCIN6h?= =?us-ascii?q?TuGGYF4gVyHSYVUhmGDZoN0ZIQMPTSFKAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,468,1444694400"; d="scan'208,217";a="610087692" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2015 09:32:03 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBN9W3Ow027590; Wed, 23 Dec 2015 09:32:03 GMT To: Mahesh Jethanandani , NETCONF References: <56705828.2040408@cisco.com> <004F6BCB-D01C-4867-9033-A4D8E3C37D21@gmail.com> From: Benoit Claise Message-ID: <567A6A13.2080103@cisco.com> Date: Wed, 23 Dec 2015 10:32:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <004F6BCB-D01C-4867-9033-A4D8E3C37D21@gmail.com> Content-Type: multipart/alternative; boundary="------------070505000504010606070608" Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home: one week review period X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 23 Dec 2015 09:32:07 -0000 This is a multi-part message in MIME format. --------------070505000504010606070608 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/22/2015 10:44 PM, Mahesh Jethanandani wrote: > The one week review period for the above draft ends today. A -17 > version > of the draft incorporates comments received during this review period. > This document will be forwarded for RFC publication. Now done. Thanks all for your work on this one. Regards, Benoit > > Thanks. > > >> On Dec 15, 2015, at 10:12 AM, Benoit Claise > > wrote: >> >> Dear all, >> >> Between the version 11, initially transmitted to the IESG, and the >> latest version 15, addressing all the DISCUSSes, there were a series >> of changes. >> I propose a one week review for those changes >> , >> before I sent this document to the RFC-editor queue. >> If you have a problem with those changes, speak up now. >> >> Regards, Benoit >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > Mahesh Jethanandani > mjethanandani@gmail.com > > > --------------070505000504010606070608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 12/22/2015 10:44 PM, Mahesh Jethanandani wrote:
The one week review period for the above draft ends today. A -17 version of the draft incorporates comments received during this review period. This document will be forwarded for RFC publication.
Now done.
Thanks all for your work on this one.

Regards, Benoit

Thanks.


On Dec 15, 2015, at 10:12 AM, Benoit Claise <bclaise@cisco.com> wrote:

Dear all,

Between the version 11, initially transmitted to the IESG, and the latest version 15, addressing all the DISCUSSes, there were a series of changes.
I propose a one week review for those changes, before I sent this document to the RFC-editor queue.
If you have a problem with those changes, speak up now.

Regards, Benoit

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

Mahesh Jethanandani




--------------070505000504010606070608-- From nobody Wed Dec 23 21:52: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 6A40C1A9066 for ; Wed, 23 Dec 2015 21:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.04 X-Spam-Level: X-Spam-Status: No, score=0.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Xrcy_bI0c0k for ; Wed, 23 Dec 2015 21:52:18 -0800 (PST) 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 7C7811A9064 for ; Wed, 23 Dec 2015 21:52:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBZ82589; Thu, 24 Dec 2015 05:52:14 +0000 (GMT) Received: from LHREML705-CAH.china.huawei.com (10.201.5.168) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Dec 2015 05:52:13 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Dec 2015 05:52:12 +0000 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.252]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Thu, 24 Dec 2015 13:52:07 +0800 From: Qin Wu To: "Ersue, Mehmet (Nokia - DE/Munich)" , "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 Thread-Index: AdE3eTk+yj/4s/NrQu2LeR6gt3+K2gABKaiQAaPtw4A= Date: Thu, 24 Dec 2015 05:52: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.136.78.255] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA852A9AF9nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.567B880F.009B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.252, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 422256327d27c1045ccd6b3a5608fc23 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 24 Dec 2015 05:52:21 -0000 --_000_B8F9A780D330094D99AF023C5877DABA852A9AF9nkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi0wOSBhbmQgSSBoYXZl IHRoZSBmb2xsb3dpbmcgcXVpY2sgZWRpdG9yaWFsIGNvbW1lbnRzOg0KDQoxLiAgICAgIFNlY3Rp b24gMy42DQpJbiB2LTA4LCBzdXBwb3J0IGZvciBZQU5HIDEuMSBhY3Rpb24gc3RhdGVtZW50IGlz IGFkZGVkLCBidXQgbG9vayBhdCBzZWN0aW9uIDMuNiwgaXQgaXMgbm90IGNsZWFyIHRvIG1lIGhv dyBycGMgc3RhdGVtZW50IGlzIHVzZWQgZGlmZmVyZW50IGZyb20gcnBjIHN0YXRlbWVudD8gSWYg dGhlcmUgaXMgc29tZSBkaWZmZXJlbmNlLCBpdCB3aWxsIGJlIGdyZWF0IHRvIGNsYXJpZnkgdGhp cyBpbiB0aGUgc2VjdGlvbiAzLjYuDQoNCjIuICAgICAgU2VjdGlvbiAzLjYgc2FpZDoNCqGwDQog ICBBbiBSUEMgb3BlcmF0aW9uIGlzIGludm9rZWQgYXM6DQoNCiAgIFBPU1QgeytyZXN0Y29uZn0v b3BlcmF0aW9ucy88b3BlcmF0aW9uPg0KobENCkl0IGxvb2tzIHsrcmVzdGNvbmZ9IHN0YW5kcyBm b3IgdGhlIFJFU1RDT05GIEFQSSBlbnRyeSBwb2ludA0KLEkgYW0gd29uZGVyaW5nIHsrcmVzdGNv bmZ9IGlzIGRpZmZlcmVudCBmcm9tIKGwL3Jlc3Rjb25mobEgaW4gdGhlIGV4YW1wbGUuIElzIKGw L3Jlc3Rjb25mobEgYW4gZXhhbXBsZSBvZiB7K3Jlc3Rjb25mfT8NCg0KM6OuIFNlY3Rpb24gNS4x LCAybmQgcGFyYWdyYXBoDQoNCldvdWxkIGl0IGJlIGdyZWF0IHRvIHVzZSBhbiBleGFtcGxlIHRv IGV4cGxhaW4gaG93IFJFU1RDT05GIG9wZXJhdGlvbiBpcyBkZXJpdmVkIGZyb20gdGhlIEhUVFAg bWV0aG9kIGFuZCB0aGUgcmVxdWVzdCBVUkk/IEUuZy4sIHlvdSBjYW4gcmVmZXJlbmNlIHRoZSBl eGFtcGxlIGluIHRoZSBBcHBlbmRpeCB0byBleHBsYWluIHRoaXM/DQoNCg0KNC4gICAgICAgU2Vj dGlvbiA1LjEgc2FpZDoNCqGwDQogICAgIDxPUD4gLzxyZXN0Y29uZj4vPHBhdGg+PzxxdWVyeT4j PGZyYWdtZW50Pg0KDQogICAgICAgICBeICAgICAgIF4gICAgICAgIF4gICAgICAgXiAgICAgICAg IF4NCiAgICAgICAgIHwgICAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgICAgfA0KICAgICAg IG1ldGhvZCAgZW50cnkgIHJlc291cmNlICBxdWVyeSAgICBmcmFnbWVudA0KDQogICAgICAgICBN ICAgICAgIE0gICAgICAgIE8gICAgICAgIE8gICAgICAgICBJDQoNCiAgICAgICBNPW1hbmRhdG9y eSwgTz1vcHRpb25hbCwgST1pZ25vcmVkDQoNCiAgICA8dGV4dD4gcmVwbGFjZWQgYnkgY2xpZW50 IHdpdGggcmVhbCB2YWx1ZXMNCg0KobENCg0KSXQgbG9va3MgPHRleHQ+IGRvZXMgbm90IGFwcGVh ciBpbiB0aGUgYWJvdmUgVVJJIHN0cnVjdHVyZSwgaXMgdGhlIDx0ZXh0PiBwYXJ0IG9mIHRoZSBh Ym92ZSBjb25jZXB0dWFsIGZpZWxkcz8NCg0KLVFpbg0Kt6K8/sjLOiBOZXRjb25mIFttYWlsdG86 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEVyc3VlLCBNZWhtZXQgKE5va2lhIC0gREUv TXVuaWNoKQ0Kt6LLzcqxvOQ6IDIwMTXE6jEy1MIxNsjVIDU6MTcNCsrVvP7IyzogbmV0Y29uZkBp ZXRmLm9yZw0K1vfM4jogW05ldGNvbmZdIEZXOiBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYt bmV0Y29uZi1yZXN0Y29uZi0wOSwgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcGF0Y2gtMDcgYW5k IGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLWxpYnJhcnktMDMNCg0KVGhlIGRlYWRsaW5lIGlzIGZv ciBzdXJlIEphbnVhcnkgMjIsIDIwMTYgRU9CIFBULg0KDQpNZWhtZXQNCg0KRnJvbTogRXJzdWUs IE1laG1ldCAoTm9raWEgLSBERS9NdW5pY2gpDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNSwg MjAxNSA5OjU5IFBNDQpUbzogbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9y Zz4NCkNjOiAnY29yZUBpZXRmLm9yZycgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5v cmc+PjsgJ2kycnNAaWV0Zi5vcmcnIDxpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3Jn Pj47ICc2bG9AaWV0Zi5vcmcnIDw2bG9AaWV0Zi5vcmc8bWFpbHRvOjZsb0BpZXRmLm9yZz4+OyAn NnRpc2NoQGlldGYub3JnJyA8NnRpc2NoQGlldGYub3JnPG1haWx0bzo2dGlzY2hAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYt MDksIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXBhdGNoLTA3IGFuZCBkcmFmdC1pZXRmLW5ldGNv bmYteWFuZy1saWJyYXJ5LTAzDQoNCkRlYXIgTkVUQ09ORiBXRywNCg0Kd2UgaGVyZWJ5IGlzc3Vl IGEgV0cgTGFzdCBDYWxsIGZvciB0aGUgZHJhZnRzIGJlbG93Og0KDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMDkudHh0DQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wYXRjaC0wNy50eHQNCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi15YW5nLWxpYnJhcnkt MDMudHh0DQoNClBsZWFzZSByZXZpZXcgYW5kIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgTkVU Q09ORiBXRyBtYWlsaW5nIGxpc3QgYnkgSmFudWFyeSAyMiwgMjAxNSBFT0IgUFQuDQoNClRoZSBk cmFmdHMgb24gUkVTVENPTkYsIFlBTkcgcGF0Y2ggYW5kIFlBTkcgbGlicmFyeSBhcmUgcGxhbm5l ZCB0byBwdWJsaXNoIGFzIHN0YW5kYXJkIHRyYWNrIGRvY3VtZW50cy4NCg0KQXMgUkVTVENPTkYg aXMgYSBtYWpvciBwcm90b2NvbCB3ZSBzZWVrIGEgZGV0YWlsZWQgYW5kIHRob3JvdWdoIHJldmll dyB3aXRoaW4gTkVUQ09ORiBXRyBidXQgYWxzbyBieSB0aGUgcmVsYXRlZCBXR3MgYmVmb3JlIHB1 Ymxpc2hpbmcuDQpUaGVyZWZvcmUgdGhlIFdHTEMgaXMgcGxhbm5lZCB0byBmaW5hbGl6ZSBvbiBK YW51YXJ5IDIydGggKGNvdmVyaW5nIHRoZSBob2xpZGF5IHRpbWUgaW4gYmV0d2VlbikgYW5kIEFQ UCwgSU5UIGFuZCBSVEcgYXJlYSBBRHMgd2lsbCBiZSBpbmZvcm1lZCBhcyB3ZWxsIGFzIENvcmUs IEkyUlMsIDZsbywgYW5kIDZ0aXNjaCBXR3MgYXJlIGludml0ZWQgdG8gcmV2aWV3Lg0KDQpQbGVh c2UgdGFrZSB5b3VyIHRpbWUgdG8gcmV2aWV3IHRoZSBkb2N1bWVudHMgYW5kIHNlbmQgeW91ciBj b21tZW50cyB0byB0aGUgTkVUQ09ORiBtYWlsbGlzdCBieSB0aGUgZGVhZGxpbmUuDQpQbGVhc2Ug c3RhdGUgb24gTkVUQ09ORiBtYWlsbGlzdCBhbHNvIGV4cGxpY2l0bHksIHdoZXRoZXIgeW91IGhh dmUgcmVhZC9yZXZpZXdlZCBhbmQgd2hldGhlciB5b3Ugc3VwcG9ydCB0aGUgcHVibGljYXRpb24u DQpGdXJ0aGVybW9yZSBwbGVhc2UgaW5kaWNhdGUgaWYgeW91IHBsYW4gdG8gaW1wbGVtZW50IG9y IGhhdmUgYWxyZWFkeSBpbXBsZW1lbnRhdGlvbnMgZm9yIFJFU1RDT05GIGFuZCBpdHMgc3VwcGxl bWVudGFyeSBkcmFmdHMuDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGtpbmQgaGVs cCBnZXR0aW5nIFJFU1RDT05GIHNwZWNpZmljYXRpb25zIHN0YWJsZS4NCg0KQmVzdCBSZWdhcmRz LA0KTWVobWV0IGFuZCBNYWhlc2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg== --_000_B8F9A780D330094D99AF023C5877DABA852A9AF9nkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I have reviewed draft-ietf-netc= onf-restconf-09 and I have the following quick editorial comments:

1= .   &= nbsp;  Section 3.6<= /span>

In v-08, support for YANG 1.1 a= ction statement is added, but look at section 3.6, it is not clear to me ho= w rpc statement is used different from rpc statement? If there is some diff= erence, it will be great to clarify this in the section 3.6.

2= .   &= nbsp;  Section 3.6 said:<= /o:p>

=A1=B0

   An RPC operation is invoked as:

 

   POST {+restconf}/operations/<operation>

=A1=B1

It looks {+restconf} stands= for the RES= TCONF API entry point

,I am wondering {+restconf}= is different from =A1=B0/restconf=A1=B1 in the example. Is =A1=B0/restconf= =A1=B1 an example of {+restconf}?

 = ;

3=A3=AE Section 5.1, 2nd parag= raph

Would it be great to use a= n example to explain how RESTCONF operation is derived from the HTTP method= and the request URI? E.g., you can reference the example in the Appendix t= o explain this?

 = ;

4.  =      Section 5.1 said= :

=A1=B0

     <OP> /<restconf>/<path>?<= ;query>#<fragment>

 

         ^    &= nbsp;  ^        ^  &= nbsp;    ^         ^=

         |   &n= bsp;   |        |  &= nbsp;    |         |=

       method  entry  resource=   query    fragment

 

         M   &n= bsp;   M        O  &= nbsp;     O       &n= bsp; I

 

       M=3Dmandatory, O=3Doptional, I=3D= ignored

 

    <text> replaced by client with real values

 = ;

=A1=B1

It looks <text> does= not appear in the above URI structure, is the <text> part of the abo= ve conceptual fields?

 = ;

-Qin

=B7=A2=BC=FE=C8=CB: Netconf= [mailto:netconf-bounces@ietf.org] =B4=FA= =B1=ED Ersue, Mehmet (Nokia - DE/Munich)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA12=D4=C216=C8=D5 5:17
=CA=D5=BC=FE=C8=CB: netconf@ietf.org
=D6=F7=CC=E2: [Netconf] FW: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf= -netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

 

The deadli= ne is for sure January 22, 2016 EOB PT.

 = ;

Mehmet

 

From: Ersue, Mehmet (Nokia - DE/Munich)
Sent: Tuesday, December 15, 2015 9:59 PM
To: netconf@ietf.org
Cc: 'core@ietf.org' <core@ietf.o= rg>; 'i2rs@ietf.org' <i2rs@ietf.= org>; '6lo@ietf.org' <6lo@ietf.or= g>; '6tisch@ietf.org' <6tisch@= ietf.org>
Subject: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf= -netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

 

Dear NETCO= NF WG,

 = ;

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

 = ;

http://tools.= ietf.org/html/draft-ietf-netconf-restconf-09.txt

http://tool= s.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt<= /p>

http://to= ols.ietf.org/html/draft-ietf-netconf-yang-library-03.txt

 

Please rev= iew and send your comments to the NETCONF WG mailing list by January 22, 20= 15 EOB PT.

 = ;

The drafts= on RESTCONF, YANG patch and YANG library are planned to publish as standar= d track documents.

 = ;

As RESTCON= F is a major protocol we seek a detailed and thorough review within NETCONF= WG but also by the related WGs before publishing.

Therefore = the WGLC is planned to finalize on January 22th (covering the holiday time = in between) and APP, INT and RTG area ADs will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to review.

 = ;

Please tak= e your time to review the documents and send your comments to the NETCONF m= aillist by the deadline.

Please sta= te on NETCONF maillist also explicitly, whether you have read/reviewed and = whether you support the publication.

Furthermor= e please indicate if you plan to implement or have already implementations for RESTCONF and its suppl= ementary drafts.

 = ;

Thank you = for your review and kind help getting RESTCONF specifications stable.<= /o:p>

 = ;

Best Regar= ds,

Mehmet and= Mahesh

 = ;

--_000_B8F9A780D330094D99AF023C5877DABA852A9AF9nkgeml513mbxchi_-- From nobody Mon Dec 28 06:42:44 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 C060B1A00E5; Mon, 28 Dec 2015 06:42:38 -0800 (PST) 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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151228144238.6667.5320.idtracker@ietfa.amsl.com> Date: Mon, 28 Dec 2015 06:42:38 -0800 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, The IESG , rfc-editor@rfc-editor.org, netconf@ietf.org Subject: [Netconf] Protocol Action: 'NETCONF Call Home and RESTCONF Call Home' to Proposed Standard (draft-ietf-netconf-call-home-17.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, 28 Dec 2015 14:42:39 -0000 The IESG has approved the following document: - 'NETCONF Call Home and RESTCONF Call Home' (draft-ietf-netconf-call-home-17.txt) as Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ Technical Summary This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. Working Group Summary This document is a result of a split between this document and the server configuration data model which is its own draft. With the split most of the complexity in configuration has moved to the server model draft. There were 10 issues that were opened and closed on the draft. At this point there are no open issues. Document Quality This document was extensively reviewed and comments were provided both in IETF meetings and on the mailing list. Perhaps the most important discussion and which resulted in the split, is the discussion around hostname keys and SSH and TLS configuration. Both Tom Petch and Juergen gave extensive comments on the draft. Personnel The document shepherd is Mahesh Jethanandani. The responsible AD will be Benoit Claise. From nobody Mon Dec 28 18: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 5528C1ACF02 for ; Mon, 28 Dec 2015 18:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 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_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=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 ACnWZ0dr0Joh for ; Mon, 28 Dec 2015 18:55:02 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 294C61ACEFE for ; Mon, 28 Dec 2015 18:55:02 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id oh2so98409365lbb.3 for ; Mon, 28 Dec 2015 18:55:02 -0800 (PST) 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=ynPlMnWJJXwF1qmyt0s5f4K9cIDt8xuwmb5WLuPB+KU=; b=Cik2f3tzvp2csdhUGtWqQFVBsMrAp+g5u1VlWoCPfDAUTCZCAm145wiG/NPt2wNMBV PvuVwPxua7I6JCJAWtgQv8/zXxVKagXRCtIQW1HglS6WLM7b2n3G5SrKrUWtAevSAv4O XLC7d/a7yb//vdhLDLayY0jfWIeBJV4+S6HXvPvKKBzA+6FyfSfcLIeHp2smpETKNsNk nlKUZ/O8ZpYT3SSyJ8/3Rl/X7qz8rPYMeBw6brRkKIVqvtgcfjr69XcYjVgSCnDVTXPQ GjrQmRe93OEX4LDFXSOTGXRvHDzxnj6DtOsPP6t07nv3e7ij2pMRHtlFCOpdZ6uySQce rugQ== 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=ynPlMnWJJXwF1qmyt0s5f4K9cIDt8xuwmb5WLuPB+KU=; b=Ip+G82uMkVHq6r06gWRwSE9lO1abYTwL4+LGayu9ypPBu0Yf30jhkyMWtwCN/9+E0b aPK3ZqxttEyF5W6B2P0/QFdwJ7fhlEbklLLuwVlLA9cfQcXVIWE4ovanYZHa+w75AS+F LZWYS9ax9YwEiHYfHhWYCyHIrDSSXEZEEo+g6cntluwkGhdG1ZA8N9DGivmhD6SOykaQ XAYXz9H1BCRVUidZu1oksCTR23vcIjuIDZ43LgQ5bpDcFIUKJ2M+KLmoHFYZfBn9de8x tW9DGQQ4BuJAeT5wyBIulPIWCR2L9XVhlPZy5MVYDLf8WAsJqaKSeOrvBP5LZ9G29BYz tCQA== X-Gm-Message-State: ALoCoQnctD5VPPiGNpqHdiYAAxvub7DRUksOFaD02BDDcyj6CRE0WE6O3zwzrc+E/Rtk9cGrwte2eBESCLSLAXO8hP0GhMLF0g== MIME-Version: 1.0 X-Received: by 10.112.199.41 with SMTP id jh9mr15988237lbc.119.1451357700220; Mon, 28 Dec 2015 18:55:00 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 28 Dec 2015 18:55:00 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Dec 2015 18:55:00 -0800 Message-ID: From: Andy Bierman To: Qin Wu Content-Type: multipart/alternative; boundary=001a11c2368229ffa40528008c9d Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 29 Dec 2015 02:55:05 -0000 --001a11c2368229ffa40528008c9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 23, 2015 at 9:52 PM, Qin Wu wrote: > I have reviewed draft-ietf-netconf-restconf-09 and I have the following > quick editorial comments: > > 1. Section 3.6 > > In v-08, support for YANG 1.1 action statement is added, but look at > section 3.6, it is not clear to me how rpc statement is used different fr= om > rpc statement? If there is some difference, it will be great to clarify > this in the section 3.6. > > 2. Section 3.6 said: > > =E2=80=9C > > An RPC operation is invoked as: > > > > POST {+restconf}/operations/ > This text in rfc6020bis-08 is the only explanation of the difference The difference between an action and an rpc is that an action is tied to a node in the datastore, whereas an rpc is not. When an action is invoked, the node in the datastore is specified along with the name of the action and the input parameters. As you can see on RESTCONF-09, pg 23, the /restconf/data entry point is used, not /restconf/operations POST {+restconf}/data// POST /restconf/data/module-A:interfaces/reset-all Note that this is inconsistent with the NETCONF/XML encoding, which uses the element: * * apache-1 2014-07-29T13:42:00Z The RESTCONF draft does not show an example of input or output parameters for actions, but I think they are the same as for RPC. The RESTCONF invocation would be: POST /restconf/data/server-farm:server=3Dapache-1/reset { "server-farm:input" : { "reset-at" : "2014-07-29T13:42:00Z" } } > =E2=80=9D > > It looks {+restconf} stands for the RESTCONF API entry point > > ,I am wondering {+restconf} is different from =E2=80=9C/restconf=E2=80=9D= in the example. > Is =E2=80=9C/restconf=E2=80=9D an example of {+restconf}? > This is the convention used to indicate the entry point is not hard-wired. > > > 3=EF=BC=8E Section 5.1, 2nd paragraph > > Would it be great to use an example to explain how RESTCONF operation is > derived from the HTTP method and the request URI? E.g., you can reference > the example in the Appendix to explain this? > > Not sure what you mean. Operations are explained in sec. 4 > > 4. Section 5.1 said: > > =E2=80=9C > > //?# > > > > ^ ^ ^ ^ ^ > > | | | | | > > method entry resource query fragment > > > > M M O O I > > > > M=3Dmandatory, O=3Doptional, I=3Dignored > > > > replaced by client with real values > > > > =E2=80=9D > > It looks does not appear in the above URI structure, is the > part of the above conceptual fields? > No -- we will change this to indicate it is all the fields with angle-brackets > > > -Qin > Andy > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Netconf [mailto:netconf-bounces@ietf.org] = *=E4=BB=A3=E8=A1=A8 *Ersue, Mehmet > (Nokia - DE/Munich) > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2015=E5=B9=B412=E6=9C=8816=E6=97= =A5 5:17 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* netconf@ietf.org > *=E4=B8=BB=E9=A2=98:* [Netconf] FW: WG Last Call for draft-ietf-netconf-r= estconf-09, > draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 > > > > The deadline is for sure January 22, *2016* EOB PT. > > > > Mehmet > > > > *From:* Ersue, Mehmet (Nokia - DE/Munich) > *Sent:* Tuesday, December 15, 2015 9:59 PM > *To:* netconf@ietf.org > *Cc:* 'core@ietf.org' ; 'i2rs@ietf.org' ; ' > 6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch@ietf.org> > *Subject:* WG Last Call for draft-ietf-netconf-restconf-09, > draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03 > > > > Dear NETCONF WG, > > > > we hereby issue a WG Last Call for the drafts below: > > > > http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt > > http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt > > http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt > > > > Please review and send your comments to the NETCONF WG mailing list by > January 22, 2015 EOB PT. > > > > The drafts on RESTCONF, YANG patch and YANG library are planned to publis= h > as standard track documents. > > > > As RESTCONF is a major protocol we seek a detailed and thorough review > within NETCONF WG but also by the related WGs before publishing. > > Therefore the WGLC is planned to finalize on January 22th (covering the > holiday time in between) and APP, INT and RTG area ADs will be informed a= s > well as Core, I2RS, 6lo, and 6tisch WGs are invited to review. > > > > Please take your time to review the documents and send your comments to > the NETCONF maillist by the deadline. > > Please state on NETCONF maillist also explicitly, whether you have > read/reviewed and whether you support the publication. > > Furthermore please indicate if you plan to implement or have already > implementations for RESTCONF and its supplementary drafts. > > > > Thank you for your review and kind help getting RESTCONF specifications > stable. > > > > Best Regards, > > Mehmet and Mahesh > > > ------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c2368229ffa40528008c9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 23, 2015 at 9:52 PM, Qin Wu <bill.wu@huawei.com>= wrote:

I have reviewed draft-ietf-netc= onf-restconf-09 and I have the following quick editorial comments:

1.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Section 3.6<= /span>

In v-08, support for YANG 1.1 a= ction statement is added, but look at section 3.6, it is not clear to me ho= w rpc statement is used different from rpc statement? If there is some diff= erence, it will be great to clarify this in the section 3.6.

2.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Section 3.6 said:

=E2=80=9C<= /p>

=C2=A0=C2=A0 An RPC operation is invoked as:

=C2=A0

=C2=A0=C2=A0 POST {+restconf}/operations/<operation>



This text = in rfc6020bis-08 is the only explanation of the difference


=C2=A0 =C2=A0The difference between an action = and an rpc is that an action is tied
=C2=A0 =C2=A0to a node in th= e datastore, whereas an rpc is not.=C2=A0 When an action is
=C2= =A0 =C2=A0invoked, the node in the datastore is specified along with the na= me
=C2=A0 =C2=A0of the action and the input parameters.


As you can see on RESTCONF-09, pg 23, = the /restconf/data entry point
is used, not /restconf/operations<= /div>

=C2=A0 =C2=A0POST {+restconf}/data/<data-r= esource-identifier>/<operation>

=C2= =A0 =C2=A0POST /restconf/data/module-A:interfaces/reset-all

<= /div>
Note that this is inconsistent with the NETCONF/XML encoding,
which uses the <action> element:

=C2=A0 =C2=A0 =C2=A0<rpc message-id=3D"101"
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:ba= se:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0<action xmlns= =3D"urn:ietf:params:xml:ns:yang:1">
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0<server xmlns=3D"http://example.net/server-farm">
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>apache-1</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<reset>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<reset-at>2014-07-29T13:= 42:00Z</reset-at>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= </reset>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</server><= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</action>
=C2=A0 =C2= =A0 =C2=A0</rpc>


The RE= STCONF draft does not show an example of input or output parameters
for actions, but I think they are the same as for RPC.

The RESTCONF invocation would be:

=C2=A0 = =C2=A0POST /restconf/data/server-farm:server=3Dapache-1/reset
=C2=A0 =C2=A0{ "server-farm:input" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "reset-at" : "2014-07-29T13:42= :00Z"
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}
<= div>




<= div>
=C2=A0

=E2=80=9D<= /p>

It looks {+restconf} stands for= the R= ESTCONF API entry point

,I am wondering {+restconf} is = different from =E2=80=9C/restconf=E2=80=9D in the example. Is =E2=80=9C/res= tconf=E2=80=9D an example of {+restconf}?



This is the convention used to indicat= e the entry point is not hard-wired.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">

=C2=A0=

3=EF=BC=8E Section 5.1, = 2nd paragraph

Would it be great to use an example to explain how = RESTCONF operation is derived from the HTTP method and the request URI? E.g= ., you can reference the example in the Appendix to explain this?=

=C2=A0
Not sure what you mean.
Ope= rations are explained in sec. 4


=C2=A0

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 5.1 said:

=E2=80=9C

=C2=A0=C2=A0=C2=A0=C2=A0 <OP> /<restconf>/<path&g= t;?<query>#<fragment>

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0^=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ^

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 method=C2=A0 entry=C2=A0 re= source=C2=A0 query=C2=A0=C2=A0=C2=A0 fragment

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 M=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 M=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 O=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 I

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 M=3Dmandatory, O=3Doptional= , I=3Dignored

=C2=A0

=C2=A0=C2=A0=C2=A0 <text> replaced by client with real val= ues

=C2=A0=

=E2=80=9D

It looks <text> does not appear in the above = URI structure, is the <text> part of the above conceptual fields?



No -- we= will change this to indicate it is all the fields with angle-brackets


=C2=A0

<= u>

=C2=A0=

-Qin


Andy
=C2=A0

=

=E5=8F=91=E4=BB=B6=E4=BA=BA: Netconf [mailto:netconf-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Ersue, Mehmet (Nokia - DE/Munich)
=E5= =8F=91=E9=80=81=E6=97=B6=E9=97=B4:= 2015= =E5=B9=B412=E6=9C=8816=E6=97=A5 5:17
=E6=94=B6=E4=BB=B6=E4=BA=BA: netc= onf@ietf.org
=E4=B8=BB=E9=A2=98: [Netconf] FW: WG Last Call for draft-ietf-netconf-restconf-09, draf= t-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03<= u>

=C2=A0

The deadline is for sure Januar= y 22, 2016 EOB PT.

=C2=A0

Mehmet

=C2=A0

From: Ersue, Mehmet (Nokia - DE/Mu= nich)
Sent: Tuesday, December 15, 2015 9:59 PM
To: netconf@ie= tf.org
Cc: 'core@iet= f.org' <core@= ietf.org>; 'i= 2rs@ietf.org' <i2rs@ietf.org>; '6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch@ietf.org>
Subject: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf= -netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03=

=C2=A0

Dear NETCONF WG,<= /span>

=C2=A0

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

=C2=A0

http://tools.ietf.org= /html/draft-ietf-netconf-restconf-09.txt

http://tools.ietf.o= rg/html/draft-ietf-netconf-yang-patch-07.txt

http://tools.ietf= .org/html/draft-ietf-netconf-yang-library-03.txt

=C2=A0

Please review and send your com= ments to the NETCONF WG mailing list by January 22, 2015 EOB PT.

=C2=A0

The drafts on RESTCONF, YANG pa= tch and YANG library are planned to publish as standard track documents.=

=C2=A0

As RESTCONF is a major protocol= we seek a detailed and thorough review within NETCONF WG but also by the r= elated WGs before publishing.

Therefore the WGLC is planned t= o finalize on January 22th (covering the holiday time in between) and APP, = INT and RTG area ADs will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to review.

=C2=A0

Please take your time to review= the documents and send your comments to the NETCONF maillist by the deadli= ne.

Please state on NETCONF maillis= t also explicitly, whether you have read/reviewed and whether you support t= he publication.

Furthermore please indicate if = you plan to implement or have already implementations for RESTCONF and its supplementary drafts.

=C2=A0

Thank you for your review and k= ind help getting RESTCONF specifications stable.

=C2=A0

Best Regards,

Mehmet and Mahesh=

=C2=A0


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


--001a11c2368229ffa40528008c9d-- From nobody Mon Dec 28 22:02: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 A0D661A1AB1 for ; Mon, 28 Dec 2015 22:02:15 -0800 (PST) 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 YtHNr4vI_Q5S for ; Mon, 28 Dec 2015 22:02:14 -0800 (PST) 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 47DC41A1A9E for ; Mon, 28 Dec 2015 22:02:14 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id y184so207417907lfc.1 for ; Mon, 28 Dec 2015 22:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=BjE0iEM5bmynu6IK4r26HJc38MFiUTxO0pM+DB5in+c=; b=JPZcAye8EUVlybGFal+f6oEfiuVYJILvZD6ZYCAsKH76drWAGaLgl2X2C+Zn5M9by3 8x2QGEhfu9+B20pDRoRZNDZjDQef5G4w7skovFPmlipz2Yeq2vtdLYrreMUQ6NwiG19A caH+X0dghiciPLVgdd+GPVwCwOir1iqlOnedyR1bpwVocbUbQwn6bOROOhN5+BRX2oqz q/5pHHBf0Ks+vhcLtHzV+rOaeadZrxCGeBUb7gOZdveMJsqo+egOWbXqWL8frMMGKbOV Df1dc3FMRYE8FPTOsQ3soTjpVul0ua0H4fTx/Ej7kRfXF+z7FpMsJHYo36TZjZUuLFOJ pZ3w== 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=BjE0iEM5bmynu6IK4r26HJc38MFiUTxO0pM+DB5in+c=; b=MPU+8azid9BzMOZJ0AVDfY5XJea+knbqF/0vD/oTtZRO0gGRSA2X/s8xdIzgL3MHrC ezNccByrVWIYPd/D9uEQr1lNGmIhdOTi6xJ6i8iTyzr9YGt7osGoKa46bebpvfvxaGsQ GmUfmbiGmTGxPUHW8IWOJ+6PT04nBsRjw93E2LfKaoBzi+14LoTm71JZpcSL7HfsU2b6 zYJH5MMZcQCTAh1CAF+ruY5r35mmgNRNdJJVX6zEr/S3MnfahtTq3wHjq7JunTyZDGKk cXNk+nypVPEkgUVM8SA930dLIG8obKiM+9t36dnTMAdclt+O9matsMurp9ylwZE854Gn v83Q== X-Gm-Message-State: ALoCoQl0d3Q99JEe+XNhNrWg/TmMcJy6USDf07BiY3pinrU8BXCFl5hc4uIYVATFhXHNE04j9y/bbUbKseeCx2vE0Jmwa7M0AQ== MIME-Version: 1.0 X-Received: by 10.25.82.144 with SMTP id g138mr21917255lfb.8.1451368932321; Mon, 28 Dec 2015 22:02:12 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 28 Dec 2015 22:02:12 -0800 (PST) Date: Mon, 28 Dec 2015 22:02:12 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a1141da8ea6473f05280329eb Archived-At: Subject: [Netconf] RESTCONF and confirmed-commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 29 Dec 2015 06:02:15 -0000 --001a1141da8ea6473f05280329eb Content-Type: text/plain; charset=UTF-8 Hi, Sec. 1.3 in RESTCONF-09 does not mention confirmed-commit at all. I just finished implementing confirmed-commit for RESTCONF and some details should be mentioned in this section. 1) persist-id A normal NETCONF commit will fail if a confirmed-commit is running with a 'persist-id' lock, and the session does not provide the correct value. Since standard RESTCONF has no way of passing a 'persist-id' parameter to the edit or commit, any RESTCONF edit must fail if this parameter is expected by the server. If no 'persist-id' is expected, then the RESTCONF edit will be processed by the server, and it will act as the confirming commit. 2) shared candidate This section does not mention that any edits in the candidate at the time of the RESTCONF edit will also be part of the commit. I propose that new text be added to sec. 1.3 similar to the text above. Andy --001a1141da8ea6473f05280329eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Sec. 1.3 in RESTCONF-09 does not me= ntion confirmed-commit at all.
I just finished implementing confi= rmed-commit for RESTCONF
and some details should be mentioned in = this section.

1) persist-id

A normal NETCONF commit will fail if a confirmed-commit is running
=
with a 'persist-id' lock, and the session does not provide the= correct value.
Since standard RESTCONF has no way of passing a &= #39;persist-id'
parameter to the edit or commit, any RESTCONF= edit must fail
if this parameter is expected by the server.

If no 'persist-id' is expected, then the RESTC= ONF edit will
be processed by the server, and it will act as the = confirming commit.

2) shared candidate
<= br>
This section does not mention that any edits in the candidate= at
the time of the RESTCONF edit will also be part of the commit= .


I propose that new text be added = to sec. 1.3 similar to the text above.


<= div>Andy


--001a1141da8ea6473f05280329eb-- From nobody Tue Dec 29 01:52: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 C6F001A6FA7 for ; Tue, 29 Dec 2015 01:52:22 -0800 (PST) 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 EQGxaUChUpAJ for ; Tue, 29 Dec 2015 01:52:21 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B094A1A6FA9 for ; Tue, 29 Dec 2015 01:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5527; q=dns/txt; s=iport; t=1451382740; x=1452592340; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=PkQNAroBuxw4b0Z0DAO5tFEJ3o0PX75C0irmmleC0KA=; b=M1H5Dk/wiNx6Zn060ghkGrDL1EiT8vSiUO34HeFkS7Sl6eSxuXu8PMb+ Azv3b4rSHAPBzQnCBy+YwGxAd2mByMryJ2ei8pLBdgGc7zk74ja33id0i CjUkweYcssIVHKFMW3wiMSitL9dDdOmEc+Oj6jRB8XVcTceyvxiIByYri I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQBWV4JW/xbLJq1EGoQMbYhZtGsBD?= =?us-ascii?q?YFkJIVrAoFWFAEBAQEBAQGBCoQ0AQEBBHgRHAMBAgoWDwkDAgECAQ8sAggGDQY?= =?us-ascii?q?CAQGIFgMSDju5FA2DMAEBAQEBAQEBAQEBAQEBAQEBAQEahlaEf4JPghMVDIQ5B?= =?us-ascii?q?ZMKg3yFQIVWQ4F4gVwWNIN8gwWFVIZhg2aDcyABAUKCERwdgUE9NAGFBQEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,494,1444694400"; d="scan'208,217";a="643813292" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Dec 2015 09:52:16 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBT9qG4N023812 for ; Tue, 29 Dec 2015 09:52:16 GMT References: <20151229044801.E817F180014@rfc-editor.org> To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: <20151229044801.E817F180014@rfc-editor.org> Message-ID: <568257D0.9030709@cisco.com> Date: Tue, 29 Dec 2015 10:52:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20151229044801.E817F180014@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------000005060201020804070206" Archived-At: Subject: [Netconf] Fwd: [RFC State] has been added to the RFC Editor database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 29 Dec 2015 09:52:22 -0000 This is a multi-part message in MIME format. --------------000005060201020804070206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit FYI. Thanks to everybody involved. Regards, Benoit. -------- Forwarded Message -------- Subject: [RFC State] has been added to the RFC Editor database Date: Mon, 28 Dec 2015 20:48:01 -0800 From: rfc-editor@rfc-editor.org To: kwatsen@juniper.net CC: netconf-ads@ietf.org, netconf-chairs@ietf.org, rfc-editor@rfc-editor.org, mjethanandani@gmail.com Author(s), We have received notice that your document draft-ietf-netconf-call-home-17 has been approved for publication as an RFC. The document has been added to the RFC Editor queue and you can check the status at If you submitted your XML file using the I-D submission tool, we have already retrieved it. If you did not submit the XML file via the I-D submission tool, or if you have an updated version (e.g., updated contact information), please send us the XML file at this time. Please attach the file as draft-ietf-netconf-call-home-17.xml, and specify any differences between the approved I-D and the document that the XML produces. We recommend using xml2rfc v2 to create your document. See the RSE's message about the RFC Editor's transition to xml2rfc v2 here . If you created this document using -ms nroff, please send us the source file. This should help increase the pace with which documents move through the RFC Editor queue. Please let us know if you have any questions. Thank you. The RFC Editor Team . --------------000005060201020804070206 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit FYI.
Thanks to everybody involved.

Regards, Benoit.


-------- Forwarded Message --------
Subject: [RFC State] <draft-ietf-netconf-call-home-17> has been added to the RFC Editor database
Date: Mon, 28 Dec 2015 20:48:01 -0800
From: rfc-editor@rfc-editor.org
To: kwatsen@juniper.net
CC: netconf-ads@ietf.org, netconf-chairs@ietf.org, rfc-editor@rfc-editor.org, mjethanandani@gmail.com 


Author(s),

We have received notice that your document draft-ietf-netconf-call-home-17 has
been approved for publication as an RFC.  The document has
been added to the RFC Editor queue and you can check the status at
<https://www.rfc-editor.org/current_queue.php>

If you submitted your XML file using the I-D submission tool, we have
already retrieved it.  If you did not submit the XML file via the I-D
submission tool, or if you have an updated version (e.g., updated
contact information), please send us the XML file at this time.  Please
attach the file as draft-ietf-netconf-call-home-17.xml, and specify 
any differences between the approved I-D and the document that the XML
produces.  We recommend using xml2rfc v2 <http://xml2rfc.ietf.org/> to create
your document.  See the RSE's message about the RFC Editor's transition to
xml2rfc v2 here 
<https://www.rfc-editor.org/pipermail/rfc-interest/2013-December/005835.html>.

If you created this document using -ms nroff, please send us the
source file.

This should help increase the pace with which documents move through
the RFC Editor queue. 

Please let us know if you have any questions.

Thank you.

The RFC Editor Team

.


--------------000005060201020804070206-- From nobody Thu Dec 31 06:06: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 70FE91A88C2 for ; Thu, 31 Dec 2015 06:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wGeNkgzrtuh for ; Thu, 31 Dec 2015 06:06:22 -0800 (PST) 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 1B7C11A88B9 for ; Thu, 31 Dec 2015 06:06:21 -0800 (PST) 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 tBVE6HNN019694 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Dec 2015 14:06:17 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id tBVE6G1f025387 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Dec 2015 15:06:17 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.48]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0248.002; Thu, 31 Dec 2015 15:06:16 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: EXT Benoit Claise , NETCONF Thread-Topic: [Netconf] Fwd: [RFC State] has been added to the RFC Editor database Thread-Index: AQHRQfQvWbEEIuQFLEyJ0nMPvh/7557hqIYAgAN0t6A= Date: Thu, 31 Dec 2015 14:06:16 +0000 Message-ID: References: <20151229044801.E817F180014@rfc-editor.org> <568257D0.9030709@cisco.com> In-Reply-To: <568257D0.9030709@cisco.com> 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_E4DE949E6CE3E34993A2FF8AE79131F819877237DEMUMBX005nsnin_" 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: 12047 X-purgate-ID: 151667::1451570777-000011B4-4EF9CA5F/0/0 Archived-At: Subject: Re: [Netconf] Fwd: [RFC State] has been added to the RFC Editor database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.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, 31 Dec 2015 14:06:27 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819877237DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Congratulations to NETCONF WG for this achievement. Many Thanks to All who commented and contributed for getting the Call-Home = draft stable and published. A Happy and Prosperous New Year to All!!! Mehmet & Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of EXT Benoit Cla= ise Sent: Tuesday, December 29, 2015 10:52 AM To: NETCONF Subject: [Netconf] Fwd: [RFC State] has b= een added to the RFC Editor database FYI. Thanks to everybody involved. Regards, Benoit. -------- Forwarded Message -------- Subject: [RFC State] has been added to the RFC Edi= tor database Date: Mon, 28 Dec 2015 20:48:01 -0800 From: rfc-editor@rfc-editor.org To: kwatsen@juniper.net CC: netconf-ads@ietf.org, netconf-chairs@ietf.org<= mailto:netconf-chairs@ietf.org>, rfc-editor@rfc-editor.org, mjethanandani@gmail.com Author(s), We have received notice that your document draft-ietf-netconf-call-home-17 = has been approved for publication as an RFC. The document has been added to the RFC Editor queue and you can check the status at If you submitted your XML file using the I-D submission tool, we have already retrieved it. If you did not submit the XML file via the I-D submission tool, or if you have an updated version (e.g., updated contact information), please send us the XML file at this time. Please attach the file as draft-ietf-netconf-call-home-17.xml, and specify any differences between the approved I-D and the document that the XML produces. We recommend using xml2rfc v2 to create your document. See the RSE's message about the RFC Editor's transition to xml2rfc v2 here . If you created this document using -ms nroff, please send us the source file. This should help increase the pace with which documents move through the RFC Editor queue. Please let us know if you have any questions. Thank you. The RFC Editor Team . --_000_E4DE949E6CE3E34993A2FF8AE79131F819877237DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Congratulations to NETCONF WG for thi= s achievement.

 

Many Thanks to All who commented and = contributed for getting the Call-Home draft stable and published.

 

A Happy and Prosperous New Year to= All!!!

 

Mehmet & Mahesh<= /o:p>

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of EXT Benoit Claise
Sent: Tuesday, December 29, 2015 10:52 AM
To: NETCONF <netconf@ietf.org>
Subject: [Netconf] Fwd: [RFC State] <draft-ietf-netconf-call-home= -17> has been added to the RFC Editor database

 

FYI.
Thanks to everybody involved.

Regards, Benoit.



-------- Forwarded Message --------

Subjec= t:

[RFC State] <draft-ietf-netconf-call-home-17> = has been added to the RFC Editor database

Date: =

Mon, 28 Dec 2015 20:48:01 -0800

From: =

rfc-edi= tor@rfc-editor.org

To:

kwatsen@junip= er.net

CC:

netconf-ads@= ietf.org, netconf-chairs@ietf.org, rfc-editor@rfc-editor.org, m= jethanandani@gmail.com

 

Author(s),
 
We have received notice that your document draft-ietf-netconf-call-hom=
e-17 has
been approved for publication as an RFC.  The document has
been added to the RFC Editor queue and you can check the status at
<https://w=
ww.rfc-editor.org/current_queue.php>
 
If you submitted your XML file using the I-D submission tool, we have<=
o:p>
already retrieved it.  If you did not submit the XML file via the=
 I-D
submission tool, or if you have an updated version (e.g., updated=

contact information), please send us the XML file at this time.  =
Please
attach the file as draft-ietf-netconf-call-home-17.xml, and specify 
any differences between the approved I-D and the document that the XML=

produces.  We recommend using xml2rfc v2 <http://xml2rfc.ietf.org/> to create

your document.  See the RSE's message about the RFC Editor's tran=
sition to


xml2rfc v2 here 


<https://www.rfc-editor.org/pipermail/rfc-interest/201=
3-December/005835.html>.


 


If you created this document using -ms nroff, please send us the<=
/o:p>


source file.


 


This should help increase the pace with which documents move through


the RFC Editor queue. 


 


Please let us know if you have any questions.


 


Thank you.


 


The RFC Editor Team


 


.


 


 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819877237DEMUMBX005nsnin_--