Subject: [tcpm] Time for RFC4614bis?

From: Alexander Zimmermann <[email-masked]>
Date: Sun, 03 Jun 2012 18:26:18 +0200

Hi, all,

I'm wondering if the WG is interested in a update of the TCP Roadmap (RFC4614). If yes, I would like to start with a first proposal.

Alex

---

From: Matt Mathis <[email-masked]>
Date: Sun, 3 Jun 2012 10:32:24 -0700

An RFC does not feel like the right form.   Perhaps a wiki?   Perhaps
a wiki periodically, check pointed to an RFC.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Sun, Jun 3, 2012 at 9:26 AM, Alexander Zimmermann
<[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 03 Jun 2012 22:13:35 -0400

> a wiki periodically, check pointed to an RFC.

In the past, we'd talked about a perpetually living I-D,
with (perhaps) periodic snapshots as an RFC.

I would be really happy to see someone with the cycles
work on that (thanks Alex!).  I have a set of several
deltas stored up that I could share ... getting them
into an I-D has been something near the bottom of my
stack for a very long time, and I would love to hand
them off :).

-- 
Wes Eddy
MTI Systems

---

From: John Leslie <[email-masked]>
Date: Mon, 4 Jun 2012 06:43:42 -0400

>> a wiki periodically, check pointed to an RFC.

   Note the discussion on <[email-masked]> about the Tao...

   We do have a number of IETF wikis, mostly inactive. While I think
the wiki paradigm has promise, we're not there yet, IMHO.

> with (perhaps) periodic snapshots as an RFC.

   This is the paradigm we're ready for. I suggest a WG I-D, where
the responsible author can change as necessary.

   Whether it should be named draft-ietf-tcpm-4614bis is an open question,
which I am happy to defer to the WGCs -- though discussion might help...

--
John Leslie <[email-masked]>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 8 Jun 2012 10:44:01 +0200

Alex, all,

The chairs think that updating RFC 4614 is a very valuable and relevant objective for TCPM.

We'd be interested in further feedback from the community regarding the process to get there, e. g., whether a Wiki could be a reasonable approach for contributing text.

In any case, we need new text on what happened since RFC 4614 was completed... As a first step, we suggest to compile an initial draft, and then to discuss this draft as well as the process (e. g., in Vancouver).

Thanks

Michael

PS: I also have some incomplete data that I could share if needed.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alexander Zimmermann
> Sent: Sunday, June 03, 2012 6:26 PM
> To: [email-masked] Extensions
> Subject: [tcpm] Time for RFC4614bis?
> 
> Hi, all,
> 
> I'm wondering if the WG is interested in a update of the TCP 
> Roadmap (RFC4614). If yes, I would like to start with a first 
> proposal.
> 
> Alex
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Jun 2012 05:53:09 -0300

> relevant objective for TCPM.

+1

> We'd be interested in further feedback from the community regarding
> the process to get there, e. g., whether a Wiki could be a reasonable
> approach for contributing text.

Just double-checking: For contributing text, or as an alternative to
publishing an RFC?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 8 Jun 2012 10:59:53 +0200

> Just double-checking: For contributing text, or as an 
> alternative to publishing an RFC?

Well, both ;)

As individual, I'd argue that we should publish an RFC from time to time, to document the status and to go through the IETF review process.

Michael

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Jun 2012 06:08:35 -0300

On 06/08/2012 05:59 AM, Scharf, Michael (Michael) wrote:
>>> We'd be interested in further feedback from the community
>>> regarding the process to get there, e. g., whether a Wiki could
>>> be a
>> reasonable
>> Just double-checking: For contributing text, or as an alternative
>> to publishing an RFC?
> 
> Well, both ;)
> 
> As individual, I'd argue that we should publish an RFC from time to
> time, to document the status and to go through the IETF review
> process.

+1

That said, if there was consensus to not revise RFC4614 and publish a
wiki instead, we should probably have a small RFC noting that RFC4614
has been replaced by a Wiki (in the same way in which we have an RFC
noting that the port numbers registry is "now" maintained in an IANA web
page).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Fri, 08 Jun 2012 11:27:34 -0700

-1.

I think this doc should be updated VERY sparingly at best.

It's important to understand what this doc would say differently. Is 
there a list of the kinds of changes we feel are sufficient to drive the 
need for a revision?

Absent that list, -1.

If we have that list, then we can decide how to proceed. I don't think a 
WIKI is a good idea except as a place to develop that information for a 
RFC issued as an update. TCP isn't supposed to have that much flux - 
it's not like port assignments in that regard.

Joe

---

From: Anantha Ramaiah <[email-masked]>
Date: Fri, 8 Jun 2012 18:14:10 -0700

Since I cannot argue on the philosophical aspects, I would state my
arguments based on the facts.  RFC 4614 (atleast one of the main goals) was
to document all the TCP related RFC's, now the RFC list has grown which
makes RFC 4614 outdated, so time for an update, pretty simple isn't it?

Also, list should include all the recent TCP RFC's we don't want
to discriminate one RFC versus other nor have an imcomplete list. (that
shouldn't be the goal)  That said, I would favor the approach which Wes
suggested. ( plus we need to decide on the granularity of doing such
updates)

+1 for update assuming  we can agree on the above points.

-Anantha

On Fri, Jun 8, 2012 at 11:27 AM, Joe Touch <[email-masked]> wrote:

> It's important to understand what this doc would say differently. Is there
> a list of the kinds of changes we feel are sufficient to drive the need for
> a revision?
>
> Absent that list, -1.
>
> WIKI is a good idea except as a place to develop that information for a RFC
> issued as an update. TCP isn't supposed to have that much flux - it's not
> like port assignments in that regard.
>
> Joe
>
> ______________________________**_________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailman/listinfo/tcpm>
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 08 Jun 2012 18:26:22 -0700

On 6/8/2012 6:14 PM, Anantha Ramaiah wrote:
> arguments based on the facts.  RFC 4614 (atleast one of the main
> goals) was to document all the TCP related RFC's, now the RFC list has
> grown which makes RFC 4614 outdated, so time for an update, pretty
> simple isn't it?

By that argument this update would be outdated when the first RFC is 
published that proposes a modification - even optional or experimental - 
to TCP.

We need some perspective on when such updates will be needed - for this 
time, and in the future, IMO -- and this perspective would be good to 
add to the document. I.e., "This document should be considered for 
update when..."

IMO, unless there are updates to TCP that are mandatory, such an update 
is not needed.

Joe

---

From: Anantha Ramaiah <[email-masked]>
Date: Fri, 8 Jun 2012 18:44:26 -0700

Hi, Joe,
  If you read my original email carefully (which you snipped), it did
mention that :-

"Also, list should include all the recent TCP RFC's we don't want to
discriminate one RFC versus other nor have an imcomplete list. (that
shouldn't be the goal)  That said, I would favor the approach which Wes
suggested. ( plus we need to decide on the granularity of doing such
updates)"

"granularity of doing updates" is same as what you are alluding below.

-Anantha

On Fri, Jun 8, 2012 at 6:26 PM, Joe Touch <[email-masked]> wrote:

> published that proposes a modification - even optional or experimental - to
> TCP.
>
> time, and in the future, IMO -- and this perspective would be good to add
> to the document. I.e., "This document should be considered for update
> when..."
>
> IMO, unless there are updates to TCP that are mandatory, such an update is
> not needed.
>
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 08 Jun 2012 18:57:50 -0700

Hi, Anantha,

Yes, I don't think we're disagreeing that much, but I was expecting to 
apply the test now, rather than only after this update.

Joe

On 6/8/2012 6:44 PM, Anantha Ramaiah wrote:
> On Fri, Jun 8, 2012 at 6:26 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     published that proposes a modification - even optional or
>     experimental - to TCP.
>
>     We need some perspective on when such updates will be needed - for
>     this time, and in the future, IMO -- and this perspective would be
>     good to add to the document. I.e., "This document should be
>     considered for update when..."
>
>     IMO, unless there are updates to TCP that are mandatory, such an
>     update is not needed.
>
>     Joe
>
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 08 Jun 2012 20:13:50 -0300

Hi, Joe,

> I think this doc should be updated VERY sparingly at best.

What'd be the point of having an outdated roadmap?

> there a list of the kinds of changes we feel are sufficient to drive the

Well, we have published a bunch of TCPM documents since RFC 4614 was
published....

Of the top of my head, I can think of:

* The updated congestion control RFCs
* ICMP attacks
* ICMP soft errors
* tcpsecure et al
* Deprecation of urgen data
* Reduction of TIME_WAIT state by means of TCP timestamps
* TCP-AO
* Deprecation of Source Quench
* The upcoming TCP MSS and TCP timestamps
* etc...

> If we have that list, then we can decide how to proceed.

Well, please consider the above a starting point. :-)

> I don't think a

Agreed.

Thanks,