2.2. <del> This YANG module imports modules from RFC6991, RFC8348, and I-D.ietf- netconf-crypto-types. </del>  3. 5.  Changes from version 00 to version 01: Addressed author's comments

Allows the YANG model changes I have suggested to be merged into the overall document
There are several issues with the current YANG model. I am grouping them as one as I have a single YANG model pull request to cover all of these. The issues I believe need to be addressed include: (1) PCR numbers should be their own type, not a UINT8. PCRs should be limited to [0..31] (2) We should use ENUMs instead of strings for TCG and IETF crypto algorithm types. Strings allow lots of errors to be introduced which we can protect using a larger, more detailed ENUM construct. (3) Most devices do not have multiple line cards. Because of that, we should not have nested keys of [node id] [tpm name]. This adds unnecessary complexity for the vast majority of users. Instead the tpm should have a mandatory leafref back to node-id when compute-nodes is not null. (4) The YANG doctors will not let us have a TPM-Name of "ALL". Instead of "ALL" we should be able to assume that an RPC means all hardware based TPMs if a specific TPM is not named in the RPC. Note that this means that we should not use TPM-name as a KEY in any RPC. (5) We should add leaf for a unique TPM-Path. It might be claimed this is irrelevant with the existing key structure, but likely the YANG model itself will learn the TPM this way after boot. You could add/remove/migrate new virtual TPMs, more easily only re-allocating an existing path when the new vTPM is activated. (6) We should have optional YANG features for TPM1.2 and TPM2.0 so that RPCs are not exposed when there are no such TPMs of that type are supported. (7) We should great new grouping for the log algorithm types. These groupings can be reused for a Telemetry/Subscription feed of individual log entries. Other log types like those proposed for "netequip boot" by Bin Cao can then be merged.
I placed this as a separate issue from the Pull Request as almost all issues are addressed in the pull request. For (2), I only added some of the relevant ENUMs. Others will be added should people agree with the direction of the pull request.
Based on some feedback, made the following changes: (8) Removed 'TPM-path' as a unique identifier for RPCs. Instead 'certificate-name' is used. This allows for a cleaner certificate migration path, and won't have issues with reboots. (9) Extracted into a group TPM2ALGID
Other issues included in latest proposal: (10) Separate out crypto-algorithm types into a separate draft (11) Not much reason in building choices for IETF algorithm types when the TPMs need to follow TCG types. (12) Leafrefs for certificate datastores should simplify the storage of this information should people not want to create separate structures.
We should separate 10 into its own issue. The current model doesn't break it out into its own draft. Let's publish the next charra version as including both within this draft. Doing so will allow us to ask the WG the question at the next IETF.
Because these TCG-defined algorithm types are only used by CHARRA now, so I think this strong relationship makes it OK that leaving the crypto-algorithm types in CHARRA.
Especially for the upcoming review phase this is fine. Long term, we have to understand how maintenance of the alg document will work. When the TCG registry changes, only the alg module in this doc has to be updated. Do we have to update the whole doc? Do we split out only the alg module? Maybe that is a reason to split it out now. I am not sure that we know today (at least I don't) and we should find out. Let's drive a thorough review cycle before the upcoming meeting and then bring this topic up in a discussion at the virtual meeting itself.
Thanks!

2.2.  <ins> 2.2.1. This YANG module imports modules from RFC6991, RFC8348, I-D.ietf- netconf-crypto-types, ietf-asymmetric-algs.yang. 2.3. Cryptographic algorithm types were initially included within -v14 NETCONF's iana-crypto-types.yang.  Unfortunately all this content including the algorithms needed here failed to make the -v15 used WGLC.  Therefore a modified version of this draft is included here. Perhaps someone will steward this list as a separate draft. </ins> 3. 5. <ins> Changes from version 01 to version 02: Extracted Crypto-types into a separate YANG file Mades the algorithms explicit, not strings Hash Algo as key the selected TPM2 PCRs PCR numbers are their own type Eliminated nested keys for node-id plus tpm-name Eliminated TPM-Name of "ALL" Added TPM-Path </ins> Changes from version 00 to version 01: Addressed author's comments


how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping.  1. Bootstrapping Remote Secure Key Infrastructures (BRSKI) I-D.ietf- For example, the pledge may only be aware of its IDevID Subject which includes a manufacturer serial number, but must include a specific fully qualified domain name in the CSR in order to complete domain <del> ownership proofs required by the CA.  As another example, the registrar may deem the manufacturer serial number in an IDevID as personally identifiable information, and may want to specify a new random opaque identifier that the pledge should use in its CSR. </del>  3. The cloud registrar returned a voucher to the pledge.  The pledge should perform voucher verification as per standard BRSKI operation. The pledge should verify the voucher signature using the <del> manufacturer-installed trust anchor(s). should verify the serial </del>  number in teh voucher, and must verify any nonce information in the voucher.

This should be a do-nothing change to the content, which just starts every sentence on fresh line. This aids greatly in reading diffs. One paragraph break added, and one period changed to a dot. And I seem to have included the IEEE reference fix by mistake.

how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. <ins> RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud </ins> 1. Bootstrapping Remote Secure Key Infrastructures (BRSKI) I-D.ietf- For example, the pledge may only be aware of its IDevID Subject which includes a manufacturer serial number, but must include a specific fully qualified domain name in the CSR in order to complete domain  <ins> ownership proofs required by the CA. As another example, the registrar may deem the manufacturer serial number in an IDevID as personally identifiable information, and may want to specify a new random opaque identifier that the pledge should use in its CSR. </ins> 3. The cloud registrar returned a voucher to the pledge.  The pledge should perform voucher verification as per standard BRSKI operation. The pledge should verify the voucher signature using the  <ins> manufacturer-installed trust anchor(s), should verify the serial </ins> number in teh voucher, and must verify any nonce information in the voucher.


5. <del> An extension to the RFC8366 voucher is needed for the case where the client will be redirected to a local EST Registrar. 5.1. INSERT_TEXT_FROM_FILE ietf-voucher-redirected-tree.txt END 5.2. INSERT_TEXT_FROM_FILE ietf-voucher-redirected@DATE.yang END </del>  6. <del> 6.1. This document registers one URI in the IETF XML registry RFC3688. Following the format in RFC3688, the following registration is requested: 6.2. This document registers two YANG modules in the YANG Module Names registry RFC6020.  Following the format defined in RFC6020, the the following registration is requested: </del>  7. Trust Anchor built in: from full multi-level WebPKI to the single self-signed certificate used by the Cloud Registrar.  There are many tradeoffs to having more or less of the PKI present in the Pledge, <del> which is addresses in part in I-D.richardson-t2trg-idevid- considerations in sections 3 and 5. </del>  7.4.

This reflects that all YANG activity has been rolled up into draft-ietf-anima-rfc8366bis.
the YANG contains "RFC XXXX: Voucher Profile for Cloud redirected Devices" - it seems the name needs updating and there should be an RFC ednote here saying the reference is "this RFC". Correct?YANG contains this: description "Base the constrained voucher upon the regular one"; This looks like a copy/paste leftover from constrained-voucher; correct that it should be modified? (Would this also bump the YANG version and date then?) YANG description for leaf "est-domain" does not explicitly say the word "EST server" which I think it should. So this URI directs to the EST server in the owner's URL YANG support the use case of combining the voucher-constrained format (that extends base voucher) and the voucher-redirected format (from current draft) ? Would that require yet another new YANG module?
Also, the YANG extensions need to move to RFC8366bis! URL

5.  <ins> RFC8366bis contains the two needed voucher extensions: est-domain and additional-configuration which are needed when a client is redirected to a local EST Registrar. </ins> 6.  <ins> This document makes no IANA requests. </ins> 7. Trust Anchor built in: from full multi-level WebPKI to the single self-signed certificate used by the Cloud Registrar.  There are many tradeoffs to having more or less of the PKI present in the Pledge,  <ins> which is addresses in part in I-D.irtf-t2trg-taxonomy-manufacturer- anchors in sections 3 and 5. </ins> 7.4.


Domain.  There may not be a Local Domain Registrar in all deployment scenarios.  1.2. Two high level use cases are documented here.  There are more details provided in sections redirect2Registrar and voucher2EST.  While both use cases aid with incremental deployment of BRSKI infrastructure, for many smaller sites (such as teleworkers) no further <del> infrastructure are expected. </del>  The pledge is not expected to know which of these two situations it is in.  The pledge determines this based upon signals that it to make the determination based upon the identity presented by the pledge. <del> While a Cloud Registrar will typically handle all the devices of a particular product line from a particular manufacturer there are no restrictions on how the Cloud Registrar is horizontally (many sites) or vertically (more equipment at one site) scaled.  It is also entirely possible that all devices sold by through a particular VAR might be preloaded with a configuration that changes the Cloud Registrar URL to point to a VAR.  Such an effort would require unboxing each device in a controlled environment, but the </del>  provisioning could occur using a regular BRSKI or SZTP RFC8572 process. have an owner registrar deployed.  The cloud registrar issues a voucher, and the pledge completes trust bootstrap using the cloud registrar.  The voucher issued by the cloud includes domain <del> information for the owner's EST service the pledge should use for certificate enrollment. </del>  In one use case, an organization has an EST service deployed, but does not have yet a BRSKI capable Registrar service deployed.  The pledge is deployed in the organization's domain, but does not <del> discover a local domain, or owner, registrar.  The pledge uses the cloud registrar to bootstrap, and the cloud registrar provides a voucher that includes instructions on finding the organization's EST service. </del>  2. 3.1.2. <del> The pledge MUST use an Implicit Trust Anchor database (see EST) to authenticate the cloud registrar service.  The Pledge can be done with pre-loaded trust-anchors that are used to validate the TLS connection.  This can be using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </del>  The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar. It may be the case that one or more 307-Redirects have taken the Pledge from the built-in Cloud Registrar to one operated by a VAR. <del> When the Pledge is directed to the Owner's EST Registrar, the Pledge validates the TLS connection with this server using the "pinned- domain-cert" attribute in the voucher.  There is no provisional TLS connection, and therefore there are no risks associated with being behind a captive portal. </del>

[EST] and [RFC7030] are duplicates.
s/are/is/ That sentence is really hard to decode. Please rewrite using more words! Please define VAR. Please define EST. Hard to parse. Maybe you mean "does not discover a local domain registrar or an owner registrar"?

Domain.  There may not be a Local Domain Registrar in all deployment scenarios. <ins> EST: Enrollment over Secure Transport VAR: Value Added Reseller </ins> 1.2. Two high level use cases are documented here.  There are more details provided in sections redirect2Registrar and voucher2EST.  While both use cases aid with incremental deployment of BRSKI infrastructure, for many smaller sites (such as teleworkers) no further  <ins> infrastructure is expected. </ins> The pledge is not expected to know which of these two situations it is in.  The pledge determines this based upon signals that it to make the determination based upon the identity presented by the pledge.  <ins> A Cloud Registrar will typically handle all the devices of a particular product line from a particular manufacturer.  This document places no restrictions on how many different deployments or owner sites the Cloud Registrar can handle, or how many devices per site that the Cloud Registrar can handle.  It is also entirely possible that all devices sold by through a particular Value Added Reseller (VAR) might be preloaded with a configuration that changes the Cloud Registrar URL to point to a VAR.  Such an effort would require unboxing each device in a controlled environment, but the </ins> provisioning could occur using a regular BRSKI or SZTP RFC8572 process. have an owner registrar deployed.  The cloud registrar issues a voucher, and the pledge completes trust bootstrap using the cloud registrar.  The voucher issued by the cloud includes domain  <ins> information for the owner's Enrollment over Secure Transport (EST) RFC7030 service the pledge should use for certificate enrollment. </ins> In one use case, an organization has an EST service deployed, but does not have yet a BRSKI capable Registrar service deployed.  The pledge is deployed in the organization's domain, but does not  <ins> discover a local domain registrar or owner registrar.  The pledge uses the cloud registrar to bootstrap, and the cloud registrar provides a voucher that includes instructions on finding the organization's EST service. </ins> 2. 3.1.2.  <ins> The pledge MUST use an Implicit Trust Anchor database (see EST RFC7030) to authenticate the cloud registrar service.  The Pledge can be done with pre-loaded trust-anchors that are used to validate the TLS connection.  This can be using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </ins> The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar. It may be the case that one or more 307-Redirects have taken the Pledge from the built-in Cloud Registrar to one operated by a VAR.  <ins> When the Pledge is directed to the Owner's EST RFC7030 Registrar, the Pledge validates the TLS connection with this server using the "pinned-domain-cert" attribute in the voucher.  There is no provisional TLS connection, and therefore there are no risks associated with being behind a captive portal. </ins>


BRSKI defines how a pledge MAY contact a well-known URI of a cloud registrar if a local domain registrar cannot be discovered. <del> Additionally, certain pledge types may never attempt to discover a local domain registrar and may automatically bootstrap against a </del>  cloud registrar. The details of the URI are manufacturer specific, with BRSKI giving 3.1.2. The pledge MUST use an Implicit Trust Anchor database (see EST <del> RFC7030) to authenticate the cloud registrar service.  The Pledge can be done with pre-loaded trust-anchors that are used to validate the TLS connection.  This can be using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </del>  The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar. 3.2. <del> The cloud registrar must determine pledge ownership.  Once ownership is determined, or if no owner can be determined, then the registrar may: </del>  return a suitable 4xx or 5xx error response to the pledge if the <del> registrar is unwilling or unable to handle the voucher request </del>  redirect the pledge to an owner register via 307 response code 3.2.2. Once the cloud registrar has determined pledge ownership, the cloud <del> registrar may redirect the pledge to the owner registrar in order to </del>  complete bootstrap.  Ownership registration will require the owner to register their local domain.  The mechanism by which pledge owners register their domain with the cloud registrar is out-of-scope of The cloud registrar returned a 307 response to the voucher request. <del> The pledge should restart the process using a new voucher request </del>  using the location provided in the HTTP redirect.  Note if the pledge is able to validate the new server using a trust anchor found in its Implicit Trust Anchor database, then it MAY accept another 307 other sources of onboarding information as specified in BRSKI section 4.1 and 5.0. <del> The pledge should establish a provisional TLS connection with specified local domain registrar.  The pledge should not use its </del>  Implicit Trust Anchor database for validating the local domain <del> registrar identity.  The pledge should send a voucher request message </del>  via the local domain registrar.  When the pledge downloads a voucher, it can validate the TLS connection to the local domain registrar and continue with enrollment and bootstrap as per standard BRSKI 3.3.2. The cloud registrar returned a voucher to the pledge.  The pledge <del> should perform voucher verification as per standard BRSKI operation. The pledge should verify the voucher signature using the manufacturer-installed trust anchor(s), should verify the serial number in teh voucher, and must verify any nonce information in the </del>  voucher. <del> The pledge should extract the "est-domain" field from the voucher, and should continue with EST enrollment as per standard BRSKI </del>  operation. 4.

The two occurences of lower-case "may" might be clearer as "might". "The Pledge can be done with" ???? "may" or "MAY"? There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST".

BRSKI defines how a pledge MAY contact a well-known URI of a cloud registrar if a local domain registrar cannot be discovered.  <ins> Additionally, certain pledge types might never attempt to discover a local domain registrar and might automatically bootstrap against a </ins> cloud registrar. The details of the URI are manufacturer specific, with BRSKI giving 3.1.2. The pledge MUST use an Implicit Trust Anchor database (see EST  <ins> RFC7030) to authenticate the cloud registrar service.  In order to make use of a Cloud Registrar, the Pledge MUST be manufactured with pre-loaded trust-anchors that are used to validate the TLS connection.  The TLS connection can be validated using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </ins> The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar. 3.2.  <ins> The cloud registrar must determine pledge ownership.  if the registrar is unwilling or unable to handle the voucher request, for example it is unable to determine ownership, then the cloud registrar MUST return a suitable 4xx or 5xx error response to the pledge. If the cloud registrar successfully determines ownership, then the registrar MUST take one of the following actions: </ins> return a suitable 4xx or 5xx error response to the pledge if the  <ins> registrar is unwilling or unable to handle the voucher request for any reason </ins> redirect the pledge to an owner register via 307 response code 3.2.2. Once the cloud registrar has determined pledge ownership, the cloud  <ins> registrar MAY redirect the pledge to the owner registrar in order to </ins> complete bootstrap.  Ownership registration will require the owner to register their local domain.  The mechanism by which pledge owners register their domain with the cloud registrar is out-of-scope of The cloud registrar returned a 307 response to the voucher request.  <ins> The pledge SHOULD restart the process using a new voucher request </ins> using the location provided in the HTTP redirect.  Note if the pledge is able to validate the new server using a trust anchor found in its Implicit Trust Anchor database, then it MAY accept another 307 other sources of onboarding information as specified in BRSKI section 4.1 and 5.0.  <ins> The pledge SHOULD establish a provisional TLS connection with specified local domain registrar.  The pledge SHOULD NOT use its </ins> Implicit Trust Anchor database for validating the local domain  <ins> registrar identity.  The pledge SHOULD send a voucher request message </ins> via the local domain registrar.  When the pledge downloads a voucher, it can validate the TLS connection to the local domain registrar and continue with enrollment and bootstrap as per standard BRSKI 3.3.2. The cloud registrar returned a voucher to the pledge.  The pledge  <ins> SHOULD perform voucher verification as per standard BRSKI operation. The pledge SHOULD verify the voucher signature using the manufacturer-installed trust anchor(s), SHOULD verify the serial number in the voucher, and SHOULD verify any nonce information in the </ins> voucher.  <ins> The pledge SHOULD extract the "est-domain" field from the voucher, and SHOULD continue with EST enrollment as per standard BRSKI </ins> operation. 4.


Abstract <del> This document specifies the behavior of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud </del>  1. Both mechanisms are described in detail later in this document. <del> 2.1. OEM - Equipment manufacturer.  Operate the MASA. Network operator.  Operate the Owner Registrar.  Often operated by end owner (company), or by outsourced IT entity. </del>  <del> Network integrator.  They operate a Cloud Registrar. 2.2. </del>  The assumption is that the pledge already has network connectivity prior to connecting to the cloud registrar.  The pledge must have an between the pledge and the cloud registar are all out of scope of this document. <del> 2.3. </del>  BRSKI section 5.9.2 specifies that the pledge MUST send an EST RFC7030 CSR Attributes request to the registrar.  The registrar MAY The pledge SHOULD restart the process using a new voucher request using the location provided in the HTTP redirect.  Note if the pledge is able to validate the new server using a trust anchor found in its <del> Implicit Trust Anchor database, then it MAY accept another 307 redirect.  The pledge MUST never visit a location that it has already been to.  If that happens then the pledge MUST fail the onboarding attempt and go back to the beginning, which includes listening to other sources of onboarding information as specified in BRSKI section 4.1 and 5.0. </del>  The pledge SHOULD establish a provisional TLS connection with specified local domain registrar.  The pledge SHOULD NOT use its

I find this section too telegraphic. Needs a bit more grammar...
Maybe we just delete this section completely NAME ?
I think we should eliminate the heading, but expand the content to better match the diagram.
I'm not convinced. In the rest of the doc, we never mention OEM or Network integrator. And Network operator is only mentioned again in secetion "Issues with Security of HTTP Redirect" I lean to delete completely, unless you have some explicit ideas and concepts you need to get across. FIne if you do - maybe include that in your abstract rewrite PR?
This is a bit short. I think it should provide a little context for a casual reader (what is BRSKI, what is a pledge, what is a registrar).
No, this is a runon sentence. It is worth. Let me work on something for Friday.

Abstract  <ins> Bootstrapping Remote Secure Key Infrastructures defines how to onboard a device securely into an operator maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and to help the device.  This document extends the new device behaviour so that if no local infrastructure is available, such as in a home or remote office, that the device can use a well defined "call-home" mechanism to find the operator maintained infrastructure. To this, this document defines how to contact a well-known cloud registrar, and two ways in which the new device may be redirected towards the operator maintained infrastructure. </ins> 1. Both mechanisms are described in detail later in this document.  <ins> As depicted in architecture-figure, there are a number of parties involve in the process.  The Manufacturer, or Original Equipment Maker (OEM) builds the device, but also is expected to run the MASA, or arrange for it to exist. The network operator or enterprise is the intended owner of the new device: the pledge.  This could be the enterprise itself, or in many cases there is some outsourced IT department that might be involved. They operator the Registrar or EST Server.  They may operate the CA, or they may contract those services from another entity. Unlike in RFC8995 there is a potential additional party involved, the network integrator, who may operate the Cloud Registrar.  This is typically a value added reseller who works with the OEM to ship products with the right configuration to the owner.  For example, SIP telephones or other conferencing systems may be installed by this VAR, often shipped directly from a warehouse to the customer's remote office location.  The network integrator and manufacturer are aware of which devices have been shipped to the integrator through sales channel integrations, and so the manufacturer's Cloud Registrar is able to redirect the pledge through a chain of Cloud Registrars, as explained in redirect-response. </ins>  <ins> 2.1. </ins> The assumption is that the pledge already has network connectivity prior to connecting to the cloud registrar.  The pledge must have an between the pledge and the cloud registar are all out of scope of this document.  <ins> 2.2. </ins> BRSKI section 5.9.2 specifies that the pledge MUST send an EST RFC7030 CSR Attributes request to the registrar.  The registrar MAY The pledge SHOULD restart the process using a new voucher request using the location provided in the HTTP redirect.  Note if the pledge is able to validate the new server using a trust anchor found in its  <ins> Implicit Trust Anchor database, then it MAY accept additional 307 redirects.redirect.  The pledge MUST never visit a location that it has already been to.  If that happens then the pledge MUST fail the onboarding attempt and go back to the beginning, which includes listening to other sources of onboarding information as specified in BRSKI section 4.1 and 5.0. </ins> The pledge SHOULD establish a provisional TLS connection with specified local domain registrar.  The pledge SHOULD NOT use its


IP address, must be able to make DNS queries, and must be able to send HTTP requests to the cloud registrar.  The pledge operator has already connected the pledge to the network, and the mechanism by <del> which this has happened is out of scope of this document. </del>  2.3.

Should specify that you mean "routeable" IP address, I think. (I suppose it could be a ULA in some deployments?)
I'm not sure routeable is correct. I think that many will think it means an address which is world reachable, when any kind of NAT44, SOCKS, or HTTP-PROXY'able address would work. (there are still enterprises that use 10./8 without a default route and socks/http-proxy...)

IP address, must be able to make DNS queries, and must be able to send HTTP requests to the cloud registrar.  The pledge operator has already connected the pledge to the network, and the mechanism by  <ins> which this has happened is out of scope of this document.  Similarly, what address space the IP address belongs to, whether it is an IPv4 or IPv6 address, or if there are firewalls or proxies deployed between the pledge and the cloud registar are all out of scope of this document. </ins> 2.3.


The returned voucher contains an attribute, "est-domain", defined in redirected below.  The pledge is directed to continue enrollment <del> using the EST registrar found at that URI.  The pledge uses the pinned-domain-cert from the voucher to authenticate the EST registrar. </del>  The process starts, in step 1, when the Pledge establishes a Mutual TLS channel with the Cloud RA/MASA using artifacts created during the includes its assigned EST domain in the est-domain attribute. At this stage, the Pledge should be able to establish a TLS channel <del> with the EST Registrar.  The connection may involve crossing the </del>  Internet requiring a DNS lookup on the provided name.  It may also be a local address that includes an IP address literal including both <del> RFC1918 and IPv6 Unique Local Address.  The EST Registrar is validated using the pinned-domain-cert value provided in the voucher as described in BRSKI section 5.6.2.  This involves treating the </del>  artifact provided in the pinned-domain-cert as a trust anchor, and <del> attempting to validate the EST Registrar from this anchor only. </del>  There is a case where the pinned-domain-cert is the identical End- <del> Entity (EE) Certificate as the EST Registrar.  It also explicitly includes the case where the EST Registrar has a self-signed EE </del>  Certificate, but it may also be an EE certificate that is part of a larger PKI.  If the certificate is not a self-signed or EE certificate, then the Pledge SHOULD apply RFC6125 DNS-ID validation In step 4, the Pledge establishes a TLS channel with the Cloud RA/ MASA, and optionally the pledge should send a request, steps 3.a and 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to <del> establish a secure TLS channel with the EST Registrar. </del>  The Pledge then follows that, in step 5, with an EST Enroll request with the CSR and obtains the requested certificate.  The Pledge must RFC8366bis contains the two needed voucher extensions: est-domain and additional-configuration which are needed when a client is redirected <del> to a local EST Registrar. </del>  6.

what is the "EST Registrar"? It is not defined so far. Wouldn't it be better to use RFC 8995 terminology of "EST server" ? So if the cloud Registrar supplies the Voucher and that redirects to an owner's EST server, we can call that "EST server" or "owner EST server". It's not a Registrar, so not "EST Registrar" or "owner Registrar". The latter term is already used for the server that provides a voucher to the pledge. (Interesting to consider that the owner's EST server could be a Registrar i.e. handing out vouchers in theory, even if the cloud-Registrar-supporting-pledge already got its voucher from the cloud-Registrar. But let's not say such things in the document to avoid complicating it.)

The returned voucher contains an attribute, "est-domain", defined in redirected below.  The pledge is directed to continue enrollment  <ins> using the EST server found at that URI.  The pledge uses the pinned- domain-cert from the voucher to authenticate the EST server. </ins> The process starts, in step 1, when the Pledge establishes a Mutual TLS channel with the Cloud RA/MASA using artifacts created during the includes its assigned EST domain in the est-domain attribute. At this stage, the Pledge should be able to establish a TLS channel  <ins> with the EST server.  The connection may involve crossing the </ins> Internet requiring a DNS lookup on the provided name.  It may also be a local address that includes an IP address literal including both  <ins> RFC1918 and IPv6 Unique Local Address.  The EST server is validated using the pinned-domain-cert value provided in the voucher as described in BRSKI section 5.6.2.  This involves treating the </ins> artifact provided in the pinned-domain-cert as a trust anchor, and  <ins> attempting to validate the EST server from this anchor only. </ins> There is a case where the pinned-domain-cert is the identical End-  <ins> Entity (EE) Certificate as the EST server.  It also explicitly includes the case where the EST server has a self-signed EE </ins> Certificate, but it may also be an EE certificate that is part of a larger PKI.  If the certificate is not a self-signed or EE certificate, then the Pledge SHOULD apply RFC6125 DNS-ID validation In step 4, the Pledge establishes a TLS channel with the Cloud RA/ MASA, and optionally the pledge should send a request, steps 3.a and 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to  <ins> establish a secure TLS channel with the EST server. </ins> The Pledge then follows that, in step 5, with an EST Enroll request with the CSR and obtains the requested certificate.  The Pledge must RFC8366bis contains the two needed voucher extensions: est-domain and additional-configuration which are needed when a client is redirected  <ins> to a local EST server. </ins> 6.


already established via the Voucher, the pledge does a full TLS handshake against the local RA indicated by the voucher response.  EXPLAIN APPLICABILITY.  NEEDS EXTENSTION to Voucher. 5. <del> [[ TODO ]] </del>  6.  [[ TODO ]]

this added the YANG machinery and a basic extension to RFC8366 to add the est-domain attribute.
Looks good.

already established via the Voucher, the pledge does a full TLS handshake against the local RA indicated by the voucher response. <ins> The returned voucher contains an attribute, "est-domain", defined in redirected below.  The pledge is directed to continue enrollment using the EST registrar found at that URI.  (XXX - how can it trust it?  I guess with pinned-domain-cert!) </ins> EXPLAIN APPLICABILITY.  NEEDS EXTENSTION to Voucher. 5.  <ins> An extension to the RFC8366 voucher is needed for the case where the client will be redirected to a local EST Registrar. 5.1. INSERT_TEXT_FROM_FILE ietf-redirected-voucher-tree.txt END 5.2. INSERT_TEXT_FROM_FILE ietf-redirected-voucher@DATE.yang END </ins> 6. <ins> TODO:MCR - Will need to add IETF YANG registration from templates. [[ TODO ]] 7. </ins> [[ TODO ]]


2.2. Representations within a bundle are named by their "Content-Location" <del> (Section 8.7 of I-D.ietf-httpbis-semantics), which holds a URL.  This is also known as the representation's URL. </del>  This identifying information for each representation is stored in an index (index-section) rather than in that representation's HTTP

Closes URL
Thanks. Sent URL
The context is URL The current format says: https://wpack-URL URL Given that, it seems the format already allows a relative URL in the index section, however, it'd be better to ask a clarification than guessing its intention. Using a relative URL is supposed to work? If so, we don't need to request a bundle format change to resolve URL
More context: https://chromium-URL This CL is intended to support relative URLs in web bundles for Subrerouce Web Bundle feature.
NAME What do you think about this? I think the section was introduced by this change in WICG/webpackage. URL
cc: NAME NAME
We need to specify how the keys in the index section are parsed, independent of their semantics as s. I'd intended that to eventually move to the when I removed the algorithms in , with the format spec here being less precise, but I think it was a mistake that I didn't even specify between absolute and relative URLs in the index. We should probably add a sentence here to say which it is. Since we have a use case for relative URLs, let's pick that one. This spec should say something about what the URLs are relative to. Probably a bundle-defined base URL, which defaults to the location of the bundle but can be overridden by a section's contents? And that it's an error if two sections independently set the base URL without their own definitions disambiguating?
I agree that the spec should clearly say that it supports relative URL. Created . Could you please reivew? I think when we introduce a new section, the section should be able to override the bundle's URL. But I don't know how useful it is yet.
This is a good idea, thank you (and apologies for the delay in providing feedback). I have added a small suggestion .
Thank you, this change looks good to me. I have a small suggestion below.Looks good, but please do run this by EMAIL before merging. Hi, WPACK folks. I'm Tsuyoshi Horo. I am working on Web Packaging in Chromium project. We are thinking about changing the spec of Web Bundles to support relative URLs. Currently, the spec says: (Section 8.7 of [I-D.ietf httpbis-semantics]), which holds a URL. This is also known as the representation's URL And draft-ietf-httpbis-semantics-19 says: It seems the spec already supports relative URLs. But we'd like to make it clear. So, I created this pull request. URL Do folks here have any opinions on this change of the pull request? Thanks.

2.2. Representations within a bundle are named by their "Content-Location"  <ins> (Section 8.7 of I-D.ietf-httpbis-semantics).  This is also known as the representation's URL.  It is either an absolute-URI or a partial- URI (Section 2.7 of RFC7230).  In the latter case, the referenced URL is relative to the bundle's URL unless an additional section in the bundle specifies a different base URL. </ins> This identifying information for each representation is stored in an index (index-section) rather than in that representation's HTTP


Web bundles provide a way to bundle up groups of HTTP responses, with the request URLs and content negotiation that produced them, to transmit or store together.  They can include multiple top-level <del> resources with one identified as the default by a primaryUrl metadata, provide random access to their component exchanges, and </del>  efficiently store 8-bit resources. 1. The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII "1" followed by 3 0s) for this version of bundles.  If the recipient <del> doesn't support the version in this field, it MUST either ignore the bundle or fetch and use the content of the "primary-url" field instead. The "primary-url" field identifies both a fallback when the recipient doesn't understand the bundle and a default resource inside the bundle to use when the recipient doesn't have more specific instructions.  This field MAY be an empty string, although protocols using bundles MAY themselves forbid that empty value. </del>  The "section-lengths" and "sections" arrays contain the actual content of the bundle and are defined in sections.  The "section- ""index"" (index-section)  ""manifest"" (manifest-section) ""critical"" (critical-section) 4.2.2.  The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. recipients apply fields in the manifest sooner, for example to show a splash screen before parsing the primary resource. <del> 4.2.3. </del>  The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the

Closes WICG/webpackage. This is transferred from NAME WICG/webpackage.
The WG hummed in favor of this direction at IETF 110: URL

Web bundles provide a way to bundle up groups of HTTP responses, with the request URLs and content negotiation that produced them, to transmit or store together.  They can include multiple top-level  <ins> resources, provide random access to their component exchanges, and </ins> efficiently store 8-bit resources. 1. The "version" bytestring MUST be "31 00 00 00" in base 16 (an ASCII "1" followed by 3 0s) for this version of bundles.  If the recipient  <ins> doesn't support the version in this field, it MUST ignore the bundle. </ins> The "section-lengths" and "sections" arrays contain the actual content of the bundle and are defined in sections.  The "section- ""index"" (index-section) <ins> ""primary"" (primary-section) </ins> ""manifest"" (manifest-section) ""critical"" (critical-section) 4.2.2. <ins> The "primary" section records a single URL identifying the primary URL of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. 4.2.3. </ins> The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. recipients apply fields in the manifest sooner, for example to show a splash screen before parsing the primary resource.  <ins> 4.2.4. </ins> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the


A bundle is logically a set of HTTP representations (Section 3.2 of I-D.ietf-httpbis-semantics), themselves represented by HTTP response messages (Section 3.4 of I-D.ietf-httpbis-semantics).  The bundle can <del> include an optional URL identifying the primary resource within the bundle and can include other optional metadata.  Particular applications can require that the primary URL and/or other metadata is present. </del>  While the order of the representations is not semantically meaningful, it can significantly affect performance when the bundle ""index"" (index-section) <del> ""primary"" (primary-section) </del> ""manifest"" (manifest-section) ""critical"" (critical-section) 4.2.2. <del> The "primary" section records a single URL identifying the primary URL of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. 4.2.3. </del> The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. "application/manifest+json" (appmanifest) and an "accept-language" header of "es-419". <del> Many bundles have a choice between identifying their manifest in this section or in their primary resource, especially if that resource is an HTML file.  Identifying the manifest in this section can help recipients apply fields in the manifest sooner, for example to show a splash screen before parsing the primary resource. 4.2.4. </del>  The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the

This PR removes the primary URL section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading. This and other removed sections can be defined in other documents in the future.
The subresource loading doesn't need a primary URL, but I think "Navigate to Bundle" use case still needs it. URL NAME NAME Please correct me if I am wrong. I'm assuming "Navigate to Bundle" uses a primary URL as a main resource URL.
That's correct. For a bundle to be navigable into, it needs to be possible to specify its main resource URL.
Yes, to open the web bundle file in the browser (eg: Drag and drop) we need either the primary URL or the manifest's . So, we need to keep either as an optional section.
The idea of this PR is that a primary URL could be defined in a separate section. However, it is outside the scope of the "core" bundle specification to define this section.
Thanks for making a PR! Could we see a path to having other document more clearly? Since we need a primary URL defined somewhere, it might be difficult to remove a primary URL section without a clear path how a primary URL is defined.
(Just in case if someone missed it) It seems this PR is one of agenda points at IETF 111 Wpack. URL
NAME : I just opened URL to discuss the possibility of creating an extension of the spec as a separate document.
LGTM (just for record). Thanks for working on this. Hello WPACK, My name is Felipe Erias. I am working on Web bundles at Igalia together with Dan Ehrenberg. I have just created several PRs at wpack-wg/bundled-responses and I am writing this email to request the addition of a point to discuss them to the agenda for the group's upcoming meeting at the end of July. These PRs address the removal of the primary URL section, the manifest section, and content negotiation. Most of this has been adapted from previous work by Dan on the WICG/webpackage repo. The overarching goal is to simplify the "core" Web Bundles specification so it includes just the minimal amount needed to support use cases like subresource loading. The removed sections may be defined in other documents in the future. These are the PRs: URL URL URL Best, Felipe

A bundle is logically a set of HTTP representations (Section 3.2 of I-D.ietf-httpbis-semantics), themselves represented by HTTP response messages (Section 3.4 of I-D.ietf-httpbis-semantics).  The bundle can  <ins> include optional metadata, which may be required by particular applications. </ins> While the order of the representations is not semantically meaningful, it can significantly affect performance when the bundle ""index"" (index-section)  ""manifest"" (manifest-section) ""critical"" (critical-section) 4.2.2.  The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. "application/manifest+json" (appmanifest) and an "accept-language" header of "es-419".  <ins> 4.2.3. </ins> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the


Abstract Web bundles provide a way to bundle up groups of HTTP responses, with <del> the request URLs and content negotiation that produced them, to transmit or store together.  They can include multiple top-level resources, provide random access to their component exchanges, and efficiently store 8-bit resources. </del>  1. They can load the bundle's metadata given a prefix of the bundle. They can find a representation within the bundle given that <del> representation's URL (semantics-naming) and the content- negotiation information that would appear in an HTTP request's headers. </del>  2.2. (Section 8.7 of I-D.ietf-httpbis-semantics), which holds a URL.  This is also known as the representation's URL. <del> Multiple representations within a bundle can have the same URL, in which case they are distinguished by the content negotiation information contained in their "Variants" and "Variant-Key" headers (I-D.ietf-httpbis-variants). </del> This identifying information for each representation is stored in an index (index-section) rather than in that representation's HTTP response message. bundle and identifies their locations in the ""responses"" section. It consists of a CBOR map whose keys are the URLs of the representations in the bundle (semantics-naming).  The value of an <del> index entry is an array whose first item is a "Variants" header field value (I-D.ietf-httpbis-variants) or the empty string.  This is followed by a sequence of offset/length pairs, one for each representation of this resource.  The offset is relative to the start of the ""responses"" section, with an offset of 0 referring to the head of the CBOR "responses" array itself.  The length is the length in bytes of the "response" CBOR item holding this representation (responses-section). If the first item in the value of an index entry is empty, it MUST be followed by exactly one offset/length pair.  This means there is a single representation for this resource, with no content negotiation. Otherwise, the first item MUST be followed by one offset/length pair for each of the possible combinations of available-values within the "Variants" value (the first item of the array) in lexicographic (row- major) order. For example, given a "Variants" value of "accept-encoding=(gzip br), accept-language=(en fr ja)", the list of offset/length pairs will correspond to the "Variant-Key"s: (gzip en) (gzip fr) (gzip ja) (br en) (br fr) (br ja) The order of variant-axes is important.  If the "Variants" value were "accept-language=(en fr ja), accept-encoding=(gzip br)" instead, the "location-in-responses" pairs would instead correspond to: (en gzip) (en br) (fr gzip) (fr br) (ja gzip) (ja br) If the wrong number of offset/length pairs is present in a resource's array, the entire index MUST fail to parse. A combination of available-values that is omitted from the bundle MUST be signaled by setting its offset and length to 0. </del>  4.2.2.

This PR removes content negotiation from the spec. It is more efficient to use content negotiation on the server to select which bundle to send, rather than including several variants in the bundle and having that negotiation happen on the client's side. Issue: URL Adapted from URL
Now that the working group has adopted the document, we actually need them to approve significant changes like this one, not me. We can check on this one during the IETF meeting .
Moved from NAME URL It's more efficient to use content negotiation to select which bundle to serve, rather than including several variants of a resource inside a bundle. Even most use cases around re-sharing bundles while offline can get away with including a single least-common-denominator resource. I only know of the case of translations that concretely need several variants of the same resource. Can we simplify the design by omitting content negotiation? We'd lose some fidelity in representing HTTP, but that might be acceptable.
I"m fine to remove the variants support from the bundle format, however, I'm wondering how removing the variants support impacts on the chromium's implementation. We should align somehow. NAME NAME Do you know any use case of variants? Can we remove variants support from the bundle format without any impacts on the chromium?
Chromium supports variants in Navigation to Web Bundles (URL), but not in Subresource loading with Web Bundles. Since Navigation to Web Bundles hasn't shipped yet, I think it's fine to remove it from Chromium.
If we remove the content negotiation, it may become difficult to support new data formats like WebP in future. But removing it from the bundle format now and re-thinking when it will be more important sounds acceptable.
The idea here is that you would negotiate for the whole bundle, not for resources within the bundle. I think this could permit upgrade to new image formats over time, without shipping all the different options redundantly to the client.
I think we can close this issue. Content negotiation was already dropped.
Thanks for making a PR! Per the discussion URL, the chromium side is okay to remove content negotiation. We probably have to change parser's behavior by checking a bundle's version. That should not be a significant issue for us. We might want to wait for NAME 's approval before merge.

Abstract Web bundles provide a way to bundle up groups of HTTP responses, with  <ins> the request URLs that produced them, to transmit or store together. They can include multiple top-level resources, provide random access to their component exchanges, and efficiently store 8-bit resources. </ins> 1. They can load the bundle's metadata given a prefix of the bundle. They can find a representation within the bundle given that  <ins> representation's URL (semantics-naming). </ins> 2.2. (Section 8.7 of I-D.ietf-httpbis-semantics), which holds a URL.  This is also known as the representation's URL.  This identifying information for each representation is stored in an index (index-section) rather than in that representation's HTTP response message. bundle and identifies their locations in the ""responses"" section. It consists of a CBOR map whose keys are the URLs of the representations in the bundle (semantics-naming).  The value of an  <ins> index entry is an offset/length pair.  The offset is relative to the start of the ""responses"" section, with an offset of 0 referring to the head of the CBOR "responses" array itself.  The length is the length in bytes of the "response" CBOR item holding this representation (responses-section). </ins> 4.2.2.


CAPPORT Architecture <del> draft-ietf-capport-architecture-01 </del>  Abstract

Using these tools should help make things run a little more smoothly. I'll setup a push to gh-pages if you think that this is a good plan.
Hmmm. We should probably deal with this merge conflict. :)
Deconflicted. It was trivial to do on the command line.

CAPPORT Architecture  <ins> draft-ietf-capport-architecture-latest </ins> Abstract


device which has voluntarily joined a network for purposes of communicating beyond the constraints of the captive network. <del> Captive Portal Server: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. </del>  Captive Portal API: Also known as API.  An HTTP API allowing User Equipment to query its state of captivity within the Captive Portal. the equipment. At minimum, the API MUST provide: (1) the state of captivity and (2) <del> a URI for the Captive Portal Server. </del>  A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports. In the diagram: <del> The Provisioning Service, API Server, and Web Portal Server are described as discrete functions.  An implementation might provide the multiple functions within a single entity. </del>  3.

To replace "web-portal" and "Captive Portal Server" Address issue
Note: this actually fixed
Sorry, don't know where I got 45 from
Some reviewers have found "Captive Portal Server" to be confusing when read alongside "Captive Portal API Server". Let's change it to something a bit more distinct. Tommy Pauly has suggested "user portal", which seems reasonable. While we're in there, make sure we're consistent with this use. It was also pointed out that we used "web portal" in quite a few places (e.g. sec 2.6, section 4).
A reasonable URL

device which has voluntarily joined a network for purposes of communicating beyond the constraints of the captive network.  <ins> User Portal: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. </ins> Captive Portal API: Also known as API.  An HTTP API allowing User Equipment to query its state of captivity within the Captive Portal. the equipment. At minimum, the API MUST provide: (1) the state of captivity and (2)  <ins> a URI for the User Portal. </ins> A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports. In the diagram:  <ins> The Provisioning Service, API Server, and User Portal are described as discrete functions.  An implementation might provide the multiple functions within a single entity. </ins> 3.


from the same User Equipment and return the state of captivity for the equipment. <del> At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the User Portal. </del>  A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.

This was raise during multiple reviews: the api doesn't make the user portal URI mandatory. Further, there is a use-case where we want to notify of a 'venue url' without being captive. Change up the wording.
Tirupachur Comerica, Subash writes:
This was also brought up by Martin Duke during the the api document's last call. Let's fix it. Two options were raised during that review (by Tommy and Erik, respectively): Require that the API be able to provide the URI Qualify the requirement to indicate when the URI is required (e.g. when captive portal enforcement may be active). Some proposals: I'm not sure it's worth discussing the use-case that leads to it being useful for it to be optional (e.g. the venue w/ notification or extra info).
We went with the first proposal, "the API MUST be able to provide a URI"
The new wording leaves it open for the API to make it optional. OK.

from the same User Equipment and return the state of captivity for the equipment.  <ins> At minimum, the API MUST provide the state of captivity.  Further the API MUST be able to provide a URI for the User Portal. </ins> A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.


block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic. <del> This document standardizes an architecture for implementing captive </del>  portals while addressing most of the problems arising for current captive portal mechanisms.  The architecture is guided by these principles:

The document is informational. We had some language implying that it intended to be standards-track. Rephrase.
S. Moonesamy writes:
Joel Halpern also pointed this out in the genart review.

block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic.  <ins> This document describes an architecture for implementing captive </ins> portals while addressing most of the problems arising for current captive portal mechanisms.  The architecture is guided by these principles:


The Enforcement Device component restricts the network access of User Equipment according to site-specific policy.  Typically User <del> Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal </del>  Conditions. The Enforcement Device component:

There was some confusion about how network access is constrained for when the user equipment hasn't satisfied the captive portal conditions. Mention that it's up to the provider's policies.
Raised during review. Is it allowed by definition (i.e. within the walled garden) Is it more nuanced? Is it just up to the use-case?
Eric suggests in reply to my suggestions: This would be up to the network operator, I suppose -- they define the extent of the walled garden. The only hosts that must be reachable are any necessary to perform the workflows related to gaining access. The document mentions those in a few places. In section 2.4, the document states: 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. Perhaps we could add some language indicating that this isn't intended to be a normative requirement -- the restrictions placed by the captive portal depend on its use-case. EV> you may add "(.g., local communication)" after "small number of services" ? I propose we do this.
NAME replied with: Let's do that.

The Enforcement Device component restricts the network access of User Equipment according to site-specific policy.  Typically User  <ins> Equipment is permitted access to a small number of services (according to the policies of the network provider) and is denied general network access until it satisfies the Captive Portal </ins> Conditions. The Enforcement Device component:


The Provisioning Service, API Server, and User Portal are described as discrete functions.  An implementation might provide the multiple <del> functions within a single entity. </del>  3.

It makes sense that in a network each component would have multiple replicas for redundancy and scale. Mention that.
Pointed out during review: we mention that components may be logically combined, but we don't talk about redundancy or scale.

The Provisioning Service, API Server, and User Portal are described as discrete functions.  An implementation might provide the multiple  <ins> functions within a single entity.  Furthermore, these functions, combined or not, as well as the Enforcement Device, could be replicated for redundancy or scale. </ins> 3.


addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs.  3.5. A Captive Portal API needs to present information to clients that is

We've had lots of people asking about the mac address as an identifier. Mention it, and point out that we won't give a deep discussion about it.
This one will likely be controversial. I wouldn't mind input from a few others.
Thanks for the reviews/suggestions.
The MAC address is such an obvious identifier, particularly since it's so widely used. We've have multiple questions about it during reviews. We should probably add some simple text pointing that out. E.g. "The MAC address of a device is often used as an identity in existing implementations. A discussion of it has been omitted for brevity, but the MAC address could be used subject to the criteria in section 3.2"

addresses on a single link.  In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs. <ins> 3.4.3. The MAC address of a device is often used as an identifier in existing implementations.  This document does not discuss the use of MAC addresses within a captive portal system, but they can be used as an identifier type, subject to the criteria in id_recommended_props. </ins> 3.5. A Captive Portal API needs to present information to clients that is


Abstract <del> This document describes a captive portal architecture.  DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </del>  1.

Open up the abstract's wording a bit so we make it clear that other provisioning protocols could be used in the future for discovering the API URI.
Benjamin writes:

Abstract  <ins> This document describes a captive portal architecture.  Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </ins> 1.


continue to be supported. If User Equipment supports the Captive Portal API, it MUST validate <del> the API server's TLS certificate (see RFC2818).  An Enforcement Device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf- capport-api for more information.  If certificate validation fails, User Equipment MUST NOT proceed with any of the behavior described above. </del>  2.2. The authors thank Lorenzo Colitti for providing the majority of the content for the Captive Portal Signal requirements.  The authors thank various individuals for their feedback on the mailing list and during the IETF98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van

A reviewer requested that we provide more detail on how the user equipment should so certificate validation. This does so.
Do this. Figure out the proper 'name type'.
Ben suggests Let's use this, and attribute it to him in the acknowledgements.

continue to be supported. If User Equipment supports the Captive Portal API, it MUST validate  <ins> the API server's TLS certificate (see RFC2818) according to the procedures in RFC6125.  The API server's URI is obtained via a network provisioning protocol, which will typically provide a hostname to be used in TLS server certificate validation, against a DNS-ID in the server certificate.  If the API server is identified by IP address, the iPAddress subjectAltName is used to validate the server certificate.  An Enforcement Device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST NOT proceed with any of the behavior described above. </ins> 2.2. The authors thank Lorenzo Colitti for providing the majority of the content for the Captive Portal Signal requirements. <ins> The authors thank Benjamin Kaduk for providing the content related to TLS certificate validation of the API server. </ins> The authors thank various individuals for their feedback on the mailing list and during the IETF98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van


the equipment. At minimum, the API MUST provide the state of captivity.  Further the <del> API MUST be able to provide a URI for the User Portal. </del>  A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.

We never talked about TLS for the user portal. Add a bit of language related to that. To discuss: Should this be a MUST? Existing solutions often don't use https, but that may not be a good reason to loosen the requirement. Have I properly mentioned the URI scheme as being https? Do we even need to do that? I'm trying to put a requirement on the API that it provide a URI that lends itself to tls-based communication, which is why I took that approach.
NAME using MUST makes sense. I've taken your suggestion.
Benjamin writes: I would at least like to recommend that it's TLS, so it's considered. Discussion continuing on list.

the equipment. At minimum, the API MUST provide the state of captivity.  Further the  <ins> API MUST be able to provide a URI for the User Portal.  The scheme for the URI MUST be https so that the User Equipment communicates with the User Portal over TLS. </ins> A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.


by the network operator, such as reading advertisements, accepting an acceptable-use policy, or providing some form of credentials. <del> 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. </del>  This document describes an architecture for implementing captive portals while addressing most of the problems arising for current certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST <del> NOT proceed with any of the behavior described above. </del>  2.2. Here we discuss candidate mechanisms for provisioning the User <del> Equipment with the URI of the API to query captive portal state and navigate the portal. </del>  2.2.1. <del> A standard for providing a portal URI using DHCP or Router Advertisements is described in RFC7710bis.  The captive portal </del>  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 <del> Information containing the URI for the JSON-based API described in section_api. </del>  2.3. The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user.  This API thereby removes <del> the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering. </del>  The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning). protocol. When User Equipment receives Captive Portal Signals, the User <del> Equipment MAY query the API to check the state.  The User Equipment SHOULD rate-limit these API queries in the event of the signal being flooded.  (See Security.) </del>  The API MUST be extensible to support future use-cases by allowing extensible information elements. 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 <del> when the User Equipment is extended externally to devices such as billing systems, or where the identity of the User Equipment could imply liability. </del>  3.2.3. A different Captive Portal API URI could be returned in the following cases: <del> 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. </del>  5.

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.
Benjamin 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 WiFi network until ..." Note: We're changing MAY to could here to address Alvaro'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.

by the network operator, such as reading advertisements, accepting an acceptable-use policy, or providing some form of credentials.  <ins> 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. </ins> This document describes an architecture for implementing captive portals while addressing most of the problems arising for current certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST  <ins> NOT make any calls to the API server. </ins> 2.2. Here we discuss candidate mechanisms for provisioning the User  <ins> Equipment with the Captive Portal API URI to query captive portal state and navigate the portal. </ins> 2.2.1.  <ins> A standard for providing a Captive Portal API URI using DHCP or Router Advertisements is described in RFC7710bis.  The captive portal </ins> 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  <ins> Information containing the URI for the API described in section_api. </ins> 2.3. The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user.  This API thereby removes  <ins> the need for User Equipment to perform clear-text "canary" (see app- additional) queries to check for response tampering. </ins> The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning). protocol. When User Equipment receives Captive Portal Signals, the User  <ins> Equipment MAY query the API to check its state of captivity.  The User Equipment SHOULD rate-limit these API queries in the event of the signal being flooded.  (See Security.) </ins> The API MUST be extensible to support future use-cases by allowing extensible information elements. 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  <ins> 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. </ins> 3.2.3. A different Captive Portal API URI could be returned in the following cases:  <ins> 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. </ins> 5.


the user in satisfying the conditions to escape captivity. Captive Portal API: Also known as API.  An HTTP API allowing User <del> Equipment to query its state of captivity within the Captive Portal. </del>  Captive Portal API Server: Also known as API Server.  A server hosting the Captive Portal API.

The API provides more than just a simple boolean sttate: it allows the UE to learn how to escape captivity. To set the tone for a more complicated API, mention this in the terminology section's definition of the Captive Portal API.
This currently only mentions the state of captivity, whereas it should also include how to get out captivity.

the user in satisfying the conditions to escape captivity. Captive Portal API: Also known as API.  An HTTP API allowing User  <ins> Equipment to query information about its state of captivity within the Captive Portal.  This information might include how to obtain full network access (e.g. by visting a URI). </ins> Captive Portal API Server: Also known as API Server.  A server hosting the Captive Portal API.


4. This section aims to improve understanding by describing a possible <del> workflow of solutions adhering to the architecture. </del>  4.1. A different Captive Portal API URI could be returned in the following cases: <del> 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. </del>  5. needs to trust the API server, server authentication will be performed using TLS mechanisms.  7.3. The solution described here requires that the API be secured using

There was some concern that section 4 could be seen as normative. To make matters worse, there was some normative text in there. Rework things a bit to address that. Explicitly call out that section 4 is not normative to avoid confusion Move normative text out of 4.3 into 2.1 Add some more description to 4.3 Describe trust for new URIs
Roman writes, It's meant to be informative. Move it Section 2.1 (User Equipment)
We did this in
Benjamin writes, This should be the same as the initial one we received when first accessing the network(e.g. via DHCP, RAs, etc). Perhaps we don't properly indicate elsewhere that this should be supported. I thought we did, but I can't find it... I think we should add a point to Section 2.1 that the UE SHOULD support updates to the captive portal URI from the network provisioning service, and then mention here that that service is what did it. The same trust as mentioned in section 7.1 still applies.
Benjamin writes, Do it.

4. This section aims to improve understanding by describing a possible  <ins> workflow of solutions adhering to the architecture.  Note that the section is not normative: it describes only as subset of possible implementations. </ins> 4.1. A different Captive Portal API URI could be returned in the following cases:  <ins> When the Network Provisioning Service updates the Captive Portal API URI, the User Equipment can retrieve updated state from the URI immediately, or it can wait as it normally would until the expiry conditions it retrieved from the old URI are about to expire. </ins> 5. needs to trust the API server, server authentication will be performed using TLS mechanisms. <ins> The Captive Portal API URI might change during the Captive Portal Session.  The User Equipment can apply the same trust mechanisms to the new URI as it did to the URI it received initially from the network provisioning service. </ins> 7.3. The solution described here requires that the API be secured using


3.2.1. <del> Each instance of User Equipment interacting with the Captive Network MUST be given an identifier that is unique among User Equipment interacting at that time. </del>  Over time, the User Equipment assigned to an identifier value MAY change.  Allowing the identified device to change over time ensures

Fixes issue
Benjamin writes, I suggest: >perhaps "given" is the wrong term here? Should we rephrase to
Looks good. Thanks!

3.2.1.  <ins> 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. </ins> Over time, the User Equipment assigned to an identifier value MAY change.  Allowing the identified device to change over time ensures


toward the User Equipment.  This signal indicates that the User Equipment might need to contact the API Server to receive updated information.  For instance, this signal might be generated when the <del> end of a session is imminent, or when network access was denied. </del>  An Enforcement Device MUST rate-limit any signal generated in response to these conditions.  See section_signal_risks for a

New SHOULD requirement to consider all signals as a single simple hint. Fixes issue Looking for reviewers to confirm this new SHOULD is OK.
Note Benjamin's reply to my question asking for clarification: My reply to that:
Closed in
lgtm

toward the User Equipment.  This signal indicates that the User Equipment might need to contact the API Server to receive updated information.  For instance, this signal might be generated when the  <ins> end of a session is imminent, or when network access was denied.  For simplicity, and to reduce the attack surface, all signals SHOULD be considered equivalent by the User Equipment: as a hint to contact the API.  If future solutions have multiple signal types, each type SHOULD be rate-limited independently. </ins> An Enforcement Device MUST rate-limit any signal generated in response to these conditions.  See section_signal_risks for a


7.2. <del> The solution described here assumes that when the User Equipment needs to trust the API server, server authentication will be performed using TLS mechanisms. </del>  The Captive Portal API URI might change during the Captive Portal Session.  The User Equipment can apply the same trust mechanisms to

A reviewer pointed out that we need to specify how TLS is used. Link to the existing procedure in the User Equipment requirements. Also rephrase so that it doesn't sound like we're suggestion that using TLS is optional.
I'm not sure if my 'link' is a good idea. I could just repeat the procedure verbatim, I suppose, but it seems like a waste of text.
Benjamin writes While in here, Roland writes:
This looks fine, but it might be more concise.

7.2.  <ins> The solution described here requires that when the User Equipment needs to access the API server, the User Equipment authenticates the server; see section_client. </ins> The Captive Portal API URI might change during the Captive Portal Session.  The User Equipment can apply the same trust mechanisms to


2.2. <del> 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. </del>  2.2.1.

We didn't really lay out the role of the provisioning service. While we still don't have any requirements on it, this changes the provisioning service section to give more guidance about its role in the network.
Any thoughts on whether we should expand to add some requirements? E.g. URI scheme MUST be HTTPS.
Roman writes, "The Provisioning Service is primarily responsible for providing a portal 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 portal URI to the User Equipment. It is expected that the provided URI will be for the API described in Section 2.3".

2.2.  <ins> 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. </ins> 2.2.1.


information.  If certificate validation fails, User Equipment MUST NOT make any calls to the API server.  2.2. The Provisioning Service is primarily responsible for providing a

In section 4.2, we describe a condition where the session is about to expire. The UE detects this by consulting some form of storage. Yet, we never mentioned that it was proper to store any state. This commit adds a small section outlining that the UE can store state, with a brief discussion about the tradeoffs in doing so.
Roman writes, it retrieved from the API so that it could consult the time remaining (seconds-remainingin the API document). I can update section 2.1 to indicate that the UE could store informationfrom the API's response in order to trigger workflows related to imminent expiry of its access.Storing the state isn't required, but it could make the user experience better if supported.

information.  If certificate validation fails, User Equipment MUST NOT make any calls to the API server. <ins> 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. </ins> 2.2. The Provisioning Service is primarily responsible for providing a


An Identifier is a characteristic of the User Equipment used by the components of a Captive Portal to uniquely determine which specific <del> User Equipment is interacting with them.  An Identifier MAY be a </del>  field contained in packets sent by the User Equipment to the External <del> Network.  Or, an Identifier MAY be an ephemeral property not </del>  contained in packets destined for the External Network, but instead correlated with such information through knowledge available to the different components.

We were unnecessarily using normative language in section 3.1. Replace it with non-normative language.
Alvaro writes of possibilities. Replace the two 'MAY' occurrences with 'could'.

An Identifier is a characteristic of the User Equipment used by the components of a Captive Portal to uniquely determine which specific  <ins> User Equipment is interacting with them.  An Identifier can be a </ins> field contained in packets sent by the User Equipment to the External  <ins> Network.  Or, an Identifier can be an ephemeral property not </ins> contained in packets destined for the External Network, but instead correlated with such information through knowledge available to the different components.


provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example.  7.2. The solution described here requires that when the User Equipment

When we trust a network, we introduce the risk of on path attacks. Mention a few of them as possibilities. A few questions for the reviewers: Should we mention that the list is not exhaustive, or is that implied? Should we mention mitigating factors? (i.e. some of the attacks I've mentioned should be prevented w/ proper use of TLS).
Roman writes, text as just one example.

provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example. <ins> Further, the possibility of an on-path attacker in an attacking network introduces some risks.  The attacker could redirect traffic to arbitrary destinations.  The attacker could analyze the user's traffic leading to loss of confidentiality.  Or, the attacker could modify the traffic inline. </ins> 7.2. The solution described here requires that when the User Equipment


for the URI MUST be https so that the User Equipment communicates with the User Portal over TLS.  A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports. For an HTTP-based interaction, such as in I-D.ietf-capport-api this

A reviewer pointed out that we never really said that it was a desired proprety of the API that it limit access to a UE's state to itself. Add a requirement to that effect so we're explicit about that goal, and reference the identifier section that describes that it's a good property for the identity.
One thing we're not addressing here is a similar requirement on the User Portal. I feel like we should probably have one. Thoughts?
Thanks. Perhaps I'll do this in a separate PR to address
Roman writes, Martin agreed that we should do something like this in response to my question: We can add a requirement stating that the only the UE should be able to check its own state of captivity (work on the phrasing/normative text).
This sentence refers to URLs in the API blob, not the API itself. We definitely are okay with a common API URL or a guessable one. That’s an option.
Right. I'm not sure what I was thinking. NAME What about the URIs provided by the API itself? Do you have an opinion whether we should suggest that they be unguessable? One thought is that the API server and web portal could agree on an mechanism to cipher the UE's identifier, so that even if it's something possible guessable (i.e. the IP), and attacker couldn't spoof it.
Nice. I think that this is sufficient. The portal itself can use things like capability URLs to avoid needing this sort of check. (And then we're far into design and not architecture; this is nice because it talks about requirements.) If you feel motivated, you could add something, but it's tricky. The user portal doesn't need to use strong identifiers, because it can base its decisions on other things than the UE identifier. For instance, a capability URL (that is, a hard-to-guess URL) embedded in the API requires no external authentication.

for the URI MUST be https so that the User Equipment communicates with the User Portal over TLS. <ins> If the API receives a request for state that does not correspond to the requesting User Equipment, the API SHOULD deny access.  Given that the API might use the User Equipment's identifier for authentication, this requirement motivates id_recommended_hard. </ins> A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports. For an HTTP-based interaction, such as in I-D.ietf-capport-api this


This adds a privacy section which discusses the implications of the User Equipment identity. I'm open to suggestions for more content here. Some thoughts: State that may not contain the identity, but can be mapped to from it? Logging?
Benjamin writes, We need a bit more text here.

doesn't get notified when network access is restricted.  Hence, end- user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. <ins> 7.6. ue_identity describes a mechanism by which all components within the Captive Portal are designed to use the same identifier to uniquely identify the User Equipment.  This identifier could be abused to track the user.  Implementers and designers of Captive Portals should take care to ensure that identifiers, if stored, are stored securely. Likewise, if any component communicates the identifier over the network, it should ensure the confidentiality of the identifier on the wire by using encryption such as TLS. There are benfits to choosing mutable anonymous identifiers.  For example, User Equipment could cycle through multiple identifiers to help prevent long-term tracking.  However, if the components of the network use an internal mapping to map the identity to a stable, long-term value in order to deal with changing identifiers, they need to treat that value as sensitive information: an attacker could use it to tie traffic back to the originating User Equipment, despite the User Equipment having changed identifiers. </ins>


1.2. <del> Captive Network: A network which limits communication of attached </del>  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 <del> Network.  This state can be used to determine whether its Captive </del>  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 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 <del> the User Equipment for access to the Captive Network (e.g., by </del>  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. 2.6. The following diagram shows the communication between each component <del> in the case where the Captive Network has a User Portal, and the User </del>  Equipment chooses to visit the User Portal in response to discovering and interacting with the API Server. 3.2.1. <del> The Captive Network MUST associate the User Equipment with an </del>  identifier that is unique among the User Equipment that are <del> interacting with the Captive Network at that time. </del>  Over time, the User Equipment assigned to an identifier value MAY change.  Allowing the identified device to change over time ensures 4.1. This section describes a possible workflow when User Equipment <del> initially joins a Captive Network. </del>  4.2.

A reviewer pointed out that Captive Portal and Captive Network were used interchangeably in the document. While we used Captive Network more frequently, Captive Portal 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 Captive Portal, which makes this change more aligned with them.
Tirupachur Comerica, Subash 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. URL point out that we assume a degree of mutual control over both.

1.2.  <ins> Captive Portal: A network which limits communication of attached </ins> 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  <ins> Portal.  This state can be used to determine whether its Captive </ins> 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 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  <ins> the User Equipment for access to the Captive Portal (e.g., by </ins> 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. 2.6. The following diagram shows the communication between each component  <ins> in the case where the Captive Portal has a User Portal, and the User </ins> Equipment chooses to visit the User Portal in response to discovering and interacting with the API Server. 3.2.1.  <ins> The Captive Portal MUST associate the User Equipment with an </ins> identifier that is unique among the User Equipment that are  <ins> interacting with the Captive Portal at that time. </ins> Over time, the User Equipment assigned to an identifier value MAY change.  Allowing the identified device to change over time ensures 4.1. This section describes a possible workflow when User Equipment  <ins> initially joins a Captive Portal. </ins> 4.2.


Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of <del> communicating beyond the constraints of the captive network. </del>  User Portal: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. The User Equipment: None of the above requirements are mandatory because (a) we do not <del> wish to say users or devices must seek full access to the captive network, (b) the requirements may be fulfilled by manually visiting </del>  the captive portal web application, and (c) legacy devices must continue to be supported. Though a URI might still correctly resolve when the User Equipment makes the request from a different network, it is possible that some functions could be limited to when the User Equipment makes requests <del> using the captive network.  For example, payment options could be </del>  absent or a warning could be displayed to indicate the payment is not for the current connection.

A reviewer found a problem with some phrasing, and also noticed that we missed a few captive networks. Clean them up.

Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of  <ins> communicating beyond the constraints of the Captive Portal. </ins> User Portal: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. The User Equipment: None of the above requirements are mandatory because (a) we do not  <ins> wish to say users or devices must seek full access to the Captive Portal, (b) the requirements may be fulfilled by manually visiting </ins> the captive portal web application, and (c) legacy devices must continue to be supported. Though a URI might still correctly resolve when the User Equipment makes the request from a different network, it is possible that some functions could be limited to when the User Equipment makes requests  <ins> using the Captive Portal.  For example, payment options could be </ins> absent or a warning could be displayed to indicate the payment is not for the current connection.


Be Visible to the Enforcement Device  3.2.1. In order to uniquely identify the User Equipment, at most one user

Fixes Issue
NAME Thanks for the quick review.
The information needs to only apply to the current point of network attachment. That is obvious, perhaps, but worth stating. Thanks to Warren Kumari.
NAME Can you take a look at PR ? I want to make sure I've captured Warren's point properly.
I think that's about right. But you should avoid 2119 language. I have a few suggestions (if only GitHub had multi-line suggestions...).

Be Visible to the Enforcement Device <ins> An identifier might only apply to the current point of network attachment.  If the device moves to a different network location its identity could change. </ins> 3.2.1. In order to uniquely identify the User Equipment, at most one user


indication that traffic is restricted, which can be used as a prompt to contact the API.  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.

Point out that future Captive Portal Signalling Protocols will not enable non-binary blocking. Fixes Issue
There are networks that want to selectively block things. We aren't going to get consensus on whether that is good practice, but we do have consensus that we don't provide protocol mechanisms for communicating about selective blocking. Document that fact.
Closed in .

indication that traffic is restricted, which can be used as a prompt to contact the API. <ins> The Captive Portal Signaling Protocol does not provide any means of indicating that the network prevents access to some destinations. The intent is to rely on the Captive Portal API and the web portal to which it points to communicate local network policies. </ins> 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.