Patrick,
Thank you for providing your approach proposal. I restructured the Registry
Mapping and Launch Phase Policy Extension schemas and samples to see how it
would work. I found your proposal to be elegant, but in the end I don't
believe that it's the path that we should go. After trying out both
approaches, I believe that defining a single Registry Mapping EPP object
extension along with an extensible set of command / response extensions, per
the extensibility built into EPP, as being the best path forward based on the
following reasons:
1. No additional extension mechanism is needed
* Clients and servers would be required to support a Registry Mapping
specific extension mechanism to support a pluggable set of Registry Mapping
Policy Definitions.
2. EPP clients and servers are capable of negotiating the supported XML
namespaces
* There is no support in the EPP greeting or login command to define the
supported Registry Mapping Policy Definition XML namespaces, since the object
and extension services identify true EPP extensions.
3. A single Registry Mapping XML namespace is simpler
* Splitting the single Registry Mapping XML Namespace into a Registry
Mapping Namespace with 5 policy XML Namespaces is more complex.
4. EPP is an XML document
* EPP does not represent a bootstrapping issue.
Overall, I don’t see a compelling argument for restructuring the Registry
Mapping.
—
JG
James Gould
Distinguished Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 7/25/18, 3:10 AM, "regext on behalf of Patrick Mevzek"
<[email protected] on behalf of [email protected]> wrote:
On Tue, Jul 17, 2018, at 09:33, Patrick Mevzek wrote:
> https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry
I have hinted in the past that I believe another structure for the XML
piece of data about zone policies could provide more benefits, such as:
- by not having parts of the information inside an EPP extension under
<extension>, but everything in the same document it means the document can be
published as is; I think this can help resolve the bootstrap problem discussed
during the meeting as the XML document, both its "core" part defined by this
draft and all extensions inside of it defined by other drafts, could be
published as is under whatever channel the registry decides, for example HTTPS,
on a public or authenticated website depending on its own wishes.
- by doing so you reduce the risk of having multiple registries implement
the same extension to encore the same policy (ex: what are the extra attributes
for a contact, if they are the same between the 2 registries) in different
documents with different namespaces
- you simplify the writing of extensions, there is much less boilerplate
coming from just the fact that you need to reuse EPP extension framework.
So here is my proposal, first the current (simplified) structure to have a
base to compare to, and then my suggestion which can be refined in many ways,
and specifically the naming of attributes.
I believe that in such way the core document is not held up by any future
extensions, as it just define how to add extensions, with an unlimited number
of unorderer slots, one per policy group (each group tied to a specific XML
namespace, hence a specific document)
CURRENT DOCUMENT
<registry:zone>
<registry:name>...
<registry:group>...
<registry:services>...
<registry:svcExtension>...
....
<registry:domain>
... all policies related to domains, including RGP and DNSSEC
</registry:domain>
<registry:host>
... all policies related to hosts
</registry:host>
<registry:contact>
... all policies related to contacts
</registry:contact>
</registry:zone>
ALTERNATIVE PROPOSAL
<registry:zone>
<registry:name>...
<registry:group>...
....
<registry:policies for="urn:ietf:params:xml:ns:epp-1.0">
... all policies regarding session commands, login, poll, etc.
previous registry:services and registries:svcExtension would be there
</registry:policies>
<registry:policies for="urn:ietf:params:xml:ns:domain-1.0">
... all policies regarding domains
</registry:policies>
<registry:policies for="urn:ietf:params:xml:ns:host-1.0">
... all policies regarding hosts, absent if hosts are attributes
</registry:policies>
<registry:policies for="urn:ietf:params:xml:ns:contact-1.0">
... all policies regarding contacts
</registry:policies>
<registry:policies for="RFC5734">
... everything related to the transport, if needed
(not sure about that, or if this can be in the first registry:policies
block
with RFC5730 data; I am not fond of the namming either in this case)
</registry:policies>
<registry:policies for="urn:ietf:params:xml:ns:secDNS-1.1">
... all policies regarding DNSSEC, if supported by registry
</registry:policies>
<registry:policies for="urn:ietf:params:xml:ns:rgp-1.0">
... all policies regarding RGP, if supported by registry
</registry:policies>
<registry:policies for="urn:ietf:params:xml:ns:launch-1.0">
... all policies regarding launchphase,
instead of a separate launch-policy extension document
</registry:policies>
<registry:policies for="http://someregistry.example/epp/localExtension";>
... all policies regarding this registry specific EPP extension
</registry:policies>
</registry:zone>
--
Patrick Mevzek
[email protected]
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
