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