[gtld-tech] [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft
Patrick Mevzek
Patrick.Mevzek at afnic.fr
Sun May 31 19:37:29 UTC 2015
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
More information about the gtld-tech
mailing list