Protocol Action: 'Captive-Portal Identification in DHCP / RA' to Proposed Standard (draft-wkumari-dhc-capport-16.txt)

The IESG <iesg-secretary@ietf.org> Wed, 30 September 2015 01:32 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Captive-Portal Identification in DHCP / RA' to Proposed Standard (draft-wkumari-dhc-capport-16.txt)
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150930013217.31734.22550.idtracker@ietfa.amsl.com>
Date: Tue, 29 Sep 2015 18:32:17 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-announce/M6LLuf-2t0nhtsiKX3bVnZ7JdNw>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Reply-To: ietf@ietf.org

The IESG has approved the following document:
- 'Captive-Portal Identification in DHCP / RA'
  (draft-wkumari-dhc-capport-16.txt) as Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/





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. Taken forward as an AD sponsored 
   it has had abundant review. been the inspiration for a BOF and generally
   received positive attention.

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.

Protocol Action: 'Captive-Portal Identification i… The IESG