jiebi/CodeConvo huggingface dataset:
Change:
When either COSEEncrypt and COSEMac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key. Countersignatures of COSEEncrypt and COSEMac with short authentication tags do not provide the security properties associated with the same algorithm used in COSESign. To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits. A countersignature of a COSEMac with AES-MAC 256/128 provides at most 64 bits of integrity protection. Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits bits of integrity protection.

Discussion:
padding is to be done to prevent or discourage such analysis.  (For example, the text strings could be defined as 'YES' and 'NO '.) <ins> When either COSE_Encrypt and COSE_Mac is used and more than two parties share the key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key. Countersignatures of COSE_Encrypt and COSE_Mac with short authentication tags do not provide the security properties associated with the same algorithm used in COSE_Sign.  To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits.  A countersignature of a COSE_Mac with AES-MAC 256/128 provides at most 64 bits of integrity protection.  Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits bits of integrity protection. </ins> 7. This section records the status of known implementations of the
Change:
Comments on the content In the XML file you can search for "COMMENT:". In the TXT file, the comments start with "_COMMENT:"
I'll address inline and commit too. Many thanks Aris!!!

Discussion:
A P-Route may be installed in either Storing and Non-Storing Mode, potentially resulting in hybrid situations where the Mode of the <del> P-Route is different from that of the RPL Main DODAG.  P-Routes can be used as stand-alone segments to reduce the size of the source routing headers with loose source routing operations down the main RPL DODAG.  P-Routes can also be combined with other P-Routes to form a more complex forwarding graph called a Track. </del> <ins> P-Route is different from that of the RPL Main DODAG. P-Routes can be used as stand-alone segments to reduce the size of the source routing headers with loose source routing operations down the main RPL DODAG.  P-Routes can also be combined with other P-Routes to form a more complex forwarding graph called a Track. </ins> 3.3.
Change:
Note added to 5.1, that L4 multipath is out-of-scope. Please, check note and its placement that it is appropriate. URL URL Internet-Draft draft-ietf-detnet-ip-oam-URL is now available. It is a work item of the Deterministic Networking (DETNET) WG of the IETF. Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Authors: Greg Mirsky Mach(Guoyi) Chen David Black Name: draft-ietf-detnet-ip-oam-URL Pages: 9 Dates: 2024-02-05 Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTML version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL
Hi Bernard, thank you for your thoughtful comments and helpful suggestions. The authors discussed them and updated the draft to address your concerns. I uploaded the new version: A new version of Internet-Draft draft-ietf-detnet-ip-oam-URL has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-detnet-ip-oam Revision: 11 Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Date: 2024-02-05 Group: detnet Pages: 9 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. Please let us know whether these updates adequately address your comments. Our sincere thanks for your help in improving this document. Regards, Greg (on behalf of the authors)

Discussion:
Layer-2. <del> Layer-3. </del> Label-switched path. Multiprotocol Label Switching. <del> Provider Edge. </del> Packet Elimination Function. Packet Replication Function.

Packet Ordering Function. <del> Packet Switched Network. </del> Pseudowire. DetNet "service" label. <ins> Switching Provider Edge. </ins> Terminating Provider Edge. Traffic Engineering.

Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. <ins> Note: using Layer-4 (L4) transport protocols e.g., for multipath are out of scope of this document both for a single flow and aggregate flows. </ins> 5.2. The traffic treatment required for a particular DetNet IP flow is

processing according to I-D.ietf-detnet-mpls. It is the responsibility of the DetNet controller plane to properly <del> provision both flow identification information and the flow specific resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and individual flows. </del> <ins> provision both flow identification information and the flow-specific resources needed to provide the traffic treatment to meet each flow's service requirements.  This applies for aggregated and individual flows. </ins> 7.
Change:
Changes: 1, Section “5. IP over DetNet MPLS Procedures” Add new text before section 5.1. 2, Fix a nit in penultimate paragraph of “5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation Procedures”

Discussion:
5. <ins> Main differences of mapping to DetNet MPLS (compared to plain MPLS) are that (1) there is a mandatory flow identification to make the forwarding decision (i.e., forwarding is not based on FEC), (2) the d-CW (DetNet Control Word) is mandatory for the MPLS encapsulation and (3) during forwarding over the DetNet MPLS network DetNet flow specific treatment is needed. </ins> 5.1. A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a

Section 5.1. An implementation MUST support the provisioning for handling any <del> received DetNet MPLS data plane as DetNet IP flows via configuration. Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. </del> <ins> packet flows received via DetNet MPLS data plane as DetNet IP flows via configuration.  Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. </ins> Note: using Layer-4 (L4) transport protocols e.g., for multipath are out of scope of this document both for a single flow and aggregate
Change:
In chapter 5. Management and Control Information Summary one more bullet added + clarification text to the paragraph after the list.

Discussion:
5. <del> The following summarizes the set of information that is needed to configure DetNet MPLS over UDP/IP: </del> <ins> The following summarizes the minimum set of information that is needed to configure DetNet MPLS over UDP/IP: </ins> Label information (A-labels, S-labels and F-labels) to be mapped to UDP/IP flow.  Note that for example, a single S-Label can map

UDP Destination Port. <ins> Use/non-use of UDP checksum. </ins> This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller RFC8655 or management plane. <ins> Not using the UDP checksum has to be evaluated on a case-by-case basis for a given network scenario based on the exception criteria's defined in RFC7510, particularly when IPv6 is used. </ins> It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific
Change:
Adding commas, the editor will probably catch these.
Hi Don, many thanks for the review. Cheers Bala'zs

Discussion:
IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a configured TSN Stream (i.e., App-flow from DetNet perspective).  If no Stream ID is matched and no other (VPN) service is configured for <del> the AC then packet MUST be dropped.  If there is a matching TSN Stream then the Stream ID specific TSN functions are executed (e.g., </del> <ins> the AC, then packet MUST be dropped.  If there is a matching TSN Stream, then the Stream ID specific TSN functions are executed (e.g., </ins> ingress policing, header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup may also be used for local MAC address learning.

according to the TSN Stream specific configuration to connected CE(s) (in case of local bridging) and/or to the DetNet Service Proxy (in case of forwarding to remote CE(s)).  If there are no TSN Stream <del> specific forwarding configurations the PE MUST flood the packet to </del> <ins> specific forwarding configurations, the PE MUST flood the packet to </ins> other locally attached CE(s) and to the DetNet Service Proxy.  If the <del> administrative policy on the PE does not allow flooding the PE MUST </del> <ins> administrative policy on the PE does not allow flooding, the PE MUST </ins> drop the packet. When a TSN entity of the PE receives a packet from the DetNet Service Proxy, it first checks via Stream Identification (see Clause 6. of IEEE8021CB and IEEEP8021CBdb) whether the packet belongs to a <del> configured TSN Stream.  If no Stream ID is matched then packet is dropped.  If there is a matching TSN Stream then the Stream ID </del> <ins> configured TSN Stream.  If no Stream ID is matched, then packet is dropped.  If there is a matching TSN Stream, then the Stream ID </ins> specific TSN functions are executed (e.g., header field manipulation in case of active Stream Identification, FRER, etc.).  Source MAC lookup may also be used for local MAC address learning. If the PE decides to forward the packet, the packet is forwarded according to the TSN Stream specific configuration to connected <del> CE(s).  If there are no TSN Stream specific forwarding configurations the PE floods the packet to locally attached CE(s).  If the administrative policy on the PE does not allow flooding the PE drops the packet. </del> <ins> CE(s).  If there are no TSN Stream specific forwarding configurations, the PE floods the packet to locally attached CE(s). If the administrative policy on the PE does not allow flooding, the PE drops the packet. </ins> Implementations of this document SHALL use management and control information to ensure TSN specific functions of the Edge Node
Change:
Fixing the comments received during the IESG review.
MPLS document
MPLS: All 01-27 changes updated
Done

Discussion:
This document uses the terminology established in the DetNet architecture RFC8655 and the the DetNet Data Plane Framework I- D.ietf-detnet-data-plane-framework.  The reader is assumed to be <del> familiar with these documents and any terminology defined therein. </del> <ins> familiar with these documents, any terminology defined therein and basic MPLS related terminologies in RFC3031. </ins> The following terminology is introduced in this document:

necessary ensure that in high speed networks the sequence number space does not wrap whilst packets are in flight. <del> The LSP used to forward the DetNet packet may be of any type (MPLS- LDP, MPLS-TE, MPLS-TP RFC5921, or MPLS-SR I-D.ietf-spring-segment- routing-mpls).  The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters.  Note that the possible use of Penultimate Hop Popping (PHP) means that the S-Label may be the only label received at the terminating DetNet service. </del> <ins> The LSP used to forward the DetNet packet is not restricted regarding any method used for establishing that LSP (for example, MPLS-LDP, MPLS-TE, MPLS-TP RFC5921, MPLS-SR RFC8660, etc.).  The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters.  Note that the possible use of Penultimate Hop Popping (PHP) means that the S-Label may be the only label received at the terminating DetNet service. </ins> 4.2.

A DetNet control word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in RFC4385.  The d-CW formatted as shown in fig_detnet_cw MUST be present in all DetNet packets containing app- <del> flow data. </del> <ins> flow data.  This format of the d-CW was created in order (1) to allow larger S/N space to avoid S/N rollover frequency in some applications and (2) to allow non-skip zero S/N what simplifies implementation. </ins>

the Associated Channel mechanism, and to the DetNet work on OAM for more information DetNet OAM. <ins> Additional considerations on DetNet-specific OAM are subjects for further study. </ins> 4.4. The ability to aggregate individual flows, and their associated

6. <del> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  This section considers exclusively security considerations which are specific to the DetNet MPLS data plane. </del> <ins> General security considerations are described in RFC8655. Additionally, security considerations and a threat analysis are described in I-D.ietf-detnet-security.  This section considers exclusively security considerations which are specific to the DetNet MPLS data plane. </ins> Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are
Change:
IESG review comment resolutions in this version: DONE Sabrina Tanamal, IANA, (03-12), OK Michael Tüxen, (03-15), Ready with Issues: Seq.Num.Space Shwetha Bhandari, (03-13), Ready TO BE DISCUSSED: Security section Watson Ladd, SecDir, (03-11), Not Ready Uri Blumenthal, (03-13), Security Deborah, (04-09), decrease authors to 6 !!!
reviewed in April 22 meeting

Discussion:
<del> An unsigned value implementing the DetNet sequence number. </del> <ins> An unsigned value implementing the DetNet sequence number.  The sequence number space is a circular one. </ins> A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet app-flow.  The following sequence
Change:
there was two more remaining human.
on the section 4, it seems better to change some of "EKU" to "KeyPurposeId" or "EKU values" to highlight following. excluded EKUs procedures checks, whether EKU values contain some OID(KeyPurpiseId), or absence of EKU extension. permitted EKU procedures check, whether EKU values contain some OID(KeyPurposeId).
Current expression on "Excluded EKUs procedure " and "Permitted EKU procedure" seems unclear about whether that procedure prohibits or allows, existence of certain key purpose identifier in the extended key usage value (partial match), OR certain set of key purpose identifier is on key usage value(exact match). my intension was the former. I will review, and will fix that expression if it were unclear. In addition, I will add "restrictions set is derived and implemented from (or configured with) the policy to which the implementation conforms." to clarify policy handling by RP or implementer.

Discussion:
document signing. Term of "Document Sign" in this document is digitally sign contents <del> that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by </del> <ins> that are consumed by people.  To be more precise, contents are intended to be shown to person with printable or displayable form by </ins> means of services or software, rather than processed by machines. 3.1.
Change:
Addressing Erik's . Given that documents may be presented to people "by means of ... software" perhaps a slight tweak to the "rather than processed by machines", e.g.: "rather than processed primarily by machines", or "rather than processed principally by machines" s/instead of single/instead of a single/ s/proresses/processes/ I think?

Discussion:
signing contents that are consumed by people.  To be more precise, contents are intended to be shown to a person with printable or displayable form by means of services or software, rather than <del> processed by machines. </del> <ins> primarily processed by machines. </ins> 3.1.

This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can <del> permit or prohibit combinations of KeyPurposeIds, instead of </del> <ins> permit or prohibit combinations of KeyPurposeIds, instead of a </ins> single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and
Change:
LGTM with the tweak I added
Where: Abstract What: s/peer-to-peer connection/connectivity Why: We talk about establishing connectivity elsewhere
peer-to-peer seems important to retain here, not sure I agree with this change
Then we could at least use "peer-to-peer connectivity", because that seems to be used once in the Introduction of 8445.
I can get behind that.
Something happened. I forked the ICE WG repo, but when I created the PR it ended up in my private repo.
You used the wrong repo for the base repo. I fixed it in URL
I think I understand why that happened, ice-wg still thinks cdh4u is upstream, need to think about how to fix that.
Shouldn't it be possible to create a pull request to a fork? I guess my repo isn't needed anymore, so in worse case we can just remove it.
Fixed in
Looks good.

Discussion:
Abstract <del> During the process of creating a peer-to-peer connection, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed.  However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature.  This document discusses when these situations can occur and proposes a way to avoid premature failure. </del> <ins> During the process of establishing peer-to-peer connectivity, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur and proposes a way to avoid premature failure. </ins> 1.
Change:
Ok.
Looks good.
Where: Introduction What: s/candidate addresses/ICE candidates Why: An address is just one part of a candidate
I tend to think this is implicit, and won't confuse anyone.
We use "candidates" everywhere else, and it is not only the addresses that are exchanged.
8445 also uses 'candidate transport addresses' in Section 2. But open to some other text here, 'ICE candidates' feels like it doesn't explain enough to the reader.
The paragraph says: "Typically, when using ICE, endpoints will exchange candidate addresses, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established. If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed." If people don't understand what an "ICE candidate" is they won't understand the rest of the text either :) My point is that endpoints are exchanging candidates. The candidate transport addresses are then used for sending connectivity checks. So, if you want to include it, perhaps something like: "and then test each candidate pair, by sending connectivity checks using the candidate transport addresses, to see if...."
Implemented in
Reworded, PTAL.

Discussion:
(ICE), for Network Address Translator (NAT) traversal for UDP-based communication. <del> Typically, when using ICE, endpoints will exchange candidate addresses, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed. </del> <ins> When using ICE, endpoints will typically exchange ICE candidates, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established.  If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process is considered to have failed. </ins> During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote
Change:
I committed both changes.
WHERE: Update to RFC 8445 WHAT: Modify... "; note that receipt of an ICE candidate is not required." URL that it also indicates that no candidate needs to be SENT before the timer is started. WHY: The text in unclear on whether a candidate needs to be sent or not before the timer is started. The text only says that a candidate does not need to be received.
ok
Implemented in
LG with two minor wording changes

Discussion:
Username Fragment and Password denoted in RFC8445, Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned <del> above; note that receipt of an ICE candidate is not required. </del> <ins> above.  Note that the agent will start the timer even if it has not sent or received any ICE candidates. </ins> The RECOMMENDED duration for the timer is equal to the agent's connectivity check transaction timeout, including all