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

[Dmitry Anipko <[e-mail]>]

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 <[e-mail]> wrote:

> 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
>
>