RE: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt

["Tom-PT Taylor" <[e-mail]>]

A colleague's question makes me wonder if IPSEC falls into the
connection-oriented category.  How do you specify that a particuular stream
is to run over an IPSEC tunnel?

> -----Original Message-----
> From: David Yon [mailto:[e-mail]]
> Sent: Wednesday, December 13, 2000 7:26 PM
> To: [e-mail]
> Subject: Iterating draft-ietf-mmusic-sdp-tcpmedia-00.txt
> 
> 
> Thanks everyone for the warm reception and feedback at the MMUSIC WG 
> meeting today.  While it is fresh in everyone's mind, I'd 
> like to collect a 
> laundry list of discussion items for the next version of the draft.
> 
> Jonathan suggested that we fold in all the 
> connection-oriented protocols 
> that we currently know about into the draft.  SSL, TLS, RTSP, 
> et al.  While 
> I wish I was an encyclopedia of existing network protocols, I'm not. 
> :-)  So if folks could chime in with their favorite 
> connection-oriented 
> protocols they would like to see listed, that would help me a 
> great deal.
> 
> On that topic, apparently there is an ambiguity as to what is 
> meant by 
> "RTP/AVP-TCP".  If there are still issues to be hammered out 
> on how RTP/AVP 
> is transported over TCP, I would submit that it is not an issue to be 
> addressed by my draft.  On the other hand, correct me if I'm 
> wrong, but I 
> *thought* I was hearing that perhaps there were two competing 
> ways to do 
> it.  If that's the case, it seems like we should either 
> standardize on one 
> approach (elsewhere), or my draft should list two different 
> protocol names 
> (i.e., RTP/AVP-TCP-1 and RTP/AVP-TCP-2 for lack of a better naming 
> covention).  Feedback on this issue is greatly appreciated.
> 
> I didn't hear any dissent on having "direction:both" be the 
> default value, 
> any objection?
> 
> Brian Rosen spoke with me afterward and suggested that the 
> draft might be 
> unnecessarily biased towards TCP, whereas with some minor 
> rewording it 
> might expand in scope to all connection-oriented protocols 
> without any 
> additional complexity.  Brian if you could elaborate on this 
> a bit that 
> would be helpful.  I have a few reservations about it but I'd 
> like to hear 
> again what you are looking for so that I'm fully 
> understanding what you are 
> after.
> 
> Several people pointed out that my firewall example was 
> flawed, at least in 
> the case of the firewall performing N/PAT.  Well, yes.  But I 
> would just 
> like to clarify that the draft, by itself, is not a complete firewall 
> solution nor is it intended to be.  It can, in some cases, help the 
> situation by (a) allowing media endpoints be more firewall 
> friendly, and 
> (b) making it easier to write ALP's as the long-term 
> solution.  But at the 
> end of the day it is a non-goal for this draft to provide a 
> complete answer 
> to the firewall and N/PAT boondoggle.
> 
> Based on the meeting, that's all I can think of for open 
> issues.  If anyone 
> else has comments feel free to elaborate.
> 
> And thanks again to everyone!
> 
> 
> David Yon
> Chief Technical Officer
> Dialout.Net, Inc.
> [e-mail]
> 
>