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

Commentary: I had hoped we could come up with something that preserves HTML 's semantics of both dd pertaining to the single dt , but this solves the ugly plain text newlines and is probably the best that can be done without larger changes in the RFC toolchain . Thanks , merged . 
 The nits of COMMENT ca n't currently be addressed easily ; looking for help at which currently blocks this .
Paragraph (version A):
In the context of an RD, a sector is a logical grouping of
endpoints.
Paragraph (version A):
The abbreviation "d=" is used for the sector in query parameters
for compatibility with deployed implementations.
Paragraph (version B):
In the context of an RD, a sector is a logical grouping of
endpoints.  The abbreviation "d=" is used for the sector in query
parameters for compatibility with deployed implementations.
Paragraph (version A):
The target of a link is the destination address (URI) of the link.
It is sometimes identified with "href=", or displayed as
"<target>".  Relative targets need resolving with respect to the
Base URI (section 5.2 of RFC3986).
Paragraph (version A):
This use of the term Target is consistent with RFC8288's use of
the term.
Paragraph (version A):
The context of a link is the source address (URI) of the link, and
describes which resource is linked to the target.  A link's
context is made explicit in serialized links as the "anchor="
attribute.
Paragraph (version A):
This use of the term Context is consistent with RFC8288's use of
the term.
Paragraph (version B):
The target of a link is the destination address (URI) of the link.
It is sometimes identified with "href=", or displayed as
"<target>".  Relative targets need resolving with respect to the
Base URI (section 5.2 of RFC3986).  This use of the term Target is
consistent with RFC8288's use of the term.
Paragraph (version B):
The context of a link is the source address (URI) of the link, and
describes which resource is linked to the target.  A link's
context is made explicit in serialized links as the "anchor="
attribute.  This use of the term Context is consistent with
RFC8288's use of the term.
Draft: draft-ietf-core-resource-directory

Commentary: The " subject " is only an example , but made more precise . Closes : 
 As in , and notes , the current wording is not clear .  provided help , just needs checking whether that really addresses all comments .
Paragraph (version A):
When certificates are used as authorization credentials, the
sector(s) and endpoint name(s) can be transported in the subject.  In
an ACE context, those are typically transported in a scope claim.
Paragraph (version B):
It is up to the concrete security policy to describe how endpoint
name and sector are transported when certificates are used.  For
example, it may describe how SubjectAltName dNSName entries are
mapped to endpoint and domain names.
Paragraph (version B):
Clarify that the mapping between endpoint names and subject
fields is up to a policy that defines reliance on names, and
give an example.
Draft: draft-ietf-core-resource-directory

Commentary: The SHOULD is not an interoperability requirement but a quality - of - implementation level recommendation ; the MUST could have been read as a requirement to have parameters there and is more describing mechanism than compatibility . See - Also :
Paragraph (version A):
An update MAY update registration parameters like lifetime, base URI
or others.  Parameters that are not being changed SHOULD NOT be
included in an update.  Adding parameters that have not changed
increases the size of the message but does not have any other
implications.  Parameters MUST be included as query parameters in an
update operation as in registration.
Paragraph (version B):
An update MAY update registration parameters like lifetime, base URI
or others.  Parameters that are not being changed should not be
included in an update.  Adding parameters that have not changed
increases the size of the message but does not have any other
implications.  Parameters are included as query parameters in an
update operation as in registration.
Draft: draft-ietf-core-resource-directory

Commentary: See - Also : Apart from pointing out the scope , this also comprehensively lists the few configuration options that are there for such an RD .
Paragraph (version A):
For this policy to be usable without configuration, clients should
not set a sector name in their registrations.  An RD can set a
default sector name for registrations accepted under this policy,
which is useful especially in a segmented setup where different
policies apply to different sectors.
Paragraph (version B):
For this policy to be usable without configuration, clients should
not set a sector name in their registrations.  An RD can set a
default sector name for registrations accepted under this policy,
which is useful especially in a segmented setup where different
policies apply to different sectors.  The configuration of such a
behavior, as well as any other configuration applicable to such an RD
(i.e. the set of recognized authorities) is out of scope for this
document.
Draft: draft-ietf-core-resource-directory

Commentary: See - Also : ( as per 2020 - 10 - 08 interim )
Paragraph (version A):
Over the last few years, mobile operators around the world have
focused on development of M2M solutions in order to expand the
business to the new type of users: machines.  The machines are
connected directly to a mobile network using an appropriate embedded
wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing
short and wide range wireless interfaces.  From the system design
point of view, the ambition is to design horizontal solutions that
can enable utilization of machines in different applications
depending on their current availability and capabilities as well as
application requirements, thus avoiding silo like solutions.  One of
the crucial enablers of such design is the ability to discover
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.
Paragraph (version B):
Over the last few years, mobile operators around the world have
focused on development of M2M solutions in order to expand the
business to the new type of users: machines.  The machines are
connected directly to a mobile network using an appropriate embedded
wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing
short and wide range wireless interfaces.  The ambition in such
systems is to build them from reusable components.  These speed up
development and deployment, and enable shared use of machines across
different applications.  One crucial component of such systems is the
discovery of 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.
Paragraph (version B):
M2M use case: Move system design paragraph towards the topic of
reusability.
Draft: draft-ietf-core-resource-directory

Commentary: See - Also :
Paragraph (version A):
Data in the RD can only be provided by the device which hosts those
data or a dedicated Commissioning Tool (CT).  These CTs are thought
to act on behalf of endpoints too constrained, or generally unable,
to present that information themselves.  No other client can modify
data in the RD.  Changes to the information in the RD do not
propagate automatically back to the web servers from where the
information originated.
Paragraph (version B):
Data in the RD can only be provided by the device which hosts those
data or a dedicated Commissioning Tool (CT).  These CTs act on behalf
of endpoints too constrained, or generally unable, to present that
information themselves.  No other client can modify data in the RD.
Changes to the information in the RD do not propagate automatically
back to the web servers from where the information originated.
Paragraph (version A):
A (re-)starting device may want to find one or more RDs for discovery
purposes.  Dependent on the operational conditions, one or more of
the techniques below apply.
Paragraph (version B):
A (re-)starting device may want to find one or more RDs before it can
discover their URIs.  Dependent on the operational conditions, one or
more of the techniques below apply.
Draft: draft-ietf-core-resource-directory

Commentary: to align with RDNSS and other similar options See - Also : That 's a large enough change that I 'd like to ask for explicit comments from the authors that worked on that section before . Éric 's comment on aligning with other options makes a lot of sense to me , it has the same overhead on the wire , does n't practically increase memory usage in implementations given they 'll convert it into whatever units their timers use anyway , and can make code more compact by reusing code . If I missed any prior considerations that led to this being 16 - bit minutes , please let me know before the cutoff Monday night , otherwise I 'll merge it .
Paragraph (version A):
RDAO: Clarify that it is an option for RAs and not other ND
messages.
Paragraph (version B):
Clarify that it is an option for RAs and not other ND messages.
Paragraph (version B):
Change Lifetime from 16-bit minutes to 32-bit seconds and swap
it with Reserved (aligning it with RDNSS which it shares other
properties as well).
Draft: draft-ietf-core-resource-directory

Commentary: See - Also : I 've gone though the rules of source address selection and think what I 'm doing here is a ) legal and b ) produces the right results ( this works is because 10.4 places fe80 and : : in the same label , and the the limited precedence for fe80 puts them out of the game in the modified rule 8) , but I 'll add this to the focus points of the 6man mail .
Paragraph (version A):
When answering a multicast request directed at a link-local group,
the RD may want to respond from a routable address; this makes it
easier for registrants to use one of their own routable addresses for
registration.
Paragraph (version B):
When answering a multicast request directed at a link-local group,
the RD may want to respond from a routable address; this makes it
easier for registrants to use one of their own routable addresses for
registration.  When RFC6724 is used for source address selection,
this can be achieved by applying the changes of its Section 10.4,
picking public addresses in its Section 5 Rule 7, and superseding
rule 8 with preferring the source address's precedence.
Paragraph (version A):
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.
Paragraph (version B):
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: See - Also :
Paragraph (version A):
Endpoint authorization needs to be checked on registration and
registration resource operations independently of whether there are
configured requirements on the credentials for a given endpoint name
(secure-ep) or whether arbitrary names are accepted (arbitrary-ep).
Paragraph (version B):
Endpoint authorization needs to be checked on registration and
registration resource operations independently of whether there are
configured requirements on the credentials for a given endpoint name
(and sector; secure-ep) or whether arbitrary names are accepted
(arbitrary-ep).
Draft: draft-ietf-core-resource-directory

Commentary: See - Also :
Paragraph (version A):
When the (ep, d) value pair of the registration-request is equal
to an existing registration, the content and parameters of the
existing registration are replaced with the content of the
registration request.
Paragraph (version B):
When the (ep, d) value pair of the registration-request is equal
to an existing registration, the content and parameters of the
existing registration are replaced with the content of the
registration request.  Like the later changes to registration
resources, security policies (policies) usually require such
requests to come from the same device.
Draft: draft-ietf-core-resource-directory

Commentary: Just one so far , but AFAIR there 'll be a few more to push on this . See - Also :
Paragraph (version A):
Discovery of the RD registration URI path is performed by sending
either a multicast or unicast GET request to "/.well-known/core" and
including a Resource Type (rt) parameter RFC6690 with the value
"core.rd" in the query string.  Likewise, a Resource Type parameter
value of "core.rd-lookup*" is used to discover the URIs for RD Lookup
operations, core.rd* is used to discover all URI paths for RD
operations.  Upon success, the response will contain a payload with a
link format entry for each RD function discovered, indicating the URI
of the RD function returned and the corresponding Resource Type.
When performing multicast discovery, the multicast IP address used
will depend on the scope required and the multicast capabilities of
the network (see mc-registration).
Paragraph (version B):
Discovery of the RD registration URI is performed by sending either a
multicast or unicast GET request to "/.well-known/core" and including
a Resource Type (rt) parameter RFC6690 with the value "core.rd" in
the query string.  Likewise, a Resource Type parameter value of
"core.rd-lookup*" is used to discover the URIs for RD Lookup
operations, core.rd* is used to discover all URIs for RD operations.
Upon success, the response will contain a payload with a link format
entry for each RD function discovered, indicating the URI of the RD
function returned and the corresponding Resource Type.  When
performing multicast discovery, the multicast IP address used will
depend on the scope required and the multicast capabilities of the
network (see mc-registration).
Paragraph (version A):
The sequence of fetching the registration content before sending a
successful response was chosen to make responses reliable, and the
caching item was chosen to still allow very constrained registrants.
Registrants MUST be able to serve a GET request to "/.well-known/
core" after having requested registration.  Constrained devices MAY
regard the initial request as temporarily failed when they need RAM
occupied by their own request to serve the RD's GET, and retry later
when the RD already has a cached representation of their discovery
resources.  Then, the RD can reply immediately and the registrant can
receive the response.
Paragraph (version B):
The sequence of fetching the registration content before sending a
successful response was chosen to make responses reliable, and the
point about caching was chosen to still allow very constrained
registrants.  Registrants MUST be able to serve a GET request to
"/.well-known/core" after having requested registration.  Constrained
devices MAY regard the initial request as temporarily failed when
they need RAM occupied by their own request to serve the RD's GET,
and retry later when the RD already has a cached representation of
their discovery resources.  Then, the RD can reply immediately and
the registrant can receive the response.
Draft: draft-ietf-core-resource-directory

Commentary: The " MUST " was non - actionable , while the " should " would be ; switching normativity . See - Also :
Paragraph (version A):
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 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 SHOULD fall back to link-format
when receiving 4.15 (Unsupported Content-Format; 415 in HTTP).
Paragraph (version B):
Error handling: Place a SHOULD around the likely cases, and make
the previous "MUST to the best of their capabilities" a "must".
Draft: draft-ietf-core-resource-directory

Commentary: The previous sentence was barely readable . Details were removed as they are obvious ( multicast ) or already mentioned in the respective section ( simple registration ) .
Paragraph (version A):
This and the following sections define the required set of REST
interfaces between an RD, endpoints and lookup clients.  Although the
examples throughout these sections assume the use of CoAP RFC7252,
these REST interfaces can also be realized using HTTP RFC7230.  Only
multicast discovery operations are not possible on HTTP, and Simple
Registration cannot be executed as the base attribute (which is
mandatory for HTTP) cannot be used there.  In all definitions in
these sections, both CoAP response codes (with dot notation) and HTTP
response codes (without dot notation) are shown.  An RD implementing
this specification MUST support the discovery, registration, update,
lookup, and removal interfaces.
Paragraph (version B):
This and the following sections define the required set of REST
interfaces between an RD, endpoints and lookup clients.  Although the
examples throughout these sections assume the use of CoAP RFC7252,
these REST interfaces can also be realized using HTTP RFC7230.  The
multicast discovery and simple registration operations are exceptions
to that, as they rely on mechanisms unavailable in HTTP.  In all
definitions in these sections, both CoAP response codes (with dot
notation) and HTTP response codes (without dot notation) are shown.
An RD implementing this specification MUST support the discovery,
registration, update, lookup, and removal interfaces.
Draft: draft-ietf-core-resource-directory

Commentary: This also answers the repeated questions that were asked about conflicts between recognized and given ep names , and brings the wording in line with the more consistent application of the security glossary .
Paragraph (version A):
Endpoint name (mostly mandatory).  The endpoint name is an
identifier that MUST be unique within a sector.  As the
endpoint name is a Unicode string, it is encoded in UTF-8 (and
possibly pct-encoded) during variable expansion (see RFC6570
Section 3.2.1).  The endpoint name MUST NOT contain any
character in the inclusive ranges 0-31 or 127-159.  The maximum
length of this parameter is 63 UTF-8 encoded bytes.  If the RD
is configured to recognize the endpoint (e.g. based on its
security context), the RD assigns an endpoint name based on a
set of configuration parameter values.
Paragraph (version A):
Sector (optional).  The sector to which this endpoint belongs.
When this parameter is not present, the RD MAY associate the
endpoint with a configured default sector or leave it empty.
The sector is encoded like the ep parameter, and is limited to
63 UTF-8 encoded bytes as well.  The endpoint name and sector
name are not set when one or both are set in an accompanying
authorization token.
Paragraph (version B):
Endpoint name (mostly mandatory).  The endpoint name is an
identifier that MUST be unique within a sector.  As the
endpoint name is a Unicode string, it is encoded in UTF-8 (and
possibly pct-encoded) during variable expansion (see RFC6570
Section 3.2.1).  The endpoint name MUST NOT contain any
character in the inclusive ranges 0-31 or 127-159.  The maximum
length of this parameter is 63 UTF-8 encoded bytes.  If the RD
is configured to recognize the endpoint to be authorized to use
exactly one endpoint name, the RD assigns that name.  In that
case, giving the endpoint name becomes optional for the client;
if the client gives any other endpoint name, it is not
authorized to perform the registration.
Paragraph (version B):
Sector (optional).  The sector to which this endpoint belongs.
When this parameter is not present, the RD MAY associate the
endpoint with a configured default sector (possibly based on
the endpoint's authorization) or leave it empty.  The sector is
encoded like the ep parameter, and is limited to 63 UTF-8
encoded bytes as well.
Paragraph (version B):
Registration: Wording around "mostly mandatory" has been improved,
conflicts clarified and sector default selection adjusted.
Draft: draft-ietf-core-resource-directory

Commentary: See - Also :
Paragraph (version A):
An RD MAY make the information submitted to it available to further
directories, if it can ensure that a loop does not form.  The
protocol used between directories to ensure loop-free operation is
outside the scope of this document.
Paragraph (version B):
An RD MAY make the information submitted to it available to further
directories (subject to security policies on link confidentiality),
if it can ensure that a loop does not form.  The protocol used
between directories to ensure loop-free operation is outside the
scope of this document.
Paragraph (version B):
RD replication: Point out that security policies may limit that.
Draft: draft-ietf-core-resource-directory

Commentary: Authentication alone is never sufficient ; with the First - Come - Fist - Remembered policy of , it should be easier to see how this is still authorization . See - Also :
Paragraph (version A):
Endpoint authentication needs to be checked independently of whether
there are configured requirements on the credentials for a given
endpoint name (secure-ep) or whether arbitrary names are accepted
(arbitrary-ep).
Paragraph (version B):
Endpoint authorization needs to be checked on registration and
registration resource operations independently of whether there are
configured requirements on the credentials for a given endpoint name
(secure-ep) or whether arbitrary names are accepted (arbitrary-ep).
Draft: draft-ietf-core-resource-directory

Commentary: The generated address failed to follow the guidance of RFC 3307 and set the first bit of the Group ID . 
 Since the example prefix is 2001 :  , I would assume the plen field is also set to 32 , so we would get : ff35:20:2001 : db8::8000 :x Or is there a reason here to use plen=0x30 ( 48 ) bits ? 
 Throughout the examples , we use the third word to distinguish between separate logically distinct examples ( 2001 : db8:1 : : .. 2001 : db8:4 : :) , so it seemed logical to take a /48 for this example as well . ( Although in keeping with the other appendix that uses 2001 : db8 : f0 : : , something like 2001 : db8 : e0::/48 and thus ff35:30:2001 : db8 : e0::1 would enhance consistency ) . 
 Ok , thanks - I see - so in example nr 4 the prefix 2001 :  is used , then the mcast address would become ff35:30:2001 : db8:4::8000 :x right ? If the ' : 4 ' is omitted it looks like a prefix 2001 : db8/32 is being used . 
 The last commit on this series ( ) now has something in the original addresses 3rd word ( 2001 : db8 : f1::/48 ) to make the choice of 30 in the prefix length more understandable , and for consistency .
Paragraph (version B):
Multicast addresses in the examples were changed from
ff35:30:2001:db8::x to ff35:30:2001:db8:f1::8000:x; the 8000 is
to follow RFC 3307, and the f1 is for consistency with all the
other example addresses where 2001:db8::/32 is subnetted to
2001:db8:x::/48 by groups of internally consistent examples.