Last Call Review of draft-ietf-regext-login-security-06
review-ietf-regext-login-security-06-opsdir-lc-pignataro-2019-12-04-00
Request | Review of | draft-ietf-regext-login-security |
---|---|---|
Requested revision | No specific revision (document currently at 10) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2019-11-12 | |
Requested | 2019-10-29 | |
Authors | James Gould , Matthew Pozun | |
I-D last updated | 2019-12-04 | |
Completed reviews |
Genart Last Call review of -05
by Brian E. Carpenter
(diff)
Opsdir Last Call review of -06 by Carlos Pignataro (diff) |
|
Assignment | Reviewer | Carlos Pignataro |
State | Completed | |
Request | Last Call review on draft-ietf-regext-login-security by Ops Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/ops-dir/lkbLskBkEqxEy3CX_aZfdw9jXqU | |
Reviewed revision | 06 (document currently at 10) | |
Result | Has issues | |
Completed | 2019-12-04 |
review-ietf-regext-login-security-06-opsdir-lc-pignataro-2019-12-04-00
Hello, 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 document describes an Extensible Provisioning Protocol (EPP) login security extension that allows longer passwords to be created and adds additional security features to the EPP login command and response. I found the document well structured and easier to read and follow, but I have one concern in regards to backwards compatibility and version management. The document says: 2. Migrating to Newer Versions of This Extension Servers which implement this extension SHOULD provide a way for clients to progressively update their implementations when a new version of the extension is deployed. Servers SHOULD (for a temporary migration period up to server policy) provide support for older versions of the extension in parallel to the newest version, and allow clients to select their preferred version via the <svcExtension> element of the <login> command. However, in which cases the first SHOULD can be ignored? That would break deployability. Further, now in the second paragraph, what is a "temporary migration period"? 27 msec, 2 minutes, 56 years? What is "older versions"? n-2? the previous how many? The client-driven selection and negotiation is useful, however, what are the guardrails and constraints for the server? Nit: Can the document incorporate instructions for the RFC Editor whether to remove the "Appendix A. Change History" section? Best, Carlos Pignataro.