Re: [regext] REGEXT Interim Meeting Invite

[Patrick Mevzek]

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

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

-- 
  Patrick Mevzek

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

Re: [regext] EPP and DNAME records?

[Patrick Mevzek]

On Mon, Jan 8, 2018, at 14:51, Stephane Bortzmeyer wrote:
> > * I have mixed feelings about section 10.
> 
> It is copy-and-paste for RFC 5910, which is on the standards track.

You are not the first one giving me that explanation when I do a review.

I think however this is a weak argument. Even perfect RFCs have errata
and are then later on obsoleted by other RFCs. So nothing is set in stone,
and if there was an error before or anyhing that is just copied from one RFC
to another this does not make it true and not questionable again.

This is why I was asking you, as author, if you are behind the sentence
you wrote, and if so if you can explain why it is mandatory.

Because I do not understand it.

-- 
  Patrick Mevzek

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

Re: [regext] REGEXT Interim Meeting Invite

[Hollenbeck, Scott]

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



Scott



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



Good Morning,



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



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

1. Fee

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

 b. Discuss WG Last Call

2. Registry Mappings

 a. Introduce the Registry Mapping concepts



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





Thanks

Roger





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



I will attend too.

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

Are there any more people that will attend?



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

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



Roger, did you get any feedback on attendance?



Regards,



- --
Antoin Verschuren

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









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





   I will attend.

   Jim



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

  Good Morning,



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



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



  Agenda

  1.Fee

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

  2.Registry Mappings

 a. Introduce the Registry Mapping concepts



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



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





  Thanks

  Roger



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

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



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

Re: [regext] I-D Action: draft-ietf-regext-change-poll-06.txt

[Gould, James]

Pieter,

I believe the confusion is that a poll message is in the form of an EPP 
response that is triggered by a poll command.  An example is the use of the 
domain transfer query response for domain transfer poll message, where it is 
technically a domain transfer query response with message queue information in 
the msgQ element that is returned in the response to a poll command.  All poll 
messages are EPP responses with additional poll queue data.  The purpose of 
draft-ietf-regext-change-poll is to enable servers to tell clients of changes 
made to their objects that the client is not directly involved with or 
knowledgeable of.  The messaging mechanism is via the EPP poll queue, which as 
noted is in the form of an EPP response.  The EPP response chosen for use by 
the draft-ietf-regext-change-poll extension is the object-specific info 
response (domain info response, host info response, contact info response, 
etc.) with the extra meta-data about the change in the extension.  In this 
case, it’s an info response that is triggered by a poll command and not an info 
command.  It’s important in draft-ietf-regext-change-poll to define it as a 
command / response extension of the info response, but to define that the info 
response extension is associated with an EPP poll response.

The extension is related to transform operations made by the server or made by 
a channel other than EPP (e.g., web UI, bulk update), but is not related to EPP 
transform commands made by the client directly.

—

JG

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

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

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

Verisign.com

From: regext  on behalf of Pieter Vandepitte 

Date: Monday, January 8, 2018 at 10:59 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-change-poll-06.txt

After some iterations of reading your reply and the draft I think I start to 
get it :-)

The extension is to be used only in a response of an EPP info command.

The whole poll thing confused me, because, how I interpret RFC 5730, an EPP 
poll response is the response to the epp:poll command (with the "op" attribute 
either "req" or "ack"), but here, poll response has a different meaning. It 
means any response having a msgQ element. To me, a response having a msgQ 
element is not a poll response, but just a response (check response, info 
response, poll response, create response, delete response, ...) containing a 
"hint" there are poll messages available.

This makes me thinking: wouldn't it be useful to allow the use of the extension 
in case of a transform response (like domain update) or a poll response (like 
poll ack, which I initially had in mind when reading the draft for the first 
time)? I think it is :-)

Best regards

Pieter


On 08 Jan 2018, at 14:28, Gould, James 
> wrote:

Pieter,

Thank you for your review and feedback.

The extension is a command / response EPP extension of any object (e.g., 
domain, host, contact) that the server needs to inform the client of changes 
via a poll message that is an extension of the object’s info response.  A poll 
response is a standard EPP response with the msgQ element populated.  The key 
choice for a poll message is which concrete EPP response to use.  In the case 
of draft-ietf-regext-change-poll, the extension of an object-specific info 
response is used.  The change poll message could have leveraged an object 
extension (e.g,. change record), but that would have required finding some 
mechanism to replicate the state attributes of an extensible set of objects 
(e.g., domain, host, contact).  The title of section 3.1.2 as EPP  
Command is in line with other command / response EPP extensions.  I believe the 
example reference to “poll  response” is accurate, since a poll command 
does result in a poll response which in this case is an extended 
object-specific info response.  Does referring to it as “poll message  
response” make it a little bit clearer in the examples?

Thanks,

—

JG



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

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

Verisign.com

From: regext > on 
behalf of Pieter Vandepitte 
>
Date: Monday, January 8, 2018 at 3:11 AM
To: "regext@ietf.org" 
>
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-change-poll-06.txt

Just a small note... Shouldn't section 3.1.2 be renamed to EPP  Command? 
I think the purpose of the extension is to extend poll messages, no?

Moreover, the draft talks about


Example poll  response

I think that's an error. Poll info does not exist. 

Re: [regext] I-D Action: draft-ietf-regext-change-poll-06.txt

[Pieter Vandepitte]

After some iterations of reading your reply and the draft I think I start to 
get it :-)

The extension is to be used only in a response of an EPP info command.

The whole poll thing confused me, because, how I interpret RFC 5730, an EPP 
poll response is the response to the epp:poll command (with the "op" attribute 
either "req" or "ack"), but here, poll response has a different meaning. It 
means any response having a msgQ element. To me, a response having a msgQ 
element is not a poll response, but just a response (check response, info 
response, poll response, create response, delete response, ...) containing a 
"hint" there are poll messages available.

This makes me thinking: wouldn't it be useful to allow the use of the extension 
in case of a transform response (like domain update) or a poll response (like 
poll ack, which I initially had in mind when reading the draft for the first 
time)? I think it is :-)

Best regards

Pieter


On 08 Jan 2018, at 14:28, Gould, James 
> wrote:

Pieter,

Thank you for your review and feedback.

The extension is a command / response EPP extension of any object (e.g., 
domain, host, contact) that the server needs to inform the client of changes 
via a poll message that is an extension of the object’s info response.  A poll 
response is a standard EPP response with the msgQ element populated.  The key 
choice for a poll message is which concrete EPP response to use.  In the case 
of draft-ietf-regext-change-poll, the extension of an object-specific info 
response is used.  The change poll message could have leveraged an object 
extension (e.g,. change record), but that would have required finding some 
mechanism to replicate the state attributes of an extensible set of objects 
(e.g., domain, host, contact).  The title of section 3.1.2 as EPP  
Command is in line with other command / response EPP extensions.  I believe the 
example reference to “poll  response” is accurate, since a poll command 
does result in a poll response which in this case is an extended 
object-specific info response.  Does referring to it as “poll message  
response” make it a little bit clearer in the examples?

Thanks,

—

JG



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

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

Verisign.com

From: regext > on 
behalf of Pieter Vandepitte 
>
Date: Monday, January 8, 2018 at 3:11 AM
To: "regext@ietf.org" 
>
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-change-poll-06.txt

Just a small note... Shouldn't section 3.1.2 be renamed to EPP  Command? 
I think the purpose of the extension is to extend poll messages, no?

Moreover, the draft talks about


Example poll  response


I think that's an error. Poll info does not exist. It should be poll req


Pieter

On 05 Jan 2018, at 14:08, 
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 WG of the 
IETF.

   Title   : Change Poll Extension for the Extensible Provisioning 
Protocol (EPP)
   Authors : James Gould
 Kal Feher
Filename: draft-ietf-regext-change-poll-06.txt
Pages   : 25
Date: 2018-01-05

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension for notifying clients of operations on client sponsored
  objects that were not initiated by the client through EPP.  These
  operations MAY include contractual or policy requirements including
  but not limited to regular batch processes, customer support actions,
  Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
  Suspension (URS) actions, court directed actions, and bulk updates
  based on customer requests.  Since the client is not directly
  involved or knowledgable of these operations, the extension is used
  along with an EPP object mapping to provide the resulting state of
  the post-operation object, and optionally a pre-operation object,
  with the operation meta-data of what, when, who, and why.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-change-poll-06
https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-06


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

Re: [regext] REGEXT Interim Meeting Invite

[Gould, James]

Andy,

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



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

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

Verisign.com  

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

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

-andy

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

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


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

Re: [regext] REGEXT Interim Meeting Invite

[Andrew Newton]

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

-andy

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

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

Re: [regext] REGEXT Interim Meeting Invite

[Gould, James]

I plan on attending.


—

JG

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

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

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

Verisign.com

From: regext  on behalf of Jody Kolker 

Date: Monday, January 8, 2018 at 10:44 AM
To: Antoin Verschuren , Roger Carney 
Cc: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] REGEXT Interim Meeting Invite

I will also be there.

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

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

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

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

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

Roger, did you get any feedback on attendance?

Regards,

- --
Antoin Verschuren

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




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




I will attend.

Jim


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

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

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

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

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

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


Thanks
Roger


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

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

Re: [regext] REGEXT Interim Meeting Invite

[Jody Kolker]

I will also be there.

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

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

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

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

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

Roger, did you get any feedback on attendance?

Regards,

- --
Antoin Verschuren

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




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



I will attend.

Jim


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

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

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

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

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

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


Thanks
Roger


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

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

[regext] Registration Protocols Extensions (regext) WG Virtual Meeting: 2018-01-10

[IESG Secretary]

The Registration Protocols Extensions (regext) Working Group will hold
a virtual interim meeting on 2018-01-10 from 19:00 to 20:00 UTC.

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


Information about remote participation:
https://godaddy.zoom.us/j/446675624

Apologies for the late scheduling, but the invite was discussed already on the 
REGEXT mailing list 4 weeks ago.

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

Re: [regext] REGEXT Interim Meeting Invite

[Antoin Verschuren]

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

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

Roger, did you get any feedback on attendance?

Regards,

- --
Antoin Verschuren

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






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

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



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

Re: [regext] org extensions for transfer requirement

[Gould, James]

Patrick,

My responses to your feedback are embedded below.
  
—
 
JG



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

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

Verisign.com  

On 1/7/18, 8:35 PM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Tue, Jan 2, 2018, at 15:11, Gould, James wrote:
> I believe the only fields missing include the 
> reference to the RDDS services (WHOIS, RDAP).  To keep the organization 
> generic, this could be defined as a list of servers that may be set for 
> an organization.

This list of servers will have absolutely no meaning for organizations not 
being registrars.
So the extension cease to be generic.

I don’t believe registrars are the only organizations that may have a list of 
typed servers used for services.  I would classify RDDS as a form of a service 
provided by a registrar.  These servers are not limited to RDDS.  Defining the 
RDDS servers is a concrete use case for a registrar organization that can be 
met by defining a generic mechanism that can apply to all organizations.  

> I’m not asking or proposing a requirement to implement the org 
> extensions, 

(I fear however that this could be a future outcome, if the use of the
extension becomes mandatory to conduct transfers).
 
I wouldn’t hinder the technical discussions based on a hypothetical future 
policy decision.  
   
> but asking whether with the org extensions over the secure 
> EPP protocol would be a better option than registrars getting 
> information from the registries via an insecure channel that may become 
> further restricted. 

I am not saying the contrary, but:
- I think that the feature can be done otherwise/by other extensions
- I do not want this extension to be suddenly perceived as absolutely 
mandatory
because it is tied to the proper handling of transfers between registrars.

I note that there was never a suggestion in the past if my memory works to 
introduce an 
extension to store registrars, so maybe the need to do that to better 
handle transfers
was not obvious.

There was for resellers, and then later it transformed
into a generic organization handling.

I’m not sure why you’re opposed to considering the use of the org extensions 
for the registries to provide registrar information that they already have over 
a secure channel in the support of transfers.  We started with reseller that 
was pushed by the working group to be more generic to cover organizations like 
registrars, and now there is a concern about making it a requirement to solve a 
problem around transfers.

> If the registries do have the registrar 
> information, then why can’t the registries provide the information over 
> EPP to the registrars to support transfers?  

They sure can. And maybe should. But we lived many years without that 
anyway.

Yes, that is true, but access to RDDS may be changing, other extensions to 
provide Whois information (e.g., Verisign’s Whois Info Extension) have been 
created for transfers, and we can provide a more standard, secure, and 
extensible model to support transfers other than requiring registrars to access 
a separate non-secure registry channel with Whois.   

> Why would you propose to create many small, targeted extensions to cover 
> specific use cases instead of leveraging a more generic extension that 
> is itself extensible (e.g., roles and servers) to support many use 
> cases.

I'm inclined to the Unix philosophy of having many small tools that
you can compose to produce what you need instead of a monolithic one
trying to cover all cases and finally not being good in any case.
I am not proposing to create other extensions because, as you already
stated there is already one extension existing covering exactly the use
case you are speaking about. As I said previously I would far more favor
works towards making the existing extension a true standard used by multiple
registries.

Does Verisign plan to stop using its own extension and using instead
the generic organization one we are talking about here if it includes
the changes related to registrars whois/rdap servers?

I don’t consider the organization extensions as monolithic in any way, but 
simply consolidating a potentially large set of small non-standard extensions 
into two extensions (org object extension and org command response extension) 
that provides an extensible framework.   My hope is that we can come to 
agreement on a set of useful EPP extensions that can be standardized as opposed 
to encouraging a soup of proprietary extensions.  The transition of proprietary 
extensions to standard extensions can be handled on a case-by-case basis. 

> I agree that the registrar information is 

Re: [regext] EPP and DNAME records?

[Stephane Bortzmeyer]

On Sun, Jan 07, 2018 at 08:26:46AM -0500,
 John Levine  wrote 
 a message of 20 lines which said:

> It can coexist with anything other than CNAME, NS/DS, or another
> DNAME, and you need A, , and MX records at the DNAME to do what
> many people wrongly believe that DNAME does.  See RFC 6672, sec 2.4.

You're right, of course. Sorry for the mistake. It may be because I
thought of only one use case (see below).

> Not to be oversnarky, but I'd want a field to upload a picture of
> the user shooting himself in the foot to demonstrate that he
> understands what DNAMEs will do.

Right. Warnings added


> I assume I missed a discussion of what problem this solves -- is it
> in the list archives?

Yes. Added to the future version of the draft but, basically, it is
draft-bortzmeyer-dname-root. Some people remarked that we don't even
have an EPP mapping for DNAME. It is not the biggest obstacle to
draft-bortzmeyer-dname-root but this new draft
draft-bortzmeyer-regext-epp-dname is an attempt to lift it.

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

Re: [regext] I-D Action: draft-ietf-regext-change-poll-06.txt

[Gould, James]

Pieter,

Thank you for your review and feedback.

The extension is a command / response EPP extension of any object (e.g., 
domain, host, contact) that the server needs to inform the client of changes 
via a poll message that is an extension of the object’s info response.  A poll 
response is a standard EPP response with the msgQ element populated.  The key 
choice for a poll message is which concrete EPP response to use.  In the case 
of draft-ietf-regext-change-poll, the extension of an object-specific info 
response is used.  The change poll message could have leveraged an object 
extension (e.g,. change record), but that would have required finding some 
mechanism to replicate the state attributes of an extensible set of objects 
(e.g., domain, host, contact).  The title of section 3.1.2 as EPP  
Command is in line with other command / response EPP extensions.  I believe the 
example reference to “poll  response” is accurate, since a poll command 
does result in a poll response which in this case is an extended 
object-specific info response.  Does referring to it as “poll message  
response” make it a little bit clearer in the examples?

Thanks,

—

JG

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

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

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

Verisign.com

From: regext  on behalf of Pieter Vandepitte 

Date: Monday, January 8, 2018 at 3:11 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-change-poll-06.txt

Just a small note... Shouldn't section 3.1.2 be renamed to EPP  Command? 
I think the purpose of the extension is to extend poll messages, no?

Moreover, the draft talks about


Example poll  response

I think that's an error. Poll info does not exist. It should be poll req


Pieter

On 05 Jan 2018, at 14:08, 
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 WG of the 
IETF.

   Title   : Change Poll Extension for the Extensible Provisioning 
Protocol (EPP)
   Authors : James Gould
 Kal Feher
Filename: draft-ietf-regext-change-poll-06.txt
Pages   : 25
Date: 2018-01-05

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension for notifying clients of operations on client sponsored
  objects that were not initiated by the client through EPP.  These
  operations MAY include contractual or policy requirements including
  but not limited to regular batch processes, customer support actions,
  Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
  Suspension (URS) actions, court directed actions, and bulk updates
  based on customer requests.  Since the client is not directly
  involved or knowledgable of these operations, the extension is used
  along with an EPP object mapping to provide the resulting state of
  the post-operation object, and optionally a pre-operation object,
  with the operation meta-data of what, when, who, and why.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-change-poll-06
https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-06


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] I-D Action: draft-ietf-regext-change-poll-06.txt

[Pieter Vandepitte]

Just a small note... Shouldn't section 3.1.2 be renamed to EPP  Command? 
I think the purpose of the extension is to extend poll messages, no?

Moreover, the draft talks about


Example poll  response

I think that's an error. Poll info does not exist. It should be poll req


Pieter

On 05 Jan 2018, at 14:08, 
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 WG of the 
IETF.

   Title   : Change Poll Extension for the Extensible Provisioning 
Protocol (EPP)
   Authors : James Gould
 Kal Feher
Filename: draft-ietf-regext-change-poll-06.txt
Pages   : 25
Date: 2018-01-05

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension for notifying clients of operations on client sponsored
  objects that were not initiated by the client through EPP.  These
  operations MAY include contractual or policy requirements including
  but not limited to regular batch processes, customer support actions,
  Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
  Suspension (URS) actions, court directed actions, and bulk updates
  based on customer requests.  Since the client is not directly
  involved or knowledgable of these operations, the extension is used
  along with an EPP object mapping to provide the resulting state of
  the post-operation object, and optionally a pre-operation object,
  with the operation meta-data of what, when, who, and why.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-change-poll-06
https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-06


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