Skip to content

Commit a798f82

Browse files
author
ietf-corpus-bot
committed
auto-ingest: ietf-elements backfill — 209 new elements (2026-05-22)
1 parent 3f273df commit a798f82

209 files changed

Lines changed: 1967 additions & 0 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎corpus/elements/rfc-6353__design-rationale-the-d-tls-internal-sessionid-is-not-used.yaml‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-6353
2+
kind: design-rationale
3+
summary: The (D)TLS internal SessionID is not used as the tlstmSessionID because it can change during renegotiation and does not necessarily uniquely identify a TLSTM session — multiple TLSTM sessions can share the same D(TLS) internal SessionID. A stable, unique TLSTM-level identifier is therefore required.
4+
section: 3.1.3
5+
topics:
6+
- snmp
7+
- tls
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__design-rationale-the-subjectaltname-certificate-field-is-the-preferred-source.yaml‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
document: rfc-6353
2+
kind: design-rationale
3+
summary: The subjectAltName certificate field is the preferred source for deriving tmSecurityNames; the CommonName mapping (snmpTlstmCertCommonName) is deprecated. Deployments SHOULD use subjectAltName because it provides structured, unambiguous identity information compared to the free-form CommonName field.
4+
section: 4.1.1
5+
topics:
6+
- snmp
7+
- tls
8+
- pkix
9+
extracted_by: claude-sonnet-4-6
10+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__interoperability-note-vacm-constrains-securityname-to-32-octets-a-tlstm.yaml‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-6353
2+
kind: interoperability-note
3+
summary: VACM constrains securityName to 32 octets. A TLSTM tmSecurityName derived from an IPv6 address (32 hex chars) combined with the TSM transport prefix yields a 36-octet securityName that exceeds VACM's limit. Operators must select algorithms and subjectAltNames carefully to avoid this incompatibility.
4+
section: 4.1.1
5+
topics:
6+
- snmp
7+
- tls
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__normative-requirement-a-tls-transport-model-implementation-must-support-message.yaml‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
document: rfc-6353
2+
kind: normative-requirement
3+
summary: A TLS Transport Model implementation MUST support message encryption to protect sensitive data from eavesdropping. The NULL integrity and encryption algorithms MUST NOT be used to fulfill security level requests for authentication or privacy.
4+
section: 3.1.2
5+
rfc2119_level: MUST NOT
6+
topics:
7+
- snmp
8+
- tls
9+
- security
10+
- crypto
11+
extracted_by: claude-sonnet-4-6
12+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__normative-requirement-a-tls-transport-model-implementation-must-support-the.yaml‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
document: rfc-6353
2+
kind: normative-requirement
3+
summary: A TLS Transport Model implementation MUST support the authentication of both the server and the client using X.509 certificates. Trusted public keys from CA certificates and/or self-signed certificates MUST be installed through a trusted out-of-band mechanism and their authenticity MUST be verified before access is granted.
4+
section: 3.1.1
5+
rfc2119_level: MUST
6+
topics:
7+
- snmp
8+
- tls
9+
- pkix
10+
- security
11+
extracted_by: claude-sonnet-4-6
12+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__normative-requirement-d-tls-must-negotiate-a-cipher-suite-that.yaml‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
document: rfc-6353
2+
kind: normative-requirement
3+
summary: (D)TLS MUST negotiate a cipher_suite that uses X.509 certificates for authentication and MUST authenticate both the client and the server. The mandatory-to-implement cipher_suite is specified in the TLS specification (RFC 5246).
4+
section: "4.2"
5+
rfc2119_level: MUST
6+
topics:
7+
- snmp
8+
- tls
9+
- pkix
10+
- crypto
11+
extracted_by: claude-sonnet-4-6
12+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__normative-requirement-for-dtls-over-udp-each-snmp-message-must.yaml‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
document: rfc-6353
2+
kind: normative-requirement
3+
summary: For DTLS over UDP, each SNMP message MUST be placed in a single UDP datagram, though it MAY be split into multiple DTLS records. The TLSTM implementation SHOULD return an error if the SNMP message does not fit in the UDP datagram.
4+
section: "4.2"
5+
rfc2119_level: MUST
6+
topics:
7+
- snmp
8+
- tls
9+
- udp
10+
extracted_by: claude-sonnet-4-6
11+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__normative-requirement-for-dtls-over-udp-the-dtls-server-implementation.yaml‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
document: rfc-6353
2+
kind: normative-requirement
3+
summary: For DTLS over UDP, the DTLS server implementation MUST support DTLS cookies. Enabling the cookie exchange by default is RECOMMENDED, though implementations are not required to perform it for every handshake.
4+
section: "4.2"
5+
rfc2119_level: MUST
6+
topics:
7+
- snmp
8+
- tls
9+
- udp
10+
- security
11+
extracted_by: claude-sonnet-4-6
12+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__normative-requirement-for-dtls-replay-protection-must-be-used.yaml‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
document: rfc-6353
2+
kind: normative-requirement
3+
summary: For DTLS, replay protection MUST be used.
4+
section: "4.2"
5+
rfc2119_level: MUST
6+
topics:
7+
- snmp
8+
- tls
9+
- security
10+
extracted_by: claude-sonnet-4-6
11+
extracted_at: "2026-05-22"

‎corpus/elements/rfc-6353__normative-requirement-the-d-tls-client-must-verify-the-server.yaml‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
document: rfc-6353
2+
kind: normative-requirement
3+
summary: The (D)TLS client MUST verify the server's presented certificate and MUST NOT transmit SNMP messages until the server certificate has been authenticated, the client certificate has been transmitted, and the TLS connection has been fully established. Session establishment MUST fail if certificate verification fails in any way.
4+
section: 5.3.1
5+
rfc2119_level: MUST
6+
topics:
7+
- snmp
8+
- tls
9+
- pkix
10+
- security
11+
extracted_by: claude-sonnet-4-6
12+
extracted_at: "2026-05-22"

0 commit comments

Comments
 (0)