|
Brian, Thank you for your review and feedback. My responses are embedded below. I will include updates based on your feedback in draft-ietf-regext-login-security-06 at the conclusion of the last call. -- JG James Gould Distinguished Engineer jgould@xxxxxxxxxxxx <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@xxxxxxxxxxxx> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/2/19, 11:49 PM, "Brian Carpenter via Datatracker" <noreply@xxxxxxxx> wrote: Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-regext-login-security-05 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-regext-login-security-05.txt Reviewer: Brian Carpenter Review Date: 2019-11-03 IETF LC End Date: 2019-11-12 IESG Telechat date: Summary: Ready with minor issues -------- Minor issues: ------------- I found section 2 "Migrating to Newer Versions of This Extension" a little hard to follow. Firstly, am I correct in assuming that "a new version" means a version number higher than 1.0, e.g. "loginSec-1.1"? That is probably the intended meaning, but I think it needs to be explicit. Maybe state that this document defines "loginSec-1.0" and future documents can define other minor and major versions such as "loginSec-1.1" or "loginSec-2.0". JG - The "Migration to Newer Versions of This Extension" section was originally meant to address point version updates (e.g., loginSec-0.2, loginSec-0.3) prior to version loginSec-1.0, but Barry Leiba's review feedback recommended leaving
it in the draft. This section is applicable to any version change, including migrating from a pre-loginSec-1.0 version to loginSec-1.0 or a future update of loginSec-1.0 to loginSec-1.1. I believe the language needs to remain generic to apply to both cases. Then "(for a temporary migration period)" is a bit vague. I think it would be useful to suggest the order of magnitude of the overlap period: days?, months?; hopefully not years. JG - The migration period is up to server policy. It could be made more explicit by changing it to read "(for a temporary migration period
up to server policy)". Do you agree with this change? I also think a short discussion of adding & removing versions is version needed in the Security Considerations, since the reason for a new version might be the discovery of a vulnerability in the current version. That's when a short migration period is desirable. JG – I don’t see the linkage of adding & removing versions to the Security Considerations, since a version change may be due to multiple reasons (functional issue, functional enhancement, and security). The length of time for the migration
is up to server policy based on many factors outside of the protocol. FYI, there are some other extension design considerations in https://tools.ietf.org/html/rfc6709#section-4 . JG – Thank you, I’ll be sure to review
https://tools.ietf.org/html/rfc6709#section-4. Nits: ----- "1. Introduction This document describes an Extensible Provisioning Protocol (EPP) extension for enhancing the security of the EPP login command in EPP RFC 5730. The enhancements include supporting longer passwords (or passphrases) than the 16-character maximum and providing a list of security events in the login response. The password (current and new) in EPP RFC 5730 can be overridden..." "RFC 5730" should either be in parenthesis as "(RFC 5730)" or a reference "[RFC5730]" (twice). JG – I will change the RFC 5730 references in the Introduction to use links (xrefs). |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
