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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 9 Sep 2005 12:32:12 +0200

[bcc to David HArrington, he also did submit comments]
[David, I am not sure if you are on WG mailing list]

Joan, thank you very much for your reviews.

It seems to me that some WG discussion may be needed and
I would also expect new revisions of the 3 documents.

Alex and WG chairs,
I have put the comments in the I-D tracker as well.

Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 09, 2005 03:37
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt
> 
> 
> 
> 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: Fri, 9 Sep 2005 15:43:36 +0100

Many thanks to David and Bert, and especially Joan.

Tom and I are wading through the comments at the moment and will send a
reply as soon as we can.

It seems that a good proportion of the requested changes are editorial,
some are important boilerplate, and a few are related to ASN.1/SNMP. We
should be able to clear them up very quickly.

Bert is right that we will need new versions of the documents. Not sure if
there is anything for WG discussion, but we will probably want to hold
another last call just because of the number of changes.

Cheers,
Adrian
----- Original Message ----- 
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, September 09, 2005 11:32 AM
Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt