From mailman-bounces@ietf.org Wed Dec 1 09:34:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03252 for ; Wed, 1 Dec 2004 09:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSid-0006Gf-Jw for entmib-archive@lists.ietf.org; Wed, 01 Dec 2004 06:32:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: entmib-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:52:33 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for entmib-archive@lists.ietf.org: List Password // URL ---- -------- entmib@ietf.org CNIo https://www1.ietf.org/mailman/options/entmib/entmib-archive%40lists.ietf.org From entmib-bounces@ietf.org Wed Dec 1 13:46:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08747 for ; Wed, 1 Dec 2004 13:46:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYll-0003SN-H8; Wed, 01 Dec 2004 13:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZY9P-0004Th-TY for entmib@megatron.ietf.org; Wed, 01 Dec 2004 12:20:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28653 for ; Wed, 1 Dec 2004 12:20:21 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYEb-0005Db-MZ for entmib@ietf.org; Wed, 01 Dec 2004 12:25:56 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2004 09:19:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iB1HJbRR005055; Wed, 1 Dec 2004 09:19:38 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-793.cisco.com [10.21.83.24]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBN13385; Wed, 1 Dec 2004 09:16:06 -0800 (PST) Message-Id: <4.3.2.7.2.20041201085157.021c5250@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Dec 2004 09:16:05 -0800 To: j.schoenwaelder@iu-bremen.de From: Andy Bierman Subject: Re: [Entmib] Entity MIB v3 In-Reply-To: <20041130214831.GA2524@james> References: <20041130210845.490A135D9@hermes.iu-bremen.de> <20041130185803.GB2231@james> <20041130210845.490A135D9@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "'Margaret Wasserman'" , entmib@ietf.org, David B Harrington , kaj@research.telcordia.com X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 01:48 PM 11/30/2004, Juergen Schoenwaelder wrote: >On Tue, Nov 30, 2004 at 04:08:36PM -0500, David B Harrington wrote: > >[...] > >> To clarify my position - entPhysicalUris hasn't been sufficiently >> justified or specified to be included in the entity mib; we should >> eliminate it. > >Now this is a clear statement. I do not agree but that is fine. >It is now time for others to speak up and if I am the clear minority >here because nobody cares, then go ahead and nuke the definition. I don't care that much either way if this object stays, but let's decide already. ********************************************************* Here is what we have in the document now: In 2.12.1 (describes entPhysicalGroup): - entPhysicalUris This object provides additional identification information about the physical entity. This object may be used to encode for example a URI containing a Common Language Equipment Identifier (CLEI) URI [reference TBD] for the managed physical entity. If no additional identification information is known or supported about the physical entity the object is not instantiated. In the MIB: entPhysicalUris OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-write STATUS current DESCRIPTION "This object contains additional identification information about the physical entity. The object contains URIs and therefore the syntax of this object must conform to RFC 2396 [RFC2396] section 2. Multiple URIs may be separated by white space characters." REFERENCE "RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, section 2, August 1998." ::= { entPhysicalEntry 18 } ************************************************************************* Issues: - Reference for CLEI missing - Is zero-length string allowed, instead or as well as not instantiated? - Is only whitespace allowed? - Is preceding or trailing whitespace allowed? - RFC 2396, sec. 2 defines structure of a generic URI. This is a very proprietary object in nature. Not only is the value set proprietary (our normal mode, e.g., sysObjectID), but the even the purpose of the value set is proprietary. Therefore, this is a total placeholder object. The issue is: Is that okay or not? IMO, this object is too vague to be in a standards document. I must admit I was paying attention to NETCONF while this group changed 'Clei' to 'Uris' in the object descriptor, so I don't know the rationale behind the change. I would approve of an entPhysicalCleis object, that contains a list of URIs that each conform to a documented content-specific structure, as well as the generic URI structure. (e.g., a REFERENCE for the CLEI URI format). >/js Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 1 15:58:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23747 for ; Wed, 1 Dec 2004 15:58:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZaJX-0005bf-I3; Wed, 01 Dec 2004 14:38:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZZrY-0007JG-SE for entmib@megatron.ietf.org; Wed, 01 Dec 2004 14:10:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10862 for ; Wed, 1 Dec 2004 14:10:02 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZZwv-0000K2-71 for entmib@ietf.org; Wed, 01 Dec 2004 14:15:38 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB1J1P85019654 for ; Wed, 1 Dec 2004 14:01:25 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB1IvB85014218 for ; Wed, 1 Dec 2004 13:59:56 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [Entmib] Entity MIB v3 Date: Wed, 1 Dec 2004 21:03:25 +0200 Message-ID: Thread-Topic: [Entmib] Entity MIB v3 Thread-Index: AcTW0Hcslu8RaTkGRS2RSZ8QC7JWugBB5+ag From: "Romascanu, Dan \(Dan\)" To: , "Margaret Wasserman" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: entmib@ietf.org, kaj@research.telcordia.com, Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I am confused. Did not the WG decide to proceed with the Definitions of = Entity Manufacturing and URN Managed Objects as an Informational, based = upon Kaj's individual submission = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-tesink-entity-sup= plmib-01.txt?=20 Regards, Dan > -----Original Message----- > From: entmib-bounces@ietf.org=20 > [mailto:entmib-bounces@ietf.org]On Behalf Of Juergen Schoenwaelder > >=20 > Regarding entPhysicalUris: This object was proposed to handle CLIE > codes and other things people may come up with to identify entities. > It would be nice if Kaj Tesink could > start an ID which defines a URI namespace for CLIE codes. While > this might take some time and we do not want to depend on it,=20 > another source of examples might be OID URNs as defined in RFC=20 > 3001, that is something like urn:oid:1.3.6.1.4.1 (I leave it to > your imagination to pick a suitable value for an example). > =20 > > If there is no one who care enough about these objects to do actual=20 > > work to finalize them, perhaps Andy should just leave them=20 > out and we=20 > > can get the Entity MIB update published? >=20 > I would love to see Kaj starting to write up the CLIE code URN spec > since this was the major driving force for this addition. I this > does not happen, then dropping these objects (even though I believe > we now have a viable solution) might be a logical conclusion. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 1 16:26:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26502 for ; Wed, 1 Dec 2004 16:26:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbXv-0002QN-Kw; Wed, 01 Dec 2004 15:57:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZaKl-0006ox-Dm for entmib@megatron.ietf.org; Wed, 01 Dec 2004 14:40:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16554 for ; Wed, 1 Dec 2004 14:40:12 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZaQ8-00021d-To for entmib@ietf.org; Wed, 01 Dec 2004 14:45:49 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iB1JdQcu012222; Wed, 1 Dec 2004 14:39:26 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA26471; Wed, 1 Dec 2004 14:39:24 -0500 (EST) Message-Id: <6.1.2.0.2.20041201135321.03a7dd80@shannon.research.telcordia.com> X-Sender: kaj@shannon.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 01 Dec 2004 14:39:19 -0500 To: entmib@ietf.org From: Kaj Tesink Subject: Re: [Entmib] Entity MIB v3 In-Reply-To: <4.3.2.7.2.20041201085157.021c5250@fedex.cisco.com> References: <20041130210845.490A135D9@hermes.iu-bremen.de> <20041130185803.GB2231@james> <20041130210845.490A135D9@hermes.iu-bremen.de> <4.3.2.7.2.20041201085157.021c5250@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: "'Margaret Wasserman'" , j.schoenwaelder@iu-bremen.de, David B Harrington , Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 12:16 PM 12/1/2004, Andy Bierman wrote: >At 01:48 PM 11/30/2004, Juergen Schoenwaelder wrote: > >On Tue, Nov 30, 2004 at 04:08:36PM -0500, David B Harrington wrote: > > > >[...] > > > >> To clarify my position - entPhysicalUris hasn't been sufficiently > >> justified or specified to be included in the entity mib; we should > >> eliminate it. > > > >Now this is a clear statement. I do not agree but that is fine. > >It is now time for others to speak up and if I am the clear minority > >here because nobody cares, then go ahead and nuke the definition. sorry for being off-line yesterday and delayed reaction. as i was one of the folks asking for this object, let me try to capture where we are and how we got here. the original request was for two objects to reflect the manufacturing date and the CLEI; after discussion that found its way in a supplemental Entity MIB. i believe that sufficient support for these objects was demonstrated but there were several issues on how to reflect and document the objects. the supplemental MIB idea was abandoned since we were recycling the entmib at Proposed anyway. through discussion between Dave P and Juergen S we arrived at the elegant solution of the URI object, allowing multiple URIs; the approach solved multiple concerns and seems future compatible in that it allows things of other URNs to be managed as well. going back to a CLEI-specific object would be fine with me but i thought there were several good arguments in the past on why the URI approach works better. so, let me jump to Andy's practical questions below: >I don't care that much either way if this object stays, >but let's decide already. > >********************************************************* >Here is what we have in the document now: > >In 2.12.1 (describes entPhysicalGroup): > > - entPhysicalUris > This object provides additional identification information about > the physical entity. This object may be used to encode for example > a URI containing a Common Language Equipment Identifier (CLEI) URI > [reference TBD] for the managed physical entity. If no additional > identification information is known or supported about the physical > entity the object is not instantiated. > >In the MIB: > >entPhysicalUris OBJECT-TYPE > SYNTAX OCTET STRING > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object contains additional identification information > about the physical entity. The object contains URIs and > therefore the syntax of this object must conform to RFC 2396 > [RFC2396] section 2. Multiple URIs may be separated by white > space characters." > REFERENCE > "RFC 2396, Uniform Resource Identifiers (URI): Generic > Syntax, section 2, August 1998." > > ::= { entPhysicalEntry 18 } > >************************************************************************* > >Issues: > - Reference for CLEI missing [T1.213] ATIS T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, 2001, www.ansi.org [T1.213a] ATIS T1.213a, Supplement to T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, to correct the representation of the Basic Code in Figure B.1, 2001, www.ansi.org i'm guilty of being slow in publishing the CLEI URN namespace request (will submit the draft tomorrow): Work in progress Tesink, K., Robert H. Fox, Uniform Resource Name (URN) Namespace for the CLEI Code, RFCxxxx, xxxxxx 2004. > - Is zero-length string allowed, instead or as well as > not instantiated? personally i dont like options and would just pick one. i suggested not-instantiated before but no strong pref > - Is only whitespace allowed? as above, i'd just pick one delimiter and stick with it; white space seems to work > - Is preceding or trailing whitespace allowed? i'd argue that good practice shouldnt produce preceding or trailing whitespace but that it shouldnt break things either in this case. > - RFC 2396, sec. 2 defines structure of a generic URI. > This is a very proprietary object in nature. Not only > is the value set proprietary (our normal mode, e.g., > sysObjectID), but the even the purpose of the value set > is proprietary. Therefore, this is a total placeholder object. > The issue is: Is that okay or not? the purpose here is identification (as Juergen pointed out) and not the creation of some kind of an opaque construct. kaj >IMO, this object is too vague to be in a standards document. >I must admit I was paying attention to NETCONF while this >group changed 'Clei' to 'Uris' in the object descriptor, >so I don't know the rationale behind the change. > >I would approve of an entPhysicalCleis object, that contains >a list of URIs that each conform to a documented content-specific >structure, as well as the generic URI structure. (e.g., a REFERENCE >for the CLEI URI format). > > >/js > >Andy _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 1 16:48:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29573 for ; Wed, 1 Dec 2004 16:48:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbgg-0004W8-4i; Wed, 01 Dec 2004 16:06:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbFJ-0003Ya-I8 for entmib@megatron.ietf.org; Wed, 01 Dec 2004 15:38:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21591 for ; Wed, 1 Dec 2004 15:38:38 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZbKg-0003A5-JM for entmib@ietf.org; Wed, 01 Dec 2004 15:44:15 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iB1KSPcu015405; Wed, 1 Dec 2004 15:28:25 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA28587; Wed, 1 Dec 2004 15:28:25 -0500 (EST) Message-Id: <6.1.2.0.2.20041201150450.03aa7ba8@shannon.research.telcordia.com> X-Sender: kaj@shannon.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 01 Dec 2004 15:08:41 -0500 To: "Romascanu, Dan \(Dan\)" From: Kaj Tesink Subject: RE: [Entmib] Entity MIB v3 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Margaret Wasserman , entmib@ietf.org, j.schoenwaelder@iu-bremen.de, Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 02:03 PM 12/1/2004, Romascanu, Dan \(Dan\) wrote: >I am confused. Did not the WG decide to proceed with the Definitions of >Entity Manufacturing and URN Managed Objects as an Informational, based >upon Kaj's individual submission >http://www.ietf.cnri.reston.va.us/internet-drafts/draft-tesink-entity-supplmib-01.txt? > subsequently we changed because the entmib was going to be recycled at proposed anyway so including these two objects in the main spec made more sense. kaj >Regards, > >Dan > > > > > -----Original Message----- > > From: entmib-bounces@ietf.org > > [mailto:entmib-bounces@ietf.org]On Behalf Of Juergen Schoenwaelder > > > > > Regarding entPhysicalUris: This object was proposed to handle CLIE > > codes and other things people may come up with to identify entities. > > It would be nice if Kaj Tesink could > > start an ID which defines a URI namespace for CLIE codes. While > > this might take some time and we do not want to depend on it, > > another source of examples might be OID URNs as defined in RFC > > 3001, that is something like urn:oid:1.3.6.1.4.1 (I leave it to > > your imagination to pick a suitable value for an example). > > > > > If there is no one who care enough about these objects to do actual > > > work to finalize them, perhaps Andy should just leave them > > out and we > > > can get the Entity MIB update published? > > > > I would love to see Kaj starting to write up the CLIE code URN spec > > since this was the major driving force for this addition. I this > > does not happen, then dropping these objects (even though I believe > > we now have a viable solution) might be a logical conclusion. > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 1 16:55:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00303 for ; Wed, 1 Dec 2004 16:55:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbgy-0004wi-Fj; Wed, 01 Dec 2004 16:07:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbP4-0000gc-5N for entmib@megatron.ietf.org; Wed, 01 Dec 2004 15:48:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22412 for ; Wed, 1 Dec 2004 15:48:44 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZbUQ-0003eG-MW for entmib@ietf.org; Wed, 01 Dec 2004 15:54:20 -0500 Received: from [207.31.248.246] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 213072; Wed, 01 Dec 2004 15:42:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 1 Dec 2004 15:48:29 -0500 To: "Romascanu, Dan \(Dan\)" , From: Margaret Wasserman Subject: RE: [Entmib] Entity MIB v3 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: entmib@ietf.org, kaj@research.telcordia.com, Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Hi Dan, It was never in this WG's charter to produce the supplemental MIB. At one point, we had recommended to Kaj that he pursue individual submission of this document, but we have since decided to add the objects to the Entity MIB instead. Margaret At 9:03 PM +0200 12/1/04, Romascanu, Dan \(Dan\) wrote: >I am confused. Did not the WG decide to proceed with the Definitions >of Entity Manufacturing and URN Managed Objects as an Informational, >based upon Kaj's individual submission >http://www.ietf.cnri.reston.va.us/internet-drafts/draft-tesink-entity-supplmib-01.txt? > > >Regards, > >Dan > > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 1 17:02:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01752 for ; Wed, 1 Dec 2004 17:02:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbyi-0000La-2L; Wed, 01 Dec 2004 16:25:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZbXb-0001lh-29 for entmib@megatron.ietf.org; Wed, 01 Dec 2004 15:57:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23645 for ; Wed, 1 Dec 2004 15:57:33 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZbcy-00047p-8i for entmib@ietf.org; Wed, 01 Dec 2004 16:03:09 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB1KtVZ4017161 for ; Wed, 1 Dec 2004 15:55:31 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iB1Ks4Z4015417 for ; Wed, 1 Dec 2004 15:54:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [Entmib] Entity MIB v3 Date: Wed, 1 Dec 2004 22:55:51 +0200 Message-ID: Thread-Topic: [Entmib] Entity MIB v3 Thread-Index: AcTX58b21qy4zBG7RfeTF6Jr199XBgAAAtOA From: "Romascanu, Dan \(Dan\)" To: "Margaret Wasserman" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: entmib@ietf.org, kaj@research.telcordia.com, Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Margaret, I know that the MIB was not in the Charter, and Kaj's work was supposed = to be pursued as an individual submission. I must have missed the point = where we decided to add the objects to the Entity MIB instead (which I = am fine with, btw). When did this happen?=20 Regards, Dan > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: 01 December, 2004 10:48 PM > To: Romascanu, Dan (Dan); j.schoenwaelder@iu-bremen.de > Cc: entmib@ietf.org; kaj@research.telcordia.com; Andy Bierman > Subject: RE: [Entmib] Entity MIB v3 >=20 >=20 >=20 > Hi Dan, >=20 > It was never in this WG's charter to produce the supplemental MIB.=20 > At one point, we had recommended to Kaj that he pursue individual=20 > submission of this document, but we have since decided to add the=20 > objects to the Entity MIB instead. >=20 > Margaret >=20 > At 9:03 PM +0200 12/1/04, Romascanu, Dan \(Dan\) wrote: > >I am confused. Did not the WG decide to proceed with the Definitions=20 > >of Entity Manufacturing and URN Managed Objects as an Informational,=20 > >based upon Kaj's individual submission=20 > >http://www.ietf.cnri.reston.va.us/internet-drafts/draft-tesin k-entity-supplmib-01.txt?=20 > > >Regards, > >Dan > > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 2 06:18:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00571 for ; Thu, 2 Dec 2004 06:18:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZohx-00029L-1e; Thu, 02 Dec 2004 06:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZnSJ-0001P9-Hh for entmib@megatron.ietf.org; Thu, 02 Dec 2004 04:41:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23834 for ; Thu, 2 Dec 2004 04:40:53 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZnXl-00051d-J7 for entmib@ietf.org; Thu, 02 Dec 2004 04:46:36 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iB29eJCk021202 for ; Thu, 2 Dec 2004 03:40:19 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Dec 2004 10:40:18 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505CEF9DF@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Andy Bierman , j.schoenwaelder@iu-bremen.de Subject: RE: [Entmib] Entity MIB v3 Date: Thu, 2 Dec 2004 10:40:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "'Margaret Wasserman'" , entmib@ietf.org, David B Harrington , kaj@research.telcordia.com X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org > entPhysicalUris OBJECT-TYPE > SYNTAX OCTET STRING > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This object contains additional identification information > about the physical entity. The object contains URIs and > therefore the syntax of this object must conform to RFC 2396 > [RFC2396] section 2. Multiple URIs may be separated by white > space characters." > REFERENCE > "RFC 2396, Uniform Resource Identifiers (URI): Generic > Syntax, section 2, August 1998." > ::= { entPhysicalEntry 18 } I do not like citations inside a MIB module, and certainly I do not see why a citation has to be made in above text, it seems redundant to me. If it is needed because this is the only place in the doc that we discuss this reference, then maybe a better methos is: REFERENCE "RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, section 2, August 1998." -- [RFC2396] But probably best is to have some prose outside of the MIB module definition itself and add a citation there. > > ************************************************************** > *********** > > Issues: > - Reference for CLEI missing > - Is zero-length string allowed, instead or as well as > not instantiated? > - Is only whitespace allowed? > - Is preceding or trailing whitespace allowed? > - RFC 2396, sec. 2 defines structure of a generic URI. > This is a very proprietary object in nature. Not only > is the value set proprietary (our normal mode, e.g., > sysObjectID), but the even the purpose of the value set > is proprietary. Therefore, this is a total placeholder object. > The issue is: Is that okay or not? > If we want to use these RFC2396 material, would it not be better to define two TCs, UriTC and UrisTC or some such? I know that if we go this path that it may just introduce more delay, which is not my intention. And so I won't object heavily if we decide to leave a proper set of TC definitions to some other effort outside this WG. > IMO, this object is too vague to be in a standards document. Mmm... rfc2396 is stds track, so why do you think it is too vague? Bert _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 2 23:07:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06876 for ; Thu, 2 Dec 2004 23:07:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca3s8-00076N-Bb; Thu, 02 Dec 2004 22:12:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0dE-0007fP-CR for entmib@megatron.ietf.org; Thu, 02 Dec 2004 18:45:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15513 for ; Thu, 2 Dec 2004 18:45:01 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca0iq-0002nD-NF for entmib@ietf.org; Thu, 02 Dec 2004 18:50:53 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iB2NiRcu022331 for ; Thu, 2 Dec 2004 18:44:27 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.71.37]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA18594 for ; Thu, 2 Dec 2004 18:44:27 -0500 (EST) Message-Id: <6.1.2.0.2.20041202174321.03c33378@shannon.research.telcordia.com> X-Sender: kaj@shannon.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 02 Dec 2004 18:44:15 -0500 To: entmib@ietf.org From: Kaj Tesink Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_292458643==_" X-Spam-Score: 0.0 (/) X-Scan-Signature: 85fe3afc5d9560be77aa81420052017a Subject: [Entmib] CLEI Code URN draft X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org --=====================_292458643==_ Content-Type: text/plain; charset="us-ascii"; format=flowed here is the draft for the CLEI URN name space request, which i'll also forward following the 3406 process. kaj _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_292458643==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="draft-tesink-urn-clei-00.txt" Content-Transfer-Encoding: quoted-printable INTERNET DRAFT Kaj Tesink Robert H. Fox Telcordia Technologies November 7, 2004 A Uniform Resource Name (URN) Namespace for the CLEI Code Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a Uniform Resource Name (URN) namespace that is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213 [T1.213], for the assignment of the CLEI Code, for usage within messages standardized by ANSI. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. The CLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI Code and supplier=92s Product ID (Manufacturer=92s name, part number along with it=92s version number). Expires 05/07/2005 URN Namespace for the CLEI Code [Page 1] =0C Internet Draft 11/07/2004 Table of Contents 1 Introduction .............................................. 3 2 Specification Template .................................... 3 3 Examples .................................................. 5 4 Security Considerations ................................... 5 5 IANA Considerations ....................................... 6 6 Intellectual Property ..................................... 6 7 Acknowledgments ........................................... 6 8 Normative References ...................................... 7 9 Author's Address .......................................... 7 Full Copyright Statement ................................... 7 Expires 05/07/2005 URN Namespace for the CLEI Code [Page 2] =0C Internet Draft 11/07/2004 1. Introduction Many circuit cards used in the global telecommunications network have a CLEI Code assigned and have a bar code or two-dimensional symbol on a label affixed to the front of that circuit card. Service providers utilize the CLEI Code to: o Track inventory, both working and spare o Logistics (movement of circuit cards, along with the serial number) o Provision equipment o Maintain asset records (accounting information) The goal of the CLEI namespace is to ensure the stability and uniqueness of the names of various (specific) items that are used within the messages exchanged between equipment used in the global telecommunications network. The assigned maintenance agent for the CLEI Code, Telcordia Technologies, is responsible for assigning certain equipment and other identifiers (e.g., location, manufacturer/supplier) for the telecommunications industry. The code assignment process identifies the structure and intelligence of the CLEI Code to identify the circuit card=92s form, fit, functions, and features. Equipment may exist in multiple physical locations with the exact same form, fit, functions, and features and will have the same CLEI Code if their Product ID is the same. 2. Specification Template Namespace ID: "CLEI" Registration Information: Version 1 Date: 2004-11-07 Declared registrant of the namespace: Telcordia Technologies, Inc. Customer Support Center 8 Corporate Place Expires 05/07/2005 URN Namespace for the CLEI Code [Page 3] =0C Internet Draft 11/07/2004 Piscataway, NJ 08854 U.S.A. +1.732.699.5577 http://www.commonlanguage.com Declaration of syntactic structures: The structure of the Namespace Specific String is a flat space of 10 characters as defined in [T1.213][T1.213a]. Relevant ancillary Documentation: [T1.213] and [T1.213a]. Identifier uniqueness considerations: Identifiers are assigned by Telcordia URN registration that guarantees Uniqueness for items with different form, fit, functions, and features. This is simply achieved by keeping track of already assigned names and comparing all new proposed names to the database ones. If the name already exists a new one is created per the rules of the process. See [T1.213][T1.213a] for assignment examples. Identifiers persistence considerations: The process defined by ANSI and the CLEI maintenance agent ensure the binding between the name and its resource is permanent, and that names are not reassigned. Process of identifiers assignment: A CLEI Code is an intelligent code that consists of 10 alpha- numeric characters with 4 data elements. The first data element is considered the basic code with the first 2 characters indicating the technology or equipment type with the third and fourth characters denoting the functional sub-category. The second data element represents the features and its three characters denote functional capabilities or changes. The third data element has one character and denotes a reference to manufacturer, system ID, specification or drawing. The fourth data element consists of two characters and contains complementary data. These two characters provide a means of differentiating or providing uniqueness between the eight character CLEI Codes by identifying the manufacturing vintage of the product. Names are assigned via procedures defined in [GR485]. Process for identifier resolution: Expires 05/07/2005 URN Namespace for the CLEI Code [Page 4] =0C Internet Draft 11/07/2004 Telcordia URNs are resolved via Telcordia resolvers run under Telcordia responsibility. For further information see www.commonlanguage.com. Rules for lexical equivalence: URNs are lexically equivalent if they are lexically identical. See [T1.213] and [T1.213a] for further information. Conformance with URN syntax: No special consideration. Validation mechanism: None specified. Scope: Global. 3. Examples The following three examples are based on the examples provided in [T1.213a], and correspond with three different sets of features by three different manufacturers (Nortel Networks, Lear and Lucent Technologies) producing "D4CE" (a particular D4 channel bank type) equipment. The fourth example refers to a SONET power unit convertor of Alcatel. URN:CLEI:D4CE18B7AA URN:CLEI:D4CE4248AA URN:CLEI:D4CE363PAB URN:CLEI:SNPWBBC7AA 4. Security Considerations There are no additional security considerations other than those normally associated with the use and resolution of URNs in general. It is noted however that attempting to resolve a Telcordia URN through a resolver other than the one provided by Telcordia is not considered authoritative. Expires 05/07/2005 URN Namespace for the CLEI Code [Page 5] =0C Internet Draft 11/07/2004 5. IANA Considerations The IANA has registered formal URN namespace ????, to Telcordia within the IANA registry of URN NIDs. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgments The contributions of the Entity MIB Working Group members are gratefully acknowledged. Special thanks go to Mike Heard, Juergen Schoenwaelder, Dave Perkins and Dan Romascanu. Expires 05/07/2005 URN Namespace for the CLEI Code [Page 6] =0C Internet Draft 11/07/2004 8. Normative References [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Name (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [T1.213] ATIS T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, 2001, www.ansi.org [T1.213a] ATIS T1.213a, Supplement to T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, to correct the representation of the Basic Code in Figure B.1, 2001, www.ansi.org [GR485] GR-485-CORE, COMMON LANGUAGE Equipment Codes (CLEI Codes) =AD Generic Requirements for Processes And Guidelines, Issue 5, Telcordia Technologies, April 2004. 9. Author's Address Kaj Tesink One Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699-6068 EMail: kaj@research.telcordia.com Robert H. Fox 3545 S.Ocean Blvd, #417 Palm Beach, FL 33480-5715 USA Phone: +1 732 699-8968 EMail: rfox@telcordia.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any Expires 05/07/2005 URN Namespace for the CLEI Code [Page 7] =0C Internet Draft 11/07/2004 kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 05/07/2005 URN Namespace for the CLEI Code [Page 8] =0C Internet Draft 11/07/2004 ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * Please replace "????" in the IANA Considerations section * * with an IANA-assigned URN NID. * * * ************************************************************ Expires 05/07/2005 URN Namespace for the CLEI Code [Page 9] =0C Internet Draft 11/07/2004 Table of Contents 1 Introduction .............................................. 3 2 Specification Template .................................... 3 3 Examples .................................................. 5 4 Security Considerations ................................... 5 5 IANA Considerations ....................................... 6 6 Intellectual Property ..................................... 6 7 Acknowledgments ........................................... 6 8 Normative References ...................................... 7 9 Author's Address .......................................... 7 Full Copyright Statement ................................... 7 Expires 05/07/2005 URN Namespace for the CLEI Code [Page 10] --=====================_292458643==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib --=====================_292458643==_-- From entmib-bounces@ietf.org Fri Dec 3 14:53:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29051 for ; Fri, 3 Dec 2004 14:53:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJ74-0000tg-3q; Fri, 03 Dec 2004 14:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaISm-0005DK-Lg for entmib@megatron.ietf.org; Fri, 03 Dec 2004 13:47:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19125 for ; Fri, 3 Dec 2004 13:47:27 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaIYY-0007sl-IW for entmib@ietf.org; Fri, 03 Dec 2004 13:53:27 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id iB3Ikna4024098; Fri, 3 Dec 2004 10:46:49 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id iB3IknXU025219; Fri, 3 Dec 2004 10:46:49 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id iB3IkmVU025208; Fri, 3 Dec 2004 10:46:49 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 3 Dec 2004 10:46:48 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Kaj Tesink Subject: Re: [Entmib] CLEI Code URN draft In-Reply-To: <6.1.2.0.2.20041202174321.03c33378@shannon.research.telcordia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org HI, Draft looks good. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 09:01:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25982 for ; Wed, 8 Dec 2004 09:01:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc2Gl-0004Wf-QY; Wed, 08 Dec 2004 08:54:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc27X-0002UC-La for entmib@megatron.ietf.org; Wed, 08 Dec 2004 08:44:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24851 for ; Wed, 8 Dec 2004 08:44:42 -0500 (EST) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc2EJ-0005eQ-Tt for entmib@ietf.org; Wed, 08 Dec 2004 08:51:44 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id IAA25821 for ; Wed, 8 Dec 2004 08:49:57 -0500 (EST) Received: from nhrocavg1(134.141.77.91) by ctron-dnm.enterasys.com via smap (4.1) id xma025768; Wed, 8 Dec 04 08:49:49 -0500 Received: from psmtp.com ([134.141.77.91]) by 134.141.77.91 with InterScan Messaging Security Suite; Wed, 08 Dec 2004 08:44:29 -0500 Received: from source ([134.141.79.122]) by host ([134.141.77.91]) with SMTP; Wed, 08 Dec 2004 08:44:27 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Dec 2004 08:44:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] WG LAST CALL: draft-ietf-entmib-state-05.txt Date: Wed, 8 Dec 2004 08:43:59 -0500 Message-ID: Thread-Topic: RE: [Entmib] WG LAST CALL: draft-ietf-entmib-state-05.txt Thread-Index: AcTdK/iPQ3g5q5jMS96f8uJ/rEW1mA== From: "McTague, Charles" To: X-OriginalArrivalTime: 08 Dec 2004 13:44:00.0200 (UTC) FILETIME=[F8E05480:01C4DD2B] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 P:95.9108 R:95.9108 S:59.6331 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I was wondering if any progress was being made towards sending the=20 ENTITY-STATE-MIB to the IESG, and if any help was needed towards that=20 effort? Thanks, chuck --------------------------- Charles McTague Firmware Archtitect Enterasys Networks, Inc.=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 12:22:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15823 for ; Wed, 8 Dec 2004 12:22:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5Mw-0006Dd-Jz; Wed, 08 Dec 2004 12:12:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc57F-0002IE-0g for entmib@megatron.ietf.org; Wed, 08 Dec 2004 11:56:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13794 for ; Wed, 8 Dec 2004 11:56:34 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5E2-00025f-8d for entmib@ietf.org; Wed, 08 Dec 2004 12:03:39 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2004 10:01:24 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB8Gu0m4000006 for ; Wed, 8 Dec 2004 08:56:00 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-642.cisco.com [10.21.82.130]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBS80325; Wed, 8 Dec 2004 08:56:01 -0800 (PST) Message-Id: <4.3.2.7.2.20041208081842.01fdcbc8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Dec 2004 08:56:01 -0800 To: entmib@ietf.org From: Andy Bierman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Entmib] entPhysicalUris object wrap-up X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Hi, I'd like to finish this up so I can submit an I-D update. I have some issues to clarify, which require WG consensus. I would rather remove this object than hold up progress any longer, but if issues get resolved quickly then it would be better to finish it now. 1) object purpose There is strong opposition to a generic URI(s) placeholder object by a couple people. This is an object that contains any semantics related to a physical entity, for which the syntax happens to be encoded as a URI string. (very low cohesion). I propose that this object be changed back to entPhysicalClei. It should contain the empty string (for none) or a URI string conforming to the CLEI URN specification (from Kaj). If we think of other required semantics in the future, we can add new objects then. 2) references As per Bert's comments, the citation to RFC 2396 will be removed from the DESCRIPTION clause, since it is redundant. Should this be changed to point to the CLEI URN specification, or just add another document to the REFERENCE clause? Where else should this spec be cited in the document? There are normative references, so how long will the Entity MIB be held up waiting for the CLEI URN RFC? 3) conformance Currently the new OBJECT-GROUP (entityPhysical3Group) is in the MANDATORY-GROUPS clause. If both objects allow for null values, then this should not be a problem. 4) examples I don't really have time (or enough info) to fill in the examples in section 4, but I know somebody will eventually ask about this before RFC publication. I would really appreciate some help updating the examples. (I need to add an example for entPhysicalClass==cpu(12) as well.) Any volunteers? (4.1 and 4.2 can be done independently) I would like to get this over with now ;-) thanks, Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 13:42:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22746 for ; Wed, 8 Dec 2004 13:42:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc6Yh-0000Oj-9B; Wed, 08 Dec 2004 13:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc6Ud-0007la-FO for entmib@megatron.ietf.org; Wed, 08 Dec 2004 13:24:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21535 for ; Wed, 8 Dec 2004 13:24:48 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc6bS-0004Ni-I4 for entmib@ietf.org; Wed, 08 Dec 2004 13:31:54 -0500 Received: from [207.31.248.246] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 230702; Wed, 08 Dec 2004 13:18:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4.3.2.7.2.20041208081842.01fdcbc8@fedex.cisco.com> References: <4.3.2.7.2.20041208081842.01fdcbc8@fedex.cisco.com> Date: Wed, 8 Dec 2004 13:24:15 -0500 To: Andy Bierman From: Margaret Wasserman Subject: Re: [Entmib] entPhysicalUris object wrap-up Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org >I propose that this object be changed back to entPhysicalClei. >It should contain the empty string (for none) or a URI >string conforming to the CLEI URN specification (from Kaj). >If we think of other required semantics in the future, >we can add new objects then. This makes sense to me if we can quickly, easily resolve the reference issues. Otherwise, I think we should just remove the object and let others add it as an "augments" if/when the proposed contents are well-defined. >2) references > >As per Bert's comments, the citation to RFC 2396 will be >removed from the DESCRIPTION clause, since it is redundant. >Should this be changed to point to the CLEI URN specification, >or just add another document to the REFERENCE clause? >Where else should this spec be cited in the document? >There are normative references, so how long will the >Entity MIB be held up waiting for the CLEI URN RFC? If we pursue this choice, I think that the CLEI URN document needs to be a normative reference. Kaj submitted a draft, but I don't know what shape it is in and/or whether Bert is willing to either: (1) allow this group to take on that document, or (2) move it forward as an individual submission. How close do folks think it is to ready for publication? Has a MIB doctor reviewed it? Bert, do you have any thoughts? >3) conformance > >Currently the new OBJECT-GROUP (entityPhysical3Group) >is in the MANDATORY-GROUPS clause. If both objects >allow for null values, then this should not be a problem. Okay. >4) examples > >I don't really have time (or enough info) to fill in the >examples in section 4, but I know somebody will eventually >ask about this before RFC publication. I would really >appreciate some help updating the examples. (I need to >add an example for entPhysicalClass==cpu(12) as well.) >Any volunteers? (4.1 and 4.2 can be done independently) >I would like to get this over with now ;-) Yes. It would be good to get this finished, so volunteer would be appreciated. Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 16:29:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04779 for ; Wed, 8 Dec 2004 16:29:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9Cy-0007ad-96; Wed, 08 Dec 2004 16:18:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc94g-0004WR-KI for entmib@megatron.ietf.org; Wed, 08 Dec 2004 16:10:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03670 for ; Wed, 8 Dec 2004 16:10:12 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc9BV-0007fV-75 for entmib@ietf.org; Wed, 08 Dec 2004 16:17:19 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iB8LA7R6017993 for ; Wed, 8 Dec 2004 15:10:07 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Dec 2004 22:10:06 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505E0CE4F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Margaret Wasserman , Andy Bierman Subject: RE: [Entmib] entPhysicalUris object wrap-up Date: Wed, 8 Dec 2004 22:10:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Inline > -----Original Message----- > From: entmib-bounces@ietf.org > [mailto:entmib-bounces@ietf.org]On Behalf > Of Margaret Wasserman > Sent: Wednesday, December 08, 2004 13:24 > To: Andy Bierman > Cc: entmib@ietf.org > Subject: Re: [Entmib] entPhysicalUris object wrap-up > > > > >I propose that this object be changed back to entPhysicalClei. > >It should contain the empty string (for none) or a URI > >string conforming to the CLEI URN specification (from Kaj). > >If we think of other required semantics in the future, > >we can add new objects then. > > This makes sense to me if we can quickly, easily resolve the > reference issues. > > Otherwise, I think we should just remove the object and let others > add it as an "augments" if/when the proposed contents are > well-defined. > > >2) references > > > >As per Bert's comments, the citation to RFC 2396 will be > >removed from the DESCRIPTION clause, since it is redundant. > >Should this be changed to point to the CLEI URN specification, > >or just add another document to the REFERENCE clause? > >Where else should this spec be cited in the document? > >There are normative references, so how long will the > >Entity MIB be held up waiting for the CLEI URN RFC? > > If we pursue this choice, I think that the CLEI URN document needs to > be a normative reference. Kaj submitted a draft, but I don't know > what shape it is in and/or whether Bert is willing to either: (1) > allow this group to take on that document, or (2) move it forward as > an individual submission. How close do folks think it is to ready > for publication? Has a MIB doctor reviewed it? Bert, do you have > any thoughts? > I'd suggest that Kaj posts his doc to the IETF I-D repository asap, so all IETF people can see it. Is it a doc that goes stds track, or what? Besides, I see in the copy that I got from Kaj): !! Missing citation for Normative reference: P007 L011: [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, idnits 1.47 (02 Nov 2004) ../../draft-tesink-urn-clei-00.txt: Looks like you're using RFC 2026 boilerplate. Better change to RFC 3667/3668. There are 4 instances of lines with non-ascii characters in the document. Is the URN intended to be a FORMAL or an INFORMAL one (see rfc3406) ?? Bert > >3) conformance > > > >Currently the new OBJECT-GROUP (entityPhysical3Group) > >is in the MANDATORY-GROUPS clause. If both objects > >allow for null values, then this should not be a problem. > > Okay. > > >4) examples > > > >I don't really have time (or enough info) to fill in the > >examples in section 4, but I know somebody will eventually > >ask about this before RFC publication. I would really > >appreciate some help updating the examples. (I need to > >add an example for entPhysicalClass==cpu(12) as well.) > >Any volunteers? (4.1 and 4.2 can be done independently) > >I would like to get this over with now ;-) > > Yes. It would be good to get this finished, so volunteer > would be appreciated. > > Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 17:27:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16332 for ; Wed, 8 Dec 2004 17:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9jA-000731-T1; Wed, 08 Dec 2004 16:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9MH-000221-66 for entmib@megatron.ietf.org; Wed, 08 Dec 2004 16:28:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04735 for ; Wed, 8 Dec 2004 16:28:23 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc9T6-0007xg-Sq for entmib@ietf.org; Wed, 08 Dec 2004 16:35:30 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6BF6B3742; Wed, 8 Dec 2004 22:27:45 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13880-09; Wed, 8 Dec 2004 22:27:44 +0100 (CET) Received: from james (I8848.i.pppool.de [85.73.136.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 6D6A33730; Wed, 8 Dec 2004 22:27:44 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Cc9Lb-0000aU-Id; Wed, 08 Dec 2004 22:27:43 +0100 Date: Wed, 8 Dec 2004 22:27:43 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Subject: Re: [Entmib] entPhysicalUris object wrap-up Message-ID: <20041208212743.GB2219@james> Mail-Followup-To: Margaret Wasserman , Andy Bierman , entmib@ietf.org References: <4.3.2.7.2.20041208081842.01fdcbc8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: entmib@ietf.org, Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Wed, Dec 08, 2004 at 01:24:15PM -0500, Margaret Wasserman wrote: > If we pursue this choice, I think that the CLEI URN document needs to > be a normative reference. Kaj submitted a draft, but I don't know > what shape it is in and/or whether Bert is willing to either: (1) > allow this group to take on that document, or (2) move it forward as > an individual submission. How close do folks think it is to ready > for publication? Has a MIB doctor reviewed it? Bert, do you have > any thoughts? If at all, this needs a URI doctor review, not a MIB doctor review. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 17:27:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16414 for ; Wed, 8 Dec 2004 17:27:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9kF-00082A-D2; Wed, 08 Dec 2004 16:53:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc9NE-0002fY-3j for entmib@megatron.ietf.org; Wed, 08 Dec 2004 16:29:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04772 for ; Wed, 8 Dec 2004 16:29:21 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc9U3-0007z5-KM for entmib@ietf.org; Wed, 08 Dec 2004 16:36:29 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id iB8LRdkc009986; Wed, 8 Dec 2004 13:27:39 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id iB8LRcAr008048; Wed, 8 Dec 2004 13:27:38 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id iB8LRceB008027; Wed, 8 Dec 2004 13:27:38 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 8 Dec 2004 13:27:37 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Margaret Wasserman Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: entmib@ietf.org, Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org HI, I somehow missed the motivating reasons to go from a an object that can provide a alternative identification to an object that supports only CLEI codes. On Wed, 8 Dec 2004, Margaret Wasserman wrote: > >I propose that this object be changed back to entPhysicalClei. > >It should contain the empty string (for none) or a URI > >string conforming to the CLEI URN specification (from Kaj). > >If we think of other required semantics in the future, > >we can add new objects then. > > This makes sense to me if we can quickly, easily resolve the reference issues. > > Otherwise, I think we should just remove the object and let others > add it as an "augments" if/when the proposed contents are > well-defined. > Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 19:17:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28672 for ; Wed, 8 Dec 2004 19:17:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcBwR-0006rr-8g; Wed, 08 Dec 2004 19:13:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcBvY-0006f9-4R for entmib@megatron.ietf.org; Wed, 08 Dec 2004 19:13:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28276 for ; Wed, 8 Dec 2004 19:12:57 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcC2O-0006Qg-RC for entmib@ietf.org; Wed, 08 Dec 2004 19:20:06 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2004 16:15:08 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB90CM5M029110; Wed, 8 Dec 2004 16:12:22 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-642.cisco.com [10.21.82.130]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBT37212; Wed, 8 Dec 2004 16:12:20 -0800 (PST) Message-Id: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Dec 2004 16:12:20 -0800 To: "David T. Perkins" From: Andy Bierman Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Margaret Wasserman , entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 01:27 PM 12/8/2004, David T. Perkins wrote: >HI, > >I somehow missed the motivating reasons to go from a >an object that can provide a alternative identification >to an object that supports only CLEI codes. IMO, standard objects add value by providing common, well-defined semantics. A list of undefined, unconstrained "alternate identifiers" doesn't meet this criteria. If the DESCRIPTION clause somehow constrained (and guided) implementations with a finite set of alternatives, that would be fine. Rationale for each alternative would need to be documented as well. I strongly oppose doing all this "alternative identifier" work as part of the 2737 update, because it isn't well-defined yet. Andy >On Wed, 8 Dec 2004, Margaret Wasserman wrote: >> >I propose that this object be changed back to entPhysicalClei. >> >It should contain the empty string (for none) or a URI >> >string conforming to the CLEI URN specification (from Kaj). >> >If we think of other required semantics in the future, >> >we can add new objects then. >> >> This makes sense to me if we can quickly, easily resolve the reference issues. >> >> Otherwise, I think we should just remove the object and let others >> add it as an "augments" if/when the proposed contents are >> well-defined. >> >Regards, >/david t. perkins > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 21:43:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11954 for ; Wed, 8 Dec 2004 21:43:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcE5v-0007FX-2B; Wed, 08 Dec 2004 21:31:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcE2F-0006Bp-G6 for entmib@megatron.ietf.org; Wed, 08 Dec 2004 21:28:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10887 for ; Wed, 8 Dec 2004 21:28:01 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcE97-0000qK-Mw for entmib@ietf.org; Wed, 08 Dec 2004 21:35:11 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id iB92RRkc032389; Wed, 8 Dec 2004 18:27:27 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id iB92RQHU018470; Wed, 8 Dec 2004 18:27:26 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id iB92RPgc018464; Wed, 8 Dec 2004 18:27:26 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 8 Dec 2004 18:27:25 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Andy Bierman Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Margaret Wasserman , entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org HI, Ok, you guys caught me not staying current on all messages. Now that I've read the I-D and read the messages from approx Nov 30 time frame, here are my comments: 1) The text of the document and the text in the description clause to not seem to be in alignment with reguards to an empty value. Some people like to not create an instance and others like the use of a zero length string. I prefer a zero length string. 2) The data type is OCTET STRING. I think it should be the proper TC for a "printable US ASCII" (that is, printable 7-bit ASCII). URIs cannot contain spaces, and must contain only a subset of characters from printable 7-bit ASCII. 3) In RFC 3413, textual convention SNMP-TARGET-MIB::SnmpTagList provides a superset of what is needed for the syntax. It provides support for UTF8 encodings, which are not needed for URIs. It describes leading, trailing, and multiple deliminators (you can't have them!). 4) This issue has been discussed many times. As was pointed out by Kaj in an earlier message, the approach choosen was the best solution and was acceptable to all on the WG mailing list. I don't believe that it is fair to undo what was hammered out over a long period of time where: a) it was demonstrated that use of an "alternative identification" scheme was needed and provided value at little cost. b) the scheme was neutral c) the scheme provided support for multiple competing alternative identifications (limited only by the size of the object) d) the cost to support a "non implementation" was next to nothing 5) Yes, all MIB purests hate this and similar objects, since they are really for "lazy management app writers". However, this object does provide benefit when it is difficult to determine values of OIDs that are used for the value of object entPhysicalVendorType. Tracking down OID values used for identification can be a time consuming and frustrating job. 6) I don't remember why it is "read-write" and not read-only, since entPhysicalVendorType is read-only. But maybe someone can provide the reason. (I think if you want to change it, then there should be a path not via SNMP. Because if you can write it via SNMP, a management app must be translating the value of entPhysicalVendorType.) So, I suggest that 1) the DESCRIPTION text be cleaned up and aligned with the text in the document to say that the object is a) an alternative way to identify the component than the value of entPhysicalVendorType b) potentially a list of alternative identifications 2) the value of the SYNTAX be changed to DisplayString (and the DESCRPTION clause restrict the values further). 3) the descriptor be changed to something like "entPhysicalAltIDlist" to better convey it's semantics. 4) Possibly change it to read-only. (But ignore this if there is a good reason not to.) Note, I thought that maybe object entPhysicalAssetID could do double duty and hold the URI value, but it is too small. So, again, I feel that the WG made the best choices to create a new neutral object. On Wed, 8 Dec 2004, Andy Bierman wrote: > At 01:27 PM 12/8/2004, David T. Perkins wrote: > >HI, > > > >I somehow missed the motivating reasons to go from a > >an object that can provide a alternative identification > >to an object that supports only CLEI codes. > > IMO, standard objects add value by providing common, well-defined > semantics. A list of undefined, unconstrained "alternate identifiers" > doesn't meet this criteria. If the DESCRIPTION clause somehow > constrained (and guided) implementations with a finite set of > alternatives, that would be fine. Rationale for each alternative > would need to be documented as well. I strongly oppose doing > all this "alternative identifier" work as part of the 2737 update, > because it isn't well-defined yet. > > Andy I believe that Andy's objection can be resolved by a registry at IANA for URIs for this object. Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 8 22:43:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28405 for ; Wed, 8 Dec 2004 22:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcFBH-00066P-Gb; Wed, 08 Dec 2004 22:41:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcF5C-0005Ob-9R for entmib@megatron.ietf.org; Wed, 08 Dec 2004 22:35:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28002 for ; Wed, 8 Dec 2004 22:35:08 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcFC4-0002Ml-7j for entmib@ietf.org; Wed, 08 Dec 2004 22:42:18 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2004 20:40:02 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB93YYm4026431; Wed, 8 Dec 2004 19:34:35 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-642.cisco.com [10.21.82.130]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBT54397; Wed, 8 Dec 2004 19:34:34 -0800 (PST) Message-Id: <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Dec 2004 19:34:33 -0800 To: "David T. Perkins" From: Andy Bierman Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: References: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Margaret Wasserman , entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 06:27 PM 12/8/2004, David T. Perkins wrote: >HI, > >Ok, you guys caught me not staying current on all messages. >Now that I've read the I-D and read the messages from approx >Nov 30 time frame, here are my comments: >1) The text of the document and the text in the description > clause to not seem to be in alignment with reguards to > an empty value. Some people like to not create an instance > and others like the use of a zero length string. I prefer > a zero length string. >2) The data type is OCTET STRING. I think it should be the > proper TC for a "printable US ASCII" (that is, printable > 7-bit ASCII). URIs cannot contain spaces, and must contain > only a subset of characters from printable 7-bit ASCII. >3) In RFC 3413, textual convention SNMP-TARGET-MIB::SnmpTagList > provides a superset of what is needed for the syntax. > It provides support for UTF8 encodings, which are not needed > for URIs. It describes leading, trailing, and multiple > deliminators (you can't have them!). >4) This issue has been discussed many times. As was pointed out > by Kaj in an earlier message, the approach choosen was the > best solution and was acceptable to all on the WG mailing > list. I don't believe that it is fair to undo what was > hammered out over a long period of time where: > a) it was demonstrated that use of an > "alternative identification" scheme was needed > and provided value at little cost. > b) the scheme was neutral > c) the scheme provided support for multiple competing > alternative identifications (limited only by the size > of the object) > d) the cost to support a "non implementation" was next > to nothing I missed all this on the mailing list. I'll let the WG Chair decide, and I'll wait on any edits. >5) Yes, all MIB purests hate this and similar objects, since > they are really for "lazy management app writers". However, No -- they are for lazy standards writers. > this object does provide benefit when it is difficult to > determine values of OIDs that are used for the value of > object entPhysicalVendorType. Tracking down OID values > used for identification can be a time consuming and > frustrating job. >6) I don't remember why it is "read-write" and not read-only, > since entPhysicalVendorType is read-only. But maybe someone > can provide the reason. (I think if you want to change it, > then there should be a path not via SNMP. Because if you > can write it via SNMP, a management app must be translating > the value of entPhysicalVendorType.) > >So, I suggest that >1) the DESCRIPTION text be cleaned up and aligned with > the text in the document to say that the object is > a) an alternative way to identify the component > than the value of entPhysicalVendorType > b) potentially a list of alternative identifications >2) the value of the SYNTAX be changed to DisplayString > (and the DESCRPTION clause restrict the values further). >3) the descriptor be changed to something like > "entPhysicalAltIDlist" to better convey it's > semantics. >4) Possibly change it to read-only. (But ignore this > if there is a good reason not to.) > >Note, I thought that maybe object entPhysicalAssetID could >do double duty and hold the URI value, but it is too small. >So, again, I feel that the WG made the best choices to >create a new neutral object. > >On Wed, 8 Dec 2004, Andy Bierman wrote: >> At 01:27 PM 12/8/2004, David T. Perkins wrote: >> >HI, >> > >> >I somehow missed the motivating reasons to go from a >> >an object that can provide a alternative identification >> >to an object that supports only CLEI codes. >> >> IMO, standard objects add value by providing common, well-defined >> semantics. A list of undefined, unconstrained "alternate identifiers" >> doesn't meet this criteria. If the DESCRIPTION clause somehow >> constrained (and guided) implementations with a finite set of >> alternatives, that would be fine. Rationale for each alternative >> would need to be documented as well. I strongly oppose doing >> all this "alternative identifier" work as part of the 2737 update, >> because it isn't well-defined yet. >> >> Andy >I believe that Andy's objection can be resolved by a registry >at IANA for URIs for this object. yep -- that works for me ;-) >Regards, >/david t. perkins thanks, Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 9 08:36:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21234 for ; Thu, 9 Dec 2004 08:36:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcOIx-0006uE-PL; Thu, 09 Dec 2004 08:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcOHF-0006M2-I0 for entmib@megatron.ietf.org; Thu, 09 Dec 2004 08:24:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20520 for ; Thu, 9 Dec 2004 08:24:12 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcOOE-0004wG-RY for entmib@ietf.org; Thu, 09 Dec 2004 08:31:27 -0500 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 240023; Thu, 09 Dec 2004 08:17:24 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> References: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> Date: Thu, 9 Dec 2004 08:23:55 -0500 To: Andy Bierman From: Margaret Wasserman Subject: Re: [Entmib] entPhysicalUris object wrap-up Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Hi All, >At 06:27 PM 12/8/2004, David T. Perkins wrote: >>4) This issue has been discussed many times. As was pointed out >> by Kaj in an earlier message, the approach choosen was the >> best solution and was acceptable to all on the WG mailing >> list. I don't believe that it is fair to undo what was >> hammered out over a long period of time where: >> a) it was demonstrated that use of an >> "alternative identification" scheme was needed >> and provided value at little cost. >> b) the scheme was neutral >> c) the scheme provided support for multiple competing >> alternative identifications (limited only by the size >> of the object) >> d) the cost to support a "non implementation" was next >> to nothing > >I missed all this on the mailing list. >I'll let the WG Chair decide, and I'll wait >on any edits. Kaj's document was never a WG document and, IMO, the Entity MIB WG did not make any official decisions about these objects before we decided to add them to the Entity MIB. I know that a few people used the Entity MIB mailing list to discuss Kaj's personal submission, and I thought that was fine. But, I didn't track the discussion closely enough to have a mental record of it, and no official consensus calls were made about it. Personally, I agree with Andy that it is a bit lame to have an undiscriminated, unformatted, loosely specified string in the middle of this MIB. How are applications supposed to know that this contains? Would it be possible to compare these strings? Use them as URLs? Or do anything with them besides just display them on a screen? I am not actually religious about this, though. So, if that's what the WG thinks is the best way to represent this object, so be it. Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 9 09:20:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24039 for ; Thu, 9 Dec 2004 09:20:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcP7k-0000mC-LJ; Thu, 09 Dec 2004 09:18:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcP3A-0008Bg-Ce for entmib@megatron.ietf.org; Thu, 09 Dec 2004 09:13:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23581 for ; Thu, 9 Dec 2004 09:13:43 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcPA9-0005rX-Fa for entmib@ietf.org; Thu, 09 Dec 2004 09:20:58 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 51D40374B; Thu, 9 Dec 2004 15:13:11 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28165-08; Thu, 9 Dec 2004 15:13:10 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 592923745; Thu, 9 Dec 2004 15:13:10 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CcP2c-0000rD-78; Thu, 09 Dec 2004 15:13:10 +0100 Date: Thu, 9 Dec 2004 15:13:10 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Subject: Re: [Entmib] entPhysicalUris object wrap-up Message-ID: <20041209141310.GB3095@james> Mail-Followup-To: Margaret Wasserman , Andy Bierman , entmib@ietf.org References: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: entmib@ietf.org, Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Thu, Dec 09, 2004 at 08:23:55AM -0500, Margaret Wasserman wrote: > Personally, I agree with Andy that it is a bit lame to have an > undiscriminated, unformatted, loosely specified string in the middle > of this MIB. This is I think a total mis-understanding of the MIB object. You may not like this object, but saying it is an undiscriminated, unformatted, loosely specified string really missed the point. > How are applications supposed to know that this contains? The object contains URIs separated by white space. Meaning is attached to URIs and applications have to understand the URIs (such as CLEI code URNs). If they do not understand the URI semantics, the URIs can still be displayed as a service to the operator who has to write down the hardware identification into an email message or speak it into a phone. > Would it be possible to compare these strings? This boils down to comparisons of URIs. In the case of CLEI code URNs, I would not see any problem. > Use them as URLs? Or do anything with them besides just display > them on a screen? See above. And yes, displaying a hardware identification number such as a CLEI code on screen can be useful. Note that most of the SnmpAdminString objects in the EntPhysicalEntry mainly serve the purpose of being displayed to the operator. (Unless I am missing some magic hidden algorithm burried deeply inside of the MIB.) Note: I do not claim that we have to add this object. There might be reasons not do so and there are of course reasons why we ended up with what we have on the table. What I dislike, however, are general and unsubstantiated statements. As far as I understand things, Andy dislikes the fact that the object allows arbitrary URIs and thus naming schemes. So we may have to reconsider the discussion that lead us to use URIs in the first place, namely to side-step the fact that these codes are not "openly" available. If that is now not a problem anymore, we can reconsider the URI notation we came up with to side-step the issue and have something that is less fancy. [But in any case, this is all about syntax and does not really change what a management application can or cannot do with a CLEI code.] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 9 09:25:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24424 for ; Thu, 9 Dec 2004 09:25:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcP8G-0000x1-2J; Thu, 09 Dec 2004 09:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcP4W-0008Qo-8f for entmib@megatron.ietf.org; Thu, 09 Dec 2004 09:15:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23746 for ; Thu, 9 Dec 2004 09:15:06 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcPBV-0005ss-NO for entmib@ietf.org; Thu, 09 Dec 2004 09:22:22 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iB9EELcu029556; Thu, 9 Dec 2004 09:14:21 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id JAA25211; Thu, 9 Dec 2004 09:14:20 -0500 (EST) Message-Id: <6.1.2.0.2.20041208212105.0448caf0@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 08 Dec 2004 22:03:17 -0500 To: Andy Bierman , Margaret Wasserman From: Kaj Tesink Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: References: <4.3.2.7.2.20041208081842.01fdcbc8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.6 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 01:24 PM 12/8/2004, Margaret Wasserman wrote: >>I propose that this object be changed back to entPhysicalClei. >>It should contain the empty string (for none) or a URI >>string conforming to the CLEI URN specification (from Kaj). >>If we think of other required semantics in the future, >>we can add new objects then. works for me; this is fairly close to the original request (but see my previous note on how we got to the URI solution) >This makes sense to me if we can quickly, easily resolve the reference issues. my sense is that there are several references we can use, including the T1.213 references which are authoritative on the CLEI format. the draft i submitted just turns that format into a URI. >Otherwise, I think we should just remove the object and let others add it >as an "augments" if/when the proposed contents are well-defined. > >>2) references >> >>As per Bert's comments, the citation to RFC 2396 will be >>removed from the DESCRIPTION clause, since it is redundant. >>Should this be changed to point to the CLEI URN specification, >>or just add another document to the REFERENCE clause? >>Where else should this spec be cited in the document? >>There are normative references, so how long will the >>Entity MIB be held up waiting for the CLEI URN RFC? > >If we pursue this choice, I think that the CLEI URN document needs to be a >normative reference. Kaj submitted a draft, but I don't know what shape >it is in and/or whether Bert is willing to either: (1) allow this group to >take on that document, or (2) move it forward as an individual >submission. How close do folks think it is to ready for publication? Has >a MIB doctor reviewed it? Bert, do you have any thoughts? the URN document is a standard request for the particular name space; so it follows the path stipulated in RFC3406. my understanding of that process (sect 4.3) is that after mailing to urn-nid@apps.ietf.org and a two week discussion period (one week has past already) the spec will be reviewed by the IESG. i'm unfamiliar with the length of that review but as the spec has been written using the standard template and closely parallels several other published URN RFCs the process should be straightforward. >>3) conformance >> >>Currently the new OBJECT-GROUP (entityPhysical3Group) >>is in the MANDATORY-GROUPS clause. If both objects >>allow for null values, then this should not be a problem. > >Okay. yup >>4) examples >> >>I don't really have time (or enough info) to fill in the >>examples in section 4, but I know somebody will eventually >>ask about this before RFC publication. I would really >>appreciate some help updating the examples. (I need to >>add an example for entPhysicalClass==cpu(12) as well.) >>Any volunteers? (4.1 and 4.2 can be done independently) >>I would like to get this over with now ;-) > >Yes. It would be good to get this finished, so volunteer would be >appreciated. if you like to add the Uri object to the exaample section we could leverage the examples in the example section of the CLEI URN document: ********************************************************************** 3. Examples The following three examples are based on the examples provided in [T1.213a], and correspond with three different sets of features by three different manufacturers (Nortel Networks, Lear and Lucent Technologies) producing "D4CE" (a particular D4 channel bank type) equipment. The fourth example refers to a SONET power unit convertor of Alcatel. URN:CLEI:D4CE18B7AA URN:CLEI:D4CE4248AA URN:CLEI:D4CE363PAB URN:CLEI:SNPWBBC7AA ********************************************************************* however, if you like to create an example in section 4 using the acme approach in the other examples i would have to find some bogus CLEI code for acme. is that what you're looking for? kaj >Margaret > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 9 10:28:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01009 for ; Thu, 9 Dec 2004 10:28:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcQCT-00039e-BX; Thu, 09 Dec 2004 10:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcQAP-0002kk-JF for entmib@megatron.ietf.org; Thu, 09 Dec 2004 10:25:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00376 for ; Thu, 9 Dec 2004 10:25:16 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcQHO-0007Qn-Pp for entmib@ietf.org; Thu, 09 Dec 2004 10:32:32 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Dec 2004 08:30:17 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB9FOZm4016865; Thu, 9 Dec 2004 07:24:35 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-642.cisco.com [10.21.82.130]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBT84388; Thu, 9 Dec 2004 07:24:41 -0800 (PST) Message-Id: <4.3.2.7.2.20041209071848.0262c6c8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Dec 2004 07:24:41 -0800 To: j.schoenwaelder@iu-bremen.de From: Andy Bierman Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: <20041209141310.GB3095@james> References: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Margaret Wasserman , entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 06:13 AM 12/9/2004, Juergen Schoenwaelder wrote: >On Thu, Dec 09, 2004 at 08:23:55AM -0500, Margaret Wasserman wrote: > >> Personally, I agree with Andy that it is a bit lame to have an >> undiscriminated, unformatted, loosely specified string in the middle >> of this MIB. > >This is I think a total mis-understanding of the MIB object. You may >not like this object, but saying it is an undiscriminated, unformatted, >loosely specified string really missed the point. > >> How are applications supposed to know that this contains? > >The object contains URIs separated by white space. Meaning is attached >to URIs and applications have to understand the URIs (such as CLEI code >URNs). If they do not understand the URI semantics, the URIs can still >be displayed as a service to the operator who has to write down the >hardware identification into an email message or speak it into a phone. > >> Would it be possible to compare these strings? > >This boils down to comparisons of URIs. In the case of CLEI code URNs, >I would not see any problem. > >> Use them as URLs? Or do anything with them besides just display >> them on a screen? > >See above. And yes, displaying a hardware identification number >such as a CLEI code on screen can be useful. Note that most of the >SnmpAdminString objects in the EntPhysicalEntry mainly serve the >purpose of being displayed to the operator. (Unless I am missing >some magic hidden algorithm burried deeply inside of the MIB.) > >Note: I do not claim that we have to add this object. There might >be reasons not do so and there are of course reasons why we ended >up with what we have on the table. What I dislike, however, are >general and unsubstantiated statements. > >As far as I understand things, Andy dislikes the fact that the object >allows arbitrary URIs and thus naming schemes. So we may have to >reconsider the discussion that lead us to use URIs in the first place, >namely to side-step the fact that these codes are not "openly" >available. If that is now not a problem anymore, we can reconsider >the URI notation we came up with to side-step the issue and have >something that is less fancy. [But in any case, this is all about >syntax and does not really change what a management application can >or cannot do with a CLEI code.] I dislike MIB objects that are too general to add value to a standard. A URI is very generic. What kind of resource is being identified here? Anything at all the vendor wants to put there. I think vendor MIBs are more appropriate for this usage. I am happy enough with an IANA registry for the URNs that SHOULD be used. >/js Andy >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 9 12:25:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12344 for ; Thu, 9 Dec 2004 12:25:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcRgx-0003w6-7X; Thu, 09 Dec 2004 12:02:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcRct-0001jV-EV for entmib@megatron.ietf.org; Thu, 09 Dec 2004 11:58:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10177 for ; Thu, 9 Dec 2004 11:58:45 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcRjr-0001Kl-BJ for entmib@ietf.org; Thu, 09 Dec 2004 12:06:02 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iB9Gw1cu006887; Thu, 9 Dec 2004 11:58:01 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA01967; Thu, 9 Dec 2004 11:58:00 -0500 (EST) Message-Id: <6.1.2.0.2.20041209100323.01d5dec0@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 09 Dec 2004 11:57:54 -0500 To: Margaret Wasserman , Andy Bierman , entmib@ietf.org From: Kaj Tesink Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: References: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 08:23 AM 12/9/2004, Margaret Wasserman wrote: >Hi All, > >>At 06:27 PM 12/8/2004, David T. Perkins wrote: >>>4) This issue has been discussed many times. As was pointed out >>> by Kaj in an earlier message, the approach choosen was the >>> best solution and was acceptable to all on the WG mailing >>> list. I don't believe that it is fair to undo what was >>> hammered out over a long period of time where: >>> a) it was demonstrated that use of an >>> "alternative identification" scheme was needed >>> and provided value at little cost. >>> b) the scheme was neutral >>> c) the scheme provided support for multiple competing >>> alternative identifications (limited only by the size >>> of the object) >>> d) the cost to support a "non implementation" was next >>> to nothing >> >>I missed all this on the mailing list. >>I'll let the WG Chair decide, and I'll wait >>on any edits. > >Kaj's document was never a WG document and, IMO, the Entity MIB WG did not >make any official decisions about these objects before we decided to add >them to the Entity MIB. I know that a few people used the Entity MIB >mailing list to discuss Kaj's personal submission, and I thought that was >fine. But, I didn't track the discussion closely enough to have a mental >record of it, and no official consensus calls were made about it. > >Personally, I agree with Andy that it is a bit lame to have an >undiscriminated, unformatted, loosely specified string in the middle of >this MIB. How are applications supposed to know that this >contains? Would it be possible to compare these strings? Use them as >URLs? Or do anything with them besides just display them on a screen? > >I am not actually religious about this, though. So, if that's what the WG >thinks is the best way to represent this object, so be it. fair enough, so let me recall again how we got here: 1. the original proposal was for some simple (i thought :-) object additions to be added to the entmib itself. 2. support for the objects was demonstrated over time, but there were 2 issues: a) status of the entmib (trying for Draft) b) the CLEI object representation 3. (2a) was solved by coming up with a separate supplemental MIB, a procedural move. 4. the supplemental MIB had to be a personal submission due to the procedural issue of wg charter. 5. later, the need for a supplemental MIB was removed since entmib stays at Proposed. thus, removing the procedural issues, and we are back to the original objects. 6. (2b) went thru an interesting discussion on concerns on how best to represent T1.213 format. this resulted eventually IMHO in an elegant proposal by Juergen and Dave using the URI representation. note that the object's nature is Identification; one advantage also pointed out by Juergen is that the URI approach allows identification not only of CLEIs but of other things as well, avoiding the need to rework the entmib in the future on this aspect. 7. to support (6) we needed a URN request for CLEI name space. this request has been posted using appropriate format and 3406 process. 8. irrespective of (6) and (7), the use and application of CLEIs themselves are perfectly clear; see T1.213 for details, and years of use. so, based on (1)-(8) i think Dave's observations above are reasonable. (i'd not suse in Dave's item (c) the word 'competing'; rather it accommodates identifiers for different applications, but i assume that that was meant). the string in the Uri object, at least for the CLEI application is well formatted and defined. IANA registries http://www.iana.org/assignments/uri-schemes and http://www.iana.org/assignments/urn-namespaces are there to help sort things out, no? kaj >Margaret > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 9 12:40:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13508 for ; Thu, 9 Dec 2004 12:40:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcS2T-0004OE-6Q; Thu, 09 Dec 2004 12:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcRod-0005S6-Iv for entmib@megatron.ietf.org; Thu, 09 Dec 2004 12:10:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11082 for ; Thu, 9 Dec 2004 12:10:49 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcRva-0001aj-Ng for entmib@ietf.org; Thu, 09 Dec 2004 12:18:07 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iB9HAJcu007380; Thu, 9 Dec 2004 12:10:19 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id MAA02515; Thu, 9 Dec 2004 12:10:19 -0500 (EST) Message-Id: <6.1.2.0.2.20041209120055.01d58ec0@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 09 Dec 2004 12:10:14 -0500 To: "Wijnen, Bert (Bert)" From: Kaj Tesink Subject: RE: [Entmib] entPhysicalUris object wrap-up In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15505E0CE4F@nl0006exch001u.nl .lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15505E0CE4F@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Margaret Wasserman , entmib@ietf.org, Andy Bierman X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 04:10 PM 12/8/2004, Wijnen, Bert (Bert) wrote: >Inline > >[..snip..] > > >I'd suggest that Kaj posts his doc to the IETF I-D repository asap, >so all IETF people can see it. ok, will do; i just followed 3406 which asks it to be sent to urn-nid@apps.ietf.org for initial review; i assumed that this would also result in I-D posting but perhaps not ... >Is it a doc that goes stds track, or what? looking at examples such as RFC3615 it would be an Informational RFC. >Besides, I see in the copy that I got from Kaj): >!! Missing citation for Normative reference: > P007 L011: [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. > Faltstrom, it is in section 8, Normative References >idnits 1.47 (02 Nov 2004) > >../../draft-tesink-urn-clei-00.txt: > > Looks like you're using RFC 2026 boilerplate. Better change to RFC > 3667/3668. i used 3614/3615 as examples but can update this > There are 4 instances of lines with non-ascii characters in the document. ?? hmm, interesting; i guess my nroff gets rusty; thanks for the flag, can you pl forward me the instances off-line? >Is the URN intended to be a FORMAL or an INFORMAL one (see rfc3406) ?? i submitted it as Formal (Informal doesnt make much sense for this case) kaj _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 9 12:55:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15591 for ; Thu, 9 Dec 2004 12:55:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSLt-0001Eu-MQ; Thu, 09 Dec 2004 12:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSA7-0006HK-4H for entmib@megatron.ietf.org; Thu, 09 Dec 2004 12:33:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12825 for ; Thu, 9 Dec 2004 12:33:04 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcSH7-00023j-7a for entmib@ietf.org; Thu, 09 Dec 2004 12:40:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2004 09:35:26 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB9HWRm4017668; Thu, 9 Dec 2004 09:32:27 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-642.cisco.com [10.21.82.130]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BBT96881; Thu, 9 Dec 2004 09:32:28 -0800 (PST) Message-Id: <4.3.2.7.2.20041209092434.026466b8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Dec 2004 09:32:27 -0800 To: Kaj Tesink From: Andy Bierman Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: <6.1.2.0.2.20041209100323.01d5dec0@128.96.81.11> References: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Margaret Wasserman , entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 08:57 AM 12/9/2004, Kaj Tesink wrote: >At 08:23 AM 12/9/2004, Margaret Wasserman wrote: > >>Hi All, >> >>>At 06:27 PM 12/8/2004, David T. Perkins wrote: >>>>4) This issue has been discussed many times. As was pointed out >>>> by Kaj in an earlier message, the approach choosen was the >>>> best solution and was acceptable to all on the WG mailing >>>> list. I don't believe that it is fair to undo what was >>>> hammered out over a long period of time where: >>>> a) it was demonstrated that use of an >>>> "alternative identification" scheme was needed >>>> and provided value at little cost. >>>> b) the scheme was neutral >>>> c) the scheme provided support for multiple competing >>>> alternative identifications (limited only by the size >>>> of the object) >>>> d) the cost to support a "non implementation" was next >>>> to nothing >>> >>>I missed all this on the mailing list. >>>I'll let the WG Chair decide, and I'll wait >>>on any edits. >> >>Kaj's document was never a WG document and, IMO, the Entity MIB WG did not make any official decisions about these objects before we decided to add them to the Entity MIB. I know that a few people used the Entity MIB mailing list to discuss Kaj's personal submission, and I thought that was fine. But, I didn't track the discussion closely enough to have a mental record of it, and no official consensus calls were made about it. >> >>Personally, I agree with Andy that it is a bit lame to have an undiscriminated, unformatted, loosely specified string in the middle of this MIB. How are applications supposed to know that this contains? Would it be possible to compare these strings? Use them as URLs? Or do anything with them besides just display them on a screen? >> >>I am not actually religious about this, though. So, if that's what the WG thinks is the best way to represent this object, so be it. > > >fair enough, so let me recall again how we got here: >1. the original proposal was for some simple (i thought :-) > object additions to be added to the entmib itself. >2. support for the objects was demonstrated over time, > but there were 2 issues: > a) status of the entmib (trying for Draft) > b) the CLEI object representation >3. (2a) was solved by coming up with a separate > supplemental MIB, a procedural move. >4. the supplemental MIB had to be a personal > submission due to the procedural issue of wg charter. >5. later, the need for a supplemental MIB was removed > since entmib stays at Proposed. thus, > removing the procedural issues, and > we are back to the original objects. >6. (2b) went thru an interesting discussion on concerns > on how best to represent T1.213 format. this > resulted eventually IMHO in an elegant proposal > by Juergen and Dave using the URI representation. > note that the object's nature is Identification; one > advantage also pointed out by Juergen is that the URI > approach allows identification not only of CLEIs > but of other things as well, avoiding the need to > rework the entmib in the future on this aspect. >7. to support (6) we needed a URN request for CLEI name space. > this request has been posted using appropriate format > and 3406 process. >8. irrespective of (6) and (7), the use and application of > CLEIs themselves are perfectly clear; see T1.213 for > details, and years of use. > >so, based on (1)-(8) i think Dave's observations above >are reasonable. >(i'd not suse in Dave's item (c) the word 'competing'; >rather it accommodates identifiers for different applications, >but i assume that that was meant). > >the string in the Uri object, at least for the CLEI >application is well formatted and defined. IANA registries >http://www.iana.org/assignments/uri-schemes and >http://www.iana.org/assignments/urn-namespaces >are there to help sort things out, no? The documentation I was provided for this object (especially the OBJECT-TYPE macro) did not convey any of this info, rationale, or references. If it did, I wouldn't have objected to the vagueness of the object. I still don't understand why we need a list of URIs per entity. This adds complexity. It there a compelling need for multiple URIs per entity? >kaj Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 9 16:45:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13969 for ; Thu, 9 Dec 2004 16:45:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVMj-0005MW-GC; Thu, 09 Dec 2004 15:58:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVAx-0007UD-Hn; Thu, 09 Dec 2004 15:46:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02613; Thu, 9 Dec 2004 15:46:08 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcVHu-0006Ue-NU; Thu, 09 Dec 2004 15:53:27 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iB9KjQcu017263; Thu, 9 Dec 2004 15:45:26 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA14730; Thu, 9 Dec 2004 15:45:25 -0500 (EST) Message-Id: <6.1.2.0.2.20041209153833.0448e960@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 09 Dec 2004 15:41:38 -0500 To: internet-drafts@ietf.org From: Kaj Tesink Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_164294232==_" X-Spam-Score: 0.0 (/) X-Scan-Signature: fe6e20eef2d8927c50910823cd0d1c84 Cc: entmib@ietf.org Subject: [Entmib] draft-tesink-urn-clei-00.txt X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org --=====================_164294232==_ Content-Type: text/plain; charset="us-ascii"; format=flowed hi, can you please post the attached in the I-D archive as an individual submission under file name draft-tesink-urn-clei-00.txt and confirm the posting thanks, kaj --=====================_164294232==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="draft-tesink-urn-clei-00.txt" Content-Transfer-Encoding: quoted-printable INTERNET DRAFT Kaj Tesink Robert H. Fox Telcordia Technologies November 7, 2004 A Uniform Resource Name (URN) Namespace for the CLEI Code Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a Uniform Resource Name (URN) namespace that is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213 [T1.213], for the assignment of the CLEI Code, for usage within messages standardized by ANSI. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. The CLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI Code and supplier=92s Product ID (Manufacturer=92s name, part number along with it=92s version number). Expires 05/07/2005 URN Namespace for the CLEI Code [Page 1] =0C Internet Draft 11/07/2004 Table of Contents 1 Introduction .............................................. 3 2 Specification Template .................................... 3 3 Examples .................................................. 5 4 Security Considerations ................................... 5 5 IANA Considerations ....................................... 6 6 Intellectual Property ..................................... 6 7 Acknowledgments ........................................... 6 8 Normative References ...................................... 7 9 Author's Address .......................................... 7 Full Copyright Statement ................................... 7 Expires 05/07/2005 URN Namespace for the CLEI Code [Page 2] =0C Internet Draft 11/07/2004 1. Introduction Many circuit cards used in the global telecommunications network have a CLEI Code assigned and have a bar code or two-dimensional symbol on a label affixed to the front of that circuit card. Service providers utilize the CLEI Code to: o Track inventory, both working and spare o Logistics (movement of circuit cards, along with the serial number) o Provision equipment o Maintain asset records (accounting information) The goal of the CLEI namespace is to ensure the stability and uniqueness of the names of various (specific) items that are used within the messages exchanged between equipment used in the global telecommunications network. The assigned maintenance agent for the CLEI Code, Telcordia Technologies, is responsible for assigning certain equipment and other identifiers (e.g., location, manufacturer/supplier) for the telecommunications industry. The code assignment process identifies the structure and intelligence of the CLEI Code to identify the circuit card=92s form, fit, functions, and features. Equipment may exist in multiple physical locations with the exact same form, fit, functions, and features and will have the same CLEI Code if their Product ID is the same. 2. Specification Template Namespace ID: "CLEI" Registration Information: Version 1 Date: 2004-11-07 Declared registrant of the namespace: Telcordia Technologies, Inc. Customer Support Center 8 Corporate Place Expires 05/07/2005 URN Namespace for the CLEI Code [Page 3] =0C Internet Draft 11/07/2004 Piscataway, NJ 08854 U.S.A. +1.732.699.5577 http://www.commonlanguage.com Declaration of syntactic structures: The structure of the Namespace Specific String is a flat space of 10 characters as defined in [T1.213][T1.213a]. Relevant ancillary Documentation: [T1.213] and [T1.213a]. Identifier uniqueness considerations: Identifiers are assigned by Telcordia URN registration that guarantees Uniqueness for items with different form, fit, functions, and features. This is simply achieved by keeping track of already assigned names and comparing all new proposed names to the database ones. If the name already exists a new one is created per the rules of the process. See [T1.213][T1.213a] for assignment examples. Identifiers persistence considerations: The process defined by ANSI and the CLEI maintenance agent ensure the binding between the name and its resource is permanent, and that names are not reassigned. Process of identifiers assignment: A CLEI Code is an intelligent code that consists of 10 alpha- numeric characters with 4 data elements. The first data element is considered the basic code with the first 2 characters indicating the technology or equipment type with the third and fourth characters denoting the functional sub-category. The second data element represents the features and its three characters denote functional capabilities or changes. The third data element has one character and denotes a reference to manufacturer, system ID, specification or drawing. The fourth data element consists of two characters and contains complementary data. These two characters provide a means of differentiating or providing uniqueness between the eight character CLEI Codes by identifying the manufacturing vintage of the product. Names are assigned via procedures defined in [GR485]. Process for identifier resolution: Expires 05/07/2005 URN Namespace for the CLEI Code [Page 4] =0C Internet Draft 11/07/2004 Telcordia URNs are resolved via Telcordia resolvers run under Telcordia responsibility. For further information see www.commonlanguage.com. Rules for lexical equivalence: URNs are lexically equivalent if they are lexically identical. See [T1.213] and [T1.213a] for further information. Conformance with URN syntax: No special consideration. Validation mechanism: None specified. Scope: Global. 3. Examples The following three examples are based on the examples provided in [T1.213a], and correspond with three different sets of features by three different manufacturers (Nortel Networks, Lear and Lucent Technologies) producing "D4CE" (a particular D4 channel bank type) equipment. The fourth example refers to a SONET power unit convertor of Alcatel. URN:CLEI:D4CE18B7AA URN:CLEI:D4CE4248AA URN:CLEI:D4CE363PAB URN:CLEI:SNPWBBC7AA 4. Security Considerations There are no additional security considerations other than those normally associated with the use and resolution of URNs in general. It is noted however that attempting to resolve a Telcordia URN through a resolver other than the one provided by Telcordia is not considered authoritative. Expires 05/07/2005 URN Namespace for the CLEI Code [Page 5] =0C Internet Draft 11/07/2004 5. IANA Considerations The IANA has registered formal URN namespace ????, to Telcordia within the IANA registry of URN NIDs. 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. Acknowledgments The contributions of the Entity MIB Working Group members are gratefully acknowledged. Special thanks go to Mike Heard, Juergen Schoenwaelder, Dave Perkins and Dan Romascanu. Expires 05/07/2005 URN Namespace for the CLEI Code [Page 6] =0C Internet Draft 11/07/2004 8. Normative References [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "Uniform Resource Name (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [T1.213] ATIS T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, 2001, www.ansi.org [T1.213a] ATIS T1.213a, Supplement to T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, to correct the representation of the Basic Code in Figure B.1, 2001, www.ansi.org [GR485] GR-485-CORE, COMMON LANGUAGE Equipment Codes (CLEI Codes) =AD Generic Requirements for Processes And Guidelines, Issue 5, Telcordia Technologies, April 2004. 9. Author's Address Kaj Tesink One Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699-6068 EMail: kaj@research.telcordia.com Robert H. Fox 3545 S.Ocean Blvd, #417 Palm Beach, FL 33480-5715 USA Phone: +1 732 699-8968 EMail: rfox@telcordia.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any Expires 05/07/2005 URN Namespace for the CLEI Code [Page 7] =0C Internet Draft 11/07/2004 kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 05/07/2005 URN Namespace for the CLEI Code [Page 8] =0C Internet Draft 11/07/2004 ************************************************************ * NOTES TO RFC Editor (to be removed prior to publication) * * * * Please replace "????" in the IANA Considerations section * * with an IANA-assigned URN NID. * * * ************************************************************ Expires 05/07/2005 URN Namespace for the CLEI Code [Page 9] =0C Internet Draft 11/07/2004 Table of Contents 1 Introduction .............................................. 3 2 Specification Template .................................... 3 3 Examples .................................................. 5 4 Security Considerations ................................... 5 5 IANA Considerations ....................................... 6 6 Intellectual Property ..................................... 6 7 Acknowledgments ........................................... 6 8 Normative References ...................................... 7 9 Author's Address .......................................... 7 Full Copyright Statement ................................... 7 Expires 05/07/2005 URN Namespace for the CLEI Code [Page 10] --=====================_164294232==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib --=====================_164294232==_-- From entmib-bounces@ietf.org Thu Dec 9 18:48:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29242 for ; Thu, 9 Dec 2004 18:48:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcXx9-0002Qj-VW; Thu, 09 Dec 2004 18:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcXs6-0001Tl-I0 for entmib@megatron.ietf.org; Thu, 09 Dec 2004 18:38:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28464 for ; Thu, 9 Dec 2004 18:38:52 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcXzB-0005im-2k for entmib@ietf.org; Thu, 09 Dec 2004 18:46:13 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iB9Nahcu024488; Thu, 9 Dec 2004 18:36:43 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA21315; Thu, 9 Dec 2004 18:36:42 -0500 (EST) Message-Id: <6.1.2.0.2.20041209172445.0448e960@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 09 Dec 2004 18:36:38 -0500 To: Andy Bierman From: Kaj Tesink Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: <4.3.2.7.2.20041209092434.026466b8@fedex.cisco.com> References: <4.3.2.7.2.20041208160349.025f4d60@fedex.cisco.com> <4.3.2.7.2.20041208192619.0260fd50@fedex.cisco.com> <4.3.2.7.2.20041209092434.026466b8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Margaret Wasserman , entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 12:32 PM 12/9/2004, Andy Bierman wrote: [..snip..] > > > >the string in the Uri object, at least for the CLEI > >application is well formatted and defined. IANA registries > >http://www.iana.org/assignments/uri-schemes and > >http://www.iana.org/assignments/urn-namespaces > >are there to help sort things out, no? > >The documentation I was provided for this object (especially the >OBJECT-TYPE macro) did not convey any of this info, rationale, >or references. If it did, I wouldn't have objected to the >vagueness of the object. > >I still don't understand why we need a list of URIs per entity. >This adds complexity. It there a compelling need for multiple >URIs per entity? from a CLEI perspective a single URI per entity would be sufficient. however, in the discussion i think it was argued that other or multiple things may be of interest. it seems easy to parse (and at least display it) so the cost in terms of complexity seems low. looking at beefing up the description, one way to work it is to beef up section 2.12.1 (or you may prefer to port selected portions to the DESCRIPTION clause), e.g., - entPhysicalUris This object provides additional identification information about the physical entity. The object contains one or more Uniform Resource Identifiers (URIs) and therefore the syntax of this object must conform to RFC 2396 [RFC2396] section 2. Uniform Resource Names (URNs) are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference. URNs are part of the larger URI family with the specific goal of providing persistent naming of resources. URI schemes and URN name spaces are registered by IANA (see http://www.iana.org/assignments/uri-schemes and http://www.iana.org/assignments/urn-namespaces. The entPhysicalUris object may be used to encode for example a URI containing a Common Language Equipment Identifier (CLEI) URI for the managed physical entity. The URN name space for CLEIs is defined in [RFC CLEIURN], and the CLEI format is defined in [T1.213][T1.213a]. For example, an entPhysicalUris instance may have the value of URN:CLEI:D4CE18B7AA [RFC2396] and [RFCCLEIURN] identify this as a URI in the CLEI URN name space, and the specific CLEI code, D4CE18B7AA is based on the example provided in [T1.213a]. Multiple URIs may be present and are separated by white space characters. Leading and trailing white space characters are ignored. If no additional identification information is known or supported about the physical entity the object is not instantiated. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFCCLEIURN] Tesink, K., and Robert H. Fox, "A Uniform Resource Name (URN) Namespace for the CLEI Code", Work in progress, November 7, 2004. [T1.213] ATIS T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, 2001, www.ansi.org [T1.213a] ATIS T1.213a, Supplement to T1.213-2001, Coded Identification of Equipment Entities in the North American Telecommunications System for Information Exchange, to correct the representation of the Basic Code in Figure B.1, 2001, www.ansi.org > >kaj > >Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Fri Dec 10 16:40:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00585 for ; Fri, 10 Dec 2004 16:40:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcsPB-0007V5-Dq; Fri, 10 Dec 2004 16:34:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcsHu-0002XW-3Y for entmib@megatron.ietf.org; Fri, 10 Dec 2004 16:26:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26811 for ; Fri, 10 Dec 2004 16:26:51 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcsP9-0000Kv-FU for entmib@ietf.org; Fri, 10 Dec 2004 16:34:23 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iBALQEcu017619; Fri, 10 Dec 2004 16:26:14 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA29537; Fri, 10 Dec 2004 16:26:13 -0500 (EST) Message-Id: <6.1.2.0.2.20041210125112.01d6d008@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Dec 2004 14:01:43 -0500 To: Andy Bierman From: Kaj Tesink Subject: Re: [Entmib] entPhysicalUris object wrap-up In-Reply-To: <4.3.2.7.2.20041208081842.01fdcbc8@fedex.cisco.com> References: <4.3.2.7.2.20041208081842.01fdcbc8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_253135269==_" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org --=====================_253135269==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 11:56 AM 12/8/2004, Andy Bierman wrote: [..snip..] >4) examples > >I don't really have time (or enough info) to fill in the >examples in section 4, but I know somebody will eventually >ask about this before RFC publication. I would really >appreciate some help updating the examples. (I need to >add an example for entPhysicalClass==cpu(12) as well.) >Any volunteers? (4.1 and 4.2 can be done independently) >I would like to get this over with now ;-) andy, we came up with some acme-compatible URIs for the examples below; see additions. also included the MfgDate. included examples for both instantiated and non-instantiated cases. kaj -------------------------------------------------------------------- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --=====================_253135269==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="example.txt" 4.1. Router/Bridge A router containing two slots. Each slot contains a 3 port router/bridge module. Each port is represented in the ifTable. There are two logical instances of OSPF running and two logical bridges: Physical entities -- entPhysicalTable: 1 Field-replaceable physical chassis: entPhysicalDescr.1 == 'Acme Chassis Model 100' entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 entPhysicalContainedIn.1 == 0 entPhysicalClass.1 == chassis(3) entPhysicalParentRelPos.1 == 0 entPhysicalName.1 == '100-A' entPhysicalHardwareRev.1 == 'A(1.00.02)' entPhysicalSoftwareRev.1 == '' entPhysicalFirmwareRev.1 == '' entPhysicalSerialNum.1 == 'C100076544' entPhysicalMfgName.1 == 'Acme' entPhysicalModelName.1 == '100' entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' entPhysicalAssetID.1 == '0007372293' entPhysicalIsFRU.1 == true(1) entPhysicalMfgDate.1 2002-5-26,13:30:30.0,-4:0 entPhysicalUris.1 URN:CLEI:CNME120ARA 2 slots within the chassis: entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' entPhysicalVendorType.2 == acmeProducts.slotTypes.1 entPhysicalContainedIn.2 == 1 entPhysicalClass.2 == container(5) entPhysicalParentRelPos.2 == 1 entPhysicalName.2 == 'S1' entPhysicalHardwareRev.2 == 'B(1.00.01)' entPhysicalSoftwareRev.2 == '' entPhysicalFirmwareRev.2 == '' entPhysicalSerialNum.2 == '' entPhysicalMfgName.2 == 'Acme' entPhysicalModelName.2 == 'AA' entPhysicalAlias.2 == '' entPhysicalAssetID.2 == '' entPhysicalIsFRU.2 == false(2) entPhysicalMfgDate.2 2002-7-26,12:22:12.0,-4:0 entPhysicalUris.2 URN:CLEI:CNME123ARA entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' entPhysicalVendorType.3 = acmeProducts.slotTypes.1 entPhysicalContainedIn.3 == 1 entPhysicalClass.3 == container(5) entPhysicalParentRelPos.3 == 2 entPhysicalName.3 == 'S2' entPhysicalHardwareRev.3 == '1.00.07' entPhysicalSoftwareRev.3 == '' entPhysicalFirmwareRev.3 == '' entPhysicalSerialNum.3 == '' entPhysicalMfgName.3 == 'Acme' entPhysicalModelName.3 == 'AA' entPhysicalAlias.3 == '' entPhysicalAssetID.3 == '' entPhysicalIsFRU.3 == false(2) entPhysicalMfgDate.3 2002-7-26,12:12:12.0,-4:0 entPhysicalUris.3 URN:CLEI:CNME123ARA 2 Field-replaceable modules: Slot 1 contains a module with 3 ports: entPhysicalDescr.4 == 'Acme Router-100' entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 entPhysicalContainedIn.4 == 2 entPhysicalClass.4 == module(9) entPhysicalParentRelPos.4 == 1 entPhysicalName.4 == 'M1' entPhysicalHardwareRev.4 == '1.00.07' entPhysicalSoftwareRev.4 == '1.4.1' entPhysicalFirmwareRev.4 == 'A(1.1)' entPhysicalSerialNum.4 == 'C100087363' entPhysicalMfgName.4 == 'Acme' entPhysicalModelName.4 == 'R100-FE' entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' entPhysicalAssetID.4 == '0007372462' entPhysicalIsFRU.4 == true(1) entPhysicalMfgDate.4 2003-7-18,13:30:30.0,-4:0 entPhysicalUris.4 URN:CLEI:CNRU123CAA entPhysicalDescr.5 == 'Acme Ethernet-100 Port' entPhysicalVendorType.5 == acmeProducts.portTypes.2 entPhysicalContainedIn.5 == 4 entPhysicalClass.5 == port(10) entPhysicalParentRelPos.5 == 1 entPhysicalName.5 == 'P1' entPhysicalHardwareRev.5 == 'G(1.02)' entPhysicalSoftwareRev.5 == '' entPhysicalFirmwareRev.5 == '1.1' entPhysicalSerialNum.5 == '' entPhysicalMfgName.5 == 'Acme' entPhysicalModelName.5 == 'FE-100' entPhysicalAlias.5 == '' entPhysicalAssetID.5 == '' entPhysicalIsFRU.5 == false(2) entPhysicalMfgDate.5 2003-7-18,14:20:22.0,-4:0 entPhysicalUris.5 URN:CLEI:CNMES23ARA entPhysicalDescr.6 == 'Acme Ethernet-100 Port' entPhysicalVendorType.6 == acmeProducts.portTypes.2 entPhysicalContainedIn.6 == 4 entPhysicalClass.6 == port(10) entPhysicalParentRelPos.6 == 2 entPhysicalName.6 == 'P2' entPhysicalHardwareRev.6 == 'G(1.02)' entPhysicalSoftwareRev.6 == '' entPhysicalFirmwareRev.6 == '1.1' entPhysicalSerialNum.6 == '' entPhysicalMfgName.6 == 'Acme' entPhysicalModelName.6 == 'FE-100' entPhysicalAlias.6 == '' entPhysicalAssetID.6 == '' entPhysicalIsFRU.6 == false(2) entPhysicalMfgDate.6 2003-7-19,10:15:15.0,-4:0 entPhysicalUris.6 URN:CLEI:CNMES23ARA entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' entPhysicalVendorType.7 == acmeProducts.portTypes.3 entPhysicalContainedIn.7 == 4 entPhysicalClass.7 == port(10) entPhysicalParentRelPos.7 == 3 entPhysicalName.7 == 'P3' entPhysicalHardwareRev.7 == 'B(1.03)' entPhysicalSoftwareRev.7 == '2.5.1' entPhysicalFirmwareRev.7 == '2.5F' entPhysicalSerialNum.7 == '' entPhysicalMfgName.7 == 'Acme' entPhysicalModelName.7 == 'FDDI-100' entPhysicalAlias.7 == '' entPhysicalAssetID.7 == '' entPhysicalIsFRU.7 == false(2) Slot 2 contains another 3-port module: entPhysicalDescr.8 == 'Acme Router-100 Comm Module' entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 entPhysicalContainedIn.8 == 3 entPhysicalClass.8 == module(9) entPhysicalParentRelPos.8 == 1 entPhysicalName.8 == 'M2' entPhysicalHardwareRev.8 == '2.01.00' entPhysicalSoftwareRev.8 == '3.0.7' entPhysicalFirmwareRev.8 == 'A(1.2)' entPhysicalSerialNum.8 == 'C100098732' entPhysicalMfgName.8 == 'Acme' entPhysicalModelName.8 == 'C100' entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' entPhysicalAssetID.8 == '0007373982' entPhysicalIsFRU.8 == true(1) entPhysicalMfgDate.8 2002-5-26,13:30:15.0,-4:0 entPhysicalUris.8 URN:CLEI:CNRT321MAA entPhysicalDescr.9 == 'Acme Fddi-100 Port' entPhysicalVendorType.9 == acmeProducts.portTypes.5 entPhysicalContainedIn.9 == 8 entPhysicalClass.9 == port(10) entPhysicalParentRelPos.9 == 1 entPhysicalName.9 == 'FDDI Primary' entPhysicalHardwareRev.9 == 'CC(1.07)' entPhysicalSoftwareRev.9 == '2.0.34' entPhysicalFirmwareRev.9 == '1.1' entPhysicalSerialNum.9 == '' entPhysicalMfgName.9 == 'Acme' entPhysicalModelName.9 == 'FDDI-100' entPhysicalAlias.9 == '' entPhysicalAssetID.9 == '' entPhysicalIsFRU.9 == false(2) entPhysicalDescr.10 == 'Acme Ethernet-100 Port' entPhysicalVendorType.10 == acmeProducts.portTypes.2 entPhysicalContainedIn.10 == 8 entPhysicalClass.10 == port(10) entPhysicalParentRelPos.10 == 2 entPhysicalName.10 == 'Ethernet A' entPhysicalHardwareRev.10 == 'G(1.04)' entPhysicalSoftwareRev.10 == '' entPhysicalFirmwareRev.10 == '1.3' entPhysicalSerialNum.10 == '' entPhysicalMfgName.10 == 'Acme' entPhysicalModelName.10 == 'FE-100' entPhysicalAlias.10 == '' entPhysicalAssetID.10 == '' entPhysicalIsFRU.10 == false(2) entPhysicalMfgDate.10 2002-7-26,13:30:15.0,-4:0 entPhysicalUris.10 URN:CLEI:CNMES23ARA entPhysicalDescr.11 == 'Acme Ethernet-100 Port' entPhysicalVendorType.11 == acmeProducts.portTypes.2 entPhysicalContainedIn.11 == 8 entPhysicalClass.11 == port(10) entPhysicalParentRelPos.11 == 3 entPhysicalName.11 == 'Ethernet B' entPhysicalHardwareRev.11 == 'G(1.04)' entPhysicalSoftwareRev.11 == '' entPhysicalFirmwareRev.11 == '1.3' entPhysicalSerialNum.11 == '' entPhysicalMfgName.11 == 'Acme' entPhysicalModelName.11 == 'FE-100' entPhysicalAlias.11 == '' entPhysicalAssetID.11 == '' entPhysicalIsFRU.11 == false(2) entPhysicalMfgDate.11 2002-8-16,15:35:15.0,-4:0 entPhysicalUris.11 URN:CLEI:CNMES23ARA --=====================_253135269==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib --=====================_253135269==_-- From entmib-bounces@ietf.org Fri Dec 10 18:56:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12048 for ; Fri, 10 Dec 2004 18:56:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcuXy-0008HJ-S3; Fri, 10 Dec 2004 18:51:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcuUr-0007dt-Iq for entmib@megatron.ietf.org; Fri, 10 Dec 2004 18:48:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11722 for ; Fri, 10 Dec 2004 18:48:22 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccuc8-0003is-Ob for entmib@ietf.org; Fri, 10 Dec 2004 18:55:57 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id BC31137AA; Sat, 11 Dec 2004 00:47:52 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27212-07; Sat, 11 Dec 2004 00:47:51 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id F095537A9; Sat, 11 Dec 2004 00:47:51 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CcuUJ-0000gg-RR; Sat, 11 Dec 2004 00:47:51 +0100 Date: Sat, 11 Dec 2004 00:47:51 +0100 From: Juergen Schoenwaelder To: Kaj Tesink Subject: Re: [Entmib] CLEI Code URN draft Message-ID: <20041210234751.GB2165@james> Mail-Followup-To: Kaj Tesink , entmib@ietf.org References: <6.1.2.0.2.20041202174321.03c33378@shannon.research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20041202174321.03c33378@shannon.research.telcordia.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Thu, Dec 02, 2004 at 06:44:15PM -0500, Kaj Tesink wrote: > The following three examples are based on the examples provided in > [T1.213a], and correspond with three different sets of features by > three different manufacturers (Nortel Networks, Lear and Lucent > Technologies) producing "D4CE" (a particular D4 channel bank type) > equipment. The fourth example refers to a SONET power unit convertor > of Alcatel. > > > URN:CLEI:D4CE18B7AA > URN:CLEI:D4CE4248AA > URN:CLEI:D4CE363PAB > URN:CLEI:SNPWBBC7AA Are these URNs always uppercase? Does case matter here? Would some or all of the following be illegal? urn:CLEI:D4CE18B7AA urn:clei:D4CE18B7AA urn:clei:d4ce18b7aa urn:CLEI:D4CE18B7AA URN:CLEI:d4ce18b7aa URN:clei:d4ce18b7aa URN:clei:D4CE18B7AA According to RFC 2141, the leading "urn:" sequence is case-insensitive. What about the rest? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Dec 13 14:16:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09827 for ; Mon, 13 Dec 2004 14:16:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdvf1-0001Ob-A3; Mon, 13 Dec 2004 14:15:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdvW9-00081c-SU for entmib@megatron.ietf.org; Mon, 13 Dec 2004 14:05:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09404 for ; Mon, 13 Dec 2004 14:05:56 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdve1-0006UN-JY for entmib@ietf.org; Mon, 13 Dec 2004 14:14:05 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iBDJ5Icu008268; Mon, 13 Dec 2004 14:05:18 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA17694; Mon, 13 Dec 2004 14:05:17 -0500 (EST) Message-Id: <6.1.2.0.2.20041213135246.04146288@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 13 Dec 2004 13:55:57 -0500 To: j.schoenwaelder@iu-bremen.de From: Kaj Tesink Subject: Re: [Entmib] CLEI Code URN draft In-Reply-To: <20041210234751.GB2165@james> References: <6.1.2.0.2.20041202174321.03c33378@shannon.research.telcordia.com> <20041210234751.GB2165@james> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 06:47 PM 12/10/2004, Juergen Schoenwaelder wrote: >On Thu, Dec 02, 2004 at 06:44:15PM -0500, Kaj Tesink wrote: > > > The following three examples are based on the examples provided in > > [T1.213a], and correspond with three different sets of features by > > three different manufacturers (Nortel Networks, Lear and Lucent > > Technologies) producing "D4CE" (a particular D4 channel bank type) > > equipment. The fourth example refers to a SONET power unit convertor > > of Alcatel. > > > > > > URN:CLEI:D4CE18B7AA > > URN:CLEI:D4CE4248AA > > URN:CLEI:D4CE363PAB > > URN:CLEI:SNPWBBC7AA > >Are these URNs always uppercase? Does case matter here? Would some or >all of the following be illegal? > > urn:CLEI:D4CE18B7AA > urn:clei:D4CE18B7AA > urn:clei:d4ce18b7aa > urn:CLEI:D4CE18B7AA > URN:CLEI:d4ce18b7aa > URN:clei:d4ce18b7aa > URN:clei:D4CE18B7AA > >According to RFC 2141, the leading "urn:" sequence is case-insensitive. >What about the rest? thanks, good catch; the rest is up to the particular name space. in the CLEI case i believe that CLEI codes are always uppercase. i'll fix that in the CLEI URN name space request together with the format issues that Bert found. kaj >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Dec 13 18:32:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08591 for ; Mon, 13 Dec 2004 18:32:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdzaj-000702-3X; Mon, 13 Dec 2004 18:26:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdzV6-0004rC-Um for entmib@megatron.ietf.org; Mon, 13 Dec 2004 18:21:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07921 for ; Mon, 13 Dec 2004 18:21:06 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdzcx-0005tX-BW for entmib@ietf.org; Mon, 13 Dec 2004 18:29:18 -0500 Received: from shannon.research.telcordia.com (shannon-83.research.telcordia.com [128.96.83.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iBDNKRwX018616; Mon, 13 Dec 2004 18:20:27 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA00784; Mon, 13 Dec 2004 18:20:27 -0500 (EST) Message-Id: <6.1.2.0.2.20041213171740.01de1df8@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 13 Dec 2004 17:27:46 -0500 To: j.schoenwaelder@iu-bremen.de From: Kaj Tesink Subject: Fwd: Re: [Entmib] CLEI Code URN draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org >Date: Mon, 13 Dec 2004 13:55:57 -0500 >To: j.schoenwaelder@iu-bremen.de >From: Kaj Tesink >Subject: Re: [Entmib] CLEI Code URN draft >Cc: entmib@ietf.org > >At 06:47 PM 12/10/2004, Juergen Schoenwaelder wrote: >>On Thu, Dec 02, 2004 at 06:44:15PM -0500, Kaj Tesink wrote: >> >> > The following three examples are based on the examples provided in >> > [T1.213a], and correspond with three different sets of features by >> > three different manufacturers (Nortel Networks, Lear and Lucent >> > Technologies) producing "D4CE" (a particular D4 channel bank type) >> > equipment. The fourth example refers to a SONET power unit convertor >> > of Alcatel. >> > >> > >> > URN:CLEI:D4CE18B7AA >> > URN:CLEI:D4CE4248AA >> > URN:CLEI:D4CE363PAB >> > URN:CLEI:SNPWBBC7AA >> >>Are these URNs always uppercase? Does case matter here? Would some or >>all of the following be illegal? >> >> urn:CLEI:D4CE18B7AA >> urn:clei:D4CE18B7AA >> urn:clei:d4ce18b7aa >> urn:CLEI:D4CE18B7AA >> URN:CLEI:d4ce18b7aa >> URN:clei:d4ce18b7aa >> URN:clei:D4CE18B7AA >> >>According to RFC 2141, the leading "urn:" sequence is case-insensitive. >>What about the rest? > > >thanks, good catch; the rest is up to the particular name space. >in the CLEI case i believe that CLEI codes are always >uppercase. >i'll fix that in the CLEI URN name space request >together with the format issues that Bert found. i verified with the CLEI gurus; it turns out that while CLEI codes are usually represented in uppercase, the codes are actually case-insensitive. as a result, i suggest that we clarify the lexical equivalence clause as follows: Rules for lexical equivalence: Lexical equivalence of two CLEI URN namespace specific strings is defined as an exact, case-insensitive string match. CLEI codes are assigned in a case-insensitive fashion, so that there will not be two CLEI codes that differ only in case. See [T1.213] and [T1.213a] for further information. kaj >kaj > > > >>/js >> >>-- >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, 28725 Bremen, Germany >> >>_______________________________________________ >>Entmib mailing list >>Entmib@ietf.org >>https://www1.ietf.org/mailman/listinfo/entmib > > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > >Kaj Tesink >Telcordia Technologies. Inc. >One Telcordia drive >Piscataway, NJ 08854 >Email: kaj@research.telcordia.com >Tel: (732) 699-6068 >Fax: (732) 336-2336 > >_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Dec 13 21:39:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20820 for ; Mon, 13 Dec 2004 21:39:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce2Yv-0002Y1-7B; Mon, 13 Dec 2004 21:37:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce2U0-0001db-NT for entmib@megatron.ietf.org; Mon, 13 Dec 2004 21:32:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20508 for ; Mon, 13 Dec 2004 21:32:11 -0500 (EST) Received: from cardinal.mail.pas.earthlink.net ([207.217.121.226]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce2bw-0001bg-Df for entmib@ietf.org; Mon, 13 Dec 2004 21:40:24 -0500 Received: from h-69-3-24-26.snvacaid.dynamic.covad.net ([69.3.24.26] helo=oemcomputer) by cardinal.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Ce2Ty-00051c-00 for entmib@ietf.org; Mon, 13 Dec 2004 18:32:10 -0800 Message-ID: <002501c4e185$24357680$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.1.2.0.2.20041213171740.01de1df8@128.96.81.11> Subject: Re: Re: [Entmib] CLEI Code URN draft Date: Mon, 13 Dec 2004 18:32:22 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Hi - > From: "Kaj Tesink" > To: > Cc: > Sent: Monday, December 13, 2004 2:27 PM > Subject: Fwd: Re: [Entmib] CLEI Code URN draft ... > i verified with the CLEI gurus; it turns out that while CLEI codes > are usually represented in uppercase, the codes are actually case-insensitive. > > as a result, i suggest that we clarify the lexical equivalence clause > as follows: > > Rules for lexical equivalence: > > Lexical equivalence of two CLEI URN namespace specific strings > is defined as an exact, case-insensitive string match. CLEI codes > are assigned in a case-insensitive fashion, so that there will > not be two CLEI codes that differ only in case. > See [T1.213] and [T1.213a] for further information. ... Wouldn't it be simpler to say that CLEI codes MUST be upper case? Randy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Tue Dec 14 15:22:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13861 for ; Tue, 14 Dec 2004 15:22:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeJ5Y-0002xz-B5; Tue, 14 Dec 2004 15:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeJ1G-0000sP-CP for entmib@megatron.ietf.org; Tue, 14 Dec 2004 15:11:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12480 for ; Tue, 14 Dec 2004 15:11:37 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeJ9K-0004N4-K6 for entmib@ietf.org; Tue, 14 Dec 2004 15:20:00 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iBEKAqwX005987; Tue, 14 Dec 2004 15:10:52 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA01109; Tue, 14 Dec 2004 15:10:51 -0500 (EST) Message-Id: <6.1.2.0.2.20041214150730.01d67ec0@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 14 Dec 2004 15:10:46 -0500 To: "Randy Presuhn" From: Kaj Tesink Subject: Re: Re: [Entmib] CLEI Code URN draft In-Reply-To: <002501c4e185$24357680$7f1afea9@oemcomputer> References: <6.1.2.0.2.20041213171740.01de1df8@128.96.81.11> <002501c4e185$24357680$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 09:32 PM 12/13/2004, Randy Presuhn wrote: >Hi - > > > From: "Kaj Tesink" > > To: > > Cc: > > Sent: Monday, December 13, 2004 2:27 PM > > Subject: Fwd: Re: [Entmib] CLEI Code URN draft >... > > i verified with the CLEI gurus; it turns out that while CLEI codes > > are usually represented in uppercase, the codes are actually > case-insensitive. > > > > as a result, i suggest that we clarify the lexical equivalence clause > > as follows: > > > > Rules for lexical equivalence: > > > > Lexical equivalence of two CLEI URN namespace specific strings > > is defined as an exact, case-insensitive string match. CLEI codes > > are assigned in a case-insensitive fashion, so that there will > > not be two CLEI codes that differ only in case. > > See [T1.213] and [T1.213a] for further information. >... > >Wouldn't it be simpler to say that CLEI codes MUST be upper case? maybe so, but as i understand it T1.213 is case-insensitive, so restricting the URN name space to upper case seems inappropriate. kaj >Randy > > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Tue Dec 14 16:55:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25749 for ; Tue, 14 Dec 2004 16:55:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeKNa-0007co-VY; Tue, 14 Dec 2004 16:38:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeKFq-0002Uz-QB for entmib@megatron.ietf.org; Tue, 14 Dec 2004 16:30:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22420 for ; Tue, 14 Dec 2004 16:30:45 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeKNv-0007SI-R0 for entmib@ietf.org; Tue, 14 Dec 2004 16:39:08 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 418EC3FF9; Tue, 14 Dec 2004 22:30:05 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 15996-04; Tue, 14 Dec 2004 22:30:04 +0100 (CET) Received: from james (Ia569.i.pppool.de [85.73.165.105]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 2546B3B82; Tue, 14 Dec 2004 22:30:04 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CeKF9-0000c0-EF; Tue, 14 Dec 2004 22:30:03 +0100 Date: Tue, 14 Dec 2004 22:30:03 +0100 From: Juergen Schoenwaelder To: Kaj Tesink Subject: Re: Re: [Entmib] CLEI Code URN draft Message-ID: <20041214213003.GA2319@james> Mail-Followup-To: Kaj Tesink , Randy Presuhn , entmib@ietf.org References: <6.1.2.0.2.20041213171740.01de1df8@128.96.81.11> <002501c4e185$24357680$7f1afea9@oemcomputer> <6.1.2.0.2.20041214150730.01d67ec0@128.96.81.11> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20041214150730.01d67ec0@128.96.81.11> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Randy Presuhn , entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Tue, Dec 14, 2004 at 03:10:46PM -0500, Kaj Tesink wrote: > maybe so, but as i understand it T1.213 is case-insensitive, > so restricting the URN name space to upper case seems inappropriate. So then this is fine. I just want to have clarity. Case conversions are really trivial since we do not have to deal with international character sets. No need to optimize for this I would say. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Tue Dec 14 17:05:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26810 for ; Tue, 14 Dec 2004 17:05:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeKhx-00049K-VW; Tue, 14 Dec 2004 16:59:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeKbP-0002fb-MZ for entmib@megatron.ietf.org; Tue, 14 Dec 2004 16:53:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25596 for ; Tue, 14 Dec 2004 16:53:01 -0500 (EST) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeKjU-0008Tq-Li for entmib@ietf.org; Tue, 14 Dec 2004 17:01:26 -0500 Received: from h-66-167-121-241.snvacaid.dynamic.covad.net ([66.167.121.241] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CeKbK-0004lx-00 for entmib@ietf.org; Tue, 14 Dec 2004 13:52:58 -0800 Message-ID: <00e601c4e227$4eb36c80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.1.2.0.2.20041213171740.01de1df8@128.96.81.11><002501c4e185$24357680$7f1afea9@oemcomputer> <6.1.2.0.2.20041214150730.01d67ec0@128.96.81.11> Subject: Re: Re: [Entmib] CLEI Code URN draft Date: Tue, 14 Dec 2004 13:53:12 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Hi - > From: "Kaj Tesink" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, December 14, 2004 12:10 PM > Subject: Re: Re: [Entmib] CLEI Code URN draft ... > >Wouldn't it be simpler to say that CLEI codes MUST be upper case? > > > maybe so, but as i understand it T1.213 is case-insensitive, > so restricting the URN name space to upper case seems inappropriate. ... My concerns are mailnly with regard to the future if these things prove useful. 1) consider what it would take to describe the behaviour of read-write objects that used these (after a write, would the value read be bit-for-bit identical, or merely fit the matching rules?) 2) if they were used for indexing... If their definition is already case insensitive, then I think we'd really be better off deciding what their "canonical" representation should be for our purposes. However, I freely admit this is a theoretical concern, and that if we don't imagine these being used in other MIB object definitions, there's less need to worry about it. Randy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 15 08:55:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01408 for ; Wed, 15 Dec 2004 08:55:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeZWk-0004GW-AR; Wed, 15 Dec 2004 08:49:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeZQk-0002wx-I0 for entmib@megatron.ietf.org; Wed, 15 Dec 2004 08:43:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00760 for ; Wed, 15 Dec 2004 08:43:00 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeZYy-0005sE-Ub for entmib@ietf.org; Wed, 15 Dec 2004 08:51:33 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBFDgOu07650 for ; Wed, 15 Dec 2004 08:42:25 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Dec 2004 08:42:26 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4021DE337@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] WG LAST CALL: draft-ietf-entmib-state-05.txt Date: Wed, 15 Dec 2004 08:42:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org hi I've context switched back to this and should have proposed resolutions out this week. Sharon -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Monday, November 29, 2004 9:44 PM To: Chisholm, Sharon [CAR:5K50:EXCH]; entmib@ietf.org Subject: RE: [Entmib] WG LAST CALL: draft-ietf-entmib-state-05.txt Hi Sharon, When do you expect to have an update to address these issue? I think we are well beyond the point of diminishing returns on this document, and I hope we can get it into the IESG within the next few weeks... Do you think that is possible? Margaret At 3:27 PM -0400 9/30/04, Sharon Chisholm wrote: >hi > >I've opened tickets to track all of the issues except 'e', which is a >previously discussed and closed issue. I likely crammed too many points >into the first one. Time will tell. > >648 Wordsmith - Various >651 Notification Description Changes >649 Clarification on 'this information' >652 Security Considerations Text Changes >650 Rename to ENTITY-STATE-TC-MIB >653 Don't need to import the textual conventions? > >Sharon _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 15 13:36:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26356 for ; Wed, 15 Dec 2004 13:36:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CedeX-000772-Ut; Wed, 15 Dec 2004 13:13:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CedVz-00046o-K0 for entmib@megatron.ietf.org; Wed, 15 Dec 2004 13:04:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23459 for ; Wed, 15 Dec 2004 13:04:40 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CedeG-0004wg-AX for entmib@ietf.org; Wed, 15 Dec 2004 13:13:16 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBFI46Z07458 for ; Wed, 15 Dec 2004 13:04:06 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Dec 2004 13:04:06 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4021DE67C@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 15 Dec 2004 13:03:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [Entmib] entstate-648 Wordsmith - various (A, B, C, G, H) X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org hi Rest of #648 to be sent in separate email. a) Section says: Usage state indicates whether or not the entity is in use at a specific instance, and if so, whether or not it currently has spare capacity to serve additional users. In the context of this MIB, the user is equivalent to an entity, so this term is substituted. This state refers to the ability of the entity to service other entities within its containment hierarchy. I think this can be made shorter without loosing significance: Usage state indicates whether or not the entity is in use at a specific instance, and if so, whether or not it currently has spare capacity to serve additional users. In the context of this MIB, the usage state refers to the ability of an entity to service other entities within its containment hierarchy. But I do not feel strongly about this change. (I just found the term substitution a bit awkward.) I read this a number of times before seeing the difference, but a UNIX diff showed me that you combined the last two sentences < user is equivalent to an entity, so this term is substituted. < This < state refers to the ability of the entity to service other entities < within its containment hierarchy. --- > usage state refers to the ability of an entity to service other > entities within its containment hierarchy. I suggest we make this change. b) I suggest to replace 'status' with 'states' in the sentence below: In addition to those alarm status defined in X.731 [X.731], warning and indeterminate status are also defined to provide a more complete mapping to the Alarm MIB [Alarm-MIB]. I suggest we make this change. c) I suggest to remove the following sentence from section 2.1: This raises some interesting issues not addressed in existing work on state management [X.731]. Rationale: Only one issue is mentioned and not multiple and it is not really relevant whether X.731 addresses the same issue or not.' I propose then that we remove the reference to X.731 and keep the rest of the sentence. The fact that the addition of hierarchy to the concept of state is not well understood is an important note given it precedes a statement indicating that this computed state is out of scope. g) In the ENTITY-STATE-TC module, replace This MIB defines a state textual conventions. with This MIB defines state textual conventions. I suggest we make this change. h) You may want to decide where you like spaces between the name of and enumerated number and the value or not. Right now, this is done differently throughout the module. Propose consistently putting a space. Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 15 14:12:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29274 for ; Wed, 15 Dec 2004 14:12:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeeLP-0002Qo-7F; Wed, 15 Dec 2004 13:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeeEr-0000cx-OR for entmib@megatron.ietf.org; Wed, 15 Dec 2004 13:51:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27391 for ; Wed, 15 Dec 2004 13:51:03 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeeN6-0006LX-Lg for entmib@ietf.org; Wed, 15 Dec 2004 13:59:39 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBFIoUN11471 for ; Wed, 15 Dec 2004 13:50:30 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Dec 2004 13:50:30 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4021DE701@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 15 Dec 2004 13:50:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [Entmib] entstate-648 Wordsmith - various (I, J, K, L, M, N ) X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org #648 Continued ... i) In the EntityOperState description, should it not be "therefore" instead of "there fore"? Yes. j) The second paragraph in the description of the EntityAlarmStatus object seems to be garbled. When no bits of this attribute are set, then none of the value of under repair is set, the resource is currently being repaired, which depending on the implementation, may make the other values in this bit string unreliable. Note sure how to repair the beginning. Also, the notion of an unreliable bit might confuse readers. Perhaps you want to say that the other bits are not meaningful or something like that. Recently introduced error. It is a garble of two separate points. Propose replacing with "When no bits of this attribute are set, then no active alarms are known against this entity and it is not under repair. When the 'value of underRepair' is set, the resource is currently being repaired, which depending on the implementation, may make the other values in this bit string meaningful." k) Missing final dot in the description of entStateLastChanged. Propose adding final dot l) I suggest to move the first sentence of the second paragraph in the description of entStateAdmin to the beginning of the text of the description clause. Furthermore, I think 'notSupported' must be replaced by 'unknown'. So the first two paragraphs of the description clause would read like this: The administrative state for this entity. This object refers to an entity's administrative permission to service both other entities within its containment hierarchy as well other users of its services defined by means outside the scope of this MIB. Setting this object to 'unknown' will result in an 'inconsistentValue' error. For entities that do not support administrative state, all set operations will result in an 'inconsistentValue' error. Also note the addition of the final dot. Agree with moving the first sentence of the second paragraph up. Just noticed that the bit of changing 'notSupported' has been discussed and closed. No further changes for this closed issue. Agree to add a final dot. m) You do not mention 'testing' in the description of the entStateOper object. Propose adding text "A value of 'testing' means that entity currently being tested and cannot there fore report whether it is operational or not." n) Description of entStateAlarm: "The alarm status for this entity. It does not include the alarms raised on child components within its containment hierarchy. Note that this differs from 'indeterminate' which means that that alarm state is supported and there are alarms against this entity, but the severity of some of the alarms is not known. I fail to see to what "this" in the beginning of the second paragraph refers to. Recently introduced error. Proposed replacement "A value of 'unknown' means that this entity is unable to report alarm state. Note that this differs from 'indeterminate' which means that that alarm state is supported and there are alarms against this entity, but the severity of some of the alarms is not known." Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 06:26:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13821 for ; Thu, 16 Dec 2004 06:26:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cetig-0005LA-1M; Thu, 16 Dec 2004 06:22:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CetiO-0005EY-EG for entmib@megatron.ietf.org; Thu, 16 Dec 2004 06:22:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13566 for ; Thu, 16 Dec 2004 06:22:33 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cetqo-0006Hg-4j for entmib@ietf.org; Thu, 16 Dec 2004 06:31:18 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 82CBF3961; Thu, 16 Dec 2004 12:22:03 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 26879-03; Thu, 16 Dec 2004 12:22:02 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id AC946395E; Thu, 16 Dec 2004 12:22:02 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Cethq-0000pk-Il; Thu, 16 Dec 2004 12:22:02 +0100 Date: Thu, 16 Dec 2004 12:22:02 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Subject: Re: [Entmib] entstate-648 Wordsmith - various (I, J, K, L, M, N ) Message-ID: <20041216112202.GD2742@james> Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4021DE701@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4021DE701@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Wed, Dec 15, 2004 at 01:50:24PM -0500, Sharon Chisholm wrote: > When the 'value of underRepair' is set, the resource is > currently being repaired, which depending on the > implementation, may make the other values in this bit > string meaningful." Something like "may make the other values in this bit string meaningful" scares me a bit. Is there any way to find out whether the bits are meaningful, other than knowing the object implementor and having a beer with her? What about this (although it does not change the general situation): When the 'value of underRepair' is set, the resource is currently being repaired. In this situation, it is implementation specific whether the other values in this bit string are meaningful. (This just avoids the "make meaningful" phrase, which kind of implies that before the transition into underRepair the bits were not meaningful, which I think is not necessarily true.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 08:02:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20052 for ; Thu, 16 Dec 2004 08:02:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cev6W-0002pv-1b; Thu, 16 Dec 2004 07:51:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cev0c-0001vb-Jk for entmib@megatron.ietf.org; Thu, 16 Dec 2004 07:45:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18766 for ; Thu, 16 Dec 2004 07:45:29 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cev90-00087I-CD for entmib@ietf.org; Thu, 16 Dec 2004 07:54:13 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBGCisf24457 for ; Thu, 16 Dec 2004 07:44:54 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Dec 2004 07:44:55 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4022400CC@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] entstate-648 Wordsmith - various (I, J, K, L, M, N ) Date: Thu, 16 Dec 2004 07:44:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org hi I had a typo. I meant this: > When the 'value of underRepair' is set, the resource is currently > being repaired, which depending on the implementation, may make the > other values in this bit string not meaningful." Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On Behalf Of Juergen Schoenwaelder Sent: Thursday, December 16, 2004 6:22 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] entstate-648 Wordsmith - various (I, J, K, L, M, N ) On Wed, Dec 15, 2004 at 01:50:24PM -0500, Sharon Chisholm wrote: > When the 'value of underRepair' is set, the resource is currently > being repaired, which depending on the implementation, may make the > other values in this bit string meaningful." Something like "may make the other values in this bit string meaningful" scares me a bit. Is there any way to find out whether the bits are meaningful, other than knowing the object implementor and having a beer with her? What about this (although it does not change the general situation): When the 'value of underRepair' is set, the resource is currently being repaired. In this situation, it is implementation specific whether the other values in this bit string are meaningful. (This just avoids the "make meaningful" phrase, which kind of implies that before the transition into underRepair the bits were not meaningful, which I think is not necessarily true.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 08:25:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21750 for ; Thu, 16 Dec 2004 08:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CevXO-0000bC-0Z; Thu, 16 Dec 2004 08:19:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CevLj-0006mM-6i for entmib@megatron.ietf.org; Thu, 16 Dec 2004 08:07:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20475 for ; Thu, 16 Dec 2004 08:07:17 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CevU9-0000L3-4s for entmib@ietf.org; Thu, 16 Dec 2004 08:16:02 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBGD6jn16869 for ; Thu, 16 Dec 2004 08:06:45 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Dec 2004 08:06:46 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4022400EE@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 16 Dec 2004 08:06:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Entmib] entstate-649 Clarification on 'this information' X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org d) I fail to understand the following sentence in section 2.4: This MIB makes no effort to standardize on the behaviours and characteristics of the various physical classes [RFC2737], but rather how this information is reported. My problem is that I do not really know what "this information" refers to. Also note that you should be using "MIB module" rather than MIB if you refer to the module. And since there are two modules, it is even unclear which one you mean." Propose "These MIB modules makes no effort to standardize on the behaviours and characteristics of the various physical classes [RFC2737], but rather how their state information is reported." Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 08:40:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22517 for ; Thu, 16 Dec 2004 08:40:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cevf7-0002x1-Mx; Thu, 16 Dec 2004 08:27:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CevYO-00012s-73 for entmib@megatron.ietf.org; Thu, 16 Dec 2004 08:20:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21396 for ; Thu, 16 Dec 2004 08:20:22 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cevgp-0000iW-28 for entmib@ietf.org; Thu, 16 Dec 2004 08:29:07 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBGDJoS17060 for ; Thu, 16 Dec 2004 08:19:50 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Dec 2004 08:19:51 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402240107@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 16 Dec 2004 08:19:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Entmib] entstate-650 Rename to ENTITY-STATE-TC-MIB X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org "f) If we keep the TC module, we may want to follow the MIB review guidelines and call the module ENTITY-STATE-TC-MIB (see Appendix C of the MIB review guidelines ID)." Propose change from ENTITY-STATE-TC to ENTITY-STATE-TC-MIB Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 11:22:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09833 for ; Thu, 16 Dec 2004 11:22:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeyAj-0000LK-Pv; Thu, 16 Dec 2004 11:08:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cey7m-0007mz-Kl for entmib@megatron.ietf.org; Thu, 16 Dec 2004 11:05:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08264 for ; Thu, 16 Dec 2004 11:05:03 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeyGE-0006F7-4F for entmib@ietf.org; Thu, 16 Dec 2004 11:13:51 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBGG4VE21117 for ; Thu, 16 Dec 2004 11:04:32 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Dec 2004 11:04:32 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402240378@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 16 Dec 2004 11:04:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Entmib] entstate-651 Notification Description Changes (Part II) X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org hi Missed part of this .... p) The notification are optional. Should there be any further guideline under which conditions implementations should support them? I don't think so. They probably should have been mandatory but optional was more a political decision. I think it is an implement them if you find them useful sort of thing rather than a design pattern that implementations could test against. Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 11:22:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09857 for ; Thu, 16 Dec 2004 11:22:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeyAk-0000LQ-3p; Thu, 16 Dec 2004 11:08:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cey7v-0007oD-JU for entmib@megatron.ietf.org; Thu, 16 Dec 2004 11:05:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08274 for ; Thu, 16 Dec 2004 11:05:12 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeyGN-0006FF-3n for entmib@ietf.org; Thu, 16 Dec 2004 11:14:00 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBGFxuX11296 for ; Thu, 16 Dec 2004 10:59:56 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Dec 2004 10:59:57 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40224035E@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 16 Dec 2004 10:59:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Entmib] entstate-651 Notification Description Changes X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org hi "o) In the two notifications, you talk about the transition disabled -> enabled or enabled->disabled. Is testing->enabled not also possible? Should these notifications not be generated whenever you transition into the enabled / disabled state, regardless what the previous state was? In both notification definitions, I also fail to understand the last sentence. Here is a concrete proposal for new wordings: "An entStateOperEnabled notification signifies that the SNMP entity, acting in an agent role, has detected that the entStateOper object for one of its entities has transitioned into the 'enabled' state. The entity can be identified by extracting the entPhysicalIndex from one of the variable bindings. The entStateAdmin and entStateAlarm varbinds may be examined to find out additional information about the administrative state at the time of the state transition as well to find out whether any alarms against the entity were pending at that time of the transition." "An entStateOperDisabled notification signifies that the SNMP entity, acting in an agent role, has detected that the entStateOper object for one of its entities has transitioned into the 'disabled' state. The entity can be identified by extracting the entPhysicalIndex from one of the variable bindings. The entStateAdmin and entStateAlarm varbinds may be examined to find out additional information about the administrative state at the time of the state transition as well to find out whether any alarms against the entity were pending at that time of the transition." This is shorter and hopefully clearer as the current text. 1. The suggested changes to the first paragraph look good. 2. For the second paragraphs, I propose we keep them as they are in the current draft. The proposed changes seem more a mater of style than clarity. Some information was lost from the compression that can be inferred, but I still prefer explicitly stating it. Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 11:37:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11359 for ; Thu, 16 Dec 2004 11:37:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeyXv-0005Oz-Hr; Thu, 16 Dec 2004 11:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeyO8-0003d1-Ox for entmib@megatron.ietf.org; Thu, 16 Dec 2004 11:22:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09822 for ; Thu, 16 Dec 2004 11:21:57 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeyWa-0006qH-D3 for entmib@ietf.org; Thu, 16 Dec 2004 11:30:45 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBGGLM117967 for ; Thu, 16 Dec 2004 11:21:23 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Dec 2004 11:21:23 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4022403AD@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 16 Dec 2004 11:21:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Entmib] entstate-652 Security Considerations Text Changes X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org q) I suggest to remove the following phrase from the security considerations section: ... ranging from those running on a port to those on an entire device, depending on the type of entity I think disruption of service is good enough and says all. Note that even disabling a port may not even lead to disruption of service if there are for example backup paths that get activated automatically (e.g., re-computation of a spanning tree in a bridged LAN)." Note that this text was added as a result of "#76: Security Considerations". You can read the details at http://rt.psg.com (ietf, ietf). It had asked that "The Security Considerations section should clearly articulate the operational risks of writing on entStateAdmin." I propose we not remove this additional information unless we have strong consensus given its origins. Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 11:40:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11612 for ; Thu, 16 Dec 2004 11:40:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ceycg-0006NX-Co; Thu, 16 Dec 2004 11:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CeyXH-0005Fz-NR for entmib@megatron.ietf.org; Thu, 16 Dec 2004 11:31:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10808 for ; Thu, 16 Dec 2004 11:31:24 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ceyfk-00079b-3k for entmib@ietf.org; Thu, 16 Dec 2004 11:40:12 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBGGUs118648 for ; Thu, 16 Dec 2004 11:30:54 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Dec 2004 11:30:55 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4022403D1@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 16 Dec 2004 11:30:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Entmib] entstate-653: Don't need to import the textual conventions? X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org "r) There is no need to import TEXTUAL-CONVENTION if the MIB modules are split into a TC module and one containing object/notification definitions." I don't think I understand this. Are you suggesting that we don't need to following: EntityAdminState, EntityOperState, EntityUsageState, EntityAlarmStatus, EntityStandbyStatus FROM ENTITY-STATE-TC; Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 15:27:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05302 for ; Thu, 16 Dec 2004 15:27:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf25k-0007eF-Kt; Thu, 16 Dec 2004 15:19:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf1xV-00033X-Q4 for entmib@megatron.ietf.org; Thu, 16 Dec 2004 15:10:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02715 for ; Thu, 16 Dec 2004 15:10:43 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf25z-0006RF-G8 for entmib@ietf.org; Thu, 16 Dec 2004 15:19:32 -0500 Received: from shannon.research.telcordia.com (shannon [128.96.81.11]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iBGKA1jR007584; Thu, 16 Dec 2004 15:10:01 -0500 (EST) Received: from KAJ-2.research.telcordia.com (KAJ-2.cc.telcordia.com [128.96.171.169]) by shannon.research.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA21548; Thu, 16 Dec 2004 15:09:53 -0500 (EST) Message-Id: <6.1.2.0.2.20041216145009.03d7e0c0@128.96.81.11> X-Sender: kaj@128.96.81.11 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 16 Dec 2004 15:09:49 -0500 To: "Randy Presuhn" From: Kaj Tesink Subject: Re: Re: [Entmib] CLEI Code URN draft In-Reply-To: <00e601c4e227$4eb36c80$7f1afea9@oemcomputer> References: <6.1.2.0.2.20041213171740.01de1df8@128.96.81.11> <002501c4e185$24357680$7f1afea9@oemcomputer> <6.1.2.0.2.20041214150730.01d67ec0@128.96.81.11> <00e601c4e227$4eb36c80$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org At 04:53 PM 12/14/2004, Randy Presuhn wrote: >Hi - > > > From: "Kaj Tesink" > > To: "Randy Presuhn" > > Cc: > > Sent: Tuesday, December 14, 2004 12:10 PM > > Subject: Re: Re: [Entmib] CLEI Code URN draft >... > > >Wouldn't it be simpler to say that CLEI codes MUST be upper case? > > > > > > maybe so, but as i understand it T1.213 is case-insensitive, > > so restricting the URN name space to upper case seems inappropriate. >... > >My concerns are mailnly with regard to the future if these things prove >useful. > 1) consider what it would take to describe the behaviour of read-write > objects that used these (after a write, would the value read be > bit-for-bit > identical, or merely fit the matching rules?) > 2) if they were used for indexing... > >If their definition is already case insensitive, then I think we'd really >be better >off deciding what their "canonical" representation should be for our purposes. >However, I freely admit this is a theoretical concern, and that if we >don't imagine >these being used in other MIB object definitions, there's less need to worry >about it. randy, i agree that at this stage your point is theoretical but at the same time we dont want to go in a direction that we may regret later on. i checked a bit more with the CLEI folks, and the following transpired: - T1.213 is case-insensitive - the maintenance agent in practice only assigns codes using uppercase representation; the records are kept uppercase - the maintenance agent can load records in lower case and their system will convert it to uppercase - common representation is usually in uppercase so in practice we seem to have two choices for the URN space: 1.sticking with case-insensitive, i.e., be strictly compatible with T1.213, or 2.going for uppercase only, which would be compatible with practical use but narrow the application of T1.213 any further thoughts? kaj >Randy > > > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kaj Tesink Telcordia Technologies. Inc. One Telcordia drive Piscataway, NJ 08854 Email: kaj@research.telcordia.com Tel: (732) 699-6068 Fax: (732) 336-2336 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 16:34:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14014 for ; Thu, 16 Dec 2004 16:34:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf2se-000135-FS; Thu, 16 Dec 2004 16:09:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf2hL-00030W-QB for entmib@megatron.ietf.org; Thu, 16 Dec 2004 15:58:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08391 for ; Thu, 16 Dec 2004 15:58:05 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf2pq-0008FF-D2 for entmib@ietf.org; Thu, 16 Dec 2004 16:06:55 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 9B3D1400E; Thu, 16 Dec 2004 21:57:28 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27533-03; Thu, 16 Dec 2004 21:57:27 +0100 (CET) Received: from james (I9e42.i.pppool.de [85.73.158.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A2C8E3B75; Thu, 16 Dec 2004 21:57:27 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Cf2gg-0000cx-Rn; Thu, 16 Dec 2004 21:57:26 +0100 Date: Thu, 16 Dec 2004 21:57:26 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Subject: Re: [Entmib] entstate-653: Don't need to import the textual conventions? Message-ID: <20041216205726.GA2336@james> Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B4022403D1@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4022403D1@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Thu, Dec 16, 2004 at 11:30:48AM -0500, Sharon Chisholm wrote: > > > "r) There is no need to import TEXTUAL-CONVENTION if the MIB modules > are split into a TC module and one containing object/notification > definitions." > > > I don't think I understand this. Are you suggesting that we don't need to > following: > > EntityAdminState, EntityOperState, EntityUsageState, > EntityAlarmStatus, EntityStandbyStatus > FROM ENTITY-STATE-TC; I was trying to convey that TEXTUAL-CONVENTION is not used in the ENTITY-STATE-MIB module. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Thu Dec 16 16:37:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14621 for ; Thu, 16 Dec 2004 16:37:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf3Dv-0004Kh-Fm; Thu, 16 Dec 2004 16:31:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cf2nm-0006i4-7J for entmib@megatron.ietf.org; Thu, 16 Dec 2004 16:04:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08891 for ; Thu, 16 Dec 2004 16:04:43 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf2wH-0008RJ-CL for entmib@ietf.org; Thu, 16 Dec 2004 16:13:33 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id EF50E4010; Thu, 16 Dec 2004 22:04:14 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27811-04; Thu, 16 Dec 2004 22:04:14 +0100 (CET) Received: from james (I9e42.i.pppool.de [85.73.158.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E07E0400E; Thu, 16 Dec 2004 22:04:13 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Cf2nE-0000dG-W7; Thu, 16 Dec 2004 22:04:13 +0100 Date: Thu, 16 Dec 2004 22:04:12 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) Message-ID: <20041216210412.GB2336@james> Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B402240378@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B402240378@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Thu, Dec 16, 2004 at 11:04:24AM -0500, Sharon Chisholm wrote: > Missed part of this .... > > > p) The notification are optional. Should there be any further > guideline under which conditions implementations should support > them? > > > I don't think so. They probably should have been mandatory but optional was > more a political decision. I think it is an implement them if you find them > useful sort of thing rather than a design pattern that implementations could > test against. I dislike totally optional notifications in standards. Either these notifications are generally useful or they are useful in specific situations which then need to be spelled out or they are not useful at all. How do I practically find out whether a given box supports these notifications? Is the answer that I have to physically remove decives are beg the vendor to give me a suitable agent capabilities statements? Sounds all not very practical from a network management application writer point of view... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Fri Dec 17 07:40:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12672 for ; Fri, 17 Dec 2004 07:40:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfHK2-0000Uj-A5; Fri, 17 Dec 2004 07:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfHFH-000890-0d for entmib@megatron.ietf.org; Fri, 17 Dec 2004 07:30:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11795 for ; Fri, 17 Dec 2004 07:30:06 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfHNu-0002cd-8n for entmib@ietf.org; Fri, 17 Dec 2004 07:39:02 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBHCTXw20805 for ; Fri, 17 Dec 2004 07:29:33 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Dec 2004 07:29:34 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B40224085E@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] entstate-653: Don't need to import the textual conve ntions? Date: Fri, 17 Dec 2004 07:29:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org hi Ah. Ok. Makes sense. Propose removing its import from the ENTITY-STATE-MIB then. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On Behalf Of Juergen Schoenwaelder Sent: Thursday, December 16, 2004 3:57 PM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] entstate-653: Don't need to import the textual conventions? On Thu, Dec 16, 2004 at 11:30:48AM -0500, Sharon Chisholm wrote: > > > "r) There is no need to import TEXTUAL-CONVENTION if the MIB modules > are split into a TC module and one containing object/notification > definitions." > > I don't think I understand this. Are you suggesting that we don't need > to > following: > > EntityAdminState, EntityOperState, EntityUsageState, > EntityAlarmStatus, EntityStandbyStatus > FROM ENTITY-STATE-TC; I was trying to convey that TEXTUAL-CONVENTION is not used in the ENTITY-STATE-MIB module. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Fri Dec 17 07:49:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13232 for ; Fri, 17 Dec 2004 07:49:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfHM8-0000xz-Ep; Fri, 17 Dec 2004 07:37:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfHHH-0008H4-Sg for entmib@megatron.ietf.org; Fri, 17 Dec 2004 07:32:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11935 for ; Fri, 17 Dec 2004 07:32:10 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfHPv-0002gd-5n for entmib@ietf.org; Fri, 17 Dec 2004 07:41:07 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBHCVc600217 for ; Fri, 17 Dec 2004 07:31:38 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Dec 2004 07:31:39 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402240860@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] entstate-651 Notification Description Changes (Part II) Date: Fri, 17 Dec 2004 07:31:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org hi Well, as I said, I can't think of a design pattern to make then conditionally mandatory. Personally, I'd love to see them mandatory, but I think we would need strong consensus to make that change at this point. Do we have it? Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On Behalf Of Juergen Schoenwaelder Sent: Thursday, December 16, 2004 4:04 PM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) On Thu, Dec 16, 2004 at 11:04:24AM -0500, Sharon Chisholm wrote: > Missed part of this .... > > > p) The notification are optional. Should there be any further > guideline under which conditions implementations should support them? > > > I don't think so. They probably should have been mandatory but > optional was more a political decision. I think it is an implement > them if you find them useful sort of thing rather than a design > pattern that implementations could test against. I dislike totally optional notifications in standards. Either these notifications are generally useful or they are useful in specific situations which then need to be spelled out or they are not useful at all. How do I practically find out whether a given box supports these notifications? Is the answer that I have to physically remove decives are beg the vendor to give me a suitable agent capabilities statements? Sounds all not very practical from a network management application writer point of view... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Fri Dec 17 08:22:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16302 for ; Fri, 17 Dec 2004 08:22:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfI0e-0006ik-7X; Fri, 17 Dec 2004 08:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfHuo-00063c-Q6 for entmib@megatron.ietf.org; Fri, 17 Dec 2004 08:13:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15452 for ; Fri, 17 Dec 2004 08:13:01 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfI3S-00045t-At for entmib@ietf.org; Fri, 17 Dec 2004 08:21:59 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C6F983B91; Fri, 17 Dec 2004 14:12:29 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04869-09; Fri, 17 Dec 2004 14:12:27 +0100 (CET) Received: from james (james.public.iu-bremen.de [212.201.47.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A2AB63B88; Fri, 17 Dec 2004 14:12:27 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CfHuH-0000vZ-V7; Fri, 17 Dec 2004 14:12:29 +0100 Date: Fri, 17 Dec 2004 14:12:29 +0100 From: Juergen Schoenwaelder To: Sharon Chisholm Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) Message-ID: <20041217131229.GB3523@james> Mail-Followup-To: Sharon Chisholm , entmib@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B402240860@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B402240860@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Fri, Dec 17, 2004 at 07:31:28AM -0500, Sharon Chisholm wrote: > Well, as I said, I can't think of a design pattern to make then > conditionally mandatory. Personally, I'd love to see them mandatory, but I > think we would need strong consensus to make that change at this point. What were the arguments against making these mandatory? Generally too hard to detect such state changes? Something else? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Fri Dec 17 08:46:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18412 for ; Fri, 17 Dec 2004 08:46:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfIOy-0002MT-CL; Fri, 17 Dec 2004 08:44:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfILT-0001rJ-KZ for entmib@megatron.ietf.org; Fri, 17 Dec 2004 08:40:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18200 for ; Fri, 17 Dec 2004 08:40:34 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfIU6-0004xn-Ke for entmib@ietf.org; Fri, 17 Dec 2004 08:49:32 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBHDe1802427 for ; Fri, 17 Dec 2004 08:40:01 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Dec 2004 08:40:02 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4022408C3@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] entstate-651 Notification Description Changes (Part II) Date: Fri, 17 Dec 2004 08:39:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org In the RT tool, I only found one issue related to this: 75. There might have been others, but I filtered on issue title. It doesn't seem to have captured the previous discussion around consensus. It also doesn't seem to be on the mailing list. It must have been during a face to face meeting, although I didn't see it reflected in any meeting minutes either. So, that might put us in a better position to change it? Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On Behalf Of Juergen Schoenwaelder Sent: Friday, December 17, 2004 8:12 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) On Fri, Dec 17, 2004 at 07:31:28AM -0500, Sharon Chisholm wrote: > Well, as I said, I can't think of a design pattern to make then > conditionally mandatory. Personally, I'd love to see them mandatory, > but I think we would need strong consensus to make that change at this > point. What were the arguments against making these mandatory? Generally too hard to detect such state changes? Something else? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Dec 20 08:46:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28282 for ; Mon, 20 Dec 2004 08:46:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgNoh-0005FV-Rj; Mon, 20 Dec 2004 08:43:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgNi1-0004gE-Jy for entmib@megatron.ietf.org; Mon, 20 Dec 2004 08:36:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27839 for ; Mon, 20 Dec 2004 08:36:20 -0500 (EST) Received: from tm-gw.cictr.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgNrH-0000NL-Tn for entmib@ietf.org; Mon, 20 Dec 2004 08:45:56 -0500 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 249095; Mon, 20 Dec 2004 08:29:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20041217131229.GB3523@james> References: <713043CE8B8E1348AF3C546DBE02C1B402240860@zcarhxm2.corp.nortel.com> <20041217131229.GB3523@james> Date: Mon, 20 Dec 2004 08:34:47 -0500 To: Juergen Schoenwaelder , Sharon Chisholm From: Margaret Wasserman Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Juergen and Sharon, I don't personally care whether the Entity State notifications are optional or mandatory, but I do have a concern about this discussion... This document has been through two or three WG LCs already, and now we seem to be discussing changes to features of the MIB that have been constant since the beginning. It seems like there are always 6 or more outstanding issues with this document. We fix the current issues, and then new issues are raised during the LC that is intended to check the resolutions of the previous issues. Where does this stop? At what point can we pull the plug on this discussion and declare the document "good enough"? Juergen, do you have any blocking objections to the publication of this document at this point? Or just suggestions for improvement? Personally, I think that this constant editing is a symptom of the fact that there is no driving force for the publication of this document. Do we actually care about getting this document published? If so, let's reach closure on the existing issues and publish it. If not, let's stop thrashing... Margaret >On Fri, Dec 17, 2004 at 07:31:28AM -0500, Sharon Chisholm wrote: > >> Well, as I said, I can't think of a design pattern to make then >> conditionally mandatory. Personally, I'd love to see them mandatory, but I >> think we would need strong consensus to make that change at this point. > >What were the arguments against making these mandatory? Generally too >hard to detect such state changes? Something else? > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 >Bremen, Germany > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Dec 20 08:55:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28741 for ; Mon, 20 Dec 2004 08:55:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgNzF-0006kj-SI; Mon, 20 Dec 2004 08:54:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgNrc-0005d7-9g for entmib@megatron.ietf.org; Mon, 20 Dec 2004 08:46:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28276 for ; Mon, 20 Dec 2004 08:46:14 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgO0r-0000YT-Ai for entmib@ietf.org; Mon, 20 Dec 2004 08:55:51 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 198E7404D; Mon, 20 Dec 2004 14:45:40 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 12114-10; Mon, 20 Dec 2004 14:45:39 +0100 (CET) Received: from james (Ia5d2.i.pppool.de [85.73.165.210]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id EF5784042; Mon, 20 Dec 2004 14:45:38 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CgNqy-00021Y-PB; Mon, 20 Dec 2004 14:45:36 +0100 Date: Mon, 20 Dec 2004 14:45:36 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) Message-ID: <20041220134536.GA7717@james> Mail-Followup-To: Margaret Wasserman , Sharon Chisholm , entmib@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B402240860@zcarhxm2.corp.nortel.com> <20041217131229.GB3523@james> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: entmib@ietf.org, Sharon Chisholm X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Mon, Dec 20, 2004 at 08:34:47AM -0500, Margaret Wasserman wrote: > Where does this stop? At what point can we pull the plug on this > discussion and declare the document "good enough"? Juergen, do you > have any blocking objections to the publication of this document at > this point? Or just suggestions for improvement? > > Personally, I think that this constant editing is a symptom of the > fact that there is no driving force for the publication of this > document. Do we actually care about getting this document published? > If so, let's reach closure on the existing issues and publish it. If > not, let's stop thrashing... Margaret, there is no constant editing. The problem are the turn around cycles. If it takes many weeks to follow up on last call comments, then there is a problem with the management of this WG. You reactions indicate that you do not really want any contribution to this WG and that you do not really care about the documents and the document quality. If that is indeed the case, then there is probably no point to continue. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Dec 20 09:28:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01346 for ; Mon, 20 Dec 2004 09:28:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgOQB-0002WU-9k; Mon, 20 Dec 2004 09:21:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgOJu-0001ZJ-Fp for entmib@megatron.ietf.org; Mon, 20 Dec 2004 09:15:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00431 for ; Mon, 20 Dec 2004 09:15:28 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgOT9-0001JK-Vt for entmib@ietf.org; Mon, 20 Dec 2004 09:25:05 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBKEEsO06829 for ; Mon, 20 Dec 2004 09:14:54 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Dec 2004 09:14:54 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4022BF713@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] entstate-651 Notification Description Changes (Part II) Date: Mon, 20 Dec 2004 09:14:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org hi There is a strong need for this MIB. Turn around times are slow since this working group hasn't responded well historically to trying to close issues quickly. We have a number of low-risk changes proposed. I suggest we make those, keep the notifications as they are and then proceed to forward things up to the IESG (without calling YAWLC (yet another working group last call)). Sharon -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com] Sent: Monday, December 20, 2004 8:35 AM To: Juergen Schoenwaelder; Chisholm, Sharon [CAR:5K50:EXCH] Cc: entmib@ietf.org Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) Juergen and Sharon, I don't personally care whether the Entity State notifications are optional or mandatory, but I do have a concern about this discussion... This document has been through two or three WG LCs already, and now we seem to be discussing changes to features of the MIB that have been constant since the beginning. It seems like there are always 6 or more outstanding issues with this document. We fix the current issues, and then new issues are raised during the LC that is intended to check the resolutions of the previous issues. Where does this stop? At what point can we pull the plug on this discussion and declare the document "good enough"? Juergen, do you have any blocking objections to the publication of this document at this point? Or just suggestions for improvement? Personally, I think that this constant editing is a symptom of the fact that there is no driving force for the publication of this document. Do we actually care about getting this document published? If so, let's reach closure on the existing issues and publish it. If not, let's stop thrashing... Margaret >On Fri, Dec 17, 2004 at 07:31:28AM -0500, Sharon Chisholm wrote: > >> Well, as I said, I can't think of a design pattern to make then >> conditionally mandatory. Personally, I'd love to see them mandatory, >> but I think we would need strong consensus to make that change at >> this point. > >What were the arguments against making these mandatory? Generally too >hard to detect such state changes? Something else? > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 >Bremen, Germany > >_______________________________________________ >Entmib mailing list >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Dec 20 09:42:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02325 for ; Mon, 20 Dec 2004 09:42:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgOhV-0004Ld-9X; Mon, 20 Dec 2004 09:39:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgOaI-0003cO-7s for entmib@megatron.ietf.org; Mon, 20 Dec 2004 09:32:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01526 for ; Mon, 20 Dec 2004 09:32:24 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgOjW-0001hu-6L for entmib@ietf.org; Mon, 20 Dec 2004 09:42:01 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBKENNja009143 for ; Mon, 20 Dec 2004 09:23:24 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBKENLja009075 for ; Mon, 20 Dec 2004 09:23:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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: [Entmib] entstate-651 Notification Description Changes (Part II) Date: Mon, 20 Dec 2004 16:32:15 +0200 Message-ID: Thread-Topic: [Entmib] entstate-651 Notification Description Changes (Part II) Thread-Index: AcTmoCLJgQyo9dW6T7WCopzqfbizjAAAG5bg From: "Romascanu, Dan \(Dan\)" To: "Sharon Chisholm" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I strongly support Sharon's statement about the need seeing this = document put on the standards track.=20 I also am in favor of the fast track process that Sharon is suggesting.=20 Regards, Dan > -----Original Message----- > From: entmib-bounces@ietf.org=20 > [mailto:entmib-bounces@ietf.org]On Behalf Of Sharon Chisholm > Sent: 20 December, 2004 4:15 PM > To: entmib@ietf.org > Subject: RE: [Entmib] entstate-651 Notification Description=20 > Changes (Part II) >=20 >=20 > hi >=20 > There is a strong need for this MIB. Turn around times are=20 > slow since this > working group hasn't responded well historically to trying to=20 > close issues > quickly.=20 >=20 > We have a number of low-risk changes proposed. I suggest we=20 > make those, keep > the notifications as they are and then proceed to forward=20 > things up to the > IESG (without calling YAWLC (yet another working group last call)). >=20 > Sharon >=20 > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com]=20 > Sent: Monday, December 20, 2004 8:35 AM > To: Juergen Schoenwaelder; Chisholm, Sharon [CAR:5K50:EXCH] > Cc: entmib@ietf.org > Subject: Re: [Entmib] entstate-651 Notification Description=20 > Changes (Part > II) >=20 >=20 >=20 > Juergen and Sharon, >=20 > I don't personally care whether the Entity State notifications are=20 > optional or mandatory, but I do have a concern about this=20 > discussion... >=20 > This document has been through two or three WG LCs already, and now=20 > we seem to be discussing changes to features of the MIB that have=20 > been constant since the beginning. It seems like there are always 6=20 > or more outstanding issues with this document. We fix the current=20 > issues, and then new issues are raised during the LC that is intended=20 > to check the resolutions of the previous issues. >=20 > Where does this stop? At what point can we pull the plug on this=20 > discussion and declare the document "good enough"? Juergen, do you=20 > have any blocking objections to the publication of this document at=20 > this point? Or just suggestions for improvement? >=20 > Personally, I think that this constant editing is a symptom of the=20 > fact that there is no driving force for the publication of this=20 > document. Do we actually care about getting this document published?=20 > If so, let's reach closure on the existing issues and publish it. If=20 > not, let's stop thrashing... >=20 > Margaret >=20 >=20 > >On Fri, Dec 17, 2004 at 07:31:28AM -0500, Sharon Chisholm wrote: > > > >> Well, as I said, I can't think of a design pattern to make then =20 > >> conditionally mandatory. Personally, I'd love to see them=20 > mandatory,=20 > >> but I think we would need strong consensus to make that change at=20 > >> this point. > > > >What were the arguments against making these mandatory?=20 > Generally too=20 > >hard to detect such state changes? Something else? > > > >/js > > > >-- > >Juergen Schoenwaelder International=20 > University Bremen > > P.O. Box 750 561, 28725=20 > >Bremen, Germany > > > >_______________________________________________ > >Entmib mailing list > >Entmib@ietf.org > >https://www1.ietf.org/mailman/listinfo/entmib >=20 >=20 >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Dec 20 12:52:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19308 for ; Mon, 20 Dec 2004 12:52:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgRgK-00055B-0k; Mon, 20 Dec 2004 12:50:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgRbA-0004Mm-Dx for entmib@megatron.ietf.org; Mon, 20 Dec 2004 12:45:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18778 for ; Mon, 20 Dec 2004 12:45:29 -0500 (EST) Received: from tm-gw.cictr.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgRkQ-0006zm-40 for entmib@ietf.org; Mon, 20 Dec 2004 12:55:09 -0500 Received: from [10.0.0.83] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 249344; Mon, 20 Dec 2004 12:38:21 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20041220134536.GA7717@james> References: <713043CE8B8E1348AF3C546DBE02C1B402240860@zcarhxm2.corp.nortel.com> <20041217131229.GB3523@james> <20041220134536.GA7717@james> Date: Mon, 20 Dec 2004 12:45:22 -0500 To: Juergen Schoenwaelder From: Margaret Wasserman Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org Hi Juergen, >On Mon, Dec 20, 2004 at 08:34:47AM -0500, Margaret Wasserman wrote: >Margaret, there is no constant editing. The problem are the turn around >cycles. If it takes many weeks to follow up on last call comments, then >there is a problem with the management of this WG. You reactions indicate >that you do not really want any contribution to this WG It is true that I do not want any new contributions to the WG, because we are supposed to be finishing our work and shutting down. I think that I've made it quite clear (on several occasions) that I would prefer to step down as chair of this WG, but (to my knowledge, anyway), no one has volunteered to replace me. I am not interested in taking on new work that will extend the life of the WG, because I don't want to keep running it. There is no great mystery here... > and that you do >not really care about the documents and the document quality. I actually do care about the Entity MIB. I designed it into Wind River's virtual router solution and had someone implement it there. I found it very useful, and I was quite enthusiastic for a time about promoting this MIB to Draft Standard. I was sorry to see the WG choose otherwise, but did support the consensus of the WG to re-cycle at proposed rather than remove the alias tables. Now, people want to add additional objects,... and so on, and so on... I don't have any problem with the Entity State MIB, except for the fact that we don't seem to be able to finish it. We keep moving (in occasional bursts), but I am not sure that we are getting any closer to the end. Are you? Do you think that the MIB is in substantially better shape today than it was a year ago? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 29 02:46:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16507 for ; Wed, 29 Dec 2004 02:46:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjYVW-0007qY-EW; Wed, 29 Dec 2004 02:44:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjYUC-0007Ku-IN for entmib@megatron.ietf.org; Wed, 29 Dec 2004 02:43:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16278 for ; Wed, 29 Dec 2004 02:43:10 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjYfF-0006gS-9k for entmib@ietf.org; Wed, 29 Dec 2004 02:54:39 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 72BB1406B; Wed, 29 Dec 2004 08:42:34 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 23590-09; Wed, 29 Dec 2004 08:42:33 +0100 (CET) Received: from james (Ibbf9.i.pppool.de [85.73.187.249]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 9A3D44066; Wed, 29 Dec 2004 08:42:33 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Cjgq3-0000r1-4C; Wed, 29 Dec 2004 17:38:19 +0100 Date: Wed, 29 Dec 2004 17:38:19 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) Message-ID: <20041229163819.GA2341@james> Mail-Followup-To: Margaret Wasserman , entmib@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B402240860@zcarhxm2.corp.nortel.com> <20041217131229.GB3523@james> <20041220134536.GA7717@james> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 1.9 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org On Mon, Dec 20, 2004 at 12:45:22PM -0500, Margaret Wasserman wrote: > >On Mon, Dec 20, 2004 at 08:34:47AM -0500, Margaret Wasserman wrote: > >Margaret, there is no constant editing. The problem are the turn around > >cycles. If it takes many weeks to follow up on last call comments, then > >there is a problem with the management of this WG. You reactions indicate > >that you do not really want any contribution to this WG > > It is true that I do not want any new contributions to the WG, > because we are supposed to be finishing our work and shutting down. > I think that I've made it quite clear (on several occasions) that I > would prefer to step down as chair of this WG, but (to my knowledge, > anyway), no one has volunteered to replace me. I am not interested > in taking on new work that will extend the life of the WG, because I > don't want to keep running it. There is no great mystery here... The point with the notifications which triggered this thread is that we are discussion last call comments that I have originally posted on 9 Jul 2003 and reposted on 29 Sep 2004. I don't think the last call comments can be considered a new contribution and I don't want to feel guilty of having done a detailed last call review. Note that I am fine to accept a resolution that the unconditional optional notification is indeed what the WG wants and then this issue is closed. What we lack is simply an efficient process to resolve issues raised during last call. > I don't have any problem with the Entity State MIB, except for the > fact that we don't seem to be able to finish it. We keep moving (in > occasional bursts), but I am not sure that we are getting any closer > to the end. Are you? Do you think that the MIB is in substantially > better shape today than it was a year ago? I believe this is primarily a matter of turn around times. Perhaps you can check with Sharon whether she can allocate some more time slots to finalize the Entity State MIB. When will the next revised version of the document be posted? Lets work on the document rather than this meta discussion which by itself does not move anything forward. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Wed Dec 29 23:37:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19770 for ; Wed, 29 Dec 2004 23:37:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjrjE-0007Ad-RX; Wed, 29 Dec 2004 23:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjrXI-00040q-R8 for entmib@megatron.ietf.org; Wed, 29 Dec 2004 23:03:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17452 for ; Wed, 29 Dec 2004 23:03:36 -0500 (EST) Received: from tm-gw.cictr.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjriV-0003nA-3O for entmib@ietf.org; Wed, 29 Dec 2004 23:15:16 -0500 Received: from [24.61.30.237] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 254122; Wed, 29 Dec 2004 22:55:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20041229163819.GA2341@james> References: <713043CE8B8E1348AF3C546DBE02C1B402240860@zcarhxm2.corp.nortel.com> <20041217131229.GB3523@james> <20041220134536.GA7717@james> <20041229163819.GA2341@james> Date: Wed, 29 Dec 2004 23:02:44 -0500 To: Juergen Schoenwaelder From: Margaret Wasserman Subject: Re: [Entmib] entstate-651 Notification Description Changes (Part II) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: entmib@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF Entity MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: entmib-bounces@ietf.org Errors-To: entmib-bounces@ietf.org >On Mon, Dec 20, 2004 at 12:45:22PM -0500, Margaret Wasserman wrote: >I believe this is primarily a matter of turn around times. Perhaps >you can check with Sharon whether she can allocate some more time >slots to finalize the Entity State MIB. When will the next revised >version of the document be posted? Lets work on the document rather >than this meta discussion which by itself does not move anything >forward. I agree that the meta-discussion isn't helping,a nd thanks for suggesting that we move back to discussing the document... Sharon has stated that she should have more time to spend on this document between now and the next IETF meeting, so I am hopeful that we can get the issues resolved and submit it to the IESG. Sharon, could you post a summary of the remaining open issues with your proposals for resolution, so that we can see if there is WG agreement? Perhaps we can attempt to reach consensus that these are the only remaining issues and that we will submit the document to the IESG once they are resolved? Thanks, Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib