Skip to main content

Network Transport Circuit Breakers
RFC 8084

Revision differences

Document history

Date Rev. By Action
2017-03-07
15 (System)
Received changes through RFC Editor sync (created alias RFC 8084, changed abstract to 'This document explains what is meant by the term "network transport …
Received changes through RFC Editor sync (created alias RFC 8084, changed abstract to 'This document explains what is meant by the term "network transport Circuit Breaker".  It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed.  It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.', changed pages to 24, changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2017-03-07, changed IESG state to RFC Published, created alias BCP 208)
2017-03-07
15 (System) RFC published
2017-02-01
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-01-18
15 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-01-09
15 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-11-13
15 (System) RFC Editor state changed to EDIT from MISSREF
2016-05-18
15 (System) IANA Action state changed to No IC from In Progress
2016-05-18
15 (System) RFC Editor state changed to MISSREF
2016-05-18
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-05-18
15 (System) Announcement was received by RFC Editor
2016-05-18
15 (System) IANA Action state changed to In Progress
2016-05-17
15 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2016-05-17
15 Amy Vezza IESG has approved the document
2016-05-17
15 Amy Vezza Closed "Approve" ballot
2016-05-17
15 Amy Vezza Ballot approval text was generated
2016-05-17
15 Amy Vezza Ballot writeup was changed
2016-04-07
15 Roni Even Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even.
2016-04-04
15 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-15.txt
2016-03-23
14 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2016-03-23
14 Gunter Van de Velde Request for Telechat review by OPSDIR Completed. Reviewer: Linda Dunbar.
2016-03-21
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-03-21
14 Gorry Fairhurst IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-03-21
14 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-14.txt
2016-03-17
13 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2016-03-17
13 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-03-16
13 Ben Campbell
[Ballot comment]
= Substantive: =

- General:

-- [I moved the following here from my original DISCUSS position. I've cleared the DISCUSS, since "discussion" has …
[Ballot comment]
= Substantive: =

- General:

-- [I moved the following here from my original DISCUSS position. I've cleared the DISCUSS, since "discussion" has started and looks promising.]  The rule 18 "out of band" section says loss of control messages SHOULD NOT trigger the CB.  But rule 1 said "The CB MUST trigger if there is a failure of the
        communication path used for the control messages." These seem to be contradictory normative requirements.

-- I'm surprised not to see much, if any, commentary about how endpoints are expected to learn of and react to triggered CBs. Flows that just stop working for no apparent reason will violate the principle of least surprise for users. Users are likely to do exactly the wrong things (e.g. restart flows), unless they are informed of why.

- 1, last paragraph:

-4, req 10:

What is meant be default here? Does this suggest that an implementation must disable all traffic unless a user explicitly configures it to behave differently?

- req 12: "... MUST be much more severe"
How do you measure that sort of requirement? Isn’t this already covered by 10 and 11 and 13?

- 5.1, last paragraph, last sentence:

Does this imply that circuit breakers can/will be stacked? If so, an explicit mention of that fact early in the document would be helpful.

- 5.1.1:
Why not reference draft-ietf-avtcore-rtp-circuit-breakers ? (Informational should be fine.)

= Editorial: =

-1, third paragraph: "Avoiding persistent excessive prevention ..."

Should that be "Avoiding persistent excessive _congestion_ ..."?

-- 5th paragraph, first sentence:

Is there a such thing as “normal excessive congestion?”

-- 8th paragraph: "This is to
  ensure that a Circuit Breaker does not accidentally trigger following
  a single (or even successive) congestion events (congestion events
  trigger transport congestion control, and are to be regarded as
  normal on a network link operating near capacity). "

I’m confused by this sentence. What is the subject of “are to be regarded as normal”?

-- 10th paragraph, first sentence: Is this the same as saying that circuit breakers should not trigger under normal conditions?

- 2nd to last paragraph, 2nd sentence:
In contrast to what? Not knowing the cause of congestion? (Are contestion-controlled protocols expected to know the cause?)

-4, req 3: It would have been helpful to mention ECN (or forward reference it) prior to the first mention of "lost/marked packets".

-- req 9: Isn’t this the point behind the last 3 (or more) requirements? That is, it seems like this is the real requirement and those were more implementation details.

- 5.1, first paragraph, 2nd sentence:
The sentence structure makes it look like you are using (TCP, SCTP, DCCP) as examples of "applications that do not use a full-fledged transport", which is  obviously not the intent.
2016-03-16
13 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2016-03-16
13 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-03-16
13 Stephen Farrell
[Ballot comment]

- I agree with Ben's discuss.

- Do the MPLS folks and similar agree with 6.1? If so, great.
(And how did you …
[Ballot comment]

- I agree with Ben's discuss.

- Do the MPLS folks and similar agree with 6.1? If so, great.
(And how did you figure that out?) If not, doesn't that make a
big part of this BCP mythical?  (Which would seem
undesirable.)

- 6.2, 2nd para: what question?

- Section 7 (and earlier): You RECOMMEND a crypto mechanism to
mitigate possible DoS. In both cases however, the statement is
ambiguous. Are you RECOMMENDing a mechanism be defined or that
one be used? (And of course if you asked me, I'd say that it'd
be better to a crypto mechanism MUST be used, even when
off-path attacks seem unlikely to work.)
2016-03-16
13 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2016-03-16
13 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2016-03-16
13 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2016-03-16
13 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2016-03-16
13 Deborah Brungard
[Ballot comment]
Agree with Ben's Discuss point. Also Requirement 18 says for in-band "SHOULD" and "ought to" vs. Requirement 1's "MUST". Would prefer Requirement 1 …
[Ballot comment]
Agree with Ben's Discuss point. Also Requirement 18 says for in-band "SHOULD" and "ought to" vs. Requirement 1's "MUST". Would prefer Requirement 1 be clarified by combining with Requirement 18. Prefer 18's requirement that an out-of-band control channel failure does not trigger the CB and disrupting traffic. May want to consider adding the ability to configure if a loss of the control channel should trigger the CB. Other technologies consider the loss of control protocol as a freeze on the bridge selector state. Also may want to consider adding the ability to configure a freeze of the CB for maintenance/operations.
2016-03-16
13 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-03-16
13 Barry Leiba [Ballot comment]
I agree with Ben's DISCUSS point.
2016-03-16
13 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2016-03-15
13 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-03-15
13 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Linda Dunbar
2016-03-15
13 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Linda Dunbar
2016-03-15
13 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-03-15
13 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2016-03-14
13 Ben Campbell
[Ballot discuss]
I expect to ballot "yes" for this, but I have one item that I think needs discussion first (as well as some non-blocking …
[Ballot discuss]
I expect to ballot "yes" for this, but I have one item that I think needs discussion first (as well as some non-blocking comments in the comment section.):

The rule 18 "out of band" section says loss of control messages SHOULD NOT trigger the CB.  But rule 1 said "The CB MUST trigger if there is a failure of the
        communication path used for the control messages." These seem to be contradictory normative requirements.
2016-03-14
13 Ben Campbell
[Ballot comment]
= Substantive: =

- General:

I'm surprised not to see much, if any, commentary about how endpoints are expected to learn of and …
[Ballot comment]
= Substantive: =

- General:

I'm surprised not to see much, if any, commentary about how endpoints are expected to learn of and react to triggered CBs. Flows that just stop working for no apparent reason will violate the principle of least surprise for users. Users are likely to do exactly the wrong things (e.g. restart flows), unless they are informed of why.

- 1, last paragraph:

-4, req 10:

What is meant be default here? Does this suggest that an implementation must disable all traffic unless a user explicitly configures it to behave differently?

- req 12: "... MUST be much more severe"
How do you measure that sort of requirement? Isn’t this already covered by 10 and 11 and 13?

- 5.1, last paragraph, last sentence:

Does this imply that circuit breakers can/will be stacked? If so, an explicit mention of that fact early in the document would be helpful.

- 5.1.1:
Why not reference draft-ietf-avtcore-rtp-circuit-breakers ? (Informational should be fine.)

= Editorial: =

-1, third paragraph: "Avoiding persistent excessive prevention ..."

Should that be "Avoiding persistent excessive _congestion_ ..."?

-- 5th paragraph, first sentence:

Is there a such thing as “normal excessive congestion?”

-- 8th paragraph: "This is to
  ensure that a Circuit Breaker does not accidentally trigger following
  a single (or even successive) congestion events (congestion events
  trigger transport congestion control, and are to be regarded as
  normal on a network link operating near capacity). "

I’m confused by this sentence. What is the subject of “are to be regarded as normal”?

-- 10th paragraph, first sentence: Is this the same as saying that circuit breakers should not trigger under normal conditions?

- 2nd to last paragraph, 2nd sentence:
In contrast to what? Not knowing the cause of congestion? (Are contestion-controlled protocols expected to know the cause?)

-4, req 3: It would have been helpful to mention ECN (or forward reference it) prior to the first mention of "lost/marked packets".

-- req 9: Isn’t this the point behind the last 3 (or more) requirements? That is, it seems like this is the real requirement and those were more implementation details.

- 5.1, first paragraph, 2nd sentence:
The sentence structure makes it look like you are using (TCP, SCTP, DCCP) as examples of "applications that do not use a full-fledged transport", which is  obviously not the intent.
2016-03-14
13 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2016-03-14
13 Brian Haberman
[Ballot discuss]
This is a "let's talk about it" DISCUSS (i.e., may not require any document changes) to make sure I understand what is being …
[Ballot discuss]
This is a "let's talk about it" DISCUSS (i.e., may not require any document changes) to make sure I understand what is being recommended...

1. Rules 12 and 13 in section 4 seem more pertinent to sender-based flows than to tunnels. Is it best current practice to terminate all tunnel traffic in the face of long-term congestion rather than attempt to terminate/regulate the worst offenders within the tunnel? If the circuit breaker capability is implemented within the tunnel ingress point (as is recommended), it would seem straightforward to penalize the flow(s) causing the congestion rather than all the flows. Or am I misinterpreting the rules 12 and 13?

2. Does the need for these types of circuit breakers imply that raw UDP (and UDP-Lite) is no longer sufficiently functional and that DCCP (or an equivalent) needs to be used?

3. If this BCP is expecting to influence the implementation of traffic sources and sinks, should there be some guidance on what should be used (e.g., ECN) prior to invoking circuit breaker logic? The text says numerous times that CBs are a last resort, but I don't see much in the way of what should be used prior to this last resort.
2016-03-14
13 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2016-03-13
13 Joel Jaeggli
[Ballot comment]
linda.dunbar@huawei.com

performed the opsdir review

  Simple protection can be provided by using a randomized source port,
  or equivalent field in the …
[Ballot comment]
linda.dunbar@huawei.com

performed the opsdir review

  Simple protection can be provided by using a randomized source port,
  or equivalent field in the packet header (such as the RTP SSRC value
  and the RTP sequence number) expected not to be known to an off-path
  attacker.  Stronger protection can be achieved using a secure
  authentication protocol.  This attack is relatively easy for an on-
  path attacker when the messages are neither encrypted nor
  authenticated.  When there is a risk of on-path attack, a
  cryptographic authentication mechanism for all control/measurement
  messages is RECOMMENDED to mitigate this concern.

By on-path attacker we mean service provider.

As with for example HLS (which is congestion controlled), and which ISPs particularly wireless carriers then deliberately degrade; Providing a protocol with a well understood mechanism for shutting it down can be used to do so maliciously without imposing a strict firewall policy. that's convenient for plausible deniability.  I wonder if the technical response from implementors isn't to wrap the flow in something harder to inspect.

The discussion of a multicast circuit breaker seems largely anchored in SSM with respect to there being one (reliable) sender. In the ASM case it seems trivial for a malicious sender to cause all the other parties to leave the group by misreporting it's own sending properties (and do so with very few packets).
2016-03-13
13 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-03-10
13 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2016-03-10
13 Jean Mahoney Request for Telechat review by GENART is assigned to Roni Even
2016-03-03
13 Tero Kivinen Request for Telechat review by SECDIR is assigned to Benjamin Kaduk
2016-03-03
13 Tero Kivinen Request for Telechat review by SECDIR is assigned to Benjamin Kaduk
2016-03-02
13 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2016-02-29
13 Spencer Dawkins Placed on agenda for telechat - 2016-03-17
2016-02-29
13 Spencer Dawkins IESG state changed to IESG Evaluation from Waiting for Writeup
2016-02-29
13 Spencer Dawkins Ballot has been issued
2016-02-29
13 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2016-02-29
13 Spencer Dawkins Created "Approve" ballot
2016-02-29
13 Spencer Dawkins Ballot writeup was changed
2016-02-29
13 Spencer Dawkins Changed consensus to Yes from Unknown
2016-02-24
13 Ben Campbell Ballot approval text was generated
2016-02-17
13 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Benjamin Kaduk.
2016-02-17
13 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-13.txt
2016-02-13
12 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Serious Issues. Reviewer: Linda Dunbar.
2016-02-12
12 Gorry Fairhurst IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-02-12
12 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-12.txt
2016-02-09
11 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-02-08
11 Jonathan Hardwick Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Andrew Malis.
2016-02-04
11 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2016-02-04
11 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-circuit-breaker-11.txt, which is currently in Last Call, and has the following comments:

We understand that this …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-circuit-breaker-11.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank  you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-02-03
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2016-02-03
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2016-02-01
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Andrew Malis
2016-02-01
11 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Andrew Malis
2016-01-28
11 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2016-01-28
11 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2016-01-28
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Kaduk
2016-01-28
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Kaduk
2016-01-26
11 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-01-26
11 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: david.black@emc.com, tsvwg@ietf.org, spencerdawkins.ietf@gmail.com, draft-ietf-tsvwg-circuit-breaker@ietf.org, tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: david.black@emc.com, tsvwg@ietf.org, spencerdawkins.ietf@gmail.com, draft-ietf-tsvwg-circuit-breaker@ietf.org, tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Network Transport Circuit Breakers) to Best Current Practice


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'Network Transport Circuit Breakers'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-02-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document explains what is meant by the term "network transport
  Circuit Breaker" (CB).  It describes the need for circuit breakers
  for network tunnels and applications when using non-congestion-
  controlled traffic, and explains where circuit breakers are, and are
  not, needed.  It also defines requirements for building a circuit
  breaker and the expected outcomes of using a circuit breaker within
  the Internet.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ballot/


No IPR declarations have been submitted directly on this I-D.


2016-01-26
11 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-01-26
11 Spencer Dawkins Last call was requested
2016-01-26
11 Spencer Dawkins Last call announcement was generated
2016-01-26
11 Spencer Dawkins Ballot approval text was generated
2016-01-26
11 Spencer Dawkins Ballot writeup was generated
2016-01-26
11 Spencer Dawkins IESG state changed to Last Call Requested from AD Evaluation::External Party
2015-12-22
11 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-11.txt
2015-11-26
10 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-10.txt
2015-11-18
09 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-09.txt
2015-11-01
08 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-08.txt
2015-10-19
07 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-07.txt
2015-10-17
06 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-06.txt
2015-10-14
05 (System) Notify list changed from david.black@emc.com, draft-ietf-tsvwg-circuit-breaker.ad@ietf.org, draft-ietf-tsvwg-circuit-breaker.shepherd@ietf.org, tsvwg-chairs@ietf.org, draft-ietf-tsvwg-circuit-breaker@ietf.org to (None)
2015-10-07
05 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-05.txt
2015-10-05
04 Spencer Dawkins I'm pretty sure this is "Revised ID Needed", but I always like to confirm that before plopping it into the datatracker ...
2015-10-05
04 Spencer Dawkins IESG state changed to AD Evaluation::External Party from Publication Requested
2015-09-30
04 Amy Vezza Notification list changed to david.black@emc.com, draft-ietf-tsvwg-circuit-breaker.ad@ietf.org, draft-ietf-tsvwg-circuit-breaker.shepherd@ietf.org, tsvwg-chairs@ietf.org, draft-ietf-tsvwg-circuit-breaker@ietf.org from "David L. Black" <david.black@emc.com>
2015-09-28
04 David Black
Document shepherd write-up:

                  Network Transport Circuit Breakers
                  …
Document shepherd write-up:

                  Network Transport Circuit Breakers
                  draft-ietf-tsvwg-circuit-breaker-04

1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins


  This document explains what is meant by the term "network transport
  Circuit Breaker" (CB).  It describes the need for circuit breakers
  when using network tunnels, and other non-congestion controlled
  applications.  It also defines requirements for building a circuit
  breaker and the expected outcomes of using a circuit breaker within
  the Internet.

The WG has requested Best Current Practice status because this draft
provides protocol design (and in some cases, operational) guidelines
for the Internet.  This request is the rough consensus of the WG.

2. Review and Consensus

The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is strongly supported by the portion of the TSVWG that is
concerned with congestion, and has received reviews and discussions from
several experts within that community.  Overall support for this draft
comes from about a dozen members of the WG, which is relatively broad
support for a TSVWG draft.  Discussion in TSVWG has not been controversial;
the draft has evolved moderately from the initial -00 version that the
WG adopted about a year ago, with no major objections to its content in
WG discussion.

In contrast, the circuit breaker concept has been controversial in other
IETF forums, with strong opposition observed to imposing circuit breaker
support as a protocol design requirement.  The concept of a managed
circuit breaker is intended to allow response via a different control-plane
protocol or via other mechanisms such as OAM and/or network operator
monitoring of service delivery.  The shepherd expects this issue to
resurface at IETF Last Call, and is accordingly dusting off his (virtual)
Kevlar vest.

There is complementary work elsewhere in the IETF, e.g., the RTP circuit
breaker activity in the AVTCORE WG.

3. Intellectual Property

The draft author has stated his direct, personal knowledge that any IPR
related to this document has already been disclosed, in conformance with
BCPs 78 and 79.

4. Other Points

idnits 2.13.02 ran clean on the -04 version.
There are no DOWNREFs or IANA Considerations.

The IESG should take note of the potential controversy surrounding the
circuit breaker concept in general (see Section 2 above).
2015-09-28
04 David Black Responsible AD changed to Spencer Dawkins
2015-09-28
04 David Black IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2015-09-28
04 David Black IESG state changed to Publication Requested
2015-09-28
04 David Black IESG process started in state Publication Requested
2015-09-28
04 David Black Tag Doc Shepherd Follow-up Underway cleared.
2015-09-28
04 David Black Based on WG Last Call discussion
2015-09-28
04 David Black Intended Status changed to Best Current Practice from None
2015-09-28
04 David Black Changed document writeup
2015-09-25
04 David Black IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2015-09-25
04 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-04.txt
2015-09-21
03 Gorry Fairhurst Tag Doc Shepherd Follow-up Underway set.
2015-09-21
03 Gorry Fairhurst IETF WG state changed to In WG Last Call from WG Document
2015-09-10
03 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-03.txt
2015-07-20
02 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-02.txt
2015-03-31
01 Gorry Fairhurst Notification list changed to "David L. Black" <david.black@emc.com>
2015-03-31
01 Gorry Fairhurst Document shepherd changed to David L. Black
2015-03-31
01 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-01.txt
2015-01-02
00 David Black This document now replaces draft-fairhurst-tsvwg-circuit-breaker instead of None
2014-09-27
00 Gorry Fairhurst New version available: draft-ietf-tsvwg-circuit-breaker-00.txt