(I just realized that I forgot to CC the 6tisch ML for the previous exchanges.)
See below. On Thu, Apr 19, 2018 at 10:55 AM Christian M. Amsüss <[email protected]> wrote: > Hi Mališa, > > On Thu, Apr 19, 2018 at 08:24:57AM +0000, Mališa Vučinić wrote: > > I agree that sending the path exposed at the pledge would be quite clean > > but I don't get the benefit of it since we need to hardcode /j at the JRC > > anyways. For the JRC and the pledge to be interoperable, pledge needs to > be > > hardcoded with /j to send the Join Request, and the increment for the JRC > > to be hardcoded with /j to send the rekeying request to the pledge is > > minimal IMO. > > I think it's one thing to mandate a path to the JRC (which is part of > the "any-cast group" 6tisch.arpa, which by the way is a trick I find > very neat), and another for the pledge. > > What does ease my concerns a bit is that those resources are anyway > limited to what I'd call the virtual host induced by the OSCORE context. > > > > If CBOR is used to glue the two things (the request hex-stuff, I don't > > > remember what exactly that was) and the path) together, 16 bytes of > > > hex-stuff and 1 byte of path become 21 bytes of payload. > > Side note: Looking through -05 again I noted that the "hex-stuff" I > mentioned is already in a join_request CBOR; the overhead associated > with the path would be further decreased. > Yes, that's right, we could extend the join_request struct, if we get pushback on this. > But yeah, sticking with /j with the option of adding that to > join_request if there is pushback sounds like a viable option right now. > Sounds good! > > I am considering POST for both the initial Join Request, and for the > > rekeying request. That should be fine, right? > > The requests for join and re-join from the node to the JRC sound good > with POST. Who would send a re-keying request -- the node or the JRC? > Current text specifies that rekeying is triggered by the joined node, but I am talking about the update to the text where the rekeying request is sent by the JRC to /j resource exposed by the joined node. POST should be fine there, as well, right?
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
