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

Fri May 17 15:27:39 UTC 2024

Hi Felix,

1. Confirmed; to the best of my knowledge not yet agreed whether to put BPv7 in the title.
2. Maybe I missed something, but do we really need a second agency review? Other than this, you are right about the numbering.

Tomaso

Sent from my iPhone

On 17. May 2024, at 16:31, Felix Flentge <Felix.Flentge at esa.int> wrote:

Dear All,

Coming back to this discussion. Is there anyone not agreeing that:

  1.  The BPv7 Blue Book will be CCSDS 734.2-B-2 ?
  2.  The book to be published for the second agency review (asap I hope) will be called CCSDS 734.2-P-1.2 (as the previous version for Agency review has been called CCSDS 734.2-P-1.1)?

Regards,
Felix

From: Robert C Durst <durst at mitre.org>
Sent: Thursday, March 28, 2024 12:37 PM
To: Tomaso.deCola at dlr.de; Felix Flentge <Felix.Flentge at esa.int>
Cc: sis-dtn at mailman.ccsds.org; Daniel Pettitt <Daniel.Pettitt at esa.int>; jordan.l.torgerson at jpl.nasa.gov
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] Re: 28 March SIS-DTN telecon

All,

Since I won’t be on today’s call, I figured I’d get my opinion on Leigh’s comment out early.

Nothing prevents BPv6 from being supported or used operationally once the spec transitions to Silver status. Ground infrastructure can still support it, references to the spec still resolve.  It’s not broken, and it’s not withdrawn.

We can and will add text to BPv7 to clearly state that it is different than BPv6 and that some systems, particularly multi-mission infrastructure, may be required to support both versions.

When BPv6 transitions to Silver, I believe that we can add a note in the version history that points toward BPv7 as the standard for new missions and notes that support for both may be required in some systems.

As to the document numbers, they’re different:  734.2-B-1 is NOT the same as 734.2-B-2.

Should we reference BPv7 in the title? Maybe. I can ask Tom Gannett whether a change to the title is permitted or whether we can add a subtitle. I’ll also ask what our options are for including some text in the 734.2-B-1 document to make clear to readers that the two versions are distinct, that both may require support for some period of time, and that new starts should use the latest version of the standard (currently -2).

So my recommendation is to continue with the current numbering. I’ll check on title wording and text to be added to -1 as it transitions to silver.

Best,
Bob

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
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>>
Sent: Thursday, March 28, 2024 3:44 AM
To: Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int> <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
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>>; Daniel.Pettitt at esa.int<mailto:Daniel.Pettitt at esa.int> <Daniel.Pettitt at esa.int<mailto:Daniel.Pettitt at esa.int>>; jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov> <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] Re: 28 March SIS-DTN telecon

Hi Felix, As to your first observation, this is indeed the result of the process we started a few years ago. At that time we are all on the same page that we needed to update the BPv6 book in order to have the BPv7 as new issue of that one,
Hi Felix,

As to your  first observation, this is indeed the result of the process we started a few years ago. At that time we are all on the same page that we needed to update the BPv6 book in order to have the BPv7 as new issue of that one, thus implying that BPv6 would have been silverised. Because of that, we started pink sheets.
 If on the contrary we wanted to have BPv7 book and also keep BPv6, we should have started a new project, without claiming this to be an update of BPv6 book. In such a case we would have had the red book.
For BPsec, it was slightly different because we had first an agency review of the once called streamlined security BP and then we decided later to “trash” it and restart with BPsec. Tom suggested to have this as an evolution of that initial red book and having a second agency review, though formally was an exception. In any case it is about a new book, I.e. no update of an existing book, hence red instead of pink.

In any case I concur that we have to agree on the next steps as soon as possible so that we have a plan before end of April and I see how to solve this situation with Tom and CESG, if the case.

Tomaso
Sent from my iPhone

On 28. Mar 2024, at 07:52, Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>> wrote:

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

a.      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”

b.      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<mailto: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<mailto:Edward.Birrane at jhuapl.edu>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>; jordan.l.torgerson at jpl.nasa.gov<mailto: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:

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

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<mailto: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/20240517/b9633243/attachment-0001.htm>