Re: Last Call: Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic

[John C Klensin <[e-mail]>]

--On Saturday, 12 May, 2018 19:06 -0400 John Levine
<[e-mail]> wrote:

> In article <[e-mail]>
> 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