Re: RFC 3484 Section 6 Rule 9
Simon Josefsson <simon@josefsson.org> Tue, 03 June 2008 12:54 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1643A6B3A; Tue, 3 Jun 2008 05:54:25 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E5E3A6B36 for <ietf@core3.amsl.com>; Tue, 3 Jun 2008 05:54:24 -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 T3P6WjkATsFR for <ietf@core3.amsl.com>; Tue, 3 Jun 2008 05:54:23 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 55F0928C200 for <ietf@ietf.org>; Tue, 3 Jun 2008 05:50:19 -0700 (PDT)
Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <simon@josefsson.org>) id 1K3Vxv-0007Yg-7F; Tue, 03 Jun 2008 14:50:15 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: RFC 3484 Section 6 Rule 9
References: <200806020456.m524ueYb080876@drugs.dv.isc.org> <200806031243.m53Cheo5027215@cichlid.raleigh.ibm.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080603:ietf@ietf.org::W6O5cCoeBeQJ8fub:0Tss
X-Hashcash: 1:22:080603:mark_andrews@isc.org::BlgJ3OBsKBcErn+p:3sf4
X-Hashcash: 1:22:080603:narten@us.ibm.com::/9pubWxqe/CjUldz:mfZa
Date: Tue, 03 Jun 2008 14:50:14 +0200
In-Reply-To: <200806031243.m53Cheo5027215@cichlid.raleigh.ibm.com> (Thomas Narten's message of "Tue, 03 Jun 2008 08:43:40 -0400")
Message-ID: <87prqyd6nt.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Cc: Mark Andrews <Mark_Andrews@isc.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Thomas Narten <narten@us.ibm.com> writes: > Longest match in 3484 is a hack, ant it only works some of the > time. The WG most certinaly knew this when we approved the > document. But it was felt that longest-match was better than no rule > at all, as it helped on some situations. > > The real discussion that should be held is what could we replace it > with if we pulled out the rule entirely? > > We do need something better. What would that be? I suggest to describe the longest match as a rule that can be used some of time, and describe a new rule, random selection, to be used some of the time. Then you recommend the latter approach when the application don't know that the longest match rule is more appropriate. This would seem to meet the objective of causing the least surprise and the least damage. Thanks, Simon _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: RFC 3484 Section 6 Rule 9 Mark Andrews
- Re: RFC 3484 Section 6 Rule 9 marcelo bagnulo braun
- Re: RFC 3484 Section 6 Rule 9 Mark Andrews
- RFC 3484 Section 6 Rule 9 Mark Andrews
- Re: RFC 3484 Section 6 Rule 9 Pekka Savola
- Re: RFC 3484 Section 6 Rule 9 Mark Andrews
- Re: RFC 3484 Section 6 Rule 9 marcelo bagnulo braun
- Re: RFC 3484 Section 6 Rule 9 SM
- Re: RFC 3484 Section 6 Rule 9 Brian E Carpenter
- Re: RFC 3484 Section 6 Rule 9 Tony Finch
- Re: RFC 3484 Section 6 Rule 9 Mark Andrews
- Re: RFC 3484 Section 6 Rule 9 Leo Vegoda
- Re: RFC 3484 Section 6 Rule 9 Thomas Narten
- Re: RFC 3484 Section 6 Rule 9 Simon Josefsson
- Re: RFC 3484 Section 6 Rule 9 Ralph Droms
- Re: RFC 3484 Section 6 Rule 9 Simon Josefsson
- Re: RFC 3484 Section 6 Rule 9 Tony Finch
- Re: RFC 3484 Section 6 Rule 9 Simon Josefsson
- Re: RFC 3484 Section 6 Rule 9 Arifumi Matsumoto
- Re: RFC 3484 Section 6 Rule 9 Michael StJohns
- Re: RFC 3484 Section 6 Rule 9 Tony Finch
- Re: RFC 3484 Section 6 Rule 9 Michael StJohns
- Re: RFC 3484 Section 6 Rule 9 Tony Finch
- Re: RFC 3484 Section 6 Rule 9 Brian E Carpenter
- Re: RFC 3484 Section 6 Rule 9 Joe Abley
- Re: RFC 3484 Section 6 Rule 9 Brian E Carpenter