jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-opsawg-l2nm

Commentary: Adding a description to signaling options to improve readability . I have pending to update L2TP after the other issue is solved 
 Thanks ,  . Does the text reflect the latest version of signaling / discovery split ? 
 leaf l2tp - type { type identityref { base t - ldp - pwe - type ; } description " T - LDP PWE type . " ; } 
 The type should be taken from this registry : 
 A new IANA - maintained module is created to fix this issue .
Paragraph (version A):
Refers to the BGP control plane as described in RFC4761 and
RFC6624.
Paragraph (version A):
Refers to the BGP control plane as described in RFC7432 and
RFC7209.
Paragraph (version A):
Refers to LDP-signaled pseudowires RFC6074.
Paragraph (version A):
Refers to L2TP-signaled pseudowires RFC6074.
Paragraph (version B):
The service is a Multipoint VPLSs that use a BGP control plane as
described in RFC4761 and RFC6624.  For this L2VPN service, the
model allows configuring the Route Distinguisher, the Route
Targets, the PWE encapsulation type and the MTU configurations to
allow MTU mismatch.
Paragraph (version B):
The service is a Multipoint VPLSs that use also a BGP control
plane but also includes the additional features and related
parameters RFC7432 and RFC7209.  The model allows the
configuration of the EVPN service interface type, the local and
remote VPWS Service Instance (VSI) RFC8214, the EVPN policies for
handling MAC addresses and the Ethernet Segment Identifier (ESI)
information.
Paragraph (version B):
A Multipoint VPLSs that use a mesh of LDP-signaled Pseudowires
RFC6074.  The model allows configuring the T-LDP PWE type, MTU
mismatch and the list of AC and PW bindings.
Paragraph (version B):
The L2 VPN uses L2TP-signaled Pseudowires as described in RFC6074.
The model allows configuring TBC.
Draft: draft-ietf-opsawg-l3sm-l3nm

Commentary: The term was used with signalling and signaling . I modified it to signaling , so it is aligned with  as well
Paragraph (version A):
Groups a set of parameters that are used when CsC is enabled such
the use of BGP for signalling purposes RFC8277.
Paragraph (version B):
Groups a set of parameters that are used when CsC is enabled such
the use of BGP for signaling purposes RFC8277.
Draft: draft-ietf-opsawg-l3sm-l3nm

Commentary: Thanks .
Paragraph (version A):
Two timers can be captured in this container: (1) 'hold-time'
which is the time interval that will be used for the HoldTimer
(Section 4.2 of RFC4271) when establishing a BGP session.  (2)
'keep-alive' which is the time interval for the KeepAlive timer
between a PE and a BGP peer (Section 4.4 of RFC4271).
Paragraph (version B):
Two timers can be captured in this container: (1) 'hold-time'
which is the time interval that will be used for the HoldTimer
(Section 4.2 of RFC4271) when establishing a BGP session.  (2)
'keepalive' which is the time interval for the KeepAlive timer
between a PE and a BGP peer (Section 4.4 of RFC4271).
Paragraph (version A):
Indicates the IS-IS level: Level 1, Level2, or both.
Paragraph (version B):
Indicates the IS-IS level: Level 1, Level 2, or both.
Paragraph (version A):
Controls the authentication schemes to be enabled for the IS-IS
instance.
Paragraph (version B):
Controls the authentication schemes to be enabled for the IS-IS
instance.  Both the specification of a key-chain RFC8177 and
the direct specification of key and authentication algorithm
are supported.
Paragraph (version B):
Carries the IP address of the peer.
Paragraph (version B):
Includes virtual IP addresses for a single VRRP group.
Paragraph (version B):
Is the minimum interval, in microseconds, that a PE would like to
use when transmitting BFD Control packets less any jitter applied.
Paragraph (version B):
Is the minimum interval, in microseconds, between received BFD
Control packets that a PE is capable of supporting, less any
jitter applied by the sender.
Paragraph (version B):
The negotiated transmit interval, multiplied by this value,
provides the detection time for the PE.
Paragraph (version A):
Indicates the MTU at service level.  It can be the IP MTU or MPLS
MTU, for example.
Paragraph (version B):
Indicates the MTU at the service level.
Paragraph (version B):
Several data nodes defined in the L3NM rely upon RFC8177 for
authentication purposes.  Therefore, this module inherits the
security considerations discussed in Section 5 of RFC8177.
Paragraph (version A):
Point-to-point Virtual Private Wire Service (VPWS) as defined
in RFC8214.
Paragraph (version B):
Virtual Private Wire Service (VPWS) as defined in Section 3.1.1
of RFC4664.
Paragraph (version B):
VPWS as defined in RFC8214.
Paragraph (version A):
such as OSPF RFC6565, Bidirectional Forwarding Detection (BFD)
RFC5880, and Virtual Router Redundancy Protocol (VRRP) RFC5798.
Paragraph (version B):
such as BGP RFC4271, OSPF RFC6565, IS-IS ISO10589, RIP RFC2453,
Bidirectional Forwarding Detection (BFD) RFC5880, and Virtual
Router Redundancy Protocol (VRRP) RFC5798.
Draft: draft-ietf-opsawg-l3sm-l3nm-04

Commentary: Error : Unable to parse the XML document : draft - ietf - opsawg - l3sm - l3nm- < string : Line 4822 : Entity ' RFC6991 ' not defined < string : Line 4823 : Entity ' RFC8294 ' not defined < string : Line 4867 : Entity ' RFC8277 ' not defined The command " xml2rfc draft - ietf - opsawg - l3sm - l3nm- " exited with 1 . can you update ?
Paragraph (version A):
The YANG data models defined in this document conform to the Network
Management Datastore Architecture (NMDA) RFC8342.
Draft: draft-ietf-opsawg-l3sm-l3nm-04

Commentary: : can you please generate a new txt and put it in the master . Thanks .
Paragraph (version A):
The detailed tree structure is provided in module_tree.
Paragraph (version A):
The 'vpn-profiles' containers (vpn_profiles_tree) allow the network
provider to define and maintain a set of common VPN profiles that
apply to several VPN services.  The exaact definition of the profiles
is local to each network provider.
Paragraph (version B):
The 'vpn-profiles' containers (vpn_profiles_tree) allow the network
provider to define and maintain a set of common VPN profiles that
apply to several VPN services.  The exact definition of the profiles
is local to each network provider.
Draft: draft-ietf-opsawg-l3sm-l3nm-04

Commentary: This is redundant with the description section + a tree spanning many many pages is difficult to use .
Paragraph (version A):
The L3NM Module Tree Structure is depicted in module_tree.
Draft: draft-ietf-opsawg-l3sm-l3nm-04

Commentary: More details about the common module will be in a new section
Paragraph (version A):
The YANG data model defined in this document is called L3VPN Network
Model (L3NM).  The L3NM module is aimed at providing a network-
centric view of L3 VPN Services.  The data model can be used to
facilitate communication between the service orchestrator (or a
network operator) and the network controller/orchestrator by allowing
for more network-centric information to be included.  It enables
further capabilities, such as resource management or to serve as a
multi-domain orchestration interface, where logical resources (such
as route targets or route distinguishers) must be synchronized.
Paragraph (version B):
This document defined a YANG module called L3VPN Network Model
(L3NM).  The L3NM module is aimed at providing a network-centric view
of L3 VPN Services.  This data model can be used to facilitate
communication between the service orchestrator (or a network
operator) and the network controller/orchestrator by allowing for
more network-centric information to be included.  It enables further
capabilities, such as resource management or to serve as a multi-
domain orchestration interface, where logical resources (such as
route targets or route distinguishers) must be synchronized.
Paragraph (version B):
The document also defines a generic module that is intended to be
reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2
Network Model): "ietf-vpn-common".
Draft: draft-ietf-opsawg-l3sm-l3nm-04

Commentary: Also made some minor edits
Paragraph (version B):
Multicast services over L3VPN can be implemented either using dual
PIM MVPNs (also known as, Draft Rosen model) [RFC4364] or
multiprotocol BGP (MBGP)-based MVPNs[RFC6513][RFC6514].  Both methods
are supported and equally effective, but the main difference is that
MBGP-based MVPN does not require multicast configuration on the
service provider backbone.  MBGP MVPNs employ the intra-autonomous
system BGP control plane and PIM sparse mode as the data plane.  The
PIM state information is maintained between the PE routers using the
same architecture that is used for unicast VPNs.
Paragraph (version B):
On the other hand, Draft Rosen has limitations such as reduced
options for transport, control plane scalability, availability,
operational inconsistency, and the need of maintaining state in the
backbone.  Because of this, MBGP MVPN is the architectural model that
has been taken as the base for implementing multicast service on
L3VPN.  In this scenario, BGP auto discovery is used to discover MVPN
PE members and the customer PIM signaling is sent across provider
core through MP-BGP.  The multicast traffic is transported on MPLS
P2MP LSPs.  All of the previous information is carried in the MCAST-
VPN BGP NRLI.
Paragraph (version A):
Multicast services over L3VPN can be implemented either using dual
PIM MVPNs (also known as Draft Rosen model) [RFC 4364] or
multiprotocol BGP (MBGP)-based MVPNs called Next Generation Multicast
VPN (ng-MVPN) [RFC 6513/6514].  Both methods are supported and
equally effective, but the main difference is that MBGP-based MVPN
does not require multicast configuration on the service provider
backbone.  Multiprotocol BGP multicast VPNs employ the intra-
autonomous system (AS) next-generation BGP control plane and PIM
sparse mode as the data plane.  The PIM state information is
maintained between the PE routers using the same architecture that is
used for unicast VPNs.
Paragraph (version A):
On the other hand, Draft Rosen has limitations such as reduced
options for transport, control plane scalability, availability,
operational inconsistency and the need of maintaining state in the
backbone.  Because of this, ng-MNPN is the architectural model that
has been taken as the base for implementing multicast service on
L3VPN.  In this scenario, BGP auto discovery is used to discover MVPN
PE members and the customer PIM signaling is sent across provider
core through MP-BGP.  The multicast traffic is transported on MPLS
P2MP LSPs.  All of the previous information is carried in the MCAST-
VPN BGP NRLI.
Draft: draft-ietf-opsawg-l3sm-l3nm-01

Commentary: to be aligned with
Paragraph (version A):
vrrp: takes only a list of address-family as parameter.  VRRP
instance is expected to run on the vpn-network-access interface.
Paragraph (version A):
rip: takes only a list of address-family as parameter.  RIP
instance is expected to run on the vpn-network-access interface.
Paragraph (version A):
static: allows user to configure one or more IPv4 and IPv6 static
routes.
Paragraph (version A):
bgp: allows the user to configure a BGP neighbor including
parameters like authentication using a key.  The authentication
type will be driven by the implementation but the model supports
any authentication that uses a key as a parameter.  A BGP neighbor
can support ipv4, ipv6, or both address-families.  Again, it is up
to the implementation to drive the device configuration (e.g.
separate BGP sessions for Dual Stack, single session for Dual
Stack, etc.).
Paragraph (version B):
vrrp: takes only a list of address-family as parameter.  VRRP
instance is expected to run on the 'vpn-network-access' interface.
Paragraph (version B):
rip: takes only a list of address-family as parameter.  RIP
instance is expected to run on the 'vpn-network-access' interface.
Paragraph (version B):
static: allows user to configure one or more IPv4 and/or IPv6
static routes.
Paragraph (version B):
bgp: allows to configure a BGP neighbor including parameters like
authentication using a key.  The authentication type will be
driven by the implementation but the module supports any
authentication that uses a key as a parameter.  A BGP neighbor can
support IPv4, IPv6, or both address families.  The module supports
supplying two neighbors (each for a given address family) or one
neighbor (for both IPv4 and IPv6 of "address-family" attribute is
set to both).  It is then up to the implementation to drive the
device configuration.
Draft: draft-ietf-opsawg-l3sm-l3nm-01

Commentary: The document does not cover renumbering matter or DHCPv6 .
Paragraph (version A):
The document is aimed at modeling BGP PE-based VPNs in a Service
Provider Network, so the terms defined in RFC4026 and RFC4076 are
used.
Paragraph (version B):
The document is aimed at modeling BGP PE-based VPNs in a Service
Provider Network, so the terms defined in RFC4026 and RFC4176 are
used.
Draft: draft-ietf-opsawg-l3sm-l3nm-01

Commentary: Allows a controller to expose the L3SM to which an L3NM is bound 
 OK ! It is optional . Should work typically the other way around , allows the service orchestrator to maintain the match and facilitate reconciliation . Please add some text in the draft to explain the parameter 
 Please see the change : Will add more text once we will work seriously on the tree structure part .
Paragraph (version A):
Some of the information captured in the L3SM can be passed by the
Orchestrator in the L3NM (e.g., customer) or be used to fed some of
the L3NM attribute (e.g., actual forwarding policies).  Some of the
information captured in L3SM may be maintained locally within the
Orchestrator; which is supposed to maintain a "glue" between a
Customer view and its network instantiation.
Paragraph (version B):
Some of the information captured in the L3SM can be passed by the
Orchestrator in the L3NM (e.g., customer) or be used to fed some of
the L3NM attribute (e.g., actual forwarding policies).  Some of the
information captured in L3SM may be maintained locally within the
Orchestrator; which is supposed to maintain a "glue" between a
Customer view and its network instantiation.  Likewise, some of the
information captured and exposed using L3NM can fed the service layer
(e.g., capabilities) to derive L3SM and drive VPN service order
handling.
Draft: draft-ietf-opsawg-l3sm-l3nm-01

Commentary: can you fix the conflicts ? I accepted your previous change request that touched the XML file . I thought I could accept both in a row … but it seems not 
 Fixed . Please check now .
Paragraph (version B):
L3NM is not a Customer Service Model.
Paragraph (version B):
The internal view of the service (L3NM) may be mapped to an
external view which is visible to Customers : L3VPN Service YANG
data Model (L3SM) RFC8299.
Paragraph (version B):
Typically, the L3NM module can be fed with inputs that are
requested by Customers, typically, relying upon a L3SM template.
Concretely, some parts of the L3SM module can be directly mapped
into L3NM while other parts are generated as a function of the
requested service and local guidelines.  Some other parts are
local to the Service Provider and do not map directly to L3SM.
Paragraph (version B):
Note that the use of L3NM within a Service Provider does assume
nor preclude exposing the VPN service via L3SM.  This is
deployment-specific.  Nevertheless, the design of L3NM tries to
align as much as possible with the features supported by the L3SM
to ease grafting both L3NM and L3SM for the sake of highly
automated VPN service provisioning and delivery.
Paragraph (version B):
A L3VPN involves nodes that are part of a topology managed by the
Service Provider Backbone network.  Such topology can be
represented as using the network topology module in RFC8345.
Paragraph (version B):
L3NM is not a device model.
Paragraph (version B):
How L3NM is used to derive device-specific actions is
implementation-specific.
Paragraph (version A):
The L3NM model, aimed at managing the L3VPN Services in a Service
Provider Network controller/orchestrator has relations with other
Yang modules.
Paragraph (version A):
RFC8299 defines a L3VPN Service YANG data Model (L3SM) that can be
used for communication between customers and VPN service providers.
Hence, the model provides inputs to the Network Operator to deliver
such service to the customer.  Hence, some parts of the model can be
directly mapped into L3NM.
Paragraph (version A):
Routing protocols requested by the client at PE-CE interface.  In
sake of alignment, the same protocols are supported.
Paragraph (version A):
The L3NM model manages VPN Services running over Service Provider
Backbone network.  The set of nodes over which it is possible to
deploy a L3 VPN Service MAY be part of the topology contained in an
ietf-network module.
Paragraph (version A):
Creating services in the l3vpn-ntw module will will lead at some
point to the configuration of devices.  Hence, it is foreseen that
the data for the device yang modules will be derived partially from
the L3NM vpn-service container.  Note that L3NM is NOT a device
model.
Draft: draft-ietf-opsawg-l3sm-l3nm-01

Commentary: an addition to the abstract fix a reference issue ( pointer to evpn ) uplevel 1.1 and 1.2
Paragraph (version A):
There is a need for a more network-centric YANG data model to be used
in the communication between the entity that interacts directly with
the customer, the service orchestrator, (either fully automated or a
human operator) and the entity in charge of network orchestration and
control (a.k.a., network controller/orchestrator).
Paragraph (version B):
There is a need for a more network-centric YANG data model to be used
in the communication between the entity that interacts directly with
the customer, the service orchestrator, (either fully automated or a
human operator) and the entity in charge of network orchestration and
control (a.k.a., network controller/orchestrator).  Such model is
meant to capture a (internal) network-oriented VPN Service that will
be used for the actual provisioning and delivery of the service.
Paragraph (version A):
The L3NM module does not attempt to address all deployment cases
especially those where the L3VPN connectivity is supported through
the coordination of different VPNs in different underlying networks.
More complex deployment scenarios involving the coordination of
different VPN instances and different technologies to provide end-to-
end VPN connectivity are addressed by a complementary YANG model
defined in [I-D.evenwu-opsawg-yang-composed-vpn].
Paragraph (version B):
The L3NM module does not attempt to address all deployment cases
especially those where the L3VPN connectivity is supported through
the coordination of different VPNs in different underlying networks.
More complex deployment scenarios involving the coordination of
different VPN instances and different technologies to provide end-to-
end VPN connectivity are addressed by a complementary YANG model
defined in I-D.evenwu-opsawg-yang-composed-vpn.
Draft: draft-ietf-opsawg-l3sm-l3nm-01

Commentary: Please check the table structure at :
Paragraph (version B):
Also, please update the "revision" date of the YANG module.