RE: Entity MIB v3

Hi,

I'd like to see the mfgdate standardized. 

It could be useful to identify something like a mfg code or OEM part
number, to make it easier to identify problem components for things
like product recalls. Enterasys uses a proprietary MIB object for this
type of information (amongst other info). In some cases, other SDOs
define standards for the semantics. The information is not necessarily
something that we are likely to reach standardization on. This
information is likely to be available via the CLI or an HTML-based
interface, and it might be useful to define an SNMP-equivalent, but a
URI is not a normal SNMP construct.

I agree there is the possibility of namespace conflict, and the
usefulness of this object to a vendor-neutral application is
questionable. 

I don't object to removing this object from this module. For those who
wish to use a CLIE URI, I suggest they write an RFC with the CLIE
codes and include a mib module with the URI object to augment the
entity mib table. Hopefully, they will also include an object to
identify the namespace.

Dbh

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Andy Bierman
> Sent: Tuesday, November 30, 2004 10:41 AM
> To: [email protected]
> Cc: Margaret Wasserman; [email protected]; [email protected]
> Subject: Re: [Entmib] 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
> 
> 
> _______________________________________________
> Entmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/entmib
>