jiebi/TextFlow huggingface dataset:
Original text:
it wishes to share with the user (e.g., store info, maps, flight status, or entertainment). <del> "expire-date" (optional, string formatted as RFC3339 datetime): indicates the date and time after which the client will be in a </del>  captive state.  The API server SHOULD include this value if the client is not captive (i.e. captive=false) and SHOULD omit this value for captive clients.

Reviewer comments:
Completes
As discussed in the IETF hackathon/informal meeting, the consensus is to change expire-date (an absolute iso datetime) to seconds-remaining integer (named after bytes-remaining)
This was already done!
thanks, missed that
The draft currently specifies a deadline as an absolute time. Experience with implementation showed that time remaining (in seconds) was easier to implement and less subject to the vagaries of clock differences.

Revised text:
it wishes to share with the user (e.g., store info, maps, flight status, or entertainment).  <ins> "seconds-remaining" (optional, integer): indicates the number of seconds remaining, after which the client will be placed into a </ins> captive state.  The API server SHOULD include this value if the client is not captive (i.e. captive=false) and SHOULD omit this value for captive clients.
Original text:
and 'ietf-tcg-algs.yang' ref-ietf-tcg-algs with prefix 'taa'. Additionally, references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key, <del> TPM1.2-Structures, bios-log, ima-log, BIOS-Log-Event-Type and netequip-boot-log. </del>  2.1.1.1. UEFI event logs. 'ima': Indicates that the device supports the retrieval of event <del> logs from the Linux Integrity Measurement Architecture (IMA). </del>  'netequip_boot': Indicates that the device supports the retrieval <del> of netequip boot event logs. </del>  2.1.1.2. 10118-3, ISO-IEC-14888-3, ISO-IEC-15946-1, ISO-IEC-18033-3, IEEE-Std- 1363-2000, IEEE-Std-1363a-2004, NIST-PUB-FIPS-202, NIST-SP800-38C, NIST-SP800-38D, NIST-SP800-38F, NIST-SP800-56A, NIST-SP800-108, bios- <del> log, ima-log, and netequip-boot-log exist within the YANG Model. </del>  2.1.2.1.

Reviewer comments:
Self-approved
Thanks, this does a good job bridging the gap between what we say in the body of the document and what is available in external references.

Revised text:
and 'ietf-tcg-algs.yang' ref-ietf-tcg-algs with prefix 'taa'. Additionally, references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key,  <ins> TPM1.2-Structures, bios-log, ima-log, BIOS-Log-Event-Type, as well as ima and netequip-boot-log. </ins> 2.1.1.1. UEFI event logs. 'ima': Indicates that the device supports the retrieval of event  <ins> logs from the Linux Integrity Measurement Architecture (IMA ima- log).  Also see ima. </ins> 'netequip_boot': Indicates that the device supports the retrieval  <ins> of netequip boot event logs.  See ima and netequip-boot-log. </ins> 2.1.1.2. 10118-3, ISO-IEC-14888-3, ISO-IEC-15946-1, ISO-IEC-18033-3, IEEE-Std- 1363-2000, IEEE-Std-1363a-2004, NIST-PUB-FIPS-202, NIST-SP800-38C, NIST-SP800-38D, NIST-SP800-38F, NIST-SP800-56A, NIST-SP800-108, bios-  <ins> log, ima-log, as well as ima and netequip-boot-log exist within the YANG Model. </ins> 2.1.2.1.
Original text:
store system security measurement Evidence.  And each TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation Evidence.  This is done by using a YANG RPC to request a quote which <del> exposes a rolling hash the security measurements held internally </del>  within the TPM. Specific terms imported from I-D.ietf-rats-architecture and used in and 'ietf-tcg-algs.yang' ref-ietf-tcg-algs with prefix 'taa'. Additionally, references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key, <del> TPM1.2-Structures, bios-log, ima-log, BIOS-Log-Event-Type, as well as ima and netequip-boot-log. </del>  2.1.1.1. UEFI event logs. 'ima': Indicates that the device supports the retrieval of event <del> logs from the Linux Integrity Measurement Architecture (IMA ima- log).  Also see ima. </del>  'netequip_boot': Indicates that the device supports the retrieval of netequip boot event logs.  See ima and netequip-boot-log. 10118-3, ISO-IEC-14888-3, ISO-IEC-15946-1, ISO-IEC-18033-3, IEEE-Std- 1363-2000, IEEE-Std-1363a-2004, NIST-PUB-FIPS-202, NIST-SP800-38C, NIST-SP800-38D, NIST-SP800-38F, NIST-SP800-56A, NIST-SP800-108, bios- <del> log, ima-log, as well as ima and netequip-boot-log exist within the YANG Model. </del>  2.1.2.1.

Reviewer comments:
NAME I did what I could in the time remaining. Please check and I think there are only two comments left unaddressed.

Revised text:
store system security measurement Evidence.  And each TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation Evidence.  This is done by using a YANG RPC to request a quote which  <ins> exposes a rolling hash of the security measurements held internally </ins> within the TPM. Specific terms imported from I-D.ietf-rats-architecture and used in and 'ietf-tcg-algs.yang' ref-ietf-tcg-algs with prefix 'taa'. Additionally, references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key,  <ins> TPM1.2-Structures, bios-log, BIOS-Log-Event-Type, as well as ima and netequip-boot-log. </ins> 2.1.1.1. UEFI event logs. 'ima': Indicates that the device supports the retrieval of event  <ins> logs from the Linux Integrity Measurement Architecture (IMA, see ima). </ins> 'netequip_boot': Indicates that the device supports the retrieval of netequip boot event logs.  See ima and netequip-boot-log. 10118-3, ISO-IEC-14888-3, ISO-IEC-15946-1, ISO-IEC-18033-3, IEEE-Std- 1363-2000, IEEE-Std-1363a-2004, NIST-PUB-FIPS-202, NIST-SP800-38C, NIST-SP800-38D, NIST-SP800-38F, NIST-SP800-56A, NIST-SP800-108, bios-  <ins> log, as well as ima and netequip-boot-log exist within the YANG Model. </ins> 2.1.2.1.
Original text:
composite device (quote primitive operation).  Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function <del> (extent primitive operation). </del>  1.1.

Reviewer comments:
extent -> extend thx! I would have never catched that, I htink.

Revised text:
composite device (quote primitive operation).  Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function  <ins> (extend primitive operation). </ins> 1.1.
Original text:
Abstract <del> This document defines a YANG RPC and a minimal datastore required to retrieve attestation evidence about integrity measurements from a device following the operational context defined in TPM-based Network Device Remote Integrity Verification.  Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. </del>  1.

Reviewer comments:
Per Jeurgen's comment that we are not building a new datastore (type)

Revised text:
Abstract  <ins> This document defines a YANG RPC and a small number of configuration node required to retrieve attestation evidence about integrity measurements from a device following the operational context defined in TPM-based Network Device Remote Integrity Verification. Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. </ins> 1.
Original text:
netconf-keystore, and "ietf-tcg-algs.yang" ref-ietf-tcg-algs. Additionally references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key, <del> TPM1.2-Structures, PC-Client-EFI-TPM-1.2, ima-log, and netequip-boot- log. </del>  2.1.1.1.

Reviewer comments:
NAME - if spaces are allowed in kramdown references, then this should work. AFAIK, this is ready to post to IETF.

Revised text:
netconf-keystore, and "ietf-tcg-algs.yang" ref-ietf-tcg-algs. Additionally references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key,  <ins> TPM1.2-Structures, PC-Client-EFI-TPM-1.2, ima-log, BIOS Log Event Type and netequip-boot-log. </ins> 2.1.1.1.
Original text:
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.

Reviewer comments:
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.

Revised text:
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.
Original text:
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.

Reviewer comments:
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

Revised text:
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.
Original text:
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.

Reviewer comments:
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...)

Revised text:
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.
Original text:
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 ]]

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

Revised text:
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 ]]
Original text:
CAPPORT Architecture <del> draft-ietf-capport-architecture-01 </del>  Abstract

Reviewer comments:
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.

Revised text:
CAPPORT Architecture  <ins> draft-ietf-capport-architecture-latest </ins> Abstract
Original text:
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.

Reviewer comments:
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

Revised text:
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.
Original text:
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.

Reviewer comments:
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.

Revised text:
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.
Original text:
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:

Reviewer comments:
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.

Revised text:
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:
Original text:
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:

Reviewer comments:
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.

Revised text:
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:
Original text:
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.

Reviewer comments:
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.

Revised text:
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.