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

Commentary: Those were in the original proposals during IETF / on the list , but not in the text yet . Depends on for practical merging purposes .
Paragraph (version A):
A resource directory can advertise its presence in DNS-SD using the
service name "_core-rd._udp" defined in this document.
Paragraph (version A):
The use of that service names implies that CoAP-over-UDP is used.
The SRV record points the client to a host name and port to use as a
starting point for the URI discovery steps of discovery.
Paragraph (version B):
A resource directory can advertise its presence in DNS-SD using the
service name "_core-rd._udp" (for CoAP), "_core-rd-dtls._udp" (for
CoAP over UDP), "_core-rd._tcp" (for CoAP over TCP) or "_core-rd-
tls._tcp" (for CoAP over TLS)` defined in this document.  (For the
WebSocket transports of CoAP, no service is defined as DNS-SD is
typically unavailable in environments where CoAP over WebSockets).
Paragraph (version B):
The selection of the service indicates the protocol used, and the SRV
record points the client to a host name and port to use as a starting
point for the URI discovery steps of discovery.
Paragraph (version B):
All in common have this document as their reference.
Draft: draft-ietf-core-resource-directory

Commentary: This was missed in the original pull of mechanism from RD - DNS - SD into here ; its wording was brought in line with the other recommendations ( " In case X , Y is recommended " ) and now goes to the internal section rather than the external document . Will be merged on Monday before submission unless spoken against .
Paragraph (version A):
The use of DNS facilities is described in I-D.ietf-core-rd-dns-sd.
Paragraph (version B):
In networks managed using DNS-SD, the use of DNS-SD for discovery
as described in rd-using-dnssd is recommended.
Draft: draft-ietf-core-resource-directory

Commentary: Reviewing the discussion in [ 1 ] and [ 2 ] , my original patch seems to have overshot . [ 1 ] : [ 2 ] : 
 Much more sensibleless ambitious and more correct .
Mailing list commentary: The outcome in discussion in the Friday meeting was that the resource - directory specification should simply define the small number of DNS - SD service types that are needed for resource directory discovery . We said details were to be taken to the list , which I want to initiate now . In the meeting , I gave the three examples core - , core - rd - , and core - — noting that while core - rd is a proper RD service type , core - rd - tls is n’t . To cover the six transports we have for CoAP today ( coap , coaps , coap+tcp , coaps+tcp , coap+ws , coaps+ws ) , we would need four service types on top of tcp and could use two of them over udp ? ,
Paragraph (version A):
A resource directory can advertise its resources in DNS-SD using the
service names "_rd._udp", "_rd-lookup-res._udp" and "_rd_lookup-
ep._udp" defined in this document for its Directory Resource, its
resource lookup and endpoint lookup resource, respectively.  A "path"
key SHOULD be set, and indicate the path on the server (starting with
a slash).
Paragraph (version A):
The use of those service names implies that CoAP-over-UDP is used.
With that information, the host name and port given in the SRV record
and the path from the TXT record, the discovering client can perform
RD and URI discovery in a single step.
Paragraph (version A):
When the "path" key is absent, the client MUST discovery the URIs on
the server according to discovery.
Paragraph (version A):
This section is a concrete application of the more generic mechanism
that is being developed as I-D.ietf-core-rd-dns-sd.
Paragraph (version B):
A resource directory can advertise its presence in DNS-SD using the
service name "_core-rd._udp" defined in this document.
Paragraph (version B):
The use of that service names implies that CoAP-over-UDP is used.
The SRV record points the client to a host name and port to use as a
starting point for the URI discovery steps of discovery.
Paragraph (version B):
This section is a simplified concrete application of the more generic
mechanism specified in I-D.ietf-core-rd-dns-sd.
Draft: draft-ietf-core-resource-directory

Commentary: Closes : 
 In the lookup filtering description , we talk about how href can be queried for ( that it only applies in the URI form ) , but say nothing about anchor ( to which the same applies in principle , with slightly different statements about application to the endpoints ) . Thanks  for pointing that out . As  contains a lookup example for ? anchor= , we may want to add one here as well .
Paragraph (version A):
Note that "href" is a valid search criterion and matches target
references.  Like all search criteria, on a resource lookup it can
match the target reference of the resource link itself, but also the
registration resource of the endpoint that registered it.  Queries
for resource link targets MUST be in URI form (i.e. not relative
references) and are matched against a resolved link target.  Queries
for endpoints SHOULD be expressed in path-absolute form if possible
and MUST be expressed in URI form otherwise; the RD SHOULD recognize
either.
Paragraph (version B):
Note that "href" is a valid search criterion and matches target
references.  Like all search criteria, on a resource lookup it can
match the target reference of the resource link itself, but also the
registration resource of the endpoint that registered it.  Queries
for resource link targets MUST be in URI form (i.e. not relative
references) and are matched against a resolved link target.  Queries
for endpoints SHOULD be expressed in path-absolute form if possible
and MUST be expressed in URI form otherwise; the RD SHOULD recognize
either.  The "anchor" attribute is usable for resource lookups, and,
if queried, MUST be for in URI form as well.
Draft: draft-ietf-core-resource-directory

Commentary: Not setting to 0 as this would require further explanation on what it means , and also leaves the 0 value usable as a sentinel in implementations for " no lt given " ( although the same , with -1 , could be achieved by reducing the range at the top end ) . Closes : 
 Feedback from LwM2 M : Their testing takes long with the arbitrary limit of 60s . We found no technical reasons to keep it there , and it should probably be abolished in favor of the natural lower limit of 1 second .
Paragraph (version A):
Lifetime (optional).  Lifetime of the registration in seconds.
Range of 60-4294967295.  If no lifetime is included in the
initial registration, a default value of 90000 (25 hours)
SHOULD be assumed.
Paragraph (version B):
Lifetime (optional).  Lifetime of the registration in seconds.
Range of 1-4294967295.  If no lifetime is included in the
initial registration, a default value of 90000 (25 hours)
SHOULD be assumed.
Paragraph (version A):
Lifetime (optional).  Lifetime of the registration in seconds.
Range of 60-4294967295.  If no lifetime is included, the
previous last lifetime set on a previous update or the original
registration (falling back to 90000) SHOULD be used.
Paragraph (version B):
Lifetime (optional).  Lifetime of the registration in seconds.
Range of 1-4294967295.  If no lifetime is included, the
previous last lifetime set on a previous update or the original
registration (falling back to 90000) SHOULD be used.
Draft: draft-ietf-core-resource-directory

Commentary: Closes : 
 Alexeys ' review mentions IANA considerations for .well - known/ , and while we do n't have any from the sentence he referred to , we are adding to behavior of .well - known / core in the simple registration -- grabbing its POST behavior . Do we need to update the registration entry for that ( or update 6690 for its registration ) ?
Paragraph (version B):
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.
Draft: draft-ietf-core-resource-directory

Commentary: Jaime provided a detailled review , and  provided an interesting use case that helped shape the base parameter details Closes : Disposition : Merge with next batch 
 The Acknowledgements section has not been updated for quite a while ; I 'll update it with the reviewers before releasing -20 .
Paragraph (version A):
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders
Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,
Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have
provided helpful comments, discussions and ideas to improve and shape
this document.  Zach would also like to thank his colleagues from the
EU FP7 SENSEI project, where many of the resource directory concepts
were originally developed.
Paragraph (version B):
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders
Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,
Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias
Kovatsch and Jaime Jimenez have provided helpful comments,
discussions and ideas to improve and shape this document.  Zach would
also like to thank his colleagues from the EU FP7 SENSEI project,
where many of the resource directory concepts were originally
developed.
Draft: draft-ietf-core-resource-directory

Commentary: See . might be worth reading in patch form , for the rest the preview at https://core- is probably better suited for reviewing . 
 : He has a point ; if we 're to change that , it could be General operation ( would get the general text of what was 5 . Resource Directory ) 4.1 ( was 4 ) Finding a Resource Directory .. Resource Directory Address Option ( RDAO ) 4.2 ( was 5.1 ) Payload Content Formats 4.3 ( was 5.2 ) URI Discovery ( was 5.3 . ) Registration 5.1 ( was 5.3.1 ) Simple Registration 5.2 ( was 5.3.2 ) Third - party registration 5.3 ( was 5.4 ) Operations on the Registration Resource .. Registration Update ..   .. Further operations ( as it was )   .. Resource lookup .. Lookup filtering .. Resource lookup examples  or nay ? 
 Puts lookup and regitration at same level . That is good . Title of 4 : It is a bit of a hodge - podge , RD discovery and syntax ? 
 Readability is improved .
Paragraph (version A):
This and the following sections define the required set of REST
interfaces between a Resource Directory (RD), endpoints and lookup
clients.  Although the examples throughout theses sections assume the
use of CoAP RFC7252, these REST interfaces can also be realized using
HTTP RFC7230.  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 a Resource Directory (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.  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: That went fast :-)
Paragraph (version A):
When answering a link-local multicast request, the RD may want to
respond with a routable one; thus, it makes it easier for registrants
to use an own routable address for registration.
Paragraph (version B):
When answering a multicast request directed at a link-local address,
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 A):
The Resource Directory Address Option (RDAO) using IPv6 Neighbor
Discovery (ND) carries information about the address of the Resource
Directory (RD).  This information is needed when endpoints cannot
discover the Resource Directory with a link-local or realm-local
scope multicast address 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) using IPv6 Neighbor
Discovery (ND) carries information about the address of the Resource
Directory (RD).  This information is needed when endpoints cannot
discover the Resource Directory 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 A):
If Base URI contains a link-local IP literal, it MUST NOT
contain a Zone Identifier, and MUST be local to the link on
which the registration request is received.
Paragraph (version B):
If the Base URI contains a link-local IP literal, it MUST NOT
contain a Zone Identifier, and MUST be local to the link on
which the registration request is received.
Paragraph (version A):
If the base URI of a registration contains a link-local address, the
RD MUST NOT show its links unless the lookup was made from the same
zone, and MUST NOT include zone identifiers in the resolved URIs.
Paragraph (version B):
If the base URI of a registration contains a link-local address, the
RD MUST NOT show its links unless the lookup was made from the same
link.  The RD MUST NOT include zone identifiers in the resolved URIs.
Paragraph (version A):
Base addresses that contain link-local addresses MUST NOT include
zone identifiers, and such registrations MUST NOT be show unless the
lookup was made from the same zone.
Paragraph (version B):
Base addresses that contain link-local addresses MUST NOT include
zone identifiers, and such registrations MUST NOT be show unless the
lookup was made from the same link from which the registration was
made.
Draft: draft-ietf-core-resource-directory

Commentary: The implementors in RIOT asked about whether a registrant could possibly maintain multiple registrations at different RDs , and how they interact . I think what I 'm saying in this PR is obvious ( though not redundant , as we do n't talk about that topic otherwise ) , but given it was asked about , it 's probably not . What are your opinions ? 
 ( Text updated after I learned more about what they thought was expected from Registrant - EPs . ) 
 Shortened and merged . 
 A registrant - ep can not be forbidden to register with multiple RDs anyway . May be a bit too much text for an obvious fact .
Paragraph (version A):
A Registrant-EP MAY keep concurrent registrations to more than one RD
at the same time, but that is not expected to supported by typical EP
implementations.  Any such registrations are independent of each
other.
Paragraph (version A):
For this case to occur, the EP would need to be explicitly configured
to register multiple times: either by having multiple discovery
mechanisms or addresses configured (which are not merely fallbacks to
each other), or by having several sets of registration data to
register with (eg. multiple endpoint names).
Paragraph (version B):
A Registrant-EP MAY keep concurrent registrations to more than one RD
at the same time if explicitly configured to do so, but that is not
expected to be supported by typical EP implementations.  Any such
registrations are independent of each other.  The usual expectation
when multiple discovery mechanisms or addresses are configured is
that they constitute a fallback path for a single registration.
Draft: draft-ietf-core-resource-directory

Commentary: The luminary of the example previously discovered its group addresses by looking up its own registration resource ( which it did not know because it was entered by a CT ) , and via that its groups . As long as the device does not need to know its own registration resource , the same can be achieved in a single step by looking up groups that contain it directly , based on the address it would originally have compared the endpoint results against . Closes : Like with : that 's the example where you know all the rationales , feel free to merge or discard . 
 In the luminary example , the device first does an endpoint lookup to find its ep by comparing values , and then a group lookup to find its groups . That is unnecessary ; by the rules of lookup , it could just do a group lookup with base= its own address and get the same result in one step .
Paragraph (version A):
The luminary, knowing its sector, queries the RD for the endpoint
with rt=light and d=R2-4-015.  The RD returns all endpoints in the
sector.
Paragraph (version A):
Knowing its own IPv6 address, the luminary discovers its endpoint
name.  With the endpoint name the luminary queries the RD for all
groups to which the endpoint belongs.
Paragraph (version A):
From the base parameter value, the luminary learns the multicast
address of the multicast group.
Paragraph (version B):
From the returned base parameter value, the luminary learns the
multicast address of the multicast group.
Draft: draft-ietf-core-resource-directory

Commentary: This responds to a comment from  on the use of the term " Origin " in  which I had previously missed . Given that the old 6690 - style documents are thus a lot less powerful , the text goes from " Submitted documents should be the same in both interpretations , and the RD can use either " to " Submitted documents should be the same , and the RD interprets them 8288 style " . A paragraph was that defines precisely what it means to interpret it 8288 style . Several outdated references to where resolution happens have been removed . The " 8288 style interpretation " is called    ; I 'd be happy of any better names , but am convinced we need to name it somehow to avoid vaguely describing the same thing again and again .
Paragraph (version A):
In link-format serialization, it is expressed in the "anchor"
attribute.  There, it can be a relative reference, in which case
it gets resolved against the URI of the ".well-known/core"
document it was obtained from.  It defaults to that document's
URI.
Paragraph (version B):
In link-format serialization, it is expressed in the "anchor"
attribute.  It defaults to that document's URI.
Paragraph (version A):
If there is an anchor attribute present and the link is serialized in
RFC6690 link format, this document will require that the link is an
absolute reference to avoid the ambiguities outlined in resolution-
rules.
Paragraph (version A):
Otherwise, it can be serialized as a relative URI, and gets resolved
against the document's URI.
Paragraph (version A):
Documents in RFC6690 Link Format SHOULD NOT contain links in which
resolving the target literal against the base URI gives a different
result than resolving it against the resolved anchor; this is to
avoid the ambiguities described in resolution-rules.
Paragraph (version A):
Entries in which there is no anchor attribute,
Paragraph (version A):
never cause that kind of ambiguity.
Paragraph (version B):
Link format documents submitted to the resource directory are
interpreted as Modernized Link Format (see modern6690) by the RD.  A
registree-ep SHOULD NOT submit documents those interpretation
according to RFC6690 and modern6690 differs and RFC6690
interpretation is intended to avoid the ambiguities described in
resolution-rules.
Paragraph (version B):
In practice, most links (precisely listed in modern-safe) can be
submitted without consideration for those details.
Paragraph (version A):
con that contains a path component need to carefully consider
the rules of relative URI resolution.  Typically, links
submitted by such an endpoint are of the "path-noscheme"
(starts with a a path not preceded by a slash, precisely
defined in RFC3986 Section 3.3) form.
Paragraph (version B):
con that contains a path component can not meaningfully use
RFC6690 Link Format due to its prevalence of the Origin concept
in relative reference resolution; they can submit payloads for
interpretation as Modernized Link Format.  Typically, links
submitted by such an endpoint are of the "path-noscheme"
(starts with a a path not preceded by a slash, precisely
defined in RFC3986 Section 3.3) form.
Draft: draft-ietf-core-resource-directory

Commentary: Populates missing descriptions in the IANA template for resource types , but primarily adds new resource types ( and ) to the lookup results . 
 ( This was quickly but a bit vaguely agreed on in the last meeting ; will merge if nobody objects . ) 
 This was discussed in the last meeting but did not result in an action item ; will check whether we agreed to do this ( AFAIR we did ) and add the text for it . 
 The right place is in the management example . I hesitated but did not do it chrysn schreef op 2018 - 06 - 27 11:51 : Links : [ 1 ] [ 2 ] 
 Done with in .
Paragraph (version A):
Endpoint and group lookups result in links to registration resources
and group resources, respectively.  Endpoint registration resources
are annotated with their endpoint names (ep), domains (d, if present)
and context (con); the lifetime (lt) is not reported.  Additional
endpoint attributes are added as link attributes to their endpoint
link unless their specification says otherwise.  Group resources are
annotated with their group names (gp), domain (d, if present) and
multicast address (con, if present).
Paragraph (version B):
Endpoint and group lookups result in links to registration resources
and group resources, respectively.  Endpoint registration resources
are annotated with their endpoint names (ep), domains (d, if present)
and context (con) as well as a constant resource type (rt="core.rd-
ep"); the lifetime (lt) is not reported.  Additional endpoint
attributes are added as link attributes to their endpoint link unless
their specification says otherwise.
Paragraph (version B):
Group resources are annotated with their group names (gp), domain (d,
if present) and multicast address (con, if present) as well as a
constant resource type (rt="core.rd-gp").
Draft: draft-ietf-core-resource-directory

Commentary: The rules laid out below the removed sentence are pretty clear , but the removed sentence itself can be read to contradict them ( " may be created at any time to supersede an existing registration " ) or at best does not add anything . Assuming it was left over from an older version ( before the rules were ) , I suggest we remove it . that 's your section of expertise . Please merge if you agree or reject otherwise .
Paragraph (version A):
multiple registration resources.  A new registration resource may be
created at any time to supersede an existing registration, replacing
the registration parameters and links.
Paragraph (version B):
multiple registration resources.
Draft: draft-ietf-core-resource-directory

Commentary: This executes the renaming of con to base and domain to sector as agreed on in the last meeting . Two follow - up commits create consistency in the ER diagram ( which had to be modified anyway for the renaming ) and the accompanying text , both internally ( describe groups the same way as resources ) and within the document ( we describe several properties of a group that the ER did not show ) .
Paragraph (version B):
a group resource location inside the RD ("href"),
Paragraph (version A):
a registration resource location inside the RD ("loc"),
Paragraph (version B):
a registration resource location inside the RD ("href"),