Re: [Gen-art] Genart last call review of draft-ietf-lamps-rfc5750-bis-05

[Ines Robles <[e-mail]>]

Ok,

Thanks for the feedback.

Best,

Ines.

2018-05-03 3:01 GMT+03:00 Jim Schaad <[e-mail]>:

>
>
> > -----Original Message-----
> > From: Ines Robles <[e-mail]>
> > Sent: Friday, April 27, 2018 4:28 AM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail];
> [e-mail]
> > 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.
> >
>
>
>