Making Route Flap Damping Usable
RFC 7196

Note: This ballot was opened for revision 03 and is now closed.

(Richard Barnes) Yes

(Stewart Bryant) Yes

Comment (2014-02-05)
No email
send info
Benoit and Barry agree on the text change, so I am looking using Barry's
proposed text.

As far as I can see the text used by the authors is semantically equivalent
and this is a matter of style, which is outside the DISCUSS criteria.

Because I am unable to see the difference I am unable to explain the
difference to the authors, and am therefore unwilling to force a text 
change on them.

OLD (version -03)
   The following RFD parameters are common to all implementations.  Some
   may be tuned by the operator, some not.
NEW
   This table shows key parameters for RFD implementations, and lists some
   existing default settings for those parameters.  Some may be tuned by the
   operator, some not.  There is currently no consensus on a single set of
   default values.
END

The text in -04 actually says:

"The following RFD parameters are common to all implementations.  Some
may be tuned by the operator, some not.  There is currently no
consensus on a single set of default values." 

The title of Table 1 is "Default RFD Paramaters of Juniper and Cisco" which
were the implementations studied.

=======

OLD (version -03)
   Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.
NEW
   Default Configurable Parameters:  In order not to break existing
      operational configurations, deployed BGP implementations SHOULD
      NOT change their default values for the parameters listed in Table 1.
END

The text in -04 says:

"Default Configurable Parameters:  In order not to break existing
      operational configurations, existing BGP implementations
      including, the examples in Table 1, SHOULD NOT change their
      default values."

The only significant difference seems to be s/deployed/existing/ which
are semantically the same and i/including, the examples in Table 1/
which is a subset of the statement requested by the discuss holders.

(Adrian Farrel) Yes

Comment (2013-09-30 for -03)
No email
send info
Thanks for this simple and sensible document.

I'm an insufferable pedant :-(

In Section 6 you say "The following changes are recommended"
I don't think it matters whether these are changes or not.
Maybe "The use of the following values is recommended."

(Brian Haberman) Yes

(Sean Turner) Yes

(Jari Arkko) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss) No Objection

(Spencer Dawkins) No Objection

Comment (2014-02-05)
No email
send info
Still No-Objection, but I support the Barry/Benoit Discusses. 

Looking back, I said that in previous e-mail on those Discusses but never added it to my ballot position - sorry.

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Comment (2013-10-09 for -03)
No email
send info
riff on benoit's comment


      Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.

This is what I'd call the phenomena of least surprise. e.g. don't change unspecifed (and therefore default values). I'd personally prefer that it say something like:


     Default Configurable Parameters:  In order not to break existing
      operational configurations, existing BGP implementations inclusive 
      of the examples in Table 1 SHOULD NOT change default values.

other than that I'm an un-equivocal yes to this.

(Ted Lemon) No Objection

Comment (2013-10-03 for -03)
No email
send info
False flap attack?   Groan.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

Barry Leiba (was Discuss) Abstain

Comment (2014-02-06)
No email
send info
Moved to a comment...
UPDATED after the IESG telechat:

In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up what it was that I didn't understand, and in figuring out how to resolve it.  Section 3 looks like general recommendations of default values, and Section 6 looks like it's telling everyone to use those default values.  The combination is confusing because it appears at the same time to be specific to two vendors, and yet perhaps to tell other vendors what values to use.  And I'm not sure what to do if I'm a new vendor aiming to support this.

Section 3 needs to make it clear what the purpose of the table is -- the text that's there is too minimal for anyone to understand the intent.  On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended:

OLD (version -03)
   The following RFD parameters are common to all implementations.  Some
   may be tuned by the operator, some not.
NEW
   This table shows key parameters for RFD implementations, and lists some
   existing default settings for those parameters.  Some may be tuned by the
   operator, some not.  There is currently no consensus on a single set of
   default values.
END

The part of Section 6 that talks about default configurable parameters needs to make it clear that it's not talking just to Cisco and Juniper, and that it's not telling other vendors to use the specific values in Table 1 (and how could it, as the values differ between the two vendors listed).  On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended:

OLD (version -03)
   Default Configurable Parameters:  In order not to break existing
      operational configurations, BGP implementations SHOULD NOT change
      the default values in Table 1.
NEW
   Default Configurable Parameters:  In order not to break existing
      operational configurations, deployed BGP implementations SHOULD
      NOT change their default values for the parameters listed in Table 1.
END