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>