Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990)
James Carlson <carlsonj@workingcode.com> Mon, 22 March 2010 11:43 UTC
Return-Path: <carlsonj@workingcode.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 5773B3A6826 for <pppext@core3.amsl.com>;
Mon, 22 Mar 2010 04:43:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.007
X-Spam-Level:
X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-0.322,
BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SARE_SUB_NEED_REPLY=0.784]
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 1BNn7MKMu778 for
<pppext@core3.amsl.com>; Mon, 22 Mar 2010 04:43:44 -0700 (PDT)
Received: from carlson.workingcode.com
(carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by
core3.amsl.com (Postfix) with ESMTP id 6DC7F3A683F for <pppext@ietf.org>;
Mon, 22 Mar 2010 04:43:44 -0700 (PDT)
Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132])
(authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with
ESMTP id o2MBhjHH000244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA
bits=256 verify=NO); Mon, 22 Mar 2010 07:43:46 -0400 (EDT)
Message-ID: <4BA757F1.8090307@workingcode.com>
Date: Mon, 22 Mar 2010 07:43:45 -0400
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Y Prasad <yprasad@juniper.net>
References: <4B98E356.2070804@workingcode.com>
<201003111520.o2BFKpeP066268@calcite.rhyolite.com>
<0DB0FFEA6887E349861A3F6B40D71C3A0639CE88@gaugeboson.jnpr.net>
<B8F6B4C5-27F7-41E9-B986-64D3C88BE8D7@columbus.rr.com>
<0DB0FFEA6887E349861A3F6B40D71C3A0639D2C4@gaugeboson.jnpr.net>
<4BA6726C.8040502@workingcode.com>
<0DB0FFEA6887E349861A3F6B40D71C3A0639D3D4@gaugeboson.jnpr.net>
In-Reply-To: <0DB0FFEA6887E349861A3F6B40D71C3A0639D3D4@gaugeboson.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-DCC-dmv.com-Metrics: carlson; whitelist
Cc: pppext@ietf.org, i.goyret@alcatel-lucent.com,
Vernon Schryver <vjs@calcite.rhyolite.com>, Karl Fox <karlfox@columbus.rr.com>
Subject: Re: [Pppext] LCP echo request/reply support over multilink interface
(RFC 1990)
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: Mon, 22 Mar 2010 11:43:45 -0000
Y Prasad wrote: > James, > > I understand all the options we have :) > Just wanted make effort to convey the reason for this interoperability > and prevent such of these at the next draft if possible. I think the prospects for "prevention" are dim at best. The peers that want to send these messages without asking first can already do so, and will continue to do so regardless of what sort of position we take in this working group. RFC 1990 is out the door; we can't reasonably recall it. There's no way to "force" the negotiation you're hoping for to occur, because publishing a new RFC doesn't force anyone to conform. Rather, it works the other way around: if you have a bunch of people who want to conform to a single specification (and have the money and skill to spend on development), then having a published RFC is a good way of making sure that they're all driving in the same direction. The document is a guide, not a reliable demand for posterity. Although we may disagree on the right new language to use in the document (I would argue for "must reply" and "should not request"), I think we do agree that there's a lack of specificity here, and it's one that may lead to interoperability problems. It is something that ought to be fixed, regardless of whether it will actually help your situation (it won't) or whether it's an important issue in context (I don't think it is). -- James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
- [Pppext] LCP echo request/reply support over mult… Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … Ignacio Goyret
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Ignacio Goyret
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … Vernon Schryver
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Vernon Schryver
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson
- Re: [Pppext] LCP echo request/reply support over … Y Prasad
- Re: [Pppext] LCP echo request/reply support over … James Carlson