From dwing@cisco.com Mon Jul 2 13:36:43 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA8911E80E7 for ; Mon, 2 Jul 2012 13:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.438 X-Spam-Level: X-Spam-Status: No, score=-110.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 93XI7cgxtls5 for ; Mon, 2 Jul 2012 13:36:42 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8858311E8112 for ; Mon, 2 Jul 2012 13:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2421; q=dns/txt; s=iport; t=1341261408; x=1342471008; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=f6oTmFGTaVvyo0+26ktb2DLgTIavGwNhg50XW5Sz/zc=; b=euhVsBS8hdAIKk4CoFXdRruLSXIxNku3lN+oU2/hm8e8JrztkZFIe7g7 RWc2Ewgjc+4vtBMOs3YUfEQ9QbNe3/3yeVcc8Gc7Lo2DE88bG8FK7Rq// grmwTHHIG/HmSm+JGCoW9NeAnytUOIZhsd9zQui5X1m1sVUOiLF/BDH6T A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFANkF8k+rRDoI/2dsb2JhbABFp0mPGYEHghgBAQEEAQEBBQoBCg0QNBcBAwIJDwIEAQEBIwQHGQ4VCgkIAQEEARIJAhAHh2gMmlSgP4s7hhoDiEqFBIh4jQuBZoJ/ X-IronPort-AV: E=Sophos;i="4.77,512,1336348800"; d="scan'208";a="50765193" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Jul 2012 20:36:47 +0000 Received: from dwingWS (sjc-vpn7-1810.cisco.com [10.21.151.18]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q62Kaltm019608; Mon, 2 Jul 2012 20:36:47 GMT From: "Dan Wing" To: "'Suresh Krishnan'" , "'Internet Area'" References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> In-Reply-To: <4FEB2D67.1010901@ericsson.com> Date: Mon, 2 Jul 2012 13:36:47 -0700 Message-ID: <046101cd5892$668f76c0$33ae6440$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1Ufapko5JBcNiIT4WXiSzGWKyagQEE9pPg Content-Language: en-us Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 20:36:43 -0000 I support draft-ietf-intarea-nat-reveal-analysis going forward. I would like the draft to include a citation of MAP (draft-ietf-softwire-map), and mention MAP in its abstract. This is because many technologists assume address sharing only occurs with NAT, even though it occurs with a bunch of other technologies. On this point, I noticed "application proxies" is mentioned in the abstract (which is good), but application proxies are not mentioned again in the introduction to draft-ietf-intarea-nat-reveal-analysis nor mentioned in RFC6269 ("Issues with IP Address Sharing"). -d > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: Wednesday, June 27, 2012 8:57 AM > To: Internet Area > Subject: [Int-area] ACTION REQUIRED: Extending working group last call > for draft-ietf-intarea-nat-reveal-analysis-02 > > Hi all, > The WGLC on this draft ended with no comments at all. In this > context, > we cannot assume that silence equates to consent. In order for this > draft to progress, we need people to read the draft and provide their > opinions on whether the draft is ready. To enable people to comment, > the > last call period is extended until Friday July 6, 2012. > > Thanks > Suresh and Julien > > On 06/08/2012 10:06 AM, Suresh Krishnan wrote: > > Hi all, > > This message starts a two week intarea working group last call on > > advancing the draft about Analysis of Solution Candidates to Reveal a > > Host Identifier (HOST_ID) in Shared Address Deployments as an > > Informational RFC. The draft is available at > > > > http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt > > http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 > > > > Substantive comments and statements of support/opposition for > advancing > > this document should be directed to the mailing list. Editorial > > suggestions can be sent directly to the authors. This last call will > > conclude on June 22, 2012. > > > > Regards, > > Suresh & Julien > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From acooper@cdt.org Thu Jul 5 13:48:40 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E7F21F85F6 for ; Thu, 5 Jul 2012 13:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, 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 B3fA6uE7rLPX for ; Thu, 5 Jul 2012 13:48:39 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 60C1421F85E7 for ; Thu, 5 Jul 2012 13:48:39 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 5 Jul 2012 16:48:44 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alissa Cooper In-Reply-To: <4FEB2D67.1010901@ericsson.com> Date: Thu, 5 Jul 2012 16:48:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41BC9D97-A168-43C1-BC0F-4F7CEA9CC0A7@cdt.org> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: Internet Area Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 20:48:40 -0000 With the changes to this draft in the -02 version, I'm having a little = trouble seeing its purpose. It basically now seems like a shell for the = recommendation in 3.3, with the analysis stuffed into appendices. But = given that there is no stable proposal for the actual TCP option to be = implemented, what is the purpose for advancing this document right now? = I think I've heard that folks "needed to know what to implement," but = does this document really resolve that problem given that even within = the space of TCP-option-based solutions for this, there are multiple = different proposals, none of which has been standardized? This document = made more sense when it was just a comparison of the different potential = solutions spaces. Some other comments: Section 2 claims that for all solutions analyzed, the draft explains = what the HOST_ID is. I don't think this is true for the TCP option = solution for the application header solution. Even the specific solution = proposals for both of those (draft-wing-nat-reveal-option or = draft-ietf-appsawg-http-forwarded) are not specific about the limits to = which IDs can be inserted. Section 3.1: Is this really specifying requirements for all solutions? = Is that sort of a self-fulfilling prophecy for a document that already = has a solution chosen? Given that the Forwarded header is being standardized, it seems like = references to XFF should be reduced to places where existing deployments = are being discussed (as opposed to encouraging the use of XFF, e.g., in = A.8.1, "service providers...can enable the feature of injecting the XFF = header").=20 As a general matter I think it would be helpful for this document to be = reviewed by some appsarea folks and/or the authors of = draft-ietf-appsawg-http-forwarded. It seems like A.8.1 and A.8.2 = contradict each other about whether header information is preserved = through multiple address sharing functions. Also, if XFF is in such = widespread use, the question of what to do when the TCP option and the = XFF header conflict seems like something that needs to be resolved. It seems odd to reference "earlier versions" of = draft-wing-nat-reveal-option in A.5.2 rather than just explaining why = this option is limited to SYN. This seems like an artifact of the = oddness of having a whole document just to recommend an = as-yet-unspecified solution. Cheers, Alissa On Jun 27, 2012, at 11:57 AM, Suresh Krishnan wrote: > Hi all, > The WGLC on this draft ended with no comments at all. In this = context, > we cannot assume that silence equates to consent. In order for this > draft to progress, we need people to read the draft and provide their > opinions on whether the draft is ready. To enable people to comment, = the > last call period is extended until Friday July 6, 2012. >=20 > Thanks > Suresh and Julien >=20 > On 06/08/2012 10:06 AM, Suresh Krishnan wrote: >> Hi all, >> This message starts a two week intarea working group last call on >> advancing the draft about Analysis of Solution Candidates to Reveal a >> Host Identifier (HOST_ID) in Shared Address Deployments as an >> Informational RFC. The draft is available at >>=20 >> http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt >> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 >>=20 >> Substantive comments and statements of support/opposition for = advancing >> this document should be directed to the mailing list. Editorial >> suggestions can be sent directly to the authors. This last call will >> conclude on June 22, 2012. >>=20 >> Regards, >> Suresh & Julien >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From touch@isi.edu Thu Jul 5 16:55:04 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7E421F86D1 for ; Thu, 5 Jul 2012 16:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.593 X-Spam-Level: X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, 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 LtgtnmKLTe5N for ; Thu, 5 Jul 2012 16:55:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id CE34421F86C7 for ; Thu, 5 Jul 2012 16:55:00 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q65NsfxK010605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2012 16:54:41 -0700 (PDT) Message-ID: <4FF62941.7090300@isi.edu> Date: Thu, 05 Jul 2012 16:54:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Dan Wing References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <046101cd5892$668f76c0$33ae6440$@com> In-Reply-To: <046101cd5892$668f76c0$33ae6440$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'Internet Area' Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 23:55:05 -0000 BTW, the MAP doc cites RFC 6145, which has errors as follows: 1. it sets IPv4 ID=0 when IPv6 lacks a frag header that will hopefully be possible after ipv4-id-update is final, but wasn't valid a the time the doc was published 2. copying the low 16 bits of the IPv6 ID field to the IPv4 ID field is invalid that field might not follow the ID uniqueness criteria of IPv4 3. the system assumes IPv4 can reassemble 1280 byte packets but only 576 can be assumed I've brought these to the attention of the authors... Joe On 7/2/2012 1:36 PM, Dan Wing wrote: > I support draft-ietf-intarea-nat-reveal-analysis going forward. > > I would like the draft to include a citation of MAP > (draft-ietf-softwire-map), and mention MAP in its abstract. This is because > many technologists assume address sharing only occurs with NAT, even though > it occurs with a bunch of other technologies. On this point, I noticed > "application proxies" is mentioned in the abstract (which is good), but > application proxies are not mentioned again in the introduction to > draft-ietf-intarea-nat-reveal-analysis nor mentioned in RFC6269 ("Issues > with IP Address Sharing"). > > -d > > >> -----Original Message----- >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of Suresh Krishnan >> Sent: Wednesday, June 27, 2012 8:57 AM >> To: Internet Area >> Subject: [Int-area] ACTION REQUIRED: Extending working group last call >> for draft-ietf-intarea-nat-reveal-analysis-02 >> >> Hi all, >> The WGLC on this draft ended with no comments at all. In this >> context, >> we cannot assume that silence equates to consent. In order for this >> draft to progress, we need people to read the draft and provide their >> opinions on whether the draft is ready. To enable people to comment, >> the >> last call period is extended until Friday July 6, 2012. >> >> Thanks >> Suresh and Julien >> >> On 06/08/2012 10:06 AM, Suresh Krishnan wrote: >>> Hi all, >>> This message starts a two week intarea working group last call on >>> advancing the draft about Analysis of Solution Candidates to Reveal a >>> Host Identifier (HOST_ID) in Shared Address Deployments as an >>> Informational RFC. The draft is available at >>> >>> http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt >>> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 >>> >>> Substantive comments and statements of support/opposition for >> advancing >>> this document should be directed to the mailing list. Editorial >>> suggestions can be sent directly to the authors. This last call will >>> conclude on June 22, 2012. >>> >>> Regards, >>> Suresh & Julien >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From touch@isi.edu Thu Jul 5 17:17:27 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8187221F8717 for ; Thu, 5 Jul 2012 17:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, 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 0AVPR4DaUABg for ; Thu, 5 Jul 2012 17:17:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E143821F8707 for ; Thu, 5 Jul 2012 17:17:26 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q660HRTk013097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2012 17:17:27 -0700 (PDT) Message-ID: <4FF62E97.3070301@isi.edu> Date: Thu, 05 Jul 2012 17:17:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Suresh Krishnan References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> In-Reply-To: <4FEB2D67.1010901@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 00:17:27 -0000 As a co-author, I didn't want to remain silent per se, so I'll at least be public in my view. I think the doc is good, but I do take Alissa's concerns to point - it might be preferable to remove section 3.3 and leave this doc as a comparison of solutions, and avoid any recommendation of a way forward at this point. Joe On 6/27/2012 8:57 AM, Suresh Krishnan wrote: > Hi all, > The WGLC on this draft ended with no comments at all. In this context, > we cannot assume that silence equates to consent. In order for this > draft to progress, we need people to read the draft and provide their > opinions on whether the draft is ready. To enable people to comment, the > last call period is extended until Friday July 6, 2012. > > Thanks > Suresh and Julien > > On 06/08/2012 10:06 AM, Suresh Krishnan wrote: >> Hi all, >> This message starts a two week intarea working group last call on >> advancing the draft about Analysis of Solution Candidates to Reveal a >> Host Identifier (HOST_ID) in Shared Address Deployments as an >> Informational RFC. The draft is available at >> >> http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt >> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 >> >> Substantive comments and statements of support/opposition for advancing >> this document should be directed to the mailing list. Editorial >> suggestions can be sent directly to the authors. This last call will >> conclude on June 22, 2012. >> >> Regards, >> Suresh & Julien >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From lars@netapp.com Fri Jul 6 00:39:42 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCFD21F8738 for ; Fri, 6 Jul 2012 00:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.411 X-Spam-Level: X-Spam-Status: No, score=-10.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 33fXOmxGbsut for ; Fri, 6 Jul 2012 00:39:42 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1003B21F870F for ; Fri, 6 Jul 2012 00:39:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,536,1336374000"; d="p7s'?scan'208";a="660288771" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 06 Jul 2012 00:39:42 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q667dgaG000617; Fri, 6 Jul 2012 00:39:42 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0298.004; Fri, 6 Jul 2012 00:39:41 -0700 From: "Eggert, Lars" To: Alissa Cooper Thread-Topic: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: AQHNWu+ojYqG7aQYS0K2VtPas5PG35ccVHwA Date: Fri, 6 Jul 2012 07:39:41 +0000 Message-ID: <87110043-46CA-40BA-B67C-9368AB53D7CA@netapp.com> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <41BC9D97-A168-43C1-BC0F-4F7CEA9CC0A7@cdt.org> In-Reply-To: <41BC9D97-A168-43C1-BC0F-4F7CEA9CC0A7@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_8E9DCA55-1939-42D1-B525-C174DF7A248D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 07:39:43 -0000 --Apple-Mail=_8E9DCA55-1939-42D1-B525-C174DF7A248D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 5, 2012, at 22:48, Alissa Cooper wrote: > With the changes to this draft in the -02 version, I'm having a little = trouble seeing its purpose. It basically now seems like a shell for the = recommendation in 3.3, with the analysis stuffed into appendices. But = given that there is no stable proposal for the actual TCP option to be = implemented, what is the purpose for advancing this document right now? = I think I've heard that folks "needed to know what to implement," but = does this document really resolve that problem given that even within = the space of TCP-option-based solutions for this, there are multiple = different proposals, none of which has been standardized? This document = made more sense when it was just a comparison of the different potential = solutions spaces. Fully agree with Alissa. An comparison of options would be fine. But 3.3 = and other text go beyond a comparison. I also don't understand why INTAREA is entertaining work that is clearly = intending to define new TCP options. None of the -abdo- drafts have been = presented in TCPM or even discussed on the mailing list. (My guess is = that the authors know that this would never get traction in TCPM and are = venue shopping.) Lars= --Apple-Mail=_8E9DCA55-1939-42D1-B525-C174DF7A248D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcwNjA3Mzk0MlowIwYJKoZIhvcNAQkEMRYEFMYH +S9CoVwS4/ptAZ9WbX/xOsziMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAA3/BcDc N40r5B2GbeodYVpmnaewoblVzEZ+NHaM3wsgmUmzOgyOZ4fxXBRUHtlKoRvPsfCFDY4lbar5cBUZ 5hl2Mjk10H6ZxBuoOoJ/K3qdgfVbmCWQcJom0J8gefIFPVtssbMZhYkqpAOnyNceJWddbDqkbrJk Anm2Ijq8VqZHWDfpf4WfC06uv1n12bDLPj0/ZafJG+FnvqOxQHLg02Q1cqiDlFXnmiGGn3LAjXm2 NuUoc3SBug7k8ao/8OV4CDuanPM68ghG4GKUftloQC8D9ifi1qsMrWqmD1Kb/gwCMqYqVYRBltDw FWoHVpvtZ+F28KNOdFxVjVsKAe1SYjQAAAAAAAA= --Apple-Mail=_8E9DCA55-1939-42D1-B525-C174DF7A248D-- From touch@isi.edu Fri Jul 6 15:30:13 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09B511E80B7 for ; Fri, 6 Jul 2012 15:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=-0.954, BAYES_00=-2.599, 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 yDI19JFsyP6Q for ; Fri, 6 Jul 2012 15:30:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9C011E80B3 for ; Fri, 6 Jul 2012 15:30:12 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q66MTjvS002688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2012 15:29:45 -0700 (PDT) Message-ID: <4FF766D9.3020900@isi.edu> Date: Fri, 06 Jul 2012 15:29:45 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Eggert, Lars" References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <41BC9D97-A168-43C1-BC0F-4F7CEA9CC0A7@cdt.org> <87110043-46CA-40BA-B67C-9368AB53D7CA@netapp.com> In-Reply-To: <87110043-46CA-40BA-B67C-9368AB53D7CA@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 22:30:14 -0000 On 7/6/2012 12:39 AM, Eggert, Lars wrote: > On Jul 5, 2012, at 22:48, Alissa Cooper wrote: >> With the changes to this draft in the -02 version, I'm having a little trouble seeing its purpose. It basically now seems like a shell for the recommendation in 3.3, with the analysis stuffed into appendices. But given that there is no stable proposal for the actual TCP option to be implemented, what is the purpose for advancing this document right now? I think I've heard that folks "needed to know what to implement," but does this document really resolve that problem given that even within the space of TCP-option-based solutions for this, there are multiple different proposals, none of which has been standardized? This document made more sense when it was just a comparison of the different potential solutions spaces. > > Fully agree with Alissa. An comparison of options would be fine. But 3.3 and other text go beyond a comparison. > > I also don't understand why INTAREA is entertaining work that is > clearly intending to define new TCP options. None of the -abdo- drafts > have been presented in TCPM or even discussed on the mailing list. (My > guess is that the authors know that this would never get traction in > TCPM and are venue shopping.) FWIW, this doc discusses existing alternatives, including proposed ones that have been documented, based on pros/cons. It doesn't make an assessment of the viability of approaches as ways forward in the IETF. (and I agree it should probably not make any single positive recommendation; it might be OK to indicate which solutions aren't viable, though) Joe From sm@resistor.net Sat Jul 7 01:43:50 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0249D21F84C8 for ; Sat, 7 Jul 2012 01:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 WpeqwhxikPLz for ; Sat, 7 Jul 2012 01:43:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CD221F84C9 for ; Sat, 7 Jul 2012 01:43:45 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q678hulF005690 for ; Sat, 7 Jul 2012 01:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1341650643; bh=4TtOMne6K9NfteKZ8CXGdmahRCHtKJi0diGhjsQE79s=; h=Date:To:From:Subject:Cc; b=Ju6KnnPhNIscNyfpnSg5omhm8kGBD8Bw5i90vyGYmxnWoxEtOGHxrZ0o5g/uNudAK ELfMidVWppJyDurUGk/9rSKnewqiwrgyITJxsOlJVI8CyjAC3hwBkKZ972iunJhVa0 3VDXSvBF/UNa/8qHMDVY497Mix4Dx71TZlDiPdps= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1341650643; i=@resistor.net; bh=4TtOMne6K9NfteKZ8CXGdmahRCHtKJi0diGhjsQE79s=; h=Date:To:From:Subject:Cc; b=wsFg6MQww9EbvPfqv3EWhg7ia9hx0pzf2DrNi5Y0+y3YRtAWhVvWKe00kgyY3xMv8 efE2a6MuVUoniqZzmewjtG3DIcGTP0mpPV06R8pYZbrUsg3QCWav/TNe34RqinqNaI o+fzAjYH/SlDw/aRoMA0i7xBc7PVSiLbMIFMQQQ4= Message-Id: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Jul 2012 01:40:35 -0700 To: int-area@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 08:43:50 -0000 Hello, I have a few comments on draft-ietf-intarea-nat-reveal-analysis-02. In Section 1.1: "Examples of such issues are listed below:" "Redirect users with infected machines to a dedicated portal" Why is this an issue? "The risk of not mitigating these issues are: OPEX increase for IP" I suggest expanding "OPEX" on first use. In Section 2: "Tomorrow, due to the introduction of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that address will be shared." Isn't IPv4 shared addresses already in use in the wild? In Section 2.1: "A solution to reveal HOST_ID is also needed in IPv6 deployment." I suggest soliciting feedback from V6OPS about this. The draft already mentions that the issue is caused by IPv4 address sharing. It then goes on to suggest that address sharing can be used for IPv6. That is going to create the same problem there and argue for the solution mentioned in this draft. In Section 3.2: "Requires the client and the server to be HIP-compliant and HIP infrastructure to be deployed." What's HIP? "XFF is de facto standard deployed and supported in operational networks" What's XFF? "From an application standpoint, the TCP Option is superior to XFF/ Forwarded-For since it is not restricted to HTTP." That doesn't sound like a fair comparison. "Nevertheless XFF/Forwarded-For is compatible with the presence of address sharing and load-balancers in the communication path." What is the meaning of compatible in here? In Section 4: "some users realize privacy benefits associated with IP address sharing, and some may even take steps to ensure that NAT functionality sits between them and the public Internet." What are the privacy benefits of IP address sharing? In skimmed over the appendix. What's "Application Headers"? This draft would benefit from cross-area review. It needs more work in my humble opinion. Regards, -sm From Tina.Tsou.Zouting@huawei.com Mon Jul 9 13:42:58 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787EA11E81F5 for ; Mon, 9 Jul 2012 13:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] 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 wOJL3HIFrdXU for ; Mon, 9 Jul 2012 13:42:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7829911E81EF for ; Mon, 9 Jul 2012 13:42:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW43248; Mon, 09 Jul 2012 16:43:23 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 13:41:25 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.208]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 13:41:24 -0700 From: Tina TSOU To: SM Thread-Topic: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: AQHNXByyM3mdKgCxJ0+Gdsg8DCXcdJchbi/M Date: Mon, 9 Jul 2012 20:41:23 +0000 Message-ID: <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> In-Reply-To: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6CB5FBBD0FB24F80A29B138AB723D38Dhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:42:58 -0000 --_000_6CB5FBBD0FB24F80A29B138AB723D38Dhuaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I reviewed this draft and I found it very detailed about the various ways o= f including a HOST ID. Considering the number of users that share the same = IPv4 address, there is an increasing importance of the HOST ID. Though it i= s discussed in the introduction about the various implications of not havin= g HOST IDs, in my opinion, there should be a little more explanation of the= problems faced if there is no HOST ID included. Moreover, the main concern= is security issue. It is very difficult to identify a particular user, whe= n there are a number of users with different private IP addresses sharing t= he same public address. This document has very well explained the pros and cons of various methods = of including the HOST ID. Among all the methods, the best one in my perspec= tive would be to assign a port set dynamically to a particular user. As reg= ards to the statement =93it contradicts RFC 6269=94, about the randomizatio= n of port allocation, the user can be allocated port set dynamically for a = specific life time. The use of dynamic allocation ensures maximum utilizati= on of port sets, as static allocation would lead to some ports being alloca= ted but not being used. The port set allocation has more advantages than re= st of the options and should be more detailed than the ones with more cons. The TCP option is another good way to include the HOST ID in case of TCP an= d UDP communications. So if the document was written more based on applicat= ions, it would be more specific and user friendly. Considering the exhausti= on of IPv4, I also feel IPv6 should be more stresses upon and included as a= n option, as IPv6 would solve the problem to a great extend. Including IPv6= might not exactly serve the purpose of the document, but would definitely = be an alternative to mitigate the issue. Tina On Jul 7, 2012, at 1:44 AM, "SM" > = wrote: Hello, I have a few comments on draft-ietf-intarea-nat-reveal-analysis-02. In Section 1.1: "Examples of such issues are listed below:" "Redirect users with infected machines to a dedicated portal" Why is this an issue? "The risk of not mitigating these issues are: OPEX increase for IP" I suggest expanding "OPEX" on first use. In Section 2: "Tomorrow, due to the introduction of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that address will be shared." Isn't IPv4 shared addresses already in use in the wild? In Section 2.1: "A solution to reveal HOST_ID is also needed in IPv6 deployment." I suggest soliciting feedback from V6OPS about this. The draft already mentions that the issue is caused by IPv4 address sharing= . It then goes on to suggest that address sharing can be used for IPv6. T= hat is going to create the same problem there and argue for the solution me= ntioned in this draft. In Section 3.2: "Requires the client and the server to be HIP-compliant and HIP infrastructure to be deployed." What's HIP? "XFF is de facto standard deployed and supported in operational networks" What's XFF? "From an application standpoint, the TCP Option is superior to XFF/ Forwarded-For since it is not restricted to HTTP." That doesn't sound like a fair comparison. "Nevertheless XFF/Forwarded-For is compatible with the presence of address sharing and load-balancers in the communication path." What is the meaning of compatible in here? In Section 4: "some users realize privacy benefits associated with IP address sharing, and some may even take steps to ensure that NAT functionality sits between them and the public Internet." What are the privacy benefits of IP address sharing? In skimmed over the appendix. What's "Application Headers"? This draft would benefit from cross-area review. It needs more work in my = humble opinion. Regards, -sm _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area --_000_6CB5FBBD0FB24F80A29B138AB723D38Dhuaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I reviewed this draft and I found it very detailed about the var= ious ways of including a HOST ID. Considering the number of users that shar= e the same IPv4 address, there is an increasing importance of the HOST ID. = Though it is discussed in the introduction about the various implications of not having HOST IDs, in my opinion, ther= e should be a little more explanation of the problems faced if there is no = HOST ID included. Moreover, the main concern is security issue. It is very = difficult to identify a particular user, when there are a number of users with different private IP addresses= sharing the same public address.
 
This document has very well explained the pros and cons of various met= hods of including the HOST ID. Among all the methods, the best one in my pe= rspective would be to assign a port set dynamically to a particular user. A= s regards to the statement =93it contradicts RFC 6269=94, about the randomization of port allocation, the user can be a= llocated port set dynamically for a specific life time. The use of dynamic = allocation ensures maximum utilization of port sets, as static allocation w= ould lead to some ports being allocated but not being used. The port set allocation has more advantages than rest = of the options and should be more detailed than the ones with more cons.
 
The TCP option is another good way to include the HOST ID in cas= e of TCP and UDP communications. So if the document was written more based = on applications, it would be more specific and user friendly. Considering t= he exhaustion of IPv4, I also feel IPv6 should be more stresses upon and included as an option, as IPv6 would= solve the problem to a great extend. Including IPv6 might not exactly serv= e the purpose of the document, but would definitely be an alternative to mi= tigate the issue. 

Tina

On Jul 7, 2012, at 1:44 AM, "SM" <sm@resistor.net> wrote:

Hello,

I have a few comments on draft-ietf-intarea-nat-reveal-analysis-02.

In Section 1.1:

 "Examples of such issues are listed below:"
   "Redirect users with infected machines to a de= dicated portal"

Why is this an issue?

 "The risk of not mitigating these issues are: OPEX increas= e for IP"

I suggest expanding "OPEX" on first use.

In Section 2:

 "Tomorrow, due to the introduction of CGNs (e.g., NAT44
  [RFC3022], NAT64 [RFC6146]), that address will be shared.= "

Isn't IPv4 shared addresses already in use in the wild?

In Section 2.1:

 "A solution to reveal HOST_ID is also needed in IPv6 deplo= yment."

I suggest soliciting feedback from V6OPS about this.

The draft already mentions that the issue is caused by IPv4 address s= haring.  It then goes on to suggest that address sharing can be used f= or IPv6.  That is going to create the same problem there and argue for= the solution mentioned in this draft.

In Section 3.2:

 "Requires the client and the server to be HIP-compliant an= d HIP
  infrastructure to be deployed."

What's HIP?

 "XFF is de facto standard deployed and supported in operat= ional
  networks"

What's XFF?

 "From an application standpoint, the TCP Option is superio= r to XFF/
  Forwarded-For since it is not restricted to HTTP."

That doesn't sound like a fair comparison.

 "Nevertheless XFF/Forwarded-For is compatible with the pre= sence of
  address sharing and load-balancers in the communication p= ath."

What is the meaning of compatible in here?

In Section 4:

 "some users realize privacy benefits associated with IP ad= dress
  sharing, and some may even take steps to ensure that NAT<= /span>
  functionality sits between them and the public Internet.&= quot;

What are the privacy benefits of IP address sharing?

In skimmed over the appendix.  What's "Application Headers&= quot;?

This draft would benefit from cross-area review.  It needs more = work in my humble opinion.

Regards,
-sm




_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://ww= w.ietf.org/mailman/listinfo/int-area
--_000_6CB5FBBD0FB24F80A29B138AB723D38Dhuaweicom_-- From brian@innovationslab.net Mon Jul 9 15:45:15 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6321F8606 for ; Mon, 9 Jul 2012 15:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2bXN-EZbOaMU for ; Mon, 9 Jul 2012 15:45:14 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7895821F85F7 for ; Mon, 9 Jul 2012 15:45:14 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8132E88094; Mon, 9 Jul 2012 15:45:40 -0700 (PDT) Received: from clemson.local (h147.118.178.64.static.ip.windstream.net [64.178.118.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 275ED130017; Mon, 9 Jul 2012 15:45:40 -0700 (PDT) Message-ID: <4FFB5F28.2040704@innovationslab.net> Date: Mon, 09 Jul 2012 18:46:00 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: int-area@ietf.org, "int-ads@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] Working group summaries X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 22:45:15 -0000 All, With the Internet Area being large (25 Working Groups) and diverse, it can be time consuming for participants to track the activities that may affect them. To help keep people up to date, we have asked the chairs of each WG within the area to generate a brief update on their WG's progress. These updates will be done at the end of each IETF meeting and posted to the INT Area wiki (http://trac.tools.ietf.org/area/int/trac/wiki). The goal of these summaries is not to give an in-depth assessment of all the happenings within a WG. Rather, it should be a set of highlights that may be of interest to people not actively involved in the WG. We hope that these reports will be useful to the INT Area community. Regards, Brian & Ralph From wes@mti-systems.com Mon Jul 9 16:26:03 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09A11E8120 for ; Mon, 9 Jul 2012 16:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] 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 MUoCfAhOR0HR for ; Mon, 9 Jul 2012 16:26:02 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id 772A111E811A for ; Mon, 9 Jul 2012 16:26:02 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q69NQRRM019874 for ; Mon, 9 Jul 2012 19:26:27 -0400 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [63.226.32.150] ([63.226.32.150:32481] helo=[172.27.250.202]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 71/5F-11934-3A86BFF4; Mon, 09 Jul 2012 19:26:27 -0400 Message-ID: <4FFB689A.90402@mti-systems.com> Date: Mon, 09 Jul 2012 19:26:18 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tina TSOU References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> In-Reply-To: <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 23:26:03 -0000 I read the document and came to rather different conclusions (see below): On 7/9/2012 4:41 PM, Tina TSOU wrote: > I reviewed this draft and I found it very detailed about the various > ways of including a HOST ID. Considering the number of users that share > the same IPv4 address, there is an increasing importance of the HOST ID. > Though it is discussed in the introduction about the various > implications of not having HOST IDs, in my opinion, there should be a > little more explanation of the problems faced if there is no HOST ID > included. Moreover, the main concern is security issue. It is very > difficult to identify a particular user, when there are a number of > users with different private IP addresses sharing the same public address. I agree with you that if the document is pursued, it should include more discussion of what the problems are with not having a host ID; the current text seems like handwaving to me. I don't personally think it is very well motivated, and from my standpoint there is absolutely no reason to pursue a solution. It would be enough to simply have the analysis documented as to why all of the considered approaches COMPLETELY STINK. But aside from that, I disagree with you on purpose of whatever is being attempted here. The document is about identifying hosts, and you mention "users". These are not the same thing. Which do you want to identify? In my opinion, anything related to users (and not hosts) should be completely out of scope. Further, I think the problem has to perhaps be refined to disambiguating between different hosts using the same IP address versus trying to semi-uniquely identify the hosts. The problems described are due to aliasing, and unique identification is a rather strong means of de-aliasing. > The TCP option is another good way to include the HOST ID in case of TCP > and UDP communications. Surely there's a typo there, since it does not work at all in the case of UDP. I disagree with the overall recommendation of the document, since it presumes that a solution is required, among other flaws with it. Additionally, it is not particularly clear how this can work for multiple layers of sharing (e.g. CGN), though draft-abdo seems to think that CGN is a single layer of sharing. -- Wes Eddy MTI Systems From lars@netapp.com Tue Jul 10 01:14:03 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8A21F8569 for ; Tue, 10 Jul 2012 01:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 be5UrqevNANb for ; Tue, 10 Jul 2012 01:14:01 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id CCE3921F852A for ; Tue, 10 Jul 2012 01:13:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,558,1336374000"; d="p7s'?scan'208";a="661044491" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 10 Jul 2012 01:14:25 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q6A8EOJT025753; Tue, 10 Jul 2012 01:14:25 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.13]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 01:14:24 -0700 From: "Eggert, Lars" To: Wesley Eddy Thread-Topic: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: AQHNXByf28umeI0l70OWWRBqxwyTrpch44eAgAAuEwCAAJOLAA== Date: Tue, 10 Jul 2012 08:14:23 +0000 Message-ID: References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> <4FFB689A.90402@mti-systems.com> In-Reply-To: <4FFB689A.90402@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_2BF31612-B6A7-4C8A-9C15-65C2F1A20DCD"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:14:03 -0000 --Apple-Mail=_2BF31612-B6A7-4C8A-9C15-65C2F1A20DCD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jul 10, 2012, at 1:26, Wesley Eddy wrote: > On 7/9/2012 4:41 PM, Tina TSOU wrote: >> The TCP option is another good way to include the HOST ID in case of TCP >> and UDP communications. > > Surely there's a typo there, since it does not work at all in the > case of UDP. > > I disagree with the overall recommendation of the document, since > it presumes that a solution is required, among other flaws with it. > > Additionally, it is not particularly clear how this can work for > multiple layers of sharing (e.g. CGN), though draft-abdo seems to > think that CGN is a single layer of sharing. +1 Lars --Apple-Mail=_2BF31612-B6A7-4C8A-9C15-65C2F1A20DCD Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMDA4MTQyM1owIwYJKoZIhvcNAQkEMRYEFOon 6NX2Ku++FTDDATrQn4P2utaMMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAGzRJ5A7 MRwFSPQAiBwemddjHH4KAFSY7UfYOzfhoxF+R9Sgr+nz525XHnpQEAwuR8B3nizZjXRe5oPU49E+ 3Zk22uISgZQIeBeoOhqT5BZEiF3CUXnMbatc+h7XHpJnSvLjCV8DpSjGTtq/x5RZAOqz1/xYFt8v Iq0Qe+ROc04G+1Z8nfJpX4A4nlvbu2+fRoVxrXPbifSVWnIaU3z7jsysqn4SUO6qKJfdvpp0pbqF Kf0S0zCAiG6Es7mWh7jtzcFCS3UoSeZvaPfgmlIlD5z7xKX4vx5CV5k19kOwdd825hrkbpqb5bJt +wKCoVFBfg39aO0VMN6A2fLfNr56xNEAAAAAAAA= --Apple-Mail=_2BF31612-B6A7-4C8A-9C15-65C2F1A20DCD-- From warren@kumari.net Tue Jul 10 17:53:14 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D7711E80CA for ; Tue, 10 Jul 2012 17:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 y1UV8EYkzHDx for ; Tue, 10 Jul 2012 17:53:14 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5221A11E80A3 for ; Tue, 10 Jul 2012 17:53:14 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BA2B11B40B83; Tue, 10 Jul 2012 20:53:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 10 Jul 2012 20:53:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <91990C4B-AC72-45FD-BDC2-50B711DA45E5@kumari.net> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> <4FFB689A.90402@mti-systems.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1278) Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 00:53:15 -0000 On Jul 10, 2012, at 4:14 AM, Eggert, Lars wrote: > On Jul 10, 2012, at 1:26, Wesley Eddy wrote: >> On 7/9/2012 4:41 PM, Tina TSOU wrote: >>> The TCP option is another good way to include the HOST ID in case of = TCP >>> and UDP communications.=20 >>=20 >> Surely there's a typo there, since it does not work at all in the >> case of UDP. >>=20 >> I disagree with the overall recommendation of the document, since >> it presumes that a solution is required, among other flaws with it. >>=20 >> Additionally, it is not particularly clear how this can work for >> multiple layers of sharing (e.g. CGN), though draft-abdo seems to >> think that CGN is a single layer of sharing. >=20 > +1 Me too! Existing "solutions" work well enough (even if in many cases the = solution simply ignores the problem :-P) W >=20 > Lars_______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- The duke had a mind that ticked like a clock and, like a clock, it = regularly went cuckoo. -- (Terry Pratchett, Wyrd Sisters) From jiangsheng@huawei.com Mon Jul 16 03:06:46 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B521821F877A for ; Mon, 16 Jul 2012 03:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IJSEi+O2C9es for ; Mon, 16 Jul 2012 03:06:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A544C21F86D3 for ; Mon, 16 Jul 2012 03:06:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU30055; Mon, 16 Jul 2012 06:07:29 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 03:04:28 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 03:04:30 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 18:04:22 +0800 From: Sheng Jiang To: "int-area@ietf.org" Thread-Topic: New Version Notification for draft-jiang-semantic-prefix-01.txt Thread-Index: AQHNYzpDsyR2Ifepx0mAKRmDW5gqkJcrrhQA Date: Mon, 16 Jul 2012 10:04:21 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF989E@szxeml545-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 16 Jul 2012 07:38:45 -0700 Subject: [Int-area] FW: New Version Notification for draft-jiang-semantic-prefix-01.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 10:06:47 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgZHJhZnQtamlhbmctc2Vt YW50aWMtcHJlZml4LCAiU2VtYW50aWMgSVB2NiBQcmVmaXgiLiBJdCBwcm9wb3NlcyBhIGZyYW1l d29yayB0byBhbGxvdyBzZW1hbnRpY3MgdG8gYmUgZW1iZWRkZWQgaW50byBwcmVmaXggc28gdGhh dCBJU1BzIGFuZCBlbnRlcnByaXNlIGNhbiBlYXNpbHkgYXBwbHkgcmVsZXZhbnQgb3BlcmF0aW9u cyBhY2NvcmRpbmdseS4NCg0KQWxsIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2Fy ZHMsDQoNClNoZW5nDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0K PiBTZW50OiBNb25kYXksIEp1bHkgMTYsIDIwMTIgNjowMyBQTQ0KPiBUbzogU2hlbmcgSmlhbmcN Cj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qaWFuZy1zZW1h bnRpYy1wcmVmaXgtMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWppYW5nLXNlbWFudGljLXByZWZpeC0wMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBTaGVuZyBKaWFuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRv cnkuDQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LWppYW5nLXNlbWFudGljLXByZWZpeA0KPiBSZXZp c2lvbjoJIDAxDQo+IFRpdGxlOgkJIFNlbWFudGljIElQdjYgUHJlZml4DQo+IENyZWF0aW9uIGRh dGU6CSAyMDEyLTA3LTE2DQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1i ZXIgb2YgcGFnZXM6IDExDQo+IFVSTDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtamlhbmctc2VtYW50aWMtcHJlZml4LTAxLnR4dA0KPiBTdGF0dXM6DQo+IGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctc2VtYW50aWMtcHJlZml4 DQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlh bmctc2VtYW50aWMtcHJlZml4LTAxDQo+IERpZmY6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtamlhbmctc2VtYW50aWMtcHJlZml4LTAxDQo+IA0KPiBBYnN0cmFj dDoNCj4gICAgU29tZSBJbnRlcm5ldCBTZXJ2aWNlIFByb3ZpZGVycyBhbmQgZW50ZXJwcmlzZXMg ZGVzaXJlIHRvIGJlIGF3YXJlIG9mDQo+ICAgIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgZWFjaCBw YWNrZXQsIHNvIHRoYXQgcGFja2V0cyBjYW4gYmUgdHJlYXRlZA0KPiAgICBkaWZmZXJlbnRseSBh bmQgZWZmaWNpZW50bHkuIFBhY2tldC1sZXZlbCBkaWZmZXJlbnRpYXRpbmcgY2FuIGFsc28NCj4g ICAgZW5hYmxlIGZsb3ctbGV2ZWwgYW5kIHVzZXItbGV2ZWwgZGlmZmVyZW50aWF0aW5nLg0KPiAN Cj4gICAgSVB2Niwgd2l0aCBhIGxhcmdlIGFkZHJlc3Mgc3BhY2UsIGFsbG93cyBzZW1hbnRpY3Mg dG8gYmUgZW1iZWRkZWQNCj4gICAgaW50byBhZGRyZXNzZXMuIFJvdXRlcnMgY2FuIGVhc2lseSBh cHBseSByZWxldmFudCBvcGVyYXRpb25zDQo+ICAgIGFjY29yZGluZ2x5LiBUaGlzIGRvY3VtZW50 IHByb3ZpZGVzIGFuYWx5c2lzIG9uIGhvdyB0byBmb3JtIHNlbWFudGljDQo+ICAgIHByZWZpeCBh bmQgY29ycmVzcG9uZGluZyB1c2UgY2FzZXMsIGFuZCBpZGVudGlmaWVzIHRoZSB0ZWNobmljYWwN Cj4gICAgcmVxdWlyZW1lbnRzIHRvIG1heGltaXplIHRoZSBiZW5lZml0cyBvZiB0aGUgc2VtYW50 aWMgcHJlZml4DQo+ICAgIGFwcHJvYWNoLiBJdCBpcyByZWNvbW1lbmRlZCB0byB1c2UgNH4xMiBi aXRzIGluIHByZWZpeCBmb3IgZW1iZWRkZWQNCj4gICAgc2VtYW50aWNzLg0KPiANCj4gICAgVGhp cyBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IG9ubHkgZGlzY3Vzc2VzIHVzYWdlIG9mIHNlbWFudGlj cyBpbiBhDQo+ICAgIHNlbWFudGljIHByZWZpeCBkb21haW4uIEl0IGRvZXMgTk9UIGludGVudCBv ciBzdWdnZXN0IHRvIHN0YW5kYXJkaXplDQo+ICAgIGFueSBjb21tb24gZ2xvYmFsIHNlbWFudGlj cy4NCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From suresh.krishnan@ericsson.com Fri Jul 20 11:54:38 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B0F11E807F for ; Fri, 20 Jul 2012 11:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 o-kL7Xlynpee for ; Fri, 20 Jul 2012 11:54:38 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id F196611E8099 for ; Fri, 20 Jul 2012 11:54:37 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6KItTwR023963 for ; Fri, 20 Jul 2012 13:55:34 -0500 Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 20 Jul 2012 14:55:32 -0400 Message-ID: <5009A9A3.4050407@ericsson.com> Date: Fri, 20 Jul 2012 14:55:31 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Internet Area References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> In-Reply-To: <4FEB2D67.1010901@ericsson.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 18:54:38 -0000 Hi all, After going through the responses to the WGLC, it is clear that the draft is not ready to go forward in the publication process. We will discuss further steps for this draft at the Vancouver meeting. Thanks Suresh & Julien From ahmodu.bankole@yahoo.com Tue Jul 24 00:46:13 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7100721F85F9 for ; Tue, 24 Jul 2012 00:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_80=2, HTML_MESSAGE=0.001] 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 dyXwxUBMM9S0 for ; Tue, 24 Jul 2012 00:46:13 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with SMTP id D119321F85F7 for ; Tue, 24 Jul 2012 00:46:12 -0700 (PDT) Received: from [98.139.214.32] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2012 07:46:12 -0000 Received: from [98.139.215.251] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jul 2012 07:46:12 -0000 Received: from [127.0.0.1] by omp1064.mail.bf1.yahoo.com with NNFMP; 24 Jul 2012 07:46:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 245904.82543.bm@omp1064.mail.bf1.yahoo.com Received: (qmail 99375 invoked by uid 60001); 24 Jul 2012 07:46:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1343115972; bh=J0AoHi5Yrz4TVr2uHLLzg4PfYXK71cToe0W/HmRU+Rs=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=YnTG/5e7mhvmFu8BZeeazEuXXI7uwRUkZBN48QSE6fZR/ivveaZDrhKc+pXD55OCTnwJDMd/WYY+jyOILJh2v5daIzzJF8rsmN9mVLEzn0WKisCtUfHv7Mz6/j4EfmiLzRL1/zOgmXcW3/6DnaAXPZkSMQjJVMycfvGQWjwkXOw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=DD72kmaVfGCmP1Yn3+X22QdG7zjYG7ZAuRSP+jJqh4tSaKxg9iawXM/pqAL1yzglF75HneX64TSnKeH7fuIpsCGzHDtAVWmrYQbMXgErx9GnkXlh3cqJVWrEG2uEc8ey+v/Gl3HTchJxV3nZjt87PcizQHwLaZ5s/zZG39fXYBg=; X-YMail-OSG: Nk9hzzkVM1kd8b3PlNrM9Fd1X2Ja4o5uN482J3bEMMqs2.b mA9CyS5AWbSEgc1Hct05PXubO_OueqilC22wniEZKjZDTgUbgyB7JavLphNi s1o6LwCDYPSKDqYH_6fxY4tAehB2OMIu2FTTeYLiCB5M5jbTvewC5wbnlj2v T9T0q8x1s._LVl2yrFYoqTNRShEBkLGZJV3nKZuZ66_D9zJas5xu5X.h6zEb ug2kRMaWkzVtjVi4ojPoWkNCe5bX9PtIPPQBdDy5enjb1cqnjz1DY3rDwt6q zo2xa7GO00XKPtrkfJV7vV_ApO7f3yOZdBwCzDVwWFmMOxXggQY51Mu.91pO uYsifYroHX1bBsNPZBbYXxN2jyvXIgmOs_MaeypM1PwldTMVFBTdoAcES4ZT taa_15yAqd7jgBpi3h1_pkLvsrjW4wgdr0zvingN1VFHZza9rYEDddRgX5Kb GLFCxcpv.vm1D1OlKu_nPHiMLQvNqVq3_P6p1hCGw9QY- Received: from [41.203.68.46] by web142601.mail.bf1.yahoo.com via HTTP; Tue, 24 Jul 2012 00:46:12 PDT X-Mailer: YahooMailWebService/0.8.120.356233 Message-ID: <1343115972.83755.YahooMailNeo@web142601.mail.bf1.yahoo.com> Date: Tue, 24 Jul 2012 00:46:12 -0700 (PDT) From: BANKOLE AHMODU To: "int-area@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1637284482-1038413315-1343115972=:83755" Subject: [Int-area] My Email X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: BANKOLE AHMODU List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 07:46:13 -0000 ---1637284482-1038413315-1343115972=:83755 Content-Type: text/plain; charset=us-ascii Hi All, My email address is ahmodu.bankole@yahoo.com Thanks Bankole ---1637284482-1038413315-1343115972=:83755 Content-Type: text/html; charset=us-ascii
Hi All,

My email address is ahmodu.bankole@yahoo.com
Thanks

Bankole
---1637284482-1038413315-1343115972=:83755-- From mohamed.boucadair@orange.com Thu Jul 26 00:03:33 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA21211E8085 for ; Thu, 26 Jul 2012 00:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 s-fxmClQXnch for ; Thu, 26 Jul 2012 00:03:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D972A11E807F for ; Thu, 26 Jul 2012 00:03:32 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id EF8C122C69E; Thu, 26 Jul 2012 09:03:31 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CB03F23804B; Thu, 26 Jul 2012 09:03:31 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 26 Jul 2012 09:03:26 +0200 From: To: Joe Touch , Suresh Krishnan Date: Thu, 26 Jul 2012 09:03:24 +0200 Thread-Topic: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1bDMVYfe1XiltcT5CJaq6pd199ewP7xw2Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E27B@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <4FF62E97.3070301@isi.edu> In-Reply-To: <4FF62E97.3070301@isi.edu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: Internet Area Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 07:03:34 -0000 Dear Joe, all, Apologies for the delay to answer (I was out of office). I have no problem to remove Section 3.3 if this is what the WG wants. As a = reminder, I added that section after the Paris meeting in accordance with w= hat I heard in the meeting: more voices in favour of adding a recommendatio= n. I sent a notification to the mailing list mid-april to acknowledge this = change.=20 Now, I'm waiting for a feedback from the WG to maintain or to remove Sectio= n 3.3. Cheers, Med >-----Message d'origine----- >De : int-area-bounces@ietf.org=20 >[mailto:int-area-bounces@ietf.org] De la part de Joe Touch >Envoy=E9 : vendredi 6 juillet 2012 02:17 >=C0 : Suresh Krishnan >Cc : Internet Area >Objet : Re: [Int-area] ACTION REQUIRED: Extending working=20 >group last call for draft-ietf-intarea-nat-reveal-analysis-02 > >As a co-author, I didn't want to remain silent per se, so I'll=20 >at least=20 >be public in my view. > >I think the doc is good, but I do take Alissa's concerns to point - it=20 >might be preferable to remove section 3.3 and leave this doc as a=20 >comparison of solutions, and avoid any recommendation of a way forward=20 >at this point. > >Joe > >On 6/27/2012 8:57 AM, Suresh Krishnan wrote: >> Hi all, >> The WGLC on this draft ended with no comments at all. In=20 >this context, >> we cannot assume that silence equates to consent. In order for this >> draft to progress, we need people to read the draft and provide their >> opinions on whether the draft is ready. To enable people to=20 >comment, the >> last call period is extended until Friday July 6, 2012. >> >> Thanks >> Suresh and Julien >> >> On 06/08/2012 10:06 AM, Suresh Krishnan wrote: >>> Hi all, >>> This message starts a two week intarea working group last call on >>> advancing the draft about Analysis of Solution Candidates=20 >to Reveal a >>> Host Identifier (HOST_ID) in Shared Address Deployments as an >>> Informational RFC. The draft is available at >>> >>> http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt >>> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 >>> >>> Substantive comments and statements of support/opposition=20 >for advancing >>> this document should be directed to the mailing list. Editorial >>> suggestions can be sent directly to the authors. This last call will >>> conclude on June 22, 2012. >>> >>> Regards, >>> Suresh & Julien >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area >= From mohamed.boucadair@orange.com Thu Jul 26 00:10:47 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D9F11E807F for ; Thu, 26 Jul 2012 00:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 uTHhNd8UjdgY for ; Thu, 26 Jul 2012 00:10:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 59D8A11E809A for ; Thu, 26 Jul 2012 00:10:46 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 296722DC416; Thu, 26 Jul 2012 09:10:45 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0D3CC35C045; Thu, 26 Jul 2012 09:10:45 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 26 Jul 2012 09:10:39 +0200 From: To: "Eggert, Lars" , Alissa Cooper Date: Thu, 26 Jul 2012 09:10:38 +0200 Thread-Topic: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: AQHNWu+ojYqG7aQYS0K2VtPas5PG35ccVHwAgB7vNIA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E282@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <41BC9D97-A168-43C1-BC0F-4F7CEA9CC0A7@cdt.org> <87110043-46CA-40BA-B67C-9368AB53D7CA@netapp.com> In-Reply-To: <87110043-46CA-40BA-B67C-9368AB53D7CA@netapp.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.50917 Cc: Internet Area Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 07:10:47 -0000 Dear Lars, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : int-area-bounces@ietf.org=20 >[mailto:int-area-bounces@ietf.org] De la part de Eggert, Lars >Envoy=E9 : vendredi 6 juillet 2012 09:40 >=C0 : Alissa Cooper >Cc : Internet Area >Objet : Re: [Int-area] ACTION REQUIRED: Extending working=20 >group last call for draft-ietf-intarea-nat-reveal-analysis-02 > >On Jul 5, 2012, at 22:48, Alissa Cooper wrote: >> With the changes to this draft in the -02 version, I'm=20 >having a little trouble seeing its purpose. It basically now=20 >seems like a shell for the recommendation in 3.3, with the=20 >analysis stuffed into appendices. But given that there is no=20 >stable proposal for the actual TCP option to be implemented,=20 >what is the purpose for advancing this document right now? I=20 >think I've heard that folks "needed to know what to=20 >implement," but does this document really resolve that problem=20 >given that even within the space of TCP-option-based solutions=20 >for this, there are multiple different proposals, none of=20 >which has been standardized? This document made more sense=20 >when it was just a comparison of the different potential=20 >solutions spaces. > >Fully agree with Alissa. An comparison of options would be=20 >fine. But 3.3 and other text go beyond a comparison. Med: FYI I added Section 3.3 after the Paris meeting where I asked the ques= tion whether we need to add a recommendation or not. It seems to me I heard= more voices for having a recommendation in the document. A notification ha= s been sent to this mailing list in mid-april. Anyway, I'm open to record t= he consensus of the WG: maintain or remove that section.=20 > >I also don't understand why INTAREA is entertaining work that=20 >is clearly intending to define new TCP options. Med: This draft is not about the TCP option but to analyze a set of solutio= ns to solve a problem already documented in RFC6069.=20 None of the=20 >-abdo- drafts have been presented in TCPM or even discussed on=20 >the mailing list. (My guess is that the authors know that this=20 >would never get traction in TCPM and are venue shopping.) Med: I checked tcpm agenda, draft-abdo will be presented in tcpm in Vancouv= er.=20 > >Lars= From mohamed.boucadair@orange.com Thu Jul 26 00:31:03 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2348121F867C for ; Thu, 26 Jul 2012 00:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 mjAHuybQjzQ2 for ; Thu, 26 Jul 2012 00:31:02 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 121A021F844A for ; Thu, 26 Jul 2012 00:31:01 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 2B19A2DC3E6; Thu, 26 Jul 2012 09:31:01 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 10C4327C053; Thu, 26 Jul 2012 09:31:01 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 26 Jul 2012 09:30:55 +0200 From: To: Wesley Eddy , Tina TSOU Date: Thu, 26 Jul 2012 09:30:53 +0200 Thread-Topic: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1eKkbTdM2W9DhST0Sc3ks8OyWm1gM06Q/Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E295@PUEXCB1B.nanterre.francetelecom.fr> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> <4FFB689A.90402@mti-systems.com> In-Reply-To: <4FFB689A.90402@mti-systems.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.43324 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 07:31:03 -0000 Dear Wes, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : int-area-bounces@ietf.org=20 >[mailto:int-area-bounces@ietf.org] De la part de Wesley Eddy >Envoy=E9 : mardi 10 juillet 2012 01:26 >=C0 : Tina TSOU >Cc : int-area@ietf.org >Objet : Re: [Int-area] Comments on=20 >draft-ietf-intarea-nat-reveal-analysis-02 > >I read the document and came to rather different conclusions (see >below): > >On 7/9/2012 4:41 PM, Tina TSOU wrote: >> I reviewed this draft and I found it very detailed about the various >> ways of including a HOST ID. Considering the number of users=20 >that share >> the same IPv4 address, there is an increasing importance of=20 >the HOST ID. >> Though it is discussed in the introduction about the various >> implications of not having HOST IDs, in my opinion, there should be a >> little more explanation of the problems faced if there is no HOST ID >> included. Moreover, the main concern is security issue. It is very >> difficult to identify a particular user, when there are a number of >> users with different private IP addresses sharing the same=20 >public address. > > >I agree with you that if the document is pursued, it should include >more discussion of what the problems are with not having a host ID; >the current text seems like handwaving to me. Med: The issues have been already documented in RFC6269. The draft includes= pointers to some sections from that draft. I don't personally >think it is very well motivated, and from my standpoint there is >absolutely no reason to pursue a solution. It would be enough to >simply have the analysis documented as to why all of the considered >approaches COMPLETELY STINK. > >But aside from that, I disagree with you on purpose of whatever is >being attempted here. The document is about identifying hosts, and >you mention "users". These are not the same thing. Which do you want >to identify? In my opinion, anything related to users (and not hosts) >should be completely out of scope. Med: Agreed. The notion of "user" is out of scope of draft-ietf-intarea-nat= -reveal-analysis. > >Further, I think the problem has to perhaps be refined to >disambiguating between different hosts using the same IP address >versus trying to semi-uniquely identify the hosts. The problems >described are due to aliasing, and unique identification is a >rather strong means of de-aliasing. > > >> The TCP option is another good way to include the HOST ID in=20 >case of TCP >> and UDP communications.=20 > > >Surely there's a typo there, since it does not work at all in the >case of UDP. > >I disagree with the overall recommendation of the document, since >it presumes that a solution is required, among other flaws with it. Med: The recommendation has been added after the Paris meeting. I asked dur= ing the presentation whether we need to add a reco or not: I heard voices f= or having a reco. =20 > >Additionally, it is not particularly clear how this can work for >multiple layers of sharing (e.g. CGN), though draft-abdo seems to >think that CGN is a single layer of sharing. Med: Good point. draft-abdo focuses on ds-lite model and as such there is o= nly one level of NAT. Even in such scenario, the CGN is configured to strip= an existing HOST_ID option since this information is not trusted. For doub= le NAT scenario, only the external IP address after the first NAT is import= ant to be passed by the second NAT. > >--=20 >Wes Eddy >MTI Systems >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area >= From hannes.tschofenig@gmx.net Thu Jul 26 00:51:57 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C539221F8606 for ; Thu, 26 Jul 2012 00:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, 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 HwRjbe92Tepu for ; Thu, 26 Jul 2012 00:51:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4918721F85DD for ; Thu, 26 Jul 2012 00:51:56 -0700 (PDT) Received: (qmail invoked by alias); 26 Jul 2012 07:51:54 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp072) with SMTP; 26 Jul 2012 09:51:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18rrPcpQfUrYHWKEAsthcBgu7386jUu7B0/KaneIh avzYmcmMriR/81 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E295@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 26 Jul 2012 10:51:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <75D8CA71-9064-4777-9465-430CE4A53B6A@gmx.net> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> <4FFB689A.90402@mti-systems.com> <94C682931C08B048B7A8645303FDC9F36E4A17E295@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 07:51:58 -0000 Hi Mohamed,=20 On Jul 26, 2012, at 10:30 AM, wrote: >> But aside from that, I disagree with you on purpose of whatever is >> being attempted here. The document is about identifying hosts, and >> you mention "users". These are not the same thing. Which do you = want >> to identify? In my opinion, anything related to users (and not = hosts) >> should be completely out of scope. >=20 > Med: Agreed. The notion of "user" is out of scope of = draft-ietf-intarea-nat-reveal-analysis. It would be nice if that would actually be true.=20 Just an example from Section 13.2 of RFC 6269 = http://tools.ietf.org/html/rfc6269#section-13 " Simple address-based identification mechanisms that are used to populate access control lists will fail when an IP address is no longer sufficient to identify a particular subscriber. " Hint: >> particular subscriber << During the Taipei presentation I had complained about promoting = inadequate (or historic) security mechanisms for user authentication = already.=20 The IETF has developed technology to provide cryptographic = authentication (at all layers) already since 20 years.=20 Ciao Hannes From mohamed.boucadair@orange.com Thu Jul 26 01:17:17 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AA521F8644 for ; Thu, 26 Jul 2012 01:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] 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 pNBzokWgamet for ; Thu, 26 Jul 2012 01:17:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D806621F855F for ; Thu, 26 Jul 2012 01:17:14 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F308C3B44D5; Thu, 26 Jul 2012 10:17:13 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D2BDB35C064; Thu, 26 Jul 2012 10:17:13 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 26 Jul 2012 10:17:08 +0200 From: To: SM , "int-area@ietf.org" Date: Thu, 26 Jul 2012 10:17:07 +0200 Thread-Topic: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1cHK+5oV2eplgXTH2OnSpSlJ+v4wO5Aujw Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E2C8@PUEXCB1B.nanterre.francetelecom.fr> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> In-Reply-To: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.50917 Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 08:17:17 -0000 Dear SM, Apologies for the delay to answer.=20 Please see inline. Cheers, Med =20 >-----Message d'origine----- >De : int-area-bounces@ietf.org=20 >[mailto:int-area-bounces@ietf.org] De la part de SM >Envoy=E9 : samedi 7 juillet 2012 10:41 >=C0 : int-area@ietf.org >Objet : [Int-area] Comments on=20 >draft-ietf-intarea-nat-reveal-analysis-02 > >Hello, > >I have a few comments on draft-ietf-intarea-nat-reveal-analysis-02. > >In Section 1.1: > > "Examples of such issues are listed below:" > > "Redirect users with infected machines to a dedicated portal" > >Why is this an issue? Med: The issue is described in detail in RFC6269: " In addition, there are web tie-ins into different blacklists that web administrators subscribe to in order to redirect users with infected machines (e.g., detect the presence of a worm) to a URL that says "Hey, your machine is infected!". With address sharing, someone else's worm can interfere with the ability to access the service for other subscribers sharing the same IP address. " > > "The risk of not mitigating these issues are: OPEX increase for IP" > >I suggest expanding "OPEX" on first use. Med: Done.=20 > >In Section 2: > > "Tomorrow, due to the introduction of CGNs (e.g., NAT44 > [RFC3022], NAT64 [RFC6146]), that address will be shared." > >Isn't IPv4 shared addresses already in use in the wild? Med: IPv4 address sharing is already deployed but still the widely deployed= model is to assign public IP addresses to customers. Would you be OK with = changing "due to the introduction of CGNs" to "due to the massive introduct= ion of CGNs"? > >In Section 2.1: > > "A solution to reveal HOST_ID is also needed in IPv6 deployment." > >I suggest soliciting feedback from V6OPS about this. > >The draft already mentions that the issue is caused by IPv4 address=20 >sharing. It then goes on to suggest that address sharing can be used=20 >for IPv6. That is going to create the same problem there and argue=20 >for the solution mentioned in this draft. Med: I'm mainly thinking about NPTv6 (RFC6296).=20 > >In Section 3.2: > > "Requires the client and the server to be HIP-compliant and HIP > infrastructure to be deployed." > >What's HIP? Med: Host Identity Protocol. A reference is provided in the draft. > > "XFF is de facto standard deployed and supported in operational > networks" > >What's XFF? Med: X-Forwarded-For. The acronym is expanded in the draft but in Section A= .8.1. I will make sure it is expanded in first use. > > "From an application standpoint, the TCP Option is superior to XFF/ > Forwarded-For since it is not restricted to HTTP." > >That doesn't sound like a fair comparison. Med: Could you please indicate what is not fair about that sentence? Thanks= . =20 > > "Nevertheless XFF/Forwarded-For is compatible with the presence of > address sharing and load-balancers in the communication path." > >What is the meaning of compatible in here? Med: XFF allows to prepend a list of IP addresses when several address shar= ing, application proxies, etc. are in the path. The term compatible is used= to indicate XFF can be used in that scenario. If you have any better wordi= ng, please advise. Thanks. > >In Section 4: > > "some users realize privacy benefits associated with IP address > sharing, and some may even take steps to ensure that NAT > functionality sits between them and the public Internet." > >What are the privacy benefits of IP address sharing? Med: Anonymity may be provided; see for instance the TOR service. > >In skimmed over the appendix. What's "Application Headers"? Med: XFF is for instance an HTTP header, "via" is a SIP header, etc. Would = it be better if we change "Application Header" to "Application Protocols He= aders"? > >This draft would benefit from cross-area review. It needs more work=20 >in my humble opinion. > >Regards, >-sm > > > > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area >= From mohamed.boucadair@orange.com Thu Jul 26 01:25:52 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDFC21F85D0 for ; Thu, 26 Jul 2012 01:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 HMSOmLYSYyz6 for ; Thu, 26 Jul 2012 01:25:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id BE45821F85D2 for ; Thu, 26 Jul 2012 01:25:51 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2078718C379; Thu, 26 Jul 2012 10:25:51 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0282627C054; Thu, 26 Jul 2012 10:25:51 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 26 Jul 2012 10:25:45 +0200 From: To: Suresh Krishnan , Internet Area Date: Thu, 26 Jul 2012 10:25:44 +0200 Thread-Topic: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1mqT+o4QhyFxnFRgmn09q3GUpfkQEXlyaQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> In-Reply-To: <5009A9A3.4050407@ericsson.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.43324 Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 08:25:52 -0000 Dear Suresh, all, After reading received comments, the major point we need to discuss is whet= her the WG wants to remove Section 3.3 or maintain it. I'm waiting for a fe= edback from the WG for the direction to take. I will implement any change r= equested by the WG. Cheers, Med =20 >-----Message d'origine----- >De : int-area-bounces@ietf.org=20 >[mailto:int-area-bounces@ietf.org] De la part de Suresh Krishnan >Envoy=E9 : vendredi 20 juillet 2012 20:56 >=C0 : Internet Area >Objet : [Int-area] Completion of working group last call for=20 >draft-ietf-intarea-nat-reveal-analysis-02 > >Hi all, > After going through the responses to the WGLC, it is clear that the >draft is not ready to go forward in the publication process. We will >discuss further steps for this draft at the Vancouver meeting. > >Thanks >Suresh & Julien >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area >= From mohamed.boucadair@orange.com Thu Jul 26 01:33:34 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C70E21F8736 for ; Thu, 26 Jul 2012 01:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 BW8YvrVXBIqB for ; Thu, 26 Jul 2012 01:33:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DC4E921F872A for ; Thu, 26 Jul 2012 01:33:33 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 45B6D22C6A2; Thu, 26 Jul 2012 10:33:33 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 28D5E27C046; Thu, 26 Jul 2012 10:33:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 26 Jul 2012 10:33:27 +0200 From: To: Hannes Tschofenig Date: Thu, 26 Jul 2012 10:33:26 +0200 Thread-Topic: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1rA4P0lnFZU+ENRc2FJmEs/TRIpgABN/bw Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E2E1@PUEXCB1B.nanterre.francetelecom.fr> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> <4FFB689A.90402@mti-systems.com> <94C682931C08B048B7A8645303FDC9F36E4A17E295@PUEXCB1B.nanterre.francetelecom.fr> <75D8CA71-9064-4777-9465-430CE4A53B6A@gmx.net> In-Reply-To: <75D8CA71-9064-4777-9465-430CE4A53B6A@gmx.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.43324 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 08:33:34 -0000 Dear Hannes, RFC6269 does not promote any mechanism but rather it identifies what is bro= ken in real deployments.=20 Saying that, do you think it is useful to re-insert the text we had in earl= ier version:=20 Enabling explicit identification means and adequate security suite is more robust than relying on source IP address or HOST_ID. But tension may appear between strong privacy and usability (see Section 4.2 of [I-D.iab-privacy-workshop]). Cheers; Med=20 >-----Message d'origine----- >De : Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 >Envoy=E9 : jeudi 26 juillet 2012 09:52 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org >Objet : Re: [Int-area] Comments on=20 >draft-ietf-intarea-nat-reveal-analysis-02 > >Hi Mohamed,=20 > >On Jul 26, 2012, at 10:30 AM, wrote: > >>> But aside from that, I disagree with you on purpose of whatever is >>> being attempted here. The document is about identifying hosts, and >>> you mention "users". These are not the same thing. Which=20 >do you want >>> to identify? In my opinion, anything related to users (and=20 >not hosts) >>> should be completely out of scope. >>=20 >> Med: Agreed. The notion of "user" is out of scope of=20 >draft-ietf-intarea-nat-reveal-analysis. > > >It would be nice if that would actually be true.=20 > >Just an example from Section 13.2 of RFC 6269=20 >http://tools.ietf.org/html/rfc6269#section-13 > >" > Simple address-based identification mechanisms that are used to > populate access control lists will fail when an IP address is no > longer sufficient to identify a particular subscriber. >" > >Hint: >> particular subscriber << > >During the Taipei presentation I had complained about=20 >promoting inadequate (or historic) security mechanisms for=20 >user authentication already.=20 > >The IETF has developed technology to provide cryptographic=20 >authentication (at all layers) already since 20 years.=20 > >Ciao >Hannes > >= From hannes.tschofenig@gmx.net Thu Jul 26 02:09:13 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C38021F869F for ; Thu, 26 Jul 2012 02:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, 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 TU9zH+w5ZKaE for ; Thu, 26 Jul 2012 02:09:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B523C21F8601 for ; Thu, 26 Jul 2012 02:09:05 -0700 (PDT) Received: (qmail invoked by alias); 26 Jul 2012 09:09:03 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 26 Jul 2012 11:09:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BdXAWGirBwVTALN2shaTHeBPf/FFMX82TIkbs/k NZhecU/w93ky+e Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E2E1@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 26 Jul 2012 12:09:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> <4FFB689A.90402@mti-systems.com> <94C682931C08B048B7A8645303FDC9F36E4A17E295@PUEXCB1B.nanterre.francetelecom.fr> <75D8CA71-9064-4777-9465-430CE4A53B6A@gmx.net> <94C682931C08B048B7A8645303FDC9F36E4A17E2E1@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 09:09:13 -0000 Hi Mohamed,=20 I know that RFC 6269 just tries to identify what the authors consider as = broken in real world deployments. The analysis in that document is, = however, used as a justification for doing the work on = draft-ietf-intarea-nat-reveal-analysis-02.=20 As it turns out there are other ways to fix these problems, particularly = with respect to authentication. Not only are these mechanisms less = brittle but they also provide better properties from a security and = privacy point of view.=20 That's maybe the reason why your co-workers had been active in = standardization on these security mechanisms for a long time (pointer to = the work on SAML).=20 I had, however, jumped into the discussion because of the statement that = users are outside the scope of this work which I believe is incorrect.=20= Ciao Hannes On Jul 26, 2012, at 11:33 AM, wrote: > Dear Hannes, >=20 > RFC6269 does not promote any mechanism but rather it identifies what = is broken in real deployments.=20 >=20 > Saying that, do you think it is useful to re-insert the text we had in = earlier version:=20 >=20 > Enabling explicit identification means and adequate security suite = is > more robust than relying on source IP address or HOST_ID. But > tension may appear between strong privacy and usability (see Section > 4.2 of [I-D.iab-privacy-workshop]). >=20 > Cheers; > Med=20 >=20 >> -----Message d'origine----- >> De : Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 >> Envoy=E9 : jeudi 26 juillet 2012 09:52 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org >> Objet : Re: [Int-area] Comments on=20 >> draft-ietf-intarea-nat-reveal-analysis-02 >>=20 >> Hi Mohamed,=20 >>=20 >> On Jul 26, 2012, at 10:30 AM, wrote: >>=20 >>>> But aside from that, I disagree with you on purpose of whatever is >>>> being attempted here. The document is about identifying hosts, and >>>> you mention "users". These are not the same thing. Which=20 >> do you want >>>> to identify? In my opinion, anything related to users (and=20 >> not hosts) >>>> should be completely out of scope. >>>=20 >>> Med: Agreed. The notion of "user" is out of scope of=20 >> draft-ietf-intarea-nat-reveal-analysis. >>=20 >>=20 >> It would be nice if that would actually be true.=20 >>=20 >> Just an example from Section 13.2 of RFC 6269=20 >> http://tools.ietf.org/html/rfc6269#section-13 >>=20 >> " >> Simple address-based identification mechanisms that are used to >> populate access control lists will fail when an IP address is no >> longer sufficient to identify a particular subscriber. >> " >>=20 >> Hint: >> particular subscriber << >>=20 >> During the Taipei presentation I had complained about=20 >> promoting inadequate (or historic) security mechanisms for=20 >> user authentication already.=20 >>=20 >> The IETF has developed technology to provide cryptographic=20 >> authentication (at all layers) already since 20 years.=20 >>=20 >> Ciao >> Hannes >>=20 From mohamed.boucadair@orange.com Thu Jul 26 02:19:14 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0321F874A for ; Thu, 26 Jul 2012 02:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 18qt2gYmdqbQ for ; Thu, 26 Jul 2012 02:19:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 02BB421F8746 for ; Thu, 26 Jul 2012 02:19:13 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 16BA832450C; Thu, 26 Jul 2012 11:19:13 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E7FDC238062; Thu, 26 Jul 2012 11:19:12 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 26 Jul 2012 11:19:07 +0200 From: To: Hannes Tschofenig Date: Thu, 26 Jul 2012 11:19:05 +0200 Thread-Topic: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1rDkr6M18umD+oRUSpbqeXg87WEAAAGT2Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E306@PUEXCB1B.nanterre.francetelecom.fr> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <6CB5FBBD-0FB2-4F80-A29B-138AB723D38D@huawei.com> <4FFB689A.90402@mti-systems.com> <94C682931C08B048B7A8645303FDC9F36E4A17E295@PUEXCB1B.nanterre.francetelecom.fr> <75D8CA71-9064-4777-9465-430CE4A53B6A@gmx.net> <94C682931C08B048B7A8645303FDC9F36E4A17E2E1@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.81514 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 09:19:14 -0000 Re-, Please don't turn this discussion into "draft-ietf-intarea-nat-reveal-analy= sis is against authentication mechanisms".=20 Implicit identification is only on use case targeted by the HOST_ID idea. I= offered you the opportunity to introduce text (see the proposal below) to = educate readers that explicit means are more robust but you rejected my off= er.=20 Cheers, Med=20 >-----Message d'origine----- >De : Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 >Envoy=E9 : jeudi 26 juillet 2012 11:09 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org >Objet : Re: [Int-area] Comments on=20 >draft-ietf-intarea-nat-reveal-analysis-02 > >Hi Mohamed,=20 > >I know that RFC 6269 just tries to identify what the authors=20 >consider as broken in real world deployments. The analysis in=20 >that document is, however, used as a justification for doing=20 >the work on draft-ietf-intarea-nat-reveal-analysis-02.=20 > >As it turns out there are other ways to fix these problems,=20 >particularly with respect to authentication. Not only are=20 >these mechanisms less brittle but they also provide better=20 >properties from a security and privacy point of view.=20 > >That's maybe the reason why your co-workers had been active in=20 >standardization on these security mechanisms for a long time=20 >(pointer to the work on SAML).=20 > >I had, however, jumped into the discussion because of the=20 >statement that users are outside the scope of this work which=20 >I believe is incorrect.=20 > >Ciao >Hannes > >On Jul 26, 2012, at 11:33 AM, wrote: > >> Dear Hannes, >>=20 >> RFC6269 does not promote any mechanism but rather it=20 >identifies what is broken in real deployments.=20 >>=20 >> Saying that, do you think it is useful to re-insert the text=20 >we had in earlier version:=20 >>=20 >> Enabling explicit identification means and adequate=20 >security suite is >> more robust than relying on source IP address or HOST_ID. But >> tension may appear between strong privacy and usability=20 >(see Section >> 4.2 of [I-D.iab-privacy-workshop]). >>=20 >> Cheers; >> Med=20 >>=20 >>> -----Message d'origine----- >>> De : Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 >>> Envoy=E9 : jeudi 26 juillet 2012 09:52 >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org >>> Objet : Re: [Int-area] Comments on=20 >>> draft-ietf-intarea-nat-reveal-analysis-02 >>>=20 >>> Hi Mohamed,=20 >>>=20 >>> On Jul 26, 2012, at 10:30 AM, wrote: >>>=20 >>>>> But aside from that, I disagree with you on purpose of whatever is >>>>> being attempted here. The document is about identifying=20 >hosts, and >>>>> you mention "users". These are not the same thing. Which=20 >>> do you want >>>>> to identify? In my opinion, anything related to users (and=20 >>> not hosts) >>>>> should be completely out of scope. >>>>=20 >>>> Med: Agreed. The notion of "user" is out of scope of=20 >>> draft-ietf-intarea-nat-reveal-analysis. >>>=20 >>>=20 >>> It would be nice if that would actually be true.=20 >>>=20 >>> Just an example from Section 13.2 of RFC 6269=20 >>> http://tools.ietf.org/html/rfc6269#section-13 >>>=20 >>> " >>> Simple address-based identification mechanisms that are used to >>> populate access control lists will fail when an IP address is no >>> longer sufficient to identify a particular subscriber. >>> " >>>=20 >>> Hint: >> particular subscriber << >>>=20 >>> During the Taipei presentation I had complained about=20 >>> promoting inadequate (or historic) security mechanisms for=20 >>> user authentication already.=20 >>>=20 >>> The IETF has developed technology to provide cryptographic=20 >>> authentication (at all layers) already since 20 years.=20 >>>=20 >>> Ciao >>> Hannes >>>=20 > >= From sarikaya2012@gmail.com Thu Jul 26 09:22:22 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB3B21F8639 for ; Thu, 26 Jul 2012 09:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 nxuxgvC2XdqY for ; Thu, 26 Jul 2012 09:22:22 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2836E21F8638 for ; Thu, 26 Jul 2012 09:22:22 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2377087ghb.31 for ; Thu, 26 Jul 2012 09:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=XomWWJZZ2OPPs9VviLTcdoi+3tgiCH4RqnsX2F4Q6kA=; b=E4LzN/0aAYlBwrtGEjU25Of/gu0T0fZlWz4BHVfQrzew06RBsTR6UTflC/8XtD3T80 fgbs08tTvaLqOIKb65Z5MFiAqIOOdsxZQsmLR/H+3AfxAWaPdoJXK84jV+iu9hSicit2 KycIicWRHFbmmVarLjazYFGjSac+7HCQOgUerTrXtxEntimVKQfu1q2xxPTb81tpxM9w NqmEDAO1GDDYYxQEkmGWqbENlKoO/Iox7qDymqgBG/rO2vB4rmDXJitXthatHIaeawI3 qPASkd4/ksKqpp0q3pPNtZosUS2b20Gzfe1w+6g7kNuXTtqxFl1VE1N4+w3eXe12/Y/m PODQ== MIME-Version: 1.0 Received: by 10.50.159.135 with SMTP id xc7mr2186581igb.9.1343319741289; Thu, 26 Jul 2012 09:22:21 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Thu, 26 Jul 2012 09:22:21 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E282@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <41BC9D97-A168-43C1-BC0F-4F7CEA9CC0A7@cdt.org> <87110043-46CA-40BA-B67C-9368AB53D7CA@netapp.com> <94C682931C08B048B7A8645303FDC9F36E4A17E282@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 26 Jul 2012 11:22:21 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Internet Area Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:22:22 -0000 Hi Med, On Thu, Jul 26, 2012 at 2:10 AM, wrote: > Dear Lars, > > Please see inline. > > Cheers, > Med > >>-----Message d'origine----- >>De : int-area-bounces@ietf.org >>[mailto:int-area-bounces@ietf.org] De la part de Eggert, Lars >>Envoy=E9 : vendredi 6 juillet 2012 09:40 >>=C0 : Alissa Cooper >>Cc : Internet Area >>Objet : Re: [Int-area] ACTION REQUIRED: Extending working >>group last call for draft-ietf-intarea-nat-reveal-analysis-02 >> >>On Jul 5, 2012, at 22:48, Alissa Cooper wrote: >>> With the changes to this draft in the -02 version, I'm >>having a little trouble seeing its purpose. It basically now >>seems like a shell for the recommendation in 3.3, with the >>analysis stuffed into appendices. But given that there is no >>stable proposal for the actual TCP option to be implemented, >>what is the purpose for advancing this document right now? I >>think I've heard that folks "needed to know what to >>implement," but does this document really resolve that problem >>given that even within the space of TCP-option-based solutions >>for this, there are multiple different proposals, none of >>which has been standardized? This document made more sense >>when it was just a comparison of the different potential >>solutions spaces. >> >>Fully agree with Alissa. An comparison of options would be >>fine. But 3.3 and other text go beyond a comparison. > > Med: FYI I added Section 3.3 after the Paris meeting where I asked the qu= estion whether we need to add a recommendation or not. It seems to me I hea= rd more voices for having a recommendation in the document. A notification = has been sent to this mailing list in mid-april. Anyway, I'm open to record= the consensus of the WG: maintain or remove that section. > >> >>I also don't understand why INTAREA is entertaining work that >>is clearly intending to define new TCP options. > > Med: This draft is not about the TCP option but to analyze a set of solut= ions to solve a problem already documented in RFC6069. > RFC 6069 is about TCP-LCD? Behcet From sarikaya2012@gmail.com Thu Jul 26 10:08:50 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C868F21F861E for ; Thu, 26 Jul 2012 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WK7hwhHKGoKv for ; Thu, 26 Jul 2012 10:08:50 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0738C21F8611 for ; Thu, 26 Jul 2012 10:08:49 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2436093ghb.31 for ; Thu, 26 Jul 2012 10:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=TuOBGLiXmWzxEhpKRbxDUWsa1T59mJA1N4FieNPhUMY=; b=VxExmXU3y/cyq7WXyJ5HsU9X7kTkzpQVbopqoQkzP9uFv/Qy3pJOZ4AIScyV/avlEY 48bvuCsr40fYo4p4A0C5AB+f98xKEQxByTt79l8Z5rnrJh/3SRXCcLTZ9dAMLYxzSpZW nMjc2r61I13qPWBkERmvSq84dm2kGzrCFq0hTdvO9GCDk61B0sm44KAzQTpsKZYAroln oBRq5QK4a1d8F9XNYGbX08v480KPReHYxs6zlctkAOku01Md6bS+86/dy+qvnVdUMnQe m+DtVKeRdLZzRyxBB8CJ8zX4YNVBrTD1h7AsOXOlB/Lf2Woh+ASGPdw3geOK3tnUbEf9 1jtg== MIME-Version: 1.0 Received: by 10.50.6.229 with SMTP id e5mr2318107iga.9.1343322529390; Thu, 26 Jul 2012 10:08:49 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Thu, 26 Jul 2012 10:08:49 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 26 Jul 2012 12:08:49 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Internet Area Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 17:08:51 -0000 On Thu, Jul 26, 2012 at 3:25 AM, wrote: > Dear Suresh, all, > > After reading received comments, the major point we need to discuss is wh= ether the WG wants to remove Section 3.3 or maintain it. I'm waiting for a = feedback from the WG for the direction to take. I will implement any change= requested by the WG. > Section 3.3 seems to give preference to one specific solution, as such it is against the whole spirit of this document. I suggest removing it. Behcet > Cheers, > Med > > >>-----Message d'origine----- >>De : int-area-bounces@ietf.org >>[mailto:int-area-bounces@ietf.org] De la part de Suresh Krishnan >>Envoy=E9 : vendredi 20 juillet 2012 20:56 >>=C0 : Internet Area >>Objet : [Int-area] Completion of working group last call for >>draft-ietf-intarea-nat-reveal-analysis-02 >> >>Hi all, >> After going through the responses to the WGLC, it is clear that the >>draft is not ready to go forward in the publication process. We will >>discuss further steps for this draft at the Vancouver meeting. >> >>Thanks >>Suresh & Julien >>_______________________________________________ >>Int-area mailing list >>Int-area@ietf.org >>https://www.ietf.org/mailman/listinfo/int-area >> > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From wes@mti-systems.com Thu Jul 26 11:33:53 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C381021F86C4 for ; Thu, 26 Jul 2012 11:33:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpST-fSZCpAe for ; Thu, 26 Jul 2012 11:33:47 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0298021F86C5 for ; Thu, 26 Jul 2012 11:33:46 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q6QIXkwk030707 for ; Thu, 26 Jul 2012 14:33:46 -0400 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.46.181.97] ([107.46.181.97:26444] helo=[192.168.43.65]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id DF/30-04790-98D81105; Thu, 26 Jul 2012 14:33:46 -0400 Message-ID: <50118D83.9010704@mti-systems.com> Date: Thu, 26 Jul 2012 14:33:39 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Internet Area , Behcet Sarikaya Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 18:33:54 -0000 On 7/26/2012 1:08 PM, Behcet Sarikaya wrote: > On Thu, Jul 26, 2012 at 3:25 AM, wrote: >> Dear Suresh, all, >> >> After reading received comments, the major point we need to discuss is whether the WG wants to remove Section 3.3 or maintain it. I'm waiting for a feedback from the WG for the direction to take. I will implement any change requested by the WG. >> > > Section 3.3 seems to give preference to one specific solution, as such > it is against the whole spirit of this document. > > I suggest removing it. > +1 In fact, I suggest that the draft should clearly say that it's doubtful whether a solution actually *needs* to be identified and recommended, especially ones that are implemented awkwardly in other layers. -- Wes Eddy MTI Systems From mohamed.boucadair@orange.com Thu Jul 26 23:59:52 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FB411E80CA for ; Thu, 26 Jul 2012 23:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 uuA2W12JTMdQ for ; Thu, 26 Jul 2012 23:59:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E114021F8499 for ; Thu, 26 Jul 2012 23:59:51 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 76D9122C73A; Fri, 27 Jul 2012 08:59:50 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5A90B4C024; Fri, 27 Jul 2012 08:59:50 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 27 Jul 2012 08:59:44 +0200 From: To: "sarikaya@ieee.org" Date: Fri, 27 Jul 2012 08:59:43 +0200 Thread-Topic: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1rStNM0X6rfNMvRLiOxSLi4jEPggAenDHg Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E4FE@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <41BC9D97-A168-43C1-BC0F-4F7CEA9CC0A7@cdt.org> <87110043-46CA-40BA-B67C-9368AB53D7CA@netapp.com> <94C682931C08B048B7A8645303FDC9F36E4A17E282@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.27.62417 Cc: Internet Area Subject: Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 06:59:52 -0000 Hi Behcet, Ooops, I wanted to quote RFC6269. Thanks.=20 Cheers, Med =20 >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : jeudi 26 juillet 2012 18:22 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Eggert, Lars; Alissa Cooper; Internet Area >Objet : Re: [Int-area] ACTION REQUIRED: Extending working=20 >group last call for draft-ietf-intarea-nat-reveal-analysis-02 > >Hi Med, >> >>> >>>I also don't understand why INTAREA is entertaining work that >>>is clearly intending to define new TCP options. >> >> Med: This draft is not about the TCP option but to analyze a=20 >set of solutions to solve a problem already documented in RFC6069. >> > >RFC 6069 is about TCP-LCD? > >Behcet >= From mohamed.boucadair@orange.com Fri Jul 27 00:09:44 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D7E11E80D6 for ; Fri, 27 Jul 2012 00:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 hUkXtSFt989d for ; Fri, 27 Jul 2012 00:09:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A0ABF21F84FB for ; Fri, 27 Jul 2012 00:09:30 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 930602DC21A; Fri, 27 Jul 2012 09:09:29 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 751B54C015; Fri, 27 Jul 2012 09:09:29 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 27 Jul 2012 09:09:23 +0200 From: To: "sarikaya@ieee.org" Date: Fri, 27 Jul 2012 09:09:22 +0200 Thread-Topic: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1rUVDxKS9Ixbw1R5COXYIAlLODvgAdJT/w Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E507@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: Internet Area Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 07:09:45 -0000 Hi Behcet, The argument I heard in Paris meeting for including a recommendation is to = help vendors to select the solution to implement in their devices. They can= not provide the same feature using 8 implementation options. That argument= makes sense to me.=20 Now, as I said earlier, I will remove or maintain that section according to= the guidance from the WG.=20 Cheers, Med=20 >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : jeudi 26 juillet 2012 19:09 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Suresh Krishnan; Internet Area >Objet : Re: [Int-area] Completion of working group last call=20 >for draft-ietf-intarea-nat-reveal-analysis-02 > >On Thu, Jul 26, 2012 at 3:25 AM, wrote: >> Dear Suresh, all, >> >> After reading received comments, the major point we need to=20 >discuss is whether the WG wants to remove Section 3.3 or=20 >maintain it. I'm waiting for a feedback from the WG for the=20 >direction to take. I will implement any change requested by the WG. >> > >Section 3.3 seems to give preference to one specific solution, as such >it is against the whole spirit of this document. > >I suggest removing it. > >Behcet >> Cheers, >> Med >> >> >>>-----Message d'origine----- >>>De : int-area-bounces@ietf.org >>>[mailto:int-area-bounces@ietf.org] De la part de Suresh Krishnan >>>Envoy=E9 : vendredi 20 juillet 2012 20:56 >>>=C0 : Internet Area >>>Objet : [Int-area] Completion of working group last call for >>>draft-ietf-intarea-nat-reveal-analysis-02 >>> >>>Hi all, >>> After going through the responses to the WGLC, it is clear that the >>>draft is not ready to go forward in the publication process. We will >>>discuss further steps for this draft at the Vancouver meeting. >>> >>>Thanks >>>Suresh & Julien >>>_______________________________________________ >>>Int-area mailing list >>>Int-area@ietf.org >>>https://www.ietf.org/mailman/listinfo/int-area >>> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >= From lars@netapp.com Fri Jul 27 09:28:34 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5264A21F87FE for ; Fri, 27 Jul 2012 09:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JTGhXEAfsFyo for ; Fri, 27 Jul 2012 09:28:33 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C82DD21F87BF for ; Fri, 27 Jul 2012 09:28:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,668,1336374000"; d="p7s'?scan'208";a="669129218" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 27 Jul 2012 09:28:32 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q6RGSWvg028687; Fri, 27 Jul 2012 09:28:32 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.13]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0298.004; Fri, 27 Jul 2012 09:28:32 -0700 From: "Eggert, Lars" To: "mohamed.boucadair@orange.com" Thread-Topic: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: AQHNa8bgJPsCdWLrKEGPSYGp7ceEdpc9x4QA Date: Fri, 27 Jul 2012 16:28:31 +0000 Message-ID: <0C81B7A4-5ED7-49D6-963F-0138F4E2E883@netapp.com> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E4A17E507@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E507@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_60AB2D0A-9E74-4E17-8B42-17E6A846A1A3"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 16:28:34 -0000 --Apple-Mail=_60AB2D0A-9E74-4E17-8B42-17E6A846A1A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 27, 2012, at 0:09, mohamed.boucadair@orange.com wrote: > The argument I heard in Paris meeting for including a recommendation = is to help vendors to select the solution to implement in their devices. = They can not provide the same feature using 8 implementation options. = That argument makes sense to me.=20 We're not at the stage yet where we can recommend anything to vendors. = We first need to determine if there even is a solution where the = benefits outweigh the drawbacks. Lars= --Apple-Mail=_60AB2D0A-9E74-4E17-8B42-17E6A846A1A3 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcyNzE2MjgzM1owIwYJKoZIhvcNAQkEMRYEFMzu VaQcRJug1qCzeAedYEZDTb9GMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAIrYG/Co HoN9uZPvd8hzSEFbTaxdQyzSbKQmyfmLYyY4hxJx3dTpinXUoZU5mb/YhEf3qw7Ysi16t4tjABlF OJvk69RdJLh9XWla9drOePLnJUZZpf+4OAqkC1//KjO22qFHRYYr1z78gU9IEoqElI8HJn7LFbx4 31Pg/a+J8DMw3dk5A5LcKt+z61isqHM701cINhCWacbMG8UVkQ/M7ZVlv1bGHrBFy0qjcmNjxud3 +d0LIIyqRQXeDN0mAnlvK/bTayrNbCtM0a3iLjX2nOCYCyNUE4DVvRK5bPkWCYlKPupQbZRc4wWR Zb1/XekEu65xurOFfs9I7VQ3x9uGA6MAAAAAAAA= --Apple-Mail=_60AB2D0A-9E74-4E17-8B42-17E6A846A1A3-- From dwing@cisco.com Fri Jul 27 09:46:20 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC7F21F8760 for ; Fri, 27 Jul 2012 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HECNd3Ij38cH for ; Fri, 27 Jul 2012 09:46:19 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 33A2821F875E for ; Fri, 27 Jul 2012 09:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=977; q=dns/txt; s=iport; t=1343407579; x=1344617179; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=wpKx0k6phEaDYKiORlhSWDWSuBp51LP5URhfsqdeCqA=; b=KPeOoL8MYqRDE6wvqyNk1zwSvI1JaLOp0zvUoTvtzYfAubMnuBrwxLlN M8JVX5VtNty7kCbH0I9mv0cEg1zjePHZeaXxWg+Hawvon2W97xKANgKfa WqrpecdmdU9IIrsMfiY/ox1Sn/RGKF3lOF7Y2F7M1VOFAGxOT96JFK1wx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJPEElCQ/khR/2dsb2JhbABFqhqPM4EHgiABAQEECAoBCg0QOgUMAQMCCQ8CBAEBAScHGSMKCQgCBAESCxAHh2uaMqBci1AKhmoDiE2FDJYWgWaCfw X-IronPort-AV: E=Sophos;i="4.77,668,1336348800"; d="scan'208";a="6951155" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 27 Jul 2012 16:46:18 +0000 Received: from dwingWS (sjc-vpn3-605.cisco.com [10.21.66.93]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6RGkGgx004871; Fri, 27 Jul 2012 16:46:17 GMT From: "Dan Wing" To: "'Eggert, Lars'" , References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E4A17E507@PUEXCB1B.nanterre.francetelecom.fr> <0C81B7A4-5ED7-49D6-963F-0138F4E2E883@netapp.com> In-Reply-To: <0C81B7A4-5ED7-49D6-963F-0138F4E2E883@netapp.com> Date: Fri, 27 Jul 2012 09:46:16 -0700 Message-ID: <092b01cd6c17$57f7fd10$07e7f730$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNa8bgJPsCdWLrKEGPSYGp7ceEdpc9x4QA//+O1YA= Content-Language: en-us Cc: 'Internet Area' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 16:46:20 -0000 > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Eggert, Lars > Sent: Friday, July 27, 2012 9:29 AM > To: mohamed.boucadair@orange.com > Cc: Internet Area > Subject: Re: [Int-area] Completion of working group last call for > draft-ietf-intarea-nat-reveal-analysis-02 > > On Jul 27, 2012, at 0:09, mohamed.boucadair@orange.com wrote: > > The argument I heard in Paris meeting for including a recommendation > > is to help vendors to select the solution to implement in their > > devices. They can not provide the same feature using 8 implementation > > options. That argument makes sense to me. > > We're not at the stage yet where we can recommend anything to vendors. > We first need to determine if there even is a solution where the > benefits outweigh the drawbacks. What analysis is missing from draft-ietf-intarea-nat-reveal-analysis to weigh the drawbacks of the 8 solutions. -d From dwing@cisco.com Fri Jul 27 11:03:48 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2995111E80DE for ; Fri, 27 Jul 2012 11:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.477 X-Spam-Level: X-Spam-Status: No, score=-110.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wZ61PCYDsZl0 for ; Fri, 27 Jul 2012 11:03:47 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1D911E80A5 for ; Fri, 27 Jul 2012 11:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2130; q=dns/txt; s=iport; t=1343412227; x=1344621827; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=vEq17rp60jj6mTh7tstWf+63no1b2IeJHLboPzBTS5M=; b=S5eJQ4aZgaPTN8Iv50uo4JJ9wtFd1dTeecVeMiMjpMipRtznrs1cQbVY 0MLuNQFTDY7wcp5pG0fePuSWZg5tgVg3ddWmkkqXsUmdJyQOEDd2vYmt2 X5HjPE2dArPCSdm91M1Ku3KJDdWnoH+/5/mgvESiEqvQAb5TX5Mr2OwTr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFTXElCrRDoJ/2dsb2JhbABFqhyPM4EHgiABAQEECAoBCg0QPwwBAwIJDgECBAEBAScHGSMKCQgBAQQBEgsQB4dqDJo2oFmLUAGGcwOITYUMiQONE4Fmgn+BPw X-IronPort-AV: E=Sophos;i="4.77,668,1336348800"; d="scan'208";a="50670091" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 27 Jul 2012 18:03:46 +0000 Received: from dwingWS (sjc-vpn3-605.cisco.com [10.21.66.93]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6RI3kgG030216; Fri, 27 Jul 2012 18:03:46 GMT From: "Dan Wing" To: "'Wesley Eddy'" , References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> In-Reply-To: <50118D83.9010704@mti-systems.com> Date: Fri, 27 Jul 2012 11:03:46 -0700 Message-ID: <098e01cd6c22$2adce560$8096b020$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1rXTnU94MA3ALNRTO6im4MGqu3wgAwH+Qw Content-Language: en-us Cc: 'Internet Area' , 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 18:03:48 -0000 > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Wesley Eddy > Sent: Thursday, July 26, 2012 11:34 AM > To: sarikaya@ieee.org > Cc: Internet Area; Behcet Sarikaya > Subject: Re: [Int-area] Completion of working group last call for > draft-ietf-intarea-nat-reveal-analysis-02 > > On 7/26/2012 1:08 PM, Behcet Sarikaya wrote: > > On Thu, Jul 26, 2012 at 3:25 AM, > wrote: > >> Dear Suresh, all, > >> > >> After reading received comments, the major point we need to discuss > is whether the WG wants to remove Section 3.3 or maintain it. I'm > waiting for a feedback from the WG for the direction to take. I will > implement any change requested by the WG. > >> > > > > Section 3.3 seems to give preference to one specific solution, as > such > > it is against the whole spirit of this document. > > > > I suggest removing it. > > > > > +1 > > In fact, I suggest that the draft should clearly say that it's > doubtful whether a solution actually *needs* to be identified and > recommended, especially ones that are implemented awkwardly in other > layers. I can't make technical sense of which of the 8 approaches are "awkward," in your analysis. I have my own analysis, but the document does not do an evaluation on "awkwardness". The underlying problem was identified in Section 13.1 "Abuse Logging and Penalty Boxes" of RFC6269, "Issues with IP Address Sharing", http://tools.ietf.org/html/rfc6269#section-13.1. That was an INTAREA document. Hence, that is why the analysis document is also an INTAREA document. My view is the penalty box problem described in Section 13.1 of RFC6269 is real. My view is the penalty box problem will continue to grow so long as there are IPv4-accessible servers and so long as there are IPv6 clients (NAT64) or IPv4 clients accessing those IPv4 servers. There appear to be different views on the size and trajectory of the problem (getting worse versus getting better). Perhaps discussing those views would be beneficial. -d From wes@mti-systems.com Sat Jul 28 00:27:58 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF9421F857D for ; Sat, 28 Jul 2012 00:27:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMep4ZyfhJHF for ; Sat, 28 Jul 2012 00:27:57 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id B6F8921F84CE for ; Sat, 28 Jul 2012 00:27:57 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q6S7RuBY005215 for ; Sat, 28 Jul 2012 03:27:56 -0400 Authentication-Results: cm-omr7 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [46.21.99.28] ([46.21.99.28:63537] helo=[10.8.0.22]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 53/8C-04833-A7493105; Sat, 28 Jul 2012 03:27:56 -0400 Message-ID: <50139472.9000901@mti-systems.com> Date: Sat, 28 Jul 2012 03:27:46 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dan Wing References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> In-Reply-To: <098e01cd6c22$2adce560$8096b020$@com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Internet Area' , 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 07:27:58 -0000 On 7/27/2012 2:03 PM, Dan Wing wrote: >> -----Original Message----- >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of Wesley Eddy >> Sent: Thursday, July 26, 2012 11:34 AM >> To: sarikaya@ieee.org >> Cc: Internet Area; Behcet Sarikaya >> Subject: Re: [Int-area] Completion of working group last call for >> draft-ietf-intarea-nat-reveal-analysis-02 >> >> On 7/26/2012 1:08 PM, Behcet Sarikaya wrote: >>> On Thu, Jul 26, 2012 at 3:25 AM, >> wrote: >>>> Dear Suresh, all, >>>> >>>> After reading received comments, the major point we need to discuss >> is whether the WG wants to remove Section 3.3 or maintain it. I'm >> waiting for a feedback from the WG for the direction to take. I will >> implement any change requested by the WG. >>>> >>> >>> Section 3.3 seems to give preference to one specific solution, as >> such >>> it is against the whole spirit of this document. >>> >>> I suggest removing it. >>> >> >> >> +1 >> >> In fact, I suggest that the draft should clearly say that it's >> doubtful whether a solution actually *needs* to be identified and >> recommended, especially ones that are implemented awkwardly in other >> layers. > > I can't make technical sense of which of the 8 approaches are "awkward," in > your analysis. I have my own analysis, but the document does not do an > evaluation on "awkwardness". > > > The underlying problem was identified in Section 13.1 "Abuse Logging and > Penalty Boxes" of RFC6269, "Issues with IP Address Sharing", > http://tools.ietf.org/html/rfc6269#section-13.1. That was an INTAREA > document. > > Hence, that is why the analysis document is also an INTAREA document. > > > My view is the penalty box problem described in Section 13.1 of RFC6269 is > real. My view is the penalty box problem will continue to grow so long as > there are IPv4-accessible servers and so long as there are IPv6 clients > (NAT64) or IPv4 clients accessing those IPv4 servers. There appear to be > different views on the size and trajectory of the problem (getting worse > versus getting better). Perhaps discussing those views would be beneficial. > Hi Dan - The problem is real because there are bits of deployed code built on an assumption that was good maybe 12 years ago, that IP addresses could be tied to users or machines. Since this is totally broken now, the solution is to get rid of them and use the proper identifiers for whatever it is that these system are trying to do. Building kludges in other layers to supplement the IP address is not the answer. Since the analysis in the document already indicates that each of the 8 solutions has non-starter properties to them, I consider that to make them pretty "awkward". Recommending any of them is like saying "this is the best tasting crap we could find." -- Wes Eddy MTI Systems From Francis.Dupont@fdupont.fr Sun Jul 29 10:29:48 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1C721F85E0 for ; Sun, 29 Jul 2012 10:29:48 -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=[AWL=0.000, BAYES_00=-2.599] 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 kHNoDnqtuatl for ; Sun, 29 Jul 2012 10:29:47 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 4D24D21F85D8 for ; Sun, 29 Jul 2012 10:29:47 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q6THThhF014403; Sun, 29 Jul 2012 19:29:43 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201207291729.q6THThhF014403@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Fri, 27 Jul 2012 09:46:16 PDT. <092b01cd6c17$57f7fd10$07e7f730$@com> Date: Sun, 29 Jul 2012 19:29:43 +0200 Sender: Francis.Dupont@fdupont.fr Cc: 'Internet Area' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 17:29:48 -0000 In your previous mail you wrote: > What analysis is missing from draft-ietf-intarea-nat-reveal-analysis > to weigh the drawbacks of the 8 solutions. => there are two kinds of drawbacks: the technical drawbacks and the not technical drawbacks, e.g., the impact on privacy... Note because if the second kind I am strongly against the 3.3 (if not changed into a SHOULD NOT :-) and I suggested to "NOT RECOMMEND" all proposals perhaps at the exception of one (i.e., leave one proposal without any recommendation). Regards Francis.Dupont@fdupont.fr PS: IMHO only the not advertised port set makes sense, any other proposal deployed in countries where privacy is protected (any place in European Union for instance) should make the ISP to be sued... PPS: we can postpone the discussion to Berlin meeting (privacy concerns are pushed in Germany clearly behind the sillyness point :-). From dwing@cisco.com Sun Jul 29 23:17:29 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F8521F847B for ; Sun, 29 Jul 2012 23:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 bUVAsXQYsQBC for ; Sun, 29 Jul 2012 23:17:28 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6477721F847A for ; Sun, 29 Jul 2012 23:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1455; q=dns/txt; s=iport; t=1343629048; x=1344838648; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=WBJZ1CswyRGuhtgMCHcrnKnRwQet8hKmjkD2LG0xIMs=; b=M5W9A/xIWb5f1To/PYSZoz64qSic68nwhwdevMLXmM94DgeBYD929K8S goT5TQcZ9Uz4nTfzRWfEJLLJA/S10sZeTxQQbgXtTq5qXjAt69eQPy/65 BXPElHIK8rgdkDZ5KQOXVlHCzkGKpJrF9Qr2hK5omZueLzxJ4ALN596Gd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigKAMElFlCrRDoJ/2dsb2JhbABFqiGOIAQDgQeBB4IgAQEBBAgKAQoNED8MAQMCCQ8BAQQBAQEnBxkjCgkIAQEEEwsQB4dqmiWfOYtQChCDLIMcA4hNhQyWF4Fmgn+BPw X-IronPort-AV: E=Sophos;i="4.77,677,1336348800"; d="scan'208";a="50929188" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 30 Jul 2012 06:17:28 +0000 Received: from dwingWS (sjc-vpn7-495.cisco.com [10.21.145.239]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6U6HQjw031666; Mon, 30 Jul 2012 06:17:27 GMT From: "Dan Wing" To: References: Your message of Fri, 27 Jul 2012 09:46:16 PDT. <092b01cd6c17$57f7fd10$07e7f730$@com> <201207291729.q6THThhF014403@givry.fdupont.fr> In-Reply-To: <201207291729.q6THThhF014403@givry.fdupont.fr> Date: Sun, 29 Jul 2012 23:17:26 -0700 Message-ID: <0cec01cd6e1a$fe3650f0$faa2f2d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1tr79PWHNPhTTgRbaXPca9RxIyXQAaxk7Q Content-Language: en-us Cc: 'Internet Area' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 06:17:29 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Sunday, July 29, 2012 10:30 AM > To: Dan Wing > Cc: 'Eggert, Lars'; mohamed.boucadair@orange.com; 'Internet Area' > Subject: Re: [Int-area] Completion of working group last call for > draft-ietf-intarea-nat-reveal-analysis-02 > > In your previous mail you wrote: > > > What analysis is missing from draft-ietf-intarea-nat-reveal-analysis > > to weigh the drawbacks of the 8 solutions. > > => there are two kinds of drawbacks: the technical drawbacks and the > not > technical drawbacks, e.g., the impact on privacy... Note because if the > second kind I am strongly against the 3.3 (if not changed into a SHOULD > NOT :-) and I suggested to "NOT RECOMMEND" all proposals perhaps at > the exception of one (i.e., leave one proposal without any > recommendation). > > Regards > > Francis.Dupont@fdupont.fr > > PS: IMHO only the not advertised port set makes sense, any other > proposal > deployed in countries where privacy is protected (any place in European > Union for instance) should make the ISP to be sued... > PPS: we can postpone the discussion to Berlin meeting (privacy concerns > are pushed in Germany clearly behind the sillyness point :-). You keep saying "privacy", but without explaining the problem or how IPv4 address sharing makes privacy better or worse than IPv6. Without that, -d From mohamed.boucadair@orange.com Sun Jul 29 23:41:41 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1330011E811A for ; Sun, 29 Jul 2012 23:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 q3M2HRx-nv6r for ; Sun, 29 Jul 2012 23:41:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7AB11E80F1 for ; Sun, 29 Jul 2012 23:41:40 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E91DD324251; Mon, 30 Jul 2012 08:41:38 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CC606238056; Mon, 30 Jul 2012 08:41:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 30 Jul 2012 08:41:31 +0200 From: To: "Eggert, Lars" Date: Mon, 30 Jul 2012 08:41:29 +0200 Thread-Topic: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: AQHNa8bgJPsCdWLrKEGPSYGp7ceEdpc9x4QAgAOdVfA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E7F0@PUEXCB1B.nanterre.francetelecom.fr> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E4A17E507@PUEXCB1B.nanterre.francetelecom.fr> <0C81B7A4-5ED7-49D6-963F-0138F4E2E883@netapp.com> In-Reply-To: <0C81B7A4-5ED7-49D6-963F-0138F4E2E883@netapp.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.29.60329 Cc: Internet Area Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 06:41:41 -0000 Dear Lars, Could be more explict and explain what is missing in draft-ietf-intarea-nat= -reveal-analysis-02 to reach that stage? Thanks. Cheers, Med =20 >-----Message d'origine----- >De : Eggert, Lars [mailto:lars@netapp.com]=20 >Envoy=E9 : vendredi 27 juillet 2012 18:29 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : sarikaya@ieee.org; Internet Area >Objet : Re: [Int-area] Completion of working group last call=20 >for draft-ietf-intarea-nat-reveal-analysis-02 > >On Jul 27, 2012, at 0:09, mohamed.boucadair@orange.com wrote: >> The argument I heard in Paris meeting for including a=20 >recommendation is to help vendors to select the solution to=20 >implement in their devices. They can not provide the same=20 >feature using 8 implementation options. That argument makes=20 >sense to me.=20 > >We're not at the stage yet where we can recommend anything to=20 >vendors. We first need to determine if there even is a=20 >solution where the benefits outweigh the drawbacks. > >Lars= From brian@innovationslab.net Mon Jul 30 07:48:40 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A7511E80BA for ; Mon, 30 Jul 2012 07:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vZzhtOKVIMci for ; Mon, 30 Jul 2012 07:48:39 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 83FF111E80A4 for ; Mon, 30 Jul 2012 07:48:39 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 332918809B for ; Mon, 30 Jul 2012 07:48:39 -0700 (PDT) Received: from dhcp-5588.meeting.ietf.org (dhcp-5588.meeting.ietf.org [130.129.85.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 20C211602C0 for ; Mon, 30 Jul 2012 07:48:39 -0700 (PDT) Message-ID: <50169EC6.1020109@innovationslab.net> Date: Mon, 30 Jul 2012 10:48:38 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: int-area@ietf.org References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E4A17E507@PUEXCB1B.nanterre.francetelecom.fr> <0C81B7A4-5ED7-49D6-963F-0138F4E2E883@netapp.com> <94C682931C08B048B7A8645303FDC9F36E4A17E7F0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E7F0@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 14:48:40 -0000 Med, My opinion, not as AD, is that this document should not make a recommendation. This document should be strictly an analysis so that we have a baseline understanding of all the existing solutions. Brian On 7/30/12 2:41 AM, mohamed.boucadair@orange.com wrote: > Dear Lars, > > Could be more explict and explain what is missing in > draft-ietf-intarea-nat-reveal-analysis-02 to reach that stage? > > Thanks. > > Cheers, Med > > >> -----Message d'origine----- De : Eggert, Lars >> [mailto:lars@netapp.com] Envoyé : vendredi 27 juillet 2012 18:29 À >> : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarikaya@ieee.org; Internet >> Area Objet : Re: [Int-area] Completion of working group last call >> for draft-ietf-intarea-nat-reveal-analysis-02 >> >> On Jul 27, 2012, at 0:09, mohamed.boucadair@orange.com wrote: >>> The argument I heard in Paris meeting for including a >> recommendation is to help vendors to select the solution to >> implement in their devices. They can not provide the same feature >> using 8 implementation options. That argument makes sense to me. >> >> We're not at the stage yet where we can recommend anything to >> vendors. We first need to determine if there even is a solution >> where the benefits outweigh the drawbacks. >> >> Lars > _______________________________________________ Int-area mailing > list Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From Francis.Dupont@fdupont.fr Mon Jul 30 09:09:20 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6542621F85C7 for ; Mon, 30 Jul 2012 09:09:20 -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=[AWL=0.000, BAYES_00=-2.599] 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 wbG1SJ5P4zhQ for ; Mon, 30 Jul 2012 09:09:20 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id AC21921F85C3 for ; Mon, 30 Jul 2012 09:09:19 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q6UG9GDd097171; Mon, 30 Jul 2012 18:09:16 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201207301609.q6UG9GDd097171@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Sun, 29 Jul 2012 23:17:26 PDT. <0cec01cd6e1a$fe3650f0$faa2f2d0$@com> Date: Mon, 30 Jul 2012 18:09:16 +0200 Sender: Francis.Dupont@fdupont.fr Cc: 'Internet Area' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:09:20 -0000 In your previous mail you wrote: > You keep saying "privacy", but without explaining the problem or > how IPv4 address sharing makes privacy better or worse than IPv6. => there are two levels about the privacy problem: the technical one which is explained/addressed in the draft (section 4) and worse the way it can be perceived which is less (or not at all) rational as the long and silly history of the "privacy extensions for stateless address autoconfiguration in IPv6" (RFC 3041 and 4941) has shown. So there is a technical and a "political" argument against the whole HOST_ID idea. Unfortunately the IETF (and this mailing list) can only deal with the first one. Regards Francis.Dupont@fdupont.fr PS: to discuss about the technical point IMHO no HOST_ID proposal brings a clear advantage. The real issue (address sharing breaks the address == identity assumption) has to be solved by the impacted part (i.e., people should accept this assumption doesn't apply)... From lars@netapp.com Mon Jul 30 09:40:51 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593BF11E80A2 for ; Mon, 30 Jul 2012 09:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.45 X-Spam-Level: X-Spam-Status: No, score=-10.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Q3I6F+jlEyKp for ; Mon, 30 Jul 2012 09:40:50 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B009F11E809C for ; Mon, 30 Jul 2012 09:40:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,681,1336374000"; d="p7s'?scan'208";a="669715607" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 30 Jul 2012 09:40:50 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q6UGe6t4025608; Mon, 30 Jul 2012 09:40:50 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.13]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0298.004; Mon, 30 Jul 2012 09:40:35 -0700 From: "Eggert, Lars" To: "mohamed.boucadair@orange.com" Thread-Topic: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: AQHNa8bgJPsCdWLrKEGPSYGp7ceEdpc9x4QAgAOdVfCAAR0GAA== Date: Mon, 30 Jul 2012 16:40:35 +0000 Message-ID: <1CF3C17B-6A48-442C-A0B4-1783497A7525@netapp.com> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E4A17E507@PUEXCB1B.nanterre.francetelecom.fr> <0C81B7A4-5ED7-49D6-963F-0138F4E2E883@netapp.com> <94C682931C08B048B7A8645303FDC9F36E4A17E7F0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E7F0@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_7BB77DCC-0801-4BDA-B9BC-965984DD733D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:40:51 -0000 --Apple-Mail=_7BB77DCC-0801-4BDA-B9BC-965984DD733D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Jul 29, 2012, at 23:41, mohamed.boucadair@orange.com wrote: > Could be more explict and explain what is missing in = draft-ietf-intarea-nat-reveal-analysis-02 to reach that stage? the goal of this draft was to survey the options. I don't think it = should make any recommendation at all. If there was a solution for which the benefits outweigh the drawbacks = (which I don't think there is), the adoption of a document that = specifies it by the IETF and the eventual publication of that document = would constitute an IETF recommendation. Lars= --Apple-Mail=_7BB77DCC-0801-4BDA-B9BC-965984DD733D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDczMDE2NDAzNVowIwYJKoZIhvcNAQkEMRYEFF4o jwkUXa+gh2z5jbre15+CdwynMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAIWEWdsA RjEIJRwX0IojHhVl/rxU22YhlQJbFPxU4qAunoWYgBN8SRWMBlxkr+EsRrqgMGjQqJaVe4O9/550 eK3c377scWjO7laYowAwuQKKf9fl/TkzuRnRL+LAo1sRhT57bDVsmMwVISkEbHDVTfre3QN8oVKg Ppq3W40mPRuZXKgZuuIhBxvGJ2roAAD6MprC6MY5fUuwCpBVzycABcxOmRQ/tfhDZGoUQ777V+F3 WtldflKmhEF4/AmCPmQv/sBvF09ik9PsMuJa6O9AK+2m4xZvt3wcsKdQUIqNkyZu/Dru/mJsm5ZL cStTVcvlL4qnWXKdhsnlW5fCT70i1KYAAAAAAAA= --Apple-Mail=_7BB77DCC-0801-4BDA-B9BC-965984DD733D-- From suresh.krishnan@ericsson.com Mon Jul 30 09:55:23 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC24621F8665 for ; Mon, 30 Jul 2012 09:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Q+PlotDOEsIY for ; Mon, 30 Jul 2012 09:55:23 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 50F1321F8625 for ; Mon, 30 Jul 2012 09:55:14 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6UGt2k9010514 for ; Mon, 30 Jul 2012 11:55:07 -0500 Received: from [164.48.125.20] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 30 Jul 2012 12:55:04 -0400 Message-ID: <5016BC64.8010405@ericsson.com> Date: Mon, 30 Jul 2012 09:55:00 -0700 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Internet Area References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: [Int-area] Fwd: Need volunteers for the NomCom X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:55:24 -0000 Hi all, If you are eligible for the Nomcom, please consider volunteering. Thanks Suresh -------- Original Message -------- Subject: Need volunteers for the NomCom Date: Sun, 29 Jul 2012 23:22:33 -0400 From: NomCom Chair To: Working Group Chairs We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. I understand that not all IETF participants read the IETF announce list frequently. Therefore, if you would be willing to inform active participants in your working groups about this year's call for NomCom volunteers, I would greatly appreciate it. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org From sm@resistor.net Tue Jul 31 15:14:56 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5EE11E813B for ; Tue, 31 Jul 2012 15:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 XTUPQl1LYgro for ; Tue, 31 Jul 2012 15:14:54 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8894C11E8137 for ; Tue, 31 Jul 2012 15:14:54 -0700 (PDT) Received: from sm-THINK.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q6VMElRr022597; Tue, 31 Jul 2012 15:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1343772892; bh=9HK9h9SkcoI2K4BjIVwt3jaSYNiMpZnx9fz5MhcyjlE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fty83ILbbzp8MnMxZABEZQ2hKmOubb4vl0xdXGDDCqHWMNFHIDyP+2lbWpqjkjs25 yG4ova5sOZYG61b1Xh5BOo2o0xkGTUVCfXlVQynokNvzaHHrL/IPo42xsuymKIloKx GgWFhOKUfFxF4Qn5j+bwJ7jhiTZKCb9GocaJANCY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1343772892; i=@resistor.net; bh=9HK9h9SkcoI2K4BjIVwt3jaSYNiMpZnx9fz5MhcyjlE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KrULnSb3dTyANgkXHCpEovxAwhYXEqOj7MCDZryvgPwoMrGL0/HTmqVvrP3fC8no0 ep7w09s3twbjNDURglhbu4ggu+1CLOurtXuS7oluVgIDfDyXmSIFfxTGp26L2TwBZ0 nQlGySNCTTEQp4rIngMVYe72PGTsmSuHyV0cSkts= Message-Id: <6.2.5.6.2.20120731145553.09028080@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 31 Jul 2012 15:14:33 -0700 To: mohamed.boucadair@orange.com From: SM In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E2C8@PUEXCB1B.nanter re.francetelecom.fr> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2C8@PUEXCB1B.nanterre.francetelecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: int-area@ietf.org Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 22:14:56 -0000 Hi Med, At 01:17 AM 7/26/2012, mohamed.boucadair@orange.com wrote: >Med: The issue is described in detail in RFC6269: > >" > In addition, there are web tie-ins into different blacklists that web > administrators subscribe to in order to redirect users with infected > machines (e.g., detect the presence of a worm) to a URL that says > "Hey, your machine is infected!". With address sharing, someone > else's worm can interfere with the ability to access the service for > other subscribers sharing the same IP address. That's not an issue; it's more of an action which may be taken once the relevant host is identified. Thinking aloud, this is more like creating a problem by sharing the same identifier and creating another identifier to solve that problem. :-) >Med: IPv4 address sharing is already deployed but still the widely >deployed model is to assign public IP addresses to customers. Would >you be OK with changing "due to the introduction of CGNs" to "due to >the massive introduction of CGNs"? If the technology has significant deployment, it does not make that difference whether it is introduced or massively introduced. I suggest using the word "deployed" to keep it simple. >Med: I'm mainly thinking about NPTv6 (RFC6296). I am not keen on seeing this in IPv6 unless we are already running out of IPv6 addresses. :-) >Med: Host Identity Protocol. A reference is provided in the draft. I suggest expanding on first use (RFC Editor nits). >Med: X-Forwarded-For. The acronym is expanded in the draft but in >Section A.8.1. I will make sure it is expanded in first use. Ok. >Med: Could you please indicate what is not fair about that sentence? Thanks. I would not compare solutions at different layers and qualify them as a fair comparison. >Med: XFF allows to prepend a list of IP addresses when several >address sharing, application proxies, etc. are in the path. The term >compatible is used to indicate XFF can be used in that scenario. If >you have any better wording, please advise. Thanks. I'll get back to you on this. >Med: Anonymity may be provided; see for instance the TOR service. There was some discussion about privacy and identifiers for another draft. You might end up getting in a long discussion about the privacy angle. >Med: XFF is for instance an HTTP header, "via" is a SIP header, etc. >Would it be better if we change "Application Header" to "Application >Protocols Headers"? If I recall correctly, the term is "message header fields". Regards, -sm P.S. Sorry for being short. From mohamed.boucadair@orange.com Tue Jul 31 23:56:39 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B225621F84A0 for ; Tue, 31 Jul 2012 23:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] 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 6IYhQRrHONUt for ; Tue, 31 Jul 2012 23:56:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D5E7521F849B for ; Tue, 31 Jul 2012 23:56:38 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 6F6122644A1; Wed, 1 Aug 2012 08:56:37 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 56EB24C027; Wed, 1 Aug 2012 08:56:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 1 Aug 2012 08:56:28 +0200 From: To: SM Date: Wed, 1 Aug 2012 08:56:27 +0200 Thread-Topic: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 Thread-Index: Ac1vaeZYchiO/t3eS8+FXhmsRdnrTgARsYsQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17ECDA@PUEXCB1B.nanterre.francetelecom.fr> References: <6.2.5.6.2.20120707005917.08734c80@elandnews.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2C8@PUEXCB1B.nanterre.francetelecom.fr> <6.2.5.6.2.20120731145553.09028080@resistor.net> In-Reply-To: <6.2.5.6.2.20120731145553.09028080@resistor.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.1.50315 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 06:56:39 -0000 Dear SM, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : SM [mailto:sm@resistor.net]=20 >Envoy=E9 : mercredi 1 ao=FBt 2012 00:15 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : int-area@ietf.org >Objet : RE: [Int-area] Comments on=20 >draft-ietf-intarea-nat-reveal-analysis-02 > >Hi Med, >At 01:17 AM 7/26/2012, mohamed.boucadair@orange.com wrote: >>Med: The issue is described in detail in RFC6269: >> >>" >> In addition, there are web tie-ins into different=20 >blacklists that web >> administrators subscribe to in order to redirect users=20 >with infected >> machines (e.g., detect the presence of a worm) to a URL that says >> "Hey, your machine is infected!". With address sharing, someone >> else's worm can interfere with the ability to access the=20 >service for >> other subscribers sharing the same IP address. > >That's not an issue; it's more of an action which may be taken once=20 >the relevant host is identified. Med: That's the point, if there is not identifier to disambiguate hosts sha= ring the same address, all these users will be impacted. > >Thinking aloud, this is more like creating a problem by sharing the=20 >same identifier and creating another identifier to solve that=20 >problem. :-) > >>Med: IPv4 address sharing is already deployed but still the widely=20 >>deployed model is to assign public IP addresses to customers. Would=20 >>you be OK with changing "due to the introduction of CGNs" to "due to=20 >>the massive introduction of CGNs"? > >If the technology has significant deployment, it does not make that=20 >difference whether it is introduced or massively introduced. I=20 >suggest using the word "deployed" to keep it simple. Med: OK. The text is updated accordingly. > >>Med: I'm mainly thinking about NPTv6 (RFC6296). > >I am not keen on seeing this in IPv6 unless we are already running=20 >out of IPv6 addresses. :-) Med: NPTv6 does not deal with IP address depletion. Multi-homed enterprise = site may for instance be tempted to "play" with that kind of techniques. I'= m not advocating for it not arguing against. The document does only raise t= he point.=20 > >>Med: Host Identity Protocol. A reference is provided in the draft. > >I suggest expanding on first use (RFC Editor nits). Med: Done. > >>Med: X-Forwarded-For. The acronym is expanded in the draft but in=20 >>Section A.8.1. I will make sure it is expanded in first use. > >Ok. > >>Med: Could you please indicate what is not fair about that=20 >sentence? Thanks. > >I would not compare solutions at different layers and qualify them as=20 >a fair comparison. Med: The purpose of the draft is to analyse and compare between alternative= channels to convey the HOST_ID information. A set of criteria to assess th= e efficiency of each channel to solve encountered issues is used for that p= urpose. =20 > >>Med: XFF allows to prepend a list of IP addresses when several=20 >>address sharing, application proxies, etc. are in the path. The term=20 >>compatible is used to indicate XFF can be used in that scenario. If=20 >>you have any better wording, please advise. Thanks. > >I'll get back to you on this. > >>Med: Anonymity may be provided; see for instance the TOR service. > >There was some discussion about privacy and identifiers for another=20 >draft. You might end up getting in a long discussion about=20 >the privacy angle. > >>Med: XFF is for instance an HTTP header, "via" is a SIP header, etc.=20 >>Would it be better if we change "Application Header" to "Application=20 >>Protocols Headers"? > >If I recall correctly, the term is "message header fields". Med: I wanted to have a generic title in which "Application" is mentioned. = I will use "Inject Application Protocol Message Headers". I can change it i= f there are better suggestions. Thanks. > >Regards, >-sm > >P.S. Sorry for being short.=20 > >=