BGP/MPLS Layer 3 VPN Multicast Management Information Base
RFC 8503

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

Martin Vigoureux Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-09-11 for -11)
No email
send info
A general comment that we've been making on lots of documents in this
space is that it would be nice to be in a place where the acronym "VPN"
implies transport encryption.  It's unclear that it's appropriate to request
changes to this specific document toward that end, though.

Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security
considerations in the list of address-related objects that may have
privacy/security impact.  That list is predicated on being "objects with a
MAX-ACCESS other than not-accessible", but all the instances of
mvpnAdvtPeerAddr I found in the body text were marked as not-accessible.
Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs,
mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and
mvpnMrouteNextHopAddr.  (Incidentally, why ar mvpnMrouteCmcastSourceAddrs
and mvpnMrouteNextHopSourceAddrs plural with the final 's'?)

Perhaps using subsections to separate the various tables' descriptions
would aid readability.

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja K├╝hlewind) No Objection

(Terry Manderson) No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection