[core] Review of draft-ietf-core-oscore-groupcomm-07

[Jim Schaad <[e-mail]>]

* Introduction - para 4 - I think you need to expand some text in this
section to explain why it is that doing a pairwise response is still going
to be considered to be group communication.   This assumes some intimate
details of how multicast works in CoRE that might not be generally known.

* Section 1.1. - Silent Server:  Consider adding the following to the
definition "Given that for CoAP group communications, messages are normally
sent without requesting a confirmation the idea of a server silently acting
on a message is not unreasonable."

* Section 2.2 - next to last paragraph s/instead retrieve/retrieve/ 

* Section 2.2 - last para - this does not make any sense because a server
could do a non-reflection response and you would be unable to deal with it.
I have not see any text to outlaw this behavior.

* Section 2.3 - para #3 - s/from which/with which/

* Section 2.4 - para #3 - The implications of the paragraph are horrendous
in terms of performance of the system.  It basically says that you need to
do some excess processing in order to deal with this issue following a key
roll-over.  If the first message received cannot be validated by the
signature then there is an issue of the question was the message corrupted
or was the id assigned to a new entity and thus a new public key is required
to be pulled down.  

* Section 3 - Have you actually done the testing to see if you can do the
mapping of EdDSA as suggested here?

* Section 3 - are all of these pairwise keys to be tossed away when new keys
are issued for the group?

* Section 3 - clarity is needed on how PIV is going to work for this.  I
would assume that it amounts to a separate context but this is not
completely clear from the text.

* Section 4.3 -  s/and one structure/and  second structure/ or different
structure

* Section 7. - Para 2 - I have a problem with the second sentence.  I think
that you need to make it clear who is supposed to be doing this
retransmission.  It should not be the CoAP system, but it is instead the
application.  That means that a new request could be sent rather than a
retransmission occurring.

* Section 7.1 - Does not reflect the case where pairwise is used.   Ditto
for other sections. - found it in section 8, but that does not seem to be
referenced from section 9 which is "message processing".

* Section 7.4.1 - Must send the group identifier on the first observe
following a rekey operation to all clients.  ---- I am not sure that the
group may not be required at all times - We need to discuss why you think
this would not be true.   Think of the case of two different observe
relations from the client to the same server sent using the same pair of
ports on both devices but with different groups.

* Section 9 - I thought I understood how this is going to work and after
reading this I find that I am wrong.  I am almost positive that I dislike
the compression for sending a request.  

* Section 9.1.1 - I believe that this is just wrong - I would have thought
that this is keep the tag and omit the countersignature.  As written you
have messed up the AEAD and thus one level of security on this.

* Section 10 para 1 - s/as further discussed/as discussed/

* Section 10.1 - should deal with the bilateral version and say that it does
not follow these rules.

* Section 10.4  s/ block-wire/block-wise/

* Section 10.7 has interesting block-wise implications that need to be
explored.