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*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
