Internet Engineering Task Force A. Farrel
Internet-Draft Juniper Networks
Intended status: Informational February 21, 2017
Expires: August 25, 2017

A Definition of the Term "Soon" for Use in Discussions with Working Group Chairs and Area Directors


Many discussions with IETF Area Directors and Working Group Chairs utilize the word "soon" to qualify a commitment to action. This document attempts to provide a definition of that term so that common expectations may be realistically set.

Requirements Language

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].

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

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 August 25, 2017.

Copyright Notice

Copyright (c) 2017 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 ( 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. Introduction

In everyday exchanges between IETF participants and those with IETF management roles (for example, Area Directors and Working Group Chairs) commitments are often made to deliver actions.

For example, a Working Group Chair may say "I will issue a working group last call on this document," or an Area Director could say "I will process your publication request and review your document." Alternatively, a document author might say "I will produce a new revision of this document," and a participant sometimes says "I will provide more details / suggested text / a follow-up review."

In all of these interactions it is common for the speaker to offer some expected completion time for the action. Sometimes this is expressed in elapsed time (for example, "I will do this within the next two lunar cycles"), frequently it is stated with reference to an absolute point in time (such as, "I will do this by the third Sunday in Lent"), but usually the qualifier applied is "Soon."

Frustration and disappointment are common currency in the modern world, but there is no need for the IETF to add to this state of affairs. Nor should the IETF be responsible for increasing cynicism and jaundiced pessimism. Therefore, this document attempts to provide a definition of the term "Soon" so that common expectations may be realistically set.

2. We Are All Volunteers

It is a commonly held belief that in the IETF "we are all volunteers." Even those of us who are paid to do our jobs are confident that we are only working out of the goodness of our hearts and that our salaries are poor recompense for our daily travails.

And, of course, it is well known that you cannot induce a volunteer to do anything that might interfere with their otherwise compulsory activities of looking at pictures of cats, creating memes, or pipe-smoking. Therefore, it is highly inappropriate for this document to make any attempt to constrain anyone into giving a meaningful delivery date for any action that they promise. To that end it is expected that this document will be withdrawn and a fulsome apology issued soon.

3. The Kompella Time-Dilation Effect

When serving as co-chair of the CCAMP working Group, Kireeti Kompella was often called to account for not offering a completion date for tasks to which he committed.

After wise consideration of this situation, Kireeti would offer an answer such as "I will do this before the end of June," and everyone would go away content. It was only as July gave way to August that Kireeti would explain that he had failed to indicate to which year he was referring.

In such cases of high residual KTDE, use of the term "Soon" would better set expectations, and Kireeti has given an undertaking to transition to this term by the end of the second quarter.

4. Possible Interpretation of the Term 'Soon'

Many learned articles have been written on possible interpretation of the term "Soon". No doubt the author will add citations and references one day soon.

Readers should note that "SOON" is also an FLA [RFC5513] although has not yet been registered as such by IANA. This document has not (noticeably) been endorsed by the Standards Organisation of Nigeria.

5. Optimism Is the Curse of the Drinking Man

The software industry is infamous for its inability to provide reliable estimates for development projects. No-one is quite sure why this should be. Is it because troops of evil mice come into the workshop late at night while the cobbler is asleep in his bed alongside his long-suffering wife and unpick the seams of carefully constructed function calls? Is it because coders make it all up as they go along and have no idea what they are doing? And is it a coincidence that sotware is so appropriately spelled?

IETF working group milestones (or "millstones" as they are more correctly termed) are commonly held in disrepute. They are certainly not dates that anyone had ever been held to, and inspection of most working group charters will show that either the chairs intend employing time travel or that no one pays any attention to the milestones. It may be because Area Directors often say to working group chairs that "milestones are just a tool for you to manage the working group", or it may be because no one likes a bully.

These two factors obviously contribute to an environment in which the term "soon" has little or no currency except as padding to fill an awkward gap between a promise and the full stop at the end of the sentence.

None of which is intended to imply that:

6. Towards A Definitive Meaning

The purpose of this document is to provide a working definition of the term "soon" so that parsers of IETF communications may reasonably understand the meaning, and so that a degree of linguistic interoperability between speakers may be achieved. The following definition applies:

7. Guidance in the Use of This Term

Terms of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for explanation of when a deliverable will arrive or to limit behavior which has potential for causing harm (e.g., limiting retransmissions of requests for action). For example, they MUST NOT be used to try to impose a particular schedule on participants where the schedule is not required for anything other than vanity.

8. Boilerplate for Inclusion in All Communications

In many IETF communications a word is often used to signify the proximity of an event described in the communication. This word is often capitalized. This document defines this word as it should be interpreted in IETF communications. Authors who follow these guidelines should incorporate this phrase near the beginning of their communication:

Contrary to the overweening pedantry of [I-D.leiba-rfc2119-update], words used in this document mean what they say regardless of what font they are in and notwithstanding the color in which thy are rendered.

To quote from Through the Looking Class by Charles Dodgson:

Thus, the term "soon" is as meaningful when it is presented in "uppercase" as it is when found in "LOWERCASE".

9. IANA Considerations

This document makes no request for any IANA actions.

10. Security Considerations

Just say no!

Further security consideration will be added to this document SOON.

10.1. Privacy Considerations

See "Author's Address" Section.

11. Acknowledgements

Kireeti Kompella reminded me of millstones and corrected my grammar.

Thanks to John Scudder for his own overweening pedantry.

Benoit Claise supplied comments NOT BEFORE TIME.

12. References

12.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.

12.2. Informative References

[I-D.leiba-rfc2119-update] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", Internet-Draft draft-leiba-rfc2119-update-01, February 2017.
[RFC4041] Farrel, A., "Requirements for Morality Sections in Routing Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 2009.

Author's Address

Adrian Farrel Juniper Networks EMail: