Thanks for the reviews and updates, Dan et al. These reviews are important for me to understand which documents I need to look at closer, and in reducing my review load. Not to mention improving the quality of IETF RFCs :-)
Jari On 21 Jul 2014, at 18:11, Romascanu, Dan (Dan) <[email protected]> wrote: > Looks good. > > Thanks, > > Dan > > > From: Tal Mizrahi [mailto:[email protected]] > Sent: Monday, July 21, 2014 8:01 AM > To: Romascanu, Dan (Dan); [email protected]; Karen ODonoghue > ([email protected]); Yaakov Stein ([email protected]); Brian Haberman > ([email protected]) > Cc: [email protected] > Subject: RE: Gen-ART review for draft-ietf-tictoc-security-requirements > > Thanks Dan, > > The updated draft has been posted: > http://datatracker.ietf.org/doc/draft-ietf-tictoc-security-requirements/ > > Regards, > Tal. > > From: Romascanu, Dan (Dan) [mailto:[email protected]] > Sent: Sunday, July 20, 2014 4:51 PM > To: Tal Mizrahi; [email protected]; Karen ODonoghue ([email protected]); > Yaakov Stein ([email protected]); Brian Haberman ([email protected]) > Cc: [email protected] > Subject: RE: Gen-ART review for draft-ietf-tictoc-security-requirements > > Hi Tal, > > Thanks for addressing my comments. I can live with the two references being > Informational. > > Regards, > > Dan > > > From: Tal Mizrahi [mailto:[email protected]] > Sent: Sunday, July 20, 2014 10:03 AM > To: Romascanu, Dan (Dan); [email protected]; Karen ODonoghue > ([email protected]); Yaakov Stein ([email protected]); Brian Haberman > ([email protected]) > Cc: [email protected] > Subject: RE: Gen-ART review for draft-ietf-tictoc-security-requirements > > Hi Dan, > > Thanks for the comments. > I have updated the draft based on the comments below, and will post an > updated version tomorrow, once the I-D submission tool is reopened. > > One small comment: > > > It looks to me that the references for NTPv4 and IEEE1588 should be > > Normative – it does not make much sense to read this document without a > > fair understanding of these. > > We had a bit of discussion about this question recently. Normative references > specify documents that must be read to understand or implement the technology > in the new RFC. Brian and Karen observed that this document could be > understood even without reading NTPv4 or IEEE 1588; for example, a reader who > is interested in a completely new time protocol can benefit from this > document without having to read NTPv4 and IEEE 1588. Therefore these > documents are listed under the informative reference list. > > Thanks, > Tal. > > From: Romascanu, Dan (Dan) [mailto:[email protected]] > Sent: Monday, July 14, 2014 6:00 PM > To: [email protected] > Cc: [email protected] > Subject: Gen-ART review for draft-ietf-tictoc-security-requirements > > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may > receive. > > Document: > https://datatracker.ietf.org/doc/draft-ietf-tictoc-security-requirements/ > Reviewer: Dan Romascanu > Review Date: 7/14/14 > IETF LC End Date: 7/16/14 > IESG Telechat date: > > Summary: > > A well written, clear and useful document documenting the security threats > and the requirements on the deployment and activation of security protocols > and options in the context of the time protocols with focus on NTP and PTP. > Ready with a few non-blocking issues. > > Major issues: > > None > > Minor issues: > 1. I am wondering if section 5.4 ‘Availability’ says anything different > from what is already said in 5.1.3. which already talked about authentication > of slaves impact on availability > 2. Section 5.6.1 – ‘The cryptographic keys MUST be refreshed > frequently’ – some definition of or detail about ‘frequently’ is required to > make this requirement actionable > > Nits/editorial comments: > > 1. Title of section 5.1.2 is printed differently than other titles at > the same level of indent > 2. Section 5.2 – s/implemented/implemented > 3. Section 5.3 - s/tamper with slaves’ delay computation/tamer with > the slaves’ delay computation/ > 4. Section 5.6.2 – Security Association has different meaning in other > context. Is not this section really about Association Protocol? > 5. Why is Summary of Requirements a separate section (6)? > 6. It looks to me that the references for NTPv4 and IEEE1588 should be > Normative – it does not make much sense to read this document without a fair > understanding of these. > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
