Subject: [core] Comments on draft-rahman-core-groupcomm-00

From: Zach Shelby <[email-masked]>
Date: Mon, 25 Oct 2010 17:00:13 +0300

Here are my comments on the draft. Overall, I think it is great to discuss this all in one place. 

Section 3.1.3. Group Discovery

- This section claims that ietf-core-link-format is limited to link-local multicast scope. This is not correct. ietf-core-coap has no limitation on what kinds of multicast addresses it can be used with. I think this is maybe being confused with mDNS, which is limited to link-local scope?

- I do agree that if DNS is being used to manage the resolution between an authority and a mulicast address, then adding more metadata about those groups would make sense using DNS-SD. However, DNS is not always available in constrained networks. How to discovery available multicast addresses without DNS? 

Section 3.1.4. Group Resource Manipulation

- It is suggested that multicast GET be restricted to link-local scope... why?

- Why must multicast requests be sent to the default CoAP port?

- What does "All multicast requests should operate on /.well-known/core URIs?" mean. 

- I am not sure that this requires a notation like coapm:// as we are dealing with IP multicast here, and the resolution is done by DNS.

3.1.5.2. Reliable IP Multicast

- It would be good to mention that in order to make a multicast request reliable, the client MUST know the members of group g. 

- We should explore whether it is better to retransmit a multicast request using individual unicast requests to members of the group g that did not ACK. 

4. Group Management

- I don't get this section at all. First you spent a lot of time explaining how DNS can be used to resolve an authority to a multicast IP address. Wouldn't you then manage IP multicast group membership using standard tools plus DNS updates? I don't see any need for overloading the base CoAP protocol with special options for doing that. 

5.1. Serial Unicast

s/group URI/authority ?

6. CoAP and HTTP interworking

- Do we need/want/care if HTTP has access to multicast requests? This whole concept doesn't exist in HTTP, so I think it would be better for an intermediate node to create a new resource out of combined multicast responses for access by HTTP. We should think about the requirements carefully before trying to do fancy things here. 

7. Security

- I would love to see a lot more here about msec and the use of IPsec for multicast requests. This will be needed as a contribution to ietf-core-coap eventually.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 25 Oct 2010 10:55:51 -0400

Hi Zach,

On Mon, Oct 25, 2010 at 10:00 AM, Zach Shelby <[email-masked]> wrote:
> Here are my comments on the draft.
>
Thanks for your comments.

> Overall, I think it is great to discuss this all in one place.
Me too.

> - This section claims that ietf-core-link-format is limited to link-local multicast scope. This is not correct. ietf-core-coap has no limitation on what kinds of multicast addresses it can be used…
Good point, modulo the design of draft-ietf-6lowpan-hc to support
3306 and 3956 Unicast-Prefix-based IPv6 Multicast Addresses.

The language should say "in the absence of support for off-link
multicast" or something similar.

>From a BCP perspective, we should probably discuss the scaling
issues in better detail.

> - I do agree that if DNS is being used to manage the resolution between an authority and a mulicast address, then adding more metadata about those groups would make sense using DNS-SD. However, DNS…

I'm sure you have ideas about this from a core-link perspective.
I still have not worked out the relationship between an MLD group
and DNS-SD group names.

> - It is suggested that multicast GET be restricted to link-local scope... why?
I think it was from a scaling perspective.

> - What does "All multicast requests should operate on /.well-known/core URIs?" mean.
The answer to both these is essentially the same.  Without well-know
targets for port and path, how do you increase the probability that all
members of a group receive or interpret the command in the same way?

> - I am not sure that this requires a notation like coapm:// as we are dealing with IP multicast here, and the resolution is done by DNS.
The thinking here is that group comms might be implemented
as multicast, serial unicast, or some combination.  Having a
distinct scheme for group comms might signal the proxy
receiving the request to look up the group membership and
replicate serial unicasts as well as multicast packets.

> - I don't get this section at all. First you spent a lot of time explaining how DNS can be used to resolve an authority to a multicast IP address. Wouldn't you then manage IP multicast group member…
I believe the thinking here is that a group authority may represent
a list of IP addresses (perhaps a mix of unicast and multicast) and
current group membership protocols like IGMP and MLD don't
support these concepts.  I guess it's TBD whether coap wants to
invent a technique for membership in compound groups.

> - I would love to see a lot more here about msec and the use of IPsec for multicast requests. This will be needed as a contribution to ietf-core-coap eventually.
Thanks, -K-

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