From: Kenneth Vaughn <[email protected]> Sent: 26 August 2022 14:25
<tp> Well, you do not include the current BCP 14 boilerplate in the I-D which muddies the waters further. Trying to find the right boilerplate is difficult, at least for someone new to the process; I expected to find it in the style guide or similar sources, but no such luck. After spending a fair while looking for the official boilerplate, I just gave up and looked at the most recent RFCs, which seem to replace "as described in [RFC2119]" with "as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here." I will include this change when I change the other change described below. Please let me know if you are aware of any other necessary changes. <tp2> Well yes, the RFC Editor web site is fairly useless these days but in this case it is probably because the use of 'must' and 'MUST' is not an RFC Editor question but an IESG question. It is they that make the rules so the latest view on that is in RFC8174 where you will find the rules and the boiler plate. My point was that it is RFC8174 that clarifies the meaning of the lower case words and so that reference needs fixing before I think it is possible to discuss what words should be used which is what this thread is all about. Tom Petch Tom Petch Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-571-331-5670 cell [email protected]<mailto:[email protected]> www.trevilon.com<http://www.trevilon.com> On Aug 26, 2022, at 3:38 AM, tom petch <[email protected]<mailto:[email protected]>> wrote: From: OPSAWG <[email protected]<mailto:[email protected]>> on behalf of Kenneth Vaughn <[email protected]<mailto:[email protected]>> Sent: 25 August 2022 22:00 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 <tp> Well, you do not include the current BCP 14 boilerplate in the I-D which muddies the waters further. Tom Petch 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]<mailto:[email protected]><mailto:[email protected]> www.trevilon.com<http://www.trevilon.com/><http://www.trevilon.com<http://www.trevilon.com/>> On Aug 24, 2022, at 3:17 PM, Joe Clarke (jclarke) <[email protected]<mailto:[email protected]><mailto:[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]<mailto:[email protected]><mailto:[email protected]>> on behalf of Joe Clarke (jclarke) <[email protected]<mailto:[email protected]><mailto:[email protected]>> Date: Thursday, August 11, 2022 at 04:40 To: [email protected]<mailto:[email protected]><mailto:[email protected]> <[email protected]<mailto:[email protected]><mailto:[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]<mailto:[email protected]><mailto:[email protected]> https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
