Hi Dan,
Good going! Here's my feedback.
In the Introduction, it would be more useful to explicitly scope
RUP as an intra-CDN protocol than to leave it to the readers to
imagine extending RUP beyond practical realms. The hooks and
extensions are in my view a very good thing. with many
*constructive* possibilities. But let's keep them a
controlled explosion, with the intra-CDN upper bound.
About the Design Goals section, I'd scrap it and migrate its contents
to the Requirements section. Let's keep the focus on requirements
at this juncture and let the protocol designers set their goals later.
To be migrated are:
1) 3.1 -- "The protocol must be simple and extensible, ..."
Forget simple. "Simple" is a relative term.
Besides, it is more a design principle than a goal.
CDNs can likely live without simplicity in an invalidation
protocol, as long as efficiency outstrips complexity in the
trade-off. Perhaps "efficient" was what you meant to say?
Extensible, yes. I think it deserves to be made a requirement.
To do so is consistent with the tone set in the Introduction that
RUP will be initially limited but forward-lookingly extensible.
I can think of adding one extension (content/command signaling) that
would foster a productive relationship between caches and an origin
server. By server requesting and caches accepting status logging,
cache-busting can be prevented, thus the caches are able to achieve
what they are supposed to achieve -- caching.
The wording may be something like:
The protocol must be extensible, for forward compatibility with
future needs, without sacrificing backward compatibility with
existing implementations. An RUP message must be capable of
carrying zero to multiple extensions. Each extension must be
clearly indicated as: 1) server mandatory; 2) server optional;
3) client mandatory; 4) client optional; 5) server-and-client
mandatory, or 6) server-and-client optional.
2) 3.2 -- First sentence, "The protocol must itself be widely
deployable
on the Internet, and should leverage existing technologies (e.g.
XML,
HTTP, URIS) as much as possible."
Drop the widely deployable part. We can't tell if RUP will be
"widely deployable" until *after* its roll-out -- design,
implementation,
deployment and all. Maybe the sentence can be re-worded as:
The protocol design should leverage existing technologies (e.g.
XML,
HTTP, URIS) that have proven themselves with wide bases of
deployment.
3) 3.3 -- "The protocol should be easy to integrate into applications
such as content management engines and Web server-side software
components.
At the time of writing, proprietary resource update protocols were
in use
in some commercial systems. ..."
Chances are the RUP protocol designers would have limited exposure
to all
proprietary protocols in use/development. So it may be helpful to
stake
out where RUP will be in a protocol stack, e.g. atop HTTP, so that
the
proprietary entities would have a clear point of reference, and
figure
out for themselves how to converge toward or interoperate with the
standard. To prevent RUP from degenerating into a collection of
methods and formats scattered all over the place, it may help to
add:
The protocol should manifest itself as an independent layer above
the
application layer of the OSI stack. It must be semantically
complete
for resource invalidation [and update? if we're to include update
in RUP],
and yet allow other protocols of similar nature to interoperate or
at
least co-exist atop, beneath, or alongside it.
Regards,
Joe Hui
Digital Island
=================================================
-----Original Message-----
From: Dan Li [mailto:lidan(_at_)cisco(_dot_)com]
Sent: Friday, July 06, 2001 12:12 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: RUP v1 document
Have you are seen this document? - MWC
-----------------------------------
Attached is the RUP v1 document. It incorporated discussions people made
in the last IETF and on the mailing list.
Revision Log:
1. state that RUP requirements focus on cache invalidation, and not on
content retrieval or content push.
2. state that RUP should strive to provide hooks so that future
inclusion of richer functionality is possible.
3. merge "scoping requirement" into "functional requirement".
4. classify various functional requirements into five areas.
5. describe the requirements for strong and weak cache consistency.
6. state that both server and client may initiate message exchange.
7. state that resource grouping is decided outside of RUP and not
negotiable dynamically.
8. state that the protocol semantics and message formats should be
self-contained and portable.
9. state that use cases include internet proxy, surrogates, CDNs,
intranet proxy/surrogate, and non-intermediary uses.
10. remove "content update" from the use cases.
11. switch the sections of the use cases and the functional
requirements.
12. acknowledge people who've given comments on the mailing list or at
the IETF meetings.
We are moving this document to closure, so if you have comments, please
send to the list.
Dan