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

[Kenneth Vaughn <[e-mail]>]

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 <https://datatracker.ietf.org/doc/rfc3410/> [RFC3410 <https://datatracker.ietf.org/doc/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 <https://datatracker.ietf.org/doc/rfc2578/> [RFC2578 <https://datatracker.ietf.org/doc/rfc2578/>], STD 58, RFC 2579 <https://datatracker.ietf.org/doc/rfc2579/> [RFC2579 <https://datatracker.ietf.org/doc/rfc2579/>] and STD 58, RFC 2580 <https://datatracker.ietf.org/doc/rfc2580/> [RFC2580 <https://datatracker.ietf.org/doc/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 <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
> 
>