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 <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
