Subject: [Speermint] Questions for Clarification

From: "Stastny Richard" <[email-masked]>
Date: Tue, 21 Mar 2006 21:18:53 +0100

I have some questions for clarification regarding the SPEERMINT charter
(or in ITU-T speak: Mr Chairman, I am confused)
 
"SPEERMINT focuses (on) architectures to identify, signal, and route
delay-sensitive (real-time) communication sessions. These sessions
use the SIP signaling protocol to enable peering between two or more
administrative domains over IP networks. Where these domains peer,
or meet, the establishment of trust, security, and a resistance to
abuse and attack are all important considerations."

First question: the term IP networks seems to need clarification:

IP networks is a generic term valid for both the Internet and private
(walled garden) IP networks, but
 
I had always the opinion that this is the INTERNET Engineering
Task Force (IETF) and the PRIMARY goal is to define architectures to
identify, signal and route ... sessions on the public INTERNET.
 
This does not prevent anybody to use these architectures and related 
protocols also on private IP networks, as it is done with other protocols
and architectures (e.g. the DNS).

But is is NOT the task of the IETF to define such architectures and
protocols PRIMARILY for the use in private IP networks.
 
So I undersatnd that the primary goal of SPEERMINT is to enable
peering between two or more administrative domains on the INTERNET.
 
and also to establich trust, security ans resistance to abuse and attacks on
the Internet.
 
I consider it therefore curious that some say the I-Ds draft-lendl-domain-policy-ddds-00
and draft-lendl-speermint-federation-00 are out of scope. If these drafts are out-of-scope
then maybe somebody would be so nice to explain to me what is in scope of SPEERMINT.
 
I am also confused about the statement from Rohan that nobody will use this because no
provider will make public to which federation he belongs to.
 
Since this drafts are modelled along the quite sucessful model of BGP peering, I wonder.
 
Imagine yor airline has a frequent flyer program, but not disclosing that it is part of 
Star Alliance.
 
It is true that SPEERMINT is special (optional?) within the IETF, because to peer between
SIP proxies on the Internet all you need is SIP AoRs and RFC 3263 NAPTR and SRV,
and I also understand that the major problem of  the VSP starts with the SIP URI giving away
their identity (some peering fabrics make a living on this ;-)
 
Nobody seems to have a problem with this with e-mail
 
Voice is really a special application, infecting anybody with bell-headism
 
best regards
 
Richard

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

---

From: Michael Haberler <[email-masked]>
Date: Thu, 23 Mar 2006 11:28:29 +0100

>provider will make public to which federation he belongs to.

I'd be very interested what people believe to be a viable alternative 
to runtime policy discovery - in particular visavis the fact that the 
draft-lendl-domain-policy-ddds-00 proposes to pubish a unique ID for 
a policy to enable runtime matching, but NOT requiring to publish 
what that policy ID actually stands for.

In BGP speak this amounts to: "Here is my AS number. You might find 
that AS number tacked to other domains if you scan a lot of them, but 
no, we are not publishing our peering and transit relations in an RIR 
database". As for the BT example, saying that the sip.bt.com ingress 
point supports the BT IP interconnect policy, which is likely to be 
found on a BT website as their Reference Interconnect Offer in the 
first place. So much for the danger of "private parts exposure".

I have a hard time believing we are back to static local 
configuration as the "preferred" solution, be that bilateral setup or 
"everything goes to my peering shop".

Here's a paper exercise for you to tinker with alternatives:

With SIP capabilites as they stand today, please emulate the GSM 
association - that's 600+ operators with some 23.000 interconnect agreements.

In the first attempt, try to avoid the "big SIP hub" scenario for 
extra intellectual challenge.

After done with defining pathetic access lists and local routing 
tables, I assume you're motivated to think about alternatives. Then 
again, if one has gobs of staff managing interconnect relations, that 
staff could well eventually be retrained to edit access control lists 
and tables.

 From a commercial point of view, there likely is a business case for 
the SIP hubs/peering providers. I think they have real value as 
SIP/RTP cleansing shops. I'm not sure that approach should be the 
IETF entropy solution to fabric discovery.

And, while lashing out at the unsuitability of 
draft-lendl-domain-policy-ddds-00 for current service provider 
mindsets, keep in mind it does not limit itself to "carriers" - it 
does address groups of users, and in fact the user-service provider 
interface policy discovery problems just as well.

Bonus value: it also includes "go to my peering shop" - besides 
keeping the end-to-end option open.

-Michael