Re: [Gen-art] Gen-ART review of draft-ietf-mext-nemo-v4traversal-07.txt
Hesham Soliman <hesham@elevatemobile.com> Sun, 14 December 2008 02:03 UTC
Return-Path: <gen-art-bounces@ietf.org>
X-Original-To: gen-art-archive@optimus.ietf.org
Delivered-To: ietfarch-gen-art-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FFEA3A68EB; Sat, 13 Dec 2008 18:03:56 -0800 (PST)
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50CC73A68F6 for <gen-art@core3.amsl.com>; Sat, 13 Dec 2008 18:03:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599]
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 JjhRwSo-Z4SC for <gen-art@core3.amsl.com>; Sat, 13 Dec 2008 18:03:54 -0800 (PST)
Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 723283A68EB for <gen-art@ietf.org>; Sat, 13 Dec 2008 18:03:53 -0800 (PST)
Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LBgKd-0003Ew-SC; Sun, 14 Dec 2008 13:03:44 +1100
User-Agent: Microsoft-Entourage/12.14.0.081024
Date: Sun, 14 Dec 2008 13:03:34 +1100
From: Hesham Soliman <hesham@elevatemobile.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, General Area Review Team <gen-art@ietf.org>
Message-ID: <C56AB4A6.AB2A%hesham@elevatemobile.com>
Thread-Topic: Gen-ART review of draft-ietf-mext-nemo-v4traversal-07.txt
Thread-Index: AcldkCtO6nwpErpWVU2c2jUmbPM7zw==
In-Reply-To: <49441BD3.8020102@gmail.com>
Mime-version: 1.0
Cc: draft-ietf-mext-nemo-v4traversal@tools.ietf.org, mext-chairs@tools.ietf.org, Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-mext-nemo-v4traversal-07.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
Hi Brian, The following appear to me to be used normatively; the absence of an upper case keyword doesn't prove the absence of a normative reference: > [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. > Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, > March 2000. > [RFC2983] Black, D., "Differentiated Services and Tunnels", > RFC 2983, October 2000. (Sorry about this, it was added at my suggestion and is a downref.) => I don't understand how the reference to GRE is a downref. There is no requirement language for it, it's simply supported if someone needs it. If you could tell me that then I will understand some of the other downrefs you refer to. Also, what do you suggest we do with 2983? > [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition > of Explicit Congestion Notification (ECN) to IP", > RFC 3168, September 2001. > [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms > for IPv6 Hosts and Routers", RFC 4213, October 2005. > [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- > Network Tunneling", RFC 4459, April 2006. => Again, I don't see it for 3168, 4213 or 4459. Can you please explain it for at least a couple of those so I know what you mean? For example, why is 3168 a downref? > [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol > (MOBIKE)", RFC 4555, June 2006. => How can this be a downref?? > 5.2. NAT Detection ... > A mobile node MUST always tunnel binding updates in UDP when located > in an IPv4-only network. I think this should indicate how the mobile knows that it's in an IPv4-only network, or maybe it should say 'A mobile node that has not been assigned an IPv6 address by the foreign network...'. Also, there's a missing verb in that sentence. => This is explained in section 5.4.4. I forgot to add the verb, will do that. Thanks, Hesham _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART review of draft-ietf-mext-nemo-… Brian E Carpenter
- Re: [Gen-art] Gen-ART review of draft-ietf-mext-n… Hesham Soliman
- Re: [Gen-art] Gen-ART review of draft-ietf-mext-n… Brian E Carpenter
- Re: [Gen-art] Gen-ART review of draft-ietf-mext-n… Hesham Soliman