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

[Benoit Claise <[e-mail]>]

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