Skip to main content

Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP
RFC 6472

Yes

(Russ Housley)
(Sean Turner)
(Stewart Bryant)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Peter Saint-Andre)
(Ralph Droms)
(Robert Sparks)
(Wesley Eddy)

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

(Ron Bonica; former steering group member) Yes

Yes (2011-09-05)
While I agree with Adrian's procedural comments, I believe that the basic idea is sound.

(Russ Housley; former steering group member) Yes

Yes ()

                            

(Sean Turner; former steering group member) Yes

Yes ()

                            

(Stewart Bryant; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2011-09-04)
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

No Objection (2011-09-08)

                            

(David Harrington; former steering group member) No Objection

No Objection (2011-09-07)
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

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2011-09-04)
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

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2011-09-02)
should this UPDATE something? e.g. RFCs 4271/5065 maybe

(Wesley Eddy; former steering group member) No Objection

No Objection ()