I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-access-network-identifier-08.txt Reviewer: Francis Dupont Review Date: 20150601 IETF LC End Date: 20150609 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 2 and 10 page 16: Acknowledgements -> Acknowledgments (BTW you wrote behavior, not behaviour, so please keep US spelling :-) - 3 page 5: I was looking for the RFC 2119 reference there but it was just after the Abstract. So I went to the RFC-Editor webpages to read what the last RFC Style Guide says: the requirement language section is supposed to be in the body (vs headers) after the introduction (i.e., exactly where I expected to find it :-). Note it doesn't really matter and if something needs to be fixed it is more likely the tool you used... - 4.3.1 page 7: Identifier[ANI]. ^ insert a space here - 4.4.2 page 10: Ex: -> e.g., - 4.4.2 page 10: the DNS encoding is a bit ambiguous because there are (too) many things in RFC 1035. I think you mean the wire format (vs text format) but perhaps it should be better to be more accurate in the wording? - 7 page 14 (twice): must -> MUST. - 7 page 14: I suggest to change: ... When generating a response, the server echoes back Relay Agent Information options by ... When generating a response, the server SHALL echo back Relay Agent Information options - 9 page 15: And, [RFC3118] and [RFC3315] -> [RFC3118] and [RFC3315] - 9 page 15: draft-ietf-dhc-sedhcpv6-07.txt is under IESG review, perhaps will be published before your document, and obsoletes a part of the argument (unfortunately not the "in active use" even the day before my review I finished the code of a secure DHCPv6 prototype :-). - authors' addresses pages 17 and 18: no uniformity in the case of country names (The UPU says upper case but this doesn't apply to I-Ds/RFCs... The RFC-Editor will fix addresses). Regards Francis.Dupont at fdupont.fr PS for native English speakers: is unsecure proper English? My speller says insecure and unsecured are but not unsecure.