Subject: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes)

From: Flemming Andreasen <[email-masked]>
Date: Fri, 08 Jun 2012 18:37:31 -0400

Hi

As part of the MMUSIC charter we have the following milestone

Sep 2012 	Submit Considerations for using SDP offer/answer with 
middleboxes for BCP

and we have the middleboxes draft

     http://www.ietf.org/id/draft-ietf-mmusic-media-path-middleboxes-04.txt

to address that milestone.

As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns 
with the goal of the document and the potential target as further 
explained in the following e-mail:

     http://www.ietf.org/mail-archive/web/mmusic/current/msg09278.html

A set of (initial) technical comments were also provided by Hadriel in 
the following e-mail:

     http://www.ietf.org/mail-archive/web/mmusic/current/msg08640.html

For now, the chairs would like to focus on the first set of questions 
above, i.e. what is the goal and potential target audience for the 
document and is there still value in pursuing it ?

The chairs would like to poll the group for opinions and interest in 
this. Specific areas to consider:

1) What is the target audience for the document ?

2) Do people believe that the target audience will read and/or care 
about this document at this point ?

3) Should the document be a BCP or Informational ?

Thanks

-- Miguel & Flemming (as chairs)

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 08 Jun 2012 19:09:57 -0400

Some comments (as an individual)

A lot of the SIP and SDP work started out with a somewhat "purist" 
Internet view of the world, where things such as middleboxes were not 
considered. As other standards and industry organizations became 
interested in using SIP and SDP, different architectures were defined 
and some of those arcitectures did include the notion of middleboxes 
(e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view, 
there was, at least initially, not a great deal of knowledge about these 
architectures and what the middleboxes defined by them were doing. 
Conversely, there was (is) also a concern that such middleboxes may 
break end-to-end transparency and hence there was a desire to try and 
alleviate that.

To that effect, it was seen as useful to have a document that could
a) Explain what/how middleboxes might be operating in these architectures
b) Provide guidelines as to how such middleboxes could minimize (ideally 
avoid) impacting end-to-end transparency and/or how protocols could be 
used to try and alleviate any impact such middleboxes might have.

The middleboxes draft is trying to address the above as it relates to 
the media path. The target audience is thus IETF participants that would 
like an overview of how these middleboxes may affect SIP/SDP-signaled 
media streams as well as what can be done to try and overcome that. 
Similarly, the document is targeted at people involved in these "other" 
architecture efforts, with a goal of making it clear how middleboxes may 
affect the operation of SIP/SDP-signaled media streams and hence provide 
some "design principles". This is not unlike some of the NAT work that 
was done in BEHAVE.

It could be argued that these architectures have now been around for so 
long that producing the above document will not make any difference at 
this point. While I have some sympathy for this, I also think we have to 
recognize the importance of documenting what we know and to make that 
readily available for new people that will be working in this space.

In other words, I still believe there is value in pursuing this 
document. As to whether it should be a BCP or Informational, I don't 
have any strong opinions.

Thanks

-- Flemming (as an individual)

On 6/8/12 6:37 PM, Flemming Andreasen wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 25 Jun 2012 10:48:20 +0200

I agree.

Thomas

----------------------------------
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Flemming Andreasen
Sent: Saturday, June 09, 2012 1:10 AM
To: mmusic
Cc: [email-masked]
Subject: Re: [MMUSIC] WG Poll on the middleboxes
draft(draft-ietf-mmusic-media-path-middleboxes)

a) Explain what/how middleboxes might be operating in these
architectures

Thanks 

Hi 

Sep 2012

Submit Considerations for using SDP offer/answer with middleboxes for
BCP

Thanks

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 25 Jun 2012 10:39:28 +0000

+1

Considering that the draft has preliminary recommendations, I think it should be a BCP if we agree on those recommendations.

Muthu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Flemming Andreasen (fandreas)
Sent: Saturday, June 09, 2012 4:40 AM
To: mmusic
Cc: [email-masked]
Subject: Re: [MMUSIC] WG Poll on the middleboxes draft (draft-ietf-mmusic-media-path-middleboxes)

A lot of the SIP and SDP work started out with a somewhat "purist" Internet view of the world, where things such as middleboxes were not considered. As other standards and industry organizations became interested in using SIP and SDP, different architectures were defined and some of those arcitectures did include the notion of middleboxes (e.g. 3GPP IMS and CableLabs PacketCable). From an IETF point of view, there was, at least initially, not a great deal of knowledge about these architectures and what the middleboxes defined by them were doing. Conversely, there was (is) also a concern that such middleboxes may break end-to-end transparency and hence there was a desire to try and alleviate that.

To that effect, it was seen as useful to have a document that could
a) Explain what/how middleboxes might be operating in these architectures
b) Provide guidelines as to how such middleboxes could minimize (ideally avoid) impacting end-to-end transparency and/or how protocols could be used to try and alleviate any impact such middleboxes might have.

The middleboxes draft is trying to address the above as it relates to the media path. The target audience is thus IETF participants that would like an overview of how these middleboxes may affect SIP/SDP-signaled media streams as well as what can be done to try and overcome that. Similarly, the document is targeted at people involved in these "other" architecture efforts, with a goal of making it clear how middleboxes may affect the operation of SIP/SDP-signaled media streams and hence provide some "design principles". This is not unlike some of the NAT work that was done in BEHAVE.

It could be argued that these architectures have now been around for so long that producing the above document will not make any difference at this point. While I have some sympathy for this, I also think we have to recognize the importance of documenting what we know and to make that readily available for new people that will be working in this space.

In other words, I still believe there is value in pursuing this document. As to whether it should be a BCP or Informational, I don't have any strong opinions.

Thanks

Submit Considerations for using SDP offer/answer with middleboxes for BCP

As discussed at IETF 83 (Paris), Hadriel Kaplan raised some concerns with the goal of the document and the potential target as further explained in the following e-mail:

A set of (initial) technical comments were also provided by Hadriel in the following e-mail:

For now, the chairs would like to focus on the first set of questions above, i.e. what is the goal and potential target audience for the document and is there still value in pursuing it ?

The chairs would like to poll the group for opinions and interest in this. Specific areas to consider:

2) Do people believe that the target audience will read and/or care about this document at this point ?

Thanks

mmusic mailing list

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

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 28 Jun 2012 00:30:35 -0400

+1

Gonzalo

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Jun 2012 10:19:46 +0300

Hi Flemming, 

I take a pragmatic view. The document has been worked on in the group for a while, a WGLC had been held, the received last call comments had been incorporated in the meanwhile. 

From there on there are only two routes (IMHO):
a) publish the document through the working group, 
b) the authors submit it to the RFC editor as an independent submission

At this point in time the outcome is not so much different anymore (since the working group had already provided their input). 

The text about the impact of middleboxes on signaling protocols is something worth capturing and the offered guidance seems to be OK. I still think that this writeup will be a useful reference for the work on middleboxes with relationship to security protocols. 

Ciao
Hannes

On Jun 9, 2012, at 2:09 AM, Flemming Andreasen wrote:

>> Sep 2012	Submit Considerations for using SDP offer/answer with middleboxes for BCP