Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP
RFC 6472

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

(Ron Bonica) Yes

Comment (2011-09-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
While I agree with Adrian's procedural comments, I believe that the basic idea is sound.

(Stewart Bryant) Yes

(Russ Housley) Yes

(Sean Turner) Yes

(Jari Arkko) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2011-09-04)
No email
send info
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/

(Stephen Farrell) No Objection

Comment (2011-09-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
should this UPDATE something? e.g. RFCs 4271/5065 maybe

(David Harrington) No Objection

Comment (2011-09-07 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Pete Resnick) No Objection

Comment (2011-09-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Dan Romascanu) (was Discuss) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection