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> Sat, 16 June 2012 05:55 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 636A321F85B1 for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 22:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.158
X-Spam-Level:
X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[AWL=0.248, 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 qxi1s-0i9TYR for <ietf@ietfa.amsl.com>; Fri, 15 Jun 2012 22:55:53 -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 5596B21F85AF for <ietf@ietf.org>; Fri, 15 Jun 2012 22:55:52 -0700 (PDT)
Received: (qmail 90230 invoked from network); 16 Jun 2012 06:00:18 -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; 16 Jun 2012 06:00:18 -0000
Message-ID: <4FDC1F9C.2060808@necom830.hpcl.titech.ac.jp>
Date: Sat, 16 Jun 2012 14:54:36 +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>
In-Reply-To: <4FDBEACA.4030701@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: Sat, 16 Jun 2012 05:55:54 -0000

Joe Touch wrote:

>>> That is not an innocent action.

>> 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.

That innocent operators must violate some standard means
the standard must be changed.

Moreover, there already is a change, RFC4821-stype PMTUD.

> This document doesn't make it more of a violation; it
> just explains the existing violation.

There is no point just to explain standards when the real
world recognizes that the standards can not be followed
and must be changed.

>> So, the proper thing for IETF to do is to obsolete RFC1191.
>>
>> There is no reason for IETF to ignore operational feedback
>> from the real world that RFC1191 is a bad idea.
> 
> That is not the focus of this document. Again, we don't create a new
> requirement.

Your draft reduces existing requirements to make RFC1191-style
PMTUD more harmful.

> If you feel there is consensus to raise this change, that
> would be a separate issue.

Do you think there is explicit consensus on your draft that
we should make RFC1191-stype PMTUD more harmful?

>>> It also violates RFC 791 and 1121.
>>
>> To stop the fair violation, obsolete RFC1191.
> 
> The steps needed to allow DF clearing need to be determined; I don't
> know what they are, but that's outside the scope of this doc.

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.

> - regarding clearing the DF bit, this document only restates existing
> requirements
> 
> Yes, there are other, new requirements that this document introduces.
> But the rules about not clearing the DF bit are not new.

The problem is that the real world requires standards must change.

We can obsolete RFC1191. Or, we must permit DF clearing.

So, there is no point to say DF clearing forbidden without
obsoleting RFC1191.

>> That many operators are actively violating the standard track
>> RFCs means the standard track RFCs are defective.
> 
> Or that they have defective equipment,

Yes, they often have equipments with RFC1191-style PMTUD.

> or that their logic in deciding
> to run their equipment this way is defective.

Don't ignore the logic in the real world to filter ICMP,
which requires standard changes.

> Just because "everyone
> does it" doesn't make it correct or warrant changing the specs (see RFC
> 2525 for treatment of TCP implementation errors, e.g.).

That is a completely different example from your draft.

>> it is not surprising if end users think you are guilty.
> 
> Again, this document doesn't change the current situation.

That's not a excuse not to change the current situation.

Worse, your draft will, by loosening a requirement, changes
the current operational situation worse.

> Operators who
> clear the DF bit are not innocent - they need to override a default
> setting. They are active participants. They ARE guilty of violating
> existing standards.

Comments are Requested For by IETF to them, the active participants.

Their comments are that they can't follow the standard, because
*SOMEONE ELSE* filters ICMP. They are not guilty.

Now, it's time for IETF to modify RFCs.

> You seem to think that this is OK because they have good reasons. That
> may make their actions acceptable, but it will not make them compliant
> *until* someone updates the standards that require the DF not be
> cleared. This is not that document.

Once RFC1191 is obsoleted, your draft becomes almost useless
because no one will follow the rate limitation requirement of
your draft.

						Masataka Ohta