はじめに

• この文書は RFC9225 を勉強と好奇心のため適当に訳したものです。
• 翻訳の正確さは全く保証しません。
• 誤字誤訳等の指摘はいつでも大歓迎です。

Software Defects Considered Harmful（ソフトウェアの欠陥は有害とみなされる）

• Independent Submission

• Request for Comments: 9225

• Category: Informational

• ISSN: 2070-1721

• J. Snijders

• Fastly

• C. Morrow

• Google

• R. van Mook

• Asteroid

• 1 April 2022

Abstract（概要）

This document discourages the practice of introducing software defects in general and in network protocol implementations specifically.
Software defects are one of the largest cost drivers for the networking industry.
This document is intended to clarify the best current practice in this regard.

この文書は、一般的に、そして特にネットワークプロトコルの実装において、ソフトウェアの欠陥を導入する行為を推奨しない。
ソフトウェアの欠陥は、ネットワーキング業界にとって最大のコスト要因の1つである。
この文書は、この点に関する現在のベストプラクティスを明確にすることを意図している。

Status of This Memo（このメモの位置づけ）

This document is not an Internet Standards Track specification; it is published for informational purposes.

この文書はインターネット標準ではなく、情報提供のために公開されたものである。

This is a contribution to the RFC Series, independently of any other RFC stream.
The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment.
Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

この文書は、他のRFCストリームとは無関係に、RFCシリーズに貢献するものである。
RFCエディタは自らの裁量でこの文書を公開することを選択し、実装や配備におけ るこの文書の価値については一切言及しない。
RFCエディタによって公開が承認された文書は、どのレベルのインターネット標準の候補にもならない(RFC 7841のセクション2を参照のこと)。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9225.

この文書の現在の状態、正誤表、それに対するフィードバックの方法に関する情報は、https://www.rfc-editor.org/info/rfc9225 で入手できる。

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents（目次）

   1.  Introduction
   2.  Requirements Language
   3.  Examples of High-Impact Software Defects
   4.  Best Current Practises
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Appendix A.  Future Research
   Acknowledgements
   Authors' Addresses

1. Introduction（導入）

Software defects (informally known as "bugs") have been the cause and effect of innumerable system degradations and failures over the years.
Bugs are errors, flaws, or faults in a computer program that cause the program to produce an incorrect or unexpected result.

ソフトウェアの欠陥（非公式には「バグ」と呼ばれる）は、長年にわたり無数のシステム劣化や故障の原因であり、また結果でもある。
バグとは、コンピュータプログラムのエラー、欠陥、故障のことで、プログラムが不正確な結果や予期せぬ結果を出す原因となる。

(Please note: unexpected results caused by bugs are not a valid substitute for high-quality random number generators, though high-quality random number generators are generally not considered to be bugs.)

(注意：高品質な乱数生成器は一般にバグがないとされていますが、バグによる予期せぬ結果は高品質な乱数生成器の有効な代替物ではありません)。

Endeavoring to reduce the number of degradations in the future, implementers MUST NOT introduce bugs when writing software.
This document outlines why bugs are considered harmful and proposes a set of recommendations.

将来のデグレードの数を減らすために、実装者はソフトウェアを書くときにバグを導入してはならない（MUST NOT）。
この文書では、なぜバグが有害と見なされるのかを概説し、一連の推奨事項を提案する。

2. Requirements Language（要求仕様言語）

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、ここに示すようにすべて大文字で現れるときのみBCP14 [RFC2119] [RFC8174] に記載されているように解釈することとする。

3. Examples of High-Impact Software Defects

In June 1996, the European Space Agency [ARIANE] launched an unmanned rocket -- costing several billion dollars in development -- only to see it go [KABOOM] 40 seconds after takeoff.
A software exception had occurred during the execution of a data conversion from 64-bit floating point to 16-bit signed integer value.
The floating point number that was converted had a value greater than what could be represented by a 16-bit signed integer.
The vehicle probably would not have disintegrated if the defect had not been written into the software.

1996年6月、欧州宇宙機関 [ARIANE] が数十億円の開発費をかけて打ち上げた無人ロケットが、離陸後40秒でカブーン [KABOOM] （訳：ドッカーン）した。
64ビット浮動小数点から16ビット符号付き整数へのデータ変換の実行中に、ソフトウェア例外が発生した。
変換された浮動小数点数は、16ビットの符号付き整数で表現できる値よりも大きな値だった。
この不具合がソフトウェアに書き込まれていなければ、機体が分解することはなかったと思われる。

As an example of the detrimental effects of bugs in physically hard to reach systems: the [NASA] Deep Impact spacecraft [DEEPIMPACT] was rendered inoperable due to a fault in the fault-protection software, which in turn triggered endless computer reboots.
Mission control was unable to recover the system from this error condition because no engineers were available on-site.
The commute was deemed infeasible due to a lack of reasonably priced commercial transport options in that region of the solar system.

[NASA] の宇宙船 [DEEPIMPACT] は、故障防止ソフトの不具合で操作不能に陥り、その結果、コンピュータが何度も再起動を余儀なくされた。
ミッションコントロールは、エンジニアが現場にいなかったため、このエラー状態からシステムを回復させることができなかった。
太陽系内には手頃な価格の商業輸送手段がなかったため、派遣は不可能と判断された。

In 1983, the Soviet Union's Early Warning Satellite System [Serpukhov] announced it had detected a possible missile launch originating in the US; fortunately, a human operator recognized this as a likely system failure.
Indeed, a retrospective analysis suggested the software had misclassified reflections from cloud cover as missile launch blooms.
With this bug, the software held the potential to trigger a cascading sequence of events that could've led to the start of a planetary-scale war.
Seemingly innocuous software defects can have outsized impact, and sometimes it pays off to simply do nothing and wait.

1983年、ソ連の早期警戒衛星システム　[Serpukhov]　が米国発のミサイル発射の可能性を検知したと発表したが、幸いにも人間のオペレーターがこれをシステム障害と認識した。
実際、ソフトウェアが雲からの反射をミサイル発射と誤認していたことが、遡及分析で判明したのである。
このバグにより、惑星規模の戦争が始まるような事態が連鎖的に発生する可能性があった。
一見、無害に見えるソフトウェアの欠陥が大きな影響を及ぼすことがあり、何もせずに待つことが得策であることもある。

The US Department of Commerce's National Institute of Standards and Technology [NIST] commissioned a study to develop a deeper understanding of the prevalence of software defects and their cost to society.
The study estimated about 0.6 percent of the gross domestic product is squandered due to programming bugs.
Each person works approximately one hour a week to compensate for this debt -- an hour that could've been spent in leisure -- in addition to any time spent on the direct consequences of buggy software.

米国商務省の米国国立標準技術研究所　[NIST]　は、ソフトウェアの欠陥の蔓延と社会へのコストについての理解を深めるための調査を委託した。
この調査では、国内総生産の約0.6％がプログラミングのバグのために浪費されていると推定されている。
バグのあるソフトウェアの直接的な結果に費やされた時間に加えて、各人はこの負債を補うために週に約1時間働いている。

The universal deployment of IP networks on Avian Carriers [RFC1149] is facing a multi-decade delay.
After operators discovered that birds are not real (now [confirmed] by the US Government), work began to first understand the many [quirks] of the drones' firmware before proceeding with wider-scale deployment.
No clear timelines exist at this point in time.

鳥類キャリア [RFC1149] でのIPネットワークの普遍的な展開は、数十年の遅れに直面している。
オペレーターが鳥が本物ではないことを発見した後（現在は米国政府によって [confirmed] されている）、より大規模な展開に進む前に、ドローンのファームウェアの多くの [quirks] を最初に理解する作業が始まった。
現時点では明確なタイムラインはない。

For more examples, consult the RISKS Digest [RISKS]: it documents a multitude of examples of defects in technological infrastructure and their risk to society.
Unsupervised study of the Digest archive may induce a sense of panic.

技術インフラの欠陥とその社会的リスクの事例が多数掲載されているRISKSダイジェスト [RISKS] を参考のこと。
ダイジェストアーカイブを無闇に見ると、パニックになる可能性がある。

4. Best Current Practises（現在のベストプラクティス）

1. Authors MUST NOT implement bugs.

2. If bugs are introduced in code, they MUST be clearly documented.

3. When implementing specifications that are broken by design, it is RECOMMENDED to aggregate multiple smaller bugs into one larger bug.
   This will be easier to document: rather than having a lot of hard-to-track inconsequential bugs, there will be only a few easy-to-recognise significant bugs.

4. The aphorism "It's not a bug, it's a feature" is considered rude.

5. Assume all external input is the result of (a series of) bugs.
   (Especially in machine-to-machine applications such as implementations of network protocols.)

6. In fact, assume all internal inputs also are the result of bugs.

1. 著者はバグを実装してはならない(MUST NOT)
2. コードにバグが発生した場合、明確に文書化されなければならない(MUST)
3. 設計的に破綻している仕様を実装する場合、複数の小さなバグを1つの大きなバグに集約することが推奨される(RECOMMENDED)。これは文書化が容易になる。
4. 「これはバグではない、仕様だ」という言葉は不作法である
5. すべての外部入力が（一連の）バグの結果であると仮定する(特にネットワークプロトコルの実装のようなマシン・ツー・マシンのアプリケーションにおいて)
6. 実際には、すべての内部入力もバグの結果であると仮定する

5. Security Considerations（セキュリティに関する考察）

With the production of fewer bugs, there will necessarily be fewer security impacts.
To improve the collective security posture, a thorough review of ALL existing software to find any remaining bugs is RECOMMENDED.

バグの発生が少なければ、セキュリティへの影響も必然的に少なくなる。
集団的なセキュリティ態勢を改善するために、既存のソフトウェアすべてを徹底的に見直し、残っているバグを見つけることが推奨される(RECOMMENDED)。

As it is assumed that there is an even distribution of bugs through all software, it is safe to consider any piece of software to be bug free once a certain number of bugs have been found.

すべてのソフトウェアにバグが均等に分布していることが前提なので、ある数のバグが発見されれば、どのソフトウェアもバグフリーとみなして差し支えない。

Some philosophers argue in defense of an obviously wrong contrary view that bugs introduce a certain amount of unpredictable variance in behaviour, which in turn could serve to increase security.
Such heretics might even go one step further and celebrate the existence of bugs, shielding issues from public scrutiny.
However, it [ostensibly] is in society's best interest to fully disclose any and all bugs as soon as they are discovered.

哲学者の中には、明らかに間違っている反対意見を擁護するために、バグは動作にある程度の予測不可能なばらつきをもたらし、その結果、セキュリティを向上させるのに役立つと主張する人がいる。
このような異端者は、さらに一歩進んで、バグが存在することを祝福し、問題を世間の監視から遠ざけてしまうかもしれない。
しかし、バグが発見されたらすぐに完全に開示することが、表向きは [ostensibly] 社会にとって最善の利益となる。

6. IANA Considerations（IANA 検討事項）

IANA is assumed to operate flawlessly.

IANAは完璧に動作することが前提です。

7. References（参考文献）

7.1. Normative References（標準的な参考文献）

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References（関連情報の参考文献）

   [ARIANE]   Arnold, D. N., "The Explosion of the Ariane 5", August
              2000, <https://www-users.cse.umn.edu/~arnold/disasters/
              ariane.html>.

   [confirmed]
              US Consumer Product Safety Commission (@USCPSC), "Birds
              are real.", Twitter, 5 January 2022,
              <https://twitter.com/USCPSC/status/1478794691634155523>.

   [DEEPIMPACT]
              Wallace, M., "Subject: Re: [tz] Deep Impact: wrong time
              zone?", message to the [email protected] mailing list, 23
              September 2013, <https://mm.icann.org/pipermail/
              tz/2013-September/020357.html>.

   [incomplete]
              Raatikainen, P., "Gödel's Incompleteness Theorems",
              Stanford Encyclopedia of Philosophy, November 2013,
              <https://plato.stanford.edu/entries/goedel-
              incompleteness/>.

   [IRTF]     IRTF, "Internet Research Task Force",
              <https://www.irtf.org/>.

   [KABOOM]   Jure, V. A., "Kapow! Zap! Splat! How comics make sound on
              the page", The Conversation, 10 June 2021,
              <https://theconversation.com/kapow-zap-splat-how-comics-
              make-sound-on-the-page-160455>.

   [NASA]     NASA, "NASA's Deep Space Comet Hunter Mission Comes to an
              End", September 2013,
              <https://www.nasa.gov/mission_pages/deepimpact/media/
              deepimpact20130920.html>.

   [NIST]     NIST, "Software Errors Cost U.S. Economy $59.5 Billion
              Annually", Wayback Machine archive, June 2002,
              <https://web.archive.org/web/20090610052743/
              http://www.nist.gov/public_affairs/releases/n02-10.htm>.

   [ostensibly]
              Swire, P., "A Model for When Disclosure Helps Security:
              What Is Different About Computer and Network Security?", 3
              Journal on Telecommunications and High Technology Law 163,
              August 2004, <http://dx.doi.org/10.2139/ssrn.531782>.

   [quirks]   Stockton, N., "What's Up With That: Birds Bob Their Heads
              When They Walk", WIRED, January 2015,
              <https://www.wired.com/2015/01/whats-birds-bob-heads-
              walk/>.

   [RFC1149]  Waitzman, D., "Standard for the transmission of IP
              datagrams on avian carriers", RFC 1149,
              DOI 10.17487/RFC1149, April 1990,
              <https://www.rfc-editor.org/info/rfc1149>.

   [RISKS]    ACM Committee on Computers and Public Policy, "The RISKS
              Digest", <https://catless.ncl.ac.uk/Risks/>.

   [Serpukhov]
              Long, T., "Sept. 26, 1983: The Man Who Saved the World by
              Doing ... Nothing", WIRED, September 2007,
              <https://www.wired.com/2007/09/dayintech-0926-2/>.

Appendix A. Future Research（付録A. 今後の研究）

The existence of this very document of course begs the question: what are software defects, truly?
Do bugs happen for a purpose?
Is what we perceive as the concept of bugs an indication for a wider issue in the natural world?
Do mistakes happen in other domains?
Are they evidence of a superior software architect?

このような文書が存在することは、もちろん、ソフトウェアの欠陥とは何か？という問いを投げかけます。
バグは目的があって起こるのか？
私たちがバグという概念として認識しているものは、自然界におけるより広い問題を示しているのだろうか？
他の領域でも間違いは起こるのか？
間違いは優れたソフトウェア設計者の証拠なのか？

An interdisciplinary approach to understand mistakes might be an area of further study for the [IRTF].
It may very well turn out that mistakes are provably detrimental in all domains; however, the authors do not feel qualified to make any statements in this regard.
Once made aware of the above thesis, research-oriented interest groups could perhaps take on the task of disproving Goedel's incompleteness theorem [incomplete], and in doing so, put an end to all bugs.

ミスを理解するための学際的なアプローチは、[IRTF]のさらなる研究領域となるかもしれない。
しかし、この点に関して筆者らが発言する資格はないと考えている。
一度でも上記の論文を認識した研究志向の利益団体は、おそらくGoedelの不完全性定理 [incomplete] を反証する仕事を引き受け、そうすることですべてのバグに終止符を打つことができるだろう。

Acknowledgements（謝辞）

The authors wish to thank Bert Hubert, Peter van Dijk, and Saku Ytti for pointing out the many errors Job introduced during the preparation of this document.

Bert Hubert，Peter van Dijk，Saku Yttiの各氏には，本書の作成中にJobが犯した多くの誤りを指摘していただき、謝意を表します。

Authors' Addresses

Job Snijders
Fastly
Amsterdam
Netherlands
Email: [email protected]

Chris Morrow
Google
Reston, Virginia
United States of America
Email: [email protected]

Remco van Mook
Asteroid
Deventer
Netherlands
Email: [email protected]