Re: [6tisch] xxx-bootstrap

2016-12-01 Thread peter van der Stok
Hi Michael, thanks for a clear answer. I think the Registrar/JCE will need to support three protocols: 1) a push protocol over CoAP. 2) a pull protocol (RFC7030/EST). 3) a protocol to talk to the MASA (TBD) As discussed earlier, having a push/pull agnostic protocol would be nice. (and prob

Re: [6tisch] xxx-bootstrap

2016-12-01 Thread peter van der Stok
Hi Michael, all in favor of one approach to merge the push/pull aspects. (I have to understand the protocol exchange below, but it looks feasibale) I am not sure about understanding EDHOC, but may be that is not important. I still see all the mime formats. is that phase 1? Is phase 2 then swi

Re: [6tisch] Handling Inconsistent Allocation in 6P

2016-12-01 Thread Qin Wang
Hi Yasuyuki, I think nodeA=>nodeB request process includes two parts, one is Tx from nodeA to nodeB, another part is for nodeB's MAC to process the Request message. As you mentioned, failure of the first part can be identified by mac-ack from nodeB, but not the second part. Right? ThanksQin 

Re: [6tisch] Handling Inconsistent Allocation in 6P

2016-12-01 Thread Yasuyuki Tanaka
Hi Qin, I think nodeA=>nodeB request process includes two parts, one is Tx from nodeA to nodeB, another part is for nodeB's MAC to process the Request message. As you mentioned, failure of the first part can be identified by mac-ack from nodeB, but not the second part. Right? Yes, that's right

Re: [6tisch] Handling Inconsistent Allocation in 6P

2016-12-01 Thread Xavi Vilajosana Guillen
HI Yatch, thanks for your comments. Could you please summarize how the timeout will work in the 2 and 3 step transactions: I see it in this way: 2-step A sends to B an ADD, if A packet is lost, B will never realize and A will timeout. Idem if B response fails ( A timeouts) 3-step A sends to B an