On Tue, Feb 20, 2018 at 10:00:10PM -0500, Michael Richardson wrote: > > Yes, that in the thread, where I referred to a thread back in January 2017, > in which you were involved in coming up with the names. > > >> + , and may be > >> + enabled only if the JRC indicates support for them in it's > >> + announcement. (See Section 4.4) > > > IMHO: sentence eend after "optional". Followed by "all proxy > functionally > > needs to ... be enabled... > > > Aka: circuit proxy is a no-op too if the proxy does not discover a > registrar > > supporting it. Not specific to advanced options. > > Circuit proxy is a MTI for the JRC, and requires *NO* special support in the > JRC. > If the Registrar doesn't support listening on port 443, then it's not a > registrar :-)
Maybe i just have an english language problems: "may (be only enabled) if" implies to me "could also (be enabled) even if not", but that would not be correct: No version of a proxy can be enabled unless a registrar has been discovered by the proxy AND that proxy is announcing support for the proxy method. And that applies to all proxy methods. correct language: "can be only enabled if" ? ^^^ If i misunderstand english: what is the difference between may/can in this sentence ? circuit-proxy is only MTI for ANI registrars, these sentences are not constrained to ANI. I would assume in some derived solutions like 6tisch or the like, registrar may only have non-circuit proxies.. ?! Sorry if this is too much nitpicking. > > Rephrase ? Don't understand what this means (especially users). "other > > authors" ? "other docs" ? > > If someone is using BRSKI in a non-ANI situation, then that entity should > explain what kinds of things can occur after voucher. So I prefer to remain > mute. ah! "user" = "author of followup work". Thanks! Toerles > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima