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

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

-----原始邮件----- 
From: weigengyu
Sent: Wednesday, December 18, 2013 12:38 PM
To: Rahman, Akbar
Subject: Re: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hi Akbar,

This email is "about group configuration"

In the draft, you gave
>2.1 in "2.3. Port and URI Configuration"
  "All CoAP multicast requests MUST be sent using a port number according to
one of below options:
    1. A pre-configured port number.
    2. If the client is configured to use service discovery ......
    3. Use the default CoAP UDP port (5683).

My comment is that three options are not better than on dedicated one.
It possible and necessary to define a dedicated port number for CoAP Group
Comm ?
If you think not, just ignor this problem.

>>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.
------------------------
> [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?

Yes.

> [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?
> ------------------------

[RFC3542] is possile to use. But RFC3542 is defined for using raw IPv6
sockets.
CoAP protocol stack has UDP over IPv6.  So, I do not prefer this cross layer
mechanism.
So, I think that it is better for the UDP and CoAP to have an explicit
identifier of multicast or group communications.

>>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.  "
------------------------
> [AKBAR] BUT THERE IS NO "CoAP URI"  IN A RESPONSE?

Current draft is that "THERE IS NO "CoAP URI"  IN A RESPONSE?", and the
related problem are aready understood.
Maybe, Change to: "The CoAP client can distinguish the origin of multiple
server responses by source IP address of the UDP message or other unique
identity.  "
Otherwise, leave the problem left.

>>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.

> [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?
Yes. current DTLS supports unicast.
And I am sure that you might know more than I do about DTLS supporting
multicast, i.e. "DTLS-based Multicast Security for Low-Power and Lossy
Networks (LLNs)" .

I suggest that for configuration operations a client is permitted to use
mulitcast CoAP methods as option.

>>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.
>------------------------
>[AKBAR] YOU ARE CORRECT.  WE ONLY GIVE RULES TO AVOID CONGESTION.  ANYTHING 
>ELSE IS OUT OF SCOPE.
------------------------
Why not to use congestion avoidance.

There are common senses about congestion avoidance and control after the
famous paper
"Congestion Avoidance and Control V. Jacobson (Originally Published in:
Proc. SIGCOMM '88" even that is about TCP.

comments are above.

Regards,

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

-----原始邮件----- 
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

>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?
------------------------
[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?
-------------------------

>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.
------------------------
[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.

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

>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.
------------------------
[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?

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

>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.
------------------------
[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?
------------------------

>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.  "
------------------------
[AKBAR] BUT THERE IS NO "CoAP URI"  IN A RESPONSE?

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

>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.

------------------------
[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?

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

>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.

------------------------
[AKBAR] YOU ARE CORRECT.  WE ONLY GIVE RULES TO AVOID CONGESTION.  ANYTHING
ELSE IS OUT OF 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.

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

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

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

- 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
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 18 Dec 2013 08:25:28 +0000

Hello,

> It possible and necessary to define a dedicated port number for CoAP Group Comm ?
The current CoAP model is that it allows to use any available UDP port; and in GroupComm we simply follow that model.

> [RFC3542] is possile to use. But RFC3542 is defined for using raw IPv6 sockets.
> CoAP protocol stack has UDP over IPv6.  So, I do not prefer this cross layer mechanism.
> So, I think that it is better for the UDP and CoAP to have an explicit identifier of multicast or group communications.
I agree this might be easier for detection at the CoAP level. However, it does mean a (malicious, or sloppy) client could send a unicast-formatted CoAP request inside an IP multicast packet. That again poses security/congestion risks if the servers are unaware of this fact. And besides current core-coap which is nearly done, does not have a flag to indicate 'multicast'.

> Maybe, Change to: "The CoAP client can distinguish the origin of multiple server responses by source IP address of the UDP message or other unique identity.  "
I agree with this proposal. It is not mandatory to use the source IP address of the UDP message if another means of identification is present in the response. E.g., some ID in the payload or the recently proposed "NodeID" option or similar, in the future.

> I suggest that for configuration operations a client is permitted to use mulitcast CoAP methods as option.
I don't see a use case yet for multicast configuration (PUT/POST). Maybe a multicast GET on "All CoAP nodes" to quickly gather group membership info is useful for some?
The MUST we have there provides the best interoperability for those who implement the interface.  But we could consider that multicast MAY be used for GET requests on this interface. (That would be allowed then without DTLS, since these GET requests do not actually change the configuration on nodes)
Akbar/all, any comments?

> Why not to use congestion avoidance.
The term "Congestion control" is taken over from core-coap. I'm not sure whether there are general definitions of both? The Jacobson paper seems to suggest that "control" is the active identification of congestion problems in the network and fixing them.
We rather use the term as the specific policies/mechanisms that both clients and servers have to apply, or may apply, to reduce the risk of network congestion.

Esko

________________________________
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: "Rahman, Akbar" <[email-masked]>
Date: Thu, 19 Dec 2013 12:03:26 -0500

Hi Esko,

>The MUST we have there provides the best interoperability for those who implement the interface.  But we could consider that multicast MAY be used for GET requests on this interface. (That would >be allowed then without DTLS, since these GET requests do not actually change the configuration on nodes) 

>Akbar/all, any comments?

I think that configuration information can often be sensitive as well (e.g. it can give valuable hints to an attacker).  So we should just stick to our current approach of keeping the whole Group Membership Configuration RESTful interface as MUST be unicast (pt-to-pt) and SHOULD use DTLS.

Best Regards,

Akbar

-----Original Message-----
From: Dijk, Esko [mailto:[email-masked]] 
Sent: Wednesday, December 18, 2013 3:25 AM
To: weigengyu; [email-masked]
Cc: Rahman, Akbar
Subject: RE: [core] WGLC comments for draft-ietf-core-groupcomm-17

Hello,

I don't see a use case yet for multicast configuration (PUT/POST). Maybe a multicast GET on "All CoAP nodes" to quickly gather group membership info is useful for some?
The MUST we have there provides the best interoperability for those who implement the interface.  But we could consider that multicast MAY be used for GET requests on this interface. (That would be allowed then without DTLS, since these GET requests do not actually change the configuration on nodes) Akbar/all, any comments?

Esko