Subject: [ipcdn] MTA MIB draft 04 comments

From: "Eugene Nechamkin" <[email-masked]>
Date: Fri, 30 Jul 2004 14:49:06 -0700

For everybody's consideration, here are the following comments on the
MTA MIB draft-04 recently published:

1. pktcMtaDevProvKerbRealmName
 
Having in mind the recently introduced secure/non-secure provisioning
Flows and the fact that the pktcMtaDevRealmTable is not indexed by the
pktcMtaDevProvKerbRealmName (as it is in the PacketCable), and also some
missing description of the MTA functionality in respect to the
RealmTable content, the existing DESCRIPTION of the object seems to be
not exactly adequate:
 
           " This object contains the name of the associated 
             provisioning Kerberos realm acquired during the MTA4 
             provisioning step (DHCP Ack) for SNMPv3 provisioning. 
             This object value is used as an index into the 
             pktcMtaDevRealmTable. The upper case ASCII representation 
             of the associated Kerberos realm name MUST be used by both 
             the Manager (SNMP entity) and the MTA. 
             The Kerberos realm name for the Provisioning Server is 
             supplied to the MTA via DHCP option code 122 sub-option 6 
             as defined in RFC 3495. In secure SNMP provisioning mode 
             the value of the Kerberos realm name for the Provisioning 
             Server supplied in the MTA configuration file must match 
             the value supplied in the DHCP option code 122  
             sub-option 6. Otherwise the value of this object must  
             contain the value supplied in DHCP Option 122  
             sub-option 6."  

I propose the following DESCRIPTION clause:
 
           " This object contains the value indicating which
Provisioning Mode 
             the MTA should use for its provisioning - SNMP secure or
SNMP non-secure.
             The value of this object is delivered to the MTA in the
DHCP option code 
             122 sub-option 6 during the DHCP-ACK provisioning step 
             (as defined in RFC 3495). 
             
             In the secure SNMP Provisioning Mode, the object contains
the upper case 
             ASCII representation of the name of the associated
provisioning 
             Kerberos realm for the SNMPv3 Provisioning. The MTA MUST
create, in 
             the pktcMtaDevRealmTable, the conceptual row corresponding 
             to the upper case ASCII representation of the value of this
object. 
             The MTA MUST make sure that the value of the Kerberos realm
name 
             for the Provisioning Server supplied in the MTA
configuration file matches 
             the value supplied in the DHCP option code 122  sub-option
6. 
             The MTA MUST use the Realm Organization Name of the SNMPv3
Provisioning 
             Kerberos Realm supplied in the configuration file, in the 
             new row created for the SNMPv3 Provisioning Kerberos Realm.
             
             In the non-secure SNMP Provisioning Mode, this object
contains the upper 
             case ASCII representation of the value delivered to the MTA
in the DHCP 
             option code 122 sub-option 6."

2. pktcMtaDevCmsFqdn
 
The DESCRIPTION clause of the object is as follows:
 
           " This object specifies the CMS FQDN. The MTA must  
             prohibit the instantiation of any two rows with identical  
             FQDNs. The MTA must also verify that any search and/or  
             comparison operation involving a CMS FQDN is case  
             insensitive." 

This description is not consistent with the the description of the
similar object - pktcMtaDevRealmName in the pktcMtaDevRealmTable, and I
propose the following DESCRIPTION clause which, I think, would better
describe the funtionality corresponding to the pktcMtaDevCmsFqdn object:
 
           " This object specifies the CMS FQDN in all  capitals. 
             The MTA MUST prohibit the instantiation of any 
             two rows with identical FQDNs. The MTA MUST  
             also verify that any search and/or comparison operations
involving 
             a CMS FQDN is done using the upper case ASCII  
             representation of the characters."  

Eugene Nechamkin,

Broadcom Corp.

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn