[Lwip] Lars Eggert's Discuss on draft-ietf-lwig-curve-representations-21: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-lwig-curve-representations-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Even with the switch to Informational, I don't see how this document is in scope
for LWIG. The LWIG charter constrains the group to work on network and transport
layer protocols, and even contains a pretty specific list of protocols that are
in scope. An alternative representation for ECs - even if it has benefits for
embedded devices - is not what LWIG is chartered to produce.

Has the group negotiated going beyond their charter in this way with the
responsible AD? Is that documented somewhere? If not, I sincerely hope that LWIG
pays more attention to its charter going forward, to avoid running into late
process issues that cause upset and require special-case handling.

That said, we need to find a way to get this document published without much
further delay. This seems to be technically sound work with some clear benefits.
Publishing via the CFRG would be an option, but would cause some delay. I wonder
if AD-sponsoring it would avoid such delays. I don't want to set a precedent
that it's OK for WGs to violate their charter, and hence I wouldn't want us to
simply publish this via LWIG.

I also want to make it clear that this issue is not something that is due to the
authors, or something tat they can resolve. The WG chairs and the IESG need to
discuss how we got into this situation and how we can avoid similar issues in
the future.

The IANA review of this document seems to not have concluded yet; I am holding
a DISCUSS for IANA until it has.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Document has Informational status, but uses RFC2119 keywords.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "Master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server".

 * Term "his"; alternatives might be "they", "them", "their".

 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Q.3.1. ", paragraph 28, nit:
-    (r, s) if valid only if the ECDSA signature (r,-s) is, one can
-            ^
+    (r, s) is valid only if the ECDSA signature (r,-s) is, one can
+            ^

"Q.3.2. ", paragraph 28, nit:
-    (r, s) if valid only if the ECDSA signature (r,-s) is, one can
-            ^
+    (r, s) is valid only if the ECDSA signature (r,-s) is, one can
+            ^

"Q.3.3. ", paragraph 28, nit:
-    (r, s) if valid only if the ECDSA signature (r,-s) is, one can
-            ^
+    (r, s) is valid only if the ECDSA signature (r,-s) is, one can
+            ^

"I ", paragraph 1, nit:
>  is due to the authors, or something tat they can resolve. The WG chairs and
>                                      ^^^
In British English, the noun "tat" means tasteless or shoddy items. Did you
mean "that"?

Section 5.1. , paragraph 2, nit:
> e if only the Curve25519 curve would have been generated so as to be isomorph
>                                ^^^^^^^^^^^^^^^
Did you mean "had been"?

Section 10.2. , paragraph 6, nit:
>  example, if there is ambiguity as to whether to represent the binary digit 0
>                                 ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

"B.1. ", paragraph 2, nit:
> n z of degree zero. If m>1 (i.e., if if q is a strict prime power), then GF(q
>                                      ^^
Did you mean "is"?

"F.1. ", paragraph 4, nit:
> hose with the desired property with lowest possible degree. Appendix G. Furt
>                                     ^^^^^^
A determiner may be missing.

"K.3.1. ", paragraph 10, nit:
> en the two constructions above is that that the first construction uses the m
>                                   ^^^^^^^^^
Possible typo: you repeated a word.

"O.4. ", paragraph 9, nit:
> ticular cryptographic criteria). Despite of its wide-spread use, some details
>                                  ^^^^^^^^^^
Did you mean "Despite" (or, alternatively, "in spite of")?

Uncited references:
     [draft-FIPS-186-5], [SP-800-56c], [tEd], [ECC], [draft-NIST-800-186],
     [SWUmap]