jiebi/CodeConvo huggingface dataset:
Code change:
Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services: <del> A long-term signature key provider which allows clients to authenticate protocol messages in a group. </del> <ins> A signature key provider which allows clients to authenticate protocol messages in a group. </ins> A broadcast channel, for each group, which will relay a message to all members of a group.  For the most part, we assume that this

Related discussion:
text: Rotating keys is important and in some cases, Signature Keys are not going to be very "long-term". Instead they're going to be rotated periodically. I thus propose we simply remove the assumption that Signature Keys are of a "long-term" nature (or otherwise "long-lived"). The second change in this PR is that I added a few words indicating explicitly that the identity must not change when updating a KeyPackage.
Code change:
3. <del> The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </del> <ins> The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </ins> While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios

Related discussion:
text: This draft attempts to address all of the issues identified during with the exception of Dealing with overload situations where further guidance has been requested from early implementers of webpush. Hi, This review is an early, i.e. pre IETF Last Call TSV-ART review. The TSV-ART reviews document that has potential transport implications or transport related subjects. Please treat it as an IETF Last call comment if you don't want to handled it during the AD review. Document: draft-ietf-webpush-protocol-09 Title: Generic Event Delivery Using HTTP Push Reviewer: M. Westerlund Review Date: Sept 27, 2016 Below are a number of comments based on my review. The one with transport related subject is the overload handling in comment 4. Section 3: So the Security Considerations do require use of HTTP over TLS. However, I do wonder if there would be a point to move that requirement up into the relevant connection sections, like 3. Especially as when one reads the confidentiality requirement in Section 4 for the message one wonders a bit why it is not explicitly required in section 3. Section 5.2: TTL = 1*DIGIT Shouldn't the upper range for allowed values be specified here. At least to ensure that one doesn't get interoperability issues. Section 7.2: To limit the number of stored push messages, the push service MAY either expire messages prior to their advertised Time-To-Live or reduce their advertised Time-To-Live. Do I understand this correctly, that theses options are push service side actions that is not notified at that point to the application server? Instead it will have to note that the message was early expired if it subscribes to delivery receipts? Dealing with overload situations Reviewing Section 7.1 and other parts I find the discussion of how overload situations of various kinds are dealt with missing some cases. So the general handling of subscriptions are covered in Section 7.1 and with a mitigation of redirecting to another server to handle the new subscription. What I lack discussion of are how any form of push back are handled when first the deliver of push service to UA link is overloaded. Is the assumption here that as the push service can store messages the delivery will catch up eventually, or the message expires?
Code change:
3. <del> The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </del> <ins> The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </ins> While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios

Related discussion:
text: How does one handle a 0-RTT messages when one has a queue of messages to deliver, despite having a UA to Push service connection? The second case is how the push service server can push back on accepting new message when it is overloaded. To me it appears that the load on a push service can be very dynamic. Thus overload can really be periods. Thus, what push back to application servers is intended here? Just, do a 503 response on the request from the application server? I do note that RFC 7231 does not appear to have any guidance one how one sets the Retry-After header to spread the load of the retries. This is a known issue. And in this context with automated or external event triggered message creations the push back mechanism needs to be robust and reduce the issues, not make them worse. I would recommend that some recommendations are actually included here for handling overload from application server message submissions. Life of subscription in relation to transports I find myself a bit perplexed of if there are any relation between the subscription and the relation to an existing transport connection and outstanding request, i.e. the availability to receive messages over push. I would guess, that there are no strict need for terminating the subscription even if there are no receiver for an extended time. However, from an application perspective there could exists reason for why a subscription would not be terminated as long as the UA is connected, while any longer duration of no connections could motivate the subscription termination. I personally would like a bit more clarification on this, but seeing how these issues are usually handled around HTTP, I would guess the answer, it will be implementation specific? Still there appear to be assumptions around this, why it wouldn't matter that much, but that is only given that one follows these assumptions. Unclarities which requests that require HTTP/2. The specification is explicit that some request can be performed over HTTP/1.x. However, it is not particular clear which requests that require HTTP/2. I assume all the GET requests that will hang to enable PUSH promises needs to be HTTP/2? Maybe this should be clarified?
Code change:
3. <del> The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </del> <ins> The push service MUST use HTTP over TLS [RFC2818] following the recommendations in [RFC7525].  The push service shares the same default port number (443/TCP) with HTTPS, but MAY also advertise the IANA allocated TCP System Port 1001 using HTTP alternative services RFC7838. </ins> While the default port (443) offers broad reachability characteristics, it is most often used for web browsing scenarios

Related discussion:
text: Cheers Magnus Westerlund Services, Media and Network features, Ericsson Research EAB/TXM Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: EMAIL
Code change:
and validate the version_information transport parameter specified in QUIC-VN to prevent version downgrade attacks. <del> Note that version 2 meets that document's definition of a compatible </del> <ins> Note that version 2 meets the QUIC-VN definition of a compatible </ins> version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions.  Endpoints that support both

Related discussion:
text: here (URL) it is better that we call it QUIC version 1 not just QUIC. As later it is referred as QUIC version 1.here (URL) I would add reference to VN draft instead of calling it "that document"here (URL) i would add "packet" after "Initial" just to be clear, as we have now a initial version in VN draft.
Thanks, fixed here URL
Code change:
extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED.  IESG Approval is REQUIRED for a Yes->No transition. <ins> IANA [SHALL update/has added] the following notes: Experts are to verify that there is in fact a publicly available specification.  An Internet Draft that is posted and never published or a specification in another standards body, industry consortium, university site, etc. suffices. As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. Extensions marked as "Yes" are those allocated via Standards Track RFCs.  Extensions marked as "No" are not. If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> The following is from I-D.ietf-tls-tls13 and is included here to ensure alignment between these specifications.

Related discussion:
text: NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Code change:
4.1. <del> 4.1.1. </del> <ins> This document registers a new entry under the IETF URN Sub-namespace defined in RFC3553: </ins> <del> Registry name: Captive Portal Unrestricted Identifier </del> <ins> Captive Portal Unrestricted Identifier </ins> <del> URN: urn:ietf:params:capport-unrestricted </del> <ins> urn:ietf:params:capport-unrestricted </ins> <del> Specification: RFC TBD (this document) </del> <ins> RFC TBD (this document) </ins> <del> Repository: RFC TBD (this document) </del> <ins> RFC TBD (this document) </ins> <del> Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </del> <ins> Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </ins> 4.2.

Related discussion:
text: Note that I do need you both to confirm that you have fulfilled IPR obligations.
Thank you!
Code change:
Indicates that interaction through some set of defined mechanisms needs to take place. <del> Claims about the RO as known and declared by the AS. </del> <ins> Claims about the RO as known and declared by the AS, as described in response-subject. </ins> An identifier this client instance can use to identify itself when making future requests. <del> An identifier this client instance can use to identify its current end-user when making future requests. </del> An error code indicating that something has gone wrong. In this example, the AS is returning an response-interact-redirect, a

Related discussion:
text: Opaque identifiers provide a generic reference, so we can simplify the text. (mainly), and as a byproduct also and - removed userhandle from main response in section 3 changed title of section 3.4 (User -> Subject) and moved the text that requires RO = end-user at the top of the section, for clarity changed name (userhandle -> user) and wording in section 3.5. Maybe we could also simplify the title "Returning Dynamically-bound Reference Handles" into "Returning Reference Handles" (didn't do it yet).
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 73de700ce82846ec5e09f8f60550fac7bee0dfb5 Inspect the deploy log: Browse the preview:
With the adoption of the subject identifier format, we no longer need to have a GNAP-specific value and can instead leverage this more standard field. Alternatively, we could have a GNAP-specific subject identifier format, instead of a separate field.
In section 2.4 (Requesting User Information), the first sentence starts with: If the client instance is requesting information about the RO from the AS, ... From the title, the acronym "RO" should be changed into "end-user". The case where the RO is also the end-user is a specific case. This leads to the following change: If the client instance is requesting information about the end-user from the AS, ... In the following sentences of this section, RO should be changed into end-user.
The current text really means RO, and generally considers the case end-user = RO. Any other case would even trigger an error: "If the identified end-user does not match the RO present at the AS during an interaction step, the AS SHOULD reject the request with an error." (section 2.4) Which makes sense because why would we return something about the RO to a potentially unknown end-user? (the only problem is that this wording is buried in the text, so it's hard to understand) Back to the general case: The RO is in control of policies at the AS. The end-user is in control of a client and a request to the AS. The end-user and client may or may not have any prior relationship with the AS.
Code change:
Indicates that interaction through some set of defined mechanisms needs to take place. <del> Claims about the RO as known and declared by the AS. </del> <ins> Claims about the RO as known and declared by the AS, as described in response-subject. </ins> An identifier this client instance can use to identify itself when making future requests. <del> An identifier this client instance can use to identify its current end-user when making future requests. </del> An error code indicating that something has gone wrong. In this example, the AS is returning an response-interact-redirect, a

Related discussion:
text: The subject info is what is known by the AS (in theory could be RO and maybe end-user, but notice that in the terminology, we define the end-user as a natural person and the RO as a subject entity). I think we should clarify when we could have a remote RO too. Then do we even return a result if the AS knows something about the end-user? (different from RO in that case). Plus we need to keep in mind that we also use sub_ids for URL In general, we might want to avoid the term "user" as it is not specific enough.
The title has been changed into "Requesting Subject information". This title is incorrect as long as a subject can be also an organization or a device. An AS can hold information about an end-user or about RO when the RO is a human being. It does not hold information about organizations or devices. However, an end-user may belong to some organizations or/and use some devices. IMO, I would replace it by "Requesting end-user Information". If an AS holds information about an end-user, it seems logical that the end-user should have access to it. If it happens that the end-user has also a RO account on the AS, then it should also have access to it. In such a case, another section with the following title "Requesting RO Information" should be created. RO = end-user was a common case in OAuth. In GNAP and in the general case a RO is different from an end-user and an AS may have no relationship with any RO (e.g. when attributes only are being used).
I guess you refer to "2.2. Requesting Subject Information". We might have to harmonize a bit, but for instance "2.3. Identifying the Client Instance" might very well hold information about devices or at least the software running on it (that's the point of client software attestation to be discussed in ) We don't always know in advance whether it will be a RO or an end-user only, so the proposal isn't always applicable.
I was indeed referring to "2.2. Requesting Subject Information" which has no relationship with "2.3. Identifying the Client Instance".
Code change:
Indicates that interaction through some set of defined mechanisms needs to take place. <del> Claims about the RO as known and declared by the AS. </del> <ins> Claims about the RO as known and declared by the AS, as described in response-subject. </ins> An identifier this client instance can use to identify itself when making future requests. <del> An identifier this client instance can use to identify its current end-user when making future requests. </del> An error code indicating that something has gone wrong. In this example, the AS is returning an response-interact-redirect, a

Related discussion:
text: This means that your arguments do not apply to section 2.2. and, by implication, that my argumentation currently remains valid.
Well, I take the point in consideration but I don't think we should base our reasoning on the structure of sections, which can change
Identifying the User by Reference: Editor's note: We might be able to fold this function into an unstructured user assertion reference issued by the AS to the RC. We could put it in as an assertion type of "gnap_reference" or something like that. Downside: it's more verbose and potentially confusing to the client developer to have an assertion-like thing that's internal to the AS and not an assertion.
Why an assertion? Is that reference supposed to be linked to a session (cf "represent the same end-user to the AS over subsequent requests") or can it be persistent? I would see that more as an opaque identifier, rather than an assertion. Something like: asref seems a bit specific to GNAP (reference managed by the AS) but it could always be read "as a reference" in a more general setting. There's a variety of generic names that we could choose if needed, localuid, internal_uid, etc. But that really asks what additional types we could define as part of secevents (section 7.1.2). Beyond the case mentioned here, it would be most useful as an opaque identifier when RO != end-user, to avoid leaking private info about the RO (although currently we don't seem to cover that case yet) It's indeed more verbose than "user": "XUT2MFM1XBIKJKSDU8QM" but at least it's always the same structure (doesn't depend whether it's a reference or not), and it also makes the type more explicit.
A subject identifier makes sense here, and I agree that it should be a new value to let us constrain it to the GNAP context.
Fixed by SECEVENT opaque identifiers
I don't think this goes far enough -- I am thinking that with the opaque identifiers we can now simply return a with a format of that the client can be allowed to send in a follow-up request if it wants to. This way they all get treated equally, there's no special field anymore.
Code change:
attributes to provide better information about the statistical properties of the measurement. <del> A SenML object is referred to as "expanded" if it does not contain any base values and has no relative times. </del> 4.4. <ins> Sometimes it is useful to be able to refer to a defined normalized format for SenML records.  This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. A SenML Record is referred to as "resolved" if it does not contain any base values and has no relative times, but the the base values of the SenML Pack (if any) are applied to the Record.  That is, name and base name are concatenated, base time is added to the time of the Record, if Record did not contain Unit the Base Unit is applied to the record, etc.  In addition the records need to be in chronological order. TODO add example 4.5. </ins> SenML is designed to carry the minimum dynamic information about measurements, and for efficiency reasons does not carry significant static meta-data about the device, object or sensors.  Instead, it is

Related discussion:
text: The link was missing from schema. After this is merged, all the example need to be regenerated.
Given we want the l to have a defined integer value in the CBOR table, I think a good approach is define the l attribute as a string here then say what goes in it in the other draft that defines link. This is also good for EXI.
Code change:
the "confirmation" value in the MLSPlaintext.  Sign the MLSPlaintext using the current epoch's GroupContext as context. <del> Complete the GroupInfo by populating the following fields: </del> <ins> Update the tree in the provisional state by applying the direct path </ins> <del> Confirmed transcript hash: The confirmed transcript hash including the current Commit object </del> <ins> Construct a GroupInfo reflecting the new state: </ins> <del> Interim transcript hash: The interim transcript hash including the current Commit object </del> <ins> Group ID, epoch, tree, confirmed transcript hash, and interim transcript hash from the new state </ins> <del> Confirmation: The confirmation from the MLSPlaintext </del> <ins> The confirmation from the MLSPlaintext object </ins> Sign the GroupInfo using the member's private signing key Encrypt the GroupInfo using the key and nonce derived from the <del> "init_secret" for the current epoch (see welcoming-new-members) </del> <ins> "epoch_secret" for the new epoch (see welcoming-new-members) For each new member in the group: Identify the lowest common ancestor in the tree of the new member's leaf node and the member sending the Commit Compute the path secret corresponding to the commonn ancestor node Compute an EncryptedKeyPackage object that encapsulates the "init_secret" for the current epoch and the path secret for the common ancestor. </ins> <del> For each new member in the group, compute an EncryptedKeyPackage object that encapsulates the "init_secret" for the current epoch. </del> Construct a Welcome message from the encrypted GroupInfo object and the encrypted key packages.

Related discussion:
text: This PR adapts the Welcome logic so that the new joiners get their path secrets directly, rather than from a DirectPath. This cleans things up in a few ways. The new joiners no longer have to have the context for the previous epoch (which was used to encrypt the DirectPath). And we can get away with one HPKE operation per new joiner instead of two (one for the EncryptedKeyPackage and one for the DirectPath). The major cost is that there's a bit more complexity in the TreeKEM. Instead of just producing and consuming DirectPaths, you now need to know which path secrets go with which nodes. You also need tree math to identify the common ancestor of two leaves, but there's a simple closed-form formula for that, expressed in the Python code here.
NAME - Curious if this seems implementable to you. Clearly it's possible, since I did it in Go :) But it also needs to make sense to other people.
Code change:
fields to provide better information about the statistical properties of the measurement. <ins> In summary, the structure of a SenML record is laid out to support a single measurement per record.  If multiple data values are measured at the same time (e.g., air pressure and altitude), they are best kept as separate records linked through their Time value; this is even true where one of the data values is more "meta" than others (e.g., describes a condition that influences other measurements at the same time). </ins> 4.4. Sometimes it is useful to be able to refer to a defined normalized

Related discussion:
text: Dave's comments: The issue is that neither of the above have an asterisk by them, so both are recommended and per Carsten’s definition of “units” during the meeting (i.e., where the reference point is separate from the units), then Kelvin and Celsius have the same units as they only vary by what the reference point is.