Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base
draft-ietf-ccamp-gmpls-te-mib-16
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
16 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2012-08-22
|
16 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2007-03-12
|
16 | (System) | This was part of a ballot set with: draft-ietf-ccamp-gmpls-lsr-mib, draft-ietf-ccamp-gmpls-tc-mib |
2007-01-22
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from In Progress |
2007-01-22
|
16 | (System) | IANA Action state changed to In Progress from Waiting on ADs |
2007-01-17
|
16 | (System) | IANA Action state changed to Waiting on ADs from In Progress |
2007-01-17
|
16 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2007-01-17
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2007-01-17
|
16 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2007-01-16
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2007-01-16
|
16 | (System) | IANA Action state changed to In Progress from Waiting on RFC Editor |
2006-11-08
|
16 | (System) | Request for Early review by SECDIR Completed. Reviewer: Joseph Salowey. |
2006-10-10
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2006-10-04
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2006-09-24
|
16 | (System) | IANA Action state changed to In Progress from RFC-Ed-Ack |
2006-09-14
|
16 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2006-09-11
|
16 | Amy Vezza | IESG state changed to Approved-announcement sent |
2006-09-11
|
16 | Amy Vezza | IESG has approved the document |
2006-09-11
|
16 | Amy Vezza | Closed "Approve" ballot |
2006-09-09
|
16 | Bill Fenner | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bill Fenner |
2006-09-08
|
16 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2006-09-08
|
16 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-16.txt |
2006-09-01
|
16 | (System) | Removed from agenda for telechat - 2006-08-31 |
2006-08-31
|
16 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2006-08-31
|
16 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2006-08-31
|
16 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2006-08-31
|
16 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2006-08-31
|
16 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2006-08-31
|
16 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2006-08-31
|
16 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
2006-08-31
|
16 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2006-08-31
|
16 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded by David Kessens |
2006-08-30
|
16 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2006-08-30
|
16 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2006-08-29
|
16 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2006-08-29
|
16 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
2006-08-29
|
16 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2006-08-28
|
16 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie |
2006-08-28
|
16 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2006-08-24
|
16 | (System) | IANA Action state changed to In Progress |
2006-08-22
|
16 | Bill Fenner | State Changes to IESG Evaluation from Waiting for Writeup by Bill Fenner |
2006-08-22
|
16 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner |
2006-08-22
|
16 | Bill Fenner | Ballot has been issued by Bill Fenner |
2006-08-22
|
16 | Bill Fenner | Created "Approve" ballot |
2006-08-21
|
16 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2006-08-07
|
16 | Amy Vezza | Last call sent |
2006-08-07
|
16 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-08-07
|
16 | Bill Fenner | Placed on agenda for telechat - 2006-08-31 by Bill Fenner |
2006-08-07
|
16 | Bill Fenner | Last Call was requested by Bill Fenner |
2006-08-07
|
16 | (System) | Ballot writeup text was added |
2006-08-07
|
16 | (System) | Last call text was added |
2006-08-07
|
16 | (System) | Ballot approval text was added |
2006-08-07
|
16 | Bill Fenner | State Changes to Last Call Requested from AD Evaluation by Bill Fenner |
2006-05-09
|
16 | Bill Fenner | State Changes to AD Evaluation from Publication Requested::AD Followup by Bill Fenner |
2006-05-05
|
16 | Bill Fenner | Merged with draft-ietf-ccamp-gmpls-lsr-mib by Bill Fenner |
2006-04-26
|
16 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-04-26
|
15 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-15.txt |
2006-04-25
|
16 | Bill Fenner | State Changes to Publication Requested::Revised ID Needed from Publication Requested by Bill Fenner |
2006-04-25
|
16 | Bill Fenner | [Note]: 'Awaiting update from final MIB review.' added by Bill Fenner |
2006-04-19
|
16 | Bill Fenner | State Changes to Publication Requested from AD Evaluation by Bill Fenner |
2006-04-19
|
16 | Bill Fenner | Shepherding AD has been changed to Bill Fenner from Alex Zinin |
2006-04-19
|
16 | Bill Fenner | State Change Notice email list have been change to ccamp-chairs@tools.ietf.org, jcucchiara@mindspring.com, dromasca@avaya.com from kireeti@juniper.net, adrian@olddog.co.uk; jcucchiara@mindspring.com; bwijnen@lucent.com; dromasca@avaya.com |
2006-04-12
|
14 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-14.txt |
2006-03-17
|
16 | Bert Wijnen | ANother MIB doctor review has been posted to the WG list. Seems a new revision is warranted based on these comments. > -----Original Message----- > … ANother MIB doctor review has been posted to the WG list. Seems a new revision is warranted based on these comments. > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Tuesday, March 14, 2006 16:52 > To: ccamp@ops.ietf.org > Cc: Wijnen, Bert (Bert); Dan Romascanu (E-mail); Adrian > Farrel (E-mail); > Bill Fenner (E-mail); Alex Zinin (E-mail); Tom Nadeau (E-mail) > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt > > > Tom and Adrian, > > Let me apologize for my tardiness in posting the > review comments. > > A great deal of work went into this latest draft. Thank you. > Compile issues are listed first, and are followed by > review comments in order of the document. > > Will have the other reviews out by tomorrow. > > Thanks, Joan > > > > Compile Issues: > =============== > > > 1) smilint and smicngPRO complained > due to REFERENCE clause for gmplsTunnelARHopTable > needing an end quote: > > gmplsTunnelARHopTable OBJECT-TYPE > ... > REFERENCE > "1. Extensions to RSVP for LSP Tunnels, RFC 3209. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473. > 3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB), RFC 3812. > > ^ need end quote > > ::= { gmplsTeObjects 3 } > > > 2) smicngPRO > E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf" > is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in > module "GMPLS-TE-STD-MIB" > > > MANDATORY-GROUPS { > gmplsTunnelGroup, > gmplsTunnelScalarGroup, > gmplsTunnelIsIntfcGroup <-- please add this > gmplsTunnelUnnumIf <--- please remove this > } > > > Also, please update the read-only conformance for gmplsTunnelUnnumIf. > > OBJECT gmplsTunnelUnnumIf > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > 3) This is listed under compile issues because it might be > an issue depending on what is really intended. > RFC4181 "Guidelines for MIB Documents", > Section 4.8. Compliance Statements, > recommends using SYNTAX clauses to denote > a subset of values for an object. > If you don't intend to have a subset for these > then please remove the SYNTAX clause. Please review all of these > Compliance Statements with SYNTAX, only a couple are listed > here: > > OBJECT gmplsTunnelLSPEncoding > SYNTAX IANAGmplsLSPEncodingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > OBJECT gmplsTunnelSwitchingType > SYNTAX IANAGmplsSwitchingType > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required." > > > > SYNTAX clauses such as InetAddressType and InetAddress don't > specify a subset, so need to ask if you intend > to have a subset for these such as: > > SYNTAX InetAddressType { unknown(0), ipv4(1), ipv6(2) } > > SYNTAX InetAddress (SIZE(0|4|16)) > > > 4) Again, wrt Section 4.8 from RFC4181, it is recommended > that if MIB authors intend to have Optional Groups that these > be noted. This was done for the Read-only compliance but not > the Full-compliance, so would ask that all Optional Groups be > specified as recommended by Section 4.8. Reviewing these > Compliances statements is difficult without this information. > > > > Comments: > ----------- > > 1) Table of Contents: > > 3. The SNMP Management Framework .......................... 4 > > Should be: > 3. The Internet-Standard Management Framework > In other words, please change the title for section 3. > > > 2) 5.7 Use of 32-bit and 64-bit Counters > > Shouldn't the quote from RFC2863 be in quotes""? > > 3) 6. Cross-referencing to the gmplsLabelTable > > 2nd paragraph which begins: > The hop tables in this document (gmplsHopTable, gmplsCHopTable and > gmplsARHopTable) and the segment tables in the [RFC3813] > > There is no gmplsHopTable, is this supposed to be: > gmplsTunnelHopTable? > Similar comment with gmplsCHopTable and gmplsARHopTable. > > > 4) gmplsTunnelPathComp > > If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls' > does this object have meaning? > > 5) gmplsTunnelErrorTable, would expect to see these objects > contained in an MPLS group in Compliance/Conformance Statements. > > > 6) gmplsTunnelErrorTLVs OBJECT-TYPE > > When the string size is 0 this could indicate that > no TLVs are present, right? > That would be slightly more efficient than > having to look at the first octet. > If you agree, please modify the > DESCRIPTION to reflect this. > > > Conformace/Compliance: > --------------------- > 7) Please move some of the following comment to the > gmplsTeModuleReadOnlyCompliance DESCRIPTION > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. > > > 8) Already mentioned this but was expecting to see MPLS objects > called out in a separate GROUP (e.g. objects which are valid when > gmplsTunnelLSPEncoding > has a value of 'tunnelLspNotGmpls', and other objects also). > For folks that want to support these MPLS related objects > prior to supporting GMPLS, this would be > important to understand, so the more clearly noted by the MIB the > better. > > > > 9) NIT: In the read-only conformance there is a comment: > > -- All scalars have max access read-only > > which appears in front of a bunch of objects that are > part of a table. Please remove this comment since it > doesn't apply. > > 10) NIT: > > --glmpsTunnelCHopTable > > ^^ typo > > > 11) Security Section > > NIT: the network via SNMP. These are the tables and > objects and their > sensitivity/vulnerability: > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, > gmplsTunnelErrorTable collectively show the tunnel network > > > Should have an "and" > > o the gmplsTunnelTable, gmplsTunnelHopTable, > gmplsTunnelARHopTable, > gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and > > ^^^ > > gmplsTunnelErrorTable collectively show the tunnel network > > > > 12) Normative References: > [RFC4328] Papadimitriou, D., Ed., "Generalized MPLS Signalling > Extensions for G.709 Optical Transport Networks > Control", draft-ietf-ccamp-gmpls-g709, work > in progress. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Please update. > > --end of comments-- |
2006-03-17
|
16 | Bert Wijnen | State Change Notice email list have been change to kireeti@juniper.net, adrian@olddog.co.uk; jcucchiara@mindspring.com; bwijnen@lucent.com; dromasca@avaya.com from kireeti@juniper.net, adrian@olddog.co.uk; jcucchiara@mindspring.com; … State Change Notice email list have been change to kireeti@juniper.net, adrian@olddog.co.uk; jcucchiara@mindspring.com; bwijnen@lucent.com; dromasca@avaya.com from kireeti@juniper.net, adrian@olddog.co.uk; jcucchiara@mindspring.com; bwijnen@lucent.com |
2006-03-03
|
13 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-13.txt |
2005-12-15
|
12 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-12.txt |
2005-10-14
|
11 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-11.txt |
2005-10-12
|
10 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-10.txt |
2005-09-16
|
16 | Bert Wijnen | Additional review from a MIB Tunneling expert (also MIB doctor). Bert Wijnen explicitly requested this review. Posted to ccamp WG list as per below -----Original … Additional review from a MIB Tunneling expert (also MIB doctor). Bert Wijnen explicitly requested this review. Posted to ccamp WG list as per below -----Original Message----- From: Wijnen, Bert (Bert) Sent: Saturday, September 17, 2005 00:11 To: Dave Thaler; Tom Nadeau (E-mail); Adrian Farrel (E-mail) Cc: Kireeti Kompella (E-mail) Subject: RE: review tunneling aspects of: Draft-ietf-ccamp-gmpls-te-mib-09.txt Thanks for your review Dave. I think some of the issues you raise have already been raised by other mIB Doctor review. But I am sure that the authors (and WG) will merge all reported questions/concerns/issues and try to address them in the next revision. I have copied the WG list, so they can see the review comments and think about them or react. Bert > -----Original Message----- > From: Dave Thaler [mailto:dthaler@windows.microsoft.com] > Sent: Friday, September 16, 2005 23:40 > To: Wijnen, Bert (Bert) > Cc: Adrian Farrel (E-mail); Kireeti Kompella (E-mail); Alex Zinin > (E-mail) > Subject: RE: review tunneling aspects of: > Draft-ietf-ccamp-gmpls-te-mib-09.txt > > > Ok here it is... > > Relationship to Tunnel MIB, Interfaces MIB, etc looks good. > > Issues found: > > 1) The MIB imports IpAddress and uses it for gmplsTunnelUpNotRecip > and gmplsTunnelDownNotRecip to instrument the recipient of > Notify messages. It references RFC 3473. However I can't > find anything in 3473 which restricts this to IPv4. Instead > all the discussion around Notify messages (specifically > section 4.2.1) supports both IPv4 and IPv6. Hence I believe > these objects should use InetAddress instead, and the MIB > should not import IpAddress. > > 2) gmplsTunnelErrorHelpString uses the DisplayString TC. > This TC cannot contain international strings. Since the > string is defined as containing descriptions of recovery > actions and support advice, this should probably use > SnmpAdminString instead. > > 3) Regarding gmplsTunnelDown, the DESCRIPTION field says: > Note that an implementation SHOULD only issue one of > mplsTunnelDown and gmplsTunnelDown for a single event on a > single tunnel." > > However, section 4.1 says: > - The GMPLS Tunnel Down Notification (gmplsTunnelDown) is > intended to > be used in place of the mplsTunnelDown Notification defined in > [RFC3812]. > > The difference in wording is that the description field > is weaker and would allow either one, whereas 4.1 is > stronger saying it should always be gmpls. The wording > should be consistent in the two places. > > 4) Error in description of gmplsTunnelIsNotIntfcGroup in compliance: > gmplsTunnelIsIf must at least be read-only returning no(0)." > ^ ^^^^^ > There is no "gmplsTunnelIsIf", it should be mplsTunnelIsIf, > and the value should be false(2) not no(0). > > 5) The gmplsTunnelIsNotIntfcGroup contains gmplsTunnelUnnumIf > as a mandatory object. This seems really odd to me, since > its DESCRIPTION says: > This object is only used if mplsTunnelIsIf is set to 'true'. > and the compliance statement section for gmplsTunnelIsNotIntfcGroup > says (as noted in #4 above) that only TunnelIsIf = false > needs to be supported. Hence, it seems that this object > should not be in this group. > > 6) The Counter64 objects are currently mandatory, in the same > conformance group as the Counter32 equivalents. This means > that an SNMPv1-only agent cannot support this MIB. > Is this the intent? If not, then the HC objects should be > in a separate group. > > -Dave > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Thursday, September 08, 2005 4:31 PM > > To: Dave Thaler > > Cc: Adrian Farrel (E-mail); Kireeti Kompella (E-mail); Alex Zinin > > Subject: review tunneling aspects of: Draft-ietf-ccamp-gmpls-te-mib-09.txt > > > > Dave, can you take a look at this document > > for any tunneling aspects? > > > > Thanks, > > Bert |
2005-09-09
|
16 | Bert Wijnen | Additional review comments from another MIB Doctor, David Harrington. -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Thursday, September 08, 2005 01:49 To: … Additional review comments from another MIB Doctor, David Harrington. -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Thursday, September 08, 2005 01:49 To: 'Thomas D. Nadeau'; 'Adrian Farrel'; kireeti@juniper.net Cc: 'Wijnen, Bert (Bert)'; 'Alex Zinin (E-mail)' Subject: Draft-ietf-ccamp-gmpls-te-mib-09.txt Hi, I am a MIB Doctor, and did a quick review even though I am not the MIB Doctor for this document. I have some comments on the TE MIB: 1) The migration strategy section discusses other documents, such as the GMPLSLSRMIB and RFC3813. Are these mentions necesssary in the TE document? What happens if the other documents are not approved for advancement? 2) Under terminology for ERLSP discusses in-segments and out-segments and egress/ingress LSRs. I don't have a good knowledge of (G)MPLS, so maybe this is a newbie mistake, but the ordering seems odd (in/out vs out/in). 3) In section 4, "those tables may not be appropriate for measuring peerformance on some types of GMPLS links." Doesn't this lead to interoperability issues? 4) The first paragraph in section 4.1 could use some wordsmithing. In addition, Notification is misspelled, and capitalized unnecessarily. Does this notification obsolete the other notification? I am concerned that there are two notification defined for the same purpose, and it is not definitive which should be used when. 5) In section 5.1, for multipoint connections, are all points represented in the table? If not, could someone inadvertently delete a segment that is depended on for multipoint? 6) In section 5.1, the Textual Conventions are not defined by IANA. IAMA only maintains the list of names and assignments. 7) In the mplsTunnelTable example in section 7, is 123.123.125.1 an IP address? If so, is 123.123 one of the approved "example" addresses? 8) As with the other MIB modules in the series, the use of mplsStdMIB as a root is NOT RECOMMENDED. I believe mib-2 is preferred. See mib review guidelines. 9) Why are gmplTeScalars separated from gmplsTeObjects? They're all objects. I think there is a preference for 0=notification, 1=objects, and 2=conformance in the mib guidelines. 10) From the MIB review guidelines "The IpAddress type described in RFC 2578 Section 7.1.5 SHOULD NOT be used in new MIB modules. The InetAddress/InetAddressType textual conventions [RFC3291bis] SHOULD be used instead." GmplsTunnelEntry uses IPAddress. 11) In the gmplsTunnelLinkProtection object, what prevents unprotected from being used in combination with other bits that indicate a protection scheme? 12) gmplsTunnelPathComp says that it deprecates mplsTunnelHopEntryPathComp. I believe the mplsTunnelHopEntryPathComp needs to actually be present here with a status of deprecated. What happens if a system only supports mpls and not gmpls? Is the object mplsTunnelHopEntryPathComp still deprecated? It might be better to support BOTH objects, so management applications that only support MPLS MIBs would still work, but those that support GMPLS gets any extra functionality of the gmpls object. 13) gmplsTunnelUpNotRecip defines an IPv4-only address for upstream notifications. What happens in a network with only IPv6? 14) With SNMPv3, the address alone is insufficient to address a notification; the security parameters are also required. See RFC 3413 for a description of the information required to configure notification targets. 15) gmplsTunnelDownNotRecip has the problems as gmplsTunnelUpNotRecip. 16) gmplsTunnelARHopEntry needs wordsmithing. 17) gmplsTunnelReversePerfPackets and HCPackets, and PerfBytes and HCPerfBytes are ambiguous. Are implementations required to support both the Counter32 and the Counter64 versions, even though they count the same thing? SNMPv1 is NOT RECOMMENDED. Why do we need a Counter32 object? Are there discointinuity situations? See mib guidelines section 4.6.1.2. 18) gmplsTunnelErrorLastErrorType needs wordsmithing. 19) What happens to gmplsTunnelErrorLastTime if sysUptime resets? 20) This MIB module has many objects that are ignored of other objects has "noError" or whatever. Do these objects EXIST if no error, and if so what value should they default to? E.g., does the SNMP agent report "noSuchObject" or an object value of zero? In SNMP, it is generally preferred to have an object not exist, than to provide a default value which might be misleading. If a managemret application cannot distinguish which is the case, then the application is likely to ignore the object and its value because it not be useful, and thus it doesn't belong in a standard mib module. 21) gmplsTunnelErrorreporter - How does a management application know whether the address represents the reporting node or the associated resource? There should probably be a ReporterType to make this distinction. 22) How does a manager know which implementation's set of error codes are in use? In SNMP, we usually provide a mechanism to identify the enterprise that defines the additional values, otherwise this can lead to interoperability problems. 23) what is the maximum length of the gmplsTunnelErrorTLVs OCTET STRING? 24) gmplsTunnelErrorHelpString uses DisplayString, and thus does not support internationalized text. It should support UTF8. See mib review guidelines Appendix B, Note 2. 25) gmplsTunnelDown - only one of mplsTunnelDown or gmplsTunnelDown SHOULD be sent. Can it be standardized WHICH is sent in preference to the other? 26) gmplsTunnelDown - should there be additional rate limiting when a device with lots of tunnels goes down? See entConfigChange in RFC 4133 for an example. 27) The purpose of compliance groups is to standardize expectations about what will be present in a compiant system. This MIB module has a huge number of compliance groups, including many optional groups, permitting many implementations with widely varying levels of support to claim compliance. This strikes me as bad for interoperability. The gmplsTunnelGroup has a rather complex approach. The purpose of compliance statements is to encourage implenentors to provide consistent levels of support, not to define compliance levels to match existing proprietary combinations of levels of support. Definign a group (gmplsTeNotificationGroup) in which "None is mandatory" indicates to me that they shouldn't be in the standard then. 28) "There are a number of management objects defined in these MIB modules ..." This security Considerations should be about the objects in the MIB module in THIS document, not the objects in some other documents. 29) There is a boilerplate for MIB Security Considerations. The text in the boilerplate has been changed here, such that it does not represent the appropriate recommendations concerning VACM and USM. If you feel the text must be changed, then ask for help crafting a correctly wordsmithed alternative. In particular, "VACM and USM MUST be used" is incorrect for a number of reasons. First, VACM and USM may be replaced at some point, and the official SNMPv3 recommendation does not require these specific pieces of SNMPv3 be used, they are only currently mandatory-to-implement. Second, MUST has specific semantics defined in RFC 2119, and this statement seems to use MUST incorrectly. Please use the text from the boilerplate, which was carefully crafted to represent the official IETF position. 30) There are quoted passages in the security considerations that are not present in the security boilerplate. Please use the text from the boilerplate, which was carefully crafted to represent the official IETF position. 31) I think the description in the MODULE-IDENTITY clause for IANA-GMPLS-MIB needs to include the copyright statement. 32) Can anybody request a new value for IANAGmplsLSPEncoding? What rules should IANA follow in assigning new values? Are AnsiEtsiPdh and SdhSonet and Fiber deprecated or obsolete? 33) Can anybody request a new value for IANAGmplsGPid or IANAGmplsAdminStatusFlags? What rules should IANA follow in assigning new values? 34) The references should be checked; at least one reference has no citation. David Harrington dbharrington@comcast.net IETF MIB Doctor |
2005-09-09
|
16 | Bert Wijnen | Copied from another email from MIB Doctor Joan. These are comments that apply to 3 GMPLS MIB documents, so also to this one. --------- General … Copied from another email from MIB Doctor Joan. These are comments that apply to 3 GMPLS MIB documents, so also to this one. --------- 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. |
2005-09-09
|
16 | Bert Wijnen | MIB doctor review by Joan Cucchiara. -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: Friday, September 09, 2005 04:00 To: tnadeau@cisco.com; adrian@olddog.co.uk; ccamp@ops.ietf.org … MIB doctor review by Joan Cucchiara. -----Original Message----- From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] Sent: Friday, September 09, 2005 04:00 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-te-mib-09.txt Hi Tom and Adrian, Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. All 3 docs show a good deal of work. -Joan draft-ietf-ccamp-gmpls-te-mib-09.txt ====================================== Section 1.1 Migration Strategy ------------------------------ 1) Please remove "and OBJECT-IDENTIFIERS" Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] and [GMPLSTCMIB]. Section 5.4 gmplsTunnelCHoptable --------------------------------- 2) Please capitalize Table in the Section's title. Section 8. GMPLS Traffic Engineering MIB Module ----------------------------------------------- smicngPRO gives the following: W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should have SIZE specified W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is identical W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is identical W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is identical W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax is identical W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax is identical Disconnect of numbering in the Conformance Section \-3 gmplsTeConformance \-v-1 gmplsTeGroups | \-v-1 gmplsTunnelGroup 2 is missing | |-3 gmplsTunnelSignaledGroup | |-4 gmplsTunnelScalarGroup | |-5 gmplsTunnelIsIntfcGroup | |-6 gmplsTunnelIsNotIntfcGroup | |-7 gmplsTunnelOptionalGroup | \-8 gmplsTeNotificationGroup 3) gmplsTunnelsConfigured OBJECT-TYPE SYNTAX Unsigned32 SYNTAX should be Gauge32 4) gmplsTunnelsActive OBJECT-TYPE SYNTAX Unsigned32 SYNTAX should be Gauge32 5) gmplsTunnelTable DESCRIPTION "The row status of an entry in this table is controlled by mplsTunnelRowStatus in the corresponding entry in mplsTunnelTable. That is, it is not permitted to create a row in this table, nor to modify an existing row, when the corresponding mplsTunnelRowStatus has value active(1).... The sentence beginning with "That is," is awkward. Could you say something like: A row in this table is created when a row is created in the mplsTunnelTable. Entries in this table cannot be modified when the corresponding mplsTunnelRowStatus has a value of active(1). The exception.... Please also update this other places in this MIB (e.g gmplsTunnelHopTable). 6) gmplsTunnelEntry DESCRIPTION: "... An entry can be created by a network administrator or by an SNMP agent as instructed by a signaling protocol." Please change the above to: "An entry can be created by a network administrator via SNMP SET commands, or by the network management entity as instructed by a signaling protocol." 7) gmplsTunnelUnnumIf What IF-MIB object are referring to in the DESCRIPTION? Could you state which object in the description? 8) gmplsTunnelAttributes Could you specify what happens when the bit is set (i.e. 1) vs. 0? 9) gmplsTunnelLSPEncoding The DESCRIPTION states: ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling is not in use. Some objects in this MIB module may be of use for MPLS signaling extensions that do not use GMPLS signaling. By setting this object to 'tunnelLspNotGmpls', an application may indicate that only those objects meaningful in MPLS should be examined.... I believe that such objects should be put in to an MPLS MIB module and not included in this GMPLS MIB module. This is also true with the gmplsTunnelErrorTable. 10) gmplsTunnelLinkProtection Same comment as with gmplsTunnelAttributes. 11) gmplsTunnelPathComp DESCRIPTION states: This object deprecates mplsTunnelHopEntryPathComp." The term "deprecates" is loaded. Perhaps something like, this object takes precedence over mplsTunnelHopEntryPathComp. In other words, for GMPLS tunnels, the value of mplsTunnelHopEntryPathComp is meaningless. 12) gmplsTunnelUpNotRecip Need to use InetAddressType and InetAddress. IpAddress is not used in MIBs anymore. Please be sure to support both v4 and v6 IP address Types. If you can't support v6 for some reason, that should be stated clearly. Please change the name of this object to: gmplsTunnelUpstreamRecipientForNotify 13) gmplsTunnelDownNotRecip Same comment as above wrt to IpAddress. Please change the name to gmplsTunnelDownstreamRecipientForNotify 14) gmplsTunnelAdminStatusFlags (please see comments regarding the name of this TC and make adjustments to the name and DESCRIPTION of this object as appropriate). 15) gmplsTunnelExtraParamsPtr OBJECT-TYPE This object does not seem appropriate for this MIB. It would seem an enterprise MIB could do something like this (and possibly not use a RowPointer) so please explain what the intention is. 16) gmplsTunnelHopTable OBJECT-TYPE The storage type for an entry in this table is inherited from mplsTunnelHopStorageType in the corresponding entry in mplsTunnelHopTable. Please change to: The storage type for this entry is given by the value of mplsTunnelHopStorageType in the corresponding entry in the mplsTunnelHopTable. 17) gmplsTunnelHopExpLabel OBJECT-TYPE DESCRIPTION "If gmplsTunnelHopLabelStatuses object indicates that a forward label is present and gmplsTunnelHopExpLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in object encoded within a 32-bit integer." Think the last part of this sentence is awkward: ...to use on this hop is represented by the value of this object. 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr Need to add the word "Forward" in here as in gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr That way it will be consistent with the Reverse counterparts. 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpRvrsLabelPtr Please change Rvrs to Reverse. 20) gmplsTunnelHopLabelStatuses and gmplsTunnelARHopLabelStatuses Please change Statuses to State. 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr Need to add the word "Forward" in here as in gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr Please change Rvrs to Reverse 23) gmplsTunnelARHopProtection OBJECT-TYPE Please add what the BIT set (i.e. 1) vs. 0 means in the DESCRIPTION. 24) gmplsTunnelCHopLabelTable objects Similar comments regarding the objects in this table to those above with regard to naming conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the details, please refer to above comments on the prior 2 tables. 25) gmplsTunnelReversePerfTable Please add to the DESCRIPTION how a user knows if this is a bidirectional tunnel (i.e. what object or objects in the gmplsTunnelTable need to have what values?). 26) gmplsTunnelReversePerfPackets Does this object represent the 32-bit value of the least significant part of the 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? 27) gmplsTunnelReversePerfBytes Does this object represent the 32-bit value of the least significant part of the 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? 28) gmplsTunnelErrorTable OBJECT-TYPE Since this table applies to MPLS, it should be put in a separate MIB module which is MPLS specific. The prefix of gmpls could be confusing. 29) gmplsTunnelErrorTLVs OBJECT-TYPE Need to add a variable size to this string. When the string size is 0 that would indicate that no TLVs are present, so the DESCRIPTION should be modified to reflect this. 30) gmplsTunnelErrorHelpString OBJECT-TYPE SYNTAX DisplayString DisplayString is not used in newer MIBs because it does not meet internationalization standards, better to use SnmpAdminString or something which meets internationalization standards. 31) Compliance Please move some of the following comment in the DESCRIPTION of gmplsTeModuleFullCompliance -- The mandatory group has to be implemented by all LSRs that -- originate, terminate or act as transit for TE-LSPs/tunnels. -- In addition, depending on the type of tunnels supported, other -- groups become mandatory as explained below. 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance and it probably should. Section 11.2.1. IANA-GMPLS-MIB Definition ----------------------------------------- 33) Please change the name of this MIB to IANA-GMPLS-TC-MIB and instead of: ianaGmpls MODULE-IDENTITY please use: ianaGmplsTcMIB MODULE-IDENTITY 34) Please add the following to the DESCRIPTION: "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 35) Please change GMPLS-TE-MIB's to GMPLS-TE-STD-MIB's [RFCXXX] (RFC-Editor please fill in the XXX based on the RFC number for draft-ietf-ccamp-gmpls-te-mib and remove this note) in the DESCRIPTION clauses of ALL TCs. 36) Please change the name IANAGmplsLSPEncoding to IANAGmplsLSPEncodingType. (more closely matches what's on IANA's website now) 37) Please change the name IANAGmplsGPid to IANAGmplsGeneralizedPid 38) I believe that the TC IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION should be put in the GMPLS-TC-STD-MIB or should just remain in the GMPLS-TE-STD-MIB. The reason is that this is not an assigned numbers list maintained by IANA, so should not be in the IANA GMPLS MIB. If I am incorrect about this please let me know, but I didn't see an IANA maintained Administrative Status Information enum. Additionally, this should be renamed to GmplsAdminStatusInformation which more closely matches rfc3471. 39) Several comments on the SYNTAX clause: 40a) smicngPRO gives the error E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS must be in contiguous positions SYNTAX BITS { delInProgress (0), adminDown (1), testing (2), reflect (31) } RFC2578 specifies that BITS should be contiguous (although there are exceptions to this, but this object does not seem to be an exception). Could delInProgress, be renamed to deleteInProgress ? Could adminDown be renamed to administrativelyDown? These names more closely match 3471. 40b) Please put in the specific section number on this reference (section 8?). -- the end -- |
2005-09-09
|
16 | Bert Wijnen | State Change Notice email list have been change to kireeti@juniper.net, adrian@olddog.co.uk; jcucchiara@mindspring.com; bwijnen@lucent.com from kireeti@juniper.net, adrian@olddog.co.uk |
2005-09-06
|
16 | Alex Zinin | State Changes to AD Evaluation from Publication Requested by Alex Zinin |
2005-06-03
|
16 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2005-06-02
|
09 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-09.txt |
2005-02-11
|
08 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-08.txt |
2005-02-10
|
07 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-07.txt |
2004-10-08
|
06 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-06.txt |
2004-06-03
|
05 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-05.txt |
2004-02-16
|
04 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-04.txt |
2003-11-18
|
03 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-03.txt |
2003-08-29
|
01 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-01.txt |
2002-06-28
|
00 | (System) | New version available: draft-ietf-ccamp-gmpls-te-mib-00.txt |