review item disposition (rid): red book rid initiation ... documents/navi… · e-mail address:...

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM

AGENCY RID NUMBER:1/8 SUBMITTING ORGANIZATION (Agency, Center): INPE ------------------------------------------------------------------ REVIEWER'S NAME: Gerald Jean Francis Banon CODE: DPI/OBT E-MAIL ADDRESS: [email protected] TELEPHONE: 55 12 3945 6489 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: 2-4 PARAGRAPH NUMBER: first of Section 2.2.4 RID SHORT TITLE: English improvement ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: “Since there are six separate NDM message types, some of which have considerable overlap in structure and/or content, …” To: “Since there are six separate NDM message types, some of which having considerable overlap in structure and/or content, …” ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial _x__ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Rejected at 26-Oct-2009 CCSDS Fall Meeting. The English in the recommended change is not correct. ================================================================== ==================================================================


AGENCY RID NUMBER: 2/8 SUBMITTING ORGANIZATION (Agency, Center): INPE ------------------------------------------------------------------ REVIEWER'S NAME: Gerald Jean Francis Banon CODE: DPI/OBT E-MAIL ADDRESS: [email protected] TELEPHONE: 55 12 3945 6489 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: 3-1 PARAGRAPH NUMBER: second of 3.1.2 RID SHORT TITLE: inappropriate link? ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) The schema names of the NDM/XML schema set available at: http://cwe.ccsds.org/moims/docs/MOIMS-NAV/Schemas are not in conformance with the schemaName description being provided in Section 3.1.2. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial _x__ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Accepted at 26-Oct-2009 CCSDS Fall Meeting. ================================================================== ==================================================================


AGENCY RID NUMBER:3/8 SUBMITTING ORGANIZATION (Agency, Center): INPE ------------------------------------------------------------------ REVIEWER'S NAME: Mauricio Ferreira CODE: CCS E-MAIL ADDRESS: [email protected] TELEPHONE: (55) 12 – 3945-6388 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: viii PARAGRAPH NUMBER: RID SHORT TITLE: type error ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: “ANNEX A NDM/XML SCHEMAS AND EXAMPLES (INFORMATIVE)” To: “ANNEX A EXAMPLE OF NDM/XML SCHEMA INSTANTIATIONS (INFORMATIVE)” ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial _x__ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Accepted at 26-Oct-2009 CCSDS Fall Meeting. ================================================================== ==================================================================


AGENCY RID NUMBER: 4/8 SUBMITTING ORGANIZATION (Agency, Center): INPE ------------------------------------------------------------------ REVIEWER'S NAME: Luciana Sêda Cardoso CODE: DSS/ETE E-MAIL ADDRESS: [email protected] TELEPHONE: 55 12 3945 7286 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: 4-14 PARAGRAPH NUMBER: RID SHORT TITLE: Abbreviations definition ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) The XSLT abbreviation should be defined in the first time it is cited in the text (page 4-14). This same abbreviation should be included in Annex D - Abbreviations and Acronyms. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Accepted at 26-Oct-2009 CCSDS Fall Meeting. ================================================================== ==================================================================


AGENCY RID NUMBER: 5/8 SUBMITTING ORGANIZATION (Agency, Center): INPE ------------------------------------------------------------------ REVIEWER'S NAME: Luciana Sêda Cardoso CODE: DSS/ETE E-MAIL ADDRESS: [email protected] TELEPHONE: 55 12 3945 7286 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: 5-1 PARAGRAPH NUMBER: RID SHORT TITLE: Abbreviations definition ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) The IT abbreviation should be included in the Annex D - Abbreviations and Acronyms because it is cited in the text (e.g., in page 5-1). ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Accepted at 26-Oct-2009 CCSDS Fall Meeting, with revision. Instead of adding "IT" to the list of abbreviations in Annex D, the phrase "Information Technology" was substituted in the document. This is because the acronym was used only once, and the abbreviation itself is not essential to the document. ================================================================== ==================================================================


AGENCY RID NUMBER: 6/8 SUBMITTING ORGANIZATION (Agency, Center): INPE ------------------------------------------------------------------ REVIEWER'S NAME: Luciana Sêda Cardoso CODE: DSS/ETE E-MAIL ADDRESS: [email protected] TELEPHONE: 55 12 3945 7286 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: PARAGRAPH NUMBER: RID SHORT TITLE: Abbreviations definition ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) The term Navigation Data Message is defined with the NDM abbreviation in item 1.1 of page 1.1. For this reason, it would be expected that the NDM abbreviation should also be invoked along the text, thereafter, in place of the term Navigation Data Message. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial _X__ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Accepted at 26-Oct-2009 CCSDS Fall Meeting.

================================================================== ==================================================================


AGENCY RID NUMBER: 7/8 SUBMITTING ORGANIZATION (Agency, Center): INPE ------------------------------------------------------------------ REVIEWER'S NAME: Luciana Sêda Cardoso CODE: DSS/ETE E-MAIL ADDRESS: [email protected] TELEPHONE: 55 12 3945 7286 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: PARAGRAPH NUMBER: RID SHORT TITLE: Abbreviations definition ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) The term Orbit Data Message is defined with the ODM abbreviation in the page 2.1, item 2.1.3. For this reason, it would be expected that the ODM abbreviation should be also used in the text, thereafter, in place of the term Orbit Data Message. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial _X__ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Accepted at 26-Oct-2009 CCSDS Fall Meeting. Also, by symmetry, the same changes were made for the Attitude Data Messages (ADM) and Tracking Data Message (TDM), where applicable.

================================================================== ==================================================================


AGENCY RID NUMBER: 8/8 SUBMITTING ORGANIZATION (Agency, Center): INPE ------------------------------------------------------------------ REVIEWER'S NAME: Luciana Sêda Cardoso CODE: DSS/ETE E-MAIL ADDRESS: [email protected] TELEPHONE: 55 12 3945 7286 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: A-2 PARAGRAPH NUMBER: RID SHORT TITLE: Edition error ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) Remove the word “COMMENT” in the <data> section, after <COMMENT> tag. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial _X__ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Accepted at 26-Oct-2009 CCSDS Fall Meeting. ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-01 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 1-2 PARAGRAPH NUMBER: 1.5.2 RID SHORT TITLE: Definition layout not i.a.w. CCSDS A20.0-Y-2 #3.4.1.7.1 ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: 1.5.2 TERMS In this document, the following definitions apply: CamelCase. A style of capitalization in which the initial characters of concatenated words are capitalized, as in CamelCase. lowerCamelCase. A variant on CamelCase in which the first character of a character string formed from concatenated words is lowercase, as in lowerCamelCase. In the case of a character string consisting of only a single word, only lowercase characters are used. ASCII. A text character set. In this document, ASCII is used generically to refer to the character set defined in reference [B4]. TO: 1.5.2 TERMS For the purpose of this document, the following definitions apply: CamelCase: style of capitalization in which the initial characters of concatenated words are capitalized NOTE - For example: CamelCase. lowerCamelCase: variant on CamelCase in which the first character of a character string formed from concatenated words is lowercase NOTE 1 - For example: lowerCamelCase. NOTE 2 - In the case of a character string consisting of only a single word, only lowercase characters are used. ASCII: text character set specified in ISO/IEC 8859-1:1998 NOTE - ISO/IEC 8859-1:1998 is "8-Bit Single-Byte Coded Graphic Character Sets—Part 1: Latin Alphabet No. 1". ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact

Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1, 2 and 3 below are editorial. 4 is technical. 1. I.A.W. CCSDS A20.0-Y-2, #3.4.1.7.1.b, the introductory sentence for terms shall be: "For the purpose of this document…". 2. I.A.W. the layout in the above document, a colom ":" shall be used between the term and the definition. 3. IAW CCSDS A20.0-Y-2, #3.4.1.7.1.a, the definition shall start with a minor letter, and with no punctuation mark at the end (this applies only to the definition, not to the NOTES). 4. IAW CCSDS A20.0-Y-2, #3.4.1.7.1.a, the definition shall be a sustitute of the term. That implies that: (a) Examples and explanations shall go in separate sentences as NOTES. (b) the definition shall specifically identify the term. A definition like "ASCII: text character set" is not appropriate, because not every character set is ASCII. NOTE that the definition of ASCII makes ISO/IEC 8859-1:1998 a normative reference (See RID ECSS-EG-02). ------------------------------------------------------------------ DISPOSITION: Partially accepted at 26-Oct-2009 CCSDS Fall Meeting, partially rejected. Rejected portions: (a) a period will be used at the end of definitions of terms; (b) "NOTEs" will not be used in the definitions; the examples will be deleted. ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-02 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 1-3 PARAGRAPH NUMBER: 1.6 RID SHORT TITLE: Missing normative reference ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) In accordance with RID ECSS-EG-01, the following normative reference shall be added to 1.6, and removed from Annex B: Information Technology—8-Bit Single-Byte Coded Graphic Character Sets—Part 1: Latin Alphabet No. 1. International Standard, ISO/IEC 8859-1:1998. Geneva: ISO, 1998. Cross-references to it shall be corrected consistently. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: See RID ECSS-EG-001, point 4.b of the supporting analysis. ------------------------------------------------------------------ DISPOSITION: Rejected at 26-Oct-2009 CCSDS Fall Meeting. The underlying documents require ASCII, and are so referenced. This document does not, though the ASCII document is included as an informative reference. ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-03 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 2- to 2-5 PARAGRAPH NUMBER: 2 RID SHORT TITLE: Misuse of the mandatory nomenclature ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: 2.2.2.3 Some of the advantages.. .. .. include: - XML defines standards.. .. .. which the contents of an XML fiel MAY be validated. 2.2.2.4 A few disadvantages.. .. .. are: - Tags.. .. .. - Some values can be specified as either attributes or child elements, so there MAY be disagreement.. .. 2.2.3 JUSTIFICATION FOR USING XML SCHEMA There are several ways.. .. .. In the case of the CCSDS, the CCSDS Management Council (CMC) has indicated that the XML Schema method SHALL be used for the XML validation. .. .. 2.2.4 .JUSTIFICATION FOR INTEGRATED NDM/XML SCHEMA SET There has been.. .. .. This will help to ensure as much consistency and re-use as possible between the message implementations, and SHOULD facilitate the coding of programs that will produce the messages that will be exchanged. It is envisioned that.. .. .. Periodic updates of elements of the schema set MAY be necessary.. .. .. An agency that downloads a copy of the NDM/XML schema set to an operations server under its management also has the option of introducing local modifications to the schema set, though doing so MAY place some limitations on its utility as an interagency exchange medium. 2.3.1 COMMENTS IN NDM/XML INSTANTIATIONS Each of the KVN.. .. .. For example, it MAY become impossible to convert between the XML.. .. .. 2.3.2 TEXT VALUE CASE In some of the KVN format Navigation Data Messages, it is stated that text values MAY be constructed using.. .. .. For example, if the word ‘cat’ is expected for a text value, but case is not significant, then the schema MUST BE coded to allow.. .. .. Thus, in the NDM/XML schema set, text values MUST BE composed of all uppercase or all lowercase.. .. ..

TO: 2.2.2.3 Some of the advantages.. .. .. include: - XML defines standards.. .. .. which the contents of an XML fiel CAN be validated. 2.2.2.4 A few disadvantages.. .. .. are: - Tags.. .. .. - Some values can be specified as either attributes or child elements, so there CAN be disagreement.. .. 2.2.3 JUSTIFICATION FOR USING XML SCHEMA There are several ways.. .. .. In the case of the CCSDS, the CCSDS Management Council (CMC) has indicated that the XML Schema method IS THE MANDATORY ONE TO be used for the XML validation. .. .. 2.2.4 .JUSTIFICATION FOR INTEGRATED NDM/XML SCHEMA SET There has been.. .. .. This will help to ensure as much consistency and re-use as possible between the message implementations, and WILL facilitate the coding of programs that will produce the messages that will be exchanged. It is envisioned that.. .. .. Periodic updates of elements of the schema set CAN be necessary.. .. .. An agency that downloads a copy of the NDM/XML schema set to an operations server under its management also has the option of introducing local modifications to the schema set, though doing so CAN place some limitations on its utility as an interagency exchange medium. 2.3.1 COMMENTS IN NDM/XML INSTANTIATIONS Each of the KVN.. .. .. For example, it CAN become impossible to convert between the XML.. .. .. 2.3.2 TEXT VALUE CASE In some of the KVN format Navigation Data Messages, it is stated that text values CAN be constructed using.. .. .. For example, if the word ‘cat’ is expected for a text value, but case is not significant, then the schema IS coded to allow.. .. .. Thus, in the NDM/XML schema set, text values ARE composed of all uppercase or all lowercase.. .. .. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. IAW #1.5.1 of the present standard, and CCSDS A20.0-Y-2 # 3.4.1.7.2, words "shall", "should" and "may" shall be used exclusively to express specifications. 2. IAW CCSDS A20.0-Y-2 #3.4.3.3.a, specifications shall begin in section 3.

3. CCSDS A20.0-Y-2 # 3.4.2.2 requires that "No requirements or specifications shall be contained in the overview section". ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-04 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 3-1 & 3-2 PARAGRAPH NUMBER: 3.1 RID SHORT TITLE: Misuse of the mandatory nomenclature ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: 3.1.2 The NDM/XML schema set consists.. .. .. A schema containing elements common to more than one Navigation Working Group schema and a schema containing elements that MAY potentially be common across more than one CCSDS application complete the current schema set, yielding a schema set with a total of 11 members.. .. .. NOTES: 3. Special considerations apply to instantiations which MUST COMPLY with the ODM Issue 1.0 Silver Book.. .. .. TO: 3.1.2 The NDM/XML schema set consists.. .. .. A schema containing elements common to more than one Navigation Working Group schema and a schema containing elements that CAN potentially be common across more than one CCSDS application complete the current schema set, yielding a schema set with a total of 11 members (SEE TABLE 3-1).. .. .. NOTES: 3. Special considerations apply to instantiations which COMPLIANCE WITH the ODM Issue 1.0 Silver Book IS MANDATORY.. .. .. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS:

1. IAW #1.5.1 of the present standard, and CCSDS A20.0-Y-2 # 3.4.1.7.2, words "shall", "should" and "may" shall be used exclusively to express specifications. 2. CCSDS A20.0-Y-2 # 3.4.2.2 requires that "No requirements or specifications shall be contained in the overview section". 3. CCSDS A20.0-Y-2 # 3.4.2.3.d specifies that the header "Overview" is used for the title of a non-normative section, "used only to introduce a set of related subsections". ------------------------------------------------------------------ DISPOSITION: ================================================================== ================================================================== Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer).

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-05 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 3-2 PARAGRAPH NUMBER: 3.2 RID SHORT TITLE: Requirements not individually identified. ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: 3.2 BASIC SCHEMA STRUCTURE Each constituent Navigation Data Message (AEM, APM, OEM, OMM, OPM, TDM) shall consist of a <header> and a <body>. Additionally, the body shall consist of one or more <segment> constructs, depending upon the message type. Each <segment> shall consist of a <metadata>/<data> pair. TO: 3.2 NAVIGATION DATA MESSAGE 3.2.1 GENERAL A Navigation Data Message shall be one of the followings: a) An Attitude Parameter Message (APM), as specified in Reference [1], section XXX. b) An Attitude Ephemeris Message (AEM), as specified in Reference [1], section XXX. c) An Orbit Parameter Message (OPM), as specified in Reference [2], section XXX. d) An Orbit Mean Elements Message (OMM), as specified in Reference [2], section XXX. e) An Orbit Ephemeris Message (OEM), as specified in Reference [2], section XXX. f) A Tracking Data Message (TDM), as specified in Reference [3], section XXX. g) A combination of 3.2.1 a) to f), as specified in 3.14. 3.2.2 NDM BASIC SCHEMA STRUCTURE a) Each constituent Navigation Data Message shall consist of a <header> and a <body>. b) The body of a NDM shall consist of one or more <segment> constructs, depending upon the message type. c) Each <segment> of the body of a NDM shall consist of a <metadata>/<data> pair. ------------------------------------------------------------------

CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. The fact that a NDM is necessarily one of (AEM, APM, OEM, OMM, OPM, TDM) is sugested several times, and explicitely stated only in the non-normative part. To make it mandatory, a specification (with "shall") shall be stated. Additionally, this specification can serve to introduce CCSDS 502, 503 and 504 as mandatory (i.e. Normative references). In the draft, since they are not called from any specification, they are not referenced as normative references iaw CCSDS A20.0-Y-2 #3.4.1.8.a)1). 2. Requirements shall be individually identified IAW CCSDS A20.0-Y-2 3.4.3.3 b). ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-06 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 3-3 PARAGRAPH NUMBER: 3.3 & 3.4 RID SHORT TITLE: Requirements are not self-standing, and mixed with informative material ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: 3.3 SUBSTRUCTURE 1: apm, omm, opm In Substructure 1, used for messages that describe a single state (APM, OMM, OPM), the body shall consist of a single segment (in essence, the segment tag is not strictly necessary; however, it is present for structural symmetry with Substructure 2 in the ‘body’ of the message). 3.4 SUBSTRUCTURE 2: aem, oem, tdm In Substructure 2, used for messages that describe multiple states or tracking data types (AEM, OEM, and the TDM), the body shall consist of one or more segments; at least one segment is required. The alternation of associated metadata and data sections is the structural element that necessitates the notion of the segment. TO: 3.3 SUBSTRUCTURE 1: apm, omm, opm a) Substructure 1 shall be used for APM, OMM and OPM. b) In Substructure 1 the body shall conform to Figure 3-1. NOTE - Substructure 1 consists of a single segment. In essence, the segment tag is not strictly necessary; however, it is present for structural symmetry with Substructure 2 in the ‘body’ of the message. 3.4 SUBSTRUCTURE 2: aem, oem, tdm a) Substructure 2 shall be used for AEM, OEM and TDM. b) In Substructure 2, the body shall conform to Figure 3-2. NOTE - Substructure 2 consists of one or more segments. At least one segment is required. The alternation of associated metadata and data sections is the structural element that necessitates the notion of the segment. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to

render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. Requirements shall be complete. That means that even put out of context (e.g. without their title), they shall not modify their meaning. This will help in importing them into a RMT (requirment management tool, as DOORS). 2. Requirements and explanation/description shall be clearly separated in different clauses, or using NOTES, as specified in CCSDS A20.0-Y-2 # 3.4.33 a) and d). ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-07 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 3-4 PARAGRAPH NUMBER: 3.5 RID SHORT TITLE: Specifications not individually identified, and vague references. ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM (See original) TO 3.5 NDM/XML TAGS 3.5.1 GENERAL a) Within the structure and substructure described in 3.3 and 3.4, the individual tags specific to the various message types shall be defined. NOTE - References [1], [2], and [3] define the contents of the specific tags. This subsection describes the XML tag names. b) With exceptions specified in xxxxx, the XML tag names shall be identical to the keywords specified in Reference [1] section XXX, [Reference [2] section XXX and Reference [3] section XXX. 3.5.2 NDM/XML TAG CORRESPONDING STRICTLY TO A KVM KEYWORD If an NDM/XML tag corresponds strictly to a KVM as specified in [Reference [2] section XXX, Reference [3] section XXX and Reference [1] section XXX, it shall be all uppercase. . 3.5.3 NDM/XML TAG NOT CORRESPONDING STRICTLY TO A KVM KEYWORD a) A NDM/XML tag may not correspond strictly with a KVM keyword as specified in Reference [1] section XXX, Reference [2] section XXX and Reference [3] section XXX, only in the fllowing three cases: : 1) the ‘CCSDS_xxx_VERS’ keyword that is present in each document; 2) keywords associated with rotations in the ADM; and 3) keywords associated with user defined parameters in the ODM. b) In cases specified in 3.5.3.a) 1) and 2), the KVN keywords shall appear as XML attributes rather than as XML elements. c) In case 3.5.3.a)3), the KVN keywords shall appear as a combination of XML elements and attributes. NOTE - The details of these special cases are described in section 4 of this document, which contains instructions necessary to code instantiations of the specific messages.

d) NDM/XML keywords that do not correspond directly to a KVN keyword ispecified in Reference [1] section XXX, Reference [2] section XXX and Reference [3] section XXX shall be in ‘lowerCamelCase’ NOTE - For example, <header>, <segment>, etc.. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. Specifications are not individually identified, as required by CCSDS A20.0-Y-2 # 3.4.3.3.b) and 3.4.3.1.1. 2. Internal references are vague ("described above"). 3. External references shall be precise, specifying the name of the document and the referred section, as specified in CCSDS A20.0-Y-2 # 4.3.7.1. ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-08 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 3-5 PARAGRAPH NUMBER: 3.6 RID SHORT TITLE: Specifications not individually identified. ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: 3.6 NDM/XML TEXT VALUES Text values in NDM/XML instantiations (i.e., the values between the begin and end tags), shall consist of either all uppercase or all lowercase characters; an exception is made for values between the <COMMENT> and </COMMENT> tags, which may be in any case desired by the user. Otherwise, mixing of uppercase and lowercase characters is prohibited. TO: 3.6 NDM/XML TEXT VALUES a) Except in the case specified in 3.6 b), text values in NDM/XML instantiations (i.e., the values between the begin and end tags), shall consist of either all uppercase or all lowercase characters. b) Values between the <COMMENT> and </COMMENT> tags may be in any case. NOTE - Otherwise, mixing of uppercase and lowercase characters is prohibited. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. Specifications are not individually identified, as required by CCSDS A20.0-Y-2 # 3.4.3.3.b) and 3.4.3.1.1.

------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-09 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4.1 PARAGRAPH NUMBER: 4-2 RID SHORT TITLE: Duplication of specification ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: 4.2 XML VERSION The first line in the instantiation shall specify the XML version: <?xml version="1.0" encoding="UTF-8"?> This line must appear on the first line of each instantiation, exactly as shown. TO: 4.2 XML VERSION a) The first line of each instantiation shall specify the XML version, exactly as follows: <?xml version="1.0" encoding="UTF-8"?> ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: the 3rd line of the original draft is a repetition of the specification stated in the 2 previous ones. ------------------------------------------------------------------ DISPOSITION: Accepted at 26-Oct-2009 CCSDS Fall Meeting. ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-10 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-1 & 4-2 PARAGRAPH NUMBER: 4.3 RID SHORT TITLE: Mandatory nomenclature, individial identification of specifications and mixture with background mate ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.3.1 GENERAL a) Each instantiation shall have a ‘root element tag’ that identifies the message type and the information specific to the NDM/XML NOTE - Example of this information is where to find the applicable schema, required attributes, etc. b) The names for a root element tags in an NDM/XML instantiation shall be one of the names in Table 4-1. 4.3.2 NAMESPACES The XML Schema Instance namespace must appear in the root element tag of all NDM/XML instantiations, exactly as shown: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 4.3.3 SCHEMA LOCATION a) The NDM/XML schema shall conform to the standard NDM/XML schema (IS THIS TRUE?. If so, it shall be stated. If not, remove this specification and put the NOTE as NOTE 1 below next specification). NOTE - The standard NDM/XML schema set is located on the CCSDS Web site. b) In the instantiation, in order to validate against the CCSDS Web-based copy, the xsi:noNamespaceSchemaLocation attribute should be coded as follows: xsi:noNamespaceSchemaLocation="http://cwe.ccsds.org/moims/docs/MOIMSNAV/ Schemas/ndmxml-1.0-master.xsd" NOTE - The value associated with the xsi:noNamespaceSchemaLocation attribute shown above is too long to appear on a single line in this document. The value is provided to be entered as a single string of non-blank characters, with no line breaks. c) For use in a local operations environment, the schema set may be downloaded from the CCSDS Web site to a local server that meets local requirements for operations robustness.

d) If a local version is used, the value associated with the xsi:noNamespaceSchemaLocation attribute must be changed to a URL that is accessible to the local server. 4.3.4 NDM/XML ATTRIBUTES IN THE ROOT ELEMENT TAG a) The following two attributes shall be provided in the root element tag of an NDM/XML single message instantiation: 1) the CCSDS_xxx_VERS keyword (that is also part of the standard KVN header) as specified in 4.3.4.b), and 2) the Blue Book version number, as specified in 4.3.4.c). b) The CCSDS_xxx_VERS keyword shall be supplied via the ‘id’ attribute of the root element tag NOTE - xxx = AEM, APM, etc. c) The version number of the Blue Book to which the schema applies shall be supplied via the ‘version’ attribute. NOTE 1 - For example: id="CCSDS_TDM_VERS" version="1.0" NOTE 2 - The following example root element tag for an OPM instantiation combines all the directions in the preceding several subsections: <?xml version="1.0" encoding="UTF-8"?> <opm xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://cwe.ccsds.org/moims/docs/MOIMS- NAV/Schemas/ndmxml-1.0-master.xsd" id="CCSDS_OPM_VERS" version="2.0"> ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. Specifications are not individually identified, as required by CCSDS A20.0-Y-2 # 3.4.3.3.b) and 3.4.3.1.1 2. Requirements and explanation/description shall be clearly separated in different clauses, or using NOTES, as specified in CCSDS A20.0-Y-2 # 3.4.33 a) and d). 3. "must" shall be used only in binding specifications. "If it is so desired" makes the specification optional. 4. "Should", which states a (desirable) specification, shall not appear in a NOTE, which is for explanatory material ONLY. See CCSDS A20.0-Y-2 #3.4.1.7.2 and 3.4.3.3.d. 5. "that are required" is not permitted in CCSDS for a specification. "Shall" or "must" shall be used instead. 6. The example in 4.3.5 has been put in a NOTE for consistency with other parts of the document (e.g. 4.4). ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-11 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-3 PARAGRAPH NUMBER: 4.4 RID SHORT TITLE: Mandatory nomenclature. ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.4 THE STANDARD NDM/XML HEADER SECTION a) The NDMs header section shall use a <header></header> tag pair. b). After the <header> tag the message may have any number of <COMMENT></COMMENT> tag pairs. c) The standard NDM header shall contain the <CREATION_DATE> </CREATION_DATE>and the <ORIGINATOR></ORIGINATOR> tag pairs. NOTE 1 - The rules for these keywords are specified in references [1], [2], and [3]. NOTE 2 - An example od a header section is the following: <header> <COMMENT>This is the common NDM/XML header</COMMENT> <COMMENT>I can put as many comments here as I want, including none.</COMMENT> <CREATION_DATE>2004-281T17:26:06</CREATION_DATE> <ORIGINATOR>AGENCY-X</ORIGINATOR> </header> ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. For binding sopecifications, "shall" or "must" shall be used. 2. Examples shall be separated from requirments, e.g. included in NOTES.

------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-12 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-3 PARAGRAPH NUMBER: 4.5 RID SHORT TITLE: Individual identification of requirements and not self standing specifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.5 THE NDM BODY SECTION 4.5.1 GENERAL a) After coding the <header>, the instantiation must include a <body></body> tag pair. b) Inside the <body></body> tag pair must appear at least one <segment></segment> tag pair. c) Each segment must be made up of one or more <metadata></metadata> and <data></data> tag pairs. 4.5.2 THE NDM METADATA SECTION a) All NDMs must have a metadata section. b) The metadata section shall be set off the by the <metadata></metadata> tag combination. c) Between the <metadata> and </metadata> tags, the keywords shall be the same as those in the metadata sections in the reference documents (reference [1], [2], and [3]), with exceptions specified in 4.6 to 4.12. 4.5.3 THE NDM DATA SECTION a) All NDMs must have a data section. b) The data section shall: 1) follow the metadata section and 2) be set off the by the <data></data> tag combination. c) Between the <data> and </data> tags, the keywords shall be the same as those in the data sections in the reference documents (references [1], [2], and [3]), with exceptions specified in 4.6 to 4.12. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not

corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. Specifications are not individually identified, as required by CCSDS A20.0-Y-2 # 3.4.3.3.b) and 3.4.3.1.1 ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-13 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-4 to 4.7 PARAGRAPH NUMBER: 4.6 RID SHORT TITLE: Specifications not individually identified, and mixed with clarifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.6 CREATING AN AEM INSTANTIATION 4.6.1 OVERVIEW Figures A-1 and A-2 of Annex A show examples of AEM instantiations. 4.6.2 THE <aem> TAG a) An AEM instantiation shall be delimited with the <aem></aem> root element tags using the standard attributes specified in 4.3. b) The final attributes of the <aem> tag shall be ‘id’ and ‘version’. c) The ‘id’ attribute shall be ‘id="CCSDS_AEM_VERS"’. d) The ‘version’ attribute for the version of the AEM described in Reference [1], section XXX, shall be ‘version="1.0"’. 4.6.3 THE <aem> HEADER The standard NDM header shall follow the <aem> tag. NOTE - See 4.4. 4.6.4 THE <aem> BODY 4.6.4.1 GENERAL a) The AEM <body> shall consist of one or more <segment> constructs NOTE: See figure 3-2. b) Each <segment> shall consist of a <metadata> section and a <data> section. c) The keywords in the <metadata> and <data> sections shall be those specified in reference Reference [1], section XXX. c) Between the <data> and </data> tags, the keywords shall be the same as those in the data sections in Reference [1], section XXX. d)Tags for keywords specified in Reference [1], section XXX shall be all uppercase as in Reference [1]. NOTE: In addition to the AEM keywords specified in reference [1], there are several special tags associated with the AEM body as described in the subsections 4.6.4.2 to 4.6.4.4.

4.6.4.2 THE <attitudeState> TAG a) The <attitudeState> tag shall be used to encapsulate the keywords associated with the structure of one of the attitude ephemeris data line types. b) The NDM/XML tags defined in Table 4-1 shall be use within the <attitudeState> structure: [HERE TABLE 4-1 (with no caption in the draft)] c) Between the begin tag and end tag, the user shall place the values required by the specific ephemeris data line type as specified in Reference [1], section XXXX NOTE - For example, between <quaternionState> and </quaternionState>. d) In the XML representation of the AEM, the components of the ephemeris data line must be represented with the same keywords (i.e., a tag) as those defined for the same construct in the APM. NOTE - In the KVN representations of the ephemeris data lines, keywords are not used. Rather, the components of the ephemeris data line appear in an order defined by the specific ephemeris data line type. 4.6.4.3 EXAMPLES OF THE USE OF QUATERNION TAGS IN THE AEM The XML representations.. .. .. As in the KVN representation of the quaternion, the tags for the individual components of the quaternion (Q1, Q2, Q3, QC) CAN be coded .. .. ... Here is an example AEM quaternion for a ‘QUATERNION’ ephemeris data line: .. .. .. Here is an example AEM quaternion for a ‘QUATERNION/DERIVATIVE’ ephemeris data line: .. .. .. Here is an example AEM quaternion for a ‘QUATERNION/RATE’ ephemeris data line: .. .. .. 4.6.4.4 ROTATION TAGS IN THE AEM a) The rotation constructs shall be used to encapsulate the keywords associated with the structure of one of the rotation sequences. NOTE - The <aem> is notable in that there are XML attributes used to convey the characteristics of rotations instead of XML elements. The AEM includes a number of rotation-related constructs that are necessitated by the fact that attitude rotations are not of one type. The rotation combinations are complicated by the fact that some rotation sequences are specified with more than one rotation about the same axis (e.g., a ‘131’ rotation, in which the first rotation is about the x-axis, second about the z-axis, and the final rotation again about the x-axis). Some <attitudeState> entries include angles only, or rates only, or both angles and rates. b) The NDM/XML tags in Table 4-2 shall be used within the rotation structure: [HERE TABLE 4-2 (with no caption in the original draft)] c) The <rotationAngles> and <rotationRates> elements shall be composed of three tags: <rotation1>, <rotation2>, and <rotation3>. d) Tags <rotationi> (i=1,2,3) shall describe angles or rates, as follows: 1) For angles, (i) The attributes are ‘angle=’ and ‘units="deg"’, where the ‘angle’ attribute is required and the ‘units’ attribute is optional. (ii) The choices for ‘angle’ are ‘X_ANGLE’, ‘Y_ANGLE’, ‘Z_ANGLE’. NOTE 1 - These are the keywords from the KVN AEM.

NOTE 2 - For example the following shows rotation angles for a 321 rotation sequence: .. .. .. 2) For rates, (i) the attributes are ‘rate=’ and ‘units="deg/s"’, where the ‘rate’ attribute is required and the ‘units’ attribute is optional. (ii) The choices for ‘rate’ are ‘X_RATE’, ‘Y_RATE’, ‘Z_RATE’. NOTE 1 - These are the keywords from the KVN AEM. NOTE 2 - For example the following shows rotation rates for a 321 rotation sequence: .. .. .. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. NOTES should be NOTES to specifications, not to titles. To avoid self-standing notes, section 4.6.1 OVERVIEW is porposed. 2. Specifications shall be individually identified (See CCSDS A20.0-Y-2 # 3.4.3.3 and 4.2.3.1.1.) 3. For easy use in contracts, references shall be made to the particular section referred. 4. Explanations/clarifications have been put out of the specifications, as NOTES (as required by CCSDS A20.0-Y-2 # 3.4.3.3 d) 1)). 5. Binding specification shall use "shall" or "must". Statements as "The rules are the same than.. " are not binding (and therefore could be ignored). ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-14 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-8 / 4-11 PARAGRAPH NUMBER: 4.7 RID SHORT TITLE: Specifications not individually identified, and mixed with clarifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM (See original) TO: 4.7 CREATING AN APM INSTANTIATION 4.7.1 OVERVIEW Figure A-3 of Annex A presents an example APM instantiation. 4.7.2 THE <apm> TAG a) An APM instantiation shall be delimited by the <apm></apm> root element tags using the standard attributes specified in 4.3. b) The final attributes of the <apm> tag shall be ‘id’ and ‘version’. c) The ‘id’ attribute shall be ‘id="CCSDS_APM_VERS"’. d) The ‘version’ attribute for the version of the APM described in Reference [1] section XXXX, shall be ‘version="1.0"’. 4.7.3 THE <apm> HEADER The standard NDM header shall follow the <apm> tag. NOTE - See 4.4. 4.7.3 THE <apm> BODY 4.7.4.1 GENERAL a) The APM <body> shall consist of a single <segment>, NOTE - See figure 3-1. b) The segment of an APM <body> shall consist of a <metadata> section and a <data> section. c) The keywords in the <metadata> and <data> sections shall be those specified in Reference [1], section XXX. d) Between the <data> and </data> tags, the keywords shall be the same as those in the data sections in Reference [1], section XXX. e) Tags for keywords specified in reference [1] shall be all uppercase as Reference [1], section XXX. NOTE - In addition to the APM keywords specified in reference [1], there are several special tags associated with the APM body as described in the subsections 4.7.4.2 to 4.7.4.5..

4.7.4.2 SPECIAL <apm> TAGS a. The information content in the APM is separated into logical blocks, as specified in Reference [1] section XXXX. b) To encapsulate the information in the logical blocks specified in 4.7.3.2.a), the NDM/XML tags defined in Table 4-3 shall be used. [HERE TABLE 4-3 (with no caption in the original draft)] c) Between the begin tag and end tag, the user must place the keywords required by the specific logical block as specified in Reference [1], section XXXX. NOTE 1: E.g., between <spacecraftParameters> and </spacecraftParameters>. NOTE 2: The Quaternion logical block has two primary NDM/XML tags associated with it: <quaternionState> and <quaternionRate>; within the <quaternionState> block there is a <quaternion> tag that contains the components of the quaternion itself. 4.7.4.3 EXAMPLES OF THE USE OF QUATERNION TAGS IN THE APM The XML representations of quaternions.. .. .. As in the KVN representation of the quaternion, the tags for the individual components of the quaternion (Q1, Q2, Q3, QC) CAN be coded.. .. .. Here is an example APM quaternion construct: .. .. .. Here is an example APM quaternion construct with the optional derivative: .. .. .. 4.7.4.4 ROTATION TAGS IN THE APM a) The rotation constructs shall be used to encapsulate the keywords associated with the structure of one of the rotation sequences. NOTE - The APM includes two rotation-related constructs that are used in conjunction with the <eulerElementsThree> tag. The rotation combinations are complicated by the fact that some rotation sequences are specified with more than one rotation about the same axis (e.g., a ‘131’ rotation, in which the first rotation is about the x-axis, second about the z-axis, and the final rotation again about the x-axis). b) The NDM/XML tags specified in Table 4-4 shall be used within the rotation structure: [HERE TABLE 4-4 (with no caption in the original draft) c) As in the KVN APM, the following may be specified: 1) angles without rates, 2) rates without angles, or 3) both angles and rates. d) The <rotationAngles> and <rotationRates> elements shall be composed of three tags: <rotation1>, <rotation2>, and <rotation3>. e) Tags <rotationi> (i=1,2,3) shall describe angles or rates, as follows: 1) For angles, (i) the attributes are ‘angle=’ and ‘units="deg"’, where the ‘angle’ attribute is required and the ‘units’ attribute is optional. (ii) The choices for ‘angle’ are ‘X_ANGLE’, ‘Y_ANGLE’, ‘Z_ANGLE’. NOTE 1 - These are the keywords from the KVN APM. NOTE 2 - For example the following shows rotation angles for a 321 rotation sequence: .. .. .. 2) For rates, (i) the attributes are ‘rate=’ and ‘units="deg/s"’, where the ‘rate’ attribute is required and the ‘units’ attribute is optional.

(ii) The choices for ‘rate’ are ‘X_RATE’, ‘Y_RATE’, ‘Z_RATE’. NOTE 1 - These are the keywords from the KVN APM. NOTE 2 - The ‘value’ is a double precision number. For example the following shows rotation rates for a 321 rotation sequence: .. .. .. 4.7.4.5 UNITS IN THE NDM/XML APM a) Units may be specified for the NDM/XML APM keywords tags in Table 4-5. [HERE TABLE 4-5 (without caption in the original draft)] b) If units are specified for NDM/XML APM keywords, these units shall match those defined in Reference [1], section XXXX. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. NOTES should be NOTES to specifications, not to titles. To avoid self-standing notes, section 4.7.1 OVERVIEW is porposed. 2. Specifications shall be individually identified (See CCSDS A20.0-Y-2 # 3.4.3.3 and 4.2.3.1.1.) 3. For easy use in contracts, references shall be made to the particular section referred. 4. Explanations/clarifications have been put out of the specifications, as NOTES (as required by CCSDS A20.0-Y-2 # 3.4.3.3 d) 1)). 5. Binding specification shall use "shall" or "must". Statements as "The following NDM/XML tags are defined" are not binding (and therefore could be ignored). ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-15 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-12/4.14 PARAGRAPH NUMBER: 4.8 RID SHORT TITLE: Specifications not individually identified, and mixed with clarifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.8 CREATING AN OEM INSTANTIATION 4.8.1 OVERVIEW Figure A-4 of Annex A presents an example OEM instantiation. 4.8.2 THE <oem> TAG a) An OEM instantiation shall be delimited with the <oem></oem> root element tags using the standard attributes specified in 4.3. b) The final attributes of the <oem> tag shall be ‘id’ and ‘version’. c) The ‘id’ attribute shall be ‘id="CCSDS_OEM_VERS"’. d) The ‘version’ attribute for the version of the OEM described in Reference [2], section XXX, shall be ‘version="2.0"’. 4.8.3 THE <oem> HEADER The standard NDM header shall follow the <oem> tag. NOTE: See 4.4. 4.8.4 THE <oem> BODY 4.8.4.1 GENERAL a) The OEM <body> shall consist of one or more <segment> constructs. NOTE: See figure 3-2. b) Each <segment> shall consist of a <metadata> section and a <data> section. c) The keywords in the <metadata> and <data> sections shall be those specified in Reference [2] section XXX. d) Between the <data> and </data> tags, the keywords shall be the same as those in the data sections in Reference [2], section XXX. e) Tags for keywords specified in reference [2] shall be all uppercase as in Reference [2], section XXX. NOTE - In addition to the OEM keywords specified in reference [2], there are some special tags associated with the OEM body as described in subsections 4.8.4.2 and 4.8.4.3.

4.8.4.2 THE <stateVector> TAG a) The <stateVector> tag shall encapsulate the keywords associated with one of the ephemeris data lines in the OEM. b) In the XML representation of the OEM, the components of the ephemeris data line must be represented with the same keywords (i.e., a tag) than those defined for the same construct in the OPM. NOTE: In the KVN representations of the ephemeris data lines, keywords are not used. Rather, the components of the ephemeris data line appear in an order defined by reference [2]. c) The OPM may include units. NOTE: Units are not used in the KVN version of the OEM; however, they are optional in the OPM. d) Units may appear in the XML version of the OEM ephemeris data line. NOTE - The reason is that the state vector structure is shared by the OPM schema and OEM schema. e) The NDM/XML tags defined in Tbale 4-6 shall be used in the <stateVector>. [HERE TABLE 4-7 (with no caption in the original draft)] 4.8.4.3 THE <covarianceMatrix> TAG a) The <covarianceMatrix> tag shall encapsulate the keywords associated with the covariance matrix lines in the OEM. NOTE: In the KVN representations of the covariance matrix data lines, keywords are not used. Rather, the components of the covariance matrix data line appear in an order defined by reference [2]. b) In the XML representation, the covariance data line must be represented with the same keywords (i.e., a tag) than those defined for the same construct in the OPM and OMM. c) Units may appear in the OPM and OMM. NOTE - Units are not used in the KVN version of the OEM covariance matrix. d) Units may appear in the XML version of the OEM covariance matrix line. NOTE: Since the covariance matrix structure is shared by the OPM, OMM and OEM, e) The NDM/XML tags defined in Table 4-7 shall be used in the <covarianceMatrix>: [HERE TABLE 4-8 (with no caption in the original draft)] 4.8.5 CREATING AN OEM VERSION 1 COMPATIBLE INSTANTIATION If an OEM instantiation compatible with the ODM Version 1 (reference [2], annex F) is created, the following conditions shall be met: a) Code the xsi:noNamespaceSchemaLocation as: xsi:noNamespaceSchemaLocation="http://cwe.ccsds.org/moims/docs/MO IMS-NAV/Schemas/ndmxml-1.0-master-odmsilver.xsd" b) Use the following value for the attribute version of the <oem> tag: 1) If an XSLT transformation is used to create a version 1.0 compliant KVN-formatted OEM, then use ‘version="1.0"’. 2) Otherwise, use ‘version="2.0"’. c) Do not code the <REF_FRAME_EPOCH> keyword. d) Do not code the acceleration components of the <stateVector> construct. e) Do not code the <covarianceMatrix> construct. f) Do not place comments othar than: 1) at the beginning of the OEM <header>; 2) at the beginning of a <metadata> section; 3) at the beginning of a <data> section. NOTE 1 - The placement of comments in XML instantiations of the Version 1 OEM is more restricted than is allowed in KVN

instantiations of the Version 1 OEM. In order to create a valid OEM XML instantiation. NOTE 2 - See annex A, figure A-5, for an example OEM instantiation that complies with OEM Version 1.0. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. NOTES should be NOTES to specifications, not to titles. To avoid self-standing notes, section 4.8.1 OVERVIEW is porposed. 2. Specifications shall be individually identified (See CCSDS A20.0-Y-2 # 3.4.3.3 and 4.2.3.1.1.) 3. For easy use in contracts, references shall be made to the particular section referred. 4. Explanations/clarifications have been put out of the specifications, as NOTES (as required by CCSDS A20.0-Y-2 # 3.4.3.3 d) 1)). 5. Binding specification shall use "shall" or "must". Statements as "The same rules than..." or "The following tags are defined" are not binding (and therefore could be ignored). 6) Last NOTE in the original draft is rather a specification ("should"), and therefore shall not be in a NOTE. ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-16 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-15/4-16 PARAGRAPH NUMBER: 4.9 RID SHORT TITLE: Specifications not individually identified, and mixed with clarifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.9 CREATING AN OMM INSTANTIATION 4.9.1 OVERVIEW Figure A-6 in Annex A presents an example of OMM instantiation. 4.9.2 THE <omm> TAG a) An OMM instantiation shall be delimited with the <omm></omm> root element tags using the standard attributes specified in 4.3. b) The final attributes of the <omm> tag shall be ‘id’ and ‘version’. c) The ‘id’ attribute shall be ‘id="CCSDS_OMM_VERS"’. d) The ‘version’ attribute for the version of the OMM described in reference [2] section XXX shall be ‘version="2.0"’. 4.9.3 THE <omm> HEADER The standard NDM header shall follow the <omm> tag. NOTE: See 4.4. 4.9.4 THE <omm> BODY 4.9.4.1 GENERAL a) The OMM <body> shall consist of a single <segment>. NOTE: See figure 3-1. b) The <segment> shall consist of a <metadata> section and a <data> section. c) The keywords in the <metadata> and <data> sections shall be those specified in reference [2], section XXXX. d) Between the <data> and </data> tags, the keywords shall be the same as those in the data sections in Reference [2], section XXX. e) Tags for keywords specified in reference [2] shall be all uppercase as in Reference [2], section XXX. NOTE - In addition to the OEM keywords specified in reference [2], there are some special tags associated with the OEM body as described in subsections 4.9.4.2 and 4.9.4.3.

4.9.4.2 SPECIAL <omm> TAGS a) The information content in the OMM shall be separated into logical blocks, as specified in rreference [2], section XXXX. b) To encapsulate the information in the logical blocks of the OMM, the NDM/XML tags defined in Table 4-8 shall be used. [HERE TABLE 4-8 (with no caption in the original draft)] c) Between the begin tag and end tag, the user must place the keywords required by the specific logical block as specified in reference [2], section XXXX. NOTE 1 - E.g., between <spacecraftParameters> and </spacecraftParameters>. NOTE 2 - For the use of <userDefinedParameters>, see 4.13. 4.9.4.3 UNITS IN THE NDM/XML OMM a) Units may appear only in the NDM/XML OMM keywords tags specified in Table 4-9. [HERE TABLE 4-9 (without caption in the original draft)] b) If units appear inr NDM/XML OMM keywords, these units shall match those defined in Reference [2], section XXXX. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. NOTES should be NOTES to specifications, not to titles. To avoid self-standing notes, section 4.9.1 OVERVIEW is porposed. 2. Specifications shall be individually identified (See CCSDS A20.0-Y-2 # 3.4.3.3 and 4.2.3.1.1.) 3. For easy use in contracts, references shall be made to the particular section referred. 4. Explanations/clarifications have been put out of the specifications, as NOTES (as required by CCSDS A20.0-Y-2 # 3.4.3.3 d) 1)). 5. Binding specification shall use "shall" or "must". Statements as "The same rules than..." or "The following tags are defined" are not binding (and therefore could be ignored). 6) Last NOTE in the original draft is rather a specification ("should"), and therefore shall not be in a NOTE. ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-17 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-17/4-19 PARAGRAPH NUMBER: 4.10 RID SHORT TITLE: Specifications not individually identified, and mixed with clarifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.10 CREATING AN OPM INSTANTIATION 4.10.1 OVERVIEW Figure A-7 in Annex A presents an example of OPM instantiation. 4.10.2 THE <opm> TAG a) An OPM instantiation shall be delimited with the <opm></opm> root element tags using the standard attributes specified in 4.3. b) The final attributes of the <opm> tag shall be ‘id’ and ‘version’. c) The ‘id’ attribute shall be ‘id="CCSDS_OPM_VERS"’. d) The ‘version’ attribute for the version of the OPM described in reference [2], section XXXX, shall be ‘version="2.0"’. 4.10.3 THE <opm> HEADER The standard NDM header shall follow the <opm> tag. NOTE - See 4.4. 4.10.4 THE <opm> BODY 4.10.4.1 GENERAL a) The OPM <body> shall consist of a single <segment>. NOTE - See figure 3-1). b) The segment shall consist of a <metadata> section and a <data> section. c) The keywords in the <metadata> and <data> sections shall be those specified in reference [2], section XXXX. d) Between the <data> and </data> tags, the keywords shall be the same as those in the data sections in Reference [2], section XXX. e) Tags for keywords specified in reference [2] shall be all uppercase as in reference [2], section XXX. NOTE - In addition to the OPM keywords specified in reference [2], there are several special tags associated with the OPM body as described in subsections 4.10.4.2 to 4.10.4.4. .

4.10.4.2 SPECIAL <opm> TAGS a) The information content in the OMM shall be separated into logical blocks, as specified in rreference [2], section XXXX. b) To encapsulate the information in the logical blocks of the OPM, the NDM/XML tags defined in Table 4-10 shall be used. [HERE TABLE 4-10 (without caption in the original draft)] c) Between the begin tag and end tag, the user must place the keywords required by the specific logical block as specified in reference [2], section XXX. NOTE 1 - E.g., between <spacecraftParameters> and </spacecraftParameters>. NOTE 2 - For the use of <userDefinedParameters>, see 4.13. 4.10.4.3 UNITS IN THE NDM/XML OPM a) Units may appear only in the NDM/XML OPM keywords tags specified in Table 4-11. [HERE TABLE 4-11 (without caption in the original draft)] b) If units appear inr NDM/XML OPM keywords, these units shall match those defined in Reference [2], section XXXX. 4.10.4 CREATING AN OPM VERSION 1 COMPATIBLE INSTANTIATION If an OEM instantiation compatible with the ODM Version 1 (reference [2], annex F) is created, the following conditions shall be met: a) Code the xsi:noNamespaceSchemaLocation as: xsi:noNamespaceSchemaLocation="http://cwe.ccsds.org/moims/docs/MO IMS-NAV/Schemas/ndmxml-1.0-master-odmsilver.xsd" b) Use the following value for the version attribute of the <opm> tag: 1) If an XSLT transformation is used to create a version 1.0 compliant KVN-formatted OPM, then use ‘version="1.0"’. 2) Otherwise, use ‘version="2.0"’. c) Do not code the <REF_FRAME_EPOCH> keyword. d) Do not code the <spacecraftParameters> logical block. e) Do not code the acceleration components of the <stateVector> construct. f) Do not code the <covarianceMatrix> construct. g) Do not code any <userDefinedParameters>. h) Do not place comments other than: 1) at the beginning of the OPM <header>; 2) at the beginning of the <metadata> section; 3) at the beginning of one of the logical blocks. NOTE 1 - The placement of comments in XML instantiations of the Version 1 OPM is more restricted than is allowed in KVN instantiations of the Version 1 OPM. NOTE 2 - See annex A, figure A-8, for an example OPM instantiation that complies with OPM Version 1.0. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS:

1. NOTES should be NOTES to specifications, not to titles. To avoid self-standing notes, section 4.9.1 OVERVIEW is porposed. 2. Specifications shall be individually identified (See CCSDS A20.0-Y-2 # 3.4.3.3 and 4.2.3.1.1.) 3. For easy use in contracts, references shall be made to the particular section referred. 4. Explanations/clarifications have been put out of the specifications, as NOTES (as required by CCSDS A20.0-Y-2 # 3.4.3.3 d) 1)). 5. Binding specification shall use "shall" or "must". Statements as "The same rules than..." or "The following tags are defined" are not binding (and therefore could be ignored). ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-18 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-20 PARAGRAPH NUMBER: 4.11 RID SHORT TITLE: Specifications not individually identified, and mixed with clarifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.11 CREATING A TDM INSTANTIATION 4.11.1 OVERVIEW Figure A-9 in Annex A presents an example TDM instantiation. 4.11.2 THE <tdm> TAG a) A TDM instantiation shall be delimited with the <tdm></tdm> root element tags using the standard attributes specified in 4.3. b) The final attributes of the <tdm> tag shall be ‘id’ and ‘version’. c) The ‘id’ attribute shall be ‘id="CCSDS_TDM_VERS"’. d) The ‘version’ attribute for the version of the TDM described in reference [3], section XXX, shall be ‘version="1.0"’. 4.11.3 THE <tdm> HEADER The standard NDM header shall follow the <tdm> tag. NOTE - See 4.4. 4.11.3 THE <tdm> BODY 4.11.3.1 GENERAL a) The TDM <body> shall consist of one or more <segment> constructs. NOTE: See figure 3-2. b) Each <segment> shall consist of a <metadata> section and a <data> section. c) The keywords in the <metadata> and <data> sections shall be those specified in reference [3], section XXX. d) Between the <data> and </data> tags, the keywords in the NDM shall be the same as those in the data sections in reference [3], section XXX. e) Tags for keywords specified in reference [3] shall be all uppercase as in reference [3], section XXX. NOTE - In addition to the OPM keywords specified in reference [3], there are several special tags associated with the TDM body as described in subsection 4.11.4.2.

4.11.4.2 THE <observation> TAG a) The <observation> tag shall be used to encapsulate the keywords associated with one of the tracking data types in the TDM. b) The <observation> tag shall consists of two subcomponents: 1) the time tag (<EPOCH> tag), and 2) one specific data type (e.g., <RECEIVE_FREQ>). NOTE: Thus a received frequency observation would appear in an NDM/XML TDM: <observation> <EPOCH>2008-200T12:34:56.789</EPOCH> <RECEIVE_FREQ>8415000000</RECEIVE_FREQ> </observation> ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. NOTES should be NOTES to specifications, not to titles. To avoid self-standing notes, section 4.9.1 OVERVIEW is porposed. 2. Specifications shall be individually identified (See CCSDS A20.0-Y-2 # 3.4.3.3 and 4.2.3.1.1.) 3. For easy use in contracts, references shall be made to the particular section referred. 4. Explanations/clarifications have been put out of the specifications, as NOTES (as required by CCSDS A20.0-Y-2 # 3.4.3.3 d) 1)). 5. Binding specification shall use "shall" or "must". Statements as "The same rules than..." or "The following tags are defined" OR " The tag is used to encapsulate" are not binding (and therefore could be ignored). 6) Last NOTE in the original draft is rather a specification ("should"), and therefore shall not be in a NOTE. ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-19 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-21/4-23 PARAGRAPH NUMBER: 4.12 RID SHORT TITLE: Specifications not individually identified, and mixed with clarifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.12 CREATING A COMBINED INSTANTIATION 4.12.1 GENERAL A combined XML instance that incorporates any number and any combination of AEM, APM, OEM, OMM, OPM, and TDM messages in a logical suite may be created as specified in 4.12.2 and 4.12.3.. NOTE 1 - The OEM Version 1 and OPM Version 1 are not supported in a combined instantiation. 4.12.2 THE <ndm> TAG a) A combined instantiation shall be delimited with the <ndm></ndm> root element tags instead of one of the individual message tags. b) The standard attributes specified in 4.3 shall be used, with the exception that neither ‘id’ nor ‘version’ attributes are associated with the <ndm> tag. NOTE - Between the <ndm></ndm> tags, then, the desired message tags as described in 4.12.1 CAN be combined. 4.12.3 MESSAGE TAGS IN THE COMBINED INSTANTIATION a) In the combined instantiation, the ‘id’ and ‘version’ attributes, as specified in 4.6.2, 4.7.2, 4.8.2, 4.9.2, 4.10.2 and 4.11.2, shall always appear in the constituent message tags. NOTE 1 - In the example in Figure 4-1, all of the detail has been removed to illustrate the structure. Any combination of constituent message types CAN be used in a combined instantiation. A special usage of combined messages CAN be for a constellation of spacecraft, e.g., Cluster. Another potential use is where an attitude data message depends upon a particular orbital state, an APM and its associated OPM could be conveniently conveyed in a single NDM. The figure below contrasts the single message NDM with a multiple message NDM. [HERE FIGURE 4-1] NOTE 2 - The basic structure of a combined instantiation NDM is illustrated in figure 4-2.

[HERE FIGURE 4-2] NOTE 3 - As shown below, in a combined instantiation the individual message tag still has the ‘id’ and ‘version’ attributes, but the namespace attributes and schema location attributes are associated with the <ndm> root element tag. [HERE FIGURE 4-3] b) A valid ‘empty’ NDM, i.e., an NDM that contains only the outermost tag levels, c an be generated. NOTE - However, it is expected that an NDM that is a combined instantiation consists of at least one message (AEM, APM, OEM, OMM, OPM, or TDM). ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. Specifications shall be individually identified (See CCSDS A20.0-Y-2 # 3.4.3.3 and 4.2.3.1.1.) 2. References "above" and "below" are vague. 3. MAY is used to express possibilities, which is against CCSDS A20.0-Y-2 #3.4.1.7.2. Here, it has been substituted by CAN. 4) Optional specifications, however, shall use may. This rule applies to 4.12.1. 4. Explanations/clarifications have been put out of the specifications, as NOTES (as required by CCSDS A20.0-Y-2 # 3.4.3.3 d) 1)). ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-20 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 4-25 PARAGRAPH NUMBER: 4.13 RID SHORT TITLE: Specifications not individually identified, and mixed with clarifications ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 4.13 USER DEFINED PARAMETERS a) In the ODM Version 2.0, ‘user-defined parameters’ may be used. NOTE 1 - These parameters are situation specific and are not standardized. NOTE 2 - User-defined parameters in the NDM/XML are only supported for the OMM and OPM Version 2; userdefined parameters are not supported in the OEM Version 2 or any other Navigation Data Message. b) If used, the user-defined parameters must be specified in the ICDs between the exchange participants. NOTE - However, the use of user-defined parameters is not encouraged. c) If used, the user-defined parameters shall 1) appear in a logical block offset with the tag <userDefinedParameters> 2) consist of any number of any number and order of <USER_DEFINED> tags within the block, . d) The prefix shall be the XML tag and the variable-length name of the parameter shall be the value for the ‘parameter’ attribute. e) All information about the user-defined parameters shall be conveyed via the attributes ‘parameter’ and ‘value’. f) The type for ‘value’ shall be ‘xsd:string’, even if the value is numeric. NOTE 1 - The KVN keywords for user-defined parameters are formed by using the prefix ‘USER_DEFINED’ followed by a variable-length character string . For example, the following KVN parameters might appear in an OMM or OPM: USER_DEFINED_ATMOSPHERE_MODEL = MSISE90 USER_DEFINED_C3 = 29.376 USER_DEFINED_EARTH_RADIUS = 6378.1 USER_DEFINED_3RD_BODY_PERTURBATION = JUPITER These parameters would appear in an NDM/XML representation as: <userDefinedParameters>

<USER_DEFINED parameter="ATMOSPHERE_MODEL">MSISE90</USER_DEFINED> <USER_DEFINED parameter="C3">29.376</USER_DEFINED> <USER_DEFINED parameter="EARTH_RADIUS">6378.1</USER_DEFINED> <USER_DEFINED parameter="3RD_BODY_PERTURBATION">JUPITER</USER_DEFINED> </userDefinedParameters> ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. Specifications shall be individually identified (See CCSDS A20.0-Y-2 # 3.4.3.3 and 4.2.3.1.1.) 2. Explanations/clarifications have been put out of the specifications, as NOTES (as required by CCSDS A20.0-Y-2 # 3.4.3.3 d) 1)). ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-21 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: 5-1 & 5-2 PARAGRAPH NUMBER: 5 RID SHORT TITLE: Misuse of the mandatory terminology ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: (See original) TO: 5.1 OVERVIEW .. .. .. 5.2.6 AUDITING OF RESOURCE USAGE Auditing of resource usage SHOULD be handled by the management of systems and networks on which this Recommended Standard is implemented. 5.3 POTENTIAL THREATS AND ATTACK SCENARIOS 5.3.1 OVERVIEW Potential threats or attack scenarios include, but are not limited to, - unauthorized access to the programs/processes that generate and interpret the messages, and - unauthorized access to the messages during transmission between exchange partners. 5.3.2 SPECIFICATIONS a) Unauthorized access to the programs/processes that generate and interpret the messages should be PREVENTED. b) Protection from unauthorized access during transmission SHOULD BE IMPLEMENTED. NOTE: This is specially important if the mission utilizes open ground networks such as the Internet to provide ground station connectivity for the exchange of data formatted in compliance with this Recommended Standard. c) Potential threats or attack scenarios applicable to the systems and networks on which this Recommended Standard is implemented SHOULD be addressed by the management of those systems and networks. 5.4 DISCUSSION ON CONSEQUENCES OF .. .. .. The consequances of.. .. Because these messages CAN be used in preparing pointing and frequency predicts used during spacecraft commanding, and CAN also be used.. .. 5.5 DATA SECURITY IMPLEMENTATION SPECIFICS

Specific information-security interoperability provisions that CAN apply between agencies and other independent users involved in an exchange of data formatted in compliance with this Recommended Standard should be specified in an ICD. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: 1. Non-normative clauses shall use the headings " Overview", " Discussion" , .. , as specified in CCSDS A20.0-Y-2 #3.4.3.3.d.2. Therefore, the Heading "General" (wich suggest general specifications) is not appropriate for 5.1. 2. For the same reason, the heading of 5.4 shall be " Discussion on. .." . A BETTER solution is to move all section 5.4 as a paragraph of 5.1. 3. Specifications shall be individually identified in 5.3, and separated from the background material. Also, the use of " is is important" or " it is recommended" is not appropriate for a " desirable specification". 4. MAY is used instead of CAN to express possibilities (twice in 5.4, and once in 5.5), which is against CCSDS A20.0-Y-2 #3.4.1.7.2. ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified in some respects from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-22 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: A-1 PARAGRAPH NUMBER: A1 RID SHORT TITLE: Misuse of the mandatory nomenclature ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: An assortment of instantiations of the NDM/XML Schema Set MAY be found on the CCSDS Web site at: TO: An assortment of instantiations of the NDM/XML Schema Set CAN be found on the CCSDS Web site at: ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: MAY is used instead of CAN to express possibilities which is against CCSDS A20.0-Y-2 #3.4.1.7.2. ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: ECSS-ECSS-EG-23 SUBMITTING ORGANIZATION (Agency, Center): ECSS ------------------------------------------------------------------ REVIEWER'S NAME: E. Gonzalez-Conde CODE: ES-TEC-QR E-MAIL ADDRESS: [email protected] TELEPHONE: +31 71 5654498 ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 DOCUMENT NAME: XML specification for navigation data messages DATE ISSUED: June 2009 PAGE NUMBER: C-1 PARAGRAPH NUMBER: C1 RID SHORT TITLE: Misuse of the mandatory nomenclature ------------------------------------------------------------------ _____ APPROVE (MEMBER) _____ CONCUR (OBSERVER) _____ COMMENTS DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) FROM: This annex presents the rationale behind the design of the Navigation Data Message XML Specification. It MAY help the application engineer.. .. . TO: This annex presents the rationale behind the design of the Navigation Data Message XML Specification. It CAN help the application engineer.. .. .. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact Technical Fact ___ Recommended ___ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: MAY is used instead of CAN to express possibilities which is against CCSDS A20.0-Y-2 #3.4.1.7.2. ------------------------------------------------------------------ DISPOSITION: Accepted in principle at 26-Oct-2009 CCSDS Fall Meeting (RID accepted, suggested "to" text modified from that suggested by the reviewer). ================================================================== ==================================================================

REVIEW ITEM DISPOSITION (RID): RED BOOK RID INITIATION FORM AGENCY RID NUMBER: NASA-01 SUBMITTING ORGANIZATION (Agency, Center): NASA ------------------------------------------------------------------ REVIEWER'S NAME: Scott Reeves CODE: N/A E-MAIL ADDRESS: [email protected] TELEPHONE: ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 505.0-R-2 Red Book, Issue 2 DOCUMENT NAME: XML Specification for Navigation Data Messages DATE ISSUED: June 2009 PAGE NUMBER: 4-1 PARAGRAPH NUMBER: 4.3.1 RID SHORT TITLE: Tag/Message type vs. Acronym List ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) Although it is stated that NDM is Attitude, Orbit, as well tracking, for clarity, we recommend: from "<ndm></ndm> Combined Instantiation Message" to "<ndm></ndm> Navigation Data Message (Combined Instantiation Message)" ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended ___ Editorial _xx__ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: ------------------------------------------------------------------ DISPOSITION: Accepted at CCSDS Fall 2009 Meetings. Text updated in the cited section, as well as other places in the text where the phrase "combined instantiation" is used without an "NDM" prefix. ================================================================== ==================================================================

review item disposition (rid): red book rid initiation ... documents/navi… · e-mail address:...

Documents