BGP ACCEPT_OWN Community Attribute
draft-ietf-l3vpn-acceptown-community-10

Nothing blocking here, but some things to please consider (and chat with me if you think it's needed):

Please expand "VRF" and "PE" on first use.

-- Section 2.1 --

   A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value
   matches that of the receiving speaker if all of the following are
   true:

Just checking here:

1. The "MAY" means that even if all the following are true, the router might still not accept the route -- it's optional.  Is that what's intended?

2. This text says nothing about what happens if *not* all of the following are true.  A router might still accept the route (or not).  Is that what's intended?  Or is a "MUST NOT accept" meant to be implied in that case?

   A route MUST never be accepted back into its source VRF, even if it
   carries one or more Route Targets (RTs) which match that VRF.

I think "MUST never be accepted" is a bit awkward, because one immediately thinks of "MUST" as a positive command.  I suggest "A route MUST NOT ever be accepted...."

-- Appendix A --
The title says "Local Extranet Application (non-informative)".  Do you mean "non-normative" here?

Clearing my DISCUSS on the basis that the following text is added as a RFC editor note, as discussed with Adrian and Ron Bonica:

OLD: 
   ACCEPT_OWN handling SHOULD be controlled by configuration, and SHOULD
   default to being disabled. 

NEW: 
   ACCEPT_OWN handling SHOULD be controlled by configuration, and if controlled by 
  configuration it MUST default to being disabled

I agree with Alia's suggested text change.

I support Stephen's comment.

In the ballot:

  Opposition to the proposal was initially expressed by one contributor, 
  but there was good support for adoption and no particular follow-up 
  from that contributor.

I'm glad someone wrote it down, but it's not exactly confidence inspiring. Was this just random opposition without explanation, or did the person have a point and it got addressed to the chairs' satisfaction, or did something get dropped? I expect it's that the concern was addressed reasonably, but the above doesn't exactly say that.

- section 6: I think I buy the argument that there are no
new security issues here but that's only true I think if the
security issues with route reflectors are somewhere (and if
those cover cases where crypto is not used to enforce the
"P" in VPN). Wouldn't a reference to something like that be
good here?

- I like non-informative appendices:-)