Hi, > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. -->
I’ll propose: IS-IS, MPLS, Segment routing > 2) <!--[rfced] Since "LSP" stands for "Link State Protocol Data Unit" per > this document, we removed "IS-IS" from its expansion in the terms > list (Section 1.2) and included it in the next sentence as shown > below. Please let us know if this is incorrect. > > Original: > LSP: IS-IS Link State Protocol Data Unit. An LSP is a set of > packets that describe a node's connectivity to other nodes. > > Current: > LSP: Link State Protocol Data Unit. An IS-IS LSP is a set of > packets that describe a node's connectivity to other nodes. > --> That’s fine. > 3) <!--[rfced] To avoid the redundancy of "Orbit orbits" in this sentence > (i.e., when "LEO" and "GEO" are expanded, it becomes "between Low > Earth Orbit and Geostationary Earth Orbit orbits"), may we remove > "orbits" as shown below? > > Original: > MEO: Medium Earth Orbit. A satellite in MEO is between LEO and GEO > orbits and has an altitude between 2,000km and 35,786km. > > Perhaps: > MEO: Medium Earth Orbit. A satellite in MEO is between LEO and GEO > and has an altitude between 2,000 km and 35,786 km. > --> That’s fine. > 4) <!--[rfced] In the first sentence of Section 2.1, should "parent > planet" perhaps be "parent planets", or is this referring to one > planet? > > Original: > Satellites travel in specific orbits around their parent planet. > Some of them have their orbital periods synchronized to planetary > rotation, so they are effectively stationary over a single point. > > Perhaps: > Satellites travel in specific orbits around their parent planets. > Some of them have their orbital periods synchronized to planetary > rotation, so they are effectively stationary over a single point. > --> Plural is fine. > 5) <!--[rfced] We updated three instances of "not discussed further" to > "not discussed further in this document". If that is not correct, > please let us know. > > One example (see the text for more instances) > > Original: > The architecture of the terrestrial network is assumed to > be a typical IS-IS and BGP deployment [RFC4271] and is > not discussed further. > > Current: > The architecture of the terrestrial network is assumed to > be a typical IS-IS and BGP deployment [RFC4271] and is > not discussed further in this document. > --> All fine. > 6) <!--[rfced] We updated the last part of this sentence from "and the > structure can scale" to "so that the structure can scale" for > clarity. Please let us know if this is incorrect. > > Original: > The goal of the routing architecture is to provide an organizational > structure to protocols running on the satellite network such that > topology information is conveyed through relevant portions of the > network, that paths are computed across the network, and that data > can be delivered along those paths, and the structure can scale > without any changes to the organizational structure. > > Current: > The goal of the routing architecture is to provide an organizational > structure to protocols running on the satellite network such that > topology information is conveyed through relevant portions of the > network, paths are computed across the network, and data > can be delivered along those paths so that the structure can scale > without any changes to the organizational structure. > --> The intent here was to express that scalability is one of the overall goals. Possible rewording: NEW TEXT The goal of the routing architecture is to provide an organizational structure to protocols running on the satellite network such that topology information is conveyed through relevant portions of the network, paths are computed across the network, data can be delivered along those paths, and the structure can scale without any changes to the organizational structure. > 7) <!-- [rfced] FYI - We added the expansion for "TI-FLA". Please let us know > of > any objections. > > Original: > These can be avoided by using TI-LFA alternate paths > [I-D.ietf-rtgwg-segment-routing-ti-lfa], or traffic > will loop until discarded based on its TTL. > > Current: > These can be avoided by using Topology Independent Loop-Free > Alternate (TI-LFA) paths [SR-TI-LFA]; otherwise, traffic will > loop until discarded based on its TTL. > --> Looks good > 8) <!--[rfced] Please clarify "into the global Internet" in this > sentence. Do gateways advertise prefixes to cover all of their > local user stations perhaps "across the global Internet" or > "including those in global Internet"? > > Original: > Gateways and their supporting terrestrial networks advertise > prefixes covering all its local user stations into the > global Internet. > > Perhaps: > Gateways and their supporting terrestrial networks advertise > prefixes to cover all its local user stations across the > global Internet. > --> Specifically, gateways would be using BGP to advertise the prefixes for the local user stations. As usual, BGP would propagate the information throughout all of the autonomous systems of the entire Internet. I view this as injection “into” the Internet as the information necessarily ends up residing in all transit operators. The word “across” would imply to me that transit systems are not involved, which is not the case. > 9) <!-- [rfced] Please clarify what "this" in "this architecture" refers > to. Is it the "forwarding plane" or "on-stripe" architecture? > > Original: > 6. Traffic Forwarding and Traffic Engineering > > Forwarding in this architecture is straightforward. > > Perhaps: > 6. Traffic Forwarding and Traffic Engineering > > Forwarding in the forwarding plane architecture is straightforward. > --> The whole document presents a single architecture: routing, addressing, and forwarding are all coupled. > 10) <!-- [rfced] FYI: For [ISO10589], we have made the following updates: > > a) The original URL navigates to a page where the .zip file is downloaded, so > we have replaced this URL with the main page for ISO/IEC 10589:2002, which > includes a link to download the file. Ok > b) We also changed the title of this reference to reflect the title of the > document. > > Please let us know if there are any objections. > > Original: > [ISO10589] International Organization for Standardization, > "Intermediate System to Intermediate System Intra-Domain > Routing Exchange Protocol for use in Conjunction with the > Protocol for Providing the Connectionless-mode Network > Service (ISO 8473)", ISO/IEC 10589:2002 , November 2002, > <https://standards.iso.org/ittf/ > PubliclyAvailableStandards/ > c030932_ISO_IEC_10589_2002(E).zip>. > > Current: > [ISO10589] ISO/IEC, "Information technology - Telecommunications and > information exchange between systems - Intermediate System > to Intermediate System intra-domain routeing information > exchange protocol for use in conjunction with the protocol > for providing the connectionless-mode network service (ISO > 8473)", ISO/IEC 10589:2002, November 2002, > <https://www.iso.org/standard/30932.html>. > --> I would argue that that’s part of their taxonomy and not actually part of the title, but I can live with it either way. > 11) <!-- [rfced] FYI: For [Bell], we have updated the URL to match the URL > from > the DOI provided. > > Note that this new URL is the official page of the American Journal of Science > and still provides an open access PDF. > > Original: > [Bell] Bell, A. G., "On the Production and Reproduction of Sound > by Light", American Journal of Science Third Series. XX > (118): 305-324., DOI 10.2475/ajs.s3-20.118.305, October > 1880, <https://zenodo.org/records/1450056>. > > Current: > [Bell] Bell, A. G., "On the Production and Reproduction of Sound > by Light", American Journal of Science, vol. S3-20, no. > 118, pp. 305-324, DOI 10.2475/ajs.s3-20.118.305, October > 1880, <https://ajsonline.org/article/64037>. > --> Thank you. > 12) <!-- [rfced] FYI: For [Cao], we have updated the URL to match the URL from > the DOI provided. > > Note that this change was made because the original URL was a direct download > of the PDF file. Also, please note that the full text of the document is still > available at this URL as well as the link to download the PDF file. > > Original: > [Cao] Cao, X., Li, Y., Xiong, X., and J. Wang, "Dynamic Routings > in Satellite Networks: An Overview", Sensors (Basel, > Switzerland), 22(12), DOI 10.3390/s22124552, 2022, > <https://www.mdpi.com/1424-8220/22/12/4552/ > pdf?version=1655449925>. > > Current: > [Cao] Cao, X., Li, Y., Xiong, X., and J. Wang, "Dynamic Routings > in Satellite Networks: An Overview", Sensors, vol. 22, no. > 12, p. 4552, DOI 10.3390/s22124552, 2022, > <https://www.mdpi.com/1424-8220/22/12/4552/ > pdf?version=1655449925>. > --> Ok > 13) <!-- [rfced] For [ITU], we found the most current version of this > reference at > the URL below. May we update this reference to use the most current > version? Note that this would include updating the date from 2016 to > 2024. > > Current: > [ITU] ITU, "Radio Regulations - Articles", 2016, > <https://search.itu.int/history/ > HistoryDigitalCollectionDocLibrary/1.43.48.en.101.pdf>. > > Perhaps: > [ITU] ITU, "Radio Regulations - Articles", 2024, > <https://search.itu.int/history/ > HistoryDigitalCollectionDocLibrary/ > 1.49.48.en.101.pdf#search=radio%20regulation>. > --> Thanks, that’s fine. > 14) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > For example, please consider whether "traditional" should be updated for > clarity. > > While the NIST website > <https://www.nist.gov/nist-research-library/nist-technical-series-publications- > author-instructions#table1> > indicates that this term is potentially biased, it is also ambiguous. > "Tradition" is a subjective term, as it is not the same for everyone. > —> No changes. While “traditional” may be subjective when used in a cultural context, this is a purely techinical context, where the historical approaches to the deployment of routing protocols is not subjective. T -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
