Subject: Re: [Enum] I-D: Publishing SIP Peering Policy

From: Adrian Georgescu <[email-masked]>
Date: Tue, 3 Jan 2006 09:24:52 +0100

Hello Michael and Otmar,

I believe this is a very good framework to start build on. By storing  
the desired peering information at the destination instead of the  
source or a central place the information will always be up to date  
as the owner of the domain is directly interested to keep its own DNS  
data in sync with his policy. This is clever and makes perfect sense.

I fully support what is described in this draft.

Regards,
Adrian

On Dec 29, 2005, at 4:32 PM, Michael Haberler wrote:

> [we've worked out a method to publish SIP peering policy through  
> the DNS. It falls into SPEERMINT territory but I think it's  
> relevant for ENUM as well.
> here's the gist in a nutshell - flames on. -mah]
>
> --
>
> There will be many, potentially incompatible SIP peering schemes,  
> and looking
> at a SIP URI does not help in deciding wether it is reachable (or  
> "peerable"). Such
> information could be managed in local tables at the egress point.  
> However, such static
> setup information is unwieldy to manage and similar in nature to a  
> hosts.txt table, or
> static routes, and associated disadvantages.
>
> To aid runtime discovery of "peerable" destinations, and facilitate  
> management of
> peering arrangements (including auto-discovery of new peering  
> partners which subscribe
> to the same set of policies), we propose to name the scheme(s) used  
> by a provider and
> publish them in the DNS, by specialized NAPTR RRs. This enables the  
> egress point to
> decide - in advance and without pre-configuration of peers - wether  
> the ingress
> point will accept a SIP INVITE, and which technique should be  
> employed.
> Our proposal also allows smooth migration between peering methods  
> and helps reduce
> the complexity of arrangements by introducing federations, of which  
> a bilateral
> arrangement is just a special case.
>
> Our proposal focuses on the URI level, and assumes that E.164  
> numbers are already
> mapped to a URI, for instance by some form of ENUM.
>
> This draft addresses the problem of managing the peering fabric  
> from an end-to-end
> perspective, which is a core task of the SPEERMINT charter.
>
> Michael Haberler
> Otmar Lendl
>
>
> On 2005/12/28 16:12, [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet- 
> Drafts directories.
> >
> >
> > 	Title		: Publishing SIP Peering Policy
> > 	Author(s)	: O. Lendl
> > 	Filename	: draft-lendl-sip-peering-policy-00.txt
> > 	Pages		: 16
> > 	Date		: 2005-12-28
> > 	
> > This documents proposes the use of DNS entries to publish a SIP
> >    proxy's policy for accepting incoming calls.  Such published  
> policies
> >    can be used to selectively establish peering relationships  
> between
> >    VoIP service providers.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lendl-sip-peering- 
> policy-00.txt
> >
> > [...]
>
>
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

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

---

From: David Meyer <[email-masked]>
Date: Tue, 3 Jan 2006 15:46:01 -0800

On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote:
> This is seems to be an excellent approach and I suggest we discuss it on the
> list and close at the 65 IETF meeting in March.

	Ditto (and happy new year everyone). BTW, I've been
	trying to spin up the [email-masked] mailing list,
	but there have been a few snafus. I'll let folks know
	when that one is up.

	Dave

---

From: Richard Shockey <[email-masked]>
Date: Wed, 04 Jan 2006 12:42:47 -0500

>>list and close at the 65 IETF meeting in March.

This is a general question for the list in general.

Presuming you could query a network for its VoIP peering policy.

What data on terms and conditions of peering would one need to encapsulate?

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: David Meyer <[email-masked]>
Date: Wed, 4 Jan 2006 13:47:33 -0800

Folks,

	Please subscribe to [email-masked], and lets move our
	discussion(s) there. Please see 

	 https://www1.ietf.org/mailman/listinfo/speermint

	As an list administrative point, we'll subscribe
	[email-masked] to voipeer after we see the traffic
	die down over there (hopefully a couple of weeks or so). 

	Thanks,

	Dave

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 5 Jan 2006 10:04:11 -0600

I am not sure if everyone is aware of the recent I-D by K. Carlberg and what
it says ( I have added boldface and underline):

http://www.ietf.org/internet-drafts/draft-ietf-ieprep-domain-frame-06.txt 

Needless to say I whole heartedly agree and suggest to include this into the
philosophy of the documents of this WG.

1.1.  Differences between Single and Inter-domain

   The progression of our work in the following sections is helped by

   stating some key differences between the single and inter-domain

   cases.  From a general perspective, one can start by observing the

   following:

    a) Congruent with physical topology of resources, each domain

       is an authority zone and there is currently no scalable way

       to transfer authority between zones.

    b) Each authority zone is under separate management

    c) Authority zones are run by competitors, which acts as

       further deterrent to transferring authority.

   As a result of the initial statements in (a) through (c) above, addi-

   tional observations can be made that distinguish the single and

   inter-domain case, as stated in the following"

    d) Different policies might be implemented in different

       administrative domains.

    e) There is an absence of any practical method for ingress nodes of

       a transit domain to authenticate all of the IP network layer

       packets that have labels indicating a preference or importance.

    f) Given item (d) above, all current inter-domain QoS mechanisms

       at the network level generally create easily exploited and

       significantly painful DoS/DDoS attack vectors on the network.

Thanks, Henry

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Wednesday, January 04, 2006 11:43 AM
To: David Meyer
Cc: Henry Sinnreich; 'Michael Haberler'; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

 

 

-- 

NeuStar Inc.

ENUM +87810-13313-31331

Fax: +1 815.333.1237

---

From: Michael Haberler <[email-masked]>
Date: Thu, 05 Jan 2006 18:45:51 +0100

>What data on terms and conditions of peering would one need to encapsulate?

here's what we could think of  - terms and conditions basically come 
from the following four realms:

* Technical
   - What SIP transport is required?
   - SIP extensions? URI conventions? Privacy? Caller-ID?
   - Anti SPIT measures.
   - QoS

* Contractual
   - Do I need to sign a contract (with whomever) beforehand?

* Regulatory
   - Is a certain legal status required? E.g. only registered
     Communication Service Providers may initiate calls.
   - E.g. sender must conform to local CALEA or other rules.

* Financial
   - No settlement?
   - If yes, how.

Note that we are NOT proposing to auto-detect, auto-match this full 
gamut of policy elements - we need to finish this in time; 
auto-matching legal & regulatory aspects is out of scope for us.

Another general question is the following: Is the peering policy a 
function of the recipient's domain, or one of the full URI? In other
words, is peering done one the domain level (and thus equal to all 
users ain that domain) or do we need to support policies which differ amongst
users?

Michael Haberler
Otmar Lendl

>_____________________________________________________________________________
>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 5 Jan 2006 15:00:17 -0600

A scalable approach must include peering policies that can be matched
without human intervention. Today, it is best effort QoS with no other
strings attached. It will be interesting to see if it possible to have
anything else better than best effort: Maybe some DSCP to start with.

A DSCP for QoS may be a good start for interdomain VoIP.
What other policies could be automated for matching by machines?

I would avoid having a big registrar in the sky, other than DNS and ENUM,
since otherwise we will be back to politics again. Besides: 
Everybody will want to be this registrar :-) Also known as a settlement
house. We could end up with just as many settlement providers as there are
VoIP islands.
The latest count is 552 at http://www.myvoipprovider.com/

Starting with ENUM/DNS discovery as you have proposed and DiffServ between
consenting peering VoIP providers would be a great accomplishment by this
WG! 

Thanks, Henry

-----Original Message-----
From: Michael Haberler [mailto:[email-masked]] 
Sent: Thursday, January 05, 2006 11:46 AM
To: Richard Shockey; David Meyer
Cc: Henry Sinnreich; [email-masked]; [email-masked]; [email-masked];
[email-masked]

* Technical

* Contractual

* Regulatory

* Financial
   - No settlement?
   - If yes, how.

Another general question is the following: Is the peering policy a 
function of the recipient's domain, or one of the full URI? In other
words, is peering done one the domain level (and thus equal to all 
users ain that domain) or do we need to support policies which differ
amongst
users?

Michael Haberler
Otmar Lendl