Subject: RE: [Speermint] Dear Collegues .. a modest proposal.

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 21 Sep 2006 17:30:45 -0400

Richard,

You sign a contract with a federation (perhaps one run by a carrier),
get a certificate, provision your proxies, and go.

Why do you need to have bi-lateral contracts with all N-thousand members
of the federation?

That seems very manual and very complex in the number of lawyers you
would need. :)

Mike

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Wednesday, September 20, 2006 6:26 AM
> To: Michael Hammer (mhammer); 'Stastny Richard'; 'Andrew Newton'
> Cc: [email-masked]
> Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
> 
> 
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Tuesday, September 19, 2006 3:21 PM
> > To: [email-masked]; Stastny Richard; Andrew Newton
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
> > 
> > ATIS has already put out an ANSI NNI standard.  Why 
> reinvent that wheel?
> 
> So why does SPEERMINT exist? See charter.
> 
> > 
> > I think it is important to realize that the world will 
> divide itself 
> > up into federations based on their natural affinities, and 
> that they 
> > won't all agree on the NNI profile.  So, it is better to spend time 
> > defining how to discover whether the party targeted by the E.164 
> > number is in a federation shared with the calling domain, 
> or whether a 
> > transit SP is needed, and which one, than to duplicate the work of 
> > other SDOs or forums.
> > 
> > ENUM (of whatever flavor) helps to discover the 
> corresponding domain.
> > A lookup based on domain helps to discover the federation.
> > A lookup based on the federation helps to discover transit 
> SPs serving 
> > those federations.
> 
> IMHO this is a very complex problem. I simply wonder if this 
> is better done out of band as part of classical bi-lateral 
> relationships between providers but accessed locally as part 
> of some cached data base.
> 
> I simply refuse to believe that any advertisement of 
> membership in a federation or ability to route against a 
> specific number range (s) will not be backed up by written contracts.
> 
> If I'm a SP I would never accept traffic unless A. I had 
> positive and authenticated knowledge of where the traffic is 
> coming from and B. a signed commercial agreement on how that 
> traffic is to be handled.
> 
> There is no transit or peering agreement on the internet now 
> that is not backed up by commercial agreements. I see no 
> reason that is going to change.
> 
> But I could be wrong.
> 
> > 
> > The above can be combined into a single lookup or done separately.
> 
> 
> 
> > 
> > Mike
> > 
> > 
> > > -----Original Message-----
> > > From: Richard Shockey [mailto:[email-masked]]
> > > Sent: Tuesday, September 19, 2006 2:58 PM
> > > To: 'Stastny Richard'; 'Andrew Newton'
> > > Cc: [email-masked]
> > > Subject: RE: [Speermint] Dear Collegues .. a modest proposal.
> > >
> > > Which are only 99.998 percent of the transactions right now.
> > >
> > >
> > >
> > > Yes SPEERMINT should define something more than an NNI 
> which is why 
> > > I suggest this be done in a series of profiles. Deal with 
> the SIMPLE 
> > > problems first then proceed in measured steps.  This is the IETF.
> > >
> > >
> > >
> > > Ending world (or SP)  hunger is not an immediate, though laudable 
> > > goal.
> > >
> > >
> > >
> > >   _____
> > >
> > > From: Stastny Richard [mailto:[email-masked]]
> > > Sent: Tuesday, September 19, 2006 2:26 PM
> > > To: [email-masked]; Andrew Newton
> > > Cc: [email-masked]
> > > Subject: Re: [Speermint] Dear Collegues .. a modest proposal.
> > >
> > >
> > >
> > > 1. SNIP assumes that you are starting with an e:164 number
> > >
> > > 2. Speermint should do more than just defining an NNI
> > >
> > >
> > >
> > > Richard
> > >
> > >
> > >
> > >   _____
> > >
> > > Von: Richard Shockey [mailto:[email-masked]]
> > > Gesendet: Di 19.09.2006 20:16
> > > An: 'Andrew Newton'; Stastny Richard
> > > Cc: 'Brian Rosen'; 'Klaus Darilion'; [email-masked]
> > > Betreff: RE: [Speermint] Dear Collegues .. a modest proposal.
> > >
> > > Right ... well you maybe could use infrastructure enum to 
> discover 
> > > the federation ... then a private tree to find the 
> routing data but 
> > > I have serious doubts about that which is why I tend assume that 
> > > some form of first iteration SNIP probably deals with federation 
> > > discovery out of band.  I could be proven wrong however.  
> Again the 
> > > idea of SNIP is SIMPLE.
> > >
> > >
> > >
> > >
> > >
> > >   _____
> > >
> > > From: Andrew Newton [mailto:[email-masked]]
> > > Sent: Tuesday, September 19, 2006 1:57 PM
> > > To: Stastny Richard
> > > Cc: Brian Rosen; Klaus Darilion; [email-masked]; 
> > > [email-masked]
> > > Subject: Re: [Speermint] Dear Collegues .. a modest proposal.
> > >
> > >
> > >
> > >
> > >
> > > On Sep 19, 2006, at 1:52 PM, Stastny Richard wrote:
> > >
> > >
> > >
> > > Use draft-stastny-enum-ern-00
> > >
> > >
> > >
> > > This assumes public ENUM. I think the point is that most 
> federations 
> > > use private ENUM.
> > >
> > >
> > >
> > > -andy
> > >
> > >
> > >
> > >
> 

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

---

From: Michael Haberler <[email-masked]>
Date: Fri, 22 Sep 2006 01:07:19 +0200

Michael,
inline -

> get a certificate, provision your proxies, and go.
That's too simple. You can't do that if you try to make peering into a
service a.k.a. revenue stream, even though it's just a decision like in
BGP. So much VSP autonomy breaks some business assumptions.

But that of course depends on where you come from.
> That seems very manual and very complex in the number of lawyers you
Well, if the assumption is that all the conceptual model of SPEERMINT
needs to support is the status quo, then this legal haystack is already
in place and leftover peering policy may go into an ENUM view. Plus,
perpetuating the contract model creates deja vous with operations old
hands since it's business as usual.

Nevermind it's a colossal opex driver, and a lousy design desicion in
the first place: cramming peering policy into the number layer is a
surefire way to perpetuate the need of E.164 addressing long after the
world has moved on.

Important problem, wrong primary key for the solution - bingo: instant
legacy creation.

But I might be wrong - the other world view where things work out under
these assumptions is: the single "interesting" e164 resolution namespace
and the single interesting federation happen to be *one* same thing. As
this fellow on VON said the other week - "there can be only one".

Strikes me as "one way in, no way out" - if I were a VSP (carrier or
enterprise) that wouldnt be exactly my first choice - lots of eggs in a
single nest. Again - depends where you come from.

-Michael