Joe,
I think we have gone through this before. Folks (including you) raise
objections. I note that the claim has no basis or ask a question which
clearly shows the objection has no basis, and they omit the question,
stop responding, or switch to something else.
First it was the algorithms this document was requiring -- but it
doesn't require any.
Now the problem is the title.
I have already started to write down the objections each folk has
raised, the questions me, Ivan or the Security AD asked, and how they
were not responded to.
At the end of the day it's up to the AD to judge if valid concerns have
been raised, or whther folks are simply trying to thwart this effort.
For folks that want a longer explanation, please refer to Theo de
Raadt's post:
https://mailarchive.ietf.org/arch/msg/last-call/4h6S6Ymw9knoJFKGVQe0bM4JMwE/
Constructive comments -- of which I've seen virtually none -- are
welcome, as always.
Thanks,
Fernando
On 17/12/20 23:35, Joseph Touch wrote:
On Dec 17, 2020, at 5:58 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx
<mailto:fgont@xxxxxxxxxxxxxxx>> wrote:
What we mean is:
#1: Spell out the interop req. i.e., tell us the properties that the
IDs must have. -- we want to know the minium requirements the IDs need
to comply to.
#2: Analyze the possible implications of such IDs.
#3: If you found any possible issues in #2, just suggest something to
the implementer that complies with #1 and deals gracefully with #2.
That would be the topic of a document on “Specifying the
interoperability requirements of generated IDs in protocols”.
That is not the title of this document; the difference between the two
is where we disagree.
Joe
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
