Hi -
On 2022-08-29 3:09 PM, Kenneth Vaughn wrote:
I still assert that the way I read the SnmpTLSAddress paragraph, “may
not” makes more sense.
I think we agree on the intent at this point, we just need to agree on
the wording that conveys the correct intent.
I talked to my technical editor and she confirmed that "may not" is
ambiguous at best and the most literal interpretation would be "not
allowed" (i.e., "may" means allowed but not required; but the negation
would mean not allowed).
Part of the problem is the ambiguity in the scope of the negation
operator, and changing "may" to "might" doesn't address that ambiguity.
Plenty of linguistics papers have been written on the topic, and your
technical editor is smart to be unwilling to be cornered.
She was not willing to commit to the "might
not" language and suggested that the better way to provide the
flexibility is to either remove the negative (e.g., "Values of this
textual convention may not be directly usable as transport-layer
addressing information _or_, and may require run-time resolution.") or
to move the negative (e.g., "Values of this textual convention may not
be directly _un_usable as transport-layer addressing information,
and may require _without _run-time resolution.")
I am happy to do either. I will also add the most recent text to the
boilerplate.
...
You've still got a "may" there, with more baggage than is IMO needed.
I'd suggest:
Values of this textual convention are not guaranteed to be directly
usable as transport layer addressing information, potentially requiring
[additional processing, such as] run-time resolution.
(I assume that you didn't intend "run-time resolution" to be the sole
possibility for additional processing needed to make the value usable,
thus my addition of the bracketed text.)
Randy
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
