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

["Daryl Malas" <D.Malas at cablelabs.com>]

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) 
> 
> Architecture Draft Review - Part 2
> 
> This email continues the detailed review of the Architecture 
> Draft Review from the point where I left off on my first email.
> 
> 1. Section 5.1.1.2.  User ENUM Lookup
> This section refers to the "peer" in several places.  This 
> should be changed to "SSP"
> 
> 2. Section 5.1.1.2 User ENUM Lookup
> This section states that "... the initiating peer [change to 
> "originating SSP] consults the public "User ENUM" ..."
> 
> I fully expect to be overruled here, but I strongly believe 
> that the query to User ENUM should be subject to local 
> policy, one important aspect of which would be the explicit 
> preferences of the originating UA.
> I would prefer to change "consults" to "may consult" - but as 
> I say, I am resigned to being overruled, if not flamed. 

First, I think "User ENUM" should be changed to "End User ENUM" as
described in RFC 5067.  I think this is the ENUM model being described
here.  Second, regarding your question, is there any reason why an SSP
could not participate in a peering relationship using End User,
Infrastructure, or Private ENUM models?  If this is the case, I think we
should either add a 3rd section for Private ENUM or indicate one of the
3 models may be used in 1 section.  Also, should *Next* be at the
beginning of Section 5.1.1.3?  I think an SSP could simply query an
Infrastructure ENUM server and derive the steps to reach the subscriber
at the target SSP peer.  I do not think it requires a query to each.  I
may be confused by the varying ENUM models, though.

> 
> 3. Section 5.1.1.3. Infrastructure ENUM Lookup Change 
> "initiating peer" to "originating SSP" and "peer" to "SSP"
> (several times).
> Change "carrier ENUM" to "Infrastructure ENUM".
> 
> 4. Section 5.1.2. Location Routing Function (LRF) Change 
> "Initiating SSP" to "Originating SSP".
> 
> This section also states that the LRF analyses the target 
> address and discovers the next hop...  I believe that the 
> analysis includes the target domain that was identified by 
> the LUF.  Therefore, with these two changes, I suggest this 
> section should read:
> "The LRF of the Originating SSP analyses target address and 
> target domain, identified by the LUF, and discovers the next 
> hop signaling function (SF) in the peering relationship. ..."
> 
> 5. Section 5.1.2.1. Routing Table
> I have several issues with this section.  
> First of all, I think it should be moved to after 5.1.2.2 SIP 
> DNS Resolution, since you should only be performing PSTN 
> breakout if SIP DNS resolution fails.
> Change "initiating" to "Originating", and "peer" to "SSP" throughout.
> 
> I believe that the third paragraph should be deleted.  The 
> first paragraph states that this section applies when you 
> "cannot discover the carrier-of-record or ... cannot reach it 
> via SIP peering" and then this paragraph goes on to say you 
> should forward to the target SSP using sip peering. Just 
> doesn't make sense.
> 
> The text beginning with the "Note" does seems confusing to 
> me.  How about starting a new paragraph at that point, and 
> use the following text (through to the new end of this section).
> "Note that the Originating SSP may still forward the call to 
> a PSTN gateway in another SSP by prior arrangement using the 
> routing table.  If so, the Originating SSP may rewrite the 
> Request-URI to address the PSTN gateway and may forward the 
> request to that SSP using SIP procedures."
> 
> 6. Section 5.1.2.2 SIP DNS Resolution
> As said earlier, this should go before the Routing Table section.
> This section also introduces a new term, the "receiving 
> peer".  This should be changed to "Target SSP".
> 
> 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?

> 
> 8. Section 5.1.3 The Signaling Function
> The first paragraph states that the SF can optionally perform 
> termination and re-initiation of a call, but the second 
> paragraph states that this is performed by the SBE.  Which is 
> it?  The third paragraph also says the SF can process SDP 
> payloads, which makes it a B2BUA.  As I understand it, a 
> B2BUA includes an SF (two actually) but an SF does not 
> include a B2BUA.
> 
> I think the problem is that this section is really describing 
> the SBE, which includes one or more signaling functions.  
> Calling it the SF just confuses the issue - or at least it 
> confuses me.  Why not just call a spade a spade, and write 
> this section as the SBE that can include signaling function, 
> modify SDP, etc.

Agreed.

> 
> 9. Section 5.1.3.1.1 TLS connection
> This section states that "the initiating [should be 
> "Originating"] SSP will open ... TLS connection".  I would 
> prefer to change "will" to "can"
> since there are circumstances where it is permissible to use 
> IPSec rather than TLS.
> 
> 10. Section 5.1.3.1.3 Co-Location
> Says that messages "would" be sent as clear text. I think it 
> would be better to say they "could" be sent as clear text.
> 
> 11. Sections 5.1.3.2 and 5.1.3.2.1
> Change "peer" to "SSP" - in several places.
> 
> ---- end of second comments email -----
> 
>  
> 
> Jim McEachern
> T:+1 613 763-3419
> M:+1 613 853-0176
> 
>