Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft

"Jose Saldana" <> Mon, 25 November 2013 08:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5A93D1ACC87; Mon, 25 Nov 2013 00:44:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9rU9Iv_TD5i2; Mon, 25 Nov 2013 00:44:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7DA151ACC81; Mon, 25 Nov 2013 00:44:31 -0800 (PST)
Received: from usuarioPC ( []) by (8.13.8/8.13.8/Debian-3) with ESMTP id rAP8iP0M002171; Mon, 25 Nov 2013 09:44:25 +0100
From: "Jose Saldana" <>
To: "'Tim Chown'" <>
References: <008c01cee5e1$9caa4590$d5fed0b0$> <> <01ee01cee6da$b05eb9a0$111c2ce0$> <> <01da01cee768$42926af0$c7b740d0$> <> <EMEW3|03e3a08ad2910f9d659aa138fccb1644pAM9wB03tjc||>
In-Reply-To: <EMEW3|03e3a08ad2910f9d659aa138fccb1644pAM9wB03tjc||>
Date: Mon, 25 Nov 2013 09:44:33 +0100
Organization: Universidad de Zaragoza
Message-ID: <00c301cee9ba$90d91de0$b28b59a0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI/pFXgt4LgH+pyHEEB6KKfTqM8zAIc4popAgX21NgA+hAoBAKlUkKdAnqSMsoCjY1aepjt174w
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc:, 'Martin Stiemerling' <>,, 'Spencer Dawkins' <>
Subject: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Nov 2013 08:44:35 -0000

Hi, Tim.

I think it is a good idea and we should definitely explain the scenarios in
more detail.

When you talk about a "deliverable which describes scenarios and
requirements," do you mean another draft? In the current "TCM-TF reference
model" draft, section 1.4 is about "Scenarios of application". Would it be
enough if we improve that section according to what we have discussed in the
last days?

Regarding the potential effects on other protocols, do you think we should
include that on the same draft?

Thanks a lot,


> -----Mensaje original-----
> De: Tim Chown []
> Enviado el: sábado, 23 de noviembre de 2013 10:58
> Para:
> CC: Eggert, Lars;;; Martin Stiemerling;
> Reinaldo Penno (repenno); Spencer Dawkins
> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
> Hi,
> On 22 Nov 2013, at 09:50, Jose Saldana <> wrote:
> > Hi, Lars.
> >
> > During the BoF in Berlin, I got the impression that the problem was
> > not the idea of TCM-TF itself, but some of the considered options
> > (e.g. TCP). There were many people who raised their hands when asked
> > about "willing to review docs or comment on mailing list". However, it
> > seems that there are some people who are not convinced about the utility
> of TCM-TF.
> >
> > So in order to reach consensus, let us keep on discussing and
> > thinking. This is very enriching, since it is making us refine the
> > scenarios where TCM-TF may have a real potential, and discard the ones
> which it makes no sense.
> I think it may be useful if the charter includes a deliverable which
> scenarios and requirements. At present, the scenarios and existing
> solutions are presented in points 1-4 of the charter, rather than being
> formally documented as part of the WG activities. Such a document could
> explain why, from a requirements perspective, ROHC isn’t sufficient for
> use cases envisioned. It could also clarify what’s in scope, e.g. point 2
> mentions satellite while point 10 mentions satellite as possible future
> work. There’s been some good scenario discussion on the list recently
> which could all be captured.
> What’s also missing is analysis of the impact on other protocols of
> soemthing like this; this concern was raised at the previous BoF.
> Tim