Re: [mif] WG LC for MIF PS

Marc Blanchet <marc.blanchet@viagenie.ca> Tue, 23 March 2010 16:06 UTC

Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: mif@core3.amsl.com
Delivered-To: mif@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78EFD3A6C59 for <mif@core3.amsl.com>; Tue, 23 Mar 2010 09:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 EdG3v6TwvvYC for <mif@core3.amsl.com>; Tue, 23 Mar 2010 09:06:35 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 861353A6CB4 for <mif@ietf.org>; Tue, 23 Mar 2010 09:06:32 -0700 (PDT)
Received: from dhcp-wireless-open-abg-27-7.meeting.ietf.org (unknown [130.129.27.7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C986C21106; Tue, 23 Mar 2010 12:06:48 -0400 (EDT)
Message-ID: <4BA8E714.80803@viagenie.ca>
Date: Tue, 23 Mar 2010 09:06:44 -0700
From: Marc Blanchet <marc.blanchet@viagenie.ca>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Zhen Cao <zehn.cao@gmail.com>
References: <COL118-W43D1A92D6FAECE336508C6B1310@phx.gbl> <c549bac51003192246t62c91c1cw925afa82aae62d30@mail.gmail.com>
In-Reply-To: <c549bac51003192246t62c91c1cw925afa82aae62d30@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: mif <mif@ietf.org>
Subject: Re: [mif] WG LC for MIF PS
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2010 16:06:36 -0000

Zhen Cao a écrit :
> Dear Authors,
> 
> Some comments below:
> 
> 3.1 Below IP Interaction
> Do we need to consider some below-ip layer techniques like Virtual interfaces?

in the first meetings, it was clearly said and agreed that these 
techniques were out of scope of PS.

> 
> 3.4 Address selection
> It is good to mention that some OS like OSX does not implement
> 3484-like policy table. 

This belongs to the current-practices doc.

> Default behavior of the 3484 policy table is
> to prefer IPv6 over IPv4, but this behavior in some situations are not
> optimal and need to be changed.

How much this comment related to MIF? Can you describe a specific scenario?

> 
> 3.5 Finding and Sharing IP Addresses with Peers
> I do not think we need to consider the application referral behavior,
> and it is out of scope of mif. I suggest removing the Grobj referral
> to ip address referral generally.

this is on the contrary to another comment asking to include Grobj, as 
agreed in Hiroshima. See: http://trac.tools.ietf.org/wg/mif/trac/ticket/4

> 
> 4.1, bullet 6,
> it is not a dns selection problem, rather it is the address selection problem.
> The dns selection problem related to DNS64 is covered in
> draft-wing-behave-dns64-config-02.

draft-wing-behave-dns64-config covers issues about a least preferable 
path for a dual-stack host on a shared v6 network with DNS64/NAT64 to 
reach a v4 destination. It has nothing to do with multiple interfaces.

Can you provide a specific MIF scenario that brings another issue that 
is not related to the current text in 4.1 bullet 6?

> 
> a typo here is "quaranteed", should be "guaranteed"
> 

thanks.

> 4.3 Address Selection Policy
> I suggest add some text on IP family selection as one bullet, some
> symptoms are introduced in draft-cao-mif-ifs.
> 
> "The inconsistency of host's application IP family, interface address
> family and remote end's IP family makes the IP family selection
> problem difficult. 

Can you be more explicit on the issue with MIF? This looks a generic 
statement about address selection, not related to MIF.

> Wrongly choosing the ip family will result into
> communication failure. "


Thanks for the comments, Marc.

> 
> 
> Thanks,
> Zhen
> 
> 2010/3/12 Hui Deng <denghui02@hotmail.com>:
>> We appear ready to start the working group last call for our PS documents.
>> This is a two-week WGLC.
>> http://www.ietf.org/id/draft-ietf-mif-problem-statement-02.txt
>>
>> This is a two week WGLC finishing on March 26.  Please send substantive
>> review comments to mif@ietf.org
>>
>> Thanks,
>>
>> -Hui
>>
>> ________________________________
>> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.
>> _______________________________________________
>> mif mailing list
>> mif@ietf.org
>> https://www.ietf.org/mailman/listinfo/mif
>>
>>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif


-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca