Re: [Anima] FYI: est-coaps registered (was: Re: Discovery of proxy/registrar insufficient (GRASP and) more).

[Esko Dijk <[e-mail]>]

> > 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).

Is this about discovery of a Registrar and why nobody yet brought up yet how to do this? 

Speaking for the OpenThread case at least, it is not because we didn't think about renewal. Renewal is done using EST-coaps, triggered either internally (by the device itself when its certificate is close to expiry) or by an external management tool (that sends a proprietary, secure message to trigger the renewal process).
Currently there's an alternative to standardized discovery methods defined - so a proprietary unicast method that a mesh device can use to get any additional data it needs for network operation. And that includes the Registrar's IP address.  We're looking into if that proprietary method can just be replaced by DNS-SD unicast query because that feature has been recently added to OpenThread (https://openthread.io/reference/group/api-dnssd-server  - it's actually a client).

Adding my 2 cents to the discussion: we currently have defined "Constrained BRSKI" as really a different protocol from "BRSKI". It is not just about running BRSKI over a different transport - it defines a fair amount of optimizations, shortcuts etc. to make it more suitable for constrained nodes & networks. REST resource names are also different; procedures are deviating, etc. So at least we can consider it as a different protocol and assign a different service-name.

>     > 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 ?

For CoRE Link Format discovery, there's a wish to make the names as short as possible. And if we consider Constrained BRSKI a different protocol then these names can differ too. So it is not just the same as a CoRE representation of a DNS(-SD) service.
Also, the brski.rjp is really a different thing from brski-registrar - the brski.rjp denotes a server that's able to handle the "JPY" protocol that's defined in 5.3 of draft-ietf-anima-constrained-join-proxy. 

Regards
Esko

-----Original Message-----
From: Anima <[e-mail]> On Behalf Of Toerless Eckert
Sent: Sunday, May 8, 2022 19:12
To: Michael Richardson <[e-mail]>
Cc: [e-mail]
Subject: Re: [Anima] FYI: est-coaps registered (was: Re: Discovery of proxy/registrar insufficient (GRASP and) more).

On Sat, May 07, 2022 at 06:32:57PM -0400, Michael Richardson wrote:
> 
> Toerless Eckert <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/anima