jiebi/CodeConvo huggingface dataset:
Change:
NAME I did what I could in the time remaining. Please check and I think there are only two comments left unaddressed.

Discussion:
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> <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, <del> TPM1.2-Structures, bios-log, ima-log, BIOS-Log-Event-Type, as well as ima and netequip-boot-log. </del> <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 <del> logs from the Linux Integrity Measurement Architecture (IMA ima- log).  Also see ima. </del> <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- <del> log, ima-log, as well as ima and netequip-boot-log exist within the YANG Model. </del> <ins> log, as well as ima and netequip-boot-log exist within the YANG Model. </ins> 2.1.2.1.
Change:
Per Jeurgen's comment that we are not building a new datastore (type)

Discussion:
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> <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.
Change:
NAME - if spaces are allowed in kramdown references, then this should work. AFAIK, this is ready to post to IETF.

Discussion:
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> <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.
Change:
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.

Discussion:
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 <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> <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 <del> manufacturer-installed trust anchor(s). should verify the serial </del> <ins> manufacturer-installed trust anchor(s), should verify the serial </ins> number in teh voucher, and must verify any nonce information in the voucher.
Change:
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

Discussion:
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> <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. <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> <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, <del> which is addresses in part in I-D.richardson-t2trg-idevid- considerations in sections 3 and 5. </del> <ins> which is addresses in part in I-D.irtf-t2trg-taxonomy-manufacturer- anchors in sections 3 and 5. </ins> 7.4.
Change:
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...)

Discussion:
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> <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.
Change:
this added the YANG machinery and a basic extension to RFC8366 to add the est-domain attribute.
Looks good.

Discussion:
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. <del> [[ TODO ]] </del> <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 ]]
Change:
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.

Discussion:
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> <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
Change:
Closes WICG/webpackage. This is transferred from NAME WICG/webpackage.
The WG hummed in favor of this direction at IETF 110: URL

Discussion:
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> <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 <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> <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. <del> 4.2.3. </del> <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
Change:
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.

Discussion:
CAPPORT Architecture <del> draft-ietf-capport-architecture-01 </del> <ins> draft-ietf-capport-architecture-latest </ins> Abstract
Change:
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

Discussion:
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> <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) <del> a URI for the Captive Portal Server. </del> <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: <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> <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.
Change:
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.

Discussion:
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> <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.
Change:
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.

Discussion:
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> <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:
Change:
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.

Discussion:
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> <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:
Change:
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.

Discussion:
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> <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.
Change:
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"

Discussion:
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
Change:
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:

Discussion:
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> <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.