Subject: [Ietf-krb-wg] preliminary review of draft-ietf-krb-wg-preauth-framework-14.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 30 Aug 2009 15:25:03 -0400

I'm in the process of doing my review and writeup of the preauth framework 
document.  My practice is generally to do a basic review for process issues 
and to prepare the bulk of the writeup, then read the document in detail to 
identify any additional issues related to the protocol or document content. 
What follows is a list of process-related issues I found during the first 
part of this review.  All of these require some kind of response before the 
document can proceed, though some may not require any changes.

I will be proceeding with the remainder of my review without first waiting 
for responses to these.  Look for comments from that review soon.

-- Jeff

ID-nits points out that this is an old document but does not contain a 
disclaimer for pre-RFC5378 content.  I know the authors are painfully aware 
of this issue, so I don't think I need to explain it.  Please be sure that 
such a disclaimer is included if it is needed.

The reference to draft-ietf-krb-wg-kerberos-referrals looks like it should 
be normative, as it is needed to understand and implement the specification 
of the kdc-follow-referrals option in section 6.5.2.

References to draft-ietf-krb-wg-anon, draft-ietf-krb-wg-kerberos-referrals, 
and draft-sakane-krb-cross-problem-statement are out of date and should be 
updated.

The descriptions of IANA registration policies in section 8 require a 
normative reference to RFC2434.

Has Tom verified that the pata registry contents in section 8.1 are 
consistent with his current records?  It's doubly important to get this 
right since we are turning this registry over to IANA.

This document contains a lot of RFC2119 requirements language, and also 
many uses of the lowercase words "may", "should", and "required" which are 
not intended as requirements language.  I did a cursory review and believe 
these are mostly in order, but it's probably worth rechecking to make sure 
you haven't left any in lowercase that should be uppercase or vice versa.

I need someone (preferably more than one someone) to verify that the ASN.1 
module in Appendix C actually compiles.

I'm pretty sure Joel Weber's name is spelled with only one 'b'.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 31 Aug 2009 10:48:56 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> ID-nits points out that this is an old document but does
    Jeffrey> not contain a disclaimer for pre-RFC5378 content.  I know
    Jeffrey> the authors are painfully aware of this issue, so I don't
    Jeffrey> think I need to explain it.  Please be sure that such a
    Jeffrey> disclaimer is included if it is needed.

All is in order here.

    Jeffrey> The reference to draft-ietf-krb-wg-kerberos-referrals
    Jeffrey> looks like it should be normative, as it is needed to
    Jeffrey> understand and implement the specification of the
    Jeffrey> kdc-follow-referrals option in section 6.5.2.

My intent from the current text and reading of WG discussion is that
we want to allocate the flag bit here, but normatively describe the
behavior in the referrals draft so as not to delay this draft.

Is that consistent with what we're trying to do?
If so, do you think text clarification is needed?

    Jeffrey> References to draft-ietf-krb-wg-anon,
    Jeffrey> draft-ietf-krb-wg-kerberos-referrals, and
    Jeffrey> draft-sakane-krb-cross-problem-statement are out of date
    Jeffrey> and should be updated.

Will do that, although honestly, I think the RFC editer is great at
this sort of thing.

    Jeffrey> The descriptions of IANA registration policies in section
    Jeffrey> 8 require a normative reference to RFC2434.
I thought we replaced 2434.
Anyway, I'll add a normative reference to whatever is appropriate.

    Jeffrey> This document contains a lot of RFC2119 requirements
    Jeffrey> language, and also many uses of the lowercase words
    Jeffrey> "may", "should", and "required" which are not intended as
    Jeffrey> requirements language.  I did a cursory review and
    Jeffrey> believe these are mostly in order, but it's probably
    Jeffrey> worth rechecking to make sure you haven't left any in
    Jeffrey> lowercase that should be uppercase or vice versa.
I think we're good here.  More eyes can of course always help.

    Jeffrey> I'm pretty sure Joel Weber's name is spelled with only
    Jeffrey> one 'b'.  _______________________________________________

Will fix.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 31 Aug 2009 10:56:02 -0400

> If so, do you think text clarification is needed?

I think that's a fine thing to want to do.  But if the reference isn't 
normative and referrals isn't done, doesn't the reference just go away on 
publication?  If that happens, the description won't make much sense.

I don't know how to make the right thing happen without waiting for 
referrals.  Perhaps you do.  I agree that we don't want to wait.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 31 Aug 2009 12:25:54 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> --On Monday, August 31, 2009 10:48:56 AM -0400 Sam
    Jeffrey> Hartman

    >> 
    >> My intent from the current text and reading of WG discussion is
    >> that we want to allocate the flag bit here, but normatively
    >> describe the behavior in the referrals draft so as not to delay
    >> this draft.
    >> 
    >> Is that consistent with what we're trying to do?  If so, do you
    >> think text clarification is needed?

    Jeffrey> I think that's a fine thing to want to do.  But if the
    Jeffrey> reference isn't normative and referrals isn't done,
    Jeffrey> doesn't the reference just go away on publication?  If
    Jeffrey> that happens, the description won't make much sense.

No.  It remains as a reference to a work in progress.

If referrals didn't happen and we we were later cleaning up the FAST
IANA registry, we might want to replace it with a reserved flag.

The thing we need to do is make it clear that we are just allocating a
flag here, so that the IESG doesn't hold a discuss claiming that we
have normative text in this version of the spec.

Another alternative is to remove entirely and move the IANA
registration of the option bit over to referrals.  I'd prefer not to
do that though.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg