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

Re: [STDS-802-16] Reply Comments for IEEE P802.16-REVd/D4; Revise d Comments invited



Eric and Itzik

I agree with Eric.

My understanding is that there are no way for comment X supercede another
comment Y;
what can supercede Y is the resolution of X.

Term "superceded" is used to mark certain type of resolution. As such, it
was implemented [by Roger Marks]
in Commentary tool. Later Roger added support of "reply comments" procedure;
eventually "superceded" was also included
as an option for reply comment, as well as "withdrawn", "deferred" etc.
I doubt whether it was an intention to have all those options used in reply
comments. Otherwise, what
is the meaning of "withdrawn"? Reply commenter recommends the original
commenter to withdraw the comment?

What happens now is that some people start to use "superceded" and other try
to invent a new interpretation for this term.
[Is "withdrawn" the next?]  I don't see utility in such extension. What
should original commenter do with reply comment "superceded" ?
If there are identical comments, so what? Should one withdraw his comment?

What if "superceded" submitted at the next step, during E-Mail voting? Must
it be counted as in favour or against?
I think, the only reasonable options at voting step are "accepted" /
"rejected"

Vladimir

-----Original Message-----
From: Jacobsen, Eric A [mailto:eric.a.jacobsen@INTEL.COM]
Sent: Wednesday, April 28, 2004 12:15 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Reply Comments for IEEE P802.16-REVd/D4; Revise d
Comments invited


Itzik, all,

While I agree with the functional purpose of what you've indicated for
the use of "superceded" in comment resolution, it conveys almost no
information to the original comment author if they weren't involved in
the resolution discussion.  In the past I've declined removing comments
because "superceded" tells me nothing about the disposition of the
intent of the comment.

The purpose of comment resolution is to address the concerns of the
commenters that are providing feedback on the condition of the document.
"Superceded" by itself does little to address the concern of the
commenter and does almost nothing to convey the result of any discussion
during comment resolution.  The commenter is then left feeling that
their comment has been ignored or brushed off by the body, and this is
counter productive to the entire comment resolution process in my
opinion.

I would suggest that if "superceded" is used as Itzik has indicated,
that it be accompanied by additional information such as which comment
is being used to address the issue, e.g., "Superceded by comment xx".
This conveys to the commenter that the issue is being addressed and then
the commenter knows where to find the results of how the issue was
resolved.  The commenter should retain the option of declining
"superceded" if he feels that the indicated superceding comment does not
address the original issue, i.e., if he feels the comment was
erroneously superceded.

Eric Jacobsen
Minister of Algorithms
Intel Corporation

-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Itzik Kitroser
Sent: Tuesday, April 27, 2004 8:17 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Reply Comments for IEEE P802.16-REVd/D4;
Revise d Comments invited

Vladimir,

I thought that selecting comment as superceded is a positive way to
indicated that the comment rejected by the superceding comment. Using
this method we are indicating that we don't necessary rejecting the
resolution of the comment, but that it will be handled by a different
comment.

I think that we should continue with this response in future work.

Regards,
Itzik.

-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Vladimir
Yanover
Sent: Tuesday, April 27, 2004 3:42 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] Reply Comments for IEEE P802.16-REVd/D4;
Revise d Comments invited

All,

Thanks to Roger, Bob, Itzik for analysis.
There is much common in the possitions. Basically everybody agrees that
by
encoding "superceded" reply-commenter actually tried to express an
option
that was not available in the menu.

After that we may think creatively to guess what was the real intention.

My suggestion is very simple. I would appreciate a recommendation from
Chair
to use only options "accept", "reject", "accept-modify"
in the next step of the procedure [voting on resolutions proposed by
original commenters] as well as in reply comments in the future.

If one wants to point to presence of identical comments, it could be
done in
the "Reason" part. In this case proposed resolution may be specified as
"rejected" [why not?] because of this reason or any other reason.

Vladimir

-----Original Message-----
From: Bob Nelson
To: STDS-802-16@listserv.ieee.org
Sent: 4/27/2004 2:56 AM
Subject: Re: [STDS-802-16] Reply Comments for IEEE P802.16-REVd/D4;
Revised
Comments invited

All,



As another user of "superceded", my intent was to indicate that I
thought the comment was a duplicate or subset of the referenced comment
and that I thought that the resolution I had specified for the
referenced comment dealt with the designated superceded comment as well.




I would encourage everyone to refrain from specifying a Recommendation
of superceded, withdrawn, or rejection unless, as suggested in the
process document, you have been able to confer with other commenters on
the same subject matter and together you have come to a conclusion on
what the Proposed Resolution should be and against which comment the
Recommendation/Proposed resolution will be specified.



In the event such a discussion did not take place, review the reply
comments for your comment and those of the related comments and specify
a Proposed Resolution/Recommendation that you believe is appropriate for
the entire comment set. Further, as part of your entry in the Reason for
Recommendation field, list the comments that you believe are members of
the set. In this second case, specify a Recommendation of reject or
withdrawn only if you feel the issue need no longer be a subject of
discussion.



Bob





-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Itzik Kitroser
Sent: Monday, April 26, 2004 8:13 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Reply Comments for IEEE P802.16-REVd/D4;
Revised Comments invited



Vladimir and Roger,



I have marked several comments as superceded, in most of the cases, it
was because comments where duplicates of others (which I recommended to
be superceded by).

I fully agree with Roger's analysis that in such cases, people probably
should withdraw such duplicated comments, since there is no sense of
having different resolutions for duplicated comments (and in duplicate I
mean the case in which two people proposed same solution for same
problem).

Also there were some cases where one comment contained solution to
problem X, and other comment contains same solution to problem X and in
addition solutions to problems Y and Z. From my perspective, it is
obvious that the first comment must be superceded by the second.

In all other cases, I agree with Vladimir, that the proposal was to
supercede by the resolution of the other comment, and it was made to
indicate the commenter and the group about this scenario.



Best regards,

Itzik.



-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Roger B. Marks
Sent: Monday, April 26, 2004 11:41 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] Reply Comments for IEEE P802.16-REVd/D4;
Revised Comments invited



Vladimir,



I agree with your analysis.



I think that, when people proposed "Superceded by #NNN," they probably
meant that they would like to see #NNN accepted and that they believed
that the current comment would thereby become irrelevant (which
essentially means that they did not want to accept it). But that's just
my interpretation.



"Superceded", "Approved, Duplicate", and "Rejected" all advocate against
accepting the comment in the current form, though they have a different
spin on how they feel about it. Ultimately, though, it doesn't matter
much what reply tag someone chose. We won't be voting on accepting the
reply comments; we will be voting on accepting revised comments. If I
found that one of my comments was better addressed by, or somehow made
irrelevant by, another comment, I might submit a revised version in
which I marked it Withdrawn. In this case, the comment need not be voted
upon. If I recommended that my own comment be Rejected, I suspect that
the voters would probably comply.



You ask whether a comment could be Superceded by a comment rather than
by a comment resolution. I think than, in some cases, it could. For
instance, let's say that my comment said to fix the spelling of a word,
and your comment said to fix that spelling in two places. Then your
comment would supercede mine. Regardless of whether the group accepted
your comment or not, mine could, and should, be simply erased. In this
case, I might revise my comment to recommend that it's resolution be
Superceded. However, Withdrawn would make things easier for the BRC.



Roger





At 11:35 +0300 04/04/26, Vladimir Yanover wrote:

Roger and All,


In Reply comments I found many proposed resolutions "superceeded by
#NNN".
Is there a reasonable interpretation for such proposal? Comment NNN
still may be resolved as "accepted" or "rejected".
My understanding of the procedure is that resolution of comment MMM may
be stated as "superceeded by the resolution of comment NNN". If we don't
have a resolution of NNN meanwhile, then there is no sense in
"superceeding". Please advise.

Thanks

Vladimir

-----Original Message-----
From: Roger B. Marks [  <mailto:r.b.marks@IEEE.ORG>
mailto:r.b.marks@IEEE.ORG]
Sent: Monday, April 26, 2004 10:10 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [STDS-802-16] Reply Comments for IEEE P802.16-REVd/D4; Revised
Comments invited


We received 1305 reply comments to the comments received in the
P802.16-REVd/D4 Sponsor Ballot recirculation.

These reply comments have been added to the comment package, which is
now available:
         <http://ieee802.org/16/docs/04/80216-04_20r2.zip>
http://ieee802.org/16/docs/04/80216-04_20r2.zip

The file is set to open to a layout showing the replies, in
abbreviated form. If more than three replies were submitted for a
given comment, you will need to scroll to see them all. For a more

spacious view of the reply comments, click "See reply details" above

the colored Reply Comment table.



In accordance with the announced comment resolution procedures:
         <http://ieee802.org/16/docs/04/80216-04_18r1.pdf>
http://ieee802.org/16/docs/04/80216-04_18r1.pdf
those who submitted the original comments are now invited to
reconsider their comments in the light of:

(a) the reply comments
(b) other comments in the database that address relevant issues

To submit your revised comment, please follow the same procedure for
submitting Reply Comments, using the fields "Recommendation ", "
Proposed Resolution ", " Reason for Recommendation ", and "
Recommendation by". Email your revised comment files to
ballot16d@wirelessman.org by Wednesday 28 April AOE (Anywhere on
Earth).

ADVICE TO COMMENTORS:

In light of the defined procedure, there will be no opportunity for
the Ballot Resolution Committee (BRC) to alter the revised comments;
the BRC can only accept or reject them. Therefore, those who
submitted comments are strongly encouraged to study the database, not

only with respect to their own comments but also with respect to
related comments. If you have a concern that related comments might
affect yours, please contact the other balloter to coordinate your
responses. Please ensure that your Suggested Remedy is fully
explicit, with detailed changes by page and line number, so that the

editor may implement it without doubt as to your intent. If your

comment refers to an external contribution, please refer to its

explicit contribution number, including the revision number, at

<  <http://ieee802.org/16/tgd/#Contributions>
http://ieee802.org/16/tgd/#Contributions>.



Please remember that your revised comment will be voted upon,
verbatim, by the BRC. The BRC members, when considering their vote,
will look to see whether your comment makes a convincing argument in
favor of the need for a change to the draft. They will also be
looking for evidence that you have fully addressed all concerns
raised in the reply comments and have considered alternatives
proposed there. You are encouraged eliminate any doubt the BRC
members have doubts about the change.

Please contact me with any questions.

Roger

--

Dr. Roger B. Marks  <  <mailto:marks@nist.gov> mailto:marks@nist.gov> +1
303 497 3037
National Institute of Standards and Technology/Boulder, CO, USA
Chair, IEEE 802.16 Working Group on Broadband Wireless Access
        <  <http://WirelessMAN.org> http://WirelessMAN.org>


This mail passed through mail.alvarion.com

************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************

This mail was sent via mail.alvarion.com

************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************





This mail passed through mail.alvarion.com

************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************

This mail was sent via mail.alvarion.com

************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************


This mail passed through mail.alvarion.com

****************************************************************************
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
****************************************************************************
********
This mail was sent via mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************