jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: anima-brski-cloud

Commentary: Should specify that you mean " routeable " IP address , I think . ( I suppose it could be a ULA in some deployments ? ) 
 I 'm not sure routeable is correct . I think that many will think it means an address which is world reachable , when any kind of NAT44 , SOCKS , or HTTP - PROXY'able address would work . ( there are still enterprises that use 10./8 without a default route and socks / http - proxy ... )
The assumption is that the pledge already has network connectivity
prior to connecting to the cloud registrar.  The pledge must have an
IP address, must be able to make DNS queries, and must be able to
send HTTP requests to the cloud registrar.  The pledge operator has
already connected the pledge to the network, and the mechanism by
which this has happened is out of scope of this document.
The assumption is that the pledge already has network connectivity
prior to connecting to the cloud registrar.  The pledge must have an
IP address, must be able to make DNS queries, and must be able to
send HTTP requests to the cloud registrar.  The pledge operator has
already connected the pledge to the network, and the mechanism by
which this has happened is out of scope of this document.  Similarly,
what address space the IP address belongs to, whether it is an IPv4
or IPv6 address, or if there are firewalls or proxies deployed
between the pledge and the cloud registar are all out of scope of
this document.
Draft: anima-brski-cloud

Commentary: I find the " ? ? " in the figure confusing .    and the MASA could just be shown as adjacent boxes ; the explanation in the text is fine . That looks ugly as a single pseudo - sentence , and I 'm not sure what it means . A more complete explanation would be good .
TWO CHOICES: 1.  Cloud Registrar redirects to Owner Registrar 2.
Cloud Registrar returns VOUCHER pinning Owner Register.
Both mechanisms are described in detail later in this document.
Draft: anima-brski-cloud

Commentary: Not quite . It specifies secure bootstrapping of the individual nodes . It 's RFC 8994 that bootstraps the ACP .
Bootstrapping Remote Secure Key Infrastructures BRSKI specifies
automated bootstrapping of an Autonomic Control Plane.  BRSKI
Section 2.7 describes how a pledge "MAY contact a well-known URI of a
cloud registrar if a local registrar cannot be discovered or if the
pledge's target use cases do not include a local registrar".
Bootstrapping Remote Secure Key Infrastructures BRSKI specifies
automated network onboarding of devices, referred to as pledges,
within an Autonomic Control Plane or other managed network
infrastructure.  BRSKI Section 2.7 describes how a pledge "MAY
contact a well-known URI of a cloud registrar if a local registrar
cannot be discovered or if the pledge's target use cases do not
include a local registrar".
Draft: anima-brski-cloud

Commentary: The two occurences of lower - case " may " might be clearer as " might " . " The Pledge can be done with " ? ? ? ? " may " or " MAY " ? There are a few occurences of " should " and " must " in these sections , and I wondered about " SHOULD " and " MUST " .
BRSKI defines how a pledge MAY contact a well-known URI of a cloud
registrar if a local domain registrar cannot be discovered.
Additionally, certain pledge types may never attempt to discover a
local domain registrar and may automatically bootstrap against a
cloud registrar.
BRSKI defines how a pledge MAY contact a well-known URI of a cloud
registrar if a local domain registrar cannot be discovered.
Additionally, certain pledge types might never attempt to discover a
local domain registrar and might automatically bootstrap against a
cloud registrar.
The pledge MUST use an Implicit Trust Anchor database (see EST
RFC7030) to authenticate the cloud registrar service.  The Pledge can
be done with pre-loaded trust-anchors that are used to validate the
TLS connection.  This can be using a public Web PKI trust anchors
using RFC6125 DNS-ID mechanisms, a pinned certification authority, or
even a pinned raw public key.  This is a local implementation
decision.
The pledge MUST use an Implicit Trust Anchor database (see EST
RFC7030) to authenticate the cloud registrar service.  In order to
make use of a Cloud Registrar, the Pledge MUST be manufactured with
pre-loaded trust-anchors that are used to validate the TLS
connection.  The TLS connection can be validated using a public Web
PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned
certification authority, or even a pinned raw public key.  This is a
local implementation decision.
The cloud registrar must determine pledge ownership.  if the
registrar is unwilling or unable to handle the voucher request, for
example it is unable to determine ownership, then the cloud registrar
MUST return a suitable 4xx or 5xx error response to the pledge.
The cloud registrar returned a voucher to the pledge.  The pledge
should perform voucher verification as per standard BRSKI operation.
The pledge should verify the voucher signature using the
manufacturer-installed trust anchor(s), should verify the serial
number in teh voucher, and must verify any nonce information in the
voucher.
The cloud registrar returned a voucher to the pledge.  The pledge
SHOULD perform voucher verification as per standard BRSKI operation.
The pledge SHOULD verify the voucher signature using the
manufacturer-installed trust anchor(s), SHOULD verify the serial
number in the voucher, and SHOULD verify any nonce information in the
voucher.
Draft: anima-brski-cloud

Commentary: This reflects that all YANG activity has been rolled up into draft - ietf - anima - rfc8366bis . 
 the YANG contains " RFC XXXX : Voucher Profile for Cloud redirected Devices " - it seems the name needs updating and there should be an RFC ednote here saying the reference is " this RFC " . Correct?YANG contains this : description " Base the constrained voucher upon the regular one " ; This looks like a copy / paste leftover from constrained - voucher ; correct that it should be modified ? ( Would this also bump the YANG version and date then ? ) YANG description for leaf " est - domain " does not explicitly say the word " EST server " which I think it should . So this URI directs to the EST server in the owner 's YANG support the use case of combining the voucher - constrained format ( that extends base voucher ) and the voucher - redirected format ( from current draft ) ? Would that require yet another new YANG module ? 
 Also , the YANG extensions need to move to RFC8366bis !
An extension to the RFC8366 voucher is needed for the case where the
client will be redirected to a local EST Registrar.
RFC8366bis contains the two needed voucher extensions: est-domain and
additional-configuration which are needed when a client is redirected
to a local EST Registrar.
This document makes no IANA requests.
The Cloud Registrar does not have a certificate that can be validated
using a public (WebPKI) anchor.  The pledge may have any kind of
Trust Anchor built in: from full multi-level WebPKI to the single
self-signed certificate used by the Cloud Registrar.  There are many
tradeoffs to having more or less of the PKI present in the Pledge,
which is addresses in part in I-D.richardson-t2trg-idevid-
considerations in sections 3 and 5.
The Cloud Registrar does not have a certificate that can be validated
using a public (WebPKI) anchor.  The pledge may have any kind of
Trust Anchor built in: from full multi-level WebPKI to the single
self-signed certificate used by the Cloud Registrar.  There are many
tradeoffs to having more or less of the PKI present in the Pledge,
which is addresses in part in I-D.irtf-t2trg-taxonomy-manufacturer-
anchors in sections 3 and 5.
Draft: anima-brski-cloud

Commentary: This includes Rifaat 's changes from
The returned voucher contains an attribute, "est-domain", defined in
redirected below.  The pledge is directed to continue enrollment
using the EST registrar found at that URI.  The pledge uses the
pinned-domain-cert from the voucher to authenticate the EST
registrar.
The process starts, in step 1, when the Pledge establishes a Mutual
TLS channel with the Cloud RA/MASA using artifacts created during the
manufacturing process of the Pledge.  In step 2, the Pledge sends a
voucher request to the Cloud RA/MASA, and in response the Pledge
receives an RFC8366 format voucher from the Cloud RA/MASA that
includes its assigned EST domain in the est-domain attribute.
At this stage, the Pledge should be able to establish a TLS channel
with the EST Registrar.  The connection may involve crossing the
Internet requiring a DNS lookup on the provided name.  It may also be
a local address that includes an IP address literal including both
RFC1918 and IPv6 Unique Local Address.
The EST Registrar is validated using the pinned-domain-cert value
provided in the voucher as described in section 5.6.2 of I-D.ietf-
anima-bootstrapping-keyinfra.  This involves treating the artifact
provided in the pinned-domain-cert as a trust anchor, and attempting
to validate the EST Registrar from this anchor only.
There is a case where the pinned-domain-cert is the identical End-
Entity (EE) Certificate as the EST Registrar.
It also explicitly includes the case where the EST Registrar has a
self-signed EE Certificate, but it may also be an EE certificate that
is part of a larger PKI.  If the certificate is not a self-signed or
EE certificate, then the Pledge SHOULD apply RFC6125 DNS-ID
validation on the certificate against the URL provided in the est-
domain attribute.  If the est-domain was provided by with an IP
address literal, then it is unlikely that it can be validated, and in
that case, it is expected that either a self-signed certificate or an
EE certificate will be pinned.
The Pledge also has the details it needs to be able to create the CSR
request to send to the RA based on the details provided in the
voucher.
In step 4, the Pledge establishes a TLS channel with the Cloud RA/
MASA, and optionally the pledge should send a request, steps 3.a and
3.b, to the Cloud RA/MASA to inform it that the Pledge was able to
establish a secure TLS channel with the EST Registrar.
The Pledge then follows that, in step 5, with an EST Enroll request
with the CSR and obtains the requested certificate.  The Pledge must
validate that the issued certificate has the expected identifier
obtained from the Cloud RA/MASA in step 3.
Draft: anima-brski-cloud

Commentary: this the YANG machinery and a basic extension to RFC8366 to add the est - domain attribute . 
 Looks good .
An extension to the RFC8366 voucher is needed for the case where the
client will be redirected to a local EST Registrar.
Draft: anima-brski-cloud

Commentary: This should be a do - nothing change to the content , which just starts every sentence on fresh line . This aids greatly in reading diffs . One paragraph break , and one period changed to a dot . And I seem to have included the IEEE reference fix by mistake .
For example, the pledge may only be aware of its IDevID Subject which
includes a manufacturer serial number, but must include a specific
fully qualified domain name in the CSR in order to complete domain
ownership proofs required by the CA.  As another example, the
registrar may deem the manufacturer serial number in an IDevID as
personally identifiable information, and may want to specify a new
random opaque identifier that the pledge should use in its CSR.
For example, the pledge may only be aware of its IDevID Subject which
includes a manufacturer serial number, but must include a specific
fully qualified domain name in the CSR in order to complete domain
ownership proofs required by the CA.
As another example, the registrar may deem the manufacturer serial
number in an IDevID as personally identifiable information, and may
want to specify a new random opaque identifier that the pledge should
use in its CSR.
The cloud registrar returned a voucher to the pledge.  The pledge
should perform voucher verification as per standard BRSKI operation.
The pledge should verify the voucher signature using the
manufacturer-installed trust anchor(s). should verify the serial
number in teh voucher, and must verify any nonce information in the
voucher.
The cloud registrar returned a voucher to the pledge.  The pledge
should perform voucher verification as per standard BRSKI operation.
The pledge should verify the voucher signature using the
manufacturer-installed trust anchor(s), should verify the serial
number in teh voucher, and must verify any nonce information in the
voucher.