IETF Logo Mail Archive

Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option

<teemu.savolainen@nokia.com> Fri, 04 January 2013 07:01 UTC

Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5732021F8D75 for <pcp@ietfa.amsl.com>; Thu, 3 Jan 2013 23:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.3
X-Spam-Level:
X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShiqguD1ev0i for <pcp@ietfa.amsl.com>; Thu, 3 Jan 2013 23:01:19 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id AD2C421F8D6F for <pcp@ietf.org>; Thu, 3 Jan 2013 23:01:19 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0471HbV003663; Fri, 4 Jan 2013 09:01:18 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jan 2013 09:01:17 +0200
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.88]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0318.003; Fri, 4 Jan 2013 07:01:16 +0000
From: teemu.savolainen@nokia.com
To: repenno@cisco.com, pcp@ietf.org
Thread-Topic: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option
Thread-Index: Ac3qR6Uh+Ye6uFudTa6KVzvjdr/IlQ==
Date: Fri, 04 Jan 2013 07:01:16 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696204550473@008-AM1MPN1-053.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Imb/kNG8e5MBaAZCGWp2zCe0v9E1GtLYFx/mmaG63icvzPS1iHxB2K1yqR0VpN7cv/EmsYF9McaF8wAjzWwn0XCQ1cMud0xxO50muisYCbVtbSJuf839WbbDjFnK7nQFQSVii7ReQtf3v9rFNt+UQVb9T/eJOp9tBpkQsa7V7YMQj7vMc/Cn81LuF8euhw9+R2Ns5b2UOHdbdSKEXfMyMTjuN8iqONc5zd5KlPXnpF+JzVp6kcPHhsbd1QALBkKPN9ZDBiyTBDaRkPBwyGNXxbk=
x-originating-ip: [10.163.162.189]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2013 07:01:17.0408 (UTC) FILETIME=[4AEB9E00:01CDEA49]
X-Nokia-AV: Clean
Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jan 2013 07:01:20 -0000

Hi,

If the PCP server readily has information about Pref64::/n, then why not tell that to PCP client indeed. But if it has not, then I would ask what is the benefit of defining PCP option instead of DHCPv6 option?

In the Behave WG we have been working on analysis of different Pref64::/n discovery tools, currently in RFC Editor:  http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03

The Behave's work resulted in heuristic approach being selected, which is currently in AD evaluation: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-13

Should this document formally update learn-analysis and have a section with similar analysis, stating pros and cons and then concluding why it is useful to have this solution for PCP deployment scenarios?

In this document I would like to see text talking about relation to said analysis document and heuristic approach. For example, if a host does Pref64::/n discovery with heuristic approach for its generic use (such as local AAAA record synthesis), is there utility for SIP client to perform separate discovery also with PCP client?

Nit: the IPv4-only SIP UA can be IPv4-only, but terminology about IPv6-only SIP UE is not that accurate IMHO: the draft's SIP UA in IPv6-only *access* seems to be quite capable of understanding IPv4-world (adding IPv4 addresses to SDP offer), hence maybe better say SIP UA in IPv6-only access, instead of IPv6-only SIP UA?

Best regards,

	Teemu



> -----Original Message-----
> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> ext Reinaldo Penno (repenno)
> Sent: 03. tammikuuta 2013 01:30
> To: pcp@ietf.org
> Subject: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-
> option
> 
> Hello,
> 
> First of all, Happy new Year!
> 
> Based on the discussions at IETF Atlanta Meeting we would like to start call of
> adoption on a few drafts, with the first one below.
> 
> This email starts a 2-week consensus call on adopting
> 
>      Title           : Learn NAT64 PREFIX64s using PCP
>      Author(s)       : M. Boucadair
>      Filename        : draft-boucadair-pcp-nat64-prefix64-option-02.txt
>      URL             :
> http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.txt
> 
> Please read the current revision and state you opinion either for or against
> adoption (and with reasoning why) in the mailing list. The call for adoption
> ends 16th January 2013.
> 
> 
> Thanks,
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp

v2.23.0 | Report a Bug | By Email