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

["David B Harrington" <dbharrington@comcast.net>]

Hi Bert,

I chose to not commit to being the MIB Doictor for these documents
because I have a lot of editing tasks (and some chair/shepherding
tasks) on my plate already, and limited knowledge of the managed
technology. 

I chose to review the documents because I wanted a better
understanding of GMPLS for other reasons (i.e. I was on a flight to a
job interview with a company that supports GMPLS), and reviewing the
MIB modules was one way to get a quick overview of the anticipated
management issues related to (G)MPLS. (oh, and the article by Thomas
in IEEE Communications was helpful as well).

Since I was going to review the MIB modules anyway, I made some notes
about what I saw and sent them in. I also have some notes about the
third MIB module (LSR?) that I haven't posted yet. If you'd prefer I
can send them to Joan and let her decide which to forward to the WG. I
think the notes on the LSR MIB are similar to those for the TE MIB.

Joan, welcome to the team!

dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
> Sent: Thursday, September 08, 2005 3:52 AM
> To: dbharrington@comcast.net
> Cc: Joan Cucchiara (E-mail); Mreview (E-mail)
> Subject: RE: Draft-ietf-ccamp-gmpls-te-mib-09.txt
> 
> 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
> >  
> > 
> > 
>