[ntpwg] [Fwd: DISCUSS: draft-ietf-ntp-autokey]

[Brian Haberman]

Dave,
      Your version 7 of the autokey spec has been rendered in IETF draft 
format and is available at:

http://www.cs.jhu.edu/~bkhabs/draft-ietf-ntp-autokey-06.txt

The corresponding XML (with slight modifications) is also available

http://www.cs.jhu.edu/~bkhabs/draft-ietf-ntp-autokey-06.xml

Regards,
Brian

David Mills wrote:
> Danny & Co.,
> 
> I've receoved comments from four reviewers and responded to the first 
> three and about to respond to the fourth. I've provided two marked up 
> drafts, the latest of which is on the NTP project page in XML. However, 
> I can't produce the text version due to an unavailable ID that must be 
> somewhere else, as it is here.
> 
> Dave
> 
> Danny Mayer wrote:
> 
>> Brian,
>>
>> When you say that the following issues are still unresolved, do you just
>> mean that the document still needs to be updated or do you mean that
>> there is further discussion needed, or something else?
>>
>> Danny
>>
>> Brian Haberman wrote:
>>
>>> -------- Original Message --------
>>> Subject: DISCUSS: draft-ietf-ntp-autokey
>>> Date: Mon, 15 Jun 2009 13:51:15 -0700 (PDT)
>>> From: Russ Housley <housley at vigilsec.com>
>>> To: iesg at ietf.org
>>> CC: jmh at joelhalpern.com,ntp-chairs at tools.ietf.org, 
>>> draft-ietf-ntp-autokey at tools.ietf.org
>>>
>>> Discuss:
>>>
>>>   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.
>>>
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwg at lists.ntp.org
>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>>
>>>
>>>
>>
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg