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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/



----------------------------------------------------------------------
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?

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".

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".

Section 3.1

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

   [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.)

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.)

Section 5

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

   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.

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).

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.