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

Joe Touch <> Sat, 16 June 2012 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D192121F84FE for <>; Sat, 16 Jun 2012 10:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R8qH00-YEw8Y for <>; Sat, 16 Jun 2012 10:18:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5A60921F84EC for <>; Sat, 16 Jun 2012 10:18:42 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q5GHHmR1022326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 16 Jun 2012 10:18:02 -0700 (PDT)
Subject: Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="iso-2022-jp"
From: Joe Touch <>
In-Reply-To: <>
Date: Sat, 16 Jun 2012 10:18:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Masataka Ohta <>
X-Mailer: Apple Mail (2.1278)
X-ISI-4-43-8-MailScanner: Found to be clean
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Jun 2012 17:18:43 -0000

On Jun 15, 2012, at 10:54 PM, Masataka Ohta wrote:

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

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.

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

4821 neither updates nor obsoletes 1191. It provides an alternative, which is (AFAIK) not widely used either.

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

It does not change existing requirements that the DF bit should not be ignored.

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

If you have a specific example of how this draft makes 1191 PMTUD more harmful, please explain. Merely restating existing requirements on preservation of the DF bit does not.

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

The draft neither mentions nor discusses 1191. If you want to update existing standards regarding PMTUD, you should write that doc.

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

You can make that case in the doc that obsoletes 1191 if you like. 

This entire issue is out of scope of this document, though.