Re: RFC 8252 [Process and reviews]

[Michael Thomas <mike@xxxxxxxx>]

On 7/14/23 2:49 AM, Rob Wilton (rwilton) wrote:

But I think that we need to be careful about changing (in particular adding) new process to the IETF publication pipeline.  I think that I’ve seen various cases, where some flaw with the processing of an RFC happened in the past, and hence someone goes to the effort of updating the process, nominally to ensure that a similar mistake can never happen again.  What sometimes happens is that new step or rule in the process has unexpected and unintended side-effects that causes extra process hoops to be jumped through for no real benefit. I.e., the negatives of the extra step greatly outweigh the benefits that it brings in a small number of cases.

    I'm not proposing any changes to process. I'm just asking for some
    accountability for how this happened. It's hard to change anything
    when you don't know why it happened in the first place, after all.

Instead, I think that it is more pragmatic to try and ensure that the IETF publication process is light enough and works well for 95+% of documents, and to handle the odd exceptional case as an exception, and also accept that occasionally the IETF will end up publishing documents that in hindsight have flaws or would have been better not to publish, and that is okay, since we can always publish a new RFC to undo the mistake.  I don’t know whether RFC 8252 fits into the category or not, but I agree with Chris that discussing that aspect on this list is unlikely to be constructive or useful.  To get anything to change needs the discussion to happen within the security area lists, probably by bringing a draft, as explained previously.

In the mean time one of the chairs of the OAUTH wg invited me to their bi-weekly telechat after the IETF meeting so we'll see what happens. I had hoped that the AD's involved might chime in, but didn't really want to invoke them directly.

Mike