Hello, Paul,
On 29/12/20 16:18, Paul Wouters wrote:
[....]
2. A set of requirements about what kind of analysis one has to do (S 5).
From my perspective, S 5 is mostly reasonable, though I don't really
think a special BCP is needed for them.
I agree. It is obvious to those who care and a really low bar that we
should be already meeting at the IETF in general at this point. For
example "2. Provide a security and privacy analysis of the aforementioned
identifiers." is already required for the Security Considerations and
checkd with SecDir reviews. The privacy parts are done somewhat less but
are not omitted either.
So I certainly agree that this is "a really low bar that we should be
already meeting at the IETF in general at this point", and probably also
that "It is obvious to those who care".
But then, may I ask:
1) How you explain the timelines in
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-history-04 ?
2) How do you explain that a preliminar inspection of the core QUIC spec
also fails in this regard? (e.g., connection-IDs)
3) What the "controversy" is all about?
Is it that nobody cares? Is it that the topic is not that obvious?
Anything else?
Section 5 bullet 3 points to another document. It is almost as if bullet
point 1 and 2 could be part of the introduction there.
Once you do these two things, this draft is basically scaffolding
without content.
Please do read the document.
Point #1 (from Section 5 of the I-D) is not "part of the Intro". Point
#1 is an actual *requirement*. Because it is this point that allows
reviewers to tell what's needed from the I-D. Without #1, you can't do #2.
And, indeed, many flaws have to do with protocol specs over-specifying
their transient numeric IDs. And the reader/reviewer somehow needs to
assume that there's a reason for which the spec specifies the IDs in the
way it does, instead of quickly realizing that the spec is
over-specifying its transient numeric IDs.
And item #3 *of course* points to another document! -- Because we don't
require you to pick any of the algorithms in
https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation --
You are free to come up with your own. We simply document algorithms
that have been employed to generate different types of transient numeric
identifiers, because it might well be the case that you need something
similar, and in that case, you don't need to rebuild the wheel. But you
are free to do it if you wish.
If you did read the document, then I wonder if some version of the above
prose would be of use bellow the numbered-list.... because clearly you
have misinterpreted both the requirements and their rationale/motivation
-- or we have not been clear enough in that regard.
It's puzzles me that you portray this document as doing lot of
handwaving. Because what's in this document is essentially the process
that I followed to improve e.g. IPv6 stable IIDs (RFC7217), TCP sequence
numbers (RFC6528), transport protocol ephemeral ports (RFC6056), IPv6
Frag IDs (RFC7739), and IPv6 temporary IIDs (rfc4941bis).
Thanks,
--
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
