Subject: [Speermint] **Last Call** on the Speermint Peering Architecture draft

From: "Daryl Malas" <[email-masked]>
Date: Thu, 7 Jan 2010 09:55:26 -0700

All,
 
We discussed this during our last meeting, but I wanted to officially
note it on the mailing list.  Please provide any final comments on the
Speermint Peering Architecture draft.  This last call will last
approximately 1 week and end on January 15th.

Here is a link to the draft:
http://tools.ietf.org/html/draft-ietf-speermint-architecture-09

Adam,

Please review and begin correction of the nits here:
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-spe
ermint-architecture-09.txt.

We would like to wrap up this draft quickly, so everyone's effort to
review and provide and final feedback is greatly appreciated.

Regards,

Daryl

---

From: "Daryl Malas" <[email-masked]>
Date: Fri, 8 Jan 2010 09:47:22 -0700

All,

With the understanding it may be challenging for some to schedule the
time to review and provide comments in 1 week, the "Last Call" is
extended to January 22nd.

Regards,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daryl Malas
Sent: Thursday, January 07, 2010 9:55 AM
To: [email-masked]
Subject: [Speermint] **Last Call** on the Speermint Peering
Architecturedraft

All,

Adam,

Regards,

Daryl
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: Daryl Malas <[email-masked]>
Date: Tue, 19 Jan 2010 08:54:15 -0700

All,

This is just a reminder the "Last Call" on the Speermint Peering Architecture draft ends this Friday, January 22nd.  Please review and post comments to the mailing list soon.

Regards,

Daryl
Speermint Chairs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Friday, January 08, 2010 9:47 AM
To: [email-masked]
Subject: [Speermint] RE:**Last Call** on the Speermint Peering Architecturedraft

All,

With the understanding it may be challenging for some to schedule the time to review and provide comments in 1 week, the "Last Call" is extended to January 22nd.

Regards,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Thursday, January 07, 2010 9:55 AM
To: [email-masked]
Subject: [Speermint] **Last Call** on the Speermint Peering Architecturedraft

All,
 
We discussed this during our last meeting, but I wanted to officially note it on the mailing list.  Please provide any final comments on the Speermint Peering Architecture draft.  This last call will last approximately 1 week and end on January 15th.

Adam,

We would like to wrap up this draft quickly, so everyone's effort to review and provide and final feedback is greatly appreciated.

Regards,

Daryl

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Jan 2010 10:15:24 +0100

I have reviewed the draft, and I have a number of concerns that collectively mean the document is not yet ready. In my opinion, as it stands, it does more to generate confusion than it does to shed light on the subject.

General concerns:

1. Figure 1 is reasonably clear. Yet later there is frequent mentioning of "SF", which is not shown in Figure 1. Also there is occasional mention of "MF", which is also not shown in figure 1. Although all these terms are defined in RFC 5486, I find unhelpful to use the terms without showing them in the architecture diagram.

In fact the figure shows SBE and DBE. My understanding is that SBE and DBE are considered physical entities, whereas SF and MF are functional entities. This would account for the idea that an SBE can contain an SF, for example. In that case, figure 1 would appear to contain a mixture of functional entities (LUF and LRF) and physical entities (SBE and DBE). Would it not be better to show in the main architectural diagram only functional entities (with perhaps a second diagram showing an example of how these might map to physical entities)?

Related to this, I find section 3.1 very confusing.

Where it talks about obtaining the address of the SF of the target SSP, should this be the address of the SBE of the target SSP?

2. The structure of the document is hard to figure out. Section 2 is clear, but then we have section 3 on procedures and section 4 on recommended procedures - how are these supposed to relate to one another.

Then section 4.1.1 is supposed to be procedures for the LUF - are these supposed to be procedures for the LUF itself or for using the LUF? Probably the latter, since section 4.1.1.1 talks about performing a LUF. Moreover, section 4.1.1.1 goes beyond using the LUF but also mentions use of the LRF. Also 4.1.1.1 fails to even mention discovery of the target domain, which is meant to be the purpose of the LUF.

Then section 4.1.2.2 is supposed to be procedures for the LRF, but it seems to be concerned with the case where you do not have a target domain. In other words, it uses an alternative target domain (one with a PSTN gateway). So isn't this more to do with LUF functionality (section 4.1.1) than LRF functionality (4.1.2)?

Specific concerns:

3. RFC 2119 language. This Informational document refers to RFC 2119, yet the only instances of RFC 2119 language I found were about 3 instances of "MAY". I don't think RFC 2119 language is appropriate.
Major concerns:

4. Figure 1 shows the target SSP having an LUF and LRF, yet I cannot find any procedures for these in section 4.2.

4. In section 3:
" The originating SSP would likely perform steps 1-4, and the target SSP would
   likely perform steps 4-5."
Step 5 (ending the session) could equally be performed by either the originating SSP or the target SSP.

5. "In the case the target SSP changes, then steps 1-4 would be repeated."
What is meant by "target SSP changes" - is this something like a mid-call transfer, redirection, or what?

6. "This is
   reflected in Figure 2 that shows the target SSP with its own peering functions."
I cannot find a Figure 2.

7. Section 4.1.1:
"Purpose is to determine the SF of the target domain of a given request and
   optionally develop Session Establishment Data."
This is not in line with the RFC 5486 definition of LUF (purpose is to determine target domain).

8. The term "session establishment data", although defined in RFC 5486, is not used elsewhere in the architecture document so should not be introduced here.

9. This section seems to mix up the terms "URI" and "address" - I think a lot of the time when it is talking about "address" it really means "URI". For example "If the target address does not represent..."

10. "If the target address does not represent a resource inside the originating
   SSP's administrative domain or federation of domains, then the originating SSP
   performs a Lookup Function (LUF) to determine a target address"
So it uses the target address to obtain the target address? Seems circular, or am I missing something.

11. "If the highest priority
   supported URI scheme is sip: or sips: the originating SSP skips to SIP DNS
   resolution in Section 5.1.3. "
There is no 5.1.3. Also, we should make it clear that the highest priority URI scheme is a result the result of the procedures of [8].

12. "performs a Lookup Function (LUF) to determine a target address"
Again, this is not what a LUF does, according to RFC 5486.

13. "and then is
   resolves the call routing data by using the Location routing Function (LRF)"
Apart from the grammatical error, where does it get the call routing data from and what is the result of resolving that data?

14. In 4.1.2.2, what is "the routing table"? This term has not been previously introduced.

15. "If so, the originating SSP rewrites"
It is not clear what "If so" refers to.

16. "the originating SSP rewrites the Request-URI to address the gateway
   resource in the target SSP's domain"
Why are we advocating rewrite of the Request-URI, rather than use of the Route header field?

17. In 4.1.2.3:
"LRF to LRF Routing"
and
"Communications between the LRF of two interconnecting SSPs may use DNS or
   statically provisioned IP Addresses for reachability."
This is the first hint of communications between the LRFs of two SSPs. It is not apparent from figure 1, which seems to show the two LRFs each accessing the same ENUM database, but with no hint of communication between the two. Before talking about how we achieve communication between LRFs, we should first explain why they need to communicate with each other. And if there is indeed communication between the two, something should be said in section 4.2 too.

18. Section 4.1.3 has SBE in the title but immediately starts talking about SF.

19. Section 4.1.3.1, on the originating SSP establishing a trust relationship, mentions IPsec and collocation, but fails to mention TLS (yet in 4.2, for the target SSP, TLS is mentioned, but not the other two).

20. Section 4.2.1.1
"The SF of the Target SSP verifies that the Identity header is valid,
   corresponds to the message, corresponds to the Identity-Info header, and that
   the domain in the From header corresponds to one of the domains in the TLS
   client certificate."
First, it does not allow the possibility of the Identity header field being absent. Second, if the Identity header field was inserted by a domain upstream of the Originating SSP, the domain in the From header will be different from the domain in the TLS client certificate.

21. Concerning that same text, it is unclear whether the requirement to check the domain of the From header applies only if the SIP Identity header is present or applies regardless. But as pointed out in the previous comment, the requirement is wrong anyway.

22. As a further comment on that text, anything to do with contents of the SIP message should not be discussed in the section dealing with TLS establishment, but would be more appropriate in 4.2.1.2.

23. In section 6:
"In order to maintain a consistent approach, unique and specialized security
   requirements common for the majority of peering relationships, should be
   standardized within the IETF."
Is this saying that the IETF should do some standardization work? If so, I don't think this is an appropriate statement for an RFC.
Or is it saying that SSPs should deploy security solutions that have been standardized by the IETF? If so, we could surely find better wording, or better still, identify those solutions that should be used.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daryl Malas
> Sent: 19 January 2010 15:54
> To: [email-masked]
> This is just a reminder the "Last Call" on the Speermint 
> Peering Architecture draft ends this Friday, January 22nd.  
> Please review and post comments to the mailing list soon.
> 
> Regards,
> 
> Daryl
> Speermint Chairs
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daryl Malas
> With the understanding it may be challenging for some to 
> schedule the time to review and provide comments in 1 week, 
> the "Last Call" is extended to January 22nd.
> 
> Regards,
> 
> Daryl
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Daryl Malas
> We discussed this during our last meeting, but I wanted to 
> officially note it on the mailing list.  Please provide any 
> final comments on the Speermint Peering Architecture draft.  
> This last call will last approximately 1 week and end on January 15th.
> 
> We would like to wrap up this draft quickly, so everyone's 
> effort to review and provide and final feedback is greatly 
> appreciated.
> 
> Regards,
> 
> Daryl

---

From: Daryl Malas <[email-masked]>
Date: Fri, 22 Jan 2010 11:10:47 -0700

All,

As a final reminder, the "Last Call" on the Speermint Peering Architecture draft ends today.  Thank you to those who have already submitted feedback on the draft, as this greatly helps the authors in improving it.  Once we receive any additional comments today, we will begin working to update the draft.

Best Regards,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Tuesday, January 19, 2010 8:54 AM
To: [email-masked]
Subject: [Speermint] RE:**Last Call** on the Speermint Peering Architecturedraft

All,

Regards,

Daryl
Speermint Chairs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Friday, January 08, 2010 9:47 AM
To: [email-masked]
Subject: [Speermint] RE:**Last Call** on the Speermint Peering Architecturedraft

All,

Regards,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Thursday, January 07, 2010 9:55 AM
To: [email-masked]
Subject: [Speermint] **Last Call** on the Speermint Peering Architecturedraft

All,

Adam,

Regards,

Daryl

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 22 Jan 2010 14:47:34 -0600

Daryl,

Two problems:

1)  The SBE to SF, LUF, and LRF relationship is convoluted and circular
(can iterate endlessly).
2)  You reference the SF throughout, but do not show it in the diagram.

My proposal is to change the figure 1 as follows.
Note, you can collapse the inner boundary of SBE, DBE, and SSP to be a
single edge if you want.

             +----------------+
+---------------+
            /                  \                       /
\
           |   +-----SBE---+   |                      |    +---SBE-----+
|
           |  /             \  |                      |   /
\ |
           | |     +--LUF-+ |  |       +------+       |   | +--LUF-+
| |
           | |  |->|      | |  |       | ENUM |       |   | |      |<-|
| |
           | |  |  |      +----------->| TN DB|<------------+      |  |
| |
           | |  |  |      | |  |       +------+       |   | |      |  |
| |
           | |  |  +------+ |  |                      |   | +------+  |
| |
           | |  |           |  |                      |   |           |
| |
           | |  |  +--LRF-+ |  |      +--------+      |   | +--LRF-+  |
| |
           | |  |->|      | |  |      | DNS    |      |   | |      |<-|
| |
           | |  |  |      +---------->|IP Addrs|<-----------+      |  |
| |
           | |  |  |      | |  |      +--------+      |   | |      |  |
| |
           | |  |  +------+ |  |                      |   | +------+  |
| |
           | |  |           |  |                      |   |           |
| |
           | |  |  +------+ |  |                      |   | +------+  |
| |
           | |  |->|      | |  |                      |   | |      |<-|
| |
           | |     |  SF  |<------------------------------->|  SF  |
| |
           | |     |      | |  |                      |   | |      |
| |
           | |     +------+ |  |                      |   | +------+
| |
           |  \       |     /  |                      |    \    |      /
|
           |   +------|----+   |                      |     +---|-----+
|
           |      +-------+    |                      |     +-------+
|
           |      |       |    |                      |     |       |
|
           | SSP1 |  DBE  |<------------------------------->|  DBE  |
SSP2|
           |      |       |    |                      |     |       |
|
           |      +-------+    |                      |     +-------+
|
            \                 /                        \
/
             +---------------+
+---------------+
                  Figure 1: Reference SPEERMINT Architecture

Thanks,
Mike

> Sent: Friday, January 22, 2010 1:11 PM
> To: [email-masked]
> As a final reminder, the "Last Call" on the Speermint Peering
Architecture
> draft ends today.  Thank you to those who have already submitted
feedback
> on the draft, as this greatly helps the authors in improving it.  Once
we
> receive any additional comments today, we will begin working to update
the
> draft.
> This is just a reminder the "Last Call" on the Speermint Peering
> Architecture draft ends this Friday, January 22nd.  Please review and
post
> comments to the mailing list soon.
> 
> Regards,
> 
> Daryl
> Speermint Chairs
> 
time
> to review and provide comments in 1 week, the "Last Call" is extended
to
> January 22nd.
note
> it on the mailing list.  Please provide any final comments on the

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 22 Jan 2010 14:52:10 -0600

All,

This txt art is messed up.  Seems like a lot of extra CR were injected.
But, hopefully you can see that the essence is:

SSP is composed of SBE and DBE.

SBE is composed of LUF, LRF, and SF.

Mike

> Behalf Of Mike Hammer (hmmr)
> Sent: Friday, January 22, 2010 3:48 PM
> To: Daryl Malas; [email-masked]
> Subject: Re: [Speermint] **Last Call** on the Speermint
> PeeringArchitecturedraft
> 
> Daryl,
> 
> Two problems:
> 
|
|
>            | |  |->|      | |  |                      |   | |
|<-|
>            |  \       |     /  |                      |    \    |
/
officially