[Cesg-all] Rick Schnurr's comments re: AOS Pink Sheets
Adrian J. Hooke
adrian.j.hooke@jpl.nasa.gov
Mon, 14 Jul 2003 12:20:32 -0700
--=====================_623742796==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 11:11 AM 7/14/2003, Greg J Kazz wrote:
>Good catch. The 3-bit field, VCDU extension field is optional and I will
>document it as such. Those missions that don't require it will simply set
>these bits to all zeros (same value as when the field was defined as 'spare').
Greg:
1: If the field is optional, how do you know whether a mission is using it
or not? [I hope that you aren't going to say "it's managed"....] Doesn't
this need some in-line protocol to signal whether the optional field is in
use? It would seem that this assignment materially changes the semantics
of the "Signalling Field" and is therefore not in line with the definition
of this field in para. 5.4.9.2.1.1.9a
>As to your second question, high data rate missions that plan to use AOS
>frame retransmission are requesting it. First customer is MRO (Mars Recon.
>Orbiter).
2: Surely Pink Sheets which introduce a material technical change should be
accompanied by a corresponding update to the Green Book that provides the
rationale for the change? Shouldn't you also build the case for why CCSDS
as a whole should approve this change? For instance, if only a limited
number of missions want it, maybe it could be handled as a local matter or
as "Experimental"?
3: Plenty of current "high data rate missions" get along without this
change. If it's coupled to "high data rate missions that plan to use AOS
frame retransmission", then why isn't this change being packaged along with
the ARQ procedures, so that everyone can see the whole technical picture
and the whole rationale?
4. Section 3.2.2 of the CCSDS Restructuring (Volume 2) states:
"At some point in the evolution of a Draft Standard that is intended to
result in a change to mission support infrastructure, at least one hardware
or software prototype (or other implementation) must exist which
demonstrates and exercises all of the options and features of the
specification in an operationally relevant environment, either real or
simulated. This point may be Issue-1, or it may be a later Issue depending
on circumstances, but for most documents the implementation must exist
prior to issuing a "final" Draft Standard. The WG Chair is responsible for
documenting the specific implementation(s) that qualify the specification,
along with reports relevant to their testing, or for justifying why such
implementation is either inappropriate or should otherwise be waived. The
documentation of the qualifying implementation must include clear
statements about its ability to support each of the individual options and
features. "
Where is this point being addressed?
5: Finally, could you perhaps provide the "audit trail" for this change?
Did these Pink Sheets result from an archived discussion on a Space Link
Protocols WG, and if so could you please refer to the list ID? Were they
approved by the SLS Area before being sent out for formal review?
///adrian
---------------------------------------
Adrian J. Hooke
Chairman, CCSDS Engineering Steering Group (CESG)
>>>Date: Fri, 11 Jul 2003 12:49:27 -0400
>>>From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov>
>>>Subject: Re: [Cesg-all] Re: [CMC] RP A3-07 Announcement of
>>>Review Opportunity
>>>To: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>>>
>>>Hi Adrian,
>>>
>>>In reading this spec. it is hard to determine if the new bits are
>>>optional or a mandatory extension. In the first instance the
>>>parenthetical statement sends one to another point in the document for
>>>information on how to extend the field. The description of the field
>>>itself reads as if one must increment the field by one at the appropriate time.
>>>
>>>So I ask the question: Is the intent to require the use of the
>>>extension for future implementations or is it an option for people who
>>>want to use it?
>>>
>>>Second question who wants this change?
>>>
>>>Rick
>>>
>>>At 03:40 PM 7/10/2003, you wrote:
>>>>At 11:38 AM 7/10/2003, ccsds_rapporteur wrote:
>>>>>The following draft CCSDS Recommendation has been placed on line for
>>>>>CCSDS Agency review:
>>>>> CCSDS 701.0-P-3.1. Advanced Orbiting Systems, Networks and Data
>>>>> Links: Architectural Specification.
>>>>> Pink Sheets. April 2003.
>>>>>DOCUMENT DESCRIPTION: This draft update to the Advanced Orbiting
>>>>>Systems, Networks and Data Links: Architectural Specification
>>>>>Recommendation modifies the VCDU Header by converting three of seven
>>>>>spare bits into a new VCDU Counter Extension
>>>>>field. http://www.ccsds.org/review/rpa307/701x0p31.pdf
--=====================_623742796==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<font color="#0000FF">At 11:11 AM 7/14/2003, Greg J Kazz wrote:<br>
<blockquote type=cite class=cite cite>Good catch. The 3-bit field,
VCDU extension field is optional and I will document it as such. Those
missions that don't require it will simply set these bits to all zeros
(same value as when the field was defined as
'spare').</font></blockquote><br>
Greg:<br><br>
1: If the field is optional, how do you know whether a mission is using
it or not? [I hope that you aren't going to say "it's
managed"....] Doesn't this need some in-line protocol to signal
whether the optional field is in use? It would seem that this
assignment materially changes the semantics of the "Signalling
Field" and is therefore not in line with the definition of this
field in para. 5.4.9.2.1.1.9a<br><br>
<blockquote type=cite class=cite cite><font color="#0000FF">As to your
second question, high data rate missions that plan to use AOS frame
retransmission are requesting it. First customer is MRO (Mars Recon.
Orbiter).</font></blockquote><br>
2: Surely Pink Sheets which introduce a material technical change should
be accompanied by a corresponding update to the Green Book that provides
the rationale for the change? Shouldn't you also build the case for why
CCSDS <u>as a whole</u> should approve this change? For instance, if only
a limited number of missions want it, maybe it could be handled as a
local matter or as "Experimental"? <br><br>
3: Plenty of current "high data rate missions" get along
without this change. If it's coupled to "high data rate missions
<u>that plan to use AOS frame retransmission</u>", then why isn't
this change being packaged along with the ARQ procedures, so that
everyone can see the whole technical picture and the whole
rationale?<br><br>
4. Section 3.2.2 of the CCSDS Restructuring (Volume 2) states:
<dl><font face="Arial, Helvetica" color="#000080">
<dd>"At some point in the evolution of a Draft Standard that is
intended to result in a change to mission support infrastructure, at
least one hardware or software prototype (or other implementation) must
exist which demonstrates and exercises all of the options and features of
the specification in an operationally relevant environment, either real
or simulated. This point may be Issue-1, or it may be a later Issue
depending on circumstances, but for most documents the implementation
<u>must </u>exist prior to issuing a "final" Draft Standard.
The WG Chair is responsible for documenting the specific
implementation(s) that qualify the specification, along with reports
relevant to their testing, or for justifying why such implementation is
either inappropriate or should otherwise be waived. The
documentation of the qualifying implementation must include clear
statements about its ability to support each of the individual options
and features. "<br><br>
</font>
</dl>Where is this point being addressed?<br><br>
5: Finally, could you perhaps provide the "audit trail" for
this change? Did these Pink Sheets result from an archived discussion on
a Space Link Protocols WG, and if so could you please refer to the list
ID? Were they approved by the SLS Area before being sent out for formal
review?<br><br>
///adrian<br>
---------------------------------------<br>
Adrian J. Hooke<br>
Chairman, CCSDS Engineering Steering Group (CESG)<br><br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>Date:
Fri, 11 Jul 2003 12:49:27 -0400<br>
From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov><br>
Subject: Re: [Cesg-all] Re: [CMC] RP A3-07 Announcement of Review
Opportunity<br>
To: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br><br>
Hi Adrian,<br><br>
In reading this spec. it is hard to determine if the new bits are
optional or a mandatory extension. In the first instance the
parenthetical statement sends one to another point in the document for
information on how to extend the field. The description of the
field itself reads as if one must increment the field by one at the
appropriate time.<br><br>
So I ask the question: Is the intent to require the use of the
extension for future implementations or is it an option for people who
want to use it?<br><br>
Second question who wants this change?<br><br>
Rick<br><br>
At 03:40 PM 7/10/2003, you wrote:<br>
<blockquote type=cite class=cite cite>At 11:38 AM 7/10/2003,
ccsds_rapporteur wrote:<br>
<blockquote type=cite class=cite cite>The following draft CCSDS
Recommendation has been placed on line for CCSDS Agency review:<br>
CCSDS 701.0-P-3.1. Advanced Orbiting
Systems, Networks and Data Links: Architectural Specification.<br>
Pink Sheets. April 2003.<br>
DOCUMENT DESCRIPTION: This draft update to the Advanced Orbiting
Systems, Networks and Data Links: Architectural Specification
Recommendation modifies the VCDU Header by converting three of seven
spare bits into a new VCDU Counter Extension field.
<a href="http://www.ccsds.org/review/rpa307/701x0p31.pdf" eudora="autourl">http://www.ccsds.org/review/rpa307/701x0p31.pdf</a></blockquote></blockquote></blockquote></blockquote></blockquote><br><br>
<br>
</html>
--=====================_623742796==_.ALT--