> I still assert that the way I read the SnmpTLSAddress paragraph, “may not” > makes more sense.
I think we agree on the intent at this point, we just need to agree on the wording that conveys the correct intent. I talked to my technical editor and she confirmed that "may not" is ambiguous at best and the most literal interpretation would be "not allowed" (i.e., "may" means allowed but not required; but the negation would mean not allowed). She was not willing to commit to the "might not" language and suggested that the better way to provide the flexibility is to either remove the negative (e.g., "Values of this textual convention may not be directly usable as transport-layer addressing information or, and may require run-time resolution.") or to move the negative (e.g., "Values of this textual convention may not be directly unusable as transport-layer addressing information, and may require without run-time resolution.") I am happy to do either. I will also add the most recent text to the boilerplate. 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 29, 2022, at 8:40 AM, Joe Clarke (jclarke) <[email protected]> wrote: > > I think it serves to provide some context in the document text for all of the > new normative language you’re adding in the MIB to add clarity. > > I still assert that the way I read the SnmpTLSAddress paragraph, “may not” > makes more sense. For example, if the value of the object that uses this TC > is a hostname, I cannot use it directly without doing DNS resolution on it. > However, if it’s an IP address, I can use it directly (because if not, then > what am I supposed to do with it?). > > Joe > > From: Kenneth Vaughn <[email protected]> > Date: Friday, August 26, 2022 at 09:26 > To: tom petch <[email protected]> > Cc: Joe Clarke (jclarke) <[email protected]>, [email protected] > <[email protected]> > Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-tlstm-update > > <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] <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] > <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
