Draft: draft-ietf-capport-architecture

Commentary: We were incorrectly describing the behaviour of the capport PvD option . Update the text to better reflect how it will work , and reference the new draft describing that behaviour . This removes most of the section describing the behaviour , since it 's now in the new draft . Fixes Issue . 
 Let 's talk about adoption of the capport - pvd draft before we make this sort of change . 
 , was the capport - pvd draft discussed during IETF 104 ? I do n't see anything in the minutes . 
 we did not specifically discuss the capport - pvd draft . I think that does n't need to be in this first core flight of docs . Note we 'll be discussing the core PvD doc more in intarea and hopefully will get that out to last call . 
 Alright . The existing content is still wrong , though . So , to fix this , perhaps we should just remove the references to PvDs in general ? 
 This text incorrectly describes the PvD JSON as the API JSON . This is incorrect . We should also refer to the CAPPORT PvD proposal document which explains this . 
 anything left for this please ? 
 Seems fine to me to close 
 Does PvD mechanism deliver the capport state , or a pointer to the capport API , from which capport state is retrieved ? 
 In IETF101 capport meeting , I think I heard that PvD is not designed for conveying per - UE state . Hence , PvD may provide a URI to the capport API , but not convey the state itself . 
 is this addressed in in the sense that the referenced doc covers it ? 
 Yes . I think it is .
Network provisioning protocols provide end-user devices with a URI
for the API that end-user devices query for information about what
is required to escape captivity.  DHCP, DHCPv6, and Router-
Advertisement options for this purpose are available in RFC7710.
Other protocols (such as RADIUS), Provisioning Domains I-D.ietf-
intarea-provisioning-domains, or static configuration may also be
used.  A device MAY query this API at any time to determine
whether the network is holding the device in a captive state.
Network provisioning protocols provide end-user devices with a URI
for the API that end-user devices query for information about what
is required to escape captivity.  DHCP, DHCPv6, and Router-
Advertisement options for this purpose are available in RFC7710.
Other protocols (such as RADIUS), Provisioning Domains I-
D.pfister-capport-pvd, or static configuration may also be used.
A device MAY query this API at any time to determine whether the
network is holding the device in a captive state.
I-D.ietf-intarea-provisioning-domains proposes a mechanism for User
Equipment to be provided with PvD Bootstrap Information containing
the URI for a JSON file containing key-value pairs to be downloaded
over HTTPS.  This JSON file would fill the role of the Captive Portal
API described in section_api.
One key-value pair can be used to indicate the network has restricted
access, requiring captive portal navigation by a user.  E.g.,
key="captivePortal" and value=<URI of portal>.  The key-value pair
should provide a different result when access is not restricted.
E.g., key="captivePortal" and value="".
This JSON file is extensible, allowing new key-value pairs to
indicate such things as network access expiry time, URI for API
access by IOT devices, etc.
The PvD server MUST support multiple (repeated) queries from each
User Equipment, always returning the current captive portal
information.  The User Equipment is expected to make this query upon
receiving (and validating) a Captive Portal Signal (see
section_signal).
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.