Reviewer: Peter Yee Review result: Has Nits 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 scheme. Major issues: None Minor issues: None Nits: 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”. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
