Mercurial > hg > ietf
comparison ace-key-groupcomm-review.txt @ 3:11c0afd7bad2
trying to get into Section 3
author | Henry S. Thompson <ht@inf.ed.ac.uk> |
---|---|
date | Wed, 25 Oct 2023 22:36:22 +0100 |
parents | 92618ff70952 |
children | a88cd2ff0a89 |
comparison
equal
deleted
inserted
replaced
2:4cda788d7ada | 3:11c0afd7bad2 |
---|---|
1 Document: | 1 Document: |
2 Intended RFC status: Proposed Standard | 2 Intended RFC status: Proposed Standard |
3 Review type: artart - Last Call review | 3 Review type: artart - Last Call review |
4 Reviewer: Henry S. Thompson | 4 Reviewer: Henry S. Thompson |
5 Review Date: | 5 Review Date: 2023-10-@@ |
6 IETF Last Call Date: | 6 Result: Ready with Issues |
7 | 7 |
8 Summary: | 8 *Summary* |
9 | 9 |
10 Caveat: I'm not familiar with the group comms family of RFCs or the | 10 Caveat: I'm not familiar with the group comms family of RFCs or the |
11 applications they support, so this review is from an outsider's | 11 applications they support, so this review is from an outsider's |
12 perspective. | 12 perspective. |
13 | 13 |
14 Minor points | 14 *Substantive points* |
15 | 15 |
16 Section @. I note that one of the two referenced examples of candidate | 16 Section 2. I'm seeing an inconsistency in the way the Dispatcher is |
17 discussed. When introduced in the bullet points the last bullet says | |
18 | |
19 "If it consists of an explicit entity such as a pub-sub Broker or a | |
20 message relayer, the Dispatcher is comparable to an _untrusted_ | |
21 on-path intermediary, and as such it is _able to read_ the messages | |
22 sent by Clients in the group." [emphasis added] | |
23 | |
24 But at the end of section 2 we find | |
25 | |
26 "5. The joining node can communicate _securely_ with the other group | |
27 members, using the keying material provided in step 3." | |
28 [emphasis added] | |
29 | |
30 If the Dispatcher is untrusted, how can communication be secure? | |
31 There is no discussion of the Dispatcher in the Security section. | |
32 | |
33 *Minor points* | |
34 | |
35 Section 1. I note that one of the two referenced examples of candidate | |
17 application profiles, "A publish-subscribe architecture for the | 36 application profiles, "A publish-subscribe architecture for the |
18 Constrained Application Protocol (CoAP)" [1], has expired. I'm not | 37 Constrained Application Protocol (CoAP)" [1], has expired. I'm not |
19 sure how much it matters to have reasonably mature examples, but | 38 sure how much it matters to have reasonably mature examples, but |
20 without _some_ good reasons to suppose that there's a community out | 39 without _some_ good reasons to suppose that there's a community out |
21 there waiting to implement this framework, its future does seem a bit | 40 there waiting to implement this framework, its future does seem a bit |
23 explain the lack of progress. | 42 explain the lack of progress. |
24 | 43 |
25 Section 2. This is the first point where the actual connection between | 44 Section 2. This is the first point where the actual connection between |
26 ACE and this document is made clear, that is, that the KDC is the | 45 ACE and this document is made clear, that is, that the KDC is the |
27 Resource Server _per ACE_. Simply adding ", per ACE," to "Resource | 46 Resource Server _per ACE_. Simply adding ", per ACE," to "Resource |
28 Server" in para 2 of Section 1 would do the trick. | 47 Server" in para 2 of Section 1 would fix this for me. |
29 | 48 |
30 Nits | 49 *Nits* |
50 | |
51 Section 1 / Appendix A: The use of REQ[n] and OPT[n] in conjunction | |
52 with REQUIRED and MAY is not explained, nor are they linked to the | |
53 relevant text in Appendix A. There is an oblique reference to this | |
54 practice in para. 4 of Section 1, which could stand to be expanded to | |
55 explain your conventions. | |
56 | |
57 Passim: Please do a thorough spell-check. The following were found in the | |
58 first 4 sections: | |
59 recommeded -> recommended | |
60 memebrs -> members | |
61 specificaton -> specification | |
62 acces -> access | |
63 trasferring -> transferring | |
64 | |
65 ht | |
66 -- | |
31 | 67 |
32 [1] https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-12 | 68 [1] https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-12 |