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

From: "Daryl Malas" <[email-masked]>
Date: Tue, 3 Feb 2009 10:02:13 -0700

Jim,

Thanks for the review.

Comments in-line...

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]

> -----Original Message-----
> From: James McEachern [mailto:[email-masked]] 
> Sent: Monday, January 26, 2009 8:28 PM
> To: [email-masked]
> Cc: Daryl Malas
> Subject: RE: [Speermint] Meeting minutes from IETF 73 
> Speermint session
> 
> Daryl,
> I volunteered to do a detailed review of the SPEERMINT 
> Peering Architecture draft, so in the spirit of "better late 
> than never" I will begin sending my comments to the list for 
> consideration.  My comments will be in several emails over 
> the rest of the week...
> 
> First a nit:
> 
> 1. References.  It appears that the references (at least in the
> introduction) are off by one. SPEERMINT Requirements is shown 
> as [13], but is actually [14] while Terminology is shown as 
> [12] but is [13] in the reference section.  I didn't go 
> further, but please check to ensure references are correct.
> 
> Next, a couple of general comments related to consistency:
> 
> 2. Originating vs. Initiating SSP: Sometimes we use one, 
> sometimes the other. In this case I'm pretty sure everyone 
> agrees on what we mean, so let's pick one or the other and 
> use it throughout.  (I'm kind of leaning toward "initiating" 
> but cold live with either.)

I personally prefer "originating".

> 
> 3. SSP vs. peer: Most of the time we use "SSP", but in some 
> sections we begin to use "peer". I think the term "peer" is 
> relative, and leaves us open to all sorts of confusion, while 
> the SSP is clear. My preference is to use SSP throughout, and 
> I will assume that in any remaining comments.

I agree with using SSP.

> 
> 4. Target vs. Terminating:  I'll save that one for later, as 
> I don't believe we all are in agreement just yet on that 
> particular one.

I think Jon made valid points at the last WG meeting that 'Target' is a
better term, since a call may be transferred or re-targeted later.  I
suggest we use 'Target'.

> 
> Now on to section specific comments:
> 
> 5. Section 2. Network Context, final paragraph says:
> " The members of a federation may jointly use a set of functions such 
>    as location function..."
> Comment: The terminology draft defines LUF and LRF, but does 
> not define "location function".  Similarly, this draft also 
> discusses LUF and LRF, but not "location function". 
> Recommended Solution:  Change "location function" to "Look-Up 
> Function, Location Routing Function,".  While we are at it, 
> we probably should capitalize the other functions the way we 
> have done in the Terminology draft.
> 
> 6. Section 3. Procedures,
> Bullet 5 states " the determination of the UAS,".
> Comment: This is unclear to me.  I think we are determining 
> something about the UAS, perhaps the location of the UAS.  If 
> this is correct, then we should change it to say this.

I agree this is a little too ambiguous.  I recommend we change it to
"determine the location of the target UA".  On a separate note, there
has been previous discussion on the use of UAC or UAS versus simply UA.
I believe in those previous discussions it was determined the preference
was to simply refer to either as a 'UA'.  This is a minor nit, but
believe it will make the draft more consistent with other similar IETF
works.

> 
> 7. Section 3. Procedures
> This section might be strengthened by changing to the active 
> voice.  For example, bullet 6 would be a lot clearer (to me 
> at least) if we just said "establish the session".  However, 
> I'm ok with group consensus on this one.

I am okay with either.  To me, they mean the same thing.

> 
> 8. Section 3. Procedures: 
> The final paragraph states that "In the case the target SSP 
> is different from the terminating SSP ...".  
> Comment: If we are going to open this can of worms (and I 
> fear we must) then it is crucial that we clearly define what 
> terminating and target SSP mean, and use them with absolute 
> consistency throughout the document.  If there was a 
> consensus on the list after Minneapolis, I missed it; to me 
> it sounded like two solitudes. 
> 
> Since I don't want to just raise issues, I am going to 
> propose what I think makes sense here, and let people react.
> Target SSP = the SSP we are currently trying to reach.  If 
> the session is "retargeted" then it is given a new target SSP 
> (unless of course the new target is in the same SSP).  This 
> seems consistent with general usage.
> Terminating SSP = the SSP where the session actually does terminate. 

I am glad you brought this issue up.  My preference is to simply scrap
"Terminating SSP" altogether.  IMO, it is to difficult for it to be
consistent.  If we must use it, I prefer we refer to "Terminating SSP"
only if the session actually *ends* there.  In this case, I mean a
successful "BYE" dialog occurs.  All other references should refer to
"Target SSP".

> 
> The remainder of my comments assume these definitions.  
> 
> In the spirit of making concrete suggestions, I would suggest 
> that the final paragraph of Section 3 be modified as follows:
> 
> Current text:
> "In the case the target SSP is different from the terminating SSP it 
>    would repeat steps 1-4. This is reflected in Figure 2 that 
> shows the 
>    target SSP with its own peering functions."
> 
> Change to:
> " In the case the initial target SSP is different from the 
> terminating SSP it would repeat steps 1-4. This is reflected 
> in Figure 2 that shows the 
>    target SSP with its own peering functions."

Keeping in the spirit of removing Terminating SSP, I would suggest we
change it to "In the case the target SSP changes during the session it
would repeat steps 1-4.  This is reflected in Figure 2 that shows the
target SSP with its own peering functions."

> 
> 9.  Section 5.1. Originating SSP Procedures We use 
> "originating SSP" in the section heading, but "initiating 
> SSP" in the body.
> 
> 10. Section 5.1.1. The Look-Up Function
> Currently states "Purpose is to determine the SF of the 
> target domain ..."
> Comment: Earlier in this document, and in the Terminology 
> draft, we state that the LUF determines the target domain - 
> not the SF of the target domain. In addition, we later state 
> that the LRF determines the location of the SF.  Therefore I 
> believe we should change as follows:
> Current text:
> "Purpose is to determine the SF of the target domain ..."
> 
> Change to:
> "Purpose is to determine the target domain ..."
> 
> 11. Section 5.1.1. The Look-Up Function
> Currently states "...optionally develop Session Establishment 
> Data (SED) [12]."  
> Comment: I believe this is only true when the target address 
> is in the same domain as the initiating SSP, otherwise the 
> LRF develops the SED.
> Therefore I suggest we change as follows:
> Current text:
> "... optionally develop Session Establishment Data (SED) [12]. "
> 
> Change to:
> "... if the target address is in the same administrative 
> domain as the initiating SSP, optionally develop Session 
> Establishment Data (SED) [12]. "
> 
> 12. Section 5.1.1.1 Target address analysis.
> Second paragraph states that
> "... the initiating SSP resolves the call routing data by 
> using the Location Routing Function (LRF)"
> 
> I suggest we recognize the step where the LUF first 
> determines the target domain, by changing the above to read:
> "... the initiating SSP first determines the target domain, 
> and then resolves the call routing data by using the Location 
> Routing Function (LRF)"
> 
> 13. Section 5.1.1.1 Target address analysis.
> The third paragraph begins with "For example...".  This confuses me.
> The previous paragraph ends by saying what the LRF does, but 
> then immediately gives examples of how the LUF works - at 
> least I think this is what it is providing.  At the very 
> least we need to somehow qualify the examples, though to be 
> honest I'd be happy if we just deleted the third and fourth 
> paragraphs..
> 
> ---- end of first set of comments ----
> 
> More comments to follow in a day or so.
> 
> 
> Jim McEachern
> T:+1 613 763-3419
> M:+1 613 853-0176
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daryl Malas
> Sent: Thursday, December 18, 2008 8:24 PM
> To: [email-masked]
> Cc: Alexander Mayrhofer; Livingood,Jason
> Subject: [Speermint] Meeting minutes from IETF 73 Speermint session
> 
> All,
> 
> The meeting minutes for the IETF 73 Speermint session can be 
> found here:
> 
> http://www.ietf.org/proceedings/08nov/minutes/speermint.txt
> 
> Please check the notes, as some of you volunteered to do 
> things...and, some by the end of the year (2008).  Also, 
> there were several issues that were going to be further 
> discussed on the mailing list.  Those of you presenting on 
> these topics, please start the threads.
> 
> If you have questions, concerns, or feel like something 
> important was left out let us know.
> 
> Thank you for your participation in Minneapolis.
> 
> Regards,
> 
> Daryl
> 
> Speermint co-Chair
> 
> 
> ----------------
> Daryl Malas
> CableLabs
> (o) +1 303 661 3302
> (f) +1 303 661 9199
> mailto:[email-masked]
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint
> 
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 3 Feb 2009 12:15:01 -0500

Daryl,

I believe the original intent of the Terminating SSP is to identify the
SSP serving the called party, i.e. the one that provides all the
services and functionality (beyond just call routing) for the person who
actually answers the call.  What used to be called supplementary
services.  It is not an intermediate node that is just playing the role
of an IXC switch.

This also plays into the idea of targeting being the intended end-user,
which through various features, like call forwarding, could be
re-targeted to another end-user.

In any case, so long as there is a distinction between intermediate hops
and the final point serving the end-user, we have done our job.  It is
not clear to me if you remove that term, then what term replaces it?

Mike

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Daryl Malas
> Sent: Tuesday, February 03, 2009 12:02 PM
> To: [email-masked]
> Subject: [Speermint] RE: Meeting minutes from IETF 73 Speermint
> session(Arch Draft Review)
> 
> Jim,
> 
> Thanks for the review.
> 
> Comments in-line...
> 
> 
> ----------------
> Daryl Malas
> CableLabs
> (o) +1 303 661 3302
> (f) +1 303 661 9199

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 3 Feb 2009 10:24:22 -0700

Mike,

While I want to try to avoid "violent agreement" on the use of this
term, I will clarify I was not referring to it as an IXC switch.  It is
more to indicate a UA that is the target for the session may not remain
the target, and "terminating" seems to indicate to me finality.  This
makes the term limiting and confusion, imo.

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

> From: Mike Hammer (hmmr) [mailto:[email-masked]] 
> Sent: Tuesday, February 03, 2009 10:15 AM
> To: Daryl Malas; [email-masked]
> Subject: RE: [Speermint] RE: Meeting minutes from IETF 73 
> Speermint session(Arch Draft Review)
> 
> Daryl,
> 
> I believe the original intent of the Terminating SSP is to 
> identify the SSP serving the called party, i.e. the one that 
> provides all the services and functionality (beyond just call 
> routing) for the person who actually answers the call.  What 
> used to be called supplementary services.  It is not an 
> intermediate node that is just playing the role of an IXC switch.
> 
> This also plays into the idea of targeting being the intended 
> end-user, which through various features, like call 
> forwarding, could be re-targeted to another end-user.
> 
> In any case, so long as there is a distinction between 
> intermediate hops and the final point serving the end-user, 
> we have done our job.  It is not clear to me if you remove 
> that term, then what term replaces it?
> 
> Mike
> 
> 
> 
> > > Subject: RE: [Speermint] Meeting minutes from IETF 73 Speermint 
> > > session
> > >
> > > Daryl,
> > > I volunteered to do a detailed review of the SPEERMINT Peering 
> > > Architecture draft, so in the spirit of "better late than 
> never" I 
> > > will begin sending my comments to the list for consideration.  My 
> > > comments will be in several emails over the rest of the week...
> > >
> > > First a nit:
> > >
> > > introduction) are off by one. SPEERMINT Requirements is shown as 
> > > [13], but is actually [14] while Terminology is shown as 
> [12] but is 
> > > [13] in the reference section.  I didn't go further, but please 
> > > check to ensure references are correct.
> > >
> sometimes 
> > > the other. In this case I'm pretty sure everyone agrees 
> on what we 
> > > mean, so let's pick one or the other and use it throughout.  (I'm 
> > > kind of leaning toward "initiating"
> > > 3. SSP vs. peer: Most of the time we use "SSP", but in 
> some sections 
> > > we begin to use "peer". I think the term "peer" is relative, and 
> > > leaves us open to all sorts of confusion, while the SSP 
> is clear. My 
> > > preference is to use SSP throughout, and I will assume 
> that in any 
> > > remaining comments.
> > 
> > I agree with using SSP.
> > 
> > >
> > > 4. Target vs. Terminating:  I'll save that one for later, 
> as I don't 
> > > believe we all are in agreement just yet on that particular one.
> > 
> > I think Jon made valid points at the last WG meeting that 
> 'Target' is
> a
> > > Comment: The terminology draft defines LUF and LRF, but does not 
> > > define "location function".  Similarly, this draft also discusses 
> > > LUF and LRF, but not "location function".
> > > Function, Location Routing Function,".  While we are at it, we 
> > > probably should capitalize the other functions the way we 
> have done 
> > > something about the UAS, perhaps the location of the UAS. 
>  If this 
> > > is correct, then we should change it to say this.
> > 
> > > This section might be strengthened by changing to the 
> active voice.  
> > > For example, bullet 6 would be a lot clearer (to me at 
> least) if we 
> > > just said "establish the session".  However, I'm ok with group 
> > > consensus on this one.
> > 
> > > The final paragraph states that "In the case the target SSP is 
> > > different from the terminating SSP ...".
> > > Comment: If we are going to open this can of worms (and I fear we 
> > > must) then it is crucial that we clearly define what 
> terminating and 
> > > target SSP mean, and use them with absolute consistency 
> throughout 
> > > the document.  If there was a consensus on the list after 
> > > Minneapolis, I missed it; to me it sounded like two solitudes.
> > >
> propose what 
> > > I think makes sense here, and let people react.
> > > Target SSP = the SSP we are currently trying to reach.  If the 
> > > session is "retargeted" then it is given a new target SSP 
> (unless of 
> > > course the new target is in the same SSP).  This seems consistent 
> > > with general usage.
> > > In the spirit of making concrete suggestions, I would 
> suggest that 
> > > the final paragraph of Section 3 be modified as follows:
> > >
> > > Current text:
> > >    would repeat steps 1-4. This is reflected in Figure 2 
> that shows 
> > > the
> > > terminating SSP it would repeat steps 1-4. This is reflected in 
> > > Figure 2 that shows the
> "originating SSP" 
> > > in the section heading, but "initiating SSP" in the body.
> > >
> > > 10. Section 5.1.1. The Look-Up Function Currently states 
> "Purpose is 
> > > to determine the SF of the target domain ..."
> draft, we 
> > > state that the LUF determines the target domain - not the 
> SF of the 
> > > target domain. In addition, we later state that the LRF 
> determines 
> > > the location of the SF.  Therefore I believe we should change as 
> > > follows:
> > > Current text:
> > > 11. Section 5.1.1. The Look-Up Function Currently states 
> > > "...optionally develop Session Establishment Data (SED) [12]."
> > > Comment: I believe this is only true when the target 
> address is in 
> > > the same domain as the initiating SSP, otherwise the LRF develops 
> > > the SED.
> domain as 
> > > the initiating SSP, optionally develop Session Establishment Data 
> > > (SED) [12]. "
> > >
> determines the 
> > > target domain, by changing the above to read:
> > > "... the initiating SSP first determines the target 
> domain, and then 
> > > resolves the call routing data by using the Location Routing 
> > > Function (LRF)"
> > >
> > > The previous paragraph ends by saying what the LRF does, but then 
> > > immediately gives examples of how the LUF works - at 
> least I think 
> > > this is what it is providing.  At the very least we need 
> to somehow 
> > > qualify the examples, though to be honest I'd be happy if we just 
> > > deleted the third and fourth paragraphs..
> > >
> > > The meeting minutes for the IETF 73 Speermint session can 
> be found 
> > > here:
> > >
> there were 
> > > several issues that were going to be further discussed on the 
> > > mailing list.  Those of you presenting on these topics, 
> please start 
> > > the threads.
> > >
> > > If you have questions, concerns, or feel like something important 
> > > was left out let us know.
> > >

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 3 Feb 2009 12:53:47 -0500

Daryl,

Understand.  Calls can be forwarded and redirected in various ways.

So, the goal is to use the term "Target SSP" with the idea that
eventually the call gets "completed" and "terminates" at some place
where an end-user can start receiving media?

I am ok with that.  I just wanted to have distinction between nodes that
target calls and those that just route them.  Maybe one day SIP gets the
Request-URI and Route headers to have such a clean distinction as well.

Mike

> From: Daryl Malas [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2009 12:24 PM
> To: Mike Hammer (hmmr); [email-masked]
> Subject: RE: [Speermint] RE: Meeting minutes from IETF 73 Speermint
[mailto:[email-masked]]
> > > has been previous discussion on the use of UAC or UAS versus
simply
> > UA.
then
> > > > If you have questions, concerns, or feel like something
important

---

From: "James McEachern" <[email-masked]>
Date: Wed, 4 Feb 2009 19:48:34 -0500

Daryl,
Your comments generally look good to me. Now that I know someone is
listening, I will continue my review over the next few days.  Based on
your comments, I will assume the following for the remainder of my
review:

- I will use Originating SSP rather than Initiating SSP
- I will assume we are using SSP rather than peer
- I will try to use only Target SSP  
- I will only use UA

All your other specific suggestions are fine with me.

Jim McEachern
T:+1 613 763-3419
M:+1 613 853-0176
-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Tuesday, February 03, 2009 12:02 PM
To: [email-masked]
Cc: McEachern, James (CAR:AR00)
Subject: [Speermint] RE: Meeting minutes from IETF 73 Speermint session
(Arch Draft Review) 

Jim,

Thanks for the review.

Comments in-line...

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

I agree with using SSP.

---

From: "James McEachern" <[email-masked]>
Date: Wed, 4 Feb 2009 22:24:20 -0500

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. 

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.

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.

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

---

From: "Daryl Malas" <[email-masked]>
Date: Fri, 6 Feb 2009 17:15:08 -0700

Jim et. al.,

Comments in-line...

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

> Sent: Wednesday, February 04, 2009 8:24 PM
> Speermint session (Arch Draft Review) 
> 
> This email continues the detailed review of the Architecture 
> Draft Review from the point where I left off on my first email.
> 
> This section refers to the "peer" in several places.  This 
> should be changed to "SSP"
> 
> 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).
> 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. ..."
> 
> 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.
> 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."
> 
> This section also introduces a new term, the "receiving 
> peer".  This should be changed to "Target SSP".
> 

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?

> 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.

> 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.
> 
> Says that messages "would" be sent as clear text. I think it 
> would be better to say they "could" be sent as clear text.
>

---

From: "James McEachern" <[email-masked]>
Date: Mon, 23 Feb 2009 21:38:27 -0500

Daryl,
Comment inline...

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

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Friday, February 06, 2009 7:15 PM
To: McEachern, James (CAR:AR00); [email-masked]
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

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

[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.