RE: NEW ISSUE (4074): [Guidelines] Collection of unclear Guidance or text issues

Hi Maryann,

I am fine clarifying the existing text instead of removing it, but I have some questions about these proposals:

> "The granularity of assertions is determined by the authors. and Itit is recommended that care be taken when defining nested policies to ensure that the options provided appropriately specify policy alternatives within a specific behavior."

Why must "care" be taken?  What does it means to provide options that "appropriately specify policy alternatives"?  If we don't answer these questions, then I think this text indicates there is a potential issue here for assertion authors but doesn't say what it is and how to deal with it.

> supporting RM at the endpoint indicates that the behavior is for an RM sequence, a policy subject that is not defined by the WS-Policy group.

The behavior indicated by an assertion and the policy subject of the assertion are different things, so I don't think the RM sequence is the policy subject.  I do think the RM sequence is the "interaction scope of the assertion" (see Section 3.4 in the Framework).  I'm still not sure what the guidance for assertion authors is in this case.

> "Authors of new assertions which will coexist with existing  assertions like  WS-Security , should make themselves
aware of the nesting of policies in the WS-Security domain and the behaviors that this represents.

Why should assertion authors "make themselves aware of the nested polices in the WS-Security domain"?  I don't think we should raise red flags without explaining the issue and explaining how to deal it.

Daniel Roth
________________________________
From: Maryann Hondo [mailto:mhondo@us.ibm.com]
Sent: Wednesday, December 20, 2006 8:52 AM
To: Daniel Roth
Cc: public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: Re: NEW ISSUE (4074): [Guidelines] Collection of unclear Guidance or text issues


Dan,
I have some questions about your proposal and some friendly amendments to propose:

For #3 would you accept a friendly amendment of the following:

"The granularity of assertions is determined by the authors. and Itit is recommended that care be taken when defining nested policies to ensure that the options provided appropriately specify policy alternatives within a specific behavior."

For #4,
I think that using RM is a good example so I suggest we address your question......

It is not clear how "the current set of subjects as mapped to the WSDL 1.1 elements, can also constrain the assertion."  It's not clear how supporting RM policy at the endpoint "resulted in the finer granularity of the assertion to apply at the message policy subject."  It is not clear what "constraints and assumptions for attachment and engagement of behavior" an assertion author should specify.

I believe that the intent here is that an assertion represents a behavior. So supporting RM  at the endpoint indicates that the behavior is for an RM sequence, a policy subject that is not defined by the WS-Policy group.   The way that RM uses sequence numbers for messages is the finer granularity, so maybe it would be good to elaborate on this expected behavior rather than removing it, since these assertions will be used by policy implementors. We could ask the RM group for some input.

For #5, you quote
"domain authors should be aware of the compositional semantics with other related domains. The protocol assertions that require composition with WS-Security should be particularly aware of the nesting requirements on top of transport level security."  [4]

and suggest it be removed.

I think the first statement is an important guideline.  Domain authors need to be aware of how their policies might interact with other
domains. I think we could change the second sentence to something like this

"Authors of new assertions which will coexist with existing  assertions like  WS-Security , should make themselves
aware of the nesting of policies in the WS-Security domain and the behaviors that this represents.

Maryann



Daniel Roth <Daniel.Roth@microsoft.com>
Sent by: public-ws-policy-request@w3.org

12/12/2006 05:38 PM

To

"public-ws-policy@w3.org" <public-ws-policy@w3.org>

cc



Subject

NEW ISSUE (4074): [Guidelines] Collection of unclear Guidance or  text issues










See http://www.w3.org/Bugs/Public/show_bug.cgi?id=4074

Title: [Guidelines] Collection of unclear Guidance or text issues

Description:

1.) Section 3.1.1 states:  "The WS-Policy Framework is based on a declarative model, meaning that it is incumbent on the WS-Policy authors to define both the semantics of the assertions as well as the scope of their target domain in their specification. The set of metadata for any particular domain will vary in the granularity of assertion specification required." [1]

It is not clear what it means to define the "scope of their target domain."

2.) Section 3.1.1 later quotes an unknown section from WS-SecurityPolicy (needs a reference) and prefaces the quote with: "An example of a domain specification that follows these practices is the WS-SecurityPolicy specification [WS-SecurityPolicy]. The WS-SecurityPolicy authors have defined their scope as follows:"

It is not clear what practice the quote is trying to demonstrate, though I think the is referring to an assertion author defining the "scope of their target domain"

3.) Section 4.4.2, 1st paragraph states: "The granularity of assertions is determined by the authors and it is recommended that care be taken when defining nested policies to ensure that the options provided appropriately specify policy alternatives within a specific behavior." [2]

It is not clear what it means to "define nested policies to ensure that the options provided appropriately specify policy alternatives within a specific behavior."

4.)  Section 4.7 states: "The current set of subjects as mapped to the WSDL 1.1 elements, can also constrain the assertion constructs. For Example, In WS-RM, the domain authors chose to support certain capabilities at the endpoint level. This resulted in the finer granularity of the assertion to apply at the message policy subject, but the assertion semantics also indicates that the if the senders choose to engage RM semantics (although not specified via attachment in WSDL at incoming messages), the providers will honor the engagement of RM. This is illustrative of how the assertion author can specify additional constraints and assumptions for attachment and engagement of behavior." [3]

It is not clear how "the current set of subjects as mapped to the WSDL 1.1 elements, can also constrain the assertion."  It's not clear how supporting RM policy at the endpoint "resulted in the finer granularity of the assertion to apply at the message policy subject."  It is not clear what "constraints and assumptions for attachment and engagement of behavior" an assertion author should specify.

5.) Section 6 states: "domain authors should be aware of the compositional semantics with other related domains. The protocol assertions that require composition with WS-Security should be particularly aware of the nesting requirements on top of transport level security."  [4]

It is not clear what Section 6 is recommending that policy assertion authors do.

Justification: The text in these sections does not provide clear guidance, which could result in confusion and misinterpretation.

Target: Guidelines for Policy Assertion Authors

Proposal:

1,2.) Replace "The WS-SecurityPolicy authors have defined their scope as follows:" with "The WS-SecurityPolicy authors have defined the scope of their target domain (security) as follows:"

3.) Remove or clarify the sentence

4.) Remove the section

5.) Remove or clarify the section.

[1] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?rev=1.11&content-type=text/html;%20charset=utf-8#domain-owners
[2] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?rev=1.11&content-type=text/html;%20charset=utf-8#nested-assertions
[3] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?rev=1.11&content-type=text/html;%20charset=utf-8#levels-of-abstraction
[4] http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-guidelines.html?rev=1.11&content-type=text/html;%20charset=utf-8#inter-policy