[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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