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

I believe that this change already took place in rev08. What more do we
need to add ?

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-curdle-ssh-ed25519-ed448-08.txt

On Wed, Jun 5, 2019 at 5:53 PM Daniel Migault <daniel.migault@ericsson.com>
wrote:

> 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
>>
>