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
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
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
> 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
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
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.
please generate a submission for TGai describing a simpler scheme because I'm
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
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
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
-----Original Message-----
Subject: CID 4741 from LB201
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
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?