Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGM] Language: Ensure



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Adrian, I have struggled in my comments to many drafts standards in which I commented on the use of ensure and my comments have been rejected in every instance, even with suggested rewording.

 

I believe that with the use of the term "ensure" that carries with it no process, activity, task, or outcome, its use is open-ended and lacks clarity in what is to be done to attain the unstated purpose and outcome. I have asked that each case of the use of ensure be either replaced with another term that acertains the desired outcome when used in the text, or to use the term and explain the desired outcome when the term is used in a document-wide context, which I think is difficult at best, especially in a protocol standard.

 

The desired result is a rewrite such as you suggest or explain the desired process to ascertain an outcome for each instance of the use of ensure.

 

Suggest that the publication staff consider style guidance for all project editors and WG chairs. It is a "Te" and not an "Ed" issue, in my opinion, humble or otherwise.

 

Regards, Tom Kurihara, a past voting member 

-----Original Message-----
From: "Stephens, Adrian P"
Sent: Mar 10, 2013 5:23 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] Language: Ensure

--- 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 _______________________________________________________________________________