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:daniel.migault@xxxxxxxxxxxx] Sent: Thursday, January 3, 2019 2:57 AM To: Tim Hollebeek <tim.hollebeek@xxxxxxxxxxxx>; Sheng Jiang <jiangsheng@xxxxxxxxxx>; ops-dir@xxxxxxxx Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx; ietf@xxxxxxxx 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 <tim.hollebeek@xxxxxxxxxxxx> Sent: Wednesday, January 02, 2019 1:12 PM To: Daniel Migault <daniel.migault@xxxxxxxxxxxx>; Sheng Jiang <jiangsheng@xxxxxxxxxx>; ops-dir@xxxxxxxx Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx; ietf@xxxxxxxx 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 <curdle-bounces@xxxxxxxx> On Behalf Of Daniel Migault > Sent: Wednesday, January 2, 2019 10:43 AM > To: Sheng Jiang <jiangsheng@xxxxxxxxxx>; ops-dir@xxxxxxxx > Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx; > ietf@xxxxxxxx > 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 <jiangsheng@xxxxxxxxxx> > Sent: Wednesday, January 02, 2019 5:02 AM > To: ops-dir@xxxxxxxx > Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@xxxxxxxx; curdle@xxxxxxxx; > ietf@xxxxxxxx > 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 > Curdle@xxxxxxxx > https://www.ietf.org/mailman/listinfo/curdle
