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

"core issue tracker" <trac+core@trac.tools.ietf.org> Sun, 06 November 2011 16:39 UTC

Return-Path: <trac+core@trac.tools.ietf.org>
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 EEC6521F84FC for <core@ietfa.amsl.com>; Sun, 6 Nov 2011 08:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level:
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 GlQ9W5lTiK55 for <core@ietfa.amsl.com>; Sun, 6 Nov 2011 08:39:07 -0800 (PST)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6A89221F84F8 for <core@ietf.org>; Sun, 6 Nov 2011 08:39:07 -0800 (PST)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+core@trac.tools.ietf.org>) id 1RN5kB-0008Ud-Jk; Sun, 06 Nov 2011 11:38:51 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: core issue tracker <trac+core@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org
X-Trac-Project: core
Date: Sun, 06 Nov 2011 16:38:51 -0000
X-URL: http://tools.ietf.org/core/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/177
Message-ID: <051.f2c70308ab0d71f7798afa515a549f6b@trac.tools.ietf.org>
X-Trac-Ticket-ID: 177
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org
X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To:
Resent-Message-Id: <20111106163907.6A89221F84F8@ietfa.amsl.com>
Resent-Date: Sun, 06 Nov 2011 08:39:07 -0800
Resent-From: trac+core@trac.tools.ietf.org
Cc: core@ietf.org
Subject: [core] #177: Response suppression for multicast not defined
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: trac+core@trac.tools.ietf.org
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: Sun, 06 Nov 2011 16:39:08 -0000

#177: Response suppression for multicast not defined

 Matthieu Vial reports:


 In section 4.1 multicast of coap 03 there is a proposition to eliminate
 responses with an error code

 This text has been removed in 07 and the text "SHOULD be a Non-confirmable
 request" is now a "MUST be Non-confirmable request".
 But as I understand coap 07 it is possible to send a response with an
 error code to a NON request as a NON response.
 So I think the text in coap 03 is now missing to avoid response floods.

 Carsten Bormann replies:

 indeed, as we fixed the layering here, we lost this functionality.

 So what the text in 07 says is that multicast needs to be NON, not CON.
 This is at the reliability layer.

 The error code becomes visible at the request/response layer.
 Independent of whether the request is a NON or a CON, if it does arrive,
 the server normally will send a response.
 1) It is up to the server to decide whether the response is sent in a CON,
 piggy-backed in an ACK (only applicable to CON requests, which we just
 excluded), or in a NON.
 2) We need to describe what the expectations are when a server does not
 send a response at all.  I think the server should always send a response
 for a request that arrived via a CON.  However, for a NON-request, it
 might as well pretend it never got the request.  This is a bit of a layer
 violation, as the reliability layer would indicate to the request/response
 layer wether the request was a NON and whether it came in by multicast.

 So yes, I think there should be new text in 4.4 that says the reliability
 layer does indicate to the r/r layer that this was a multicast.  There
 also should be text, probably in 5.2.3, that restores some form of silent
 behavior for requests that are "not applicable".  This needs to be defined
 a bit better, I think (even an empty 2.04 might qualify for a "not
 applicable" here, say in a link-format request with a query.  Note that
 section 4.1 of draft-ietf-core-link-format-07.txt also has something to
 say about multicast.

-- 
--------------------------------+------------------------------------
 Reporter:  cabo@…              |      Owner:  draft-ietf-core-coap@…
     Type:  protocol defect     |     Status:  new
 Priority:  major               |  Milestone:
Component:  coap                |    Version:
 Severity:  Active WG Document  |   Keywords:
--------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/177>
core <http://tools.ietf.org/core/>