| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Kirsten – We need to be careful to avoid discussion of licensing issues in our meetings and on 802.3 reflectors, and the IEEE-SA Patcom provides references which can help you decide for yourself. I suggest you see the patcom website:
https://standards.ieee.org/about/sasb/patcom/materials.html , and particularly, the FAQ there,
https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/patents.pdf which has a section entitled “Compliant Implementations” which may offer information related to your questions. (FAQs 39, 40, and 41). However, regarding the relationship of new amendments and features to the existing standard, it seems that you are operating from a premise that the new specification might make existing implementations noncompliant. An amendment to 802.3, like 802.3cg, adds new clauses and PHY types – such as the clause 147 10BASE-T1S PHY. Implementations may claim compliance to that clause – without effecting compliance to other clauses.
If the new project amends clause 147, in other than a corrective or maintenance way (these are usually corrigendum projects or maintenance items), the new project would have to do so in a way that is differentiated, so that existing implementations
remain compliant. That usually means either: a) a new clause or clauses, which might include the existing clause by reference and add to it, or be used with the existing clause (think about the relationship of clause 98 autoneg and clause 97), or b) a new
set of options to the existing clause. As such, and to what I think is your concern, I don’t see it being normal 802.3 process to amend clause 147 to change the MDI specification to only call out, and require the use of, a single specified connector type. That would be unusual
and make existing implementations noncompliant. It’s also hard to see that happening by adding an option. Therefore, I think we are headed for a new clause – which could interoperate and reference clause 147, but add requirements to it. New features may then be implemented by picking and choosing the new features. The thing we will have to watch for and think about is which features get bundled together in a single clause or option. On the one hand, having ‘feature sets’
makes for an easier to understand user experience, but on the other hand, it having them separate is more flexible. We’ll have to see where the interests lie as we develop the project. However, I reiterate, please see the patcom materials for licensing issues. I think you’ll find material related to your question there. I hope this helps. Please feel free to contact me privately if you want to discuss in more detail or specific. -george From: Kirsten Matheus <Kirsten.Matheus@xxxxxx> Dear all, (and maybe especially dear David Law) I have the following question to the planned activity. I already indicated it in the ad-hoc call, but would appreciate if someone can explain how the situation is.
In my understanding, the multidrop enhancements offer a number of features that may be used “stand alone” (in case a new PHY is added) or that may be used with 802.1cg. A company might choose to add the topology discovery for their next
cg product but not the power over feature. Just as an example. If now, the multidrop enhancement standard makes any feature mandatory (e.g. the connector, or a new PHY), I do not see how anyone can be standard compliant when picking e.g. just the topology discovery to go with cg, but none of the mandatory
features. If there is no compliance there is no necessity to license any necessary claims. So how can it be insured that no one is sued for patent infringement based on this? In my experience it is an essential part of standardization projects that potential implementers cannot just use parts but have to use all of the mandatory features to be entitled to licensing. Saying, oh, I like e.g. the modulation scheme
of this standard, and implement it in my own, somewhat different (non-interoperable) product, does not work. Anyone buying the product might find themselves in a law suit (not just the vendor). How is this done in the IEEE 802.3 projects? What is the intention with the multidrop enhancements and how can it be ensured that the intentions are met? Thank you and kind regards, Kirsten ------------------------------------- BMW Group Dr. Kirsten Matheus Electrics and Electronics Communication Technologies (EE-322) Knorrstraße 147 80788 München Telephone: +49 89 382 12635 Mobile: +49 151 601 12635 Mail:
Kirsten.matheus@xxxxxx Web:
www.bmwgroup.com
To unsubscribe from the STDS-802-3-SPMD list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPMD&A=1 To unsubscribe from the STDS-802-3-SPMD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPMD&A=1 |