RE: Entity MIB v3

> 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