Yes. Except that if we do not adopt my proposed draft(s) that formally introduce
the SRV.* notion, i am not sure how long i want to explicitly explain that name
choice ;-)
Was there an adoption call?
Regards
Brian
On 09-May-22 05:12, Toerless Eckert wrote:
On Sat, May 07, 2022 at 06:32:57PM -0400, Michael Richardson wrote:
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?
Yes, someone could register service-name "est" for UDP and refer to rfc9148.
That was not my point. My point was that i don't think EST/HTTPs and EST/COAPS
are just one protocol with different underlying transports. Not because
they shouldn't, but just because our specs are too weak to formally make that
claim (IMHO!).
But i am somewhat inconsistent in my arguments here ;-))
> 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.
If we can agree on parameters for objective-value and DNS-SD TXT proto= key to
distinguish the different transport/variations, then IMHO it would be nicest
to stick to just brski-proxy and brski-registrar.
> 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?
Yes. Except that if we do not adopt my proposed draft(s) that formally introduce
the SRV.* notion, i am not sure how long i want to explicitly explain that name
choice ;-)
>> 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.
Yes. Aurelius said that the other groups like thread, who are working on
enrollment
seemingly haven't started to think about renewal... Maybe thats why nobody
brought it
up (yet).
Cheers
Toerless
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
