Subject: RE: SCVP & validation policies

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 11 May 2004 10:05:29 -0700

Hi Steve,
I am not excluding that. A SCVP client may choose to implement the more
al a carte or a combination of al-a-carte plus predefined policy. In
every validation policy it may agree m parameters. That leaves n
parameters to be specified per request. Since we don't know which of the
m parameters will be fixed in any given deployment  we must support any
combination so we must support the full rage of parameter currently
defined. In many situations the overhead of agreeing these pre-caned
selection is an administrative burden such as a departmental server
wanting to implement special needs. Equally in may corporate deployments
there is no choice with many of the values so you can default every to
whoever is good for the server, so again rendering app specific policy
of no value.
Trevor

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 9:28 AM
To: Trevor Freeman
Cc: Denis Pinkas; [email-masked]
Subject: RE: SCVP & validation policies

At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
>Hi Dennis,
>The OID is optional for the client to use. Servers don't have to
support
>this. It become a matter of mutual agreement between the client and
>server what the OID represents. An SCVP server must either comply with
>any request or return an error so I don't see the validation policy OID
>needs any special treatment beyond want SCVP already defines.
>Trevor

Trevor,

I have to agree with Denis here. This is completely backwards from 
what I recall we defined as the requirements in his RFC a while ago. 
OIDs were sufficient to identify a policy, the parameters for which 
were managed via a separate protocol. It seems a lot easier to 
configure a client with an OID per app, than to configure a set of 
parameters for each app.

Steve

---

From: "Florian Oelmaier" <[email-masked]>
Date: Tue, 11 May 2004 21:12:41 +0200

> Hi Steve,
> I am not excluding that. A SCVP client may choose to 
> implement the more al a carte or a combination of al-a-carte 
> plus predefined policy. In every validation policy it may 
> agree m parameters. That leaves n parameters to be specified 
> per request. Since we don't know which of the m parameters 
> will be fixed in any given deployment  we must support any 
> combination so we must support the full rage of parameter 
> currently defined. In many situations the overhead of 
> agreeing these pre-caned selection is an administrative 
> burden such as a departmental server wanting to implement 
> special needs. Equally in may corporate deployments there is 
> no choice with many of the values so you can default every to 
> whoever is good for the server, so again rendering app 
> specific policy of no value. Trevor

Hello Trevor,

I feel that a solution allowing a client to specify values that the
server MUST use will not only harm the usability of SCVP in enterprise
environments but also make interoperability between different software
vendors on the client side with different servers a lot more difficult.

If we specify a set of parameters that the server MAY use - I am fine.
But please dont allow the client to specify any parameters a server MUST
use.

Best regards,

Florian Oelmaier

> >needs any special treatment beyond want SCVP already defines. Trevor
> 
> Trevor,
>