Minutes for 0304: IEEE8021PriorityCodePoint misnamed

Standard: IEEE Std 802.1Q-2018 Clause: 17.7.1 Draft with fix: Qcw/d?.? Submitted: 2020-11-16
Show Request Show Preformatted Request
Date Meeting Text Status
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

Back