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

Thu Mar 28 00:17:58 UTC 2024

+1 to this suggestion
v

On Wed, Mar 27, 2024 at 8:05 PM Torgerson, J. Leigh (US 332C) via SIS-DTN <
sis-dtn at mailman.ccsds.org> wrote:

> 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> on behalf of
> "Birrane, Edward J. via SIS-DTN" <sis-dtn at mailman.ccsds.org>
> *Reply-To: *"EXTERNAL-Birrane, Edward J (US 9300-Affiliate)" <
> Edward.Birrane at jhuapl.edu>
> *Date: *Wednesday, March 27, 2024 at 12:57 PM
> *To: *"Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>, "durst at mitre.org" <
> durst at mitre.org>
> *Cc: *"sis-dtn at mailman.ccsds.org" <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> on behalf of: Tomaso
> de Cola via SIS-DTN <sis-dtn at mailman.ccsds.org>
>
> *Date: *Wednesday, Mar 27, 2024 at 3:38 PM
>
> *To: *durst at mitre.org <durst at mitre.org>
>
> *Cc: *sis-dtn at mailman.ccsds.org <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 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> 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
> <https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!K38mP4rbU8jGUQyBg3xrTtPzITStOomm7OlVgpM2jUK1CbKp628TOhgAF_zEoCeN4LAr9_BsAIQumJolxI8EqLWi-a4$>
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346

until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240327/8669210b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4006 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240327/8669210b/attachment-0001.bin>