Subject: Re: [Speermint] [wg-business] WGLC fordraft-ietf-speermint-terminology-12

From: Otmar Lendl <[email-masked]>
Date: Mon, 5 Nov 2007 15:15:05 +0100

On 2007/10/26 01:10, Daryl Malas <[email-masked]> wrote:
> Otmar, I apologize for taking so long to respond to your comments.

No need.

> (FYI...I'm updating the draft right now.)

I've just had a look, looks a lot better.  I'll send a review of this
version in a separate mail.

> > >                | 
> > >                | <--- ENUM lookup of NAPTR in Domain Name System (DNS) 
> > >                | 
> > >                | 
> > >                | ENUM Working Group Scope 
> > >           =====+==================================================== 
> > >                | SPEERMINT Working Group Scope 
> > >           Lookup 
> > >           Discovery <--- Session Establishment Data (SED)                    
> > >           SIP URI 
> > 
> > According to the SED definition below, SED is definitly not
> > the input into the speermint WG scope; instead I see it as
> > the result of this step:
> > 
> I disagree with some of this.  Although, I could agree the "SIP URI" is
> not part of the scope of SPEERMINT, it is derived of information
> attained through steps defined in SPEERMINT.
> 
> Lookup = Look-up Function
> Discovery = Location Function
> SIP URI = Derived information from these prior to functions

I think the main source of our disagreement is the overloaded nature
of the term "SIP URI". In the context of speermint, IMHO we encounter
at least two very different incarnations of that term. 

a) SIP Address of Record (AoR)

That's the SIP aequivalent of an email address. That's the thing you
put on your business cards. Examples are: sip:[email-masked], 
sip:[email-masked], sip:[email-masked]

b) Context dependent SIP URI

If a federation runs a private ENUM within a private peering
network, then the URIs stored within that ENUM might look like
sip:[email-masked].<privateroot> which is only resolvable
to an IP address in the private DNS inside that peering network.

In extreme cases this could just as well be a URI as used in the
Contact header: sip:[email-masked]

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

What does this mean for speermint?

If we do number-based dialing/routing, then the ENUM step can happen
inside a federation (via that federation's Lookup function) and yield
a SIP URI which explicitly contains the carrier's border element for
calls inside that federation. (resolving that into an IP address /
transport / portnumber is then straight-forward using the RFC3263 
algorithm in either private or public DNS trees).

But what happens when we don't do number-based dialing/routing?
In that case we somehow need to map the AoR to the next SIP hop.
The Lookup function thus doesn't take a E.164 number as the input
(as it was above), but needs to operate on a SIP AoR. 

What are the options? 

* One could use pure RFC3263 in the public DNS. This gives the same
ingress element for all askers and thus does not support control on
who actually is peering.

* RFC 3263 in a federation-internal DNS tree. That's fine for AoR which
use provider-owned domains. It won't scale for customer-owned domains
for which carriers just host the SIP service.

* Something completely different.

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

What does this mean for this document?

I think we have to differentiate between the SIP AoR which can be the 
input in the whole speermint scenario (when doing URI-based calling)
and any other SIP URI addressing a specific border element inside a
federation.

We might bring back the term Call Addressing Data (CAD) that we had
in some earlier revision of the draft. With that we can be clearer:

CAD: Either a E.164 phone number or a SIP AoR (potentially using a
customer-owned domain). This is the input into the overall call routing
algorithm.

SED: A SIP URI which is specific to a federation and which directly
encodes the next-hop information.

The task for speermint can thus be defined as "Devise an algorithm how
to derive SED from CAD".

> > >3.4. Call Routing 
> > >
> > >   Call routing is the set of processes, rules, and SED used to route a 
> > >   call to its proper (SIP) destination.  More generally, call routing 
> > >   can be thought of as the set of processes, rules and SED which are 
> > >   used to route a real-time session to its termination point. 
> > 
> > Please strike SED from this paragraph.
> As I described earlier, I think the Look-up and Location functions are
> part of deriving SED for peering.

I see the SED as the result of this processing.

/ol
-- 
/ 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 /

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint