On Mon, Apr 23, 2018, at 15:27, Gould, James wrote: > This may be an excellent topic for a working session at the next IETF.
If there is interest, yes... For now I think only you, me, and Pieter said anything in this discussion. So again maybe there is a real problem to tackle and then you need to foster participation, or there is no real problem to tackle any more because people already found out solutions. Since our resources are thin and participation low, I just want to make sure that no work starts before making sure it really address a problem shared by more than one party. > It would be great to hear opinions from others on this topic, since > there is obviously a gap in the interpretation of the greeting and login > services as it relates to responses (command responses and poll > response) provided by the server. It would be, yes. Also, in the meantime, people could report how they current software reacts, this would at least give some factual data. Speaking about what I know directly, because I worked on them and to the best of my recollection from those in the past: 1) my open source EPP client on login either mirrors all extensions given by registry (handling the case of the same extension in multiple version to select only the highest one) or specifically use only extensions requested by the application using the library; it does not validate EPP frames received from registries (for pragmatic reasons, and some people could say also for performance ones); for results of poll command, it will parse what it can based on the extension locally registered and let the calling application deal with others if it wants (it has access to both the parsed message and its raw complete form) 2) another proprietary client used on the field by a registrar for multiple registries: it does login only with the specific extensions implemented locally, it does not validate messages received, it stores poll results in a DB without any attempt to parse them in any way, and just acks them; other processes completely outside of EPP takes care of parsing the relevant part of the messages stored in DB. 3) as for a proprietary server, it checks what namespaces are used for each subsequent messages and that they correspond to namespaces selected at login (erroring otherwise); it does not validate XML messages on input or output; it does not reply in domain:info with namespaces not chosen by client but it does not filter them out in registry notifications. > How can the client ack the message if it doesn’t at least parse it for > the message id? The message ID is in the core EPP, it has nothing to do with any specific EPP extension that may have been used in the message itself. I am sure you know that, so I may have taken a too short summary in my previous message. > An EPP client should frame the responses per RFC 5734 > and will most likely parse the response to determine the result of the > command You are again it seems only thinking about poll results being messages resulting from past actions of this registrar. There are other ones like: - transfers, when the registrar looses a domain (so clearly not due to one of its action) - registry warning about contacts being deleted after not being used - registry warning about account balances, etc. The last two are specific examples today of basically being messages formatted in different ways in each registry as there is no standard covering them. And the result of the action could be conveyed by the data already in the panData node, irrespective to other specific extensions used to further describe the content of the message. > If the client > wants to retrieve everything from the server for later processing, then > the client can simply mirror the greeting services into the login > services. This is not always possible in reality, for at least this specific example that it is not imaginary since it derives directly from two known cases. This will also serve to illustrate that the problem is not really or not only with registry notification messages in fact, but that you have the exact same problem with a result of a domain:info for example (note that I am not claiming there is always one and only one good way to do things, and I am not sure a standard could be written on this, something closer to a guidance document that specifies the pro and cons of each case and at least mandate that registries clearly specify in which case they are) 1) Some registries treat DNSSEC very separately and mandates their registrars to be separately accredited for it. So it is optional, and some registrars may decide not to conduct it (as strange as it may seem I know some registrars are philosophically against DNSSEC, and not only for business reasons, and those ones, even if mandated by a contract to do DNSSEC, will still refuse to do it. Sad, maybe, but that is on the field today). The EPP server will most probably offer the exact same greeting to all clients. However, upon receiving the login, it will probably refuses to accept clients not being DNSSEC accredited present a login with a secdns extension. 2) Now imagine one of such reluctant registrar. It does not want to deal with DNSSEC in any way, because it has its reasons. Even if there would be no specific needs to be accredited so nothing special to do to be able to use the extension at login, since it does not want to handle it at all, it will never use the secdns extension at login. His choice. But you will probably also note that the most reluctant folks against DNSSEC are often very technically minded ones. Especially in EPP land, people know that DNSSEC and transfers do not play well together (keyRelay is a standard but is there anyone else than SIDN using it today? plannig to use it in the next year?) So you may have one registrar against it but also wanting to play nice to its customers: it wants to make sure never to accept an incoming transfer of a domain that is currently using DNSSEC because it does not handle it himself so the transfer at its core will just horribly break the zone. Now what happens if it does a domain:info for such a domain previous to the transfer (with the associated authInfo as being done by multiple registries): it either has the secDNS:infData (because the registry sends everything) or it has not, even if it exists for the domain (because the registry filters messages based on extensions provided at login). In the first case, with the "extra" data being there the registrar can detect that the domain is DNSSEC enabled and refuse to start the transfer (it could of course also query the DNS to find out about the DNSSEC exiting on the domain or not, but this may not exactly fit an EPP based workflow), making him nice and its customer happy as the zone will not get broken. Or the extra data is not there and the registrar does the transfer and the zone is broken. So here is an example that needs to be taken into account. Again I am not saying this is clear cut with a clear good option and a clear bad one. I think both positions have merits. This is the only purpose of my participation in the discussion, to try showing more of the global picture to really think about all cases, and their consequences. > Just because servers have been sending unsolicited extensions to clients > does not make it correct or appropriate from a protocol perspective. This issue being debated right now, and since there is 0 documents currently saying anything specifically on this, it would be quite inappropriate (and clearly not a good way to bring everyone around the table) to already label some servers being incorrect or inappropriate. > I > believe we have examples of EPP extensions (RFC 5910 and draft-ietf- > regext-epp-fees) that includes language related to what the server > should or should not due based on the client login services, so this > should be understood. I believe where it is not well understood is the > handling of poll messages, which would be the point in creating a new > draft. I still think the problem is larger than that, and not as clear cut as presented. IF the problem exists, it must be dealt globally and must not need text about it in each extension. > I believe not sending it creates more harm than benefits, even if the > registrar did not specify it at login, but clearly this is the core > point of our disagreement. Note that I am not fully convinced by either position in fact. For now I am just saying: - the problem is more complex that just registry notifications - each case has benefits and drawbacks - the problem may already have been solved and/or the registrars may not care to revisit the issue now > The registry should not return the secDNS extension in the domain info > response for a client that does support secDNS-1.0 (RFC 4310) or > secDNS-1.1 (RFC 5910) according to section 2 of RFC 5910 > (https://tools.ietf.org/html/rfc5910#page-4). Section 2 specifically handles the problem of transitioning from secDNS-1.0 to secDNS-1.1 so for now I fail to see how it is relevant to our discussion here. > Inclusion of an extension outside of the negotiated > services should result with an error on the server side and the server > should not return an unsupported extension back in a response. The > server does not know the capabilities of the client, where sending an > unsolicitated extension may result in a client-side failure in the case > for a validating client or a client that unmarshalls the response. The exact same problem exists in the opposite case. I am fine you disagree with me but I am not sure if you accept to see there are other cases where, using your interpretation, creates problems too. So it is not clear cut, and no solution resolves eerything. If work is engaged on this topic I think there is first a need to clearly define the problem statement, what cases exist today, what solutions may be implemented and their consequences. Only after that we could have a discussion on the merit of each solutions. But if we even disagree on the problem itself and the use cases that exist, then I will probably not be able to participate in the following discussion either. I was happier when you wrote in one of the first messages on the issue: " there is no great solution to the problem of including extensions (object or command-response) in poll messages to clients that don’t support the extension as indicated by their login services." There we agree, there is no great solution. So let us now not decide for a solution before even having explored all the problem space (or agree on its scope). Experiences here specifically from other registrars would be very useful. Again, don't you feel it strange that this issue has never been brought and discussed extensively before, during the nearly 20 years that EPP now exists? This does not mean of course there is not a problem, but then even more than elsewhere I fear very low level of participation from registrars... PS: just thinking more globally, please also take into account this example. A registrar connects at some time with extension X from the one offered by the registry. It does some operations through this connection and let us imagine that one of this operation triggers the *future* creation of a registry message that will use extension X. But through this connection the registar does not do a poll operation at all. Later the registar does another connection from scratch, this time without the extension X. It does a poll. What happens for the registry notification that had the X extension? You do not deliver it at all to the registar and block its queue? You deliver it completely, even with X? You deliver it while removing the X part, loosing it forever? Etc. No great solution either here. This needs to be documented before any attempt to solve (and again I do not believe it will be possible to find a solution that fits all cases, at best a guidance document clearly describing things, and suggesting things maybe at most, not mandating one case over another) -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
