Re: [802SEC] Proposal for Editions
Hi James,
I like the general approach overall. However, I'm not in a hurry to add requirements in this area to the P&P or OM. I'd prefer to leave it open to individual chairs to implement a process that works for their groups. What we may need to do in ensure that the processes we desire are consistent with SA rules, and push for some changes in the SA rules if necessary...
Regards,
Mat
Matthew Sherman, Ph.D.
Technical Director & Engineering Fellow
Office: +1 973. 636.7510
Cell: +1 973.229.9520
email: matthew.sherman@baesystems.com
-----Original Message-----
From: ***** IEEE 802 Executive Committee List ***** [mailto:STDS-802-SEC@ieee.org] On Behalf Of James P. K. Gilb
Sent: Thursday, October 06, 2011 2:20 PM
To: STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] Proposal for Editions
All
Just to throw in my general agreement:
1) Consolidations should be made when requested by the WG Chair. The
reality is that you couldn't get more than 1 or 2 a year with a 4 month
request and time to review the document. It should not be limited to
revisions only. For extremely active WGs (802.11 would be an example of
this), 2 consolidations a year would be about right to assist the balloters.
2) I think the WG Chair should appoint a review committee to review the
consolidation. Does this need to be in the SA policy versus 802 or WG
operations manual? I am open to suggestions here. One reason for the
review committee is that there can be questions in the roll-up that may
need to be answered. Also, the review committee may find errata or
corrigendum that need to be handled quickly in the process of the
review. They can start these projects quickly and finish them quickly
as well to avoid problems for subsequent amendments. IMHO.
3) Distributing the standard amendment format and consolidation format
would be nice, but then we would need a policy for which document is the
"official" standard. I suspect that the answer is that the amendment
format is official as the consolidation has not been voted on by the
Sponsor.
4) We should clarify that consolidations enter the Get IEEE 802 program
6 months after publication. Thus, if the SA does 2 consolidations a
year for an 802 WG (say for 802.3, 802.1 and 802.11), they would always
have something to sell. :)
Flame away, it has been too calm on the list anyway.
James Gilb
On 10/06/2011 10:25 AM, Geoff Thompson wrote:
> Pat-
>
> As I said earlier, it is perfectly appropriate for the circulated ballot
> draft to only include those clauses of the consolidated edition that are
> within the scope of the ballot.
> I believe that addresses your concern.
>
> GeoffT
>
> On 610//11 9:16 AM, Pat Thaler wrote:
>> 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.
>>
>
> ----------
> 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.