[Sis-dtn] 28 March SIS-DTN telecon

[Tomaso.deCola at dlr.de]

Concerning Leigh’s point, as soon as BPv7 book will be published as 734.2-B-2, the previous release I.e. BPv6 will become silver (I.e, obsoleted and maintained as historical record).
If I’m not wrong we took this path exactly because we wanted CCSDS to go on only with BPv7 and “forget” about v6. Now if on the contrary it turns out that we would like instead to keep both, maybe v6 for not that long I’ll check with Tom how to handle this situation. I’d expect that we could have a new number for v7 and issue a corrigendum for the title of v6 book.
But first of all, we must agree on what we want to do here.

Tomaso
Sent from my iPhone

On 27. Mar 2024, at 19:54, Robert C Durst via SIS-DTN <sis-dtn at mailman.ccsds.org> wrote:


All,

I have arranged for someone to open the telecon line tomorrow, but I won’t be able to attend due to a conflict.

*If* it seems like there is a quorum:


  1.  Please consider the draft agenda send previously and send me email if there are issues that need addressed.


  1.  Also, Leigh Torgerson sent the following comment on the BPv7 blue book that I think merits some consideration.  We can discuss during the BPv7 discussion at the CCSDS meeting, but I’d like folks to consider this beforehand:

Subject: CCSDS BP Specs - late agency review comment
I wish to note that while BPv6 is, I assume, deprecated (where does it say that in any CCSDS docs, by the way?), we still have missions and users flying BPv6, and in the future continued support for bpv6 is required.

If a user wishes to write a new application that is designed for BPv6, do we put in the contract to write something that is compatible with BP as specified by 734.2-B-1 (which does not indicate any particular version of BP in its title), and then on another project using BPv7 specify 734.2-P-1.1  (which has the same title as 734.2-B-1)?? Do you seriously think that won’t be confusing??

If you are going to change a protocol in such a dramatic manner as to completely eliminate backward compatibility, from a System Engineering point of view, and as one who has to help both projects and the DSN do the formal documentation of what service agreements are with external customers, I believe CCSDS is making a bad mistake not giving the Bluebooks SEPARATE numbers and titles that indicate that the specification is for a particular protocol that is totally incompatible with another protocol with the same CCSDS book name.

The recommendation is therefore to Change the title of the current BPv7 draft specification to “CCSDS BUNDLE PROTOCOL v7 SPECIFICATION”, assign it a new and non-confusing CCSDS book number, and then to add to the title of the existing 2015 BPv6 734.2-B-1 the indication that it is for BPv6.

This would be both sound System Engineering practice, as well as sound contractual practice in accordance with both FARs and UCC regulations.

Resulting questions:

1)      Should we publish BPv7 as a separately numbered Blue Book rather than an update to the previous Blue Book?

2)      Should we revise the Blue Book to retain support for both versions? (I haven’t begun to consider what *that* does to naming and so forth.)

3)      Should BPv6 be reaffirmed or eventually be transitioned to Silver (historical) status?  If Silver, when?

4)      What is the IETF posture on BPv6 (RFC 5050)?  It is listed as an experimental protocol, while RFC9171 is  “standards track,” but not yet an internet standard.  There is no attempt in the IETF to maintain backward compatibility, because nothing in the IETF world is using BPv6 operationally, unlike the CCSDS world.
If there’s not a quorum, please ponder these and we’ll return to them later.

Thank you!
Bob
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240327/92092be8/attachment.htm>