Re: [Entmib] CONSENSUS CHECK: Undo entAliasMapping deprecation

Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> Wed, 18 August 2004 08:37 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18244 for <entmib-archive@lists.ietf.org>; Wed, 18 Aug 2004 04:37:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxLwG-0005Gp-Kf; Wed, 18 Aug 2004 04:36:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BxLsQ-0004t5-WD for entmib@megatron.ietf.org; Wed, 18 Aug 2004 04:32:59 -0400
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 EAA17994 for <entmib@ietf.org>; Wed, 18 Aug 2004 04:32:57 -0400 (EDT)
Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BxLya-0007jp-SA for entmib@ietf.org; Wed, 18 Aug 2004 04:39:22 -0400
Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2CF855E39; Wed, 18 Aug 2004 10:32:25 +0200 (CEST)
Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22138-05; Wed, 18 Aug 2004 10:32:24 +0200 (CEST)
Received: from james.eecs.iu-bremen.de (unknown [212.201.47.66]) by hermes.iu-bremen.de (Postfix) with ESMTP id 56257AC2; Wed, 18 Aug 2004 10:32:24 +0200 (CEST)
Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 3935281F3; Wed, 18 Aug 2004 10:32:24 +0200 (CEST)
Date: Wed, 18 Aug 2004 10:32:24 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: Kaj Tesink <kaj@research.telcordia.com>
Subject: Re: [Entmib] CONSENSUS CHECK: Undo entAliasMapping deprecation
Message-ID: <20040818083224.GA4566@iu-bremen.de>
Mail-Followup-To: Kaj Tesink <kaj@research.telcordia.com>, entmib@ietf.org
References: <20040816082053.GD1761@iu-bremen.de> <p0602041fbd39fdb5fff2@[130.129.130.34]> <p0602041fbd39fdb5fff2@[130.129.130.34]> <4.3.2.7.2.20040817172040.026f8378@128.96.81.11>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4.3.2.7.2.20040817172040.026f8378@128.96.81.11>
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: 7aafa0432175920a4b3e118e16c5cb64
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 <entmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:entmib@ietf.org>
List-Help: <mailto:entmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=subscribe>
Sender: entmib-bounces@ietf.org
Errors-To: entmib-bounces@ietf.org

On Tue, Aug 17, 2004 at 05:31:24PM -0400, Kaj Tesink wrote:
> 
> further actions:
> - as per the emerging consensus, it is better to
>    insert the two objects in the entPhysicalEntry
>    of the entity mib itself; in that case all that is needed
>    is to cut&paste from the attached
> - we'll post the draft for the for CLEI URN namespace request soon
> - any other comments?

Cutting and pasting text from your proposal, I came up with this
proposal for integration into the ENTITY-MIB itself:

entPhysicalMfgDate OBJECT-TYPE
    SYNTAX	DateAndTime
    MAX-ACCESS	read-only
    STATUS	current
    DESCRIPTION
	"The manufacturing date for the physical entity. The value
	 '0000000000000000'H should be returned if the manufacturing
	 date for a physical entity is unknown."
    ::= { entPhysicalEntry 17 }

entPhysicalMfgID OBJECT-TYPE
    SYNTAX	DisplayString
    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 section 2. Multiple URIs may be separated by white 
	 space characters.

	 This object contains a zero-length string if no additional
         identification information is known or supported about the
         physical entity."
    ::= { entPhysicalEntry 18 }

I think we should say something about when it is appropriate to write 
entPhysicalMfgId and to what extend it is required to provide write 
support for this object. In addition, we have to say something about 
the persistence of any modifications.

Note that I called the objects *MfgDate and *MfgId since we already
have entPhysicalMfgName and I propose to use null values in case a
value is unknown since that avoids holes in tables and seems to be
more consistent with the other objects in the entPhysicalTable.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib