Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates

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.farrell@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.farrell@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