[Sis-dtn] PID responses for BPV7

Tue Nov 15 15:08:02 UTC 2022

Keith,

Thank your for your e-mail.

From what I have seen in the updated draft and its comments, we can close 
PIDs SLS-01, -02, -03, -04, -05, -07, -08, -09, and -12,

For the remaining ones, please find additional feedback.

I believe PID SLS-06 has been missed, since I do not see any comment at 
the relevant paragraph (page 2-1, tenth paragraph) and the text remains as 
it was. It should be easy to fix.

PIDs SLS-10 and -11 go about anonymous bundles. I believe you have 
interpreted well my willingness to eliminate them on a space mission 
context. 
Perhaps you could explain what is the purpose of anonymous bundles and why 
they are needed on a space mission context. 
I could see a potential use for network security . Anonymity is a well 
sought security property for certain networks. An observer cannot 
determine who is talking to who. 
But I guess this is not the current motivation behind their tolerance in 
this standard. So I need some understanding here.
What are they good for? Anonymous for whom?

PID SLS-13 is about error indications at the service interface. In fact 
after reading your response I agree with you that, in contrast to those 
reported in Annex C3, they do not have interoperability meaning.
My reference to other protocols was pointing to the example of the 
Verification Status Code defined in the Space Link Protocols when 
implementing SDLS.
But clearly that one has interoperability meaning as well.
Hence, no need to define error codes at the service interface.
Therefore, we can close this one as well.

PID SLS-14 is about being more clear on the boundaries and the subject for 
the requirements provided in section 5.
The so-called "System" seemed to me undefined, too open to interpretation.
I wonder if what you are actually formulating in that section is a few key 
requirements for a Bundle Protocol node (implementation).
Note for instance the very clear and specific subject used in requirement 
5.1.1 (now 5.2.1): Bundle protocol node.
Note as well "Bundle protocol agent" in 5.2.1 (now 5.3.1). 
Stating requirements for the "bundle protocol" instead would not make much 
sense in my opinion.
They should have been an input from which this standard would have been 
derived.
So I think that if you identify the (active) subject for the requirements 
stated in that section and reflect it in the title, you will probably 
improve meaning.
For instance, what about Bundle Protocol Node (and/or Agent) Requirements?

Your thoughts?

Kind regards,

Ignacio

Ignacio Aguilar Sánchez
Communication Systems Engineer
Electrical Engineering Department

European Space Research and Technology Centre
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands
Tel. (31) 71 565 5695
Fax (31) 71 565 5418
Email: ignacio.aguilar.sanchez at esa.int
www.esa.int

From:   "Dr. Keith L Scott" <kscott at mitre.org>
To:     "Ignacio.Aguilar.Sanchez at esa.int" 
<Ignacio.Aguilar.Sanchez at esa.int>, "Blanding, Beau T. (MSFC-HP27)[HOSC 
SERVICES CONTRACT]" <beau.t.blanding at nasa.gov>, 
"sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Date:   14/11/2022 17:48
Subject:        PID responses for BPV7

Ignacio,

The sis-dtn working group has reviewed your PIDs on the draft BPv7 Red 
Book.

A spreadsheet with the dispositions as well as a marked-up document are 
available from the Google Drive Folder here:

https://drive.google.com/drive/folders/1q1bS7VfNsLfh55GwKvy6Eza_Q1FoU4Kn?usp=share_link

And I can send you snapshots if that’s difficult to access.

Can you let me know if you agree with the dispositions and/or if you have 
some time to discuss them?  I think the largest thing that we’d like to 
NOT do is to add a list of error indications at the service interface, 
which is slightly (maybe) qualitatively different from the error 
indications listed in annex C in that the service interface is entirely 
local and implementation-dependent.  We could probably add such a list of 
suggested error indications in a non-normative note or discussion section, 
but I’d prefer to add it to the list of material to put into a revised DTN 
rationale Green Book.

                                v/r,

                                --keith

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221115/852c1464/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1155 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221115/852c1464/attachment.gif>