On Mon, 8 Mar 2021, Dan Harkins wrote:
Oh for gaia's sake....
Recipient address: p...@nohats.ca
Reason: Remote SMTP server has rejected address
Diagnostic code: smtp;550 5.7.1 <dhark...@lounge.org>: Sender address
rejected: Exercising my freedom to not hear you scream
I had put that in after a rather unpleasant email exchange and forgot
about it. I've removed it now.
I kind of ran through my comments pretty quickly so let me repeat
them here so they don't get lost:
- like the TLS 1.0 to historic, I think this draft should be BCP
Ben said this might not be the best example and was an excepion in the
process? I'm also not sure if a BCP can have IANA Considerations ?
- make the title ikev1-to-historic, get rid of cutesy name
That is really only in the draft name, not the title. The title is:
Deprecation of IKEv1 and obsoleted algorithms
I'm fine changing the draft name to draft-ipsecme-ikev1-algo-to-historic
and the title to "Moving IKEv1 and obsoleted algorithms to Historic"
- remove all the subjective opinion in section 3-- all the "high
chance" or "most likely" or "quite often" etc-- and just mention
that anything IKEv1 can do IKEv2 can do better, and that the
reasons to do IKEv1 in the past-- PQ and labeled IPsec-- are
no longer legit due to the advancement of the relevant drafts
It would be nice to keep some of the justifications in there. I can
look at rephrasing it a bit.
- I don't think deprecating the registries is necessary if the
RFC goes to historic, as you note, there's been no work on IKEv1
for over a decade so leaving the registries alone will not be
some backdoor way of sneaking in IKEv1 changes. Other orgs are
using the repository so just deprecating is not right.
I thought it would just be a stronger signal to implementers, but if
there are practical concerns, like people still shoehorning things in
there then it can be removed from this document. As Tero said, those
registries cannot really be populated with new stuff without involving
the WG, so we can just count on our regular IKEv1 change pushbacks.
- If you're gonna reject any DH groups then reject the weak ones,
it doesn't make sense to do 1 and 22 and leave 2 and 5 (and 23
and 24!) alone.
DH updates should be done in RFC 8247bis. This document only obsoleted
the algorithms that either had no specifiction to begin with, or have
been stuck in MAY because no one cares about them.
It didn't look like there was any opposition to adopting this so
just consider these as comments on the draft as adopted.
Will do, thanks!
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
