Thanks for your review, Francis. Authors, have you see Francis’ comments?
Jari On 16 Feb 2015, at 15:26, Francis Dupont <[email protected]> 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 > > [email protected] > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
