Client Identifier Option in DHCP Server Replies
draft-ietf-dhc-client-id-07

I agree with the concern expressed by other ADs that this document makes
no comment about why there was mandatory behavior in 2131.  Perhaps it
was a mistake, or maybe "MUST NOT" was used to indicate that there was 
no known reason to include 'cleint identifier'. I also agree that it 
seems likely that the WG would not have supported this document without
being OK with this point, so I don't think the issue merits a Discuss,
but adding a briefexplanation to the Introduction would be nice.

While you have this document open to address the Discusses, could you 
please consider some tidying...

---

Abstract

- Please don't include citations (using square brackets) in the Abstract
  as it must stand alone.
- Please s/draft/document/
- s/clairies/clarify/

---                                                                                      

Section 1 para 1

a/server/servers/

---

Section 1 para 2

- s/clairies/clarify/
- s/of 'client identifier'/of the 'client identifier'/
- s/return client identifier'/return the 'client identifier'/

---

Section 2

   DHCP relay agents and servers,
   following these recommendations MAY drop the DHCP packets in the
   absence of both 'client identifier' and 'chaddr'.

It is not clear what "these recommendations" means. The previously 
quoted text is not a recommendation. And the "MAY" is also not a 
recommendation.

I assume that this text is still describing the status quo ante, not
the status after this document, so how about...

   Furthermore, DHCP relay agents and servers implementing [RFC2131]
   "MAY" drop the DHCP packets in the absence of both 'client
   identifier' and 'chaddr'.

---

Section 2 para 2

OLD
   In some cases, client may not be having valid hardware address value
   to be filled in 'chaddr' field of the packet and hence may set this
   field as zero.
NEW
   In some cases, a client may not be have a valid hardware address
   value to be fill into the 'chaddr' field of the packet and hence may
   set this field as zero.
END

---

Section 2 para 3

   Note that due to above mentioned recommendations in [RFC2131]

I don't think it is a recommendation. How about s/recommendation/option/

---

Sections 2 and 3

You want his published as a standards track RFC, so you need to stop
"proposing" and start "specifying".

---

Section 3

   If the 'client identifier' option is set in a message received

To avoid exactly the same ambiguity in the future, can I suggest
s/set/present/

Thanks for addressing all my comments in the -07 version.

1. There are several places with subject-verb disagreement and missing articles.  I would suggest an editorial review.

2. The Introduction should either drop mention of the "Problem Statement" or add a forward reference to that section.

3. I had a hard time parsing the 1st sentence of the 2nd paragraph in Section 2:

          In some cases, client may not be having valid hardware address value
          to be filled in 'chaddr' field of the packet and hence may set this
          field as zero.

Should this be:

          In some cases, a client may not have a valid hardware address to populate
          the 'chaddr' field and may set the field to all zeroes.

I support Barry's discuss.

The last sentence in the first paragraph of the problem statement looks like it is putting a normative requirement on DHCP relay agents and servers ("MAY drop the DHCP packets"). Is it restating something that 2131 explicitly allows? I'm not quickly finding text in 2131 that says this - could you add a pointer? Or was the intent to say "some implementations might"?

Is there danger that existing relays (or firewalls) would discard responses containing the client identifier given that the packet violates a MUST NOT in 2131? If so, the document should acknowledge that deployment consideration.

In the fifth paragraph of the problem statement, the document talks of multiple DHCP clients running on the same host sharing the same chaddr. Please consider clarifying whether you mean independent pieces of software (running in different processes) or if you are talking about a single piece of software attempting to configure more than one address.

I'm on board with the other discuss holders.  Further, I really like Ted's response to Stephen's comment and am hoping the shepherd & authors agree to include it.

This is a "did the WG think about this?" comment that used
to be a discuss. 

Privacy is much more of a deal now than it was in 1997. RFC
2131 says that the client identifier is opaque and MUST be
unique for the subnet and MUST be the same for a while.

I believe (but am open to correction) that current clients 
generally pick a value for this and then pretty much use 
that for all time for all networks.

Would it be reasonable to call that out as a privacy issue if
the value chosen is personally identifying information (PII),
(or becomes such through repeated usage) and to RECOMMEND that
clients don't pick PII as the value for client identifiers and
that clients also change the value used when they can? I'm not
sure it'd be easy to properly state when its safe to change the
value used, but perhaps folks who know DHCP better would be
able to figure that out.

Ted Lemon suggested maybe adding something like
this as a security consideration: 

  "It is worth noting that DHCP clients routinely connect to different 
   IP networks managed by different network providers.   DHCP 
   clients have no a priori knowledge of which network they are 
   connecting to.   Consequently, the client identifier will, by 
   definition, be routinely shared with network operators and 
   could be used in ways that violate the user's privacy.   This is a 
   problem that existed in RFC2131.   This document does nothing 
   to address this problem."

The document says:

The Dynamic Host Configuration Protocol (DHCP) defined in [RFC2131]
provides configuration parameters to hosts on a TCP/IP based network.

I think it should say ... hosts on an IP network.

TCP may be there, but is not required.

I support both Brian & Barry's DISCUSS points.