Re: [STDS-802-11-TGM] Language: Ensure
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello Hunter,
> Is that the point of the proposed comment resolutions?
No, it's not. I'm not proposing any comment resolutions yet. I'm getting feedback from the group
as to whether they agree with my logic or not.
If the group agrees that the changed text is equally problematic, then I guess we'll be looking for
a volunteer to write a submission with alternative text.
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
-----Original Message-----
From: hunter [mailto:hunter@xxxxxxxxxxxxxx]
Sent: Tuesday, March 12, 2013 3:38 AM
To: Stephens, Adrian P
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx; hunter
Subject: Re: [STDS-802-11-TGM] Language: Ensure
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
_______________________________________________________________________________