Subject: Re: [core] Group Communication identify

From: "Dijk, Esko" <[email-masked]>
Date: Sat, 4 Jan 2014 07:23:38 +0000

Indeed, currently #4 is used in a CoAP Proxy.
The Proxy in any case has to process the CoAP request so that the hostname is resolved to an IP address (unicast or multicast); so there is no extra work involved in determining whether the message is multicast or not.
Due to some issues described in http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.10 there is a guideline proposed that a Proxy SHOULD NOT send out a CoAP multicast request.

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of weigengyu
Sent: Tuesday, December 24, 2013 06:18
To: Carsten Bormann; [email-masked]
Subject: [core] Group Communication identify

Hi Carsten and all:

I raise a problem without relation to the current group comm draft.

The problem is whether we need an explicit identity of multicast/group comm message.

There is no identity in the CoAP message whether it is  a group comm or multicast message in CoAP-18.
Although Group URI is defined in Group Comm for CoAP, each node needs to do name resolution to know the multicast/group comm, or the node to dig out the IP address from the underneath protocol layers.
This may not be a trivial for an intermediary node to get this knowledge when forwading message as message is transferred hop by hop.
So, marking a message to be multicast/group comm can simplify this.

Marking a message to be a CoAP multicast/group comm message would have following alternatives:
1. define a bit flag in message format, that informs whether message is sent in multicast/group comm; 2. define a option of multicast or Group comm; 3. define a dedicated UDP port number, which represents for multicast/group comm; 4. define a primitive to get the underneath IP address and determines whether the message is multicast/group comm by IP multicast address;

Current CoAP drafts seem to use #4 that is a cross layer means.
Probably, the above #1, #2 and #3 would be better than #4.

Regards,

Gengyu

Network Technology Center
School of computer
Beijing University of Posts & Telecommunications

-----原始邮件-----
From: Carsten Bormann
Sent: Tuesday, December 10, 2013 1:49 AM
To: core ([email-masked])
Subject: [core] WGLC of draft-ietf-core-groupcomm-17

In Vancouver, we said we were going to WGLC the groupcomm draft after some more edits, which were submitted by the authors on 2013-11-28.
All outstanding tickets are closed.  The recent discussion on correlating responses to multicast requests might lead to some additional explanatory text on how to handle the correlation, but this is something we can handle during the WGLC.

So this starts a working group last call for -groupcomm for submission as an informational RFC, ending on

24:00 PDT on Monday, December 23, 2013.

Please start a new email thread for each major issue that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue.  For minor issues such as typos and things that are not likely to lead to much discussion, it is probably easier to group them all in to one email but again, please make sure the subject line includes the draft name.  If you read the draft and think it looks fine, please send a one line email to the list or to the chairs letting us know that so we can get a feel of how broad the review has been.

If you are aware of any patent claims that might apply to systems that implement the suggestions in this draft, please review BCP 78 and BCP
79 and make any appropriate IPR declaration. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help get you in touch with people that can provide appropriate advice.

Grüße, Carsten

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

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

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "weigengyu" <[email-masked]>
Date: Sat, 4 Jan 2014 22:58:32 +0800

Hi,

In the CoRE network, endpoints, proxies or routers might not have IP 
multicast capability.
As an application layer protocol, the multicast facility could be got on 
some alternatives, not limited IP multicast only.

In current CoAP -18,
      " 8. Multicast CoAP
      CoAP supports making requests to a IP multicast group. This is defined 
by a series of deltas to Unicast CoAP. A more general
      discussion of group communication with CoAP is in 
[I-D.ietf-core-groupcomm]."

I suggest to change as :
" 8. Multicast CoAP
     CoAP supports making requests to a group of endpoints, named as CoAP 
group communication.
     This is defined by a series of deltas to Unicast CoAP.  A more general
     discussion of group communication with CoAP is in 
[I-D.ietf-core-groupcomm]."

It is well known that current [I-D.ietf-core-groupcomm] concerns to use IP 
multicast only.
It is better to open other alternatives.

Regards,

Gengyu

School of Computer

-----原始邮件----- 
From: Dijk, Esko
Sent: Saturday, January 04, 2014 3:23 PM
To: weigengyu ; Carsten Bormann ; [email-masked]
Subject: RE: [core] Group Communication identify

Indeed, currently #4 is used in a CoAP Proxy.
The Proxy in any case has to process the CoAP request so that the hostname 
is resolved to an IP address (unicast or multicast); so there is no extra 
work involved in determining whether the message is multicast or not.
Due to some issues described in 
http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.10 there 
is a guideline proposed that a Proxy SHOULD NOT send out a CoAP multicast 
request.

Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of weigengyu
Sent: Tuesday, December 24, 2013 06:18
To: Carsten Bormann; [email-masked]
Subject: [core] Group Communication identify

Hi Carsten and all:

The problem is whether we need an explicit identity of multicast/group comm 
message.

There is no identity in the CoAP message whether it is  a group comm or 
multicast message in CoAP-18.
Although Group URI is defined in Group Comm for CoAP, each node needs to do 
name resolution to know the multicast/group comm, or the node to dig out the 
IP address from the underneath protocol layers.
This may not be a trivial for an intermediary node to get this knowledge 
when forwading message as message is transferred hop by hop.
So, marking a message to be multicast/group comm can simplify this.

Marking a message to be a CoAP multicast/group comm message would have 
following alternatives:
1. define a bit flag in message format, that informs whether message is sent 
in multicast/group comm; 2. define a option of multicast or Group comm; 3. 
define a dedicated UDP port number, which represents for multicast/group 
comm; 4. define a primitive to get the underneath IP address and determines 
whether the message is multicast/group comm by IP multicast address;

Regards,

Gengyu

-----原始邮件-----
From: Carsten Bormann
Sent: Tuesday, December 10, 2013 1:49 AM
To: core ([email-masked])
Subject: [core] WGLC of draft-ietf-core-groupcomm-17

In Vancouver, we said we were going to WGLC the groupcomm draft after some 
more edits, which were submitted by the authors on 2013-11-28.
All outstanding tickets are closed.  The recent discussion on correlating 
responses to multicast requests might lead to some additional explanatory 
text on how to handle the correlation, but this is something we can handle 
during the WGLC.

So this starts a working group last call for -groupcomm for submission as an 
informational RFC, ending on

Please start a new email thread for each major issue that will need 
discussion and make sure the subject line includes the draft name and some 
sort of name for the issue.  For minor issues such as typos and things that 
are not likely to lead to much discussion, it is probably easier to group 
them all in to one email but again, please make sure the subject line 
includes the draft name.  If you read the draft and think it looks fine, 
please send a one line email to the list or to the chairs letting us know 
that so we can get a feel of how broad the review has been.

If you are aware of any patent claims that might apply to systems that 
implement the suggestions in this draft, please review BCP 78 and BCP
79 and make any appropriate IPR declaration. If you are not sure whether you 
need to make a declaration or not, please talk to the chairs and we will 
help get you in touch with people that can provide appropriate advice.

Grüße, Carsten

________________________________
The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended 
recipient, please contact the sender by return e-mail and destroy all copies 
of the original message.