Re: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT)

[<[e-mail]>]

Alvaro, Benoit
Thanks!

On comment 1, about references to the Information model:
I’m happy to keep as-is, as Benoit suggests (providing it doesn’t hold up this document)

On comment 2 and Benoit’s reply

If I remember some earlier discussion, it wasn’t obvious to everyone that there can be non-IETF registries.



How about this:

      *  the Metric, specified as a URI to a registry entry; it includes

         the specification of a Measurement Method. The registry could be defined by a standards organisation or locally by the operator of the Measurement System. Note that the IETF

               currently works on such a registry specification

         [I-D.ietf-ippm-metric-registry].

phil

From: lmap [mailto:[e-mail]] On Behalf Of Benoit Claise
Sent: 14 April 2015 10:11
To: Alvaro Retana; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [lmap] Alvaro Retana's No Objection on draft-ietf-lmap-framework-12: (with COMMENT)

Hi Alvaro,

Thanks for your review.
See in-line.

Alvaro Retana has entered the following ballot position for

draft-ietf-lmap-framework-12: No Objection



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

http://datatracker.ietf.org/doc/draft-ietf-lmap-framework/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



This document provides a framework, as such it is not defining the

specific final pieces.  Section 2 reads:



   Other LMAP specifications will define an information model, the

   associated data models, and select/extend one or more protocols for

   the secure communication: . . .



I believe there are at least 2 superfluous forward references that the

document can live without.



1. Information Model.  For example, in Section 5:



   The protocol model is closely related to the Information Model

   [I-D.ietf-lmap-information-model], which is the abstract definition

   of the information carried by the protocol.  (If there is any

   difference between this document and the Information Model, the

   latter is definitive, since it is on the standards track.)  The

   purpose of both is to provide a protocol and device independent view,

   which can be implemented via specific protocols.  LMAP defines a

   specific Control Protocol and Report Protocol, but others could be

   defined by other standards bodies or be proprietary.  However it is

   important that they all implement the same Information Model and

   protocol model, in order to ease the definition, operation and

   interoperability of large-scale Measurement Systems.



Reference is made to Information Model work in progress that could match

this document.  Given the disclaimer in the text about potential

differences, I think that leaving a reference in the text could cause

confusion.  IOW, I'm suggesting you take out the reference and the

disclaimer, and just let the Information Model draft speak for itself.
There is actually a correlation between the [I-D.ietf-lmap-information-model] and the high level primitives documented in the framework.
Just as one example:
   +-----------------+                                   +-------------+
   |                 |                                   | Measurement |
   |  Controller     |===================================|  Agent      |
   +-----------------+                                   +-------------+

   Instruction:                            ->
   [(Measurement Task configuration
       URI of Metric(
      [Input Parameter],
      (Role)
      (interface),
      (Cycle-ID)
      (measurement point)),
    (Report Channel),
    (Schedule),
    (Suppression information)]
                                            <-        Response(details)


   The Instruction defines information with the following aims
   ([I-D.ietf-lmap-information-model] defines the consequent list of
   information elements):

   o  the Measurement Task configurations, each of which needs:

      *  the Metric, specified as a URI to a registry entry; it includes
         the specification of a Measurement Method.  The registry could
                ...
Considering that we needed some agreement on the information model to document the framework, and considering that the information model is stable, I'm not too concerned about the forward reference to the information model.
LMAP could have been submitting the framework and the information model at the same time, but chose to submit first the framework and then the information model AND the YANG data model at the same time.




2. Registry for Performance Metrics.  Section 5.2.2:



   o  the Measurement Task configurations, each of which needs:



      *  the Metric, specified as a URI to a registry entry; it includes

         the specification of a Measurement Method.  The registry could

         be defined by the IETF [I-D.ietf-ippm-metric-registry], locally

         by the operator of the Measurement System or perhaps by another

         standards organisation.



The framework is leaving the door open for multiple ways to define a

registry, but is making reference to a specific one (still WIP)..it just

causes confusion.
I understand where you come from. The fact is that LMAP requires performance metric definitions, so it should be mentioned.
Potential new text:


  o  the Measurement Task configurations, each of which needs:



      *  the Metric, specified as a URI to a registry entry; it includes

         the specification of a Measurement Method.  Note that the IETF

        currently works on such a registry specification

         [I-D.ietf-ippm-metric-registry].


Regards, Benoit








Neither of these comments are major, not do they take away from the

technical value of the document.  Mostly suggestions to improve the

clarity of what the framework is proposing.





.