> Should we also rename draft-ietf-anima-constrained-join-proxy to brski-proxy?
The drafts name is currently "Join Proxy for Bootstrapping of Constrained
Network Elements".
It uses the term "Join Proxy" for the thing defined, which is directly imported
from RFC 8995.
Join Proxy:
A domain entity that helps the pledge join the domain. A Join Proxy
facilitates communication for
devices that find themselves in an environment where they are not provided
connectivity until
after they are validated as members of the domain.
So as long as the function of the proxy is network/domain joining, we can keep
using "Join Proxy" per 8995, I think?
If more functions get added to it, agree that we might need a different name.
Esko
-----Original Message-----
From: Michael Richardson <mcr+i...@sandelman.ca>
Sent: vrijdag 14 maart 2025 10:35
To: Fries, Steffen <steffen.fries=40siemens....@dmarc.ietf.org>; anima@ietf.org
Subject: [Anima] Re: draft-ietf-anima-brski-discovery feedback/review
Fries, Steffen <steffen.fries=40siemens....@dmarc.ietf.org> wrote:
> Proposal to refer to the "BRSKI proxy" rather
> as "Join proxy" or "BRSKI Join proxy" as defined in RFC 8995. If the
> functionality goes beyond the join proxy, we should define the term
Should we also rename draft-ietf-anima-constrained-join-proxy to brski-proxy?
> Section 3.1.5 - The variations for vformat only relate to the "outer"
> format. With the current approaches in BRSKI, BRSKI-PRM and cBRSKI this
> is consistent as they do not provide further variations of inner/outer
> format. In BRSKI CMS is used as a wrapper for JSON. If some draft in
> the future utilizes a different format wrapped with CMS, the variation
> type "cms" is no longer unique. One approach may be to name it
> "cms-json" instead.
yes, that's reasonable.
> Section 3.2.1 - Just a thought: The last two paragraph regarding
> resilience may be put in a separate "operational consideration
> section". On the other hand this would rip the description and the
> considerations also in other sections apart. This is also valid for
> other section. Right now, I'm seeing a benefit in keeping the
> information together.
+1
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
