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

Jim Schaad <ietf@augustcellars.com> Mon, 11 November 2019 23:17 UTC

From: Jim Schaad <ietf@augustcellars.com>
To: draft-dijk-core-groupcomm-bis@ietf.org
CC: 'Core WG mailing list' <core@ietf.org>
Date: Mon, 11 Nov 2019 15:17:34 -0800
Message-ID: <004501d598e6$34bd7830$9e386890$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
Thread-Index: AdWYOY3vmCyjz4VYRmuWEjaTvSz+EA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/fme0kaeiiroi6ETKxD3yoD_MiyE>
Subject: [core] Review of draft-dijk-core-groupcomm-bis-02
Precedence: list

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).

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.

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.

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.

5.  Section 2.3.2 - is the last paragraph misplaced?

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"

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.

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?

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/

[core] Review of draft-dijk-core-groupcomm-bis-02 Jim Schaad
Re: [core] Review of draft-dijk-core-groupcomm-bi… Esko Dijk