Draft: draft-ekwk-capport-rfc7710bis

Commentary: Trying to improve clarity and alignment with the architecture document . 
 Thank you very much , especially for sending as a pull request !
Paragraph (version A):
This document describes a DHCP option (and a Router Advertisement
(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.
Paragraph (version B):
This document describes a DHCP option (and a Router Advertisement
(RA) extension) to inform clients that they are behind some sort of
captive-portal enforcement 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.
Paragraph (version A):
In many environments, users need to connect to a captive-portal
device and agree to an Acceptable Use Policy (AUP) and / or provide
billing information before they can access the Internet.  It is
anticipated that the IETF will work on a more fully featured protocol
at some point, to ease interaction with Captive Portals.  Regardless
of how that protocol operates, it is expected that this document will
provide needed functionality because the client will need to know
when it is behind a captive portal and how to contact it.
Paragraph (version B):
In many environments, users need to connect to a captive-portal
server and agree to an Acceptable Use Policy (AUP) and / or provide
billing information before they can access the Internet.  It is
anticipated that the IETF will work on a more fully featured protocol
at some point, to ease interaction with Captive Portals.  Regardless
of how that protocol operates, it is expected that this document will
provide needed functionality because the client will need to know
when it is behind a captive portal and how to contact it.
Paragraph (version A):
In order to present users with the payment or AUP pages, the captive-
portal device has to intercept the user's connections and redirect
the user to the captive portal, using methods that are very similar
to man-in-the-middle (MITM) attacks.  As increasing focus is placed
on security, and end nodes adopt a more secure stance, these
interception techniques will become less effective and/or more
intrusive.
Paragraph (version A):
This document describes a DHCP (RFC2131) option (Captive-Portal) and
an IPv6 Router Advertisement (RA) (RFC4861) extension that informs
clients that they are behind a captive-portal device and how to
contact it.
Paragraph (version B):
In order to present users with the payment or AUP pages, presently a
captive-portal enforcement device has to intercept the user's
connections and redirect the user to a captive portal server, using
methods that are very similar to man-in-the-middle (MITM) attacks.
As increasing focus is placed on security, and end nodes adopt a more
secure stance, these interception techniques will become less
effective and/or more intrusive.
Paragraph (version B):
This document describes a DHCP (RFC2131) option (Captive-Portal) and
an IPv6 Router Advertisement (RA) (RFC4861) extension that informs
clients that they are behind a captive-portal enforcement device and
how to contact an API for more information.
Paragraph (version A):
The Captive Portal DHCP / RA Option informs the client that it may be
behind a captive portal and provides the URI to access an API as
defined by [draft-ietf-capport-api].  This is primarily intended to
improve the user experience by getting them to the captive portal
faster and more reliably.  Note that, for the foreseeable future,
captive portals will still need to implement the interception
techniques to serve legacy clients, and clients will need to perform
probing to detect captive portals.
Paragraph (version B):
The Captive Portal DHCP / RA Option informs the client that it may be
behind a captive portal and provides the URI to access an API as
defined by [draft-ietf-capport-api].  This is primarily intended to
improve the user experience by showing the user the captive portal
information faster and more reliably.  Note that, for the foreseeable
future, captive portals will still need to implement the interception
techniques to serve legacy clients, and clients will need to perform
probing to detect captive portals.
Paragraph (version A):
In order to support multiple "classes" of clients (e.g.  IPv4 only,
IPv6 only with DHCPv6 (RFC3315), IPv6 only with RA) the captive
portal can provide the URI via multiple methods (IPv4 DHCP, IPv6
DHCP, IPv6 RA).  The captive portal operator SHOULD ensure that the
URIs handed out are equivalent to reduce the chance of operational
problems.  The maximum length of the URI that can be carried in IPv4
DHCP is 255 bytes, so URIs longer than 255 bytes should not be used
in IPv6 DHCP or IPv6 RA.
Paragraph (version A):
In all variants of this option, the URI MUST be that of the captive
portal API endpoint, conforming to the recommendations for such URIs
[draft-ietf-capport-api] (i.e. the URI SHOULD contain a DNS name and
SHOULD reference a secure transport, e.g. https).
Paragraph (version A):
A captive portal MAY redirect requests that do not have an Accept
header field (RFC7231 Section 5.3) containing a field item whose
content-type is "application/capport+json" to the URL conveyed in the
"user-portal-url" API key.  When performing such content negotiation
(RFC7231 Section 3.4), captive portals need to keep in mind that such
responses might be cached, and therefore SHOULD include an
appropriate Vary header field (RFC7231 Section 7.1.4) or mark them
explicitly uncacheable (for example, using Cache-Control: no-store
RFC7234 Section 5.2.2.3).
Paragraph (version B):
In order to support multiple "classes" of clients (e.g.  IPv4 only,
IPv6 only with DHCPv6 (RFC3315), and IPv6 only with RA) the captive
network can provision the client with the URI via multiple methods
(IPv4 DHCP, IPv6 DHCP, and IPv6 RA).  The captive portal operator
SHOULD ensure that the URIs provisioned by each method are equivalent
to reduce the chance of operational problems.  The maximum length of
the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer
than 255 bytes should not be provisioned via IPv6 DHCP or IPv6 RA
either.
Paragraph (version B):
In all variants of this option, the URI MUST be that of the captive
portal API endpoint, conforming to the recommendations for such URIs
[draft-ietf-capport-api].
Paragraph (version B):
A captive portal server MAY redirect requests that do not have an
Accept header field (RFC7231 Section 5.3) containing a field item
whose content-type is "application/capport+json" to the URL conveyed
in the "user-portal-url" API key.  When performing such content
negotiation (RFC7231 Section 3.4), captive portals implementors need
to keep in mind that such responses might be cached, and therefore
SHOULD include an appropriate Vary header field (RFC7231
Section 7.1.4) or mark them explicitly uncacheable (for example,
using Cache-Control: no-store RFC7234 Section 5.2.2.3).
Paragraph (version A):
The URI SHOULD NOT contain an IP address literal.  The URI parameter
is not null terminated.
Paragraph (version B):
The URI SHOULD NOT contain an IP address literal.
Paragraph (version B):
Note that the URI parameter is not guaranteed to be null terminated.
Paragraph (version A):
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.
Paragraph (version B):
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 presently common captive portal mechanisms, so
this technique does not give the attackers more capabilities.