jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: dtbootstrap-anima-keyinfra

Commentary: ( n.b . , i was not able to " make " and test the change , due to external pyang dependencies of some form .
The IANA is requested to list the name "masa" in the MUD extensions
registry defined in I-D.ietf-opsawg-mud.  Its use is documented in
mud-extension.
Draft: dtbootstrap-anima-keyinfra

Commentary: Adds text to include SNI in BRSKI - MASA handshake . 
 I like the first diff ( expanding the client authentication discussion into a paragraph ) . I do n't see the need for RFC6066 SNI reference . But since it is a " SHOULD " do n't have a technical complaint .
The primary method of Registrar "authentication" by the MASA is
detailed in RequestVoucherFromMASA.  As detailed in
securityconsiderations the MASA might find it necessary to request
additional Registrar authentication.  Registrars MUST be prepared to
support TLS client certificate authentication and HTTP Basic or
Digest authentication as described in RFC7030 for EST clients.
Implementors are advised that contacting the MASA is to establish a
secured REST connection with a web service and that there are a
number of authentication models being explored within the industry.
Registrars are RECOMMENDED to fail gracefully and generate useful
administrative notifications or logs in the advent of unexpected HTTP
401 (Unauthorized) responses from the MASA.
The primary method of Registrar "authentication" by the MASA is
detailed in RequestVoucherFromMASA.  As detailed in
securityconsiderations the MASA might find it necessary to request
additional Registrar authentication.
The Registrar is the client in the BRSKI-MASA connection.  When
operating as such, the Registrars MUST be prepared to support TLS
client certificate authentication.  The registrar should also be
configurable to support HTTP Basic or Digest authentication as
described in RFC7030 for EST clients: provision of such credentials
of outside the scope of this document and would be part of a supply-
chain integration process.
Implementors are advised that contacting the MASA is to establish a
secured REST connection with a web service and that there are a
number of authentication models being explored within the industry.
Registrars are RECOMMENDED to fail gracefully and generate useful
administrative notifications or logs in the advent of unexpected HTTP
401 (Unauthorized) responses from the MASA.
In order to support multi-tenant MASA implementations the Registrar
SHOULD include the RFC6066 Server Name Indicator.
Draft: dtbootstrap-anima-keyinfra

Commentary: Proposes 201 / Location : operation optional for /requestauditlog end - point . 
 Think we should discuss .
This is done with an HTTPS POST using the operation path value of
"/requestvoucher".
This is done with an HTTPS POST using the operation path value of
"/.well-known/est/requestvoucher".
This is done with an HTTP POST using the operation path value of
"/requestvoucher".
This is done with an HTTP POST using the operation path value of
"/.well-known/est/requestvoucher".
This is done with an HTTP GET using the operation path value of
"/requestauditlog".
This is done with an HTTP GET using the operation path value of
"/.well-known/est/requestauditlog".
Rather than returning the audit log as a response to the POST (with a
return code 200), the MASA MAY instead return a 201 ("Created")
RESTful response (RFC7231 section 7.1) containing a URL to the
prepared (and easily cachable) audit response.
MASA servers that return URLs SHOULD take care to make the returned
URL unguessable.  URLs containing a database number such as
https://example.com/auditlog/1234 or the EUI of the device such
https://example.com/auditlog/10-00-00-11-22-33, would be easily
enumerable by an attacker.  It is recommended put to put some
meaningless randomly generated slug that indexes a database instead.
A MASA that returns a code 200 MAY also include a Location: header
for future reference by the Registrar.
Draft: dtbootstrap-anima-keyinfra

Commentary: action items complete .
The Domain Registrar (having the formal name Join Registrar/
Coordinator (JRC)), operates as a CMC Registrar, terminating the EST
connections.  The Registrar communicates with the Vendor supplied
MASA to establish ownership.
The Domain Registrar (having the formal name Join Registrar/
Coordinator (JRC)), operates as a CMC Registrar, terminating the EST
and BRSKI connections.  The Registrar is manually configured or
distributed with a list of trust anchors necessary to authenticate
any Pledge device expected on the network.  The Registrar
communicates with the Vendor supplied MASA to establish ownership.
The device's Initial Device Identifier will normally contain the MASA
URL as detailed in IDevIDextension.  This is the RECOMMENDED
mechanism.
If the Registrar is integrated with I-D.ietf-opsawg-mud and the
Pledge IDevID contains the id-pe-mud-url then the Registrar MAY
attempt to obtain the MASA URL from the MUD file.  The MUD file
extension for the MASA URL is defined in mud-extension.
It can be operationally difficult to ensure the necessary X.509
extensions are in the Pledge's' IDevID due to the difficulty of
aligning current Pledge manufacturing with software releases and
development.  As a final fallback the Registrar MAY be manually
configured or distributed with a MASA URL for each vendor.  Note that
the Registrar can only select the configured MASA URL based on the
trust anchor -- so vendors can only leverage this approach if they
ensure a single MASA URL works for all Pledge's associated with each
trust anchor.