Hi all, I am satisfied with the responses by the author to my review completely. So I change my review
Document:draft-moskowitz-ipsecme-ipseckey-eddsa-06 Reviewer: Behcet Sarikaya Review Date: 2022-11-28 IETF LC End Date:2022-12-12 IESG Telechat date: (if known) Summary: Ready to go. Major issues: None Minor issues: None Nits/editorial comments: None Behcet On Tue, Nov 29, 2022 at 10:23 AM Robert Moskowitz <r...@labs.htt-consult.com> wrote: > > > On 11/29/22 10:58, Behcet Sarikaya wrote: > > > > On Mon, Nov 28, 2022 at 4:37 PM Robert Moskowitz <r...@labs.htt-consult.com> > wrote: > >> >> >> On 11/28/22 12:41, Behcet Sarikaya 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 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-moskowitz-ipsecme-ipseckey-eddsa-06 >> Reviewer: Behcet Sarikaya >> Review Date: 2022-11-28 >> IETF LC End Date:2022-12-12 >> IESG Telechat date: (if known) >> >> Summary: Ready with nits. It will be nice to explain why these IANA >> Registry additions for EdDSA Public Keys to the IPSECKEY not done with >> RFC 8080 which defined it in Feb. 2017. >> >> >> 8080 is for DNSSEC. OK. But this is for other uses. Now those that use >> the IPSECKEY RR are ready to use EdDSA, so could of, would of, should of. >> It was not done, now it is. RFC numbers are relatively cheap. Explain >> what? That 8080 was only for DNSSEC RR and this is for IPSECKEY RR? Why? >> Leave it alone. >> > > I think this should be explained explicitly in the draft. > > > The draft explicitly says it is for the IPSECKEY RR. Whereas rfc8080 > explicitly says it is for the DNSSEC RR. > > 8080 was done by those needing DNSSEC. > > This draft is for those needing the IPSECKEY RR. We are just using the > 8080 EdDSA format for not adding unnecessary encoding complications. > > > >> >> >> >> Major issues: >> None >> >> Minor issues: >> None >> >> Nits/editorial comments: >> Appendix A >> please add an IPv6 example. RFC 4025 does have some. >> >> >> Yes, 4025 defines all the gateway use cases, so has gateway RR examples >> with only ONE public key format. >> >> This draft is to add EdDSA as a public key format and gives the example >> of what that key looks like in the IPSECKEY RR. Any reader that wants the >> gateway use case will use 4025 for those examples. I do not see where >> cluttering up this document with use cases already covered in 4025 adds >> value/clarity. >> >> > I thought the example is for IPv4, so I asked to make it IPv6. The issue > is not "cluttering up the document". > > Please reply to this Bob. > > > The example is for "No Gateway" so it has no IP addresses. If an > implementer needs a gateway, look to 4025 for how to do that. This draft > adds nothing for the gateway functionality in the IPSECKEY RR so it has no > examples related to that. > > All this draft does is add the EdDSA key format and thus has an example of > what that looks like. > > > > Behcet > >> So I respectfully state that I prefer to leave all the gateway examples >> out of this document. >> >> Bob >> >> >> > -- > Robert Moskowitz > Owner > HTT Consulting > C: 248-219-2059 > F: 248-968-2824 > E: r...@labs.htt-consult.com > > There's no limit to what can be accomplished if it doesn't matter who gets > the credit >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
