Re: [lmap] draft-ietf-lmap-restconf status and way forward

"Carey, Timothy (Nokia - US)" <> Fri, 09 June 2017 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB0AF128D3E for <>; Fri, 9 Jun 2017 12:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.701
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RaKaRjIEfo2I for <>; Fri, 9 Jun 2017 12:50:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (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;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eCwqwfVaFDu83iwD9C5MTtNv19OtisFSxMqT0ROV8BI=; b=EPmr/mpsleddKkg5cqdgeSqbrYgGfTZTejOnWdDR3W4JrXmKVCFEl8dZnQ5mNOhjCWZviR5Q85EHDCCLqoiEaSQcZpL9aqJ7VsXdVG0L16q65NXEf3vCjM3axvv0itwoAAJpRd5Wdy8at6sPMK+dj3jp8eyNSF9ZxswA3TEoI78=
Received: from ( by ( 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 ([fe80::3c71:9e3f:be9a:feec]) by ([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 <>, "" <>
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
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
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;; 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-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-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


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.


-----Original Message-----
From: Juergen Schoenwaelder [] 
Sent: Friday, June 02, 2017 5:14 AM
Subject: [lmap] draft-ietf-lmap-restconf status and way forward


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

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.


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