Change:
The requirement was neither precise with current technology (requiring base= even for NAT with endpoint-independent filtering) nor particularly future-proof, and is replaced with a more general statement. While the previous paragraph (about ephemeral endpoints) could have been pulled into the new one, I decided against it as it'd be deeply nested ("(e.g. because of using ephemeral ports (which happens in TCP))") and would have borne the risk of implementors overlooking it because of that. Closes: URL Will merge soon given prior discussion in
The current text says "behind a NAT gateway" as one case in which is obligatory. Reviewing (esp. the part on making base mandatory all the time) I noticed that this should probably be made more precise (would have said "NAT other than full cone", but RFC 4787 has better terminology I'll yet need to go through).
other than full cone?
"Full cone" is an older term that AFAICT roughly means that for each inside port there's an outside port as well (a rather uncommon setup at least in the simple setups I've seen), but anyway that's neither the modern term nor the right criterion. The criterion is probably "If a registrant-ep residing on the internal side NAT that does not follow the recommendations of {{?RFC4787}} with no stringent filtering (in particular REQ-1 and the Endpoint-Independent Filtering of REQ-8) registers with a Resource Directory on its external side, it MUST NOT register with the RD unless it gives an explicit base address that is usable for the lifetime of the registration (e.g. using a configured forwarded port)." I've left the general requirement structure as it is, ie. from the normative language, the registrant has to know about the network. This is unreasonable to demand of the software implementation, and will need to be covered by the implementation's usage instructions or similar (a la "If you deploy this in behind a NAT, you have to add port forwarding and give the externally visible address in this configuration field (which becomes base), otherwise your endpoint would not be compliant") – but that does not change with this edit, and I still think it's good that way. Reading 4787 I also noted that the lifetime interacts with this as well; in the same vein as "if in a really-bad NAT then set base", there'd be a "if in a regular NAT, need to refresh often enough"; not sure which line that'd go into yet.
I would be carefull with any of these instructions because they arre very general and new boxes between communicating nodes may appear any time. chrysn schreef op 2019-03-05 17:16: Links: [1] URL [2] URL
Valid point; so can we put that more generally? Maybe ? Adding "or uses an ephemeral port to register" to the parentheses would even allow this to swallow the paragraph before as well. (Nitpickers might argue that this needs an exception for link-local addresses, but we're talking about them in the next paragraph). 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:
it MUST include the base parameter in the registration to provide a valid network path. <del> If the registrant-ep, located behind a NAT gateway, is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> A registrant that can not be reached by potential lookup clients at the address it registers from (e.g. because it is behind some form of Network Address Translation (NAT)) MUST provide a reachable base address with its registration. </ins> If the Base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier, and MUST be local to the link on