[Sis-uce] Thoughts?

Scott Burleigh Scott.Burleigh@jpl.nasa.gov
Mon, 12 May 2003 12:50:43 -0700


--=====================_251001370==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi, BOF members.  I have been supposing that the change described in the 
UCE Concept Paper was simple and non-controversial enough to make 
establishment of the SIS UCE Working Group rapid and 
straightforward.  Here's where we test that idea.  There seem to be three 
general points on which we need to reach rough consensus before we propose 
WG formation to the Area Director; please let me know your thoughts on all 
three.

1.      Technical concept.

Is there anything about the technical concept (in the repository at 
<http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-215>http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-215) 
that we need to revise?

Rob Smith doesn't have funding to participate in the BOF, but he has asked 
me to pass this comment along:

"I've just read through your proposed extension to Unacknowledged CFDP to 
counter out-of-order delivery. This looks like a very sensible suggestion 
to me. However, I feel that 'Check Limit' nomenclature is not the best 
description of the (clearly defined) error. 'Check' could describe almost 
any of the CFDP faults, e.g. NAK Limit, Positive Acknowledgement Limit, 
etc. as they all involve some kind of check.

I think this would be clearer with a more descriptive name, like:
a. Transaction Lifetime Limit
b. Reordering Leeway Limit
c. Unacknowledged Extension Limit

Or some permutation of the above."

I personally think "Check Limit" is okay, but please speak up if you disagree.

2.      Charter.

Is there anything about the Charter (same repository) that is 
unreasonable?  In particular, would JPL, GSFC, and ESTEC be prepared to 
provide the resources to support the necessary demonstrations and 
interoperability testing?

3.      Working group chair.

When we propose the new Working Group to the Area Director, we need to 
identify someone who is willing and able to be its Chair.  I will 
volunteer, but if anyone else would like to take this on (or nominate some 
other lucky BOF member), please feel free!

Scott

--=====================_251001370==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Hi, BOF members.&nbsp; I have been supposing that the change described in
the UCE Concept Paper was simple and non-controversial enough to make
establishment of the SIS UCE Working Group rapid and
straightforward.&nbsp; Here's where we test that idea.&nbsp; There seem
to be three general points on which we need to reach rough consensus
before we propose WG formation to the Area Director; please let me know
your thoughts on all three.<br><br>
1.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Technical
concept.<br><br>
Is there anything about the technical concept (in the repository at
<a href="http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-215">http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-215</a>)
that we need to revise?<br><br>
Rob Smith doesn't have funding to participate in the BOF, but he has
asked me to pass this comment along:<br><br>
&quot;I've just read through your proposed extension to Unacknowledged
CFDP to counter out-of-order delivery. This looks like a very sensible
suggestion to me. However, I feel that 'Check Limit' nomenclature is not
the best description of the (clearly defined) error. 'Check' could
describe almost any of the CFDP faults, e.g. NAK Limit, Positive
Acknowledgement Limit, etc. as they all involve some kind of
check.<br><br>
I think this would be clearer with a more descriptive name, like:<br>
a. Transaction Lifetime Limit<br>
b. Reordering Leeway Limit<br>
c. Unacknowledged Extension Limit<br><br>
Or some permutation of the above.&quot;<br><br>
I personally think &quot;Check Limit&quot; is okay, but please speak up
if you disagree.<br><br>
2.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Charter.<br><br>
Is there anything about the Charter (same repository) that is
unreasonable?&nbsp; In particular, would JPL, GSFC, and ESTEC be prepared
to provide the resources to support the necessary demonstrations and
interoperability testing?<br><br>
3.<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Working group
chair.<br><br>
When we propose the new Working Group to the Area Director, we need to
identify someone who is willing and able to be its Chair.&nbsp; I will
volunteer, but if anyone else would like to take this on (or nominate
some other lucky BOF member), please feel free!<br><br>
Scott<br>
</body>
</html>

--=====================_251001370==.ALT--