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

[<[e-mail]>]

Re-,

Please see inline.
Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]]
>Envoyé : jeudi 14 mars 2013 13:57
>À : 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
>
>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?

Med: No. The text need to be clear and explicit IMHO. It should say it must not be used for that purpose.

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