On Fri, May 10, 2019, at 08:55, Adam Roach wrote: > On 5/9/19 5:25 PM, John C Klensin wrote: > > Leaving the reader with "Some [unspecified] portions of the text > > have not been updated and do not meet current best practices for > > documents published by the IETF", even if combined with > > detailing each specific technique... that would not generally be > > acceptable", just does not come up to the standard I think we > > hope for in IETF technical specification RFCs. Let me make a supposition: a big part of why people don't attempt to update documents is that they are scared of having to deal with problems unrelated to the one they are fixing. And another one: a lot of RFCs contain problems worth fixing, some of which we all agree on, and some that are in John's third category of skeletons in the closet. Adam proposes that we allow people to fix the fixable problems, but we need to agree on what to do with the skeletons. We have a range of options along this continuum: a/ stick a notice on the doc saying that there might be skeletons anywhere other than the updated stuff b/ signpost all the skeletons we know about c/ fix all the skeletons We've been doing c/ for a while and being shackled to that has meant that we get horrible "patch" RFCs or no updates at all. Adam quoted an earlier mail where I advocated for a/, but I later suggested that the draft not REQUIRE putting little sticky notes on all the skeletons, but to encourage that. That's for two reasons. To remove the disincentive associated with having to perform the analysis, and the disincentives arising from discussion about the content of the list. For larger documents, it's possible that collecting the list of shortcomings could be a fairly significant task. And as for getting consensus on a list... I'm currently watching the TLS WG do its usual thing at the moment, and aside from the usual anger and despair that is evoked by that sort of discussion, I am reminded that we don't always have consensus about whether the skeleton even exists. So that's why I suggested a slightly weaker version of what Adam proposes. That way, if someone volunteers to do us a service by fixing our protocol, we don't reward them by giving them another, harder task.
