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

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

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

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

Hello Jody Von: Jody Kolker [jkol...@godaddy.com] Gesendet: Montag, 16. Juli 2018 21:48 An: Martin Casanova; Patrick Mevzek; regext@ietf.org Betreff: RE: [regext] Poll messages with unhandled namespaces (was Re: I-D Action:

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

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

Hi Martin, << 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

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

See my comment below.. Von: regext [regext-boun...@ietf.org] im Auftrag von Patrick Mevzek [p...@dotandco.com] Gesendet: Montag, 16. Juli 2018 21:32 An: regext@ietf.org Betreff: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action:

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 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

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

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

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

@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

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

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

Hi James, my  answers to your questions are below. Regards, Mario Il 16/07/2018 04:24, Gould, James ha scritto: Mario, In reviewing the mailing list feedback on draft-gould-carney-regext-registry, I missed your feedback.  Thanks for taking the time to review

[regext] Milestones changed for regext WG

Changed milestone "Submit for publication "Organization Extension for EPP"", resolved as "Done". Changed milestone "Submit for publication "EPP Organization Mapping"", resolved as "Done". URL: https://datatracker.ietf.org/wg/regext/about/ ___ regext

[regext] Milestones changed for regext WG

Changed milestone "Submit for publication "Allocation Token Extension for EPP"", resolved as "Done". URL: https://datatracker.ietf.org/wg/regext/about/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext

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

James, Patrick Partly I understand Patrick's argument that the introduction of new types of poll messages could cause a problem for clients if their business logic is not prepared for it, even if technically the message can be received without any problem. Also our rule of restricting not

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

Patrick, My replies are embedded below. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com On 7/16/18, 3:14 AM, "regext on behalf of Patrick Mevzek" wrote: On Mon, Jun 11, 2018, at

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

Patrick, Yes, I believe the idea that Martin came up with to use the element with the inclusion of the full unhandled XML block is the best option thus far. It honors the client login services, it includes all of the XML for later processing, and it does not cause XML parsing failures or

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

Patrick, In this case the server is communicating an error condition, but the condition does not result in an error code being returned. A poll message really cannot fail, otherwise you get into the poison message scenario. Even if we disagreed that this is an error condition, the RFC 5730

[regext] Suggestion of work methodology?

Hello, This is a meta discussion on the way we work. So just exposing some ideas, if they could interest anyone. Feel free to participate in you want, here or in private. You may have seen this email on the DNSOP working group:

Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt

On Mon, Jun 11, 2018, at 15:48, Gould, James wrote: > JG - Why does the extension data need to reside within the > node? EPP already has an extension mechanism that > can be used, so why not use it in this case? I have two reasons for this. The first one being that the XML document in itself