hur.cn - 华软网

 热门搜索

RFC4041 - Requirements for Morality Sections in Routing Area Drafts

  作者:未知    来源:网络    更新时间:2010/9/1
Network Working Group                                          A. Farrel

Request for Comments: 4041                            Old Dog Consulting

Category: Informational                                     1 April 2005





       Requirements for Morality Sections in Routing Area Drafts



Status of This Memo



   This memo provides information for the Internet community.  It does

   not specify an Internet standard of any kind.  Distribution of this

   memo is unlimited.



Copyright Notice



   Copyright (C) The Internet Society (2005).



Abstract



   It has often been the case that morality has not been given proper

   consideration in the design and specification of protocols produced

   within the Routing Area.  This has led to a decline in the moral

   values within the Internet and attempts to retrofit a suitable moral

   code to implemented and deployed protocols has been shown to be

   sub-optimal.



   This document specifies a requirement for all new Routing Area

   Internet-Drafts to include a "Morality Considerations" section, and

   gives guidance on what that section should contain.



1.  Introduction



   It is well accepted by popular opinion and other reliable metrics

   that moral values are declining and that degeneracy is increasing.

   Young people are particularly at risk from the rising depravity in

   society and much of the blame can be squarely placed at the door of

   the Internet.  If you do not feel safe on the streets at night, what

   do you think it is like on the Information Superhighway?



   When new protocols or protocol extensions are developed within the

   Routing Area, it is often the case that not enough consideration is

   given to the impact of the protocol on the moral fiber of the

   Internet.  The result is that moral consequences are only understood

   once the protocols have been implemented, and sometimes not until

   after they have been deployed.



   The resultant attempts to restore appropriate behavior and purge the

   community of improper activities are not always easy or

   architecturally pleasant.  Further, it is possible that certain

   protocol designs make morality particularly hard to achieve.



   Recognising that moral issues are fundamental to the utility and

   success of protocols designed within the IETF, and that simply making

   a wishy-washy liberal-minded statement does not necessarily provide

   adequate guarantees of a correct and proper outcome for society, this

   document defines requirements for the inclusion of Morality

   Considerations sections in all Internet-Drafts produced within the

   Routing Area.  Meeting these requirements will ensure that proper

   consideration is given to moral issues at all stages of the protocol

   development process, from Requirements and Architecture, through

   Specification and Applicability.



   The remainder of this document describes the necessary subsections of

   the Morality Considerations sections, and gives guidance about what

   information should be contained in those subsections.



1.1.  Conventions Used in This Document



   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

   document are to be interpreted as described in RFC 2119 [RFC2119].



   The key words "SHALT", "SHALT NOT", "SMITE", and "PILLAR OF SALT" in

   this document are to be interpreted as expected.



2.  Presence and Placement of Morality Considerations Sections



2.1.  Null Morality Considerations Sections



   It may be the case that the authors of Internet-Drafts have no or few

   morals.  This does not relieve them of their duty to understand the

   consequences of their actions.



   The more likely an author is to say that a null Morality

   Considerations section is acceptable, the more pressure must be

   exerted on him by the Area and the appropriate Working Group to

   ensure that he gives full consideration to his actions, and reflects

   long and hard on the consequences of his writing and the value of his

   life.



   On the other hand, some authors are well known to have the highest

   moral pedigree: a fact that is plainly obvious from the company they

   keep, the Working Groups they attend, and their eligibility for

   NomCom.  It is clearly unnecessary for such esteemed persons to waste

   effort on Morality Considerations sections.  It is inconceivable that

   anything that they write would have anything other than a beneficial

   effect on the Routing Area and the Internet in general.



2.2.  Mandatory Subsections



   If the Morality Considerations section is present, it MUST contain at

   least the following subsections.  The content of these subsections is

   surely self-evident to any right-thinking person.  Further guidance

   can be obtained from your moral guardian, your household gods, or

   from any member of the IMM (Internet Moral Majority).



   -  Likelihood of misuse by depraved or sick individuals.  This

      subsection must fully address the possibility that the proposed

      protocols or protocol extensions might be used for the

      distribution of blue, smutty, or plain disgusting images.



   -  Likelihood of misuse by misguided individuals.  There is an

      obvious need to protect minors and people with misguided thought

      processes from utilising the protocols or protocol extensions for

      purposes that would inevitably do them harm.



   -  Likelihood of misuse by large, multi-national corporations.  Such

      a thought is, of course, unthinkable.



   -  Availability of oversight facilities.  There are those who would

      corrupt our morals motivated as they are by a hatred of the

      freedom of Internet access with which we are graced.  We place a

      significant burden of responsibility on those who guard our

      community from these evil-doers and it is only fitting that we

      give them as much support as is possible.  Therefore, all

      encryption and obfuscation techniques MUST be excluded -

      individuals who have nothing to hide need to fear the oversight of

      those whose morals are beyond doubt.



   -  Inter-SDO impact.  We must allow for other moral frameworks and

      fully respect other people's right to subscribe to other belief

      systems.  Such people are, however, wrong and doomed to spend

      eternity in a dark corner with only dial-up access.  So it has

      been written.



   -  Care and concern for avian carriers.  A duck may be somebody's

      mother.



   Even if one or more of these subsections are considered irrelevant,

   they MUST all still be present, and MUST contain a full rebuttal of

   this deviant thought.



2.3.  Optional Subsections



   Additional subsections may be added to accommodate zealots.



2.4.  Placement of Morality Considerations Sections



   The Morality Considerations section MUST be given full prominence in

   each Internet Draft.



3.  Applicability Scenarios



   This section outlines, by way of example, some particular areas that

   are in dire need of reform and where a short, sharp shock could make

   a really big difference.



3.1.  Provision of Services



   We must do our utmost to ensure that services are delivered in a

   timely and reliable way.  Emphasis should be placed on Quality of

   Service (QoS) and meeting the needs of the consumer of the service.



   Arrangements should be made for regular provision of services, and

   sermons should be to the point and contain a strong moral message.



3.2.  Political Correctness (PC)



   Political correctness has gone too far.  This problem can be traced

   way back to the 1970s when the desktop PC was invented.  It is

   necessary for Internet-Drafts to observe a form of political

   correctness, but note that you do not always have to mean what you

   say.



3.2.1.  Differentiated Services



   Segregation of packets on the grounds of color is now banned and

   Internet-Drafts must not make use of this technique.



   If you follow all of the recommendations in this document, you will

   find that "packets of color" (as we must now refer to them) tend to

   avoid your points of presence, and you will no longer be troubled by

   them.



3.2.2.  Jumbo Packets



   It is no longer appropriate to refer to "jumbo packets".  Please use

   the term "capacitorially challenged".



3.2.3.  Byte Ordering



   Note that within Internet-Drafts, bytes (and bits) progress from the

   left to the right.  This is how things should be.



3.3.  Protection or Abstinence



   Much has been made recently of the need to provide protection within

   the Internet.  It is the role of the IMM to determine when protection

   is required, and the role of the IESG bulldogs to ensure that we are

   all protected.



   However, protection is only one way to prevent unplanned outages and,

   as we all know, the ready availability of protection schemes such as

   1:1 (one-on-one) or 1:n (orgy-mode) have lead to a belief that it is

   acceptable to switch (or swing) at will.  It should be noted that

   protection can fail, and under no circumstances should extra traffic

   be countenanced.



   In reality, the only safe way to avoid passing data to your friends

   is to agree to pledge to have no control plane before marriage.  Join

   our campaign and sign up for the SONET Ring Thing.



3.4.  Promiscuity



   Various disgusting protocols indulge in promiscuity.  This appears to

   happen most often when an operator is unwilling to select a single

   partner and wants to play the field.



   Promiscuous modes of operation are an abomination, exceeded only by

   multicast.



4.  Terminology



   Admission Control

      The caring investigative arm of the IMM.



   Doom

      Port 666.  Need we say more?



   ECMP

      What is this?  Some kind of Communism?



   Money

      The root of all evil.



   MPLS

      What is with this "layer two-and-a-half" nonsense?  The world is

      flat, just accept the fact.



   Packet Switching

      Sounds like fraud to me.



   Path

      The route of all LSPs.



   Policy Control

      The administrative arm of the IMM.



   Random Walk

      Substance abuse is to be avoided.



   Rendezvous Point

      Poorly lit street corner.  Not to be confused with the root of all

      multicast.



   Standard Body

      What we should all strive for.



   Strawberry Ice Cream

      Something that wills the void between rational discussion and

      all-out thermo nuclear war [SCREAM].



5.  Morality Considerations



   The moral pedigree of the author of this document places him and his

   writings beyond question.



6.  IANA Considerations



   IANA should think carefully about the protection of their immortal

   souls.



7.  Security Considerations



   Security is of the utmost importance.



   A secure Internet community will ensure the security of all of its

   members.



8.  Acknowledgements



   I would like to thank my guru Alex Dipandra-Zinin.



   Jozef Wroblewski, who clearly knows promiscuous behavior when he sees

   it, pointed out some of the dangers in promiscuous operation.



   No avian carriers were harmed in the production of this document.



9.  Intellectual Property Considerations



   Property is theft.  What is yours is mine.  What is mine, you keep

   your hands off.



10.  Normative References



   I don't need to be told how to formulate my morals.



   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

             Requirement Levels", BCP 14, RFC 2119, March 1997.



11.  Informative References



   To be frank, I don't find many other documents informative.



   [SCREAM]  Farrel, A., "Observations on Proposing Protocol

             Enhancements that Address Stated Requirements but also go

             Further by Meeting more General Needs", Work in Progress,

             June 2003.



Author's Address



   Adrian Farrel

   Old Dog Consulting



   Phone: I'm not telling you that.  Why do you ask, anyway?

   EMail: adrian@olddog.co.uk



Full Copyright Statement



   Copyright (C) The Internet Society (2005).



   This document is subject to the rights, licenses and restrictions

   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and

   except as set forth therein, the authors retain all their rights.



   This document and the information contained herein are provided on an

   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET

   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Intellectual Property



   The IETF takes no position regarding the validity or scope of any

   Intellectual Property Rights or other rights that might be claimed to

   pertain to the implementation or use of the technology described in

   this document or the extent to which any license under such rights

   might or might not be available; nor does it represent that it has

   made any independent effort to identify any such rights.  Information

   on the procedures with respect to rights in RFC documents can be

   found in BCP 78 and BCP 79.



   Copies of IPR disclosures made to the IETF Secretariat and any

   assurances of licenses to be made available, or the result of an

   attempt made to obtain a general license or permission for the use of

   such proprietary rights by implementers or users of this

   specification can be obtained from the IETF on-line IPR repository at

   http://www.ietf.org/ipr.



   The IETF invites any interested party to bring to its attention any

   copyrights, patents or patent applications, or other proprietary

   rights that may cover technology that may be required to implement

   this standard.  Please address the information to the IETF at ietf-

   ipr@ietf.org.



Acknowledgement



   Funding for the RFC Editor function is currently provided by the

   Internet Society.


华软声明:本内容来自网络,如有侵犯您版权请来信指出,本站立即删除。