RE: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbRealmName - object SYNTAX - AD Comment 31
"Jean-Francois Mule" <jf.mule@cablelabs.com> Thu, 08 September 2005 13:23 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMMz-00019s-M1; Thu, 08 Sep 2005 09:23:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMMw-00019n-SV for ipcdn@megatron.ietf.org; Thu, 08 Sep 2005 09:23:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19042 for <ipcdn@ietf.org>; Thu, 8 Sep 2005 09:23:08 -0400 (EDT)
Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDMQK-0003jV-Eo for ipcdn@ietf.org; Thu, 08 Sep 2005 09:26:40 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j88DN05B000402; Thu, 8 Sep 2005 07:23:00 -0600 (MDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbRealmName - object SYNTAX - AD Comment 31
Date: Thu, 08 Sep 2005 07:23:00 -0600
Message-ID: <CD6CE349CFD30D40BF5E13B3E0D84804F2F60A@srvxchg.cablelabs.com>
Thread-Topic: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbRealmName - object SYNTAX - AD Comment 31
Thread-Index: AcUaHjA3TVembRd7SZi6Xmx0B63FgCaVufywAADXFbA=
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>, bwijnen@lucent.com, "Ipcdn (E-mail)" <ipcdn@ietf.org>
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Content-Transfer-Encoding: quoted-printable
Cc: enechamkin@broadcom.com
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
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@lucent.com) Ipcdn (E-mail) > Cc: Eugene Nechamkin (enechamkin@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@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@cablelabs.com> > > > To: "Randy Presuhn" <randy_presuhn@mindspring.com>; "Ipcdn (E- > mail)" > > <ipcdn@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@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbRealm… Jean-Francois Mule
- RE: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbR… Jean-Francois Mule
- Re: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbR… Thomas Anders
- Re: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbR… Thomas Anders
- RE: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbR… Eugene Nechamkin
- RE: [ipcdn] MTA MIB draft06 - pktcMtaDevProvKerbR… Eugene Nechamkin