[Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Yves.Doat at esa.int
Yves.Doat at esa.int
Mon Nov 8 13:59:14 EST 2010
Dear John,
Thanks for your answer. I will look into it and we may end up with different
structures depending on the operation.
I overlooked a meeting on the day I proposed and my next possible date would
be on the 23.11.2010. Please let me know if that would suit you.
So far nobody else responded.
I saw you sent me some additional RIDs and I will incorporate them in the
list. I started to work on the document and I also added a couple of RIDs so
far.
Best regards
Yves
From: "John Pietras" <john.pietras at gst.com>
To: <Yves.Doat at esa.int>
Cc: css-csts-bounces at mailman.ccsds.org, css-csts at mailman.ccsds.org, "Ray, Timothy J. \(GSFC-5830\)" <timothy.j.ray at nasa.gov>
Date: 03/11/2010 16:35
Subject: RE: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Sent by: css-csts-bounces at mailman.ccsds.org
Yves,
Please see my underlined comments embedded below. You mention "16.11" - are
you proposing a telecon on
16 November? I have a doctor apppointment on that day that I have already
delayed once. However, it does not
start until 11 am that day and so I could talk between 0800 and 1000
Washington time (1400 - 1600 European time),
if that would work.
Best regards,
John
-----Original Message-----
From: Yves.Doat at esa.int [mailto:Yves.Doat at esa.int]
Sent: Wednesday, November 03, 2010 8:18 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org; Ray,
Timothy J. (GSFC-5830)
Subject: RE: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Dear John,
1) We can extend the AbstractChoice to emcompass a VisbleString, e.g.
AbstractChoice ::= CHOICE
{ opaqueString [0] OCTET STRING
, text [1] VisibleString
, extendedData [2] EMBEDDED PDV
}
That definition would be more flexible to support the statement "It shall be
possible to use the procedure as is".
That's okay be me for the EXECUTE-DIRECTIVE dirctiveIdentifier, but do we
want this
VisibleString choice available for all AbstractChoice parameters (e.g., the
data parameters
of TRANSFER-DATA and PROCESS-DATA)?
Also, I'm not sure that we can say that the VisibleString option is "as is",
because the
procedure/service still has to resolve it to the VisibleString choice. In
fact, if you look under
the Behavior for the TRANSFER-DATA operation at the top of page 4-15, the
NOTE states:
" This procedure does not define the data parameter of the TRANSFER-DATA
operation and therefore this procedure cannot be used as is by a service." (a
similar note is in the PROCESS-DATA behavior).
I think this as-is statement for EXECUTE-DIRECTIVE is more trouble than it is
worth.
Alternatively, it doesn't seem so bad to keep just the opaqueString option -
any derived operation
can refine it to a VisibleString (or specific values of VisibleString), and
simple refinement
doesn't involve having to create a new extension type.
2) Link between identifier and qualifier values.
The link cannot be enforced by the syntax. i.e. the syntax does not prevent
to use of a value for the identifier and an incorrect value for the
qualifier. I do no see how to solve that.
We have to build the link by requirements, e.g.
The 'reset' identifier shall be used with a qualifier identifying the
data-sequence-counter.
The 'reset' identifier shall use a visible string format.
The data-sequence-counter shall be defined as an extension of the
parameter directiveQualifier of the EXECUTE-DIRECTIVE operation
supporting an integer.
If the directiveIdentifier is truly just an identifier and that all
ancillary data associated with it is embedded in the directiveQualifier, then
it seems like
using the extendedData option would just result in a list of null-valued
labels. E.g.,
DummyServiceMadeUpProcExecDirDirectiveIdExt ::= CHOICE
{ firstDirectiveId [0] NULL
, secondDirectiveId [1] NULL
, extendedDirId [2] EMBEDDED PDV
}
where the extendedDirId would also be limited to null-valued labels.
What would be the downside of simply declaring directiveIdentifier to be a
VisibleString,
and requiring that all identifiers be conveyed as visible string values?
3) Link between the identifier type and the qualifier type.
I don't think we want to force a link between the type of the identifier and
the type of the qualifier (e.g. if the identifier is of VisibleString type,
the qualifier may be extended for an integer).
I wasn't proposing that the type of the qualifier be linked to the type of
the identifier,
but that it be linked to the value of the identifier. To make a
possibly-absurd example, let's
say that we want an EXECUTE-DIRECTIVE operation that combines the reset
capability of the
Data Processing procedure with the parameter value-setting capability of the
SC-CSTS. The
extension type for the new Combo procedure EXECUTE-DIRECTIVE operation could
be:
DummyServiceComboExecDirDirectiveIdExt ::= CHOICE
{ reset [0] NextProcessDataIdentifier
, reconfigureParameters [1] SEQUENCE OF ReconfigParamRecord
, extensionActionType [2]
}
NextProcessDataIdentifier ::= DataSequenceCounter
ReconfigParamRecord ::= SEQUENCE
{ ParameterName VisibleString
; ParameterTypeAndValue TypeAndValue
}
In this case, directiveQualifier would be set to null because all of the
"qualifying" data is directly
associated with the directiveIdentifier. Note that this approach is different
from the one
described under (2) above, because there is complex structure to the
directiveIdentifier (whereas in (2)
the identifier is *only* and identifier). I'm not proposing that this is
better than keeping the
qualifier separate and linking it to the identifier via requirements - it is
simply how I interpreted the
Red-1 book.
4) Possible alternative syntax:
ExecuteDirectiveInvocation ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentifier AbstractChoice
, directiveQualifier CHOICE
{ octetString [0] OCTET STRING
, namedList [1] SEQUENCE OF
{ name PublishedName
, value TypeAndValue
}
, null [2] NULL
, extended [3] EMBEDDED PDV
}
, extensionParameter Extended
}
This syntax fulfil the requirement: use as is.
I think that this will work, too. I would like to test it by trying to apply
it to the SC-CSTS. Unfortunately,
I can't get to it immediately. I'll try to test it as soon as I can.
5) EMBEDDED PDV.
I agree with you and I will raise a RID to cover that comment: NASA-JVP-74.
We could further discuss and close that particular issue on the 16.11. Would
that be Ok for you?
If yes would anybody else be interested to join?
Best regards
Yves.
From: "John Pietras"
<john.pietras at gst.com>
To: <Yves.Doat at esa.int>, "Ray, Timothy J. (GSFC-5830)"
<timothy.j.ray at nasa.gov>
Cc:
css-csts at mailman.ccsds.org
Date: 02/11/2010
19:45
Subject: RE: [Css-csts] EXECUTE-DIRECTIVE Possible
redefinitions
Sent by:
css-csts-bounces at mailman.ccsds.org
Yves,
I tend to agree with your choice of option 2. I can use it in the Service
Control service, by setting directiveQualifier to null and extending the
directiveIdentifier to be a complex type that includes directive names and
context-specific values. (In effect, I'm using the idea of directiveQualifier
but making its type and value linked to the specific directiveIdentifier
value. I have to be able to do this because the directive IDs and their
"qualifiers" have to be defined externally in a published control parameter
list.)
Note that none of these three options support the statement made for the
directiveQualifier for the EXECUTE-DIRECTIVE operation of the Throw Event
procedure:
"It shall be possible to use the procedure as is (i.e., without extension)
using the
parameters:
a) directive-identifier defined as an ASCII string;
b) directive-qualifier defined as a list of parameter name and parameter
values."
That will have to be changed to (OCTET STRING. (Also, should the default
value for directive-identifier be OCTET STRING instead of ASCII string - that
is, the derived service/prcedure would still have to refine it?)
Using this option, for the EXECUTE-DIRECTIVE operation of the Data Processing
oepration, directiveIdentifier would be resolved as the extended choice and
extended with a type that has the value 'reset', and directiveQualifier would
be resolved as the extended choice extended as an integer value. This leads
to some questions about what values derived versions of EXECUTE-DIRECTIVE can
assign to directvieQualifier. The AbstractChoice type (I like your name
better than my "AbstractType")has embedded in its definition that once a
CHOICE is selected, all further derivations must follow that choice. That is,
if the OCTET STRING choice is selected, the most any derived
procedure/service can do is refine the contetn of that string. (If the
exended value is chosen and the extension type is defined to have a choce of
EMBEDDED PDV, then going down that branch still preserves a lot of
flexibility.) The directiveQualifier, defined as AbstractChoice, is therefore
subject tot his constraint.
On the other hand, it's not clear whether the directiveQualifier is intended
to be constrained in the same way. That is, as currently defined in your
option 2, there appears to be nothing to stop service XYZ from defining
directiveQualifier as an OCTET STRING, and then have service XYZ' (derived
from XYZ) define directiveQualifier as an extended type. Do we want to allow
this behavior, or should the definition of directiveQualifier alwas be bound
to its parent operation? (another example - if the parent operation sets it
to NULL, can a child operation set it to some non-null value?)
However, it seems that it has to have the same type of constraint in order to
make any sense. Using the Data Processing procedure example, a derived
EXECUTE-DIRECTIVE could add another dirctiveIdentifier and associated
diirectiveQualifier (unless prohibited by the Data Processing procedure,
which it is not). But it would still have to support the 'reset' identfier
and associated integer-valued qualifier. If the new identifier has its own
qualifier, that qualifier has to extend the list - that is, be added to the
integer value. So we need to put the right words into the specification.
Finally, in this new type definition and throughout the FW, we have instances
of "extended" components of type "Extended" in some cases and "EMBEDDED PDV"
in other cases. It would be nice if "embedded" were restricted to be of type
"Embedded" to minimize confusion, and come up with a new name for components
of type EMBEDDED PDV (e.g., "alternateType" or "newType"). I realize that
this would ripple throught the ASN.1, but I do think that it would help
readability.
Best regards,
John
-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org [
mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Yves.Doat at esa.int
Sent: Tuesday, November 02, 2010 11:42 AM
To: Ray, Timothy J. (GSFC-5830)
Cc: css-csts at mailman.ccsds.org
Subject: RE: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Dear Tim,
Thanks for your reply.
The AbstractType is introduced for operations (TRANSFER-DATA, PROCESS-DATA
and EXECUTE-DIRECTIVE) such that a procedure can use them without need for
extension. If we add the NULL capability, this will allow users to send any
of the three operations without data. In my view this would not make sense.
During the meeting, we agreed to the AbstractType as I have proposed it (See
NASA-JVP-16)
Reading it again last night I came to the conclusion that option 2 is my
preferred one as it gives the capability to send an EXECUTE-DIRECTIVE with an
identifier and set the qualifier to "null". This option gives the possibility
we need and is cleaner.
Option 1 is less appropriate as it would enforce a requirement stating "in
case the qualifier is not used, the service-provider shall send an empty
string". I think this would not be adequate.
Best regards
Yves
From: "Ray, Timothy J. (GSFC-5830)" <timothy.j.ray at nasa.gov>
To: "Yves.Doat at esa.int" <Yves.Doat at esa.int>,
"css-csts at mailman.ccsds.org" <css-csts at mailman.ccsds.org>
Date: 02/11/2010 16:29
Subject: RE: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Dear Yves,
I like option #1 because I can understand what is needed.
Do you think it might make sense to modify our AbstractType to add a third
choice as follows? I’m thinking that this may not be the only situation in
which the ‘user’ of AbstractType will want the option of ‘unused’.
AbstractType ::= CHOICE
{ unused
NULL
, opaqueString OCTET STRING
, extendedData EMBEDDED PDV
}
Or, create two classes of AbstractType as follows:
MandatoryAbstractType ::= CHOICE
{
opaqueString OCTET STRING
, extendedData EMBEDDED PDV
}
OptionalAbstractType ::= CHOICE
{ unused
NULL
, opaqueString OCTET STRING
, extendedData EMBEDDED PDV
}
Best regards,
Tim
From: css-csts-bounces at mailman.ccsds.org [
mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of Yves.Doat at esa.int
Sent: Monday, November 01, 2010 1:04 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] EXECUTE-DIRECTIVE Possible redefinitions
Dear all,
I know you are all back in your daily work and quite busy so I will do my
best to be short. My question is at the end of the mail.
I started to look at the EXECUTE-DIRECTIVE trying to answer the RID we
discussed last week,
RID references: NASA-JVP-15. NASA-JVP-16.
Our requirements:
1. Enure a procedure and/or a service using the operation to have the
possibility to use the operation withour extension.
2. Reuse the AbstractType (proposed definition as follows):
-- This type is used by operations allowing the procedures
-- using them to two possibilities for the definition of the data:
-- 1. opaqueString: direct use. No extension required
-- 2. extendedData: definition of a complex type using a constructed
syntax
AbstractChoice ::= CHOICE
{ opaqueString OCTET STRING
, extendedData EMBEDDED PDV
}
3. Link the the directive qualifier to the directive identifier.
Possible redefinitions
Option 1:
Exec-Dir
Pro’s: - reuse AbstractChoice
- simple
- if dir-qual is not required we add a requirement to
use an empty octet-string
Con’s: - mixture octet-string & extended is possible.
- does not link a given dir-qual to a given dir-id: dedicated
requirement in the text can solve that.
- in case dir-qualif is not required, it cannot be
mapped to a NULL value but to an empty Octet String.
ExecuteDirectiveInvocationOption1 ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentifier AbstractChoice
, directiveQualifier AbstractChoice --
qualifier of the directive identifier
, extensionParameter Extended
}
Option 2:
Exec-Dir same as option 1 but with a different dir-qualif definition
Pro’s: - reuse AbstractChoice
- simple
- if dir-qual is not required we add a requirement to
use an empty octet-string
Con’s: - mixture octet-string & extended is possible.
- does not link a given dir-qual to a given dir-id: dedicated
requirement in the text can solve that.
ExecuteDirectiveInvocationOption1 ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentifier AbstractChoice
, directiveQualifier CHOIDE -- qualifier of the
directive identifier
{ octetString [0] OCTET STRING
, null [1] NULL
, extended [2] EMBEDDED PDV
}
, extensionParameter Extended
}
Option 3:
Pro’s: - does not allows octet-string & extended mixture
Con’s: - more complex structure (but still workable)
- AbstractChoice not reused
- does not link a given dir-qual to a given dir-id. dedicated
requirement in the text can solve that.
ExecuteDirectiveInvocationOption2 ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, directiveIdentification CHOICE
( octetString [0]
SEQUENCE
{ directiveIdentifier OCTET
STRING
, directiveQualifier CHOICE
{ selected [0]
OCTET STRING
, unused [1]
NULL
}
}
, Extended [1] SEQUENCE
{ directiveIdentifier EMBEDDED
PDV
, directiveQualifier CHOICE
{ selected [0]
EMBEDDED PDV
, unused [1]
NULL
}
}
, extensionParameter Extended
}
Notes:
- None of the options ensure a proper link between the identifier and he
qualifier. We should be able to cover the link by appropriate requirements in
the text
- Option 1 is the simplest but may require more requirements for a proper
usage.
Could you please let me know from your opinion which option answers the best
our discussions from last week.
1. Option 1?
2. Option 2?
3. Option 3?
4. New option?
Best regards
Yves
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list