From Fred.L.Templin@boeing.com Fri Jun 1 08:59:24 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 9A50011E8088 for ; Fri, 1 Jun 2012 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 5sf6YpyOOuTl for ; Fri, 1 Jun 2012 08:59:23 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1311E8074 for ; Fri, 1 Jun 2012 08:59:23 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q51FxMUc022162 for ; Fri, 1 Jun 2012 10:59:22 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q51FxMW3022153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 10:59:22 -0500 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q51FxMoP009918; Fri, 1 Jun 2012 10:59:22 -0500 Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q51FxL3V009864 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 1 Jun 2012 10:59:22 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 1 Jun 2012 08:59:21 -0700 From: "Templin, Fred L" To: Julien Laganier Date: Fri, 1 Jun 2012 08:59:19 -0700 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt Thread-Index: Ac0/eyBLbGcWspGyS4mjEF3Dup24/wABDDvwACPKINA= Message-ID: References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> <4FC7A337.70406@isi.edu> <4FC7B0E8.5020306@isi.edu> <4FC7D5BD.4010001@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.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: Fri, 01 Jun 2012 15:59:24 -0000 Below I'll give an alternative which should make the MSL issue go away: > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Templin, Fred L > Sent: Thursday, May 31, 2012 4:02 PM > To: Julien Laganier > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update- > 05.txt >=20 > Hi Julien, >=20 > > -----Original Message----- > > From: Julien Laganier [mailto:julien.ietf@gmail.com] > > Sent: Thursday, May 31, 2012 3:17 PM > > To: Templin, Fred L > > Cc: int-area@ietf.org; Joe Touch; Brian Haberman > > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update- > > 05.txt > > > > Hi Fred, > > > > With WG Co-chair hat on, > > > > Changing MSL to Maximum Datagram Lifetime is a minor and almost > > editorial change that I recommend we make since the use of MSL and > > possible reference to RFC793 could implicitly restrict the scope of > > the document to TCP, which is not the case -- this doc applies to IP > > irrespective of the transport protocol in use. >=20 > From Section 3.3.2 of RFC1122: >=20 > "If the reassembly timeout is set too high, buffer > resources in the receiving host will be tied up too long, > and the MSL (Maximum Segment Lifetime) [TCP:1] will be > larger than necessary. The MSL controls the maximum rate > at which fragmented datagrams can be sent using distinct > values of the 16-bit Ident field; a larger MSL lowers the > maximum rate. The TCP specification [TCP:1] arbitrarily > assumes a value of 2 minutes for MSL. This sets an upper > limit on a reasonable reassembly timeout value." >=20 > This clearly shows that the value 120 for reassembly timeout > came from the TCP MSL specification, and does not take other > transport protocols into account. For historical correctness, > the 'ipv4-id-update' document should therefore continue to > cite "MSL" but should identify RFC793 (and not RFC791) as > the reference. In draft-ietf-intarea-ipv4-id-update Section 1, where it says: "In IPv4, the Identification (ID) field is a 16-bit value that is unique for every datagram for a given source address, destination address, and protocol, such that it does not repeat within the Maximum Segment Lifetime (MSL) [RFC791][RFC1122]." simply delete the citation of [RFC791] and do not replace it with anything. The text from RFC1122 (cited above) gives sufficient explanation of MSL and where it came from. Replacing MSL with "maximum datagram lifetime" would be incorrect. Per RFC791, maximum datagram lifetime is told by the TTL which can be at maximum 255 - not 120. Fred fred.l.templin@boeing.com > > As to the other change about the reassembly timeout, I agree with Joe > > that this is out-of-scope of this document in its current form, and I > > do not think it is appropriate to use a document as a vehicle for > > changes that are out-of-scope. Furthermore, this document as been in > > the hands of the Intarea WG for a fair amount of time during which the > > consensus has been that no changes should be made to the core IP > > specifications unless something is broken. Your proposal to include > > considerations on reassembly timeouts does not seem to fix something > > that is broken in IP and as such is against the consensus of that WG. > > With both these in mind I recommend against it. >=20 > Based on recent discussions on the v6ops list regarding > tunneling protocols that perform IPv4 fragmentation, I had > an obligation to ask for a more favorable reassembly timeout. > Others who were involved in those discussions have had fair > opportunity to comment have not done so. I therefore withdraw > the request. >=20 > > That being said it is up to our AD and the IESG to consider your IETF > > Last Call comments as well as my recommendation on a disposition. >=20 > Please forward the above comments for their consideration > also. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Regards, > > > > --julien > > > > On Thu, May 31, 2012 at 1:34 PM, Joe Touch wrote: > > > Hi, Fred, > > > > > > > > > On 5/31/2012 12:13 PM, Templin, Fred L wrote: > > >> > > >> Hi Joe, > > > > > > ... > > > > > >> As you know, the bar for documents that would update > > >> bedrock specifications such as RFC791 and RFC1122 is > > >> set very high indeed. That your document has made it > > >> to this level of maturation is a tribute to your many > > >> years of concerted effort, which would best be amortized > > >> if this useful addition can also be applied. > > > > > > > > > As you note, this doc has taken a lot to get to its current state. > > > > > > Nothing should be added that isn't core to its purpose AND agreed by > the > > > community. Your proposed change doesn't meet either criteria - your > only > > > reason for adding it is to get a "free ride", and I don't think that'= s > > an > > > appropriate suggestion for *any* doc. > > > > > > > > >>>>> - reducing the timeout is not current practice AFAIK > > >>>>> =A0 =A0 =A0 =A0so we'd be adding a new recommendation, rather > > >>>>> =A0 =A0 =A0 =A0than even documenting existing practice > > >>>>> > > >>>>> - my conclusion, based on "keep it simple", is to not include thi= s > > >>>>> recommendation in this document > > >>>> > > >>>> > > >>>> Let me ask, do you know of any implementations that have > > >>>> ever benefitted from keeping the fragments of an incomplete > > >>>> reassembly for longer than 60sec? (Linux for example only > > >>>> waits 30sec before discarding fragments.) > > >>> > > >>> > > >>> I don't, but that's a discussion that should happen - as you note > > below > > >>> - involving those on a different list as well, for a different > reason. > > >>> Linux does a lot of things that are not standard, but that alone is > > not > > >>> necessarily a reason to document it as best practice - e.g., why ar= e > > you > > >>> not suggesting 30 sec? > > >> > > >> > > >> 60sec is consistent with both RFC1122 and RFC2460. > > > > > > > > > RFC2460 isn't relevant to the reassembly requirements of IPv4; if it > > were, > > > it would be 120 seconds, or would have updated RFC1122 itself. > > > > > > ... > > > > > >> If you want to call it MSL you need to cite RFC793. If > > >> you want to change all occurrences of MSL to something > > >> else, then you could get away with citing only RFC1122. > > >> My preference would be to keep it as MSL and cite RFC793. > > > > > > > > > It's only MSL in that one place in this doc, but it's intended to > refer > > to > > > maximum datagram lifetime since this doc has no other reference to > > transport > > > protocols. > > > > > > Joe > > > > > > _______________________________________________ > > > 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 Fri Jun 1 18:12:07 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 5AD0811E8095 for ; Fri, 1 Jun 2012 18:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 PDSDvppG1o1d for ; Fri, 1 Jun 2012 18:12:06 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id D634511E8094 for ; Fri, 1 Jun 2012 18:12:06 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q521BaL8000626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jun 2012 18:11:37 -0700 (PDT) Message-ID: <4FC96848.5090502@isi.edu> Date: Fri, 01 Jun 2012 18:11:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <20120530184618.6000.74469.idtracker@ietfa.amsl.com> <4FC66DFA.3010300@isi.edu> <4FC6A602.4050507@isi.edu> <4FC6B9A1.4060409@isi.edu> <4FC7A337.70406@isi.edu> <4FC7B0E8.5020306@isi.edu> <4FC7D5BD.4010001@isi.edu> In-Reply-To: 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: Julien Laganier , "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.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: Sat, 02 Jun 2012 01:12:07 -0000 FWIW, that solution works for me. Joe On 6/1/2012 8:59 AM, Templin, Fred L wrote: > Below I'll give an alternative which should make the > MSL issue go away: > ... > In draft-ietf-intarea-ipv4-id-update Section 1, where it > says: > > "In IPv4, the Identification (ID) field is a 16-bit value that is > unique for every datagram for a given source address, destination > address, and protocol, such that it does not repeat within the > Maximum Segment Lifetime (MSL) [RFC791][RFC1122]." > > simply delete the citation of [RFC791] and do not replace > it with anything. The text from RFC1122 (cited above) gives > sufficient explanation of MSL and where it came from. > > Replacing MSL with "maximum datagram lifetime" would be > incorrect. Per RFC791, maximum datagram lifetime is told > by the TTL which can be at maximum 255 - not 120. > > Fred > fred.l.templin@boeing.com From lear@cisco.com Sat Jun 2 06:00: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 6E65821F8665; Sat, 2 Jun 2012 06:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yL8b4D4QqjZ5; Sat, 2 Jun 2012 06:00:50 -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 E16E221F865A; Sat, 2 Jun 2012 06:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=4616; q=dns/txt; s=iport; t=1338642050; x=1339851650; h=message-id:date:from:mime-version:to:cc:subject; bh=pOhlmC+eumfcB67KHpASchgU1L+bBCW8LzySfz2x8hQ=; b=MssU/AE/GnLbWt1c2cvdQ7+AoI8GMfJgEVV5jgYKO5bq6HyQSIvb21wQ ZliqoiIRbPPa5ukZCrC1/3wx4i0/8OSwy2SjU4sXdxCvFB+I26T+sLBGx /mIbJJvUInGwCjcSvDfSmg+8CugrGxL2zKcO6RPIIJsY7g1AzM6JeZx10 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIcNyk+Q/khL/2dsb2JhbABFhU6uT4EHghgBAQEDEwEQVQEFGhANFgsCCwMCAQIBSwEMAQcBAR6HZAWXUY0Wkg2LEYR+gRIDlRuOEIFmgmI X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208,217";a="5291680" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 02 Jun 2012 13:00:48 +0000 Received: from dhcp-10-61-99-222.cisco.com (dhcp-10-61-99-222.cisco.com [10.61.99.222]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q52D0lu1024078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2012 13:00:48 GMT Message-ID: <4FCA0E7F.7020109@cisco.com> Date: Sat, 02 Jun 2012 15:00:47 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: draft-ietf-intarea-ipv4-update.all@tools.ietf.org, "apps-discuss@ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: multipart/alternative; boundary="------------060505010801040403010400" Cc: Internet Area , IETF Discussion Subject: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 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, 02 Jun 2012 13:00:51 -0000 This is a multi-part message in MIME format. --------------060505010801040403010400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Document: draft-ietf-intarea-ipv4-id-update-05 Title: Updated Specification of the IPv4 ID Field Reviewer: Eliot Lear Review Date: 2 June 2012 IETF Last Call Date: 31 May 2012 Summary: This draft is quite well written, and is *very* nearly ready for publication. This draft is well written, and from the applications perspective represents an important step to improving performance and error reduction. It uses a new requirements call-out style that I would class as experimental, but not bad. It is worth people reading this draft and deciding if they agree with Joe's approach. Major issues: None (Yay!). Minor issues: Section 4 needs to be reconciled a bit with Section 6.1. Specifically: > The IPv4 ID field can be useful for other purposes. And >> IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly. My suggestion is to drop the above sentence from Section 4. In Section 6.1: > Datagram de-duplication can be accomplished using hash-based > duplicate detection for cases where the ID field is absent. Under what circumstances would the ID field be absent? > >> Sources of non-atomic IPv4 datagrams using strong integrity checks > MAY reuse the ID within MSL values smaller than is typical. Is the issue really the source using strong integrity checks or the destination in this context? What is typical? Nit: Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? Eliot --------------060505010801040403010400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Document: draft-ietf-intarea-ipv4-id-update-05
Title: Updated Specification of the IPv4 ID Field
Reviewer: Eliot Lear
Review Date: 2 June 2012
IETF Last Call Date: 31 May  2012


Summary: This draft is quite well written, and is very nearly ready for publication.

This draft is well written, and from the applications perspective represents an important step to improving performance and error reduction.  It uses a new requirements call-out style that I would class as experimental, but not bad.  It is worth people reading this draft and deciding if they agree with Joe's approach.

Major issues:

None (Yay!).

Minor issues:

Section 4 needs to be reconciled a bit with Section 6.1.  Specifically:

 The IPv4 ID field can be useful for other purposes.


And

  >> IPv4 ID field MUST NOT be used for purposes other than
   fragmentation and reassembly.

My suggestion is to drop the above sentence from Section 4.

In Section 6.1:


   Datagram de-duplication can be accomplished using hash-based
   duplicate detection for cases where the ID field is absent.

Under what circumstances would the ID field be absent?

   >> Sources of non-atomic IPv4 datagrams using strong integrity checks
   MAY reuse the ID within MSL values smaller than is typical.

Is the issue really the source using strong integrity checks or the destination in this context?  What is typical?

Nit:

Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3?


Eliot


--------------060505010801040403010400-- From touch@isi.edu Sat Jun 2 07:50:30 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 0C95321F8535; Sat, 2 Jun 2012 07:50:30 -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 hdACuNWqRnzV; Sat, 2 Jun 2012 07:50:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDFA21F8531; Sat, 2 Jun 2012 07:50:29 -0700 (PDT) Received: from [192.168.1.95] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q52Eo1WA022182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 2 Jun 2012 07:50:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <4FCA0E7F.7020109@cisco.com> Date: Sat, 2 Jun 2012 07:50:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCA0E7F.7020109@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1278) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area , draft-ietf-intarea-ipv4-update.all@tools.ietf.org, IETF Discussion , "apps-discuss@ietf.org" Subject: Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 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, 02 Jun 2012 14:50:30 -0000 Hi, Eliot, On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote: >=20 > Document: draft-ietf-intarea-ipv4-id-update-05 > Title: Updated Specification of the IPv4 ID Field > Reviewer: Eliot Lear > Review Date: 2 June 2012 > IETF Last Call Date: 31 May 2012 >=20 >=20 > Summary: This draft is quite well written, and is very nearly ready = for publication. >=20 > This draft is well written, and from the applications perspective = represents an important step to improving performance and error = reduction. It uses a new requirements call-out style that I would class = as experimental, but not bad. It is worth people reading this draft and = deciding if they agree with Joe's approach. >=20 > Major issues: >=20 > None (Yay!). >=20 > Minor issues: >=20 > Section 4 needs to be reconciled a bit with Section 6.1. = Specifically: >=20 >> The IPv4 ID field can be useful for other purposes.=20 >=20 >=20 > And >=20 > >> IPv4 ID field MUST NOT be used for purposes other than > fragmentation and reassembly. >=20 >=20 > My suggestion is to drop the above sentence from Section 4. The two are not contradictory - the ID can be useful, but generating it = correctly is prohibitive and typically not done. > In Section 6.1: >=20 >=20 >> Datagram de-duplication can be accomplished using hash-based >> duplicate detection for cases where the ID field is absent. >>=20 >=20 > Under what circumstances would the ID field be absent? Replace "absent" with "known not unique". >> >> Sources of non-atomic IPv4 datagrams using strong integrity = checks >> MAY reuse the ID within MSL values smaller than is typical. >>=20 >=20 > Is the issue really the source using strong integrity checks or the = destination in this context? What is typical? The onus is on the source (of non-atomic datagrams) - if it includes = strong integrity checks (that are presumably validated by the receiver), = it then has more flexibility in its generation of the iD values. > Nit: >=20 > Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? Not subsections of 2, but perhaps "3, 3.1, 3.2"?=20 Joe= From heard@pobox.com Sat Jun 2 21:21: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 93DE111E808A for ; Sat, 2 Jun 2012 21:21:42 -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.372, 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 oJPTuipe7JGp for ; Sat, 2 Jun 2012 21:21:41 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E7911E8089 for ; Sat, 2 Jun 2012 21:21:39 -0700 (PDT) Received: (qmail 19638 invoked from network); 2 Jun 2012 21:21:39 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Jun 2012 21:21:39 -0700 Date: Sat, 2 Jun 2012 21:21:38 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IETF Discussion In-Reply-To: Message-ID: References: <4FCA0E7F.7020109@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Internet Area , Apps Discussion Subject: Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 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, 03 Jun 2012 04:21:42 -0000 On Sat, 2 Jun 2012, Joe Touch wrote: > Hi, Eliot, > > On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote: > > > > > Document: draft-ietf-intarea-ipv4-id-update-05 > > Title: Updated Specification of the IPv4 ID Field > > Reviewer: Eliot Lear > > Review Date: 2 June 2012 > > IETF Last Call Date: 31 May 2012 > > > > > > Summary: This draft is quite well written, and is very nearly ready for publication. > > > > This draft is well written, and from the applications > > perspective represents an important step to improving > > performance and error reduction. It uses a new requirements > > call-out style that I would class as experimental, but not bad. > > It is worth people reading this draft and deciding if they agree > > with Joe's approach. FWIW, I thought it was helpful. > > Major issues: > > > > None (Yay!). > > > > Minor issues: > > > > Section 4 needs to be reconciled a bit with Section 6.1. Specifically: > > > >> The IPv4 ID field can be useful for other purposes. > > > > > > And > > > > >> IPv4 ID field MUST NOT be used for purposes other than > > fragmentation and reassembly. > > > > > > My suggestion is to drop the above sentence from Section 4. > > The two are not contradictory - the ID can be useful, but > generating it correctly is prohibitive and typically not done. After re-reading the text I agree with Eliot that it is confusing. Dropping the sentence in Section 4 would be fine. Another possibility would be to reword it along the following lines: Other uses have been envisioned for the IPv4 ID field. > > In Section 6.1: > > > > > >> Datagram de-duplication can be accomplished using hash-based > >> duplicate detection for cases where the ID field is absent. > >> > > > > Under what circumstances would the ID field be absent? > > Replace "absent" with "known not unique". Better, I think, would be "not known to be unique". > >> >> Sources of non-atomic IPv4 datagrams using strong integrity checks > >> MAY reuse the ID within MSL values smaller than is typical. > >> > > > > Is the issue really the source using strong integrity checks or > > the destination in this context? What is typical? > > The onus is on the source (of non-atomic datagrams) - if it > includes strong integrity checks (that are presumably validated by > the receiver), it then has more flexibility in its generation of > the iD values. > > > Nit: > > > > Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? > > Not subsections of 2, but perhaps "3, 3.1, 3.2"? That would be fine but I'm also OK with leaving the document the way it is (especially if it would get it into the publication queue faster). //cmh From heard@pobox.com Sat Jun 2 22: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 F164221F851E for ; Sat, 2 Jun 2012 22:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 y2GZ9-nZBETs for ; Sat, 2 Jun 2012 22:06:45 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469CA21F8526 for ; Sat, 2 Jun 2012 22:06:45 -0700 (PDT) Received: (qmail 31369 invoked from network); 2 Jun 2012 22:00:02 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Jun 2012 22:00:02 -0700 Date: Sat, 2 Jun 2012 22:00:01 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: IETF Discussion In-Reply-To: <1338699237.5620.3.camel@gwz-laptop> Message-ID: References: <4FCA0E7F.7020109@cisco.com> <1338699237.5620.3.camel@gwz-laptop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Glen Zorn , Internet Area , Apps Discussion Subject: Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 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, 03 Jun 2012 05:06:46 -0000 On Sun, 3 Jun 2012, Glen Zorn wrote: > On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: > > ... > > > > > In Section 6.1: > > > > > > > > > > > >> Datagram de-duplication can be accomplished using hash-based > > > >> duplicate detection for cases where the ID field is absent. > > > >> > > > > > > > > Under what circumstances would the ID field be absent? > > > > > > Replace "absent" with "known not unique". > > > > Better, I think, would be "not known to be unique". > > Except that the two are not semantically equivalent. Indeed. That was why I suggested the change. //cmh From glenzorn@gmail.com Sat Jun 2 21:54:02 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 2C24C21F848A; Sat, 2 Jun 2012 21:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 oc0xjAjGOSAI; Sat, 2 Jun 2012 21:54:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 944BE21F8466; Sat, 2 Jun 2012 21:54:01 -0700 (PDT) Received: by dacx6 with SMTP id x6so4350273dac.31 for ; Sat, 02 Jun 2012 21:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:content-type:x-mailer:content-transfer-encoding :mime-version; bh=SW8hKCbAQgq3FmuGaCh+kPbttGlsBCtrkCRMo3sbY+Q=; b=rfh+j1fhkn/UQjPKIUGY4adFK/7MyusW7H68QgCgrqR7q+mc1hhhy8DBYHs68vm15E 1riNaXtM3F4DzWshYzO5oUCBdlN6MOlAFnPzho6QhLJ3S4Vzn2aSbfBJkc9HXE0dECUP /CDc2Bbg71aBfT/yn4sdiKg4DkO6wevXuepTFgiQRAgjz3dNFoAzEqX0AlO3tVVdrWSr FlcNdMUQyiktlDJdvkamyvqxxq5KBkVsbfvVdzzbcmnEBN/v94TNOXtmFSnpZXkGK+FH UOIZ5J6raVNcvqf98+KHvXp+Az0bN3QgiCqUkNFoyI+UwvI2FzoARxwFRZLOym+lBTYO u/cQ== Received: by 10.68.219.162 with SMTP id pp2mr25898071pbc.85.1338699241397; Sat, 02 Jun 2012 21:54:01 -0700 (PDT) Received: from [192.168.1.99] (ppp-58-11-241-69.revip2.asianet.co.th. [58.11.241.69]) by mx.google.com with ESMTPS id iv8sm326444pbc.53.2012.06.02.21.53.59 (version=SSLv3 cipher=OTHER); Sat, 02 Jun 2012 21:54:00 -0700 (PDT) Message-ID: <1338699237.5620.3.camel@gwz-laptop> From: Glen Zorn To: "C. M. Heard" Date: Sun, 03 Jun 2012 11:53:57 +0700 In-Reply-To: References: <4FCA0E7F.7020109@cisco.com> Organization: Network Zen Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2- Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailman-Approved-At: Mon, 04 Jun 2012 08:11:07 -0700 Cc: glenzorn@gmail.com, Internet Area , IETF Discussion , Apps Discussion Subject: Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 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, 03 Jun 2012 04:54:02 -0000 On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: ... > > > In Section 6.1: > > > > > > > > >> Datagram de-duplication can be accomplished using hash-based > > >> duplicate detection for cases where the ID field is absent. > > >> > > > > > > Under what circumstances would the ID field be absent? > > > > Replace "absent" with "known not unique". > > Better, I think, would be "not known to be unique". Except that the two are not semantically equivalent. ... From touch@isi.edu Tue Jun 5 17:42:35 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 87C5B21F85DB; Tue, 5 Jun 2012 17:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=-0.106, 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 D3R-xKWdhNX0; Tue, 5 Jun 2012 17:42:34 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id DB3FB21F8602; Tue, 5 Jun 2012 17:42:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q560gFO9026508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2012 17:42:15 -0700 (PDT) Message-ID: <4FCEA767.30404@isi.edu> Date: Tue, 05 Jun 2012 17:42:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "C. M. Heard" References: <4FCA0E7F.7020109@cisco.com> In-Reply-To: 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: Apps Discussion , Internet Area , IETF Discussion Subject: Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 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, 06 Jun 2012 00:42:35 -0000 Hi, all, On 6/2/2012 9:21 PM, C. M. Heard wrote: > On Sat, 2 Jun 2012, Joe Touch wrote: >> Hi, Eliot, >> >> On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote: >> >>> >>> Document: draft-ietf-intarea-ipv4-id-update-05 >>> Title: Updated Specification of the IPv4 ID Field >>> Reviewer: Eliot Lear >>> Review Date: 2 June 2012 >>> IETF Last Call Date: 31 May 2012 >>> >>> >>> Summary: This draft is quite well written, and is very nearly ready for publication. >>> >>> This draft is well written, and from the applications >>> perspective represents an important step to improving >>> performance and error reduction. It uses a new requirements >>> call-out style that I would class as experimental, but not bad. >>> It is worth people reading this draft and deciding if they agree >>> with Joe's approach. > > FWIW, I thought it was helpful. > >>> Major issues: >>> >>> None (Yay!). >>> >>> Minor issues: >>> >>> Section 4 needs to be reconciled a bit with Section 6.1. Specifically: >>> >>>> The IPv4 ID field can be useful for other purposes. >>> >>> >>> And >>> >>> >> IPv4 ID field MUST NOT be used for purposes other than >>> fragmentation and reassembly. >>> >>> >>> My suggestion is to drop the above sentence from Section 4. >> >> The two are not contradictory - the ID can be useful, but >> generating it correctly is prohibitive and typically not done. > > After re-reading the text I agree with Eliot that it is confusing. > Dropping the sentence in Section 4 would be fine. Another > possibility would be to reword it along the following lines: > > Other uses have been envisioned for the IPv4 ID field. That's much better, IMO. >>> In Section 6.1: >>> >>> >>>> Datagram de-duplication can be accomplished using hash-based >>>> duplicate detection for cases where the ID field is absent. >>>> >>> >>> Under what circumstances would the ID field be absent? >> >> Replace "absent" with "known not unique". > > Better, I think, would be "not known to be unique". Sure. >>>> >> Sources of non-atomic IPv4 datagrams using strong integrity checks >>>> MAY reuse the ID within MSL values smaller than is typical. >>>> >>> >>> Is the issue really the source using strong integrity checks or >>> the destination in this context? What is typical? >> >> The onus is on the source (of non-atomic datagrams) - if it >> includes strong integrity checks (that are presumably validated by >> the receiver), it then has more flexibility in its generation of >> the iD values. >> >>> Nit: >>> >>> Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? >> >> Not subsections of 2, but perhaps "3, 3.1, 3.2"? > > That would be fine but I'm also OK with leaving the document the way > it is (especially if it would get it into the publication queue > faster). I'll check. I'm not sure if it matters whether I do a rev inbetween IETF LC and final RFC Editor processing. If so, I'll check on this to see if it can be done with minimal content impact (maybe some fluff to explain the flow, but no semantic changes). Joe From touch@isi.edu Tue Jun 5 17:46:11 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 EB1FB21F86B7; Tue, 5 Jun 2012 17:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 8hEsg8yX+SFg; Tue, 5 Jun 2012 17:46:10 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2C921F86AA; Tue, 5 Jun 2012 17:46:10 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q560jqv7027613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2012 17:45:52 -0700 (PDT) Message-ID: <4FCEA840.9030204@isi.edu> Date: Tue, 05 Jun 2012 17:45:52 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "C. M. Heard" References: <4FCA0E7F.7020109@cisco.com> <1338699237.5620.3.camel@gwz-laptop> In-Reply-To: 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: Glen Zorn , Internet Area , IETF Discussion , Apps Discussion Subject: Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05 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, 06 Jun 2012 00:46:11 -0000 On 6/2/2012 10:00 PM, C. M. Heard wrote: > On Sun, 3 Jun 2012, Glen Zorn wrote: >> On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: >> >> ... >> >>>>> In Section 6.1: >>>>> >>>>> >>>>>> Datagram de-duplication can be accomplished using hash-based >>>>>> duplicate detection for cases where the ID field is absent. >>>>>> >>>>> >>>>> Under what circumstances would the ID field be absent? >>>> >>>> Replace "absent" with "known not unique". >>> >>> Better, I think, would be "not known to be unique". >> >> Except that the two are not semantically equivalent. Sorry - I didn't catch that. When the datagram is atomic, under the new rules, we would *assume* that the ID field was not unique for a src/dst/protocol triple within the expected time (120 seconds). I.e., the ID field is "assumed to not be useful for such purposes", which might be more accurate. Joe > > Indeed. That was why I suggested the change. > > //cmh > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From talmi@marvell.com Thu Jun 7 05:06:35 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 4902E21F8637; Thu, 7 Jun 2012 05:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NHqODWJwUQoV; Thu, 7 Jun 2012 05:06:34 -0700 (PDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by ietfa.amsl.com (Postfix) with ESMTP id B4D4721F8630; Thu, 7 Jun 2012 05:06:02 -0700 (PDT) From: Tal Mizrahi To: "int-area@ietf.org" , "armd@ietf.org" Date: Thu, 7 Jun 2012 15:05:59 +0300 Thread-Topic: Request for comments on draft-nachum-sarp-02 Thread-Index: Ac1EpaDwLHCN8bhBSpS7qHT3cDrLSg== Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F856863F@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F856863FILMB01marve_" MIME-Version: 1.0 Cc: Youval Nachum , "Linda Dunbar \(linda.dunbar@huawei.com\)" Subject: [Int-area] Request for comments on draft-nachum-sarp-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, 07 Jun 2012 12:06:35 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F856863FILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have posted a new draft of "Scaling the Address Resolution Protocol for = Large Data Centers (SARP)". The previous version was posted as an independent informational draft, but = we have changed the current draft to Proposed Standard in the INTAREA WG. There was a brief discussion about previous versions of this draft in the A= RMD mailing list. https://datatracker.ietf.org/doc/draft-nachum-sarp Comments will be appreciated. Thanks, Tal Mizrahi. --_000_74470498B659FA4687F0B0018C19A89C01A0F856863FILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have po= sted a new draft of “Scaling the Address Resolution Protocol for Larg= e Data Centers (SARP)”.

The previo= us version was posted as an independent informational draft, but we have ch= anged the current draft to Proposed Standard in the INTAREA WG.<= /p>

There was a brief discussion about previous version= s of this draft in the ARMD mailing list.

 

https://datatracker.ietf.org/doc/draft-nach= um-sarp

 

Comments will be appreciated.

 

Thanks,

Tal Mizrahi.

= --_000_74470498B659FA4687F0B0018C19A89C01A0F856863FILMB01marve_-- From suresh.krishnan@ericsson.com Fri Jun 8 07:06: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 8946E21F885B for ; Fri, 8 Jun 2012 07:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 8CUU5E6CPDWL for ; Fri, 8 Jun 2012 07:06:20 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B853821F88A2 for ; Fri, 8 Jun 2012 07:06:18 -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 q58E6Hdd000855 for ; Fri, 8 Jun 2012 09:06:18 -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, 8 Jun 2012 10:06:11 -0400 Message-ID: <4FD206D3.3010200@ericsson.com> Date: Fri, 8 Jun 2012 10:06:11 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Internet Area X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [Int-area] 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, 08 Jun 2012 14:06:20 -0000 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 From suresh.krishnan@ericsson.com Mon Jun 11 10:57:06 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 5556621F854C for ; Mon, 11 Jun 2012 10:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 TjGD-dgATSvF for ; Mon, 11 Jun 2012 10:57:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C15A221F8543 for ; Mon, 11 Jun 2012 10:57:05 -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 q5BHv1SC029064 for ; Mon, 11 Jun 2012 12:57:05 -0500 Received: from [142.133.112.108] (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, 11 Jun 2012 13:57:04 -0400 Message-ID: <4FD6316F.3020003@ericsson.com> Date: Mon, 11 Jun 2012 13:57:03 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Internet Area X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [Int-area] New draft about formally obsoleting some historic IPv4 options 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, 11 Jun 2012 17:57:06 -0000 Hi all, Here is a new draft about formally obsoleting some IPv4 options that are not being used in practice. The draft is available at Text: http://www.ietf.org/id/draft-gp-intarea-obsolete-ipv4-options-iana-00.txt HTML: http://tools.ietf.org/html/draft-gp-intarea-obsolete-ipv4-options-iana-00 The authors have requested that this work be taken up by intarea. Please take a look at the draft and send your comments to the mailing list. Thanks Suresh and Julien From lars@netapp.com Tue Jun 12 00:37:00 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 0923221F85CE for ; Tue, 12 Jun 2012 00:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.56 X-Spam-Level: X-Spam-Status: No, score=-9.56 tagged_above=-999 required=5 tests=[AWL=1.039, 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 DNy4ribcxzpV for ; Tue, 12 Jun 2012 00:36:59 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8717121F85C7 for ; Tue, 12 Jun 2012 00:36:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,755,1330934400"; d="p7s'?scan'208";a="654820774" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 12 Jun 2012 00:36:44 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q5C7ai13009993; Tue, 12 Jun 2012 00:36:44 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.15]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0298.004; Tue, 12 Jun 2012 00:36:44 -0700 From: "Eggert, Lars" To: Suresh Krishnan Thread-Topic: [Int-area] New draft about formally obsoleting some historic IPv4 options Thread-Index: AQHNR/ue6nzP3IVaXUirg93jgIPzdZb2wZkA Date: Tue, 12 Jun 2012 07:36:43 +0000 Message-ID: <27EAC4DE-D5E3-4E17-B83C-186CEF37223D@netapp.com> References: <4FD6316F.3020003@ericsson.com> In-Reply-To: <4FD6316F.3020003@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_329FCC3A-D1B8-4C40-B9E2-B06739315C67"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] New draft about formally obsoleting some historic IPv4 options 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, 12 Jun 2012 07:37:00 -0000 --Apple-Mail=_329FCC3A-D1B8-4C40-B9E2-B06739315C67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, shouldn't we at the same time also be making the RFCs that originally = registered these option numbers Historic? Lars On Jun 11, 2012, at 19:57, Suresh Krishnan wrote: > Hi all, > Here is a new draft about formally obsoleting some IPv4 options that > are not being used in practice. The draft is available at >=20 > Text: > = http://www.ietf.org/id/draft-gp-intarea-obsolete-ipv4-options-iana-00.txt >=20 > HTML: > = http://tools.ietf.org/html/draft-gp-intarea-obsolete-ipv4-options-iana-00 >=20 > The authors have requested that this work be taken up by intarea. = Please > take a look at the draft and send your comments to the mailing list. >=20 > Thanks > Suresh and Julien > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Apple-Mail=_329FCC3A-D1B8-4C40-B9E2-B06739315C67 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYxMjA3MzY0M1owIwYJKoZIhvcNAQkEMRYEFGTt S2B6JY1kEGqF3EBr0s3wdrv7MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAHQHfhEi 5PRqt7Q7SKPHBMO65zuOjFLzDoT/7mxc+OyLlQrUg1QK6PKgsXUmzfSjV62NIM1CybN4xlXZ3zAb JXRZPvXPGmnzBKRW6tMlwxCHJRYyfp93dxldkS2qGcXA0Etj5EJwafM6WKbtmwAiSVPhxpZ6TXIM PZi8meLVIRnSkAsYr3VGVkn0aPxzwyYFwFUm/R21mqbZPm1031JAnTEvylcY/a5CXz7batas61kI Up2doJ6gtFZor+FisZ0blo+dDLWgk9RCRJSFuFiXEzUeC9ICWoCRjh9gLFjBfjealZoMM4QiXSgE DaPzz+gWiHpR1VGJ+WL5qv0JBCEEda0AAAAAAAA= --Apple-Mail=_329FCC3A-D1B8-4C40-B9E2-B06739315C67-- From brian.e.carpenter@gmail.com Tue Jun 12 04:56:06 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 06A6E21F8672 for ; Tue, 12 Jun 2012 04:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGUDqpoVREwt for ; Tue, 12 Jun 2012 04:56:05 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43A4A21F8670 for ; Tue, 12 Jun 2012 04:56:05 -0700 (PDT) Received: by eekd4 with SMTP id d4so3059490eek.31 for ; Tue, 12 Jun 2012 04:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=W/GHbU5qXh+P+h/RojnGExNQS4ux5lUpRVUrdntmOXI=; b=ZxoBYuTEz3/60XsZa3Y/ZMZOC8RcDGpF+odJVi+gqiSWMkEOPPTdWwn7htEWt2U2wr sOBU2H8rrszEKghgjdahBRjWsSSTS6Um4CJKvzh0UN1o6kjik2QzZfDNFDgWJjZ8T6SP veTGJ9J2R6C6C6/RC9n7xrv0t76P6nVuxlkRS8o6Ht22J9/Nr1waIZ/Kn5PjJfSBjdbb +WWT+CT5xvIDSXYtd1J7gWcp8SNNdJR6UXSz2xSIEnh6YnmneYeJ2QacoZeOXjnspxsd OW0k/WGzblqo04dC8T99Ywx/xMCjeKE3FKS+wu8PGPHWxqtiIxn9EQW+7ioKlCK6n1Sg Ec5g== Received: by 10.14.127.202 with SMTP id d50mr6861095eei.193.1339502164284; Tue, 12 Jun 2012 04:56:04 -0700 (PDT) Received: from [128.232.110.88] (c088.al.cl.cam.ac.uk. [128.232.110.88]) by mx.google.com with ESMTPS id s47sm63530074eef.4.2012.06.12.04.56.02 (version=SSLv3 cipher=OTHER); Tue, 12 Jun 2012 04:56:03 -0700 (PDT) Message-ID: <4FD72E4F.7080502@gmail.com> Date: Tue, 12 Jun 2012 12:55:59 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: int-area@ietf.org, draft-carpenter-flow-label-balancing@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Int-area] [Fwd: I-D Action: draft-carpenter-flow-label-balancing-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: Tue, 12 Jun 2012 11:56:06 -0000 This is an update of the work presented to int-area in Paris. The authors would be interested in comments, including whether this should be pursued in the Internet area, the Transport area, or elsewhere. Brian, Sheng, Willy -------- Original Message -------- Subject: I-D Action: draft-carpenter-flow-label-balancing-01.txt Date: Tue, 12 Jun 2012 04:09:24 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the IPv6 Flow Label for Server Load Balancing Author(s) : Brian Carpenter Sheng Jiang Willy Tarreau Filename : draft-carpenter-flow-label-balancing-01.txt Pages : 12 Date : 2012-06-12 Abstract: This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-flow-label-balancing There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-carpenter-flow-label-balancing-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From suresh.krishnan@ericsson.com Tue Jun 12 21:02: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 9A66A11E80AB for ; Tue, 12 Jun 2012 21:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 io53iVnTIHJo for ; Tue, 12 Jun 2012 21:02:29 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 22CA811E80A4 for ; Tue, 12 Jun 2012 21:02:29 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5D42RKU030281; Tue, 12 Jun 2012 23:02:28 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.57]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 13 Jun 2012 00:02:25 -0400 From: Suresh Krishnan To: "Eggert, Lars" Date: Wed, 13 Jun 2012 00:02:24 -0400 Thread-Topic: [Int-area] New draft about formally obsoleting some historic IPv4 options Thread-Index: AQHNR/ue6nzP3IVaXUirg93jgIPzdZb2wZkAgADhHQM= Message-ID: <13bo5f0seo5vg2u5m55y5n15.1339560137769@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Internet Area Subject: Re: [Int-area] New draft about formally obsoleting some historic IPv4 options 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, 13 Jun 2012 04:02:29 -0000 Hi Lars, Sounds like a reasonable thing to do if this work is to proceed further a= long. Thanks Suresh "Eggert, Lars" wrote: Hi, shouldn't we at the same time also be making the RFCs that originally regis= tered these option numbers Historic? Lars On Jun 11, 2012, at 19:57, Suresh Krishnan wrote: > Hi all, > Here is a new draft about formally obsoleting some IPv4 options that > are not being used in practice. The draft is available at > > Text: > http://www.ietf.org/id/draft-gp-intarea-obsolete-ipv4-options-iana-00.txt > > HTML: > http://tools.ietf.org/html/draft-gp-intarea-obsolete-ipv4-options-iana-00 > > The authors have requested that this work be taken up by intarea. Please > take a look at the draft and send your comments to the mailing list. > > Thanks > Suresh and Julien > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From fernando.gont.netbook.win@gmail.com Tue Jun 12 21:43:11 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 D36EA21F8678 for ; Tue, 12 Jun 2012 21:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 EYonqD8if9cH for ; Tue, 12 Jun 2012 21:43:10 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 384D921F865F for ; Tue, 12 Jun 2012 21:43:02 -0700 (PDT) Received: by ggnc4 with SMTP id c4so113072ggn.31 for ; Tue, 12 Jun 2012 21:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=y0mKi9zgqcVl7R0w2/8Y8EaH617LWyyAzxtu9RZqLbc=; b=La8P6tSDDbYOx4182txp+dwbhGqUafv9tpPfEE1Nqz6KHBZlcJ2bhl2qPNwL4H+DYK OjWxAZvAbDZNEayWHKzS+zOTTh1GvOlmo/d0QqrVWNFFbzCX7WEipaZdKU0cgWa6KK2C wMTLm/e1OCrW66xFM2i095sedtEfTcVvvZFCB5j3z4ev8kK7MU7xDCRb8k8w2JsZ49j6 Zt4uQfhTQ8hRLonlGrucG5rkk0GGHRY9F0Z+o/75FxdGJuQkmFznv0iuAaffVxgyoIGq x3tOu/ovNQL58/qgKTtPukuUXdsg15yEYawHr38A0L5Hr1r0Az6jkcmw/37ROhJoc7dA 05qg== Received: by 10.236.177.104 with SMTP id c68mr30730759yhm.76.1339562581302; Tue, 12 Jun 2012 21:43:01 -0700 (PDT) Received: from [192.168.0.168] (61-128-17-190.fibertel.com.ar. [190.17.128.61]) by mx.google.com with ESMTPS id q36sm2900650anh.6.2012.06.12.21.42.56 (version=SSLv3 cipher=OTHER); Tue, 12 Jun 2012 21:43:00 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FD8198A.8080901@gont.com.ar> Date: Wed, 13 Jun 2012 01:39:38 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Eggert, Lars" References: <4FD6316F.3020003@ericsson.com> <27EAC4DE-D5E3-4E17-B83C-186CEF37223D@netapp.com> In-Reply-To: <27EAC4DE-D5E3-4E17-B83C-186CEF37223D@netapp.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Internet Area Subject: Re: [Int-area] New draft about formally obsoleting some historic IPv4 options 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, 13 Jun 2012 04:43:12 -0000 Hi, Lars, On 06/12/2012 04:36 AM, Eggert, Lars wrote: > Hi, > > shouldn't we at the same time also be making the RFCs that originally registered these option numbers Historic? You're absolutely right. The next rev will do this. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From suresh.krishnan@ericsson.com Wed Jun 27 08:03: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 3EE3421F85F6 for ; Wed, 27 Jun 2012 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 PFkmn-QfvWxH for ; Wed, 27 Jun 2012 08:03:50 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC8C21F873E for ; Wed, 27 Jun 2012 08:03:50 -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 q5RF3mq0030188 for ; Wed, 27 Jun 2012 10:03:49 -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; Wed, 27 Jun 2012 11:03:47 -0400 Message-ID: <4FEB20D2.1060905@ericsson.com> Date: Wed, 27 Jun 2012 11:03:46 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "int-area@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [Int-area] Call for agenda items 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, 27 Jun 2012 15:03:51 -0000 Hi all, The intarea WG will be meeting in Vancouver (we have requested a 2 hour slot) and we are in the process of setting the agenda. Please send us your request for slots detailing * Name of the draft * Short description of why you think the item needs to be discussed in the intarea meeting * Whether the draft has already been presented or will be presented in some other wg/bof. Thanks Julien and Suresh From suresh.krishnan@ericsson.com Wed Jun 27 08:58:06 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 681BB21F87B6 for ; Wed, 27 Jun 2012 08:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 Vew6QPfjt0nO for ; Wed, 27 Jun 2012 08:58:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CA0EA21F8610 for ; Wed, 27 Jun 2012 08:58:05 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5RFvbnF011407 for ; Wed, 27 Jun 2012 10:58:05 -0500 Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 27 Jun 2012 11:57:27 -0400 Message-ID: <4FEB2D67.1010901@ericsson.com> Date: Wed, 27 Jun 2012 11:57:27 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Internet Area References: <4FD206D3.3010200@ericsson.com> In-Reply-To: <4FD206D3.3010200@ericsson.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [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: Wed, 27 Jun 2012 15:58:06 -0000 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 From sarikaya2012@gmail.com Wed Jun 27 09:12:31 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 E7F7021F8744 for ; Wed, 27 Jun 2012 09:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 Fd1mZHLQyyey for ; Wed, 27 Jun 2012 09:12:30 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2644E21F8738 for ; Wed, 27 Jun 2012 09:12:30 -0700 (PDT) Received: by yenq13 with SMTP id q13so1176115yen.31 for ; Wed, 27 Jun 2012 09:12:29 -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=h79zQfeqmlpXkMTyuJ1lqwitBw+mDawsXdA+JZfITJY=; b=I2vh2sHOeWzzHTVHfN4GzCw0Hxs1STo26F9BbkzIiu+PE/12kQryqY9Z/Ue4CDY6ue utExXilx/fbm12ufX5U+HXPbfycOvjHJ2ESd4VhEprS0rhB4DiWv4I1XbgnvhzpnPLNv V75aGoIm+ieJYrDJVNJVFj5pY3Fftwt39K3xXqom064OLXmh1h+kgZLw1YeQwzpfbFxH xW/kME7Mj1YQKxSN6odTG7GWyX0/btyw/LPQHCOlp4EHkdbnl2es136rgDIPGnDguCgR ytjLo9M2v5S0dXvwioIk5NKrAfrpbaH/89tcvhcLDB3bttOGh1CoMiAybusJIZqcLOKw EmGQ== MIME-Version: 1.0 Received: by 10.50.160.198 with SMTP id xm6mr2335365igb.0.1340813547239; Wed, 27 Jun 2012 09:12:27 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Wed, 27 Jun 2012 09:12:27 -0700 (PDT) In-Reply-To: <4FEB2D67.1010901@ericsson.com> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> Date: Wed, 27 Jun 2012 11:12:27 -0500 Message-ID: From: Behcet Sarikaya To: Suresh Krishnan 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: Wed, 27 Jun 2012 16:12:31 -0000 Support. Regards, Behcet On Wed, Jun 27, 2012 at 10:57 AM, Suresh Krishnan wrote: > Hi all, > =A0The 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, >> =A0 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