Change:
8.2. Access control SHOULD be performed separately for the RD <del> registration, Lookup, and group API base paths, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD.  Such access control SHOULD be performed in as fine-grained a level as possible.  For example access control for lookups could be performed either at the domain, endpoint or resource level. </del> <ins> registration, Lookup, and group API paths, as different endpoints may be authorized to register with an RD from those authorized to lookup endpoints from the RD.  Such access control SHOULD be performed in as fine-grained a level as possible.  For example access control for lookups could be performed either at the domain, endpoint or resource level. </ins> 8.3.

Discussion:
All URIs of RD APIs are discovered standalone, and no relative URI or path-appending is required any more. Therefore, the term "Base URIs" and the distinction between "rd-lookup-base" and "lookup-type" in the RD lookup API are obsolete. This has already been , and , if I understood his response correctly (which I'm unsure about, thus tagging this for review).
I'd consider toning down the default value recommendations a different issue; is it fine with you apart from that? (Note to self: I accidentally dropped the "res:= " parameter here; that's another topic and shouldn't go in that commit.)
There is still some weirdness here: The "URIs" here are still parameters for URI templates, not the actual URIs that will be used for accesses.
Good point. Going from to should address that, I'll update accordingly.
I've updated the pull request to address the comments, and fixed some oversights of mine. While the first commit has been modified, the changes should largely be review friendly in that the three last commits are the newly introduced ones for NAME template weirdness NAME "recommended" → "example" rewording and some more "base" occurrences I had missed, together with clearer naming of the "RD registration URI" instead of just "RD (base) URI" which might cause confusion with the "RD URIs" (the "RD lookup URIs" and the "RD group URI") in general.
Merged as agreed in last call.
It is argued that a recommended base path is not appropriate. At line 593: "the value /rd is recommended", should be: "the value /rd is an example value". Hello Peter, among those, I just happened to note that instead of (say) being advertised as URL (which would then have triggered string-appending "/ep" to it), the individual records are now advertised. Much appreciated; this makes implementation of resource trees smoother! (Actually I found an inconsistency of my implementation of -09, and looking it up, it was fixed in this version I had not read before). It does add one easily fixed quirx, however: In the lookup URI template, there's now /{+rd-looup-base}/{lookup-type}. Is that distinction still needed?

The base can't be discovered now any more, so I'd say this now should be | URI Template: /{+type-lookup}{?d,...} | | type-lookup := RD lookup location (mandatory). Discovered for a given | type in .well-known/core by its resource type, where it SHOULD be | listed. The recommended value for this variable is: | "/rd-lookup/{type}". Mandatory to be present for types "ep" and | "res", optional for "d" and "gp". (Or maybe you they can stay "base URIs", but be many; that's only terminology then). I've gone through the rest of the document; "is used to discover the base URI for RD Lookup operations" would need to speak of "URIs". Sounds good now. The term "Simple directory discovery" was dropped from the descriptions but survived in 5.3.3; it should probably say "simple registration" there. Other notes (some on nitpicking level, but if we're at WGLC level I suppose that's OK): 5.2 mentions '"URL" is used to discover the base URI for RD group operations'. Shouldn't this be "URL"? (Unsure as not yet really familiar with all the groupcom things). 5.2 lists HTTP support but no HTTP response codes 5.2 first request/response example: needless quotes about a ct 5.3 example: The HTTP requester will probably want to set a con= too unless it actually sends the HTTP request from its port 80. 'The domain lookup returns every lookup domain with a base RD resource value (e.g. "/rd") encapsulated within angle brackets.' (and similarly the following group paragraph): This sounds contradictory to the example given later (which returns '<>;d="domain1"'), where nothing is encapsulated in the angle brackets. 9.3 "con" entry: Since the latest changes this should include "path" too. 10.1.2: In the requests from the CT, the domain parameter is given per-resource in the payload. Isn't that exclusively used as a query parameter in registration? Later in the group setup POST, the semicolons after the <> are missing in the payload, and the colon in 'coap//' in the con parameter, which has abundant quotation marks.

10.2: "./well-known/core" -> "/." I haven't updated my implementation yet, but don't see any trouble on that road. Looks good to me, all things considered. Best regards Christian To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
Hi Christian, Thank for the feedback; see below. Christian Amsüss schreef op 2017-03-16 17:43: Good to read. URIs it will be; rd-lookup-base is also used later; and is an understandable concept. agreed. not yet. No opinion. see what the co-authors think. Correct; correct, again. good suggestions Yep, have to solve that one way or the other. mistakes come and go, in spite of github change it, thanks for looking at it. thanks again. there is also another instance; also here mistakes come and go. Many thanks, peter