From mailman-bounces@ietf.org Mon Nov 1 08:44: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 IAA02400 for ; Mon, 1 Nov 2004 08:44: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 1COZgr-0006eZ-JD for entmib-archive@lists.ietf.org; Mon, 01 Nov 2004 05:45:33 -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: Mon, 01 Nov 2004 05:18:04 -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 Thu Nov 4 14:44:05 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 OAA26417 for ; Thu, 4 Nov 2004 14:44:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPnQl-0005Ck-9J; Thu, 04 Nov 2004 14:37:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPnO5-0004c3-C8 for entmib@megatron.ietf.org; Thu, 04 Nov 2004 14:35: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 OAA25429 for ; Thu, 4 Nov 2004 14:35:12 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnde-0004pS-Og for entmib@ietf.org; Thu, 04 Nov 2004 14:51:20 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2004 11:47:31 -0800 X-BrightmailFiltered: true 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 iA4JYYnC001501 for ; Thu, 4 Nov 2004 11:34:38 -0800 (PST) Received: from abierman-xp.cisco.com (sjc-vpn4-40.cisco.com [10.21.80.40]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id BAS90479; Thu, 4 Nov 2004 11:34:33 -0800 (PST) Message-Id: <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Nov 2004 11:34:33 -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: 79899194edc4f33a41f49410777972f8 Subject: [Entmib] Entity MIB v3 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, It doesn't make sense to me to undo one deprecated table but not the other one. The entLPMappingTable was deprecated so we could advance to Draft Standard. Since we are cycling at Proposed instead of advancing to Draft, there is no reason to deprecate this table. I will post an update (w/o the IPR goof) after the IETF. I would like to un-deprecate the entLPMappingTable as well. Also, I need examples for the entPhysicalUris object. This object is too vague for me to provide any examples. I also see no guidance for which types of physical entities should provide a mfg date. FRUs only? More text is needed for both of these new objects. thanks, Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Nov 29 21:45:57 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 VAA11758 for ; Mon, 29 Nov 2004 21:45:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxzz-0000z6-VW; Mon, 29 Nov 2004 21:44:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxzM-0000mu-Fk for entmib@megatron.ietf.org; Mon, 29 Nov 2004 21:43: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 VAA11590 for ; Mon, 29 Nov 2004 21:43:34 -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 1CYy4K-0006h2-3M for entmib@ietf.org; Mon, 29 Nov 2004 21:48:48 -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 200775; Mon, 29 Nov 2004 21:36:57 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> References: <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> Date: Mon, 29 Nov 2004 21:41:15 -0500 To: Andy Bierman , entmib@ietf.org From: Margaret Wasserman Subject: Re: [Entmib] Entity MIB v3 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Andy, At 11:34 AM -0800 11/4/04, Andy Bierman wrote: >I will post an update (w/o the IPR goof) after the IETF. >I would like to un-deprecate the entLPMappingTable as well. This makes sense to me. Does anyone have an objection to this plan? >Also, I need examples for the entPhysicalUris object. >This object is too vague for me to provide any examples. >I also see no guidance for which types of physical >entities should provide a mfg date. FRUs only? >More text is needed for both of these new objects. Could one of the people who felt strongly that these objects should be included in the Entity MIB update please respond to Andy's request for more information? 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? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Mon Nov 29 21:50:51 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 VAA12039 for ; Mon, 29 Nov 2004 21:50: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 1CYy3U-0001gf-9q; Mon, 29 Nov 2004 21:47:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYy0K-0000zt-69 for entmib@megatron.ietf.org; Mon, 29 Nov 2004 21:44: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 VAA11640 for ; Mon, 29 Nov 2004 21:44:34 -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 1CYy5K-0006iK-UA for entmib@ietf.org; Mon, 29 Nov 2004 21:49:48 -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 200770; Mon, 29 Nov 2004 21:38:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4017C0892@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B4017C0892@zcarhxm2.corp.nortel.com> Date: Mon, 29 Nov 2004 21:44:02 -0500 To: "Sharon Chisholm" , entmib@ietf.org From: Margaret Wasserman Subject: RE: [Entmib] WG LAST CALL: draft-ietf-entmib-state-05.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 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 Tue Nov 30 06:33:24 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 GAA08085 for ; Tue, 30 Nov 2004 06:33:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ6Ay-0005lQ-Fr; Tue, 30 Nov 2004 06:28:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ67g-0004wK-EH for entmib@megatron.ietf.org; Tue, 30 Nov 2004 06:24: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 GAA07379 for ; Tue, 30 Nov 2004 06:24:41 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ6Cm-0000gy-8a for entmib@ietf.org; Tue, 30 Nov 2004 06:30:01 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6FEE935F4; Tue, 30 Nov 2004 12:24:09 +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 11054-05; Tue, 30 Nov 2004 12:24:08 +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 65C283607; Tue, 30 Nov 2004 12:24:08 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZ677-0000pP-8D; Tue, 30 Nov 2004 12:24:09 +0100 Date: Tue, 30 Nov 2004 12:24:09 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Subject: Re: [Entmib] Entity MIB v3 Message-ID: <20041130112409.GE2823@james> Mail-Followup-To: Margaret Wasserman , Andy Bierman , entmib@ietf.org, kaj@research.telcordia.com References: <4.3.2.7.2.20041104112435.02e10e70@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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: entmib@ietf.org, kaj@research.telcordia.com, 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 Mon, Nov 29, 2004 at 09:41:15PM -0500, Margaret Wasserman wrote: > >Also, I need examples for the entPhysicalUris object. > >This object is too vague for me to provide any examples. > >I also see no guidance for which types of physical > >entities should provide a mfg date. FRUs only? > >More text is needed for both of these new objects. > > Could one of the people who felt strongly that these objects should > be included in the Entity MIB update please respond to Andy's request > for more information? I suggest to add language to entPhysicalMfgDate which says that there is a default value in case the manufacturing date is unknown: The value '0000000000000000'H is returned if the manufacturing date of the entity in unknown. I don't think we need to constrain this object to FRUs. 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 From entmib-bounces@ietf.org Tue Nov 30 08:19: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 IAA15929 for ; Tue, 30 Nov 2004 08:19:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ7ra-0002rz-SU; Tue, 30 Nov 2004 08:16:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ7lo-0001lX-Dr for entmib@megatron.ietf.org; Tue, 30 Nov 2004 08:10: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 IAA15261 for ; Tue, 30 Nov 2004 08:10:14 -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 1CZ7qu-00036b-GN for entmib@ietf.org; Tue, 30 Nov 2004 08:15:33 -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 210006; Tue, 30 Nov 2004 08:03:35 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20041130112409.GE2823@james> References: <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> <20041130112409.GE2823@james> Date: Tue, 30 Nov 2004 08:09:56 -0500 To: j.schoenwaelder@iu-bremen.de From: Margaret Wasserman Subject: Re: [Entmib] Entity MIB v3 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 At 12:24 PM +0100 11/30/04, Juergen Schoenwaelder wrote: >I suggest to add language to entPhysicalMfgDate which says that there >is a default value in case the manufacturing date is unknown: > > The value '0000000000000000'H is returned if the manufacturing > date of the entity in unknown. > >I don't think we need to constrain this object to FRUs. This seems reasonable to me. >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. The Entity MIB update has been hanging out in various nebulous states quite literally for _years_. This WG has reached a level of delay/inaction that is appalling (for which I accept some of the blame), we seem to placing theory above practice, and we have a penchant for finding new rat-holes... Some symptoms of our current disease include: - We have continuously had 4-7 issues open with the Entity State MIB for over a year. We agreed to the resolution of all 7 outstanding issues in August, only to open 4 or 5 more when we tried to do a final check that those 7 had been address correctly. When does this stop? Is there anyone who actually wants to see this MIB get published (besides me and Sharon)? Is anyone implementing it? What is the driver to finish this work? - We added deprecated objects back into the Entity MIB, preventing it from going to DS, because those objects are purported to be essential to the SNMP information model. But, as far as we can tell, NO ONE HAS _EVER_ IMPLEMENTED THOSE OBJECTS!! How essential could they really be if they don't actually exist in the real world? - Accepting the consensus of the group, Andy agreed to produce a new version of the Entity MIB with the objects un-deprecated that could recycle at PS. Then, people decided that we should add a new set of objects to the MIB. Several people spoke out that these objects were important to add, but no one responded for almost a month when Andy asked for help defining the objects, not even the person who first proposed them. What am I supposed to do? Bert periodically threatens to shut the group down because we aren't making progress, and I keep putting him off because we are one or two months away from completion. How long can this go on? Should I just say "okay" next time he asks? I do understand the desire to add this feature to the MIB, but I think that we are suffering from terminal mission creep. AFAICT, there is no reason not to publish an update to the Entity MIB now (without the new, poorly specified objects) and to later publish an extension and/or an update that adds these objects if/when anyone cares enough to actually do the work. What do others think? Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Tue Nov 30 08:47: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 IAA17643 for ; Tue, 30 Nov 2004 08:47: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 1CZ8Kg-0008DI-9K; Tue, 30 Nov 2004 08:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8JK-0007WJ-Fe for entmib@megatron.ietf.org; Tue, 30 Nov 2004 08:44:57 -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 IAA17416 for ; Tue, 30 Nov 2004 08:44:52 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ8OR-0003iz-1r for entmib@ietf.org; Tue, 30 Nov 2004 08:50:12 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id DD0353619; Tue, 30 Nov 2004 14:44:21 +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 21018-09; Tue, 30 Nov 2004 14:44:21 +0100 (CET) Received: from james (unknown [10.71.235.255]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 0BA303614; Tue, 30 Nov 2004 14:44:21 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZ8In-0000ye-OS; Tue, 30 Nov 2004 14:44:21 +0100 Date: Tue, 30 Nov 2004 14:44:21 +0100 From: Juergen Schoenwaelder To: Margaret Wasserman Subject: Re: [Entmib] Entity MIB v3 Message-ID: <20041130134421.GA3686@james> Mail-Followup-To: Margaret Wasserman , entmib@ietf.org, kaj@research.telcordia.com, Andy Bierman References: <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> <20041130112409.GE2823@james> 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: 79899194edc4f33a41f49410777972f8 Cc: entmib@ietf.org, kaj@research.telcordia.com, 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 Tue, Nov 30, 2004 at 08:09:56AM -0500, Margaret Wasserman wrote: > AFAICT, there is no reason not to publish an update to the Entity MIB now > (without the new, poorly specified objects) and to later publish an > extension and/or an update that adds these objects if/when anyone > cares enough to actually do the work. I do not agree that these two objects are poorly specified. Your mileage obviously varies. Procedurally, I suggest to start a last call on this document - if Andy wants to undeprecate some more stuff, ask him to post a revised document in a week and start a last call on that version. Simply put, set clear deadlines and make sure any followup work is done on time. /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 Nov 30 09:54: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 JAA24297 for ; Tue, 30 Nov 2004 09:54:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9Kn-00069T-Ho; Tue, 30 Nov 2004 09:50:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ98q-0002Py-QO for entmib@megatron.ietf.org; Tue, 30 Nov 2004 09:38:09 -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 JAA22318 for ; Tue, 30 Nov 2004 09:38:06 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Dx-000534-IZ for entmib@ietf.org; Tue, 30 Nov 2004 09:43:26 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2004 06:37:48 -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-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAUEbVtR009176; Tue, 30 Nov 2004 06:37:33 -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 BBL88623; Tue, 30 Nov 2004 06:37:30 -0800 (PST) Message-Id: <4.3.2.7.2.20041130062101.02212380@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Nov 2004 06:37:29 -0800 To: Margaret Wasserman From: Andy Bierman Subject: Re: [Entmib] Entity MIB v3 In-Reply-To: References: <20041130112409.GE2823@james> <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> <20041130112409.GE2823@james> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: entmib@ietf.org, j.schoenwaelder@iu-bremen.de, 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 05:09 AM 11/30/2004, Margaret Wasserman wrote: >At 12:24 PM +0100 11/30/04, Juergen Schoenwaelder wrote: >>I suggest to add language to entPhysicalMfgDate which says that there >>is a default value in case the manufacturing date is unknown: >> >> The value '0000000000000000'H is returned if the manufacturing >> date of the entity in unknown. >> >>I don't think we need to constrain this object to FRUs. > >This seems reasonable to me. Unfortunately, the DateAndTime TC doesn't allow this value: field octets contents range ----- ------ -------- ----- 1 1-2 year* 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC* 0..13 10 11 minutes from UTC 0..59 Fields 3,4, and 8 cannot contain all zero bits. >>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. > >The Entity MIB update has been hanging out in various nebulous states quite literally for _years_. This WG has reached a level of delay/inaction that is appalling (for which I accept some of the blame), we seem to placing theory above practice, and we have a penchant for finding new rat-holes... > >Some symptoms of our current disease include: > >- We have continuously had 4-7 issues open with the Entity State MIB for over a year. We agreed to the resolution of all 7 outstanding issues in August, only to open 4 or 5 more when we tried to do a final check that those 7 had been address correctly. When does this stop? Is there anyone who actually wants to see this MIB get published (besides me and Sharon)? Is anyone implementing it? What is the driver to finish this work? > >- We added deprecated objects back into the Entity MIB, preventing it from going to DS, because those objects are purported to be essential to the SNMP information model. But, as far as we can tell, NO ONE HAS _EVER_ IMPLEMENTED THOSE OBJECTS!! How essential could they really be if they don't actually exist in the real world? Cisco has multiple independent implementations of the deprecated objects, but I'm not sure that counts as more than one implementation. >- Accepting the consensus of the group, Andy agreed to produce a new version of the Entity MIB with the objects un-deprecated that could recycle at PS. Then, people decided that we should add a new set of objects to the MIB. Several people spoke out that these objects were important to add, but no one responded for almost a month when Andy asked for help defining the objects, not even the person who first proposed them. > >What am I supposed to do? Bert periodically threatens to shut the group down because we aren't making progress, and I keep putting him off because we are one or two months away from completion. How long can this go on? Should I just say "okay" next time he asks? > >I do understand the desire to add this feature to the MIB, but I think that we are suffering from terminal mission creep. AFAICT, there is no reason not to publish an update to the Entity MIB now (without the new, poorly specified objects) and to later publish an extension and/or an update that adds these objects if/when anyone cares enough to actually do the work. I agree that the new objects are not well specified yet. Right now, these objects are mandatory, so the conformance (entityPhysical3Group in MANDATORY-GROUP clause) needs to change. There is no way to provide a N/A value for entPhysicalMfgDate. There is no multi-vendor interoperability possible with the entPhysicalUris object as currently defined. >What do others think? > >Margaret Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Tue Nov 30 10:12: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 KAA26362 for ; Tue, 30 Nov 2004 10:12: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 1CZ9e3-0007SF-VX; Tue, 30 Nov 2004 10:10:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9ZW-0005Lg-8Z for entmib@megatron.ietf.org; Tue, 30 Nov 2004 10:05: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 KAA25426 for ; Tue, 30 Nov 2004 10:05:40 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9ed-0005qv-6l for entmib@ietf.org; Tue, 30 Nov 2004 10:11:00 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1895F3614; Tue, 30 Nov 2004 16:05:09 +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 26459-09; Tue, 30 Nov 2004 16:05:08 +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 249973612; Tue, 30 Nov 2004 16:05:08 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZ9Yz-0001Cc-2G; Tue, 30 Nov 2004 16:05:09 +0100 Date: Tue, 30 Nov 2004 16:05:08 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [Entmib] Entity MIB v3 Message-ID: <20041130150508.GA4506@james> Mail-Followup-To: Andy Bierman , Margaret Wasserman , entmib@ietf.org, kaj@research.telcordia.com References: <20041130112409.GE2823@james> <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> <20041130112409.GE2823@james> <4.3.2.7.2.20041130062101.02212380@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20041130062101.02212380@fedex.cisco.com> 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Margaret Wasserman , entmib@ietf.org, kaj@research.telcordia.com 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, Nov 30, 2004 at 06:37:29AM -0800, Andy Bierman wrote: > Unfortunately, the DateAndTime TC doesn't allow this value: > > field octets contents range > ----- ------ -------- ----- > 1 1-2 year* 0..65536 > 2 3 month 1..12 > 3 4 day 1..31 > 4 5 hour 0..23 > 5 6 minutes 0..59 > 6 7 seconds 0..60 > (use 60 for leap-second) > 7 8 deci-seconds 0..9 > 8 9 direction from UTC '+' / '-' > 9 10 hours from UTC* 0..13 > 10 11 minutes from UTC 0..59 > > Fields 3,4, and 8 cannot contain all zero bits. See the lengthy debate about this we had in the past and the errata which is posted on this issue on the RFC editor page. > I agree that the new objects are not well specified yet. > Right now, these objects are mandatory, so the conformance > (entityPhysical3Group in MANDATORY-GROUP clause) needs to change. > There is no way to provide a N/A value for entPhysicalMfgDate. See above. > There is no multi-vendor interoperability possible with the > entPhysicalUris object as currently defined. The URIs are intended to be used to carry identifiers outside of the scope of the IETF, specifically CLIE codes. The format I think is well defined to be interoperable. The semantics associated with the given URI are outside the scope of this document by the design of this construction so that proprietary (but widely used) CLIE codes can be put here. Perhaps you don't like the solution to use URIs to sidestep standardizing proprietary identification schemes. Perhaps you don't like the fact that no CLIE code URN document has been written so far. Perhaps you dislike the object in general. But just saying there is no multi-vendor interoperability does not convince me. This is an identification object, to some extend similar to sysObjectID. The value reported by sysObjectID also only makes sense if you happen to know the semantics what sysObjectID means. /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 Nov 30 10:58:27 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 KAA00897 for ; Tue, 30 Nov 2004 10:58:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAAB-0000g0-0W; Tue, 30 Nov 2004 10:43:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZA8Q-0008Pz-3Q for entmib@megatron.ietf.org; Tue, 30 Nov 2004 10:41: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 KAA29446 for ; Tue, 30 Nov 2004 10:41:43 -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 1CZADX-0006en-IF for entmib@ietf.org; Tue, 30 Nov 2004 10:47:04 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Nov 2004 08:48:19 +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-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAUFf89N020439; Tue, 30 Nov 2004 07:41:08 -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 BBL93113; Tue, 30 Nov 2004 07:41:08 -0800 (PST) Message-Id: <4.3.2.7.2.20041130073024.02914f08@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Nov 2004 07:41:05 -0800 To: j.schoenwaelder@iu-bremen.de From: Andy Bierman Subject: Re: [Entmib] Entity MIB v3 In-Reply-To: <20041130150508.GA4506@james> References: <4.3.2.7.2.20041130062101.02212380@fedex.cisco.com> <20041130112409.GE2823@james> <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> <20041130112409.GE2823@james> <4.3.2.7.2.20041130062101.02212380@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Margaret Wasserman , entmib@ietf.org, 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 07:05 AM 11/30/2004, Juergen Schoenwaelder wrote: >On Tue, Nov 30, 2004 at 06:37:29AM -0800, Andy Bierman wrote: > >> Unfortunately, the DateAndTime TC doesn't allow this value: >> >> field octets contents range >> ----- ------ -------- ----- >> 1 1-2 year* 0..65536 >> 2 3 month 1..12 >> 3 4 day 1..31 >> 4 5 hour 0..23 >> 5 6 minutes 0..59 >> 6 7 seconds 0..60 >> (use 60 for leap-second) >> 7 8 deci-seconds 0..9 >> 8 9 direction from UTC '+' / '-' >> 9 10 hours from UTC* 0..13 >> 10 11 minutes from UTC 0..59 >> >> Fields 3,4, and 8 cannot contain all zero bits. > >See the lengthy debate about this we had in the past and the errata >which is posted on this issue on the RFC editor page. > okay -- the correction still contains errors. Field 8 is supposed to contain a '+' or '-' char, not 0x00. >> I agree that the new objects are not well specified yet. >> Right now, these objects are mandatory, so the conformance >> (entityPhysical3Group in MANDATORY-GROUP clause) needs to change. >> There is no way to provide a N/A value for entPhysicalMfgDate. > >See above. > >> There is no multi-vendor interoperability possible with the >> entPhysicalUris object as currently defined. > >The URIs are intended to be used to carry identifiers outside of the >scope of the IETF, specifically CLIE codes. The format I think is well >defined to be interoperable. The semantics associated with the given >URI are outside the scope of this document by the design of this >construction so that proprietary (but widely used) CLIE codes can >be put here. Perhaps you don't like the solution to use URIs to >sidestep standardizing proprietary identification schemes. Perhaps >you don't like the fact that no CLIE code URN document has been >written so far. Perhaps you dislike the object in general. Perhaps. I think we have enough standard containers for proprietary content already. IMO, the bulk of app-dev work is related to the semantics. Associating a particular OID with the semantics (i.e., standard container or proprietary container) is trivial, and provides minimal standards value. >But just saying there is no multi-vendor interoperability does not >convince me. This is an identification object, to some extend similar >to sysObjectID. The value reported by sysObjectID also only makes >sense if you happen to know the semantics what sysObjectID means. At least with sysObjectID there is naming scope management via the IANA registration of enterprise ID values. I don't see how naming collisions are avoided with the entPhysicalUris object. >/js Andy _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-bounces@ietf.org Tue Nov 30 11:44:30 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 LAA05493 for ; Tue, 30 Nov 2004 11:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAzw-0006l8-Ru; Tue, 30 Nov 2004 11:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAla-0002oq-Jl for entmib@megatron.ietf.org; Tue, 30 Nov 2004 11:22: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 LAA03315 for ; Tue, 30 Nov 2004 11:22:12 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAqi-0007lj-C4 for entmib@ietf.org; Tue, 30 Nov 2004 11:27:33 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5D04C3250; Tue, 30 Nov 2004 17:21:41 +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 32082-03; Tue, 30 Nov 2004 17:21:40 +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 C93E13251; Tue, 30 Nov 2004 17:21:39 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZAl2-0001Sh-OJ; Tue, 30 Nov 2004 17:21:40 +0100 Date: Tue, 30 Nov 2004 17:21:40 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [Entmib] Entity MIB v3 Message-ID: <20041130162140.GD4506@james> Mail-Followup-To: Andy Bierman , Margaret Wasserman , entmib@ietf.org, kaj@research.telcordia.com References: <4.3.2.7.2.20041130062101.02212380@fedex.cisco.com> <20041130112409.GE2823@james> <4.3.2.7.2.20041104112435.02e10e70@fedex.cisco.com> <20041130112409.GE2823@james> <4.3.2.7.2.20041130062101.02212380@fedex.cisco.com> <4.3.2.7.2.20041130073024.02914f08@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20041130073024.02914f08@fedex.cisco.com> 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: d6b246023072368de71562c0ab503126 Cc: Margaret Wasserman , entmib@ietf.org, kaj@research.telcordia.com 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, Nov 30, 2004 at 07:41:05AM -0800, Andy Bierman wrote: > okay -- the correction still contains errors. > Field 8 is supposed to contain a '+' or '-' char, not 0x00. The UTC offset if option. Please count the zeros - in case I did submit too many, I apologize and leave it to you to remove some. ;-) > At least with sysObjectID there is naming scope management via > the IANA registration of enterprise ID values. I don't see how > naming collisions are avoided with the entPhysicalUris object. There is a URI registry in place. IANA manages this like usual. /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 Nov 30 11:56: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 LAA06574 for ; Tue, 30 Nov 2004 11:56: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 1CZBGI-0002oF-45; Tue, 30 Nov 2004 11:53:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZB1H-0007AR-HU for entmib@megatron.ietf.org; Tue, 30 Nov 2004 11:38: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 LAA04934 for ; Tue, 30 Nov 2004 11:38:24 -0500 (EST) Message-Id: <200411301638.LAA04934@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZB6M-0008DE-SQ for entmib@ietf.org; Tue, 30 Nov 2004 11:43:46 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2004113016373401200ibpi3e>; Tue, 30 Nov 2004 16:37:34 +0000 From: "David B Harrington" To: "'Andy Bierman'" , Subject: RE: [Entmib] Entity MIB v3 Date: Tue, 30 Nov 2004 11:37:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4.3.2.7.2.20041130073024.02914f08@fedex.cisco.com> Thread-Index: AcTW9V0REjgZbJYiSlqHy9u4tAaIeAAAltwQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Cc: "'Margaret Wasserman'" , entmib@ietf.org, kaj@research.telcordia.com X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net 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: 7bit Hi, I'd like to see the mfgdate standardized. It could be useful to identify something like a mfg code or OEM part number, to make it easier to identify problem components for things like product recalls. Enterasys uses a proprietary MIB object for this type of information (amongst other info). In some cases, other SDOs define standards for the semantics. The information is not necessarily something that we are likely to reach standardization on. This information is likely to be available via the CLI or an HTML-based interface, and it might be useful to define an SNMP-equivalent, but a URI is not a normal SNMP construct. I agree there is the possibility of namespace conflict, and the usefulness of this object to a vendor-neutral application is questionable. I don't object to removing this object from this module. For those who wish to use a CLIE URI, I suggest they write an RFC with the CLIE codes and include a mib module with the URI object to augment the entity mib table. Hopefully, they will also include an object to identify the namespace. Dbh > -----Original Message----- > From: entmib-bounces@ietf.org > [mailto:entmib-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Tuesday, November 30, 2004 10:41 AM > To: j.schoenwaelder@iu-bremen.de > Cc: Margaret Wasserman; entmib@ietf.org; kaj@research.telcordia.com > Subject: Re: [Entmib] Entity MIB v3 > > At 07:05 AM 11/30/2004, Juergen Schoenwaelder wrote: > >On Tue, Nov 30, 2004 at 06:37:29AM -0800, Andy Bierman wrote: > > > >> Unfortunately, the DateAndTime TC doesn't allow this value: > >> > >> field octets contents range > >> ----- ------ -------- ----- > >> 1 1-2 year* 0..65536 > >> 2 3 month 1..12 > >> 3 4 day 1..31 > >> 4 5 hour 0..23 > >> 5 6 minutes 0..59 > >> 6 7 seconds 0..60 > >> (use 60 for leap-second) > >> 7 8 deci-seconds 0..9 > >> 8 9 direction from UTC '+' / '-' > >> 9 10 hours from UTC* 0..13 > >> 10 11 minutes from UTC 0..59 > >> > >> Fields 3,4, and 8 cannot contain all zero bits. > > > >See the lengthy debate about this we had in the past and the errata > >which is posted on this issue on the RFC editor page. > > > > okay -- the correction still contains errors. > Field 8 is supposed to contain a '+' or '-' char, not 0x00. > > >> I agree that the new objects are not well specified yet. > >> Right now, these objects are mandatory, so the conformance > >> (entityPhysical3Group in MANDATORY-GROUP clause) needs to change. > >> There is no way to provide a N/A value for entPhysicalMfgDate. > > > >See above. > > > >> There is no multi-vendor interoperability possible with the > >> entPhysicalUris object as currently defined. > > > >The URIs are intended to be used to carry identifiers outside of the > >scope of the IETF, specifically CLIE codes. The format I > think is well > >defined to be interoperable. The semantics associated with the given > >URI are outside the scope of this document by the design of this > >construction so that proprietary (but widely used) CLIE codes can be > >put here. Perhaps you don't like the solution to use URIs to > sidestep > >standardizing proprietary identification schemes. Perhaps you don't > >like the fact that no CLIE code URN document has been > written so far. > >Perhaps you dislike the object in general. > > Perhaps. I think we have enough standard containers for > proprietary content already. IMO, the bulk of app-dev work > is related to the semantics. Associating a particular OID > with the semantics (i.e., standard container or proprietary > container) is trivial, and provides minimal standards value. > > > >But just saying there is no multi-vendor interoperability does not > >convince me. This is an identification object, to some extend similar > >to sysObjectID. The value reported by sysObjectID also only makes > >sense if you happen to know the semantics what sysObjectID means. > > At least with sysObjectID there is naming scope management via > the IANA registration of enterprise ID values. I don't see how > naming collisions are avoided with the entPhysicalUris object. > > > >/js > > Andy > > > _______________________________________________ > 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 Tue Nov 30 14:16:06 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 OAA21872 for ; Tue, 30 Nov 2004 14:16: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 1CZDID-0002uC-IJ; Tue, 30 Nov 2004 14:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDCx-0001A8-JF for entmib@megatron.ietf.org; Tue, 30 Nov 2004 13:58: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 NAA20240 for ; Tue, 30 Nov 2004 13:58:37 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDI7-0003tY-Aj for entmib@ietf.org; Tue, 30 Nov 2004 14:04:00 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A30DA3256; Tue, 30 Nov 2004 19:58:06 +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 08646-03; Tue, 30 Nov 2004 19:58:05 +0100 (CET) Received: from james (Ib38f.i.pppool.de [85.73.179.143]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id BCBD635FA; Tue, 30 Nov 2004 19:58:04 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZDCN-0000bf-W9; Tue, 30 Nov 2004 19:58:04 +0100 Date: Tue, 30 Nov 2004 19:58:03 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Entmib] Entity MIB v3 Message-ID: <20041130185803.GB2231@james> Mail-Followup-To: David B Harrington , 'Andy Bierman' , 'Margaret Wasserman' , entmib@ietf.org, kaj@research.telcordia.com References: <4.3.2.7.2.20041130073024.02914f08@fedex.cisco.com> <200411301638.LAA04934@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411301638.LAA04934@ietf.org> 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: 8b30eb7682a596edff707698f4a80f7d Cc: "'Margaret Wasserman'" , entmib@ietf.org, kaj@research.telcordia.com, "'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 Tue, Nov 30, 2004 at 11:37:31AM -0500, David B Harrington wrote: > It could be useful to identify something like a mfg code or OEM part > number, to make it easier to identify problem components for things > like product recalls. Enterasys uses a proprietary MIB object for this > type of information (amongst other info). In some cases, other SDOs > define standards for the semantics. The information is not necessarily > something that we are likely to reach standardization on. This > information is likely to be available via the CLI or an HTML-based > interface, and it might be useful to define an SNMP-equivalent, but a > URI is not a normal SNMP construct. I read this as an argument in favor of the entPhysicalUris addition. > I agree there is the possibility of namespace conflict, and the > usefulness of this object to a vendor-neutral application is > questionable. Please someone explain to me the namespace conflict you are seeing. > I don't object to removing this object from this module. For those who > wish to use a CLIE URI, I suggest they write an RFC with the CLIE > codes and include a mib module with the URI object to augment the > entity mib table. Hopefully, they will also include an object to > identify the namespace. Now you seem to argue against the entPhysicalUris addition. (I fail to see why you need an object to identify a namespace since the namespace should be clear from the URI. But then I admit that I fail to understand the point raised above, so I am obviously missing some pieces here.) So, Dave, what do you want to tell us? /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 Nov 30 17:35:30 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 RAA23911 for ; Tue, 30 Nov 2004 17:35:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGE4-0007Cj-EX; Tue, 30 Nov 2004 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFFQ-0008DN-2r for entmib@megatron.ietf.org; Tue, 30 Nov 2004 16:09:20 -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 QAA07230 for ; Tue, 30 Nov 2004 16:09:16 -0500 (EST) Message-Id: <200411302109.QAA07230@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFKW-0008Rn-S5 for entmib@ietf.org; Tue, 30 Nov 2004 16:14:40 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc11) with SMTP id <20041130210843011004ipb2e>; Tue, 30 Nov 2004 21:08:44 +0000 From: "David B Harrington" To: Subject: RE: [Entmib] Entity MIB v3 Date: Tue, 30 Nov 2004 16:08:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041130185803.GB2231@james> Thread-Index: AcTXDohUU2SJJs2nTYOo0T6Od6MvWwADaO/A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: "'Margaret Wasserman'" , entmib@ietf.org, kaj@research.telcordia.com, "'Andy Bierman'" X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net 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: 7bit Hi, Sorry that I confuse you. I don't have much knowledge of URIs, so if the namespace issue is already resolved by URI standardization, that's an improvement over the potential for conflict that I thought would exist. I should have done my homework better. I see both sides of the argument for entPhysicalUris. I feel entPhysicalUris could be a useful object for some purposes, like recalls and consistency with other NM interfaces, but, as currently specified, I think that it is likely to be useful primarily for a proprietary application interpreting the proprietary value of the object, and to support a manual usage rather than a programmtic usage. The proprietary nature of the semantics seriously limits it from being a useful vendor-neutral standardized solution, and useful vendor-neutral standards are what we should be trying to produce. As part of the "MIB Police" at Enterasys, I always liked to ask "what application will actually use this data?" If no vendor-neutral application vendor is likely to actually interpret the data, maybe its existence isn't justified. Are there application developers in this WG that think having this data made available via an SNMP standard mib module is really important? If not, maybe we would be better off leaving it out; it can always be added in later via another mib module. Have we asked how many vendors have propietary mib modules defined for this data? If many do, then maybe we have a case for standardizing the object, but if so, I think we should standardize the content, not just the container, and the current proposed object is under-specified. To clarify my position - entPhysicalUris hasn't been sufficiently justified or specified to be included in the entity mib; we should eliminate it. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, November 30, 2004 1:58 PM > To: David B Harrington > Cc: 'Andy Bierman'; 'Margaret Wasserman'; entmib@ietf.org; > kaj@research.telcordia.com > Subject: Re: [Entmib] Entity MIB v3 > > On Tue, Nov 30, 2004 at 11:37:31AM -0500, David B Harrington wrote: > > > It could be useful to identify something like a mfg code or > OEM part > > number, to make it easier to identify problem components for things > > like product recalls. Enterasys uses a proprietary MIB > object for this > > type of information (amongst other info). In some cases, other SDOs > > define standards for the semantics. The information is not > necessarily > > something that we are likely to reach standardization on. This > > information is likely to be available via the CLI or an HTML-based > > interface, and it might be useful to define an > SNMP-equivalent, but a > > URI is not a normal SNMP construct. > > I read this as an argument in favor of the entPhysicalUris addition. > > > I agree there is the possibility of namespace conflict, and the > > usefulness of this object to a vendor-neutral application is > > questionable. > > Please someone explain to me the namespace conflict you are seeing. > > > I don't object to removing this object from this module. > For those who > > wish to use a CLIE URI, I suggest they write an RFC with the CLIE > > codes and include a mib module with the URI object to augment the > > entity mib table. Hopefully, they will also include an object to > > identify the namespace. > > Now you seem to argue against the entPhysicalUris addition. > (I fail to see why you need an object to identify a namespace > since the namespace should be clear from the URI. But then I > admit that I fail to understand the point raised above, so I > am obviously missing some pieces here.) > > So, Dave, what do you want to tell us? > > /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 Nov 30 17:44:58 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 RAA24991 for ; Tue, 30 Nov 2004 17:44: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 1CZGN3-0005AY-IN; Tue, 30 Nov 2004 17:21:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFru-00055f-73 for entmib@megatron.ietf.org; Tue, 30 Nov 2004 16:49: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 QAA16605 for ; Tue, 30 Nov 2004 16:49:03 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFx4-00031L-VY for entmib@ietf.org; Tue, 30 Nov 2004 16:54:28 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 82FDD35F8; Tue, 30 Nov 2004 22:48:33 +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 17321-03; Tue, 30 Nov 2004 22:48:32 +0100 (CET) Received: from james (Ib38f.i.pppool.de [85.73.179.143]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8213A35F3; Tue, 30 Nov 2004 22:48:32 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CZFrL-0000hR-Lu; Tue, 30 Nov 2004 22:48:31 +0100 Date: Tue, 30 Nov 2004 22:48:31 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Entmib] Entity MIB v3 Message-ID: <20041130214831.GA2524@james> Mail-Followup-To: David B Harrington , 'Andy Bierman' , 'Margaret Wasserman' , entmib@ietf.org, kaj@research.telcordia.com References: <20041130185803.GB2231@james> <20041130210845.490A135D9@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041130210845.490A135D9@hermes.iu-bremen.de> 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: "'Margaret Wasserman'" , entmib@ietf.org, kaj@research.telcordia.com, "'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 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. /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