Internet DRAFT - draft-hallambaker-iab-deployment

draft-hallambaker-iab-deployment







Network Working Group                                    P. Hallam-Baker
Internet-Draft                                               May 3, 2019
Intended status: Informational
Expires: November 4, 2019


                     The Devil is in the Deployment
                  draft-hallambaker-iab-deployment-00

Abstract

   The defining feature of a standard is that it be widely, preferably
   ubiquitously used.  The deployment strategies of previous protocol
   standardization efforts are compared and best practice suggested for
   application and infrastructure protocol deployment strategies are
   described.  Recommendations for enabling deployment of specific
   protocols and for future IETF working practices are made.

   This draft is a generalization of the principles used to develop the
   deployment strategy for the Mathematical Mesh.  Many documents
   describing deployment considerations have been developed during the
   development of the Mesh and these have motivated many changes to the
   design during the course of development.

   The Mesh is consciously and deliberately modeled on the same
   strategies that succeeded in the Web. Some of these strategies are
   well known:

   Other parts of the Web strategy have not been widely discussed.  This
   paper presents some parts of the strategy most relevant to the IAB
   workshop program.

   This document is also available online at
   http://mathmesh.com/Documents/draft-hallambaker-iab-deployment.html
   [1] .

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Hallam-Baker            Expires November 4, 2019                [Page 1]

Internet-Draft               PHB Deployment                     May 2019


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 4, 2019.

Copyright Notice

   Copyright (c) 2019 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Lessons from History  . . . . . . . . . . . . . . . . . . . .   2
     1.1.  The World Wide Web  . . . . . . . . . . . . . . . . . . .   3
     1.2.  IPv6  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.1.  Recommendations . . . . . . . . . . . . . . . . . . .   7
     1.3.  DNSSEC and DANE . . . . . . . . . . . . . . . . . . . . .   7
       1.3.1.  DANE  . . . . . . . . . . . . . . . . . . . . . . . .   9
       1.3.2.  DPRIV . . . . . . . . . . . . . . . . . . . . . . . .  10
   2.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .  10
     2.1.  Purpose of the IETF . . . . . . . . . . . . . . . . . . .  10
     2.2.  Design for Deployment . . . . . . . . . . . . . . . . . .  11
     2.3.  Identify Stakeholders and Gatekeepers . . . . . . . . . .  12
     2.4.  Realistic Schedules . . . . . . . . . . . . . . . . . . .  12
     2.5.  Eliminate Deployment Dependencies . . . . . . . . . . . .  13
     2.6.  Recognize Failure . . . . . . . . . . . . . . . . . . . .  14
     3.1.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Lessons from History

   When the Internet was first being developed, the number of hosts was
   zero and the user community was highly motivated to adopt new
   technologies because they were developing them.  Today the Internet
   has four billion users and forty years of legacy infrastructure.  If
   we are going to improve our record of deploying new developments we
   must look past the earliest pioneering days and focus on deployment




Hallam-Baker            Expires November 4, 2019                [Page 2]

Internet-Draft               PHB Deployment                     May 2019


   of technologies developed since the Internet had grown in size to the
   point where deployment was a primary design constraint.

   If we are going to succeed in being relevant, we must design for
   deployment.  We also have to have the courage to learn from past
   mistakes.  Reminding people of past mistakes is never popular but
   learning from them is the only way to avoid them.

1.1.  The World Wide Web

   Contrary to subsequent histories, the success of the World Wide Web
   was neither inevitable nor an accidental consequence of the design.
   The Web was neither the first network hypertext system proposed or
   the best funded.  Then the Web was demonstrated in public for the
   first time late in 1992, there were two dozen competing schemes and
   the only developers paid to work on the Web full time were Tim
   Berners-Lee himself and one intern.

   Having read and re-read the www-talk archives many times during
   research of prior art, it is clear that deployment was of paramount
   concern in the design of URLs, HTTP and HTML.  The scheme prefix was
   added to the original HTTP locator in response to Dan Connolly's
   suggestion that the Web should permit access to any resource
   regardless of the access protocol.  The port field was added after
   developers complained that they could not run a Web server because
   they lacked the system privileges then required to bind to port
   numbers lower than 1024.  SGML was adopted as the basis for the
   markup language in spite of rather than because of its technical
   merits.

   The success of the Web was in part due to the fact that it was
   designed to solve a specific set of problems rather than to realize
   Ted Nelson's vision.  Stripping out difficult to implement features
   (search, payments, referential transparency) from the core allowed
   them to be solved separately as demand and resources permitted.

   But more important than the design was the fact that the Web offered
   a dramatically lower cost of deployment than any of its rivals.  At
   the time 'free software' generally came at the cost of several days
   effort trying to get the source code to compile.  Pricing for
   commercial software was based on a fraction of the price of the
   machine on which it ran which ranged from the tens of thousands to
   the millions of dollars.

   The Web clients and servers were free for non-commercial use and the
   implementations developed by NCSA had been developed with US
   government grants.  This last consideration was of key importance in




Hallam-Baker            Expires November 4, 2019                [Page 3]

Internet-Draft               PHB Deployment                     May 2019


   the Clinton administration decision to use the Web as the basis for
   realizing Al Gore's vision of an 'Information superhighway'.

   Work on gaining the endorsement of the White House began before the
   1992 presidential election.  The MIT AI lab had begun its Intelligent
   Information Infrastructures project which put material from all the
   campaigns online a year earlier.  I made contact with Jock Gill who
   was then in charge of the Clinton-Gore campaign and proposed that the
   White House deploy a Web site.

   The launch of the IBM PC a decade earlier had validated the use of
   the 'microcomputer' as a business tool.  Before the IBM PC, the
   priority of most MIS departments was to maintain their monopoly.  As
   an intern at ICI, I spent four months writing code to screen scrape
   reports from the IBM mainframe so that my boss could analyze them
   with Lotus 123.  My predecessor had had to work with a machine hidden
   in a cupboard so the MIS department couldn't find and confiscate it.
   The IBM endorsement of the microcomputer legitimized the
   microcomputer and I wanted a similar endorsement for the Web.

   The strategy paid off.  Before the launch of whitehouse.gov, we could
   persuade almost no businesses outside the computing industry to adopt
   the Web. This was not for lack of effort and despite the fevered
   press reporting on the thousand percent per week growth rate of the
   Web. After whitehouse.gov was launched, there was no need for
   persuasion.  The Web was growing of its own accord.

   Another endorsement that was aggressively pursued was Microsoft.
   This initiative was taken by Robert Cailliau over the course of many
   months in 1993.  Subsequent attacks on Microsoft for 'stealing' the
   Web technologies has always rankled me.  The truth of the matter is
   that we gave them the technology and pleaded with them to distribute
   it.

   In summary, the Web succeeded because it was designed for deployment
   and we aggressively pursued key endorsements to market it.  A
   necessary part of the design for deployment approach was abandoning
   approaches that were regarded as sacrosanct in the field for reasons
   that turned out to be grounded in ideology rather than technology.

1.2.  IPv6

   Despite work on IPv6 starting at the same time as the Web and despite
   the fact that the projected growth rate of the Internet was projected
   to exhaust the IPv4 address space in 1998, deployment of IPv6
   continues to fall short of expectations.





Hallam-Baker            Expires November 4, 2019                [Page 4]

Internet-Draft               PHB Deployment                     May 2019


   It is arguable that the delay in adoption of IPv6 is in part due to
   the success of the Web. Wide Area Networking was growing at an
   exponential rate before the Web appeared on the scene.  But the Web
   caused the Internet to kill off the competing WAN protocols.  Had
   that occurred in 1997, the transition to IPv6 might conceivably have
   been completed first.  But Internet supremacy became inevitable in
   1995 instead meaning that it was IPv4 not IPv6 that became
   ubiquitous.

   Deployment of the Internet has been driven by two killer
   applications: Email and the Web. And here there is an ironic twist.
   Over 1993 the proportion of Internet users who were Web users rose
   from ~0% to ~100% because the URL scheme field delivered
   interoperability.  But from the start of 1994 to the end of 1995 the
   percentage of global WAN traffic that was Internet traffic grew from
   under 20% to over 80% and this change was likely driven by the Web's
   lack of interoperability.

   In 1992, the primary applications for academic computer networks were
   remote access, email and file transfer.  As a graduate student in the
   UK the primary WAN networks I made use of were HEPNET which ran on
   DECNET phase 4 and JANET which ran a protocol stack called coloured
   books.  I did not have direct access to the Internet from my Oxford
   University machine but I could access Internet machines in Germany
   via HEPNET.  I could also exchange email with Internet users via a
   mail gateway which used the heuristic that email addresses beginning
   with com. or edu. were Internet addresses and reverse the big-endian
   addressing convention adopted by JANET.  Remote access and file
   transfer could be achieved using similar (but less reliable)
   techniques.

   Before the Web, attempts to secure funding for access to any computer
   network other than JANET were an exercise in futility.  The only
   person with decision making power was the Secretary of State for
   Education who was most unlikely to fund a rival to the system his own
   department was paying to build.  Not least because the advisory board
   was staffed by the people who were developing it.  Any attempt to
   propose use of a rival technology was easily defeated by pointing out
   that JANET afforded access to the exact same resources.

   The Web changed this calculus because even though the Web itself
   could run on other protocols, it was the content that the users
   wanted access to and that was only available on the Internet (at
   least as far as the Minister was aware).

   The first point of this apparent digression is that while these
   political considerations may sound petty and short sighted, they are
   the exact considerations that gave rise to a particular



Hallam-Baker            Expires November 4, 2019                [Page 5]

Internet-Draft               PHB Deployment                     May 2019


   interpretation of the 'end to end' principle which insists that the
   IP address remains constant end-to-end, an interpretation that
   appears nowhere in the original papers.  The point of 'IP end-to-end'
   was that applications work a lot better without unnecessary
   translations from one protocol stack to another and back.  Government
   sponsorship can be a powerful driver of early adoption.  It can also
   lead to a situation in which the market is deadlocked in a format
   war.

   The second point of the digression is that 'IP end-to-end' became
   ideology, a slogan.  Any suggestion that NAT was beneficial was
   attacked using exclusionary tactics.  I was attacked in very
   unpleasant terms for suggesting that I had no intention of paying my
   ISP $10/month for each device added to my home network when I could
   do the same thing for free using NAT.  Since I now have 200 devices
   on my home network, this would cost me $24,000 a year.

   To the extent there was a deployment strategy for IPv6, it was to
   raise concern that exhaustion of the address space was imminent and
   make dire predictions of the consequences of this happening while
   discouraging the use of NAT or other techniques that might mitigate
   the problem.  This approach was unsustainable.  The main party that
   would suffer if the IPv4 address poll was exhausted was the ISPs.  In
   1998, I was amused when a neighbor reported that the broadband
   provider I had abandoned because their TOS did not permit use of NAT
   had shipped him a new router with NAT enabled by default.  I was
   further amused when I read the new TOS to find that use of NAT was
   still prohibited.

   The argument made against NAT was that users were not going to move
   to IPv6 unless the new protocol offered new features.  The reverse is
   in fact the case.  Even today, IPv6 is not a choice for most Internet
   users.  It is a feature their ISP does or does not provide.  Or more
   accurately, it is a feature that some of the multiple ISPs that a
   user might rely on in a single day might provide.  Differentiating
   IPv6 by offering additional features to application developers is
   doomed to failure because the IP is a network layer capability that
   the application protocol designer does not and indeed cannot rely on.

   The OSI layered model is a poor guide to the Internet protocol stack
   but the principles of abstraction and encapsulation are not.  An
   application layer protocol has no business dealing in network layer
   addresses.  We should regard application protocols that rely on IP
   addresses being constant end-to-end as being poorly architected
   rather than attempting to police global provision of Internet
   services to enforce a misfeature.





Hallam-Baker            Expires November 4, 2019                [Page 6]

Internet-Draft               PHB Deployment                     May 2019


1.2.1.  Recommendations

   Rather than trying to drive deployment of IPv6 by limiting the
   functionality of the IPv4 Internet, we should attempt to eliminate as
   many differences as possible.  Our end goal should be to improve
   network capabilities as quickly as possible rather than to achieve
   IPv4 sunset as quickly as possible.

   What is important is that we have enough addresses to allow the
   Internet to continue to grow.  NAT has allowed the number of devices
   connected to the Internet to exceed the number of IPv4 addresses by
   at least an order of magnitude by allowing multiple devices at the
   same site to share the same address.  The effectiveness of this
   strategy will inevitably decline as the number of sites begins to
   approach the number of available addresses.

   The priority therefore should be to make access to the IPv6 backbone
   as ubiquitous as possible, including access using devices that are
   not IPv6 capable and never will be.

   I have 200 devices on my home network of which only 20 are configured
   for use of IPv6.  I am not replacing my 36" plotter just so that I
   can connect via IPv6.  Nor do I plan to open up walls or climb
   ladders to do so.  Nor is anyone else in a similar position going to
   do so.  But every one of those devices could function as if it were
   IPv6 capable as far as the rest of the Internet was concerned if the
   NAT box connecting my home network to the Inter-network was
   appropriately configured.

   Deployment cannot be advanced by withholding features, but it can be
   advanced by offering better performance.  Users demand gigabit
   connection speeds because they believe they will deliver performance.
   Users are likely to demand an IETF specified suite of RFC compliances
   if they believe that this will provide better performance.  But the
   industry can only follow the IETF lead if the IETF recommendation is
   actionable.  'Stop using IPv4' is not actionable today and will not
   be actionable as far as the home user is concerned within our
   lifetimes.  A recommendation that ISPs provide IPv6 to the home/
   enterprise and that every home router support a feature set that
   allows every device connected to the local network to make full and
   transparent use of that capability is actionable.

1.3.  DNSSEC and DANE

   Like IPv6, DNSSEC was also proposed at roughly the same time as the
   Web and it is generally argued that deployment of DNSSEC was eclipsed
   by the rise of a Web technology.  The introduction of SSL (now TLS)
   led to the deployment of what is now known as the WebPKI, one of only



Hallam-Baker            Expires November 4, 2019                [Page 7]

Internet-Draft               PHB Deployment                     May 2019


   two Internet security protocols that has approached ubiquitous
   deployment in its field of use (the other being the closely related
   SSH).

   This is a misconception as the WebPKI was developed to provide a
   sufficient accountability infrastructure to enable Internet commerce.
   The DNSSEC was never intended to provide a form of authentication
   that was sufficient for accountability.  But neither is the WebPKI
   capable of supporting what should have been the primary objective of
   DNSSEC: Authenticated distribution of security policy.

   One of the chief problems faced in deployment of DNSSEC was that
   until critical mass is reached, the network effect works against
   deployment.  DNS services were typically consumed through operating
   system services and no major operating platform provider was going to
   provide support for DNSSEC until there was customer demand.  No
   customer was going to demand support for DNSSEC in the operating
   system until they could register their keys in their domain and the
   registries were not going to support registration of keys until there
   was some means of using them.

   The first time the CEO of any major Internet technology provider
   mentioned DNSSEC was when Stratton Sclavos gave the potential for
   deployment of DNSSEC as one of the major potential benefits of the
   acquisition of Network Solutions in 2000.  At that point, VeriSign
   was the only major stakeholder in the DNS infrastructure endorsing
   deployment of DNSSEC.

   The endorsement was not appreciated by the DNS community.  One of the
   DNSEXT chairs who was also a member of the IESG repeatedly
   demonstrated open hostility to the name 'VeriSign' and anyone
   associated with the company.

   In 2001, detailed examination of the DNSSEC deployment requirements
   revealed that the implementation of the NSEC record as it was then
   specified would require every zone to be signed, increasing the size
   of the zone file by more than an order of magnitude.  This would in
   turn require substantial changes to the architecture of the ATLAS
   infrastructure then being developed.  Storing the complete zone file
   at every node would require more than 4GB of memory and thus require
   the use of 64 bit machines which would add an estimated $30 million
   to the cost.  Re-engineering the system to partition the database
   would delay deployment by a year at least.

   These facts and a technical proposal that addressed the issue were
   presented.  One of the responses to the proposal was that if the .com
   zone was too large to be signed using DNSSEC, the correct solution
   was to reduce the size of .com, not to change DNSSEC.  While I was



Hallam-Baker            Expires November 4, 2019                [Page 8]

Internet-Draft               PHB Deployment                     May 2019


   not surprised the statement was made, it should perhaps have been
   surprising that nobody laughed.

   Besides delaying the start of actual DNSSEC deployment by a decade,
   the situation came very close to litigation that could have
   bankrupted the IETF.  When Sclavos resigned in 2007, one of the
   principle complaints of his performance made by the board was the
   failure to show synergies between the businesses he had acquired, in
   particular the failure to deploy DNSSEC.

   Attempts to deploy DANE and DPRIV have fallen victim to similarly
   blinkered thinking.

1.3.1.  DANE

   DANE was an attempt to use the DNS to provide certification of server
   keys and distribute security policy using the DNS.  Despite repeated
   warnings, the working group never recognized that attempting to
   achieve both goals in one system would introduce constraints that
   doomed deployment.

   At the time DANE was proposed, most DNS registrars operated their
   domain name registration businesses as a loss leader for their other
   services.  The major profit center for most being sale of TLS
   Certificates.  The same DNS registrars were the gatekeeper for
   deployment of DNSSEC.

   Had the scope of DANE been limited to issue of free certificates,
   DNSSEC need not have been an essential requirement and the registrars
   would not have been gatekeepers for the deployment of DANE and the
   fact that DANE would eliminate their main source of earnings would
   not have mattered.  But DANE was also intended to be a means of
   publishing security policy information and in particular to tell
   clients that they must use TLS.  This meant that deployment of DANE
   was necessarily dependent of deployment of DNSSEC.

   Had deployment of DANE and DNSSEC been decoupled so that one could be
   used without the other if necessary, a virtuous cycle of deployment
   might have been realized in which the success of one encouraged the
   other.

   To this day, very few DNS registrars advertise support for DNSSEC and
   none that I am aware of facilitate use of DANE TLSA records.








Hallam-Baker            Expires November 4, 2019                [Page 9]

Internet-Draft               PHB Deployment                     May 2019


1.3.2.  DPRIV

   DPRIV was an attempt to provide confidentiality for DNS protocol
   communications between end user clients and resolution services.

   As with DANE and DNSSEC, the deployment constraints the Web browser
   providers were ignored and the design was predicated on an undeployed
   technology.

   DPRIV did have the backing of VeriSign, the primary DNS operator.
   But the Web browser providers did not express interest.  Recognizing
   the urgent need to protect the confidentiality of DNS traffic, the
   working group decided to complete its work in a year.  This in turn
   constrained the choice of cryptographic protection to TLS and since
   TLS is layered on TCP/IP, this meant DPRIV could only come close to
   meeting the latency requirements set by the browser providers if TCP
   Fast Open, an experimental technology was used.

2.  Recommendations

   Almost any advice on deployment strategy is likely to prove useful.
   The one counterexample being the advice that is most frequently
   given: To give up on any hope of making changes because the scale of
   the Internet has made all new infrastructure deployment impossible.

   The Internet can and does change.  New protocols and protocol
   features are developed and successfully deployed every day.  Only a
   small fraction of that work takes place in the IETF and for every
   project that succeeds, ten or perhaps a hundred fail.  But even work
   that is a failure is worthwhile if at least one other person learns a
   lesson that allows another project to succeed.

2.1.  Purpose of the IETF

   The first comment I received when I announced the Mesh 3.0
   documentation set was to ask if anyone else was planning to implement
   the specification as the primary focus of IETF work was to enable
   interoperability between implementations.

   While developing clear specification documents that describe
   compelling designs facilitating widespread interoperability is a
   noble and important goal, it is not one that the IETF is designed to
   serve.  If I wanted to develop elegant and compelling specifications,
   I would hardly want to do so in a hundred-person committee.

   It doesn't take a hundred people to design a specification, but it
   frequently requires that number or even more to represent the




Hallam-Baker            Expires November 4, 2019               [Page 10]

Internet-Draft               PHB Deployment                     May 2019


   interests of all the stakeholders and gatekeepers whose requirements
   must be met if deployment is to be successful.

   The main if not the sole reason I attend standards organization
   meetings is to build the constituency necessary for adoption.  If I
   had already established that deployment constituency, I would have no
   need of coming to the IETF in the first place.  Equally, it would be
   surprising to say the least if anyone else had begun an
   implementation of a set of specifications when I have been
   discouraging anyone from doing that until the work was nearly
   complete.

   If our work has any importance, it is that it improves the Internet.
   It is the consensus outside the IETF in the user community that
   ultimately counts.  Over the years I have seen many attempts to short
   circuit the process and march a specification through at breakneck
   speed.  While this is an effective strategy for impressing managers,
   it is not an effective strategy for building a deployment community.
   It is much easier to form a strong consensus among a dozen people who
   start with strongly aligned views and interests than to form such a
   consensus among a hundred people representing twenty different
   deployment constituencies.  But it is the latter that is necessary if
   we are to achieve deployment.

   Many people try to accelerate IETF process, I have frequently
   preferred a slower pace when I believe it might allow endorsement by
   a key stakeholder or a gatekeeper.

   Recommendation: The IAB should recognize that at least one purpose of
   the IETF is to help technology developers build a deployment
   constituency and that this is properly a result of rather than a
   precondition for considering work.

2.2.  Design for Deployment

   The need to design for deployment is argued in the previous section.
   The question for the IAB is when and how that approach should be
   required.

   Rather than clutter up every RFC with a mandatory 'Deployments
   Consideration' section, the intended outcome is more likely to be
   received if this is an exceptional rather than a routine requirement
   and takes the form of a deliverable required of a working group
   during the chartering process.  As is frequently the case with use
   cases and requirements documents, a document describing deployment
   considerations need not necessarily be published as an RFC but would
   serve to inform and facilitate the design process.




Hallam-Baker            Expires November 4, 2019               [Page 11]

Internet-Draft               PHB Deployment                     May 2019


   Recommendation: The IESG should request presentation of a 'Deployment
   Considerations' section as a deliverable when chartering or re-
   chartering work where success requires widespread adoption.

2.3.  Identify Stakeholders and Gatekeepers

   When deployment of a specification depends on adoption by a
   particular community of stakeholders, the opinions expressed by that
   community must be considered when designing for deployment.  When one
   or more stakeholders have an influence so strong that it amounts to a
   veto power on particular forms of deployment they should be
   recognized as a gatekeeper and the deployment strategy designed
   accordingly.

   It is important to note however that recognizing stakeholders and
   gatekeepers is not the same as affording them veto power.  What is
   important is that their views must be considered by the Working Group
   even if the stakeholders and gatekeepers themselves are not present.
   If a proposal to improve Internet security is critically dependent on
   adoption by Web browser providers, their deployment criteria must be
   determined and respected.  Or if it is impossible to reconcile the
   objectives with those criteria the design must be changed so that it
   does not depend on adoption by the Web browser providers.

   It is of course necessary that the IETF operate under the fiction
   that every participant participates in their personal capacity alone
   and is not speaking for their employer.  And this is certainly true
   to the extent that of the 1,500 attendees at a typical meeting, few
   if any have direct authority to speak on behalf of an organization of
   more than fifty people.  And those that do are less likely to speak
   because of that fact.

   But this polite fiction should not prevent Working Groups from
   soliciting and receiving direct input on the issue of deployment
   criteria from constituencies identified as stakeholders and
   gatekeepers.

   Recommendation: When the IESG requires deployment considerations be
   produced, these should specify the key stakeholders and gatekeepers
   and the positions these parties have expressed.

2.4.  Realistic Schedules

   Some of the standards efforts I have been involved in have succeeded
   and some of those efforts have failed.  While it is never possible to
   know with certainty that an effort will succeed, it is often possible
   to predict with a high degree of certainty that an effort will fail.
   There is no more certain sign that an effort is doomed than when the



Hallam-Baker            Expires November 4, 2019               [Page 12]

Internet-Draft               PHB Deployment                     May 2019


   introductory slides assert that the urgency of the problem is so
   great that a solution much be found and deployed within 12 months.

   There are very few problems that are currently being addressed in
   IETF Working Groups that have not been recognized as issues for at
   least five years.  Most had been understood as issues for a decade or
   more.  The claim that any issue has suddenly become so urgent that
   there is insufficient time to consider it properly should therefore
   bear a heavy burden of proof.

   The fact that a Working Group charter sets an unrealistic schedule is
   not of course any guarantee that it will be met.  And it is usually
   apparent from the start that this was never the intention.  Setting
   an unrealistic schedule allows the scope of work to be controlled to
   exclude unwanted use cases, requirements and constraints and thus
   ensure that the Working Group selects a particular approach that
   allows the party controlling the process to re-use existing code
   rather than write new code.

   Recommendation: The IESG should reject Working group schedules that
   leave insufficient time to discuss the use cases, requirements and
   appropriate technology.

2.5.  Eliminate Deployment Dependencies

   One of the most useful, certainly the most frequent advice offered by
   Jim Schadd when I shared an office with him at W3C was to avoid
   'error 22': do not build research on research.

   It is not uncommon for one Working Group to attempt to force
   deployment of their work by persuading another working group to make
   it an essential requirement.  Rather than encouraging such
   dependencies, they should be vigorously discouraged.

   Another form of deployment dependency is the requirement that a
   standard be designed in a particular way so that a particular
   stakeholder can re-use existing code.  While re-use of existing code
   is an advantage, it is very rarely as decisive an advantage as the
   proposer imagines.  The fact that a designer was able to lash
   together a prototype using an existing 500K line library does not
   necessarily suggest that this will provide a short cut to development
   of a production version of the same system.

   Recommendation: When the IESG requires deployment considerations be
   produced, these should specify all the technologies that the proposal
   is dependent on, the status of each and a justification given for
   reliance on any technology that is not already ubiquitously deployed.




Hallam-Baker            Expires November 4, 2019               [Page 13]

Internet-Draft               PHB Deployment                     May 2019


2.6.  Recognize Failure

   Probably the hardest step for the IETF to take as an institution is
   to recognize when an approach has failed and to stop investing
   resources in that effort.

   One of the most important decisions that the IETF took in the
   deployment of end-to-end secure mail was the recognition that PEM had
   failed to win adoption and clear the field for S/MIME and OpenPGP.

   It is now time for the IETF to have the courage to recognize that
   S/MIME and OpenPGP have failed to thrive.  They have both established
   significant user bases and serve important functions.  But neither
   has made appreciable progress in adoption in the past two decades and
   neither is likely to achieve ubiquity.  Recognizing that these legacy
   protocols have failed to thrive would not render them obsolete but
   would clear the field allowing alternative approaches to be proposed.

   Recommendation: The IAB should be tasked with performing periodic
   reviews of IETF standards and identify those that have 'failed to
   thrive'.

3.  References

3.1.  URIs

   [1] http://mathmesh.com/Documents/draft-hallambaker-iab-
       deployment.html

Author's Address

   Phillip Hallam-Baker

   Email: phill@hallambaker.com

















Hallam-Baker            Expires November 4, 2019               [Page 14]