On 17/12/20 02:19, Christian Huitema wrote:
[....]
Again, you are providing a great example of why the IETF should not
publish this draft. It is using an abstract generalization of
"identifiers" to draw broad recommendations that are at odds with actual
protocol development practice. Endorsing these recommendation in a BCP
or even an informational RFC will be harmful, because it will cause
unnecessary discussions, just like the one we are having here.
In the same line of reasoning, you might as well propose that RFC3552
("Guidelines for Writing RFC Text on Security Considerations") be
obsoleted, because it also takes time to write "Security Considerations".
And I guess one could also ask for document reviews (including IESG
reviews) to be eliminated, since at times they can "cause unnecessary
discussions".
Otherwise, I wonder what's harmful about this:
1. Clearly specify the interoperability requirements for the
aforementioned identifiers (e.g., required properties such as
uniqueness, along with the failure severity if such properties
are not met).
i.e., specify the interoperability requirements of your identifiers.
2. Provide a security and privacy analysis of the aforementioned
identifiers.
i.e., do the associate security and privacy assessment.
3. Recommend an algorithm for generating the aforementioned
identifiers that mitigates security and privacy issues, such as
those discussed in [I-D.irtf-pearg-numeric-ids-generation].
i.e., suggest an algorithm that can generate your IDs while mitigating
the possible issues (if any) that you found in step #2 above.
Is the above text what all this controversy is about?
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
