Subject: comments on the entity-mib version 2 draft

From: Cliff Sojourner <[email-masked]>
Date: Sat, 14 Nov 1998 13:34:41 -0800

Hi entity-mib folks,

following are my comments on the entity-mib version 2 draft 

(http://www.ietf.org/internet-drafts/draft-ietf-entmib-v2-01.txt)

In general I believe this draft is a significant improvement over RFC
2037.

issues:

E1: put the asset information in a separate table.

("FRU" == Field Replaceable Unit, a customer-indivisible assembly.  FRUs
are usually customer replaceable but sometimes are not.)

the FRU asset objects do not belong in the entPhysicalTable.  There is
not a 

1-1 relationship between FRUs and physical entities.  Only a FRU will
have 

asset information, the FRU components will not.  let's not bother with 

zero-length string objects, let's just put the asset information in a
separate 

table.

E2: differentiate between "orderable part number" and "manufacturing
assembly 

number".

from the entPhysicalModelName DESCRIPTION, I believe this object is the 

customer-visible part number, the number the customer would use to order
a new 

FRU.

However, functionally equivalent FRUs might be assembled from completely 

different parts.  This is commonly encountered in second-source parts,
but is 

also seen, for example, in cost-reduced redesigns.

Field support personnell, asset/inventory/spares management
applications, FRU 

embedded software, and vendor's software upgrade management applications
need 

to know the manufacturing assembly number of the FRU components.

This has been the case at every hardware vendor I've seen.  If you
disagree 

then please talk with your field support, software image management,
software 

developers, and manufacturing staff.

Let's do this:
 
1.  add a DisplayString object to represent the manufacturing assembly
number

2.  revise the entPhysicalModelName DESCRIPTION to be clear that it is
the 

orderable part number for the FRU assembly

3.  revise the entPhysicalMfgName DESCRIPTION to be clear that the other
asset 

objects (sw/fw/hw revision, serial number, orderable part number, mfg
ass'y 

number) only make sense in the context of that manufacturer.

in other words, don't compare or collate these objects when they are
from 

different manufacturers.

this way, we can support mixed-OEM FRUs in a deployed device.

E3: entPhysicalTable has no way to represent double-high modules

unfortunately the entity contains/contained-by relationship does not
have a 

mechanism to represent one FRU that occupies two containers.  For
example, 

there is no way to show that one double-high module occupies two slots
in the 

chassis.

I don't have a proposal, but I wanted to raise the issue.  has this
already 

been discussed?

E4: implementation of user-writeable objects is problemmatic

entPhysicalAlias should be removed.  This object correctly lies in the 

asset/spares/inventory management application.  Existing such
applications 

include this functionality, keyed off FRU serial-number.

implementing write access to this object is not reliable:  the FRU may
not 

have any non-volatile memory to store the alias.  So, the written value
can 

not follow the FRU through removal, return to inventory, re-installation
in a 

new system, etc.

Since it is not reliable the NMS will not use this capability at all. 
It's 

true, ask your NMS guys if they will support a features that sometimes
works.  

they won't.

This is why applications keep the alias with the inventory database.

same comments apply for entPhysicalAssetID.  Nice idea but not really 

deployable.

E5: specify the MIBs that are expected to populate logical entries

the draft says:

    There is a need for a standardized way of representing a single
agent
    which supports multiple instances of one MIB.  This is presently
true
    for at least 3 standard MIBs, and is likely to become true for more
and
    more MIBs as time passes.

let's make it explicit what RFC MIBs should populate the logical-table. 
Can 

we make a conformance/compliance for this too?

E6:  make entPhysicalIndex MAX-ACCESS accessible-for-notify

recently we wrote a MIB with a notification, one of the varbinds was 

entPhysicalIndex.  We wanted to signal a change in operational state for
a 

particular entity and entPhysicalIndex is the correct object to indicate
that.

however, we could not generate the notification because entPhysicalIndex 

MAX-ACCESS is not-accessable.  There is no OID so the SNMP agent could
never 

get the value or put it in the notification.

(Interestingly three MIB compilers accepted "not-accessible"
notification 

objects!)

let's change entPhysicalIndex MAX-ACCESS to accessible-for-notify so
that we 

can use it for notification varbind.

nits on the draft:

E7: define "FRU" early in the draft and use the term, then MIB object 

descriptions won't have circumlocutions like "Physical entities which
are
permanently 'contained in' another physical entity (e.g.,
the repeater ports within a repeater module)"  bleah!

E8:  4.10 says "Most of the MIB objects defined in this MIB have at most
a 

read-only MAX-ACCESS clause, i.e., none are write-able."  Yet there are
two 

read-write objects in this draft.

E9: typos in section 6.1, remaining from RFC 2037:
...
    2 logical bridges:
      entLogicalDescr.3 ==            "Acme Bridge v2.1.1"
      entLogicalType.3  ==            dod1dBridge

==> dot1dBridge

      entLogicalCommunity.3 ==        "public-bridge1"
      entLogicalTAddress.3 ==         124.125.126.127:161
      entLogicalTDomain.3 ==          snmpUDPDomain

      entLogicalDescr.4 ==            "Acme Bridge v2.1.1"
      entLogicalType.4 ==             dod1dBridge

==> dot1dBridge

      entLogicalCommunity.4 ==        "public-bridge2"
      entLogicalTAddress.4 ==         124.125.126.127:161
      entLogicalTDomain.4 ==          snmpUDPDomain
...

E10:  SnmpAdminString size range semantics unclear

this is really an SNMPv3 wg issue, but:  several entity-mib objects are
SYNTAX 

SnmpAdminString (SIZE(0..something)).  It is not clear from the object 

DESCRIPTION, nor from SnmpAdminString's DESCRIPTION, whether the
"something" 

indicates the maximum number of OCTETs, or the number of characters.  In
a 

multibyte character set, these are different things.

For simplicity I suggest "something"  == OCTETs. 

thanks,
Cliff
-- 
Cliff Sojourner, Cisco Systems Inc.  [email-masked] 
(408) 527-7637   170 W. Tasman Drive, SJ CA 95134

---

From: Andy Bierman <[email-masked]>
Date: Sat, 14 Nov 1998 23:11:18 -0800

Hi Cliff,

I reformatted your mail by hand, since your mailer didn't
do such a great job at line breaks...

> In general I believe this draft is a significant improvement 
> over RFC 2037.
> 
> issues:
> 
> ("FRU" == Field Replaceable Unit, a customer-indivisible assembly.  
> FRUs are usually customer replaceable but sometimes are not.)
> 
> the FRU asset objects do not belong in the entPhysicalTable.  
> There is not a 1-1 relationship between FRUs and physical entities.  
> Only a FRU will have asset information, the FRU components will not.  
> let's not bother with zero-length string objects, let's just put 
> the asset information in a separate table.

I don't object to creating a separate 'SPARSE-AUGMENTS' type of table.
It would be better than zero-length strings.  The WG would
have to approve such a change.

The WG discussed this "FRU support" issue as far back as
the earliest drafts.  I originally had a r/o TruthValue
for 'entPhysicalIsFieldReplaceable' because I knew this 
important subset would come up again. 

But the WG didn't agree on what field-replaceable really is,
since not all 'containers' are field-serviceable, and
serviced by the customer or a technician?  It was a rathole.
So FRU is not mentioned.

> assembly number". 
> a new FRU.

There are those who feel there are already too many strings
to NV-save in this MIB. I think the customer visible model name
or model number is what most vendors will put here.  
I don't think an additional string for mfg assembly number
is needed. The entPhysicalHardwareRev object should be
good enough to identify the vendor's ID for the part.

> but is also seen, for example, in cost-reduced redesigns.
> 
> applications, FRU embedded software, and vendor's software 
> upgrade management applications need to know the manufacturing 
> assembly number of the FRU components.
> 
> disagree then please talk with your field support, software image 
> management, software developers, and manufacturing staff.

I think there are enough strings in the entPhysicalTable
already, and a vendor can find someplace to put enough
info to identify a physical part.  The WG will have to
debate this one I guess.

> 1.  add a DisplayString object to represent the manufacturing assembly

I'd rather not.

> the orderable part number for the FRU assembly

I don't want to make that restriction. A vendor may want
to put both numbers in this string, and they may change
their part numbers sometime after a part is released,
so the "reorder #" changes. I think text to say this
object should contain the orderable part number is a good idea.

> asset objects (sw/fw/hw revision, serial number, orderable part number,
> mfg ass'y number) only make sense in the context of that manufacturer.
> 
> from different manufacturers.
> 

okay, good idea

> have a mechanism to represent one FRU that occupies two containers.  
> For example, there is no way to show that one double-high module 
> occupies two slots in the chassis.
> 
> already been discussed?

I don't know either. Keith and I came up with 'containedIn'
as a compromise to all the failed indexing schemes that had
been discussed.  I'd like to support this feature, because
'double-wide' modules are showing up more often.

Here is a hack proposal; add this text to the entPhysicalContainedIn
DESCRIPTION clause:

  For entPhysicalEntities which occupy more than one container,
  the entPhysicalContainedIn object shall contain the 
  entPhysicalIndex value of the lowest-numbered container
  entity, occupied by the contained entity.  The associated
  entPhysicalContainsTable shall have entries for all the
  container/contained relationships for such a physical entity.

This hack allows an NMS to see that a container is occupied,
and find all the containers used for these special cards.
 
> applications include this functionality, keyed off FRU serial-number.
> not have any non-volatile memory to store the alias.  So, the written 
> value can not follow the FRU through removal, return to inventory, 
> re-installation in a new system, etc.
> 
> It's true, ask your NMS guys if they will support a features that 
> sometimes works. they won't.
> 

I can argue that the NMS can keep the mfg part number in that
database as well. :-)

I think the writable strings are useful in some cases.  
Note that entPhysicalAlias is only mandatory for 
the 'chassis' component itself. This is useful for topology 
correlation purposes.

> same comments apply for entPhysicalAssetID.  Nice idea but not really

This is a compromise area.  There needs to be flexibility on
how such strings are supported by all vendors.  It is expected
that a vendor will set this at compile-time or load-time,
and implement these strings as read-only.  

It is expected that only implementations which with non-volatile
storage will implement read-write access. Vendors  without NV
and don't know the info won't implement this at all.
Some vendors wanted the ability to 'plug-in' the asset ID
manually, in case the agent didn't know it.  

I don't think either of these strings should be removed.

>     agent which supports multiple instances of one MIB.  This is 
>     presently true for at least 3 standard MIBs, and is likely to 
>     become true for more and more MIBs as time passes.
> 

I strongly disagree.
The criteria for implementation of the entLogicalTable
is very clear.  The ENTMIB WG does not need to track down
every MIB that should use this table. 

> entPhysicalIndex.  We wanted to signal a change in operational state 
> for a particular entity and entPhysicalIndex is the correct object to 
> indicate that.
> 
> never get the value or put it in the notification.
> 
> (Interestingly three MIB compilers accepted "not-accessible" notification
> objects!)
> 
> that we can use it for notification varbind.
> 

I don't really object to this change, but it isn't entirely useful.
It's not that hard to simply include any one of the readable
objects (like entPhysicalClass) and the entPhysicalIndex will
be known.  But I don't mind making this change.

> are permanently 'contained in' another physical entity (e.g.,

as stated above, FRU was a rathole.
The WG didn't want to couple a vendor's notion of a FRU
with the 'container' entPhysicalClass value.  Not all containers
are FRUs. Not all vendors have one level of FRU. 

I don't mind defining FRU in very broad terms, and using that
throughout the text.

> a read-only MAX-ACCESS clause, i.e., none are write-able."  Yet there are
> two read-write objects in this draft.

the next sentence says that, but I will fix the first sentence.
It was leftover from RFC 2037.

>       entLogicalTDomain.4 ==          snmpUDPDomain

thanks

> SYNTAX SnmpAdminString (SIZE(0..something)).  It is not clear from the 
> object DESCRIPTION, nor from SnmpAdminString's DESCRIPTION, whether the
> "something" indicates the maximum number of OCTETs, or the number of
> characters.  In a multibyte character set, these are different things.
> 

It is defined as OCTETS somewhere in RFC 227x, but I could 
add a note to the Entity MIB.

> Cliff

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 16 Nov 1998 11:51:05 -0800

Hi -

> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, 14 November, 1998 13:35
> To: [email-masked]
> Subject: comments on the entity-mib version 2 draft
...
...

Any suggestions as to how the current RFC 2271 text might be made
clearer?

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked] http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

---

From: Cliff Sojourner <[email-masked]>
Date: Mon, 23 Nov 1998 15:46:45 -0800

Hi Andy, 

thanks for your response.  there's been very little comment about most
of these.  I am going to dig in my heels a bit and really insist on a
few things, in particular E1 and E2.

> do such a great job at line breaks...

thanks Andy and apologies to all for mangled mailing.

> Cliff Sojourner wrote:
...
> have to approve such a change.

yes, let's do it this way.  WG, please approve this change.

...
> good enough to identify the vendor's ID for the part.

last week I presented the Entity-MIB v2 draft to a large group of
Cisco's NMS developers.  Several of the apps people and managers
emphasized the importance of the distinction between the
customer-visible orderable part number, and the manufacturing assembly
number, and the engineering revision.  

Also, people really don't want to parse strings like
entPhysicalHardwareRev looking for the manufacturing assembly number,
and the engineering revision - we want separate objects.

I know you think "there are enough strings already" but these things
have separate semantics so they really deserve separate objects.

...
> > 1.  add a DisplayString object to represent the manufacturing assembly

I'd like to.  anyone else?

> object should contain the orderable part number is a good idea.

OK, great, please update the draft.

> > this way, we can support mixed-OEM FRUs in a deployed device.

OK, great, please update the draft.

...
> and find all the containers used for these special cards.

OK, great, please update the draft.

> I can argue that the NMS can keep the mfg part number in that

you could argue that but you would be wrong.  as I noted previously the
manufacturing assembly number is often different for equivalent
orderable part numbers.  so, the NMS can never determine the correct mfg
ass'y number from the OPN.

> the 'chassis' component itself. This is useful for topology

seems like a reasonable guideline.  

> I don't think either of these strings should be removed.

OK, I agree.

...
> every MIB that should use this table.

I'm not suggesting tracking down every MIB, but the base set of MIBs
that ought to populate this table is well known:  bridge-mib, ospf-mib,
etc.  Can we document that as a suggested set of logical entities?

...
> be known.  But I don't mind making this change.

my feeling is that sometimes the other readable objects do not have the
intended semantic.  using an inappropriate object in a tangential
fashion (for example, for the side-effect of its index) is a wart for
MIB designers and a distraction to MIB implementers and users.

> 
> > nits on the draft:
> >
> > E7: define "FRU" early in the draft ...

> as stated above, FRU was a rathole.

OK, after your explanation I understand.  since this is a nit let's skip
it.

I deleted E8-E9 since you indicated you updated the draft.  E10 went to
SNMPv3 WG.

regards,
Cliff
-- 
Cliff Sojourner, Cisco Systems Inc.  [email-masked] 
(408) 527-7637   170 W. Tasman Drive, SJ CA 95134  bldg H2/cube E2-7
plus ca change, plus c'est le meme chose