Hiya, I'm the sponsoring AD for this. I had some non-blocking comments that I'd like to be considered with other IETF last call comments. S. - I still find the phrase "TLS feature extension" confusing given section 1.2. - section 2, 3rd last para: I think this SHOULD NOT is broken, how (in general) can a CA check/know that it's true and that it will continue to be true? - 3.1, para 1 could do with a forward pointer to the relevant bit of IANA considerations. - 3.1, 2nd last para, last sentence: I'm not sure I get the sentence's meaning - it has two MAY statements and a double negative. I bet a re-phrase (as a positive statement) or breaking into two boring sentences could be a lot simpler. - 3.2.2: I wonder if this is really a good idea. (Still) - 3.2.3: and elsewhere: What exactly does "reject the TLS configuration" mean? I think you mean the cert and/or handshake? (And those might differ e.g. with http opp-sec.) If you need this term, why not define it at the top? - 3.2.3.1: you could add a reference to RFC7435 at the end there to justify the MUST NOT. - 3.3.3: 1st para ends without a "." - 3.3.3: I think the "treat as bad cert" model is ok, but I do wonder if that's been fully thought through - would it maybe be better to treat the bad case as a handshake failure? - 5.1: the section title isn't great, maybe "Bad Certificates" would be better? - 5.x: I think you could add a risk that we're adding a new way to brick your site a bit, either via certificate update or (less likely) s/w update (say if a server deprecates a feature).