I have no real problem with revising the phrase you have identified, but the revision needs to be unambiguous. The phrase "may not" is ambiguous as it can be interpreted as meaning: - not allowed, in which case "MUST NOT" is the better BCP14 phrase - an attempt to softly say not allowed, but perhaps giving exceptions, in which case "SHOULD NOT" is a better BCP14 phrase - an attempt to indicate an optional feature, in which case "MAY" is a better BCP14 phrase - an attempt to indicate that normally the feature is provided but in cases it might not be, in which case "SHOULD" is a better BCP14 phrase - an attempt to indicate that the text is outside the control of an implementation and a calling entity might or might not perform an operation, in which case "might not" would be a better phrase
In the particular instance you point out, I concede "might not" is probably the better phrase to use. Unless I hear otherwise, I will revise the definition of SnmpTLSAddress to read in part > Values of this textual convention might not be directly usable as > transport-layer addressing information, and may require run-time resolution. The other conversions from "may not" to "MUST NOT" all related to rules related to modifying objects when the RowStatus object is active(1) (e.g., "the following objects may not be modified while the value of this object is active(1)"). In these cases, I believe the "MUST NOT" terminology is more appropriate. Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-571-331-5670 cell [email protected] www.trevilon.com > On Aug 24, 2022, at 3:17 PM, Joe Clarke (jclarke) > <[email protected]> wrote: > > I have read this document, and I feel it is nearly ready. Speaking as chair, > I would like some more eyes on it, so I’ve requested reviews from OPS and SEC > DIRs. > > In my read through the document, I paid close attention to MIB changes, and > your revision description looks accurate. I do wonder if changing some of > the text to reflect more normative-style wording works in all cases, though. > Take for example under SnmpTLSAddress where you have changed “may not” to > “MUST NOT”. It now reads as values of this TC MUST NOT be directly usable as > transport-layer addressing information, and _may_ require run-time > resolution. I think your new phrasing is wrong here. I think in this case, > “may not” is correct. > > Other than that, I’m not opposed to the stronger language. > > In terms of IANA considerations, I think they are clear, though it may be > better to adjust the new registry reference in the MIB to be clearer that > this is to be replaced with a more specific URI. > > Joe > > From: OPSAWG <[email protected]> on behalf of Joe Clarke (jclarke) > <[email protected]> > Date: Thursday, August 11, 2022 at 04:40 > To: [email protected] <[email protected]> > Subject: [OPSAWG] WG LC: draft-ietf-opsawg-tlstm-update > > Hello, WG. I hope those that were in Philadelphia had a safe trip home and > good vacations (if you had them). As we stated during the 114 meeting, we > want to conduct a working group last call for the “Updates to the TLS > Transport Model for SNMP” document. > > We will run this last call for two weeks, ending on August 25, 2022. Please > provide your thoughts and comments before then. > > Also, if someone is interested in serving as document shepherd for this > draft, please let the chairs know. > > Thanks. > > Joe > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
