Re: [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 12:05 UTC

Return-Path: <dromasca@gmail.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 1BE00120454 for <lmap@ietfa.amsl.com>; 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 <lmap@ietfa.amsl.com>; 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 <lmap@ietf.org>; Tue, 27 Jun 2017 05:05:25 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id i2so22273688qta.3 for <lmap@ietf.org>; 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: <CAFgnS4WqBXSCsAK3F_q_BafUpQgq6QNTbg2vSnxBa0SrQxDy5g@mail.gmail.com> <20170627114152.GA4350@elstar.local>
From: Dan Romascanu <dromasca@gmail.com>
Date: Tue, 27 Jun 2017 15:05:23 +0300
Message-ID: <CAFgnS4VoGpv1ephq1X-e3jXGMJxt+GvVrj0LT_5=ULvVy2b=1w@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Dan Romascanu <dromasca@gmail.com>, Benoit Claise <bclaise@cisco.com>, "Carey, Timothy (Nokia - US)" <timothy.carey@nokia.com>, "lmap@ietf.org" <lmap@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c070a32e77ed30552efe15d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/SVJZ1zhfJcW9BXWoCrmXZ1EUEAU>
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 <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 12:05:37 -0000

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         <http://www.jacobs-university.de/>
>