Draft: draft-ietf-capport-architecture

Commentary: One of the reviewers had a bunch of nits . This addresses all of them in one commit . See The issue for the list of nits . 
  writes : Clarify to implementations of captive portals -"huge variety of preexisting portals and ... " Take the suggestion . Is it sufficient to just say " SHOULD have a non - spoofable mechanism ... " ? How about " ... the operating system could avoid updating the default route to a device on the captive  network until ... " Note : We 're changing MAY to could here to address  's review comment . This is a bit ambiguous . It 's meant to basically say : " Stop interacting with the API " . We canprobably rephrase to " If certificate validation fails , the User Equipment MUST NOT make any calls tothe API Server " . Remove HTTP Do it Do it The identifier . Will update . Fix it . Do it . Do it . 
 Working on this . Will have a PR up tomorrow . 
 LGTM . Some small tweaks suggested .
Implementations generally require a web server, some method to allow/
block traffic, and some method to alert the user.  Common methods of
alerting the user involve modifying HTTP or DNS traffic.
Implementations of captive portals generally require a web server,
some method to allow/block traffic, and some method to alert the
user.  Common methods of alerting the user in implementations prior
to this work involve modifying HTTP or DNS traffic.
NOT proceed with any of the behavior described above.
Here we discuss candidate mechanisms for provisioning the User
Equipment with the URI of the API to query captive portal state and
navigate the portal.
A standard for providing a portal URI using DHCP or Router
Advertisements is described in RFC7710bis.  The captive portal
architecture expects this URI to indicate the API described in
section_api.
NOT make any calls to the API server.
Here we discuss candidate mechanisms for provisioning the User
Equipment with the Captive Portal API URI to query captive portal
state and navigate the portal.
A standard for providing a Captive Portal API URI using DHCP or
Router Advertisements is described in RFC7710bis.  The captive portal
architecture expects this URI to indicate the API described in
section_api.
Although still a work in progress, I-D.pfister-capport-pvd proposes a
mechanism for User Equipment to be provided with PvD Bootstrap
Information containing the URI for the JSON-based API described in
section_api.
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.
Although still a work in progress, I-D.pfister-capport-pvd proposes a
mechanism for User Equipment to be provided with PvD Bootstrap
Information containing the URI for the API described in section_api.
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" (see app-
additional) queries to check for response tampering.
A good identifier does not lend itself to being easily spoofed.  At
no time should it be simple or straightforward for one User Equipment
to pretend to be another User Equipment, regardless of whether both
are active at the same time.  This property is particularly important
when the User Equipment is extended externally to devices such as
billing systems, or where the identity of the User Equipment could
imply liability.
A good identifier does not lend itself to being easily spoofed.  At
no time should it be simple or straightforward for one User Equipment
to pretend to be another User Equipment, regardless of whether both
are active at the same time.  This property is particularly important
when the User Equipment identifier is referenced externally by
devices such as billing systems, or where the identity of the User
Equipment could imply liability.
Whenever a new Portal URI is received by end User Equipment, it
SHOULD discard the old URI and use the new one for future requests to
the API.
Whenever a new Captive Portal API URI is received by end User
Equipment, it SHOULD discard the old URI and use the new one for
future requests to the API.