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