[ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbRealmName - object SYNTAX - AD Comment 31

["Jean-Francois Mule" <[e-mail]>]

Randy, Bert and all,

Looking for any ack/nack to close on this one.

To recap, Bert and Randy had raised the following question: 

----
# Comment 31
> - I wonder if for an object like pktcMtaDevProvKerbRealmName 
>   it is wise to use SnmpAdminString while the content MUST be
>   uppercase ASCII ??

Proposed resolution:
The Kerberos protocol (RFC1510, RFC4120) defines the RealmName to be
of ASN.1 type "GeneralString". This type has numerous interop problems
(RFC4120, section 5.2.1).
The newer version of Kerberos protocol (RFC4120) requires that the
RealmName follows a new type "KerberosString" which effectively
constrains the value of the GeneralString to only contain characters
in IA5String.
     KerberosString  ::= GeneralString (IA5String)
The "IA5String" type is defined in ISO/IEC646:1991 and also known
as US-ASCII. 
Hence, based on the above analysis, "DisplayString" and
"SnmpAdminString" seem to be the closest mapping in SMI. The
co-authors are shared on whether to change the current SYNTAX from
SnmpAdminstring to DisplayString. 

Any input on this?
----

In addition, Eugene provided additional comments: 
per description of the SnmpAdmninString TC:
                 For information encoded in 7-bit US-ASCII,
                 the UTF-8 encoding is identical to the
                 US-ASCII encoding.

and I would like to underline one paragraph of the newest Kerberos RFC, section 5.2.1.
 " Future revisions to this protocol will almost certainly allow for a
   more interoperable representation of principal names, probably
   including UTF8String."
             ^^^^^^^^^^ 

==> Our preference is to not change the syntax, leave it SnmpAdminString but add pointers to the newest Kerberos RFC.


Current MIB object def:
pktcMtaDevProvKerbRealmName  OBJECT-TYPE  
       SYNTAX      SnmpAdminString (SIZE(1..255))  
       MAX-ACCESS  read-only  
       STATUS      current  
       DESCRIPTION  
           " 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."  
       REFERENCE 
           " PacketCable MTA Device Provisioning Specification; 
             RFC 3495, DHCP Option for CableLabs Client Configuration." 
       ::= { pktcMtaDevServer 15 }  
    
Proposed New MIB object def:
pktcMtaDevProvKerbRealmName  OBJECT-TYPE  
       SYNTAX      SnmpAdminString (SIZE(1..255))  
       MAX-ACCESS  read-only  
       STATUS      current  
       DESCRIPTION  
           " 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. RFC 4120 sections
             5.2.1 and 6.1 define Kerberos types and naming constraints 
             for Kerberos Realm Names.

             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."  
       REFERENCE 
           " PacketCable MTA Device Provisioning Specification; 
             RFC 3495, DHCP Option for CableLabs Client Configuration.
             RFC 4120, The Kerberos Network Authentication Service (V5)" 
       ::= { pktcMtaDevServer 15 }  
    

Unless we hear from anyone, this will be in draft07.
Jean-François

 


 

> -----Original Message-----
> From: Randy Presuhn [mailto:[e-mail]]
> Sent: Tuesday, February 22, 2005 3:17 PM
> To: Ipcdn (E-mail)
> Subject: Re: [ipcdn] pktcMtaDevRealmName
> 
> Hi -
> 
> > From: "Jean-Francois Mule" <[e-mail]>
> > To: "Randy Presuhn" <[e-mail]>; "Ipcdn (E-mail)"
> <[e-mail]>
> > Sent: Thursday, February 17, 2005 4:51 PM
> > Subject: RE: [ipcdn] pktcMtaDevRealmName
> ...
> > > I think the use of SnmpAdminString for pktcMtaDevRealmName
> > > might need some more thought.  The language about "all capitals"
> > > and search operations using upper-case ASCII doesn't mesh
> > > too well with SnmpAdminString.
> > >
> > > Whether it makes any sense at all will depend on
> > > whether Kerberos will ever permit realm names which are
> > > not upper-case ASCII.
> >
> >   How about changing the syntax to DisplayString?
> >   This would address your point and align the mib object syntax with
> the kerberos type.
> ...
> 
> This would be OK with me.  It wouldn't hurt to add some text to the
> BEHAVIOUR explaining that the kerberos type is limited to ASCII,
> so that well-meaning folks who want to help the cause of
> internationalization
> aren't led astray, and so that other MIB reviewers understand why it
> isn't SnmpAdminString.
> 
> Randy
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ipcdn



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