Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-3315id-for-v4

From: Ralph Droms <[email-masked]>
Date: Thu, 16 Dec 2004 07:15:57 -0500

This message announces a WG last call on "Node-Specific Client
Identifiers for DHCPv4" <draft-ietf-dhc-3315id-for-v4-03>.  The last
call will conclude at 1700EST on 2005-01-07.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.

"Node-Specific Client Identifiers for DHCPv4" specifies the format
that is to be used for encoding DHCPv4 [RFC2131 and RFC2132] client
identifiers, so that those identifiers will be interchangeable with
identifiers used in the DHCPv6 protocol [RFC3315].  This draft is
available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-03.txt

- Ralph Droms 

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 30 Dec 2004 11:55:06 -0800

A few cosmetic errors I may as well mention first;

In the Introduction, there are newlines where they don't belong;

>  regardless of the version of DHCP they are using at any given
>
>
>  moment.  Most obviously, DNS updates made by the DHCP server on

In section 3 (Requirements):

>  - It must be possible, in cases where the DHCPv4 client is
>    expressing more than one network identity at the same time, it
>    must nevertheless be possible for the DHCPv4 server to determine
>    that the two network identities belong to the same host.

The language is redundant, and confuses the point.

In section 4.4, we have a less trivial problem:

>  The text in section 9.14, beginning with "The client identifier MAY
>  consist of" through "that meet this requirement for uniqueness." is
>  replaced with "the client identifier consists of a type field whose
>  value is normally 255, followed by a two-byte type field, followed
>  by the contents of the identifier.  The two-byte type field and the
>  format of the contents of the identifier are defined in RF3315,
>  section 9."  The text "its minimum length is 2" in the following
>  paragraph is deleted.

The one-byte type field (normally 255) is followed by a two-byte type
field?

In section 4.1 we were told the option looked like this:

>     Code  Len  Type  IAID                DUID
>     +----+----+-----+----+----+----+----+----+----+---
>     | 61 | n  | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
>     +----+----+-----+----+----+----+----+----+----+---

Which contradicts what we were just told section 4.4.  I think the
author meant that the DUID starts with a 2-byte type field, but the
DUID contents are never defined in this draft (it always refers to
rfc3315 section 9), so probably this just shouldn't be mentioned.

Because of this last bit, I don't think this draft should be advanced.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg