Skip to main content

Last Call Review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05
review-ietf-dhc-problem-statement-of-mredhcpv6-05-genart-lc-resnick-2020-05-20-00

Request Review of draft-ietf-dhc-problem-statement-of-mredhcpv6
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-05-25
Requested 2020-05-11
Authors Ren Gang , Lin He , Ying Liu
I-D last updated 2020-05-20
Completed reviews Secdir Last Call review of -05 by Christopher A. Wood (diff)
Genart Last Call review of -05 by Pete Resnick (diff)
Opsdir Last Call review of -05 by Nagendra Kumar Nainar (diff)
Assignment Reviewer Pete Resnick
State Completed
Request Last Call review on draft-ietf-dhc-problem-statement-of-mredhcpv6 by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/IBPTiJLIVHIEazLmWLg1dyAG1Ic
Reviewed revision 05 (document currently at 08)
Result Not ready
Completed 2020-05-20
review-ietf-dhc-problem-statement-of-mredhcpv6-05-genart-lc-resnick-2020-05-20-00
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.