Original text:
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>  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>  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>  recommended in simple. The Registration Resource path is visible to any client that is

Reviewer comments:
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...)

Revised text:
a set of links belonging to the hosting web server The web server is free to choose links it deems appropriate to be  <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  <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  <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