Document: draft-ietf-dhc-server-mib-10.txt Reviewer: Lucy Lynch Date: March 15, 2004 REVIEW: Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB Status of this Memo - ok Copyright Notice NIT - Should it read 2004? Abstract "This memo defines an experimental portion of the Management Information Base (MIB)" - Is the word experimental a hold over from an earlier draft? 1. Introduction Paragraph 1: "In particular, it describes a set of extensions that DHCPv4 and Bootstrap Protocol (BOOTP) servers implement." - Awkward, I would reword as: 'In particular, it describes a set of extensions implemented by DHCPv4 and Bootstrap Protocol (BOOTP) servers.' Paragraph 2: "these are possibly the subjects of future investigation" - suggested replacement text: 'these may be the subjects of future investigation' "Provision is also made for Standards-Track additions to the DHCP Message Type (option 61.)" - Is "option 61" clear enough language for the DHCP aware or should this include more context - for example: DHCP Message Type Client-identifier (option 61), as defined in RFC 2132 section 9.14. "Objects defined in this MIB allow access to and control of DHCP Server Software." - what about BOOTP ??? Is it assumed that BOOTP objects will be used only in conjunction w/ DHCP? NIT - A Normative Reference to RFC 2119 is also needed. 2. The Internet-Standard Management Framework boilerplate from: http://www.ops.ietf.org/mib-boilerplate.html NIT - reinsert period and paragraph after [RFC3410]? 3.1.1. DHCP MIB Extensions - Again, how are BOOTP servers related to this diagram? 3.1.3. DHCP Client MIB Extensions - Text needs to flag this as "future work" 3.1.4. DHCP Relay Agent MIB Extensions 3.1.5. DHCPv6 MIB Extensions - no "natural path" to these? Was the natural path cited in 3.1.3 a reflection of current work in progress or an editorial comment? 3.2.1. Dhcpv4PhysicalAddress "This data type contains the type of hardware address represented by MacAddress, as defined for ARP messages, the length in octets of MacAddress, and the actual layer 1 hardware address." - This might be a little clearer: This data type contains: the type of hardware address represented by MacAddress (as defined for ARP messages), the length in octets of MacAddress, and the actual layer 1 hardware address." The DESCRIPTION included in section 4 is *much* clearer - 3.3. BOOTP and DHCP Counter Groups "In this context, a "valid" packet is one which has an identifiable message type and has passed all format and validation checks that the DHCP server implements." - suggested rewording In this context, a "valid" packet is one which has an identifiable message type and has passed all format and validation checks implemented by the DHCP server. "It is appropriate to simply accept the server's notion of what constitutes a valid packet." - I take it this is DCHWG gospel? 3.3.1. Discontinuities "While the counts reported in the first GET response following the outage were accurate at some time, they MAY NOT be completely current. If this occurs, the manager MAY have to accept that data has been lost, perhaps discarding accumulated data, and continue." - Use of Caps for MAY NOT is confusing here - MAY NOT is not an RFC 2119 keyword, and it is not defined earlier - are the caps for emphasis? ASIDE: Capitalization & keywords questions: Section 8. Security Considerations includes: GET SET NOTIFY This text come from boiler plate found here: http://www.ops.ietf.org/mib-security.html QUESTION: - Is this also the correct way to reference SNMP operators in the body of the document? (3.3.1 contains three uses of GET with no definition provided see: "between successive GETs", "responding to a GET request", and "first GET response following") 3.3.2. Counter Rollover "If this is likely to occur (due to very short leases, very large numbers of clients, network topology, and the presence of unreliable clients or intermediate network equipment)". - Use of 64-bit counters instead of 32-bit counters was flagged as an issue in WG discussion: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03184.html The definitions (Section 4) have been modified to include only the 64-bit counter, how does that effect the cases cited? See: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03190.html - If the conditions described in this section are still of concern, might the keyword MUST be substituted for the keyword SHOULD? Are there "valid reasons in particular circumstances" to ignore a situation when "When a counter's value at time t2 is less than its value at time t1" and if so, sould they be noted? 3.4. Server Configuration Group - Note that the two tables discussed here: dhcpv4ServerRangeTable and dhcpv4ServerClientTable raise security concerns and section 8 makes recommendations but no requirements related to these objects. QUESTION: "Examples of server-reserved addresses are those that have been declined (i.e., through a DHCPDECLINE)" DHCPDECLINE - Do keywords like DHCPDECLINE need a pointer to the normative RFC (2131 in this case) the first time they're used or is the reference at the top of the document enough? 4. Definitions - - not my area... 5. Intellectual Property - using the standard RCF 2026 boilerplate 10.4. notices, however - a quick heads up, in: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg03089.html Barr Hibbs said: "Finally, as far as the much-delayed DHCP server MIB is concerned, you are completely correct: I would be thoroughly disingenuous if I applied a different standard to my contributions than to those of others. I'm not going to withdraw the draft until I've learned more about how IBM's patent on "Network Alert Message Construction" has actually affected SNMP implementers, but a quick web search turned up several SNMP agent and manager implementations whose licenses make copyright claims, but none that even acknowledge the IBM patent." In relation to the IPR big blow up on DCPWG in the thread: "IPR statement related to draft-ietf-dhc-subscriber-id-X.txt" 6. Acknowledgements - OK 7. IANA Considerations - Not sure of the correct format here, the pointer is correct. 8. Security Considerations - see 3.4. Server Configuration Group above. The security concerns raised have to do with the visibility of network address information to potentially dangerous viewers. The data in question is read-only, but may provide information about address availablity. Recommendations are made for protecting this data, but no requirements are placed on implementers or operators. 9. References "One normative reference is currently an Internet-Draft, nearly ready for Working Group Last Call. This reference MUST be updated when the draft advances to RFC status." - ? which draft - I didn't find this reference ? - Add Normative Reference to RFC 2119 10. Editors' Addresses 11. Full Copyright Statement - OK, standard boilerplate