[Css-csts] Revised Forward Procedures for integration into the Framework

[John Pietras]

Wolfgang,
Below are my responses to those items that were not obviously closed in your email of last week. Deleted paragraphs (e.g., paragraphs related to comments that are closed with no remaining issues) are marked with ellipses (...).

Best regards,
John


...

B. BUFFERED DATA PROCESSING PROCEDURE
1.		 Section 1.1.2.1 (Purpose), last paragraph: This paragraph
doesn't really address the purpose of the procedure. Also, is the list of ways that transfer mode is selected intended to be exhaustive or merely representative? I suggest dropping this paragraph in section 1.1.2.1, and making any statements regarding  how the mode is to be specified in section 1.1.4.2.2.

WH: I agree that the last paragraph of section 1.1.2.1. should be placed elsewhere, but we do not move it to 1.1.4.2.2, as we have the formal requirement addressing this point in 1.1.4.2.2.2. I still think that it is useful to tell the reader early on that when specifying a service using this procedure one will have to decide on the mechanism for the selection of the transfer mode. My inclination is to add the paragrph in question to the 'Concept' section and I have done so in V14 of the document. But I do not feel particularly strong about this and I am open to other suggestions.

JP: I think that moving the paragraph to the Concept is fine.

...


3.		 1.1.4.2.1 (Transfer Buffer): if the User submits only P-D invocations (that is, no buffer is used), is it necessary to specify a Transfer Buffer size?

WH: To keep things simple, I would think that the Transfer Buffer shall always be specified by the service using the Buffered Data Processing procedure. In case the service characteristics require the transfer of individual data units, the buffer size can be set to 1. I have not made any changes to the procedure with respect to this comment.

JP: Okay, I was just curious about it. Should there be a NOTE to the effect that the size must always be set even if it is not used, i.e., when the uses transfers unbuffered P-D invocations? I do not have a strong opinion on this - it really is just a question.

4.		 1.1.4.2.1.2: "Transfer Buffer size" sounds like a configuration parameter, and as such should use the convention for parameter names (e.g., transfer-buffer-size in Courier font).

WH: I agree that this will be a configuration parameter. However, in SLE we applied the fixed width font convention only to parameters being elements of the SLE operations.Shall we apply it in CSTS also to configuration parameters. I have not made any changes to the procedure with respect to this comment.

JP: At one the CSTS SFW used fixed-width fonts for at least some managed/configuration parameter names, and that's why I made the comment. But looking through the June version that usage seems to have been removed and it looks like fixed-width is once again reserved for in-operation parameters. However, in the BDPP itself, parameter-latency-limit (which is a configuration parameter) is expressed uses Courier font - that should probably be changed.

...

9.		 1.1.4.2.2.4: "maximum" in "maximum Transfer Buffer size" is
redundant, since Transfer Buffer size (transfer-buffer-size) is defined as the maximum possible value.

WH: I see your point. However, I prefer leaving the word maximum in as there is also the actual Transfer Buffer size when a new Buffer arrives. Using the word maximum stresses that the limit is addressed here and not the actual size of the incoming buffer. I have not changed the document with respect to this comment.

JP: If there is a danger of confusing the maximum transfer buffer size with the size of an instance of the transfer buffer, then perhaps the configuration parameter name should be "maximum Transfer Buffer size" and used whenever it is that size (and not the size of an instance of the TB) is being discussed.

...

C.  SEQUENCE-CONTROLLED DPP
1.		 1.1.2.2, third paragraph, and 1.1.4.2.3: These section
describe/require a behavior in which a P-D invocation with an out-of-sequence value in the data-sequence-counter parameter results in a rejection of the invocation. However, the SCDPP is derived from the DPP. Version 13 of which mandates that such a sequencing error result in a PEER-ABORT. NOTE that if the recommendation proposed above is adopted, the DPP would leave the behavior undefined so that the SCDPP could define it as it currently is (reject, not PEER-ABORT).

WH: The DPP uses the unconfirmed variant of the PROCESS-DATA operation and as a consequence, rejecting of the invocation is not possible and therefore the only possibility for dealing with an out-of-sequence invocation is the PEER-ABORT. The SCDPP extends the PROCESS-DATA operation by adding a return and with that in place we can reject an out-of-sequence invocation. Is your concern that such change is beyond what should be possible by means of extension? The BDPP needs to deal with the case of an out-of sequence PROCESS-DATA invocation as well and it does so in exactly the same way as DPP specifies. If we were to leave this aspect undefined in DPP, we would have to move that specification to BDPP. For now, I have not introduced any related change until we have a decision if DPP should be more abstract at the expense of adding the necessary specification to BDPP.

JP: My primary comments on this are included in the message that I sent earlier today. However, regarding the question about whether a derived procedure can replace the peer-abort  behavior with a less drastic one (e.g., rejection of the invocation): I suppose that it could be done, as long as the derived specification made it clear what behavior is being overridden. In particular, as currently written, the Behavior section of the SCDPP specifications states "The following behavior is specified in addition to the specifications for the parent procedure in <REF>." That implies that all previous behavior (including peer-aborting) is still in effect. The explicit overriding of behavior should be identified, e.g., "The following behavior is specified in addition to -or instead of -that specified for the parent procedure. Where the parent behavior is overridden, the overridden parent behavior is explicitly identified."