[lmap] [review]: draft-ietf-lmap-restconf-00

["Bajpai, Vaibhav" <[e-mail]>]

Hello,

>     Title           : Using RESTCONF with LMAP Measurement Agents
>     Authors         : Juergen Schoenwaelder
>                       Vaibhav Bajpai
>     Filename        : draft-ietf-lmap-RESTCONF-00.txt
>     Pages           : 10
>     Date            : 2015-07-03

I made some notes. Thought to share it along:

a) The LMAP framework document reference is outdated:

The draft currently cites -12 (while the latest version is -14). Although
the framework may become an RFC by the next revision.

b) Appendix A: Response to Protocol Comparison Criteria:

Perhaps we promote the example exchanges (Appendix B and Appendix C) ahead of
the response to protocol selection critera? -- or maybe we can just remove it
given the document is a WG document now. The response is documented already in
the non-WG version of this document. Currently it digresses the reader into a
tangent.

c) Examples: (Appendix B and C):

Perhaps we reiterate that in the example exchanges; the MA is the RESTCONF
server and the LMAP controller/collectors are the RESTCONF clients. Although
it's clear that a client would be sending GET/POST requests; but maybe adding
this line avoids any confusion, given that there is also a call-home mechanism
that switches roles in the very beginning where the MA works as a TCP client.

d) Appendix C

>     The first step taken by the collector is to lookup the event stream resource.
> 
>     C: GET /restconf/data/ietf-restconf-monitoring:restconf-state/
>     C:     /streams/stream=NETCONF/encoding=json/events HTTP/1.1
>     C: Host: example.com
>     C: Accept: application/yang.data+xml

Perhaps we should add (as previously indicated in Appendix B) that prefix C:
indicates the LMAP collector.

>     C: GET /streams/NETCONF-json HTTP/1.1
>     C: Host: example.com
>     C: Accept: text/event-stream
>     C: Cache-Control: no-cache
>     C: Connection: keep-alive
> 
>     M: data: {
>     M: data:    "ietf-restconf:notification": {
>     M: data:      "event-time": "2015-03-25T00:01:00+00:00",
>     M: data:      "ietf-lmap:report": {
>     M: data:         "date": "2015-03-25T00:01:00+00:00",
>     M: data:         "agent-id": "xxx",
>     M: data:         "header": {
>     M: data:           "column": "target",
>     M: data:           "column": "rtt"
>     M: data:         }
>     M: data:         "row": {
>     M: data:           "start": "2015-03-25T00:00:55+00:00",
>     M: data:           "value": "192.0.2.1",
>     M: data:           "value": 42
>     M: data:         }
>     M: data:         "row": {
>     M: data:           "start": "2015-03-25T00:00:56+00:00",
>     M: data:           "value": "192.0.2.2",
>     M: data:           "value": 24
>     M: data:         }
>     M: data:      }
>     M: data:    }
>     M: data: }

Perhaps we add a line to indicate that this response is asynchronous and not
an immediate reaction to the LMAP controller's GET request?

e) Typos/Edits

>     levels of granularity using DELETE, PATCH, POST, and PUT methods.

- using HTTP DELETE, ... methods

>     One way of mapping the information model parts relevant for reports
>     into a YANG data model is the usage of YANG notifications.

- isn't it RESTCONF notifications? -- or YANG-defined notifications?

>     Note that alternative designs are possible.

- alternative designs are also possible.

>     One option is to make the collector a RESTCONF server and to have the MA
>     push results to the collector by posting to resources on the controller.

- by posting to resources on the ‘collector’? (instead of controller)

>     Below is an XML representation of instance data conforming to the
>     YANG data model is shown below.

An XML representation of instance data conforming to the YANG data model is
shown below.

>     Note that some of the strings are references to other portions of the
>     instance data not show here.  This is again taken from [I-D.ietf-lmap-yang].

Note that some of the strings which are references to other portions of the
instance data are not shown here.

f) Generally, do you think we should prepend LMAP every time we use the controller
and collector, or should it be obvious given that this is an LMAP document?

Best, Vaibhav

=====================================================
Vaibhav Bajpai

Research I, Room 91
Computer Networks and Distributed Systems (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com
=====================================================