Return-Path: 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 135F711E8110 for ; Thu, 14 Mar 2013 10:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+Gs2FCgriz8 for ; Thu, 14 Mar 2013 10:43:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C6B8011E80E9 for ; Thu, 14 Mar 2013 10:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56441; q=dns/txt; s=iport; t=1363283005; x=1364492605; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=jq1Zqf86xHj7bjIpeGcSjyXbjddjdPdeG7FJ5MSG1Ps=; b=NtM/vchv5nzRxUUFHmvLWDn7YsyROSc83eg2edfBe0mo0+mx3c3hEdZg njGS3H1ZBQ0pV/KRh+HxrkuV8lfUZ3+aKAmw3ylCvNvATFcaUqrbv02Ap 4BN/dsZvxoy96EOYAw+l/LdfSF2wtiMimMneIFbgOxxGd9LLrFDT8ebh5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAKAGULQlGtJV2Z/2dsb2JhbABDhVKINbZ2BAGBZRZ0gisBAQEDAQEBARcBUwQGAQUHBAsRBAEBAQkWAQEGBwkDAgECARUfCQgTAQUCAQEFEodzBgcFwhKNZSt0BwEKBgEGgzoDlliBH49jgyYggTc X-IronPort-AV: E=Sophos; i="4.84,845,1355097600"; d="scan'208,217"; a="187586896" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 14 Mar 2013 17:43:24 +0000 Received: from dhcp-170e.meeting.ietf.org ([10.86.245.177]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2EHhMm5023339; Thu, 14 Mar 2013 17:43:23 GMT Message-ID: <51420C3A.3040807@cisco.com> Date: Thu, 14 Mar 2013 13:43:22 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <5141DFF8.4050006@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356863@PUEXCB1B.nanterre.francetelecom.fr> <5141EB56.9090103@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7356880@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB7356880@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------030001040501020008050604" X-Mailman-Approved-At: Thu, 14 Mar 2013 10:56:33 -0700 Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:43:31 -0000 This is a multi-part message in MIME format. --------------030001040501020008050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote: > Re-, > What is important is the quality of produced documents. The content of > the document is not frozen and unless I'm mistaken there is not IETF LC. > Correct. > What I understand from the text in the draft is: ccap is allowed to > signal an IPv4@ and IPv6@ if ICE is not supported. > ccap is not prohibited from doing so in the absence of ICE, however as explained in the document 1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT signal an IPv4/IPV6 address alternative. 2) The draft does (intentionally) not provide a full solution for negotiating alternative IP-addresses since we have a Standards Track mechanism for doing so (ICE). > Simo said: "That's not what I want." and it seems you disagree with him. > You are quoting out of context. Other than that I will let Simo respond. > This illustrates there is a confusion in the current wording and the > intent of that text is not clear. > I think the wording is clear, however I understand that you do not necessarily agree with it. The time to express that dissenting opinion was ~6 monhts ago when WGLC was issued and completed without comments. Again, as WG chair, I'm not sympathetic to re-opening the document this late in the process on the grounds that you have provided. Thanks -- Flemming (MMUSIC co-chair) > Cheers, > Med > > ------------------------------------------------------------------------ > *De :* Flemming Andreasen [mailto:fandreas@cisco.com] > *Envoyé :* jeudi 14 mars 2013 16:23 > *À :* BOUCADAIR Mohamed OLNC/OLN > *Cc :* Jonathan Lennox; Andrew Allen; mmusic@ietf.org > *Objet :* Re: [MMUSIC] RE : I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > On 3/14/13 11:19 AM, mohamed.boucadair@orange.com wrote: >> Dear Flemming, >> Apologies for not sending my comment earlier. I should read the >> draft before but I didn't read it since a while. >> It is unfair to ignore the messages exchanged in this thread >> which say the text is confusing and it should be worked better. >> The wording proposed by Jonathan is much better. >> > I respectfully disagree. What is unfair is that people do not read > documents when they are WGLC'ed but still expect their comments to > be addressed ~6 months later. > > As to the message below be specific please; exactly what is it > that is unclear in the text below ? > > Thanks > > -- Flemming > > >> Cheers, >> Med >> >> ------------------------------------------------------------------------ >> *De :* Flemming Andreasen [mailto:fandreas@cisco.com] >> *Envoyé :* jeudi 14 mars 2013 15:35 >> *À :* Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN >> *Cc :* Andrew Allen; mmusic@ietf.org >> *Objet :* Re: [MMUSIC] RE : I-D Action: >> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >> >> A couple of points here related to the overall thread: >> >> 1) WGLC for this draft completed about 6 months ago with no >> comments on the draft >> (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html). >> The -01 version that was WGLC'ed stated the following: >> >> >> The 'ccap' capability attribute is intended to >> be used only when there is no other mechanism available for >> negotiating alternative connection address information, such as when >> the is different among the alternative addresses. The >> 'ccap' attribute MUST NOT be used in situations where an existing >> mechanism (such as Interactive Connectivity Establishment (ICE) >> [RFC5245]) can be used to select between different connection >> addresses. >> >> > >> and there is what the current -04 states: >> >> >> The 'ccap' capability attribute is intended to >> be used only when there is no other mechanism available for >> negotiating alternative connection address information, such as when >> the is different among the alternative addresses (e.g. >> "IN" and "PSTN"). The 'ccap' attribute MUST NOT be used in >> situations where an existing mechanism (such as Interactive >> Connectivity Establishment (ICE) [RFC5245]) can be used to select >> between different connection addresses (e.g. "IP4" and "IP6" or >> different IP addresses within the same IP address family). >> >> >> >> The only difference is the addition of clarifying examples >> and hence there is no change in operation here. >> >> 2) On January 25, Simo sent an e-mail to the list pointing >> out the port issue and suggesting text to be added >> (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html). >> To recap, the draft specifically does not define port >> negotiation (but simply reuses the current port in accordance >> with general capability negotiation operation). Since this >> doesn't work when changing between IN and PSTN, exception >> text to use port 9 for PSTN was added (again in accordance >> with previous discussion). One comment was received, which >> was in favor of the proposal. >> >> >> The comments brought up now are not identifying any new or >> severe problems, but essentially amount to word-smithing >> requests. As a Working Group chair, I am unsympathetic to >> such requests on a document that is this far along and >> furthermore has external dependencies. We go through a WGLC >> process for a reason, and people need to review and make >> their comments at that time. >> >> Comments on new text or changes made since the WGLC completed >> are of course reasonable. With that in mind, if anybody still >> has comments on the -04 version, please let us know. >> >> Thanks >> >> -- Flemming (MMUSIC co-chair) >> >> >> >> >> On 3/14/13 9:04 AM, Jonathan Lennox wrote: >>> I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses. We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it. >>> >>> Thus, I suggest something like this (wordsmithing requested): >>> >>> The 'ccap' attribute MUST NOT be used to offer multiple addresses with the "IN" (i.e., multiple Internet protocol addresses) in the same media stream. Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses. The use of ICE with capability negotiation is described in section 3.7 of [RFC5939]. >>> >>> >>> This text might also be useful (though it definitely needs editorial improvement): >>> >>> In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the "IN"); otherwise, under the rules of ICE, an ICE mismatch will result. However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer. >>> >>> >>> On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote: >>> >>>> The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it. >>>> >>>> Andrew >>>> >>>> ----- Original Message ----- >>>> From:mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >>>> Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time >>>> To: Andrew Allen;thomas.stach@siemens-enterprise.com ;Simo.Veikkolainen@nokia.com ;mmusic@ietf.org >>>> Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>> >>>> Hi Andrew, >>>> >>>> This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address. >>>> >>>> If it is not allowed, then the text should be clear. >>>> >>>> Cheers, >>>> Med >>>> >>>> ________________________________________ >>>> De : Andrew Allen [aallen@blackberry.com] >>>> Date d'envoi : mercredi 13 mars 2013 19:37 >>>> À : BOUCADAIR Mohamed OLNC/OLN;thomas.stach@siemens-enterprise.com;Simo.Veikkolainen@nokia.com;mmusic@ietf.org >>>> Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>> >>>> The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined mechanism. >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From:mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >>>> Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time >>>> To: Stach, Thomas;Simo.Veikkolainen@nokia.com ;mmusic@ietf.org >>>> Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>> >>>> Re-, >>>> >>>> The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered. >>>> >>>> In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid. >>>> >>>> The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address. >>>> >>>> Cheers, >>>> Med >>>> >>>> ________________________________________ >>>> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >>>> Date d'envoi : mercredi 13 mars 2013 19:17 >>>> À : BOUCADAIR Mohamed OLNC/OLN;Simo.Veikkolainen@nokia.com;mmusic@ietf.org >>>> Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>> >>>> Mohammed, >>>> >>>> I think it is not acceptable to mention altc in the example. >>>> If I recollect correctly, the intention of the text is to specify that ICE MUST be >>>> preferred over 'ccap' for IPv4/v6 address negotiation. >>>> >>>> If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'. >>>> I don't think that a standards track RFC should give the message that proprietary is preferred. >>>> Based on this issue I think the current text in the draft does not work. >>>> I would explicitly mention the relation of ICE and 'ccap'. >>>> The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism. >>>> >>>> Thus I propose to rephrase to: >>>> >>>> If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and >>>> the 'ccap' attribute it MUST use ICE to select between different connection addresses >>>> (e.g. "IP4" and "IP6" or different IP addresses within the same IP address family). >>>> >>>> >>>> Regards >>>> Thomas >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von:mohamed.boucadair@orange.com >>>>> [mailto:mohamed.boucadair@orange.com] >>>>> Gesendet: Mittwoch, 13. März 2013 13:40 >>>>> An: Stach, Thomas;Simo.Veikkolainen@nokia.com;mmusic@ietf.org >>>>> Betreff: RE : [MMUSIC] I-D Action: >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>> >>>>> Dear Thomas, >>>>> >>>>> I'm not proposing to change the existing behavior; I'm just >>>>> asking whether it is acceptable to add an additional example >>>>> to the one already cited in the text. >>>>> Wouldn't that be acceptable? >>>>> >>>>> You can propose to add another example if you have any in mind. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> ________________________________________ >>>>> De : Stach, Thomas [thomas.stach@siemens-enterprise.com] >>>>> Date d'envoi : mercredi 13 mars 2013 17:57 >>>>> À : BOUCADAIR Mohamed OLNC/OLN;Simo.Veikkolainen@nokia.com; >>>>> mmusic@ietf.org >>>>> Objet : AW: [MMUSIC] I-D Action: >>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>> >>>>> Mohammed, >>>>> >>>>> I think you have draft-boucadair-mmusic-altc in mind. >>>>> This is an individual submission intended to document some >>>>> proporietary mechanism. >>>>> I don't think we should make restrictions in a standards >>>>> track document in support of proprietary mechanisms. >>>>> Otherwise I could also think of additional proprietary stuff >>>>> that could be mentioned as well. >>>>> >>>>> >>>>> Regards >>>>> Thomas >>>>> >>>>>> -----Ursprüngliche Nachricht----- >>>>>> Von:mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>>>> Im Auftrag vonmohamed.boucadair@orange.com >>>>>> Gesendet: Mittwoch, 13. März 2013 11:20 >>>>>> An:Simo.Veikkolainen@nokia.com;mmusic@ietf.org >>>>>> Betreff: Re: [MMUSIC] I-D Action: >>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>>> >>>>>> Hi Simo, >>>>>> >>>>>> The document says: >>>>>> >>>>>> The 'ccap' attribute MUST NOT be used in >>>>>> situations where an existing mechanism (such as Interactive >>>>>> Connectivity Establishment (ICE) [RFC5245]) can be used to select >>>>>> between different connection addresses (e.g. "IP4" and "IP6" or >>>>>> different IP addresses within the same IP address family). >>>>>> >>>>>> Would it be possible to change it to the following: >>>>>> >>>>>> NEW: >>>>>> >>>>>> The 'ccap' attribute MUST NOT be used in >>>>>> situations where a mechanism (such as Interactive >>>>>> Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is >>>>>> used to select >>>>>> between different connection addresses (e.g. "IP4" and "IP6" or >>>>>> different IP addresses within the same IP address family). >>>>>> >>>>>> >>>>>> Thanks. >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De :mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>>>>> De la part deSimo.Veikkolainen@nokia.com >>>>>>> Envoyé : mercredi 13 mars 2013 16:09 >>>>>>> À :mmusic@ietf.org >>>>>>> Objet : Re: [MMUSIC] I-D Action: >>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> We just submitted a new version of the miscellaneous-caps >>>>>>> draft, with text that states that if the connection data >>>>>>> capability attribute (a=ccap) is used the port number in the >>>>>>> resulting SDP MUST be the same as in the original "m=" line, >>>>>>> except for PSTN type bearers (when the port number used is 9). >>>>>>> >>>>>>> Regards, >>>>>>> Simo >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From:mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] >>>>>>> On Behalf Of extinternet-drafts@ietf.org >>>>>>> Sent: 13. maaliskuuta 2013 15:39 >>>>>>> To:i-d-announce@ietf.org >>>>>>> Cc:mmusic@ietf.org >>>>>>> Subject: [MMUSIC] I-D Action: >>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts directories. >>>>>>> This draft is a work item of the Multiparty Multimedia >>>>>>> Session Control Working Group of the IETF. >>>>>>> >>>>>>> Title : Miscellaneous Capabilities >>>>>>> Negotiation in the Session Description Protocol (SDP) >>>>>>> Author(s) : Miguel A. Garcia-Martin >>>>>>> Simo Veikkolainen >>>>>>> Robert R. Gilman >>>>>>> Filename : >>>>>>> draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt >>>>>>> Pages : 21 >>>>>>> Date : 2013-03-13 >>>>>>> >>>>>>> Abstract: >>>>>>> SDP has been extended with a capability negotiation mechanism >>>>>>> framework that allows the endpoints to negotiate >>>>>> transport protocols >>>>>>> and attributes. This framework has been extended with a media >>>>>>> capabilities negotiation mechanism that allows endpoints to >>>>>>> negotiate >>>>>>> additional media-related capabilities. This negotiation >>>>>> is embedded >>>>>>> into the widely-used SDP offer/answer procedures. >>>>>>> >>>>>>> This memo extends the SDP capability negotiation >>>>>> framework to allow >>>>>>> endpoints to negotiate three additional SDP capabilities. In >>>>>>> particular, this memo provides a mechanism to negotiate >>>>> bandwidth >>>>>>> ('b=' line), connection data ('c=' line), and titles >>>>>> ('i=' line for >>>>>>> each session or media). >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella >>>>>>> neous-caps >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella >>>>>>> neous-caps-04 >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> _______________________________________________ >>>>>>> mmusic mailing list >>>>>>> mmusic@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>>> >>>>>> _______________________________________________ >>>>>> mmusic mailing list >>>>>> mmusic@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmusic >>>>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> -- >>> Jonathan Lennox >>> jonathan@vidyo.com >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> . >>> >> > --------------030001040501020008050604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 3/14/13 11:40 AM, mohamed.boucadair@orange.com wrote:
Re-,
 
What is important is the quality of produced documents. The content of the document is not frozen and unless I'm mistaken there is not IETF LC.

Correct.
What I understand from the text in the draft is: ccap is allowed to signal an IPv4@ and IPv6@ if ICE is not supported.

ccap is not prohibited from doing so in the absence of ICE, however as explained in the document
1) When the IETF Standard Track mechanism ICE is available, ccap MUST NOT signal an IPv4/IPV6 address alternative.
2) The draft does (intentionally) not provide a full solution for negotiating alternative IP-addresses since we have a Standards Track mechanism for doing so (ICE).


Simo said: "That's not what I want." and it seems you disagree with him.

You are quoting out of context. Other than that I will let Simo respond.

This illustrates there is a confusion in the current wording and the intent of that text is not clear.

I think the wording is clear, however I understand that you do not necessarily agree with it. The time to express that dissenting opinion was ~6 monhts ago when WGLC was issued and completed without comments. Again, as WG chair, I'm not sympathetic to re-opening the document this late in the process on the grounds that you have provided.

Thanks

-- Flemming (MMUSIC co-chair)


Cheers,
Med

De : Flemming Andreasen [mailto:fandreas@cisco.com]
Envoyé : jeudi 14 mars 2013 16:23
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Jonathan Lennox; Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


On 3/14/13 11:19 AM, mohamed.boucadair@orange.com wrote:
Dear Flemming,
 
Apologies for not sending my comment earlier. I should read the draft before but I didn't read it since a while.
 
It is unfair to ignore the messages exchanged in this thread which say the text is confusing and it should be worked better. The wording proposed by Jonathan is much better.

I respectfully disagree. What is unfair is that people do not read documents when they are WGLC'ed but still expect their comments to be addressed ~6 months later.

As to the message below be specific please; exactly what is it that is unclear in the text below ?

Thanks

-- Flemming


Cheers,
Med

De : Flemming Andreasen [mailto:fandreas@cisco.com]
Envoyé : jeudi 14 mars 2013 15:35
À : Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
Cc : Andrew Allen; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

A couple of points here related to the overall thread:

1) WGLC for this draft completed about 6 months ago with no comments on the draft (http://www.ietf.org/mail-archive/web/mmusic/current/msg09594.html). The -01 version that was WGLC'ed stated the following:
<quote>
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses.  The
   'ccap' attribute MUST NOT be used in situations where an existing
   mechanism (such as Interactive Connectivity Establishment (ICE)
   [RFC5245]) can be used to select between different connection
   addresses.
</quote

and there is what the current -04 states:
<quote>
The 'ccap' capability attribute is intended to
   be used only when there is no other mechanism available for
   negotiating alternative connection address information, such as when
   the <nettype> is different among the alternative addresses (e.g.
   "IN" and "PSTN").  The 'ccap' attribute MUST NOT be used in
   situations where an existing mechanism (such as Interactive
   Connectivity Establishment (ICE) [RFC5245]) can be used to select
   between different connection addresses (e.g.  "IP4" and "IP6" or
   different IP addresses within the same IP address family).
</quote>

The only difference is the addition of clarifying examples and hence there is no change in operation here.

2) On January 25, Simo sent an e-mail to the list pointing out the port issue and suggesting text to be added (http://www.ietf.org/mail-archive/web/mmusic/current/msg10160.html). To recap, the draft specifically does not define port negotiation (but simply reuses the current port in accordance with general capability negotiation operation). Since this doesn't work when changing between IN and PSTN, exception text to use port 9 for PSTN was added (again in accordance with previous discussion). One comment was received, which was in favor of the proposal.


The comments brought up now are not identifying any new or severe problems, but essentially amount to word-smithing requests. As a Working Group chair, I am unsympathetic to such requests on a document that is this far along and furthermore has external dependencies. We go through a WGLC process for a reason, and people need to review and make their comments at that time.

Comments on new text or changes made since the WGLC completed are of course reasonable. With that in mind, if anybody still has comments on the -04 version, please let us know.

Thanks

-- Flemming (MMUSIC co-chair)




On 3/14/13 9:04 AM, Jonathan Lennox wrote:
I suggest being more concrete about ccap's restrictions, that it can't be used to negotiate alternative IP addresses.  We can then discuss only ICE, without precluding altc for the proprietary systems which want to use it.

Thus, I suggest something like this (wordsmithing requested):

The 'ccap' attribute MUST NOT be used to offer multiple addresses with the <nettype> "IN" (i.e., multiple Internet protocol addresses) in the same media stream.  Interactive Connectivity Establishment (ICE) [RFC5245] can be used to allow a choice among multiple Internet addresses.  The use of ICE with capability negotiation is described in section 3.7 of [RFC5939].


This text might also be useful (though it definitely needs editorial improvement):

In principle, the attributes associated with ICE ought to be included only in configurations where each media stream has a connection address which matches one of the ICE candidates (i.e, for currently-defined candidate types, a configuration whose connection address has the <nettype> "IN"); otherwise, under the rules of ICE, an ICE mismatch will result.  However, this ICE mismatch will in fact induce the desired behavior, causing the answerer to abort ICE processing and use the connection address; so this ICE mismatch is harmless, other than the inclusion of an "ice-mismatch" attribute in the SDP answer.


On Mar 13, 2013, at 3:03 PM, Andrew Allen wrote:


The text in the draft was worked out with Jonathan Lennox who raised the initial concen about conflict with ICE. If Jonathan is ok with the revised proposal from Thomas then I am OK with it.

Andrew

----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; thomas.stach@siemens-enterprise.com <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

This was also my understanding but it seems the current text opens the door to signal an IPv4 and IPv6 address.

If it is not allowed, then the text should be clear.

Cheers,
Med

________________________________________
De : Andrew Allen [aallen@blackberry.com]
Date d'envoi : mercredi 13 mars 2013 19:37
À : BOUCADAIR Mohamed OLNC/OLN; thomas.stach@siemens-enterprise.com; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

The main use of the CCAP parameter is to indicate the capability to use CS SDP and E.164 numbers as a connection address and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  mechanism.



----- Original Message -----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <thomas.stach@siemens-enterprise.com>; Simo.Veikkolainen@nokia.com <Simo.Veikkolainen@nokia.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

The wording you propose is better as it explicits this behavior is about ICE and not something else. So, I'm fine with that wording if this is the intent of the authors. BTW, the altc draft already mentions that if altc and ccap are both supported, then both are offered.

In fact, I stopped to track this draft since the Anaheim meeting when it seems the consensus of the wg was: ICE is to solution to signal an IPv4 and IPv6 address. The misc draft should specify ccap when distinct nettypes are in use. It seems that consensus is not anymore valid.

The current text of ccap is under-specified if it is to be used to convey an IPv4 and IPv6 address.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 19:17
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think it is not acceptable to mention altc in the example.
If I recollect correctly, the intention of the text is to specify that ICE MUST be
preferred over 'ccap' for IPv4/v6 address negotiation.

If we add 'altc' as another example it basically means that the proprietary 'altc' is preferred over 'ccap'.
I don't think that a standards track RFC should give the message that proprietary is preferred.
Based on this issue I think the current text in the draft does not work.
I would explicitly mention the relation of ICE and 'ccap'.
The relation to other mechanism such as 'altc' needs to be treated in hte specification of that mechanism.

Thus I propose to rephrase to:

If an offerer has implemented Interactive Connectivity Establishment (ICE) [RFC5245] and
the 'ccap' attribute it MUST use ICE to select between different connection addresses
(e.g.  "IP4" and "IP6" or different IP addresses within the same IP address family).


Regards
Thomas


-----Ursprüngliche Nachricht-----
Von: mohamed.boucadair@orange.com
[mailto:mohamed.boucadair@orange.com]
Gesendet: Mittwoch, 13. März 2013 13:40
An: Stach, Thomas; Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

I'm not proposing to change the existing behavior; I'm just
asking whether it is acceptable to add an additional example
to the one already cited in the text.
Wouldn't that be acceptable?

You can propose to add another example if you have any in mind.

Cheers,
Med

________________________________________
De : Stach, Thomas [thomas.stach@siemens-enterprise.com]
Date d'envoi : mercredi 13 mars 2013 17:57
À : BOUCADAIR Mohamed OLNC/OLN; Simo.Veikkolainen@nokia.com;
mmusic@ietf.org
Objet : AW: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

I think you have draft-boucadair-mmusic-altc in mind.
This is an individual submission intended to document some
proporietary mechanism.
I don't think we should make restrictions in a standards
track document in support of proprietary mechanisms.
Otherwise I could also think of additional proprietary stuff
that could be mentioned as well.


Regards
Thomas


-----Ursprüngliche Nachricht-----
Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
Im Auftrag von mohamed.boucadair@orange.com
Gesendet: Mittwoch, 13. März 2013 11:20
An: Simo.Veikkolainen@nokia.com; mmusic@ietf.org
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

The 'ccap' attribute MUST NOT be used in
  situations where an existing mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245]) can be used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).

Would it be possible to change it to the following:

NEW:

The 'ccap' attribute MUST NOT be used in
  situations where a mechanism (such as Interactive
  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select
  between different connection addresses (e.g.  "IP4" and "IP6" or
  different IP addresses within the same IP address family).


Thanks.
Cheers,
Med



-----Message d'origine-----
De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
De la part de Simo.Veikkolainen@nokia.com
Envoyé : mercredi 13 mars 2013 16:09
À : mmusic@ietf.org
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

We just submitted a new version of the miscellaneous-caps
draft, with text that states that if the connection data
capability attribute (a=ccap) is used the port number in the
resulting SDP MUST be the same as in the original "m=" line,
except for PSTN type bearers (when the port number used is 9).

Regards,
Simo

-----Original Message-----
From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]
On Behalf Of ext internet-drafts@ietf.org
Sent: 13. maaliskuuta 2013 15:39
To: i-d-announce@ietf.org
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia
Session Control Working Group of the IETF.

   Title           : Miscellaneous Capabilities
Negotiation in the Session Description Protocol (SDP)
   Author(s)       : Miguel A. Garcia-Martin
                        Simo Veikkolainen
                        Robert R. Gilman
   Filename        :
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
   Pages           : 21
   Date            : 2013-03-13

Abstract:
 SDP has been extended with a capability negotiation mechanism
 framework that allows the endpoints to negotiate

transport protocols

 and attributes.  This framework has been extended with a media
 capabilities negotiation mechanism that allows endpoints to
negotiate
 additional media-related capabilities.  This negotiation

is embedded

 into the widely-used SDP offer/answer procedures.

 This memo extends the SDP capability negotiation

framework to allow

 endpoints to negotiate three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate

bandwidth

 ('b=' line), connection data ('c=' line), and titles

('i=' line for

 each session or media).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscella
neous-caps

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscella
neous-caps-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

--
Jonathan Lennox
jonathan@vidyo.com


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
.



--------------030001040501020008050604--