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). _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
