jiebi/CodeConvo huggingface dataset:
Code change:
as slice bounds and must first be normalized.  Normalization for this purpose is defined as: <del> The result of the array indexing expression "i" applied to an array of length "len" is defined to be the result of the array slicing </del> <ins> The result of the array index expression "i" applied to an array of length "len" is defined to be the result of the array slicing </ins> expression "Normalize(i, len):Normalize(i, len)+1:1". Slice expression parameters "start" and "end" are used to derive

Related discussion:
text: Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.
Code change:
packet protection keys for Initial packets. The client populates the Source Connection ID field with a value of <del> its choosing and sets the SCID Length field to indicate the length. </del> <ins> its choosing and sets the Source Connection ID Length field to indicate the length. </ins> The first flight of 0-RTT packets use the same Destination Connection ID and Source Connection ID values as the client's first Initial

Related discussion:
text: Editorial NiTs when reviewing the invariant text. These NiTs address readability issues, and do not intend to change the meaning of the text.
Is there an associated issue?
Thanks Gorry, these are all quite helpful. 1) I understand the acronyms DCID and SCID, but these aren't really expanded on first use in sect 5.1. 2) There's mention of "the high bit", but there doesn't seem to be any statement of bit order saying. Is it worth declaring network byte/bit order earlier in section 4? This also clarifies the placement of fields within a byte, which was basically assumed knowledge otherwise. 3) Personally, I don't think: "The length of the Destination Connection ID is not specified" is a great choice of words. Surely, this needs to be specified somewhere for a protocol instance to use it? This reads better as something like: The length of the Destination Connection ID is not encoded in packets with a short header and is not constrained by this specification. 4) The brackets here seem to point to connection IDs in general, not the DCID "(see Section 5.3)". Is it worth writing that as "Connection IDs are described in Section 5", rather than use brackets? The same is true for versions. 5) In section 5.3: "the wrong endpoint" is taken as the wrong transport endpoint, but some of our IP and subIP colleagues would use the term endpoint for other uses, so one insertion of "transport" would perhaps help? 6) In the appendix A, this: "QUIC forbids acknowledgments of packets" - still has me wondering what is actually intended to be understood, because the list of bullets is not guarenteed ... : /The last packet before a long period of quiescence might be assumed to contain an acknowledgment (it should be assumed that QUIC could allow acknowledgments of packets that only contain ACK frames)/ I'm not sure what to say here I think the combination of not... forbids threw me off the meaning. Changes proposed in
Thanks for changing SCID/DCID to "Source Connection ID" and "Destination Connection ID", that seems like a good change.
Code change:
respectively, and the public authentication keys are denoted G_I and G_R, respectively. <del> For X.509 certificates the authentication key is represented with a </del> <ins> For X.509 certificates the authentication key is represented by a </ins> SubjectPublicKeyInfo field.  For CWT and CCS (see auth-cred)) the <del> authentication key is represented with a 'cnf' claim RFC8747 containing a COSE_Key RFC9052. </del> <ins> authentication key is represented by a 'cnf' claim RFC8747 containing a COSE_Key RFC9052.  In EDHOC, a raw public key (RPK) is an authentication key encoded as a COSE_Key wrapped in a CCS. </ins> 3.5.2. The authentication credentials, CRED_I and CRED_R, contain the public authentication key of the Initiator and the Responder, respectively. <ins> The authentication credential typically also contains other parameters that needs to be verified by the application, see auth- validation, and in particular information about the identity ("subject") of the endpoint to prevent misbinding attacks, see identities. </ins> EDHOC relies on COSE for identification of credentials (see id_cred), for example X.509 certificates RFC5280, C509 certificates I-D.ietf- cose-cbor-encoded-cert, CWTs RFC8392 and CWT Claims Sets (CCS) RFC8392.  When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 <del> certificate / CWT. </del> <ins> certificate / CWT.  The Initiator and the Responder MAY use different types of authentication credentials, e.g., one uses an RPK and the other uses a public key certificate. </ins> Since CRED_R is used in the integrity verification, see asym- msg2-proc, it needs to be specified such that it is identical when

Related discussion:
text: Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: EMAIL
Code change:
11.4. <del> During each epoch senders MUST NOT encrypt more messages than permitted by the security bounds of the AEAD scheme used. </del> <ins> During each epoch senders MUST NOT encrypt more data than permitted by the security bounds of the AEAD scheme used. </ins> Note that each change to the Group through a Handshake message will also set a new application_secret.  Hence this change MUST be applied

Related discussion:
text: Update change log for draft-07 No conflicting PRs so I did break many lines that were too long. Fix a few minor editorial issues after merging the tree-based application key schedule.
Code change:
Both of these approaches allow clients to confirm that a discovered Encrypted Resolver is designated by the originally provisioned <del> resolver.  "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. </del> <ins> resolver.  "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. </ins> 1.1.

Related discussion:
text: changed equivalence instances for designated and added the possibility of multiple entities so long as they are cooperating This is to address issue
I am not sure we need to introduce "Equivalence" nor to develop who is operating the resolvers - especially as many entities may be involved in the operation of a resolver. I am not sure we need to introduce Equivalence. If so I would propose the following text: OLD: "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. NEW: "Equivalence" in this context means that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. If Equivalence is not introduced - which I prefer -I would propose the following text: NEW: In this context the discovery process ensures that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers.
I agree that we do not need to introduce "equivalence" in this document. It is a remnant of the DEER draft DDR is based on. Per WG discussion, we want to use the term "designation" to describe the relationship between the unencrypted resolver and the encrypted resolver to which the client is transferring. I'm editing accordingly. I have also added references to the possibility of multiple "entities" as that is definitely possible. (PR coming later tonight)
good.
Code change:
If a contributor makes a comment that raises what you believe to be a new issue, create an issue for them.  If the issue has an obvious solution, consider creating a pull request.  It doesn't matter what <del> venue the issue was raised in, email, issue discussion, a pull request review, capturing issues quickly ensures that problems become visible and can be tracked. </del> <ins> venue the issue was raised in (e.g., email, issue discussion, a pull request review); capturing issues quickly ensures that problems become visible and can be tracked. </ins> This takes a little more effort, but these simple steps can help encourage contributions, which will ultimately improve the quality of

Related discussion:
text: A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara
Code change:
10.2. <del> These properties specifies configurations for the User Timeout Option </del> <ins> These properties specify configurations for the User Timeout Option </ins> (UTO), in case TCP becomes the chosen transport protocol. Implementation is optional and of course only sensible if TCP is implemented in the transport system. <del> All of the below parameters are optional (e.g., it is possible to </del> <ins> These TCP-specific properties are included here because the feature "Suggest timeout to the peer" is part of the minimal set of transport services I-D.ietf-taps-minset, where this feature was categorized as "functional".  This means that when an implementation offers this feature, it has to expose an interface to it to the application. Otherwise, the implementation might violate assumptions by the application, which could cause the application to fail. All of the below properties are optional (e.g., it is possible to </ins> specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used).

Related discussion:
text: Following the discussion in , explain why TCP UTO is included as a Protocol-Specific Property, while other properties are not. Also, some minor consistency fixes.
Thanks for doing this!Thanks
Code change:
identifiers or IP address information, to the Issuer.  Tokens produced by an Issuer that admits issuance for any type of attestation cannot be relied on for any specific property.  See <del> attester-role for more details. </del> <ins> attester for more details. </ins> 3.2.1.

Related discussion:
text: In this image: ! It isn't very clear where messages originate and who gets to see them. In particular, it isn't clear where the TokenRequest originates (the Client) and whether the Attester gets to see it (¯(°_o)/¯).
That's a fair point. It should be clear that the TokenRequest comes from the Attester. I wonder if we also somehow need to illustrate that there's a trust relationship between the Attester and Issuer here. Something to at least imply that the Attester is either implicitly trusted to do attestation, or, perhaps in future versions of Privacy Pass, attestation proofs are sent directly to the Issuer.
Move diagram to section 3 (architecture). Also move much of the second intro paragraph down. Add more text about the actual steps to section 3, such as a numbered list
In here, introduce the basic privacy premise for how the redemption and issuance contexts are separated
The architecture references [AUTHSCHEME] for key concepts far more than I expected. For instance: Or: Can the architecture define the messages in their own right, then point to [AUTHSCHEME] for example implementations?
Is the suggestion here to describe -- conceptually -- what Token and TokenChallenges are in the architecture document? If so, that seems quite reasonable.
Yeah. An architecture is most useful if you don't have to dig into the details to understand it and those references are somewhat critical to comprehension.
Code change:
otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server. <del> The "quota-policy" values and comments provided in "RateLimit-Limit" are informative and MAY be ignored. </del> <ins> The details provided in "RateLimit-Policy" are informative and MAY be ignored. </ins> If a response contains both the "RateLimit-Reset" and "Retry-After" fields, "Retry-After" MUST take precedence and "RateLimit-Reset" MAY

Related discussion:
text: moves quota-policies from RateLimit-Limit -> RateLimit-Policyrequires WG discussion -
Given this hint from Mark URL I think it's fine to merge this PR (separate Policy from Limit) since there seems to be agreement to use different fields at least in this case.
Perhaps best to continue discussion in that issue before merging this? While the change will happen in a similar vein, we might want to wait to flesh out further details.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in
The draft today suggests putting quota policies, a list, into the header. But that's a sort of breaking change, because that header's equivalent is strictly a number (not a list) in most existing implementations. Could be kept as a plain number (like and ), and instead a new header like or some such can contain supplementary information? That way, the story for upgrading to this draft is simpler. Sorry if this is asked and answered.
iirc we considered this but we initially had some requests of conflating as much as possible in fewer fields. Probably it's a more interoperable choice. I am open in re-considering the idea, provided we get in touch with the current implementers including 3scale, kong and envoy cc: 3scale: NAME , kong: NAME , envoyproxy: NAME
There's no inherent problem in using a specific header for policies, and no issue in moving to use them from the 3scale side. The only downside is we're adding yet another header for rate limiting, currently 4 of them, which might raise a few eyebrows.
Code change:
otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server. <del> The "quota-policy" values and comments provided in "RateLimit-Limit" are informative and MAY be ignored. </del> <ins> The details provided in "RateLimit-Policy" are informative and MAY be ignored. </ins> If a response contains both the "RateLimit-Reset" and "Retry-After" fields, "Retry-After" MUST take precedence and "RateLimit-Reset" MAY

Related discussion:
text: NAME thanks :) do you think that splitting is a more interoperable choice wrt to the parsing implementation / usability? Do you see other practical drawbacks? if we don't get feedback on this issue, can you ping the other implementers you know?
Yes, it's easier for people to pick up a new header for this to apply a policy, since as it stands they might break when seeing extra stuff in the limit one by expecting a single value rather than multiple, as NAME mentions above. No, just dealing with people (maybe) opposing too-many-headers - I don't know if this is something that we can predictably foresee happening in the HTTPAPI WG or in the HTTP WG, but my intuition says "likely" given how we were asked to "condense" this information, so I think we might want to spend some time making a good case out of it. NAME other than potential breakages in pre-existing implementations, is there any additional point we could make to justify the additional header? I think they are all currently listed - that being said I think porting to a new header should be an easy task, so hopefully not a problem.
if almost everyone is implementing just the minimal specification, probably this could even simplify the addition of ...
The primary motivation is breakage, as you suggest, NAME The secondary motivation is ease of "upgrading" to adoption of quota policies, as NAME suggests. The flipside of "easy to adopt, easy to upgrade" is that the spec would also make it easy to never upgrade at all. This is a good thing, supposing that most services can operate perfectly fine without quota policies. A third, much weaker argument, is that the current approach of putting the "limit" and "quota policy" in the same header is that it's confusing. I would need more time to really state this argument more clearly, but what rubs me the wrong way here is that the current design basically puts two different kinds of data in the same list. As it stands, is a list of a numbers, but the first number (the "limit") is not like the rest of the numbers (the policy). The first number cannot have SFV parameters, but the others can (and typically will). It's an accident of SFV's syntax that this is even conceivable as an approach.
Code change:
otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server. <del> The "quota-policy" values and comments provided in "RateLimit-Limit" are informative and MAY be ignored. </del> <ins> The details provided in "RateLimit-Policy" are informative and MAY be ignored. </ins> If a response contains both the "RateLimit-Reset" and "Retry-After" fields, "Retry-After" MUST take precedence and "RateLimit-Reset" MAY

Related discussion:
text: For implementors, this means that does not simply deserialize as some sort of . It deserializes into a list, where the first element is an and the tail is a . I fear this will at minimum confuse folks, and perhaps even lead to incorrect implementations, such as people not realizing the first element of the list is not a quota policy at all.
Given URL it seems there's some consensus in providing quota policy in a separate field.
Code change:
protocol execution (specifically, cipher suite, see cs) but other parameters are only communicated and may not be negotiated (e.g., which authentication method is used, see method).  Yet other <del> parameters need to be known out-of-band. </del> <ins> parameters need to be known out-of-band.  The application decides which endpoint is Initiator and which is Responder. </ins> The purpose of an application profile is to describe the intended use of EDHOC to allow for the relevant processing and verifications to be

Related discussion:
text: URL I have been reading v17 and sent some comments to the authors, that I summarize here: 1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. However, v17 may have a different meaning since it seems “credentials" is defined as follows: "EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy. 2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct? 3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement?
Yes. The document should talk about RPK a bit more as that is term that people might search for. Should be explained that CWT is the format EDHOC uses for raw public keys (RPK).
Code change:
protocol execution (specifically, cipher suite, see cs) but other parameters are only communicated and may not be negotiated (e.g., which authentication method is used, see method).  Yet other <del> parameters need to be known out-of-band. </del> <ins> parameters need to be known out-of-band.  The application decides which endpoint is Initiator and which is Responder. </ins> The purpose of an application profile is to describe the intended use of EDHOC to allow for the relevant processing and verifications to be

Related discussion:
text: Hi all: I have been reading v17 and sent some comments to the authors, that I summarize here: 1) - Regarding RPK, previous versions of the document had a more detailed explanation about RPK. For example, in version v06 you had "The Initiator and the Responder MAY use different types of credentials, e.g. one uses an RPK and the other uses a public key certificate.” So RPK is included as part of the definition of authentication credential. However, v17 may have a different meaning since it seems “credentials" is defined as follows: "EDHOC relies on COSE for identification of credentials (see Section 3.5.3), for example X.509 certificates [RFC5280], C509 certificates [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392] and CWT Claims Sets (CCS) [RFC8392]. When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 certificate / CWT. I assume RPK is also an authentication credential and this should be included in this text. A clarification would be worthy. 2) I assume it is possible that any two IoT devices can act as initiator but also as a responder, even between same two peers. It is the application which decides when to start EDHOC (initiator) in a particular case, correct? 3) It seems the EDHOC does not define any exchange for the key update (some sort of rekey). It seems an application at some point exchange some messages as "some event that triggered the key update.” Then the application call to EDHOC-KeyUpdate function to get a new PRK. Am I right? I am asking because looking at IKEv2, for example, and for the rekey, an exchange is required. Although it would add a little bit more complexity, wouldn’t it be sensical that EDHOC defines a 1 RTT to exchange a couple of nonces for the rekeying. Moreover, this function is defined in an Appendix. Is it mandatory to implement? Beyond these clarifications, I think the document is ready. Best Regards. Rafa Marin-Lopez, PhD Dept.
Code change:
protocol execution (specifically, cipher suite, see cs) but other parameters are only communicated and may not be negotiated (e.g., which authentication method is used, see method).  Yet other <del> parameters need to be known out-of-band. </del> <ins> parameters need to be known out-of-band.  The application decides which endpoint is Initiator and which is Responder. </ins> The purpose of an application profile is to describe the intended use of EDHOC to allow for the relevant processing and verifications to be

Related discussion:
text: Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: EMAIL