On Wed, 19 Feb 2003, Reinaldo Penno wrote:
Before I make any comments, it seems to me this work has a lot of
overlap with things we already did.
1. The examples are greatly covered in the use cases and deployment
scenarios
The examples (Section 3) simply illustrate how to map the protocol
commands to the use cases.
2. Some other things seems to me that belong in the requirements
draft. It doesn't make any sense to have two drafts having
requirements on the protocol, moreover the sole purpose of one of
them was to have all the requirements.
It felt awkward to simply send a dry protocol spec draft without any
motivation/introduction/examples. I guess it is safe to ignore those
sections if you can grok the protocol spec without them.
On the other hand, the final OPES protocol RFC will have to duplicate
a lot of information from current drafts. Implementors and integrators
will use that RFC as a primary reference point. They should not be
required to merge three or four RFCs/IDs to understand and implement
the protocol. In other words, the requirements drafts are for IETF
(our) internal use; the protocol RFC is for the world.
I am also not sure my proposal contains any new requirements. It
contains beginnings of a protocol to satisfy existing requirements.
3. The idea was to try to reuse a existing protocol instead of
designing a new one.
We SHOULD reuse. So far, I have not seen any existing protocol that
would meet the requirements and support desirable features mentioned
on this list. Did I miss any?
Moreover, as far as I can see, there is only one protocol, ICAP, that
is "an existing OPES-like protocol". Other things like HTTP/BEEP/SOAP
mentioned on this list are lower-level abstractions that can only be
used as a foundation of an OPES protocol (like ICAP uses HTTP). As I
noted, the proposed protocol can be implemented on top of HTTP, BEEP,
and (maybe) SOAP.
One of the reasons I made the proposal is so that the discussion "ICAP
or something new" becomes more substantiated. I expect ICAP proponents
defend ICAP on this list. ICAP (or any other public deployed protocol)
should be given a "bonus point" compared to anything new, of course.
4. There are two protocols for OPES, in-path and the callout. Are
they going to be the same, different?
What document describes the in-path protocol? I based my proposal on
draft-ietf-opes-protocol-reqs-03.txt which talks about one [callout]
protocol only and does not mention the "in-path" protocol. Also,
draft-ietf-opes-architecture-04.txt specifically says in Section 7
that OPES ruleset schema and OPES callout protocol are necessary and
sufficient OPES elements. It does not mention the "in-path" protocol.
What am I missing?
I guess what we need is to incorporate whatever requirements in a
bis/whatever version of the requirements draft, extend the use cases
and scenarios
I agree with the latter (use cases and scenarios). It looks like there
were a few desirable features mentioned on this list but not
documented in the drafts (e.g., creating multiple responses based on a
single message).
I did not hear any new requirements, but I probably missed them.
and for every protocol we think has a chance to be the
OPES protocol, match its semantics against the requirements draft,
that's what a requirement draft is for.
My understanding is that the above has been done for ICAP
(draft-stecher-opes-icap-eval-00.txt). Again, what are other protocols
to be considered?
If Alex's document is the bootstrap for the following deliverable
"MAY 03 Initial protocol document for OPES services including their
authorization, invocation, tracking, and enforcement of authorization."
Yes, I guess it is.
I guess it should be much more to the point and focused.
See my lame excuses above. The only section that might survive (after
lots of editing, of course) is section 2 "OPES processor-server
communication", which is already as focused as it can be.
Should we hold a conf call to iron these things out?
I would be happy to participate though the mailing list seems to be
working pretty well so far.
Thank you,
Alex.
--
| HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
| all of the above - PolyBox appliance