<br><font size=2 face="sans-serif">Greg,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for contributing the great comments.
Responses:</font>
<br>
<br><font size=2 face="sans-serif">9. As I mentioned in my response to
Raul, I do want to watch for "scope creep". I think we
have to keep the scope of the document as tightly focused on VoIP as we
can... or we're going to wind up taking an awfully long time to complete
it. So my concern with the "periphery", as you so aptly
put it, is that we just need to be cautious how much we add in.</font>
<br>
<br><font size=2 face="sans-serif">9a. Yes, I think there's a place for
those *as they pertain to usage by typical VoIP servers*.</font>
<br>
<br><font size=2 face="sans-serif">9b. I'm not sure on this personally.
It would seem that these apps are really using signaling connections
and media connections, and so they would fall under those appropriate sections.
Which is to say that the sections on "Securing Call Control"
and "Securing Media" should probably take into account the use
of those connections by applications.</font>
<br>
<br><font size=2 face="sans-serif">10. I'll confess to not knowing enough
about securing DTMF to really answer this. In my simplistic view,
isn't DTMF transmitted in either the media or signaling stream? And
so if we secure those streams are we not also securing DTMF? Or do
those only secure the *transport* (and confidentiality/integrity) of DTMF
and there is another aspect we need to worry about? </font>
<br>
<br><font size=2 face="sans-serif">In general, I would say that items that
span multiple categories should be *considered* in developing the best
practices for each relevant category. For example, in developing
a best practice for securing call control, we would need to be sure it
allowed the proper sending of DTMF.</font>
<br>
<br><font size=2 face="sans-serif">11. Interesting point. Certainly
"availability" is a security concern and *part* of that relates
to quality assurance. But I don't know how far we want to go down
that road... we want to focus on helping people understand how to have
a *secure* VoIP system, but not necessarily instructing them on how to
have one with *excellent* audio quality. </font>
<br>
<br><font size=2 face="sans-serif">I don't know... what do others think?
How important should we stress quality assurance?</font>
<br>
<br><font size=2 face="sans-serif">Thanks again for contributing the comments,</font>
<br><font size=2 face="sans-serif">Dan<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Greg Scallan" <spider@tellme.com></b></font>
<p><font size=1 face="sans-serif">01/19/2007 08:14 AM</font>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
<dan_york@Mitel.com></font>
<br><font size=1 face="sans-serif"> cc:
<bestpractices@voipsa.org></font>
<br><font size=1 face="sans-serif"> Subject:
RE: [VOIPSA Best Practices] Best Practices
document structure set - next question: are these the appropriate areas?</font></table>
<br>
<br>
<br><font size=2 color=#000080 face="Arial">This list looks pretty exhaustive
in terms of covering all the primary components. Here are some additional
items to contemplate:</font>
<br><font size=2 color=#000080 face="Arial"> </font>
<br><font size=2 color=#000080 face="Arial">9) There are some items on
the periphery we may want to touch upon somewhere since ensuring they are
appropriately secured needs to be contemplated by those building out VoIP
networks. Such as:</font>
<br><font size=2 color=#000080 face="Arial"> </font>
<br><font size=2 color=#000080 face="Arial">a)</font><font size=1 color=#000080 face="Times New Roman">
</font><font size=2 color=#000080 face="Arial">securing
dependent systems and protocols (such as when using DNS as per RFC 3263
or NTP).</font>
<br><font size=2 color=#000080 face="Arial">b)</font><font size=1 color=#000080 face="Times New Roman">
</font><font size=2 color=#000080 face="Arial">Securing
VoIP Applications (such as CCXML or VoiceXML apps that invoke VoIP related
services and manage and have access to VoIP signaling and media data)</font>
<br><font size=2 color=#000080 face="Arial"> </font>
<br><font size=2 color=#000080 face="Arial">10) What about features that
span many of the categories below, such as the multitude of ways to do
DTMF? Should we have separate sections on best practices to transport
DTMF end to end, or talk about it in each section, referring to other ways
of securing it?</font>
<br><font size=2 color=#000080 face="Arial"> </font>
<br><font size=2 color=#000080 face="Arial">11) How about BP for securing
active and passive media quality assurance systems, as these devices play
a critical role for any service oriented network being monitored?</font>
<br><font size=2 color=#000080 face="Arial"> </font>
<br><font size=2 color=#000080 face="Arial">greg</font>
<br>
<br>