RE: [Entmib] Entity MIB v3

Hi,

Sorry that I confuse you.

I don't have much knowledge of URIs, so if the namespace issue is
already resolved by URI standardization, that's an improvement over
the potential for conflict that I thought would exist. I should have
done my homework better.

I see both sides of the argument for entPhysicalUris. I feel
entPhysicalUris could be a useful object for some purposes, like
recalls and consistency with other NM interfaces, but, as currently
specified, I think that it is likely to be useful primarily for a
proprietary application interpreting the proprietary value of the
object, and to support a manual usage rather than a programmtic usage.
The proprietary nature of the semantics seriously limits it from being
a useful vendor-neutral standardized solution, and useful
vendor-neutral standards are what we should be trying to produce. 

As part of the "MIB Police" at Enterasys, I always liked to ask "what
application will actually use this data?" If no vendor-neutral
application vendor is likely to actually interpret the data, maybe its
existence isn't justified. Are there application developers in this WG
that think having this data made available via an SNMP standard mib
module is really important? If not, maybe we would be better off
leaving it out; it can always be added in later via another mib
module.

Have we asked how many vendors have propietary mib modules defined for
this data? If many do, then maybe we have a case for standardizing the
object, but if so, I think we should standardize the content, not just
the container, and the current proposed object is under-specified.

To clarify my position - entPhysicalUris hasn't been sufficiently
justified or specified to be included in the entity mib; we should
eliminate it.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, November 30, 2004 1:58 PM
> To: David B Harrington
> Cc: 'Andy Bierman'; 'Margaret Wasserman'; entmib@ietf.org; 
> kaj@research.telcordia.com
> Subject: Re: [Entmib] Entity MIB v3
> 
> On Tue, Nov 30, 2004 at 11:37:31AM -0500, David B Harrington wrote:
>  
> > 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 read this as an argument in favor of the entPhysicalUris addition.
>  
> > I agree there is the possibility of namespace conflict, and the 
> > usefulness of this object to a vendor-neutral application is 
> > questionable.
> 
> Please someone explain to me the namespace conflict you are seeing.
>  
> > 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.
> 
> Now you seem to argue against the entPhysicalUris addition. 
> (I fail to see why you need an object to identify a namespace 
> since the namespace should be clear from the URI. But then I 
> admit that I fail to understand the point raised above, so I 
> am obviously missing some pieces here.)
> 
> So, Dave, what do you want to tell us?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib