On 06-May-22 05:37, Michael Richardson wrote:
Toerless Eckert <t...@cs.fau.de> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
