Re: [Hubmib] I-D ACTION:draft-ietf-hubmib-power-ethernet-mib-03.txt

On Tue, 5 Nov 2002 Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.  This draft is a work item of the Ethernet Interfaces
> and Hub MIB Working Group of the IETF.
> 
> 	Title		: Power Ethernet (DTE Power via MDI) MIB
> 	Author(s)	: A. Berger, D. Romascanu
> 	Filename	: draft-ietf-hubmib-power-ethernet-mib-03.txt
> 	Pages		: 28
> 	Date		: 2002-11-4
> 	
> This memo defines a portion of the Management Information Base (MIB)
> for use with network management protocols in the Internet community.
> The document proposes an extension to the Ethernet-like Interfaces
> MIB [RFC2665] with a set of objects for managing a power Ethernet
> Powered Device (PD) and/or Power Source Equipment (PSE).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hubmib-power-ethernet-mib-03.txt

Greetings,

I have some MIB doctor type comments about this draft.  Most of
them are things that I either did not catch in the -02 draft or
else did not adequately explain in my comments on the -02 draft.
My apologies for that.

1.)  There is no REVISION clause in the MODULE-IDENTITY
statement.  I suggest that something along the lines of

       REVISION    "200210190000Z"  -- October 19, 2002
       DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this notice

be added in the next revision (with an appropriately updated date).

2.)  The MIB is registered as { dot3 20 }.  Although this subtree does
not seem to be assigned (assignments under dot3 in the EtherLike-MIB
go up to { dot3 11 }), it seems dangerous to me to register the MIB
under the dot3 tree unless we also note this fact in the EtherLike-MIB
itself.  That's because it's possible that a future maintainer of
that module might accidentally cause a collision.  Perhaps it would
be better to follow the usual practice of registering the module under
mib-2 and let IANA assign the number.  The changes to effect this would
be to add mib-2 to the IMPORTS statement and remove dot3 and to replace
the line

           ::= { dot3 20 }

with something along the lines of

       ::= { mib-2 XXX }
-- RFC Ed.: replace XXX with IANA-assigned number & remove this notice

Note that there is precedent for this:  the MAU-MIB is registered
directly under mib-2 and  not under dot3.

3.)  smilint-0.4.0 still complains about a lot of stuff:

% libsmi-0.4.0/tools/smilint -l 9 -s ./POWER-ETHERNET-MIB |& grep -v 'name .* longer than 32 characters$'
./POWER-ETHERNET-MIB:114: [6] use Integer32 instead of INTEGER in SMIv2
./POWER-ETHERNET-MIB:128: [6] use Integer32 instead of INTEGER in SMIv2
./POWER-ETHERNET-MIB:364: [6] use Integer32 instead of INTEGER in SMIv2
./POWER-ETHERNET-MIB:440: [6] use Integer32 instead of INTEGER in SMIv2
./POWER-ETHERNET-MIB:504: [6] use Integer32 instead of INTEGER in SMIv2
./POWER-ETHERNET-MIB:516: [6] use Integer32 instead of INTEGER in SMIv2
./POWER-ETHERNET-MIB:554: [6] use Integer32 instead of INTEGER in SMIv2
./POWER-ETHERNET-MIB:582: [5] notification `pethPsePortOnOffNotification' is not reverse mappable
./POWER-ETHERNET-MIB:593: [5] notification `pethPsePortPowerMaintenanceStatusNotification' is not reverse mappable
./POWER-ETHERNET-MIB:601: [5] notification `pethMainPseBackUpActivatedNotification' is not reverse mappable
./POWER-ETHERNET-MIB:609: [5] notification `pethMainPowerUsageOnNotification' is not reverse mappable
./POWER-ETHERNET-MIB:617: [5] notification `pethMainPowerUsageOffNotification' is not reverse mappable
./POWER-ETHERNET-MIB:728: [6] current group `pethPsePortNotificationGroup' is unconditionally optional
./POWER-ETHERNET-MIB:735: [6] current group `pethMainPowerNotificationGroup' is unconditionally optional

Suggested fixes are as follows:

line 114:  change the syntax of pethPsePortGroupIndex from
INTEGER (1..2147483647) to Integer32 (1..2147483647).

line 128:  change the syntax of pethPsePortIndex from
INTEGER (1..2147483647) to Integer32 (1..2147483647).
[If it is intended to represent an ifIndex value, use
InterfaceIndex instead and modify the description.]

line 364:  change the syntax of pethPdPortIndex from
INTEGER (0..65535) to InterfaceIndex.  Be sure to
import InterfaceIndex from IF-MIB.

line 440:  change the syntax of pethMainPseGroupIndex
from INTEGER (0..65535) either to Integer32 (1..2147483647),
if it is supposed to have the same value range as
pethPsePortGroupIndex, or to Integer32 (1..65535), if you
really meant for it to be limited to 16 bits.

line 504:  change the syntax of pethMainPseUsageThreshold
from INTEGER (1..99) to Integer32 (1..99).

line 516:  change the syntax of pethMainPseMaximumDcPower
from INTEGER to Gauge32, to be consistent with the
usage in the definition of pethMainPseConsumptionPower.

line 554:  change the syntax of  pethNotificationControlGroupIndex
from INTEGER (1..65535) either to Integer32 (1..2147483647),
if it is supposed to have the same value range as
pethPsePortGroupIndex, or to Integer32 (1..65535), if you
really meant for it to be limited to 16 bits.

lines 582, 593, 601, 609, 617:  the problem here is that
the OIDs assigned to the notifications do not have a
next-to-last sub-OID of zero, and as a result passing
them through a V2-to-V1 translator (proxy) and then
back through a V1-to-V2 translator (proxy) won't get
the original notification back.  One trivial way to fix
this problem is to reassign the top-level OIDs as follows:

***************
*** 56,58 ****
!    pethObjects       OBJECT IDENTIFIER ::= { powerEthernetMIB 1 }
!    pethNotifications OBJECT IDENTIFIER ::= { powerEthernetMIB 2 }
!    pethConformance   OBJECT IDENTIFIER ::= { powerEthernetMIB 3 }
--- 56,58 ----
!    pethNotifications OBJECT IDENTIFIER ::= { powerEthernetMIB 0 }
!    pethObjects       OBJECT IDENTIFIER ::= { powerEthernetMIB 1 }
!    pethConformance   OBJECT IDENTIFIER ::= { powerEthernetMIB 2 }

Another way, which is used in many MIB modules, would be to do this:

        pethNotificationPrefix OBJECT IDENTIFIER ::= { pethNotifications 0 }

        pethPsePortOnOffNotification NOTIFICATION-TYPE
            OBJECTS     { pethPsePortDetectionStatus }
            STATUS      current
            DESCRIPTION
                    " This Notification indicates if Pse Port is  delivering  or
                       not power to the PD. This Notification SHOULD be sent on
                       every status change except in the searching mode."
             ::= { pethNotificationPrefix 1 }

with the other notification definitions similarly modified.

lines 728 and 735:  for each of these groups, either add an
appropriate GROUP clause whose DESCRIPTION states when that
group MUST or SHOULD be implemented (or that it is optional but
implementation is encouraged) or else add it to the appropriate
MANDATORY-GROUPS list(s).

(4) pethMainPsePower has a syntax of Integer32 (1..65535),
which should be changed to Gauge32 in order to be
consistent with pethMainPseConsumptionPower.

All of these things are sure to be brought up during MIB doctor
review if they are not addressed before then.

Regards,

Mike

_______________________________________________
Hubmib mailing list
Hubmib@ietf.org
https://www1.ietf.org/mailman/listinfo/hubmib