Subject: Re: [Ietf-krb-wg] Fwd: New Version Notification for draft-ietf-krb-wg-kdc-model-08

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 13 Aug 2010 18:43:53 -0400

--On Tuesday, May 18, 2010 04:09:02 PM +0200 Leif Johansson <[email-masked]> 
wrote:

> This post-WGLC version of the kerberos information model spec includes
> the WGLC comments from Greg Hudson. Feel free to start the publication
> process at any time.

I did a review of this document, and had a few comments.  The three marked 
with '*' are blocking; that is, they need to be resolved before the 
document can move forward.  Of course, I'd appreciate a response on the 
others as well.

* Abstract: expand "KDC" on first use.
- Merge sections 1 and 3?

- Section 2: "KDC" is "Key Distribution Center", not "... Service"

- MUST is for implementors (in this case, schemas), not readers.
  So, "use of these particular words MUST not be taken to imply..."
  (section 2) is not really an appropriate use of requirements
  language.  Similarly, it's not really right to say a document
  SHOULD be published as an RFC (section 2) or MUST include such and
  such a normative reference (section 5).

- Move acknowledgements to the end?

- Section 6: Since the particulars of what objects and attributes
  should be included in the model has been discussed to death, I'll
  not comment further.

* Section 6.3.1.1 (keyEncryptionType): There is an IANA registry for
  enctypes; names should be drawn from the registry, not from RFC3961.
  This is especially important since RFC3961 and RFC4120 are quite
  bad about not using consistent names for enctypes.

- Section 6.3.1.7 (keyNotUsedBefore): This attribute appears twice!

- Section 6.4.1.1 (policyIdentifier): I'm confused.  Does this
  attribute name a specific policy, such as "passwords must be at
  least 8 characters long", or a class of policy such as password
  quality policies?  Does each different password quality policy in
  a KDB have a distinct policyIdentifier, or do they all use the
  same identifier?

- Section 7.1: a variation on this is to use LDAP to back everything
  _except_ the keys, which are stored in some private KDC database

* Section 9: OIDs are a heirarchical namespace; values and sub-arcs
  within any given OID arc are allocated by that arc's owner.  IANA
  doesn't "allocate OIDs" in the general sense, and a "TBD" with no
  further information is not sufficient guidance to IANA.  In this
  particular case, the right thing is probably to allocate a new arc,
  1.3.6.1.5.2.5 (iso.org.dod.internet.security.kerberosV5.policies),
  and assign each policy a number under that arc.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 13 Aug 2010 19:05:26 -0400

--On Friday, August 13, 2010 06:43:53 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> --On Tuesday, May 18, 2010 04:09:02 PM +0200 Leif Johansson
> <[email-masked]> wrote:
>
> I did a review of this document, and had a few comments.  The three
> marked with '*' are blocking; that is, they need to be resolved before
> the document can move forward.  Of course, I'd appreciate a response on
> the others as well.

In addition, id-nits found these:

  == You're using the IETF Trust Provisions' Section 6.b License Notice from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the 
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.) -- however,
     there's a paragraph with a matching beginning. Boilerplate error?

-- Jeff