[Speermint] Comments: message-flows draft

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

Hadriel,

Here are some comments regarding the draft  (I know I am an author on this
draft, but my comments to the list are to solicit feedback from the mailing
list.):

3. Peering Scenarios
- Based on what is commonly in use *today*, I think the various methods of
"static" peering should be focused on first.  On-demand is something that
should be included as a potential future method.

- The sentence "Media-direct: In this model SIP proxies perform Layer 5
peering Signaling Function (SF)..." does not make sense to me.  Suggest:
"Media-direct: In this model Signaling Functions (SFs) perform Layer 5
peering, while media is sent directly between..."

- I noticed throughout the draft a lot of "SF/SBE" and "MF/DBE" uses.  Is it
necessary to do this?  Can we simply say SF and MF?  Based on RFC 5486, the
definitions for SF and MF say they are capabilities of a SBE and DBE.

- In "Decomposed:..." you say the model "is not discussed separately", but
then under Figure 2 it is discussed further.  Is this necessary or should it
be included in the "Decomposed" description?

4. Legend of Message Flows
- Just a nit, but this and the srv-naptr draft use "example.com" for the
example FQDNs.  Should this be "examplessp.com"?  Also, in the SBE URIs, it
should be "sbe1.ssp1.examplessp.com" -- potentially based on the outcome of
my first question.  I personally think it better aligns with the terminology
and what we are describing.

5. Basic Peering Message Flow
- I do not think a "basic" message flow should describe an "On-Demand"
peering phase.  In my opinion, a basic peering message flow is static and
direct between two SSPs.

7. Static Peering
- Just a comment, TLS is not commonly used in my experience of SSPs peering.
I think this should be described as "optional".  For that matter, IPSec is
not used that commonly.  While TLS is something to be considered in the
message flows, I think IPSec is out of scope of the draft.

- Co-Location, while I am not a fan of this term, is a more common method
for peering today, in my experience.  If others agree, then I think this
should be discussed first.

8. Federation-based Peering
- I think describing "Federation" is only contextual and is minor to the two
message flows: redirect server and ENUM server (LUF).  I think these should
be in a different section with a small description about their potential use
in a Federation.  This can both be used outside of a Federation.

Regards,

Daryl