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

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jul 2018 10:02:28 -0400

Hi.

As suggested by one of my comments to the list several days ago
and in the hope that it will help with the discussions, I've put
together an Internet Draft that attempts to summarize some major
categories of proposals so far.  The draft largely sets the
issues of problem statement and whether there is a problem work
solving aside and looks at possible solutions (including one
very radical one not explicitly proposed yet, at least in any
message I've seen).

Alissa agreed to allowing it to be posted between the cutoff and
Monday if I sent it to her.  I did that at around 19:48 UTC
yesterday.  It apparently has not been posted yet, I assume
because of the very busy schedule of the IETF Chair.  If she
continues to not have time, I'll post it to this list late
afternoon Montreal time today and then just go through the
normal procedure for the repository.

I hope at least a few people find it helpful.

best,
    john

---

From: Heather Flanagan <[email-masked]>
Date: Sat, 14 Jul 2018 12:52:30 -0400

> On Jul 14, 2018, at 10:02, John C Klensin <[email-masked]> wrote:
> ...
> 

FYI, I just saw Alissa. She’s sent the draft on to the Secretariat for posting. 

-Heather

> _______________________________________________
> Rfcplusplus mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rfcplusplus
>

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 14 Jul 2018 13:28:02 -0400

> On Jul 14, 2018, at 12:52 PM, Heather Flanagan <[email-masked]> wrote:
> 
> 
> 

Yep sent it yesterday and just checked with them and they will get it posted.

Alissa

---

From: Heather Flanagan <[email-masked]>
Date: Sat, 14 Jul 2018 13:37:20 -0400

https://datatracker.ietf.org/doc/draft-klensin-rfcplusplus-alternatives/?include_text=1

Sent from my iPad

> On Jul 14, 2018, at 13:28, Alissa Cooper <[email-masked]> wrote:
> 
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 14 Jul 2018 13:53:00 -0400

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).

Cheers,
Andy

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jul 2018 14:55:40 -0400

--On Saturday, July 14, 2018 13:53 -0400 "Andrew G. Malis"
<[email-masked]> 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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Jul 2018 13:27:32 -0400

> https://tools.ietf.org/html/draft-klensin-rfcplusplus-alternatives-00

Thanks for writing this, John, I found it a good enumeration of options.

Also, I found this process reasonable:

> (1) Determining that there is actually a problem 
> (2) Sorting through possible solutions 
> (3) Actually designing any experiments 

Jari