Toerless Eckert <[email protected]> wrote: >> 6.5.1. Discovery >> >> The Pledge discovers an IP address and port number that connects to >> the Registrar (possibly via a Join Proxy), and it establishes a DTLS >> connection.
> This is very terse and possibly not completely correct.
https://github.com/anima-wg/constrained-voucher/issues/224
> But the discovery itself is described in
draft-ietf-anima-constrained-join-proxy,
> right ? E.g.: it could involve either directly discovering brski.rjp if
there
> is no join proxy or discoverin brski.jp if there is a join proxy. True ?
> Would be good to at least provide an appropriate pointer that describes
this. And
> i am not sure that draft-ietf-anima-constrained-join-proxy actually
describes how
> a pledge would use either brski.jp or brski.rjp... ?
You are a bit right.
The discovery by the proxy of the Registrar on a *NON* ACP network uses
brski.rjp.
This discovery is *specific* to *this* kind of stateless join proxy.
The registrar and the proxy have to agree to use this extension.
The discovery by the pledge of the Registrar does not have any other place
discovery by CoAP RD. constrained-voucher does not define it, so that's why
it is in join-proxy.
>> No further discovery of hosts or port numbers is required, but a
> beyond the discovery described in the prior paragraph ? Would suggest to
> either remove this part of the sentence or add more details. As it stands
it
> is like be inserting into this email: It is not required to send toerless
chocolade.
> (huh, why the heck does toerless mention this - what other cases are there
> where toerless would actuallt expect chocoade. why does he mention
> it.. ?)
To point it your analogy, once we have determine that Toerless is Hungry, we
do not need to determine whether you want chocolate or not, because, only
triangular chocolate bars will fit through the transport protocol.
>> pledge that can do more than one kind of enrollment
>> (future work offers protocols other than [I-D.ietf-ace-coap-est]),
>> then a pledge may need to use CoAP Discovery to determine what other
protocols are
>> available.
> If the solultion os CoAP Discovery, then it seems the problem should
maybe also
> be rewritten to "pledge that can do more than one kind of enrollment
mechanism using CoAP".
The pledge could also do DPP or CHIP/MATTER or 802.1x, which is not using CoAP.
>> A Pledge that only supports the EST-coaps enrollment method SHOULD
>> NOT use discovery for BRSKI resources. It is more efficient to just
> Confused. Do i translate this correctly to say "do not use
brski.jp/brski.rjp discovery
> from anima-constrained-join-proxy" ?
brski.jp is used to find the proxy in order to reach the Registrar.
Once a connection to the Registrar is found, then the question becomes: can
the pledge do CMP as well as EST? If so, it might need to discover if the
Registrar can do that.
I haven't opened another issue yet,because I'm not sure what to write yet.
--
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
