OPES note and ICAP IESG notes

[ned.freed@mrochek.com]

Recall that we agreed that a note needed to be sent to the OPES group prior to
announcing approval of the two OPES informational documents. Attached below is
a draft of that note.

Also recall that we agreed that publication of ICAP protocol specification is
appropriate provided an IESG note explaining that work is underway in OPES to
develop a standards track replacement is attached. Attached below is a draft of
that note.

Secretariat, please add both of these as discussion items to this week's
agenda. Thanks.

				Ned

P.S. I wrote these some time back and I was sure I'd sent them out a couple of
weeks ago. But after seeing no comments I checked and could not find any
indication they ever went out. Oops. 
The IESG has approved the drafts

   ietf-opes-protocol-reqs-03.txt
   draft-ietf-opes-architecture-04.txt

for publication as informational RFCs. An announcement to this effect will be
sent shortly. As explained previously, the IESG beleieves 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 may lead to problems deciding on actual protocol
details later in 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.
The Open Pluggable Edge Services (OPES) working group has been chartered to
produce a standards track protocol specification for a protocol intended to
perform the same sorts of functions as ICAP. However, since ICAP is already in
widespread use the IESG believes it is appropriate to document existing usage
by publishing the iCAP specification as an informational document. The IESG
also notes that ICAP was developed before the publication of RFC 3238 and
therefore does not address the architectural and policy issues described in
that document.