 | SLE Transfer Service Profile Management | Sil Zendejas | | sil@jpl.nasa.gov | Section 5 | | Why are transfer service profiles not treated the same as carrier profiles for the purpose of management? Should they be allowed to be submitted independently? There is already a provision to reference transfer service profiles separately as shown in Figure 4-2 | Recommended | |
| More General Data Set Queries Needed | Sil Zendejas | | sil@jpl.nasa.gov | General | | If a UM needs to determine the current CMs data sets for a given service agreement, a query that returns metadata for all active and pending data sets of a given type is needed. Also, a query that returns all active service agreements for a given mission is needed. Not having this feature would create problem for UM/MDOS operations when context and state of communications is lost for whatever reason. | Recommended | |
| trajectory applicable start and end times | Sil Zendejas | | sil@jpl.nasa.gov | 6-6 | | Should parameters for applicable start and end times for all trajectory types be included? These would be specially needed to support "bilateral" agreements on trajetory format. Corresponding CM and UM requirements would need to be added to check that applicable start and end times fall within actual start/end time interval. | Recommended | |
| Need for unavailabilty event | Sil Zendejas | | sil@jpl.nasa.gov | 5-33 | Figure 5-15 | Consider modelling data transport availability intervals as such rather than as events. The availability windows would then have a start time and end time as well as corresponding start and end time event time windows. This would simplify the management of "events". Along with this, consider eliminating the concept of change events. Instead, model availability windows as intervals of time during which a given carrier profile is active. Any gaps in the sequence of availability windows would imply an unavailability window. To further simplify the model, assume that the carrier, subcarrier and symbol stream parameters values currently part of the availability and change events, simply correspond to the carrier profile that references the "event profile". This assumes that event profiles are only referenced within the context of a carrier profile which I believe is the case. Changes to availability windows could then be simply modelled as multiple carrier requests in a given scenario. This is possible since each carrier request has a reference to a carrier profile and an optional event profile. | Recommended | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | 4-8 | Figure 4-2 | Figure shows that a space link event sequence or space link event sequence reference is specified as part of a carrier request. However, depending on the value of the sequenceOfEvents parameter of the carrier request, zero event sequences can be specified or referenced. | Editorial | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | General | | Size of document would be significantly reduce without compromising content by consolidating some of the common requirements into general requirements. For example, CM requirements for all opeations dealing with syntactic validation and service management validation are the same across operations once the operation has been classified as 2-phase or 3-phase, since the type of messages exchanged is the same across operations of a given type. This would also facilitate maintenance when/if some of these rules or behavior changes. If necessary or desired (for completeness), a reference could be made to this general requirements Table in each of the operation-specific requirements table. | Editorial | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | 5-17 | Table 5-10 | diagnostic value "required resource not supported by referenced Service Agreement." does not match the given definition of "The referenced Service Agreement
does not contain the referenced
data set."
| Editorial | |
| Start Operation Descriptions with QSA Operation | Sil Zendejas | | sil@jpl.nasa.gov | Section 7 | | Since most operations refer to the service agreeement for constraints and limits, it would be good to define the various parameters in service agreement earlier in the document. One possibility is to bring current Section 7 to replace Section 5 and to move Section 5 to Section 6 and so on. | Recommended | |
| constraint violations and resulting FR messages | Sil Zendejas | | sil@jpl.nasa.gov | General | | It would be very useful to have the tables showing the various parameters such as timeouts and threshold values, to also show the consequence of violating the constraints as part of another column in the table. The reverse lookup is documented in the failed return message table parameter table. However, it is not convenient since it cites the requirement number rather than the description. This forces the reader to perform additional lookups when trying to close the loop on a particular requirement. Also, documenting this in the failed return requirements does not make it easy to determine if all syntactic, semantic and service rules are covered by an appropriate diagnostic value. | Recommended | |
| Delivery Quality, Latency Limit, and Data Rate Limit Relationship Needs Explanation | Sil Zendejas | | sil@jpl.nasa.gov | 5-11 | Table 5-14 | what is the relationship between deliveryQuality,
latencyLimit and datarateLimitation?
| Recommended | |
| deliveryQuality needs definition | Sil Zendejas | | sil@jpl.nasa.gov | 5-11 | Table 5-14 | deliveryQuality needs to be semantically defined or a reference to appropriate document needs to be given. What does timelyOnline or completeOnline mean?
| Recommended | |
| Superflous "filter" parameter | Erik Barkley | | erik.barkley@jpl.nasa.gov | 2-11 and 2-12 (Figure 2-4) | | From: "subcarrier frequency, waveform, and filter"
To: "subcarrier frequency and waveform".
The "filter" parameter does not occur in the normative sections of the document. It appears as a "left-over" from in the descriptive section 2 and should be removed. | Editorial | |
| Management of ranging/radiometric services. | Erik Barkley | | erik.barkley@jpl.nasa.gov | General | | The draft recommendation does not address management of ranging and/or radiometric services. Real-world spacecraft tracking operations utilize ranging/radiometric services conjunction with Command and telemetry services far more often than not. Adoption for real-world operation will be greatly hindered if the service management recommendation does not include management of ranging/radiometeric services. the CCSDS 401 modulation scheme includes provision for insertion of ranging tones on the Spacelink carrier. The draft recommendation should at least address this and consider the management of the related transfer services. | Recommended | |
| subcarrier frequency range? | Sil Zendejas | | sil@jpl.nasa.gov | | Table 5-5 | fSubcarrierFrequency data type is defined as "Positive Integer (8000 to 16000)". Not clear what the 8000 to 16000 range means. | Recommended | |
| More inconsistent data types | Sil Zendejas | | sil@jpl.nasa.gov | | Tables 4-61 and 4-76 | Data types String and String256 of referenced parameters inconsistent with similar references in other parts of the document. | Recommended | |
| return error classification | Sil Zendejas | | sil@jpl.nasa.gov | | 4.3.7.2 | Shouldn't the creator name validation error result in a RspDenial rather than RspError message? classification is not intuitive. | Recommended | |
| creator and delegate | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-38 | In RSPC-6, the fact that sleSmCreatorName has to be the same as that of the original creator places an operability constraint on the UM. Why not allow a set of names or at least one "creator" name and an optional delegate name create and change a package during its entire life cycle? At a minimum, rationale for constraining this to creator name is needed. | Recommended | |
| denial vs error | Sil Zendejas | | sil@jpl.nasa.gov | | Tables 4-34 and 4-35 | Suggest that errors due to violations of prenegotiated quantity of service levels should return in a CspDenial data set rather than in a CspError data set. All violations starting with "exceed..." fall under this category. At a minimum, explain the rationale for classifying an exception as an error or as a denial. | Recommended | |
| Errors and Denials | Sil Zendejas | | sil@jpl.nasa.gov | | Figures 4-9, 4-18, and 4-22 | Is there a reason not to return a combination of CspError and CspDenial messages when necessary? If reasons for denial exist independently of the reasons for erro and viceversa, the UM might be forced to iterate submission until all errors and denials are cleared. | Recommended | |
| absolute or relative mix | Sil Zendejas | | sil@jpl.nasa.gov | | CSPD-11 | item f) forces all parameters to be absolute or relative. A more flexible framework would allow for a combination. This combined with a previously suggested feature to allow references to a variable event, would increase the expresiveness of this framework. | Recommended | |
| Time Ordered Sequences | Sil Zendejas | | sil@jpl.nasa.gov | | CSPD-11 | item c) requires that events in SpaceLinkEventSequenceRequest be time ordered. Is this necessary? What is important is that temporal relationships between dependent events be enforced. Since the events sequence information is in a document intended for computer communications, it is not important that the sequence as found in the document be time ordered. | Recommended | |
| validation issue | Sil Zendejas | | sil@jpl.nasa.gov | | CSPD-5 | item d) suffers from previously reported problem of using minimumContactDuration rahter than preferredContactDuration for validation of time span violations. If the intent is to have CM allocate the actual (scheduled) duration based on the time balance available, then this needs to be made explicit.
Also, item d) has same issue reported for Table 4-4. | Technical Fact | |
| Editorial | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-17 | item a) might be better worded: "shall contain one or more ServiceScenario data sets" | Editorial | |
| convolutional coding | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-16 | Does convolutionalCoding parameter also need to specify the constrain length (k) in addition to the rate? | Recommended | |
| 3-way validation | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-16 | When 3-way communicationMode is used and UM allows CM to select the antenna to be used, is CM then responsible for providing the DataTranportAvailabilityEvents associated with this mode of communications? Is CM required to validate that 3-way is in fact possible given the range and geometry of the target trajectory? Please clarify | Recommended | |
| polarization options | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-15 | Should Horizontal and Vertical polarization options be allowed in addition to the circular options? Not sure if these are used in satellite/spacecraft communications. | Recommended | |
| event time window undertainty | Sil Zendejas | | sil@jpl.nasa.gov | | Tables 4-14 and 4-27 | eventTimeWindow is a symmetric offset. Suggest to allow for different values for lead and lag time offsets. This would increase the expresiveness and allow expressions equivalent to "no later than" and "no earlier than". | Recommended | |
| relative event reference inconsistency | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-14 | Relative events are said to be relative to acquisitionStartTime. Elsewhere in the document the events are said to be relative to the scheduled acquistion start time. As noted in comment to Table 4-13, perhaps an option should be added to indicate what event the relative time should be based on. | Recommended | |
| Relative event time enhancement | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-13 | Suggest that the ability to make event times relative to a referenced event or time be enhanced to allow the referenced event to be variable. Additionally, suggest that the offset from the referenced time by allowed to be positive or negative. | Recommended | |
| Inconsistent data types | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-6 | transferServiceConfiProfileRef is of "String" type. This is inconsistent with other similar references where "String256" is used. Suggest to use one or the other or to explain the rationale for the difference. | Technical Fact | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-4 | trajectoryRef parameter can only specify one trajectory id. Hoever, if CM/UM bilateral negotiations result in a service agreement that allows SPK-formatted files, there would likely be a need to be able to submit multiple trajectory files as part of one set. Thus, trajectoryRef should be able to reference a trajectory profile with one or more trajectory files in it. Furthermore, it might be very useful to allow for some type of qualifier for each trajectory entry in profile to distinguish the different files in set. | Technical Fact | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-2, CSPC-18 | fpr item b) of CSPC-18, should scheduled acquistion times be consistent with sequence data set? Can the scheduled stop acquistion time exceed the preferred time? it should be clearly stated (if that is the intent) that the scheduled time span is limited to a value between the minimum and the preferred. | Recommended | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-2, CSPC-18 | Item a2 requires that CM check that the preferred antenna is conformant. However, item a1 does not mention this requirement for required antennas. A required antenna needs to also be checked for conformance during validation. This is already covered in CSPC-10 so this simply needs to be consistent. | Recommended | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-2, CSPC-14 | CSPC-14 requirement suffers from same issues addressed in previous RIDs and having to do with the use of minimum contact duration rather than preferred contact duration for validation. More serious is the issue of having an event sequence event time compared with a non-deterministic time interval as defined by the acquistion time plus the contact time adusted by the various offsets. WHen a sequence of deterministic events is referenced, the duration of the acquistion activity should also be deterministic and consistent with the sequence of event times. It is not clear how the valiator can function without making all times deterministic. This issue was alluded to in the general RIDs dealing with Scheduling and Execution phases of the SLE Service Management life-cycle. | Technical Fact | |
| more ambiguity of offset times | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-6 | startTimeOffset and stopTimeOffset are defined as times in this table. More clearly, these parameters should be defined as time offsets used to compute an absolute time relative to the acquistioinStartTime and acquisitionEndTime repectively. Current definition does not indicate if this offset should be added or subtracted to/from referenced time. Although this might be deduced by careful reading of relevant parts of the document, it would be best to be explicit. | Technical Fact | |
| ambiguity of time offset parameters | Sil Zendejas | | sil@jpl.nasa.gov | | Table 4-5 | acquistionStartTimeLead/Lag parameters are unsigned integers. startTimeOffset and stopTimeOffset defined in Table 4-6 are Integers. SInce both are offsets of time relative to the acquistion time, shy not make both the same type? If values are allowed to be negative, then all time computations involving the offsets can be done in a consisten additive basis. Optionally, values can be constrained to be positive integers. With this option, more clear definitions of the various offset parameters needs to be made so as to clearly specify if the value is to be added or subtracted from the referenced time. | Technical Fact | |
| viewperiod validation | Sil Zendejas | | sil@jpl.nasa.gov | | Tables 4-1 and 4-2 | CSPC-10 item c) refers to viewperiod validation done based on a minimumContactDuration. This validation should be against the preferredContactDuration under the assumption that the scheduled actual will be between these two values. Same issue with items d) and e). Also, these requirements are difficult to verify given the reliance on definitions to parameters not yet defined at this point in the document. | Technical Fact | |
| Self-Containment | Sil Zendejas | | sil@jpl.nasa.gov | | Tables 4-1 and 4-2 | Requirements such as CSPC-4 deal with service management validation checks. However, no mention is made of what action should be taken when a particular service management violation occurs. This might be spelled out elsewhere in the document but perhaps would be more useful to reader to have the requirement be self contained with action and reaction descriptions. | Recommended | |
| Editorial | Sil Zendejas | | sil@jpl.nasa.gov | | Tables 4-1 and 4-2 | Reference is made to Invoker and Performer Requirements for Three-Phase Operation Procedures. However, no reference to Tables 3-28 and 3-29 is made. This is inconsistent with other references to requirements. | Editorial | |
| Editorial | Sil Zendejas | | sil@jpl.nasa.gov | | 4.2.3.1 | Parameters referenced in Section 4 are not really defined until Section 7. Consider defining the parameters and operations earlier in the document. This will make it easier for the first time reader to read the document. | Editorial | |
| Service Package Update operation | Sil Zendejas | | sil@jpl.nasa.gov | | 4.1 | Should there be a service package update operation that covers the needs of the new trajectory and select alternate scenario operations? A more general service package update would allow for updating only selected parts of the package. One extreme would be to replace all components of the package and so the replace operation would not be necessary either. | Recommended | |
| Order of Messages | Sil Zendejas | | sil@jpl.nasa.gov | | 3.4.2.4 | Since order of message sets can not be guaranteed under this agreement, how does the 3-phase pattern protect against the acknowledgement set arriving to submitter before the scuccessful or failure return set? What is the behavior of submitter when this happens? | Technical Fact | |
| automation support | Sil Zendejas | | sil@jpl.nasa.gov | | 3.4.1.2 | Automating submittal of message sets requires a more robust protocol for document set exchange and the need for more explicit levels of transactional integrity in the operations. service package processing. If disposition tiers expire, submitter might want to have an option to retry. Some of this behavior seems to be left to a "bilaterally agreed" handling protocol. | Technical Fact | |
| Time Synchronization | Sil Zendejas | | sil@jpl.nasa.gov | | 3.4.1.2 | Timer management appears to depend on an implication that UM and CM have some level of time synchronization. If timeouts are in seconds or minutes, perhaps an explicit requirement should be mentioned to ensure that both sides of the exchange are somewhat synchronized in time by whatever means are feasible. Additionally, and as mentioned in prior RID, timeout management needs to allow for possible large latencies on message transit. | Technical Fact | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | | 3.3.2.3 | There is probably a need to indicate in an invocation package that all messages be accepted or all rejected as a single transaction. Some of these might depend on each other and it would simplify the management of request to the UM if this option was available. | Recommended | |
| denial of service | Sil Zendejas | | sil@jpl.nasa.gov | | 2.6.4 | It is not clear why "denial of service" can be a consequence of not applying security. | Recommended | |
| editorial | Sil Zendejas | | sil@jpl.nasa.gov | | 2.6.2.5 | replace "enmities" with "entities" | Editorial | |
| editorial | Sil Zendejas | | sil@jpl.nasa.gov | | Table 2-1 | Consider adding name of operation rather than just acronym. Saves time to reader when assessing compliance levels. | Editorial | |
| Editorial | Sil Zendejas | | sil@jpl.nasa.gov | | 2.4 | Inference that all existing system not complying with the prosposed new standard are "ad-hoc" is not appropriate. Consider removing such statement even if true :). | Editorial | |
| CREATOR NAME | Sil Zendejas | | sil@jpl.nasa.gov | | 2.3.3 | CREATOR NAME seems like a misleading name for the described concept. Second paragraph confuses the definition as it states that only the creator can modify or delete the managed entity. Rest of section states that a number of "creators" can be associated with a given managed entity. Seems like this is equivalent to an OWNER ROLE where multiple accounts can be members of. Need to clarify this concept a little better. | Recommended | |
| Query Trajectory | Sil Zendejas | | sil@jpl.nasa.gov | | 2.3.1.6 | Clarify if the QUERY_TRAJECTORY_PREDICTION operation only return list of pending and executing service packages referencing the given trajectory. Will it also return past service packages that have not been deleted by UM? | Recommended | |
| Resource Allocation for Alternates | Sil Zendejas | | sil@jpl.nasa.gov | | | It seems unrealistic to expect that a service package with many scenarios, with only one of them being primary, can be approved on the basis of guaranteeing that all resources reference by various scenarios can be reserved. Suggest that reservation only be done on primary scenario and alternate scenarios be validated only. Since primary scenarios changes can only be initiated by UM anyway, validation of resources can occur at that time. | Recommended | |
| Cascade Delete | Sil Zendejas | | sil@jpl.nasa.gov | | 2.3.1.2.3 and 2.3.1.2.4 | Should there be a parameter to indicate cascading deletes when a service package is deleted and it is referenced by other packages and/or there is a 3-way relation? Is this left to UM to manage? | Recommended | |
| Latency in Timeouts? | Sil Zendejas | | sil@jpl.nasa.gov | | 2.3.1.2.2 | CSP-SR and CSP-FR responses are not delivered if the expected disposition time has expired. Does this expiration (timeout) time account for expected latency of the message in arriving to the UM requester? Depending on the transport and communications mechanism used and which are outside the scope of this agreement, the latency could be considerable. | Technical Fact | |
| Scheduling | Sil Zendejas | | sil@jpl.nasa.gov | | | Unless scheduling is managed fully outside of the SLE Service Management document exchange process, it seems unrealistic that the DSN will use Service Packages as a way to capture scheduling requirements and constraints. As noted in other RIDs, scheduling should be acknowledged by properly and carefully scoping the SLE Service Management activities. | Technical Fact | |
| Antenna List | Sil Zendejas | | sil@jpl.nasa.gov | | 2.3.1.2.2 | It would be desireable to have a way to specify a list of preferred antennas in some kind of priority order rather than specifying one preferred antenna only. | Recommended | |
| Need for more general service package query | Sil Zendejas | | sil@jpl.nasa.gov | | | If UM loses constext, it would be very useful to have a way to query for a set of service packages based on query criteria such as creator name, time submitted, etc. | Recommended | |
| Delete Semantics | Sil Zendejas | | sil@jpl.nasa.gov | | | The delete operation presents an operability issue. If any mesure of "accountability" or archiving service is to be part of the support agreement, the delete operation must take special meaning. At a minimum, it should be left to the CM to decide whether to make this a physical or logical operation. Not doing so would create a service management constraint for CM. | Technical Fact | |
| CM Operation Names | Sil Zendejas | | sil@jpl.nasa.gov | | 2.3.1.2.1 | No rationale is given for having CM operation names in the past tense. Naming is inconsistent with other UM operations. Suggest to make naming consistent or to explain the rationale for the difference. | Editorial | |
| Package Diagram not Defined | Sil Zendejas | | sil@jpl.nasa.gov | | 1.8 | UML notation tutorial does not show package diagram although it is referenced in 1.8.1 and later used in the document. | Editorial | |
| Editorial | Sil Zendejas | | sil@jpl.nasa.gov | | 2.2.7 | change "pace" to "space" in 2.2.7c | Editorial | |
| Trajectory Profile? | Sil Zendejas | | sil@jpl.nasa.gov | | 2.2.7 | Since the terms "Carrier Profile" and "Event Sequence Profile" are used. Suggest similar term for trajectory data sets. Call this the "Trajectory Profile". As noted in another RID, a trajectory profile should probably allow for more than one trajectory in the set. | Recommended | |
| Sequence Profile | Sil Zendejas | | sil@jpl.nasa.gov | | 2.2.4.3 | This paragraph states that event times are defined in relative terms. This is inconsistent with other parts of the document where both, absolute and relative times are allowed. | Recommended | |
| quality metrics | Sil Zendejas | | sil@jpl.nasa.gov | 2.2.3 | | Service Agreement appears highly CM centric. SHould quality measures such as expected availability, percent data return, etc. be part of the agreement? | Recommended | |
| editorial | Sil Zendejas | | sil@jpl.nasa.gov | | 2.2.4.2 | replace "fore" with "for" | Editorial | |
| Buffer Quotas and Latencies | Sil Zendejas | | sil@jpl.nasa.gov | | 2.2.3.3.2 | Is ther a way to define limits on the amount of buffering space to be provided by CM in case UM can not accept the products due to network or availability issues? Are there latency requiremetns for delivery of the various products? Please clarify | Recommended | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | | 2.2.1 | Since S/C attitude information is not included, should it be explicitly said that this information is embedded in the teleocom parameters provided as part of the configuration profile? | Recommended | |
| editorial | Sil Zendejas | | sil@jpl.nasa.gov | | 2.2.2 | Use of SLE term is ont consistent with use of "space link" term. Either abbreviate both or sepll out both. Section 2.2.3 actually spells out SLE. | Editorial | |
| Deferred data sets notifications | Sil Zendejas | | sil@jpl.nasa.gov | | | I might have missed it but did not see a concept for notification messages from CM to UM when deferred data sets are not submitted in time. Is package cancellation the only option? Is keeping track of this fully the responsibility of UM? Please clarify | Recommended | |
| 3-way mode behavior | Sil Zendejas | | sil@jpl.nasa.gov | | | When a DSP/SPM operation is performed and the deleted package has a 3-way relation with another package that remains in the CM, what should the behavior of the CM system be? Should this be the responsibility of the UM? Please clarify | Recommended | |
| Modelling of Availability Events | Sil Zendejas | | sil@jpl.nasa.gov | | | SpaceLinkAvailabilityEvents and other availability events are modelled as events with one time attribute. It could be simpler to manage if all Availability/Unavailability events were paired and part of a single event definition. This new event would have start and end time attributes (parameters) and would simplify the process for both, the CM and UM when validating and generating such events. Although this deviates from currently used schemes, it might be worth considering. | Recommended | |
| scheduling process | Sil Zendejas | | sil@jpl.nasa.gov | | | The implicit existence of a scheduling process where CM and UM are players confuses matters. Service Management does not clearly scope the intended use of the document exchange process that ultimately results in the specification of a service package. Since scheduling appears not to be in the scope of the SLE Service Management, it might be better to confine the scope of this agreement to prescheduled activities. This would simplify the management and validation of lead/lag times and make the process more manageable. Another option is to have SLE Service Management support two distinct phases of the package preparation in a more explicit and targeted manner: Scheduling and Execution. The Scheduling phase would have simplified data sets and operations where mention of optional data sets as currently drafted do not enter the definition of the package. During the Execution phase, the concept of minimum and preferred should not exist and neither should the concept of lead/lag times. The support for each of these phases should also enter into the equation when rating a CM or UM for the level of SLE Service Management support. | Recommended | |
| General issue with semantics of lead/lag/offset times | Sil Zendejas | | sil@jpl.nasa.gov | | | In general, references to minimum, preferred, and scheduled acquisition times present a problem during validation by CM. Validation occurs during CSP-I processing and other "I" operations. Semantics of the various offsets (lead/lag/offset times) are not consistent. How the resulting computed absolute times are compared against times in sequence of events data is not all clear. More specifics will be cited in other RIDs. | Technical Fact | |
| (no title) | Sil Zendejas | | sil@jpl.nasa.gov | | | Parameter names shown in tables should not wrap-around. When file converted to PDF, can't use a search function to find parameter name. This slows down review. | Editorial | |
| Minor Typo or "cut & paste" error | David Berry | | david.s.berry@jpl.nasa.gov | 5-48 | 5.7.5.1 | From: "is the structure class diagram for the DEP-SR message."
To: "is the structure class diagram for the QEP-SR message." | Editorial | |
| Minor Typo or "cut & paste" error | David Berry | | david.s.berry@jpl.nasa.gov | 5-46 | 5.7.3.1 | In requirement QEPU-3
From: "UM should send DCP-I messages..."
To: "UM should send QEP-I messages..." | Editorial | |
| Missing Parameters in QEP Operation Procedure Arguments | David Berry | | david.s.berry@jpl.nasa.gov | 5-45 - 5-46 | 5.7.2 | The QEP twoPhaseOperationProcedure PatternSequence and PatternActivity are missing the "UM" and "CM" parameters. These should be added. | Recommended | |
| Minor Typo or "cut & paste" error | David Berry | | david.s.berry@jpl.nasa.gov | 5-43 | 5.6.6.1 | From: "is the structure class diagram for the DEP-SR message."
To: "is the structure class diagram for the DEP-FR message." | Editorial | |
| Minor Typo or "cut & paste" error | David Berry | | david.s.berry@jpl.nasa.gov | 5-42 | 5.6.5.3, Table 5-47 | In the requirement DEPD-2
From: "The DCP-SR shall..."
To: "The DEP-SR shall..." | Editorial | |
| Missing Parameters in DEP Operation Procedure Arguments | David Berry | | david.s.berry@jpl.nasa.gov | 5-39 | 5.6.2 | The DEP twoPhaseOperationProcedure PatternSequence and PatternActivity are missing the "UM" and "CM" parameters. These should be added. | Recommended | |
| Rationale for Requirement not Clear | David Berry | | david.s.berry@jpl.nasa.gov | 5-34 | 5.5.4.3, Table 5-39 | Requirement AEPD-7 indicates that an AEP sequenceTimeReference must have the value "relative", but it is not clear why the value "absolute" is prohibited. An explanation as to why this is so may be desirable. | Recommended | |
| Missing Requirement Number in Table 5-35 | David Berry | | david.s.berry@jpl.nasa.gov | 5-31 | 5.5.3.1 | In Table 5-35 there are 5 requirements, but only 4 requirement numbers. The third requirement in the list has not been assigned a number.
Recommend assigning a number to the requirement. | Recommended | |
| Missing Parameters in AEP Operation Procedure Arguments | David Berry | | david.s.berry@jpl.nasa.gov | 5-30 | 5.5.2 | The AEP twoPhaseOperationProcedure PatternSequence and PatternActivity are missing the "UM" and "CM" parameters. | Recommended | |
| Errors in QCPD-06 | David Berry | | david.s.berry@jpl.nasa.gov | 5-29 | 5.4.6.3 | From: "DCP-FR"
To " "QCP-FR"
Also,
From: "DCP-I"
To: "QCP-I" | Editorial | |
| Minor Typo or "cut & paste" error | David Berry | | david.s.berry@jpl.nasa.gov | 5-18 | 5.2.7.1 | From: "...is the message structure class diagram for the QCP-AR message."
To: "...is the message structure class diagram for the ACP-AR message." | Editorial | |
| Typo or "cut & paste" error | David Berry | | david.s.berry@jpl.nasa.gov | 5-15 | 5.2.6.1 | From: "...is the message structure class diagram for the QCP-FR message."
To: "...is the message structure class diagram for the ACP-FR message." | Editorial | |
| Allowed pcmWaveform values may be too restrictive | David Berry | | david.s.berry@jpl.nasa.gov | 5-6 | Table 5-4 | The pcmWaveformOptions seem to exclude a number of options that are specified in the 401 Blue Book (e.g., NRZ-S, and the set of bi-phase modulations (unless that is what is meant by "split phase level")).
Should ensure that the PCM waveform options accommodated by 401 are possible in the SLE-SM. | Technical Fact | |
| Allowed fSubcarrierFrequency values too restrictive | David Berry | | david.s.berry@jpl.nasa.gov | 5-6 | Table 5-5 | Some uplinks for flying spacecraft use subcarrier frequencies other than 8000 and 16000. For example, Voyager uses 512 Hz and Muses-C uses 4000 Hz. The DSN Uplink is required to generate subcarriers for commanding over a much wider range of values (from 1 Hz to 16000 Hz), including values that take into account doppler shifts. Future implementations may require higher subcarrier frequencies.
| Technical Fact | |
| Time Ambiguity | David Berry | | david.s.berry@jpl.nasa.gov | F-1 | Annex F | The ambiguity DOY n 24:00:00 = DOY n+1 00:00:00 should not be allowed. The CCSDS Time Code Formats 301 document does not allow this ("hh" restricted to "00" - "23"). | Technical Fact | |
| "UTC" data type should reference CCSDS 301 Time Code Formats | David Berry | | david.s.berry@jpl.nasa.gov | F-1 | Annex F | I'm wondering why the "UTC" data type is not just a reference to CCSDS 301.0-B-3 Time Code Formats Blue Book. This Recommendation establishes a common framework and provides a common basis for the formats of time code data.
| Recommended | |
| YYYY in UTC | David Berry | | david.s.berry@jpl.nasa.gov | F-1 | Annex F | It seems silly to speak of strings of length greater than 4 to describe a year. I'm wondering what was the possible reason to allow more than 4 characters? | Recommended | |
| "String" and "StringX" | David Berry | | david.s.berry@jpl.nasa.gov | F-1 | Annex F | For "String" it is stated that it is a "finite-length sequence of characters". However, in computers, *all* strings are finite length. Thus there would seem to be no practical difference between "String" and "StringX".
Simply stated, it seems that "String" and "StringX" are redundant. | Recommended | |
| "nullable" = "nillable" ? | David BErry | | david.s.berry@jpl.nasa.gov | Annex B (mostly) | Annex B | The terms "nullable" and "nillable" are used seemingly equivalently in the document... there are a couple of instances of "nullable" in Section 1, then most of the references to "nullable" and "nillable" occur in Annex B.
Recommend that the instances of these 2 words be checked to determine that the usage is always correct.
(Since I'm not an expert in XML, I'm not sure whether there is any substance to this RID). | Editorial | |
| Obsolete Term in Annex A | David Berry | | david.s.berry@jpl.nasa.gov | A-1 | Annex A | EPM: obsolete term. Remove from Annex
Justification: "EPM" is completely replaced, and obsoleted by, the term "OEM". | Technical Fact | |
| Acronym Suggestions | David Berry | | david.s.berry@jpl.nasa.gov | A-1 | Annex A | DSS: I wonder if the term "DSS" is too "NASA-centric" for use here. Should consider removing it.
QPSK: I wonder if the other terms for the "Q" might be added, specifically, "quadrature" and "quadra-phase" | Recommended | |
| Strange Lack of Specificity in QSA-FR | David Berry | | david.s.berry@jpl.nasa.gov | 7-26 | 7.2.6.3 | Compared to other "Return" messages in the standard, the lack of specificity here is puzzling... is it really so vague? Should be specified better it seems | Recommended | |
| rPolarizationOptions | David Berry | | david.s.berry@jpl.nasa.gov | 7-17 | Table 7-28 | The set of rPolarizationOptions should be augmented to include "linear" as noted in a prior RID. Also, the "LHC" should be changed to "LCP", and "RHC" should be changed to "RCP" to be consistent with the 401 Blue Book. | Recommended | |
| pcmWaveformOptions | David Berry | | david.s.berry@jpl.nasa.golv | 7-14 | Table 7-23 | The pcmWaveformOptions seem to exclude a number of options that are specified in the 401 Blue Book (e.g., NRZ-S, and the set of bi-phase modulations (unless that is what is meant by "split phase level")).
Should ensure that the PCM waveform options accommodated by 401 are possible in the SLE-SM. | Recommended | |
| fPolarizationOptions Data Set Element | David Berry | | david.s.berry@jpl.nasa.gov | 7-14 | Table 7-23 | The set of options for fPolarizationOptions should be augmented to include "linear", as noted in a previous RID. Also, the "RHC" and "LHC" should be changed to "RCP" and "LCP" respectively, to be consistent with the 401 Blue Book. | Recommended | |
| Minor Typo | David Berry | | david.s.berry@jpl.nasa.gov | 7-13 | Table 7-20 | From" "Value of t urgentTwoPhaseTimeout..."
To: "Value of urgentTwoPhaseTimeout ..."
There is an extra "t" in the "From" value. | Editorial | |
| Add Default Values to Tables where Applicable | David Berry | | david.s.berry@jpl.nasa.gov | 7-10 through 7-22 | Many | Along with the notion of CREATE_SERVICE_AGREEMENT previously expressed, one could set defaults for many of the elements of the Tables in Section 7. Setting defaults for each constraint would allow a vanilla Service Agreement to be created, as a strawman for the negotiation process.
Note: the RID for ServicePackageOperationsConstraints Data Set also expresses this notion. It is the same concept. | Recommended | |
| Add default values to Table where applicable | David Berry | | david.s.berry@jpl.nasa.gov | 7-9 | Table 7-4 | Along with the notion of CREATE_SERVICE_AGREEMENT previously expressed, one could set defaults for many of the elements of the ServicePackageOperationsConstraints Data Set. For example, "allowedAntennaIds" default could be null, maxForwardSpaceLinkCarriersPerScenario could default to 1, maxServicePackageTemporalSpan could default to 28800 (8 hours), etc. Setting defaults for each constraint would allow a vanilla Service Agreement to be created, as a strawman for the negotiation process. | Recommended | |
| Additional Service Agreement Operations | David Berry | | david.s.berry@jpl.nasa.gov | Section 7 | Section 7 | In addition to a "CREATE_SERVICE_AGREEMENT" Operation, it would seem that a MODIFY or REPLACE operation would be needed in order to allow parameters in an existing Service Agreement to be modified. Due to the probably lengthy process of negotiating a Service Agreement, a "CREATE" could create an empty shell, then as aspects of the Service Agreement are negotiated, successive MODIFY operations flesh out the parameters.
Finally, a DELETE_SERVICE_AGREEMENT or OBSOLETE_SERVICE_AGREEMENT operation would seem to be in order (e.g., when a mission is ended).
In general, the Chapter 7 of the Recommendation seems to be insufficiently developed to make the overall recommendation useful. | Recommended | |
| Word Choice | David Berry | | david.s.berry@jpl.nasa.gov | 7-1 | 7.2.1 | From: "...status of a previously negotiated Service Agreement"
To: "...status of a previously created Service Agreement"
Obviously the Service Agreement must be created before it can be queried. | Recommended | |
| Should have "CREATE_SERVICE_AGREEMENT (CSA)" Operation | David Berry | | david.s.berry@jpl.nasa.gov | 7-1 | 7.1 | From: "The means and procedures for the CREATION of a Service Agreement are currently outside the scope..."
To: "The means and procedures for NEGOTIATION of a Service Agreement are currently outside the scope..."
Presumably if there is a Service Agreement that can be queried with the QSA operation, there was some means to create it. The act of creating the Service Agreement as a data structure seems trivial. I agree that the methods of NEGOTIATING are out of scope of the document. But without the means to CREATE a Service Agreement, this entire Service Management Standard would seem to be built on quicksand. The lack of a "CREATE_SERVICE_AGREEMENT" would seem to me to be a fundamental flaw. | Recommended | |
| Error in QTPD-05 | David Berry | | david.s.berry@jpl.nasa.gov | 6-23 | 6.4.5.3, Table 6-25 | Requirement QTPD-05 refers to ATPD-08, which is not shown in Section 6.2.
Reference should be removed, or the ATPD-08 should be specified. | Recommended | |
| DTPC-08 | David Berry | | david.s.berry@jpl.nasa.gov | 6-15 | 6.3.3.2 | From: "...CM shall reject the DTP-I."
To: "...CM shall reject the DTP-I and send a DTP-FR."
I think this is what is intended by saying "reject the DTP-I", but I think it should be clarified. | Recommended | |
| Typo in DTPU-05 | David Berry | | david.s.berry@jpl.nasa.gov | 6-14 | 6.3.3.1, Table 6-15 | From: "...conforms to all DTP-SR or RTP-FR..."
To: "...conforms to all DTP-SR or DTP-FR..." | Editorial | |
| Add case numbering | David Berry | | david.s.berry@jpl.nasa.gov | 6-11 | Table 6-13 | For the diagnostic value "non-conformant to data set composition and relationship requirements of indicated format", there are 5 different cases given. Each case is preceded by a dash "-". However, in the column "Parameter or Data Set Identified by erroredItem", the text refers to the cases by number. It might be helpful for the reader to number these cases. | Editorial | |
| Change Reference # in ATPD-06 | David Berry | | david.s.berry@jpl.nasa.gov | 6-8 | 6.2.4.3 | From: "(reference [14])"
To: "(reference [16])"
Justification: Reference [14] makes only passing reference to XML. Reference [16] is where the XML schemas for OPM and OEM are provided. | Technical Fact | |
| Change Obsolete Usage in ATPD-05 and ATPD-06 | David Berry | | david.s.berry@jpl.nasa.gov | 6-8 | 6.2.4.3 | From: "Ephemeris Parameter Message (EPM)"
To: "Orbit Ephemeris Message (OEM)"
This change should be made in both ATPD-05 and ATPD-06.
Justification: "Ephemeris Parameter Message (EPM)" is an obsolete term, having been replaced by "Orbit Ephemeris Message (OEM)" | Technical Fact | |
| Add "linear" to possible rPolarization Values | David Berry | | david.s.berry@jpl.nasa.gov | 4-17 | Table 4-16 | Although it is not done often for space-to-earth links, the 401 modulation standard doesn't prohibit the use of linear polarization. Thus the present values of "RHC", "LHC" and "dynamic" should be augmented to include "linear".
In section 2.3.5 of the 401 CCSDS RECOMMENDATIONS FOR RADIO FREQUENCY AND MODULATION SYSTEMS it is stated "(3) that when using linear polarization, polarization diversity reception should be used to meet the required system time constants at Earth stations used for Category A missions."
Thus the Service Management Standard should allow the use of linear | Technical Fact | |
| Change "RHC" to "RCP" and "LHC" to "LCP" | David Berry | | david.s.berry@jpl.nasa.gov | 4-15, 4-17 | Table 4-15, 4-16 | There are several possible abbreviations for "Right Hand Circular Polarization" in use (RHC, RHCP, RCP). However, the 401 CCSDS RECOMMENDATIONS FOR RADIO FREQUENCY AND MODULATION SYSTEMS uses "RCP". Should perhaps be consistent.
By symmetry, applies to Left Hand Circular Polarization as well. | Recommended | |
| Add "linear" to possible fPolarization Values | David Berry | | david.s.berry@jpl.nasa.gov | 4-15 | Table 4-15 | Although it is not done often for earth-to-space links, the 401 modulation standard doesn't prohibit the use of linear polarization. Thus the present values of "RHC" and "LHC" should be augmented to include "Linear". | Recommended | |
| Reference Correction | David Berry | | david.s.berry@jpl.nasa.gov | 6-6 | 6.2.4.2 | From: "The specification of the parameters... is given in reference [14] and hence..."
To: "The specification of the parameters... is given in references [14] and [16] and hence..."
Reason: Reference [14] makes only passing reference to XML; reference [16] defines the XML schemas for OPM and OEM. | Technical Fact | |
| Minor Text Change | David Berry | | daivd.s.berry@jpl.nasa.gov | 6-4 | 6.2.3.2 | From: "...CM shall add: a) the Trajectory Prediction..."
To: "...CM shall: a) add the Trajectory Prediction..." | | |
| References in ATPC-10, ATPC-12 | David Berry | | david.s.berry@jpl.nasa.gov | 6-4 | 6.2.3.2 | From: "(reference [14])"
To: "(references [14], [16])"
Reason: Reference 14 makes only passing reference to XML. Reference 16 defines the XML schemas for OPM and OEM. | Technical Fact | |
| ATPC-11, ATPC-12 | David Berry | | david.s.berry@jpl.nasa.gov | 6-4 | 6.2.3.2, Table 6-2 | From: "Ephemeris Parameter Message (EPM)"
To: "Orbit Ephemeris Message (OEM)"
| Technical Fact | |
| ATPU-06 | David Berry | | david.s.berry@jpl.nasa.gov | 6-3 | 6.2.3.1 | This requirement is one that I think will benefit from defining the relationship "is consistent with" when used with trajectories (i.e., as described in a previous RID, that "is consistent with" means that "T1 < S1 < S2 < T2, where T1 & T2 represent the begin/end times of the trajectory, and S1 & S2 represent the earliest begin time and lastest end time of all the Service Scenarios in the Service Package"). | Recommended | |
| Possible error in "modificationReason" | David Berry | | david.s.berry@jpl.nasa.gov | 4-76 | 4.8.4.2, Table 4-75 | Where modificationReason = "scheduleChange", it is stated that "there may be related changes in providerId and/or providerPortId". It is not clear to me how this is possible if only the service time is changed. I think this may be a "cut & paste" error. | Recommended | |
| Error in Argument Lists | David Berry | | david.s.berry@jpl.nasa.gov | 4-72 | 4.8.2 | For the argument lists of the SERVICE_PACKAGE_MODIFIED sequence diagram and activity diagram, the notifier and recipient are inconsistent. | Recommended | |
| Position of Reason "other" in table | David Berry | | david.s.berry@jpl.nasa.gov | 4-65 | Table 4-65 | In this table, there is a value of "other" for the Reason that is not the last position in the table. In general, it is recommended that if there is a diagnostic or reason of "other", it be the last position of the table, even if the table is otherwise sorted in alphabetical order. | Recommended | |
| Potential Issue with use of word "match" in ANTC-7 | David Berry | | david.s.berry@jpl.nasa.gov | 4-60 | 4.6.3.2 | In every other instance of the word "match" in the document, there is one parameter, usually a reference of some sort, that must necessarily match exactly. However, in the case of a trajectory, I don't think an exact match is necessary. Thus using "match" here is perhaps a poor choice. I think what is really meant is that T1 < S1 < S2 < T2, where T1 & T2 represent the begin/end times of the trajectory, and S1 & S2 represent the Service Scenario begin/end times.
It may be worth putting this definition somewhere in the document stating that it is what is meant by the phrase "consistent with" when used for trajectories. | Recommended | |
| Minor formatting observation | David Berry | | david.s.berry@jpl.nasa.gov | 4-59, 4-60 | Table 4-60 | May wish to wrap the text in ANTC-4 and ANTC-5. | Editorial | |
| Requirement for SAS? | David Berry | | david.s.berry@jpl.nasa.gov | 4-54 | 4.5.4.3 | It seems that maybe there should be another requirement for the SAS (i.e., SASD-4), specifically, something to the effect that the "alternate scenario" ref should be different than the prime scenario ref that is already associated with the service package. | Recommended | |
| DSPC-9 | David Berry | | david.s.berry | 4-46 | 4.4.3.2 | From: "...the corresponding CSP-I"
To: "...the corresponding DSP-I" | Recommended | |
| Unnecessary Lack of Symmetry in Three-Phase Operation Pattern Arguments | David Berry | | david.s.berry | 3-42, 3-42 | 3.4.2.3, 3.4.2.4 | It is not clear why the argument lists of the "threePhaseOperationProcedurePatternSequence" and "threePhaseOperationProcedurePatternActivity" are so different. There are only 2 parameters in these two argument lists that are not in both argument lists. These 2 should be the last in the list of the activity diagram, and the other arguments should be in the same order in both lists (i.e., order of SR and FR is different in the 2... both should be SR, FR).
There was a previous RID to this effect on a specific instance, but now having read more of the document I see that the argument lists of the underlying sequence/activity diagrams are the things that should change, and then the specific instantiations should be corrected to match the operation procedure pattern. Note that there is an instance in section 4 that does not conform to the patterns as listed (e.g., ANT), which shows the "SR, FR" in the same order, as I think they should be. | Recommended | |
| Unnecessary Lack of Symmetry in Two-Phase Operation Pattern Arguments | David Berry | | david.s.berry@jpl.nasa.gov | 3-35, 3-36 | 3.4.1.3, 3.4.1.4 | It is not clear why the argument lists of the "twoPhaseOperationProcedurePatternSequence" and "twoPhaseOperationProcedurePatternActivity" are so different. There are only 2 parameters in these two argument lists that are not in both argument lists. These 2 should be the last in the list of the activity diagram, and the other arguments should be in the same order in both lists (i.e., order of SR and FR is different in the 2... both should be SR, FR).
There was a previous RID to this effect on a specific instance, but now having read more of the document I see that the argument lists of the underlying sequence/activity diagrams are the things that should change, and then the specific instantiations should be corrected to match the operation procedure pattern. Note that there are several instances in section 6 and section 7 that do not conform to the patterns as listed (e.g., ATP, DTP, QTP, QSA), but show the "SR, FR" in the same order, as I think they should be. | Recommended | |
| reason value = "unable to view spacecraft from antenna" | David Berry | | david.s.berry@jpl.nasa.gov | 4-36 | Table 4-35 | Shouldn't the Definition/Description include a statement to the effect that occultation events are not included? I.e., during an occultation it is not possible to view the spacecraft from the antenna, however, that would not seem to be a reason to deny creation of a service package. | Recommended | |
| diganostic = event sequence exhibits time regression... | David Berry | | david.s.berry@jpl.nasa.gov | 4.36 | Table 4d-34 | In this line of the table, there is a minor error in the Definition/Description:
From: "... potentially earlier than is predecessor"
To: "... potentially earlier than its predecessor" | Editorial | |
| event sequence incompatible with CarrierProfile | David Berry | | david.s.berry@jpl.nasa.gov | 4-35 | Table 4-34 | The diagnostic information (carrierProfileRef and Event Sequence Profile) do not seem to be detailed enough to enable the UM to easily determine where the conflict exists.
The element of the CarrierProfile and element of the event sequence that are incompatible should be identified, not the constructs as a whole. | Recommended | |
| Service Package Temporal Span | David Berry | | david.s.berry@jpl.nasa.gov | 4-34 | 4.2.9.2 | In Table 4-34, the diagnostic of "exceeds maxServicePackageTemporalSpan" may have an error in the "Parameter or Data Set Identified by erroredItem".
From: "Identification of the earliest acquisitionStartTime and latest acquisitionStartTime..."
From: "Identification of the earliest acquisitionStartTime and latest acquisitionStopTime..." | Recommended | |
| Convolutional Coding rates | David Berry | | david.s.berry@jpl.nasa.gov | 4-17 | Table 4-16 | I would recommend that the list of enumerations be confirmed to ensure that all possible values are captured here. I am not completely familiar with the possible rates, but comparing this list to some JPL documentation suggests that there may be some rates left out here. | Recommended | |
| MPR-0008 | David Berry | | david.s.berry@jpl.nasa.gov | 3-16 | 3.3.3.2 | This requirement states that "the Receiver is not required to further process the invalid invocation message."
As stated, there is an implementation option (i.e., the Receiver may decide to continue processing the invalid invocation message, or may decide NOT to continue processing the invalid invocation message).
Is this what the authors intended? | Recommended | |
| Possible Error in Table 4-33 | David Berry | | david.s.berry@jpl.nasa.gov | 4-32 | 4.2.8.3 | The text in requirement CSPD-30 does not seem to relate to the topic of Table 4-33. | Recommended | |
| Error in requirement CSPD (i) (?) | David Berry | | david.s.berry@jpl.nasa.gov | 4-20 | CSPD-11 | From: "i) the last eventTime of the sequence shall be no later than the acquisitionStartTime plus minimumContactDuration"
To: "i) the last eventTime of the sequence shall be no earlier than the acquisitionStartTime plus minimumContactDuration"
Justification: as stated, there is no need for the preferredContactDuration. | Recommended | |
| Unrealistic Requirements (?) | David Berry | | david.s.berry@jpl.nasa.gov | 4-20 | CSPD-11 | CSPD-11(f) indicates that eventTimes shall be all absolute or all relative, but this does not seem consistent with the fact that acquistionStartTime and acquisitionStopTime can vary. | Recommended | |
| [R|F]...forward and return | David Berry | | david.s.berry@jpl.nasa.gov | 4-17, 4-29 | 4.2.4.3, 4.2.6.3 | From: "...use the notation [R|F] in requirements that are applicable to the forward and return data sets..."
To Option#1: "...use the notation [R|F] in requirements that are applicable to the return and forward data sets..."
To Option#2: "...use the notation [R|F] in requirements that are applicable to the return and forward data sets respectively..."
To Option#3: "...use the notation [F|R] in requirements that are applicable to the forward and return data sets..."
To Option#4: "...use the notation [F|R] in requirements that are applicable to the forward and return data sets respectively..." | Editorial | |
| rSubcarrierFrequency | David Berry | | david.s.berry@jpl.nasa.gov | 4-17 | Table 4-16 | It is not clear what should be entered in this field if the modulation is direct to carrier... zero (0)? Perhaps should specify. | Recommended | |
| Unclear text | David Berry | | "The forward and return carrier spacelink involves different antennaRef parameters" | 4-16 | Table 4-16 | In the "2-way" definition of "communicationMode", the following appears:
"The return carrier frequency may be coherent with the forward carrier frequency as determined by sensitivity to a forward carrier as defined ..."
This should be essentially the same as the text that appears on the "3-way" definition, which is somewhat different (and clearer):
"The return carrier frequency may be coherent with the forward carrier frequency as defined ..." | Recommended | |
| Word Choice in "communicationMode" | David Berry | | david.s.berry@jpl.nasa.gov | 4-16 | Table 4-16 | From: "Both the forward and return carrier spacelink service involve the same antennaRef parameter"
To: "Both the forward and return carrier spacelink service specify the same antennaRef parameter value"
From: "The forward and return carrier spacelink involves different antennaRef parameters"
To: "The forward and return carrier spacelink specify different antennaRef parameter values" | Editorial | |
| "eventTime" parameter definition | David Berry | | david.s.berry@jpl.nasa.gov | 4-14 | Table 4-14 | It is currently the case in some operations that events are specified relative to the end of a track, or in the terms of this specification, the "acquisitionStopTime". However, this option is not covered by the eventTime description, which is restricted to eventTimes relative to the acquisitionStartTime.
If the data type was SIGNED integer, however, a positive number could be used to indicate that the number should be added to the acquisitionStartTime, and a negative number could be used to indicate that the number should be added to the acquisitionStopTime. Thus events could be specified relative to either end of the service.
Such a facility really is necessary given that the actual contactDuration could vary between the minimumContactDuration and preferredContactDuration. | Technical Fact | |
| Error in Requirement CSPC-14 | David Berry | | david.s.berry@jpl.nasa.gov | 4-5 | 4.2.3.2 | This requirement states: "... the difference between the first and last eventTime parameters of the sequence are less than or equal to the minimumContactDuration".
If the difference between the first and last eventTime parameters is less than the minimumContactDuration, there appears to be a contradiction.
From: "less than or equal to"
To: "greater than or equal to"
or alternatively
From: "minimumContactDuration"
To: "preferredContactDuration" ??? | Technical Fact | |
| Diagram Might Be Helpful | David Berry | | david.s.berry@jpl.nasa.gov | 4-4 | 4.2.3.2 | A simple diagram of the time relationships in CSPC-10(e) might be helpful. | Recommended | |
| Unnecessary Lack of Symmetry | David Berry | | david.s.berry@jpl.nasa.gov | 4-2 | 4.2.2 | It is not clear why the argument lists of the "threePhaseOperationProcedurePatternSequence" and "threePhaseOperationProcedurePatternActivity" are so different. There are only 2 parameters in these two argument lists that are not in both argument lists. These 2 should be the last in the list of the activity diagram, and the other arguments should be in the same order in both lists. KISS | Recommended | |
| Notified Operation Procedure Pattern Activity Diagram | David Berry | | david.s.berry@jpl.nasa.gov | 3-49 | 3.4.3.4 | This may be my own ignorance, but in Figure 3-19 it is not clear to me how or where the confirmation timer is reset in the case of a valid confirmation? I see where it times out in the case of no receipt of confirmation, but not what happens to the timer when there is a valid confirmation received. | Recommended | |
| Requirement outside Performer control | David Berry | | david.s.berry@jpl.nasa.gov | 3-38 | 3.4.1.5.2 | Requirement 2PP-0103 states that "the Performer shall transmit the SuccessfulReturn or FailedReturn to the message set port of the Invoker such that the return is received by the Invoker at or before the messageTimestamp of the operation invocation plus the value of the appropriate two phase timeout parameter of the referenced Service Agreement".
It is not clear how the Performer can ensure when the Inovker receives the return message. It would seem that the only factor that is within the control of the Performer is the time that they SEND the return... not when it is received by the Invoker. | Technical Fact | |
| Differences between "invalid" and "repeated" messageSequenceNumber not clear | David Berry | | david.s.berry@jpl.nasa.gov | 3-31 | 3.3.4.4, Table 3-24 | The functional difference between "invalid messageSequenceNumber" and "repeated messageSequenceNumber" is not clear. The difference between the underlying requirements MPR-0007 and MPR-0008 is not clear. | Recommended | |
| Unnecessary Complication | David Berry | | david.s.berry@jpl.nasa.gov | 3-30 | 3.3.4.4, Table 3-21, 3-22 | It is not clear why there is a need for both "UnrecognizedMessageSetResponse" and "InvalidMessageResponse" message data sets, nor why there is such a great difference in the information returned. It would seem that only one such message data set would be necessary, and that it should represent a union of the information presently contained in Table 3-21 and Table 3-22 (e.g., it's not clear why the "unrecognizedMessageSetInstance" in its entirety is returned in the "UnrecognizedMessageSetResponse", but not in the "InvalidMessageResponse". | Recommended | |
| "notifying management entity" | David Berry | | david.s.berry@jpl.nasa.gov | 3-27 | 3.3.4.3.5 | The phrase "Confirmation messages are used to notifying management entity that...". This sentence as written is a little confusing. "Notifying management entity" may be intended to say "notify management entity", but that doesn't make much sense either. Is this meant to be the UM? or CM? or both UM/CM? | Recommended | |
| "Peer Management Entity" | David Berry | | david.s.berry@jpl.nasa.gov | 3-26 | 3.3.4.3.4 | The term "peer management entity" is used here for the first time, and its meaning is not clear. Is this the UM? or the CM? or something else entirely? This is the only usage of this phrase in the document. | Recommended | |
| GRD-0043, GRD-0044 | David Berry | | david.s.berry@jpl.nasa.gov | 3-26 | 3.3.4.3.3.4 | What if the expectedDispositionTime rules specified by these 2 requirements cannot be met, and the CM expects the request to time out... do they just "fail" the request? | Recommended | |
| expectedDispositionTime | David Berry | | david.s.berry@jpl.nasa.gov | 3-26 | 3.3.4.3.3.4, Table 3-15 | It is not clear how one might designate an "unknown" expectedDispositionTime, since the field is supposed to be a UTC value. May wish to define a specific UTC value that is operationally defined as "unknown".
Related question... is this field supposed to be filled by automation? or by human intervention? or both? If automation, what factors are used in deciding the expectedDispositionTime? | Recommended | |
| Unnecessary Complication | David Berry | | david.s.berry@jpl.nasa.gov | 3-25 | 3.3.4.3.3.4, Table 3-14 | It is not clear why there is a need for "messagePrivateAnnotation" and "privateAnnotation" in this data set. What is unique about the contents of these 2 seemingly redundant data areas? | Recommended | |
| Recommended Revision to Requirement | David Berry | | david.s.berry@jpl.nasa.gov | 3-23 | 3.3.4.3.3.3.2, Table 3-11 | As noted in a prior RID, the "FailedReturn" and "FailedReturnWithDenial" are redundant. The "FailedReturnWithDenial" should be removed, and the text of GRD-0031 should be placed into the text section of GRD-0021, specifically, the "FailedReturn" message stereotype would then contain one or more <<Error>> data sets or one <<Denial>> data set. | Recommended | |
| Unnecessary Requirement | David Berry | | david.s.berry@jpl.nasa.gov | 3-23 | 3.3.4.3.3.3.2, Table 3-11 | As noted in a prior RID, there is no clear need for both "additionalInformation" and "privateAnnotation" in the <<Error>> Stereotype data set. If the "privateAnnotation" is removed, then the GRD-0025 is an unnecessary requirement. | Recommended | |
| Unnecessary Complication | David Berry | | david.s.berry@jpl.nasa.gov | 3-23 | 3.3.4.3.3.3.2, Table 3-10 | It is not clear why there is a need for both "additionalInformation" and "privateAnnotation" in the <<Error>> stereotype data set. | Recommended | |
| Minor Typo | David Berry | | david.s.berry@jpl.nasa.gov | 3-22 | 3.3.4.3.3.3.2 | From: "For that reason, the diagnostic parameter is defined as an instances..."
To: "For that reason, the diagnostic parameter is defined as an instance..." | Editorial | |
| Seemingly Unnecessary Complication | David Berry@jpl.nasa.gov | | david.s.berry@jpl.nasa.gov | 3-21 | 3.3.4.3.3.2, Figure 3-10 | This figure shows the class diagram of Return Stereotype Messages. There is no clear reason why there is a need for both the "FailedReturn" and "FailedReturnWithDenial" message stereotypes. This seems to be an unnecessary complication in an already complicated document. I think the "FailedReturnWithDenial" message stereotype could be removed with no great loss. Then the "FailedReturn" steretype would reference the <<Error>> data set xor the <<Denial>> data set, and things woud be much clearer. Further support for this notion is found in 3.3.4.3.3.3.3 where it is noted that "The contents of the <<FailedReturnWithDenial>> message stereotype dataset are identical to the contents of the <<FailedReturn>> message stereotype data set.". KISS. | Recommended | |
| Missing Reference | Reid Thomas | | snrthomas@earthlink.net | 2-6 | 2.2.3.1 g) | From: "... SLE Service Management Service Specification (see section ;"
To: "... SLE Service Management Service Specification (see section [appropriate section number]" | Editorial | |
| "urgentFlag" and its values | David Berry | | david.s.berry | 3-20 | 3.3.4.3.2, Table 3-5 | The name of the flag "urgentFlag" with the values "urgent" and "routine" seems confusing.
If the flag is named "urgentFlag", the values should be simply "Yes" or "No".
If the values are "urgent" and "routine", then perhaps the parameter name should be "priorityFlag" or something like that.
An urgentFlag setting of "routine" seems contradictory. | Recommended | |
| Misleading use of the word "Each" | David Berry | | david.s.berry@jpl.nasa.gov | 3-18 | 3.3.4.2.3, Table 3-4 | There are 3 requirements in the referenced table (MSD-0006, MSD-0007, MSD-0008) that begin with the word "each" (e.g., "Each Return message contained in a SleSmMessageSet..."). The word each in this case implies the potential that there is more than one such message in the SleSmMessageSet. However, MSD-0004 restricts the number of Return, Notification, and Confirmation messages to one per SleSmMessageSet.
From: "Each..."
To: "The..." or "A..." | Recommended | |
| Hyphens in "Parameter Names" | David Berry | | david.s.berry@jpl.nasa.gov | 3-17 | 3.3.4.2.2, Table 3-3 | Table 3-3 has a column on the far left called "Parameter Names". In general I observe that parameter names (and the names of most constructs in the document) do not have hyphens. However the parameter names in this table have hyphens, presumably for reasons of conserving space. If the hyphens are going to remain, there should be a statement in the section 1.8 "Conventions" that indicates that the hyphens in certain tables are not truly part of the parameter names. The way the table is currently constructed could lead to application errors between exchange parties. | Recommended | |
| MPR-0013 | David Berry | | david.s.berry@jpl.nasa.gov | 3-16 | 3.3.3.2Table 3-2 | The requirement states that "The Receiver should increment the messageSequenceNumber values of InvalidMessageResponses...". This seems to contradict the statement in Note 3 in section 3.3.2.3, page 3-7. | Recommended | |
| Requirement MPR-0002 | David S. Berry | | david.s.berry@jpl.nasa.gov | 3.15 | 3.3.3.2, Table 3-2 | From: "...UnrecognizedMessage-SetResponse"
To: "...UnrecognizedMessageSetResponse"
The requirement as written implies that there is a dash in the name of the message type. | Editorial | |
| Typo | David Berry | | david.s.berry@jpl.nasa.gov | 3-8 | 3.3.2.4.2, "Syntactic Validation" | From: "...has not further obligation..."
To: "...has no further obligation..." | Editorial | |
| Sender & Receiver mixups... | David Berry | | david.s.berry@jpl.nasa.gov | 3-8 | 3.3.2.4.1 | This section requires a note to explain that the Sender is really the Receiver of an original message. Maybe could be clearer if the "Invoker"/"Performer" terminology is used here, as is used later in section 3. | Editorial | |
| Why? | David Berry | | david.s.berry@jpl.nasa.gov | 3-7 | 3.3.2.3, paragraph "Verification of support for the invoked operation" | This paragraph states: "If the Receiver does not support the operation return or confirmation type of any received message, the Receiver shall ignore the unsupported-operation...".
Why is lack of support for returns, confirmations and notifications an option? This would seem to invalidate the 2-phase and 3-phase operation procedure models. | Editorial | |
| Typo (know => known) | David Berry | | david.s.berry@jpl.nasa.gov | 3-2 | 3.2, paragraph 2 | From: "...Source and Destination refer to the communicating entities as they are know to..."
To: "...Source and Destination refer to the communicating entities as they are known to..." | Editorial | |
| Typo | David Berry | | david.s.berry@jpl.nasa.gov | 3-1 | 3.1 | From: "Each SLE-SM operation procedure use..."
To: "Each SLE-SM operation procedure uses..." | Editorial | |
| Possible Attack Scenario | David Berr | | david.s.berry@jpl.nasa.gov | 2-31 | 2.6.3 | This section states that "...compromise of the SLE-SM services does not allow an attacker to directly attack the spacecraft." I would like to suggest that the compromise of a Forward Spacelink Carrier Profile, which contains the EIRP to use, could allow an attacker to damage communications equipment that is onboard the spacecraft if the EIRP in a carrier profile is changed such that it is in excess of that which the spacecraft receiver can sustain. | Recommended | |
| Use SLE SM Terminology (?) | David Berry | | david.s.berry@jpl.nasa.gov | 2-31 | 2.6.2.7 | From: "...between the spaceflight mission and the service provider."
To: "...between the UM and CM." | Editorial | |
| Wrong Word | David Berry | | david.s.berry@jpl.nasa.gov | 2-31 | 2.6.2.5 | The last word in the section is "enmities", but should probably be "entities". | Editorial | |
| Undecipherable Sentence | David Berry | | david.s.berry@jpl.nasa.gov | 2-31 | 2.6.2.5 | The intent of this sentence is not clear:
"In addition, each individual Service Package, Carrier Profile, Event Profile, and Trajectory Prediction has associated with it sleSmCreatorName of the message set that contained to invocation that created that information entity in the first place."
I *think* what is meant is:
"In addition, each individual Service Package, Carrier Profile, Event Profile, and Trajectory Prediction has associated with it the sleSmCreatorName of the message set that contained the invocation that created that information entity in the first place."
Addition of "the" in a couple of places makes the sentence clearer, assuming this is what was meant. | Editorial | |
| RSP Should be added to minimal specification compliance | David Berry | | david.s.berry@jpl.nasa.gov | 2-28 | 2.4, Table 2-1 | The RSP operation is currently shown with "N" in the columns for minimal compliance. However, it should be added to the minimal set (i.e., change "N" to "Y" for the RSP operation). This is because if a service package is created (CSP #1), then resources will be allocated to it. If one needs to change parameters in the service package, it is necessary to delete (DSP) the service package and then create a new one (CSP #2). In between the time of the DSP and CSP #2, the resources that had been allocated to CSP #1 may be allocated to a different service package. This is undesirable. | Recommended | |
| Section Boundaries in Table 2-1 Not Clear | David S. Berry | | david.s.berry@jpl.nasa.gov | 2-28 | 2.4, Table 2-1 | Under the "Service" column in Table 2-1, there are several services listed, however, because there are no grid lines in the table, the boundaries between the services are difficult to discern. Either grid lines should be added to the table, or the names of the various services should be aligned in the table with the first Operation associated with the Service. | Editorial | |
| Overly Restrictive Constraint on CM | David Berry | | david.s.berry@jpl.nasa.gov | 2-25 | 2.3.1.7 | This paragraph states that "No Service Agreement operations can be invoked by CM.". This seems overly restrictive. The CM should be able to QUERY the service agreement within the scope of the application. I don't see why this is restricted. | Recommended | |
| Incorrect NOTE | David Berry | | david.s.berry | 2-24 | 2.3.1.4(a) | The note after the text in 2.3.1.4(a) states "Submission of trajectory data occurs on the order of months to days in advance of the support period to which the trajectory data applies.".
This is not strictly true, as there are many occasions in which trajectory data are supplied on a much more "just in time" basis, e.g., launch supports, aerobraking campaigns, orbit insertion and other planetary encounters, maneuvers, etc. | Technical Fact | |
| Overly Restrictive Specification on CM | David S. Berry | | david.s.berry@jpl.nasa.gov | 2-23 | 2.3.1.3 | This section states that "No Configuration Profile operations may be invoked by CM.". However, this seems overly restrictive. It seems that CM might be interested in *at least* the "QUERY" operations. This way it would not be necessary to perform such operations outside the CM application that instantiates the SLE-SM specification.
For database management reasons, it may also be advisable for the CM to be able to ADD or DELETE profiles too. | Recommended | |
| Minor Typos | David Berry | | david.s.berry@jpl.nasa.gov | 2-17 | 2.2.7 | In 2.2.7(c):
From: "pace link"
To: "space link"
In 2.2.7(f), last sentence
From: "... service instance requests on turn..."
To: "... service instance requests in turn..." | Editorial | |
| Alternate Scenario Reservation | David Berry | | david.s.berry@jpl.nasa.gov | 2-15 | 2.2.6.1 (c) and (d) | "Alternate Scenario Reservation" appears to be a feature of the SLE-SM, yet this phrase only occurs twice in this document (in these 2 paragraphs). It would seem that if this is truly a feature, it would be described a bit more. Without such a description, different people could derive different interpretations of what such a feature would entail. | Recommended | |
| Clarification of Responsibilities | David Berry | | david.s.berry@jpl.nasa.gov | 2-13 | 2.2.5.1 | In Figure 2-6, there is an implication that UM must provide the "Storage space remaining for trajectory predictions", when this is clearly something that can be better managed by the CM.
May wish to postfix "(UM)" and "(CM)" behind the information in the figure to clarify where the responsibility lies, specifically, the first 2 are "UM" and the last is "CM". | Recommended | |
| Misspelled word | David Berry | | david.s.berry@jpl.nasa.gov | 2-12 | 2.2.4.2 | From: "Fore each return symbol stream..."
To: "For each return symbol stream..." | Editorial | |
| Add info that subcarrier may not be present | David Berry | | david.s.berry@jpl.nasa.gov | 2-11 | 2.2.4.2 | On the lists of Forward and Return carriers, item (c) in both lists indicates subcarrier characteristics. May wish to add that the subcarrier information need not be present if the modulation is direct to the carrier. | Recommended | |
| Redundant Constraint | David Berry | | david.s.berry@jpl.nasa.gov | 2-9 | 2.2.3.3.3 (a) and (c) | It is not clear why (c) is not included in (a), e.g.:
From: "list of allowed Trajectory Prediction formats"
To" "list of allowed Trajectory Prediction formats, some of which may be bilateral".
Then you can delete (c) | Editorial | |
| Clarification on Configuration Profile Constraints | David Berry | | david.s.berry | 2-9 | 2.2.3.3.2 (a) and (b) | From: "Maximum number of Carrier Profiles that can reside at CM..."
To: "Maximum number of Carrier Profiles for the applicable mission that can reside at CM..."
Same suggestion for Event Sequence Profiles. | Editorial | |
| Should pre-define term "Service Scenario" | David Berry | | david.s.berry | 2-9 | 2.2.3.3.1 | The term "Service Scenario" is used here for the first time without prior definition that it has a special usage, and is a component of a Service Package. May wish to simply indicate that a Service Scenario is a component of a Service Pagkage in 1.3.1(d). | Editorial | |
| "producer" and "provider"? | David Berry | | david.s.berry@jpl.nasa.gov | 2-3 | 2.1.4, paragraph 2 | From: "The SLE Complex acts as the SLE transfer service provider..."
To: "The SLE Complex acts as the SLE transfer service producer and provider..."
Justification: just being the provider doesn't require execution of space link services. | Recommended | |
| Awkward and misleading sentence | David Berry | | david.s.berry@jpl.nasa.gov | 2-3 | 2.1.3(b) | From: "Provides RF, modulation, space link service, and space link extension transfer service configuration information"
To: "Provides configuration information for RF, modulation, space link service, and space link extension transfer service"
Justification: The sentence as written implies that UM provides RF, modulation, etc., which is not true. The intent of the sentence is not clear until you get to the very end, when you find that it's only configuration information. | Editorial | |
| New Explanation of Typographic Convention | David Berry | | david.s.berry@jpl.nasa.gov | 1-18 | 1.8.6 | There are some conventions used to convey shortened Names, e.g., "CreateServicePackageInvocation" can be abbreviated as "CSP-I". In these abbreviations, the "-" is part of the abbreviated name. However, in general, the Names in the document are either UpperCamelCase or lowerCamelCase strings with no hyphens. It is observed that in a number of tables in the document, for readability reasons, hyphens have been inserted in some of the Names (e.g., Table 3-7). In the section 1.8.6, it should perhaps be pointed out that the various Names (Message, Parameter, Operation, etc.) do NOT have hyphens, and that the ones in various tables are for readability only. | Recommended | |
| Misnamed Document Section | David Berry | | david.s.berry@jpl.nasa.gov | 1-6 | 1.7 | The section 1.7 is named "Definitions, Nomenclature, and Conventions". However, section 1.7 only covers "Definitions and Nomenclature". Section 1.8 is titled "Conventions", and deals with various conventions.
Recommendation: either rename 1.7 to "Definitions and Nomenclature" OR renumber 1.8 to be 1.7.3.
Since 1.8 is a large and relatively pivotal section in the early part of the document, perhaps the first recommendation is the best. | Recommended | |
| First Use Acronym Without Explanation | David Berry | | david.s.berry@jpl.nasa.gov | 1-4 | 1.3.5(h) | In subject paragraph, the acronym "CM" is used for the first time in the text without the explanation that it means "Complex Management". The explanation should be provided at the first use. | Recommended | |
| Cited Limitation Doesn't Seem to be a Limitation | David Berry | | david.s.berry@jpl.nasa.gov | 1-3 | 1.3.5 | Item (c) "Although sharing ground systems..." doesn't really seem to be a limitation, thus perhaps should be moved to a different section. | Editorial | |
| Missing Word | David Berry | | david.s.berry@jpl.nasa.gov | 1-1 | 1.2, paragraph 3 | From: "...MDOS, is actually..."
To: "...MDOS, it is actually..." | Editorial | |