RFC Errata
Found 2 records.
Status: Rejected (2)
RFC 9460, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", November 2023
Source of RFC: dnsop (ops)
Errata ID: 7871
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Shulhan
Date Reported: 2024-03-25
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2024-04-16
Section D.2 says:
example.com. SVCB 1 foo.example.com. key667="hello\210qoo" \# 32 ( 00 01 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 02 9b ; key 667 00 09 ; length 9 68 65 6c 6c 6f d2 71 6f 6f ; value ) \x00\x01 # priority \x03foo\x07example\x03com\x00 # target \x02\x9b # key 667 \x00\x09 # length 9 hello\xd2qoo # value
It should say:
example.com. SVCB 1 foo.example.com. key667="hello\210qoo" \# 32 ( 00 01 ; priority 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 02 9b ; key 667 00 09 ; length 9 68 65 6c 6c 6f 88 71 6f 6f ; value ) \x00\x01 # priority \x03foo\x07example\x03com\x00 # target \x02\x9b # key 667 \x00\x09 # length 9 hello\x88qoo # value
Notes:
Original report:
The escaped octal number "\210" when encoded to hexadecimal should be "88" or "\x88", NOT "d2" or "\xd2".
The "d2" or "\xd2" is hexadecimal value for decimal number "210".
WK Edit: I am rejecting this Errata -- the display format (key667="hello\210qoo") is encoded using the DNS RFC1035 syntax, which specifies:
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD.
This is, um, surprising to many, and a relatively common source of issues in the DNS parsing world.
I encourage future updates of the RFC to include a "footnote" / parenthetical pointing this out...
--VERIFIER NOTES--
I am rejecting this Errata -- the display format (key667="hello\210qoo") is encoded using the DNS RFC1035 syntax, which specifies:
\DDD where each D is a digit is the octet corresponding to
the decimal number described by DDD.
This is, um, surprising to many, and a relatively common source of issues in the DNS parsing world.
I encourage future updates of the RFC to include a "footnote" / parenthetical pointing this out...
Errata ID: 8168
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Julian Keck
Date Reported: 2024-11-04
Rejected by: Warren Kumari (Ops AD)
Date Rejected: 2024-12-02
Section 2.3 says:
This record would indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net". The owner of "example.net", in turn, could publish this record: svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( alpn="bar" port="8004" ) This record would indicate that these services are served on port number 8004, which supports the protocol "bar" and its associated transport in addition to the default transport protocol for "foo://".
It should say:
This record would indicate that "foo://api.example.com:8443" is aliased to "svc4.example.net". The owner of "example.net", in turn, could publish this record: svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( alpn="bar" port=8004 ) This record would indicate that these services are served on port number 8004, which supports the protocol "bar" and its associated transport in addition to the default transport protocol for "foo://".
Notes:
As far as I understand the rest of the RFC as well as the other examples provided, the port must not be quoted as stated in 7.2 ("port"):
The presentation value of the SvcParamValue is a single decimal integer between 0 and 65535 in ASCII.
[WK: Rejecting this errata with a note from the DNSOP list: https://mailarchive.ietf.org/arch/msg/dnsop/BHLZtTaDLiHcMWe2NDnl_HJ0RwM/
Text:
"This report is incorrect. SvcParamValues always are presented via a char-string encoding as defined in Appendix A, so quotes are always allowed. The "single decimal integer" applies to the "value" which is derived by reversing the escaping of the char-string, producing a *OCTET in ABNF.
Thanks for the close read!
Ben Schwartz"
--VERIFIER NOTES--
Thank you for the Errata report.
I'm rejecting it as per: https://mailarchive.ietf.org/arch/msg/dnsop/BHLZtTaDLiHcMWe2NDnl_HJ0RwM/
Thanks again,
Warren (Ops AD)