[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 ---