Subject: [core] WGLC of draft-ietf-core-groupcomm-17

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 Dec 2013 18:49:50 +0100

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

---

From: "weigengyu" <[email-masked]>
Date: Tue, 24 Dec 2013 13:17:53 +0800

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

Grüße, Carsten

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