Making Route Flap Damping Usable
draft-ietf-idr-rfd-usable-04
Yes
(Brian Haberman)
(Richard Barnes)
(Sean Turner)
No Objection
(Benoît Claise)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Stephen Farrell)
Abstain
Note: This ballot was opened for revision 03 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2013-09-30 for -03)
Unknown
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 IESG member
Yes
Yes
(for -03)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(for -03)
Unknown
Sean Turner Former IESG member
Yes
Yes
(for -03)
Unknown
Stewart Bryant Former IESG member
Yes
Yes
(2014-02-05)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2013-10-09 for -03)
Unknown
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 IESG member
No Objection
No Objection
(for -03)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2014-02-05)
Unknown
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 IESG member
No Objection
No Objection
(for -03)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2013-10-03 for -03)
Unknown
False flap attack? Groan.
Barry Leiba Former IESG member
(was Discuss)
Abstain
Abstain
(2014-02-06)
Unknown
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