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

[[e-mail]]

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>. -->


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? -->


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. -->


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.

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. -->


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" -->


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 } -->


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."

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.

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.

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.

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."-->


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. -->


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?

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.

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.
-->


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. -->


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. -->


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)

 [T][t]his textual convention (4 instances) /
   This TEXTUAL-CONVENTION (1 instance)
   (We also see "existing fingerprint TEXTUAL-CONVENTION" in
    Section 2.1.)

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.

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)) -->


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