[Sis-dtn] Level of granularity in PICS

[Felix.Flentge at esa.int]

Hi,

I think having one entry for each of the subsections in Section 5 may make 
sense:

a) it's a kind of logical approach
b) there are actual some sections where I could see that implementation 
could (but shall not) deviate: e.g., not implementing fragmentation (5.8). 
I still think all of this should be mandatory but by separating it out we 
would at least get a clear statement of non-compliance.

For Section 4, we may structure:

4.1
4.2
4.3
4.4.1
4.4.2
4.4.3

Regards,
Felix



From:   "sburleig.sb--- via SIS-DTN" <sis-dtn at mailman.ccsds.org>
To:     "'Dr. Keith L Scott'" <kscott at mitre.org>, 
<sis-dtn at mailman.ccsds.org>
Date:   13/07/2022 07:45
Subject:        Re: [Sis-dtn] Level of granularity in PICS
Sent by:        "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org>



On section 5: I think we need entries for every bit of normative language 
in this section that is not ?SHALL? or ?MUST?.  Otherwise, though, I would 
say that a code base that doesn?t implement all this stuff simply isn?t 
BPv7.  Maybe less harshly we could have something like a section in which 
?Deviations From The BPv7 Standard? are listed?  That?s not strictly PICS 
style, but maybe there?s some wiggle room.
 
Scott
 
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L 
Scott via SIS-DTN
Sent: Tuesday, July 12, 2022 3:24 PM
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] Level of granularity in PICS
 
So I?m trying to clean up and have gotten to the PICS section.  Felix had 
a question about the level of granularity we need.  I?m leaning towards 
something like:
 
An entry per CLA (Optional to implement but if you DO implement that CLA, 
do it this way).
 
One entry per service (register, deregister, change, send, cancel, ?). 
Must implement this service.
 
Something about bundle format (referencing 9171)
 
Then there?s section 5 of RFC9171.  We COULD try to get away with a 
blanket statement saying that CCSDS implementation should implement all of 
the procedures in section 5, OR we could have entries for essentially each 
subsection of section 5 in RFC9171 (Bundle Transmission, Bundle 
Dispatching, Bundle Forwarding, ?).  I suppose the ?advantage? of the 
latter would be if an implementation wanted to deviate, it would be more 
?contained? in the PICS.
 
Something about admin record processing (RFC9171 section 6)
 
========
 
Thoughts on the above, especially what to do about section 5 in RFC9171?
 
                                --keith
 _______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn



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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220714/0ee871c3/attachment.htm>