Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > Here is what i think, please reject points if you have arguments against them,
    > otherwise i'd assume you agree ;-):

    > 1. "AN_join_registrar" and "AN_Proxy" where defined in RFC8995 for use with ANI.
    > To me that means those objectives indicate that by default those objectives
    > will provide ANI/ACP certificates.

Agreed, but remember that RFC8994 also defines SRV.est for renewal.
(I sometimes think that RFCs ought to have a commentary, much like the Torah
(old-testament) has the Mishnah which is a series of commentaries.)

    > 2. There is no need to introduce new objective values just because we use a new
    > protocol (EST-coaps instead of EST-tls). Instead, that should be done via
    > the objective-value. RFC8995 already nicely uses "EST-TLS" for "AN_join_registrar".
    > I have no idea why we did not also do this for "AN_Proxy", but we just left it
    > blank there. But we can easily assume that Empty ("" as in the RFC8995 example)
    > is the same as "EST-TLS".

I agree completely.
I would go as far as Amending RFC8995 to say that "EST-TLS" should be inserted.
I'm not sure what document to that in.  Perhaps we should plan to write an
ANI/ACP Updates document.

    > 3. I think the GRASP announcements MUST indicate what mode the Registrar
    > supports. Stateful or stateless. Or if it supports both, then just have
    > GRASP announcements for both and let the Proxy pick.

Yes.

    > 4. I think by using explicit objective-values to indicate the protocol we are
    > also future proof when we come up with even more protocols like CMP or the like.

Yes, do we need a Registry for this?

    > 5. The constrained proxy draft describes three discovery options:
    > (a) Proxy Discovers Registrar
    > (b) Pledge discovers Proxy
    > (c) Pledge discovers Registrar.
    > In ANI/ACP, we do not have case (c). I do not see how it could ever happen,
    > so we should not introduce it.

That's my position.
I explained at:
  https://www.ietf.org/archive/id/draft-richardson-anima-registrar-considerations-05.html#name-join-proxy-southbound-inter

that the Registrar should announce it's own TLS (and DTLS) ports using
AN_proxy.   No actual proxy functionality is necessary.

    > 6. To me, this means the ANI/ACP service discovery for use with constrained proxy are:

    > Proxy Discovers Registrar:

Proxy Discovers Join Proxy.

    > objective-name:  "AN_join_registrar", protocol UDP, objective-value: "EST-COAPS"
    > objective-name:  "AN_join_registrar", protocol UDP, objective-value: "EST-COAPS-JPY"

The third one makes no sense.

    > Pledge Discovers Proxy:
    > objective-name:  "AN_Proxy", protocol UDP, objective-value: "EST-COAPS"
+   > objective-name:  "AN_Proxy", protocol UDP, objective-value: "EST-COAPS-JPY"

Here it makes sense.

    > 7. Until there is sufficient proof of the opposite, i will claim that multihop
    > ASM IP Multicast in support of admin-scope COAP group communication via ff05::fd
    > will not exist in the mayority of target deployments of constrained proxy.

I agree that multicast is unlikely in many LLNs.
I don't agree that we need to do something for GRASP outside of ACP.

> 9. In result, i would suggest:

Not sure how this differs from #6.

    > Logic for Pledge is simple: If it can discover a registrar via "brski-rjp"/"EST-COAPS",
    > then it uses that. Else it has to look for "brski-jp"/"EST-COAPS"

No, this is very wrong.
RJP is only for Proxy<->Registrar, and the pledge NEVER sees that.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide