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

Re: [802SEC] Proposal for Editions



In many cases, our base standards are very large and any given amendment changes only a small portion of them. I'd find balloting a consolidated redline to be very burdensome and not likely to focus attention on the changes. I speak from recent experience balloting the changes in the current 802.3-Rev project. I wouldn't want to go through that pain on every amendment ballot.

Automated diffs sometimes don't produce very workable documents so getting a good redline isn't always insignificant.

But having a consolidated document with the prior amendments is very helpful when reviewing drafts. This is particularly true when the amendments have touched large portions of the base text. It got pretty difficult to review 802.1Q amendments during the period when the provider bridging amendments hadn't been consolidated.

Regards,
Pat

-----Original Message-----
From: ***** IEEE 802 Executive Committee List ***** [mailto:STDS-802-SEC@ieee.org] On Behalf Of Grow, Bob
Sent: Wednesday, October 05, 2011 9:04 AM
To: STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] Proposal for Editions

As some may recall, I have been advocating publishing all amendments and corrigenda as consolidations (editions) for some time.  In my proposals, I have recommended that WGs be allowed to decide if an amendment/corrigendum is balloted as a redline or as change instructions (as is currently done).  

Publishing of redlines I agree is a valuable product and something that IEEE-SA is now selectively offereing.  Since these can be done as diffs, I don't think it is a significant workload for editorial staff, and probably less than the work of publishing a change instruction amendment and then later having to merge the amendment for a revision.

Personally, for 802 I think a bundle of redline and clean versions would be an appropriate product to serve the needs of implementers.

I agree balloting as redlines also is often valuable.  A speed increase or new PHY type for 802.3 is not likely to show as much benefit from a redline ballot as would energy efficient Ethernet which is much better reviewed in context (as you point out for much 802.1 work).  In a very large document though, a complete redline is difficult to find scattered changes, so only supplying changed clauses or a changed clause list might be necessary for a redline ballot.

The only point where I find using consolidated redlines problematic is when amendment projects are very parallel (e.g., in ballot at the same time).

--Bob

-----Original Message-----
From: ***** IEEE 802 Executive Committee List ***** [mailto:STDS-802-SEC@ieee.org] On Behalf Of Tony Jeffree
Sent: Wednesday, October 05, 2011 7:33 AM
To: STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] Proposal for Editions

I would agree with that too.

Regards,
Tony


On 5 October 2011 15:18, Geoff Thompson <thompson@ieee.org> wrote:

> All-
>
> I would focus on a specific aspect of this.
> When a standard has a non-trivial number of approved parts it is extremely
> difficult for voters to evaluate additional drafts.
> Having to consider a large number of documents when voting on drafts is a
> significant disservice to our balloting reviewers.
> So, again, just having consolidations a base text for revisions doesn't
> deal with the critical issue in 802.
>
> Regards,
>    Geoff
>
>
> On 510//11 5:44 AM, Tony Jeffree wrote:
>
>> I should have added to this...in WGs where a number of amendments to a
>> single base standard are being processed simultaneously, as has been the
>> case in 802.1 for some while, the availability of an up-to-date
>> consolidation of all published material considerably aids the development
>> of
>> further amendments. So for me, focusing the generation of consolidations
>> solely on the need for base text for a revision only deals with half (or
>> maybe much less) of the problem.
>>
>> Regards,
>> Tony
>>
>>
>> On 5 October 2011 11:27, Tony Jeffree<tony@jeffree.co.uk>  wrote:
>>
>>
>>
>>> Bob -
>>>
>>> I agree with much of what you have said here. However, given feedback
>>> received from implementers in 802.1, I don't believe that *just*
>>> publishing
>>> amendments/corrigenda as consolidations serves our readership either. The
>>> complexity of our standards, and the sometimes intricate way that an
>>> amendment inserts itself into the base, means that for the implementer to
>>> have a clear picture of what an amendment does to the base document,
>>> he/she
>>> needs to see the deltas; in order to have a clear picture of what the
>>> final
>>> end result is, he/she needs to see the consolidation.
>>>
>>> So I believe that publishing amendments/corrigenda as deltas to the base
>>> standard is necessary IN ADDITION TO publishing the consolidation, and
>>> preferably publishing the consolidation at the same time or soon after.
>>> We
>>> are currently processing several amendments to Q that are following this
>>> model; I am hoping that we will be able to publish a consolidation very
>>> soon
>>> after we are done with the individual amendments. I know that this
>>> creates
>>> an additional load on the editing staff, but on the other hand, it
>>> actually
>>> delivers what the implementers need.
>>>
>>> Regards,
>>> Tony
>>>
>>>
>>>
>>> On 27 September 2011 16:28, Grow, Bob<bob.grow@intel.com>  wrote:
>>>
>>>
>>>
>>>> Paul:
>>>>
>>>> While a reasonable IEEE-SA wide policy, it does little to help the most
>>>> active 802 standards.
>>>>
>>>> 1.  We have already learned that we have to create consolidations in
>>>> some
>>>> WGs simply to manage the continuing amendment of the standard.  (This
>>>> policy
>>>> will not change that.  If this were a rule rather than a pubs policy,
>>>> then
>>>> we would be in violation of the statement that a consolidation shall
>>>> only be
>>>> prepared for a revision.  But if it is read only referring to pubs staff
>>>> then there isn't an issue, only no help to our needs.)
>>>>
>>>> 2.  Four months is a significant problem.  In my 802.3 experience it has
>>>> been difficult to find a period of 1 year in which to do a revision.
>>>>  The 3
>>>> year, 3 amendment rule has to be satisfied and some of our standards
>>>> will
>>>> have a half dozen or more approved amendments/corrigenda and a few new
>>>> amendment projects in process when we try to slot a revision into the
>>>> flow
>>>> of new projects.  While we can typically give a 4 month heads-up for
>>>> when we
>>>> plan a revision, it will typically be triggered when the last amendment
>>>> to
>>>> be included in the revision is approved.  (No new amendments are
>>>> expected to
>>>> complete within a year or so.)  At that point, the latest amendment
>>>> needs to
>>>> be prepared for publication and then consolidated into the revision
>>>> draft,
>>>> then maintenance changes need to be consolidated into the draft in
>>>> preparation to go to WG ballot.  Either volunteers have to merge the
>>>> approved draft into the staff prepared revision draft (with publication
>>>> changes possibly being missed),!
>>>>  or we have to find a longer gap into which the revision can be slotted,
>>>> or staff has to be willing to accelerate the consolidation of a
>>>> virtually
>>>> complete amdnement/corrigenda.
>>>>
>>>> Fortunately, publication staff has been willing to work with us in
>>>> recognition of these needs, but the policy certainly doesn't specify
>>>> what we
>>>> need.
>>>>
>>>> On the other hand, if all amendments and corrigenda were published as
>>>> consolidations (editions) pubs staff would not have to handle the
>>>> amendment/corrigenda twice (publish and then consolidate), our balloters
>>>> and
>>>> users of the standard would not be faced with trying to make sense of a
>>>> standard composed of a big set of documents with stacked changes and
>>>> order
>>>> specific changes, and we would be making fewer errors by consistently
>>>> having
>>>> a solid single base standard (not a base standard with separately
>>>> published
>>>> amendments and corrigenda that are part of the standard).
>>>>
>>>> --Bob
>>>>
>>>> -----Original Message-----
>>>> From: ***** IEEE 802 Executive Committee List ***** [mailto:
>>>> STDS-802-SEC@ieee.org] On Behalf Of Paul Nikolich
>>>> Sent: Tuesday, September 27, 2011 6:48 AM
>>>> To: STDS-802-SEC@LISTSERV.IEEE.ORG
>>>> Subject: [802SEC] Proposal for Editions
>>>>
>>>> Dear EC members,
>>>>
>>>> Attached is a proposal from the SA regarding a guideline for
>>>> consolidations (also known as editions or roll-ups).  I've reviewed it
>>>> and
>>>> it looks like a reasonable process. The one gap I would like filled is
>>>> the
>>>> time for the SA to respond to a WG Chair 'request for consolidation' be
>>>> defined (one week, perhaps).
>>>>
>>>> Please review the guideline and provide feedback to the EC reflector and
>>>> Karen McCabe.  Thank you.
>>>>
>>>> Regards,
>>>>
>>>> --Paul
>>>>
>>>> ----------
>>>> This email is sent from the 802 Executive Committee email reflector.
>>>>  This
>>>> list is maintained by Listserv.
>>>>
>>>> ----------
>>>> This email is sent from the 802 Executive Committee email reflector.
>>>>  This
>>>> list is maintained by Listserv.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ----------
>> This email is sent from the 802 Executive Committee email reflector.  This
>> list is maintained by Listserv.
>>
>>
>>
>
> ----------
> This email is sent from the 802 Executive Committee email reflector.  This
> list is maintained by Listserv.
>

----------
This email is sent from the 802 Executive Committee email reflector.  This list is maintained by Listserv.

----------
This email is sent from the 802 Executive Committee email reflector.  This list is maintained by Listserv.

----------
This email is sent from the 802 Executive Committee email reflector.  This list is maintained by Listserv.