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

Flemming Andreasen <fandreas@cisco.com> Tue, 08 January 2013 03:23 UTC

Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E1921F870A for <mmusic@ietfa.amsl.com>; Mon, 7 Jan 2013 19:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.695
X-Spam-Level:
X-Spam-Status: No, score=-9.695 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qJhSGbaV5ky for <mmusic@ietfa.amsl.com>; Mon, 7 Jan 2013 19:23:51 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63221F84F6 for <mmusic@ietf.org>; Mon, 7 Jan 2013 19:23:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3903; q=dns/txt; s=iport; t=1357615431; x=1358825031; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=soFoU2b5d1XexTFZ5HDUINd0iho53dkICQBKJ3p/bO0=; b=KNP0duWwJe+s42w3FhSxf5jx+tStC1ktrgmLUIOxJ6Th5Rkjw+xgL2Rv IRQyCx2QLbEYD7Xhr52+W4/3N+fasPk0GAHlfQV+cJFDyAAtG6L1uMVIm DaF8KXe975i9MBSlqxWI7E+YM9WS9FrRkXt79DYPWAyUbRX/QcmppaXNj s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjIIAHmQ61CtJV2Y/2dsb2JhbABFg0e6DBZzgl1AATwWGAMCAQIBSw0BBwEBBRKHfAy3J4xngVKCXAOIYYl3gzOQSYJnK4FK
X-IronPort-AV: E=Sophos;i="4.84,428,1355097600"; d="scan'208";a="159864403"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jan 2013 03:23:50 +0000
Received: from rtp-fandreas-8719.cisco.com (rtp-fandreas-8719.cisco.com [10.117.7.90]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r083NnGi032089; Tue, 8 Jan 2013 03:23:50 GMT
Message-ID: <50EB9145.8050301@cisco.com>
Date: Mon, 07 Jan 2013 22:23:49 -0500
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "draft-boucadair-mmusic-altc@tools.ietf.org" <draft-boucadair-mmusic-altc@tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mmusic <mmusic@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: [MMUSIC] SDP Directorate: Review of draft-boucadair-mmusic-altc-07
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2013 03:23:52 -0000

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