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 3D36F21F866F for ; Sun, 17 Mar 2013 22:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.415 X-Spam-Level: X-Spam-Status: No, score=-8.415 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MANGLED_LOAN=2.3, 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 Yh2mwpAR2zpa for ; Sun, 17 Mar 2013 22:58:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7635021F85EE for ; Sun, 17 Mar 2013 22:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57457; q=dns/txt; s=iport; t=1363586333; x=1364795933; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=iq55Bza2xoZjyaNFkW2xKyQCwE+Qaf22gf8bnk4REdM=; b=Uxmu86XQWASgSF/r5zjAsrUA5vHy/nhivm5W1dt7pUFJxkBOHlzYuGne eRT+3oeVTAN2PsGUOyO28idY+CQs72cwG02eVM85oU1GI5IW5EEK7xmYO IOv3rdEC3AExruk6O94snqWRBbYlVeJ6KxOfMTn2/6NVVbKGoCJt3OmY8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAKerRlGtJXG9/2dsb2JhbABChBSJa7ckgVkWdIIkAQEBBBoTQQsFCwsRBAEBAQkXAQYHDwI1CQgTAQUCAQEFEod5DMFHF4kJgzyBBRuBAwsQBwEKBgEGgzoDll6BH49jgyYggTc X-IronPort-AV: E=Sophos; i="4.84,862,1355097600"; d="scan'208,217"; a="188501632" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 18 Mar 2013 05:58:51 +0000 Received: from Flemmings-MacBook-Pro.local ([10.86.244.39]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2I5wnaV023996; Mon, 18 Mar 2013 05:58:50 GMT Message-ID: <514690F2.700@cisco.com> Date: Sun, 17 Mar 2013 23:58:42 -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: Simo.Veikkolainen@nokia.com References: <5142356F.3060201@cisco.com> <94C682931C08B048B7A8645303FDC9F36EB7F296B6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000806000909070709010205" X-Mailman-Approved-At: Sun, 17 Mar 2013 23:30:59 -0700 Cc: jonathan@vidyo.com, 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: Mon, 18 Mar 2013 05:59:01 -0000 This is a multi-part message in MIME format. --------------000806000909070709010205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit As noted in my e-mail below, the Anaheim discussion was based on the original draft-garcia-mmusic-sdp-misc-cap document, which did indeed position "ccap" as an alternative to ICE. The http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps which was adopted by the WG changed the wording to what is being discussed now and was adopted by the WG. If people wanted to explicitly prevent this mechanism from being used for IP4 and/or IP6 addresses, then I"m at a loss to understand why the current wording was chosen and agreed to as well as to why a general mechanism like "connection data capability" as part of the overall capability negotiation framework was chosen and agreed to. However, in spite of the document reviews, long completed WGLC, and the external 3GPP dependency, it is obvious from the e-mail thread that more discussion is needed on this, and hence we will have to deal with that before we can progress the document. Thanks -- Flemming (MMUSIC co-chair) On 3/15/13 8:04 AM, Simo.Veikkolainen@nokia.com wrote: > > I think this goes all the way back to IETF68, where an agreement was > made to use ICE for future address type selection (deprecating ANAT). > > I couldn't find a written statement in minutes on ccap being > explicitly forbidden to express IP4 and/or IP6 addresses as > alternatives -- but my thought has been that alternative IP addresses > may only be offered with ICE. This was also reflected in by > Jean-Francois > (http://www.ietf.org/mail-archive/web/mmusic/current/msg07916.html) > where he says " As for proposing IPv4/IPv6 alternatives, ICE > deprecates ANAT and is the preferred solution the WG has chosen so far > per IETF#68. " > > Simo > > *From:*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On > Behalf Of *ext mohamed.boucadair@orange.com > *Sent:* 15. maaliskuuta 2013 8:36 > *To:* Flemming Andreasen; Andrew Allen > *Cc:* jonathan@vidyo.com; mmusic@ietf.org > *Subject:* Re: [MMUSIC] RE : I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > Felmming, > > If you are looking for something written, you can read the minutes in > the Anaheim meeting (In > http://tools.ietf.org/wg/mmusic/minutes?item=minutes77.html), you can > read the following: > > To conclude the WG chair report, Jean-Francois clarified the > status ofdraft-ietf-mmusic-sdp-misc-cap-00 (see the chair's > slides #9). > This Internet-Draft was mistakenly accepted as a WG document > without confirmation on the list. > > After a brief recap of the I-D history and scope, several > comments were made in support of continuing the work as part of > a WG item as long as the scope does not overlap with ICE for > IPv4-IPv6 connection address negotiations: > - Roni Even indicated support for the work and noted that the > b parameter was part of the original SDP capability > negotiation framework. > - John Elwell, Gonzalo Camarillo, Jonathan Lennox and Cullen > Jennings are in favor of the work item as long as its scope > is clarified to not overlap with ICE for IPv4-IPv6 address > negotiation. > - Ingemar Johansson also expressed support for it > There was strong support for continuing to define a capability > parameter for b, i and some concerns with the ccap parameter. > More discussions occurred at the end of the meeting when the > document was presented, see notes below. > > Jean-Francois proposed the next steps: > - the WG chairs will confirm the interest for a WG item to > define additional SDP cap neg parameters (b and i lines) > - Pending AD approval, the WG item will be chartered > - Simo V. will re-submit an updated Internet-Draft as an > individual submission > - then the chairs will ask the list if the Working Group > supports making Simo's individual submission as the WG > draft. > The current discussion shows there is a confusion in the current text and it is worth to be clarified. > Cheers, > Med > > ------------------------------------------------------------------------ > > *De :*mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *De > la part de* Flemming Andreasen > *Envoyé :* jeudi 14 mars 2013 21:39 > *À :* Andrew Allen > *Cc :* jonathan@vidyo.com; mmusic@ietf.org > *Objet :* Re: [MMUSIC] RE : I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > On 3/14/13 3:50 PM, Andrew Allen wrote: > > > I am not sure if anything is recorded in any minutes but we > had an offline discussion to remove the roadblock on this with > Jonathan to address his concern that this was a potential > alternative to ICE and addressed this with the current text. > This text and the reason behind it I think was pointed out on > the list during Quebec or shortly after. > > Can you find the message or recall who sent it ? > > Also, the Quebec meeting was in July 2011. Tracing back we have: > > a) The initial (?) individul versions of the draft (2008/2009): > http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap > b) Another individual take on the draft (August 2011+): > http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps > c) The intial WG version of the draft (March 2012+): > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps > > The "a)" version did indeed position the draft as an alternative > to ICE, however all "b)" and "c)" versions changed this as per the > previous discussion. > > I'm still looking for anything written anywhere that suggests that > the text in "b)" and "c)" does not represent consensus and/or that > consensus is that the mechanism MUST always be prohibited from > negotiating IP4/IP6 addresses (as opposed to just when ICE is not > available). > > Thanks > > -- Flemming > > > *From*: Flemming Andreasen [mailto:fandreas@cisco.com] > *Sent*: Thursday, March 14, 2013 02:45 PM Central Standard Time > *To*: Stach, Thomas > > *Cc*: Andrew Allen; jonathan@vidyo.com > ; mmusic@ietf.org > > *Subject*: Re: AW: [MMUSIC] RE : I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > As to ccap not being an alternative to ICE we are all in agreement > on that - the lack of port negotiation alone makes that clear (it > simply doesn't work without that). > > As to ccap being explicitly forbidden to express IP4 and/or IP6 > addresses as alternatives, can somebody please point me to either > meeting minutes or mailing list discussion to that effect ? The > only thing I have found is the port discussion we had in Taipei, > where we agreed not to add a port capability. From > http://www.ietf.org/proceedings/82/minutes/mmusic.htm > : > > > Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10) > > ===================================================================== > > draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt > > > Simo presented hisslides > . > > Simo explained the need to be able to indicate alternative port > numbers, but PSTN media, port number doesn't make sense. The CS > draft says use port number 9 (the discard port). We have to put > something there because required by SDP syntax. If an RTP stream > is offered, then a regular port number should be written instead. > The problem arises when both CS and RTP streams are offered at the > same time, one as an alternative of the other. Then, the port > number makes sense for RTP but not for CS, but still, there is a > single place to write the port number in the SDP, so, has to be > shared by both alternative media streams. > > Possible solutions: > > 1. Circuit-switched media uses the same port as RTP media even > though the port is not really used > > 2. Extend capneg with a port number capability attribute, > restricting its use to cases where ICE cannot be used. > > 3. Select anything as a port number and say "do not care on > reception". > > Jonathan Lennox suggested saying that port numbers not equal 0 > have to be ignored. > > Hadriel Kaplan asked if middle boxes not supporting this stuff can > be broken. The discussion is moved offline. > > There are questions on how could be possible to indicate > preference for one media stream above the alternative. > > Miguel Garcia suggested using port 9 if it works. If not take > anything not equal 0. Receiver has to ignore. > > In general, there was pushback on the port negotiation approach. > The authors should explore a solution along the third option: > write the RTP port number in the "m=" line. If CS alternative is > chosen, discard the port number on reception. > > > > Apart from that, the only thing I'm aware of is the 4 WG versions > of this draft which have all said the same about IP4/IP6 and ICE, > and again, that text was both WGLC'ed and reviewed by 2 volunteers > without any concerns. Where does the alternate understanding come > from ? > > Thanks > > -- Flemming > > > On 3/14/13 2:16 PM, Stach, Thomas wrote: > > This is also my understanding > > ... although my initially proposed text does not reflect this > correctly. > > Regards > Thomas > > ------------------------------------------------------------------------ > > *Von:*mmusic-bounces@ietf.org > > [mailto:mmusic-bounces@ietf.org] *Im Auftrag von *Andrew Allen > *Gesendet:* Donnerstag, 14. März 2013 14:10 > *An:* jonathan@vidyo.com ; > fandreas@cisco.com > *Cc:* mmusic@ietf.org > *Betreff:* Re: [MMUSIC] RE : I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > > My understanding also was that we agreed that CCAP was not > an alternative to ICE. > > *From*: Jonathan Lennox [mailto:jonathan@vidyo.com] > *Sent*: Thursday, March 14, 2013 01:06 PM Central Standard > Time > *To*: Flemming Andreasen > > *Cc*: mohamed.boucadair@orange.com > > > ; Andrew Allen; > mmusic@ietf.org > > *Subject*: Re: [MMUSIC] RE : I-D Action: > draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt > > On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote: > > > > 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). > > Hi, Fleming -- > > My understanding of the WG consensus -- and my > interpretation of the text in the draft -- was stronger > than this: ccap MUST NOT be used for the kinds of > alternatives ICE can express, whether or not ICE is > actually being used in a particular offer/answer. > > If we're getting divergent interpretations of this > document, we probably do need to update its text. > > -- > > Jonathan Lennox > jonathan@vidyo.com > > > --------------------------------------------------------------------- > > 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. > --------------000806000909070709010205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As noted in my e-mail below, the Anaheim discussion was based on the original draft-garcia-mmusic-sdp-misc-cap document, which did indeed position "ccap" as an alternative to ICE. The http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps which was adopted by the WG changed the wording to what is being discussed now and was adopted by the WG.

If people wanted to explicitly prevent this mechanism from being used for IP4 and/or IP6 addresses, then I"m at a loss to understand why the current wording was chosen and agreed to as well as to why a general mechanism like "connection data capability" as part of the overall capability negotiation framework was chosen and agreed to. However, in spite of the document reviews, long completed WGLC, and the external 3GPP dependency, it is obvious from the e-mail thread that more discussion is needed on this, and hence we will have to deal with that before we can progress the document.

Thanks

-- Flemming (MMUSIC co-chair)


On 3/15/13 8:04 AM, Simo.Veikkolainen@nokia.com wrote:

I think this goes all the way back to IETF68, where an agreement was made to use ICE for future address type selection (deprecating ANAT).

 

I couldn’t find a written statement in minutes on ccap being explicitly forbidden to express IP4 and/or IP6 addresses as alternatives – but my thought has been that alternative IP addresses may only be offered with ICE. This was also reflected in by Jean-Francois (http://www.ietf.org/mail-archive/web/mmusic/current/msg07916.html) where he says ” As for proposing IPv4/IPv6 alternatives, ICE deprecates ANAT and is the preferred solution the WG has chosen so far per IETF#68. “             

 

Simo

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of ext mohamed.boucadair@orange.com
Sent: 15. maaliskuuta 2013 8:36
To: Flemming Andreasen; Andrew Allen
Cc: jonathan@vidyo.com; mmusic@ietf.org
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

 

Felmming,

 

If you are looking for something written, you can read the minutes in the Anaheim meeting (In http://tools.ietf.org/wg/mmusic/minutes?item=minutes77.html), you can read the following:

              To conclude the WG chair report, Jean-Francois clarified the
              status of draft-ietf-mmusic-sdp-misc-cap-00 (see the chair's
              slides #9).
              This Internet-Draft was mistakenly accepted as a WG document
              without confirmation on the list.
          
              After a brief recap of the I-D history and scope, several
              comments were made in support of continuing the work as part of
              a WG item as long as the scope does not overlap with ICE for
              IPv4-IPv6 connection address negotiations:
                - Roni Even indicated support for the work and noted that the
                  b parameter was part of the original SDP capability
                  negotiation framework.
                - John Elwell, Gonzalo Camarillo, Jonathan Lennox and Cullen
                  Jennings are in favor of the work item as long as its scope
                  is clarified to not overlap with ICE for IPv4-IPv6 address
                  negotiation.
                - Ingemar Johansson also expressed support for it
               There was strong support for continuing to define a capability
               parameter for b, i and some concerns with the ccap parameter.
               More discussions occurred at the end of the meeting when the
               document was presented, see notes below.
          
               Jean-Francois proposed the next steps:
                - the WG chairs will confirm the interest for a WG item to
                  define additional SDP cap neg parameters (b and i lines)
                - Pending AD approval, the WG item will be chartered
                - Simo V. will re-submit an updated Internet-Draft as an
                  individual submission
                - then the chairs will ask the list if the Working Group
                  supports making Simo's individual submission as the WG
                  draft.
The current discussion shows there is a confusion in the current text and it is worth to be clarified.
Cheers,
Med

 

De : mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] De la part de Flemming Andreasen
Envoyé : jeudi 14 mars 2013 21:39
À : Andrew Allen
Cc : jonathan@vidyo.com; mmusic@ietf.org
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

 

On 3/14/13 3:50 PM, Andrew Allen wrote:


I am not sure if anything is recorded in any minutes but we had an offline discussion to remove the roadblock on this with Jonathan to address his concern that this was a potential alternative to ICE and addressed this with the current text. This text and the reason behind it I think was pointed out on the list during Quebec or shortly after.

Can you find the message or recall who sent it ?

Also, the Quebec meeting was in July 2011. Tracing back we have:

a) The initial (?) individul versions of the draft (2008/2009):     http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap
b) Another individual take on the draft (August 2011+):         http://tools.ietf.org/html/draft-garcia-mmusic-sdp-miscellaneous-caps
c) The intial WG version of the draft (March 2012+):             http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps

The "a)" version did indeed position the draft as an alternative to ICE, however all "b)" and "c)" versions changed this as per the previous discussion.

I'm still looking for anything written anywhere that suggests that the text in "b)" and "c)" does not represent consensus and/or that consensus is that the mechanism MUST always be prohibited from negotiating IP4/IP6 addresses (as opposed to just when ICE is not available).

Thanks

-- Flemming


 

From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Thursday, March 14, 2013 02:45 PM Central Standard Time
To: Stach, Thomas <thomas.stach@siemens-enterprise.com>
Cc: Andrew Allen; jonathan@vidyo.com <jonathan@vidyo.com>; mmusic@ietf.org <mmusic@ietf.org>
Subject: Re: AW: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
 

As to ccap not being an alternative to ICE we are all in agreement on that - the lack of port negotiation alone makes that clear (it simply doesn't work without that).

As to ccap being explicitly forbidden to express IP4 and/or IP6 addresses as alternatives, can somebody please point me to either meeting minutes or mailing list discussion to that effect ? The only thing I have found is the port discussion we had in Taipei, where we agreed not to add a port capability. From http://www.ietf.org/proceedings/82/minutes/mmusic.htm:
<quote>

Miscellaneous Capabilities Negotiation in SDP (Simo Veikkolainen, 10)

=====================================================================

draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt

Simo presented his slides.

Simo explained the need to be able to indicate alternative port numbers, but PSTN media, port number doesn't make sense. The CS draft says use port number 9 (the discard port). We have to put something there because required by SDP syntax. If an RTP stream is offered, then a regular port number should be written instead. The problem arises when both CS and RTP streams are offered at the same time, one as an alternative of the other. Then, the port number makes sense for RTP but not for CS, but still, there is a single place to write the port number in the SDP, so, has to be shared by both alternative media streams.

Possible solutions:

1. Circuit-switched media uses the same port as RTP media even though the port is not really used

2. Extend capneg with a port number capability attribute, restricting its use to cases where ICE cannot be used.

3.  Select anything as a port number and say "do not care on reception".

Jonathan Lennox suggested saying that port numbers not equal 0 have to be ignored.

Hadriel Kaplan asked if middle boxes not supporting this stuff can be broken. The discussion is moved offline.

There are questions on how could be possible to indicate preference for one media stream above the alternative.

Miguel Garcia suggested using port 9 if it works. If not take anything not equal 0. Receiver has to ignore.

In general, there was pushback on the port negotiation approach. The authors should explore a solution along the third option: write the RTP port number in the "m=" line. If CS alternative is chosen, discard the port number on reception.
</quote>


Apart from that, the only thing I'm aware of is the 4 WG versions of this draft which have all said the same about IP4/IP6 and ICE, and again, that text was both WGLC'ed and reviewed by 2 volunteers without any concerns. Where does the alternate understanding come from ?

Thanks

-- Flemming


On 3/14/13 2:16 PM, Stach, Thomas wrote:

This is also my understanding

... although my initially proposed text does not reflect this correctly.

 

Regards
Thomas

 

 

Von: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] Im Auftrag von Andrew Allen
Gesendet: Donnerstag, 14. März 2013 14:10
An: jonathan@vidyo.com; fandreas@cisco.com
Cc: mmusic@ietf.org
Betreff: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt


My understanding also was that we agreed that CCAP was not an alternative to ICE.

 

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: Thursday, March 14, 2013 01:06 PM Central Standard Time
To: Flemming Andreasen <fandreas@cisco.com>
Cc: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>; Andrew Allen; mmusic@ietf.org <mmusic@ietf.org>
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
 

 

On Mar 14, 2013, at 1:43 PM, Flemming Andreasen wrote:



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

 

Hi, Fleming --

 

My understanding of the WG consensus -- and my interpretation of the text in the draft -- was stronger than this: ccap MUST NOT be used for the kinds of alternatives ICE can express, whether or not ICE is actually being used in a particular offer/answer.

 

If we're getting divergent interpretations of this document, we probably do need to update its text.

 

--

Jonathan Lennox
jonathan@vidyo.com


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

 


--------------000806000909070709010205--