--On Thursday, May 9, 2019 17:17 -0500 Adam Roach
<adam@xxxxxxxxxxx> wrote:
> On 5/9/19 5:14 PM, John C Klensin wrote:
>> Fine plan, except that it would deceive the reader
>> about the state of the (new) specification and would violate
>> our long-standing rule against publishing standards-track
>> specifications that contain known technical defects.
>
>
> That's why section 3.3 is, in my opinion, critical. Maybe not
> in its current formulation, but (IMHO) something along those
> lines is necessary to make this work even a little bit.
Agreed. But, if that section is the solution, it almost
certainly needs work. In particular, there is the well-known
tendency of people to glance through RFCs (and other technical
specs) looking for answers rather than reading them carefully
from beginning to end (especially likely if the current document
replaces, and largely duplicate, a previous RFC on the same
subject). Given that, and regardless of what the Introduction
and/or Appendices say, the sections that are known to be
problematic should probably have individual, in-line, text that
calls out the problem and/or indicates (by reference if needed)
why they should not be taken seriously as written.
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.
john
