Re: Entity MIB v3

On Tue, Nov 30, 2004 at 06:37:29AM -0800, Andy Bierman wrote:

> Unfortunately, the DateAndTime TC doesn't allow this value:
> 
>             field  octets  contents                  range
>             -----  ------  --------                  -----
>               1      1-2   year*                     0..65536
>               2       3    month                     1..12
>               3       4    day                       1..31
>               4       5    hour                      0..23
>               5       6    minutes                   0..59
>               6       7    seconds                   0..60
>                            (use 60 for leap-second)
>               7       8    deci-seconds              0..9
>               8       9    direction from UTC        '+' / '-'
>               9      10    hours from UTC*           0..13
>              10      11    minutes from UTC          0..59
> 
> Fields 3,4, and 8 cannot contain all zero bits.

See the lengthy debate about this we had in the past and the errata
which is posted on this issue on the RFC editor page.
 
> I agree that the new objects are not well specified yet.
> Right now, these objects are mandatory, so the conformance
> (entityPhysical3Group in MANDATORY-GROUP clause) needs to change.
> There is no way to provide a N/A value for entPhysicalMfgDate.

See above.

> There is no multi-vendor interoperability possible with the
> entPhysicalUris object as currently defined.

The URIs are intended to be used to carry identifiers outside of the
scope of the IETF, specifically CLIE codes. The format I think is well
defined to be interoperable. The semantics associated with the given
URI are outside the scope of this document by the design of this
construction so that proprietary (but widely used) CLIE codes can
be put here. Perhaps you don't like the solution to use URIs to
sidestep standardizing proprietary identification schemes. Perhaps
you don't like the fact that no CLIE code URN document has been
written so far. Perhaps you dislike the object in general.

But just saying there is no multi-vendor interoperability does not
convince me. This is an identification object, to some extend similar
to sysObjectID. The value reported by sysObjectID also only makes 
sense if you happen to know the semantics what sysObjectID means.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany