search

anima-wg / constrained-join-proxy

1 stars 2 forks source link

Check wording of the mandatory-to-implement text (Section 4.0) #64

Open EskoDijk opened 3 weeks ago

EskoDijk commented 3 weeks ago

Current text

A Join Proxy MUST implement both. A Registrar MUST implement the stateful mode and SHOULD implement the Stateless mode.

A mechanism to switch between modes is out of scope of this document. It is recommended that a Join Proxy uses only one of these modes at any given moment during an installation lifetime.

Assigning to @toerless to consider some "softer" wording or rewording to clarify.

Noting that the part "A Registrar MUST implement the stateful mode" is always satisfied, otherwise the Registrar wouldn't be a Registrar at all. (It will always implement Coap-over-DTLS-over-UDP per cBRSKI -- even if it would keep this port locked & shielded from any clients.)

mcr commented 2 weeks ago

I'm still happy with the text.

EskoDijk commented 2 weeks ago

For me the "A Join Proxy MUST implement both" isn't fully aligned with existing reality of mesh networks.

For example if Thread would adopt a stateful join proxy solution, the code for "stateless" would never be used and implementers would soon remove that code even if it were added at all. And maybe 6Tisch or something like it would adopt a stateless join proxy solution, not using the "stateful code" at all.

A network / mesh standard that switches between modes based on configuration is of course possible, but that doesn't mean that e.g. Thread or 6tisch nodes all need to carry deadweight code.

So I think we have a possible exception case here; if we know all nodes in a single WPAN network adhere to the same profile (like Thread/6tisch/JupiterMesh/WiSun/others...) and we know this profile defines a single method (stateful or stateless) only, then that's ok as well. The operator will then also know how to configure the Registrar based on the profile. And one site can still have multiple networks with multiple profiles, supported by a single Registrar.

So the MUST here is not really a requirement for interoperability and it can be softened, as long as the Registrar can be configured on site to support only stateful, only stateless, or both.

mcr commented 1 week ago

So I think we have a possible exception case here; if we know all nodes in a single WPAN network adhere to the same profile (like Thread/6tisch/JupiterMesh/WiSun/others...) and we know this profile defines a single method (stateful or stateless) only, then that's ok as well. The operator will then also know how to configure the Registrar based on the profile. And one site can still have multiple networks with multiple profiles, supported by a single Registrar.

I think that for a number of scenarios, that we could allow (demand really) the relevant vertical to specify things. I think that would work for WiSun, application-onboarding in Thread, and the like. For some other verticals, like 6tisch, I think the IETF has to write a MTI, otherwise, the ADs will get confused. Can this advice go into the discovery document? It would wind up as a series of applicability statements.

EskoDijk commented 1 week ago

Ok to mention the profiles / MTI in other documents; and this would impact the discovery-draft also. For constrained JP we could mention "MUST implement both" holds unless a particular profile has selected a single method only, described in some profile / MTI document either in IETF or by an external standard.