RE: [EFM] Moving forward on extended temperature range optics
"The road to hell is paved with good intentions". I thought Bill and Howard had got the discussion onto a sensible footing but a process of feature creep seems to have set in immediately after.
Let's repeat, for those who have not yet unsubscribed from this reflector: environmental conditions such as temperature, supply voltage and so on are considered out of the scope of the standard. So are customer-facing requirements (parts of a procurement spec) such as cost, reliability and labelling, and component temperature. 802 concentrates on interoperability requirements: observable behaviour at ports.
That doesn't mean we should not discuss the other conditions, as far as they relate to technical and economic feasibility or broadness of market. We can "take on" the temperature issue in that sense, and seek optical parameters which are compatible with the access environments. But we won't make normative requirements out of them in our standard; we'll leave that to the buyers, who will.
We have reconciled these two conditions with an overwhelming vote for an informative annex. Let us all honour that agreement.
An informative annex wouldn't have a PICS.
We have better things to do with our time than re-invent wheels. We don't need to write temperature test procedures!
As Bill points out, the market will provide the driving force for temperature specs. Following that thought, I would say that any environmental spec that 802 wrote would be futile - money talks; some operators will install their optoelectronics in sheltered locations and temperate climates, and save capex, whatever the standard says, others wish to install their optoelectronics in non-weatherprotected locations in extreme climates, whatever the standard says, to save opex. And it is the operator's $ that will encourage "more effort ... at the extended range", not empty words.
Some have claimed that "access is different" and therefore we need to specify things which have been out of scope for many generations of the Ethernet standard. We compare with the traditional IT market where the temperature range is much less, so meeting it is not such a problem. But in that market, there still IS a temperature requirement, set by the market and documented in datasheets and purchase specs. Now in the access market, the temperature ranges are wider and the market is much less homogeneous. Does this mean that our methodology must change? Of course not, only our assumptions and the optical parameters which address them should change.
Several people now have expressed an interest in the underlying issues of technical and economic feasibility or broadness of market (Howard's task A: Ensure that ... the ... Optical ... parameters ... can be met ... across an "extended temperature range" of operation). But while some people are still asking for normative material which they will vote against so that they can hold the standard to ransom, and which would waste a great deal more of our time to no effect (see market forces), it's difficult to have a reasonable discussion on these underlying issues.
Now some information about labelling. The problem here is one of very restricted space and overlapping jurisdictions. Labels don't contain much, but that's OK, these days one can find the datasheet on the web. Labels have to obey national laws (safety marks, "made in") and the MSAs also have something to say:
Quoting from the SFP MSA,
"A5. Labeling of SFP Transceivers
Color coding requirements for optical SFP transceivers are specified in Figure 1B.
Each SFP transceiver should be clearly labeled. The complete labeling need not be visible when the SFP transceiver is installed. Labeling should include appropriate manufacturing and part number identification, appropriate regulatory compliance labeling, and a clear specification of the external port characteristics. The external port characteristic label may include such information as optical wavelength, required fiber characteristics, operating data rate, interface standards supported, and link length supported.
Fig. 1B, note 4
Color code: An exposed colored feature of the transceiver (a feature or surface extending outside the cage assembly) shall be color coded as follows:
* Black or beige for multi-mode
* Blue for single mode"
And 802.3 has sections like "It is recommended that each PHY (and supporting documentation) be labeled in a manner visible to the user, with at least the applicable safety warnings and the applicable port type designation. Labeling requirements for Class 1 lasers are given in the laser safety standards referenced in ...."
But I don't think this defeats Bill's idea; is it not the case already that the datasheet will give a temperature range (who would buy if it didn't) and an implementation claimed to be compliant to the (normative) optical/timing/electrical/protocol PICS must meet them over the stated temperature and supply ranges given in the datasheet. So I had thought Bill's point 4 was already covered.
Piers