Subject: [Speermint] [wg-business] Possible Interim Meeting in September?

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 11 Jul 2006 09:46:01 -0400

There has been some discussion about holding an interim meeting before
the next IETF.  We'll work on a proposed agenda later, but the general
idea was to accelerate some of our technical discussions and
deliverables work in a smaller, highly-focused, f2f environment.  We're
thinking that August should be avoided due to vacations in Europe, as
well as the first week or so of September due to returning from said
vacations.
 
So, I'd like to suggest the possibility of September 18 - 20 (meeting
would likely be two days).  The location would likely be in the US (the
next interim would presumably move to Europe or Canada to accomodate all
participants). 
 
Is anyone aware of potential meeting conflicts with these dates?  If so,
what are they? 
 
Thanks
Jason
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Jul 2006 18:40:10 +0200

In draft-ietf-speermint-terminology-00 in section 2 Speermint context, the last sentence
on page 3 states the following:
 
"Finally, note that the subsequent
   lookup steps described in RFC 3263 [RFC3263] used to find the next-
   hop SIP server from this URI are outside the scope of SPEERMINT."
 
OTOH, in the milestones list presented yesterday it is stated:
 
"Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified
by RFC 3263."
 
So we are doing an I-D explaing out of scope issues?

IMO the sentence has to be deleted.
 
This also raises some issues with Figure 1:
 
Figure 1 on top of page 4 defines the upper boundary of the speermint
scope against ENUM, but not the lower boundary

According to the above sentence it must be just below SIP URI
and above Service location lookup
 
IMHO the boundary is sharp below session establishment
(keeping in mind that you need out-of-scope actions like A and AAAA
IP Address and Mac-address first before you establish a session)
 
There is also an issue with 
<--- Service location (lookup of SRV in DNS)
 
we either take this a e.g Service Location
or
we elaborate more
 
Federation detection and policy lookup
Service Location (NAPTR and SRV)
etc
 
And one other nit:
 
in section 3.4 Network

insead of:
"For purposes of this document and the SPEERMINT and ENUM Working
   Groups, a network is defined to be the set of SIP servers and end-
   users (customers) that are controlled by a single administrative
   domain.  The network may also contain end-users who are located on
   the PSTN."

it should be made more clearly:
 
For purposes of this document and the SPEERMINT and ENUM Working
   Groups, a network is defined to be the set of SIP servers and end-
   users (customers) that are controlled by a single administrative
   domain and can be reached via IP-peering.  The network may also contain end-users 
  who are located on the PSTN, as long as they are also reachable via IP-peering.

regards
 
Richard

---

From: David Meyer <[email-masked]>
Date: Wed, 12 Jul 2006 09:59:34 -0700

Richard,

	Thanks for the comments. I'll include in the next update.

	--dm

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 00:55:26 +0200

Proposed wording for Peering
 
4.2.  Layer 5 Peering or Session Peering
   Layer 5 peering or Session Peering refers to interconnection of 
   two (VoIP) service providers for the purposes of routing real-time
   (or quasi-real time) secure call signaling between their respective 
   customers using SIP methods.  Such interconnection may be direct or 
   indirect. 
   Media streams associated with this signaling (if any) are not 
   constrained to follow the same set of paths.
4.3.  Direct Peering
   Direct Peering covers all cases where the two SPs interconnect without
   using an intervening L5 network. Both SP must have a trust relationship
   established (e.g. know they belong to the same federation (see below))
   before opening up a secure communication path on L5.
4.4   Indirect or Transit Peering
   Indirect or transit peering is the establishment of a secure signalling
   path via one (or more) referral or transit network(s). In this case it is
   required that a trust relationship is established between the originating
   SP and the transit network on one side and the transit network and the 
   termination network on the other side before opening up a secure 
   communication path on L5.
 
In addition,
I suggest to delete the old section 4.4. on private peering because
it is confusing and and out of scope anyway

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 12 Jul 2006 22:32:40 -0400

Hello Richard,

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Wednesday, July 12, 2006 3:55 PM
> To: David Meyer
> Cc: [email-masked]
> Subject: [Speermint] Terminology draft - Peering
> 
>    Direct Peering covers all cases where the two SPs 
[[Reinaldo]] 

SPs or VSPs?

interconnect without
>    established (e.g. know they belong to the same federation (see
below)
>    path via one (or more) referral or transit network(s). In this case
it
> is
[[Reinaldo]] 

Is this transit network just providing IP transit or it is actually a
Layer 5 transit network? I think the requirements are different in the
two scenarios.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 06:17:49 +0200

>SPs or VSPs?

Both 

>Layer 5 transit network? I think the requirements are different in the

L5
 
Richard

________________________________

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Do 13.07.2006 04:32
An: Stastny Richard; David Meyer
Cc: [email-masked]
Betreff: RE: [Speermint] Terminology draft - Peering

Hello Richard,

[[Reinaldo]]

SPs or VSPs?

interconnect without
below)
it
[[Reinaldo]]

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Jul 2006 09:49:15 -0400

I thought at some point we kind of agreed to get rid of the transit
term, wasn't it?

Anyway, in the following case

VSPA <-----> VSP B <-----> VSP C

Is VSP B providing layer 5 "transit" or we can just say it peers with A
and B? 

VSP A might not even know that is talking with VSP C through VSP B. For
all purposes, VSP B is VSP C...

Thanks,

Reinaldo

> Sent: Wednesday, July 12, 2006 9:18 PM
> To: Reinaldo Penno; David Meyer
> Cc: [email-masked]
> Subject: Re: [Speermint] Terminology draft - Peering
> 
> >[[Reinaldo]]
> 
> >SPs or VSPs?
> 
> Both
> 
> >    SP and the transit network on one side and the transit network
and
> the

---

From: "Uzelac, Adam" <[email-masked]>
Date: Thu, 13 Jul 2006 10:06:16 -0400

A couple thoughts.

The concept of the "transit L5 network" has to be acknowledged if you
subscribe to the notion that the a complete mesh of bi-lateral
interconnections of VoIP networks is unrealistic.  I understand the
point in the example below that VSP-A might not even know that it's
communicating with VSP-C via VSP-B, but that doesn't mean that it's not
happening?!?!  

Also, David Schwartz also presented a plausible (IMO) use case that
pointed out intentionally introducing a L5 intermediary (transit) for
trust purposes.  The point I am trying to make is this - it's gonna be
there, why not acknowledge it?!?!

Regards,

Adam

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 9:49 AM
To: Stastny Richard; David Meyer
Cc: [email-masked]
Subject: RE: [Speermint] Terminology draft - Peering

Thanks,

Reinaldo

and

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Thu, 13 Jul 2006 10:24:24 -0400

Then the question to ask is whether the two sub cases are functionally
different:

A. VSPA knows the ultimate destination is VSPC but is routing through
VSPB at L5
B. As far as VSPA knows VSPC is the terminating VSP

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 9:49 AM
To: Stastny Richard; David Meyer
Cc: [email-masked]
Subject: RE: [Speermint] Terminology draft - Peering

Thanks,

Reinaldo

and

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Jul 2006 10:27:21 -0400

It is going to be there, the issue is how to phrase it in the
terminology draft. 

As to your point below, VSP A might actually care. If VSP B is not
actually VSP C, he might want to see some trust transitivity from C to B
to him (A). If he does _not_ care (OR cannot perceive) and VSP B appears
for all purposes as VSP C, we fall back into the "direct peering"
scenario where maybe no security/trust is needed? Is it clear now?

Thanks,

Reinaldo

> From: Uzelac, Adam [mailto:[email-masked]]
> Sent: Thursday, July 13, 2006 7:06 AM
> To: Reinaldo Penno; Stastny Richard; David Meyer
> Cc: [email-masked]
> > >    customers using SIP methods.  Such interconnection may be
direct

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 17:05:59 +0200

If VSP B is giving A all what he needs, does he need to care how 
VSP B and C are doing this?
 
Richard

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Do 13.07.2006 16:27
An: Uzelac, Adam; Stastny Richard; David Meyer
Cc: [email-masked]
Betreff: RE: [Speermint] Terminology draft - Peering

Thanks,

Reinaldo

direct

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 17:01:47 +0200

and B?

>all purposes, VSP B is VSP C...
 
VSP A must know that the call terminates at VSP C, because he basically has
an AoR for VSP C.
 
He looks up VSP C and sees he cannot peer with VSP C directly, but gets
the pointer to VSP B (somehow)
 
Now he peers with VSP B and VSP B peers with VSP C
 
Richard

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Do 13.07.2006 15:49
An: Stastny Richard; David Meyer
Cc: [email-masked]
Betreff: RE: [Speermint] Terminology draft - Peering

Thanks,

Reinaldo

and

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Jul 2006 11:17:28 -0400

Sure, isn't that the same thing in real life? If I'm paying you for a
service, do I care if you are doing it in a legitimate way or not?

If to perform this service you are involving somebody else, should I
care if that somebody else is legitimate and not some front end money
laundry shops?

Thanks,

Reinaldo

> Sent: Thursday, July 13, 2006 8:06 AM
> To: Reinaldo Penno; Uzelac, Adam; David Meyer
> Cc: [email-masked]
> > Is VSP B providing layer 5 "transit" or we can just say it peers
with
> A
> > > >Is this transit network just providing IP transit or it is
actually
> a
> >
> > > >Layer 5 transit network? I think the requirements are different
in
> > > >    path via one (or more) referral or transit network(s). In
this
> > case
> > > Is this transit network just providing IP transit or it is
actually
> a

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 17:14:52 +0200

I do not really understand you anonynizing concept in Speermint
 
I may look up an E.164 number and interconnect without knowing with whom

But in speermint VSP A alway gets an AoR indicating a domain name od VSP C

How can you now anonymize it?
 
Richard

Von: David Schwartz [mailto:[email-masked]]
Gesendet: Do 13.07.2006 17:01
An: Pfautz, Penn L, GBLAM; Reinaldo Penno; Stastny Richard; David Meyer
Cc: [email-masked]
Betreff: RE: [Speermint] Terminology draft - Peering

Hi Penn.

My point was that there are two cases I can think of.

1.  1@A --- B --- 2@C 

    In this case when user 1 wants to call user 2. If this is a federation where B is anonymizing all data than A would ask B and B would return 2@B implying that communication with 2 needs to go via B and 1 can have no visibility into who "owns" 2. My only point is that in this case B is not a transit network, rather he is a "super" entity that for all practical purposes "owns" 2 vis-à-vis 1.

2. 1@A ---B --- 2@C

    In this case 1 has visibility to the fact that 2 is "owned" by C. The case I am trying to cover here is where 2 wants 1 to signal C via B. This may be due to security or interoperability reasons. This is the case that was referred to as "hosted policy".

Point is there is thus no need for transit definition.

Cheers,

David

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]]
Sent: Thursday, July 13, 2006 9:49 AM
To: Stastny Richard; David Meyer
Cc: [email-masked]
Subject: RE: [Speermint] Terminology draft - Peering

Thanks,

Reinaldo

and

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Jul 2006 11:19:31 -0400

Richard,

I think you are assuming the domain part of AORs maps to the VSP that
actually host his VoIP service and this relationship is not well
defined.

I can be in VSP A and make a DNS query for [email-masked] and
get as a result a proxy server at VSP B. Now, some-company.com is
actually served by VSP C, but the DNS returns VSP B because that's where
you need to send your signaling to get to some-company.com

In this case, VSP A has no way of knowing that some-company.com is
actually "hosted" (for a lack of a better term) in VSP C. 

A VSP can serve many domains. Just because the VSP is called vspb.com
does not mean it cannot serve, e.g., supervoip.com, voip'r'us.com,
voipathome.com, etc, etc

Thanks,

Reinaldo

> Sent: Thursday, July 13, 2006 8:02 AM
> VSP A must know that the call terminates at VSP C, because he
basically
> has
direct

---

From: "David Schwartz" <[email-masked]>
Date: Thu, 13 Jul 2006 18:01:28 +0300

Hi Penn.

1.  1@A --- B --- 2@C  

2. 1@A ---B --- 2@C

Cheers,

David

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 9:49 AM
To: Stastny Richard; David Meyer
Cc: [email-masked]
Subject: RE: [Speermint] Terminology draft - Peering

Thanks,

Reinaldo

and

---

From: Andrew Newton <[email-masked]>
Date: Thu, 13 Jul 2006 11:38:18 -0400

> VSP B and C are doing this?

Yes.  We do care if any transcoding occurs and we do care if the 
termination is on the PSTN.

-andy

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 17:39:56 +0200

You are still in the signalling path
 
Regarding transcoding, we are talking here only about L5
 
Richard

Von: Andrew Newton [mailto:[email-masked]]
Gesendet: Do 13.07.2006 17:38
An: Stastny Richard
Cc: Reinaldo Penno; Uzelac, Adam; David Meyer; [email-masked]
Betreff: Re: [Speermint] Terminology draft - Peering

-andy

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Jul 2006 11:46:54 -0400

So, what I'm trying to say is that the domain part of the AOR does not
tell you which VSP actually hosts it. You can have vanity domains,
company domains, etc, etc. Just like you can have a domain at your home
but use your providers SMTP to relay email to you.

Okay, let's put some call flows around it putting the federation thing
aside for a moment. So, adapted from RFC 3263...example.com is actually
at vspc.com

As an example, consider a client that wishes to resolve
   sip:[email-masked].  The client performs a NAPTR query for that
   domain, and the following NAPTR records are returned:

   ;          order pref flags service      regexp  replacement
      IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.vspb.com.
      IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.vspb.com
      IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.vspb.com.

   This indicates that the server supports TLS over TCP, TCP, and UDP,
   in that order of preference.  Since the client supports TCP and UDP,
   TCP will be used, targeted to a host determined by an SRV lookup of
   _sip._tcp.vspb.com.  That lookup would return:

   ;;          Priority Weight Port   Target
       IN SRV  0        1      5060   server1.vspb.com
       IN SRV  0        2      5060   server2.vspb.com

When the INVITE gets to server1.vspb.com it would eventually send to
server1.vspc.com because that's the proxy/VSP that provides VoIP
services to example.com. I might begetting this wrong, is there
something wrong with this example?

Thanks,

Reinaldo

> Sent: Thursday, July 13, 2006 8:28 AM
> I think we are getting ahead of ourselves here
> 
> I always have to start with the AoR and look up the domain there
> 
> Here I may find a NAPTR indicating the federation (and eventually a
> policy)
> and I alsi find there the 3263 NAPTR and SRV, pointing to the servers
> where
> I should send the invites to
> 
> If there is an indirect peering, I may be diverted to (the domain of)
VSP
> B,
> where I also may finally look up the 3263 SRV to find the ingress
points
> to send the invite too. How VSP B is no going further to reach B is
none
> of my business
> Gesendet: Do 13.07.2006 17:19
with
with
actually
in
this
actually

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 17:27:30 +0200

Here I may find a NAPTR indicating the federation (and eventually a policy)
and I alsi find there the 3263 NAPTR and SRV, pointing to the servers where
I should send the invites to
 
If there is an indirect peering, I may be diverted to (the domain of) VSP B,
where I also may finally look up the 3263 SRV to find the ingress points
to send the invite too. How VSP B is no going further to reach B is none of my business
 
Richard

Richard,

Thanks,

Reinaldo

basically
direct

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 13 Jul 2006 12:38:09 -0400

There are many operational reasons...

When VSP C is provisioning its customers, it points to VSP B because B
can actually check certificate revocation, or can prevent some SIP DDoS
attacks, or in some parts of the country C has no presence, so it uses
VSP B to route it back to him, etc, etc

Regards,

Reinaldo

> Sent: Thursday, July 13, 2006 9:16 AM
> Simply: why is example.com entering
> server1.vspb.com into the NAPTRs and
> not server1.vspc.com?
> 
> How is vspb.com coming into play at all?
> 
> If you do this, everything is ok
> 
> Richard
> 
> 
> 
> Gesendet: Do 13.07.2006 17:46
> > > >VSP A might not even know that is talking with VSP C through VSP
B.
> > For
> > > VSP A might not even know that is talking with VSP C through VSP
B.
> > For
> > > > >    Layer 5 peering or Session Peering refers to
interconnection
> of
> > > > >    Indirect or transit peering is the establishment of a
secure
> > > > signalling
> > > > >    required that a trust relationship is established between
the
> > > > > originating
in

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 19:41:01 +0200

I do not think there is any difference
 
example.com (it belongs to a federation vspb.com is also a part of)
 
the direct peering takes place between vspa.com and vspb.com
 
if vspb.com is proxying the request then to vspc.com, this does not matter
anymore. This is similar if you send a call to an I-CSCF or SBC and this element is  
proxying the call further to an S-CSCSF.
 
So this is still direct peering between A and B
 
Richard

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Do 13.07.2006 18:38
An: Stastny Richard; David Meyer
Cc: [email-masked]
Betreff: RE: [Speermint] Terminology draft - Peering

Regards,

Reinaldo

B.
B.
interconnection
secure
the
in

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 13 Jul 2006 18:15:49 +0200

Richard

Thanks,

Reinaldo

VSP
points
none
with
with
actually
in
this
actually

---

From: Gaurav Kulshreshtha <[email-masked]>
Date: Fri, 14 Jul 2006 10:03:30 -0400

Richard,
Agree we are talking in this thread about L5 but I would argue that in
our interconnect discussions we have to keep an eye towards delay
elements along the media path  e.g. If transcoders at VSP D <--> VSP C
introduce 70 ms delay and then VSP C <->VSP B introduce another 30 ms
delay. We are left with only 50 ms of transit delay time for rest of the
voice path according to ITU specs on Telephony.

Gaurav

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 14 Jul 2006 16:41:21 +0200

So basically satellite telephony is illegal ;-)
 
Serious:
 
There is two (3) problems with this:
 
1. We are talking here about the determination if you can peer or not
i.e. selecting the VSP which may either host the subscriber or have
a path to the VSP who is. The question is if you are allowed to establish 
a secure communication path to start signalling and negotiation without
being rejected in the first place. I cannot imagine you put all information
you negotiate with SIP methods in advance in the DNS as policy elements
 
2. Keeping in mind the end-to-end principle, I have no idea how any
VSP in the path may know about the media delays involved on the
media path. This is only valid for the case where the media path follows
the signalling path and here it is difficult.
 
3. I also cannot imaging that a network provider is announcing publicy 
his worst case delay ;-)
 
Richard

Von: Gaurav Kulshreshtha [mailto:[email-masked]]
Gesendet: Fr 14.07.2006 16:03
An: Stastny Richard
Cc: Andrew Newton; [email-masked]
Betreff: Re: [Speermint] Terminology draft - Peering

Richard,

Gaurav

---

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 14 Jul 2006 11:02:26 -0400

Gaurav,

I agree with Richard that the focus should be on L5. (call signaling as
I read it - at least at this time)  As I have noted on this list before,
I believe that transcoding is evil, and questionable if required in
certain use-cases.  Ultimately/ideally, bearer-path should be
point-to-point and capabilities negotiated by those endpoints directly.
I know all too well there are situations that transcoding is required,
and it's important that both parties know it's occurring.  Unfortunately
this notification doesn't always happen.  

On a bit of a side-note, currently it is unclear the extent to which
bearer/media should be addressed within the SPEERMINT scope.  I plan on
supplying Jean-Francois feedback on that section [3.3] of the
requirements draft - and I encourage others to do the same to fully vet
out the requirements.

-AU

-----Original Message-----
From: Gaurav Kulshreshtha [mailto:[email-masked]] 
Sent: Friday, July 14, 2006 10:04 AM
To: Stastny Richard
Cc: [email-masked]
Subject: Re: [Speermint] Terminology draft - Peering

Richard,

Gaurav

Stastny Richard wrote:
>> If VSP B is giving A all what he needs, does he need to care how VSP 
>> B and C are doing this?
>>     
>

---

From: Gaurav Kulshreshtha <[email-masked]>
Date: Fri, 14 Jul 2006 17:28:38 -0400

Uzelac, Adam wrote:
> certain use-cases.  
My point is that we should end up with really quality links after all
the L5 mechanism are done.
At the end of the day its the media we are trying to transport and this
media has certain requirements on
end-to-end delay.
> Ultimately/ideally, bearer-path should be
Ideally is the operative word. This is more than likely not going to be
the case depending upon business model of the
peering federation administrator.
> requirements draft - and I encourage others to do the same to fully vet
Will do.

---

From: Gaurav Kulshreshtha <[email-masked]>
Date: Fri, 14 Jul 2006 17:34:57 -0400

> So basically satellite telephony is illegal ;-)
No illegal but definitely a pain in neck. If you have ever used it for
personal communication.

> the signalling path and here it is difficult.
In this light I think the work initiated in the
draft-malas-performance-metrics-03.txt
<http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-03.txt>
is of significance to this group.__
<http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-03.txt>
<http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-03.txt>

> 3. I also cannot imaging that a network provider is announcing publicy 
It won't even if they have the best of the intentions.