jiebi/CodeConvo huggingface dataset:
Change:
Use case HA/BA: Expand and reference term "6LBR" Use case HA/BA: Use term 'IoT' that's more common in that area these days

Discussion:
3.6. Home and commercial building automation systems can benefit from the <del> use of M2M web services.  The discovery requirements of these </del> <ins> use of IoT web services.  The discovery requirements of these </ins> 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

Two phases can be discerned for a network servicing the system: (1) installation and (2) operation.  During the operational phase, the <del> 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 </del> <ins> network is connected to the Internet with a Border Router (e.g. a 6LoWPAN Border Router (6LBR), see RFC6775) 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 Border Router is connected, and the network only supports the IP </ins> 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

"coap://[MCD1]/.well-known/core?rt=core.rd*".  RDs within the multicast scope will answer the query. <del> When answering a multicast request directed at a link-local address, </del> <ins> When answering a multicast request directed at a link-local group, </ins> 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.
Change:
rather than only referring to the subregistry's name See-Also: URL I concur with my colleagues who commended the authors for making the document very readable. I support Roman's first two DISCUSS points. In Section 9.2, you might want to mention that you're talking about a sub-registry under "Internet Control Message Protocol version 6 (ICMPv6) Parameters". In Section 9.3, you enumerate six fields in each registration, but the initial table of entries has only five columns. It's obvious (I think) that the sixth column would be "this document" for all entries, but I suggest that you should either include the column or some prose making this explicit (since everything else is).

Discussion:
9.2. This document registers one new ND option type under the sub-registry <del> "IPv6 Neighbor Discovery Option Formats": </del> <ins> "IPv6 Neighbor Discovery Option Formats" of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry: </ins> Resource Directory Address Option (TBD38)
Change:
See-Also: URL Apart from pointing out the scope, this also comprehensively lists the few configuration options that are there for such an RD. Hi, Thank you for this document. I'm glad that the shepherd's writeup indicates that there are implementations since that indicates that there does appear to be value in standardizing this work, despite its long journey. My main comment (which I was considering raising as a discuss) is: Since this document is defining a new service, I think that this document would benefit on having a short later section on "Operations, Administration and Management". This document does seem to cover some management/administration considerations in various sections in a somewhat ad hoc way, but having a section highlighting those would potentially make it easier deploy.  Defining a common management model (or API) would potentially also make administration of the service easier, I don't know if that had been considered, and if useful could be done as a separate document. A few other comments: What happens if an endpoint is managing the registration and is upgraded to new hardware with a different certificate?  Would the updated endpoint expect to be able to update the registration?  Or would it have to wait for the existing registration to timeout (which could be a long time)? Nit: Perhaps reword the second sentence.  Otherwise it seems to conflict with the last sentence of the prior paragraph. The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as "MAY NOT".  In many cases, if the configuration is not too big then providing the full configuration makes it easy to guarantee that the receiver has exactly the correct configuration.  I appreciate that there are many cases where from an endpoint perspective it may want to keep the update small, but if I was doing this from a CT, I think that I would rather just resend the entire configuration, if it is not large. Just to check, is it correct that the anchor in the http link is also to coap://?  If this is wrong then there is a second example in the same section that also needs to be fixed.

Discussion:
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 <del> policies apply to different sectors. </del> <ins> 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. </ins> 8.
Change:
Even disregarding the examples that necessarily have the slash, this (vs. plain .well-known/core) version was the more common in the text so far. Closes: URL
This actually
Current master branch text is really unclear: What does it mean : "used to find the identification" ? Can we say intead "used to identify the components" ? How can the URI discovery process identify client-server incompatibilities? CoAP doesn't let you discover supported protocol versions, options, etc. as far as I know, by default. For those implementations not supporting I-D.bormann-t2trg-rel-impl , it is really unclear what to do with this paragraph.
Oups, wrong link in the commit -- sorry for the noise
The intention behind this paragraph is merely to point those who want versioning and more RD metadata that is immaterial to the regular operation to a place where they can safely do so. I see, however, how the "it is necessary to" makes this sound like more than there really is to it. Accordingly, the incompatibilities part is not about finding that something can't work in the first place (that works on a positive-list base using rt and that like), but more for understanding later why things don't work (say, client X produces a document that upsets RD implementation Y in versions earlier than 0.4.1). The address is in section 4 of 6690 (ie. just .well-known/core); now referred to by the name it has there.
A couple of places has ".well-known/core" as resource name, while in most places it says "/.well-known/core". Proposal is to update all occurrences to the latter form. (Maybe this is already addressed in the pull requests with nits, but there are so many - hard to check...)

Discussion:
a set of links belonging to the hosting web server The web server is free to choose links it deems appropriate to be <del> exposed in its ".well-known/core".  Typically, the links describe </del> <ins> exposed in its "/.well-known/core".  Typically, the links describe </ins> resources that are served by the host, but the set can also contain links to resources on other servers (see examples in RFC6690 page 14).  The set does not necessarily contain links to all resources

7.3. When registrants publish information in the RD that is not available <del> to any client that would query the registrant's .well-known/core </del> <ins> to any client that would query the registrant's /.well-known/core </ins> interface, or when lookups to that interface are subject so stricter firewalling than lookups to the RD, the RD may need to limit which lookup clients may access the information.

Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with the victim's address as source address, and later look up the <del> victim's .well-known/core content in the RD.  Mitigation for this is </del> <ins> victim's /.well-known/core content in the RD.  Mitigation for this is </ins> recommended in simple. The Registration Resource path is visible to any client that is
Change:
These changes were talked about previously in Prague and allow preservation of link relationships. A new example based on the relevant RFC6690 example shows different relevant cases (with present in the registration) in the lookup interface. The latest suggestions of bringing the endpoint interface in line with that are not included yet.
RFC5988 (web linking) describes that a statement of in the context of A means that "A has a hosted resource at B, which has the attribute C=D" (with the implied "hosts" relationship from RFC6690). The repeated entries of the pattern currently drafted for the domain lookup interface (and the analogous group lookups) are bear no such meaning, and all provide statements about the same resource. In a way, they could be collapsed into (or ). Given it then talks about the currently used resource-directory (that is ), isn't that a more straightforward to express the desired information anyway?
See issue I think we need to include the group resource location, which is returned when a group is created, in the angle brackets or "href". I also believe we shod not specify a "domain" lookup because we decided to specify domain as an attribute of a registration. There is no domain table to do lookups on...

Discussion:
The following example shows a client performing an endpoint type lookup: <del> The following example shows a client performing a domain lookup: </del> The following example shows a client performing a group lookup for all groups:
Change:
This is the first step to closing [54], doing the changes to the model itself. Won't close the issue by itself probably, as some other portions might mention the model. This does not try to address any of the open issues. [54]: URL
s taget/target/

Discussion:
the cardinality of the relations.  The relations between the values of the attributes are explained in the interface sections. <ins> Some of the attribute values are URIs.  Those values are always full URIs and never relative references in the data model.  They can, however, be expressed as relative references in serializations, and often are. </ins> The model shown in fig-ER-WKC models the contents of /.well-known/ core which contains:

A link has the following attributes: <del> One or more link relations (expressed as space-separated values in the "rel" attribute, defaulting to "hosts").  They describe a </del> <ins> Zero or more link relations (expressed as space-separated values in the "rel" attribute, defaulting to "hosts").  They describe a </ins> relations between the link context and the link target. A link context URI ("anchor").  The link context defines the source of the relation, and serves as the Base URI for resolving <del> the target.  It can be relative, in which case it gets resolved against the Base URI of the ".well-known/core" document it was obtained from . It can be absent, in which the Base URI of the document is used as the context. </del> <ins> the target.  In the serialization, it can be relative, in which case it gets resolved against the Base URI of the ".well-known/ core" document it was obtained from . It can be absent, in which the Base URI of the document is used as the context. </ins> A link target URI ("href", expressed between the angular brackets in link-format).  The link target defines the destination of the <del> relation, and is the topic of all other target attributes.  If it is a relative URI, it gets resolved against the link context URI. </del> <ins> relation, and is the topic of all other target attributes.  In the serialization, if it is a relative URI, it gets resolved against the link context URI. </ins> Other target attributes (eg. resource type (rt), interface (if), cor content-type (ct)).  These provide additional information

copied from the value of the "hosts" relation and overwritten by the value of the con query parameter. <del> Links are modelled as they are in fig-ER-WKC.  As they do not have their ".well-known/core" document associated with them any more which would originally provide its Base URI, the "con" attribute of the registration fills that gap and is used as a Base URI. </del> <ins> Links are modelled as they are in fig-ER-WKC. </ins> 3.4.
Change:
Some minor text changes (commented per commit) I think are resonable and will merge soon unless someone speaks up against them.

Discussion:
The endpoint then finds one or more addresses of the directory server as described in simple_finding. <del> An endpoint can send (a selection of) hosted resources to a directory server for publication as described in simple_publishing. </del> <ins> An endpoint finally asks the directory server to probe it for resources and publish them as described in simple_publishing. </ins> The directory server integrates the information it received this way into its resource directory.  It MAY make the information available
Change:
I think that rt is not an attribute of a registration; the first commit reflects that. (The second is more bycatch from that). Possibly we can simplify the whole section; as everything in the result is links, we're only applying the same link filtering that 6690 already specifies (plus pagination).
Absolutely right. After all commits by Christian, I will look at these examples again together with discovery text and other details. cabo schreef op 2017-10-19 16:57:

Discussion:
Endpoint type (optional).  Used for group, endpoint and resource lookups. <del> Link attribute parameters (optional).  Any link target attribute as defined in Section 4.1 of RFC6690, used for resource lookups. </del> <ins> Link parameters (optional).  Any link parameter as defined in Section 4.1 of RFC6690, including href, used for resource lookups. </ins> application/link-format (optional)
Change:
The first commit tries to get across the difference between the relative references in the serialization and the URIs in the model more clearly. The second commit adds paragraphs to the descriptions of various operations about how and by whom URIs are resolved in those steps.

Discussion:
An empty payload is considered a malformed request. <ins> The posted link-format document can (and typically does) contain relative references both in its link targets and in its anchors, or contain empty anchors.  The server needs to resolve these references in order to faithfully represent them in lookups.  The Base URI against which they are resolved is the context of the registration, which is provided either explicitly in the "con" parameter or constructed implicitly from the requester's network address.  When resolving relative target references, the server first resolves the context of that link (the in the "anchor" attribute), and then interprets the target as a reference relative to that context (see resolution-rules). </ins> The registration request interface is specified as follows: EP -> RD

(possibly updated) lifetime of the registration, independent of whether a "lt" parameter was given. <ins> If the context of the registration is changed in an update explicitly or implicitly, relative references submitted in the original registration or later updates are resolved anew against the new context (like in the original registration). </ins> The update registration request interface is specified as follows: EP -> RD

Resource lookup results in links that are semantically equivalent to the links submitted to the RD if they were accessed on the endpoint itself.  The links and link parameters returned are equal to the <del> submitted ones except for anchor, which gets resolved according to the endpoint's context.  That allows the client to interpret the response as links without any further knowledge of what the RD does. The Resource Directory MAY replace the contexts with a configured intermediate proxy, e.g. in the case of an HTTP lookup interface for CoAP endpoints. </del> <ins> submitted ones except for anchor, which was resolved by the server against the endpoint's context. Links that did not have an anchor attribute are therefore returned with the (explicitly or implicitly set) context URI of the registration as the anchor.  Links whose anchor was submitted as an absolute URI are returned as they were registered.  The hrefs of links can always be served as they were submitted; the server MAY return relative references in absolute form in to resource lookups, but that results in needlessly verbose responses. That allows the client to interpret the response as links without any further knowledge of what the RD does.  The Resource Directory MAY replace the contexts with a configured intermediate proxy, e.g. in the case of an HTTP lookup interface for CoAP endpoints. </ins> Endpoint and group lookups result in links to the selected registration resource and group resources.  Endpoint registration
Change:
See individual commit messages
As we support the alternative serializations from draft-ietf-core-links-json, I'd like to add at least the numbers in the RD lookup examples.
Use TBD64 etc., as discussed in the call.

Discussion:
similar to example-discovery. A Resource Directory may optionally support HTTP.  Here is an example <del> of the same registration operation above, when done using HTTP. </del> <ins> of almost the same registration operation above, when done using HTTP and the JSON Link Format. </ins> 5.3.1.

with the example resource look-up locations discovered in example- discovery: <ins> The same lookup using the CBOR Link Format media type: </ins> The following example shows a client performing an endpoint type lookup:
Change:
The description of the Registration interface describes it as idempotent, I think it should be idempotent on CoAP and not only on application level -- the same request results in the same response with no further state change. As to what happens when the re-registration arrives with a different set of links, there we have options; I went for "replaces the registration" here, but a 4.09 in that case would be just as valid an option. NAME that topic came up with the removal of the plurality removal at URL Do you agree with the basic proposition of "an unmodified request should be 2.04", and do you think replacing is the right way, or 4.09 if the links don't match?
Replacement is OK, given the removal of "addition of inks" with a POST. Conflicts are indeed impossible then.

Discussion:
registration resource.  The registration resource location thus returned is for the purpose of updating the lifetime of the registration and for maintaining the content of the registered <del> links, including updating and deleting links. </del> <ins> links, including updating and deleting links.  A registration with an already registered ep and d value pair responds with the same success code and Location as the original registration; the set of links registered with the endpoint is replaced with the links from the payload. </ins> 4.00 "Bad Request" or 400 "Bad Request".  Malformed request. <del> 4.09 "Conflict" or 409 "Conflict".  Attempt to create a registration resource with ep and d value pair which is already present in an earlier created registration resource. </del> 5.03 "Service Unavailable" or 503 "Service Unavailable".  Service could not perform the operation.
Change:
Unless takes a very surprising turn, I suggest reverting this: /rd-lookup/res (assuming it was discovered) always exists 2.03 is the wrong code this prescribes things already following from general observation Not reverting it yet awaiting the closure of .
chrysn schreef op 2018-01-31 12:26: Peter

Discussion:
detected and used according to their own specifications and can be used with the lookup interface as with any other resource. <ins> When resource observation is used, the following convention MUST be followed: When /rd-lookup/res does not exist, the response code 4.04 (Not Found) is returned and the request is not registered. When rd-lookup/res exists, the request is registered in the list of subjects and observers. When none of the links matches the filter, an empty payload with response code 2.03 (Valid) is returned. In all other cases, the set of matching links is returned in the payload with response code 2.05 (Content). Every time, the set of matching links changes, or the content of a matching link changes, the RD sends a notification with the matching link set. </ins> The lookup interface is specified as follows: Client -> RD
Change:
This adds an example of how impl-info can be used to obtain implemetation software and version information. Closes: URL
But why would you want to do the latter, if not for the former or for some privacy-intrusive application? (Well, OK, netcraft style surveys. But these are not the motivation for documenting this, either.) Grüße, Carsten
The text in the RD spec suggests that debugging is needed and that debugging is possible thanks to the rel-impl relation. That is a bit strong: I can debug without the rel-impl relation. cabo schreef op 2018-01-31 17:27:
I was referring to generic use of .well-known/core as opposed to the formally limited interface ( described in the URI Discovery section. The pull request will be updated to address both concerns; thanks for the review.
Closed after immediate comments were addressed; it appears we're deep enough into the discussion of impl-info details that the direction is good.
There is a lot of confusing info in the first 4 lines. Debugging is not the problem, getting information about the implementation is. What are generic resource discovery techniques? We do have one specification called RD., and /.well-known/core The example is terse; Nice to know what the link means or is supposed to provide Thanks for the text; it helps to focus.

Discussion:
application/link-format+cbor and application/link-format+json, respectively, as they are defined in I-D.ietf-core-links-json. ] <del> At the same location where URI discovery happens, a user who wants to debug interoperability issues can ask for additional information that might be available about the server using generic resource discovery techniques.  That information would typically be stored in an implementation information link (as described in I-D.bormann-t2trg- rel-impl): </del> <ins> A user can introspect the server for implementation information to ease debugging by using the URI discovery address as described in RFC6690 Section 4.  Information about the used software would typically be stored in an implementation information link (as described in I-D.bormann-t2trg-rel-impl): </ins> Note that depending on the particular server's architecture, such a link could be anchored at the server's root, at the discovery site