[core] Review of draft-ietf-core-groupcomm-bis-00

[Jim Schaad <[e-mail]>]

I can't see that I have an outstanding review on this document so here is a
new one.

* Section 2.1 - Please make it clear of a client sending a message is part
of an application group.  It is not part of a CoAP group but it is not clear
for an application group.  (It might be useful to just define these things
in terms of CoAP servers except for security groups.)

* Section 2.1 - I believe that a client endpoint is part of a security
group.  Please make this clear either true or false.

* Section 2.1 - s/do not share any resource/do not share any resources/

* Section 2.1 - I still do not like the above statement.  If a resource maps
to a URI-path, /.well-known/core could be part of multiple security groups.
I don't know if this means it is a different application group or what. The
fact that URI-path is not part of the tuple leads me to not know how to deal
with this.

* Figure 1:  I think that you have the grouping in reverse on the
Application Group <-> CoAP group link.  I will admit that I do not use these
a lot so I could be wrong.

* Section 2.2.3 - I don't know that this needs to be included in the
document because I think it might be more of a corner case, but it seems to
me that application groups might also be discovered by doing a query to
/.well-known/core on the multicast address.  That information might be part
of the NoSec security group and thus if the RS knows the answer it could
return it to the client.

* Section 2.2.4 - It looks like you are doing the start/stop of listening
twice.

* Section 2.3.1 - I think we might need to have a discussion if the MAY in
paragraph 3 ought to be upgraded to a SHOULD for traffic purposes.  I.e.
don't send an answer if you don't have anything to say (error) unless you
are required to do so by the application.

* Section 2.3.1 - In the paragraph starting "For multicast CoAP requests", I
got confused when reading this paragraph because it starts dealing with
multicast processing of tokens and then seems for some unknown reason starts
talking about DTLS and TLS which seems to be extraneous.  I think that this
extra information can just be deleted.  (By the way, I don't agree that you
can immediately free up the token after getting a response.  You might end
up sending a request with that token and getting the original response
replayed to you and incorrectly associating things.  I believe that there is
a time out before doing the re-use but I would need to check this in the
CoAP document.  Additionally, this is not a true statement for things like
observe.)

* Section 2.3.1 - " The Token values only have to be unique within the
context of a single CoAP client"  This should really be the context of a
single client - or depending on the implementation - a single source
UDP/Port pair if token processing is different for each port used by a
single client.

* Section 2.3.3 - Bullet 1 in second list - Another difference for a CoAP
client rather than a proxy is that the client can process responses as they
show up and that can also be used as input to the decision of how long to
wait for responses or if a new request needs to be made for additional
responses.

* Section 2.3.3 - Does it make sense to define a new HTTP header for the
purpose of returning the address of the server?

* Section 2.3.3 - Last bullet point - I do not believe that the multicast
scope is something that the client gets to choose.  I think it is part of
choosing what the multicast address is for the CoAP group.  If multiple
addresses are assigned to a CoAP group then the client would have the
ability to choose which address to use.  It is not clear to me how a RD
would return this, but I have not thought about it at all.  Given that you
cannot say FF0X::FD as the address.

* Section 2.3.5 - I think you need to have a paragraph dealing with
unsubscribing to an observe relationship.  I believe that this is always
going to be done via unicast but it would seem that this could be done in
multicast instead.

* Section 2.4.1 - I think you need to justify the addition of admin-local to
the list of supported scopes as this is not part of RFC 7252.

* Section 4 - Reference to COSE needs to be updated to point to the IDs.

* Section 4 - Off the top of my head I don't remember an MAC operations done
by OSCORE, it just uses encryption and signing (for group)

* Section 4 - I think this is a mistake, para 2 says that the result is
encoded as a COSE object, but I am not sure that this should not be a CORE
object.

* Section 5.2.1 - last paragraph - I think that "most recently" is better
than "latest"

* Section 5.2.3 - Bullet 2 - I think that you need some expansion in this
topic.  My first reading was that the alleged sender was tied to the IP
address and not tied to the signature key.  

* Section 5.4 - when used with security, I do not believe that this can do
an amplification attack because the No-Response option is an inner option.

Jim