Re: [tcmtf] About the possibility of having a BOF about TCMTF in IETF87
ken carlberg <carlberg@g11.org.uk> Wed, 27 February 2013 15:23 UTC
Return-Path: <carlberg@g11.org.uk>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id ADC7221F84BB; Wed, 27 Feb 2013 07:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level:
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3ZwKM-6iJ7L;
Wed, 27 Feb 2013 07:23:19 -0800 (PST)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5])
by ietfa.amsl.com (Postfix) with ESMTP id 40E1921F84B2;
Wed, 27 Feb 2013 07:23:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk;
s=default;
h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type;
bh=7P3lFiwvOq2U/VjTU9sxnoC+kPRrDTkZYT8vhgkevTQ=;
b=fnQ/VsMd8r4DIy99WBbY4b60cMwQmS7PMMZ3UKKWuMb3A1PjnwfYyouARD0aPXGSdwdE+jvWCss9OuOsmuTRWacWhiD2vzHA7F+0TLKGQDQNNT8YLkdOyZ4kFFSp03gx;
Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:36211
helo=[10.0.1.20]) by portland.eukhosting.net with esmtps
(TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <carlberg@g11.org.uk>) id
1UAiqg-002wUN-AB; Wed, 27 Feb 2013 15:23:15 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <002801ce10e8$e070f7c0$a152e740$@unizar.es>
Date: Wed, 27 Feb 2013 10:23:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F86D34F3-7D68-4EE7-89F6-5577BBDA6072@g11.org.uk>
References: <003001cdff0e$33658a50$9a309ef0$@unizar.es> <008601ce0db4$e4af6f60$ae0e4e20$@unizar.es>
<50F486E8-69AA-4A9D-970C-1F8EC1372B8D@g11.org.uk>
<002801ce10e8$e070f7c0$a152e740$@unizar.es>
To: <jsaldana@unizar.es>
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry:
carlberg@g11.org.uk|g11.org.uk
Cc: tcmtf@ietf.org, tsv-area@ietf.org
Subject: Re: [tcmtf] About the possibility of having a BOF about TCMTF
in IETF87
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion
list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>,
<mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>,
<mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2013 15:23:19 -0000
Hola Jose, sorry for the tardy reply. The altered text below is helpful, thanks. With respect to your candidate deliverables, it appears that you have listed two for the proposed group: (A) a document that describes options and negotiation mechanisms, and (B) a document describing recommendations of which packet types should be multiplexed and a list fo traffic classification methods. Have you considered a third document that presents a more encompassing architecture or framework that would include sample scenarios upon which your deliverables A & B are aimed at? My impression is that you may want to point the reader of documents A & B to the same reference model, and instead of repeating the same text, it may be helpful to separate this into a separate document. Also, would section 9 of your proposed charter lead one to consider a requirements document? Many times, new groups start with a requirements document, but since you have a good focus of what you want to accomplish, perhaps your last deliverable could be a requirements document that would guide any future work. -ken ps, I don't want to advocate more work, but rather just have you consider other possibilities (and feel free to shoot them down :-) On Feb 22, 2013, at 5:39 AM, Jose Saldana <jsaldana@unizar.es> wrote: > Hi Ken, > > Sorry for the delay. I think you are talking about Paragraph 5: > > 5. So the first objective of this group is to specify the protocol stack for > tunneling, compressing and multiplexing traffic flows (TCMTF). Since > standard protocols are being used at each layer, the signaling methods of > those protocols will be used. Interactions with the Working Groups and Areas > in which these protocols are developed can be expected. However, the > development of new compressing, multiplexing or tunneling protocols is not > an objective of this Working Group. In addition, since the current RFC 4170 > would be considered as one of the options, this RFC could be obsoleted. > > Perhaps this is a bit confusing. When we say "at each layer", we are talking > about "tunneling, compressing and multiplexing" layers. Perhaps this can be > a bit confusing. What about this?: > > 5. So the first objective of this group is to specify the protocol stack for > tunneling, compressing and multiplexing traffic flows (TCMTF). Since > standard protocols are being used for tunneling, compressing and > multiplexing layers, the signaling methods of those protocols will be used. > Interactions with the Working Groups and Areas in which these protocols are > developed can be expected. However, the development of new compressing, > multiplexing or tunneling protocols is not an objective of this Working > Group. In addition, since the current RFC 4170 would be considered as one of > the options, this RFC could be obsoleted. > > Is this what you were asking? > > Thanks for your feedback. > > Jose > >> -----Mensaje original----- >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de >> ken carlberg >> Enviado el: martes, 19 de febrero de 2013 14:17 >> Para: jsaldana@unizar.es >> CC: tcmtf@ietf.org; tsv-area@ietf.org >> Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF in >> IETF87 >> >> Hola Jose, >> >> could you expand a bit more on your text in the proposed charter regarding >> "signaling methods". Are you speaking in the more general context of >> information stored in headers of various protocol up and down the stack > (ie, >> layers 3, 4, and 5/app)? Or, are you speaking of concurrent resource >> signaling protocols like RSVP/RSVP-TE, or path establishment protocols > like >> MPLS? Or, some combination of both? >> >> -ken >> >> _______________________________________________ >> tcmtf mailing list >> tcmtf@ietf.org >> https://www.ietf.org/mailman/listinfo/tcmtf >
- [tcmtf] About the possibility of having a BOF abo… Jose Saldana
- Re: [tcmtf] About the possibility of having a BOF… Eggert, Lars
- Re: [tcmtf] About the possibility of having a BOF… Jose Saldana
- Re: [tcmtf] About the possibility of having a BOF… Jose Saldana
- Re: [tcmtf] About the possibility of having a BOF… ken carlberg
- Re: [tcmtf] About the possibility of having a BOF… Jose Saldana
- Re: [tcmtf] About the possibility of having a BOF… ken carlberg
- Re: [tcmtf] About the possibility of having a BOF… Jose Saldana
- Re: [tcmtf] About the possibility of having a BOF… Jose Saldana
- Re: [tcmtf] About the possibility of having a BOF… ken carlberg
- Re: [tcmtf] About the possibility of having a BOF… Jose Saldana
- Re: [tcmtf] About the possibility of having a BOF… FERNANDO PASCUAL BLANCO
- Re: [tcmtf] About the possibility of having a BOF… MANUEL NUÑEZ SANZ