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
<<attachment: smime.p7s>>
