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 . Document: draft-ietf-homenet-dot-12 Reviewer: Dale R. Worley Review Date: 2017-08-24 IETF LC End Date: 2017-08-25 IESG Telechat date: 2017-08-31 Summary: This draft is ready for publication as a Standards Track RFC. It has some nits that should be considered before publication. 4. Domain Name Reservation Considerations 3. Name resolution APIs MUST send queries for such names to a recursive DNS server that is configured to be authoritative for the 'home.arpa.' zone appropriate to the homenet. If I understand the terminology correctly, this rules out sending the query to a DNS server that recursively sends the query to a server that is authoritative for home.arpa. If that is intended and there are technical reasons for making this prescription, that's OK, but I want to check that that is intended, as this rule is stricter than the similar rule in the second paragraph of item 4, which is qualified "Unless configured otherwise". 4. Domain Name Reservation Considerations There are 5 paragraphs under item 4. It might be worth giving them separate numbers, or if they truly form a unified topic, giving them sub-numbers 4a, 4b, etc. 6. Security Considerations Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved is an insecure delegation, as in [RFC6303] section 7. In context what this means is clear, but its literal meaning is sufficiently incorrect that I think it could be clarified, perhaps to Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved by a validating resolver that is not aware of the local meaning is an insecure delegation, as in [RFC6303] section 7. [EOF]