Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 15 Dec 2013 21:23:32 -0500

Hi Thomas,

Thanks for your detailed review.  Esko and I will review your comments in the next  few days and get back to you with a consolidated response.

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of FOSSATI, Thomas (Thomas)
Sent: Saturday, December 14, 2013 4:28 PM
To: core ([email-masked])
Subject: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Akbar, Esko.

Good job with the document.  The “Use Cases” section is especially enjoyable.

There are no major issues on my side; the following comments are mostly editorial.

Cheers, Thomas.

Section 1.1

- httpbis has been sent to IESG for publication, I guess it's ok to reference it instead of 2616;
- last para: it'd be super nice to have pointers to sections while topics are enumerated;

Section 1.3

- "IP multicast" definition could be made a bit richer?  To me IP multicast is not just a matter of addressing, is also the membership management, the routing and forwarding, the abstraction built on top of different L2 protocols.

Section 2.2

- first para: is it necessary for the two MAY's to be RFC2119?
- second para, last sentence: is there any reason why the "may also be enabled" is not RFC2119?
- fourth para: it's not clear to me what the "group communication request API" is
- fifth para: is the "It is recommended" meant to be RFC2119?
- last para: not clear what the use case for the reverse DNS mapping would be.

Section 2.3

- isn't bullet 3. (i.e. use the default CoAP port) just a special case of 1. (i.e. pre-configured port number)?

Section 2.4

- I guess it's the unreliable (more then the lossy) nature of IP multicast that makes POST unusable?

Section 2.5

- second para: it looks like the server can unilaterally decide to suppress a response to a multicast request.  But there is no mention about which conditions could trigger the actual response suppression.  A pointer to Section 2.8 perhaps?

Section 2.7

- The title/name is very generic.  "Group Membership RESTful Interface"
(or similar) would be more easily and consistently referenced in subsequent text (where it appears as "RESTful CoAP interface", and then as "RESTful interface").
- first para: missing comma "[...] only as [...]" -> "[...] only, as [...]"
- second para: the "Thus only authorized controllers [...]" is not clear to me: it seems to imply that DTLS provides authorisation, which it doesn't.

Section 2.7.2.1

- the beginning of this section could have a small description of the semantics, before going deep into syntactic details?
- second para: "A resource offering this representation": it's not clear to me what "this representation" refers to;
- third para: "[...] in a format as defined [...]" -> "[...] in the format defined [...]";
- problem with the defined syntax: it's impossible to specify a non-literal group with a non-default port.  I'd suggest adding the optional port to the non-literal format as well;
- fifth para: "SHOULD NOT be included if unknown" isn't this more a MUST NOT?  What should I put into it if I don't know what to put into it?
Also, the preceding MUST sounds more like a SHOULD?

Section 2.7.2.2

- I'd add a note about the need for the Group index to be unique
- what happens when a client tries to register a duplicate "a"?
- last para: add context/rationale for the re-join requirement on POST of an already registered

Section 2.7.2.3

- the "/" in  "/{+location}" looks redundant
- would be nice to have text that describes the actions that are to be done by the server on successful deletion

Section 2.7.2.4

- the "/" in  "/{+location}" looks redundant

Section 2.7.2.5

- last para: add reference to RFC5952?

Section 2.7.2.6

- would be nice to have text that describes the actions that are to be done by the server on successful update

Section 2.7.2.7

- first para: it's not clear what makes a CoAP client responsibile for the group membership objects
- would be nice to have text that describes the actions that are to be done by the server on successful update

Section 2.8

- It is said that the response suppression should be configurabile, which is great.  But then why not allowing this via the "Group Membership RESTful Interface"?

Section 2.10

- shameless plug: the "Multipart Content-Format Encoding for CoAP" I-D could provide the aggregation format needed ;-)

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

---

From: "weigengyu" <[email-masked]>
Date: Mon, 16 Dec 2013 13:25:53 +0800

Hi Akbar,

I also think you did a good job.
And I would like to give some comments after reading your draft.

>From the scope (1.2 scope )  the draft describes "group definition, group 
resource manipulation, and group configuration. Also,
proxy operation and minimizing network congestion for group communication"

1. about group definition
1.1    You use  terminalogyies group communication for CoAP, CoAP multicast, 
what the difference is?
1.2    in "2.2 Group Definition and Naming"
        "A group is defined as a set of CoAP endpoints, where each endpoint 
is configured to receive multicast CoAP requests that are sent to the group’s associated IP multicast address.
An endpoint MAY be a member of multiple groups. Group membership of an 
endpoint MAY dynamically change over time."
         As CoAP endpoints include client and servers,  A CoAP Group should 
include a sender (at least) and multiple recievers.
       or you can called the servers related to the specific IP multicast 
address as a receive-only group.
1.3  "Note: A Group URI is needed to initiate CoAP group communications."
        Is it possible to give Group URI an explicity Symble that is 
different from Host URI, just as specified in the resource type.
        The difference is not only in the meaning of words, but also by the 
symbole definition.

2. about group configuration

2.1 in "2.3. Port and URI Configuration"
      Is it possible and necessary to define a CoAP Group Comm port number?
      Even thoufh CoAP Supports  multicast,  it has no explicity flag in 
message when doing multicast.
      If there is a dedicated CoAP Group Comm port number, the differece for 
unicast and multicast are clear;
all CoAP group comm can use that UDP port number  and different groups are 
identified by Group URI.

2.2 in "2.5. Messaging and Responses"
      "The CoAP client can distinguish the origin of multiple server 
responses by source IP address of the UDP message containing the CoAP
response. In case a CoAP client sent multiple group requests, the responses 
are as usual matched to a request using the CoAP Token."
       Suggest to "The CoAP client can distinguish the origin of multiple 
server responses by source IP address of the UDP message,  CoAP URI, or 
other unique identity.  "

2.3 in "2.7.2. RESTful Interface"
      "To access this interface a client MUST use unicast CoAP methods 
(GET/PUT/POST/DELETE) only as it is a method of configuring group 
information in individual endpoints."
      I do suggest to add a client to use multicast CoAP methods as option.
     Configure the endpoints one by one may has considerations of security 
issues, but should reserve one to many configuration operations.

3. group resource manipulation
     in "2.9. Congestion Control",

     The draft gives decriptions on  " CoAP [I-D.ietf-core-coap] reduces 
multicast-specific congestion risks through the following measures: ......"
     But there are no words about how a node should do when there is 
congestion.
     Maybe this is the critical issue of congestion control and this is out 
of the scope.

I am appreciate your works on section 3 and 4.  And no commets on others 
currently.

Just read Thomas email
> "- httpbis has been sent to IESG for publication, I guess it's ok to 
> reference it instead of 2616;"

     If it referes to http2.0, I prefer rfc2616.  I am not sure whether 
http2.0 is so-called RESTful.

Regards,

Gengyu

Network Techonology Center
School of Computer
Beijing University of Posts & Telecommunications

-----原始邮件----- 
From: Rahman, Akbar
Sent: Monday, December 16, 2013 10:23 AM
To: FOSSATI, Thomas (Thomas)
Cc: [email-masked]
Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Thomas,

Thanks for your detailed review.  Esko and I will review your comments in 
the next  few days and get back to you with a consolidated response.

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of FOSSATI, Thomas 
(Thomas)
Sent: Saturday, December 14, 2013 4:28 PM
To: core ([email-masked])
Subject: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Akbar, Esko.

Good job with the document.  The “Use Cases” section is especially 
enjoyable.

There are no major issues on my side; the following comments are mostly 
editorial.

Cheers, Thomas.

Section 1.1

- httpbis has been sent to IESG for publication, I guess it's ok to 
reference it instead of 2616;
- last para: it'd be super nice to have pointers to sections while topics 
are enumerated;

Section 1.3

- "IP multicast" definition could be made a bit richer?  To me IP multicast 
is not just a matter of addressing, is also the membership management, the 
routing and forwarding, the abstraction built on top of different L2 
protocols.

Section 2.2

- first para: is it necessary for the two MAY's to be RFC2119?
- second para, last sentence: is there any reason why the "may also be 
enabled" is not RFC2119?
- fourth para: it's not clear to me what the "group communication request 
API" is
- fifth para: is the "It is recommended" meant to be RFC2119?
- last para: not clear what the use case for the reverse DNS mapping would 
be.

Section 2.3

- isn't bullet 3. (i.e. use the default CoAP port) just a special case of 1. 
(i.e. pre-configured port number)?

Section 2.4

- I guess it's the unreliable (more then the lossy) nature of IP multicast 
that makes POST unusable?

Section 2.5

- second para: it looks like the server can unilaterally decide to suppress 
a response to a multicast request.  But there is no mention about which 
conditions could trigger the actual response suppression.  A pointer to 
Section 2.8 perhaps?

Section 2.7

- The title/name is very generic.  "Group Membership RESTful Interface"
(or similar) would be more easily and consistently referenced in subsequent 
text (where it appears as "RESTful CoAP interface", and then as "RESTful 
interface").
- first para: missing comma "[...] only as [...]" -> "[...] only, as [...]"
- second para: the "Thus only authorized controllers [...]" is not clear to 
me: it seems to imply that DTLS provides authorisation, which it doesn't.

Section 2.7.2.1

- the beginning of this section could have a small description of the 
semantics, before going deep into syntactic details?
- second para: "A resource offering this representation": it's not clear to 
me what "this representation" refers to;
- third para: "[...] in a format as defined [...]" -> "[...] in the format 
defined [...]";
- problem with the defined syntax: it's impossible to specify a non-literal 
group with a non-default port.  I'd suggest adding the optional port to the 
non-literal format as well;
- fifth para: "SHOULD NOT be included if unknown" isn't this more a MUST 
NOT?  What should I put into it if I don't know what to put into it?
Also, the preceding MUST sounds more like a SHOULD?

Section 2.7.2.2

- I'd add a note about the need for the Group index to be unique
- what happens when a client tries to register a duplicate "a"?
- last para: add context/rationale for the re-join requirement on POST of an 
already registered

Section 2.7.2.3

- the "/" in  "/{+location}" looks redundant
- would be nice to have text that describes the actions that are to be done 
by the server on successful deletion

Section 2.7.2.4

Section 2.7.2.5

Section 2.7.2.6

- would be nice to have text that describes the actions that are to be done 
by the server on successful update

Section 2.7.2.7

- first para: it's not clear what makes a CoAP client responsibile for the 
group membership objects
- would be nice to have text that describes the actions that are to be done 
by the server on successful update

Section 2.8

- It is said that the response suppression should be configurabile, which is 
great.  But then why not allowing this via the "Group Membership RESTful 
Interface"?

Section 2.10

- shameless plug: the "Multipart Content-Format Encoding for CoAP" I-D could 
provide the aggregation format needed ;-)

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Mon, 16 Dec 2013 08:29:26 +0000

Hi Gengyu, Akbar,

On 16/12/2013 05:25, "weigengyu" <[email-masked]> wrote:
>     If it referes to http2.0, I prefer rfc2616.

I mean the 2616-bis document set, not HTTP/2.0.

Cheers

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 16 Dec 2013 09:39:41 -0500

Thanks, Gengyu, for your thorough review.  Esko and I will get back to you with a point by point response in the next few days.

Akbar

-----Original Message-----
From: weigengyu [mailto:[email-masked]] 
Sent: Monday, December 16, 2013 12:26 AM
To: Rahman, Akbar; FOSSATI, Thomas (Thomas)
Cc: [email-masked]
Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Akbar,

From the scope (1.2 scope )  the draft describes "group definition, group resource manipulation, and group configuration. Also, proxy operation and minimizing network congestion for group communication"

1. about group definition
1.1    You use  terminalogyies group communication for CoAP, CoAP multicast, 
what the difference is?
1.2    in "2.2 Group Definition and Naming"
        "A group is defined as a set of CoAP endpoints, where each endpoint is configured to receive multicast CoAP requests that are sent to the group’s associated IP multicast address.
An endpoint MAY be a member of multiple groups. Group membership of an endpoint MAY dynamically change over time."
         As CoAP endpoints include client and servers,  A CoAP Group should include a sender (at least) and multiple recievers.
       or you can called the servers related to the specific IP multicast address as a receive-only group.
1.3  "Note: A Group URI is needed to initiate CoAP group communications."
        Is it possible to give Group URI an explicity Symble that is different from Host URI, just as specified in the resource type.
        The difference is not only in the meaning of words, but also by the symbole definition.

2.1 in "2.3. Port and URI Configuration"
      Is it possible and necessary to define a CoAP Group Comm port number?
      Even thoufh CoAP Supports  multicast,  it has no explicity flag in message when doing multicast.
      If there is a dedicated CoAP Group Comm port number, the differece for unicast and multicast are clear; all CoAP group comm can use that UDP port number  and different groups are identified by Group URI.

2.2 in "2.5. Messaging and Responses"
      "The CoAP client can distinguish the origin of multiple server responses by source IP address of the UDP message containing the CoAP response. In case a CoAP client sent multiple group requests, the responses are as usual matched to a request using the CoAP Token."
       Suggest to "The CoAP client can distinguish the origin of multiple server responses by source IP address of the UDP message,  CoAP URI, or other unique identity.  "

2.3 in "2.7.2. RESTful Interface"
      "To access this interface a client MUST use unicast CoAP methods
(GET/PUT/POST/DELETE) only as it is a method of configuring group information in individual endpoints."
      I do suggest to add a client to use multicast CoAP methods as option.
     Configure the endpoints one by one may has considerations of security issues, but should reserve one to many configuration operations.

     The draft gives decriptions on  " CoAP [I-D.ietf-core-coap] reduces multicast-specific congestion risks through the following measures: ......"
     But there are no words about how a node should do when there is congestion.
     Maybe this is the critical issue of congestion control and this is out of the scope.

I am appreciate your works on section 3 and 4.  And no commets on others currently.

Just read Thomas email

Regards,

Gengyu

-----原始邮件----- 
From: Rahman, Akbar
Sent: Monday, December 16, 2013 10:23 AM
To: FOSSATI, Thomas (Thomas)
Cc: [email-masked]
Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Thomas,

Akbar

-----Original Message-----

Hi Akbar, Esko.

Cheers, Thomas.

Section 1.1

Section 1.3

Section 2.2

Section 2.3

Section 2.4

Section 2.5

Section 2.7

Section 2.7.2.1

Section 2.7.2.2

Section 2.7.2.3

Section 2.7.2.4

Section 2.7.2.5

Section 2.7.2.6

Section 2.7.2.7

Section 2.8

Section 2.10

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 17 Dec 2013 16:44:34 -0500

Hi Gengyu,

Thank you very much for the good comments.  Below are our embedded RESPONSES.  Please review and write back with your thoughts.

Best Regards,

Akbar & Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]] 
Sent: Monday, December 16, 2013 12:26 AM
To: Rahman, Akbar; FOSSATI, Thomas (Thomas)
Cc: [email-masked]
Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

>From the scope (1.2 scope )  the draft describes "group definition, group resource manipulation, and group configuration. Also, proxy operation and minimizing network congestion for group >communication"
>
------------------------
[AKBAR] AS DEFINED IN SECTION 1.3, THE MAIN DIFFERENCE IS THAT "MULTICAST" IN OUR DRAFT REFERS TO "IP MULTICAST".  WHILE "GROUP COMMUNICATION" REFERS TO SENDING OF APPLICATION COAP MESSAGES OVER IP MULTICAST.  PERHAPS ONE CLARIFICATION WE CAN MAKE IS AS FOLLOWS TO THE "GROUP COMMUNICATION" DEFINITION IN SECTION 1.3:

FROM:
"Group Communication
	A source node sends a single message which is delivered to multiple destination nodes ..."

TO:
"Group Communication
	A source node sends a single application layer (e.g. CoAP) message which is delivered to multiple destination nodes ..."

DO YOU AGREE?
-------------------------

>       or you can called the servers related to the specific IP multicast address as a receive-only group.
------------------------
[AKBAR] IT IS OPTIONAL FOR THE SENDER TO BE PART OF THE COAP GROUP AS WE HAVE STATED IN THE DEFINITION OF GROUP COMMUNCATION IN SECTION 1.3.  (I.E. "The source node itself may be part of the group").   THIS IS HOW ALL  UNDERLYING IP MULTICAST GROUPS WORK.

------------------------

>        The difference is not only in the meaning of words, but also by the symbole definition.
------------------------
[AKBAR] WE STATED IN SECTION 2.2 ("Group URIs follow the CoAP URI syntax") SO I AM NOT SURE WHAT YOU MEAN BY DIFFERENT SYMBOL?  WE WILL HOWEVER CLARIFY WHAT "group communications request API" MEANS FROM THE SAME SECTION 2.2 AS THOMAS SUGGESTED.  WILL THAT ANSWER  YOUR QUESTION?

------------------------

>      If there is a dedicated CoAP Group Comm port number, the differece for unicast and multicast are clear; all CoAP group comm can use that UDP port number  and different groups are identified by >Group URI.
------------------------
[AKBAR] THE STANDARD WAY FOR A SERVER TO KNOW THAT IT RECEIVED A MULTICAST MESSAGE IS IDENTIFIED IN SECTION 2.8

   "To apply any rules for request and/or response suppression, a CoAP
   server must be aware that an incoming request arrived via multicast
   by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]."

DOES THAT ANSWER YOUR QUESTION?
------------------------

>      "The CoAP client can distinguish the origin of multiple server responses by source IP address of the UDP message containing the CoAP response. In case a CoAP client sent multiple group requests, >the responses are as usual matched to a request using the CoAP Token."
------------------------
[AKBAR] BUT THERE IS NO "CoAP URI"  IN A RESPONSE?

------------------------

>     Configure the endpoints one by one may has considerations of security issues, but should reserve one to many configuration operations.

------------------------
[AKBAR] CURRENTLY IN COAP THE ONLY SECURITY IS ONE TO ONE (I.E. UNICAST DTLS).  THERE IS NO MULTICAST SECURITY.  SO I DON'T UNDERSTAND YOUR LAST SENTENCE?

------------------------

>     Maybe this is the critical issue of congestion control and this is out of the scope.

------------------------
[AKBAR] YOU ARE CORRECT.  WE ONLY GIVE RULES TO AVOID CONGESTION.  ANYTHING ELSE IS OUT OF SCOPE.

------------------------

>http2.0 is so-called RESTful.

------------------------
[AKBAR] YES.  PLEASE SEE MY RESPONSE TO THOMAS.

------------------------

Regards,

Gengyu

-----原始邮件----- 
From: Rahman, Akbar
Sent: Monday, December 16, 2013 10:23 AM
To: FOSSATI, Thomas (Thomas)
Cc: [email-masked]
Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Thomas,

Akbar

-----Original Message-----

Hi Akbar, Esko.

Cheers, Thomas.

Section 1.1

Section 1.3

Section 2.2

Section 2.3

Section 2.4

Section 2.5

Section 2.7

Section 2.7.2.1

Section 2.7.2.2

Section 2.7.2.3

Section 2.7.2.4

Section 2.7.2.5

Section 2.7.2.6

Section 2.7.2.7

Section 2.8

Section 2.10

---

From: "weigengyu" <[email-masked]>
Date: Wed, 18 Dec 2013 11:30:51 +0800

Hi Akbar,

My comments on each problem will be sent one by one.

>1.1    You use  terminologyies group communication for CoAP, CoAP 
>multicast,

Group communication and multicast are different.
If multicast  in the draft is restricted as the IP mulitcast, CLARIFICATION 
in terminology definition is OK. CoAP multicast should be avoided.

CoAP group communications is different from general group communication.
In a CoAP group, there are sender(s) and receivers, the sender and the 
receiver should be different.
A sender  is authorizied to send to the gorup by IP multicast. The receivers 
knows who is/are the sender(s) authorized to send,
and receive the message by IP multicast. Each reciever is not permited to 
send to the group by IP multicast.

> TO:
> "Group Communication
> A source node sends a single application layer (e.g. CoAP) message which 
> is delivered to multiple destination nodes ..."
> DO YOU AGREE?

Yes, I agree.

> [AKBAR] IT IS OPTIONAL FOR THE SENDER TO BE PART OF THE COAP GROUP AS WE 
> HAVE STATED IN THE DEFINITION OF GROUP COMMUNCATION IN SECTION 1.3.
>  (I.E. "The source node itself may be part of the group").   THIS IS HOW 
> ALL  UNDERLYING IP MULTICAST GROUPS WORK.

I do not agree that "IT IS OPTIONAL FOR THE SENDER TO BE PART OF THE COAP 
GROUP ".
I do not aggree that the sender is not part of the group.
If the sender is not part of the group, how the receivers know whether it is 
authorize to send.

Group membership management is at the application layer.
This issue will effect authentication and authorization.

Reagrds,

Gengyu

-----原始邮件----- 
From: Rahman, Akbar
Sent: Wednesday, December 18, 2013 5:44 AM
To: weigengyu
Cc: [email-masked] ; Dijk, Esko
Subject: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Gengyu,

Thank you very much for the good comments.  Below are our embedded 
RESPONSES.  Please review and write back with your thoughts.

Best Regards,

Akbar & Esko

-----Original Message-----
From: weigengyu [mailto:[email-masked]]
Sent: Monday, December 16, 2013 12:26 AM
To: Rahman, Akbar; FOSSATI, Thomas (Thomas)
Cc: [email-masked]
Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

>resource manipulation, and group configuration. Also, proxy operation and 
>minimizing network congestion for group >communication"
>
------------------------
[AKBAR] AS DEFINED IN SECTION 1.3, THE MAIN DIFFERENCE IS THAT "MULTICAST" 
IN OUR DRAFT REFERS TO "IP MULTICAST".  WHILE "GROUP COMMUNICATION" REFERS 
TO SENDING OF APPLICATION COAP MESSAGES OVER IP MULTICAST.  PERHAPS ONE 
CLARIFICATION WE CAN MAKE IS AS FOLLOWS TO THE "GROUP COMMUNICATION" 
DEFINITION IN SECTION 1.3:

FROM:
"Group Communication
A source node sends a single message which is delivered to multiple 
destination nodes ..."

TO:
"Group Communication
A source node sends a single application layer (e.g. CoAP) message which is 
delivered to multiple destination nodes ..."

DO YOU AGREE?

> address as a receive-only group.
------------------------
[AKBAR] IT IS OPTIONAL FOR THE SENDER TO BE PART OF THE COAP GROUP AS WE 
HAVE STATED IN THE DEFINITION OF GROUP COMMUNCATION IN SECTION 1.3.  (I.E. 
"The source node itself may be part of the group").   THIS IS HOW ALL 
UNDERLYING IP MULTICAST GROUPS WORK.

------------------------

>        The difference is not only in the meaning of words, but also by the 
------------------------
[AKBAR] WE STATED IN SECTION 2.2 ("Group URIs follow the CoAP URI syntax") 
SO I AM NOT SURE WHAT YOU MEAN BY DIFFERENT SYMBOL?  WE WILL HOWEVER CLARIFY 
WHAT "group communications request API" MEANS FROM THE SAME SECTION 2.2 AS 
THOMAS SUGGESTED.  WILL THAT ANSWER  YOUR QUESTION?

------------------------

>      If there is a dedicated CoAP Group Comm port number, the differece 
> for unicast and multicast are clear; all CoAP group comm can use that UDP 
> port number  and different groups are identified by >Group URI.
------------------------
[AKBAR] THE STANDARD WAY FOR A SERVER TO KNOW THAT IT RECEIVED A MULTICAST 
MESSAGE IS IDENTIFIED IN SECTION 2.8

> response. In case a CoAP client sent multiple group requests, >the 
> responses are as usual matched to a request using the CoAP Token."
------------------------

------------------------

> issues, but should reserve one to many configuration operations.

------------------------
[AKBAR] CURRENTLY IN COAP THE ONLY SECURITY IS ONE TO ONE (I.E. UNICAST 
DTLS).  THERE IS NO MULTICAST SECURITY.  SO I DON'T UNDERSTAND YOUR LAST 
SENTENCE?

------------------------

>     Maybe this is the critical issue of congestion control and this is out 

------------------------
[AKBAR] YOU ARE CORRECT.  WE ONLY GIVE RULES TO AVOID CONGESTION.  ANYTHING 
ELSE IS OUT OF SCOPE.

------------------------

------------------------

------------------------

Regards,

Gengyu

-----原始邮件----- 
From: Rahman, Akbar
Sent: Monday, December 16, 2013 10:23 AM
To: FOSSATI, Thomas (Thomas)
Cc: [email-masked]
Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Thomas,

Akbar

-----Original Message-----

Hi Akbar, Esko.

Cheers, Thomas.

Section 1.1

Section 1.3

Section 2.2

Section 2.3

Section 2.4

Section 2.5

Section 2.7

Section 2.7.2.1

Section 2.7.2.2

Section 2.7.2.3

Section 2.7.2.4

Section 2.7.2.5

Section 2.7.2.6

Section 2.7.2.7

Section 2.8

Section 2.10