| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 |