On Thu, Jul 2, 2026 at 4:11 PM tojens.ietf <[email protected]> wrote:
> To your specific point about =N being the default: that makes sense to me > as an IETF process, but I'm not convinced this is so obvious to someone > reading the registry, especially the nuance about pre and post 9847 values > having different implications. > I see this as a failure of the registry text itself not being sufficiently clear. The current IANA TLS registry page [0] has this wording at the start of every table with a Recommended column: > Note: > If the "Recommended" column is set to "N", it does not necessarily > mean that it is flawed; rather, it indicates that the item either > has not been through the IETF consensus process, has limited > applicability, or is intended only for specific use cases. If the > "Recommended" column is set to "D," the item is discouraged and > SHOULD NOT or MUST NOT be used, depending upon the situation; > consult the item's references for clarity. The second sentence is adapted from RFC 9847 Section 3: > D: Indicates that the item is discouraged. This marking could be > used to identify mechanisms that might result in problems if they > are used, such as a weak cryptographic algorithm or a mechanism > that might cause interoperability problems in deployment. When > marking a registry entry as "D", either the "Reference" or the > "Comment" column MUST include sufficient information to determine > why the marking has been applied. Implementers and users SHOULD > consult the linked references associated with the item to > determine the conditions under which the item SHOULD NOT or MUST > NOT be used. However, the first sentence was clearly left at its original adaption from RFC 8447 Section 5 [1] (which added the column in the first place): > If an item is not marked as "Recommended" (i.e., "N"), it does not > necessarily mean that it is flawed; rather, it indicates that the > item either has not been through the IETF consensus process, has > limited applicability, or is intended only for specific use cases. If we compare this to the updated definition in RFC 9847 Section 3 [2]: > N: Indicates that the item has not been evaluated by the IETF and > that the IETF has made no statement about the suitability of the > associated mechanism. This does not necessarily mean that the > mechanism is flawed, only that no consensus exists. The IETF might > have consensus to leave an item marked as "N" on the basis of the > item having limited applicability or usage constraints. > > [...] Any item not otherwise specified is set to "N". [...] we see that the IANA registry page is missing the additional context of "made no statement", as well as the original context (which this preserved) from RFC 8447 about N being the default (which described adding a Recommended parameter as a Standards Action, and "not marked as Recommended" as the non-Standards Action default state). The IANA registry *does* separately say for each table that setting Recommended = N is only Specification Required (vs Standards Action or IESG Approval for all other transitions), but doing so separately from the context Note doesn't make the intent from either RFC 8447 or 9847 particularly clear. Interestingly, this choice of wording was made in RFC 9847 itself [3], which strongly implies the intention of that RFC was to *add* the D state, not to *change* the meaning of the N state (at most some state space from N is carved off into D, but otherwise N has always been the default). Cheers, Jack [0] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml [1] https://datatracker.ietf.org/doc/html/rfc8447#section-5 [2] https://datatracker.ietf.org/doc/html/rfc9847#name-updating-recommended-column [3] https://datatracker.ietf.org/doc/html/rfc9847#name-recommended-note
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
