> <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. 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 26, 2022, at 3:38 AM, tom petch <[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] > <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] > <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] > <mailto:[email protected]>>> on behalf of Joe Clarke (jclarke) > <[email protected] > <mailto:[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] > <mailto:[email protected]>> <[email protected] > <mailto:[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] > <mailto:[email protected]>> > https://www.ietf.org/mailman/listinfo/opsawg > <https://www.ietf.org/mailman/listinfo/opsawg>
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
