jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-detnet-mpls-over-udp-ip

Commentary: In chapter 5 . Management and Control Information Summary one more bullet + clarification text to the paragraph after the list .
Paragraph (version A):
This information MUST be provisioned per DetNet flow via
configuration, e.g., via the controller RFC8655 or management plane.
Paragraph (version B):
Use/non-use of UDP checksum.
Paragraph (version B):
This information MUST be provisioned per DetNet flow via
configuration, e.g., via the controller RFC8655 or management plane.
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.
Draft: draft-ietf-detnet-mpls-over-udp-ip

Commentary: Changes OK
Paragraph (version B):
As specified in RFC7510: "MPLS-in-UDP MUST NOT be used over the
general Internet, or over non-cooperating network operators, to carry
traffic that is not congestion controlled."  This does apply to
DetNet networks as this document focuses on solutions for networks
that are under a single administrative control or within a closed
group of administrative control.
Paragraph (version B):
Note: In the presence of network (and port) address translation
devices/functions it would be up to the controller plane to determine
the appropriate information to ensure proper mapping at the sender/
receiver.
Draft: draft-ietf-detnet-ip-over-mpls

Commentary: 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 ”
Paragraph (version B):
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.
Paragraph (version A):
An implementation MUST support the provisioning for handling any
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.
Paragraph (version B):
An implementation MUST support the provisioning for handling any
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.
Draft: draft-ietf-detnet-ip-over-mpls

Commentary: All comments were replied and fixed as per 8:00pm CET , 09 - 09 - 2020
Paragraph (version A):
Security aspects which are unique to DetNet are those whose aim is to
provide the specific quality of service aspects of DetNet, which are
primarily to deliver data flows with extremely low packet loss rates
and bounded end-to-end delivery latency.
Paragraph (version B):
Security aspects which are unique to DetNet are those whose aim is to
protect the support of specific quality of service aspects of DetNet,
which are primarily to deliver data flows with extremely low packet
loss rates and bounded end-to-end delivery latency.
Draft: draft-ietf-detnet-ip-over-mpls

Commentary: Note to 5.1 , that  multipath is out - of - scope . Please , check note and its placement that it is appropriate .
Mailing list commentary: Hi , Thanks for the good memory . : -- ) ) ) Sure , You are right . I will add a note regarding multipath . Thanks & Cheers Bala'zs
Hi , Thanks for your comments . Yes , transport layer is out - of - scope for DetNet scenarios . The framework document ( ) says explicitly : " Use of packet - by - packet distribution of the same DetNet flow over multiple paths is not recommended ... Packet by packet load sharing , e.g. , via ECMP or UCMP , impacts ordering and possibly jitter . " I will add an explicit note on this here as well . So , your comment is absolutely right , multipath would impact aggregation as well . Many thanks Bala'zs
Paragraph (version A):
Layer-3.
Paragraph (version A):
Provider Edge.
Paragraph (version A):
Packet Switched Network.
Paragraph (version B):
Switching Provider Edge.
Paragraph (version B):
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.
Paragraph (version A):
It is the responsibility of the DetNet controller plane to properly
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.
Paragraph (version B):
It is the responsibility of the DetNet controller plane to properly
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.
Draft: draft-ietf-detnet-ip-over-mpls

Commentary: Comments before 04 - 27 resolved .
Paragraph (version B):
DetNet Control Word.
Paragraph (version B):
DetNet "service" label.
Paragraph (version B):
Terminating Provider Edge.
Paragraph (version A):
In fig_dn_ip_mpls_sn_ex "App-Flow" indicates the payload carried by
the DetNet IP data plane.  "IP" and "NProto" indicate the fields
described in Section 5.1.1.  IP Header Information and Section 5.1.2.
Other Protocol Header Information in I-D.ietf-detnet-ip,
respectively.  "App-Flow for MPLS" indicates that an individual
DetNet IP flow is the payload from the perspective of the DetNet MPLS
data plane defined in I-D.ietf-detnet-mpls.
Paragraph (version A):
Per I-D.ietf-detnet-mpls, the DetNet MPLS data plane uses a single
S-Label to support a single app flow.  Section 5.1.  DetNet IP Flow
Identification Procedures in I-D.ietf-detnet-ip states that a single
DetNet flow is identified based on IP, and next level protocol,
header information.  Section 4.4.  Aggregation Considerations in I-
D.ietf-detnet-ip defines the ways in which aggregation is supported
through the use of prefixes, wildcards, lists, and port ranges.
Collectively, this results in the fairly straightforward procedures
defined in this section.
Paragraph (version B):
In fig_dn_ip_mpls_sn_ex "App-Flow" indicates the payload carried by
the DetNet IP data plane.  "IP" and "NProto" indicate the fields
described in Section 5.1.1.  (IP Header Information) and
Section 5.1.2.  (Other Protocol Header Information) of I-D.ietf-
detnet-ip, respectively.  "App-Flow for MPLS" indicates that an
individual DetNet IP flow is the payload from the perspective of the
DetNet MPLS data plane defined in I-D.ietf-detnet-mpls.
Paragraph (version B):
Per Section 5.1 of I-D.ietf-detnet-mpls, the DetNet MPLS data plane
uses a single S-Label to support a single app flow.  DetNet IP Flow
Identification Procedures in Section 4.4 of I-D.ietf-detnet-ip states
that a single DetNet flow is identified based on IP, and next level
protocol, header information.  Section 4.4.  (Aggregation
Considerations) of I-D.ietf-detnet-ip defines the ways in which
aggregation is supported through the use of prefixes, wildcards,
lists, and port ranges.  Collectively, this results in the fairly
straightforward procedures defined in this section.
Paragraph (version A):
This draft does not have additional security considerations.
Security considerations for DetNet are described in detail in I-
D.ietf-detnet-security.  General security considerations are
described in RFC8655.  MPLS and IP specific considerations are
described in I-D.ietf-detnet-mpls and I-D.ietf-detnet-ip.
Paragraph (version B):
Generals security considerations for DetNet are described in detail
in I-D.ietf-detnet-security.  DetNet MPLS and DetNet IP security
considerations equally apply to this document and are described in I-
D.ietf-detnet-mpls and I-D.ietf-detnet-ip.
Paragraph (version B):
RFC7322 limits the number of authors listed on the front page of a
draft to a maximum of 5.  The editor wishes to thank and acknowledge
the follow authors for contributing text to this draft.
Draft: draft-ietf-detnet-mpls

Commentary: Fixing authors and security in mpls
Paragraph (version A):
existing mechanism, such as through policing and shaping.  To prevent
DetNet packets from being delayed by an entity external to a DetNet
domain, DetNet technology definition can allow for the mitigation of
Man-In-The-Middle attacks, for example through use of authentication
and authorization of devices within the DetNet domain.
Paragraph (version B):
existing mechanisms, for example by policing and shaping incoming
traffic.  To prevent DetNet packets from being delayed by an entity
external to a DetNet domain, DetNet technology definition can allow
for the mitigation of Man-In-The-Middle attacks, for example through
use of authentication and authorization of devices within the DetNet
domain.
Paragraph (version B):
This document makes no IANA requests.
Draft: draft-ietf-detnet-mpls

Commentary: from april 20 call
Paragraph (version A):
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.
Paragraph (version B):
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
security considerations which are specific to the DetNet MPLS data
plane.  The considerations raised related to MPLS networks in general
in RFC5920 are equally applicable to the the DetNet MPLS data plane.
Paragraph (version A):
To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks.  To
protect against DOS attacks, excess traffic due to malicious or
malfunctioning devices can be prevented or mitigated, for example
through the use of existing mechanism such as policing and shaping
applied at the input of a DetNet domain.  To prevent DetNet packets
from being delayed by an entity external to a DetNet domain, DetNet
technology definition can allow for the mitigation of Man-In-The-
Middle attacks, for example through use of authentication and
authorization of devices within the DetNet domain.
Paragraph (version B):
To provide uninterrupted availability of the DetNet service,
provisions can be made against DOS attacks and delay attacks.  To
protect against DOS attacks, excess traffic due to malicious or
malfunctioning devices is prevented or mitigated through the use of
existing mechanism, such as through policing and shaping.  To prevent
DetNet packets from being delayed by an entity external to a DetNet
domain, DetNet technology definition can allow for the mitigation of
Man-In-The-Middle attacks, for example through use of authentication
and authorization of devices within the DetNet domain.
Draft: draft-ietf-detnet-mpls

Commentary: IESG review comment resolutions in this version : DONE   , IANA , ( 03 - 12 ) , OK   , ( 03 - 15 ) , Ready with Issues : Seq . Num .    , ( 03 - 13 ) , Ready TO BE DISCUSSED : Security section   , SecDir , ( 03 - 11 ) , Not    , ( 03 - 13 ) ,   , ( 04 - 09 ) , decrease authors to 6 ! ! ! 
 reviewed in April 22 meeting
Paragraph (version A):
An unsigned value implementing the DetNet sequence number.
Paragraph (version B):
An unsigned value implementing the DetNet sequence number.  The
sequence number space is a circular one.
Draft: draft-ietf-detnet-ip

Commentary: from   and Tero
Paragraph (version A):
The DetNet Architecture models the DetNet related data plane
functions as two sub-layers: functions into two sub-layers: a service
sub-layer and a forwarding sub-layer.  The service sub-layer is used
to provide DetNet service protection (e.g., by packet replication and
packet elimination functions) and reordering.  The forwarding sub-
layer is used to provide congestion protection (low loss, assured
latency, and limited out-of-order delivery).  The service sub-layer
generally requires additional fields to provide its service; for
example see I-D.ietf-detnet-mpls.  Since no DetNet-specific fields
are added to support DetNet IP flows, only the forwarding sub-layer
functions are supported using the DetNet IP defined by this document.
Service protection can be provided on a per sub-net basis using
technologies such as MPLS I-D.ietf-detnet-dp-sol-mpls and Ethernet as
specified in the IEEE 802.1 TSN task group(referred to in this
document simply as IEEE802.1 TSN).
Paragraph (version B):
The DetNet Architecture models the DetNet related data plane
functions as two sub-layers: a service sub-layer and a forwarding
sub-layer.  The service sub-layer is used to provide DetNet service
protection (e.g., by packet replication and packet elimination
functions) and reordering.  The forwarding sub-layer is used to
provide congestion protection (low loss, assured latency, and limited
out-of-order delivery).  The service sub-layer generally requires
additional fields to provide its service; for example see I-D.ietf-
detnet-mpls.  Since no DetNet-specific fields are added to support
DetNet IP flows, only the forwarding sub-layer functions are
supported using the DetNet IP defined by this document.  Service
protection can be provided on a per sub-net basis using technologies
such as MPLS I-D.ietf-detnet-dp-sol-mpls and Ethernet as specified in
the IEEE 802.1 TSN task group(referred to in this document simply as
IEEE802.1 TSN).
Paragraph (version A):
Class of Service (CoS) for DetNet flows carried in IPv6 is provided
using the standard differentiated services code point (DSCP) field
RFC2474 and related mechanisms.
Paragraph (version B):
Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is
provided using the standard differentiated services code point (DSCP)
field RFC2474 and related mechanisms.
Paragraph (version B):
The rules defined in this section only apply when the IPv4 Protocol
or IPv6 Next Header Field contains the IANA defined value for UDP or
TCP.
Paragraph (version B):
The rules defined in this section only apply when the IPv4 Protocol
or IPv6 Next Header Field contains the IANA defined value for AH or
ESP.
Paragraph (version A):
If the DSCP field is to be used in flow identification.
Ignoring the DSCP filed is optional.
Paragraph (version B):
If the DSCP field is to be used in flow identification.
Ignoring the DSCP field is optional.
Paragraph (version A):
IPsec Header SPI field.  Exact matching is required.
Paragraph (version B):
IPsec Header SPI field.  Exact matching is required.  Support for
wildcard matching is recommended.
Draft: draft-ietf-detnet-ip-over-tsn

Commentary: Remove of editorial comments and update of abbreviations and references .
Paragraph (version B):
Frame Replication and Elimination for Redundancy (TSN function).
Draft: draft-ietf-detnet-data-plane-framework

Commentary: Updates from call Feb 3rd .
Paragraph (version A):
In the preceding example, reordering of packets is dependent on the
number of out-of-order packets that can be buffered and the delay
difference of arriving packets.  DetNet uses configuration of the
number of maximum number out-of-order packets and the maximum delay
that out-of-order packets can be held before being delivered.  If the
differential delay between paths is large enough or the arrival rate
of packets large enough packets may be dropped instead of being
reordered.  Likewise elimination uses the sequence number to
eliminate duplicate packets and large differential delays combined
with high numbers of packets may exceed the ability of this
elimination function to eliminate all duplicate packets.  Path
selection for DetNet services needs to take these factors into
account.
Paragraph (version B):
In the preceding example, proper working of duplicate elimination and
reordering of packets are dependent on the number of out-of-order
packets that can be buffered and the delay difference of arriving
packets.  DetNet uses flow specific requirements (e.g., maximum
number of out-of-order packets, maximum latency of the flow, etc.)
for configuration of POF related buffers.  If the differential delay
between paths is excessively large or there is excessive mis-ordering
of the packets, then packets may be dropped instead of being
reordered.  Likewise, PEF uses the sequence number to identify
duplicate packets, and large differential delays combined with high
numbers of packets may exceed the ability of the PEF to work
properly.
Draft: draft-ietf-detnet-mpls

Commentary: Fixing the comments received during the IESG review . 
 MPLS document 
 MPLS : All 01 - 27 changes updated 
 Done
Paragraph (version A):
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
familiar with these documents and any terminology defined therein.
Paragraph (version B):
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
familiar with these documents, any terminology defined therein and
basic MPLS related terminologies in RFC3031.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
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-
flow data.
Paragraph (version B):
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-
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.
Paragraph (version B):
Additional considerations on DetNet-specific OAM are subjects for
further study.
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-ietf-detnet-ip-over-mpls

Commentary: Updates from comments on the mailing list .
Paragraph (version A):
Packet Replication, Ordering and Elimination Function.
Paragraph (version B):
Packet Elimination Function.
Paragraph (version B):
Packet Replication Function.
Paragraph (version B):
Packet Replication, Elimination and Ordering Functions.
Paragraph (version B):
Packet Ordering Function.
Paragraph (version A):
A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a
DetNet MPLS network MUST map a DetNet IP flow, as identified in I-
D.ietf-detnet-ip into a single MPLS DetNet flow and MUST process it
in accordance to the procedures defined in I-D.ietf-detnet-mpls
Section 6.1.  PRF MAY be supported at the MPLS level for DetNet IP
flows sent over an DetNet MPLS network.  Aggregation MAY be supported
as defined in I-D.ietf-detnet-mpls Section 5.4.  Aggregation
considerations in I-D.ietf-detnet-ip MAY be used to identify an
individual DetNet IP flow.  The provisioning of the mapping of DetNet
IP flows to DetNet MPLS flows MUST be supported via configuration,
e.g., via the controller plane.
Paragraph (version B):
A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a
DetNet MPLS network MUST map a DetNet IP flow, as identified in I-
D.ietf-detnet-ip into a single MPLS DetNet flow and MUST process it
in accordance to the procedures defined in I-D.ietf-detnet-mpls.  PRF
MAY be supported at the MPLS level for DetNet IP flows sent over an
DetNet MPLS network.  Aggregation MAY be supported as defined in I-
D.ietf-detnet-mpls Section 4.4.  Aggregation considerations in I-
D.ietf-detnet-ip MAY be used to identify an individual DetNet IP
flow.  The provisioning of the mapping of DetNet IP flows to DetNet
MPLS flows MUST be supported via configuration, e.g., via the
controller plane.
Paragraph (version A):
A DetNet relay node (egress T-PE) MAY be provisioned to handle
packets received via the DetNet MPLS data plane as DetNet IP flows.
A single incoming DetNet MPLS flow MAY be treated as a single DetNet
IP flow, without examination of IP headers.  Alternatively, packets
received via the DetNet MPLS data plane MAY follow the normal DetNet
IP flow identification procedures defined in I-D.ietf-detnet-ip
Section 7.1.
Paragraph (version B):
A DetNet relay node (egress T-PE) MAY be provisioned to handle
packets received via the DetNet MPLS data plane as DetNet IP flows.
A single incoming DetNet MPLS flow MAY be treated as a single DetNet
IP flow, without examination of IP headers.  Alternatively, packets
received via the DetNet MPLS data plane MAY follow the normal DetNet
IP flow identification procedures defined in I-D.ietf-detnet-ip
Section 5.1.
Draft: draft-ietf-detnet-mpls

Commentary: Based on  's comment ( 10.24 ) . 
 Distinction without a difference
Paragraph (version A):
The forwarding sub-layer information associated with the output of
the service sub-layer.  Note that when the PRF function is
provisioned, this information is per DetNet member flow.
Logically this is a pointer to details provided below for
transmission of Detnet flows at the forwarding sub-layer.
Paragraph (version B):
The forwarding sub-layer information associated with the output of
the service sub-layer.  Note that when the PRF function is
provisioned, this information is per DetNet member flow.
Logically the forwarding sub-layer information is a pointer to
further details of transmission of Detnet flows at the forwarding
sub-layer.
Paragraph (version A):
The forwarding sub-layer information associated with the input of
the service sub-layer.  Note that when the PEF function is
provisioned, this information is per DetNet member flow.
Logically this is a pointer to details provided below related to
the reception of Detnet flows at the forwarding sub-layer or
A-Label.
Paragraph (version B):
The forwarding sub-layer information associated with the input of
the service sub-layer.  Note that when the PEF function is
provisioned, this information is per DetNet member flow.
Logically the forwarding sub-layer information is a pointer to
further details of the reception of Detnet flows at the forwarding
sub-layer or A-Label.
Draft: draft-ietf-detnet-mpls

Commentary: OK . Thanks .
Paragraph (version A):
Important background information common to all data planes for DetNet
can be found in the DetNet Data Plane Framework I-D.ietf-detnet-data-
plane-framework.
Paragraph (version B):
Background information common to all data planes for DetNet can be
found in the DetNet Data Plane Framework I-D.ietf-detnet-data-plane-
framework.