Hi Jari, Yes. As far as draft revision is concerned, I was following this:
>> In no case should you submit an updated version of the document without consulting the AD/document shepherd. For responses to comments I can respond today if that's what you meant. Thank you, Dmitry On Thu, Feb 19, 2015 at 2:51 AM, Jari Arkko <[email protected]> wrote: > 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 > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
