[CESG] CESG-P-2023-06-004 Approval to release CCSDS 142.0-P-1.1, Non-Coherent Optical Communications Coding and Synchronization (Pink Sheets, Issue 1.1) for CCSDS Agency review
CCSDS Secretariat
thomas.gannett at tgannett.net
Tue Sep 26 20:02:15 UTC 2023
Dear CESG Members,
Conditions for approval of CCSDS 142.0-P-1.1, Non-Coherent Optical Communications Coding and Synchronization (Pink Sheets, 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: Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC]
<jonathan.j.wilmot at nasa.gov>
Sent: Tuesday, September 26, 2023 2:02 PM
To: Hamkins, Jon (JPL-3300)[JPL Employee]
Cc: Edwards, Bernard L. (GSFC-5600); Ignacio Aguilar Sanchez; Clemens Heese;
Shames, Peter M (JPL-312B)[JPL Employee]; thomas.gannett
(thomas.gannett at tgannett.net)
Subject: RE: [EXTERNAL] Re: Closed CESG Polls with Conditions concerning OPT WG
documents
Categories: Poll Condition Closure
Jon,
Thanks for the response. Coming from a flight software background I tend toward precise definitions
to avoid ambiguities/misinterpretation. As we exchange managed parameters between organizations
we should have well defined names, definitions, ranges, with any constraints. For a managed
communications network (like DTN) some of the MIB parameters must be exchanged as part of a
contact schedule. It's harder to do this when we don't have agreed/standard names, and associated
metadata. I would like all CCSDS standards to move in this direction.
I agree that it would be better to have this as part of the agency review process and withdraw my
condition and will generate an agency RID on this topic.
Kind regards,
Jonathan Wilmot
CCSDS SOIS Area Director
GSFC DTN Systems Engineer
cFS Architecture
Cell 301-751-2658
From: Jon Hamkins <Jon.Hamkins at jpl.nasa.gov>
Sent: Tuesday, September 26, 2023 12:44 PM
To: Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC] <jonathan.j.wilmot at nasa.gov>
Cc: Edwards, Bernard L. (GSFC-5600) <bernard.l.edwards at nasa.gov>; Ignacio Aguilar Sanchez
<Ignacio.Aguilar.Sanchez at esa.int>; Clemens Heese <Clemens.Heese at esa.int>
Subject: [EXTERNAL] Re: Closed CESG Polls with Conditions concerning OPT WG documents
Hi Jonathan. We eagerly await your response, when you get a moment to think about this. Thank you.
----Jon
Jon Hamkins
Lead Technologist, Communications, Tracking, and Radar Division
O 818-354-4764 | M 626-658-6220
JPL | jpl.nasa.gov
On 9/16/2023 9:00 PM, Jon Hamkins wrote:
Hi Jonathan,
Concerning CESG-P-2023-06-004 Approval to release CCSDS 142.0-P-1.1, Non-Coherent Optical
Communications Coding and Synchronization (Pink Sheets, Issue 1.1) for CCSDS Agency review, you
defined the following conditions, which I repeat here for convenience:
Managed parameters should be more formally specified in in the section 7 tables. Maybe this is to be
done in the FRM? If users of this standard write software to export and ingest interoperable MIBs, how
do they define the data types?
From table 7-4, is "AOS/USLP transfer frame length (octets)" an integer (which can be positive or
negative) or an unsigned integer range 0 to 65536. Is the managed parameter name an ASCII string with
spaces? Is "Input block length, k" represented in the MIB as "Input block length ", or "k"? Are the values
unsigned integers or ASCII strings of "64", "256", "1024"?
For interoperable MIBs (machine readable), there must be agreement on parameter names, data types,
and values. If the approach is to specify them as an FRM in SANA, then there should be a note and link
to them in this document. In the past these parameters were written into paper ICDs and interpreted
by humans (sometimes incorrectly) The modern approach should be to make them machine readable
and formally define in a FRM.
We would like to work through and resolve your conditions.
Our intent is to be clear enough within the Blue Book, including the managed parameters description,
that a human implementer does not need to go to the Functional Resource Model or a Management
Information Base. The pink sheets have not defined ASCII representations of the names of its managed
parameters or data types for the values because machine-readable interoperable exchange of managed
parameter tables is not a subject of this specification. The existing 142 Blue Book, like the 131 series of
Blue Books, is similar in this respect. If we want to move to a machine-readable managed parameter
specification, perhaps that would be a better subject for the RID process, where it may be exposed to a
broader community and resolved across both the pink sheets and existing parameter tables? Or what do
you suggest? Whatever we do, we'd like Tables 7-2 and 7-3 to be as consistent as possible with the
format of 7-4, which is not changing.
You reference Table 7-4, but that is already an approved part of the blue book and is not changing, and
thus is not subject to review. However, I take your meaning and your comment would also apply to
Tabled 7-2 and 7-3, which are subject to this review. Yes, you are correct, the length is an integer range
0 to 65536. I think it is clear enough that a frame length will not be a negative integer. Do you agree?
This section is similar to the section in 131.0-B-4, section 12.9, which also simply says "Integer." Also The
AOS Blue Book 732.0-B-4 Table 5-1 for the managed parameters simply says "Integer." I'm not sure
Tables 7-2 and 7-3 need to be more explicit than they are in this respect, but let me know what you
think.
I look forward to your thoughts about how we ought to proceed. Thanks.
----Jon
Jon Hamkins
Lead Technologist, Communications, Tracking, and Radar Division
O 818-354-4764 | M 626-658-6220
JPL | jpl.nasa.gov
On 7/11/2023 5:05 AM, Ignacio Aguilar Sanchez wrote:
Dear Clemens and Jon,
I do not know if you can see the recent results of the two CESG Polls that concerned two of the OPT WG
documents.
Just in case I am posting the CWE webpages as well as screen captures so you can see the comments
raised by certain Area Directors.
CESG Polls - CESG-P-2023-06-004 Approval to release
CCSDS...<https://urldefense.us/v3/__https://cwe.ccsds.org/fm/Lists/CESGPollQuestion/DispFormClosed
.aspx?ID=74&Source=open.aspx__;!!PvBDto6Hs4WbVuu7!Oo_aDDnai_edcqElt09nag2nQ5PzVB4TcL_-
7__nJs_Yf6yrrwRxz-1wy9-iW0D1YcmprSaCSdrDbYcpdd0UelZovaaTpAi40Q$>
CESG Polls - CESG-P-2023-06-005 Approval to publish
CCSDS...<https://urldefense.us/v3/__https://cwe.ccsds.org/fm/Lists/CESGPollQuestion/DispFormClosed
.aspx?ID=75&Source=open.aspx__;!!PvBDto6Hs4WbVuu7!Oo_aDDnai_edcqElt09nag2nQ5PzVB4TcL_-
7__nJs_Yf6yrrwRxz-1wy9-iW0D1YcmprSaCSdrDbYcpdd0UelZovaY1Ew_96g$>
Please initiate contact with the relevant ADs to solve the comments.
Kind regards,
Ignacio
Ignacio Aguilar Sánchez
Communication Systems Engineer
Electrical Engineering Department
European Space Research and Technology Centre Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The
Netherlands
Mob.+31641360257
Fax +31715655418
Email: ignacio.aguilar.sanchez at esa.int<mailto:ignacio.aguilar.sanchez at esa.int>
www.esa.int<https://urldefense.us/v3/__http://www.esa.int/__;!!PvBDto6Hs4WbVuu7!Oo_aDDnai_ed
cqElt09nag2nQ5PzVB4TcL_-7__nJs_Yf6yrrwRxz-1wy9-
iW0D1YcmprSaCSdrDbYcpdd0UelZovaZpLOeZQA$>
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>).
From: Tomaso.deCola at dlr.de
Sent: Wednesday, July 12, 2023 11:02 AM
To: thomas.gannett at tgannett.net; Jon.Hamkins at jpl.caltech.edu
Cc: bernard.l.edwards at nasa.gov; Clemens.Heese at esa.int
Subject: Re: [EXTERNAL] AW: Conditions for poll CESG-P-2023-06-004
Dear Tom,
yes the proposal from Jon works for me. You can close my conditions.
Best Regards,
Tomaso
Da: Thomas Gannett <thomas.gannett at tgannett.net>
Inviato: martedì 11 luglio 2023 21:31
A: 'Jon Hamkins'; de Cola, Tomaso
Cc: bernard.l.edwards at nasa.gov; Clemens.Heese at esa.int
Oggetto: RE: [EXTERNAL] AW: Conditions for poll CESG-P-2023-06-004
Dear Tomaso:
Please indicate by return email if the changes proposed by Jon satisfy your remaining conditions.
Best regards,
Tom
Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805
From: Jon Hamkins [mailto:Jon.Hamkins at jpl.caltech.edu]
Sent: Tuesday, July 11, 2023 3:01 PM
To: Tomaso.deCola at dlr.de; thomas.gannett at tgannett.net
Cc: bernard.l.edwards at nasa.gov; Clemens.Heese at esa.int
Subject: Re: [EXTERNAL] AW: Conditions for poll CESG-P-2023-06-004
Tom, to satisfy Tomaso's condition 4, can you update the Pink Sheets as follows:
* p. 1-1: change "Issue 2" to "This issue" (or otherwise avoid what may be confusing use of
"2")
To satisfy condition 2, I will make a point of notifying reviewers that they may find it convenient
to keep open a copy of the original Blue Book during their review to follow the references
between sections. I hope this will be acceptable. I appreciate your view of wanting a full Pink
Book (making the review easier) and Tom's as well (not opening up previously approved
wording to review).
Concerning section 2 (overview), to better delineate between HPE and O3K, I suggest the
following changes:
* p. 2-3 Replace this wording:
*
* with:
* "The overall architecture of the optical communications system is shown in figure 2-2.
Throughout the communications session, the optical Terminal A may optionally transmit
a beacon, in which case the Terminal B receiver locks onto the beacon and uses it to
assist in accurately pointing its optical transmitter. In the case of HPE, the beacon may be
accompanied by optional AOS/USLP transfer frame data, which is decoded onboard.
O3K allows no data to accompany the beacon. Telemetry is transmitted from Terminal B
and received by Terminal A."
* Update figure 2-2 to replace "Beacon and (Optional) AOS or USLP Transfer Frames"
with "Optional beacon. If HPE, beacon may optionally be accompanied by AOS or USLP
Transfer Frames."
* Update p. 2-5 to insert "For HPE" just before the paragraph beginning "At the receiving
end..."
I hope this will make things clearer. There will also be an opportunity to submit RIDs to clear up
language, as needed.
Would these changes be acceptable?
----Jon
Jon Hamkins
Lead Technologist, Communications, Tracking, and Radar Division
O 818-354-4764 | M 626-658-6220
JPL | jpl.nasa.gov
On 7/11/2023 10:51 AM, Tomaso.deCola at dlr.de wrote:
Hi Tom, Jon
concerning 4, ok. Then I’d suggest that any occurrence showing issue 2 is then removed
(as far as I can remember I had spotted 1 or 2).
concerning 2, yes I’m aware of the difference between pink sheet and pink book but I
hoped that there was a gray zone so that it were possible to add material not subject to
review (i.e. full content of Sections 2 and 3) without changing the review scope. If this is
not possible, ok then reviewers will have to keep the two books open to avoid
misunderstanding on some parts.
@Jon: If so, then my remaining point is to make clearer which functions listed in Section
2 go with HPE and which with O3K. And then immediately afterwards if the text coming
from the issue 1 of the book shall be completed with some more specifities about O3K
or it’s ok like this (is quite oriented to HPE only in my opinion).
Thank you all,
Tomaso
Von: Thomas Gannett <thomas.gannett at tgannett.net>
Gesendet: Dienstag, 11. Juli 2023 19:27
An: 'Jon Hamkins' <Jon.Hamkins at jpl.caltech.edu>; de Cola, Tomaso
<Tomaso.deCola at dlr.de>
Cc: 'Edwards, Bernard L. (GSFC-567.0)' <bernard.l.edwards at nasa.gov>; 'Clemens Heese'
<Clemens.Heese at esa.int>
Betreff: RE: Conditions for poll CESG-P-2023-06-004
All:
Concerning 4, the issue is 1.0 at the time of CESG polling; it will be 1.1 when it goes to
review. Issue 2 will not exist until the Pink Sheets have completed review and a new
issue of the Blue Book has been approved. This is standard numbering and should not
be an approval condition.
Concerning 2 (and 1 where applicable), Pink Sheets frequently contain cross references
to parts of the published book not included in the Pink Sheets. The purpose of Pink
Sheets is to present only new and changed materials to reviewers so that reviewers do
not submit RIDs against previously approved content. The published document is
available on line free of charge if any reviewer wishes to explore cross references; if that
is burdensome, then the existence of reference documents in any publication must be
extremely onerous. If the solution to the condition in this case is to release the entire
document for review, then all parts of the previously reviewed and approved document
will be subject to review. That becomes a resource issue, since the resources for the
approved project are specific to “Addition of Optical On/Off Keying to the Optical
Communications Physical Layer Blue Book for the Low Complexitiy Scenario” (not
revision of the entire document).
Tom
Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805
From: Jon Hamkins [mailto:Jon.Hamkins at jpl.caltech.edu]
Sent: Tuesday, July 11, 2023 12:45 PM
To: Tomaso.deCola at dlr.de
Cc: Thomas Gannett; Edwards, Bernard L. (GSFC-567.0); Clemens Heese
Subject: Conditions for poll CESG-P-2023-06-004
Hi Tomaso,
I see the conditions (copied at bottom of this email) for your vote in the poll for
the non-coherent optical communications coding and sync book.
If I understand you, items 1) and 2) might be resolved with Pink Sheets that show
the entire document and not just the pages with changes on them. Is this
correct? I am copying Tom Gannett for his advice on how to handle this.
Regarding 3), I agree we should improve the definitions/wording regarding
ISLFrame. I think this is wording that we could improve during the RID process, if
you are amenable to the WG handling it during the agency review.
Tom, could you could comment on issue 4) regarding the issue number.
I look forward to your and Tom's thoughts on this. Thanks.
----Jon
1) I understand that this is a pink sheet, so that only the amended
or new sections are included for the review. However I find this
may complicate the life of reviewers during the agency review.
Just to me clearer, Sections 1 and 2 are both addressing HPE and
O3K, so that having the full new version of section 2 would have
been desirable. Then in particular, at the beginning of the excerpt
of section 2 kept here, it is mentioned that some functions are for
HPE, some for O3K, some for both. Why not making this more
explicit, i..e which functions belon to what? Then, the following
desription seems to be limited only on HPE, nothing to report
about O3K?
2) Section 4 containts pointers to section 3, which as mentioned
above is not reported here because not touched by this pink
sheet. However it implies that reviewers have to go back and
forth from this and the currently published version of the book.
3) ISLFrame is not defined (it only appears in a diagram and
nothing more).
4) The cover and the history of the document report issue 1, but in
fact this should be issue 2.
--
Jon Hamkins
Lead Technologist, Communications, Tracking, and Radar Division
O 818-354-4764 | M 626-658-6220
JPL | jpl.nasa.gov
More information about the CESG
mailing list