Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS
draft-ietf-ccamp-gmpls-ted-mib-15

-- Section 8 --
   There is a number of management objects defined in this MIB module 
   that has a MAX-ACCESS clause of read-write.

While technically "a number of Xes" is singular, in actual usage that's very odd English, and seems wrong.  The RFC Editor can fix this, of course, but if you're editing the document anyway you might change it to plural usage by making it "There are" and "that have".  If that bothers you, you can also change "a number of" to "several", and you'll be correct both in common usage and technically.

No objections to the publication of this document. I'm actually in favor of it.
Dan Romascanu, in his OPS-DIR brought a couple of good points, which I support.
At the very minimum, the point 4 should be addressed

1. In Section 2: 

>  This MIB module should be used in conjunction with OSPFv2 MIB, OSPF 
   v3 MIB and ISIS MIB as well as other MIBs defined in [RFC3812], 
   [RFC3813], [RFC4802], [RFC4803] for the management of MPLS/GMPLS 
   based traffic engineering information.  


It would have been useful to develop this a section that explains the
relation of the TED-MIB with other MIB modules that model MPLS-TE and
GMPLS devices. Are all these MIB modules required on the same device at
the same time? Being more precise here would help implementers and
switch designers in planning the resources required to implement and run
this MIB module. 

2. Runing id-nits results in a number of warnings related to unused
references: 

  == Unused Reference: 'RFC2328' is defined on line 1552, but no
explicit
     reference was found in the text
     '[RFC2328] J. Moy, " OSPF version2 ", RFC2328, April 1998....'

  == Unused Reference: 'RFC4001' is defined on line 1566, but no
explicit
     reference was found in the text
     '[RFC4001]  M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
"...'

  == Unused Reference: 'RFC4801' is defined on line 1579, but no
explicit
     reference was found in the text
     '[RFC4801] T. D. Nadeau and A. Farrel, Ed., "Definitions of Textual
C...'

  == Unused Reference: 'RFC5340' is defined on line 1587, but no
explicit
     reference was found in the text
     '[RFC5340] R. Coltun, D. Ferguson, J. Moy, A.Lindem " OSPF for
IPv6",...'

  == Unused Reference: 'RFC6340' is defined on line 1593, but no
explicit
     reference was found in the text
     '[RFC6340] R. Presuhn, "Textual Conventions for the Representation
of...'

  == Unused Reference: 'ISO10589' is defined on line 1596, but no
explicit
     reference was found in the text
     '[ISO10589] ISO 10589, "Intermediate system to Intermediate system
ro...'

  == Unused Reference: 'RFC4220' is defined on line 1625, but no
explicit
     reference was found in the text
     '[RFC4220] M. Dubuc, T. D. Nadeau and J. Lang, " Traffic
Engineering...'
 
Actually the references are used, but they appear in the DESCRIPTION or
REFERENCE clauses in the MIB module, and in a format (no brakets) that
makes them to pass undetected by id-nits. It would be useful to group at
lease the references that contain MIB modules in a short section prior
to the MIB module, so that implmenters and operators deploying the MIB
have an easy access to the documents that indicate what MIB modules need
to be compiled or loaded together with the TED-MIB. Add to these RFC4802
mentioned in the IMPORTS.  

3. The example provided in section 6 is ipv4 only. It would be useful to
add an ipv6 example. 

4. Expanding the example to detail what would be a typical or
recommended operational flow used by an operator when working with the
MIB module would have been useful. How is the MIB modules supposed to be
used. What an operator can do with this MIB module? Download the
topology? How often? Verify that the switch was properly configured and
debug problems in the network using the objects in the tedTable,
tedRemoteTable and tedSwCapTable? What is the functionality and how can
be used the tedSrlgTable? 

5. Notifications throttling is discussed and implemented and this is a
good thing. However, there is a potential issue here. The notifications
tedEntryCreated and tedENtryDeleted are supposed to be sent when an
entry was created or deleted in the TED table. However, the writeable
object that sets the notifications rate is set by default at 1
notification/minute, a value that many operators will leave as is. This
means that whenever more than one row is created or deleted in one
minute, just one notification will be sent. I think that an explicit
warning should be included about this situation, so that operators are
aware that in order to make sure that all changes were detected when a
notification was received, the whole table needs to be traversed. 

6. There is no indication or hints to the operators about using the
objects in this MIB module for faults management or alerting about the
status of the network. For example can the tedUnreservedBandwidth per
priority objects be used to detect problems in capacity or in
configuration?

Isn't the following missing from the security considerations (penultimate para) because it's part of the generic MIB Dr. boilerplate:

   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].

The *MaxRate settings (on p23) are read-write and allow up to
2^32-1 notifications per second in theory. Should you note that
implementations MAY or SHOULD have a limit that they impose on
these values so that if someone tries to set them to >LIMIT, an
error results? 

If you wanted to say something about this, that could be done 
on p23 where they're defined or in section 8 I guess.

If this is just some generic MIB thing that's already handled 
everywhere, then sorry for bothering you with it:-)

I am prepared to believe that Adrian has been thorough with this draft.