Thank you Jari, Comments inline. Regards, Gustavo On 2/18/16, 00:18, "Jari Arkko" <jari.arkko@xxxxxxxxx> wrote: >Many thanks for your reviews, Russ. > >I have looked at the document as well, looked up the reference, and agree >with Russ’ comment that there is something missing. I would have wanted >to talk about this issue wrt this document on tonight’s IESG telechat, >but Stephen Farrell has already raised this point. I am interested in the >matter being resolved, however. Gustavo - I replied to Stephen¹s comment, reply here: https://mailarchive.ietf.org/arch/msg/eppext/cNizylFVKdWXu20OKKlq5gIA1KM > >Also, Gustavo, did you get a chance to look at Russ’ editorial comments? >Those seem worthwhile to be addressed as well. Gustavo - Yes, I uploaded version 05 of the I-D that includes Russ’ editorial comments. Version 05 is here: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-05 > >Thanks, > >Jari > >On 12 Feb 2016, at 18:57, Russ Housley <housley@xxxxxxxxxxxx> wrote: > >> 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 wait for direction from your >> document shepherd or AD before posting a new version of the draft. >> >> For more information, please see the FAQ at >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Document: draft-ietf-eppext-tmch-smd-04 >> Reviewer: Russ Housley >> Review Date: 2016-02-12 >> IETF LC End Date: 2015-12-04 >> IESG Telechat date: 2016-02-18 >> >> Summary: Not Ready >> >> >> Major Concerns: >> >> >> The Security Considerations include this paragraph: >> >> Signed Marks are used primarily for sunrise domain name registrations >> in gTLDs, but other third-parties might be using them. A party using >> Signed Marks should verify that the digital signature is valid based >> on local policy. In the case of gTLDs, the RPM Requirements document >> [ICANN-TMCH] defines such policy. >> >> The RPM Requirements document [ICANN-TMCH] does not seem to say anything >> at all about validating a digital signature. >> >> Protocols that make use of certificates perform some checks on the >> certificate subject name to ensure that it represents an appropriate >> signer. That is missing from this document, and it is not contained in >> [ICANN-TMCH] either. >> >> >> Minor Concerns: >> >> Section 2, second paragraph, I think that use of the phrase "in the >> appropriate objects" ass ambiguity. I suggest: >> >> This section defines some elements as OPTIONAL. If an elements is >> not defined as OPTIONAL, then it MUST be included in the object. >> >> The NOTE at the end of Section 2.3 about choosing an algorithm other >> that RSA-SHA256 is better suited for the Security Considerations. >> It would be helpful to say something more about the needed security >> strength. >> >> Why is RFC5730 a normative reference? I do not see a dependency. >> >> >> Other Editorial Comments: >> >> Section 1: s/nothing precudle/nothing precludes/ >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/gen-art >
<<attachment: smime.p7s>>