Yong,
You are correct that for discussions directly related to the comments and in-scope solutions, we remain in scope.
I won’t take a heavy hand here, and I am not ruling the comments out of scope. Regarding Claude’s comment (and while the presentation was Don’s the comment was Claude’s), the suggested remedy as it currently stands involves a new service
interface, a priority client at the level of the MAC, which, I believe, would be outside our scope. I have had some discussions with the commenter and with Don and I think we’re working on finding a way forward, while remaining in scope.
Likewise, discussion of multiple transmit opportunities (which is related to a comment, and, as discussed, I believe would be within the existing physical layer service interface), appears to be within the scope, but the discussion was
ranging off into the wide ranging discussion of market opportunities. We have to be careful there, and keep ourselves within the scope of the project, or we could use ‘justifying with end-user use cases’ to expand the scope within any project. We are in
the working group ballot phase of the project and need to focus on in-scope remedies to comments. Hence, my reminder.
-george
From: Yong Kim <yongkim.mail@xxxxxxxxx>
Sent: Friday, September 07, 2018 12:37 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Scope reminder (was RE: [802.3_10SPE] Support for Don Pannell's proposal)
Perhaps I am missing something..
Whether it is a request to consider multiple transmit opportunities (Kirsten et al comments) through device ID being logical versus physical, or request to consider explicit weighted transmit opportunities
(Don et al comments), they are all related to comments against transmit opportunities specification.
Are the above out-of-scope discussions? I naturally thought they were in-scope -- request to change the specification parameter and justifying them with end-user use cases.
Yong Kim, affiliation: NIO
All - as Chair for 802.3cg, I need to try to contain the scope of our discussions. We need to remain cognizant of the project's scope, as defined in the project documentation (PAR, CSDs and Objectives)
We have objectives, approved at the 802.3 level, and CSDs, approved at the 802.3 and 802 level. Both of these are subservient to the PAR, approved not only by 802.3 and 802 but at the standards board level. 802.3 process requires a CFI and study group to
propose changes to the PAR, and since we are no longer a study group, we are not discussing changes to the PAR, which would need a new CFI and study group to propose.
Our current PAR specifically states our scope as: Specify additions to and appropriate modifications of IEEE Std 802.3 to add 10 Mb/s Physical Layer (PHY) specifications and management parameters for operation, and associated optional provision of power, using
a single balanced pair of conductors.
This means that we need to constrain our discussion within the context of: physical layer specifications and management parameters. Note, that I did not use the common shorthand of a "PHY project", which could be interpreted to mean a specifying a 'physical
layer entity' - a slightly more limited thing. Our specifications begin and end at the defined physical layer service interface.
I will further note that 802.3's current CSDs and objectives do not specifically call out TSN as a requirement, and the objectives do reference half-duplex and multidrop, shared-medium (non point-to-point) PHYs, which are specifically excluded from a number
of 802.1 specifications.
I try to tread very lightly when considering whether something is in scope, and have let this discussion go on for a while, hoping it would find its way clearly into the project scope.
It is nice, and even useful in a larger context, to talk about what different segments of a market may need, and what 802.1 TSN may offer in other specifications.
However, it is not the 802.3cg project. The project is solving particular problems, within a particular scope defined by our project documentation.
Discussing and working on solutions to the comment within the scope of our project are encouraged, but please try to keep within that scope.
-george
George Zimmerman, Ph.D.
Chair, IEEE P802.3cg 10 Mb/s Single Twisted Pair Ethernet Task Force
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
george@xxxxxxxxxxxxxxxxxxxx
310-920-3860
________________________________________________________________________
To unsubscribe from the STDS-802-3-10SPE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
|