Subject: draft-ietf-opes-ocp-core

From: "MITTIG Karel FTRD/DMI/CAE" <[email-masked]>
Date: Mon, 25 Aug 2003 14:20:48 +0200

Hello,

I'm actually working on a generic OCP implementation for a later adaptation to DNS services. In this context, I have several comments on actual draft, which I hope will help you to clarify or modify it:

DUM=>'as-is'
--------------
"as-is" includes an "am-id" parameter. What is the range of this am-id: AM session or Transaction ? If it's only available in current AM session, why using it when it's already present in DUM anonymous parameters ?

DUM=>'ack'
--------------
DUM 'ack' can be send by both processor and callout server, but DACK messages can only be send by callout server. Draft modification needed to make DACK sendable by both ?

DH:
--------------
First draft version was including DH message, which has been removed in the last version (replaced by ack flag in DUM message as I understand). However, several parts of the draft still refer to DH:
	-DACK
 	-Adapted dataflow definition
	-Message Examples

DACK
--------------
DACK description speak about a "please-ack" parameter which is not defined anywhere else. Also, the aim of "wont-forward" parameter is not clear to me. If it's only used to terminate preservation commitment, why not re-using the "wont-use" parameter ?

PONG/PING
--------------
rid named parameter => obsolete ?
Name of [xid[am-id]] named parameter is not defined

NO/NR
--------------
ocp core draft defines anonymous parameters as a list of features(§8.13), while HTTP adaptation uses a list of services(§8.4) instead. Which one is right ? :-)
In NR, named parameters "Rejects" (which is normally indicated by omitting the "feature" parameter) & "Unknowns" are not defined.

FLAGS
--------------
"flag" named-parameters (error, ack & wont-forward) type is not clear. Normally, it should be boolean ("0"/"1", correct ?) but this is not explicitly defined.

Data syntax
--------------
Result parameter is defined like for example {200 "2:OK"}. However, Martin presents on his OCP sample a {200 OK} result. Is it an error or are both solutions possible ? If true, it will need useless syntax checks, introduce possible errors in implementation and should be avoid (in my opinion). 
Named parameters use indifferently lowercase or uppercase ("Kept", "modp","Error", "sizep"). Knowing that the protocol is case-sensitive, it would be clearer to use the same nomenclature for all parameters (everything in lowercase for example).

Last point is about processor management of server "adapted" data, using processing points defined in "draft-beck-opes-irml" (adding maybe 2 more points corresponding to processor core treatments between 1->2 and 3->4).
My idea is to add an optional parameter in DUM message (something like [next-processing-point: value]). Receiving this parameter, processor SHOULD transmit adapted message to given processing point.

This will allow for example a filtering service to tell the processor (a proxy in this case) to directly answer to a client with a denied message (with or without allowing processor to cache the answer), or another service to tell the processor (server or proxy in this case) to get another content instead of the one provided in the answer, etc.

Regards,

Karel
[France Telecom R&D ]

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 25 Aug 2003 09:56:33 -0600 (MDT)

On Mon, 25 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote:

> I'm actually working on a generic OCP implementation for a later
> adaptation to DNS services. In this context, I have several comments
> on actual draft, which I hope will help you to clarify or modify it:

Glad to see more people interested in OCP and appreciate your
comments! Detailed responses are below.

> DUM=>'as-is'
> --------------
>
> "as-is" includes an "am-id" parameter. What is the range of this
> am-id: AM session or Transaction ? If it's only available in current
> AM session, why using it when it's already present in DUM anonymous
> parameters ?

Anonymous am-id parameter of DUM message identifies the _adapted_
application message within the transaction. There may be several
adapted application messages within a single transaction for protocols
such as SMTP. Am-id field of the "as-is" parameter identifies the
_original_ application message within the transaction.

For now, there can be only one original application message within a
transaction, but that might change. Even if it never changes, it's
good to keep original am-id in the protocol to keep original and
adapted data messages symmetric (IMO).

Do the above statements answer your questions?

> DUM=>'ack'
> --------------
>
> DUM 'ack' can be send by both processor and callout server, but DACK
> messages can only be send by callout server. Draft modification
> needed to make DACK sendable by both ?

I think you are right. Data acknowledgment mechanism should be
symmetric. Added to the to-do list.

BTW, I suspect it would be better to make the mechanism more universal
so that any message can be acknowledged, not just DUM. We already have
a problem with DUY messages that cannot be acknowledged. Unless I hear
objections or better ideas, I will try to make the acknowledgment
mechanism work with any OCP message.

> DH:
> --------------
>
> First draft version was including DH message, which has been removed
> in the last version (replaced by ack flag in DUM message as I
> understand). However, several parts of the draft still refer to DH:
>
> 	-DACK

Indeed. The next draft version should have all DH references replaced
with DUM. Please let me know if you find more leftovers after the next
release. It is mostly a text management issue -- I still need to find
a way to use some kind of XML placeholders with xml2rfc instead of
actual message names, to better track name usage and reduce renaming
problems.

> DACK
> --------------
>
> DACK description speak about a "please-ack" parameter which is not
> defined anywhere else. Also, the aim of "wont-forward" parameter is
> not clear to me. If it's only used to terminate preservation
> commitment, why not re-using the "wont-use" parameter ?

Renamed "DUM.please-ack" in DACK description to "DUM.ack".

Note that wont-use has a very different semantics: The ack parameter
of a DUM message asks the recipient to acknowledge that the message
has been received. The wont-use parameter informs OPES processor that
a portion of the original data kept at the processor will not be used
by the callout service (and, hence, does not need to be kept any
longer).

> PONG/PING

Removed for now. I think we may need it later, but it is possible that
we can merge the ping/pong and DACK mechanisms together and remove at
least one of the ping/pong messages. See above comments regarding DACK
future.

> Name of [xid[am-id]] named parameter is not defined

These will be anonymous parameters in the next draft release.

> NO/NR
> --------------
>
> ocp core draft defines anonymous parameters as a list of
> features(§8.13), while HTTP adaptation uses a list of services(§8.4)
> instead. Which one is right ? :-)

Both are correct, in principle. A "feature" is a generic mechanism
that HTTP uses to negotiate "services". In other words, "service" is
one of the "features" that can be negotiated.

> In NR, named parameters "Rejects" (which is normally indicated by
> omitting the "feature" parameter) & "Unknowns" are not defined.

Will document for the next release:

   When accepting or rejecting an offer, the sender of the NR message
   MAY supply additional details via Rejects and Unknowns parameters.
   The Rejects parameter can be used to list features that were known to
   the NO recipient but could not be supported given negotiated state
   that existed when NO message was received. The Unknowns parameter can
   be used to list features that were unknown to the NO recipient.

Note that even a positive NR response may have rejects and unknowns.

> FLAGS
> --------------
>
> "flag" named-parameters (error, ack & wont-forward) type is not
> clear. Normally, it should be boolean ("0"/"1", correct ?) but this
> is not explicitly defined.

True. Added to the to-do list. "0"/"1" would work. An alternative is
to say that a present flag name means "true" and an absent flag means
"false" (and have no value when the name is present).

> Data syntax
> --------------
>
> Result parameter is defined like for example {200 "2:OK"}. However,
> Martin presents on his OCP sample a {200 OK} result. Is it an error
> or are both solutions possible ? If true, it will need useless
> syntax checks, introduce possible errors in implementation and
> should be avoid (in my opinion).

{200 "2:OK"} is correct, {200 OK} is wrong, IMO. Both are
syntactically valid, but we need to make it clear somewhere that only
one form is valid because "OK" is a string, not a token.

> Named parameters use indifferently lowercase or uppercase ("Kept",
> "modp","Error", "sizep"). Knowing that the protocol is
> case-sensitive, it would be clearer to use the same nomenclature for
> all parameters (everything in lowercase for example).

Yes. I think we are quite consistent with message names, but named
parameters need more work. Use named constants rather than hard-coded
strings in your code :-).

> Last point is about processor management of server "adapted" data,
> using processing points defined in "draft-beck-opes-irml" (adding
> maybe 2 more points corresponding to processor core treatments
> between 1->2 and 3->4).
>
> My idea is to add an optional parameter in DUM message (something
> like [next-processing-point: value]). Receiving this parameter,
> processor SHOULD transmit adapted message to given processing point.

I am not very fond of the "processing points" approach because it is
very rigid and application-specific. Some application/protocols may
not have processing points (have one processing point). Some protocols
may have processing points that are not appropriate to enumerate as
integers or that change dynamically.

And perhaps more importantly, it seems wrong for the callout service
to tell processor which processing point to use next -- even if the
callout service knows a lot about processing points at the processor,
it cannot know whether adapted data it returns has to go through some
more adaptations before being directed to a given processing point.

> This will allow for example a filtering service to tell the
> processor (a proxy in this case) to directly answer to a client with
> a denied message (with or without allowing processor to cache the
> answer), or another service to tell the processor (server or proxy
> in this case) to get another content instead of the one provided in
> the answer, etc.

I do agree that supporting service-generated responses to client
requests is a MUST-have for HTTP adaptations. I hope we can do that
using application message parts concept (AM-Part): if processor is
receiving response parts when adapting a request, it would know that
the service is generating a response and would route that response
accordingly. Would that approach work well for you?

Thanks again for your comments and bug reports,

Alex.