Thank you for your comments. I have responded per below and hope to have a new
version available today.
Regards,
Ken Vaughn
Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> ** Section 6. Per the new IANA registry:
>
> -- Is the WG sure that expert review for the entire registry is sufficient?
> I’ll point out that the “TLS HashAlgorithm” from which it forked defines
> ranges
> for code points (to include standards track … expert review).
The WG did discuss this point a reasonable amount and this was the agreed
position. I am hesitant to change it.
> -- I applaud the design of this registry incorporating the notion of
> “Recommended”. Based on the TLS experience of using that flag, specifically
> Section 5 of RFC8447, does stronger guidance need to be added on the threshold
> for getting a “Y” and the semantics of “N”. In RFC8847, “Recommended=Y”
> requires a standards track; and “Recommended=N” allows for the possibility
> that
> the proposed algorithm is not “flawed”, simply that it hasn’t been reviewed by
> the IETF.
It does seem reasonable to align the meaning of our column with the already
established attribute defined by RFC 8447 to minimize any potential confusion.
As such I have added the following 2 paragraphs to Section 2-1 that mimics
section 5 of RFC8447, as follows:
A "Y" in the "Recommended" column indicates that the registered value
has been recommended through a formal Standards Action. Not all parameters
defined in Standards Track documents are necessarily marked as
"Recommended".
An "N" in the "Recommended" column does not
necessarily mean that it is flawed; rather, it indicates that the
item either has not been through the IETF consensus process, has
limited applicability, or is intended only for specific use cases.
I have also revised Section 6 to read:
The "recommended" column indicates "Y" for hashing
algorithms that are standards track and are deemed to be
acceptable for current use and "N" for hashing algorithms that
reflect meanings that are not recommended (e.g., they do not
provide sufficient security for modern systems, they are not
standards track, they have limited applicability) _______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
