| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
What are you thanking ME for? Richard took on this big job! From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx> Thank you, George Richard will spearhead the work on new management objects for Clause 30 to be submitted as a comment against D2.2. I hope we can use the reflector for consensus building and simply roll in new objects with the group’s consensus
Regards Marek From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Marek – that sounds like a good plan. You might also consider an editor’s note capturing some general thoughts and soliciting complete proposals for resolution. From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Richard, The proposed modifications go way beyond the original scope of the comment and I do not think we will be in position to craft individual objects on the fly at the comment resolution. If these indeed are needed, I believe we should have
a more complete proposal with a comment against D2.2 once published, and consensus building around it. It would be a major change to Clause 30 material.
At this cycle, I suggest we fix the problem with aTimeSyncCapabilityType definition to make it correct, and then use the time of the next recirculation to build a better set of management objects for Clause 30
Regards Marek From: Richard Tse <0000117d24f8db68-dmarc-request@xxxxxxxxxxxxxxxxx>
In my understanding, the managed objects (listed below) in clause 30.13 only represent the result of the configurations contained in the TimeSync registers in clause 45. They don’t currently allow a MIB to configure these objects (e.g.,
the sum of the delays is given in a management object, but the MIB cannot configure the individual component delays through these same management objects).
I believe that George’s suggestion earlier of adding new management objects for the sub-nanosecond delays is appropriate since the capability to support this is independent from that of the nanosecond resolution delays. Also, the INTEGER
value of their aTimeSyncDelayTX/RXmin/max objects have different units (2-16 nanoseconds vs nanoseconds). I also believe the other new 802.3cx functions (listed in the bullet list below) are just as important as the above delay functions and, thus, deserve equal representation as management objects. If we follow the same structure as the delay management objects, we should have an item for the capability and for the configured operation for each of the following functions:
As a result, I suggest that we provide following management objects, where the ones in
red need modification and the ones in
blue are new:
The availability of these management objects allows a management function to determine the capabilities and the operating status of an 802.3 instance. From this determination, it could set up its network to get the best timestamping performance.
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
EXTERNAL EMAIL:
Do not click links or open attachments unless you know the content is safe
Marek (bringing our conversation back to the reflector) – So, we agree that clause 30 objects are not necessary, because the “real” MIB now lives in 802.3.1 and 802.3.2. So that means that at the top level, the Task Force has a choice – whether to take the management out or to leave in the clause
30 – as a way of showing the intended structure of the management objects. Clause 30 is used by most projects that I am aware of in exactly this way – to add necessary management objects (and amend others), and serve as a template, a proxy, if you will, for the work that needs to be done in the 802.3.1 (and 802.3.2
YANG) documents. That way we aren’t amending 2 (or 3) documents at once, and can still get a unified look at the management. It is true that sometimes you get stuff in the 802.3.1 and 802.3.2 docs that just reference the registers, but usually our projects
update Clause 30 so that we have a template to look at. Until Clause 30 is deprecated I suggest we continue the practice. Further, it would be bad form, IMHO, to amend clause 30 partially - updating existing objects with the new information while leaving
out new ones that were intended. So, my dog not really being in the fight – I’ll ask those intending to use 802.3cx – do you intend new management objects to indicate which reference is being used for the timestamp (SFD or FIRST SYMBOL), and whether fine resolution delay
is supported. (I’m assuming these are independent features, because they appear to be independently controlled) If no, then we should delete 30.13.1.7 and be done with it. That can then be the response to all the comments – but please consider this and don’t go back and THEN write a mib later into the 802.3.1 and 802.3.2 – it will make the 802.3
amendment process misleading, because reviewers will consider this information that you don’t need to pass up to the management system when reviewing the document. Also, reviewers may not know know how to parse 30.13.1.3 & 4: to consider 30.13.1.3 and 30.13.1.4
as an exact number with zero on the new ‘sub-ns fraction’ which has been added, or as simply the less-precise legacy value. If, however, you want these features captured in a MIB, then we should rewrite 30.13.1.7, and comments my comment 294 & 295 along with Richard Tse’s 306 point us in the right direction. Richard’s makes me think we want two, not one new
parameters. Now that I’m starting to understand this draft better, I think you’re actually adding two independent features (shifting the delay point and fine resolution), that are independently determined and controlled – if that is right, the structure of
the original 30.13.1.7 as a single parameter saying ‘.3cx or legacy’ didn’t really work anyways, and furthermore, you may need the MIB to be able to SET the data delay point. I would suggest writing 30.13.1.7 as aTimeSyncResolution, which has two values (like the current 30.13.1.7): NANOSECOND or SUBNANOSECOND (with meanings Capable of nanosecond resolution or capable of subnanosecond resolution) – and with
text determining it pretty much like the existing one, but mapping to registers .2 and .3 (see my comment 295 for the edit to the description – the rest is just a name change and changing the attributes) The second parameter, which would be 30.13.1.8, I’d suggest as aTimeSyncMeasurementPoint. I’ll need some help to write aTimeSyncMeasurementPoint correctly, because you want it to be meaningful for legacy devices too, and I’m not sure,
but I think you might also need an action to SET the measurement point (or should we uplevel it and just make the attribute the unit/change?) -george From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Dear colleagues, Just a reminder that we have several unresolved comments associated with a managed object specificized in 30.13.1.7. At this time, the proposal on the table is to remove this object altogether, but there were concerns about this course
of action. I would like to solicit any alternative proposals to have the text in this subclause revised. Since 6 out of remaining 18 comments are associated with this particular topic, it would be really handy to have a solid proposal available tomorrow.
Regards Marek To unsubscribe from the STDS-802-3-ITSA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1 To unsubscribe from the STDS-802-3-ITSA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1 To unsubscribe from the STDS-802-3-ITSA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1 To unsubscribe from the STDS-802-3-ITSA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1 To unsubscribe from the STDS-802-3-ITSA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ITSA&A=1 |