RE: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()

Dave Thaler <dthaler@microsoft.com> Tue, 31 July 2012 22:40 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E15721F8738 for <ipv6@ietfa.amsl.com>; Tue, 31 Jul 2012 15:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.397
X-Spam-Level:
X-Spam-Status: No, score=-103.397 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XOMFQ9QT5d8 for <ipv6@ietfa.amsl.com>; Tue, 31 Jul 2012 15:40:18 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id E32CA21F86EB for <ipv6@ietf.org>; Tue, 31 Jul 2012 15:40:17 -0700 (PDT)
Received: from mail166-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 22:40:06 +0000
Received: from mail166-ch1 (localhost [127.0.0.1]) by mail166-ch1-R.bigfish.com (Postfix) with ESMTP id 5E29E60272; Tue, 31 Jul 2012 22:40:06 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -30
X-BigFish: VS-30(zz98dI9371I936eI542M1432I1447Izz1202hzz1033IL8275dhz2fh2a8h668h839h93fhd25hf0ah107ah)
Received-SPF: pass (mail166-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail166-ch1 (localhost.localdomain [127.0.0.1]) by mail166-ch1 (MessageSwitch) id 1343774405146317_9047; Tue, 31 Jul 2012 22:40:05 +0000 (UTC)
Received: from CH1EHSMHS019.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail166-ch1.bigfish.com (Postfix) with ESMTP id 2186D240049; Tue, 31 Jul 2012 22:40:05 +0000 (UTC)
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 22:40:04 +0000
Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 31 Jul 2012 22:40:03 +0000
Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Tue, 31 Jul 2012 15:40:02 -0700
From: Dave Thaler <dthaler@microsoft.com>
To: Karl Auer <kauer@biplane.com.au>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()
Thread-Topic: question about draft-ietf-6man-rfc3484bis-06.txt and CommonPrefixLen()
Thread-Index: AQHNbSefWPJft5j+MUyaK6aT0cUFA5dCiZ7ggACN6oCAAOeS8A==
Date: Tue, 31 Jul 2012 22:40:03 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7313E1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
References: <1343085852.2796.201.camel@karl> <1343524489.3497.94.camel@karl> <9B57C850BB53634CACEC56EF4853FF653B72ECDD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <1343699165.26898.113.camel@karl>
In-Reply-To: <1343699165.26898.113.camel@karl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.43]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2012 22:40:19 -0000

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Karl Auer
> Sent: Monday, July 30, 2012 6:46 PM
> To: ipv6@ietf.org
> Subject: RE: question about draft-ietf-6man-rfc3484bis-06.txt and
> CommonPrefixLen()
> 
> On Tue, 2012-07-31 at 00:28 +0000, Dave Thaler wrote:
> > The bits in the interface identifier are not indicative of goodness or
> > appropriateness or whatever.
> 
> Firstly, thanks for the extensive explanation.
> 
> I realise now that I was confusing two comparisons - the comparison of an
> address with a prefix in the policy table and the comparison of two addresses
> with each other.
> 
> Comparing an address with a prefix in the policy table must continue for as
> many bits as are specified for the prefix in the policy table.
> 
> Is that understanding correct? 

That is correct.  The CommonPrefixLen(). algorithm is only relevant in the context of rules
that explicitly say so.   Prefix policy table lookups are not in that category

> If so, given the redefinition of
> CommonPrefixLen(), do the definitions of Label() and Precedence() need to
> make this point explicit?

My opinion: no, it already seems explicit enough to me.

> > 1) explicitly add Rule 9 which is already implied.
> 
> Is it? In the fourth paragraph of Section 5, the draft says
> 
>      If the eight rules fail to choose a single address,
>      the tie-breaker is implementation-specific.

True.   I forgot that, so no editorial change is needed, it's already explicit
as you point out.

> I suppose one could say that since the draft does not specify an initial
> ordering, the ordering is implementation-specific, so therefore the tie-
> breaker is implementation specific :-) but that's not really the point. If the
> draft wants the ordering to be the tie-breaker I think it has to say so
> explicitly, as that would then exclude other tie-breaking mechanisms.
>
> It seems to me that the draft should be left as it is in this respect, and thus
> allow an implementation to use the original ordering if it wants to, but not
> demand it or expect it.

Agreed.

So the only editorial change we could consider is adding a sentence to
Appendix B noting the source rule was affected by the change as well.

-Dave

> Regards, K.
> 
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~~~~~~~~~~~
> Karl Auer (kauer@biplane.com.au)
> http://www.biplane.com.au/kauer
> http://www.biplane.com.au/blog
> 
> GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old
> fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687