Re: [Speermint] Meeting minutes from IETF 73 Speermint session (Arch Draft Review)

["James McEachern" <jmce at nortel.com>]

Daryl,
Comment inline...

Jim McEachern
T:+1 613 763-3419
M:+1 613 853-0176

-----Original Message-----
From: Daryl Malas [mailto:D.Malas at cablelabs.com] 
Sent: Friday, February 06, 2009 7:15 PM
To: McEachern, James (CAR:AR00); speermint at ietf.org
Subject: RE: [Speermint] RE: Meeting minutes from IETF 73 Speermint
session (Arch Draft Review) 

Jim et. al.,

Comments in-line...


----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas at cablelabs.com
 

> -----Original Message-----
> From: James McEachern [mailto:jmce at nortel.com] 
> Sent: Wednesday, February 04, 2009 8:24 PM
> To: Daryl Malas; speermint at ietf.org
> Subject: RE: [Speermint] RE: Meeting minutes from IETF 73 
> Speermint session (Arch Draft Review) 
> 

-------- snip -------------

> 
> 7. Section 5.1.2.3 SIP Redirect Server
> I am not at all certain this section adds value.  I would delete it.

I think the reason why this is in here is that a SIP Redirect is a very
viable alternative to ENUM.  One of the challenges this and several
Speermint documents face is placing too much emphasis on the use of ENUM
in peering.  While I believe this is a very efficient way for SSPs to
peer, not all SSPs are ready or plan to utilize ENUM.  What is a better
recommendation for documenting a very valid approach to peering simply
by using the constructs in SIP?

[jmce] Fair enough - I'm happy to leave it.  My hesitation was that the
trick is how you set up the magic database that the SIP Redirect Server
uses to find the route.  But I guess you could say exactly the same
about the magic used to populate ENUM.  So I'm fine with it as is.