Re: [MMUSIC] RE : RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

[<[e-mail]>]

See below [SV]

-----Original Message-----
From: ext [e-mail] [mailto:[e-mail]] 
Sent: 14. maaliskuuta 2013 11:05
To: Veikkolainen Simo (Nokia-CTO/Espoo); [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The proposed change is not sufficient. If you want ccap to be used  to signal an IPv4 address and an IPv6 alternate one,
[SV] That's not what I want.

 the current text is underspecified (e.g, it does not specify how to signal an alternate port for a distinct AF, how to detect a ccap-unaware midllebox, whether multiple sessions are established or only one is allowed, how many ccap lines are allowed, whether ccap line can be present in both O/A, etc.).


But as I understood there is no consensus change then the text should be explicit and say ccap MUST NOT be used to signal an IPv4 address and an IPv6 alternate one.

[SV] The same effect can be achieved by saying that ICE MUST be used, right?

Simo

Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]]
>Envoyé : jeudi 14 mars 2013 09:53
>À : BOUCADAIR Mohamed OLNC/OLN; [e-mail]; 
>[e-mail]; [e-mail]; 
>[e-mail] Objet : RE: RE : [MMUSIC] RE : I-D Action:
>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>There is no change in the consensus, which is that ICE is used to 
>negotiating alternative IP addresses.
>
>I'm also fine with Thomas's proposed text, but just to highlight that 
>ICE is used for IP addresses I would modify a bit:
>
>---
>If an offerer has implemented Interactive Connectivity Establishment 
>(ICE) [RFC5245] and the 'ccap' attribute it MUST use ICE to select 
>between different IP addresses (e.g.  "IP4"
>and "IP6" or different IP addresses within the same IP address family).
>---
>
>Regards,
>Simo
>
>-----Original Message-----
>From: ext [e-mail]
>[mailto:[e-mail]]
>Sent: 13. maaliskuuta 2013 21:19
>To: Andrew Allen; [e-mail];
>Veikkolainen Simo (Nokia-CTO/Espoo); [e-mail]; 
>[e-mail]
>Subject: RE : RE : [MMUSIC] RE : I-D Action:
>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>Re-,
>
>The point is that if the attribute is extended to be able to convey an 
>IPv4 and an alternate IPv6@, then your statement  "
>and is not intended for IPv4 vs IPv6 for which ICE is the IETF defined  
>mechanism." is not valid anymore...If that consensus changed then I'm 
>puzzled why that argument was raised against altc and not ccap?!!
>
>OTOH, if the attribute is extended to cover IPv4/IPv6  then it should 
>be clearly specified. The current text does not say much for that case.
>
>Cheers,
>Med
>
>________________________________________
>De : Andrew Allen [[e-mail]] Date d'envoi :
>mercredi 13 mars 2013 20:03 À : BOUCADAIR Mohamed OLNC/OLN; 
>[e-mail];
>[e-mail]; [e-mail]; [e-mail] Objet 
>: Re: RE : [MMUSIC] RE : I-D Action:
>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>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: [e-mail]
>[mailto:[e-mail]]
>Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
>To: Andrew Allen; [e-mail]
><[e-mail]>;
>[e-mail] <[e-mail]>; 
>[e-mail] <[e-mail]>
>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 [[e-mail]] Date d'envoi :
>mercredi 13 mars 2013 19:37 À : BOUCADAIR Mohamed OLNC/OLN; 
>[e-mail];
>[e-mail]; [e-mail] 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: [e-mail]
>[mailto:[e-mail]]
>Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
>To: Stach, Thomas <[e-mail]>;
>[e-mail] <[e-mail]>; 
>[e-mail] <[e-mail]>
>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 [[e-mail]]
>Date d'envoi : mercredi 13 mars 2013 19:17 À : BOUCADAIR Mohamed 
>OLNC/OLN; [e-mail]; [e-mail] 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: [e-mail]
>> [mailto:[e-mail]]
>> Gesendet: Mittwoch, 13. März 2013 13:40
>> An: Stach, Thomas; [e-mail]; [e-mail]
>> 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 [[e-mail]]
>> Date d'envoi : mercredi 13 mars 2013 17:57 À : BOUCADAIR Mohamed 
>> OLNC/OLN; [e-mail]; [e-mail] 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: [e-mail] [mailto:[e-mail]] Im 
>> > Auftrag von [e-mail]
>> > Gesendet: Mittwoch, 13. März 2013 11:20
>> > An: [e-mail]; [e-mail]
>> > 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 : [e-mail]
>[mailto:[e-mail]] De la
>> > >part de [e-mail] Envoyé : mercredi 13
>mars 2013
>> > >16:09 À : [e-mail] 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: [e-mail] [mailto:[e-mail]] On 
>> > >Behalf Of ext [e-mail]
>> > >Sent: 13. maaliskuuta 2013 15:39
>> > >To: [e-mail]
>> > >Cc: [e-mail]
>> > >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
>> > >[e-mail]
>> > >https://www.ietf.org/mailman/listinfo/mmusic
>> > >_______________________________________________
>> > >mmusic mailing list
>> > >[e-mail]
>> > >https://www.ietf.org/mailman/listinfo/mmusic
>> > >
>> > _______________________________________________
>> > mmusic mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mmusic
>> >
>>
>_______________________________________________
>mmusic mailing list
>[e-mail]
>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.
>