On 6/27/21 7:02 PM, Paul Wouters wrote:
On Sun, 27 Jun 2021, Dan Harkins wrote:
Thanks for facilitating this discussion (especially given the
editor's issues with
interacting with me).
I don't want to keep focussing on this, but again I need to
defense myself. I have no issues with interacting with you on public
mailing lists. I have a personal opinion that your behaviour has been
inappropriate enough towards me and other groups of people that I wish
no longer interact with you via non-public emails.
Yet all these problematic non-public email interactions seem to have been
initiated by you! (I have the receipts).
I believe that is within my rights.
If only you would give that accommodation ("my rights") to me.
But whatever, it's not really an IPsecme issue.
This does not interfere with me responding to on topic
discussion where I am acting in an official IETF capacity, such as
Document Author or Working Group Chair.
Or document *editor*, as is the case here.
Yes, the unaddressed points are in the 3rd email. Everything
above the "there is another IKEv1 feature not available in IKEv2"
line are my
unresolved comments, everything below that is further discussed in
the final 2 emails
and is not relevant to the comments I made on the draft.
Basically, I want to get rid of the speculative language and the
guesswork language
which is not really even necessary to make the case. I also provided
2 reworded
paragraphs which I think improve the draft and are more clear. Of
course, that's my
opinion, it's open to debate and disagreement, but if others agree
with me then I
think these changes should be adopted by the editor.
At the time, I was waiting for more comments before updating the
document. I have now pushed these changes. I've taken in some text of
Dan,
although I did not remove everything he suggested removing because I deem
those bits have value to bring across. If other people wish to chime in,
that would be useful to determine consensus.
I still think there is a problem in providing speculative text about
some vendors
and their potentially "unmaintained code". Unless you're prepared to
state which
vendors are not maintaining their code to the detriment of their
customers I don't
think you should allude to such a situation. And I really don't think an
RFC is the
appropriate vehicle to describe such vendor behavior even if you were gonna
describe it.
The draft does not need to engage in such speculation. There are
plenty of other
concrete, definitive reasons to send IKEv1 to historic. This
coulda/shoulda/woulda
stuff is not necessary and actually detracts from the draft.
The changes to the document are minor, so I think this can be
evaluated as
part of this WGLC, but the final decision on that rests with the chairs.
Actually it rests with the group. This is a document of the working
group.
Dan.
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-01
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
