Toerless Eckert <[email protected]> wrote: >> I'm not sure that I agree with the name "est-coaps", as I think it's still >> "est" with a transport of CoAP/UDP.
> a) I think you're logically right, but practically we do not have any
actual
> formal service specification agnostic to transport for that abstract EST,
> such as a TAP-like service interface definition. We only have stuff in
> rfc9148 and ANIMA cBRSKI draft that reads: "this does the same as XXX
> in RFC7030/RFC8995".
I thought in DNS-SD, one would ask for _est._udp.local?
> b) I was just looking at the openthread brski code, and it would be
interesting
> to see how far one could get with actual code and a set of API functions
> shared bteween BRSKI/cBRSKI..
I haven't read that code due to unclear IPR around the patents in Thread.
> c) Can i circle that argument back to you and ask why we should actually
> introduce brski.jp/brski.rjp if we already have brski-proxy and
brski-registrar ?
I'm open to any name.
> For unicast, what exactly is then the method to discover the URI of the
> registrar (across >= 1 L3 hop) ? If there is some mandatory support
> not only for unicast DNS (requests) but also automatically working
GRASP SRV.est?
>> If not for the above, I think that we would not have split RFC9148 out.
> What do you men with "split out" ?
est-coaps and constrained-voucher/brski could have been one document.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
