Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-unhandled-namespaces-07: (with COMMENT)

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

Ben,

Thank you for your review and feedback.  I provide answers to your feedback below.  The referenced updates will be included in the posting of draft-ietf-regext-unhandled-namespaces-08 along with addressing the other feedback.

Thanks,

-- 
 
JG


James Gould
Fellow 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 2/18/21, 3:04 AM, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:

    Benjamin Kaduk has entered the following ballot position for
    draft-ietf-regext-unhandled-namespaces-07: No Objection

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://secure-web.cisco.com/1yPQYI1c9tXSEoYfkadjJdqXcBm9wmFYjvHBdyXg8gl7UfX3tyGPiT_vPr2PLWg6lpuqG_V8dwvTQ5B5bnQLDmzOOkJbSUkjMaC20YuIdBwKFZFh0NdSt-Ds-i0ykvPdf0mHHvGv5ILUyMbr6CBdiaXdi7Fydwx2LuUPOhTA9yAWLpfFdOGu7J3LSy0wrN32oh_kx2dwP5BVBZx5hFqZsr2SACtCukV8jme46DwTWh9zZiUCvPyM8gwKDkGb-1VzI/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://secure-web.cisco.com/1wy2ArcqQe3Zq40eI7HaKnaXuR0vvqzH838JvnmQrBzHjnb2jRMy-2ApZ8e2EzlE3g44OC9QVBYI6346OQjxknh2Aq062BriBH6Cwt-BhsNU99N9KroO0lFYdYvFgnShD44GJjSISOtJmmolVNmHfDeiGgVHjM18gyIK90rBbzwZAQ5kv3XcQrqN51wrd_VkLalpHzhOo7iBySvB6CgbR9veCq1QpnKyfBIxctIMZwnGXZEylNu3PBQlsWFg86d-3/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-unhandled-namespaces%2F



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    If both object-level and command-response extensions end up in the
    <extValue> element, is it possible to determine whether a given
    <extValue> is due to an object extension or a command-response
    extension?

JG - The way that a client would do this is by mapping the XML namespace to the namespaces included in the original EPP Greeting (https://tools.ietf.org/html/rfc5730#section-2.4), which splits out object-level extensions, using the <objURI> elements, from command-response extensions, using the <svcExtension> elements.  

    Section 2

                                                       The services
       supported by the server are included in the <objURI> and <extURI>
       elements of the [RFC5730] EPP <greeting>, which should be a superset
       of the login services included in the EPP <login> command.  [...]

    Where is this "should be a superset" specified?  AFAICT it seems a bit
    challenging for graceful deployment of new functionality, as it would
    require servers to be updated before clients.  If it was intended to be
    a *sub*set, that might make more sense, but text elsewhere in the
    document is not consistent with "subset".

JG - The use of the superset language is based on an interpretation of RFC 5730, where the EPP Greeting includes the set of services "supported by the server", and the EPP Login includes the set of services "to be used during the session".  If the client includes more services than the server supports in the EPP Greeting then the negotiated services in the EPP session would be invalid.  Therefore, the EPP Greeting services needs to be a superset of the EPP Login services or conversely the EPP Login services needs to be a subset of the EPP Greeting services, since the EPP Login services specify what will be used.  Superset is the appropriate term when defining it from the perspective of the EPP Greeting.  

    Section 3

       This document supports handling of unsupported namespaces for
       [RFC3735] object-level extensions and command-response extensions.
       This document does not support [RFC3735] protocol-level extensions or
       authentication information extensions.  [...]

    (editorial) I might consider a different word than "support"; perhaps
    "utilize" or "instantiate".

JG - The use of the "apply" may be more appropriate than "support", as in "This document applies to the handling of unsupported namespaces for..." and "This document does not apply to the handling of unsupported namespaces for...".  Do you agree? 

    Section 3.1

    Should we mention that the example <transfer> query response from RFC
    5731 is in section 3.1.3 of that RFC?

JG - Sure the section reference can be added, as in "...example in Section 3.1.3 of [RFC5731]...".  

       [RFC5731] example <transfer> query response converted into an
       unhandled namespace response.

       S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
       [...]
       S:        <value>
       S:          <domain:trnData
       S:            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
       S:            <domain:name>example.com</domain:name>
       S:            <domain:trStatus>pending</domain:trStatus>
       S:            <domain:reID>ClientX</domain:reID>
       S:            <domain:reDate>2020-06-06T22:00:00.0Z</domain:reDate>
       S:            <domain:acID>ClientY</domain:acID>
       S:            <domain:acDate>2020-06-11T22:00:00.0Z</domain:acDate>
       S:            <domain:exDate>2021-09-08T22:00:00.0Z</domain:exDate>

    Why did the dates (years) get updated compared to the RFC 5731 example?
    (And it's not just a matter of uniformly adding 20 years, as the exDate
    is only 19 years different.)

JG - It was meant to update the dates to something more current, so 20 years was added.  I don't remember the logic beyond use of 19 years for the exDate.  Updating of the examples to match their source RFC XML and reference them by section of the RFC will be addressed throughout the draft.

    Section 3.2

       [RFC5910] DS Data Interface <info> response converted into an
       unhandled namespace response.

    I couldn't actually find which example this corresponds to.  It seems
    like Section 5.1.2 of RFC 5910 would be the section in question, but the
    first example there has a <secDNS:keyData> element that's not present
    here, and the second example there doesn't have a <secDNS:keyTag>.
    (Also, algorithm 3 and digest type 1 corresponds to DSA/SHA1 and SHA1,
    IIRC, which are not exactly current best practice values.  But the focus
    here is on the XML, so I would not fault us for using the RFC 5910
    example verbatim ... if that was what we were actually doing.)

JG - The example is taken from the first example in Section 5.1.2 of RFC 5910.  The second example in Section 5.1.2 of RFC 5910 includes the optional <secDNS:keyTag> element.  Updating of the examples to match their source RFC XML and reference them by section of the RFC will be addressed throughout the draft. 

Section 5

    I had the same question as Murray.  (And shouldn't that be something
    specified in RFC 5730 anyway, not here?)

JG - I provided a similar response to Murray. This is set as a SHOULD and SHOULD NOT since it's based on an interpretation of RFC 5730 that the server only accepts object-level commands based on the negotiated services in the EPP session.  Since this draft is focused on unhandled namespaces it was felt to make it a recommendation with the SHOULD and the SHOULD NOT.  RFC 5730 doesn't explicitly state it, which is the basis for the SHOULD and SHOULD NOT instead of the MUST and MUST NOT.    

       S:          <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0">
       S:            <rgp:rgpStatus s="redemptionPeriod"/>
       S:          </rgp:infData>

    It looks like the corresponding RFC 3915 example also had an
    xsi:schemaLocation attribute here.  Though I guess maybe we are not
    strictly claiming that this example is taken from RFC 3915, so it's okay
    (as well as the following few nits)...

       S:        <domain:upID>ClientX</domain:upID>
       S:        <domain:upDate>2020-12-03T09:00:00.0Z</domain:upDate>
       S:        <domain:exDate>2021-04-03T22:00:00.0Z</domain:exDate>
       S:        <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>

    These dates seem to have been changed from the RFC 3915 example as well.

       S:        <domain:authInfo>
       S:          <domain:pw>2fooBAR</domain:pw>
       S:        </domain:authInfo>

    I did not see the authInfo in the RFC 3915 example.

JG - Good eye.  Updating of the examples to match their source RFC XML and reference them by section of the RFC will be addressed throughout the draft. 

   Section 10

    I'd recommend just "SHOULD validate" rather than the (not exactly
    actionable) "SHOULD consider validating".

    Also, there are arguably security considerations in the risk of the
    client not actually processing the data from unhandled namespaces,
    especially if it is "needed" for some purpose (we don't seem to go into
    much detail as to if/when that might happen).

JG - Agreed on the use of "SHOULD validate" instead of "SHOULD consider validating".  The only security consideration would be associated with the processing of poll messages.  But in thinking about it this doesn't really represent a security consideration in implementing the draft since  inclusion of the information in the standard location is no different from inclusion under the <extValue> element, since the client doesn't support it.  The only solution is for the client to support all of the namespaces supported by the server and use the unhandled namespaces approach as a signal to add that support.      

    Section 12.1

    The RFC 3915 content seems to only be used in an example, so it could
    probably be classified as informative.  Likewise for RFC 5910 and RFC
    8590.

JG - Agreed, that change will be made.