Re: Summary of proposed changes to draft-gont-tsvwg-source-quench

Fernando Gont <> Thu, 02 December 2010 04:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DF0E3A6876 for <>; Wed, 1 Dec 2010 20:04:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.39
X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mqMEUllf1Uz7 for <>; Wed, 1 Dec 2010 20:04:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A89DA3A6873 for <>; Wed, 1 Dec 2010 20:04:19 -0800 (PST)
Received: by gwj18 with SMTP id 18so4768749gwj.1 for <>; Wed, 01 Dec 2010 20:05:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=UeWfnJMvEii3KpVxgNip51fmsY0h4qGnML/irnNq3YE=; b=J/240oDFZc6Zl9vZEB0n0KG7Gp7Hk749YijBEeOBtBVAh9AyowqDr0Eps9uiaV2KO4 t/sQMFhrAwyvzcXf5P+5EMphSQENXHr7pAh5gT4xeR7hEpyQ5AtUjmLRZBwI0FfhWs+e pwByW20A5a03IANXLOcMSVKSCe7diNJOsiuVU=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ObiqQPgEohwJrL7I2GEbVWesPhdF7fI8du0e3/82febS+4gdLulucKQaTglM3yz/yn 5UM3+4DYwH8x0X9h8wKjO9FI82eazIPyBqoLI3rUtU4WMsk9W1GprMF0ITJoQkWyxur4 kO2vyXT7HASYzAbp+8YfM4XUyLQx/YkQbRPuo=
Received: by with SMTP id y1mr552450ybn.323.1291262734200; Wed, 01 Dec 2010 20:05:34 -0800 (PST)
Received: from [] ( []) by with ESMTPS id q8sm2168341ybk.12.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 20:05:33 -0800 (PST)
Sender: Fernando Gont <>
Message-ID: <>
Date: Thu, 02 Dec 2010 01:05:27 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Fred Baker <>
Subject: Re: Summary of proposed changes to draft-gont-tsvwg-source-quench
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "" <>, tsvwg <>, Dan Wing <>,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Dec 2010 04:04:22 -0000

On 02/12/2010 12:15 a.m., Fred Baker wrote:

>>> Do you expect folks to be building new IPv4 routers at some point
>>> in the future?
>> Yes, as much as they build new IPv6 routers. -- put another way, I
>> don't think ipv6-only routers will be shipped in the near term.
>> e.g., anyone entering the business would have to implement both
>> IPv4 and IPv6 (unless they base their products on existing code, of
>> course).
> Two different questions. If I build a new bit of hardware and port an
> old bit of code to it, it will still do what the old bit of code did.
> Yes, there will be routers that implement IPv4 functionality; there
> are currently "new" routers that implement DECNET IV, XNS, Novell
> Netware, and OSI CLNS. Are there any that will do so with new
> functionality? Not on your life.

Agreed. However, there's no existing requirement that everybody should
base his products on someone else's code.

In theory, a product implementing IPv4 from scratch would base its
implementation on the RFCs.

-- Yeah, I know... in practice most products are based on someone else's
code (whether legally or not), and the RFCs tend to be outdated, so it's
not really possible to comply with them.

> Are you expecting folks to build IPv4 routers that try to interpret
> source quench?

I'm expecting folks to build IPv4 routers, and I'm expecting people to
implement stuff that the RFCs tell them that they MUST/SHOULD/MAY
implement (and sometimes not even that) -- from my perspective, the less
an implementer has to figure out by himself, the better.

IMO, at least for every protocol that is still expected to be
implemented, the IETF should do the maintenance of the corresponding
specifications -- and that includes formally obsoleting features that
have become obsolete.

FWIW, I know of vendors that run "RFC-compliance" tests, for which it
does matter that they implement what the RFCs mandate -- whether this is
clever or not, is a different story. But performing the proper
specifications maintenance help these folks, too.

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1