Document Action: Requirements for OPES Callout Protocols to Informational
The IESG <iesg-secretary@ietf.org> Wed, 12 February 2003 01:19 UTC
Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23946; Tue, 11 Feb 2003 20:19:19 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18ilbc-0007am-00 for ietf-announce-list@ran.ietf.org; Tue, 11 Feb 2003 20:22:32 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18ilbU-0007Y4-00 for all-ietf@ran.ietf.org; Tue, 11 Feb 2003 20:22:24 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23864; Tue, 11 Feb 2003 20:15:48 -0500 (EST)
Message-Id: <200302120115.UAA23864@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>, ietf-openproxy@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Requirements for OPES Callout Protocols to Informational
Date: Tue, 11 Feb 2003 20:15:47 -0500
Sender: owner-ietf-announce@ietf.org
Precedence: bulk
The IESG has approved the following Internet-Drafts as Informational RFCs: o 'Requirements for OPES Callout Protocols' <draft-ietf-opes-protocol-reqs-03.txt> o 'An Architecture for Open Pluggable Edge Services (OPES)' <draft-ietf-opes-architecture-04.txt> These documents are the product of the Open Pluggable Edge Services Working Group. The IESG contact persons are Ned Freed and Patrik Faltstrom. An announcement to this effect will be sent shortly. As explained previously, the IESG believes that draft-ietf-opes-scenarios-01.txt is too dependent on draft-ietf-opes-threats-00.txt to publish at this time. The IESG is concerned, however, that what appears in these drafts is a fairly high level overview of OPES requirements and architecture. Missing is any mention of specific mechanisms to provide security and congestions. This is not necessarily a problem given these are informational requirement and architecture documents. However, the IESG notes that the lack of specificity at this point could lead to problems deciding on actual protocol details later in the process. Requirement and architecture documents have often proved to be useful tools in reaching consensus on subsequent protocol specifications. Should difficulties arise in reaching consensus later it may be necessary and useful to expand on these documents with information about specific mechanisms to be used.