[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbRealmName - object SYNTAX - AD Comment 31
Same proposal applies to:
pktcMtaDevProvKerbRealmName
pktcMtaDevKerberosRealm
pktcMtaDevRealmName
Jean-François
> -----Original Message-----
> From: Jean-Francois Mule
> Sent: Thursday, September 08, 2005 7:23 AM
> To: 'Randy Presuhn'; Bert Wijnen (bwijnen at lucent.com); Ipcdn (E-mail)
> Cc: Eugene Nechamkin (enechamkin at broadcom.com)
> Subject: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbRealmName -
> object SYNTAX - AD Comment 31
>
> 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:randy_presuhn at mindspring.com]
> > Sent: Tuesday, February 22, 2005 3:17 PM
> > To: Ipcdn (E-mail)
> > Subject: Re: [ipcdn] pktcMtaDevRealmName
> >
> > Hi -
> >
> > > From: "Jean-Francois Mule" <jf.mule at cablelabs.com>
> > > To: "Randy Presuhn" <randy_presuhn at mindspring.com>; "Ipcdn (E-
> mail)"
> > <ipcdn at ietf.org>
> > > 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
> > IPCDN at ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipcdn
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn