Re: [RPRWG] [Fwd: Ballot Reminder - your thoughts?]
Tom, your reply is eloquently worded and makes many good points.
It seems from my reading of your comments that with regard to this issue
there is only one area where our philosophies diverge. While you believe
the PICS can be implemented mechanically, and the main text should be the
focus of the WG participants, I believe that there are likely to be cases
where a review of the PICS, in coordination with a review of the rest of the
document, will alert members of potential problems (for them) that were not
apparent in the rest of the document without the PICS. Therefore, I would
like to see a 30 day review of the entire document after the PICS is
completed.
This is obviously an area where different philosophies of draft review will
lead to different conclusions.
Thank you for stating your position so eloquently and clearly.
Best regards,
Robert D. Love
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 208 978-1187
----- Original Message -----
From: "Tom Alexander" <tom@xxxxxxxxxxxx>
To: "Robert D. Love" <rdlove@xxxxxxxx>; "RPRWG" <stds-802-17@xxxxxxxx>
Sent: Saturday, May 10, 2003 11:48 AM
Subject: Re: [RPRWG] [Fwd: Ballot Reminder - your thoughts?]
> Bob,
>
> If I may clarify a couple of points:
>
> I certainly agree with you that the PICS are extremely important for the
RPR
> standard
> as they will be used by vendors and customers to determine conformance to
> the
> standard. However, it should be kept in mind that the PICS are merely the
> expression
> of the "shall"s and "may"s in the normative text; i.e., the mandatory and
> the optional
> elements in the standard. The editors have no license to determine what is
> mandatory
> and what is optional; this is entirely the province of the WG.
>
> So far, I have not seen much WG attention paid to the mandatory or
optional
> attributes
> of various elements in the normative text. For example, I could find only
> two comments
> (#966 and #444) in the D2.1 comment database pertaining to whether a
feature
> was
> a requirement or not. I find it hard to believe that a 600-page draft
could
> be so close
> to perfection that there are only two instances of improper use of
> shall/may. Therefore,
> I foresee that at some point there will have to be a detailed review by
the
> WG of all the
> features in the draft and whether these features are mandatory or
optional.
> Until such a
> review is performed, it is clearly a waste of time for the editors to
start
> the mechanical
> process of converting shalls/mays into PICS items. It is also not helpful
to
> use the PICS
> tables as an aid to finding out what is optional/mandatory - this leads to
a
> false sense of
> security, because it is far too easy to look at a detailed PICS table and
> miss features
> that are not covered. It is much preferable to go through the draft text
> line by line and
> determine if the "shall"s and "may"s are present in the proper places.
Once
> that is done,
> generating the PICS entries is a simple (though time-consuming) process.
>
> With respect to Sponsor Ballot: I absolutely agree that we should put out
a
> complete
> and "clean" standard to Sponsor Ballot. This is not merely a good idea but
> also the
> responsibility of the WG - after all, if the draft fails in Sponsor
Ballot,
> it will get kicked
> back to the WG and we'll be back to square one. Thus, I did not intend to
> imply that we
> should vote to go to Sponsor Ballot right away. However, I believe that we
> still have
> plenty of time to "clean up" the draft during Working Group ballot
> recirculations, so
> my position was that it would not hurt to have a passing WG ballot at this
> stage. I
> believe that achieving a passing WG ballot brings a higher level of
> consensus and
> cooperation during meetings, and that will assist in speeding up the
process
> of
> getting a good draft out to Sponsor Ballot.
>
> Best regards,
>
> - Tom Alexander
> Chief Editor, P802.17
>
>
> ----- Original Message -----
> From: "Robert D. Love" <rdlove@xxxxxxxxx>
> To: "Tom Alexander" <tom@xxxxxxxxxxxx>; "RPRWG" <stds-802-17@xxxxxxxx>
> Sent: Friday, May 09, 2003 11:12 AM
> Subject: Re: [RPRWG] [Fwd: Ballot Reminder - your thoughts?]
>
>
> >
> > Tom, we are certainly in agreement that it is important that we all vote
> > responsibly. I have a bit of a different point of view on the PICS
since
> > that will be the basis for conforming to the standard. I entirely agree
> > with you that starting the PICS too early is a waste of time. However,
I
> > don't think we need to wait for a passing ballot to begin creating them.
> We
> > are, as a group, pretty aware of the technical issues that are still
open.
> > If we can close most of them in Montreal, then I believe we should make
> sure
> > everyone has a good chance to carefully review the PICS on the next
ballot
> > cycle.
> >
> > Regarding your statement:
> > Therefore, it would seem that there is not a whole lot of harm done in
> > starting down the
> > road to Sponsor Ballot, especially if Sponsor Ballot is the "real"
> balloting
> > process anyway.
> >
> > For two reasons I take strong exception to the idea that we still have
> time
> > to "clean up" the draft after we begin sponsor ballot. The first reason
> is
> > that it is up the WG to put a good complete standard out to sponsor
> ballot.
> > The second reason is more practical. I believe that if we have a lot of
> > delay going through sponsor ballot that it will strongly impact RPR
sales.
> > Therefore, I am pushing everyone to get the draft in a state that will
> allow
> > it to sale through sponsor ballot.
> >
> > Best regards,
> >
> > Robert D. Love
> > President, LAN Connect Consultants
> > 7105 Leveret Circle Raleigh, NC 27615
> > Phone: 919 848-6773 Mobile: 919 810-7816
> > email: rdlove@xxxxxxxx Fax: 208 978-1187
> > ----- Original Message -----
> > From: "Tom Alexander" <tom@xxxxxxxxxxxx>
> > To: "RPRWG" <stds-802-17@xxxxxxxx>
> > Sent: Friday, May 09, 2003 10:32 AM
> > Subject: Re: [RPRWG] [Fwd: Ballot Reminder - your thoughts?]
> >
> >
> > >
> > > Colleagues,
> > >
> > > I agree with the general sentiments expressed by Bob and Kshitij,
which
> is
> > > to
> > > vote responsibly with a view to obtaining a good, technically correct
> and
> > > complete standard in an expeditious manner. I would, however like to
> offer
> > a
> > > couple of clarifications.
> > >
> > > Regarding PICS entries: note that the general sentiment that I have
> heard
> > > expressed in 802 groups is that PICS entries are an editorial matter
> > rather
> > > than a technical matter. This is not as counterintuitive as it seems.
> Note
> > > that
> > > the PICS entries are based entirely on the words "shall" and "may"
that
> > > occur in normative portions of the text. Therefore, PICS entries may
be
> > > regarded as automatic (one day, perhaps, we'll have an 802 PICS
> generator
> > > program that scans the text and creates all of the PICS tables!). The
WG
> > > therefore automatically triggers the creation and removal of PICS
> entries
> > by
> > > adding or removing the "shall"s and "may"s in the clause text. The
> editors
> > > are
> > > expected to note all of the "shall"s and "may"s in the draft, and
ensure
> > > that
> > > the PICS are changed to reflect the change in the normative text.
There
> is
> > > no
> > > vote or comment required in connection with the PICS; for example, a
> vote
> > to
> > > insert a PICS entry is redundant with the vote that inserted the
> > > corresponding
> > > "shall". As there is no point voting twice on the same matter -
> especially
> > > when
> > > it's not possible to vote differently in the two votes! - PICS have
been
> > > normally
> > > considered to be an editorial matter. Certainly PICS entries can and
do
> > > attract comments, but these should not be technical issues.
> > >
> > > Given this situation, I have instructed the editors to not pay too
much
> > > attention
> > > to the PICS entries until the draft reaches a reasonably stable state.
> > > Otherwise,
> > > the editors would waste far too much time adding and removing PICS
> entries
> > > as normative portions of the draft came and went. For instance, note
> that
> > in
> > > the last draft, Clauses 10 and 11 were combined into a single clause.
> This
> > > is
> > > a major change in the format of the draft. If the Clause 10/11 editor
> had
> > > previously spent a lot of time generating PICS entries, most of his
work
> > > would
> > > have been wasted. Further, I defined "reasonably stable" as "draft
> > achieves
> > > passing ballot"; once the draft reaches 75% approval, there is a good
> > chance
> > > that it will not experience major surgery such as the above. Hence my
> > > instructions
> > > to the editors were to hold off on the PICS until this point. You will
> > note
> > > the
> > > obvious incompatibility between these instructions, and the view that
> the
> > > draft
> > > should not be allowed to pass WG ballot without a complete PICS!
> > >
> > > Regarding ballot: it is worth pointing out that the IEEE Standards
staff
> > do
> > > not
> > > even recognize any ballot excepting Sponsor Ballot. In some of the
other
> > > (non-802) groups, especially the smaller ones, it is not uncommon to
> avoid
> > > the
> > > entire process of WG ballot and go directly to Sponsor Ballot.
> Therefore,
> > it
> > > would seem that there is not a whole lot of harm done in starting down
> the
> > > road to Sponsor Ballot, especially if Sponsor Ballot is the "real"
> > balloting
> > > process anyway.
> > >
> > > I would also note that even if the draft passes (and in theory we then
> go
> > to
> > > voting
> > > only on changed sections), it would be grossly irresponsible of the WG
> to
> > > throw
> > > out a technical comment pointing out an actual error in a portion of
the
> > > draft,
> > > on the grounds that it was not open to comment. In my experience, the
> > option
> > > of disallowing comments on unchanged portions of the draft is used
> > sparingly
> > > and only to achieve convergence. Further, note that once a draft
passes,
> > ALL
> > > technically binding comments linked to negative votes go to the SEC,
> > whether
> > > they were made on portions of the draft that were open to comment or
> not.
> > > Hence the WG has a strong incentive to resolve all comments, without
> > > resorting
> > > to tactics that could be interpreted as suppressing dissenting views.
> > >
> > > All that being said, I reiterate: it is up to us to vote responsibly.
> > >
> > > Best regards,
> > >
> > > - Tom Alexander
> > > Chief Editor, P802.17
> > >
> > >
> > > ----- Original Message -----
> > > From: "Kshitij Kumar" <kkumar@xxxxxxxxxxxxxx>
> > > To: "'Mike Takefman'" <tak@xxxxxxxxx>; "RPRWG" <stds-802-17@xxxxxxxx>
> > > Sent: Thursday, May 08, 2003 10:09 AM
> > > Subject: RE: [RPRWG] [Fwd: Ballot Reminder - your thoughts?]
> > >
> > >
> > > >
> > > > Folks,
> > > >
> > > > My interpretation of voting APPROVE (with or without comments) on
this
> > > draft
> > > > is that we are agree that the draft is complete (possibly with
> optional
> > > > modifications).
> > > >
> > > > It is important for us to realize that this draft is still far from
> > > > complete.
> > > >
> > > > For instance, one important area that is clearly lacking is the
> > > > specification of the PICS Proforma. This crucial information will be
> the
> > > > basis for claiming conformance with the standard.
> > > >
> > > > For example, Clause 5, Page 86 contains an editors note "This
> standards
> > > > draft shall not be considered to be complete until this PICS
proforma
> is
> > > > complete. The editors estimate that the level of completeness of
this
> > PICS
> > > > proforma is 5%." For Clause 6, Page 155 has a similar editor's
note,
> > > except
> > > > the level of completeness is 10%.
> > > >
> > > > And please look at the other PICS Proforma clauses as well.
> > > >
> > > > Since the editors have explicitly stated that the present draft is
> > > > incomplete, and since an APPROVE vote on this draft would mean that
we
> > are
> > > > in agreement with the draft (as it is today) becoming the standard,
we
> > > need
> > > > to vote DISAPPROVE to give the editors time to complete the draft,
> > > including
> > > > the PICS Proforma, based on comments received this time.
> > > >
> > > > Because of the critical nature of the PICS Proforma, we must have a
> full
> > > 30
> > > > day review of the final PICS once it is completed, and not be forced
> to
> > > > review it in a short recirculation ballot cycle, IMHO.
> > > >
> > > > After the review period - PICS entries - like anything else new
coming
> > > into
> > > > the draft - should be voted into the draft, one PICS entry at a
time.
> > > >
> > > > I also do not agree with the view that the PICS can be ignored until
> > > sponsor
> > > > ballot - they are too critical to be left till so late in the cycle.
> > > >
> > > > Further, allowing ONLY changed portions of the draft to be commented
> > > > against, forces us away from the preferred method of improving the
> > quality
> > > > of the draft overall - since only a subset can be improved. I agree
we
> > > need
> > > > to do so according to the recirc process, but this means we should
not
> > > > really be trying to be in recirculation until after the next
meeting.
> > > >
> > > > Therefore, if we are looking to progress the standard as quickly as
> > > > possible, we must DISAPPROVE this draft, which has been declared
> > > incomplete
> > > > by the editors, and to task the editors with completing the next
draft
> > > > including all of the new PICS, have those voted in one by one by the
> WG,
> > > and
> > > > then to have that draft balloted prior to the next meeting.
> > > >
> > > > Thank you.
> > > >
> > > > Kshitij Kumar.
> > > > Director, System Architecture,
> > > > Lantern Communications.
> > > > 408-521-6806
> > > >
> > > > -----Original Message-----
> > > > From: Mike Takefman [mailto:tak@xxxxxxxxx]
> > > > Sent: Monday, May 05, 2003 1:20 PM
> > > > To: RPRWG
> > > > Subject: [RPRWG] [Fwd: Ballot Reminder - your thoughts?]
> > > >
> > > >
> > > >
> > > > RPRWGers,
> > > >
> > > > the ballot runs for approximately 1 more week, please
> > > > remember to get your votes in. Failure to respond to
> > > > ballots will result in loss of voting rights.
> > > >
> > > > A reminder about process.
> > > >
> > > > A passing ballot does not imply that the draft will
> > > > be forwarded to Sponsor Ballot. The WG must vote to
> > > > forward the draft for Sponsor Ballot. What a passing
> > > > ballot does is begin the recirculation process on
> > > > the draft. Once we are in recirculations, you may
> > > > only comment on changed portions of the draft or on
> > > > areas affected by a change elsewhere. Hence the process
> > > > begins to become bounded. As a WG, we should not forward
> > > > a draft for sponsor until we have reached the point where
> > > > improvements to the draft / concensus have been maximized.
> > > >
> > > > Thus your approve vote can be interpreted as either a
> > > > belief that it is time to start getting the draft
> > > > ready for sponsor ballot, or that you believe that it
> > > > is time to begin to recirculate. Both are equivalent.
> > > >
> > > > In terms of voting approve with comments versus
> > > > dissaprove with comments. If you fundamentally believe
> > > > that something is broken, then you may choose to vote
> > > > disapprove with comments. If you believe that something
> > > > is broken, but believe that you can work with your
> > > > fellow RPRWGers to resolve the comments you can vote
> > > > approve with comments. There is risk in voting approve
> > > > with comments, in that if the comment is not resolved
> > > > to your satisfaction, but the ballot passed and the
> > > > text is unchanged, then you are out of luck until the
> > > > draft comes back in sponsor (and you end up being a
> > > > member of the sponsor group, which is not guaranteed).
> > > >
> > > > Note: You may change your vote from approve to disapprove
> > > > during recirculations. All you have to do is comment on
> > > > a changed portion of text.
> > > >
> > > > Should a recirculated ballot fail, we are back to commenting
> > > > on the entire draft (and the number advances to the next
> > > > major revision).
> > > >
> > > > cheers,
> > > >
> > > > mike
> > > >
> > > > --
> > > > Michael Takefman tak@xxxxxxxxx
> > > > Manager of Engineering, Cisco Systems
> > > > Chair IEEE 802.17 Stds WG
> > > > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > > > voice: 613-254-3399 cell:613-220-6991
> > > >
> > >
> >
>