Christian, See inline.
Mališa On Thu, Apr 12, 2018 at 3:15 PM Christian M. Amsüss <[email protected]> wrote: > > > What would be the advantage of establishing a dynlink over specifying in > > the minimal-security draft that once the pledge joins, it needs to > expose a > > /j resource that the JRC may use to update the keying material? This > would > > essentially be a static link specified in the draft. Do you see any > pitfall > > with that? > > Apart from that we should not specify statically named resources in > devices' namespaces outside `.well-known/`, I see no problem with that. > So, we had /j exposed at the JRC for long time in the draft and I assumed this is OK because ACE is using something similar, i.e /token, /authz-info. Are you saying that we have to add 11 bytes without counting the option encoding to the Join Request because this is a static resource? Is there any way around this? > I wouldn't see it as a matter of being "an advantage of ... over", but > more of the dynlink being the theoretical background behind and > justifying what happens here; think of it as a form of compressed > exchange if you will. > Sounds good, I am working on the text tomorrow and will send you the PR to double check if it makes sense. > I don't think we have the consensus on the use of CoMI in > minimal-security. > > We considered it for future work, but at this point I would refrain from > > pulling in new specifications.. > > It might still be convenient to consider, eg. whether a future > implementor that *does* use CoMI can just treat your /j resource as an > alias to /c/abc0815 and be done with it, because a POST there with the > binary data has the desired effect. > I am not very familiar with CoMI so it could be a dummy question, but would we need to specify in the draft to allow this?
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
