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

[<[e-mail]>]

Dear Flemming,

Thank you for the review. 

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] 
>De la part de Flemming Andreasen
>Envoyé : mardi 8 janvier 2013 04:24
>À : [e-mail]
>Cc : mmusic; Gonzalo Camarillo
>Objet : [MMUSIC] SDP Directorate: Review of 
>draft-boucadair-mmusic-altc-07
>
>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.

Med: I updated the abstract as follows: 

OLD:

   This document proposes a mechanism which allows to carry multiple IP
   addresses, of different address families (e.g., IPv4, IPv6), in the
   same SDP offer.  The proposed attribute solves the backward
   compatibility problem which plagued ANAT, due to its syntax.

NEW:

   This document proposes a mechanism which allows to carry multiple IP
   addresses, of different address families (e.g., IPv4, IPv6), in the
   same SDP offer.  The proposed attribute solves the backward
   compatibility problem which plagued ANAT, due to its syntax.

   The proposed solution is applicable to scenarios where connectivity
   checks are not required.

>
>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).

Med: The scope of ALTC is very clear: scenarios where there is no need for connectivity checks. This is already mentioned in Section 2 and I tried to make it clear in the new proposed abstract text.  

>
>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).

Med: closed networks are provided only as an example. Anyway, I updated the text as follows: 

OLD:

(e.g., closed networks)

NEW:

(e.g., closed networks making use of SBCs)

>
>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.

Med: The text from RFC6157 is:

      Implementations are encouraged to use ICE; however, the normative
      strength of the text above is left at a SHOULD since in some
      managed networks (such as a closed enterprise network) it is
      possible for the administrator to have control over the IP version
      utilized in all nodes and thus deploy an IPv6-only network, for
      example.  The use of ICE can be avoided for signaling messages
      that stay within such managed networks.

IPv6-only is mentioned as an example. The key word IMHO in the above text is "managed networks". 

>
>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)

Med: OK. I updated the text.

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

Med: Thanks for catching this. I updated section 4.1.

>
>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.

Med: We updated the text as follows:

OLD:

   Note that for RTCP, if applicable for the given media types, each
   side would act as if the chosen "altc" attribute's port number was in
   the 'm=' media line.  Typically, this would mean RTCP is sent to the
   odd +1 of the port number, unless some other attribute determines
   otherwise.

NEW:

   Note that for RTCP, if applicable for the given media types, each
   side would act as if the chosen "altc" attribute's port number was in
   the 'm=' media line.  Typically, this would mean RTCP is sent to the
   odd +1 of the port number, unless some other attribute determines
   otherwise.

   For example the RTP/RTCP multiplexing mechanism defined in [RFC5761]
   can still be used with ALTC, such that if both sides support
   multiplexing they will indicate so using the 'a=rtcp-mux' attribute
   as defined in [RFC5761]; but the IP connection address and port they
   use may be chosen using the ALTC mechanism.

   If the SDP offerer wishes to use the RTCP attribute defined in
   [RFC3605], a complication can arise since it may not be clear which
   address choice the 'a=rtcp' attribute applies to, relative the
   choices offered by ALTC.  Technically RFC 3605 allows indicating the
   address for RTCP explicitly in the 'a=rtcp' attribute itself, but
   this is optional and rarely used.  Since RFC 3605 did not prevent
   encoding multiple 'a=rtcp' attributes per media description, this
   document recommends encoding the first 'a=rtcp' attribute to be for
   the address choice encoded in the "m=" line, and a second 'a=rtcp'
   attribute for the alternate address provided by the 'a=altc'
   attribute.  In other words, if the 'a=rtcp' attribute explicitly
   encodes an address in its attribute, then that applies for ALTC as
   per [RFC3605]; if it does not, then ALTC assumes the first one is for
   the address in the "m=" line, and the second is for the alternate.

>
>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.

Med: Is this harmful? If an intermediary entity change the order, this does not impact the session establishment. Note the document already specify how a remote UA can detect the presence of an intermediary entity changing the "c" line is present in the path. 

>
>
>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"

Med: I implemented all the proposed changed. Thanks. 

>
>
>Thanks
>
>-- Flemming
>
>_______________________________________________
>mmusic mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mmusic
>