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. ================================= 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? ================================= 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
