[core] Review on draft-tiloca-core-multicast-oscoap-01

[Jim Schaad <[e-mail]>]

Here are a few comments on this draft.

Section 1 - "Keying Material" - it is a bit confusing to say "key, key
pairs".   I suggest that this become more detailed on the types of keys -
and perhaps purpose - or maybe just reduce to one item.

Section 1 - "GM" - The sentence starting "A GMC can" should be split into
two as the concepts are different.

Section 1 - "GM" - I think that the word 'may' should not be in these
sentences.  This is what it is responsible for, a group may not use the
services.  That is a different statement.

Section 1 - "GM" - I do not understand what this sentence is trying to say
"Any message exchange with the GM MUST be secured and based on different
secure channels for different endpoints."

Section 1 - "Listener" - Are there cases where a listener may reply to a
multicast message w/ a multicast rather than a unicast message?

Section 1 - "Group response" - Is this a normal term?  Group is implying
multicast to my uneducated mind.

Section 1 - "Source authentication" - suggest the last sentence ends "not
tampered with either by a different group member or by a non-group member".
	
Section 2 - "Multicast communication technology" - The first for instance is
a problem, thisis really an M-to-N situation if you are talking about
"switches".  You should probably change this to "a single switch" so that it
is really 1 not M.

Section 2 - You should probably add a requirement on ordering of messages.
Specifically - there is a requirement that it is possible to determine
ordering of messages coming from a single sender, but it is not a
requirement to be able to determine the correct ordering of messages between
two different senders.  If this is a requirement then it needs to be
incorporated into the data portion of the protocol.

Section 3- para 3 - the last sentence needs to be cleaned up a bit.  It
could be read as saying that two endpoint ids that are in different groups
is precluded.

Section 3 - Note that endpoint ids only need to be assigned to multicasters,
a pure listener that never responds w/ unicast does not need to have an
endpoint id.  This would be protocol specific.

Section 4 - You would have zero or one sender context - depending on if you
would ever respond unicast to a message - protocol dependent.

Section 4 - You would have R recipient contexts.  One for every possible
sender of a message to this endpoint.  This would be M-1 or N-1 for a
multicaster (depending if unicast responses are needed) or M for a listener.

Section 4 - Creation of recipient contexts on demand is an optional item.
The current text reads as mandatory.

Section 4 - Need to update the last paragraph of this section to deal with
the changes in OSCOAP - I assume that Cid is converted into a Group
Identifier.  The question then becomes if this is transmitted as a separate
item or if it is part of the kid when transmitted.  Additionally, how it is
put into the AAD needs to be modified.

Section 5 - Yes - need to be sure to highlight the difference between this
and unicast as re-use of serial numbers might occur without the change of
using the sender context partial IV always.

Section 6.2 - The order of verifying the signature and doing the decryption
does not matter and thus should not be mandated.  It may be that it is
cheaper to do the decryption first as long as the memory constraint is not
so large that decryption in place is needed.  This would allow the cheaper
operation occur first.

Section 6.4 - the mapping rules are not necessarily the same in the final
paragraph of this section.  This is because of the updates to OSCOAP.

Section 7.3 - You need to have a bit of a discussion here about the
difference between a late joining endpoint and a new endpoint that is
joining an existing group.  The in latter case there would not be an issue
w/ serial numbers because a new context is going to be created.

RANT - Please review all 2119 language.  If it does not refer to a byte on
the wire or to a specific step that one of the parities is going to perform,
then it is not appropriate.  Example the MAY in the first paragraph of
section 3.   How would I even think about doing a compliance test for this?


Jim