IETF Logo Mail Archive

Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Ted Lemon <ted.lemon@nominum.com> Tue, 25 February 2014 23:55 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22E01A0311 for <softwires@ietfa.amsl.com>; Tue, 25 Feb 2014 15:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz4vJN6Tq5vv for <softwires@ietfa.amsl.com>; Tue, 25 Feb 2014 15:55:46 -0800 (PST)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id B844A1A02CD for <softwires@ietf.org>; Tue, 25 Feb 2014 15:55:46 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A41B61B8215 for <softwires@ietf.org>; Tue, 25 Feb 2014 15:55:45 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 96CCD190052; Tue, 25 Feb 2014 15:55:45 -0800 (PST)
Received: from [10.0.1.10] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 15:55:45 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <F70097FE-5D5A-4F91-AAF9-09F30FB74AF5@employees.org>
Date: Tue, 25 Feb 2014 18:55:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <947F3013-19D5-4EB0-82DC-1246AE9362FE@nominum.com>
References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <FD878467-904B-4441-95B4-11D4461A612E@employees.org> <CF237FDE.AACEB%ian.farrer@telekom.de> <CAFFjW4jOBfvnqCV4UH8qt0HA5zZ-35f+q5ZepzjnwGX5_Oj9Gg@mail.gmail.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <CAFFjW4iP2KqNJFtJPr5rp0tzRwM5TPjaqiSP5r13JqbX46ao7w@mail.gmail.com> <CD1D4FF6-9509-43B4-AFC4-4F1AF99D0C4D@gmx.com> <CAFFjW4ibkj_xpTuXrbYjxkdxD=+qNzapCGPHJwXsZ-k0ZvGg-g@mail.gmail.com> <EBAECD54-9E78-4B07-BC8F-032B585AE0EE@gmail.com> <CAFFjW4hEBF3ZTnGXv+0ncTb981Mr_mdMW04EW=ZqBWFSRE9Q-Q@mail.gmail.com> <530CDF3D.3030908@gmail.com> <E540B187-E331-4FCD-B962-8FBCB4C945B8@nominum.com> <F70097FE-5D5A-4F91-AAF9-09F30FB74AF5@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/IHBr327EENCGoUCIeeWIjmRddWw
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 23:55:48 -0000

On Feb 25, 2014, at 6:11 PM, Ole Troan <otroan@employees.org> wrote:
> I think the point he was trying to make was that it isn't optimal to have two standards documents, specifying mechanisms where one is almost completely encompassed by the other. I say almost, because there might be some divergence in how tunnel endpoint addresses are used, and how fragmentation and ICMP is dealt with.

If this is indeed his point, I'm sure we're all sympathetic (I know I am) but it's not actionable, so we should move on.

v2.23.0 | Report a Bug | By Email