Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt

From: [email-masked]
Date: Thu, 08 Sep 2005 21:37:17 -0400

HI Tom and Adrian,

This email has 2 parts:  First are comments which
pertain to the 3 GMPLS MIB docs under review.  
I thought this was easier than repeating these
comments 3 times.  

Following are additional comments on 
draft-ietf-ccamp-gmpls-tc-mib-07.txt.

   thanks, Joan

General comments for all 3 drafts:
================================================
1*) Suggestion only:
   When submitting these 3 GMPLS MIBs
   you may want to ask RFC-editor
   to give the GMPLS-TC-STD-MIB document the first
   RFC number, and that all 3 GMPLS MIB docs appear
   contiguously numbered.

   If you would like to incorporate this suggestion
   then you'd need to add a paragraph to the 
   IANA Considerations section and put the usual
   RFC-editor disclaimers around your request, such
   as:

   (Note to RFC-Editor:)
   We request that you assign the first RFC number
   to the draft-ietf-ccamp-gmpls-tc-mib, and also
   assign contiguous numbers to all three GMPLS MIB
   docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, 
   draft-ietf-ccamp-gmpls-lsr-mib, and 
   draft-ietf-ccamp-gmpls-te-mib.
   (Please remove this note prior to publication.)

2*) Table of Contents is incorrect, please
   regenerate it, (e.g. The SNMP Management Framework
   should be The Internet-Standard Management Framework).

3*) Question if these documents should have a 
   contributors section.  It violates the guidelines
   of "RFC Editorial Guidelines and Procedures"
   http://www.rfc-editor.org/policy.html#policy.auth2

   There are many people listed under 
   Authors but not listed on the front page,
   so how about adding a Contributors Section?

4*) Tom's Contact info needs to be updated to 
   Boxborough. 

5*) would be clearer to be consistent about
referring to MIB modules and always use the entire MIB name
and site the reference: 
e.g. MPLS LSR MIB module or LSR MIB module, 
     should be MPLS-LSR-STD-MIB module [RFC3813]

e.g. GMPLS LSR MIB module, should be 
     GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor:
     please fill in XXX with the RFC name for 
     draft-ietf-ccamp-gmpls-lsr-mib and remove this note.)

6*) The term "extends" is used and since this term is applied
to GMPLS interfaces, the more appropriate phrase is
'sparse augments'.    Please change this in the text.

7*) ORGANIZATION, please add IETF
   as in "IETF Common Control and ...."

8*) DESCRIPTION
   Please change the first paragraph to:

             Copyright (C) The Internet Society (2005).  This version of
             this MIB module is part of RFC XXX; see the RFC itself for
             full legal notices.

The exception to this is the IANA-GMPLS-MIB module, which should
include:

       "Copyright (C) The Internet Society (2005). The initial version
        of this MIB module was published in RFC XXXX. For full legal
        notices see the RFC itself.  Supplementary information
        may be available on:
        http://www.ietf.org/copyrights/ianamib.html

9*) Please make sure to ask RFC-Editor to remove comments
    prior to publication, e.g.

    -- RFC Editor's Note (to be removed prior to publication): 

    "Initial version published as part of RFC XXXX."
       -- replace XXX with actual RFC number & remove this note.

10*) Acknowledgements Section
   Please start off this section with:

This document is a product of the CCAMP Working Group.  

   and remove:

This draft is the work of the five authors listed in the next
   section.

11*) Please change "Informational References"
to "Informative References"

12*) There are a number of references (as discovered by
Bert) that aren't in the RFC expected format.
Please review all the references in this document and
the other GMPLS MIB docs.
Please see comments in the review of the
draft-ietf-ccamp-gmpls-lsr-mib-08.txt for
examples of references in the RFC format.

draft-ietf-ccamp-gmpls-tc-mib-07.txt
======================================

Section 3. GMPLS Textual Conventions MIB Definitions
---------------------------------------------------

1) GmplsFreeformLabel TC
   
1a) Could the REFERENCE include section(s)?  
   I suspect that this is referring to the Generalized Label
   described in section 3.2.1, is this correct?

1b) Please explain why this is 0..64 ?  
   RFC3471 states that the Generalized label can be
   variable length, so wondering if this should be made
   larger?  

1c) The DESCRIPTION needs a little work:
    DESCRIPTION
       "This value represents a freeform generalized MPLS Label. This
        can be used to represent label types which are not standard in
        the drafts. It may also be used by systems that do not wish to
        represent the labels using the specific label types."

     Please reword to something like:

      "This value represents a freeform GMPLS label.  A freeform GMPLS
       label is specified by the system which uses it.  In other words,
       the freeform GMPLS label is not a standard GMPLS label type,
       but is created by the system which uses it."

2) GmplsGeneralizedLabelTypes  TC

2a) Could you change the name of the TC
     GmplsGeneralizedLabelTypes to

     GmplsLabelType

     It is more appropriate to have it singular when
     Imported and used in other MIBs, and dropping the
     word Generalized, because you already have the
     prefix Gmpls.

2b)  Could the SYNTAX order be changed?

    Currently:

    SYNTAX INTEGER {
       gmplsMplsLabel(1),
       gmplsPortWavelengthLabel(2),
       gmplsFreeformGeneralizedLabel(3),
       gmplsSonetLabel(4),
       gmplsSdhLabel(5),
       gmplsWavebandLabel(6)
     }

    Proposed (NOTE also some of the names have been changed):

   SYNTAX INTEGER {
       gmplsFreeformLabelOrOther(1),
       gmplsMplsLabel(2),
       gmplsPortAndWavelengthLabel(3),
       gmplsSonetLabel(4),
       gmplsSdhLabel(5),
       gmplsWavebandLabel(6)
     }

Section 4. Security Considerations 
-------------------------------------

3)   Change MPLS to GMPLS in the following statement:

   "This module does not define any management objects. Instead, it
   defines a set of textual conventions which may be used by other MPLS
   MIB modules to define management objects."

Section 5. IANA Considerations
-------------------------------------

4) Section 5. IANA Considerations
   RFC Editor's Note (to be removed prior to publication):
   the IANA is requested to assign a value for "XXX" under
   the mib-2/mplsStdMIB subtree and to record the assignment 
   in the SMI Numbers registry.
   When the assignment has been made, the RFC Editor is
   asked to replace the "XXX" (here and in the MIB module) with
   the assigned value and to remove this note.

5) Section 5. IANA Considerations

   Please remove the last sentence of this section:

  "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB."

Section 6.2 Informational References.
---------------------------------------

6) Section 6.2 Informational References.
  Please change to "Informative".

7) I believe the following references should be moved
to the Normative section:

   [RFC3472]        Ashwood-Smith, P., Berger, L. (Editors),
                    "Generalized MPLS Signaling - CR-LDP Extensions",
                    RFC 3472, January 2003.

   [RFC3473]        Berger, L. (Editor), "Generalized MPLS Signaling -
                    RSVP-TE Extensions", RFC 3473 January 2003.

   [RFC3811]        Nadeau, T. and J. Cucchiara, "Definition of Textual
                    Conventions and for Multiprotocol Label Switching
                    (MPLS) Management", RFC 3811, June 2004.

   [RFC3945]        Mannie, E. (Editor), "Generalized Multiprotocol
                    Label Switching (GMPLS) Architecture", RFC 3945,
                    October 2004.

   [GMPLSSonetSDH]  Mannie, E., Papadimitriou, D. (Editors),
                    "Generalized Multi-Protocol Label Switching
                    Extensions for SONET and SDH Control",
                    draft-ietf-ccamp-gmpls-sonet-sdh, work in progress.
 
   (the above is now RFC 3946)
   [GMPLS-SONET]   Mannie, E. and D. Papadimitriou, "Generalized Multi-
                   Protocol Label Switching (GMPLS) Extensions for
                   Synchronous Optical Network (SONET) and Synchronous
                   Digital Hierarchy (SDH) Control", RFC 3946, October
                   2004.

Also, as previously mentioned, need to check
on the format of these References.
Please see comments in the review of the
draft-ietf-ccamp-gmpls-lsr-mib-08.txt for
examples of references in the RFC format.

--- the end ---

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Sep 2005 13:49:09 +0100

Hi Joan,

Thanks again for the thorough review.

Please see below our responses on the general comments and the TC MIB
module.

I have indicated Ack or Nack for each point you raised.  Where there is a
Nack I have indicated either our reasoning or a proposed alternate
solution.

Cheers,
Adrian

> General comments for all 3 drafts:

Ack

>    should be The Internet-Standard Management Framework).

Ack

>    so how about adding a Contributors Section?

Ack
We will change the title of "Authors' Addresses" section to be "Contact
Details".
That covers all

> 4*) Tom's Contact info needs to be updated to

Ack

>      draft-ietf-ccamp-gmpls-lsr-mib and remove this note.)

Ack

> 'sparse augments'.    Please change this in the text.

Ack

>    as in "IETF Common Control and ...."

Ack

>         http://www.ietf.org/copyrights/ianamib.html

Ack

>        -- replace XXX with actual RFC number & remove this note.

Ack

> This draft is the work of the five authors listed in the next

Ack

> to "Informative References"

Bleagh
Ack

> examples of references in the RFC format.

Ack

> draft-ietf-ccamp-gmpls-tc-mib-07.txt

Ack
All of the labels are Generalized Labels!

>    variable length, so wondering if this should be made

Nack
64 is safely larger than will ever be used.

>        but is created by the system which uses it."

Nack
The text as originally stated is correct and your revision is wrong. That
is,
the freeform label MAY also be used to represent standard labels as octet
strings.
This is a popular way to handle the management of multiple different types
of
labels.

Will change to:
        "This value represents a freeform GMPLS Label. This can be used
         to represent label that have label types which are not
standardised.
         It may also be used by systems that do not wish to represent
labels
         that have standardised label types using the type-specific
objects
         in this table."

>      word Generalized, because you already have the

Ack

>        gmplsPortAndWavelengthLabel(3),

Nack
i.  "FreeformOrOther" What other? There is just freeform.
ii. Why re-order? The new order seems to have no more logic than the
    old order.

> Section 4. Security Considerations

Ack

> Section 5. IANA Considerations

Ack

>   "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB."

Ack

> Section 6.2 Informational References.

Grrrrrr.
Ack

>                     "Generalized MPLS Signaling - CR-LDP Extensions",

Nack
In fact not referenced and should be deleted.

>                     RSVP-TE Extensions", RFC 3473 January 2003.

Nack
In fact not referenced and should be deleted.

>                     (MPLS) Management", RFC 3811, June 2004.

Ack

>                     Label Switching (GMPLS) Architecture", RFC 3945,

Ack

>                    Digital Hierarchy (SDH) Control", RFC 3946, October

Nack
In fact not referenced and should be deleted.

> examples of references in the RFC format.

Ack

---

From: [email-masked]
Date: Fri, 23 Sep 2005 12:05:04 -0400

Adrian,

Thank you for the quick turn around.  I have removed issues where we
are in agreement (both the ack'd and nack'd) and will comment only 
on those ones which might need further discussion (both ack'd and nack'd).

Please see comments inline.

  thanks, Joan

>We will change the title of "Authors' Addresses" section to be "Contact

According to the rfc-editor website above,
this should be "Contact Information", is this what you mean?

>         that have standardised label types using the type-specific

Sorry, I'm still a little foggy on what this TC is, partly because the
description is referring to "objects in this table" which is confusing
in a TC DESCRIPTION, and also the definition of the freeform label
used here and used in the GmplsGeneralizedLabelType enum seems be
defined slightly differently. 

A freeform label as described in the DESCRIPTION clause
could contain the value of any GMPLS/MPLS labels, 
right?

>i.  "FreeformOrOther" What other? There is just freeform.

Aren't the label types: gmplsMplsLabel(2),
gmplsPortAndWavelengthLabel(3),
gmplsSonetLabel(4),
gmplsSdhLabel(5),
gmplsWavebandLabel(6)
also a kind of freeform GMPLS label (as indicated by the DESCRIPTION
clause in GmplsFreeformLabel)?

>ii. Why re-order? The new order seems to have no more logic than the

Partly depends on the answer to above i. question.  
If the labels are a kind of freeform label, 
then a better style would be to list 
gmplsFreeformLabel first.  Admittedly, this is a NIT.

Also, please add into the DESCRIPTION clause
a definition for each enum (an example would
be MplsLspType in RFC3811).

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 24 Sep 2005 11:02:24 +0100

Hi Joan,

Thanks for the rapid convergence.

In-line...

Cheers,
Adrian

> this should be "Contact Information", is this what you mean?

Yes, in deed. And Henrick's little tool catches this admirably.

> >is, the freeform label MAY also be used to represent standard labels
> >as octet strings.
> >of labels.
> >         standardised. It may also be used by systems that do not wish to 
> >         represent labels that have standardised label types using the 
> >         type-specific objects in this table."
> 

Good point about "objects in this table." That needs to be removed.

So, the description of GmplsGeneralizedLabelTypes should be changed to read...
        Determines the interpretation that should be applied to an
        object that encodes a label.

But I don't see anything else in the GmplsGeneralizedLabelType enum that presents any interpretation of the freeform object.

> could contain the value of any GMPLS/MPLS labels, 

Right.

How about...
  "This Textual Convention can be used as the syntax of an object
   that contains any GMPLS label. Objects with this syntax can be
   used to represent labels that have label types that are not
   standardised. The freeform GMPLS Label may also be used by 
   systems that do not wish to represent labels that have
   standardised label types using type-specific syntaxes."

> clause in GmplsFreeformLabel)?

It is all to do with the encodings of objects (i.e. the syntaxes) not the use to which the labels can be put. Thus, a normal 20-bit MPLS label an be encoded in an object with syntax MPLSLabel or in an object with syntax GMPLSFreeformLabel. In the former case it is presented as an Unsigned32. In the latter case it is presented as an OCTET STRING.

> be MplsLspType in RFC3811).  

Yes. That is a good idea.

Description will now read...

 DESCRIPTION

   "Determines the interpretation that should be applied to an
    object that encodes a label. The possible types are:

           gmplsMplsLabel(1)         - The label is an MPLS packet, cell,
                                       or frame label and is encoded as 
                                       described for the Textual Convention
                                       MPLSLabel defined in RFC 3811.

    gmplsPortWavelengthLabel(2)      - The label is a port or wavelength
                                       label as defined in RFC 3741.

    gmplsFreeformGeneralizedLabel(3) - The label is any form of label encoded
                                       as an OCTET STRING using the Textual
                                       Convention GMPLSFreeformLabel.

    gmplsSonetLabel(4)               - The label is a SONET label as defined
                                       in RFC 3946.

    gmplsSdhLabel(5)                 - The label is an SDH label as defined in
                                       RFC 3946.

    gmplsWavebandLabel(6)            - The label is a waveband label as defined
                                       in RFC 3471."

---

From: <[email-masked]>
Date: Tue, 27 Sep 2005 21:38:01 -0400

Hi Adrian,

A couple of minor comments inline below.

thanks,
  Joan

> ----- Original Message -----
> From: Adrian Farrel
> To: [email-masked] ; [email-masked] ; [email-masked]
> Cc: [email-masked] ; [email-masked]
> Sent: Saturday, September 24, 2005 6:02 AM
> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt
>
>
> Hi Joan,
>
> But I don't see anything else in the GmplsGeneralizedLabelType enum that
> presents any interpretation of the freeform object.
>

Instead of saying "not standardised" could you say "not defined in any
RFCs"?
This is a small point but not sure if a label in a "proposed standard"
is considered "standardised" yet.

Similarly, with the second use of "standarised" could you say "defined"?

> It is all to do with the encodings of objects (i.e. the syntaxes) not the
> use to which the labels can be put. Thus, a normal 20-bit MPLS label an be
> encoded in an object with syntax MPLSLabel or in an object with syntax
> GMPLSFreeformLabel. In the former case it is presented as an Unsigned32.
In
> the latter case it is presented as an OCTET STRING.
>

Should be "MplsLabel"

>                                        Convention GMPLSFreeformLabel.

Please rename this enum to: gmplsFreeformLabel
which will match the GmplsFreeformLabel TC.  (Also, GMPLSFreeformLabel
should be GmplsFreeformLabel.)

>     gmplsSdhLabel(5)                 - The label is an SDH label as
defined
> in

Please be sure to include all the above referenced RFCs in the
REFERENCE Clause of this object (and also in the Normative References
Section of this draft).

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Sep 2005 13:22:08 +0100

Thanks for your thoroughness, Joan.

All points agreed.

Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 28, 2005 2:38 AM
Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt

> > > >>         can be used to represent label types which are not
standard
> in
> > > >>         the drafts. It may also be used by systems that do not
wish
> to
> > > >The text as originally stated is correct and your revision is
wrong.
> That
> > > >This is a popular way to handle the management of multiple
different
> > types
> > > >         standardised. It may also be used by systems that do not
wish
> to
> >     gmplsWavebandLabel(6)            - The label is a waveband label
as