Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy

From: "Stastny Richard" <[email-masked]>
Date: Fri, 6 Jan 2006 00:10:21 +0100

>We also need to address: how does a mobile user enjoy the outcome of his
>home admin-domain policy when the he is visiting a foreign admin-domain
>that implements a different policy.

First someone needs to explain to me what "visiting a foreign domain"
means on the public Internet.

I always register with my home domain. I may use a different access,
but I am always contacted via my home domain, using my home profile.

I would consider it very strange if e.g. the Mariott in New York where I am
currently connected would screen my incoming calls depending on THEIR policy

Richard

________________________________

Von: [email-masked] im Auftrag von Khan, Sohel Q [CTO]
Gesendet: Do 05.01.2006 22:20
An: Michael Haberler; Richard Shockey; David Meyer
Cc: [email-masked]; Henry Sinnreich; [email-masked]; [email-masked]
Betreff: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy

We also need to address: how does a mobile user enjoy the outcome of his
home admin-domain policy when the he is visiting a foreign admin-domain
that implements a different policy.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Haberler
Sent: Thursday, January 05, 2006 11:46 AM
To: Richard Shockey; David Meyer
Cc: Henry Sinnreich; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

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

>--
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>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>
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>_______________________________________________________________________
>______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html

________________________________________________________________________
_____
List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html

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

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

---

From: lconroy <[email-masked]>
Date: Thu, 5 Jan 2006 23:35:54 +0000

Hi Richard, folks,
  ... but, then again, the Marriot doesn't charge you to receive calls.

When looking at IMS, I am reminded of the following quote:

"In C++ it's harder to shoot yourself in the foot, but when you do,  
you blow off your whole leg."
— Bjarne Stroustrup.

Re. the draft - which is what this thread WAS about...

IMO, it's an excellent start - lots of fixmes, but a solid base on  
which to build.

As mentioned by others, I also wonder about whether or not a domain  
is the atomic
level for a particular federated policy. This SEEMs to be  
appropriate, but I can't
picture every possible scenario.

I AM reminded of the discussion a few years back on the phone context  
for the tel:
URL. At least for SIP peering as discussed in the draft, one may have  
a simpler
problem to solve, and SIP does use a domain as an atomic element:
One is going to talk to a server, and through SRVs and the whacky  
load-balancing
NAPTRs, that/those server(s) claim to be authoritative for that  
domain's SIP
processing, so I think it/they will apply a consistent policy ***FOR  
PEERING***.

This is different from an individual recipient's policies; I would  
assume that
executing those policies is a job for the end user (or his/her agent).

IMHO, executing Individual policies is way out of scope for ENUM, and  
speermint,
and anything else that is dealing purely with peering. If that  
Individual's device
has registered with a different domain, then it's no surprise if a  
different policy
is applied.

Peering had better work on IMS, or GSMA have not been doing their job  
- either way,
how is this the IETF's problem?

all the best & happy new year,
   Lawrence

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 5 Jan 2006 18:28:46 -0600

>how is this the IETF's problem?

Correct! I believe this sums it up.

Thanks, Henry

-----Original Message-----
From: lconroy [mailto:[email-masked]] 
Sent: Thursday, January 05, 2006 5:36 PM
To: Stastny Richard
Cc: Khan, Sohel Q [CTO]; Michael Haberler; Richard Shockey; David Meyer;
[email-masked]; Henry Sinnreich; [email-masked];
[email-masked]
Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP
PeeringPolicy

Hi Richard, folks,

- Bjarne Stroustrup.