Re: [Entmib] Entity MIB v3

Andy Bierman <abierman@cisco.com> Wed, 01 December 2004 18:46 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 NAA08747 for <entmib-archive@lists.ietf.org>; Wed, 1 Dec 2004 13:46:11 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYll-0003SN-H8; Wed, 01 Dec 2004 13:00:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZY9P-0004Th-TY for entmib@megatron.ietf.org; Wed, 01 Dec 2004 12:20:24 -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 MAA28653 for <entmib@ietf.org>; Wed, 1 Dec 2004 12:20:21 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZYEb-0005Db-MZ for entmib@ietf.org; Wed, 01 Dec 2004 12:25:56 -0500
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2004 09:19:45 -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-3.cisco.com (8.12.10/8.12.6) with ESMTP id iB1HJbRR005055; Wed, 1 Dec 2004 09:19:38 -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 BBN13385; Wed, 1 Dec 2004 09:16:06 -0800 (PST)
Message-Id: <4.3.2.7.2.20041201085157.021c5250@fedex.cisco.com>
X-Sender: abierman@fedex.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 01 Dec 2004 09:16:05 -0800
To: j.schoenwaelder@iu-bremen.de
From: Andy Bierman <abierman@cisco.com>
Subject: Re: [Entmib] Entity MIB v3
In-Reply-To: <20041130214831.GA2524@james>
References: <20041130210845.490A135D9@hermes.iu-bremen.de> <20041130185803.GB2231@james> <20041130210845.490A135D9@hermes.iu-bremen.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: "'Margaret Wasserman'" <margaret@thingmagic.com>, entmib@ietf.org, David B Harrington <ietfdbh@comcast.net>, kaj@research.telcordia.com
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

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
    SYNTAX      OCTET STRING
    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
            [RFC2396] section 2. Multiple URIs may be separated by white
            space characters."
    REFERENCE
            "RFC 2396, Uniform Resource Identifiers (URI): Generic
            Syntax, section 2, August 1998."

    ::= { entPhysicalEntry 18 }

*************************************************************************

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

>/js

Andy


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