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
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
