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, 18 June 2012 12:40 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 3C47B21F8610 for <ietf@ietfa.amsl.com>; Mon, 18 Jun 2012 05:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.034
X-Spam-Level:
X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=0.124, 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 2T-DDyopNVKI for <ietf@ietfa.amsl.com>; Mon, 18 Jun 2012 05:40:20 -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 54A1F21F860F for <ietf@ietf.org>; Mon, 18 Jun 2012 05:40:20 -0700 (PDT)
Received: (qmail 15712 invoked from network); 18 Jun 2012 12:45:46 -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; 18 Jun 2012 12:45:46 -0000
Message-ID: <4FDF219D.5020201@necom830.hpcl.titech.ac.jp>
Date: Mon, 18 Jun 2012 21:39:57 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
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> <4FC96ACA.9040800@isi.edu> <4FC97E57.6070505@necom830.hpcl.titech.ac.jp> <4FCEAB53.2020504@isi.edu> <4FDB12F2.6030808@necom830.hpcl.titech.ac.jp> <4FDB6843.6090107@isi.edu> <4FDBE75A.8090100@necom830.hpcl.titech.ac.jp> <4FDBEACA.4030701@isi.edu> <4FDC1F9C.2060808@necom830.hpcl.titech.ac.jp> <79E3C9F8-3A0F-4BD7-B018-A508D439ED57@isi.edu>
In-Reply-To: <79E3C9F8-3A0F-4BD7-B018-A508D439ED57@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, 18 Jun 2012 12:40:21 -0000

Joe Touch wrote:>

>>>> It is a fair action by innocent providers.
>>
>>> It is a violation of standards. They may do it innocently, but it's
>>> still a violation.
>>
>> You misunderstand standardization processes.
> 
> Standards remain so until revoked explicitly. Common use does
> not itself revoke a standard - it can also represent either
> operator error or ignorance. That decision has not yet been
> made for ignoring the DF bit - if you want to make that case,
> you need to take it through the IETF process to obsolete the
> existing standards.

Urrrr, I'm afraid standards can be ignored a lot more easily.

That operators think it fine to clear DF means IETF must
admit it especially because there is RFC 4821.

>> Your draft reduces existing requirements to make RFC1191-style
>> PMTUD more harmful.
> 
> It does not change existing requirements that the DF bit should
> not be ignored.

So what?

That it does change existing requirements is the problem.

> If you have a specific example of how this draft makes 1191 PMTUD
> more harmful, please explain.

As I already wrote, your draft enables people insisting on 1191
PMUTD can, now, set ID always zero, which is harmful to people,
IN THE REAL WORLD, to clear DF.

> Merely restating existing requirements on preservation of the
> DF bitn

The reality is that you merely loosening existing requirements
to make IPv4 PMTUD more harmful.

>> Your draft has too much to do with RFC1191-stype PMTUD and
>> is narrowly scoped to make RFC1191-stype PMTUD more harmful,
>> which means it is in scope.
> 
> The draft neither mentions nor discusses 1191. If you want to
> update existing standards regarding PMTUD, you should write
> that doc.

That you maliciously do not mention 1191 dose not mean your
draft is strongly tied to 1191.

>> Once RFC1191 is obsoleted, your draft becomes almost useless
>> because no one will follow the rate limitation requirement of
>> your draft.
> 
> You can make that case in the doc that obsoletes 1191 if you like.

My point is that that's what IETF must do.

						Masataka Ohta

PS

While your draft is rather harmful than useless, I'm fine
if the following point of the draft:

   >> Originating sources MAY set the IPv4 ID field of atomic
   datagrams to any value.

is changed to:

   >> Originating sources MUST set the IPv4 ID field of atomic
   datagrams to values as unique as possible.

which is what the current BSD implementations do.