Re: Entity MIB v3

At 07:05 AM 11/30/2004, Juergen Schoenwaelder wrote:
>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.
> 

okay -- the correction still contains errors.
Field 8 is supposed to contain a '+' or '-' char, not 0x00.

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

Perhaps.  I think we have enough standard containers for
proprietary content already.  IMO, the bulk of app-dev work
is related to the semantics.  Associating a particular OID 
with the semantics (i.e., standard container or proprietary
container) is trivial, and provides minimal standards value.


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

At least with sysObjectID there is naming scope management via
the IANA registration of enterprise ID values.  I don't see how
naming collisions are avoided with the entPhysicalUris object.


>/js

Andy