[apps-discuss] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
Eliot Lear <lear@cisco.com> Sat, 02 June 2012 13:00 UTC
Return-Path: <lear@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@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 <lear@cisco.com>
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" <apps-discuss@ietf.org>
X-Enigmail-Version: 1.4.1
Content-Type: multipart/alternative; boundary="------------060505010801040403010400"
Cc: Internet Area <int-area@ietf.org>, IETF Discussion <ietf@ietf.org>
Subject: [apps-discuss] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Jun 2012 13:00:51 -0000
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
- [apps-discuss] Apps Directorate Review of draft-i… Eliot Lear
- Re: [apps-discuss] [Int-area] Apps Directorate Re… Joe Touch
- Re: [apps-discuss] [Int-area] Apps Directorate Re… Glen Zorn
- Re: [apps-discuss] [Int-area] Apps Directorate Re… C. M. Heard
- Re: [apps-discuss] [Int-area] Apps Directorate Re… C. M. Heard
- Re: [apps-discuss] [Int-area] Apps Directorate Re… Joe Touch
- Re: [apps-discuss] [Int-area] Apps Directorate Re… Joe Touch