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

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