Subject: [regext] Tidbits after monday meeting, related to registry mapping extension

From: Patrick Mevzek <[email-masked]>
Date: Tue, 17 Jul 2018 09:33:13 +0200

https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry

Multiple subjects were covered and I had to input some data, so I will be doing different topics by replying to this email so that they are threaded together. You may wish to read all of them for context before replying to any.

I only took a quick read of some documentation I currently have on hand for some registries, and this is far from exhaustive. I am not putting the registry names as I do not think that changes anything, but you will have to trust my word that I am not making up cases. Otherwise, the registry that recognize themselves could also speak up and say if they would deploy this extension.

Like I said, to be a success, this extension needs to be widespread. It needs to be made in such a way that it can encompass very different cases. And for the one point specifically raised (control over the contact IDs, while the RFC may say there are completely under control of registrar, in practice for many ccTLDs registries it is the registry that choose the ID at creation, irrespective to what the registrar asks for), it needs to be easy to derive it separately in an extension for deviations from base.

In fact, here is a generic comment: I think there is already things belonging in an extension that are indeed in the base document, so that should be split.
For example, about contact types, while it is obvious that there are other ones on the wild, RFC5731 defines only 3, and not "custom". So custom should be dropped from core document. Same for privacy/proxy these concepts are not in RFC5733, and should be handled in extensions.

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 17 Jul 2018 09:36:30 +0200

I discovered this myself just before the meeting when preparing it but Scott also clearly mentioned it during the meeting (thanks for that): there is currently an IPR on this extension, with the case of "details will be provided later".

You may recall that we were in a similar case for the keyRelay extension, and it got delayed because at some point noone knew anymore who was waiting on what and then discussions were needed to decide if going through or still waiting on the full IPR.

I would prefer if the same situation does not repeat itself, so I am just wondering what can be done to make that going smoothly?

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 17 Jul 2018 09:37:49 +0200

Specific points related to RFC5730:

* clTRID is optional; but some registries make it mandatory
* some registries do not allow some commands, like contact:transfer being not implemented (this is very frequent)
or even sometimes contact:check (especially if registrars do not control their IDs), or other operations.
Should that be specified somehow?
* for domain:info you have the hosts boolean with 3 values, not all registries are supporting all 3 cases.

* also, some commands, like updates may always be asynchronous (return code 1001), should that be specified?

* for authInfo: <registry:authInfoRegEx>:  The OPTIONAL regular expression used
           to validate the domain object authorization information
           value.
I do not think again that a regext will solve all problems. For example some registries say:
with at least one uppercase and one digit and one "special" character. This is hard to express in a regex
as the position does not matter.

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 17 Jul 2018 09:40:48 +0200

* contacts, the extension has:
 <registry:contact>:  Zero or more <registry:contact> elements
           that defines the minimum and maximum number of contacts by
           contact type.

This will not cover all cases, like those:
- admin contact is optional and falls back to registrant
- since you allow for custom type (and I disagree with that here), some registries have other contact types,
let us say "other" and have rules like: at least one contact of type technical or other.

* about periods, there are 2 cases not handled:

- something around maximum expiration date, like the ICANN rule on 10 years max and what happens for
commands that would go beyond that (ex: create for 9 years and immediate renewal for 5)
- how is the new expiration date computed after a transfer: for some registries it is like a start of a new
contract, hence the expiration is the date of transfer + 1 year
In the same way, sometimes a registrant change (often through a separate command) is deemend to be a new contract
starting at the command time, hence it changes the expiration.

How could we encode these expiration rules?

* about secDNS, one registry has this:
keyData only, flags muts be 257, protocol 3 and any algorithm.
While indeed protocol 3 is the only value possible, the secDNS extension
could allow other value for flags even if 257 is the only one making sense, and the only one used in examples.
Should we care to codify these limits?
Things may be different with CDS/CDSNKEY, I am not sure.

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 17 Jul 2018 09:43:46 +0200

* int/loc
The current 4 values in the draft (loc, int, locOrInt, locAndInt) should be replaced by 3 independant booleans:
loc = loc only
int = int only
locAndInt = loc+int only

With combinations, that will makes us available to encode all cases I think:
- wide registries accepting every case (so all 3 booleans to yes)
- cases with loc only or int only (very frequent in ccTLDs)
- edge cases like int only or loc+int but not loc only.

What happens when registrar sends here an information the registry does not want (like sending loc+int
where the registry wants only loc)? I see two cases: the registry generates an error or the registry
drops (ignores) the part it does not need. Should that be encoded in the extension?

Also the RFC5733 says "If a
      localized form (type="loc") is provided, element content MAY be
      represented in unrestricted UTF-8."
some registries do restrict the set of characters allowed,
so should that  be encoded there?

One registry says: "loc preferred if country is local ccTLD one, otherwise int preferred"
I have no idea what preferred means here and how this could be encoded, if needed.

* contact:id format, the extension has:

<registry:contactIdRegEx>:  The OPTIONAL regular expression used
           to validate the <contact:id> element defined in [RFC5733].

I do not think this covers all cases. For example some registry gives each registrar a prefix
and all contact IDs of this registrar must start with the given prefix. But it is different per registrar.
How to encode that policy?
Or cases like: "at least one upper case character". This can very fast provoke explosion of combinations
if only written by a regex

* contact:sp : one registry has this rule "if the contact is in country X - the registry country - then
the <sp> should be the 2 letters code of the nation provices", that is not free form.

* privacy/proxy: the extension has:
       <registry:privacyContactSupported>:  An OPTIONAL boolean value
           that indicates whether a privacy contact is supported with a
           default value of "true".
       <registry:proxyContactSupported>:  An OPTIONAL boolean value that
           indicates whether a proxy contact is supported with a default
           value of "true".

this is however completely germane to RFC5733 so I believe this should not be there, but in an extension.

* disclose is optional per RFC7333. Many registries ignore it.
Again you have the same problem as above: some registries may just ignore it, other may reply an error if it
is not allowed but present. The extension should code both cases.
As a generic note I dislike renaming fields for no reason, RFC5733 uses "disclose" for this, the extension
should use the same name, and not "Disclosure".
Also things are not homogeneous. You have voiceRequired vs clientDisclosureSupported. I see no reason
for the differences, voice and disclose are at same level in the contact object and why Required vs Supported?

* contact:authInfo is not supported by some registries, like contact:id
Should that be handled or left to an extension?

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 17 Jul 2018 09:44:43 +0200

* some registries allow, in domain:create, either attributes or objects for host.
One might say this is against the core EPP specification, so do we want to treat it?

* some registries do not allow all possible values for IP addresses. For example one is saying that it will
refuse any IP provided if it is in  RFC 1918 or 3330 or 3927 or 4193 or 3879.
Of course other registries may have the same exclusion list or another. So that should be expressed.

* one registry has this: at most 4 IP addresses but at least one IPv4 if some are provided.
Which means you can not solve this even by just min+max for both IPv4 or IPv6
Because IPv4 min is 1 if IPv6 is present, otherwise 0. You can not say min=0 always because
then it will allow a set with only one IPv6 address, which the registry disallow.

* again around operations possible/not possible, one registry says for example: host:name can not be updated
if it would then become a glue without any IP or become an external host with an IP.

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Tue, 17 Jul 2018 11:11:50 +0000

Patrick,

Thank you for your detailed feedback.  We'll take a look at your following messages.  I believe the goal of the Registry Mapping is to hit on the most common use cases and leave exceptional cases up to extensions (the 80/20 or 90/10 rule).  If there is a crosscutting policy being applied across many registries then it is a good candidate for inclusion directly within the Registry Mapping.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 7/17/18, 3:33 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    -- 
      Patrick Mevzek
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 17 Jul 2018 14:25:47 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Patrick Mevzek
> Sent: Tuesday, July 17, 2018 3:37 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] Tidbits after monday meeting, related to
> registry mapping extension => IPR
>
> I discovered this myself just before the meeting when preparing it but
> Scott also clearly mentioned it during the meeting (thanks for that):
> there is currently an IPR on this extension, with the case of "details
> will be provided later".
>
>
> You may recall that we were in a similar case for the keyRelay extension,
> and it got delayed because at some point noone knew anymore who was
> waiting on what and then discussions were needed to decide if going
> through or still waiting on the full IPR.
>
> I would prefer if the same situation does not repeat itself, so I am just
> wondering what can be done to make that going smoothly?

It would be helpful if I could provide a measure of implementation interest to my corporate attorneys. That would help them come up with an appropriate declaration.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 20 Jul 2018 19:04:34 +0000

Patrick,

There is no intention to request for this to be a working group document until the IPR declaration is defined.  We already provided the IPR disclosure.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 7/17/18, 3:36 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    -- 
      Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Fri, 20 Jul 2018 19:31:45 +0000

Patrick,

Thank you for this information.  I provide feedback embedded below.  Our goal is to address the crosscutting policy choices, so it's important to understand how many registries implement the policies (many, some, few, or just one), where "just one" or potentially a "few" may be best suited for the registry or registries to define a policy extension.   

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 7/17/18, 3:38 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

JG - Does this apply to all commands sent to the registry system or is it a policy that applies at the zone-level (e.g., .FOO requires the clTRID but .BAR does not require the clTRID)?  The reason that I ask is to determine where such a policy would be defined at the system-level or at the zone-level.  How many registries implement this policy (many, some, few, or just one)?  

JG-yes, I can see this.  I assume this policy would be classified as "many".  It may make sense to add a <registry:supportedCommands> element that supports an "all=<boolean>" attribute along with a list of sub-elements to identify which commands are supported.  Such an element would be used under each of the objects (domain, host, contact).  In draft-gould-regext-launch-policy, the policy associated with the check forms and create forms supported by the zone kind of matches this use case for the operations supported by RFC 8334.  

JG- How many registries implement the policy of support for a subset of the "hosts" values in RFC 5731 (many, some, few, or just one)?  If this needs to be added, I would imagine  that we would need to include a list of the supported host values; although this is certainly not compliant with RFC 5731.  

JG-I believe it's good enough to include "pendingUpdate" in the list of <registry:status> sub-elements of the <registry:supportedStatus> element.  The client then knows that an update may result in a pendingUpdate.

JG-A regular expression can precisely define the required syntax.  Yes it may be hard, but a client can directly pull the regular expression for execution on their side.  I would like to hear from a registry that can't express their policy without the use of a regular expression.  

    -- 
      Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Fri, 20 Jul 2018 19:49:50 +0000

Patrick,

Again, thanks for providing the detailed information.  I provide my feedback embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 7/17/18, 3:41 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

JG-Can you provide a propose of how to define this?  The use of "custom" is a pattern that has been followed elsewhere to enable an extensible set of values.  If a registry does have "other" or "custom" contact types, they can fully define the min and max policies for their custom contact type.  

JG-What are the possible set of policies out in the wild?  We clip the fractional period past the maximum year (10.5 years would become 10 years and attempting to go 11 or more years would fail).  

JG-You mean the transfer is not treated as a renewal and sets a new expiration date independent of the expiration date prior to the transfer?  How many registries do this (many, some, few, or just one)?  

JG-You mean a domain update can result in changing the expiration date if the registrant is changed?  How many registries do this (many, some, few, or just one)?  We may not include such a policy in draft-gould-carney-regext-registry, where this would be left to the registry to define their own policy extension.    

JG-We will need to take a closer look at this one.  I don't have any immediate thoughts for this.  

    -- 
      Patrick Mevzek

---

From: Ben McIlwain <[email-masked]>
Date: Fri, 20 Jul 2018 17:36:53 -0400

On Fri, Jul 20, 2018 at 3:31 PM Gould, James <jgould=
[email-masked]> wrote:

> JG-A regular expression can precisely define the required syntax.  Yes it
> may be hard, but a client can directly pull the regular expression for
> execution on their side.  I would like to hear from a registry that can't
> express their policy without the use of a regular expression.
>
>
Here's a regex that enforces some common password requirements:

^(?:(?=.*[a-z])(?:(?=.*[A-Z])(?=.*[\d\W])|(?=.*\W)(?=.*\d))|(?=.*\W)(?=.*[A-Z])(?=.*\d)).{8,}$

That requires at least 8 characters and at least three different types of
the following characters: lowercase, uppercase, digits, and punctuation.

I don't know if this is a road we want to go down.  For the required
complexity of regexes needed to validate passwords, regex dialect really
does matter, so if e.g. someone is using Perl regexes and you're running on
Java, you can't easily just "pull the regex and run it locally".

And in response to the original message ... booleans cannot have three
possible values!

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 21 Jul 2018 02:02:30 +0200

> And in response to the original message ... booleans cannot have three

Thanks Ben, you were probably replying to:
"* for domain:info you have the hosts boolean with 3 values, not all registries are supporting all 3 cases."

which indeed even at 2:38 AM is sloppy, so let me try to rephrase that, even if I am sure that everyone fixed it already:

in RFC5731 you have this explanation for a domain:info
(so I should put that in the other thread in fact, mea culpa)
" An OPTIONAL "hosts" attribute is
      available to control return of information describing hosts
      related to the domain object.  A value of "all" (the default,
      which MAY be absent) returns information describing both
      subordinate and delegated hosts.  A value of "del" returns
      information describing only delegated hosts.  A value of "sub"
      returns information describing only subordinate hosts.  A value of
      "none" returns no information describing delegated or subordinate
      hosts."

(so in fact it is 4 values, not 3, even less a boolean I guess :-))

Not all registries accept all of these values (again you can argue they are not following the standard, I am not judging that in one way or another just letting people know what exists really today), so you might want to track that in the registry mapping.

Sorry again for my sloppiness at 2:38 AM.

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Jul 2018 12:42:59 +0000

Patrick,

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 7/17/18, 3:44 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    * int/loc

JG - I believe the only combination with the single postalInfoTypeSupport element does not cover is "int" being required and "loc" being optional.  Of course, the opposite is a possible scenario but highly unlikely.  Instead of creating three independent attributes that may not properly cover the exact policy, how about simply adding a fifth enumerated value of "intOptLoc", where the "int" is required and the "loc" is optional?  

JG - I believe that if something doesn't follow the defined policy, it should result in a failure.  If a server ignores data instead of failing a command due to not following the defined policy, then that would need to be defined a  higher level; although I don't believe ignoring data passed by the client is appropriate server behavior.  Maybe we can define a higher level zone-level element that defines how the server handles data that doesn't follow the policy (e.g., <registry:invalidData> with a value of "fail" or "ignore").  The registry should at a minimum be consistent in how invalid data.

JG - That is a good question.  How are the characters being restricted and how would those restrictions be represented?  This would come down the regular expression topic that we're having with other attributes.  

JG - The registry that defines "preferred" would need to better describe it since "preferred" may not come with any additional server behavior that the client needs to account for.  

JG - I really not sure what value a registry has in requiring a unique prefix per registrar for the contact:id element, but if this needed to be included then I would propose adding an optional <registry:contactIdPrefix> element.  The <registry:contactIdPrefix> could include the value "clientPrefix" with a description that states that the contact ID must be prefixed with a client specific prefix defined by the server.  The <registry:contactIdRegEx> could define the format independent of the prefix.

JG - That would be really difficult to communicate declaratively if the rule is derived from the value of a different element (e.g,. <contact:cc>).  So, this policy only applies if the <contact:cc> matches the country code of the registry?  

JG - These are elements added by GoDaddy, where support for privacy and proxy contacts are crosscutting policies that I believe do belong.       

JG - The reason for Disclosure instead of disclose in <registry:clientDisclosureSupported> is because we're talking about the Disclosure policy of RFC 5733, as in "Disclosure of Data Element and Attribute".  Required defines an optional element as required, and supported defines whether an optional element is allowed or accepted.  I have the same comment about what the server does with invalid data (e.g., invalid according to the policy), where it is best to define the policy at a higher level with the expectation that the server handles invalid data consistently.  

JG - The contact:authInfo is a required element per RFC 5733, so I believe that defining the lack of support of a required RFC element be left up to a registry-specific policy extension.  I assume that you're not proposing removing the definition of the contact:authInfo policy in the Registry Mapping because some registries have decided not to support it.  
    
    -- 
      Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Jul 2018 13:08:19 +0000

Patrick,

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 7/17/18, 3:45 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

JG - RFC 5731 states "A server operator MUST use one name server specification form consistently", so if a registry does support more than one form it should define that policy in a server-specific policy extension.  

JG - Good point, there are invalid IP ranges.  I don't believe we want to embed the list of invalid IP ranges within the Registry Mapping, but it may make sense to enable referencing an external resource (e.g., URL) that does define it.  

JG - This is a very unique policy that is best met by the registry to defined a server policy extension.  

JG - Doesn't the policies defined for an internal and external host already cover this?  If there is a host update that changes an internal host to an external host, or vice-versa, the new host must follow the appropriate defined policy.  
    
    -- 
      Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 25 Jul 2018 09:10:32 +0200

> 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-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 30 Jul 2018 15:55:23 +0000

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-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 7/25/18, 3:10 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    CURRENT DOCUMENT

    <registry:zone>

      <registry:name>...

      <registry:group>...

      <registry:services>...

    ....

      <registry:domain>

      </registry:domain>

      <registry:host>

      </registry:host>

      <registry:contact>

      </registry:contact>

    </registry:zone>

    ALTERNATIVE PROPOSAL

    <registry:zone>

      <registry:name>...

      <registry:group>...

    ....

      </registry:policies>

      </registry:policies>

      </registry:policies>

      </registry:policies>

      </registry:policies>

      </registry:policies>

      </registry:policies>

      </registry:policies>

      </registry:policies>

    </registry:zone>

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]