Subject: [core] Brian Haberman's Discuss on draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT)

From: "Brian Haberman" <[email-masked]>
Date: Tue, 19 Aug 2014 07:43:34 -0700

Brian Haberman has entered the following ballot position for
draft-ietf-core-groupcomm-21: 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 to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have no issues with the goal of this document, but I do have some items
I would like to talk about:

1. The text in section 1.2 implies that the primary multicast mode of
operation is source-specific, but doesn't explicitly state that.  Is it
intended that multicast is only done in an SSM mode?  If so, it would be
good to provide explicit discussion of that (including references to
relevant SSM RFCs such as 3569, 4604, and 4607).  If the goal is to also
support ASM, that should be stated explicitly.

2. Does the multicast proxy forwarding described in RFC 4605 apply in
section 2.1?

3. I am a little concerned with the SHOULD used in section 2.2 when
discussing nodes joining the All-CoAP-Nodes multicast address.  What
happens if a device does not join that group?  Will the protocol break?

4. Section 2.3 should allow a device to obtain the port number for the
group from the URI schema referenced in section 2.2.

5. I see that the socket() API (RFC 3542) is referenced, but it is not
discussed in terms of CoAP interacting with the group management
protocols.  Is it assumed that implementers know that they are to use
that API to indicate changes in group membership state to IGMP/MLD?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The various discussions of reliable multicast in the document may benefit
from an informative reference to a technique such as RFC 3940.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 19 Aug 2014 12:29:36 -0400

Hi Brain,

Response:
-------------
The intent was not to imply that primary mode should be Source Specific
Multicast (SSM.  The goal is instead to support Any Source Multicast
(ASM).  We can update to specifically state that.  Are there any
specific RFCs we should point to for ASM support?

(Note: In some of the future multicast security solutions for group
communications being discussed in DICE WG there is interest in source
authentication.  But even in DICE at this point they are not specifying
SSM).

section 2.1?

Response:
-------------
We did not have a specific requirement to support RFC 4605 multicast
proxy forwarding for CoAP group communication.  Though of course RFC
4605 type proxy may be deployed as part of the underlying IP multicast
infrastructure that CoAP group communication runs on.  So, if you wanted
us to just point to RFC 4605 as a background reference from section 2.1
then I am fine with that.  Is that what you wanted?

Please also note that the main proxy functionality that we need for
group communication is described in section 2.10.  But this is very
specific to a CoAP proxy functionality and not RFC 4605 functionality.
I just wanted to draw your attention to that fact as we are discussing
proxies.

Response:
-------------
The SHOULD was reflecting what was already there in the base CoAP spec
(RFC 7252) and CORE link format (RFC 6690).  That is, CoAP devices are
strongly encouraged to join a multicast group so that they can be easily
discoverable by other CoAP nodes.   (Please note that it is not a MUST
but a SHOULD).  If the device decides not join then it simply will not
be discovered.  Nothing will really break.

(Please note that there is a separate thread with Martin that is
requesting clarification (from the AD) of whether we should have any
normative language in an Informational document or whether this document
should be Standards track or BCP instead ...)

Response:
-------------
Section 2.3 reference to ports is guidance for the listener as to which
port it should be monitoring on to receive the IP multicast.  So I am
unfortunately missing your point.  Can you please expand on your
thinking for me?

Response:
-------------
Our main reference to interaction between CoAP and the group management
protocols is in the last paragraph of
http://tools.ietf.org/html/draft-ietf-core-groupcomm-21#section-2.7.2.1
(and then repeated in some of the following sections).  Should we add
the reference to RFC 3542 in that last paragraph (and corresponding
following paragraphs)?  I think this is a good idea but just want to
double check with you.

Best Regards,

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, August 19, 2014 10:44 AM
To: The IESG
Cc: [email-masked];
[email-masked]; [email-masked]
Subject: [core] Brian Haberman's Discuss on
draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT)

I have no issues with the goal of this document, but I do have some
items I would like to talk about:

The various discussions of reliable multicast in the document may
benefit from an informative reference to a technique such as RFC 3940.

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Brian Haberman <[email-masked]>
Date: Tue, 19 Aug 2014 12:56:16 -0400

Hi Akbar,

> support ASM, that should be stated explicitly.

The term ASM is defined in several different RFCs.  The original
multicast specification (RFC 1112) is often referenced as the definition
of ASM.  RFC 5110 should have had a crisp definition, but it doesn't.

>> 2. Does the multicast proxy forwarding described in RFC 4605 apply in

I just wanted to ensure that this approach did not preclude RFC 4605 in
constrained networks/devices.  An informative reference would be fine.

> I just wanted to draw your attention to that fact as we are discussing

Yes.

> happens if a device does not join that group?  Will the protocol break?

Ok.  I just wanted to make sure the lack of ability to discover a node
would not break multicast distribution.

> should be Standards track or BCP instead ...)

Yes, I am aware of that ongoing discussion.

> group from the URI schema referenced in section 2.2.

Sure (since I worded my point very poorly).  If I am a listener (called
a server in 2.3), I need to select a port number.  That port number
needs to be available to the client devices.  So, my concern is one of
ensuring the clients select the correct destination port based on the
port selected by the server for listening.  In relation to 2.3, the
server should be able to use the port number published in the URI
described in section 2.2, right?

> that API to indicate changes in group membership state to IGMP/MLD?

That would make things clearer.

Thanks for the quick response!

Regards,
Brian

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 19 Aug 2014 15:36:09 -0400

Hi Brian,

Thanks for the responses.  I will update the draft with all the points
below that we have closed on.  For the one open question, below is my
response:

> If I am a listener (called a server in 2.3), I need to select a port
number.  That port number needs to be available to the client devices.
So, my concern is one of ensuring the clients select the correct
destination port based on the port selected by the server for listening.
In relation to 2.3, the server should be able to use the port number
published in the URI described in section 2.2, right?

Response:
-------------
Yes, the server should  be listening on the port number of the URI as
described in section 2.2.  Please note that section 2.2 is describing
the general structure of the CoAP group URI, and also discussing the
case of when the URI is an FQDN and how to resolve it to an IP address
through DNS.  If that is what you are referring to as "publishing" then
we are in sync.

Best Regards,

Akbar

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2014 12:56 PM
To: Rahman, Akbar; The IESG
Cc: [email-masked];
[email-masked]; [email-masked]
Subject: Re: [core] Brian Haberman's Discuss on
draft-ietf-core-groupcomm-21: (with DISCUSS and COMMENT)

Hi Akbar,

On 8/19/14 12:29 PM, Rahman, Akbar wrote:
> operation is source-specific, but doesn't explicitly state that.  Is 
> it intended that multicast is only done in an SSM mode?  If so, it 
> would be good to provide explicit discussion of that (including 
> references to relevant SSM RFCs such as 3569, 4604, and 4607).  If the

> goal is to also support ASM, that should be stated explicitly.
> 
> Response:
> -------------
> The intent was not to imply that primary mode should be Source 
> Specific Multicast (SSM.  The goal is instead to support Any Source 
> Multicast (ASM).  We can update to specifically state that.  Are there

> any specific RFCs we should point to for ASM support?
> 
> authentication.  But even in DICE at this point they are not 
> specifying SSM).
> 

> infrastructure that CoAP group communication runs on.  So, if you 
> wanted us to just point to RFC 4605 as a background reference from 
> section 2.1 then I am fine with that.  Is that what you wanted?
> 

Yes.

> normative language in an Informational document or whether this 
> document should be Standards track or BCP instead ...)
> 
> 

> Section 2.3 reference to ports is guidance for the listener as to 
> which port it should be monitoring on to receive the IP multicast.  So

> I am unfortunately missing your point.  Can you please expand on your 
> thinking for me?
> 

> Our main reference to interaction between CoAP and the group 
> management protocols is in the last paragraph of
> http://tools.ietf.org/html/draft-ietf-core-groupcomm-21#section-2.7.2.
> 1 (and then repeated in some of the following sections).  Should we 
> add the reference to RFC 3542 in that last paragraph (and 
> corresponding following paragraphs)?  I think this is a good idea but 
> just want to double check with you.
> 

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 19 Aug 2014 15:43:54 -0400

Hi Akbar,

> published in the URI described in section 2.2, right?

I understand that 2.2 is just discussing the general structure of the
CoAP group URI.  I am wondering if the following change needs to be made
in section 2.3 to utilize that URI from the server's perspective.  Does
this change make sense?

OLD:

   1.  A pre-configured port number.

   2.  If the client is configured to use service discovery including
       port discovery, it uses a port number obtained via a service
       discovery lookup operation for the targeted CoAP group.

   3.  Use the default CoAP UDP port (5683).

NEW:

   1.  A pre-configured port number.

   2.  If the client is configured to use service discovery including
       port discovery, it uses a port number obtained via a service
       discovery lookup operation for the targeted CoAP group.

   3.  The port number published in the corresponding CoAP group URI.

   4.  Use the default CoAP UDP port (5683).

Regards,
Brian

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 19 Aug 2014 17:03:29 -0400

Hi Brian,

Okay.  Now I understand your point.  The thing is that the only real
"publication" method would have been in the service discovery of item 2.
So we could re-phrase item 2 to explicitly call this out as follows:

OLD:

NEW:

   2.  If the client is configured to use service discovery including
       URI and/or port discovery, it uses the port number obtained via
the service
       discovery lookup operation for the targeted CoAP group.

Does that address your question?

/Akbar

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2014 3:44 PM
To: Rahman, Akbar; The IESG
Cc: [email-masked];

Hi Akbar,

> through DNS.  If that is what you are referring to as "publishing" 
> then we are in sync.
> 

OLD:

NEW:

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 20 Aug 2014 14:51:13 -0400

Hi Akbar,

> Does that address your question?

Works for me.  Thanks for taking the time to work through this.

Regards,
Brian