[Speermint] Comments: srv-naptr-use draft

[Daryl Malas <d.malas at cablelabs.com>]

Jason,

Here are some comments regarding your draft:

2. Introduction
- You mention "service provider" throughout this section and the document,
and I think this should be "SIP service provider (SSP)".
- There is an incomplete sentence at the end of the section, "It should be
noted that..."

3.  Session Peering Setup
- Last time I will note the "service provider (SP1)" should be "SIP service
provider (SSP1) -- change throughout the draft.
- I think it should be noted in Figure 1 (and in the text) that the DNS
servers are part of the LUF.  This will align the draft better with other
Speermint terminology.  Also, would it be better to differentiate DNS from
ENUM for clarity purposes?  This may allow differentiation of LUF and LRF
(e.g. ENUM and SRV).
- I think this "SIP signaling path border element" can simply be "SBE".  You
expand it and use the acronym in various instances throughout.
- In the first paragraph under "Figure 1", I do not understand why the last
sentence "UDP, TCP and ..." is even in scope of this document.  Are you
intending context for the NAPTR regexp response?  Even in this case, I think
they are examples and should not be strictly defined.  Based on the rest of
the document, I would question whether this sentence is necessary.
- The paragraph "As a best current practice..." does not seem to provide
value to the document in my opinion.  It provides an architectural
recommendation rather than providing a recommendation of using NAPTR
order/pref and SRV priority/weight.  Perhaps a reference to RFC 5483 on
recommendations for load balancing would be appropriate.
- Regarding the call flows, I think expanding the different scenarios and
potential uses of the following portion is the most critical aspect:

                     |INVITE|      |      |      |      |
                     |----->|      |      |      |      |
                     |    NAPTR Query     |      |      |
                     |      |----->|      |      |      |
                     |    NAPTR Response  |      |      |
                     |      |<-----|      |      |      |
                     |     SRV Query      |      |      |
                     |      |----->|      |      |      |
                     |     SRV Response   |      |      |
                     |      |<-----|      |      |      |
                     |      A Query       |      |      |
                     |      |----->|      |      |      |
                     |      A Response    |      |      |
                     |      |<-----|      |      |      |
                     |      |       INVITE       |      |
                     |      |------------------->|      |

For example, expand the use of multiple NAPTRs and SRV records for
determining a single ingress point, multiple ingress points, and egress
points.  How many times must an ENUM query take place in an indirected
scenario with egress routes, etc.?

3.1 Target Determination
Is there a Speermint recommendation, taking into consideration RFC 5483, for
using SRV or ENUM NAPTRs for providing load balancing, based on ingress,
egress, and enumservice types?  I think this might be a good addition to
this section.

4.0 High Availability
I think if you apply my comments on 3.1 to that section, then you can tie
this section back to it (i.e. Continue the example).

Regards,

Daryl

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas at cablelabs.com