Re: [regext] Interest in collaborating on an EPP over HTTP draft?
It is interesting to see the discussion about EPP over HTTP. Right now I am working on a greenfield development project where we will need to connect to the majority of Registries. Being that this is a greenfield project we have been keen to architect the system that will interact between the Registries and the Registrar to run within the public cloud. Azure and or AWS. We had a discussion the other day about using Azure Functions but had to quickly rule it out because EPP requirement on TCP Sockets. Azure Functions only support http as a protocol . Has there been any conversation about the Registries using REST? Cheers Ryan -Original Message- From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Patrick Mevzek Sent: Tuesday, May 29, 2018 10:18 PM To: regext@ietf.org Subject: Re: [regext] Interest in collaborating on an EPP over HTTP draft? On Tue, May 29, 2018, at 19:40, Justin Mack wrote: > Just about everyone else uses EPP 0.4 or EPP 1.0, with notable > exceptions of RRI (.DE) and TMCH for the Trademark Clearinghouse. If you want to list everything that looks like EPP but is not EPP, you could list .IE too. However I think this is unrelated: the protocol and the transport should be orthogonal. The protocol should specify some properties it needs (RFC 5730 for EPP, section 2.1 that should probably be the starting point of all endeavours to define new transports for EPP), and then it should work with any transport having those properties. Both "parts" should be able to evolve/be swapped independently as long as the contract (the common set of properties agreed upon) remains valid. As for EPP, each new transport should have a specification like it is done in RFC 5734 for TLS. -- 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
Re: [regext] WGLC: draft-ietf-regext-org-02
On Wed, May 30, 2018, at 22:24, Antoin Verschuren wrote: > I remember a CENTR meeting where ccTLD’s tried to get consensus over if > we could harmonize EPP extensions so registrars would not have to code > differently for every TLD. > This was before EPPEXT existed. > We all thought this would be a good idea. > But half the registries concluded that they wanted to stick to their own > extensions because they felt local legislation or their local > constituencies required them so, and the other half had the standpoint > that they would only implement as followers, after extensions would be > standardized. I have thought for a long time about EPP standardization and I came into conclusion that if consolidation does not happen it is for reasons outside of the technical realm. Hence my belief no technical solutions would change any of it. > This was not only TLD registries that had an opinion, > and I remember some hesitation especially by ICANN registrars as well > because they didn't want extra work, but third party dns-operators, > ICANN related policy makers, RIR’s, registrants and plain IETF protocol > guardians also have an equal voice in the IETF process, even though they > don’t implement. While every voice is welcome at the table, I still like and favor the idea of "running code". Besides rough consensus which you are all saying we have, so let us go forward on this topic and standardize this extension that so many actors want or agree to. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
Op 28 mei 2018, om 22:48 heeft Patrick Mevzek het volgende geschreven: > In your quote you missed the other part which is basically: all domain names > are not under ICANN policies. I didn’t want to go in that discussion, but I’m on your side on that one. > So for all other TLDs currently can you let me know which protocol > limitations currently forbid registry to add formatted content in their whois > or, let us say just decide to implement RDAP to start with? Do you really > think there are almost none because of protocol limitations, especially in > the EPP channel, or maybe for other reasons? Perhaps it’s not only protocol limitations, or perhaps limitation the wrong word, it’s more the pinpointed ICANN RRR model I think that can only be provisioned for now. I remember a CENTR meeting where ccTLD’s tried to get consensus over if we could harmonize EPP extensions so registrars would not have to code differently for every TLD. This was before EPPEXT existed. We all thought this would be a good idea. But half the registries concluded that they wanted to stick to their own extensions because they felt local legislation or their local constituencies required them so, and the other half had the standpoint that they would only implement as followers, after extensions would be standardized. Again Patrick, I share your concern of complexity, and we shouldn’t build something nobody uses. I also shared your concern for double labeling both at the organization and link level, but James managed to convince me it’s a choice between two bad’s where the responsibility of registrars over records they maintain outscores double entries in the database for organizations that do anything for anybody. The reseller draft was originally requested and supported by cnnic, sidn and dns belgium who also had the intend to implement. If not this standard then their own extension. Other registries didn’t immediately acknowledge the need for resellers unless mandated by (ICANN) policy, but there was consensus that if we were to standardize something to accommodate resellers, it should be reusable for other emerging "Internet identifier registration related roles" as well. This was not only TLD registries that had an opinion, and I remember some hesitation especially by ICANN registrars as well because they didn't want extra work, but third party dns-operators, ICANN related policy makers, RIR’s, registrants and plain IETF protocol guardians also have an equal voice in the IETF process, even though they don’t implement. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 signature.asc Description: Message signed with OpenPGP using GPGMail ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Potential Topic for IETF-102: RDAP Search Capabilities
Folks, one of the questions that came up during a presentation at the recent Registration Operations Workshop was focused on RDAP's search capabilities and if they were sufficient for use in the gTLD community. Francisco Arias has some thoughts on functional requirements, so I thought it might be a good idea to talk about the topic at IETF-102. Francisco has confirmed that he's available and can talk to the topic. Can we consider adding this topic to our meeting agenda? Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Delegated EPP
Besides DNSSEC, I'm thinking of NS data and reseller data kind regards Pieter > On 30 May 2018, at 11:10, Kal Feher wrote: > > Hi Pieter, > > could you elaborate on what objects you think might be modified? Are you > thinking of anything other than DNSSEC material? > > delegation of epp to 3rd parties that are unknown to the registry does have > some operational implications that need to be thought through. Although I > suppose this group isnt regops. > > > On 29/5/18 6:13 am, Pieter Vandepitte wrote: >> Hi, >> >> As I see discussions popping up now and then of 3rd party organisations >> having to modify registry objects, wouldn't it be an idea to design >> something like delegated EPP instead of implementing new protocols? >> Something like: a registrar assigns a group to an object, then generates a >> token for the group and shares it with a 3rd party. Could be more or less >> complex, introducing users, etc. >> >> I'm probably reopening old discussions, but maybe worth thinking of. >> >> Pieter >> ___ >> regext mailing list >> regext@ietf.org >> https://www.ietf.org/mailman/listinfo/regext > > -- > Kal Feher > Melbourne, Australia > > ___ > 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
Re: [regext] Delegated EPP
Hi Pieter, could you elaborate on what objects you think might be modified? Are you thinking of anything other than DNSSEC material? delegation of epp to 3rd parties that are unknown to the registry does have some operational implications that need to be thought through. Although I suppose this group isnt regops. On 29/5/18 6:13 am, Pieter Vandepitte wrote: Hi, As I see discussions popping up now and then of 3rd party organisations having to modify registry objects, wouldn't it be an idea to design something like delegated EPP instead of implementing new protocols? Something like: a registrar assigns a group to an object, then generates a token for the group and shares it with a 3rd party. Could be more or less complex, introducing users, etc. I'm probably reopening old discussions, but maybe worth thinking of. Pieter ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Kal Feher Melbourne, Australia ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
