Subject: Re: [drinks] Seeking volunteers for the protocol I-D

From: Otmar Lendl <[email-masked]>
Date: Fri, 10 Dec 2010 10:31:15 +0100

On 03.11.2010 00:36, Sumanth Channabasappa wrote:
>
> Given this, we would like to request expert reviewers who can help the WG make progress on this I-D. 

Folks,

I've been reading spprov-03 during some commutes and here is a quick recap
of my notes. I haven't finished reading, but I thought it would be helpful
for the WG to see even a partial review:

Page 5:
----
   The data provisioned for session establishment is typically used by
   various downstream SIP signaling systems to route a call to the next
   hop associated with the called domain.  These systems typically use a
   local data store ("Local Data Repository") as their source of session
   routing information.  More specifically, the SED data is the set of
   parameters that the outgoing signaling path border elements (SBEs)
   need to initiate the session.  See [RFC5486] for more details.

   A "terminating" SIP Service Provider (SSP) provisions SED into the
   registry to be selectively shared with other peer SSPs.
----

We have the same issues with "next hop" versus "terminating" as we
discussed in the use-case document.

Page 6:
----
       use other means to perform the Location Routing Function (LRF)
       which in turn helps determine the actual location of the
       Signaling Function in that domain.
----

"Signaling Function" is an IMS term that I think we should avoid here.

... domain or next hop". (this might be a transit ...)

Page 11
----
                            |         |       |     |
                         +------+  +-----+  +-----+ +-----+
                         |  TN  |  | TNP |  | TNR | | RN  |
                         +------+  +-----+  +-----+ +-----+
----
There are explanations for TN, TNR, and RN, but not TNP on page 12.

Page 12
----
      A TN Public Identifier may optionally be associated with zero or
      more individual Route Records.  This ability for a Public
      Identifier to be directly associated with a set of Route Records
      (e.g. target URI), as opposed to being associated with a
      Destination Group, supports the use cases where the target URI
      contains data specifically tailored to an individual TN Public
      Identifier.
----

I still don't like this.

Page 13
----
   o  Organization:
      An Organization is an entity that may fulfill any combination of
      three roles: Registrant, Registrar, and Peering Organization.  All
      SPPP objects are associated with two organization identifiers to
      identify each object's registrant and the registrar.  A Route
      Group object is also associated with a set of zero or more
      organization identifiers that identify the peering organizations
      whose query responses may include the routing information (SED)
      defined in the Route Records within that Route Group.
----

We have a potential source for troubles here:

Different registrars will provision entries into the registry that will
have to reference objects provisioned by other registrars. Mainly this will
involve the identity of registrants and peering organizations.

This is in contrast to EPP, where objects created by one registrar will
never ever come into contact with objects created by another registrar.

Example: if Registrar A wants to make his routeGroups visible to "Carrier
ABC", then it important that he uses the same identification of "Carrier
ABC" as Registrar B is using when he is processing the routeGroupOffer request.

As I read the document, there will be no stand-alone objects for
"registrant" and "peering organization" in the registry, instead the
OrgIdType will be used. This looks fine at first, see also page 26:

----
   The identifiers used for registrants (rantId), registrars (rarId) and
   peering organizations (peeringOrg) are instances of OrgIdType.  The
   OrgIdType is defined as a string and all OrgIdType instances SHOULD
   follow the textual convention: "namespace:value" (for example "iana-
   en:32473").  See the IANA Consideration section for more details.
----

I see the following caveats:

A registry needs to clearly define which namespace should be used. If
registrars mix them, the system breaks. Eg.:

iana-en:12345 might refer to the same entity as itu-spid:0815

Carriers to merge / split. We will have the case where
iana-en:11111 get bought up by iana-en:22222 and will want to merge their
network.

Is this something SPPP needs to directly support or are we sure that case
could be handle with the existing protocol?

Page 16:
----
4.6. Near Real Time

   Many use cases require near real-time responses from the Server.
   Therefore, a DRINKS transport protocol MUST support near-real-time
   response to requests submitted by the Client.
----

This is pretty vague. What exactly is "near-real-time"?

Page 17:
----
   Therefore, a transport protocol for SPPP MUST provide a Response for
   each Request, so that a Client can identify whether a Request
   succeeded or failed.
----

As I wrote on Nov., 22th, this is impossible.

Page 19:
----
        included in the request.  And with respect to handling error
        conditions, it is a matter of policy whether the objects are
        processed in a "stop and rollback" fashion or in a "stop and
        commit" fashion.
----

This is a cop-out. Go ahead and define it or make it a flag in the request
what behavior is desired. Otherwise this will be a source of subtle
interoperability problems.

Page 27:
----
   The AddRteGrpRqstType operation creates or overwrites a Route Group
   object.  If a Route Group with the given name and registrant ID
   (which together comprise the unique key or a Route Group) does not
   exist, then the server MUST create the Route Group.
----

I had to read that sentence twice to make sense of it. Please simplify.

A more generic note: The uniqueness constraints of various objects and the
write permissions for them is either distributed throughout the document or
not really clearly defined.

e.g. in this case: is RGname/rantID unique over all registrars? If not, can
another registrar also update this Route Group? What if a registrant is
served by more than one registrar? Changes its registrar?

Page 29:
----
   o    dgName: Set of zero or more names of DestGrpType object
        instances.
----

This is basically a foreign key. This leads to the obvious database design
questions like:

* Does this dgName need to exist when the RteGrp is created?
* What happens if a referred to DG is deleted? Will that operation fail?
Will it cascade?

Page 30:
----
   The RteGrpType object provides support for source-based routing via
   the peeringOrg data element and more granular source base routing via
   the source identity element.  The source identity element provides
   the ability to specify zero or more of the following in association
   with a given Route Group: a regular expression that is matched
   against the resolution client IP address, a regular expression that
   is matched against the root domain name(s), and/or a regular
   expression that is matched against the calling party URI(s).  The
   result will be that, after identifying the visible Route Groups whose
   associated Destination Group(s) contain the lookup key being queried
   and whose peeringOrg list contains the querying organizations
   organization ID, the resolution server will evaluate the
   characteristics of the Source URI, and Source IP address, and root
   domain of the lookup key being queried.
----

Phew.

"resolution client IP address"

How is the provisioning side supposed to know that? The resolution client
need not be the peering element it sees, it could be some central IN-style
call control element. Does this mean that any carrier-internal change in
the call routing infrastructure needs to be communicated to all peering
partners so that they can updated their RouteGroups?

"root domain name"

What the *that* supposed to mean? The root domain is "."
Can you give an example?

"calling party URI(s)"

How is this supposed to work for TN-based calls?

The regex is certainly helpful to specify a large number of potential call
sources with a simple string. But I'm wondering why you are not re-using
the DestinationGroup abstraction here. After all, they are supposed to
aggregate numbers/URIs that are treated the same when routing towards them,
making it pretty likely that they will also get the same treatment when
calls originate within a DG.

------------------------

.... to be continued.

HTH,

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //