Subject: [dhcwg] Ad additional reeqview of: DHCPv4 MIB, revision 10

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 17 Mar 2004 16:44:04 +0100

Let me add my comments after a (very) quick scan.
David, I am not intending to step on your toes here, just
trying to help and trying to point out a few more things that
I could quickly spot. May make it easier for authors to
include fixes in next revision.

1.Sect 3.1.1. syasy:
       The DHCP MIBs share a
  Better:
       The DHCP MIB modules share a
  There is ONE MIB that is composed of many MIB modules!
  This may be true for other places in the doc.
 
2.Sect 3.1.2 talks about a Host System Mib with ref to RFC1123???
  RFC1123 does not have a MIB Did you mean RFC1213, which 
  does not contain a Host System Mib, but contains a "systemGroup"
  in the SNMP MIB II. But these days it would be betetr to point
  to RFC3418 SNMPv20MIB that conatins systemGroup)

3.Recently the RFC-Editor has requested notation for IMPORTs as
  follows:
           SnmpAdminString FROM SNMP-FRAMEWORK-MIB    -- [RFC3411]
  So that there are citattions for normative refrences.

4.Things like:
          ::= { mib-2 9999 } -- IANA will make official assignment
  Are VERY BAD.
  Please use:
          ::= { mib-2 nnn } -- IANA please assign xxxx

5.I doubt that the use of OBJECT-IDENTITY is proper here.
  I will check with MIB DOctor team

Thanks,
Bert 

> -----Original Message-----
> From: Harrington, David [mailto:[email-masked]]
> Sent: woensdag 17 maart 2004 15:48
> To: Harrington, David; [email-masked]; [email-masked];
> [email-masked]
> Cc: Wijnen, Bert (Bert); [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: DHCPv4 MIB review - detailed part one
> 
> 
> Hi,
> 
> I'm doing a mib doctor review of the DHCPv4 server mib. This 
> document is
> not ready for advancement, and needs through review by the WG.
> 
> Part I: technical concerns
> 
> Section 3.3 says "there will be differences in the counts reported by
> different servers." The purpose of a standard is to get all
> implementations to report the data the same way, so data can 
> be compared
> reasonably across vendors. We don't want to standardize that
> implementors can count things in whatever non-interoperable 
> manner they
> choose.
> 
> Section 3.3.1 uses MUSTs in a manner that does not seem 
> consistent with
> RFC2119 - [MUST   This word, or the terms "REQUIRED" or "SHALL", mean
> that the definition is an absolute requirement of the 
> specification.] We
> standardize the format and semantics of values that pass on-the-wire
> between an agent and a manager; we do not dictate what a 
> manager must do
> with the data it receives from the agent.
> 
> In the first case, it says "a manager MUST be capable of recognizing
> this case." I would suggest that you tell an implementor HOW to
> recognize this case, without chance of error. I'm not sure it's always
> possible. Even with a method to do so, we should only recommend that a
> manager recognize this case, since we don't know whether this case is
> important to the purpose of the management application. A mibwalk
> application is a type of manager that doesn't even attempt to 
> interpret
> counters; it may start and end without ever getting a counter 
> twice. Why
> MUST it be capable of recognizing a counter discontinuity?
> 
> Section 3.3.1, second case, says "a manager MUST discard 
> data"; I don't
> believe that should be a MUST; it should be a SHOULD. The 
> discontinuity
> between two GETs does not affect on-the-wire 
> interoperability, and thus
> is not an absolute requirement; it only affects subsequent
> interpretation of the values.  We should RECOMMEND that they 
> discard the
> faulty data, but it is an application-implementor decision 
> whether to do
> so, depending on the application needs. Therefore this should 
> only be a
> SHOULD.
> 
> ---
> MODULE IDENTITY - it is good practice to use consistent 
> prefixes for the
> DEFINITIONS ::= BEGIN clause, the MODULE IDENTITY, and the objects in
> the mib. See appendix C in
> http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-
> guidelines
> -02.txt 
> 
> In this MIB, they are inconsistent:
> 
> DHCP-SERVER-MIB DEFINITIONS ::= BEGIN
> dhcp MODULE-IDENTITY
> dhcpv4ServerXXX objects
> 
> These are just guidelines, but I suggest changing DHCP-SERVER-MIB to
> DHCPv4-SERVER-MIB, and I suggest using dhcpv4ServerMIB as the MODULE
> IDENTITY, to improve consistency.
> 
> ---
> bootpXXXX objects - It is good practice (see Naming conventions in the
> guidelines document) to prefix all objects in the mib with the same
> prefix used in the module identity. This helps others not 
> create objects
> with conflicting names. Have you considered having two mib modules in
> this document - one small one for bootp objects and the other for
> dhcpv4Server objects? Can bootp ever be used without dhcpv4Server? If
> so, they probably should be independent mib modules. If not, 
> they should
> probably be named dhcpv4ServerBootpXXX for consistency.
> 
> Could bootp packets be counted at the client or in transit as 
> well as at
> the server? Should these be bootpServerXXX objects?
> 
> bootpCountXXX - you don't need the "Count" in the name;
> bootpRequests/bootpInvalids/etc.  would be consistent with established
> practice for naming counters.
> 
> bootpCountInvalids might be ambiguous regarding the meaning 
> of invalid.
> A standard should be written such that different implementors will not
> interpret the semantics differently.
> 
> bootpCountDroppedUnknownClients and bootpCountDroppedNotServingSubnet
> seem ambiguous and overlapping. If I have not configured my 
> server, and
> don't recognize the hardware address in a received packet, which
> counter(s) get incremented? If I do not provide service to 
> the hardware
> address found in the received packet, and the packet was 
> received from a
> subnet I am not configured to serve, which counter(s) do I increment?
> 
> ---
> dhcpv4Server objects (all objects below start with 
> dhcpv4Server prefix)
> 
> SystemDescr - why is this a SHOULD and not a MUST for compliant
> implementations? Is there a technical reason why it may be 
> impossible to
> provide this information in an implementation that complies with the
> standard? For comparison, sysDescr in RFC3418 calls for the hardware
> type, operating system, and networking software, but that 
> information is
> not always available to the snmp subsystem, so the 
> requirement can only
> be a SHOULD. 
> 
> dhcpv4ServerSystemObjectID - I suspect this is a cut and paste error;
> "identification of the network management subsystem" is also the
> description of sysObjectId from the snmpMIB in RFC3418. Did 
> you mean to
> duplicate that object here? If so, why? If not, what did you 
> want here?
> 
> dhcpv4CountXXX - don't need the "Count"; should use prefix of
> dhcpv4ServerXXX.
> 
> Could these counters also be implemented on clients or transit points?
> (For example, I might want to monitor how much DHCP traffic 
> is passing a
> given node in the network, which is neither client nor server). If so,
> it might be better to write one mib module with objects that 
> can be used
> by either server or client, and another mib module for objects only
> meaningful on a server. Multiple mib modules can exist in a 
> document. By
> separating the modules, an application doesn't need to import object
> definitions that are not important. A developer that uses a utility to
> generate stub code from a mib module won't need to generate stub code
> for a server when they are implementing a client, if you 
> divide the mib
> accordingly.
> 
> Counters that count multiple conditions can lead to different
> interpretations and overlap. In your mib, I get nervous when such OR
> conditions have no reference clause, while the unambiguous counters do
> have reference clauses; this makes me think the counter is 
> ill-defined.
> Can you write CountInvalids, UnknownClient, NotServingSubnet without
> using an OR in the description? Can you provide a reference to ensure
> that there is one unambiguous reference to the condition to 
> be counted?
> Wouldn't it be better to count <address not recognized> 
> separately from
> <address recognized but not serviced>? Wouldn't it be better to count
> <server not configured> separately from <configured to not serve
> addresses on that subnet>? Would it be better to count <not 
> understood>
> separately from <understood but not handled>?
> 
> ---
> SharedNetXXX objects
> 
> SharedNetTable. The description says this table is present ONLY under
> certain conditions, but the Compliance statement shows this as
> unconditionally mandatory. See section 4.8 in the guidelines document
> for how to specify conditionally mandatory sections of the mib. (Note
> that if you make this unconditionally optional, I will 
> probably suggest
> removing it from the mib altogether, since many 
> implementations wouldn't
> bother implementing a fully optional section.)
> 
> SharedNetName is a SnmpAdminString, a T-C defined to allow
> administrators to define names that would be meaningful to them. The
> Security Considerations treats this as a read-only mib. Who decides on
> the value of the names? How is the name set? Is there a 
> reference to how
> one determines what a name should be? Or is it freeform, up to the
> operator? How is it set on a device with only an SNMP interface?
> 
> Why 100 for a length? Is there a reference?
> 
> LowThreshold/HighThreshold - what's an event? Is there a reference for
> the term event in DHCPv4? Is this an snmp notification? 
> 
> LowThreshold/HighThreshold - must the HighThreshold be 
> greater than the
> LowThreshold? Can they be equal? Can High be less than Low? Is there a
> reference someplace?
> 
> How are the thresholds set? They're read-only, but they appear to be
> user-configurable values, possibly set through some backdoor mechanism
> like the CLI. If they are meant to be user configured, why 
> not make the
> objects read-write so those who want to can use snmp SETs to modify
> them? You can always write two compliance clauses - one for a 
> read-write
> implementation and one for read-only implementation, and allow the
> implementor to choose whether to support SETs. For 
> implementations that
> support read-write, a disable-writes object can be used by 
> the operation
> to disable the set capability for the mib (or a global one can be used
> to disable all sets to the agent). SNMP SETs of SNMP objects 
> expected to
> be user-configured shouldn't be **prohibited** by the standard.
> 
> Consistency - SharedNetTable.sharedNetName vs.
> Subnettable.SharedNetworkName; they should both be NetName or both be
> NetworkName.
> 
> Cut-and-paste error? Subnet..LowThreshold ... generated for this
> **shared network**. 
> 
> It would be nice if all accesible-for-notify tables were located near
> the notifications. Currently there are readable objects, then
> accessible-for-notify objects, then readable objects, then 
> notifications
> in the mib.
> 
> ---
> ServerClientTable "an optional list" that "MUST contain addresses that
> have not expired". Is this list optional or "an absolute 
> requirement of
> the specification"? I can't tell what is expected here.
> 
> non-meaningful descriptions:
> ClientEntry - a logical row in the ClientTable (yeah, but what does it
> represent?)
> Client (IPv4 address type) - "the IPv4 address of this entry in the
> ClientTable". (does that mean I can send IPv4 messages to this row in
> the table using this address? Or do you mean this is the IPv4 
> address of
> the client represented in this row?)
> 
> dhcpv4ServerClientSubnetMask "... MUST ... Appear as a row in the
> dhcpSubnetTable." Where do I find the dhcpSubnetTable?
> 
> I did a general review of the document through page 24; I 
> didn't review
> the rest. I'll wait for the next revision, which should be thoroughly
> reviewed by the WG first.
> 
> ---
> There are some typos:
> Section 2: "[RFC3410], Managed" s/b "[RFC3410]. Managed"
> 
> ---
> This module should have been checked against
> http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-
> guidelines
> -02.txt  before being sent for IESG and mib doctor review. It 
> appears to
> me the document has not been checked against the guidelines:
> 
> 1) The boilerplate for snmp is just slightly incorrect (punctuation), 
> 2) the references for SNMP don't match the template, 
> 3) the security considerations don't quite follow the security
> boilerplate,
> 4) the MODULE-IDENTITY OID assignment doesn't follow the section 4.5
> guidelines, 
> 5) the abstract says it is experimental,
> And so on. I stopped mib-doctor-checking at this point.
> 
> Can the WG please check the document against the guidelines before
> resubmitting?
> 
> Thanks,
> dbh
> 
> > -----Original Message-----
> > From: Harrington, David 
> > Sent: Thursday, February 19, 2004 3:03 PM
> > To: [email-masked]'; Glenn Waters ([email-masked])
> > Cc: 'Wijnen, Bert (Bert)'; [email-masked]; 
> > [email-masked]'; [email-masked]'
> > Subject: FW: DHCPv4 MIB review 
> > 
> > Hi,
> > 
> > I don't think I've responded since you published -11- (0r the 
> > second -10-), so here you go. 
> > 
> > This is my first pass only, which includes only the result of 
> > using a diff utility to find text you changed. Since you also 
> > significantly changed the design of the mib, that will 
> > require at least another pass to understand the ramifications 
> > of your changes. Have you run all these chnages past the WG 
> > for review?
> > 
> > 1) I was a bit surprised to see a whole section dropped, 
> > apparently without discussion with the WG. The dropped 
> > "optional" stuff can of course be done as a separate mib later.
> > 
> > 2) In section 3.2.1, it states the MAC address is the layer 1 
> > physical address. The media access control (MAC) address is 
> > part of layer 2.
> > 
> > 3) 3.3 "Not all servers validate received packets in the same 
> > way, so there will be differences in the counts reported by 
> > different servers." I find this antithetical to a standards 
> > document. The MIB object interface should standardize what 
> > gets reported. If different servers count things differently 
> > now, then they should change to provide a consistent 
> > reporting metric. A counter that records different things on 
> > different servers is close to useless for a manager, because 
> > the values cannot be compared across vendors. For example, if 
> > an application sends an alarm to an operator if a counter 
> > exceeds some threshold, you don't want to have to write a 
> > separate rule for each vendor about what the threshold should 
> > be. You want consistency in reporting.
> > 
> > This also means that the counters which go into the formulae 
> > need to be consistent, or you get the GIGO effect.
> > 
> > 4) You dropped leasequery objects, but leasequeries are still 
> > in your total packets formula. Can you check the document for 
> > the use of any objects you eliminated, such as 
> > Dhcpv4CountLeaseQueries, please?
> > 
> > 5) Discontinutities. In the first case, it is hard to 
> > understand when the "point of restart" is, so an application 
> > in the process of two GETs for comparison should assume the 
> > first GET is worthless, and start over, because there is no 
> > way to quantify what occurred during the discontinuous period.
> > 
> > 6) 3.4 "should be able to provide" should be "SHOULD provide"
> > 
> > 7) Many counters were changed to Counter64. Do you really 
> > need 64-bit counters? They are much more expensive for most 
> > vendors to implement, and **critically important** they 
> > cannot be passed using SNMPv1 or SNMPv2 messages. Counter64 
> > should only be used if rollover of a 32-bit counter is 
> > possible within an hour. A 32-bit counter can handle more 
> > than 1 million counted events per second; and "one of the 
> > busiest known to exist" only got to 100 transactions per 
> > second. Counter64 is for counting things like bytes 
> > transmitted on a Gig interface.
> > 
> > dbh
> > 
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Barr Hibbs [mailto:[email-masked]]
> > Sent: Monday, February 02, 2004 7:58 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: DHCPv4 MIB review
> > 
> > 
> > 
> > Dave--
> > 
> > I've updated the DHCPv4 Server MIB per your suggestions and 
> > am attaching a
> > copy of it to this note, prior to submitting it to the I-D editor.
> > 
> > The MIB has been successfully compiled by the SMILINT 
> > compiler, save for the
> > warnings about use of IPv4-specific address components and 
> > the lack of a
> > display hint for an unsigned32 object.
> > 
> > I appreciate your efforts to date on our behalf.
> > 
> > --Barr
> > 
> > 
> > *** included message text ***
> > 
> > This is an automatically generated mail message in response 
> to a mail
> > message
> > you (or someone else who used your address) sent to
> > <[email-masked]>.
> > If you want to learn more about this mail service, send a 
> > mail message with
> > the "Subject: help" to <[email-masked]>.
> > 
> > This command (smilint 0.4.3-pre1, as of Mon Jan 12 15:21:55 2004)
> > has been processed to get the following results:
> > smilint -m -s -l 6 -i namelength-32 mailbody
> > 
> > mailbody:64: [5] {type-without-format} warning: type 
> > `DhcpTimeInterval' has
> > no format specification
> > mailbody:812: [5] {inetaddress-specific} warning: 
> > `InetAddress' should be
> > used instead of `InetAddressIPv4'
> > mailbody:915: [5] {inetaddress-specific} warning: 
> > `InetAddress' should be
> > used instead of `InetAddressIPv4'
> > mailbody:925: [5] {inetaddress-specific} warning: 
> > `InetAddress' should be
> > used instead of `InetAddressIPv4'
> > mailbody:1010: [5] {inetaddress-specific} warning: 
> > `InetAddress' should be
> > used instead of `InetAddressIPv4'
> > mailbody:1031: [5] {inetaddress-specific} warning: 
> > `InetAddress' should be
> > used instead of `InetAddressIPv4'
> > mailbody:1226: [5] {inetaddress-specific} warning: 
> > `InetAddress' should be
> > used instead of `InetAddressIPv4'
> > mailbody:1296: [5] {inetaddress-specific} warning: 
> > `InetAddress' should be
> > used instead of `InetAddressIPv4'
> > 
> 

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

---

From: "Harrington, David" <[email-masked]>
Date: Wed, 17 Mar 2004 11:46:50 -0500

Step on them all you want, Bert ;-) 

I welcome additional eyes reviewing this document. I haven't yet
completed my review, and I think it received inadequate review by the WG
before submission.

dbh

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Wednesday, March 17, 2004 10:44 AM
> Subject: Ad additional reeqview of: DHCPv4 MIB, revision 10
>