Re: [regext] REGEXT Interim Meeting (2019JUN11) Notes

[Patrick Mevzek]

 On 2019-07-03 09:45 -0500, Pieter Vandepitte 
 wrote:> The current EPP specifications 
do not prevent a client to perform “bulk > updates”, it’s just the 
clients that are not smart enough. If clients > would operate 
asynchronously (not waiting for a server response), the


(except that sometimes updates may be linked in the sense of one should 
stop if one is giving out errors; using pipelining is explicitly allowed 
by the RFC, may or may not be allowed by registries - so it is not just 
a matter of clients being not smart enough - and will certainly not 
solve the problem of conditionally continuing the batch or not)


only overhead is the verbosity of XML (vs. message RTT when operating 
synchronously). I doubt that this is a real issue (except if you’re 
provisioning billions of objects/updates)...


There is (at least) one (existing[1]) use case that is absolutely not 
covered:

in some registry, some names are "bundled" together.

If you transfer/update one name from the bundle, you need to apply the 
same operation to others.
Currently it is done in a fashion where the first command is put in 
pending state until all other commands are done, at which point all are 
released as done.


In situations like that, you would need a way to send multiple commands 
in the same "batch", like a logical unit, or a DB transaction.
Or an EPP extension clearly describing bundles, identifying them, and 
being then able to send commands not on a domain but on a bundle of 
domains, and I do not think this extension exists anywhere.


EPP does not provide that and I am not sure it should provide that anyway.
I will try to read the underlying proposal at some time, but I wanted to 
react to add a use case that may not be known.


[1] upon checking, that specific behavior I described existed but ceased 
to recently when the registry changed its backend (now any single 
operation on a domain in a bundle does the same operation for all other 
domains in the bundle - that clearly solves the "batch" problem but then 
exposes to many other pitfalls)

--
Patrick Mevzek

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

Re: [regext] REGEXT Interim Meeting (2019JUN11) Notes

[Gould, James]

Peiter,

Thank you for re-reading the DSF draft and also thank you for the references to 
the other CSV initiatives.  I’ll review those initiatives and see what can be 
reused from them.

Without questioning the usefulness of this draft, I don’t see the use case for 
EPP (intro), so I would try to come up with other examples.
The current EPP specifications do not prevent a client to perform “bulk 
updates”, it’s just the clients that are not smart enough. If clients would 
operate asynchronously (not waiting for a server response), the only overhead 
is the verbosity of XML (vs. message RTT when operating synchronously). I doubt 
that this is a real issue (except if you’re provisioning billions of 
objects/updates)...

There are cases that cannot be easily done via EPP, such as executing a bulk 
transfer, or that need to be executed in a controlled manner to minimize the 
impact to the provisioning database, such as providing a bulk mechanism for 
populating the contact data.  EPP is designed to handle general provisioning 
operations, but is not designed to deal with special cases that are better 
handled via a bulk processing engine using DSF.  A pipelining EPP client can 
certainly handle a large volume of updates, but EPP may not provide the 
features needed for the job or the server can execute the job faster without 
the client-side constraints (connection / bandwidth) and without putting the 
provisioing database at risk.


—

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 Pieter Vandepitte 

Date: Wednesday, July 3, 2019 at 10:46 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting (2019JUN11) Notes

Thanks for the minutes. This also triggered me to re-read the DSF draft :)

Regarding reporting,

I don’t know the details of the conversations in that meeting, but keep in mind 
that we are not the first ones to invent the wheel...

There are initiatives like CSV on the web 
(https://www.w3.org/TR/tabular-data-primer/), DCAT 
(https://www.w3.org/TR/vocab-dcat/ ) or https://schema.org to describe data 
sets and/or catalogs

Regarding the draft,

Without questioning the usefulness of this draft, I don’t see the use case for 
EPP (intro), so I would try to come up with other examples.
The current EPP specifications do not prevent a client to perform “bulk 
updates”, it’s just the clients that are not smart enough. If clients would 
operate asynchronously (not waiting for a server response), the only overhead 
is the verbosity of XML (vs. message RTT when operating synchronously). I doubt 
that this is a real issue (except if you’re provisioning billions of 
objects/updates)...

Also, it would be nice if the draft would build upon existing initiatives (like 
the ones above) to describe the data set metadata...

Just my 2 cents...

Pieter

From: regext  on behalf of Roger D Carney 

Date: Wednesday, 3 July 2019 at 14:17
To: "regext@ietf.org" 
Subject: [regext] REGEXT Interim Meeting (2019JUN11) Notes

Meeting minutes from our quick Interim Meeting on June 11th, enjoy! See 
everyone in a few weeks.

Meeting started at 11:04 (UTC-5)

Attendees: Roger Carney (GoDaddy), Gordon Dick (Nominet), Joseph Yee (Afilias)


Agenda
1.   Reporting 
Repository<https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/>/Structure<https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/>/Reports<https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/>
 (how does the Data Set File 
Format<https://datatracker.ietf.org/doc/draft-gould-regext-dataset/> fit in).

We talked for about 15 minutes, I suggested that we would schedule a meeting 
before the next IETF, maybe the first couple weeks of July.

We agreed that expanding the specific communications protocol from just sFTP to 
a small number of them (sFTP or HTTPS or ??) would be good for the registry 
side. As for using the Data Set File format suggested by Gould, we thought that 
it seemed to be overly complex/heavy handed for this scenario, though we would 
like to have a fuller discussion around how/where it does fit.

Jim Gould was not able to make it, but he did send me these notes: “I just 
wanted to let you know that the Data Set File format draft has not been updated 
yet to support reports, but I have a domain model defined that would support 
defined bulk operations with the definition and data in a single file and 
report definition with the definition in a separate file with a reference to 
the report data file.  The report defining and data can be contained in a 
single file, but I anticipate that it will be a separate file.  The meta data 
about the report including its format is in the definition along with the 
definition of a type that 

Re: [regext] REGEXT Interim Meeting (2019JUN11) Notes

[Pieter Vandepitte]

Thanks for the minutes. This also triggered me to re-read the DSF draft :)

Regarding reporting,

I don’t know the details of the conversations in that meeting, but keep in mind 
that we are not the first ones to invent the wheel...

There are initiatives like CSV on the web 
(https://www.w3.org/TR/tabular-data-primer/), DCAT 
(https://www.w3.org/TR/vocab-dcat/ ) or https://schema.org to describe data 
sets and/or catalogs

Regarding the draft,

Without questioning the usefulness of this draft, I don’t see the use case for 
EPP (intro), so I would try to come up with other examples.
The current EPP specifications do not prevent a client to perform “bulk 
updates”, it’s just the clients that are not smart enough. If clients would 
operate asynchronously (not waiting for a server response), the only overhead 
is the verbosity of XML (vs. message RTT when operating synchronously). I doubt 
that this is a real issue (except if you’re provisioning billions of 
objects/updates)...

Also, it would be nice if the draft would build upon existing initiatives (like 
the ones above) to describe the data set metadata...

Just my 2 cents...

Pieter

From: regext  on behalf of Roger D Carney 

Date: Wednesday, 3 July 2019 at 14:17
To: "regext@ietf.org" 
Subject: [regext] REGEXT Interim Meeting (2019JUN11) Notes

Meeting minutes from our quick Interim Meeting on June 11th, enjoy! See 
everyone in a few weeks.

Meeting started at 11:04 (UTC-5)

Attendees: Roger Carney (GoDaddy), Gordon Dick (Nominet), Joseph Yee (Afilias)


Agenda

  1.  Reporting 
Repository<https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/>/Structure<https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/>/Reports<https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/>
 (how does the Data Set File 
Format<https://datatracker.ietf.org/doc/draft-gould-regext-dataset/> fit in).

We talked for about 15 minutes, I suggested that we would schedule a meeting 
before the next IETF, maybe the first couple weeks of July.

We agreed that expanding the specific communications protocol from just sFTP to 
a small number of them (sFTP or HTTPS or ??) would be good for the registry 
side. As for using the Data Set File format suggested by Gould, we thought that 
it seemed to be overly complex/heavy handed for this scenario, though we would 
like to have a fuller discussion around how/where it does fit.

Jim Gould was not able to make it, but he did send me these notes: “I just 
wanted to let you know that the Data Set File format draft has not been updated 
yet to support reports, but I have a domain model defined that would support 
defined bulk operations with the definition and data in a single file and 
report definition with the definition in a separate file with a reference to 
the report data file.  The report defining and data can be contained in a 
single file, but I anticipate that it will be a separate file.  The meta data 
about the report including its format is in the definition along with the 
definition of a type that can be registered in an IANA registry.  A registry 
could implement  a registered report and even extend it by adding more fields.  
Clients that are not interested in the additional fields can process the field 
based on the IANA registered definition.  Both standard reports and custom 
reports can be defined using a common set of meta data and a common set of 
field elements.  The field elements are defined using XML schema types and can 
be fully validated by a processor.  Custom field elements can be defined.  The 
field definition approach is taken from the CSV data escrow format and the 
existing Data Set Format draft.  The key with the approach is that we can 
define the Wild West using a standards based mechanism that will support 
automation and provide a lighter weight mechanism for standardization with the 
use of an IANA registry that contains the report definition with a unique type 
identifier.  There can also be sub-types to support additional granularity.  I 
intend to make a dent in updating the draft this month.”



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

[regext] REGEXT Interim Meeting (2019JUN11) Notes

[Roger D Carney]

Meeting minutes from our quick Interim Meeting on June 11th, enjoy! See 
everyone in a few weeks.

Meeting started at 11:04 (UTC-5)

Attendees: Roger Carney (GoDaddy), Gordon Dick (Nominet), Joseph Yee (Afilias)


Agenda

  1.  Reporting 
Repository/Structure/Reports
 (how does the Data Set File 
Format fit in).

We talked for about 15 minutes, I suggested that we would schedule a meeting 
before the next IETF, maybe the first couple weeks of July.

We agreed that expanding the specific communications protocol from just sFTP to 
a small number of them (sFTP or HTTPS or ??) would be good for the registry 
side. As for using the Data Set File format suggested by Gould, we thought that 
it seemed to be overly complex/heavy handed for this scenario, though we would 
like to have a fuller discussion around how/where it does fit.

Jim Gould was not able to make it, but he did send me these notes: "I just 
wanted to let you know that the Data Set File format draft has not been updated 
yet to support reports, but I have a domain model defined that would support 
defined bulk operations with the definition and data in a single file and 
report definition with the definition in a separate file with a reference to 
the report data file.  The report defining and data can be contained in a 
single file, but I anticipate that it will be a separate file.  The meta data 
about the report including its format is in the definition along with the 
definition of a type that can be registered in an IANA registry.  A registry 
could implement  a registered report and even extend it by adding more fields.  
Clients that are not interested in the additional fields can process the field 
based on the IANA registered definition.  Both standard reports and custom 
reports can be defined using a common set of meta data and a common set of 
field elements.  The field elements are defined using XML schema types and can 
be fully validated by a processor.  Custom field elements can be defined.  The 
field definition approach is taken from the CSV data escrow format and the 
existing Data Set Format draft.  The key with the approach is that we can 
define the Wild West using a standards based mechanism that will support 
automation and provide a lighter weight mechanism for standardization with the 
use of an IANA registry that contains the report definition with a unique type 
identifier.  There can also be sub-types to support additional granularity.  I 
intend to make a dent in updating the draft this month."



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

Re: [regext] REGEXT Interim Meeting 2019JUN11

[Roger D Carney]

Good Afternoon,

Unfortunately we have to reschedule this meeting, fortunately we have 
rescheduled to June 11th, we will plan the same time (16:00 UTC) using the same 
Zoom conference meeting.


Agenda

  1.  Reporting 
Repository/Structure/Reports
 (how does the Data Set File 
Format fit in).


Thanks
Roger


From: Roger D Carney
Sent: Thursday, May 16, 2019 9:07 AM
To: regext@ietf.org
Subject: REGEXT Interim Meeting 2019MAY30

Good Morning,


I would like to invite everyone to an interim meeting Thursday May 30th at 
16:00 UTC for 60 minutes.



We plan to focus the discussion around Reporting.



Agenda

  1.  Reporting 
Repository/Structure/Reports
 (how does the Data Set File 
Format fit in).



We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.



Thanks
Roger

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

[regext] REGEXT Interim Meeting 2019MAY30

[Roger D Carney]

Good Morning,


I would like to invite everyone to an interim meeting Thursday May 30th at 
16:00 UTC for 60 minutes.



We plan to focus the discussion around Reporting.



Agenda

  1.  Reporting 
Repository/Structure/Reports
 (how does the Data Set File 
Format fit in).



We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.



Thanks
Roger

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

Re: [regext] REGEXT Interim Meeting 2018DEC19

[Patrick Mevzek]

On Fri, Nov 30, 2018, at 11:36, Roger D Carney wrote:
> I would like to invite everyone to an interim meeting Wednesday 
> December 19th at 15:00 UTC for 60 minutes.

Were the minutes and list of attendees for this meeting ever published on this 
list?

I do not find them, at least by searching on the obvious title.

Thanks in advance,

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

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

Re: [regext] REGEXT Interim Meeting 2018OCT16

[Gould, James]

Patrick,



I like how you have broken down the problem into discrete registry 
implementation cases that can be applied to any EPP extension.  To make the 
core object-extension (draft-gould-carney-regext-registry) workable, we need to 
target case 1 (fully RFC-compliant registry implementers) and case 3b 
(implement base and standard policy extensions along with a server-specific 
policy extension for unique policies), since the goal is to define policies 
associated with the SHOULDs, MAYs, and options included in RFCs.  Case 3b could 
also be a sub-option for case 1 (1a), since a fully compliant registry 
implementer may have unique RFC-compliant policies that they need to define.  
Targeting case 2 does not make any sense, since those not implementing 
draft-gould-carney-regext-registry will most likely not speak up.  Targeting 
case 3a is highly unlikely to be successful, since why would an implementer 
change their policy to support defining their policy externally?  Also, case 3a 
is equivalent to case 1 from a draft-gould-carney-regext-registry  perspective. 
 I also have a 3c case, where the implementer creates a Registry Mapping-like 
implementation by not following the normative language or/and customizing the 
XML schema.  In the end, the best that we can do is to define a solid base 
draft that covers the SHOULDs, MAYs, and options of the EPP RFCs, with the 
ability to define system-level and zone-level policy extensions that cover the 
policies of specific EPP extensions or a server-specific policy.  I would 
imagine that if there is a need for a server-specific policy extension, that 
the implementer would define just one.  For clarity, I include the revised 
draft-gould-carney-regext-registry implementation cases below:



  1.  Fully RFC-compliant Registry Implementers - Implementation driven by 
policy/business/marketing case.
 *   Optionally create Server Policy Extension for server-specific policies
  2.  Registry Non-Implementers - Registries not implementing for a variety of 
reasons.
  3.  Non RFC-compliant Registry Implementers
 *   Change policies to be compliant with RFCs
 *   Define Server Policy Extension for server-specific policies (e.g., RFC 
overrides)
 *   Create Registry Mapping-like implementation (e.g., not following 
normative language and/or XML schema in draft-gould-carney-regext-registry)



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 12/11/18, 1:53 AM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Tue, Nov 27, 2018, at 11:28, Gould, James wrote:

> > * Ensure that the hostAddr model of RFC 5731 is supported

> > 
*

> > *Discussion*

> >  * In the case of a zone that supports domain:hostAddr instead of

> > domain:hostObj,

>

> No. It is not "instead".

> Have a look at the example on page 19 of some registry documentation

> at

> 
https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf



[..]



> The purpose of draft-gould-carney-regext-registry and the policy

> extensions is to define the policies around the SHOULDs, MAYs, and

> options included in extension RFCs, I-Ds, custom extensions, and to

> define the server-specific policies.  If a registry chooses not to

> follow the MUSTs in the extensions, that is their choice.  They can

> define their custom, non-compliant policies in a server-specific policy

> extension of draft-gould-carney-regext-registry.  Custom policy

> extensions can be created that define system-level and zone-level

> policies that don't need to go through the IETF.  There is no need to

> attempt to address non-compliant policies in the standards track I-Ds.



I think you are missing the point I try to raise here.

It is of course very easy to dismiss this specific case (but there are tons 
of others)

because the RFC says "MUST", and the case does not follow it, so it is 
deemed invalid

per RFC specifications and can then be ignored.

Technically, yes.

But this has consequences for the future.



First, let me reiterate how important I think this extension is, and I 
wished we

had it many years ago already. With it, life of registrars would be 
tremendously easier. Which would then also make registries life easier.



**IF** (and this is the big if and the core of my point) it gets 
implemented, and this is where I fear problems, even more so because there is 
basically no discussion

on this list from other registries about it.



For me the future can morph into the following cases:



1) a registry is fully conformant with all RFCs and hence could implement 
this

extension as is without difficulties. It is just a 

Re: [regext] REGEXT Interim Meeting 2018OCT16

[Patrick Mevzek]

On Tue, Nov 27, 2018, at 11:28, Gould, James wrote:
> > * Ensure that the hostAddr model of RFC 5731 is supported 
> > * 
> > *Discussion*
> >  * In the case of a zone that supports domain:hostAddr instead of 
> > domain:hostObj, 
> 
> No. It is not "instead".
> Have a look at the example on page 19 of some registry documentation
> at 
> https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

[..]

> The purpose of draft-gould-carney-regext-registry and the policy 
> extensions is to define the policies around the SHOULDs, MAYs, and 
> options included in extension RFCs, I-Ds, custom extensions, and to 
> define the server-specific policies.  If a registry chooses not to 
> follow the MUSTs in the extensions, that is their choice.  They can 
> define their custom, non-compliant policies in a server-specific policy 
> extension of draft-gould-carney-regext-registry.  Custom policy 
> extensions can be created that define system-level and zone-level 
> policies that don't need to go through the IETF.  There is no need to 
> attempt to address non-compliant policies in the standards track I-Ds.  

I think you are missing the point I try to raise here.
It is of course very easy to dismiss this specific case (but there are tons of 
others)
because the RFC says "MUST", and the case does not follow it, so it is deemed 
invalid
per RFC specifications and can then be ignored.
Technically, yes.
But this has consequences for the future.

First, let me reiterate how important I think this extension is, and I wished we
had it many years ago already. With it, life of registrars would be 
tremendously easier. Which would then also make registries life easier.

**IF** (and this is the big if and the core of my point) it gets implemented, 
and this is where I fear problems, even more so because there is basically no 
discussion
on this list from other registries about it.

For me the future can morph into the following cases:

1) a registry is fully conformant with all RFCs and hence could implement this
extension as is without difficulties. It is just a policy/business/marketing 
case
to decide to implement it or not, the specification is not a barrier

2) registries that decided not to implement it anyway, for whatever reasons and 
case they are in

3) registries that DO NOT respect all RFCs to the letter and/or are in cases 
not handled by this new extension and that are thinking about implementing it 
or not.
If they want to implement it they have the choice:
a) either to change their policies and business rules that either contradicts 
core
EPP documents or are incompatible with the extension as written right now
b) or to create **another** EPP extension just to code for the differences 
between the kind of policies that can be encoded in your extension and the 
registry policies that do not fit in

The above are facts, the below are my assumptions.

- case 1 will be mostly gTLDs or said differenly I doubt many ccTLDs will fall 
in this case
- case 2 is irrelevant for this discussion as nothing we discuss can change that
- case 3 is the interesting point, and my assumption is that this will group 
basically all ccTLDs, and my further assumptions are that of course registries 
will not change their policies just because this extension is not tailored to 
them (so 3a will mostly be empty) and I doubt many will go the length of 
writing a new extension just to codify their policies (so 3b will be negligible)
[BTW 3b introduces again the exact same problem we had with EPP extensions 
since the beginning: fragmentation. Multiple registries have a "trade" 
operation for example. To encode that as policy, there is a risk each one 
drafting an extension for it, and then you come back to the case of multiple 
non-interoperable extensions that do the same things which is a nightmare]

So I fear that at the end we will have something beautiful that caters for all 
the
generic/simple cases, but that left out all complicated cases, and hence the 
implementation will not be widespread.

The fact that no registry claimed to be willing to implement it or to write an 
extension for their own policy is very troublesome for me. But maybe it 
happened in private or will be announced in the future.


-- 
  Patrick Mevzek

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

[regext] REGEXT Interim Meeting 2018DEC19

[Roger D Carney]

Good Morning,


I would like to invite everyone to an interim meeting Wednesday December 19th 
at 15:00 UTC for 60 minutes.



We plan to focus the discussion around Reporting and if time allows a 
discussion on the Validate draft.



Agenda

  1.  Reporting 
Repository/Structure/Reports
 and
  2.  Validate draft (updates from last interim and Bangkok)



We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.



Please reply to the list or directly to myself if you plan on attending this 
meeting.



Thanks
Roger

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

Re: [regext] REGEXT Interim Meeting 2018OCT16

[Gould, James]

Patrick,

Please review the latest version of draft-gould-carney-regext-registry, since I 
believe it has changes that are applicable to your feedback (e.g., batch 
schedule, host attribute support).  I provide my responses to your feedback 
below.  
  
—
 
JG



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

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

Verisign.com  

On 11/26/18, 8:02 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Nov 26, 2018, at 13:58, Roger D Carney wrote:
>  * I still don’t like the use of the  elements as a 
> “flexible mechanism to share data between the client and the server”. 

There are many registries going this route, and it is very sad, even
if easy to understand why.
It voids any usefulness of the schema attached to the (XML) documents,
and basically will only need to interoperability problem because this 
content
will not be described in an automated content, and relying on human
documentation is not enough.

I agree that the key, value pair approach is an anti-pattern that has been 
tried before without success.  

> * The schedule format to use with the  
>  element 
> * 
> *Discussion*
>  * This particular topic is not straight forward, since we need a 
> condensed mechanism to define the batch schedules. 

I do not see why "condensed". We are in XML land already, which is not
known for its small size anyway so why would there be a need here to
condense things?

The key is not the word "condensed", but "effective".  Please review the latest 
update to the approach taken for the schedule in 
draft-gould-carney-regext-registry-04.  

> * Ensure that the hostAddr model of RFC 5731 is supported 
> * 
> *Discussion*
>  * In the case of a zone that supports domain:hostAddr instead of 
> domain:hostObj, 

No. It is not "instead".
Have a look at the example on page 19 of some registry documentation
at 
https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

You will see that both options can cohabit.

Now, I already know that some people will say: this is not allowed per EPP 
specifications.

But besides that it is important to be clear on the purpose of this 
extension:
being as "pure" and perfect as possible, with the hope that non-conforming 
current
cases will then suddenly decide to fix their thing in order to be able to 
use it, or
being as inclusive as possible so that as many registries as possible are 
using it
as is.

I think this extension can be very useful if many registries implement it.
If it is only a few, it will not give registrars a lot of useful data, and 
hence
they will not profit from it.

And I do not think that "not conforming" cases will feel the need to change 
just
to be able to implement this extension.

This is a generic point I may try to raise again later in the past threads 
about
this extension. It is an important question, that is itself tied to the 
amount
of energy devoted to each extension, which extension becomes working group 
documents
and which extensions really solve problem of more than one registry and 
hence
may have the chance to be implemented by a sizeable chunk of current 
players.

The purpose of draft-gould-carney-regext-registry and the policy extensions is 
to define the policies around the SHOULDs, MAYs, and options included in 
extension RFCs, I-Ds, custom extensions, and to define the server-specific 
policies.  If a registry chooses not to follow the MUSTs in the extensions, 
that is their choice.  They can define their custom, non-compliant policies in 
a server-specific policy extension of draft-gould-carney-regext-registry.  
Custom policy extensions can be created that define system-level and zone-level 
policies that don't need to go through the IETF.  There is no need to attempt 
to address non-compliant policies in the standards track I-Ds.  

HTH,

-- 
  Patrick Mevzek

___
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] REGEXT Interim Meeting 2018OCT16

[Patrick Mevzek]

On Mon, Nov 26, 2018, at 13:58, Roger D Carney wrote:
>  * I still don’t like the use of the  elements as a 
> “flexible mechanism to share data between the client and the server”. 

There are many registries going this route, and it is very sad, even
if easy to understand why.
It voids any usefulness of the schema attached to the (XML) documents,
and basically will only need to interoperability problem because this content
will not be described in an automated content, and relying on human
documentation is not enough.

> * The schedule format to use with the  
>  element 
> * 
> *Discussion*
>  * This particular topic is not straight forward, since we need a 
> condensed mechanism to define the batch schedules. 

I do not see why "condensed". We are in XML land already, which is not
known for its small size anyway so why would there be a need here to
condense things?

> * Ensure that the hostAddr model of RFC 5731 is supported 
> * 
> *Discussion*
>  * In the case of a zone that supports domain:hostAddr instead of 
> domain:hostObj, 

No. It is not "instead".
Have a look at the example on page 19 of some registry documentation
at https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf

You will see that both options can cohabit.

Now, I already know that some people will say: this is not allowed per EPP 
specifications.

But besides that it is important to be clear on the purpose of this extension:
being as "pure" and perfect as possible, with the hope that non-conforming 
current
cases will then suddenly decide to fix their thing in order to be able to use 
it, or
being as inclusive as possible so that as many registries as possible are using 
it
as is.

I think this extension can be very useful if many registries implement it.
If it is only a few, it will not give registrars a lot of useful data, and hence
they will not profit from it.

And I do not think that "not conforming" cases will feel the need to change just
to be able to implement this extension.

This is a generic point I may try to raise again later in the past threads about
this extension. It is an important question, that is itself tied to the amount
of energy devoted to each extension, which extension becomes working group 
documents
and which extensions really solve problem of more than one registry and hence
may have the chance to be implemented by a sizeable chunk of current players.

HTH,

-- 
  Patrick Mevzek

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

[regext] REGEXT Interim Meeting 2018OCT16

[Roger D Carney]

Meeting started at 11:03 (UTC-5)

Attendees: Roger Carney, Jody Kolker, James Gould, James Galvin, Gurshabad 
Grover, Rick Wilhelm


Agenda

  1.  Validate draft (comments, concerns, implementations) - New version to be 
posted this week.
  2.  Registry Mapping
 *   Continue the lively discussion that were started in London and 
continued in Montreal
 *   Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.

We first started talking about the changes to the Validate Draft:

* Roger gave an update on the current version

* Still need to make change to reference for RFC 7451 from normative to 
informative

* Gould talked about a few items he had posted to the list:

 *   Section 2.2 "Validate Id"
*   I recommend creating 2 numbered paragraphs for the two different 
scenarios and end the first sentence with a colon ":".  You could then change 
the "First if the  is passed" with "1. If the  
element is passed" and "Second scenario would be if the request includes 
additional elements" with "2. If the  element includes additional 
elements".
   *   [Interim] Will look at this
*   Nit - Change ">validate:postalIinfo>" to ""
   *   [Interim] Will update
 *   Section 2.3 "Validate PostalInfo, Voice, Fax, Email, AuthInfo"
*   I would directly refer to the validate elements by element name 
that mirror the associated elements in RFC 5733.  My recommendation is to be as 
explicit as possible here.  You reference section 2.3 for the elements in 
section 3.1.1 "EPP  Command", but you really don't describe the elements 
section 2.3.
   *   [Interim] Will look at this
 *   Section 3.1.1 "EPP  Command"
*   I recommend putting the attribute in double quotes as in '...two 
required attributes: contactType, which describes...' to '...two required 
attributes: "contactType", which describes...' and '...tld, which provides' 
to '"tld", which provides...'.
   *   [Interim] Will update
*   I still don't like the use of the  elements as a 
"flexible mechanism to share data between the client and the server".  It would 
be best to enable the use of the EPP extensions to be passed directly to the 
validate mapping without the need for transforming them to key, value pairs.   
The client and server would need to negotiate, most likely out-of-band, on the 
acceptable set of key, value pairs, or a new IANA registry would need to be 
defined to globally define the set of acceptable validate keys.
   *   [Interim] Gould was suggesting the draft to support the  
so that it can use the extesions of the contact create so that they map more 
specifically instead of mapping these to KV pairs. I made mention that it is 
not a required element, a server may choose not to support. Maybe add text like 
"KV is server dependent and these keys would be communicated out of band"

We moved onto the Registry Mapping discussion

* Gould talked about the GitHub project and all the issues that have 
been raised on list have been recorded into the project. Gould closed six items 
as corner cases. Currently 14 items remaining.

 *   Define Exceeding Maximum Expiration Date 
Policy
*   Discussion
*   Schema Change
*   Maybe we can add the registry:exceedMaxExDate element under the 
registry:domain element after the registry:period element, with the description:
   *   The OPTIONAL action taken by the server when the domain:exDate 
exceeds the maximum expiration date by a fractional period on a renewal command 
like domain:renew or domain:transfer. The possible values for the 
registry:exceedMaxExDate element include:
   *   "fail": The server will fail the renewal command when the 
expiration date exceeds the maximum expiration date by a fraction of a period.. 
An example is if the maximum expiration date is 10 years, and a client renews a 
domain name to 10.5 years, the server will fail the renew.
   *   "clip": The server will clip the fractional period when the 
expiration date exceeds the maximum expiration date by a fraction of a period. 
An example is if the maximum expiration date is 10 years, and the client renews 
a domain to 10.5 years, the server will clip the .5 fractional year so that the 
domain name will expire exactly in 10 years.

?  [Interim] This may need to specific for transfers and renew. Gould will 
update language here on the "fail".

 *   Definition of Regular Expressions for String Format 
Policies
*   Discussion
*   I addressed this in the Login Security Policy Extension 
(draft-gould-regext-login-security-policy) by choosing Perl-compatible Regular 
Expression (PCRE) syntax. I can add the appropriate informational reference to 
PCRE within the Registry Mapping 

Re: [regext] REGEXT Interim Meeting (2018OCT16)

[James Galvin]

I will attend this meeting.  Thanks Roger.

Jim



On 1 Oct 2018, at 12:57, Roger D Carney wrote:


Good Morning,



I would like to invite everyone to an interim meeting Tuesday October 
16th at 16:00 UTC for 60 minutes.




We plan to focus the discussion around two topics:



Agenda

  1.  Validate draft (comments, concerns, implementations) - New 
version to be posted this week.

  2.  Registry Mapping
 *   Continue the lively discussion that were started in London 
and continued in Montreal
 *   Policy Extension Review: how a server implements an 
extension, the SHOULD(s), MAY(s), etc.




We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.




Please reply to the list or directly to myself if you plan on 
attending this meeting.






Thanks

Roger




___
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] REGEXT Interim Meeting (2018JUN05) Notes

[Roger D Carney]

Good Morning,

Thanks Pieter. I think the real goal of Validate is improved customer 
experience.

I don’t think wrapping this in a transaction helps as the error identification 
is still occurring to late in the process.

There are quite a few steps in the registration process but today one of the 
main issues comes at domain create time (this is basically the last step in the 
process along with collecting fees).

Today, validating contacts in terms of their “roles”/contactType 
(Registrant/Admin/Tech/etc) occurs at Domain Create time, which is way too late 
for a good customer experience. A contact maybe a valid contact for the 
Registry but it may not be a valid contact for the “role” /contactType. So what 
we want to do is validate this data in as full of context as we can before the 
Domain Create / Collection of fees. Getting an error at this point (domain 
create) causes a painful customer experience and a lot of additional processing 
to occur.


Thanks
Roger


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Pieter Vandepitte
Sent: Friday, July 06, 2018 7:05 AM
To: Registration Protocols Extensions mailto:regext@ietf.org>>
Subject: Re: [regext] REGEXT Interim Meeting (2018JUN05) Notes

Short question regarding the validate extension:

Isn’t the purpose of the validate extension to do what actually transactions 
are meant for? Ultimately the goal of the validate extension is to check 
whether a group of commands are possible: create some contacts, link the 
contacts to a domain with a specific role.
Why not trying to add a layer on top of EPP to enable transactions? Start a 
transaction, add commands to a transaction, execute a transaction with either 
commit or auto roll back?
I think that would lead to a much simpler model and could easily deal with 
other objects and other extensions.

Thoughts?

Pieter


--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]



From: regext mailto:regext-boun...@ietf.org>> on 
behalf of Roger D Carney mailto:rcar...@godaddy.com>>
Date: Tuesday 3 July 2018 at 20:04
To: Registration Protocols Extensions mailto:regext@ietf.org>>
Subject: [regext] REGEXT Interim Meeting (2018JUN05) Notes

Sorry about the tardiness, please enjoy, see everyone in a couple weeks.

Meeting started at 11:06 (UTC-5)

Attendees: Roger Carney, James Gould, Jody Kolker, Jim Galvin

Agenda
1.Validate draft (comments, concerns, implementations)
2.Registry Mapping
a.Continue the lively discussion that was started in London
b.Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.

Jim Galvin mentioned that co-chairs have been discussing milestones and updated 
charter with AD (Adam). Hopefully circulate new Charter to the group next week. 
Planning two meetings for IETF-102.

James Gould said that he has started implementing the Validate draft in their 
SDK. I mentioned that Nominet has already implemented.

We started out discussing the Validate draft, specifically the questions James 
Gould posted to the list Monday June 4, 2018, copied below:

1.I don’t see the purpose of the  element in the check 
command..  Initially, I thought the  may support a list within a 
list (e.g., ), but that is not the case.  There is also a 
little confusion with the use of  in both the check command and 
response.  My recommendation is to remove the  element from the 
check command and simply move all its sub-elements to sub-elements of the 
 element. [Interim] Interesting for removal, post to list.
2.Is the extension meant to validate the contact details of existing 
contacts by contact id and also non-existent contacts based on the contact 
details, by contact type and by tld?  [Interim] Yes, both scenarios. For “new” 
contacts pass all data, don’t try to short cut it with only id, if only id is 
passed server will assume it is an existing contact. Change response 
validate:cd to include TLD and contact type attributes. Discussed the 
preferences of smaller payload versus complicated payload, went with simpler. 
Add a new section to 2.0 describing validate:id (Need to have response pass 
back contact type and tld).
a.If both cases are true, then wouldn’t you have a choice of referencing 
the contact by identifier for an existing contact or defining the contact 
attributes for a non-existing contact?
b.Also, what if you desire to use the same contact information for multiple 
contact types for a tld?

  1.  Do you need to replicate the same attributes for each contact type?  
[Interim] Simple method would
  2.  It may be better to define a single contact (existing with contact 
identifier) or contact attributes for non-existing with the list of contact 
types.  I imagine that you always want to validate a contact within the scope 
of a tld.  [Interim] Interesting, thoughts?
3.I view definition of only the check command an

Re: [regext] REGEXT Interim Meeting (2018JUN05) Notes

[Pieter Vandepitte]

Short question regarding the validate extension:

Isn’t the purpose of the validate extension to do what actually transactions 
are meant for? Ultimately the goal of the validate extension is to check 
whether a group of commands are possible: create some contacts, link the 
contacts to a domain with a specific role.
Why not trying to add a layer on top of EPP to enable transactions? Start a 
transaction, add commands to a transaction, execute a transaction with either 
commit or auto roll back?
I think that would lead to a much simpler model and could easily deal with 
other objects and other extensions.

Thoughts?

Pieter


--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]



From: regext  on behalf of Roger D Carney 

Date: Tuesday 3 July 2018 at 20:04
To: Registration Protocols Extensions 
Subject: [regext] REGEXT Interim Meeting (2018JUN05) Notes

Sorry about the tardiness, please enjoy, see everyone in a couple weeks.

Meeting started at 11:06 (UTC-5)

Attendees: Roger Carney, James Gould, Jody Kolker, Jim Galvin

Agenda
1.Validate draft (comments, concerns, implementations)
2.Registry Mapping
a.Continue the lively discussion that was started in London
b.Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.

Jim Galvin mentioned that co-chairs have been discussing milestones and updated 
charter with AD (Adam). Hopefully circulate new Charter to the group next week. 
Planning two meetings for IETF-102.

James Gould said that he has started implementing the Validate draft in their 
SDK. I mentioned that Nominet has already implemented.

We started out discussing the Validate draft, specifically the questions James 
Gould posted to the list Monday June 4, 2018, copied below:

1.I don’t see the purpose of the  element in the check 
command..  Initially, I thought the  may support a list within a 
list (e.g., ), but that is not the case.  There is also a 
little confusion with the use of  in both the check command and 
response.  My recommendation is to remove the  element from the 
check command and simply move all its sub-elements to sub-elements of the 
 element. [Interim] Interesting for removal, post to list.
2.Is the extension meant to validate the contact details of existing 
contacts by contact id and also non-existent contacts based on the contact 
details, by contact type and by tld?  [Interim] Yes, both scenarios. For “new” 
contacts pass all data, don’t try to short cut it with only id, if only id is 
passed server will assume it is an existing contact. Change response 
validate:cd to include TLD and contact type attributes. Discussed the 
preferences of smaller payload versus complicated payload, went with simpler. 
Add a new section to 2.0 describing validate:id (Need to have response pass 
back contact type and tld).
a.If both cases are true, then wouldn’t you have a choice of referencing 
the contact by identifier for an existing contact or defining the contact 
attributes for a non-existing contact?
b.Also, what if you desire to use the same contact information for multiple 
contact types for a tld?

  1.  Do you need to replicate the same attributes for each contact type?  
[Interim] Simple method would
  2.  It may be better to define a single contact (existing with contact 
identifier) or contact attributes for non-existing with the list of contact 
types.  I imagine that you always want to validate a contact within the scope 
of a tld.  [Interim] Interesting, thoughts?
3.I view definition of only the check command and response with many 
contacts and with extensibility via the kv elements as somewhat non-optimal.  
Other options include:
a.Instead of supporting multiple contacts in an individual command, why not 
support the check or info of an individual contact with attribute extensibility 
via command / response extensions.  Yes, you can validate only a single contact 
with multiple target types and a tld at a time, but you get to use existing 
contact command / response extensions to define the additional contact 
attributes without having to use key / value pairs.  [Interim] One goal is to 
pass in multiple contacts and validate as a whole
b.Create a validate command / response extension of the contact mapping 
that extends the contact create to function as a no-op with the additional 
attributes used to validate usage of the contact (e.g., object - domain, 
contact types, tld), which would define a validate contact validate create 
command.  The contact info could have been extended by the validate extension 
to function as a validate usage command with the usage attributes consistent 
with the contact validate create command (e.g., object – domain, contact types, 
tld).  In this case, the contact commands can be directly extended by the 
validate extension. [Interim] So does key/value make sense here. Can this 
va

[regext] REGEXT Interim Meeting (2018JUN05) Notes

[Roger D Carney]

Sorry about the tardiness, please enjoy, see everyone in a couple weeks.

Meeting started at 11:06 (UTC-5)

Attendees: Roger Carney, James Gould, Jody Kolker, Jim Galvin

Agenda
1.Validate draft (comments, concerns, implementations)
2.Registry Mapping
a.Continue the lively discussion that was started in London
b.Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.

Jim Galvin mentioned that co-chairs have been discussing milestones and updated 
charter with AD (Adam). Hopefully circulate new Charter to the group next week. 
Planning two meetings for IETF-102.

James Gould said that he has started implementing the Validate draft in their 
SDK. I mentioned that Nominet has already implemented.

We started out discussing the Validate draft, specifically the questions James 
Gould posted to the list Monday June 4, 2018, copied below:

1.I don't see the purpose of the  element in the check 
command.  Initially, I thought the  may support a list within a 
list (e.g., ), but that is not the case.  There is also a 
little confusion with the use of  in both the check command and 
response.  My recommendation is to remove the  element from the 
check command and simply move all its sub-elements to sub-elements of the 
 element. [Interim] Interesting for removal, post to list.
2.Is the extension meant to validate the contact details of existing 
contacts by contact id and also non-existent contacts based on the contact 
details, by contact type and by tld?  [Interim] Yes, both scenarios. For "new" 
contacts pass all data, don't try to short cut it with only id, if only id is 
passed server will assume it is an existing contact. Change response 
validate:cd to include TLD and contact type attributes. Discussed the 
preferences of smaller payload versus complicated payload, went with simpler. 
Add a new section to 2.0 describing validate:id (Need to have response pass 
back contact type and tld).
a.If both cases are true, then wouldn't you have a choice of referencing 
the contact by identifier for an existing contact or defining the contact 
attributes for a non-existing contact?
b.Also, what if you desire to use the same contact information for multiple 
contact types for a tld?

  1.  Do you need to replicate the same attributes for each contact type?  
[Interim] Simple method would
  2.  It may be better to define a single contact (existing with contact 
identifier) or contact attributes for non-existing with the list of contact 
types.  I imagine that you always want to validate a contact within the scope 
of a tld.  [Interim] Interesting, thoughts?
3.I view definition of only the check command and response with many 
contacts and with extensibility via the kv elements as somewhat non-optimal.  
Other options include:
a.Instead of supporting multiple contacts in an individual command, why not 
support the check or info of an individual contact with attribute extensibility 
via command / response extensions.  Yes, you can validate only a single contact 
with multiple target types and a tld at a time, but you get to use existing 
contact command / response extensions to define the additional contact 
attributes without having to use key / value pairs.  [Interim] One goal is to 
pass in multiple contacts and validate as a whole
b.Create a validate command / response extension of the contact mapping 
that extends the contact create to function as a no-op with the additional 
attributes used to validate usage of the contact (e.g., object - domain, 
contact types, tld), which would define a validate contact validate create 
command.  The contact info could have been extended by the validate extension 
to function as a validate usage command with the usage attributes consistent 
with the contact validate create command (e.g., object - domain, contact types, 
tld).  In this case, the contact commands can be directly extended by the 
validate extension. [Interim] So does key/value make sense here. Can this 
validate extension be able to be extended with other extensions (e.g.. registry 
has a VAT extension instead of this)?
4.Each element needs to be fully described.  I include some examples below:
a. element does not define the required "contactType" or 
"tld" attributes.  [Interim] Add more descriptions
b.There is no description of any of the  sub-elements in the 
check command or response. [Interim] Add more descriptions
5.Wouldn't be better to include a required "valid" attribute in the check 
response  element with an optional reason and reason language 
similar to the domain check response?  I'm not sure if there is a real need to 
define a whole list of validity errors using the list of  
elements.  It may be good enough to short circuit the validation by simply 
saying yes or no and if no a human readable reason.  There would be no need for 
the  element or the  elements.  [Interim] 
Should the response look more 

Re: [regext] REGEXT Interim Meeting (Validate Draft)

[Pieter Vandepitte]

Thanks, Roger,

It now makes much more sense to me.

Kind regards

Pieter

--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]


From: regext  on behalf of Roger D Carney 

Date: Monday 11 June 2018 at 17:44
To: "regext@ietf.org" 
Subject: Re: [regext] REGEXT Interim Meeting (Validate Draft)

Good Morning,

I will be sending out minutes/notes of the Interim meeting later this week.

I agree with what Jim proposed during the meeting and here in reference to 
providing ids for new/existing contacts, as well as the one to one matching of 
the check/response items.

Just for a little color/background on the issues/goals of this draft. From a 
registrar standpoint we have run into difficult customer registration 
processing flows when we go to do a domain create and assign “roles” to 
contacts. Registrars can create “valid” contacts at a registry only to find out 
later (during domain create) that the “valid” contact created earlier is not 
valid for a specific contact type/role. Many registries have different policies 
around different contact types/roles (e.g. either the Registrant or Admin must 
have a postal address from a certain country but both are not required to), but 
you can only confirm this on a domain create when the contact type/role is 
being assigned. This is a huge headache for customers. They have already 
selected a domain name, provided contacts, provided payment and now find out 
they may not be eligible for the domain (and now wait for a refund) or have to 
edit contacts again because the registrar was not able to validate the contact 
information for the contact type/role earlier in the process. I hope this helps 
explain the issue/goal for this draft more clearly.


Thanks
Roger


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Monday, June 11, 2018 9:27 AM
To: Pieter Vandepitte ; Gould, James 
; Patrick Mevzek ; 
regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting


Pieter,



Regardless of that, I’m still trying to figure out the use of this extension. 
Will a client first check whether a contact can be created, then interpret the 
response of the check, and finally create the command. Or will the client just 
try to create the contact, and in case of error interpret the error message? 
Maybe there’s a need for better, more structured and machine interpretable 
responses, but I don’t think the extra check step is the way to go. Just my 2 
cents…



Based on my deep dive into draft-ietf-regext-validate, my take of the draft is 
that it’s used to validate the use of an existing or new contact as a contact 
type for a domain name of a tld.   A little of the confusion discussed during 
the REGEXT Interim Meeting was how the client specifies the use of an existing 
or new contact.  One assumption that I made was the reference to an existing 
contact was made by only including a contact id () and definition 
of a new contact to validate was made by the inclusion of the additional 
contact attributes (, etc.).  That was not the case, since 
the extension supported reuse of new contact attributes for a different contact 
type and tld by referencing a contact id included earlier in the check command. 
 Take a look at the use of the “sh8013” contact id in the check command 
example, where it’s fully defined for the “registrant” type and the “COM” tld, 
but only referenced by contact ID for the subsequent “tech” type and “COM” tld. 
 Also notice that the contacts are consolidated in the check response by 
contact ID.  In the validate check command there are 4 contacts and the 
validate check response has only two.  My recommendation was to support 
referencing an existing contact by only supplying the contact ID, don’t create 
dependencies between check items to reduce the amount of duplicate information 
provided, and ensure that the number of items in the check response match the 
number of items in the check command.





—



JG







James Gould

Distinguished Engineer

jgo...@verisign.com<mailto:jgo...@verisign.com>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



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



On 6/11/18, 4:53 AM, "Pieter Vandepitte" 
mailto:pieter.vandepi...@dnsbelgium.be>> wrote:



Maybe I’m missing something, but this draft is about validating contacts, 
so I don't see an issue in referring to the contact RFC. There’s no point in 
validating contacts, but not creating them, so the client needs to support the 
contact xsd anyway.



Regardless of that, I’m still trying to figure out the use of this 
extension. Will a client first check whether a contact can be created, then 
interpret the response of the check, and finally create the command. Or will 
the client just try to create the contact, and in case of error interpret the 
error message? Maybe there’s a need for better, more structured and machine

Re: [regext] REGEXT Interim Meeting (Validate Draft)

[Roger D Carney]

Good Morning,

I will be sending out minutes/notes of the Interim meeting later this week.

I agree with what Jim proposed during the meeting and here in reference to 
providing ids for new/existing contacts, as well as the one to one matching of 
the check/response items.

Just for a little color/background on the issues/goals of this draft. From a 
registrar standpoint we have run into difficult customer registration 
processing flows when we go to do a domain create and assign “roles” to 
contacts. Registrars can create “valid” contacts at a registry only to find out 
later (during domain create) that the “valid” contact created earlier is not 
valid for a specific contact type/role. Many registries have different policies 
around different contact types/roles (e.g. either the Registrant or Admin must 
have a postal address from a certain country but both are not required to), but 
you can only confirm this on a domain create when the contact type/role is 
being assigned. This is a huge headache for customers. They have already 
selected a domain name, provided contacts, provided payment and now find out 
they may not be eligible for the domain (and now wait for a refund) or have to 
edit contacts again because the registrar was not able to validate the contact 
information for the contact type/role earlier in the process. I hope this helps 
explain the issue/goal for this draft more clearly.


Thanks
Roger


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Monday, June 11, 2018 9:27 AM
To: Pieter Vandepitte ; Gould, James 
; Patrick Mevzek ; 
regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting


Pieter,



Regardless of that, I’m still trying to figure out the use of this extension. 
Will a client first check whether a contact can be created, then interpret the 
response of the check, and finally create the command. Or will the client just 
try to create the contact, and in case of error interpret the error message? 
Maybe there’s a need for better, more structured and machine interpretable 
responses, but I don’t think the extra check step is the way to go. Just my 2 
cents…



Based on my deep dive into draft-ietf-regext-validate, my take of the draft is 
that it’s used to validate the use of an existing or new contact as a contact 
type for a domain name of a tld.   A little of the confusion discussed during 
the REGEXT Interim Meeting was how the client specifies the use of an existing 
or new contact.  One assumption that I made was the reference to an existing 
contact was made by only including a contact id () and definition 
of a new contact to validate was made by the inclusion of the additional 
contact attributes (, etc.).  That was not the case, since 
the extension supported reuse of new contact attributes for a different contact 
type and tld by referencing a contact id included earlier in the check command. 
 Take a look at the use of the “sh8013” contact id in the check command 
example, where it’s fully defined for the “registrant” type and the “COM” tld, 
but only referenced by contact ID for the subsequent “tech” type and “COM” tld. 
 Also notice that the contacts are consolidated in the check response by 
contact ID.  In the validate check command there are 4 contacts and the 
validate check response has only two.  My recommendation was to support 
referencing an existing contact by only supplying the contact ID, don’t create 
dependencies between check items to reduce the amount of duplicate information 
provided, and ensure that the number of items in the check response match the 
number of items in the check command.





—



JG







James Gould

Distinguished Engineer

jgo...@verisign.com<mailto:jgo...@verisign.com>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



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



On 6/11/18, 4:53 AM, "Pieter Vandepitte" 
mailto:pieter.vandepi...@dnsbelgium.be>> wrote:



Maybe I’m missing something, but this draft is about validating contacts, 
so I don't see an issue in referring to the contact RFC. There’s no point in 
validating contacts, but not creating them, so the client needs to support the 
contact xsd anyway.



Regardless of that, I’m still trying to figure out the use of this 
extension. Will a client first check whether a contact can be created, then 
interpret the response of the check, and finally create the command. Or will 
the client just try to create the contact, and in case of error interpret the 
error message? Maybe there’s a need for better, more structured and machine 
interpretable responses, but I don’t think the extra check step is the way to 
go. Just my 2 cents…



Kind regards



--

Pieter Vandepitte

Product Expert

+32 16 28 49 70

www.dnsbelgium.be<http://www.dnsbelgium.be>







On 06/06/18 14:22, "regext on behalf of Gould, James" 
mailto:regext-boun...@ietf.org%20on%20behalf%20of%20j

Re: [regext] REGEXT Interim Meeting

[Gould, James]

Pieter,



Regardless of that, I’m still trying to figure out the use of this extension. 
Will a client first check whether a contact can be created, then interpret the 
response of the check, and finally create the command. Or will the client just 
try to create the contact, and in case of error interpret the error message? 
Maybe there’s a need for better, more structured and machine interpretable 
responses, but I don’t think the extra check step is the way to go. Just my 2 
cents…



Based on my deep dive into draft-ietf-regext-validate, my take of the draft is 
that it’s used to validate the use of an existing or new contact as a contact 
type for a domain name of a tld.   A little of the confusion discussed during 
the REGEXT Interim Meeting was how the client specifies the use of an existing 
or new contact.  One assumption that I made was the reference to an existing 
contact was made by only including a contact id () and definition 
of a new contact to validate was made by the inclusion of the additional 
contact attributes (, etc.).  That was not the case, since 
the extension supported reuse of new contact attributes for a different contact 
type and tld by referencing a contact id included earlier in the check command. 
 Take a look at the use of the “sh8013” contact id in the check command 
example, where it’s fully defined for the “registrant” type and the “COM” tld, 
but only referenced by contact ID for the subsequent “tech” type and “COM” tld. 
 Also notice that the contacts are consolidated in the check response by 
contact ID.  In the validate check command there are 4 contacts and the 
validate check response has only two.  My recommendation was to support 
referencing an existing contact by only supplying the contact ID, don’t create 
dependencies between check items to reduce the amount of duplicate information 
provided, and ensure that the number of items in the check response match the 
number of items in the check command.





—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 6/11/18, 4:53 AM, "Pieter Vandepitte"  
wrote:



Maybe I’m missing something, but this draft is about validating contacts, 
so I don't see an issue in referring to the contact RFC. There’s no point in 
validating contacts, but not creating them, so the client needs to support the 
contact xsd anyway.



Regardless of that, I’m still trying to figure out the use of this 
extension. Will a client first check whether a contact can be created, then 
interpret the response of the check, and finally create the command. Or will 
the client just try to create the contact, and in case of error interpret the 
error message? Maybe there’s a need for better, more structured and machine 
interpretable responses, but I don’t think the extra check step is the way to 
go. Just my 2 cents…



Kind regards



--

Pieter Vandepitte

Product Expert

+32 16 28 49 70

www.dnsbelgium.be







On 06/06/18 14:22, "regext on behalf of Gould, James" 
 
wrote:



Patrick,



The base EPP protocol is defined using epp and eppcom, where extensions 
(object or command / response) would naturally be dependent on the base 
schemas.  Creating dependencies across extensions does not allow them to stand 
on their own, so my preference would be to copy and paste the elements from 
sibling extension XML schemas unless there is a large advantage with creating 
the dependency.  There are examples of cross extension dependencies that exist 
today, like the inclusion of the host XML schema within the domain XML schema 
of RFC 5731.  This dependency does require ensuring that the host XML schema is 
loaded ahead of the domain XML schema when pre-caching the XML schemas.  The 
contact reference in the validate extension takes it one step further by 
referencing complex types that requires the use of the contact namespace 
directly within the XML, so it's more than just ensuring that the contact XML 
schema is loaded ahead of the validate XML schema.  It is not hard to overcome, 
but I believe the priority should be to have the extensions stand on their own 
and only be dependent on the base XML schemas of epp and eppcom unless there is 
an overriding reason to add the cross-extension dependency.





—



JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 6/5/18, 8:09 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Jun 4, 2018, at 19:56, Gould, James wrote:

>   4.  I don’t recommend directly referencing the

> urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a 
direct

> dependency to inclusion of the contact 

Re: [regext] REGEXT Interim Meeting

[Gould, James]

Patrick,

Yes, the issue is associated with the loading of the XML schemas and validating 
the XML against them.  There is also a potential code (library) dependency 
based on where the dependent XML schema (e.g., host-1.0.xsd for the domain 
mapping) lives.  In looking at the Verisign EPP SDK, there is a directory per 
mapping or set of extensions that includes the XML schemas to load and validate 
against with a set of tests that are isolated to that mapping or set of 
extensions.  By adding an inter-mapping / extension dependency, you either need 
to copy the dependent XML schemas or create a build dependency.  This is not a 
huge technical issue, but is certainly an annoyance that is only worth it if 
the dependency is truly warranted.  I view the Validate Extension as being on 
the borderline of justifying the dependency, which is why I wanted to bring it 
up.  The Validate Extension also added the extra complexity of requiring the 
use of the contact namespace directly in the XML (e.g., John Doe...) 
based on the use of complex types in the contact XML schema.  Again, it is not 
a huge technical issue to support two XML namespaces in the Validate extension, 
but it is a factor to consider.  

Thanks,
  
—
 
JG



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

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

Verisign.com  

On 6/9/18, 2:03 AM, "Patrick Mevzek"  wrote:

On Wed, Jun 6, 2018, at 14:21, Gould, James wrote:
> This dependency 
> does require ensuring that the host XML schema is loaded ahead of the 
> domain XML schema when pre-caching the XML schemas.

So it seems having dependencies is only a problem or a difficulty when 
validating the frames per the schemas.

-- 
  Patrick Mevzek

___
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] REGEXT Interim Meeting

[Pieter Vandepitte]

Maybe I’m missing something, but this draft is about validating contacts, so I 
don't see an issue in referring to the contact RFC. There’s no point in 
validating contacts, but not creating them, so the client needs to support the 
contact xsd anyway.

Regardless of that, I’m still trying to figure out the use of this extension. 
Will a client first check whether a contact can be created, then interpret the 
response of the check, and finally create the command. Or will the client just 
try to create the contact, and in case of error interpret the error message? 
Maybe there’s a need for better, more structured and machine interpretable 
responses, but I don’t think the extra check step is the way to go. Just my 2 
cents…

Kind regards

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

 
 
On 06/06/18 14:22, "regext on behalf of Gould, James"  wrote:

Patrick,

The base EPP protocol is defined using epp and eppcom, where extensions 
(object or command / response) would naturally be dependent on the base 
schemas.  Creating dependencies across extensions does not allow them to stand 
on their own, so my preference would be to copy and paste the elements from 
sibling extension XML schemas unless there is a large advantage with creating 
the dependency.  There are examples of cross extension dependencies that exist 
today, like the inclusion of the host XML schema within the domain XML schema 
of RFC 5731.  This dependency does require ensuring that the host XML schema is 
loaded ahead of the domain XML schema when pre-caching the XML schemas.  The 
contact reference in the validate extension takes it one step further by 
referencing complex types that requires the use of the contact namespace 
directly within the XML, so it's more than just ensuring that the contact XML 
schema is loaded ahead of the validate XML schema.  It is not hard to overcome, 
but I believe the priority should be to have the extensions stand on their own 
and only be dependent on the base XML schemas of epp and eppcom unless there is 
an overriding reason to add the cross-extension dependency.  

  
—
 
JG



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

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

Verisign.com  

On 6/5/18, 8:09 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 4, 2018, at 19:56, Gould, James wrote:
>   4.  I don’t recommend directly referencing the 
> urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct 
> dependency to inclusion of the contact XML schema and namespace for a 
> subset of the elements that are really specific to the validate 
mapping.  
> I would prefer for the validate XML schema to stand on its own by 
only 
> referring to epp and eppcom, with no cross references to contact.  
This 
> would mean copying and pasting elements directly from the contact XML 
> schema into the validate XML schema, which is an inconvenient, but 
makes 
> it easier to implement.

I am sure that not all elements of epp/eppcom namespaces are used 
either so under symmetry and consistency I would find more logical that all 
schemas are treated the same, either all referenced, or all copied (for the 
parts needed).

And I see no problems in referencing the contact-1.0 one.
Using epp/eppcom as references already make the schema dependent on 
other resources and not "standing on its own".

I am not sure this has a huge consequence on implementations, 
especially if taking into account multiple ways to implement things (and 
especially doing validation or not).

-- 
  Patrick Mevzek

___
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


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

Re: [regext] REGEXT Interim Meeting

[Patrick Mevzek]

On Wed, Jun 6, 2018, at 14:21, Gould, James wrote:
> This dependency 
> does require ensuring that the host XML schema is loaded ahead of the 
> domain XML schema when pre-caching the XML schemas.

So it seems having dependencies is only a problem or a difficulty when 
validating the frames per the schemas.

-- 
  Patrick Mevzek

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

Re: [regext] REGEXT Interim Meeting

[Gould, James]

Patrick,

The base EPP protocol is defined using epp and eppcom, where extensions (object 
or command / response) would naturally be dependent on the base schemas.  
Creating dependencies across extensions does not allow them to stand on their 
own, so my preference would be to copy and paste the elements from sibling 
extension XML schemas unless there is a large advantage with creating the 
dependency.  There are examples of cross extension dependencies that exist 
today, like the inclusion of the host XML schema within the domain XML schema 
of RFC 5731.  This dependency does require ensuring that the host XML schema is 
loaded ahead of the domain XML schema when pre-caching the XML schemas.  The 
contact reference in the validate extension takes it one step further by 
referencing complex types that requires the use of the contact namespace 
directly within the XML, so it's more than just ensuring that the contact XML 
schema is loaded ahead of the validate XML schema.  It is not hard to overcome, 
but I believe the priority should be to have the extensions stand on their own 
and only be dependent on the base XML schemas of epp and eppcom unless there is 
an overriding reason to add the cross-extension dependency.  

  
—
 
JG



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

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

Verisign.com  

On 6/5/18, 8:09 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 4, 2018, at 19:56, Gould, James wrote:
>   4.  I don’t recommend directly referencing the 
> urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct 
> dependency to inclusion of the contact XML schema and namespace for a 
> subset of the elements that are really specific to the validate mapping.  
> I would prefer for the validate XML schema to stand on its own by only 
> referring to epp and eppcom, with no cross references to contact.  This 
> would mean copying and pasting elements directly from the contact XML 
> schema into the validate XML schema, which is an inconvenient, but makes 
> it easier to implement.

I am sure that not all elements of epp/eppcom namespaces are used either so 
under symmetry and consistency I would find more logical that all schemas are 
treated the same, either all referenced, or all copied (for the parts needed).

And I see no problems in referencing the contact-1.0 one.
Using epp/eppcom as references already make the schema dependent on other 
resources and not "standing on its own".

I am not sure this has a huge consequence on implementations, especially if 
taking into account multiple ways to implement things (and especially doing 
validation or not).

-- 
  Patrick Mevzek

___
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] REGEXT Interim Meeting

[Patrick Mevzek]

On Mon, Jun 4, 2018, at 19:56, Gould, James wrote:
>   4.  I don’t recommend directly referencing the 
> urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct 
> dependency to inclusion of the contact XML schema and namespace for a 
> subset of the elements that are really specific to the validate mapping.  
> I would prefer for the validate XML schema to stand on its own by only 
> referring to epp and eppcom, with no cross references to contact.  This 
> would mean copying and pasting elements directly from the contact XML 
> schema into the validate XML schema, which is an inconvenient, but makes 
> it easier to implement.

I am sure that not all elements of epp/eppcom namespaces are used either so 
under symmetry and consistency I would find more logical that all schemas are 
treated the same, either all referenced, or all copied (for the parts needed).

And I see no problems in referencing the contact-1.0 one.
Using epp/eppcom as references already make the schema dependent on other 
resources and not "standing on its own".

I am not sure this has a huge consequence on implementations, especially if 
taking into account multiple ways to implement things (and especially doing 
validation or not).

-- 
  Patrick Mevzek

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

Re: [regext] REGEXT Interim Meeting

[Gould, James]

Roger,

I preparation for the Interim Meeting, I did a deeper dive into the Validate 
draft, and I have the following feedback:


  1.  I don’t see the purpose of the  element in the check 
command.  Initially, I thought the  may support a list within a 
list (e.g., ), but that is not the case.  There is also a 
little confusion with the use of  in both the check command and 
response.  My recommendation is to remove the  element from the 
check command and simply move all its sub-elements to sub-elements of the 
 element.
  2.  Is the extension meant to validate the contact details of existing 
contacts by contact id and also non-existent contacts based on the contact 
details, by contact type and by tld?
 *   If both cases are true, then wouldn’t you have a choice of referencing 
the contact by identifier for an existing contact or defining the contact 
attributes for a non-existing contact?
 *   Also, what if you desire to use the same contact information for 
multiple contact types for a tld?

  i.  Do you 
need to replicate the same attributes for each contact type?

ii.  It may be 
better to define a single contact (existing with contact identifier) or contact 
attributes for non-existing with the list of contact types.  I imagine that you 
always want to validate a contact within the scope of a tld.

  1.  I view definition of only the check command and response with many 
contacts and with extensibility via the kv elements as somewhat non-optimal.  
Other options include:
 *   Instead of supporting multiple contacts in an individual command, why 
not support the check or info of an individual contact with attribute 
extensibility via command / response extensions.  Yes, you can validate only a 
single contact with multiple target types and a tld at a time, but you get to 
use existing contact command / response extensions to define the additional 
contact attributes without having to use key / value pairs.
 *   Create a validate command / response extension of the contact mapping 
that extends the contact create to function as a no-op with the additional 
attributes used to validate usage of the contact (e.g., object - domain, 
contact types, tld), which would define a validate contact validate create 
command.  The contact info could have been extended by the validate extension 
to function as a validate usage command with the usage attributes consistent 
with the contact validate create command (e.g., object – domain, contact types, 
tld).  In this case, the contact commands can be directly extended by the 
validate extension.
  2.  Each element needs to be fully described.  I include some examples below:
 *element does not define the required “contactType” 
or “tld” attributes.
 *   There is no description of any of the  sub-elements in 
the check command or response.
  3.  Wouldn’t be better to include a required “valid” attribute in the check 
response  element with an optional reason and reason language 
similar to the domain check response?  I’m not sure if there is a real need to 
define a whole list of validity errors using the list of  
elements.  It may be good enough to short circuit the validation by simply 
saying yes or no and if no a human readable reason.  There would be no need for 
the  element or the  elements.
  4.  I don’t recommend directly referencing the 
urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct dependency 
to inclusion of the contact XML schema and namespace for a subset of the 
elements that are really specific to the validate mapping.  I would prefer for 
the validate XML schema to stand on its own by only referring to epp and 
eppcom, with no cross references to contact.  This would mean copying and 
pasting elements directly from the contact XML schema into the validate XML 
schema, which is an inconvenient, but makes it easier to implement.

—

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, May 4, 2018 at 12:33 PM
To: Registration Protocols Extensions 
Subject: [EXTERNAL] [regext] REGEXT Interim Meeting


Good Morning,



I would like to invite everyone to an interim meeting Tuesday June 5th at 16:00 
UTC for 60 minutes.



We plan to focus the discussion around two topics:



Agenda
1.   Validate draft (comments, concerns, implementations)
2.   Registry Mapping
a.   Continue the lively discussion that was started in London
b.   Policy Extension Review: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.



We will once again use Zoom as a conferencing tool, please use this 
link<https://godaddy.zoom.us/j/453206454> to connect to the meeting.

[regext] REGEXT Interim Meeting (2018JAN31) Notes

[Roger D Carney]

Meeting started at 9:04 (UTC-6)


Moderated by Roger Carney.


Attendees: Roger Carney, James Gould, Antoin Verschuren, James Galvin, Jody 
Kolker, Joe Snitker


Agenda

  1.  Introduce the Registry Mapping concepts
 *   Base Mappings
 *   Policy Extensions: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.


I briefly introduced the Registry Mapping idea and the idea of the new Policy 
document that describes all of the variable paths that an extension creates 
(SHOULD(s), MAY(s), lists, etc).


Jim Gould explained why they created the Registry Mapping, 2012 expansion, 
originally created for registrars and was created by digesting the Verisign 
Registrar documentation (Verisign uses this internally as well). Jim provided a 
link to the current Verisign version

https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v01.html.

Jim walked through this draft and the current thoughts on the changes needed to 
this Verisign draft to get to an internet-draft.


Antoin asked how this was different then the documentation that Registries 
provide in SDK manuals. Explained that this is electronically consumable, also 
that very Registry has a different format of SDK documentation, this would 
provide standard way of formatting this information. Antoin asked if other 
registries will be interested in supporting this idea and implement, we will 
need to socialize this and see.


Next steps, Jim Gould will get internal approval to move forward and we will 
submit the draft and post an introduction to the list.

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

Re: [regext] REGEXT Interim Meeting

[James Galvin]

I plan to attend.

Jim



On 17 Jan 2018, at 11:22, Roger D Carney wrote:


Good Morning,



I would like to invite everyone to an interim meeting Wednesday 
January 31st at 15:00 UTC for 60 minutes.




We plan to focus the discussion around the Registry Mapping proposal.



Agenda

  1.  Introduce the Registry Mapping concepts
 *   Base Mappings
 *   Policy Extensions: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.




We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.




Please reply to the list or directly to myself if you plan on 
attending this meeting.






Thanks

Roger




___
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

[regext] REGEXT Interim Meeting

[Roger D Carney]

Good Morning,



I would like to invite everyone to an interim meeting Wednesday January 31st at 
15:00 UTC for 60 minutes.



We plan to focus the discussion around the Registry Mapping proposal.



Agenda

  1.  Introduce the Registry Mapping concepts
 *   Base Mappings
 *   Policy Extensions: how a server implements an extension, the 
SHOULD(s), MAY(s), etc.



We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.



Please reply to the list or directly to myself if you plan on attending this 
meeting.





Thanks

Roger

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

Re: [regext] REGEXT Interim Meeting

[Patrick Mevzek]

On Wed, Jan 10, 2018, at 21:51, Roger D Carney wrote:
> Good Afternoon,
> 
> We held an interim meeting today January 10, 2018 and discussed the Fee 
> document.

Thanks Roger for the summary.

> We did not make it to discussing the Registry Mapping, we will plan to 
> have a follow-up meeting to introduce and discuss this topic.

AFAIR this point has not been discussed on the mailing-list.
Could it start there maybe first?

-- 
  Patrick Mevzek

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

[regext] REGEXT Interim Meeting

[Roger D Carney]

Good Afternoon,

We held an interim meeting today January 10, 2018 and discussed the Fee 
document.

In attendance was James Gould, Jody Kolker, Joe Snitker, Peter Koch, Antoin 
Verschuren, and Roger Carney. Scott Hollenbeck, James Galvin and Andreas Huber 
sent their regrets.

Agenda:

  1.  Fee
 *   Discuss appropriate level for , at the object level  or 
 level
 *   Discuss WG Last Call
  2.  Registry Mappings
 *   Introduce the Registry Mapping concepts

In regards to the Fee draft, we talked through the option presented on list to 
move the  to the object level and provide an optional  
attribute to allow for the command level distinction with a default of false. 
We agreed to proceed this way and an updated draft will be posted soon. 
Additionally, we agreed to remove second paragraph in 5.2.1 as it duplicates 
second to last paragraph in section 4.

We did not make it to discussing the Registry Mapping, we will plan to have a 
follow-up meeting to introduce and discuss this topic.

Again, thanks to all that participated in this call.


Thanks
Roger




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

Re: [regext] REGEXT Interim Meeting Invite

[Andreas Huber]

Hi,

I planned to attend, but unfortunately can't make it.

Regarding 1.a, as mentioned before, it "would" be very helpful to know if a 
billable transaction (create, renew, transfer, restore) is priced with a 
standard fee (based on contracts between registrars and registries) or a 
non-standard fee.
There is no need to put this information inside , any other tag or 
attribute would also work (proposed by JG). Probably the usage of  by 
some registries, to transport this information, as documented in draft version 
05 and 06, leads us to this discussion.

But well, if nobody else has this requirement, it's probably a "nice to have" 
and clients should make their decisions whether a fee is standard/non-standard 
in some other way - if a client needs it at all.

Therefore, moving  to the object level is ok for me, if it's not used 
for this case.

Best,
Andreas



Am 08.01.2018 um 17:11 schrieb Roger D Carney:
> Good Morning,
> 
>  
> 
> Thanks for email Antoin. We have had a few people indicate that they plan on 
> attending the meeting this Wednesday at 19:00UTC (Chris Cowherd, James Gould, 
> Jody Kolker, Scott Hollenbeck and of course the two chairs).
> 
>  
> 
> As a reminder for the group, here is the agenda:
> 
> 1. Fee
> 
>  a. Discuss appropriate level for , at the object level  or 
>  level
> 
>  b. Discuss WG Last Call
> 
> 2. Registry Mappings
> 
>  a. Introduce the Registry Mapping concepts
> 
>  
> 
> For agenda 1.a  we will be making the decision on how  works (command 
> or object level), so for those that have an opinion on this topic, this will 
> be the last time to discuss before the document is updated.
> 
>  
> 
>  
> 
> Thanks
> 
> Roger
> 
>  
> 
>  
> 
> *From:*Antoin Verschuren [mailto:i...@antoin.nl]
> *Sent:* Monday, January 08, 2018 9:04 AM
> *To:* Roger D Carney <rcar...@godaddy.com>
> *Cc:* regext@ietf.org
> *Subject:* Re: [regext] REGEXT Interim Meeting Invite
> 
>  
> 
> I will attend too.
> 
> But so far the chairs seem to be the only attendants?
> 
> Are there any more people that will attend?
> 
>  
> 
> I was waiting for some more respondents before scheduling the meeting.
> 
> I just submitted the official meeting request, but that would be a late 
> notice for the secretariat.
> 
>  
> 
> Roger, did you get any feedback on attendance?
> 
>  
> 
> Regards,
> 
>  
> 
> - -- 
> Antoin Verschuren
> 
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Op 13 dec. 2017, om 14:46 heeft James Galvin <gal...@elistx.com 
> <mailto:gal...@elistx.com>> het volgende geschreven:
> 
> 
> 
> I will attend.
> 
> Jim
> 
>  
> 
> On 7 Dec 2017, at 11:36, Roger D Carney wrote:
> 
> Good Morning,
> 
>  
> 
> I would like to invite everyone to an interim meeting Wednesday 
> January 10^th  at 19:00 UTC for 60 minutes.
> 
>  
> 
> We plan to discuss items around the latest version of the Fee draft 
> and to introduce a Registry Mapping proposal.
> 
>  
> 
> Agenda
> 
>  1. Fee
> 
>  1. Discuss appropriate level for , at the object level 
>  or  level
>  2. Discuss WG Last Call
> 
>  2. Registry Mappings
> 
>  1. Introduce the Registry Mapping concepts
> 
>  
> 
> We will once again use Zoom as a conferencing tool, please use this 
> link <https://godaddy.zoom.us/j/446675624> to connect to the meeting.
> 
>  
> 
> Please reply to the list or directly to myself if you plan on 
> attending this meeting.
> 
>  
> 
>  
> 
> Thanks
> 
> Roger
> 
>  
> 
> ___
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext
> 
> ___
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext
> 
>  
> 
> 
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] REGEXT Interim Meeting Invite

[Patrick Mevzek]

On Mon, Jan 8, 2018, at 17:11, Roger D Carney wrote:
> For agenda 1.a  we will be making the decision on how  works 
> (command or object level), so for those that have an opinion on this 
> topic, this will be the last time to discuss before the document is 
> updated.

I will probably not be able to take part of the meeting for technical
reasons, but I hope that you would also take into account prior discussions
by email on this topic.

-- 
  Patrick Mevzek

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

Re: [regext] REGEXT Interim Meeting Invite

[Hollenbeck, Scott]

I'm unfortunately not going to be able to make it due to a scheduling conflict.



Scott



From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Roger D Carney
Sent: Monday, January 08, 2018 11:11 AM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting Invite



Good Morning,



Thanks for email Antoin. We have had a few people indicate that they plan on 
attending the meeting this Wednesday at 19:00UTC (Chris Cowherd, James Gould, 
Jody Kolker, Scott Hollenbeck and of course the two chairs).



As a reminder for the group, here is the agenda:

1. Fee

 a. Discuss appropriate level for , at the object level  or 
 level

 b. Discuss WG Last Call

2. Registry Mappings

 a. Introduce the Registry Mapping concepts



For agenda 1.a  we will be making the decision on how  works (command or 
object level), so for those that have an opinion on this topic, this will be 
the last time to discuss before the document is updated.





Thanks

Roger





From: Antoin Verschuren [mailto:i...@antoin.nl]
Sent: Monday, January 08, 2018 9:04 AM
To: Roger D Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>
Cc: regext@ietf.org<mailto:regext@ietf.org>
Subject: Re: [regext] REGEXT Interim Meeting Invite



I will attend too.

But so far the chairs seem to be the only attendants?

Are there any more people that will attend?



I was waiting for some more respondents before scheduling the meeting.

I just submitted the official meeting request, but that would be a late notice 
for the secretariat.



Roger, did you get any feedback on attendance?



Regards,



- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392









Op 13 dec. 2017, om 14:46 heeft James Galvin 
<gal...@elistx.com<mailto:gal...@elistx.com>> het volgende geschreven:





   I will attend.

   Jim



   On 7 Dec 2017, at 11:36, Roger D Carney wrote:

  Good Morning,



  I would like to invite everyone to an interim meeting Wednesday January 
10th at 19:00 UTC for 60 minutes.



  We plan to discuss items around the latest version of the Fee draft and 
to introduce a Registry Mapping proposal.



  Agenda

  1.Fee

 a. Discuss appropriate level for , at the object level  
or  level
 b. Discuss WG Last Call

  2.Registry Mappings

 a. Introduce the Registry Mapping concepts



  We will once again use Zoom as a conferencing tool, please use this 
link<https://godaddy.zoom.us/j/446675624> to connect to the meeting.



  Please reply to the list or directly to myself if you plan on attending 
this meeting.





  Thanks

  Roger



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

   ___
   regext mailing list
   regext@ietf.org<mailto: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] REGEXT Interim Meeting Invite

[Gould, James]

Andy,

Roger and I are currently working on an Internet Draft that is based on the 
Verisign proprietary Registry Mapping extension at 
https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v01.html.
  
  
—
 
JG



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

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

Verisign.com  

On 1/8/18, 10:52 AM, "regext on behalf of Andrew Newton" 
 wrote:

What is this? Is there an I-D on it?

-andy

On Thu, Dec 7, 2017 at 11:36 AM, Roger D Carney  wrote:
>
> Introduce the Registry Mapping concepts

___
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] REGEXT Interim Meeting Invite

[Andrew Newton]

What is this? Is there an I-D on it?

-andy

On Thu, Dec 7, 2017 at 11:36 AM, Roger D Carney  wrote:
>
> Introduce the Registry Mapping concepts

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

Re: [regext] REGEXT Interim Meeting Invite

[Gould, James]

I plan on attending.


—

JG

[id: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 <regext-boun...@ietf.org> on behalf of Jody Kolker 
<jkol...@godaddy.com>
Date: Monday, January 8, 2018 at 10:44 AM
To: Antoin Verschuren <i...@antoin.nl>, Roger Carney <rcar...@godaddy.com>
Cc: "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting Invite

I will also be there.

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Moninder Jheeta 
(mjhe...@godaddy.com<mailto:mjhe...@godaddy.com>) with any feedback.

This email message and any attachments hereto is intended for use only by the 
addressee(s) named herein and may contain confidential information. If you have 
received this email in error, please immediately notify the sender and 
permanently delete the original and any copy of this message and its 
attachments.

From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Monday, January 8, 2018 9:04 AM
To: Roger D Carney <rcar...@godaddy.com>
Cc: regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting Invite

I will attend too.
But so far the chairs seem to be the only attendants?
Are there any more people that will attend?

I was waiting for some more respondents before scheduling the meeting.
I just submitted the official meeting request, but that would be a late notice 
for the secretariat.

Roger, did you get any feedback on attendance?

Regards,

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392




Op 13 dec. 2017, om 14:46 heeft James Galvin 
<gal...@elistx.com<mailto:gal...@elistx.com>> het volgende geschreven:




I will attend.

Jim


On 7 Dec 2017, at 11:36, Roger D Carney wrote:
Good Morning,

I would like to invite everyone to an interim meeting Wednesday January 10th at 
19:00 UTC for 60 minutes.

We plan to discuss items around the latest version of the Fee draft and to 
introduce a Registry Mapping proposal.

Agenda
1.  Fee
a.   Discuss appropriate level for , at the object level  or 
 level
b.  Discuss WG Last Call
2.  Registry Mappings
a.   Introduce the Registry Mapping concepts

We will once again use Zoom as a conferencing tool, please use this 
link<https://godaddy.zoom.us/j/446675624> to connect to the meeting.

Please reply to the list or directly to myself if you plan on attending this 
meeting.


Thanks
Roger


___
regext mailing list
regext@ietf.org<mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org<mailto: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] REGEXT Interim Meeting Invite

[Jody Kolker]

I will also be there.

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Moninder Jheeta 
(mjhe...@godaddy.com<mailto:mjhe...@godaddy.com>) with any feedback.

This email message and any attachments hereto is intended for use only by the 
addressee(s) named herein and may contain confidential information. If you have 
received this email in error, please immediately notify the sender and 
permanently delete the original and any copy of this message and its 
attachments.

From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Monday, January 8, 2018 9:04 AM
To: Roger D Carney <rcar...@godaddy.com>
Cc: regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting Invite

I will attend too.
But so far the chairs seem to be the only attendants?
Are there any more people that will attend?

I was waiting for some more respondents before scheduling the meeting.
I just submitted the official meeting request, but that would be a late notice 
for the secretariat.

Roger, did you get any feedback on attendance?

Regards,

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392




Op 13 dec. 2017, om 14:46 heeft James Galvin 
<gal...@elistx.com<mailto:gal...@elistx.com>> het volgende geschreven:



I will attend.

Jim


On 7 Dec 2017, at 11:36, Roger D Carney wrote:
Good Morning,

I would like to invite everyone to an interim meeting Wednesday January 10th at 
19:00 UTC for 60 minutes.

We plan to discuss items around the latest version of the Fee draft and to 
introduce a Registry Mapping proposal.

Agenda
1.  Fee
a.  Discuss appropriate level for , at the object level  or 
 level
b.  Discuss WG Last Call
2.  Registry Mappings
a.  Introduce the Registry Mapping concepts

We will once again use Zoom as a conferencing tool, please use this 
link<https://godaddy.zoom.us/j/446675624> to connect to the meeting.

Please reply to the list or directly to myself if you plan on attending this 
meeting.


Thanks
Roger


___
regext mailing list
regext@ietf.org<mailto:regext@ietf.org>
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org<mailto: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] REGEXT Interim Meeting Invite

[Antoin Verschuren]

I will attend too.
But so far the chairs seem to be the only attendants?
Are there any more people that will attend?

I was waiting for some more respondents before scheduling the meeting.
I just submitted the official meeting request, but that would be a late notice 
for the secretariat.

Roger, did you get any feedback on attendance?

Regards,

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392






Op 13 dec. 2017, om 14:46 heeft James Galvin  het volgende 
geschreven:

> I will attend.
> 
> Jim
> 
> 
> 
> On 7 Dec 2017, at 11:36, Roger D Carney wrote:
> 
> Good Morning,
> 
> 
> 
> I would like to invite everyone to an interim meeting Wednesday January 10th 
> at 19:00 UTC for 60 minutes.
> 
> 
> 
> We plan to discuss items around the latest version of the Fee draft and to 
> introduce a Registry Mapping proposal.
> 
> 
> 
> Agenda
> 
> Fee
> Discuss appropriate level for , at the object level  or  
> level
> Discuss WG Last Call
> Registry Mappings
> Introduce the Registry Mapping concepts
> 
> 
> We will once again use Zoom as a conferencing tool, please use this link to 
> connect to the meeting.
> 
> 
> 
> Please reply to the list or directly to myself if you plan on attending this 
> meeting.
> 
> 
> 
> 
> 
> Thanks
> 
> Roger
> 
> 
> 
> ___
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] REGEXT Interim Meeting Invite

[James Galvin]

I will attend.

Jim



On 7 Dec 2017, at 11:36, Roger D Carney wrote:


Good Morning,

I would like to invite everyone to an interim meeting Wednesday 
January 10th at 19:00 UTC for 60 minutes.


We plan to discuss items around the latest version of the Fee draft 
and to introduce a Registry Mapping proposal.


Agenda

  1.  Fee
 *   Discuss appropriate level for , at the object level 
 or  level

 *   Discuss WG Last Call
  2.  Registry Mappings
 *   Introduce the Registry Mapping concepts

We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.


Please reply to the list or directly to myself if you plan on 
attending this meeting.



Thanks
Roger




___
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

[regext] REGEXT Interim Meeting Invite

[Roger D Carney]

Good Morning,

I would like to invite everyone to an interim meeting Wednesday January 10th at 
19:00 UTC for 60 minutes.

We plan to discuss items around the latest version of the Fee draft and to 
introduce a Registry Mapping proposal.

Agenda

  1.  Fee
 *   Discuss appropriate level for , at the object level  or 
 level
 *   Discuss WG Last Call
  2.  Registry Mappings
 *   Introduce the Registry Mapping concepts

We will once again use Zoom as a conferencing tool, please use this 
link to connect to the meeting.

Please reply to the list or directly to myself if you plan on attending this 
meeting.


Thanks
Roger

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

[regext] REGEXT Interim Meeting

[Roger D Carney]

Good Afternoon,

We held an interim meeting on October 11th, 2017 to discuss the current Fee and 
Validate draft documents.

In attendance was Jody Kolker, Antoin Verschuren, James Galvin, and Roger 
Carney. Alex Mayrhofer sent his regrets.

Agenda:

  1.  Fee
 *   Confirm Edits (section 3.8 and section 4.0)
 *   Discuss WG Last Call
  2.  Validate
 *   A validate/verification framework discussion
 *   Validate group processing of contacts

With the limited number of participants the only topic we briefly discussed was 
the Fee document and that we have a few more minor edits (coming from 
implementation findings) for a revision 9 and that revision should be ready for 
last call. This next revision will be publish prior to IETF-100.

Again, thanks to all that participated in this call, hopefully we can get more 
participation in future meetings.


Thanks
Roger



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

Re: [regext] REGEXT Interim Meeting

[Jody Kolker]

Thanks Jim.

<<
.  If there is no active launch phase or if there is only one active launch 
phase, then the server should return the current fee that is associated with 
the TLD.
>>

If there is no active phase, what is the current fee?  The fee when the 
registry is in an “open” phase?

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall 
(cbeadn...@godaddy.com<mailto:cbeadn...@godaddy.com>) with any feedback.

This email message and any attachments hereto is intended for use only by the 
addressee(s) named herein and may contain confidential information. If you have 
received this email in error, please immediately notify the sender and 
permanently delete the original and any copy of this message and its 
attachments.


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Friday, September 01, 2017 1:00 PM
To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

I believe that we’re pulling hairs when it comes to the handling of a “quiet 
period”.  My recommendation is remove any reference to a “quiet period” within 
draft-ietf-regext-epp-fees, since I don’t believe there is an agreed upon 
definition of a “quiet period”.  I believe that you’re attempting to cover the 
behavior for the three cases:


1.  No active launch phase – Which is what you’re calling a “quiet period”

2.  One active launch phase

3.  More than one active launch phase

The only case that can potentially be an issue for the client that doesn’t pass 
the launch phase is when there is more than one active launch phase and the fee 
is dependent on the launch phase.  There may be a case where there are multiple 
active launch phases that has nothing to do with the fee (e.g., eligibility 
policy, allocation policy), which should simply return the current fee.  If 
there is no active launch phase or if there is only one active launch phase, 
then the server should return the current fee that is associated with the TLD.  
A fee may or may not be available for the TLD, which is already covered by the 
 “avail” flag.

The language in 3.8 “Phase and Subphase Attributes” should describe the ability 
for the client to explicitly specify the phase and subphase when the client 
wants to target a future phase and subphase or they need to clarify which 
current phase and subphase to get the fee for only if there are multiple active 
launch phases that the fee is dependent on.

There is no need to specify the server behavior for zero or one or even 
multiple launch phases if the launch phase is not relavant to the fee returned.

—

JG

[id: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 <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on 
behalf of Roger Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>
Date: Friday, September 1, 2017 at 12:08 PM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Hi James,

After rereading the  commands in RFC 5730 and 5731, I do agree with you 
that it appears the RFCs intended (Scott Hollenbeck may provide clarity) the 
 command to return “avail=0” during a “quiet period” even though “quiet 
period” was not mentioned specifically or defined in these RFCs. I just want to 
recognize in practice today this is not always the case, some registries return 
“avail=1” on  commands processed during quiet periods if the name has 
not been registered.

So in reference to the Fee draft I am recommending that paragraph 5 of section 
3.8 be changed from:

“If the client  contains no phase/subphase attributes and the 
server is currently in a "quiet period" (e.g. not accepting registrations or 
applications) the server MUST return data consistent with the general 
availability phase.”

to

“If the client  contains no phase/subphase attributes and the 
server is currently in a "quiet period" (e.g. not accepting registrations or 
applications) the server MUST return data consistent with RFCs 5730 and 5731 
and MUST include a  in the response extension.”

Should we force a specific reason (e.g. Quiet period, please 
provide appropriate phase details for fee information.)?

Does anyone else have thoughts on this rewording?


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Friday, August 25, 2017 12:22 PM
To: Roger D Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

It’s not clear what the “quiet period” is.  Is it really part of the open 
phase, is it a sub-phase, or is it a gap bet

Re: [regext] REGEXT Interim Meeting

[Gould, James]

Roger,

It’s not clear what the “quiet period” is.  Is it really part of the open 
phase, is it a sub-phase, or is it a gap between phases?  Without a clear 
definition of what a “quiet period” is, I believe it is difficult to define the 
expected behavior for it in the registry fee extension.  My recommendation is 
to define the registry fee draft to cover one or more active phases, where a 
TLD should always be in at least one defined phase (“sunrise”, “landrush”, 
“claims”, “open”, or “custom”), where a “quiet period” may be a custom phase 
that does not require special handling in the registry fee extension.  The 
registrars are not required to implement draft-ietf-regext-launchphase, but 
should be aware of the possible set of phases the TLD operates in when 
determining the target fee.  If the registrar is unaware of the phases, then 
the server will respond based on the current active phase(s) according to what 
is defined in the registry fee extension (e.g., fee of the current phase if 
there is just one or an error if there is more than one phase).


—

JG

[id: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 <regext-boun...@ietf.org> on behalf of Roger Carney 
<rcar...@godaddy.com>
Date: Friday, August 25, 2017 at 12:33 PM
To: "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Hi James,

So you are suggesting the “quiet period” is a distinct phase. As I was 
suggesting the “quiet period” is the “open” phase, I don’t think that is an 
exception to the rule, just defining “quiet period.”

If we write it into the document, there is no assuming/forecasting of client 
desire.

I do want to sort of retract my presumption from my previous email to the list. 
There are registrars that did not implement draft-ietf-regext-launchphase, but 
the link to fee is really not appropriate.


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Thursday, August 24, 2017 2:43 PM
To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

I don’t believe it is clean to assume the capabilities or desire of the client 
when the current phase is a quiet period by defaulting the return to the “open” 
/ general registration phase.  When there is an active phase the behavior is to 
return the fee for the active phase by default.  If you consider the quiet 
period a phase (null or explicitly the custom “quiet” period) then why would 
you make an exception to that rule?  A client submitting pre-registration 
availability checks needs to be aware of what they’re looking for (fee during 
“sunrise”, fee during “claims”, fee during “open”), and the protocol should not 
attempt to forecast the clients desire.


—

JG

[cid:image002.png@01D31DA5.12EB3490]

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

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

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

From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on 
behalf of Roger Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>
Date: Thursday, August 24, 2017 at 3:31 PM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Good Afternoon,

For the quiet period, I think you provide a clean proposal of using “open” but 
I have one “compatibility/legacy” concern. There are registrars that do not 
participate in “launches/phases”, for various reasons I am sure. Some of these 
registrars most likely never implemented draft-ietf-regext-launchphase, which 
would mean any “pre-registration” availability checks from these registrars 
would return unavailable. I don’t think that we would want to exclude these 
potential registrations.


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Thursday, August 24, 2017 8:03 AM
To: Roger D Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

Thanks for hosting this meeting.  Unfortunately, I was not able to participate 
in the meeting.  I include some points below based on review of 
draft-ietf-regext-epp-fees-06 and the minutes:

1.   I agree that we shouldn’t mix launch phase detection into the fee 
extension, and this is best suited for a draft specifically designed for policy 
and feature detection like the Registry Mapping.
2.   The “quiet period” is not formally defined, but if it were I would 
define as a period when there is no active launch phase (null launch phase) or 
when there is a launch phase that does not accept any registrations or 
applications (custom “quiet” launch phase).  In 

Re: [regext] REGEXT Interim Meeting

[Roger D Carney]

Hi James,

So you are suggesting the “quiet period” is a distinct phase. As I was 
suggesting the “quiet period” is the “open” phase, I don’t think that is an 
exception to the rule, just defining “quiet period.”

If we write it into the document, there is no assuming/forecasting of client 
desire.

I do want to sort of retract my presumption from my previous email to the list. 
There are registrars that did not implement draft-ietf-regext-launchphase, but 
the link to fee is really not appropriate.


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Thursday, August 24, 2017 2:43 PM
To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

I don’t believe it is clean to assume the capabilities or desire of the client 
when the current phase is a quiet period by defaulting the return to the “open” 
/ general registration phase.  When there is an active phase the behavior is to 
return the fee for the active phase by default.  If you consider the quiet 
period a phase (null or explicitly the custom “quiet” period) then why would 
you make an exception to that rule?  A client submitting pre-registration 
availability checks needs to be aware of what they’re looking for (fee during 
“sunrise”, fee during “claims”, fee during “open”), and the protocol should not 
attempt to forecast the clients desire.


—

JG

[id: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 <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on 
behalf of Roger Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>
Date: Thursday, August 24, 2017 at 3:31 PM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Good Afternoon,

For the quiet period, I think you provide a clean proposal of using “open” but 
I have one “compatibility/legacy” concern. There are registrars that do not 
participate in “launches/phases”, for various reasons I am sure. Some of these 
registrars most likely never implemented draft-ietf-regext-launchphase, which 
would mean any “pre-registration” availability checks from these registrars 
would return unavailable. I don’t think that we would want to exclude these 
potential registrations.


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Thursday, August 24, 2017 8:03 AM
To: Roger D Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

Thanks for hosting this meeting.  Unfortunately, I was not able to participate 
in the meeting.  I include some points below based on review of 
draft-ietf-regext-epp-fees-06 and the minutes:

1.   I agree that we shouldn’t mix launch phase detection into the fee 
extension, and this is best suited for a draft specifically designed for policy 
and feature detection like the Registry Mapping.
2.   The “quiet period” is not formally defined, but if it were I would 
define as a period when there is no active launch phase (null launch phase) or 
when there is a launch phase that does not accept any registrations or 
applications (custom “quiet” launch phase).  In either case, I believe that if 
the phase / sub-phase is not supplied by the client that the fee should be 
returned in context to the current launch phase.  If no registrations or 
applications are allowed during the current launch phase (null or custom 
“quiet” launch phase) then the fee should come back as unavailable.  Returning 
the fee as if the active phase is the “open” phase (general availability) does 
not seem to match the default behavior of returning the fee according to the 
current active phase.  The client can pass the “open” phase explicitly if they 
needed to determine the fee for that future phase.
3.   The Validate extension meets a similar purpose as the policy and 
feature detection of the Registry Mapping, where the Registry Mapping provides 
TLD level service, policy, and feature information that enables the client to 
automate their configuration.  The Validate extension implements a pre-check of 
the contact policy using real data.  One option for the Validate extension that 
we discussed in the past is providing a pre-check extension (e.g., no-op) to 
the domain mapping or the contact mapping, but the issue with the pre-check 
(e.g., no-op) extension is that a registrar may need to create a set of objects 
(contacts, hosts, and domains) that are validated against the server policy at 
the time of the domain create.  The Registry Mapping provides meta-data to 
drive client policy discovery and configuration and the Validate extension 
provides a pre-check or test of contact p

Re: [regext] REGEXT Interim Meeting

[Gould, James]

Jody,

That is a good question.  We haven’t had a “quiet” period, so from my 
perspective this is theoretical.  My guess is that during a “quiet” period the 
domain would be returned as available, since it hasn’t been registered.  It 
makes sense to return the fee as being unavailable if there is no fee set for a 
“quiet” period.


—

JG

[id: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: Jody Kolker <jkol...@godaddy.com>
Date: Friday, August 25, 2017 at 10:50 AM
To: James Gould <jgo...@verisign.com>, Roger Carney <rcar...@godaddy.com>, 
"regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] RE: [regext] REGEXT Interim Meeting

Hi guys,

Just a general question for this area.  If the registrar does not send in a 
phase or fee extension in a domain:check command for a standard name during a 
quiet period, would the domain:check return available or unavailable (assuming 
the domain is not registered and not on any type of reserved list basically the 
domain could be registered if the domain was not in a quiet period).

Thanks,
Jody Kolker
319-294-3933 (office)


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Thursday, August 24, 2017 2:43 PM
To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

I don’t believe it is clean to assume the capabilities or desire of the client 
when the current phase is a quiet period by defaulting the return to the “open” 
/ general registration phase.  When there is an active phase the behavior is to 
return the fee for the active phase by default.  If you consider the quiet 
period a phase (null or explicitly the custom “quiet” period) then why would 
you make an exception to that rule?  A client submitting pre-registration 
availability checks needs to be aware of what they’re looking for (fee during 
“sunrise”, fee during “claims”, fee during “open”), and the protocol should not 
attempt to forecast the clients desire.


—

JG

[cid:image002.png@01D31D92.9F87E370]

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

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

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

From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on 
behalf of Roger Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>
Date: Thursday, August 24, 2017 at 3:31 PM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Good Afternoon,

For the quiet period, I think you provide a clean proposal of using “open” but 
I have one “compatibility/legacy” concern. There are registrars that do not 
participate in “launches/phases”, for various reasons I am sure. Some of these 
registrars most likely never implemented draft-ietf-regext-launchphase, which 
would mean any “pre-registration” availability checks from these registrars 
would return unavailable. I don’t think that we would want to exclude these 
potential registrations.


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Thursday, August 24, 2017 8:03 AM
To: Roger D Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

Thanks for hosting this meeting.  Unfortunately, I was not able to participate 
in the meeting.  I include some points below based on review of 
draft-ietf-regext-epp-fees-06 and the minutes:

1.   I agree that we shouldn’t mix launch phase detection into the fee 
extension, and this is best suited for a draft specifically designed for policy 
and feature detection like the Registry Mapping.
2.   The “quiet period” is not formally defined, but if it were I would 
define as a period when there is no active launch phase (null launch phase) or 
when there is a launch phase that does not accept any registrations or 
applications (custom “quiet” launch phase).  In either case, I believe that if 
the phase / sub-phase is not supplied by the client that the fee should be 
returned in context to the current launch phase.  If no registrations or 
applications are allowed during the current launch phase (null or custom 
“quiet” launch phase) then the fee should come back as unavailable.  Returning 
the fee as if the active phase is the “open” phase (general availability) does 
not seem to match the default behavior of returning the fee according to the 
current active phase.  The client can pass the “open” phase explicitly if they 
needed to determine the fee for that future phase.
3.   The Validate extension meets a similar purpose as the policy and 
feature detection of the Registry Mapping, where the Registry Map

Re: [regext] REGEXT Interim Meeting

[Jody Kolker]

Hi guys,

Just a general question for this area.  If the registrar does not send in a 
phase or fee extension in a domain:check command for a standard name during a 
quiet period, would the domain:check return available or unavailable (assuming 
the domain is not registered and not on any type of reserved list basically the 
domain could be registered if the domain was not in a quiet period).

Thanks,
Jody Kolker
319-294-3933 (office)


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Thursday, August 24, 2017 2:43 PM
To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

I don’t believe it is clean to assume the capabilities or desire of the client 
when the current phase is a quiet period by defaulting the return to the “open” 
/ general registration phase.  When there is an active phase the behavior is to 
return the fee for the active phase by default.  If you consider the quiet 
period a phase (null or explicitly the custom “quiet” period) then why would 
you make an exception to that rule?  A client submitting pre-registration 
availability checks needs to be aware of what they’re looking for (fee during 
“sunrise”, fee during “claims”, fee during “open”), and the protocol should not 
attempt to forecast the clients desire.


—

JG

[id: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 <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on 
behalf of Roger Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>
Date: Thursday, August 24, 2017 at 3:31 PM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Good Afternoon,

For the quiet period, I think you provide a clean proposal of using “open” but 
I have one “compatibility/legacy” concern. There are registrars that do not 
participate in “launches/phases”, for various reasons I am sure. Some of these 
registrars most likely never implemented draft-ietf-regext-launchphase, which 
would mean any “pre-registration” availability checks from these registrars 
would return unavailable. I don’t think that we would want to exclude these 
potential registrations.


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Thursday, August 24, 2017 8:03 AM
To: Roger D Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

Thanks for hosting this meeting.  Unfortunately, I was not able to participate 
in the meeting.  I include some points below based on review of 
draft-ietf-regext-epp-fees-06 and the minutes:

1.   I agree that we shouldn’t mix launch phase detection into the fee 
extension, and this is best suited for a draft specifically designed for policy 
and feature detection like the Registry Mapping.
2.   The “quiet period” is not formally defined, but if it were I would 
define as a period when there is no active launch phase (null launch phase) or 
when there is a launch phase that does not accept any registrations or 
applications (custom “quiet” launch phase).  In either case, I believe that if 
the phase / sub-phase is not supplied by the client that the fee should be 
returned in context to the current launch phase.  If no registrations or 
applications are allowed during the current launch phase (null or custom 
“quiet” launch phase) then the fee should come back as unavailable.  Returning 
the fee as if the active phase is the “open” phase (general availability) does 
not seem to match the default behavior of returning the fee according to the 
current active phase.  The client can pass the “open” phase explicitly if they 
needed to determine the fee for that future phase.
3.   The Validate extension meets a similar purpose as the policy and 
feature detection of the Registry Mapping, where the Registry Mapping provides 
TLD level service, policy, and feature information that enables the client to 
automate their configuration.  The Validate extension implements a pre-check of 
the contact policy using real data.  One option for the Validate extension that 
we discussed in the past is providing a pre-check extension (e.g., no-op) to 
the domain mapping or the contact mapping, but the issue with the pre-check 
(e.g., no-op) extension is that a registrar may need to create a set of objects 
(contacts, hosts, and domains) that are validated against the server policy at 
the time of the domain create.  The Registry Mapping provides meta-data to 
drive client policy discovery and configuration and the Validate extension 
provides a pre-check or test of contact policy using real contact data.  I view 
the Allocat

Re: [regext] REGEXT Interim Meeting

[James Galvin]

The minutes have been uploaded to the proceedings.

If there are any corrections please make that known and I will upload a 
revised version.


Thanks for hosting this meeting!

Jim



On 23 Aug 2017, at 16:52, Roger D Carney wrote:


Good Afternoon,

We held an interim meeting this morning and discussed the current Fee 
draft document (draft-ietf-regext-epp-fees-06) and the Validate draft 
document (draft-ietf-regext-validate-02).


In attendance was Jody Kolker, Antoin Verschuren, Alex Mayrhofer, 
James Galvin, Dean Farwell, Andreas Huber and Roger Carney.


Agenda:

  1.  Fee
 *   Confirm Edits (scheme, section 3.8 and reference)
 *   Discuss "Quiet Period": section 3.8 paragraph 5
 *   Discuss WG Last Call
  2.  Validate
 *   Re-introduce
 *   Comments/Questions
  3.  TLD Phase Mapping

We started the meeting by confirming that the current revision of the 
document (v6) addressed all currently known issues.


Jim Galvin mentioned that we may need to resolve TLD phase detection 
to make it easier for this draft to move forward as detection (at 
least in simple form) was removed in the last draft. We spent a few 
minutes on this and recalled some of the reasons given for removal, 
e.g. complexity and not a true fit for this draft. We discussed the 
idea of pulling this into the proposed Registry Mapping draft. We also 
discussed if the authors were opposed to detection being in the Fee 
draft and I confirmed that I was not completely against including but 
I do believe the reasons everyone provided for not including makes 
sense and that it seems more appropriate in the Registry Mapping 
draft.


We spent a good amount of time, roughly 35 minutes focused on section 
3.8 describing Phase/Subphase. Alex mentioned that 3.8 does not 
clearly address the scenario of a server not supporting 
phase/subphase. Alex will provide some language and we will work into 
the next draft. Discussion continued on the "comfort" idea of phase 
detection: "Should we allow servers to provide responses with multiple 
phases/subphases in the same response?" We generally agreed that the 
added complexity and cost associated with this did not outweigh the 
possible benefits and that we would stay with the v6 language around 
this (if client does not supply and only one exists return the one and 
if multiple exist return error).


No one on the call raised any concerns with the "Quiet Period" in 
section 3.8 paragraph 5. Please review and express any concerns.


The Chairs did indicate that once we get general agreement on the list 
for the Fee draft we can move this draft to WG last call. At this 
point I believe we are in a good state with v6 plus the addition of 
Alex's suggested text on servers that may not have phase support. 
Please respond to the list if you agree or disagree.


We moved the discussion onto Validate and Jody provided an overview of 
the problem space and the proposed solution. There was a general 
agreement that this proposal sounds good and seems like a logical 
business issue to resolve. There was some discussion on the possible 
need to be able to refine this "validate" down to the exact domain 
name. The draft does allow for this though it was not in the original 
goals. Jim and Antoin talked about this whole "validate" concept 
possibly being larger and may need to examined in totality (e.g. with 
allocation token and verification code). Do they belong together or 
stay separate, should there be a "higher" framework that pulls 
together the idea of validation/verification?


If anyone has any additional thoughts on these topics or new topics 
for these documents please let us know.


Again, thanks to all that were able to participate this morning, it 
was a very productive meeting.



Thanks
Roger




___
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] REGEXT Interim Meeting

[Gould, James]

Roger,

I don’t believe it is clean to assume the capabilities or desire of the client 
when the current phase is a quiet period by defaulting the return to the “open” 
/ general registration phase.  When there is an active phase the behavior is to 
return the fee for the active phase by default.  If you consider the quiet 
period a phase (null or explicitly the custom “quiet” period) then why would 
you make an exception to that rule?  A client submitting pre-registration 
availability checks needs to be aware of what they’re looking for (fee during 
“sunrise”, fee during “claims”, fee during “open”), and the protocol should not 
attempt to forecast the clients desire.


—

JG

[id: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 <regext-boun...@ietf.org> on behalf of Roger Carney 
<rcar...@godaddy.com>
Date: Thursday, August 24, 2017 at 3:31 PM
To: "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting

Good Afternoon,

For the quiet period, I think you provide a clean proposal of using “open” but 
I have one “compatibility/legacy” concern. There are registrars that do not 
participate in “launches/phases”, for various reasons I am sure. Some of these 
registrars most likely never implemented draft-ietf-regext-launchphase, which 
would mean any “pre-registration” availability checks from these registrars 
would return unavailable. I don’t think that we would want to exclude these 
potential registrations.


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Thursday, August 24, 2017 8:03 AM
To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

Thanks for hosting this meeting.  Unfortunately, I was not able to participate 
in the meeting.  I include some points below based on review of 
draft-ietf-regext-epp-fees-06 and the minutes:

1.   I agree that we shouldn’t mix launch phase detection into the fee 
extension, and this is best suited for a draft specifically designed for policy 
and feature detection like the Registry Mapping.
2.   The “quiet period” is not formally defined, but if it were I would 
define as a period when there is no active launch phase (null launch phase) or 
when there is a launch phase that does not accept any registrations or 
applications (custom “quiet” launch phase).  In either case, I believe that if 
the phase / sub-phase is not supplied by the client that the fee should be 
returned in context to the current launch phase.  If no registrations or 
applications are allowed during the current launch phase (null or custom 
“quiet” launch phase) then the fee should come back as unavailable.  Returning 
the fee as if the active phase is the “open” phase (general availability) does 
not seem to match the default behavior of returning the fee according to the 
current active phase.  The client can pass the “open” phase explicitly if they 
needed to determine the fee for that future phase.
3.   The Validate extension meets a similar purpose as the policy and 
feature detection of the Registry Mapping, where the Registry Mapping provides 
TLD level service, policy, and feature information that enables the client to 
automate their configuration.  The Validate extension implements a pre-check of 
the contact policy using real data.  One option for the Validate extension that 
we discussed in the past is providing a pre-check extension (e.g., no-op) to 
the domain mapping or the contact mapping, but the issue with the pre-check 
(e.g., no-op) extension is that a registrar may need to create a set of objects 
(contacts, hosts, and domains) that are validated against the server policy at 
the time of the domain create.  The Registry Mapping provides meta-data to 
drive client policy discovery and configuration and the Validate extension 
provides a pre-check or test of contact policy using real contact data.  I view 
the Allocation Token and Verification Code extensions serving a completely 
different purpose of authorizing the allocation of a domain name via an 
allocation token and enabling the client to provide proof of one or more forms 
of verification in meeting one or more verification profiles, respectively.  In 
summary, I would group the Validate extension and the Registry Mapping in one 
bucket of discovering the verifying policy, and the Allocation Token and the 
Verification Code extensions in another bucket of providing tokens or codes to 
apply different policies (allocation and verification).

—

JG

[cid:image002.png@01D31CEF.BA4E4710]

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

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

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

From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> o

Re: [regext] REGEXT Interim Meeting

[Roger D Carney]

Good Afternoon,

For the quiet period, I think you provide a clean proposal of using “open” but 
I have one “compatibility/legacy” concern. There are registrars that do not 
participate in “launches/phases”, for various reasons I am sure. Some of these 
registrars most likely never implemented draft-ietf-regext-launchphase, which 
would mean any “pre-registration” availability checks from these registrars 
would return unavailable. I don’t think that we would want to exclude these 
potential registrations.


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Thursday, August 24, 2017 8:03 AM
To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

Thanks for hosting this meeting.  Unfortunately, I was not able to participate 
in the meeting.  I include some points below based on review of 
draft-ietf-regext-epp-fees-06 and the minutes:


  1.  I agree that we shouldn’t mix launch phase detection into the fee 
extension, and this is best suited for a draft specifically designed for policy 
and feature detection like the Registry Mapping.
  2.  The “quiet period” is not formally defined, but if it were I would define 
as a period when there is no active launch phase (null launch phase) or when 
there is a launch phase that does not accept any registrations or applications 
(custom “quiet” launch phase).  In either case, I believe that if the phase / 
sub-phase is not supplied by the client that the fee should be returned in 
context to the current launch phase.  If no registrations or applications are 
allowed during the current launch phase (null or custom “quiet” launch phase) 
then the fee should come back as unavailable.  Returning the fee as if the 
active phase is the “open” phase (general availability) does not seem to match 
the default behavior of returning the fee according to the current active 
phase.  The client can pass the “open” phase explicitly if they needed to 
determine the fee for that future phase.
  3.  The Validate extension meets a similar purpose as the policy and feature 
detection of the Registry Mapping, where the Registry Mapping provides TLD 
level service, policy, and feature information that enables the client to 
automate their configuration.  The Validate extension implements a pre-check of 
the contact policy using real data.  One option for the Validate extension that 
we discussed in the past is providing a pre-check extension (e.g., no-op) to 
the domain mapping or the contact mapping, but the issue with the pre-check 
(e.g., no-op) extension is that a registrar may need to create a set of objects 
(contacts, hosts, and domains) that are validated against the server policy at 
the time of the domain create.  The Registry Mapping provides meta-data to 
drive client policy discovery and configuration and the Validate extension 
provides a pre-check or test of contact policy using real contact data.  I view 
the Allocation Token and Verification Code extensions serving a completely 
different purpose of authorizing the allocation of a domain name via an 
allocation token and enabling the client to provide proof of one or more forms 
of verification in meeting one or more verification profiles, respectively.  In 
summary, I would group the Validate extension and the Registry Mapping in one 
bucket of discovering the verifying policy, and the Allocation Token and the 
Verification Code extensions in another bucket of providing tokens or codes to 
apply different policies (allocation and verification).

—

JG

[id: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 <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on 
behalf of Roger Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>
Date: Wednesday, August 23, 2017 at 4:52 PM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] [regext] REGEXT Interim Meeting

Good Afternoon,

We held an interim meeting this morning and discussed the current Fee draft 
document (draft-ietf-regext-epp-fees-06) and the Validate draft document 
(draft-ietf-regext-validate-02).

In attendance was Jody Kolker, Antoin Verschuren, Alex Mayrhofer, James Galvin, 
Dean Farwell, Andreas Huber and Roger Carney.

Agenda:
1.   Fee
a.   Confirm Edits (scheme, section 3.8 and reference)
b.   Discuss “Quiet Period”: section 3.8 paragraph 5
c.   Discuss WG Last Call
2.   Validate
a.   Re-introduce
b.   Comments/Questions
3.   TLD Phase Mapping

We started the meeting by confirming that the current revision of the document 
(v6) addressed all currently known issues.

Jim Galvin mentioned that we may need to resolve TLD phase detection to make it 
easier for this draft to move forward

Re: [regext] REGEXT Interim Meeting

[Roger D Carney]

Good Morning,

Thanks Karl. Interesting, we had a very similar discussion as we were drafting 
this document. I believe we had some text describing this but we couldn’t get 
the language worked out so we pulled it. The intent is that whatever contacts 
are sent by the client they would be processed by the sever as a whole. We will 
look to add clarity to the document.

Agreed, there will be some scenarios that this draft will not be able to 
resolve completely.


Thanks
Roger


From: Karl Heinz Wolf [mailto:khwo...@gmail.com]
Sent: Thursday, August 24, 2017 3:02 AM
To: Roger D Carney <rcar...@godaddy.com>
Cc: regext@ietf.org
Subject: Re: [regext] REGEXT Interim Meeting

On Wed, Aug 23, 2017 at 10:52 PM, Roger D Carney 
<rcar...@godaddy.com<mailto:rcar...@godaddy.com>> wrote:

We moved the discussion onto Validate and Jody provided an overview of the 
problem space and the proposed solution. There was a general agreement that 
this proposal sounds good and seems like a logical business issue to resolve. 
There was some discussion on the possible need to be able to refine this 
“validate” down to the exact domain name. The draft does allow for this though 
it was not in the original goals. Jim and Antoin talked about this whole 
“validate” concept possibly being larger and may need to examined in totality 
(e.g. with allocation token and verification code). Do they belong together or 
stay separate, should there be a “higher” framework that pulls together the 
idea of validation/verification?


What might also be necessary to consider for validation: there are geoTLDs that 
do not require a certain contact type to be out of their region, but rather the 
policy says that either the registrant or the tech-c or the admin-c have to be 
out of that region. The draft allows to state multiple contact types in one 
check command, but currently the text does not say if these contacts are 
validated separately or if all these contacts are considered to be then linked 
to the same domain.
Another situation that seems not be discussed in this meeting is community TLDs 
with policies that do out of band validation and accept several different 
proofs that you belong to that community. So it is not as simple as the VATID 
example in the draft. Hence, I’m not sure if the key value mechanism could 
easily cover such scenarios.

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