Edited: 7/2/2007 8:56 AM by Pietras John
SMWG: Possible SLE-SM Red-2 RID items
Item 1 - Do we need to explicilty state that an SR is sent as part of the perform operation Data Set Composition and Relationship Requirements
Posted: 9/24/2007 11:17 AM by Crowson Anthony

Sequence Preservation 

The Document Exchange Protocol does not require the underlying communication service to preserve sequence among messages. In principle, this provides the flexibility to use services such as email (SMTP). However, it does add some complication to the standard, without making it fully robust against out-of-sequence messages.

A special arrangement is made to allow multiple Invocations to be sent in a single SleSmMessageSet. This is meant to allow dependent Invocations to be processed in guaranteed order without waiting for confirmation of each one's execution before sending the next.

  • A requirement remains for invocation sequence numbers to be ascending between message sets. Thus a message set received ahead of sequence will be processed, but cause any message sets sent earlier, but delivered later, to be discarded (with InvalidMessageResponse exception).
  • There is no specification of how completely an invocation must be processed before the next invocation is started. If a three-phase operation is invoked, does the following invocation get processed only when its predecessor is successfully (or otherwise) performed? Or, say, as soon as it is validated? Suppose we have ASLSP-I, followed by RSP-I referencing the just-added SLSP. the the ASLSP would have to be fully complete, or else the RSP will fail. However, since ASLSP is 3-phase, it may take some time before it is fully performed. By then, the 3-phase routine timeout on the RSP will probably have expired if no RSP-AR has been sent.

I suggest either (a) requiring the underlying communication service to preserve sequence among messages, and removing the associated features from the standard; or (b) specifying more precisely the sequencing/interlocking of processing of multiple invocations, and removing the sequence check between invocations in separate message sets.

Posted: 3/10/2008 11:21 AM by Barkley Erik
10-Mar-08: AC to submit formal RID
Posted: 9/27/2007 12:00 PM by Barkley Erik
Subject: SMWG: Possible SLE-SM Red-2 RID items
 
Item 1 - Do we need to explicilty state that an SR is sent as part of the perform operation Data Set Composition and Relationship Requirements
 
Item 2 - Service Package states and PSP operation.  To be completely symmetric with the ability of UM to delete an acknowledged SP, the ability of CM to issue a cancel for a proposed SP should also be included.

Posted: 3/10/2008 11:28 AM by Barkley Erik
10-Mar-08:  Consensus appears to be that this is not strictly required.
Posted: 12/14/2007 9:01 PM by Barkley Erik
Item 2 - ANT-SR should return the complete service package so that UM may check that the trajectoryRef parameters are correct.
Posted: 3/10/2008 11:32 AM by Barkley Erik

10-Mar-08: No need for RID as UM has option of issuing QSP operation to confirm trajectory references.
From: Barkley Erik
Posted: Friday, December 14, 2007 6:01 PM
Subject: SMWG: Possible SLE-SM Red-2 RID items

Item 2 - ANT-SR should return the complete service package so that UM may check that the trajectoryRef parameters are correct.

From: Pietras John
Posted: Monday, July 02, 2007 5:56 AM
Subject: SMWG: Possible SLE-SM Red-2 RID items

Item 1 - Do we need to explicilty state that an SR is sent as part of the perform operation Data Set Composition and Relationship Requirements
Posted: 1/9/2008 2:46 PM by Pietras John


Subject: SMWG: Possible SLE-SM Red-2 RID items: RSP-FR should be only failed return, not failed return with denial

The only DspDenial reason that currently exists is 'other'. Just make it a simple failed return (i.e., only diagnostics are returned).
Posted: 3/10/2008 11:36 AM by Barkley Erik
10-Mar-08: Agreed that this should be a RID. Dispostion likely to be removal of "extra" data set.
Posted: 1/9/2008 2:56 PM by Pietras John
Subject: SMWG: Possible SLE-SM Red-2 RID items: SAS-FR should be only failed return, not failed return with denial

The only SasDenial reason that currently exists is 'other'. Just make it a simple failed return (i.e., only diagnostics are returned).
Posted: 3/10/2008 11:43 AM by Barkley Erik
10-Mar-08:  Appears that there may be a larger issue of need to consider whether or not a service package is cancelled if all contingency scenarios are supported.  Alternatively could a CM issue an SPM indicate that a non-prime scenario is no longer supportable?  (Seems that idea of removing denial data set is not appropriate)
Posted: 2/6/2008 9:45 PM by Barkley Erik
Polarization in event sequencing is at the wrong "level".  It's parenting is at the level of data transport availability events.  In fact, polarization is a spacelink level parameter and as such should be parented in the spaclink available state.
Posted: 3/10/2008 11:44 AM by Barkley Erik
10-Mar-08: Agreed -- submit RID.
Posted: 2/13/2008 9:09 AM by Crowson Anthony

Carrier vs SLS Profiles

The Space Link Session profile consists of one or more carrier profiles. If a carrier profile is to be available in more than one SLS profile, it needs to be duplicated. For example,

  • SLS-A has downlink carrier profile 1 and uplink carrier profile 1
  • SLS-B has downlink carrier profile 2 and uplink carrier profile 1

The alternative is to include all carrier profiles that might be combined into a single SLS profile, and use events profiles to select - this appears unwieldy. 

It would seem sensible to allow the carrier profiles to be manipulated separately. The SLS profile would then either (a) consist of a set of references to carrier profiles; or (b) disappear, in which case each existing SLS profile reference would need to be replaced with a set of references to carrier profiles. Option (a) is probably conceptually still useful, to reference known groups of carrier profiles; option (b) requires fewer config profile services and is more flexible.

Edited: 2/13/2008 10:24 AM by Pietras John

We appear to be coming full circle. What we had in Red-1 was essentially option (b), but requiring the individual carriers to be specified in the CSP-I/RSP-I was burdensome to multiple potential users, and I submitted a RID. My original proposal was essentially option (a). In discussing it in Rome, the SMWG decided that the two-tiered layering of individually-specified carrier-related profiles was undesirable, and opted for the single SLS Profiles that contained the carrier profiles, even though it was recognized that the potential for redundancy existed. If I recall correctly, part of the argument for the redundancy not being an issue practically was the expectation that users easily develop tools that would allow cut-and-paste of carrier profile definitions (e.g., complex elements of an XML SLE Profile instance document) from one SLE Profile to another.

We need to retain the capability to reference a single high-level profile (i.e., the SLSP) in the CSP and RSP, so option (b) is not viable. If we want to reopen the issue of specifying the carrier profiles independently of the SLS Profiles, we can do that, but I just want to point out that we have been here before.


From: Crowson Anthony
Posted: Wednesday, February 13, 2008 6:09 AM
Subject: SMWG: Possible SLE-SM Red-2 RID items

Carrier vs SLS Profiles

The Space Link Session profile consists of one or more carrier profiles. If a carrier profile is to be available in more than one SLS profile, it needs to be duplicated. For example,

  • SLS-A has downlink carrier profile 1 and uplink carrier profile 1
  • SLS-B has downlink carrier profile 2 and uplink carrier profile 1

The alternative is to include all carrier profiles that might be combined into a single SLS profile, and use events profiles to select - this appears unwieldy. 

It would seem sensible to allow the carrier profiles to be manipulated separately. The SLS profile would then either (a) consist of a set of references to carrier profiles; or (b) disappear, in which case each existing SLS profile reference would need to be replaced with a set of references to carrier profiles. Option (a) is probably conceptually still useful, to reference known groups of carrier profiles; option (b) requires fewer config profile services and is more flexible.

Posted: 2/18/2008 1:08 PM by Crowson Anthony
In that case, I suggest we leave well alone unless it comes up separately from the agency review.
Posted: 3/10/2008 11:46 AM by Barkley Erik
10-Mar-08:  No RID needed.
Posted: 2/18/2008 1:35 PM by Crowson Anthony

Ambiguity in returns

An invocation is uniquely identified by messageSequenceNumber, sleSmCreatorName, and the service agreement referenced in the containing . However, return messages do not identify the sleSmCreatorName of the invocation they respond to. Depending on implementation details, it may be possible (if unlikely) for a management entity to have outstanding invocations of the same type from more than one creator but using the same messageSequenceNumber, and therefore to be unable to correlate the return unambiguously with the invocation.

While  this would not happen if the different creators are using independent communication channels, I believe that there is nothing in the spec which would rule out the possibility.

Recommendation: add invocationMessageSleSmCreatorName to the <<Return>> stereotype. For consistency, do the same with notification/confirmation, although a scenario where different entities send parallel notifications seems even less likely.

Posted: 3/10/2008 11:56 AM by Barkley Erik
10-Mar-08:  this may already be adequately addressed in the recommendation.
 
Action: JVP to verify if further action required.
Posted: 2/29/2008 11:18 AM by Pietras John


Subject: SMWG: Possible SLE-SM Red-2 RID items: Revisit Red-1 RID Vega-07

Red-1 RID Vega-07 asks for a capability to "give me whatever is available" in scheduling, rather than being required to completely specify all parameter values. The RID was closed with the disposition that a suitable capability is present in the ability to submit multiple scenarios. However, we've never received confirmation that this would meet the stated need. We should confer with Martin Pilgram at the Crystal City meeting to confirm this.
Posted: 3/10/2008 12:08 PM by Barkley Erik
10-Mar-08:  No RID needed for this as alternate scenario mechansim already addresses this.
Posted: 3/10/2008 11:01 AM by Barkley Erik
10-Mar-08: JVP please re-state, determine need for RID.