jiebi/CodeConvo huggingface dataset:
Change:
registrar's proximity. The "prior-signed-voucher-request" leaf is used in registrar voucher- <del> requests.  If present, it is the encoded (signed form) of the pledge voucher-request.  This provides a method for the registrar to forward the pledge's signed request to the MASA.  This completes transmission of the signed "proximity-registrar-cert" leaf. </del> <ins> requests.  If present, it is the signed pledge voucher-request.  This provides a method for the registrar to forward the pledge's signed request to the MASA.  This completes transmission of the signed "proximity-registrar-cert" leaf. </ins> Unless otherwise signaled (outside the voucher-request artifact), the signing structure is as defined for vouchers, see RFC8366.

Discussion:
This should be a complete set of diffs for removing unsigned pledge voucher-requests from the text.
For issue
The text "This artifact may be optionally signed" is buried in the yang module (ietf-voucher-URL) and needs to be removed.
When a pledge decides to use an unsigned voucher request, the Registrar will place it into prior-signed-voucher request on the BRSKI-MASA arc. It will be JSON embedded in. When a pledge decides to use a signed voucher request, the Registrar will place the base64 encode of the pledge_request in as a string. The MASA can tell the difference between the two because the signed thing (whether CBOR, COSE, CMS signed CBOR, or CMS signed JSON) will always be base64 encoded. We need to explain this somewhere.
section 5.5 indicates that: prior-signed-voucher-request: If a signed pledge voucher-request was received then it SHOULD be included in the registrar voucher- request. (NOTE: what is included is the complete pledge voucher- request, inclusive of the 'assertion', 'proximity-registrar-cert', etc wrapped by the pledge's original signature). If a signed voucher-request was not recieved from the pledge then this leaf is omitted from the registrar voucher request. This indicates that the MASA never needs to "tell the difference" only the registrar. (The pledge to registrar signaling is via request media type as detailed in s5.2). I did notice this when reading: s3.3. these references to voucher in the leaf description should be to voucher request? "If it is necessary to change a voucher, or re-sign and forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field." etc. subsequent paragraphs.
URL tries to fix the lack of specification for unsigned voucher requests.
Max to produce a draft branch that removes unsigned voucher request so we can examine the ramifications of this.
v20 of BRSKI removed unsigned voucher requests. What were the reasons for removing? I don't see a mention of this in the anima WG email. If removed as a final decision, then this issue can be closed also.
Hi, yes, we could close this now. I did post several times to the list in Feb and March, and it was raised during the WG meeting itself, asking for feedback.

Ok, I now see the email list discussion also in December 2018 and based on this the unsigned voucher was removed.
Change:
were or might be processed in this connection.  The server sends a client-initiated bidirectional Stream ID; the client sends a Push ID. Requests or pushes with the indicated identifier or greater are <del> rejected by the sender of the GOAWAY.  This identifier MAY be zero if no requests or pushes were processed. </del> <ins> rejected (request-cancellation) by the sender of the GOAWAY.  This identifier MAY be zero if no requests or pushes were processed. </ins> The information in the GOAWAY frame enables a client and server to agree on which requests or pushes were accepted prior to the

Discussion:
I still don't feel like this flows quite right, so suggestions appreciated.
it better be clarify Implementation means Client/Server or both. there are some of similar terms reset cancel reject abort (abruptly) terminate it seems better to make them more clarify what each of them describes and how they can be done.
"Implementations," throughout the document, refers to both clients and servers. Do you have a suggested place to clarify this? "reset" and "abrupt termination" are synonyms for the same operation in "cancel" and "reject" are separate actions an implementation can take, described in It looks like "abort" is used with relatively little context -- I'll try to clean that up a bit. It's intended to refer to "abort reading," another operation in .
I thought this section says about client, but suddenly appears. Clients can cancel requests by ~ When the client aborts reading a response ~ Implementations SHOULD cancel requests by ~ so I think this is also a client (that says about cancel response). but you mean this says both client/server ? server can cancel request too ? SGTM > I'll try to clean that up a bit
Yes, servers can cancel a request; that is, indicate that for some reason they will not be processing it any further. But perhaps it would be clearer to separately state that in a paragraph about server behavior.
Thank you for improving the specs!
Change:
representations. Multiple endpoint identifiers can be specified for each Local <del> Endpoint and RemoteEndoint.  For example, a Local Endpoint could be </del> <ins> Endpoint and Remote Endpoint.  For example, a Local Endpoint could be </ins> configured with two interface names, or a Remote Endpoint could be specified via both IPv4 and IPv6 addresses.  These multiple identifiers refer to the same transport endpoint. <del> The transport services API will resolve names internally, when the </del> <ins> The transport services API resolves names internally, when the </ins> Initiate(), Listen(), or Rendezvous() method is called establish a <del> Connection.  The API does not need the application to resolve names, and premature name resolution can damage performance by limiting the scope for alternate path discovery during Connection establishment. The Resolve() method is, however, provided to resolve a Local Endpoint or a Remote Endpoint in cases where this is required, for example with some Network Address Translator (NAT) traversal protocols (see rendezvous). </del> <ins> Connection.  The API explicitly does not require the application to resolve names, though there is a tradeoff between early and late binding of addresses to names.  Early binding allows the API implementation to reduce connection setup latency, at the cost of potentially limited scope for alternate path discovery during Connection establishment, as well as potential additional information leakage about application interest when used with a resolution method (such as DNS without TLS) which does not protect query confidentiality. The Resolve() action on Preconnection can be used by the application to force early binding when required, for example with some Network Address Translator (NAT) traversal protocols (see rendezvous). </ins> 5.2.

Discussion:
as I started reviewing issues in advance of the interim, I saw that was already mostly fixed, but I made a few editorial changes to the language there.
Change:
6.5. <del> There are cases where useless repaired symbols may be transmitted. </del> <ins> There are cases where useless repair symbols may be transmitted. </ins> These impact on the network load and may reduce the goodput of the flow without concrete gains. 6.5.1. In this case, the discussion depends on application needs.  The only <del> case where adding useless repaired symbols does not result in reduced </del> <ins> case where adding useless repair symbols does not result in reduced </ins> goodput is when the application needs a limited amount of goodput <del> (e.g., VoIP traffic).  In this case, the useless repaired symbols would only impact the amount of data generated in the network. </del> <ins> (e.g., VoIP traffic).  In this case, the useless repair symbols would only impact the amount of data generated in the network. </ins> 6.5.2. The sender may exploit the information given by the receiver to <del> reduce the number of useless repaired symbols and the resulting goodput reduction. </del> <ins> reduce the number of useless repair symbols and the resulting goodput reduction. </ins> 6.5.3. <del> In this case, the useless repaired symbols only impact the load of the network without actual gain for the coded flow. </del> <ins> In this case, the useless repair symbols only impact the load of the network without actual gain for the coded flow. </ins> 7.

Discussion:
Small changes, nothing urging, should be easy to merge if you are ok with it :-)
Change:
permit these streams to open, an HTTP/3 server SHOULD configure non- zero minimum values for the number of permitted streams and the initial stream flow control window.  So as to not unnecessarily limit <del> parallelism, at least 100 requests SHOULD be permitted at a time. </del> <ins> parallelism, at least 100 request streams SHOULD be permitted at a time. </ins> HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams.  Clients MUST treat

Discussion:
NAME said
NAME said
Honestly, this whole sentence is a bit awkward. I'll improve that.
NAME said
I have to say, this is a little odd. HTTP requires case insensitive comparison, but by calling it out here, the juxtaposition is weird. As we force lowercase, we could just strike: "that are compared in a case-insensitive fashion"
The first is a statement of fact about what SEMANTICS requires. However, I agree that we reduce confusion and lose nothing by making the statement less explicit. Interested parties can read SEMANTICS.
Yes, the proposed text addresses my comments. Thanks for the updates.
Change:
6. <del> Supporting manageability of QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. </del> <ins> QUIC is an encrypted and authenticated transport.  That means, once the cryptographic handshake is complete, QUIC endpoints discard most packets that are not authenticated, greatly limiting the ability of an attacker to interfere with existing connections. However, some information is still observerable, as supporting manageability of QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. More security considerations for QUIC are discussed in QUIC-TRANSPORT and QUIC-TLS, generally considering active or passive attackers in the network as well as attacks on specific QUIC mechanism. Version Negotiation packets do not contain any mechanism to prevent version downgrade attacks.  However, future versions of QUIC that use Version Negotiation packets are require to define a mechanism that is robust against version downgrade attacks.  Therefore a network node should not attempt to impact version selection, as version downgrade may result in connection failure. </ins> 7.

Discussion:
This is a proposal to mention some more things specifically in the security considerations section. At minimum we should add a sentence pointing the reader at the security consideration of the transport and tis drafts. I additionally, more or less, copied some notes from the transport draft that I found particular relevant for reader of the manageability draft. Comments welcome!
NAME any further thought here?
After removing normative language, it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or (especially) Applicability.
Change:
by the objects are equal. a comparison using the operator "<" yields true if and only if the <del> comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </del> <ins> comparison is between values which are both numbers or both strings and which satisfy the comparison: </ins> numbers expected to interoperate as per RFC7493 MUST compare using the normal mathematical ordering; numbers not expected to

Discussion:
JSON types are not used much in the JSON spec. It is debatable whether there really is a boolean type or simply the values and . Also, the JSONPath spec doesn't really benefit from this term.
I think this reads well without breaking any semantics.
Change:
a context that has a different origin than the top-level browsing context), or a private browsing context. <del> 6. </del> <ins> 7. </ins> <del> 6.1. </del> <ins> 7.1. </ins> The implementation of this proposal requires the mDNS querying capability of the browser for registering mDNS names or adding remote

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
6.1. <del> An application server can use the Push-Receipt header field to request a confirmation from the push service when a push message is delivered and acknowledged by the user agent.  The Push-Receipt header field is a URI-Reference as defined in Section 2.7 of RFC7230. </del> <ins> An application server can use the "urn:ietf:params:push:receipt" link relation type to request a confirmation from the push service when a push message is delivered and acknowledged by the user agent. </ins> <del> The application sets the Push-Receipt header field value to a receipt </del> <ins> The application sets the link relation value to a receipt </ins> subscription URI.  This receipt subscription resource MUST be created from the same receipt subscribe resource which was returned with the push message subscription response (see message_subscription).

Discussion:
Is there any value in using a link relation type for the receipt subscription rather than a new header field? We already have to define the link relation type, so maybe it can save on a bit of protocol machinery.
While considering this, I noticed an editorial error in Section 10.2 where the link relation is referenced as urn:ietf:push:receipts instead of urn:ietf:push:receipt which is used throughout the rest of the draft. Using a link relation might be more consistent - not sure that it saves on protocol machinery? Are you proposing to replace the Push-Receipt header with a new link relation - potentially there would be: push:receipts - to create new receipt subscriptions push:receipt - a specific receipt subscription
Yes, there are the same number of moving parts. My mistake. Just remembered the actual reason for opening the issue. The HTTP working group often state that header fields need to have wide applicability for them to be defined, otherwise the data they carry is best carried in payload bodies. The same restriction does not apply to link relations.
Change:
POST-as-GET request to the URL returns "Not Found" or "Unauthorized". For example, suppose that the CA uses highly structured URLs with <del> several low-entropy fields: </del> <ins> guessable fields: </ins> Accounts: https://example.com/:accountID <del> Orders: https://example.com/:accountID/:orderID </del> <ins> Orders: https://example.com/:accountID/:domainName </ins> <del> Authorizations: https://example.com/:accountID/:authorizationID </del> <ins> Authorizations: https://example.com/:accountID/:domainName </ins> <del> Certificates: https://example.com/:accountID/:certID </del> <ins> Certificates: https://example.com/:accountID/:domainName </ins> <del> If the ID fields have low entropy, then an attacker can find out how many users a CA has, how many authorizations each account has, etc. </del> <ins> Under that scheme, an attacker could probe for which domain names are associated with which accounts, which may allow correlation of ownership between domain names, if the CA does not otherwise permit it. </ins> <del> In order to avoid leaking these correlations, servers SHOULD assign capability URLs for dynamically-created resources W3C.WD-capability- urls-20140218.  These URLs incorporate large unpredictable components to prevent third parties from guessing them.  These URLs SHOULD NOT have a structure that would enable a third party to infer correlations between resources. For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource: </del> <ins> To avoid leaking these correlations, CAs SHOULD assign URLs with an unpredictable component.  For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource: </ins> Accounts: https://example.com/acct/:accountID

Discussion:
Fix a misuse of the term "capability URL." Change the example. Hiding the number of accounts was not a great example, because even with randomized account URLs, an attacker could probe the space of URLs to estimate their density.
Thanks for slimming this down. I can live with this version.Thanks NAME This looks fine to me.
Change:
9.6. <del> IANA is asked to extend the reference for the "core" URI suffix in the "Well-Known URIs" registry to reference this document next to RFC6690, as this defines the resource's behavior for POST requests. </del> <ins> IANA is asked to permanently register the URI suffix "rd" in the "Well-Known URIs" registry.  The change controller is the IETF, this document is the reference. </ins> 9.7.

Discussion:
No deployed implementations of simple registration are known that can't switch over easily. As per URL
Change:
specific usage for each media type is outlined in Sections 4 and 5. <del> "a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. One or more "a=fingerprint" line(s) for each of the endpoint's certificates, as specified in I-D.ietf-mmusic-4572-update. An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5. The role value in the answer MUST be "active" or "passive"; the "active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. If present in the offer, an "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4.3. If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. </del> For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is

Discussion:
NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits
Change:
A DNS API Server MUST be able to process application/dns- udpwireformat request messages. <del> A DNS API Server SHOULD respond with HTTP status code 415 upon receiving a media type it is unable to process. </del> <ins> A DNS API Server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to process. </ins> This document does not change the definition of any HTTP response codes or otherwise proscribe their use.

Discussion:
minor editoral changes
thanks for these. The only one that's a little iffy is the inclusion of the reason phrase for 415... but I think here its giving more explanatory value than an impression that particular phrase needs to be used (which wouldn't jibe with http details).
Change:
plaintext SNI name.  This restriction allows a client to reject resumptions in auth-public-name. <del> Note that an unrecognized ClientEncryptedCH.config_digest value may be a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to </del> <ins> Note that an unrecognized ClientEncryptedCH.config_id value may be a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to </ins> abort if ECH was required.  In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (misconfiguration).  Instead, servers can measure occurrences of the

Discussion:
Also, rename configdigest to configid to avoid confusion with cryptographic hash digests. cc NAME NAME NAME
It's bound by the size o the HPKE KDF output size, which is unlikely to be larger than 32B. Let's make this:
We should also add a requirement for the HPKE ciphersuite. E.g., 'Nh <= 2^8`.
(Careful with fenceposts: .) If config_digest is the output of a KDF, why could you not fix the length to something that is enough to avoid collisions (16 bytes seems ample for this) and not worry about Nh at all?
I think it makes sense to let the KDF dictate the security level, i.e., the collision probability of the config_digest.
I would argue that collision probability here doesn't contribute to security. If a config is misidentified, the result will be failure, not a reduction in security. A failure either because the group doesn't match or because peers end up disagreeing on keys.
True that it's an operational consideration rather than a security one. I still think it makes sense to let the length of be dictated by the KDF, since whether truncation is an operational risk depends on the KDF.
I assume here that a KDF is capable of producing uniform random bytes of arbitrary length, meaning that truncation isn't a factor. That's what is for, right?
That assumption holds if the input has sufficient entropy. Since the public key is public, there's no entropy from the point of view of an adversary who wants to distinguish the output from random.
(To be clear, I think truncating to something reasonable, like 16 bytes, is low risk. I would be fine with doing this.)
Change:
send this message when authenticating via a certificate.  Clients MUST send this message whenever authenticating via a Certificate (i.e., when the Certificate message is non-empty).  When sent, this <del> message MUST appear immediately after the Certificate Message and </del> <ins> message MUST appear immediately after the Certificate message and </ins> immediately prior to the Finished message. Structure of this message:

Discussion:
It could be just me, but the previous wording was kind of confusing (YMMV).
Change:
However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that <del> "time(OP) - time(NR) < Threshold". </del> <ins> "time(OP_r)-time(NR_r) < Threshold". </ins> The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a <del> validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(ER) < time(RX)-time(RG)". </del> <ins> validity lifetime in terms of "time(RX_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)- time(RG_v)". </ins>

Discussion:
Per offline discussion between Henk and Dave, trying this annotation to see if it helps Also try combining VG and AA into VC since nothing in doc uses AA, and any example could use either VG or AA, so combining makes any example work for both. Signed-off-by: Dave Thaler
Change:
"Yes".  All others are "No".  A Standards Track document RFC8126 is required to register a certificate type with the value "Yes".  Future Certificate Types MUST define the value of this column.  A Standards <del> Track document RFC8126 is required to register an entry with the value "Yes". </del> <ins> Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG action is REQUIRED for a Yes->No transition. </ins> See expert-pool for additional information about the designated expert pool.

Discussion:
Addresses .
Our esteemed Shepherd has pointed out that we need to specify the rules for going from Yes->No. After consulting the list, we settled on "IESG action is REQUIRED for a Yes->No transition."
Closed as part of .