Subject: Re: [CFRG] Second RGLC on draft-irtf-cfrg-pairing-friendly-curves

From: Marek Jankowski <[email-masked]>
Date: Thu, 29 Apr 2021 08:46:28 +0200

I think Michael's comment points at the right direction for this draft. It
would be beneficial to have a CFRG specification for those curves and the
draft's core describes them well. I suggest that the proposers take off the
edges and put it up for review again.

Marek

On Fri, Mar 19, 2021 at 12:45 PM Michael Scott <mike.scott=
[email-masked]> wrote:

> The purpose of this proposed draft standard entitled “Pairing Friendly
> Curves” is to suggest standardised state-of-the-art curves for the safe
> implementation of pairing-based cryptography. The clue is in the title. The
> curves suggested are not controversial, and they are well enough described
> to allow unambiguous implementation (I have done it myself).
>
> I think  that the draft under consideration is not intended as, and should
> not be judged as, an attempt to vindicate the whole field of pairing-based
> crypto. It is just about the curves.
>
> The comments  from Rene do not anywhere suggest any problem with the
> curves themselves. Clearly “ditching” the whole proposal (as he suggests)
> would be a case of throwing the baby out with the bathwater.
>
> Might I suggest that the proposers cut back their proposal so as to just
> describe the curves, some test vectors, and a heavily curtailed
> bibliography. There is no actual requirement for much of the surrounding
> commentary. I don’t think this document needs to take on an educational
> brief. A reference to the excellent “Guide to Pairing-based Cryptography”
> would suffice. Of the RFCs I have attempted implementations from, the
> shortest have always been the best.
>
> The alternative  would be an attempt to respond point-by-point to Rene’s
> objections in order to keep the draft in its current shape. I suspect that
> this would involve multiple over-and-backs (as some of Rene's concerns seem
> pretty opaque to me), and would be a waste of everyone’s time.
>
> Mike Scott
>
> On Thu, Mar 18, 2021 at 5:36 PM Stanislav V. Smyshlyaev <[email-masked]>
> wrote:
>
>> Dear CFRG,
>>
>> This is to cancel the Second RGLC for Pairing-Friendly Curves for now.
>>
>> A part of the questions (
>> https://mailarchive.ietf.org/arch/msg/cfrg/kAQwgiKejMby4aYONkQzt0ZiOOU/
>> from Rene Struik with the additional concerns related to the -08 version of
>> the draft) raised in the list has not been replied publicly. The replies
>> for other reviews were provided in
>> https://mailarchive.ietf.org/arch/msg/cfrg/2i183zl28y4fK54oIwqEfEVVu0U/;
>> all later messages contained only support of the draft, but that does not
>> change the fact that one part of the concerns has not been discussed.
>>
>> Please accept my apologies for the inconvenience.
>> The RGLC will be restarted after all received comments are discussed
>> publicly in the mailing list.
>>
>> Regards,
>> Stanislav
>>
>>
>>
>> On Thu, 18 Mar 2021 at 18:23, Stanislav V. Smyshlyaev <[email-masked]>
>> wrote:
>>
>>> Dear Rene,
>>>
>>> Yumi replied to the received comments in the following message in
>>> December:
>>> https://mailarchive.ietf.org/arch/msg/cfrg/2i183zl28y4fK54oIwqEfEVVu0U/ (after
>>> the line "Followings are our reply comments for Rene's comments in RGLC.").
>>> After that message there were two messages in the mailing list with
>>> support of the draft, no new concerns.
>>>
>>> After that message there was also one clarifying message from Yumi in
>>> February about the normative references (I asked to send that message since
>>> I had found out that that comment remained unanswered).
>>>
>>> Regards,
>>> Stanislav
>>>
>>>
>>> On Thu, 18 Mar 2021 at 15:52, Rene Struik <[email-masked]> wrote:
>>>
>>>> Hi Stanislav:
>>>>
>>>> I am puzzled that the 2nd WGLC is on rev09 of the pairing curve draft
>>>> (i.e., the one posted on Nov 16th last year).
>>>>
>>>> On Nov 11th, I posted another review on rev08 of this document (see
>>>> [1]) {for my review of the previous rev07 version, see [2]}.
>>>>
>>>> I could not find any response by the authors to my detailed comments of
>>>> my rev08 review. Since they posted the current rev09 version (that is under
>>>> 2nd WGLC) on Nov 16th, considerations of those comments must have happened
>>>> within that 5-day time window. The authors, however, stated in [3]
>>>> "Because we are currently considering Rene's latest comments, I'm sorry but
>>>> this version does not reflect them".
>>>>
>>>> Isn't the normal step to consider received comments? If so, isn't the
>>>> 2nd WGLC premature?
>>>>
>>>> (FYI - the authors only commented - after almost four months - on my
>>>> minor note regarding normative vs. informative reference classification,
>>>> but not at all on the much larger review I did in [1].)
>>>>
>>>> Best regards, Rene
>>>>
>>>> [1] Review RS of draft-irtf-cfrg-pairing-friendly-curves-08 (Nov 11,
>>>> 2020):
>>>> https://mailarchive.ietf.org/arch/msg/cfrg/kAQwgiKejMby4aYONkQzt0ZiOOU/
>>>>
>>>> [2] Review RS of draft-irtf-cfrg-pairing-friendly-curves-07 (July 12,
>>>> 2020):
>>>> https://mailarchive.ietf.org/arch/msg/cfrg/pW71h3yUETnqedHsH0m3rwzPnm4/
>>>>
>>>> [2] Message Yumi Sakemi on draft-irtf-cfrg-pairing-friendly-curves-09
>>>> (Nov 16, 2020):
>>>> https://mailarchive.ietf.org/arch/msg/cfrg/NNpHIWGOvsSBd22gg7Ve10zDhT4/
>>>>
>>>>
>>>> On 2021-03-18 7:04 a.m., Stanislav V. Smyshlyaev wrote:
>>>>
>>>> Dear CFRG participants,
>>>>
>>>> This message starts a second 3-week RGLC on "Pairing-Friendly Curves"
>>>> (draft-irtf-cfrg-pairing-friendly-curves-09), that will end on April 9th.
>>>> See
>>>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/
>>>> for the latest version of the draft.
>>>>
>>>> We are having the second RGLC since Yumi Sakemi has provided (see
>>>> https://mailarchive.ietf.org/arch/msg/cfrg/2-LVS6EXc4TfY1zlHRGUXe3cu6w/)
>>>> replies for the questions raised after the first RGLC.
>>>>
>>>> Please send your comments, as well as expression of support to publish
>>>> as an RFC (or possible reasons for not doing so) in reply to this message
>>>> or directly to CFRG chairs.
>>>>
>>>> Regards,
>>>> Stanislav, Nick and Alexey
>>>>
>>>>
>>>> _______________________________________________
>>>> CFRG mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>>>>
>>>>
>>>> --
>>>> email: [email-masked] | Skype: rstruik
>>>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>>>>
>>>> _______________________________________________
>> CFRG mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Yumi Sakemi <[email-masked]>
Date: Sat, 1 May 2021 05:55:30 +0900

Dear CFRG members

I sent an email to the CFRG ML, but I got an error message, so I forward it.

Best regards,
Yumi

---------- Forwarded message ---------
From: Yumi Sakemi <[email-masked]>
Date: 2021年5月1日(土) 5:47
Subject: Re: [CFRG] Second RGLC on draft-irtf-cfrg-pairing-friendly-curves
To: Rene Struik <[email-masked]>
Cc: CFRG <[email-masked]>, SAITO Tsunekazu
<[email-masked]>, Tetsutaro Kobayashi
<[email-masked]>, <[email-masked]>

Dear Rene

Thank you for your e-mail.
I am very sorry for the delay in responding to your email at the start
of the 2nd RGLC.

I had already responded to the main part of your comment in November
2020 in the following email I sent in December 2020, and we were
waiting for your response to that communication.
https://mailarchive.ietf.org/arch/msg/cfrg/2i183zl28y4fK54oIwqEfEVVu0U/

I was relieved to hear from you, as I had been worried that I had not
heard from you for a long time.

Since there is a possibility that you may not have read my e-mail in
December, I will reply to each of your comments again in this e-mail.
I apologize for the length of this message in advance.

----------
>1) It seems that at least half of my main technical comments (apart from
>editorials) with my review of the rev-07 draft have not been addressed.
>Moreover, it is somewhat hard to get back to the authors on the mailing
>list, since they buried their comment resolutions in a somewhat nebulous
>github structure. This makes it a little bit hard to get enthusiastic
>about doing yet another review.

Thank you for your comments.
As you may know, many of the drafts registered on CFRG use GitHub's
issue feature to track revisions and changes of drafts.
You can refer to the following URL.
https://github.com/cfrg

So, let me add that this is not our original management method.
In addition, for comments that were not reflected as a result of
discussions among the authors, the reasons for not reflecting them are
also listed.
Could you please check again our reply comments for your comments if
you have any additional concerns?

>2) It seems that the authors have not done any effort to disentangle
>technical specification, availability of libraries, and actual
>deployment (see my comment #01 of my rev07 review), where there still is
>a somewhat misleading tilt due to equating all these disparate things
>and where there is still an unusual prominence of company names, etc.
>Perhaps, some of this can be taken care of by including a section with
>"implementation status" (which disappears once this becomes an RFC), as
>other IETF drafts have done. Nevertheless, this would fly in the face of
>selection policies for pairing-based curves which are based on conflated
>notions. This begs the question what the purpose of this draft is.

I'm sorry that the purpose of our draft was difficult to understand.
Let me explain the target of standardization again.
Our goal is to standardize secure parameters for pairing-based
cryptographic applications.
Since the 2016 Kim's attack made widely used standard parameters no
longer secure enough, we are organizing existing parameters and, among
others, showing which parameters should be used for each bit security.

As reference information, the calculation method of pairing is
described, but it is out of the scope of standardization
And also, an educational purpose for pairing is out of the scope of our draft.

On the other hand, in response to your comment, the authors have
discussed why this misunderstanding has occurred and thought that the
current title may be too generic and inappropriate.

The current title is "Pairing-Friendly Curves", which may have given
the impression of a broad standardization of information about
pairing.
We thought it would be a better idea to change the title to something
more specific to secure parameters of pairing, such as "Secure
Parameters of Pairing-Friendly Curves".
Would this address the misconceptions and concerns underlying your comment?

Also, the reason why we are describing the implementation status is
that in standardizing the parameters it is because this information is
essential to show how the parameters were selected.
There is no purpose to advertise the company or implementer.

>3) The draft, as it stands, still contains lots of material that is in a
>state with much to be desired for. As an example, Appendix A contains
>quite a few errors (Ate pairing) and lacks sufficient explanatory
>context and Appendix C is such an adhoc hack that (I feel) this should
>never be endorsed by CFRG. For details, see some of my comments on rev08
>(where I did focus on the appendices).

I think this comment is corresponds to Detailed Comments, so I'll
provide detailed answers there.
As you know because you commented in detail, our target is a specific
pairing calculation called "Optimal Ate pairing", not Ate pairing.
Optimal Ate pairing is an improved version of Ate pairing proposed by
F. Vercauteren in 2008.

F. Vercauteren, "Optimal Pairings",
available at https://eprint.iacr.org/2008/096.pdf, 2008.

>4) It may be best if CFRG ditches this document, since it still seems
>far off from being a useful document, written clearly so as to educate
>the CFRG and the wider IETF community. (Given the lack of feedback on
>this document over time, perhaps nobody would care.). Should CFRG still
>wish to give this draft a chance to become a CFRG-issued RFC, I believe
>it needs a major rewrite to get rid of nontechnical spin material. I
>also think it would be beneficial not to have yet more specifications
>come up with their own representations and procedures where there is no
>real technical justification for this. Should the authors wish to push
>this "as is", they could always pursue the "independent stream" for this
>(where one could argue that nothing can be changed). If this should be
>pushed furthr, I can imagine a slim draft, without umpteen tables and
>zillions of references, where one simply provides domain parameters and
>explains how mappings work without all the ads for libraries and
>start-up companies with non-empty github pages.
>For some detailed technical and editorial comments, see below. (I have
>more comments, but I think the below suffices to show this is far from
>ready.)
>I know this is not what authors want to hear and does not make me
>popular, but so be it.

Thank you for your comments.
We believe that there is no problem to proceed with standardization in
CFRG because we are following the IETF manner.
In light of the situation in our draft, we recognize that there is no
change in the situation that would overturn the approval in the
Adoption Call.
Regarding the table on implementation status, other CFRG members
pointed out the size of the table.
For this, I followed your comments and increased readability by
splitting the table.
Also, this table is required information to show that we are following
the selection policy, not to advertise it.
We are aware that we have reached a consensus by keeping the size to
the minimum required.

>Detailed comments:
>1) Appendix A: the description of the so-called line function is very
>unclear for non-pairing people (which I presume is most of the CFRG),
>where expressing this in a style resembling elliptic curve notation more
>would certainly help. Some suggestions: express the line function as
>Line_function(P1,P2,Q), where P1:=(x1,y1) and P2:=(x2,y2) are affine
>points of G2 (curve defined over GF(p^2)) and where Q:=(X,Y) is an
>affine point of G1 (curve defined over GF(p)), mapping to subgroup G_T
>of GF(p^k)^*. This allows expressing the number l if P1=P2 as
>l:=lambda:=(3*x1^2+a)/(2*y1), which is familiar in point doubling
>formulas for short-Weierstrass curves (where, here, domain parm a is
>zero) and, similarly, if P1<> (+/-) P2, as l:=lambda:=(y2-y1)/(x2-x1)
>(see, e.g., [3]). Here, it would also help explaining what happens in
>case of non-affine inputs (point-at-infinity) and why the output would
>be an element of the prime-order multiplicative subgroup G_T of GF(p^k)^*.

Thank you for pointing this out.
I understood that your comment means that in Appendix A, the
expressions for the x- and y-coordinates in the Affine coordinates of
the rational point A are represented as A[1] and A[2], respectively.
I agree with your point that the expressions are not familiar, so I
will correct it by using the symbols x and y.

>2) Appendix A, last para before A.1: one should mentions the image of
>the point-at-infinity under this Frobenius map.

I am afraid that I explain this to experts, but the Frobenius map is
an isomorphism map, so the identity element (the point at infinity) is
mapped to the identity element.
Since we think it is trivial, we describe no explanation about it.

>3) Appendix A.1: this section seems to be full of ambiguities and
>errors:
(a) should one assume the parameter t is the same as the one
>definining the prime p, etc.? (if so, please say so);
The parameter t is defined in the main part of 4.2.1 and 4.2.2, so I
hope you will check the draft properly.
Also, the method of expressing parameters p and r as polynomials of
the basic parameters (in this case t) is familiar to those in the
field of pairing.

>(b) write c:=c0+c1*2+ ... + c_{L}*2^{L} and explain that c_L is nonzero and that
>the Ate pairing procedure works no matter the choice of the coefficients
>in the range {-1,0,1} (if not, much explanation is needed, since, e.g.,
>c=0+1=2-1 may have different results;
Thank you for your comments.
As a reiteration, we would like to note that our target is *Optimal*
Ate pairing.
As mentioned in the draft, the parameter c is a specific value
determined by the parameter t.
The calculation method is outside the scope of our standardization,
and since there are several ways to expand c, our policy is that
implementers can choose the best one.

>(c) fix the loop to "for i:=L-1 downto 0";
Thanks for pointing that out.
I'll revise it to "downto" according to your comments.

>(d) replace the silly "|" language in the if condition "c_i=1
>| c_i=-1" by "c_i nonzero" (you are writing this for humans, not for
>parsers);

Thank you for your comments.
Indeed, I agree that it is not common to express "or" with "|".
So, I will define "! =" is defined as "not equal to" in advance and
then modify to "c_i ! = zero".

>(d) the Line_function has three arguments, but in the call
>Line_function(T, ci*Q) it only has two: should this include P as third
>argument?;
I'm sorry but I had a typo, so thank you for pointing it out.
I will revise it.

>(e) how does one know the line function never receives
>non-affine points as input?;

You can also calculate pairing with other coordinates than Affine
coordinates, such as projective coordinates.
However, we have a policy of not mentioning specific calculations that
use other coordinates in particular, as it may violate patents.
We recognize that there is no big influence even if the coordinates
are different because it does not affect the final calculation results
of pairing or test vectors.

>(f) the line with frobenius maps seems to compute Q1:=frob(Q); Q2:=frob(Q1) and,
>if so, doesn't one get Q2=frob(frob(Q))=Q since Q is a point of G2 and,
>thereby a point of a curve defined over GF(p^2)?
Algorithms using the Frobenius map are not the target of our standardization.
For this reason, we consider the reference information on the
calculation method to be sufficient.
If you want to know the details of the calculation method, please
refer to the reference information.

>4) Appendix A.1: how does one know that f is never the zero element 0
>(if so, it is not in GF(p^k)*)?

We believe that it is clear from the method of calculation that f does
not equal zero.
For f to be zero, the numerator of the Line Function needs to be zero.
The numerator of the Line Function is when the difference of the
x-coordinates of the points is zero, that is, in an elliptic curve,
when the two input rational points are equal.
However, in this case, the process is (3 * A[1]^2), which is not zero.
Implementers can check that the implementation is correct by testing
with test vectors and boundary values.

>5) Appendix A.1: the Ate pairing seems to use integer c written in
>NAF-notation. If so, shouldn't one at least say something about side
>channels, in case the inputs or outputs of the Ate pairing are
>non-public parameters? What about the huge final exponentiation in
>GF(p^k)^*, where the exponent h:=(p^k-1)/r has an enormous size (~
>p^{k-1})? (Note RS: I did ask about side-channels in my review of the
>rev07-draft [rev07-comment #10], but that comment was never addressed.)

Although the NAF representation is sometimes used as a side-channel
countermeasure, the NAF representation in pairing calculations is used
for accelerating purposes.
The reason for this is that the parameter c is public information, not secret.
The cases where side-channel attack countermeasures are required as
pairing-based cryptography are described in security considerations.

>6) Appendix A.2: the beginning of that section is virtually the same as
>Appendix A.1's, but misses some language (e.g., on "sum of
>(i=0,1,...,L)" --> equals c, order r --> of G1, etc. Remarks on some of
>the steps of the listed procedure similar to those with Appendix A.1 apply.
Thank you for pointing this out.
We will revise the description so that description is aligned.

>7) Appendix A would benefit from a much better explanation of the role
>of the Ate pairing in pairing-based crypto. Otherwise, this seems just
>loose sand, without context. (If the goal is to educate the CFRG
>audience about coolness of pairing-based crypto, why not provide
>sufficient detail to raise interest?; otherwise, why pursuing this draft?)

We consider it sufficient to show that pairing realizes for great
applications in the Introduction section.

>8) Appendix B: the relationship between elements of GF(p^k) and the
>output sequences (e_0,...,e_{11}), resp. (e_0,...,e_{47}) is not
>described in sufficient detail.
Thanks for your comments.
The symbol e consistently represents the value of the pairing in the
draft, but we will describe the explanation again.

>9) Appendix C: this appendix is so poorly written and the construction
>so adhoc that this should be abandoned right away (see also my previous
>comment in my rev-07 draft review (rev07-comments#21/#22). Here, simply
>observe that this point encoding only works for BLS12-381 and not for,
>e.g., BN462, purely because of poor design choices made. Please also see
>Note 2 of Appendix I.8 of draft-ietf-lwig-curve-representations-13
>(which describes SEC1 representations, but now for any field of odd
>characteristic). Simply using the SEC1-encoding, where one squeezes-in
>the 1-octet identifier for affine points (0x04), point-at-infinity
>(0x00), and compressed y-coordinate (0x02 or 0x03) in the leftmost 2
>bits of the tight MSB/msb-order representation of elements of GF(p),
>where the bit-length of p has two fixed bit positions for BLS12-381 and
>BN462 case does the job.

>10) Appendix C: while I think this appendix should be ditched right away
>and replaced by a more systematic approach that, in principle, applies
>to all pairing-based curve domain parameters (see prevous comment),
>there are also some problems with the text itself, including (a) the
>high-level remarks are confusing and do not seem to contain any useful
>information, so might easily be removed; (b) The I2OSP and OS2IP
>functions in RFC 8017 do describe integer-to-octet-string and
>octet-string-to-integer conversions, but do not specify the bit-ordering
>(which is needed to describe the encoding of integers as bit-strings and
>vice-versa);  (c) Step 2 (in Appendix C.1) seems to confuse
>specification and implementation (since seemingly aimed at machines
>rather than humans); (d) Step 3 (in Appendix C.1) seems to suggest that
>an element x=x0 + u*x1 of GF(p^2) is represented in the order "highest
>coefficient first", whereas in Section 2.5 this seems to be in the order
>"lowest coefficient first" (although this is hard to figure out due to
>the recursive definition in terms of towers of fields) - it is hard to
>figure out what "see discussion of vector representation above" refers
>to, since there does not seem to have been one; (e) Step 8 (in Appendix
>C.2) may result in output P:=(x,-y), where the second coordinate is a
>negative integer (and, thereby, not in the interval [0,p)).

I recognized that detailed comments 9 and 10 are about Appendix C.
The position of Appendix C is that it is reference information for
implementers, not a standardization target.
Since the author understands that the methods in Appendix C don't
apply to BN462, it is also clearly stated that the methods are for
BLS12-381 and are for reference only.
As for the contents of the Appendix in the draft (excluding typos), I
think that there is no problem with the current expression.

>Editorial comments:
>1) Appendix A, last para before A.1: this para refers to Barreto-Naehrig
>curves and should be moved to the beginning of Appendix A.1.
Thank you for your comment.
This is not a technique specific to BN curves, so we will remove "for
BN curves".

>2) Appendix A, last para before A.1: why not expressing the Frobenius
>map in a more human-friendly way, e.g., frob(x,y):=(x^p,y^p), where one
>leaves the parameter p implicit?
Thank you for your suggestion.
We will revise it according to your comments.

>3) Appendix B, l. 8: in "where u is a indeterminate", change "a" to "an".
I’m sorry but I had a typo, so thank you for pointing it out.
I will revise it.

>4) Appendix B, l. 8: check for consistent naming of BLS48-581, etc.
>(underscore vs. dash language). Also elsewhere. BTW - it would help to
>add the curve name to section headings to make these easier to find,
>e.g., adding BLS12_381 to the title of Section 4.2.1, etc.

Thanks for pointing this out.
I will revise the wording to be consistent, using underscores.
Additionally, we will revise the title as you suggested.

>5) Appendix C, p. 49: replace "sign_F_p" by "sign_GF(p)", etc.
Thank you for your comments.
I will revise it.

>6) Section 4.2.1, last para: I am not sure what adding the new (in
>rev08) advertisement for another cfrg draft (hash-to-curve) adds to this
>document, since it seems to be just PR, without any context. Shouldn't
>one shy away from cross-marketing?

There is no cross-marketing implication as you have pointed out.
As for the pairing draft, we are citing it because it is a draft that
should be cited from the perspective that the Hashing feature is
necessary for the protocol implementation.

Best regards,
Yumi

2021年3月18日(木) 21:53 Rene Struik <[email-masked]>:
>
> Hi Stanislav:
>
> I am puzzled that the 2nd WGLC is on rev09 of the pairing curve draft (i.e., the one posted on Nov 16th last year).
>
> On Nov 11th, I posted another review on rev08 of this document (see [1]) {for my review of the previous rev07 version, see [2]}.
>
> I could not find any response by the authors to my detailed comments of my rev08 review. Since they posted the current rev09 version (that is under 2nd WGLC) on Nov 16th, considerations of those comments must have happened within that 5-day time window. The authors, however, stated in [3]  "Because we are currently considering Rene's latest comments, I'm sorry but this version does not reflect them".
>
> Isn't the normal step to consider received comments? If so, isn't the 2nd WGLC premature?
>
> (FYI - the authors only commented - after almost four months - on my minor note regarding normative vs. informative reference classification, but not at all on the much larger review I did in [1].)
>
> Best regards, Rene
>
> [1] Review RS of draft-irtf-cfrg-pairing-friendly-curves-08 (Nov 11, 2020):
> [2] Review RS of draft-irtf-cfrg-pairing-friendly-curves-07 (July 12, 2020):
> [2] Message Yumi Sakemi on draft-irtf-cfrg-pairing-friendly-curves-09 (Nov 16, 2020):
> This message starts a second 3-week RGLC on "Pairing-Friendly Curves" (draft-irtf-cfrg-pairing-friendly-curves-09), that will end on April 9th. See https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/ for the latest version of the draft.
>
> We are having the second RGLC since Yumi Sakemi has provided (see https://mailarchive.ietf.org/arch/msg/cfrg/2-LVS6EXc4TfY1zlHRGUXe3cu6w/) replies for the questions raised after the first RGLC.
>
> Please send your comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs.
>
> Regards,

-- 
Yumi Sakemi, Ph. D.
 Infours Inc.

E-Mail: [email-masked]

---

From: Rene Struik <[email-masked]>
Date: Fri, 30 Apr 2021 17:18:29 -0400

Hi Yumi:

Thanks for your note.

I may have missed something, but the weblink which you provided below 
and which supposedly already answered my 2nd WGLC comments does *not* 
seem to already have answered my review comments, contrary to what you 
suggested. If it did (and I somehow missed this), why did not you not 
simply indicate so on  March 18th, rather than only doing his now, 6 

weeks later?

I will try and go through the details of your note later (it is hard to 
keep interested with such extremely long cycles [we all have time to 
manage]).

One general comment and piece of advice (based on a quick scan of your 
email): you seem to take the position that one does not need to 
elaborate on topics that are already known to "people in the know" in 
pairing. I do think the purpose of CFRG docs is to introduce "new" 
(whatever that means) crypto and make these accessible to a community 
that is wider than those already in the know. I do think (my 
interpretation of) your position is not very helpful to garner wider 
appreciation of a topic area. It again makes me wonder why you're even 
bothering. I think one can do much better and serve the community at 
large by not tasking readers to go elsewhere to look up details.

Rene

Your ref: [1] 

On 2021-04-30 4:47 p.m., Yumi Sakemi wrote:
>> I could not find any response by the authors to my detailed comments of my rev08 review. Since they posted the current rev09 version (that is under 2nd WGLC) on Nov 16th, considerations of those comments must have happened within that 5-day time window. The authors, however, stated in [3] 
 "Because we are currently considering Rene's latest comments, I'm sorry but this version does not reflect them".
>> This message starts a second 3-week RGLC on "Pairing-Friendly Curves" (draft-irtf-cfrg-pairing-friendly-curves-09), that will end on April 9th. 
See https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/ for the latest version of the draft.