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

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Jun 2017 12:13:40 +0200

Hi,

I have posted a new version of draft-ietf-lmap-restconf. I have tried
to address the Dan Romascanu's review comments and I tried to better
align the text with the other specifications. There are a couple of
open issues where I would like to have guidance from the WG or the
chairs.

a) The document header says Standards Track but since this document
   does not really define anything but merely explains how the various
   pieces fit together, I think the document should be Informational.

b) I added some figures to explain how connection establishment works
   with RESTCONF with and without Call Home. I think Tim wanted to
   have this better explained. It would be nice to receive feedback
   whether the figures address the comment.

c) There are two examples in the appendix. I still need to update them
   to align them with the final version of the data model and to move
   to JSON encoding. (We once decided that the YANG model shows XML
   encoded examples while the RESTCONF document shows JSON encoded
   examples.) If the document becomes Informational, I think it is
   better to move the examples inline instead of having them in an
   appendix.

d) I do not know what to do about section 5. Do we have to discuss in
   this document how RESTCONF configuration is done? My preference is
   to not go there since (a) the relevant specifications are still
   being worked on in NETCONF - so we have to wait on these
   specifications getting stable and (b) there may be several
   different ways to configure certain features and I do not know how
   to select what we should document here and I see also a certain
   risk of ending up with something that is inconsistent with the
   actual specifications. My preference would be to simply point to
   the work-in-progress documents.

If the answer to a) is Informational, to b) Tim's request has been
addressed, to d) we do not go into the details of RESTCONF
configuration, than I can do c) relatively quickly and we may even
move this document to WG last call before IETF 99.

/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: "Carey, Timothy (Nokia - US)" <[email-masked]>
Date: Fri, 9 Jun 2017 19:50:42 +0000

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.

Other than that I am fine with how you describe the Call Home.

As to the others - 

Yes informational would be better than standards as there isn't any normative language; 

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.

BR,
Tim

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, June 02, 2017 5:14 AM
To: [email-masked]
Subject: [lmap] draft-ietf-lmap-restconf status and way forward

Hi,

I have posted a new version of draft-ietf-lmap-restconf. I have tried to address the Dan Romascanu's review comments and I tried to better align the text with the other specifications. There are a couple of open issues where I would like to have guidance from the WG or the chairs.

If the answer to a) is Informational, to b) Tim's request has been addressed, to d) we do not go into the details of RESTCONF configuration, than I can do c) relatively quickly and we may even move this document to WG last call before IETF 99.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Jun 2017 22:14:55 +0200

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

> 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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 27 Jun 2017 08:55:41 +0200

> I will change -05 to say Informational unless the chairs tell me
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