MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB)
draft-ietf-mpls-tp-te-mib-11

I realize the security considerations might get updated based on comments from Stephen/Benoit, but wanted to ask about this in case this text stays in the document:

"When MIB is used to configure ICC_Operator_ID, as specified in
   [RFC6370], it should be considered sensitive operation. Hence proper
   protection should be taken to allow configuration via SET operation
   in order to ensure its purpose of providing globally unique MPLS-TP
   identifiers."

This is a little confusing for a number of reasons. ICC_Operator_ID does not appear to be specified in RFC 6370, but rather in RFC 6923. Global_ID is specified in RFC 6370. Was this text meant to apply to both?

Also, it's not clear why the configuration of ICC_Operator_ID "should be considered a sensitive operation." Is it because failing to use a unique ICC_Operator_ID can cause operational problems (as described in RFC 6370 for Global_ID)? Isn't uniqueness guaranteed in the way that both ICC_Operator_IDs and Global_IDs themselves are generated, such that the only real risk with the MIB is that these IDs would be somehow transformed from their originals to no longer be unique? Or are they sensitive for some other reason not related to uniqueness?

I'm confident that the responsible AD will take care of the Security Guidelines for IETF MIB Modules (http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security) in the next draft version.

I know that this MIB was the source of much debate. Thanks for this paragraph:

At the time of writing, SNMP SET is no longer recommended as a way to
configure MPLS networks as was described in [RFC3812].  However, since
the MIB modules specified in this document extend and are intended to
work in parallel with the MIB modules for MPLS specified in [RFC3812],
certain objects defined here are specified with MAX-ACCESS of read-write
or read-create so that specifications of the base tables in [RFC3812]
and the extensions in this document are consistent. Although the
examples described in Section 9 specify means to configure MPLS-TP
tunnels in a similar way to the examples in [RFC3812], this should be
seen as indicating how the MIB values would be returned in the specified
circumstances having been configured by alternative means.

6.1 and 10: Maybe this is crystal clear in the MPLS and SNMP communities, and if it is you can ignore this comment, but "alphabetic character" is ambiguous. You probably mean "ASCII alphabetic character", and you could simply make the substitution throughout if you like (and reference RFC 20 is you were feeling especially pedantic), but if there is no chance for misinterpretation, I certainly won't stand on ceremony.

The security considerations doesn't appear to match the
guidance for MIBs. ([1] that may possibly still have an
update to come, not sure.) I think Benoit is onto this as
well so I'll leave it to him as he knows MIBs better.

   [1] http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security