[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/>
- [core] #177: Response suppression for multicast n… core issue tracker
- Re: [core] #177: Response suppression for multica… core issue tracker
- Re: [core] #177: Response suppression for multica… Rahman, Akbar
- Re: [core] #177: Response suppression for multica… Zach Shelby
- Re: [core] #177: Response suppression for multica… Rahman, Akbar
- Re: [core] #177: Response suppression for multica… Rahman, Akbar
- Re: [core] #177: Response suppression for multica… Carsten Bormann
- Re: [core] #177: Response suppression for multica… Dijk, Esko
- Re: [core] #177: Response suppression for multica… Carsten Bormann
- Re: [core] #177: Response suppression for multica… Rahman, Akbar