Re: [auth48] *[AD] AUTH48: RFC-to-be 9456 <draft-ietf-opsawg-tlstm-update-15> for your review

[Kenneth Vaughn <[e-mail]>]

I can review the files tomorrow, but here are the answers to the additional questions.

> 1) please note that per IANA guidance we had to use a shorter URL for the registry.
This is fine

>> 2) Regarding our question 7)b) and your reply:  Were any updates to be made here?  Your NEW text appears to us to be identical to the original.
>> 
>> b) Please confirm that "local part" (2 words, no hyphen) and
>>>> Original:
>>>> The
>>>> local part of the rfc822Name is passed unaltered but the
>>>> host-part of the name MUST be passed in lowercase.
Sorry, it should be:
NEW
The local-part of the rfc822Name is passed unaltered but the
domain of the name MUST be passed in lowercase.

> 3) Do you prefer that spaces be added or removed around the following items?
Based on the examples in RFC 2578 - and I believe most RFC MIBs that I have seen - I think there should be a space on either side of a curly bracket and no space on the interior of a parenthesis. When curly brackets enclose more than one item, it is most common to use a newline on the inside of the curly bracket and then have the closing bracket align with the parent clause (e.g., the letter "O" in "OBJECTS" in the following example. For example (using red underscores to highlight where spaces are):

{_snmpTlstmConfig 1_}

OBJECTS {
     snmpTlstmAddrServerFingerprint,
     snmpTlstmSessionInvalidServerCertificates
}

OCTET STRING (SIZE_(1..255))

Integer32_(0..255) 


Regards,
Ken Vaughn

Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
[phone] cell
[e-mail]
www.trevilon.com

> On Aug 24, 2023, at 4:58 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi, Ken, Joe, and *Rob.
> 
> Ken and Joe, thanks for the emails.
> 
> * Rob, in addition to our question regarding the IANA Considerations section, we will need your approval as AD for the following:
> 
> 1) adding RFC 3410 to the list of Normative References
> 2) the update to Table 1
> 3) the updates to the MIB module (Section 4)
> 
> Ken and Joe, we have updated this document per your notes below.
> 
> Ken, three follow-up items for you:
> 
> 1) Regarding our question 5) and your reply:  Apologies for our confusion regarding the use of "REFERENCE" entries.  We updated per your suggested text -- thank you -- but please note that per IANA guidance we had to use a shorter URL for the registry.
> 
> = = =
> 
> 2) Regarding our question 7)b) and your reply:  Were any updates to be made here?  Your NEW text appears to us to be identical to the original.
> 
> b) Please confirm that "local part" (2 words, no hyphen) and
>>>> "host-part" (hyphenated) are both correct.  Would "localpart"
>>>> and "hostpart" be acceptable?
>>>> 
>>>> Original:
>>>> The
>>>> local part of the rfc822Name is passed unaltered but the
>>>> host-part of the name MUST be passed in lowercase.
>>> Agreed, this is original text that is worth improving. It appears that RFC 822 (and its current replacement RFC 5322) both use the names "local-name" and "domain" when formally defining the name format. I suggest the following:
>>> 
>>> NEW
>>> The local part of the rfc822Name is passed unaltered but the
>>> host-part of the name MUST be passed in lowercase.
> 
> = = =
> 
> 3) Regarding our question 12)d) and your reply:  Apologies for not being clear and asking for your preference.  Do you prefer that spaces be added or removed around the following items?
> 
>>>> d) Would you like spacing to be consistent within this document for
>>>> the following?
>>>> 
>>>> Curly brackets (most have spaces around them):
>>>> 
>>>> {snmpTlstmConfig 1}
>>>> 
>>>> OBJECTS { snmpTlstmAddrServerFingerprint,
>>>>          snmpTlstmSessionInvalidServerCertificates}
>>>> 
>>>> "SIZE" entries:
>>>> (SIZE (1..255))
>>>> (SIZE (0..255))
>>>> (SIZE(1..255))
>>>> (SIZE(0..1024)) -->
>>> 
>>> Yes, consistency is good and does not affect the code.
> 
> = = =
> 
> The latest files are posted here.  Please refresh your browser.  Also, please review our updates carefully, and let us know if anything is incorrect or was missed:
> 
>   https://www.rfc-editor.org/authors/rfc9456.txt
>   https://www.rfc-editor.org/authors/rfc9456.pdf
>   https://www.rfc-editor.org/authors/rfc9456.html
>   https://www.rfc-editor.org/authors/rfc9456.xml
>   https://www.rfc-editor.org/authors/rfc9456-diff.html
>   https://www.rfc-editor.org/authors/rfc9456-rfcdiff.html
>   https://www.rfc-editor.org/authors/rfc9456-auth48diff.html
> 
>   https://www.rfc-editor.org/authors/rfc9456-xmldiff1.html
>   https://www.rfc-editor.org/authors/rfc9456-xmldiff2.html
> 
> Thanks again!
> 
> RFC Editor/lb
> 
> 
>> On Aug 24, 2023, at 9:53 AM, Kenneth Vaughn <[e-mail]> wrote:
>> 
>> Yeah, I went back and forth on this one. RFC 3413 does provide more information on SNMP applications, but RFC 3411 provides more context about the applications in relation to the architecture. In short, one could argue either way - and in either case it is a purely informative statement and not that critical, so I concluded that it was easiest to just accept the change.
>> 
>> However, my gut tends to agree with Joe that the paragraph is really talking about how we are adopting the 3411-defined architecture terminology rather than the details about the applications themselves. In that sense, I think the RFC3411 reference is more appropriate and recommend Joe's suggested text. 
>> 
>> Regards,
>> Ken Vaughn
>> 
>> Trevilon LLC
>> 1060 S Hwy 107
>> Del Rio, TN 37727
>> [phone] cell
>> [e-mail]
>> www.trevilon.com
> 
> 
>>> On Aug 24, 2023, at 5:40 AM, Joe Clarke (jclarke) <jclarke=[e-mail]> wrote:
>>> 
>>> 3) <!-- [rfced] Section 1.1:  It appears that RFC 3413 ("Simple Network
>>> Management Protocol (SNMP) Applications") should be cited here
>>> instead of RFC 3411 (which only mentions "SNMP applications" in
>>> passing in its text (Abstract, Section 3.1.1.2, and Section 4.1)).
>>> May we update as suggested?
>>> 
>>> Original:
>>> See
>>> "SNMP Applications" (RFC3411) for further information.
>>> 
>>> Suggested:
>>> See "Simple Network Management Protocol (SNMP) Applications"
>>> [RFC3413] for further information. -->
>>> Agreed, revise as suggested
>>> [JMC]: Hmmm, is that right.  I think RFC3411 is the right reference here based on my reading and when certain concepts and components are described (such as notification originator).  Shouldn’t the update here be to reflect the correct title of RFC3411.  That is:
>>> NEW:
>>> See “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks” [RFC3411]
>>> Joe
>> 
>> 
>>> On Aug 23, 2023, at 3:51 PM, Kenneth Vaughn <[e-mail]> wrote:
>>> 
>>> See responses below. Let me know if you have any additional questions.
>>> 
>>> Regards,
>>> Ken Vaughn
>>> 
>>> Trevilon LLC
>>> 1060 S Hwy 107
>>> Del Rio, TN 37727
>>> [phone] cell
>>> [e-mail]
>>> www.trevilon.com
>>> 
>>>> On Aug 17, 2023, at 5:29 PM, [e-mail] wrote:
>>>> 
>>>> Authors,
>>>> 
>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>> 
>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>>>> title) for use on <https://www.rfc-editor.org/search>. -->
>>> Agreed,
>>> 
>>> FRONT MATTER
>>> OLD
>>> 
>>> NEW
>>> Keywords: TLSTM, DTLS, security, SNMPv3, MIB
>>> 
>>>> 2) <!-- [rfced] Please review
>>>> <https://wiki.ietf.org/group/ops/mib-boilerplate>; it appears that
>>>> the section "The Internet-Standard Management Framework" is missing
>>>> from this document.  May we add this section as a new Section 1.1,
>>>> move "Conventions" to Section 1.2, and add RFC 3410 to the Normative
>>>> References section? -->
>>> Agreed
>>> 
>>> OLD
>>> 1.1. Conventions
>>> 
>>> NEW
>>> 
>>> 1.1 The Internet-Standard Management Framework
>>> 
>>> For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
>>>    • 
>>> Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
>>> 
>>> 1.2 Conventions
>>> 
>>>> 3) <!-- [rfced] Section 1.1:  It appears that RFC 3413 ("Simple Network
>>>> Management Protocol (SNMP) Applications") should be cited here
>>>> instead of RFC 3411 (which only mentions "SNMP applications" in
>>>> passing in its text (Abstract, Section 3.1.1.2, and Section 4.1)).
>>>> May we update as suggested?
>>>> 
>>>> Original:
>>>> See
>>>> "SNMP Applications" (RFC3411) for further information.
>>>> 
>>>> Suggested:
>>>> See "Simple Network Management Protocol (SNMP) Applications"
>>>> [RFC3413] for further information. -->
>>> Agreed, revise as suggested
>>> 
>>>> 4) <!-- [rfced] Section 2.1:  Please let us know if any changes are
>>>> needed for the following:
>>>> 
>>>> a) For ease of the reader, we added a citation for RFC 8446 here.
>>>> However, we could not verify that TLS 1.3 replaced the one-octet
>>>> hash algorithm identifier with a two-octet TLS 1.3 cipher suite
>>>> identifier.  Please let us know if this text should be clarified.
>>>> 
>>>> Original:
>>>> TLS 1.3 replaced the one-
>>>> octet hash algorithm identifier with a two-octet TLS 1.3 cipher suite
>>>> identifier.
>>>> 
>>>> Currently:
>>>> TLS 1.3 [RFC8446] replaced
>>>> the one-octet hash algorithm identifier with a two-octet TLS 1.3
>>>> cipher suite identifier.
>>> One could perhaps whether the one-octet identifier was "replaced" by the two-octet identifier; I suggest that we revise the text to be consistent with the note that is provided with the TLS HashAlgorithm table (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18)
>>> 
>>> NEW
>>> This one-octet algorithm identifier is only applicable to (D)TLS protocol versions prior to 1.3. 
>>> 
>>>> b) We could not find any instances of "fingerprint algorithm" in
>>>> RFC 6353.  Would the updates suggested below be helpful to readers?
>>>> 
>>>> Original:
>>>> [RFC6353] defines a fingerprint algorithm that references the one-
>>>> octet TLS 1.2 hash algorithm identifier.
>>>> ...
>>>> This document updates the definition of SnmpTLSFingerprint to clarify
>>>> that the one-octet identifier in the fingerprint algorithm uses the
>>>> IANA SNMP-TLSTM HashAlgorithm Registry; this registry is consistent
>>>> with the IANA TLS HashAlgorithm Registry for its initial values but
>>>> can be extended as needed to support new hashing algorithms without
>>>> implying that the new values can be used by TLS version 1.2.
>>>> 
>>>> Suggested (assuming that "one-octet algorithm identifier" is correct):
>>>> [RFC6353] defines a SnmpTLSFingerprint algorithm identifier that
>>>> references the one-octet TLS 1.2 hash algorithm identifier.
>>>> ...
>>>> This document updates the definition of SnmpTLSFingerprint to clarify
>>>> that the one-octet algorithm identifier uses the values in the IANA
>>>> "SNMP-TLSTM HashAlgorithm" registry; this registry is consistent
>>>> with the IANA "TLS HashAlgorithm" registry for its initial values
>>>> but can be extended as needed to support new hashing algorithms
>>>> without implying that the new values can be used by TLS version 1.2. -->
>>> The revision to the second paragraph is fine, but I find the firs more confusing. I suggest:
>>> 
>>> NEW
>>> [RFC6353] defines the SnmpTLSFingerprint textual convention to 
>>> include the one-octet TLS 1.2 hash algorithm identifier. 
>>> ...
>>> This document updates the definition of SnmpTLSFingerprint to clarify
>>> that the one-octet algorithm identifier uses the values in the IANA
>>> "SNMP-TLSTM HashAlgorithm" registry; this registry is consistent
>>> with the IANA "TLS HashAlgorithm" registry for its initial values
>>> but can be extended as needed to support new hashing algorithms
>>> without implying that the new values can be used by TLS version 1.2.
>>> 
>>>> 
>>>> 
>>>> 5) <!-- [rfced] Section 4:  We have been advised that MIB modules should
>>>> be self-contained.  We do not see any "REFERENCE" entries for
>>>> RFC 5246, RFC 5953, or RFC 6353.  May we update as suggested?
>>>> 
>>>> Original:
>>>> This module makes references to [RFC1123], RFC2578, RFC2579, RFC2580,
>>>> RFC3411, RFC3413, [RFC5246], [RFC5280], [RFC5890], [RFC5952],
>>>> [RFC5953], [RFC6353], and [STD58]
>>>> ...
>>>>       DESCRIPTION  "This version of this MIB module is part of
>>>>                     RFC 6353; see the RFC itself for full legal
>>>>                     notices.  The only change was to introduce
>>>>                     new wording to reflect require changes for
>>>>                     IDNA addresses in the SnmpTLSAddress TC."
>>>> 
>>>>       REVISION     "201005070000Z"
>>>>       DESCRIPTION  "This version of this MIB module is part of
>>>>                     RFC 5953; see the RFC itself for full legal
>>>>                     notices."
>>>>    ::= { mib-2 198 }
>>>> ...
>>>>       Historically, the 1-octet hashing algorithm identifier was
>>>>       based on the IANA TLS HashAlgorithm Registry (RFC 5246);
>>>>       however, this registry is no longer in use for TLS 1.3
>>>>       and above and are not expected to have any new registrations
>>>>       added to it. ...
>>>> 
>>>> Suggested:
>>>> This SNMP-TLS-TM-MIB module imports items from [RFC2578], [RFC2579],
>>>> [RFC2580], [RFC3411], and [RFC3413].  It also references [RFC1123],
>>>> [RFC5246], [RFC5280], [RFC5890], [RFC5952], [RFC5953], [RFC6353], and
>>>> [STD58].
>>>> ...
>>>>       DESCRIPTION
>>>>          "This version of this MIB module is part of
>>>>           RFC 6353; see the RFC itself for full legal
>>>>           notices.  The only change was to introduce
>>>>           new wording to reflect required changes for
>>>>           Internationalized Domain Names for Applications
>>>>           (IDNA) addresses in the SnmpTLSAddress
>>>>           textual convention (TC)."
>>>>       REFERENCE
>>>>         "RFC 6353: Transport Layer Security (TLS) Transport
>>>>                    Model for the Simple Network Management
>>>>                    Protocol (SNMP)"
>>>> 
>>>>       REVISION     "201005070000Z"
>>>>       DESCRIPTION
>>>>          "This version of this MIB module is part of
>>>>           RFC 5953; see the RFC itself for full legal
>>>>           notices."
>>>>       REFERENCE
>>>>         "RFC 5953: Transport Layer Security (TLS) Transport
>>>>                    Model for the Simple Network Management
>>>>                    Protocol (SNMP)"
>>>>    ::= { mib-2 198 }
>>>> ...
>>>>       Historically, the one-octet hashing algorithm identifier
>>>>       was based on the IANA 'TLS HashAlgorithm' registry
>>>>       (RFC 5246); however, this registry is no longer in use for
>>>>       TLS 1.3 and above and is not expected to have any new
>>>>       registrations added to it. ...
>>>>   REFERENCE
>>>>     "RFC 5246: The Transport Layer Security (TLS) Protocol
>>>>                Version 1.2" -->
>>> The MODULE-IDENTITY macro, as defined in RFC 2578 does not allow for a "REFERENCE" clause in a "Revision" entry. I have removed these from the suggested text; there does not seem to be a way to achieve what you are trying to do without violating RFC 2578.
>>> 
>>> RFC 2579 only allows one "REFERENCE" clause within the "ReferPart" of a textual convention and there is already a reference clause for SnmpTLSFingerprint. However, as the REFERENCE clause is free text, we could provide both references in the single field. If we only want to provide one reference, my preference would be to refer to the current table rather than a historic document.
>>> 
>>> The other suggested changes are fine.
>>> 
>>> NEW
>>> This SNMP-TLS-TM-MIB module imports items from [RFC2578], [RFC2579],
>>> [RFC2580], [RFC3411], and [RFC3413].  It also references [RFC1123],
>>> [RFC5246], [RFC5280], [RFC5890], [RFC5952], [RFC5953], [RFC6353], and
>>> [STD58].
>>> ...
>>>       DESCRIPTION
>>>          "This version of this MIB module is part of
>>>           RFC 6353; see the RFC itself for full legal
>>>           notices.  The only change was to introduce
>>>           new wording to reflect required changes for
>>>           Internationalized Domain Names for Applications
>>>           (IDNA) addresses in the SnmpTLSAddress
>>>           textual convention (TC)."
>>> 
>>>       REVISION     "201005070000Z"
>>>       DESCRIPTION
>>>          "This version of this MIB module is part of
>>>           RFC 5953; see the RFC itself for full legal
>>>           notices."
>>> 
>>>    ::= { mib-2 198 }
>>> ...
>>>       Historically, the one-octet hashing algorithm identifier
>>>       was based on the IANA 'TLS HashAlgorithm' registry
>>>       (RFC 5246); however, this registry is no longer in use for
>>>       TLS 1.3 and above and is not expected to have any new
>>>       registrations added to it. ...
>>>   REFERENCE
>>>     "RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2; 
>>>      https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.2.1.198.4" 
>>> 
>>> 
>>>> 6) <!-- [rfced] Section 4:  We could not find a relationship between
>>>> RFC 2579 and these two entries.  Please confirm that these citations
>>>> for RFC 2579 will be clear to readers.
>>>> 
>>>> Original:
>>>> snmpTLSTCPDomain OBJECT-IDENTITY
>>>>    STATUS      current
>>>>    DESCRIPTION
>>>>        "The SNMP over TLS via TCP transport domain.  The
>>>>        corresponding transport address is of type SnmpTLSAddress.
>>>> 
>>>>        The securityName prefix to be associated with the
>>>>        snmpTLSTCPDomain is 'tls'.  This prefix MAY be used by
>>>>        security models or other components to identify which secure
>>>>        transport infrastructure authenticated a securityName."
>>>>    REFERENCE
>>>>      "RFC 2579: Textual Conventions for SMIv2"
>>>>    ::= { snmpDomains 8 }
>>>> 
>>>> snmpDTLSUDPDomain OBJECT-IDENTITY
>>>>    STATUS      current
>>>>    DESCRIPTION
>>>>        "The SNMP over DTLS via UDP transport domain.  The
>>>>        corresponding transport address is of type SnmpTLSAddress.
>>>> 
>>>>        The securityName prefix to be associated with the
>>>>        snmpDTLSUDPDomain is 'dtls'.  This prefix MAY be used by
>>>>        security models or other components to identify which secure
>>>>        transport infrastructure authenticated a securityName."
>>>>    REFERENCE
>>>>      "RFC 2579: Textual Conventions for SMIv2"
>>>>    ::= { snmpDomains 9 } -->
>>> This is original text from RFC 6353, which is reasonable to clarify. Both of these OBJECT-IDENTITYs are identifiers that can vibe used as TDomain values.
>>> 
>>> NEW
>>> snmpTLSTCPDomain OBJECT-IDENTITY
>>>    STATUS      current
>>>    DESCRIPTION
>>>        "The OBJECT IDENTIFIER representing the TDomain for 
>>>        SNMP over TLS via TCP transport domain.  The
>>>        corresponding transport address is of type SnmpTLSAddress.
>>> 
>>>        The securityName prefix to be associated with the
>>>        snmpTLSTCPDomain is 'tls'.  This prefix MAY be used by
>>>        security models or other components to identify which secure
>>>        transport infrastructure authenticated a securityName."
>>>    REFERENCE
>>>      "TDomain, as defined in RFC 2579: Textual Conventions for SMIv2"
>>>    ::= { snmpDomains 8 }
>>> 
>>> snmpDTLSUDPDomain OBJECT-IDENTITY
>>>    STATUS      current
>>>    DESCRIPTION
>>>        "The OBJECT IDENTIFIER representing the TDomain for 
>>>        SNMP over DTLS via UDP transport domain.  The
>>>        corresponding transport address is of type SnmpTLSAddress.
>>> 
>>>        The securityName prefix to be associated with the
>>>        snmpDTLSUDPDomain is 'dtls'.  This prefix MAY be used by
>>>        security models or other components to identify which secure
>>>        transport infrastructure authenticated a securityName."
>>>    REFERENCE
>>>      "TDomain, as defined in RFC 2579: Textual Conventions for SMIv2"
>>>    ::= { snmpDomains 9 }
>>> 
>>>> 7) <!-- [rfced] Section 4:  Please review the following, and advise.
>>>> 
>>>> a) This sentence does not parse.  Does "both the" mean "both of the"
>>>> (in which case text for the second item is missing and we will need
>>>> you to provide it), or should the word "both" be removed (to make
>>>> clear that the model's support for transport prefixes is the only
>>>> concept mentioned in this sentence)?
>>>> 
>>>> Also, for ease of the reader, should RFC 5591 (SNMP-TSM-MIB) be added
>>>> to this document, perhaps (1) in the first paragraph of this section,
>>>> (2) as a reference entry after this description clause, and
>>>> (3) in the list of Informative References?
>>>> 
>>>> Original:
>>>> "... Using both the Transport Security Model's support for
>>>> transport prefixes (see the SNMP-TSM-MIB's
>>>> snmpTsmConfigurationUsePrefix object for details) will result
>>>> in securityName lengths that exceed what VACM can handle."
>>> Agreed, this is original text that is worth improving. It appears that the sentence was intended to explicitly state what the preceding sentence implies: i.e., that if you add a prefix onto the IPv6 string, it is longer than VAM can handle. I suggest rewording as follows:
>>> 
>>> NEW
>>> "... Using an IPv6 address while the value of 
>>> snmpTsmConfigurationUsePrefix is 'true' (see the SNMP-TSM-MIB, 
>>> as defined in RFC 559) will result in securityName lengths that exceed 
>>> what VACM can handle."
>>> 
>>>> b) Please confirm that "local part" (2 words, no hyphen) and
>>>> "host-part" (hyphenated) are both correct.  Would "localpart"
>>>> and "hostpart" be acceptable?
>>>> 
>>>> Original:
>>>> The
>>>> local part of the rfc822Name is passed unaltered but the
>>>> host-part of the name MUST be passed in lowercase.
>>> Agreed, this is original text that is worth improving. It appears that RFC 822 (and its current replacement RFC 5322) both use the names "local-name" and "domain" when formally defining the name format. I suggest the following:
>>> 
>>> NEW
>>> The local part of the rfc822Name is passed unaltered but the
>>> host-part of the name MUST be passed in lowercase.
>>> 
>>>> c) Should "certificate of the above types" be "certificates of the
>>>> above types"?
>>>> 
>>>> Original:
>>>> The first matching subjectAltName value found in the
>>>> certificate of the above types MUST be used when deriving the
>>>> tmSecurityName. The mapping algorithm
>>>> specified in the 'Algorithm' column MUST be used to
>>>> derive the tmSecurityName.
>>> 
>>> Agreed, this is original text that is worth improving. However, I believe the plurality is correct while the sentence structure is confusing. In other words, a single certificate could have multiple subjectAltNames, with multiple possible types. Implementations are required to use the first provided. I suggest rewording as follows:
>>> 
>>> NEW
>>> The first subjectAltName value contained in the certificate that 
>>> matches any of the above types MUST be used when deriving 
>>> the tmSecurityName.  The mapping algorithm specified in the 
>>> 'Algorithm' column of the corresponding row MUST be used to
>>> derive the tmSecurityName.
>>> 
>>>> d) This sentence does not parse.  Does "all child certificate's
>>>> subjectAltName to" mean "all child certificates' subjectAltName
>>>> fields to" or something else?
>>>> 
>>>> Original:
>>>> Users are encouraged to make use of certificates with
>>>> subjectAltName fields that can be used as tmSecurityNames so
>>>> that a single root CA certificate can allow all child
>>>> certificate's subjectAltName to map directly to a
>>>> tmSecurityName via a 1:1 transformation.
>>> Agreed, this is original text that is worth improving. I believe the author's intent is as follows:
>>> 
>>> NEW
>>> Users are encouraged to make use of certificates with
>>> subjectAltName fields that can be used as tmSecurityNames. 
>>> This allows all child certificates of a single root CA certificate 
>>> to include a subjectAltName that maps directly to a
>>> tmSecurityName via a 1:1 transformation.
>>> 
>>>> e) Does "mapping type that does not require data present in this
>>>> column" mean "mapping type that does not require that data be
>>>> present in this column", "mapping type that does not require data
>>>> that is present in this column", or something else?
>>>> 
>>>> Original:
>>>> "... The value in this
>>>> column MUST be ignored for any mapping type that does not
>>>> require data present in this column."
>>>> 
>>>> Perhaps A:
>>>> "... The value in this
>>>> column MUST be ignored for any mapping type that does not
>>>> require that data be present in this column."
>>>> 
>>>> Perhaps B:
>>>> "... The value in this
>>>> column MUST be ignored for any mapping type that does not
>>>> require data that is present in this column."-->
>>> Agreed, this is original text that is worth improving.
>>> 
>>> NEW
>>> "... The value in this
>>> column MUST be ignored for any mapping type that does not
>>> require that data be present in this column."
>>> 
>>>> 8) <!-- [rfced] Security Considerations:  It appears that, per the first
>>>> paragraph of this section, this document adequately follows the
>>>> guidelines provided on
>>>> <https://wiki.ietf.org/group/ops/mib-security>.  Please review and
>>>> confirm that no further changes are needed as related to the IETF
>>>> security guidelines for MIB documents. -->
>>> Agreed. I have reviewed the text and confirm that RFC 6353 already provides a detailed analysis of the vulnerabilities and no changes seem to be needed. 
>>> 
>>>> 9) <!-- [rfced] Section 6: IANA Considerations
>>>> 
>>>> a) [AD]:  We see that extensive updates have
>>>> been made to the IANA Considerations section between versions
>>>> -14 and -15.
>>>> 
>>>> Email from Ken dated 1 May 2023 (with PDF attached):
>>>> "Based on comments received during the implementation of the IANA
>>>> actions, we would like to edit the IANA Considerations section of
>>>> draft-ietf-opsawg-tlstm-update-14 according to the attached.
>>>> 
>>>> I am happy to upload a new version of the document, but I recognize
>>>> that it is in the editing queue and was advised to coordinate with
>>>> your efforts. Please let me know what I should do. (Note: I assume
>>>> the first couple of paragraphs will be deleted now that IANA has
>>>> completed their task)"
>>>> 
>>>> It appears that the decision was made later (8 May 2023) to upload
>>>> the updated version -15 to the Datatracker.  We assume that the
>>>> updates mentioned in Ken's 1 May email were all incorporated into
>>>> version -15.
>>>> 
>>>> Please review the updates to the IANA Considerations carefully, and
>>>> let us know if any further changes are needed.
>>>> 
>>>> Also, does IANA need to add anything on iana.org as related to the
>>>> version -15 updates?
>>> OLD
>>> A blank field indicates that no recommendation is made (e.g., 
>>> because the value is reserved or left for private use).
>>> 
>>> NEW
>>> A blank field indicates that no recommendation is made (e.g., 
>>> because the value is unassigned or left for private use).
>>> 
>>>> b) FYI, we will update this text once this action has been completed
>>>> by the secretariat. See mail from IANA sent on 8/14/2023. 
>>>> 
>>>> Original:
>>>>  IANA is
>>>>  also asked to either 1) create the <[e-mail]>
>>>>  email address that appears later in this section or 2) update the
>>>>  email address to an appropriate address.
>>> Agreed.
>>> 
>>>> 
>>>> c) As the "SNMP-TLSTM HashAlgorithm" registry
>>>> (https://www.iana.org/assignments/smi-numbers) lists multiple
>>>> algorithms, would you like the registry name to be pluralized, i.e.,
>>>> "SNMP-TLSTM HashAlgorithms"? If so, we will ask IANA to update this
>>>> registry title accordingly.
>>>> -->
>>> Yes, please. That would seem to more closely align with the existing conventions
>>> 
>>> 
>>>> 10) <!-- [rfced] Section 6:  Should "SHOULD not" be "SHOULD NOT" here, or
>>>> "should not"?  This was flagged by the Datatracker idnits script as
>>>> follows:
>>>> 
>>>> Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
>>>> or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
>>>> use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
>>>> mean).
>>>> 
>>>> Original:
>>>> Assignments that are inspecific (e.g.,
>>>> reserved values) SHOULD not receive an assigned value for the
>>>> recommended column. -->
>>> 
>>> NEW
>>> Assignments that are inspecific (e.g.,
>>> reserved values) SHOULD NOT receive an assigned value for the
>>> recommended column.
>>> 
>>>> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>>> online Style Guide at
>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>>>> and let us know if any changes are needed.
>>>> Note that our script did not flag any words in particular, but this
>>>> should still be reviewed as a best practice. -->
>>> I have reviewed the guidelines and am unaware of any issues in the document.
>>> 
>>>> 12) <!-- [rfced] Please let us know if any changes are needed for the
>>>> following:
>>>> 
>>>> a) The following terms were used inconsistently in this document.
>>>> We chose to use the latter forms.  Please let us know any objections.
>>>> 
>>>> 1-octet (DESCRIPTION clause for SnmpTLSFingerprint) /
>>>>  one-octet (elsewhere)
>>>> 
>>>> common name (1 instance) / CommonName (6 instances in text)
>>>> 
>>>> b) The following terms appear to be used inconsistently in this
>>>> document.  Please let us know which form is preferred.
>>>> 
>>>> host name (5 instances) / hostname (4 instances)
>>> RFC 5322 prefers "host name" so I think we should use that.
>>> 
>>>> 
>>>> [T][t]his textual convention (4 instances) /
>>>>  This TEXTUAL-CONVENTION (1 instance)
>>>>  (We also see "existing fingerprint TEXTUAL-CONVENTION" in
>>>>   Section 2.1.)
>>> Within text, it should be "textual convention" but of course when declaring an instance of the Macro in the MIB, it should be "TEXTUAL-CONVENTION"
>>> 
>>>> c) Column names were quoted in the original document in four of
>>>> approximately 22 instances (e.g., 'Algorithm' column,
>>>> snmpTlstmCertToTSNMapType column, "Recommended" column,
>>>> recommended column).  We added quotes throughout for consistency.
>>>> Please let us know if you would prefer that all quotes for column
>>>> names be removed.
>>> That is fine
>>> 
>>>> d) Would you like spacing to be consistent within this document for
>>>> the following?
>>>> 
>>>> Curly brackets (most have spaces around them):
>>>> 
>>>> {snmpTlstmConfig 1}
>>>> 
>>>> OBJECTS { snmpTlstmAddrServerFingerprint,
>>>>          snmpTlstmSessionInvalidServerCertificates}
>>>> 
>>>> "SIZE" entries:
>>>> (SIZE (1..255))
>>>> (SIZE (0..255))
>>>> (SIZE(1..255))
>>>> (SIZE(0..1024)) -->
>>> 
>>> Yes, consistency is good and does not affect the code.
>>> 
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor/lb/ap
>>>> 
>>>> 
>>>> On Aug 17, 2023, at 2:27 PM, [e-mail] wrote:
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2023/08/17
>>>> 
>>>> RFC Author(s):
>>>> --------------
>>>> 
>>>> Instructions for Completing AUTH48
>>>> 
>>>> Your document has now entered AUTH48.  Once it has been reviewed and 
>>>> approved by you and all coauthors, it will be published as an RFC.  
>>>> If an author is no longer available, there are several remedies 
>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>> 
>>>> You and you coauthors are responsible for engaging other parties 
>>>> (e.g., Contributors or Working Group) as necessary before providing 
>>>> your approval.
>>>> 
>>>> Planning your review 
>>>> ---------------------
>>>> 
>>>> Please review the following aspects of your document:
>>>> 
>>>> *  RFC Editor questions
>>>> 
>>>>  Please review and resolve any questions raised by the RFC Editor 
>>>>  that have been included in the XML file as comments marked as 
>>>>  follows:
>>>> 
>>>>  <!-- [rfced] ... -->
>>>> 
>>>>  These questions will also be sent in a subsequent email.
>>>> 
>>>> *  Changes submitted by coauthors 
>>>> 
>>>>  Please ensure that you review any changes submitted by your 
>>>>  coauthors.  We assume that if you do not speak up that you 
>>>>  agree to changes submitted by your coauthors.
>>>> 
>>>> *  Content 
>>>> 
>>>>  Please review the full content of the document, as this cannot 
>>>>  change once the RFC is published.  Please pay particular attention to:
>>>>  - IANA considerations updates (if applicable)
>>>>  - contact information
>>>>  - references
>>>> 
>>>> *  Copyright notices and legends
>>>> 
>>>>  Please review the copyright notice and legends as defined in
>>>>  RFC 5378 and the Trust Legal Provisions 
>>>>  (TLP – https://trustee.ietf.org/license-info/).
>>>> 
>>>> *  Semantic markup
>>>> 
>>>>  Please review the markup in the XML file to ensure that elements of  
>>>>  content are correctly tagged.  For example, ensure that <sourcecode> 
>>>>  and <artwork> are set correctly.  See details at 
>>>>  <https://authors.ietf.org/rfcxml-vocabulary>.
>>>> 
>>>> *  Formatted output
>>>> 
>>>>  Please review the PDF, HTML, and TXT files to ensure that the 
>>>>  formatted output, as generated from the markup in the XML file, is 
>>>>  reasonable.  Please note that the TXT will have formatting 
>>>>  limitations compared to the PDF and HTML.
>>>> 
>>>> 
>>>> Submitting changes
>>>> ------------------
>>>> 
>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>>> the parties CCed on this message need to see your changes. The parties 
>>>> include:
>>>> 
>>>>  *  your coauthors
>>>> 
>>>>  *  [e-mail] (the RPC team)
>>>> 
>>>>  *  other document participants, depending on the stream (e.g., 
>>>>     IETF Stream participants are your working group chairs, the 
>>>>     responsible ADs, and the document shepherd).
>>>> 
>>>>  *  [e-mail], which is a new archival mailing list 
>>>>     to preserve AUTH48 conversations; it is not an active discussion 
>>>>     list:
>>>> 
>>>>    *  More info:
>>>>       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>>> 
>>>>    *  The archive itself:
>>>>       https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>> 
>>>>    *  Note: If only absolutely necessary, you may temporarily opt out 
>>>>       of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>       If needed, please add a note at the top of the message that you 
>>>>       have dropped the address. When the discussion is concluded, 
>>>>       [e-mail] will be re-added to the CC list and 
>>>>       its addition will be noted at the top of the message. 
>>>> 
>>>> You may submit your changes in one of two ways:
>>>> 
>>>> An update to the provided XML file
>>>> — OR —
>>>> An explicit list of changes in this format
>>>> 
>>>> Section # (or indicate Global)
>>>> 
>>>> OLD:
>>>> old text
>>>> 
>>>> NEW:
>>>> new text
>>>> 
>>>> You do not need to reply with both an updated XML file and an explicit 
>>>> list of changes, as either form is sufficient.
>>>> 
>>>> We will ask a stream manager to review and approve any changes that seem
>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>>> and technical changes.  Information about stream managers can be found in 
>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>>> 
>>>> 
>>>> Approving for publication
>>>> --------------------------
>>>> 
>>>> To approve your RFC for publication, please reply to this email stating
>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>>>> as all the parties CCed on this message need to see your approval.
>>>> 
>>>> 
>>>> Files 
>>>> -----
>>>> 
>>>> The files are available here:
>>>>  https://www.rfc-editor.org/authors/rfc9456.xml
>>>>  https://www.rfc-editor.org/authors/rfc9456.html
>>>>  https://www.rfc-editor.org/authors/rfc9456.pdf
>>>>  https://www.rfc-editor.org/authors/rfc9456.txt
>>>> 
>>>> Diff file of the text:
>>>>  https://www.rfc-editor.org/authors/rfc9456-diff.html
>>>>  https://www.rfc-editor.org/authors/rfc9456-rfcdiff.html (side by side)
>>>> 
>>>> Diff of the XML: 
>>>>  https://www.rfc-editor.org/authors/rfc9456-xmldiff1.html
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>>  https://www.rfc-editor.org/auth48/rfc9456
>>>> 
>>>> Please let us know if you have any questions.  
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9456 (draft-ietf-opsawg-tlstm-update-15)
>>>> 
>>>> Title            : Updates to the TLS Transport Model for SNMP
>>>> Author(s)        : K. Vaughn, Ed.
>>>> WG Chair(s)      : Henk Birkholz, Joe Clarke, Tianran Zhou
>>>> Area Director(s) : Warren Kumari, Robert Wilton
>>>> 
>>>> 
>>> 
>> 
>