Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Mon, 13 August 2012 09:46 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0321F86D5 for <ietf@ietfa.amsl.com>; Mon, 13 Aug 2012 02:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.049
X-Spam-Level:
X-Spam-Status: No, score=-0.049 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xOB0CezJDw5 for <ietf@ietfa.amsl.com>; Mon, 13 Aug 2012 02:46:08 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 7E62421F8712 for <ietf@ietf.org>; Mon, 13 Aug 2012 02:46:08 -0700 (PDT)
Received: (qmail 1144 invoked from network); 13 Aug 2012 09:44:36 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 13 Aug 2012 09:44:36 -0000
Message-ID: <5028CCB9.5050503@necom830.hpcl.titech.ac.jp>
Date: Mon, 13 Aug 2012 18:45:29 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
Subject: Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
References: <20120531143816.30508.66250.idtracker@ietfa.amsl.com> <Pine.LNX.4.64.1205311957420.31608@shell4.bayarea.net> <4FC9585E.6010205@necom830.hpcl.titech.ac.jp> <4FE2715C.2090601@necom830.hpcl.titech.ac.jp> <4FF20DE7.2080208@isi.edu> <500654AB.7060500@necom830.hpcl.titech.ac.jp> <8F5CBE79-4540-4519-9F51-62B36686EE8C@isi.edu> <501C5C75.9040209@necom830.hpcl.titech.ac.jp> <501C6441.4000302@isi.edu> <5020C32A.4060907@necom830.hpcl.titech.ac.jp> <50215032.7090800@isi.edu> <5027767A.60601@necom830.hpcl.titech.ac.jp> <5027E8EE.8010109@isi.edu>
In-Reply-To: <5027E8EE.8010109@isi.edu>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
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>
X-List-Received-Date: Mon, 13 Aug 2012 09:46:09 -0000

Joe Touch wrote:

> Again, this doc is about updating the IPv4 ID specification in RFC791 -
> which has not yet been updated.

But, the way you update rfc791 requires updating rfc2460,
rfc2765 and their implementations, for which there is no
consensus.

That is, though your draft claims to "more closely reflect
current practice" and "more closely match IPv6", the way you
update rfc791 does not "reflect current practice" nor "match
IPv6".

As your draft states:

   it is clear that
   existing systems violate the current specification

and rfc2026 states:

   4.1.3  Internet Standard
   A specification for which significant implementation and successful
   operational experience has been obtained may be elevated to the
   Internet Standard level.

there is no point to insist on the ID uniqueness requirement of
rfc791 as a requirement of an Internet Standard.

> The IPv6-IPv4 translation that creates IPv4 IDs is currently
> non-compliant with RFC791 and does not override RFC791. This document's
> update might make that translation easier,

Wrong.

Insisting on rfc791 makes the translation a lot harder than
just "closely reflect current practice" to loosen uniqueness
request of rfc791, which is what almost all (if not all) the
IPv4 and IPv6 implementations today are doing.

> If you disagree with that conclusion, please contact the INTAREA WG
> chairs directly.

As we are in IETF last call stage, I can see no point you
insist on the original conclusion of the WG, which
overlooked the complication caused by 6->4 translation.

						Masataka Ohta