Re: [lmap] draft-ietf-lmap-restconf status and way forward
"Carey, Timothy (Nokia - US)" <timothy.carey@nokia.com> Fri, 09 June 2017 19:50 UTC
Return-Path: <timothy.carey@nokia.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0AF128D3E for <lmap@ietfa.amsl.com>; Fri, 9 Jun 2017 12:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaKaRjIEfo2I for <lmap@ietfa.amsl.com>; Fri, 9 Jun 2017 12:50:45 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10138.outbound.protection.outlook.com [40.107.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D645C1200CF for <lmap@ietf.org>; Fri, 9 Jun 2017 12:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eCwqwfVaFDu83iwD9C5MTtNv19OtisFSxMqT0ROV8BI=; b=EPmr/mpsleddKkg5cqdgeSqbrYgGfTZTejOnWdDR3W4JrXmKVCFEl8dZnQ5mNOhjCWZviR5Q85EHDCCLqoiEaSQcZpL9aqJ7VsXdVG0L16q65NXEf3vCjM3axvv0itwoAAJpRd5Wdy8at6sPMK+dj3jp8eyNSF9ZxswA3TEoI78=
Received: from AM5PR0701MB2644.eurprd07.prod.outlook.com (10.173.92.151) by AM5PR0701MB2659.eurprd07.prod.outlook.com (10.173.93.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.6; Fri, 9 Jun 2017 19:50:42 +0000
Received: from AM5PR0701MB2644.eurprd07.prod.outlook.com ([fe80::3c71:9e3f:be9a:feec]) by AM5PR0701MB2644.eurprd07.prod.outlook.com ([fe80::3c71:9e3f:be9a:feec%17]) with mapi id 15.01.1157.010; Fri, 9 Jun 2017 19:50:42 +0000
From: "Carey, Timothy (Nokia - US)" <timothy.carey@nokia.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "lmap@ietf.org" <lmap@ietf.org>
Thread-Topic: [lmap] draft-ietf-lmap-restconf status and way forward
Thread-Index: AQHS29KS/dcqZWw59EWIDd5fNwEo/aIc8Lig
Date: Fri, 09 Jun 2017 19:50:42 +0000
Message-ID: <AM5PR0701MB2644F8C2534577F043E0FBF8EFCE0@AM5PR0701MB2644.eurprd07.prod.outlook.com>
References: <20170602101340.GA93882@elstar.local>
In-Reply-To: <20170602101340.GA93882@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [135.245.20.28]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2659; 7:ZWcCNNlwcMTNVik3TRt06rzxW+e8YlLB2sWpOejh0IXC9ykHOcreLn99OqCYkBUj/v8X71Dmq1zrxJSZML1ZIhsqNfaXtXe/4mu04UsFzsP8vmPsoUj7ArYbM+jSaxpQT3dUkmmbf0ejhO68VCkmrAQZV5On6RLimyLJtdjtsI8biKkla5ErNdyRdVu5Fn1L4OgEp0to3o4it4X9EQIchyEdTJXCOqtzq/LVUIOUg1y6UJzUGmx9i/AxLtMqthqsrdT6HOEJtRzRAbOykJAVTTiojvZIQUnuslmv6NmrogNvFif3AsoZSQWq+1Z7r9f5KR8yi3cMgriT6dqxmv++1Q==
x-ms-traffictypediagnostic: AM5PR0701MB2659:
x-ms-office365-filtering-correlation-id: 4dbc9012-2aab-45b8-26d3-08d4af70cfed
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2659;
x-microsoft-antispam-prvs: <AM5PR0701MB2659ACFF681FAF371A2FD1E5EFCE0@AM5PR0701MB2659.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2659; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2659;
x-forefront-prvs: 03333C607F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(39400400002)(377454003)(13464003)(478600001)(229853002)(25786009)(86362001)(74316002)(305945005)(7736002)(8676002)(3280700002)(230783001)(8936002)(14454004)(2950100002)(2501003)(7696004)(3660700001)(102836003)(3846002)(50986999)(6436002)(33656002)(6306002)(5250100002)(81166006)(9686003)(53546009)(99286003)(76176999)(54356999)(189998001)(2900100001)(5660300001)(55016002)(66066001)(6506006)(6246003)(38730400002)(53936002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2659; H:AM5PR0701MB2644.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2017 19:50:42.5237 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2659
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/7QGwhf_AE3KsHxDEo4g4-MNP8eI>
Subject: Re: [lmap] draft-ietf-lmap-restconf status and way forward
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jun 2017 19:50:48 -0000
Juergen, I finally got around to reading the restconf draft (rev-04) In section 4 (RESTCONF as LMAP Report Protocol) - I think you still have some spurious text (would Call Home be relevant between the MA and the Collector) and incorrect use of Controller (should have been Collector) Figure 3 depicts how the connection and the secure transport is established and how reports are delivered to the Controller. Note that it is generally assumed that the Controller is directly reachable from the Measurement Agent. (In situations where this may not be true, RESTCONF Call Home can be used as well but this is not shown here.) If you were trying to say that when the MA issues reports for any reason to the Controller then the above would be correct but I would clearly separate the two scenarios. Other than that I am fine with how you describe the Call Home. As to the others - Yes informational would be better than standards as there isn't any normative language; In section 5 Unless there is specific configuration needs for the MA, Controller or Collector (maybe defining the ports or authentication requirements (e.g., client authentication) as it relates to the RESTCONF client/server interaction that you might want mandate (if so then it should go to standards track BTW). In the TR-069 we specifically called these out so that any Device would know the ports to implement and how a TR-069 agent is identified for authentication as well as what is mandated. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Friday, June 02, 2017 5:14 AM To: lmap@ietf.org Subject: [lmap] draft-ietf-lmap-restconf status and way forward Hi, I have posted a new version of draft-ietf-lmap-restconf. I have tried to address the Dan Romascanu's review comments and I tried to better align the text with the other specifications. There are a couple of open issues where I would like to have guidance from the WG or the chairs. a) The document header says Standards Track but since this document does not really define anything but merely explains how the various pieces fit together, I think the document should be Informational. b) I added some figures to explain how connection establishment works with RESTCONF with and without Call Home. I think Tim wanted to have this better explained. It would be nice to receive feedback whether the figures address the comment. c) There are two examples in the appendix. I still need to update them to align them with the final version of the data model and to move to JSON encoding. (We once decided that the YANG model shows XML encoded examples while the RESTCONF document shows JSON encoded examples.) If the document becomes Informational, I think it is better to move the examples inline instead of having them in an appendix. d) I do not know what to do about section 5. Do we have to discuss in this document how RESTCONF configuration is done? My preference is to not go there since (a) the relevant specifications are still being worked on in NETCONF - so we have to wait on these specifications getting stable and (b) there may be several different ways to configure certain features and I do not know how to select what we should document here and I see also a certain risk of ending up with something that is inconsistent with the actual specifications. My preference would be to simply point to the work-in-progress documents. If the answer to a) is Informational, to b) Tim's request has been addressed, to d) we do not go into the details of RESTCONF configuration, than I can do c) relatively quickly and we may even move this document to WG last call before IETF 99. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
- [lmap] draft-ietf-lmap-restconf status and way fo… Juergen Schoenwaelder
- Re: [lmap] draft-ietf-lmap-restconf status and wa… Carey, Timothy (Nokia - US)
- Re: [lmap] draft-ietf-lmap-restconf status and wa… Juergen Schoenwaelder
- Re: [lmap] draft-ietf-lmap-restconf status and wa… Benoit Claise