From speermint-bounces@ietf.org Mon Nov 05 09:15:14 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ip2jQ-0006b9-Aq; Mon, 05 Nov 2007 09:15:12 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2jO-0006Wx-P9
	for speermint@ietf.org; Mon, 05 Nov 2007 09:15:10 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip2jN-0007Qc-NX
	for speermint@ietf.org; Mon, 05 Nov 2007 09:15:10 -0500
Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian))
	id 1Ip2jJ-0001FG-00; Mon, 05 Nov 2007 15:15:05 +0100
Date: Mon, 5 Nov 2007 15:15:05 +0100
From: Otmar Lendl <lendl@nic.at>
To: Daryl Malas <daryl@level3.net>
Subject: Re: [Speermint] [wg-business] WGLC
	fordraft-ietf-speermint-terminology-12
Message-ID: <20071105141505.GA4606@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>,
	Daryl Malas <daryl@level3.net>, speermint@ietf.org
References: <45AEC6EF95942140888406588E1A6602026BA4CC@PACDCEXCMB04.cable.comcast.com>
	<45AEC6EF95942140888406588E1A660202A031F5@PACDCEXCMB04.cable.comcast.com>
	<20070918154835.GA16188@nic.at>
	<1193353696.1297.368.camel@montag.eng.level3.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1193353696.1297.368.camel@montag.eng.level3.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

On 2007/10/26 01:10, Daryl Malas <daryl@level3.net> wrote:
> Otmar, I apologize for taking so long to respond to your comments.

No need.

> (FYI...I'm updating the draft right now.)

I've just had a look, looks a lot better.  I'll send a review of this
version in a separate mail.

> > >                | 
> > >                | <--- ENUM lookup of NAPTR in Domain Name System (DNS) 
> > >                | 
> > >                | 
> > >                | ENUM Working Group Scope 
> > >           =====+==================================================== 
> > >                | SPEERMINT Working Group Scope 
> > >           Lookup 
> > >           Discovery <--- Session Establishment Data (SED)                    
> > >           SIP URI 
> > 
> > According to the SED definition below, SED is definitly not
> > the input into the speermint WG scope; instead I see it as
> > the result of this step:
> > 
> I disagree with some of this.  Although, I could agree the "SIP URI" is
> not part of the scope of SPEERMINT, it is derived of information
> attained through steps defined in SPEERMINT.
> 
> Lookup = Look-up Function
> Discovery = Location Function
> SIP URI = Derived information from these prior to functions

I think the main source of our disagreement is the overloaded nature
of the term "SIP URI". In the context of speermint, IMHO we encounter
at least two very different incarnations of that term. 

a) SIP Address of Record (AoR)

That's the SIP aequivalent of an email address. That's the thing you
put on your business cards. Examples are: sip:lendl@nic.at, 
sip:20312349876@bigteco.com, sip:joe.doe@big-enterprise.com

b) Context dependent SIP URI

If a federation runs a private ENUM within a private peering
network, then the URIs stored within that ENUM might look like
sip:20312349876@sbc-1.carriername.<privateroot> which is only resolvable
to an IP address in the private DNS inside that peering network.

In extreme cases this could just as well be a URI as used in the
Contact header: sip:username@10.10.0.42

-------------

What does this mean for speermint?

If we do number-based dialing/routing, then the ENUM step can happen
inside a federation (via that federation's Lookup function) and yield
a SIP URI which explicitly contains the carrier's border element for
calls inside that federation. (resolving that into an IP address /
transport / portnumber is then straight-forward using the RFC3263 
algorithm in either private or public DNS trees).

But what happens when we don't do number-based dialing/routing?
In that case we somehow need to map the AoR to the next SIP hop.
The Lookup function thus doesn't take a E.164 number as the input
(as it was above), but needs to operate on a SIP AoR. 

What are the options? 

* One could use pure RFC3263 in the public DNS. This gives the same
ingress element for all askers and thus does not support control on
who actually is peering.

* RFC 3263 in a federation-internal DNS tree. That's fine for AoR which
use provider-owned domains. It won't scale for customer-owned domains
for which carriers just host the SIP service.

* Something completely different.

-------------

What does this mean for this document?

I think we have to differentiate between the SIP AoR which can be the 
input in the whole speermint scenario (when doing URI-based calling)
and any other SIP URI addressing a specific border element inside a
federation.

We might bring back the term Call Addressing Data (CAD) that we had
in some earlier revision of the draft. With that we can be clearer:

CAD: Either a E.164 phone number or a SIP AoR (potentially using a
customer-owned domain). This is the input into the overall call routing
algorithm.

SED: A SIP URI which is specific to a federation and which directly
encodes the next-hop information.

The task for speermint can thus be defined as "Devise an algorithm how
to derive SED from CAD".

> > >3.4. Call Routing 
> > >
> > >   Call routing is the set of processes, rules, and SED used to route a 
> > >   call to its proper (SIP) destination.  More generally, call routing 
> > >   can be thought of as the set of processes, rules and SED which are 
> > >   used to route a real-time session to its termination point. 
> > 
> > Please strike SED from this paragraph.
> As I described earlier, I think the Look-up and Location functions are
> part of deriving SED for peering.

I see the SED as the result of this processing.

/ol
-- 
/ Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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



From speermint-bounces@ietf.org Mon Nov 05 11:12:48 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ip4ZD-0001tz-11; Mon, 05 Nov 2007 11:12:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip4ZC-0001tt-7l
	for speermint@ietf.org; Mon, 05 Nov 2007 11:12:46 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip4ZA-000298-KS
	for speermint@ietf.org; Mon, 05 Nov 2007 11:12:46 -0500
Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian))
	id 1Ip4Z6-0001GH-00; Mon, 05 Nov 2007 17:12:40 +0100
Date: Mon, 5 Nov 2007 17:12:40 +0100
From: Otmar Lendl <lendl@nic.at>
To: Daryl Malas <daryl@level3.net>
Subject: Re: [Speermint] Updated: draft-ietf-speermint-terminology-13
Message-ID: <20071105161240.GB4606@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>,
	Daryl Malas <daryl@level3.net>, speermint@ietf.org
References: <1193872413.1297.374.camel@montag.eng.level3.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1193872413.1297.374.camel@montag.eng.level3.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

On 2007/11/01 00:11, Daryl Malas <daryl@level3.net> wrote:
> 
> This revision updates the WGLC of rev 12 discussion points.  Please
> review the draft and provide feedback.

As promised, here is my review. IMHO we're getting there.

> 2.  SPEERMINT Context 
> 
>    Figure 1 depicts the general session peering context (Not in 
>    chronological order). Note that vertical axis in this figure 
>    describes the layering of identifiers, while the horizontal lines 
>    indicate working group scope. While the SPEERMINT working group is 
>    not limited (or coupled in any way) to the use of E.164 numbers, in 
>    the case shown here an E.164 number [5] is used as a key in an E.164 
>    to Uniform Resource Identifier (URI) mapping (ENUM [4]). The result 
>    of this step (which involves looking up Naming Authority Pointer 
>    (NAPTR) records in the DNS) is a SIP URI, on which the subsequent 
>    call routing is based. Note that the call routing step does not 
>    depend on the presence of an E.164 number. Indeed, the resulting SIP 
>    URI may no longer even contain any numbers of any type. In 
>    particular, the SIP URI can be advertised in various other ways, such 
>    as on a web page. 

Good.

>    Note that in Figure 1, Session Establishment Data (SED), is the data 
>    used to route a call to the called domain's ingress point (see 
>    Section 3.3 for additional detail). 

This is a bit ambiguous: is SED the input into the routing algorithm?
is SED the result of the routing algorithm? Some interim step?

>    As illustrated in Figure 1, the ENUM Working Group is primarily 
>    concerned with the acquisition of SED while the SPEERMINT Working 
>    Group is focused on the use of such SED in routing session signaling 
>    requests. Importantly, the SED can be derived from ENUM (i.e., an 
>    E.164 DNS entry) or via any other mechanism available to the user. 

As mentioned in the other mail: the user should never enter something
which is not a neutral Address-of-Records SIP URI. I hesitate to
call that SED. 

> 3.3. Session Establishment Data 
> 
>    Session Establishment Data, or SED, is the data used to route a call 
>    to the called domain's ingress point. A domain's ingress point can be 

Same as above: "route" is a bit ambiguous. What about:

|    Session Establishment Data, or SED, is the data needed to hand the
|    call to the next hop's ingress point. In the simplest case, this
|    information is derived from a SIP AoR using NAPTR/SRV/A record
|    lookups according to RFC 3263.

> 3.9. SIP Service Provider 
> 
>    A SIP Service Provider (or SSP) is an entity that provides 
>    application services utilizing SIP signaling to its customers. 

Stupid question: Do we actually care whether the SSP talks SIP with his
customers? We already dumped all the graphs depicting the internal setup
of a SSP as they are irrelevant to the peering question.

So, if any incumbent telco (DT, Qwest, TI, Telia, ...) decides to
use SIP for interconnection, is the fact that the customers themselves
are attached using POTS or ISDN lines an obstacle to the use of
speermint methods (whatever that may be)?

> 4.1. Layer 3 Peering 
> 
>    Layer 3 peering refers to interconnection of two service providers' 
>    networks for the purposes of exchanging IP packets which destined for 
>    one (or both) of the peer's networks. Layer 3 peering is generally 
>    agnostic to the IP payload, and is frequently achieved using a 
>    routing protocol such as Border Gateway Protocol (BGP) [6] to 
>    exchange the required routing information. 
> 
>    An alternate, perhaps more operational definition of layer 3 peering 
>    is that two peers exchange only customer routes, and hence any 
>    traffic between peers terminates on the peer's network or the peer's 
>    customer's network. 
> 
> 4.2. Layer 5 Peering 
> 
>    Layer 5 (Session) peering refers to interconnection of two service 
>    providers for the purposes of routing real-time (or quasi-real time) 
>    call signaling between their respective customers using SIP methods.  

This is a good description.

(This begs the question that given the similarities, why we need a
routing protocol on layer 3 and but not on layer 5. This draft does not
need to answer that, it is just terminology.)

> 4.2.2. Indirect Peering 
> 
>    Indirect, or transit, peering refers to the establishment of either a 
>    signaling and media path or signaling path alone via one (or more) 
>    referral or transit network(s). 

This is misleading. When I read this paragraph, I conclude that the
originating and terminating SSPs are peering (indirectly). Given your
last mails, this is not what you intend to say.

So what about:

|    A peering whose signalling (and optionally a media) path is also
|    used to carry calls originating or terminating not withing one
|    of the peering SSPs is called an indirect (transit) peering.
|    Any SSP in such a setup which is neither the originating nor
|    the terminating SSP is called a "transit network".

That's all a bit awkward.

Perhaps we need to introduce the concept of "reachability", i.e.
"is there a path via transit networks between SSP-O and SSP-T?"

(In order to keep the terminology in sync with Layer3 stuff, we
should not talk about primarily about "peering", but about
"interconnection". A "peering" is just a special case where the
set of announced routes is limited.)

> 4.3.1. Look-Up Function 
> 
>    The Look-Up Function (LUF) provides a mechanism for querying an 
>    internal and/or external database, which maintains a list of peered 
>    host domains. 

Could you be a bit more specific here? What exactly is the input
into the LUF, and what does the LUF return?

> 
> 4.3.2. Location Function 
> 
>    The Location Function (LF) develops SED by discovering the Signaling 
>    Function (SF), and SF's reachable host (IP Address and port). 

Again: what is the input? Output? Can you give examples?

That's it.

/ol
-- 
/ Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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



From speermint-bounces@ietf.org Thu Nov 08 13:30:54 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqC9U-0004jZ-IG; Thu, 08 Nov 2007 13:30:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqC9T-0004ig-Tf
	for speermint@ietf.org; Thu, 08 Nov 2007 13:30:51 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqC9Q-0007BG-Mh
	for speermint@ietf.org; Thu, 08 Nov 2007 13:30:51 -0500
Received: from ([10.52.116.31])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH7.38974308;
	Thu, 08 Nov 2007 13:30:35 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PAOAKEXCSMTP02.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:30:34 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Updated: draft-ietf-speermint-terminology-13
Date: Thu, 8 Nov 2007 13:30:34 -0500
Message-ID: <45AEC6EF95942140888406588E1A66020307D6BD@PACDCEXCMB04.cable.comcast.com>
In-Reply-To: <1193872413.1297.374.camel@montag.eng.level3.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] Updated: draft-ietf-speermint-terminology-13
Thread-Index: AcgcE9qcAyRZS12FQEeNr5HFhWH/JQGIWaCA
References: <1193872413.1297.374.camel@montag.eng.level3.com>
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Daryl Malas" <daryl@level3.net>,
	<speermint@ietf.org>
X-OriginalArrivalTime: 08 Nov 2007 18:30:34.0857 (UTC)
	FILETIME=[73A08590:01C82235]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Please upload this ID to the IETF site asap (today/tomorrow).  We should
always submit to the I-D editor at the same time that we post to some
private site for review for WG docs.

As soon as it is announced, we'll do a quick 2nd WGLC on -13.

Thanks
Jason=20

> -----Original Message-----
> From: Daryl Malas [mailto:daryl@level3.net]=20
> Sent: Wednesday, October 31, 2007 7:14 PM
> To: speermint@ietf.org
> Subject: [Speermint] Updated: draft-ietf-speermint-terminology-13
>=20
> In order to avoid several revisions prior to Vancouver, I=20
> have place an updated draft here:
> http://www.malas.net-a.googlepages.com/draft-ietf-speermint-te
> rminology-13.txt
>=20
> This revision updates the WGLC of rev 12 discussion points. =20
> Please review the draft and provide feedback.
>=20
> Thanks...
>=20
> Daryl
>=20
>=20
>=20
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

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



From speermint-bounces@ietf.org Thu Nov 08 13:31:42 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqCAI-00068T-1l; Thu, 08 Nov 2007 13:31:42 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCAG-00064k-GI
	for speermint@ietf.org; Thu, 08 Nov 2007 13:31:40 -0500
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqCAF-0000O9-Fy
	for speermint@ietf.org; Thu, 08 Nov 2007 13:31:40 -0500
Received: from ([24.40.15.118])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-NTF18.48633100;
	Thu, 08 Nov 2007 13:31:22 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PACDCEXCSMTP04.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:31:23 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Updated: draft-ietf-speermint-terminology-13
Date: Thu, 8 Nov 2007 13:31:22 -0500
Message-ID: <45AEC6EF95942140888406588E1A66020307D6BE@PACDCEXCMB04.cable.comcast.com>
In-Reply-To: <20071105161240.GB4606@nic.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] Updated: draft-ietf-speermint-terminology-13
Thread-Index: Acgfxs1e9lLKn4uBSsSlDoWLQRdrIQCbrTvw
References: <1193872413.1297.374.camel@montag.eng.level3.com>
	<20071105161240.GB4606@nic.at>
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Otmar Lendl" <lendl@nic.at>,
	"Daryl Malas" <daryl@level3.net>
X-OriginalArrivalTime: 08 Nov 2007 18:31:23.0164 (UTC)
	FILETIME=[906B95C0:01C82235]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Keep in mind we're simply defining TERMINOLOGY here...

Jason=20

> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]=20
> Sent: Monday, November 05, 2007 11:13 AM
> To: Daryl Malas
> Cc: speermint@ietf.org
> Subject: Re: [Speermint] Updated: draft-ietf-speermint-terminology-13
>=20
> On 2007/11/01 00:11, Daryl Malas <daryl@level3.net> wrote:
> >=20
> > This revision updates the WGLC of rev 12 discussion points.  Please=20
> > review the draft and provide feedback.
>=20
> As promised, here is my review. IMHO we're getting there.
>=20
> > 2.  SPEERMINT Context
> >=20
> >    Figure 1 depicts the general session peering context (Not in=20
> >    chronological order). Note that vertical axis in this figure=20
> >    describes the layering of identifiers, while the=20
> horizontal lines=20
> >    indicate working group scope. While the SPEERMINT=20
> working group is=20
> >    not limited (or coupled in any way) to the use of E.164=20
> numbers, in=20
> >    the case shown here an E.164 number [5] is used as a key=20
> in an E.164=20
> >    to Uniform Resource Identifier (URI) mapping (ENUM [4]).=20
> The result=20
> >    of this step (which involves looking up Naming Authority Pointer=20
> >    (NAPTR) records in the DNS) is a SIP URI, on which the=20
> subsequent=20
> >    call routing is based. Note that the call routing step does not=20
> >    depend on the presence of an E.164 number. Indeed, the=20
> resulting SIP=20
> >    URI may no longer even contain any numbers of any type. In=20
> >    particular, the SIP URI can be advertised in various=20
> other ways, such=20
> >    as on a web page.=20
>=20
> Good.
>=20
> >    Note that in Figure 1, Session Establishment Data (SED),=20
> is the data=20
> >    used to route a call to the called domain's ingress point (see=20
> >    Section 3.3 for additional detail).=20
>=20
> This is a bit ambiguous: is SED the input into the routing algorithm?
> is SED the result of the routing algorithm? Some interim step?
>=20
> >    As illustrated in Figure 1, the ENUM Working Group is primarily=20
> >    concerned with the acquisition of SED while the=20
> SPEERMINT Working=20
> >    Group is focused on the use of such SED in routing=20
> session signaling=20
> >    requests. Importantly, the SED can be derived from ENUM=20
> (i.e., an=20
> >    E.164 DNS entry) or via any other mechanism available to=20
> the user.=20
>=20
> As mentioned in the other mail: the user should never enter=20
> something which is not a neutral Address-of-Records SIP URI.=20
> I hesitate to call that SED.=20
>=20
> > 3.3. Session Establishment Data
> >=20
> >    Session Establishment Data, or SED, is the data used to=20
> route a call=20
> >    to the called domain's ingress point. A domain's ingress=20
> point can=20
> > be
>=20
> Same as above: "route" is a bit ambiguous. What about:
>=20
> |    Session Establishment Data, or SED, is the data needed=20
> to hand the
> |    call to the next hop's ingress point. In the simplest case, this
> |    information is derived from a SIP AoR using NAPTR/SRV/A record
> |    lookups according to RFC 3263.
>=20
> > 3.9. SIP Service Provider
> >=20
> >    A SIP Service Provider (or SSP) is an entity that provides=20
> >    application services utilizing SIP signaling to its customers.=20
>=20
> Stupid question: Do we actually care whether the SSP talks=20
> SIP with his customers? We already dumped all the graphs=20
> depicting the internal setup of a SSP as they are irrelevant=20
> to the peering question.
>=20
> So, if any incumbent telco (DT, Qwest, TI, Telia, ...)=20
> decides to use SIP for interconnection, is the fact that the=20
> customers themselves are attached using POTS or ISDN lines an=20
> obstacle to the use of speermint methods (whatever that may be)?
>=20
> > 4.1. Layer 3 Peering
> >=20
> >    Layer 3 peering refers to interconnection of two service=20
> providers'=20
> >    networks for the purposes of exchanging IP packets which=20
> destined for=20
> >    one (or both) of the peer's networks. Layer 3 peering is=20
> generally=20
> >    agnostic to the IP payload, and is frequently achieved using a=20
> >    routing protocol such as Border Gateway Protocol (BGP) [6] to=20
> >    exchange the required routing information.=20
> >=20
> >    An alternate, perhaps more operational definition of=20
> layer 3 peering=20
> >    is that two peers exchange only customer routes, and hence any=20
> >    traffic between peers terminates on the peer's network=20
> or the peer's=20
> >    customer's network.=20
> >=20
> > 4.2. Layer 5 Peering
> >=20
> >    Layer 5 (Session) peering refers to interconnection of=20
> two service=20
> >    providers for the purposes of routing real-time (or=20
> quasi-real time)=20
> >    call signaling between their respective customers using=20
> SIP methods. =20
>=20
> This is a good description.
>=20
> (This begs the question that given the similarities, why we=20
> need a routing protocol on layer 3 and but not on layer 5.=20
> This draft does not need to answer that, it is just terminology.)
>=20
> > 4.2.2. Indirect Peering
> >=20
> >    Indirect, or transit, peering refers to the=20
> establishment of either a=20
> >    signaling and media path or signaling path alone via one=20
> (or more)=20
> >    referral or transit network(s).=20
>=20
> This is misleading. When I read this paragraph, I conclude=20
> that the originating and terminating SSPs are peering=20
> (indirectly). Given your last mails, this is not what you=20
> intend to say.
>=20
> So what about:
>=20
> |    A peering whose signalling (and optionally a media) path is also
> |    used to carry calls originating or terminating not withing one
> |    of the peering SSPs is called an indirect (transit) peering.
> |    Any SSP in such a setup which is neither the originating nor
> |    the terminating SSP is called a "transit network".
>=20
> That's all a bit awkward.
>=20
> Perhaps we need to introduce the concept of "reachability", i.e.
> "is there a path via transit networks between SSP-O and SSP-T?"
>=20
> (In order to keep the terminology in sync with Layer3 stuff,=20
> we should not talk about primarily about "peering", but about=20
> "interconnection". A "peering" is just a special case where=20
> the set of announced routes is limited.)
>=20
> > 4.3.1. Look-Up Function
> >=20
> >    The Look-Up Function (LUF) provides a mechanism for querying an=20
> >    internal and/or external database, which maintains a=20
> list of peered=20
> >    host domains.=20
>=20
> Could you be a bit more specific here? What exactly is the=20
> input into the LUF, and what does the LUF return?
>=20
> >=20
> > 4.3.2. Location Function
> >=20
> >    The Location Function (LF) develops SED by discovering=20
> the Signaling=20
> >    Function (SF), and SF's reachable host (IP Address and port).=20
>=20
> Again: what is the input? Output? Can you give examples?
>=20
> That's it.
>=20
> /ol
> --
> / Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
> \ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

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



From speermint-bounces@ietf.org Thu Nov 08 15:53:10 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqEN8-0000B7-Jb; Thu, 08 Nov 2007 15:53:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEN7-00007J-NZ
	for speermint@ietf.org; Thu, 08 Nov 2007 15:53:05 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqEN7-00030A-JF
	for speermint@ietf.org; Thu, 08 Nov 2007 15:53:05 -0500
Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42])
	by ns1.neustar.com (Postfix) with ESMTP id 75734327BD;
	Thu,  8 Nov 2007 20:53:05 +0000 (GMT)
Received: from mirror by ietf.org with local (Exim 4.43)
	id 1IqEN7-0000eB-Ca; Thu, 08 Nov 2007 15:53:05 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: daryl.malas@level3.com
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Message-Id: <E1IqEN7-0000eB-Ca@ietf.org>
Date: Thu, 08 Nov 2007 15:53:05 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: speermint@ietf.org
Subject: [Speermint] New Version Notification for
	draft-ietf-speermint-terminology-13 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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


A new version of I-D, draft-ietf-speermint-terminology-13.txt has been successfuly submitted by Daryl Malas and posted to the IETF repository.

Filename:	 draft-ietf-speermint-terminology
Revision:	 13
Title:		 SPEERMINT Terminology
Creation_date:	 2007-11-08
WG ID:		 speermint
Number_of_pages: 13

Abstract:
This document defines the terminology that is to be used in 
describing Session PEERing for Multimedia INTerconnect (SPEERMINT).
                                                                                  


The IETF Secretariat.



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



From speermint-bounces@ietf.org Thu Nov 08 15:55:11 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqEP8-0003MW-Sk; Thu, 08 Nov 2007 15:55:10 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEP7-0003KV-57
	for speermint@ietf.org; Thu, 08 Nov 2007 15:55:09 -0500
Received: from mail44.messagelabs.com ([216.82.249.179])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqEP6-0004lk-7c
	for speermint@ietf.org; Thu, 08 Nov 2007 15:55:08 -0500
X-VirusChecked: Checked
X-Env-Sender: daryl@level3.net
X-Msg-Ref: server-11.tower-44.messagelabs.com!1194555297!33540250!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [209.245.18.106]
Received: (qmail 31836 invoked from network); 8 Nov 2007 20:54:57 -0000
Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106)
	by server-11.tower-44.messagelabs.com with SMTP;
	8 Nov 2007 20:54:57 -0000
Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57])
	by f10bb8-10 (Postfix) with ESMTP id EEB3E4441;
	Thu,  8 Nov 2007 20:54:56 +0000 (GMT)
Subject: RE: [Speermint] Updated: draft-ietf-speermint-terminology-13
From: Daryl Malas <daryl@level3.net>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
In-Reply-To: <45AEC6EF95942140888406588E1A66020307D6BD@PACDCEXCMB04.cable.comcast.com>
References: <1193872413.1297.374.camel@montag.eng.level3.com>
	<45AEC6EF95942140888406588E1A66020307D6BD@PACDCEXCMB04.cable.comcast.com>
Content-Type: text/plain
Date: Thu, 08 Nov 2007 14:04:08 -0700
Message-Id: <1194555848.1297.375.camel@montag.eng.level3.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 (2.6.0-1) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Done, look for it soon.

On Thu, 2007-11-08 at 13:30 -0500, Livingood, Jason wrote:
> Please upload this ID to the IETF site asap (today/tomorrow).  We should
> always submit to the I-D editor at the same time that we post to some
> private site for review for WG docs.
> 
> As soon as it is announced, we'll do a quick 2nd WGLC on -13.
> 
> Thanks
> Jason 
> 
> > -----Original Message-----
> > From: Daryl Malas [mailto:daryl@level3.net] 
> > Sent: Wednesday, October 31, 2007 7:14 PM
> > To: speermint@ietf.org
> > Subject: [Speermint] Updated: draft-ietf-speermint-terminology-13
> > 
> > In order to avoid several revisions prior to Vancouver, I 
> > have place an updated draft here:
> > http://www.malas.net-a.googlepages.com/draft-ietf-speermint-te
> > rminology-13.txt
> > 
> > This revision updates the WGLC of rev 12 discussion points.  
> > Please review the draft and provide feedback.
> > 
> > Thanks...
> > 
> > Daryl
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> > 


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



From speermint-bounces@ietf.org Thu Nov 08 16:00:10 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqETw-00021N-11; Thu, 08 Nov 2007 16:00:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqETs-0001ym-Dm; Thu, 08 Nov 2007 16:00:04 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1IqETq-0003Nt-2K; Thu, 08 Nov 2007 16:00:04 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0A44C328B9;
	Thu,  8 Nov 2007 21:00:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IqETp-0006Vw-Uc; Thu, 08 Nov 2007 16:00:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1IqETp-0006Vw-Uc@stiedprstage1.ietf.org>
Date: Thu, 08 Nov 2007 16:00:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: speermint@ietf.org
Subject: [Speermint] I-D Action:draft-ietf-speermint-terminology-13.txt 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.


	Title           : SPEERMINT Terminology
	Author(s)       : D. Malas, D. Meyer
	Filename        : draft-ietf-speermint-terminology-13.txt
	Pages           : 13
	Date            : 2007-11-08

This document defines the terminology that is to be used in 
describing Session PEERing for Multimedia INTerconnect (SPEERMINT).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-13.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-speermint-terminology-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-terminology-13.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-08155302.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-terminology-13.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-terminology-13.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-08155302.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From speermint-bounces@ietf.org Thu Nov 08 16:23:03 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqEq6-00043V-Q1; Thu, 08 Nov 2007 16:23:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEq5-0003zI-LM
	for speermint@ietf.org; Thu, 08 Nov 2007 16:23:01 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqEq3-00043J-13
	for speermint@ietf.org; Thu, 08 Nov 2007 16:23:01 -0500
Received: from ([10.52.116.30])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH7.38986096;
	Thu, 08 Nov 2007 16:22:39 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PAOAKEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 16:22:39 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 8 Nov 2007 16:22:39 -0500
Message-ID: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [wg-business] WGLC for draft-ietf-speermint-terminology-13
Thread-Index: AcgiTXyT2LUuTWVNQoucZCuye/0c3g==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 08 Nov 2007 21:22:39.0259 (UTC)
	FILETIME=[7D733EB0:01C8224D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: [Speermint] [wg-business] WGLC for
	draft-ietf-speermint-terminology-13
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

	Title           : SPEERMINT Terminology
	Author(s)       : D. Malas, D. Meyer
	Filename        : draft-ietf-speermint-terminology-13.txt
	Pages           : 13
	Date            : 2007-11-08
=09
This document defines the terminology that is to be used in describing
Session PEERing for Multimedia INTerconnect (SPEERMINT).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-13.
txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The intent of the last call is to solicit comments before submitting the
ID to the IESG.

The purpose of a working group Last Call is in the style of "speak now
or forever hold your peace" in case there are fundamental objections
which have not gotten previous or adequate discussion, or minor errors
which need correction.

Working group last call will extend for 2 weeks from today, 8 November
2007, until 22 November 2007.  Please note that this is the second WGLC
on this document.

Please post any comments in reply to the list, as well as to the
editor(s) of this draft.

Regards,

Jason & Dave

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

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



From speermint-bounces@ietf.org Fri Nov 09 13:15:40 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqYOK-0007Zv-1S; Fri, 09 Nov 2007 13:15:40 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IqYOD-0007O8-TE; Fri, 09 Nov 2007 13:15:33 -0500
Received: from ns3.neustar.com ([156.154.24.138])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IqYOD-0005Tb-AW; Fri, 09 Nov 2007 13:15:33 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id E0BB2175B3;
	Fri,  9 Nov 2007 18:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IqYNi-0003Bu-9H; Fri, 09 Nov 2007 13:15:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1IqYNi-0003Bu-9H@stiedprstage1.ietf.org>
Date: Fri, 09 Nov 2007 13:15:02 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: speermint@ietf.org
Subject: [Speermint] I-D ACTION:draft-ietf-speermint-srv-naptr-use-02.txt 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.

	Title		: Use of DNS SRV and NAPTR Records for SPEERMINT
	Author(s)	: T. Creighton, J. Livingood
	Filename	: draft-ietf-speermint-srv-naptr-use-02.txt
	Pages		: 11
	Date		: 2007-11-9
	
The objective of this document is to specify the Best Current 
   Practice (BCP) adopted by a service provider providing multimedia 
   communication services such as Voice over Internet Protocol(VoIP) in 
   order to locate another service provider to peer with in the context 
   of Session PEERing for Multimedia INTerconnect.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-srv-naptr-use-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-speermint-srv-naptr-use-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-srv-naptr-use-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-9120027.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-srv-naptr-use-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-srv-naptr-use-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-9120027.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From speermint-bounces@ietf.org Tue Nov 13 10:15:41 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxUJ-00027q-8t; Tue, 13 Nov 2007 10:15:39 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IrxUD-0001eX-3R; Tue, 13 Nov 2007 10:15:33 -0500
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1IrxUC-00081d-Kv; Tue, 13 Nov 2007 10:15:33 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8F0D62AC6D;
	Tue, 13 Nov 2007 15:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1IrxTi-00020l-9s; Tue, 13 Nov 2007 10:15:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1IrxTi-00020l-9s@stiedprstage1.ietf.org>
Date: Tue, 13 Nov 2007 10:15:02 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: speermint@ietf.org
Subject: [Speermint] I-D 
 ACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.

	Title		: VoIP SIP Peering Use Cases
	Author(s)	: A. Uzelac, et al.
	Filename	: draft-ietf-speermint-voip-consolidated-usecases-03.txt
	Pages		: 22
	Date		: 2007-11-13
	
This document will capture VoIP use case for SIP Peering.  It is a 
        consolidation of Speermint use cases drafts. This document depicts 
        many common VoIP peering use cases. These use cases are categorized 
        into three types: Direct, Indirect and Assisted. They are not the 
        exhaust set of use cases but the most common use cases deployed in 
        production today. This document captures them to provide a reference.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-speermint-voip-consolidated-usecases-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-13094339.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-voip-consolidated-usecases-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-13094339.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From speermint-bounces@ietf.org Tue Nov 13 15:19:04 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Is2Dr-0006dQ-2O; Tue, 13 Nov 2007 15:18:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2Dn-0006Zo-KD
	for speermint@ietf.org; Tue, 13 Nov 2007 15:18:55 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is2Dl-00037F-B8
	for speermint@ietf.org; Tue, 13 Nov 2007 15:18:55 -0500
Received: from ([10.52.116.31])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH7.39132608;
	Tue, 13 Nov 2007 15:18:24 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PAOAKEXCSMTP02.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 15:18:23 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] I-D
	ACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt 
Date: Tue, 13 Nov 2007 15:18:23 -0500
Message-ID: <45AEC6EF95942140888406588E1A66020307D7BE@PACDCEXCMB04.cable.comcast.com>
In-Reply-To: <E1IrxTi-00020l-9s@stiedprstage1.ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] I-D
	ACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt 
Thread-Index: AcgmCCFVs4dMgQEjQa6UswoCPKFizQAKc+rw
References: <E1IrxTi-00020l-9s@stiedprstage1.ietf.org>
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>, "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>,
	"Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
X-OriginalArrivalTime: 13 Nov 2007 20:18:23.0872 (UTC)
	FILETIME=[5786A000:01C82632]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

I think you guys indicated that you planned a quick -04 update in the
next 1 to 2 weeks to clean up some things in the draft and ensure that
this is in sync with the terminology I-D.  It would be wonderful to see
a -04 turned around in advance of IETF 70.  Then any feedback from IETF
70 can go into a -05 just after or during the week of IETF 70, after
which we can issue a WGLC.

I am copying the WG on this so everyone understands that we need to
press ahead on this I-D rapidly, and that we'll be reviewing in the
great detail at IETF 70.  So please ensure you read the I-D and get
comments to the authors before IETF 70 (preferred) or at IETF 70.=20

Thanks
Jason

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
> Sent: Tuesday, November 13, 2007 10:15 AM
> To: i-d-announce@ietf.org
> Cc: speermint@ietf.org
> Subject: [Speermint] I-D=20
> ACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Session PEERing for=20
> Multimedia INTerconnect Working Group of the IETF.
>=20
> 	Title		: VoIP SIP Peering Use Cases
> 	Author(s)	: A. Uzelac, et al.
> 	Filename	:=20
> draft-ietf-speermint-voip-consolidated-usecases-03.txt
> 	Pages		: 22
> 	Date		: 2007-11-13
> =09
> This document will capture VoIP use case for SIP Peering.  It is a=20
>         consolidation of Speermint use cases drafts. This=20
> document depicts=20
>         many common VoIP peering use cases. These use cases=20
> are categorized=20
>         into three types: Direct, Indirect and Assisted. They=20
> are not the=20
>         exhaust set of use cases but the most common use=20
> cases deployed in=20
>         production today. This document captures them to=20
> provide a reference.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-
> consolidated-usecases-03.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to i-d-announce-request@ietf.org with the word=20
> unsubscribe in the body of the message.=20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then=20
> "get draft-ietf-speermint-voip-consolidated-usecases-03.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE=20
> /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas
> es-03.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>=20
> Below is the data which will enable a MIME compliant mail=20
> reader implementation to automatically retrieve the ASCII=20
> version of the Internet-Draft.
>=20

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



From speermint-bounces@ietf.org Fri Nov 16 10:43:10 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It3LU-0007hR-EB; Fri, 16 Nov 2007 10:43:04 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1It3LS-0007eT-9i
	for speermint@ietf.org; Fri, 16 Nov 2007 10:43:02 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=bemg01.siemenscomms.co.uk)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It3LR-0002gl-KR
	for speermint@ietf.org; Fri, 16 Nov 2007 10:43:02 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.0-24 #40642)
	with ESMTP id <0JRL0094AVMXTD@siemenscomms.co.uk> for
	speermint@ietf.org; Fri, 16 Nov 2007 15:42:33 +0000 (GMT)
Date: Fri, 16 Nov 2007 15:42:55 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Speermint] [wg-business] WGLC for
	draft-ietf-speermint-terminology-13
In-reply-to: A
	<45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, speermint@ietf.org,
	"Malas, Daryl" <Daryl.Malas@Level3.com>, Dave Meyer <dmm@1-4-5.net>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0440FBE@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Speermint] [wg-business] WGLC for
	draft-ietf-speermint-terminology-13
Thread-Index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gGF/7Kg
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: A
	<45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

I still think the concept of SED is confusing. On the one hand it says:
"   As illustrated in Figure 1, the ENUM Working Group is primarily 
   concerned with the acquisition of SED while the SPEERMINT Working 
   Group is focused on the use of such SED in routing session signaling 
   requests. Importantly, the SED can be derived from ENUM (i.e., an 
   E.164 DNS entry) or via any other mechanism available to the user."
This clearly says that SED is input to the SPEERMINT process and can be
provided by the ENUM process. As far as I know, the ENUM process will
only provide a SIP URI.

On the other hand, it states:
"   More specifically, the SED is the set of parameters that the
outgoing 
   SBEs need to complete the call, and may include: 

     . A destination SIP URI 

     . A SIP proxy to send the INVITE to, including 

          o  Fully Qualified Domain Name (FQDN) 

          o  Port 

          o  Transport Protocol (UDP/TCP/TLS [9/10/11]) 

     . Security Parameters, including 

          o  TLS certificate to use 

          o  TLS certificate to expect 

          o  TLS certificate verification setting 

     . Optional resource control parameters such as 

          o  Limits on the total number of call initiations to a peer 

          o  Limits on SIP transactions/second "

This is clearly in conflict, since it is a lot more than just the SIP
URI and also appears to include a lot of data that is output from,
rather than input to, the SPEERMINT process.
 
John


> -----Original Message-----
> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] 
> Sent: 08 November 2007 21:23
> To: speermint@ietf.org
> Subject: [Speermint] [wg-business] WGLC for 
> draft-ietf-speermint-terminology-13
> 
> 
> 	Title           : SPEERMINT Terminology
> 	Author(s)       : D. Malas, D. Meyer
> 	Filename        : draft-ietf-speermint-terminology-13.txt
> 	Pages           : 13
> 	Date            : 2007-11-08
> 	
> This document defines the terminology that is to be used in describing
> Session PEERing for Multimedia INTerconnect (SPEERMINT).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi
> nology-13.
> txt
> ==============================================================
> ==========
> =================
> The intent of the last call is to solicit comments before 
> submitting the
> ID to the IESG.
> 
> The purpose of a working group Last Call is in the style of "speak now
> or forever hold your peace" in case there are fundamental objections
> which have not gotten previous or adequate discussion, or minor errors
> which need correction.
> 
> Working group last call will extend for 2 weeks from today, 8 November
> 2007, until 22 November 2007.  Please note that this is the 
> second WGLC
> on this document.
> 
> Please post any comments in reply to the list, as well as to the
> editor(s) of this draft.
> 
> Regards,
> 
> Jason & Dave
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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



From speermint-bounces@ietf.org Fri Nov 16 12:37:14 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It4pQ-0003tF-Mo; Fri, 16 Nov 2007 12:18:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It4nH-0001NM-Rd; Fri, 16 Nov 2007 12:15:53 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1It4my-0006Gi-5f; Fri, 16 Nov 2007 12:15:51 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 12B3A32935;
	Fri, 16 Nov 2007 17:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1It4mT-0002qx-UW; Fri, 16 Nov 2007 12:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1It4mT-0002qx-UW@stiedprstage1.ietf.org>
Date: Fri, 16 Nov 2007 12:15:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: speermint@ietf.org
Subject: [Speermint] I-D 
 ACTION:draft-ietf-speermint-consolidated-presence-im-usecases-03.txt 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.

	Title		: Presence & Instant Messaging Peering Use Cases
	Author(s)	: A. Houri, et al.
	Filename	: draft-ietf-speermint-consolidated-presence-im-usecases-03.txt
	Pages		: 9
	Date		: 2007-11-16
	
The document describes several use cases of peering of non-VoIP
   services between two or more Service Providers (SP).  These Service
   Providers create a peering relationship between themselves thus
   enabling their users to collaborate with users on the other Service
   Provider network.  The target of the document is to drive
   requirements for peering between domains that provide the non-VoIP
   based collaboration services and presence and Instant Messaging (IM)
   in particular.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-speermint-consolidated-presence-im-usecases-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-16113521.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-consolidated-presence-im-usecases-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-16113521.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From speermint-bounces@ietf.org Mon Nov 19 08:50:18 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu70p-0002TA-KC; Mon, 19 Nov 2007 08:50:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu70k-0002NF-8P; Mon, 19 Nov 2007 08:50:02 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Iu70j-0001fL-S0; Mon, 19 Nov 2007 08:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id BC89C26E60;
	Mon, 19 Nov 2007 13:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Iu70j-0004oQ-LE; Mon, 19 Nov 2007 08:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Iu70j-0004oQ-LE@stiedprstage1.ietf.org>
Date: Mon, 19 Nov 2007 08:50:01 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: speermint@ietf.org
Subject: [Speermint] I-D Action:draft-ietf-speermint-requirements-03.txt 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.


	Title           : SPEERMINT Requirements for SIP-based VoIP Interconnection
	Author(s)       : J. Mule
	Filename        : draft-ietf-speermint-requirements-03.txt
	Pages           : 29
	Date            : 2007-11-19

A number of use cases have been identified for session peering of
voice and other types of multimedia traffic.  This memo captures some
of the requirements that enable these use case scenarios.  In its
current version, this document describes both general and use case
specific requirements for session peering for multimedia
interconnect.  It is intended to become an informational document
linking the use cases with potential protocol solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-03.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-speermint-requirements-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-requirements-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-19084053.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-requirements-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-requirements-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-19084053.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From speermint-bounces@ietf.org Mon Nov 19 09:27:36 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu7b4-0002Pl-0D; Mon, 19 Nov 2007 09:27:34 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7DM-0000t8-5v
	for speermint@ietf.org; Mon, 19 Nov 2007 09:03:04 -0500
Received: from ondar.cablelabs.com ([192.160.73.61])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu7DL-0001oJ-JU
	for speermint@ietf.org; Mon, 19 Nov 2007 09:03:04 -0500
Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7])
	by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lAJE31wU023308
	for <speermint@ietf.org>; Mon, 19 Nov 2007 07:03:01 -0700
Received: from srvxchg3.cablelabs.com (10.5.0.25)
	by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com);
	Mon, 19 Nov 2007 07:03:01 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Nov 2007 07:03:00 -0700
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C695BEB5@srvxchg3.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: new version of draft-ietf-speermint-requirements
Thread-Index: AcgqtOVL74Z37bEWREGpNBMXNAQ/Lg==
From: "Jean-Francois Mule" <jf.mule@cablelabs.com>
To: <speermint@ietf.org>
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Subject: [Speermint] new version of draft-ietf-speermint-requirements
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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


   Until the announcement is sent to the list by the submission tool,
the new version of the requirements draft is available at:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-03
.txt

   This update is a minor revision, mostly a refresh of the ID to
address the comments received as follows:

1/ Comments at IETF and via email from John Elwell:
	+ mis-use of RFC2119 verbs
	+ requirements should not be put on service providers
	+ no need for SSPs to declare/advertize SDE

2/ Feedback from various participants, chairs and Jon Peterson:=20
This ID is a speermint requirement document and its main intent is now
to translate the use cases that have been expressed by the wg
(consolidated use case draft plus IM use cases) into a set of
requirements to must be met by protocol mechanisms to enable the use
cases we have.
    =3D> Section 3 has been reworked per the above, showing what text =
and
use case brings what requirement.  I lacked time to do more analysis and
improve the writing but this should give the orientation. =20

Comments welcome.

Jean-Francois.


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



From speermint-bounces@ietf.org Tue Nov 20 07:38:02 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuSMa-0006Nz-G3; Tue, 20 Nov 2007 07:38:00 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuSMY-0006Mj-El; Tue, 20 Nov 2007 07:37:58 -0500
Received: from [202.99.23.227] (helo=people.com.cn)
	by chiedprmail1.ietf.org with smtp (Exim 4.43)
	id 1IuSMX-0000qV-DA; Tue, 20 Nov 2007 07:37:58 -0500
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jm31474316aa; Tue, 20 Nov 2007 20:50:54 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id jmf473df781; Sat, 17 Nov 2007 02:50:05 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id AISP action; Sat, 17 Nov 2007 02:50:05 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It4pM-0003ga-RV; Fri, 16 Nov 2007 12:18:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1It4nH-0001NM-Rd; Fri, 16 Nov 2007 12:15:53 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1It4my-0006Gi-5f; Fri, 16 Nov 2007 12:15:51 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 12B3A32935;
	Fri, 16 Nov 2007 17:15:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1It4mT-0002qx-UW; Fri, 16 Nov 2007 12:15:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1It4mT-0002qx-UW@stiedprstage1.ietf.org>
Date: Fri, 16 Nov 2007 12:15:01 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: Internet-Drafts@ietf.org
X-Auto-Forward: jaglee@people.com.cn
 jag@kw.com.cn
X-Spam-Score: 2.8 (++)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: speermint@ietf.org
Subject: [Speermint] I-D 
 ACTION:draft-ietf-speermint-consolidated-presence-im-usecases-03.txt 
X-BeenThere: speermint@ietf.org
Reply-To: internet-drafts@ietf.org
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.

	Title		: Presence & Instant Messaging Peering Use Cases
	Author(s)	: A. Houri, et al.
	Filename	: draft-ietf-speermint-consolidated-presence-im-usecases-03.txt
	Pages		: 9
	Date		: 2007-11-16
	
The document describes several use cases of peering of non-VoIP
   services between two or more Service Providers (SP).  These Service
   Providers create a peering relationship between themselves thus
   enabling their users to collaborate with users on the other Service
   Provider network.  The target of the document is to drive
   requirements for peering between domains that provide the non-VoIP
   based collaboration services and presence and Instant Messaging (IM)
   in particular.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-speermint-consolidated-presence-im-usecases-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-16113521.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-consolidated-presence-im-usecases-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-consolidated-presence-im-usecases-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-16113521.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From speermint-bounces@ietf.org Tue Nov 20 12:30:42 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IuWvm-0007fr-V5; Tue, 20 Nov 2007 12:30:38 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWvl-0007dQ-HP
	for speermint@ietf.org; Tue, 20 Nov 2007 12:30:37 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuWvk-0001l7-8D
	for speermint@ietf.org; Tue, 20 Nov 2007 12:30:37 -0500
Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian))
	id 1IuWvg-0005rE-00; Tue, 20 Nov 2007 18:30:32 +0100
Date: Tue, 20 Nov 2007 18:30:32 +0100
From: Otmar Lendl <lendl@nic.at>
To: Jean-Francois Mule <jf.mule@cablelabs.com>
Subject: Re: [Speermint] new version of draft-ietf-speermint-requirements
Message-ID: <20071120173032.GA22290@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>,
	Jean-Francois Mule <jf.mule@cablelabs.com>, speermint@ietf.org
References: <9AAEDF491EF7CA48AB587781B8F5D7C695BEB5@srvxchg3.cablelabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C695BEB5@srvxchg3.cablelabs.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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


Well, I took a print-out of -02 on a plane for a review, and before
I managed to type my comments, you release -03. Oh well.

Anyway:

On 2007/11/19 15:11, Jean-Francois Mule <jf.mule@cablelabs.com> wrote:
> 
> 1/ Comments at IETF and via email from John Elwell:

> 	+ requirements should not be put on service providers

> 
> 2/ Feedback from various participants, chairs and Jon Peterson: 
> This ID is a speermint requirement document and its main intent is now
> to translate the use cases that have been expressed by the wg
> (consolidated use case draft plus IM use cases) into a set of
> requirements to must be met by protocol mechanisms to enable the use
> cases we have.

This is very positive change of direction. The "this document lists
requirements on SSPs" idea has always been a source of misunderstanding
and confusion. 

The document is much clearer and more consistent this way (e.g. in -02
the IM sections already listed requirements on protocol features
whereas the rest of the document described considerations for SSPs).

> Comments welcome.

Here are some based on my notes plus looking at the diff:

>       SPEERMINT Requirements for SIP-based VoIP Interconnection
>                draft-ietf-speermint-requirements-03.txt

>1.  Introduction
>
>   Peering at the session layer can be achieved on a bilateral basis
>   (direct peering with SIP sessions established directly between two
>   SSPs), or on an indirect basis via an intermediary (indirect peering
>   via a third-party SSP that has a trust relationship with the SSPs),
>   or on a multilateral basis (assisted peering using a federation model
>   between SSPs) - see the terminology document for more details.

As with the terminology draft, I'm a bit worried whether we're really
clear and consistent regarding the term "indirect peering". As I read
this paragraph, in the case of the scenario SSP-O -- SSP-transit -- SSP-T 
this language suggests that "SSP-O" and "SSP-T" are doing "indirect
peering" with each other. Daryl's mails seem to indicate that he
intended that term to be used for the relationship "SSP-O -- SSP-transit"
and "SSP-transit -- SSP-T".

In other words, is this an example of two indirect peering relationships
or is this just one indirect peering involving three SSPs?

(I don't particularily care one way or the other, I just strive 
for consistency.)

>3.2.  Session Peering Points
>
>      Requirement #1: protocol mechanisms must exist for SSPs to
>      communicate the egress and ingress points of its service domain.
>      The session peering points may be advertized to session peers
>      using static mechanisms or they may be dynamically advertized.
>
>      Notes on solution space: there seems to be general agreement that
>      [RFC3263] provides a solution for dynamic advertisements in most
>      cases of Direct, Indirect and Assistent peering use cases.  There
>      continues to be discussion on how to best use this to advertize
>      peer-dependent SBEs (see below).

Regarding ingress points, this is certainly true for direct peerings.
I don't see how the current RFCs ever announce any egress elements.

>      Requirement #3: the mechanisms recommended for the declaration and
>      advertisement of SBE and SDE entities must allow for peer and
>      media variability.

Good point.

>      Notes on solution space: for advertising peer-dependent SBEs (peer
>      variability), the solution space based on is under specified and
>      there are no know best current practices.  

Yes, this is where RFC3263 in the public DNS is not sufficient.

>      Requirement #4: the mechanisms recommended for the location
>      service must be capable or returning both a target URI destination
>      and a SIP Route.
>
>      Notes on solution space: solutions exist if the protocol used
>      between the SM and the LS is SIP; if ENUM is used, the author of
>      this document does not know of any solution today.

Once again a valid point.  I'm just not 100% sure whether we should nail
down the solution to the SM-LS interface or whether we should be more
open here. (e.g. allow for other ways how the information is learned
by the SM.)

>      Requirement #5: the mechanisms recommended for locating a peer's
>      SBE must be able to convey how a peer should initiate secure
>      session establishment.

Ack.

>
>3.3.  Session Establishment Data (SED)
>
>   The Session Establishment Data (SED) is defined as the data used to
>   route a call or SIP session to the called domain's ingress point
>   ([I-D.ietf-speermint-terminology]).  Given that SED is the set of
>   parameters that the Session Managers and outgoing SBEs need to
>   complete the session establishment, some information is shared
>   between SSPs.  The following paragraphs capture some general
>   requirements on the SED data.

I like the "SIP Route" you mentioned in Req.#5, and perhaps you
should reference it here again, as the next SIP hop information
and the request URI to use are the central components of the SED.

>3.3.1.  User Identities and SIP URIs
>
>      Requirement #6: 

Ack.

>      Requirement #7: 

Ack.

>3.3.2.  URI Reachability
>
>   Based on a well-known URI type (for e.g. sip, pres, or im URIs), it
>   must be possible to determine whether the SSP domain servicing the
>   URI allows for session peering, and if it does, it should be possible
>   to locate and retrieve the domain's policy and SBE entities.

Shouldn't that be "allows direct session peering ..."?

Plus a second sentence like "if the SSP domain servicing the URI can
be reached via an indirect peering involving a transit SSP, the identity
and the ingress elements of this tranit SSP need to be learned".

>   For example, an originating service provider must be able to
>   determine whether a SIP URI is open for direct interconnection
>   without requiring an SBE to initiate a SIP request.  

Hm? How can there be a direct interconnection without a SIP request?
Shouldn't that be "without requiring a pre-established SIP connection"?

>
>      Requirement #8: the mechanisms for session peering must allow an
>      SBE to locate its peer SBE given a SSP hostname or domain name.

Ack.

>      Notes on the solution space: generally well understood in IETF.
>      Open questions exist in how dynamic should the mechanism be to be
>      able to retrieve the domain's policy for secure signaling between
>      SBEs, peer-dependent/media-dependent policies.

Well, it's well understood for direct peering. It's completely undefined
for indirect and assisted peering.

>4.5.2.  Signaling Security and TLS Considerations
>
>      5.  SIP and SBE servers involved in the session establishment over
>      TLS must verify and validate the client certificates: the client
>      certificate must contain a DNS or URI choice type in the
>      subjectAltName which corresponds to the domain asserted in the
>      host portion of the URI contained in the From header.  It is also
>      recommended that VSPs/ASPs convey the domain identity in the
>      certificates using both a canonical name of the SIP server(s) and
>      the SIP URI for the domain as described in section 4 of
>      [I-D.gurbani-sip-domain-certs].  

I'm not up-to-date familiar with the SIP / TLS standards, I just want
to make sure that customer-owned domains in SIP URIs do not cause
troubles here.

-------------------------

This draft is a huge step forward for speermint.

/ol
-- 
/ Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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



From speermint-bounces@ietf.org Wed Nov 21 09:59:13 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iur2l-0005GR-W0; Wed, 21 Nov 2007 09:59:11 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iur2k-0005Fd-QB
	for speermint@ietf.org; Wed, 21 Nov 2007 09:59:10 -0500
Received: from pacdcimo01.cable.comcast.com ([24.40.8.145])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iur2k-0003gI-7y
	for speermint@ietf.org; Wed, 21 Nov 2007 09:59:10 -0500
Received: from ([10.195.246.152])
	by pacdcimo01.cable.comcast.com with ESMTP  id KP-BXT38.10326715;
	Wed, 21 Nov 2007 09:58:28 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	NJMDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 09:58:28 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] [wg-business] WGLC
	fordraft-ietf-speermint-terminology-13
Date: Wed, 21 Nov 2007 09:58:27 -0500
Message-ID: <45AEC6EF95942140888406588E1A66020307D94F@PACDCEXCMB04.cable.comcast.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0440FBE@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] [wg-business] WGLC
	fordraft-ietf-speermint-terminology-13
Thread-Index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gGF/7KgAPpZYxA=
References: A
	<45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0440FBE@GBNTHT12009MSX.gb002.siemens.net>
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Elwell, John" <john.elwell@siemens.com>, <speermint@ietf.org>,
	"Malas, Daryl" <Daryl.Malas@Level3.com>, "Dave Meyer" <dmm@1-4-5.net>
X-OriginalArrivalTime: 21 Nov 2007 14:58:28.0215 (UTC)
	FILETIME=[F953D070:01C82C4E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

It is easy to identify problems in any document.  ;-)  We're open to any
suggestion on how to resolve this by you.  Please make a proposal to the
list.

Thanks
Jason=20

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]=20
> Sent: Friday, November 16, 2007 10:43 AM
> To: Livingood, Jason; speermint@ietf.org; Malas, Daryl; Dave Meyer
> Subject: RE: [Speermint] [wg-business] WGLC=20
> fordraft-ietf-speermint-terminology-13
>=20
> I still think the concept of SED is confusing. On the one=20
> hand it says:
> "   As illustrated in Figure 1, the ENUM Working Group is primarily=20
>    concerned with the acquisition of SED while the SPEERMINT Working=20
>    Group is focused on the use of such SED in routing session=20
> signaling=20
>    requests. Importantly, the SED can be derived from ENUM (i.e., an=20
>    E.164 DNS entry) or via any other mechanism available to the user."
> This clearly says that SED is input to the SPEERMINT process=20
> and can be provided by the ENUM process. As far as I know,=20
> the ENUM process will only provide a SIP URI.
>=20
> On the other hand, it states:
> "   More specifically, the SED is the set of parameters that the
> outgoing=20
>    SBEs need to complete the call, and may include:=20
>=20
>      . A destination SIP URI=20
>=20
>      . A SIP proxy to send the INVITE to, including=20
>=20
>           o  Fully Qualified Domain Name (FQDN)=20
>=20
>           o  Port=20
>=20
>           o  Transport Protocol (UDP/TCP/TLS [9/10/11])=20
>=20
>      . Security Parameters, including=20
>=20
>           o  TLS certificate to use=20
>=20
>           o  TLS certificate to expect=20
>=20
>           o  TLS certificate verification setting=20
>=20
>      . Optional resource control parameters such as=20
>=20
>           o  Limits on the total number of call initiations to a peer=20
>=20
>           o  Limits on SIP transactions/second "
>=20
> This is clearly in conflict, since it is a lot more than just=20
> the SIP URI and also appears to include a lot of data that is=20
> output from, rather than input to, the SPEERMINT process.
> =20
> John
>=20
>=20
> > -----Original Message-----
> > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
> > Sent: 08 November 2007 21:23
> > To: speermint@ietf.org
> > Subject: [Speermint] [wg-business] WGLC for
> > draft-ietf-speermint-terminology-13
> >=20
> >=20
> > 	Title           : SPEERMINT Terminology
> > 	Author(s)       : D. Malas, D. Meyer
> > 	Filename        : draft-ietf-speermint-terminology-13.txt
> > 	Pages           : 13
> > 	Date            : 2007-11-08
> > =09
> > This document defines the terminology that is to be used in=20
> describing=20
> > Session PEERing for Multimedia INTerconnect (SPEERMINT).
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi
> > nology-13.
> > txt
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > The intent of the last call is to solicit comments before=20
> submitting=20
> > the ID to the IESG.
> >=20
> > The purpose of a working group Last Call is in the style of=20
> "speak now=20
> > or forever hold your peace" in case there are fundamental=20
> objections=20
> > which have not gotten previous or adequate discussion, or=20
> minor errors=20
> > which need correction.
> >=20
> > Working group last call will extend for 2 weeks from today,=20
> 8 November=20
> > 2007, until 22 November 2007.  Please note that this is the second=20
> > WGLC on this document.
> >=20
> > Please post any comments in reply to the list, as well as to the
> > editor(s) of this draft.
> >=20
> > Regards,
> >=20
> > Jason & Dave
> >=20
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> >=20
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> >=20
>=20

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



From speermint-bounces@ietf.org Wed Nov 21 12:45:03 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IutdD-0002QW-Su; Wed, 21 Nov 2007 12:44:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IutdB-0002QO-HG
	for speermint@ietf.org; Wed, 21 Nov 2007 12:44:57 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]
	helo=mailhost.siemenscomms.co.uk)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iutd7-0005PN-0K
	for speermint@ietf.org; Wed, 21 Nov 2007 12:44:57 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x11 #31430)
	with ESMTP id <0JRV0030QAMSFO@siemenscomms.co.uk> for
	speermint@ietf.org; Wed, 21 Nov 2007 17:44:52 +0000 (GMT)
Date: Wed, 21 Nov 2007 17:44:51 +0000
From: "Elwell, John" <john.elwell@siemens.com>
To: speermint@ietf.org, Jean-Francois Mule <jf.mule@cablelabs.com>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441600@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: Comments on Requirements-03
Thread-Index: AcgsZjfSV1bztBsHTWmO5MhpimN6Kw==
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: 
Subject: [Speermint] Comments on Requirements-03
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Jean-Francois,

I am now a lot happier about the way the requirements in section 3 are
formulated (in terms of "protocol mechanisms must...". Thanks.

I haven't done a complete review, but I happened to notice the
following:

1. "Requirement #1: protocol mechanisms must exist for SSPs to
      communicate the egress and ingress points of its service domain."
Why do ingress points need to be advertised?

2. "a mechanism should exist to allow SSPs to advertize their
   media border elements responsible for egress and ingress points so
   called Signaling Path Data Elements (SDEs)."
There is confusing use of terminology, not in line with terminology
draft. What are "Signalling Path Data Elements (SDEs)" and, if they are
on the signalling path, why are they another name for "media border
elements"?

3. "Requirement #2: protocol mechanisms must exist for SSPs to
      communicate the egress and ingress media points or SDEs of its
      service domain.

      Notes on solution space: SSPs engaged in SIP interconnects do
      exchange this information today in a static manner."
If SDEs are indeed media border elements, they are exchanged using SDP
on a per call basis. Why is there a requirement for anything else? To
me, the preceding paragraph does not really give convincing
justification.

John



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



From speermint-bounces@ietf.org Wed Nov 21 16:08:04 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iuwna-000271-G9; Wed, 21 Nov 2007 16:07:54 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwnY-00026k-Eq
	for speermint@ietf.org; Wed, 21 Nov 2007 16:07:52 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuwnX-00018M-HM
	for speermint@ietf.org; Wed, 21 Nov 2007 16:07:52 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x11 #31430)
	with ESMTP id <0JRV00D1ZK120I@siemenscomms.co.uk> for
	speermint@ietf.org; Wed, 21 Nov 2007 21:07:50 +0000 (GMT)
Date: Wed, 21 Nov 2007 21:07:49 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Speermint] [wg-business] WGLC
	fordraft-ietf-speermint-terminology-13
In-reply-to: A
	<45AEC6EF95942140888406588E1A66020307D94F@PACDCEXCMB04.cable.comcast.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, speermint@ietf.org,
	"Malas, Daryl" <Daryl.Malas@Level3.com>, Dave Meyer <dmm@1-4-5.net>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441618@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Speermint] [wg-business] WGLC
	fordraft-ietf-speermint-terminology-13
Thread-Index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gGF/7KgAPpZYxAADIiegA==
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: A
	<45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0440FBE@GBNTHT12009MSX.gb002.siemens.net>
	A
	<45AEC6EF95942140888406588E1A66020307D94F@PACDCEXCMB04.cable.comcast.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Jason,

Thanks for the invitation. I will not make a text proposal at present,
but a general proposal how to solve it.

Basically, I think it would make more sense if SED were the data you
ended up with at the end of the SPEERMINT process.

I think  the following existing statement: 
"Note that in Figure 1, Session Establishment Data (SED), is the data 
   used to route a call to the called domain's ingress point (see 
   Section 3.3 for additional detail)."
Would then be correct, but the position of SED in figure 1 would be
wrong, because it looks like it is intended to be input data to the
look-up. Also in figure 1, I think the processes of federation
detection, policy look-up and service location are all things that help
to construct the SED. So figure 1 would need some rework. However, to me
the conventions used in figure 1 are unclear, so I don't know how it
should be represented. But basically it should show the following
things:
 - the input to the SPEERMINT process is the SIP URI;
 - the process itself comprises look-up to achieve federation detection,
policy and service location;
 - the output from the SPEERMINT process is the SED.

I think the following existing statement is wrong:
"As illustrated in Figure 1, the ENUM Working Group is primarily 
   concerned with the acquisition of SED while the SPEERMINT Working 
   Group is focused on the use of such SED in routing session signaling 
   requests. Importantly, the SED can be derived from ENUM (i.e., an 
   E.164 DNS entry) or via any other mechanism available to the user. 
   Finally, note that the term "call" is being used here in the most 
   general sense, i.e., call routing and session routing are used 
   interchangeably."
Because this treats SED as input, not as output from the process.

I think the following existing statement:
"More specifically, the SED is the set of parameters that the outgoing 
   SBEs need to complete the call, and may include:"
and the bullets that follow it are correct, because they seem to
describe the output from the process.

I haven't cross-checked whether this would align with usage of SED in
other documents.

John

> -----Original Message-----
> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] 
> Sent: 21 November 2007 14:58
> To: Elwell, John; speermint@ietf.org; Malas, Daryl; Dave Meyer
> Subject: RE: [Speermint] [wg-business] WGLC 
> fordraft-ietf-speermint-terminology-13
> 
> It is easy to identify problems in any document.  ;-)  We're 
> open to any
> suggestion on how to resolve this by you.  Please make a 
> proposal to the
> list.
> 
> Thanks
> Jason 
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens.com] 
> > Sent: Friday, November 16, 2007 10:43 AM
> > To: Livingood, Jason; speermint@ietf.org; Malas, Daryl; Dave Meyer
> > Subject: RE: [Speermint] [wg-business] WGLC 
> > fordraft-ietf-speermint-terminology-13
> > 
> > I still think the concept of SED is confusing. On the one 
> > hand it says:
> > "   As illustrated in Figure 1, the ENUM Working Group is primarily 
> >    concerned with the acquisition of SED while the 
> SPEERMINT Working 
> >    Group is focused on the use of such SED in routing session 
> > signaling 
> >    requests. Importantly, the SED can be derived from ENUM 
> (i.e., an 
> >    E.164 DNS entry) or via any other mechanism available to 
> the user."
> > This clearly says that SED is input to the SPEERMINT process 
> > and can be provided by the ENUM process. As far as I know, 
> > the ENUM process will only provide a SIP URI.
> > 
> > On the other hand, it states:
> > "   More specifically, the SED is the set of parameters that the
> > outgoing 
> >    SBEs need to complete the call, and may include: 
> > 
> >      . A destination SIP URI 
> > 
> >      . A SIP proxy to send the INVITE to, including 
> > 
> >           o  Fully Qualified Domain Name (FQDN) 
> > 
> >           o  Port 
> > 
> >           o  Transport Protocol (UDP/TCP/TLS [9/10/11]) 
> > 
> >      . Security Parameters, including 
> > 
> >           o  TLS certificate to use 
> > 
> >           o  TLS certificate to expect 
> > 
> >           o  TLS certificate verification setting 
> > 
> >      . Optional resource control parameters such as 
> > 
> >           o  Limits on the total number of call initiations 
> to a peer 
> > 
> >           o  Limits on SIP transactions/second "
> > 
> > This is clearly in conflict, since it is a lot more than just 
> > the SIP URI and also appears to include a lot of data that is 
> > output from, rather than input to, the SPEERMINT process.
> >  
> > John
> > 
> > 
> > > -----Original Message-----
> > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
> > > Sent: 08 November 2007 21:23
> > > To: speermint@ietf.org
> > > Subject: [Speermint] [wg-business] WGLC for
> > > draft-ietf-speermint-terminology-13
> > > 
> > > 
> > > 	Title           : SPEERMINT Terminology
> > > 	Author(s)       : D. Malas, D. Meyer
> > > 	Filename        : draft-ietf-speermint-terminology-13.txt
> > > 	Pages           : 13
> > > 	Date            : 2007-11-08
> > > 	
> > > This document defines the terminology that is to be used in 
> > describing 
> > > Session PEERing for Multimedia INTerconnect (SPEERMINT).
> > > 
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi
> > > nology-13.
> > > txt
> > > ==============================================================
> > > ==========
> > > =================
> > > The intent of the last call is to solicit comments before 
> > submitting 
> > > the ID to the IESG.
> > > 
> > > The purpose of a working group Last Call is in the style of 
> > "speak now 
> > > or forever hold your peace" in case there are fundamental 
> > objections 
> > > which have not gotten previous or adequate discussion, or 
> > minor errors 
> > > which need correction.
> > > 
> > > Working group last call will extend for 2 weeks from today, 
> > 8 November 
> > > 2007, until 22 November 2007.  Please note that this is 
> the second 
> > > WGLC on this document.
> > > 
> > > Please post any comments in reply to the list, as well as to the
> > > editor(s) of this draft.
> > > 
> > > Regards,
> > > 
> > > Jason & Dave
> > > 
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > > 
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > > 
> > 
> 

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



From speermint-bounces@ietf.org Thu Nov 22 05:25:40 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iv9FY-00037Z-FC; Thu, 22 Nov 2007 05:25:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9FR-00033a-7k
	for speermint@ietf.org; Thu, 22 Nov 2007 05:25:29 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv9FL-0002hO-L6
	for speermint@ietf.org; Thu, 22 Nov 2007 05:25:29 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x11 #31430)
	with ESMTP id <0JRW00E4XKVIBI@siemenscomms.co.uk> for
	speermint@ietf.org; Thu, 22 Nov 2007 10:23:42 +0000 (GMT)
Date: Thu, 22 Nov 2007 10:23:41 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Speermint]
	I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
In-reply-to: A
	<45AEC6EF95942140888406588E1A66020307D7BE@PACDCEXCMB04.cable.comcast.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, speermint@ietf.org,
	"Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>,
	"Lee, Yiu" <Yiu_Lee@cable.comcast.com>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441690@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Speermint]
	I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
Thread-Index: AcgmCCFVs4dMgQEjQa6UswoCPKFizQAKc+rwAa6E3HA=
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <E1IrxTi-00020l-9s@stiedprstage1.ietf.org> A
	<45AEC6EF95942140888406588E1A66020307D7BE@PACDCEXCMB04.cable.comcast.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Well, I didn't see an 04. At the risk of repeating known issues, I will
list some immediate concerns with 03, mainly concerning terminology,
which quite frankly needs a lot of attention, not only within this draft
but for alignment between drafts. Until the terminology is sorted out
and I can get a good grasp of what is what, it is difficult to review
the remainder of the draft with any confidence.

1. "Location Server (LS): A server called upon by originating SSP, 
           either Local or Remote, to obtain the Session Establish Data 
           (SED). Often, the input to the server is an E.164 number and
the 
           SED is a SIP URI."
See separate thread discussing meaning of "SED" in the definitions
draft. The use of SED in the consolidated use cases draft is in conflict
with at least one statement in the definitions draft, where it claims
that SED is a lot more than just the SIP URI derived from original
telephone number. I don't have a strong opinion on what SED should mean,
but we must be consistent within and between drafts, since it seems to
be a fundamental concept in SPEERMINT.

2. This meaning of Location Server (LS) is in conflict with the very
similar term Location Service (LS) in RFC 3261. The SIP meaning of LS is
different - it resolves an AoR into one or more contact URIs. Since
SPEERMINT work is very much tied to SIP, it would be unfortunate to use
two terms with the same acronym and very similar expansions. Perhaps we
need to find a different term.

3. "The originating SSP's client may call the 
           Location Function using ENUM Query/Response, SIP
Invite/Redirect, 
           or other method depending on orginating SSP's infrastructure
and 
           methods available for the data being interrogated, with the 
           response format being appropriate to the Query format."
This occurs within the definition of LS. Are Location Function (defined
later in the document) and Location Server the same thing?

4. "Session Border Element (SBE) : A SBE performs signaling sanitation 
           and security tasks in the signaling plane of Session 
           establishment. Common threats may be DOS or intentionally 
           malformed packet/headers.  This device may perform NAT/PAT or

           enable far-end NAT traversal."
We also have a definition Signalling Path Border Element (SBE) in the
definitions draft. Are these meant to be the same thing? They share the
same acronym, but with different expansions and different meanings.

5. Similarly DBE.

6. "User Endpoint (UE): User Endpoint is the client that makes or 
           receives calls. UE can be sip based or non-sip based. For
non-sip 
           based UE, SM acts as a signaling gateway and translates the
non-
           sip signaling to sip signaling before sending to SBE."
Certain other organisations such (e.g., 3GPP, TISPAN) use UE to mean
"User Equipment". I haven't checked whether the definitions are the same
or different, but it might be wise to avoid any conflicts.

7. "Session Manager (SM): A SM is the home registrar of the user 
           endpoint."
In that case, what is the meaning of a-SM in the Assisting SSP Domain in
figure 1, since there are no UEs there (or if there are, they are
irrelevant to the role of the domain as an Assisting SSP Domain?

8. "Figure 1 Generalized Overview"
This is not completely general, because it shows an assisting domain but
not a transit domain.

9. "Indirect, or transit, peering refers to the establishment of either
a 
        signaling and media path or signaling path alone via one (or
more) 
        referral or transit network(s). In this case it is generally
required 
        that a trust relationship is established between the originating

        service provider and the transit network on one side, and the
transit 
        network and the termination network on the other side."
There should also be a trust relationship between transit networks, if
more than one.

10. In 4.1 to 4.5 terms LUF, LF, SF and MF are defined, but it is not
clear how they relate to the terms already defined (e.g., SM, LS, SBE,
SDE) and there is no picture to show how they relate to each other and
to those other terms. In fact the use cases themselves seem to make use
of the terms defined earlier, mostly, so why do we need these additional
terms?

John




> -----Original Message-----
> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] 
> Sent: 13 November 2007 20:18
> To: speermint@ietf.org; Uzelac, Adam; Lee, Yiu
> Subject: RE: [Speermint] 
> I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
> 
> I think you guys indicated that you planned a quick -04 update in the
> next 1 to 2 weeks to clean up some things in the draft and ensure that
> this is in sync with the terminology I-D.  It would be 
> wonderful to see
> a -04 turned around in advance of IETF 70.  Then any feedback 
> from IETF
> 70 can go into a -05 just after or during the week of IETF 70, after
> which we can issue a WGLC.
> 
> I am copying the WG on this so everyone understands that we need to
> press ahead on this I-D rapidly, and that we'll be reviewing in the
> great detail at IETF 70.  So please ensure you read the I-D and get
> comments to the authors before IETF 70 (preferred) or at IETF 70. 
> 
> Thanks
> Jason
> 
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] 
> > Sent: Tuesday, November 13, 2007 10:15 AM
> > To: i-d-announce@ietf.org
> > Cc: speermint@ietf.org
> > Subject: [Speermint] I-D 
> > ACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt 
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > This draft is a work item of the Session PEERing for 
> > Multimedia INTerconnect Working Group of the IETF.
> > 
> > 	Title		: VoIP SIP Peering Use Cases
> > 	Author(s)	: A. Uzelac, et al.
> > 	Filename	: 
> > draft-ietf-speermint-voip-consolidated-usecases-03.txt
> > 	Pages		: 22
> > 	Date		: 2007-11-13
> > 	
> > This document will capture VoIP use case for SIP Peering.  It is a 
> >         consolidation of Speermint use cases drafts. This 
> > document depicts 
> >         many common VoIP peering use cases. These use cases 
> > are categorized 
> >         into three types: Direct, Indirect and Assisted. They 
> > are not the 
> >         exhaust set of use cases but the most common use 
> > cases deployed in 
> >         production today. This document captures them to 
> > provide a reference.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-
> > consolidated-usecases-03.txt
> > 
> > To remove yourself from the I-D Announcement list, send a 
> > message to i-d-announce-request@ietf.org with the word 
> > unsubscribe in the body of the message. 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login 
> > with the username "anonymous" and a password of your e-mail 
> > address. After logging in, type "cd internet-drafts" and then 
> > "get draft-ietf-speermint-voip-consolidated-usecases-03.txt".
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE 
> > /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas
> > es-03.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> > mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 
> > Below is the data which will enable a MIME compliant mail 
> > reader implementation to automatically retrieve the ASCII 
> > version of the Internet-Draft.
> > 
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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



From speermint-bounces@ietf.org Fri Nov 23 12:26:39 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvcIJ-0001si-Jx; Fri, 23 Nov 2007 12:26:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvcII-0001sY-2I
	for speermint@ietf.org; Fri, 23 Nov 2007 12:26:22 -0500
Received: from pacdcimo01.cable.comcast.com ([24.40.8.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvcIF-0007f7-0f
	for speermint@ietf.org; Fri, 23 Nov 2007 12:26:22 -0500
Received: from ([10.52.116.30])
	by pacdcimo01.cable.comcast.com with ESMTP  id KP-BXT38.10396466;
	Fri, 23 Nov 2007 12:26:00 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PAOAKEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 12:26:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint]
	I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
Date: Fri, 23 Nov 2007 12:25:56 -0500
Message-ID: <45AEC6EF95942140888406588E1A660203340BDA@PACDCEXCMB04.cable.comcast.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441690@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint]
	I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
Thread-Index: AcgmCCFVs4dMgQEjQa6UswoCPKFizQAKc+rwAa6E3HAAQPZJgA==
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
To: "Elwell, John" <john.elwell@siemens.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>, "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>
X-OriginalArrivalTime: 23 Nov 2007 17:26:00.0176 (UTC)
	FILETIME=[EA555F00:01C82DF5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6907f330301e69261fa73bed91449a20
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Hi John,=20

Adam and I are working on 04 and will release very soon. Comments
inline:=20

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]=20
Sent: Thursday, November 22, 2007 5:24 AM
To: Livingood, Jason; speermint@ietf.org; Uzelac, Adam; Lee, Yiu
Subject: RE: [Speermint]
I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt

Well, I didn't see an 04. At the risk of repeating known issues, I will
list some immediate concerns with 03, mainly concerning terminology,
which quite frankly needs a lot of attention, not only within this draft
but for alignment between drafts. Until the terminology is sorted out
and I can get a good grasp of what is what, it is difficult to review
the remainder of the draft with any confidence.

1. "Location Server (LS): A server called upon by originating SSP,=20
           either Local or Remote, to obtain the Session Establish Data=20
           (SED). Often, the input to the server is an E.164 number and
the=20
           SED is a SIP URI."
See separate thread discussing meaning of "SED" in the definitions
draft. The use of SED in the consolidated use cases draft is in conflict
with at least one statement in the definitions draft, where it claims
that SED is a lot more than just the SIP URI derived from original
telephone number. I don't have a strong opinion on what SED should mean,
but we must be consistent within and between drafts, since it seems to
be a fundamental concept in SPEERMINT.

	[YL]  Agreed that the usecase draft and term draft must keep in
sync. In the content of=20
		consolidated-usecase draft, we focus on discussing voip
usecases, so it is true that 			input is often TN and
output is often sip-uri. We didn't limit the input "must be" TN=20
		and output must be "sip-uri". Can you explain to us what
exactly the conflict is?

2. This meaning of Location Server (LS) is in conflict with the very
similar term Location Service (LS) in RFC 3261. The SIP meaning of LS is
different - it resolves an AoR into one or more contact URIs. Since
SPEERMINT work is very much tied to SIP, it would be unfortunate to use
two terms with the same acronym and very similar expansions. Perhaps we
need to find a different term.

	[YL]	3261 defined Location Service an abstract service. We
define the term Location Server=20
		to deliver both LUF and LF. If seems you suggest to
eliminate LS and use LUF
		and LF to replace LS. Am I right?

3. "The originating SSP's client may call the=20
           Location Function using ENUM Query/Response, SIP
Invite/Redirect,=20
           or other method depending on orginating SSP's infrastructure
and=20
           methods available for the data being interrogated, with the=20
           response format being appropriate to the Query format."
This occurs within the definition of LS. Are Location Function (defined
later in the document) and Location Server the same thing?

4. "Session Border Element (SBE) : A SBE performs signaling sanitation=20
           and security tasks in the signaling plane of Session=20
           establishment. Common threats may be DOS or intentionally=20
           malformed packet/headers.  This device may perform NAT/PAT or

           enable far-end NAT traversal."
We also have a definition Signalling Path Border Element (SBE) in the
definitions draft. Are these meant to be the same thing? They share the
same acronym, but with different expansions and different meanings.

	[YL]	Thanks for the catch. The term was changed in the
term-draft. We will update ours.

5. Similarly DBE.

	[YL] Same for DBE.

6. "User Endpoint (UE): User Endpoint is the client that makes or=20
           receives calls. UE can be sip based or non-sip based. For
non-sip=20
           based UE, SM acts as a signaling gateway and translates the
non-
           sip signaling to sip signaling before sending to SBE."

Certain other organisations such (e.g., 3GPP, TISPAN) use UE to mean
"User Equipment". I haven't checked whether the definitions are the same
or different, but it might be wise to avoid any conflicts.

	[YL] Thanks we will update the name to User=20

7. "Session Manager (SM): A SM is the home registrar of the user=20
           endpoint."
In that case, what is the meaning of a-SM in the Assisting SSP Domain in
figure 1, since there are no UEs there (or if there are, they are
irrelevant to the role of the domain as an Assisting SSP Domain?

	[YL]	We cleaned this up in 04.

8. "Figure 1 Generalized Overview"
This is not completely general, because it shows an assisting domain but
not a transit domain.

	[YL]	We are working on the term "transit" and "assisting". In
my understanding, I see a
		transit domain is the same as assisting domain because
the transit needs to help to
		route the message (SF). It is kind of assisting, isn't
it?

9. "Indirect, or transit, peering refers to the establishment of either
a=20
        signaling and media path or signaling path alone via one (or
more)=20
        referral or transit network(s). In this case it is generally
required=20
        that a trust relationship is established between the originating

        service provider and the transit network on one side, and the
transit=20
        network and the termination network on the other side."
There should also be a trust relationship between transit networks, if
more than one.

	[YL]	Agreed

10. In 4.1 to 4.5 terms LUF, LF, SF and MF are defined, but it is not
clear how they relate to the terms already defined (e.g., SM, LS, SBE,
SDE) and there is no picture to show how they relate to each other and
to those other terms. In fact the use cases themselves seem to make use
of the terms defined earlier, mostly, so why do we need these additional
terms?

	[YL] We are in the middle of cleaning up all the terms. We hope
to release it very soon.

John




> -----Original Message-----
> From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
> Sent: 13 November 2007 20:18
> To: speermint@ietf.org; Uzelac, Adam; Lee, Yiu
> Subject: RE: [Speermint]
> I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
>=20
> I think you guys indicated that you planned a quick -04 update in the=20
> next 1 to 2 weeks to clean up some things in the draft and ensure that

> this is in sync with the terminology I-D.  It would be wonderful to=20
> see a -04 turned around in advance of IETF 70.  Then any feedback from

> IETF 70 can go into a -05 just after or during the week of IETF 70,=20
> after which we can issue a WGLC.
>=20
> I am copying the WG on this so everyone understands that we need to=20
> press ahead on this I-D rapidly, and that we'll be reviewing in the=20
> great detail at IETF 70.  So please ensure you read the I-D and get=20
> comments to the authors before IETF 70 (preferred) or at IETF 70.
>=20
> Thanks
> Jason
>=20
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Tuesday, November 13, 2007 10:15 AM
> > To: i-d-announce@ietf.org
> > Cc: speermint@ietf.org
> > Subject: [Speermint] I-D
> > ACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
> >=20
> > A New Internet-Draft is available from the on-line Internet-Drafts=20
> > directories.
> > This draft is a work item of the Session PEERing for Multimedia=20
> > INTerconnect Working Group of the IETF.
> >=20
> > 	Title		: VoIP SIP Peering Use Cases
> > 	Author(s)	: A. Uzelac, et al.
> > 	Filename	:=20
> > draft-ietf-speermint-voip-consolidated-usecases-03.txt
> > 	Pages		: 22
> > 	Date		: 2007-11-13
> > =09
> > This document will capture VoIP use case for SIP Peering.  It is a=20
> >         consolidation of Speermint use cases drafts. This document=20
> > depicts
> >         many common VoIP peering use cases. These use cases are=20
> > categorized
> >         into three types: Direct, Indirect and Assisted. They are=20
> > not the
> >         exhaust set of use cases but the most common use cases=20
> > deployed in
> >         production today. This document captures them to provide a=20
> > reference.
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-
> > consolidated-usecases-03.txt
> >=20
> > To remove yourself from the I-D Announcement list, send a message to

> > i-d-announce-request@ietf.org with the word unsubscribe in the body=20
> > of the message.
> > You can also visit
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >=20
> > Internet-Drafts are also available by anonymous FTP. Login with the=20
> > username "anonymous" and a password of your e-mail address. After=20
> > logging in, type "cd internet-drafts" and then "get=20
> > draft-ietf-speermint-voip-consolidated-usecases-03.txt".
> >=20
> > A list of Internet-Drafts directories can be found in=20
> > http://www.ietf.org/shadow.html or=20
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >=20
> > Internet-Drafts can also be obtained by e-mail.
> >=20
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE
> > /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas
> > es-03.txt".
> > =09
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail=20
> > readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >=20
> > Below is the data which will enable a MIME compliant mail reader=20
> > implementation to automatically retrieve the ASCII version of the=20
> > Internet-Draft.
> >=20
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

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



From speermint-bounces@ietf.org Fri Nov 23 14:02:22 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvdnB-0006o5-HJ; Fri, 23 Nov 2007 14:02:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IvdnA-0006nz-Ep
	for speermint@ietf.org; Fri, 23 Nov 2007 14:02:20 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivdmz-0002mn-02
	for speermint@ietf.org; Fri, 23 Nov 2007 14:02:20 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JRZ00FB82SDAE@siemenscomms.co.uk> for
	speermint@ietf.org; Fri, 23 Nov 2007 18:45:50 +0000 (GMT)
Date: Fri, 23 Nov 2007 18:45:49 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Speermint]
	I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
In-reply-to: A
	<45AEC6EF95942140888406588E1A660203340BDA@PACDCEXCMB04.cable.comcast.com>
To: "Lee, Yiu" <Yiu_Lee@cable.comcast.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	speermint@ietf.org, "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441A39@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-Topic: [Speermint]
	I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
Thread-Index: AcgmCCFVs4dMgQEjQa6UswoCPKFizQAKc+rwAa6E3HAAQPZJgAADzJKg
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <0D5F89FAC29E2C41B98A6A762007F5D0441690@GBNTHT12009MSX.gb002.siemens.net>
	A
	<45AEC6EF95942140888406588E1A660203340BDA@PACDCEXCMB04.cable.comcast.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Lee,

My further responses in-line.

John 

> -----Original Message-----
> From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] 
> Sent: 23 November 2007 17:26
> To: Elwell, John; Livingood, Jason; speermint@ietf.org; Uzelac, Adam
> Subject: RE: [Speermint] 
> I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
> 
> Hi John, 
> 
> Adam and I are working on 04 and will release very soon. Comments
> inline: 
> 
> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com] 
> Sent: Thursday, November 22, 2007 5:24 AM
> To: Livingood, Jason; speermint@ietf.org; Uzelac, Adam; Lee, Yiu
> Subject: RE: [Speermint]
> I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
> 
> Well, I didn't see an 04. At the risk of repeating known 
> issues, I will
> list some immediate concerns with 03, mainly concerning terminology,
> which quite frankly needs a lot of attention, not only within 
> this draft
> but for alignment between drafts. Until the terminology is sorted out
> and I can get a good grasp of what is what, it is difficult to review
> the remainder of the draft with any confidence.
> 
> 1. "Location Server (LS): A server called upon by originating SSP, 
>            either Local or Remote, to obtain the Session 
> Establish Data 
>            (SED). Often, the input to the server is an E.164 
> number and
> the 
>            SED is a SIP URI."
> See separate thread discussing meaning of "SED" in the definitions
> draft. The use of SED in the consolidated use cases draft is 
> in conflict
> with at least one statement in the definitions draft, where it claims
> that SED is a lot more than just the SIP URI derived from original
> telephone number. I don't have a strong opinion on what SED 
> should mean,
> but we must be consistent within and between drafts, since it seems to
> be a fundamental concept in SPEERMINT.
> 
> 	[YL]  Agreed that the usecase draft and term draft must keep in
> sync. In the content of 
> 		consolidated-usecase draft, we focus on discussing voip
> usecases, so it is true that 			input is often TN and
> output is often sip-uri. We didn't limit the input "must be" TN 
> 		and output must be "sip-uri". Can you explain to us what
> exactly the conflict is?
[JRE] The conflict is as follows. The use cases draft says the SIP-URI
is the SED. The terminology draft section 3.3 says that SED is a lot
more than just the SIP-URI and gives a whole bulleted list of things it
includes.

> 
> 2. This meaning of Location Server (LS) is in conflict with the very
> similar term Location Service (LS) in RFC 3261. The SIP 
> meaning of LS is
> different - it resolves an AoR into one or more contact URIs. Since
> SPEERMINT work is very much tied to SIP, it would be 
> unfortunate to use
> two terms with the same acronym and very similar expansions. 
> Perhaps we
> need to find a different term.
> 
> 	[YL]	3261 defined Location Service an abstract service. We
> define the term Location Server 
> 		to deliver both LUF and LF. If seems you suggest to
> eliminate LS and use LUF
> 		and LF to replace LS. Am I right?
[JRE] No, I am saying we shouldn't use the term Location Server (LS) to
mean something different from the Location Service (LS) that is defined
in RFC 3261, because it appears they mean quite different things. We
should choose a different term. I don't know whether Location Function
would do, because I didn't really understand the difference between LS
and LF - see my next point.

> 
> 3. "The originating SSP's client may call the 
>            Location Function using ENUM Query/Response, SIP
> Invite/Redirect, 
>            or other method depending on orginating SSP's 
> infrastructure
> and 
>            methods available for the data being interrogated, 
> with the 
>            response format being appropriate to the Query format."
> This occurs within the definition of LS. Are Location 
> Function (defined
> later in the document) and Location Server the same thing?
[JRE] I am asking whether these two terms are intended to be the same
thing. If they are different things, then the definition of Location
Function should be moved up to the terminology section. But then I am
not sure I appreciate the difference between the two.
By the way, shouldn't some of the terms in the terminology section be in
the terminology draft instead?

> 
> 4. "Session Border Element (SBE) : A SBE performs signaling 
> sanitation 
>            and security tasks in the signaling plane of Session 
>            establishment. Common threats may be DOS or intentionally 
>            malformed packet/headers.  This device may perform 
> NAT/PAT or
> 
>            enable far-end NAT traversal."
> We also have a definition Signalling Path Border Element (SBE) in the
> definitions draft. Are these meant to be the same thing? They 
> share the
> same acronym, but with different expansions and different meanings.
> 
> 	[YL]	Thanks for the catch. The term was changed in the
> term-draft. We will update ours.
> 
> 5. Similarly DBE.
> 
> 	[YL] Same for DBE.
> 
> 6. "User Endpoint (UE): User Endpoint is the client that makes or 
>            receives calls. UE can be sip based or non-sip based. For
> non-sip 
>            based UE, SM acts as a signaling gateway and translates the
> non-
>            sip signaling to sip signaling before sending to SBE."
> 
> Certain other organisations such (e.g., 3GPP, TISPAN) use UE to mean
> "User Equipment". I haven't checked whether the definitions 
> are the same
> or different, but it might be wise to avoid any conflicts.
> 
> 	[YL] Thanks we will update the name to User 
> 
> 7. "Session Manager (SM): A SM is the home registrar of the user 
>            endpoint."
> In that case, what is the meaning of a-SM in the Assisting 
> SSP Domain in
> figure 1, since there are no UEs there (or if there are, they are
> irrelevant to the role of the domain as an Assisting SSP Domain?
> 
> 	[YL]	We cleaned this up in 04.
> 
> 8. "Figure 1 Generalized Overview"
> This is not completely general, because it shows an assisting 
> domain but
> not a transit domain.
> 
> 	[YL]	We are working on the term "transit" and "assisting". In
> my understanding, I see a
> 		transit domain is the same as assisting domain because
> the transit needs to help to
> 		route the message (SF). It is kind of assisting, isn't
> it?
[JRE] Well, if that is the case we effectively have only two scenarios -
direct and indirect/assisted. But I thought earlier discussions had
identified two orthogonal concepts - assisted and direct/indirect, and
that assisted peering (where the assisting domain does not remain on the
call path) can be used in conjunction with direct peering or with
indirect peering. If you want to collapse it, WG discussion is required.

> 
> 9. "Indirect, or transit, peering refers to the establishment 
> of either
> a 
>         signaling and media path or signaling path alone via one (or
> more) 
>         referral or transit network(s). In this case it is generally
> required 
>         that a trust relationship is established between the 
> originating
> 
>         service provider and the transit network on one side, and the
> transit 
>         network and the termination network on the other side."
> There should also be a trust relationship between transit networks, if
> more than one.
> 
> 	[YL]	Agreed
> 
> 10. In 4.1 to 4.5 terms LUF, LF, SF and MF are defined, but it is not
> clear how they relate to the terms already defined (e.g., SM, LS, SBE,
> SDE) and there is no picture to show how they relate to each other and
> to those other terms. In fact the use cases themselves seem 
> to make use
> of the terms defined earlier, mostly, so why do we need these 
> additional
> terms?
> 
> 	[YL] We are in the middle of cleaning up all the terms. We hope
> to release it very soon.
> 
> John
> 
> 
> 
> 
> > -----Original Message-----
> > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
> > Sent: 13 November 2007 20:18
> > To: speermint@ietf.org; Uzelac, Adam; Lee, Yiu
> > Subject: RE: [Speermint]
> > I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
> > 
> > I think you guys indicated that you planned a quick -04 
> update in the 
> > next 1 to 2 weeks to clean up some things in the draft and 
> ensure that
> 
> > this is in sync with the terminology I-D.  It would be wonderful to 
> > see a -04 turned around in advance of IETF 70.  Then any 
> feedback from
> 
> > IETF 70 can go into a -05 just after or during the week of IETF 70, 
> > after which we can issue a WGLC.
> > 
> > I am copying the WG on this so everyone understands that we need to 
> > press ahead on this I-D rapidly, and that we'll be reviewing in the 
> > great detail at IETF 70.  So please ensure you read the I-D and get 
> > comments to the authors before IETF 70 (preferred) or at IETF 70.
> > 
> > Thanks
> > Jason
> > 
> > > -----Original Message-----
> > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > > Sent: Tuesday, November 13, 2007 10:15 AM
> > > To: i-d-announce@ietf.org
> > > Cc: speermint@ietf.org
> > > Subject: [Speermint] I-D
> > > ACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
> > > 
> > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > directories.
> > > This draft is a work item of the Session PEERing for Multimedia 
> > > INTerconnect Working Group of the IETF.
> > > 
> > > 	Title		: VoIP SIP Peering Use Cases
> > > 	Author(s)	: A. Uzelac, et al.
> > > 	Filename	: 
> > > draft-ietf-speermint-voip-consolidated-usecases-03.txt
> > > 	Pages		: 22
> > > 	Date		: 2007-11-13
> > > 	
> > > This document will capture VoIP use case for SIP Peering. 
>  It is a 
> > >         consolidation of Speermint use cases drafts. This 
> document 
> > > depicts
> > >         many common VoIP peering use cases. These use cases are 
> > > categorized
> > >         into three types: Direct, Indirect and Assisted. They are 
> > > not the
> > >         exhaust set of use cases but the most common use cases 
> > > deployed in
> > >         production today. This document captures them to 
> provide a 
> > > reference.
> > > 
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-
> > > consolidated-usecases-03.txt
> > > 
> > > To remove yourself from the I-D Announcement list, send a 
> message to
> 
> > > i-d-announce-request@ietf.org with the word unsubscribe 
> in the body 
> > > of the message.
> > > You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > > 
> > > Internet-Drafts are also available by anonymous FTP. 
> Login with the 
> > > username "anonymous" and a password of your e-mail address. After 
> > > logging in, type "cd internet-drafts" and then "get 
> > > draft-ietf-speermint-voip-consolidated-usecases-03.txt".
> > > 
> > > A list of Internet-Drafts directories can be found in 
> > > http://www.ietf.org/shadow.html or 
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > 
> > > Internet-Drafts can also be obtained by e-mail.
> > > 
> > > Send a message to:
> > > 	mailserv@ietf.org.
> > > In the body type:
> > > 	"FILE
> > > /internet-drafts/draft-ietf-speermint-voip-consolidated-usecas
> > > es-03.txt".
> > > 	
> > > NOTE:	The mail server at ietf.org can return the document in
> > > 	MIME-encoded form by using the "mpack" utility.  To use this
> > > 	feature, insert the command "ENCODING mime" before the "FILE"
> > > 	command.  To decode the response(s), you will need "munpack" or
> > > 	a MIME-compliant mail reader.  Different MIME-compliant mail 
> > > readers
> > > 	exhibit different behavior, especially when dealing with
> > > 	"multipart" MIME messages (i.e. documents which have been split
> > > 	up into multiple messages), so check your local documentation on
> > > 	how to manipulate these messages.
> > > 
> > > Below is the data which will enable a MIME compliant mail reader 
> > > implementation to automatically retrieve the ASCII version of the 
> > > Internet-Draft.
> > > 
> > 
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> > 
> 

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



From speermint-bounces@ietf.org Sat Nov 24 06:36:55 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvtJc-000054-29; Sat, 24 Nov 2007 06:36:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IvtJa-0008VC-EW; Sat, 24 Nov 2007 06:36:50 -0500
Received: from [202.99.23.227] (helo=people.com.cn)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1IvtJW-0006zg-6z; Sat, 24 Nov 2007 06:36:50 -0500
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8)
	with SMTP id jm1b0474817e8; Sat, 24 Nov 2007 19:49:43 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id jm494741aa1e; Mon, 19 Nov 2007 22:06:48 +0800
Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC
	2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 22:06:48 +0800
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu70o-0002O5-4F; Mon, 19 Nov 2007 08:50:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iu70k-0002NF-8P; Mon, 19 Nov 2007 08:50:02 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Iu70j-0001fL-S0; Mon, 19 Nov 2007 08:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id BC89C26E60;
	Mon, 19 Nov 2007 13:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1Iu70j-0004oQ-LE; Mon, 19 Nov 2007 08:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1Iu70j-0004oQ-LE@stiedprstage1.ietf.org>
Date: Mon, 19 Nov 2007 08:50:01 -0500
X-Spam-Score: -1.4 (-)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
X-BeenThere: i-d-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: Internet-Drafts@ietf.org
X-Auto-Forward: jaglee@people.com.cn
 jag@kw.com.cn
X-Spam-Score: 2.8 (++)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: speermint@ietf.org
Subject: [Speermint] I-D Action:draft-ietf-speermint-requirements-03.txt 
X-BeenThere: speermint@ietf.org
Reply-To: internet-drafts@ietf.org
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

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.


	Title           : SPEERMINT Requirements for SIP-based VoIP Interconnection
	Author(s)       : J. Mule
	Filename        : draft-ietf-speermint-requirements-03.txt
	Pages           : 29
	Date            : 2007-11-19

A number of use cases have been identified for session peering of
voice and other types of multimedia traffic.  This memo captures some
of the requirements that enable these use case scenarios.  In its
current version, this document describes both general and use case
specific requirements for session peering for multimedia
interconnect.  It is intended to become an informational document
linking the use cases with potential protocol solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-03.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-speermint-requirements-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-requirements-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-11-19084053.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-speermint-requirements-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-speermint-requirements-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-19084053.I-D\@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--





From speermint-bounces@ietf.org Sun Nov 25 12:36:20 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwLOy-0007v1-0s; Sun, 25 Nov 2007 12:36:16 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwLOs-0007ua-Qn
	for speermint@ietf.org; Sun, 25 Nov 2007 12:36:10 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwLOr-0005mt-Q4
	for speermint@ietf.org; Sun, 25 Nov 2007 12:36:10 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 25 Nov 2007 12:36:09 -0500
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAPHa9b1005219; 
	Sun, 25 Nov 2007 12:36:09 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAPHa8xX003054; 
	Sun, 25 Nov 2007 17:36:08 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 25 Nov 2007 12:36:08 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] [wg-business]
	WGLCfordraft-ietf-speermint-terminology-13
Date: Sun, 25 Nov 2007 12:36:28 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E303F1B775@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441618@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] [wg-business]
	WGLCfordraft-ietf-speermint-terminology-13
Thread-Index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gGF/7KgAPpZYxAADIiegADBqm6A
References: A<45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com><0D5F89FAC29E2C41B98A6A762007F5D0440FBE@GBNTHT12009MSX.gb002.siemens.net>A<45AEC6EF95942140888406588E1A66020307D94F@PACDCEXCMB04.cable.comcast.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441618@GBNTHT12009MSX.gb002.siemens.net>
From: "Michael Hammer (mhammer)" <mhammer@cisco.com>
To: "Elwell, John" <john.elwell@siemens.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>, "Malas, Daryl" <Daryl.Malas@Level3.com>,
	"Dave Meyer" <dmm@1-4-5.net>
X-OriginalArrivalTime: 25 Nov 2007 17:36:08.0382 (UTC)
	FILETIME=[A9ADBDE0:01C82F89]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9446; t=1196012169;
	x=1196876169; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mhammer@cisco.com;
	z=From:=20=22Michael=20Hammer=20(mhammer)=22=20<mhammer@cisco.com>
	|Subject:=20RE=3A=20[Speermint]=20[wg-business]=20WGLCfordraft-ietf-speer
	mint-terminology-13 |Sender:=20
	|To:=20=22Elwell, =20John=22=20<john.elwell@siemens.com>,
	=0A=20=20=20=20=2 0=20=20=20=22Livingood,
	=20Jason=22=20<Jason_Livingood@cable.comcast.com>, =
	0A=20=20=20=20=20=20=20=20<speermint@ietf.org>, =20=22Malas,
	=20Daryl=22=20< Daryl.Malas@Level3.com>,
	=0A=20=20=20=20=20=20=20=20=22Dave=20Meyer=22=20<d
	mm@1-4-5.net>; bh=ZJRXuQB1TOMoJ7buNa08KF66PFCz2CYnvIfjGHsvun0=;
	b=Wn4TDJWeAIRVDE3xogVaTbdNth5DWuQg5nJXJp1XvgkPcIrAXJfvwyxdd8Cl7yS6LuFC7XWt
	7yQLToWM1V+Njb/u8eR+uSsXbKsSKvoHeyHa8AUh5/np80daHuVferim;
Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ed68cc91cc637fea89623888898579ba
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Part of the problem here may be trying to keep a clear separation
between the work of ENUM and SPEERMINT. =20

The ENUM group defines a mechanism that can be used in many ways.  Input
an E.164 and output some value.  That value could be another E.164 or a
SIP URI.  Even when a SIP URI, the result could be pointing to another
registry, some database of a federation or carrier, or an ingress GW to
deliver the call to.  So the ENUM (or resulting DNS) mechanisms may need
to be invoked recursively before it is time to send the SIP INVITE to
the ingress GW of the terminating SP.=20

The SPEERMINT group is attempting to define the overall process within
which the ENUM gets used, leading to a point at which the SIP, SIPPING,
BLISS, MMUSIC, and AVT groups' work takes over, such as the handling of
the SIP messages and the specification of RTP delivery point in the SDP.

We originally tried to describe this as a series of peeling the onion
and discovering successively more granular information and ending with a
high success rate for delivering the call from a given originating
carrier (possibly through a transit carrier) to the terminating carrier
without the "can't get there from here" problem due to lack of full-mesh
interconnection arrangements between SP.

So, SPEERMINT may need to define requirements for the ENUM group to
define more than one output type for SPEERMINT to use.

Mike


> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]=20
> Sent: Wednesday, November 21, 2007 4:08 PM
> To: Livingood, Jason; speermint@ietf.org; Malas, Daryl; Dave Meyer
> Subject: RE: [Speermint] [wg-business]=20
> WGLCfordraft-ietf-speermint-terminology-13
>=20
> Jason,
>=20
> Thanks for the invitation. I will not make a text proposal at=20
> present, but a general proposal how to solve it.
>=20
> Basically, I think it would make more sense if SED were the=20
> data you ended up with at the end of the SPEERMINT process.
>=20
> I think  the following existing statement:=20
> "Note that in Figure 1, Session Establishment Data (SED), is the data=20
>    used to route a call to the called domain's ingress point (see=20
>    Section 3.3 for additional detail)."
> Would then be correct, but the position of SED in figure 1=20
> would be wrong, because it looks like it is intended to be=20
> input data to the look-up. Also in figure 1, I think the=20
> processes of federation detection, policy look-up and service=20
> location are all things that help to construct the SED. So=20
> figure 1 would need some rework. However, to me the=20
> conventions used in figure 1 are unclear, so I don't know how=20
> it should be represented. But basically it should show the following
> things:
>  - the input to the SPEERMINT process is the SIP URI;
>  - the process itself comprises look-up to achieve federation=20
> detection, policy and service location;
>  - the output from the SPEERMINT process is the SED.
>=20
> I think the following existing statement is wrong:
> "As illustrated in Figure 1, the ENUM Working Group is primarily=20
>    concerned with the acquisition of SED while the SPEERMINT Working=20
>    Group is focused on the use of such SED in routing session=20
> signaling=20
>    requests. Importantly, the SED can be derived from ENUM (i.e., an=20
>    E.164 DNS entry) or via any other mechanism available to the user.=20
>    Finally, note that the term "call" is being used here in the most=20
>    general sense, i.e., call routing and session routing are used=20
>    interchangeably."
> Because this treats SED as input, not as output from the process.
>=20
> I think the following existing statement:
> "More specifically, the SED is the set of parameters that the=20
> outgoing=20
>    SBEs need to complete the call, and may include:"
> and the bullets that follow it are correct, because they seem=20
> to describe the output from the process.
>=20
> I haven't cross-checked whether this would align with usage=20
> of SED in other documents.
>=20
> John
>=20
> > -----Original Message-----
> > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
> > Sent: 21 November 2007 14:58
> > To: Elwell, John; speermint@ietf.org; Malas, Daryl; Dave Meyer
> > Subject: RE: [Speermint] [wg-business] WGLC
> > fordraft-ietf-speermint-terminology-13
> >=20
> > It is easy to identify problems in any document.  ;-) =20
> We're open to=20
> > any suggestion on how to resolve this by you.  Please make=20
> a proposal=20
> > to the list.
> >=20
> > Thanks
> > Jason
> >=20
> > > -----Original Message-----
> > > From: Elwell, John [mailto:john.elwell@siemens.com]
> > > Sent: Friday, November 16, 2007 10:43 AM
> > > To: Livingood, Jason; speermint@ietf.org; Malas, Daryl; Dave Meyer
> > > Subject: RE: [Speermint] [wg-business] WGLC
> > > fordraft-ietf-speermint-terminology-13
> > >=20
> > > I still think the concept of SED is confusing. On the one hand it=20
> > > says:
> > > "   As illustrated in Figure 1, the ENUM Working Group is=20
> primarily=20
> > >    concerned with the acquisition of SED while the
> > SPEERMINT Working
> > >    Group is focused on the use of such SED in routing session=20
> > > signaling
> > >    requests. Importantly, the SED can be derived from ENUM
> > (i.e., an
> > >    E.164 DNS entry) or via any other mechanism available to
> > the user."
> > > This clearly says that SED is input to the SPEERMINT=20
> process and can=20
> > > be provided by the ENUM process. As far as I know, the=20
> ENUM process=20
> > > will only provide a SIP URI.
> > >=20
> > > On the other hand, it states:
> > > "   More specifically, the SED is the set of parameters that the
> > > outgoing=20
> > >    SBEs need to complete the call, and may include:=20
> > >=20
> > >      . A destination SIP URI
> > >=20
> > >      . A SIP proxy to send the INVITE to, including
> > >=20
> > >           o  Fully Qualified Domain Name (FQDN)
> > >=20
> > >           o  Port
> > >=20
> > >           o  Transport Protocol (UDP/TCP/TLS [9/10/11])
> > >=20
> > >      . Security Parameters, including
> > >=20
> > >           o  TLS certificate to use
> > >=20
> > >           o  TLS certificate to expect
> > >=20
> > >           o  TLS certificate verification setting
> > >=20
> > >      . Optional resource control parameters such as
> > >=20
> > >           o  Limits on the total number of call initiations
> > to a peer
> > >=20
> > >           o  Limits on SIP transactions/second "
> > >=20
> > > This is clearly in conflict, since it is a lot more than just the=20
> > > SIP URI and also appears to include a lot of data that is output=20
> > > from, rather than input to, the SPEERMINT process.
> > > =20
> > > John
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: Livingood, Jason=20
> [mailto:Jason_Livingood@cable.comcast.com]
> > > > Sent: 08 November 2007 21:23
> > > > To: speermint@ietf.org
> > > > Subject: [Speermint] [wg-business] WGLC for
> > > > draft-ietf-speermint-terminology-13
> > > >=20
> > > >=20
> > > > 	Title           : SPEERMINT Terminology
> > > > 	Author(s)       : D. Malas, D. Meyer
> > > > 	Filename        :=20
> draft-ietf-speermint-terminology-13.txt
> > > > 	Pages           : 13
> > > > 	Date            : 2007-11-08
> > > > =09
> > > > This document defines the terminology that is to be used in
> > > describing
> > > > Session PEERing for Multimedia INTerconnect (SPEERMINT).
> > > >=20
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi
> > > > nology-13.
> > > > txt
> > > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > The intent of the last call is to solicit comments before
> > > submitting
> > > > the ID to the IESG.
> > > >=20
> > > > The purpose of a working group Last Call is in the style of
> > > "speak now
> > > > or forever hold your peace" in case there are fundamental
> > > objections
> > > > which have not gotten previous or adequate discussion, or
> > > minor errors
> > > > which need correction.
> > > >=20
> > > > Working group last call will extend for 2 weeks from today,
> > > 8 November
> > > > 2007, until 22 November 2007.  Please note that this is
> > the second
> > > > WGLC on this document.
> > > >=20
> > > > Please post any comments in reply to the list, as well as to the
> > > > editor(s) of this draft.
> > > >=20
> > > > Regards,
> > > >=20
> > > > Jason & Dave
> > > >=20
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > Speermint@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > >=20
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > Speermint@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > >=20
> > >=20
> >=20
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

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



From speermint-bounces@ietf.org Sun Nov 25 15:15:57 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwNtU-0003Z4-58; Sun, 25 Nov 2007 15:15:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwNtS-0003Yw-Tc
	for speermint@ietf.org; Sun, 25 Nov 2007 15:15:54 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwNtP-0006Pa-9T
	for speermint@ietf.org; Sun, 25 Nov 2007 15:15:54 -0500
Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian))
	id 1IwNtO-0007FD-00
	for <speermint@ietf.org>; Sun, 25 Nov 2007 21:15:50 +0100
Date: Sun, 25 Nov 2007 21:15:50 +0100
From: Otmar Lendl <lendl@nic.at>
To: speermint@ietf.org
Subject: Re: [Speermint] [wg-business]
	WGLCfordraft-ietf-speermint-terminology-13
Message-ID: <20071125201549.GA27827@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org
References: <0D5F89FAC29E2C41B98A6A762007F5D0441618@GBNTHT12009MSX.gb002.siemens.net>
	<072C5B76F7CEAB488172C6F64B30B5E303F1B775@xmb-rtp-20b.amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E303F1B775@xmb-rtp-20b.amer.cisco.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

On 2007/11/25 18:11, "Michael Hammer (mhammer)" <mhammer@cisco.com> wrote:
> 
> So, SPEERMINT may need to define requirements for the ENUM group to
> define more than one output type for SPEERMINT to use.
> 

As your correctly say, ENUM does not need to return a SIP AoR.

On the other hand, _if_ we assume (and I do) that the speermint peering
process MUST also work with URI-based calls (where the user never dialed
a telephone number, but directly a SIP URI like sip:user@example.com
instead), then pushing more work (peering discovery / routing /
source-dependent ingress points / ...) into the ENUM step is foolish as
we need to replicate the same mechanisms on the domain level for these
cases.

/ol
-- 
/ Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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



From speermint-bounces@ietf.org Mon Nov 26 08:34:23 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwe6Q-0008TM-4W; Mon, 26 Nov 2007 08:34:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwe6P-0008OD-BD
	for speermint@ietf.org; Mon, 26 Nov 2007 08:34:21 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwe6I-0005vj-8h
	for speermint@ietf.org; Mon, 26 Nov 2007 08:34:20 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lAQDYBH14941; Mon, 26 Nov 2007 13:34:11 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint]	I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
Date: Mon, 26 Nov 2007 08:34:01 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA314CB028A@zcarhxm0.corp.nortel.com>
In-Reply-To: <45AEC6EF95942140888406588E1A660203340BDA@PACDCEXCMB04.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint]	I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
thread-index: AcgmCCFVs4dMgQEjQa6UswoCPKFizQAKc+rwAa6E3HAAQPZJgACPaw/w
References: <0D5F89FAC29E2C41B98A6A762007F5D0441690@GBNTHT12009MSX.gb002.siemens.net>
	<45AEC6EF95942140888406588E1A660203340BDA@PACDCEXCMB04.cable.comcast.com>
From: "James McEachern" <jmce@nortel.com>
To: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>, <speermint@ietf.org>
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Some additional comments inline...

Jim McEachern

-----Original Message-----
From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20
Sent: Friday, November 23, 2007 12:26 PM
To: Elwell, John; Livingood, Jason; speermint@ietf.org; Uzelac, Adam
Subject: RE: [Speermint]
I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt

Hi John,=20

Adam and I are working on 04 and will release very soon. Comments
inline:=20

---- snip ----

1. "Location Server (LS): A server called upon by originating SSP,
either Local or Remote, to obtain the Session Establish Data (SED).
Often, the input to the server is an E.164 number and the SED is a SIP
URI."


See separate thread discussing meaning of "SED" in the definitions
draft. The use of SED in the consolidated use cases draft is in conflict
with at least one statement in the definitions draft, where it claims
that SED is a lot more than just the SIP URI derived from original
telephone number. I don't have a strong opinion on what SED should mean,
but we must be consistent within and between drafts, since it seems to
be a fundamental concept in SPEERMINT.

[YL]  Agreed that the usecase draft and term draft must keep in sync. In
the content of consolidated-usecase draft, we focus on discussing voip
usecases, so it is true that input is often TN and output is often
sip-uri. We didn't limit the input "must be" TN and output must be
"sip-uri". Can you explain to us what exactly the conflict is?

[jmce] Having spent the weekend going over these drafts, I can explain
the conflict.  This definition says "the SED is a SIP URI".  However in
the definitions draft says "...the SED is the set of parameters that the
outgoing SBEs need to complete the call, and may include ... Port ...
Transport Protocol ..."  The definition in the Terminology draft
continues to list several other parameters that clearly show the SED my
begin with the SIP URI, but is not just the SIP URI (which is what this
seems to say).  If you look at the description of the Location Function
in the Architecture Draft, it also indicates that the SED is more than
the SIP URI.  Specifically it says "Purpose is to develop ... SED by
discovering the ... SF and the end user's reachable host (IP address and
port)."  I'd suggest that you consider using the text from the
Architecture draft.

--- snip ----=20

=20

7. "Session Manager (SM): A SM is the home registrar of the user=20
           endpoint."
In that case, what is the meaning of a-SM in the Assisting SSP Domain in
figure 1, since there are no UEs there (or if there are, they are
irrelevant to the role of the domain as an Assisting SSP Domain?

	[YL]	We cleaned this up in 04.

[jmce] I note that the term Session Manager (SM) is used in this draft
and in the Architecture draft, yet is not defined in the Terminology
draft (or anywhere else that I can find, for that matter).  Would it be
appropriate to add this definition to the Terminology draft?


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



From speermint-bounces@ietf.org Mon Nov 26 10:26:09 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwfqa-0005cV-MG; Mon, 26 Nov 2007 10:26:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwfqa-0005cL-6l
	for speermint@ietf.org; Mon, 26 Nov 2007 10:26:08 -0500
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwfqT-0000LF-MU
	for speermint@ietf.org; Mon, 26 Nov 2007 10:26:08 -0500
Received: from ([10.52.116.31])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-NTF18.49184972;
	Mon, 26 Nov 2007 10:25:47 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PAOAKEXCSMTP02.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 10:25:47 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Nov 2007 10:25:47 -0500
Message-ID: <45AEC6EF95942140888406588E1A66020307D98B@PACDCEXCMB04.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [wg-business] Draft IETF 70 Agenda
Thread-Index: AcgwQJ5BEzVXT830RqyuoCRyzKZtvQ==
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: <speermint@ietf.org>
X-OriginalArrivalTime: 26 Nov 2007 15:25:47.0271 (UTC)
	FILETIME=[9E58A970:01C83040]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Subject: [Speermint] [wg-business] Draft IETF 70 Agenda
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

We've posted a draft agenda.  Please advise if anyone would like to
suggest changes or additions.

http://www3.ietf.org/proceedings/07dec/agenda/speermint.txt

Regards
Jason

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



From speermint-bounces@ietf.org Mon Nov 26 10:55:31 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwgJ0-0004DH-T6; Mon, 26 Nov 2007 10:55:30 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgIy-0004Cz-Q7
	for speermint@ietf.org; Mon, 26 Nov 2007 10:55:29 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwgIx-00040v-PA
	for speermint@ietf.org; Mon, 26 Nov 2007 10:55:28 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lAQFtP013767; Mon, 26 Nov 2007 15:55:25 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] [wg-business]
	WGLC	fordraft-ietf-speermint-terminology-13
Date: Mon, 26 Nov 2007 10:55:20 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA314CB0743@zcarhxm0.corp.nortel.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441618@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] [wg-business]
	WGLC	fordraft-ietf-speermint-terminology-13
thread-index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gGF/7KgAPpZYxAADIiegADsV/Rw
References: A
	<45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0440FBE@GBNTHT12009MSX.gb002.siemens.net>
	A
	<45AEC6EF95942140888406588E1A66020307D94F@PACDCEXCMB04.cable.comcast.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441618@GBNTHT12009MSX.gb002.siemens.net>
From: "James McEachern" <jmce@nortel.com>
To: "Elwell, John" <john.elwell@siemens.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

John, Jason,
I like John's proposal for how to solve the SED ambiguity, but have not
seen a proposal for specific text yet.  At the risk of duplicating
effort, I will propose some concrete changes to the Terminology draft
that may achieve the intended effect.

1. Section 2, the final paragraph currently says:
"As illustrated in Figure 1, the ENUM Working Group is primarily=20
   concerned with the acquisition of SED while the SPEERMINT Working=20
   Group is focused on the use of such SED in routing session signaling=20
   requests. Importantly, the SED can be derived from ENUM (i.e., an=20
   E.164 DNS entry) or via any other mechanism available to the user."

Suggest this be changed to:
"As illustrated in Figure 1, the ENUM Working Group is primarily
concerned with identifying a SIP URI that corresponds to a given E.164
number, while the SPEERMINT Working Group is concerned with using that
SIP URI to acquire the SED and on the use of such SED in routing session
signaling requests.  Importantly, the SIP URI can be derived from ENUM
(i.e., an E.164 DNS entry) or via any other mechanism available to the
user."

2. Section 3.3, the first paragraph says:
"Session Establishment Data, or SED, is the data used to route a call=20
   to the next hop associated with the called domain's ingress point. A=20
   domain's ingress point can be thought of as the location derived from
the NAPTR/SRV/A record [1] that resulted from the resolution of the=20
   SED (i.e., a SIP Address of Record (AoR))."

I suggest modifying this paragraph to read:

"Session Establishment Data, or SED, is the data used to route a call=20
   to the next hop associated with the called domain's ingress point. A=20
   domain's ingress point can be thought of as the location derived from
the NAPTR/SRV/A record [1] that resulted from the resolution of the=20
   SIP URI."

3. Section 3.3 also includes a list of parameters that the SBE needs to
complete the call.  The section then provides a bullet list of
parameters that the SED "may include".  Although much of our work seems
to be around identifying an ingress SBE, there is no mention of this in
the list.  I suggest modifying the current second bullets as follows:

Current bullet:
     . A SIP proxy to send the INVITE to, including

Change to:
     . A SIP proxy or Ingress SBE to send the INVITE to, including

I believe these changes would expand the definition of SED, and better
align with the use of the term in the rest of this draft, and in other
SPEERMINT drafts.

BTW, I believe changes to figure 1 will also be required, but I'll
suggest those in another post.


Jim McEachern

  > -----Original Message-----
  > From: Elwell, John [mailto:john.elwell@siemens.com]
  > Sent: Wednesday, November 21, 2007 4:08 PM
  > To: Livingood, Jason; speermint@ietf.org; Malas, Daryl; Dave Meyer
  > Subject: RE: [Speermint] [wg-business] WGLC fordraft-ietf-speermint-
  > terminology-13
  >=20
  > Jason,
  >=20
  > Thanks for the invitation. I will not make a text proposal at
present,
  > but a general proposal how to solve it.
  >=20
  > Basically, I think it would make more sense if SED were the data you
  > ended up with at the end of the SPEERMINT process.
  >=20
  > I think  the following existing statement:
  > "Note that in Figure 1, Session Establishment Data (SED), is the
data
  >    used to route a call to the called domain's ingress point (see
  >    Section 3.3 for additional detail)."
  > Would then be correct, but the position of SED in figure 1 would be
  > wrong, because it looks like it is intended to be input data to the
  > look-up. Also in figure 1, I think the processes of federation
  > detection, policy look-up and service location are all things that
help
  > to construct the SED. So figure 1 would need some rework. However,
to me
  > the conventions used in figure 1 are unclear, so I don't know how it
  > should be represented. But basically it should show the following
  > things:
  >  - the input to the SPEERMINT process is the SIP URI;
  >  - the process itself comprises look-up to achieve federation
detection,
  > policy and service location;
  >  - the output from the SPEERMINT process is the SED.
  >=20
  > I think the following existing statement is wrong:
  > "As illustrated in Figure 1, the ENUM Working Group is primarily
  >    concerned with the acquisition of SED while the SPEERMINT Working
  >    Group is focused on the use of such SED in routing session
signaling
  >    requests. Importantly, the SED can be derived from ENUM (i.e., an
  >    E.164 DNS entry) or via any other mechanism available to the
user.
  >    Finally, note that the term "call" is being used here in the most
  >    general sense, i.e., call routing and session routing are used
  >    interchangeably."
  > Because this treats SED as input, not as output from the process.
  >=20
  > I think the following existing statement:
  > "More specifically, the SED is the set of parameters that the
outgoing
  >    SBEs need to complete the call, and may include:"
  > and the bullets that follow it are correct, because they seem to
  > describe the output from the process.
  >=20
  > I haven't cross-checked whether this would align with usage of SED
in
  > other documents.
  >=20
  > John
  >=20
  > > -----Original Message-----
  > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
  > > Sent: 21 November 2007 14:58
  > > To: Elwell, John; speermint@ietf.org; Malas, Daryl; Dave Meyer
  > > Subject: RE: [Speermint] [wg-business] WGLC
  > > fordraft-ietf-speermint-terminology-13
  > >
  > > It is easy to identify problems in any document.  ;-)  We're
  > > open to any
  > > suggestion on how to resolve this by you.  Please make a
  > > proposal to the
  > > list.
  > >
  > > Thanks
  > > Jason
  > >
  > > > -----Original Message-----
  > > > From: Elwell, John [mailto:john.elwell@siemens.com]
  > > > Sent: Friday, November 16, 2007 10:43 AM
  > > > To: Livingood, Jason; speermint@ietf.org; Malas, Daryl; Dave
Meyer
  > > > Subject: RE: [Speermint] [wg-business] WGLC
  > > > fordraft-ietf-speermint-terminology-13
  > > >
  > > > I still think the concept of SED is confusing. On the one
  > > > hand it says:
  > > > "   As illustrated in Figure 1, the ENUM Working Group is
primarily
  > > >    concerned with the acquisition of SED while the
  > > SPEERMINT Working
  > > >    Group is focused on the use of such SED in routing session
  > > > signaling
  > > >    requests. Importantly, the SED can be derived from ENUM
  > > (i.e., an
  > > >    E.164 DNS entry) or via any other mechanism available to
  > > the user."
  > > > This clearly says that SED is input to the SPEERMINT process
  > > > and can be provided by the ENUM process. As far as I know,
  > > > the ENUM process will only provide a SIP URI.
  > > >
  > > > On the other hand, it states:
  > > > "   More specifically, the SED is the set of parameters that the
  > > > outgoing
  > > >    SBEs need to complete the call, and may include:
  > > >
  > > >      . A destination SIP URI
  > > >
  > > >      . A SIP proxy to send the INVITE to, including
  > > >
  > > >           o  Fully Qualified Domain Name (FQDN)
  > > >
  > > >           o  Port
  > > >
  > > >           o  Transport Protocol (UDP/TCP/TLS [9/10/11])
  > > >
  > > >      . Security Parameters, including
  > > >
  > > >           o  TLS certificate to use
  > > >
  > > >           o  TLS certificate to expect
  > > >
  > > >           o  TLS certificate verification setting
  > > >
  > > >      . Optional resource control parameters such as
  > > >
  > > >           o  Limits on the total number of call initiations
  > > to a peer
  > > >
  > > >           o  Limits on SIP transactions/second "
  > > >
  > > > This is clearly in conflict, since it is a lot more than just
  > > > the SIP URI and also appears to include a lot of data that is
  > > > output from, rather than input to, the SPEERMINT process.
  > > >
  > > > John
  > > >
  > > >
  > > > > -----Original Message-----
  > > > > From: Livingood, Jason
[mailto:Jason_Livingood@cable.comcast.com]
  > > > > Sent: 08 November 2007 21:23
  > > > > To: speermint@ietf.org
  > > > > Subject: [Speermint] [wg-business] WGLC for
  > > > > draft-ietf-speermint-terminology-13
  > > > >
  > > > >
  > > > > 	Title           : SPEERMINT Terminology
  > > > > 	Author(s)       : D. Malas, D. Meyer
  > > > > 	Filename        :
draft-ietf-speermint-terminology-13.txt
  > > > > 	Pages           : 13
  > > > > 	Date            : 2007-11-08
  > > > >
  > > > > This document defines the terminology that is to be used in
  > > > describing
  > > > > Session PEERing for Multimedia INTerconnect (SPEERMINT).
  > > > >
  > > > > A URL for this Internet-Draft is:
  > > > > http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi
  > > > > nology-13.
  > > > > txt
  > > > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  > > > > The intent of the last call is to solicit comments before
  > > > submitting
  > > > > the ID to the IESG.
  > > > >
  > > > > The purpose of a working group Last Call is in the style of
  > > > "speak now
  > > > > or forever hold your peace" in case there are fundamental
  > > > objections
  > > > > which have not gotten previous or adequate discussion, or
  > > > minor errors
  > > > > which need correction.
  > > > >
  > > > > Working group last call will extend for 2 weeks from today,
  > > > 8 November
  > > > > 2007, until 22 November 2007.  Please note that this is
  > > the second
  > > > > WGLC on this document.
  > > > >
  > > > > Please post any comments in reply to the list, as well as to
the
  > > > > editor(s) of this draft.
  > > > >
  > > > > Regards,
  > > > >
  > > > > Jason & Dave
  > > > >
  > > > > _______________________________________________
  > > > > Speermint mailing list
  > > > > Speermint@ietf.org
  > > > > https://www1.ietf.org/mailman/listinfo/speermint
  > > > >
  > > > > _______________________________________________
  > > > > Speermint mailing list
  > > > > Speermint@ietf.org
  > > > > https://www1.ietf.org/mailman/listinfo/speermint
  > > > >
  > > >
  > >
  >=20
  > _______________________________________________
  > Speermint mailing list
  > Speermint@ietf.org
  > https://www1.ietf.org/mailman/listinfo/speermint

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



From speermint-bounces@ietf.org Mon Nov 26 11:15:19 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwgc8-0007k3-EO; Mon, 26 Nov 2007 11:15:16 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgc6-0007eB-Du
	for speermint@ietf.org; Mon, 26 Nov 2007 11:15:14 -0500
Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100]
	helo=co300216-co-outbound.avaya.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwgc6-0004WW-0a
	for speermint@ietf.org; Mon, 26 Nov 2007 11:15:14 -0500
X-IronPort-AV: E=Sophos;i="4.21,467,1188792000"; d="scan'208";a="86700214"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5])
	by co300216-co-outbound.avaya.com with ESMTP; 26 Nov 2007 11:15:13 -0500
X-IronPort-AV: E=Sophos;i="4.21,467,1188792000"; d="scan'208";a="134119296"
Received: from unknown (HELO 300815ANEX3.global.avaya.com) ([198.152.6.136])
	by co300216-co-erhwest-out.avaya.com with ESMTP;
	26 Nov 2007 11:14:33 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
Date: Mon, 26 Nov 2007 11:13:26 -0500
Message-ID: <3036F4A94122BD4AAAAB441FE88845287F7603@300815ANEX3.global.avaya.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441A39@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint]I-DACTION:draft-ietf-speermint-voip-consolidated-usecases-03.txt
Thread-Index: AcgmCCFVs4dMgQEjQa6UswoCPKFizQAKc+rwAa6E3HAAQPZJgAADzJKgAJCt1bA=
References: <0D5F89FAC29E2C41B98A6A762007F5D0441690@GBNTHT12009MSX.gb002.siemens.net>A<45AEC6EF95942140888406588E1A660203340BDA@PACDCEXCMB04.cable.comcast.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441A39@GBNTHT12009MSX.gb002.siemens.net>
From: "Rodrig, Benny (Benny)" <brodrig@avaya.com>
To: "Elwell, John" <john.elwell@siemens.com>,
	"Lee, Yiu" <Yiu_Lee@cable.comcast.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>, "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Lee,=20

>> 	[YL]	We are working on the term "transit" and "assisting". In
>> my understanding, I see a
>> 		transit domain is the same as assisting domain because
the transit=20
>> needs to help to
>> 		route the message (SF). It is kind of assisting, isn't
it?
> [JRE] Well, if that is the case we effectively have only two scenarios
-=20
> direct and indirect/assisted. But I thought earlier discussions had
identified=20
> two orthogonal concepts - assisted and direct/indirect, and that
assisted peering
> (where the assisting domain does not remain on the call path) can be
used in
> conjunction with direct peering or with indirect peering. If you want
to collapse
> it, WG discussion is required.

As John said, previous discussions seemed to conclude that Assisted was
orthogonal to direct/indirect, i.e. that Assisting is about the steps
preceding the SIP session routing (i.e. about steps 2 & 3 in Figure 4)
whereas direct vs. indirect/transit is about SIP session routing (i.e.
step 4 in Figure 2 as well as step 5 in Figure 4 for direct, vs. step 5
in Figure 3 for indirect/transit. According to that view:
- Figure 4 is fine
- the text in 5.2 should be modified to not refer to A-SSP SBE handling
the sessions.=20
- step 8 in 5.2.1 should be changed from '...through O/A/T DBE' to
'...through O/T DBE'.
- section 5.2.2 is really about indirect/transit and not about Assisted
- the indirect section 5.1.2 needs work. Steps 2 & 3 which determine the
t-SBE can probably be done either in the Orig Domain or via an Assisting
Domain. And then between step 4 and step 5 isn't there a missing step
between t-SBE and t-LS to determine the T-SBE?

Another point is On-demand which is probably also orthogonal to
direct/indirect. The way On-demand was added to section 5.1 there is now
no direct peering case which is not on-demand. Also there is
inconsistency between 5.1.1 which states there is NOT a pre-established
relationship between the domains and 5.1.1.1 which says the opposite.=20

Benny

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



From speermint-bounces@ietf.org Mon Nov 26 11:37:40 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwgxk-0006cm-TQ; Mon, 26 Nov 2007 11:37:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgxj-0006al-J3
	for speermint@ietf.org; Mon, 26 Nov 2007 11:37:35 -0500
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwgxc-0002ol-Le
	for speermint@ietf.org; Mon, 26 Nov 2007 11:37:35 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	lAQGYIk11050; Mon, 26 Nov 2007 16:34:18 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] [wg-business] WGLC
	for	draft-ietf-speermint-terminology-13
Date: Mon, 26 Nov 2007 11:37:23 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
In-Reply-To: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] [wg-business] WGLC
	for	draft-ietf-speermint-terminology-13
thread-index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gN+ALlg
References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
From: "James McEachern" <jmce@nortel.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Jason,
I realize this is after the deadline, but I went over all the drafts
again this weekend, and couldn't help but notice the inconsistencies.
(It is definitely getting better, but not quite there yet...)

I know you probably don't want to revisit figure 1, but in its current
form it seems to me that it is most definitely wrong.  For example, this
figure shows that the "Lookup of SRV/A and AAAA in DNS" is out of scope
for SPEERMINT.  This would suggest that your excellent draft on the "Use
of DNS and NAPTR Records for SPEERMINT" is entirely out of scope for
SPEERMINT.  This seems just plain wrong to me. =20
After re-reading all the drafts this weekend, it seems to me that we are
really talking about something that is better described by the following
diagram:

           E.164 number =20
                |=20
                | <--- ENUM lookup of NAPTR in Domain Name System (DNS)=20
                |
           Lookup=20
           Discovery=20
           SIP URI=20
                |=20
                | ENUM Working Group Scope=20
           =
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=20
                | SPEERMINT Working Group Scope=20
                |                                             \
                | <--- Federation Detection, Policy           |=20
                |      Lookup, and Service Location           |
                |                                             | Session
                |
|Establishment
           Hostname <--- Addressing and session establishment \ Data=20
                |                                             /(SED)

                |                                             |
                | <--- Lookup of SRV/A and AAAA in DNS        |
                |                                             |
                |                                             |
           IP address                                         |
                |                                             /
                | SPEERMINT Working Group Scope=20
           =
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=20
                | Out of scope for the SPEERMINT Working Group=20
                |
                | <--- Routing protocols, ARP [14] etc.=20
                |=20
           MAC-address=20

                  Figure 1: Session Peering Context

If this isn't the scope, then there are many other pieces that do not
really make sense.

Finally, and again I apologize for the lateness of this comment, the
definition of Service Provider in section 3.8 suggests that the term
"Service Provider" when used without the preceding "SIP" means an entity
that only provides layer 3 functionality.  This definition conflicts
with usage later in this and other documents.  (e.g. section 4.2 states:
"Layer 5 (Session) peering refers to interconnection of two service
providers...".)  We either need to add "SIP" before "service provider"
(in several places) or modify the definition slightly. =20

Perhaps change the existing text:
"A Service Provider (or SP) is defined to be an entity that provides
layer 3 (IP) transport of SIP signaling and media packets."

Change to:
"A Service Provider (or SP) is defined to be an entity that provides
layer 3 (IP) transport of SIP signaling and media packets, and may also
provide layer 5 processing of SIP signaling and media packets." =20

If that change doesn't work for people, then there are a number of other
places where I believe we need to add the work "SIP" in front of
"service provider" or we are talking about layer 5 functions being
performed by an entity that is only supposed to work at layer 3.

Jim McEachern

  > -----Original Message-----
  > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
  > Sent: Thursday, November 08, 2007 4:23 PM
  > To: speermint@ietf.org
  > Subject: [Speermint] [wg-business] WGLC for draft-ietf-speermint-
  > terminology-13
  >=20
  > 	Title           : SPEERMINT Terminology
  > 	Author(s)       : D. Malas, D. Meyer
  > 	Filename        : draft-ietf-speermint-terminology-13.txt
  > 	Pages           : 13
  > 	Date            : 2007-11-08
  >=20
  > This document defines the terminology that is to be used in
describing
  > Session PEERing for Multimedia INTerconnect (SPEERMINT).
  >=20
  > A URL for this Internet-Draft is:
  >
http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-13.
  > txt
  >
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  > The intent of the last call is to solicit comments before submitting
the
  > ID to the IESG.
  >=20
  > The purpose of a working group Last Call is in the style of "speak
now
  > or forever hold your peace" in case there are fundamental objections
  > which have not gotten previous or adequate discussion, or minor
errors
  > which need correction.
  >=20
  > Working group last call will extend for 2 weeks from today, 8
November
  > 2007, until 22 November 2007.  Please note that this is the second
WGLC
  > on this document.
  >=20
  > Please post any comments in reply to the list, as well as to the
  > editor(s) of this draft.
  >=20
  > Regards,
  >=20
  > Jason & Dave
  >=20
  > _______________________________________________
  > Speermint mailing list
  > Speermint@ietf.org
  > https://www1.ietf.org/mailman/listinfo/speermint
  >=20
  > _______________________________________________
  > Speermint mailing list
  > Speermint@ietf.org
  > https://www1.ietf.org/mailman/listinfo/speermint

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



From speermint-bounces@ietf.org Mon Nov 26 11:45:09 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iwh52-0004LA-VT; Mon, 26 Nov 2007 11:45:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwh51-0004L1-0C
	for speermint@ietf.org; Mon, 26 Nov 2007 11:45:07 -0500
Received: from zrtps0kn.nortel.com ([47.140.192.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwh4u-00033Q-03
	for speermint@ietf.org; Mon, 26 Nov 2007 11:45:06 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lAQGivv12645 for <speermint@ietf.org>; Mon, 26 Nov 2007 16:44:58 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 26 Nov 2007 11:44:55 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA314CB0907@zcarhxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SPEERMINT Peering Architecture
thread-index: AcgwS6GpAfUuJ43eQUGy1Ab95Ma5HA==
From: "James McEachern" <jmce@nortel.com>
To: <speermint@ietf.org>
X-Spam-Score: -4.0 (----)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Subject: [Speermint] SPEERMINT Peering Architecture
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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>
Content-Type: multipart/mixed; boundary="===============2031018962=="
Errors-To: speermint-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2031018962==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8304B.AD9C88A6"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8304B.AD9C88A6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Not sure if you plan to revise, or if this is already known, but I did
spot one small nit on  this draft.  Section 5.5 "The Signaling Function
(SF) of an Initiating Provider" really should be for the "Receiving"
provider.  Section 5.4 deals with the Initiating Provider.

Jim McEachern


------_=_NextPart_001_01C8304B.AD9C88A6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>SPEERMINT Peering Architecture</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2 FACE=3D"Arial">Not sure</FONT> <FONT SIZE=3D2 FACE=3D"Arial">if =
you plan to revise, or if th</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">is</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Arial">is</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial"> already known, but I did =
spot one small nit on&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Arial">this</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial"> draft.</FONT>&nbsp;<FONT =
SIZE=3D2 FACE=3D"Arial"> S</FONT><FONT SIZE=3D2 FACE=3D"Arial">ection =
5.5</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT =
SIZE=3D2 FACE=3D"Arial">&#8220;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">The Signaling Function (SF) of an Initiating =
Provider</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&#8221;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial"> really should be for the</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Arial">&#8220;</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Receiving</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&#8221;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial"> provider.</FONT>&nbsp;<FONT SIZE=3D2 FACE=3D"Arial"> =
S</FONT><FONT SIZE=3D2 FACE=3D"Arial">ection 5.4</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> <FONT SIZE=3D2 =
FACE=3D"Arial">deals with</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial"> the Initiating =
Provider.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN><A NAME=3D""><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Jim McEachern</FONT></SPAN></A></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C8304B.AD9C88A6--


--===============2031018962==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2031018962==--




From speermint-bounces@ietf.org Mon Nov 26 12:14:46 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwhXh-0004Dy-JF; Mon, 26 Nov 2007 12:14:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhXg-0004Ds-QJ
	for speermint@ietf.org; Mon, 26 Nov 2007 12:14:44 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhXX-0004Mk-5f
	for speermint@ietf.org; Mon, 26 Nov 2007 12:14:44 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JS400AA7IIMOI@siemenscomms.co.uk> for
	speermint@ietf.org; Mon, 26 Nov 2007 17:13:41 +0000 (GMT)
Date: Mon, 26 Nov 2007 16:25:57 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Speermint] [wg-business]
	WGLCfordraft-ietf-speermint-terminology-13
In-reply-to: <F1A1D21DA394814E824AC89F5A005BA314CB0743@zcarhxm0.corp.nortel.com>
To: James McEachern <jmce@nortel.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>, speermint@ietf.org
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441BBA@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [Speermint] [wg-business]
	WGLCfordraft-ietf-speermint-terminology-13
Thread-Index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gGF/7KgAPpZYxAADIiegADsV/RwAAWieYA=
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: A
	<45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0440FBE@GBNTHT12009MSX.gb002.siemens.net>
	A
	<45AEC6EF95942140888406588E1A66020307D94F@PACDCEXCMB04.cable.comcast.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441618@GBNTHT12009MSX.gb002.siemens.net>
	<F1A1D21DA394814E824AC89F5A005BA314CB0743@zcarhxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Jim,

Your proposal sounds good.

John=20

> -----Original Message-----
> From: James McEachern [mailto:jmce@nortel.com]=20
> Sent: 26 November 2007 15:55
> To: Elwell, John; Livingood, Jason; speermint@ietf.org
> Subject: RE: [Speermint] [wg-business]=20
> WGLCfordraft-ietf-speermint-terminology-13
>=20
> John, Jason,
> I like John's proposal for how to solve the SED ambiguity,=20
> but have not
> seen a proposal for specific text yet.  At the risk of duplicating
> effort, I will propose some concrete changes to the Terminology draft
> that may achieve the intended effect.
>=20
> 1. Section 2, the final paragraph currently says:
> "As illustrated in Figure 1, the ENUM Working Group is primarily=20
>    concerned with the acquisition of SED while the SPEERMINT Working=20
>    Group is focused on the use of such SED in routing session=20
> signaling=20
>    requests. Importantly, the SED can be derived from ENUM (i.e., an=20
>    E.164 DNS entry) or via any other mechanism available to the user."
>=20
> Suggest this be changed to:
> "As illustrated in Figure 1, the ENUM Working Group is primarily
> concerned with identifying a SIP URI that corresponds to a given E.164
> number, while the SPEERMINT Working Group is concerned with using that
> SIP URI to acquire the SED and on the use of such SED in=20
> routing session
> signaling requests.  Importantly, the SIP URI can be derived from ENUM
> (i.e., an E.164 DNS entry) or via any other mechanism available to the
> user."
>=20
> 2. Section 3.3, the first paragraph says:
> "Session Establishment Data, or SED, is the data used to route a call=20
>    to the next hop associated with the called domain's=20
> ingress point. A=20
>    domain's ingress point can be thought of as the location=20
> derived from
> the NAPTR/SRV/A record [1] that resulted from the resolution of the=20
>    SED (i.e., a SIP Address of Record (AoR))."
>=20
> I suggest modifying this paragraph to read:
>=20
> "Session Establishment Data, or SED, is the data used to route a call=20
>    to the next hop associated with the called domain's=20
> ingress point. A=20
>    domain's ingress point can be thought of as the location=20
> derived from
> the NAPTR/SRV/A record [1] that resulted from the resolution of the=20
>    SIP URI."
>=20
> 3. Section 3.3 also includes a list of parameters that the=20
> SBE needs to
> complete the call.  The section then provides a bullet list of
> parameters that the SED "may include".  Although much of our=20
> work seems
> to be around identifying an ingress SBE, there is no mention=20
> of this in
> the list.  I suggest modifying the current second bullets as follows:
>=20
> Current bullet:
>      . A SIP proxy to send the INVITE to, including
>=20
> Change to:
>      . A SIP proxy or Ingress SBE to send the INVITE to, including
>=20
> I believe these changes would expand the definition of SED, and better
> align with the use of the term in the rest of this draft, and in other
> SPEERMINT drafts.
>=20
> BTW, I believe changes to figure 1 will also be required, but I'll
> suggest those in another post.
>=20
>=20
> Jim McEachern
>=20
>   > -----Original Message-----
>   > From: Elwell, John [mailto:john.elwell@siemens.com]
>   > Sent: Wednesday, November 21, 2007 4:08 PM
>   > To: Livingood, Jason; speermint@ietf.org; Malas, Daryl; Dave Meyer
>   > Subject: RE: [Speermint] [wg-business] WGLC=20
> fordraft-ietf-speermint-
>   > terminology-13
>   >=20
>   > Jason,
>   >=20
>   > Thanks for the invitation. I will not make a text proposal at
> present,
>   > but a general proposal how to solve it.
>   >=20
>   > Basically, I think it would make more sense if SED were=20
> the data you
>   > ended up with at the end of the SPEERMINT process.
>   >=20
>   > I think  the following existing statement:
>   > "Note that in Figure 1, Session Establishment Data (SED), is the
> data
>   >    used to route a call to the called domain's ingress point (see
>   >    Section 3.3 for additional detail)."
>   > Would then be correct, but the position of SED in figure=20
> 1 would be
>   > wrong, because it looks like it is intended to be input=20
> data to the
>   > look-up. Also in figure 1, I think the processes of federation
>   > detection, policy look-up and service location are all things that
> help
>   > to construct the SED. So figure 1 would need some rework. However,
> to me
>   > the conventions used in figure 1 are unclear, so I don't=20
> know how it
>   > should be represented. But basically it should show the following
>   > things:
>   >  - the input to the SPEERMINT process is the SIP URI;
>   >  - the process itself comprises look-up to achieve federation
> detection,
>   > policy and service location;
>   >  - the output from the SPEERMINT process is the SED.
>   >=20
>   > I think the following existing statement is wrong:
>   > "As illustrated in Figure 1, the ENUM Working Group is primarily
>   >    concerned with the acquisition of SED while the=20
> SPEERMINT Working
>   >    Group is focused on the use of such SED in routing session
> signaling
>   >    requests. Importantly, the SED can be derived from=20
> ENUM (i.e., an
>   >    E.164 DNS entry) or via any other mechanism available to the
> user.
>   >    Finally, note that the term "call" is being used here=20
> in the most
>   >    general sense, i.e., call routing and session routing are used
>   >    interchangeably."
>   > Because this treats SED as input, not as output from the process.
>   >=20
>   > I think the following existing statement:
>   > "More specifically, the SED is the set of parameters that the
> outgoing
>   >    SBEs need to complete the call, and may include:"
>   > and the bullets that follow it are correct, because they seem to
>   > describe the output from the process.
>   >=20
>   > I haven't cross-checked whether this would align with usage of SED
> in
>   > other documents.
>   >=20
>   > John
>   >=20
>   > > -----Original Message-----
>   > > From: Livingood, Jason=20
> [mailto:Jason_Livingood@cable.comcast.com]
>   > > Sent: 21 November 2007 14:58
>   > > To: Elwell, John; speermint@ietf.org; Malas, Daryl; Dave Meyer
>   > > Subject: RE: [Speermint] [wg-business] WGLC
>   > > fordraft-ietf-speermint-terminology-13
>   > >
>   > > It is easy to identify problems in any document.  ;-)  We're
>   > > open to any
>   > > suggestion on how to resolve this by you.  Please make a
>   > > proposal to the
>   > > list.
>   > >
>   > > Thanks
>   > > Jason
>   > >
>   > > > -----Original Message-----
>   > > > From: Elwell, John [mailto:john.elwell@siemens.com]
>   > > > Sent: Friday, November 16, 2007 10:43 AM
>   > > > To: Livingood, Jason; speermint@ietf.org; Malas, Daryl; Dave
> Meyer
>   > > > Subject: RE: [Speermint] [wg-business] WGLC
>   > > > fordraft-ietf-speermint-terminology-13
>   > > >
>   > > > I still think the concept of SED is confusing. On the one
>   > > > hand it says:
>   > > > "   As illustrated in Figure 1, the ENUM Working Group is
> primarily
>   > > >    concerned with the acquisition of SED while the
>   > > SPEERMINT Working
>   > > >    Group is focused on the use of such SED in routing session
>   > > > signaling
>   > > >    requests. Importantly, the SED can be derived from ENUM
>   > > (i.e., an
>   > > >    E.164 DNS entry) or via any other mechanism available to
>   > > the user."
>   > > > This clearly says that SED is input to the SPEERMINT process
>   > > > and can be provided by the ENUM process. As far as I know,
>   > > > the ENUM process will only provide a SIP URI.
>   > > >
>   > > > On the other hand, it states:
>   > > > "   More specifically, the SED is the set of=20
> parameters that the
>   > > > outgoing
>   > > >    SBEs need to complete the call, and may include:
>   > > >
>   > > >      . A destination SIP URI
>   > > >
>   > > >      . A SIP proxy to send the INVITE to, including
>   > > >
>   > > >           o  Fully Qualified Domain Name (FQDN)
>   > > >
>   > > >           o  Port
>   > > >
>   > > >           o  Transport Protocol (UDP/TCP/TLS [9/10/11])
>   > > >
>   > > >      . Security Parameters, including
>   > > >
>   > > >           o  TLS certificate to use
>   > > >
>   > > >           o  TLS certificate to expect
>   > > >
>   > > >           o  TLS certificate verification setting
>   > > >
>   > > >      . Optional resource control parameters such as
>   > > >
>   > > >           o  Limits on the total number of call initiations
>   > > to a peer
>   > > >
>   > > >           o  Limits on SIP transactions/second "
>   > > >
>   > > > This is clearly in conflict, since it is a lot more than just
>   > > > the SIP URI and also appears to include a lot of data that is
>   > > > output from, rather than input to, the SPEERMINT process.
>   > > >
>   > > > John
>   > > >
>   > > >
>   > > > > -----Original Message-----
>   > > > > From: Livingood, Jason
> [mailto:Jason_Livingood@cable.comcast.com]
>   > > > > Sent: 08 November 2007 21:23
>   > > > > To: speermint@ietf.org
>   > > > > Subject: [Speermint] [wg-business] WGLC for
>   > > > > draft-ietf-speermint-terminology-13
>   > > > >
>   > > > >
>   > > > > 	Title           : SPEERMINT Terminology
>   > > > > 	Author(s)       : D. Malas, D. Meyer
>   > > > > 	Filename        :
> draft-ietf-speermint-terminology-13.txt
>   > > > > 	Pages           : 13
>   > > > > 	Date            : 2007-11-08
>   > > > >
>   > > > > This document defines the terminology that is to be used in
>   > > > describing
>   > > > > Session PEERing for Multimedia INTerconnect (SPEERMINT).
>   > > > >
>   > > > > A URL for this Internet-Draft is:
>   > > > >=20
> http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi
>   > > > > nology-13.
>   > > > > txt
>   > > > >=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>   > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>   > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>   > > > > The intent of the last call is to solicit comments before
>   > > > submitting
>   > > > > the ID to the IESG.
>   > > > >
>   > > > > The purpose of a working group Last Call is in the style of
>   > > > "speak now
>   > > > > or forever hold your peace" in case there are fundamental
>   > > > objections
>   > > > > which have not gotten previous or adequate discussion, or
>   > > > minor errors
>   > > > > which need correction.
>   > > > >
>   > > > > Working group last call will extend for 2 weeks from today,
>   > > > 8 November
>   > > > > 2007, until 22 November 2007.  Please note that this is
>   > > the second
>   > > > > WGLC on this document.
>   > > > >
>   > > > > Please post any comments in reply to the list, as well as to
> the
>   > > > > editor(s) of this draft.
>   > > > >
>   > > > > Regards,
>   > > > >
>   > > > > Jason & Dave
>   > > > >
>   > > > > _______________________________________________
>   > > > > Speermint mailing list
>   > > > > Speermint@ietf.org
>   > > > > https://www1.ietf.org/mailman/listinfo/speermint
>   > > > >
>   > > > > _______________________________________________
>   > > > > Speermint mailing list
>   > > > > Speermint@ietf.org
>   > > > > https://www1.ietf.org/mailman/listinfo/speermint
>   > > > >
>   > > >
>   > >
>   >=20
>   > _______________________________________________
>   > Speermint mailing list
>   > Speermint@ietf.org
>   > https://www1.ietf.org/mailman/listinfo/speermint
>=20

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



From speermint-bounces@ietf.org Mon Nov 26 12:54:24 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwiA1-00039Q-Fu; Mon, 26 Nov 2007 12:54:21 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiA0-00036q-AS
	for speermint@ietf.org; Mon, 26 Nov 2007 12:54:20 -0500
Received: from mail164.messagelabs.com ([216.82.253.131])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwi9z-0000LO-AI
	for speermint@ietf.org; Mon, 26 Nov 2007 12:54:20 -0500
X-VirusChecked: Checked
X-Env-Sender: daryl@level3.net
X-Msg-Ref: server-7.tower-164.messagelabs.com!1196099657!1817582!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [209.245.18.107]
Received: (qmail 8669 invoked from network); 26 Nov 2007 17:54:17 -0000
Received: from unknown.level3.net (HELO f10cc8-10.level3.com) (209.245.18.107)
	by server-7.tower-164.messagelabs.com with SMTP;
	26 Nov 2007 17:54:17 -0000
Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57])
	by f10cc8-10.level3.com (Postfix) with ESMTP id 28F1633AC;
	Mon, 26 Nov 2007 17:54:17 +0000 (GMT)
Subject: RE: [Speermint] [wg-business] WGLC
	for	draft-ietf-speermint-terminology-13
From: Daryl Malas <daryl@level3.net>
To: James McEachern <jmce@nortel.com>
In-Reply-To: <F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
Content-Type: text/plain
Date: Mon, 26 Nov 2007 11:04:37 -0700
Message-Id: <1196100278.1297.397.camel@montag.eng.level3.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 (2.6.0-1) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Cc: speermint@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Jim,

I will update the draft today and submit a new revision.  Thanks for
your comments and feedback.

--Daryl

On Mon, 2007-11-26 at 11:37 -0500, James McEachern wrote:
> Jason,
> I realize this is after the deadline, but I went over all the drafts
> again this weekend, and couldn't help but notice the inconsistencies.
> (It is definitely getting better, but not quite there yet...)
> 
> I know you probably don't want to revisit figure 1, but in its current
> form it seems to me that it is most definitely wrong.  For example, this
> figure shows that the "Lookup of SRV/A and AAAA in DNS" is out of scope
> for SPEERMINT.  This would suggest that your excellent draft on the "Use
> of DNS and NAPTR Records for SPEERMINT" is entirely out of scope for
> SPEERMINT.  This seems just plain wrong to me.  
> After re-reading all the drafts this weekend, it seems to me that we are
> really talking about something that is better described by the following
> diagram:
> 
>            E.164 number  
>                 | 
>                 | <--- ENUM lookup of NAPTR in Domain Name System (DNS) 
>                 |
>            Lookup 
>            Discovery 
>            SIP URI 
>                 | 
>                 | ENUM Working Group Scope 
>            =====+==================================================== 
>                 | SPEERMINT Working Group Scope 
>                 |                                             \
>                 | <--- Federation Detection, Policy           | 
>                 |      Lookup, and Service Location           |
>                 |                                             | Session
>                 |
> |Establishment
>            Hostname <--- Addressing and session establishment \ Data 
>                 |                                             /(SED)
> 
>                 |                                             |
>                 | <--- Lookup of SRV/A and AAAA in DNS        |
>                 |                                             |
>                 |                                             |
>            IP address                                         |
>                 |                                             /
>                 | SPEERMINT Working Group Scope 
>            =====+==================================================== 
>                 | Out of scope for the SPEERMINT Working Group 
>                 |
>                 | <--- Routing protocols, ARP [14] etc. 
>                 | 
>            MAC-address 
> 
>                   Figure 1: Session Peering Context
> 
> If this isn't the scope, then there are many other pieces that do not
> really make sense.
> 
> Finally, and again I apologize for the lateness of this comment, the
> definition of Service Provider in section 3.8 suggests that the term
> "Service Provider" when used without the preceding "SIP" means an entity
> that only provides layer 3 functionality.  This definition conflicts
> with usage later in this and other documents.  (e.g. section 4.2 states:
> "Layer 5 (Session) peering refers to interconnection of two service
> providers...".)  We either need to add "SIP" before "service provider"
> (in several places) or modify the definition slightly.  
> 
> Perhaps change the existing text:
> "A Service Provider (or SP) is defined to be an entity that provides
> layer 3 (IP) transport of SIP signaling and media packets."
> 
> Change to:
> "A Service Provider (or SP) is defined to be an entity that provides
> layer 3 (IP) transport of SIP signaling and media packets, and may also
> provide layer 5 processing of SIP signaling and media packets."  
> 
> If that change doesn't work for people, then there are a number of other
> places where I believe we need to add the work "SIP" in front of
> "service provider" or we are talking about layer 5 functions being
> performed by an entity that is only supposed to work at layer 3.
> 
> Jim McEachern
> 
>   > -----Original Message-----
>   > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
>   > Sent: Thursday, November 08, 2007 4:23 PM
>   > To: speermint@ietf.org
>   > Subject: [Speermint] [wg-business] WGLC for draft-ietf-speermint-
>   > terminology-13
>   > 
>   > 	Title           : SPEERMINT Terminology
>   > 	Author(s)       : D. Malas, D. Meyer
>   > 	Filename        : draft-ietf-speermint-terminology-13.txt
>   > 	Pages           : 13
>   > 	Date            : 2007-11-08
>   > 
>   > This document defines the terminology that is to be used in
> describing
>   > Session PEERing for Multimedia INTerconnect (SPEERMINT).
>   > 
>   > A URL for this Internet-Draft is:
>   >
> http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-13.
>   > txt
>   >
> ========================================================================
>   > =================
>   > The intent of the last call is to solicit comments before submitting
> the
>   > ID to the IESG.
>   > 
>   > The purpose of a working group Last Call is in the style of "speak
> now
>   > or forever hold your peace" in case there are fundamental objections
>   > which have not gotten previous or adequate discussion, or minor
> errors
>   > which need correction.
>   > 
>   > Working group last call will extend for 2 weeks from today, 8
> November
>   > 2007, until 22 November 2007.  Please note that this is the second
> WGLC
>   > on this document.
>   > 
>   > Please post any comments in reply to the list, as well as to the
>   > editor(s) of this draft.
>   > 
>   > Regards,
>   > 
>   > Jason & Dave
>   > 
>   > _______________________________________________
>   > Speermint mailing list
>   > Speermint@ietf.org
>   > https://www1.ietf.org/mailman/listinfo/speermint
>   > 
>   > _______________________________________________
>   > Speermint mailing list
>   > Speermint@ietf.org
>   > https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint


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



From speermint-bounces@ietf.org Mon Nov 26 15:40:16 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwkkX-0006Si-91; Mon, 26 Nov 2007 15:40:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkkV-0006Mf-2A
	for speermint@ietf.org; Mon, 26 Nov 2007 15:40:11 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwkkR-0002gM-4y
	for speermint@ietf.org; Mon, 26 Nov 2007 15:40:11 -0500
Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian))
	id 1IwkkP-0007Vp-00
	for <speermint@ietf.org>; Mon, 26 Nov 2007 21:40:05 +0100
Date: Mon, 26 Nov 2007 21:40:05 +0100
From: Otmar Lendl <lendl@nic.at>
To: speermint@ietf.org
Subject: Re: [Speermint] [wg-business]
	WGLCfor	draft-ietf-speermint-terminology-13
Message-ID: <20071126204005.GA28858@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org
References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

On 2007/11/26 17:11, James McEachern <jmce@nortel.com> wrote:
> 
> I know you probably don't want to revisit figure 1, but in its current
> form it seems to me that it is most definitely wrong.  For example, this
> figure shows that the "Lookup of SRV/A and AAAA in DNS" is out of scope
> for SPEERMINT.  This would suggest that your excellent draft on the "Use
> of DNS and NAPTR Records for SPEERMINT" is entirely out of scope for
> SPEERMINT.  This seems just plain wrong to me.  

Good catch.

As I see it, the NAPTR/SRV/A lookup step (RFC3263, or the NAPTR
speermint draft) is the solution to the speermint problem in a
world where any SSP agrees to do ad-hoc peering with any other SSP
over the public Internet. The other extreme would be just static,
manually configured peerings. Both is too limiting for the real world.

It's the middle ground (SSPs with complex and diverse peering
strategies) which is not covered by existing mechanisms. Here is IMHO
the true calling of speermint: provide a framework which allows all
SSPs to use a common routing architecture which supports whatever
their peering strategy is and will be. 

This provides the room for incremental changes in peering strategies:
SSPs can slowly converge to a fully open peering setup. At the pace
they are comfortable with. Not just all-or-nothing decisions.
>From my perspective, such an approach is much likelier to result in 
widespread peering than a RFC3263 purity contest.

/ol
-- 
/ Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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



From speermint-bounces@ietf.org Mon Nov 26 17:22:49 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwmLl-0002MH-3H; Mon, 26 Nov 2007 17:22:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwmLj-0002M7-Ib
	for speermint@ietf.org; Mon, 26 Nov 2007 17:22:43 -0500
Received: from mail161.messagelabs.com ([216.82.253.115])
	by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwmLi-0007op-LU
	for speermint@ietf.org; Mon, 26 Nov 2007 17:22:43 -0500
X-VirusChecked: Checked
X-Env-Sender: daryl@level3.net
X-Msg-Ref: server-3.tower-161.messagelabs.com!1196115761!8728497!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [209.245.18.106]
Received: (qmail 28460 invoked from network); 26 Nov 2007 22:22:41 -0000
Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106)
	by server-3.tower-161.messagelabs.com with SMTP;
	26 Nov 2007 22:22:41 -0000
Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57])
	by f10bb8-10 (Postfix) with ESMTP id DF4294444;
	Mon, 26 Nov 2007 22:22:40 +0000 (GMT)
Subject: RE: [Speermint] [wg-business] WGLC
	for	draft-ietf-speermint-terminology-13
From: Daryl Malas <daryl@level3.net>
To: James McEachern <jmce@nortel.com>
In-Reply-To: <1196100278.1297.397.camel@montag.eng.level3.com>
References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
	<1196100278.1297.397.camel@montag.eng.level3.com>
Content-Type: text/plain
Date: Mon, 26 Nov 2007 15:33:02 -0700
Message-Id: <1196116382.1297.401.camel@montag.eng.level3.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 (2.6.0-1) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: speermint@ietf.org, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

FYI..due to the cutoff date, and the fact I cannot submit a new rev
until 12/3; feel free to provide comments up to 12/2.

Thanks...--Daryl

On Mon, 2007-11-26 at 11:04 -0700, Daryl Malas wrote:
> Jim,
> 
> I will update the draft today and submit a new revision.  Thanks for
> your comments and feedback.
> 
> --Daryl
> 
> On Mon, 2007-11-26 at 11:37 -0500, James McEachern wrote:
> > Jason,
> > I realize this is after the deadline, but I went over all the drafts
> > again this weekend, and couldn't help but notice the inconsistencies.
> > (It is definitely getting better, but not quite there yet...)
> > 
> > I know you probably don't want to revisit figure 1, but in its current
> > form it seems to me that it is most definitely wrong.  For example, this
> > figure shows that the "Lookup of SRV/A and AAAA in DNS" is out of scope
> > for SPEERMINT.  This would suggest that your excellent draft on the "Use
> > of DNS and NAPTR Records for SPEERMINT" is entirely out of scope for
> > SPEERMINT.  This seems just plain wrong to me.  
> > After re-reading all the drafts this weekend, it seems to me that we are
> > really talking about something that is better described by the following
> > diagram:
> > 
> >            E.164 number  
> >                 | 
> >                 | <--- ENUM lookup of NAPTR in Domain Name System (DNS) 
> >                 |
> >            Lookup 
> >            Discovery 
> >            SIP URI 
> >                 | 
> >                 | ENUM Working Group Scope 
> >            =====+==================================================== 
> >                 | SPEERMINT Working Group Scope 
> >                 |                                             \
> >                 | <--- Federation Detection, Policy           | 
> >                 |      Lookup, and Service Location           |
> >                 |                                             | Session
> >                 |
> > |Establishment
> >            Hostname <--- Addressing and session establishment \ Data 
> >                 |                                             /(SED)
> > 
> >                 |                                             |
> >                 | <--- Lookup of SRV/A and AAAA in DNS        |
> >                 |                                             |
> >                 |                                             |
> >            IP address                                         |
> >                 |                                             /
> >                 | SPEERMINT Working Group Scope 
> >            =====+==================================================== 
> >                 | Out of scope for the SPEERMINT Working Group 
> >                 |
> >                 | <--- Routing protocols, ARP [14] etc. 
> >                 | 
> >            MAC-address 
> > 
> >                   Figure 1: Session Peering Context
> > 
> > If this isn't the scope, then there are many other pieces that do not
> > really make sense.
> > 
> > Finally, and again I apologize for the lateness of this comment, the
> > definition of Service Provider in section 3.8 suggests that the term
> > "Service Provider" when used without the preceding "SIP" means an entity
> > that only provides layer 3 functionality.  This definition conflicts
> > with usage later in this and other documents.  (e.g. section 4.2 states:
> > "Layer 5 (Session) peering refers to interconnection of two service
> > providers...".)  We either need to add "SIP" before "service provider"
> > (in several places) or modify the definition slightly.  
> > 
> > Perhaps change the existing text:
> > "A Service Provider (or SP) is defined to be an entity that provides
> > layer 3 (IP) transport of SIP signaling and media packets."
> > 
> > Change to:
> > "A Service Provider (or SP) is defined to be an entity that provides
> > layer 3 (IP) transport of SIP signaling and media packets, and may also
> > provide layer 5 processing of SIP signaling and media packets."  
> > 
> > If that change doesn't work for people, then there are a number of other
> > places where I believe we need to add the work "SIP" in front of
> > "service provider" or we are talking about layer 5 functions being
> > performed by an entity that is only supposed to work at layer 3.
> > 
> > Jim McEachern
> > 
> >   > -----Original Message-----
> >   > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
> >   > Sent: Thursday, November 08, 2007 4:23 PM
> >   > To: speermint@ietf.org
> >   > Subject: [Speermint] [wg-business] WGLC for draft-ietf-speermint-
> >   > terminology-13
> >   > 
> >   > 	Title           : SPEERMINT Terminology
> >   > 	Author(s)       : D. Malas, D. Meyer
> >   > 	Filename        : draft-ietf-speermint-terminology-13.txt
> >   > 	Pages           : 13
> >   > 	Date            : 2007-11-08
> >   > 
> >   > This document defines the terminology that is to be used in
> > describing
> >   > Session PEERing for Multimedia INTerconnect (SPEERMINT).
> >   > 
> >   > A URL for this Internet-Draft is:
> >   >
> > http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-13.
> >   > txt
> >   >
> > ========================================================================
> >   > =================
> >   > The intent of the last call is to solicit comments before submitting
> > the
> >   > ID to the IESG.
> >   > 
> >   > The purpose of a working group Last Call is in the style of "speak
> > now
> >   > or forever hold your peace" in case there are fundamental objections
> >   > which have not gotten previous or adequate discussion, or minor
> > errors
> >   > which need correction.
> >   > 
> >   > Working group last call will extend for 2 weeks from today, 8
> > November
> >   > 2007, until 22 November 2007.  Please note that this is the second
> > WGLC
> >   > on this document.
> >   > 
> >   > Please post any comments in reply to the list, as well as to the
> >   > editor(s) of this draft.
> >   > 
> >   > Regards,
> >   > 
> >   > Jason & Dave
> >   > 
> >   > _______________________________________________
> >   > Speermint mailing list
> >   > Speermint@ietf.org
> >   > https://www1.ietf.org/mailman/listinfo/speermint
> >   > 
> >   > _______________________________________________
> >   > Speermint mailing list
> >   > Speermint@ietf.org
> >   > https://www1.ietf.org/mailman/listinfo/speermint
> > 
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint


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



From speermint-bounces@ietf.org Tue Nov 27 03:22:56 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IwviY-0007hB-MO; Tue, 27 Nov 2007 03:22:54 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IwviX-0007gs-PO
	for speermint@ietf.org; Tue, 27 Nov 2007 03:22:53 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwviX-0004Nb-7d
	for speermint@ietf.org; Tue, 27 Nov 2007 03:22:53 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JS500HBNOM4YQ@siemenscomms.co.uk> for
	speermint@ietf.org; Tue, 27 Nov 2007 08:22:52 +0000 (GMT)
Date: Tue, 27 Nov 2007 08:22:52 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Speermint] [wg-business] WGLC
	fordraft-ietf-speermint-terminology-13
In-reply-to: <F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
To: James McEachern <jmce@nortel.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>, speermint@ietf.org
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0441C05@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [Speermint] [wg-business] WGLC
	fordraft-ietf-speermint-terminology-13
Thread-Index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gN+ALlgACJA0sA=
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

=20

> -----Original Message-----
> From: James McEachern [mailto:jmce@nortel.com]=20
> Sent: 26 November 2007 16:37
> To: Livingood, Jason; speermint@ietf.org
> Subject: RE: [Speermint] [wg-business] WGLC=20
> fordraft-ietf-speermint-terminology-13
>=20
> Jason,
> I realize this is after the deadline, but I went over all the drafts
> again this weekend, and couldn't help but notice the inconsistencies.
> (It is definitely getting better, but not quite there yet...)
>=20
> I know you probably don't want to revisit figure 1, but in its current
> form it seems to me that it is most definitely wrong.  For=20
> example, this
> figure shows that the "Lookup of SRV/A and AAAA in DNS" is=20
> out of scope
> for SPEERMINT.  This would suggest that your excellent draft=20
> on the "Use
> of DNS and NAPTR Records for SPEERMINT" is entirely out of scope for
> SPEERMINT.  This seems just plain wrong to me. =20
> After re-reading all the drafts this weekend, it seems to me=20
> that we are
> really talking about something that is better described by=20
> the following
> diagram:
>=20
>            E.164 number =20
>                 |=20
>                 | <--- ENUM lookup of NAPTR in Domain Name=20
> System (DNS)=20
>                 |
>            Lookup=20
>            Discovery=20
>            SIP URI=20
>                 |=20
>                 | ENUM Working Group Scope=20
>            =
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=20
>                 | SPEERMINT Working Group Scope=20
>                 |                                             \
>                 | <--- Federation Detection, Policy           |=20
>                 |      Lookup, and Service Location           |
>                 |                                            =20
> | Session
>                 |
> |Establishment
>            Hostname <--- Addressing and session establishment \ Data=20
>                 |                                             /(SED)
>=20
>                 |                                             |
>                 | <--- Lookup of SRV/A and AAAA in DNS        |
>                 |                                             |
>                 |                                             |
>            IP address                                         |
>                 |                                             /
>                 | SPEERMINT Working Group Scope=20
>            =
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=20
>                 | Out of scope for the SPEERMINT Working Group=20
>                 |
>                 | <--- Routing protocols, ARP [14] etc.=20
>                 |=20
>            MAC-address=20
>=20
>                   Figure 1: Session Peering Context
>=20
> If this isn't the scope, then there are many other pieces that do not
> really make sense.
>=20
> Finally, and again I apologize for the lateness of this comment, the
> definition of Service Provider in section 3.8 suggests that the term
> "Service Provider" when used without the preceding "SIP"=20
> means an entity
> that only provides layer 3 functionality.  This definition conflicts
> with usage later in this and other documents.  (e.g. section=20
> 4.2 states:
> "Layer 5 (Session) peering refers to interconnection of two service
> providers...".)  We either need to add "SIP" before "service provider"
> (in several places) or modify the definition slightly. =20
>=20
> Perhaps change the existing text:
> "A Service Provider (or SP) is defined to be an entity that provides
> layer 3 (IP) transport of SIP signaling and media packets."
>=20
> Change to:
> "A Service Provider (or SP) is defined to be an entity that provides
> layer 3 (IP) transport of SIP signaling and media packets,=20
> and may also
> provide layer 5 processing of SIP signaling and media packets."=20
[JRE] This change doesn't work for me. I think we need to go for your
other proposal (inserting "SIP" in appropriate places).

John

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



From speermint-bounces@ietf.org Wed Nov 28 00:53:34 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxFrV-0005PI-Qp; Wed, 28 Nov 2007 00:53:29 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxFrU-0005P5-L5
	for speermint@ietf.org; Wed, 28 Nov 2007 00:53:28 -0500
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxFrU-0000Ce-9s
	for speermint@ietf.org; Wed, 28 Nov 2007 00:53:28 -0500
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	lAS5rP811660; Wed, 28 Nov 2007 05:53:25 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] [wg-business]
	WGLC	fordraft-ietf-speermint-terminology-13
Date: Wed, 28 Nov 2007 00:53:23 -0500
Message-ID: <F1A1D21DA394814E824AC89F5A005BA314D42D39@zcarhxm0.corp.nortel.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0441C05@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] [wg-business]
	WGLC	fordraft-ietf-speermint-terminology-13
thread-index: AcgiTXyT2LUuTWVNQoucZCuye/0c3gN+ALlgACJA0sAALOVl0A==
References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441C05@GBNTHT12009MSX.gb002.siemens.net>
From: "James McEachern" <jmce@nortel.com>
To: "Elwell, John" <john.elwell@siemens.com>,
	"Livingood, Jason" <Jason_Livingood@cable.comcast.com>,
	<speermint@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Comments inline.

John Elwell wrote:

--- snip ----
 =20
  > > Finally, and again I apologize for the lateness of this comment,
the
  > > definition of Service Provider in section 3.8 suggests that the
term
  > > "Service Provider" when used without the preceding "SIP"
  > > means an entity
  > > that only provides layer 3 functionality.  This definition
conflicts
  > > with usage later in this and other documents.  (e.g. section
  > > 4.2 states:
  > > "Layer 5 (Session) peering refers to interconnection of two
service
  > > providers...".)  We either need to add "SIP" before "service
provider"
  > > (in several places) or modify the definition slightly.
  > >
  > > Perhaps change the existing text:
  > > "A Service Provider (or SP) is defined to be an entity that
provides
  > > layer 3 (IP) transport of SIP signaling and media packets."
  > >
  > > Change to:
  > > "A Service Provider (or SP) is defined to be an entity that
provides
  > > layer 3 (IP) transport of SIP signaling and media packets,
  > > and may also
  > > provide layer 5 processing of SIP signaling and media packets."
  > [JRE] This change doesn't work for me. I think we need to go for
your
  > other proposal (inserting "SIP" in appropriate places).
  >=20
  > John
[jmce]  I've gone through most of the drafts to identify where we would
need to make changes by inserting "SIP".  I've found over 20 instances
already, along with a dozen or so that simply say "provider" - and hence
presumably need to add "SIP Service".  Before I document all of these
instances, I just want to ensure that the group wants to go this route,
rather than the simpler choice of changing the definition.

Let me know.

Jim

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



From speermint-bounces@ietf.org Wed Nov 28 08:28:43 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxMxz-0004YP-W6; Wed, 28 Nov 2007 08:28:39 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMxy-0004Y4-TB
	for speermint@ietf.org; Wed, 28 Nov 2007 08:28:38 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxMxx-00057y-0R
	for speermint@ietf.org; Wed, 28 Nov 2007 08:28:38 -0500
Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian))
	id 1IxMxv-0007yH-00
	for <speermint@ietf.org>; Wed, 28 Nov 2007 14:28:35 +0100
Date: Wed, 28 Nov 2007 14:28:35 +0100
From: Otmar Lendl <lendl@nic.at>
To: speermint@ietf.org
Message-ID: <20071128132835.GA29883@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb
Subject: [Speermint] Review of draft-ietf-speermint-architecture-04
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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


I can't remember that we discussed that draft during the last two
meetings. The current agenda gives 40 mins for this draft, so took
another look at this document.

>Abstract 
>
>   This document defines the SPEERMINT peering architecture, its  
>   functional components and peering interface functions. It also 
>  describes the steps taken to establish a session between two peering   

General comment: 

We now finally have once again a document which lists the requirements
on what the speermint architecture is supposed to solve. That list
isn't done yet, but still it would be worthwhile to look at the
architecture document with an eye for the requirements.

As the requirements draft changed substantially recently, this draft
also needs to reflect this.

>2. Network Context  
>
> 
>   Figure 1 shows an example network context. 

I find this figure to be more confusing than helping.

>   Two SIP providers can form  
>   a Layer 5 peer over either the public Internet or private Layer 3  
>   networks. In addition, two or more providers may form a SIP (Layer 5)  
>   federation [17] on either the public Internet or private Layer 3  
>   networks. This document does not make any assumption whether the SIP  
>   providers directly peer to each other or through Layer 3 transit  
>   network as per use case of [16].   

fine.

> 
>   Note that Figure 1 allows for the following potential SPEERMINT  
>   peering scenarios:  
> 
>   o  Enterprise to Enterprise across the public Internet  
> 
>   o  Enterprise to Service Provider across the public Internet  
> 
>   o  Service Provider to Service Provider across the public Internet  
> 
>   o  Enterprise to enterprise across a private Layer 3 network  
> 
>   o  Enterprise to Service Provider across a private Layer 3 network  
> 
>   o  Service Provider to Service Provider across a private Layer 3  
>      network  

I see no reasons to treat Enterprises any different from Service
Providers. Yes, there may be legal and regulatory issues specific to
these cases, but from a pure protocol point of view, I see no need
to add this distinction. (BGP doesn't care whether layer 3 peering
partners are ISPs or enterprises, too.)

>   The members of a federation may jointly use a set of functions such  
>   as location peering function, application function, subscriber  
>   database function, SIP proxies, and/or functions that synthesize  
>   various SIP and non-SIP based applications. Similarly, two providers  
>   may jointly use a set of peering functions. The federation functions  
>   or the peering functions can be either public or private.  

Hu? 

>3. Procedures  
>
> 
>   This document assumes that a call from an end user in the initiating  
>   peer goes through the following steps to establish a call to an end  
>   user in the receiving peer:   
> 
>         1. The analysis of a target address.   
> 
>             a. If the target address represents an intra-VSP resource,  
>                we go directly to step 4.  

SSP, not VSP. 

Case a. doesn't fit in here as we're considering calls to other SSPs.
(we're not covering calls to voicemail and other types of calls, either.)

So what's the result of this analysis?

>         2. the discovery of the receiving peering point address,  

Does this include the determination of whether there is a peering?

> 
>         3. the enforcement of authentication and other policy,  
> 
>         4. the discovery of end user address,   
> 
>         5. the routing of SIP messages,  
> 
>         6. the session establishment,   
> 
>         7. the transfer of media,  
> 
>         8. and the session termination.   
> 
>4. Reference SPEERMINT Architecture  
> 
>   The procedures presented in Chapter 3 are implemented by a set of  
>   peering functions:   
>
>   o  Location Function (LF): Purpose is to develop Session  
>      Establishment Data (SED) by discovering the Signaling Function 
>     (SF) and the end user's reachable host (IP address and port). The 

I'm not sure whether we should include purely internal functions
in this document. For all we care, the terminating SSP could
route all calls to voicemail, to a PSTN gateway, to a H.323 gate,
to a Skype gateway or whatnot.

>      location function is distributed across the Location Server (LS)  
>      and Session Manager (SM). 
> 
>5.1. The Location Function (LF) of an Initiating Provider  
>
>   Purpose is to develop Session Establishment Data (SED) [12] by 
>   discovering the Signaling Function (SF), and end user's reachable 
>   host (IP address and host). The LF of an Initiating provider analyzes   
>   target address and discovers the next hop signaling function (SF) in 
>   a peering relationship using DNS, SIP Redirect Server, or a  
>   functional equivalent database.    

Good. As this is the crux of the matter, I recommend to either
completely strike the DNS/SIP/DB half-sentence or *really* explain
what happens.

>5.1.1. Target address analysis  
>
>   When the initiating provider receives a request to communicate, the  
>   initiating provider analyzes the target state data to determine  
>   whether the call needs to be terminated internal or external to its  
>   network. The analysis method is internal to the provider's policy;  
>   thus, outside the scope of SPEERMINT. Note that the peer is free to  
>   consult any manner of private data sources to make this  
>   determination.  
> 
>   If the target address does not represent a resource inside the  
>   initiating peer's administrative domain or federation of domains, the  
>   initiating provider resolves the call routing data by using the  
>   Location Function (LF). Examples of the LF are the functions of ENUM,  
>   Routing Table, SIP DNS, and SIP Redirect Server.  

As above, this is TAMO.  (then a miracle occurs)

>5.1.3. Carrier ENUM lookup  

Infrastructure ENUM.

>
>   Next the initiating peer checks for a carrier-of-record in a carrier  
>   ENUM domain according to the procedures described in [12].  As in the  
>   previous step, the peer MAY consult a cache or alternate  
>   representation of the ENUM data in lieu of actual DNS queries.  The  
>   peer first checks for records for the "E2U+sip" enumservice, then for  
>   the "E2U+pstn" enumservice as defined in [21].  If a terminal record  
>   is found with a sip: or sips: URI, the peer skips to Section 5.1.5,  
>   otherwise the peer continues processing according to the next  
>   section.  

See comment to 5.2.1

> 
>5.1.4. Routing Table  
>
>   If there is no user ENUM records and the initiating peer cannot  
>   discover the carrier-of-record or if the initiating peer cannot reach  
>   the carrier-of-record via SIP peering, the initiating peer still  
>   needs to deliver the call to the PSTN or reject the call.  Note that  
>   the initiating peer MAY still sends the call to another provider for  
>   PSTN gateway termination by prior arrangement using a routing table.   
>   If so, the initiating peer rewrites the Request-URI to address the  
>   gateway resource in the target provider's domain and MAY forward the  
>   request on to that provider using the procedures described in the  
>   remainder of these steps.  

The indirect peering option is missing here. There could be a transit SSP
who does noch act as PSTN gateway, but simply as SIP hop.

> 
>5.1.5. SIP DNS Resolution  
>
>   Once a sip: or sips: in an external domain is selected as the target, 
>   the initiating peer MAY apply local policy to decide whether 
>   forwarding requests to the target domain is acceptable.  

Well, maybe the target domain also has some say in whether it
will accept calls via SIP from the originating domain.

again, see comment to 5.2.1.

>5.1.6. SIP Redirect Server    
>
>   A SIP Redirect Server may help in resolving current address of a  
>   mobile target address.  

hu?

"mobile" in the sense of nomadic use, i.e. the current IP address
of the user's phone? No, that's LF territory. 

"mobile" in the sense of fixed/mobile convergence? Number porting?
You lost me here.

>5.2. The Location Function (LF) of a Receiving Provider  
>
>5.2.1. Publish ENUM records  
>
>   The receiving peer SHOULD participate by publishing "E2U+sip" and  
>   "E2U+pstn" records with sip: or sips: URIs wherever a public carrier  
>   ENUM root is available.  This assumes that the receiving peer wants  
>   to peer by default.  Even when the receiving peer does not want to  
>   accept traffic from specific initiating peers, it MAY still reject  
>   requests on a case-by-case basis.  

This is one of the core questions for the whole speermint architecture.

I do not think we can assume that a receiving peer wants to peer by default.
Quite to the contrary: As I see it, the primary reason for the existence
of speermint is that fact that this is NOT TRUE. If it were true, then
RFC3261/3263 plus ENUM would be sufficient for universal SIP interconnection.

Can we *please* get consensus on this question in Vancouver?

Second question:

	Assuming what the receiving peer will only accept calls from
	specific initiating peers, can we handle the rejections on 
	the SIP layer?

My answer (from
http://www.enum.at/ietf/draft-lendl-sip-peering-policy-00.html on) has
always been that we cannot do that. The main reasons are that some SSPs
will elect to only run SIP ingress points within private interconnection
networks and not on the public Internet. Or if they do, they will be
firewalled so that INVITES from unwanted peers will be rejected on the
IP layer. Others might place restrictions on the TLS parameters of
incoming SIP connection: when the wrong TLS certs are presented, no SIP
communication is possible.

Once again, can we get this sorted out in Vancouver?

> 
>5.2.2. Publish SIP DNS records  
>
>   To receive peer requests, the receiving peer MUST insure that it    
>   publishes appropriate NAPTR, SRV, and address (A and/or AAAA) records     
>   in the global DNS that resolve an appropriate transport, port, and    
>   address to a relevant SIP server.    

How does this square with

      Requirement #3: the mechanisms recommended for the declaration and
      advertisement of SBE and SDE entities must allow for peer and
      media variability.

      Notes on solution space: for advertising peer-dependent SBEs (peer
      variability), the solution space based on is under specified and
      there are no know best current practices. 

from the requirements draft?

>5.4.1. Setup TLS connection 
>
>   Once a transport, port, and address are found, the initiating peer 
>   will open or find a reusable TLS connection to the peer.  The 
>   initiating provider MUST verify the server certificate which SHOULD 
>   be rooted in a well-known certificate authority.  The initiating 
>   provider MUST be prepared to provide a TLS client certificate upon 
>   request during the TLS handshake.  The client certificate MUST 
>   contain a DNS or URI choice type in the subjectAltName which 
>   corresponds to the domain asserted in the host production of the From 
>   header URI.  The certificate SHOULD be valid and rooted in a well- 
>   known certificate authority. 

How does this work in the case on the second leg of an inderect peering?
In that case the domain in the From: header does not belong the transit
SSP.

> 
>   Note that the client certificate MAY contain a list of entries in the 
>   subjectAltName, only one of which has to match the domain in the From 
>   header URI. 

Can this work if customer-owned domains hosted with SSPs take off
the same way they did for e-mail? In other words, what happens when
ATT hosts the SIP service for a few thousand domains?

>   SHOULD be a global-number.  For example, the following are all 
>   acceptable, the first three are encouraged: 
> 
>   From: "John Doe" <john.doe@example.net> 
>   From: "+12125551212" <+12125551212@example.net;user=phone> 
>   From: "Anonymous" <anonymous@example.net> 

This is fine.

>5.5.2. Receive SIP requests 
>
>   Once a TLS connection is established, the receiving peer is prepared 
>   to receive incoming SIP requests.  For new dialog-forming requests 
>   and out-of-dialog requests, the receiving peer verifies that the 
>   target (request-URI) is a domain which for which it is responsible. 

Once again, this does not seem to cover indirect peering.

> 
>   The receiving peer MAY reject incoming requests due to local policy. 
>   When a request is rejected because the initiating peer is not 
>   authorized to peer, the receiving peer SHOULD respond with a 403 
>   response with the reason phrase "Unsupported Peer". 

What is the initiating peer supposed to do in this case?

* For E.164 number based dialing, it could bounce the call to the PSTN.

* For SIP URI dialed calls: ???

Perhaps there is a path via a transit SIP operator? How will the initiating
peer learn about this other path?

>6. Call Control and Media Control Deployment Options  
>
>   In a decomposed model, SF and MF are implemented in separate peering  
>   logical elements. Signaling functions are implemented in a proxy and  
>   media functions are implemented in another logical element.  The  
>   scaling of signaling versus scaling of media may differ between  
>   applications.  Decomposing allows each to follow a separate migration  
>   path.  

Is the protocol between the SF and the MF in scope for speermint? 
I have no clue what is used there.

>
>7. Address space considerations  
>

fine.

Let the discussion begin.

/ol
-- 
/ Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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



From speermint-bounces@ietf.org Wed Nov 28 17:43:08 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxVcX-0006pX-IN; Wed, 28 Nov 2007 17:43:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVcW-0006p7-Bu
	for speermint@ietf.org; Wed, 28 Nov 2007 17:43:04 -0500
Received: from host6.216.41.24.conversent.net ([216.41.24.6]
	helo=etmail.acmepacket.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxVcV-0003nQ-JU
	for speermint@ietf.org; Wed, 28 Nov 2007 17:43:04 -0500
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com
	(216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.751.0;
	Wed, 28 Nov 2007 17:43:03 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com
	([216.41.24.7]) with mapi; Wed, 28 Nov 2007 17:43:02 -0500
From: Pat MeLampy <PMelampy@acmepacket.com>
To: "speermint@ietf.org" <speermint@ietf.org>
Date: Wed, 28 Nov 2007 17:45:10 -0500
Subject: RE: [Speermint] Review of draft-ietf-speermint-architecture-04
Thread-Topic: [Speermint] Review of draft-ietf-speermint-architecture-04
Thread-Index: Acgxwp0O3YDfdNNVSsO7QWY7qw34gwAB6/wg
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC30232471B1C@mail.acmepacket.com>
References: <20071128132835.GA29883@nic.at>
In-Reply-To: <20071128132835.GA29883@nic.at>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

The real body of standards work that is necessary for this group to accompl=
ish is now at hand. If one were to look at these use cases, a crying need f=
or standards development exists. Let me be specific.

5.1.1-4 Talks about directing a call to a domains SM
5.1.2-3 Talks about directing a call to a domans SBE
5.2.1-3 Talks about selecting both a O-SBE and T-SBE for a destination
6.1-3 Talks about next-hop IP address resolution

Already there is a great ongoing debate about how to provision all of the d=
atabases and ENUM servers used in these steps above. I wanted to suggest th=
at this entire scheme needs to be discussed in greater detail as this worki=
ng group moves forward. Consider the following...

1.) Cingular (ATT) reported that it had 51 million subscribers in June of 2=
005. I'm sure they have many more now.

Now lets make some working assumptions

1.) With a 11% busy hour, there would be 5.61 million users on their phone
2.) Assuming 40% were "outbound network terminations", this would mean ther=
e would be 2.244 million outbound peering calls
3.) Assuming 20% were "inbound network terminations", this would mean there=
 would be 1.122 million inbound peering calls
3.) Assuming a 3 minute call hold time, this would create a PEERING call si=
gnaling rate of 18,700 calls per second (successful calls).
4.) Assuming an Answer Seizure Ration of 80%, then the number of call signa=
led attempts would be 23,375 per second
5.) The number of GiGE's to support the media traffic would be 420, or 42 1=
0GigE's
6.) The number of stateless proxies (assuming 2000 CPS) would be 12.
7.) The number of SBE proxies (assuming 200 CPS) would be 120.

Not knowing anything about this network in particular, my guess is there wo=
uld be an attempt to have DBE regionally to optimize media path. The number=
 of locations and size of each location is not easy for me to contemplate -=
- but for illustrative purposes, lets say there are 40 locations where ther=
e is a desire to have DBE equipment for optimized media flows.

Now the fun part.....

For the simplest use case of direct peering, and in the simplest case, assu=
me the carrier is identical in size. The carriers on both sides have the sa=
me number of elements in equal proportion. So here is what we have...

40 physical locations -- at which there are:
a.) 120 SBE's facing 120 SBE's across a direct peering border
b.) somewhere between 42 and 420 DBE's on each side facing each other
c.) At least 12 routing proxies on each side sending calls to the 120 SBE's=
.

The ability to provision this equipment, and share the IP Addresses with bo=
th sides, and maintain the service state of these physical links is not tri=
vial. Data must be exchanged to expose SBE addresses, and consequently DBE =
addresses for use. This is clearly within the Scope of this working group i=
n my opinion.

The belief that a routing proxy can "hunt and peck" its way to an open chan=
nel is simply impossible. There needs to be a serious look at taking the ad=
vertised capabilities exchange that must occur to provision and manage this=
 direct relationship and using that information along with some 'soft state=
' about rates and loads to solve this problem. There is no way an ENUM serv=
er or data base without network state than can solve the routing problem we=
 have here.

Said another way, until we look at making the layer 5 routing schemes paral=
lel the way layer 3 routing schemes work, we will never reach the kind of s=
cale I have presented here. If you want to really complicate the problem co=
nsider this reasonable guess. If our sample customer (ATT) were to have 100=
% IP Peering in the future -- it would be distributed something like...

1.) 15% to Sprint
2.) 20% to Verizon Wireless
3.) 10% to Verizon Wireline
3.) 20% to ATT Wireline
4.) 10% to Qwest
5.) 15% to a large host of others

CONCLUSION:

Static location functions and ENUM functions can be very useful in locating=
 a Terminating SSP Domain

BUT ...

We need a set of network protocols that can establish and maintain routing =
information bases that can make this kind of interconnection work with scal=
e in a very dynamic way. I think this working group is only just beginning.

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



From speermint-bounces@ietf.org Wed Nov 28 18:35:33 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxWRG-0005oy-VU; Wed, 28 Nov 2007 18:35:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWRG-0005os-F0
	for speermint@ietf.org; Wed, 28 Nov 2007 18:35:30 -0500
Received: from mail43.messagelabs.com ([216.82.249.163])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxWRF-0001Gv-VB
	for speermint@ietf.org; Wed, 28 Nov 2007 18:35:30 -0500
X-VirusChecked: Checked
X-Env-Sender: daryl@level3.net
X-Msg-Ref: server-14.tower-43.messagelabs.com!1196292896!11687592!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [209.245.18.107]
Received: (qmail 11481 invoked from network); 28 Nov 2007 23:34:56 -0000
Received: from unknown.level3.net (HELO f10cc8-10.level3.com) (209.245.18.107)
	by server-14.tower-43.messagelabs.com with SMTP;
	28 Nov 2007 23:34:56 -0000
Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57])
	by f10cc8-10.level3.com (Postfix) with ESMTP id 204AD33A4;
	Wed, 28 Nov 2007 23:34:56 +0000 (GMT)
Subject: RE: [Speermint] [wg-business]
	WGLC	fordraft-ietf-speermint-terminology-13
From: Daryl Malas <daryl@level3.net>
To: James McEachern <jmce@nortel.com>
In-Reply-To: <F1A1D21DA394814E824AC89F5A005BA314D42D39@zcarhxm0.corp.nortel.com>
References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0441C05@GBNTHT12009MSX.gb002.siemens.net>
	<F1A1D21DA394814E824AC89F5A005BA314D42D39@zcarhxm0.corp.nortel.com>
Content-Type: text/plain
Date: Wed, 28 Nov 2007 16:45:25 -0700
Message-Id: <1196293525.1297.405.camel@montag.eng.level3.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.0 (2.6.0-1) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

I think I am actually more of a fan of the "add SIP" to "service
provider" in Section 4.2 (and, throughout the document as necessary) for
this reference.  Then, it will directly relate back to the definition of
a SSP in Section 3.9.

--Daryl

On Wed, 2007-11-28 at 00:53 -0500, James McEachern wrote:
> Comments inline.
> 
> John Elwell wrote:
> 
> --- snip ----
>   
>   > > Finally, and again I apologize for the lateness of this comment,
> the
>   > > definition of Service Provider in section 3.8 suggests that the
> term
>   > > "Service Provider" when used without the preceding "SIP"
>   > > means an entity
>   > > that only provides layer 3 functionality.  This definition
> conflicts
>   > > with usage later in this and other documents.  (e.g. section
>   > > 4.2 states:
>   > > "Layer 5 (Session) peering refers to interconnection of two
> service
>   > > providers...".)  We either need to add "SIP" before "service
> provider"
>   > > (in several places) or modify the definition slightly.
>   > >
>   > > Perhaps change the existing text:
>   > > "A Service Provider (or SP) is defined to be an entity that
> provides
>   > > layer 3 (IP) transport of SIP signaling and media packets."
>   > >
>   > > Change to:
>   > > "A Service Provider (or SP) is defined to be an entity that
> provides
>   > > layer 3 (IP) transport of SIP signaling and media packets,
>   > > and may also
>   > > provide layer 5 processing of SIP signaling and media packets."
>   > [JRE] This change doesn't work for me. I think we need to go for
> your
>   > other proposal (inserting "SIP" in appropriate places).
>   > 
>   > John
> [jmce]  I've gone through most of the drafts to identify where we would
> need to make changes by inserting "SIP".  I've found over 20 instances
> already, along with a dozen or so that simply say "provider" - and hence
> presumably need to add "SIP Service".  Before I document all of these
> instances, I just want to ensure that the group wants to go this route,
> rather than the simpler choice of changing the definition.
> 
> Let me know.
> 
> Jim
> 
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint


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



From speermint-bounces@ietf.org Thu Nov 29 09:22:00 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxkH7-00056U-UF; Thu, 29 Nov 2007 09:21:57 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxkH7-00056D-9Y
	for speermint@ietf.org; Thu, 29 Nov 2007 09:21:57 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxkH5-0005AY-Mr
	for speermint@ietf.org; Thu, 29 Nov 2007 09:21:57 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2007 09:21:55 -0500
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lATELtu0022115; 
	Thu, 29 Nov 2007 09:21:55 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lATELoBq011715; 
	Thu, 29 Nov 2007 14:21:55 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 29 Nov 2007 09:21:42 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Review of draft-ietf-speermint-architecture-04
Date: Thu, 29 Nov 2007 09:22:03 -0500
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E303F9FB84@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <20071128132835.GA29883@nic.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] Review of draft-ietf-speermint-architecture-04
Thread-Index: Acgxwp/27pL2LEYGSCOgfZou65SAGwA0BgYQ
References: <20071128132835.GA29883@nic.at>
From: "Michael Hammer (mhammer)" <mhammer@cisco.com>
To: "Otmar Lendl" <lendl@nic.at>, <speermint@ietf.org>
X-OriginalArrivalTime: 29 Nov 2007 14:21:42.0711 (UTC)
	FILETIME=[2A0C9C70:01C83293]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16640; t=1196346115;
	x=1197210115; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mhammer@cisco.com;
	z=From:=20=22Michael=20Hammer=20(mhammer)=22=20<mhammer@cisco.com>
	|Subject:=20RE=3A=20[Speermint]=20Review=20of=20draft-ietf-speermint-arch
	itecture-04 |Sender:=20
	|To:=20=22Otmar=20Lendl=22=20<lendl@nic.at>,=20<speermint@ietf.org>;
	bh=tkXn0SI3x2m/4eOuJQEESf173M7CHU/Myyib9dxFCRU=;
	b=atE/W4/wSjbqBSkdwgyXq5xGfJyXPS76MHzM1KoEgi91cbSVjQEklM9woX/s1rTpwg9lEP3t
	P8aBX1sb25Kc1qnztUioY9YSoS17M8aYfPPPDqXn4Ds6ixxO5Q56Pyrs;
Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Otmar,

Agree with the sentiment that the enterprise v. carrier distinction
should have no effect on the protocol aspects.  However, it still needs
to be identified so that folks don't lose sight of it and design some
roadblock into the protocol work that would prevent enterprises from
using it.  The technical details can have a way of wandering if we lose
sight of all the possible end results.  Our job should be to ensure that
the distinction is one of business agreements, not technical agreements.

Mike
=20

> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]=20
> Sent: Wednesday, November 28, 2007 8:29 AM
> To: speermint@ietf.org
> Subject: [Speermint] Review of draft-ietf-speermint-architecture-04
>=20
>=20
> I can't remember that we discussed that draft during the last=20
> two meetings. The current agenda gives 40 mins for this=20
> draft, so took another look at this document.
>=20
> >Abstract
> >
> >   This document defines the SPEERMINT peering architecture, its =20
> >   functional components and peering interface functions. It also=20
> >  describes the steps taken to establish a session between=20
> two peering  =20
>=20
> General comment:=20
>=20
> We now finally have once again a document which lists the=20
> requirements on what the speermint architecture is supposed=20
> to solve. That list isn't done yet, but still it would be=20
> worthwhile to look at the architecture document with an eye=20
> for the requirements.
>=20
> As the requirements draft changed substantially recently,=20
> this draft also needs to reflect this.
>=20
> >2. Network Context
> >
> >=20
> >   Figure 1 shows an example network context.=20
>=20
> I find this figure to be more confusing than helping.
>=20
> >   Two SIP providers can form =20
> >   a Layer 5 peer over either the public Internet or private=20
> Layer 3 =20
> >   networks. In addition, two or more providers may form a=20
> SIP (Layer 5) =20
> >   federation [17] on either the public Internet or private Layer 3 =20
> >   networks. This document does not make any assumption=20
> whether the SIP =20
> >   providers directly peer to each other or through Layer 3 transit =20
> >   network as per use case of [16].  =20
>=20
> fine.
>=20
> >=20
> >   Note that Figure 1 allows for the following potential SPEERMINT =20
> >   peering scenarios: =20
> >=20
> >   o  Enterprise to Enterprise across the public Internet
> >=20
> >   o  Enterprise to Service Provider across the public Internet
> >=20
> >   o  Service Provider to Service Provider across the public Internet
> >=20
> >   o  Enterprise to enterprise across a private Layer 3 network
> >=20
> >   o  Enterprise to Service Provider across a private Layer 3 network
> >=20
> >   o  Service Provider to Service Provider across a private Layer 3 =20
> >      network
>=20
> I see no reasons to treat Enterprises any different from=20
> Service Providers. Yes, there may be legal and regulatory=20
> issues specific to these cases, but from a pure protocol=20
> point of view, I see no need to add this distinction. (BGP=20
> doesn't care whether layer 3 peering partners are ISPs or=20
> enterprises, too.)
>=20
> >   The members of a federation may jointly use a set of=20
> functions such =20
> >   as location peering function, application function, subscriber =20
> >   database function, SIP proxies, and/or functions that synthesize =20
> >   various SIP and non-SIP based applications. Similarly,=20
> two providers =20
> >   may jointly use a set of peering functions. The=20
> federation functions =20
> >   or the peering functions can be either public or private. =20
>=20
> Hu?=20
>=20
> >3. Procedures
> >
> >=20
> >   This document assumes that a call from an end user in the=20
> initiating =20
> >   peer goes through the following steps to establish a call=20
> to an end =20
> >   user in the receiving peer:  =20
> >=20
> >         1. The analysis of a target address.  =20
> >=20
> >             a. If the target address represents an=20
> intra-VSP resource, =20
> >                we go directly to step 4. =20
>=20
> SSP, not VSP.=20
>=20
> Case a. doesn't fit in here as we're considering calls to other SSPs.
> (we're not covering calls to voicemail and other types of=20
> calls, either.)
>=20
> So what's the result of this analysis?
>=20
> >         2. the discovery of the receiving peering point address,
>=20
> Does this include the determination of whether there is a peering?
>=20
> >=20
> >         3. the enforcement of authentication and other policy,
> >=20
> >         4. the discovery of end user address,  =20
> >=20
> >         5. the routing of SIP messages,
> >=20
> >         6. the session establishment,  =20
> >=20
> >         7. the transfer of media,
> >=20
> >         8. and the session termination.  =20
> >=20
> >4. Reference SPEERMINT Architecture
> >=20
> >   The procedures presented in Chapter 3 are implemented by=20
> a set of =20
> >   peering functions:  =20
> >
> >   o  Location Function (LF): Purpose is to develop Session =20
> >      Establishment Data (SED) by discovering the Signaling Function=20
> >     (SF) and the end user's reachable host (IP address and=20
> port). The
>=20
> I'm not sure whether we should include purely internal=20
> functions in this document. For all we care, the terminating=20
> SSP could route all calls to voicemail, to a PSTN gateway, to=20
> a H.323 gate, to a Skype gateway or whatnot.
>=20
> >      location function is distributed across the Location=20
> Server (LS) =20
> >      and Session Manager (SM).=20
> >=20
> >5.1. The Location Function (LF) of an Initiating Provider
> >
> >   Purpose is to develop Session Establishment Data (SED) [12] by=20
> >   discovering the Signaling Function (SF), and end user's reachable=20
> >   host (IP address and host). The LF of an Initiating=20
> provider analyzes  =20
> >   target address and discovers the next hop signaling=20
> function (SF) in=20
> >   a peering relationship using DNS, SIP Redirect Server, or a =20
> >   functional equivalent database.   =20
>=20
> Good. As this is the crux of the matter, I recommend to=20
> either completely strike the DNS/SIP/DB half-sentence or=20
> *really* explain what happens.
>=20
> >5.1.1. Target address analysis
> >
> >   When the initiating provider receives a request to=20
> communicate, the =20
> >   initiating provider analyzes the target state data to determine =20
> >   whether the call needs to be terminated internal or=20
> external to its =20
> >   network. The analysis method is internal to the=20
> provider's policy; =20
> >   thus, outside the scope of SPEERMINT. Note that the peer=20
> is free to =20
> >   consult any manner of private data sources to make this =20
> >   determination. =20
> >=20
> >   If the target address does not represent a resource inside the =20
> >   initiating peer's administrative domain or federation of=20
> domains, the =20
> >   initiating provider resolves the call routing data by using the =20
> >   Location Function (LF). Examples of the LF are the=20
> functions of ENUM, =20
> >   Routing Table, SIP DNS, and SIP Redirect Server. =20
>=20
> As above, this is TAMO.  (then a miracle occurs)
>=20
> >5.1.3. Carrier ENUM lookup
>=20
> Infrastructure ENUM.
>=20
> >
> >   Next the initiating peer checks for a carrier-of-record=20
> in a carrier =20
> >   ENUM domain according to the procedures described in=20
> [12].  As in the =20
> >   previous step, the peer MAY consult a cache or alternate =20
> >   representation of the ENUM data in lieu of actual DNS=20
> queries.  The =20
> >   peer first checks for records for the "E2U+sip"=20
> enumservice, then for =20
> >   the "E2U+pstn" enumservice as defined in [21].  If a=20
> terminal record =20
> >   is found with a sip: or sips: URI, the peer skips to=20
> Section 5.1.5, =20
> >   otherwise the peer continues processing according to the next =20
> >   section. =20
>=20
> See comment to 5.2.1
>=20
> >=20
> >5.1.4. Routing Table
> >
> >   If there is no user ENUM records and the initiating peer cannot =20
> >   discover the carrier-of-record or if the initiating peer=20
> cannot reach =20
> >   the carrier-of-record via SIP peering, the initiating peer still =20
> >   needs to deliver the call to the PSTN or reject the call.=20
>  Note that =20
> >   the initiating peer MAY still sends the call to another=20
> provider for =20
> >   PSTN gateway termination by prior arrangement using a=20
> routing table.  =20
> >   If so, the initiating peer rewrites the Request-URI to=20
> address the =20
> >   gateway resource in the target provider's domain and MAY=20
> forward the =20
> >   request on to that provider using the procedures=20
> described in the =20
> >   remainder of these steps. =20
>=20
> The indirect peering option is missing here. There could be a=20
> transit SSP who does noch act as PSTN gateway, but simply as SIP hop.
>=20
> >=20
> >5.1.5. SIP DNS Resolution
> >
> >   Once a sip: or sips: in an external domain is selected as=20
> the target,=20
> >   the initiating peer MAY apply local policy to decide whether=20
> >   forwarding requests to the target domain is acceptable. =20
>=20
> Well, maybe the target domain also has some say in whether it=20
> will accept calls via SIP from the originating domain.
>=20
> again, see comment to 5.2.1.
>=20
> >5.1.6. SIP Redirect Server   =20
> >
> >   A SIP Redirect Server may help in resolving current address of a =20
> >   mobile target address. =20
>=20
> hu?
>=20
> "mobile" in the sense of nomadic use, i.e. the current IP=20
> address of the user's phone? No, that's LF territory.=20
>=20
> "mobile" in the sense of fixed/mobile convergence? Number porting?
> You lost me here.
>=20
> >5.2. The Location Function (LF) of a Receiving Provider
> >
> >5.2.1. Publish ENUM records
> >
> >   The receiving peer SHOULD participate by publishing=20
> "E2U+sip" and =20
> >   "E2U+pstn" records with sip: or sips: URIs wherever a=20
> public carrier =20
> >   ENUM root is available.  This assumes that the receiving=20
> peer wants =20
> >   to peer by default.  Even when the receiving peer does=20
> not want to =20
> >   accept traffic from specific initiating peers, it MAY=20
> still reject =20
> >   requests on a case-by-case basis. =20
>=20
> This is one of the core questions for the whole speermint=20
> architecture.
>=20
> I do not think we can assume that a receiving peer wants to=20
> peer by default.
> Quite to the contrary: As I see it, the primary reason for=20
> the existence of speermint is that fact that this is NOT=20
> TRUE. If it were true, then
> RFC3261/3263 plus ENUM would be sufficient for universal SIP=20
> interconnection.
>=20
> Can we *please* get consensus on this question in Vancouver?
>=20
> Second question:
>=20
> 	Assuming what the receiving peer will only accept calls from
> 	specific initiating peers, can we handle the rejections on=20
> 	the SIP layer?
>=20
> My answer (from
> http://www.enum.at/ietf/draft-lendl-sip-peering-policy-00.html
>  on) has always been that we cannot do that. The main reasons=20
> are that some SSPs will elect to only run SIP ingress points=20
> within private interconnection networks and not on the public=20
> Internet. Or if they do, they will be firewalled so that=20
> INVITES from unwanted peers will be rejected on the IP layer.=20
> Others might place restrictions on the TLS parameters of=20
> incoming SIP connection: when the wrong TLS certs are=20
> presented, no SIP communication is possible.
>=20
> Once again, can we get this sorted out in Vancouver?
>=20
> >=20
> >5.2.2. Publish SIP DNS records
> >
> >   To receive peer requests, the receiving peer MUST insure=20
> that it   =20
> >   publishes appropriate NAPTR, SRV, and address (A and/or=20
> AAAA) records    =20
> >   in the global DNS that resolve an appropriate transport,=20
> port, and   =20
> >   address to a relevant SIP server.   =20
>=20
> How does this square with
>=20
>       Requirement #3: the mechanisms recommended for the=20
> declaration and
>       advertisement of SBE and SDE entities must allow for peer and
>       media variability.
>=20
>       Notes on solution space: for advertising peer-dependent=20
> SBEs (peer
>       variability), the solution space based on is under specified and
>       there are no know best current practices.=20
>=20
> from the requirements draft?
>=20
> >5.4.1. Setup TLS connection
> >
> >   Once a transport, port, and address are found, the=20
> initiating peer=20
> >   will open or find a reusable TLS connection to the peer.  The=20
> >   initiating provider MUST verify the server certificate=20
> which SHOULD=20
> >   be rooted in a well-known certificate authority.  The initiating=20
> >   provider MUST be prepared to provide a TLS client=20
> certificate upon=20
> >   request during the TLS handshake.  The client certificate MUST=20
> >   contain a DNS or URI choice type in the subjectAltName which=20
> >   corresponds to the domain asserted in the host production=20
> of the From=20
> >   header URI.  The certificate SHOULD be valid and rooted=20
> in a well-=20
> >   known certificate authority.=20
>=20
> How does this work in the case on the second leg of an=20
> inderect peering?
> In that case the domain in the From: header does not belong=20
> the transit SSP.
>=20
> >=20
> >   Note that the client certificate MAY contain a list of=20
> entries in the=20
> >   subjectAltName, only one of which has to match the domain=20
> in the From=20
> >   header URI.=20
>=20
> Can this work if customer-owned domains hosted with SSPs take=20
> off the same way they did for e-mail? In other words, what=20
> happens when ATT hosts the SIP service for a few thousand domains?
>=20
> >   SHOULD be a global-number.  For example, the following are all=20
> >   acceptable, the first three are encouraged:=20
> >=20
> >   From: "John Doe" <john.doe@example.net>=20
> >   From: "+12125551212" <+12125551212@example.net;user=3Dphone>=20
> >   From: "Anonymous" <anonymous@example.net>
>=20
> This is fine.
>=20
> >5.5.2. Receive SIP requests
> >
> >   Once a TLS connection is established, the receiving peer=20
> is prepared=20
> >   to receive incoming SIP requests.  For new dialog-forming=20
> requests=20
> >   and out-of-dialog requests, the receiving peer verifies that the=20
> >   target (request-URI) is a domain which for which it is=20
> responsible.=20
>=20
> Once again, this does not seem to cover indirect peering.
>=20
> >=20
> >   The receiving peer MAY reject incoming requests due to=20
> local policy.=20
> >   When a request is rejected because the initiating peer is not=20
> >   authorized to peer, the receiving peer SHOULD respond with a 403=20
> >   response with the reason phrase "Unsupported Peer".=20
>=20
> What is the initiating peer supposed to do in this case?
>=20
> * For E.164 number based dialing, it could bounce the call to=20
> the PSTN.
>=20
> * For SIP URI dialed calls: ???
>=20
> Perhaps there is a path via a transit SIP operator? How will=20
> the initiating peer learn about this other path?
>=20
> >6. Call Control and Media Control Deployment Options
> >
> >   In a decomposed model, SF and MF are implemented in=20
> separate peering =20
> >   logical elements. Signaling functions are implemented in=20
> a proxy and =20
> >   media functions are implemented in another logical element.  The =20
> >   scaling of signaling versus scaling of media may differ between =20
> >   applications.  Decomposing allows each to follow a=20
> separate migration =20
> >   path. =20
>=20
> Is the protocol between the SF and the MF in scope for speermint?=20
> I have no clue what is used there.
>=20
> >
> >7. Address space considerations
> >
>=20
> fine.
>=20
> Let the discussion begin.
>=20
> /ol
> --
> / Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
> \ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

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



From speermint-bounces@ietf.org Thu Nov 29 11:25:10 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxmCK-00069p-5G; Thu, 29 Nov 2007 11:25:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmCJ-00069e-4F
	for speermint@ietf.org; Thu, 29 Nov 2007 11:25:07 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmCF-0001co-UZ
	for speermint@ietf.org; Thu, 29 Nov 2007 11:25:07 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235])
	by siemenscomms.co.uk (PMDF V6.3-x14 #31430)
	with ESMTP id <0JSA00E0R09P5T@siemenscomms.co.uk> for
	speermint@ietf.org; Thu, 29 Nov 2007 16:25:02 +0000 (GMT)
Date: Thu, 29 Nov 2007 16:25:00 +0000
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Speermint] Review of draft-ietf-speermint-architecture-04
In-reply-to: A
	<072C5B76F7CEAB488172C6F64B30B5E303F9FB84@xmb-rtp-20b.amer.cisco.com>
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>, Otmar Lendl <lendl@nic.at>,
	speermint@ietf.org
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0490F46@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [Speermint] Review of draft-ietf-speermint-architecture-04
Thread-Index: Acgxwp/27pL2LEYGSCOgfZou65SAGwA0BgYQAARnXgA=
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <20071128132835.GA29883@nic.at> A
	<072C5B76F7CEAB488172C6F64B30B5E303F9FB84@xmb-rtp-20b.amer.cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

I agree with what Michael says here.

John=20

> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20
> Sent: 29 November 2007 14:22
> To: Otmar Lendl; speermint@ietf.org
> Subject: RE: [Speermint] Review of=20
> draft-ietf-speermint-architecture-04
>=20
> Otmar,
>=20
> Agree with the sentiment that the enterprise v. carrier distinction
> should have no effect on the protocol aspects.  However, it=20
> still needs
> to be identified so that folks don't lose sight of it and design some
> roadblock into the protocol work that would prevent enterprises from
> using it.  The technical details can have a way of wandering=20
> if we lose
> sight of all the possible end results.  Our job should be to=20
> ensure that
> the distinction is one of business agreements, not technical=20
> agreements.
>=20
> Mike
> =20
>=20
> > -----Original Message-----
> > From: Otmar Lendl [mailto:lendl@nic.at]=20
> > Sent: Wednesday, November 28, 2007 8:29 AM
> > To: speermint@ietf.org
> > Subject: [Speermint] Review of draft-ietf-speermint-architecture-04
> >=20
> >=20
> > I can't remember that we discussed that draft during the last=20
> > two meetings. The current agenda gives 40 mins for this=20
> > draft, so took another look at this document.
> >=20
> > >Abstract
> > >
> > >   This document defines the SPEERMINT peering architecture, its =20
> > >   functional components and peering interface functions. It also=20
> > >  describes the steps taken to establish a session between=20
> > two peering  =20
> >=20
> > General comment:=20
> >=20
> > We now finally have once again a document which lists the=20
> > requirements on what the speermint architecture is supposed=20
> > to solve. That list isn't done yet, but still it would be=20
> > worthwhile to look at the architecture document with an eye=20
> > for the requirements.
> >=20
> > As the requirements draft changed substantially recently,=20
> > this draft also needs to reflect this.
> >=20
> > >2. Network Context
> > >
> > >=20
> > >   Figure 1 shows an example network context.=20
> >=20
> > I find this figure to be more confusing than helping.
> >=20
> > >   Two SIP providers can form =20
> > >   a Layer 5 peer over either the public Internet or private=20
> > Layer 3 =20
> > >   networks. In addition, two or more providers may form a=20
> > SIP (Layer 5) =20
> > >   federation [17] on either the public Internet or=20
> private Layer 3 =20
> > >   networks. This document does not make any assumption=20
> > whether the SIP =20
> > >   providers directly peer to each other or through Layer=20
> 3 transit =20
> > >   network as per use case of [16].  =20
> >=20
> > fine.
> >=20
> > >=20
> > >   Note that Figure 1 allows for the following potential=20
> SPEERMINT =20
> > >   peering scenarios: =20
> > >=20
> > >   o  Enterprise to Enterprise across the public Internet
> > >=20
> > >   o  Enterprise to Service Provider across the public Internet
> > >=20
> > >   o  Service Provider to Service Provider across the=20
> public Internet
> > >=20
> > >   o  Enterprise to enterprise across a private Layer 3 network
> > >=20
> > >   o  Enterprise to Service Provider across a private=20
> Layer 3 network
> > >=20
> > >   o  Service Provider to Service Provider across a=20
> private Layer 3 =20
> > >      network
> >=20
> > I see no reasons to treat Enterprises any different from=20
> > Service Providers. Yes, there may be legal and regulatory=20
> > issues specific to these cases, but from a pure protocol=20
> > point of view, I see no need to add this distinction. (BGP=20
> > doesn't care whether layer 3 peering partners are ISPs or=20
> > enterprises, too.)
> >=20
> > >   The members of a federation may jointly use a set of=20
> > functions such =20
> > >   as location peering function, application function, subscriber =20
> > >   database function, SIP proxies, and/or functions that=20
> synthesize =20
> > >   various SIP and non-SIP based applications. Similarly,=20
> > two providers =20
> > >   may jointly use a set of peering functions. The=20
> > federation functions =20
> > >   or the peering functions can be either public or private. =20
> >=20
> > Hu?=20
> >=20
> > >3. Procedures
> > >
> > >=20
> > >   This document assumes that a call from an end user in the=20
> > initiating =20
> > >   peer goes through the following steps to establish a call=20
> > to an end =20
> > >   user in the receiving peer:  =20
> > >=20
> > >         1. The analysis of a target address.  =20
> > >=20
> > >             a. If the target address represents an=20
> > intra-VSP resource, =20
> > >                we go directly to step 4. =20
> >=20
> > SSP, not VSP.=20
> >=20
> > Case a. doesn't fit in here as we're considering calls to=20
> other SSPs.
> > (we're not covering calls to voicemail and other types of=20
> > calls, either.)
> >=20
> > So what's the result of this analysis?
> >=20
> > >         2. the discovery of the receiving peering point address,
> >=20
> > Does this include the determination of whether there is a peering?
> >=20
> > >=20
> > >         3. the enforcement of authentication and other policy,
> > >=20
> > >         4. the discovery of end user address,  =20
> > >=20
> > >         5. the routing of SIP messages,
> > >=20
> > >         6. the session establishment,  =20
> > >=20
> > >         7. the transfer of media,
> > >=20
> > >         8. and the session termination.  =20
> > >=20
> > >4. Reference SPEERMINT Architecture
> > >=20
> > >   The procedures presented in Chapter 3 are implemented by=20
> > a set of =20
> > >   peering functions:  =20
> > >
> > >   o  Location Function (LF): Purpose is to develop Session =20
> > >      Establishment Data (SED) by discovering the=20
> Signaling Function=20
> > >     (SF) and the end user's reachable host (IP address and=20
> > port). The
> >=20
> > I'm not sure whether we should include purely internal=20
> > functions in this document. For all we care, the terminating=20
> > SSP could route all calls to voicemail, to a PSTN gateway, to=20
> > a H.323 gate, to a Skype gateway or whatnot.
> >=20
> > >      location function is distributed across the Location=20
> > Server (LS) =20
> > >      and Session Manager (SM).=20
> > >=20
> > >5.1. The Location Function (LF) of an Initiating Provider
> > >
> > >   Purpose is to develop Session Establishment Data (SED) [12] by=20
> > >   discovering the Signaling Function (SF), and end user's=20
> reachable=20
> > >   host (IP address and host). The LF of an Initiating=20
> > provider analyzes  =20
> > >   target address and discovers the next hop signaling=20
> > function (SF) in=20
> > >   a peering relationship using DNS, SIP Redirect Server, or a =20
> > >   functional equivalent database.   =20
> >=20
> > Good. As this is the crux of the matter, I recommend to=20
> > either completely strike the DNS/SIP/DB half-sentence or=20
> > *really* explain what happens.
> >=20
> > >5.1.1. Target address analysis
> > >
> > >   When the initiating provider receives a request to=20
> > communicate, the =20
> > >   initiating provider analyzes the target state data to=20
> determine =20
> > >   whether the call needs to be terminated internal or=20
> > external to its =20
> > >   network. The analysis method is internal to the=20
> > provider's policy; =20
> > >   thus, outside the scope of SPEERMINT. Note that the peer=20
> > is free to =20
> > >   consult any manner of private data sources to make this =20
> > >   determination. =20
> > >=20
> > >   If the target address does not represent a resource inside the =20
> > >   initiating peer's administrative domain or federation of=20
> > domains, the =20
> > >   initiating provider resolves the call routing data by=20
> using the =20
> > >   Location Function (LF). Examples of the LF are the=20
> > functions of ENUM, =20
> > >   Routing Table, SIP DNS, and SIP Redirect Server. =20
> >=20
> > As above, this is TAMO.  (then a miracle occurs)
> >=20
> > >5.1.3. Carrier ENUM lookup
> >=20
> > Infrastructure ENUM.
> >=20
> > >
> > >   Next the initiating peer checks for a carrier-of-record=20
> > in a carrier =20
> > >   ENUM domain according to the procedures described in=20
> > [12].  As in the =20
> > >   previous step, the peer MAY consult a cache or alternate =20
> > >   representation of the ENUM data in lieu of actual DNS=20
> > queries.  The =20
> > >   peer first checks for records for the "E2U+sip"=20
> > enumservice, then for =20
> > >   the "E2U+pstn" enumservice as defined in [21].  If a=20
> > terminal record =20
> > >   is found with a sip: or sips: URI, the peer skips to=20
> > Section 5.1.5, =20
> > >   otherwise the peer continues processing according to the next =20
> > >   section. =20
> >=20
> > See comment to 5.2.1
> >=20
> > >=20
> > >5.1.4. Routing Table
> > >
> > >   If there is no user ENUM records and the initiating=20
> peer cannot =20
> > >   discover the carrier-of-record or if the initiating peer=20
> > cannot reach =20
> > >   the carrier-of-record via SIP peering, the initiating=20
> peer still =20
> > >   needs to deliver the call to the PSTN or reject the call.=20
> >  Note that =20
> > >   the initiating peer MAY still sends the call to another=20
> > provider for =20
> > >   PSTN gateway termination by prior arrangement using a=20
> > routing table.  =20
> > >   If so, the initiating peer rewrites the Request-URI to=20
> > address the =20
> > >   gateway resource in the target provider's domain and MAY=20
> > forward the =20
> > >   request on to that provider using the procedures=20
> > described in the =20
> > >   remainder of these steps. =20
> >=20
> > The indirect peering option is missing here. There could be a=20
> > transit SSP who does noch act as PSTN gateway, but simply=20
> as SIP hop.
> >=20
> > >=20
> > >5.1.5. SIP DNS Resolution
> > >
> > >   Once a sip: or sips: in an external domain is selected as=20
> > the target,=20
> > >   the initiating peer MAY apply local policy to decide whether=20
> > >   forwarding requests to the target domain is acceptable. =20
> >=20
> > Well, maybe the target domain also has some say in whether it=20
> > will accept calls via SIP from the originating domain.
> >=20
> > again, see comment to 5.2.1.
> >=20
> > >5.1.6. SIP Redirect Server   =20
> > >
> > >   A SIP Redirect Server may help in resolving current=20
> address of a =20
> > >   mobile target address. =20
> >=20
> > hu?
> >=20
> > "mobile" in the sense of nomadic use, i.e. the current IP=20
> > address of the user's phone? No, that's LF territory.=20
> >=20
> > "mobile" in the sense of fixed/mobile convergence? Number porting?
> > You lost me here.
> >=20
> > >5.2. The Location Function (LF) of a Receiving Provider
> > >
> > >5.2.1. Publish ENUM records
> > >
> > >   The receiving peer SHOULD participate by publishing=20
> > "E2U+sip" and =20
> > >   "E2U+pstn" records with sip: or sips: URIs wherever a=20
> > public carrier =20
> > >   ENUM root is available.  This assumes that the receiving=20
> > peer wants =20
> > >   to peer by default.  Even when the receiving peer does=20
> > not want to =20
> > >   accept traffic from specific initiating peers, it MAY=20
> > still reject =20
> > >   requests on a case-by-case basis. =20
> >=20
> > This is one of the core questions for the whole speermint=20
> > architecture.
> >=20
> > I do not think we can assume that a receiving peer wants to=20
> > peer by default.
> > Quite to the contrary: As I see it, the primary reason for=20
> > the existence of speermint is that fact that this is NOT=20
> > TRUE. If it were true, then
> > RFC3261/3263 plus ENUM would be sufficient for universal SIP=20
> > interconnection.
> >=20
> > Can we *please* get consensus on this question in Vancouver?
> >=20
> > Second question:
> >=20
> > 	Assuming what the receiving peer will only accept calls from
> > 	specific initiating peers, can we handle the rejections on=20
> > 	the SIP layer?
> >=20
> > My answer (from
> > http://www.enum.at/ietf/draft-lendl-sip-peering-policy-00.html
> >  on) has always been that we cannot do that. The main reasons=20
> > are that some SSPs will elect to only run SIP ingress points=20
> > within private interconnection networks and not on the public=20
> > Internet. Or if they do, they will be firewalled so that=20
> > INVITES from unwanted peers will be rejected on the IP layer.=20
> > Others might place restrictions on the TLS parameters of=20
> > incoming SIP connection: when the wrong TLS certs are=20
> > presented, no SIP communication is possible.
> >=20
> > Once again, can we get this sorted out in Vancouver?
> >=20
> > >=20
> > >5.2.2. Publish SIP DNS records
> > >
> > >   To receive peer requests, the receiving peer MUST insure=20
> > that it   =20
> > >   publishes appropriate NAPTR, SRV, and address (A and/or=20
> > AAAA) records    =20
> > >   in the global DNS that resolve an appropriate transport,=20
> > port, and   =20
> > >   address to a relevant SIP server.   =20
> >=20
> > How does this square with
> >=20
> >       Requirement #3: the mechanisms recommended for the=20
> > declaration and
> >       advertisement of SBE and SDE entities must allow for peer and
> >       media variability.
> >=20
> >       Notes on solution space: for advertising peer-dependent=20
> > SBEs (peer
> >       variability), the solution space based on is under=20
> specified and
> >       there are no know best current practices.=20
> >=20
> > from the requirements draft?
> >=20
> > >5.4.1. Setup TLS connection
> > >
> > >   Once a transport, port, and address are found, the=20
> > initiating peer=20
> > >   will open or find a reusable TLS connection to the peer.  The=20
> > >   initiating provider MUST verify the server certificate=20
> > which SHOULD=20
> > >   be rooted in a well-known certificate authority.  The=20
> initiating=20
> > >   provider MUST be prepared to provide a TLS client=20
> > certificate upon=20
> > >   request during the TLS handshake.  The client certificate MUST=20
> > >   contain a DNS or URI choice type in the subjectAltName which=20
> > >   corresponds to the domain asserted in the host production=20
> > of the From=20
> > >   header URI.  The certificate SHOULD be valid and rooted=20
> > in a well-=20
> > >   known certificate authority.=20
> >=20
> > How does this work in the case on the second leg of an=20
> > inderect peering?
> > In that case the domain in the From: header does not belong=20
> > the transit SSP.
> >=20
> > >=20
> > >   Note that the client certificate MAY contain a list of=20
> > entries in the=20
> > >   subjectAltName, only one of which has to match the domain=20
> > in the From=20
> > >   header URI.=20
> >=20
> > Can this work if customer-owned domains hosted with SSPs take=20
> > off the same way they did for e-mail? In other words, what=20
> > happens when ATT hosts the SIP service for a few thousand domains?
> >=20
> > >   SHOULD be a global-number.  For example, the following are all=20
> > >   acceptable, the first three are encouraged:=20
> > >=20
> > >   From: "John Doe" <john.doe@example.net>=20
> > >   From: "+12125551212" <+12125551212@example.net;user=3Dphone>=20
> > >   From: "Anonymous" <anonymous@example.net>
> >=20
> > This is fine.
> >=20
> > >5.5.2. Receive SIP requests
> > >
> > >   Once a TLS connection is established, the receiving peer=20
> > is prepared=20
> > >   to receive incoming SIP requests.  For new dialog-forming=20
> > requests=20
> > >   and out-of-dialog requests, the receiving peer verifies=20
> that the=20
> > >   target (request-URI) is a domain which for which it is=20
> > responsible.=20
> >=20
> > Once again, this does not seem to cover indirect peering.
> >=20
> > >=20
> > >   The receiving peer MAY reject incoming requests due to=20
> > local policy.=20
> > >   When a request is rejected because the initiating peer is not=20
> > >   authorized to peer, the receiving peer SHOULD respond=20
> with a 403=20
> > >   response with the reason phrase "Unsupported Peer".=20
> >=20
> > What is the initiating peer supposed to do in this case?
> >=20
> > * For E.164 number based dialing, it could bounce the call to=20
> > the PSTN.
> >=20
> > * For SIP URI dialed calls: ???
> >=20
> > Perhaps there is a path via a transit SIP operator? How will=20
> > the initiating peer learn about this other path?
> >=20
> > >6. Call Control and Media Control Deployment Options
> > >
> > >   In a decomposed model, SF and MF are implemented in=20
> > separate peering =20
> > >   logical elements. Signaling functions are implemented in=20
> > a proxy and =20
> > >   media functions are implemented in another logical=20
> element.  The =20
> > >   scaling of signaling versus scaling of media may differ=20
> between =20
> > >   applications.  Decomposing allows each to follow a=20
> > separate migration =20
> > >   path. =20
> >=20
> > Is the protocol between the SF and the MF in scope for speermint?=20
> > I have no clue what is used there.
> >=20
> > >
> > >7. Address space considerations
> > >
> >=20
> > fine.
> >=20
> > Let the discussion begin.
> >=20
> > /ol
> > --
> > / Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
> > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
> > \ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /
> >=20
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> >=20
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

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



From speermint-bounces@ietf.org Thu Nov 29 14:23:03 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IxoyS-0004Px-3s; Thu, 29 Nov 2007 14:23:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoyQ-0004Pj-Fl
	for speermint@ietf.org; Thu, 29 Nov 2007 14:22:58 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxoyP-0003JY-FT
	for speermint@ietf.org; Thu, 29 Nov 2007 14:22:58 -0500
Received: from ([24.40.15.92])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH7.39684309;
	Thu, 29 Nov 2007 14:22:44 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	PACDCEXCSMTP03.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:22:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] [wg-business]
	WGLCfor	draft-ietf-speermint-terminology-13
Date: Thu, 29 Nov 2007 14:22:44 -0500
Message-ID: <45AEC6EF95942140888406588E1A66020307DAB0@PACDCEXCMB04.cable.comcast.com>
In-Reply-To: <1196116382.1297.401.camel@montag.eng.level3.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] [wg-business]
	WGLCfor	draft-ietf-speermint-terminology-13
Thread-Index: AcgweuqAgZi4SoVOSryLqQYW2xac9gCQe9Mg
References: <45AEC6EF95942140888406588E1A66020307D6DA@PACDCEXCMB04.cable.comcast.com>
	<F1A1D21DA394814E824AC89F5A005BA314CB08B7@zcarhxm0.corp.nortel.com>
	<1196100278.1297.397.camel@montag.eng.level3.com>
	<1196116382.1297.401.camel@montag.eng.level3.com>
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Daryl Malas" <daryl@level3.net>,
	"James McEachern" <jmce@nortel.com>
X-OriginalArrivalTime: 29 Nov 2007 19:22:45.0094 (UTC)
	FILETIME=[38118860:01C832BD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32
Cc: speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Actually, please email the ID editor with the new -14 version and email
the file to the list.  I would like folks to come to the meeting next
week with this new version in case it comes up for discussion.

Regards
Jason=20

> -----Original Message-----
> From: Daryl Malas [mailto:daryl@level3.net]=20
> Sent: Monday, November 26, 2007 5:33 PM
> To: James McEachern
> Cc: speermint@ietf.org; Livingood, Jason
> Subject: RE: [Speermint] [wg-business] WGLCfor=20
> draft-ietf-speermint-terminology-13
>=20
> FYI..due to the cutoff date, and the fact I cannot submit a=20
> new rev until 12/3; feel free to provide comments up to 12/2.
>=20
> Thanks...--Daryl
>=20
> On Mon, 2007-11-26 at 11:04 -0700, Daryl Malas wrote:
> > Jim,
> >=20
> > I will update the draft today and submit a new revision. =20
> Thanks for=20
> > your comments and feedback.
> >=20
> > --Daryl
> >=20
> > On Mon, 2007-11-26 at 11:37 -0500, James McEachern wrote:
> > > Jason,
> > > I realize this is after the deadline, but I went over all=20
> the drafts=20
> > > again this weekend, and couldn't help but notice the=20
> inconsistencies.
> > > (It is definitely getting better, but not quite there yet...)
> > >=20
> > > I know you probably don't want to revisit figure 1, but in its=20
> > > current form it seems to me that it is most definitely=20
> wrong.  For=20
> > > example, this figure shows that the "Lookup of SRV/A and AAAA in=20
> > > DNS" is out of scope for SPEERMINT.  This would suggest that your=20
> > > excellent draft on the "Use of DNS and NAPTR Records for=20
> SPEERMINT"=20
> > > is entirely out of scope for SPEERMINT.  This seems just=20
> plain wrong to me.
> > > After re-reading all the drafts this weekend, it seems to=20
> me that we=20
> > > are really talking about something that is better=20
> described by the=20
> > > following
> > > diagram:
> > >=20
> > >            E.164 number =20
> > >                 |=20
> > >                 | <--- ENUM lookup of NAPTR in Domain=20
> Name System (DNS)=20
> > >                 |
> > >            Lookup=20
> > >            Discovery=20
> > >            SIP URI=20
> > >                 |=20
> > >                 | ENUM Working Group Scope=20
> > >           =20
> =
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=20
> > >                 | SPEERMINT Working Group Scope=20
> > >                 |                                             \
> > >                 | <--- Federation Detection, Policy           |=20
> > >                 |      Lookup, and Service Location           |
> > >                 |                                        =20
>     | Session
> > >                 |
> > > |Establishment
> > >            Hostname <--- Addressing and session=20
> establishment \ Data=20
> > >                 |                                        =20
>     /(SED)
> > >=20
> > >                 |                                             |
> > >                 | <--- Lookup of SRV/A and AAAA in DNS        |
> > >                 |                                             |
> > >                 |                                             |
> > >            IP address                                         |
> > >                 |                                             /
> > >                 | SPEERMINT Working Group Scope=20
> > >           =20
> =
=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=20
> > >                 | Out of scope for the SPEERMINT Working Group=20
> > >                 |
> > >                 | <--- Routing protocols, ARP [14] etc.=20
> > >                 |=20
> > >            MAC-address
> > >=20
> > >                   Figure 1: Session Peering Context
> > >=20
> > > If this isn't the scope, then there are many other pieces that do=20
> > > not really make sense.
> > >=20
> > > Finally, and again I apologize for the lateness of this=20
> comment, the=20
> > > definition of Service Provider in section 3.8 suggests=20
> that the term=20
> > > "Service Provider" when used without the preceding "SIP" means an=20
> > > entity that only provides layer 3 functionality.  This definition=20
> > > conflicts with usage later in this and other documents. =20
> (e.g. section 4.2 states:
> > > "Layer 5 (Session) peering refers to interconnection of=20
> two service
> > > providers...".)  We either need to add "SIP" before=20
> "service provider"
> > > (in several places) or modify the definition slightly. =20
> > >=20
> > > Perhaps change the existing text:
> > > "A Service Provider (or SP) is defined to be an entity=20
> that provides=20
> > > layer 3 (IP) transport of SIP signaling and media packets."
> > >=20
> > > Change to:
> > > "A Service Provider (or SP) is defined to be an entity=20
> that provides=20
> > > layer 3 (IP) transport of SIP signaling and media=20
> packets, and may=20
> > > also provide layer 5 processing of SIP signaling and=20
> media packets."
> > >=20
> > > If that change doesn't work for people, then there are a=20
> number of=20
> > > other places where I believe we need to add the work=20
> "SIP" in front=20
> > > of "service provider" or we are talking about layer 5 functions=20
> > > being performed by an entity that is only supposed to=20
> work at layer 3.
> > >=20
> > > Jim McEachern
> > >=20
> > >   > -----Original Message-----
> > >   > From: Livingood, Jason=20
> [mailto:Jason_Livingood@cable.comcast.com]
> > >   > Sent: Thursday, November 08, 2007 4:23 PM
> > >   > To: speermint@ietf.org
> > >   > Subject: [Speermint] [wg-business] WGLC for=20
> draft-ietf-speermint-
> > >   > terminology-13
> > >   >=20
> > >   > 	Title           : SPEERMINT Terminology
> > >   > 	Author(s)       : D. Malas, D. Meyer
> > >   > 	Filename        :=20
> draft-ietf-speermint-terminology-13.txt
> > >   > 	Pages           : 13
> > >   > 	Date            : 2007-11-08
> > >   >=20
> > >   > This document defines the terminology that is to be used in=20
> > > describing
> > >   > Session PEERing for Multimedia INTerconnect (SPEERMINT).
> > >   >=20
> > >   > A URL for this Internet-Draft is:
> > >   >
> > >=20
> http://www.ietf.org/internet-drafts/draft-ietf-speermint-termi
nology-13.
> > >   > txt
> > >   >
> > >=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >   > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >   > The intent of the last call is to solicit comments before=20
> > > submitting the
> > >   > ID to the IESG.
> > >   >=20
> > >   > The purpose of a working group Last Call is in the style of=20
> > > "speak now
> > >   > or forever hold your peace" in case there are=20
> fundamental objections
> > >   > which have not gotten previous or adequate=20
> discussion, or minor=20
> > > errors
> > >   > which need correction.
> > >   >=20
> > >   > Working group last call will extend for 2 weeks from today, 8=20
> > > November
> > >   > 2007, until 22 November 2007.  Please note that this is the=20
> > > second WGLC
> > >   > on this document.
> > >   >=20
> > >   > Please post any comments in reply to the list, as=20
> well as to the
> > >   > editor(s) of this draft.
> > >   >=20
> > >   > Regards,
> > >   >=20
> > >   > Jason & Dave
> > >   >=20
> > >   > _______________________________________________
> > >   > Speermint mailing list
> > >   > Speermint@ietf.org
> > >   > https://www1.ietf.org/mailman/listinfo/speermint
> > >   >=20
> > >   > _______________________________________________
> > >   > Speermint mailing list
> > >   > Speermint@ietf.org
> > >   > https://www1.ietf.org/mailman/listinfo/speermint
> > >=20
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
> >=20
> >=20
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
>=20
>=20

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



From speermint-bounces@ietf.org Thu Nov 29 14:28:32 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ixp3n-0006W3-RN; Thu, 29 Nov 2007 14:28:31 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixp3m-0006Vr-NI
	for speermint@ietf.org; Thu, 29 Nov 2007 14:28:30 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixp3k-0002tO-Uu
	for speermint@ietf.org; Thu, 29 Nov 2007 14:28:30 -0500
Received: from ([10.195.246.152])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH7.39684695;
	Thu, 29 Nov 2007 14:28:09 -0500
Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by
	NJMDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:28:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Review of draft-ietf-speermint-architecture-04
Date: Thu, 29 Nov 2007 14:28:09 -0500
Message-ID: <45AEC6EF95942140888406588E1A66020307DAB3@PACDCEXCMB04.cable.comcast.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0490F46@GBNTHT12009MSX.gb002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] Review of draft-ietf-speermint-architecture-04
Thread-Index: Acgxwp/27pL2LEYGSCOgfZou65SAGwA0BgYQAARnXgAABmbMYA==
References: <20071128132835.GA29883@nic.at>
	A<072C5B76F7CEAB488172C6F64B30B5E303F9FB84@xmb-rtp-20b.amer.cisco.com>
	<0D5F89FAC29E2C41B98A6A762007F5D0490F46@GBNTHT12009MSX.gb002.siemens.net>
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Elwell, John" <john.elwell@siemens.com>,
	"Michael Hammer \(mhammer\)" <mhammer@cisco.com>,
	"Otmar Lendl" <lendl@nic.at>, <speermint@ietf.org>
X-OriginalArrivalTime: 29 Nov 2007 19:28:09.0630 (UTC)
	FILETIME=[F981CBE0:01C832BD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0d6b5666eba887052ef5e87a9de0d3b8
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

I agree with Michael as well.

Jason=20

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]=20
> Sent: Thursday, November 29, 2007 11:25 AM
> To: Michael Hammer (mhammer); Otmar Lendl; speermint@ietf.org
> Subject: RE: [Speermint] Review of=20
> draft-ietf-speermint-architecture-04
>=20
> I agree with what Michael says here.
>=20
> John=20
>=20
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> > Sent: 29 November 2007 14:22
> > To: Otmar Lendl; speermint@ietf.org
> > Subject: RE: [Speermint] Review of
> > draft-ietf-speermint-architecture-04
> >=20
> > Otmar,
> >=20
> > Agree with the sentiment that the enterprise v. carrier distinction=20
> > should have no effect on the protocol aspects.  However, it still=20
> > needs to be identified so that folks don't lose sight of it=20
> and design=20
> > some roadblock into the protocol work that would prevent=20
> enterprises=20
> > from using it.  The technical details can have a way of=20
> wandering if=20
> > we lose sight of all the possible end results.  Our job=20
> should be to=20
> > ensure that the distinction is one of business agreements, not=20
> > technical agreements.
> >=20
> > Mike
> > =20
> >=20
> > > -----Original Message-----
> > > From: Otmar Lendl [mailto:lendl@nic.at]
> > > Sent: Wednesday, November 28, 2007 8:29 AM
> > > To: speermint@ietf.org
> > > Subject: [Speermint] Review of=20
> draft-ietf-speermint-architecture-04
> > >=20
> > >=20
> > > I can't remember that we discussed that draft during the last two=20
> > > meetings. The current agenda gives 40 mins for this=20
> draft, so took=20
> > > another look at this document.
> > >=20
> > > >Abstract
> > > >
> > > >   This document defines the SPEERMINT peering=20
> architecture, its =20
> > > >   functional components and peering interface=20
> functions. It also =20
> > > > describes the steps taken to establish a session between
> > > two peering  =20
> > >=20
> > > General comment:=20
> > >=20
> > > We now finally have once again a document which lists the=20
> > > requirements on what the speermint architecture is supposed to=20
> > > solve. That list isn't done yet, but still it would be=20
> worthwhile to=20
> > > look at the architecture document with an eye for the=20
> requirements.
> > >=20
> > > As the requirements draft changed substantially recently,=20
> this draft=20
> > > also needs to reflect this.
> > >=20
> > > >2. Network Context
> > > >
> > > >=20
> > > >   Figure 1 shows an example network context.=20
> > >=20
> > > I find this figure to be more confusing than helping.
> > >=20
> > > >   Two SIP providers can form =20
> > > >   a Layer 5 peer over either the public Internet or private
> > > Layer 3
> > > >   networks. In addition, two or more providers may form a
> > > SIP (Layer 5)
> > > >   federation [17] on either the public Internet or
> > private Layer 3
> > > >   networks. This document does not make any assumption
> > > whether the SIP
> > > >   providers directly peer to each other or through Layer
> > 3 transit
> > > >   network as per use case of [16].  =20
> > >=20
> > > fine.
> > >=20
> > > >=20
> > > >   Note that Figure 1 allows for the following potential
> > SPEERMINT
> > > >   peering scenarios: =20
> > > >=20
> > > >   o  Enterprise to Enterprise across the public Internet
> > > >=20
> > > >   o  Enterprise to Service Provider across the public Internet
> > > >=20
> > > >   o  Service Provider to Service Provider across the
> > public Internet
> > > >=20
> > > >   o  Enterprise to enterprise across a private Layer 3 network
> > > >=20
> > > >   o  Enterprise to Service Provider across a private
> > Layer 3 network
> > > >=20
> > > >   o  Service Provider to Service Provider across a
> > private Layer 3
> > > >      network
> > >=20
> > > I see no reasons to treat Enterprises any different from Service=20
> > > Providers. Yes, there may be legal and regulatory issues=20
> specific to=20
> > > these cases, but from a pure protocol point of view, I=20
> see no need=20
> > > to add this distinction. (BGP doesn't care whether layer=20
> 3 peering=20
> > > partners are ISPs or enterprises, too.)
> > >=20
> > > >   The members of a federation may jointly use a set of
> > > functions such
> > > >   as location peering function, application function,=20
> subscriber =20
> > > >   database function, SIP proxies, and/or functions that
> > synthesize
> > > >   various SIP and non-SIP based applications. Similarly,
> > > two providers
> > > >   may jointly use a set of peering functions. The
> > > federation functions
> > > >   or the peering functions can be either public or private. =20
> > >=20
> > > Hu?=20
> > >=20
> > > >3. Procedures
> > > >
> > > >=20
> > > >   This document assumes that a call from an end user in the
> > > initiating
> > > >   peer goes through the following steps to establish a call
> > > to an end
> > > >   user in the receiving peer:  =20
> > > >=20
> > > >         1. The analysis of a target address.  =20
> > > >=20
> > > >             a. If the target address represents an
> > > intra-VSP resource,
> > > >                we go directly to step 4. =20
> > >=20
> > > SSP, not VSP.=20
> > >=20
> > > Case a. doesn't fit in here as we're considering calls to
> > other SSPs.
> > > (we're not covering calls to voicemail and other types of calls,=20
> > > either.)
> > >=20
> > > So what's the result of this analysis?
> > >=20
> > > >         2. the discovery of the receiving peering point address,
> > >=20
> > > Does this include the determination of whether there is a peering?
> > >=20
> > > >=20
> > > >         3. the enforcement of authentication and other policy,
> > > >=20
> > > >         4. the discovery of end user address,  =20
> > > >=20
> > > >         5. the routing of SIP messages,
> > > >=20
> > > >         6. the session establishment,  =20
> > > >=20
> > > >         7. the transfer of media,
> > > >=20
> > > >         8. and the session termination.  =20
> > > >=20
> > > >4. Reference SPEERMINT Architecture
> > > >=20
> > > >   The procedures presented in Chapter 3 are implemented by
> > > a set of
> > > >   peering functions:  =20
> > > >
> > > >   o  Location Function (LF): Purpose is to develop Session =20
> > > >      Establishment Data (SED) by discovering the
> > Signaling Function
> > > >     (SF) and the end user's reachable host (IP address and
> > > port). The
> > >=20
> > > I'm not sure whether we should include purely internal=20
> functions in=20
> > > this document. For all we care, the terminating SSP could=20
> route all=20
> > > calls to voicemail, to a PSTN gateway, to a H.323 gate,=20
> to a Skype=20
> > > gateway or whatnot.
> > >=20
> > > >      location function is distributed across the Location
> > > Server (LS)
> > > >      and Session Manager (SM).=20
> > > >=20
> > > >5.1. The Location Function (LF) of an Initiating Provider
> > > >
> > > >   Purpose is to develop Session Establishment Data=20
> (SED) [12] by=20
> > > >   discovering the Signaling Function (SF), and end user's
> > reachable
> > > >   host (IP address and host). The LF of an Initiating
> > > provider analyzes  =20
> > > >   target address and discovers the next hop signaling
> > > function (SF) in
> > > >   a peering relationship using DNS, SIP Redirect Server, or a =20
> > > >   functional equivalent database.   =20
> > >=20
> > > Good. As this is the crux of the matter, I recommend to either=20
> > > completely strike the DNS/SIP/DB half-sentence or
> > > *really* explain what happens.
> > >=20
> > > >5.1.1. Target address analysis
> > > >
> > > >   When the initiating provider receives a request to
> > > communicate, the
> > > >   initiating provider analyzes the target state data to
> > determine
> > > >   whether the call needs to be terminated internal or
> > > external to its
> > > >   network. The analysis method is internal to the
> > > provider's policy;
> > > >   thus, outside the scope of SPEERMINT. Note that the peer
> > > is free to
> > > >   consult any manner of private data sources to make this =20
> > > >   determination. =20
> > > >=20
> > > >   If the target address does not represent a resource=20
> inside the =20
> > > >   initiating peer's administrative domain or federation of
> > > domains, the
> > > >   initiating provider resolves the call routing data by
> > using the
> > > >   Location Function (LF). Examples of the LF are the
> > > functions of ENUM,
> > > >   Routing Table, SIP DNS, and SIP Redirect Server. =20
> > >=20
> > > As above, this is TAMO.  (then a miracle occurs)
> > >=20
> > > >5.1.3. Carrier ENUM lookup
> > >=20
> > > Infrastructure ENUM.
> > >=20
> > > >
> > > >   Next the initiating peer checks for a carrier-of-record
> > > in a carrier
> > > >   ENUM domain according to the procedures described in
> > > [12].  As in the
> > > >   previous step, the peer MAY consult a cache or alternate =20
> > > >   representation of the ENUM data in lieu of actual DNS
> > > queries.  The
> > > >   peer first checks for records for the "E2U+sip"=20
> > > enumservice, then for
> > > >   the "E2U+pstn" enumservice as defined in [21].  If a
> > > terminal record
> > > >   is found with a sip: or sips: URI, the peer skips to
> > > Section 5.1.5,
> > > >   otherwise the peer continues processing according to=20
> the next =20
> > > >   section. =20
> > >=20
> > > See comment to 5.2.1
> > >=20
> > > >=20
> > > >5.1.4. Routing Table
> > > >
> > > >   If there is no user ENUM records and the initiating
> > peer cannot
> > > >   discover the carrier-of-record or if the initiating peer
> > > cannot reach
> > > >   the carrier-of-record via SIP peering, the initiating
> > peer still
> > > >   needs to deliver the call to the PSTN or reject the call.=20
> > >  Note that
> > > >   the initiating peer MAY still sends the call to another
> > > provider for
> > > >   PSTN gateway termination by prior arrangement using a
> > > routing table.  =20
> > > >   If so, the initiating peer rewrites the Request-URI to
> > > address the
> > > >   gateway resource in the target provider's domain and MAY
> > > forward the
> > > >   request on to that provider using the procedures
> > > described in the
> > > >   remainder of these steps. =20
> > >=20
> > > The indirect peering option is missing here. There could be a=20
> > > transit SSP who does noch act as PSTN gateway, but simply
> > as SIP hop.
> > >=20
> > > >=20
> > > >5.1.5. SIP DNS Resolution
> > > >
> > > >   Once a sip: or sips: in an external domain is selected as
> > > the target,
> > > >   the initiating peer MAY apply local policy to decide whether=20
> > > >   forwarding requests to the target domain is acceptable. =20
> > >=20
> > > Well, maybe the target domain also has some say in=20
> whether it will=20
> > > accept calls via SIP from the originating domain.
> > >=20
> > > again, see comment to 5.2.1.
> > >=20
> > > >5.1.6. SIP Redirect Server   =20
> > > >
> > > >   A SIP Redirect Server may help in resolving current
> > address of a
> > > >   mobile target address. =20
> > >=20
> > > hu?
> > >=20
> > > "mobile" in the sense of nomadic use, i.e. the current IP=20
> address of=20
> > > the user's phone? No, that's LF territory.
> > >=20
> > > "mobile" in the sense of fixed/mobile convergence? Number porting?
> > > You lost me here.
> > >=20
> > > >5.2. The Location Function (LF) of a Receiving Provider
> > > >
> > > >5.2.1. Publish ENUM records
> > > >
> > > >   The receiving peer SHOULD participate by publishing
> > > "E2U+sip" and
> > > >   "E2U+pstn" records with sip: or sips: URIs wherever a
> > > public carrier
> > > >   ENUM root is available.  This assumes that the receiving
> > > peer wants
> > > >   to peer by default.  Even when the receiving peer does
> > > not want to
> > > >   accept traffic from specific initiating peers, it MAY
> > > still reject
> > > >   requests on a case-by-case basis. =20
> > >=20
> > > This is one of the core questions for the whole speermint=20
> > > architecture.
> > >=20
> > > I do not think we can assume that a receiving peer wants=20
> to peer by=20
> > > default.
> > > Quite to the contrary: As I see it, the primary reason for the=20
> > > existence of speermint is that fact that this is NOT TRUE. If it=20
> > > were true, then
> > > RFC3261/3263 plus ENUM would be sufficient for universal SIP=20
> > > interconnection.
> > >=20
> > > Can we *please* get consensus on this question in Vancouver?
> > >=20
> > > Second question:
> > >=20
> > > 	Assuming what the receiving peer will only accept calls from
> > > 	specific initiating peers, can we handle the rejections on=20
> > > 	the SIP layer?
> > >=20
> > > My answer (from
> > > http://www.enum.at/ietf/draft-lendl-sip-peering-policy-00.html
> > >  on) has always been that we cannot do that. The main reasons are=20
> > > that some SSPs will elect to only run SIP ingress points within=20
> > > private interconnection networks and not on the public=20
> Internet. Or=20
> > > if they do, they will be firewalled so that INVITES from unwanted=20
> > > peers will be rejected on the IP layer.
> > > Others might place restrictions on the TLS parameters of incoming=20
> > > SIP connection: when the wrong TLS certs are presented, no SIP=20
> > > communication is possible.
> > >=20
> > > Once again, can we get this sorted out in Vancouver?
> > >=20
> > > >=20
> > > >5.2.2. Publish SIP DNS records
> > > >
> > > >   To receive peer requests, the receiving peer MUST insure
> > > that it   =20
> > > >   publishes appropriate NAPTR, SRV, and address (A and/or
> > > AAAA) records    =20
> > > >   in the global DNS that resolve an appropriate transport,
> > > port, and   =20
> > > >   address to a relevant SIP server.   =20
> > >=20
> > > How does this square with
> > >=20
> > >       Requirement #3: the mechanisms recommended for the=20
> declaration=20
> > > and
> > >       advertisement of SBE and SDE entities must allow=20
> for peer and
> > >       media variability.
> > >=20
> > >       Notes on solution space: for advertising=20
> peer-dependent SBEs=20
> > > (peer
> > >       variability), the solution space based on is under
> > specified and
> > >       there are no know best current practices.=20
> > >=20
> > > from the requirements draft?
> > >=20
> > > >5.4.1. Setup TLS connection
> > > >
> > > >   Once a transport, port, and address are found, the
> > > initiating peer
> > > >   will open or find a reusable TLS connection to the peer.  The=20
> > > >   initiating provider MUST verify the server certificate
> > > which SHOULD
> > > >   be rooted in a well-known certificate authority.  The
> > initiating
> > > >   provider MUST be prepared to provide a TLS client
> > > certificate upon
> > > >   request during the TLS handshake.  The client=20
> certificate MUST=20
> > > >   contain a DNS or URI choice type in the subjectAltName which=20
> > > >   corresponds to the domain asserted in the host production
> > > of the From
> > > >   header URI.  The certificate SHOULD be valid and rooted
> > > in a well-
> > > >   known certificate authority.=20
> > >=20
> > > How does this work in the case on the second leg of an inderect=20
> > > peering?
> > > In that case the domain in the From: header does not belong the=20
> > > transit SSP.
> > >=20
> > > >=20
> > > >   Note that the client certificate MAY contain a list of
> > > entries in the
> > > >   subjectAltName, only one of which has to match the domain
> > > in the From
> > > >   header URI.=20
> > >=20
> > > Can this work if customer-owned domains hosted with SSPs take off=20
> > > the same way they did for e-mail? In other words, what=20
> happens when=20
> > > ATT hosts the SIP service for a few thousand domains?
> > >=20
> > > >   SHOULD be a global-number.  For example, the=20
> following are all=20
> > > >   acceptable, the first three are encouraged:=20
> > > >=20
> > > >   From: "John Doe" <john.doe@example.net>=20
> > > >   From: "+12125551212" <+12125551212@example.net;user=3Dphone>=20
> > > >   From: "Anonymous" <anonymous@example.net>
> > >=20
> > > This is fine.
> > >=20
> > > >5.5.2. Receive SIP requests
> > > >
> > > >   Once a TLS connection is established, the receiving peer
> > > is prepared
> > > >   to receive incoming SIP requests.  For new dialog-forming
> > > requests
> > > >   and out-of-dialog requests, the receiving peer verifies
> > that the
> > > >   target (request-URI) is a domain which for which it is
> > > responsible.=20
> > >=20
> > > Once again, this does not seem to cover indirect peering.
> > >=20
> > > >=20
> > > >   The receiving peer MAY reject incoming requests due to
> > > local policy.=20
> > > >   When a request is rejected because the initiating peer is not=20
> > > >   authorized to peer, the receiving peer SHOULD respond
> > with a 403
> > > >   response with the reason phrase "Unsupported Peer".=20
> > >=20
> > > What is the initiating peer supposed to do in this case?
> > >=20
> > > * For E.164 number based dialing, it could bounce the call to the=20
> > > PSTN.
> > >=20
> > > * For SIP URI dialed calls: ???
> > >=20
> > > Perhaps there is a path via a transit SIP operator? How will the=20
> > > initiating peer learn about this other path?
> > >=20
> > > >6. Call Control and Media Control Deployment Options
> > > >
> > > >   In a decomposed model, SF and MF are implemented in
> > > separate peering
> > > >   logical elements. Signaling functions are implemented in
> > > a proxy and
> > > >   media functions are implemented in another logical
> > element.  The
> > > >   scaling of signaling versus scaling of media may differ
> > between
> > > >   applications.  Decomposing allows each to follow a
> > > separate migration
> > > >   path. =20
> > >=20
> > > Is the protocol between the SF and the MF in scope for speermint?=20
> > > I have no clue what is used there.
> > >=20
> > > >
> > > >7. Address space considerations
> > > >
> > >=20
> > > fine.
> > >=20
> > > Let the discussion begin.
> > >=20
> > > /ol
> > > --
> > > / Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
> > > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
> > > \ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /
> > >=20
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >=20
> >=20
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> >=20
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

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



From speermint-bounces@ietf.org Thu Nov 29 16:10:06 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ixqe4-000344-OR; Thu, 29 Nov 2007 16:10:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixqe3-00033Z-Dc
	for speermint@ietf.org; Thu, 29 Nov 2007 16:10:03 -0500
Received: from nat.labs.nic.at ([83.136.33.3] helo=labs.nic.at)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixqe1-0003fj-IT
	for speermint@ietf.org; Thu, 29 Nov 2007 16:10:03 -0500
Received: from lendl by labs.nic.at with local (Exim 3.36 #1 (Debian))
	id 1Ixqe0-0008I7-00
	for <speermint@ietf.org>; Thu, 29 Nov 2007 22:10:00 +0100
Date: Thu, 29 Nov 2007 22:10:00 +0100
From: Otmar Lendl <lendl@nic.at>
To: speermint@ietf.org
Subject: Re: [Speermint] Review of draft-ietf-speermint-architecture-04
Message-ID: <20071129211000.GA31864@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org
References: <20071128132835.GA29883@nic.at>
	<0D5F89FAC29E2C41B98A6A762007F5D0490F46@GBNTHT12009MSX.gb002.siemens.net>
	<45AEC6EF95942140888406588E1A66020307DAB3@PACDCEXCMB04.cable.comcast.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45AEC6EF95942140888406588E1A66020307DAB3@PACDCEXCMB04.cable.comcast.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

On 2007/11/29 20:11, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote:
> I agree with Michael as well.
> 

Fine. We all agree on the substantive issue. I have no qualms with
mentioning the enterprise and carrier examples.

Can I have some responses to the other questions I raised in my review?

/ol
-- 
/ Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

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



From speermint-bounces@ietf.org Fri Nov 30 10:53:22 2007
Return-path: <speermint-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Iy8B2-0005fJ-AO; Fri, 30 Nov 2007 10:53:16 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8B0-0005en-U0
	for speermint@ietf.org; Fri, 30 Nov 2007 10:53:14 -0500
Received: from exprod7og101.obsmtp.com ([64.18.2.155])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy8B0-0005bg-Dc
	for speermint@ietf.org; Fri, 30 Nov 2007 10:53:14 -0500
Received: from source ([66.129.224.36]) by exprod7ob101.postini.com
	([64.18.6.12]) with SMTP; Fri, 30 Nov 2007 07:52:59 PST
Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 07:52:20 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Review of draft-ietf-speermint-architecture-04
Date: Fri, 30 Nov 2007 10:42:19 -0500
Message-ID: <9BD5D7887235424FA97DFC223CAE3C280BC10D41@proton.jnpr.net>
In-Reply-To: <20071129211000.GA31864@nic.at>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Speermint] Review of draft-ietf-speermint-architecture-04
Thread-Index: AcgyzEyzdtmLHSMZRw2ahdHKdXn8zAAmxuTQ
From: "Reinaldo Penno" <rpenno@juniper.net>
To: "Otmar Lendl" <lendl@nic.at>,
	<speermint@ietf.org>
X-OriginalArrivalTime: 30 Nov 2007 15:52:20.0258 (UTC)
	FILETIME=[FD7E3020:01C83368]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: 
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Hello Otmar,

I'm following the discussions and read your comments. I wanted other
people to comment before committing to make any changes to the draft.

Thanks,

Reinaldo=20

> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]=20
> Sent: Thursday, November 29, 2007 1:10 PM
> To: speermint@ietf.org
> Subject: Re: [Speermint] Review of=20
> draft-ietf-speermint-architecture-04
>=20
> On 2007/11/29 20:11, "Livingood, Jason"=20
> <Jason_Livingood@cable.comcast.com> wrote:
> > I agree with Michael as well.
> >=20
>=20
> Fine. We all agree on the substantive issue. I have no qualms=20
> with mentioning the enterprise and carrier examples.
>=20
> Can I have some responses to the other questions I raised in=20
> my review?
>=20
> /ol
> --
> / Otmar Lendl <lendl@nic.at>, T: +43 1 5056416 - 33, F: - 933 \
> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
> \ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /
>=20
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>=20

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