Extensible Provisioning Protocol (EPP) Unhandled Namespaces
draft-ietf-regext-unhandled-namespaces-08

[[ nits ]]

[ section 4 ]

* "does not define new protocol" -> "does not define a new protocol",
  perhaps

Why are the SHOULD and SHOULD NOT in Section 5 not MUST and MUST NOT?

Thank you for including Section 9.

Section 10.  

Since the unhandled namespace context
   is XML that is not processed in the first pass by the XML parser, the
   client SHOULD consider validating the XML when the content is
   processed to protect against the inclusion of malicious content.

Could this proposed validation please be further explained?  The client has previously signaled that didn’t understand the namespace to begin with which is why it got content in via an extension.  Therefore, how would it be expected to parse the content on a subsequent pass?

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.

Thanks Qin for the OPS-DIR review.