[CESG] CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review

Wed Jun 12 17:07:33 UTC 2024

Dear CESG Members,

Conditions for approval of CCSDS 311.0-P-1.1, Reference Architecture for Space Data Systems (Pink Book, Issue 1.1) have been disposed to the satisfaction of the AD(s) who voted to approve with conditions. The Secretariat will now proceed with CMC polling to authorize release for Agency review.
-------------- next part --------------
From:	Tomaso.deCola at dlr.de
Sent:	Wednesday, June 12, 2024 2:57 AM
To:	thomas.gannett at tgannett.net
Cc:	erik.j.barkley at jpl.nasa.gov; peter.m.shames at jpl.nasa.gov; 
miles.gannett at logothete.net; cesg at mailman.ccsds.org
Subject:	AW: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 
311.0-P-1.1, Reference Architecture for Space Data Systems (Pink 
Book, Issue 1.1) for CCSDS Agency review

Categories:	Poll Condition Closure

Dear Tom,

I’ve just checked the proposed changes that are fine with me. As such, you can consider close my 
condition for the publication of the book.

Best Regards,

Tomaso

Von: Thomas Gannett <thomas.gannett at tgannett.net>  
Gesendet: Dienstag, 11. Juni 2024 22:36 
An: de Cola, Tomaso <Tomaso.deCola at dlr.de> 
Cc: 'Barkley, Erik J (US 3970)' <erik.j.barkley at jpl.nasa.gov>; 'Shames, Peter M (US 312B)' 
<peter.m.shames at jpl.nasa.gov>; miles.gannett at logothete.net; 'CESG' <cesg at mailman.ccsds.org> 
Betreff: RE: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference 
Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review 
Priorität: Hoch

Dear Tomaso:

Please respond by return email indicating whether the editorial changes below satisfy your 
conditions.

Best regards,
Tom

1) Figure 5-2 should be enhanced (similar comment from Peter)

Editorial change: Figure 5-2 has been repaired.

2) table 9-1 mentions DTN layer with 'BPv7' between brackets: I'd simply point to Bundle 
Protocol still with 'BPv7' in brackets. Then as to the description, it emphasises on the routing 
part. I'd generally point to the store-carry-forward paradigm.

Editorial change:

Delay Tolerant Network 
LayerBundle Protocol (BPv7)
Network protocol
Provides store-and-forward relay 
routing throughas a core element of a 
dDelay (and disruption) tTolerant 
nNetwork (DTN) involving a set of 
space links

[Note: DTN is referred to in the next table row, so the call-out is retained in the description.]

3) still in table 9-1, there is the pointer to the optical physical item, why not including also the 
C&S? The table mentioned in the previous rows the TM/TC C&S (RF part), so that I see the 
inclusion of the optical one worth for the sake of the completeness. 

Editorial change (new row added at end of table 9-1):

Optical Communications 
Coding and Synchronization
Channel coding
Provides mechanisms for data 
synchronization and error control 

Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805

From: Barkley, Erik J (US 3970) [mailto:erik.j.barkley at jpl.nasa.gov]  
Sent: Wednesday, May 22, 2024 3:55 PM 
To: Shames, Peter M (US 312B); Thomas Gannett 
Cc: Tomaso.deCola at dlr.de; miles.gannett at logothete.net; CESG 
Subject: RE: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference 
Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review

Peter,

RASDSv2 is a fine term.  It’s use consistently throughout the document retires the condition.  

Best regards,
-Erik

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Wednesday, May 22, 2024 12:30 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; Thomas Gannett 
<thomas.gannett at tgannett.net> 
Cc: Tomaso.deCola at dlr.de; miles.gannett at logothete.net; CESG <cesg at mailman.ccsds.org> 
Subject: Re: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference 
Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review

Erik & Tom,

I agree with using one term consistently.

As for the adoption of RASDS++ vs RASDS v2, I checked with Fred Slane.  His ISO TC20/SC14 
organization is going to be a co-owner of the final document in ISO.  We have agreed to call it: 
RASDSv2.  This aligns with other similar document version changes, IPv4 vs IPv6, SysML vs SysMLv2, 
etc.  It also reflects that this is going to be published as CCSDS 311.0-B-2.  It is an extension and 
evolution of that original document.

So I request that Tom, during his editing, change all instances of RASDS and RASDS++ to read 
RASDSv2.  

Erik, please signal that this meets your condition.

I think there was also one question from Wilmot asking if all the new terms would be updated in the 
SANA Terms registry.  My request is that the CTE perform that update after the final version of the 
document has been approved.

One last note about the review and publication process is also in order.  I have agreed with Fred Slane, 
chair of ISO TC20/SC14, that we will follow this process:

1.	The document will go out for CCSDS Agency (and Observer, etc) review.
2.	In parallel we will send the Review notice to ISO TC20/SC14 with a request that they ask their 
Agency membership to participate in the CCSDS review process.
3.	In parallel I will be inviting outside systems architecture experts to also participate.
4.	All RIDs that are returned will be reviewed and dispositioned within the SEA SAWG, with the 
option to augment membership with SC14 participants.
5.	The final document, after the usual RID dispositioning, will be published as a CCSDS document.
6.	That document will then be sent to ISO for the usual “fast track” cover page process, and the final 
approved document will be jointly published with an ISO number and attributed to both SC13 
and SC14.

Anyone have any issues with this plan?

Thanks, Peter

From: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov> 
Date: Tuesday, May 21, 2024 at 4:34?PM 
To: Thomas Gannett <thomas.gannett at tgannett.net> 
Cc: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Tomaso.deCola at dlr.de 
<Tomaso.deCola at dlr.de>, miles.gannett at logothete.net <miles.gannett at logothete.net> 
Subject: RE: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-
1.1, Reference Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency 
review
Tom,

I'm happy to see the RASDS++ vs RASDS concern addressed however you would like – just as long as a 
single term is used consistently, rather than leaving the reader wondering  if there is significance as to 
when RASDS++ is used vs RASDS. Frankly RASDS++ sounds like a marketing buzz word to me.  I’d suggest 
just indicating RASDS 2.0, but if you choose to use RASDS++ consistently throughout the document that 
is okay too.

-Erik 

From: Thomas Gannett <thomas.gannett at tgannett.net>  
Sent: Tuesday, May 21, 2024 12:44 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov> 
Cc: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>; Tomaso.deCola at dlr.de; 
miles.gannett at logothete.net 
Subject: RE: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference 
Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review

Erik: 

Since your acquiescence is limited to the  UML inheritance condition/question, I believe Peter’s initial 
response grants editorial freedom to accept your RASDS++ vs. RASDS proposal. Please respond by return 
email if you are satisfied that that condition is closed as well.  

Tom 

Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805

From: Barkley, Erik J (US 3970) [mailto:erik.j.barkley at jpl.nasa.gov]  
Sent: Monday, May 20, 2024 9:00 PM 
To: Shames, Peter M (US 312B); Thomas Gannett; secretariat at mailman.ccsds.org 
Cc: Tomaso.deCola at dlr.de; miles.gannett at logothete.net 
Subject: RE: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference 
Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review

Yes, that works.  UML inheritance condition/question resolved.  Thank you.

Best regards,
-Erik

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Monday, May 20, 2024 17:21 
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; Thomas Gannett 
<thomas.gannett at tgannett.net>; secretariat at mailman.ccsds.org 
Cc: Tomaso.deCola at dlr.de; miles.gannett at logothete.net 
Subject: Re: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference 
Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review

Hi Erik,
Yes.  You could say that “correspondence” is a specialization of “Association (other relationship, 
labelled)”.  That said, we did explicitly assign a relationship meaning, and a separate type of 
arrow, to this relationship.  
If we address this in a footnote to Fig 3-3, stated thus:
“Relationships inherited from UML, with Correspondence added as a named extension to 
Association”
Does that meet your concern?
Thanks, Peter

From: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov> 
Date: Monday, May 20, 2024 at 4:07?PM 
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Thomas Gannett 
<thomas.gannett at tgannett.net>, secretariat at mailman.ccsds.org 
<secretariat at mailman.ccsds.org> 
Cc: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>, miles.gannett at logothete.net 
<miles.gannett at logothete.net> 
Subject: RE: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-
1.1, Reference Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency 
review
Peter,

My suggestion is to note that the correspondence is derived from the UML "Association" 
relationship.  Given that this is making use of UML class diagram definitions to start with, that seems to 
be the best “home” for the RASDS derivation.  Do you agree?

-Erik

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>  
Sent: Monday, May 20, 2024 11:35 
To: Thomas Gannett <thomas.gannett at tgannett.net>; secretariat at mailman.ccsds.org 
Cc: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; Tomaso.deCola at dlr.de; 
miles.gannett at logothete.net 
Subject: Re: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference 
Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review

Hi Tom,

I am completely confident that the issues I pointed out will be satisfied during your final editorial pass 
over the document.

Having just reviewed the comments from the other ADs I am similarly confident that you can handle all 
of these as editorial as well.  I hope the other ADs concur.

The only even slightly crunchy comment, IMHO, was Erik’s.  He is correct that most of Fig 3-3 was, in 
fact, inherited from UML.  However, in Fig 3-3 we also added “Correspondence”, which is not a 
relationship that UML has defined.  It is a new relationship added to meet requirements from ISO 
42010.  Hence “derived from”.

Is that acceptable?  Or would you rather put in a footnote stating something like “Inherited from UML, 
with Correspondence extension”

Thanks, Peter

From: Thomas Gannett <thomas.gannett at tgannett.net> 
Date: Monday, May 20, 2024 at 9:06?AM 
To: secretariat at mailman.ccsds.org <secretariat at mailman.ccsds.org>, Shames, Peter M (US 
312B) <peter.m.shames at jpl.nasa.gov> 
Cc: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>, Tomaso.deCola at dlr.de 
<Tomaso.deCola at dlr.de>, miles.gannett at logothete.net <miles.gannett at logothete.net> 
Subject: [EXTERNAL] RE: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, 
Reference Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency 
review
Peter: 

As discussed previously, in order to expedite processing, CCSDS 311.0-P-1.1, Reference Architecture for 
Space Data Systems (Pink Book, Issue 1.1), was placed in CESG polling while undergoing concurrent 
editing. 

If you are confident, as I am, that the draft resulting from the in-progress editing will correct the editorial 
issues identified in your conditional approval, perhaps along with other editorial issues,  please reply by 
return email stating that your conditions are effectively satisfied. 

Tom 

Logothete, L.L.C. 
thomas.gannett at tgannett.net 
+1 443 472 0805 

-----Original Message----- 
From: CCSDS Secretariat [mailto:thomas.gannett at tgannett.net]  
Sent: Monday, May 20, 2024 12:50 PM 
To: Peter.M.Shames at jpl.nasa.gov 
Cc: Erik.Barkley at jpl.nasa.gov; Peter.M.Shames at jpl.nasa.gov; Tomaso.deCola at dlr.de 
Subject: Re: CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference Architecture for 
Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review 

Dear Document Rapporteur, 

The CESG poll to approve release of CCSDS 311.0-P-1.1, Reference Architecture for Space Data 
Systems (Pink Book, Issue 1.1) for CCSDS Agency review concluded with conditions. Please negotiate 
disposition of the conditions directly with the AD(s) who voted to approve with conditions and CC the 
Secretariat on all related correspondence. 

CESG E-Poll Identifier:  CESG-P-2024-04-002 Approval to release CCSDS 311.0-P-1.1, Reference 
Architecture for Space Data Systems (Pink Book, Issue 1.1) for CCSDS Agency review 

Results of CESG poll beginning 28 April 2024 and ending 17 May 2024: 

                 Abstain:  0 (0%)   
 Approve Unconditionally:  2 (40%) (Aguilar Sanchez, Wilmot) 
 Approve with Conditions:  3 (60%) (Barkley, Shames, Cola) 
 Disapprove with Comment:  0 (0%)   

CONDITIONS/COMMENTS: 

     Erik Barkley (Approve with Conditions):  1) There are about 90 uses of the term "RASDS++" in the 
document and about 140 uses of the term "RASDS" (without "++").  There does not seem to be any 
indication in the book if there is to be inferred singificance when one term is used vs another.  I suspect 
not, and so would suggest simply introducing this as  RASDS V 2.0 and then just uniformly refer to this 
as RASDS rather than switching terms back and forth.  

2) figure 3 -3 -- the arrow defintions appear to be inherited from UML rather than derived -- there is not 
explanation offered as to what the derived properties are.  As such I recommend that this be stated as 
inherited, not derived.  

     Peter Shames (Approve with Conditions):  Tom, excellent job with lengthy & challenging 
input.  There are a few typos, as follows: 

Sec 2, pg - all, fix page numbers, they should read 2-1, 2-2…. The first page is just numbered “8”. 
Sec 2.2, pg 8, remove highlight on text 5.5.4. 
Sec 4, pg 4-1, change title to just “Enterprise Viewpoint” 
Sec 5.4.2.2, pg 5-3, Fig 5-2, White background on arrows obscures underlying figure elements 
Sec 9.9, pg 9-15, Fig 9-9, White background on arrows obscures underlying figure elements 

     Tomaso de Cola (Approve with Conditions):  Just two minor points: 

1) Figure 5-2 should be enhanced (similar comment from Peter) 

2) table 9-1 mentions DTN layer with 'BPv7' between brackets: I'd simply point to Bundle Protocol still 
with 'BPv7' in brackets. Then as to the description, it emphasises on the routing part. I'd generally point to 
the store-carry-forward paradigm. 

3) still in table 9-1, there is the pointer to the optical physical item, why not including also the C&S? The 
table mentioned in the previous rows the TM/TC C&S (RF part), so that I see the inclusion of the optical 
one worth for the sake of the completeness.  

Total Respondents:  5 

No response was received from the following Area(s): 

     MOIMS 

SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions 
PROPOSED SECRETARIAT ACTION:            Generate CMC poll after conditions have been addressed 

* * * * * * * * * * * * * * * * * * * * * * * *