<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;
mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle22
{mso-style-type:personal-compose;
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>Felix and Jeremy,<o:p></o:p></p><p class=MsoNormal>This is a good definition of this protocol so far. I have a few feedback comments to clarify some things.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>One aspect of the HPRP that doesn’t seem to be discussed is the technical relationship between HPRP and LTP in the sense that the two protocols can be disambiguated over the same (datagram) channel. They put the version code in the same starting spot in each datagram and use disjoint code points that an endpoint or a middlebox can use to distinguish them. This could be explicitly not a requirement for interoperation between LTP and HPRP over the same paths, but just to mention that it could happen and there is no problem in doing so.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In Section 3.6 I think the need from the underlying layer are not just to send and receive segment data, but when sending there must be either a notion of a destination (parameterized by engine ID perhaps) or a discussion that this parameterization assumes that the underlying layer is assumed to be point-to-point with a single peer engine (and if there are actual link addresses required those addresses need to be handled outside of the HPRP engine/layer).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In Section 3.6 it would be helpful to have an explicit statement that this protocol does not rely on there being any relation between the forward and return path taken by segments between two HPRP engines. They could involve completely separate underlying transport, framing, or link layers.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Generally about the integer fields: I don’t see any statements about the endianness of multi-octet integers. It would be good to be explicit about this, maybe at the start of Section 4.<o:p></o:p></p><p class=MsoNormal>Is there an expected use/need/benefit from non-power-of-two encoded sizes? Is there any requirement for minimum-length encodings? Can an engine choose to just use 4-octet (or whatever other fixed length) encodings for everything (assuming it fits all needed values)?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>One other nit: The “session length" field may be less confusingly called the “block length” to use the term “block” consistently with other parts of the document.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='mso-ligatures:none'>From:</span></b><span style='mso-ligatures:none'> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> <b>On Behalf Of </b>Felix Flentge via SIS-DTN<br><b>Sent:</b> Tuesday, March 5, 2024 8:10 AM<br><b>To:</b> Dr. Keith L Scott via SIS-DTN <sis-dtn@mailman.ccsds.org><br><b>Subject:</b> [EXT] [Sis-dtn] HPRP Orange Book - Draft A for Comments<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div id=APLWarningText><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 align=left><tr><td width="100%" style='width:100.0%;background:#E0E0E0;padding:0in 0in 0in 0in'><p class=MsoNormal style='mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly'><b><span style='color:red;mso-ligatures:none'>APL external email warning: </span></b><span style='color:black;mso-ligatures:none'>Verify sender <a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a> before clicking links or attachments</span><span style='mso-ligatures:none'><o:p></o:p></span></p></td></tr></table><p><span lang=EN-GB> <o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-GB>Dear All,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Jeremy and myself produced a new draft for the HPRP Orange Book.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Please note that there are still some open questions which also may lead to some updates of the data formats. In addition, we certainly need to work on the specification of the protocol behaviour.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>The document is available in Google Docs. Please add any comment you may have directly to the document.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB><a href="https://docs.google.com/document/d/1WsxgHSiG7UQNiHNHXtPOv9Dd98fK_ZKN/edit?usp=sharing&ouid=113258250953253070571&rtpof=true&sd=true">https://docs.google.com/document/d/1WsxgHSiG7UQNiHNHXtPOv9Dd98fK_ZKN/edit?usp=sharing&ouid=113258250953253070571&rtpof=true&sd=true</a><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-ligatures:none;mso-fareast-language:EN-GB'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-ligatures:none;mso-fareast-language:EN-GB'>Felix<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='mso-ligatures:none'>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 (<a href="mailto:dpo@esa.int">dpo@esa.int</a>). <o:p></o:p></span></p></div></div></body></html>