jiebi/CodeConvo huggingface dataset:
Change:
If an access token response includes the "manage" parameter as described in response-token-single, the client instance MAY call this URL to manage the access token with any of the actions defined in the <del> following sections.  Other actions are undefined by this specification. </del> <ins> following sections: rotate and revoke.  Other actions are undefined by this specification. </ins> The access token being managed acts as the access element for its own management API.  The client instance MUST present proof of an

Discussion:
Actually a very minor editorial change to specify the actions.
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: b874cebd8f241746631e4c73c3c9056b190bfb1e Inspect the deploy log: Browse the preview:
So I was starting to have a look at rotation/revocation issues (keys or tokens), as we have many open issues that relate to that Interesting insight from DIF KERI (Universal Identifier Theory paper) "The term revocation has two completely different meanings in the identity space. In key management one may speak of revoking keys. With statement issuance, authorization issuance, or credential issuance, one may speak of revoking an authorization statement, a token, or a credential. This becomes confusing when the act of revoking keys also implicitly revokes the authorization of statements signed with those keys." and "KERI terminology usually avoids that confusion between rotation and revocation because a key rotation operation is the equivalent of a key revocation operation followed by a key replacement operation. So one operation, rotate, is implemented instead of two operations (revoke and replace)."
Related question: what is persistent (drawback, need to store that info somewhere, safely) ? what is ephemeral ? what's the lifecycle of related objects? And more specifically: every new request needs to provide a key -> don't need long term persistance for that, we simply need to handle key rotations during a single request (as described in issue ) objets derived from some underlying key however (including bound tokens) might be more tricky ( ex ). Do we need some kind of registry to keep track of the changes over time, to keep them alive even if the key changes? Or do we just consider that they get revoked? (and what happens if you fall into that case at some point, what's your next action?)
This is already managed by section 7.2 "If the flags field does not contain the bearer flag and the key is absent, the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation)"
Change:
luminaries can learn to which groups they belong, and enable their interface for the multicast address. <del> The luminary, knowing its sector, queries the RD for the endpoint with rt=light and d=R2-4-015.  The RD returns all endpoints in the sector. </del> <ins> The luminary, knowing its sector and own IPv6 address, looks up the groups containing light resources it is assigned to: </ins> <del> Knowing its own IPv6 address, the luminary discovers its endpoint name.  With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. From the base parameter value, the luminary learns the multicast address of the multicast group. </del> <ins> From the returned base parameter value, the luminary learns the multicast address of the multicast group. </ins> Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in

Discussion:
The luminary of the example previously discovered its group addresses by looking up its own registration resource (which it did not know because it was entered by a CT), and via that its groups. As long as the device does not need to know its own registration resource, the same can be achieved in a single step by looking up groups that contain it directly, based on the address it would originally have compared the endpoint results against. Closes: URL Like with : NAME that's the example where you know all the rationales, feel free to merge or discard.
In the luminary example, the device first does an endpoint lookup to find its ep by comparing values, and then a group lookup to find its groups. That is unnecessary; by the rules of lookup, it could just do a group lookup with base= its own address and get the same result in one step.
Change:
If an enterprise TURN server is present, the preferred route MUST be through this TURN server.  Once an interface has been chosen, the private IPv4 and IPv6 addresses associated with this interface <del> MUST be discovered and provided to the application.  This ensures that direct connections can still be established in this mode. </del> <ins> MUST be discovered and provided to the application as host candidates.  This ensures that direct connections can still be established in this mode. </ins> Default route only: This is the the same as Mode 2, except that the associated private addresses MUST NOT be provided; the only IP

Discussion:
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.
Change:
representation to a dynamic table entry which has already been evicted or which has an absolute index greater than or equal to the declared Required Insert Count (header-prefix), it MUST treat this as <del> a connection error of type "HTTP_QPACK_DECOMPRESSION_FAILED". </del> <ins> a connection error of type QPACK_DECOMPRESSION_FAILED. </ins> If the decoder encounters a reference in an encoder instruction to a dynamic table entry which has already been evicted, it MUST treat <del> this as a connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". </del> <ins> this as a connection error of type QPACK_ENCODER_STREAM_ERROR. </ins> 3.

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
becomes greater than or equal to the Required Insert Count for all header blocks the decoder has started reading from the stream. <del> If the decoder encounters a header block where the largest Absolute Index used is not equal to the largest value permitted by the Required Insert Count, it MAY treat this as a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED. </del> The SETTINGS_QPACK_BLOCKED_STREAMS setting (see configuration) specifies an upper bound on the number of streams which can be blocked.  An encoder MUST limit the number of streams which could

Discussion:
Currently the draft is inconsistent: if the Required Insert Count value in a header block is smaller than dictated by the referenced dynamic table entries, {{overview-hol-avoidance}} says the decoder MAY treat this as a stream error, while {{invalid-references}} says it MUST. This PR seeks to clarify this.
Change:
A TLS client making use of this specification, and which receives a DNSSEC authentication chain extension from a server, SHOULD use this information to perform DANE authentication of the server.  In order <del> to do this, it uses the mechanism specified by the RFC4035.  This mechanism is sometimes implemented in a DNSSEC validation engine or library. </del> <ins> to do this, it uses the mechanism specified by the DNSSEC protocol RFC4035 RFC5155.  This mechanism is sometimes implemented in a DNSSEC validation engine or library. </ins> <del> If the authentication chain is correctly verified, the client then performs DANE authentication of the server according to the DANE TLS protocol RFC6698 RFC7671. </del> <ins> Clients MAY cache the server's validated TLS RRset or other validated portions of the chain as an optimization to save signature verification work for future connections.  The period of such caching MUST NOT exceed the TTL associated with those records. </ins> 7.

Discussion:
Draft 05. Tried to address all the outstanding comments during the WGLC. Draft cutoff for IETF100 is Monday evening - hopefully we can submit a new version.
Change:
[[ TODO: A preliminary formal security analysis has yet to be performed on this authentication scheme.]] <del> [[ OPEN ISSUE: Currently, the group identifier, epoch and generation are contained as meta-data of the Signature.  A different solution could be to include the GroupContext instead, if more information is required to achieve the security goals regarding cross-group attacks. ]] </del> [[ OPEN ISSUE: Should the padding be required for handshake messages ? Can an adversary get more than the position of a participant in the tree without padding ? Should the base ciphertext block length be

Discussion:
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened.

:greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
Referral responses from "test" for "foo.test" must include the sibling glue (and set TC=1 if they do not fit): <ins> 5. </ins> This document clarifies correct DNS server behaviour and does not introduce any changes or new security considerations. <del> 5. </del> <ins> 6. </ins> There are no actions for IANA. <del> 6. </del> <ins> 7. </ins> The authors wish to thank Joe Abley, Brian Dickson, Geoff Huston, Jared Mauch, George Michaelson, Benno Overeinder, John R Levine,

Discussion:
work in progress. please do not merge without review & discussion.
Should we use the naming for Glue from 8499?
"Sibling domain glue" "in-domain glue" and maybe we should define "orphan glue/promoted glue". while we have 8499bis open?
IMO 8499 doesn't have glue definitions that are useful for this draft, so yeah, maybe they should be added to 8499.
Change:
Removed ART (*) <ins> Added explicit key confirmation (*) </ins> draft-01 Initial description of the Message Protection mechanism. (*)

Discussion:
At the MLS interim, the major feedback regarding authentication was that it would be good practice to provide explicit key confirmation. This PR adds an explicit confirmation field to Handshake messages, containing a MAC over the proposed (updated) state of the group, together with the latest handshake message.
Reflecting on offline conversation here: This PR derives a new key, then calculates the MAC over both the HS message and the group state; that others verify. PR 72 derives a new key, then sends that to the others to verify they all got the same key. We assume that, as the key was derived from a tree with this group state, it must be correct. These appear to test basically the same property, but I probably prefer this PR unless we can formally verify that they have the same properties (or at least the relevant ones); in which case 72 is a little more efficient.
So one question would be under what circumstances would this verify something that won't be verified by failing AEAD on any associated messages that decrypt? Or is it more just that we've now decoupled updates and message sending, so without a failing AEAD we need this to confirm too?
Thanks, NAME Absolutely agree that this needs more discussion. I'll send a ping on the list shortly.
NAME To answer your question, yes, the idea here is to fail before you get to the AEAD stage. In the spec before this PR merged, group members that arrived at different states would have different keys, but they would never find out that was the case until there was an AEAD failure. With this PR (or ), a peer know that if processing of a Handshake message succeeds, then it has the same GroupState as the sender.
Agreed that we need further discussion with academics, and modelling of the properties, but this seems good to provisionally merge.
Change:
the client can be learned.  In particular, if the client tries to hide its physical location through a Virtual Private Network (VPN), and the VPN and local OS support routing over multiple <del> interfaces (a "split-tunnel" VPN), WebRTC will discover not only </del> <ins> interfaces (a "split-tunnel" VPN), WebRTC can discover not only </ins> the public address for the VPN, but also the ISP public address over which the VPN is running.

Discussion:
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.
Change:
B (the MitM) instead of account key A (the legitimate domain holder) <del> All of the challenges above have a binding between the account private key and the validation query made by the server, via the key authorization.  The key authorization reflects the account public key, is provided to the server in the validation response over the validation channel and signed afterwards by the corresponding private key in the challenge response over the ACME channel. </del> <ins> All of the challenges defined in this document have a binding between the account private key and the validation query made by the server, via the key authorization.  The key authorization reflects the account public key, is provided to the server in the validation response over the validation channel and signed afterwards by the corresponding private key in the challenge response over the ACME channel. </ins> The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who

Discussion:
EKR pointed out to me privately a couple of remaining issues after his AD review. This PR addresses those issues.
No complaints from me, looks good. Thanks NAME
Change:
10.6. <ins> The Stream Cipher and Block Cipher algorithms need to generate different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the Block Cipher CID and at least eight octets of the Stream Cipher CID are reserved for a nonce that, if used only once, will result in unique cipher text for each Connection ID. If servers simply increment the nonce by one with each generated connection ID, then it is safe to use the existing keys until any server's nonce counter exhausts the allocated space and rolls over to zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. Configuration agents SHOULD implement an out-of-band method to discover when servers are in danger of exhausting their nonce space, and SHOULD respond by issuing a new configuration.  A server that has exhausted its nonces MUST either switch to a different configuration, or if none exists, use the 4-tuple routing config rotation codepoint. 10.7. </ins> The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly

Discussion:
Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.
Change:
(queuing, policing, shaping) are supported using the underlying link / sub-net specific mechanisms.  Service protections (packet replication and packet elimination functions) are not provided at the <del> DetNet layer end to end due the lack of a unified end to end </del> <ins> DetNet layer end-to-end due the lack of a unified end-to-end </ins> sequencing information that would be available for intermediate nodes.  However, such service protection can be provided on a per underlying L2 link and sub-network basis.

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
belonging to the same Message, and will constitute an in-order series until the endOfMessage is marked. <del> 8.2.5. </del> <ins> 8.2.4. </ins> To reduce the overhead of sending multiple small Messages on a Connection, the application could batch several Send Actions

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
If the argument value is an object, the result is the number of members in the object. <del> For any other argument value, the result is one. </del> <ins> For any other argument value, the result is "Nothing". </ins> 2.6.4.

Discussion:
For , the spec defines Why return 1? That's a possible value for to return for valid inputs. Wouldn't it make sense to return a value that can't be returned by a valid input, like -1? Currently, this returns the both objects in the array, which is counter-intuitive. The length of the property in is nonsensical because it doesn't contain an property.
Well, I picked this hoping people would notice this... We have two different cases that probably also need different answers. The one the text addresses: A non-container, non-string value, e.g., length(3) I think I can argue that 1 is a good value for that. The one the text does not address: An empty nodelist (Nothing). 1 is definitely not a good value for that. Nothing speaks for -1 except FORTRAN-era conventions. I think we want to be able to return Nothing here.
I disagree. I don't think the "length" of is 1. I think it's nonsensical. Numbers, booleans, nulls, and (really all that's left) don't have a "length." (We've also decided that we don't do any kind of type coersion, so interpreting as is invalid.) I'm happy with this.
I'd be comfortable with returning .
LGTM, thanks.
Change:
Form a URI by populating the URI template RFC6570 "http://{domain}/.well-known/acme-challenge/{token}", where: * the domain field is set to the domain name being verified; and * the <del> token field is set to the token in the authorized key object. </del> <ins> token field is set to the token in the challenge. </ins> Verify that the resulting URI is well-formed.

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
A variable-length integer error code that indicates the reason for closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in transport-error-codes.  A <del> CONNECTION_CLOSE frame of type 0x1d uses codes from the application protocol error code space; see app-error-codes. </del> <ins> CONNECTION_CLOSE frame of type 0x1d uses codes defined by the application protocol; see app-error-codes. </ins> A variable-length integer encoding the type of frame that triggered the error.  A value of 0 (equivalent to the mention of

Discussion:
This avoids the implication of a single error code space. Even if one is permissible, that is not necessary.
NAME originally posted in URL a comment highlighting that although HTTP/3 uses a single error code space for connection and stream errors, there is no requirement for other application protocol mappings to do the same. I found the text in URL to give me the wrong assumptions. This is the only mention of an error code space in the text that will make it into RFC. So I suggest in the offending paragraph we delete the 2 occurrences of "space" and just state that the frame contains a value, either defined in transport [ref] or application [ref]
"uses codes defined by the application protocol"?
Change:
A variable-length integer error code that indicates the reason for closing this connection.  A CONNECTION_CLOSE frame of type 0x1c uses codes from the space defined in transport-error-codes.  A <del> CONNECTION_CLOSE frame of type 0x1d uses codes from the application protocol error code space; see app-error-codes. </del> <ins> CONNECTION_CLOSE frame of type 0x1d uses codes defined by the application protocol; see app-error-codes. </ins> A variable-length integer encoding the type of frame that triggered the error.  A value of 0 (equivalent to the mention of

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!