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

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

Section 2

                                                  The services
  supported by the server are included in the  and
  elements of the [RFC5730] EPP , which should be a superset
  of the login services included in the EPP  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  query response from RFC
5731 is in section 3.1.3 of that RFC?

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

  S:
  [...]
  S:       
  S:         
  S:            example.com
  S:            pending
  S:            ClientX
  S:            2020-06-06T22:00:00.0Z
  S:            ClientY
  S:            2020-06-11T22:00:00.0Z
  S:            2021-09-08T22:00:00.0Z

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  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  element that's not present
here, and the second example there doesn't have a .
(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:         
  S:           
  S:         

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:        ClientX
  S:        2020-12-03T09:00:00.0Z
  S:        2021-04-03T22:00:00.0Z
  S:        2000-04-08T09:00:00.0Z

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

  S:       
  S:          2fooBAR
  S:       

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.

[Ballot comment]
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?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-unhandled-namespaces-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns namespace on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: epp:unhandled-namespaces-1.0
URL: urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at:

https://www.iana.org/assignments/epp-extensions/

a single, new extension will be registered as follows:

Name of Extension: Extensible Provisioning Protocol (EPP) Unhandled Namespaces
Document Status: Standards Track
Reference: [ RFC-to-be ]
Registrant: IESG
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-09):

From: The IESG
To: IETF-Announce
CC: David Smith , barryleiba@gmail.com, draft-ietf-regext-unhandled-namespaces@ietf.org, dsmith@verisign.com, regext-chairs@ietf.org, regext@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extensible Provisioning Protocol (EPP) Unhandled Namespaces) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Extensible Provisioning
Protocol (EPP) Unhandled Namespaces'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,
  includes a method for the client and server to determine the objects
  to be managed during a session and the object extensions to be used
  during a session.  The services are identified using namespace URIs,
  and an "unhandled namespace" is one that is associated with a service
  not supported by the client.  This document defines an operational
  practice that enables the server to return information associated
  with unhandled namespace URIs that is compliant with the negotiated
  services defined in RFC 5730.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/



No IPR declarations have been submitted directly on this I-D.

Shepherd writeup
draft-ietf-regext-unhandled-namespaces-06

Technical Summary
===

This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730, occasioned by the handling of certain poll messages.

Working Group Summary
===

draft-ietf-regext-unhandled-namespaces-06 is on standards track as an Applicability Statement, having originally been considered as a BCP.  It specifies a way for a server to return data to a client when the server knows that the data's namespace was not specified as being supported by the client (via the client's negotiated login services). The server accomplishes this by embedding the unhandled-namespace information into  elements in its responses. Because the server's responses conform to RFC 5730, these responses will pass any client's strict XML parsing while also delivering the unhandled-namespace data for the client to consume (or ignore) as it sees fit.

There remains a difference of opinion on whether the draft will incur "interoperability problems" with respect to the way RFC5730 describes  and  elements. Specifically, the concern is whether clients will neglect to capture the  data returned in an unhandled-namespaces response due to those clients receiving a "success" response code when they had expected to look at the  only in cases of an "error" response code. To address these concerns, the draft now includes an Implementation Considerations section with guidance for both clients and servers.

Document Quality
===

This document has been discussed on the regext mailing list, and its authors have repeatedly edited the document to address concerns. The document now includes an "Implementation Considerations" section to provide specific guidance to both clients and servers to reduce any  operational impacts of the processes described in the draft.


Personnel
===

Document shepherd is David Smith: dsmith@verisign.com
Area Director is Barry Leiba: barryleiba@computer.org

Shepherd Comments
===

As document shepherd I have verified all of the XML examples against
the XML schema included in this document.

As mentioned in the "Working Group Summary," above, the "Implementation Considerations" portion of the document points to important information for servers and clients. I don't know whether the draft should somehow place more emphasis on this section, or how it would do so, but the mailing-list participants seem to be fine with its inclusion, placement, and level of emphasis.

The move from BCP to standards track resulted from the September 16, 2020, mailing-list discussion of such. There, Scott Hollenbeck stated that:

  "If we as a community can't agree that the documents describe best current practices, then it might not be appropriate for them to be published as BCPs. I'd feel more comfortable with publication on the standards track as technical specifications ("A Technical Specification is any description of a protocol, service, procedure, convention, or format") as described in Section 3.1 of RFC 2026."

This statement elicited a positive response.

The authors have confirmed that they've followed BCP78 and BCP79. No IPR disclosures have been submitted for this document.

All normative and informative references have been verified.

As document shepherd I believe this document is ready for publication.

Shepherd writeup
draft-ietf-regext-unhandled-namespaces-06

Technical Summary
===

This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730, occasioned by the handling of certain poll messages.

Working Group Summary
===

draft-ietf-regext-unhandled-namespaces-06 is on standards track -- after having been developed as a BCP -- and it specifies a way for a server to return data to a client when the server knows that the data's namespace was not specified as being supported by the client (via the client's negotiated login services). The server accomplishes this by embedding the unhandled-namespace information into  elements in its responses. Because the server's responses conform to RFC 5730, these reponses will pass any client's strict XML parsing while also delivering the unhandled-namespace data for the client to consume (or ignore) as it sees fit.

There remains a difference of opinion on whether the draft will incur "interoperability problems" with respect to the way RFC5730 describes  and  elements. Specifically, the concern is whether clients will neglect to capture the  data returned in an unhandled-namespaces response due to those clients receiving a "success" response code when they had expected to look at the  only in cases of an "error" response code. To address these concerns, the draft now includes an Implementation Considerations section with guidance for both clients and servers.

Document Quality
===

This document has been discussed on the regext mailing list, and its authors have repeatedly edited the document to address concerns. The document now includes an "Implementation Considerations" section to provide specific guidance to both clients and servers to reduce any  operational impacts of the processes described in the draft.


Personnel
===

Document shepherd is David Smith: dsmith@verisign.com
Area Director is Barry Leiba: barryleiba@computer.org

Shepherd Comments
===

As document shepherd I have verified all of the XML examples against
the XML schema included in this document.

As mentioned in the "Working Group Summary," above, the "Implementation Considerations" portion of the document points to important information for servers and clients. I don't know whether the draft should somehow place more emphasis on this section, or how it would do so, but the mailing-list participants seem to be fine with its inclusion, placement, and level of emphasis.

The move from BCP to standards track resulted from the September 16, 2020, mailing-list discussion of such. There, Scott Hollenbeck stated that:

  "If we as a community can't agree that the documents describe best current practices, then it might not be appropriate for them to be published as BCPs. I'd feel more comfortable with publication on the standards track as technical specifications ("A Technical Specification is any description of a protocol, service, procedure, convention, or format") as described in Section 3.1 of RFC 2026."

This statement elicited a positive response.

The authors have confirmed that they've followed BCP78 and BCP79. No IPR disclosures have been submitted for this document.

All normative and informative references have been verified.

As document shepherd I believe this document is ready for publication.

Shepherd writeup
draft-ietf-regext-unhandled-namespaces-06

Technical Summary
===

This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730, occasioned by the handling of certain poll messages.

Working Group Summary
===

draft-ietf-regext-unhandled-namespaces-06 is on standards track -- after having been developed as a BCP -- and it specifies a way for a server to return data to a client when the server knows that the data's namespace was not specified as being supported by the client (via the client's negotiated login services). The server accomplishes this by embedding the unhandled-namespace information into  elements in its responses. Because the server's responses conform to RFC 5730, these reponses will pass any client's strict XML parsing while also delivering the unhandled-namespace data for the client to consume (or ignore) as it sees fit.

There remains a difference of opinion on whether the draft will incur "interoperability problems" with respect to the way RFC5730 describes  and  elements. Specifically, the concern is whether clients will neglect to capture the  data returned in an unhandled-namespaces response due to those clients receiving a "success" response code when they had expected to look at the  only in cases of an "error" response code. To address these concerns, the draft now includes an Implementation Considerations section with guidance for both clients and servers.

Document Quality
===

This document has been discussed on the regext mailing list, and its authors have repeatedly edited the document to address concerns. The document now includes an "Implementation Considerations" section to provide specific guidance to both clients and servers to reduce any  operational impacts of the processes described in the draft.


Personnel
===

Document shepherd is David Smith: dsmith@verisign.com
Area Director is Barry Leiba: barryleiba@computer.org

Shepherd Comments
===

As document shepherd I have verified all of the XML examples against
the XML schema included in this document.

As mentioned in the "Working Group Summary," above, the "Implementation Considerations" portion of the document points to important information for servers and clients. I don't know whether the draft should somehow place more emphasis on this section, or how it would do so, but the mailing-list participants seem to be fine with its inclusion, placement, and level of emphasis.

The move from BCP to standards track resulted from the September 16, 2020, mailing-list discussion of such. There, Scott Hollenbeck stated that:

  "If we as a community can't agree that the documents describe best current practices, then it might not be appropriate for them to be published as BCPs. I'd feel more comfortable with publication on the standards track as technical specifications ("A Technical Specification is any description of a protocol, service, procedure, convention, or format") as described in Section 3.1 of RFC 2026."

This statement elicited a positive response.

The authors have confirmed that they've followed BCP78 and BCP79. No IPR disclosures have been submitted for this document.

All normative and informative references have been verified.

As document shepherd I believe this document is ready for publication.

Shepherd writeup
draft-ietf-regext-unhandled-namespaces-06

Technical Summary
===

This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730, occasioned by the handling of certain poll messages.

Working Group Summary
===

draft-ietf-regext-unhandled-namespaces-06 is on standards track -- after having been developed as a BCP -- and it specifies a way for a server to return data to a client when the server knows that the data's namespace was not specified as being supported by the client (via the client's negotiated login services). The server accomplishes this by embedding the unhandled-namespace information into  elements in its responses. Because the server's responses conform to RFC 5730, these reponses will pass any client's strict XML parsing while also delivering the unhandled-namespace data for the client to consume (or ignore) as it sees fit.

There remains a difference of opinion on whether the draft will incur "interoperability problems" with respect to the way RFC5730 describes  and  elements. Specifically, the concern is whether clients will neglect to capture the  data returned in an unhandled-namespaces response due to those clients receiving a "success" response code when they had expected to look at the  only in cases of an "error" response code. To address these concerns, the draft now includes an Implementation Considerations section with guidance for both clients and servers.

Document Quality
===

This document has been discussed on the regext mailing list, and its authors have repeatedly edited the document to address concerns. The document now includes an "Implementation Considerations" section to provide specific guidance to both clients and servers to reduce any  operational impacts of the processes described in the draft.


Personnel
===

Document shepherd is David Smith: dsmith@verisign.com
Area Director is Barry Leiba: barryleiba@computer.org

Shepherd Comments
===

As document shepherd I have verified all of the XML examples against
the XML schema included in this document.

As mentioned in the "Working Group Summary," above, the "Implementation onsiderations" portion of the document points to important information for servers and clients. I don't know whether the draft should somehow place more emphasis on this section, or how it would do so, but the mailing-list participants seem to be fine with its inclusion, placement, and level of emphasis.

The move from BCP to standards track resulted from the September 16, 2020, mailing-list discussion of such. There, Scott Hollenbeck stated that:

  "If we as a community can't agree that the documents describe best current practices, then it might not be appropriate for them to be published as BCPs. I'd feel more comfortable with publication on the standards track as technical specifications ("A Technical Specification is any description of a protocol, service, procedure, convention, or format") as described in Section 3.1 of RFC 2026."

This statement elicited a positive response.

The authors have confirmed that they've followed BCP78 and BCP79. No IPR disclosures have been submitted for this document.

All normative and informative references have been verified.

As document shepherd I believe this document is ready for publication.