Thank you Pete for your review.
I will take your and Chris' reviews when considering the next steps.
Regards
-éric
-----Original Message-----
From: Pete Resnick via Datatracker <noreply@xxxxxxxx>
Reply-To: Pete Resnick <resnick@xxxxxxxxxxxx>
Date: Wednesday, 20 May 2020 at 18:03
To: "gen-art@xxxxxxxx" <gen-art@xxxxxxxx>
Cc: "draft-ietf-dhc-problem-statement-of-mredhcpv6.all@xxxxxxxx" <draft-ietf-dhc-problem-statement-of-mredhcpv6.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>, "dhcwg@xxxxxxxx" <dhcwg@xxxxxxxx>
Subject: Genart last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05
Resent-From: <alias-bounces@xxxxxxxx>
Resent-To: <rengang@xxxxxxxxxxxxx>, <he-l14@xxxxxxxxxxxxxxxxxxxxx>, <liuying@xxxxxxxxxxxxx>, <volz@xxxxxxxxx>, <tomasz.mrugalski@xxxxxxxxx>, Eric Vyncke <evyncke@xxxxxxxxx>, <ek.ietf@xxxxxxxxx>, Bernie Volz <volz@xxxxxxxxx>
Resent-Date: Wednesday, 20 May 2020 at 18:03
Reviewer: Pete Resnick
Review result: Not Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-dhc-problem-statement-of-mredhcpv6-05
Reviewer: Pete Resnick
Review Date: 2020-05-20
IETF LC End Date: 2020-05-25
IESG Telechat date: Not scheduled for a telechat
Summary:
This document is not ready for publication.
Major issues:
Nowhere in the Introduction does this document explain its motivation: Why is a
survey of these mechanisms important for the IETF to publish? It claims that it
is doing "a detailed analysis" in order to "clarify the problems, design
principles, and extract and unify the design specifications to help better
solve the multi-requirement extension problems", but the rest of the document
seems to do nothing more than describe extensions, not do any real analysis of
design principles. And after reading the introduction, I still don't understand
what a "multi-requirement extension" is (the term is never defined), nor do I
know what the problem is with them. Unless the motivation for this document can
be better explained, I do not see this document as being appropriate for
publication.
Minor issues:
None.
Nits/editorial comments:
The entire document could use a good editorial scrub. There are quite a few
grammatical issues.
3.2, 4.2.2, and 4.2.4 give lists of example implementations and options. These
seem unnecessary. When particular examples are useful, of course they can be
included, but simply long lists are not useful.
The general model in 4.1 seems unnecessary; this is nothing that you wouldn't
already know if you understand DHCP.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
