I am an assigned INT directorate reviewer for <draft-ietf-6man-vpn-dest-opt-04.txt>. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, the document is _nearly_ ready to go to IETF Last Call and therefore can be forwarded to the IESG.

Overall, the document is clear. The description of the VPN Service option is consistent with RFC 8200 from what I can judge, and the formatting of the option respect the formatting boundaries stated for destination options. 

I have three remarks regarding the formatting of the IPv6 packet containing this option and its interpretation:
	- In section 3, it is mentioned that the low order 20 bits of the Option data are used to identify the outgoing interface or a VPN-specific portion of the FIB that will be used to identify the outgoing interface. I wonder whether this should be clarified, and whether a flag of some sort could be used to determine whether the 20 bits identify an interface directly or a FIB portion. 
	- In Section 4, the ESP header is mentioned at the end of the section but it is not listed among the optional headers to be included at the beginning of the section, which is a bit astonishing. It is even more astonishing since ESP is clearly mentioned in Section 7.
	Besides, I am wondering why the use of ESP is not encouraged, given that my assumption for a tunneling technology would be that the content of the tunnel is hidden or encrypted from the outside. 
	- In my understanding, the end of section 4 describes the Destination Options extension header of the outer IPv6 packet carrying the tunneled packet. Thus, I am wondering why the authors mention that the Next Header field must identify the protocol of the customer data and not the fact that the payload carries an IPv6 packet, thus using value 41 as mentioned in RFC 2473.

The following are other issues I found with this document that SHOULD be corrected before publication:
	- In Section 7, the sentence describing the behavior of edge nodes with regards to the filtering of the VPN Service option is unclear (at least for me). For instance, I would mention that the packet are discarded if they are bound to exit the edge node through an interface exiting the limited domain.

The following are minor issues (typos, misspelling, minor text improvements) with the document:
	- Throughout Section 9, I was left wondering whether an open testbed is already available, against which potential experimenters could test their implementation. If such a testbed exists, I would reference it.