[Css-csts] Answer to Various Comments to draft 0.17
Yves.Doat at esa.int
Yves.Doat at esa.int
Sun Mar 8 03:54:54 EST 2009
Dear John,
I processed all your comments and hopefully I did not overlooked any. If
that is the case please let me know.
You will find below an answer to each of your comment. The document has
been updated accordingly.
Best regards
Yves
===============================
Mail 24.02.2009 -- Comments about Service Type Identifiers
Section D2.2 of the R-0.17 Framework defines the service type identifiers
for the CSTSes. I have a few comments about the content of this section.
I don?t believe that the individual service identifiers should be
documented in the Framework book. As the NOTE to the section itself points
out, the Framework would have to be updated to include new services. This
is really not the job of the Framework document, which is supposed to
define the Toolkit procedures.
One alternative is to have a distributed approach ? the CSTS Guidelines
require that the service type identifier be defined as part of the new
service specification. Thus any CSTS, if it is developed in conformance
with the guidelines, will have its service type identifier defined as part
of its specification. I can add material to the Guidelines requirements
specifying that the identifiers must be in the
CCSDS-CSTS-TRANSFER-SERVICE-SERVICE-TYPE-ID space.
The second alternative is to create a stand-alone Recommended Standard the
just contains the service type identifiers. It will be easier to update
this document every time a new CSTS is defined than it would be to put the
whole Framework into the Pink Sheet process. However, I personally don?t
see the need for such a stand-alone specification ? I believe that
defining the type identifiers as part of the CSTS Service Specification is
sufficient.
If there is some desire to ?bookmark? the service instance identifiers of
CSTSes that are planned for the future (e.g.,rtnSpacePkt), this could be
done in an Annex of the Concept book.
YD Answer:
Considering that most of the object identifier are defined and reused in
the Recommendation, I want to keep the Object Identifier tree in that book
(See Appendix H of draft 0.17 or appendix I of draft 0.18). You comment
refers to one branch of the Object Identifier and clearly I can remove it.
The branch containing the application-identifier should be easy to update.
we have to discuss and may be address SANA on the best way to maintain the
registration.
I do not have a problem to remove the list of services which are copied
from SLE (apart from cstsMonitoring and cstsRadiometric). I will send a
mail to Secretariat to address the issue and ask if they can offer a
solution. In the mean time I will remove the list from the book.
Changes:
1. Section D.2.2: I removed the services OIDs
2. Figure H-1 (I-1 in draft 0.18): I removed the branch defining the
services.
?space-link-extension (3)? should not be part of any CSTS object
identifiers. For example, the CCSDS-CSTS-TRANSFER-SERVICE-SERVICE-TYPE-ID
should be {iso identified-organization (3)
standards-producing-organization(112) ccsds(4) csts (2) framework (1)
modules(1) service-type(2) ({iso 3 112 4 2 1 1 2}) instead of {iso
identified-organization (3) standards-producing-organization(112) ccsds(4)
space-link-extension(3) csts (2) framework (1)modules(1) service-type(2)
({iso 3 112 4 3 2 1 1 2}).
YD Answer: You are right I corrected the object identifiers for all
modules
If the service type identifiers *do* remain in the Framework specification
or moved to a stand-alone document, the list should not include serviced
type identifiers for the existing SLE transfer services. The SLE services
do not use these service type identifiers in their BIND operations
(rather, they use integer-valued ApplicationIdentifiers). The SLE transfer
services do not conform to the Framework procedures and to include them in
the Framework specification is misleading.
YD answer: As you proposed above, the definition in the Framework should
not list all possible services, but rather leave it open for use when a
new service is defined. I will only keep the tree in Annex H (Annex I in
draft 0.18) as information.
Are the object identifiers within a module supposed to be extensions of
the object identifiers of the modules themselves? If so, then there are
differences throughout the ASN.1. For example, the OID for the Service
Type ID module is {iso 3 112 4 3 2 1 1 2}, but the OID of the
cstsMonitoring service type ID is {iso 3 112 4 3 2 2 19}. That is, they
match through the ?csts? element but diverge after that.
YD Answer: No the OID of a module are not related to the OID defined in
the module. If you look at the tree representation (last appendix of the
book) you will see that the modules are a branch in their own.
Finally, an editorial note ? there is a lot of redundancy in the ASN.1
module names, which all begin with ?CCSDS-CSTS-TRANSFER-SERVICE?. Since
the ?TS? in ?CSTS? stands for ?Transfer Service?, these names could be
shortened or changed to ?CCSDS-CSTS-?? or
?CCSDS-CROSS-SUPPORT-TRANSFER-SERVICE-?? This is not a major issue.
YD answer: I agree and changed the text as you suggested.
========================================================================================
Mail 23.02.2008 -- Questions about the Notification Procedure
What is the purpose of the empty string described in 4.10.3.2.1.1? Is it
to add new notification types, or is it to allow additional information to
be added about an existing or new notification-type? I tried to look at
the corresponding ASN.1, but I could not see anything that looks like the
empty string described under the NOTIFICATION procedure. I am also
confused about how the IndividualEventNames type is supposed to work.
Please pardon my ignorance of these features of ASN.1. could you please
provide a simple example of how one would use these specifications to add
a new event, ?antennaFellOver?, accompanied by additional information
describing the direction that it fell over?
-------------------------
Obviously my text is cryptic and I reworked it. Here is the revised text
of section 4.10.3.2.1.1 and the corresponding ASN.1.
4.10.3.2.1.1.Extension notification-type values
The service using this procedure may define new event names that will be
transferred using the following mechanism:.
a. event name: extension of the notification-type parameter with an empty
string definition.
b. event value: allows the new notification to carry additional
information to the event name using an empty string extension that may
ASN.1:
NotifyInvocation ::= SEQUENCE
{ standardInvocationHeader StandardInvocationHeader
, eventTime Time
, notificationType NotificationTypes
, extensionParameter Extended
}
.....
-- ***********************************************************
-- NOTIFY invocation extension of the notificationExtension (see
-- 4.10.3.2.1.1) of the NotificationType parameter (see annex D2.5) to be
-- used for service specific events:
NotificationTypeExtension ::= SEQUENCE
{ eventName VisibleString
, eventValue VisibleString
}
Example for a new event: "antennaFellOver".
I use the NotifyInvocation:
1. standardInvocationHeader : filled with appropriate values;
2. eventTime : time of the event
3. notificationType : I select notificationExtension [4]
Extended
I fill the extension with
NotificationTypeExtension :
eventName =
"antennaFellOver" and
eventValue = ""
========================================================================================
Mail 18.02.2009 --- Max number of list-of-events names not identified as
managed
Under the NOTIFICATION procedure, the diagnostic values for the START
operation have an extended value ?maximum number exceeded?. However, I
can?t find a statement as to what this maximum number is, and I think that
it?s intended to be managed. If so, there should be a numbered paragraph
that identifies the maximum number as a managed parameter. Also, if you
agree with my suggestion (in an earlier email) to put all of these managed
parameters in a table, The managed parameter could be name
max-number-of-event-names.
-------------------------
You are right, so I will add:
1. Requirement 4.10.2.2.2 The Service User supports a maximum number of
notifiable events (max-number-of-events) defined by management
2. A non-normative appendix (Annex F - Procedures Management) grouping the
parameters to be managed. The parameters will be ordered by procedures.
========================================================================================
Mail 18.02.2009 ---
- In Section 4.7.3.1.2, the sentence should read ?Table 4?22 shows the
use of the extension parameters of the START operation defined by this
procedure? (not NOTIFY).
YD answer: corrected
- Section 4.7.3.1.2.3.2 states ?The delivery cycle range and the maximum
number of parameters shall be defined by service management?, but then
section 4.7.3.1.2.3.2 states ?The delivery cycle to be supported shall be
1 second minimum and 65535 seconds maximum.? This second statement seems
to override service management?s role in setting the delivery cycle range.
Should 4.7.3.1.2.3.2 simply read ?The delivery cycle range and the maximum
number of parameters shall be defined by service management??
YD answer: One requirement defines the min and max range supported. The
other refers to the maximum number of parameters supported and the cyclic
range that needs to be supported by the provider.
In thinking about parameter values and constraints set by service
management, I think that it would be a good idea to establish a table of
managed parameters, similar to Table 3.1 in the various SLE service
specifications. As the Framework currently exists, one has to hunt around
to be sure that all managed parameters have been found. As Wolfgang and I
found out in Berlin, there were a number of managed parameters that were
buried in the text of the SLE specifications that had not been included in
Table 3.1, even after almost 10 years and multiple revisions, so it?s easy
to overlook some managed parameters. I?m thinking of a table with columns
like managed parameter name, procedure, operation, and reference. Using
the example of the maximum number of parameters in the list-of-parameters,
the entry would look like:
Parameter Name Procedure Operation Reference
max-number-of-parameters Cyclic Report START
4.7.3.1.2.3.2
It could be put in an annex so as not to interrupt the current
organization of the Framework. What do you think?
YD answer: A non-normative appendix (Annex F - Procedures Management)
grouping the parameters to be managed. The parameters will be ordered by
procedures.
========================================================================================
Mail 18.02.2009 --- credentials creation specified by ISP-1
The Notes under 3.3.2.2 and 3.3.2.3 of the Framework (v0.17) state ?The
definition of the required values to compute the
invoker[performer]-credentials is under the responsibility of service
management?. However, the specification of the computation of these
credentials is actually specified in ISP-1. These two Notes should be
replaced with normative statements referencing ISP-1 as the controlling
document for the formation of the credentials parameter values
YD answer: Notes updated to read "The definition of the required values to
compute the xxx-credentials is specified in [9]".
========================================================================================
Mail 17.02.2009 --- A few more corrections for Fremework R0.17
In section 1.5.2, item (d) is called Cross Support Transfer Service?Part
1: Procedures Definition instead of its current name (Cross Support
Transfer Services Specification Framework).
Also, item (e) is called Cross Support Transfer Service?Part 2: Guidelines
. I don?t think we should call it ?part 2? if we are no longer calling the
Framework part 1. I have been calling it Guidelines for Specification of
Cross Support Transfer Services, which I think is a little more
informative than Cross Support Transfer Services Guidelines, but I can
change it to that simpler name if you wish. Whatever name we decide to
use, we should be consistent in the various Cross Support Service
Documentation sections.
YD answer: References updated as proposed.
========================================================================================
Mail 17.02.2009 --- PEER-ABORT table missing Standard Operation Header
parameter
In Framework R-0.17, table 3-5, PEER-ABORT Operation Parameters, is
missing a Standard Operation Header (unconfirmed) row.
Also, for consistency and clarity, the Standard Operation Header row in
Table 3-8, TRANSFER-DATA operation, should probably be ?Standard Operation
Header (unconfirmed)?.
YD answer: The PEER-ABORT does not have any standard operation header as
its length may be limited to a few octet (in case urgency is used).
table 3-8 updated
========================================================================================
Mail 04.02.2009 --- response to BIND invocation when already bound
Wolfgang,
Thank you very much for your clarification. The reason that this issue
popped up for me is that it just came up recently in the context of the
Framework Association Control procedure/BIND operation. In last summer's
CSTSWG telecon, the WG decided to change the peer-abort in the state table
to -BindReturn to be consistent with the SLE books. We apparently
collectively forgot the difference between the two cases when we made
this decision. Looking at the Concept and Behavior sections for the
Association Control procedure in the latest Framework draft (R-0.17), I
see that we don't have any text equivalent to sections 4.2.1.5 of the SLE
books.
I suggest that we do the following in the Framework Association Control
section:
- In the Binding section (currently 4.3.3.1.2), insert the following new
paragraph after 4.3.3.1.2.1:
"If a BIND invocation is received from a Service User for a service
instance that is already bound to another Service User, it shall be
rejected with a BIND return with the result parameter set to 'negativ
result' and the diagnostic parameter set to 'already bound'. This event
shall not affect the association already in place."
- In "Procedure State Table (Service Provider Side)" section (currently
4.3.5), add the following sentence:
"The state transition matrix specified in table 4-2 represents one
instance of the Association Control procedure. Since there is one and only
one instance of the Association Control procedure for each instance of a
CSTS, the state table thus represents the single association for that
CSTS."
- In the (BindInvocation) row, define the State-2 action as:
(PeerAbortInvocation 'protocol error')
terminate
->1
YD answer: Text updated with proposed phrasing.
========================================================================================
Mail 26.01.2009 --- 'positive result' predicate missing from Predicate
Descriptions table for Association Control
The predicate ?positive result? is missing from table 4-4 in Framework
0.17.
YD answer: Added
========================================================================================
Mail 26.01.2009 --- Ambiguous diagnostic for BIND attempt after UNBIND
with 'end'
The definition of the unbind-reason for the UNBIND operation includes the
following NOTE:
?NOTE ? If unbind-reason is ?end?, any subsequent attempt to invoke BIND
will fail even if the service instance provision period has not expired,
since the Service Provider may release the resources allocated to that
service instance. ?
It is not obvious which diagnostic for the BIND operation covers this
case, if any. I suggest adding the following diagnostic value:
?service instance ended? ? The requested service instance has been ended
and the associated resources have been released.
YD answer: Your proposal makes sense, I added the proposed diagnostic and
updated the ASN.1.
========================================================================================
Mail 26.01.2009 --- ambiguous UNBIND operation requirements for duplicate
invoke-ID
In Framework R-0.17, the definition of the UNBIND operation includes the
following NOTE under paragraph 3.5.1.2:
?NOTE ? The unbind invocation cannot be rejected. In case the unbind
invocation cannot be accepted, the Service Provider can only issue a
peer-abort (see 4.2.1.9).?
By definition, the note is informative. However, under the normative
definition of the table content there is no mention of this. Rather, table
3-4 states that the UNBIND inherits the Standard Operation Header
(confirmed). This standard header allows the result to be either ?positive
result? or ?negative result? and includes the conditional diagnostic
parameter. Normatively, if the UNBIND is issued with a duplicated
invoke-ID, an UNBIND negative return should be returned with diagnostic
value ?duplicate-Invoke-ID?, not a peer-abort.
If the intention is to peer-abort, then the normative definition needs to
be changed for the UNBIND. Specifically, the result parameter must be
restricted to ?positive result? and the diagnostic parameter must be
disallowed.
Note, too, that the reference to 4.2.1.9 in the NOTE cited above no
longer seems applicable.
YD answer: The working-group agreed to keep the same structure (i.e.
including the standard header) for all operations but the PEER-ABORT (due
to TCP restrictions). Strictly speaking, the UNBIND invocation can be
rejected. In one of the earlier version of the book, I introduced the
possibility to reject an UNBIND. This point was discussed during the
teleconference April 2008. The minutes of that teleconference clearly
state that the service provider always sends back a positive response. The
main issue is that if the Service Provider sends a negative response, the
states in the user and in the provider may not be aligned and we may end
up with an inconsistent situation. To avoid problems, I added the note. I
will remove the cross-reference which is incorrect.
This means that even in case of duplicate-invoke-id, the UNBIND cannot be
rejected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090308/44924ed7/attachment-0001.html
More information about the Css-csts
mailing list