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

Dear co-authors of curdle-ssh-ed25519-ed448,

Could we update the document and address the concern from Sheng ?

Yours,
Daniel

On Thu, Jan 3, 2019 at 11:23 AM Daniel Migault <daniel.migault@ericsson.com>
wrote:

> Hi Sheng,
>
> Thanks for the comment. It should be easily addressed in the next version.
>
> Yours,
> Daniel
>
> -----Original Message-----
> From: Sheng Jiang <jiangsheng@huawei.com>
> Sent: Thursday, January 03, 2019 8:59 AM
> To: Daniel Migault <daniel.migault@ericsson.com>; Tim Hollebeek <
> tim.hollebeek@digicert.com>; ops-dir@ietf.org
> Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
> ietf@ietf.org
> 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:daniel.migault@ericsson.com]
> Sent: Thursday, January 3, 2019 2:57 AM
> To: Tim Hollebeek <tim.hollebeek@digicert.com>; Sheng Jiang <
> jiangsheng@huawei.com>; ops-dir@ietf.org
> Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
> ietf@ietf.org
> 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@digicert.com>
> Sent: Wednesday, January 02, 2019 1:12 PM
> To: Daniel Migault <daniel.migault@ericsson.com>; Sheng Jiang <
> jiangsheng@huawei.com>; ops-dir@ietf.org
> Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
> ietf@ietf.org
> 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@ietf.org> On Behalf Of Daniel Migault
> > Sent: Wednesday, January 2, 2019 10:43 AM
> > To: Sheng Jiang <jiangsheng@huawei.com>; ops-dir@ietf.org
> > Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
> > ietf@ietf.org
> > 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@huawei.com>
> > Sent: Wednesday, January 02, 2019 5:02 AM
> > To: ops-dir@ietf.org
> > Cc: draft-ietf-curdle-ssh-ed25519-ed448.all@ietf.org; curdle@ietf.org;
> > ietf@ietf.org
> > 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@ietf.org
> > https://www.ietf.org/mailman/listinfo/curdle
> _______________________________________________
> Curdle mailing list
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>