Additional Kerberos Naming Constraints
draft-ietf-krb-wg-naming-07

In section 3.1: is the string "WELLKNOWN" case sensitive?

6.  IANA Considerations

   This document provides the framework for defining well-known Kerberos
   names and Kerberos realms.  A new IANA registry should be created to
   contain well-known Kerberos names and Kerberos realms that are
   defined based on this document.  The evaluation policy is
   "Specification Required".

This needs (at least) an Informative reference to RFC 5226.

1. Please expand KDC at first occurence. 

2. In the Security Considerations section: 

> It is possible to have name collision with well-known names because
   Kerberos as defined in [RFC4120] does not reserve names that have
   special meanings, consequently care MUST be taken to avoid accidental
   reuse of names.

s/care MUST be taken to avoid accidental reuse of names/accidental reuse of names MUST be avoided/

I would like to echo Ralph's comment: given that RFC 4120 does not have the concept of reserved names, this specification cannot legislate the behavior of applications that currently conform to RFC 4120 but not this specification. Furthermore, it would be helpful to describe the recommended behavior of a client that supports reserved names when it interacts with an authentication service or ticket granting service that does not support reserved names; for example, does the client need to discard the ticket it receives?

Section 3.1:

   If a well-known principal name is used as the client principal name
   or the server principal name but not supported, the Authentication
   Service (AS) [RFC4120] and the application server MUST reject the
   authentication attempt.

What does "not supported" mean here?  How does this behavior compare with the behavior of currently deployed ASs; i.e., will an AS implemented before this document was written reject the authentication attempt?

1) Sec 1: It's odd that there's a 2119 requirement in the intro (before the requirements terminology).  Could this be reworked?

2) Sec 1: r/is to remedy/remedies

3) Sec 1: It would be nice to have some text that indicates say which parts of 4120 you're updating.  Section 6.1, 6.2, 7.5.7, and 7.5.8 right?  Side note: Interesting that in 4120 Section 6.2 uses NT-TYPENAME while 7.5.8 uses the prefix KRB and underscores instead of dashes (KRB_NT_TYPENAME).  Should KRB_NT_WELLKNOWN also be NT-WELLKNOWN?

4) Sec 3.1, 2nd para, 2nd sentence: r/must/MUST