[Sls-slp] PIDs concerning AOS & TC SDLP Pink Sheets

[Kazz, Greg J (US 312B)]

Dear SLP WG,

I was informed by Peter Shames, SEA Area Director, that he is considering generating two PIDs (Area Director Level) one for the attached AOS (732.0) and one for the TC (232.0) SDLP pink sheets.
My purpose of this email is to see if we (SLP WG) can come up with adequate changes to the text in question or provide adequate rationale for these specific pink sheet changes for example in the NOTE section of the documents.

Proposed PID 1: AOS Section 3.2.6 AOS Transfer Frame – why exclude the Insert Zone under the condition ?

FROM: 3.2.6. “ The following restriction apply to AOS Transfer Frames: if at least a Virtual Channel Frame or a Master Channel Frame service exists, all AOS Transfer Frames on the Physical Channel shall not include the Transfer Frame Insert Zone.”
TO: ?

The issue the PID brings up, is “what is the rationale for this restriction ?” Why can’t the physical channel contain an Insert Zone under this condition ? Provide the rationale in the document, in order to avoid confusing the user.

I believe the rationale has to do with the fact, that if a service user subscribes to either the VCF or the MCF service, then that user provides either complete Master Channel Frames or complete Virtual Channel Frames to the service provider. However, in those cases, there is an ambiguity concerning the use of the Insert Zone service by that user. The protocol only allows for one use of the Insert Zone service on the Physical Channel. Therefore to avoid any ambiguity, under this condition, there cannot be an Insert Zone.
If I am incorrect, please let me know.

So in order to address the PID, we could either modify 3.2.6 or provide clarification in the NOTE below it.
Your suggestions are welcome.

Proposed PID 2: TC SDLP Section 2.2.1 (and reoccurring) – removal of the term, “ports”

Issue: Why was the term, “ports” removed throughout the document ? By removing it from the document, does it break any implementations?

I noticed that the term “port” is not defined in both the 2003 as well as the current version of 232.0. I believe the SLP WG removed the term, “port(s)” because it was undefined and was not connected to the TC SDLP. In other words, “port(s)” was just a notional term, but never part of the actual TC SDLP. The only question remaining in the PID is “does it break any existing agency implementation, if that term is removed from the protocol” ?
I would like the SLP WG to weigh in on that question. I am not aware of any implementation issues from the NASA side.

Please try and respond back to me by the end of this week i.e., no later than Feb. 12.

Best regards,

Greg Kazz
Principal Engineer
Technical Group Supervisor,
PSSE/EEISE/PPSE (312B)
Jet Propulsion Laboratory
4800 Oak Grove Dr., M/S 301-490
Pasadena, CA 91109
1+(818)393 6529(voice)
1+(818)393 6871(fax)
email: greg.j.kazz at jpl.nasa.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210209/c3d3a9bf/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 732x0p30_CESG_Approval.pdf
Type: application/pdf
Size: 101971 bytes
Desc: 732x0p30_CESG_Approval.pdf
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210209/c3d3a9bf/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 232x0b3_CESG_Approval.pdf
Type: application/pdf
Size: 161207 bytes
Desc: 232x0b3_CESG_Approval.pdf
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20210209/c3d3a9bf/attachment-0003.pdf>