Subject: [drinks] draft-ietf-drinks-spprov-00

From: Jean-Francois Mule <[email-masked]>
Date: Fri, 9 Jul 2010 10:23:34 -0600

All,

   With Syed, Ken, and Alex, we've released a first draft on the SPP provisioning protocol based on the WG chair guidance.

   This version first incorporates feedback from the drinks wg meeting we had in March (e.g. use URIs said Jon Peterson, forget target domain), and comments from David Schwartz on being able to indicate that a telephone number is one from the carrier-of-record and not a transit provider among other things.

   The draft also builds on feedback we received during the design team calls that Sumanth, Alex, Rich, David, Syed, Ken and (sometimes) I did participate in since the last meeting.

Check it out:
 http://tools.ietf.org/html/draft-ietf-drinks-spprov-00

Another minor revision is coming on Monday, mostly to beef up some text and add more on egress routes (background: http://tools.ietf.org/html/draft-malas-dispatch-sip-egress-route-00).

Feedback welcome on the list.

Jean-Francois.

---

From: David Schwartz <[email-masked]>
Date: Mon, 12 Jul 2010 12:14:54 +0300

Hi Jean Francois 

One comment for discussion

The connection between a set of Organizations (which I understand to be dialog "originators") and a Route Group seems to be misplaced.  While it is certainly desirable to apply various policy rules associated with an Organization to the decision of how to route a dialog, imho these rules will need to include information (e.g. the list of other Destination Groups) that is unavailable at the level where the Organization information has been placed. By associating Organizations with a Route Group, one is saying that the decision of which Route Group to use has already been made, and now can be “fine tuned” using Organization preferences.  I believe that Organizational preferences and peering relationships will have a direct bearing on which Route Group, and indeed with Destination Group to choose. 

The linkage to Organizations should thus be removed from this diagram, as their preferences often will not bear a direct relationship to any of its other elements.  Rather, the various pieces of information returned by a number lookup in the data represented by this diagram should as a collective entity be related to Organization by policy rules.  This would be expressed in a separate, orthogonal diagram resulting in a two step resolution process as follows:  First, determine all the possible routes and any accompanying information; second, apply policy rules to determine the desired order of routes to be attempted.

Thoughts?

:D
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jean-Francois Mule [[email-masked]]
Sent: Friday, July 09, 2010 7:23 PM
To: [email-masked]
Subject: [drinks] draft-ietf-drinks-spprov-00

All,

Check it out:

Jean-Francois.

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 12 Jul 2010 08:05:27 -0400

David:
I believe the reason that DG is tied to organization is to reflect the
terminating service provider's view of the ingress point it wants to
advertise to different originating parties. Originating parties that
receive this terminating-SP-provisioned data from the registry may
indeed have to take other things into account in route selection but I
don't see the protocol, or at least this part of it, as addressing that
need.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Schwartz
Sent: Monday, July 12, 2010 5:15 AM
To: Jean-Francois Mule; [email-masked]
Subject: Re: [drinks] draft-ietf-drinks-spprov-00

Hi Jean Francois 

The connection between a set of Organizations (which I understand to be
dialog "originators") and a Route Group seems to be misplaced.  While it
is certainly desirable to apply various policy rules associated with an
Organization to the decision of how to route a dialog, imho these rules
will need to include information (e.g. the list of other Destination
Groups) that is unavailable at the level where the Organization
information has been placed. By associating Organizations with a Route
Group, one is saying that the decision of which Route Group to use has
already been made, and now can be "fine tuned" using Organization
preferences.  I believe that Organizational preferences and peering
relationships will have a direct bearing on which Route Group, and
indeed with Destination Group to choose. 

The linkage to Organizations should thus be removed from this diagram,
as their preferences often will not bear a direct relationship to any of
its other elements.  Rather, the various pieces of information returned
by a number lookup in the data represented by this diagram should as a
collective entity be related to Organization by policy rules.  This
would be expressed in a separate, orthogonal diagram resulting in a two
step resolution process as follows:  First, determine all the possible
routes and any accompanying information; second, apply policy rules to
determine the desired order of routes to be attempted.

Thoughts?

:D
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of
Jean-Francois Mule [[email-masked]]
Sent: Friday, July 09, 2010 7:23 PM
To: [email-masked]
Subject: [drinks] draft-ietf-drinks-spprov-00

All,

   With Syed, Ken, and Alex, we've released a first draft on the SPP
provisioning protocol based on the WG chair guidance.

   This version first incorporates feedback from the drinks wg meeting
we had in March (e.g. use URIs said Jon Peterson, forget target domain),
and comments from David Schwartz on being able to indicate that a
telephone number is one from the carrier-of-record and not a transit
provider among other things.

   The draft also builds on feedback we received during the design team
calls that Sumanth, Alex, Rich, David, Syed, Ken and (sometimes) I did
participate in since the last meeting.

Check it out:

Another minor revision is coming on Monday, mostly to beef up some text
and add more on egress routes (background:
http://tools.ietf.org/html/draft-malas-dispatch-sip-egress-route-00).

Jean-Francois.

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

---

From: "Cartwright, Ken" <[email-masked]>
Date: Mon, 12 Jul 2010 09:39:53 -0400

If I understand you correctly, you are saying that all mechanisms that allow control over what organizations can use what route groups, and all mechanisms to facilitate control/selection/preference over which route group is selected from those available should not be part of this protocol?

This is of course in direct conflict with the use case requirements.  This would then result in these controls being facilitated/enabled via non-standardized mechanisms outside of the standardized protocol.  I guess I'm ok with this, but given that this would be a notable change to the scope of the use case requirements, further/wider agreement would be necessary.

Wow, late in the game for fundamental use-case feedback like this.  :-)

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Schwartz
Sent: Monday, July 12, 2010 5:15 AM
To: Jean-Francois Mule; [email-masked]
Subject: Re: [drinks] draft-ietf-drinks-spprov-00

Hi Jean Francois

The connection between a set of Organizations (which I understand to be dialog "originators") and a Route Group seems to be misplaced.  While it is certainly desirable to apply various policy rules associated with an Organization to the decision of how to route a dialog, imho these rules will need to include information (e.g. the list of other Destination Groups) that is unavailable at the level where the Organization information has been placed. By associating Organizations with a Route Group, one is saying that the decision of which Route Group to use has already been made, and now can be "fine tuned" using Organization preferences.  I believe that Organizational preferences and peering relationships will have a direct bearing on which Route Group, and indeed with Destination Group to choose.

Thoughts?

:D

All,

Check it out:

Jean-Francois.

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: David Schwartz <[email-masked]>
Date: Mon, 12 Jul 2010 16:47:02 +0300

The UCs merely provide an overview of what is done today (which no one is debating). The UCs do not dictate that one protocol needs to be responsible for all aspects of the UC. I am the last to argue that the UCs are inaccurate. I am merely suggesting that the "policy" aspects be left out - they are far more complex an what we have accepted for.

BTW - u will note that recipient groups were left out (IMHO correctly) when in reality the origination entity is more or less a recipient group.

As for the "late in the game" stuff - I am looking to simplify - not complicate so if we agree this can be done with little pain.

:D

---

From: "Cartwright, Ken" <[email-masked]>
Date: Mon, 12 Jul 2010 09:53:59 -0400

Hmmm.  I did not see the use cases simply as a listing of what is done today.  I saw the use cases as the listing of things that are done today that the protocol needs to support, otherwise why would we bother writing and discussing them as part of this effort.  But that aside, you are certainly correct; pushing these requirements out of the protocol would certainly simplify this protocol.

I'll be curious to hear the opinions of others on this scope question.

Ken

-----Original Message-----
From: David Schwartz [mailto:[email-masked]]
Sent: Monday, July 12, 2010 9:47 AM
To: Cartwright, Ken
Cc: Jean-Francois Mule; [email-masked]
Subject: Re: draft-ietf-drinks-spprov-00

:D

---

From: David Schwartz <[email-masked]>
Date: Tue, 13 Jul 2010 03:06:40 +0300

Hi Penn

1. If indeed the relationship is between orig and DG why the arrow from route group?

2. Regardless, I feel that any form of policy (including which ingress point to show which originating party) is better handled orthogonally. I re-read RFC 4745 and think that mode of operation 3.1 "Passive Request-Response - PS as Server (Responder)" can be used as a base for registry policy handling. As the intro to 4745 states "The general framework defined in this document is intended to be accompanied and enhanced by application-specific policies specified elsewhere."

Should DRINKS consider undertaking an application specific policy for peering registries? 

Like I said before, I just think that policy is much more complex than just showing different ingress points to different originators.

:D
________________________________________
From: PFAUTZ, PENN L (ATTCORP) [[email-masked]]
Sent: Monday, July 12, 2010 3:05 PM
To: David Schwartz; Jean-Francois Mule; [email-masked]
Subject: RE: [drinks] draft-ietf-drinks-spprov-00

David:

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----

Hi Jean Francois

Thoughts?

:D

All,

Check it out:

Jean-Francois.

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Tue, 13 Jul 2010 10:07:12 -0400

David
Personally I have not been in favor of putting policy in the registry
but I know other parties feel differently and it was part of the
original ESPP I-D.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: David Schwartz [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 8:07 PM
To: PFAUTZ, PENN L (ATTCORP); [email-masked]
Subject: RE: [drinks] draft-ietf-drinks-spprov-00

Hi Penn

1. If indeed the relationship is between orig and DG why the arrow from
route group?

2. Regardless, I feel that any form of policy (including which ingress
point to show which originating party) is better handled orthogonally. I
re-read RFC 4745 and think that mode of operation 3.1 "Passive
Request-Response - PS as Server (Responder)" can be used as a base for
registry policy handling. As the intro to 4745 states "The general
framework defined in this document is intended to be accompanied and
enhanced by application-specific policies specified elsewhere."

Should DRINKS consider undertaking an application specific policy for
peering registries? 

Like I said before, I just think that policy is much more complex than
just showing different ingress points to different originators.

:D

David:

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----

Hi Jean Francois

Thoughts?

:D

All,

Check it out:

Jean-Francois.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 13 Jul 2010 10:51:34 -0400

"Like I said before, I just think that policy is much more complex than
just showing different ingress points to different originators."

Definitely no doubt about that, hence the design team's outstanding action item to address this.  And your suggestion to address that action item is to remove the requirement from the protocol, allowing/requiring it to be handled outside the standardized protocol.  As I've said, I'm ok with that.  Opinions of others?

"1. If indeed the relationship is between orig and DG why the arrow from
route group?"

The relationship is between orig and Route Group, not DG.

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L (ATTCORP)
Sent: Tuesday, July 13, 2010 10:07 AM
To: David Schwartz; [email-masked]
Subject: Re: [drinks] draft-ietf-drinks-spprov-00

David

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: David Schwartz [mailto:[email-masked]]
Sent: Monday, July 12, 2010 8:07 PM
To: PFAUTZ, PENN L (ATTCORP); [email-masked]
Subject: RE: [drinks] draft-ietf-drinks-spprov-00

Hi Penn

:D

David:

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----

Hi Jean Francois

Thoughts?

:D

All,

Check it out:

Jean-Francois.

---

From: "Cartwright, Ken" <[email-masked]>
Date: Tue, 13 Jul 2010 13:30:59 -0400

And something to keep in mind about this is that, naturally, some of the requirements in the use case document have interdependencies.  So if we remove the one about associating originating orgs with Route Groups, then we may/will also need to remove other requirements that directly or indirectly depend on that one (e.g. egress routing, route group offer/accept, etc).

Ken

-----Original Message-----
From: Cartwright, Ken
Sent: Tuesday, July 13, 2010 10:52 AM
To: 'PFAUTZ, PENN L (ATTCORP)'; David Schwartz; [email-masked]
Subject: RE: [drinks] draft-ietf-drinks-spprov-00

Ken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L (ATTCORP)
Sent: Tuesday, July 13, 2010 10:07 AM
To: David Schwartz; [email-masked]
Subject: Re: [drinks] draft-ietf-drinks-spprov-00

David

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: David Schwartz [mailto:[email-masked]]
Sent: Monday, July 12, 2010 8:07 PM
To: PFAUTZ, PENN L (ATTCORP); [email-masked]
Subject: RE: [drinks] draft-ietf-drinks-spprov-00

Hi Penn

:D

David:

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----

Hi Jean Francois

Thoughts?

:D

All,

Check it out:

Jean-Francois.

---

From: Jean-Francois Mule <[email-masked]>
Date: Tue, 27 Jul 2010 09:34:44 -0600

David,

  Sorry for the delay, see inline.

Jean-Francois.

On Jul12 2010, at 11:14, David Schwartz wrote:

> The connection between a set of Organizations (which I understand to be dialog "originators") and a Route Group seems to be misplaced.  
To be clear, I assume you are looking at this abusive UMLish diagram:
+-------------+      +------------------+                         
| all object  |      |Organization:     |                        
| types       |      |orgId,            |                       
+------+------+      |orgName,          |                       
       +------------>|                  |                           
                     |extension         |                       
 All objects are     |                  |                       
 associated with 2   |                  |                       
 Organizations to    +------------------+                       
 identify the            ^                                      
 registrant and          |A Route Group is                      
 the registrar           |associated with                       
                         |zero or more           
                         |Organizations         
                         |                      
                +--------+--------------+                          
                |Route Group:           |        +-----[abstract]-+   
                |  rantId*,             |        |                |

> While it is certainly desirable to apply various policy rules associated with an Organization to the decision of how to route a dialog, imho these rules will need to include information (e.g. the list of other Destination Groups) that is unavailable at the level where the Organization information has been placed. By associating Organizations with a Route Group, one is saying that the decision of which Route Group to use has already been made, and now can be “fine tuned” using Organization preferences.

The word policy is so vague and its definitions are overloaded in many ways that I'm not sure what you mean but it.
To answer your question, this diagram is simply trying to show that a Route Group is associated with:
	- a registrant (SSP1 who has a route that it wants to put in a route group for a given destination)
	- a registrar (SSP1 who will provision the data itself in many cases, or another org provisioning data on behalf of SSP1 inside that registry)
	- and peeringOrgs (the set of organizations that can query the Route Group and access the routes in it)

This is clearer when you look at the XSD.

>  I believe that Organizational preferences and peering relationships will have a direct bearing on which Route Group, and indeed with Destination Group to choose. 

yes, this protocol is trying to provide a way for an SSP1 to tell its peers (peeringOrgs) which routes they can access for a given destination.

> The linkage to Organizations should thus be removed from this diagram,

The linkage is to show that a Route Group object links to the 3 types of organizations I mentioned.  Let me know if this explains it better.

> as their preferences often will not bear a direct relationship to any of its other elements.  Rather, the various pieces of information returned by a number lookup in the data represented by this diagram should as a collective entity be related to Organization by policy rules.  
not sure what you mean by policy rules here.

> This would be expressed in a separate, orthogonal diagram resulting in a two step resolution process as follows:  First, determine all the possible routes and any accompanying information
that first piece is what sppp is intended to provision in various data stores.

> ; second, apply policy rules to determine the desired order of routes to be attempted.
> 
that second piece is handled in many different ways today, often by the resolver of the route query into such a data store based on *local* settings to prioritize the returned routes based on parameters that typically do not reside in registries or real-time data stores used for SIP routing.
What SPPP currently provides is for an SSP1 to give multiple routes to SSP2 and indicate a priority preference to SSP2.  It does not provide means for SSP2 to figure out the priorities between all the routes returned for a given destination among routes from SSP1, SSP3, SSP4, etc.

---

From: Jean-Francois Mule <[email-masked]>
Date: Tue, 27 Jul 2010 09:39:57 -0600

Penn,

Just to re-iterate, the reason most objects are tied to organizations is because 

1/ the objects in the XSD use: 
      <element name="base" type="spppb:BasicObjType"/>

2/ and this links each object to a registrant and a registrar 
  <complexType name="BasicObjType">
    <sequence>
      <element name="rantId" type="spppb:OrgIdType"/>
      <element name="rarId" type="spppb:OrgIdType"/>
      <element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
    </sequence>
  </complexType>

The reason for this is so that a Registry can identify who "owns" this data (the registrant) and who provisioned it (the registrar).  Sometimes these 2 entities are just one entity, sometimes they are two.

Jean-Francois.

---

From: Jean-Francois Mule <[email-masked]>
Date: Tue, 27 Jul 2010 09:45:49 -0600

David,

  To add to Ken's note, Sumanth and I are sharing a table in the MECC @ Table and he reminded me that we have an old use case, "Selective Peering" (UC Interconnect #4) that many of us believe is critical to meet in SPPP.

Jean-Francois.
---
Jean-François Mulé
CableLabs
tel:+1-303-661-3708
mailto:[email-masked]

---

From: Jean-Francois Mule <[email-masked]>
Date: Tue, 27 Jul 2010 09:56:06 -0600

On Jul12 2010, at 15:47, David Schwartz wrote:

> The UCs merely provide an overview of what is done today (which no one is debating).

The intent (at least that some of us shared) is to come up with a protocol that can accommodate what is deployed today and that can work between multiple vendors. 

> The UCs do not dictate that one protocol needs to be responsible for all aspects of the UC.
Yes, they do.
As you know from the design team calls, when Syed joined the design team, he actually did quite a bit of work to look at what use cases were addressed in the current version of the protocol draft and which ones were not.
The idea is that we can go through the req & use case document and validate that the protocol does address them.
It is ok to eliminate some but the one you are after here is fundamental I think.

> I am the last to argue that the UCs are inaccurate. I am merely suggesting that the "policy" aspects be left out - they are far more complex an what we have accepted for.

Sure, prioritization of routes based on call rating, PSTN termination fees, time of day, and other parameters is out of scope.
However, it is core to the protocol to allow an SSP to provision a route and indicate which peers can resolve queries to it.  If you remove this, we got a useless protocol.

> 
> BTW - u will note that recipient groups were left out (IMHO correctly)
Agreed.  Debbie proposed we add them and we entertained those discussions for a while.  We added them and then after discussion, did not think it was useful to keep them.  It shows the open process here.

> when in reality the origination entity is more or less a recipient group.
>

---

From: Jean-Francois Mule <[email-masked]>
Date: Tue, 27 Jul 2010 10:00:28 -0600

This will be discussed tomorrow at the meeting but just to be clear, I personally do not think we have in SPP a protocol that enables policy driven decisions.  Quite the contrary, we on purpose left that out.

Jean-Francois.