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