draft-ietf-opes-ocp-core

["MITTIG Karel FTRD/DMI/CAE" <karel.mittig@xxxxxxxxxxxxxxxxxxxx>]

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 ]