RE: Draft-ietf-ccamp-gmpls-te-mib-09.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Dave, 

I see that this week you took some initiative to review the
GMPLS MIB documents.

What a pitty that you did not first check with me, because I
had Joan reviewing them (and depending how this was gonna work
out for her and us, she may become a team member of the MIB 
doctors). So now we have 2 reviews. Not bad in iteself, but 
a bit of a duplication, and that while I have many other MIBs for
review. Why did you not react to my repeated "plea for reviews
during the last 2 months"? Why did you not let me know
before you started, so I could have told you work was being done?

The reason I keep asking on the mreview list is to try and co-ordinate
and to try and avoid duplication.

Oh well...

Nevertheless, the reviews are always helpful.

Joan, pls continue submitting your review to the authors and the
WG.

Bert

> -----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
>  
> 
>