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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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."

[Ballot discuss]

This is a "did the WG think about this?" discuss.  If the wg
considered it but decided not to bother that's fine and I'll
clear. If not, I'd like to know if it seems like a good/bad
idea, but will clear if folks figure its not worth it.

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.

(I realise that this draft is mainly an update for servers and
relays, hence my willingness to fold on the discuss, but if we
could at the same time encourage clients to be more
privacy-friendly then that might be worthwhile.)

[Ballot comment]
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/

[Ballot discuss]
*Why* does 2131 say what it says?  Is the fix really as simple as this?  Is there no danger of any misbehaviour with clients that are not expecting the "client identifier" in the DHCPOFFER and DHCPACK messages?

Regardless of the answer to this (I'm expecting that it's safe to do this, or the WG wouldn't have approved the document), these questions should be answered in the document.  Why is it currently prohobited to return that option, why is it different in DHCPv6, and why is it safe to make this change?

[Ballot comment]
These are non-blocking, but please consider them, and feel free to chat with me about them:

Does this document really need the pre-5378 disclaimer?  I presume it means that the first listed author isn't sure he has clerance from Nokia to grant rights to the IETF Trust.  But that would surprise me, as Nokia still has a lot of active IETF participants.  Or is there some other reason for the disclaimer?

The abstract should not use citations.  You could also clean up redundancy and verbosity in the abstract, and actually say more, this way:

NEW
  This document updates RFC 2131 -- Dynamic Host Configuration
  Protocol (DHCP) -- by addressing the issues arising from that
  document's specification that the server MUST NOT return the
  "client identifier" option to the client.

Despite its brevity, this is a difficult document to read.  I think, though, that it's ultimately understandable, and that the RFC Editor will be able to fix the problems without introducing errors, so this isn't worth a major editing pass at this point.

[Ballot discuss]
I have no problem with the publication of this document, but I do have a few issues that should be discussed.

1. I find it surprising that the draft's Security Considerations section says "No known security considerations".  If a DHCP message contains the client identifier option, are there any potential DoS attacks that could be launched?  What about user tracking?

2. Should this draft provide more guidance on the setting of the client identifier field?  I did not see anything in 2131 that precluded a device from setting it to zero, which appears to be an issue if chaddr is set to zero.

[Ballot comment]
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.

IANA has reviewed draft-ietf-dhc-client-id-06, which is currently in
Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Client Identifier Option in DHCP Server Replies) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Client Identifier Option in DHCP Server Replies'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document updates RFC2131 [RFC2131].  The changes to [RFC2131]
  defined in this draft clarifies the use of 'client identifier' option
  by the DHCP servers.  The clarification addresses the issues arising
  out of the point specified by [RFC2131] that the server 'MUST NOT'
  return client identifier' option to the client.

Requirements



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-client-id/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-client-id/ballot/


No IPR declarations have been submitted directly on this I-D.

UPDATED Write-up:

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard: this updates RFC2131, which is a proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document updates RFC2131 to change the DHCP server's behavior with respect to the DHCP client identifier option.  Prior to this update, DHCP servers were expected not to return the client identifier to the client in DHCPOFFER, DHCPACK and DHCPNAK messages.  Following this update, DHCP servers are expected to return the client identifier in all three of these messages.  This resolves a problem where in cases where the chaddr field of the client identifier is zero, the client can't accurately identify DHCP messages as being directed specifically to it.

Working Group Summary:

There was essentially unanimous support for this document, and the document received wide review.

Document Quality:

This is a relatively minor change to the existing DHCPv4 protocol, and is not expected to create interoperability problems.  The authors have done a test implementation with a Cisco DHCP server, and tested this against five DHCP clients, and no problems were observed.  It's always possible that some client somewhere will break, but these results are encouraging.

Personnel:

Ted Lemon is the Document Shepherd.  Ralph Droms is the responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have read this document several times over the course of its development, including one read just before writing this shepherd document.  It's not very long.  The document could use some additional editing for language, but is otherwise solid.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, the document received thorough review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No, there's nothing like this in the document.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

This document is an enabling update for DHCP across tunnels, which may become important during the transition to IPv6.  I fully support this work.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Gaurav Halwasia has stated that he is unaware of any IPR related to this document.  Prashant Jhingran has also stated that he is unaware of any IPR related to this document.  Narasimha Swamy Nelakuditi (N. Swamy) has also stated that he is unaware of any IPR related to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WGLC only got five positive responses (and no negative repsonses), but we've had widespread support both on the mailing list, in terms of reviews, and in the meetings.  Unfortunately it's hard to get people to respond in a timely fashion--I'd like to have had more positive responses, but this is not atypical, and given the lack of opposition and the support we've had in meetings, I don't feel that it's necessary to stall the document by doing another last call.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No, as far as I know, there's been no dissent about this document at all.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The document triggers a warning about missing the required text for legal provisions, but when I compared the text in the document to the text in the legal provisions, it looked right.  I think the problem is that it's got a page break in the middle.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no MIBs, media types or URIs in the document, so no need for these reviews.

(13) Have all references within this document been identified as either normative or informative?

All of the references in the document are identified as normative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No, all the normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

This document isn't mature enough to trigger a downward reference.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, RFC2131, and yes, it is listed.  The introduction mentions the changes to RFC2131 but does not explicitly say that the document updates RFC2131; however, the abstract does say this, and of course it's also stated on the title page.  It would be a minor tweak to the introduction to fix this if it's necessary to do so.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section is a no-op; my review of it was to determine that it was a no-op.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries are required.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no such sections.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard.  This updates RFC2131, which is a proposed standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please
provide such a Document Announcement Write-Up. Recent examples can be found in the "Action"
announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document updates RFC2131 to change the DHCP server's behavior with respect to the DHCP
client identifier option.  Prior to this update, DHCP servers were expected not to return the client
identifier to the client in DHCPOFFER, DHCPACK and DHCPNAK messages.  Following this update,
DHCP servers are expected to return the client identifier in all three of these messages.  This
resolves a problem where in cases where the chaddr field of the client identifier is zero, the client
can't accurately identify DHCP messages as being directed specifically to it.

Working Group Summary:

There was essentially unanimous support for this document, and the document received wide review.

Document Quality:

This is a relatively minor change to the existing DHCPv4 protocol, and is not expected to create
interoperability problems.  The authors have done a test implementation with a Cisco DHCP server,
and tested this against five DHCP clients, and no problems were observed.  It's always possible that
some client somewhere will break, but these results are encouraging.

Personnel:

Ted Lemon is the Document Shepherd.  Ralph Droms is the responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If
this version of the document is not ready for publication, please explain why the document is being
forwarded to the IESG.

I have read this document several times over the course of its development, including one read just
before writing this shepherd document.  It's not very long.  The document could use some additional
editing for language, but is otherwise solid.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that
have been performed?

No, the document received thorough review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g.,
security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the
review that took place.

No, there's nothing like this in the document.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document
that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or has concerns whether there really is
a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes
to advance the document, detail those concerns here.

This document is an enabling update for DHCP across tunnels, which may become important during
the transition to IPv6.  I fully support this work.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full
conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Gaurav Halwasia has stated that he is unaware of any IPR related to this document.  Prashant
Jhingran has also stated that he is unaware of any IPR related to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG
discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence
of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WGLC only got five positive responses (and no negative repsonses), but we've had widespread
support both on the mailing list, in terms of reviews, and in the meetings.  Unfortunately it's hard to
get people to respond in a timely fashion--I'd like to have had more positive responses, but this is not
atypical, and given the lack of opposition and the support we've had in meetings, I don't feel that it's
necessary to stall the document by doing another last call.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please
summarise the areas of conflict in separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is publicly available.)

No, as far as I know, there's been no dissent about this document at all.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/
and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The document triggers a warning about missing the required text for legal provisions, but when I
compared the text in the document to the text in the legal provisions, it looked right.  I think the
problem is that it's got a page break in the middle.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor,
media type, and URI type reviews.

There are no MIBs, media types or URIs in the document, so no need for these reviews.

(13) Have all references within this document been identified as either normative or informative?

All of the references in the document are identified as normative.

(14) Are there normative references to documents that are not ready for advancement or are
otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No, all the normative references are to RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

This document isn't mature enough to trigger a downward reference.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed
on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

Yes, RFC2131, and yes, it is listed.  The introduction mentions the changes to RFC2131 but does
not explicitly say that the document updates RFC2131; however, the abstract does say this, and of
course it's also stated on the title page.  It would be a minor tweak to the introduction to fix this if it's
necessary to do so.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with
regard to its consistency with the body of the document. Confirm that all protocol extensions that the
document makes are associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name for the new registry has been
suggested (see RFC 5226).

The IANA considerations section is a no-op; my review of it was to determine that it was a no-op.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries are required.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate
sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no such sections.