[core] Re: Gorry Fairhurst's Discuss on draft-ietf-core-groupcomm-bis-15: (with DISCUSS and COMMENT)

[Esko Dijk <[e-mail]>]

Hello Gorry,

Thanks for your extensive review! Below, inline are the detailed replies 
to your comments by the authors.
A GitHub PR where we have addressed your comments is available at [PR].

Unless any concern is raised, we plan to soon merge this PR (and the 
other ones related to other received reviews) and to submit the result 
as version -16 of the document.

best regards,
Esko & Marco

[PR] https://github.com/core-wg/groupcomm-bis/pull/59 <Hello 
Éric,,,Thanks for your review! Below, inline are the detailed replies to 
your comments by the authors.,A GitHub PR where we have addressed your 
comments is available at [PR].,,Unless any concern is raised, we plan to 
soon merge this PR (and the other ones related to other received 
reviews) and to submit the result as version -16 of the document.,,best 
regards,,Esko & Marco,,[PR] 
https://github.com/core-wg/groupcomm-bis/pull/59>


On 30-9-2025 14:14, Gorry Fairhurst via Datatracker wrote:
> Gorry Fairhurst has entered the following ballot position for
> draft-ietf-core-groupcomm-bis-15: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for preparing this document on multicast transport. This is a topic I
> have worked with over many years, and I know this touches on a wide range of
> issues and trade-offs. The following topics are blocking DISCUSS points (some
> may be trivial to address, but I do wish to understand first if I am correctly
> understanding what is proposed and to discuss each point).
>
> As noted in
> https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
> a DISCUSS ballot is a request to have a discussion on the points below; I
> really think that the document would be improved with a change here, but can be
> convinced otherwise.
>
> 1. DISCUSS - Status as PS
>
> RFC 7390 was EXPERIMENTAL. The text describing the changes to the document that
> this obsoletes and replaces [RFC7390] does not describe any implementation or
> reason why this document is to be published as PS.
>
> Alas, I did not see a stated reason why this was published as experimental. I
> do not see any reason in the current document that explains why the level of
> interoperability and experience would support publication on the standards
> track. - If the intent is to publish as PS, is the review sufficient? - What is
> the level of review and implementation experience for the final specification
> set out in rev -14?

Please find below our answer to each point. We hope this helps to 
resolve this point, or as input to the discussion.

  *

    Why is RFC 7390 Experimental?

      o Details are available
        athttps://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ballot/
      o In short: the main reason is that, at the time when RFC 7390 was
        written and published, there was no security solution and no
        implementation experience for CoAP group communication. The
        protocol for configuring CoAP groups through JSON was also an
        experiment, which eventually was not implemented and is not
        considered in the present document (see the fourth paragraph of
        Section 2.2.2).
  *

    RFC 7390 did not say what would be needed to have a Proposed
    Standard out of it.

      o As also tracked
        inhttps://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ballot/,
        the expectation for following-up with a Proposed Standard was to
        see the addition of a security solution and implementation
        experience.
      o The security solution is now available as the Group OSCORE
        security protocol (see draft-ietf-core-oscore-groupcomm and
        Section 5 of the present document).
      o The implementation experience largely occurred as per the three
        major implementations listed in Section 1. (As suggested by
        Mohamed Boucadair in his review, we are going to remove those
        references from the document, and instead make them available in
        the section “Additional resources” in the Datatracker page.)
        Furthermore, additional experience came up from the
        implementation of the Group OSCORE security protocol in itself,
        for which two mature implementations have been listed
        athttps://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-27#section-13
  *

    This document is not saying how/why it is justified to move to
    Proposed Standard.

      o Building on the points above, the expectations that were set at
        the time of publication of RFC 7390 have been met. It does not
        seem necessary to explicitly elaborate about this in the present
        document.
  *

    Have there been enough review?

      o We believe so, and so it was assessed upon requesting publication.
  *

    Has there been enough implementation experience and coverage?

      o Yes; further building on the implementation experience for RFC
        7390, implementations have built on this document and used the
        result for further implementing and testing the Group OSCORE
        security protocol (see draft-ietf-core-oscore-groupcomm and
        Section 5 of the present document), for which there are at least
        two existing interoperable implementations
        (seehttps://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-27#section-13)


> ----
> 2. DISCUSS - updates to RFC 7252
>
> This document specifies updates to RFC 7252, and although section 1.3 refers to
> relevant sections in the new document, I found it hard to relate these changes
> to the sections that appear in RFC 7252. Please can you explain which specific
> sections (or text) in that existing RFC will be changed as a result of
> publication of this document as an RFC?
>
> - I also could not find a mention of "CoAP group creation"?

Let’s take this comment in two parts.

*Section pointers*

The current references in Section 1.3 of the present document are to 
later sections of the present document, and those sections do include 
references to the relevant sections of the updated RFC 7252.

To be more explicit, as suggested, in Section 1.3 we have added specific 
pointers that refer to sections of the updated documents RFC 7252 and 
RFC 7641.

Specifically, we have rephrased as below:

OLD

      * It updates the request/response model for group communication,
        as to response suppression (see Section 3.1.2) and token reuse
        time (see Section 3.1.5).

NEW

      *

        With reference to Section 8.2 of [RFC7252], it updates the
        request/response layer for group communication, as to response
        suppression (see Section 3.1.2 of the present document).

      *

        With reference to Section 5.3.1 of [RFC7252], it updates the
        token requirements on request/response matching, as to token
        reuse time (see Section 3.1.5 of the present document).

OLD

      * It updates the freshness model and validation model to use for
        cached responses (see Section 3.2.1 and Section 3.2.2).

NEW

      * With reference to Section 8.2.1 of [RFC7252], it updates the
        freshness model and validation model to use for cached responses
        (see Section 3.2.1 and Section 3.2.2 of the present document).

OLD

      * It defines the measures against congestion risk specified in
        [RFC7252] to be applicable also to alternative transports other
        than IP multicast and defines additional guidelines to reduce
        congestion risks (see Section 3.6), including new values for the
        transmission parameter DEFAULT_LEISURE that account for secure
        communication with Group OSCORE (see Section 3.6.1).

NEW

      * With reference to the measures against congestion risk specified
        in Sections 5.2.3, 8.1, 8.2 and 11.3 of [RFC7252], it defines
        such measures to be applicable also to alternative transports
        (other than IP multicast) and defines additional requirements to
        reduce congestion risks (see Section 3.6 of the present
        document). It also defines new values for the transmission
        parameter DEFAULT_LEISURE that account for secure communication
        with Group OSCORE (see Section 3.6.1 of the present document).

OLD

      * It explicitly allows the use of the IPv6 multicast address
        scopes realm-local (3), admin-local (4), and global (E). In
        particular, it recommends that an IPv6 CoAP server supports at
        least link-local (2), admin-local (4), and site-local (5) scopes
        with the “All CoAP Nodes” multicast CoAP group (see Section
        3.9.1). Also, it recommends that the realm-local (3) scope is
        supported by an IPv6 CoAP server on a 6LoWPAN node (see Section
        3.9.1).

NEW

      * It explicitly allows the use of the IPv6 multicast address
        scopes realm-local (3), admin-local (4), and global (E). In
        particular, with reference to Section 12.8 of [RFC7252], it
        recommends that an IPv6 CoAP server supports at least the
        link-local (2), admin-local (4), and site-local (5) scopes with
        the “All CoAP Nodes” IPv6 multicast addresses (see Section 3.9.1
        of the present document). Also, it recommends that the
        realm-local (3) scope is supported by an IPv6 CoAP server on a
        6LoWPAN node (see Section 3.9.1 of the present document).

OLD

      * It defines the use of the CoAP Observe Option in group requests,
        for both the GET method and the FETCH method [RFC8132], together
        with normative behavior for both CoAP clients and CoAP servers
        (see Section 3.7).

NEW

      * With reference to Sections 3 and 4 of [RFC7641], it defines the
        use of the CoAP Observe Option in group requests, for both the
        GET method and the FETCH method [RFC8132], together with
        normative behavior for both CoAP clients and CoAP servers (see
        Section 3.7 of the present document).

*On “CoAP group creation”*

RFC 7390 uses “group creation” in Section 2.6.2.3 and “group membership 
creation” in Section 2.6.2.4. When doing so, it was indeed referring to 
the creation of CoAP groups, which have the same meaning both in RFC 
7390 and in the present document.

Also, both instances are within Section 2.6 “Membership Configuration” 
of RFC 7390, which Section 2.2.2 “Group Creation and Membership” of the 
present document refers to as quoted below:

    The IETF does not define a mandatory protocol to accomplish CoAP
    group creation. [RFC7390] defined an experimental protocol for
    configuring memberships of CoAP groups for unsecured group
    communication, based on JSON-formatted configuration resources. The
    experiment is concluded as showing that the protocol has not been
    considered for deployment and use.

The quoted paragraph specifically refers to the creation of CoAP groups, 
i.e., the type of group discussed in the first five paragraphs of 
Section 2.2.2 of the present document.

After that text, group creation is discussed also for the other types of 
groups, i.e., application groups and security groups.



> ---
> 4. DISCUSS
> Section 2.2.2
> /The part of the process that involves secure distribution of group security
> material MAY use standardized communication with a Group Manager as  defined in
> Section 5./ - Why is this a MAY? ought this to be a SHOULD? - It seems to lack
> context to make the decision and isn't it best pactice to recommend use of
> secure methods?

Group OSCORE is the default and only available solution for secure CoAP 
group communication at the moment, while potential alternatives are even 
out of scope.

That said, the distribution of group security material has to happen and 
(as already stated) it has to be secure and based on an entity acting as 
Group Manager.

As long as it happens, such distribution can be based on different 
(standardized) approaches, which might not necessarily require 
communication on the wire.

Neither the present document nor the Group OSCORE security protocol is 
devoted to, or requires, any approach in particular. However, as a 
relevant example, the later Section 5.1 refers to the approach specified 
in draft-ietf-ace-key-groupcomm-oscore.

We have made the quoted sentence simpler and rephrased it as below.

OLD

    The part of the process that involves secure distribution of group
    security material MAY use standardized communication with a Group
    Manager as defined in Section 5.

NEW

    The part of the process that involves secure distribution of group
    security material for Group OSCORE is entrusted to the Group Manager
    responsible for the security group (see Section 5).



> ---
> 5. DISCUSS
> Section 3 (Please explain the multicast addressing model).
>
> I think (from my reading) refers to the ASM model. I see text in  RFC 7390 that
> clearly states: "   CoAP group communication will run in the Any Source
> Multicast (ASM) mode [RFC5110] of IP multicast operation.  This means that
> there is no restriction on the source node that sends (originates) the CoAP
> messages to the IP multicast group.  For example, the source node may or may
> not be part of the IP multicast group.  Also, there is no restriction on the
> number of source nodes." - I do not see equivalent text in this document. I'd
> like to understand if this still applies and can be included, or if not, what
> model ought to be described?

Indeed the ASM mode is intended. Actually, it is already mentioned in 
Section 1.1 “Scope” (just like in the equivalent Section 1.2 of RFC 
7390). That is, Section 1.1 says:

    Only the Any Source Multicast (ASM) mode [RFC5110] of IP multicast
    operation is in scope.

In order to address the review from Roman Danyliw, we have updated the 
sentence to refer to RFC 1112 and RFC 8085 instead of to RFC 5110, thus 
avoiding a downref. That is:

NEW

    Only the Any Source Multicast (ASM) mode of IP multicast operation
    is in scope, as defined in [RFC1112] and referred by that name in
    [RFC8085].



> ---
> 6. DISCUSS
> Section 3.1.3 - is recovery totally optional?
> /To this end, CoAP clients can rely on the following two
>     approaches./ ... MAY... MAY...
> - I am unsure what is intended! ... and how will this be interoperable?
> - I wonder if the intent was to specify a recommended default (SHOULD) and then
> suggest an alternative? - Please propose text or explain more.

Quoting more text for context:

    Group requests sent over IP multicast generally have much higher
    loss rates than messages sent over unicast, particularly in
    constrained networks. Therefore, it is more urgent to have a
    strategy in place for handling the loss of group requests than the
    loss of unicast responses. To this end, CoAP clients can rely on the
    following two approaches.

    The first approach is the default, used in case there is no explicit
    preference of the implementer. It is supported already by all CoAP
    stacks. The application in this case implements a custom
    retransmission logic that MAY trigger a new API request for
    transmission (of a CoAP request) to the CoAP stack, …
    …
    The second approach that MAY be implemented requires specific
    support in the CoAP stack. The application layer in this case also
    implements a custom retransmission logic that MAY trigger a new API
    request to the stack if less responses than expected were received. …

*How will this be interoperable?*

The CoAP specification (RFC 7252) allows any/all of these approaches. 
Also, this is local behavior at a client, i.e.:

  *

    It is up to the client whether to use an approach at all, or which
    approach to use.

  *

    The client can use either approach in a mixed way, e.g., by deciding
    on a per request-basis and depending on the targeted resource,
    possibly according to a local configuration.

>From the point of view of the recipient server(s), the above occurs 
seamlessly. That is, a server is anyway able to handle the received 
request, irrespective of the exact approach taken by the client for 
repeating the request. So interoperability is guaranteed.

We do not think that it is needed to update the document about this point.

*Recommending a default*

As already noted in the text, the first approach is available in CoAP 
stacks, hence it is defined to be the default one, absent preferences 
for using the second approach.

We have updated the text by adding a SHOULD, to mark the first approach 
as the default one to use in case there is no preference/reason to use 
the second approach (i.e., it SHOULD be used in case there is no 
preference).

Also, it is good to explicitly say that a client “MAY” repeat a group 
request in the first place. Instead, two instances of “MAY” can actually 
be expressed as “can”. Overall, we have rephrased as below.

OLD

    To this end, CoAP clients can rely on the following two approaches.

    The first approach is the default, used in case there is no explicit
    preference of the implementer. It is supported already by all CoAP
    stacks. The application in this case implements a custom
    retransmission logic that MAY trigger a new API request for
    transmission (of a CoAP request) to the CoAP stack, if less
    responses than expected were received. …

    The second approach that MAY be implemented requires specific
    support in the CoAP stack. The application layer in this case also
    implements a custom retransmission logic that MAY trigger a new API
    request to the stack if less responses than expected were received. …

NEW (emphasis mine)

    To this end,*a CoAP client MAY repeat a group request by relying*on
    the following two approaches.

    The first approach is*supported already by all CoAP stacks and is
    used by default. That is, it SHOULD be used in case the implementer
    has no explicit preference or reason to use the alternative approach
    described further below. When using this first approach,
    the*application implements a custom retransmission logic
    that*can*trigger a new API request for transmission (of a CoAP
    request) to the CoAP stack, if less responses than expected were
    received. …

    The second approach*requires specific support in the CoAP stack and
    MAY be implemented. When using this second approach, the*application
    layer also implements a custom retransmission logic that*can*trigger
    a new API request to the stack, if less responses than expected were
    received. …



> ---
> 7. DISCUSS
> 3.1.5.  Token Reuse
> / A preferred solution to meet this requirement is to generate a new unique
> Token for every new group request, such that a Token value is never reused.  /
> - I do not understand the sentence highlighted above, when stated as a part of
> a PS. Is this intended to be the WG recommendation or not? - I wonder if the
> intent was to specify a recommended default (SHOULD)? Later it states: /Thus, a
> client may reuse a
>     Token value after it has been freed up, as discussed above and
>     considering a reuse time greater than MIN_TOKEN_REUSE_TIME. /
> - ought this to be a MAY or SHOULD?
> This is followed by:
> /Another method to more easily meet the above constraint is to instantiate
> multiple CoAP clients at multiple UDP ports on the same host.  The Token values
> only have to be unique within the context of a single CoAP client, so using
> multiple clients can make it easier to meet the constraint./ - Please clarify
> what the intent is. If this document is to be published as a PS, it ought to
> provide clear guidance in RFC2119 language about what is required for an
> interoperable implementation.

There are two truly normative requirements to consider, which are 
already stated in the referred Section 3.1.5:

  *

    The time between reuse of Token values for different group requests
    MUST be greater than MIN_TOKEN_REUSE_TIME (see the second paragraph
    in this section).

  *

    If secure binding between requests and responses is not ensured,
    then a client MUST follow the Token processing requirements as
    defined in RFC 9175 (see the second from last paragraph in this
    section).

Other statements here are not prescriptive; they just highlight 
possible, legitimate behaviors and clarify that those behaviors are 
appropriate. In particular, they do not prevent interoperability.

We have rephrased those to simply state facts:

OLD

    A preferred solution to meet this requirement is to generate a new
    unique Token …

NEW

    To meet this requirement, a client can simply generate a new unique
    Token …

OLD

    Thus, a client may reuse a Token value …

NEW

    Thus, a client can safely reuse a Token value …

OLD

    Another method to more easily meet the above constraint is to
    instantiate multiple CoAP clients at multiple UDP ports on the same
    host. The Token values only have to be unique within the context of
    a single CoAP client, so using multiple clients can make it easier
    to meet the constraint.

NEW

    An alternative method that meets the requirement above consists in
    instantiating multiple CoAP clients at multiple UDP ports on the
    same host. This is consistent with what is defined in Section 5.3.1
    of [RFC7252], i.e., Token values currently in use only have to be
    unique for a given source/destination endpoint pair.


> ---
> 8. DISCUSS
> Section 3.2.2.1. ETag Option in a Group Request/Response
> /Finally, the recommended strategy is for the servers to generate unique ETags
> as specified below./ - So it describes options and concludes you can do other
> things, this seems weirdly indecisive at the start and suddenly makes normative
> requirements. - Please clarify what the intent is. If this document is to be
> published as a PS, it ought to provide clear guidance in RFC2119 language about
> what is required for an interoperable implementation.

The text before the quoted sentence is all about behavior on the client 
side.

The quoted sentence introduces behavior on the server side, which is 
elaborated in the next paragraph.

For clarity, we have rephrased as below.

OLD

    There are various strategies to avoid problems caused by identical
    ETag values: one strategy is for a client to repeat a request if a
    particular server returned 2.03 (Valid) with an ETag value that is
    not in the client’s cache (for that server). The repeated request
    excludes the “duplicate” ETag, and it may be a group request or a
    unicast request to the particular server. Another strategy is to
    mark a cached ETag value as “duplicated - not to be used for
    revalidation” as soon as another server responds with the same ETag
    value. Finally, the recommended strategy is for the servers to
    generate unique ETags as specified below.

    A server endpoint MUST process an ETag Option in a GET or FETCH
    group request in the same way it processes an ETag Option for a
    unicast request. A server endpoint that includes an ETag Option in a
    response to a group request SHOULD construct the ETag Option value
    in such a way that the value will be unique to this particular
    server with a high probability. …

NEW

    A client that uses the ETag Option for validating stored responses
    SHOULD perform the following actions, in order to avoid problems
    caused by identical ETag values.

      * The client repeats a request if a particular server returned
        2.03 (Valid) with an ETag value that is not in the client’s
        cache (for that server). The repeated request excludes the
        “duplicate” ETag value. It can be either a group request or a
        unicast request to the particular server.
      * The client marks a cached ETag value as “duplicated - not to be
        used for revalidation” as soon as another server responds with
        the same ETag value.

    A server endpoint MUST process an ETag Option in a GET or FETCH
    group request in the same way it processes an ETag Option for a
    unicast request. A server endpoint that includes an ETag Option in a
    response to a group request SHOULD construct the ETag Option value
    in such a way that the value will be unique to this particular
    server with a high probability. …


> ---
> 9. DISCUSS
> Section  3.6.  Congestion Control
> /Therefore, both the
>     sending of CoAP group requests and the sending of the unicast CoAP
>     responses to these group requests should be conservatively
>     controlled./
> - Why is this not a SHOULD, as per RFC 8085?
> - Why are the following statements not all normative requirements using  RFC
> 2119 language? - including: /The transmission parameter DEFAULT_LEISURE may be
>        used to define a Leisure period when it cannot be computed
>        otherwise./
> - Why is this not the recommendation, is there another mitigation that can
> satisfy this need? - and: /   Independently of the transport used, additional
> guidelines to reduce congestion risks defined in this document are as follows:/
> - If these are normative requirements, which I agree they ought to be based on
> RFC98085 etc, then these are not "guidelines", but requirements, please could
> you change this word?

Taking the points separately:

*- Why is this not a SHOULD, as per RFC 8085?*

We have rephrased as below.

OLD

    … should be conservatively controlled.

NEW

    … SHOULD be conservatively controlled.

*- Why are the following statements not all normative requirements using 
RFC 2119 language? - including: /The transmission parameter 
DEFAULT_LEISURE may be used to define a Leisure period when it cannot be 
computed otherwise./*

The following paragraph intentionally uses “may”, since the requirement 
is not new but rather inherited from RFC 7252, so it is not new behavior:

    A server may choose not to respond to an IP multicast request if
    there is nothing useful to respond, e.g., error or empty response
    (see Section 8.2 of [RFC7252]).

The following paragraph intentionally uses “should”, since the 
requirement is not new but rather inherited from RFC 7252, so it is not 
new behavior:

    A server should limit the support for IP multicast requests to
    specific resources where multicast operation is required (Section
    11.3 of [RFC7252]).

Actually, consistent with a comment in the review from Mohamed Boucadair 
about Section 3.1.1, we have updated the following two paragraphs in 
Section 3.6 to not use normative language, since the described behavior 
is not new but rather already defined in the referred RFC 7252 and 
inherited in the present document. That is:

OLD

      *

        An IP multicast request MUST be Non-confirmable (Section 8.1 of
        [RFC7252]).

      *

        A response to an IP multicast request SHOULD be Non-confirmable
        (Section 5.2.3 of [RFC7252]).

NEW

      *

        An IP multicast request must be Non-confirmable (see Section 8.1
        of [RFC7252]).

      *

        A response to an IP multicast request should be Non-confirmable
        (see Section 5.2.3 of [RFC7252]).

The following sentence intentionally uses “should”, since the 
requirement is not new but rather inherited from RFC 7252 (also phrased 
as “should”), so it is not new behavior:

    A server does not respond immediately to an IP multicast request and
    should first wait for a time that is randomly picked within a
    predetermined time interval called the Leisure (Section 8.2 of
    [RFC7252]).

We have updated the following sentence to use “MAY” instead of “may”: 
while the requirement is not new but rather inherited from RFC 7252, the 
present document is updating the calculation for DEFAULT_LEISURE in 
Section 3.6.1:

OLD

    The transmission parameter DEFAULT_LEISURE may be used to define a
    Leisure period when it cannot be computed otherwise.

NEW

    The transmission parameter DEFAULT_LEISURE MAY be used to define a
    Leisure period when it cannot be computed otherwise (see Section 3.6.1).

We have also extended the text right before the first bullet list, to 
make it clear that the requirements are defined in RFC 7252 but apply 
here too.

OLD

    CoAP [RFC7252] reduces IP multicast-specific congestion risks
    through the following measures:

NEW (emphasis mine)

    CoAP [RFC7252] reduces IP multicast-specific congestion risks
    through the following measures,*which the present document inherits
    and extends as appropriate*:

The following sentence intentionally uses “may”, since the requirement 
is not new but rather inherited from RFC 7252 (also phrased as “may”), 
so it is not new behavior:

    Note that the transmission parameter values for NSTART,
    DEFAULT_LEISURE, and PROBING_RATE may be configured to values
    specific to the application environment (including dynamically
    adjusted values); however, the configuration method is out of the
    scope of this document. This is unchanged from Section 4.8.1 of
    [RFC7252].

*- Why is this not the recommendation, is there another mitigation that 
can satisfy this need?*

Just like in the inherited requirement from Section 8.2 of RFC 7252, MAY 
(instead of SHOULD) is used here too as to employing DEFAULT_LEISURE 
when a Leisure period cannot be otherwise computed.

(The next comment in this review is specifically about why “MAY” instead 
of “SHOULD” or “MUST”)

*- and: / Independently of the transport used, additional guidelines to 
reduce congestion risks defined in this document are as follows:/*
*- If these are normative requirements, which I agree they ought to be 
based on RFC98085 etc, then these are not “guidelines”, but 
requirements, please could you change this word?*

Yes; we have changed “additional guidelines” to “additional requirements”

This applies to this instance in Section 3.6 and to the instance in 
Section 1.3.



> ---
> 10. DISCUSS
> Section 3.6.1.  Default Leisure Updates
>   /If the Leisure is not computed or configured, the default value
>     DEFAULT_LEISURE MAY be used./
> - I'd like to understand how this can be used to improve scaling of the method.
> If this document is to be published as a PS, it ought to provide clear guidance
> in RFC2119 language about what is required for safe operation, why is this not
> MUST or at least SHOULD (stating why this is important).

The original requirement in Section 8.2 of RFC 7252 says:

    If a CoAP endpoint does not have suitable data to compute a value
    for Leisure, it MAY resort to DEFAULT_LEISURE.

While Section 3.6.1 of the present document is updating the specific 
method for computing DEFAULT_LEISURE, it was not meant to change the 
fact that, absent a better computation method, DEFAULT_LEISURE “MAY” be 
used as a configured/preconfigured value.

We have rephrased as below:

OLD

    If the Leisure is not computed or configured, the default value
    DEFAULT_LEISURE MAY be used.

NEW

    If the Leisure is not computed, then a configured/predefined value
    is used, which MAY be the default value DEFAULT_LEISURE in case no
    better or more suitable value is known.

Note that the*use*of Leisure (irrespective of the specific value) is a 
SHOULD requirement inherited from Section 8.2 of RFC 7252 (see Section 
3.6 of the present document).

On the importance of having a DEFAULT_LEISURE, it is simply because 
there is a defined fallback value available to consider for the Leisure 
time period (building on reasonable assumptions to determine that). 
Hence, a server can send a response to a group request with reasonable 
chances for that response to reach the client, instead of colliding with 
the responses to the same group request from other servers.

The above was the main reason for RFC 7252 to introduce the concept of 
Leisure time period in its Section 8.2, irrespective of its value.



> ---
> 11. DISCUSS
> Section 3.7.  Observing Resources
> /When responding, a server SHOULD apply the Leisure period defined in Section
> 8.2 of [RFC7252]./ - Please explain why this is not MUST in this case? (if it
> were SHOULD how will the equivalent response scaling be achieved to satisfy the
> congestion control requirements?)

Consistent with the corresponding requirement from Section 8.2 of RFC 
7252, Section 3.6 of the present document says (emphasis mine):

    A server does not respond immediately to an IP multicast request
    and*should*first wait for a time that is randomly picked within a
    predetermined time interval called the Leisure (Section 8.2 of
    [RFC7252]).

Section 3.7 focuses on responses to a group request that are 
specifically Observe notifications. This is not different from the case 
where responses are not Observe notifications, with respect to the 
replying server adhering with the requirement of using a Leisure time 
period.

Hence the choice of the word “SHOULD”, here normative because it is a 
new behavior, i.e., it was not defined in RFC 7641 that did not consider 
group communication with Observe for CoAP.

However, it is good to update the sentence to explicitly say that 
DEFAULT_LEISURE, if used, is computed as defined in Section 3.6.1 of the 
present document.

OLD

    When responding, a server SHOULD apply the Leisure period defined in
    Section 8.2 of [RFC7252].

NEW

    When responding, a server SHOULD apply the Leisure period defined in
    Section 8.2 of [RFC7252] (if DEFAULT_LEISURE is used, it is computed
    as defined in Section 3.6.1 of this document).



> ---
> 12. DISCUSS
> Section 3.7.
> /A server SHOULD have a mechanism to verify the aliveness of its
>     observing clients and the continued interest of these clients in
>     receiving the Observe notifications. /
> - what does SHOULD have mean?
> - Is this: /A server SHOULD verify.../?

We have rephrased for clarity and quoted explicitly the content from 
Section 4.5/7 of RFC 7641. There's now a MUST requirement added for the 
overall client aliveness validation which is strictly speaking a new 
requirement now for the groupcomm Observe case; hence "MUST".

It builds upon the already-present requirements in Section 4.5 and 7 of 
RFC 7641, as a way to satisfy the new MUST requirement.

OLD

    A server SHOULD have a mechanism to verify the aliveness of its
    observing clients and the continued interest of these clients in
    receiving the Observe notifications. This can be implemented by
    sending notifications occasionally using a Confirmable message (see
    Section 4.5 of [RFC7641] for details).

NEW

    Throughout the lifetime of an observation, a server MUST verify the
    aliveness of its observing clients and the continued interest of
    these clients in receiving the Observe notifications. To this end,
    the server occasionally sends a notification to a given observing
    client in a Confirmable message (see Section 4.5 and 7 of [RFC7641]
    for details).



> ---
> 13. DISCUSS
> /Furthermore, a server (member of a targeted CoAP group) that needs to respond
> to a group request with a particularly large resource can use lock-wise
> transfer (Block2 Option) at its own initiative, to limit the size of the
> initial response./ - This seems a very plausible method to use. Why is this not
> recommended (SHOULD), since it seems to align with other congestion control
> requirements defined in this document?

RFC 7949 did not pose any requirement about this behavior.

Building on this comment, we have rephrased as below and introduced a 
“SHOULD” for this particular multicast case. The exception case is also 
specified (in context of constrained clients where the server 
implementer knows about the client constraints a-priori).

OLD

    Furthermore, a server (member of a targeted CoAP group) that needs
    to respond to a group request with a particularly large resource can
    use block-wise transfer (Block2 Option) at its own initiative, to
    limit the size of the initial response. That is the case when a
    client sends a multicast GET or FETCH request that does not include
    a Block2 Option.

NEW

    Furthermore, a server (member of a targeted CoAP group) that needs
    to respond to a group request with a particularly large resource can
    use block-wise transfer (Block2 Option) at its own initiative, to
    limit the size of the initial response. That is the case when a
    client sends a multicast GET or FETCH request that does not include
    a Block2 Option.*In such a situation, unless the implementer of the
    server is aware that its clients do not support Block-wise transfer,
    the server SHOULD use Block-wise transfer at its own initiative.*



> ---
> 14. DISCUSS
> Section 3.9.1.
> /IPv6 multicast MAY be supported in a network only for a limited scope. /
> - I'm unsure what the MAY permits and what is also allowed. is this really
> normative (constraining something) or simply explanation, so it might be /may/?

We have rephrased as below.

OLD

    IPv6 multicast MAY be supported in a network only for a limited scope.

NEW

    A network might support IPv6 multicast only for a limited scope.



> ---
> 15. DISCUSS
> Section 5.1.  Group OSCORE
> /As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint.../
> What does lower case recommended here? I see this is put forward as "PS", does
> this not define requirements for this case? The section later says: /If
> security is required, / is this intended to be /The security method described
> in this section requires.../ ? and /   For secured group communication (see
> Section 5), the maintenance
>     operations of the protocol Group OSCORE
>     [I-D.ietf-core-oscore-groupcomm] MUST be implemented as well.
> /
> - Why is this a requirement only to implement? Is this also a requirement to
> process?
> ---

On the first part of the comment, the current text has some bad wording.

The Group Manager and joining process specified in 
draft-ietf-ace-key-groupcomm-oscore are just a possible option. In fact, 
draft-ietf-core-oscore-groupcomm simply mentions it as an example, as it 
is not a requirement.

We have rephrased as below, also consistent with 
draft-ietf-core-oscore-groupcomm.

OLD

    As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint
    can join an OSCORE group by using the method described in
    [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework
    for Authentication and Authorization in constrained environments
    [RFC9200].

NEW

    As mentioned in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint
    can join an OSCORE group through the realization of a Group Manager
    specified in [I-D.ietf-ace-key-groupcomm-oscore] and based on the
    ACE framework for Authentication and Authorization in constrained
    environments [RFC9200].

On the second part of the comment: indeed! We have rephrased as below.

OLD

    For secured group communication (see Section 5), the maintenance
    operations of the protocol Group OSCORE
    [I-D.ietf-core-oscore-groupcomm] MUST be implemented as well.

NEW (emphasis mine)

    For secured group communication (see Section 5), the maintenance
    operations of the protocol Group OSCORE
    [I-D.ietf-core-oscore-groupcomm] MUST be*performed*as well.

(Here, the requirement to perform the operations implies that they must 
also have been implemented.)


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> Please consider the following comments for draft-ietf-core-groupcomm-bis:
>
> Thank you for the TSV-ART review by Magnus, it raised many issues that were
> important to me as a WIT AD. I see the document was revised following this (rev
> -14), some of my comments below relate also to these topics as seen in rev -14.
>
> Section 2.2.2
> /   For unsecure group communication using the NoSec mode (see
>     Section 4), there is no security material to be provided, hence there
>     is no security group for CoAP endpoints to participate in./
> - For me, this text is not well constructed, because I earlier understood that
> NoSec mode was only permitted under very specific uses and I'd expected this to
> be clear here also and for the avoidance of any doubt I'd expect this also to
> be clear in the introduction to section 4.

We have highlighted that through the following updates.

*Section 2.1.3*

We have rephrased as below.

OLD

    If the NoSec mode is used (see Section 4), group communication does
    not rely on security at the transport layer nor at the CoAP layer,
    hence the communicating endpoints do not refer to a security group.

NEW

    *It is strongly discouraged to have unsecure group communication
    through the NoSec mode (see Section 4), whose possible exceptional
    use ought to be limited to specific circumstances (see Section 4 and
    Section 6.1). When the NoSec mode is nevertheless used,*the
    communicating endpoints do not refer to a security group.

*Section 4*

In order to say as soon as possible that the NoSec mode is not 
recommended, we have reordered the content of this section to be as below.

    CoAP group communication can operate in CoAP NoSec (No Security)
    mode, without using application-layer and transport-layer security
    mechanisms.

    It is NOT RECOMMENDED to use CoAP group communication in NoSec mode.

    The possible, exceptional use … resources (see Section 6.1).

    Before possibly and exceptionally … avoided whenever possible.

    The NoSec mode uses the “coap” scheme, and is defined in Section 9
    of [RFC7252]. The NoSec mode does not require and does not make use
    of a security group. Indications that … its lowercase/uppercase
    combinations.

    A CoAP server in NoSec mode MUST NOT be accessible through the
    public Internet.

Also, we have made minor rephrasing on two of those sentences above:

  *

    s/(No Security) mode, without using/(No Security) mode, i.e.,
    without using

  *

    s/A CoAP server in NoSec mode MUST NOT be accessible through the
    public Internet./A CoAP server MUST NOT be accessible for group
    communication in NoSec mode through the public Internet.

Finally, as a result of addressing a comment from the review of Mohamed 
Boucadair at [1], we have also shortened the second from last paragraph 
in the new text, to not repeat a requirement already made earlier in the 
document.

So that paragraph becomes as below:

    The NoSec mode uses the “coap” scheme, and is defined in Section 9
    of [RFC7252]. The NoSec mode does not require and does not make use
    of a security group (see Section 2.2.1.3).

[1]https://mailarchive.ietf.org/arch/msg/core/6bjFRbSwzAvfdQqupIn9hCxB_OA/



> ---
> /This task MAY be entrusted to a
>     dedicated administrator, that interacts with a Group Manager as
>     defined in Section 5./
> - Is this really an interoperability requirement, could the /MAY/ be a /may/?

Yes; or, even more clearly, it could be “can”, like used later in 
Section 5.1 when talking about the administrator and its interactions 
with the Group Manager.

We have rephrased as below:

OLD

    This task MAY be entrusted to a dedicated administrator, …

NEW

    This task can be entrusted to a dedicated administrator, …



> ---
>
> These commenst mostly relate to editorial NiTs, I've suggested some proposed
> text, but you my find other text, if you wish to clarify please do:
>
> /Then, Group configuration/
> - Why capital "G" here, could this be "group"?

Indeed, that’s a typo. Now fixed as below.

OLD

    Then, Group configuration, including …

NEW

    Then, group configuration, including …


> ---
> /In fact, being a member of a security group actually grants/
> - I didn't understand why this is written this way, would it be the same as
> something like: /Being a member of a security group grants/

It was meant to emphasize the rationale of the previous paragraph, but 
we have rephrased as suggested:

OLD

    In fact, being a member of a security group actually grants …

NEW

    Being a member of a security group grants …


> ---
> Section 2.2.1.1.
> I see the text refers to the IPv6 prefix: ff15
> - I think this is intended to be a a temporary site-local multicast address, if
> so please state this also in the text, rather than allowing any possibly for a
> reader to think this is a special reserved prefix.

A related point came up also in the review from Ketan Talaulikar [2].

Also in order to address his comment, we have made the updates below, 
switching to an IPv6 address from the range provided for documentation 
(see RFC 6676).

OLD (Section 2.2.1.1, 4 instances)

    ff15::1234

NEW (Section 2.2.1.1, 4 instances)

    ff05::db8:0:1

OLD (Section 2.1.4)

    … for example the CoAP group with site-local, site-specific
    multicast IP address ff15::3456 and default UDP port number 5683 …

NEW (Section 2.1.4)

    … for example the CoAP group with site-local multicast IP address
    ff05::db8:0:3456 and default UDP port number 5683 …

Similary, we made a related change in Appendix B and Appendix B.1:

OLD (Appendix B and Appendix B.1)

    ff35:30:2001:db8:f1:0:8000:1

NEW (Appendix B and Appendix B.1)

    ff05::db8:8000:1

[2]https://mailarchive.ietf.org/arch/msg/core/SG7fpMILV2a4qrJYHz0xhUw-V50/



> ---
> Section 2.2.1.2.
> This text mentions ff35:30:2001:db8:f1:0:8000:1 which seems like it may be an
> example of a site-local scope multicast address, please state this also in the
> text.

This text is simply referring to RFC 9176, which uses 
ff35:30:2001:db8:f1::8000:1, hence we prefer to keep that address here too.

For consistency, we have however edited the address to use exactly the 
same compact notation as in RFC 9176 and have made it explicit that it 
is a site-local address, i.e.:

OLD

    while the CoAP group ff35:30:2001:db8:f1:0:8000:1

NEW

    while the CoAP group with site-local address ff35:30:2001:db8:f1::8000:1

OLD

    selects the CoAP group ff35:30:2001:db8:f1:0:8000:1

NEW

    selects the CoAP group with address ff35:30:2001:db8:f1::8000:1


> ---
> I see this text:
> /For IPv6 CoAP groups, common multicast address ranges from which group
> addresses can be taken are ff1x::/16 and ff3x::/16./ - This does not clearly
> point to the address allocation and its specified use. Please explain the scope
> and refer to the IANA registry entry.

In order to address a comment in the review from Ketan Talaulikar [2], 
we have updated the text as below, to leave the choice to network 
operators and administrators. Therefore, there is no need to mention 
specific address ranges any more.

OLD

    For IPv6 CoAP groups, common multicast address ranges from which
    group addresses can be taken are ff1x::/16 and ff3x::/16.

NEW

    For IPv6 CoAP groups, this document does not suggest or recommend
    any particular multicast address ranges from which group addresses
    can be taken. It is up to network operators and managers to
    appropriately select addresses from the multicast address space with
    the intended multicast address scope.

[2]https://mailarchive.ietf.org/arch/msg/core/SG7fpMILV2a4qrJYHz0xhUw-V50/



> ----
> At various places, the word "effective" is used to describe the impact of an
> attack. Whilst it is true an attack would have an "effect", I don't think this
> word is the best, and I could suggest: /more effective/ is replaced by /makes
> this more vulnerable/ or something equivalent that indicates this is a problem
> not a goal.


Yes, it is implied that the effect of an attack is negative, hence a 
problem. Depending on the specific sentence, we have rephrased as below 
to use, e.g., “harmful” or “impact” instead.

OLD (Section 3.3.1)

    When using CoAP group communication, an amplification attack becomes
    more effective than when …

NEW (Section 3.3.1, emphasis mine)

    When using CoAP group communication, an amplification attack becomes
    more*harmful*than when …

OLD (Section 3.7)

    When combining CoAP group communication and Observe as described
    above, an amplification attack can become particularly effective.

NEW (Section 3.7, emphasis mine)

    When combining CoAP group communication and Observe as described
    above, an amplification attack can become particularly*harmful*.

OLD (Section 6.1)

    Moreover, as also discussed in
    [I-D.irtf-t2trg-amplification-attacks], the NoSec mode is
    susceptible to source IP address spoofing, hence amplification
    attacks are especially feasible and greatly effective,

NEW (Section 6.1, emphasis mine)

    Moreover, as also discussed in
    [I-D.irtf-t2trg-amplification-attacks], the NoSec mode is
    susceptible to source IP address spoofing, hence amplification
    attacks are especially feasible and greatly*harmful*,

OLD (Section 6.3)

    In terms of attack effectiveness, an adversary sending a single
    group request may therefore achieve a large amplification factor …

NEW (Section 6.3, emphasis mine)

    In terms of attack*impact*, an adversary sending a single group
    request may therefore achieve a large amplification factor …

OLD (Section 6.4)

    … this replay attack would not accomplish anything on the client,
    although it does effectively target the servers …

NEW (Section 6.4, emphasis mine)

    … this replay attack would not accomplish anything on the client,
    although it*does target*the servers …



> ---
> /the attack may/the attack could/
> - only to avoid potential mis-reading.

Yes; rephrased as below.

OLD (Section 3.1.1)

    the attack may result in …

NEW (Section 3.1.1)

    the attack could result in …

OLD (Section 3.7)

    the attack may result in …

NEW (Section 3.7)

    the attack could result in …



> ---
> Section 3.1.3 makes a general statement I think is wrong:
> /Group requests sent over IP multicast generally have much higher loss rates
> than messages sent over unicast, particularly in constrained networks./ - I can
> see that loss ratios can be higher for multicast when sent over a different
> link with a different property, but in the general Internet this is not so. I
> suggest: /Group requests sent over IP multicast can have much higher loss rates
> than messages sent over unicast, particularly when using a constrained network./

We have rephased as suggested.

OLD

    Group requests sent over IP multicast generally have much higher
    loss rates than messages sent over unicast, particularly in
    constrained networks.

NEW

    Group requests sent over IP multicast can have much higher loss
    rates than messages sent over unicast, particularly when using a
    constrained network.


> ---
> /This document updates [RFC7252] by allowing a group request to contain ETag
> Options as specified below./ - please refer to section number where the update
> is to be applied in RFC 7252.

That section is mentioned in the sentence immediately preceding the 
quoted text in Section 3.2.2 of the present document:

    For validation of cached group communication responses at client
    endpoints, the multicast validation rules in Section 8.2.1 of
    [RFC7252] apply, except for the last paragraph which states “A GET
    request to a multicast group MUST NOT contain an ETag option”.

We have rephrased as below and repeated the section number:

OLD

    This document updates [RFC7252] by allowing a group request to
    contain ETag Options as specified below.

NEW (emphasis mine)

    This document updates*Section 8.2.1 of*[RFC7252] by allowing a group
    request to contain ETag Options as specified below.



> ---
> /the CoAP default UDP port number 5683/
> - OK, but please insert a reference to the IANA allocation registry.

Done, as per the rephrasing below:

OLD

    … is usually the CoAP default UDP port number 5683, or alternatively …

NEW

    … is usually the CoAP default UDP port number 5683 [Port.Number], or
    alternatively …

With the additional informative reference below:

    Port.Number:
    author:
    org: IANA
    date: false
    title: Service Name and Transport Protocol Port Number Registry
    target:https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml



> ---
> /One way to create multiple CoAP groups is using different UDP ports  with the
> same IP multicast address, .../ - True, but it seems like this should probably
> be prefaced by something like: /When COAP groups are created with unique IP
> multicast addresses the receivers of these messages can utilise multicast
> filters to extract the messages of interest./ - and then make the directly
> above sentence in the text start as: /Another way..."

Quoting the whole paragraph for context:

OLD

    One way to create multiple CoAP groups is using different UDP ports
    with the same IP multicast address, in case the devices’ network
    stack only supports a limited number of multicast address
    subscriptions. However, it must be taken into account that this
    incurs additional processing overhead on each CoAP server
    participating in at least one of these groups: messages to groups
    that are not of interest to the node are only discarded at the
    higher transport (UDP) layer instead of directly at the Internet
    (IP) layer. Also, a constrained network may be additionally burdened
    in this case with multicast traffic that is eventually discarded at
    the UDP layer by most nodes.

In order to also address a comment in the review from Éric Vyncke [2] 
about the same paragraph, we have rephrased the paragraph as below.

The new text explicitly mentions the use of the same IP multicast 
address as a starting point. Even though it is generally possible to 
think of “multicast filters”, it would be good that this document 
mentions only addresses and port numbers as specific tools, since the 
scope for group communication is anyway limited to IP and UDP.

NEW (emphasis mine)

    *It is NOT RECOMMENDED to create multiple CoAP groups by using
    different UDP ports with the same IP multicast address. An allowed
    exception is the presence of constrained devices whose network stack
    only supports a limited number of multicast address subscriptions.
    The use of such an approach for creating CoAP groups*incurs
    additional processing overhead … discarded at the UDP layer by most
    nodes.

[2]https://mailarchive.ietf.org/arch/msg/core/N0x5gyVLzepZA_aTdsXZcYJyGyY/



> ---
> /The port number 5684/
> - OK, but please insert a reference to the IANA allocation registry.

We have rephrased as below:

OLD

    The port number 5684 is dedicated for DTLS-secured unicast CoAP and …

NEW

    The port number 5684 is dedicated for DTLS-secured unicast CoAP
    [Port.Number] and …

With the additional informative reference below:

    Port.Number:
    author:
    org: IANA
    date: false
    title: Service Name and Transport Protocol Port Number Registry
    target:https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml


> ---
> /For a CoAP server node that supports resource discovery as defined in
>     Section 2.4 of [RFC7252], the default port number 5683 MUST be
>     supported /
> - I don't know what "supported" means in this context - must the receiver
> process packets received on this port; or only if configure, or what? (please
> change supported to some explanation).

Quoting the whole sentence for completeness:

    For a CoAP server node that supports resource discovery as defined
    in Section 2.4 of [RFC7252], the default port number 5683 MUST be
    supported (see Section 7.1 of [RFC7252]) for the “All CoAP Nodes”
    CoAP group as detailed in Section 3.9.

The text is using the same parlance of the referred Section 7.1 of RFC 7252:

    The CoAP default port number 5683 MUST be supported by a server that
    offers resources for resource discovery (see Section 7.2 below) …

We have updated the text in the present document to be even closer to 
that of RFC 7252, and to be more precise about “All CoAP Nodes” being an 
address (not a CoAP group):

NEW (emphasis mine):

    For a CoAP server node that*offers resources for*resource
    discovery*(see*Section 2.4 of [RFC7252]*)*, the default port number
    5683 MUST be supported (see Section 7.1 of [RFC7252]) for the “All
    CoAP Nodes”*IP multicast addresses (see Section 12.8 of
    [RFC7252]),*as detailed in Section 3.9.

“Supported” here means that such a server must be listening for incoming 
requests that target an “All CoAP Nodes” address and port number 5683. 
Assuming the received request to be valid, the server would indeed 
process it, as the server offers resources for resource discovery by 
definition.

This was not expanded/explained in RFC 7252, and we would prefer to not 
do it in the present document to avoid risk of confusion.



> ---
> /If this happens, the reverse-proxy MUST /
> - appears in a separate paragraph to the description. I think it would be
> better for the sentence to state what /this/ is, i.e. if a client re-uses a
> Token value, or something similar. - Consider also making this one paragraph to
> clearly link the description with the requirement.

We have accordingly rephrased as below.

OLD

    A client might re-use a Token value in a valid new request to the
    reverse-proxy, while the reverse-proxy still has an ongoing group
    communication request for this client with the same Token value
    (i.e., its time period for response collection has not ended yet).

    If this happens, the reverse-proxy MUST stop the ongoing request and
    associated response forwarding, it MUST NOT forward the new request
    to the servers in the CoAP group, and it MUST send a 4.00 (Bad
    Request) error response to the client. The diagnostic payload of the
    error response SHOULD indicate to the client that the resource is a
    reverse-proxy resource, and that for this reason immediate Token
    re-use is not possible.

NEW (emphasis mine)

    A client might re-use a Token value in a valid new request to the
    reverse-proxy, while the reverse-proxy still has an ongoing group
    communication request for this client with the same Token value
    (i.e., its time period for response collection has not ended yet).
    If*the client does so*, the reverse-proxy MUST stop the ongoing
    request and associated response forwarding, it MUST NOT forward the
    new request to the servers in the CoAP group, and it MUST send a
    4.00 (Bad Request) error response to the client. The diagnostic
    payload of the error response SHOULD indicate to the client that the
    resource is a reverse-proxy resource, and that for this reason
    immediate Token re-use is not possible.


> ---
> /   For the operation of HTTP-to-CoAP reverse proxies, see the last two
>     paragraphs of Section 3.5.1, which apply also to the case of reverse-
>     proxies./
> - Would this be clearer rewritten, e.g.:
> /   The last two  paragraphs of Section 3.5.1, also apply for the operation of
> HTTP-to-CoAP reverse proxies./

Yes, minus the comma, and adding a dash that we missed in “reverse-proxies”.

OLD

    For the operation of HTTP-to-CoAP reverse proxies, see the last two
    paragraphs of Section 3.5.1, which apply also to the case of
    reverse-proxies.

NEW

    The last two paragraphs of Section 3.5.1 also apply for the
    operation of HTTP-to-CoAP reverse-proxies.


> ---
> /CoAP group requests may result in a multitude of responses from/
> - To avoid doubt, can this be rewritten as something like:
> /CoAP group requests could result in a multitude of responses from/

We have rephrased as suggested.

OLD

    CoAP group requests may result in a multitude of responses from
    different nodes …

NEW

    CoAP group requests could result in a multitude of responses from
    different nodes …


> ---
> /Multicast usage of
>     Block1 is non-trivial due to potential message loss (leading to
>     missing blocks or missing confirmations), and potential diverging
>     block size preferences of different members of the CoAP group./
> - I agree, but would also strongly encourage that you add another
> consideration: that retransmission needs to conform to the congestion control
> requirements stated in section XX of this document.

Yes, although we should avoid the word “retransmission”, since it would 
instead suggest what happens at the messaging layer to handle 
non-acknowledged Confirmable messages.

Instead, it is better to use “repeated transmission” if we would define 
the details of this. We have rephrased as below in a very general way as 
to avoid such details; and place requirements on future solutions that 
are currently still out of scope:

OLD

    Multicast usage of Block1 is non-trivial due to potential message
    loss (leading to missing blocks or missing confirmations), and
    potential diverging block size preferences of different members of
    the CoAP group.

NEW

    Multicast usage of Block1 is non-trivial due to potential message
    loss (leading to missing blocks or missing confirmations), and
    potential diverging block size preferences of different members of
    the CoAP group.*Besides addressing such issues, a future solution
    for group/multicast block-wise transfer using the Block1 Option
    needs to conform to the congestion control requirements compiled in
    Section 3.6 of this document.*


> ---
> /the default port number 5683 MUST be supported as per Sections 7.1 and 12.8 of
> [RFC7252] / - as before, please expand upon the word /supported/, does this
> mean messages received and processed? (Also the same comment to explain the
> meaning of support in 3.9.3)

The same answer to an earlier comment about Section 3.4 applies here.

Quoting the whole sentence for completeness:

    For a CoAP server node that supports resource discovery as defined
    in Section 2.4 of [RFC7252], the default port number 5683 MUST be
    supported as per Sections 7.1 and 12.8 of [RFC7252] for the “All
    CoAP Nodes” multicast CoAP group. An IPv6 CoAP server SHOULD support
    the “All CoAP Nodes” multicast CoAP group with at least …

The text is using the same parlance of the referred Section 7.1 of RFC 7252:

    The CoAP default port number 5683 MUST be supported by a server that
    offers resources for resource discovery (see Section 7.2 below) …

Like for the update to address the previous comment, we can rephrase as 
below:

NEW (Section 3.9.1, emphasis mine)

    For a CoAP server node that*offers resources for*resource discovery
    as defined in Section 2.4 of [RFC7252], the default port number 5683
    MUST be supported as per*Section 7.1 of [RFC7252]*for the “All CoAP
    Nodes”*IPv6 multicast addresses (see Section 12.8 of [RFC7252])*. An
    IPv6 CoAP server SHOULD support the “All CoAP Nodes”*IPv6 multicast
    addresses*with at least*the*…

NEW (Section 3.9.3, emphasis mine)

    For a CoAP server node that*offers resources for*resource discovery
    as defined in Section 2.4 of [RFC7252], the default port number 5683
    MUST be supported*as per Section 7.1 of [RFC7252]*for the “All CoAP
    Nodes”*IPv4 multicast address (see Section 12.8 of [RFC7252])*.

Like in the earlier Section 3.4 that anticipates the details provided in 
Sections 3.9.1 and 3.9.3, “supported” here means that such a server must 
be listening for incoming requests that target the “All CoAP Nodes” 
addresses and port number 5683. Assuming the received request to be 
valid, the server would indeed process it, as the server offers 
resources for resource discovery by definition.

This was not expanded/explained in RFC 7252, and we would prefer to not 
do it in the present document to avoid risk of confusion.

The updates above suggested that it is good to make also the following, 
related updates in other sections, i.e. make clear that "All CoAP Nodes" 
are multicast addresses and not a "CoAP group":

OLD (Section 1.3)

    … scopes with the “All CoAP Nodes” multicast CoAP group (see Section
    3.9.1).

NEW (Section 1.3, emphasis mine)

    … scopes with the “All CoAP Nodes”*IPv6 multicast addresses*(see
    Section 3.9.1 of the present document).

OLD (Section 2.2.3.2)

    …; or to the “All CoAP Nodes” multicast address …

NEW (Section 2.2.3.2, emphasis mine)

    …; or to*an*“All CoAP Nodes”*IP*multicast address …

OLD (Section 2.2.3.2, 2 instances)

    This is achieved by sending the GET request above to the “All CoAP
    Nodes” IP multicast address …

NEW (Section 2.2.3.2, 2 instances, emphasis mine)

    This is achieved by sending the GET request above to*an*“All CoAP
    Nodes” IP multicast address …

OLD (Section 2.2.3.2)

    The request is sent to the “All CoAP Nodes” IP multicast address …

NEW (Section 2.2.3.2, emphasis mine)

    The request is sent to*an*“All CoAP Nodes” IP multicast address …

OLD (Section 3.9.2)

    … to the realm-local “All CoAP Nodes” IPv6 multicast CoAP group (see
    Section 3.9.1) in …

NEW (Section 3.9.2, emphasis mine)

    … to the “All CoAP Nodes” IPv6 multicast*address*(see Section
    3.9.1)*with realm-local scope*, in …

OLD (Appendix A.1.3)

    … to the site-local “All CoAP Nodes” multicast address (ff05::fd).

NEW (Appendix A.1.3, emphasis mine)

    … to the site-local “All CoAP Nodes”*IP*multicast address (ff05::fd).



> ---
> /A suitable cross-proxy can be set up, such that it receives a
>        unicast CoAP group request over TCP/TLS/WebSockets, and then
>        forwards the request to the servers in the group over UDP/IP
>        multicast /
> - OK, but please explicitly state that any multicast transmission MUST respect
> the requirements stated in this document.

Like for a previous comment about the Block1 Option, we interpret your 
comment as referring to the congestion control requirements.

Also, this should first of all be stated in Sections 3.5 about proxies 
in general.

We have rephrased the text in Section 3.5 as below:

OLD (Section 3.5)

    In particular, forward-proxies and reverse-proxies are separately
    considered in Section 3.5.1 and Section 3.5.2, respectively.
    Furthermore, Section 3.5.3 discusses the case where a client sends a
    group request to multiple proxies at once. Security considerations
    that apply when using a proxy are discussed later in Section 5.3.

NEW (Section 3.5)

    In particular, forward-proxies and reverse-proxies are separately
    considered in Section 3.5.1 and Section 3.5.2, respectively.
    Furthermore, Section 3.5.3 discusses the case where a client sends a
    group request to multiple proxies at once.*When sending a CoAP group
    request over UDP/IP multicast, a proxy MUST conform to the
    congestion control requirements compiled in Section 3.6 of this
    document.*Security considerations that apply when using a proxy are
    discussed later in Section 5.3.

So the intent is now that the new requirement covers any type of proxy 
that sends out CoAP group requests over UDP/IP multicast.

For consistency, we have made a related rephrasing in Section 3.5.2 and 
Appendix F:

OLD

    … such as IP/UDP multicast.

NEW

    … such as UDP/IP multicast.



> ---
> Section 4: Please consider moving the text within the first few paras. I'd
> hoped the requirement: /It is NOT RECOMMENDED to use CoAP group communication
> in NoSec mode./ at the start of section 4 followed by the next para an
> explanation why, so that this is made this very clear.

Yes. We have addressed this by addressing the first comment in the 
“COMMENT” part of this review.

That is, we have reordered the content of this section, mentioning as 
early as possible that the NoSec mode is NOT RECOMMENDED.


> ---
> Plase consider whether you can creat a separate section title: "Operational
> Considerations" to alert the operator community to relevant content (no need
> for extra content, just restructuring to make this more obvious). - If you do
> this, I'd encourage you to move the subsections 6.6, 6.7 and 6.8 to this new
> section.

Sections 6.6-6.8 are under Section 6 “Security Considerations” and 
discuss security-related aspects. So, we think that they already are in 
the right place.

We are not sure of what other content can be taken from other sections 
of the document and moved into a new section “Operational Considerations”.

We believe that the content is in the right place, and we prefer to not 
experiment with or shake the document structure too much at this point.


> ---
> I assume all appendices are Informative - but this is not stated, please add a
> sentence to state this.
> ---

That’s correct, and it is already stated in the last paragraph of 
Section 1.0:

    All sections in the body of this document are normative, while
    appendices are informative.

> _______________________________________________
> core mailing list [e-mail]
> To unsubscribe send an email [e-mail]

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339