Subject: Re: [Entmib] Entity MIB v3

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Dec 2004 09:16:05 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: Kaj Tesink <[email-masked]>
Date: Wed, 01 Dec 2004 14:39:19 -0500

> >here because nobody cares, then go ahead and nuke the definition.

sorry for being off-line yesterday and delayed reaction.
as i was one of the folks asking for this object, let me
try to capture where we are and how we got here.

the original request was for two objects to reflect
the manufacturing date and the CLEI; after discussion that
found its way in a supplemental Entity MIB.
i believe that sufficient support for these objects was demonstrated
but there were several issues on how to reflect and document
the objects.

the supplemental MIB idea was abandoned since we were
recycling the entmib at Proposed anyway.
through discussion between Dave P and Juergen S we arrived
at the elegant solution of the URI object, allowing
multiple URIs; the approach solved multiple concerns
and seems future compatible in that it allows things
of other URNs to be managed as well.
going back to a CLEI-specific object would be fine
with me but i thought there were several good arguments
in the past on why the URI approach works better.

>but let's decide already.

[T1.213]    ATIS T1.213-2001, Coded Identification of Equipment Entities
             in the North American Telecommunications System for
             Information Exchange, 2001, www.ansi.org

[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,
             2001, www.ansi.org

i'm guilty of being slow in publishing the CLEI URN namespace request
(will submit the draft tomorrow):

Work in progress <draft-tesink-urn-clei-00.txt>
Tesink, K., Robert H. Fox, Uniform Resource Name (URN)
Namespace for the CLEI Code, RFCxxxx, xxxxxx 2004.

>   - Is zero-length string allowed, instead or as well as

personally i dont like options and would just pick one.
i suggested not-instantiated before but no strong pref

>   - Is only whitespace allowed?

as above, i'd just pick one delimiter and stick with it;
white space seems to work

>   - Is preceding or trailing whitespace allowed?

i'd argue that good practice shouldnt produce
preceding or trailing whitespace but that it shouldnt
break things either in this case.

>     The issue is: Is that okay or not?

the purpose here is identification (as Juergen
pointed out) and not the creation of some kind of an opaque
construct.

kaj

>for the CLEI URI format).

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. Inc.
One Telcordia drive
Piscataway, NJ 08854
Email: [email-masked]
Tel: (732) 699-6068
Fax: (732) 336-2336

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/