[Sis-dtn] [EXTERNAL] Re: [EXT] Re: 28 March SIS-DTN telecon

Thu Mar 28 06:52:27 UTC 2024

Hi,

My (maybe wrong) assumption has always been that the new (BPv7) Blue Book will become 734.2-B-2 and that 734.2-B-1 will be silverized.

We have a lot of documentation which included 734.2-B-1 with the expectation that this will be “updated” to 734.2-B-2 when the new book has been published by CCSDS.
(This sounds much less scary to people then saying that a standard will be replaced by a new standard once published although it means the same …).

Anyway, this is important as we are trying to resolve the LNIS RIDs (and put out ICD, ITTs, etc for other activities). So, in general I think it is important to

  1.  Have a clear identifier for an upcoming standard which is *stable*, so that we can already refer to it by eg, “734.2-B-2, to be published”
  2.  Have a way to refer to drafts that have been released for Agency reviews (this is not ideal but sometimes much better then referring (only) to the old standard). In CCSDS terms I believe that this should be red books. However, for some reason we ended up with 734.2-P-1.1 for the new BP book (for BPSEC we have 734.5-R-2 which looks better). Having those allows to reference eg
734.2-B-2, to be published (CCSDS profile of RFC 9171 - Bundle Protocol Version 7, see CCSDS Draft Recommended Standard 734.2-P-1.1)

Whatever we do, we should conclude asap (ideally before the spring meetings; we have to finalise LNIS RID responses now).

Regards,
Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Tomaso de Cola via SIS-DTN
Sent: Thursday, March 28, 2024 6:58 AM
To: Edward.Birrane at jhuapl.edu
Cc: sis-dtn at mailman.ccsds.org; jordan.l.torgerson at jpl.nasa.gov
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] Re: 28 March SIS-DTN telecon

Hi Ed,

The point is that we started the BPv7 as update of BPv6, so that a new issue of that book will be created. The BPv6 issue will be automatically obsoleted and that version becoming silver. If we wanted to keep the two books alive in parallel, we should have started a new project for a brand new book, not the update of an existing one (that’s why we have a pink book instead of a red here)
But as said I can check with Tom how to solve this situation if this is what we plan to do.

Tomaso
Sent from my iPhone

On 28. Mar 2024, at 05:23, Birrane, Edward J. <Edward.Birrane at jhuapl.edu<mailto:Edward.Birrane at jhuapl.edu>> wrote:

Leigh,

  Completely agree that Bpv6 and Bpv7 are distinct things and MUST be uniquely identifiable through distinct CCSDS document numbers.

  I, personally, like the construct of 734.2-B-1 (BPv6) and 734.2-B-2 (BPv7). It acknowledges that BPv7 is a new issue of bundle protocol and it preserves the requirement to keep the BPv6 ID unique and unchanged.

  How has CCSDS handled this in the past?  This cannot be the first time CCSDS has published a new issue of a blue book when the prior issue of the book was still in operational use.

-Ed
---
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Networking
Space Systems Implementation Branch
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

From: Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>
Sent: Wednesday, March 27, 2024 8:04 PM
To: Birrane, Edward J. <Edward.Birrane at jhuapl.edu<mailto:Edward.Birrane at jhuapl.edu>>; Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>; durst at mitre.org<mailto:durst at mitre.org>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [EXTERNAL] Re: [Sis-dtn] [EXT] Re: 28 March SIS-DTN telecon

APL external email warning: Verify sender jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov> before clicking links or attachments

Ed -- A bunch of ISS payloads use BPv6, the Korean KPLO mission uses BPv6, and continued operational support of BPv6 is required in the DSN.

From a contractual standpoint, the CCSDS Bluebook 734.2-B-1 is already IN a bunch of contractual documents, and is in the formal interagency DSN operations specifications and existing service agreements, so you should NOT eliminate BPv6 from the document named 734.2-B-1. And, I doubt that anyone is going to buy in to the idea that we instead go back and retroactively modify a bunch of contacts, ICDs and international DSN operations interface documentation. Let’s not make CCSDS look silly.

We all agree that anything new will use BPv7 – no argument there – and I doubt that any new work will be done by anyone that needs to reference 734.2-B-1 – but none of us know that will be true; I can’t speak for JAXA or KARI or ISRO etc.  From a contractual point-of-view, you could probably get away with silverizing 734.2-B-1 and call it 734.2-B-1-S , but please don’t cause problems with existing contracts, support requirements and missions by using the same document number and title for something that is clearly incompatible with BPv6.

A new number and non-confusing title for a BPv7 Bluebook shouldn’t be difficult..

Regards,
Leigh

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> on behalf of "Birrane, Edward J. via SIS-DTN" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Reply-To: "EXTERNAL-Birrane, Edward J (US 9300-Affiliate)" <Edward.Birrane at jhuapl.edu<mailto:Edward.Birrane at jhuapl.edu>>
Date: Wednesday, March 27, 2024 at 12:57 PM
To: "Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>" <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>, "durst at mitre.org<mailto:durst at mitre.org>" <durst at mitre.org<mailto:durst at mitre.org>>
Cc: "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: [EXTERNAL] Re: [Sis-dtn] [EXT] Re: 28 March SIS-DTN telecon

The IETF perspective is the BPv6 was an experimental specification.

Existing operational missions (I am only aware of PACE?) must support BPv6 but there should not be an expectation of new work for BPv6 beyond required sustainment of existing operational deployments.

In my opinion.

-Ed

Sent with BlackBerry Work
(www.blackberry.com<https://urldefense.us/v3/__http:/www.blackberry.com__;!!PvBDto6Hs4WbVuu7!K38mP4rbU8jGUQyBg3xrTtPzITStOomm7OlVgpM2jUK1CbKp628TOhgAF_zEoCeN4LAr9_BsAIQumJolxI8EVk2t4UY$>)

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> on behalf of: Tomaso de Cola via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Date: Wednesday, Mar 27, 2024 at 3:38 PM
To: durst at mitre.org<mailto:durst at mitre.org> <durst at mitre.org<mailto:durst at mitre.org>>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org> <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: [EXT] Re: [Sis-dtn] 28 March SIS-DTN telecon

APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> before clicking links or attachments

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<mailto: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<mailto:SIS-DTN at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn<https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!K38mP4rbU8jGUQyBg3xrTtPzITStOomm7OlVgpM2jUK1CbKp628TOhgAF_zEoCeN4LAr9_BsAIQumJolxI8EqLWi-a4$>
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/20240328/d1fbfb4c/attachment-0001.htm>