Funny I never thought about going down, but I guess we should ;) I think the premise we want here is hard to get a Yes (whether new or upgrade) and somewhat easier than that to go down but it can’t be done in the dark so 4 would work. This kind of works out because people are motivated to get ciphers specified, but very much less so to de-specify them.
spt > On Nov 21, 2017, at 18:54, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > > On 21/11/17 23:39, Martin Thomson wrote: >> IESG action seems appropriate for both. > > I'm fairly sure the WG discussed the No->Yes (or new Yes) > before and wanted standards action for that. I'd guess > that changing that might take some discussion. (FWIW, I'd > not support that change myself but maybe others would.) > > If the No->Yes stuff doesn't change I'll take you as > arguing for a (4) below but correct me if that's wrong. > > Cheers, > S. > >> If we could include guidance >> around this (values with Yes should only include those for which the >> community currently has consensus are worth having available at the >> current time), tat would be awesom> >> On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell >> <stephen.farr...@cs.tcd.ie> wrote: >>> >>> Hiya, >>> >>> I just posted a draft shepherd write-up for this [1]. (The >>> write-up text was mostly written by Sean as it happens - for >>> which he has my thanks as it's boring as hell to do that:-) >>> >>> There are nits but only one substantive question that I don't >>> recall the WG discussing before (but maybe I'm forgetting). >>> >>> What is needed to change from Recommended == Yes down to >>> Recommended == No? Does that need a standards action (e.g. >>> with an RFC) or just IETF review or even maybe just IESG >>> action? >>> >>> In the current draft write-up I've put in the first as a >>> placeholder, as that's symmetric with the No->Yes change but >>> I think IESG action is probably ok if the WG wanted that as >>> the IESG probably won't go crazy and will likely do as the >>> WG want in such cases. If the WG do want to write a specific >>> foo-no-longer-recommended RFC it can do that in all cases, >>> and of course Yes->No transitions could be documented in an >>> RFC that documents a "replacement" Yes entry. >>> >>> So, unless this was already discussed....answers on a postcard >>> please - which'd we like: >>> >>> (1) say nothing (as in -02 draft) >>> (2) say standards action is required for a Yes->No transition >>> (3) say IETF review (i.e. an IETF last call) is required for a >>> Yes->No transition >>> (4) say IESG action is required for a Yes->No transition >>> (5) something else >>> >>> And as a reminder the Recommended column is not about crypto >>> quality but is about things for which we have consensus that >>> they ought be widely implemented and available at the current >>> point in time. Those are related things but Recommended == No >>> does not imply crap-crypto even if crap-crypto will hopefully >>> imply Recommended == No. >>> >>> If nobody says anything I'll chat with Kathleen, Sean and Joe >>> and we'll pick a thing and that'll doubtless be quibbled about >>> during directorate reviews and IESG processing as these things >>> always are;-) >>> >>> But since I'd hope implementers will care about keeping up to >>> date with the set of Recommended == Yes things, I do hope that >>> folks are willing to express a preference here. >>> >>> Cheers, >>> S. >>> >>> [1] >>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/ >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
