Re: [Entmib] Entity MIB v3

Andy Bierman <> Tue, 30 November 2004 14:54 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA24297 for <>; Tue, 30 Nov 2004 09:54:03 -0500 (EST)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CZ9Kn-00069T-Ho; Tue, 30 Nov 2004 09:50:30 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1CZ98q-0002Py-QO for; Tue, 30 Nov 2004 09:38:09 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA22318 for <>; Tue, 30 Nov 2004 09:38:06 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.33) id 1CZ9Dx-000534-IZ for; Tue, 30 Nov 2004 09:43:26 -0500
Received: from ( by with ESMTP; 30 Nov 2004 06:37:48 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id iAUEbVtR009176; Tue, 30 Nov 2004 06:37:33 -0800 (PST)
Received: from ( []) by (MOS 3.4.5-GR) with ESMTP id BBL88623; Tue, 30 Nov 2004 06:37:30 -0800 (PST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 30 Nov 2004 06:37:29 -0800
To: Margaret Wasserman <>
From: Andy Bierman <>
Subject: Re: [Entmib] Entity MIB v3
In-Reply-To: <p06200729bdd21d2c5fa4@[]>
References: <20041130112409.GE2823@james> <> <p06200720bdd18dd1c671@[]> <20041130112409.GE2823@james>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

At 05:09 AM 11/30/2004, Margaret Wasserman wrote:
>At 12:24 PM +0100 11/30/04, Juergen Schoenwaelder wrote:
>>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.
>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.

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

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.  

>What do others think?


Entmib mailing list