[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
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:
> ================================================
> 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.)
Ack
> 2*) Table of Contents is incorrect, please
> regenerate it, (e.g. The SNMP Management Framework
> should be The Internet-Standard Management Framework).
Ack
> 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?
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
> Boxborough.
Ack
> 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.)
Ack
> 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.
Ack
> 7*) ORGANIZATION, please add IETF
> as in "IETF Common Control and ...."
Ack
> 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
Ack
> 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.
Ack
> 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.
Ack
> 11*) Please change "Informational References"
> to "Informative References"
Bleagh
Ack
> 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.
Ack
> 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?
Ack
All of the labels are Generalized Labels!
> 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?
Nack
64 is safely larger than will ever be used.
> 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."
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."
> 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.
Ack
> 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)
> }
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
> -------------------------------------
>
> 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."
Ack
> 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.
Ack
> 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."
Ack
> Section 6.2 Informational References.
> ---------------------------------------
>
> 6) Section 6.2 Informational References.
> Please change to "Informative".
Grrrrrr.
Ack
> 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.
Nack
In fact not referenced and should be deleted.
> [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling -
> RSVP-TE Extensions", RFC 3473 January 2003.
Nack
In fact not referenced and should be deleted.
> [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual
> Conventions and for Multiprotocol Label Switching
> (MPLS) Management", RFC 3811, June 2004.
Ack
> [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol
> Label Switching (GMPLS) Architecture", RFC 3945,
> October 2004.
Ack
> [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.
Nack
In fact not referenced and should be deleted.
> 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.
Ack