An Information Model for Kerberos Version 5
draft-ietf-krb-wg-kdc-model-16

Thanks for a readable document and for doing the important work of 
writing an information model rather than a data model.

I have only a number of petty nits...

---

I do agree wit others' comments about uppercase and pseudo-2119 
langauge. At least his could be tidied up a bit. For example, "MUST NOT
be OPTIONAL" is a lovely mixture :-)

---

Abstract should say what a KDC is.

---

Please decide "kerberos" or "Kerberos"

---

   The Kerberos version 5 authentication service described in [RFC4120]
   describes how a Key Distribution Center (KDC) provides authentication
   to clients.  The standard does not stipulate how a KDC is managed and

RFC 4120 is not a standard in the IETF sense of the word.
Maybe s/The standard/RFC 4120/

---

I am not convinced that Section 5 adds to this document, and I can 
believe that it might confuse the reader and potentially lead to a
restricted view of implementation options.

If it were to be enitely deleted, I would not miss it.

These are non-blocking, but please consider them seriously, and feel free to
chat with me about them:

I find Section 2 to be rather odd.  I don't like the way you say that the terms are used as defined in 2119, and then go on to say, "Oh, but they're really not, and here's what we mean."  I would *greatly* prefer that you eliminate the 2119 boilerplate and reference, and simply define the terms here, as you mean them.

-- Section 4.1 --

   The Principal MUST be implemented in full and MUST NOT be OPTIONAL in
   an implementation

I think the combination of not-really-2119 terms here is confusing: "MUST NOT be OPTIONAL".  Maybe the right fix here is just to use lower-case "optional".  Or, better, maybe just this: "The Principal MUST be implemented in full, as a required part of every implementation."

-- Section 4.3 --

Similarly, make "MUST NOT REQUIRE" into "MUST NOT require", probably.

Based on the removal of the standard 2119 template and the new text in section, I'm willing to clear the DISCUSS. Given how unusual it is nowadays to have MUST/SHOULD/etc. without 2119, Stephen might decide whether this is worth mentioning to the rest of the IETF, but that's his call. Just a few things that might still be worth some updates:

1. MUST and MAY are used in the introduction before they are defined in section 2. You might just want to avoid them there.

4.2.2: That's a seriously funky construction of English.

4.3: Aside from the adorable use of "MUST NOT REQUIRE" (which should probably be defined in section 2), I agree with Robert that the meaning sentence is a bit obscure.

I don't think adding additional load to the meanings of the 2119 terms helped with the precision
or conciseness of the text in this document. For future efforts, please consider using prose
where you need it instead. There are two places where I had to either read multiple times, or just 
guess at the intended meaning. Please try to find a way to clarify them.

1) In section 4.1, when you say MUST NOT be OPTIONAL, it took awhile to convince myself that this
was only trying to say the schema must have this as a mandatory element. If it meant more than that,
I didn't take that away. 

2) In section 4.3, does the first sentence mean "A schema must make keys an optional element"?
Is it ok for the schema to not represent keys at all? Is it OK for the interface to not represent keys
even if the schema does? (I realize that's not what reasonable interfaces would do, but the way the 
requirements language here is constructed, the sentence as written could be read to say that's ok.)