Subject: [Speermint] Review of draft-ietf-speermint-flows-00.txt

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 09 Sep 2006 11:18:58 +0200

Hi all,

I reviewed draft-ietf-speermint-flows-00.txt

This document has severe problems. The document shows a number of SIP 
message flows whereby the relevant content for the working group is not 
yet available. I don't know why this document is a working group 
document; It just far too early. Please note that this is, by no means, 
a critique to the authors! It is a really tough job to work on such a 
document at this point in time.

As an example, the following paragraphs show the problems for the authors:

"
    TBD: DNS exchange could present proxy 1 with a set of peering
    policies that need to be met for the peering with proxy 2 too
    succeed.
"

Section 3.2 talks about a solution that does not provide enough details 
to be understood.

Section 5 talks about a non-agreed solution.

Let me also provide some tiny comments:

* I suggest to put the 'on-demand' / 'static' peering into the 
terminology and/or the architecture document.

* Replace every occurrence of SPEERMINT with 'VoIP peering' or something 
else.

* Indicate the type of the document into the template (Informational RFC).

Hence, the RFC 2119 terminology in the document has to go away. The RFC 
2219 boilerplate is also obsolete.

* You write:

"
    Normally, media for a given SIP session follows a different path,
    traversing a different device (most commonly a router) when crossing
    peering domains. Alternatively, media for a given session can be
    directed to traverse the same device used for Layer 5 peering, i.e.,
    the same device that handles signaling when crossing domains.
"

What you mean is that the intersection of the set of nodes traversed by 
the media traffic and the set of nodes traversed by SIP signaling 
messages is not empty. It does not mean that the two sets are equal.

If the description in the architecture document would be more precise 
then you could just replace the the text in this document with a reference.

* I suggest to add the Decomposed/Collapsed terminology into the 
terminology document.

* No figure without a reference in the text. No figure without a 
description of the figure.

* Figure 2 is not aligned with the terminology in the architecture 
document. Here you write "B2BUA & other funct." whereas in the 
architecture document you are talking about SF and MF.

* In Figure 3 you might want to highlight that there is an interaction 
between the SF and the MF. Replace B2BUA with SF.

* Figure 2 & 3 do not match to Figure 1 since the media traffic always 
travels through the MF in Figure 2/3 whereas this aspect is not shown in 
Figure 1. Why do you need Figure 1?

Why don't you put these figures into the architecture document? 
Currently, you only have Figure 3 in 
draft-ietf-speermint-architecture-00.txt. Figure 2/3 is, however, much 
better.

* The figures in Section 2 do not have a caption.

Mixing static and dynamic peering into the same figure is not helpful 
from an editorial point of view.

The important information in Section 2 is actually missing: Exchange of 
information for peering.

* Section 13: Security Considerations: You write:

"
    If the two proxies communicate over an insecure network, and
    consequently are subject to attacks, the use of TLS or IPSec would be
    advisable.
"

Are you suggesting to protect signaling and / or media traffic?

* I have absolutely no clue what Section 3.3 is about.

* I don't understand Section 4.1. What is the magic about IPsec here? Is 
IPsec used to protect signaling or data traffic? How are the IPsec SAs 
created? IKEv2?

* Section 4.2: It does not make sense to argue about co-located proxies.
They are not co-located.

Why does it make a big difference whether the SIP signaling messages are 
protected via TLS, IPsec, L2VPNs, etc.?

* Don't use references in the heading of a section

(see Section 6 for an example)

* I think it is time to decide whether you want to discuss aspects like

   - NAT traversal
   - Firewall traversal
   - Quality of Service

Some documents say that these aspects are outside the scope. Some other 
discuss them.

This is not consistent.

Section 7 would much better fit into the architecture document if you 
think it is useful to talk about it.

If you want to talk about QoS then you need to consider the IETF work.

* Section 8 is something for the architecture document.

* Why is Section 9 again dealing with QoS although Section 7.3 did it 
already? My previous comment is applicable.

* I am not sure what you try to accomplish in Section 10. What 
information would you like to obtain from RADIUS?

I stopped my review with Section 10.

Ciao
Hannes

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