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

Benoit Claise <bclaise@cisco.com> Tue, 27 June 2017 06:55 UTC

Return-Path: <bclaise@cisco.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 3B34212EB77 for <lmap@ietfa.amsl.com>; 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 <lmap@ietfa.amsl.com>; 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 <lmap@ietf.org>; 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: A0DQAADCAFJZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBgyuGCIoZc5BNIpV8ghGGJAKDMBgBAgEBAQEBAQFrKIUZAQUjDwEFUQsYAgImAgJXBgEMCAEBiiyvWYImi1sBAQEBAQEBAwEBAQEBASKBC4Icg0yBYSsLgm6EVIMpgmEBBJ5vk2qLHoZ2jFWITx84gQowIQgbFYdePolSAQEB
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)" <timothy.carey@nokia.com>, "lmap@ietf.org" <lmap@ietf.org>
References: <20170602101340.GA93882@elstar.local> <AM5PR0701MB2644F8C2534577F043E0FBF8EFCE0@AM5PR0701MB2644.eurprd07.prod.outlook.com> <20170609201454.GA49378@elstar.local>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <d34ebfd7-bfc2-9a97-0241-ec66862d716e@cisco.com>
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: <https://mailarchive.ietf.org/arch/msg/lmap/1otE-4RgNjfqYgNGolT9xB8Hwek>
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: 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
>