ipcdn MTA MIB: update of description clauses when secure SNMPv3 is not used

Folks,

Some operators are using SNMPv2c for MTA device management (and will
continue to do so for some period of time). We've been discussing the
impact that the unsecure SNMPv2 mgmt has on the MTA MIB with the
PacketCable OSS vendor team. I would like to share some of our thoughts
and our suggestions to make sure that we are doing the right thing and
to that those proposed changes are sound and can later be reflected in
the IETF ID mtamib draft 04.

Note that the IETF ID mtamib draft 03 does have a fairly detailed
security consideration section and recommends the use of secure SNMPv3.
Yet, the MIB module and its objects definitions assume v3 only and we've
found that the implementers feel that there should be clear guidance
when v2c mgmt is used. Some MIB objects don't mean anything when v2 is
used (these objects are related to the key mgmt for the security
relationship with the SNMP entity or prov server
(pktcMtaDevProvSolicitedKeyTimeout and alike), or to key/hash values for
the config file that are passed in secure v3 mode when the MTA
enrollment mechanism is used (pktcMtaDevProvConfigKey), etc. 

At this point, our suggestions are as follows:
 - maintain the compliance statements as-is, all MTAs will support
SNMPv3 and when v3 is used, all the objects as defined in draft 03 make
sense (at least, we think they do);
 - define in our PacketCable MIB framework the mib views, access right
for v2 mgmt,
 - for the specific objects that do not mean anything in v2, enhance the
DESCRIPTION clause to state what the device must do if v2 mgmt is used,
that is, specify the MTA's behavior when receiving SNMPv2 SET & GET
operations on those v3-specific objects.
 - Suggestions:
   add something like this in the impacted objects:
   for pktcMtaDevProvConfigKey:
             This object should not be used in non secure SNMPv3 modes.
             In non secure SNMPv3 modes, the MTA MUST return an 
             'inconsistentValue' in response to SNMP SET operations, 
             and the MTA MUST return a 'genErr' error in response to 
             SNMP GET operations."
   for pktcMtaDevProvConfigHash:
             When the MTA SNMP Enrollment mechanism is not in use, the
             hash value is provided in the configuration file itself 
             and it is also calculated by the MTA. This object value
             MUST represent the hash value calculated by the MTA.
             When the MTA SNMP Enrollment mechanism is not in use, the
             MTA must reject all SNMP SET operations on this object and
             return an 'inconsistentValue' error.
   These are just 2 examples but they basically say:
     - if unsecure v2 is used, SNMP SET on the object =>
'inconsistentValue', SNMP GET => 'genErr'
   This seems to be consistent with RFC 3416 (one could argue that
'noAccess' could be returned as well).

Question:
Is this the proper way to do this to provide some info in the MIB module
as our MTA implementers have been asking for? We plan on adding some
more details on the VACM model (MIB views, access rights and object
trees that cannot be accessed without the proper security policies.

Thanks in advance for any input on this,
Jean-Francois