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

[<[e-mail]>]

Dear Atle, 

To my knowledge, 3GPP never discussed the use of ccap to convey IPv4 and IPv6 addresses. 

Can you please confirm/infirm?

Thanks.
Cheers,
Med
________________________________________
De : Atle Monrad [[e-mail]]
Date d'envoi : mercredi 13 mars 2013 19:31
À : Stach, Thomas; BOUCADAIR Mohamed OLNC/OLN; [e-mail]; [e-mail]
Objet : RE: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

All

I'd like to support not adding any new dependencies to the miscellaneous-caps draft. The proposed new text below seems OK, even thugh I personally like the existing text better.

This draft has been on the 3GPP depenceny list for years, and we need the draft completed.

thanks
/atle


________________________________


Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management
Ericsson


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Stach, Thomas
Sent: 13. mars 2013 14:18
To: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [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