Re: [core] #177: Response suppression for multicast not defined

"Rahman, Akbar" <Akbar.Rahman@InterDigital.com> Thu, 15 March 2012 19:50 UTC

Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1769921F8587 for <core@ietfa.amsl.com>; Thu, 15 Mar 2012 12:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.313
X-Spam-Level:
X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRszCq6vkSiN for <core@ietfa.amsl.com>; Thu, 15 Mar 2012 12:50:12 -0700 (PDT)
Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7833221F857F for <core@ietf.org>; Thu, 15 Mar 2012 12:50:12 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 15:50:11 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 15 Mar 2012 15:50:10 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C04608A20@SAM.InterDigital.com>
In-Reply-To: <FB642636-078D-41A6-8525-5604EA125218@tzi.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [core] #177: Response suppression for multicast not defined
Thread-Index: Ac0CFbNEXbbMNBN1RmmmoOdaqqIAAQAzk4uw
References: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org><066.924a528dfa41671c33a7c32467afea34@trac.tools.ietf.org><D60519DB022FFA48974A25955FFEC08C046085D1@SAM.InterDigital.com><AABA9EFA-250D-4D9B-8949-EE89FE1F8457@sensinode.com> <D60519DB022FFA48974A25955FFEC08C046085F8@SAM.InterDigital.com> <D60519DB022FFA48974A25955FFEC08C046088BB@SAM.InterDigital.com> <FB642636-078D-41A6-8525-5604EA125218@tzi.org>
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: "Carsten Bormann" <cabo@tzi.org>
X-OriginalArrivalTime: 15 Mar 2012 19:50:11.0135 (UTC) FILETIME=[D4E774F0:01CD02E4]
Cc: core issue tracker <trac+core@gamay.tools.ietf.org>, core WG <core@ietf.org>
Subject: Re: [core] #177: Response suppression for multicast not defined
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Mar 2012 19:50:13 -0000

Carsten,


Can you clarify what you mean by "We do not specify local processing ..."? 

I do not follow your logic.  For example, in coap-09 there is clearly specification language for local caching (http://tools.ietf.org/html/draft-ietf-core-coap-09#section-5.6).  So what did you really mean?



Akbar


-----Original Message-----
From: Carsten Bormann [mailto:cabo@tzi.org] 
Sent: Wednesday, March 14, 2012 3:07 PM
To: Rahman, Akbar
Cc: Zach Shelby; core issue tracker; core WG
Subject: Re: [core] #177: Response suppression for multicast not defined

> Thanks, I read coap-09 and saw the new text for multicast response
> handling in section 4.5.  One follow up question:
> 
> 
> - If the multicast message receivers (servers) do send back valid
> responses (e.g. successful Response to a GET), then the original sender
> (or some intermediate CoAP proxy) will receive multiple responses and
> will have to some method of filtering and processing the multiple
> responses.

That is the nature of multicast, so I would expect the need for that to be obvious.
We do not specify local processing, so what exactly the client does with the information is up to the implementer.

> - We show one possible use case in 
> 
> http://tools.ietf.org/html/draft-ietf-core-groupcomm-01#page-17

Indeed, but generally the core-coap draft is very sparse on use cases.

> - Should we have some text in coap-09 to cover this multiple response
> processing as well?

So, in summary, I do not see a need for additions to core-coap.

Grüße, Carsten