Generalized UDP Source Port for DHCP Relay
draft-ietf-dhc-relay-port-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-03-06
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-03-01
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-02-16
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-01-07
|
10 | Martin Stiemerling | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
2018-01-04
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-01-03
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-01-02
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-01-02
|
10 | (System) | RFC Editor state changed to EDIT |
2018-01-02
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-01-02
|
10 | (System) | Announcement was received by RFC Editor |
2018-01-02
|
10 | (System) | IANA Action state changed to In Progress |
2018-01-01
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-01-01
|
10 | Cindy Morgan | IESG has approved the document |
2018-01-01
|
10 | Cindy Morgan | Closed "Approve" ballot |
2018-01-01
|
10 | Cindy Morgan | Ballot approval text was generated |
2017-12-27
|
10 | Suresh Krishnan | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2017-12-14
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-12-14
|
10 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-10.txt |
2017-12-14
|
10 | (System) | New version approved |
2017-12-14
|
10 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-12-14
|
10 | Naiming Shen | Uploaded new revision |
2017-11-30
|
09 | Jean Mahoney | Closed request for Telechat review by GENART with state 'Team Will not Review Version' |
2017-11-30
|
09 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2017-11-30
|
09 | Spencer Dawkins | [Ballot comment] I am watching the discussion about whether the same port is used to send and receive these messages on Ben's (previous) Discuss (now … [Ballot comment] I am watching the discussion about whether the same port is used to send and receive these messages on Ben's (previous) Discuss (now a No-Objection). |
2017-11-30
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-11-30
|
09 | Alexey Melnikov | [Ballot comment] Looking forward to hearing answer to Adam's last question. |
2017-11-30
|
09 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2017-11-29
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-11-29
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-11-29
|
09 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-09.txt |
2017-11-29
|
09 | (System) | New version approved |
2017-11-29
|
09 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-11-29
|
09 | Naiming Shen | Uploaded new revision |
2017-11-29
|
08 | Ben Campbell | [Ballot comment] Discussion seems to be moving in the right direction, so I have cleared my response. I've added it back as a comment for … [Ballot comment] Discussion seems to be moving in the right direction, so I have cleared my response. I've added it back as a comment for now: (I want to "discuss" the following DISCUSS point. If the answer is that this is by design, and the working group thinks that the operational aspects are reasonable, then I will clear.) This extension places normative requirements on any upstream server or relay, which may or may not implement this spec. It further appears that if you try to use this extension without that support, things will break. That seems to require at least an update to the DCHP and DCHPv6 RFCs[1], and some method of discovery or fallback would be helpful. Section 5.4 discusses this a little bit, but I think it needs to talk about what to do when things fail. "Turn off the feature if you don't get DHCP responses" doesn't seem satisfying. [1] I see 3.1 and 3.2 make changes to 2131 and 3315, so it seems an "UPDATES... " tag is needed one way or another. -1, last paragraph: It seems like the 2119 keywords here would be better placed in the later sections about relay and server behavior. I suggest moving them there, and making the introductory language non-normative. - 3.1 and 3.2: I am surprised not to see 2119 keywords in the language added to 2131 and 3315: -8: This spec adds the ability to direct dhcp responses to non-standard ports. If the working group believes that does not affect the security considerations, please describe the rational. (I'm not saying that I think there's a problem, but I think the burden is on the working group to explain why they think there is not.) |
2017-11-29
|
08 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss |
2017-11-29
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-11-29
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-11-29
|
08 | Ben Campbell | [Ballot discuss] (I want to "discuss" the following DISCUSS point. If the answer is that this is by design, and the working group thinks that … [Ballot discuss] (I want to "discuss" the following DISCUSS point. If the answer is that this is by design, and the working group thinks that the operational aspects are reasonable, then I will clear.) This extension places normative requirements on any upstream server or relay, which may or may not implement this spec. It further appears that if you try to use this extension without that support, things will break. That seems to require at least an update to the DCHP and DCHPv6 RFCs[1], and some method of discovery or fallback would be helpful. Section 5.4 discusses this a little bit, but I think it needs to talk about what to do when things fail. "Turn off the feature if you don't get DHCP responses" doesn't seem satisfying. [1] I see 3.1 and 3.2 make changes to 2131 and 3315, so it seems an "UPDATES... " tag is needed one way or another. |
2017-11-29
|
08 | Ben Campbell | [Ballot comment] -1, last paragraph: It seems like the 2119 keywords here would be better placed in the later sections about relay and server behavior. … [Ballot comment] -1, last paragraph: It seems like the 2119 keywords here would be better placed in the later sections about relay and server behavior. I suggest moving them there, and making the introductory language non-normative. - 3.1 and 3.2: I am surprised not to see 2119 keywords in the language added to 2131 and 3315: -8: This spec adds the ability to direct dhcp responses to non-standard ports. If the working group believes that does not affect the security considerations, please describe the rational. (I'm not saying that I think there's a problem, but I think the burden is on the working group to explain why they think there is not.) |
2017-11-29
|
08 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2017-11-29
|
08 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-11-28
|
08 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-11-28
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-11-28
|
08 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-08.txt |
2017-11-28
|
08 | (System) | New version approved |
2017-11-28
|
08 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-11-28
|
08 | Naiming Shen | Uploaded new revision |
2017-11-28
|
07 | Adam Roach | [Ballot comment] Thanks for your time on this document. I have one minor correction and two questions. The introduction says: "...for IPv6 the server port … [Ballot comment] Thanks for your time on this document. I have one minor correction and two questions. The introduction says: "...for IPv6 the server port is (546) and the client port is (547)." I believe this is backwards. Section 5.2 says: If this option is included to indicate only the local non-DHCP UDP port usage and there is no downstream relay agent's non-DHCP UDP port usage, the field Downstream Source Port field MUST be set to zero. Was the use of length=0 considered rather that port=0 here? The reason I ask is that UDP port 0 is *reserved*, but not technically *invalid*, and the use of "length=0" would distinguish between the flag usage and the port usage while not precluding the valid (if admittedly rare) use of port=0. Finally, I have a question about DHCPv6 relay agent chains that arose in reading the document. The example section actually gives a pretty good jumping off point to ask the question, so I'll quote an excerpt here: Similar to the above example, now assume that Relay2 uses the UDP source port of 2000 instead of 547 as in the diagram. The Relay3 device needs to support this DHCP extension and it will set 2000 in its "Downstream Source Port" field of the option in the Relay-forward message. When DHCP server sends the DHCP Relay-reply to Relay3, Relay3 finds its own relay option has this "Downstream Source Port" with the value of 2000. Relay3 will use this UDP port when sending the Relay-reply message to Relay2. If we were to continue this paragraph all the way back to Relay1, it's not clear how Relay2 would know to use port 1000 when sending its Relay-reply message to Relay1. Does this mechanism have a limitation that only one Relay Agent in the forwarding chain is allowed to use a Non-DHCP UDP Port? |
2017-11-28
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2017-11-28
|
07 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-11-28
|
07 | Warren Kumari | [Ballot comment] I have only some nits to offer... Nits: Section 1. Introduction "based on DHCP relay computational load. But rather DHCP relay" -- extra … [Ballot comment] I have only some nits to offer... Nits: Section 1. Introduction "based on DHCP relay computational load. But rather DHCP relay" -- extra space after period. "The DHCP server when sending back replies MUST use the UDP port number that the incoming relay agent uses instead of the fixed DHCP port number." -- I think that this would be more readable as: When sending back replies, the DHCP server MUST..." -- the original caused me to stop and scratch my head for a bit. |
2017-11-28
|
07 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2017-11-28
|
07 | Alissa Cooper | [Ballot comment] Please have a look at the Gen-ART review, although I disagree with the reviewer's suggestion about replacing the reference to RFC 2119 with … [Ballot comment] Please have a look at the Gen-ART review, although I disagree with the reviewer's suggestion about replacing the reference to RFC 2119 with one to RFC 8174. If there is a desire to make usage of normative keywords clearer in this document, I would suggest replacing the two occurrences of lowercase "must" with "needs to." |
2017-11-28
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-11-28
|
07 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-11-28
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-11-25
|
07 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2017-11-13
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-11-12
|
07 | Mirja Kühlewind | [Ballot comment] I really think this document should update RFC2131 and RFC3315 as it proposed concrete changes to both RFCs. The point is that, while … [Ballot comment] I really think this document should update RFC2131 and RFC3315 as it proposed concrete changes to both RFCs. The point is that, while the use of the described mechanism and options is optional, I think the updates of the texts apply more generally. Further, I would think that if a DHCP server now has to listen on all ports for incoming traffic, that this would raise additional security considerations. However, didn’t think enough about it to name a specific threat. |
2017-11-12
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-11-11
|
07 | Suresh Krishnan | Ballot has been issued |
2017-11-11
|
07 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2017-11-11
|
07 | Suresh Krishnan | Created "Approve" ballot |
2017-11-11
|
07 | Suresh Krishnan | Ballot writeup was changed |
2017-11-11
|
07 | Suresh Krishnan | Ballot writeup was changed |
2017-10-28
|
07 | Victor Kuarsingh | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Victor Kuarsingh. |
2017-10-27
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Jari Arkko |
2017-10-27
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Jari Arkko |
2017-10-27
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-10-27
|
07 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-07.txt |
2017-10-27
|
07 | (System) | New version approved |
2017-10-27
|
07 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-10-27
|
07 | Naiming Shen | Uploaded new revision |
2017-10-26
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Scott Kelly. |
2017-10-24
|
06 | Francis Dupont | Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2017-10-24
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-10-20
|
06 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2017-10-19
|
06 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-10-19
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-dhc-relay-port-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-dhc-relay-port-06. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the DHCP Relay Agent Sub-Option Codes registry located on the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry page located at: https://www.iana.org/assignments/bootp-dhcp-parameters/ a single, new sub-option code is to be registered as follows: Code: [ TBD-at-registration ] Sub-Option Description: DHCPv4 Relay Source Port Reference" [ RFC-to-be ] Second, in the Option Codes registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at: https://www.iana.org/assignments/dhcpv6-parameters/ a single, new option code is to be registered as follows: Value: [ TBD-at-registration ] Description: DHCPv6 Relay Source Port Reference: [ RFC-to-be ] Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC. The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist |
2017-10-12
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2017-10-12
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2017-10-12
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2017-10-12
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2017-10-11
|
06 | Suresh Krishnan | Telechat date has been changed to 2017-11-30 from 2017-10-26 |
2017-10-11
|
06 | Suresh Krishnan | Placed on agenda for telechat - 2017-10-26 |
2017-10-11
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2017-10-11
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2017-10-11
|
06 | Martin Stiemerling | Request for Last Call review by TSVART is assigned to Joerg Ott |
2017-10-11
|
06 | Martin Stiemerling | Request for Last Call review by TSVART is assigned to Joerg Ott |
2017-10-11
|
06 | Martin Stiemerling | Request for Last Call review by TSVART is assigned to Colin Perkins |
2017-10-11
|
06 | Martin Stiemerling | Request for Last Call review by TSVART is assigned to Colin Perkins |
2017-10-10
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-10-10
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2017-10-24): From: The IESG To: IETF-Announce CC: tomasz.mrugalski@gmail.com, dhc-chairs@ietf.org, Tomek Mrugalski , draft-ietf-dhc-relay-port@ietf.org, … The following Last Call announcement was sent out (ends 2017-10-24): From: The IESG To: IETF-Announce CC: tomasz.mrugalski@gmail.com, dhc-chairs@ietf.org, Tomek Mrugalski , draft-ietf-dhc-relay-port@ietf.org, dhcwg@ietf.org, suresh@kaloom.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Generalized UDP Source Port for DHCP Relay) to Proposed Standard The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Generalized UDP Source Port for DHCP Relay' 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 2017-10-24. 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 proposes an extension to the DHCP protocols that allows a relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-10-10
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-10-10
|
06 | Suresh Krishnan | Last call was requested |
2017-10-10
|
06 | Suresh Krishnan | Ballot approval text was generated |
2017-10-10
|
06 | Suresh Krishnan | Ballot writeup was generated |
2017-10-10
|
06 | Suresh Krishnan | IESG state changed to Last Call Requested from AD Evaluation |
2017-10-10
|
06 | Suresh Krishnan | Last call announcement was generated |
2017-08-28
|
06 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-06.txt |
2017-08-28
|
06 | (System) | New version approved |
2017-08-28
|
06 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-08-28
|
06 | Naiming Shen | Uploaded new revision |
2017-07-20
|
05 | Ralf Weber | Request for Early review by INTDIR Completed: Ready with Nits. Reviewer: Ralf Weber. Sent review to list. |
2017-07-03
|
05 | Bernie Volz | Request for Early review by INTDIR is assigned to Ralf Weber |
2017-07-03
|
05 | Bernie Volz | Request for Early review by INTDIR is assigned to Ralf Weber |
2017-07-02
|
05 | Suresh Krishnan | Requested Early review by INTDIR |
2017-07-02
|
05 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2017-06-23
|
05 | Tomek Mrugalski | Write up for draft-ietf-dhc-relay-port-05.txt: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why … Write up for draft-ietf-dhc-relay-port-05.txt: (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? Standards track. This is the proper type because it defines new DHCPv4 and DHCPv6 options. Both require standards track. (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 specifies an optional mechanism that lets the DHCPv4 and DHCPv6 relays to use different UDP ports than the standard ones, defined in RFC2131 and RFC3315. Working Group Summary: This document has been presented in Berlin (IETF'96) and adopted in Oct. 2016. Even though the concept is very simple, there was an healthy discussion before it went through a successful WLGC in April 2017. Document Quality: I found 72 posts to DHC related to this draft (note it was named client-port in its individual submission phase). There was never any opposition to the concept, just couple improvement areas that were addressed. This has been reviewed by a number of interested and knowledgable people. Personnel: Tomek Mrugalski is the document shepherd. Suresh Krishnan is the current responsible AD. (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 reviewed this document late in its life cycle (-05) and I had no specific comments. The concept is simple and well explained, the option formats and their usage is well defined. The option formats follow RFC7227. This document is ready for publication in my opinion. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No, this document has had sufficient 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. (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. The document is good as written, it is useful and I'm aware of at least two implementations that have implemented this. (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? Yes, both authors confirmed in writing that they are not aware of any IPR claims related to this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (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? There is a consensus behind thid document. Several well known DHC experts and a few newcomers reviewed this draft and expressed support for this. This is a minor extension that affects only those who chose to deploy it. As such, people not interested were passive, but not objected. (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. (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. There are none. (The one reported by idnits tool about the publication date being 49 days in the past is a non-issue.) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such review needed. (13) Have all references within this document been identified as either normative or informative? Yes. (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. (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. No. (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. No. This document extends, but not updates RFC2131 and RFC3315. This is an optional extension. Vendors are free to not implement this if they chose so. Therefore it does not update the base spec RFCs. (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). This draft defines one new DHCPv4 and one new DHCPv6 option. All IANA actions are well defined and the registries to be updated are properly identified. (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. There are no new IANA registries requested by this draft. (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 parts to the document. |
2017-06-23
|
05 | Tomek Mrugalski | Responsible AD changed to Suresh Krishnan |
2017-06-23
|
05 | Tomek Mrugalski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-06-23
|
05 | Tomek Mrugalski | IESG state changed to Publication Requested |
2017-06-23
|
05 | Tomek Mrugalski | IESG process started in state Publication Requested |
2017-06-23
|
05 | Tomek Mrugalski | Changed document writeup |
2017-06-13
|
05 | Tomek Mrugalski | Changed document writeup |
2017-06-13
|
05 | Tomek Mrugalski | Changed document writeup |
2017-04-28
|
05 | Tomek Mrugalski | Changed consensus to Yes from Unknown |
2017-04-28
|
05 | Tomek Mrugalski | Intended Status changed to Proposed Standard from None |
2017-04-28
|
05 | Tomek Mrugalski | Tomek disappearing for 2 weeks of vacation/business trip. Write-up expected mid May. |
2017-04-28
|
05 | Tomek Mrugalski | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-04-25
|
05 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-05.txt |
2017-04-25
|
05 | (System) | New version approved |
2017-04-25
|
05 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-04-25
|
05 | Naiming Shen | Uploaded new revision |
2017-04-18
|
04 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-04.txt |
2017-04-18
|
04 | (System) | New version approved |
2017-04-18
|
04 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-04-18
|
04 | Naiming Shen | Uploaded new revision |
2017-04-11
|
03 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-03.txt |
2017-04-11
|
03 | (System) | New version approved |
2017-04-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-04-11
|
03 | Naiming Shen | Uploaded new revision |
2017-04-05
|
02 | Tomek Mrugalski | Tag Other - see Comment Log cleared. |
2017-04-05
|
02 | Tomek Mrugalski | IETF WG state changed to In WG Last Call from WG Document |
2017-03-06
|
02 | Bernie Volz | The authors indicated on 3/6/2017 that they feel the -02 version is ready for WGLC. However, we want to get the seDHCPv6 WGLC started first, … The authors indicated on 3/6/2017 that they feel the -02 version is ready for WGLC. However, we want to get the seDHCPv6 WGLC started first, so this will need to wait a bit. |
2017-03-06
|
02 | Bernie Volz | Tag Other - see Comment Log set. |
2017-02-28
|
02 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-02.txt |
2017-02-28
|
02 | (System) | New version approved |
2017-02-28
|
02 | (System) | Request for posting confirmation emailed to previous authors: Naiming Shen , Enke Chen |
2017-02-28
|
02 | Naiming Shen | Uploaded new revision |
2017-01-06
|
01 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-01.txt |
2017-01-06
|
01 | (System) | New version approved |
2017-01-06
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Naiming Shen" , "Enke Chen" |
2017-01-06
|
01 | Naiming Shen | Uploaded new revision |
2016-12-09
|
00 | Tomek Mrugalski | Notification list changed to "Tomek Mrugalski" <tomasz.mrugalski@gmail.com> |
2016-12-09
|
00 | Tomek Mrugalski | Document shepherd changed to Tomek Mrugalski |
2016-10-27
|
00 | Bernie Volz | This document now replaces draft-shen-dhc-client-port instead of None |
2016-10-27
|
00 | Naiming Shen | New version available: draft-ietf-dhc-relay-port-00.txt |
2016-10-27
|
00 | (System) | WG -00 approved |
2016-10-27
|
00 | Naiming Shen | Set submitter to "Naiming Shen ", replaces to (none) and sent approval email to group chairs: dhc-chairs@ietf.org |
2016-10-27
|
00 | Naiming Shen | Uploaded new revision |