<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Scott<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> <b>On Behalf Of </b>Dr. Keith L Scott via SIS-DTN<br><b>Sent:</b> Tuesday, July 12, 2022 3:24 PM<br><b>To:</b> sis-dtn@mailman.ccsds.org<br><b>Subject:</b> [Sis-dtn] Level of granularity in PICS<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>An entry per CLA (Optional to implement but if you DO implement that CLA, do it this way).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>One entry per service (register, deregister, change, send, cancel, …).  Must implement this service.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Something about bundle format (referencing 9171)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Something about admin record processing (RFC9171 section 6)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>========<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thoughts on the above, especially what to do about section 5 in RFC9171?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>                                --keith<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>