Fries, Steffen <[email protected]> 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
