Re: [Entmib] entPhysicalUris object wrap-up

Kaj Tesink <> Thu, 09 December 2004 23:48 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA29242 for <>; Thu, 9 Dec 2004 18:48:43 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CcXx9-0002Qj-VW; Thu, 09 Dec 2004 18:44:07 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CcXs6-0001Tl-I0 for; Thu, 09 Dec 2004 18:38:54 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA28464 for <>; Thu, 9 Dec 2004 18:38:52 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CcXzB-0005im-2k for; Thu, 09 Dec 2004 18:46:13 -0500
Received: from (shannon []) by (8.12.9/8.12.9) with ESMTP id iB9Nahcu024488; Thu, 9 Dec 2004 18:36:43 -0500 (EST)
Received: from ( []) by (8.9.3/8.9.3) with ESMTP id SAA21315; Thu, 9 Dec 2004 18:36:42 -0500 (EST)
Message-Id: <>
X-Sender: kaj@
X-Mailer: QUALCOMM Windows Eudora Version
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: <>
References: <p0620073ebdde00b935ad@[]> <> <> <p0620073ebdde00b935ad@[]> <>
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 <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

At 12:32 PM 12/9/2004, Andy Bierman wrote:


> >
> >the string in the Uri object, at least for the CLEI
> >application is well formatted and defined. IANA registries
> >  and
> >
> >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 and

      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
      For example, an entPhysicalUris instance may have the value  of


      [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

      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,

[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,

> >kaj

Entmib mailing list