jiebi/CodeConvo huggingface dataset:
Change:
about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth.  Unlike Evidence, which is often very device- <del> and vendor-specific, Attestation Results can be vendor-neutral if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This </del> <ins> and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This </ins> allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices.

Discussion:
This is the portion of the complete review that contains minor/editorial changes aggregated in a single PR and various commits as discussed in the last editor meeting.
Are you sure that making Composite Device a term isn't a better idea?
I agree with that. There are also some other terms that I would capitalize. But this is the editorial part of the changes so I stuck with the groups consensus. Could you open an issue on "terms you want to capitalize"?
When I ask github to render the diff, it says that it can not. ("Oh my") it says. I wonder if there is an error in the markdown?
Change:
an optional authenticator request <del> It returns the exported authenticator as output.  It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library. Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </del> <ins> It returns the exported authenticator as a sequence of octets.  It is RECOMMENDED that the logic for selecting the certificates and extensions to include in the exporter is implemented in the TLS library.  Implementing this in the TLS library lets the implementer take advantage of existing extension and certificate selection logic. </ins> It is also possible to implement this API outside of the TLS library using TLS exporters.  This may be preferable in cases where the application does not have access to a TLS library with these APIs or when TLS is handled independently of the application layer protocol. <del> "validate", which takes as input: * an optional authenticator request * an authenticator </del> <ins> 5.4. The "validate" API takes as input: an optional authenticator request an authenticator </ins> It returns the certificate chain and extensions.

Discussion:
There are lots of changes here. I did stage this as separate commits to some extent, so feel free to cherry-pick. There is one maybe-technical change here. It wasn't clear about the precedence between handshake and authenticator request for extensions. I've chosen to be clear about this and say that if the authenticator request exists, then it is the only thing that matters. That's 8c0b166. I can drop that from the CL and do that separately if you prefer.
Thanks for the comments. The technical clarification you made is the correct one, the request supersedes the handshake for extension choices if present.
Change:
An entity that issues tokens to Clients for properties attested to by the Attester. <del> An entity that attests to properties of Client for the purposes of token issuance. </del> <ins> An entity that attests to properties of Clients for the purposes of token issuance. The procedure by which an Attester determines whether or not a Client is trusted with a specific set of properties for token issuance. </ins> 3.

Discussion:
From Section 3.2.1: This is a pretty wild equivalence. I stumbled badly on this one. It's very much like saying "in this context a verb is sometimes referred to as a noun". Is the goal here to say that "there is a attestation process by which the Attester determines whether a Client meets the requirements for issuance; if successful, the Attester captures this information using an attestation format" ? That seems to be the case, but that's not what this says.
I think we might just drop the equivalence to avoid confusion, but in the interest of transparency, here's where it came from. Consider the two following types of attestation procedures: Attestation based on , where the client and attester use this mechanism to prove that the client's device is valid. Attestation based on , perhaps where the signature is computed in some client enclave, where the client authenticates its token request with such a ring signature. In (1), attestation is some procedure that takes place between client and attester, whereas in (2) attestation is sort of non-interactive mechanism for producing an attestation format or proof of sorts. Since we don't specify the details of attestation, the text was written in a way to be maximally accommodating to these types of things. In any case, I think it's probably fine to just treat attestation as a procedure_, be it interactive or non-interactive or whatever, and that procedure has certain properties associated with it. I'll propose text.
Change:
3.5.7.2. <del> The "descendant-selector" selects the node and all its descendants. </del> <ins> The "descendant-selector" selects certain descendants of a node: </ins> <del> In the resultant nodelist: * nodes occur before their children, and * nodes of an array occur in array order. </del> <ins> the "..<name>" form (and the "..[<index>]" form where "<index>" is a "quoted-member-name") selects those descendants of the node that are member values of an object with the given member name. the "..[<index>]" where "<index>" is an "element-index" selects those descendants of the node that are array elements with the given index. the "..[*]" and "..*" forms select all the descendants of the node. In the resultant nodelist: nodes occur before their children, and nodes of an array occur in array order. </ins> Children of an object may occur in any order, since JSON objects are unordered.

Discussion:
Exclude the node itself Define the term "descendants" more precisely Define the descendant selector semantics more thoroughly Fixes: URL
I would consider adding two additional examples: given: results in: - and results in: - ] ]
I extended the existing example attempting to exhibit the same points as the example above.
Looks good, thanks!
Considering the following input: would evaluate to (in this case the values of the object): I would expect the descendant version: to evaluate to: Yet the example says: Considering the following pseudo logic: In the case of the would be an index wildcard selector. I would expect the descendant selector to (starting by selecting itself) walk through the json structure and select all the results by applying the child selector (dot-member-name, index-selector, index-wild-selector, or wildcard) on each traversed value. Am I misunderstanding something here or is this the intended behavior?
Thanks for raising this. When I was writing the example, I noticed that only a few implementations included the node itself. But the descendant selector semantics currently say: and so I included the "starting" node itself. This is why I included the following text in the commit message: The semantics section needs improving anyway to clarify the semantics of the various forms of the descendants selector. I agree with the semantics proposed above, providing there is a consensus for this in the WG.
In my understanding descendant selector simply extends the single-level operating of child selector , in that it further recursively operates on all other descendant levels. So I agree to Bram's traversal algorithm above. A node is not considered a descendant of itself. Obviously I have not been aware of this behavior.
I haven't checked the examples, but I like the narrative changes.
Change:
Other attacks can target the behavior of underlying technologies such as UTF-8 (see RFC3629) and the Unicode character set. <ins> Editorial Comments [unnumbered-bad] -- cabo: This should not be an unnumbered section, which it is forced to be by the parent section being unnumbered too.  The overall structure where the parts of this subsection go to needs to be decided; one part already is in the IANA Considerations in [dedup] Well, that can be discussed. </ins>

Discussion:
Weirdly, I cannot reply to this observation: URL Expiry is somewhat unusual for IANA registries (early allocations do expire). What is the behavior you would expect implementations to exhibit? The function extension to stop working on the expiry day?
Hey NAME based on this useful-looking discussion, do you plan to revise this significantly? I'm wondering if I should give it a careful read now or wait for an updated version.
Definitely. Of course, I'd like to have your input on the points raised (the non-trivial ones). We might even want to have a design-team meeting...
Might be a good idea to mark the non-non-trivial issues above resolved, to help reviewer focus. If it's OK, I'll wait for the next revision to go end-to-end. Agreed on a design meeting.
Here's my list of items where we could use input: More frugal with allowing whitespace? return value of functions that don't get the right arguments (e.g., length(1)) (interaction with -- non-singular paths in exist-expr) IANA designated expert instructions (frugal with "good" names) expiring reservations? (shades of certificates) domain of length (arrays now, add strings, objects?)? should there be another function for the size of nodelists (size())? Probably mostly resolved: for function names (ASCII, lowercase, only)
NAME I rebased this and resolved some conflicts.
Update: Address whitespace in a separate PR, if desired. Semantic issue: What to do with value of wrong kind? Fixed in 08dd7ad Fixed in afda44a Probably not. Semantic issue: What to do with value of wrong kind? Yes, that is called count() now (e3a565a) Let's stick with that name space.
We may be able to make this syntactically invalid. See URL for some ideas.
Change:
create a new stream on the given Connection, then attempts to clone a connection will result in a CloneError: <del> The Protocol Property "Niceness" operates on entangled Connections as in msg-niceness: when allocating available network capacity among </del> <ins> The Protocol Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </ins> Connections in a Connection Group, sends on Connections with higher <del> Niceness values will be prioritized over sends on Connections with lower Niceness values.  An ideal transport system implementation </del> <ins> Priority values will be prioritized over sends on Connections with lower Priority values.  An ideal transport system implementation </ins> would assign each Connection the capacity share (M-N) x C / M, where <del> N is the Connection's Niceness value, M is the maximum Niceness value </del> <ins> N is the Connection's Priority value, M is the maximum Priority value </ins> used by all Connections in the group and C is the total available <del> capacity.  However, the Niceness setting is purely advisory, and no </del> <ins> capacity.  However, the Priority setting is purely advisory, and no </ins> guarantees are given about the way capacity is shared.  Each implementation is free to implement a way to share capacity that it sees fit.

Discussion:
Not many text fixes needed - quite a bit of text reflected the old choice of Priority anyway and wasn't correctly updated for Niceness :-)
At 8.1.2 you say lower values have higher priorities for connPrio. But later, at msgPrio, higher values have higher priority, and in the examples where you speak of the interaction of connPrio and msgPrio, you imply that higher means higher for both properties. Please check for consistency and clarify.
Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this, e.g. PR which I don't know... too many iterations have mangled the text.
Aha, now I see what happened: following some more PRs, also , in PR , NAME re-introduced some text saying that sends on Connections with lower-priority values will be prioritized over sends on Connections with a higher-priority value. This reverses the logic for some part of the text - I suspect that NAME (very understandably!) forgot what happened and this created this mix. We have been editing these documents for way too long!
Fine with me. The max_prio problem can be addressed separately.
Change:
queries, announcement responses, resolution queries, and goodbye responses associated with mDNS. <del> 6.2. </del> <ins> 7.2. </ins> If the optional probing queries are implemented for the name registration, a malicious endpoint in the local network, which is

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
If the BUNDLE policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the BUNDLE <del> policy is set to "default", and this is not the first m= section </del> <ins> policy is set to "balanced", and this is not the first m= section </ins> for this media type, an "a=bundle-only" line. Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> and the <proto> field MUST be set to "DTLS/SCTP", as specified in I- D.ietf-mmusic-sctp-sdp, Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1. </del> <ins> and the <proto> field MUST be set to "DTLS/SCTP" [TODO: fix this in profile PR], as specified in I-D.ietf-mmusic-sctp-sdp, Section 3; the "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in the latest data channel docs] </ins> Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- passwd", "a=ice-options", "a=candidate", "a=fingerprint", and

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
designated digitally-signed, and aead-ciphered, respectively.  A field's cryptographic processing is specified by prepending an appropriate key word designation before the field's type <del> specification.  Cryptographic keys are implied by the current session state (see connection-states). </del> <ins> specification. </ins> 4.8.1.

Discussion:
The section on connection states was almost all cruft. I made a new section for nonce construction and moved the piece on sequence numbers there. The only text I modified was the first three paragraphs of the nonce section, which needed to be scrubbed for references to "connection state", and the lead-in section on the AEAD, which I moved to where the other AEAD stuff was and expanded a little to include some forward references.
LGTM NAME Did you still want to replace any of this? The stuff being cut here is very obsolete and must confuse anyone who attempts to read through the whole spec.
Yes, I'm working on it this week. , Dave Garrett EMAIL wrote:
Change:
4. <del> The DTLS record layer is similar to that of TLS 1.3 unless noted otherwise.  The only change is the inclusion of an explicit epoch and sequence number in the record.  This sequence number allows the recipient to correctly verify the TLS MAC.  The DTLS record format is shown below: </del> <ins> The DTLS record layer is similar to that of TLS 1.3.  There are two major changes: The DTLS record layer includes an explicit epoch and sequence number in the record.  This sequence number allows the recipient to correctly verify the TLS MAC. DTLS adds a short header format that can be used to reduce overhead once the handshake is complete. The basic DTLS record format is shown below: </ins> The content type of the record.

Discussion:
NAME PTAL
Oops. Thanks.
Sorry, I forgot to mention that I plan to do a separate PR for shrinking DTLS ciphertext. I have part of it in my buffer, but got this up and had to move on to something else for a bit.
I'm happy to defer fixing KeyUpdate, which is basically non-functional as it is. This is fine on that basis.
Change:
4.3. <del> When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that if the client uses TURN to send to an IP that was obtained by mDNS resolution, the TURN server will learn the underlying host IP and port, and this information can then be relayed to the web application, defeating the value of the mDNS wrapping. To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names, they will be unreachable from the TURN server, and as noted above, the reverse path will continue to work normally. 4.4. </del> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking

Discussion:
PR of
I will upload a PR for this.
OK, bad merge, thanks for catching
Fixed by
E.g. "Step 5 in Section {{gathering}}" in .md becomes "Step 5 in Section Section 2.1" in .html or "Step 5 in Section Section 2.1" in the raw html source.
Was this fixed?
No, it looks to me an issue with the generator code. Or, can I fix it inline? I was assuming the html would be auto-generated, but if it is supposed to just upload a copy, I will fix it inline asap.
I was wrong. This issue is gone in the newly generated HTML (from the "here" link), but we probably need to regenerate it after merging PR
OK, will do as part of the upload
Resolved in latest HTML.
Change:
DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange <del> draft-ietf-perc-dtls-tunnel-06 </del> <ins> draft-ietf-perc-dtls-tunnel-07 </ins> Abstract

Discussion:
Changes for -07 of the tunnel draft include: Updated references Change status to informational Align terminology with newer UKS draft
LGTM
LGTM
Change:
"target" and "ipproto" variables MUST adhere to the format in target- format, using notation from ABNF.  Additionally: <del> if "target" contains an IPv6 literal, the colons (":") MUST be percent-encoded.  For example, if the target host is </del> <ins> if "target" contains an IPv6 literal or prefix, the colons (":") MUST be percent-encoded.  For example, if the target host is </ins> "2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42".

Discussion:
So the description of target says: The variable "target" contains a hostname or IP prefix of a specific host to which the client wants to proxy packets. If the "target" variable is not specified or its value is "", the client is requesting to communicate with any allowable host. "target" supports using DNS names, IPv6 literals and IPv4 literals. Further down the the ABNF is stating: target = IPv6prefix / IPv4prefix / reg-name / "" IPv6prefix = IPv6address ["%2F" 13DIGIT] IPv4prefix = IPv4address ["%2F" 12DIGIT] ipproto = 13DIGIT / "" Thus, the text is inconsistent where the first indicates hostnames and prefixes. Second indicates hostnames (as DNS names) and IPv4/6 Literals, but not prefixes. Then the ABNF indicates Prefixes and reg-name. So if it is only the prefix construct and hostnames then the text about literals directly needs to be addressed. If it is hostnames, IPvX literals, and IPprefix the ABNF and description need to be addressed.
I think you misread the ABNF? It allows hostnames and IP prefixes, that's what the is for. Also those brackets indicate optionality of the prefix.
I think the ABNF is fine. It's the text that once talks about IP prefixes and once about IP literals.
Ah! Thank you, will fix via PR
Change:
a set of links belonging to the hosting web server The web server is free to choose links it deems appropriate to be <del> exposed in its ".well-known/core".  Typically, the links describe </del> <ins> exposed in its "/.well-known/core".  Typically, the links describe </ins> resources that are served by the host, but the set can also contain links to resources on other servers (see examples in RFC6690 page 14).  The set does not necessarily contain links to all resources

Discussion:
Even disregarding the examples that necessarily have the slash, this (vs. plain .well-known/core) version was the more common in the text so far. Closes: URL
This actually
Current master branch text is really unclear: What does it mean : "used to find the identification" ? Can we say intead "used to identify the components" ? How can the URI discovery process identify client-server incompatibilities? CoAP doesn't let you discover supported protocol versions, options, etc. as far as I know, by default. For those implementations not supporting I-D.bormann-t2trg-rel-impl , it is really unclear what to do with this paragraph.
Oups, wrong link in the commit -- sorry for the noise
The intention behind this paragraph is merely to point those who want versioning and more RD metadata that is immaterial to the regular operation to a place where they can safely do so. I see, however, how the "it is necessary to" makes this sound like more than there really is to it. Accordingly, the incompatibilities part is not about finding that something can't work in the first place (that works on a positive-list base using rt and that like), but more for understanding later why things don't work (say, client X produces a document that upsets RD implementation Y in versions earlier than 0.4.1). The address is in section 4 of 6690 (ie. just .well-known/core); now referred to by the name it has there.
A couple of places has ".well-known/core" as resource name, while in most places it says "/.well-known/core". Proposal is to update all occurrences to the latter form. (Maybe this is already addressed in the pull requests with nits, but there are so many - hard to check...)