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

Benoit Claise <> Tue, 27 June 2017 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B34212EB77 for <>; Mon, 26 Jun 2017 23:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.503
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nap8a8uXLbTq for <>; Mon, 26 Jun 2017 23:55:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (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;;; 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 (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 06:55:42 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id v5R6tgx9001525; Tue, 27 Jun 2017 06:55:42 GMT
To: "Carey, Timothy (Nokia - US)" <>, "" <>
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-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

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