retaining the {addressing} property?

We are removing the UsingAddressing WSDL marker. I naively assumed that meant removing the entire section 3.1. Upon more detailed study, I am fairly sure that that is NOT the case.
 
Do we intend to retain the {addressing} property which 3.1.1 introduced as an extension to the WSDL 2.0 component model? I suspect that we need to do so.
 
Should we describe how the presence / absence / wsp:Optional-ness of the wsam:Addressing assertion affects the {addressing} property? It can be done, but I'd appreciate some help in phrasing it. Perhaps some words along the line of:
 

		The {addressing} property is present if the wsam:Addressing assertion is present. The value of the property is "required" is the only policy alternatives present include this assertion, without the wsp:Optional="true" attribute . The value of the property is "optional" if there are policy alternatives that include this assertion, and alternatives which do not include it, or if it is marked with the wsp:Optional="true" attribute.

 
I'd really appreciate a Policy-literate person rephrasing that in legitimate Policy language :-) Should I separate the discussion of alternatives with and without the assertion from discussion of wsp:Optional? 
 
Do we also retain Table 3-1 showing the effect of the {addressing} property? I think this table, plus the discusson of what must be present for the message to be compliant, belongs in a separate section, placed after the discussion of how the property is set. The current layout confuses things, because it mixes the defining of the property with the effects of the property, thus clouding the discussion of the SOAP module's ability to affect the same property.
 
So I think we should have 3.1 specifying the policy assertions, and their effect on the {addressing} property, then 3.2 specifying the SOAP module, and its effect on the {addressing} property, then 3.3 describing the {addressing} property and the presence/absence of MAPs in the message.
 
Does that make sense?
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com