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

From: [email-masked]
Date: Wed, 13 Mar 2013 06:39:20 -0700

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-miscellaneous-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-miscellaneous-caps-04

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

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 15:08:56 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 13. maaliskuuta 2013 15:39
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Abstract:

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 16:20:02 +0100

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 : [email-masked] [mailto:[email-masked]] 
>De la part de [email-masked]
>Envoyé : mercredi 13 mars 2013 16:09
>À : [email-masked]
>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
>
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext [email-masked]
>Subject: [MMUSIC] I-D Action: 
>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>
>
> 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)
>	Filename        : 
>draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt
>	Pages           : 21
>	Date            : 2013-03-13
>
>Abstract:

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 13 Mar 2013 16:57:09 +0000

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: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von [email-masked]
> Gesendet: Mittwoch, 13. März 2013 11:20
> An: [email-masked]; [email-masked]
> Betreff: Re: [MMUSIC] I-D Action:

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 18:39:54 +0100

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 [[email-masked]]
Date d'envoi : mercredi 13 mars 2013 17:57
À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

Regards
Thomas

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 13 Mar 2013 18:17:50 +0000

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  

> Von: [email-masked] 
> [mailto:[email-masked]] 
> Gesendet: Mittwoch, 13. März 2013 13:40
> An: Stach, Thomas; [email-masked]; [email-masked]
> Betreff: RE : [MMUSIC] I-D Action: 
> 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.
> Objet : AW: [MMUSIC] I-D Action: 
> I don't think we should make restrictions in a standards 
> track document in support of proprietary mechanisms.

---

From: Atle Monrad <[email-masked]>
Date: Wed, 13 Mar 2013 18:31:36 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Stach, Thomas
Sent: 13. mars 2013 14:18
To: [email-masked]; [email-masked]; [email-masked]
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 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  

> 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.
> Date d'envoi : mercredi 13 mars 2013 17:57 À : BOUCADAIR Mohamed 
> OLNC/OLN; [email-masked]; [email-masked] Objet : AW: 
> [MMUSIC] I-D Action:
> I don't think we should make restrictions in a standards track 
> document in support of proprietary mechanisms.
> > Von: [email-masked] [mailto:[email-masked]] Im 
> > Auftrag von [email-masked]
> > >De : [email-masked] [mailto:[email-masked]] De la 
> > >part de [email-masked] Envoyé : mercredi 13 mars 2013 
> > >16:09 À : [email-masked] Objet : Re: [MMUSIC] I-D Action:
> > >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
> > >

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 19:32:53 +0100

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

Date d'envoi : mercredi 13 mars 2013 19:17

Mohammed,

Regards
Thomas

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 19:33:47 +0100

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 [[email-masked]]
Date d'envoi : mercredi 13 mars 2013 19:31
À : Stach, Thomas; BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]
Objet : RE: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

All

thanks
/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stach, Thomas
Sent: 13. mars 2013 14:18
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

Regards
Thomas

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 13 Mar 2013 18:35:19 +0000

I agree with Atle

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Atle Monrad
Sent: Wednesday, March 13, 2013 2:32 PM
To: Stach, Thomas; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

All

thanks
/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stach, Thomas
Sent: 13. mars 2013 14:18
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

Regards
Thomas

---

From: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 18:37:17 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

Mohammed,

Regards
Thomas

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

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 19:38:20 +0100

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 [[email-masked]]
Date d'envoi : mercredi 13 mars 2013 19:37
À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

Mohammed,

Regards
Thomas

---

From: Atle Monrad <[email-masked]>
Date: Wed, 13 Mar 2013 18:59:53 +0000

Hi

3GPP use this draft in our centralized services which is a feature since 3GPP Rel-8 as mentioned by Andrew.

My point was to avoid adding new references to new drafts on this topic where 3GPP is waiting for completion.

My personal preference on the sentence is clearly stated below, but should in no way be seen as a showstopper.

cheers
/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 13. mars 2013 14:34
To: Atle Monrad; Stach, Thomas; [email-masked]; [email-masked]
Subject: RE : [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Atle, 

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

All

thanks
/atle

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stach, Thomas
Sent: 13. mars 2013 14:18
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

Regards
Thomas

---

From: Andrew Allen <[email-masked]>
Date: Wed, 13 Mar 2013 19:03:26 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

Cheers,
Med

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

Mohammed,

Regards
Thomas

---

From: <[email-masked]>
Date: Wed, 13 Mar 2013 20:18:33 +0100

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 [[email-masked]]
Date d'envoi : mercredi 13 mars 2013 20:03
À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Andrew

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

Cheers,
Med

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

Mohammed,

Regards
Thomas

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 08:53:06 +0000

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 [email-masked] [mailto:[email-masked]] 
Sent: 13. maaliskuuta 2013 21:19
To: Andrew Allen; [email-masked]; Veikkolainen Simo (Nokia-CTO/Espoo); [email-masked]; [email-masked]
Subject: RE : RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

________________________________________
De : Andrew Allen [[email-masked]] Date d'envoi : mercredi 13 mars 2013 20:03 À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]; [email-masked]; [email-masked] Objet : Re: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Andrew

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

Cheers,
Med

________________________________________
De : Andrew Allen [[email-masked]] Date d'envoi : mercredi 13 mars 2013 19:37 À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked]; [email-masked] Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

________________________________________
De : Stach, Thomas [[email-masked]]
Date d'envoi : mercredi 13 mars 2013 19:17 À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; [email-masked] Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

Regards
Thomas

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 10:05:02 +0100

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

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]]
>Envoyé : jeudi 14 mars 2013 09:53
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked];
>[email-masked]; [email-masked];
>[email-masked]
>Objet : RE: RE : [MMUSIC] RE : I-D Action:
>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
>
>To: Andrew Allen; [email-masked];
>Veikkolainen Simo (Nokia-CTO/Espoo); [email-masked];
>[email-masked]
>Subject: RE : RE : [MMUSIC] RE : I-D Action:
>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 [[email-masked]] Date d'envoi :
>mercredi 13 mars 2013 20:03 À : BOUCADAIR Mohamed OLNC/OLN;
>[email-masked];
>[email-masked]; [email-masked];
>[email-masked] Objet : Re: RE : [MMUSIC] RE : I-D Action:
>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
>
>To: Andrew Allen; [email-masked]
><[email-masked]>;
>[email-masked] <[email-masked]>;
>[email-masked] <[email-masked]>
>Subject: RE : [MMUSIC] RE : I-D Action:
>This was also my understanding but it seems the current text
>opens the door to signal an IPv4 and IPv6 address.
>
>De : Andrew Allen [[email-masked]] Date d'envoi :
>mercredi 13 mars 2013 19:37 À : BOUCADAIR Mohamed OLNC/OLN;
>[email-masked];
>[email-masked]; [email-masked] Objet : Re:
>[MMUSIC] RE : I-D Action:
>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.
>
>
>
>To: Stach, Thomas <[email-masked]>;
>[email-masked] <[email-masked]>;
>[email-masked] <[email-masked]>
>Subject: [MMUSIC] RE : I-D Action:
>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.
>
>Date d'envoi : mercredi 13 mars 2013 19:17 À : BOUCADAIR
>Mohamed OLNC/OLN; [email-masked]; [email-masked]
>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'.
>The relation to other mechanism such as 'altc' needs to be
>treated in hte specification of that mechanism.
>
>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
>
>> >    Connectivity Establishment (ICE) [RFC5245] or [ALTC])
>is used to
>> > select
>> > >A New Internet-Draft is available from the on-line
>Internet-Drafts
>> > >directories.
>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.
>

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 12:57:00 +0000

See below [SV]

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: 14. maaliskuuta 2013 11:05
To: Veikkolainen Simo (Nokia-CTO/Espoo); [email-masked]; [email-masked]; [email-masked]; [email-masked]
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.).

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

Simo

Cheers,
Med

>[email-masked] Objet : RE: RE : [MMUSIC] RE : I-D Action:
>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
>
>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
>
>[email-masked]; [email-masked]; [email-masked] Objet 
>: Re: RE : [MMUSIC] RE : I-D Action:
>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
>
>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.
>
>
>
>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.
>
>Date d'envoi : mercredi 13 mars 2013 19:17 À : BOUCADAIR Mohamed 
>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'.
>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
>
>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.
>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Mar 2013 09:04:01 -0400

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:

>>>> Internet-Drafts directories.

--
Jonathan Lennox
[email-masked]

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 14:10:56 +0100

Re-,

Please see inline.
Cheers,
Med

>Envoyé : jeudi 14 mars 2013 13:57
>To: Veikkolainen Simo (Nokia-CTO/Espoo);
>[email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Subject: RE: RE : [MMUSIC] RE : I-D Action:
>The proposed change is not sufficient. If you want ccap to be
>used  to signal an IPv4 address and an IPv6 alternate one,
> 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.
>

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

>convey an
>capability to use
>specify that
>>> > >From: [email-masked]
>[mailto:[email-masked]] On
>>> > >Behalf Of ext [email-masked]
>confidential
>confidential

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Mar 2013 10:34:32 -0400

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

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 16:19:53 +0100

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.

Cheers,
Med

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

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>

</quote

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

Andrew

----- Original Message -----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

Cheers,
Med

________________________________________
De : Andrew Allen [[email-masked]<mailto:[email-masked]>]
Date d'envoi : mercredi 13 mars 2013 19:37
À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

----- Original Message -----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

________________________________________
De : Stach, Thomas [[email-masked]<mailto:[email-masked]>]
Date d'envoi : mercredi 13 mars 2013 19:17
À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : AW: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Mohammed,

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]]
Gesendet: Mittwoch, 13. März 2013 13:40
An: Stach, Thomas; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: RE : [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Dear Thomas,

Cheers,
Med

________________________________________
De : Stach, Thomas [[email-masked]<mailto:[email-masked]>]
Date d'envoi : mercredi 13 mars 2013 17:57
À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Im Auftrag von [email-masked]<mailto:[email-masked]>
Gesendet: Mittwoch, 13. März 2013 11:20
An: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Simo,

The document says:

NEW:

  Connectivity Establishment (ICE) [RFC5245] or [ALTC]) is
used to select

Thanks.
Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 13 mars 2013 16:09
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hello,

Regards,
Simo

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
On Behalf Of ext [email-masked]<mailto:[email-masked]>
Sent: 13. maaliskuuta 2013 15:39
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] I-D Action:
draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

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

 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

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

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic
.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Mar 2013 11:23:02 -0400

On 3/14/13 11:19 AM, [email-masked] 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:[email-masked]]
>     *Envoyé :* jeudi 14 mars 2013 15:35
>     *À :* Jonathan Lennox; BOUCADAIR Mohamed OLNC/OLN
>     *Cc :* Andrew Allen; [email-masked]
>     *Objet :* Re: [MMUSIC] RE : I-D Action:
>     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 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.
>
>
>     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
>
>>>     From:[email-masked]  [mailto:[email-masked]]
>>>     To: Andrew Allen;[email-masked]  <[email-masked]>;[email-masked]  <[email-masked]>;[email-masked]  <[email-masked]>
>>>     À : BOUCADAIR Mohamed OLNC/OLN;[email-masked];[email-masked];[email-masked]
>>>     From:[email-masked]  [mailto:[email-masked]]
>>>     To: Stach, Thomas<[email-masked]>;[email-masked]  <[email-masked]>;[email-masked]  <[email-masked]>
>>>     À : BOUCADAIR Mohamed OLNC/OLN;[email-masked];[email-masked]
>>>>     Von:[email-masked]
>>>>     An: Stach, Thomas;[email-masked];[email-masked]
>>>>     À : BOUCADAIR Mohamed OLNC/OLN;[email-masked];
>>>>     [email-masked]
>>>>>     Von:[email-masked]  [mailto:[email-masked]]
>>>>>     Im Auftrag [email-masked]
>>>>>     An:[email-masked];[email-masked]
>>>>>>     De :[email-masked]  [mailto:[email-masked]]
>>>>>>     De la part [email-masked]
>>>>>>     À :[email-masked]
>>>>>>     From:[email-masked]  [mailto:[email-masked]]
>>>>>>     On Behalf Of [email-masked]
>>>>>>     To:[email-masked]
>>>>>>     Cc:[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Mar 2013 11:33:18 -0400

My apologies; I was responding to Andrew's request that I review the new text, and I'd lost track of where this draft was in the process.

I have no problem with the original text that was in the WGLC.  I believe that, as written, it doesn't preclude the use of altc.

On Mar 14, 2013, at 11:23 AM, Flemming Andreasen wrote:

On 3/14/13 11:19 AM, [email-masked]<mailto:[email-masked]> wrote:
Dear Flemming,

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

Cc : Andrew Allen; [email-masked]<mailto:[email-masked]>

</quote

</quote>

Thanks

Andrew

----- Original Message -----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

Cheers,
Med

----- Original Message -----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

Mohammed,

Regards
Thomas

-----Ursprüngliche Nachricht-----

Dear Thomas,

Cheers,
Med

Mohammed,

Regards
Thomas

-----Ursprüngliche Nachricht-----

Hi Simo,

The document says:

NEW:

Thanks.
Cheers,
Med

-----Message d'origine-----

Hello,

Regards,
Simo

-----Original Message-----

Abstract:

transport protocols

is embedded

framework to allow

bandwidth

('i=' line for

 each session or media).

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 16:40:15 +0100

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.

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

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

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

Cheers,
Med

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

Thanks

-- Flemming

Cheers,
Med

</quote

</quote>

Thanks

Andrew

----- Original Message -----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

Cheers,
Med

----- Original Message -----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

Mohammed,

Regards
Thomas

-----Ursprüngliche Nachricht-----

Dear Thomas,

Cheers,
Med

Mohammed,

Regards
Thomas

-----Ursprüngliche Nachricht-----

Hi Simo,

The document says:

NEW:

Thanks.
Cheers,
Med

-----Message d'origine-----

Hello,

Regards,
Simo

-----Original Message-----

Abstract:

transport protocols

is embedded

framework to allow

bandwidth

('i=' line for

 each session or media).

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 18:55:18 +0100

Re-,

The answer from Simo is available here: http://www.ietf.org/mail-archive/web/mmusic/current/msg10504.html. It is clear.

None of the answers received in this list, including the editor, have the same interpretation of the text I quoted as you. It is clear there is only no consensus on what the text should say.

Cheers,
Med

________________________________________
De : Flemming Andreasen [[email-masked]]
Date d'envoi : jeudi 14 mars 2013 18:43
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Jonathan Lennox; Andrew Allen; [email-masked]
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

On 3/14/13 11:40 AM, [email-masked]<mailto:[email-masked]> wrote:
Re-,

Correct.

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

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

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

Cheers,
Med

Cc : Jonathan Lennox; Andrew Allen; [email-masked]<mailto:[email-masked]>

Thanks

-- Flemming

Cheers,
Med

</quote

</quote>

Thanks

Andrew

----- Original Message -----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:38 PM Central Standard Time
To: Andrew Allen; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: RE : [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Hi Andrew,

Cheers,
Med

----- Original Message -----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, March 13, 2013 01:32 PM Central Standard Time
To: Stach, Thomas <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Re-,

Cheers,
Med

Mohammed,

Regards
Thomas

-----Ursprüngliche Nachricht-----

Dear Thomas,

Cheers,
Med

Mohammed,

Regards
Thomas

-----Ursprüngliche Nachricht-----

Hi Simo,

The document says:

NEW:

Thanks.
Cheers,
Med

-----Message d'origine-----

Hello,

Regards,
Simo

-----Original Message-----

Abstract:

transport protocols

is embedded

framework to allow

bandwidth

('i=' line for

 each session or media).

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Mar 2013 13:40:51 -0400

On 3/14/13 11:33 AM, Jonathan Lennox wrote:
> My apologies; I was responding to Andrew's request that I review the 
> new text, and I'd lost track of where this draft was in the process.
>
> I have no problem with the original text that was in the WGLC.
Ok - thanks for clarifying.
>  I believe that, as written, it doesn't preclude the use of altc.
>
Agreed.

Thanks

-- 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.
>>>
>>>     2) On January 25, Simo sent an e-mail to the list pointing out
>>>     the port issue and suggesting text to be added
>>>     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
>>>
> [email-masked] <mailto:[email-masked]>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Mar 2013 13:43:22 -0400

On 3/14/13 11:40 AM, [email-masked] 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).

> 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

>     *Envoyé :* jeudi 14 mars 2013 16:23
>     *À :* BOUCADAIR Mohamed OLNC/OLN
>     *Cc :* Jonathan Lennox; Andrew Allen; [email-masked]
>>     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.
>>
>     documents when they are WGLC'ed but still expect their comments to
>     be addressed ~6 months later.
>
>>         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
>>         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
>>         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.
>>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 14 Mar 2013 14:06:24 -0400

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

Correct.

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.

---

From: Andrew Allen <[email-masked]>
Date: Thu, 14 Mar 2013 18:10:29 +0000

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

From: Jonathan Lennox [mailto:[email-masked]]
Sent: Thursday, March 14, 2013 01:06 PM Central Standard Time
To: Flemming Andreasen <[email-masked]>
Cc: [email-masked] <[email-masked]>; Andrew Allen; [email-masked] <[email-masked]>
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Correct.

Hi, Fleming --

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 14 Mar 2013 18:16:54 +0000

This is also my understanding
... although my initially proposed text does not reflect this correctly.

Regards
Thomas

________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Andrew Allen
Gesendet: Donnerstag, 14. März 2013 14:10
An: [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Correct.

Hi, Fleming --

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Mar 2013 15:45:35 -0400

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 
<http://www.ietf.org/id/draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt>

Simo presented hisslides 
<http://www.ietf.org/proceedings/82/slides/mmusic-8.pptx>.

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:
>     *Von:* [email-masked] [mailto:[email-masked]]
>     *Im Auftrag von *Andrew Allen
>     *Gesendet:* Donnerstag, 14. März 2013 14:10
>     *An:* [email-masked]; [email-masked]
>     *Cc:* [email-masked]
>     *Betreff:* Re: [MMUSIC] RE : I-D Action:
>     *From*: Jonathan Lennox [mailto:[email-masked]]
>     *Sent*: Thursday, March 14, 2013 01:06 PM Central Standard Time
>     *To*: Flemming Andreasen <[email-masked]>
>     *Cc*: [email-masked] <[email-masked]>;
>     Andrew Allen; [email-masked] <[email-masked]>
>     *Subject*: Re: [MMUSIC] RE : I-D Action:
>>>     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.
>>>
>>     1) When the IETF Standard Track mechanism ICE is available, ccap
>>     MUST NOT signal an IPv4/IPV6 address alternative.
>>     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.
>
>     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. 
>

---

From: Andrew Allen <[email-masked]>
Date: Thu, 14 Mar 2013 19:50:56 +0000

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.

From: Flemming Andreasen [mailto:[email-masked]]
Sent: Thursday, March 14, 2013 02:45 PM Central Standard Time
To: Stach, Thomas <[email-masked]>
Cc: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
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<http://www.ietf.org/id/draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt>

Simo presented his slides<http://www.ietf.org/proceedings/82/slides/mmusic-8.pptx>.

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

Regards
Thomas

________________________________
Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von Andrew Allen
Gesendet: Donnerstag, 14. März 2013 14:10
An: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

From: Jonathan Lennox [mailto:[email-masked]]
Sent: Thursday, March 14, 2013 01:06 PM Central Standard Time
To: Flemming Andreasen <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; Andrew Allen; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Correct.

Hi, Fleming --

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Mar 2013 16:39:11 -0400

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:[email-masked]]
> *Sent*: Thursday, March 14, 2013 02:45 PM Central Standard Time
> *To*: Stach, Thomas <[email-masked]>
> *Cc*: Andrew Allen; [email-masked] <[email-masked]>; 
> *Subject*: Re: AW: [MMUSIC] RE : I-D Action: 
> 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:
>
> There are questions on how could be possible to indicate preference 
> for one media stream above the alternative.
>
> 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>
>
>
>>     *Cc*: [email-masked]
>>     <[email-masked]>; Andrew Allen; [email-masked]
>>     <[email-masked]>
>>>>     What I understand from the text in the draft is: ccap is
>>>>     allowed to signal an IPv4@ and IPv6@ if ICE is not supported.
>>>>
>>>     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 --
>>
>>     used for the kinds of alternatives ICE can express, whether or
>>     not ICE is actually being used in a particular offer/answer.
>>
>>     protected by the solicitor-client or other applicable
>>     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. 
>>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 15 Mar 2013 05:38:04 +0000

For section 3.1.2, page 9:

What does that sentence actually mean??  What's a "situation" where an existing mechanism *can* be used?

Does it mean 'ccap' MUST NOT be used if ICE is also used - i.e., they cannot both be in an offer?  
Does it mean 'ccap' MUST NOT be used if it's technically possible to accomplish using ICE, even if the device in question doesn't support ICE?

When is it ok to use a ccap containing an IP4 or IP6 address?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 15 Mar 2013 06:11:12 +0000

Sorry, I didn't notice there was a lengthy email chain about this topic.  Ignore my email below.  It appears from the later emails that others were also confused by the wording of that section, but they know what they meant it to say.

Although I still have one simple question: when is it ok to use a 'ccap' attribute containing either an IP4 or IP6 address?

For example, how is this useful:

    m=audio 9 PSTN -
    c=PSTN E164 +15555556666
    a=ccap:1 IN IP4 198.51.100.7
    a=tcap:2 RTP/AVP
    a=omcap:1 0

Since there is no port number being offered for the IPv4 ccap, and the number 9 is being used for PSTN, how would this actually work??

-hadriel

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 07:36:14 +0100

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<http://tools.ietf.org/html?repository=http://tools.ietf.org&draft=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 : [email-masked] [mailto:[email-masked]] De la part de Flemming Andreasen
Envoyé : jeudi 14 mars 2013 21:39
À : Andrew Allen
Cc : [email-masked]; [email-masked]
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

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:[email-masked]]
Sent: Thursday, March 14, 2013 02:45 PM Central Standard Time
To: Stach, Thomas <[email-masked]><mailto:[email-masked]>
Cc: Andrew Allen; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: AW: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Thanks

-- Flemming

Regards
Thomas

Correct.

Hi, Fleming --

---

From: <[email-masked]>
Date: Fri, 15 Mar 2013 12:04:02 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 15. maaliskuuta 2013 8:36
To: Flemming Andreasen; Andrew Allen
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Felmming,

              slides #9).

                  negotiation framework.

                  negotiation.

                  individual submission

                  draft.

Cheers,

Med

Thanks

-- Flemming

Thanks

-- Flemming

Regards
Thomas

Correct.

Hi, Fleming --

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 15 Mar 2013 16:53:45 +0000

That was my understanding as well - that ccap wouldn't be used to perform alternate address family selection.  However the current text doesn't clearly say that, but rather is confusing.  Mostly just because of the exact English words being used, I think.

Regardless, ccap can't really be used for alternate address selection anyway, because it doesn't indicate a port number for the ccap alternate address.  It's technically possible to use the same port number for an IP4 and IP6 interface, of course, but it's not practical for many.

But because ccap doesn't support indicating a port number, it also can't be used to indicate an IP address when the m/c= lines indicate a PSTN circuit, afaict.  Right?

If so, then why does ccap even support indicating an IP address to begin with?  Why isn't it *only* for indicating a PSTN circuit, when the m/c lines indicate an IP4 or IP6 default?  In other words, why not just change the ABNF of ccap to only support a PSTN type; or to never be for 'IP4' nor for 'IP6'.

-hadriel

On Mar 15, 2013, at 8:04 AM, [email-masked] wrote:

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 18 Mar 2013 00:05:22 -0400

> Although I still have one simple question: when is it ok to use a 'ccap' attribute containing either an IP4 or IP6 address?
Based on the thread, that seems to be a discussion that needs to happen.

> Since there is no port number being offered for the IPv4 ccap, and the number 9 is being used for PSTN, how would this actually work??
It wouldn't; you could only do it in the other direction (i.e. start 
with "IN" and then offer "PSTN" as an alternative configuration) - not a 
terribly generic connection data capability.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 17 Mar 2013 23:58:42 -0400

As noted in my e-mail below, the Anaheim discussion was based on the 
original draft-garcia-mmusic-sdp-misc-cap 
<http://tools.ietf.org/html/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

On 3/15/13 8:04 AM, [email-masked] 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:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext [email-masked]
> *Sent:* 15. maaliskuuta 2013 8:36
> *To:* Flemming Andreasen; Andrew Allen
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [MMUSIC] RE : I-D Action: 
> 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:
>
>                status ofdraft-ietf-mmusic-sdp-misc-cap-00  <http://tools.ietf.org/html?repository=http://tools.ietf.org&draft=draft-ietf-mmusic-sdp-misc-cap-00>  (see the chair's
>                slides #9).
>     *De :[email-masked] [mailto:[email-masked]] *De
>     la part de* Flemming Andreasen
>     *Envoyé :* jeudi 14 mars 2013 21:39
>     *À :* Andrew Allen
>     *Cc :* [email-masked]; [email-masked]
>         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.
>
>     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
>
>
>     <mailto:[email-masked]>
>     *Cc*: Andrew Allen; [email-masked] <mailto:[email-masked]>
>     <[email-masked]> <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>     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).
>
>     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
>     <http://www.ietf.org/proceedings/82/minutes/mmusic.htm>:
>     <quote>
>
>     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:
>
>     2. Extend capneg with a port number capability attribute,
>     restricting its use to cases where ICE cannot be used.
>
>     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
>
>
>             *Von:[email-masked]
>             <mailto:[email-masked]>
>             [mailto:[email-masked]] *Im Auftrag von *Andrew Allen
>             *An:* [email-masked] <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>
>             *Cc:* [email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked]>
>             <mailto:[email-masked]>
>             <[email-masked]>
>             <mailto:[email-masked]>; Andrew Allen;
>             [email-masked] <mailto:[email-masked]> <[email-masked]>
>             <mailto:[email-masked]>
>             On 3/14/13 11:40 AM, [email-masked]
>             <mailto:[email-masked]> 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.
>
>             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
>             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.
>
>

---

From: Andrew Allen <[email-masked]>
Date: Tue, 19 Mar 2013 01:03:50 +0000

Flemming

What is the proposed way forward now?

Does this have to go back to the WG and redo WGLC or is this something that can be resolved without that?

IMHO its a matter of getting the wording right. I don't see a problem with continuing to use CCAP for this and having text that puts a prohibition on using this to negotiate alternate IN types because this would duplicate that capability already provided by ICE.

Andrew

From: Flemming Andreasen [mailto:[email-masked]]
Sent: Sunday, March 17, 2013 10:58 PM Central Standard Time
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

As noted in my e-mail below, the Anaheim discussion was based on the original draft-garcia-mmusic-sdp-misc-cap<http://tools.ietf.org/html/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

On 3/15/13 8:04 AM, [email-masked]<mailto:[email-masked]> 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).

Simo

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext [email-masked]<mailto:[email-masked]>
Sent: 15. maaliskuuta 2013 8:36
To: Flemming Andreasen; Andrew Allen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Felmming,

              slides #9).

                  negotiation framework.

                  negotiation.

                  individual submission

                  draft.

Cheers,

Med

________________________________
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Flemming Andreasen
Envoyé : jeudi 14 mars 2013 21:39
À : Andrew Allen
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [MMUSIC] RE : I-D Action: draft-ietf-mmusic-sdp-miscellaneous-caps-04.txt

Thanks

-- Flemming

Thanks

-- Flemming

Regards
Thomas

Correct.

Hi, Fleming --

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 19 Mar 2013 02:24:03 -0400

> that can be resolved without that?
I guess that depends on the discussion and where we end up. At worst, 
we'd redo WGLC on the ccap part - the rest of the document is unaffected.

> IMHO its a matter of getting the wording right. I don't see a problem 
> with continuing to use CCAP for this and having text that puts a 
> prohibition on using this to negotiate alternate IN types because this 
> would duplicate that capability already provided by ICE.
>
I think we are talking about more than just wording changes here, which 
is why I'd like more discussion. We'll start a new thread on it.

Thanks

-- Flemming

> *Sent*: Sunday, March 17, 2013 10:58 PM Central Standard Time
> *To*: [email-masked] <[email-masked]>
> Andrew Allen; [email-masked] <[email-masked]>; [email-masked] 
> <[email-masked]>
> <http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap> 
> document, which did indeed position "ccap" as an alternative to ICE. 
> The 
>> I couldn’t find a written statement in minutes on ccap being 
>> alternatives – but my thought has been that alternative IP addresses 
>> 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
>>
>>