jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-dnssd-srp

Commentary:   wrote : 
 I noticed this was missing during my shepherd review . Please add the necessary boilerplate . 
 Fixed by
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Draft: draft-ietf-dnssd-srp

Commentary:   pointed out : This PR implements  's suggestion . 
 I noticed this during my shepherd review . Section creates a new registry but is lacking sufficient information for IANA to create the registry . In particular , the registration procedure is missing . Please refer to RFC 8126 for guidance . 
 Fixed by
Paragraph (version B):
This document only makes use of the 'default.service.arpa' subdomain
of 'service.arpa.'  Other subdomains are reserved for future use by
DNS-SD or related work.  The IANA is requested to create a registry,
the "service.arpa Subdomain Registry".  The IETF shall have change
control for this registry.  New entries may be added either as a
result of Standards Action RFC8126 or with IESG approval RFC 8126,
provided that a specification exists RFC8126.
Paragraph (version B):
The IANA shall group the "service.arpa Subdomain Registry" with the
"Locally-Served DNS Zones" registry.  The registry shall be a table
with three columns: the subdomain name (expressed as a fully-
qualified domain name), a brief description of how it is used, and a
reference to the document that describes its use in detail.
Draft: draft-ietf-dnssd-srp

Commentary: Add a reference to the IAB statement on the registration of special use names in the ARPA domain .
Paragraph (version A):
In order to be fully functional, the owner of the 'arpa.' zone must
add a delegation of 'service.arpa.' in the '.arpa.' zone RFC3172.
This delegation should be set up as was done for 'home.arpa', as a
result of the specification in RFC8375.
Draft: draft-ietf-dnssd-srp

Commentary: Move the IANA considerations for into the IANA considerations section . power -energy
Paragraph (version A):
The reason for these different variants is that low-power devices
that typically use Constrained-Node Networks may have very limited
battery storage.  The series of DNS lookups required to discover an
SRP registrar and then communicate with it will increase the power
required to advertise a service; for low-power devices, the
additional flexibility this provides does not justify the additional
use of energy.  It is also fairly typical of such networks that some
network service information is obtained as part of the process of
joining the network, and so this can be relied upon to provide nodes
with the information they need.
Paragraph (version B):
The reason for these different variants is that low-power devices
that typically use Constrained-Node Networks may have very limited
battery storage.  The series of DNS lookups required to discover an
SRP registrar and then communicate with it will increase the energy
required to advertise a service; for low-power devices, the
additional flexibility this provides does not justify the additional
use of energy.  It is also fairly typical of such networks that some
network service information is obtained as part of the process of
joining the network, and so this can be relied upon to provide nodes
with the information they need.
Draft: draft-ietf-dnssd-srp

Commentary: Add a definition for DNS - SD .
Paragraph (version A):
This document describes an enhancement to RFC6763 that allows servers
to register the services they offer using the DNS protocol rather
than using RFC6762 (mDNS).  There is already a large installed base
of DNS-SD clients that can discover services using the DNS protocol.
Paragraph (version B):
This document describes an enhancement to RFC6763 (DNS-SD) that
allows servers to register the services they offer using the DNS
protocol rather than using RFC6762 (mDNS).  There is already a large
installed base of DNS-SD clients that can discover services using the
DNS protocol.
Draft: draft-ietf-dnssd-srp

Commentary: I had a brief chat with Qiaoyu and the change here is the result of that discussion , including a minor editorial fix that makes a compound sentence a little more comprehensible ( I hope ) .
Paragraph (version A):
Full-featured hosts are either configured manually with a
registration domain, or discover the default registration domain as
described in RFC6763.  If this process does not produce a default
registration zone, the Service Registration protocol is not
discoverable on the local network using this mechanism.  Other
discovery mechanisms are possible, but are out of scope for this
document.
Paragraph (version B):
Full-featured hosts either are configured manually with a
registration domain, or discover the default registration domain as
described in RFC6763.  If this process does not produce a default
registration zone, the Service Registration protocol is not
discoverable on the local network using this mechanism.  Other
discovery mechanisms are possible, but are out of scope for this
document.
Paragraph (version A):
We refer to the DNS Update message sent by servers using SRP as an
SRP Update.  Three types of updates appear in an SRP update: Service
Discovery records, Service Description records, and Host Description
records.
Paragraph (version B):
We refer to a DNS Update message that is constructed so as to conform
to the constraints described in server_behavior as an SRP update.
SRP Updates are sent by SRP requestors to SRP registrars.  Three
types of updates appear in an SRP update: Service Discovery records,
Service Description records, and Host Description records.
Draft: draft-ietf-dnssd-srp

Commentary: Update the draft number , date , and change draft - sekar - ul to draft - ietf - dnssd - update - lease .
Paragraph (version A):
When sending DNS updates, the requestor includes a KEY record
containing the public portion of the key in each Host Description
Instruction and each Service Description Instruction.  Each KEY
record MUST contain the same public key.  The update is signed using
SIG(0), using the private key that corresponds to the public key in
the KEY record.  The lifetimes of the records in the update is set
using the EDNS(0) Update Lease option I-D.sekar-dns-ul.
Paragraph (version B):
When sending DNS updates, the requestor includes a KEY record
containing the public portion of the key in each Host Description
Instruction and each Service Description Instruction.  Each KEY
record MUST contain the same public key.  The update is signed using
SIG(0), using the private key that corresponds to the public key in
the KEY record.  The lifetimes of the records in the update is set
using the EDNS(0) Update Lease option I-D.ietf-dnssd-update-lease.
Paragraph (version A):
Because the DNS-SD registration protocol is automatic, and not
managed by humans, some additional bookkeeping is required.  When an
update is constructed by the SRP requestor, it MUST include an
EDNS(0) Update Lease Option I-D.sekar-dns-ul.  The Update Lease
Option contains two lease times: the Lease Time and the Key Lease
Time.
Paragraph (version B):
Because the DNS-SD registration protocol is automatic, and not
managed by humans, some additional bookkeeping is required.  When an
update is constructed by the SRP requestor, it MUST include an
EDNS(0) Update Lease Option I-D.ietf-dnssd-update-lease.  The Update
Lease Option contains two lease times: the Lease Time and the Key
Lease Time.
Draft: draft-ietf-dnssd-srp

Commentary: The set of constraints for the host description includes a constrain that A and AAAA records must be of sufficient scope . This is asking a bit much of the SRP server , which may or may not be able to make this determination . There may also be cases where an SRP registration with an address of less than global scope is useful . Consequently , this constraint is removed , and text to talk about how servers should deal with addresses of less - than - global scope .
Paragraph (version B):
A and/or AAAA records that are not of of sufficient scope to be
validly published in a DNS zone can be ignored by the SRP server,
which could result in a host description effectively containing zero
reachable addresses even when it contains one or more addresses.
Paragraph (version B):
For example, if a link-scope address or IPv4 autoconfiguration
address is provided by the SRP requestor, the SRP registrar could not
publish this in a DNS zone.  However, in some situations, the SRP
registrar may make the records available through a mechanism such as
an advertising proxy only on the specific link from which the SRP
update originated; in such a situation, locally-scoped records are
still valid.
Draft: draft-ietf-dnssd-srp

Commentary: Update Service Discovery Instruction text to address    last call comments . This fixes a bogus reference , removes a confusing double negative , and splits the text hierarchically in a way that hopefully makes more sense .
Paragraph (version B):
Note that there can be more than one Service Discovery Instruction
for the same name if the SRP requestor is advertising more than one
service of the same type, or is changing the target of a PTR RR.  For
each such PTR RR add or remove, the above constraints must be met.
Draft: draft-ietf-dnssd-srp

Commentary: This is part of the previous pull request , but I missed it because it was interleaved with some unrelated changes .
Paragraph (version A):
For devices designed for Constrained-Node Networks RFC7228 some
simplifications are available.  Instead of being configured with (or
discovering) the service registration domain, the (proposed) special-
use domain name (see RFC6761) "default.service.arpa" is used.  The
details of how SRP server(s) are discovered will be specific to the
constrained network, and therefore we do not suggest a specific
mechanism here.
Paragraph (version A):
SRP clients on constrained networks are expected to receive from the
network a list of SRP servers with which to register.  It is the
responsibility of a Constrained-Node Network supporting SRP to
provide one or more SRP server addresses.  It is the responsibility
of the SRP server supporting a Constrained-Node Network to handle the
updates appropriately.  In some network environments, updates may be
accepted directly into a local "default.service.arpa" zone, which has
only local visibility.  In other network environments, updates for
names ending in "default.service.arpa" may be rewritten internally to
names with broader visibility.
Paragraph (version B):
For devices designed for Constrained-Node Networks RFC7228 some
simplifications are available.  Instead of being configured with (or
discovering) the service registration domain, the (proposed) special-
use domain name (see RFC6761) "default.service.arpa" is used.  The
details of how SRP registrar(s) are discovered will be specific to
the constrained network, and therefore we do not suggest a specific
mechanism here.
Paragraph (version B):
SRP requestors on constrained networks are expected to receive from
the network a list of SRP registrars with which to register.  It is
the responsibility of a Constrained-Node Network supporting SRP to
provide one or more SRP registrar addresses.  It is the
responsibility of the SRP registrar supporting a Constrained-Node
Network to handle the updates appropriately.  In some network
environments, updates may be accepted directly into a local
"default.service.arpa" zone, which has only local visibility.  In
other network environments, updates for names ending in
"default.service.arpa" may be rewritten internally to names with
broader visibility.