[6tisch] I-D Action: draft-ietf-6tisch-terminology-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF. Title : Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e Authors : Maria Rita Palatte

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

Hi Malisa, I have a question about the join protocol described in sections 5-6. The pledge sends a EDHOC message_1 to JRC via a stateless proxy. It is not clear to me what happens when more than 1 proxy forwards the message to the JRC. Peter Mališa Vučinić schreef op 2017-06-15 11:05: All,

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

Hi Peter, I’m missing context on how would that happen. The pledge selects *one* JP based on the Join Metric in the received EBs. It fills the destination IPv6 address in the packet with JP’s link-local address and sends it. How would multiple proxies forward the message in that case? Mališa

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

The discovery section had disappeared. I see now that discovery and selection is done during ND. That removes my worry, peter Mališa Vučinić schreef op 2017-06-19 15:12: Hi Peter, I’m missing context on how would that happen. The pledge selects *one* JP based on the Join Metric in the recei

[6tisch] 6TiSCH interop: 6LoRH and OSCOAP as a requirement?

Hi, In the current description, the nodes are expected to run, among others, 6LoRH and OSCOAP. Question: how much will be able to test if we don't support any of the above? Particularly worried about 6LoRH: will the single-hop tests be possible between nodes that support 6LoRH and nodes that don'

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

peter van der Stok wrote: > I have a question about the join protocol described in sections 5-6. > The pledge sends a EDHOC message_1 to JRC via a stateless proxy. > It is not clear to me what happens when more than 1 proxy forwards the > message to the JRC. Are these messages fr

[6tisch] Question about TD

Hello, I got a question about 6P04: obj: Check that concurrent transaction cannot request for the same cells in the schedule according to draft-ietf-6tisch-6top-protocol-05 cfg: star ref: IEEE802.15.4-2015, draft-ietf-6tisch-6top-protocol-05 pre: - The DAGroot sends EBs periodically,

Re: [6tisch] Question about TD

Hi Remy, this is a concurrent situation so both should happen almost at the same time. The return code to 6N2 is BUSY. regards, X 2017-06-19 16:37 GMT+02:00 Remy Leone : > Hello, > > I got a question about 6P04: > > obj: Check that concurrent transaction cannot request for the same cells > in

Re: [6tisch] Question about TD

If it is a concurrent situation it's also likely that 6N1 will receive the BUSY. There is no explicit locking. Le lun. 19 juin 2017 à 18:13, Xavi Vilajosana Guillen a écrit : > Hi Remy, > > this is a concurrent situation so both should happen almost at the same > time. The return code to 6N2 is

Re: [6tisch] Question about TD

Hi Remy, in my way of seeing this, and assuming 6N1 goes first in the transaction, 6N2 will receive the BUSY as the resource is locked by 6N1, 6N1 will be able to finalize as it started the transaction before 6N2 and locked the resources. Note that the request message lock the resources. I want t