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 <xvilajos...@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.ch...@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 <qinwang6...@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 <wor...@ariadne.com> >>> wrote: >>> >>> >>> Xavier Vilajosana <xvilajos...@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| xvilajos...@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 _______________________________________
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
