RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

"Richard Shockey" <richard@shockey.us> Sun, 28 May 2006 18:03 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkPc5-0008Ql-Ec; Sun, 28 May 2006 14:03:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkPc5-0008Qg-33 for speermint@ietf.org; Sun, 28 May 2006 14:03:41 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkPc3-00069C-NG for speermint@ietf.org; Sun, 28 May 2006 14:03:41 -0400
Received: from RSHOCKEYLTXP (h-68-165-240-36.mclnva23.covad.net [68.165.240.36]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k4SI41YP004015 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 28 May 2006 11:04:03 -0700
From: Richard Shockey <richard@shockey.us>
To: "'Francois D. Menard'" <fmenard@xittelecom.com>, 'Otmar Lendl' <lendl@nic.at>, "'Michael Hammer (mhammer)'" <mhammer@cisco.com>
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
Date: Sun, 28 May 2006 14:03:21 -0400
Message-ID: <00e901c68281$02d3e0f0$24f0a544@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
In-Reply-To: <01d101c6812b$01412060$8b02a8c0@gestionfm>
thread-index: AcaA2Le010KfVlOFQ2qE5Is0+ne8LwAUcYkAAFWHPIA=
X-SongbirdInformation: support@songbird.com for more information
X-Songbird: Clean
X-Songbird-From: richard@shockey.us
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: "'Khan, Sohel Q [CTO]'" <Sohel.Q.Khan@sprint.com>, speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: richard@shockey.us
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org


> -----Original Message-----
> From: Francois D. Menard [mailto:fmenard@xittelecom.com]
> Sent: Friday, May 26, 2006 9:15 PM
> To: 'Otmar Lendl'; 'Michael Hammer (mhammer)'
> Cc: 'Khan, Sohel Q [CTO]'; speermint@ietf.org
> Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> > * infrastructure ENUM will be public (if it wants to enable more than
> just
> national peerings).
> 
> This is why I had the Canadian ENUM trial framework modified to hold
> non-terminal NAPTRs in Tier 1B which is unlike the US enum trial
> framework.


Yes but many of us really dislike the use of non terminal NAPTRS since their
behavior is not sufficiently documented.



> 
> 
> > My thinking was that one would need to progress through a series of
> > steps/functions where the bootstrap steps are very public, but the
> > later steps depend on the previous step enabling it.  The chicken or
> > egg problem shouldn't occur for first steps.
> 
> That's why we put the bootstrapping steps into the DNS. Any other system
> SPEERMINT will come up with, e.g. some SUBSCRIBE/NOTIFY would fit in very
> nicely: the domain policy the can reference this framework as the
> requirement to reach the destination.
> 
> > (I do understand your model
> > where you advertise what is only reachable by a few, but then it is
> > working as you intended with selective unreachability being part of
> > your
> > design.)
> 
> As I see the market right now, we already have a very selective
> reachability
> on the SIP layer between VoIP operators.
> 
> I can't see a way to move the state of affairs to "interconnection on SIP
> basis between all commercial VoIP-operators worldwide" without either
> 
> * building a SIP routing protocol complete with transit networks
>   (the BGP model)
> 
> or
> 
> * require the possibility of direct connections between all
>   operators worldwide.
>   Determining whether the caller from halfway around the globe
>   is a legitimate operator is massively difficult, thus we
>   end running open servers. (the email model)
> 
> Thus I think selective reachability on SIP will stay with us for the
> medium
> term.



They are called bi-lateral agreements. 



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint