Change:
This pull request contains edits to resolve my comments earlier; these here address the uncontroversial points .
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.
There has been confusion about the semantics of an absent in the presence of transient ports ( first paragraphs, 5.3 HTTP example). Proposed solution: more explicit wording about con= being practically required when transient ports are used.
The wording has already been strengthened in -10; can be closed when the examples are adapted.
Closing comment was missing on 132d5c3145e6f8b3ebe568f560e922fc70b2085d; keeping the issue open until Carsten's comments in URL are resolved. 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
Hi Christian Okay, I was clearly using these libraries incorrectly (create a client context - with a transient port - to register and a server context to handle queries). I now have my code working correctly using only the server context. I know it's implied, but could it be made more explicit in the spec as In the absence of this parameter the scheme of the protocol, source IP address and source port of the register request are assumed. The request should not be sent from a transient port, the registering agent is expected to be an endpoint for that scheme, IP and port. I'm thinking of someone just querying /.w-k/c, without a filter. They will see all /rd/xxxx resources, even if they don't know their type. Yes, the endpoint registering the resource is expected to use this when updating or removing the registration. Maybe I'm reading more into the spec than I should, but I'm thinking that no-one else apart from the original registering endpoint should be able to modify/delete the resources. Eventually that comes down to security but using obscurity through non-visibility helps achieve this. Cheers Jan Dr Jan Newmarch

Discussion:
The location of the LWM2M Server and RD base URI path is provided by the LWM2M Bootstrap process, so no dynamic discovery of the RD is used.  LWM2M Servers and endpoints are not required to implement the <del> ./well-known/core resource. </del> <ins> /.well-known/core resource. </ins> 10.2.1.