<br><font size=2 face="sans-serif">Greetings</font>
<br>
<br><font size=2 face="sans-serif">Let me weigh in on this one. &nbsp;Any
attempt to &quot;dissallow&quot; &nbsp;alternatives will be ignored. &nbsp;This
is true because CCSDS recommendations are just that, recommendations, and
not requirements.</font>
<br>
<br><font size=2 face="sans-serif">Don</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;James L. Rash&quot;
&lt;James.L.Rash@nasa.gov&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: sis-csi-bounces@mailman.ccsds.org</font>
<p><font size=1 face="sans-serif">04/20/2006 12:23 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">sis-csi@mailman.ccsds.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: [Sis-csi] Green book
thoughts</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3>At 8:05 AM -0700 4/20/06, Scott Burleigh wrote:</font>
<br><font size=3>James L. Rash wrote:</font>
<br><font size=3>Re: [Sis-csi] Green book thoughts</font>
<br><font size=3>At 6:06 PM -0700 4/19/06, Scott Burleigh wrote:</font>
<br><a href=mailto:Lee.Neitzel@EmersonProcess.com><font size=3 color=blue><u>Lee.Neitzel@EmersonProcess.com</u></font></a><font size=3>
wrote:</font>
<br><font size=3>RE: [Sis-csi] Green book thoughts</font>
<br><font size=3 color=#000080 face="Arial">As you know, there are significant
fixed and variable costs associated with design, implementation, testing,
and deployment of each layer protocol.</font>
<br><font size=3>In my mind, this is the key point in this discussion.</font>
<br><font size=3>....</font>
<br><font size=3>So in this architecture document I think we want *not*
to encourage every flight software manager to look at each mission as yet
another opportunity to demonstrate what fools the designers of TCP were.
&nbsp;The architecture needs to support the insertion of alternatives to
TCP where they are needed, but the fewer the better. &nbsp;Suppose we leave
it at that?</font>
<br><font size=3>Scott,</font>
<br>
<br><font size=3>If I understand what you have been saying, it boils down
to the following. &nbsp;We as architects should aim towards saving the
mission community from making costly and/or dumb choices about rolling
their own re-transmission protocols. &nbsp;We should accomplish this by
(a) developing/adopting a small set of re-transmission protocols that will
meet all-but-the-most-usual-mission-needs for the future and (b) disallow
future missions from using any other re-transmission protocols over the
infrastructure we are &quot;architecting&quot;<b>.</b></font>
<br>
<br><font size=3>My apologies if I have misinterpreted your thesis, and
I am happy to be corrected.</font>
<br><font size=3>As Adrian points out, &quot;disallow&quot; isn't quite
the right word here. &nbsp;&quot;Discourage&quot; is better, and more specifically
I would say &quot;discourage&quot; in the sense of providing such stable
and effective functionality in the supported protocols that missions don't
have any sound technical reason to *want* to invent their own. &nbsp;People
will always make poor technical decisions for arguably irrational reasons;
it's not the function of the Space Communications Architecture to prevent
that. &nbsp;The best we can do is address in advance any arguments that
would otherwise have a defensible technical basis.</font>
<br>
<br><font size=3>Scott,</font>
<br>
<br><font size=3>Thanks -- makes sense. &nbsp;It also implies a means for
measuring success: the ratio of the number of missions that adopt the preferred
protocols to the number of missions that don't. &nbsp;But success will
be more likely if mission designers actually have enough relevant information
on which to base decisions. &nbsp;We can provide such information for decision-making
and produce something far more valuable and effective than a bare list
of recommendations.</font>
<br><font size=3><tt>-- <br>
</tt></font>
<br><font size=3><br>
James L. Rash<br>
Building 23, Room E403</font>
<br><font size=3>Code 588 -- Advanced Architectures and Automation Branch</font>
<br><font size=3>NASA Goddard Space Flight Center<br>
Greenbelt, MD &nbsp;20771<br>
301-286-5246 (voice) &nbsp; &nbsp; 301-286-1768 (fax)</font><font size=2><tt>_______________________________________________<br>
Sis-CSI mailing list<br>
Sis-CSI@mailman.ccsds.org<br>
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi<br>
</tt></font>
<br>