Re: [Entmib] Re: Entity mib support for tcif

Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> Thu, 15 April 2004 08:15 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10534 for <entmib-archive@lists.ietf.org>; Thu, 15 Apr 2004 04:15:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1xk-0005x1-K5; Thu, 15 Apr 2004 04:11:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE1ur-0004a2-2U for entmib@optimus.ietf.org; Thu, 15 Apr 2004 04:08:09 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09743 for <entmib@ietf.org>; Thu, 15 Apr 2004 04:08:06 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE1uo-0007mk-00 for entmib@ietf.org; Thu, 15 Apr 2004 04:08:06 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE1tr-0007iF-00 for entmib@ietf.org; Thu, 15 Apr 2004 04:07:08 -0400
Received: from g5b63.g.pppool.de ([80.185.91.99] helo=james.eecs.iu-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1BE1t0-0007dQ-00 for entmib@ietf.org; Thu, 15 Apr 2004 04:06:15 -0400
Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 22B698906; Thu, 15 Apr 2004 10:06:15 +0200 (CEST)
Date: Thu, 15 Apr 2004 10:06:15 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
To: "David T. Perkins" <dperkins@dsperkins.com>
Cc: Kaj Tesink <kaj@research.telcordia.com>, entmib@ietf.org
Subject: Re: [Entmib] Re: Entity mib support for tcif
Message-ID: <20040415080615.GA1021@iu-bremen.de>
Reply-To: j.schoenwaelder@iu-bremen.de
Mail-Followup-To: "David T. Perkins" <dperkins@dsperkins.com>, Kaj Tesink <kaj@research.telcordia.com>, entmib@ietf.org
References: <93401232EABAAB4EA430E13ECC701CCF63A9CC@yorktown.pedestalnetworks.com> <5.2.0.9.2.20040414212356.02415658@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5.2.0.9.2.20040414212356.02415658@127.0.0.1>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Sender: entmib-admin@ietf.org
Errors-To: entmib-admin@ietf.org
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Id: IETF Entity MIB WG <entmib.ietf.org>
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>

On Wed, Apr 14, 2004 at 10:13:57PM -0700, David T. Perkins wrote:
 
> entPhysicalSupplManfactDate  OBJECT-TYPE
>     SYNTAX      DateAndTimeOrZero
>     MAX-ACCESS  read-only  -- maybe this should be w/r like serial number
>     STATUS      current
>     DESCRIPTION
>       "The manufacturing date for the physical entity, or 'zero'
>       if the date is unknown or not appropriate."
>     ::= { entSupplPhysicalEntry 1 }

We do not have DateAndTimeOrZero. Why not use what seems to work
everywhere else?

	"The manufacturing date for the physical entity. The special 
	 value '0000000000000000'H is used if the date is unknown or 
	 not appropriate."

> entPhysicalSupplAltTypes OBJECT-TYPE
>     SYNTAX      Utf8String
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
>           "A zero length string if the value is unknown or not
>           appropriate; or one, or more pairs of tag and value
>           which provide alternative identification of the entity
>           in addition to the value of object entPhysicalVendorType.
>           This object was added so that one or more industry
>           sectors could add sector specific identification codes.
>           It is expected that typically, at most a single sector
>           identification code will be present. However, managers
>           must cope with a list of tag-value pairs.
>           The format of the value (when not a zero length string) is:
>             <pair>[;<pair>]...
>           where the format of <pair> is
>             <id>:<value>
>           where the values for <id> are short strings managed by IANA,
>           and <value> follows the rules for an <id> definition,
>           and may include any character other than ';'. The first
>           defined <id> is 'CLEI', and when so, the values for
>           <value> are 1 to 10 characters long as defined by 
>           TCIF-02-004, Guideline for data elements
>           included in the Management Information Base,
>           Telecommunications Industry Forum (TCIF), 09/11/2002.
> 
>           An example value is 'CLEI:ABCDEFGHIJ'"
>     ::= { entSupplPhysicalEntry 2 }

How did you pick the special characters : and ;? Do you have evidence
that these characters will not be used by identification code schemes? 
And does this not complicate matters instead of just saying this is the
CLEI code object (and to potentially add other identification objects
as the need arises)? I mean, it is easy to return a zero length string
or not to implement the object at all.

An alternative might be to actually add a URI object for identification
purposes. It is then the job of the CLEI folks to write up a URN
definition so that they can use CLEI codes for identification. I think
such an approach would be much better than creating a special purpose
name space just for this single MIB object.

/js



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