Subject: [AVT] FW: New Version Notification for draft-begen-avt-token-for-portmapping-01

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 12 Aug 2010 00:13:04 -0700

We updated the token draft with the proposed text to address the concerns related to CGNs.

Here is the new draft and diff:
https://datatracker.ietf.org/doc/draft-begen-avt-token-for-portmapping/#history 

Co-chairs, could we determine whether WG consensus  is Token or Cookie?

Thanks,
-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, August 12, 2010 10:07 AM
To: Ali C. Begen (abegen)
Cc: Dan Wing (dwing); [email-masked]
Subject: New Version Notification for draft-begen-avt-token-for-portmapping-01 

A new version of I-D, draft-begen-avt-token-for-portmapping-01.txt has been successfully submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-begen-avt-token-for-portmapping
Revision:	 01
Title:		 Token-Based Port Mapping Between Unicast and Multicast RTP Sessions
Creation_date:	 2010-08-12
WG ID:		 Independent Submission
Number_of_pages: 21

Abstract:
This document presents an alternative port mapping solution that
allows RTP receivers to choose their own ports for an auxiliary
unicast session in RTP applications using both unicast and multicast
services (almost) without the need for retrieving pre-authorization.

The IETF Secretariat.

---

From: Roni Even <[email-masked]>
Date: Thu, 12 Aug 2010 16:31:51 +0300

Hi Ali,
I thought that there were other issues raised during the AVT session.

1. The current example shows the portmapping-req as a media level attribute
which may hint that the token is valid only for the specific m-line.
Question: was there a request to allow it to be a session level attribute
make the same token usable for all m-lines?

2. There was a union proposal in which the server may return a token or a
token + port that will look like a cookie. Are we looking at this option?

3. The last comment was about an issuer ID allowing the client to associate
the token with a specific server. I am not sure if needed but was mentioned

Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Thursday, August 12, 2010 10:13 AM
> To: [email-masked]
> Subject: [AVT] FW: New Version Notification for draft-begen-avt-token-
> for-portmapping-01
> 
> A new version of I-D, draft-begen-avt-token-for-portmapping-01.txt has
> been successfully submitted by Ali Begen and posted to the IETF
> repository.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 12 Aug 2010 07:16:56 -0700

Hi Roni,

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, August 12, 2010 4:32 PM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [AVT] FW: New Version Notification fordraft-begen-avt-token-for-portmapping-01
> 
> Hi Ali,

Yeah, I believe Colin brought this up. Yes, we should allow for session level.
 
> token + port that will look like a cookie. Are we looking at this option?

As the authors, we don't think that will be a good approach. And the new text should ease the concerns about the topology related assumptions.
 
> the token with a specific server. I am not sure if needed but was mentioned

I don't think we came up with a strong need for it. 

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 12 Aug 2010 18:31:38 +0300

Ali,
As individual, I am OK with your responses for these three items. As for
session level attribute, you will need to say that it is only for unicast
streams.

As a WG co-chair I brought up all these issues since they are part of the
meeting notes and if we want to accept this document as a WG document
replacing the current one we will need to verify that there are no
objections.

Roni Even 

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Thursday, August 12, 2010 5:17 PM
> To: Roni Even; [email-masked]
> As the authors, we don't think that will be a good approach. And the
> new text should ease the concerns about the topology related
> assumptions.
>