Hi, I've just rewriten the JPY message to be an actual CoAP header as discussed at the CORE/IOTOPS meeting on Oct12. I'll post an email to CORE@ and ANIMA@ about that part, where I have a few technical questions.
The result of that effort is at: https://github.com/anima-wg/constrained-join-proxy/pull/42 Now, I'm processing the thread from Esko's WGLC. I did this after since some of the rewrite makes some of the comments obsolete :-) Esko Dijk <esko.d...@iotconsultancy.nl> wrote: ED> 5.2 doc} A Join Proxy MUST implement both. A Registrar MUST implement the doc} stateful mode and SHOULD implement the Stateless mode. ED> Maybe I missed the discussion on this new statement, sorry! Why can't ED> the unconstrained Registrar always implement both modes too? (Code ED> size isn't an issue.) Yeah, I tried to make this argument at the July IETF114 meeting. I think that we agreed with that, and I'll make that change. How about: } A Registrar MUST implement both the stateful mode and the Stateless mode, } but an operator MAY configure it to announce only one. } A Join Proxy MUST implement the stateless mode, but SHOULD implement the } stateful mode if it has sufficient memory. ED> 5.3.1 ED> pledge_content field -> the field is named "content" in the CDDL, not pledge_content. obsolete ED> 6.1.1 ED> The scheme remains coaps -> Seems not? The scheme is coaps+jpy:// obsolete ED> The coaps+jpy scheme is registered is defined in Section 9.2, as per ED> [RFC7252], Section 6.2 -> the "as per ... " part is unclear. Shouldn't we say that the scheme is registered with syntax identical to [RFC7252] Section 6.2 ? Now it's rather fuzzy what is meant. obsolete ED> 6.2.1 ED> Discoverable port numbers are ED> usually returned for Join Proxy resources in the <URI-Reference> of ED> the payload (see section 5.1 of [RFC9148]). -> reference seems wrong - no section 5.1 there? No <URI-Reference> mentioned also. It seems it was section 4.1 of RFC9148 now. ED> 7. ED> In the comparison table, the row "Specification complexity" seems not ED> so relevant anymore given that the Join Proxy must implement both ED> modes. So now it just implements stateless. ED> A "Security" row could be useful - in stateful mode, the Join Proxy ED> is more vulnerable to resource exhaustion attacks. E.g. attacker uses ED> multiple LL addresses and pretends to be N Pledges joining at the ED> same time. Yes, I agree. I've transformed that into a proper markdown table, to adding a new line should be easy. ED> That seems like a more important consideration for the network ED> operator than "Specification complexity". But if people want to ED> leave it as is, I won't object further. okay. ED> 8. doc> It is also pointed out doc> that the encryption in the source is a local matter. Similarly to doc> [RFC8974], the use of AES-CCM [RFC3610] with a 64-bit tag is doc> recommended, combined with a sequence number and a replay window. ED> a bit unclear; "the source" - is that the Join Proxy, and is the ED> encryption that of the header data? (Not DTLS payload.) If possible ED> let's name the entities here and what is encrypted. Agreed, it should be Join Proxy rather than source. doc> In some installations, layer 2 protection is provided between all doc> member pairs of the mesh. In such an environment encryption of the doc> CBOR array is unnecessary because the layer 2 protection already doc> provide it. ED> I disagree here. (Or maybe I don’t understand the issue.) If the JP ED> does not encrypt the header data here, then all the (authenticated) I agree, and I've removed that paragraph. ED> [RFC6690] ED> This should be a normative reference. Without it, the discovery ED> (CoAP) can't be implemented. Done. ED> Appendix A ED> The payload examples do not conform to the CDDL definition. (They ED> are based on the old, pre WG last call format.) Marked as old, which I'll have to redo. ED> General ED> consistency of capitalization of terms - this is not yet ED> applied. E.g. "pledge" vs "Pledge", "JOIN Proxy" vs "Join Proxy" vs ED> "join Proxy" vs "Join-Proxy", "CoAP" vs "coap" and perhaps ED> others. This can also be updated in the future editing phase of ED> course but to me it looks a bit sloppy if the WG doesn't address ED> this. Some other WGs do this at least ;-) I think that I got them all. ED> 2. doc> The term "installation network" refers to all devices in the doc> installation and the network connections between them. The term doc> "installation IP_address" refers to an address out of the set of doc> addresses which are routable over the whole installation network. ED> both terms are never used again in the document. So suggest to remove ED> this text - it is not needed. I agree. ED> 5.3.1 ED> any kind of of per session -> typo 'of of' ED> 6.1.1 ED> The coaps+jpy scheme is registered is defined -> is registered and defined ? ED> 6.1.2 ED> Figure 6: Example of Registrar announcing two services -> isn't it 3 services here? 3 ports are advertised. ED> 9.2 ED> The text contains "{{stateless-jpy}}" which should be a section reference. I think I got all of these. ED> 13.1 ED> [RFC9032] is not a normative reference as far as I can see. It is ED> only mentioned in 6.3.2 and this says that 6tisch is not even using ED> the present protocol. fixed. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
