[deepspace] Re: Review comments on [e-mail]

[Marc Blanchet <[e-mail]>]

> Le 25 juin 2026 à 10:48, Wes Eddy <[e-mail]> a écrit :
> 
> Thank you; I agree w/ these comments

Same here.

Marc.

> and can work with the other editors to get them reflected in an update (assuming general agreement).
> 
> On Thu, Jun 25, 2026 at 10:24 AM Padma Pillay-Esnault <[e-mail]> wrote:
> Dear authors,
> Thank you for publishing the WG document. 
> Please find below a few comments that  would help improve clarity. I also included a few minor editorial nits at the end.
> Section 1 — Introduction
> Original text:
> “Given the evolution of modern IP application protocol stacks and the new needs of deep space missions, this document describes an architecture for the use of IP in deep space, meeting needs described in [I-D.ietf-tiptop-usecase]. This includes:
>     • running IP over end-to-end paths that include high-latency, deep space layer-2 links,
>     • buffering of IP packets, when needed,
>     • IP addressing and routing,
>     • transport protocol configuration,
>     • application protocols,
>     • and other network services, including network management of deep space IP networks.”
> 
> Comment:
> A small readability improvement would be to summarize the key architectural constraints before the document moves into deeper discussion. A short high level recap (without duplicating the use case doc referenced) could help connect the architecture choices to the constraints they address, for example:
>     • long and variable delay;
>     • intermittent and scheduled connectivity;
>     • constrained bandwidth;
>     • need for buffering / store-and-forward behavior;
>     • need for adapted transport and application timers;
>     • operational management of deep-space IP nodes;
>     • security and access-control constraints for high-value assets.
> This could be a short paragraph or a compact bullet list.
> Section 5.2 — Routing
> Original text:
> “Existing routing protocols require proof of liveness between protocol partners, implemented through the periodic exchange of packets between partners. This is impractical on long-delay or intermittent links, so a Path Computation Engine (PCE) [RFC4655] based approach seems appropriate for those domains possibly supplemented by contact plan schedules [I-D.ietf-tvr-schedule-yang].”
> Comment:
> The wording may read as if a PCE-based approach is the main expected solution.
> The text should be more deployment-neutral, since agencies and operators may use different control-plane models, including PCE, SDN, contact-plan-based routing, scheduled routing, or other mission-specific orchestration systems.
> Suggested text:
> “Existing routing protocols require proof of liveness between protocol partners, implemented through the periodic exchange of packets between partners. This is impractical on long-delay or intermittent links. Therefore, scheduled or controller-based approaches, such as PCE, SDN, contact-plan-based routing, or other mission-specific orchestration systems, may be appropriate for those domains.”Section 10 — Security Considerations / filtering and enforcement points
> Original text:
> “Given low bandwidth, low number of alternate paths, high costs of links and nodes high value, access control to the deep space network and related policies should be in place.”
> and:
> “Each tiptop forwarding node, such as celestial network edge device, shall have firewall rules to prevent inappropriate traffic from entering deep space links. If communications from Mars may only occur to Earth, but not to the Moon, then appropriate filtering based on destination IP prefixes shall be used.”
> Comment:
> One point that may benefit from clarification/definition in the document is the term “celestial network edge device.” 
> Suggested text to be added :
> “In this context, the relevant edge device is deployment-specific and may be an Earth-side gateway, provider gateway, relay, orbiter, surface gateway, or spacecraft/vehicle forwarding node. Filtering and access-control policies may therefore need to be enforced at one or more points along the path.”Minor editorial nits, in draft orderSection 4.1 — IP Forwarding and Store-and-Forward
> Original text:
> “The choice of which packets to drop depends on the policies configured on the node, which may be a to drop depends on the policies configured on the node, which may be a function of traffic class, source or destination IP addresses, flow labels, or other parameters.”
> Comment:
> This appears to contain duplicated text and should be cleaned up.
> Section 6.1 — General Transport Issues
> Original text:
> “In the near-term, and in present space mission operations, it can be assumed that data link capacity is explicitly planned and scheduled end-to-end in order to accomodate mission needs.”
> Comment:
> “accomodate” should be “accommodate”.
> Section 10 — Security Considerations
> Original text:
> “If some packets are buffered in one intermediate node, If multiple paths are possible to a destination, then bad packet injection may use an alternate faster path...”
> Comment:
> This sentence needs editorial cleanup.
> Thanks
> Padma