[MMUSIC] SDP Directorate: Review of draft-boucadair-mmusic-altc-07

[Flemming Andreasen <[e-mail]>]

Hi

I am the assigned SDP directorate reviewer for 
draft-boucadair-mmusic-altc-07

For background on the SDP directorate, please see the FAQ at

     http://www.ietf.org/iesg/directorate/sdp.html

Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

Summary:
---------
- The document does not adequately cover how it relates to the existing 
Standards Track mechanism for solving the similar problem in a different 
and more general way (namely ICE [RFC 5245])
- The document has technical issues
- The document has a few minor editorial issues


New SDP Information Elements:
---------------------------
The draft defines a new "a=altc" attribute


Technical Comments:
------------------
1) The Abstract positions the document as an alternative to ANAT, but 
without certain problems experienced by ANAT. The abstract fails to 
mention that a general Standards Track solution in the form of ICE (RFC 
5245) has been defined whereas the solution defined in this document has 
a narrower scope and various limitations.

2) Section 1.1, third paragraph. The document states that ICE is 
processing intensive and has seen limited deployment. While this is 
perhaps a matter of debate, it would be helpful if the document would 
point out the limitations of using instead of ICE. Areas that come to 
mind here are
- lack of NAT traversal (without network/SBC support),
- no connectivity verification (verifying functioning path as well as 
authenticating/correlating initial incoming media packets with signaling),
- support for non-contiguous RTP/RTCP port pairs in alternatives
There are probably others and it would be helpful to point those out to 
potential implementers (the simplicity comes with trade-offs).

3) Section 1.1, third paragraph: The document claims that ICE is not 
usable in closed networks. This is incorrect (it is however correct that 
there are scenarios where ICE does not work, however those scenarios 
should then be explained instead).

4) Section 1.1, fourth paragraph: The document claims to be compliant 
with RFC 6157 because RFC 6157 includes the sentence
<quote>
The use of ICE can be avoided for signaling messages that stay within 
such managed networks
</quote>
The quote is taken out of context however as it applies to a scenario in 
RFC 6157 where the entire network is IPv6 based, whereas the mechanism 
defined here is for scenarios where it is not.

5) Section 3.2, first paragraph
<quote>
A compliant SDP parser will ignore any session description that contains 
attribute lines it does not support.
<quote>
No - only the unsupported attribute lines will be ignored (which is also 
what the rest of the draft implies)

6) Section 4.1, attribute definition
The optional trailing integer part is not defined.

7) Section 4.1, Bullet list, "port"
This does not seem to work with the "a=rtcp" attribute [RFC 4566], and 
hence there may be issues with non-contiguous RTP/RTCP port pair support 
in alternatives.

8) Section 4.1, 4th last paragraph
The mechanism relies on implicit ordering of attribute lines. If an 
intermediary changes the order, it would have unintended side-effects. 
It would be much better to have an explicit ordering mechanism. In the 
absence of that, the potential reordering issue should be called out.


Editorial Comments:
-----------------
1) Section 1.1, second paragraph. Add reference after "DS-Lite"

2) sdp-cap-neg should be SDPCapNeg (multiple occurrences)

3) Section 1.3, first paragraph: Add reference to RFC 4091.

4) Section 1.3, second paragraph: Add text and reference to RFC 6157 for 
a solution to "SIP layer address family interworking"

5) Section 4.2.3
Add RFC reference after "ICE"

6) Section 4.2.4
Add RFC reference after "SDPCapNeg"


Thanks

-- Flemming