Subject: Krb-wg Fianl WG Last Call on Clarifications, Kcrypto and AES

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 20 Jun 2003 15:27:17 -0500

After three years we are finally ready for the Final Working Group Last 
call for the three main documents of the krb-wg: 

 The Kerberos Network Authentication Service (V5)
 http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-clarifications-04.txt

 Encryption and Checksum Specifications for Kerberos 5
 http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-crypto-05.txt

 AES Encryption for Kerberos 5
 http://www.ietf.org/internet-drafts/draft-raeburn-krb-rijndael-krb-05.txt
 (Ken is submitting the final changes to the editors as I write this note.
  You should see draft -05 from the RFC editors early next week.)  

All of these documents have been through WG last call before and the comments
from each have been included in these drafts. So I DO NOT EXPECT ANY CHANGES!
This final WG last call is to make sure the comments have been addressed, and 
to catch  any glaring errors.  
 
If you do see a problem: 

  o Report it, quoting the text in error, 

  o Provide your version of the replacement text. 

  o Report each problem in a separate e-mail using the following title:
    "LAST CALL COMMENT {CLARIFICATIONS|KCRYPTO|AES} Section n.n.n ...." 

  o Keep the report short.

I don't want any long winded replies with hand waving. You must be specific
in the problem report and it BETTER BE A SHOW STOPPER. I expect the authors
to respond, and I expect they will defend the current text. 

I don't want to see any "I don't know if its to late, but ..." comments,
as it is to late! Save these for the Extensions draft. 

If you don't follow these rules, I will ask you to submit your comments again
following these rules. 

If you don't use the title above, its not a LAST CALL Comment. 

As I said above, the AES -05 is being submitted. It is about 11 pages long. 
Clarifications is 133 pages and Kcrypto is 49, so you have plenty of reading 
to do before getting to the AES draft. 

You have until July 4 till the Last Call ends. 

I will be on vacation next week, reading these drafts, so I might not respond.

I want to thank everyone on the WG for all their hard work, I feel we are about
to make a major step forward when we get these documents past this final WG 
last call.

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Jun 2003 16:34:52 -0400

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> After three years we are finally ready for the Final
    Douglas> Working Group Last call for the three main documents of
    Douglas> the krb-wg:

Wait, we already had last calls on these documents.  If you have a
small number of changes in a document after last call you don't need
another last call.

I can understand specifically asking if the changes have been
addressed and giving people a week to object if they have not.  But it
seems like it will at best delay things to pen things up for another
last call.

Of course it's your option as a chair, but why do we want to slow
things down now?

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 20 Jun 2003 18:52:22 -0400

Minor editorial nits on clarifications-04:

    Section 3.3.1 paragraph 5 starts with "(This paragraph changed)".
    Jacques Vidrine suggested fixing this in November.

    In section 6.2, the table header (column labels) is at the bottom
    of one page, and the table body -- with another header, labelling
    only one of the columns -- is on the next page.  It looks poor.  A
    ".ne 5" or some such would force a page break if the specified
    number of lines aren't available on the current page.

draft-rfc-editor-rfc2223bis-05 says the Abstract should be 5-10 lines
typically and definitely under 20 (we're at 15), and should contain no
citations not fully defined within the Abstract.  It also has various
suggestions for section order that we don't follow (unnumbered
abstract and TOC, then body of memo including appendices and then
references, then unnumbered authors address and copyright statement).

Both id-nits and rfc2223bis say that lines are not supposed to be
longer than 72 characters.  We exceed this in sections 5.2.7.5, 5.2.8,
5.3, 5.4.1, 5.5.1, 6.2, 7.5.1, 7.5.2, 7.5.4, 7.5.7, 7.5.8, 7.5.9, and
appendix A.  In some parts of section 7, we exceed 80 characters.
Mostly it's in ASN.1 code and tables, both of which could be adjusted.

It's too late to do anything about it now, I'm sure, but I don't think
we really need the Abstract *and* Overview *and* Background *and*
Introduction, do we?  Even if we do, the Overview and Background
should probably be after the TOC (two and a half pages of material
before the TOC is a bit much), and perhaps folded into the
Introduction section.

Some recent online discussion caused me to notice that error code 68,
KDC_ERR_WRONG_REALM, is described as "USER-TO-USER TGT issued
different KDC".  What in the world does that mean?  It's not mentioned
anywhere else in the document that I could find.  And I believe it
came up because it was returned by some KDC (MS AD?) in a non-U2U
situation.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 20 Jun 2003 19:22:17 -0400

Since I'm complaining about problems in the tables, the vertical
alignment in bitfield tables is poor, too.  The table describing
ticket flags in section 5.3 has the name and number for each bitfield
aligned vertically with the *center* of the description, and that
description is sometimes two paragraphs, the second paragraph being
"this is new since 1510".  Yes, I know which field it belongs with,
but it's not obvious visually.

In HTML, with nice little boxes around each entry in the table, it was
okay; it was unambiguous.  As text, with no clear boundaries between
"lines" of the table, it's not.  In plain text form, the fields should
probably be aligned at their tops.

         123     may-tweak        Blah blah eaotnehu ao uetnaoeh's,
                                  tn.uheaou oeaunaot oeuth u
                                  u',.thkku ku', atnhk u ok euo k k
                                  euo u',4 unthcg htn rcgrc .uh
                                  84aoetnu tihh.

                                  oh, and by the way, ntaoeh otauh
                                  hxk hu, theui rfc 1510.

Likewise for the kdc-options and ap-options.

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Sun, 22 Jun 2003 22:41:32 -0500

Your message did not follow the instructions as specified in the WG last
call note:

--

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 23 Jun 2003 01:00:30 -0400

> Your message did not follow the instructions as specified in the WG last

Sorry, I hadn't read it very carefully.  I'll resubmit the important
ones.

Ken