"may" is an ambiguous word in English, and is probably the main reason
we have RFC2119.

"It may rain today." == "Rain is possible today."

"You may shake my hand." ==
either
  (a) "I permit you to shake my hand."
or
  (b) "It is physically possible that you will shake my hand."

"You may not shake my hand." == "I forbid you to shake my hand."

"It may not rain today." == "Rain is possible today."

(In fact the last two are also ambiguous, strictly speaking, but
I think most people would interpret them as I suggest. This is
why "MAY NOT" is not allowed by RFC 2119.)

So lower case non-RFC2119 "may" is a tricky word in an RFC. Sometimes
it means "might" or "is possible", sometimes it means "is allowed".

I definitely recommend replacing lower-case "may" in a case like
the one below.

Perhaps:

>> , and MUST NOT be
>>   enabled unless the JRC indicates support for them 

Regards
   Brian

On 22/02/2018 04:15, Toerless Eckert wrote:
> 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
> 

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to