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.