Re: [regext] draft-ietf-regext-epp-eai Path Forward

[Roger D Carney]

+1 on cardinality of one

From: regext  on behalf of Dmitry Belyavsky 

Sent: Thursday, March 2, 2023 7:03 AM
To: Gould, James 
Cc: regext@ietf.org 
Subject: Re: [regext] draft-ietf-regext-epp-eai Path Forward

Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.



Dear colleagues,

I also support the cardinality of one.

On Thu, Mar 2, 2023 at 1:50 PM Gould, James 
mailto:40verisign@dmarc.ietf.org>> 
wrote:

I’ve discussed the path forward for draft-ietf-regext-epp-eai with some working 
group participates and I have concern of the current path that the draft is 
taking with the support for an alternate e-mail address, whether it be either 
ASCII, SMTPUTF8, or either.  There are system and policy impacts associated 
with the requirement to collect and transmit an additional e-mail address 
across EPP RFCs (e.g., RFC 5733, RFC 7848, RFC 8543), where the end goal of 
draft-ietf-regext-epp-eai was to support the use of SMTPUTF8 e-mail values with 
the appropriate signaling by the server and client.  I realize that the term 
“cardinality” was not popular with some, but the inclusion of an alternative 
e-mail across all EPP extensions that include an e-mail address does make a 
crosscutting cardinality change from one to two.  The registry needs to support 
either ASCII or SMTPUTF8 addresses to enable the registrars, which have the 
relationship with the registrant, to make the decision what form of e-mail to 
accept.  In hindsight, I believe the “Change of Cardinality to One or Two 
(ASCII or SMTPUTF8)” recommendation from the IETF-115 REGEXT meeting that was 
incorporated into draft-ietf-regext-epp-eai-17 is the wrong option.  We should 
keep the cardinality of one to provide the needed support for SMTPUTF8 in the 
registry for the registrars to make the decision what to collect and pass to 
the registry.  I provide the options below for consideration by the working 
group:

  1.  Cardinality of One – The approach taken in draft-ietf-regext-epp-eai-16, 
where the server (registry) supports either SMTPUTF8 or ASCII addresses for a 
decision by the client (registrar).
  2.  Cardinality of Two – The approach taken in draft-ietf-regext-epp-eai-17, 
where the server (registry) supports an alternative email element during a 
transition period that requires one email element to be ASCII.  There are two 
sub-options based on the recent discussion:
 *   Alternative Email can be ASCII or SMTPUTF8
 *   Alternative Email is only ASCII

My preference is Cardinality of One that would roll back to 
draft-ietf-regext-epp-eai-16.  Please respond to the mailing list with your 
preference or any other options that should be considered.

Thanks,



--



JG

[cid:186a26b461f4cff311]

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

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

Verisign.com

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


--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

[Roger D Carney]

Good Afternoon,

Thanks Jim and Rick, I agree that option B looks like the best collaborative 
option.


Thanks
Roger


From: regext  on behalf of Rick Wilhelm 

Sent: Friday, June 24, 2022 11:37 AM
To: Gould, James ; 
mario.loffr...@iit.cnr.it ; 
shollenbeck=40verisign@dmarc.ietf.org 
; regext@ietf.org 
Subject: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.



I have been watching this discussion with great interest.  Thanks to Jim Gould 
for the below.  As it’s been a week and no one has commented on this summary, I 
will assume that prior participants view the below as largely reasonable.



In considering the below, I’ll offer the observations related to two key 
use-cases related to implementers.



Use-case:  Determine the version from the conformance identifier:



Approach A:  The version information is in the prefix, probably at the end and 
without a defined separator (in all examples I’ve seen).  The most logical 
place for the version is at the END of the prefix and therefore, the version is 
placed in the middle of the conformance identifier.  While a reader can detect 
the version by looking closely, this seems like a big disadvantage for an 
implementer seeking to parse the conformance identifier.  I would have a hard 
time writing that code.  Others might be better programmers.



Approach B/C:  Version information at the end; using the underbar.  Seems easy 
to parse via code.  Super-easy to read.





Implementers need to be able to determine the version quickly and reliably in 
code.  For this, either Approach B or Approach C is the better fit.  Approach A 
works for human readers, but not for code.





Use-case:  Interacting with IANA Registry as an extension implementer:



Approach A:  Create a new registry entry when creating a new extension or when 
the version changes.   Registry entry integrates version. Benefit:  IANA 
registry has full record of all versions.  Drawback:  Seems hard to express 
version compatibility.



Approach B:  Create a new registry entry when creating a new extension, but NO 
interaction required when creating a version.



Approach C:  Create a new registry entry when creating a new extension.  Create 
a new versioned extension identifier when creating a new version of an existing 
extension.   Registry entry decoupled from versioning. Benefit:  IANA registry 
has full record of all versions.





In my experience, IANA registries are typically managed to avoid namespace 
collision.  They do not typically have an explicit mechanism for versioning.  
For example:



https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1

https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#epp-extensions-1



If client-side implementers used the IANA RDAP Extensions registry for 
discovery, then it might make sense to have some versioning mechanism.  
However, unlike the various RDAP Bootstrap registries, I do not believe that 
the IANA RDAP Extensions registry is used for discovery.



This would tilt the decision in favor of B because it results in a simpler RDAP 
Extensions registry.



I wonder if, over the long term, Approach A might discourage protocol evolution 
because the version information is embedded.





Regardless, when looking at the combination of these use-cases, I think that 

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

[Roger D Carney]

+1


From: regext  on behalf of Antoin Verschuren 

Sent: Monday, December 20, 2021 7:55 AM
To: regext@ietf.org 
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

You don't often get email from ietf=40antoin...@dmarc.ietf.org. Learn why this 
is important
Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.



Dear WG,

This WGLC will end tonight, and so far we only have 2 explicit voices of 
support.
This is a bit low to declare consensus. Could more people voice their support?
Scott, can you confirm that the changes in version 05 address your initial 
concerns?

- --
Antoin Verschuren

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






Op 19 dec. 2021, om 19:11 heeft Dmitry Belyavsky 
mailto:beld...@gmail.com>> het volgende geschreven:



On Sat, Dec 18, 2021 at 2:53 PM Taras Heichenko 
mailto:ta...@academ.kiev.ua>> wrote:


> On 15 Dec 2021, at 16:14, Dmitry Belyavsky 
> mailto:beld...@gmail.com>> wrote:
>
> Dear Taras.

Dear Dmitry

>
> On Tue, Dec 14, 2021 at 8:13 PM Taras Heichenko 
> mailto:ta...@academ.kiev.ua>> wrote:
> The comment is in body.
>
> > On 13 Dec 2021, at 15:15, Hollenbeck, Scott 
> > mailto:40verisign@dmarc.ietf.org>>
> >  wrote:
> >
> >> -Original Message-
> >> From: Gould, James 
> >> mailto:40verisign@dmarc.ietf.org>>
> >> Sent: Thursday, December 9, 2021 11:59 AM
> >> To: Hollenbeck, Scott 
> >> mailto:shollenb...@verisign.com>>;
> >> ietf=40antoin...@dmarc.ietf.org 
> >> mailto:i...@antoin.nl>>; 
> >> regext@ietf.org
> >> Subject: [EXTERNAL] Re: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-
> >> eai-04
> >>
> >> Caution: This email originated from outside the organization. Do not click
> >> links
> >> or open attachments unless you recognize the sender and know the content
> >> is safe.
> >>
> >> Scott,
> >>
> >> Thanks for the review and feedback.  I provide responses to your feedback
> >> embedded below.
> >>
> >> --
> >>
> >> JG
> >>
> >>
> >>
> >> James Gould
> >> Fellow Engineer
> >> jgo...@verisign.com 
> >>  >> B4BA42740803/jgo...@verisign.com>
> >>
> >> 703-948-3271
> >> 12061 Bluemont Way
> >> Reston, VA 20190
> >>
> >> Verisign.com
> >>  
> >> web.cisco.com/1bUEhaRz5CoSQPd4colm8eTGE5D6zPQvtrYPAzQf9pUSXnqD
> >> Nq7mmnlZ8At92joPzY5DkJdQiiPe1mlyvgzDAdDz_shcqHzSugkfXA2qX9z7aQp0
> >> 6ld-
> >> LnwMzxo2VGkwqFH5gLrI7qSYQlgj4Unll4AIUd6ALSZ38i2kjYqgA0AnBBjaJEVg7
> >> yUIN-
> >> P8bpFGxQgN__tWour_sxUBBx2vUcVpmrR7SUG6UsUo5U3gb_YbWCYcRn8b
> >> 4Rl06BQIL8B8k/http%3A%2F%2Fverisigninc.com%2F>
> >>
> >> On 12/6/21, 9:18 AM, "regext on behalf of Hollenbeck, Scott"  >> boun...@ietf.org on behalf of 
> >> shollenbeck=40verisign@dmarc.ietf.org>
> >> wrote:
> >>
> >>
> >>A few questions/comments:
> >>
> >>Section 6: We need to provide the rationale for that SHOULD (Registries
> >> SHOULD validate the domain names in the provided email addresses). What
> >> does "validate" mean? For syntax? For reachability?
> >>
> >> JG - This is associated with validating the syntax.  The goal is to ensure
> >> that
> >> the domain name, whether an ASCII or IDN domain name is a syntactic valid
> >> domain name the may be reachable.  Would it help to modify this to read
> >> "Registries SHOULD validate the syntax of the domain names in the provided
> >> email addresses so they may be reachable."?
> >
> > [SAH] Syntax validity is no guarantee of reachability. The only way to 
> > confirm
> > that an 

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-rfc7483bis

[Roger D Carney]

+1


From: regext  on behalf of Antoin Verschuren 

Sent: Tuesday, December 8, 2020 1:55 PM
To: regext@ietf.org 
Subject: [regext] 2nd WG LAST CALL: draft-ietf-regext-rfc7483bis

Notice: This email is from an external sender.



This is a special second working group last call for:

https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/

This document is suggested to be elevated from “proposed standard” to "Internet 
standard” as described by the process in RFC6410.
We therefor seek specific consensus from reviewers that they are aware of the 
elevation requirements, and that they have reviewed this document with the 
elevation intention in mind.

Please review this document and indicate your support (a simple “+1” is 
sufficient) or concerns with the publication of this document as “Internet 
standard” by replying to this message on the list.

This WG last call will end Sunday, 2 January 2021.


Regards,

Jim and Antoin



___
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] 2nd WG LAST CALL: draft-ietf-regext-rfc7482bis

[Roger D Carney]

+1


From: regext  on behalf of Antoin Verschuren 

Sent: Tuesday, December 8, 2020 1:55 PM
To: regext@ietf.org 
Subject: [regext] 2nd WG LAST CALL: draft-ietf-regext-rfc7482bis

Notice: This email is from an external sender.



This is a special second working group last call for:

https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/

This document is suggested to be elevated from “proposed standard” to "Internet 
standard” as described by the process in RFC6410.
We therefor seek specific consensus from reviewers that they are aware of the 
elevation requirements, and that they have reviewed this document with the 
elevation intention in mind.

Please review this document and indicate your support (a simple “+1” is 
sufficient) or concerns with the publication of this document as “Internet 
standard” by replying to this message on the list.

This WG last call will end Sunday, 2 January 2021.


Regards,

Jim and Antoin


___
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] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Roger D Carney]

+1


From: regext  on behalf of Tobias Sattler 

Sent: Monday, October 5, 2020 6:15 AM
To: James Galvin 
Cc: regext@ietf.org 
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

Notice: This email is from an external sender.



+1

> On 2. Oct 2020, at 22:52, James Galvin  wrote:
>
> The following working group document is believed to be ready for submission 
> to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces/
>
> This WG last call will end at close of business, Friday, 16 October 2020.
>
> Please review this document and indicate your support (a simple “+1” is 
> sufficient) or concerns with the publication of this document by replying to 
> this message on the list.
>
> The document shepherd for this document is David Smith.
>
> Regards,
>
> Antoin and Jim
>
> ___
> 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] WG LAST CALL: draft-ietf-regext-secure-authinfo-transfer-03

[Roger D Carney]

+1


From: regext  on behalf of Tobias Sattler 

Sent: Monday, October 5, 2020 6:09 AM
To: James Galvin 
Cc: regext@ietf.org 
Subject: Re: [regext] WG LAST CALL: 
draft-ietf-regext-secure-authinfo-transfer-03

Notice: This email is from an external sender.



+1

> On 2. Oct 2020, at 22:55, James Galvin  wrote:
>
> The following working group document is believed to be ready for submission 
> to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/
>
> This WG last call will end at close of business, Friday, 16 October 2020.
>
> Please review this document and indicate your support (a simple “+1” is 
> sufficient) or concerns with the publication of this document by replying to 
> this message on the list.
>
> The document shepherd for this document is Jody Kolker.
>
> Regards,
>
> Antoin and Jim
>
> ___
> 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] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03

[Roger D Carney]

+1


From: regext  on behalf of Tobias Sattler 

Sent: Monday, October 5, 2020 6:23 AM
To: James Galvin 
Cc: regext@ietf.org 
Subject: Re: [regext] WG LAST CALL: 
draft-ietf-regext-epp-registry-maintenance-03

Notice: This email is from an external sender.



+1

> On 2. Oct 2020, at 22:57, James Galvin  wrote:
>
> The following working group document is believed to be ready for submission 
> to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
>
> This WG last call will end at close of business, Friday, 16 October 2020.
>
> Please review this document and indicate your support (a simple “+1” is 
> sufficient) or concerns with the publication of this document by replying to 
> this message on the list.
>
> The document shepherd for this document is James Galvin.
>
> Regards,
>
> Antoin and Jim
>
> ___
> 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] WG LAST CALL: draft-ietf-regext-rfc7483bis

[Roger D Carney]

+1


From: regext  on behalf of Mario Loffredo 

Sent: Monday, September 21, 2020 12:49 AM
To: Antoin Verschuren ; regext@ietf.org 
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

Notice: This email is from an external sender.



+1

Mario

Il 18/09/2020 15:52, Antoin Verschuren ha scritto:
> The following working group document is believed to be ready for submission 
> to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/
>
> This WG last call will end at close of business, Friday, 2 October 2020.
>
> Please review this document and indicate your support (a simple “+1” is 
> sufficient) or concerns with the publication of this document by replying to 
> this message on the list.
>
> The document shepherd for this document is Jasdip Singh.
>
> Regards,
>
> Jim and Antoin
>
>
>
>
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

___
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] WG LAST CALL: draft-ietf-regext-rfc7482bis

[Roger D Carney]

+1


From: regext  on behalf of Mario Loffredo 

Sent: Monday, September 21, 2020 12:49 AM
To: Antoin Verschuren ; regext@ietf.org 
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

Notice: This email is from an external sender.



+1

Mario

Il 18/09/2020 15:52, Antoin Verschuren ha scritto:
> The following working group document is believed to be ready for submission 
> to the IESG for publication as a standards track document:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis/
>
> This WG last call will end at close of business, Friday, 2 October 2020.
>
> Please review this document and indicate your support (a simple “+1” is 
> sufficient) or concerns with the publication of this document by replying to 
> this message on the list.
>
> The document shepherd for this document is Mario Loffredo.
>
> Regards,
>
> Jim and Antoin
>
>
>
>
>
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

___
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] CALL FOR ADOPTION: draft-hollenbeck-regext-rfc7483bis

[Roger D Carney]

+1


From: regext  on behalf of Mario Loffredo 

Sent: Friday, May 15, 2020 9:23 AM
To: Antoin Verschuren ; regext 
Subject: Re: [regext] CALL FOR ADOPTION: draft-hollenbeck-regext-rfc7483bis

Notice: This email is from an external sender.



I support adoption.

Mario

Il 15/05/2020 15:54, Antoin Verschuren ha scritto:
> Dear working group,
>
> Now that we have 2 more RDAP slots available on our milestones, we had new 
> requests for adoption:
>
> This is a formal adoption request for JSON Responses for the Registration 
> Data Access Protocol (RDAP):
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7483bis/
>
> Please review this draft to see if you think it is suitable for adoption by 
> REGEXT, and comment to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review text, or 
> be a document shepherd.
>
> This call for adoption ends Friday, 29 May 2020.
>
> If there are no objections, and we receive enough consensus for adoption, the 
> chairs will consider this document adopted.
>
> Thanks,
>
> Your REGEXT co-chairs Jim and Antoin
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
#pleasestayathome

___
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] CALL FOR ADOPTION: draft-hollenbeck-regext-rfc7482bis

[Roger D Carney]

+1


From: regext  on behalf of Mario Loffredo 

Sent: Friday, May 15, 2020 9:23 AM
To: Antoin Verschuren ; regext 
Subject: Re: [regext] CALL FOR ADOPTION: draft-hollenbeck-regext-rfc7482bis

Notice: This email is from an external sender.



I support adoption.

Mario

Il 15/05/2020 15:54, Antoin Verschuren ha scritto:
> Dear working group,
>
> Now that we have 2 more RDAP slots available on our milestones, we had new 
> requests for adoption:
>
> This is a formal adoption request for Registration Data Access Protocol 
> (RDAP) Query Format:
> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/
>
> Please review this draft to see if you think it is suitable for adoption by 
> REGEXT, and comment to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review text, or 
> be a document shepherd.
>
> This call for adoption ends Friday, 29 May 2020.
>
> If there are no objections, and we receive enough consensus for adoption, the 
> chairs will consider this document adopted.
>
> Thanks,
>
> Your REGEXT co-chairs Jim and Antoin
>
>
>
>
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
#pleasestayathome

___
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] CALL FOR ADOPTION: draft-yee-regext-simple-registration-reporting

[Roger D Carney]

+1 on adoption



From: regext  on behalf of Antoin Verschuren 

Sent: Friday, May 8, 2020 8:36 AM
To: regext 
Subject: [regext] CALL FOR ADOPTION: 
draft-yee-regext-simple-registration-reporting

Notice: This email is from an external sender.



Dear working group,

We will soon have a slot available in our milestone list for a new EPP/Registry 
document.
The chairs are not aware of any outstanding adoption requests other than this 
one.

This is a formal adoption request for Simple Registration Reporting:
https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-reporting/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT, and comment to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review text, or be 
a document shepherd.

This call for adoption ends Friday, 22 May 2020.

If there are no objections, and we receive enough consensus for adoption, the 
chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin






___
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] [Ext] Robert Wilton's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS and COMMENT)

[Roger D Carney]

+1 Scott.




From: regext  on behalf of Hollenbeck, Scott 

Sent: Thursday, May 7, 2020 12:53 PM
To: barryle...@computer.org ; 
rwilton=40cisco@dmarc.ietf.org 
Cc: Gould, James ; regext-cha...@ietf.org 
; i...@ietf.org ; 
gustavo.loz...@icann.org ; regext@ietf.org 
; draft-ietf-regext-data-esc...@ietf.org 

Subject: Re: [regext] [Ext] Robert Wilton's Discuss on 
draft-ietf-regext-data-escrow-07: (with DISCUSS and COMMENT)

Notice: This email is from an external sender.



> -Original Message-
> From: regext  On Behalf Of Barry Leiba
> Sent: Thursday, May 7, 2020 1:37 PM
> To: Rob Wilton (rwilton) 
> Cc: Gould, James ; regext-cha...@ietf.org; The IESG
> ; Gustavo Lozano ;
> regext@ietf.org; draft-ietf-regext-data-esc...@ietf.org
> Subject: [EXTERNAL] Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-
> regext-data-escrow-07: (with DISCUSS and COMMENT)
>
> I'm afraid I have to agree with Gustavo that the terms used here need to
> match what's used in the domain this is written for.  It's often the case that
> things mean different things in different domains, and sometimes those
> domains are similar enough that we wish it weren't the case.  When it is,
> that's sad... but.
>
> Unless someone in the working group wants to tell us that Gustavo is wrong
> and we should go with what Rob suggests, I think the discussion has been
> had.  I *would* like to hear some input from the working group on this,
> though, before we make any final decisions.

A description of the terms tied to their use in the document really should be 
sufficient.

Scott
___
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] RDAP Event Members: REQUIRED or OPTIONAL?

[Roger D Carney]

Good Morning,

Thanks Scott, I do believe this suggestion would add clarity and is appropriate.


Thanks
Roger



From: regext  on behalf of Hollenbeck, Scott 

Sent: Thursday, May 7, 2020 8:34 AM
To: regext@ietf.org 
Subject: [regext] RDAP Event Members: REQUIRED or OPTIONAL?

Notice: This email is from an external sender.



Mario found an interesting issue in RFC 7483. The text in Section 4.5 says this:

"The "events" array consists of objects, each with the following members:

   o  "eventAction" -- a string denoting the reason for the event

   o  "eventActor" -- an optional identifier denoting the actor responsible for 
the event

   o  "eventDate" -- a string containing the time and date the event occurred.

   o  "links" -- see Section 4.2"

As I read this, an "events" array contains objects, and each object has 4 
members. There's nothing here that says that any of the members are REQUIRED or 
OPTIONAL, but "each with the following members" sounds to me like they MUST be 
included. There are, however, examples in the document the omit one or more 
members. The example in Section 4.5 itself omits the "links" member, and an 
example in Section 5.1 omits both the "eventActor" and "links" members.

The few implementations I've looked at (Verisign, ARIN, APNIC, Afilias, 
GoDaddy) all omit both the "eventActor" and "links" members. I'm inclined to 
add text to 7483bis noting that the "eventAction" and "eventDate" members are 
REQUIRED and the "eventActor" and "links" members are OPTIONAL. Does that cause 
any concern for anyone?

Scott

___
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] milestones for recently adopted documents

[Roger D Carney]

Good Morning,

Thanks for your review and comments Patrick.

For the questions you brought up:

DDoS/SRS down - This draft is not intended to support emergency notifications.

 - Draft will be updated to include language describing type 
and name attributes.

 - Draft will be updated to match text to schema. Simply, we 
limited size to restrict someone from writing a book, is there an alternative 
size people would suggest?


Thanks
Roger, Tobias, Jody



From: regext  on behalf of Patrick Mevzek 

Sent: Monday, April 27, 2020 12:32 AM
To: regext@ietf.org 
Subject: Re: [regext] milestones for recently adopted documents

Notice: This email is from an external sender.



On Fri, Mar 6, 2020, at 10:02, James Galvin wrote:
> The co-chairs have discussed proposed milestones for the recently
> adopted documents.  We would like to propose the following.
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/
>   2020 October - Jim Galvin will be document shepherd

[..]

> Document authors are encouraged to begin discussion of these documents
> on the list at this time, in preparation for asking for submission to
> the IESG for publication.

In that regard, for this document, I can offer again my list of comments and 
questions
already asked 2 years ago on the mailing-list without any follow-up:
https://mailarchive.ietf.org/arch/msg/regext/d79sscIkCy0RR1yv-VZb3d2_D48/

They were also some procedural interrogations, but the technical parts are 
below.

Before that, now with a fresh view, I'm wondering if "maintenances" are really
objects that should managed through EPP and what is the benefit.

If I take for example one of the major ccTLD disruption from this week-end,
due to DDOS, the EPP server was completely unreachable. I am also sure the 
registry
at that moment had other things to worry about than enqueing to all registrars
EPP polling queue a message about an emergency maintenance... which can not
be read anyway as the server is unreachable.
So right now I am not sure anymore to be convinced that:
- maintenances are objects in EPP ecosystem, like domains or hosts
(in fact they are not *registrar* objects in registry database, which is what 
EPP is bout)
- if doing so does really provide benefit in operations, especially for the
unscheduled maintenance cases


Back to the technical part from 2 years ago:
I did a quick glance on my past technical comments anyway, it seems the 
document did not change significantly since then
so most if not all points apply.
In fact in the meantime I found other 2 areas of concern that I did not bother
post about but here they are:

*)

" 
   MUST be present and indicates the type of the affected system;
   values SHOULD either be 'production', 'ote', 'staging' or 'dev'"

but in schema:
 
   
 
   
   
 
   
 

So text and schema do not seem to align very well and at the very
least the text does not say anything about the "type" and "name" attributes..
Also, since "type" is an enum, you can not say "values SHOULD either be...", 
they MUST be one of the values in the enum list.
And you do not list the "custom" value among the possible ones.

*)

" 
   MAY be present and provides a freeform description of the
   maintenance without having to create and traverse an external
   resource. The maximum length MUST NOT exceed 1024 bit."

and in schema:
 
   
 
   
 

So, it should be 1024 characters in the text, not 1024 bit (sic).
Also, I see no reason for this limit, can you care to explain why description 
content, being freeform for human consumption, should be limited at the 
protocol level?


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

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

Re: [regext] WG LAST CALL: draft-ietf-regext-tmch-func-spec

[Roger D Carney]

Good Afternoon,



As I have mentioned previously, this informational draft has quite a few policy 
dependencies built into it that are currently being reviewed and will be 
changed by ICANN. The authors have addressed several of these potential policy 
issues but there are some that still exist (e.g. TCNIDs generated twice daily; 
use and definition of  and ).



I do support sending this to the IESG as this draft does depict the current 
operating environment, but due to these dependent policy items, I do believe 
this will need to be revisited and corrected once these policy decisions are 
made/changed, I would guess, at ICANN speed, in the next 2-3 years.



There are a few wording/grammatical issues that a good read should resolve 
(e.g. section 5.2.2, second paragraph, I believe “effective allocate” is meant 
to be “effectively allocate”, copyright dates should be updated).





Thanks

Roger





-Original Message-
From: regext  On Behalf Of Antoin Verschuren
Sent: Friday, February 14, 2020 9:01 AM
To: regext 
Subject: [regext] WG LAST CALL: draft-ietf-regext-tmch-func-spec



Notice: This email is from an external sender.







The following working group document is believed to be ready for submission to 
the IESG for publication as an Informational document:



https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/



This WG last call will end at close of business, Friday, 28 February 2020.



Please review this document and indicate your support (a simple “+1” is 
sufficient) or concerns with the publication of this document by replying to 
this message on the list.



The document shepherd for this document is Ulrich Wisser.



Thanks!



Jim and Antoin

___

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] CALL FOR ADOPTION: draft-sattler-epp-registry-maintenance

[Roger D Carney]

+1 to add to milestones.

-Original Message-
From: regext  On Behalf Of Antoin Verschuren
Sent: Friday, January 24, 2020 8:51 AM
To: regext 
Subject: [regext] CALL FOR ADOPTION: draft-sattler-epp-registry-maintenance

Notice: This email is from an external sender.



This is a formal adoption request for Registry Maintenance Notifications for 
the Extensible Provisioning Protocol (EPP):
https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT, and comment to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review text, or be 
a document shepherd.

This call for adoption ends Friday, 7 February 2020.

If there are no objections, and we receive enough consensus for adoption, the 
chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin




___
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] CALL FOR ADOPTION: draft-gould-regext-secure-authinfo-transfer

[Roger D Carney]

+1 to add to milestones.

-Original Message-
From: regext  On Behalf Of Antoin Verschuren
Sent: Friday, January 24, 2020 8:51 AM
To: regext 
Subject: [regext] CALL FOR ADOPTION: draft-gould-regext-secure-authinfo-transfer

Notice: This email is from an external sender.



This is a formal adoption request for Extensible Provisioning Protocol (EPP) 
Secure Authorization Information for Transfer:
https://datatracker.ietf.org/doc/draft-gould-regext-secure-authinfo-transfer/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT, and comment to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review text, or be 
a document shepherd.

This call for adoption ends Friday, 7 February 2020.

If there are no objections, and we receive enough consensus for adoption, the 
chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin


- --
Antoin Verschuren

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






___
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] CALL FOR ADOPTION: draft-gould-casanova-regext-unhandled-namespaces

[Roger D Carney]

+1 to add to milestones.


-Original Message-
From: regext  On Behalf Of Antoin Verschuren
Sent: Friday, January 24, 2020 8:51 AM
To: regext 
Subject: [regext] CALL FOR ADOPTION: 
draft-gould-casanova-regext-unhandled-namespaces

Notice: This email is from an external sender.



This is a formal adoption request for Extensible Provisioning Protocol (EPP) 
Unhandled Namespaces:
https://datatracker.ietf.org/doc/draft-gould-casanova-regext-unhandled-namespaces/

Please review this draft to see if you think it is suitable for adoption by 
REGEXT, and comment to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review text, or be 
a document shepherd.

This call for adoption ends Friday, 7 February 2020.

If there are no objections, and we receive enough consensus for adoption, the 
chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin






___
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] Registry-Registrar Reporting

[Roger D Carney]

Good Afternoon,

I took an action item out of the Interim REGEXT Meeting held 03NOV2019 in 
regards to the Registry-Registrar Reporting discussion.

We discussed, for almost two hours, several proposals around standardizing 
Registry-Registrar Reports. Roughly there were three proposals:

*   Column/Report Registry - Create two (2) first come first serve 
registries at IANA to contain the industry agreed standardized 1) column names 
and definitions and 2) Report Name and column mappings. This was a new proposal 
presented at the Interim Meeting.

*   Best Practice - Define each standard report as an RFC. Over the past 
year or so there have been several drafts created to document proposed 
reporting standards between Registries and Registrars.  
(draft-mcpherson-sattler-report-structure,
 
draft-mcpherson-sattler-reporting-repository,
 
draft-mcpherson-sattler-transaction-report,
 
draft-sattler-premium-domain-fee-report,
 
draft-sattler-domain-inventory-report,
 
draft-sattler-domain-drop-list-report,
 
draft-sattler-unavailable-domain-report,
  
draft-sattler-contact-inventory-report).

*   Dataset File Format - A proposed format that can be used to define and 
pass bulk data between Registry-Registrar. There was some discussion on 
possible modifications that would possibly allow report definition and delivery 
(draft-gould-regext-dataset).

To provide focus and eliminate as much duplicate effort as possible, I would 
propose that the WG proceed with the Column/Report Registry concept; remove 
(from the REGEXT backlog) the internet drafts created under the Best Practice 
concept; and continue with the Dataset File Format for bulk operations but not 
be used/modified for these standard reports.

For discussion details please see the meeting notes (coming soon).


Thanks
Roger

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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18: (with DISCUSS and COMMENT)

[Roger D Carney]

Good Morning,



Thank you for your clarification remarks Benjamin.



By convention the extensions are not included in EPP error responses unless 
it's explicitly stated or obvious based on the purpose of the extension.  We 
don't see any scenario that a server that supports returning the 
draft-ietf-regext-epp-fees balance information will return it in an error 
response.  We do not recommend changing the language of the draft to explicitly 
state the convention for an optional response attribute.





Thanks

Roger





-Original Message-
From: Benjamin Kaduk 
Sent: Wednesday, October 23, 2019 5:40 PM
To: Roger D Carney 
Cc: The IESG ; regext@ietf.org
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18: (with 
DISCUSS and COMMENT)



Notice: This email is from an external sender.







On Fri, Oct 04, 2019 at 12:25:23PM -0700, Benjamin Kaduk wrote:

> On Tue, Oct 01, 2019 at 02:41:20PM +0000, Roger D Carney wrote:

> > Good Morning,

> >

> >

> >

> > Thanks for your comments Benjamin, please see my responses below, a new 
> > revision will be published shortly to address issues brought up in this 
> > latest round of comments.

> >

> >

> >

> >

> >

> > Thanks

> >

> > Roger

> >

> >

> >

> >

> >

> > -Original Message-

> > From: Benjamin Kaduk via Datatracker

> > mailto:nore...@ietf.org<mailto:nore...@ietf.org%3cmailto:nore...@ietf.org>>>

> > Sent: Monday, September 16, 2019 11:26 AM

> > To: The IESG 
> > mailto:i...@ietf.org<mailto:i...@ietf.org%3cmailto:i...@ietf.org>>>

> > Cc:

> > draft-ietf-regext-epp-f...@ietf.org<mailto:draft-ietf-regext-epp-fee<mailto:draft-ietf-regext-epp-f...@ietf.org%3cmailto:draft-ietf-regext-epp-fee>

> > s...@ietf.org<mailto:s...@ietf.org>>; James Gould

> > mailto:jgo...@verisign.com<mailto:jgo...@verisign.com%3cmailto:jgo...@verisign.com>>>;

> > regext-cha...@ietf.org<mailto:regext-cha...@ietf.org<mailto:regext-cha...@ietf.org%3cmailto:regext-cha...@ietf.org>>;

> > jgo...@verisign.com<mailto:jgo...@verisign.com<mailto:jgo...@verisign.com%3cmailto:jgo...@verisign.com>>;

> > regext@ietf.org<mailto:regext@ietf.org<mailto:regext@ietf.org%3cmailto:regext@ietf.org>>

> > Subject: Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18:

> > (with DISCUSS and COMMENT)

> >

> >

> >

> > Notice: This email is from an external sender.

> >

> >

> >

> >

> >

> >

> >

> > Benjamin Kaduk has entered the following ballot position for

> >

> > draft-ietf-regext-epp-fees-18: Discuss

> >

> >

> >

> > When responding, please keep the subject line intact and reply to

> > all email addresses included in the To and CC lines. (Feel free to

> > cut this introductory paragraph, however.)

> >

> >

> >

> >

> >

> > Please refer to

> > https://www.ietf.org/iesg/statement/discuss-criteria.html

> >

> > for more information about IESG DISCUSS and COMMENT positions.

> >

> >

> >

> >

> >

> > The document, along with other ballot positions, can be found here:

> >

> > https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

> >

> >

> >

> >

> >

> >

> >

> > 

> > --

> >

> > DISCUSS:

> >

> > 

> > --

> >

> >

> >

> > I think (at least with the present formulation) we need greater clarity on 
> > when the "it's up to server policy whether to include, but that policy must 
> > be the same for all transactions" elements ( and 
> > ) are returned, as at present there seems to be an 
> > internal inconsistency in the text.  Section 3.5 and 3.6 just talk about 
> > including them "in responses to all 'transform' or billable commands", but 
> > then we have more qualified text such as (but not limited to) in Section 
> > 5.2.5 that only has  (and its children) included when the 
> >  has been processed successfully.  So, are  and 
> >  supposed to be included in error responses or not?

> >

> >

> >

> > [RDC] I am not sure I see the real issue as I don’t read a conflict here 
> > (technically 5.2.5 [and others] don’t say “ (and its 
> > children)” can only be included in successful responses, the sections just 
> > don’t discuss i

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-20.txt

[Roger D Carney]

Good Morning,



This should be the final edit, just to add normative reference to XML Schema.





Thanks

Roger





-Original Message-
From: regext  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, October 22, 2019 9:11 AM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-20.txt



Notice: This email is from an external sender.







A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.



Title   : Registry Fee Extension for the Extensible 
Provisioning Protocol (EPP)

Authors : Roger Carney

  Gavin Brown

  Jothan Frakes

Filename: draft-ietf-regext-epp-fees-20.txt

Pages   : 39

Date: 2019-10-22



Abstract:

   Given the expansion of the DNS namespace, and the proliferation of

   novel business models, it is desirable to provide a method for

   Extensible Provisioning Protocol (EPP) clients to query EPP servers

   for the fees and credits and provide expected fees and credits for

   certain commands and objects.  This document describes an EPP

   extension mapping for registry fees.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-regext-epp-fees-20

https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-20



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-20





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



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



___

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] Roman Danyliw's Discuss on draft-ietf-regext-epp-fees-18: (with DISCUSS and COMMENT)

[Roger D Carney]

Good Morning,

Thanks to both of you!!

Revision 20 coming with updated references.


Thanks
Roger



From: Hollenbeck, Scott 
Sent: Wednesday, October 16, 2019 6:10 AM
To: r...@cert.org; Roger D Carney ; i...@ietf.org; 
regext@ietf.org
Subject: RE: Roman Danyliw's Discuss on draft-ietf-regext-epp-fees-18: (with 
DISCUSS and COMMENT)

Notice: This email is from an external sender.



From: regext mailto:regext-boun...@ietf.org>> On 
Behalf Of Roman Danyliw
Sent: Tuesday, October 15, 2019 6:15 PM
To: Roger D Carney mailto:rcar...@godaddy.com>>; The IESG 
mailto:i...@ietf.org>>; regext@ietf.org<mailto:regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] Roman Danyliw's Discuss on 
draft-ietf-regext-epp-fees-18: (with DISCUSS and COMMENT)

Hello Roger!

From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Roger D Carney
Sent: Tuesday, October 1, 2019 10:42 AM
To: The IESG mailto:i...@ietf.org>>; 
regext@ietf.org<mailto:regext@ietf.org>
Subject: RE: Roman Danyliw's Discuss on draft-ietf-regext-epp-fees-18: (with 
DISCUSS and COMMENT)


[snip]



** Section 6.1.  This section needs a normative reference to W3C Schema as the 
format of the blob between the BEGIN and END tags.



[RDC] I have not seen this in any EPP RFC, what reference is needed?



[Roman] I can’t explain why EPP didn’t make a normative reference to cite XML 
Schema.  I would recommend adding:



 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,

  "XML Schema Part 1: Structures Second Edition", W3C

  Recommendation REC-xmlschema-1-20041028, October 2004,

  <http://www.w3.org/TR/xmlschema-1/>.



[SAH] The core EPP RFCs *DO* cite the W3C XML Schema Recommendations as 
normative references. Here’s what’s in RFC 5730:



   [W3C.REC-xmlschema-1-20041028]

  Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech,

  "XML Schema Part 1: Structures Second Edition", World Wide

  Web Consortium Recommendation REC-xmlschema-1-20041028,

  October 2004,

  <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.



   [W3C.REC-xmlschema-2-20041028]

  Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes

  Second Edition", World Wide Web Consortium

  Recommendation REC-xmlschema-2-20041028, October 2004,

  <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.



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

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-19.txt

[Roger D Carney]

Good Afternoon,



One more update, to address IESG reviews and comments. All changes were just 
textual for clarity/correctness except one, a non-breaking schema change, 
requiring the name attribute for the command.



Enjoy and have a great weekend!!





Thanks

Roger





-Original Message-
From: regext  On Behalf Of internet-dra...@ietf.org
Sent: Friday, October 11, 2019 2:48 PM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-19.txt



Notice: This email is from an external sender.







A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.



Title   : Registry Fee Extension for the Extensible 
Provisioning Protocol (EPP)

Authors : Roger Carney

  Gavin Brown

  Jothan Frakes

Filename: draft-ietf-regext-epp-fees-19.txt

Pages   : 39

Date: 2019-10-11



Abstract:

   Given the expansion of the DNS namespace, and the proliferation of

   novel business models, it is desirable to provide a method for

   Extensible Provisioning Protocol (EPP) clients to query EPP servers

   for the fees and credits and provide expected fees and credits for

   certain commands and objects.  This document describes an EPP

   extension mapping for registry fees.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-regext-epp-fees-19

https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-19



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-19





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



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



___

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] WG LAST CALL: draft-ietf-regext-data-escrow-01 draft-ietf-regext-dnrd-objects-mapping-01

[Roger D Carney]

+1

From: regext  On Behalf Of Joseph Yee
Sent: Monday, October 7, 2019 2:29 PM
To: Jothan Frakes 
Cc: Owen Smigelski ; James Galvin 
; Registration Protocols Extensions 
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-data-escrow-01 
draft-ietf-regext-dnrd-objects-mapping-01

Notice: This email is from an external sender.


+1

On Fri, Oct 4, 2019 at 5:41 PM Jothan Frakes 
mailto:jot...@jothan.com>> wrote:
+1

On Fri, Oct 4, 2019, 2:21 PM Owen Smigelski 
mailto:owen.smigel...@namecheap.com>> wrote:
+1

> On Sep 27, 2019, at 6:40 AM, James Galvin 
> mailto:gal...@elistx.com>> wrote:
>
> This is a reminder to please indicate your support or comments regarding 
> these drafts.
>
> Thanks!
>
> Antoin and Jim
>
>
>
> On 20 Sep 2019, at 9:31, James Galvin wrote:
>
>> The following working group documents are believed to be ready for 
>> submission to the IESG for publication as a Proposed Standard:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/
>> https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/
>>
>> These documents are a set and will be processed together.
>>
>> The WG LAST CALL will end in two weeks at close of business, Friday, 4 
>> October 2019.
>>
>> Please review these documents and indicate your support (a simple “+1” is 
>> sufficient) or concerns with the publication of these documents by replying 
>> to this message on the list.
>>
>> Finally, we need a document shepherd for these documents.  If you are 
>> interested in being the document shepherd please let the Chairs know by 
>> sending a message to the list or to 
>> regext-cha...@ietf.org.
>>
>> Thanks!
>>
>> Antoin and Jim
>
> ___
> 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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Éric Vyncke's No Objection on draft-ietf-regext-epp-fees-18: (with COMMENT)

[Roger D Carney]

Good Morning,



Thanks for your comments Eric, please see my responses below, a new revision 
will be published shortly to address issues brought up in this latest round of 
comments.





Thanks

Roger



-Original Message-
From: Éric Vyncke via Datatracker mailto:nore...@ietf.org>>
Sent: Thursday, September 19, 2019 3:15 AM
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-regext-epp-f...@ietf.org;
 James Gould mailto:jgo...@verisign.com>>; 
regext-cha...@ietf.org; 
jgo...@verisign.com; 
regext@ietf.org
Subject: Éric Vyncke's No Objection on draft-ietf-regext-epp-fees-18: (with 
COMMENT)



Notice: This email is from an external sender.







Éric Vyncke has entered the following ballot position for

draft-ietf-regext-epp-fees-18: No Objection



When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/







--

COMMENT:

--



Thank you for the work put into this document. I have only one COMMENT and one 
NITS see below.



Regards,



-éric



== COMMENT ==



-- Section 3.4 --

C.1) Any reason to have a negative value for  ? This seems 
counter-intuitive to me.



[RDC] I think I see both sides of the fee (non-negative) / credit (negative) 
struggle. I think if you are thinking about this in accounting terms the 
definitions may seem backwards but this draft is not about accounting/ledger so 
much, it is about the fee. In the end this draft is about the “number” (fee) a 
server is going to charge the client for an action (e.g. what is the fee to 
create this domain). Not sure if I am making this clearer or mudding it up, but 
to me it does seem intuitive that one is positive and one is negative. The 
group thought it was cleaner to make the fees positive and the credits negative.



== NITS ==



Introducing  earlier in the text would improve the readability of the 
document.



[RDC] Section 3.9 (first section this is mentioned) will be updated to provide 
a reference to the details in section 5.1.1.


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

Re: [regext] Secdir telechat review of draft-ietf-regext-epp-fees-18

[Roger D Carney]

Good Morning,



Thanks for your comments Yoav, please see my responses below, a new revision 
will be published shortly to address issues brought up in this latest round of 
comments.





Thanks

Roger





-Original Message-
From: Yoav Nir via Datatracker mailto:nore...@ietf.org>>
Sent: Tuesday, September 17, 2019 3:37 PM
To: sec...@ietf.org
Cc: i...@ietf.org; 
draft-ietf-regext-epp-fees@ietf.org;
 regext@ietf.org
Subject: Secdir telechat review of draft-ietf-regext-epp-fees-18



Notice: This email is from an external sender.







Reviewer: Yoav Nir

Review result: Has Nits



The changes in revision -17 are fine.



I would still like to have it stated that financial information is not at risk 
of leaking because the account information of a customer is only sent in 
communications with that customer. The Security Considerations section already 
says that encryption is used when transmitting financial information. That is 
necessary but not sufficient. You also need to state that such information is 
only sent to entities that should have access to that information.



[RDC] Section 7 will be updated to add: “The server will only provide 
information, including financial information, that is relevant to the 
authenticated client.”


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

Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18: (with DISCUSS and COMMENT)

[Roger D Carney]

Good Morning,



Thanks for your comments Benjamin, please see my responses below, a new 
revision will be published shortly to address issues brought up in this latest 
round of comments.





Thanks

Roger





-Original Message-
From: Benjamin Kaduk via Datatracker mailto:nore...@ietf.org>>
Sent: Monday, September 16, 2019 11:26 AM
To: The IESG mailto:i...@ietf.org>>
Cc: 
draft-ietf-regext-epp-f...@ietf.org;
 James Gould mailto:jgo...@verisign.com>>; 
regext-cha...@ietf.org; 
jgo...@verisign.com; 
regext@ietf.org
Subject: Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18: (with 
DISCUSS and COMMENT)



Notice: This email is from an external sender.







Benjamin Kaduk has entered the following ballot position for

draft-ietf-regext-epp-fees-18: Discuss



When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)





Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/







--

DISCUSS:

--



I think (at least with the present formulation) we need greater clarity on when 
the "it's up to server policy whether to include, but that policy must be the 
same for all transactions" elements ( and ) are 
returned, as at present there seems to be an internal inconsistency in the 
text.  Section 3.5 and 3.6 just talk about including them "in responses to all 
'transform' or billable commands", but then we have more qualified text such as 
(but not limited to) in Section 5.2.5 that only has  (and its 
children) included when the  has been processed successfully.  So, are 
 and  supposed to be included in error responses 
or not?



[RDC] I am not sure I see the real issue as I don’t read a conflict here 
(technically 5.2.5 [and others] don’t say “ (and its children)” 
can only be included in successful responses, the sections just don’t discuss 
if “ (and its children)” should/shouldn’t be included in errors. I 
would assume a server would most likely not return these data on errors, but I 
also don’t see harm if they do and the extension allows for both.





--

COMMENT:

--



It might be helpful to note somewhere that  stands for "check data", as 
per stock EPP, since we use the term a few times before we get to the 
 context and its definition.



[RDC] “(check data)” will be added to section 5.1.1 where  is defined.



Section 1



   Given the expansion of the DNS namespace, and the proliferation of

   novel business models, it is desirable to provide a method for EPP



It's not clear to me whether all readers (whether now or in ten years) will 
have the context to appreciate what is meant by these background clauses.



[RDC] I think that is true that not all clients will have the context to 
appreciate it, but the proliferation of novel business models did lead to the 
creation of the extension, so it seems like the context is relevant and needed.



Section 3.3





   When querying for fee information using the  command, the

element is used to indicate the units to be added to the

   registration period of objects by the ,  and

commands.  This element is derived from the

element described in [RFC5731].



The word "units" here is really confusing me.  Even after reading the rest of 
the document (and 5731's definition of periodType) it still feels like there's 
some words missing here.



[RDC] Section 3.3 will be updated for clarity: “When querying for fee 
information using the  command, the  element is used to 
indicate the period measured in years or months, with the appropriate units 
specified using the “unit” attribute, to be added to the registration period of 
objects by the ,  and  commands.”


Section 3.4



   A server MAY respond with multiple  and 

   elements in the same response.  In such cases, the net fee or credit

   applicable to the transaction is the arithmetic sum of the values of

   each of the  and/or  elements.  This amount

   applies to the total additional validity period applied to the object

   (where applicable) rather than to any incremental unit.



"unit" here is also confusing to me, though less so.  I think what's going on 
here is just the common-sense "the sum of all fees/credits applies for the 
conceptual 'sum' of all the indicated registry operations taken together", in 
which case I might 

Re: [regext] Opsdir last call review of draft-ietf-regext-epp-fees-16

[Roger D Carney]

Good Morning,



Thanks so much for catching this Barry. This was a mistake on my part, this was 
an in-process edit that should not have been published (it was some early 
thoughts on how to respond that we eventually decided to not make). You are 
completely correct and we did intend to leave the original language as it was, 
I will publish a new draft with this verbiage returned to its original text.



Sorry for the confusion everyone! And thanks again Barry for catching.





Thanks

Roger





-Original Message-
From: Barry Leiba 
Sent: Friday, September 6, 2019 4:02 PM
To: Roger D Carney 
Cc: Carlos Pignataro ; ops-...@ietf.org; i...@ietf.org; 
draft-ietf-regext-epp-fees@ietf.org; regext@ietf.org
Subject: Re: Opsdir last call review of draft-ietf-regext-epp-fees-16



Notice: This email is from an external sender.







Thanks for making the updates, Roger.  I do have an issue with the change to 
"non-negative" in Section 3.4:



> 4. S3.4. Does this text imply there is no zero fee or credit possible?

> Might be useful to explicitly set guidance for the use of 0/null fee/credit.

>

>A  element MUST

>have a non-negative value.  A  element MUST have a

>negative value.

>

> [RDC] This was discussed in another email but for completeness, this does 
> state fee can be zero (a non-negative value).



Indeed, it was discussed, and the thing is that the text change is wrong:



New text:

   A  element MUST

   have a zero or non-negative value.  A  element MUST have

   a zero or negative value.



1. "Non-negative" already includes zero.  It does.  So "zero or non-negative" 
is redundant and sounds silly.  But it's not wrong, so if you really want that 
I'm not going to object further.  But...



2. By adding "zero or" to the credit part, you have changed the meaning.  The 
original text said that it MUST be negative... so you can't have a zero credit. 
 The new text allows that.  Is it really the intent that a zero credit is 
permissible?



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

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-17.txt

[Roger D Carney]

Good Afternoon,

One last draft to address AD reviews and comments. No scheme changes just 
verbiage cleanup for an easier more concise read.


Thanks
Roger


-Original Message-
From: regext  On Behalf Of internet-dra...@ietf.org
Sent: Friday, September 6, 2019 3:06 PM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-17.txt

Notice: This email is from an external sender.



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Registry Fee Extension for the Extensible 
Provisioning Protocol (EPP)
Authors : Roger Carney
  Gavin Brown
  Jothan Frakes
Filename: draft-ietf-regext-epp-fees-17.txt
Pages   : 39
Date: 2019-09-06

Abstract:
   Given the expansion of the DNS namespace, and the proliferation of
   novel business models, it is desirable to provide a method for
   Extensible Provisioning Protocol (EPP) clients to query EPP servers
   for the fees and credits and provide expected fees and credits for
   certain commands and objects.  This document describes an EPP
   extension mapping for registry fees.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-epp-fees-17
https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-17


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] Opsdir last call review of draft-ietf-regext-epp-fees-16

[Roger D Carney]

Good Morning,



Thank you for your follow-up Carlos, please see my responses below. A new 
version of the draft will be published shortly and will address all of the 
review comments that needed edits.





Thanks

Roger



-Original Message-

From: Carlos Pignataro (cpignata) 

Sent: Wednesday, July 3, 2019 11:38 AM

To: Barry Leiba 

Cc: ops-...@ietf.org; IETF discussion list ; 
draft-ietf-regext-epp-fees@ietf.org; regext@ietf.org

Subject: Re: Opsdir last call review of draft-ietf-regext-epp-fees-16



Notice: This email is from an external sender.







Hi, Barry,



> On Jul 3, 2019, at 9:17 AM, Barry Leiba  wrote:

>

> Thanks, Carlos, for the review.



Anytime!



>

> On one item in your list:

>

>> 4. S3.4. Does this text imply there is no zero fee or credit

>> possible? Might be useful to explicitly set guidance for the use of 0/null 
>> fee/credit.

>>

>>   A  element MUST

>>   have a non-negative value.  A  element MUST have a

>>   negative value.

>

> The text says the fee can be zero ("non-negative"), but the credit

> can't (has to be negative).  That makes general sense, doesn't it?  Do

> you really think there needs to be further explanation of that?



Since zero is neither negative nor positive, I thought it was potentially a 
source of misinterpretation.



But you are correct, the text as-is is accurate and perfect.



That is why I marked these as “Minor comments, questions, and nits for your 
consideration”. As this is an Ops-Dir review, Appendix A of RFC 5706 is 
detailed about defaults, boundary conditions, hence asking :-)



BTW, re-reading that section, I noticed:



   A server MAY respond with multiple  and 

   elements in the same response.  In such cases, the net fee or credit

   applicable to the transaction is the arithmetic sum of the values of

   each of the  and/or  elements.



Do these need to include the same  or otherwise how would the 
arithmetic sum work?



[RDC] Yes, the currencies are the same and the schema enforces this rule.



Thanks,



-- Carlos.



>

> Barry


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

Re: [regext] Opsdir last call review of draft-ietf-regext-epp-fees-16

[Roger D Carney]

Good Morning,



Thank you for your comments Carlos, please see my responses below. A new 
version of the draft will be published shortly and will address all of the 
review comments that needed edits.





Thanks

Roger





-Original Message-

From: Carlos Pignataro via Datatracker 

Sent: Wednesday, July 3, 2019 2:51 AM

To: ops-...@ietf.org

Cc: i...@ietf.org; draft-ietf-regext-epp-fees@ietf.org; regext@ietf.org

Subject: Opsdir last call review of draft-ietf-regext-epp-fees-16



Notice: This email is from an external sender.







Reviewer: Carlos Pignataro

Review result: Has Nits



Reviewer: Carlos Pignataro

Review Result: Has Nits



I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review.  Document editors and WG chairs should 
treat these comments just like any other last call comments.



I hope these comments are useful and clear.



>From an operational point of view, the document describes protocol

>interactions

for dealing with failure conditions, and sets default behaviors. For example, 
the RFC 2119 language explaining the use of  is super useful.



Minor comments, questions, and nits for your consideration follow:



1. Section 2 -- Migrating to Newer Versions of This Extension



   (Note to RFC Editor: remove this section before publication as an

   RFC.)



Since forward compatibility is a key operational consideration, why should this 
section be removed? Especially when it contains RFC 2119 language.



[RDC] Agree, Note will be removed.



2. Please do not treat as a pedantic comment, but I did not see an actual 
definition for what "fee" and "credit" mean. Since these words have specific 
context, it might not hurt to have a formal definition in Section 1.1



[RDC] Added clarifying text to section 3.4 “A fee will result in subtracting 
from the Account Balance (described section 3.5) and a credit will result in 
adding to the Account Balance (described in section 3.5).”



3. Should the citation / reference for "ISO 4217" be "ISO 4217:2015"?



[RDC] Text updated.



4. S3.4. Does this text imply there is no zero fee or credit possible? Might be 
useful to explicitly set guidance for the use of 0/null fee/credit.



   A  element MUST

   have a non-negative value.  A  element MUST have a

   negative value.



[RDC] This was discussed in another email but for completeness, this does state 
fee can be zero (a non-negative value).



5. S3.6, why "equal to" and not only "exceed"?



   A server MAY reject certain

   transactions if the absolute value of the  is equal to

   or exceeds the value of the  element.



[RDC] This allows server policy flexibility, allows a server to deny a 
transaction when the limit is reached or exceeded.



6. Section 6.1



  * Should  and  markers be used as per the TLP?

  * Should the (c) year be 2019?

  * And should the BSD License be part of the code?



[RDC] BEGIN/END is the standard that has been used in EPP RFCs. The copyright 
information in this section has been removed..



7. Section 7, Security Considerations.



What are "security services"? Further, this protocol deals with on-the-wire 
monetary information. I suspect there might be specific such considerations.



[RDC] “Security Services” are any related security features/functions. 
“on-the-wire” monetary information has been addressed through secdir comments, 
an additional line of text for clarity was added.



8. Section 9.  Implementation Status



If this section is removed, the reference to [RFC7942] would result hanging 
without citations to it. ALthough the RFC Editor would catch, might want to 
indicate removal of the Normative Reference as well.



[RDC] The removal text also states to remove the reference.



Thanks!



Carlos Pignataro.


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

Re: [regext] Genart last call review of draft-ietf-regext-epp-fees-16

[Roger D Carney]

Good Morning,



Thank you for your comments Stewart, please see my responses below. A new 
version of the draft will be published shortly and will address all of the 
review comments that needed edits.





Thanks

Roger



-Original Message-

From: Stewart Bryant via Datatracker mailto:nore...@ietf.org>>

Sent: Thursday, June 27, 2019 8:57 AM

To: gen-...@ietf.org

Cc: i...@ietf.org; 
draft-ietf-regext-epp-fees@ietf.org;
 regext@ietf.org

Subject: Genart last call review of draft-ietf-regext-epp-fees-16



Notice: This email is from an external sender.







Reviewer: Stewart Bryant

Review result: Ready with Issues



I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



.



Document: draft-ietf-regext-epp-fees-16

Reviewer: Stewart Bryant

Review Date: 2019-06-27

IETF LC End Date: 2019-07-08

IESG Telechat date: Not scheduled for a telechat



Summary:



A well written document that is ready for publication subject to a couple of 
clarifications



Major issues: None



Minor issues:



===

2.  Migrating to Newer Versions of This Extension



   (Note to RFC Editor: remove this section before publication as an

   RFC.)



SB> This seems like good advice, why is it to be removed?



[RDC] Agree, Note has been removed

===



   Copyright (c) 2018 IETF Trust and the persons identified as authors

   of the code.  All rights reserved.



   Redistribution and use in source and binary forms, with or without

   modification, are permitted provided that the following conditions

   are met:



   o  Redistributions of source code must retain the above copyright

  notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright

  notice, this list of conditions and the following disclaimer in

  the documentation and/or other materials provided with the

  distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the

  names of specific contributors, may be used to endorse or promote



SB> It is not clear what the purpose of this text is, whether or not it

SB>is  intended to be included with each instance the technical text below.

SB>If not why is the copyright not covered by the RFC boilerplate copyright 
text?



[RDC] This verbiage has been removed.



=

7.  Security Considerations



   The mapping extensions described in this document do not provide any

   security services beyond those described by EPP [RFC5730], the EPP

SB> "security services" or "security risks"



[RDC] “security services”

=



Nits/editorial comments: None




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

Re: [regext] Secdir last call review of draft-ietf-regext-epp-fees-16

[Roger D Carney]

Good Morning,



Thank you for your comments Yoav, please see my responses below. A new version 
of the draft will be published shortly and will address all of the review 
comments that needed edits.





Thanks

Roger



-Original Message-

From: Yoav Nir via Datatracker 

Sent: Saturday, June 29, 2019 10:26 AM

To: sec...@ietf.org

Cc: i...@ietf.org; draft-ietf-regext-epp-fees@ietf.org; regext@ietf.org

Subject: Secdir last call review of draft-ietf-regext-epp-fees-16



Notice: This email is from an external sender.







Reviewer: Yoav Nir

Review result: Has Nits



Hi



I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the security area directors.

Document editors and WG chairs should treat these comments just like any other 
last call comments.



The entire text of the Security Considerations section is as follows:



   The mapping extensions described in this document do not provide any

   security services beyond those described by EPP [RFC5730], the EPP

   domain name mapping [RFC5731], and protocol layers used by EPP.  The

   security considerations described in these other specifications apply

   to this specification as well.



This is what we like to call "security considerations by reference". I don't 
know what "security services" are in this context, but they are not the only 
thing that needs to be described in a Security Considerations section.



In this case, the draft adds information about fees, customer credit and pay 
schedule. This falls under the category of financial information, which should 
be protected in transit by security mechanisms that protect confidentiality and 
integrity. It is also true that any transport mechanism that complies with RFC

5730 provides those functions. So what I'm missing here is a sentence that 
calls this out specifically. Something along the lines of "This extension adds 
financial information to the EPP protocol, so confidentiality and integrity 
protection must be provided by the transport mechanism.  All transports 
compliant with RFC5730 provide that"



[RDC] We have added the following text to section 7: "This extension passes 
financial information using the EPP protocol, so confidentiality and integrity 
protection must be provided by the transport mechanism.  All transports 
compliant with RFC5730 provide the needed level of confidentiality and 
integrity protections."
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] on RDAP milestones

[Roger D Carney]

Good Morning,



Thanks George, I like this thought process. One additional thing I would like 
to add is the discussions of privacy at a higher level. For those that did not 
attend the Plenary Wednesday, there were some good privacy presentations and 
shows that privacy is an issue that needs to addressed across many 
protocol/standards development. Maybe George's suggested "Privacy in RDAP" is a 
good first step to take and might even be helpful outside the RDAP concept.



Does anyone know of current work at IETF specifically addressing privacy that 
could be leveraged by REGEXT? Additionally, is there a larger privacy effort 
going on within the IETF that the suggested "Privacy in RDAP" should be aware 
of and possibly get direction from?





Thanks

Roger





-Original Message-
From: regext  On Behalf Of George Michaelson
Sent: Friday, July 26, 2019 8:26 AM
To: regext@ietf.org
Subject: Re: [regext] on RDAP milestones



Notice: This email is from an external sender.







I believe a proper response to Stephane and Peters stated concerns in privacy, 
is for a "Privacy in RDAP" document to be written which becomes a reference 
back into the patterns like reverse search. I do not believe we can expect to 
go forward without reverse-index lookup:

it is a fundamental tool in LEA, but is (in that context) circumscribed by 
GDPR, probably to be authenticated user only: It depends on OpenID or Oauth or 
some other wide ranging model of access control we can agree to (given that 
registries do 302 redirect, you would expect a client to need to present a 
federated auth token) Or, when invoked, it has limits. Or some combination. The 
issues are not something which should just be an addendum or appendix in 
another document. They should be addressed first-class. Unlike EPP, this is 
about privacy of data in public view, not about the maintenance of records 
inside registry, its about the access to that data from the public 
globally-connected space.



I fundamentally believe that there is a huge role for "what are related records 
from this person" queries. I do this from personal experience, dealing with a 
hacked WHOIS account and seeking to find the related resource records which 
showed signs of having been tampered with from the maintainers rights. I am 
sure there are other use cases.



I also think we need to distinguish between individual, organisational, and 
corporate-entity rights here. I am happy to see individual rights to privacy 
defended. I am concerned we are walking into a world where we routinely extend 
personal rights to corporate rights and I do not take it as axiomatic the GDPR 
rules mean that registered and incorporated entities have some assumed right to 
privacy.



If we do that, If we separate things out, we can progress partial-response and 
sorting/paging in one strand, and reverse-index query in another, with the 
latter the only one affected by new work on privacy in narrow sense. In wide, 
all work in RDAP has to consider the privacy issue.



I would invite Stephane (and Peter) to write. They have the most direct 
statements of concern, I think they are able to document the concerns.



-G



___

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] on RDAP milestones

[Roger D Carney]

+1 to extensions of these milestones


-Original Message-
From: regext  On Behalf Of Wilhelm, Richard
Sent: Friday, July 26, 2019 7:49 AM
To: regext@ietf.org
Subject: [regext] on RDAP milestones

Notice: This email is from an external sender.



Capturing/elaborating on my comments at the mic the WG meeting in Montreal…

Related to these three drafts:

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

I offer that the number of RDAP server implementations is about to go (perhaps 
‘undergoing’) a significant increase due to the Aug 26 deadline for ICANN gTLD 
registries and registrars to launch their own RDAP servers (see 
https://www.icann.org/rdap ).  Consequently, the RDAP community is in the 
process of both rapidly expanding and gaining valuable implementation 
experience with ‘basic’ RDAP implementation capabilities.

As it relates to the partial-response and sorting-and-paging drafts, I think 
that the emerging implementation work will be providing an opportunity for both 
the drafts to be exposed to experience gained on both the client and server.

As it relates to the reverse-search draft, the privacy considerations related 
to this are subtle/complex within the context of recent/current IETF 
discussions and are also related to legal/policy considerations outside the 
IETF sphere.  The outcome of forthcoming IETF discussions and incorporation of 
relevant legal/policy discussions will (presumably) need to be taken into 
consideration by this I-D.

I recognize and agree that ICANN gTLD policy work need not be a key dependency 
for REGEXT work.  But in this case, ICANN gTLD policy work is not the only 
policy question that is being considered.  There are also national 
legislation/regulations that are emerging in this area and the EU GDPR is in 
effect for just over a year (i.e GDPR is still relatively new).  Consequently, 
these EU/national policy considerations could have relevant impact.

Thus, for all three of these I-Ds, I would suggest that the milestone dates be 
extended in order to allow for more experience (partial-response and 
sorting-and-paging), more discussion (reverse-search), and for the relevant 
policy work to be completed/incorporated (reverse-search).  I think that the 
extensions will allow for the documents to evolve/mature based on these items, 
thus leading to more stable and long-lived documents.


Thanks,
Rick




___
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] on jcard and jscontact migration

[Roger D Carney]

Good Evening,



+1 on the transition thoughts, thanks Marc for delving a bit deeper on this 
topic.



Just wanted to make one comment/clarification on one of Andy's questions: "Are 
there any registries willing to step up and say they'll deploy RDAP if we move 
to JSContact? Just wanted to add clarity to “registries” and suggest 
supplementing “RDAP servers “ as there will also be thousands of Registrar RDAP 
servers instances as well. As for GoDaddy, we look forward to migrating our 
server and clients to a more appropriate contact structure.



I can’t speak to Andy’s “holdout question” but I would like to also say I 
believe migrating will lessen the long term maintenance (e.g. new clients 
writing/debugging to your server, handling of unique data scenarios into these 
arrays of arrays) by going with a more simplified/precise structure.



Just some additional food for thought.



Thanks

Roger





-Original Message-
From: regext  On Behalf Of Andrew Newton
Sent: Thursday, July 25, 2019 4:43 PM
To: Marc Blanchet 
Cc: regext 
Subject: Re: [regext] on jcard and jscontact migration



Notice: This email is from an external sender.







Thanks for describing that. I think that makes sense, and if we have to 
transition this plan seems like the way to go.



Given that there are many registries and clients whom have already implemented 
jCard, does moving to JSContact mean hold-outs will implement RDAP?

In other words, who is NOT doing RDAP because of jCard? Are there any 
registries willing to step up and say they'll deploy RDAP if we move to 
JSContact?



-andy



On Thu, Jul 25, 2019 at 4:21 PM Marc Blanchet 
mailto:marc.blanc...@viagenie.ca>> wrote:

>

> There has been discussion on replacement of jcard. One of the

> considerations in the equation is how to handle the migration. Some

> people have (appropriatly) expressed concerns about this issue of

> migration. While I’m not yet sure if we need to deprecate jcard, I

> would like to suggest a way to manage the migration if we ever

> consider the new format:

> - define in RDAP RESPONSE another property additional to vcardarray,

> at the same place as vcardarray appears. Say « jscontact »

> - have servers to send both (for quite a long time). This is more work

> from the server side, but I think it is not that bad.

> - clients not able to read the new format will just ignore it and will

> continue to parse the jcard.

> - clients that are updated and prefer the new format just parse the

> new format and ignore the jcard.

> - wait a while. at some point in time, deprecate jcard.

>

> My point here is that there is a smooth path to the new format, which

> has some costs, but it is doable and not that complicated.

>

> Regards, Marc.

>

> ___

> 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] WG LAST CALL: draft-ietf-regext-login-security

[Roger D Carney]

+1

-Original Message-
From: regext  On Behalf Of Hollenbeck, Scott
Sent: Tuesday, July 23, 2019 8:19 AM
To: gal...@elistx.com; regext@ietf.org
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-login-security

Notice: This email is from an external sender.



> -Original Message-
> From: regext  On Behalf Of James Galvin
> Sent: Friday, July 12, 2019 3:14 PM
> To: Registration Protocols Extensions WG 
> Subject: [EXTERNAL] [regext] WG LAST CALL: 
> draft-ietf-regext-login-security
>
> The following working group document is believed to be ready for 
> submission to the IESG for publication as a Proposed Standard:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/
>
> A WG last call would normally be two weeks long.  However, because the 
> IETF meeting is in two weeks this last call will be extended 1 week 
> and will end at close of business, Friday, 2 August 2019.
>
> Please review this document and indicate your support (a simple “+1”
> is sufficient) or concerns with the publication of this document by 
> replying to this message on the list.

+1

Scott
___
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 (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] Registration Protocols Extensions (regext) WG Virtual Meeting: 2019-06-11 CHANGED

[Roger D Carney]

Good Morning,

Thanks for the nudge Patrick, I had the minutes in my drafts folder from right 
after the meeting and forgot to get them out before taking off for a couple 
weeks. I will get these notes cleaned up and sent out today.


Thanks
Roger

-Original Message-
From: regext  On Behalf Of Patrick Mevzek
Sent: Monday, July 1, 2019 11:47 PM
To: regext@ietf.org
Subject: Re: [regext] Registration Protocols Extensions (regext) WG Virtual 
Meeting: 2019-06-11 CHANGED

Notice: This email is from an external sender.



Hello,

Have notes being published/circulated about this meeting?

My previous request about a past meeting whose minutes were never published was 
never answered.

Thanks in advance.

On Mon, Jun 24, 2019, at 11:02, IESG Secretary wrote:
> MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.
>
> The Registration Protocols Extensions (regext) Working Group will hold 
> a virtual interim meeting on 2019-06-11 from 16:00 to 17:00 UTC.
>
> Agenda:
> Reporting Repository/Structure/Reports (how does the Data Set File 
> Format fit in)
> Documents:
> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-repo
> rting-repo/ 
> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-repo
> rt-structure/ 
> https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-rep
> ort/ https://datatracker.ietf.org/doc/draft-gould-regext-dataset/
>
> Information about remote participation:
> https://godaddy.zoom.us/j/958439027
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>

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

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

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

Re: [regext] 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<https://godaddy.zoom.us/j/958439027>.


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).


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<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 will once again use Zoom as a conferencing tool, please use this 
link<https://godaddy.zoom.us/j/958439027> 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] I-D Action: draft-ietf-regext-epp-fees-16.txt

[Roger D Carney]

Good Afternoon,



Per AD comments and list comments I have posted revision 16 to address all 
comments.



Here is the change log for revision 16: Updated per AD review and list 
comments: several grammar corrections; clarification text added to section 
3.4.3 and 3.5; and a schema update for consistency by providing a "lang" 
attribute to the  and  "description" attribute detailed in 
section 3.4.





Thanks

Roger





-Original Message-
From: regext  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, May 1, 2019 4:22 PM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-16.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.



Title   : Registry Fee Extension for the Extensible 
Provisioning Protocol (EPP)

Authors : Roger Carney

  Gavin Brown

  Jothan Frakes

Filename: draft-ietf-regext-epp-fees-16.txt

Pages   : 39

Date: 2019-05-01



Abstract:

   Given the expansion of the DNS namespace, and the proliferation of

   novel business models, it is desirable to provide a method for

   Extensible Provisioning Protocol (EPP) clients to query EPP servers

   for the fees and credits and provide expected fees and credits for

   certain commands and objects.  This document describes an EPP

   extension mapping for registry fees.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-regext-epp-fees-16

https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-16



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-16





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



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



___

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] CALL FOR ADOPTION: Proposed Milestones for the next year

[Roger D Carney]

+1 on the milestones

-Original Message-
From: regext  On Behalf Of James Galvin
Sent: Friday, April 26, 2019 3:26 PM
To: Registration Protocols Extensions 
Subject: [regext] CALL FOR ADOPTION: Proposed Milestones for the next year

As discussed at our last meeting at IETF104 Prague, we need to set milestones 
for ourself.

This is a formal request for adoption of a set of milestones.

As previously explained, we have included the two proposed new documents in 
this set.  If you support the adoption of the documents you can just vote on 
the milestones as proposed.  You can also vote on the milestones without the 
two new documents.

Please review the milestones and respond to the list with “+1” or
“+1 with any updates or comments” or just respond with your questions or 
comments.


Here are the proposed milestones:


July 2019 - Login Security
https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/


August 2019 - Registry Data Escrow Specification 
https://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/


August 2019 - Domain Name Registration Data (DNRD) Objects Mapping 
https://datatracker.ietf.org/doc/draft-arias-noguchi-dnrd-objects-mapping/


September 2019 - RDAP Partial Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/


October 2019 - RDAP Sorting and Paging
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging/


November 2019 - RDAP Reverse Search
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/


March 2020 - Federated Authentication for the RDAP using OpenID Connect 
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/


Please consider whether this is the right order for the documents and whether 
or not you believe enough time has been allotted to complete the working group 
review of each document.

Thanks,

Antoin and Jim

___
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] [gtld-tech] EPDP recommendations and EPP

[Roger D Carney]

Good Morning,

Thanks for the comments Patrick.

Agreed, another one of the concerns going with placeholders is that to some, it 
will lessen the urgency to solve the underlying issue.

Not speaking specifically to the examples you gave on multiple mechanisms, I 
still believe that adding an additional contact mapping will increase 
implementation complexity that is not needed, more below.

As far as tailoring the protocol, it seems to me that the current RFC 5733 has 
been tailored. I am not sure why 5733 required these fields to exist in the 
first place, I assume it was discussed when it was written many years ago and 
it was decided for some reason these fields be treated special, but I don't see 
a technical reason to treat them differently. I don't think the idea of making 
the EPP Contact Mapping more flexible is a gTLD specific solution.

Thanks for digging deeper into what it takes to "improve" the current 
mechanism. As Gavin mentioned in his original email, this would require a new 
RFC be created and you have provided some more logistics to that effort. As you 
mention, there may be clients that may need to support both namespaces, but for 
servers that choose to use the new namespace the interface on both sides would 
be less complex than having two mapping mechanisms. Servers could have the 
option of supporting the namespace that is appropriate for them (though I 
assume for gTLDs ICANN would update policy to use the new namespace).


Thanks
Roger


-Original Message-
From: regext  On Behalf Of Patrick Mevzek
Sent: Friday, March 1, 2019 9:55 AM
To: regext@ietf.org
Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP

On Fri, Mar 1, 2019, at 16:22, Roger D Carney wrote:
> Thanks for the comments Patrick.  I agree about the pollution of 
> placeholders and that is one reason why I think it can only be used as 
> a temporary solution.

If this is implemented, it will become permanent and there will be nothing else 
replacing it later.
 
> I am not sold on creating a "new object." Another way to do the same 
> intention, to me this will just get convoluted for implementers (look 
> here unless you should look over there).

I do not feel that convoluted and even if it is the case we already have many 
of them:
- host attributes vs host objects
- secDNS keyData vs dsData
etc.

> To me this is just creating a
> new mechanism to avoid fixing a problem in the current mechanism.

There is no problem in current mechanism. ccTLDs are all "fine" with it.
Right now we are discussing (in multiple places so that makes participating 
difficult) things that will only apply to gTLDs.

I really do not want again to give everyone's impression that we are tailoring 
a protocol to a very specific case just because the major vocal interests are 
there.

In short, if gTLDs need another contact model because the one in RFC5733 is not 
fitting today anymore, it seems the clearer and simpler to me to just define a 
new model for contacts.

> I am not sure how improving RFC 5733 to be more flexible and data 
> privacy/protection aware is a detriment to anyone using EPP. Anyone 
> using 5733 needs to be acutely aware of data "processing" and would 
> greatly benefit from a more flexible technical solution.

You can not "improve" RFC 5733. You will need to create a new namespace, like 
"contact-2.0"
At which point it is quite the same for implementors because any client with 
multi registries need will need to handle both namespaces (you can not expect 
all registries, specially non gTLD ones, just moving to your new schema, even 
if it is a strict superset of previous ones, because they will have absolutely 
0 reasons, technical or economical, to do the change), so if you have 
"contact-1.0" and "contact-2.0" namespaces to handle OR "contact-1.0" and 
"lightContact-1.0" (or "shallowContact-1.0" or "gtldContact-1.0" or whatever) 
it is basically the same amount of work, but second option seems better to me 
for multiple reasons.

And again, there is a huge non technical difference.
If we give again the impression to change the EPP just to suite gTLD needs, we 
should not lament later on the state of EPP worldwide and why not everyone 
follows the standard to the letter, or best current practices, etc.


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

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

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

Re: [regext] [gtld-tech] EPDP recommendations and EPP

[Roger D Carney]

Good Morning,

Thanks for the comments Patrick.  I agree about the pollution of placeholders 
and that is one reason why I think it can only be used as a temporary solution.

I am not sold on creating a "new object." Another way to do the same intention, 
to me this will just get convoluted for implementers (look here unless you 
should look over there). To me this is just creating a new mechanism to avoid 
fixing a problem in the current mechanism.

I am not sure how improving RFC 5733 to be more flexible and data 
privacy/protection aware is a detriment to anyone using EPP. Anyone using 5733 
needs to be acutely aware of data "processing" and would greatly benefit from a 
more flexible technical solution.


Thanks
Roger


-Original Message-
From: regext  On Behalf Of Patrick Mevzek
Sent: Friday, March 1, 2019 9:03 AM
To: regext@ietf.org
Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP

On Fri, Mar 1, 2019, at 15:39, Roger D Carney wrote:
> I think I am in agreement with most people on this, that option 3 (or 
> C, whatever it is called) is the best short term solution “define a 
> "convention" that allows the  and  elements to contain 
> placeholder values, such as: - and XX which pose 
> no data protection issues”.

I am completely againts such placeholders.
While they are the easy fast solution, they just pollute databases with useless 
data.

Instead of updating RFC5733 I would suggest creating a new object, a "light (or 
shallow) contact" which is like a contact currently, just with less fields.
Domains could use "full contacts" (the ones we know today) or light contacts 
(the new ones).

One has to keep remembering that EPP is not just used by gTLDs, so any change 
has to be done in such a way that it does not impact negatively any operation 
done outside of ICANN circles.

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

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

Re: [regext] [gtld-tech] EPDP recommendations and EPP

[Roger D Carney]

Good Morning,


I think I am in agreement with most people on this, that option 3 (or C, 
whatever it is called) is the best short term solution “define a "convention" 
that allows the  and  elements to contain placeholder values, such 
as: - and XX which pose no data protection issues”.



Though I want to stress that I believe this is just the quick/short term 
solution and that I believe that the correct way to resolve this is to “update” 
RFC 5733. At minimum to make city and cc optional but we should really look at 
what is needed for improving data privacy/protection on the whole. I also 
believe this work is extremely important and would like to see this as one of 
the items that the REGEXT group picks up and starts working immediately.




Thanks
Roger


From: gtld-tech  On Behalf Of Gould, James via 
gtld-tech
Sent: Thursday, February 28, 2019 7:51 AM
To: Hollenbeck, Scott ; gavin.br...@centralnic.com; 
gtld-t...@icann.org
Subject: Re: [gtld-tech] EPDP recommendations and EPP


Scott,



There are a few issues that we need to address, which include:



  1.  Technical Contact – Only 3 optional fields of Name, Phone, and Email are 
defined in EPDP Team Recommendation #7.  Is the collection of the additional 
RFC 5733 disallowed?
  2.  Registrant Contact – All of the Registrant data fields are defined as 
optional in EPDP Team Recommendation #7.  This means that both Technical 
Contacts and Registrant Contacts would need to get around the required 
, , and  elements in RFC 5733.
  3.  Contacts Don’t Have a Type – Contacts are created without a type in RFC 
5733, where type is based on the link from the domain name.  Since a Contact is 
an object, it could be a Registrant and Technical contact for a single domain 
or for many domains.  Who would apply the policy for what fields are set or not 
set (client, server, or both)?  My recommendation is for the client to apply 
the policy, since the client has the relationship with the registrant.



To meet the policy, my recommendation is to support RFC 5733 with placeholder 
values for the , , and  elements to 
indicate non-existence, to have the servers be flexible to the contact fields 
set by the client, and to have the clients implement the policy related to what 
fields of a contact are set based on the type of the contact.  This is not a 
perfect solution, but it would allow implementing the policy without a great 
amount of dependencies and complexity (e.g., parallel contact mappings, adding 
typing to contacts, adding link type rules, and raising the issue of 
inconsistent server policies).



I agree with your proposal of option 3, with the additional placeholder text 
for the required  element, the server accepting a flexible number 
of contact fields (empty or placeholder) for all contacts, and the client 
implementing the policy.



—



JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 2/28/19, 7:53 AM, "gtld-tech on behalf of Hollenbeck, Scott via gtld-tech" 
mailto:gtld-tech-boun...@icann.org%20on%20behalf%20of%20gtld-t...@icann.org>>
 wrote:



> -Original Message-

> From: gtld-tech 
mailto:gtld-tech-boun...@icann.org>> On Behalf Of 
Gavin Brown

> Sent: Wednesday, February 27, 2019 4:41 AM

> To: gtld-t...@icann.org

> Subject: [EXTERNAL] [gtld-tech] EPDP recommendations and EPP

>

> Hi all,

>

> The EPDP final report says that, if a domain name has a technical contact

> (whose information is different from the registrant's), the only data that

> registrars should send to registries are the technical contact's name, 
email

> address, and phone number (if any).

>

> Assuming that technical contacts should still be created and managed as 
RFC

> 5733 contact objects, and also assuming that this recommendation is 
adopted

> without change, it poses a challenge, because the RFC requires all contact

> objects to have  and  elements.

>

> I've been thinking about how this could be resolved, here are some ideas 
(in

> descending order of nastiness):

>

> * write a new RFC which updates RFC 5733 to make the  and 

> elements optional

>

> * write a new EPP extension which makes the technical contact's name,

> email address, and phone number directly attributes of the the domain

> name rather than a contact object

>

> * define a "convention" that allows the  and  elements to 
contain

> placeholder values, such as: - and XX which pose no

> data protection issues.

>

> Any thoughts?



I tend to prefer the last option. It doesn't have any dependencies on 
pushing documents through the IETF, and it doesn't get us into developing 
policy-specific specifications.



Scott

Re: [regext] AD Review: draft-ietf-regext-epp-fees-15

[Roger D Carney]

Good Morning,

Thanks for the input James. I haven’t seen any additional comments, if anyone 
else has comments please send them into the list. I will plan to generate 
revision 16 soon with the input that was sent into the list.


Thanks
Roger


From: Gould, James 
Sent: Monday, February 11, 2019 7:31 AM
To: Roger D Carney ; a...@nostrum.com; regext@ietf.org
Cc: draft-ietf-regext-epp-fees@ietf.org
Subject: Re: RE: AD Review: draft-ietf-regext-epp-fees-15

Roger,

In reviewing the items.  I provide my feedback embedded within your list, 
prefixed with “JG – “.

—

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: Roger Carney mailto:rcar...@godaddy.com>>
Date: Monday, February 11, 2019 at 7:29 AM
To: Adam Roach mailto:a...@nostrum.com>>, 
"regext@ietf.org<mailto:regext@ietf.org>" 
mailto:regext@ietf.org>>
Cc: 
"draft-ietf-regext-epp-fees@ietf.org<mailto:draft-ietf-regext-epp-fees@ietf.org>"
 
mailto:draft-ietf-regext-epp-fees@ietf.org>>
Subject: [EXTERNAL] RE: AD Review: draft-ietf-regext-epp-fees-15
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Roger Carney mailto:rcar...@godaddy.com>>, 
Gavin Brown mailto:gavin.br...@centralnic.com>>, 
mailto:jot...@jothan.com>>, 
mailto:i...@antoin.nl>>, 
mailto:gal...@elistx.com>>, 
mailto:b...@nostrum.com>>, 
mailto:barryle...@computer.org>>, 
mailto:a...@nostrum.com>>, 
mailto:aamelni...@fastmail.fm>>, James Gould 
mailto:jgo...@verisign.com>>, James Gould 
mailto:jgo...@verisign.com>>
Resent-Date: Monday, February 11, 2019 at 7:29 AM


Good Morning,



Thanks for the review and input Adam.



·   Abstract updated with some more introductory verbiage.


JG - Simple fix


·   Updated 1.1 with lower “required”


JG - Simple fix

·   Updated 3.1 with “that” in place of “which”


JG - Simple fix



·   Updated 3.4 with “lang” attribute for consistency


JG - I assume that you’re going to add  to the feetype element of the XML schema, along with a 
description of the “lang” attribute in 3.4.  Would you also need to add the 
same “lang” attribute to the “creditType” element in the XML schema, and 
include it for the description of the  element in section 3.4?



·   Question on 3.4.1:  I thought the intent was your #1 interpretation “If 
a  element has a "grace-period" attribute but does not also contain 
"refundable='1'", then it is malformed”. I would like the list to provide 
thoughts.


JG - I would simply say “If a  element has a “grace-period” attribute 
then it must be refundable and the “refundable” attribute MUST be true.”



·   Interesting question on 3.5. I agree that either way would be ok, my 
thought was that the balance would not include “delayed”. I would like the list 
to provide thoughts.


JG - This one is interesting, since I view the  as being the 
balance as of a point of time.  The point in time should be when the response 
is created, so if the “applied” attribute is “immediate”, then the 
 MUST reflect the client’s account balance after any fees or 
credits associated with that command have been applied.  If the “applied” 
attribute is “delayed”, then the  MUST reflect the client’s 
account balance without any fees or credits associated with that command.



·   Updated 3.6 with “that” in place of “which”


JG - Simple fix


·   Updated 3.7 with “that” in place of “which”


JG - Simple fix



I will release revision 16 after some list discussion on 3.4.1 and 3.5.





Thanks

Roger





-Original Message-
From: Adam Roach mailto:a...@nostrum.com>>
Sent: Friday, January 4, 2019 9:08 PM
To: 
draft-ietf-regext-epp-fees@ietf.org<mailto:draft-ietf-regext-epp-fees@ietf.org>
Cc: regext@ietf.org<mailto:regext@ietf.org>
Subject: AD Review: draft-ietf-regext-epp-fees-15



This is my AD review of draft-ietf-regext-epp-fees. It looks to be in generally 
good shape, although I have marked two of my feedback items below as "DISCUSS".

This doesn't necessarily mean they need to result in document changes (as I 
might be mistaken), but I would like to make sure we address them in some way 
before I put the document into IETF last call.



The remainder of my comments should be treated the same as any IETF last call 
comments.



Thanks to everyone who has worked on this document, and I apologize for the 
longer-than-usual processing time on my part.



---



Abstract:



This section should probably be a bit longer, incorporating some of the 
background from the introduction.



---



§1.1:



>  Indentation and

>  whit

Re: [regext] AD Review: draft-ietf-regext-epp-fees-15

[Roger D Carney]

Good Morning,



Thanks for the review and input Adam.



·   Abstract updated with some more introductory verbiage.

·   Updated 1.1 with lower “required”

·   Updated 3.1 with “that” in place of “which”

·   Updated 3.4 with “lang” attribute for consistency

·   Question on 3.4.1:  I thought the intent was your #1 interpretation “If 
a  element has a "grace-period" attribute but does not also contain 
"refundable='1'", then it is malformed”. I would like the list to provide 
thoughts.

·   Interesting question on 3.5. I agree that either way would be ok, my 
thought was that the balance would not include “delayed”. I would like the list 
to provide thoughts.

·   Updated 3.6 with “that” in place of “which”

·   Updated 3.7 with “that” in place of “which”



I will release revision 16 after some list discussion on 3.4.1 and 3.5.





Thanks

Roger





-Original Message-
From: Adam Roach 
Sent: Friday, January 4, 2019 9:08 PM
To: draft-ietf-regext-epp-fees@ietf.org
Cc: regext@ietf.org
Subject: AD Review: draft-ietf-regext-epp-fees-15



This is my AD review of draft-ietf-regext-epp-fees. It looks to be in generally 
good shape, although I have marked two of my feedback items below as "DISCUSS".

This doesn't necessarily mean they need to result in document changes (as I 
might be mistaken), but I would like to make sure we address them in some way 
before I put the document into IETF last call.



The remainder of my comments should be treated the same as any IETF last call 
comments.



Thanks to everyone who has worked on this document, and I apologize for the 
longer-than-usual processing time on my part.



---



Abstract:



This section should probably be a bit longer, incorporating some of the 
background from the introduction.



---



§1.1:



>  Indentation and

>  white space in examples are provided only to illustrate element  >  
> relationships and are not a REQUIRED feature of this protocol.



This is a somewhat unconventional use of RFC-2119-style language. I would 
recommend using a lowercase "required" in this case.



---



§3.1:



>  The  element is used in the EPP  command to  >  
> determine the fee which is applicable to the given command.



Nit: "...the fee that is applicable..."



---



DISCUSS:



§3.4:



>  description: an OPTIONAL attribute which provides a human-readable  >  
> description of the fee.  Servers should provide documentation on the  >  
> possible values of this attribute, and their meanings.



Since this string is human-readable, localization considerations apply.

Minimally, this needs to include the ability to add a "lang" attribute, similar 
to what is done for 



---



DISCUSS:



§3.4.1 says:



>  If the "refundable" attribute is omitted, then clients SHOULD NOT  >  make 
> any assumption about the refundability of the fee.



§3.4.3 says:



>  If a  element has a "grace-period" attribute then it MUST  >  also 
> be refundable.



This second statement is a bit confusing in the context of the first one.

There's two ways to read it:



1. If a  element has a "grace-period" attribute but does not also

   contain "refundable='1'", then it is malformed; or



2. If a  element has a "grace-period" attribute but does not also

   contain "refundable='1'", then the client is required to make an

   assumption that the fee is refundable.



If the intention is #1, then the language in 3.4.3 needs to be more explicit.



If the intention is #2, then it contradicts the language in §3.4.1, and the 
language in §3.4.1 needs to be adjusted to indicate this exception.



---



§3.5:



>  If a server includes a  element in response to transform  >  
> commands, the value of the element MUST reflect the client's account  >  
> balance after any fees or credits associated with that command have  >  been 
> applied.



I'm confused about how this value interacts with applied="delayed".

Since the

charge won't happen during the course of the transaction, does the balance 
include the effect of applying the fee? I don't think it matters much whether 
the answer is "yes" or "no," as long as implementations are consistent (which I 
believe requires the behavior to be clearly specified in this section).



---



§3.6:



>  line of credit to the client.  A server MAY also include a  >  
>  element in responses which indicates the maximum  >  credit 
> available to a client



Nit: "...in responses that indicates..."

Re: [regext] list of documents to consider for working group adoption

[Roger D Carney]

Good Morning,

Please add https://datatracker.ietf.org/doc/draft-ietf-regext-validate/.


Thanks
Roger

-Original Message-
From: regext  On Behalf Of Gould, James
Sent: Friday, December 7, 2018 10:19 AM
To: gal...@elistx.com; regext@ietf.org
Subject: Re: [regext] list of documents to consider for working group adoption

Jim,

Thanks for putting the list together and I look forward to the Doodle poll.  

You can remove the following drafts from the list for now until we address the 
IPR with draft-gould-carney-regext-registry:

Registry Mapping
https://www.ietf.org/internet-drafts/draft-gould-carney-regext-registry/

Launch Phase Policy (Extension of Registry Mapping)
https://datatracker.ietf.org/doc/draft-gould-regext-launch-policy/

I would add the data escrow drafts to the list:

Registry Data Escrow Specification
https://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/

Domain Name Registration Data (DNRD) Objects Mapping
https://datatracker.ietf.org/doc/ draft-arias-noguchi-dnrd-objects-mapping/


I'm in the process of updating the Data Set File Format draft 
https://datatracker.ietf.org/doc/draft-gould-regext-dataset/ to support a 
report file definition, in addition to the existing bulk operation file 
defintion.  The draft will support an extensible set of file definitions, so if 
new file definitions are needed the draft can be used.  The definition can be 
in a separate file from the data, which is similar to the CSV approach in the 
data escrow drafts, or may be combined in the same file as the data, as 
currently defined in the existing version of draft-gould-regext-dataset.  The 
field definitions (domain, host, contact, registrar) can be reused across many 
types of definition files.  The meta-data about the files can be extensible - 
the meta-data for a bulk operation (i.e., bulk command and sub-command, client 
identifier, creation date) is different from the meta-data for a report (i.e., 
report type and sub-type, date or date-range, frequency, tld or tlds, account). 
 Support for a standard report definition file would help in formally defining 
the meta-data and format of any report.  This would help the registrars to 
automate the consumption of any report.  An IANA registry could be setup to 
register report identifiers and the associated format definitions for both 
custom and standardized reports.  This draft represents an opportunity for the 
working group to create a more generic solution for handling reports and bulk 
operations.  

—
 
JG



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

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

Verisign.com  

On 12/7/18, 9:38 AM, "regext on behalf of James Galvin" 
 wrote:

Included below is the list of potential documents and topics this 
working group could adopt.  The first step in moving forward is to make 
sure we have a complete list.  We are asking folks to review this list 
and make sure we have not missed anything.  We are allowing one week for 
this review, until Friday 14 December 2018.  During this time please do 
ask questions about documents or topics.

The next step will be for the working group members to indicate their 
top 5 choices of documents to move forward.  Recall that 5 is the 
maximum number of milestones suggested for us to have open at a time.  
If there is discussion to be had about this number please start a new 
email thread and we will see where it goes.

We will do this with a Doodle poll.  Hopefully you are familiar with 
this.  We will setup each document as a choice and you’ll be asked to 
select up to 5 documents.  In Doodle, you can select Yes, No, or 
IfNeedBe.  You can use the IfNeedBe option to indicate documents that 
you support but not as your top 5.  We will open this Doodle poll before 
the Christmas holiday and leave it open through Friday, 11 January.  
That should be plenty of time to get past holiday and vacation time that 
many folks will have during this time.

Once we have an ordered list of documents we will announce working group 
adoption requests and we will move forward with our work.  It’s going 
to be a busy year, 2019!

Registry Mapping
https://www.ietf.org/internet-drafts/draft-gould-carney-regext-registry/

Registry Reporting Repository

https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/

Registry Reporting Structure

https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/

Domain Fee Report
https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/

Registry Transaction Report

https://datatracker.ietf.org/doc/draft-mcpherson-sattler-ry-transaction-report/

Registry Domain Inventory Report

[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

[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] I-D Action: draft-ietf-regext-epp-fees-15.txt

[Roger D Carney]

Good Morning,

A small updated was needed, implementers found the "standard" attribute was not 
at the correct level in the commandDataType.


Thanks
Roger


-Original Message-
From: regext  On Behalf Of internet-dra...@ietf.org
Sent: Sunday, November 4, 2018 9:31 AM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.

Title   : Registry Fee Extension for the Extensible 
Provisioning Protocol (EPP)
Authors : Roger Carney
  Gavin Brown
  Jothan Frakes
Filename: draft-ietf-regext-epp-fees-15.txt
Pages   : 38
Date: 2018-11-04

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for registry fees.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-epp-fees-15
https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-15


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] FW: New Version Notification - draft-ietf-regext-change-poll-09.txt

[Roger D Carney]

Good Morning,



I just wanted to let the group know that I have updated the shepherd write-up 
this morning for this draft. The authors updated the draft based on the 
previous shepherd write-up addressing the “new” wording for drafts in section 
1.1. Only section 1.1 (and relevant references) were updated.



At this point, as shepherd, I believe this draft is ready for publication.





Thanks

Roger





-Original Message-
From: internet-dra...@ietf.org 
Sent: Thursday, October 4, 2018 12:57 PM
To: Roger D Carney 
Subject: New Version Notification - draft-ietf-regext-change-poll-09.txt





A new version (-09) has been submitted for draft-ietf-regext-change-poll:

https://www.ietf.org/internet-drafts/draft-ietf-regext-change-poll-09.txt





The IETF datatracker page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/



Diff from previous version:

https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-09



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



IETF Secretariat.


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

Re: [regext] Call for agenda items for Bangkok

[Roger D Carney]

Good Morning,

I think that that we could still benefit from a work session. 

With the RDAP Profile completing ICANN public comment in mid October and final 
publication expected in November, it may be a good time to review and answer 
(and confirm) any of the technical questions/issues.

I also think it would be great to work on one of the new items that will most 
likely be added to the WG work queue (e.g. Registry Reporting Repository, 
Registry Mapping, Validate, etc).


Thanks
Roger


-Original Message-
From: regext  On Behalf Of Antoin Verschuren
Sent: Friday, September 14, 2018 9:46 AM
To: Registration Protocols Extensions 
Subject: [regext] Call for agenda items for Bangkok

Hi all,

Next week is the cut-off date to schedule a WG meeting in Bangkok.
To get any insight in the time we need, could you please send agenda requests 
to the chairs?

We will certainly talk about new items to adopt and add to our milestone list 
now that many documents have proceeded to the publication process, and we will 
send a revised charter to the IESG next week.
Is there any need for a work session now that most documents that needed 
discussion have proceeded and the new items have not been presented yet?

Thanks,

Jim and Antoin

- --
Antoin Verschuren

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






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

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-12.txt

[Roger D Carney]

Good Afternoon,



This is revision 12 of the Fee document that we discussed last week at 
IETF-102. This is to address the last few items discussed on list and last week 
at the F2F meeting. For detailed discussion notes please see document shepherd 
James Gould's email to the list last Wednesday (2018JUL18).



Change Log: "Updated references to current version of documents and moved the 
"standard" attribute from the check command (commandType) to the check response 
(commandDataType)."





Thanks

Roger







-Original Message-
From: regext  On Behalf Of internet-dra...@ietf.org
Sent: Wednesday, July 25, 2018 1:36 PM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-12.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Registration Protocols Extensions WG of the 
IETF.



Title   : Registry Fee Extension for the Extensible 
Provisioning Protocol (EPP)

Authors : Roger Carney

  Gavin Brown

  Jothan Frakes

Filename: draft-ietf-regext-epp-fees-12.txt

Pages   : 37

Date: 2018-07-25



Abstract:

   This document describes an Extensible Provisioning Protocol (EPP)

   extension mapping for registry fees.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-regext-epp-fees-12

https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-12



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-12





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



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



___

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

[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] Proposed Revision to our Charter

[Roger D Carney]

Good Morning,



I was definitely not thinking of two working groups.



The focus of the WG is EPP and RDAP extensions. The additional suggested 
wording just adds on the ability to take on relevant (as determined by WG and 
AD) work (e.g. Third Party DNS Operator…). My suggestion was not to exclude, 
but to provide more focused wording. Maybe that wording is better, change the 
entire sentence to state: “The working group may also take on relevant (as 
determined by WG and AD) work, beyond the EPP and RDAP protocols.”



Andy, I think your original question that you posted earlier in the week is 
what needs to be answered first, paraphrasing “what is the motivation for this 
change”. Several others I think have basically asked the same question.



I don’t think I was the one asking for the charter change but here are my 
thoughts on why I see a change being beneficial.



To me this started with the proposed Third Party DNS Operator document. At one 
point the Charter was updated to add in this specific item (our current 
Charter). Then over the past year some discussions were had on standardizing 
the files that registries and registrars share (Unavailable Names, 
Non-Standard/Premium Domain Fees, Invoicing) which lead into the discussion of 
standardizing the storage of these files and other items (reporting comes to 
mind). Today different registries have different web portals and ftp sites to 
get this information from and different registrars request the information in 
different formats. Many registries and registrars have agreed that they would 
like to see a much better experience here. These topics do not fit into the 
EPP/RDAP focus of our current charter but the people with the most interest and 
expertise in these ideas are in this WG.





Thanks

Roger





-Original Message-
From: Andrew Newton [mailto:a...@hxr.us]
Sent: Wednesday, June 13, 2018 9:45 AM
To: Roger D Carney 
Cc: Registration Protocols Extensions 
Subject: Re: [regext] Proposed Revision to our Charter



On Wed, Jun 13, 2018 at 10:35 AM, Roger D Carney 
mailto:rcar...@godaddy.com>> wrote:

> Good Morning,

>

>

>

> I agree with those saying this new wording seems a bit broad, what if

> "...related to the operation of Internet identifier registries..." was

> changed to "...related to the operation of Internet domain name

> registration systems..."?



What about RIRs? Or would you suggest we split REGEXT into two working groups?



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

Re: [regext] Proposed Revision to our Charter

[Roger D Carney]

Good Morning,



I agree with those saying this new wording seems a bit broad, what if 
"...related to the operation of Internet identifier registries..." was changed 
to "...related to the operation of Internet domain name registration 
systems"?





Thanks

Roger







-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
Sent: Friday, June 08, 2018 8:52 AM
To: Registration Protocols Extensions 
Subject: [regext] Proposed Revision to our Charter



As we have discussed in at least the last two IETF meetings, we would like to 
propose broadening the responsibility of this working group to cover the 
standards related generally to Internet Identifier systems.



Attached you will find a proposed revision to our charter that would allow this.



Please review and provide any comments or concerns to the mailing list.



There is a PDF that shows the changes to the charter and a text file of the 
proposed new charter with the changes already incorporated.



Thanks,



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

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



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.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







On 06/06/18 14:22, "regext on behalf of Gould, James" 
mailto:regext-boun...@ietf.org%20on%20behalf%20of%20jgould=40verisign@dmarc.ietf.org>>
 wrote:

Re: [regext] Potential Topic for IETF-102: RDAP Search Capabilities

[Roger D Carney]

Good Morning,



For the two hour working session I would suggest three forty minute sessions 
(in no specific order):

  *   Unhandled Namespaces (Jim Gould)
  *   Registry Mapping (Roger)
  *   RDAP Search and Authentication (Francisco/Scott)





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Friday, June 01, 2018 8:03 AM
To: Hollenbeck, Scott 
Cc: regext@ietf.org
Subject: Re: [regext] Potential Topic for IETF-102: RDAP Search Capabilities



Scott,



Sounds like an excellent idea.

Since it's new work, I assume we would like to have that discussion in our 
"work session"?, and Francisco is willing to lead that discussion?



- --

Antoin Verschuren



Tweevoren 6, 5672 SB Nuenen, NL

M: +31 6 37682392













Op 30 mei 2018, om 20:19 heeft Hollenbeck, Scott 
mailto:shollenbeck=40verisign@dmarc.ietf.org>>
 het volgende geschreven:



> Folks, one of the questions that came up during a presentation at the recent 
> Registration Operations Workshop was focused on RDAP's search capabilities 
> and if they were sufficient for use in the gTLD community. Francisco Arias 
> has some thoughts on functional requirements, so I thought it might be a good 
> idea to talk about the topic at IETF-102. Francisco has confirmed that he's 
> available and can talk to the topic. Can we consider adding this topic to our 
> meeting agenda?

>

> Scott

>

> ___

> 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] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

[Roger D Carney]

Good Afternoon,

+1.

We agree that that we should move forward with the current 
draft-ietf-regext-change-poll draft and move this discussion along another path.


Thanks
Roger


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Friday, May 04, 2018 9:16 AM
To: James Galvin 
Cc: Patrick Mevzek ; regext@ietf.org
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D 
Action: draft-ietf-regext-change-poll-07.txt)

Jim,

My recommendation is to move forward with draft-ietf-regext-change-poll and to 
leave the EPP server sending unsupported responses (mapping extension and / or 
command response extensions) to a client based on the login services up to a 
separate draft.

This comes down to the interpretation of how the server should handle the login 
services of the client in creating responses.  EPP extensions like the DNSSEC 
extension (RFC 5910) leverages the login services in the migration from RFC 
4310 to RFC 5910, since the info response may include the DNSSEC extension if 
there is DNSSEC data.  The inclusion of the DNSSEC extension and the version of 
the DNSSEC extension is based on the login services.  Similar functionality 
exists within draft-ietf-regext-epp-fees in determining if and which version of 
the extension to return to the client.  Poll messages are unique since they are 
inserted ahead of time by the server without knowledge of what the client does 
support, and therefore runs the risk of coming across a message that the client 
does not support based on the login services.  Clients may or may not be able 
to handle the parsing and unmarshalling of unsupported extensions sent by the 
server.  For poll messaging this is of particular interest, since a client may 
have an issue acknowledging the unsupported poll messages to get to the rest of 
the messages in the queue.  This would represent a poison message in the poll 
queue.

Based on the thread, there are separate thoughts related to whether it is fine 
for the server to send a response that contains an extension that was not 
included in the client’s login services.  I believe that the greeting services 
and the login services are used to negotiate the set of extensions that client 
are server can use.  What should the EPP server do with unsupported extensions 
in any EPP response and with poll message EPP responses in particular?  This is 
a broader topic than draft-ietf-regext-change-poll, so I recommend that we 
don’t attempt to solve the problem specifically for 
draft-ietf-regext-change-poll but more generically across all of the extensions 
in a separate draft.


—

JG

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

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

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

Verisign.com
From: James Galvin >
Date: Friday, May 4, 2018 at 9:31 AM
To: James Gould >
Cc: Patrick Mevzek >, 
"regext@ietf.org" 
>
Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was 
Re: I-D Action: draft-ietf-regext-change-poll-07.txt)


The chairs would appreciate a suggestion from those in this discussion as to 
what you would like to do next?

The change-poll document has been in WGLC that has now expired. However, you 
have identified a technical issue but you have not been clear as to whether you 
want a change in the existing document or you want a new work item for the 
working group?

What would you propose? What do others think?

Antoin and Jim



On 23 Apr 2018, at 9:27, Gould, James wrote:

Patrick,



This may be an excellent topic for a working session at the next IETF.  It 
would be great to hear opinions from others on this topic, since there is 
obviously a gap in the interpretation of the greeting and login services as it 
relates to responses (command responses and poll response) provided by the 
server.



Your description still leaves out a case, that I cannot prove to be the 
dominant one but that is certainly not a negligible one: the client receives 
the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just 
stores it (as is or with a simple transformation to any other serialization 
format, an operation that does not need to know about the schema nor the 
content at all) for out of band later examination, and ACKs it in EPP to be 
able to fetch the next one.



How can the client ack the message if it doesn’t at least parse it for the 
message id?  An EPP client should frame the responses per RFC 5734 and will 
most likely parse the response to determine the result of the command and in 
the case of a poll message parse the message id to send the subsequent poll 
ack.  The client could use regular expressions to extract the information or 

[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] Preparing for IETF 101

[Roger D Carney]

Good Morning,


Things for sending this out Antoin.


Yes, I agree that we should meet in London.


I think our last meeting showed that trying to combine the regular meeting and 
a working session does not work. I would like to suggest a 90 minute regular 
session and a second 60 minute working session. I would prefer that the working 
session is scheduled before the regular session so updates can be presented at 
the regular session.

I would like a few minutes to talk about the updates to the Fee draft, the 
Registry Mapping draft and the Validate draft.

As for the working session, I would think Registry Mapping may be a good topic, 
once we have our next interim meeting we will know better on specifics to work 
on.


Thanks
Roger



From: regext  on behalf of Antoin Verschuren 

Sent: Friday, January 26, 2018 9:10 AM
To: Registration Protocols Extensions
Subject: [regext] Preparing for IETF 101

Dear Working group,

It’s time to start planning for IETF 101 in London.
We would like to hear from the working group if anyone wants to request 
additional work meeting time.

I guess we want to meet in London, and we plan to request a 2 hour session that 
we will split up in a regular and a work session.
Should this not be enough we can also request the ad-hoc conference room for an 
additional work session.

Please start thinking about agenda items and let us know what you think before 
next friday when scheduling is due.

regards,

Jim and Antoin

- --
Antoin Verschuren

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






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

Re: [regext] WGLC: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees

[Roger D Carney]

Thanks Jim, I will add some text to describe this attribute and look to add an 
example.



From: Gould, James <jgo...@verisign.com>
Sent: Friday, January 26, 2018 10:15 AM
To: Roger D Carney; 'regext@ietf.org'
Subject: Re: [regext] WGLC: 
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees


Roger,



In reviewing the latest draft, I notice the inclusion of the optional 
“standard” attribute in the commandType XSD type, with a default of “0”, that 
is not described in the text.  Is there an intention to support the “standard” 
attribute in the  element?



Thanks,



—



JG

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

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

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

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

From: regext <regext-boun...@ietf.org> on behalf of Roger Carney 
<rcar...@godaddy.com>
Date: Friday, January 26, 2018 at 10:35 AM
To: "'regext@ietf.org'" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] WGLC: 
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees



Thanks Scott, I will take a look at those sections





From: regext <regext-boun...@ietf.org> on behalf of Hollenbeck, Scott 
<shollenb...@verisign.com>
Sent: Friday, January 26, 2018 9:15 AM
To: 'gal...@elistx.com'; 'regext@ietf.org'
Subject: Re: [regext] WGLC: 
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees



> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
> Sent: Friday, January 26, 2018 9:39 AM
> To: Registration Protocols Extensions <regext@ietf.org>
> Subject: [EXTERNAL] [regext] WGLC: https://datatracker.ietf.org/doc/draft-
> ietf-regext-epp-fees
>
> The document editors have indicated that the following document is ready
> for submission to the IESG to be considered for publication as a Proposed
> Standard:
>
> Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees-09
>
> Please indicate your support for the publication of this document.

I support publication of this document. I have only one multi-faceted comment:

Section 8.1 includes instructions to IANA to register an XML namespace. This 
should be broken into two requests, with one used to register the namespace and 
a second request to register the Schema from Section 6.1. Section 6 of RFC 5732 
is one example of the appropriate structure for the namespace and Schema 
registration requests.

Since this is a Standards Track proposal, the IESG should be used as the 
registrant contact for both registration requests in Sections 8.1 and 8.2.

Scott
___
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] WGLC: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees

[Roger D Carney]

Thanks Scott, I will take a look at those sections



From: regext  on behalf of Hollenbeck, Scott 

Sent: Friday, January 26, 2018 9:15 AM
To: 'gal...@elistx.com'; 'regext@ietf.org'
Subject: Re: [regext] WGLC: 
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees

> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
> Sent: Friday, January 26, 2018 9:39 AM
> To: Registration Protocols Extensions 
> Subject: [EXTERNAL] [regext] WGLC: https://datatracker.ietf.org/doc/draft-
> ietf-regext-epp-fees
>
> The document editors have indicated that the following document is ready
> for submission to the IESG to be considered for publication as a Proposed
> Standard:
>
> Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees-09
>
> Please indicate your support for the publication of this document.

I support publication of this document. I have only one multi-faceted comment:

Section 8.1 includes instructions to IANA to register an XML namespace. This 
should be broken into two requests, with one used to register the namespace and 
a second request to register the Schema from Section 6.1. Section 6 of RFC 5732 
is one example of the appropriate structure for the namespace and Schema 
registration requests.

Since this is a Standards Track proposal, the IESG should be used as the 
registrant contact for both registration requests in Sections 8.1 and 8.2.

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

Re: [regext] New Version Notification for draft-ietf-regext-epp-fees-09.txt

[Roger D Carney]

Good Morning,


We posted the latest version of the Fee draft late last week.


This document is now ready for WGLC, I would like to ask the chairs to move 
this document forward.



Thanks

Roger




From: internet-dra...@ietf.org <internet-dra...@ietf.org>
Sent: Friday, January 19, 2018 3:48 PM
To: Jothan Frakes; Gavin Brown; Roger D Carney; Roger D Carney
Subject: New Version Notification for draft-ietf-regext-epp-fees-09.txt


A new version of I-D, draft-ietf-regext-epp-fees-09.txt
has been successfully submitted by Roger Carney and posted to the
IETF repository.

Name:   draft-ietf-regext-epp-fees
Revision:   09
Title:  Registry Fee Extension for the Extensible Provisioning Protocol 
(EPP)
Document date:  2018-01-19
Group:  regext
Pages:  36
URL:
https://www.ietf.org/internet-drafts/draft-ietf-regext-epp-fees-09.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/
draft-ietf-regext-epp-fees-09 - Registry Fee Extension for the Extensible 
Provisioning Protocol (EPP) 
<https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/>
datatracker.ietf.org
Registry Fee Extension for the Extensible Provisioning Protocol (EPP) 
(Internet-Draft, 2018)



Htmlized:   https://tools.ietf.org/html/draft-ietf-regext-epp-fees-09
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-09
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-09

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for registry fees.




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

The IETF Secretariat

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

[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

[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

[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 Fee Document

[Roger D Carney]

Good Afternoon,

As mentioned today in the REGEXT face to face meeting at IETF-100 in Singapore, 
we have two remaining questions open on the current draft 
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees.


  1.   "avail" attribute meaning on partial return of results, see section 
3.9 for some additional context. The extension allows servers to choose between 
returning no results or partial results when a server encounters an issue with 
one or more of the requested s. The question raised specifically was 
"Should a partial result set the  "avail" attribute to true or false". The 
intent of the draft was to return "avail=0" on partial (there was some 
failure), but some implementations have interpreted it as "avail=1" (some data 
returned). What do people think?
  2.  Appropriate level of , see section 3.7 for more details. There 
has been an ongoing discussion on moving the  element to the object 
level (i.e. at the  level versus the  level). Currently the draft 
has this at the  level but I do believe in the merits of the argument 
that in reality/practice  is defined at the domain object level and not 
the command level, so unless there are arguments to keep it at the command 
level the next version will move this to the object, , level.

After comments have been received and document updated accordingly, we will ask 
for WGLC.


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] Preparing for IETF 100

[Roger D Carney]

Good Morning,

This sounds like a productive process.


Thanks
Roger


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, September 26, 2017 7:31 AM
To: 'i...@antoin.nl' <i...@antoin.nl>; 'regext@ietf.org' <regext@ietf.org>
Subject: Re: [regext] Preparing for IETF 100

Here's a thought: identify the milestone documents for which there has been no 
discussion, no progress, and no requests for meeting time slots. Schedule 
meeting time to talk about removing them as milestones so we can make room for 
other documents.

Scott

From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Tuesday, September 26, 2017 8:14 AM
To: Registration Protocols Extensions <regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] Preparing for IETF 100

Hi all,

So far, we only had one reply from Roger for agenda items.
With one of the items for a working session being discussed in an Interim 
meeting before IETF100, this seems like we will not have enough topics to 
justify a full working session during IETF100.
This feels a bit contradictory to the desire to have a seperate working session.

We will probably opt for one longer update session where the additional time 
will be dedicated to working items.
Any thoughts? Any more agenda items?

Jim and Antoin

- --
Antoin Verschuren

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




Op 20 sep. 2017, om 17:55 heeft Roger D Carney 
<rcar...@godaddy.com<mailto:rcar...@godaddy.com>> het volgende geschreven:

Good Morning,

I would like to suggest the following agenda items for the working session:

  *   The Validate draft
  *   Registry Mapping and Launch Phase Listing

And for updates:

  *   Fee
  *   Validate
  *   Interim Meetings


Thanks
Roger


-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Friday, September 15, 2017 8:30 AM
To: Registration Protocols Extensions <regext@ietf.org<mailto:regext@ietf.org>>
Subject: [regext] Preparing for IETF 100

Dear Working group,

It's time to start planning for IETF 100 in Singapore.
To be able to judge if we need a working session, we have 2 questions for you

1. Please submit agenda items to the list.
2. Please indicate if you need working time or update time for your item.

Since we need to request meeting slots within a fortnight please submit your 
discussion items before friday 22th so we can discuss if:

1. We can discuss items in a interim meeting before IETF 100 and only need 1 
update session.
2. We need both a working session and a short update session for IETF 100.
3. Or we can do with one longer joint working/update session.

Thanx,

Jim and Antoin

- --
Antoin Verschuren

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






___
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] Preparing for IETF 100

[Roger D Carney]

Good Morning,



I would like to suggest the following agenda items for the working session:

  *   The Validate draft
  *   Registry Mapping and Launch Phase Listing



And for updates:

  *   Fee
  *   Validate
  *   Interim Meetings





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Friday, September 15, 2017 8:30 AM
To: Registration Protocols Extensions 
Subject: [regext] Preparing for IETF 100



Dear Working group,



It's time to start planning for IETF 100 in Singapore.

To be able to judge if we need a working session, we have 2 questions for you



1. Please submit agenda items to the list.

2. Please indicate if you need working time or update time for your item.



Since we need to request meeting slots within a fortnight please submit your 
discussion items before friday 22th so we can discuss if:



1. We can discuss items in a interim meeting before IETF 100 and only need 1 
update session.

2. We need both a working session and a short update session for IETF 100.

3. Or we can do with one longer joint working/update session.



Thanx,



Jim and Antoin



- --

Antoin Verschuren



Tweevoren 6, 5672 SB Nuenen, NL

M: +31 6 37682392












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

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

[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

Re: [regext] TLD Phase Discovery

[Roger D Carney]

Good Morning,



To me it seems:

1. That this is somewhat of a corner case.

2. I don't think the current draft of launchphase addresses the issue Thomas is 
expressing.

3. I don't think there is a need to modify launchphase for this functionality.



Sending a separate note to discuss Thomas' issue.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Monday, August 07, 2017 10:19 AM
To: Thomas Corte ; regext@ietf.org
Cc: supp...@tango-rs.com
Subject: Re: [regext] TLD Phase Discovery



Thomas,



My feedback is provided below with a “JG-“ prefix.



From a high level, we need other registries and registrars to weigh in on this 
topic to answer the following:



1. Is phase-dependent availability (e.g., domain available only in specific 
launch phases) a corner case?

2. Does the existing Availability Check Form in draft-ietf-regext-launchphase 
satisfy the need?

3. Is adding a new check form to draft-ietf-regext-launchphase (e.g., Phase 
Availability Check Form) needed?



My answer to the questions is Yes, Yes, and No.  We need others to help 
determine the path forward for draft-ietf-regext-launchphase.



Thanks,



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 8/7/17, 5:22 AM, "regext on behalf of Thomas Corte" >
 wrote:



James,



On 04/08/2017 16:58, Gould, James wrote:



> Thomas,

>

> I believe the domain-level availability based on launch phases is a

> corner case that as you point out is currently supported by the

> Availability Check Form in draft-ietf-regext-launchphase.  Providing

> trial-and-error probing is sort of the point of the Check Command and

> its extensions, so I’m not sure whether there is a real problem to

> solve here.



Imagine a registry setup where certain domains names are available, but

only in certain launch phases (as described in the current launch phase

extension spec, so it's obviously not a "corner case" scenario at all).



JG-I believe this use case is a “corner case”.  Of the TLD’s that we’ve 
launched, there are only a few that had specific availability rules associated 
with a Limited Registration Period (LRP), that did not warrant creating or 
changing a check form defined in draft-ietf-eppext-launchphase.  The 
Availability Check Form was added to draft-ietf-eppext-launchphase based on a 
request by James Mitchell.  Can the other registries identify whether this is a 
corner case or not?  I would also like to hear from the registries and the 
registrars whether the existing Availability Check Form does not address it?



Now, to find the right launch phase, a registrar seeking to register one

of those names now needs to:



1) Determine the available launch phases (either out-of-band, or using

the newly discussed facility to enumerate existing launch phases, i.e.

possibly yet another extension)



2) Send one  command for every single of these launch phases,

until the server signals the domain's availability for the name.



With x launch phases running in parallel, this would require up to x+1

commands just to determine the right phase.

That's not only inconvenient for the registrar, but also puts a strain on

the server where no optimization of this task can happen.



JG-I believe the Available Check Form was added to fulfil the need of 
determining whether a domain is available in a specific launch phase.  The 
Availability Check Form should be lightweight and it should not be very 
difficult for a client to get what is needed once they know what the launch 
phases are either out-of-band or via an extension like the Registry Mapping.



> Your proposal is to pass any empty  extension element

> with type=”avail”, to indicate the Availability Check Form, to the

> Domain Check Command for the server to return the list of launch

> phases where the domain name is available. What is the expected

> behavior of the Domain Check Command itself?  Is the availability of

> the domain name based on the current phase?  If this is the case, then

> we’re getting into the territory of merging two commands (availability

> of domain in current phase and get a list of phases that the domain is

> available) into one.  If such a feature is really needed, I would

> propose creating another check form (e.g. “Phase Availability Check

> This Form” with a type value of “phase-avail”) that only returns the

> list of phases that the domain is available in or a list of all the

> known phases with an availability flag for each 

[regext] Interim Meeting Invite

[Roger D Carney]

Good Afternoon,

I would like to invite everyone to an interim meeting Wednesday August 23 at 
15:00 UTC for 60 minutes.

As you may have seen I have recently published new versions of the Fee draft, 
draft-ietf-regext-epp-fees-06 and of the Validate draft 
draft-ietf-regext-validate-02.

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

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] Multiple REGEXT Sessions at IETF Meetings

[Roger D Carney]

Good Afternoon,

I just wanted to start (continue) the discussion about having two sessions for 
REGEXT at IETF meetings. As many of you heard me say in Prague, I thought that 
the extra working session that we had in Chicago was very productive and I 
would like to see this continue with future meetings. I would like to propose 
two meetings during the week:  a working session (90-120 minutes) earlier in 
the week and; a status session (90 minutes) later in the week, preferably two 
or three days after the working session (e.g. Mon-Wed or Mon-Thur).

Please share with the list if you support this idea or if you have other 
thoughts on how we can make these meetings as productive as possible.


Thanks
Roger

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

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-05.txt

[Roger D Carney]

Good Afternoon,

Thanks Thomas, I will make sure we get that updated.


Thanks
Roger


-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Thomas Corte
Sent: Tuesday, June 27, 2017 9:03 AM
To: regext@ietf.org
Cc: supp...@tango-rs.com
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-05.txt

Hello,

On 2017-06-24 17:50, internet-dra...@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Registration Protocols Extensions of the 
> IETF.
> 
> Title   : Registry Fee Extension for the Extensible 
> Provisioning Protocol (EPP)
> Authors : Roger Carney
>   Gavin Brown
>   Jothan Frakes
>   Filename: draft-ietf-regext-epp-fees-05.txt

Thanks for this new version.


I noticed one minor issue (carried over from previous versions) that should be 
corrected. Section 5.1.1 says

   If "avail" is false then the 
   element MUST contain a  element (as described in
   Section 3.9) and the server MAY eliminate some or all of the
element(s).

However, eliminating *all* of the  elements isn't allowed by the 
schema since the "command" element must appear at least once in
"objectCDType":


  



  
  


The "command" element should therefore be defined using minOccurs="0".
Otherwise, a server is forced to include an (empty) dummy command element to 
satisfy the schema.

Note that the seemingly obvious change (use an XSD  between  
and ) won't work since there may be situations in which commands are 
present (all unavailable with reason, such as "wrong
period") and the overall availability is false.

Best regards,

Thomas Corte

--
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

___
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] interim meetings proposal

[Roger D Carney]

Good Afternoon,



The latest revision, 05, of the fee draft was just posted.



I would like to invite everyone to an interim meeting to discuss the most 
current revision of the Fee draft, draft-ietf-regext-epp-fees-05. This latest 
draft should account for all comments to this point.



The meeting will be held Tuesday July 11th, 2017 at 13:00 UTC. We will utilize 
Zoom as the conferencing tool, please use this 
link<https://godaddy.zoom.us/j/944283307> to connect to the meeting.





Thanks

Roger





-Original Message-
From: James Galvin [mailto:gal...@elistx.com]
Sent: Friday, June 23, 2017 8:19 AM
To: Jody Kolker <jkol...@godaddy.com>
Cc: Roger D Carney <rcar...@godaddy.com>; Registration Protocols Extensions 
<regext@ietf.org>
Subject: Re: [regext] interim meetings proposal



Yes, please, let’s move forward with scheduling a meeting to discuss the fee 
document on 11 July.



Please take the lead.



Jim







On 21 Jun 2017, at 11:18, Jody Kolker wrote:



> Thanks Jim/Antion/Adam,

>

> I fully support having virtual meetings between full IETF meetings.  I

> think it would help to move documents along faster.  Roger and I were

> discussing having a meeting for the fee document on July 11th.  Will

> we be able to have an approved meeting on that day?

>

>

> Thanks,

> Jody Kolker

>

>

> -Original Message-

> FromR: regext [mailto:regext-boun...@ietf.org] On Behalf Of James

> Galvin

> Sent: Friday, June 16, 2017 12:55 PM

> To: Roger D Carney <rcar...@godaddy.com<mailto:rcar...@godaddy.com>>

> Cc: Registration Protocols Extensions 
> <regext@ietf.org<mailto:regext@ietf.org>>

> Subject: Re: [regext] interim meetings proposal

>

>

>

> On 16 Jun 2017, at 12:40, Roger D Carney wrote:

>

>> Good Afternoon,

>>

>>

>>

>> I think this is a great idea and I think this process looks

>> acceptable. I have just one question and one comment.

>

> Thanks!

>

>

>> Question: To clarify number 3 below "...chairs will handle

>> administrative tasks...summary...", I assume the summary will be

>> provided by the requester to the chairs for correct handling?

>

> Yes, that would be our preference.  In fact, to go a step farther in

> detail, if the interim meetings are “one document” meetings, then the

> author/editor will prepare for the meeting with a bulleted list of

> “issues” to discuss.  The summary is most likely just the same

> bulleted list with a few sentences or paragraphs (as needed) to state

> the consensus of the meeting regarding the issue.  This summary could

> be posted to the list as is, as well as being used as the Secretariat

> summary.

>

>

>>

>>

>>

>> Comment: As for "...as a replacement for the second WG meetings at

>> IETF meetings...", I would like to see these interim meetings as an

>> addition to and not a replacement. I think the F2F working sessions

>> that we had at IETF-98 were very productive and we should try to keep

>> doing.

>

> Thanks for this.  We won’t have this option in Prague unfortunately

> (the Chairs had timing conflicts this time) but I’m interested in

> other points of view for the future.

>

> Jim

>

>

>>

>>

>>

>>

>>

>> Thanks

>>

>> Roger

>>

>>

>>

>>

>>

>> -Original Message-

>> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James

>> Galvin

>> Sent: Friday, June 16, 2017 8:41 AM

>> To: Registration Protocols Extensions 
>> <regext@ietf.org<mailto:regext@ietf.org>>

>> Subject: [regext] interim meetings proposal

>>

>>

>>

>> In addition to updating our milestones, a few folks have asked us

>> privately for interim meetings to help move along our documents.  The

>> Chairs have followed up with our Area Director and in this message we

>> have a proposal for interim meetings for the working group to

>> consider.

>>

>>

>>

>> For reference the IETF has some guidance on interim meetings located

>>

>> here:

>>

>>

>>

>> http://ietf.org/iesg/statement/interim-meetings.html

>>

>>

>>

>>

>>

>>

>>

>> Here is what we propose.  Please review and comment on the list by

>> Friday, 23 June 2017.

>>

>>

>>

>> 1. Any author/editor from a document on our milestone list can

>> request an interim meeting.  As long as there is no objection from

>> the working group the meeting can proceed.  In general, the

>> author/editor woul

Re: [regext] interim meetings proposal

[Roger D Carney]

Hi Thomas,



Yes, there will be a new version soon, looking like early next week. The pace 
has been to allow for additional comments. We are in the process of final edits 
today with peer reviews later this week.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Thomas Corte
Sent: Wednesday, June 21, 2017 10:32 AM
To: regext@ietf.org
Cc: supp...@tango-rs.com
Subject: Re: [regext] interim meetings proposal



Hello Jody,



On 21/06/2017 17:18, Jody Kolker wrote:



> Thanks Jim/Antion/Adam,

>

> I fully support having virtual meetings between full IETF meetings.  I think 
> it would help to move documents along faster.  Roger and I were discussing 
> having a meeting for the fee document on July 11th.  Will we be able to have 
> an approved meeting on that day?



The meeting aside, may we still expect a new version of the fee extension draft 
(with the fixes suggested by James Gould and myself on this list) before July 
11th?



To be frank, I'm not quite happy with the sluggish pace at which the fee 
extension has been maintained recently, i.e. in my point of view, some of the - 
in part rather trivial - changes have taken quite some time to be incorporated, 
and sometimes new issues were introduced in the process.



That being said, please note that I'm quite aware that all of this is 
voluntary, unpaid work, and I truly appreciate the efforts of all people 
involved. Then again, many of our registrars are waiting for a new, stable 
version of the fee extension, which therefore at this point must be regarded as 
a crucial part of many registries' EPP interface.

It should therefore be maintained with sufficient dedication.



Best regards,



Thomas



--

TANGO REGISTRY SERVICES® is a product of:

Knipp Medien und Kommunikation GmbH

Technologiepark Phone: +49 231 9703-222

Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200

D-44227 Dortmund   E-Mail: 
supp...@tango-rs.com

Germany



___

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] interim meetings proposal

[Roger D Carney]

Good Afternoon,



I think this is a great idea and I think this process looks acceptable. I have 
just one question and one comment.



Question: To clarify number 3 below "...chairs will handle administrative 
tasks...summary...", I assume the summary will be provided by the requester to 
the chairs for correct handling?



Comment: As for "...as a replacement for the second WG meetings at IETF 
meetings...", I would like to see these interim meetings as an addition to and 
not a replacement. I think the F2F working sessions that we had at IETF-98 were 
very productive and we should try to keep doing.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
Sent: Friday, June 16, 2017 8:41 AM
To: Registration Protocols Extensions 
Subject: [regext] interim meetings proposal



In addition to updating our milestones, a few folks have asked us privately for 
interim meetings to help move along our documents.  The Chairs have followed up 
with our Area Director and in this message we have a proposal for interim 
meetings for the working group to consider.



For reference the IETF has some guidance on interim meetings located

here:



http://ietf.org/iesg/statement/interim-meetings.html







Here is what we propose.  Please review and comment on the list by Friday, 23 
June 2017.



1. Any author/editor from a document on our milestone list can request an 
interim meeting.  As long as there is no objection from the working group the 
meeting can proceed.  In general, the author/editor would be expected to 
moderate the meeting but anyone can volunteer.



2. The meeting can be a teleconference, which someone will need to provide.  
You can also have a physical meeting if there is interest and the logistics can 
be organized by the participants.



3. The Chairs will handle the administrative tasks with the IETF Secretariat.  
The basics are that the meeting must be reported to the IETF Secretariat, the 
agenda must be provided, and at the conclusion of the meeting a summary must be 
provided that includes the list of participants.



4. There are two critical details that must be respected: the meeting must be 
announced with its agenda provided at least one week before it actually begins, 
preferably two weeks, and the meeting summary must be provided within 10 days 
of the close of the meeting.



5. Finally, please note that any actions taken or decisions made at the interim 
meeting are not final.  They must be reviewed and accepted on the mailing list.





If we can come to a consensus that this is acceptable, with any changes that we 
agree to during the discussion here, we will adopt this and tell the folks who 
wanted to have a meeting to suggest it and arrange to have it.



If we have interim meetings, these could serve as a replacement for the second 
working group meeting that we had at the last IETF meeting.





Thanks,



Antoin and Jim



___

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] Proposed Changes to Milestones

[Roger D Carney]

Good Morning,

Thanks for looking Jim. I am referring to this snipet (and memoryJ) from the 
reseller discussion in the minutes:

“Jim Galvin (as Chair): WG has two roles: a) create extensions that several 
people require, and standardize those b) just register the extension with IANA 
- path to go forward in this case would be b) since it does not seem to be 
applicable to a broad community”


Thanks
Roger


From: Gould, James [mailto:jgo...@verisign.com]
Sent: Friday, May 19, 2017 11:01 AM
To: Roger D Carney <rcar...@godaddy.com>; Registration Protocols Extensions 
<regext@ietf.org>
Subject: Re: [regext] Proposed Changes to Milestones

Roger,

I don’t see the decision you outline in the minutes from IETF-97 ( 
https://www.ietf.org/proceedings/97/minutes/minutes-97-regext-00 ).  Do you 
know where that decision was captured?

Thanks,

—

JG

[cid:image001.png@01D2D094.277F5840]

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

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

VerisignInc.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, May 19, 2017 at 11:01 AM
To: Registration Protocols Extensions <regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] Proposed Changes to Milestones


Good Morning,



Thanks Jim/Antoin for working through all of these documents.



I think these updates look good, except for a question on the reseller 
documents. As I mentioned on list back in March, I thought in Seoul we decided 
to review and comment but to not dedicate WG effort to these drafts?



As far as the bundling and idn drafts, I have not followed these with too much 
intensity so I will defer to others on these documents.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
Sent: Friday, May 19, 2017 8:41 AM
To: Registration Protocols Extensions <regext@ietf.org<mailto:regext@ietf.org>>
Subject: [regext] Proposed Changes to Milestones



During the last IETF meeting we had a request to adopt another document.

  As part of that discussion our AD expressed concern about the number of 
documents currently on our list and the number of milestones currently on our 
list.



The Chairs took an action to review both of these and we now have a proposal 
for consideration by the working group.



To see the list of current milestones review this link:



https://datatracker.ietf.org/group/regext/about/



To see the list of current documents review this link:



https://datatracker.ietf.org/group/regext/documents/



The Chairs have contacted the authors of all documents and asked for their 
feedback regarding the status of their document, reviewed the current proposed 
milestone dates, and propose the following.  These are shown as they are listed 
in the current milestones.







draft-ietf-regext-launchphase

   WGLC finished. Waiting for shepherd write-up adjustments before submitting 
to IESG.

   Action: Change milestone date to June 2017.



draft-ietf-regext-tmch-func-spec

   Status changed to Informational. Changed to Parked document.

   Action: Delete from milestone list.



draft-ietf-regext-epp-rdap-status-mapping

   RFC 8056

   Action: Set Status Resolved on milestone list.



draft-ietf-regext-epp-fees

   Recent version submitted. Active discussion.

   Action: Change milestone date to July 2017.



draft-ietf-regext-reseller

draft-ietf-regext-reseller-ext

   These drafts have been replaced by draft-ietf-regext-org and 
draft-ietf-regext-org-ext.

   Active discussion.

   Action: Accept new documents, replace on milestones, Change milestone date 
to Nov 2017.



draft-gould-eppext-verificationcode

   No reaction from authors.

   Action: Replace to draft-ietf-regext-verificationcode on milestone list

   Change milestone date to June 2018.



draft-xie-eppext-nv-mapping

   (current milestone listing but document is really

draft-ietf-regext-nv-mappgin)

   Informational document, waiting for

draft-ietf-regext-verificationcode

   Action: Change to parked document. Delete from milestone list.



draft-gould-change-poll (change to draft-ietf-regext-change-poll)

   Needs more reviewers and implementation.

   Action: Change milestone date to Nov 2017.



draft-gould-allocation-token (change to

draft-ietf-regext-allocation-token)

   Needs implementation status section and review.

   Action: Change milestone date to Nov 2017.



draft-ietf-regext-bundling-registration

   New version submitted for STRICT bundling.

draft-ietf-eppext-idnmap

draft-gould-idn-table

draft-cira-regext-idn

   These documents have discussion but no consensus. All these documents relate.

   Some want all IDN to be included in bundling discussion.

   Action: Discuss.  Chairs do not have a proposal for a milesto

Re: [regext] Proposed Changes to Milestones

[Roger D Carney]

Good Morning,



Thanks Jim/Antoin for working through all of these documents.



I think these updates look good, except for a question on the reseller 
documents. As I mentioned on list back in March, I thought in Seoul we decided 
to review and comment but to not dedicate WG effort to these drafts?



As far as the bundling and idn drafts, I have not followed these with too much 
intensity so I will defer to others on these documents.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
Sent: Friday, May 19, 2017 8:41 AM
To: Registration Protocols Extensions 
Subject: [regext] Proposed Changes to Milestones



During the last IETF meeting we had a request to adopt another document.

  As part of that discussion our AD expressed concern about the number of 
documents currently on our list and the number of milestones currently on our 
list.



The Chairs took an action to review both of these and we now have a proposal 
for consideration by the working group.



To see the list of current milestones review this link:



https://datatracker.ietf.org/group/regext/about/



To see the list of current documents review this link:



https://datatracker.ietf.org/group/regext/documents/



The Chairs have contacted the authors of all documents and asked for their 
feedback regarding the status of their document, reviewed the current proposed 
milestone dates, and propose the following.  These are shown as they are listed 
in the current milestones.







draft-ietf-regext-launchphase

   WGLC finished. Waiting for shepherd write-up adjustments before submitting 
to IESG.

   Action: Change milestone date to June 2017.



draft-ietf-regext-tmch-func-spec

   Status changed to Informational. Changed to Parked document.

   Action: Delete from milestone list.



draft-ietf-regext-epp-rdap-status-mapping

   RFC 8056

   Action: Set Status Resolved on milestone list.



draft-ietf-regext-epp-fees

   Recent version submitted. Active discussion.

   Action: Change milestone date to July 2017.



draft-ietf-regext-reseller

draft-ietf-regext-reseller-ext

   These drafts have been replaced by draft-ietf-regext-org and 
draft-ietf-regext-org-ext.

   Active discussion.

   Action: Accept new documents, replace on milestones, Change milestone date 
to Nov 2017.



draft-gould-eppext-verificationcode

   No reaction from authors.

   Action: Replace to draft-ietf-regext-verificationcode on milestone list

   Change milestone date to June 2018.



draft-xie-eppext-nv-mapping

   (current milestone listing but document is really

draft-ietf-regext-nv-mappgin)

   Informational document, waiting for

draft-ietf-regext-verificationcode

   Action: Change to parked document. Delete from milestone list.



draft-gould-change-poll (change to draft-ietf-regext-change-poll)

   Needs more reviewers and implementation.

   Action: Change milestone date to Nov 2017.



draft-gould-allocation-token (change to

draft-ietf-regext-allocation-token)

   Needs implementation status section and review.

   Action: Change milestone date to Nov 2017.



draft-ietf-regext-bundling-registration

   New version submitted for STRICT bundling.

draft-ietf-eppext-idnmap

draft-gould-idn-table

draft-cira-regext-idn

   These documents have discussion but no consensus. All these documents relate.

   Some want all IDN to be included in bundling discussion.

   Action: Discuss.  Chairs do not have a proposal for a milestone date of 
these documents.  We need input from the working group.



draft-ietf-regext-dnsoperator-to-rrr-protocol

   Wants to move to WGLC, but had little review on mailing list.

   Action: Change milestone date to Jan 2018.







Other WG documents not on milestone list:



draft-ietf-regext-validate

   Adopted. To be pursued after draft-ietf-regext-epp-fees.

   Action: Add to milestone list with date May 2018.



draft-hollenbeck-regext-rdap-object-tag

   Scott requested WG adoption.

   Action: Formal WG adoption request on mailing list before adding to 
milestones and after revising existing milestone list.





Specific questions to the working group:



1. Do you agree with the proposed dates for milestones?  If not, please

suggest other dates and indicate why you believe your date should be

preferred.  If you agree, please show your support on the list.



2. Do you agree with the documents selected to be parked or dropped?  If

not, please suggest a milestone date and indicate why you believe the

working group should keep this document on its milestone list.  If you

agree, please show your support on the list.



3. Please suggest how you believe the working group should handle the

bundling and IDN drafts?  Should they be kept together?  Should they be

separated?  Why or why not?  Please also suggest a milestone date if you

believe we should keep one or more of these documents active.





Antoin and Jim

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

[Roger D Carney]

Good Afternoon,



Here is the update draft document. This should include all of the agreed upon 
changes from the Chicago meeting (biggest change was the simplification of the 
 call).



One topic that was discussed in Chicago (and not resolved) was on the concept 
of "premium names" and what is returned from the server if no fee extension was 
passed into the . Many thought to be more "backwards compatible"/"user 
friendly", especially for those registrars that do not and may not be 
participating in the allocation of "premium names", that the server should 
respond as unavailable. Others expressed that if it is available then the 
server should respond available. Please share your thoughts on the list on this 
topic and if this draft should even try to account for this concept.



Please let me know if you have any questions.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, April 25, 2017 4:31 PM
To: i-d-annou...@ietf.org
Cc: regext@ietf.org
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Registration Protocols Extensions of the IETF.



Title   : Registry Fee Extension for the Extensible 
Provisioning Protocol (EPP)

Authors : Roger Carney

  Gavin Brown

  Jothan Frakes

Filename: draft-ietf-regext-epp-fees-03.txt

Pages   : 33

Date: 2017-04-25



Abstract:

   This document describes an Extensible Provisioning Protocol (EPP)

   extension mapping for registry fees.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-regext-epp-fees-03

https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-03



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-03





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



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



___

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] draft-ietf-regext-epp-fees

[Roger D Carney]

Good Morning,



Thanks for the note Thomas. We are working on the final edits this week and 
hope to have a draft posted within the week.





Thanks

Roger





-Original Message-
From: Thomas Corte [mailto:thomas.co...@knipp.de]
Sent: Tuesday, April 18, 2017 3:25 AM
To: Roger D Carney <rcar...@godaddy.com>; regext@ietf.org
Cc: supp...@tango-rs.com
Subject: Re: [regext] draft-ietf-regext-epp-fees



Hello Roger,



On 2017-03-29 16:05, Roger D Carney wrote:



> Good Morning,

>

> We had a very productive meeting at our IETF-98 Monday session.

> ...

>

> I have started work on v3 (0.17) of the draft with these changes in mind.



I'm wondering about the status of this new draft version.

Is there an ETA for it?



Some of our registrars are waiting for an updated version of the fee extension 
since they found the  functionality of "urn:ietf:params:xml:ns:fee-0.11" 
unusable.

However, introducing support for "urn:ietf:params:xml:ns:fee-0.15" seems 
pointless if a new version (with further changes to the  command) is 
around the corner.



Best regards,



Thomas



--

TANGO REGISTRY SERVICES(r) is a product of:

Knipp Medien und Kommunikation GmbH

Technologiepark Phone: +49 231 9703-222

Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200

D-44227 Dortmund   E-Mail: 
supp...@tango-rs.com<mailto:supp...@tango-rs.com>

Germany


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

[regext] draft-ietf-regext-epp-fees

[Roger D Carney]

Good Morning,

We had a very productive meeting at our IETF-98 Monday session.

A few of the items that we resolved Monday include:

* Simplifying the  request by removing the  from the 
extension. This is more in line with Option C from last year's discussions. It 
does eliminate some flexibility that v0.15 provided. But generally everyone 
agreed that the flexibility was not worth the expense and that it in practice 
many preferred the simple approach.

* Agreement on failing a create when the passed in fee is not equal to 
or greater than what the server expects. Language will be added.

* Agreement that balance information in the  response is not 
desirable.

One topic that was not resolved was around the  response when the 
domain(s) are premium (a label that will require fee data on the  
command to succeed) and no fee extension data is passed by the client. There 
were two main thoughts on this:

* If a premium domain is available then it should return available if 
no fee extension data is provided in the request.

* Returning unavailable was discussed for a couple reasons. First if no 
fee data is passed in the  and you return available and then the client 
tries to do the  with no fee data (assuming since they did not provide 
in the  they will likely not provide in the ), the  
would fail. Along with this it was discussed that there are and will be many 
registrars that do/will not participate in premium sales (not using the fee 
extension). The thought is that returning unavailable will provided a much 
better backwards compatibility experience.

Please share your thoughts on the premium  response when no fee 
extension data is provided by the client.

Another topic discussed at Monday's session and being discussed on list 
revolves around the optional fee avail flag and its scope within the  
response. Currently (v0.15) the optional fee avail flag is at the  
level. Several have suggested moving this up one level to the  level 
mostly in order to provide a more efficient way to fail fast. Others like the 
current (v0.15) solution as it provides more details around the issues causing 
the false response. I wonder if we provide this optional flag at both levels?

I have started work on v3 (0.17) of the draft with these changes in mind.

Also, please let me know if I missed anything from Monday's discussions.


Thanks
Roger

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

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-01.txt

[Roger D Carney]

Good Afternoon,



Thanks for the review and comments James!!!



I think your discussion of Option C is a great starting point for the list. I 
believe, this current version 01 allows for more flexibility/refinement (being 
able to request different fees for different domains) then what you describe. 
Obviously there is more cost with this flexibility, more defining, validating, 
etc. I am open to either solution and would like to see what the others think 
about the “flexibility” need and use of the current draft 01 versus what you 
are proposing.



And likewise on your discussion of the location of the “avail” attribute, I 
think the current version 01 allows for more flexibility/refinement. Again, I 
am open to either solution and would like to hear what others think.



As for your number items:

1.  Fixed in version 02 (coming soon)

2.  I think this is left open and could potentially be extended.

3.  a) I will work to include descriptions in version 03. I don’t think we 
want to state the default period as 1 year, I think that should be left to 
server policy; b) I agree that this should be directed by server policy and 
will update wording in version 03; c) As mentioned above “avail” at the command 
level provides more flexibility/refinement; d) “avail” defaults to 1.

4.  I agree and will look for missing definitions, please pass along any 
that you see are missing.

5.  I think the create should fail if the passed in fee does not match the 
server fee.

6.  I think it should return available if it is available.

7.  Good question. I like the idea of some predefined with extensibility.



Again, I think this version was built for flexibility but I think we need to 
consider the complexity and use and balance correctly, please share your 
thoughts.





Thanks

Roger



-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Monday, March 06, 2017 2:26 PM
To: regext@ietf.org
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-01.txt



In review of draft-ietf-regext-epp-fees-01, I have the following feedback.



From a high-level, I believe that draft-ietf-regext-epp-fees-01 does not match 
the target of Option C presented by Gavin Brown at IETF-97 
(https://www.ietf.org/proceedings/95/slides/slides-95-regext-9.pdf ), which 
consists of an extension to the domain names in the body of the  command 
with a list of commands in the extension.  All the domains in the body would 
get the fee information for the same set of commands included in the fee 
extension.  I believe that the response “avail” attribute needs to be included 
in the cd element and not in the command sub-element, so that it’s an all of 
nothing result per domain name.  This way invalid or reserved domain names 
would return “avail=0” in the cd element without inclusion of a command 
sub-elements.   I included full command and response examples for the Option B 
and Option C discussed at IETF 97 in the mail posting 
https://www.ietf.org/mail-archive/web/eppext/current/msg00883.html.





1. Section 1.1 since refer to “0.13” instead of “0.1”

2. Section 3.1 “Client Commands”

a. Can you extend the supported commands?   For example, can we add the command 
“sync” for the consolidate command?  There is no enumerated list in the XSD, 
but the text in 3.1 states “The list of values include:”.  Does this allow only 
using these command strings or can we define new ones?

3. Section 5.1.1 “EPP  Command”

a. Add a description for the  and  elements that 
includes their meaning in relationship to the extension to the check command.

i. I assume that not specifying the period matches the period that is defined 
for the object mapping.  In the case of a domain name, the default period would 
be 1 year for the create, renew, and transfer commands.  The restore would not 
support a period, since it is a fixed fee, so there are commands where the 
period would not be allowed.

b. The number of supported  elements would be up to server policy, 
since I don’t believe we would support specifying every billable command and 
every possible period within a single extension to a check command.  That sort 
of bulk query is best suited for an extension to the info command as in a fee 
info command, which was removed in one of the prior versions of the draft.

c. Why are you putting the “avail” attribute at the  level instead 
of the  level?  What if the domain name is invalid or there is some 
other input issue like the currency is invalid?  The server would want to fast 
fail on the entire object and not at the command level.  If the “avail” flag is 
at the command level, then it is best suited to look to extend info instead of 
the check command, since this is getting much to heavy weight for a check 
command and response.

d. The response sample does not include an “avail” attribute for each of the 
 elements.

4. I believe we should define the fields of the 

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-01.txt

[Roger D Carney]

Good Afternoon,

Thanks for catching these issues Thomas, these will be corrected in the next 
version. We have found that there were a few scheme issues, looks like an older 
scheme got published with this update.

We are running through all the examples and scheme and will take a look at any 
notes anyone has (thanks for sending notes Jim) and we will plan to publish an 
update Tuesday or Wednesday this week.

Please keep the comments coming and we will get this draft over the hump and on 
the final stretch soon.


Thanks
Roger


-Original Message-
From: TANGO Support [mailto:supp...@tango-rs.com] 
Sent: Monday, March 06, 2017 6:11 AM
To: regext@ietf.org
Cc: gavin.br...@centralnic.com; Roger D Carney <rcar...@godaddy.com>
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-01.txt

Hello,

On 03/03/2017 23:13, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Registration Protocols Extensions of the 
> IETF.
> 
> Title   : Registry Fee Extension for the Extensible 
> Provisioning Protocol (EPP)
> Authors : Roger Carney
>   Gavin Brown
>   Jothan Frakes
>   Filename: draft-ietf-regext-epp-fees-01.txt
>   Pages   : 34
>   Date: 2017-03-03
> ...

It seems that there is an issue with the XML schema included in this new 
version. This type definition is defective:

  

  
  
  
  
  
  


  


  


  

XML validator says:

cvc-complex-type.2.4.a: Invalid content was found starting with element 
'simpleContent'. One of '{"http://www.w3.org/2001/XMLSchema":attribute,
"http://www.w3.org/2001/XMLSchema":attributeGroup,
"http://www.w3.org/2001/XMLSchema":anyAttribute}' is expected. [132] Open quote 
is expected for attribute "type" associated with an  element type  "attribute". 
[133]

Looks like a fix is needed here.

Best regards,

Thomas

--
TANGO REGISTRY SERVICES(r) is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

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

Re: [regext] Working Session @ IETF 98

[Roger D Carney]

Good Morning,



I am a bit confused on the reseller drafts. I thought in Seoul we decided to 
review and comment but to not dedicate WG effort to these drafts?





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Friday, March 03, 2017 7:36 AM
To: Antoin Verschuren ; regext 
Subject: Re: [regext] Working Session @ IETF 98



Antoin,



I’m willing to help facilitate or participate in the reseller drafts 
(draft-ietf-regext-reseller and draft-ietf-regext-reseller-ext) sub-group; 
although the draft-ietf-regext-epp-fees sub-group is a high priority for me.  
You may be able to split it based on EPP based sub-groups and RDAP based 
sub-groups.



For the draft-ietf-regext-epp-fees sub-group, I particularly would like to 
discuss the policies around the handling of premium domain names.  The specific 
policies that I would like to discuss include:



1. Should a create fail if the client does not pass a fee that is greater than 
or equal to the premium domain name fee?

2. Should a premium domain name be returned as unavailable in the check if the 
fee extension is not passed, since the create would most likely fail later in 
the purchase flow?

3. Should we have text in the draft with guidance around these and other 
policies?



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



VerisignInc.com 



On 3/3/17, 5:23 AM, "regext on behalf of Antoin Verschuren" 
>
 wrote:



Dear WG,



Important questions below.

As you may have seen, we have requested 2 meeting slots in Chicago.

The first slot will be an experimental working session.

It will be similar to this experiment: 
https://trac.ietf.org/trac/iesg/wiki/MeetingExperiments



For this experiment to succeed, it will be vital that the participants have 
prepared.

It will not be a session to sit in the back of the room reading email.

This means:



-You must have read and have an opinion or questions about at least one of 
the documents discussed here.

-Prepare your questions or text and choose a subgroup from the listing 
below beforehand.



The setup of this session will be as followed:

-We will have a short introduction with a sum-up of the sub-groups and 
documents that will be discussed.

-We may split up the group in sub-groups, and ask participants to close 
laptops and join a sub-group of their choice.

-We have asked for a room setup where each sub-group will have at least a 
table to sit around.

-We ask each sub-group to appoint a "facilitator” that will lead the 
discussion and summarize the results of the discussion afterwards.

-If there are remote participants for your sub-group, we may ask on-site 
participants to assist in Skype or similar conferencing tools.

-We expect a small presentation by the facilitator with the results of the 
sub-group discusion in the regular session later in the week.

-You will have an opportunity in the regular session to ask questions to 
the whole working group if necessary.



So far we have the following documents for this session:



Facilitator:   Document:

Scott draft-hollenbeck-regext-rdap-openid

Scott draft-hollenbeck-regext-rdap-object-tag

Scott draft-fregly-regext-rdap-search-regex

Rogerdraft-ietf-regext-epp-fees-01



We are considering, but didn’t get confirmation from one of these authors 
yet:



Facilitator:   Document:

Jacques? 
draft-ietf-regext-dnsoperator-to-rrr-protocol-02

Linlin/James? draft-ietf-regext-reseller-ext-01



Please let us know if you want to work on these documents during the 
working session.

Perhaps people other than the authors may have an interest to discuss.



Not all documents will have the same interest or expertise.

Questions we have for the WG now:



-Do you think we should treat the documents in parallel or serial ?



We want to give enough time to each document to discuss and do actual work 
like writing text.

Since Scott is leading 3 document discussions, it will be hard to treat 
them in parallel, but how about the others?



-If you are a remote participant and want to join one of the discussions, 
please identify yourself on the mailinglist so on-site participants that will 
join the same sub-discussion can offer to assist in remote participation when 
we decide to treat them in parallel. It will also allow for the facilitator to 
get a sense of interest and prepare discussions.







The preliminary agenda and call for agenda items 

Re: [regext] Meeting in Chicago

[Roger D Carney]

Good Morning,



I agree with Scott, I would like to see two one hour sessions.



In the working session, I would like to propose working on 
draft-ietf-regext-epp-fees-01 (this draft will be published later this week). 
This has been updated to reflect most of the discussions from the past year and 
should be really close to being complete.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, February 07, 2017 6:26 AM
To: i...@antoin.nl; regext@ietf.org
Subject: Re: [regext] Meeting in Chicago



> -Original Message-

> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin

> Verschuren

> Sent: Tuesday, February 07, 2017 3:41 AM

> To: regext >

> Subject: [EXTERNAL] [regext] Meeting in Chicago

>

> Dear working group,

>

> It's time again to start scheduling for our next meeting.

> The chairs need to make a meeting request before this friday.

> We intend to meet in Chicago, but following up on our discussion in

> Seoul, we have an important question for you:

>

> Do you want one traditional meeting slot only discussing progress, or

> do you want two 1 hour slots with one slot reserved as a working

> session on doing actual work on documents?

>

> Please let us know before friday.



There hasn't been much progress on anything (or extensive discussion without 
resolution that has impeded progress), so I think I'd prefer the "two 1 hour 
slots with one slot reserved as a working session" option. If we go that route 
I would like to ask for some time to talk about the three drafts I'm working on 
that are currently individual submissions:





draft-hollenbeck-regext-rdap-openid

draft-hollenbeck-regext-rdap-object-tag

draft-fregly-regext-rdap-search-regex



Scott



___

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] Agenda items for IETF97

[Roger D Carney]

Good Morning,



Thanks for the draft agenda Antoin!



For agenda items I would like to request a couple minutes (probably no more 
than 10, 5 to introduce 5 for questions) to re-introduce the 
draft-carney-regext-validate internet-draft, this has been reworked after 
registry input. We would like to request this draft be added to the milestones 
for the WG.



I like the idea of live document editing for the unstructured meeting time, we 
could spend a minute and select the document of choice and edit away, most 
likely author lead with any changes and reasoning posted to mailing list after.



As far as the regext-tmch-func-spec last call, I still have not seen a solution 
for two items that have been mentioned several times previously.

1.  One is about the stated requirements of 48 hours in section 5.3.2. 
Gustavo did add language about policy but as we cannot find any documented 
reason for this 48 hours we believe that it should be removed. This requirement 
is a major headache for registering domains especially when it comes to 
pre-orders.

2.  And the other is about the TCNs being rotated every twelve hours. 
Ideally a TCN would be valid indefinitely and only change if claims on a label 
have changed, I am not sure why the TMCH is updating these every 12 hours 
(twice daily) maybe there are good reasons and I just don't know the reasons. 
Additionally the old TCN should remain valid for a certain amount of time after 
being updated (e.g. 7 days) so that a customer that has seen and accepted a 
claim can process their registration over a reasonable amount of time (many 
domains are registered after sitting in a shopping cart for days). I think this 
could remove some of the registry checks as well. Current setup makes 
pre-orders very inefficient (possibly requiring multiple registrant acceptances 
of the same claim information) and results in frustrated customers and 
dramatically lower go-live GA registration numbers.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Friday, October 21, 2016 6:19 AM
To: regext 
Subject: [regext] Agenda items for IETF97



Hi all,



It's time to start preparing for Seoul.

This is a call for agenda items.

We requested a 1,5 hour slot, but so far we received a 2 hour slot on Friday, 
so we have enough time left.

I posted a preliminary agenda below.

Authors that see their documents on the agenda and want to present updates or 
discussions, please do! and let us know.




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

Re: [regext] draft-ietf-eppext-keyrelay

[Roger D Carney]

Good Afternoon,



Interesting question Jim.



It seems like it would be a benefit to most of the stakeholders to have a 
licensing statement included prior to moving forward. Why would we not include 
the statement? I was unable to attend the last meeting, though I did review the 
minutes and it looks like there was some discussion on this, so maybe this has 
already been answered.





Thanks

Roger





-Original Message-
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
Sent: Monday, August 08, 2016 9:56 AM
To: Rik Ribbers 
Cc: Alexey Melnikov ; Ulrich Wisser 
; Registration Protocols Extensions 
Subject: Re: [regext] draft-ietf-eppext-keyrelay



Rik,



Speaking as working group co-chair (note that the other co-chair is conflicted 
as he is a co-author), the working group has agreed to submit this document for 
publication but the working group has not considered the issue of the IPR.



To say this differently, the working group has agreed with the content of the 
document but it has not fully considered the IPR that may or may not apply to 
the resulting standard.



Typically, the IETF does not approve standards with an IPR claim unless two 
things are true.  First, the working group must have significant consensus that 
it has considered the IPR and believes that the document represents the best 
solution regardless.  Second, there is an expectation that there will be some 
indication of the licensing that may or may not be required based on the IPR.



While it is true that no licensing statement is required, the working group 
must consider this fact as part of its discussion and then decide what its 
consensus will be based on that.



Since the working group has not yet considered the question of whether or not 
it wants to advance this document without an IPR licensing statement, let me 
ask two questions at this time.



1. To the document authors - do you want to ask the working group if it would 
be willing to advance this document without a licensing statement from Verisign?



2. To the working group - is there anyone who objects to moving this document 
forward without an IPR licensing statement?



While normally rough consensus is sufficient to resolve a question, in this 
case I want to state in advance that I will require significant consensus, 
which means limited objection, in order to declare that the working group 
believes that this document should move forward.  I believe that the IETF in 
general will expect this of this working group.



I would appreciate if working group members would respond to the second 
question on the list.



Thanks!



Jim

(speaking as co-Chair of REGEXT)













On 28 Jul 2016, at 8:29, Rik Ribbers wrote:



> All,

>

> Thx Ulrich for bringing this to the mailing list. I have sent a

> lengthy email to WG-chairs and ADs on this issue but this mail sums it

> up quite easily. This is my understanding:

>

> I have re-read BCP-79 on the train home from IETF and I have to agree

> with Scott that the IPR-disclosure on the keyrelay draft is conform

> BCP-79, as licence details are not mandatory.

>

> On 28 Jul 2016, at 13:46, Ulrich Wisser

> >>
>  wrote:

>

>  I believe if we indicate that the WG is content with the information

> provided by Verisign, the IESG will forward the document

>

>

> As far as I see it the IPR-disclosure is conform BCP-79 and should not

> be blocking publication. The WG has not discussed the IPR-disclosure

> at all in public, so implementers will have to consider this IPR

> disclosure themselves before implementing this (My company had legal

> advice in this specific case).  Of coarse I agree that an updated

> IPR-disclosure with licensing details makes it easier for implementers

> to make an informed decision but it is not necessary. So I am content

> with the information provided by Verisign.

>

> I would love to hear from others, especially the WG-chairs an ADs what

> they think on this matter.

>

> Gr,

> Rik

>

>

>

>

>

> ___

> 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