Draft: draft-ietf-capport-architecture

Commentary: Happy to elaborate on them if the motivation is not clear from the changes , let me know ! 
 Thanks accepts the suggestion . corrects the mistake I had made , which your question was about . 
 Looks great . Thanks for the PR !
This document aims to document consensus on the CAPPORT architecture.
DHCP or Router Advertisements, an optional signaling protocol, and an
HTTP API are used to provide the solution.  The role of Provisioning
Domains (PvDs) is described.
This document describes a CAPPORT architecture.  DHCP or Router
Advertisements, an optional signaling protocol, and an HTTP API are
used to provide the solution.  The role of Provisioning Domains
(PvDs) is described.
The architecture attempts to provide privacy, authentication, and
safety mechanisms to the extent possible.
The architecture attempts to provide confidentiality, authentication,
and safety mechanisms to the extent possible.
At this time we consider only devices with web browsers, with web
applications being the means of satisfying Captive Portal Conditions.
At this time we consider only devices with web browsers, with web
applications being the means of satisfying Captive Portal Conditions.
An example interactive User Equipment is a smart phone.
The purpose of a Captive Portal API is to permit a query of Captive
Portal state without interrupting the user.  This API thereby removes
the need for a device to perform clear-text "canary" HTTP queries to
check for response tampering.
The purpose of a Captive Portal API is to permit a query of Captive
Portal state without interrupting the user.  This API thereby removes
the need for User Equipment to perform clear-text "canary" HTTP
queries to check for response tampering.
This architecture expects the User Equipment to query the API when
the User Equipment attaches to the network and multiple times
thereafter.  Therefore the API MUST support multiple repeated queries
from the same User Equipment, returning the current state of
captivity for the equipment.
At minimum the API MUST provide: (1) the state of captivity and (2) a
URI for a browser to present the portal application to the user.  The
API SHOULD provide evidence to the caller that it supports the
present architecture.
This architecture expects the User Equipment to query the API when
the User Equipment attaches to the network and multiple times
thereafter.  Therefore the API MUST support multiple repeated queries
from the same User Equipment and return the state of captivity for
the equipment.
At minimum, the API MUST provide: (1) the state of captivity and (2)
a URI for the Captive Portal Server.  The API SHOULD provide evidence
to the caller that it supports the present architecture.
The API MUST use TLS for privacy and server authentication.  The
implementation of the API MUST ensure both privacy and integrity of
any information provided by or required by it.
The Captive Portal Enforcement component restricts network access to
User Equipment according to site-specific policy.  Typically User
Equipment is permitted access to a small number of services and is
denied general network access until it has performed some action.
The API MUST use TLS to ensure server authentication.  The
implementation of the API MUST ensure both confidentiality and
integrity of any information provided by or required by it.
The Captive Portal Enforcement component restrict the network access
of User Equipment according to site-specific policy.  Typically User
Equipment is permitted access to a small number of services and is
denied general network access until it satisfies the Captive Portal
Conditions.
User Equipment may send traffic to hosts blocked by the captive
network prior to the Enforcement device granting it access.  The
Enforcement Device rightly blocks or resets these requests.  However,
lacking a signal from the Enforcement Device or interaction with the
API server, the User Equipment can only guess at whether it is
captive.  Consequently, allowing the Enforcement Device to explicitly
signal to the User Equipment that the traffic is being blocked may
improve the user's experience.
An Enforcement Device may also want to inform the User Equipment of a
pending expiry of its access to the external network, so providing
the Enforcement Device the ability to preemptively signal may be
desirable.
User Equipment may send traffic to hosts blocked by the captive
network prior to the Enforcement device granting it access.  The
Enforcement Device rightly blocks or resets these requests.  However,
in the absence of a signal from the Enforcement Device or interaction
with the API server, the User Equipment can only guess at whether it
is captive.  Consequently, allowing the Enforcement Device to
explicitly signal to the User Equipment that the traffic is being
blocked may improve the user's experience.
An Enforcement Device may also want to notify the User Equipment of a
pending expiry of its access to the external network, so providing
the Enforcement Device the ability to preemptively signal may be
desirable.
The Captive Portal Enforcement function MAY send Captive Portal
Signals when disallowed User Equipment attempts to send to the
network.  These signals MUST be rate-limited to a configurable rate.
The Captive Portal Enforcement function MAY send Captive Portal
Signals when User Equipment that has not satisfied the Captive Portal
Conditions attempts to send traffic to the network.  These signals
MUST be rate-limited to a configurable rate.