Original text:
authenticating to, and interacting with the captive portal is out of scope of this document.  [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of the document, open issues, etc should all be available here.  The 1. In many environments, users need to connect to a captive-portal <del> server and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  It is anticipated that the IETF will work on a more fully featured protocol at some point, to ease interaction with Captive Portals.  Regardless of how that protocol operates, it is expected that this document will provide needed functionality because the client will need to know when it is behind a captive portal and how to contact it. </del>  In order to present users with the payment or AUP pages, presently a captive-portal enforcement device has to intercept the user's The format of the IPv4 Captive-Portal DHCP option is shown below. <del> Code: The Captive-Portal DHCPv4 Option (160) (one octet) </del>  Len: The length, in octets of the URI. be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, <del> credentials, etc.  By provisioning a URI using which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </del> 

Reviewer comments:
Forgot to make PR. This is the "good" one, should be abandoned...
Nope -- I think it is still TBD - we've asked / strongly suggested 114 in the IANA section, but I think it would feel presumptive to state that it is... W
I believe this should be changed to 114, or IANA-TBD.
Yikes, good catch. I changed it to TBD, and also added a sentence to the Abstract noting that it has changed from 160 to TBD (it seemed important enough). Thank you! W
NAME have changed or will change? I can't see this in the current version(s) of the draft here.
I swear I'd done this, and event sent a PR, but I cannot find it.... so, just made a new one...
I had created the branch, and made the edits, but apparently forgot to make the PR.... and then, because I couldn't find it, I made a new branch, change and PR (), and then realized the original was better, so I removed PR and created ... Oy vey, W
Done, had forgotten to close...
Should the TBDs be 114? Either that, or the list of changes should be TBD as well?

Revised text:
authenticating to, and interacting with the captive portal is out of scope of this document. <ins> RFC7710 used DHCP code point 160.  Due to a conflict, this document specifies TBD. </ins> [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of the document, open issues, etc should all be available here.  The 1. In many environments, users need to connect to a captive-portal  <ins> device and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  Regardless of how that mechanism operates, this document provides functionality to allow the client to know when it is behind a captive portal and how to contact it. </ins> In order to present users with the payment or AUP pages, presently a captive-portal enforcement device has to intercept the user's The format of the IPv4 Captive-Portal DHCP option is shown below.  <ins> Code: The Captive-Portal DHCPv4 Option (TBD) (one octet) </ins> Len: The length, in octets of the URI. be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies,  <ins> credentials, etc.  By handing out a URI which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </ins>