Re: [Rfcplusplus] draft-klensin-rfcplusplus-alternatives-00

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

--On Saturday, July 14, 2018 13:53 -0400 "Andrew G. Malis"
<[e-mail]> wrote:

> John,
> 
> Thanks, I just read the draft. It's a nice enumeration of
> possible solutions assuming the IETF agrees that there's a
> problem. Given that whatever solutoin is chosen is intended to
> be a limited-time experiement, each of the solutions should
> include the way to back out of it at the conclusion of the
> experiment, and also criteria to detemine whether or not the
> experiment was a succsss or failure. If backing out is
> impossible, that should be mentioned (as you did in sections 2
> and 6).

Andy,

Thanks for the kind words.  Agreed about back out strategies.
>From my point of view, there are three elements to a decision to
actually do anything here:

(1) Determining that there is actually a problem that is
significant enough to need a fix.   I quite explicitly avoided
going there, not because it isn't important but because I'm not
at all convinced (and, as I at least hinted in the document, I
specifically believe that trying to reason forward from RFC 1796
without a careful analysis of the effects of relatively recent
boilerplate changes doesn't hold water) and hence not the person
to identify, much less advocate for, the perceived problems.

(2) Sorting through possible solutions to see both if they have
a good chance of solving those problems and to understand the
costs of deploying and/or experimenting with them.  The document
was intended to help with at least parts of that.

(3) Actually designing any experiments so we have a clear
understanding of the back out strategy, its costs, and any
residual damage.  I see Brian's qualifier suffixes as the least
complex to back away from of things that have been proposed, but
even it is not cost or risk-free, especially when one considers
citations to documents from well outside our community and the
amount of planning and ongoing effort it will take to keep such
citations or links working.   Again, the draft addresses parts
of that, but only slightly.

The draft took more time than I had but was still a fairly hasty
piece of work (which is one reason why some of the issues are
better covered for some possibilities than others).  One topic I
hope we can discuss post-BoF is whether a revised version of it
is likely to have lasting value (in which case I'll be looking
for collaborators/ co-authors) or whether it will have served
its purpose by then and we can move on.

best,
     john