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

All,
I have captured this discussion in
https://trac.tools.ietf.org/wg/6tisch/trac/ticket/45. Let's discuss at the
interim and make a decision.
Thomas

On Thu, Oct 6, 2016 at 9:31 PM, Xavi Vilajosana Guillen <xvilajosana@uoc.edu
> wrote:

> Hi Tengfei,
>
> thanks for your effort on going through the details of the error codes.
>
> see inline:
>
>
>
> 2016-10-04 10:37 GMT+02:00 Tengfei Chang <tengfei.chang@inria.fr>:
>
>> Hi Professor, all
>>
>> Probably there is no overlap between specific error code. But some
>> concept of the error code is not that clear for me.
>> =================================
>> In section 4.3.8 about aborting a 6P Transaction:
>>
>> 4.3.8 <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02#section-4.3.8>.  Aborting a 6P Transaction
>>
>>    In case the receiver of a 6top request fails during a 6P Transaction
>>    and is unable to complete it, it SHOULD reply to that request with a
>>    6P Response with return code RC_ERR_RESET.  Upon receiving this 6top
>>    reply, the initiator of the 6P Transaction MUST consider the 6P
>>
>>    Transaction as failed.
>>
>> I am thinking here when it says
>> a 6top request fails during a 6P Transaction
>>
>>    and is unable to complete it
>>
>>
>> what is the definition of  6top request fails OR is unable to complete
>> it? If there is specific reason, we can use an specific ERROR code for
>> that. The current content (for now) says, the nodes doesn't know the
>> reason, so return with RC_ERR_RESET. If this is the case, the content
>> trying to say, it more like a undefined error, in case we can't cover all
>> error.
>>
>> Also what does the RESET mean?  Reset the sixtop transaction? then what
>> the default status of sixtop transaction? May somewhere in the
>> draft/concept I missed? Please let me know.
>>
>
> XV>> I think that reset means CLEAR the transaction state, that is for
> example unlock the cells that have been temporally reserved for the
> transaction, clear any state machine or state variable that indicates that
> a transaction has been initiated.
>
> XV>> as a consequence of your comment, maybe we have to clarify that in
> the draft.
>
>>
>> =================================
>> Xavi,
>>
>> If a node receives a 6P Request from a given neighbor before
>>    having sent the 6P Response to the previous 6P Request from that
>>    neighbor, it MUST send back a 6P Response with a return code of
>>
>>    RC_ERR.
>>
>> this is, a Node A has still not received from Node B the response of a
>> command while A issues again a command to B. In this case B responds with
>> RC_ERR.
>>
>> RC_ERR is defined as generic error in the table. However, this content is
>> saying a specific case, rather than a generic error. Maybe generic is not
>> the right term
>>
>> Also when should we use a generic error?
>>
>
> XV>> good point. Generic is not a good term. We should definitely be more
> clear with the errors. I would say this is an error that indicates that the
> operation is not permitted as there is an ongoing transaction.
>
>>
>> =================================
>> Dale,
>>
>> Indeed, there is an order for sure when the sixtop is implemented.
>>
>>
>> I am wondering If we didn't define this order in the draft and let the
>> implementer choose.
>> what happens when we do interoperability test, if one sixtop
>> implementation return error code is not expected  as the other sixtop
>> implementation.
>>
>> Maybe it's fine, but at least we need keep the following error codes with
>> higher return priority than other.
>>
>> RC_ERR_VER
>>
>> RC_ERR_SFID
>>
>> maybe also RC_ERR_GEN
>>
>>
>> Please let me know if there is something I misunderstand from the draft.
>>
>>
>> Tengfei
>>
>>
>>
>> On Mon, Oct 3, 2016 at 9:20 PM, Qin Wang <qinwang6top@yahoo.com> wrote:
>>
>>> 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?
>>>
>>> Thanks
>>> Qin
>>>
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>
>>
>> --
>> Chang Tengfei,
>> Pre-Postdoctoral Research Engineer, Inria
>>
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> Dr. Xavier Vilajosana Guillén
> Research Professor
> Wireless Networks Research Group
> Internet Interdisciplinary Institute (IN3)
> Universitat Oberta de Catalunya
>
> +34 646 633 681| xvilajosana@uoc.edu | Skype: xvilajosana
> http://xvilajosana.org
> http://wine.rdi.uoc.edu/
>
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 5. Edifici B3
> 08860 Castelldefels (Barcelona)
>
>
>
> 
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________