Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
draft-wkumari-dhc-capport-16
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-12-01
|
16 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-11-20
|
16 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-11-20
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-10-14
|
16 | (System) | Notify list changed from draft-wkumari-dhc-capport.shepherd@ietf.org, olafur@cloudflare.com, ebersman-ietf@dragon.net, draft-wkumari-dhc-capport.ad@ietf.org, draft-wkumari-dhc-capport@ietf.org, ted.lemon@nominum.com, steve.sheng@icann.org, warren@kumari.net to (None) |
2015-10-05
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-10-01
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-10-01
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-09-30
|
16 | (System) | RFC Editor state changed to EDIT |
2015-09-30
|
16 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-09-30
|
16 | (System) | Announcement was received by RFC Editor |
2015-09-29
|
16 | (System) | IANA Action state changed to In Progress |
2015-09-29
|
16 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-09-29
|
16 | Amy Vezza | IESG has approved the document |
2015-09-29
|
16 | Amy Vezza | Closed "Approve" ballot |
2015-09-29
|
16 | Amy Vezza | Ballot approval text was generated |
2015-09-29
|
16 | Joel Jaeggli | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-09-24
|
16 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2015-09-17
|
16 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for AD Go-Ahead |
2015-09-17
|
16 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-09-16
|
16 | Kathleen Moriarty | [Ballot comment] I find this paragraph a little confusing an think it could be a bit cleaner: "Devices and systems that automatically connect to … [Ballot comment] I find this paragraph a little confusing an think it could be a bit cleaner: "Devices and systems that automatically connect to an open network could potentially be tracked using the techniques described in this document (forcing the user to continually authenticate, or exposing their browser fingerprint). However, similar tracking can already be performed with the standard captive portal mechanisms, so this technique does not give the attackers more capabilities." I think just a variation of the second sentence is enough as this mechanism doesn't introduce any new tracking mechanism. Just stating that it is possible to track users from a network with a captive portal should be enough. As a side note, I know this is out of scope, it would be interesting as a user to understand policies of captive portals using this mechanism before selecting which to use. Maybe some set of registered policies that go in the URI for the future? |
2015-09-16
|
16 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2015-09-16
|
16 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2015-09-16
|
16 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2015-09-16
|
16 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-wkumari-dhc-capport-16. If any part of this review is inaccurate, please let us know. IANA … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-wkumari-dhc-capport-16. If any part of this review is inaccurate, please let us know. IANA has a question about one of the actions requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document, there are three actions which IANA must complete. First, in the BOOTP Vendor Extensions and DHCP Options subregistry of the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry located at: https://www.iana.org/assignments/bootp-dhcp-parameters/ a new option is to be defined as follows: Tag: [ TBD-at-Registration ] Name: Captive-Portal Data Length: Meaning: DHCP Captive Portal Option Reference: [ RFC-to-be ] IANA Question --> What should the entry for "Data Length" be for this option? Second, in the Option Codfes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at: https://www.iana.org/assignments/dhcpv6-parameters/ a new option code will be registered as follows: Value: [ TBD-at-Registration ] Description: OPTION_CAPTIVE_PORTAL Reference: [ RFC-to-be ] As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we have initiated the required Expert Review via a separate ticket. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, in the IPv6 Neighbor Discovery Option Formats subregistry of the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry locasted at: https://www.iana.org/assignments/icmpv6-parameters/ a new registration will be made as follows: Type: [ TBD-at-Registration ] Description: Captive Portal Option Reference: [ RFC-to-be ] |
2015-09-16
|
16 | Ben Campbell | [Ballot comment] There are lots of TBDs in the shepherd write up. Some are fairly important (i.e. the IPR questions) -- section 2: Are there … [Ballot comment] There are lots of TBDs in the shepherd write up. Some are fairly important (i.e. the IPR questions) -- section 2: Are there any rules about the nature of the uri? Scheme? Security? -- section 4, last paragraph: Would it make sense to have a stronger statement about TLS for privacy purposes, given that captive portals often ask for passwords? Also, It might be worth elaborating on the "assure users a portal is not malicious" part.. editorial: -- 4, last paragraph: "By handing out a URI using which is protected with TLS, ..." Looks like an editing error around "using which" |
2015-09-16
|
16 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2015-09-16
|
16 | Spencer Dawkins | [Ballot comment] Thank you for producing this draft. I hope the mechanism it describes is widely deployed. It's a small thing, but this draft uses … [Ballot comment] Thank you for producing this draft. I hope the mechanism it describes is widely deployed. It's a small thing, but this draft uses "authenticate" in the abstract, and "agree to an acceptable use policy (AUP) and / or provide billing information" in the Introduction, and then talks about "an authentication page" in section 2. Are all those synonyms, for those skilled in the art? If not, more consistency might be helpful, or perhaps adding a definition of "authenticate" that includes things like agreeing to an AUP. |
2015-09-16
|
16 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2015-09-15
|
16 | Benoît Claise | [Ballot comment] Nothing against the draft itself, but a reflection. I'm sure we all faced this issue: In an airport, with lots of WIFI networks, … [Ballot comment] Nothing against the draft itself, but a reflection. I'm sure we all faced this issue: In an airport, with lots of WIFI networks, we connect to each of them one by one, hoping for a free WIFI for a few minutes to exchange emails, and it takes a long time to "test" every network". I can envision the solution in the draft to be used to provide the list of all WIFI networks along with the associated portal page (after a quick DHCP request for each WIFI), to help me select my network. In this multi providers configuration, what is the incentive for the different captive portals to populate this field. All the providers want to attract customers to their portal, and show how great/cheap their services are. So not populating this field might trick me to believe that there is a direct connection to the Internet and influence my WIFI selection. Nits: - RA acronym in the abstract - AUP acronym - idnits complaints about the 'RFC2939' missing reference - remove ">" in "Captive portals are increasingly hijacking TLS connections to force > browsers to talk to the portal." . |
2015-09-15
|
16 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-09-15
|
16 | Stephen Farrell | [Ballot comment] Address literal URIs don't play well with https, do they? And using https here is desirable as credentials are likely to be sent. … [Ballot comment] Address literal URIs don't play well with https, do they? And using https here is desirable as credentials are likely to be sent. And while a 30x to a https URL can be used, that round-trip could allow for new points of attack, for an adversary not able to insert a DHCP response. (E.g. if the evntual https TLS endpoint is far from the WLAN, then the http URI could be more easily attacked.) Maybe you ought note this issue? Or... Why not send the URI and optionally the address? That way a standard CA could support https, and a client with no DNS could still be ok. Not sure if the client could benefit from standard URL de-referencing code though, so this may be a dumb idea. OTOH, you're already calling for special sandboxing of that (usually) web page, so maybe this could work? |
2015-09-15
|
16 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2015-09-14
|
16 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-09-14
|
16 | Alissa Cooper | [Ballot comment] Glad we got the document status thing sorted out. |
2015-09-14
|
16 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to Yes from Discuss |
2015-09-03
|
16 | David Black | Request for Last Call review by GENART Completed: Ready. Reviewer: David Black. |
2015-09-03
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
2015-09-03
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
2015-09-03
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hannes Tschofenig |
2015-09-03
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hannes Tschofenig |
2015-09-02
|
16 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Captive-Portal Identification in DHCP / RA) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Captive-Portal Identification in DHCP / RA) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Captive-Portal Identification in DHCP / RA' as Proposed Standard While the original last call went out correctly with a a 4 week peroid due to the standards action required for DHCP registration the last call erroneously stated that the status for which the draft was aiming was informational. The intended status is proposed standard. This additional last call intended to clarify that point runs for two weeks completing 9/17. 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 2015-09-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 In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a RA extension) to inform clients that they are behind some sort of captive portal device, and that they will need to authenticate to get Internet Access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to, and interacting with the captive portal is out of scope of this document. [ Ed note (remove): This document is being developed in github: https://github.com/wkumari/draft-wkumari-dhc-capport . ] The file can be obtained via https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-09-02
|
16 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-09-02
|
16 | Joel Jaeggli | Telechat date has been changed to 2015-09-17 from 2015-09-03 |
2015-09-02
|
16 | Joel Jaeggli | Last call was requested |
2015-09-02
|
16 | Joel Jaeggli | IESG state changed to Last Call Requested from IESG Evaluation |
2015-09-02
|
16 | Joel Jaeggli | Last call announcement was changed |
2015-09-02
|
16 | Joel Jaeggli | Last call announcement was generated |
2015-09-02
|
16 | Joel Jaeggli | Changed consensus to Yes from Unknown |
2015-09-02
|
16 | Joel Jaeggli | Intended Status changed to Proposed Standard from Informational |
2015-09-02
|
16 | Alissa Cooper | [Ballot discuss] Thanks for putting this together. The tracker lists this document's intended status as informational but the document header says it is intended to … [Ballot discuss] Thanks for putting this together. The tracker lists this document's intended status as informational but the document header says it is intended to be standards track. Which is it? |
2015-09-02
|
16 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2015-09-02
|
16 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-09-01
|
16 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-09-01
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-09-01
|
16 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: David Black. |
2015-09-01
|
16 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to David Black |
2015-09-01
|
16 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to David Black |
2015-08-31
|
16 | Warren Kumari | New version available: draft-wkumari-dhc-capport-16.txt |
2015-08-28
|
15 | David Black | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: David Black. |
2015-08-28
|
15 | Brian Haberman | [Ballot comment] I think you need to specify somewhere that the URIs are encoded following the rules in RFC 3986. |
2015-08-28
|
15 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2015-08-27
|
15 | Jean Mahoney | Request for Telechat review by GENART is assigned to David Black |
2015-08-27
|
15 | Jean Mahoney | Request for Telechat review by GENART is assigned to David Black |
2015-08-24
|
15 | Warren Kumari | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-08-24
|
15 | Warren Kumari | New version available: draft-wkumari-dhc-capport-15.txt |
2015-08-21
|
14 | Barry Leiba | [Ballot comment] At least some of the authors should know from earlier conversations that I very much support going ahead with this document. Just one … [Ballot comment] At least some of the authors should know from earlier conversations that I very much support going ahead with this document. Just one teeny comment: -- Section 2 -- In order to avoid having to perform DNS interception, the URI SHOULD contain an address literal, but MAY contain a DNS name if the captive portal allows the client to perform DNS requests to resolve the name. In my continuing effort to eradicate 2119-use problem #1: the SHOULD/but-MAY structure is a bad one; "SHOULD" is strong and "MAY" negates it. It's not really a problem here because your "if" constrains the scope of the "MAY", but I'd prefer it if you'd rephrase it something like this: NEW In order to avoid having to perform DNS interception, the URI SHOULD contain an address literal. If the captive portal allows the client to perform DNS requests to resolve the name, it is then acceptable for the URI to contain a DNS name. END Note that's "I'd prefer it"; if you disagree, that's the last you'll hear of it from me, and there's no need to discuss this point. |
2015-08-21
|
14 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2015-08-17
|
14 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-08-16
|
14 | Joel Jaeggli | IESG state changed to IESG Evaluation from Waiting for Writeup |
2015-08-16
|
14 | Joel Jaeggli | Ballot has been issued |
2015-08-16
|
14 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2015-08-16
|
14 | Joel Jaeggli | Created "Approve" ballot |
2015-08-16
|
14 | Joel Jaeggli | Ballot writeup was changed |
2015-08-16
|
14 | Joel Jaeggli | Placed on agenda for telechat - 2015-09-03 |
2015-08-13
|
14 | Warren Kumari | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2015-08-13
|
14 | Warren Kumari | New version available: draft-wkumari-dhc-capport-14.txt |
2015-07-13
|
13 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: David Black. |
2015-07-08
|
13 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Hannes Tschofenig. |
2015-07-07
|
13 | David Black | Request for Last Call review by GENART Completed: On the Right Track. Reviewer: David Black. |
2015-07-07
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-06-25
|
13 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-06-25
|
13 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-wkumari-dhc-capport-12. Please report any inaccuracies and respond to any questions as soon as possible. IANA has two … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-wkumari-dhc-capport-12. Please report any inaccuracies and respond to any questions as soon as possible. IANA has two questions and a couple of notes about the actions requested in this document's IANA Considerations section. NOTE: There appears to be a typo in the first sentence of the section: "This document defines two DHCP Captive-Portal options, one for IPv6 and one for IPv6." NOTE: The URLs should be replaced as follows: OLD: http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xml NEW: http://www.iana.org/assignments/bootp-dhcp-parameters OLD: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml NEW: http://www.iana.org/assignments/dhcpv6-parameters Should the extension change, the shorter names should still point to the registry. IANA understands that, upon approval of this document, there are three actions which need to be completed. First, in the Bootp and DHCP options registry under the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters heading at http://www.iana.org/assignments/bootp-dhcp-parameters a new option code is to be registered as follows: Tag: [ TBD ] Name: DHCP Captive-Portal Data Length: ? Meaning: DHCP Captive-Portal Reference: [ RFC-to-be ] QUESTION: How should we fill in the "Data Length" field? Second, in the Option Codes registry under the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) heading at http://www.iana.org/assignments/dhcpv6-parameters/ a new option code is to be registered as follows: Value: [ TBD-at-Registration ] Description: DHCP Captive-Portal Reference: [ RFC-to-be ] This request has been approved by the registry's designated expert. Third, in the IPv6 Neighbor Discovery Option Formats registry under the Internet Control Message Protocol version 6 (ICMPv6) Parameters heading at https://www.iana.org/assignments/icmpv6-parameters/ the authors write, "IANA is also requested to assign an IPv6 RA Option Type code (TBA3) from the 'IPv6 Neighbor Discovery Option Formats' registry." QUESTION: Would this registration be correct? The entry for the "description" field isn't clear. Type: [ TBD ] Description: IPv6 RA Option Type Reference: [ RFC-to-be] IANA understands that these three 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. |
2015-06-18
|
13 | Warren Kumari | New version available: draft-wkumari-dhc-capport-13.txt |
2015-06-12
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
2015-06-12
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
2015-06-12
|
12 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Withdrawn' |
2015-06-11
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2015-06-11
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2015-06-11
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Black |
2015-06-11
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Black |
2015-06-10
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hannes Tschofenig |
2015-06-10
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hannes Tschofenig |
2015-06-09
|
12 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-06-09
|
12 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Captive-Portal identification in DHCP / RA) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Captive-Portal identification in DHCP / RA) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Captive-Portal identification in DHCP / RA' as Informational RFC - The document got extensive review in DHC OPSAWG and elsewhere prior to the decision to AD-sponsor the draft. An informal BOF was held and a mailing list subsequently created to continue to explore the problem space more generally https://www.ietf.org/mailman/listinfo/captive-portals - 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 2015-07-07. 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 In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a RA extension) to inform clients that they are behind some sort of captive portal device, and that they will need to authenticate to get Internet Access. The file can be obtained via https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-06-09
|
12 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-06-09
|
12 | Amy Vezza | Last call announcement was changed |
2015-06-08
|
12 | Joel Jaeggli | Last call was requested |
2015-06-08
|
12 | Joel Jaeggli | Ballot approval text was generated |
2015-06-08
|
12 | Joel Jaeggli | Ballot writeup was generated |
2015-06-08
|
12 | Joel Jaeggli | IESG state changed to Last Call Requested from AD Evaluation |
2015-06-08
|
12 | Joel Jaeggli | Last call announcement was changed |
2015-06-08
|
12 | Joel Jaeggli | Last call announcement was generated |
2015-04-19
|
12 | Joel Jaeggli | IESG state changed to AD Evaluation from Publication Requested |
2015-03-25
|
12 | Ted Lemon | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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 document extends DHCP and Neighbor Discovery by adding new configuration-information-carrying options, and contains an applicability statement. (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 describes a DHCP option and an RA extension to inform nodes that they are behind some sort of captive portal device, and that they will need to authenticate to get Internet Access. Working Group Summary This document was reviewed by the DHC working group, but was not adopted there because the work is not in charter. Because it defines new DHCP options, it's not really in charter for 6man either. Document Quality Dan Lüdtke has done an implementation of the router side of the RA option. We are aware of no RA listener implementations nor DHCP client implementations. Because this document defines DHCP options, any generally-configurable DHCP server or client can readily be configured to support this new option, typically without recompilation. The option question for this document is whether captive portal manufacturers and, more importantly, DHCP client implementors and RA listener implementors will see the extension as valuable and make use of it. The reason for advancing it at this stage rather than waiting for widespread adoption is that until a standard format is defined, the extension serves no useful purpose and cannot be deployed. By documenting this extension, we hope to provide an opportunity for improvement in the way captive portals are operated. Personnel Ted Lemon is the document shepherd. Joel Jaeggli is the 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 have read this document and suggested changes to the author, who has addressed the concerns I raised. I believe the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? --tbd-- (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. The DHC working group has reviewed the document, and I've also reviewed it for correctness. (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 interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I think there is a potential need for this document. It's possible that no client implementors will adopt it, but I think it's worth the risk, since without this document, we can be certain that no mechanism of this sort will ever be adopted. (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. --tbd-- (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. --tbd-- (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There seems to be some concurrence that this proposal is worth trying. I would not describe the support for it as broad, but I don't think it needs to be, since at worst the document is harmless, and at best it's potentially useful. (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.) The worst negative comment was along the lines of "isn't this solved by 802.11u?" The person who made the comment has not expressed any intention to stand in the way of advancing the document, nor even an indication that he personally is against advancing it. (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. --tbd-- (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. --tbd-- (13) Have all references within this document been identified as either normative or informative? --tbd-- (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? --tbd-- (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. There are no 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 interested community considers it unnecessary. No. (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 document creates no new registries. --tbd-- modulo edits --tbd-- The IANA registry section appears to be correct. (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. None. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no such checks required for this document. |
2015-03-25
|
12 | Ted Lemon | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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 document extends DHCP and Neighbor Discovery by adding new configuration-information-carrying options, and contains an applicability statement. (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 describes a DHCP option and an RA extension to inform nodes that they are behind some sort of captive portal device, and that they will need to authenticate to get Internet Access. Working Group Summary This document was reviewed by the DHC working group, but was not adopted there because the work is not in charter. Because it defines new DHCP options, it's not really in charter for 6man either. Document Quality Dan Lüdtke has done an implementation of the router side of the RA option. We are aware of no RA listener implementations nor DHCP client implementations. Because this document defines DHCP options, any generally-configurable DHCP server or client can readily be configured to support this new option, typically without recompilation. The option question for this document is whether captive portal manufacturers and, more importantly, DHCP client implementors and RA listener implementors will see the extension as valuable and make use of it. The reason for advancing it at this stage rather than waiting for widespread adoption is that until a standard format is defined, the extension serves no useful purpose and cannot be deployed. By documenting this extension, we hope to provide an opportunity for improvement in the way captive portals are operated. Personnel Ted Lemon is the document shepherd. Joel Jaeggli is the 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 have read this document and suggested changes to the author, who has addressed the concerns I raised. I believe the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? --tbd-- (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. The DHC working group has reviewed the document, and I've also reviewed it for correctness. (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 interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I think there is a potential need for this document. It's possible that no client implementors will adopt it, but I think it's worth the risk, since without this document, we can be certain that no mechanism of this sort will ever be adopted. (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. --tbd-- (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. --tbd-- (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There seems to be some concurrence that this proposal is worth trying. I would not describe the support for it as broad, but I don't think it needs to be, since at worst the document is harmless, and at best it's potentially useful. (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.) The worst negative comment was along the lines of "isn't this solved by 802.11u?" The person who made the comment has not expressed any intention to stand in the way of advancing the document, nor even an indication that he personally is against advancing it. (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. --tbd-- (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. --tbd-- (13) Have all references within this document been identified as either normative or informative? --tbd-- (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? --tbd-- (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. There are no 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 interested community considers it unnecessary. No. (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 document creates no new registries. --tbd-- modulo edits --tbd-- The IANA registry section appears to be correct. (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. None. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no such checks required for this document. |
2015-03-04
|
12 | Warren Kumari | New version available: draft-wkumari-dhc-capport-12.txt |
2015-03-04
|
11 | Ted Lemon | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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 document extends DHCP and Neighbor Discovery by adding new configuration-information-carrying options, and contains an applicability statement. (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 describes a DHCP option and an RA extension to inform nodes that they are behind some sort of captive portal device, and that they will need to authenticate to get Internet Access. Working Group Summary This document was reviewed by the DHC working group, but was not adopted there because the work is not in charter. Because it defines new DHCP options, it's not really in charter for 6man either. Document Quality There are no existing implementations. However, because this document defines DHCP options, any generally-configurable DHCP server or client can readily be configured to support this new option, typically without recompilation. The option question for this document is whether captive portal manufacturers and, more importantly, DHCP client implementors and RA listener implementors will see the extension as valuable and make use of it. The reason for advancing it at this stage rather than waiting for widespread adoption is that until a standard format is defined, the extension serves no useful purpose and cannot be deployed. By documenting this extension, we hope to provide an opportunity for improvement in the way captive portals are operated. Personnel Ted Lemon is the document shepherd. Joel Jaeggli is the 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 have read this document and suggested changes to the author, who has addressed the concerns I raised. I believe the document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? --tbd-- (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. The DHC working group has reviewed the document, and I've also reviewed it for correctness. (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 interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I think there is a potential need for this document. It's possible that no client implementors will adopt it, but I think it's worth the risk, since without this document, we can be certain that no mechanism of this sort will ever be adopted. (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. --tbd-- (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. --tbd-- (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There seems to be some concurrence that this proposal is worth trying. I would not describe the support for it as broad, but I don't think it needs to be, since at worst the document is harmless, and at best it's potentially useful. (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.) The worst negative comment was along the lines of "isn't this solved by 802.11u?" The person who made the comment has not expressed any intention to stand in the way of advancing the document, nor even an indication that he personally is against advancing it. (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. --tbd-- (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. --tbd-- (13) Have all references within this document been identified as either normative or informative? --tbd-- (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? --tbd-- (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. There are no 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 interested community considers it unnecessary. No. (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 document creates no new registries. --tbd-- modulo edits --tbd-- The IANA registry section appears to be correct. (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. None. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no such checks required for this document. |
2015-02-16
|
11 | Joel Jaeggli | IESG process started in state Publication Requested |
2015-02-16
|
11 | Joel Jaeggli | Shepherding AD changed to Joel Jaeggli |
2015-02-16
|
11 | Joel Jaeggli | Intended Status changed to Informational from None |
2015-02-16
|
11 | Joel Jaeggli | Notification list changed to "Ted Lemon" <ted.lemon@nominum.com> |
2015-02-16
|
11 | Joel Jaeggli | Document shepherd changed to Ted Lemon |
2015-02-16
|
11 | Joel Jaeggli | IETF WG state changed to Submitted to IESG for Publication |
2015-02-16
|
11 | Joel Jaeggli | Stream changed to IETF from None |
2015-01-30
|
11 | Warren Kumari | New version available: draft-wkumari-dhc-capport-11.txt |
2015-01-28
|
10 | Warren Kumari | New version available: draft-wkumari-dhc-capport-10.txt |
2015-01-27
|
09 | Warren Kumari | New version available: draft-wkumari-dhc-capport-09.txt |
2015-01-27
|
08 | Warren Kumari | New version available: draft-wkumari-dhc-capport-08.txt |
2014-12-22
|
07 | Warren Kumari | New version available: draft-wkumari-dhc-capport-07.txt |
2014-12-02
|
06 | Warren Kumari | New version available: draft-wkumari-dhc-capport-06.txt |
2014-09-08
|
05 | Warren Kumari | New version available: draft-wkumari-dhc-capport-05.txt |
2014-07-04
|
04 | Warren Kumari | New version available: draft-wkumari-dhc-capport-04.txt |
2014-06-02
|
03 | Warren Kumari | New version available: draft-wkumari-dhc-capport-03.txt |
2014-04-16
|
02 | Warren Kumari | New version available: draft-wkumari-dhc-capport-02.txt |
2014-01-23
|
01 | Warren Kumari | New version available: draft-wkumari-dhc-capport-01.txt |
2014-01-13
|
00 | Warren Kumari | New version available: draft-wkumari-dhc-capport-00.txt |