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 <martin.casan...@switch.ch> 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 > > ------------------------------ > *Von:* Ulrich Wisser [ulr...@wisser.se] > *Gesendet:* Dienstag, 17. Juli 2018 02:27 > > *An:* Martin Casanova > *Cc:* Patrick Mevzek; regext@ietf.org > *Betreff:* Re: [regext] Poll messages with unhandled namespaces (was Re: > I-D Action: draft-ietf-regext-change-poll-07.txt) > 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 <martin.casan...@switch.ch> schrieb am Mo., 16. Juli 2018 > um 18:09 Uhr: > >> 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 [ulr...@wisser.se] >> *Gesendet:* Montag, 16. Juli 2018 21:58 >> *An:* Martin Casanova >> *Cc:* Patrick Mevzek; regext@ietf.org >> >> *Betreff:* Re: [regext] Poll messages with unhandled namespaces (was Re: >> I-D Action: draft-ietf-regext-change-poll-07.txt) >> 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 <martin.casan...@switch.ch> 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. >>> >>> 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 [regext-boun...@ietf.org]" im Auftrag von >>> "Patrick Mevzek [p...@dotandco.com] >>> Gesendet: Montag, 16. Juli 2018 20:31 >>> An: regext@ietf.org >>> 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 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 >>> >>> _______________________________________________ >>> regext mailing list >>> regext@ietf.org >>> https://www.ietf.org/mailman/listinfo/regext >>> >>> _______________________________________________ >>> regext mailing list >>> regext@ietf.org >>> https://www.ietf.org/mailman/listinfo/regext >>> >> -- >> Ulrich Wisser >> ulr...@wisser.se >> > -- > Ulrich Wisser > ulr...@wisser.se > -- Ulrich Wisser ulr...@wisser.se
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
