One document matched: draft-tschofenig-rai-reducing-delays-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC5031 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml'>
<!ENTITY RFC3967 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3967.xml'>
<!ENTITY RFC2026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
<!ENTITY RFC2865 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY RFC3427 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3427.xml'>
<!ENTITY I-D.ietf-ecrit-local-emergency-rph-namespace PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-local-emergency-rph-namespace.xml'>
<!ENTITY I-D.peterson-rai-rfc3427bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.peterson-rai-rfc3427bis.xml'>
<!ENTITY I-D.ietf-behave-turn PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-turn.xml'>
<!ENTITY I-D.ietf-radext-design PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-radext-design.xml'>
<!ENTITY I-D.ietf-geopriv-radius-lo PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-radius-lo.xml'>
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml'>
<!ENTITY I-D.ietf-sip-location-conveyance PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-location-conveyance.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-tschofenig-rai-reducing-delays-00.txt">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Reducing Delays">A Pragmatic Approach for Reducing Delays in Publishing
Documents within the Real-time Applications and Infrastructure (RAI) Area</title>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author initials="M." surname="Isomaki" fullname="Markus Isomaki">
<organization>Nokia</organization>
<address>
<postal>
<street>P.O.BOX 100</street>
<street>00045 NOKIA GROUP</street>
<city>Helsinki</city>
<country>Finland</country>
</postal>
<phone/>
<email>markus.isomaki@nokia.com</email>
</address>
</author>
<date year="2009"/>
<workgroup>rai</workgroup>
<abstract>
<t>During the last year, participants in the Real-time Applications and Infrastructure
(RAI) area have been quite active in discussing proposals that could improve their
way of working. This document is a contribution to that discussion and focuses on
the reduction of delays experienced in producing specifications. We believe that
this is one of the main problems in the RAI area (and quite likely in other areas of
the IETF as well) and it requires attention. A number of side effects, caused by the
long specification work, are illustrated in this document. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> Many participants in the Real-time Applications and Infrastructure (RAI) area have
noticed that it takes several years for a specification from the initial working
group item to the published RFC. A brief look at
http://www.arkko.com/tools/lifecycle/ (for documents like ICE, SIP Location
Conveyance, SIP configuration framework) very quickly confirms this observation.
Several years are quickly spent. In various cases these delays have had negative
effects on the deployment situation and on interoperability. In some other cases the
relationship between a long delay and lack of deployment cannot be directly observed
and there are more complex reasons that can only be analysed on a per-specification
basis. For example, some of the interoperability problems that got discussed during
the SIP Interoperability Workshop at IETF#70 (see
http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,42/Itemid,75)
may have been caused by specifications with too many options.</t>
<t>The authors are not aware of a detailed and structured analysis of the documents
within the RAI area with respect to their delays. With some documents there is the
question whether additional delay is actually problematic, particularly when they
have a research character. One could argue that optimizations to the process should
not be started without a detailed analysis of the main causes for these delays.
Unfortunately, the delays are the effects of actions taken by individuals and
blaming them for the problems is not helpful, particularly since the accused persons
are very likely to disagree.</t>
<t>Protocol specifications that are not deployed are useless regardless how fast they
found their way through the IETF. This document, however, does not attempt to
discuss problems of publishing specifications that do not meet market demands
(especially since different IETF participants target different market segments, some
of which might not even closely reflect the properties of the Internet). </t>
<t>Instead, this document only focuss on delays assuming that the only problem to be
solved is that specifications are not published in a timely fashion.</t>
</section>
<!-- ****************************************************************************************** -->
<section title="Reasons for Delays">
<t>The authors believe that the following list provides a fairly complete list of
reasons for delays in the process of publishing a specification: <list
style="hanging">
<t hangText="Interworking between different working groups:"><vspace
blankLines="1"/>While it may sound fairly unproblematic to work on a
single specification in different working groups experience has shown the
opposite. Typically, the problems are related to the lack of understanding
of the usage scenarios, different schedules and priorities, unclear
responsibilities, different workstyles in different groups, etc. A similar
problem can also be observed when special expert groups need to get
involved, e.g., in the form of XML directorates, reviews of URI schemes,
application layer design aspects. <vspace blankLines="1"/> Examples that
support the above statement can be found with RADIUS GEOPRIV <xref
target="I-D.ietf-geopriv-radius-lo"/> (interaction between GEOPRIV and
RADEXT), HELD <xref target="I-D.ietf-geopriv-http-location-delivery"/>
(interaction between GEOPRIV and the APPS area), and SIP Location Conveyance
<xref target="I-D.ietf-sip-location-conveyance"/> (interaction between
GEOPRIV and SIP). </t>
<t hangText="Interworking with other SDOs:"><vspace blankLines="1"/>Similarly to
the interworking between different IETF working groups one might already
expect problems in the interworking with other SDOs as the differences might
quickly increase due to the different set of participants, fairly different
standardization procedures and deadlines ('yes, in some SDOs deadlines are
taken serious even though they are completely artificial'), different
architectural approaches, different business models, different target
markets (e.g., enterprise networks, cellular networks, military networks)
different security assumptions. <vspace blankLines="1"/> Examples can be
found throughout the IETF. In the RAI area the SIP change process (see <xref
target="RFC3427"/> and the currently discussed revision of it <xref
target="I-D.peterson-rai-rfc3427bis"/>) build the basis of the
interworking. Unfortunately, it turned out that in practice problems show up
with the lack of participation of persons in both organizations. A high
priority item from, for example, the TISPAN leads to a lot of confusion and
lack of interest in the IETF RAI area due to the lack of context. There are,
however, different models in the IETF as well where a lot of the actual
protocol work is outsourced to the respective organization. An example would
be the RADEXT working group with their work on RADIUS <xref target="RFC2865"
/>; a protocol that is being used by a number of SDOs. Although the
specifications that are sometimes produced outside the IETF do not meet the
quality expectations in the IETF they do at least not cause resources from
IETF participants to be wasted when there is little to no interest in that
specific work. To provide a minimum degree of guidance rules have been
outlined that should be followed when defining new extensions for RADIUS,
see <xref target="I-D.ietf-radext-design"/>. </t>
<t hangText="Disagreement about architectural approaches:"><vspace
blankLines="1"/> Sometimes document authors have a different
architectural approach in mind that is incompatible with a large part of the
working group members. Often, these aspects are discovered fairly late in
the process particularly when the document lacks a description of the
assumptions and the security architecture. Often, the problems are related
to the interworking with other SDOs as the solution approach developed with
the IETF specification as seen by the authors as a building block that has
then to be fit into an architecture developed elsewhere (often without
explicitly stating who else would be doing that work). <vspace
blankLines="1"/> Examples include the stream of work regarding GETS/MLPP
(partially done in the IEPREP working group). </t>
<t hangText="Review marathon:"><vspace blankLines="1"/> Getting a document
through the IETF process does not happen without reviews. There are reviews
before the document becomes a WG item, reviews while the document is within
the group, some chairs demand reviews before they issue a WGLC to probe
'readiness', someone in between reviews by special expert groups are done
(also by other SDOs and external groups, if necessary), then comes the WGLC,
review by the responsible AD, review by the IESG, review by directorates
(and there are many of those) and (depending on the type of document and
history) an IETF Last Call. Everybody has an opinion, often not necessarily
a technical opinion, on how documents should be written and why other
solution approaches have not been explored. Reviewers need time and then the
review comments often cannot be ignored but need to be discussed and
resolved. When reviews happen later in the process then text changes are
often expected to keep the reviewer happy. IESG members frequently put
DISCUSSes on reviews and this increases their priority allowing a single
person to, for example, delay the publication of a document for an extended
period of time. From a psychological point of view reviewers are in the
unfortunate position that they have the feeling that something must be
improved as an outcome of the review activity. As soon as documents leave
the working group the transparency is largely lost, despite IESG comments
being sent to the authors, WG chairs and responsible ADs and despite
information being available in the I-D tracker. Mentally, many working group
members consider documents to be 'done' when they leave the working group.
<vspace blankLines="1"/> The authors are not arguing that reviews are
unnecessary but there has to be balance with respect to the goal that is
about to be accomplished. </t>
<t hangText="Degeneration of the 3-level Standards Track process:"><vspace
blankLines="1"/>RFC 2026 <xref target="RFC2026"/> describes the
'Internet Standards Process' and describes the level of Standards Track
documents, namely 'Proposed Standard' to 'Draft Standard' to 'Internet
Standard'. It appears that IETF participants are less likely to spend their
time on advancing documents from 'Proposed Standard' to 'Draft Standard',
particularly since the industry to a large extent does not understand the
standards process anyway. More and more it can be observed how a fairly
small group of people get together and produce de-facto standards by
finishing specifications in an astonishing time frame together with a large
number of implementations that the Internet community is willing to deploy.
The standards process utilized in the IETF is, unfortunately, not tailored
to these type of developments. Experimental documents on the other hand,
although easier to publish through the IETF, have the stigma of being very
unbaked. In certain environments the label of 'experimental' is considered
as a problem. Putting normative references to informational or experimental
RFCs in Standards Track documents later makes the publication process more
complex due to the need for Down-Refs <xref target="RFC3967"/>. </t>
<t hangText="Feature creep and overall complexity:">
<vspace blankLines="1"/>Setting up a working group takes some time, getting
working group members to agree that a certain document has to become WG item
also takes a lot of time, the time it takes to publish it as an RFC takes
even longer and producing more extensions involves also a certain overhead
(e.g., re-chartering, new working group/BOF, new milestones, support from
the working group). It is therefore not surprising that document
authors/edtiors or the working group are sometimes tempted to add a tiny
feature here and another small feature there. <vspace blankLines="1"/> A
further favorite 'hobby' is to generalize the solution. In theory this is a
good idea as the same protocol can be then used in a variety of different
usage scenarios. In most case, this has lead to more complexity, much longer
time to finish the specification and sometimes none of the use cases are
consequently covered appropriately. For some, the SIP configuration
framework might be an example. </t>
<t hangText="Lack of time:"><vspace blankLines="1"/> The IETF to a large extend
consists of volunteers (rather than standardization specialists and
consultants), who have a fairly limited time budget. Those who are involved
in the development of standards tend to have time constraints (e.g.,
authors, WG participants, WG chairs, ADs, Expert Reviewers, etc.). This is
quite normal. <vspace blankLines="1"/> Problems arise when the lack of time
causes considerable delays in completing work other people rely on. Consider
the following hypothetical case. Bob is an expert in writing specifications
and he has a lot of energy and enthusiasm. He is assigned as the main editor
of a specification. The work on the specification takes some time (typically
years) but Bob does his job well and the community respects him. Over time
Bob develops new interests, might even change his job and does not show the
same availability anymore. Still, Bob remains in charge of the document and
Bob does not recognize that he is unable to commit the necessary time to get
the job done. A similar situation can happen in any other role previously
mentioned. </t>
<t hangText="Missing running code:"><vspace blankLines="1"/> Although most
people would agree that running code is very useful many specifications are
not backed up with it. Since specifications change a lot over the lifetime
before being published as an RFC (even at a very late stage) it can be
pretty frustrating to have running code in an early stage. The standards
process considers interoperable code but due to the long time it takes to
publish specifications it is rarely utilized. <vspace blankLines="1"/> As an
example, the TURN specification <xref target="I-D.ietf-behave-turn"/> has
changed quite considerably over time. Those who implemented earlier versions
essentially had to re-write their code.</t>
<t hangText="Onerous extensibility rules:"><vspace blankLines="1"/> Many
document authors feel insecure when writing IANA consideration sections and
for some reasons these consideration sections often demand Standards Track
documents to introduce new extensions. <vspace blankLines="1"/> A recent
example can be found with the Service URN document <xref target="RFC5031"/>,
which requires a Standards Track document for allocating a new top-level
top-level service labels. With the new extensions that the working group had
seen it became cumbersome to progress these documents in a timely fashion
through the working group. </t>
<t hangText="AD and IESG overload:"><vspace blankLines="1"/> Some documents need
significant time after leaving the working group until they are published.
It is unclear that these delays yield significantly better documents in the
end. Part of the problem is that the current IETF area director model seems
to assume that ADs spend the equivalent of a full-time job on their
"volunteer" job, which appears to be unrealistic, particularly when ADs have
been in office for several years. Compared to other organizations, the AD
"span of control" is very large, supervising twenty or more working group
chairs.</t>
<t hangText="Exhaustion:"><vspace blankLines="1"/>As the publication process
wears on, the amount of change per time unit continuously decreases. Because
of the long delays, authors are often working on many documents in parallel,
making it difficult for them to switch context and remember all the issues
when they update documents. As the initial excitement about a problem fades
after a few years, editing such documents becomes a chore, further delaying
the publication. This leads to author exhaustion. <vspace blankLines="1"
/>Thus, to the extent possible, most documents should be finished in no more
than three IETF meetings: gauge interest and agreement on basic approach
during the first IETF meeting and assign reviewers, reach consensus on the
technical issues during the second IETF meeting and get a final WG approval
during the third one, if needed. </t>
</list>
</t>
</section>
<section title="Suggestions">
<t> Below, we present a set of suggestions to reduce publication delays. We believe that
many of the suggestions can be used together, and some can be used experimentally to
see if they produce significant improvements. <list style="hanging">
<t hangText="Improving the chartering process:"><vspace blankLines="1"/> It
takes far too long to add an item to a charter. If there's interest in the
working group and the document is below a certain size and complexity (based
on the judgement by the WG chair) and three reviewer volunteers, the
document should just get into the next cycle. </t>
<t hangText="State assumptions clearly:"><vspace blankLines="1"/> Sometimes a
specific protocol specification is target for usage in a certain environment
(or envisioned context). The working group may be fine with such an approach
but often the document does not state the usage environment. This often
leads to confusion in the review process. For example, some documents are
being progressed through the IETF where the main use case can be found in
the 3GPP IMS architecture. Maybe the document assumes that other
organizations utilize the specification in a specific context. There are
often additional operational aspects that need to be considered in order to
come to a complete solution. <vspace blankLines="1"/> A recent example can
be found in the work on <xref
target="I-D.ietf-ecrit-local-emergency-rph-namespace"/> where the
document essentially only specifies the syntax but the semantic is supposed
to be provided by organizations outside the IETF. </t>
<t hangText="Delegate down:"><vspace blankLines="1"/> In most organizations,
middle management is given significant decision authority, usually described
by the financial impact of a decision. A CEO of company does not approve
every contract, user manual or feature list. The current IETF review model
is predicated on the notion that the IESG reviews protocols to ensure that
they do not damage the Internet. However, most of the current RAI documents
are extensions and bug fixes that are likely to have only local effects.
<vspace blankLines="1"/> To reduce AD and IESG load, working group
chairs should be able to handle most documents until they reach the RFC
editor, unless there is an objection during IETF last call. IESG members are
expected to voice their objection during that last call period, triggering
formal IESG review. Only efforts that introduce new protocols or are likely
to have significant Internet-wide impact require more extensive review.
<vspace blankLines="1"/> When a document is added to the WG work list,
it should be flagged to indicate that it will require a full review. All
other documents receive a lighter late-stage review. </t>
<t hangText="Clearly label IETF discussion slots:"><vspace blankLines="1"/>Given
the three-meeting model mentioned earlier, the IETF meeting presentations
should be structured accordingly, with a clear set of questions to be
answered. For example, the first presentation needs to answer questions
about architectural assumptions, relation to other work, dependencies,
importance of the problem and alternative approaches. Working group chairs
should work with document authors to structure presentations, possibly
providing templates. In this model, the second discussion is crucial and
should be given ample time, if necessary enhancing the plenary working group
meeting with break-out meetings before and after the WG meeting slot. (It is
a waste of time to have 200 people listen to a discussion where only a
handful can really make significant contributions.) </t>
<t hangText="Journal-like review model:">
<vspace blankLines="1"/> When a new document is submitted to the working
group, the working group chair determines at latest at the next IETF meeting
whether there is sufficient interest to pursue this work. If so, he or she
seeks at least three reviewers from the working group. If such reviewers
cannot be found, the document lacks sufficient interest. Authors may suggest
qualified reviewers. Reviewers are given a two-month review deadline, so
that reviews would typically arrive mid-cycle between IETF meetings. The
basic process could follow the GenArt review model, which could proceed in
parallel. As needed, a specialized reviewer might be assigned to only look
at specific issues, such as XML usage, security aspects or congestion
control. <vspace blankLines="1"/> The reviews should be tracked in an issue
tracker, in addition to being disseminated via the working group mailing
list. As a short-term measure until the IETF tools are enhanced, existing
conference review tools might be used, as they offer definable review forms
(e.g., to separate editorial and technical issues) and automated review
reminder mechanisms. <vspace blankLines="1"/> This approach closely models
the review process used by scientific journals and technical conferences. </t>
<t hangText="Increasing implementation feedback:"><vspace blankLines="1"/> When
documents are able to progress faster through the IETF participants should
feel encouraged to provide an update that includes bug fixes and other
corrections based on implementation efforts. A possible approach to
accomplish this today is to publish documents as informational and
experimental RFCs (faster) and to advance them to Standars Track once
implementation (or even deployment) experience is available. </t>
<t hangText="Delegate work to other SDOs:">
<vspace blankLines="1"/>We believe that the updated version of the SIP
Change Process <xref target="I-D.peterson-rai-rfc3427bis"/> goes into the
right direction already. </t>
<t hangText="Additional WG chair training:"><vspace blankLines="1"/> We suggest
to use some of the WG chair training lunches to offer room for discussions
on how to avoid delays in progressing documents and to collect the best
current practises. </t>
<t hangText="Virtual interim meetings:"><vspace blankLines="1"/>Many document
authors do their IETF work in the two-week period around the submission
deadlines before an IETF meeting. This leads to fairly low document update
cycles. A tool to increase the time that is spent on documents per IETF
cycle working style is to hold virtual interim meetings (i.e., phone
conferences). This is common practice also in other organizations and helps
to stay focused on open issues. Sometimes chairs regularly contact the main
document authors to discuss the editing progress and the status of open
issues. It is useful to allow working group members to participate and
distribute notes about this informal communication. </t>
<t hangText="Publish WG status updates:"><vspace blankLines="1"/> Sometimes no
progress is made because there is uncertainty about who is responsible for
taking the next step. Periodic reminders (even with tool support) would help
to make the workflow more visible. Examples of these periodic status updates
can be found here
http://www.ietf.org/mail-archive/web/ecrit/current/msg05785.html,
http://www.ietf.org/mail-archive/web/ops-area/current/msg00467.html and
http://www.ietf.org/mail-archive/web/saag/current/msg02242.html.</t>
<t hangText="Assign new editors:"><vspace blankLines="1"/> If the original
author clearly cannot complete the work in a timely fashion, the working
group chair should routinely assign an editor to the document, after, say, a
one-year delay since the -00 draft. If no other person is capable to take
that role, this indicates that the document is either too long, too
complicated or of insufficient interest to merit further consideration as-is
and needs to be split up, simplified or abandoned.</t>
<t hangText="Enhance I-D tracker:"><vspace blankLines="1"/> The I-D tracker
should indicate who is supposed to be reviewing the document and by what
deadline. It should also clearly indicate who has the "token" on the
document, i.e, whether the next action is expected to come from the working
group chair, a reviewer or set of reviewers, a directorate, or the authors.
</t>
</list>
</t>
</section>
<section title="Security Considerations">
<t>This document discusses process related aspects that are not directly related to
security. However, the outcome of an improved process might have a positive impact
on security provided by the deployed specifications.</t>
</section>
<section title="Acknowledgements">
<t>We would like to thank all of those you care about the process related aspects in the
IETF as they contribute to the impact of the work produced by the IETF in the
future. We would also like to thank everyone participating on the RAI area mailing
list for their input during the RAI reorganization discussions.</t>
</section>
<!-- ****************************************************************************************** -->
</middle>
<back>
<!-- <references title="Normative References"> </references> -->
<references title="Informative References">
&I-D.ietf-ecrit-local-emergency-rph-namespace; &I-D.peterson-rai-rfc3427bis;
&RFC5031; &I-D.ietf-behave-turn; &RFC3967; &RFC2026; &RFC2865;
&I-D.ietf-radext-design; &I-D.ietf-geopriv-radius-lo;
&I-D.ietf-geopriv-http-location-delivery; &I-D.ietf-sip-location-conveyance;
&RFC3427; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 18:00:32 |