Subject: [ippm] OPS-AD evaluation of: draft-ietf-ippm-metrics-registry-05.txt (fwd)

From: "Henk Uijterwaal (RIPE NCC)" <[email-masked]>
Date: Thu, 29 Apr 2004 12:50:31 +0200 (CEST)

Dear All,

We received the attached set of comments on
draft-ietf-ippm-metrics-registry-05.txt from Bert Wijnen.  Emile is
already looking into them, as soon as he has processed them, an 06-draft
will be published and the WGLC repeated,

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Process and Procedure are the last hiding place of people without the wit
and wisdom to do their job properly.                          (David Brent).

---------- Forwarded message ----------
Date: Sun, 25 Apr 2004 05:52:49 +0200
From: "Wijnen, Bert (Bert)" <[email-masked]>

[...]

Here we go:

1. Abstract
   s/OBJECT IDENTIFIER/OBJECT-IDENTITY/
   I actually would word it differently. SO I would change it from

    Abstract

    This memo defines a registry of the IPPM working group metrics. It
    assigns an OBJECT IDENTIFIER to each metric currently standardized by
    the IPPM WG. It defines the rules for the identification of the
    metrics standardized in the future.

   to something aka:

    Abstract

    This memo defines a registry for IP Performance Metrics (IPPM). It
    assigns and registers an initial set of OBJECT IDENTITIES to currently
    defined metrics in the IETF.

    This memo also defines the rules for adding new IP Performance Metrics
    in the future, both those standardized inside and outside the IETF.

    IANA has been assigned to administer this new registry.

2. Section 3 currently is a copy of the abstract. Not sure if that is
   usefull. I would just leave it out. Section 5 (also named overview)
   seems to be more helpfull.

3. In sect 5, the memo speaks of "MIBs". This should be changed to
   "MIB modules". I think I have mentioned many times that we have only
    one single MIB that is composed of multiple MIB modules.
   This same change needs to be made at multiple places in this document

4. Sect 5. first bullet.
   I think I would change "clearly" into "clearly and unambiguously"

5. Sect 6, 1st para

     MIBs need OBJECT INDENTIFIERs to refer precisely to the standardized
     metrics. The registry associates an OBJECT IDENTIFIER with each
     metric. As an example oneWayDelay and oneWayDelayPoissonStream have
     different identifiers.

   change to something aka:

     MIB modules need to be able to precisely reference IPPM Metrics.
     The registry associates an OBJECT-IDENTITY with each metric. As an
     example oneWayDelay and oneWayDelayPoissonStream have different
     OBJECT IDENTITIES.

6. Sect 6 2nd para
   I do not know why we would name a branch "rfc".
   The OIDs under RFC are IETF OIDs, and so I would name the branch
   ietf and not rfc.

7. Sect 6 3rd para
   Seems that this specifically applies to metrics defined in IPPM sofar.
   You may want to add a note about that. Or better, I would change

     The name of the metric in the registry must respect the SMIv2 rules
     for descriptors ([RFC2578], section 3.1) and should be easily
     readable. Consequently the following is applied to adapt the name
     used in the metric definition:

       + The first letter is forced to lower case;
       + '-' are removed;
       + The letter following a '-' is forced to upper case;
       + 'Type-P' prefix is removed.

   Into

     The name of the metric in the registry must respect the SMIv2 rules
     for descriptors ([RFC2578], section 3.1) and should be easily
     readable. Consequently the following is applied to adapt the name
     used in the IPPM WG metric definitions:

       + The first letter is changed to lower case;
       + '-' are removed;
       + The letter following a '-' is changed to upper case;
       + 'Type-P' prefix is removed.

   But as I said before, I think I would add to all of them a prefix of
   ietf. So I would even change it to:

       + The name always starts with prefix 'ietf'
       + 'Type-P' prefix is removed.
       + '-' are removed;
       + The letter following a '-' is changed to upper case;

8. I am not sure what section 6.1 is.
   If I understand the word "improbable" correctly, then it means that
   this does not yet exist and will probably never exists. So it is an
   example of how new metrics would be added (as per the idea of this
   internet-draft). I think that that method is wrong, because

   - it will move the assignments over many documents,
   - therefor it will be more difficult to ensure that there are no
     name clashes/conflicts and that assignments are unique
   - for people who want to use metrics it will be difficult to find
     them.

   So I would make it a single IANA maintained MIB module in which the
   IANA can add new assignments.
   If you all do agree, then of course the writeup needs to change.

   Each document that creates new Metrics would have an IANA considerations
   secrion in which it would request to assign the new metrics. For
   each metric, that document would have (in IANA Considerations sect)
   a statement aka:

     IANA has registed the following Metric in the IANA-IPPM-METRICS-MIB:

       ietfSomeNewMetricName OBJECT-IDENTITY
           STATUS       current
           DESCRIPTION "The identifier for the Type-P-Some-New_Metric-Name
                        metric."
           REFERENCE   "RFCxxxx, section n."  -- RFC-Editor fills in xxxx
           ::=         { ietf nn }            -- IANA assigns nn

   There is one little concern I have... do we expect the RFCxxxx that
   contains the metrics to be updated? In any event, such is possible.
   And in that case, the REFERENCE clause may have to be updated
   (assuming no semantic change was made to the metric... in which case
    it would have to be assigned another name anyway, no?).
   So if the REFERENCE clause then needs to be updated, we should say
   something about that too in the IANA rules.

9. Sect 6.2 needs to change a bit if you agree with my proposal to have
   IANA maintain this registry

10. Sect 6.3
    I think it is better if assignments are made by IANA and such AFTER
    approval of a document by the IESG. SO very much similar to the
    way MIB Modules are assigned a root OID.

11. Sect 6.4
    I think "otherBodies" is a bad name. I would call it otherOrganizations
    Or maybe nonIetfSpecifications

12. Although other organisations can indeed define their metrics in their
    own OID tree, I would strongly encourage them to register with IANA
    instead. That way we have one place to find the metrics.

    We could also add a enterprise branch, under which enterprises can
    create new names with their enterprise.vendodID (as assigned per
    IANA already).

13. I think that most of the Informative References (those that point to
    RFCs that contain metrics that are assigned an OID in this memo)
    MUST be normative. Because they are the authoritative source of the
    metric.

14. By the way, if we do use an IANA maintained MIB module, then we MUST
    describe the rules for assignments in the MODULE-IDENTITY DESSCRIPTION
    clause, so that IANA always has them handy and so that people who
    pick up the iana mib module can see it.

15. I would make the Security Considerations MUCH simpler. And spcifically
    if we follow my suggestion/proposal to make it an IANA maintained
    MIB module. I would make it something aka:

      This module does not define any management objects.  Instead, it
      assigns a set of OBJECT-IDENTITIES which may be used by other MIB
      modules to identify specific IP Performance Metrics.

      Meaningful security considerations can only be written in the MIB
      modules that define management objects.  This document has therefore
      no impact on the security of the Internet.

16. In any case, there SHOULD be an IANA considerations section

Thanks,
Bert

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm