jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-resource-directory

Commentary: We were asked about the term in  's comments , and nobody could explain its relevance to the RD ; removing it . See - Also :
Paragraph (version A):
In many IoT applications, direct discovery of resources is not
practical due to sleeping nodes, disperse networks, or networks where
multicast traffic is inefficient.  These problems can be solved by
employing an entity called a Resource Directory (RD), which contains
information about resources held on other servers, allowing lookups
to be performed for those resources.  The input to an RD is composed
of links and the output is composed of links constructed from the
information stored in the RD.  This document specifies the web
interfaces that an RD supports for web servers to discover the RD and
to register, maintain, lookup and remove information on resources.
Furthermore, new target attributes useful in conjunction with an RD
are defined.
Paragraph (version B):
In many IoT applications, direct discovery of resources is not
practical due to sleeping nodes, or networks where multicast traffic
is inefficient.  These problems can be solved by employing an entity
called a Resource Directory (RD), which contains information about
resources held on other servers, allowing lookups to be performed for
those resources.  The input to an RD is composed of links and the
output is composed of links constructed from the information stored
in the RD.  This document specifies the web interfaces that an RD
supports for web servers to discover the RD and to register,
maintain, lookup and remove information on resources.  Furthermore,
new target attributes useful in conjunction with an RD are defined.
Paragraph (version A):
sleeping nodes, disperse networks, or networks where multicast
traffic is inefficient.  These problems can be solved by employing an
entity called a Resource Directory (RD), which contains information
about resources held on other servers, allowing lookups to be
performed for those resources.
Paragraph (version B):
sleeping nodes, or networks where multicast traffic is inefficient.
These problems can be solved by employing an entity called a Resource
Directory (RD), which contains information about resources held on
other servers, allowing lookups to be performed for those resources.
Draft: draft-ietf-core-resource-directory

Commentary: These fix some missing parts from , and address  's SLAAC comments as well as their fall - out on the CTs " knowing " the RD .
Paragraph (version B):
At the moment of installation, the network under installation is not
necessarily connected to the DNS infrastructure.  Therefore, SLAAC
IPv6 addresses are assigned to CT, RD, luminaries and the sensor.
The addresses shown in interface-S below stand in for these in the
following examples.
Paragraph (version A):
It is assumed that the CT knows the RD's address, and has performed
URI discovery on it that returned a response like the one in the
discovery example.
Paragraph (version B):
It is assumed that the CT has performed RD discovery and has received
a response like the one in the discovery example.
Draft: draft-ietf-core-resource-directory

Commentary: This is a result of the discussion following Roman 's " But why expose them at all if they 're not going to be accessible ? " comment .
Paragraph (version B):
The Registration Resource path is visible to any client that is
allowed endpoint lookup, and can be extracted by resource lookup
clients as well.  The same goes for registration attributes that are
shown as target attributes or lookup attributes.  The RD needs to
consider this in the choice of Registration Resource paths, and
administrators or endpoint in their choice of attributes.
Paragraph (version B):
Add note about information in Registration Resource path.
Draft: draft-ietf-core-resource-directory

Commentary: ... and a few other cases of example errors and use of unregistered names .
Paragraph (version A):
A link matches a search criterion if it has an attribute of the same
name and the same value, allowing for a trailing "*" wildcard
operator as in Section 4.1 of RFC6690.  Attributes that are defined
as "link-type" match if the search value matches any of their values
(see Section 4.1 of RFC6690; e.g. "?if=core.s" matches ";if="abc
core.s";").  A resource link also matches a search criterion if its
endpoint would match the criterion, and vice versa, an endpoint link
matches a search criterion if any of its resource links matches it.
Paragraph (version B):
A link matches a search criterion if it has an attribute of the same
name and the same value, allowing for a trailing "*" wildcard
operator as in Section 4.1 of RFC6690.  Attributes that are defined
as "link-type" match if the search value matches any of their values
(see Section 4.1 of RFC6690; e.g. "?if=tag:example.net,2020:sensor"
matches ";if="example.regname tag:example.net,2020:sensor";").  A
resource link also matches a search criterion if its endpoint would
match the criterion, and vice versa, an endpoint link matches a
search criterion if any of its resource links matches it.
Paragraph (version A):
The presence sensor can learn the presence of groups that support
resources with rt=light in its own sector by sending the same
request, as used by the luminary.  The presence sensor learns the
multicast address to use for sending messages to the luminaries.
Paragraph (version B):
The presence sensor can learn the presence of groups that support
resources with rt=tag:example.com,2020:light in its own sector by
sending the same request, as used by the luminary.  The presence
sensor learns the multicast address to use for sending messages to
the luminaries.
Draft: draft-ietf-core-resource-directory

Commentary: … om authorized RDs This makes the paragraph that described that for a particular case largely redundant . The lines about that special case that described special considerations for ACE anticipate a mechanism that is not finished yet , and were removed .
Paragraph (version B):
Security policies are set by configuration of the RD, or by choice of
the implementation.  Lookup clients (and, where relevant, endpoints)
can only trust an RD to uphold them if it is authenticated, and
authorized to serve as an RD according to the application's
requirements.
Paragraph (version A):
In those situations, the registrant needs to be careful to
authenticate the RD as well.  The registrant needs to know in advance
which AS, audience and scope values indicate an RD it may trust for
this purpose, and cannot rely on the RD to provide AS address and
token details.  (In contrast, in the other scenarios it may try to
register, and follow the pointers the RD gives it as to which
credentials it needs to provide in order to perform its
registration).
Paragraph (version B):
In this case, the endpoint (and not the lookup clients) needs to be
careful to check the RD's authorization.
Paragraph (version B):
Clarify that with all security policies, clients must verify
the authorization of the RD.
Paragraph (version B):
Remove speculation about how in detail ACE scopes are obtained.
Draft: draft-ietf-core-resource-directory

Commentary: See - Also :
Paragraph (version A):
Home and commercial building automation systems can benefit from the
use of M2M web services.  The discovery requirements of these
applications are demanding.  Home automation usually relies on run-
time discovery to commission the system, whereas in building
automation a combination of professional commissioning and run-time
discovery is used.  Both home and building automation involve peer-
to-peer interactions between endpoints, and involve battery-powered
sleeping devices.
Paragraph (version B):
Home and commercial building automation systems can benefit from the
use of M2M web services.  The discovery requirements of these
applications are demanding.  Home automation usually relies on run-
time discovery to commission the system, whereas in building
automation a combination of professional commissioning and run-time
discovery is used.  Both home and building automation involve peer-
to-peer interactions between endpoints, and involve battery-powered
sleeping devices.  Both can use the common RD infrastructure to
establish device interactions efficiently, but can pick security
policies suitable for their needs.
Paragraph (version A):
Two phases can be discerned for a network servicing the system: (1)
installation and (2) operation.  During the operational phase, the
network is connected to the Internet with a Border router (6LBR) and
the nodes connected to the network can use the Internet services that
are provided by the Internet Provider or the network administrator.
During the installation phase, the network is completely stand-alone,
no 6LBR is connected, and the network only supports the IP
communication between the connected nodes.  The installation phase is
usually followed by the operational phase.
Paragraph (version B):
Two phases can be discerned for a network servicing the system: (1)
installation and (2) operation.  During the operational phase, the
network is connected to the Internet with a Border router (6LBR) and
the nodes connected to the network can use the Internet services that
are provided by the Internet Provider or the network administrator.
During the installation phase, the network is completely stand-alone,
no 6LBR is connected, and the network only supports the IP
communication between the connected nodes.  The installation phase is
usually followed by the operational phase.  As an RD's operations
work without hard dependencies on names or addresses, it can be used
for discovery across both phases.
Draft: draft-ietf-core-resource-directory

Commentary: See - Also : This is quite literally from my notes on A bit of uncertainty remains whether this change should be two - sided . Should the line above say " When SLAAC is in use , " ( or " When ND is in use , " ? ) as well ? Can RA options be used in presence of DHCP or static address configuration ? 
 Updated to a more plain and not SLAAC related statement about the  as per last interim .
Paragraph (version A):
If the address configuration of the network is performed via
SLAAC, this is provided by the RDAO option rdao.
Paragraph (version A):
If the address configuration of the network is performed via DHCP,
this could be provided via a DHCP option (no such option is
defined at the time of writing).
Paragraph (version B):
The IPv6 Neighbor Discovery option RDAO rdao can do that.
Paragraph (version B):
When DHCP is in use, this could be provided via a DHCP option (no
such option is defined at the time of writing).
Paragraph (version B):
RD discovery: Drop the previously stated assumption that RDAO and
any DHCP options would only be used together with SLAAC and DHCP
for address configuration, respectivly.
Draft: draft-ietf-core-resource-directory

Commentary: This puts the  in the same messages as RDNSS option ( see RFC8106 ) See - Also : 
 All addressed , sorry for the bugs .
Paragraph (version A):
The Resource Directory Address Option (RDAO) using IPv6 Neighbor
Discovery (ND) carries information about the address of the RD.  This
information is needed when endpoints cannot discover the RD with a
link-local or realm-local scope multicast address, for instance
because the endpoint and the RD are separated by a Border Router
(6LBR).  In many circumstances the availability of DHCP cannot be
guaranteed either during commissioning of the network.  The presence
and the use of the RD is essential during commissioning.
Paragraph (version B):
The Resource Directory Address Option (RDAO) carries information
about the address of the RD in RAs (Router Advertisements) of IPv6
Neighbor Discovery (ND), similar to how RDNSS options RFC8106 are
sent.  This information is needed when endpoints cannot discover the
RD with a link-local or realm-local scope multicast address, for
instance because the endpoint and the RD are separated by a Border
Router (6LBR).  In many circumstances the availability of DHCP cannot
be guaranteed either during commissioning of the network.  The
presence and the use of the RD is essential during commissioning.
Paragraph (version B):
RDAO: Clarify that it is an option for RAs and not other ND
messages.
Draft: draft-ietf-core-resource-directory

Commentary: No deployed implementations of simple registration are known that ca n't switch over easily . As per
Paragraph (version A):
The registrant-ep sends (and regularly refreshes with) a POST
request to the "/.well-known/core" URI of the directory server of
choice.  The body of the POST request is empty, and triggers the
resource directory server to perform GET requests at the
requesting registrant-ep's /.well-known/core to obtain the link-
format payload to register.
Paragraph (version B):
The registrant-ep sends (and regularly refreshes with) a POST
request to the "/.well-known/rd" URI of the directory server of
choice.  The body of the POST request is empty, and triggers the
resource directory server to perform GET requests at the
requesting registrant-ep's /.well-known/core to obtain the link-
format payload to register.
Paragraph (version A):
URI Template Variables are as they are for registration in
registration.  The base attribute is not accepted to keep the
registration interface simple; that rules out registration over CoAP-
over-TCP or HTTP that would need to specify one.
Paragraph (version B):
URI Template Variables are as they are for registration in
registration.  The base attribute is not accepted to keep the
registration interface simple; that rules out registration over CoAP-
over-TCP or HTTP that would need to specify one.  For some time
during this document's development, the URI template "/.well-known/
core{?ep,...}" has been in use instead.
Paragraph (version A):
IANA is asked to extend the reference for the "core" URI suffix in
the "Well-Known URIs" registry to reference this document next to
RFC6690, as this defines the resource's behavior for POST requests.
Paragraph (version B):
IANA is asked to permanently register the URI suffix "rd" in the
"Well-Known URIs" registry.  The change controller is the IETF, this
document is the reference.
Paragraph (version B):
Simple registration: Rather than coopting POSTs to /.well-known/
core, a new resource /.well-known/rd is registered.  A historical
note in the text documents the change.
Draft: draft-ietf-core-resource-directory

Commentary: Will still grow while I 'm working through the latest discusses / comments ; these are things not directly mentioned there but small errors that became obvious when working through the document to prepare responses and/or when preparing patches to address the issues .
Paragraph (version A):
If the registration fails in any way, including "Not Found" and
request timeouts, or if the time indicated in a Service Unavailable
Max-Age/Retry-After exceeds the remaining lifetime, the registering
endpoint SHOULD attempt registration again.
Paragraph (version B):
If the registration update fails in any way, including "Not Found"
and request timeouts, or if the time indicated in a Service
Unavailable Max-Age/Retry-After exceeds the remaining lifetime, the
registering endpoint SHOULD attempt registration again.
Draft: draft-ietf-core-resource-directory

Commentary: This is the WIP work to go from " we explain how exactly to do RD security " ( and get the details wrong ) to " we outline what needs to be considered but it 's really up to the application " talked about in 
 ( as no single commit has this in its metadata ) 
 From  's Genart review : It 's tempting to say " squared number of maximum endpoints times security " here . But really what 's the error mode here ? If a registrant happens to pick something duplicate , it 'll get a 4.03 Forbidden . It could then try a different value , but as the RD only " can " ( and not MUST ) check for collisions , it might have allowed someone else to take our registrant 's ep name , and if the registrant was previously successful with that name , it ca n't change it any more as the RD would refuse it based on the MUST . We can make both MUSTs ( the RD already needs to keep a list of used certificates already anyway , it only adds a requirement to use it ( possibly via a new index ) ) , but then still , what 's a device to do if it receives a 4.03 ? Change its ep name as this is obviously not the same RD where it had worked before ? Just fail ? Can or must a device change its name if it is fashioned with a new certificate ? Does it need to know the RD 's criteria for equivalence of certificates to decide that ? 
 With the text of this is easier now ( as the error mode in " and require the same properties " is implied to be 4.01 ) ; text to follow .
Paragraph (version B):
Rather than prescribing which data in the RD _is_ authenticated
(and how), it now describes what applications built on an RD _can_
choose to authenticate, show possibilities on how to do it and
outline what it means for clients.
Paragraph (version B):
This addresses Russ' Genart review points on details in the text
in a rather broad fashion.  That is because the discussion on the
topic inside the WG showed that that text on security has been
driven more review-by-review than by the an architectural plan of
the authors and WG.
Draft: draft-ietf-core-resource-directory

Commentary: It appears I 've missed some of  's remarks responding to the changes made after his initial review ( < mid:-7d81 - 4c89 - ad81- , 2019 - 11 - 20 ) . This contains fixes for the points he still wanted changed / suggested after my original response to his review .
Paragraph (version A):
This section describes how the registering endpoint can maintain the
registrations that it created.  The registering endpoint can be the
registrant-ep or the CT.  An endpoint SHOULD NOT use this interface
for registrations that it did not create.  The registrations are
resources of the RD.
Paragraph (version B):
This section describes how the registering endpoint can maintain the
registrations that it created.  The registering endpoint can be the
registrant-ep or the CT.  The registrations are resources of the RD.
Paragraph (version B):
An endpoint should not use this interface for registrations that it
did not create.  This is usually enforced by security policies, which
in general require equivalent credentials for creation of and
operations on a registration.
Paragraph (version A):
validity requirements if any,
Paragraph (version B):
syntax and validity requirements if any,
Draft: draft-ietf-core-resource-directory

Commentary: Something around " whether many registrations are expected over time " is supposed to be said according to BCP26 , but it seems this belongs in the shepherd write - up , where it is now being . To be merged right away .
Paragraph (version A):
endpoint property or the RFC6690 target attribute).  It is expected
that the registry will receive between 5 and 50 registrations in
total over the next years.
Paragraph (version B):
endpoint property or the RFC6690 target attribute).
Draft: draft-ietf-core-resource-directory

Commentary: as suggested by  in the genart review : did I get the intention of the expression right ? 
 LGTM
Paragraph (version A):
resources (machines -- endpoints) capable of providing required
information at a given time or acting on instructions from the end
users.
Paragraph (version B):
resources (and thus the endpoints they are hosted on) capable of
providing required information at a given time or acting on
instructions from the end users.
Draft: draft-ietf-core-resource-directory

Commentary: This is to address  's genart comment : 
 The reflowing commit went here by accident ( wrong branch / did n't check on upload ) . I 'm pushing it to master , hoping this makes the PR 's diff show only what 's intended .
Paragraph (version A):
A web entity that stores information about web resources and
implements the REST interfaces defined in this specification for
registration and lookup of those resources.
Paragraph (version B):
A web entity that stores information about web resources and
implements the REST interfaces defined in this specification for
discovery, for the creation, the maintenance and the removal of
registrations, and for lookup of the registered resources.
Draft: draft-ietf-core-resource-directory

Commentary: All expected to be uncontroversial ; to be merged soon . 
 Commit should have been part of this as well , and is already applied to master .
Paragraph (version A):
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
RFC2119.  The term "byte" is used in its now customary sense as a
synonym for "octet".
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.
Paragraph (version B):
The term "byte" is used in its now customary sense as a synonym for
"octet".
Paragraph (version A):
REST clients (registrant-EPs / CTs, lookup clients, RD servers during
simple registrations) MUST be prepared to receive any unsuccessful
code and act upon it according to its definition, options and/or
payload to the best of their capabilities, falling back to failing
the operation if recovery is not possible.  In particular, they
should retry the request upon 5.03 (Service Unavailable; 503 in HTTP)
according to the Max-Age (Retry-After in HTTP) option, and fall back
to link-format when receiving 4.15 (Unsupported Content-Format; 415
in HTTP).
Paragraph (version B):
REST clients (registrant-EPs and CTs during registration and
maintenance, lookup clients, RD servers during simple registrations)
MUST be prepared to receive any unsuccessful code and act upon it
according to its definition, options and/or payload to the best of
their capabilities, falling back to failing the operation if recovery
is not possible.  In particular, they should retry the request upon
(Retry-After in HTTP) option, and fall back to link-format when
receiving 4.15 (Unsupported Content-Format; 415 in HTTP).
Paragraph (version A):
An Endpoint (name, sector) pair is unique within the et of endpoints
registered by the RD.  An Endpoint MUST NOT be identified by its
protocol, port or IP address as these may change over the lifetime of
an Endpoint.
Paragraph (version B):
An Endpoint (name, sector) pair is unique within the set of endpoints
registered by the RD.  An Endpoint MUST NOT be identified by its
protocol, port or IP address as these may change over the lifetime of
an Endpoint.
Paragraph (version A):
IPv4 - "all CoRE resource directories" address MCD2 (suggestion:
224.0.1.189), from the "IPv4 Multicast Address Space Registry".  As
the address is used for discovery that may span beyond a single
network, it has come from the Internetwork Control Block (224.0.1.x,
RFC 5771).
Paragraph (version B):
IPv4 - "all CoRE resource directories" address MCD2 (suggestion:
224.0.1.189), from the "IPv4 Multicast Address Space Registry".  As
the address is used for discovery that may span beyond a single
network, it has come from the Internetwork Control Block (224.0.1.x)
RFC5771.