Subject: [Speermint] Comments on draft-ietf-speermint-architecture-05

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 Mar 2008 15:07:44 -0500

Howdy,
here are my comments on sections 1-3, fwiw:

--------------------------
Section 3:
I like the idea of having an overview of the steps required, but this section is confusing.  The first paragraph says:
   This document assumes that a call from a UAC end user in the
   initiating peer's network goes through the following steps to
   establish a call to a UAS in the receiving peer's network...
that implies the steps are for the UAC to perform? (presumably not)  Or does it mean for the "call" to perform?  (which is weird in concept and wording here)

Step 2 says "the discovery of the receiving peering point address" - it should mean the destination peering point address, right?  In Figure 2 the words "Target SSP" are used, which is probably what should be used here.

Step 3 could happen even if the target represents an intra-SPP resource.

Step 4 "the discovery of the UAS" is a bit odd, because for intra-SSP requests it may or may not require additional steps (e.g., finding the right Registrar and sending it to that), and for inter-SSP requests only the target SSP does this, not the originating SSP.  It's also odd because step-5 happens before step-4 in many cases.

Step-5 "the routing of SIP messages" is not a single step that can be enumerated in this one step - it is incorporated in or among several of the steps.

Therefore, I propose the following replacement to section 3:

"This document assumes that a call from a UAC in the originating peer's network to a UAS in the target peer's network requires the following steps to be taken, as requests get routed from one SSP to another:
        1. Analyzing the target address.  If the target is determined to represent an intra-SSP resource, the behavior is out-of-scope with respect to this draft.
        2. Determination of the Target SSP, for example by the LUF.
        3. Determination of the SBE next-hops for egressing the originating SSP and ingressing the terminating SSP, for example by the LRF.
        4. The enforcement of authentication, authorization, and potentially other policies.
        5. Determination of the path to the final UAS.
        6. Session establishment.
        7. Potentially transfer of media, such as audio, video, text, and so on.
        8. Session termination.
The originating SSP would likely perform steps 1-4, and the terminating SSP would likely perform steps 4-5."

--------------------------

Editorial nits:
Figure 1 in section 2 should be drawn on one page, so insert a page break right before it. (it should fit on one page)

Figure 1 uses "Service Provider" for the public internet cloud connected blocks, but "SSP" for the private ones.  Why?  They should be the same.

Figure 1 has a "Private SIP Peering" block at the bottom - what is this for?

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 Mar 2008 21:50:44 -0500

Following are comments for section 4:

Figure 2: what do the arrows represent?  That data is installed/provisioned from the LUF to the LRF?
And what does the line from the LRF to the SBE represent?

I think internally, inside an SSP, it doesn't matter how the SSP goes about performing the LRF/LUF lookup - it may well matter to Peppermint, but not Speermint.  By that I mean the LRF and LUF "lookup" may be done by the UAC, a proxy in the middle, or an SBE.  And the "lookup" could be a query or provisioned data.  And how the LRF/LUF are populated, instantiated, and queried are up to Peppermint, presumably.

All that matters to Speermint is that for a given target URI, the originating SSP determines (a) the terminating SSP via LUF, (b) how to get to the terminating SSP through proxies/SBE's/whatever via LRF, and (c) how the SSP modifies the request-URI or inserts Route headers to get it there.

For the terminating SSP, all that matters is how it should expect to receive a target URI (i.e., in req-uri or Route headers), and how it gets it to the UAS is basically it's own business.  In that sense, showing a LUF/LRF in the terminating SSP is not relevant.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 4 Mar 2008 22:59:27 -0500

Comments on sections 5.1 and 5.2...

The title of section 5 "Peer Function Examples" is a misnomer, I think.  It is neither about the "Peer" nor really examples.  It is really "Recommended SSP Procedures" or some such.
Likewise, section 5.1's title should be "Originating SSP Procedures", and section 5.2's should be "Terminating SSP Procedures".

Section 5.1 LF function: This section seems to collapse the LUF and LRF functions into one, which is a shame because I really liked that distinction/separation.  If you want text for this to reflect the Figure 2 separation, where the two are separate functions, I can provide it.

Section 5.1.1 target URI: paragraph 3 says:
   ...If the highest
   priority supported URI scheme is sip: or sips:, the initiating peer
   skips to SIP DNS resolution in Section 5.1.5. Likewise, if the
   target address is already a sip: or sips: URI in an external domain,
   the initiating peer skips to SIP DNS resolution in Section 5.1.5.
I'm not quite sure why it says this.  It is basically a matter of local policy to the originating SSP, whether it wants to use DNS at all to direct-route such requests, or whether it wants to perform a LUF/LRF lookup, Infrastructure ENUM lookup, etc.

Section 5.1.2 User ENUM: Is this section in here to be politically correct?  'cause this is super-rare today, obviously.

Section 5.1.3 DNS resolution:
It says in paragraph 2:
   When communicating with a public external peer, entities compliant
   to this document MUST only select a TLS-protected transport for
   communication from the initiating peer to the receiving peer.
I believe this document is Informational, so having a MUST statement is not allowed.  Furthermore, it would depend on the SRV resolution process and what the next-hop can support.

Section 5.1.6 Redirect server is basically a no-op statement. :)

Section 5.2.2 says:
   To receive peer requests, the receiving peer MUST insure that it
   publishes appropriate NAPTR, SRV, and address (A and/or AAAA)
   records in the LF relevant to the peer's SF.
Again, this is an informational RFC so can't use MUST.  Also, it doesn't even make sense, since using DNS is not necessary.

Section 5.2.3 references "[22]". But should be "[21]".

-hadriel

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 10 Mar 2008 21:20:58 -0700

Hello Hadriel,

I agree with your evaluation and incorporated the suggested text.

Thanks,

Reinaldo

On 3/4/08 12:07 PM, "Hadriel Kaplan" <[email-masked]> wrote:

> that implies the steps are for the UAC to perform? (presumably not)  Or does
> it mean for the "call" to perform?  (which is weird in concept and wording
> here)
> 
> Step 2 says "the discovery of the receiving peering point address" - it should
> mean the destination peering point address, right?  In Figure 2 the words
> "Target SSP" are used, which is probably what should be used here.
> 
> Step 4 "the discovery of the UAS" is a bit odd, because for intra-SSP requests
> it may or may not require additional steps (e.g., finding the right Registrar
> and sending it to that), and for inter-SSP requests only the target SSP does
> this, not the originating SSP.  It's also odd because step-5 happens before
> step-4 in many cases.
> 
> Step-5 "the routing of SIP messages" is not a single step that can be
> enumerated in this one step - it is incorporated in or among several of the
> steps.
> 
> "This document assumes that a call from a UAC in the originating peer's
> network to a UAS in the target peer's network requires the following steps to
> be taken, as requests get routed from one SSP to another:
>         1. Analyzing the target address.  If the target is determined to
> represent an intra-SSP resource, the behavior is out-of-scope with respect to
> this draft.
>         3. Determination of the SBE next-hops for egressing the originating
> SSP and ingressing the terminating SSP, for example by the LRF.
> Figure 1 in section 2 should be drawn on one page, so insert a page break
> right before it. (it should fit on one page)
> 
> Figure 1 uses "Service Provider" for the public internet cloud connected
> blocks, but "SSP" for the private ones.  Why?  They should be the same.
>

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Tue, 11 Mar 2008 09:38:07 -0400

I'd like to second Hadriel's comment re 5.1.2. A User ENUM query should
be at the originating SSP's option, not a do-first requirement.

Also, there are a couple of nits in the References: I don't think [12]
and [21] refer to the correct documents as cited in the text ([21] is
expired)

Penn Pfautz
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Tuesday, March 04, 2008 10:59 PM
To: [email-masked]
Subject: Re: [Speermint] Comments on section-5.1 and 5.2 of
draft-ietf-speermint-architecture-05

Section 5.1.2 User ENUM: Is this section in here to be politically
correct?  'cause this is super-rare today, obviously.