RE: Action-272: Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...

I just noticed an small typo in my previous mail: it should say QoS does NOT seem like the right term.  QoS in the networking world has a pretty specific meaning that is different than what is specified in policy.  The Framework spec uses the phrase capabilities and requirements so in the proposed rewrite we use that phrase instead.

Other than that though it seems like we are on the same page.  We would be happy to work together on the wording together.

Daniel Roth

-----Original Message-----
From: Charlton Barreto [mailto:charlton_b@mac.com]
Sent: Tuesday, April 10, 2007 11:14 PM
To: Daniel Roth
Cc: public-ws-policy@w3.org
Subject: RE: Action-272: Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...

Hi Daniel,

On Wednesday, April 11, 2007, at 02:36AM, "Daniel Roth" <Daniel.Roth@microsoft.com> wrote:
>Hi Carlton,
>
>We have some questions about the last two paragraphs in this proposal:
>
>> Domain specific processing can be used by a requester to effectively navigate which QoS (service interface) to use through its requirements.
>
>What does it mean to "navigate which QoS (service interface) to use"?  We think you are saying that a requester gets to decide using whatever processing the requester chooses if any of the policy alternatives supported by a provider are acceptable to the requester, correct?  QoS does really seem like the right term here . . .

[cbb] This means that a requestor makes the decision, dependent on the domain (hence domain-specific processing), on what qualities of service it can or will use, based on the provider's supported alternatives and the requestor's own requirements. Tying in QoS here is particularly useful in the primer as it helps the reader understand the application of assertions.

>> The requestor may need to consistently apply certain assertions in order to use that service, whether these are the requestor's own, or accepted from the provider.
>
>We agree that a requester may have its own policy about what behaviors it is willing to do.  Is this also saying that the provider may or may not support these behaviors?

This is speaking to the nature of intersection. The requestor may have its own policy about the behaviours or QoS that it supports, and the provider may have its own about what it supports. The requestor may need to apply these behaviours whether they are from its own policy or the provider's.

>> Domain specific processing by a requester can also provide a way to trigger alternate processing options when no alternatives are available from the intersection alone. The requestor could be presented with the result to determine an acceptable alternative. For example, in strict mode intersection, no alternatives may be available as a product of the intersection to the requestor. The requestor can then make additional attempts at intersection in order to isolate the cause and/or determine an acceptable alternative."
>
>We think this is again restating that the requester can be creative about how they process the provider's policy.  We agree that trying strict intersection and then falling back to lax intersection is a fine thing to do.

Yes, it describes that the requestor can use processing - which can be dependent on the domain - to determine why an intersection resulted in no alternatives, and to report why and/or resolve what alternatives it can use. It was written in a way that is not specific to the application of multiple intersection modes - e.g. trying strict then falling back to lax - and then to use that application as a very real example.

>
>We think the text could use some rephrasing to make these points clearer.  Below is a suggested rewrite for the last two paragraphs:
>
>A requester can choose how it wants to process a provider's policy to decide if and how the requester will interact with the provider.  A requester can have its own policy that expresses its own capabilities and requirements, and the requester can make one or more attempts at policy intersection in order to determine a compatible alternative and/or isolate the cause of an empty intersection result.  A requester can use the result of policy intersection to select a compatible alternative or trigger alternative processing options. For example, a requester can first try strict mode intersection but then fallback to lax mode intersection as an alternative if the initial intersection attempt returns an empty intersection result.

Thanks. Let me go over this toward discussing further with you.

Cheers,

-Charlton.

>From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Charlton Barreto
>Sent: Tuesday, April 10, 2007 1:43 PM
>To: public-ws-policy@w3.org
>Subject: Action-272: Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...
>
>Here is an *updated* proposal based on the feedback we received last week,
>See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393
>Title: Add text to strict and lax policy intersection discussion describing how a policy consumer can determine issues due to intersection mode conflicts
>Target: WS-Policy Primer, Section 3.4.1
>Description: While the Primer covers scenarios on applying intersection modes, we do not have any content which illustrates how conflicts can be detected. As such we need to indicate in the Primer how a consumer may address such conflict detection and reporting.
>Justification: As consumers have the option to choose one or more modes for policy intersection (strict | lax | strict, delegate-to-user | lax, delegate-to-user | strict, lax, delegate-to-user | ...), conflicts may occur when providers intend for their policies to be applied only in a lax mode - this is distinct from treating everything as ignorable. While the end result may be the same (failure, being that no policy alternatives are available), the consumer needs to be able to report why this occurs.
>Proposal: Perform the following changes to the Primer text
>Change in 3.4.1 Strict and Lax Policy Intersection, as follows (highlighted in colour below):
>
> "The previous sections outlined how the normal-form of a policy expression relate to the policy data model and how the compatibility of requester and provider policies may be determined. This section outlines how ignorable assertions may impact the process of determining compatibility.
>
>In order to determine compatibility of its policy expression with a provider policy expression, a requester may use either a "lax" or "strict" mode of the intersection algorithm.
>
>In the strict intersection mode two policy alternatives are compatible when each assertion in one is compatible with an assertion in the other, and vice versa. For this to be possible they must share the same policy alternative vocabulary. The strict intersection mode is the mode of intersection discussed in the previous sections of this document.
>
>When using the strict intersection mode, all assertions are part of the policy alternative vocabulary, including those marked with wsp:Ignorable. Thus, the wsp:Ignorable attribute does not impact the intersection result even when its attribute value is "true".
>If a requester wishes to ignore ignorable assertions in a provider's policy, then the requester should use the lax intersection mode. In the lax intersection mode all ignorable assertions (i.e. with the value "true" for the wsp:Ignorable attribute) are to be ignored by the intersection algorithm. Thus in the lax intersection mode two policy alternatives are compatible when each non-ignorable assertion in one is compatible with an assertion in the other, and vice versa. For this to be possible the two policy alternatives must share a policy alternative vocabulary for all "non-ignorable" assertions.
>
>Regardless of chosen policy intersection mode, a policy assertion marked with the wsp:Ignorable attribute does not express any requirement on the behavior of the client, rather, it is used for intersection as indicated in Section 2.7. After intersection, any assertions contained in the resulting policy that are understood by the client are handled as expected. As part of the policy expression, these assertions are not ignored, regardless of whether they are marked with wsp:Ignorable.
>
>Domain-specific processing could take advantage of any information from the policy data model, such as the ignorable property of a policy assertion.
>
>Domain specific processing can be used by a requestor to effectively navigate which QoS (service interface) to use through its requirements. The requestor may need to consistently apply certain assertions in order to use that service, whether these are the requestor's own, or accepted from the provider.
>
>Domain specific processing by a requestor can also provide a way to trigger alternate processing options when no alternatives are available from the intersection alone. The requestor could be presented with the result to determine an acceptable alternative. For example, in strict mode intersection, no alternatives may be available as a product of the intersection to the requestor. The requestor can then make additional attempts at intersection in order to isolate the cause and/or determine an acceptable alternative."
>Thanks,
>-Charlton.
>

Received on Wednesday, 11 April 2007 16:01:26 UTC