jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-anima-brski-prm

Commentary: move YANG to RFC8366bis 
 Some corrections are necessary regarding the referenced fields defined . BRSKI - PRM specifies the agent - provided - registrar - certificate in contrast to the registar - proximity - certificate . Will be addressed in the next commit .
The enhancements of the YANG module for the ietf-voucher-request with
these new leaves are defined in voucher-request-prm-yang.
The enhancements of the YANG module for the ietf-voucher-request with
these new leaves are defined in RFC8366bis.
The following enhancement extends the voucher-request as defined in
RFC8995 to include additional fields necessary for handling
bootstrapping in the pledge-responder-mode.
The following tree diagram is mostly a duplicate of the contents of
RFC8995, with the addition of the fields agent-signed-data,
registrar-proximity-certificate, and agent-signing certificate.  The
tree diagram is described in RFC8340.  Each node in the diagram is
fully described by the YANG module in Section voucher-request-prm-
yang-module.
The following YANG module extends the RFC8995 Voucher Request to
include a signed artifact from the registrar-agent (agent-signed-
data) as well as the registrar-proximity-certificate and the agent-
signing certificate.
RFC8366bis extends the voucher-request as defined in RFC8995 to
include additional fields necessary for handling bootstrapping in the
pledge-responder-mode.  They are: agent-signed-data, registrar-
proximity-certificate, and agent-signing certificate.
The YANG module specified in RFC8366bis defines the schema for data
that is subsequently encapsulated by a JOSE signed-data Content-type
as described in I-D.ietf-anima-jws-voucher.  As such, all of the
YANG-modeled data is protected against modification.
Draft: draft-ietf-anima-brski-prm

Commentary: Included in the text . Maybe will include further text for 
 In 5.5.1 : This kind of suggests that an Agent may also not know the serial number . But in creating the agent - signed - data , this number is required later on . Could we clarify perhaps the Agent MUST know the serial - number ; e.g. in one of these ways : ( as in quoted text above ) ( in " standard " way using mDNS / DNS - SD first part of service instance name ) ( in vendor - specific way e.g.  beacons ) ( in vendor - specific way , e.g. scan QR code of packaging ) - maybe that 's the same as category 1 from the Agent point of view . 
 Additional Note : figure 4 does n't show the part where the Agent discovers the serial number of the Pledge . This was adding to the confusion . Maybe figure 4 can stay as is ; this is just to clarify that at the start of  4 the Agent MUST know the serial - number . So some small link is missing to get the complete picture . 
 I reopened as the initial point if the registrar - agent MUST know the serial number is not solved by the QR code reference . As the registrar - agent needs to know , which pledges he is bootstrapping , he needs the list of serial numbers in advance to be able to construct the agent signed data . Text proposed will be included into the pre - conditions described in section 5.5.1 , In addition , the registrar - agent MUST know the product - serial - number(s ) of the pledge(s ) to be bootstrapped . The registrar - agent  be provided with the product - serial - number in different ways : configured , e.g. , as a list of pledges to be bootstrapped via QR code scanning discovered by using standard approaches like mDNS as described in 5.4.2 . discovered by using a vendor specific approach , e.g. , RF beacons 
 Ok
In addition to the LDevID(RegAgt), the registrar-agent is provided
with the product-serial-numbers of the pledges to be bootstrapped.
This is necessary to allow the discovery of pledges by the registrar-
agent using mDNS.  The list may be provided by administrative means
or the registrar agent may get the information via an interaction
with the pledge, like scanning of product-serial-number information
using a QR code or similar.
In addition to the LDevID(RegAgt), the registrar-agent is provided
with the product-serial-numbers of the pledges to be bootstrapped.
This is necessary to allow the discovery of pledges by the registrar-
agent using mDNS.  The list may be provided by administrative means
or the registrar agent may get the information via an interaction
with the pledge.  For instance, RFC9238 describes scanning of a QR
code, the product-serial-number would be initialized from the 12N
B005 Product Serial Number.