RE: [Entmib] Entity MIB v3

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Thu, 02 December 2004 11:18 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 GAA00571 for <entmib-archive@lists.ietf.org>; Thu, 2 Dec 2004 06:18:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZohx-00029L-1e; Thu, 02 Dec 2004 06:01:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZnSJ-0001P9-Hh for entmib@megatron.ietf.org; Thu, 02 Dec 2004 04:41:00 -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 EAA23834 for <entmib@ietf.org>; Thu, 2 Dec 2004 04:40:53 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZnXl-00051d-J7 for entmib@ietf.org; Thu, 02 Dec 2004 04:46:36 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iB29eJCk021202 for <entmib@ietf.org>; Thu, 2 Dec 2004 03:40:19 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <XJHXCN7Y>; Thu, 2 Dec 2004 10:40:18 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15505CEF9DF@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Andy Bierman <abierman@cisco.com>, j.schoenwaelder@iu-bremen.de
Subject: RE: [Entmib] Entity MIB v3
Date: Thu, 2 Dec 2004 10:40:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
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

> 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 }

I do not like citations inside a MIB module, and certainly I do not
see why a citation has to be made in above text, it seems redundant to me.

If it is needed because this is the only place in the doc that we
discuss this reference, then maybe a better methos is:

     REFERENCE
             "RFC 2396, Uniform Resource Identifiers (URI): Generic
             Syntax, section 2, August 1998." -- [RFC2396]

But probably best is to have some prose outside of the MIB module
definition itself and add a citation there.

> 
> **************************************************************
> ***********
> 
> 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?
> 

If we want to use these RFC2396 material, would it not be better to
define two TCs, UriTC and UrisTC or some such? I know that if we go
this path that it may just introduce more delay, which is not my
intention. And so I won't object heavily if we decide to leave a
proper set of TC definitions to some other effort outside this WG.

> IMO, this object is too vague to be in a standards document.

Mmm... rfc2396 is stds track, so why do you think it is too vague?

Bert

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