[ippm] AD review of draft-ietf-ippm-bw-capacity-04.txt
Lars Eggert <lars.eggert@netlab.nec.de> Thu, 14 December 2006 10:54 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoEM-0000tU-EA; Thu, 14 Dec 2006 05:54:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoEL-0000sx-EO for ippm@ietf.org; Thu, 14 Dec 2006 05:54:25 -0500
Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoEI-0003Rl-Rx for ippm@ietf.org; Thu, 14 Dec 2006 05:54:25 -0500
Received: from lars.local (p54AD127F.dip0.t-ipconnect.de [84.173.18.127]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4BBC713CF82; Thu, 14 Dec 2006 11:59:14 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 5740A2AEAEA; Thu, 14 Dec 2006 11:54:17 +0100 (CET)
In-Reply-To: <45767D65.7000207@ripe.net>
References: <45767D65.7000207@ripe.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: <2AEEA246-0CF5-4AC1-BF4C-8D6328811257@netlab.nec.de>
From: Lars Eggert <lars.eggert@netlab.nec.de>
Date: Thu, 14 Dec 2006 11:54:14 +0100
To: Henk Uijterwaal <henk@ripe.net>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1
Cc: ippm@ietf.org
Subject: [ippm] AD review of draft-ietf-ippm-bw-capacity-04.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0029536310=="
Errors-To: ippm-bounces@ietf.org
Hi, I did the AD review as part of the WGLC. Solid document, some editorial nits. Lars Section 2.3.1.1, paragraph 0: 2.3.1.1 Standard or Correctly Formed Packets The "shoulds" and "should nots" in this section need to be "musts" and "must nots", according to both the first sentence of this section and section 5.2.2 of RFC1812. (Nit: Since there is no section 2.3.1.2, omit the heading of 2.3.1.1?) Section 2.3.3, paragraph 2: > The previous definitions specify a link's capacity, namely the IP > layer bits that can be transmitted across a link or path should the > resource be free of any congestion. Determining how much capacity is > available for use on a congested link is potentially much more > useful. However, in order to define the available capacity we must > first specify how much is being used. I think what is meant by "should the resource be free of any congestion" is actually "if the full capacity is available for traffic between the source and destination." Also, is this paragraph in the correct section? It doesn't seem to talk about the path capacity metric. Section 2.3.5, paragraph 0: > 2.3.5 Definition: Average IP Layer Link Utilization Nit: This is the only heading that has "average" in it, but other sections also define averages. Align headings. Section 2.3.6, paragraph 1: > AvailCap(L,T,I) = C(L,T,I) * ( 1 - Util(L,T,I) ) A bit of explanatory text may be good. Section 2.3.7, paragraph 2: > Since measurements of available capacity are more volatile than that > of capacity, it is important that both the time and interval be > specified as their values have a great deal of influence on the > results. In addition, a sequence of measurements may be beneficial > in offsetting the volatility when attempting to characterize > available capacity. This reads as if it should be the start of section 3? Section 4., paragraph 0: > 4. Conclusion Nit: Suggest to move this after the IANA and security considerations. Section 4., paragraph 1: > In this document, we have defined a set of quantities related to the > capacity of links in an IP network. In these definitions, we have > tried to be as clear as possible and take into account various > characteristics that links can have. The goal of these definitions > is to enable researchers who propose capacity metrics to relate those > metrics to these definitions and to evaluate those metrics with > respect to how well they approximate these quantities. Nit: s/links/links and paths/g Section 8.2, paragraph 2: > [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", > RFC 1812, June 1995. Probably needs to be cited normatively. Section 8.2, paragraph 3: > [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, > "Framework for IP Performance Metrics", RFC 2330, > May 1998. Needs to be cited normatively.
_______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm
- [ippm] WGLC on draft-ietf-ippm-bw-capacity-04.txt Henk Uijterwaal
- Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Mark Allman
- [ippm] AD review of draft-ietf-ippm-bw-capacity-0… Lars Eggert
- Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Matthew J Zekauskas
- RE: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Romascanu, Dan (Dan)
- Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Henk Uijterwaal
- Re: [ippm] WGLC on draft-ietf-ippm-bw-capacity-04… Joseph Kopena