Hi Jim, I don't think that your statement is correct: as far as I understood the oscoap-joining document, the RS is the group manager, while in the pubsub document (even generalizing it and making a group communication profile as Carsten was suggesting) the entity that does group management is the AS2.
I consider these differences a reason to have separate documents, yes, they could be described in the same draft, but I don't see how that simplifies the specifications. One more comment inline. Thanks, Francesca > -----Original Message----- > From: Jim Schaad [mailto:[email protected]] > Sent: den 20 oktober 2017 07:42 > To: [email protected]; draft-palombini-ace-coap- > [email protected] > Cc: [email protected] > Subject: Comments on draft-tiloca-ace-oscoap-joining > > After the interim meeting, I read this document through in order to produce > a review. Instead you are going to get a meta-review. > > I am having a hard to seeing why this document exists in its current form and > it is not some type of simple profile of the pub-sub security draft. > While I am not sure that this document is a sub-set of that document, it > appears to be about 90-99% a sub set of that document. Consider the > following: > > You have both the publisher and subscriber roles as in the pub-sub draft. > > You have an entity which is doing key distribution in the system. For the > pub- > sub draft this is AS2 for you it is the RS, but they are performing the exact > same set of tasks. > Yes, they are performing the same set of tasks on a high level, but they are using the ACE framework differently in practice. For example the publisher and subscriber acquire the keys without using the token. > The pub-sub draft as and endpoint which holds the encrypted messages, in > its place you are using the multi-cast UDP channel. In both cases they are > basically unprotected-untrusted entities to distribute the content message. > The only difference is that in the pub-sub model the RS will also provide > restricted access to publishing which is not enforceable here. > > Both of these documents are missing what I would consider to be core > pieces. > The pub-sub document does initial key distribution, while this document > does not. Neither document does any discussion of how subsequent key > distribution is done to deal with forward and backward security of messages. > > > This document probably needs to define a new relationship, which might be > more generally used, to say - this URL is where you get the security > information for this URL which is published in the directory - esp in the case > of multi-cast address URLs in the resource directory. You might also find > that > the correct answer is not to use a separate resource for each channel, but to > allow for the use of URI path elements to define the security for a resource. > > Jim > _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
