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

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