Re: [Anima] draft-ietf-anima-constrained-voucher discovery questions

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide