Re: [regext] Opsdir last call review of draft-ietf-regext-login-security-06

["Gould, James" <[e-mail]>]

Carlos,

Thank you for your review and feedback.  I reply to your feedback embedded below.

-- 
 
JG



James Gould
Distinguished Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 12/4/19, 10:18 PM, "Carlos Pignataro via Datatracker" <[e-mail]> wrote:

    Reviewer: Carlos Pignataro
    Review result: Has Issues
    
    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?

JG - Ignoring the SHOULD is when the server implements a hard cutover of the old version to the new version based on other mitigating steps, such as providing adequate notice and providing a test environment for clients to test against prior to the cutover.  The cutover and the mitigating steps is up to server policy, but the recommendation in the draft is to progressively update the server implementation.  Performing a hard cutover would not break deployability if the server only supports the latest version and the clients are created to be forward compatible.  It's much better to not force the clients to be forward compatible and to support the old and new versions in parallel for a period of time.  The overlap period is a server policy decision and not something that the protocol should define and come to consensus on.   
    
    Nit: Can the document incorporate instructions for the RFC Editor whether to
    remove the "Appendix A.  Change History" section?
 
JG - Thanks, "[[RFC Editor: Please remove this section.]]" can be added to section.  


   
    Best,
    
    Carlos Pignataro.