Subject: [Entmib] Entity MIB v3

From: Andy Bierman <[email-masked]>
Date: Thu, 04 Nov 2004 11:34:33 -0800

Hi,

It doesn't make sense to me to undo one deprecated table
but not the other one.  The entLPMappingTable was deprecated 
so we could advance to Draft Standard.  Since we are cycling 
at Proposed instead of advancing to Draft, there is no reason 
to deprecate this table.

I will post an update (w/o the IPR goof) after the IETF. 
I would like to un-deprecate the entLPMappingTable as well.

Also, I need examples for the entPhysicalUris object.
This object is too vague for me to provide any examples.
I also see no guidance for which types of physical
entities should provide a mfg date.  FRUs only?
More text is needed for both of these new objects.

thanks,
Andy

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Nov 2004 21:41:15 -0500

Hi Andy,

>I would like to un-deprecate the entLPMappingTable as well.

This makes sense to me.  Does anyone have an objection to this plan?

>More text is needed for both of these new objects.

Could one of the people who felt strongly that these objects should 
be included in the Entity MIB update please respond to Andy's request 
for more information?

If there is no one who care enough about these objects to do actual 
work to finalize them, perhaps Andy should just leave them out and we 
can get the Entity MIB update published?

Margaret

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Nov 2004 12:24:09 +0100

> be included in the Entity MIB update please respond to Andy's request 

I suggest to add language to entPhysicalMfgDate which says that there
is a default value in case the manufacturing date is unknown: 

	The value '0000000000000000'H is returned if the manufacturing
	date of the entity in unknown.

I don't think we need to constrain this object to FRUs. 

Regarding entPhysicalUris: This object was proposed to handle CLIE
codes and other things people may come up with to identify entities.
It would be nice if Kaj Tesink <[email-masked]> could
start an ID which defines a URI namespace for CLIE codes. While
this might take some time and we do not want to depend on it, 
another source of examples might be OID URNs as defined in RFC 
3001, that is something like urn:oid:1.3.6.1.4.1 (I leave it to
your imagination to pick a suitable value for an example).
 
> can get the Entity MIB update published?

I would love to see Kaj starting to write up the CLIE code URN spec
since this was the major driving force for this addition. I this
does not happen, then dropping these objects (even though I believe
we now have a viable solution) might be a logical conclusion.

/js

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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 30 Nov 2004 08:09:56 -0500

>I don't think we need to constrain this object to FRUs.

This seems reasonable to me.

>we now have a viable solution) might be a logical conclusion.

The Entity MIB update has been hanging out in various nebulous states 
quite literally for _years_.  This WG has reached a level of 
delay/inaction that is appalling (for which I accept some of the 
blame), we seem to placing theory above practice, and we have a 
penchant for finding new rat-holes...

Some symptoms of our current disease include:

- We have continuously had 4-7 issues open with the Entity State MIB 
for over a year.  We agreed to the resolution of all 7 outstanding 
issues in August, only to open 4 or 5 more when we tried to do a 
final check that those 7 had been address correctly.  When does this 
stop?  Is there anyone who actually wants to see this MIB get 
published (besides me and Sharon)?  Is anyone implementing it?   What 
is the driver to finish this work?

- We added deprecated objects back into the Entity MIB, preventing it 
from going to DS, because those objects are purported to be essential 
to the SNMP information model.  But, as far as we can tell, NO ONE 
HAS _EVER_ IMPLEMENTED THOSE OBJECTS!!  How essential could they 
really be if they don't actually exist in the real world?

- Accepting the consensus of the group, Andy agreed to produce a new 
version of the Entity MIB with the objects un-deprecated that could 
recycle at PS.  Then, people decided that we should add a new set of 
objects to the MIB.  Several people spoke out that these objects were 
important to add, but no one responded for almost a month when Andy 
asked for help defining the objects, not even the person who first 
proposed them.

What am I supposed to do?  Bert periodically threatens to shut the 
group down because we aren't making progress, and I keep putting him 
off because we are one or two months away from completion.  How long 
can this go on?  Should I just say "okay" next time he asks?

I do understand the desire to add this feature to the MIB, but I 
think that we are suffering from terminal mission creep. AFAICT, 
there is no reason not to publish an update to the Entity MIB now 
(without the new, poorly specified objects) and to later publish an 
extension and/or an update that adds these objects if/when anyone 
cares enough to actually do the work.

What do others think?

Margaret

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Nov 2004 14:44:21 +0100

On Tue, Nov 30, 2004 at 08:09:56AM -0500, Margaret Wasserman wrote:

> AFAICT, there is no reason not to publish an update to the Entity MIB now 

I do not agree that these two objects are poorly specified. Your
mileage obviously varies. 

Procedurally, I suggest to start a last call on this document - if 
Andy wants to undeprecate some more stuff, ask him to post a revised 
document in a week and start a last call on that version. Simply put,
set clear deadlines and make sure any followup work is done on time. 

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Nov 2004 06:37:29 -0800

>This seems reasonable to me.

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.

>The Entity MIB update has been hanging out in various nebulous states quite literally for _years_.  This WG has reached a level of delay/inaction that is appalling (for which I accept some of the blame), we seem to placing theory above practice, and we have a penchant for finding new rat-holes...
>
>- We have continuously had 4-7 issues open with the Entity State MIB for over a year.  We agreed to the resolution of all 7 outstanding issues in August, only to open 4 or 5 more when we tried to do a final check that those 7 had been address correctly.  When does this stop?  Is there anyone who actually wants to see this MIB get published (besides me and Sharon)?  Is anyone implementing it?   What is the driver to finish this work?
>
>- We added deprecated objects back into the Entity MIB, preventing it from going to DS, because those objects are purported to be essential to the SNMP information model.  But, as far as we can tell, NO ONE HAS _EVER_ IMPLEMENTED THOSE OBJECTS!!  How essential could they really be if they don't actually exist in the real world?

Cisco has multiple independent implementations of the deprecated objects, 
but I'm not sure that counts as more than one implementation.

>- Accepting the consensus of the group, Andy agreed to produce a new version of the Entity MIB with the objects un-deprecated that could recycle at PS.  Then, people decided that we should add a new set of objects to the MIB.  Several people spoke out that these objects were important to add, but no one responded for almost a month when Andy asked for help defining the objects, not even the person who first proposed them.
>
>What am I supposed to do?  Bert periodically threatens to shut the group down because we aren't making progress, and I keep putting him off because we are one or two months away from completion.  How long can this go on?  Should I just say "okay" next time he asks?
>
>I do understand the desire to add this feature to the MIB, but I think that we are suffering from terminal mission creep. AFAICT, there is no reason not to publish an update to the Entity MIB now (without the new, poorly specified objects) and to later publish an extension and/or an update that adds these objects if/when anyone cares enough to actually do the work.

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.
There is no multi-vendor interoperability possible with the
entPhysicalUris object as currently defined.  

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Nov 2004 16:05:08 +0100

>             field  octets  contents                  range

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.
 
> There is no way to provide a N/A value for entPhysicalMfgDate.

See above.

> 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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 30 Nov 2004 07:41:05 -0800

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

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

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

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Nov 2004 17:21:40 +0100

> Field 8 is supposed to contain a '+' or '-' char, not 0x00.

The UTC offset if option. Please count the zeros - in case I did
submit too many, I apologize and leave it to you to remove some. ;-)
 
> naming collisions are avoided with the entPhysicalUris object.

There is a URI registry in place. IANA manages this like usual.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 30 Nov 2004 11:37:31 -0500

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-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Tuesday, November 30, 2004 10:41 AM
> To: [email-masked]
> Cc: Margaret Wasserman; [email-masked]; [email-masked]
> Subject: Re: [Entmib] Entity MIB v3
> 

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Nov 2004 19:58:03 +0100

> URI is not a normal SNMP construct.

I read this as an argument in favor of the entPhysicalUris addition.
 
> usefulness of this object to a vendor-neutral application is

Please someone explain to me the namespace conflict you are seeing.
 
> entity mib table. Hopefully, they will also include an object to

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

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 30 Nov 2004 16:08:36 -0500

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

> From: Juergen Schoenwaelder [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, November 30, 2004 1:58 PM
> To: David B Harrington
> Cc: 'Andy Bierman'; 'Margaret Wasserman'; [email-masked]; 
> [email-masked]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Nov 2004 22:48:31 +0100

On Tue, Nov 30, 2004 at 04:08:36PM -0500, David B Harrington wrote:

[...]
 
> justified or specified to be included in the entity mib; we should

Now this is a clear statement. I do not agree but that is fine.
It is now time for others to speak up and if I am the clear minority
here because nobody cares, then go ahead and nuke the definition.

/js