[EFM] RE: [EFM-Copper] Long Reach Copper Presentations in Vancouver
I believe that the point Howard made in Hawaii that a presentation per side for #1 and #2 would be allowed should have prevented wasted effort on your part. I am sure we all regret this has happened.
I would also like to remind us all of the meeting in Edinburgh, where Dong Wei's impassioned plea along with his presentation in support of #2 (g.SHDSL) were widely supported over the whole Task Force and had a majority vote in the straw polls.
Therefore, I believe that, given the fact that delays since that time seem to have helped solidify support for #2 and against those continuing to delay copper's advance, that it will achieve a strong vote and the only open question will be: will #1 (ADSL Annex J) be able to justify the existence of Annex J and the creation of yet another LR PHY that will somehow be different (unique identity) than VDSL operating in the bands already defined for it (where ADSL J operates) and SHDSL already selected for the LR PHY. I cannot see any justification for going back for another Objective and then defining something that does not have a unique identity.
From: O'Mahony, Barry [mailto:barry.omahony@xxxxxxxxx]
Sent: Thursday, December 19, 2002 3:28 AM
To: 'Howard Frazier'; firstname.lastname@example.org
Subject: RE: [EFM-Copper] Long Reach Copper Presentations in Vancouver
I disagree with your characterization that there are only two potential
proposals. Based on the agreed motion to "limit proposals for
consideration regarding the long reach objective to those based on
artman_copper_1_0702 and jackson_copper_1_0702", one can construct any
number of proposals. But among those proposals which have been actively
discussed in the copper track over the past few meetings, they can be binned
into three major categories:
1.) those based on artman_copper_1_0702 only,
2.) those based on jackson_copper_1_0702 only,
3.) those based on artman_copper_1_0702 and jackson_1_0702.
This is not just a subtle semantic difference. I believe each of these is a
distinct, separate proposal category. #3 is not merely a cop-out
amalgamation of #1+#2, although it certainly may appear to be at first
glance. Unfortunately, artificially restricting presentations to only
those based on #1 and #2 would make it difficult to dispell this first
For example, if for the sake of argument, one accepts that both are needed
in order to form a complete solution, one can hardly expect an advocate for
#1 or #2 to make the point that the other is deficient because it offers
only a partial solution, as that would illuminate the fact that his/her own
proposal is similarly deficient. This then leads to the argument over which
of the partial solutions is less partial than the other, which customers are
more imprtant than others, etc., far more subjective issues and a recipe for
the endless rathole discussions we've been having.
There are other points to make along these lines, which for brevity's sake
are best left to a presentation itself. Technically, the key problem
reconciling the long-reach objective and the spectrum management objective.
But aside from technical reasons, an approach where the only path into #3 is
as some sort of "consolation prize" when/if #1 and #2 fail seems to be a
poor way to adopt a decision. It's almost guaranteed to leave the
impression that #3 was adopted only because the group could not make a
decision between #1 and #2, and lazily chose "both". If number #3 were
in fact to be chosen, far better that the group does it because they believe
it is the best technical decision, and have been given all the information
upon which to feel comfortable making it. Considering 802.3ah is a large
subset of 802.3, it makes even more sense for all proposals to be presented
to the entire Task Force. I thought that was the intent of doing this
during the Monday general session.
Finally, I must mention that all three proposals, #1, #2, and #3 have been
discussed in the copper track for a couple of the past meetings. While none
has reached consensus, all have gotten significatn support; none are
something new for this meeting. In the announcement for this meeting sent
out 11/22, it was stated that a significant amount of time would be devoted
in the Monday general session to the issues of Long-Reach copper, FEC, and
PON PMD timing. Presentations on proposals to address them would would be
"welcome". It was requested that the appropriate sub-TF editor be notified
prior to 12/23. In fact, I notified Hugh prior to Thanksgiving that I was
planning on a presentation for the long-reach issue. To now see, at a late
date when it would be expected that work on such presentations would be
largely completed, that some presentations now appear to be considered
"uwelcome", is very disappointing. I fear it will feed into the resentment
in some quarters in the copper track that some opinions are dismissed
without due consideration.
From: Howard Frazier [mailto:millardo@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, December 18, 2002 10:10 AM
Subject: [EFM-Copper] Long Reach Copper Presentations in Vancouver
Dear Members of the IEEE 802.3ah EFM Copper Sub Task Force,
There has been considerable discussion about the Long Reach Copper
presentations that are being planned for the upcoming meeting in
Vancouver. I previously announced that we would reserve the
entire day on Monday, January 6th for an "all hands" meeting of
the 802.3ah EFM Task Force to consider several "big ticket" items
that require the attention and involvement of all of the Task Force
members. One of these "big ticket" items concerns our long reach
copper PHY objective.
Clearly, we need to resolve the question of how we are going to meet
the long reach objective. Adhering to the motion that we passed last July,
that limits our consideration to those proposals based on the Artman and
Jackson presentations (advocating PHYs based on ADSL Annex J and
g.shdsl, respectively), the task force has a finite set of choices:
1) Adopt the ADSL Annex J proposal (with appropriate updates)
2) Adopt the g.shdsl proposal (with appropriate updates)
3) Adopt both proposals
4) Adopt neither proposal
It is obvious to me that choice # 4 above is the least desireable outcome.
It is also the default outcome, because the first three choices require a
positive vote, while # 4 represents the status quo ante.
In the hope that the Task Force can reach a >= 75% concensus on
one of choices # 1-3, I request that we invest all of our efforts in the
task of producing EXCELLENT material in support of ADSL Annex J,
and EXCELLENT material in support of g.shdsl.
Each of these proposals must stand on its own, and must satisfy the
5 Criteria. Each proposal must demonstrate that it has a Broad Market
Potential, that it is Compatible with 802.3 and 802, that it has a
Distinct Identity, that it is Technically Feasible, and that it is
I have heard some individuals argue (quite eloquently) that both proposals
must be adopted in order to satisfy the Broad Market Potential criterion.
In my opinion, this is not the best argument to put forward. Neither
nor 802.3 will adopt a proposal that fails to satisfy all of the 5
I fear that by saying that both proposals are required to satisfy the Broad
Market Potential criterion, we imply that neither proposal alone is
May I therefore strongly urge the proponents of each of the two proposals
to concentrate on putting forward the best possible arguments in support
of their proposal. If the Task Force concludes that both proposals satisfy
the 5 Criteria, and that both proposals should be adopted, then the Task
Force will vote accordingly. I do not intend to entertain a "shoot out",
"choose one and only one" motion (though I may conduct a "beauty contest"
type of straw poll, where I ask the Task Force members to indicate their
favorite). I intend to entertain motions on each of the proposals
in the hope that the Task Force casts a >= 75% vote in favor of choice
1, 2, or 3, above.
One last note about the interpretation of our long reach objective: I
interpret our long reach objective, as we adopted it last July, to permit
only ONE PHY for long reach copper. This would seem to eliminate
choice # 3 as an option. Based on past history, I don't think
that we can successfully argue that choice # 3 really represents only
one PHY. As I have said before, our Task Force members may not each
possess a Ph.D. in digital signal processing, but they can all count to
Therefore, if we adopt choice # 3, I believe that we will have a follow on
task to justify the choice, and to modify our objective(s) accordingly. If
we adopt choice # 3 on Monday, January 6th, I will assign an action item
to the Copper Sub Task Force to carry out this task, and we will review
their work on Thursday, January 9th in general session. We will then have
to present the change(s) to the 802.3 Working Group when it meets in March.
Chair, IEEE 802.3ah EFM Task Force