IETF Logo Mail Archive

Re: [Pppext] I-D Action:draft-hu-pppext-ipv6cp-requirements-00.txt

Vernon Schryver <vjs@calcite.rhyolite.com> Wed, 20 October 2010 14:28 UTC

Return-Path: <vjs@calcite.rhyolite.com>
X-Original-To: pppext@core3.amsl.com
Delivered-To: pppext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4851D3A69D7 for <pppext@core3.amsl.com>; Wed, 20 Oct 2010 07:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfRhqgGqurOI for <pppext@core3.amsl.com>; Wed, 20 Oct 2010 07:28:10 -0700 (PDT)
Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by core3.amsl.com (Postfix) with ESMTP id DD2A73A6830 for <pppext@ietf.org>; Wed, 20 Oct 2010 07:28:09 -0700 (PDT)
Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id o9KETNWQ092486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from <vjs@calcite.rhyolite.com>; Wed, 20 Oct 2010 14:29:24 GMT
Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id o9KETNpi092485; Wed, 20 Oct 2010 14:29:23 GMT
Date: Wed, 20 Oct 2010 14:29:23 GMT
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <201010201429.o9KETNpi092485@calcite.rhyolite.com>
To: carlsonj@workingcode.com, huj@ctbri.com.cn
In-Reply-To: <4CBEEF16.1030304@workingcode.com>
X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist
Cc: pppext@ietf.org
Subject: Re: [Pppext] I-D Action:draft-hu-pppext-ipv6cp-requirements-00.txt
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Oct 2010 14:28:11 -0000

> From: James Carlson <carlsonj@workingcode.com>
> To: huj@ctbri.com.cn
> Cc: pppext@ietf.org

> > Yes, of course, we've read the archives(after 2004) carefully.
> > Right, several drafts have ever been posted trying to solve some of
> > these problems, but not moving forward.
>
> Correct; there was no consensus to do so.

There was a clear consensus to not do so.  That differs from
a lack of consensus.


> > But now, under the great pressure of IPv4 address exhaustion, we try to
> > evaluate critical mechanisms for IPv6

IPv4 addresses will be exhausted before a standards track RFC could
be approved.  Any real IPv6/PPP problems at this late date must be
addressed elsewhere.

> > One RFC will make real sense only if it is verified by implementations
> > in real world and finally got widely deployed.

No RFC can be approved by the IAB etc. in time to encourage independent
implementations until long after the last IPv4 address has been assigned.

China Telecom must have started testing and working with IPv6 years
ago, just like the rest of us.  If China Telecom really thinks that
the problems described in the drafts must be solved by extending the
point-to-point protocol instead of using the existing, familiar,
standardized, and widely implemented mechanisms, then China Telecom
must have already built, tested, and deployed in alpha testing prototype
implementations of the proposed PPP extensions.  What has been observed,
especially in the alpha testing?


Vernon Schryver    vjs@rhyolite.com

v2.8.7 | Report a Bug | By Email