Re: [STDS-802-11-TGM] Language: Ensure
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Adrian,
Your argument appears to be:
(a) Use of "ensure" yields an incomplete requirement.
(b) Suggested replacements of "ensure" -- "check", "confirm", "verify",
"provide", etc. -- likewise provide incomplete requirements.
(c) So we might as well keep "ensure".
Is that the point of the proposed comment resolutions?
This argument ignores two important issues with "ensure", and, if (b) is
being claimed, casts aspersions on large portions of the 802.11 standard
(but I won't worry about that for now).
Important issues with "ensure":
1. "ensure" in English (at least American English) is much stronger
(because it is 'absolute') than "confirm", "verify", "check" and the
other proposed replacements. That is, "ensure" claims an absolute
accuracy (in both time and space -- i.e., under all possible
circumstances). But "check", "confirm", "verify", etc. do not. So, if
any of those proposed replacements accurately states the desired
specification, then the replacement is much better than the absolute claim.
I agree with your point that the substitution of these terms does not
provide complete specifications of all pertinent details. But that does
not mean that substituting these terms won't improve the specification.
Are these replacements more useful than "ensure"? Of course they are, if
only because each is more precise than "ensure":
- "Check" requires that the implementation incorporates a mechanism to
evaluate something. If the replacement is "check", then a test could
show whether or not the implementation actually evaluates the situation.
- "Confirm" and "verify" do the same as "check", but also require that
the evaluation results match a set of criteria. Then a test could show
whether or not the implementation evaluates and finds predicted results.
- "Provide" requires that a certain functionality exists after the
implementation meets the requirement. Then a test could show whether or
not the functionality that is to be provided exists after the
implementation does the stated action.
None of these terms, by themselves, create complete detail in the
specifications. But all provide a basis on which details can be
specified and valid tests can be produced. So all seem to be much better
than "ensure" in a technical standard.
2. "ensure" is a term that is strongly discouraged by the 2012 IEEE
Style Manual.
Subclause 11.2.5 ("Absolute" verbiage) states:
Avoid making guarantees if there is a possibility of unforeseen
situations or circumstances altering an
outcome. Review the text for any explicit or implicit guarantees made
within the document, especially
those that are safety-related.
For example, words such as “ensure,” “guarantee,” “always,” etc., should
be modified, if they are
inaccurate. Substitutions might include “maximize” or “minimize” or
“often.”
In short, if you really don't want to make or demand an absolute
guarantee, then don't use "ensure".
Conclusion:
The proposed substitutions are both more conformant to the IEEE Style
Manual and provide a better basis for additional detailed specifications.
Thanks for your time,
Hunter
On 3/10/2013 14:23, Stephens, Adrian P wrote:
--- This message came from the IEEE 802.11 Task Group M Technical
Reflector ---
Hello all,
LB183 has a number of editorial comments on “ensure”.
For example:
*comments*
*Selected***
*CID***
*Page***
*Clause***
*Resn Status***
*Comment***
*Proposed Change***
*Resolution***
*Owning Ad-hoc***
0
1255
475.45
8.3.2.1
Not only is "ensure" is not a good word in an IEEE standard, but it is
unclear what actions a MAC shall take to 'ensure' anything.
Replace "ensure" with "confirm".
EDITOR
The context is:
“When a mesh STA
receives a frame with the Address 1 field equal to a group address,
the mesh STA also validates the TA to
ensure that the group addressed frame originated from one of its peer
mesh STA.”
My opinion is that the change of itself achieves nothing.
I am willing to agree that “ensure” creates the problem of
“incompleteness”.
It is equivalent to stating: “A STA shall check if <condition> is
true, and if not shall do <unspecified stuff> to make it so.”
“Shall do <unspecified-stuff>” should be a big no-no in anybody’s
book, even if Lewis Carroll wrote it.
But the change to “Confirm”, IMHO, carries exactly the same issue.
“A STA shall check if <condition> is true, and if not shall do
<something>”, because there is surely no point in checking something
unless there is some action taken based on the outcome of that check.
The issue here is not with the particular word used, but the absence
of the unspecified text.
So, the quoted text should, IMHO, read something like:
”When a mesh STA receives a frame with the Address 1 field equal to a
group address, the mesh STA also checks whether the TA of the group
addressed frame originated from one of its peer mesh STA, and if not
generates a short burst of burned plastic smell.”
Do folks agree with this logic? I would like to establish the
sentiment of the group (e.g. mawkish, contra-Sisyphean)
before writing a bunch of suitably sentimental comment resolutions.
Best Regards,
Adrian P STEPHENS
Tel: +44 (1793) 404 825
Tel: +44 (7920) 084 900
Tel: +1 (408) 239 7485
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your
request to this CLOSED reflector. We use this valuable tool to
communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then
amend your subscription on the form provided. If you require removal
from the reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________