Brian, thanks for your review. I can see where you’re coming from with the points you raise about migrating versions, but given the nature of this extension, it seems like an urgent security-related version update is quite unlikely. Therefore leaving the time scale up to server policy seems ok.
James, thanks for your response. I entered a DISCUSS ballot to chat about the extensibility with custom events. Thanks, Alissa > On Nov 5, 2019, at 2:37 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > James, > > Comments in line: > On 06-Nov-19 07:58, Gould, James wrote: >> 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 >> jgo...@verisign.com >> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > >> 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" <nore...@ietf.org> >> 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. > > Yes, that makes sense. I think that because this section occurs *before* the > technical details it isn't quite clear what "version" means - I certainly had > to come back to this section after reading the whole text. But you probably > don't want to mention loginSec-0.x, hence the examples I suggested. > >> 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? > > Making it clear that it's a policy choice is an improvement, yes. But I still > think that it would be useful to indicate a timescale. I've seen migration > overlaps ranging anywhere from seconds to years in different protocols and I > really have no idea where this one lies on that spectrum. > >> 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. > > Of course. But the specific case of a security-driven update is special and > may be much more urgent than normal policy. That's why I'd be inclined to > mention it. Not a big deal, however. > > Regards > Brian Carpenter > >> 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). > > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
