Re: [802.3_SPMD] General question to the multidrop enhancements specification and objectives
Dear Kirsten,
George has referenced the FAQs that I believe may be relevant, and as he noted we need to be careful with respect to discussions that take place on IEEE 802.3 reflectors and in IEEE 802.3 meetings. As a result, if you still have questions after reviewing the material on the PatCom website, please follow the directions on the 'Guidelines for IEEE-SA Meetings' slide and contact the IEEE-SA Standards Board Patent Committee Administrator at <patcom@xxxxxxxx>.
Thanks and best regards,
David
-----
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: 16 May 2020 17:54
To: STDS-802-3-SPMD@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPMD] General question to the multidrop enhancements specification and objectives
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>
Sent: Saturday, May 16, 2020 9:15 AM
To: STDS-802-3-SPMD@xxxxxxxxxxxxxxxxx
Subject: [802.3_SPMD] General question to the multidrop enhancements specification and objectives
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
--------------------------------------------------------------------
Bayerische Motoren Werke Aktiengesellschaft
Vorstand/Board of Management: Oliver Zipse (Vorsitzender/Chairman),
Milagros Caiña Carreiro-Andree, Klaus Fröhlich, Pieter Nota,
Nicolas Peter, Peter Schwarzenbauer, Andreas Wendt.
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Norbert Reithofer
Sitz und Registergericht/Domicile and Court of Registry: München HRB 42243
--------------------------------------------------------------------
________________________________________
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
________________________________________________________________________
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