Last Call Review of draft-ietf-radext-nai-10
review-ietf-radext-nai-10-opsdir-lc-ersue-2014-12-04-00

Request Review of draft-ietf-radext-nai
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-12-02
Requested 2014-11-11
Other Reviews Secdir Last Call review of -10 by Yoav Nir (diff)
Review State Completed
Reviewer Mehmet Ersue
Review review-ietf-radext-nai-10-opsdir-lc-ersue-2014-12-04
Posted at http://www.ietf.org/mail-archive/web/ops-dir/current/msg00638.html
Reviewed rev. 10 (document currently at 15)
Review result Has Nits
Draft last updated 2014-12-04
Review completed: 2014-12-04

Review
review-ietf-radext-nai-10-opsdir-lc-ersue-2014-12-04



I have reviewed the document "The Network Access Identifier" (draft-ietf-radext-nai-11.txt) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written
primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.




 




Intended status: Standards Track




Obsoletes: RFC 4282




Current draft status: Submitted to IESG for Publication 




 




Summary: The document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing resources. This document obsoletes RFC 4282.




 




I would suggest to change:




"In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server." as




"Concerning the support of roaming capability, one of the requirements is the ability to identify the user's home authentication server."




 




It is praiseworthy that the draft includes a section on the administration of names, which however has been kept short and handles NAI realm namespace piggybacks, NAI realm name uniqueness and the location of the authentication server.




 




I agree with Brian Haberman who asks to drop the "hope" from section 1.3 making a more definitive statement about the use of the document. There are three occurrences of the verb hope, which should be rewritten in a more explicit
manner.




 




I don't see any other issues from the operations and management pov.




 




There are some nits in the draft:




 




The format of Table of Contents is wrong. It lists Appendix A before Introduction.




 




== The document seems to contain a disclaimer for pre-RFC5378 work, but was




   first submitted on or after 10 November 2008.  The disclaimer is usually




   necessary only for documents that revise or obsolete older RFCs




 




-- Obsolete informational reference: RFC 5335




   (Obsoleted by RFC 6532)




 




Cheers, 



Mehmet