Subject: Re: [Speermint] **Last Call** on the Speermint Peering Architecturedraft

From: Daryl Malas <[email-masked]>
Date: Thu, 4 Mar 2010 12:07:21 -0700

Mike,

I have updated the diagram.  Thanks.

Regards,

Daryl 

-----Original Message-----
From: Mike Hammer (hmmr) [mailto:[email-masked]] 
Sent: Friday, January 22, 2010 1:48 PM
To: Daryl Malas; [email-masked]
Subject: RE: [Speermint] RE:**Last Call** on the Speermint Peering Architecturedraft

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Daryl Malas
> Sent: Friday, January 22, 2010 1:11 PM
> To: [email-masked]
> Subject: [Speermint] RE:**Last Call** on the Speermint Peering 
> Architecturedraft
> 
> 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,
> 
> 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.
> 
> 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
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint
> _______________________________________________
> 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: Daryl Malas <[email-masked]>
Date: Thu, 4 Mar 2010 12:11:12 -0700

The new diagram looks like this:

+=============++                          ++==============+
              ||                          ||
        +-----------+                +-----------+        
        |    SBE    |                |    SBE    |
        |  +-----+  | SIP   +-----+  |  +-----+  |
        |  | LUF |<-|------>|ENUM |  |  | LUF |  |
        |  +-----+  | ENUM  |TN DB|  |  +-----+  |
   SIP  |           |       +-----+  |           |
 ------>|  +-----+  | DNS   +-----+  |  +-----+  |
        |  | LRF |<-|------>|FQDN |  |  | LRF |  |
        |  +-----+  |       |IP   |  |  +-----+  |
        |  +-----+  | SIP   +-----+  |  +-----+  |
        |  | SF  |<-|----------------|->|  SF |  |
        |  +-----+  |                |  +-----+  |
        +-----------+                +-----------+
              ||                           ||
        +-----------+                +-----------+
   RTP  |    DBE    | RTP            |    DBE    |
 ------>|           |--------------->|           |  
        +-----------+                +-----------+
              ||                           ||
SSP1 Network  ||                           ||  SSP2 Network
+=============++                           ++=============+

Any concerns?

--Daryl 

-----Original Message-----
From: Mike Hammer (hmmr) [mailto:[email-masked]] 
Sent: Friday, January 22, 2010 1:52 PM
To: Mike Hammer (hmmr); Daryl Malas; [email-masked]
Subject: RE: [Speermint] **Last Call** on the Speermint PeeringArchitecturedraft

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

On
> Behalf Of Mike Hammer (hmmr)
> Sent: Friday, January 22, 2010 3:48 PM
> Subject: Re: [Speermint] **Last Call** on the Speermint 
> PeeringArchitecturedraft
> 
> Daryl,
> 
> Two problems:
> 
> 1)  The SBE to SF, LUF, and LRF relationship is convoluted and
circular
> (can iterate endlessly).
|
|
>            | |  |->|      | |  |                      |   | |
|<-|
>            |  \       |     /  |                      |    \    |
/

---

From: Daryl Malas <[email-masked]>
Date: Mon, 8 Mar 2010 17:50:15 -0700

John,

My apologies, but I have not been able to address your comments yet.

I took time to convert the draft into .xml format, which should resolve all of the formatting issues and nits.  Also, I addressed many comments.  Please review the new -10 revision and let me know if it addresses some of your comments.

Regards,

Daryl 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, January 20, 2010 2:15 AM
To: Daryl Malas; [email-masked]
Subject: RE: [Speermint] RE:**Last Call** on the Speermint Peering Architecturedraft

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

---

From: Adam Uzelac <[email-masked]>
Date: Tue, 9 Mar 2010 13:02:44 -0500

Daryl/John.

I believe that many of the concerns that John expressed here are indeed
addressed in the latest revision of the document.  I was reading over John's
comments, and comparing them to the latest draft - and it's looking like
most are addressed.  I didn't do a complete review, so please note the
caveat.

Adam Uzelac
Global Crossing

On Mon, Mar 8, 2010 at 7:50 PM, Daryl Malas <[email-masked]> wrote:

> I took time to convert the draft into .xml format, which should resolve all
> of the formatting issues and nits.  Also, I addressed many comments.  Please
> review the new -10 revision and let me know if it addresses some of your
> comments.
>
> Regards,
>
> Daryl
>
> 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)?
>
>
> 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:
>
> 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..."
>
> 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].
>
> Apart from the grammatical error, where does it get the call routing data
> from and what is the result of resolving that data?
>
> 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.
>
> 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
> 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:
> 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: "Elwell, John" <[email-masked]>
Date: Tue, 16 Mar 2010 11:48:03 +0100

Because the diff showed very extensive changes, I did not check the extent to which my earlier comments have been addressed, but instead I just reviewed the new version (10).

I have to say I am most disappointed that, considering its post-WGLC state, this still seems to be a self-inconsistent document and furthermore is inconsistent with RFC 5486. I would go as far as to say this document is so confusing that it should not be published. I just cannot believe it has undergone serious review. Please remove my name from the Acknowledgements, to avoid any implication that I condone the document in its present form.

This is not intended to be a criticism of the editors, but a criticism of the whole WG for not directing the editors towards a consistent and meaningful document.

I don't have time to spell out particular comments on the list, but I will send an annotated WORD copy to Daryl. Just a quick summary of some of the main points I found:

- Inconsistency with RFC 5486 in not allowing LUF and/or LRF to be external.
- Inconsistency with RFC 5486 concerning the output from the LUF
- Use of terms with definitions or references (e.g., carrier-of-record, session establishment data)
- Reference to figure 1 when talking about an indirect peer, even though figure 1 doesn't show such a case.
- Inconsistencies concerning the relationships between SBE, SF, LUF and LRF.
- Mix-up between "target address" and "target URI".
- Occasional RFC 2119 language ("MAY")
- Specifying inappropriate SIP procedures (overwriting Request URI rather than using Route header field).
- Talking about inter-LRF communication (section 5.1.2.3) without explaining what this is and how it fits into the architecture.

John

> From: Daryl Malas [mailto:[email-masked]] 
> Sent: 09 March 2010 00:50
> To: Elwell, John; [email-masked]
> I took time to convert the draft into .xml format, which 
> should resolve all of the formatting issues and nits.  Also, 
> I addressed many comments.  Please review the new -10 
> revision and let me know if it addresses some of your comments.
> 
> Regards,
> 
> Daryl 
> 
> 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 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)?
> 
> 
> 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:
> Step 5 (ending the session) could equally be performed by 
> either the originating SSP or the target SSP.
> 
> What is meant by "target SSP changes" - is this something 
> like a mid-call transfer, redirection, or what?
> 
> 6. "This is
> 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..."
> 
> So it uses the target address to obtain the target address? 
> Seems circular, or am I missing something.
> 
> 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].
> 
> Apart from the grammatical error, where does it get the call 
> routing data from and what is the result of resolving that data?
> 
> 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.
> 
> 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
> 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:
> 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
>