jiebi/CodeConvo huggingface dataset:
Change:
value of specific Claims if it knew that only certain values were accepted by the Relying Party. <del> Evidence and Attestation Results are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If there isn't confidentiality protection of Evidence and Attestation Results, the underlying conveyance protocol should provide these protections. </del> <ins> Conceptual messages carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections. </ins> As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted

Discussion:
Signed-off-by: Dave Thaler
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.
Change:
attempts in parallel, "unconnected" protocols such as raw UDP do not offer a way to validate the presence of a peer or the usability of a Connection without application feedback.  An implementation should <del> consider such a protocol stack to be established as soon as a local route to the peer endpoint is confirmed. </del> <ins> consider such a protocol stack to be established as soon as the Transport Services system has selected a path on which to send data. </ins> However, if a peer is not reachable over the network using the unconnected protocol, or data cannot be exchanged for any other

Discussion:
My first try to make a PR from the web interface. Maybe this compiles without problems?
Aha, the error appears even when doing it over the web interface.
I think I am missing something ... how do endpoints know a route exists (is present)? My thinking from NEAT was that endpoints only knew this was established when there was some "confirmation" from the remote endpoint. Do you mean something else?
NAME this is for UDP, nothing is sent to the other end until the application sends data. it was the same in neat, our open call in neat just returned immediately for UDP.
True - for UDP, as you say, you basically know the Interface is up (and often not much more), but the words "established" sounds more like what happened when you get the first packet back... Maybe I could live with this, but it doesn't immediately inspire the right sense...
Yes, "connectivity is established" is not good at all, this is why I said the proposed update made it worse :) Or you mean that "local port reservations has been established" also triggers the wrong idea because of "established"? How about "... any necessary state like local port reservations is available/has been allocated." Or just remove that part all together.
In Sec 4.5 of taps-impl: "An implementation should consider such a protocol stack to be established as soon as a local route to the peer endpoint is confirmed." What does this mean for an unconnected protocol? That there is an entry in the route table, or that it's received a packet?
Good catch: This appears to be rough sentence. The term "confirmed" occurs only once, and a "local route" is something quite different to what is intended! We do talk about establishing connectivity with a remote endpoint... maybe that might work?
Change:
Abstract This document specifies the Deterministic Networking MPLS data plane <del> when operating over a TSN network. </del> <ins> when operating over a TSN sub-network. </ins> 1. <del> [Editor's note: Introduction to be made specific to DetNet MPLS over TSN scenario.  May be similar to intro of DetNet IP over TSN.]. </del> Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows.  DetNet provides these flows with a low packet loss rates and assured maximum end-to-end delivery latency.

Discussion:
Similar structure and changes as in IP over TSN. Service protection interworking is out-of-scope.
Change:
Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. <del> 5.1.2. Registry name: Captive Portal API Link Relation Type URN: urn:ietf:params:capport-api Specification: RFC TBD (this document) Repository: RFC TBD (this document) Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. 6. </del> <ins> 5. </ins> <del> An attacker with the ability to inject DHCP messages, RAs, or HTTP headers into cleartext HTTP communications could include an option or link relation from this document and so force users to contact an </del> <ins> An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an </ins> address of his choosing.  As an attacker with this capability could simply list himself as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more

Discussion:
At IETF 106, we discussed removing the link relation. This PR does that.
I suppose we should be reading and implementing draft-ietf-git-github-wg-configuration ... As Warren's T-shirt says: "In my defense I was left unsupervised."
100% agreed about the build output...
People who put build output in their repository deserve a special place.
Change:
This extension replaces "max_fragment_length" RFC6066, which this document deprecates.  This extension is valid in all versions of TLS. <ins> A smaller protected record size is just one of many problems that a constrained implementation might need to address.  The "record_size_limit" extension only addresses the memory allocation problem, it does not address limits of code size, or processing and bandwidth capacity. </ins> 2. The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this

Discussion:
Add an applicability statement. This only addresses buffer space issues, not processing or bandwidth constraints. I didn't observe (in the introduction) that this can negatively affect bandwidth, that's later. Hannes also observed that we don't really talk about the path MTU. I made it clear that these are separate and independent limitations. For NAME
Thanks for providing this text. While I had been hoping for more clarifications about the interactions between the MTU information entering the stack from below and the RSL parameter passed to the stack from the application side I think it is a good start.
Oh, also, I have moved the intro text down a paragraph. I think that it is better to talk about the properties of this extension rather than focus more on what MFL does or doesn't do.
Change:
6. <del> [Editor's note: This section covers management/control plane related implications of creation, mapping, removal of DetNet flow IDs, their related parameters and, when needed, the configuration of PREOF.] </del> TSN Stream(s) to DetNet flow mapping related information are required only for the service proxy function of MPLS (DetNet) Edge nodes. From the Data Plane perspective there is no practical difference

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:
The time considerations in this example are equivalent to those discussed under Example 1 above. <del> 15.4. </del> <ins> 15.5. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any

Discussion:
This is an evolution of PR and based on Issue Attester Awareness time(AA) is not included in this PR (see ), but a concise definition of Handle received (HR). The included diagram might need more work. Also a "background-check version" might be perceived as missing. Do we need one? (oh and the compilations errors due to malformed references are also fixed in this PR. pls always make sure your commit compiles before push)
PR and PR merged text that I had, and continue to have, problems with. A summary of the problems follows: 1) It includes events (CC, RP) that are not used in any checks in the text. I had pointed this out before when the PR was generated, but the PR was merged without addressing this comment. 2) The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism (handles) that is not in any RFC or WG document. I believe that such replacement is inappropriate. If the WG adopts a document that talks about a handle distribution mechanism, then a section can be added. Or if there is a standard from another org that can be referenced then it's fine to add one in that case too. But I think it should not replace the section discussing the well known technique of synchronized clocks (e.g., using secure NTP, or PTP (IEEE 1588-2002) or whatever other standard mechanism). 3) time(HD) is problematic as phrased since all the other events are times as seen by a single entity, whereas time(HD) does not clearly say whose perspective (i.e., whose clock) it is from... is it the distributor's? Text is unclear. 4) It talks about nonces in a timestamp section, which I think causes confusion since there's already a separately section about nonces and this section is labeled to be scoped to timestamps. Addressing might address this naturally, if it uses a different section title. 5) There are some editorial typos, such as capital "The" in the middle of a sentence, etc. 6) I have no idea what "delta(time(HD),time(EG))distribution-interval" is supposed to mean. Normally I would expect an equality for any condition to be evaluated, but I have no idea what this check is.

7) time(HD) and time(EG) are according to different clocks (if my guess about point 3 above is right) and so the delta is not directly comparable. I'm not sure how point 6 accounts for this. 8) The phrase "A nonce not predictable to an Attester (recentness & uniqueness) is sent to an Attester" has "(recentness & uniqueness)" which doesn't read well (sounds like bad grammar) to me, and is not explained.
Hopefully PR now addresses this issue.
PR reverts the text, leaving the work in progress in PR
fixed by .
Much better than previous PR but needs some cleanup
Change:
Note that a client may be required to re-POST the access token in order to complete a request, since an RS may delete a stored access <del> token at any time, for example due to all storage space being consumed.  This situation is detected by the client when it receives an AS Request Creation Hints response. </del> <ins> token (and associated Security Context) at any time, for example due to all storage space being consumed.  This situation is detected by the client when it receives an AS Request Creation Hints response. Reposting the same access token will result in deriving a new OSCORE Security Context to be used with the RS, as different nonces will be used. </ins> ex3 shows an example of the request sent from the client to the RS, with payload in CBOR diagnostic notation without the tag and value abbreviations.  The access token has been truncated for readability. <ins> If the client has already posted a valid token, has already established a security association with the RS, and wants to update its access rights, the client can do so by posting the new token (retrieved from the AS and containing the update of access rights) to the /authz-info endpoint.  The client MUST protect the request using the OSCORE Security Context established during the first token exchange.  The client MUST only send the access token in the payload, no nonce is sent.  After proper verification (see rs-c), the RS will replace the old token with the new one, maintaining the same Security Context. </ins> 4.1.1. This parameter MUST be sent from the client to the RS, together with

Discussion:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)
Change:
for the API that end-user devices query for information about what is required to escape captivity.  DHCP, DHCPv6, and Router- Advertisement options for this purpose are available in RFC7710. <del> Other protocols (such as RADIUS), Provisioning Domains I-D.ietf- intarea-provisioning-domains, or static configuration may also be used.  A device MAY query this API at any time to determine whether the network is holding the device in a captive state. </del> <ins> Other protocols (such as RADIUS), Provisioning Domains I- D.pfister-capport-pvd, or static configuration may also be used. A device MAY query this API at any time to determine whether the network is holding the device in a captive state. </ins> End-user devices can be notified of captivity with Captive Portal Signals in response to traffic.  This notification should work

Discussion:
We were incorrectly describing the behaviour of the capport PvD option. Update the text to better reflect how it will work, and reference the new draft describing that behaviour. This removes most of the section describing the behaviour, since it's now in the new draft. Fixes Issue .
Let's talk about adoption of the capport-pvd draft before we make this sort of change.
NAME , was the capport-pvd draft discussed during IETF 104? I don't see anything in the minutes.
NAME we did not specifically discuss the capport-pvd draft. I think that doesn't need to be in this first core flight of docs. Note we'll be discussing the core PvD doc more in intarea and hopefully will get that out to last call.
NAME Alright. The existing content is still wrong, though. So, to fix this, perhaps we should just remove the references to PvDs in general?
This text incorrectly describes the PvD JSON as the API JSON. This is incorrect. We should also refer to the CAPPORT PvD proposal document which explains this.
anything left for this please?
NAME
Seems fine to me to close
Does PvD mechanism deliver the capport state, or a pointer to the capport API, from which capport state is retrieved?
In IETF101 capport meeting, I think I heard that PvD is not designed for conveying per-UE state. Hence, PvD may provide a URI to the capport API, but not convey the state itself.
NAME is this addressed in in the sense that the referenced doc covers it?
Yes. I think it is.
Change:
not easily confused by a developer, such as by limiting the strings to easily disambiguated characters. <ins> In order to facilitate the use of both object and reference strings to access the same kind of APIs, the API designer can define a clear mapping between these forms.  One possible approach for choosing reference string values is to use the same value as the "type" parameter from the fully-specified object, with the API defining a set of default behaviors in this case.  For example, an API definition could declare the following string: As being equivalent to the following fully-defined object: The exact mechanisms for relating reference strings is up to the API designer.  These are enforced by the AS, and the details are out of scope for this specification. </ins> This functionality is similar in practice to OAuth 2.0's "scope" parameter RFC6749, where a single string represents the set of access rights requested by the client instance.  As such, the reference

Discussion:
Removes the normative suggestion that access right string values be always expandable to objects, but instead adds an example of one way to do it.
To edit notification comments on pull requests, go to your .
We say: But then we give examples like "some other thing" that clearly do not correspond to anything. We also don't specify any kind of semantics, such as if I request the reference string, I might get back the expanded access right representation. I suggest to remove or weaken that sentence:
I don't see a reason for it not being a SHOULD -- it provides guidance to API developers that the strings a short-hand for the expanded objects. And since it's only a SHOULD, the AS is still free to treat it differently.
No, this would be a MAY. With a SHOULD, you're supposed to have a good, documented reason to do something else. Quoting the original, may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. If we keep the SHOULD, our examples in the text should reflect that.
Probably we could improve the examples. But as an implementer, I wouldn't understand what you mean by MAY. Because then it suggests there can be reasonable alternatives to something known to the AS, which I don't think we have.
NAME I've proposed a change to the text in question in . Also, please note that the example string of is intended to be an actual value, with spaces and all. If it's not clear that this is a real and valid value in this context, please suggest an alternative that might fit here. We don't want people to assume that it has the same restrictions as OAuth scopes (which can't have spaces).
Change:
IANA [SHALL add/has added] the following notes: <del> The designated expert RFC8126 only ensures that the specification is publicly available.  An Internet Draft that is posted and never </del> <ins> The role of the designature expert is described in [this-RFC]. The designated expert RFC8126 ensures that the specification is publicly available.  An Internet Draft that is posted and never </ins> published or a standard in another standards body, industry <del> consortium, university site, etc. suffices. </del> <ins> consortium, university site, etc. suffices.  The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the identifier. </ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the

Discussion:
This change aligns the DE text and adds more info about what the DE does and doesn't do. It also capitalizes "Recommended" so that it's more clear that we're referring to the column. NAME PTAL
LGTM, thanks for unifying the DE language.
Change:
This alert notifies the recipient that the sender will not send any more messages on this connection.  Any data received after a <del> closure MUST be ignored. </del> <ins> closure alert has been received MUST be ignored. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a

Discussion:
Currently TLS 1.3 specifies closenotify in the same way that TLS 1.2 did. I believe that has issues and this might be the right time to fix them. The purpose of closenotify is to protect against data truncation attacks, each side is required to send closenotify before closing the write side of the transport connection so the other side knows that the data was not truncated. As such, closenotify only needs half-close semantics to prevent truncation. However, the specification contains the following text: > This means that an application-layer client can't send a query then close their write transport when they know that they're done, because the server would terminate the TLS session before sending the reply. On top of this, when the server receives the closenotify, it may have already sent part of the reply (or wrote it to the socket send buffer) so the responding closenotify would in effect be inflicting a truncation attack on the client. This doesn't make much difference for HTTP because clients already don't close their write transport after sending a reply, however having the option do do this could allow innovation in new protocols that can define the semantics of when they use closenotify. An example is DNS PUSH: URL A proposal to solve this problem would be to give closenotify half-close semantics: we keep the requirements that a closenotify be sent before closing the transport, and that any data received after a closenotify is ignored, but we simply remove the requirement to immediately reply with a close_notify. This has the advantage that current implementations are already compliant but future ones can leverage this improvement.
Change:
2. <del> Replace </del> <ins> The following is a simple example of glue records present in the delegating zone "test" for the child zone "foo.test".  The nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both below the delegation point.  They are configured as glue records in the "test" zone: </ins> <del> "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  Go to step 4." </del> <ins> Referral responses from "test" for "foo.test" must include the glue records in the additional section (and set TC=1 if they do not fit): </ins> <del> with "Copy the NS RRs for the subzone into the authority section of the reply.  Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache.  If all glue RRs do not fit, set TC=1 in the header.  Go to step 4." 3. </del> <ins> 2.1. </ins> While not common, real life examples of servers that fail to set TC=1 <del> when glue records are available exist and they do cause resolution </del> <ins> when glue records are available, exist and they do cause resolution </ins> failures. <del> 3.1. </del> The example below from June 2020 shows a case where none of the glue records, present in the zone, fitted into the available space and TC=1 was not set in the response.  While this example shows an DNSSEC

Discussion:
Misc updates .. Rework Sibling Glue section, and clarify that they MUST be included, and also subject to TC=1 if they don't fit. Remove the cross parent zone cyclic dependency example, which doesn't work (I think we agreed to that, but I can be persuaded to add it back, if we want to point out a misconfiguration as a warning). Move the paragraph about non-optionality of types of additional section data into the tail end of the Intro. It deserves to be more prominently mentioned than buried at the end of the example of missing glue. Addressed Duane's comment that the "Why is Glue Required?" section did not actually say why, but instead just gave examples. Instead, I added a one phrase explaining why to the Intro section that defines glue records. I don't think it requires a separate section. Removed Duane's comment about "I think the document should say that some servers might experience an increase in TCP if implementations require all glue or set TC=1. If not in this section then somewhere else._". I agree we should address this, so I've made an "issue" for it. And we can add the relevant text in the next update, once we figure out where it goes (an "Operational Considerations" section perhaps?).
NAME - added your tweaks. Please review/approve!