| 2020-11-19 |
2 Dec 2020 Concall |
Received |
Received |
|
| 2020-12-16 |
16 Dec 2020 Concall |
The proposed change is desired, but the exact process and procedure for updating the MIB needs further discussion. Unclear at this point what vehicle would be used to make this change. |
Technical experts review |
|
| 2021-02-16 |
16 Feb 2021 Concall |
It was agreed to review the proposed changes with IETF MIB Doctors. A draft email has been created so specific changes can be included for this item. If the resolution occurs in time this could be included in Q-Rev or Qcw. |
Technical experts review |
|
| 2021-03-09 |
9 Mar 2021 Plenary |
The proposal was reviewed with IETF MIB Doctors via email and the following response was provided:
Dear Norm,
since a TC has a status clause, you can of course deprecate it. This
may trigger warnings on modules that use the TC (and which had no
warnings before).
Is it possible replace a TC with a different one without changing the
OID of an object? I think so as long as the syntax and semantics are
identical. Section 10.2 of RFC 2578 spells out the case of replacing
the value of a SYNTAX clause with a TC and it says its OK as long as
syntax and semantics are the same. There are not really any side
effects since the "type" definition used in an object definition is
not externally visible/accessible.
To sum up: What you are proposing appears to be legal from the SMIv2
perspective. Whether its worth the effort is something I can't judge.
Such a change likely takes years to propagate, in the IETF it would
take decades to infinity. So you will have to make a judgement call
how widely the TC is used and what the update paths of affected
documents will be.
|
Technical experts review |
|
| 2021-03-12 |
9 Mar 2021 Plenary |
Instructions from the MIB doctors. We can make this a comment against Q-Rev or Qcw. Need to talk with the editors
Attached is my question to MIB doctors, and the response. If you want to include this in the resolution, feel free. Here is my suggestion for the "do this" part of the resolution:
1. Create a new TC in IEEE8021-TC-MIB called "IEEE8021PriorityMapping", with exactly the same clauses as the current IEEE8021PriorityCodePoint, except for the name of the TC.
2. Add "STATUS DEPRECATED" to IEEE8021PriorityCodePoint
3. Change all uses of IEEE8021PriorityCodePoint in Clause 17 from IEEE8021PriorityCodePoint to IEEE8021PriorityMapping EXCEPT:
4. DO NOT change the IEEE8021-SRP-MIB module. Its uses of IEEE8021PriorityCodePoint are incorrect, and these errors are being fixed separately from this maintenance item.
5. Update the LAST-UPDATED and REVISION clauses of the changed MIBs.
|
Complete then Ballot |
|
| 2023-01-20 |
16 Jan 2023 Interim |
This has been changed to INTEGER type based on discussions in the working group and has been balloted on draft d1.5 |
Balloting |
|
| 2023-10-17 |
17 Oct 2023 Concall |
P802.1Qcw/D2.2 is in pre-publication. |
Approved |
|