Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP
RFC 6472
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Ron Bonica; former steering group member) Yes
While I agree with Adrian's procedural comments, I believe that the basic idea is sound.
(Russ Housley; former steering group member) Yes
(Sean Turner; former steering group member) Yes
(Stewart Bryant; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
I would like to see proper use of RFC 2119 language in Section 3 strongly advised == RECOMMENDED should withdraw == SHOULD withdraw operators may begin filtering == MAY --- Section 3 It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) may not support routes with AS_SETs / I prefer s/may not/might not/
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(David Harrington; former steering group member) No Objection
I support Adrian's Discuss, and pete's comments. Either this is an update to the existing standards, and thus should be standards-track itself, OR it is a usage recommendation. Either way, the document, especially, the RFC2119 language, should be modified to reflect the purpose.
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
Paragraph 1 of section 3 has a couple of places that look appropriate for 2119 language: "are strongly advised to not" could easily be "SHOULD NOT" and "should withdraw" could be "SHOULD withdraw". Indeed, the last sentence of section 3 mirrors the language of 2119 where it says "the operator should understand the full implications of the change." So if you really want to use 2119, it seems like these are good places to use it. However, the one (and only one) place you *do* use 2119 language, it is used incorrectly: It is worth noting that new technologies (such as those that take advantage of the "X.509 Extensions for IP Addresses and AS Identifiers" ([RFC3779]) may not support routes with AS_SETs / AS_CONFED_SETs in them, and MAY treat as infeasible routes containing them. Future BGP implementations may also do the same. This is not defining the optional behavior of treating routes as infeasible. This is saying that it should be noted that new technologies might treat routes as infeasible. I suggest changing "MAY" to "may" or "might". If you put SHOULDs into paragraph 1, include the 2119 reference. If you don't, remove the 2119 reference entirely. Either way, fix the MAY.
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
should this UPDATE something? e.g. RFCs 4271/5065 maybe
(Wesley Eddy; former steering group member) No Objection