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

[Brian E Carpenter <[e-mail]>]

On 06-May-22 05:37, Michael Richardson wrote:
> 
> 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.

You can define that a null value is equivalent to "EST-TLS", if there
is existing code that will break otherwise.

     Brian

> 
>      > 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
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>