Draft: draft-ietf-capport-rfc7710bis

Commentary: 2 typos , and normalize the usage of hyphens ( captive - portal vs captive portal ) . We use no hyphen ( to match arch doc ) , except when referring to the option ( to match the registry ... ) [ Gahforthe_hyphens ] 2 typos , and normalize the usage of hyphens ( captive - portal vs captive portal ) . We use no hyphen ( to match arch doc ) , except when referring to the option ( to match the registry ... )
Paragraph (version A):
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 user can do
until the user has satified the Captive Portal conditions.
Paragraph (version A):
This document describes a DHCPv4 and DHCPv6 option and a Router
Advertisement (RA) option to inform clients that they are behind some
sort of captive-portal enforcement device, and that they will need to
satify the Captive Portal conditions 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 one component of a
standardized approach for hosts to interact with such portals.  While
this document defines how the network operator may convey the captive
portal API endpoint to hosts, the specific methods of satisfying and
interacting with the captive portal are out of scope of this
document.
Paragraph (version B):
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 user can do
until the user has satisfied the captive portal conditions.
Paragraph (version B):
This document describes a DHCPv4 and DHCPv6 option and a Router
Advertisement (RA) option to inform clients that they are behind some
sort of captive portal enforcement device, and that they will need to
satify the Captive Portal conditions 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 one component of a
standardized approach for hosts to interact with such portals.  While
this document defines how the network operator may convey the captive
portal API endpoint to hosts, the specific methods of satisfying and
interacting with the captive portal are 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.  Regardless
of how that mechanism operates, this document provides functionality
to allow the client 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
device and agree to an Acceptable Use Policy (AUP) and / or provide
billing information before they can access the Internet.  Regardless
of how that mechanism operates, this document provides functionality
to allow the client 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, 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):
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 A):
This document describes a DHCPv4 RFC2131 and DHCPv6 RFC8415 option
(Captive-Portal) and an IPv6 Router Advertisement (RA) RFC4861 option
that informs clients that they are behind a captive-portal
enforcement device and the API endpoint that the host can contact for
more information.
Paragraph (version B):
This document describes a DHCPv4 RFC2131 and DHCPv6 RFC8415 option
(Captive-Portal) and an IPv6 Router Advertisement (RA) RFC4861 option
that informs clients that they are behind a captive portal
enforcement device and the API endpoint that the host can contact for
more information.
Paragraph (version A):
However, as the operating systems and application(s) that make use of
this information know that they are connecting to a captive-portal
device (as opposed to intercepted connections where the OS/
application may not know that they are connecting to a captive portal
or hostile device) they can render the page in a sandboxed
environment and take other precautions, such as clearly labeling the
page as untrusted.  The means of sandboxing and user interface
presenting this information is not covered in this document - by its
nature it is implementation specific and best left to the application
and user interface designers.
Paragraph (version B):
However, as the operating systems and application(s) that make use of
this information know that they are connecting to a captive portal
device (as opposed to intercepted connections where the OS/
application may not know that they are connecting to a captive portal
or hostile device) they can render the page in a sandboxed
environment and take other precautions, such as clearly labeling the
page as untrusted.  The means of sandboxing and user interface
presenting this information is not covered in this document - by its
nature it is implementation specific and best left to the application
and user interface designers.