RE: [soa-tel] Up for review on Tuesdays Meeting

John,

Let me take a crack at your questions. See inline.

From: John Storrie [mailto:storrie@nortel.com]
Sent: Friday, June 12, 2009 4:54 AM
To: soa-tel@lists.oasis-open.org
Subject: RE: [soa-tel] Up for review on Tuesdays Meeting

Hi Mike,

I took a look at the use case scenarios with a view of providing these use cases but I have some comments to pass back to you and the group, to understand if I have got this correct - so here goes!

R3. SOA-Tel interfaces MUST offer capability (for higher layer applications) to transparently negotiate (NAT and Firewall) perimeter traversal inbound to the enterprise.

To me this looks like we could consider use of the Parlay-X model here for QoS TS 29.199-17 as this allows various aspects of this type of requirement to be specified as name-value pairings. If this is allowed to be associated with the requested service via some form of "interface" offered to the application plane then this would meet this requirement, as the interface can issue the relevant command sequences to effect the required functionality.

[Mani] The parlay-x model for QoS still does not appear to keep the path capabilities (QoS SLA, bandwidth) hidden from the application. However, do higher layer applications need to be aware of the path-non-linearity introduced by NAT and firewall whose discovery, negotiation and resolution are better absorbed in the transport layer. Sure enough, the application having an interface to negotiate through ‘interface’ among a choice of parameters and protocols. That would allow at least functional transparency to the application.

R5. Federation capabilities: communication services in one provider/enterprise realm requiring interoperation with one or more of others’ to complete a client request.

This appears to be along the lines of the SAML or WS-Trust specification but with the twist of providing a per-hop model of trust management, where I think the functionality required is a form of up-issuing or down-grading the trust between the network boundaries. This would occur where a componentized service had to cross a network boundary or boundaries to action the service request possibly initially using a repository to ask where the service resides and having to do this traversal to get to that specific component. My question is around the use of "stacked" trust data, similar to a SIP header, where the trust data between boundaries is contained in the message being transported.

[Mani] More than per-hop vs. end-end (which could be constrained by the governing protocol such as SIP, HTTP or SOAP); the emphasis is on identifying the need for transitive trust wherever per-hop model prevails. This goes beyond federation’s basic point-point Trust model which is essentially intransitive (at realm level). I would prefer to refer to realm or domain boundaries (from standpoint of trust or security policies) and to network boundaries (from traversal non-linearities – which is more appropriate to R3 than R5). The analogy to stacked trust data is very appropriate: the “inner” trust data in message being trusted based on the trust data of the transport established a priori (a two-tier or multi-tier hierarchy of trust, if you will) - the basis of identity propagation in SoA and distributed systems.

Let me know what people think and I can then take a stab at the use cases for the next meeting.

Regards John

________________________________

From: Giordano, Michael (Michael) [mailto:giordano@avaya.com]
Sent: 29 May 2009 22:26
To: soa-tel@lists.oasis-open.org
Subject: [soa-tel] Up for review on Tuesdays Meeting

This is to further clarify SOA-Tel Objectives.

Please become prepared to comment and make additions/ changes, etc. as it will be used as a guide for what types of use cases SOA-TEL accepts in the future.

soa-tel message