Re: [Entmib] Entity MIB v3

Andy Bierman <> Wed, 01 December 2004 18:46 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA08747 for <>; Wed, 1 Dec 2004 13:46:11 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CZYll-0003SN-H8; Wed, 01 Dec 2004 13:00:01 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CZY9P-0004Th-TY for; Wed, 01 Dec 2004 12:20:24 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA28653 for <>; Wed, 1 Dec 2004 12:20:21 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CZYEb-0005Db-MZ for; Wed, 01 Dec 2004 12:25:56 -0500
Received: from ( by with ESMTP; 01 Dec 2004 09:19:45 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id iB1HJbRR005055; Wed, 1 Dec 2004 09:19:38 -0800 (PST)
Received: from ( []) by (MOS 3.4.5-GR) with ESMTP id BBN13385; Wed, 1 Dec 2004 09:16:06 -0800 (PST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 Dec 2004 09:16:05 -0800
From: Andy Bierman <>
Subject: Re: [Entmib] Entity MIB v3
In-Reply-To: <20041130214831.GA2524@james>
References: <> <20041130185803.GB2231@james> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: "'Margaret Wasserman'" <>,, David B Harrington <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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
    MAX-ACCESS  read-write
    STATUS      current
            "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."
            "RFC 2396, Uniform Resource Identifiers (URI): Generic
            Syntax, section 2, August 1998."

    ::= { entPhysicalEntry 18 }


  - 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).



Entmib mailing list