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

[David Yon <[e-mail]>]

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]