Change:
This addresses . The net effect on word/line count is not large (saving ~60 lines and ~150 words), but it's less repetitive and IMO gives better guidance towards how to handle errors. Will merge into -20 today unless objected to.
The entries for "Failure" are quite repetitive for 4.00 and 5.03. Can we factor these out a bit? The entry "HTTP support" is surprising; maybe this item should be explained beforehand. (It seems all it is saying is that HTTP does not do multicast or /.well-known/core?) (via Jaime)
NAME and NAME AFAIR both of you argued for the interaction templates in the length they have now, but I failed to find the old arguments. (There were some unresolved points in and and , but they don't tell the whole story). I'd argue that most of the failure codes can be removed, for they can't be exhaustive anyway (would we need to add 4.01 for when the client would need to authenticate? 4.08 if a block was missed? 4.29 to throttle?) – handling those is part of CoAP and not the application. If I were to make a proposal, I'd replace all "Failure:" paragraphs (except 4.04 on update/removal, as that's particularly noteworthy) with a general note that Are the sections still justified to be that long, and if so, could you contribute a note on why that is for the review of ?
A point I missed that should go after that suggested paragraph, to fully cover Jaime's comment:
I have made no contribution to template length or format. I don't remeber arguments that support their length. Having written that, I like to idea of having templates. I like them to be stand-alone which makes them lengthy. I have enormous problems with the response codes. Their text never covers what you want to express, they remain approximations of the problem unless they are at the general server level. My sugesstion is not change what is there, but I will not oppose the general text although I consider it possibly too vague for standardization. Dear authors, below are some of the comments to the draft, they are mostly editorials with few ones that may warrant further discussion. p1 - "Web interfaces" is often used interchangeably with "REST interfaces" it'd be better to use one only, maybe the latter. p3 - "with limited RAM and ROM" Adding a reference to the expected RAM and ROM would be good. URL provides an estimation of : -> : : Which in markdown would look like: ~ p22 - Endpoint Name "mostly mandatory" is ambiguous. If the ep name is not needed to register to an RD then it is optional. If, on the other hand the RD needs an ep name and assigns one then it is mandatory ( btw if the RD assigns the ep name, shouldn't it return that information to the ep, together with the location within the rd, once the registration is successful? ) Github Issue 190 (below) raises the need to define a bit better what the ep name is supposed to contain. To me, we could keep it mandatory and add some guidelines for its creation, in OMA for example they are defined as an URN URL p22 - URL "All we know from the draft is that it is ≤ 63 bytes. But we need to say that it is a UTF-8 string. Not entirely sure we want as an endpoint name either. Same for sector." p23 - Sorry for asking, but why is base URI only mandatory when filled by the Commissioning Tool? Wouldn't it be better to make it always mandatory to avoid the differentiation? p26 - Section 5.3.1 seems like could use a bit of reordering, I can explain this in another email or call with the authors. p30 - lt, base and extra-attrs were already explained in 5.3 you might want to keep it as it is or change it by adding a reference to 5.3 and comment on the changes that the Registration Update has over the Registration. p33 - As per the document structure, there are two interfaces: registration and lookup. Shouldn't they be at the same level in the document? Registration is 5.3, shouldn't lookup be 5.5 instead of 6? p41 p42 - Just to clarify, is then the tuple [endpoint,sector] the way RD identifies endpoints? Or is it derived from the device's credentials? "A given endpoint that registers itself, needs to proof its possession of its unique (endpoint name, sector) value pair." - "An Endpoint (name, sector) pair is unique within the et of endpoints registered by the RD. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint." p44 - typo address/Address

Discussion:
Update operation.  Therefore, the Location-Query option MUST NOT be present in a successful response. <del> If the registration fails with a Service Unavailable response and a Max-Age option or Retry-After header, the registering endpoint SHOULD retry the operation after the time indicated.  If the registration fails in another way, including request timeouts, or if the Service Unavailable error persists after several retries, or indicates a longer time than the endpoint is willing to wait, it SHOULD pick another registration URI from the "URI Discovery" step and if there is only one or the list is exhausted, pick other choices from the "Finding a Resource Directory" step.  Care has to be taken to </del> <ins> If the registration fails, including request timeouts, or if delays from Service Unavailable responses with Max-Age or Retry-After accumulate to exceed the registrant's configured timeouts, it SHOULD pick another registration URI from the "URI Discovery" step and if there is only one or the list is exhausted, pick other choices from the "Finding a Resource Directory" step.  Care has to be taken to </ins> consider the freshness of results obtained earlier, e.g. of the result of a "/.well-known/core" response, the lifetime of an RDAO option and of DNS responses.  Any rate limits and persistent errors

4.04 "Not Found" or 404 "Not Found".  Registration does not exist (e.g. may have been removed). <del> If the registration update fails with a "Service Unavailable" response and a Max-Age option or Retry-After header, the registering endpoint SHOULD retry the operation after the time indicated.  If the registration fails in another way, including request timeouts, or if the time indicated exceeds the remaining lifetime, the registering </del> <ins> If the registration fails in any way, including "Not Found" and request timeouts, or if the time indicated in a Service Unabailable Max-Age/Retry-After exceeds the remaining lifetime, the registering </ins> endpoint SHOULD attempt registration again. The following example shows how the registering endpoint updates its