From nobody Fri Jun 2 02:55:09 2017 Return-Path: X-Original-To: lmap@ietf.org Delivered-To: lmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 676131294E9; Fri, 2 Jun 2017 02:54:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149639729937.31859.4492783694826686244@ietfa.amsl.com> Date: Fri, 02 Jun 2017 02:54:59 -0700 Archived-At: Subject: [lmap] I-D Action: draft-ietf-lmap-restconf-04.txt X-BeenThere: lmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: Large Scale Measurement of Access network Performance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 09:54:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Large-Scale Measurement of Broadband Performance of the IETF. Title : Using RESTCONF with LMAP Measurement Agents Authors : Juergen Schoenwaelder Vaibhav Bajpai Filename : draft-ietf-lmap-restconf-04.txt Pages : 11 Date : 2017-06-02 Abstract: This document describes how RESTCONF can be used with a YANG data model for Large-Scale Measurement Platforms (LMAP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lmap-restconf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lmap-restconf-04 https://datatracker.ietf.org/doc/html/draft-ietf-lmap-restconf-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lmap-restconf-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 2 03:13:46 2017 Return-Path: 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 74893126DED for ; Fri, 2 Jun 2017 03:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 BGWXVKMeKqd8 for ; Fri, 2 Jun 2017 03:13:43 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5EB12E05C for ; Fri, 2 Jun 2017 03:13:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B00B7F6A for ; Fri, 2 Jun 2017 12:13:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wsIZUu3zAy3O for ; Fri, 2 Jun 2017 12:13:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 2 Jun 2017 12:13:41 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95F5F200A6 for ; Fri, 2 Jun 2017 12:13:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id naqqdmQvVu4w; Fri, 2 Jun 2017 12:13:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B5BE200AB; Fri, 2 Jun 2017 12:13:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D32D13F684DD; Fri, 2 Jun 2017 12:13:40 +0200 (CEST) Date: Fri, 2 Jun 2017 12:13:40 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20170602101340.GA93882@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 10:13:45 -0000 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 From nobody Fri Jun 9 12:50:48 2017 Return-Path: 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 ; 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 ; 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 ; 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)" To: Juergen Schoenwaelder , "lmap@ietf.org" Thread-Topic: [lmap] draft-ietf-lmap-restconf status and way forward Thread-Index: AQHS29KS/dcqZWw59EWIDd5fNwEo/aIc8Lig Date: Fri, 9 Jun 2017 19:50:42 +0000 Message-ID: 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 so= me spurious text (would Call Home be relevant between the MA and the Collec= tor) 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 separat= e the two scenarios. Other than that I am fine with how you describe the Call Home. As to the others -=20 Yes informational would be better than standards as there isn't any normati= ve language;=20 In section 5 Unless there is specific configuration needs for the MA, Contr= oller 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 standar= ds track BTW). In the TR-069 we specifically called these out so that any Device would kno= w the ports to implement and how a TR-069 agent is identified for authentic= ation as well as what is mandated. BR, Tim -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 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 ad= dress the Dan Romascanu's review comments and I tried to better align the t= ext 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 addresse= d, to d) we do not go into the details of RESTCONF configuration, than I ca= n do c) relatively quickly and we may even move this document to WG last ca= ll before IETF 99. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jun 9 13:15:02 2017 Return-Path: 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 5403B128D3E for ; Fri, 9 Jun 2017 13:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 utcL_ZIPSGNN for ; Fri, 9 Jun 2017 13:14:58 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61093128DE7 for ; Fri, 9 Jun 2017 13:14:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 96408317; Fri, 9 Jun 2017 22:14:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Byaf3ZsFZ9gz; Fri, 9 Jun 2017 22:14:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Jun 2017 22:14:56 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7373F20090; Fri, 9 Jun 2017 22:14:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DsEVpXEYjIZK; Fri, 9 Jun 2017 22:14:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 023902008D; Fri, 9 Jun 2017 22:14:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 996303FB9020; Fri, 9 Jun 2017 22:14:55 +0200 (CEST) Date: Fri, 9 Jun 2017 22:14:55 +0200 From: Juergen Schoenwaelder To: "Carey, Timothy (Nokia - US)" Cc: "lmap@ietf.org" Message-ID: <20170609201454.GA49378@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20170602101340.GA93882@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 20:15:01 -0000 On Fri, Jun 09, 2017 at 07:50:42PM +0000, Carey, Timothy (Nokia - US) wrote: > 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. > Oops, this is a typing error, this will be fixed in -05. > Other than that I am fine with how you describe the Call Home. Good. > As to the others - > > Yes informational would be better than standards as there isn't any normative language; I will change -05 to say Informational unless the chairs tell me otherwise. > 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. The ports are defined in the RESTCONF and RESTCONF call home specifications. The data model of the authentication configuration details is still worked on in NETCONF. It could be that the NETCONF work does not detail all aspects of the client side interface but its work in progress so we will only know details in a couple of months (the new charter says August 2017 but this is an IETF milestone). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 26 23:55:47 2017 Return-Path: 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 3B34212EB77 for ; Mon, 26 Jun 2017 23:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Nap8a8uXLbTq for ; Mon, 26 Jun 2017 23:55:44 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD52124BFA for ; Mon, 26 Jun 2017 23:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2524; q=dns/txt; s=iport; t=1498546544; x=1499756144; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=xY+UXmhj0NH6Il/heCkTKZiTg/w9Yw+8bogwUkWBiz0=; b=HrCmZRu2Kah1soDG59QWo2eB+bAMv8ql6JrHtZ++FQ/x52FOw0xEWnc0 VdkoPvSmuZrF/L6CMLs2v3PkJDnTYSNfoGEKeCAUthrY71AJYrBIXetAH Dcru+h0XR6XaQc/1mLktT1r190/Tv9Mzny4uAwl1q1gVW+E5go2+hnlnx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAADCAFJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyuGCIoZc5BNIpV8ghGGJAKDMBgBAgEBAQEBAQFrKIUZAQUjDwE?= =?us-ascii?q?FUQsYAgImAgJXBgEMCAEBiiyvWYImi1sBAQEBAQEBAwEBAQEBASKBC4Icg0yBY?= =?us-ascii?q?SsLgm6EVIMpgmEBBJ5vk2qLHoZ2jFWITx84gQowIQgbFYdePolSAQEB?= X-IronPort-AV: E=Sophos;i="5.39,399,1493683200"; d="scan'208";a="652860164" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 06:55:42 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5R6tgx9001525; Tue, 27 Jun 2017 06:55:42 GMT To: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: <20170602101340.GA93882@elstar.local> <20170609201454.GA49378@elstar.local> From: Benoit Claise Message-ID: Date: Tue, 27 Jun 2017 08:55:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20170609201454.GA49378@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 06:55:46 -0000 On 6/9/2017 10:14 PM, Juergen Schoenwaelder wrote: > On Fri, Jun 09, 2017 at 07:50:42PM +0000, Carey, Timothy (Nokia - US) wrote: >> 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. >> > Oops, this is a typing error, this will be fixed in -05. > >> Other than that I am fine with how you describe the Call Home. > Good. > >> As to the others - >> >> Yes informational would be better than standards as there isn't any normative language; > I will change -05 to say Informational unless the chairs tell me > otherwise. Changing to Informational makes sense IMO. And I agree with Jürgen' statement. If the document becomes Informational, I think it is better to move the examples inline instead of having them in an appendix. Regards, Benoit > >> 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. > The ports are defined in the RESTCONF and RESTCONF call home > specifications. The data model of the authentication configuration > details is still worked on in NETCONF. It could be that the NETCONF > work does not detail all aspects of the client side interface but its > work in progress so we will only know details in a couple of months > (the new charter says August 2017 but this is an IETF milestone). > > /js > From nobody Tue Jun 27 02:23:26 2017 Return-Path: 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 3CFC1129413 for ; Tue, 27 Jun 2017 02:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9Xt4UdrX2FlM for ; Tue, 27 Jun 2017 02:23:21 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E9E1293E1 for ; Tue, 27 Jun 2017 02:23:21 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id 16so20365246qkg.2 for ; Tue, 27 Jun 2017 02:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Vvk5olDauxq1FTLApTwcRzRz1QcBlFNXW5wuvEkB90Y=; b=czlhCakSEkjLPu7vPAs5FSyPIWefw4F5UNUCzkiW5U4zJ7hYPX+pZOXnpjLsdHNfNb Dhmq72+v1Im4cf8VHh2/e6tG9cos5DaAvGgyBAZ1muQGJzxR3d6RbLQAoVPa5KNNbAzD TK+RyUXfozIyxaHj4LpaQUdrsjPUm8hglTvYdqzQKufZPS+nzLAnz5itRKxjv+QvWQJD z2OYEiX6A/Gb7u20UcT9PDT0fjkANifAKuMXVy2kpJXnxCB5eJtYbV40CGhTgthTOeLD Ksz16J+z0MSRHEud0FCHqY9ShsxLntnG1hgIldOHuJahAJdhOIpkw/P60/+0P3j+suV0 +qBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Vvk5olDauxq1FTLApTwcRzRz1QcBlFNXW5wuvEkB90Y=; b=jXQPJ09nO3ebJ67Obm0lGL+MRQpyiiW8fcuAtkXEzoCs9zD8W8YqSUe1zaB0iuFkzY teaaWlUiQlL48SJyglad39tFGMOjfH7ElGuhgyohP2bHk0JSdZkHBCkHsCCGpzyONq2M yTzdBBCnczHCsE0Xr5k50WeYM75e7sZU169PomZn1HPhFyPvPsrSUorebZPT7wvktO4P V+MdfdyRs8ylIRGc2bW59huAikpCi8tLWw0knA+DxT5cqBGn95UUF00WzDANfqOR6uQf ML2sTMFW1DJrRxuZJdbW9vXST72i5DqvRXGEPnszMtI3XteNssnWP5lip45Mi6RP5N9d Rh/w== X-Gm-Message-State: AKS2vOyC7P/sS7/ST+1Qh7RqyZ5P1XWdPx2LFrsDZy2J5jvBqfxKoaWw dCX1YicY8NlDiUs306ae5uLdmJ8JBw== X-Received: by 10.55.110.195 with SMTP id j186mr5486000qkc.92.1498555400402; Tue, 27 Jun 2017 02:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.67 with HTTP; Tue, 27 Jun 2017 02:23:19 -0700 (PDT) From: Dan Romascanu Date: Tue, 27 Jun 2017 12:23:19 +0300 Message-ID: To: Benoit Claise Cc: "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" , Dan Romascanu Content-Type: multipart/alternative; boundary="94eb2c05c282513cef0552ed9ea4" Archived-At: Subject: [lmap] changing draft-ietf-lmap-restconf to Informational (was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 09:23:24 -0000 --94eb2c05c282513cef0552ed9ea4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I believe that the change of draft-ietf-lmap-restconf from Standards Track to Informational deserves more attention and discussion. As WG chair I would like to remind that the WG is chartered to deliver 'The Control protocol and the associated data model' and 'The Report protocol and the associated data model', and that these two items were marked 'Standards Track' since the WG was chartered. For these purpose we ran a protocol evaluation, compared the existing solutions and decided that RESTCONF and YANG are the most appropriate solution for both the control and the report protocol. Changing now the intended status would mean that there will be no full standards-track solution for the control protocol and for the report protocol. The P in LMAP stands for Protocol. Maybe the YANG data models are sufficient, but I would like to make sure that the significance of this change is understood by all WG participants, and by the potential users in the operators space, the BBF and IEEE 802.16, and other organizations that expressed interest in LMAP. So, please, express your opinions. Maybe a formal consensus call in the WG and communication with the BBF and IEEE 802.16 is needed. Regards, Dan On Tue, Jun 27, 2017 at 9:55 AM, Benoit Claise wrote: > On 6/9/2017 10:14 PM, Juergen Schoenwaelder wrote: > >> On Fri, Jun 09, 2017 at 07:50:42PM +0000, Carey, Timothy (Nokia - US) >> wrote: >> >>> Juergen, >>> >>> I finally got around to reading the restconf draft (rev-04) >>> >>> In section 4 (RESTCONF as LMAP Report Protocol) - I think you still hav= e >>> 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 reaso= n >>> to the Controller then the above would be correct but I would clearly >>> separate the two scenarios. >>> >>> Oops, this is a typing error, this will be fixed in -05. >> >> >>> Other than that I am fine with how you describe the Call Home. >>> >> Good. >> >> >>> As to the others - >>> >>> Yes informational would be better than standards as there isn't any >>> normative language; >>> >> I will change -05 to say Informational unless the chairs tell me >> otherwise. >> > Changing to Informational makes sense IMO. > > And I agree with J=C3=BCrgen' statement. > > If the document becomes Informational, I think it is > better to move the examples inline instead of having them in an > appendix. > > > Regards, Benoit > >> >> 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 RESTCON= F >>> client/server interaction that you might want mandate (if so then it sh= ould >>> 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. >>> >> The ports are defined in the RESTCONF and RESTCONF call home >> specifications. The data model of the authentication configuration >> details is still worked on in NETCONF. It could be that the NETCONF >> work does not detail all aspects of the client side interface but its >> work in progress so we will only know details in a couple of months >> (the new charter says August 2017 but this is an IETF milestone). >> >> /js >> >> > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > --94eb2c05c282513cef0552ed9ea4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I beli= eve that the change of draft-ietf-lmap-restconf from Standards Track to Inf= ormational deserves more attention and discussion.

As W= G chair I would like to remind that the WG is chartered to deliver 'The= Control protocol and the associated data model' and 'The Report pr= otocol and the associated data model', and that these two items were ma= rked 'Standards Track' since the WG was chartered. For these purpos= e we ran a protocol evaluation, compared the existing solutions and decided= that RESTCONF and YANG are the most appropriate solution for both the cont= rol and the report protocol. Changing now the intended status would mean th= at there will be no full standards-track solution for the control protocol = and for the report protocol.

The P in LMAP stands for Protoco= l. Maybe the YANG data models are sufficient, but I would like to make sure= that the significance of this change is understood by all WG participants,= and by the potential users in the operators space, the BBF and IEEE 802.16= , and other organizations that expressed interest in LMAP.

So= , please, express your opinions. Maybe a formal consensus call in the WG an= d communication with the BBF and IEEE 802.16 is needed.

Regar= ds,

Dan


On Tue, Jun 27= , 2017 at 9:55 AM, Benoit Claise <bclaise@cisco.com> wrote:<= br>
On 6/9/2017 10:14 PM, = Juergen Schoenwaelder wrote:
On Fri, Jun 09, 2017 at 07:50:42PM +0000, Carey, Timothy (Nokia - US) wrote= :
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 so= me spurious text (would Call Home be relevant between the MA and the Collec= tor) 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 separat= e the two scenarios.

Oops, this is a typing error, this will be fixed in -05.
=C2=A0
Other than that I am fine with how you describe the Call Home.
Good.
=C2=A0
As to the others -

Yes informational would be better than standards as there isn't any nor= mative language;
I will change -05 to say Informational unless the chairs tell me
otherwise.
Changing to Informational makes sense IMO.

And I agree with J=C3=BCrgen' statement.

=C2=A0 =C2=A0If the document becomes Informational, I think it is
=C2=A0 =C2=A0better to move the examples inline instead of having them in a= n
=C2=A0 =C2=A0appendix.


Regards, Benoit

In section 5 Unless there is specific configuration needs for the MA, Contr= oller 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 standar= ds track BTW).
In the TR-069 we specifically called these out so that any Device would kno= w the ports to implement and how a TR-069 agent is identified for authentic= ation as well as what is mandated.
The ports are defined in the RESTCONF and RESTCONF call home
specifications. The data model of the authentication configuration
details is still worked on in NETCONF. It could be that the NETCONF
work does not detail all aspects of the client side interface but its
work in progress so we will only know details in a couple of months
(the new charter says August 2017 but this is an IETF milestone).

/js


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

--94eb2c05c282513cef0552ed9ea4-- From nobody Tue Jun 27 04:42:09 2017 Return-Path: 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 3B61A129AC4 for ; Tue, 27 Jun 2017 04:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 oSbzSlosUJ_t for ; Tue, 27 Jun 2017 04:41:59 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B124129ABE for ; Tue, 27 Jun 2017 04:41:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 09008E90; Tue, 27 Jun 2017 13:41:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id msamls8d0E_G; Tue, 27 Jun 2017 13:41:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 27 Jun 2017 13:41:57 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8F812009F; Tue, 27 Jun 2017 13:41:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SmpY6vOpbtOV; Tue, 27 Jun 2017 13:41:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CFFC2009B; Tue, 27 Jun 2017 13:41:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 82F503FD3E5D; Tue, 27 Jun 2017 13:41:52 +0200 (CEST) Date: Tue, 27 Jun 2017 13:41:52 +0200 From: Juergen Schoenwaelder To: Dan Romascanu Cc: Benoit Claise , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" Message-ID: <20170627114152.GA4350@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Dan Romascanu , Benoit Claise , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [lmap] changing draft-ietf-lmap-restconf to Informational (was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 11:42:02 -0000 On Tue, Jun 27, 2017 at 12:23:19PM +0300, Dan Romascanu wrote: > Hi, > > I believe that the change of draft-ietf-lmap-restconf from Standards Track > to Informational deserves more attention and discussion. > > As WG chair I would like to remind that the WG is chartered to deliver 'The > Control protocol and the associated data model' and 'The Report protocol > and the associated data model', and that these two items were marked > 'Standards Track' since the WG was chartered. For these purpose we ran a > protocol evaluation, compared the existing solutions and decided that > RESTCONF and YANG are the most appropriate solution for both the control > and the report protocol. Changing now the intended status would mean that > there will be no full standards-track solution for the control protocol and > for the report protocol. This is incorrect since there are two standards-track protocols that can be used with the standards-track LMAP data model. > The P in LMAP stands for Protocol. The charter says "Large-Scale Measurement of Broadband Performance (lmap)". > Maybe the YANG data models are > sufficient, but I would like to make sure that the significance of this > change is understood by all WG participants, and by the potential users in > the operators space, the BBF and IEEE 802.16, and other organizations that > expressed interest in LMAP. > > So, please, express your opinions. Maybe a formal consensus call in the WG > and communication with the BBF and IEEE 802.16 is needed. There is no normative standards-track content in the I-D (assuming client configuration will be done in NETCONF). I do not see what the alternatives are, creating a new protocol for the sake of having a protocol or labeling a document as a protocol definition even though there is nothing normative in the document? Well, if the chairs think a formal consensus call is needed, simply execute one. As document editor, I would appreciate more document content reviews. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 27 05:05:38 2017 Return-Path: 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 1BE00120454 for ; Tue, 27 Jun 2017 05:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EKnMGf3h6G8h for ; Tue, 27 Jun 2017 05:05:26 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 243DE129AD1 for ; Tue, 27 Jun 2017 05:05:25 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id i2so22273688qta.3 for ; Tue, 27 Jun 2017 05:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XVmZzCi2QezvJ7DOzI9wMnm+f7TMZjZD1AwLWonaVNg=; b=rudZYu1AcGtpz55UxsqOhjlFXdA5La7UDRnkvgYm8K8pe69f5FV8oYkHVZiaHfzJ9M JhV7cIR/TrRj3220fYbef30vbpOJgGZQX40HoJjuvkKEn8s455dGX1JPqParkG+VAjeq Cmmt3P+avKPLsGA8RzfClImS0CWAOpCf0J49jJh2WjvmveOxDBQ0I1gTuBdWZOqyzNlB t+mi5LEgkw8ncaeFdKQM28ZuILQj4vzXiAHVCGqs3tE75vXsRvrEDVFYQwEnBq/eRQSy n4gGnrqrs7gnyxu+SMa75PhW13Ygab/2tom920/5+JWxUBBPogqXbjOqF8H8NQserslS 5QOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XVmZzCi2QezvJ7DOzI9wMnm+f7TMZjZD1AwLWonaVNg=; b=K4HBZR2GKfLmZ85IBa5onV/uTXCniVkZ+7PDyUsGuFzXKak/Bn0VvlRyYDlpJbsgy7 YeuikIgvgVv/H0vMCYsYSUE2olSqYqdG2uAQdVYNbhBMy+jpS/y+/e7laQx3qMYIE3cX VLsc2/FMgknB3UXKyui4g5+4cLp2+O0jCNej/La2tlZ9w38ahJpc1vfxggRgaSaCWb9K MG8hwCHS4G1Tvb5KzfWWPImJgbiYQGdKzJnV8TvHFpPDsRhZXebCoFlLpyKmQ22UkQx5 xkr2YlizqoKq86WIXlVce6TZHP+KcZB/qbVbVHiNUQw7L151S9UrxNP9MX/Tc75kJHTp fxAw== X-Gm-Message-State: AKS2vOz8cRX0d10wgwH7yWU91jfzHqs96rPNrMeh2tcWIOEWJYD1bbcm 9UoZWqgSHwR5F9JcCoNuoxwqU3/ANA== X-Received: by 10.237.43.199 with SMTP id e65mr5816447qtd.19.1498565124258; Tue, 27 Jun 2017 05:05:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.108.67 with HTTP; Tue, 27 Jun 2017 05:05:23 -0700 (PDT) In-Reply-To: <20170627114152.GA4350@elstar.local> References: <20170627114152.GA4350@elstar.local> From: Dan Romascanu Date: Tue, 27 Jun 2017 15:05:23 +0300 Message-ID: To: Juergen Schoenwaelder , Dan Romascanu , Benoit Claise , "Carey, Timothy (Nokia - US)" , "lmap@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c070a32e77ed30552efe15d" Archived-At: Subject: Re: [lmap] changing draft-ietf-lmap-restconf to Informational (was: Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 12:05:37 -0000 --94eb2c070a32e77ed30552efe15d Content-Type: text/plain; charset="UTF-8" Hi, See in-line. Regards, Dan On Tue, Jun 27, 2017 at 2:41 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jun 27, 2017 at 12:23:19PM +0300, Dan Romascanu wrote: > > Hi, > > > > I believe that the change of draft-ietf-lmap-restconf from Standards > Track > > to Informational deserves more attention and discussion. > > > > As WG chair I would like to remind that the WG is chartered to deliver > 'The > > Control protocol and the associated data model' and 'The Report protocol > > and the associated data model', and that these two items were marked > > 'Standards Track' since the WG was chartered. For these purpose we ran a > > protocol evaluation, compared the existing solutions and decided that > > RESTCONF and YANG are the most appropriate solution for both the control > > and the report protocol. Changing now the intended status would mean that > > there will be no full standards-track solution for the control protocol > and > > for the report protocol. > > This is incorrect since there are two standards-track protocols that > can be used with the standards-track LMAP data model. > I am not sure whether two protocols is what was expected from the WG. Certainly not according to the charter. We need at least an applicability statement, IMO. > > > The P in LMAP stands for Protocol. > > The charter says "Large-Scale Measurement of Broadband Performance (lmap)". > I stand corrected. > > > Maybe the YANG data models are > > sufficient, but I would like to make sure that the significance of this > > change is understood by all WG participants, and by the potential users > in > > the operators space, the BBF and IEEE 802.16, and other organizations > that > > expressed interest in LMAP. > > > > So, please, express your opinions. Maybe a formal consensus call in the > WG > > and communication with the BBF and IEEE 802.16 is needed. > > There is no normative standards-track content in the I-D (assuming > client configuration will be done in NETCONF). I do not see what the > alternatives are, creating a new protocol for the sake of having a > protocol or labeling a document as a protocol definition even though > there is nothing normative in the document? Well, if the chairs think > a formal consensus call is needed, simply execute one. As document > editor, I would appreciate more document content reviews. ;-) > I believe that we need at least an applicability statement pointing to RESTCONF as the normative solution for LMAP. IMO this statement was implicit as long as draft-ietf-lmap-restconf is Standards Track. Making it Informational leads to the need to write something else, or change the scope in the charter. More document content reviews would certainly be welcome. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c070a32e77ed30552efe15d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

See in-line.

Regards,

Dan


On Tue, Jun 27, 2017 at 2:41 PM, Juer= gen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Tue, Jun 27, 2017 at 12:23:19PM +0300, Dan Romas= canu wrote:
> Hi,
>
> I believe that the change of draft-ietf-lmap-restconf from Standards T= rack
> to Informational deserves more attention and discussion.
>
> As WG chair I would like to remind that the WG is chartered to deliver= 'The
> Control protocol and the associated data model' and 'The Repor= t protocol
> and the associated data model', and that these two items were mark= ed
> 'Standards Track' since the WG was chartered. For these purpos= e we ran a
> protocol evaluation, compared the existing solutions and decided that<= br> > RESTCONF and YANG are the most appropriate solution for both the contr= ol
> and the report protocol. Changing now the intended status would mean t= hat
> there will be no full standards-track solution for the control protoco= l and
> for the report protocol.

This is incorrect since there are two standards-track protocols that=
can be used with the standards-track LMAP data model.
=
I am not sure whether two protocols is what was expected fro= m the WG. Certainly not according to the charter. We need at least an appli= cability statement, IMO.

=C2=A0

> The P in LMAP stands for Protocol.

The charter says "Large-Scale Measurement of Broadband Performa= nce (lmap)".

I stand corrected.
=C2=A0

> Maybe the YANG data models are
> sufficient, but I would like to make sure that the significance of thi= s
> change is understood by all WG participants, and by the potential user= s in
> the operators space, the BBF and IEEE 802.16, and other organizations = that
> expressed interest in LMAP.
>
> So, please, express your opinions. Maybe a formal consensus call in th= e WG
> and communication with the BBF and IEEE 802.16 is needed.

There is no normative standards-track content in the I-D (assuming client configuration will be done in NETCONF). I do not see what the
alternatives are, creating a new protocol for the sake of having a
protocol or labeling a document as a protocol definition even though
there is nothing normative in the document? Well, if the chairs think
a formal consensus call is needed, simply execute one. As document
editor, I would appreciate more document content reviews. ;-)

I believe that we need at least an applicability sta= tement pointing to RESTCONF as the normative solution for LMAP. IMO this st= atement was implicit as long as draft-ietf-lmap-rest= conf is Standards Track. Making it Informational le= ads to the need to write something else, or change the scope in the charter= .=C2=A0

More document content reviews woul= d certainly be welcome.


=C2=A0

/js

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

--94eb2c070a32e77ed30552efe15d--