RFC 1550

IP: Next Generation (IPng) White Paper Solicitation

πŸ“… published December 1993, from ietf

IP: Next Generation (IPng) White Paper Solicitation πŸ’–

okay bestie, this is RFC 1550 πŸ¦‹ It's from the Network Working Group, written by Scott Bradner (Harvard University) and Allison Mankin (NRL). It's in the Informational category and dated December 1993. The title block doesn't list anything it obsoletes or updates, so it's just doing its own thing ✨


Status of This Memo πŸ“œ

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. so it's info, not a rulebook πŸ’…

Table of Contents πŸ—‚οΈ

1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2.   Document Review Process  . . . . . . . . . . . . . . . . . . 2
3.   Document Format Requirement  . . . . . . . . . . . . . . . . 2
4.   Outline for IPng Requirements and Concerns White Papers  . . 3
5.   Engineering considerations . . . . . . . . . . . . . . . . . 3
6.   Security Considerations  . . . . . . . . . . . . . . . . . . 5
7.   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 5
Appendix A - Formatting Rules (from RFC 1543) . . . . . . . . . . 6

1. Introduction 🌸

okay so the IPng area in the IETF (that's IP: next generation) is basically asking everyone for white papers on IPng requirements and selection criteria 🫢

all interested parties are invited to submit white papers about any specific requirements they feel an IPng must fulfill, or any factors they feel might sway the IPng selection. an example of the first kind is a utility company rep explaining the scaling and addressing features needed to bring utility meters onto the network someday ⚑ the other kind could be a paper about how parts of future network connectivity running over wireless networks might affect IPng πŸ“‘

at this time, we are NOT accepting white papers that evaluate specific IPng proposals. Those get accepted after the various proposal documents are deemed to be clear and complete. (the caps here are just for emphasis, not a BCP 14 word!)

wait wait, the caps above were a bad idea, so here it is again, calmly: at this time, we are not accepting white papers that evaluate specific IPng proposals. This type of document will be accepted after the various proposal documents are deemed to be clear and complete πŸ™ˆ

every white paper gets reviewed (more on that below) and gets the focused attention of the IPng directorate and the community πŸ‘‘ the papers become resource materials for the IPng Area working groups, the directorate, the external review board and the area directors during the selection process πŸ”₯

the deadline is February 1, 1994, but early submissions are encouraged πŸ’œ

send your white papers, general questions, topic questions, and so on to ipng-wp@harvard.edu πŸ“¬

2. Document Review Process πŸ”

first up, all submitted docs get reviewed for clarity by members of the IPng directorate and the external review board. this review might send suggestions about spots where the meaning could be confusing. authors are urged to treat those suggestions as constructive and to reexamine their text based on them 🫢

then there's a separate technical review of the white paper. this one looks at the paper within the context of the document. it still won't make value judgments on the white papers, but it does assess technical feasibility. this review might also send suggestions to the author ✨

the document gets submitted as an Internet-Draft after these reviews are done and after whatever (if any) revisions the author decides to make. after a suitable period of time, these documents get submitted as informational RFCs unless the author withdraws them. they'll be part of the historical record of the IPng process πŸ“œπŸ¦‹

3. Document Format Requirements πŸŽ€

all white papers must follow the format requirements listed in RFC 1543, and must not exceed 10 pages in length. (the relevant bit of RFC 1543 is included in this document as Appendix A, bestie πŸ’–) they should not include the "status of memo" section, since that gets added when the docs are posted as Internet Drafts.

the reference version of the document must be in ASCII, as is current practice with all RFCs πŸ’» a PostScript version may be submitted in addition to the ASCII version. (see RFC 1543 for the formatting procedures to use with PostScript documents 🧚)

4. Outline for IPng Requirements and Concerns White Papers 🌈

this section is the white paper outline for anyone who wants to share an opinion about the factors in the IPng definition and selection process. these docs get used as resource material by the various IPng working groups, the directorate, the external review board and the area directors, so they should be well-focused and give specific references to data supporting their points πŸ“Š

each white paper should begin with an executive summary of its important points. that executive summary must not exceed 1/2 page in length 🌸

after that, the white paper should address the issue or issues the author feels should be understood during the IPng process. the total document must not exceed 10 pages in length. an author may submit more than one white paper if he or she feels the level of detailed discussion on each topic warrants it πŸ’…

5. Engineering considerations 🧠

in past discussions, the following issues have been raised as relevant to the IPng selection process. this list is in no particular order πŸŒ€ any or all of these issues may be addressed, as well as any other topic the author feels is germane, but do not exceed the 10 page limit, please πŸ™

5.1 Scaling πŸ“ˆ

what's a reasonable estimate for the scale of the future data networking environment? the current common wisdom is that IPng should be able to deal with 10 to the 12th nodes 🀯

5.2 Timescale ⏳

what are reasonable time estimates for the IPng selection, development and deployment process, or what should the timeframe requirements be? this topic is being evaluated by the ALE working group, and a copy of all white papers that express opinions about these topics will be forwarded to that group πŸ“¨

5.3 Transition and deployment 🚚

transition from the current version to IPng will be a complex and difficult process. what are the issues that should be considered The TACIT working group will be discussing these issues, and a copy of all white papers that express opinions about these topics will be forwarded to that group 🫠

5.4 Security πŸ”

what level and type of security will be required in the future network environment? what features should be in an IPng to facilitate security? πŸ”’

5.5 Configuration, administration and operation πŸ› οΈ

as networks get larger and more complex, the day to day operational aspects become ever more important. what should an IPng include or avoid in order to minimize the effect on the network operators? πŸ™ˆ

5.6 Mobile hosts πŸ“±

how important is the proliferation of mobile hosts to the IPng selection process? to what extent should features be included in an IPng to assist in dealing with mobile hosts? 🧳

5.7 Flows and resource reservation 🌊

as data networks begin to get used for an increasing number of time-critical processes, what are the requirements or concerns that affect how IPng should facilitate the use of resource reservations or flows? ⚑

5.8 Policy based routing πŸ—ΊοΈ

how important is policy based routing? if it's important, what types of policies will be used? what requirements do routing policies and potential future global architectures of the Internet bring to IPng? how do policy requirements interact with scaling? πŸ€”

5.9 Topological flexibility πŸ•ΈοΈ

what topology is anticipated for the Internet? will the current general topology model continue? is it acceptable (or even necessary) to place significant topological restrictions on interconnectivity of networks? 🧩

5.10 Applicability πŸ›οΈ

what environment or marketplace do you see for the application of IPng? how much wider is it than the existing IP market? πŸ’œ

5.11 Datagram service πŸ“¦

existing IP service is "best effort" and based on hop-by-hop routed datagrams. what requirements for this paradigm influence the IPng selection? 🫢

5.12 Accounting 🧾

how important a consideration should the ability to do accounting be in the selection of an IPng? what, if any, features should be included in an IPng to support accounting functions? πŸ’°

5.13 Support of communication media πŸ“Ά

IPv4 can be supported over most known types of communications media. how important is this same flexibility to an IPng? 🌈

5.14 Robustness and fault tolerance πŸ›‘οΈ

to the extent that the Internet built from IPv4 has been highly fault tolerant, what are ways IPng may avoid an inadvertent decrease in robustness (since some things may work despite flaws that we do not understand well)? comment on any other ways this requirement may affect the IPng 🧸

5.15 Technology pull 🧲

are there technologies that will pull the Internet in a way that should influence IPng? can specific strategies be developed to encompass these? πŸš€

5.16 Action items βœ…

suggested charges to the directorate, working groups or others to support the concerns or gather more information needed for a decision πŸ“


6. Security Considerations 🚨

this one is serious, bestie 😭 This RFC raises no security issues, but it does invite comment on the security requirements of IPng. so if you have thoughts on IPng security, this is literally your invitation πŸ”

7. Authors' Addresses πŸ’Œ

Scott Bradner
Harvard University
10 Ware St.
Cambridge, MA 02138

Phone: (617) 495-3864

EMail: sob@harvard.edu


Allison Mankin
Naval Research Laboratory
c/o Code 5591
Washington D.C. 20375-5000

Phone: 202-404-7030

EMail: mankin@cmf.nrl.navy.mil

Appendix A - Formatting Rules (from RFC 1543) πŸŽ€

Note: there's a set of NROFF formatting macros for the following format. please contact ipng-wp@harvard.edu if you'd like a copy πŸ’Œ

3a. ASCII Format Rules πŸ–‹οΈ

the character codes are ASCII.

each page must be limited to 58 lines, followed by a form feed on a line by itself.

each line must be limited to 72 characters, followed by carriage return and line feed.

no overstriking (or underlining) is allowed.

these "height" and "width" constraints include any headers, footers, page numbers, or left side indenting.

do not fill the text with extra spaces to provide a straight right margin.

do not do hyphenation of words at the right margin.

do not use footnotes. if such notes are necessary, put them at the end of a section, or at the end of the document.

use single spaced text within a paragraph, and one blank line between paragraphs.

the number of pages in a document, and the page numbers on which various sections fall, will likely change with reformatting. so cross references in the text by section number are usually easier to keep consistent than cross references by page number πŸ’–

πŸ“¦ where this page comes from