RE: [dhcwg] WG last call for "Dynamic Host Configuration Protocol (DHCP) Server MIB" (reminder)

["Woundy, Richard" <[e-mail]>]

Here are some MIB-related comments on draft-ietf-dhc-server-mib-06.txt.

I am willing to work with the draft authors to address these issues. While I
am not a MIB doctor, I have had a little previous experience with getting a
MIB published by the IETF in the last few years.

1. This draft needs to conform to the boilerplate for IETF MIBs,
<http://www.ops.ietf.org/mib-boilerplate.html>. Note that the boilerplate
includes a mandatory SNMP Management Framework section and mandatory
References items.

2. This draft needs an updated Security Considerations section, to conform
with the Security Guidelines for IETF MIBs
<http://www.ops.ietf.org/security.html>. It looks like this section text did
conform to these guidelines when the MIB included read-write/read-create
objects, but since all objects have been redefined to be read-only, the
boilerplate text is not quite correct.

3. The MIB doctor is likely to insist that this MIB avoid the use of the
"DisplayString" SYNTAX (e.g. "DhcpLabel" and "serverSystemDescr"). They
recommend the use of the "SnmpAdminString" SYNTAX as defined in RFC 2571.

4. The MIB doctor will likely strongly urge that this MIB avoid the use of
the "IpAddress" SYNTAX (e.g. "serverSubnet" and "serverSubnetMask"). They
recommend the use of the "InetAddress" and "InetAddressType" SYNTAX as
defined in RFC 3291 (which obsoletes RFC 2851). Note that the textual
conventions in RFC 3291 apply even to MIBs with IPv4 specific tables, such
as this MIB. You should consider using the new "InetAddressPrefixLength"
SYNTAX for the subnet mask objects (e.g. "serverSubnetMask" and
"serverRangeSubnetMask"). You should add new objects with the
InetAddressType syntax that provide context for the InetAddress objects --
note that this activity will impact the indexing of several tables, e.g.
serverSubnetTable and serverRangeTable. Finally, you should add compliance
statements to clarify that the IP address objects in this MIB are expected
only to be IPv4 addresses; for example:

   somethingCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement of the something MIB."

       MODULE      -- this module
       MANDATORY-GROUPS    { somethingGroup }

       OBJECT somethingAddressType
       SYNTAX InetAddressType { ipv4(1) }
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

       OBJECT somethingAddress
       SYNTAX InetAddress (SIZE(4))
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

       ::= { somewhere 2 }

5. The MIB doctor is likely to insist that this MIB include DHC working
group information in the CONTACT-INFO clause in the MODULE-IDENTITY: working
group mailing list information, how to subscribe, where the archives are
kept, working group chair, and his contact information. In the case of this
MIB, you might add this text:

                IETF DHC Working Group
                General Discussion: [e-mail]
                Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg
                Archive: http://www1.ietf.org/mailman/listinfo/dhcwg
                Chair: Ralph Droms, [e-mail]

6. The MIB doctor is likely to insist that this MIB include a REVISION
clause, which is defined in RFC 2578. For example:

  REVISION "200202141126Z"  -- use same timestamp as LAST-UPDATED; I assume
GMT ("Z")
  DESCRIPTION "Initial Version, published as RFC xxxx."
                            -- RFC Editor assigns xxxx

On a related note, the timestamp in the LAST-UPDATED clause of the current
MIB draft needs to be put into the correct format (as above); see RFC 2578.

7. There are unexplained gaps in the OID numbering of objects in this MIB.
In particular, the MIB numbering skips from dhcpCountLeaseQueries, {
dhcpCounters 6 }, to dhcpCountOffers, { dhcpCounters 11 }. Are there objects
with these OIDs that have been previously implemented but dropped from this
MIB draft? If so, perhaps those objects should be added back to the MIB with
an obsolete STATUS, to prevent the OIDs from accidental reuse in the future.
Otherwise, you might want to renumber the OIDs again.

Far worse, I see some OID conflicts. In particular, dhcpCountAcks has OID {
dhcpCounters 12 } and dhcpCountNacks has OID { dhcpCounters 13 } -- but
dhcpCountKnowns also has OID { dhcpCounters 12 } and dhcpCountUnknowns also
has OID { dhcpCounters 13 }. Probably the last two objects should have OIDs
{ dhcpCounters 15 } and { dhcpCounters 16 }.

8. Has the MIB been compiled with a (picky) SNMP MIB compiler such as
SMICng?

(Unfortunately, I am still waiting for my present employer to purchase a
SMICng license, for my other IETF-related work. Otherwise I would have
already volunteered.)

9. I think two DHCP Lease Query-related MIB objects need to be added for the
DHCPACTIVE and DHCPUNIMPLEMENTED messages. Note that there are some Lease
Query last-call comments (from Ralph) that should be reflected in this MIB
as well, e.g. if the DHCP message name changes from DHCPKNOWN to
DHCPLEASEKNOWN, then the MIB object name should change from dhcpCountKnowns
to dhcpCountLeaseKnowns. The latest draft is
draft-ietf-dhc-leasequery-03.txt, by the way.

10. Your reference to draft-ietf-dhc-pv4-reconfigure-06.txt should be
updated to RFC 3203. You should also note in the MIB that the value for DHCP
option 53 (DHCP message type) to indicate a DHCPFORCERENEW message is 9.

11. One of my motivations for reviewing this MIB (besides the fact that I
have lots of deployed DHCP servers in support of cable modem services), is
that there are concerted efforts to specify/deploy embedded DHCP servers in
cable modems. The folks at CableLabs have a project called "CableHome",
<http://www.cablelabs.com/cablehome/specifications.html> -- I am hoping the
CDP MIB will leverage this DHCP server MIB in particular. It would be very
helpful if the DHCP Server MIB had some read-create tables, since we would
need mechanisms to configure a few hundred thousand embedded DHCP servers
sometime in the future. If you did add back this capability to the MIB (not
sure if there is time or consensus), perhaps the read-create functions would
be strictly optional in this MIB (via more compliance statements).

-- Rich

-----Original Message-----
From: Ralph Droms [mailto:[e-mail]]
Sent: Monday, July 08, 2002 8:11 AM
To: [e-mail]
Subject: [dhcwg] WG last call for "Dynamic Host Configuration Protocol
(DHCP) Server MIB" (reminder)


Announcing the WG last call for "Dynamic Host Configuration Protocol (DHCP) 
Server MIB", <draft-ietf-dhc-server-mib-06.txt>.  If you have any comments 
about this I-D, please respond to [e-mail], preferably before the DHC 
WG meeting in Yokohama on 7/16.  The last call discussion will close on 
Monday, 7/22/2002.

- Ralph Droms


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg