[Sis-dtn] [EXT] Re: PID responses for BPV7

Tue Nov 15 16:06:32 UTC 2022

Ignacio,

-06
My sincere apologies for missing -06, will get on that.  Ah, OK, I copied your ‘from’ text…

Anonymous bundles:
I think we need to support the concept of dtn:none in case e.g. somebody SENDS an anonymous bundle into the CCSDS portion of the DTN network.  As a concrete example, if somebody were to perversely send an anonymous bundle to the (as yet not-entirely-specified) bpecho service (which simply reflects the bundle back to the source), the receiving node needs (I think) to be able to interpret the source EID (ipn:0.0) as a valid well-formed EID, and it will then find that there is no route to that endpoint.  It would be an implementation optimization to then simply not reply (or immediately discard the reply) instead of trying to wait for a route to ipn:0.0 to become available, which it should never do.  Or, if a node is validating the primary block of a bundle with an anonymous source, the bare fact that it has an anonymous source shouldn’t cause the node to throw an error (though security policy certainly might).

The CCSDS BPv7 profile states that CCSDS implementations don’t need to be able to source anonymous bundles (3.3.3), which might get at your question above (why do we need them in the space context – we don’t, at least we assert that implementations aren’t required to be able to generate any).  That leaves open the possibility that an implementation could send anonymous bundles if it came up with a good reason to do so.

[As a side note: I think dtn:none is left over from BPv6 and the current custodian field.  It doesn’t really make sense to use dtn:none as a report-to EID, and certainly not as a destination EID.]

SLS-14
We tried to address this by renaming section 5 simply “Services BP Requires”.  I think this is in half-correct, in that in order to function correctly the PROTOCOL needs a time source.  The PROTOCOL doesn’t really need storage, but any sane implementation does.

I sort of like “BP Node Requirements” or “Services Required by BP Nodes” (the BP agent is part of the node, and I could see someone arguing that storage is required as part of the application agent to buffer bundles for delivery to registrations that are in a passive state).  I suppose a contender would be “BP Implementation Requirements” but I think I like ‘node’ better.  Anybody else have thoughts here?

Assuming we go with ‘BP Node Requirements’ or ‘Services Required by BP Nodes’ as the title of section 5 and correct the text for -06, would that then address all of your concerns?

                                v/r,

                                --keith

From: Ignacio.Aguilar.Sanchez at esa.int <Ignacio.Aguilar.Sanchez at esa.int>
Date: Tuesday, November 15, 2022 at 10:10 AM
To: Dr. Keith L Scott <kscott at mitre.org>
Cc: 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>
Subject: [EXT] Re: PID responses for BPV7
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

[cid:_1_0A3693300A368F4C00532075C12588FB]

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/584b164f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATT00001.gif
Type: image/gif
Size: 1155 bytes
Desc: ATT00001.gif
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221115/584b164f/attachment-0001.gif>