--On Saturday, 12 May, 2018 19:06 -0400 John Levine <johnl@xxxxxxxxx> wrote: > In article <7FEC3265-C38B-4BB0-91C4-4F6990D00DA4@xxxxxxxxx> > you write: >> I would sure rather the justification were published as an >> RFC so people can find the reasons in the future > > It's in RFC 6686, in the unlikely event that someone who cares > didn't already know the answer. Yeah, but, knowing that, my version of Scott's comment would have been only slightly different. (Almost) too late now, but why wasn't this action taken as part of adopting 6686 and documented there? If that was an inadvertent omission, should our review process (Last Call, Shepherd writeups, etc.) be modified to lower the odds of future such omissions? Either way, when this action occurs, should it be noted as an omission/ erratum on 6686 to improve the relevant threading. Personally, I'd much prefer to see these things described in the RFC Series rather than assuming people will look at the datatracker to find relevant information. We at least used to believe that RFC numbers were cheap, a lot cheaper than losing important information or hiding it in obscure places Part of the reason for that is that the RFC Series is archival, existed before the IETF, and is likely to continue to exist in some form even after the IETF fades into history. I have no such confidence about the datatracker. Consequently, I'd rather see a one-page RFC that says what the proposed tracker note says and that points to (and updates) 6686, rather than just the tracker note. But I (and Scott) seem to have lost that argument to a series of IESG statements with some apparent ex cathedra character to them. john
