Subject: Re: [drinks] Looking for 2-4 volunteers to review draft-ietf-drinks-usecases-requirements

From: Sumanth Channabasappa <[email-masked]>
Date: Mon, 2 Aug 2010 10:04:57 -0600

Otmar,

Thanks again for your comments. I am enclosing some responses, inline, tagged with [S]. For items that I need additional clarification (from you or others on this list), I have tried to mark them with the following string '************'.

[FYI, I believe we discussed some of these at the meeting, so I tried to keep it brief, although not diligently. I also added numbers so that we can reference them easily when we make I-D updates. ]

- S

<...snip..>
----------------------

#1
>
>   This document reuses terms from [RFC3261] (e.g., SIP), [RFC5486]
>   (e.g., LUF, LRF, SED) and [RFC5067] (carrier-of-record and transit
>   provider).  In addition, this document specifies the following
>   additional terms.

I'm missing a definition of RN (Routing Number?).

===
[S] Hmmm, I guess we are missing a reference to RFC4694. 
===

#2
>   Registry:   The authoritative source for provisioned session
>      establishment data (SED) and related information.

It is explained later, but at that stage it would have been helpful to state whether that Regstry is part of a SSP or whether it is an independent body.
===
[S] We can add the clarification.
===

#3
>   Registrar  An entity that provisions and manages data into the
>      registry.

That term appears only once in the rest of the document, and in most cases its "SSP provisions...".

So perhaps junk it?

>   Registrant  An entity whose data is provisioned into the registry.
>      The registrant can act as its own registrar or - additionally or
>      alternatively - delegate this function to a third party who acts
>      as its registrar.

Never appears in the document.
===
[S] This is probably my bad. We agreed to use registrar and registrant to the use cases (at the interim meeting), but it is not used as expected.
===

#4
>
>   Local Data Repository:   The data store component of an addressing
>      server that provides resolution responses.

Is this run by the SSP it serves?

===
[S] Yes. See Figure 2.
===

#5
>   Public Identifier:   A public identifier refers to a telephone number
>      (TN), an email address, or other identity as deemed appropriate,
>      such as a globally routable URI of a user address (e.g.,
>      mailto:[email-masked]).

Why an email address? Or is this just to a hint in the direction of email-like sip URIs like sip:[email-masked]?
===
[S] The idea here was to allow for additional associations with a public identity, outside of TNs. Email was referenced as an example (not as a look-up key). 
===

#6
>   TN Range:   A numerically contiguous set of telephone numbers whose
>      SED can be looked up (resolved).

"whose" is a bit wrong here, as all the SSP-specific and data-policy- dependend features make the SED not a simple attribute of a TN range.

So, I recommend either

   TN Range:   A numerically contiguous set of telephone numbers

or stress that all numbers in the range have the same routing data associated with them:

   TN Range:   A numerically contiguous set of telephone numbers for
      which the same data distribution policy and SED applies.

===
[S] I personally prefer the latter.
===

#7
>   Destination Group:   An aggregation of a set of public identifiers,
>      TN Ranges, or RNs that share common SED.

good. perhaps not just SED, but also the "who sees what" properties.

=== ************
[S] Can you elaborate on this (as it applies to the description), please?
=== ************

#8
>   Routing Group:   An aggregation that contains a related set of SED
>      records, and is associated with a set of destination groups.
>      Routing groups facilitate the management of SED records - which
>      are common to a large number of public identifiers, TN Ranges or
>      RNs - for one or more data recipients.

DGs are intuitively right and important, but for RGs I have more difficulties understanding the argument. I guess it makes sense, but this text does not convince me.

Please leave the PIs, TN ranges and RN out of the definition, RGs are only connected to Destination Groups.
===************
[S] RGs associate DGs to SED. We discussed some of the rationale at the meeting. Do you still have questions about its applicability?
===************

#9
>   SED is typically created by the terminating SSP and consumed by the
>   originating SSP.  To avoid a multitude of bilateral exchanges, SED 
> is

"terminating" is perhaps the wrong word for the transit case, as the it's the transit SSP, and not the final, terminating SSP that creates the SED entries.

===************
[S] That's true. Design Team: any suggestions on how to word this better for direct and transit cases?  
===************

#10
>   often shared via intermediary systems - termed registries within this
>   document.  Such registries receive SED via provisioning transactions
>   from other SSPs, and then distribute the received data into Local
>   Data Repositories.  These local data repositories are used for call
>   routing by outgoing SBEs.  This is depicted in Figure 1.

I don't want to pick nits, but the SED alone are useless unless you also provision and distribute the TN-Ranges / PIs / .. to which these SED records apply.

The diagram is fine und useful, just be a bit more careful about the terminology.

===
[S] Fair point.
===

#11

>   In this version of the document, we primarily address the use cases
>   and requirements for provisioning registries.  Future revisions may
>   include data distribution to local data repositories.  The resulting
>   provisioning protocol can be used to provision data into a registry,
>   or between registries.  This is depicted in Figure 2.
>
>

The fact that there could be multiple registries operating in parallel should be stressed somewhere else.

The dotted lines make this diagram slightly confusing.

Perhaps do a version with the current focus only, and then add a second one that explains what future revisions might do.

===
[S] K
=== 

#12
>   In addition, this document proposes the following aggregation groups
>   with regards to SED (refer to the use cases in Section 3.5 for the
>   rationale):
>
>   o  Aggregation of public Identifiers into a destination group.
>
>
>   o  Aggregation of SED records into a Routing Group.

As before, some more explanations on the RG, perhaps with some examples might be helpful.

===************
[S] In addition to the use cases?
==************

#13
>
>   The data model depicted in Figure 3 shows the various entities,
>   aggregations and the relationships between them.
>

I think the direct PI-SED link should be removed. It just leads to endless special-cases in all the code.

>   UC INTERCONNECT #3  Intra-SSP SED: SSPs support the establishment of
>                       sessions between their own public identifiers,
>                       not just to other SSPs public identifiers.
>                       Enabling this involves, among other things,
>                       communicating and enabling intra-SSP signaling
>                       points and other SED that can differ from inter-
>                       SSP signaling points and SED.

This confused me a bit. Why would an SSP out-source their internal routing to an external DB?

But yes, it's done in the PSTN world and perhaps the drinks protocol might be used internally to an SSP (think merger process of two SSPs), so ok, leave it in.

===
[S]  :)
===

#14
>   UC INTERCONNECT #4  Selective Peering (a.k.a. per peer policies):
>                       SSPs create peering relationships with other SSPs
>                       in order to establish interconnects.  However,
>                       SSPs peering relationships often result in
>                       different points of ingress or other SED for the
>                       same set of public identifiers.

Please clarify the level of selectiveness supported:
by PI, by TN-Range, by RN or just by Destination-Group.

===
[S] Destination Group is an internal structure, so it would be by PI, RN or TN Range. We can clarify.
===

#15
>   UC INTERCONNECT #5  Provisioning of a delegated name server: An SSP
>                       maintains a Tier 2 name server that contains the
>                       NAPTR records that constitute the terminal step
>                       in the LUF.  The SSP needs to provision a
>                       registry to direct queries for the SSP's numbers
>                       to the Tier 2 name server.  Usually queries to
>                       the registry should return NS records, but in
>                       cases where the Tier 2 uses a different domain
>                       suffix from that used in the registry, CNAME and
>                       NS records may be employed instead.

WTF?

The rest of the draft talk about generic SED, does not specify a query protocol, and now, out-of-the-blue, we're on NAPTR, NS, CNAME level?

This makes no sense at this level. If there is a use-case, describe it at the same abstraction level as the others.

===
[S] OK :)! I think we agreed to make this abstract at the meeting.
===

#16
>3.3.  Category: SED Exchange and Discovery Models

>   UC SED EXCHANGE #2  SED Exchange and Discovery using LUF's Domain
>                       Name: When establishing peering relationships
>                       some SSPs may not wish to communicate or receive
>                       points of ingress and other SED using a registry.
>                       They wish to only communicate or receive domain
>                       names resolvable via [RFC3263], and this query
>                       will then return the points of ingress or other
>                       SED that form the LUF.

I think this is ok, but the text confuses me. Please describe (perhaps using examples) what the query is and what the answer will be.

(Examples would be helpful for all these 4 types.)

===
[S] We could add some small examples.
===

#17
>3.5.  Category: Separation and Facilitation of Data Management
>
>   UC DATA #1  Separation of Provisioning Responsibility: An SSP's
>               operational practices often separate the responsibility
>               of provisioning the points of ingress and other SED, from
>               the responsibility of provisioning public identifiers (or
>               TN ranges or RNs).  For example, a network engineer can
>               establish a physical interconnect with a peering SSP's
>               network and provision the associated domain name, host,
>               and IP addressing information.  Separately, for each new
>               subscriber, the SSP's provisioning systems provisions the
>               associated public identifiers.

This is good.

Perhaps clarifiy that one is the LUF data (PI/TN -> DG mapping) and that the other is the LRF data (DG -> SED).

===************
[S] Do we really want to add LUF and LRF distinction within the use case?
===************

#18
>
>   UC DATA #3  Route Groups: SSPs often provision identical SED for
>               large numbers of public identifiers, and then expose 
> that

^^^ this is handled via the DG abstraction.

===
[S] Yes...
===

#19
>               relationship between a group of SED records and a group
>               of public identifiers to one or more SSPs.  This combined
>               grouping of SED records and Destination Groups
>               facilitates management of public identity SED
>               relationships and the list of peers (data recipients)
>               that can lookup those public identifiers and receive that
>               SED.  This dual set of SED Records and Destination Groups
>               is termed as a Route Group.

Once again, the idea is good, but the explanation for the RG rationale is more confusing than helpful.

===************
[S] Any suggestions (Otmar or the design team)?
===************

#20
>3.7.  Category: Number Portability
>
>   UC NP #1  EDITOR's NOTE: Need to clarify this further.
>
>
>             The SSP wishes to provide in query response to public
>             identifiers an associated routing number or RN.  This is
>             the case when a set of public identifiers is no longer
>             associated with original SSP but have been ported to a
>             recipient SSP who provides access to these identifiers via
>             a switch on the SS7 network identified by the RN.  In this
>             case a destination group containing all numbers that should
>             be routed to this RN needs to be created and the route
>             group associated with this DG needs to contain the RN

I do not think this is a good idea.

===
[S] :)
===

#21
>4.  Requirements
>
>   REQ13:  Support for lookup keys having identical business keys (the
>           public identity string, the digits that comprise an RN, the
>           start and end point of a TN range's range) that concurrently
>           exist across multiple destination groups and where each
>           destination group may be managed by different SSPs.
>
>           Editor's note: We need to simplify the above requirement.

btw, one thing that is missing is the handling of overlapping information:

e.g.

SSP-A provisions:  123-1000 to 123-1999 to DG "foobar"
SSP-B provisions:  123-1100 to 123-1149 to DG "funk"

what would a query for 123-1120 yield? Both entries? Just the one from the closer match?

===
[S] I don't know if we speak about the resolution here. My personal take is that both of them should be returned (assuming the recipient is allowed to see either).
===

#22

>5.  Security Considerations
>
>   Session establishment data allows for the routing of SIP sesions
>   within, and between, SIP Service Providers.  Access to this data can
>   compromise the routing of sessions and expose a SIP Service Provider
>   to attacks such as service hijacking and denial of service.  The data
>   can be compromised by vulnerable functional components and interfaces
>   identified within the use cases.

This is a bit thin.

Consider:

* data-leaks
* stale data in the registry
* protection against a malicious SSP
* re-routing of calls due to injection of wrong data

===
[S] OK
===

#23
>
>7.  Acknowledgments
>
>   (AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey,
>   Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of

Neustar.

===
[S] Thanks! 
===

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 02 Aug 2010 22:14:50 +0200

On 02.08.2010 18:04, Sumanth Channabasappa wrote:
> 
> [FYI, I believe we discussed some of these at the meeting, ]

Yes, some things got clarified during the meeting.

A number of my comments were editorial comments, where I just think you
need to improve the document. I'll skip over these now.

> [S] The idea here was to allow for additional associations with a public identity, outside of TNs. Email was referenced as an example (not as a look-up key). 

This is confusing. From the rest of the use-cases one would assume that the
PI is always the key to the lookup. While I can see the utility of
returning the email-address associated to a TN (e.g. for MMS or
voice-mail), IMHO that address should then be part of the Route-Set and not
part of the PI.

Perhaps the best way forward is to provide an example on where
email-addresses could appear in a use-case, and use SIP URIs as examples of
a PI.

>>      SED can be looked up (resolved).

As per the Maastricht session: you should explicitly state both that this
could be a range in a closed numbering plan, or a prefix in an open
numbering plan setting.

> good. perhaps not just SED, but also the "who sees what" properties.

If I take a look at the overview diagram, then all the selective
peering/visibility features do not apply to a single TN/RN/PI, but are
connected to DG. so "..that share common SED" is just one part, a DG is
also atomic in respect to the selective peering features. IMHO that should
be part of the definition.

> Please leave the PIs, TN ranges and RN out of the definition, RGs are only connected to Destination Groups.

As you say, RGs associate DGs to SED, so PIs, TN ranges and RN should not
be in the definition.

As I wrote, I don't think the idea is wrong. I just think that you don't
make the case for the idea overall in this document.

(Somehow this reminds me of file system permissions: The simple unix
user-group-world system can do anything, but some settings are tricky to
do. Other systems (e.g. windows), provide other abstractions as well, that
can be helpful in simplifying some rules. But as you made the TN-DG
relationship 0..n:1, you will probably need the ability to do route-groups.)

So some more explanations or examples would be helpful.

> As before, some more explanations on the RG, perhaps with some examples might be helpful.

Yes.

> I think the direct PI-SED link should be removed. It just leads to endless special-cases in all the code.

One idea on how one might simplify this:

Perhaps provide for an RN/TN/PI -> RN/TN/PI mapping for these cases? The
actual routing could then go via the normal way.

> [S] Destination Group is an internal structure, so it would be by PI, RN or TN Range. We can clarify.

Hu?

Do DG feature in the protocol? if yes, then it is better to tell users
right here that DGs are atomic with respect to the selective peering features.

>>                       in the LUF.  The SSP needs to provision a

[...]

> [S] OK :)! I think we agreed to make this abstract at the meeting.

I'll try to write up my suggestions later this week.

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

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 03 Aug 2010 21:39:52 +0200

> I'll try to write up my suggestions later this week.

Here are my thoughts on how one might approach the data structures in the
route records.

This is based on http://tools.ietf.org/html/draft-ietf-drinks-spprov-01

There they are defined as:

   o  Route Record (RteRecType):
      A Route Record is the data that the resolution systems return in
      response to a successful query with the Public Identifier as the
      query string.  It is associated with a Route Group for routes that
      are not specific to a Public Identifier.
      To support the use cases defined in
      [I-D.ietf-drinks-usecases-requirements], SPPP protocol defines
      three type of Route Records: URIType, NAPTRType, and NSType.
      These Route Records extend the abstract type RteRecType and
      inherit the common attribute 'priority' that is meant for setting
      precedence across the route records defined within a Route Group
      in a protocol agnostic fashion.

The NAPTRType is basically 1:1 the fields in a NAPTR, but the URIType is
more interesting:

       <complexType name="URIType">
         <complexContent>
           <extension base="spppb:RteRecType">
             <sequence>
               <element name="ere" type="string" default="^(.*)$"/>
               <element name="uri" type="string"/>
               <element name="ext" type="spppb:ExtAnyType"
   minOccurs="0"/>
             </sequence>
           </extension>
         </complexContent>
       </complexType>

This is quite nice and tails very closely what the NAPTRs are doing.

But let's step back for a second and look at what's common to all these
Route Records. We have:

* Route Records that map from the PI to an URI
	+ Terminal NAPTR
	+ URIType

* Route Records that only generate a referral, not a full resolution
	+ NSType
	+ non-terminal NAPTR

So, if we would want to create a more resolution-protocol independent set
of Route Records, we could do it in the following way:

That record needs to contain:

* A regex
  - Maybe allow in the XML an alternative to the /^.*$/whatever/ greedy
match by stating "<replaceWith>whatever</replaceWith>.

* What kind of PI it applies to? (what is the input to the regex?)
  - E.164 number
  - SIP uri
  - ...

* What kind of service it applies to?
  - voice calling
  - message service (SMS, MMS)
  - voicemail
  - video calling

* How to interpret the result of the regex?
  - A re-target operation
	(like ENUM, the result becomes the new request-URI)
  - A routing operation
	(The request-URI is not touched (e.g. can remain a tel: URI),
	the result just defines the next SIP hop.)
  - A referral
	This need not be limited to
	"go use ENUM to query the following Nameservers"
	but could also be something like
	"query the following SIP server for a redirect"	
	or even a
	"go to a completely different resolution scheme"
---

This way, we're completely independent of a resolution protocol. Some of
these route records can be used to populate ENUM trees (if it's not a
re-target operation, one would need something like
http://www.ietf.org/mail-archive/web/sip/current/msg23298.html). Others
might drive SIP redirect servers.

Comments?

otmar

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 4 Aug 2010 10:27:42 -0400

I know that the question of an open numbering plan has come up a couple times, however, it's not clear to me why this is not simply a matter of policy and has no bearing on the SPPP protocol itself.

1) The resolution server can/should be aware of each of the country codes that adhere to an open numbering plan.
2) The resolution server can/should, for country codes known to have an open numbering plan, interpret an SPPP TNRange within such a country code as being inclusive of TNs that may be longer than the start and end point of the range.  As a result, the best match of the provisioned TNRanges will be selected, even of the queried TN is longer than the best matching TNRange.

Iow, afaik, there is *not* the need for the following in SPPP:
1) For country codes that *do not* support an open numbering plan, allow provisioning of a TNRange in that country code and mark that TNRange as *an* "open number plan TNRange".
2) For country codes that *do* support an open numbering plan, allow provisioning of a TNRange in that country code and mark that TNRange as *not an* "open number plan TNRange".

Sorry about the double negatives, etc, above, perhaps there is a more succinct way to state this, but I think you get the point.

Making this a matter of policy would of course be superior to embedding it in the protocol because the provisioning activities will be simpler on the SPPP clients as well as the SPPP servers.

Ken

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: Alexander Mayrhofer <[email-masked]>
Date: Wed, 4 Aug 2010 16:55:55 +0200

<WG chair hat off>

> 1) The resolution server can/should be aware of each of the 
> country codes that adhere to an open numbering plan.

It could. But i think this is out of scope of our work, since this would
mean having to keep up to date with 200+ local regulators, and their
actual policy (which, btw, might even vary by region).

Plus, even in countries with an open numbering plan there might be
specific number types that have an closed numbering plan. For example,
it could be possible that geographic numbers follow an open numbering
plan, while mobile numbers are of fixed lenght.

Unfortunately, it's pretty complicated - don't get me started. 

> 2) The resolution server can/should, for country codes known 
> to have an open numbering plan, interpret an SPPP TNRange 
> within such a country code as being inclusive of TNs that may 
> be longer than the start and end point of the range.  As a 
> result, the best match of the provisioned TNRanges will be 
> selected, even of the queried TN is longer than the best 
> matching TNRange.

I think this is very risky. Such interpretation might vary over time, as
countries change their numbering plans. Which would mean that if a
country (or region of a country) changes their administrative model, the
semantics of an SPPP object would change - withount a change in the
protocol.

I don't want to require ITU-T driven (or local regulator driven)
knowledge in network elements affect the semantics of objects in our
protocol. That just does not work.

> 1) For country codes that *do not* support an open numbering 
> plan, allow provisioning of a TNRange in that country code 
> and mark that TNRange as *an* "open number plan TNRange".
> 2) For country codes that *do* support an open numbering 
> plan, allow provisioning of a TNRange in that country code 
> and mark that TNRange as *not an* "open number plan TNRange".

I think that there is definitely the need for distinguishing "prefix"
style TNs and TN ranges from "non-prefix" style TNs or TN ranges.
Particularly because as outlined above, a country could very well mix
open and non-open numbering ranges.

> Making this a matter of policy would of course be superior to 
> embedding it in the protocol because the provisioning 
> activities will be simpler on the SPPP clients as well as the 
> SPPP servers.

I think the contrary is true: Embedding a way to indicate whether a TN
or TN range is of "prefix" style is superior to policy. Because the
policy depends on external parties, which means that semantics of an
object in SPPP could change over time, just because that external party
changes the policy.

Please please please make SPPP independent of ITU-T and regulatory
policy. It's simple:

<tn>+1813555666</tn> - "plain" TN - does not include +18135556667
<tn prefix='1'>+4315056416</tn> - "prefix" TN - *does* include
+4315056416

(side note: have we defined tnrange yet?)

"plain" TNRange - does not include +181355534377

<tnrange>
   <start>+1813555000</start>
   <end>+1813555999</end>
</tnrange>

"prefix" TNRange - *does* include +4315056416930

<tnrange prefix='1'>
   <start>+4315056400</start>
   <end>+4315056499</end>
</tnrange>

Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 4 Aug 2010 17:15:33 +0200

> protocol. That just does not work.

(WG chair hat still off, of course!)

I'd like to go even one step further. I object to all "hidden" semantics
in SPPP, based on external "background" information. SPPP should even be
agnostic to the list of (currently) valid country codes. 

For TNs in SPPP, everything should just be (E.164?) numbers. Hidden
semantics should only be applied by local policy (for example, a
registry could reject "prefix" type TN ranges in the NANP), but it
should not be contained in the protocol.

It's similar to how SMTP can be used to transport even emails using
"invalid" top level domains. SMTP is agnostic to the root zone, and it's
local policy of SMTP servers what to accept.

Alex

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 4 Aug 2010 11:39:44 -0400

Ok.  I'm sold.  If there is a possible need to allow the "openness" of the numbering plan to vary within a given country code, depending on who is provisioning the number(s), then we certainly need to move this out of policy and into the protocol.

Ken

-----Original Message-----
From: Alexander Mayrhofer [mailto:[email-masked]]
Sent: Wednesday, August 04, 2010 10:56 AM
To: Cartwright, Ken; IETF DRINKS WG
Subject: RE: [drinks] Open Numbering Plan

<WG chair hat off>

<tnrange>

<tnrange prefix='1'>

Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 4 Aug 2010 17:51:23 +0200

> Ok.  I'm sold. 

That was quick. I actually prepared myself for multiple 100+ messages
long thread ;)

Alex

---

From: "Cartwright, Ken" <[email-masked]>
Date: Wed, 4 Aug 2010 11:53:02 -0400

I think I agree with your statements below, but...

SMTP as a set of data structures does of course not imply much (if any) meaningful provisioning policy.  However, the applications that manage and provision email addresses and *use* SMTP under the covers apply all sorts of policies.

A more appropriate analogy here than SMTP I think is EPP and a domain name provisioning system.  All systems that use EPP, both as clients and server apply all sorts of policies to control what domain names are/canBe provisioned using EPP, what those domain names can look like, what words those domain names can contain, when they can be provisioned, when and how they can be deleted, when and how they can be modified, when and how they can be renewed, etc, etc.  SPPP clients and servers are highly likely to apply policies that rely on external "background" information.  But this has little to do with EPP.

Ken

-----Original Message-----
From: Alexander Mayrhofer [mailto:[email-masked]]
Sent: Wednesday, August 04, 2010 11:16 AM
To: Alexander Mayrhofer; Cartwright, Ken; IETF DRINKS WG
Subject: RE: [drinks] Open Numbering Plan

Alex