Ok, Thanks for the feedback.
Best, Ines. 2018-05-03 3:01 GMT+03:00 Jim Schaad <i...@augustcellars.com>: > > > > -----Original Message----- > > From: Ines Robles <mariainesrob...@googlemail.com> > > Sent: Friday, April 27, 2018 4:28 AM > > To: gen-art@ietf.org > > Cc: sp...@ietf.org; draft-ietf-lamps-rfc5750-bis....@ietf.org; > i...@ietf.org > > Subject: Genart last call review of draft-ietf-lamps-rfc5750-bis-05 > > > > Reviewer: Ines Robles > > Review result: Ready with Issues > > > > Hello, > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review > > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > > the IETF Chair. Please treat these comments just like any other last > call > > comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-lamps-rfc5750-bis-05 > > Reviewer: Ines Robles > > Review Date: 27-04-2018 > > IETF LC End Date: 27-04-2018 > > IESG Telechat date: --- > > > > Summary: > > > > I believe the draft is technically good. This document is well written > and clear > > to understand. Some minor concerns are mentioned that should be resolved > > before publication. > > > > Major issues: No major issues found. > > > > Minor issues: > > > > Section 1.6: > > > > It would be nice to start the section with some text like "This > document > > obsoletes 5750 due to the addition of the following information...." > > This is missing information, however I think it should go into section 1 - > Introduction and not be buried here. The new text does point to this > section. > > > > > Section 2.3: > > > > "but SHOULD use some other mechanism to determine ...." => It would > be > > nice > > to mention some examples of the other mechanism > > > > "...but SHOULD use some other mechanism (such as ....) to > determine..." > > I am not sure that this would be a useful addition. I can see two > different outcomes from this which neither of which is helpful. > > * People will complain about implementations which do not implement all > of the items in the list > * People will complain that something should not be implemented because > it is not on the list > > One of the problems is that this will be a list that is not very useful. > Items can range anywhere from use the set of trust points you already have > and don't let it be expanded to call the other person up and get them to > read you a hash value to look at various trusted locations for root > certificates, including some types of transparency logs. I cannot really > say that any of these is what I would recommend. The knowledge of how > trust configuration is handed is an extremely application and > implementation specific function. > > > > > Section 4: > > > > Related to this: > > "Another method under consideration by the IETF is to provide > certificate > > retrieval services as part of the existing Domain Name System (DNS)" > > > > - This text seems to be out of the date (since belongs as well to > RFC5750 > > (2010)), maybe it would be nice to re-write it (e.g. method under > > consideration => method approved) and add a reference of the proposed > > methods. Would it be RFC 8162 [1] a good reference for this topic? > > > > [1] https://tools.ietf.org/html/rfc8162: Using Secure DNS to Associate > > Certificates with Domain Names for S/MIME > > This was raised during the rfc5751-bis review as well. I have replaced > that sentence with a pointer to the experimental DANE draft. > > > > > Nits/editorial comments: > > > > Section 2.3: CertificateSet --> Certificate Set > > > > Section 4.4.1: basicConstraints --> basic Constraints > > > > Thanks for this document! > > > > Ines. > > > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
