[lmap] changing draft-ietf-lmap-restconf to Informational (was: Re: draft-ietf-lmap-restconf status and way forward)

Dan Romascanu <dromasca@gmail.com> Tue, 27 June 2017 09:23 UTC

Return-Path: <dromasca@gmail.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3CFC1129413 for <lmap@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9Xt4UdrX2FlM for <lmap@ietfa.amsl.com>; 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 <lmap@ietf.org>; Tue, 27 Jun 2017 02:23:21 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id 16so20365246qkg.2 for <lmap@ietf.org>; 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 with SMTP id j186mr5486000qkc.92.1498555400402; Tue, 27 Jun 2017 02:23:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 27 Jun 2017 02:23:19 -0700 (PDT)
From: Dan Romascanu <dromasca@gmail.com>
Date: Tue, 27 Jun 2017 12:23:19 +0300
Message-ID: <CAFgnS4WqBXSCsAK3F_q_BafUpQgq6QNTbg2vSnxBa0SrQxDy5g@mail.gmail.com>
To: Benoit Claise <bclaise@cisco.com>
Cc: "Carey, Timothy (Nokia - US)" <timothy.carey@nokia.com>, "lmap@ietf.org" <lmap@ietf.org>, Dan Romascanu <dromasca@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c05c282513cef0552ed9ea4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/7sdgMCMm5uTYnDHIF-XIGVknj4o>
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 <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 09:23:24 -0000


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.



On Tue, Jun 27, 2017 at 9:55 AM, Benoit Claise <bclaise@cisco.com> 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 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
> _______________________________________________
> lmap mailing list
> lmap@ietf.org
> https://www.ietf.org/mailman/listinfo/lmap