Re: [Curdle] Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07

[Daniel Migault <[e-mail]>]

Hi Sheng, 

Thanks for the comment. It should be easily addressed in the next version.

Yours, 
Daniel

-----Original Message-----
From: Sheng Jiang <[e-mail]> 
Sent: Thursday, January 03, 2019 8:59 AM
To: Daniel Migault <[e-mail]>; Tim Hollebeek <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07

Hi, Daniel,

The suggestion from Tim is a good improvement. However, it would be even better for a "standard track" document, if it gave a little bit more detailed guidance "where" and "how" a SSH implement should quota the key format that defined in this document.

Regards,

Sheng

-----Original Message-----
From: Daniel Migault [mailto:[e-mail]]
Sent: Thursday, January 3, 2019 2:57 AM
To: Tim Hollebeek <[e-mail]>; Sheng Jiang <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Opsdir last call review of draft-ietf-curdle-ssh-ed25519-ed448-07

Thanks for the suggestion Tim. That works for me. 
Yours,
Daniel

-----Original Message-----
From: Tim Hollebeek <[e-mail]>
Sent: Wednesday, January 02, 2019 1:12 PM
To: Daniel Migault <[e-mail]>; Sheng Jiang <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: Opsdir last call review of
draft-ietf-curdle-ssh-ed25519-ed448-07

Why not just reference RFC 2119 and say "Standard implementations of SSH SHOULD implement these signature algorithms." ?

-Tim

> -----Original Message-----
> From: Curdle <[e-mail]> On Behalf Of Daniel Migault
> Sent: Wednesday, January 2, 2019 10:43 AM
> To: Sheng Jiang <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: Re: [Curdle] Opsdir last call review of
draft-ietf-curdle-ssh-ed25519-
> ed448-07
> 
> Hi Sheng,
> 
> Thanks for the comment and the suggestion. I agree that it may sound 
> strange to have a standard Track category without any reference to 
> RFC2119. In addition, while the document provides IANA registry 
> updates, the IANA registration does not require a Standard Track. So 
> *technically*
the
> informational category could be fine.
> 
> The motivation for a Standard Track document was to have these 
> algorithms as part of the SSH protocol. In other words, we expect that 
> SSH will come with these algorithms in the future. For that reason we 
> requested the
status
> to be "Standard Track" to remain coherent with RFC425{1-4}.
> 
> (RFC4250 and) RFC4253 provided the initial values for the Public Key
registry.
> While the protocol comes with some registry values, my understanding 
> is that updating the registry by adding a new value is not considered 
> as an update the RFC. For that reason we did not provide RFC4253 or 
> RFC4250 in the update status. While the update does not concern the 
> RFC, it affects
the
> protocol and should - in my opinion be associated to the same status 
> as
the
> protocol.
> 
> As a side note, all RFCs that have updated the Public Key Algorithm 
> Names are Standard Track documents. On the other hand, they seem to 
> reference and use the RFC2119 terms.
> 
> I believe that the Standard Track category is the most appropriated, 
> however, I am happy to be wrong and have misunderstood something. Feel 
> free to let me know your opinion on the category, as well as if there 
> are
any
> clarification we should add in the text. I suggest that we add a 
> sentence around the lines:
> """ These signature algorithms are expected to be integrated into the 
> standard implementations of SSH. """
> 
> Any feed back is welcome!
> 
> Yours,
> Daniel
> -----Original Message-----
> From: Sheng Jiang <[e-mail]>
> Sent: Wednesday, January 02, 2019 5:02 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: Opsdir last call review of 
> draft-ietf-curdle-ssh-ed25519-ed448-07
> 
> Reviewer: Sheng Jiang
> Review result: Has Issues
> 
> Reviewer: Sheng Jiang
> Review result: Has Issues
> 
> Hi, OPS-DIR, Authors,
> 
> I have reviewed this document as part of the Operational directorate's 
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written with the intent of improving the 
> operational aspects of the IETF drafts. Comments that are not 
> addressed in last call
may
> be included in AD reviews during the IESG review. Document editors and 
> WG chairs should treat these comments just like any other last call comments.
> 
> This standard track document describes the use of the Ed25519 and 
> Ed448 digital signature algorithm in the Secure Shell (SSH) protocol.  
> This
document
> is one of the shortest documents I have ever seen. It is clear and 
> well written.
> However, I have a fundamental issue regarding to its Intended status 
> "Standards Track", describe below. Therefore, it has issues for
publication
> although I think it is easy to fixed - changing the Intended status.
> 
> Major issue: this document has Intended status for Standards Track.
> However, neither this document fails to quota RFC 2119 or has any 
> normative words.
> Consistently, I don't think the description in this document has any 
> mandatory requirements for any implementations of protocols. Actually, 
> the most important quota of this document, RFC8032, is Informational, 
> which is a Downref in this document. Therefore, I think it is more 
> proper this document intends for Informational status.
> 
> Minor issue: no.
> 
> Regards,
> 
> Sheng
> 
> 
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle