Draft: draft-ietf-capport-architecture

Commentary: A reviewer pointed out that Captive Portal and   were used interchangeably in the document . While we used Captive Network more frequently ,   aligns more closely with familiar use of the term . Further , other documents such as the API draft refer to the system as a whole as a   , which makes this change more aligned with them . 
   ,  writes : I think that this is clear : one is a network and the other a server . Review to see if the right choice is used throughout . point out that we assume a degree of mutual control over both .
Captive Network: A network which limits communication of attached
devices to restricted hosts until the user has satisfied Captive
Portal Conditions, after which access is permitted to a wider set of
hosts (typically the Internet).
Captive Portal: A network which limits communication of attached
devices to restricted hosts until the user has satisfied Captive
Portal Conditions, after which access is permitted to a wider set of
hosts (typically the Internet).
The User Equipment can store the last response it received from the
Captive Portal API as a cached view of its state within the Captive
Network.  This state can be used to determine whether its Captive
Portal Session is near expiry.  For example, the User Equipment might
compare a timestamp indicating when the session expires to the
current time.  Storing state in this way can reduce the need for
communication with the Captive Portal API.  However, it could lead to
the state becoming stale if the User Equipment's view of the relevant
conditions (byte quota, for example) is not consistent with the
Captive Portal API's.
The User Equipment can store the last response it received from the
Captive Portal API as a cached view of its state within the Captive
Portal.  This state can be used to determine whether its Captive
Portal Session is near expiry.  For example, the User Equipment might
compare a timestamp indicating when the session expires to the
current time.  Storing state in this way can reduce the need for
communication with the Captive Portal API.  However, it could lead to
the state becoming stale if the User Equipment's view of the relevant
conditions (byte quota, for example) is not consistent with the
Captive Portal API's.
The Provisioning Service is primarily responsible for providing a
Captive Portal API URI to the User Equipment when it connects to the
network, and later if the URI changes.  The provisioning service
could also be the same service which is responsible for provisioning
the User Equipment for access to the Captive Network (e.g., by
providing it with an IP address).  This section discusses two
mechanisms which may be used to provide the Captive Portal API URI to
the User Equipment.
The Provisioning Service is primarily responsible for providing a
Captive Portal API URI to the User Equipment when it connects to the
network, and later if the URI changes.  The provisioning service
could also be the same service which is responsible for provisioning
the User Equipment for access to the Captive Portal (e.g., by
providing it with an IP address).  This section discusses two
mechanisms which may be used to provide the Captive Portal API URI to
the User Equipment.
The following diagram shows the communication between each component
in the case where the Captive Network has a User Portal, and the User
Equipment chooses to visit the User Portal in response to discovering
and interacting with the API Server.
The following diagram shows the communication between each component
in the case where the Captive Portal has a User Portal, and the User
Equipment chooses to visit the User Portal in response to discovering
and interacting with the API Server.
The Captive Network MUST associate the User Equipment with an
identifier that is unique among the User Equipment that are
interacting with the Captive Network at that time.
The Captive Portal MUST associate the User Equipment with an
identifier that is unique among the User Equipment that are
interacting with the Captive Portal at that time.
This section describes a possible workflow when User Equipment
initially joins a Captive Network.
This section describes a possible workflow when User Equipment
initially joins a Captive Portal.