Skip to main content

Last Call Review of draft-ietf-dhc-addr-notification-11

Request Review of draft-ietf-dhc-addr-notification
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2024-04-30
Requested 2024-04-16
Authors Warren "Ace" Kumari , Suresh Krishnan , Rajiv Asati , Lorenzo Colitti , Jen Linkova , Sheng Jiang
I-D last updated 2024-04-30
Completed reviews Intdir Telechat review of -11 by Carlos J. Bernardos (diff)
Dnsdir Telechat review of -12 by Jim Reid (diff)
Dnsdir Last Call review of -11 by Jim Reid (diff)
Genart Last Call review of -11 by Mallory Knodel (diff)
Secdir Last Call review of -11 by Peter E. Yee (diff)
Opsdir Last Call review of -11 by Niclas Comstedt (diff)
Assignment Reviewer Peter E. Yee
State Completed
Request Last Call review on draft-ietf-dhc-addr-notification by Security Area Directorate Assigned
Posted at
Reviewed revision 11 (document currently at 13)
Result Has nits
Completed 2024-04-30
Reviewer: Peter Yee
Review result: Has Issues

I reviewed this document as part of the Security Directorate's ongoing effort
to review all IETF documents being processed by the IESG.  These comments were
written primarily for the benefit of the Security Area Directors.  Document
authors, document editors, and WG chairs should treat these comments just like
any other IETF Last Call comments.

Document: draft-ietf-dhc-addr-notification-11
Reviewer: Peter Yee
Review Date: 2024-04-30
IETF LC End Date: 2024-04-30
IESG Telechat date: Unknown

Summary: This document specifies a way for an IPv6 host to register its
addresses with a DHCPv6 server primarily as aid to troubleshooting. The
addresses that a host might want to register this way are static addresses or
ones obtained via SLAAC, for example. This registration of an address is mostly
informative, although DHCPv6 servers attempt to determine the correctness of
the address registered as much as is feasible. I did not find any substantive
issues with the document, but it has some nits that should be corrected. These
are mostly offered to lessen the burden on the RFC Editor, although a few of
them should be addressed because they have bearing on the operation of the

Major issues: None

Minor issues: None


Page 3, section 3, 3rd sentence: append “in” after “option code”.

Page 4, 1st full paragraph, last sentence: change “an” to “a” before “DHCPv6”.
Delete “to” before “being”.

Page 5, section 4.1, 1st sentence: it says “includes” but doesn’t say where the
option is included. Perhaps point to the statement below after the figure.

Page 6, 3rd paragraph after Figure 3, 1st sentence: Presumably the IA Address
option is inside of an IA_NA or IA_TA option as required by RFC 8415, section
21.6. Should this be spelled out?

Page 10, section 4.4, title: change “Signalling” to “Signaling” since the
former is the preferred spelling in British English, but there are several
other words in the document that are written in American English (e.g.,
behavior, apologize). You could go the other way, but it would be more work.

Page 11, 1st paragraph, 2nd sentence: change “retranmits” to “retransmits”.

Page 11, section 4.6, 2nd paragraph, 3rd sentence: you might want to indicate
that the range is inclusive (as implied by the 3rd bullet item on the next
page). You might also want to give a useful precision needed across this range
to offer a reasonable desynchronization effect. Otherwise, choosing to use a
single digit after the decimal point meets the requirement but only provides 3
multiplier values. I have no idea how much desynchronization is required, but
I’m guessing this is network dependent.

Page 11, section 4.6, 3rd paragraph: delete the comma after “future”.

Page 12, 1st bullet item: spell out “PIO” on first use as it’s not in the RFC
Editor’s list of abbreviations that don’t need to be expanded.

Page 12, 3rd bullet item: the same holds true for “RA”.

Page 12, 6th bullet item, 1st sentence: delete “the” after “match”.

Page 12, 6th bullet item, 2nd sentence: insert “on the” before “order”.

Page 13, 2nd paragraph, 2nd sentence: does this setting of IA Address lifetime
field values to zero occur only in ADDR-REG-INFORM messages or could it be done
in other message? This paragraph seems a little underspecified although one
could assume that the ADDR-REG-INFORM message is the logical choice.

Page 13, section 6, 1st paragraph, 2nd sentence: append a comma after “e.g.”.
Change “contained” to “containing”.

Page 13, section 6, 3rd paragraph, last sentence: append a comma after “anyway”

Page 13, section 6, 4th paragraph, 2nd sentence: append a comma after “However”.

Page 14, 1st paragraph, 2nd sentence: change the hyphen in “Layer-2” to a
space. Change “to mitigate” to “mitigating” of “mitigation of”.