jiebi/CodeConvo huggingface dataset:
Change:
Preference)".  Instances take a sequence of values each valid for the corresponding value type. <del> Array: Denoted []Type, an instance takes a value for each of zero or more elements in a sequence of the given Type.  An array may be of fixed or variable length. </del> <ins> Array: Denoted "[]Type", an instance takes a value for each of zero or more elements in a sequence of the given Type.  An array may be of fixed or variable length. </ins> Collection: An unordered grouping of one or more values of the same type.

Discussion:
Review the use of and markdown in the API document, and make it consistent.
A fantastic PR! The best ever!
Change:
server", "security-aware resolver", "security-aware stub resolver", and "security-oblivious 'anything'".  (Note that the term "validating resolver", which is used in some places in <del> DNSSEC-related documents, is also not defined.) </del> <ins> DNSSEC-related documents, is also not defined in those RFCs, but is defined below.) </ins> "A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure

Discussion:
…st label', and remove dbound. Fix affiliation. I suggest these before publication. This addresses issue 18.
Yep, these all seem great.
Change:
distinguish different origin client endpoints.  Following from the recommendation above, a proxy that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks. <del> The proxy MAY use Echo to verify origin reachability as </del> <ins> The proxy SHOULD use Echo to verify origin reachability as </ins> described in echo-proc.  The proxy MAY forward idempotent requests immediately to have a cached result available when the client's Echoed request arrives. <ins> Amplification mitigation should be used when the the response would be more than three times the size of the request, considering the complete frame on the wire as it is typically sent across the Internet.  In practice, this allows UDP data of at least 152 Bytes without further checks. When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or non-confirmable response, never as a separate one (which would cause amplification due to retransmission). </ins> A server may want to use the request freshness provided by the Echo to verify the aliveness of a client.  Note that in a deployment with hop-by-hop security and proxies, the server can

Discussion:
I take URL as a mandate to make Echo mitigation of amplification issues a more prominent point in ERT. (It wasn't intended as an update, as the SHOULD mentioned there is just a copy of the original 7252 SHOULD and we "provide one way", but no objections from me either). Along that I'd offer concrete size numbers, and a note that this really needs piggy-backed responses. Unless objected to, I'd take this into the next version of ERT (as soon as I have processed any other pending comments if there still are any). In draft-ietf-core-echo-request-tag-URL, Section 2.4 item 3 places a SHOULD on a "server that sends large responses to unauthenticated peers” to mitigate the amplification threat using the Echo Option procedure. draft-ietf-core-echo-request-tag already is flagged to update RFC7252, but this is called out in the abstract and introduction only for Token processing. The SHOULD in Section 2.4 item 3 is a bit hidden for my taste. My esteemed co-chair pointed out to me that we don’t really advertise a mitigation for the substantial amplification opportunities posed by those installations that do not translate the discussion in Section 11.3 of RFC 7252 into active behavior. There are now people out there that believe CoAP ranks with DNS and NTP in the DDoS threat generated. Would the CoRE WG be fine with expanding the “updates 7252” text in draft-ietf-core-echo-request-tag to also include recommending this mitigation? If you have a position on this, please reply to the list (or to the chairs) by March 2nd. Grüße, Carsten
Change:
server_certificate_type extension RFC7250, the resulting altered message is compressed instead. <del> If the server chooses to use the cached_info extension RFC7924 to replace the Certificate message with a hash, it MUST NOT send the compress_certificates extension. </del> 5. After decompression, the Certificate message MUST be processed as if

Discussion:
This allows for stateless parsers to easily understand the contents of the message without having to keep track of the handshake state. This also decouples client and server compression parameters, allowing compression being negotiated in only one direction.
LGTM, added just a couple of small nits.
Looks good to me.
Change:
has in breaking one of the security guarantees in the Privacy Pass protocol I-D.ietf-privacypass-protocol. <del> 10.2. </del> <ins> 6.2. </ins> Using the specification above, we can give some example parameterizations.  For example, the current Privacy Pass browser

Discussion:
This reshuffles quite a bit to frame Privacy Pass as two protocols -- issuance and redemption -- run between Clients, Mediators, Issuers, and Origins. First draft, so there may be things we want to rephrase or reflow. Rendered view of this PR .
Whitespace errors?
NAME fixed!
Merging this per the discussion during the interim meeting today.
A few comments; thanks for the quick turnaround!
Change:
Properties after Connection establishment take effect on a best- effort basis. <ins> Security Parameters: Security Parameters define an application's requirements for authentication and encryption on a Connection. They are used by Transport Security protocols (such as those described in I-D.ietf-taps-transport-security) to establish secure Connections.  Examples of parameters that can be set include local identities, private keys, supported cryptographic algorithms, and requirements for validating trust of remote identities.  Security Parameters are primarily associated with a Preconnection object, but properties related to identities can be associated directly with Endpoints. </ins> 4.1.3. Initiate: The primary action that an application can take to

Discussion:
Addresses
I wondering if we should to talk a bit more about authentication in the the arch doc. The API doc has the concept of security parameters, however there is no discussion about this in the arch document. Also, just double-checking: private keys and certificates/identify can be set as a security parameter of a pre-connection. However, is that really a connection parameter or rather a local endpoint property?
To match the API, add Security Properties to Section 4.1.2.
Try to associate with the endpoint?
Add to figure 4 too
I think?
Change:
To support a handover, a server involved in the transition could issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, <del> and retire CIDs associated with the new server using the "Retire </del> <ins> and retire CIDs associated with the old server using the "Retire </ins> Prior To" field in that frame. <del> Alternately, if the old server is going offline, the load balancer could simply map its server ID to the new server's address. </del> 7. The server ID encodings, and requirements for their handling, are

Discussion:
This only works if the cutover is immediate. "going offline" suggests something progressive, which means that this strategy only works if you suddenly start holding a bunch of state. There a lots of caveats here, to the point that I'd probably just drop this whole paragraph.
Change:
To allow a receiver to determine whether a record has a CID or not, connections which have negotiated this extension use a distinguished <del> record type tls12_cid(25).  Use of this content type has the </del> <ins> record type tls12_cid(TBD2).  Use of this content type has the </ins> following three implications: The CID field is present and contains one or more bytes.

Discussion:
URL If this PR is postponed to that date (12. April), may be the final values could be used. We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04. We believe that only editorial changes are pending. Please respond to this list of you have concerns about these assignments by April 12, 2019. Thanks, Joe, Sean and Chris
Change:
4.2.4. <del> The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its peer that it is not willing to route traffic to a given prefix.  This capsule uses a Capsule Type of 0xfff103.  Its value uses the following format: </del> <ins> The ROUTE_WITHDRAWAL capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it is not willing to route traffic to a given prefix. </ins> IP Version of this route withdrawal.  MUST be either 4 or 6.

Discussion:
The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
Change:
simulcast offer MUST create an answer according to the procedures RFC8853 section 5.3.2. <del> 4.7. </del> <ins> 5.2. </ins> In order to support future extensions to be defined for the WHIP protocol, a common procedure for registering and announcing the new

Discussion:
NAME wdyt?
he usability of the ICE server configuration seem to go far beyond WHIP. Also, in my opinion the way you configure your STUN/TURN servers is slightly outside the scope of core WHIP. But, assuming you want to keep the text: First, you should add references to where the STUN- and TURN server URIs are defined. Second, I believe Link URIs have to be enclosed by . Third, I think the "ice-server" value is misleading. An ICE server is not the same thing as a STUN/TURN server. You don't even have to use ICE in order to support STUN/TURN. Fourth, related to the third issue, perhaps you should use the "urn:ietf:params:whip:" appendix also for the STUN/TURN servers? Fifth, you say that not all webrtc implementations may allow STUN/TURN server re-configuring after the offer has been created. But, does WebRTC even define a mechanism to programmatically configure the servers? If so, please add a reference. If not, please indicate that.
Using WHIP without a valid TURN/STUN server configuration will fail in many cases, so In practice any WHIP service provider will also be providing STUN/TURN services to be used with. WHIP allows sending the STUN/TURN server configuration in the HTTP request in order to not have to manualy configure the configuration manually o the client. Moreover, some WHIP providers may want to restrict the usage of their TURN/STUN server and only provide short lived credentials that are only valid in the context of the WHIP session. The term is taken from the W3C webrtc spec that uses the configuration property when creating the PC. Regarding the and , yes, it is a typo and should be corrected. Regarding the it was originally propossed like that but i was agreed that this could be used to configure other webrtc services and not only WHIP and it could be better to not have the urn be whip-specific WebRTC w3c spec supports reconfiguration of the stun/turn server connection via URL
Won't the WHIP servers have a publicly available IP address in most cases? And, as the WHIP client is the one always establishing the media path, there should be no need for a STUN/TURN server in such cases.

Or? Ok. I suggest adding a note to indicate that. I suggest adding some text and point that out. Thanks! I suggest adding a reference,
Clients may be behind restricted firewalls which block UDP. It is easier to just deploy a TURN server to do TURN over TCP/TLS than implement ICE TCP on the media server (and ICE TLS is not standard anyway). Also, you typically have less TURN servers than media servers, so it is easier to have them allowed by IP on the firewalls. In our case for example, our IPs of the media server pool are dinamic, so we must use TURN server IPs instead. I will add notes for the other comments as suggested
Change:
a Relying Party would appraise an Attestation Result for any other purpose. <ins> Another approach to deal with Evidence is to remove PII from the Evidence while still being able to verify that the Attester is one of a large set.  This approach is often called "Direct Anonymous Attestation".  See CCC-DeepDive section 6.2 for more discussion. </ins> 12. 12.1.

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
Change:
When a stream is closed, this indicates the end of an HTTP message. Because some messages are large or unbounded, endpoints SHOULD begin processing partial HTTP messages once enough of the message has been <del> received to make progress.  If a client stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE. </del> <ins> received to make progress.  If a client-initiated stream terminates without enough of the HTTP message to provide a complete response, the server SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE. </ins> A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the

Discussion:
client stream should be clearly written as client initiated stream the word which pair of send response is receive request, so its better to be does not abort recieving request here for clearify.
First one is good. The second one is intended to align with Section 2.4 of the transport draft, where "abort reading" is a defined operation on a stream; maybe "does not abort reading the request"?
NAME > "does not abort reading the request" SGTM too
Change:
2.10. The YANG model defined in this document supports the following <del> protection architectures: </del> <ins> optical protection architectures: </ins> Individual OTSi protection OMS MCG protection = TE-link protection between adjacent WDM-TE-

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 115 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request URL Addressing and resolving .
Change:
CONNECTION_CLOSE frames sent in multiple packet types can be coalesced into a single UDP datagram; see packet-coalesce. <del> An endpoint might send a CONNECTION_CLOSE frame in an Initial packet or in response to unauthenticated information received in Initial or Handshake packets.  Such an immediate close might expose legitimate connections to a denial of service.  QUIC does not include defensive measures for on-path attacks during the handshake; see handshake-dos. However, at the cost of reducing feedback about errors for legitimate peers, some forms of denial of service can be made more difficult for an attacker if endpoints discard illegal packets rather than terminating a connection with CONNECTION_CLOSE.  For this reason, endpoints MAY discard packets rather than immediately close if errors are detected in packets that lack authentication. </del> <ins> An endpoint can send a CONNECTION_CLOSE frame in an Initial packet. This might be in response to unauthenticated information received in Initial or Handshake packets.  Such an immediate close might expose legitimate connections to a denial of service.  QUIC does not include defensive measures for on-path attacks during the handshake; see handshake-dos.  However, at the cost of reducing feedback about errors for legitimate peers, some forms of denial of service can be made more difficult for an attacker if endpoints discard illegal packets rather than terminating a connection with CONNECTION_CLOSE. For this reason, endpoints MAY discard packets rather than immediately close if errors are detected in packets that lack authentication. </ins> An endpoint that has not established state, such as a server that detects an error in an Initial packet, does not enter the closing

Discussion:
This sentence structure was unnecessarily byzantine.
is hard to read. [A D] [A D]] [A D]] ...
Change:
how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. <ins> RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud </ins> 1. Bootstrapping Remote Secure Key Infrastructures (BRSKI) I-D.ietf-

Discussion:
This should be a do-nothing change to the content, which just starts every sentence on fresh line. This aids greatly in reading diffs. One paragraph break added, and one period changed to a dot. And I seem to have included the IEEE reference fix by mistake.
Change:
from TSN (L2) to PW (MPLS) encapsulation.  However, such interworking is out-of-scope in this document and left for further study. <ins> A MPLS DetNet flow is configured to carry any number of TSN flows. The DetNet flow specific bandwidth profile SHOULD match the required bandwidth of the App-flow aggregate. </ins> 5.3. In the design of I-D.ietf-detnet-mpls an MPLS service label (the

Discussion:
Work In progress - Wanted to get the figure changes out for review. Need to check if the overly wording is complete. There was a lot of inter working text - I have commented out.
Change:
three 16-bit integers, respectively, each in network byte order. Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, and the header. </del> <ins> bhttp request", a zero byte, and the header.  Note: repurposing discusses how alternative message formats might use a different "info" value. </ins> Create a sending HPKE context by invoking "SetupBaseS()" (HPKE) with the public key of the receiver "pkR" and "info".  This yields

Discussion:
This is a lot more disruptive, but I think it is a clearer description of how you might repurpose this design. I'm still a little unsure about using application/dns-message, but I can live with it.
If this is acceptable, I might cherry-pick some of the other changes from rather than take it wholesale.
OK, I think that I understand what you are looking for and I agree, we can say more about that. But we probably don't need to say heaps more. Is the latest commit what you are looking for?
NAME I think it's closer, but I genuinely don't see why noting precisely where things need to change in the spec is harmful. I prefer Tommy's original change here.
Yeah, this still doesn't solve the problem of letting implementers know which parts of the encapsulated request processing are the bits that can become generic to handle other media types. Another way to look at this is, for another spec to define how to use another media type, it should be easy to simply say "the OHTTP spec explains the couple places where the media type can be changed from BHTTP to something else — and this use of OHTTP tells you to use a different media type in those spots". We should avoid having new specs like this need to wholesale copy the sections of the OHTTP document that define how to use HPKE, etc, and just have one subtle difference.
I'm not seeing that. I realize that I missed the padding piece (though I don't consider that particularly important, it's worth mentioning). For a generic format, the only adaptation required is replacing the constant strings. This describes how that might work. That we don't burden the reader of the algorithm piece with this detail at the time is a feature, not a bug, as far as I'm concerned.
I don't consider it a burden. I think it's an important piece for someone who's implementing OHTTP since it has API implications. For example, one could implement the main encap and decap algorithms using the fixed "message/bhttp" content type and then find they have to either duplicate code later on adjust their encap and decap APIs (or something else) to accommodate another type of application encoding.

The inline hints from the original suggestion in suggest that implementers might want to allow for changes to the content type string so they don't run into this situation down the road, and they're minimally invasive hints at that.
I've added the pointers, as requested. (I only skipped one on the decapsulation process as that seemed redundant.)
Thanks, latest changes look good to me
Change:
Because the consent issue is more difficult here, we require WebRTC implementations to periodically send keepalives.  As described in Section 5.3, these keepalives MUST be based on the consent freshness <del> mechanism specified in I-D.muthu-behave-consent-freshness.  If a keepalive fails and no new ICE channels can be established, then the session is terminated. </del> <ins> mechanism specified in RFC7675.  If a keepalive fails and no new ICE channels can be established, then the session is terminated. </ins> 5.

Discussion:
Addresses .
NAME CI fail
Yeah I can’t wait to diagnose what xml problem I introduced - sigh.
From Cullen's 20171106 review: The refs to draft-muthu-behave-consent-freshness should be to RFC7675
Addressed by .