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

Re: [STDS-802-11-TGAI] CID 4741 from LB201




  Hi Mark,

  I invite you to read through the comments received in LB201. Quite a few of them
request changes in language that seems clear to me but is obviously not to the
commenter. You are proposing a change in language not because it is incorrect
or ambiguous but because you feel it is too complex. And the reason it is so complex
is because of the people who find ambiguity in language that defines what is to
most people a simple procedure. 

  The problem, as I see it, is that your language would generate more comments
due to its stated ambiguities. I don't think it would be fruitful for the TG to accept
that language. You state below, "I fail to see the difference" in an example in
which I point out an ambiguity. Since that response seems to be satisfactory for
comments you receive on your text I will use that to respond to your comment
on my text. Your text does not mention M and N but is no less complex, at least I
fail to see the difference. Furthermore, it is much more ambiguous than mine.

  I know that there are better ways to describe a fragmentation/reassembly
scheme than the one I have come up with and I earnestly request someone
(maybe you!) step forward and specify one. And whoever does it can own the text
and deal with the umpteen comments on fragmentation/reassembly. But I'm
not going to take your text and deal with the resulting fallout. Sorry.

  Dan.

On 5/13/14 6:05 PM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

Hello Dan,

 

>  The purpose of comment resolution is to improve the draft and ultimately

get the number of comments reduced. It is my contention that acceptance

of your proposed change would actually increase the number of comments

the TG received (it would receive at least 3 from me). Therefore rejecting it

on that account is entirely valid.

 

Again, I think you need to address my comment, even if you disagree

with my proposed resolution.

 

>  Well, your suggested text does not say "zero or more Fragment elements

with an information length of 255" it says "zero or more Fragment elements, 

each containing the next chunk of information."

 

Yes it does.

 

> It also says that all Fragment

elements following the first are of length 255 so final fragment above violates

your description.

 

Again, it does not say that "all" Fragment elements have "length 255",

it says that "these" (i.e. the zero or more mentioned just before

(perhaps I should say immediately before)) have.

 

>   Exactly. If all fragments are of length 255, as your text says

 

Ditto.

 

> > I think I'm using "immediately following" in the same way as "immediately

following" is used 19 times in mc/D2.0 (though I admit I have not checked

them all).

>  "You shall perform action X immediately following action Y" is not the same

as saying "A is in an immediately following B". 

 

I fail to see the difference in this case.

 

>  Does this mean you are going to produce and present a submission with your

suggested text or not? 

 

As I previously stated, not at this stage.

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: Dan Harkins [mailto:dharkins@xxxxxxxxxxxxxxxxx]
Sent: 13 May 2014 14:27
To: m.rison@xxxxxxxxxxx
Cc: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
Subject: Re: CID 4741 from LB201

 

 

  Hi Mark,

 

On 5/13/14 1:16 PM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

 

Hello Dan,

 

> > "The information to be fragmented is divided into chunks, in order.  The element into which the data would not fit is filled with the first chunk of data and is termed the leading element. The length of the information in the leading element shall be 255. This element shall be immediately followed by zero or more Fragment elements, each containing the next chunk of information.  The length of the information in these elements shall also be 255. Finally, if there is a remaining chunk, this shall be contained in an immediately following Fragment element."

 

> Then I will, respectfully, reject your comment as your suggestion is what I

call "comment bait", i.e. text that, if included, will result in more comments.

 

If you are the comment resolver, then you are of course free to propose any

resolution.  My understanding is that rejecting on this basis would not be

valid, however, because calling the proposed "change comment" bait does

not actually address the comment.

 

  The purpose of comment resolution is to improve the draft and ultimately

get the number of comments reduced. It is my contention that acceptance

of your proposed change would actually increase the number of comments

the TG received (it would receive at least 3 from me). Therefore rejecting it

on that account is entirely valid.

 

  I will not include the words "comment bait" in the rejection text. That

was merely a convenient description of the reason cited above.

 

> Why would a fragmented element be followed by zero ("zero or more")

fragment elements? It wouldn't be fragmented in that case.

 

The leading element is followed by zero or more Fragment elements with

an information length of 255.  Consider the case where information of

length 256 is to be transmitted -- this will be done as:

 

1 leading element with an information length of 255

0 Fragment elements with an information length of 255

1 Fragment element with an information length of 1

 

  Well, your suggested text does not say "zero or more Fragment elements

with an information length of 255" it says "zero or more Fragment elements, 

each containing the next chunk of information." It also says that all Fragment

elements following the first are of length 255 so final fragment above violates

your description.

 

  Now, I will admit that your wording is a little ambiguous but that is part of

the problem. "You know what I mean" is not an acceptable response to

the inevitable comment on ambiguous text.

 

> And how can

all fragment elements following the first fragmented element be 255

in length when there may be a "remaining chunk"?

 

My proposed text does not say that "all" fragment elements following the leading

element have an information length of 255.  My proposed text says that "these"

fragment elements (the zero or more ones immediately following the leading

element and before any Fragment element with an information length less than

255) have an information length of 255.

 

> How do we pad that

> final fragment element out to 255 if the size of the "remaining chunk" is

> less than 255?

 

There is nothing in my proposed text about padding.

 

  Exactly. If all fragments are of length 255, as your text says, then the final

fragment element must be 255. If the actual data is less than 255 you have

a problem. 

 

> What is an "immediately following" fragment element and

> how does it differ from fragment elements that are not "immediately

> following"?

 

I think I'm using "immediately following" in the same way as "immediately

following" is used 19 times in mc/D2.0 (though I admit I have not checked

them all).

 

  "You shall perform action X immediately following action Y" is not the same

as saying "A is in an immediately following B". 

 

> Et cetera et cetera et cetera. 

> Which isn't to say that your suggestion couldn't be cleaned up to remove its

"comment bait" characteristics, just that I'm not gonna do it because I don't

think the M+N stuff is overly complex, it's just correct and complete. If you

would like to clean it up and generate a submission please do so as I would

be happy to reassign this CID (and the others!) to you.

 

See above and below.

 

  Does this mean you are going to produce and present a submission with your

suggested text or not? 

 

  Dan.

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: Dan Harkins [mailto:dharkins@xxxxxxxxxxxxxxxxx]
Sent: 13 May 2014 10:01
To: m.rison@xxxxxxxxxxx
Cc: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx
Subject: Re: CID 4741 from LB201

 

 

  Hi Mark,

 

On 5/13/14 12:30 PM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

 

Hello Don,

 

  :-)

 

   CID 4741 is yours. In it you state that the fragmentation/reassembly scheme

described in section 9.41 and 9.42 of the TGai draft is overly complex.

 

No, in this CID I state that the description of the fragmentation/reassembly

scheme, in terms of M and N, is overly complex.

 

Would you

please generate a submission for TGai describing a simpler scheme because I'm

unable to do it.

 

I provided this as a proposed change:

 

"The information to be fragmented is divided into chunks, in order.  The element into which the data would not fit is filled with the first chunk of data and is termed the leading element. The length of the information in the leading element shall be 255. This element shall be immediately followed by zero or more Fragment elements, each containing the next chunk of information.  The length of the information in these elements shall also be 255. Finally, if there is a remaining chunk, this shall be contained in an immediately following Fragment element."

 

  Then I will, respectfully, reject your comment as your suggestion is what I

call "comment bait", i.e. text that, if included, will result in more comments.

Why would a fragmented element be followed by zero ("zero or more")

fragment elements? It wouldn't be fragmented in that case. And how can

all fragment elements following the first fragmented element be 255

in length when there may be a "remaining chunk"? How do we pad that

final fragment element out to 255 if the size of the "remaining chunk" is

less than 255? What is an "immediately following" fragment element and

how does it differ from fragment elements that are not "immediately

following"? Et cetera et cetera et cetera. 

 

  Which isn't to say that your suggestion couldn't be cleaned up to remove its

"comment bait" characteristics, just that I'm not gonna do it because I don't

think the M+N stuff is overly complex, it's just correct and complete. If you

would like to clean it up and generate a submission please do so as I would

be happy to reassign this CID (and the others!) to you.

 

   Also, would you be willing to take ownership of the other 18 CIDs related to

these sections since you'd, effectively, be rewriting the whole thing?

 

Not at this stage, at least in part because I am not sure what my

or TGai's position is on some of them, e.g.:

 

CID 4513/5089: "Why has another fragmentation scheme been developed here?

Why not re-use the GAS fragmentation scheme design for pre-association

public action frames?"

 

CID 4897: "It is better to have all data as self-describing rather than

relationally describing - that is, it would be better if the fragment IE

contained two more fields - the IE number of the IE being fragmented and

the fragment number of this fragment"

 

CID 4902: "An element contains fields. Even if the Fragmentatoin element

allows the element length to go beyond 255, fields cannot be fragmented

across elements. There is no description of how to fragment a field that

has been broken across elements. Furthermore, the length of the

fragmented element is not specified."

 

  Well, it would require contacting the commenters and querying the TG.

Basically owning the text. But I guess I'll have to do it as the CIDs are still

assigned to me.

 

  thanks,

 

  Dan.

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

 

-----Original Message-----

From: Dan Harkins [mailto:dharkins@xxxxxxxxxxxxxxxxx]

Sent: 13 May 2014 08:46

To: Mark Rison

Subject: CID 4741 from LB201

   Hi Marc,

   CID 4741 is yours. In it you state that the fragmentation/reassembly scheme

described in section 9.41 and 9.42 of the TGai draft is overly complex. Would you

please generate a submission for TGai describing a simpler scheme because I'm

unable to do it.

   Also, would you be willing to take ownership of the other 18 CIDs related to

these sections since you'd, effectively, be rewriting the whole thing?

   thanks,

   Dan.

 

 

 

 

_______________________________________________________________________________

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