Subject: [Entmib] WG Last Call: Entity MIB for Draft Standard

From: Margaret Wasserman <[email-masked]>
Date: Tue, 22 Jul 2003 09:24:16 -0400

This is an Entity MIB working group last call for comments on advancing the 
following
document as a Draft Standard:

Title :         Entity MIB (Version 3)
Author(s) :     K. McCloghrie, A. Bierman
Filename :      draft-ietf-entmib-v3-01.txt
Date :  May 2003

The document can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-entmib-v3-01.txt

Please send substantive comments to the entmib mailing list, and minor 
editorial
comments to the authors. This last call period will end on August 5th, 2003.

Margaret Wasserman
Entity MIB WG Chair

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

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 22 Jul 2003 14:59:01 -0700 (PDT)

On Tue, 22 Jul 2003 Margaret Wasserman forwarded the following
message to the [email-masked] list:
> This is an Entity MIB working group last call for comments on
> advancing the following document as a Draft Standard:
> 
> Please send substantive comments to the entmib mailing list, and
> minor editorial comments to the authors. This last call period
> will end on August 5th, 2003.

There may be a problem in advancing this document to Draft Standard
since it contains a new TC -- PhysicalIndexOrZero -- which has not
been used in any object definition.  I suppose that this is open
to interpretation, but in the AToM MIB WG we assumed for the purposes
of advancing RFC 2493 (which contains only TCs) that we'd have to
provide evidence that each TC had been used in defining at least
one object that was implemented by two vendors.  For details see:
http://www.ietf.org/IESG/Implementations/RFC2493-Implementation.txt

In the case of PhysicalIndexOrZero the problem of not being used in
any object definitions (if it is a problem) can be easily overcome
by changing

entPhysicalContainedIn OBJECT-TYPE
    SYNTAX      Integer32 (0..2147483647)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The value of entPhysicalIndex for the physical entity which
            'contains' this physical entity.  A value of zero indicates
            this physical entity is not contained in any other physical
            entity.  Note that the set of 'containment' relationships
            define a strict hierarchy; that is, recursion is not
            allowed.

            In the event a physical entity is contained by more than one
            physical entity (e.g., double-wide modules), this object
            should identify the containing entity with the lowest value
            of entPhysicalIndex."
    ::= { entPhysicalEntry 4 }

to:

entPhysicalContainedIn OBJECT-TYPE
    SYNTAX      PhysicalIndexOrZero
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The value of entPhysicalIndex for the physical entity which
            'contains' this physical entity.  A value of zero indicates
            this physical entity is not contained in any other physical
            entity.  Note that the set of 'containment' relationships
            define a strict hierarchy; that is, recursion is not
            allowed.

            In the event a physical entity is contained by more than one
            physical entity (e.g., double-wide modules), this object
            should identify the containing entity with the lowest value
            of entPhysicalIndex."
    ::= { entPhysicalEntry 4 }

as suggested some time ago by Juergen Schoenwaelder.  In my opinion
this is a very good idea on its own merits, irrespective of the process
question I have raised, and I strongly urge the WG to consider making
this change before submitting the document to the IESG.  (Indeed,
PhysicalIndexOrZero seems to be made exactly for objects such as
entPhysicalContainedIn, and in a MIB doctor review I would ask why
it was not used.)

If the WG agrees to make this change, then the following additional
changes (or something like them) would also be needed:

OLD:
EntPhysicalEntry ::= SEQUENCE {
      ...
      entPhysicalContainedIn    Integer32,
      ...
}

NEW:
EntPhysicalEntry ::= SEQUENCE {
      ...
      entPhysicalContainedIn    PhysicalIndexOrZero,
      ...
}

OLD:
4.15.3.  Bugfixes
     
The syntax was changed from INTEGER to Integer32 for the
entPhysicalContainedIn, entPhysicalParentRelPos, entLogicalIndex, and
entAliasLogicalIndexOrZero objects.

NEW:
4.15.3.  Bugfixes
     
The syntax was changed from INTEGER to Integer32 for the
entPhysicalParentRelPos, entLogicalIndex, and
entAliasLogicalIndexOrZero objects, and from INTEGER to
PhysicalIndexOrZero for the entPhysicalContainedIn object.

Best regards,

Mike Heard

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jul 2003 15:05:35 -0700

At 02:59 PM 7/22/2003, C. M. Heard wrote:

I agree with these changes.  

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Jul 2003 15:05:35 -0700

Andy

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 23 Jul 2003 23:00:07 +0200

Pls add a line to the abstract that indicates that this
document obsoletes RFC2737.

Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 23 Jul 2003 23:00:07 +0200

Thanks,
Bert