[Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates

[Tomaso.deCola at dlr.de]

If we are all available, let’s discuss the way forward at the DTN telco in 15’.

Tomaso

From: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] <jonathan.w.jackson at nasa.gov>
Sent: Donnerstag, 11. Juli 2024 16:39
To: de Cola, Tomaso <Tomaso.deCola at dlr.de>; morinaga.yu at jaxa.jp
Cc: sis-dtn at mailman.ccsds.org
Subject: RE: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates

Thanks Tomaso,

We have requirements in annex B (CLs) that reference BP MIB in the requirements (e.g., LTP parameters).
If we remove these references in the PICS, should they be replaced with something else to ensure Annex B?
Or are we covered with the other features listed?

Regards,
Jonathan


From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Sent: Wednesday, July 10, 2024 2:47 AM
To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] <jonathan.w.jackson at nasa.gov<mailto:jonathan.w.jackson at nasa.gov>>; morinaga.yu at jaxa.jp<mailto:morinaga.yu at jaxa.jp>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.


But if the annex has become informative, practically speaking it does not belong to the specification and as such it won’t be in any case part of any interoperability. As such I don’t see how we could indicate a corresponding item (i.e. coming from an informative annex) in the NPICS and label it as ‘optional’. My understand it is that we have to refer to items (i.e. functionalities, capabilities, etc.) which are defined in the normative part of the document only and if not relevant for the interoperability label as ‘optional’.
Am I missing something here?

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN
Sent: Dienstag, 9. Juli 2024 21:30
To: morinaga.yu at jaxa.jp<mailto:morinaga.yu at jaxa.jp>; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] [EXTERNAL] RE: BPv7 RIDs and Updates

Thanks Yu!

Fair point…if everyone agrees will update these to “optional.”


Thanks again!
Jonathan

From: morinaga.yu at jaxa.jp<mailto:morinaga.yu at jaxa.jp> <morinaga.yu at jaxa.jp<mailto:morinaga.yu at jaxa.jp>>
Sent: Tuesday, July 9, 2024 7:26 AM
To: Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] <jonathan.w.jackson at nasa.gov<mailto:jonathan.w.jackson at nasa.gov>>; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [EXTERNAL] RE: [Sis-dtn] BPv7 RIDs and Updates

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.


Dear all
In RID No.99, ANNEX C is made informative.
However, the status of PICS (A5.5) No. 51-54 regarding MIB remains "mandatory".
Is it mistake? I think the status should be made "optional" instead of "mandatory".
Thanks,
Yu


From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Jackson, Jonathan W. (MSFC-HP27)[MOSSI2] via SIS-DTN
Sent: Friday, June 28, 2024 2:44 AM
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] BPv7 RIDs and Updates
Importance: High

Hello All,

Attached is the updated BPv7 book and RID spreadsheet for Final Reviews.
We致e drafted the following note for RID 115 based on our discussion during today痴 telecon:

RID#

Paragraph Number

RID Short Title

From

To

Supporting Analysis

115

4.3.4

Creation Timestamp Sequence Number Clarification

The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number.

The creation timestamp shall comprise the bundle creation time and the creation timestamp sequence number.

NOTE: Implementations may choose to use the source node id and the creation timestamp sequence number. However, a global counter or a separate counter for each fully qualified source node ID is possible.

Without this wording there is enough ambiguity to allow for implementors to either associate the sequence number of the creation timestamp to a global counter which is the intent or on a per service basis potentially leading to unintended behavior.



Please let me know if you have any comments or questions.


Thanks,
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240711/063d65ff/attachment-0001.htm>