Andrew Sullivan wrote:
>
> Martin Rex wrote:
>>
>> Viktor's submitted errata is both important and valuable.
>
> That may well be, but I don't think it's an erratum. It's a
> substantive change.
Huh?
The additonal clarification _neither_ changes the DANE protocol,
_nor_ does it change the TLS protocol. So it is merely a
technical clarification, but *NO* (technical) change!
However, this errata is extremely important information for an implementor
of a DANE client
- for knowing which location to typically search for a potential
match to the info from the TLSA record
- what error message and suggestion to produce when the necessary
certificate is not present in a handshake,
- what kind of configuration interfaces will be necessary for
the typical DANE client
- what to write into the documentation of the DANE client
or the documentation of the APP that contains the DANE client.
(example configurations and pitfalls).
Viktor's submitted errate is a brief and accurate description
of vital information that is missing in rfc6658.
With the current guidance in rfc2026 about the to-be-expected defects
of documents at Proposed Standard maturity level, and the existing
guidance about Erratas from RFC Editor and IESG, and the lack of
any alternative mechanism to add missing clarifications to a published RFC,
Viktor's approach is currently the one and only that is documented,
and it is an extremely reasonable solution.
-Martin
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
