This is just going to be a high level review on how things are done rather than a detailed review on each line of text.
1. - Go and read that CoRE Pub-Sub update document - you know the one that Klaus and friends have not managed to get written since the model proposal was done way back when. 2. Re-write this to use CoRAL - Yes I know that this makes another dependency on getting it published from the CoRE group, but I don't want to do things multiple times. 3. I think that this document really needs to be able to be used with HTTP/JSON as well as CoAP. If you can get the JSON version of CoRAL from Klaus then this falls out without any work. 4. Are you making it a requirement that the group name be the same as the group identifier assigned by the "group_name" parameter? If so then having some type of title and description would seem to be almost mandatory. 5. There needs to be some parameters around pointing to the correct AS and so forth. The management API may reject because it does not trust the AS. Don't assume that this is a single value for the AS either. 6. You are missing a lot of management detail on the POST to the group node. Some of the things that are missing would be: a) Is the group active or inactive b) How does the server react if you change a the content encryption algorithm, is this a simple re-key operation or is it more complicated c) How does the server react if you change the signature algorithm? This would seem to be a much harder thing to do if the group is not empty or not active as everybody is going to need to re-join. d) Other parameter that are changed may be just as bad as changing the signature algorithm - how the re-key is done jumps immediately to mind. 7. Is there currently any way for a KDC to signal to all of the members that have joined that the key group no longer exists? A DELETE would seem to indicate the need to be able to do this. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace