Subject: Re: [Gen-art] draft-ietf-ntp-autokey-06.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 18 Aug 2009 21:04:53 -0400

Russ - would you be willing to clear your DISCUSS and capture Joel's  
new issues in a COMMENT?

- Ralph

On Jul 27, 2009, at 4:56 AM 7/27/09, Joel M. Halpern wrote:

> This document is nearly ready for publication as an Informational RFC.
>
> While my comments have been resolved, some minor issues
> apparently crept in during the editing process..  These are small  
> enough that they can probably be dealt with in notes to the RFC  
> Editor if no other issues are found.  However, they are sufficiently  
> ambiguous that they should not be left for rediscovery by the RFC  
> Editor.
>
>
> Two individual sentences became truncated (Section 7, first  
> paragraph "was created." => "was." and section 8, third bullet "the  
> server."=>"the.")
>
> Section 8 on the Sign exchange previously said that the information  
> was signed using the private key.  Now it says that it is signed  
> using the public key.  As I understand it, the signature is  
> generated with the private key to be verified with the public key.   
> I am not sure what the right words in the paragraph would be.  (I   
> was happy with "private key" before since the signer used his own  
> private key.)
>
> In the paragraph on the extension field parser length calculation,  
> with the text beginning:
> "If greater than 22 an extension field is present.  If the length  
> is .."
> has two minor issues.  I believe it would be clearer if it said
> "If the remaining length is greater than 22 an extension field is  
> present.  If the remaining length is ..."
>
> Yours,
> Joel M. Halpern
>
> Russ Housley wrote:
>> Joel:
>> Please take a look at the updated document....
>> *Discuss (2009-06-15)
>> *
>>  The Gen-ART Review by Joel Halpern on 5-June-2009 has
>> lead to some
>>  discussion with the authors.  Not all of the issues have
>> been
>>  resolved, but it is clear that some changes to the document are
>>  needed.  The following issues are still unresolved.
>>  The usage within Autokey of the extension field need description
>> early
>>  in the document.  Paragraph 3 of Section 10 reserves seven
>> values (1-7)
>>  Autokey. The "Field Type" field performs two roles:
>> identification as
>>  an Autokey extension and defining the type within Autokey.
>>  Section 11.1 includes a 16 bit Digest / Signature NID.  There
>> is no
>>  description of how this is used.
>>  The wording on hierarchy in section 5, paragraph 3 is the opposite
>> of
>>  what is shown in the figure.  (The figure matches
>> expectations, where
>>  a client of one group operates as the TH of a group operating at
>> a
>>  lower stratum.)
>>  In Section 10, the paragraph that begins "[T]he extension
>> field parser   initializes a pointer..." is incorrect.  The
>> "length" by which the
>>  pointer is increment is the length in the extension header, not
>> the
>>  length computed by subtracting the NTP header from the packet
>> length.
>>  In figure 5, it would help the reader if the groups and hosts had
>>  different names.  (Even just calling the groups Alice-Group
>> and
>>  Carol-Group would help.)
>>  In section 5, in the description of "[t]he steps in hiking
>> the   certificate trails...", in step 1, in the second sentence,
>> please add
>>  language to make it clear that the server is "exchanging host
>> names
>>  and negotiating..." with is the server from whom it is
>> getting
>>  information.
>>  Section 8 should be moved earlier in the document.  Early
>> parts of the
>>  document assume an understanding of properties of the system
>> which
>>  have not been described yet.
>>  Section 11.6 (Security Considerations) is supposed to be a
>> top-level
>>  section.
>>> X-Original-To: [email-masked]
>>> Delivered-To: [email-masked]
>>> X-Virus-Scanned: amavisd-new at smetech.net
>>> X-Spam-Flag: NO
>>> X-Spam-Score: -6.599
>>> X-Spam-Level:
>>> X-Spam-Status: No, score=-6.599 required=3.5 tests=[BAYES_00=-2.599,
>>>         RCVD_IN_DNSWL_MED=-4]
>>> From: [email-masked]
>>> To: [email-masked], draft-ietf-ntp- 
>>> [email-masked],[email-masked],[email-masked],[email-masked] 
>>> ,[email-masked],[email-masked]
>>> Subject: New Version Notification - draft-ietf-ntp-autokey-06.txt
>>> Date: Wed,  8 Jul 2009 05:00:02 -0700 (PDT)
>>>
>>> New version (-06) has been submitted for draft-ietf-ntp- 
>>> autokey-06.txt. http://www.ietf.org/internet-drafts/draft-ietf-ntp-autokey-06.txt
>>> Sub state has been changed to AD Follow up from New Id Needed
>>>
>>> Diff from previous version:
>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-ntp-autokey-06
>>>
>>> IETF Secretariat.

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Aug 2009 16:58:09 -0400

>>paragraph "was created." => "was." and section 8, third bullet "the

Can you post an RFC Editor note this one?  We have experience that 
shows RFC Editor notes are read, but comments are almost always ignored.

>>was happy with "private key" before since the signer used his own

Again, I'd like to see an RFC Editor note for this one?

>>present.  If the remaining length is ..."

I'm fine with a comment for this one.

Russ

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Aug 2009 07:39:13 -0400

Russ - I've added the RFC Editor comments.  I expect we'll need  
another rev before publication, which should incorporate those comments.

- Ralph

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Aug 2009 17:18:38 -0400

I cleared.