Re: [core] Review of draft-dijk-core-groupcomm-bis-02

[Esko Dijk <[e-mail]>]

Hello Jim,

Thanks again for your review. Below inline I  have included the authors' responses to your comments, marked [GC]. All items have been addressed in the -03 version.

Esko

> -----Original Message-----
> From: Jim Schaad <[e-mail]> 
> Sent: Tuesday, November 12, 2019 00:18
> To: [e-mail]
> Cc: 'Core WG mailing list' <[e-mail]>
> Subject: Review of draft-dijk-core-groupcomm-bis-02
> 
> Here is a fast read through of the document.  Overall it looks to be a good
> document.
> 
> Jim
> 
> 
> 1.  Abstract needs to note the obsoletes and update actions someplace.  Also
> put into the introduction ( found in section 1.1 - might need to be earlier
> - depends on how the IESG feels).

[GC] Done, and mentioned obsoleted/updated document earlier in Section 1.

> 
> 2. Section 2.1.1 - I like the definition of a group here in many ways.  I am
> wondering if it needs to be extended to deal with the prospective observe
> protocol (which might be below where I am reading) that was discussed in the
> virtual.  In that case we are talking about an endpoint listening on the
> multicast address, but not as a server but looking for responses which
> corollate to a request.
> 
[GC] We have revised the definitions of the three types of groups (now Section 2.1).
For the CoAP group definition, now we more generally say “devices as listeners to that Multicast IP address”. When the text gets even more specific and talks about messages, we mention only a client sending a request over multicast, as in scope for this document.
We can easily extend it to also mention a server sending a response over multicast, as specified in
https://tools.ietf.org/html/draft-tiloca-core-observe-multicast-notifications-02

> 3. Section 2.2.1, para 4 - This criteria does not seem reasonable.  If it
> returns an error and then would return a success this seems to say that
> second response ought to be suppressed.
> 
[GC] We have rephrased the text as follows (now fifth paragraph of Section 2.3.1)
“Any default response suppression by a server SHOULD be performed in a consistent way, such that if a request on a resource produces a Response Code and this response is not suppressed, then a later request on the same resource that produces a response with the same Response Code is also not suppressed.”

> 4. Section 2.2.1 - I think that the section on freeing up a token for
> unicast responses should be updated to deal with the change made in the
> draft-ietf-core-echo-request-tag.
> 
[GC] We have rephrased that paragraph considering the updated client processing in the unicast case (now in Section 2.3.1).
Later in the section, we have added the related paragraph “When securing group CoAP communications with Group OSCORE …”

> 5.  Section 2.3.2 - is the last paragraph misplaced?
[GC] Yes, we have swapped the last paragraph in current Section 2.4.2 and the last paragraph in Section 2.4.1.

> 
> 6. Section 5.2.3 -  I think that this section needs a new title.  It does
> not make any sense to me when I read it.  I think you mean "Countering
> Attacks"
[GC] Changed to “Countering Attacks”.

> 
> 7. Section 5.2.3 - You make some grandiose statements about the fact that
> these attacks are countered without given any idea of how or where to go to
> find out how.
> 
[GC] We have accordingly done a major rewriting of the whole section.

> 8.  Security considerations.   Should there be some type of statement that
> since all messages are non-confirmable, there is now way for a client to
> know if an attacker is capturing the packets for later replay?
> 
[GC] Yes. We have added a new Section 5.3 where we discuss this.

> Nits
> Section 2.1.4, para 3 - s/participating to group/participating in group/
> Section 2.2.1 s/but it MAY suppress this response if selected so by the
> server application/but the server MAY suppress the response if the server
> chooses/
> s/is not standardized yet currently/  either yet or currently but not both
> section 4 s/so still allowing/while still allowing/
> 
[GC] Done


IoTconsultancy.nl  |  Email/Skype: [e-mail]