> > 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 On Behalf Of Toerless Eckert
Sent: Sunday, May 8, 2022 19:12
To: Michael Richardson
Cc: anima@ietf.org
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 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
