Client Identifier Option in DHCP Server Replies
draft-ietf-dhc-client-id-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-11-16
|
07 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-11-15
|
07 | (System) | IANA Action state changed to No IC |
2012-11-15
|
07 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-11-15
|
07 | Amy Vezza | IESG has approved the document |
2012-11-15
|
07 | Amy Vezza | Closed "Approve" ballot |
2012-11-15
|
07 | Amy Vezza | Ballot approval text was generated |
2012-11-15
|
07 | Amy Vezza | Ballot writeup was changed |
2012-11-15
|
07 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-11-05
|
07 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2012-11-05
|
07 | Barry Leiba | [Ballot comment] Thanks for addressing all my comments in the -07 version. |
2012-11-05
|
07 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2012-11-04
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-11-04
|
07 | Gaurav Halwasia | New version available: draft-ietf-dhc-client-id-07.txt |
2012-11-01
|
06 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2012-10-25
|
06 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead |
2012-10-25
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-10-24
|
06 | Wesley Eddy | [Ballot comment] I support both Brian & Barry's DISCUSS points. |
2012-10-24
|
06 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-10-24
|
06 | Sean Turner | [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 & … [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. |
2012-10-24
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-10-24
|
06 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-10-23
|
06 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-10-23
|
06 | Robert Sparks | [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 … [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. |
2012-10-23
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-10-22
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-10-22
|
06 | Francis Dupont | Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2012-10-22
|
06 | Stewart Bryant | [Ballot comment] The document says: The Dynamic Host Configuration Protocol (DHCP) defined in [RFC2131] provides configuration parameters to hosts on a TCP/IP based … [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. |
2012-10-22
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-10-22
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-10-22
|
06 | Stephen Farrell | [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 … [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." |
2012-10-22
|
06 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2012-10-22
|
06 | Stephen Farrell | [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 … [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.) |
2012-10-22
|
06 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-10-21
|
06 | Adrian Farrel | [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. … [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/ |
2012-10-21
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-10-19
|
06 | Barry Leiba | [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 … [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? |
2012-10-19
|
06 | Barry Leiba | [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 … [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. |
2012-10-19
|
06 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2012-10-17
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-10-16
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-10-16
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-10-16
|
06 | Brian Haberman | [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 … [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. |
2012-10-16
|
06 | Brian Haberman | [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 … [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. |
2012-10-16
|
06 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2012-10-08
|
06 | Pearl Liang | 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 … 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. |
2012-10-04
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-10-04
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2012-10-04
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2012-10-04
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2012-10-03
|
06 | Amy Vezza | 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 … 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. |
2012-10-03
|
06 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-10-03
|
06 | Ralph Droms | Placed on agenda for telechat - 2012-10-25 |
2012-10-03
|
06 | Ralph Droms | Last call was requested |
2012-10-03
|
06 | Ralph Droms | State changed to Last Call Requested from AD Evaluation |
2012-10-03
|
06 | Ralph Droms | Last call announcement was generated |
2012-10-03
|
06 | Ralph Droms | Ballot has been issued |
2012-10-03
|
06 | Ralph Droms | Ballot approval text was generated |
2012-10-03
|
06 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2012-10-03
|
06 | Ralph Droms | Created "Approve" ballot |
2012-10-02
|
06 | Gaurav Halwasia | New version available: draft-ietf-dhc-client-id-06.txt |
2012-10-02
|
05 | Ralph Droms | Ballot writeup was changed |
2012-10-02
|
05 | Ralph Droms | Ballot writeup was generated |
2012-09-24
|
05 | Ralph Droms | State changed to AD Evaluation from Publication Requested |
2012-09-12
|
05 | Cindy Morgan | 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 … 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. |
2012-09-11
|
05 | Amy Vezza | (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? … (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. |
2012-09-11
|
05 | Amy Vezza | Note added 'Ted Lemon (Ted.Lemon@nominum.com) is the Document Shepherd.' |
2012-09-11
|
05 | Amy Vezza | Intended Status changed to Proposed Standard |
2012-09-11
|
05 | Amy Vezza | IESG process started in state Publication Requested |
2012-09-10
|
05 | Gaurav Halwasia | New version available: draft-ietf-dhc-client-id-05.txt |
2012-07-11
|
04 | Gaurav Halwasia | New version available: draft-ietf-dhc-client-id-04.txt |
2012-07-10
|
03 | Gaurav Halwasia | New version available: draft-ietf-dhc-client-id-03.txt |
2012-03-12
|
02 | Unit Sez | New version available: draft-ietf-dhc-client-id-02.txt |
2012-02-17
|
01 | (System) | Document has expired |
2011-08-16
|
01 | (System) | New version available: draft-ietf-dhc-client-id-01.txt |
2004-02-02
|
00 | (System) | New version available: draft-ietf-dhc-client-id-00.txt |