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

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Jun 2017 12:23:19 +0300

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.

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.

Regards,

Dan

On Tue, Jun 27, 2017 at 9:55 AM, Benoit Claise <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Jun 2017 13:41:52 +0200

> there will be no full standards-track solution for the control protocol and

This is incorrect since there are two standards-track protocols that
can be used with the standards-track LMAP data model.
 
> The P in LMAP stands for Protocol.

The charter says "Large-Scale Measurement of Broadband Performance (lmap)".

> Maybe the YANG data models are

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. ;-)

/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/>

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 27 Jun 2017 15:05:23 +0300

Hi,

See in-line.

Regards,

Dan

> 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 charter says "Large-Scale Measurement of Broadband Performance (lmap)".

I stand corrected.

> 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.