IETF Logo Mail Archive

Re: [6tisch] [6TiSCH] return code in 6p response defined in sixtop draft

Qin Wang <qinwang6top@yahoo.com> Mon, 03 October 2016 19:20 UTC

Return-Path: <qinwang6top@yahoo.com>
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 5A2961294A0 for <6tisch@ietfa.amsl.com>; Mon, 3 Oct 2016 12:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.015
X-Spam-Level:
X-Spam-Status: No, score=-5.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 6FSO16uU2UH8 for <6tisch@ietfa.amsl.com>; Mon, 3 Oct 2016 12:20:40 -0700 (PDT)
Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D314129497 for <6tisch@ietf.org>; Mon, 3 Oct 2016 12:20:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475522439; bh=aoYjvtuL6wzqdkhIgMwqn92B3zCX7a3MeCx46uvZoV4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ZGeZ+PkOPmS8Di0/y3LJkx7zBQiAWZhcJ2fQ3XHKTbNe8siVVoTDwKw/8HGU0L33XWvBxPtdmpO7ywyPGfaHDNJ5krfWjV5Pkyn9ZWE3qDcfjKcoB5Bf2mYVza1/kyVjFwUVVG13FQW9O4znSc5AH1c8z7NHn+uvGy2nA/O0omHixx0tlvUg648h+aQKDw2G43ROXFgYVatCEGsH14r3RiVxWOpG5jv171GNA3d/JQVTHAevfGJOG89dkb5YdqDR0kAH4pB7+dO2HGSa9HtTI8GOGHO5whaWBTkkzdGhb41oM4YkM/XN7L51PV6ugxbEfo3SlukDCII87+3ZfD5cpw==
Received: from [66.196.81.174] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 03 Oct 2016 19:20:39 -0000
Received: from [98.139.212.202] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 03 Oct 2016 19:20:39 -0000
Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 03 Oct 2016 19:20:39 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 655149.24358.bm@omp1011.mail.bf1.yahoo.com
X-YMail-OSG: CipZulAVM1nOsGy338l08k6fIWwIGb_bTV_Z9_hfJUGRyyGOICwySc4q6ftF7hJ OtfCGRKGJb1Gsmn_hJ841DcFG5AQV4f3vzADhoWlYEnEWH6t7QQ0JuEFRDbLHnKRCxCgY9CQ_xBZ cO3sxyj1Qbdtdjf_C8o8vqohl76fOikX0YLmamWa3nnojjz4QZYYdE.Tg4jZW.SHlEmOaoHtDxGi mua927VzRTHh3SXdwM0SsWfuloSb0tBbOwl163OcHj1A_WjK1rXrk9yaaEOGh_Knx9oRduv12CKd q3LMy9nuB.XjtAzt8DlXpgq6WZLTXevARsJhYCTJUy4fUbEsfDzRBBj5LR7Y0vqPFVqRHTxPM2fM PTmlGYS7FmK4ULYWNDs8Bf18ApgbLsGefZnF9bqPkUfclDRvM_n.IxKXQ0XzbOZXIHQlPksoAMUW CwpMPJTlVJhNcmRVdC57utzUHrye8PwHuGIJtAdlDvmyfdcJj0zkv9U3j1BhnTFsM18M7fU46HX2 zMysMecXz1AKyWbsGGjoEQlgulrsuIssYsQi_ylM-
Received: from jws10686.mail.bf1.yahoo.com by sendmailws109.mail.bf1.yahoo.com; Mon, 03 Oct 2016 19:20:39 +0000; 1475522439.276
Date: Mon, 03 Oct 2016 19:20:38 +0000
From: Qin Wang <qinwang6top@yahoo.com>
To: "Dale R. Worley" <worley@ariadne.com>, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Message-ID: <1793512404.3595994.1475522438871@mail.yahoo.com>
In-Reply-To: <87shsdz2xx.fsf@hobgoblin.ariadne.com>
References: <CAMsDxWQNAH4_VT10_Y30aeiFSbmt27GBtdWiOB=ttcrpWvcbRg@mail.gmail.com> <87shsdz2xx.fsf@hobgoblin.ariadne.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3595993_1313212630.1475522438865"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/bkkEi4s89CJwzBsxYNYFsRVi87o>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "tengfei.chang@inria.fr" <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
Reply-To: Qin Wang <qinwang6top@yahoo.com>
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 19:20:42 -0000

Hi,
Regarding to how to choose a error code when multiple error codes could be candidate, I think we can use a simple rule as follows. If a specific error code, such as RC_ERR_NORES, is matched to the abnormal situation, then the specific error code must be used. If there is no specific error code is matched to the abnormal situation, then the generic error code RC_ERR must be used. 
BTW, I haven't seen there is any overlap among different specific error codes. Did I miss something?
ThanksQin

 

    On Monday, October 3, 2016 2:55 PM, Dale R. Worley <worley@ariadne.com> wrote:
 

 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 mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

v2.23.0 | Report a Bug | By Email