| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
All, I can add no more to the strong arguments made by Paul, Brad, Mark and others. It seems clear that at some point, consensus will be reached to switch to Arabic labeling simply because the complexity of the Roman numbering will force it at some point. The sooner we make the change to Arabic, the less confusion we will have and the better we serve our industry. .3by began the transition to a simpler Arabic solution. I’m traveling in the morning but I trust .3bs to continue the transition. Regards, Dale From: Kolesar, Paul [mailto:PKOLESAR@xxxxxxxxxxxxx] Mark and all, the use of Arabic numbers is superior to the immediate understanding of the written specification, not only because it assists those who may be Roman numeral impaired, but also because it is consistent with our PMD/PHY nomenclature (e.g. 400GBASE-). There are some pronunciation issues with either the Roman or Arabic choice. But the Arabic pronunciation issues can be cleared up with simple familiarity, while the Roman numeral approach is stuck with strings of letter combinations over which we will trip if attempted to be said as words. So while it is easy to get used to saying “400-G-AUI” and avoid “400G-GAUI” and “400-GAUI”, the consonant strings associated with some of these Roman numerals are forever unnatural or unwieldy. To illustrate, here is a list of current and probable future AUI names using the Roman nomenclature and my observations on their pronunciation. 10 = X and is in use as XAUI (pronounced zau-wee) 25 = XXV and already converted to 25GAUI rather than XXVAUI, 50 = L and easy to say as LAUI, 100 = C and easy to say as CAUI, 200 = CC and sounds like stuttering to say as CCAUI, 400 = CD is an unnatural consonant combination in English words, 800 = DCCC and sounds like a phonetic machine gun as DCCCAUI, 1600 = MDC and is phonetically challenged as MDCAUI, etc. The alternative for Roman numerals is to say them one at a time, but that too is a burden that can be cause for ridicule. The first incidence of the conversion to Arabic for 25G begs for consistent application of that new convention going forward. Continuing to mix Roman with Arabic will look foolish by its inconsistency. Let’s make a clean break now. It is time to consistently apply Arabic nomenclature. Regards, Paul From: Mark Nowell (mnowell) [mailto:mnowell@xxxxxxxxx] The 802.3bs Task Force will be handling it’s motions this week on Friday. Unfortunately many may miss this due to travel constraints – myself included. I therefore thought I’d use the reflector to share my thoughts around nomenclature as the group looks to adopt their 200GbE SMF baselines. This topic keeps coming up as many appear to be frustrated with the continuing use of Roman numerals nomenclature for the AUI and MII interfaces. While the simplistic use of Roman numerals for 10GbE (XAUI) and 100GbE (CAUI) were somewhat easy to understand and say, we saw that with 25GbE it was unwieldy and when looking ahead at 200 GbE and beyond (800, 1000, 1600 … it wouldn’t get any better). Therefore 802.3by switched back to the arabic nomenclature for the 25 GbE standard. The joint meeting of the 50G/NGOATH and the 200GbE SMF Study groups in Macau considered the topic and a straw poll there was overwhelmingly in favor of using Arabic nomenclature. Obviously this is non-binding, so this week the 802.3cd group followed through with adopting its nomenclature that included the arabic usage for the AUI and MII interfaces (and of course for the PMDs etc). A lot of the discussion during the TF meeting centered around the challenges with talking to customers, press etc to explain things to those not fully steeped into the depths of 802.3 specification writing. The motion result was Y:65 N:9 A:13. I’m hoping that the 802.3bs Task force will also follow through in a similar manner when they make their decisions on adopting 200 GbE baselines and be sure to consider the clear direction from the SG that generated the work. Since I won’t be there tomorrow for the discussion, I wanted to share my thoughts and allow others to respond in case they may also be missing the discussion on Friday. Regards…Mark |