On 03/30/2016 01:03 PM, Sean Turner wrote: > I apologize in advance; this is about process so it’s long. >
It seems correct and reasonably comprehensive. > This definition gives power/discretion to the designated expert (it’s ekr > btw). We can: > > a) defer to the expert's judgement (some of what they are to do is in > [1][2]), or > b) write some rules for the IANA considerations section that they’ll follow. > > I think that a) has worked in the past and would continue to work in the > future, but b) couldn’t hurt. If we go for a) then if the expert is ever > unsure, they can just ask the AD/WG chair/community for guidance [3][4]. > Beware that the text for b) will be like a bright light for process moths [5]. > I feel like (b) will probably result in a lot of time on the list getting the text "just so"; perhaps that time would be better spent elsewhere. That said, I'm happy to help with the editing of such text... > > > Some other things we should be clear on: > > 1. All of the drafts referenced and the future drafts requesting code points > do *not* need to come through the WG. But, I do think drafts that want a “Y” > need to come through, and we shouldn’t kid ourselves most folks will want the > “Y”. How does this sound (here I assume the algorithms are already published > elsewhere i.e., this is just for the assignments): I agree ... the chairs should use their power to turn things away judiciously :) > a) For MTI and “Y” requests, > a.1) requester’s publish individual draft, > a.2) requester’s ask for wg adoption, > a.3) wg chairs do adoption call, > a.4) wg does its thing on wg draft, > a.5) ietf does its thing, and > a.6) iana (assigns #s) & rfc editor (publishes) do their things. > > b) For all others: > b.1) request is submitted to IANA, WG, WG chair, AD, That's "one of the above", I presume? > b.2) request is redirected to designated expert, > b.3) designated experts reviews request: > -- if good-to-go designated expert tells IANA to assign code point (goto b.4) > -- if not-good-to-go for an obvious reasons the designated expert rejects the > request with some rationale (and probably lets the sec ADs know about it) > -- if not-good-to-go for all other reasons the designated expert asks > (expert's choice depending on the situation) AD/WG chairs/community for > guidance > b.4) iana makes assignment and includes the cipher suite assignment > specification reference in the registry (and possibly the rfc editor does > their thing if an RFC is being published) > > Early assignment rules can still apply to a) and b). Sounds good to me. > 2. As far as draft-ietf-tls-pwd, we need to decide whether it should continue > as a WG draft or free Dan to pursue other publication avenues. No opinion at present. > 3. We should avoid a long list of “updates” to TLS1.3 RFC#-to-be when new > cipher suites get added. Drafts should only include an “updates” header if > we’re modifying the MTIs or we’re adding a new “Y” cipher suite because we > only expect all implementations to support these cases. I support this, yes -- long "updates" lists can be annoying for the reader. > 4. WRT language - I’m assuming we’d continue to have English versions of the > algorithm specification. > If we are using IANA as a service for the global Internet, it is not entirely clear to me that we need to insist on English versions of the "specification required" document ... though the capabilities of the designated expert might affect what would in practice get approved. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
