[core] Review of draft-dijk-core-groupcomm-bis-03

[Jim Schaad <[e-mail]>]

I need still need to review your response to my last review.  This is a
clean review from scratch without reference to my prior one.

Jim



* General - Feel free to ignore this, but I far prefer positive rather than
negative protocol requirements.  Thus in section 2.3.5 - "MUST respond to
this request and not suppress it".  Negative statements are difficult to
test, did you cover every single condition?

* Section 2.1, para 3 - are application groups only those which provide the
resources or do they also include those which use the resources?  It is not
clear from the text which is true.

* Section 2.1, para 4 - does this mean that a group of CoAP servers which
are not in a multicast URI (i.e. not a Group URI) then they cannot be part
of an application group?  This could be a scoping issue where the problem is
that for me Group Communication does not necessarily equal Multicast
Communication.   Think in terms of pub-sub as an alternate backbone.
Another alternative for this is Anycast where you send a message and you
don't know which server it is going to but they are still treated as a
group.   If the issue is scoping then expand some discussion about this in
the introduction.

* Section 2.1, para 5 - I think I understand what you are trying to say
here, however based on the definition of a CoAP group a security group would
likely include endpoints which are not in a CoAP group.  This makes the
one-to-one concept a bit difficult to grok.

* Section 2.1, para 5 - If application groups are really designed to be
non-intersecting, that needs to be part of the definition of an application
group in the previous paragraphs.  I would be surprised if a resource could
not be part of two different application groups so I think this is an
incorrect statement.

* Section 2.1, para 6 - If I read the definitions correctly, then this
requires that each of the first two items could be empty.  That is a message
sent by a client endpoint does not have either an application group or a
CoAP group.  The target it is sending the message to has those properties
however.

* Section 2.1, Figure 2 - I think it would be reasonable to place "Cli2"
into security group 2 as well to show that clients can be in multiple
security groups.

*  Section 2 - you need to put a qualifier for "Group" on all of the title
fields and probably on every usage in the document.  I think you need to
create a new term to cover the "This is more than one" group

* Section 2.2.4 para 2 - the last clause appears to be a repeat

* Section 2.2.4 - does not cover application group maintenance

* Section 2.3.4 - In the bullet that says requests are non-confirmable, I
think it would be reasonable to say that a server SHOULD treat a confirmable
request as if it where non-confirmable.

* Section 2.3.4 - last bullet - I don't know how IPv6 multicast works, but
does this mean that a CoAP group may want to advertise itself at different
scopes so that a client can work its way up from interface-local to
organization-local?  Looks like a pointer to 2..1 w/ a sentence would be
useful here.

* Section 2.3.5 - para  - I am not sure that you can use the same token for
both the multicast and the unicast observe request.  It is going to make a
difference in terms of the sending port that is used by the client.
Otherwise there is the potential that you could get messed up on the code
which deals with token cancelations in the event that the unicast server
does not honor the observe request.

* Section 5.2.1 s/paralizing/paralyzing/

* Section 5..3 - s/Group OSCORE prevents to effectively mount/  ???? I don't
know what this means
	s/Group OSCORE prevents to make any/ ???