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:
Nits/editorial comments: None
BehcetReviewer: 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
Minor issues:
None
Nits/editorial comments: None
On Tue, Nov 29, 2022 at 10:23 AM Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx> wrote:
On 11/29/22 10:58, Behcet Sarikaya wrote:
On Mon, Nov 28, 2022 at 4:37 PM Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx> 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 Aplease 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.
BehcetSo 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: rgm@xxxxxxxxxxxxxxxxxxxx
There's no limit to what can be accomplished if it doesn't matter who gets the credit
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
