Re: Review of draft-ietf-behave-dccp-04

" Rémi Denis-Courmont" <remi.denis-courmont@nokia.com> Thu, 06 November 2008 12:23 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229183A699F; Thu, 6 Nov 2008 04:23:44 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186363A699F for <ietf@core3.amsl.com>; Thu, 6 Nov 2008 04:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmneFDyBpBo5 for <ietf@core3.amsl.com>; Thu, 6 Nov 2008 04:23:42 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 145093A6989 for <ietf@ietf.org>; Thu, 6 Nov 2008 04:23:41 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mA6CNW9I017998; Thu, 6 Nov 2008 14:23:36 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 14:23:27 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 14:23:27 +0200
Received: from esdhcp041160.research.nokia.com ([172.21.41.160]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Nov 2008 14:23:27 +0200
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Organization: Maemo Software - Nokia Devices R&D
To: ietf@ietf.org
Subject: Re: Review of draft-ietf-behave-dccp-04
Date: Thu, 06 Nov 2008 14:23:27 +0200
User-Agent: KMail/1.9.10
References: <3873DF72-B768-427B-A6F5-99778DF5DC02@ericsson.com>
In-Reply-To: <3873DF72-B768-427B-A6F5-99778DF5DC02@ericsson.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200811061423.27286.remi.denis-courmont@nokia.com>
X-OriginalArrivalTime: 06 Nov 2008 12:23:27.0493 (UTC) FILETIME=[78A88350:01C9400A]
X-Nokia-AV: Clean
Cc: ext Christian Vogt <christian.vogt@ericsson.com>, Behave Chairs <behave-chairs@tools.ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Thursday 06 November 2008 14:07:41 ext Christian Vogt, you wrote:
> (2) On requirements 1 and 3:
>
>          REQ-1: A NAT MUST have an "Endpoint-Independent Mapping"
>          behavior for DCCP.
>
>          REQ-3: If application transparency is most important, it is
>          RECOMMENDED that a NAT have an "Endpoint-independent filtering"
>          behavior for DCCP.  If a more stringent filtering behavior is
>          most important, it is RECOMMENDED that a NAT have an
>          "Address-dependent filtering" behavior.
>
>      These requirements are general and not specific to DCCP.  Would it
>      make sense to specify them in a separate RFC for NATs in general,
>      independent of any specific transport protocol?

Whether it's of any use depends on the connection model (or lack thereof) of 
the transport protocol. I don't want to presume that this would make sense 
for all future transport protocols. In fact, it does not make sense for 
multicast UDP(-Lite) to me - which has its own document.

> (3) On requirement 6:
>
>          REQ-6: If a NAT includes ALGs, it MUST NOT affect DCCP.
>
>      This requirement is not 100% clear.  I am assuming it means:  "If a
>      NAT includes ALGs, the NAT MUST NOT affect DCCP packets that are
>      processed by one of those ALGs."  Suggest to reword the requirement
>      in this way.

This reads worse to me. An ALG cannot "process" DCCP packets if it does not 
affect in any way. There is already a IESG discuss on this. What about this?

          REQ-6: If a NAT includes ALGs, they MUST NOT affect DCCP.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf