Stewart, thank you for this review and please see below for responses to the points you raised:
> -----Original Message----- > From: Stewart Bryant via Datatracker <[email protected]> > Sent: Monday, October 06, 2025 5:39 AM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: [rtgwg] draft-ietf-rtgwg-atn-bgp-27 early Rtgdir review > > Document: draft-ietf-rtgwg-atn-bgp > Title: A Simple BGP-based Mobile Routing System for the Aeronautical > Telecommunications Network Reviewer: Stewart Bryant Review result: Ready > > At one level this document is ready for publication subject to a few > relatively > minor comments which I include below. However, considering that this is a > safety of flight system and as such a prime target for hostile state and > non-state actors of many kinds, I was surprised at the brevity of the security > considerations. I also wonder if greater security would have been obtained > through the use of a non-native- IP overlay such as MPLS and or through a > directed path technology such as one of the SR variants. The intention of the Security Considerations section was to articulate a multi-layer security architecture with security applied as necessary at each layer in the stack. We could probably insert an introductory paragraph making this more clear, and could also probably say more about data link and physical layer security. Another reviewer also suggested a consideration of MACsec and I will add something about that. Appendix B also mentions the "secured spanning tree" as core to the security architecture - perhaps this discussion could be expanded earlier in the body of the document? > Comments: > > The draft references RFC6347 which is obsoleted by RFC9147 is this intended? Thank you. The most recent version of the standard is what is desired, so we can change this to RFC9147. > ===== > 2. Terminology > SB> An early forward reference to terminology would help in reading the > Introduction We will add something about this - thank you. > ===== > packet matches a black-hole route without matching an MNP/SNP, the > c-ASBR should drop the packet and may also generate an ICMPv6 > > SB> The should looks as if they should be expressed as RFC 2119 SHOULD. Our goal is to remain as Informational Track and avoid upper-case RFC2119 keywords. If you find the lower-case keywords too confusing, we can probably rephrase to avoid them - would that be helpful? > ====== > > The number of aircraft in operation at a given time worldwide is > likely to be significantly less than 1M, but we will assume this > number for a worst-case analysis. > > SB> 1M is undoubtedly true for the register of full sized human piloted > aircraft, but I wonder if it holds true when UAVs (drones) are added into the > mix and hence whether the obvious move towards an integrated control system > for > human in cockpit, remote piloted and autonomous aircraft would stress this > assumption. I will have to confer with my aviation community colleagues to see what the current thinking is regarding goals for a manned and unmanned integrated control system. I am slightly out of date with that community, and this may present an opportunity to catch up. Thank you - Fred Templin > _______________________________________________ > rtgwg mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
