Subject: [dhcwg] RE: Minutes from 2/23 RFC2131 review conf call (2nd try)

From: "Richard Barr Hibbs" <[email-masked]>
Date: Fri, 26 Mar 2004 15:18:02 -0800

sorry to have taken so long to reply, but two rounds of eye
surgery affected my ability to read....

--Barr

> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]]
> Sent: Wednesday, 24 March 2004 05:06
>
> 2. Accept or reject typographic corrections
>
> The state machine in RFC2131 will be retained.
>
(1) there was some discussion about whether some messages
were sent BEFORE or AFTER transitioning from one state to
the other, with no clear consensus;  (2) an earlier mailing
list discussion about a STOPPED state was not discussed
during the conference call;  (3) I offered to supply an
updated version of the client state transition diagram for
discussion that goes to point (1)

> 5. Clarification of the Client Identifier
> (eliminate suggested format)
>
> RFC2131bis (as well as RFC2132bis) will specify
> that the 'client
> identifier' is an opaque string, with one
> suggestion that the client
> can construct the 'client identifier' as an
> htype/address pair.  The
> server MUST NOT try to interpret the contents of
> the 'client
> identifier'; in particular, the server will not
> try to determine if
> the length of the address matches the hardware type.
>
(1) the conference call did not address Ted's proposal for a
3315-like DUID to be used in place of the suggested format
for client identifier:  this requires a bit more discussion
and should be taken to the mailing list;  (2) my memory of
our consensus regarding htype and hlen was that a server
(and, presumably, a client as well) should not be REQUIRED
to verify agreement between htype, hlen, and the contents of
client identifier because client identifier is supposed to
be opaque:  at the same time, the text should strongly
suggest that htype, hlen, and chaddr be in agreement so that
any intermediate equipment will not wrongly discard packets
due to mismatches;  (3) we didn't quite agree that the
client identifier should be globally unique, despite the
advantages of that assertion, but we did nearly agree that
RFC2132bis should offer multiple suggestions on how to
construct client identifiers as long as the text clearly
states that the suggestions are not required behavior.

> 8. Can we eliminate the 'sname' and 'file' fields
> of the BOOTP packet?
>
> Because this topic touches on significant changes
> to the DHCP specification, it will be the subject
> of a separate document.
>
> Currently, 'siaddr' carries the address of one
> boot server, while 'sname' and the TFTP server
> name option (66) carry a DNS name.  Is there a
> requirement for an option that carries a list of
> addresses of boot servers?
> draft-vijay-dhc-opt-extrboot-00.txt defines a
> new option with a list of servers and associated
> file names.
>
(1) generally (but NOT universally) DHCP options use IP
addresses rather than DNS names for locating network
resources, so which to use is an item for discussion;  (2)
it's not clear to me from my reading of DOCSIS and other
documents that specify the use of the sname and file fields
that they would even successfully interoperate with an
arbitrary DHCP server because they don't seem to accept
option 66 or overlaying the sname and file fields for long
lists of options -- definitely a mailing list discussion is
needed.

> 9. Accept, reject, or further study SHOULD v. MUST changes
>
> draft-hibbs-dhc-changes-00.txt will be discussed
> in detail in the next
> conf call.
>
...the intent of that draft was to specify minimum
documentation requirements for any new I-D that modifies the
DHCP protocol or options, so it should be pretty
non-controversial (I hope!)

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