Re: [Gen-art] Gen-ART review of draft-ietf-pce-pcecp-interarea-reqs-05.txt

Brian E Carpenter <brc@zurich.ibm.com> Mon, 05 March 2007 14:41 UTC

Return-path: <gen-art-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOENl-0006TS-AD; Mon, 05 Mar 2007 09:41:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOENk-0006TC-RX for gen-art@ietf.org; Mon, 05 Mar 2007 09:41:44 -0500
Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOENb-0000um-VJ for gen-art@ietf.org; Mon, 05 Mar 2007 09:41:44 -0500
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l25EfYR3082684 for <gen-art@ietf.org>; Mon, 5 Mar 2007 14:41:34 GMT
Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l25EfYSB1536246 for <gen-art@ietf.org>; Mon, 5 Mar 2007 15:41:34 +0100
Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l25EfYbR027472 for <gen-art@ietf.org>; Mon, 5 Mar 2007 15:41:34 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l25EfXL7027456; Mon, 5 Mar 2007 15:41:34 +0100
Received: from [9.145.135.171] (sig-9-145-135-171.de.ibm.com [9.145.135.171]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA353744; Mon, 5 Mar 2007 15:41:29 +0100
Message-ID: <45EC2C19.5060704@zurich.ibm.com>
Date: Mon, 05 Mar 2007 15:41:29 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-pce-pcecp-interarea-reqs-05.txt
References: <45EC102E.5010505@nokia.com>
In-Reply-To: <45EC102E.5010505@nokia.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: rcallon@juniper.net, adrian@olddog.co.uk, General Area Review Team <gen-art@ietf.org>, jeanlouis.leroux@orange-ftgroup.com, jpv@cisco.com
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

I think Miguel is completely correct in principle -
requirements shouldn't include specific protocol elements;
they should describe necessary functionality.

This draft has to fit into a rather precisely defined world
though, so I don't think it can really be made more abstract.
I won't ask for any changes.

      Brian

On 2007-03-05 13:42, Miguel Garcia wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-pce-pcecp-interarea-reqs-05.txt
> Reviewer: Miguel Garcia <miguel.an.garcia@nokia.com>
> Review Date: 2007-03-05
> IESG Telechat date: 08 March 2007
> 
> Summary: The document is ready for publication as Informational RFC.
> 
> Comments: I have only a very subjective comment. In my opinion 
> requirements drafts should make an abstraction of the solution and just 
> note down the requirements. However, while reading this draft, I got the 
> impression that the authors have been thinking quite a lot on the 
> solution space, haven't separated them from the solution, and have 
> written down a few solutions. Just to illustrate a couple of examples. 
> On Section 4.8 the text reads:
> 
>    The request message MUST allow for the inclusion of the address of
>    the originating PCC.
> 
> This is a solution for a requirement. Unfortunately it is not clear to 
> me what the requirement is. It is probably something related to the 
> "ability of a PCE to apply PCC-specific policies" or something like 
> that, where a solution is "to record the address of the PCC in request 
> messages, so that the PCE can apply a pcc-specific policy".
> 
> Another example in Section 4.4:
> 
>    Hence the request message SHOULD allow a request for the
>    identification of path segments computed by a PCE, and the response
>    message SHOULD allow identifying the path segments computed by each
>    PCE.
> 
> Well, just an opinion.
> 
> /Miguel
> 
> 

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art