Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

From: "Gould, James" <[email-masked]>
Date: Mon, 16 Jul 2018 17:58:36 +0000

Hopefully both Martin and Patrick will participate in the REGEXT working session on the Unhandled Namespaces.  

I agree that the DNSSEC extension falls into the unhandled namespace discussion; although the scenario is less severe than poll messages since a poll message can block the poll queue.  I believe that the login services defines what the server can return to the client, so if the client does not support the DNSSEC extension it is completely reasonable for the server not to return it.  If a client wants to see the DNSSEC information returned they should include the URI in their login services.  A client that can accept any extension back from the server can simply mirror the greeting services in the login services.  Returning the extension irrespective of the client services is not in line with the protocol.  Use of the <extValue> approach provides a middle ground of returning the information without breaking the services defined in the login services since it will not be parsed, validated, and marshalled by a validating client.  
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 7/16/18, 12:44 PM, "regext on behalf of Martin Casanova" <[email-masked] on behalf of [email-masked]> wrote:

    @Thoma Corte: Sorry if my formulation was not precise enough:
    
    “The precondition of this approach is, that we actually can ask all registrars to prepare their clients to at least tolerate new poll messages and to update their business logic in order to process the newly given information properly if they wish to do so.” 
    
    With this statement I wanted to support the  <extValue> approach. No (validating) client will have a  technical problem receiving such a message regardless of what was configured at login. But as I was speaking to a registrar he told me: “So far you only sent me outgoing transfer poll messages and thats all my client is prepared for. ” So in our case we need to announce to registrars that they should build tolerant clients to be prepared to also receive unexpected poll messages with content in <extValue> eg. also low balance notifications in the future.. And that not every poll message will be automatically an outgoing transfer notification anymore.
    
    @Patrick
    In deed, for domain info requests on DNSSec domains we so far left out the DNSSec part in the domain info response if the client was not DNSSec enabled at login. In the future this content could also be transmitted in the <extValue>. To me it falls also under the “unhandled namespace” problem.
    
    Martin Casanova
    ________________________________________
    Von: regext [[email-masked]]&quot; im Auftrag von &quot;Patrick Mevzek [[email-masked]]
    Gesendet: Montag, 16. Juli 2018 18:02
    An: [email-masked]
    Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)
    
    On Mon, Jul 16, 2018, at 17:41, Patrick Mevzek wrote:
    > This is indeed more pragmatic. But all this mechanism to define which
    > messages to accept
    > will be outside the EPP protocol and this WG.
    
    But please also remember that if we want to tackle this problem in a generic way (and also taking care of different servers and clients strategies regarding handling of namespaces and inline/offline parsing and use) it is not limited to a single extension (the thread started long ago with changePoll) nor in fact limited to poll messages.
    
    Imagine registrar A wanting to request a transfer from registrar B. In some registries it means that regitrar A can do a domain:info on the domain, with the authInfo to get access to all details, and specifically the contacts.
    But a domain can have a secDNS part in the domain:info reply.
    What happens if the registrar A did not login with the secDNS extension (maybe this case does not exist in gTLDs where DNSSEC is mandatory but again we have other registries cases to take into account)?
    
    Should the domain:info return an error? Return everything as is? Return everything but the secDNS part?
    
    The last case is the worst to me: some registrars may like not to support DNSSEC at all (and hence will not log in at all, or you have other cases where registries mandate specific tests to be "DNSSEC" accredited so it may not even be possible to log in with secDNS extension even if the registrar would like to) but, and especially for this, being able to detect beforehand if some client is trying to transfer to them a domain using DNSSEC, that they would like to refuse transferring.

    Of course the above is only one example with a domain:info and the secDNS extension but I am sure we can find others.
    
    This illustrates I think the distinction I made in earlier messages and the different semantic I attach to extensions listed as login: for me they are those that the client announce it will use. Of course, it has no control over messages or objects he is not the origin or the sponsor, all cases where other namespaces may appear.

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

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 16 Jul 2018 20:31:57 +0200

On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> I believe that the login 
> services defines what the server can return to the client, so if the 
> client does not support the DNSSEC extension it is completely reasonable 
> for the server not to return it.  If a client wants to see the DNSSEC 
> information returned they should include the URI in their login 
> services. 

James, please, again, take into account some real life examples that happen today:

registries restrict the use of secDNS at login for only the registrars having passed
a specific accreditation test (trying to login with it without prior registry vetting triggers an authentication error, so the registrar can only do its business if it removes this extension from list at login)
thus, in your case (just removing the content), a registrar not wanting to do DNSSEC and not wanting to transfer
to him a currently DNSSEC-enabled domain will have no way to know that.

And saying to registrars: "then pass registry accreditation tests to be able to login with secDNS and see **others** domain names with secDNS data while you do not want to do any DNSSEC related stuff", is certainly not going to fly...

As long as we take into account only some cases and not others we will never be
able to deliver an extension used by multiple registries.
Also, before anything happen I will be very interested by intention of support
(which means deployment) from registries.

Otherwise, like I said, this problem exists since EPP started so it is not new,
and it seems the current status quo fits most of the player (due to the number of people
having participated here), so we are maybe devoting resources to trying to design
something perfect... that noone will then use :-(

-- 
  Patrick Mevzek

---

From: Martin Casanova <[email-masked]>
Date: Mon, 16 Jul 2018 19:08:39 +0000

Patrick

To be clear the domain info response will be sent just without the DNSSec part. Therefore a not DNSSec interested registrar will just not see the DNSSec configuration but all the rest of the domain info resData. I don't see a problem with that.

In our case a registrar currently needs to be accredited by us (DNSEC_ENABLED) in order to successfully login with DNSSec extension configured and he will only be able to transfer a DNSSec domain to him if the configured DNSSec at login. 

In case he is DNSSec enabled but still logs in without this extension he will get a failure with error message similar to  “Not allowed to transfer DNSSec Domain” when trying to transfer a DNSSec domain to him.

So actually there is a way to know why it didn't work for him.

As a matter of fact we will have to over think this rule now because with CDS DNSSec Data can be configured by the DNS-Operator of a domain as well (which does not need to be the registrar) . So a domain of a non DNSSec accredited registrar could end up with  DNSSec data. In case he is DNSSec accredited he might be interested to keep his DNSSec Data synchronized with the data at the registry originated by CDS. That is exactly our use case where we want to use the change poll extension.

Martin 
________________________________________
Von: regext [[email-masked]]&quot; im Auftrag von &quot;Patrick Mevzek [[email-masked]]
Gesendet: Montag, 16. Juli 2018 20:31
An: [email-masked]
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

--
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 16 Jul 2018 21:32:45 +0200

On Mon, Jul 16, 2018, at 21:08, Martin Casanova wrote:
> To be clear the domain info response will be sent just without the 
> DNSSec part. Therefore a not DNSSec interested registrar will just not 
> see the DNSSec configuration but all the rest of the domain info 
> resData. I don't see a problem with that.

Here is the problem as already exposed: you may have registrars that do not want to deal
with DNSSEC on a philosophical principle. They may want to specifically not try to 
transfer a currently DNSSEC enabled domain to them, because they know it will break
resolution and they do not want to handle the customer saying that they broke
the domain.

Besides using the DNS, in your case, this registrar has no way to know in advance
that the transfer will be a problem. And I suspect telling them 'Please be DNSSEC
accredited with us and login with secDNS extension' will fall on a deaf ear.

> In case he is DNSSec enabled but still logs in without this extension he 
> will get a failure with error message similar to  “Not allowed to 
> transfer DNSSec Domain” when trying to transfer a DNSSec domain to him.

What happens for a non-DNSSEC enabled registrar (and hence not using secDNS on login)
when he tries to transfer to him a DNSSEC-enabled domain?
Is this refused?
 
Also to leave the discussion on track, this DNSSEC part of domain:info response was only
one example of the same problem ("unhandled namespaces") outside of the poll messages,
because I think the problem is global and we should tackle it globally (or not at all
and leave it at the current status quo).

-- 
  Patrick Mevzek

---

From: Martin Casanova <[email-masked]>
Date: Mon, 16 Jul 2018 19:47:56 +0000

See my comment below..

________________________________________
Von: regext [[email-masked]]&quot; im Auftrag von &quot;Patrick Mevzek [[email-masked]]
Gesendet: Montag, 16. Juli 2018 21:32
An: [email-masked]
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

M: The Registrar does not need to check the domain with domain info in order to check if he is allowed to to do or not.
M: If he is not than we will prevent it (see next comment)

M: No we never told such a thing to a registrar. However we do put in the manual that a DNSSec Domain can only be transfered to a DNSSec enabled Registrar (up to now at least)

M: Exactly. Through the transitive relation that we prevent him to start a DNSSec enabled session and a non enabled session will never authorize an incoming transfer of a DNSSec domain.

M: Thats exactly what we should discuss in a minute :)

--
  Patrick Mevzek

Martin

---

From: Jody Kolker <[email-masked]>
Date: Mon, 16 Jul 2018 19:48:23 +0000

Hi Martin,

<<

How does DNSSEC data get configured by the DNS-Operator of a domain if the DNS-Operator is not the registrar?  Is the DNSSEC data set without the registrar knowing it was added?  If so, how?

Thanks,
Jody Kolker

-----Original Message-----
From: regext <[email-masked]> On Behalf Of Martin Casanova
Sent: Monday, July 16, 2018 2:09 PM
To: Patrick Mevzek <[email-masked]>; [email-masked]
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

Patrick

In case he is DNSSec enabled but still logs in without this extension he will get a failure with error message similar to  "Not allowed to transfer DNSSec Domain" when trying to transfer a DNSSec domain to him.

Martin

On Mon, Jul 16, 2018, at 19:58, Gould, James wrote:
> client does not support the DNSSEC extension it is completely 
> reasonable for the server not to return it.  If a client wants to see 
> the DNSSEC information returned they should include the URI in their 
> login services.

registries restrict the use of secDNS at login for only the registrars having passed a specific accreditation test (trying to login with it without prior registry vetting triggers an authentication error, so the registrar can only do its business if it removes this extension from list at login) thus, in your case (just removing the content), a registrar not wanting to do DNSSEC and not wanting to transfer to him a currently DNSSEC-enabled domain will have no way to know that.

As long as we take into account only some cases and not others we will never be able to deliver an extension used by multiple registries.
Also, before anything happen I will be very interested by intention of support (which means deployment) from registries.

Otherwise, like I said, this problem exists since EPP started so it is not new, and it seems the current status quo fits most of the player (due to the number of people having participated here), so we are maybe devoting resources to trying to design something perfect... that noone will then use :-(

--
  Patrick Mevzek

---

From: Ulrich Wisser <[email-masked]>
Date: Mon, 16 Jul 2018 20:58:04 +0100

Hi,

are we really sure this is a problem worth solving?
At .se registrars (with very few exceptions) fall into two categories.
- do never poll
- poll and ignore anyway

I know that we have registrars who validate, but those usually support all
our extensions.

Could anybody produce numbers on registrars who do all three?
  1. poll
  2. validate
  3. do not support all extensions

/Ulrich

Martin Casanova <[email-masked]> schrieb am Mo., 16. Juli 2018
um 15:09 Uhr:

> Patrick
>
> To be clear the domain info response will be sent just without the DNSSec
> part. Therefore a not DNSSec interested registrar will just not see the
> DNSSec configuration but all the rest of the domain info resData. I don't
> see a problem with that.
>
> In our case a registrar currently needs to be accredited by us
> (DNSEC_ENABLED) in order to successfully login with DNSSec extension
> configured and he will only be able to transfer a DNSSec domain to him if
> the configured DNSSec at login.
>
> will get a failure with error message similar to  “Not allowed to transfer
> DNSSec Domain” when trying to transfer a DNSSec domain to him.
>
> As a matter of fact we will have to over think this rule now because with
> CDS DNSSec Data can be configured by the DNS-Operator of a domain as well
> (which does not need to be the registrar) . So a domain of a non DNSSec
> accredited registrar could end up with  DNSSec data. In case he is DNSSec
> accredited he might be interested to keep his DNSSec Data synchronized with
> the data at the registry originated by CDS. That is exactly our use case
> where we want to use the change poll extension.
>
> Martin
> Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D
> Action: draft-ietf-regext-change-poll-07.txt)
>
> a specific accreditation test (trying to login with it without prior
> registry vetting triggers an authentication error, so the registrar can
> only do its business if it removes this extension from list at login)
> And saying to registrars: "then pass registry accreditation tests to be
> able to login with secDNS and see **others** domain names with secDNS data
> while you do not want to do any DNSSEC related stuff", is certainly not
> going to fly...
>
-- 
Ulrich Wisser
[email-masked]

---

From: Martin Casanova <[email-masked]>
Date: Mon, 16 Jul 2018 21:39:02 +0000

Hello Jody
________________________________________
Von: Jody Kolker [[email-masked]]
Gesendet: Montag, 16. Juli 2018 21:48
An: Martin Casanova; Patrick Mevzek; [email-masked]
Betreff: RE: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

Hi Martin,

<<

M: This done by the polling specific DNS Records (CDS) from the configured name servers of a domains. (RFC-7344 and RFC-8078) which we are currently implementing. It could be and will be often the case that the DNS-Operator and the registrar are the same entity but its not a must.
"We support RFC-7344 and RFC-8078 for automated DNSSEC delegation trust maintenance. Enable fully automated DNSSEC bootstraping, key rollover or removal in your favourite name server software. Once a day your name servers will be checked for new CDS signaling records. Changes in CDS signaling records are accepted and published in our .ch or .li zone after a delay of 3 working days if our acceptance criterias are met. "

Thanks,
Jody Kolker
Martin Casanova

-----Original Message-----
From: regext <[email-masked]> On Behalf Of Martin Casanova
Sent: Monday, July 16, 2018 2:09 PM
To: Patrick Mevzek <[email-masked]>; [email-masked]
Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

Patrick

Martin

--
  Patrick Mevzek

---

From: Martin Casanova <[email-masked]>
Date: Mon, 16 Jul 2018 22:09:10 +0000

Hello Ulrich

I don't know the numbers but I think you are right that most registrars don't care too much yet.
On the other hand there are some new extensions in the pipeline that use the poll mechanism. (change poll, balance etc.)

Thats why I believe it will/should become more important in the future.

The number of validating clients may be small but I don't believe that we can ignore them and send our poll message with extensions regardless of the configured login services.
Even if some of the registrars don't implement according to the standards, I think at least the registries should do so and creating a poisoned message is therefore not an option for us.

So the only alternative to deal with it is to not send the extension part and in some cases this means to not send a poll message at all.

Therefore a client has no option of knowing that he is missing out on some information unless studying the manuals of the registry...

I think that this is hindering the development of EPP Poll extensions for no good reason. Out of sight - out of mind...

Martin

________________________________
Von: Ulrich Wisser [[email-masked]]
Gesendet: Montag, 16. Juli 2018 21:58
An: Martin Casanova
Cc: Patrick Mevzek; [email-masked]
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

Hi,

I know that we have registrars who validate, but those usually support all our extensions.

/Ulrich

Martin Casanova <[email-masked]<mailto:[email-masked]>> schrieb am Mo., 16. Juli 2018 um 15:09 Uhr:
Patrick

Martin
________________________________________
Von: regext [[email-masked]<mailto:[email-masked]>]&quot; im Auftrag von &quot;Patrick Mevzek [[email-masked]<mailto:[email-masked]>]
Gesendet: Montag, 16. Juli 2018 20:31
An: [email-masked]<mailto:[email-masked]>
Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

--
  Patrick Mevzek

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext
--
Ulrich Wisser
[email-masked]<mailto:[email-masked]>

---

From: Ulrich Wisser <[email-masked]>
Date: Tue, 17 Jul 2018 01:27:09 +0100

Hi Martin,

as was said in the wg session, you are a registrar to a registry. You
probably have a contract and in most cases, you have to go through some
sort of OTE.
So how would you get into a situation where you cannot validate data from
the registry? Of course you could choose to not support one of the
extensions and just ignore those messages. By all means, do that. And I
mean do that, ignore the message. From a registry perspective there is no
good way to handle this. None of the proposals leads to actual fixing of
the problem. It just helps lazy registrars to ignore the problem. That can
be achieved cheaper!

/Ulrich

um 18:09 Uhr:

> On the other hand there are some new extensions in the pipeline that use
> the poll mechanism. (change poll, balance etc.)
>
> The number of validating clients may be small but I don't believe that we
> can ignore them and send our poll message with extensions regardless of the
> configured login services.
> Even if some of the registrars don't implement according to the standards,
> I think at least the registries should do so and creating a poisoned
> message is therefore not an option for us.
>
> So the only alternative to deal with it is to not send the extension part
> and in some cases this means to not send a poll message at all.
>
> Therefore a client has no option of knowing that he is missing out on some
> information unless studying the manuals of the registry...
>
> I think that this is hindering the development of EPP Poll extensions for
> no good reason. Out of sight - out of mind...
>
> Martin
>
>
>
> ------------------------------
> *Von:* Ulrich Wisser [[email-masked]]
> *Gesendet:* Montag, 16. Juli 2018 21:58
> *An:* Martin Casanova
> *Cc:* Patrick Mevzek; [email-masked]
>
> *Betreff:* Re: [regext] Poll messages with unhandled namespaces (was Re:
> I-D Action: draft-ietf-regext-change-poll-07.txt)
> Hi,
>
>> Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re:
>> I-D Action: draft-ietf-regext-change-poll-07.txt)
>>
-- 
Ulrich Wisser
[email-masked]

---

From: Martin Casanova <[email-masked]>
Date: Tue, 17 Jul 2018 09:10:32 +0000

Hi Ulrich

We do have contracts yes. However experience shows us that some registrars just don't have the necessary technical skills or means to react on any changes we ask them to implement. To pull a change through, long dead lines must be granted and even after that, only a part of them actually got active. Many registrars only react after we don’t support the outdated options anymore and then call our support to ask why it fails, even though they were reminded several times.

In this cases customer relations will ask the technical team to make an exception for so and so registrar until he fixed his client which leads to more work having to configure opt out for single registrars. Also there is no standard way of triggering registry initiated messages in OTE yet.

So knowing this we were looking for a more elegant way than going through this hassle for every new poll extension we plan to implement. (That's the situation where clients cannot validate data from the registry)

To ask the registrars to ignore “unknown” extensions would be the same as asking them not to validate the poll responses at all or to at least skip poll messages for which validation fails due to unhandled name-spaces since this could occur any time a new poll extension is implemented.

If the extended poll messages are sent regardless of the configured login services, would that not contradict the idea that only the intersecting set of extensions configured in greeting and login are activated for a session? That’s how I understood Scott Hollenbeck examples but I may be wrong.

If there is a consent in the WG about these two last points I agree it is also an easy solution to just send the message and expect the clients to cope with it.

Martin

Gesendet: Dienstag, 17. Juli 2018 02:27

Hi Martin,

as was said in the wg session, you are a registrar to a registry. You probably have a contract and in most cases, you have to go through some sort of OTE.
So how would you get into a situation where you cannot validate data from the registry? Of course you could choose to not support one of the extensions and just ignore those messages. By all means, do that. And I mean do that, ignore the message. From a registry perspective there is no good way to handle this. None of the proposals leads to actual fixing of the problem. It just helps lazy registrars to ignore the problem. That can be achieved cheaper!

/Ulrich

Martin Casanova <[email-masked]<mailto:[email-masked]>> schrieb am Mo., 16. Juli 2018 um 18:09 Uhr:
Hello Ulrich

Martin

________________________________
Von: Ulrich Wisser [[email-masked]<mailto:[email-masked]>]
Gesendet: Montag, 16. Juli 2018 21:58
An: Martin Casanova
Cc: Patrick Mevzek; [email-masked]<mailto:[email-masked]>

/Ulrich

Martin

--
  Patrick Mevzek

---

From: Ulrich Wisser <[email-masked]>
Date: Tue, 17 Jul 2018 14:25:22 +0100

Martin,

if I understand you right, the problem is ignorant registrars. And the
solution is to make it easier for them to stay ignorant.
I am convinced that this is not the best way to go.

Clear communication with registrars and all internal departments sounds
more feasible.
We deploy these changes six months in advance in our OTE environment.
We check who tested and actively contact registrars that don't.
The only time we had to do a rollback was when the product owner thought
that would be unnecessary.

/Ulrich

Martin Casanova <[email-masked]> schrieb am Di., 17. Juli 2018
um 05:10 Uhr:

> Hi Ulrich
>
>
> We do have contracts yes. However experience shows us that some registrars
> just don't have the necessary technical skills or means to react on any
> changes we ask them to implement. To pull a change through, long dead lines
> must be granted and even after that, only a part of them actually got
> active. Many registrars only react after we don’t support the outdated
> options anymore and then call our support to ask why it fails, even though
> they were reminded several times.
>
>
> In this cases customer relations will ask the technical team to make an
> exception for so and so registrar until he fixed his client which leads to
> more work having to configure opt out for single registrars. Also there is
> no standard way of triggering registry initiated messages in OTE yet.
>
>
> So knowing this we were looking for a more elegant way than going through
> this hassle for every new poll extension we plan to implement. (That's the
> situation where clients cannot validate data from the registry)
>
>
> To ask the registrars to ignore “unknown” extensions would be the same as
> asking them not to validate the poll responses at all or to at least skip
> poll messages for which validation fails due to unhandled name-spaces since
> this could occur any time a new poll extension is implemented.
>
>
> If the extended poll messages are sent regardless of the configured login
> services, would that not contradict the idea that only the intersecting set
> of extensions configured in greeting and login are activated for a session?
> That’s how I understood Scott Hollenbeck examples but I may be wrong.
>
>
> If there is a consent in the WG about these two last points I agree it is
> also an easy solution to just send the message and expect the clients to
> cope with it.
>
>
> Martin
>
> *Gesendet:* Dienstag, 17. Juli 2018 02:27
>
> *An:* Martin Casanova
>> Even if some of the registrars don't implement according to the
>> standards, I think at least the registries should do so and creating a
>> poisoned message is therefore not an option for us.
>>
>> Therefore a client has no option of knowing that he is missing out on
>> some information unless studying the manuals of the registry...
>>
>> Martin Casanova <[email-masked]> schrieb am Mo., 16. Juli
>> 2018 um 15:09 Uhr:
>>
>>> Patrick
>>>
>>> DNSSec part. Therefore a not DNSSec interested registrar will just not see
>>> the DNSSec configuration but all the rest of the domain info resData. I
>>> don't see a problem with that.
>>>
>>> As a matter of fact we will have to over think this rule now because
>>> with CDS DNSSec Data can be configured by the DNS-Operator of a domain as
>>> well (which does not need to be the registrar) . So a domain of a non
>>> DNSSec accredited registrar could end up with  DNSSec data. In case he is
>>> DNSSec accredited he might be interested to keep his DNSSec Data
>>> synchronized with the data at the registry originated by CDS. That is
>>> exactly our use case where we want to use the change poll extension.
>>>
>>> Martin
>>> reasonable
-- 
Ulrich Wisser
[email-masked]

---

From: Martin Casanova <[email-masked]>
Date: Tue, 17 Jul 2018 15:41:23 +0000

Ulrich

I am impressed by your process of checking who tested and who did not and actively contact those who did not test. We did something like that as well when we turned off TLS1.0 so I agree to this procedure for some cases.

It kind of confirms my statement that a technical change needs long deadlines and intense assistance by the registry.

So in the case of poll extensions how would you proceed? Would you ask all the clients to include the new extensions in their login command by the date x? How would you proceed with the ones that don't react on your request after the dead line?

Some of the options are:

1. Block logins without that extension? (Actually we do not want to force anyone to use the poll extension)

2. Send poll messages with extensions anyway? (not exactly according to the current RFC)

3. Don’t send such poll extensions or poll messages at all for such clients? (creating the poll messages is an asynchronous process and the server has actually no way of knowing with which extensions the client might logs in the next time to get his poll messages. Also different concurrent sessions can support different extensions)

4. Maintaining an out of band server side list of which registrar subscribed to which poll extension? (ok but a lot of work for every registry and registrars dealing with lots of registries)

I think as well that a registrar who does not want to use a poll extension should always be free to ignore them. So it boils down to a technical question of how to handle the special case of unknown name-spaces in poll messages. For this question we tried to find an easy answer with the <extValue> approach. It signals to the interested registrar that there is something new but should not break current client implementations.

Martin

Gesendet: Dienstag, 17. Juli 2018 15:25

Martin,

if I understand you right, the problem is ignorant registrars. And the solution is to make it easier for them to stay ignorant.
I am convinced that this is not the best way to go.

Clear communication with registrars and all internal departments sounds more feasible.
We deploy these changes six months in advance in our OTE environment.
We check who tested and actively contact registrars that don't.
The only time we had to do a rollback was when the product owner thought that would be unnecessary.

/Ulrich

Martin Casanova <[email-masked]<mailto:[email-masked]>> schrieb am Di., 17. Juli 2018 um 05:10 Uhr:

Hi Ulrich

Martin

An: Martin Casanova

/Ulrich

Martin

/Ulrich

Martin

--
  Patrick Mevzek