Hello James, Le lundi 27 avril 2015 à 13:04 +0000, Gould, James a écrit :

We discussed the Change Poll Extension and the use case of DNS deferred publication at the Registration Operations Workshop (ROW) prior to IETF-92. The question was whether the deferred publication was part of pending operations (e.g. pendingCreate, pendingUpdate). No one could speak to the use case. Can you describe the domain operation flow of a registry that supports deferred publication?

Sorry for my delay. I can give you some details on how it was done at the .FR registry in the past (we are not doing it anymore). Basically any DNS change had to be checked against some rules, using the then active tool zonecheck (which also meant that you could only change nameservers in one operation, you could not mix it with other updates at the same time). In our case, at that time, creation was not possible with nameservers. You had to first register the domain, then modify it if you want to add nameservers.

I see two different flows:

1. Pending Action 1. Client sends domain create with NS (domain update would work in a similar fashion) 2. Server puts the domain on pendingCreate status and returns the 1001 “Command completed successfully; action pending” response 3. Server validates the NS (DNS servers respond correctly ) 4. If NS validate 1. Remove the pendingCreate status 2. Insert pending action (<domain:panData> ) poll message with a positive result ( “paResult=1” ) 5. else if within validation period 1. Validate again at the next interval 6. else 1. Remove domain ( or reject update ) 2. Insert pending action (<domain:panData> ) poll message with negative result ( “paResult=0” ). An extension could be added to provide more error detail.

We were basically doing that except for the following points : - no creation with nameservers, hence the above workflow was for updates only - either it valides or not, but in all cases the operation was done at that time, either successfully or not. the registry did not try to validate again, the onus would be on the registrar to send again a domain:update command to trigger a recheck. - for the more details part (basically the validation result), we did not design an extension but just put the error message as a text in the notification. Clearly not as good as the new drafts to convey such kind of information, but at that time, it was good enough.

1. Registration Deferred Publication ( My thoughts without any detail previously provided ) 1. Client sends domain create with NS ( domain update may work in a similar fashion, but I see some added complexity) 2. Server accepts the domain create for deferred publication and sets the “serverHold” and “ serverUpdateProhibited” statuses pending the validation. 1. A domain update would be more complex, since I imagine that the update would not add any server statuses to support the deferred validation. I also imagine that the domain would not be removed from the zone based on the update deferred validation by putting the “serverHold” on it. Is update of NS validated via a deferred validation model? 3. Server validates the NS (DNS servers respond correctly ) 4. If NS validate 1. Remove the “serverHold” and “serverUpdate” statuses 2. Poll message here is in question. Should this be a Change Poll message reflecting the update made by the server to remove the and “ serverUpdateProhibited” statuses based on the successful deferred publication validation? 1. If so, I see the server operation as “update” and the reason as something like “Deferred publication validation success”. The reason is free-form text. The change poll message (domain info response) should reflect the removal of the “serverHold” and “serverUpdateProhibited” statuses. 5. else if within validation period 1. Validate again at the next interval. No poll message required, since the state of the domain has not changed. 6. else 1. Remove the “serverUpdateProhibited” status to enable the client to modify the NS 2. Poll message here is in question. Should this be a Change Poll message reflecting the update made by the server to remove the “serverUpdateProhibited” status based on the failed deferred publication validation? 1. If so, I see the server operation as “update” and the reason as something like “Deferred publication validation failed”. The reason is free-form text. The change poll message (domain info response) should reflect the removal of the “serverUpdateProhibited” status, and not the “serverHold” status still set. 1. If additional information is required for this failure, I recommend creating a separate deferred publication failure extension or a generic validation failure extension that is attached to the change poll message. The info response would provide the state of the object (domain in this case), the change poll extension would provide the what, when, why for the server-side change, and the validation failure extension would provide the failure detail.

This is more complex, and like I said I have past experience only for updates. Using statuses in that way seems to me a problem since they do not "stack". A domain can have a serverHold for various reasons: if it has serverHold before the domain:update for example because of a dispute or something out of band, at the end of the procedure it may have been removed, but wrongly. Also, it breaks the domain: if you put serverHold right at the beginning of the domain:update and if the zonefile data is published in real time or near real time, and if the validation itself takes more time than the average publication delay, then you create a window were the current domain can be published without its (past) nameservers at all, which is for me a no-go. So I would think the first case is simpler for anyone. Also, we may have the same problem for secDNS changes (if the registry wants to validate them before applying them)

I don’t see the operations done by the server above as being anything other than an “update” with the reason communicating the deferred publication validation result. There are two forms of extensibility of operations defined in the draft that is supported by the <changePoll:operation> “op” attribute, which can be used to define a sub-operation (e.g. <changePoll:operation op=“deferredPublication”>update</changePoll:operation>) or a custom operation (e.g. <changePoll:operation op=“deferredPublication”>custom</changePoll:operation> ), which handles extensibility without the need for a new XML schema and requiring an extension to an extension. Is there any other form of extensibility that you are looking for?

No, my fault sorry, I overlooked this possible extension, which indeed solves my question. -- Patrick Mevzek