Well, the only important thing was that you’ve seen the comments and are planning to address those that make sense from your perspective. You should of course defer to your AD wrt when a document update should be posted.
Jari On 19 Feb 2015, at 18:04, Dmitry Anipko <[email protected]> wrote: > 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 > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
