Making Route Flap Damping Usable
RFC 7196
Yes
No Objection
Abstain
Note: This ballot was opened for revision 03 and is now closed.
(Adrian Farrel; former steering group member) Yes
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; former steering group member) Yes
(Richard Barnes; former steering group member) Yes
(Sean Turner; former steering group member) Yes
(Stewart Bryant; former steering group member) Yes
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.
(Benoît Claise; former steering group member) (was Discuss) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
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.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
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; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection
False flap attack? Groan.
(Barry Leiba; former steering group member) (was Discuss) Abstain
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