Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Pieter Vandepitte]

Did anyone consider RFC 6321 (xcal)? It has features like recurrences too. A 
maintenance event is basically just a calendar event + some data about the 
scope/context...

Kind regards

-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be 
 

 
 

On 10/08/18 00:08, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 11, 2018, at 15:48, Gould, James wrote:
> More specifically now, about "2.3.  Schedule" I am *strongly* 
> against using the format proposed for at least 2 reasons:
> - crontab format is not a standard, and is ambiguous for various 
> points
> - it encodes a format as a string which is itself in a formatted 
> structure since it is XML. "Hijacking" some free form space when you are 
> in formatted structure seems wrong to me and shows that the structure is 
> not correctly formatted because if it were you would not have to inject 
> a new format in a free text.
> 
> Why not use ISO8601 Repeated Time Interval format? We are then still 
> gulty of the previous point but at least it is a standard.
> Otherwise please amend the XML structure to break the content 
> currently in the crontab format.

Another way of encoding that, without judging myself if it is 
good/bad/better or worse than others but just to open horizons and see what is 
out there since I just stumbled upon it for unrelated reasons, is the systemd 
way, as described on 
https://www.freedesktop.org/software/systemd/man/systemd.time.html

With this example:

Thu,Fri 2012-*-1,5 11:12:13

The above refers to 11:12:13 of the first or fifth day of any month of the 
year 2012, but only if that day is a Thursday or Friday.

HTH,

-- 
  Patrick Mevzek
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Patrick Mevzek]

On Mon, Jun 11, 2018, at 15:48, Gould, James wrote:
> More specifically now, about "2.3.  Schedule" I am *strongly* 
> against using the format proposed for at least 2 reasons:
> - crontab format is not a standard, and is ambiguous for various 
> points
> - it encodes a format as a string which is itself in a formatted 
> structure since it is XML. "Hijacking" some free form space when you are 
> in formatted structure seems wrong to me and shows that the structure is 
> not correctly formatted because if it were you would not have to inject 
> a new format in a free text.
> 
> Why not use ISO8601 Repeated Time Interval format? We are then still 
> gulty of the previous point but at least it is a standard.
> Otherwise please amend the XML structure to break the content 
> currently in the crontab format.

Another way of encoding that, without judging myself if it is good/bad/better 
or worse than others but just to open horizons and see what is out there since 
I just stumbled upon it for unrelated reasons, is the systemd way, as described 
on 
https://www.freedesktop.org/software/systemd/man/systemd.time.html

With this example:

Thu,Fri 2012-*-1,5 11:12:13

The above refers to 11:12:13 of the first or fifth day of any month of the year 
2012, but only if that day is a Thursday or Friday.

HTH,

-- 
  Patrick Mevzek
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Mario Loffredo]

Hi James,
my  answers to your questions are below.

Regards,
Mario

Il 16/07/2018 04:24, Gould, James ha scritto:


Mario,

In reviewing the mailing list feedback on 
draft-gould-carney-regext-registry, I missed your feedback.  Thanks 
for taking the time to review draft-gould-carney-regext-registry and 
provide your feedback.  I provide responses to your feedback below.


—

JG


cid:image001.png@01D255E2.EB933A30

*James Gould
*Distinguished Engineer
jgo...@verisign.com

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

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

*From: *regext  on behalf of Mario Loffredo 


*Date: *Thursday, June 7, 2018 at 10:40 AM
*To: *Roger Carney , regext 
*Subject: *[EXTERNAL] Re: [regext] New Version Notification for 
draft-gould-carney-regext-registry-00.txt


Hi Roger,

I couldn't attend the last Interim Meeting so I apologise if some 
comments below could be obsolete:


1) According to section 1.1 of RFC 5731, a server cannot support the 
host object. So, even if the server implements a policy about IP 
addresses included in domain:hostAddr elements, it doesn't implement 
check (or any other) operation on hosts
Therefore, a minOccurs="0" attribute should be added to the element 
maxCheckHost of hostType.


Good point that draft-gould-carney-regext-registry may not properly 
support defining the policies for a zone that supports hostAddr 
instead of hostObj in RFC 5731.  We’ll take a closer look at how 
hostAddr can be supported in draft-gould-carney-regext-registry 
including the XML schema definition of maxCheckHost.




2) Why should supportedStatus only contain standard status ? The 
supportedStatusType definition is less strict than the description and 
this seems good to me because supportedStatusType can match custom 
status too.


It would be good to understand how custom statuses are supported to 
effectively define the policy for custom statuses.  Can you provide a 
description of how custom statuses are supported?  You are correct 
that the supportedStatusType is not an enumerated type, so therefore 
any status can be included.



In the same way the rgpStatus of RGP extension is supported. Usually, 
due to local regulations, custom statuses are applied to domains and 
affect the set of operations a client can request. I think that the 
Registry Mapping extension would be very helpful if servers could 
provide clients with a formal description of the operations clients are 
allowed to request on a domain according to their statuses, no matter 
the statuses are standard or custom. IMHO, the only reference of the 
extension declaring the custom statuses in the registry:svcExtension 
element would not be enough.

I hope this could clarify my previous statement.



3) The description of expiryPolicy contains the following sentence:

"autoRenew": The domain object will auto-renew at expiry.
  The client can receive a credit for the 
auto-renew if the
                         domain object is deleted within the 
auto-renew grace period."


Does it make sense to replace "if the domain object is deleted" with 
"if the domain object is deleted or transferred" ?


Yes, adding “or transferred” to the description makes sense for the 
auto-renew grace period.



4) Considering that RFC 5730 defines a response code returned when a 
server receives an unimplemented command (i.e. 2101) , maybe it's 
worth to add information about unimplemented operations.


Good point, we can put some thought into how to define this.


5) In my opinion, the schedule format has some limits. Java EE Timer 
expressions 
(https://docs.oracle.com/javaee/7/tutorial/ejb-basicexamples004.htm) 
seem to be more flexible especially regarding dayOfMonth values:


1 to 31. For example: dayOfMonth="15".

–7 to –1 (a negative number means the /n/th day or days before the end 
of the month). For example: dayOfMonth="–3".


Last. For example: dayOfMonth="Last".

[1st, 2nd, 3rd, 4th, 5th, Last] [Sun, Mon, Tue, Wed, Thu, Fri, Sat]. 
For example: dayOfMonth="2nd Fri".


The schedule format was our first attempt, so we can consider your 
proposal as well.




6) Finally, I hope that in the future the draft will address the 
mapping of the possible extensions described in RFC 5730.


I’m unsure what you mean by “mapping of the possible extensions 
described in RFC 5730”.  Can you describe this a little more?



This answer is strictly related to the previous one of point 2. 
According to RFC5730 there could be three kinds of extensions.  By the 
term "extensions", I mean both the custom extensions (applied only to a 
specific registry) and  new standardized extensions (completing in the 
future the standardization process). Both could deeply affect the server 
policy.
Just to give you an example,  the Login Security extension is currently 
under the WG evaluation. If it will complete the standar

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Gould, James]

Patrick,

My replies are embedded below.
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 7/16/18, 3:14 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 11, 2018, at 15:48, Gould, James wrote:
> JG - Why does the extension data need to reside within the 
>  node?  EPP already has an extension mechanism that 
> can be used, so why not use it in this case? 

I have two reasons for this.
The first one being that the XML document in itself can be useful, outside 
of the EPP protocol and design over how messages are exchanged.
If all (core + extensions) policies of a given registry are in one and some 
document, registrars can use it, for example, to process it and generate some 
code based on it. The XML document in this case, that is without any structure 
coming from EPP, could evevn be distributed out of band (one may argue that EPP 
being a *provisioning* protocol it is not the best to just send information and 
while you define the  command on this new structure, I doubt many EPP 
clients will implement or need to implement it).

The second reason is structure.
You decided to have domain/host/contact as "top" structure, hence mimicking 
the  3 RFCs about each of them. We can agree on that. But then, RGP and DNSSEC 
are their own RFCs and while they are purely related to domain names, it would 
not look strange to me that they are top elements themselves, like I wrote each 
RFC and/or namespace could be a top element grouping policies related to it.

This would also simplify the whole  content.

JG - The elements included in the draft ("top" structure) are directly 
associated with the existing mature EPP RFCs.  New EPP extensions (drafts and 
RFCs) that are defined can include or be associated with new policy extensions 
of the registry object.  The entire EPP command and response is a full XML 
document, so I don't see any advantage to creating a new extensibility point 
within the registry mapping to put policy extensions under the 
 element.  We should use the extensibility mechanism that is 
already defined in EPP.  

> JG - Maybe you can provide some sample XML that combines the policy for 
> a Registry Zone that supports what is in the Registry Mapping and in the 
> Launch Phase Policy Extension to help understand your proposal.  

I will try to do that based on other discussions of this draft, to see 
where the consensus goes to.

> Why not use ISO8601 Repeated Time Interval format? We are then still 
> gulty of the previous point but at least it is a standard.
> Otherwise please amend the XML structure to break the content 
> currently in the crontab format.
> 
> JG - The schedule can certainly be enhanced.  Can you propose an 
> alternative structure to define it?  

The current example

   
 pendingDelete
 Pending Delete Batch
 
 0 14 * * *
 
   

could be with ISO8601:

   
 pendingDelete
 Pending Delete Batch
 R/14:00:00-05:00/P1D
   



The EDT/EST switch may be a problem and would need two intervals maybe,
each for 6 months during the year (this can be done by start and stop date 
of the ISO8601 format)


On a related note, there may be a need here to also encode things such as: 
contacts not linked for 30 days are deleted from system
(which means processes that can not be anchored at a specific time)

  JG - I believe the format of the schedule is a good area for discussion, 
since use of the cron format was simply the first attempt.  Yes, policy 
associated with deletion of unused (unlinked) objects (contacts and hosts) is a 
good topic for inclusion.  
 
> As for timezones, all EPP standards always used UTC for all 
> timestamps (and even if some registries on the field do not respect 
> that), and I think it would be best to stick to that, so that removes 
> the "tz" attribute.
> 
> JG - Yes, that is the case for communicating dates (create date, 
> expiration date), but not the case when it comes to defining a schedule 
> for a batch component that runs based on a local time zone.  

I still think it is simpler to have UTC everywhere, this also makes 
registries fully aware that their operations are indeed international because 
some of their registrars may really be from the opposite side of the world.

But at least as long as the timezone is mandatory (and non ambiguous, which 
means only offsets from UTC, otherwise things like EST/EDT are ambiguous), is a 
step in the good direction.

JG-Yes UTC everywhere would make things simpler, but the reality is that there 
are registries that do run batches based on the local time zone.  

 

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Patrick Mevzek]

On Mon, Jun 11, 2018, at 15:48, Gould, James wrote:
> JG - Why does the extension data need to reside within the 
>  node?  EPP already has an extension mechanism that 
> can be used, so why not use it in this case? 

I have two reasons for this.
The first one being that the XML document in itself can be useful, outside of 
the EPP protocol and design over how messages are exchanged.
If all (core + extensions) policies of a given registry are in one and some 
document, registrars can use it, for example, to process it and generate some 
code based on it. The XML document in this case, that is without any structure 
coming from EPP, could evevn be distributed out of band (one may argue that EPP 
being a *provisioning* protocol it is not the best to just send information and 
while you define the  command on this new structure, I doubt many EPP 
clients will implement or need to implement it).

The second reason is structure.
You decided to have domain/host/contact as "top" structure, hence mimicking the 
 3 RFCs about each of them. We can agree on that. But then, RGP and DNSSEC are 
their own RFCs and while they are purely related to domain names, it would not 
look strange to me that they are top elements themselves, like I wrote each RFC 
and/or namespace could be a top element grouping policies related to it.

This would also simplify the whole  content.

> JG - Maybe you can provide some sample XML that combines the policy for 
> a Registry Zone that supports what is in the Registry Mapping and in the 
> Launch Phase Policy Extension to help understand your proposal.  

I will try to do that based on other discussions of this draft, to see where 
the consensus goes to.

> Why not use ISO8601 Repeated Time Interval format? We are then still 
> gulty of the previous point but at least it is a standard.
> Otherwise please amend the XML structure to break the content 
> currently in the crontab format.
> 
> JG - The schedule can certainly be enhanced.  Can you propose an 
> alternative structure to define it?  

The current example

   
 pendingDelete
 Pending Delete Batch
 
 0 14 * * *
 
   

could be with ISO8601:

   
 pendingDelete
 Pending Delete Batch
 R/14:00:00-05:00/P1D
   



The EDT/EST switch may be a problem and would need two intervals maybe,
each for 6 months during the year (this can be done by start and stop date of 
the ISO8601 format)


On a related note, there may be a need here to also encode things such as: 
contacts not linked for 30 days are deleted from system
(which means processes that can not be anchored at a specific time)


 
> As for timezones, all EPP standards always used UTC for all 
> timestamps (and even if some registries on the field do not respect 
> that), and I think it would be best to stick to that, so that removes 
> the "tz" attribute.
> 
> JG - Yes, that is the case for communicating dates (create date, 
> expiration date), but not the case when it comes to defining a schedule 
> for a batch component that runs based on a local time zone.  

I still think it is simpler to have UTC everywhere, this also makes registries 
fully aware that their operations are indeed international because some of 
their registrars may really be from the opposite side of the world.

But at least as long as the timezone is mandatory (and non ambiguous, which 
means only offsets from UTC, otherwise things like EST/EDT are ambiguous), is a 
step in the good direction.

> I find this unfortunate:
> :  The zone name that can be at any level
> 
> When you parse it, you read it as "a registry name", but then it is a 
> zone.
> So while it could probably not be  it should at least be
> .
>  
> JG- The label name could be changed, but I believe the most important 
> item is the meaning of the element.  Since the  element 
> is a sub-element of the  element, wouldn't it be 
> redundant to replicate the zone in the label () or 
> the namespace ()?  I don't believe defining a new namespace 
> will help here.  I believe leaving it as 
> EXAMPLE... 
> with a description of the  element as meeting the need.   

My problem is probably exacerbated by the use of "registry" as namespace alias. 
I believe both the name of the extension and hence its XML namespace should be 
changed.

> You are speaking about "regex" in various places without referencing 
> how is this formatted. There are multiple de facto regex "standards" so 
> care must be taken there to reference precisely what kind of regex are 
> manipulated.
> Also, for example for passwords, some registries policies are not 
> possible to express (only) in regex I think, so there might be a blind 
> spot here.
> 
> JG - Do you have a proposal of how to precisely define the regex?  I'm 
> looking for the other registries to review the draft and weigh in on how 
> they can effectively communicate their policies.

I think it would be important to specify 

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Gould, James]

Patrick,

Thank you for your review and feedback.  My comments are embedded below.
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/9/18, 3:39 AM, "Patrick Mevzek"  wrote:

On Fri, Jun 1, 2018, at 17:16, Roger D Carney wrote:
> We have been talking about Registry Mapping for over a year now and here 
> is the official first 
> draft >.
> 
> 
> 
> Please take a read and let the discussions flow! 

Some quick remarks before trying to implement it and hence reviewing it 
more in depth later.

First I think it is an important concept (auto-discovery), whatever the 
implementation is. It would be most useful if deployed by multiple registries, 
also outside of gTLDs, so even if not technical some outreach should be done to 
try finding registries willing to participate and/or deploy it later.
So that during desigining no spots are missed.

Also I think this is an extension that needs itself to be extended.
I have seen the other document about the launchphase policies but I think 
the model should be different, so that extension data is still inside the 
 node.

JG - Why does the extension data need to reside within the  
node?  EPP already has an extension mechanism that can be used, so why not use 
it in this case?  The Registry Mapping defines a Registry object with two 
separate sub-objects, which include Zone and System.  The Zone represents the 
RFC policies for an individual zone supported by the Registry.  The System 
represents the policies of the Registry System.  The Registry Mapping provides 
the base to define zone-level (e.g., Launch Phase Policy Extension or Registry 
Fee Policy Extension) or system-level (e.g., Login Security Policy Extension) 
extensions using the existing command / response EPP extension mechanism.  

Here is an outline of what I thought, so names are just examples:
among the nodes there would be a  one with a "for" attribute whose 
value would be the XML namespace of the extension concerned by the policies 
that will be described inside this policy node. So infData will be mostly a 
list of  nodes. The core document would define the blocks for RFC 5730 
to 5733 (and maybe also RGP and DNSSEC) and then each other extension would 
define their own block content.

Also, using the XML namespace as identifier may not be always possible: all 
policies regarding transport are in RFC5734 which has no XML namespace per se.
So maybe instead of the XML namespace you could use the RFC number or the 
interne-draft name.

In the long run if all of this work (independ of the specific 
implementation details) I would think at least an update to RFC3735 would be 
welcome that could add:
* IANA registration in the EPP registry is mandatory 
* and description of the policy of the extension described must exist and 
conform to this document standard.

JG - Maybe you can provide some sample XML that combines the policy for a 
Registry Zone that supports what is in the Registry Mapping and in the Launch 
Phase Policy Extension to help understand your proposal.  

More specifically now, about "2.3.  Schedule" I am *strongly* against using 
the format proposed for at least 2 reasons:
- crontab format is not a standard, and is ambiguous for various points
- it encodes a format as a string which is itself in a formatted structure 
since it is XML. "Hijacking" some free form space when you are in formatted 
structure seems wrong to me and shows that the structure is not correctly 
formatted because if it were you would not have to inject a new format in a 
free text.

Why not use ISO8601 Repeated Time Interval format? We are then still gulty 
of the previous point but at least it is a standard.
Otherwise please amend the XML structure to break the content currently in 
the crontab format.

JG - The schedule can certainly be enhanced.  Can you propose an alternative 
structure to define it?  

As for timezones, all EPP standards always used UTC for all timestamps (and 
even if some registries on the field do not respect that), and I think it would 
be best to stick to that, so that removes the "tz" attribute.

JG - Yes, that is the case for communicating dates (create date, expiration 
date), but not the case when it comes to defining a schedule for a batch 
component that runs based on a local time zone.  
 
I find this unfortunate:
:  The zone name that can be at any level

When you parse it, you read it as "a registry name", but then it is a zone.
So while it could probably not be  it should at least be
.
 
JG- The label name could be changed, but I believe the most important item is 
the meaning of the element.  Since the  element is a 

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Patrick Mevzek]

On Fri, Jun 1, 2018, at 17:16, Roger D Carney wrote:
> We have been talking about Registry Mapping for over a year now and here 
> is the official first 
> draft >.
> 
> 
> 
> Please take a read and let the discussions flow! 

Some quick remarks before trying to implement it and hence reviewing it more in 
depth later.

First I think it is an important concept (auto-discovery), whatever the 
implementation is. It would be most useful if deployed by multiple registries, 
also outside of gTLDs, so even if not technical some outreach should be done to 
try finding registries willing to participate and/or deploy it later.
So that during desigining no spots are missed.

Also I think this is an extension that needs itself to be extended.
I have seen the other document about the launchphase policies but I think the 
model should be different, so that extension data is still inside the 
 node.
Here is an outline of what I thought, so names are just examples:
among the nodes there would be a  one with a "for" attribute whose 
value would be the XML namespace of the extension concerned by the policies 
that will be described inside this policy node. So infData will be mostly a 
list of  nodes. The core document would define the blocks for RFC 5730 
to 5733 (and maybe also RGP and DNSSEC) and then each other extension would 
define their own block content.

Also, using the XML namespace as identifier may not be always possible: all 
policies regarding transport are in RFC5734 which has no XML namespace per se.
So maybe instead of the XML namespace you could use the RFC number or the 
interne-draft name.

In the long run if all of this work (independ of the specific implementation 
details) I would think at least an update to RFC3735 would be welcome that 
could add:
* IANA registration in the EPP registry is mandatory 
* and description of the policy of the extension described must exist and 
conform to this document standard.


More specifically now, about "2.3.  Schedule" I am *strongly* against using the 
format proposed for at least 2 reasons:
- crontab format is not a standard, and is ambiguous for various points
- it encodes a format as a string which is itself in a formatted structure 
since it is XML. "Hijacking" some free form space when you are in formatted 
structure seems wrong to me and shows that the structure is not correctly 
formatted because if it were you would not have to inject a new format in a 
free text.

Why not use ISO8601 Repeated Time Interval format? We are then still gulty of 
the previous point but at least it is a standard.
Otherwise please amend the XML structure to break the content currently in the 
crontab format.


As for timezones, all EPP standards always used UTC for all timestamps (and 
even if some registries on the field do not respect that), and I think it would 
be best to stick to that, so that removes the "tz" attribute.
 
I find this unfortunate:
:  The zone name that can be at any level

When you parse it, you read it as "a registry name", but then it is a zone.
So while it could probably not be  it should at least be
.

You are speaking about "regex" in various places without referencing how is 
this formatted. There are multiple de facto regex "standards" so care must be 
taken there to reference precisely what kind of regex are manipulated.
Also, for example for passwords, some registries policies are not possible to 
express (only) in regex I think, so there might be a blind spot here.

alphaNumStart/alphaNumEnd/aLabelSupported/uLabelSupported and maybe others (all 
the IDNs ones) should be removed and instead LGRs (RFC7940) should be 
used/referenced: far more complicated but at least you cater for all cases.

For IP addresses (min/max) you may need to separate between IPv4 and IPv6 as 
some registries may impose different constraints to each (including: IPv4 
allowed but not IPv6)

For contacts:
- I think the design around int/loc policy does not capture all cases.
Some registries allow int only; some loc; some int only or int+loc, some loc 
only or int+loc, some int only or loc only or int+loc, etc.
(I am not saying all combinations exist, but there are at least more than one 
of them so we need to be able to handle that)
- for the contact ID some registries let the registrars choose it (per the 
RFC5733 spirit) but some do not and just choose instead of them; it should be 
possible to encode this in the policy; there may also be the need to encode 
that in some cases the prefix of contact ids is not free, but fixed per 
registrar; maybe a need too to define what happens when 2 registrars try to 
create the same contact ID, depending on if they are global to the system or 
local to each registrar (the ROID would be different of course).


Other things that would be useful to include (and could be done "easily" if you 
take my ideas on top to have blocks identified by the underlying XML 

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

[Gould, James]

To add to Roger’s note about the Registry Mapping, I posted the Launch Phase 
Policy Extension 
(draft-gould-regext-launch-policy<https://datatracker.ietf.org/doc/draft-gould-regext-launch-policy>).
  This is the first Registry Mapping command / response extension that defines 
the policies (MAYs, SHOULDs, and options) associated with the Launch Phase 
Extension (RFC 8334<https://tools.ietf.org/html/rfc8334>).  There was interest 
in discovering the launch phase schedule in the working group, which is fully 
supported by the Launch Phase Policy Extension.

As a co-author of the Launch Phase Extension (RFC 
8334<https://tools.ietf.org/html/rfc8334>), I found it extremely useful to 
formally define the MAYs, SHOULDs, and options of the RFC into a draft that can 
be defined by the server and consumed by a client.

Please review both the Registry Mapping and the Launch Phase Policy Extension 
and provide any feedback on the list.

Thanks,

—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgo...@verisign.com

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

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

From: regext  on behalf of Roger Carney 

Date: Friday, June 1, 2018 at 11:17 AM
To: regext 
Subject: [EXTERNAL] Re: [regext] New Version Notification for 
draft-gould-carney-regext-registry-00.txt


Good Morning,



We have been talking about Registry Mapping for over a year now and here is the 
official first 
draft<https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/>.



Please take a read and let the discussions flow! We will be having an interim 
meeting<https://datatracker.ietf.org/doc/agenda-interim-2018-regext-03-regext-01/>
 next Tuesday (June 5th at 16:00 UTC) and one of the two agenda items is a 
discussion of this idea/draft.





Thanks

Roger





-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, May 31, 2018 3:12 PM
To: Roger D Carney ; Lin Jia ; James 
Gould ; Roger D Carney ; Jody Kolker 

Subject: New Version Notification for draft-gould-carney-regext-registry-00.txt





A new version of I-D, draft-gould-carney-regext-registry-00.txt

has been successfully submitted by James Gould and posted to the IETF 
repository.



Name:  draft-gould-carney-regext-registry

Revision:  00

Title:  Registry Mapping for the Extensible Provisioning 
Protocol (EPP)

Document date:   2018-05-31

Group:  Individual Submission

Pages:   61

URL:
https://www.ietf.org/internet-drafts/draft-gould-carney-regext-registry-00.txt

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

Htmlized:   
https://tools.ietf.org/html/draft-gould-carney-regext-registry-00

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





Abstract:

   This document describes an Extensible Provisioning Protocol (EPP)

   mapping for provisioning registry zones (e.g. top-level domains) in a

   Domain Name Registry.  The attributes of a registry zone include the

   features and policies of the registry zone.









Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext