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

Wed Nov 16 14:09:24 UTC 2022

Keith,

I am ok with your explanations about anonymous bundles. The PIDs SLS-10 
and 11 can now be closed.

For SLS-14 and based on what I read below, we are in sync. Just wait for 
any additional feedback and a final edition. Similarly for SLS-06.

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>
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>
Date:   15/11/2022 17:06
Subject:        Re: [EXT] Re: PID responses for BPV7

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 

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).

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/20221116/86e44275/attachment-0001.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/20221116/86e44275/attachment-0002.gif>
-------------- 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/20221116/86e44275/attachment-0003.gif>