Use of company names...
All,
Patrick is quite correct in his comment below that the chair has been
unusually lax in not challenging the personification of companies. In fact,
the chair is also culpable of this infraction.
Therefore, would everyone (me too) please remember that 802.3 only has
individual (meaning human) members. There is no corporate entity that can be
a member. There are no company presentations, company proposals, company
positions, company motions, company votes. Only people can do these things.
My apologies to all if I have misdirected or mislead any of you.
I promise not be upset if I ever slip again and require reminder.
jonathan
Jonathan Thatcher,
Chair, IEEE 802.3ae (10 Gigabit Ethernet)
Director of Engineering, World Wide Packets
PO BOX 141719, Suite B; 12720 E. Nora, Spokane, WA 99214
509-242-9000 X228; Fax 509-242-9001; jonathan@xxxxxxxxxxxxxxxxxxxx
> -----Original Message-----
> From: Patrick Gilliland [mailto:pgilliland@xxxxxxxxxxx]
> Sent: Tuesday, March 21, 2000 12:00 PM
> To: stds-802-3-hssg@xxxxxxxx; rtaborek@xxxxxxxxxxx
> Subject: Re: XAUI and 64b/66b
>
>
>
> Rich,
>
> 1.) I believe it is proper to mention the support
> of 27 individuals for the 8B/10b XAUI/XGXS proosal.
>
> Typically, at IEEE we do not have companies voting
> their support as a block, and it has been the intent
> of the IEEE not to engage companies formally as
> voting members.
>
> I have seen quite a number of these corporate references
> in the last few days, and I thought the chair might have
> noticed by now and stepped in.
>
> 2.) It raises an interesting theoretical question about
> individuals who are incorporated as one-man consulting
> and design services. Should they be barred from voting
> because their vote might also be interpreted as representing
> the interest of their company?
>
> Before anyone flames me for 2.), please consider the source
> and the purely diversionary motives.
>
> Best Regards,
>
> Patrick Gilliland
>
> -----------------------------------------------------
>
> At 07:26 PM 3/19/00 -0800, you wrote:
> >
> >Roy,
> >
> >Please go ahead and put together a proposal for the Serial
> PHY based on
> SDLC or
> >HDLC. The complete proposal on the table for an 8B/10B-based
> XAUI/XGXS is
> backed
> >by at least 24 companies. The complete proposal on the table
> for a Serial LAN
> >PHY based on XAUI/XGXS and 64B/66B encoding is backed by at least 27
> companies.
> >
> >I don't see any other complete XAUI/XGXS or Serial LAN PHY
> proposals based on
> >SLP, HDLC, SDLC, SUPI or otherwise anywhere.
> >
> >I'd be very happy to compare proposals.
> >
> >P.S. XAUI is optional.
> >
> >Best Regards,
> >Rich
> >
> >--
> >
> >Roy Bynum wrote:
> >>
> >> Rich,
> >>
> >> What several people is saying that making the 8B10B codes
> a required
> >> precursor to the 64B/66B encoding removes the "optional"
> label that has
> been
> >> put on XAUI. You can have your cake and eat it too.
> Either XAUI is an
> >> optional XGMII extender and 8B10B is not part of the
> 64B/66B encoding, or
> >> 8B10B is part of 64B/66B and XAUI is a requirement for all
> implementations.
> >>
> >> While I laud your work and experience with 8B10B, there
> are other solutions
> >> that are just as elegant. I recognize that you have
> wanted 8B10B to be
> part
> >> of the requirements for 10GbE from day one. This has
> perhaps clouded your
> >> ability to be pragmatic.
> >>
> >> If I were not pragmatic about the uses of protocols, I
> would be proposing
> >> that we use HDLC, but I am not. SDLC and HDLC have been
> around longer than
> >> 8B10B as communications protocols. I have been working
> with SDLC and HDLC
> >> as long if not longer than you have with 8B10B. The first
> protocol that I
> >> used to any extent other than SDLC was BiSync (1968). Do
> you see me
> >> suggesting these? I am pragmatic and unlike the IETF,
> recognize that HDLC
> >> has some major flaws and should not be part of the
> requirements for 10GbE.
> >>
> >> Again, is XAUI going to be optional or not? If it is not
> optional, then I
> >> think that you are going to have a hard time getting 75%
> of the people to
> >> include it in the standard. If XAUI is optional, then
> 8B10B encoding can
> >> not be a required precursor to any PCS. Which is it?
> >>
> >> With respects,
> >> Thank you,
> >> Roy Bynum
> >>
> >> ----- Original Message -----
> >> From: Rich Taborek <rtaborek@xxxxxxxxxxx>
> >> To: HSSG <stds-802-3-hssg@xxxxxxxx>
> >> Sent: Thursday, March 16, 2000 4:22 PM
> >> Subject: Re: XAUI and 64b/66b
> >>
> >> >
> >> > Ben,
> >> >
> >> > I disagree with your direction on this issue for the
> same reason that I
> >> have
> >> > trouble with the lack of specification of an optional
> interface in
> >> 1000BASE-X
> >> > which is implemented in 100% of Ethernet products implementing
> 1000BASE-X.
> >> I may
> >> > be being politically incorrect in stating this, but I
> typically like
> >> products to
> >> > match specs.
> >> >
> >> > I view XAUI as being a very prevalent 10 GbE interface,
> perhaps not as
> >> prevalent
> >> > as the serial side of the GbE Ten-Bit-Interface. Barring no other
> complete
> >> and
> >> > workable XAUI/XGXS proposals that meet the requirements
> of an optional
> >> XGMII
> >> > extender, my view is that the PCS should accommodate the
> optional XGMII
> >> extender
> >> > as well as operate properly without one. Since we'll
> have multiple PCS's
> >> > probably corresponding to PMA/PMDs, and one of the
> heavily backed (27
> >> companies)
> >> > Serial PHY proposals endorse a 64B/66B PCS, I believe
> that this PCS
> should
> >> > support the optional XGMII extender which is specified
> to be PHY/PMD
> >> > independent. The Serial PHY proposal already does this
> and I see no
> >> benefit or
> >> > savings in cost, complexity, etc. in removing it.
> >> >
> >> > I also see no significant difference in complexity
> between converting
> >> between
> >> > XGMII and PCS 64B/66B codes whether or not the IPG
> includes only /I/ or
> >> /A/K/R/.
> >> >
> >> > Best Regards,
> >> > Rich
> >> >
> >> > --
> >> >
> >> > "Benjamin J. Brown" wrote:
> >> > >
> >> > > Rich,
> >> > >
> >> > > Jonathan just sent me a note saying that I was even confusing
> >> > > him right now so I want to stop and ask my question again. I'll
> >> > > try to make this as clear as possible.
> >> > >
> >> > > In the layer diagram that Brad showed in Albuquerque, the XAUI
> >> > > was shown as an XGMII extender. To me this means that the
> >> > > reconcilation sub-layer speaks using XGMII language and the PCS
> >> > > listens using XGMII language. The XAUI can extend this
> interface
> >> > > by translating from XGMII to XAUI but it must translate back
> >> > > again before it gets to the PCS. The XGXS block is the
> translator.
> >> > >
> >> > > The 64b/66b proposal as written ignores the XGXS block between
> >> > > XAUI and the PCS. It is my contention that, though this would
> >> > > work, it is unnecessary and even burdensome to those
> implementors
> >> > > that choose to not use XAUI. 64b/66b would work equally as well
> >> > > without the XAUI specific control codes as they add nothing to
> >> > > the efficiencies of 64b/66b (that I can tell). The
> XGMII specific
> >> > > control codes are completely adequate for 64b/66b. In
> my opinion,
> >> > > a serial PCS should be specified as if XAUI didn't exist.
> >> > >
> >> > > I'll even go so far as to state that, in my opinion, even a
> >> > > parallel/CWDM PCS should be specified as if XAUI didn't exist.
> >> > > If this PCS turns out to be identical to the XGXS
> block then some
> >> > > implementors may choose to avoid the encode/decode/encode as
> >> > > specified in the standard, but I believe that is how it should
> >> > > be specified.
> >> > >
> >> > > Is the question/comment still confusing or do you
> merely disagree?
> >> > >
> >> > > Ben
> >
> >-------------------------------------------------------
> >Richard Taborek Sr. Phone: 408-845-6102
> >Chief Technology Officer Cell: 408-832-3957
> >nSerial Corporation Fax: 408-845-6114
> >2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> >Santa Clara, CA 95054 http://www.nSerial.com
> >
> >
>
application/ms-tnef