Re: [Entmib] Entity MIB v3

[Kaj Tesink <[e-mail]>]

At 12:16 PM 12/1/2004, Andy Bierman wrote:
>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.


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.

so, let me jump to Andy's practical questions below:


>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


[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
>     not instantiated?


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.


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


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

kaj



>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


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

Kaj Tesink
Telcordia Technologies. Inc.
One Telcordia drive
Piscataway, NJ 08854
Email: [e-mail]
Tel: [phone]
Fax: [phone]

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


_______________________________________________
Entmib mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/entmib