Subject: [dhcwg] New draft as WG work item

From: Ralph Droms <[email-masked]>
Date: Thu, 29 Jan 2004 12:29:44 -0500

We have a request to consider the following draft as a WG work item:

                    Requirements for Proposed Changes to the
                 Dynamic Host Configuration Protocol for IPv4 (DHCPv4)

                           <draft-hibbs-dhc-changes-00.txt>

      Abstract

         This memo describes the requirements of Internet-Drafts proposing
         changes to the Dynamic Host Configuration Protocol for IPv4 
(DHCPv4).
         These requirements specifically cover documentation expected whenever
         message formats or client state transitions are modified.

It is my judgment that this draft provides a useful set of requirements to
be used in evaluating future updates and extensions to DHCP.  Please post
comments about this draft to the [email-masked] mailing list before 5PM
Friday, 1/30.

- Ralph

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

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 29 Jan 2004 11:34:40 -0800

As the author, I obviously favor this short draft, and would like to give an
expanded rationale for it.

>From our review of RFC2131 one of the common threads has been that certain
sections of the RFC were not kept in synch with the rest of the changes
occurring in separate I-Ds or RFCs.  I've presented what I think is a
reasonable set of requirements that SHOULD be met by any future I-D author
to address these synchronization problems.

Specific items include:

(1) updating the client state machine diagram whenever a new message type is
added or the behavior of an existing message type is changed (or, as was
recently suggested on the mailing list, when a new state is added)

(2) updating the tables giving requirements for certain protocol fields in
the message formats whenever the relationship between fields is changed, a
new protocol field is added, or (however unlikely) a protocol field is
deleted

(3) updating the text of the RFC whenever an I-D proposes a change in the
behavior of the protocol, identifies a conflict, or attempts to resolve
interactions between other features of the protocol

As I believe that each of these is something that an author should be doing
as part of the implied "due diligence" to create workable RFCs, I don't
believe that any of them represent an undue burden on I-D authors.

This work could be extended to include DHCPv6 if the Working Group desires.

Thanks,

--Barr