Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Bob Love,
Thanks for informing us all regarding the
process. This should help
in understanding the ramifications of voting throughout
the
balloting process. In the spirit of election day,
there are a
couple things which I would like
to see clarified in a revised
draft of the Comment Resolution
Protocol.
1. Please include points you made in earlier
emails regarding the
comment resolution and balloting process (see
attached). It's
important for all aspects of the balloting process to
appear in
one place.
2. Comment resolutions are voted on comment by
comment basis of the
one's which have commentor objections. Please
identify which type of comment
objections are taken to the WG, (E, T, TR). If
all 3 are taken to
the WG, please
include % of votes for each type required to
approve
a particular comment resolution? Please discuss
how specific resolutions are handled
if fail to receive required % approval. See 1st
highlighted text.
3. You also seem to imply that once voting has
completed on individual comments
a subsequent vote is taken on the document as a whole
(see 2nd highlighted
text). Please be more
explicit as to whether WG voting discussed here is of
the individual comments or document as a
whole.
4. You mention that ballots sent to LMSC normally
have a 95% approval rating
at the WG. If all the voting at the WG level is
geared toward 75% approval,
I'm not sure how 95% is ever achieved? It is also
important to identify
the minimum acceptable WG approval for LMSC ballot if
such a criteria
exists?
There are also several issues with the comment
resolution database (CRD) based on
the comment resolution process you outlined here and in
earlier messages. Let me
know whether you think the following changes in the CRD
need to be made.
Maybe there is someone who is MSAccess guru who can
speedily incorporate
the changes into the database.
1. Each record in the CRD does not include a
document issue number
from which the comment was made. As we go to new
document revisions
and section numbering changes there is no way to
uniquely
determine which comments are associated with which
document sections.
For example, in T&D each term is a unique
section. As a new term is added
section numbers of the remaining terms are
affected. It shall be impossible
to track original comments made against these
terms. Having a document
revision # in the record, at least
allows us to bring up the old draft and identify the section
against which the comment was originally
made. An
alternative might
be to maintain a separate CRD for each document
revision; although this
introduces it's own set of
problems.
2. The CRD does not support a field "to be
reviewed by working group".
The CRD needs to be enhanced to include this field and
the associated
reports we will need to generate.
3. The CRD has commentor "closed, unsatisfied,
withdrawn" instead of :
"accepted, rejected, accommodated, withdrawn".
While the wording
is a little different, we are missing the
"accommodated" category.
Should the database be modified to include
accommodated, or use
as is?
4. The CRD does not have "Revised Resolution
Group proposed Resolution" field.
Is this something which needs to be added or do we add
subsequent updates
to the "response" field with the proper
annotations?
5. The voter list in the database should include
a field for objectionable
comments. This should include a list of those
comment #'s which a voter
objects to the resolution. This list may comprise
of either comments
directly submitted by the voter or comments submitted
by others.
The voting record needs to make provision for voting
specific sections
vs. the entire document in cases where we are balloting
a section.
This allows us to track when we see votes in the
database what the
votes pertain to. The current voter
list and voting record for T&D section 1
of draft needs to be
added to the CRD. Do we need to
make the above
changes in the CRD to the voting
record?
6. There is a problem with sorting by
section/subsection, in that MSaccess
performs an alphanumeric sort vs. numeric sort.
In this case you'll see
sections 1.31 preceding 1.4. It was a pretty big
nuisance
for resolving comments in the text.
I tried to fix this in a
temporary copy of the database, but changing the field from
alphanumeric to numeric
resulted in all the values being
lost.
Regards,
Bob Castellano
Robert
Castellano
Jedai Broadband
Networks
(732) 758-9900
x236
|
- To: "Bob Sultan" <ra_sultan@yahoo.com>,<rc@jedai.com>
- Subject: Re: Comment Resolution with Working Group
- From: "RDLove" <rdlove@nc.rr.com>
- Date: Fri, 19 Oct 2001 08:06:22 -0500
- Cc: "Takefman, Mike" <tak@cisco.com>,"Hawkins, John" <jhawkins@nortelnetworks.com>
- Importance: Normal
- References: <NFBBJEBNEMCKNIABOCKJKEIOCCAA.rc@jedai.com>
Bob, these are good questions. Let me review the process in some detail including answers to your questions.The data base that gets published and printed out for review by the working group needs to have the following fields:CommenterComment NumberEditorial / Technical / Technical RequiredMust be Reviewed by Working Group (This box can be checked by the commenter or by the Resolution Group - We didn't have this field in our first ballot. It is there because the commenter may want to indicate an editorial change is important enough that it really needs broad review, or the resolution group may feel uncomfortable not having a particular proposed resolution get extra scrutiny, or the commenter will not be at the meeting but has expressed concern with the proposed resolution, or significant concerns were posted on the reflector and the resolution group wants to make sure those concerns are reviewed.)Original ConcernOriginal Proposed ResolutionComment Accepted / Rejected / Accommodated / Comment Withdrawn (One of the four will be checked. Accepted is only checked if specific proposed wording is accepted. Accommodated means that it is believed the resolution may satisfy the concern of the commenter. Sometimes after discussing the concern with the commenter, the commenter agrees to withdraw the comment.)Resolution Group's Proposed ResolutionWorking Groups approved ResolutionThere will be a single character field Commenter accepts Resolution.Note that if through some process you come to a resolution the resolution group and commenter agree on, then the Resolution Group's Proposed Resolution is accepted by the commenter.Once that data base report is circulated all WG members will have a chance to comment on the Resolution Group's proposed resolution. That includes the original commenter (Ideally, it would be nice to get the commenter's input before publishing the data base. In this case we have too little time to do that.) Anyone with concerns over the proposed comment resolutions should post their concerns to the reflector. Based on reviewing those concerns, the comment resolution group may decide to change the Resolution Group's Proposed Resolution prior to or at the meeting.As a bonus to the WG, if you can have a copy of the proposed updated T&Ds with highlighted cross reference from each change to the commenter/comment number it is addressing(a single change may reference multiple comments, and a single comment may force multiple changes), that would allow people to see the implications of the proposed resolutions. That document could be posted after the data base is posted, if it can't be ready at the same time.= = = =Given that part of the process, at the meeting you will need to have available an updated data base with an additional field "Revised Resolution Group's Proposed Resolution" When reviewing comments with the group we quickly go through the data base asking people to state which proposed resolutions they have concerns with. Only those comments, and ones with "must be reviewed by the WG" will be reviewed by the WG.All comments with proposed resolutions that go unchallenged become WG approved resolutions. The working group votes on approved wording when there is disagreement on approved resolution. a 75% approval is needed for technical issues.Mike, please review carefully and let me know if you have any concerns with this proposed process.John, you are on copy because the process impacts the design of the data base.Best regards,Robert D. Love
Chair, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@ieee.org Fax: 208 978-1187----- Original Message -----From: Robert CastellanoTo: RDLove ; Bob SultanSent: Thursday, October 18, 2001 7:14 PMSubject: Comment Resolution with Working GroupBob Love,Bob Sultan relayed to me your discussion regardingRS and myself to finish putting our proposed resolutionsinto the database and send out to the working group. Whenwe send to the working group, how do we log the responses?I see 4 types of responses coming back from the working group.1. The comment originator agrees with our proposed resolution.2. The comment originator doesn't agree with our proposed resolution, butthrough some process we come to a mutual resolution.3. We are not able to come to agreement on a mutual resolution withthe comment originator.4. Some other member of the working group does not agree with our proposedresolution that either the commentor originator already agrees with ordoesn't agree with.It's a given that we will strive for consensus while trying to maintain thetechnical and editorial integrity of the document.My question is how do we document or log in the database the abovekinds of responses? I see the database supports a response status field"closed, unsatisfied, withdrawn". Is this where the commentor'sfinal acceptance/rejection of the resolution logged? What aboutanother member's dissatisfaction of the resolution? Does that constitutea new comment that is separately tracked?At what point do the dispositions transition from proposal modeto final mode? At what point can the T&D section go through a revision,and how is the incorporation of changes in the revision,reflected in the comment database? My assumption is thatthe database records are updated to final mode, followingfinal ballot. I'm not sure any special updating of the databaseis required to incorporate the comments aside from the documentreflecting the proposed resolutions.Let me know if my assumptions about the process are correct.thanks,bobRobert CastellanoJedai Broadband Networks(732) 758-9900 x236
- To: "802.17" <stds-802-17@ieee.org>,<rc@jedai.com>
- Subject: Re: [RPRWG] IEEE 802.17 Balloting Instructions
- From: "RDLove" <rdlove@nc.rr.com>
- Date: Thu, 20 Sep 2001 16:37:55 -0500
- Importance: Normal
- References: <NFBBJEBNEMCKNIABOCKJOECACCAA.rc@jedai.com>
Bob Castellano brings up some good questions that everyone ought to know the answers to, and probably does if they have been involved in IEEE 802 for 10 or more years.For those of you that have not mis-spent your last 10 years, here are the answers:All NO votes must be based on issues brought up during the balloting period. If all issues that have caused a voter to issue a NO vote have been addressed to that voter's satisfaction, then the voter no longer has a valid NO vote. However, the voter must state that the issues have been resolved before his no vote is converted.There is no requirement for the working group to address issues brought up after the ballot period closes. Note, however, that in the process of resolving comments, additional errors in the standard are often uncovered by the ballot resolution group / editors. In IEEE 802.5 we had a separate category for new issues that were uncovered during ballot resolution and the working group always worked to resolve these issues, although they were not associated with NO votes.If a commenter votes NO without providing specific changes for converting that NO vote, then the NO vote may be declared invalid and thrown out.Balloters may not register NO votes based on issues uncovered after the ballot has closed. However, it is acceptable to change your vote to a NO during a recirculation ballot based on information learned from reading the other comments, and / or based on changes made to the draft to resolve issues. This capability is what drives the rules for recirculation ballots.The working group can decide to address new issues not uncovered during the voting or ballot resolution process, but is under no obligation to do so. They are, however, leaving the draft subject to being rejected by voters during the LMSC ballot. Therefore, concerns with the standard are normally addressed fully prior to LMSC balloting.Best regards,Robert D. Love
Chair, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@ieee.org Fax: 208 978-1187----- Original Message -----From: Robert CastellanoTo: John Hawkins ; RDLoveSent: Thursday, September 20, 2001 11:51 AMSubject: RE: [RPRWG] IEEE 802.17 Balloting InstructionsJohn,No problem. I just wanted to make sure it wasn't a "Netscape problem", similarto the ones I had before. I think it would be really useful to writeup theballoting process, so that people clearly understand the implications oftheir vote. Also, understanding the comment resolution process. Understandingscenarios like, if all the TR comments of a commentor are addressed are they obligated tochange a NO vote to a vote to approve. How is a commentor's "NO vote""officially" handled if they do not provide any TR comments. Doesit stand as a "NO", changed to a "Yes", or thrown out? Are commentor'sallowed to continue to vote "NO", if their original comments have beenaddressed, but they bring up a new reason which was previously inthe document that was balloted and not due to a change from theprevious version.thanks,bobRobert CastellanoJedai Broadband Networks(732) 758-9900 x236-----Original Message-----
From: John Hawkins [mailto:jhawkins@nortelnetworks.com]
Sent: Thursday, September 20, 2001 10:31 AM
To: 'rc'; RDLove
Subject: RE: [RPRWG] IEEE 802.17 Balloting InstructionsHi Bob,You don't see the file 'cause I never created it! One of those things that fell through the proverbial crack. I know Bob sent out several emails with instructions and clarifications. Also, the ballot itself was built to be self-explanatory (wishful thinking I know).Before we vote again, I'll compose a more comprehensive "help" doc for this purpose. I won't undertake that right now as there is no vote underway.john-----Original Message-----
From: Robert Castellano [mailto:rc@jedai.com]
Sent: Monday, September 17, 2001 6:53 PM
To: RDLove
Cc: Hawkins, John [WWP1:2268:EXCH]
Subject: RE: [RPRWG] IEEE 802.17 Balloting InstructionsBob,I receive an error when I try this link. This may be one of the reasonswhy people are not following the process as requested.thanks,bob c.Robert CastellanoJedai Broadband Networks(732) 758-9900 x236-----Original Message-----
From: owner-stds-802-17@majordomo.ieee.org [mailto:owner-stds-802-17@majordomo.ieee.org]On Behalf Of RDLove
Sent: Thursday, August 23, 2001 11:28 AM
To: 802.17
Subject: Fw: [RPRWG] IEEE 802.17 Balloting InstructionsAll, on August 10th I posted the balloting instructions attached to the bottom of a long note. Since then I have received two requests for instructions on posting the ballots. Here are the concise balloting instructions for the Terms and Definitions draft, without the excess verbiage contained in the first note.(John Hawkins, please post the full balloting instructions at http://www.ieee802.org/17/documents/drafts/Ballot_instr.txt, as indicated in the August 10th note)Best regards,Robert D. Love
Chair, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@ieee.org Fax: 208 978-1187- - - - - - - - - - - - Balloting Information - - - - - - - - - - - - - -PLEASE RESPOND NO LATER THAN August 31, 2001
COMMENTS WILL NOT BE ACCEPTED AFTER September 8, 2001
RETURN ALL BALLOTS & COMMENTS BY E-MAIL TO:E-MAIL: jhawkins@nortelnetworks.com and bob.sultan@fnc.fujitsu.com
----- Please use 1 of the following 4 Subject lines on your email ballot --------
P802.17 TD1.0 RESPONSE = APPROVE WITH COMMENT
P802.17 TD1.0 RESPONSE = APPROVE WITH COMMENT
P802.17 TD1.0 RESPONSE = DISAPPROVE [comment(s) enclosed]
P802.17 TD1.0 RESPONSE = ABSTAIN----- Begining of Ballot Form. Cut and paste text below this line only please --------
TA Document IEEE802.17-11Jul2001/:7, July 11, 2000
Working Group Ballot August, 2001
(Terms and Definitions for Resilient Packet Ring)
Your Name:___________________________
___ APPROVE WITHOUT COMMENT
___ APPROVE WITH COMMENTS
___ DO NOT APPROVE (Please attach specific comments for remedy)
___ ABSTAIN, List Reason i.e. Lack of Expertise, Lack of Time: ____________________________
------ END OF BALLOT SECTION -------
IF YOU ARE VOTING "APPROVE WITHOUT COMMENT" or ABSTAINING, YOUR WORK
IS DONE AT THIS POINT.COMMENT INFORMATION:
COMMENTS ARE APPROPRIATE IN THE INSTANCE OF AN "APPROVE WITH COMMENT"
VOTE AND REQUIRED IN THE INSTANCE OF A "DO NOT APPROVE" VOTE.
"DO NOT APPROVE" VOTES MUST BE BACKED UP BY COMMENTS CLASSIFIED AS
"TECHNICAL REQUIRED" AND THESE MUST PROVIDE SUFFICIENT REMEDY AS
TO CHANGE THE VOTE TO AN "APPROVE" IF ADOPTED. ALL COMMENTS SHOULD
INCLUDE CHANGES REQUIRED TO ELIMINATE THE STATED CONCERN.PLEASE USE THE FORM BELOW FOR ALL COMMENTS. MULTIPLE COMMENTS CAN BE
SUBMITTED IN ONE ASCII TEXT FILE OR E-MAIL. SIMPLY ADD YOUR PERSONAL DATA
AND THEN COPY THE LINES FOLLOWING "------ COMMENT SECTION -------"
AND REPEAT AS OFTEN AS REQUIRED WITHIN THE FILE OR EMAIL. PLEASE USE THE
FORMAT BELOW, MAKING SURE THAT THE COMMENTS ARE IN ASCII FORM AND THAT
EACH COMMENT INCLUDES:
CommenterName:
CommenterEmail:
CommenterPhone:
CommenterCellPhone:
CommenterCompany:
Acceptable comment types:
E = Editorial
T = Technical
TR = Technical Required------ COMMENT SECTION -------
Comments on P802.17/TD1.0CommenterName:
CommenterEmail:
CommenterPhone:
CommenterCellPhone:
CommenterCompany:
Clause:
Subclause:
Page:
Line:
CommentType (E, T or TR):
Comment #:
Comment:
CommentEnd:
SuggestedRemedy:
RemedyEnd:
- - - - - - - - - - END OF BALLOT FORM - - - - - - - - - - - -
If you should have any questions, problems or comments please contact:
Mike Takefman
Chair, IEEE P802.17 Working Group
Office: 613-271-3399
takf@cisco.comBob Love
Vice-Chair, IEEE 802.17 Working Group
Office: 919-848-6773 Fax: 208-978-1187
rdlove@ieee.orgBob Sultan
Editor, Terms and Definitions Section for IEEE 802.17 Working Group
Office: 845 731-211
bob.sultan@fnc.fujitsu.comJohn Hawkins
Co-Webmaster, IEEE 802.17 Working Group
Office: 770 705-708-7375
jhawkins@nortelnetworks.com