Re: [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft

["Gould, James" <[e-mail]>]

Patrick,

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?  I see two different flows:


  1.  Pending Action
     *   Client sends domain create with NS (domain update would work in a similar fashion)
     *   Server puts the domain on pendingCreate status and returns the 1001 “Command completed successfully; action pending” response
     *   Server validates the NS (DNS servers respond correctly )
     *   If NS validate
        *   Remove the pendingCreate status
        *   Insert pending action (<domain:panData> ) poll message with a positive result ( “paResult=1” )
     *   else if within validation period
        *   Validate again at the next interval
     *   else
        *   Remove domain ( or reject update )
        *   Insert pending action (<domain:panData> ) poll message with negative result ( “paResult=0” ).  An extension could be added to provide more error detail.
  2.  Registration Deferred Publication ( My thoughts without any detail previously provided )
     *   Client sends domain create with NS ( domain update may work in a similar fashion, but I see some added complexity)
     *   Server accepts the domain create for deferred publication and sets the “serverHold” and “ serverUpdateProhibited” statuses pending the validation.
        *   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?
     *   Server validates the NS (DNS servers respond correctly )
     *   If NS validate
        *   Remove the “serverHold” and “serverUpdate” statuses
        *   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?
           *   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.
     *   else if within validation period
        *   Validate again at the next interval.  No poll message required, since the state of the domain has not changed.
     *   else
        *   Remove the “serverUpdateProhibited” status to enable the client to modify the NS
        *   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?
           *   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.
              *   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.

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?

Thanks,


—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

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

VerisignInc.com<http://VerisignInc.com>

On Apr 25, 2015, at 10:26 AM, Patrick Mevzek <[e-mail]<mailto:[e-mail]>> wrote:

Le jeudi 05 mars 2015 à 21:07 -0300, Rubens Kuhl a écrit :

Has the use case of DNS publishing been considered for the changepoll
extension ? Some registries defer publication of a domain to the
registry zone until DNS servers respond correctly (authoritative,
DNSKEY matches DS etc.), and a poll message could signal that to the
sponsoring client. I couldn't find an appropriate operation in
changepoll-02... what are your and the group's thoughts on this ?

I agree that could be very useful, especially if the polling message can
carry some information on what tests have been done, which have failed,
and courses of action for the registrar (including info to know if the
failure is temporary or definitive).

However it could be using the operation name "update". But I would
recommend to define some kind of extensibility into the list of
operation names, making registry able to add some new ones.

When AFNIC did include a message for registrars after a DNS check in the
the past, here was how the polling message looked like :
<msgQ count="1" id="50001">
<qDate>2008-12-25T00:01:00.0Z</qDate>
<msg>
 <resZC type="plain-text">
ZONE : ndd-de-test-0001.fr<http://ndd-de-test-0001.fr>.
NS    : ns1.nic.fr<http://ns1.nic.fr>.
NS    : ns2.nic.fr<http://ns2.nic.fr>.
NS    : ns.ndd-de-test-0001.fr<http://ns.ndd-de-test-0001.fr>. [192.93.0.1, 2001:660:3005:1::1:1]

==> SUCCESS
 </resZC>
</msg>
</msgQ>


It was using at the time the pure text result of the Zonecheck tool.
Today, this tool has been replaced by ZoneMaster.

--
Patrick Mevzek