Subject: Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll

From: Patrick Mevzek <[email-masked]>
Date: Wed, 03 Jan 2018 02:59:15 +0100

Hello James,

>>     I am not sure to understand the example for the autopurge.
>>     If the registry deletes a domain with an immediate purge I expect the 
>>     domain not to exist anymore. But in your example you show the "after"
>>     state
>>     and there you have a domain:name and a domain:clID still... but the
>>     domain
>>     should not exist anymore.
>>     In my view you should have the before state with all domain:infDatq, and
>>     for the
>>     after state, there should be no domain data anymore.
>>     I agree it creates a problem as you loose the domain name itself
>>     in the message, but I still think there should be no domain
>>     data if it was purged.
>>     What do you think?
> 
> I thought about this one, and yes this is a grey area.  I believe it’s 
> more important to keep the use of the required “after” state here.  The 
> use of the “before” state is optional and I don’t want to add complexity 
> by adding support for it here.  In this case, the operation is 
> identifying to the client that the specified record that is included was 
> purged from the system.           

On a purely semantic level I still find it wrong to have an "after" purge message
reflecting data as if the domain still exists.

This will need to be handled by registrars as a specific case, since they
could, for example, not always update their database based on the "after" messages
because in this specific case if they do it like that they will see the domain
existing, where it was deleted. So that message will have a specific handling just
for it.

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Wed, 3 Jan 2018 13:08:51 +0000

Patrick,

As stated before, I do agree that the purging of the object either via the “delete” operation with the “op” attribute set to “purge” or the “autopurge” operation as a grey area, but the use of the “before” state is an optional feature of the protocol that is not meant to be used for this corner case.  The server may choose to support providing both the before and after state, but is required to provide the after state.  There is no clean mechanism to extend the info response of a purged object, so in the case of a “purge” or an “autopurge”, the last state of the purged object is returned.  If we started mixing in the use of the “before” state with the “after” state, the client would need to interrogate the extension as well to determine whether the object was purged or whether the server is providing the before image of another operation.  Fundamentally, clients can ignore the “before” state if that don’t require it and they should interrogate the change poll extension to determine what actions they should take.  The opposite scenario would for the “create” operation, where there would be no “before” state but there would be an “after” state.  I would recommend taking a similar approach here as well if a server chooses to support the “before” state option if they were to perform some form of create (bulk or individual) on behalf of the client.  So, in general, the change poll extension needs to support the full set of CRUD operations, where the create and the delete (purge) represent a special case when supporting the required “after” state and the optional “before” state poll messages.  Semantically you are correct that there is no “before” state for a create operation and there is no “after” state for a delete (purge) operation, but from a protocol perspective it’s important to separate the requirements for the “after” state behavior and the “before” state behavior.  In this case, “after” is required and “before” is optional, so the extension must support an “after” state mechanism for all possible operations including the delete (purge).  

I can add a subsection in section 2 to describe the expected before for both the create and the delete (purge) to ensure that the servers implement it consistently and the clients know what to expect.  Do you agree?        
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 1/2/18, 8:59 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Hello James,

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

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 04 Jan 2018 01:06:16 +0100

On Wed, Jan 3, 2018, at 14:08, Gould, James wrote:
> I can add a subsection in section 2 to describe the expected before for 
> both the create and the delete (purge) to ensure that the servers 
> implement it consistently and the clients know what to expect.  Do you 
> agree?        

I think we will agree to remain in disagreement on the subject itself,
as you put the protocol over the semantics and I do the opposite.

However putting more text and explanations as you suggest would certainly
help implementers to better understand things, so this will be welcome I am sure.

-- 
  Patrick Mevzek