Re: [6tisch] [6TiSCH] return code in 6p response defined in sixtop draft
worley@ariadne.com (Dale R. Worley) Mon, 03 October 2016 18:55 UTC
Return-Path: <worley@alum.mit.edu>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00A91294BD for <6tisch@ietfa.amsl.com>; Mon, 3 Oct 2016 11:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.035
X-Spam-Level:
X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDcZECm3i9Xl for <6tisch@ietfa.amsl.com>; Mon, 3 Oct 2016 11:55:10 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101C0129489 for <6tisch@ietf.org>; Mon, 3 Oct 2016 11:45:49 -0700 (PDT)
Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-01v.sys.comcast.net with SMTP id r8EjbPg8CTaLwr8FJbu4Tp; Mon, 03 Oct 2016 18:45:49 +0000
Received: from hobgoblin.ariadne.com ([73.16.37.18]) by resomta-ch2-12v.sys.comcast.net with SMTP id r8FHbvDWKNw51r8FIbvEVM; Mon, 03 Oct 2016 18:45:49 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u93Ijk9u019560; Mon, 3 Oct 2016 14:45:46 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u93Ijk02019557; Mon, 3 Oct 2016 14:45:46 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
In-Reply-To: <CAMsDxWQNAH4_VT10_Y30aeiFSbmt27GBtdWiOB=ttcrpWvcbRg@mail.gmail.com> (xvilajosana@eecs.berkeley.edu)
Sender: worley@ariadne.com
Date: Mon, 03 Oct 2016 14:45:46 -0400
Message-ID: <87shsdz2xx.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfGIbeGhDF5vE3O0zx0uPbdDVaWAn+6bThrlR2mmFVLf/DQvfiUNJ23UiwgKZJ+55erqwajfvLhlaqFmPgtsxU2eh/emDpTwk+pkM203OGHEOOdpZkndt Twnh2x+4DLiI2rvSAcV0o3PYoxaNlUcU5idhMEPywv8EenJ02WSo8PL2nIqB3US6TV3GXQEOaZjoGdXyPJSdYdOvQEAtwxSU7mYEE4zKPvaV2l4BSd+8YQuj 3j8k0UoUhWDKjdg08B32ng==
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/JMVHQNPyvaRLZD55f6RXwgGp4Cs>
Cc: 6tisch@ietf.org, tengfei.chang@inria.fr
Subject: Re: [6tisch] [6TiSCH] return code in 6p response defined in sixtop draft
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2016 18:55:11 -0000
Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> writes: >> - Also, if the 6p response has multiple cases matched (for example, >> the candidate cells are occupied RC_ERROR and also no enough resource >> ERROR_NORES...), which one should the mote choose? (add priority for the >> error code? at least we need a decision) >> > that is a good point. The two options I see are, either returning the list > of error codes or defining priorities and returning the most important. We > should consider that in the next version of the draft. I've seen situations in another protocol (SIP) where a single request could be responded to with multiple error codes. There has been no pressure to specify which of the possible error codes MUST be returned. The understanding is that different implementations process various aspects of a request in different orders, and that an implementation will generally return the first error condition that it discovers and then abort processing of the request. A rule for which of the multiple errors must be returned would require either that an implementation process the request in a fixed order, or that it must somehow complete processing and then select the "best" error code. Worse, if a request is erroneous in one particular aspect, then it may be ill-defined whether it is erroneous in another particular aspect. Dale
- [6tisch] [6TiSCH] return code in 6p response defi… Tengfei Chang
- Re: [6tisch] [6TiSCH] return code in 6p response … Xavier Vilajosana
- Re: [6tisch] [6TiSCH] return code in 6p response … Dale R. Worley
- Re: [6tisch] [6TiSCH] return code in 6p response … Qin Wang
- Re: [6tisch] [6TiSCH] return code in 6p response … Tengfei Chang
- Re: [6tisch] [6TiSCH] return code in 6p response … Xavi Vilajosana Guillen
- Re: [6tisch] [6TiSCH] return code in 6p response … Thomas Watteyne