Subject: [dhcwg] RE: DHCPv4 MIB review - detailed part one

From: "Harrington, David" <[email-masked]>
Date: Wed, 17 Mar 2004 09:48:23 -0500

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