I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mif-mpvd-arch-09.txt
Reviewer: Francis Dupont
Review Date: 20150212
IETF LC End Date: 20150206
IESG Telechat date: 20150219

Summary: Almost Ready

Major issues: None

Minor issues: the authentication in DHCPv6 (RFC 3315 section 21)
is considered in the document as a strong authentication.
I have to disagree with this, in particular when it comes with
SeND... i.e., IMHO the authentication in DHCPv6 is mainly in
the name/title. Note there is a current work for a (real/strong)
authentication in DHCPv6.
Now it is my own opinion: I leave this to the IESG and the
security directorate.

Nits/editorial comments:
 These are related to the 09 version (the 10 version was published
too late for me but there are a few changes between 09 and 10).

 - Abstract page 1 and 1 page 3: expand the MIF abbrev

 - 2.2 page 6: beloinging -> belonging

 - 2.4 page 7: advertize -> advertise

 - 3.2 page 8: first occurrence of DHCPv6 auth:
  "DHCPv6 and RAs both provide some form of authentication..."
  Note the next sentence states that authentication is not
  authorization (something you could always remind of :-).
  To avoid a future confusion between DHCPv6 auth and
  draft-ietf-dhc-sedhcpv6 IMHO an explicit reference is required
  (and I suggest to add the SeND reference too).

 - 3.3 page 8: i.e. -> i.e.,

 - 3.3 page 8: utiilize -> utilize

 - 3.5 page 9: formally this subsection 3.5 about IKEv2 doesn't belong
  to section 3... I have no idea about to fix this (nor whether it
  should be fixed :-)

 - 4.1 page 10: in the figure I expect one (vs. two) Internet cloud

 - 5.2.1 page 12: e.g. -> e.g.,
  (and 5.2.4 page 15, 5.3 page 5, 5.3 page 16 (twice), 5.4 page 16)

 - 5.2.2 page 13 (twice): advertized -> advertised
 - 7.1 page 18: Wifi -> Wi-Fi (wikipedia says WiFi is incorrect too)

 - 11 page 20: E.g. -> E.g.,

 - 11 page 20: there are a lot of RFC 2119 keywords used in lower cases
  in this section. But the fact of they are keywords is not bound to
  the case, so please consider:
   - either to promote them to more visible keywords, i.e., put them
    in upper case
   - either to use a synonym wording (e.g., must -> has to) so
    there is no ambiguity.
  BTW I expect the first solution in Security Considerations but
  it is not the only place where this problem occurs, just the more
  visible/critical one.

 - 11 page 20: my speller doesn't like authenticatable
  (I can't find a synonym but IMHO the simplest is to remove this word):

    PvD identifier to an authenticatable identity, and must be able to
    authenticate that identity

 -> 

    PvD identifier to an identity, and must be able to
    authenticate that identity

Regards

Francis.Dupont@fdupont.fr