jiebi/CodeConvo huggingface dataset:
Change:
The order of AggregateContinueResp.prepare_shares MUST match that of the PrepareStep values in "AggregateContinueReq.prepare_shares".  The helper's response to the leader is an HTTP 200 OK whose body is the <del> AggregateContinueResp and media type is "message/ppm-aggregate- </del> <ins> AggregateContinueResp and media type is "message/dap-aggregate- </ins> continue-resp".  The helper then awaits the next message from the leader.

Discussion:
This change is basically a search-and-replace for /ppm/dap/. However, I have also re-aligned the context strings to match the next draft that will be cut (-01). I think the change is mostly correct, my main concern is the "URN Sub-namespace for PPM (urn:ietf:params:dap)" section. : Does it make sense for all drafts in the PPM WG to share the namespace, or do we want to define one specifically for DAP?
Before merging I would appreciate an answer on the question I raised above. I want to make sure the URN bits are correct.
Separate namespaces seems better, especially if we're thinking of DAP and STAR. Names are cheap, after all.
Separate namespaces, because otherwise I think we'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference. We should avoid spreading the specification across multiple documents more than necessary. Maybe including the WG in the URN path like helps?
Here's the RFC defining URL It's pretty loosely structured, and the existing sub-namespaces from published RFCs appear to just be named after protocols and formats, not working groups. URL
I took NAME suggestion of prefixing the dap space with ppm.
Change:
the capabilities of the protocol.  Once an application specifies its Transport Properties, the transport system matches the required and prohibited properties against the transport features of the available <del> protocols. </del> <ins> protocols (see Section 6.2 of I-D.ietf-taps-interface for the definition of property preferences). </ins> In the following cases, failure should be detected during pre- establishment:

Discussion:
Quoting from the end of the Section 4 overview, the earliest point in the Implementation Draft where Preference Levels are explicitly mentioned: While the capitalization of "Prohibit" and "Require" does somewhat help to indicate their role as a special term, the sentence does not scan particularly well to any reader that is yet unfamiliar with the notion of Preference Levels from the API draft. At the very least it would help to better contextualize the sentence. Suggestion 1: It could also help to not explicitly refer to any Preference Levels yet. Suggestion 2: This could be sufficient for the Section 4 overview, since Section 4.1.3 "Sorting Branches" later goes into more detail about the different properties and their handling, even if the wording is a bit terse:
Change:
When a server needs a new connection ID, it encodes one of its assigned server IDs in consecutive octets beginning with the second. <del> All other bits in the connection ID, except for the first octet, MAY be set to any other value.  These other bits SHOULD appear random to observers. </del> 5.2.

Discussion:
Writing it, I'm not sure that this makes anything conceptually clearer, but I'm open to merging it.
The clear text stream cipher and block cipher formats are specified as: I think that this difference is not necessary. In the block cipher format, the first bytes are effectively used as a nonce: using the same value and the same server ID would result in the same initial 16 bytes, with exactly the same privacy effect as failing to properly initialize the nonce in the stream-cipher case. I wish we could unify these two formats, to: With just three parameters: The scope of encryption would be 0 bytes for the clear text format, 16 bytes for the block cipher format, and a value greater than server-ID length and lower than the length of the CID for the stream cipher format. This will of course require that the first bytes of the server-use field act as a nonce. Alternately, we could have: Which achieves the same unification result, but is maybe a bit more explicit.
I think this would simplify things, yes. Though it might be worth it to separate the server-use bit into a nonce and server-use, since one has uniqueness constraints and one doesn't.
Thinking of that a bit more, it is possible to further simplify. In the case of the stream cipher, the "nonce" part cannot be more than 16 bytes long. This means that the nonce will include: All of the "server-use" bytes if the are fewer than 16 such bytes The initial 16 bytes of the "server use" field if there are more With that, for all schemes we will require just two parameters, the length of the SID and the length of the CID. This simplifies configuration and APIs. At that point, the "nonce" requirement is not particularly onerous. There is already an operational requirement that CID as a whole be unique -- conflicting values would lead to packets delivered to the wrong context. If we use "all the bytes" then the server-use field is effectively a nonce. The requirement only applies to the cases where the server use field is larger than 16 bytes. We can mention it, the same way we should mention it for the block cipher. There is a small technical weakness, because the uniqueness of the CID could also result from the randomness of the first byte.

This could be fixed by using the first byte in the encryption passes: use first-byte + server ID when encrypting the nonce if the server ID is fewer than 16 bytes. (Is there really a use case for a 16 bytes server ID? Would 15 bytes be sufficient?)
I like how this is developing. I should clarify that the "CID length" is actually the minimum length of the CID -- that's all the LB will look at. The server can pad it out to 20B but that's not relevant to the algorithm. Regarding the first byte: if using length-self-encoding, there will be little or not entropy there. I don't think the case for a 16B SID is compelling.
Change:
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, <del> Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have provided helpful comments, discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. </del> <ins> Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias Kovatsch and Jaime Jimenez have provided helpful comments, discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. </ins> 12.

Discussion:
Jaime provided a detailled review, and Matthias provided an interesting use case that helped shape the base parameter details Closes: URL Disposition: Merge with next batch
The Acknowledgements section has not been updated for quite a while; I'll update it with the reviewers before releasing -20.
Change:
The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line. <del> The "a=rtcp-mux" line MUST NOT be added unless present in the most recent answer. </del> <ins> The "a=rtcp-mux" line MUST be the same as that in the most recent answer. </ins> The "a=rtcp-mux-only" line MUST NOT be added.

Discussion:
The local description can never be wrong, because it is constructed by the browser. I also explicitly added text to make clear that the mux state for any m= line cannot change.
LGTM
Section 5.8 describes the behavior of an implementation processing its own unmodified SDP. It contains significant error language that should have been removed when SDP munging was removed. In particular, please remove all of the following: • "If an error is returned, the session MUST be restored to the state it was in before performing these steps." • "If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error." • "If any indicated RTP header extension is not supported, this MUST result in an error." • "If any indicated media format is not supported, this MUST result in an error." • "If any referenced primary payload types are not present, this MUST result in an error." The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only.
I think Adam is right about this, but I wonder if this actually belongs elsewhere, so further study needed.
This is already duplicated. This seems to be a prohibition that is stricter than RFC 5761, and if we remove it here we have removed it generally, unless I have missed somewhere else we say it. This is not appropriate for remote descriptions. We say this in 5.9. >The first bullet of section 5.8 includes: "URL it has been marked as bundle-only...," and the second includes "URL it has not been marked as bundle-only..." -- in both cases, I believe the indicated behavior is supposed to happen for any bundled section (e.g., in a re-offer or re-answer), regardless of whether it is bundle-only. Yeah, I think Adam is right about this and it's probably the result of some section refactor
Made some progress on it. Editor discussion on the mux piece. Once an m= line has mux or non-mux negotiated, that's immutable.
LG with nits
Change:
3.1. Firmware images can be conveyed to devices in a variety of ways, <del> including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and </del> <ins> including USB, UART, WiFi, BLE, low-power WAN technologies, etc.  and </ins> use different protocols (e.g., CoAP, HTTP).  The specified mechanism needs to be agnostic to the distribution of the firmware images and manifests.

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)
Change:
administrator. Cause clients to use a discovered resolver which has no <del> authenticated delegation from a client-known entity. Influence automatic discovery mechanisms such that a client uses one or more resolvers that are not otherwise involved with providing service to the client, such as: a network provider, a VPN server, a content provider being accessed, or a server that the client has manually configured. </del> <ins> designation from a client-known entity. </ins> When discovering DNS resolvers on a local network, clients have no mechanism to distinguish between cases where an active attacker with

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
GitHub prominently links to the CONTRIBUTING file on certain pages. This file SHOULD be used in preference to the README for information <del> that new contributors need.  A link to the CONTRIBUTING file from the README is advised. </del> <ins> that new contributors need.  The README SHOULD contain a link to the CONTRIBUTING file. </ins> In addition to Working Group policies, notices on repositories MUST <del> include citations for BCPs 78 and 79 (COPYRIGHT, IPR) and other IETF contribution policies.  A copy or reference to the IETF Note Well [6] is ideal. </del> <ins> include citations for the IETF Note Well [6]. </ins> 3.

Discussion:
This consolidates text about notices in the "communicating policies" section, which seems most appropriate.
Thanks!
Change:
A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately.  This Application Data can be replayed by an attacker <del> so it MUST NOT carry a self-contained trigger for any non- idempotent action. </del> <ins> so 0-RTT is not suitable for carrying instructions that might initiate any non-idempotent action. </ins> A simplified TLS handshake with 0-RTT application data is shown in tls-full.

Discussion:
These are all small, but neat improvements inspired by the feedback in .
Here are some minor editorial issues: Section 2.1: "TLS provides two endpoints with a way to establish a means of communication over an untrusted medium (that is, the Internet) that ensures that messages they exchange cannot be observed, modified, or forged." I think "observed" as used here is the wrong word. Because the encrypted form of the clear-text message will be possible to observe. Please reformulate to give actual security properties. Section 2.1: "A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately. This Application Data can be replayed by an attacker so it MUST NOT carry a self-contained trigger for any non-idempotent action." Please do not use RFC2119 words "MUST NOT" in overview. I understand the need for emphasis on this. However, I assume this is actually specified normatively elsewhere. So simply using other words to provide the emphasis and possibly a reference to the section defining this normatively. Section 5.2: "Note: The Destination Connection ID is of arbitrary length, and it could be zero length if the server sends a Retry packet with a zero-length Source Connection ID field." To my understanding the DCID is not arbitrary length, it is of any octet length between 0 and 160 bits. Does the Initial processing function need to deal with non QUIC version-1 long header packets?
Based on , labeling this as "editorial"
I think the PR resolves my issues nicely.
I liked that we dropped the MUST NOT, it's already somewhere else. I also like that we point back to quic-trans for the dcid URL
Change:
occur before the Ready Event for Connections established using Initiate. <del> An InitiateError occurs either when the set of transport properties and security parameters cannot be fulfilled on a Connection for initiation (e.g. the set of available Paths and/or Protocol Stacks meeting the constraints is empty) or reconciled with the local and/or remote Endpoints; when the remote specifier cannot be resolved; or when no transport-layer connection can be established to the remote Endpoint (e.g. because the remote Endpoint is not accepting connections, the application is prohibited from opening a Connection by the operating system, or the establishment attempt has timed out for any other reason). </del> <ins> An EstablishmentError occurs either when the set of transport properties and security parameters cannot be fulfilled on a Connection for initiation (e.g. the set of available Paths and/or Protocol Stacks meeting the constraints is empty) or reconciled with the local and/or remote Endpoints; when the remote specifier cannot be resolved; or when no transport-layer connection can be established to the remote Endpoint (e.g. because the remote Endpoint is not accepting connections, the application is prohibited from opening a Connection by the operating system, or the establishment attempt has timed out for any other reason). </ins> See also initiate-and-send to combine Connection establishment and transmission of the first message in a single action.

Discussion:
No need to have a different type of Event for initiate, listen and rendezvous.
On a PreConnection, an application uses EITHER Initiate OR Listen OR Rendezvous. Therefore, it seems unnecessary to distinguish between three types of errors. Shouldn't we have a general per-PreConnection "UnfulfilledError" instead of the InitiateError + ListenError + RendezvousError, just to shorten things a bit? An application needs more details (reasons), but it gets them as a parameter anyway when the new "UnfulfilledError" would occur.
Change:
If the Broker is unable to serve a certain client that is sending publish messages too fast, the Broker SHOULD respond with Response <del> Code 4.29, "Too Many Requests" I-D.keranen-core-too-many-reqs and set </del> <ins> Code 4.29, "Too Many Requests" I-D.ietf-core-too-many-reqs and set </ins> the Max-Age Option to indicate the number of seconds after which the client can retry.  The Broker MAY stop creating notifications from the publish messages from this client and to this topic for the

Discussion:
This mechanism is also useful for cases where the pub/sub paradigm instead of classic req/resp is desired (one-to-many, many-to-one, many-to-many communications, etc.).
Change:
status of "valid" or "invalid", corresponding to whether it considers the account authorized for the identifier.  If the final state is "valid", the server MUST add an "expires" field to the authorization. <del> When finalizing an authorization, the server MAY remove the "combinations" field (if present) or remove any challenges still pending.  The server SHOULD NOT remove challenges with status "invalid". </del> <ins> When finalizing an authorization, the server MAY remove challenges other than the one that was completed.  The server SHOULD NOT remove challenges with status "invalid". </ins> Usually, the validation process will take some time, so the client will need to poll the authorization resource to see when it is

Discussion:
This is a fairly complicated part of the protocol, and not used in practice. For instance, in Let's Encrypt's implementation, there are always three challenges, any one of which may be fulfilled by the client. After this change, all challenges are considered to be combined with an "OR." That is, any challenge within an authorization may be completed to make the authorization valid. Authorizations within the new-application object are considered to be combined with an "AND." That is, all of them must become valid before the certificate will be issued. The combination of the two means that we have similar expressiveness as before, even without the combinations array.
Change:
first act as an Attester, providing Evidence that the Owner can appraise, before the Owner would give the Relying Party an updated policy that might contain sensitive information.  In such a case, <del> mutual authentication or attestation might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. </del> <ins> authentication or attestation in both directions might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. See privacy-considerations for more discussion. </ins> 7.4.

Discussion:
1) Avoid the term "mutual attestation" 2) Add reference to CCC whitepaper for discussion of anonymous attestation Signed-off-by: Dave Thaler
Does this term (Mutual Authentication) need to be defined? Aren’t there lots of cases where mutual attestation might be employed?
We have not defined Mutual Authentication, why would Mutual Attestation be any different?
Could there be a reference to this other document, C3 document. I don’t know what it means, but all the cases here seem to ultimately rely on a unitary Verifier/Relying-Party somewhere in the chain. Maybe that’s not true… if the verifier and relying party trust each other by fiat, the roles need not be combined.
It means this: Say you have devices A (normally an Attester) and V (normally a Verifier) and RP (normally a Relying Party). A can say it won't send Evidence to V unless V first attests to A. Thus, A starts by acting as a Relying Party where V is the Attester. If A devices that V is trustworthy, then A can start sending sensitive Evidence to V. Note this does not require anywhere have a combined Verifier/Relying Party.
I can see how: "Verifier/Relying Party" looks misleading here Dave illustrated well that this text is not about a "unitary Verifier/Relying-Party" this is related to the current mutual authentication/attestation discussion that recently emerged I'll try to pitch this issues in the next meeting so we can deal with it in the same swoop as mutual authentication. Personally, I'd simply leave the text as is.
reference
closed with email: URL
Closing since Michael's comment above says "closed with email" but didn't actually close the issue EMAIL wrote: The design team closed a few remaining issues and pull requests. Two pull requests turned out to fix the same text, so we needed to be sure we really liked the text we chose. On issue , wontfix: URL -- Attester We discussed the issue of how the RP trusts that the Verifier is operating correctly. (Who Verifies the Verifier?) This does not lead to architecting a "unitary Verifier/Relying-Party somewhere in the chain", as the roles can still be split out.

When we dealt with the "mutual attestation" issue, in URL we changed text that has relevance to this issue. We have no issues open. No pull requests. If the Shepherd hasn't already started, then they should please start. Michael Richardson . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide