Change:
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.
NAME , was the capport-pvd draft discussed during IETF 104? I don't see anything in the minutes.
NAME we did not specifically discuss the capport-pvd draft. I think that doesn'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.
NAME 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?
NAME
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.
NAME is this addressed in in the sense that the referenced doc covers it?
Yes. I think it is.

Discussion:
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. <del> 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. </del> <ins> 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. </ins> End-user devices can be notified of captivity with Captive Portal Signals in response to traffic.  This notification should work

2.2.2. <del> 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. </del> <ins> 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. </ins> The PvD security model provides secure binding between the information provided by the trusted Router Advertisement and the HTTPS server. <del> 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). </del> 2.3. The purpose of a Captive Portal API is to permit a query of Captive