Re: [Gen-art] review of draft-ietf-mif-mpvd-arch-09.txt

[Jari Arkko <[e-mail]>]

Thanks for your review, Francis. Authors, have you see Francis’ comments?

Jari

On 16 Feb 2015, at 15:26, Francis Dupont <[e-mail]> wrote:

> 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
> 
> [e-mail]
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art