[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



[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: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
> Sent: Friday, September 09, 2005 03:37
> To: tnadeau@cisco.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
> Cc: bwijnen@lucent.com; jcucchiara@mindspring.com
> 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 ---
>