On Fri, Sep 7, 2018 at 6:30 PM Tero Kivinen wrote:
> Mališa Vučinić writes:
> > Yes, I think it can be made to work, but I think it is quite a lot of
> > work and code just to be able to claim to be "stateless".
> >
> > I don't quite agree that what is typically a one-liner to schedule a
Mališa Vučinić writes:
> Yes, I think it can be made to work, but I think it is quite a lot of
> work and code just to be able to claim to be "stateless".
>
> I don't quite agree that what is typically a one-liner to schedule a timeout
> event and a couple of lines of code in the callback
Hi Tero,
Just getting back to this after my vacation, see inline.
Mališa
On Fri, Jul 27, 2018 at 8:25 PM Tero Kivinen wrote:
> Mališa Vučinić writes:
> >
> > The question now is when to remove the entry with secExempt for
> > pledge at JP, once it was installed from Stateless-Proxy. From the
Mališa Vučinić writes:
> For the upper-layer protocol, this seems to degrade performance in
> case a pledge generates a frame *after* JP has already forwarded
> one packet from the pledge to the JRC and used Stateless-Proxy. In
> that case, pledge will need to do one L2 retransmission to get the
(snip)
On Tue, Jul 17, 2018 at 10:13 PM Tero Kivinen wrote:
>
> I would like at least some text in the security considerations section
> warning about the common wrong ways of generating PSK. The IoT vendors
> are quite often care more about the time to market than the security,
> thus do use
Hi Tero,
Thank you for this extensive review! See my responses inline.
Mališa
On Thu, Jun 28, 2018 at 12:24 AM Tero Kivinen wrote:
> In section 3 there is text saying:
>
>The "network identifier" uniquely identifies the 6TiSCH network in
>the namespace managed by a JRC. Typically,
In section 3 there is text saying:
The "network identifier" uniquely identifies the 6TiSCH network in
the namespace managed by a JRC. Typically, this is the 16-bit
Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4].
Note, that the PAN ID is not stable. The PAN
