[Sis-dtn] Level of granularity in PICS

[sburleig.sb at gmail.com]

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220713/6ed13af9/attachment.htm>