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

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

Thanks for explaining Dave.
I am not mad or angry (as it may have looked like
after re-reading my own message). More eyes are always
good, and I believe I have seen that you and Loan have 
found different things to check and verify. So that is goodness.

The only bad part is is that we should try to co-ordinate better
so that we can get all MIB documents reviewed appropriately.

And pls do not trow away the notes about the 3rd module.
Either send them directly or coordinate with Joan. Either way is
fine by me.

Thanks all!

Bert

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of David B Harrington
> Sent: Thursday, September 08, 2005 16:12
> To: 'Wijnen, Bert (Bert)'
> Cc: 'Joan Cucchiara (E-mail)'; 'Mreview (E-mail)'
> Subject: RE: Draft-ietf-ccamp-gmpls-te-mib-09.txt
> 
> 
> 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
> > >  
> > > 
> > > 
> > 
> 
> 
>