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

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 15 Jul 2010 14:28:26 +0200

All,

we're looking for 2-4 additional volunteers for
https://datatracker.ietf.org/doc/draft-ietf-drinks-usecases-requirements
(outside of the core contributor team of the document). The document is
pretty mature at this point. However, before doing working group last
call on it, we'd like to have it reviewed thoroughly.

If you can spend the time on doing a review of the document within the
next one or two weeks, we'd appreciate your contribution. Please respond
to list or privately to the chairs at [email-masked].

thanks,

Alex

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 21 Jul 2010 15:47:32 +0200

On 2010/07/15 14:07, Alexander Mayrhofer <[email-masked]> wrote:
> (outside of the core contributor team of the document). 

I couldn't refuse Alex's request ...

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

Overall this is a fine document and a good basis for further work.
Here are my notes:

>
>               DRINKS Use cases and Protocol Requirements
>               draft-ietf-drinks-usecases-requirements-03

>1.  Terminology
>
>
>   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?).

>   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.

>   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.

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

Is this run by the SSP it serves?

>   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]?

>   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.

>   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.

>   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.

>   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.

>   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.

>
>   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.

>
>                                  . . . . . . .
>                  . . . .  . . .   registry    . . . . . . .
>                .                 . . . . . . .              .
>              .                        .                      .
>            .                          . provision             .
>       +-----------+                   .                 +-----------+
>       |           |  provision  +----------+  provision |           |
>       |   SSP 1   |------------>| Registry |<-----------|   SSP 2   |
>       |           |             +----------+            |           |
>       |  +-----+  |                   /\                |  +-----+  |
>       |  | LDR | <--------------------  ------------------>| LDR |  |
>       |  +-----+  |   distribute           distribute   |  +-----+  |
>       |           |                                     |           |
>       +-----------+                                     +-----------+
>              .                                                .
>               . . . . . . . . . . . . . . . . . . . . . . . .
>                              (provision / distribute)

>   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.

>
>   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.

>   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.

>   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.

>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.)

>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).

>
>   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.

>               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.

>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.

>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?

>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

>
>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.

I hope this helps,

[I re-sent this mail with a better envelope-from. Sorry if it's a duplicate
on the list.]

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg