NTRUencrypt in NIST competition Why did the NTRUencrypt team not maintain the NTRU1024 release in the NIST second-round competition?

Is this because of the speed performance or security performance or other things?
This has been answered on the PQC forum. The question was asked by El Hassane Laaji:


  Hello NTRU team
  
  Can you say me, why you didn't keep the NTRUencrypt-1024 release, is it because of > speed performance or security performance.
  
  Best regards.


The reply came from John Schanck:


  Thanks for your question. To clarify for others, the "NTRUencrypt-1024"
  parameter set was proposed in the first round NTRUEncrypt submission for
  use with the ss-ntru-pke and ss-ntru-kem schemes. I'll split your question
  into two parts:
  
  
  Why didn't we recommend ss-ntru?
  Why didn't we recommend an NTRU variant that uses Z[x]/(x^1024 + 1)?
  
  
  Regarding ss-ntru:
  
  At a fixed security level, NTRU and LWE schemes have a trade-off
  triangle between
  
  
  the correctness of the decryption procedure,
  the width of the coefficient distributions,
  the compactness of public keys and ciphertexts.
  
  
  The second round NTRU team wanted a compact scheme with a correct
  decryption procedure. The coefficient distribution used in ss-ntru
  is not compatible with that goal.
  
  Regarding Z[x]/(x^1024 + 1):
  
  It's not clear to us that there's a real need for an NTRU parameter set
  with such a large n. The largest n that we recommend is 821.
  
  Best,
  John (on behalf of the NTRU team)