Re: [addr-select-dt] draft-ietf-6man-rfc3484-revise-02

Tim Chown <tjc@ecs.soton.ac.uk> Sun, 27 March 2011 10:30 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: addr-select-dt@core3.amsl.com
Delivered-To: addr-select-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6F33A6910 for <addr-select-dt@core3.amsl.com>; Sun, 27 Mar 2011 03:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level:
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_57=0.6]
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 eWxpi0bgIjlZ for <addr-select-dt@core3.amsl.com>; Sun, 27 Mar 2011 03:30:49 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id 0A81B3A690E for <addr-select-dt@ietf.org>; Sun, 27 Mar 2011 03:30:47 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p2RAWFiK012586; Sun, 27 Mar 2011 11:32:15 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p2RAWFiK012586
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1301221936; bh=/ZDCzvf5wLvG3PqXKVLNPDHbzDk=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=uPACh6o+TrD1QVN+Vh/2L+ZaPXJe+BwdAKTOuoglWAYiUrjWSB6lZCjQKfW7nDiq3 iY1Pj8coMlBqHn/CadQLGGLS+OjbnsXI82yYHNErgyVwf0T/Sk5hBeYyajOKSYh5m1 NtPcHa3Bvqg19crwK53TDODig0s5Rpayn9XHjLDs=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id n2QBWF00356534912j ret-id none; Sun, 27 Mar 2011 11:32:15 +0100
Received: from [192.168.1.12] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p2RAUqD2027471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Mar 2011 11:30:53 +0100
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/mixed; boundary=Apple-Mail-5-792105613
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <7B445611-D061-4659-9C73-DFFCB9783245@gmail.com>
Date: Sun, 27 Mar 2011 11:30:52 +0100
Message-ID: <EMEW3|471ef5b6b8e06f23fdf187e873dd7010n2QBWF03tjc|ecs.soton.ac.uk|E51DE9EE-F4F6-43AF-87EB-84EBB77AF32A@ecs.soton.ac.uk>
References: <3ABDA38B-EC8D-445F-BDB0-9D265794CEE8@nttv6.net> <EE4D601C-D0B8-41A7-B0FF-2B7384C6408E@ecs.soton.ac.uk> <EMEW3|439bf15624adaebf5d25e951e1da714dn2A0Gj03tjc|ecs.soton.ac.uk|EE4D601C-D0B8-41A7-B0FF-2B7384C6408E@ecs.soton.ac.uk> <1C257C96-9461-4C45-B040-51A87E20A499@nttv6.net> <4D8C2BA1.4080308@inetcore.com> <FD4106B1-FF8C-42FF-8A1E-17544D252C8A@nttv6.net> <4D8C7FC3.70507@innovationslab.net> <540FB21B-F604-40CB-B77E-5EFD7EA430BD@nttv6.net> <1E0B43F5-DF5C-4220-ABD5-C3B3A71EA28D@nttv6.net> <7B445611-D061-4659-9C73-DFFCB9783245@gmail.com> <E51DE9EE-F4F6-43AF-87EB-84EBB77AF32A@ecs.soton.ac.uk>
To: Bob Hinden <bob.hinden@gmail.com>
X-Mailer: Apple Mail (2.1082)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n2QBWF003565349100; tid=n2QBWF00356534912j; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p2RAWFiK012586
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] draft-ietf-6man-rfc3484-revise-02
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Mar 2011 10:30:51 -0000

Hi all,

Here's a version of the slides including two slides to clarify where all the drafts stand (i.e. we'd like to push the 3484-bis and DHCP distribution drafts to WGLC together, and the other drafts can expire, with v6ops taking up multihoming-wthout-nat66).     Also minor tweaks to the other slides.

I am fine to present, but also very happy for Suresh to do so.

Tim


On 27 Mar 2011, at 10:53, Bob Hinden wrote:

> Arifumi-san,
> 
> Thanks for the slides.
> 
> Is Suresh going to do the presentation?
> 
> Thanks,
> Bob
> 
> On Mar 27, 2011, at 11:39 AM, Arifumi Matsumoto wrote:
> 
>> I put together slides for Monday.
>> Please take a look at the attached file.
>> 
>> It looks Tim did not respond to me, so
>> Suresh may be the only person who is in Prague.
>> 
>> If you have any question about the slides, please ask me.
>> I'll try to be available on jabber.
>> arifumi@jabber.org
>> 
>> Kindest regards,
>> <ietf80-rfc3484.ppt>
>> On 2011/03/26, at 0:27, Arifumi Matsumoto wrote:
>> 
>>> Thanks, Brian.
>>> 
>>> Technical discussion should be moved to 6man ML.
>>> 
>>> 
>>> Let me start another non-technical coordination.
>>> I'lll prepare some slides for Monday session.
>>> Suresh, or Tim,
>>> please make a presentation for me.
>>> Please change the slides anyway you like.
>>> 
>>> Kindest regards,
>>> 
>>> On 2011/03/25, at 20:42, Brian Haberman wrote:
>>> 
>>>> All,
>>>>  This discussion should be occurring on the 6man mailing list.  As
>>>> the chairs noted a few months ago, the DT has completed its task and the
>>>> resulting documents should be discussed with the entire WG.  Please move
>>>> this discussion to the ipv6@ietf.org mailing list so that the entire WG
>>>> can participate.
>>>> 
>>>> Regards,
>>>> Brian & Bob
>>>> 
>>>> On 3/25/11 2:23 AM, Arifumi Matsumoto wrote:
>>>>> Hiromi-san,
>>>>> thank you for your comment.
>>>>> 
>>>>> First of all, you are commenting about the following rule, right ?
>>>>> 
>>>>>>>> 
>>>>>>>> I found this sentence a little clumsy:
>>>>>>>> "When a destination address DA, DB, and the source address of DA
>>>>>>>> Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS
>>>>>>>> round robin load-balancing cannot function. "
>>>>>>>> Maybe it can be written a little more clearly?
>>>>>>> 
>>>>>>> Sorry, writing clear english is always an assignment for me. X(
>>>>>>> 
>>>>>>> How about the following text ?
>>>>>>> 
>>>>>>> "When a destination address DA, DB and the source address S are on the
>>>>>>> same subnet, the present longest matching rule always choose the same
>>>>>>> destination address."
>>>>> 
>>>>> 
>>>>> 
>>>>>> Hi list,
>>>>>> 
>>>>>> I did only read original Arifumi's document.
>>>>>> 
>>>>>> I also feel DA,DB and S description is a little bit confusing.
>>>>>> My understanding is here;
>>>>>> 
>>>>>>         DA(s,d)         DB(s',d')
>>>>>> 
>>>>>>          |              |
>>>>>> subnet P(S,D) -------------------------
>>>>>> 
>>>>>> prefix P is same for DA,DB and it can be described as s == s'. Is this
>>>>>> true?
>>>>> 
>>>>> I failed to see what DA(s,d) means here.
>>>>> Also the meaning of P(S,D).
>>>>> 
>>>>>> If yes, how about write their network factor into small letter?
>>>>> 
>>>>> I appreciate if you can elaborate on this.
>>>>> 
>>>>>> But as for DNS round robin, current major OSs follows RFC3484 Rule9 and
>>>>>> neglect DNS information. RFC3483 rule9 is first and if someone wants to
>>>>>> utilize DNS round robin, 3484 policy table(disable subnet
>>>>>> prioritization) can be changed is the better indication I suppose.
>>>>> 
>>>>> What you mean here is that you want a switch to enable/disable rule 9, 
>>>>> that is the longest matching rule, and want to switch on/off it remotely, right ?
>>>>> 
>>>>> My understanding about this issue of rule 9 is,
>>>>> - This is basically a remote side policy.
>>>>> That is, it should be a server side policy, whether rule 9
>>>>> is preferable or not.
>>>>> - The local network administrator basically does not care about this
>>>>> behavior of destination address selection, as far as the destination
>>>>> site is not in his administration site. 
>>>>> 
>>>>> So, I suppose there is not so much need of local switch of rule 9.
>>>>> What we need to discuss is what the universal rule about longest
>>>>> match should be.
>>>>> 
>>>>>> Informative Referece; http://support.microsoft.com/kb/968920
>>>>>> 
>>>>>> Don't you put some note above that?
>>>>> 
>>>>> Thank you for information.
>>>>> I do not quite understand what this configuration does.
>>>>> If if I put this in my registry, my machine disables rule 9 ?
>>>>> I do not think such a thing is fully described by the word
>>>>> "subnet prioritization" in this page.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>>> 
>>>>>> (2011/03/17 11:31), Arifumi Matsumoto wrote:
>>>>>>> Tim,
>>>>>>> 
>>>>>>> On 2011/03/11, at 9:16, Tim Chown wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I have edited the txt file, largely to tidy up the English in a few places.   There's nothing I disagree with in the text.   So you could diff the file with yours to see if you want to apply the changes.
>>>>>>> 
>>>>>>> Thank you for your review and comments.
>>>>>>> I'm sorry that I could not addressed all issues in -02.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Some other comments:
>>>>>>>> 
>>>>>>>> We don't cite draft-ietf-6man-addr-select-sol-03 or draft-ietf-v6ops-addr-select-req-07 - would this be worth doing?    Should probably have a final pass through those to ensure everything is captured in the 3484 bis text?
>>>>>>> 
>>>>>>> The rfc3484-revise does not mention about the whole problem related to address selection, but it does focus on the present issues for RFC 3484 itself.
>>>>>>> 
>>>>>>> It may be helpful if we mention about the whole problem for the readers to grasp the big picture, too. I'll put some texts about them in the introduction, where problem statement and requirement, and the solution documents will be referenced.
>>>>>>> 
>>>>>>>> Note the address selection considerations reference is now a WG item: draft-ietf-6man-addr-select-considerations-02; this needs updating in your text.
>>>>>>> 
>>>>>>> Applied.
>>>>>>> 
>>>>>>>> 
>>>>>>>> I found this sentence a little clumsy:
>>>>>>>> "When a destination address DA, DB, and the source address of DA
>>>>>>>> Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS
>>>>>>>> round robin load-balancing cannot function. "
>>>>>>>> Maybe it can be written a little more clearly?
>>>>>>> 
>>>>>>> Sorry, writing clear english is always an assignment for me. X(
>>>>>>> 
>>>>>>> How about the following text ?
>>>>>>> 
>>>>>>> "When a destination address DA, DB and the source address S are on the
>>>>>>> same subnet, the present longest matching rule always choose the same
>>>>>>> destination address."
>>>>>>> 
>>>>>>>> Quite a few of the citations (reference labels) appear after the full stops in sentences, not before.   Corrected in the attached text.
>>>>>>> 
>>>>>>> I hope all were corrected.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Do we want to add a rule for 2001:db8:: ?     If 3ffe:: is in there...
>>>>>>> 
>>>>>>> I do not know.
>>>>>>> Do we see 2001:db8:: addresses on a real packets ?
>>>>>>> 
>>>>>>>> And I would still love to see a way to add a rule to put privacy address preference in there.   This would be a great way to help answer the concerns in long email threads currently running in other lists :)
>>>>>>> 
>>>>>>> Do you think it should be addressed in RFC 3484 revision, or in the policy distribution draft, or totally different way ?
>>>>>>> 
>>>>>>> Kindest regards,
>>>>>>> 
>>>>>>>> 
>>>>>>>> Tim
>>>>>>>> 
>>>>>>>> <draft-ietf-6man-rfc3484-revise-02-tc.txt>
>>>>>>>> 
>>>>>>>> On 9 Mar 2011, at 10:38, Arifumi Matsumoto wrote:
>>>>>>>> 
>>>>>>>>> All,
>>>>>>>>> 
>>>>>>>>> here attached the -02 version of RFC 3484 revision work.
>>>>>>>>> I'm very sorry about the long suspension on this item,
>>>>>>>>> despite your commitment on it.
>>>>>>>>> 
>>>>>>>>> If you can comment on it, I think I can incorporate it
>>>>>>>>> before the cut-off.
>>>>>>>>> 
>>>>>>>>> Kindest regards,
>>>>>>>>> 
>>>>>>>>> <draft-ietf-6man-rfc3484-revise-02.txt>
>>>>>>>>> --
>>>>>>>>> Arifumi Matsumoto
>>>>>>>>> NGN System Architecture Project
>>>>>>>>> NTT Service Integration Laboratories
>>>>>>>>> E-mail: arifumi@nttv6.net
>>>>>>>>> TEL +81-422-59-3334 FAX +81-422-59-6364
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> addr-select-dt mailing list
>>>>>>>>> addr-select-dt@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> addr-select-dt mailing list
>>>>>>>> addr-select-dt@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> addr-select-dt mailing list
>>>>>>> addr-select-dt@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> ----------
>>>>>> Ruri Hiromi
>>>>>> INTEC Systems Institute, Inc.
>>>>>> _______________________________________________
>>>>>> addr-select-dt mailing list
>>>>>> addr-select-dt@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> addr-select-dt mailing list
>>>>> addr-select-dt@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>> 
>>>> _______________________________________________
>>>> addr-select-dt mailing list
>>>> addr-select-dt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>> 
>>> 
>>> _______________________________________________
>>> addr-select-dt mailing list
>>> addr-select-dt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>> 
>> _______________________________________________
>> addr-select-dt mailing list
>> addr-select-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>