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

[Daniel Migault <[e-mail]>]

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