Adam, Understood and appreciated without, as you say, necessarily agreeing. I'll think about this further, but one observation in the interim: I draw a fairly large distinction between "we have discovered some issues with this and it might not work as expected and/or not represent current best practice" (which is where I see Martin's comments focusing, but I may still not understand his point of view) and "we have come to understand this feature better and it definitely will not work as expected in some list of cases we also understand" (whether those cases are enumerated or not). The latter is a known "unresolved design choice" and/or "known technical omission" as those terms are used in RFC 2026. 2026 allows the IESG to waive the "no known technical omissions" requirement, but, as I have read that text in the last 22+ years doing so far a document that is replacing another one and without addressing that omission would put the IESG and authors on rather thin ice if there were not a very clear and explicit justification. Of course, one could modify/update 2026 to match the intent of this I-D, but I assume that would be considered a much more major step. best, john --On Thursday, May 9, 2019 17:54 -0500 Adam Roach <adam@xxxxxxxxxxx> 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. > > I understand and have some sympathy for your position, but I > don't necessarily agree with it. > > Given Martin's related feedback at > <https://mailarchive.ietf.org/arch/msg/ietf/3FUqzIyiYo82AFgBaj > y55eBz2kU>: > >> I would instead suggest that rather than requiring >> enumeration of all the "icky bits", we instead label what is >> updated and say that "everything else is left as is and might >> not reflect current best practice". > ...I would curious what conclusion the two of you might reach > if you decided to spend significant face-to-face time > discussing the topic. > > I'll note that I similarly have some sympathy for (but also > don't necessarily agree with) Martin's position, and offered > the current proposal as a compromise between the two > countervailing concerns that you have respectively brought > forth. > > /a >
