Subject: [Speermint] I-D Action:draft-ietf-speermint-architecture-10.txt

From: [email-masked]
Date: Mon, 8 Mar 2010 17:00:01 -0800 (PST)

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 Peering Architecture
	Author(s)       : A. Uzelac, et al.
	Filename        : draft-ietf-speermint-architecture-10.txt
	Pages           : 13
	Date            : 2010-03-08

This document defines a peering architecture for the Session
Initation Protocol (SIP) [RFC3261], it's functional components and
interfaces.  It also describes the steps necessary to establish a
session between two peering domains in the context of the functions
defined.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Daryl Malas <[email-masked]>
Date: Tue, 9 Mar 2010 16:35:18 -0700

All,

I was surprised by how many authors are attributed to this draft, while I was editing it.  While there are many authors, there have only been 1 or 2 of them commenting on it in the past year or so.  We realize this draft is victim to the "worked on so long people have forgotten or do not care anymore" circumstance, but we really need to wrap this up.  Can everyone, including the authors, read through this revision and provide final feedback for discussion at the upcoming IETF meeting?

Best Regards,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 08, 2010 6:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Speermint] I-D Action:draft-ietf-speermint-architecture-10.txt

This document defines a peering architecture for the Session Initation Protocol (SIP) [RFC3261], it's functional components and interfaces.  It also describes the steps necessary to establish a session between two peering domains in the context of the functions defined.

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

---

From: Daryl Malas <[email-masked]>
Date: Tue, 9 Mar 2010 16:40:06 -0700

...many thanks to those who provided feedback during the recent WGLC. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Tuesday, March 09, 2010 4:35 PM
To: [email-masked]
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-architecture-10.txt

All,

Best Regards,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 08, 2010 6:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Speermint] I-D Action:draft-ietf-speermint-architecture-10.txt

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
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Thu, 11 Mar 2010 09:24:29 -0500

Two points:

1. In Section 5.1.2.2 the first paragraph suggests that a Routing Table
would be used only if there were no end user ENUM records and the
Carrier of Record was undeterminable or unreachable. It also indicates
that in these cases the call could be rejected, sent to the PSTN, or
sent to another SSP for PSTN termination.
I think in the spirit of the last sentence of 5.1.2 ("These [LRF
mechanisms]are not in any particular order, and importantly, not all of
them may be used", that the section might be better rewritten as
follows:

Next hop selection may also be accomplished by a routing table internal
to the Originating SSP, either as a first choice or if other
alternatives are unsuccessful. The routing table might direct the call
to its ultimate destination, to an SSP acting as a transit provider, or
to an SSP providing a gateway resource. Alternatively the routing table
might send the call to the PSTN or cause it to be rejected. 
   
In the case of direction to a gateway in another SSP, the originating
SSP rewrites the Request-URI to address the
gateway resource in the target SSP's domain and MAY forward the request
on to that SSP using the procedures described in the
remainder of these steps.

Implementation details of the routing table are out of scope for this
document.

2. I'm not sure I understand what Section 5.1.2.3 means. Can someone
elaborate on "LRF to LRF routing?" Some of the elements here sound more
like routing table based.

Thanks,

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, March 08, 2010 8:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Speermint] I-D Action:draft-ietf-speermint-architecture-10.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.

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

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 11 Mar 2010 09:42:11 -0600

Daryl,

No further comments.

One small edit:  My email was changed to [email-masked]

Thanks,
Mike Hammer

> Behalf Of Daryl Malas
> Sent: Tuesday, March 09, 2010 6:35 PM
> To: [email-masked]
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> I was surprised by how many authors are attributed to this draft,
while I
> was editing it.  While there are many authors, there have only been 1
or 2
> of them commenting on it in the past year or so.  We realize this
draft is
> victim to the "worked on so long people have forgotten or do not care
> anymore" circumstance, but we really need to wrap this up.  Can
everyone,
> including the authors, read through this revision and provide final
> feedback for discussion at the upcoming IETF meeting?
> 
> Best Regards,
> 
> Daryl
> 
> Subject: [Speermint] I-D
Action:draft-ietf-speermint-architecture-10.txt
> This document defines a peering architecture for the Session Initation
> Protocol (SIP) [RFC3261], it's functional components and interfaces.
It
> also describes the steps necessary to establish a session between two
> peering domains in the context of the functions defined.
>

---

From: Daryl Malas <[email-masked]>
Date: Fri, 12 Mar 2010 08:59:13 -0700

Penn,

Regarding your second point, I was confused by the LRF-to-LRF section myself when I was editing the draft.  I almost deleted the section.  Can anyone remind us of what this is for?

Thanks,

Daryl 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L (ATTCORP)
Sent: Thursday, March 11, 2010 7:24 AM
To: [email-masked]
Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-architecture-10.txt

Two points:

1. In Section 5.1.2.2 the first paragraph suggests that a Routing Table would be used only if there were no end user ENUM records and the Carrier of Record was undeterminable or unreachable. It also indicates that in these cases the call could be rejected, sent to the PSTN, or sent to another SSP for PSTN termination.
I think in the spirit of the last sentence of 5.1.2 ("These [LRF mechanisms]are not in any particular order, and importantly, not all of them may be used", that the section might be better rewritten as
follows:

Next hop selection may also be accomplished by a routing table internal to the Originating SSP, either as a first choice or if other alternatives are unsuccessful. The routing table might direct the call to its ultimate destination, to an SSP acting as a transit provider, or to an SSP providing a gateway resource. Alternatively the routing table might send the call to the PSTN or cause it to be rejected. 
   
In the case of direction to a gateway in another SSP, the originating SSP rewrites the Request-URI to address the gateway resource in the target SSP's domain and MAY forward the request on to that SSP using the procedures described in the remainder of these steps.

Implementation details of the routing table are out of scope for this document.

2. I'm not sure I understand what Section 5.1.2.3 means. Can someone elaborate on "LRF to LRF routing?" Some of the elements here sound more like routing table based.

Thanks,

Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 12 Mar 2010 10:31:08 -0600

Daryl,

I thought that was originally a communication path for exchanging
information which may be policy controlled depending on who was making
the requests to the target domain.  Thus, while the earlier stages were
likely more static, centralized, and designed to be lean and fast; those
more dynamic aspects would be handled by databases internal to the
target domain.

Thanks,
Mike Hammer

> Sent: Friday, March 12, 2010 10:59 AM
> To: 'PFAUTZ, PENN L (ATTCORP)'; [email-masked]
> Regarding your second point, I was confused by the LRF-to-LRF section
> myself when I was editing the draft.  I almost deleted the section.
Can
> anyone remind us of what this is for?
> 
> Thanks,
> 
> Daryl
> 
> Behalf Of PFAUTZ, PENN L (ATTCORP)
Carrier
> of Record was undeterminable or unreachable. It also indicates that in
> these cases the call could be rejected, sent to the PSTN, or sent to
> another SSP for PSTN termination.
> Next hop selection may also be accomplished by a routing table
internal to
> the Originating SSP, either as a first choice or if other alternatives
are
> unsuccessful. The routing table might direct the call to its ultimate
> destination, to an SSP acting as a transit provider, or to an SSP
> providing a gateway resource. Alternatively the routing table might
send
> the call to the PSTN or cause it to be rejected.
> 
SSP
> rewrites the Request-URI to address the gateway resource in the target
> SSP's domain and MAY forward the request on to that SSP using the
> procedures described in the remainder of these steps.
> 
It

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Fri, 12 Mar 2010 14:21:21 -0500

Mike:
Thanks. Now I think I have a better idea of what the intent was. I do
think the language needs revision. How about:

The LRF of the originating SSP may also communicate with the LRF of the
target SSP to identify the next hop signaling function.
The details of this communication are out of scope for this document.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: Mike Hammer (hmmr) [mailto:[email-masked]] 
Sent: Friday, March 12, 2010 11:31 AM
To: Daryl Malas; PFAUTZ, PENN L (ATTCORP); [email-masked]
Subject: RE: [Speermint] I-D

Daryl,

Thanks,
Mike Hammer

Can
Carrier
internal to
are
send
SSP
It

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 12 Mar 2010 13:23:00 -0600

That works for me.

Thanks,
Mike Hammer

> From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]]
> Sent: Friday, March 12, 2010 2:21 PM
> To: Mike Hammer (hmmr); Daryl Malas; [email-masked]
> Subject: RE: [Speermint] I-D Action:draft-ietf-speermint-architecture-
> 10.txt
> 
> Mike:
> > Subject: Re: [Speermint] I-D
Action:draft-ietf-speermint-architecture-
> > 10.txt
> > Subject: Re: [Speermint] I-D
Action:draft-ietf-speermint-architecture-
> > 10.txt
Initation

---

From: Daryl Malas <[email-masked]>
Date: Fri, 12 Mar 2010 14:30:08 -0700

Penn,

That wording works for me.

All,

Anyone else have a problem with this?

Thanks,

Daryl 

-----Original Message-----
From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]] 
Sent: Friday, March 12, 2010 12:21 PM
To: Mike Hammer (hmmr); Daryl Malas; [email-masked]
Subject: RE: [Speermint] I-D Action:draft-ietf-speermint-architecture-10.txt

Mike:
Thanks. Now I think I have a better idea of what the intent was. I do think the language needs revision. How about:

The LRF of the originating SSP may also communicate with the LRF of the target SSP to identify the next hop signaling function.
The details of this communication are out of scope for this document.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: Mike Hammer (hmmr) [mailto:[email-masked]]
Sent: Friday, March 12, 2010 11:31 AM
To: Daryl Malas; PFAUTZ, PENN L (ATTCORP); [email-masked]
Subject: RE: [Speermint] I-D

Daryl,

I thought that was originally a communication path for exchanging information which may be policy controlled depending on who was making the requests to the target domain.  Thus, while the earlier stages were likely more static, centralized, and designed to be lean and fast; those more dynamic aspects would be handled by databases internal to the target domain.

Thanks,
Mike Hammer

Can
Carrier
internal to
are
send
SSP
It

---

From: Daryl Malas <[email-masked]>
Date: Fri, 12 Mar 2010 14:36:57 -0700

Penn,

I am generally okay with your suggested changes.  I changed a couple of the words, now in [].  Please review and let me know if you have any concerns:

"Next hop selection may also be accomplished by a routing table internal to the Originating SSP, either as a first choice or if other alternatives are unsuccessful. The routing table might direct the call to its [target] destination [or] to an SSP acting as [an indirect SSP]. Alternatively, the routing table might send the call to the PSTN or cause it to be rejected. 

Implementation details of the routing table are out of scope for this document." 

Any concerns?

Thanks,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L (ATTCORP)
Sent: Thursday, March 11, 2010 7:24 AM
To: [email-masked]
Subject: Re: [Speermint] I-D Action:draft-ietf-speermint-architecture-10.txt

Two points:

   

Thanks,

Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Fri, 12 Mar 2010 16:40:30 -0500

Thanks Daryl. Works for me

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Friday, March 12, 2010 4:37 PM
To: PFAUTZ, PENN L (ATTCORP); [email-masked]
Subject: RE: [Speermint] I-D

Penn,

I am generally okay with your suggested changes.  I changed a couple of
the words, now in [].  Please review and let me know if you have any
concerns:

"Next hop selection may also be accomplished by a routing table internal
to the Originating SSP, either as a first choice or if other
alternatives are unsuccessful. The routing table might direct the call
to its [target] destination [or] to an SSP acting as [an indirect SSP].
Alternatively, the routing table might send the call to the PSTN or
cause it to be rejected. 
   
In the case of direction to a gateway in another SSP, the originating
SSP rewrites the Request-URI to address the gateway resource in the
target SSP's domain and MAY forward the request on to that SSP using the
procedures described in the remainder of these steps.

document." 

Any concerns?

Thanks,

Daryl

-----Original Message-----

Two points:

   
In the case of direction to a gateway in another SSP, the originating
SSP rewrites the Request-URI to address the gateway resource in the
target SSP's domain and MAY forward the request on to that SSP using the
procedures described in the remainder of these steps.

Thanks,

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----

This document defines a peering architecture for the Session Initation
Protocol (SIP) [RFC3261], it's functional components and interfaces.  It
also describes the steps necessary to establish a session between two
peering domains in the context of the functions defined.