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

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

Hi Brian, 

 

In this specific case I don't know. 

 

However, there have been cases in the past were folks claim that a
specific body of work is overtaken by events. 

 

For this specific document that would mean: 

 

1.      There are no middleboxes anymore. 

2.      Nobody uses SIP anymore. 

3.      End-to-end security isn't relevant anymore (and in particular
when considering end-to-end security work that concerns proposals that
use the media path). 

 

Regarding (1): I have no reason to believe that middleboxes will go away
anytime in the near future. 

 

Regarding (2): With RTCWeb SIP may not be used between the end host and
the VSP/ASP but JavaScript instead. We could improve the document to
also take the recent developments in the RTCWeb environment into
consideration since the discussion we have in the document isn't
necessarily specific to SIP but rather to the offer-answer exchange. 

 

Regarding (3): I hope that e2e security isn't something that will go
away either. The approach for media security in RTCWeb is very similar
to what had been done in SIP a few years ago with
http://tools.ietf.org/html/rfc5763 (at least after I quickly looked at
http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-02) 

 

In a nutshell I still believe the document is relevant and none of the
core foundations of the document has changed. What could, however, be
done is to improve the writeup by referencing some of the more recent
work on RTCWEB. 

 

Ciao

Hannes

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of ext Brian Stucker
Sent: Sunday, July 01, 2012 8:21 AM
To: Hannes Tschofenig
Cc: Flemming Andreasen; mmusic;
[e-mail]
Subject: Re: [MMUSIC] WG Poll on the middleboxes
draft(draft-ietf-mmusic-media-path-middleboxes)

 

Why wouldn't the WG simply publish the document and move on?

 

Cheers,

Brian Stucker

On Thu, Jun 28, 2012 at 12:19 AM, Hannes Tschofenig
<[e-mail]> wrote:

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:

> 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:
>> 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)
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>>
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic